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

UCM 8.01 Call Forwarding w Local RGs

We are running UCM 7.01 and when using local route groups in conjunction with call forwarding, calls are sent out the calling party's gateway instead of the called parties gateway.

Example: If PersonB in San Diego needs to go to lunch, he forwards his 7945 to his cell 96192223333. When PersonA in Salt Lake calls PersonB's 7945 and gets forwarded to PersonB's cell, the call is sent out PersonA's local gateway in Salt Lake. Therefore the call does not complete because a 1 is needed to dial the cell phone since it is long distance. However if PersonC in San Diego dials PersonB's 7945, when it is redirected to his cell phone, the call completes since it is a local call and therefore does not need the 1 for long distance. I found this quote in the UCM Feature and Services Guide for 7.01

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

According to this doc, it seems that the call forwarding is working as it is supposed to. However this design seems flawed and causes issues such as the one described above. Can anyone verify that this is how call forwarding with local route groups is supposed to behave and if so, what a workaround would be. Basically, we want all forwarded calls to be sent out the gateway local to the IP phone doing the forwarding (called party), not the calling party's gateway.


Re: UCM 8.01 Call Forwarding w Local RGs


For CFUR it's great (you find that in all the LRG slides) - for CFA it's not.

There is also the problem "who pays for forwarding".

As I interpret the doc..

"..the calls will be routed differently, based on the caller's currently associated local route group." works as designed. :-(



CreatePlease to create content