Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MM drops after a few seconds

Status
Not open for further replies.

Softail09

Technical User
Oct 23, 2012
19
US
We changed from a MM 5.2 TDM connection to a SIP connection this summer and I don't know if this issue is related or not but it seems to have started around the same time. I have 9 800 #'s of which 6 work properly. The 3 that don't work do get routed to MM but after 4 seconds of hearing the voicemail message the calls get disconnected with a fast busy. Does anyone know if this might be related and if so how I can fix these lines?
 
We would need more information. You said 3 don't work but do any of the ones that work get routed to eh MM using the SIP trunk group?

What type of PBX are you using and is the SIP native or using a SIP gateway of some kind.





Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
These lines have worked fine for over 6 years but now callers to these 3 800 numbers are actually routed to the voicemail system but the message starts playing and then they get a busy signal and disconnected. Only one of the numbers is routed to a DID and you can call that number directly from the outside and it works and you can call all 3 of the numbers internally and they work. I have tried routing them to a different DNIS and they still follow the same pattern. I had Paetec try to change the DNIS in their system on one of them and it does the same thing no matter what DNIS is used. When I trace the calls they are getting a timeout signal and that is why they disconnect. It's like MM is not really seeing the number come in even though the caller gets a brief bit of the gretting. I don't have SIP trunks, just a SIP connection from CM to MM and all calls have to route over that trunk to reach MM.
 
when you call the number from the outside i assume it is coming in on a different trunk group than if you call the 800 number ?

If that is the case then it sounds like the trunk to trunk may be having an issue from the inbound to the outbound going to MM.

If you do a SIP trace on the MM OHV it may show more detail.

I assume you traced the call on the CM side but would need to see the trace from MM as well if you can post it.



Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Below is the trace I ran on the mailbox. I tried to keep it small so I don't overwhelm this post. This is what it does every time someone tries to leave a message.

When Object Event Type Call-Id Message Application Server Information Port Mailbox

10/22/2012 23:59 "TUI" 21217 "Information" 63193 "VIHTI" "Caller has requested to leave a message for mailbox 4031 after a ring no answer condition."
10/22/2012 23:59 "TUI" 21330 "Information" 63193 "VIHTI" "Greeting played" 1 4031
10/22/2012 23:59 "TUI" 21342 "Information" 63193 "VIHTI" "Statement 4 was interrupted by a hangup" 1 4031
10/22/2012 23:59 "TUI" 21235 "Information" 63193 "VIHTI" "Hang up was aborted." 1 4031

10/23/2012 11:33 "TUI" 21217 "Information" 63515 "VIHTI" "Caller has requested to leave a message for mailbox 4031 after a ring no answer condition." 2
10/23/2012 11:34 "TUI" 21330 "Information" 63515 "VIHTI" "Greeting played" 2 4031
10/23/2012 11:34 "TUI" 21342 "Information" 63515 "VIHTI" "Statement 4 was interrupted by a hangup" 2 4031
10/23/2012 11:34 "TUI" 21235 "Information" 63515 "VIHTI" "Hang up was aborted." 2 4031
10/23/2012 15:46 "TUI" 21217 "Information" 63857 "VIHTI" "Caller has requested to leave a message for mailbox 4031 after a ring no answer condition." 2
 
You need to turn on the SIP trace in the VMSC to that the trace will show the SIP messages in the OHV.

That should tell us what is going on or at least point us in the right direction it should look like the below trace from the MAS



10/23/12 15:33:36, "Call Management", 21010, "Information", 0, "TXDA1SVA2", "Incoming ring.", 4,
10/23/12 15:33:36, "Call Management", 22212, "Error", 0, "TXDA1SVA2", "ERROR NT significant event with ID '3221227347' was reported with strings '18049656501\nChicago SIP\n'.", 0,
10/23/12 15:33:36, "PBX Integration", 21409, "Information", 0, "TXDA1SVA2", "Integration data: Extension . Called extension . Calling extension +18049656501. Call divert 1.", 0,
10/23/12 15:33:36, "Call Management", 21027, "Information", 25733, "TXDA1SVA2", "Incoming call detected.", 4,
10/23/12 15:33:36, "Call Management", 21030, "Information", 25733, "TXDA1SVA2", "Call routed.", 4,
10/23/12 15:33:36, "Call Management", 21008, "Information", 0, "TXDA1SVA2", "Channel on hook.", 2,
10/23/12 15:33:36, "Call Management", 21048, "Information", 25733, "TXDA1SVA2", "SIP IN :INVITE sip:sipmm@heart.org SIP/2.0

Record-Route: <sip:604083d1@10.14.251.54;transport=tcp;lr>

Record-Route: <sip:10.14.251.53:15060;lr;sap=-1650612390*1*016asm-callprocessing.sar888868362~1351024416281~-1329103579~1;transport=tcp>

From: sip:18049656501@heart.org;tag=8062ccd02821e21b77f4edbbea700

To: sip:sipmm@heart.org

Call-ID: 8062ccd02821e21b87f4edbbea700

CSeq: 1 INVITE

Record-Route: <sip:604083d1@10.14.251.54:5063;transport=tcp;lr>

Record-Route: <sip:10.14.251.55:5063;lr;transport=tcp>

Via: SIP/2.0/TCP 10.14.251.54;branch=z9hG4bK0A0EFB3578088880051039008-AP;ft=46816

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880051039008

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039006
", 4,
10/23/12 15:33:36, "Call Management", 21048, "Information", 25733, "TXDA1SVA2", "SIP OUT :SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.14.251.54;branch=z9hG4bK0A0EFB3578088880051039008-AP;ft=46816

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880051039008

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039006

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039005

Via: SIP/2.0/TCP 10.14.251.54:5063;branch=z9hG4bK8062ccd02821e21b97f4edbbea700-AP;ft=47016

Via: SIP/2.0/TCP 10.14.251.55:5063;branch=z9hG4bK8062ccd02821e21b97f4edbbea700

From: sip:18049656501@heart.org;tag=8062ccd02821e21b77f4edbbea700

To: sip:sipmm@heart.org

Call-ID: 8062ccd02821e21b87f4edbbea700

CSeq: 1 INVITE

Server: Modular Messaging

Content-Length: 0



", 4,
10/23/12 15:33:36, "Call Management", 21048, "Information", 25733, "TXDA1SVA2", "SIP OUT :SIP/2.0 180 Ringing

Via: SIP/2.0/TCP 10.14.251.54;branch=z9hG4bK0A0EFB3578088880051039008-AP;ft=46816

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880051039008

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039006

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039005

Via: SIP/2.0/TCP 10.14.251.54:5063;branch=z9hG4bK8062ccd02821e21b97f4edbbea700-AP;ft=47016

Via: SIP/2.0/TCP 10.14.251.55:5063;branch=z9hG4bK8062ccd02821e21b97f4edbbea700

Record-Route: <sip:604083d1@10.14.251.54;transport=tcp;lr>

Record-Route: <sip:10.14.251.53:15060;lr;sap=-1650612390*1*016asm-callprocessing.sar888868362~1351024416281~-1329103579~1;transport=tcp>

Record-Route: <sip:604083d1@10.14", 4,
10/23/12 15:33:36, "Call Management", 21048, "Information", 25733, "TXDA1SVA2", "SIP IN :pRACK sip:10.0.0.104:5060;transport=tcp SIP/2.0

From: sip:18049656501@heart.org;tag=8062ccd02821e21b77f4edbbea700

To: sip:sipmm@heart.org;tag=e3178656596cbe4d

Call-ID: 8062ccd02821e21b87f4edbbea700

CSeq: 2 PRACK

Via: SIP/2.0/TCP 10.14.251.54;branch=z9hG4bK0A0EFB3578088880051039011-AP;ft=46816

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880051039011

Via: SIP/2.0/TCP 10.14.251.53:15070;branch=z9hG4bK0A0EFB3578088880151039009

Via: SIP/2.0/TCP 10.14.251.54:5063;branch=z9hG4bK8062ccd02821e21ba7f4edbbea700-AP;ft=47016

Via: SIP/2.0/TCP 10.14.251.55:5063;branch=z9hG4bK8062ccd02821e21ba7f4edbbea700

User-Agent: Avaya CM/R015x.02.1.016.4 AVAYA-SM-6.0.2.0.602004

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
I am trying to figure out how to make this happen but so far I'm still looking. I understand what you are getting at but this messaging system is still so new to me I haven't had much of a chance to learn how it works. As soon as I can make this happen I will post the results. Looking at your trace though is quite confusing...I'm not sure I would even notice where it is failing unless it actually says it has failed. Thanks for your help Ken, I'll get back with you as soon as I can.
 
In the vmc under pbx is a tab for sip you Joliet the ip of the pbx and hit the icon that looks like a drum on the top left and pick how long you want it to stay on



Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Okay...I got that going but now where will I find the data?
 
Alrighty then...finally figured out where and how to get this information. I am attaching the trace for one of the extensions that is having a problem. Hope this can tell you what is going wrong because I couldn't see anything. Of course I am not surprised by that as this is beyond my programming level! Thanks again Ken.

", 2, , ""
10/25/12 12:07:25, "Call Management", 21012, "Information", 0, "VIHTI", "Cleared DTMF buffer.", 2, , ""
10/25/12 12:07:25, "PBX Integration", 21409, "Information", 0, "VIHTI", "Integration data: Extension . Called extension 4031. Calling extension 6169754800. Call divert 2.", 0, , ""
10/25/12 12:07:26, "TUI", 21203, "Information", 848, "VIHTI", "Incoming call due to a ring no answer condition for extension 4031.", 2, , ""
10/25/12 12:07:26, "TUI", 21217, "Information", 848, "VIHTI", "Caller has requested to leave a message for mailbox 4031 after a ring no answer condition.", 2, 4031, ""
10/25/12 12:07:29, "TUI", 21048, "Information", 848, "VIHTI", "SIP IN :BYE sip:192.168.67.11:5060;transport=tcp SIP/2.0

From: sip:6169754800@sip.local;tag=8066425d8a22e21ab92503e4ea00

To: "4799" <sip:4574799@sip.local>;tag=adbe9e7e4ffad34c

Call-ID: 8066425d8a22e21ac92503e4ea00

CSeq: 3 BYE

Max-Forwards: 70

Via: SIP/2.0/TCP 192.168.67.6;branch=z9hG4bK80c0a45f8a22e21b092503e4ea00

User-Agent: Avaya CM/R015x.02.1.016.4

Content-Length: 0



", 2, , ""
10/25/12 12:07:29, "TUI", 21048, "Information", 848, "VIHTI", "SIP OUT :SIP/2.0 200 OK

Via: SIP/2.0/TCP 192.168.67.6;branch=z9hG4bK80c0a45f8a22e21b092503e4ea00

From: sip:6169754800@sip.local;tag=8066425d8a22e21ab92503e4ea00

To: "4799" <sip:4574799@sip.local>;tag=adbe9e7e4ffad34c

Call-ID: 8066425d8a22e21ac92503e4ea00

CSeq: 3 BYE

Server: Modular Messaging

Content-Length: 0



", 2, , ""
10/25/12 12:07:29, "TUI", 21330, "Information", 848, "VIHTI", "Greeting played", 2, 4031, ""
10/25/12 12:07:30, "TUI", 21048, "Information", 846, "VIHTI", "SIP IN :BYE sip:192.168.67.11:5060;transport=tcp SIP/2.0

From: sip:6169132006@sip.local;tag=802ea6408a22e21a092503e4ea00

To: "4799" <sip:4574799@sip.local>;tag=64109d7cfdea14fa

Call-ID: 802ea6408a22e21a192503e4ea00

CSeq: 3 BYE

Max-Forwards: 70

Via: SIP/2.0/TCP 192.168.67.6;branch=z9hG4bK0c0a45f8a22e21b192503e4ea00

User-Agent: Avaya CM/R015x.02.1.016.4

Content-Length: 0



", 1, , ""
10/25/12 12:07:30, "TUI", 21048, "Information", 846, "VIHTI", "SIP OUT :SIP/2.0 200 OK

Via: SIP/2.0/TCP 192.168.67.6;branch=z9hG4bK0c0a45f8a22e21b192503e4ea00

From: sip:6169132006@sip.local;tag=802ea6408a22e21a092503e4ea00

To: "4799" <sip:4574799@sip.local>;tag=64109d7cfdea14fa

Call-ID: 802ea6408a22e21a192503e4ea00

CSeq: 3 BYE

Server: Modular Messaging

Content-Length: 0



", 1, , ""
10/25/12 12:07:30, "TUI", 21245, "Information", 846, "VIHTI", "Recording ended. Message length was 31 seconds.", 1, 4812, ""
10/25/12 12:07:30, "Call Management", 21012, "Information", 0, "VIHTI", "Cleared DTMF buffer.", 1, , ""
10/25/12 12:07:30, "Call Management", 21008, "Information", 0, "VIHTI", "Channel on hook.", 2, , ""
10/25/12 12:07:30, "Call Management", 21044, "Information", 0, "VIHTI", "Timed out while waiting for DMTF events.", 2, , ""
10/25/12 12:07:30, "TUI", 21342, "Information", 848, "VIHTI", "Statement 4 was interrupted by a hangup", 2, 4031, ""
10/25/12 12:07:30, "Call Management", 21024, "Information", 848, "VIHTI", "ReleaseCall() was requested.", 2, , ""
10/25/12 12:07:30, "TUI", 21235, "Information", 848, "VIHTI", "Hang up was aborted.", 2, 4031, ""
10/25/12 12:07:30, "Call Management", 21022, "Information", 0, "VIHTI", "WaitForCall() was requested.", 0, , ""
10/25/12 12:07:31, "Call Management", 21008, "Information", 0, "VIHTI", "Channel on hook.", 1, ,
 
Are you using SES, Session Manager or Direct SIP to CM?

If you are doing direct SIP to CM make sure this configuration guide is followed - CN 88012
It looks like you are using TCP, but are you using SRTP?

It looks like MM is hanging up because it received a BYE SIP message from whatever MM is integrated with. MM is probably getting a BYE either because the inbound call disconnected from the PBX or whatever MM is integrated with didn't get a ACK SIP messages from MM saying it is accepting the call.

If you put that trace along side a similar call where that doesn't happen, is there anything out of place? I can't see this happening to only a few numbers while it works for other similar numbers. Unless they are coming in a different trunk, or some other path that the good calls don't follow. Like other network regions or something else that either requires transcoding or doesn't have a common codec in which to talk to MM with.

What SP level is your MM running?
 
Thank you for responding. We are at MM 5.2 SP12. It is a direct connection to CM, no SES involved. I have 2 other 800 numbers that also come in on this trunk but they route through a call center and I don't know if they ever reach a vm box. I do know the callers to those numbers would be quick to complain if it wasn't working properly so I have to assume that everything is routing fine with them. The rest of my 800's route over a different trunk, the trunk they are supposed to come in on. I am at a total loss as to why these numbers route to the wrong trunk when everyone involved assures me that routing is exactly the same as the others. And we are not using SRTP. I'm hoping you can provide some direction because everyone I've talked to is stumped. Thanks again.
 
So this call comes in on a T1 to CM? Is 4799 or 4574799 the extension/mailbox MM is supposed to be answering with?
 
i assume that the IP below is your PBX right ?



"SIP IN :BYE sip:192.168.67.11:5060;transport=tcp SIP/2.0

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Yes 4799 is the extension for MM.
No, that IP address is the server for the MAS.
 
why is there a 4574799? Is that your routing digits? It appears to be a direct call versus a diverted call. What is the number that should be going to MM to integrate into a MM mailbox?
 
The number that actually is called is 306-457-4799 although the SIP trace doesn't reflect that a simple extension trace shows all the number being used. The 306 drops and then the 457-4799 is routed through aar which strips off the first 3 digits and sends 4799, the number of the MM mailbox.
 
Yes you inbound looks a bit odd as it is a number and not a name. As Texeric asked what is the 4574799 ? the 7 digit hunt number? and then you are deleting the first 3 ?



From: sip:18049656501@heart.org;tag=8062ccd02821e21b77f4edbbea700

To: sip:sipmm@hxxx.org


From: sip:6169754800@sip.local;tag=8066425d8a22e21ab92503e4ea00

To: "4799" <sip:4574799@sip.local>;tag=adbe9e7e4ffad34c

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
That is apparently what is happening. I tested this from a working number and a non-working number and they send the same digits.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top