cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12788
Views
10
Helpful
19
Replies

Unity Connection 8.0 transfer calls to voicemail goes to sign in

voicewiztim
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

19 Replies 19

Brad Magnani
Cisco Employee
Cisco Employee

Hi,

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,

Brad

Randall White
Level 3
Level 3

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.

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

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!

Hi All,

I came across the following link, sharing it with you all.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00800dea82.shtml

- Atul

Please rate this post, if you find it useful.

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.

Hi Peter,

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

-- Atul

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

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

Nice ... worked like a charm.

Hi Brian

I am using Unity Connection 11.0 ...Wherein the Integration is done via a SIP trunk

So there is no CTI RP used

Can i know how you got it working and what ver of Unity were you using ?

Hey Randall, hope you're still out there.

Running CM 8 and sounds like this is the issue I am trying to help a user with.  They answer someone elses phone and try to put them into their voicemail but the caller is asked for a pin.

I checked my CTI Route point under device and the *XXXX is setup with a description of "Direct Transfer to VM".  I blanked out that out just to test but it still asks for a pin.

Any ideas what I might can check?

All I can suggest is you set up the Remote Port Status Monitor tool (ciscounitytools.com).

The RedirectingId= needs to match the extension of the voicemail box you are trying to reach.

If it is asking for a PIN, it is trying to send you to signin for a particular voicemail account.

Using Exchange 2010 as our VM.   Is that tool still available?