Anyone have Local Route Group Call Forwarding issues?

[Tommer Catlin]

There seems to be an issue with Call Forwarding issue with Local Route Groups.  IE.... if I forward my phone to 95551212  and someone calls from another cisco site internally, it defaults to the remote devices Local Route Group with 95551212.  If we do not use LRGs, it will go out my gateway. 

[John Palmason]

I believe we had a similar issue, we have a single cluster with 13 branch offices and when a user at a remote branch office would forward their phone (to a cell phone) it would always use my local gateway to place the call.  Because the branch is in a different area code the call would fail.  You can watch the debug isdn q931 and see that the calls will try and use the local gateway, but calling number is incorrect because it will require to prefixed with a 1 to complete.

Is this what you mean? 

We opened a TAC case and we were told that it was working as intended so we had two choices, live with it or remove the SLRG and create Loacl route groups.  Because we only have 12 sites it wasn't that big of a task, but it could be if you have a huge environment.

[Tommer Catlin]

John, exactly what I mean. How did you work around this?

[John Palmason]

We had to go back and create route patterns for each location and place them in a partition that can be reached from each site CSS. Then we had to remove the "all_sites_route_list" our SLRG and create a route lists for each branch office that listed only the local gateway.  Basically undo all steps of SLRG, once we did this we were able to have any call forward number on a branch phone and the call would complete using the local gateway of the branch phone.

Hopefully that make sense, it seems like a bug to me but that is not how Cisco is seeing it.

[Tommer Catlin]

So basically, remove local route groups complete correct? I have a fix that uses the toll to dial long distance on call forward using Translation/transformations and it works. But it’s a toll call.

I kind got Cisco to admit that is was a design change and will be fixed in later releases. I have 8.5 SU1. I cant remember if I had this probably in 7.x..

[John Palmason]

Yes unfortunately this was our solution to this problem.  We are currently using 7.1.5(SU4) and it still exists. Cisco had recommended us to do a feature request with our local VAR but I didn’t see the value in it.

[Tommer Catlin]

Interesting…. I have about 15 sites I just converted and noticed this…. My only work around is to toll charge with transformations. Or rip out LRGs. Cisco said it might be fixed in 9.x. Thanks for the input.. I thought I was going crazy.

[William Bell]

Hailey and I were discussing a similar design a month or so ago. I believe he is doing the deployment this Friday. Anyway, what I believe we did was to normalize the dialed digits to an E.164 number and then, if TEHO was required, create route patterns for specific NPAs to prefer a specific RG (w/ a secondary preference for LRG).

Taking a scenario. In Washington, D.C. you can dial 7-digits (95551212). This number hits the directory assistance for DC metro. Phones in DC have a CSS like: DC_User-Std_CSS.  This CSS has numerous partitions and patterns, one of those patterns catches 95551212 and expands it to +12025551212 (it could easily be 92025551212 or 91202551212) but let's say it expands to +12025551212.

This works for direct calls and for CFA to 95551212. The phone line DN will store 95551212 but we tell CUCM to use a specific CSS (which is DC_User-Std_CSS) when the forward manager initiaties digit analysis. So, net effect is it should be the same behavior. 

The reason we normalize the dial string is because there are more than 1 local geographies which allow 7D dialing. As you found out, if you have a phone in DC forwarding to 95551212 and one in Chicago metro forwarding to 95551212 AND you are using LRG, your phone in NYC will send calls to the NYC gateway. That gateway has no clue how to route that call.

So, first problem is normalizing the number so you can make smart routing decisions in various call scenarios.

This thread also touched on TEHO concepts. Basically, the idea that when the DC phone is forwarding to a DC number, you want to use the DC gateway.  You can still do this. Once you globalize the number, you have all information needed to pick the right gateway(s).

For instance, we could have a route pattern +1202[2-9]XXXXXX point to a route list: DC_PSTN-Std_RL and that route list can have:

(1) DC_PSTN-Std_RG  (the voice gateways in Washington DC)

(2) Local Route Group (failover to your own local route group, whereever that may be)

Final step, use transformations at the gateways to present the DNIS the way the local CO wants to see it.

Going back to the OP, the real problem is that you aren't normalizing (or "globalizing") the 95551212 pattern to something that is universally recognizable to other areas of your dial plan. Oh, and if you didn't care about TEHO (i.e. sending calls to DC) then you could still use a generic RL with a LRG in the priority 1 position.

HTH.

Regards,
Bill

[Tommer Catlin]

Hi there!

So I know we went over this pretty much before I believe. The concept of normalizing locally with translation patterns.. IE 95551212 to 14085551212. Route pattern /1 and then a transformation pattern to strip it back to 95551212 if its local is effective.

The problem arises if that the phone is in call forward all. CUCM is defaulting back to the originating devices DP LRG…. It does translate it and keep it at +14085551212, but it routes the call LD (Toll call). In the past, the call has always simply hit the call forward, and followed the CSS/PT of that line of the CFWD. (without LRGs). We actually got Cisco to admit that this may be a design flaw or something that was “left out of the design” and “will be added in at a later release”. But I had go deep down into the bowels of cisco to find someone to actually admit to this.

[David Hailey]

Tommer,

Interesting tidbit of info and quite timely as well.  So, the issue you are experiencing - correct me if I am wrong - is NOT that the CFA doesn't work.  Instead, when the CFA is active on Phone A (Site 1) and receives a call from Phone B (Site 2) it is using the LRG of the calling device (Phone B - Site 2) to make the call.  In this scenario, the CFA pattern is being translated/globalized so it's always a LD call going out of the LRG (gateway) of Site 2?

Hailey

[Tommer Catlin]

You are correct good sir. Give it try and you will see the call go out the originating devices LRG on a call forward. Its ridiculous. Now, if you had a Centralized SIP trunk, then I guess it wouldn’t matter. The only option I have is to rip out LRGs and go “traditional” or stick with LRGs and let the customer know CFDs will be toll calls in that scenario. I hear mumbles from Cisco that it might be fixed in 9.x

[William Bell]

Sorry to disagree, but I don't think it is "ridiculous". What you are describing is exactly what I would expect to happen based on my understand of Local Route Group. Think of a different call forwarding scenario, like call forward unregistered (CFUR). If you had a Site A that suffered a WAN outage, you may want other phones at other sites to still be able to call phones at Site A. You also may not want Site B, C, D, E, F, etc. to send traffic to a gateway in Site A (stupid) or a HQ site. This is where LRG is very handy.

So, SRST+LRG+CFUR gets you around a WAN outage in a somewhat graceful way. Definitely better than pre-LRG versions of CUCM/CM.

I do agree with Jason that people can't get ridiculous with TEHO and I wouldn't introduce TEHO to direct call routing designs if I was only trying to solve a problem with redirecting calls. Instead, I would build a separate callfwd CSS to deal with the scenario Tommer describes. UNLESS the customer had a TEHO requirement for direct calling anyway, then it wouldn't matter (of course, standard disclaimers should be given to said customer).

Anyway, I think that LRG is operating exactly as designed and documented. That doesn't mean that it couldn't stand some improvements. There are other design scenarios where I wish it was a little "smarter". Call forwarding/redirection being an interesting challenge. Cisco couldn't (or shouldn't) just update the code to say use the LRG of the forwarding station during a forwarding event. That would only shift the problem. There would have to be a mechanism that is granular enough to selectively apply alternate-LRG (ALRG?) on individual call forwarding directives per device line.

Hailey and I have discussed this on numerous occassions and my opinion has been that if you think LRG (and I'll lump transformations in here too) is going to simplify your dial plan, then you are lining yourself up for disappointment. It is possible, in some designs, that you can realize an overal reduction in complexity. However, I have found that it is better to think of LRG and transformation patterns as tools of the trade. Tools that navigate around certain problems that we had to contend with pre-LRG (e.g. SRST and routing around outages, tertiary callfwd for CER, 911 dialing in general).

Just my .02 cents.

HTH.

Regards,

Bill

[Tommer Catlin]

Love the 2 cents! I think there are pros/cons with how CUCM deals with call forwarding in the event of any type of call. I still think that any Destination in on the line for calls should be allowed to follow the remote device if it is registered. If its unregistered, then it should follow routing of the remote device.

IE, phone is registered and the scenario is CFWDall, Ring no answer internal, external, busy, etc… should following the line css. If the device is unregistered, it should follow the LRG then. Or at least, there should be a “toggle” in the service parameters for this. Where Callforwarding when registered Follows line CSS or follows LRG. (On/off) Unregistered should always follow LRG.

I agree, LRG are designed and documented this way to follow the remote device’s LRG. But what we cant figure out is why its not outlined in the SRND. All it says is that call forwarding will follow the remote device… IE, if you are migrating TO LRGs.. beware that call forwards will need to be normalized and to handle 7D and 10D dialing (or any other patterns)

So in the unregistered field for the line, are you putting the +1408555XXXX (if the DN was XXXX). That way, it will use LRG and go out the originating devices gateway?

Where is Rob to give us all +5 on our conversations?! ☺

[jahman614]

This is an issue particulary where you have 1 cluster serving sites in different countries.

For example we have a customer with 6 sites in 1 country and 4 in 4 different countries. In the first case LocalRouteGroups are awesome. But as soon as we cross the border it becomes a hassle because then the CallForwarded call becomes an international call.

So there definitely should be a toggle for the different CallForward scenarios (i.e in CFA bad, in CFUR good)

Just my 0.02 SEK

[Jason Aarons]

I don't like TEHO in large designs because you can't provide enough capacity at the remote site level for all the users across the globe who at a particular moment decide to say call New York City.  I prefer to route all toll calls Intl/LD to a single provider SIP/PRI centralized in the datacenter (or regional provider) so I can better monitor resources. Usually I get a better intl pricing then having resources all over the place, and less hardware (CUBE/PVDMs)  to purchase. There are some exceptions to the rules, and smaller companies you can easily overprovision.

Same applies for inbound resources in duplicate datacenters versus having inbound at branch locations is more reliable.  Your office can go down but callers still get your VM when it's in the data center.