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.