cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

344
Views
0
Helpful
4
Replies
Beginner

Routing logic on CUCM route list

If we have two active SIP trunk configured and we decided to add that in Route group/Route list, if one of the ISP link is down in one router(sip) how does CUCM make decision on routing the call to second Router- Although SIP trunk is up from CUCM to Router.

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Contributor

Re: Routing logic on CUCM route list

I have no idea why you're talking about dial peers.

 

If you build a route list that contains two trunks, say to two separate border elements, and assuming the trunk is up but the far end item can't process the call, the UCM will use the next item in the route list based on the signaling received from whatever is at the other end, and a parameter that tells the UCM to either continue hunting or not depending on cause. I believe there are two CallManager service parameters for stop routing on busy, or unallocated. There should also be timeouts in the SIP profile which could mark the transaction failed. 

 

You could have two TDM gateways or CUBE or whatever and stack them in this manner for resiliency. The concept of overflow would depend on the signaling and how the UCM is set to handle it. And, as well, if you're trying to consider how that far end device is going to play along in this scenario, it also depends what is happening or what it does. If you are using a SIP trunk out from there, let's say, and the carrier is going to intercept the call or do something weird when you hit a capacity limit, you may have to figure out how to "translate" that into something that causes routing to proceed via the UCM rather than being terminated by that device.

4 REPLIES 4
Beginner

Re: Routing logic on CUCM route list

Hi,

 

You should have option ping enabled on cucm for the trunks as well as on the dial-peers.

if one dial-peer fails it should route it through another dial-peer.

if trunk between cucm and gateway fails depending on which layer it will mark the trunk down and route it through next trunk.

 

Regards,

Adarsh Chauhan

Please mark helpful or correct

Contributor

Re: Routing logic on CUCM route list

I have no idea why you're talking about dial peers.

 

If you build a route list that contains two trunks, say to two separate border elements, and assuming the trunk is up but the far end item can't process the call, the UCM will use the next item in the route list based on the signaling received from whatever is at the other end, and a parameter that tells the UCM to either continue hunting or not depending on cause. I believe there are two CallManager service parameters for stop routing on busy, or unallocated. There should also be timeouts in the SIP profile which could mark the transaction failed. 

 

You could have two TDM gateways or CUBE or whatever and stack them in this manner for resiliency. The concept of overflow would depend on the signaling and how the UCM is set to handle it. And, as well, if you're trying to consider how that far end device is going to play along in this scenario, it also depends what is happening or what it does. If you are using a SIP trunk out from there, let's say, and the carrier is going to intercept the call or do something weird when you hit a capacity limit, you may have to figure out how to "translate" that into something that causes routing to proceed via the UCM rather than being terminated by that device.

Highlighted
Beginner

Re: Routing logic on CUCM route list

Can you pls help with more specific details about the service parameter that need to set so that the UCM identifies that routing is unavailable and move to second trunk in RL?

Contributor

Re: Routing logic on CUCM route list

See below, from System -> Service Parameters -> CallManager

These are the parameters available, the last one is advanced, and I don't know if that applies to "mapped" SIP cause codes nor which ones you would or wouldn't want here. 

 

These are the defaults and this works for us for resiliency as long as the gateway signals back appropriately when it cannot route the call.

 

routing_params.PNG

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards