The Scenario
The scenario is pretty straightforward. We have Cisco Unified Communications Manager (CUCM) 8.5(1)SU3 and Cisco Unity Connection (CUC) 8.5(1)Su3. The use case is that we want to allow CUCM users to transfer callers to the voice mailbox of another Unity Connection subscriber.
The Normal Behavior
So, I have been working with Unity/Unity Connection for many years and this whole transfer a caller to another mailbox thing has been around almost as long. I recall reading a Cisco document on how to accomplish this back when deploying CallManager 3.1(4b). The procedure worked well then and has been a staple forever, well at least until I tested it with Unity Connection 8.5.
What is “Normal” anyway?
Hailey and I are building out this system, we are applying our standard build, and we go into validating configurations. It is at this time we realize that we can’t transfer callers to another user’s mailbox. Not only that, but we can’t get into CUGA or access any of the other Call Handlers we have on the system. Instead of going to the proper Call Handler or conversation, calls are getting opening greeting or the subscriber sign-in conversation. Which are both accessed via Direct call routing rules.
Since we use bogus lines on a bogus CTI Route Point to hit our call handlers, we know to look at redirection (aka forwarding) rules in Unity Connection. We check configurations and everything appears to be what one would expect.
We monitor calls coming into Unity Connection and at first glance everything appears normal. We go through another round of double checking and triple checking everything to no avail. This is such a simple thing, why can’t we find the issue?
We accept that our configuration is correct. So now we are in the wonderful world of “bug” hunting. Fortunately for us the Cisco Support Community (CSC) exists. With a few searches we come across a thread where some poor soul ran into the same issue.
What’s in a name?
The solution, as absurd as it sounds, was to remove any occurrences of the words “voice” or “mail” in the alerting or display name fields. When I first read the thread I was like “no way”. I re-read it twice just to see if someone later in the thread would contradict this naive suggestion and offer the “true” root cause. Instead I found 2 or 3 people who confirmed that this was indeed the fix.
With some skepticism I say “what the hell” and modify the alerting and display fields. As soon as we applied the configuration, everything worked as it should. We put the words “voice” and “mail” back in just to see, and sure enough it breaks.
I took another look later on in the build out using Port Status Monitor and you can see that in a failed call (you know, one where the alerting/description field has “voice” or “mail” configured) the RedirectingId is blank. This is the reason the forwarding rules are not engaged and the Attempt Sign-In conversation or Opening Greeting (depending on where you call from) is.
This one was so ridiculous that I just had to share. Now I wonder what happens if the phone line in the “mail room” is redirected to Unity Connection. I may have to test that out just to see how deep the rabbit hole goes. For now, I am done with this one.
Update
A colleague recently forwarded the following URL to me about CCM 3.2.2 voice mail integration. At the bottom of the page there is a note about using “Voicemail” in the alerting or display name fields. Interesting given that I have use the term ‘Voice mail” in builds since CCM 4.1 and didn’t hit an issue until CUCM 8.5. Now, the question is: how curious am I?
Transferring Calls Directly to Voice Mail with Cisco CallManager 3.2.2 spD