CUCM SIP trunk call routing

[Prasad Paradkar]

Hi,

We have an issue where we are routing a call through CUCM cluster --> CUBE 1 and cube 2 in a round robin fashion--> which sends the call to Trunk towads ESBC of ISP.

Now the issue is when the CUBE 2 link towards ESBC fails, can CUCM able to detect this early as he needs to wait for 32sec to understand the link towads Cube 2 is down and send the call to Cube 1 again.

cucme Cluster --> cube 1 --> ESBC

                        --> cube 2 --> 

[Prasad Paradkar]

please find the network diagram below and need to knwo that the CUCM can provide the redundency for the red (wan link) link.

We have CUCM sending calls in round robin manner to the cube 1 and cube 2 , if cube 2 goes down what we can do in a quick switchover as user is not holding the cal ltill the cube respond with the WAN link down.

[Prasad Paradkar]

[Alok Jaiswal]

Hi Prasad,

I believe you are referring to the link between CUBE 2 to ESBC and not between CUCM and CUBE 2, correct ?

My question is does the CUBE 1 and CUBE 2 sends call towards same ESBC ? Because if the link between CUBE 2 and ESBC is down it means its down for CUBE 1 as well, isn't it ?

Any ways, I think the issue is because of SIP UDP timeout, and CUBE tries for 6 times before  CUCM tries to send to CUBE 1.

You can configure the maximum retries in the sip-ua configuration, so that CUBE doesn't tries for 30 seconds before declaring it can't handle the call.

Router(config-sip-ua)# retry {invitenumber | response number | bye number | cancel number}

Please note that the timer actually starts with value of 0 and then goes on increasing for e.g. 0, 500, 1500, 3500 and so forth till 31500 msec. You can read about SIP UDP timeout in the rfc 3261.

http://www.ietf.org/rfc/rfc3261.txt 

I think other way is if you configure the session transport as tcp under dial-peer.

Router(config-dial-peer)# session transport{udp | tcp}

Regards,

Alok

[Prasad Paradkar]

we have already configured the SIP-ua retry at 2.

after options ping activation on dial peer the issue is resolve.

Just want to know what we can do from the call manager side to overcome this issue.

[Alok Jaiswal]

Call Manager can't track the CUBE interfaces. So consider this scenario, that you have options ping enable which kind of a periodic keep alive. 

So when the CUCM sends the call to CUBE, if the trunk is already down but the timer hasn't been reached to initiate another option's PING, in this case CUBE will try to reach SBC. 

But if you keep session transport as TCP (provided the provider also support that), it will detect the trunk down immediately and notify the CUCM, and then CUCM can route the call to second CUBE. 

Assuming that both CUBE are sending call to different SBC :)

Regards,

Alok

[Jaime Valencia · Accepted solution]

Ask your telco if they support options ping, and if they do, configure it on the outbound dial peers.

But as Alok mentions, it's not clear if both CUBEs are sending calls to the same ISP, or not. If it's the same, then both would be down. Does this have HSRP??

[Prasad Paradkar]

Hi Jaime,

We have configured the options ping on the dial-peer towards the SBC to resolve the issue.

I just want to know what we can do from CUCM side other than SIP trunk options ping to overcome the issue.

Thanks for the help.