Solved: SIP trunk to ITSP SIP Circuit cause code 102 International calls

asherif82 · ‎08-25-2015

Hi,

We have that scenario where we are trying to call back from CWMS to mobile number however I receive a 102 timer expiry. The call rings the mobile but when answer it stays for 2-5 seconds and then disconnect and automatically dial again and then disconnected.

The topology is as follow:

CUCM-->SIP Trunk(w/early offer)-->CUBE-->ISP

When dialing from Normal IP Phones or Jabber directly calls are working for local,mobile and national, however when trying to call back from cwms on mobile we experience the above behavior...

Attached is the configuration and the debug ccsip message.

Vivek Batra · ‎08-25-2015

I doubt on SIP bind interface.

Seems incoming call from CUCM is hitting dial-peer 34 which is bind with Gig 0/0/0.1186 however CUBE is getting INVITE on other interface viz 10.165.144.2 (port-channel 5.75).

Since dial-peer is bind with Gig 0/0/0.1186, 183 Session Progress from CUBE to CUCM is using this interface and may be that is the reason there is no response from CUCM, however I assume that you would like to use port-channel 5.75 interface for the packets from CUBE to CUCM.

Please correct the configuration and share the results.

Thanks

Vivek

View solution in original post

Vivek Batra · ‎08-25-2015

I doubt on SIP bind interface.

Seems incoming call from CUCM is hitting dial-peer 34 which is bind with Gig 0/0/0.1186 however CUBE is getting INVITE on other interface viz 10.165.144.2 (port-channel 5.75).

Since dial-peer is bind with Gig 0/0/0.1186, 183 Session Progress from CUBE to CUCM is using this interface and may be that is the reason there is no response from CUCM, however I assume that you would like to use port-channel 5.75 interface for the packets from CUBE to CUCM.

Please correct the configuration and share the results.

Thanks

Vivek

asherif82 · ‎08-26-2015

Hi Vivek,

Thanks for your comment.

Actually, I'm using interface port-channel 5.75 for communication between CUBE and UCM as this is considered the internal interface between UCM SIP trunk and CUBE. You can see that in dial-peer 4 & 5.

So is this what you mean? or Should I change dial-peer 34 to be using port-channel 5.75?.

Please advise.

Vivek Batra · ‎08-26-2015

Can you please check and let me know which inbound and outbound dial-peer is hitting for the call (logs you shared before)?

Vivek Batra · ‎08-27-2015

Hi,

Could you check which dial-peers are being matched in inbound and outbound direction?

asherif82 · ‎08-29-2015

The call flow from Unified CM to SIP ISP is suppose to be:

UCM-->Dial-peer 4 (port-channel 5.75)-->Dial-peer 34(GigabitEthernet0/0/0.1186)--->ISP

But after your comment, I noticed that the inbound dial-peer is 10 which make the call flow as this:

UCM-->Dial-peer 10 (GigabitEthernet0/0/0.1186)-->Dial-peer 34(GigabitEthernet0/0/0.1186)--->ISP

So, That's why I think PRACK is not being sent properly. I figured out that the problem is the matching Destination-pattern as Caller ID is being matched on dial-peer 10 instead of 4 ,thereby, after adding a new dial-peer to be matched on the caller id and binded with port-channel 5.75, PRACK is being sent and call is okay :).

Vivek Batra · ‎08-29-2015

Glad to see you get it fixed.