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.
voiceonbits.com 
nice read. what CLS commands did u use to check database entries for this directory number.
Can you share the commands please
I meant to say what CLI commands did u use to check database entries for this directory number.
Can you share the commands please
Good work.. As requested by max, please share the CLI commands you used to dig in.. Also, if you have any documents which can help me learn CUCM Traces, it will be very very very very helpful..
Thanks Mate..
Here are the commands:
run sql select * from CallForwardDynamic where cfadestination = ‘7554111’
run sql select * from numplan where dnorpattern = ‘76146920’
ash I have learnt so much since the last time we met and slowly I was going under the illusion that I was getting closer and closer to your level of expertise. but the more I read your work the more I realise that you are truly amazing. Ash, you are on another level.
Cheers for the reply mate.
agree with Max. I’ve been reading you since I start working on voice 7 years before and every time your article left me with a feeling that a lot more to be done in terms of better understanding of technology.
been working on inter-cluster sip trunk for last 2 days–connecting 2 clusters where CTI RP in cluster B was giving busy signal with no reason. call within Cluster B was good and plays the associated IVR message. Even the RP in Cluster A while calling from Cluster B was good and configurations are all same on both RP and SIP trunks level. found intercept partition & number which was actually the same RP number in logs. search & found this page and got the clue. checked my route plan but no extra number was there. then changed the incoming CSS of Trunk to none. got the call can not be completed message and then return the CSS back to hit the RP partition. and magic happened -:) you are just amazing Ashar. keep up the good work…Mudassar