Issue: Local Route Groups and External Call Fowarding

[heathrw]

Hi,

I have a two sites configured with the following:

Site A:

DevicePool_A (No Local Route Group Set)

Specific Patterns with Specific Route list

Device & Line CSS approach (Gateway at Device level and Blocking at line level)

Site B:

DevicePool_B (Local Route Group Defined)

Specific Patterns with Route list to use Standard Local Group

When a phone at SiteB calls another phone at SiteB with CFA to an external number it works. But when a person from SiteA calls the SiteB phone with CFA enabled I get fast busy. The only way around this was to create a route list specific for site B with a route patterns and set on the line CFA CSS.

It seems that when the SiteA phone is trying to use the SiteB CSS and the SiteA device pool local route group (which is none) to call the forward number which fails the call and not what I want as I would like the SiteB phone to get charged for the call via the local gateway. Is this this how the local route groups are supposed to work?

Thanks

[heathrw]

Just fixed my own problem:

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/admin/7_0_1/ccmfeat/fslrg.html

Forwarding

For forwarded calls, Cisco Unified Communications Managermust use the Local Route Group that is provisioned in the device pool settingsthat are associated with the redirected party to find the provisioned localroute group. Thus, if phone A calls (local) phone B and phone B forwards thecall to (remote) phone C, the Local Route Group value from the phone A devicepool gets used rather than the corresponding value for phone B.

Is there a way around this? Service/Enterprise parameter?

[gonatienza]

Hi there,

Did you solve your problem?

A coworker is having a similar issue.

Please tell me you didnt start adding patterns to solve this, that would go against the idea of local RGs...

Thanks.

[heathrw]

Hi Gonatienza,

Please refer to my previous post as it is outlined in the SRND explaining the local route group function.

Unfortunately I had to create a new entire set of call forward patterns and search space with specific gateways, but limited to digits to local numbers only so only one set for each site.

I only see this as an issue with ISDN technology as here in AU you cannot spoof a number (external phone number mask) on a circuit where the numbers do not come in on. On the other hand if there are SIP trunks you could make an arrangement with your carrier.

My client typically uses this to divert to their own mobile phones so looking into single number reach.

Heath

[Steven Griffin]

Heathrw,

Sorry to say, no there isn't a way to disable the behavior. The answer is that the Call Manager is behaving as designed.  As an  administrator you need to design your dial-plan to take this situation  into account.

Generally this issue crops up in a CFWD-All situation where someone sends all their calls to a local NANP 7-digit pattern and someone at a remote site tries to call them on-net and the local route group ends up dialing a 7 digit number that isn't local to the remote user.

That said, you have options:

Option 1: Use 11 digit or E.164 dialing.  Translate all local numbers into 11 digit or E.164 (+ dial) numbers *before* attempting to match a route patten that uses the Standard Local Route Group to find a voice gateway

Option 2: Forbid your users from forwarding to 7-digit local numbers (class of restriction or remove 7-digit patterns from CFWD-All Calling Search Spaces)

-Steven

P.S.  I assume here that you are dialing within the North American Numbering Plan (NANP).

[talmand]

I have a setup with SIP trunk to PSTN, using SLG call forwarding failed. I was able to correct this by ensuring that the centralized SIP trunk DP has the SLG defined and contains the originating GW. this would seem to help some on this post, but maybe not all.

[Mohsin Khan Feroz]

Can you route the call as a ON-Net Call and check if that works?