Typically my UCCX (Unified Cisco Contact Center Express) stories involve much weeping and gnashing of teeth, but here’s one that (mostly) just left me scratching my head for a while.
I got a ticket reporting that a courtesy phone in a lobby was no longer working. After a little digging, I found that this phone was put in place to be a PLAR (private line automatic ringdown) phone, and when users picked up the handset they were greeted with an unfriendly fast busy instead of being courteously and automatically connected to the proper extension.
The phone in question was assigned its own Calling Search Space (CSS) and that CSS contained a single partition with a single translation pattern. This pattern translated “nothing” (meaning the user enters no digits) to an extension, but in typical network discovery fashion, I found that this extension pointed to yet another extension assigned to a different translation pattern and then that was pointed to a UCCX trigger. Yes, because complexity always makes the network run better.
First order of business, simplify. This extra translation didn’t seem likely to be the cause of the issue at hand, but it certainly wasn’t necessary so by pointing the PLAR translation the to UCCX trigger directly I made my life a whole lot easier, which I am a huge fan of doing.
Knowing what I know about UCCX and CUCM hand-offs, I honed in quickly on determining if the CSS of the translation pattern could “reach” the UCCX trigger. The device calling the UCCX trigger has to have access to the partition the trigger is in otherwise the call isn’t going through, and you’re going to be having a bad day.
In this case, we are actually talking about the CSS of the translation pattern and upon inspection the translation pattern was assigned a CSS that included the partition the UCCX trigger was in.
At this point, I needed to prove to myself that this was a UCCX issue and not a general CUCM issue, so I changed the destination on the translation pattern to my own extension – also in the same partition as the UCCX trigger. Worked like a charm. Definitely looking like UCCX weirdness then…
Quickly tired of grasping at straws, I took some logs from CUCM and threw them into Translator X and Notepad++, both of these tools are awesome and if you are not using them, you should be!
Here’s the line I kept seeing from my CUCM traces, indicating what I first suspected, a CSS issue:
10:03:35.086 |Digit analysis: potentialMatches=NoPotentialMatchesExist
CUCM could not find a potential match for the destination directory number in any partition in the CSS of the translation pattern. Which didn’t make sense. Which is why Contact Center so often makes me wanna cry.
I decided it was time to talk to my excellent friends over at TAC. After reviewing the configuration with the engineer, I was presented with Bug ID CSCso91760* which basically reports that instead of using the CSS on the translation pattern redirecting the call, the hand-off was using the CSS of the originating phone. In our case this meant the CSS being used was the PLAR CSS of the phone – which couldn’t reach anything except that single PLAR translation pattern. Lovely.
The fix was simple enough, though. In UCCX**, just go to the configuration page for the trigger and click the “Show More” button at the bottom. Then look for Calling Search Space for Redirect under the Directory Number Settings Section. Change the CSS from Default Calling Search Space to whatever CSS you need for the call to go through.
Here’s what you should be looking for in the trigger settings page, you can see that Default Calling Search Space is, well, the default:
Nothing further required, problem solved. Yay you! Now somebody pass the tissues…
Published July 17, 2013.
*CCO account required
**UCCX version in this case is 8.5, I was too lazy to research if earlier version have this same option box, if you have an earlier version and you don’t see this option, you may want an extra box of tissues.
Amy Engineer 
Hi there,
Nice article..
Just reading the bug report description and looks like the issue is with using the JTAPI initiated Redirect and what CSS it uses on CUCM so i dont think the version of UCCX will matter..
Also reading the description from the developer it sounds like there is a miss understanding of what CSS JTAPI Redirect uses rather then a bug.. could have it wrong 😉
Good read though
alexis
I completely agree! In fact, I should have mentioned that this issue could be a problem with any third party app. Based on my conversation with the UCCX engineer, it very likely could be the result of a communication issue in development. Hoping other apps have the capability to change the CSS of the redirect because as in my case, I couldn’t very well change the CSS of the phone to have the CSS of the trigger since that phone could only have a CSS with just the connection PLAR translation.
I have UCCX 8.0(2). I couldn’t recreate the problem. Phone has a CSS, only contains a partition for the empty translation pattern. This has a CSS with the UCCX trigger in the partition. PLAR works fine. Default CSS for redirect is “Address Search Space”. Also tried setting to “Default Calling Search Space” and “Calling Address Search Space”.
Hummm, maybe this only affects 8.5 releases? I didn’t dig too deep into the origins of the issue, I should look back at the affected versions for the Bug ID…
Thanks! This post explained a problem I encountered with a customer’s UCCX 8.5 over a year ago & is still ongoing when we upgraded it to UCCX 9.0. Using a translation pattern to rewrite DNIS for calls received from a SIP trunk to the UCCX CTI RP always resulted in 404 not found errors.
Glad it helped!!
This is why I ran away from voice after 7 years. The first 4 in regular voice were ok and interesting then anything to do with Cisco VoIP and Cucm and call centers forget it, I rather learn how to program SDN
“Here’s the line I kept seeing from my CUCM traces, indicating what I first suspected, a CSS issue:
10:03:35.086 |Digit analysis: potentialMatches=NoPotentialMatchesExist
CUCM could not find a potential match for the destination directory number in any partition in the CSS of the translation pattern. Which didn’t make sense. Which is why Contact Center so often makes me wanna cry.”
This statement is not correct. “NoPotentialMatchesExist” means that there are no more matches. In most cases it means that CUCM will not wait for interdigit timeout. This is not intuitive at all. The developer made it difficult to understand. To check if this call would be routed, you need to take a look at SDL traces to find if the call was routed or blocked on DigitAnalysis level.
I fixed something exactly like this you described here with a ringdown phone pointing to a UCCX Trigger few weeks back. But in a different way. After digging into the traces, wondering why am I seeing ‘NoPotentialMatchesExist.’ Figured it was choosing the originating device’s CSS instead of Translation Pattern’s CSS. I put my CUCM logic aside and went ahead and added Partition of the UCCX Trigger on the lobby phone’s CSS. This along with the special partition it has. Adding the second partition doesn’t affect the ringdown behavior but it allows the call to connect to UCCX Trigger. Voila!
I didn’t come across your post or the documented bug first. I needed a quick fix and I was not convinced that something can be done from the UCCX end. Weird thing, I have a lot of other ringdown phones configured the same way, they all work fine. This is on Ver 10.5.
Super helpful as always, Amy! Fixed my issue. Thanks!