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

route pattern, intercluster trunk, digit manipulation

We have two CUCM, UCCX clusters, one for genral call routing, the other is for an IVR TTS system. Customers can call into the IVR system and get information from dozens of differnet prompts.

Internally certain people are able to dial *#1234 (star pound, 1234) and this allows them to get to a script on the IVR system to record new prompts.

This currently is not working (worked before) and I am trying to follow the call path.

What I see is a route pattern (*#1234) on the general system that points to an intercluster trunk from general system to IVR TTS system.

On the IVR TTS system, there is a directory number 1234 that is set up for the prompt recording, it is associated with the CTI RP to do that.

What I don't see is how did the first two characters get stripped from the 1234 to send it to the directory number on the IVR TTS cluster?

There is a 1234 directory number on the genreal system already.

There is no mask on the route pattern (*#1234) on the general system.

There is no translation pattern anywhere.

Does an intercluster trunk not send special characters across?

5 REPLIES
New Member

route pattern, intercluster trunk, digit manipulation

I found it, I missed it before.

I didn't see the route pattern is actually *#.1234 (star pound dot 1234)

On the route pattern there is a called party transformation to discard predot.

VIP Super Bronze

route pattern, intercluster trunk, digit manipulation

The ICT on the called cluster will have a Significant Digits field. This will strip any digits from the call above what is specified. Less likely but also possible is a DDI on the route group appearence on the route list. Browse to the route list  that the ICT route pattern is assigned to and there will be a link at the bottom for the associated route group.

New Member

route pattern, intercluster trunk, digit manipulation

The didgit strip makes sense now, what I see is when i dial the *#1234, I get a wait of about fifteen seconds and then it looks like the call gets sent to another four digit directory number configured in the IVR system for the customers to access the system.

Every time I call, waits about fifteen seconds and then rolls to a different number.

On the IVR system, there is no configuration on the 1234 directory number to forward it anywhere.

Is there any kind of capture to see if the call is actually getting to the IVR cluster?

VIP Super Bronze

Re: route pattern, intercluster trunk, digit manipulation

The 15 second figure is probably your T302 inter-digit timer. This applies when there is more than one match for a given string and CUCM is waiting for you to add more digits. If you don't it proceeds at the T302 tiemr expiry. So, check both clusters using the Route Plan Report search option to find what you have overlapping with *#1234. You want to remove the overlap in your numbering plan.

You can also use the Dialed Number Analyzer to evaluate the call flow. http:///dna

You can turn up troubleshooting traces (Unified Serviciability > Traces > Troubleshooting), make a call, and then download the CallManager SDI traces from both clusters for the timeframe of the call. Be sure that both clusters have identical time (i.e. share an NTP source) for sanity when comparing logs. It will show you the H225 call setup between clusters if it's happening.

New Member

route pattern, intercluster trunk, digit manipulation

Thanks for the great information.

I was mistaken on how long it takes before sending to the other number, is is more like 5 seconds.

I dial the pattern and after about five seconds, I hear a partial ring and my phone looks like it is goes to any one of the extension numbers configured on the IVR cluster, another five seconds and I hear "Are you still there?"

When looking in the phone call log on the phone, I see:

To 5500

*#1234

This was all I could find in the trace from the Call Routing cluster, the IVR cluster didn't really have anything related to this call:

I am 10.11.12.250, CUCM is 10.11.10.21

02/01/2012 08:26:44.051 CCM|SMDMSharedData::findSubscriptionIdExistsInSubscribeeState - SubscriptionId=4|0|292 found|<:CALLCENTERCLUSTER><:10.11.10.21><:3><:10.11.12.250><:SEP001319ACC8AA><:DETAILED><:FFFFFF>

02/01/2012 08:26:44.052 CCM|SMDMSharedData::updateSubscribeeStateAndNotify - updated state entry for outSubId = 4|0|292, NotifyMsg = SNFNotifyMsg: state = 0, reason = 0, retryAfter = -1, subscriptionType =  REGISTRATION  BUSY_AVAILABLE_IDLE , content = SNFLegacyContent with content data set to: busy, cepn = f54dc9f6-b31b-4ccc-b924-cbac3d99d51d, mSubscribeePid = (3,139,2571)

, and sent notify to subscribers|<:CALLCENTERCLUSTER><:10.11.10.21><:3><:10.11.12.250><:SEP001319ACC8AA><:DETAILED><:FFFFFF> 02/01/2012 08:26:44.051 CCM|SMDMSharedData::findSubscriptionIdExistsInSubscribeeState - SubscriptionId=4|0|292 found|<:CALLCENTERCLUSTER><:10.11.10.21><:3><:10.11.12.250><:SEP001319ACC8AA><:DETAILED><:FFFFFF>
02/01/2012 08:26:44.052 CCM|SMDMSharedData::updateSubscribeeStateAndNotify - updated state entry for outSubId = 4|0|292, NotifyMsg = SNFNotifyMsg: state = 0, reason = 0, retryAfter = -1, subscriptionType =  REGISTRATION  BUSY_AVAILABLE_IDLE , content = SNFLegacyContent with content data set to: busy, cepn = f54dc9f6-b31b-4ccc-b924-cbac3d99d51d, mSubscribeePid = (3,139,2571)
, and sent notify to subscribers|<:CALLCENTERCLUSTER><:10.11.10.21><:3><:10.11.12.250><:SEP001319ACC8AA><:DETAILED><:FFFFFF>

749
Views
10
Helpful
5
Replies
CreatePlease to create content