In this entertaining episode of stump-the-voice engineer, users report a directory number is being routed through the Bermuda Triangle and landing in no-man’s voicemail land. In fact, the mysterious voicemail greeting being heard by callers sounds like 3 minutes of someone pocket dialing their neighbor’s cat.
Proceeding to the standard fact collection, I find that the path of the call goes something like this:
PSTN -> gateway -> call manager-> directory number 1000 -> call forwarded to CTI route point 1001 -> 1001 call forwarded to Unity Connection voicemail -> voicemail greeting of unknown origin
If you’ve ever had to troubleshoot a similar issue, you probably already know where this is headed.
First test call: dial 1001, listen to greeting. Confirm correct greeting heard. Check.
Second test call: unforward 1000, let it go to voicemail. Surprise users by finding their cryptic voicemail greeting in record time. Yep, users of this voicemail box had unintentionally recorded 3 minutes of scratchy noises and dead air, somehow managed to enable it as their standard voicemail greeting, and all without being the slight bit conscious of the process. Amazing.
While this of course boggles the mind, it doesn’t actually fix the real issue here – the fact that users want callers to hear the voicemail greeting for 1001 when 1000 is called and 1000 is forwarded to 1001.
For those not familiar, Unity Connection – in this particular case 8.x – has a couple of options on how to handle forwarded calls like the ones we are dealing with here.
The default behavior of Unity Connection is to use the first number when dealing with incoming calls that have been forwarded. So in our case, even though 1001 is the directory number that forwarded to voicemail, the message for 1000 is being played out for the caller. You can change this behavior globally by going to System Settings -> Advanced -> Conversations -> scrolling down toward the bottom and checking the Use Last (Rather than First) Redirecting Number for Routing Incoming Call box.
It’ll look something like this:
The problem with this solution is that some people, including the users in this case, actually like routing to voicemail boxes based on the first number called, so changing the behavior globally isn’t the best way to make friends and influence people.
Instead you can create a Forwarded Routing Rule in Unity Connection that changes the behavior just for a single the directory number – and only when that directory number is a redirecting number.
You will want to navigate to Call Routing -> Forwarded Routing Rules -> Add New. The rule looks something like this:
You will then set where you want the call to go. You can direct the call to a Call Handler, a Directory Handler, a Conversation, or to a User with a Voicemail Box.
Lastly, you will click Add New under Routing Rule Conditions to create the match statement.
Your match statement should look something like this:
Be sure to save your condition and your routing rule, and voilà! Incoming calls to voicemail containing the forwarding number you specified will now follow the rule you created. And there will be much rejoicing. If only in your own head.
Published 5/29/2012
Amy Engineer 
Pretty good…Loved it ..
Thanks!!
Hi Amy,
Nice article !
As a French guy, maybe i can suggest to replace “viola” wich means “to rape” by “Voilà” 🙂
Have a Nice day
Ha! Thanks for the spell check, sad I missed that one! Corrected now! 🙂
This post helped me to understand what was going on in a couple of CUC related tickets I had and resolve the issue. Thank you and keep up the good work!
Awesome!! So glad it helped!!
Good Job Amy. From a future troubleshooting point of view, I would be tempted to use a mailbox mask for this to keep everything within CUCM, but I’ve always been a fan of Unity Conneciton’s interface.
Hi,
Trying to set this up in our environment so when a particular station RNA’s out to voicemail it goes to that stations voicemail, not someone elses. (I have another forum post here about it: https://supportforums.cisco.com/discussion/12253066/override-unity-connection-redirecting-and-last-redirecting-number-during).
Any idea why this isn’t working as intended?
Sounds pretty similar to the problem in this post, I think if you created a routing rule like the one I did, it could solve the problem. It’s a pretty straightforward way of making the call go to the box you want it to. You could also try a voice mail profile and mask the original number to the second number – but this would affect voice mail for that original number all the time. The Unity Connection routing rule allows you to direct the call based on seeing that redirected (forwarded) number.
Ok, so say I only want the call to go to the voicemail box for someone else when i CallForwardAll the phone to someone else. if my phone is not call forwarded I don’t want it to go to someone elses voicemail. that is what is happening now.
Right, so when you do the rule, you select “Forwarding Station in” – this will only apply then when the system sees the specified extension as the redirected number – the forwarding number, and only then will it take the action in the rule. So in your case, if you set up the routing rule that had Send Call to User with a Mailbox [6116 voicemail box] – and set the Routing Rule Condition to Forwarding Number is 6115 – then when it sees a call that the first redirecting number is 6115, it’ll do whatever the rule says to do. So calls for 6115 route normally unless they have been redirected and have 6115 as the forwarding number when the call gets to Unity Connection. I hope this helps…
Hi, I can get that scenario. Her’es the call flow 750-3311 –> DN 4231 (CfwdAll to 4230) –> DN 4230 No Answer –> 6100 (Unity Conn pilot) —> Forward Routing Rule (Forwarding Station IN 4231 –> greeting for 4230) —> I get 4230’s greeting.
If I turn off CallFwdAll on 4231, I still get 4230’s greeting.
Sorry for all the confusion and back and forth, this is making my head hurt. Is there any part of the call manager to unity connection SIP trunk that may be causing an issue?
hi matt
did you find a solution for your problem?
Hi, no we never got this working in our environment using the routing rules. what we ended up doing is allowing the DN to callfwd outside to the DID of the other line, so any forwarded call information would be removed by the PSTN carrier.
hummm, not sure why it is still seeing 4231 as the forwarding number when you have call forward turned off. I am not aware of any reason why the SIP trunk would cause this, but I am definitely curious. I’m pretty sure that when I have used this trick before it was on SCCP integrated voice mail servers. Do you have access to TAC? I would love to know what they say about it…
I have configured the same way as you mentioned above and my scenario as follows.
One PSTN number from E1 (XXXXXX525) 1010 (directory Number) 1020 ( CTI RP Num)
In unity connection 1020 (call handler)
Forward station (in) (1010)
When I try to call from outside network call disconnected with busy tone.
XXXXX525 tested with another extension and it worked. And call handler tested with internal extension worked fine.
Any idea to resolve this.?
Hummm, possibly a CSS issue? Haven’t run into this particular issue – check logs for errors, I’d definitely start there and see what the disconnect codes or messages are.
Very nice example. I understand now the forwarded routing rule !
hi amy, good to know there’s Voice engineer sharing their knowledge in the internet in casual way. make it easier to understand. Have a question, what does this function “Forwarded Routing rule” do any difference from normal Call Handler?
Thank you for posting this. Its an issue that often comes up on new installations and I hardly ever remember the location of that setting! Its a common issue that you’d think Cisco would have an easy to follow forum post or tech note.
Anyway, great blog!
This blog post has helped me multiple times thanks!
Amy, it’s never late to thank you, so here I am.Thank you!
Awww, much appreciated!! Thank you for reading!! 🙂
Spent 30 minutes trying to solve this problem and your easy-to-follow steps did the trick. Seems odd that there’s not a simpler forwarding option in CUCM by now. 🙂
Thanks!