Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

Route group in Callmanager

Hi,

I have 2 H323 gateways in a Route Group. Each gateway has an ISDN connection to a remote office.

When the ISDN connection goes down in the primary gateway the callmanager(4.1.3) won't send the call to the secondary gateway (because the gateway is still alive).

I know that if the primary gateway goes down, the CCM will send the calls to the secondary gateway in the route group.

But is there a way to let know the callmanager know when the controller goes down?

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Green

Re: Route group in Callmanager

Hola Ernie,

The default behavior in IOS, when there are no valid POTS dial-peers for a call to go out of, is to return “unallocated number” as a cause code to CCM. This can happen even if a t1 goes down. When the T1 goes down, the POTS peer is marked as down, and when CCM sends a call to the gateway, it'll return a UAN cause code to the ccm, causing CCM (by default) to stop hunting for other available gateways. There are ways to change the behavior using service parameters in CCM as explained above, but this behavior don't make sense to me, so we looked for other ways to do it in 1 case.

It turns out that you can issue the global command "no dial-peer outbound status-check pots" on the IOS GW, if you're opposed to changing the CCM behavior. What this command will do is cause the dial-peer to stay up. IOS will try and route the call, and when the T1 is down, it returns "No circuit available" to CCM. When CCM receives this cause code, it knows there's been a non-user error, and continues hunting, achieving the desired behavior.

3 REPLIES

Re: Route group in Callmanager

When the system initially presents a call to a member of a route list, Cisco Unified CallManager reroutes for all cause codes other than Out of Bandwidth, User Busy, and Unallocated Number.

I suspect that in this particular instance, that gateway is returning unallocated number flag, consequently rerouting does not continue despite a second RG existing in the RL.

The values of the associated service parameters for the Cisco CallManager service which determines the rerouting decision for those cause codes are either true or false.

The Clusterwide Parameters (Route Plan) grouping includes the Stop Routing on Out of Bandwidth Flag, Stop Routing on User Busy Flag, and Stop Routing on Unallocated Number Flag service parameters. You can set each service parameter to True or False.

Have you tried changing the 'stop re-routing on unallocated number flag' to false, by default it is set to true.

Regards

Allan.

New Member

Re: Route group in Callmanager

Hi,

maybe rather than having both your gateways in single route group, try to put them in two route groups, then assign both route groups into single route list, then route your calls to the route list. then CM will try to route call to each route group in the route list in the order you set till success, to achieve gateway redundancy.

hope this works for you :)

Green

Re: Route group in Callmanager

Hola Ernie,

The default behavior in IOS, when there are no valid POTS dial-peers for a call to go out of, is to return “unallocated number” as a cause code to CCM. This can happen even if a t1 goes down. When the T1 goes down, the POTS peer is marked as down, and when CCM sends a call to the gateway, it'll return a UAN cause code to the ccm, causing CCM (by default) to stop hunting for other available gateways. There are ways to change the behavior using service parameters in CCM as explained above, but this behavior don't make sense to me, so we looked for other ways to do it in 1 case.

It turns out that you can issue the global command "no dial-peer outbound status-check pots" on the IOS GW, if you're opposed to changing the CCM behavior. What this command will do is cause the dial-peer to stay up. IOS will try and route the call, and when the T1 is down, it returns "No circuit available" to CCM. When CCM receives this cause code, it knows there's been a non-user error, and continues hunting, achieving the desired behavior.

530
Views
5
Helpful
3
Replies
CreatePlease to create content