CUCM 7.1.3 Outbound calls to Multiple Gateways using Route List / Route Group

[dtran]

Hi all,

I am running CUCM 7.1.3 and I am using Route List and Route Group to route outbound calls to multiple gateways in case if one gateway fails, calls will get routed to the other gateway. But for some reason it didn't seem to work for me today where two of the PRI's on one of the gateways fail and outbound calls did not failover to the other gateway in the Route List. Has anyone seen this issue ?

In this Route List I have two Route Groups and each Route Group contains a gateway and the gateways are H.323 gateways. My thinking is that if the PRI circuits are down on one gateway calls will get routed to the next gateway in the Route List. Is that correct ?

Thanks all in advance !! I appreciate any inputs / suggestions !!!

Danny

[William Bell · Accepted solution]

Danny,

On your H323 gateway, can you check to see if you have the following command (global config):

no dial-peer outbound status-check pots

By default, this feature is enabled. When enabled, the H323 gateway will check the status of a dial-peer to see if the dial-peer is active or not. If the dial-peer is active, the gateway attempts to seize a trunk on the associated port. If the dial-peer is inactive the gateway will choose the next available dial-peer with a match. If all dial-peers are inactive (as is the case in your example) the gateway will disconnect the call with cause code 1 (Unallocated/unassigned).

Now, at first glance you may think that dial-peer status checking is exactly what you want. However, the way the gateway handles a call when there is no matching egress dial-peers is the problem. There are actually two remedies.

The one that a lot of people pursue is a Call manager service parameter named "Stop routing on Unallocated Number Flag". By default this is true. Some people opt to set it to false. One of the effects of setting this to "false" is that when the CUCM receives the Unallocated/Unassigned disconnect cause code from your gateway it will hunt to the next gateway in the RG or RG in the RL. However, another side effect is that CUCM will keep trying to route the call when the Unallocated/Unassigned disconnect cause code is a legit state from a remote system. Basically, it is a suboptimal solution and I recommend against going this path. At least for your scenario.

The second approach is disable the status-checking for outbound pots at the gateway level: no dial-peer outbound status-check pots. What this does is that the egress dial-peer is matched even when it is inactive. An attempt to use the dial-peer elicits a disconnect cause code of "No channel available". Which is actually a more correct statement of what is happening. When CUCM receives this cause code, it will keep routing (next GW in RG or next RG in RL). 

HTH.

-Bill (@ucguerrilla)

[dtran]

Hello William !! Thank you very much for thorough response !! very much appreciate it !!

no, I do not have the command "no dial-peer outbound status-check pots" in the gateway config. I went ahead added it to the config. I'll let you know how it goes. 

I can only use one or the other option right ? can't do both ? 

Thanks again !!

Danny

[William Bell]

Danny,

It isn't as absolute as that. These options are parameters on different systems in your solution. You can tweak the parameters independently of each other. Strictly speaking, they don't interact with each other. IOW, it isn't like call preservation on H323 gateways where there is a UCM-side config and a GW-side config working together to create an experience.

That said, in the context of your SPECIFIC question, I would choose one or the other. Now, down the road you may have another requirement that steers you to tweak the parameters behind the options presented by me. At that time, you have to re-evaluate your design, determine impact, adjust, execute, etc..

HTH.

-Bill (@ucguerrilla)

[dtran]

Thanks Bill !! very much appreciate your help !!

Danny