UCCX Disconnects

refram · ‎04-02-2010

I'm using CUMC 6.1.3.3190-1 and UCCX 5.0(2)SR02_Build045.

We have scripts in place that are performing their jobs correctly. One of the jobs being done by these scripts is redirecting calls to other users.

I am working on my first script for this. I have created a simple one that is supposed to do nothing other than prompt a caller to dial a person's extension and then transfer the calller to that extension.

When I call the trigger number from inside the building, it works. When I call from outside of the building it does not. What happens instead is the caller hears the initial prompt, dials "1" to get to the next section, hears the prompt informing them that now is the time to enter an extension, and is allowed to enter the extension. The routine at that point calls for a consultative transfer, so the caller hears about a half-second of music-on-hold, but then the call is disconnected. I tried using a call redirect instead of a transfer and the same thing happens. Works on the inside, not on the outside.

I wondered if it's an issue dealing with "rights" given to the caller, but I've checked the calling search spaces of the triggers for the other applications that work and they are the same. Any ideas?

William Bell · ‎04-02-2010

There could be a possible CODEC mismatch. But that is speculation at this point. Some questions/things to check:

1. Are you using H.323, SIP, or MGCP on the voice gateway?

2. Is there a way to test the same gateway/trunk that is handling ingress calls for your UCCX solution but route the call directly to an IP phone by either using a DID line appearance, translation, etc.? If so, can you test the direct call through the gateway to the IP phone (thereby separating the call flow into parts and seeing if there is an issue with direct calls).

3. Can you check region configurations on the Music on Hold provider, IP phone, UCCX port, and gateway. Remember that the default intra-region CODEC is G.711/G.722 and the default inter-region CODEC is G.729. Also note that Region configs on CUCM do not dictate CODEC but simply identify maximum bandwidth allowed (CUCM will always try to choose the more robust CODEC). At the same time, if you are using SIP/H323 on the voice gateway. Check the dial-peers voice CODEC (either assigned directly or via the codec class statement).

The components in the call flow you described are:

1. Voice gateway ingress port

2. Cisco IP phone

3. MoH server

4. UCCX CTI Route Point (not something you need to check at this point, included for completeness)

5. UCCX CTI Ports

What you want to look for is anything in the region or gateway/CODEC configurations that could lead to a situation where the gateway cannot negotiate CODEC with either the UCCX ports (not likely since the call was answered fine), MoH source, or IP phone.

You know the disconnect happens from UCCX to the phone. On this leg of the call, you have a MoH resource and the IP phone. Take the UCCX and MoH out of the picture and validate IP phone-directly-to-voicegateway. If that works. Then look at the MoH resource a little closer. You could even take MoH out of the picture by assigning a MRGL to the voice gateway that does not have any MRGs with MoH resources (this assumes that you are using MRGs/MRGLs. If not, then MoH resources are in the default MRG which is available to all devices.

Another angle to check is the CSS configs. But you have already checked that out and if you are using consultative transfer, the CSS that matters (with respect to bridging the call from the Gateway to the IP phone via UCCX) is the UCCX CTI port CSS. Which, you know works because internal calls can get where they need to go. But, if you wanted to be double-sure you can configure a test phone with a device level CSS that is identical to what you are using on the voice gateway. From there, call your CCX app and see what gives. You will want to make sure that the line you are testing from does not have a CSS associated. Note, you could also use DNA to dissect the CSS call path. Worth checking, but I am leaning to CODEC issues given the info thus far.

HTH.

Regards,

Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

toronto09 · ‎04-04-2010

+5 for Bill. I believe Bill is on the correct track where it could be a codec issue. Just in case, you may also want to check the incoming DID translation pattern and partitions.

Good luck.

Thomas/

refram · ‎04-07-2010

I wanted to give good ratings to both who answered because it was good information, but neither of the answers were correct in this case. It turns out that the issue was that the client has 10-digit DNs everywhere, but users can dial 5-digits to ring the extensions. People hitting the script from the inside could dial 5 digits and it would work. People on the outside who dialed 5 digits couldn't get the number expansion to 10 digits and it didn't work. If they dialed 10 digits from the outside it did work.

So that explains that. But now I have a different problem. Since I'm still new at this, I don't know how to deal with fixing it so people on the outside CAN dial 5 digits and have it work. I don't want to mess with calling search spaces. At this client's office the 5-digit versions of the extensions all begin with either 2 or 3. If the extension begins with 2, a specific group of numbers needs to be prepended to the 5 that are entered. If the extension begins with 3 a different group of 5 needs to be prepended.

So I need a routine that will check the group of 5 digits that is entered, see if the group begins with a 2 or a 3, prepend a set of 5 more digits to the entered group, and then hand the final result off to the next step.

William Bell · ‎04-07-2010

I assume that you are looking for a script snippet for UCCX? Try this:

Assumptions:

1. Station lines with a leading "2" in the 5-digit abbreviated pattern are in the NPANXX 202552xxxx

2. Station lines with a leading "3" in the 5-digit abbreviated pattern are in the NPANXX 202663xxxx

Script:

After you use the "CollectDigits" routine to gather 5-digits from the caller it is written to a string variable. Let's say: extensionDN

Next, you need to parse this string to understand what you are dealing with. One method:

Set extensionID = {extensionDN.substr(0,1)}

/use a switch statement because you can add to it down the road (e.g. 4xxxx, 5xxxx, etc.)/

Switch extensionID

branch "two" (if the extensionID == "2")

set transferDN = "20255" + extensionDN

goto TRANSFER_CALLER

branch "three" (if the extensionID == "3")

set transferDN = "20266" + extensionDN

goto TRANSFER_CALLER

branch Default

/you got here because the caller entered some bogus stuff/

Play prompt "You entered some bogus stuff"

/* at this point you could clear all of the string variables and then send the caller back to the main menu to try again, or you could punt them to an operator*/

:TRANSFER_CALLER

/use consultative transfer to send the caller to the user/

Under TRANSFER_CALLER you should also have some error routine in place just in case the extension was invalid. The UCCX will try to transfer, get a reorder and then come back to the script. You should handle that error state by playing a prompt that said the extension the user was trying to reach was invalid (nicer wording of course) and then send the caller to the operator. Don't use the "Contact Handled" flag until you actually handle the contact.

HTH.

Regards,

Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify