CUCM sip redunduncy

[Bekzod Fakhriddinov]

HI guys. There are 2 cubes to 2 isp connected with sip trunks to CUCM. CUBEs have Out-of-dialog SIP OPTIONS Ping enabled on all dial-peers.  If cube did  busyout outgoing dial peer will it send this info to CUCM so CUCM will use backup sip trunk (on CUCM backup  is on RL level)?

thank you 

[Slavik Bialik]

No, not according to my knowledge. What will happen is that when you're trying to make an outbound call to your first preference (first CUBE), and this CUBE has lost his SIP connection with ITSP, the CUBE will give back the CUCM some 4XX/5XX message error, and according to this error, the CUCM will know to go and try his second preference in the route list, which will be the second CUBE. The CUBE cannot pass back that his connection with the ISP is down, so the CUCM will know to ignore it.

[Bekzod Fakhriddinov]

do u mean CUBE will send 503 message to CUCM "dest unreachable" ? But this should be enough for CUCM to select another sip trunk from route list . 

[Adam Pawlowski]

I am interested to know myself - I know some of the messaging is configurable from the CUBE, as well the route/stop route action taken by the UCM depending on the response it gets.

In my experience CUBE doesn't necessarily know that the destination that you want to reach is unreachable - if the peer is down and it has nothing else to route with it may simply respond with a 404 that it doesn't know what to do with your call, rather than a 503 saying that the CUBE itself is not able to service the call. I'd love to know.

[Slavik Bialik]

Hi @Adam Pawlowski,

In CUBE you can apply few configurations to make it work better. I always use 2 things in my configurations:

• voice class server-group - You can configure all your ITSP / CUCMs IP address with a preference, and configure ONLY one dial-peer that directs to the relevant server-group. That helps you to simplify your configurations, and you don't need to configure X dial-peers per CUCM / ITSP node.
• voice class sip-options-keepalive - Using this will allow the dial-peer to send SIP OPTIONS to all the destinations configured under the server-group profile. So if a ITSP node is down and it is preference 1, it'll know for the next time and try the second preference. When the first node is up, and after it'll get its SIP OPTIONS it'll detect it as up and will automatically let the calls go through this node.

Here's a combined example of using the both methods:

voice class server-group 1
 ipv4 <PSTN-SIP-1-IP-ADDRESS> preference 1
 ipv4 <PSTN-SIP-2-IP-ADDRESS> preference 2
 description PSTN

voice class sip-options-keepalive 1
 description SIP OPTIONS to PSTN SIP Servers
 retry 2
 transport udp

dial-peer voice 1000 voip
 description OUTBOUND dial-peer to PSTN
 session protocol sipv2
 session transport udp
 session server-group 1
 destination e164-pattern-map 1000
 voice-class codec 1  
 voice-class sip options-keepalive profile 2
 voice-class sip bind control source-interface GigabitEthernet0/1
 voice-class sip bind media source-interface GigabitEthernet0/1
 dtmf-relay rtp-nte sip-notify
 no vad

[Slavik Bialik · Accepted solution]

Hi @Bekzod Fakhriddinov,

Exactly, this is enough for the CUCM to know to try the second route route in the route group / route list.

But of course, if you know you'll have a long downtime you can always go and change the priority of the working CUBE (the one with the working connection to the ITSP) to be the first one, and after the ITSP will be working again you can change it back. That way you won't have to go the current CUBE all the time, and avoid the re-routes.