Unity Connection 8.0 transfer calls to voicemail goes to sign in

Unanswered Question
Nov 22nd, 2010

Setting up the regular CTI RP --> #XXXX --> Voicemail Profile mask XXXX

The calls gets to Connection and the user calling from an IP Phone to IP Phone is prompted to sign in. Without creating a call routing rule for each user how can this be disabled? This was never the default feature in Connection 7 and below.

Port mon shows reason - FwdUnconditional --> Sign In

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Bradford Magnani Mon, 11/22/2010 - 19:23


The call routing rule logic hasn't changed from 7.x to 8.x.  It's sending you to sign in because it's recognizing the passed in digits as matching either a subscriber's primary extension, or someone's alternate extension.  Port Monitor isn't always the most helpful in showing what the incoming digits are so I usually recommend pulling the Connection Conversation Manager traces after setting the SCCP/SIP (depending on what protocol you're using) Call Control Macro traces under Connection Serviceability and double check to see what is actually arriving at UC and go from there.

Hope that helps,


Randall White Tue, 05/24/2011 - 12:28

I ran into this in UCONN 8.5.1, so I'll post the solution in case anyone else hits it.

Go to the CTI Route Point and remove any reference to the words "voice" or "mail" in the alerting or display names (no, I'm not joking).

If you are hitting this, check Port Status Monitor. If RedirectingID= is blank, then you will hit the default Direct Routing rules.

Once you clear out the Alerting and Display names from the CTI-RP, the RedirectingID should equal the called number.

voicewiztim Tue, 05/24/2011 - 12:56

will have to try that! i ended up finding out the # was causing issues and changed it to *XXXX

Peter Mirabile Tue, 05/31/2011 - 10:38

I just ran into this same even on Unity Connection 8.5.1. I followed what Randall recommended as my alerting name was "voicemail", Once I removed it, the calls came in to the Call Handler from outside without a problem. Working on this with TAC to see why this would happen. Thanks Randall!

Peter Mirabile Wed, 06/01/2011 - 05:17

I saw the post as well which is from 2006. Who is running CCM 3.x? I would think that Cisco would have something more up to date. We are in the process of migrating from Unity 5 to Unity Conncetion 8.5.1 and I so no reference to this in any of the documentation for 8.5.

Atul Khanna Wed, 06/01/2011 - 07:27

Hi Peter,

I do agree the CCM version is old. Please ignore the version and follow the configuration, its still the same.

-- Atul

Randall White Wed, 06/01/2011 - 08:36

Hi Atul,

Thanks for the memories, does anyone else remember when CallManager ran on SQL7?

I have used that configuration many times over the years, so I was surprised when it didn't work on UCXN 8.X

In my case, the config was a CTI-RP with a DN of *XXXX (CfwdAll to Voicemail), and the VM Profile masked to XXXX. I also had "voicemail" in the alerting and display names. One of my co-workers (Ron Smith) suggested I remove any reference to voice or mail in the alerting or display names.

The log file from Remote Port Status Monitor shows what's going on. Here is a call from 4700 to *4725, with the word Voicemail in the alerting & display name. Notice that RedirectingId= is blank. My understanding is that if the RedirectingId is unknown, the call will hit the default Direct Routing rule and will be sent to sign in (if CallerID is known - see the second line, AttemptSignIn).

CallData, 1, CallerId=4700, CalledId=4725, RedirectingId=, Origin=16, Reason=1, CallGuid=94C6637CE813490FAC197D649AE51913, CallerName=Receptionist, LastRedirectingId=, LastRedirectingReason=1024, PortDisplayName=PhoneSystem-1-001
Application, 1, 4700, AttemptSignIn
State, 1, 4700, State - AttemptSignIn.cde!Dummy


Here is a successfull call, the only difference is that "voicemail" was removed from the Alerting & Display names on the CTI Route Point DN. Notice that the CalledID is the same as the RedirectingId, and that the mask did it's job and stripped the *:

CallData, 1, CallerId=4800, CalledId=4725, RedirectingId=4725, Origin=16, Reason=1, CallGuid=28F99E4..

Thanks, R

Atul Khanna Wed, 06/01/2011 - 09:04

Hi Randall,

I faced the same issue two days back.Output of the port status monitor was exactly the same.

While researching I came across that link, Change of Alerting and Display name resolved the issue.

- Atul

Liz Bentler Sat, 11/19/2011 - 22:26

For 2 and a half days we have been troubleshooting and escalating this exact problem with TAC and i just found this, removed the name and we are golden.  Thank you so much!!  And cisco, COME ON!!

bmarkel123 Wed, 05/16/2012 - 13:27

I ran into a similar issue but the trouble was an overlap in the dial-plan.

UCM 8.6(2a)

Unity Connection 8.6(2a)

CTI Route Point extension 8021 CFA to VM

Call Handler extension 8021

11:29:21, New Call, CalledId=8021,  RedirectingId=,  Origin=16,  Reason=1,   CallGuid=14552B0CA2F74E91A3E8C6948D55A04B,  CallerName=,  LastRedirectingId=,   LastRedirectingReason=1024,   PortDisplayName=PhoneSystem-1-001,[Origin=Unknown],[Reason=Direct]

11:29:21,  AttemptSignIn

Calls to the CTI Route Point extension are passed to Unity Connection properly.  My call was being sent to Sign-In because there is a VM Port using 8021.  After troubleshooting this I discovered UCM is partition aware; setting my callling search spaces properly I can route the call to the CTI RP instead of a VM port.  Unity Connection is not partition aware.  So with two objects sharing the same DN (8021 in this case) Connection choose to select the VM port instead of the Call Handler.

Creating a Direct routing rule for 8021 to send callers to the Call Handler's greeting was an effective work-around but one had to be created for each Call Handler sharing a DN with a VM port.  Moving things around (either the Call Handler DN's or VM port DN's) fixed my trouble.

ghinson Mon, 05/12/2014 - 20:21

Just hit the same "bug" in version 9.1.2 of CUCM. Was glad to have found this post - I can't believe we are still running into this issue in the 9.x code set.


This Discussion

Related Content