03-14-2017 09:38 PM - edited 03-17-2019 09:48 AM
Hello
Cisco 2921 use as voice gateway. Call flow from pstn E1 to 2921 then sip trunk to CUCM.
I have this config
voice translation-profile IngressCall
translate calling 15
translate called 10
voice translation-rule 10
rule 10 /^\(2222[67]..\)$/ /+7846\1/
!
voice translation-rule 15
rule 10 /^\(..........\)$/ /+7\1/
dial-peer voice 1000 pots
description *** Inbound DP Default ***
incoming called-number .
dial-peer voice 8601 voip
description *** Outbound DP for PSTN->CUCM ***
translation-profile outgoing IngressCall
preference 1
destination-pattern 2222[67]..$
session protocol sipv2
session target ipv4:10.214.104.121
dtmf-relay cisco-rtp rtp-nte
codec g711ulaw
no vad
!
dial-peer voice 8602 voip
description *** Outbound DP for PSTN->CUCM ***
translation-profile outgoing IngressCall
preference 2
destination-pattern 2222[67]..$
session protocol sipv2
session target ipv4:10.214.104.122
dtmf-relay cisco-rtp rtp-nte
codec g711ulaw
no vad
translation-profile IngressCall used for globalize number e164.
When first CUCM node down, call drop and never go to second node.
Can anyone advise why?
Debug output in attachment (call placed from pstn Calling Number=9063333333, Called Number=2222648):
debug voip dial peer all
debug ccsip messages
debug voip ccapi
Solved! Go to Solution.
03-15-2017 03:28 AM
Vladisav
A couple of things
1.Adjust sip timers on your CUBE
Before we go further, please adjust the default SIP timers on the gateway since you are using UDP as your transport porotocol.
From the logs we can see that the gateway is attempting to connect to the primary and by default it will attempt 6 INVITES
conf t
sip-ua
retry invite 2
timers trying 150
2. Configure options PING on both dial-peers so CUBE will know when CUCM is down and it should not send an INVITE at all to that server. Then test again
dial-peer voice 8601 voip
voice-class sip options-keepalive up-interval 30 down-interval 10 retry 3
dial-peer voice 8602 voip
voice-class sip options-keepalive up-interval 30 down-interval 10 retry 3
3. Ensure that Options Ping is also enabled on CUCM side on the SIP profile assigned to the SIP trunk
03-14-2017 11:21 PM
Hi Vladislav,
Couple of things you can check:
>> Are both these servers part of the Callmanager group assigned on SIP trunk on cucm and in same order as the dial-peer preference?
>> If you shut down dial-peer 8601 instead of shutting down server 10.214.104.121, does the dial-peer 8602 take over successfully?
HTH
Manish
03-14-2017 11:49 PM
not sure understand
>> Are both these servers part of the Callmanager group assigned on SIP trunk on cucm and in same order as the dial-peer preference?
I have one cluster with two server. I cant see config what group assigned on SIP trunk? Where to find it? And what is order? CM group screen in attachment
This is production system, I can test shutdown dial-peer later
03-14-2017 11:58 PM
Hi Vladislav,
This Callmanager group should be assigned to the device pool that you have assigned to the SIP trunk that is pointing to the gateway. The order looks correct here if this CM group is used by the device pool of SIP trunk.
HTH
Manish
03-15-2017 12:13 AM
Yes this cm group used by device pool of this SIP trunk. (I have only one cm group)
03-15-2017 12:32 AM
Check if ccm service is running on the backup server, check the database replication and when you test the dial-peers during some maintenance you can try resetting the SIP trunk as well.
Manish
- Do rate helpful posts -
03-15-2017 12:56 AM
"All servers have a good replication status."
"Cisco CallManager Started Activated" on both servers.
I will try reset. But I think it does not matter.
I was upgrade cucm 10.5 to 11.5 about 5 days ago with some rebooting. And behavior is same on both 10.5 and 11.5.
I suppose problem not on CUCM side. As seen in debug 2921 not send INVITE to second node at all.
03-15-2017 03:28 AM
Vladisav
A couple of things
1.Adjust sip timers on your CUBE
Before we go further, please adjust the default SIP timers on the gateway since you are using UDP as your transport porotocol.
From the logs we can see that the gateway is attempting to connect to the primary and by default it will attempt 6 INVITES
conf t
sip-ua
retry invite 2
timers trying 150
2. Configure options PING on both dial-peers so CUBE will know when CUCM is down and it should not send an INVITE at all to that server. Then test again
dial-peer voice 8601 voip
voice-class sip options-keepalive up-interval 30 down-interval 10 retry 3
dial-peer voice 8602 voip
voice-class sip options-keepalive up-interval 30 down-interval 10 retry 3
3. Ensure that Options Ping is also enabled on CUCM side on the SIP profile assigned to the SIP trunk
03-15-2017 10:18 PM
Thanks. After Adjust timers call successfuly was connected to second node.
05-04-2018 03:53 AM
This is really useful,
In my case unfortunatelly I have noticed that when I enable the Options Ping on CUCM side on the SIP profile the SIP trunk drops and the call is not applicable.
CUCMv11 - SIP trunk- CUBE (ISR4331/K9)
Am I missing something?
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