TSP REL 8.0(1)

[sduchesne]

Hi,

Call Manager: 3.3(4)

Unity: 4.0(4) SR1

TSP: 8.0(1)

We upgraded the TSP from release 7.0(4) to 8.0(1) to fix the problem that corresponded to CSCef29258 in the release notes for TSP 8.0(1) but since then we have problems if we do not activate the supervise transfer .For example , I have used internet subscribers for the transfer or the dial by name from a call handler since the user don't have a mailbox. If the phone is busy , the port is held up,when the transfer is not supervised in the configuration of the Internet Subscriber, if I programmed the transfer as supervised it follows the programming after the greeting. It seems like Unity don't recognise the busy state of the phone, with the no answer it works.

I have about 2000 internet Subscribers and I wouldn't like to change them all with supervision considering that it would occupy the ports.

Does anybody have a solution, thanks in advance for your help.

[mrmccann]

Do you have the phones configured to forward busy back to Unity?

[sduchesne]

No, most of the phones have no forward busy.

[mrmccann]

When Unity does a release transfer, it is handing the transfer off to the phone system. If the target phone is busy, Unity has no way of knowing this. You need to program the phones to forward back to Unity on no answer/busy if you want this to work correctly.

If you're wondering why this worked before the upgrade to TSP 8.0(1), previously Unity actually was able to detect busy on a release transfer and "pull" the call back. However in TSP 8.0(1) we made some changes to the TSP for other bug fixes that forced us to remove this "feature". This "feature" really just compensated for a misconfiguration, which is what you have. Set your phones to forward back to Unity, and your release transfers should work as expected once again.

[kdamisch]

I'll add to this....

We have CCM 4.1(3)SR1 and Unity 4.0(4)SR1. We were at 4.1(2) and when I upgraded to 4.1(3)SR1, I also updated the TSP to 8.0(1). At this point, here is what happened.....

A user sets his IP Phone to CFwdAll to voicemail. A PSTN call comes into CCM CTI Route Point, which we have setup to go to Unity to play a call handler greeting. During the greeting, we dial the extension of the IP Phone that has CFwdAll set to go to voicemail. This subscriber's account has the call transfer type set to "Release to Switch". The call drops. If we set the call transfer type to "Supervise Transfer", the call completes successfully and the PSTN caller is sent into the subscriber's voicemail greeting.

Is there going to be a fix in the TSP? TAC told me it was because Unity "seems" to have a problem with the call originating in Unity (in this case during the opening greeting), then releasing to switch (send to CCM), then coming back into Unity on another voicemail port (CFwdAll set to voicemail). I guess the TAC engineer didn't know about this TSP bug, otherwise he probably would have mentioned it.

Kevin Damisch

kdamisch@erbs.com

[mikehunt140]

We are having similar problems I think.

We upgraded to ccm 4.1.3 and unity 4.0.5, with "release to switch", with enabling diagnostics I am getting Event ID 559

Cisco Unity's telephony component has encountered a serious error.

EXPLANATION:

A serious failure has occurred on port 27 while dropping a call. In some cases, further calls on this port will not be handled correctly.

TECHNICAL DETAILS:

Thread 0x00001584 had a failure on port 27 in method CAvMiuLine::Drop()

and Event ID 549.

Cisco Unity's telephony component has encountered a serious error.

EXPLANATION:

No reponse was received on port 27 while waiting for an incoming call to be answered. This is a serious failure, and most likely parties involved in the call will be disconnected. In some cases, further calls on this port will not be handled correctly.

TECHNICAL DETAILS:

Thread 0x00001584 had a failure on port 27 in method CAvMiuLine::Answer()

Is anyone else getting this

Supervise transfer works but the call says coming from Voicemail, until the phone is anwsered on the destination phone. If it doesn't get answered, missed calls come from Vmail

Is anyone else experiencing this??

Richard

[d.albertson]

I had this same issue with TSP 8.0(1) adn CCM 4.1(3)sr1

Randomly, calls going to Unity Call Handlers would just ring no answer and Subscribers accessing voice mail via phone would not have their DTMF digits recognized.

I found this about it:

===================================================

CSCsb08723 Bug Details

Headline TSP ignoring StationKeypadButtonMessage due to stale call reference

Product unity Model

Component telephony Duplicate of

Severity 2 Severity help Status Verified Status help

First Found-in Version 4.0(5) First Fixed-in Version 4.1(0.25) Version help

Release Notes

Symptom: Unity does not respond to DTMFs entered by the user.

Condition: Unity with TSP 8.0(1) installed, integrated with CallManager. On an affected port, the problem will occur continuously until the port is reset.

In the TSP traces, a message similar to the following indicates the problem is occurring:

[Device 5] Ignore StationKeypadButtonMessage (callReference=33655518) since it's not for the ActiveCall=33654548

Workaround:

To clear the problem on an affected port, reset the port from CallManager admin interface. This can also be accomplished by restarting Unity.

The fix for this defect is contained in TSP 8.0(1b)

===================================================

Upgrading to TSP 8.0(1b) solved the problem.

Dave

[eschulz]

The lastest version of the TSP available for download on CCO is 8.0(1b). It fixes serveral issues found in the original 8.0(1) release.

Beyond that, the symptoms you describer sound similar to CSCsb27128. Your TAC engineer should be able to verify this is a match and, if so, provide an ES version of the TSP to address it.

-Eric

[kdamisch]

I've installed 8.0(1b). Didn't fix it. Call disconnects when the call comes from Unity, goes back CCM when caller dials and extension. The phone is CFwdALL to VM. Call goes back into Unity, but drops.

You gotta love bug fixes that create other bugs. :)

Kevin Damisch

[mikehunt140]

Yes I have 8.0(1b) installed too. My setup that Unity does a release to switch to a huntgroup / pilot point, and I have a unity subcriber as "always route member" I only get this problem when all hunt group members are busy or logged out. Therfore unity "hairpins" the call so to speak. Restarting Unity does work for for 20 30 tranfers.. but then the problem starts again. I have contacted TAC and currently giving them traces etc.

Their workaround was to use "supervise transfer" but as i said before this gives the undesirable behaviour of the caller ID being "Voicemail" until the call is answered

If I get an answer fix from TAC I will let you know.

Richard

[joe.conger]

There is an ES 3 for TSP 8.0(1)b that may fix your problem. ES 3 contains the following fixes:

This includes patches for 7 defects in version 8.0(1b) of Cisco Unity-CM TSP.

1) CSCsb23638 - A Cisco Unity installation integrated with Cisco CallManager with Unity TSP version 8.0.1b may stop answering calls and ring no answer until being forwarded to the next available port (which also may trigger a Unity failover, if configured).

2) CSCsb20680 - With Cisco Unity TSP 8.0.1b, after a failed blind transfer, a voicemail port may not answer when called.

3) CSCsb19146 - After a blind transfer attempt by Cisco Unity, the caller may be placed on hold indefinitely. The call is not reverted back so the caller can leave a message.

4) CSCsb19050 - End subscribers may receive a blind transfered call from Unity. However, when answered, there is no one on line. If the call is unanswered and rolls back to Unity, two ports are conference together and end up timing out after 10 seconds of no audio recording.

5) CSCsb27041 - TSP failback: increase TSP retries on CCM registration timeouts.

6) CSCsb27128 - Unity Disconnects Blind Transfers To Devices Forwarded ALL To Voicemail

7) CSCsb42730 - Unity ports may not clear immediately after a PSTN caller hangs up. This may also result in blank messages delivered to subscribers

[Leonlei]

I am having the same issue on Unity 4.0(5) with CCM 4.1(3)sr1. TSP is 8.0(1b). I don't have CFwdAll to voicemail on phones' setting,just for no answer and busy. Actually this issue is really impacting my mobil users, they only have CTI ports(for softphones) on CallManager. In most of time, those CTI ports are in failure state, so I think from CCM point view, it same as CFwdAll(I could be wrong). I am going to upgrade TSP to 8.0(2) which contains fixes.