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 http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmfeat/fslrg.html#wp1050881
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.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...