08-25-2015 02:13 AM - edited 03-18-2019 11:36 AM
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.
Solved! Go to Solution.
08-25-2015 06:56 AM
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
08-25-2015 06:56 AM
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
08-26-2015 01:21 AM
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.
08-26-2015 02:13 AM
Can you please check and let me know which inbound and outbound dial-peer is hitting for the call (logs you shared before)?
08-27-2015 05:09 AM
Hi,
Could you check which dial-peers are being matched in inbound and outbound direction?
08-29-2015 11:18 PM
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 :).
08-29-2015 11:53 PM
Glad to see you get it fixed.
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