I couldn't find anywhere any mention of this problem so I am starting a new discussion on this one.
I have an issue when all Local Route Group, Call Forward and Extension Mobility are combined in the below scenario.
All external calls are routed using the Local Route Group feature
The Enterprise parameter "local route group for redirected calls" is set to "local route group of last redirecting party."
A user has set on his/her DN the "Call Forward All to his/her mobile phone
The user is logged off the phone
So when a call comes in (external or internal) the call fails because the CUCM is trying to forward the call using the route for external PSTN calls which points to the standard route group but as no device is attached to the DN and doing redirection, the "last redirecting party" doesn't have a Device Pool, hence which gateway it should use is unknown to the CUCM and the call fails.
I can't change the enterprise parameter to "local route group of calling party" because an internal call coming from another employee in a different country would be route to that employee's gateway and the call would fail because the gateway (in that other country) would dial the mobile number as a local number so the call would fail.
Anyone has any idea on how to go around this issue ?
Local route group for redirected calls" doesn't work fully for EM
Symptom: When "Local route group for redirected calls" service parameters is set to "local route group of last redirecting party"
A (EM logged in)-> B(EM logged in)-> CFA -> PSTN number using local route group -> fast busy
When "Local route group for redirected calls" service parameters is set to "local route group of calling party" (default)
A (EM logged in)-> B(EM logged in)-> CFA -> PSTN number using local route group -> works
Conditions: EM users try to use "Local route group for redirected calls" service parameters with value set to "local route group of last redirecting party"
Further Problem Description: Reason: When DA tries to fetch the Local Route Group settings for the Called Party and the Last Redirecting Party, it checks for EM number A or B association with device and corresponding LRG (according to the current implementation). However A or B is associated with a Device Profile not the Device. Device Profile will not have any LRG configuration thus the originalLRG and lastRedirectingLRG fields are empty
It seems the workaround is to use calling party LRG, you may check with TAC if there are any further updates on this since you can not use the workaround in your scenario.
Per bug description when respective parameter is set to last redirecting party, both A and B are internal users and EM logged in and if both are logged in, DA must get device pool and hence LRG of respective device.
Issue should be for example when B is not logged in and if B is last redirecting party, DA will not get device pool and associated LRG, that is the actual issue reported here.