Unity 4.0.4 Ring No Answer

[pbarman]

Unity 4.0.4 on Windows 2003 and using Exchange 2003.

Unity is configured for failover, so have two Unity servers.

CallManager 4.0.1 es30

Unity Pilot is 1900.

Unity ports are from 1901 to 1972

Problem:-

After processing random number of calls, Unity will lock the first two voicemail ports, 1901 and 1902. So, if you call Unity pilot now, you get RNA. If you call the ports individually, then calling 1901 and 1902 gives RNA; but 1903 onwards is answered by Unity just fine. Resetting the voicemail ports from CCMAdmin doesn't help. A restart of Unity will help resolve the problem.

If Unity is not restarted, and the first two ports are locked, then you place calls to Unity pilot and keep getting RNA. Eventually the Unity service, AvCsMgr, on primary Unity server will go down, and a red X appears on the Unity tray icon. At this point secondary Unity server should answer calls, but it doesn't pick up the call, and gives RNA simply. When you call Unity, you can see that the call is going to Unity secondary server, by looking at the name display for the voicemail port, but you just get RNA.

When primary Unity server comes back online (manual restart), then Unity again starts answering calls correctly, until a random time when the problem starts again.

This has been happening since install.

[Hin Lee]

Do you see errors or warnings on windows event logs such as dcom errors on the system event logs on the Unity server?

[pbarman]

Yes, there are a lot of exceptions shown on the applog as errors. Attached are the applog and system log.

Last time problem happened was on 11/8/04 at ~16:00 PST

[pbarman]

I am applying Unity 4.0.4 sr1 and will update here.

[tarun.pahuja]

Any luck after applying the update. I have to configure unity failover this weekend, just curious as it how yours went.

Also, i am slightly confussed about setting up unity failover in callmanager 4.x. Since Cisco introduced the concept of line group and line list for voice mail port access.

Did you follow cisco documentation while configuring the failover where they talk about 2 methods of doing it (recommended and non recommended)?

I was speeking to cisco TAC and they told me that i could use the line group and line list concept also to configure unity for faiolver as far as callmanagers go.

basically create two line groups ( group1--untiy1 voice ports and group2--- unity voice ports), and put then in the same route list, so if the first line group fails it sends the calls to the second line group.

Does it make sense? i am confussed my self.

any advice or suggestions would he highly appreciated.

Thanks,

[eschulz]

You should follow the appropriate CallManager 4.x Intgration Guide for Unity...

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_configuration_guides_list.html

I think you've got the basic idea already. Create two Line Groups, one for each server and put them in a single Hunt List.

Regards,

Eric

[jeff.singh_2]

We are having similar problems - Unity 404 SR1 with CCM4.1(2). We have followed the integration guides and get RNA when dialling Unity and ports begin to lock up.

Any suggestions?

Jeff

[jerake]

And I thought I was the only one...same setup, Unity 4.0.4 SR1 with CCM 4.1.2...anyone have any ideas or has anyone resolved this...?

TMH

[fmarotta]

I am having the same issue with unity 4.0.4 SR1 TSP 704b.

Has anyone found a fix to this?

[jm9393]

I am on 4.0.4 SR1 on W2K3. I'm experiencing the same problem with Unity ports locking up and getting RNA to the Unity server. Did anyone find a fix for this?

[jerake]

TSP 8.0.1b seems to have fixed this issue; it takes 30 seconds and a reboot. It fixed everything up for me.

TMH

[jm9393]

It didn't do the trick for me. :( Anyone else have any ideas? I have a TAC case open and will post a solution when we come up with something.

[mrmccann]

Just to be clear, TSP 8.0(1b) fixes issues that were instroduced in TSP 8.0(1). One of these issues involved Unity not answering calls. If you are seeing this type of issue using TSP 7.0(4b), it is a different problem.

[jerake]

I had port locking all over the place with 7.0.4b; TAC told me to upgrade to 8.0.1 to fix it, it did not. When 8.0.1b came out, I installed it right away, the problem was fixed. Now, my scenario isn't exactly the same as the original problem posted, but it did fix things for me.

This is the bug ID: CSCsb07764

Release Notes

Symptom:

A Unity voicemail port will sometimes use the call reference associated with a previously disconnected call with new calls received on the port. This will result in any input being ignored and sometimes calls will not be answered.

Conditions:

The following error message may be seen in the application log of event viewer:

Event Type: Error

Event Source: CiscoUnity_Miu

Event Category: Error

Event ID: 550

Date: 25.05.2005

Time: 1:25:35

User: N/A

Computer: unity-primary

Description:

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

EXPLANATION:

No reponse was received on port 2 while performing a blind transfer. 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 0x000009DC had a Failure on Port 2 in Method CAvMiuLine::Transfer(eMIU_XFER_RELEASE)

DESCRIPTION: Timed-out waiting for LINECALLSTATE_IDLE after lineBlindTransfer.

DETAILS:

HCALL: 0x00010A09

CallState: LINECALLSTATE_CONNECTED

DestAddress: 2002.

Workaround:

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

TMH

[jm9393]

My error is attached. Cisco recommended upgrading to 4.0.5 (which didn't fix the problem either) and removing W2K3 SP1 from the Unity server. My TAC guy also recommended removing W2K3 SP1 from the Exchange servers as well.

Is anyone using W2K3 SP1 on either the Unity or Exchange servers successfully?

Removing W2K3 SP1 didn't seem to do the trick either. We have not removed it from our Exchange servers, but that seems rather extreme.

The description for Event ID ( 535 ) in Source ( CiscoUnity_Miu ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 1, 0x0000121C, 1, CAvMiuWave::Play(), AvWav WavPlay failed with 0xFFFFFFFF,

IStream: 0x015DDAC0

HWAV: 0x00000020

WavState: WAV_STOPPED,

CallerID: 2498

CalledID: 2050

RedirectingID: Unknown

Origin: Internal

Reason: Direct

Trunk: 0, [16:09:58:644 - 0x00001218] Drop() - S_OK

[16:10:19:036 - 0x000010C4] LINE_APPNEWCALL(0x000103F3)

[16:10:19:036 - 0x000010C4] SetEvent(NewCall)

[16:10:19:036 - 0x000010C4] SetEvent(CallInfoArrived)

[16:10:19:142 - 0x0000121C] Answer() entered

[16:10:19:142 - 0x0000121C] lineAnswer(0x000103F3) - 0x000100AE

[16:10:19:142 - 0x000010C4] LINE_REPLY(0x000100AE | 0x00000000)

[16:10:20:081 - 0x000010C4] LINECALLSTATE_CONNECTED(0x000103F3 | Active)

[16:10:20:081 - 0x0000121C] WaitFor(0x000100AE | CONNECTED) - CONNECTED

[16:10:20:081 - 0x0000121C] Answer() - S_MIU_CONNECTED

[16:10:20:308 - 0x0000121C] Play() entered

[16:10:20:308 - 0x0000121C] WavOpen(0x015DDAC0) - 0x0000001F

[16:10:20:308 - 0x0000121C] WavGetLength(0x0000001F) - 15323

[16:10:20:308 - 0x0000121C] WavClose(0x0000001F) - 0x00000000

[16:10:20:308 - 0x0000121C] WavOpen(0x015DDAC0) - 0x00000020

[16:10:20:308 - 0x0000121C] WavSetChunks(0x00000020) - 0x00000000

[16:10:20:308 - 0x0000121C] WavSetPosition(0x00000020 | 0) - 0

[16:10:20:308 - 0x0000121C] WavSetVolume(0x00000020 | 50) - 0x00000000

[16:10:20:308 - 0x0000121C] WavSetSpeed(0x00000020 | 100) - 0x00000000

[16:10:20:338 - 0x0000121C] WavPlay(0x00000020) - 0xFFFFFFFF,

For more information, click: