So we had an issue for months where if Single Number Reach (Mobility Connect Features) were enabled for users and if they would then use their mobile phones to dial in to the in-dial range (company extensions) the calls would fail, they would then have to block their CLID on their mobile phones before making the call for it to work.
Issue: Users having to have to block their caller-id to dial in to the office main line or that their SNR has stopped working all of a sudeen.
The root cause of the issue turned out to be the following:
So we basically had MGCP BRI in our environment with SNR activated. The option to get away from this was to NOT use BRI in your environment if we want to implement SNR function, need to get rid of the BRI MGCP irrespective of whether it's in use or no.
Cisco developers confirmed that BRI is the source of “CellProxyCdpc” leaking which cause SNR call reaches the limit. Document “Features and Services Guide for Cisco Unified Communications Manager, Release 10.0(1)” chapter “Cisco Mobility” says:
"Gateways and Ports Both H.323 and SIP VoIP gateways are supported for Mobile Voice Access. Cisco Unified Mobility features do not get supported for T1 CAS, FXO, FXS and BRI."
MGCP and BRI is not supported by the SNR feature because BRI couldn’t tell the SNR process to terminate the call.
Mobile Connect features do not get supported for T1 CAS, FXO, FXS and BRI.
These SNR calls through MGCP GWs cause CellProxyCdpc process leaked hence the problem