cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
927
Views
25
Helpful
11
Replies

Call Failure over PRI from PBX to ISR Router

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.

 

  • The failure seems to happen at the ISR router
    • Call is received via the PRI and matches incoming POTS dial peer (914).
    • Called Number = 18593962666
    • A translation pattern is invoked and the called number is prepended with steering digits of 91+10 digits or 918593962666.
    • The called number matches the outbound SIP dial peers 911(primary) and 912 (secondary).
    • SIP Dial peer 911& 912 point to CUBEs
    • No invites or SIP messages are generated on the ISR Router and none are received at either CUBE.
    • Router Version = 15.2(4)M6
    • Show run and debugs from ISR router attached

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

 

11 Replies 11

George Thomas
Level 10
Level 10

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.

Please rate useful posts.

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

Will you be able to post the CUBE configs?

Please rate useful posts.

Attached

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)

Please rate useful posts.

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'.

 

 

Options ping is for SIP dial-peers,not necessarily  POTS. Can you make a call with ccsip all turned on? 

Please rate useful posts.

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

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.
 

Please rate all useful posts

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.

Please rate useful posts.

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