[cisco-voip] Another Gatekeeper Question
Andrew Dignan
andy at dignans.com
Sat May 28 12:35:22 EDT 2005
Fixed the issue with a service parameter change:
****************************************************************
CCM Service Parameter
Stop Routing on Unallocated Number Flag
This parameter determines routing behavior for intercluster trunk calls to
an unalloc ted number. An unallocated number represents a dialed directory
number that does not exist in a Cisco cluster. Valid values specify True
or False. When the parameter is set to True and a call that is being
routed to a remote Cisco cluster through a route list is released by a
remote Cisco CallManager because of the unallocated number, a local Cisco
CallManager will stop routing the call to a next device in the route list.
When the parameter is set to False, the local Cisco CallManager will route
the call to the next device.
This is a required field.
Default: true.
****************************************************************
Andy
Berbee
> Excuse me, receive an ARJ not ARQ.
>
>> Ok, I am just about there.....
>>
>> Is there any way to have the gatekeeper send an ARQ back to the
>> originating CallManager if a "zone prefix" exists that points to another
>> zone but the remote CallManager doesn't have a device registered with
>> the
>> called number?
>>
>> For example, in my gatekeeper config I have the following command:
>>
>> zone prefix DC1_CCM_Zone 202481* gw-priority 10 WDC1TRUNK_2 9
>> WDC1TRUNK_1
>> 8 WDC1TRUNK_3
>>
>> However, in that DC1_CCM_Zone the only extensions are "20248180xx". So,
>> if someone in another zone dials 2024815000 it goes to the gatekeeper,
>> it
>> matches the prefix above, and the call gets a fast busy. I want it to
>> get
>> an ARQ back so it can fail to the next Route Group in my Route List. I
>> do
>> have "arq reject-unknown-prefix" but that doesn't fix this scenario. If
>> I
>> can't find a way to do this I will have to get crazy with zone prefixes
>> and drill down to exact DID level which I would rather not do. There
>> has
>> to be a way to accomplish this.
>>
>> TIA,
>>
>> Andy Dignan
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
More information about the cisco-voip
mailing list