Scenario 38# Call Routing Issue – Intercept Pattern

Posted: April 19, 2012 in Call Manager - CUCM, Real World Scenarios
Tags:

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.

 

Advertisements
Comments
  1. max says:

    nice read. what CLS commands did u use to check database entries for this directory number.
    Can you share the commands please

  2. max says:

    I meant to say what CLI commands did u use to check database entries for this directory number.
    Can you share the commands please

  3. shabeebcool says:

    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..

  4. asharsidd says:

    Here are the commands:

    run sql select * from CallForwardDynamic where cfadestination = ‘7554111’

    run sql select * from numplan where dnorpattern = ‘76146920’

  5. max says:

    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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s