01-20-2015 10:43 AM - edited 03-17-2019 01:39 AM
I am experiencing call failures on outbound calls from the PBX with the following setup that I'm hoping someone may be able to help me with.
Mitel 5000 PBX ==(pri)==>ISR Router ==(sip)==>CUBE==(sip)==>PSTN.
TAC seems somewhat baffled along with me. I'm open to suggestions at this point If anyone has thoughts or ideas.
Thanks in advance for any and all assistance,
Robert
01-20-2015 12:12 PM
Looks like the outbound call leg to CUBE is matching dial-peer 912 which has a session target of 192.168.205.x. What I dont see is a default route or a routing protocol to tell the router where to go to get to 192.168.205.x? You will have to put a default route at the least telling the router what the next hop is.
01-20-2015 12:23 PM
George,
Thanks for the reply. I cut out some of the router configuration for customer privacy, but I have confirmed I have connectivity between the ISR router and CUBEs. I am able to successfully PING between all elements in the desigm
Additionally, I am told there are no firewalls separating the two devices.
Thank You,
Robert
01-20-2015 12:25 PM
Will you be able to post the CUBE configs?
01-20-2015 01:01 PM
01-20-2015 01:06 PM
Config looks ok. Can you run debug ccsip all and post output? Could you try turning on the options ping on the 912 dial and issue 'show dial peer voice summary' and see if it is active? (voice-class sip options-keepalive)
01-20-2015 01:51 PM
I added the command 'voice-class sip keepalive' to dial peers 911 & 912 in the ISR router and turned on 'debug ccsip all'. Output attached.
The 'Show dial-peer voice active' command show dial peers 911 & 912 as Up and the Keepalive state as 'active' Interestingly, though dial peer 914 shows as 'Down'.
01-20-2015 01:54 PM
Options ping is for SIP dial-peers,not necessarily POTS. Can you make a call with ccsip all turned on?
01-20-2015 02:08 PM
George,
I appreciate all your assistance. Unfortunately, I cannot generate a call remotely for the customer and my contacts have left for the evening.
I will contact someone first thing in the morning, get a test call made, and post the debug results.
Thanks again for all your help!
-Robert
01-20-2015 04:30 PM
George great support so far (+5)
Hi Robert
debug ccsip all is very intensive so you should do the following before enabling the debug
service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit
Then..
<Enable debugs, then test again.>
debug ccsip all
<Enable session capture to txt file in terminal program.> (such as Putty)
then do the ff:
terminal length 0
show logging
++++
What is even more strange is that the call appears to be disconnected from the far end. From the logs below the outbound call leg (45) is where the disconnect is coming from and the "cc_api_call_disconnected" shows this call leg talking to CCAPI..
001858: *Jan 20 13:18:19.102: //45/8B56ECEE8011/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x3CE6D670, Call Id=45
001859: *Jan 20 13:18:19.102: //45/8B56ECEE8011/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
Can you also send a debug voip ccapi onout from the CUBE. we need to check if the call arrives there, though we don't see any INVITE request sent out.
01-20-2015 04:34 PM
I agree with Ayodeji on the intensity of debug ccsip all however since we dont see INVITE messages go out, debug ccsip messages wont give us the reason but debug ccsip all should.
01-21-2015 08:03 AM
I wanted to provide an update. I think I was able to resolve the issue.
When I ran the Debug CCSIP All trace, I noticed the ISR router was advertising all codecs for tx and rx. Once I saw that, it clicked that I had set the Voice-Class codec applied to the dial peers in the ISR router as Transparent which is the same configuration I used in the CUBES. I think the call was failing because neither end of the call was advertising a codec. Once I set the codec options on the ISR end of the call to G729r8 & g711ulaw, calls started working as expected.
Thanks Again,
Robert
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide