Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CUCM appears to be treating enbloc and non-enbloc calls hitting translation pattern differently

We're running CUCM 7.0.2.10000-18


We use 4-digit dialing and have created a system of translation patterns, for the purpose of "speed dialing" branches, by mapping 4-digit extensions (main DN for each branch) to a 3-digit number that corrolate with the accounting system.  For example, Chicago is branch number 02 in the accounting system.  All speed dials start with '7' so the speed dial for Chicago would be 702 (which then hits a translation pattern which transforms the called party number to Chicago's main line DN of 5420).  There are 39 branches and every single branch has a translation pattern created for it in the format 7xx where xx is the two digit branch ID.  Every single translation pattern is setup in the exact same way.

One particular branch is having issues.  If you simulate a call, via DNA, using a line on a phone at corporate to 728 (which is the speed dial number for this branch) DNA says "Route this pattern" and properly identifies the correct 4-digit extension.

If you enter 728 at the TUI and press the "dial" softkey, the call goes through properly.

However, if you press the "new call" softkey or in any other way take the phone off-hook and then press 7 2 8, the call does not go thru and the caller hears a fast busy.  This only affects one branch. 

I turned on tracing (I can provide full traces upon request) and then I asked two users to try placing calls (in the two different methods mentioned earlier).  The only thing I see that's different from the call that goes thru vs. the call that does not is this (first, the call that didn't go thru):

PotentialMatches=PotentialMatchesExist 

Now the call that did go thru:

PotentialMatches=NoPotentialMatchesExist

I think this is because the call that worked used enbloc whereas the call that didn't searched for potential matches after each key was pressed in the 728 sequence.  There's reference to it in the trace:

03/06/2012 10:45:20.335 CCM|StationInit: (0003780) EnblocCall calledParty=728.

I seached for bugs on Cisco's website but didn't find anything.

Any ideas?  Thanks, in advance, for taking the time to help.  If I can provide any additional information please let me know.

4 REPLIES
Hall of Fame Super Silver

CUCM appears to be treating enbloc and non-enbloc calls hitting

How is the translation pattern defined that prefixes the digits? Is it 728XXXX or 728!?  This issue has to definitely to do with urgent priority routing, so if you are using the second option please uncheck "urgent priority".

HTH,

Chris

New Member

CUCM appears to be treating enbloc and non-enbloc calls hitting

Hall of Fame Super Silver

CUCM appears to be treating enbloc and non-enbloc calls hitting

Uncheck the "Urgent Priority" and it will behave as you want it to behave.

Chris

New Member

CUCM appears to be treating enbloc and non-enbloc calls hitting

Chris,

Thanks for your input.  All of the translation patterns, including those which work just fine, have the "Urgent Priority" checkbox checked.


Regards,

Steven

478
Views
0
Helpful
4
Replies