Had a bizarre issue with one of the customer where they were trying to dial an internal extension and it was going to a mobile phone. There were no CFA/CFNA/CFB set on the extension itself but for some reason it was following this path. The Call manager version was 6.x.
The call routing was designed in a way that when they dial any 7614XXXX extension, it hits a TP (7614XXXX )and gets translated to 60447614XXXX. For testing we dialed several 7614XXXX numbers and they all went fine to corresponding 60447614XXXX except when they dialed 76146920. As soon as they dial that number you will see on the display that it’s going to an outside mobile number.
I had to dig into traces where I found for some reason it is not even hitting the Translation pattern at all and was getting intercepted by a pattern 76146920 with a Time of Day routing on it which had that mobile number setup during a certain period of time. But when I checked, there was no such TOD routing setup on this extension, moreover there was no such extension 76146920 which exist in the system. I ran some CLI commands to find if there are any database entries for this extension and found none. Customer told me that they use to have extensions like 7614XXXX before they migrated all extensions to 60447614XXXX which means may be previously someone did setup a CFA on this extension which is still stuck in it’s database.
|VoiceMailPilotNumber=
|RouteBlockFlag=BlockThisPattern <———block
|RouteBlockCause=1
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=33
|InterceptPartition=Internal
|InterceptPattern=76146920
cfa = 755XXXXXX <———– Mobile number
This is what I did to resolve the issue:
- Created an internal extension 76146920 and put it in Internal Partition
- Assigned the extension to a dummy phone
- Put a Call Forward ALL on the extension to some internal number
- Made a test call which now hits this newly created DN and goes to that CFA internal extension
- Removed CFA and saved
- Deleted the DN 76146920
- Made a test call and this time it was ringing the phone 604476146920
This was just a one off issue and Cisco TAC later confirmed that old versions of CCM may come across these kind of issues. This is rare but I thought to share it for the benefit of everyone.
