Release to Switch Never Forwards to Voicemail

[luchtcm]

All,

We had, up until recently, a Unity 3.1 and CM 3.1 system integrated. The CM version was bumped to 4 last weekend. Since then, the following behavior has been noticed:

When a caller calls in from the outside, they get the automated attendant. If the subscriber is logged in, and release to switch is set for the user, everything works great. If the subscriber is not logged in, however, and the release to switch is set for the user, you hear nine rings and then the call is terminated.

It did not work this way before. Before the upgrade, whether you were logged in or not, it worked the same way.

In the meanwhile, the CM administrator has set the supervise transfer setting for all users, but the downside to this is that the user no longer see caller ID information when being transfered from the automated attendant.

Anyone have any ideas what we can do to fix the situation? I just want the functionality we had before.

Thanks in advance,

Craig

[Ginger Dillon]

Hi Craig -

You didn't mention which 3.1 version you are running, but I would make sure you are running a compatible TSP version for Unity and CallManager 4.x - http://www.cisco.com/en/US/customer/products/sw/voicesw/ps2237/prod_pre_installation_guide09186a00800f1e98.html

I'm not sure if this could impact you or be related to the problem you are experiencing, but the voice port configuration for Unity with CallManager 4.x changed to take advantage of the hunt and line group features in 4.x. See this hyperlink - http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00802deb09.html#wp1032198

to see if it applies to your environment.

Best wishes,

Ginger

[luchtcm]

That's not something that I had thought of. Since it requires a reboot, we're going to try upgrading the TSP tonight. We were running a 6.x version which is not supported by CM 4.x.

Thanks for the insight. I'll let you know how this turns out.

[luchtcm]

While the upgrade went smoothly, it did not fix the problem. I've broken down and called TAC to have them look at the issue.

To further complicate things, this behavior only happens when the call is coming in from the outside. If an internal user calls the extension of a user who is not logged in, the call goes to voicemail as it should.

*sigh*

[luchtcm]

Just a quick update on this. TAC has been working on the issue for two weeks now without resolution. So, my guess is that it's not an easy fix, whatever the issue is.

Internally, if you dial the voicemail pilot and then dial the extension, it never goes to voicemail, just like if you were to call in from the outside.

[eschulz]

My guess would be that when Unity transfers the call to (off-line) x212, that call gets immediately forwarded back to another Unity port. This new incoming call goes unanswered because it shows up with calling number matching another Unity port. With supervised transfers this does not pose a problem because the transferring port eventually recalls the transfer and sends the caller to the appropriate greeting. But with release transfers, the first Unity port drops out of the picture and the call continues to ring, unanswered at the second Unity port.

Unity is trying to prevent what it thinks is a looped call from itself. You can disable this feature in a few ways. With Unity 3.1, the simplest thing would be to remove extension numbers from the Unity SA Ports page. You'll only need to do this for ports that are handling inbound calls. Ports that are dedicated for dialout (notification, MWI, TRaP) can keep the extension labels. This will allow Unity to continue to block looping of outbound calls from those ports.

Starting with Unity 4.0(1), we do this check automatically. Unity will only reject calls when the Caller ID matches a port that is configured for outbound capabilities only. If the port handles incoming calls, and hence transfers, then Unity will accept the incoming call.

Of course, I don't know the full details of your case so this might not be your issue at all, just a guess.

Regards,

Eric