Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

I get a port failure and reset when turning the MWI on and off. It still seems to work now and then even though the warning messeges in the event viewer say the port failed. Looks like the port trying to turn on or off the lamp tries and fails and reconnects to CM. Sometimes the lamp goes out sometimes not?

Error messages as follows :

Component Miu : Thread 0x00000A4C had a failure on Port 4 in Method CAvTSP abstraction: Selsius_SetMWI{}

DESCRIPTION HardFailure from line DevSpecific

DETAILS:

DestAddress: 2000

Messages: 0

State: OFF

ErrorCode: 0x00000102

Next error code reads:

Failed to set message waiting lamp for {username} ext 2000, switch 0. cluster 0, reason SetMWI failed with 0x80004005

Your thoughts would be greatly appreciated.

Doug Heppler

Bell Canada

23 REPLIES
Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

That "102" is a timeout, and that timeout is probably a timeout that happens after the TSP dials the MWI DN. The TSP is waiting for a specific skinny message to come back from CCM after dialing the MWI DN.

Is there any chance that the MWI DN overlaps with another dial pattern? What is the MWI DN?

We can start by looking at the AvSkinnyTSP traces when this happens. If you can set all of them with the exception of "keepalives", repro the problem and then post those traces, I can take a look.

This would show the skinny communication b/w Unity and CCM for that MWI.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Hi,

Thanks for responding, My MWI DN for on is 4001 and 4000 for off. As far as I know I have no overlapping dial pattern. I have no dial pattern set up for internal DN's, they work fine between extensions. Do I need to create a pattern for the internal DN's and MWI DN's?

Attached is the log file I created, not sure if I did it correctly but I can see the errors.

Doug

Moderator Note:

Trace removed due to size.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Those are the AvCsMgr traces. We'll need to look at the AvSkinnyTSP traces with the AvSkinnyTSP diagnostics enabled.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Sorry I'm taking so long, first time in the log file generator tool.

I've hopefully got the log file your looking for this time.

Doug

Moderator Note:

Trace removed due to size.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,11) [Thread 0x0000065C] [Device 8] TSPI_lineDevSpecific hdLine 20867880.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,18) [Thread 0x0000065C] [Device 8] CAvTapiLine::SetMwi: szExtension 2000 fMWIon 1.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x0000065C] [Device 8] CSkinny::SetMWIOn szMWIOn szExtension.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::SendOffHookWithCgpn 2000.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigits 4001 No Delay.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 4.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 0.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 0.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 1.

13:37:23:718 (CiscoUnity_TSP,116,SkinnyTSP,16) [Thread 0x00000838] [Device 8] CAvSkinnyController::WaitForEvent signalled LineTimer.

Yup, it's a timeout. Above here, it shows that after dialing the MWI, it has waited 30 seconds for the skinny message that it wants; it never got it. The TSP is waiting for the "proceed" skinny call state message to come back after dialing that MWI DN.

I guess it's off the CCM logs to see why that message isn't coming back. Or, if it is an overlapping dial plan, and the digit "#" is a terminator for a dial string, you could try changing the MWI settings on Unity's TSP to be 4000# and 4001#. That'll require a restart of Unity.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Great... Thanks! Ok a timeout because Call Manager isn't responding to the TSP as I understand it. I've set the TSP's to be 4000# and 4001# and rebooted the system but I still get the same events. FYI, One time all the configured ports disconnected and reconnected {all four, only four configured so far} but mostly it seems the last two ports 3 & 4 disconnect. I assume that Unity goes to the last port to do MWI {4 in my case} and goes to 3 when it can't find port 4.

Since I'm in the primary build phase, I have only two dial patterns created :

9.1XXXXXXXXXX

9.XXXXXXXXXX

I'll try to look at the Call Manager logs and see if I can get some info there

Thanks,

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

I've looked into the Call Manager logs and I found the following:

------------------------------------------------------------------------------------------

03/18/2003 16:44:14.803 Cisco Messaging Interface|kVMDNConfigurationError - Voice-mail DN for CMI invalid. Invalid VoiceMailDN: App ID:Cisco Messaging Interface Cluster ID:ccm-Cluster Node ID:ccm|<:CCM-CLUSTER><:CCM><:ALARM>

------------------------------------------------------------------------------------------------

I've deleted all 4 Voice Mail ports in CM and created 8 new ones {used to have 4}. I still get the last two ports disconnecting, port 8 and 7 now instead of 3 & 4

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

That diag makes me think that the CMI is installed and configured on CCM. For Unity's use, it shouldn't be.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

There was a default CMI set up in Call Manager and I deleted it. Rebooted both the Unity and Call Manager, still getting the same warning in event viewer {ports disconnecting} however the MWI lights seem to turning on and off everytime regardless.

You can dial the MWI DN from a phone and turn on and off the MWI manually, this should rule out a dial pattern issue.

Any Ideas?

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Watching the Unity Status Monitor, port monitor as I leave a message: I see port 1 answer the voice mail call then I see port 8 dialing the MWI and I see the light come on the phone. The port monitor keeps going for the full 30 seconds on port 8 even though the lamp has come on the phone, it stops and a few seconds later it tries to dial the MWI again on port 8 even though the lamp has been lit.

It's as if Unity has called the MWI DN and Call Manager has lit the lamp but Unity doesn't know this and keeps trying again and again to light the lamp?

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Sounds like that "proceed" skinny message still is not coming back. Do the CCM and AvSkinnyTSP diagnostics look the same as when the CMI was enabled?

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

After I removed the Call manager CMI configuration, I can't perform that trace as it's no longer an option. I've attached a new AvSkinnyTSP log.

Thanks,

Doug

Moderator Note:

Trace removed due to size.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

oliviers is correct in that CMI is not used for Unity - Please disable this service. Hopefully disabling this service will solve the timeout issue.

What oliviers is looking for is detailed Cisco CallManager (ccm) traces to correspond with the AvSkinny traces. We need to see why CallManager is not send the call proceeding signal back to Unity for sucessful MWI. A snippet of the MWI setting from both servers would be useful.

when you dial the MWI on DN from the phone, does the light turn on right away or does it take around ten seconds?

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Hello,

I've tried deleting the CMI from CM and rebooted both the Call Manager and the Unity servers and I have the same trouble.

Can you provide me with more direction on which trace is required from the Call Manager as with the CMI deleted that trace is no longer an option in Call Manager?

I'll post you the information from the MWI settings from both servers later. I've gone over those settings a few times and researched settings info on the Web but they seem ok.

Most times the MWI light comes on right away once the message is sent but the odd time it does take a few seconds {5-10}. The odd time it does not light at all, more often if there is an issue, it's because te MWI light won't go out after you clear the messages. When this happens and I send a new message and clear that one the light will go out. Also, you can turn it off and on no problem by dialing the MWI DN's.

Thanks,

Doug

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

I can explain why the light does not go out. It's because Unity thinks that the attempt to turn it on never worked (never got that proceed, right?). Unity will keep track of the status of the lamp. At this point, Unity will think that the lamp is off; it thinks that because it believed the previous "on" attempt failed. When the messages are cleared out, Unity doesn't bother to turn the lamp off, because it thinks the lamp arleady is off.

Fixing that lack of proceed should take care of both of those issues.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

We will need to look at detailed Cisco CallManager traces from the CallManager that has the test phone registered to it and from the CallManager that has the voicemail ports registered. They are usually the same server.

In order to enable the "DETAILED" CCM traces, goto CCMAdmin>Application>Cisco CallManager Serviceability and select Trace>Configuration. Then select the server to which the device is registered. Then select the Cisco CallManager service. Then hit the "Set Default" button. Then change the "Debug Trace Level" to "DETAILED". Then hit the "Update" button.

Make sure there are no new messages in the subscribers mailbox and that Unity doesn;t think there are new messages from the Subscriber > Messages screen. Plasce a test call leave a message. Wait long enough for Unity to light the light and retreive the message. This will show us both functions.

You can then gather the CCM traces from the following folder.

C:\Program Files\Cisco\Trace\CCM\

Make sure you view this with the details option. Sort by date and collect the current file of the filename format ccm000000x.txt.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Hello,

Attached is the requested trace. Thanks for providing exact detail on how to obtain the trace, very helpful. Hopefully I've captured what your looking for. The test message I created following your instructions worked ok, light on, light off. However once again I did observe the port monitor in Unity and once again I saw port 8 trying to call the MWI DN over and over. Also, the event viewer in Unity shows port 8 disconnecting and reconnecting to Call Manager. It's the same server that has the voice mail ports and the test phone registered to it.

Good luck and thanks again for the detailed instruction

Doug

Moderator Note:

Trace removed due to size.

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Hello,

Attached is the requested trace. Thanks for providing exact detail on how to obtain the trace, very helpful. Hopefully I've captured what your looking for. The test message I created following your instructions worked ok, light on, light off. However once again I did observe the port monitor in Unity and once again I saw port 8 trying to call the MWI DN over and over. Also, the event viewer in Unity shows port 8 disconnecting and reconnecting to Call Manager. It's the same server that has the voice mail ports and the test phone registered to it.

Good luck and thanks again for the detailed instruction

Doug

Moderator Note:

Trace removed due to size.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Feel free to send the trace directly to me. I will take a look when I get a chance. Please provide the DN of the phone you left the message for and your MWI on and MWI off DNs.

send to kthorngr@cisco.com

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Took a look at the trace and here is what I found:

When VM port 8 dials MWI on, CallManager immediately places the call. The log has this "PotentialMatches=NoPotentialMatchesExist" which means that there is only one match and that there are no other potential matches. This menas that there are now overlapping DNs for MWI on.

Then we see CallManager send a call state 12, which is call proceeding to the VM port. This is the indication to Unity that MWI was successful.

StationD: 6eb8e18 CallState callState=12 lineInstance=1 callReference=16777776|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

Then we see CallManager signal Unity VM port 8 to go OnHook

StationD: 6eb8e18 CallState callState=2 lineInstance=1 callReference=16777776

We never see the Unity port signal that it has gone OnHook.

Then there are three sets of keepalive messages from Unity port 8 and keepalive ACKs from CallManager.

Then Unity timesout the port and unregisters:

03/22/2003 12:01:29.131 Cisco CallManager|***** StationInit - Socket Broken. DeviceName=Unknown, TCPHandle=0x6eb8e18, Socket=0x73c, IPAddr=192.168.0.104, Port=0x9ec, Device Controller=[0,0,0]|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/22/2003 12:01:29.131 Cisco CallManager|StationInit - StationCloseReq received: 0x6eb8e18|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/22/2003 12:01:29.131 Cisco CallManager|StationInit - Closing Station connection DeviceName=CiscoUM1-VI8, TCPHandle=0x6eb8e18, Socket=0x73c, IPAddr=192.168.0.104, Port=2540, Device Controller=[1,92,66]|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/22/2003 12:01:29.131 Cisco CallManager|Device UnRegister deviceName : CiscoUM1-VI8|<:CCM-CLUSTER><:CCM>

It seems that Unity is either not getting the TCP messages from CallManager or it is not listening to them.

- Please look in your Application Event log on the Unity server to see what the message is when the voicemail ports have this issue.

- What TSP version are you running on the Unity server?

Step 1 Browse to the WinNT\System32 directory.

Step 2 Right-click AvSkinny.tsp, and click Properties.

Step 3 In the Properties window, click the Version tab.

Step 4 In the Item Name list, click Product Version. The Cisco Unity-CM TSP version is displayed in the Value window.

- We will need to look at both detailed ccm traces and AvSkinny traces for a test call. On the Unity server make sure you enable all Skinny traces including keepalives. Once doen with the test please turn off at minimum the kSkinny keepalive trace.

Go ahead and forward those along with the App Event log expoarted in evt format. I will look at them when I get a chance.

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Took a look at AvSkinny traces from Doug and found what looks like an issue where Unity sends the off-hook with cgpn message to CallManager then dials the MWI digits before receiving the off-hook message from Callmanager. Dou is going to send a new set of both ccm and AvSkinny traces to compare the two.

Are their any known issues with Unity send the digits too soon? Here is the snippet of the trace:

11:43:19:755 (CiscoUnity_TSP,116,SkinnyTSP,22) [Thread 0x00000BDC] [Device 12] CAvSkinnyController::GetLine: hdLine matches returning m_pTapiLineHandler 013EC3A8 .

11:43:19:756 (CiscoUnity_TSP,116,SkinnyTSP,11) [Thread 0x00000BDC] [Device 12] TSPI_lineDevSpecific hdLine 20878472.

11:43:19:755 (CiscoUnity_TSP,116,SkinnyTSP,18) [Thread 0x00000BDC] [Device 12] CAvTapiLine::SetMwi: szExtension 2000 fMWIon 1.

11:43:19:756 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x00000BDC] [Device 12] CSkinny::SetMWIOn szMWIOn szExtension.

11:43:19:755 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000BDC] [Device 12] CSkinny::SendOffHookWithCgpn 2000.

11:43:19:756 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x00000BDC] [Device 12] CSkinny::GenerateDigits 2101 No Delay.

11:43:19:755 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000BDC] [Device 12] CSkinny::GenerateDigit: button = 2.

11:43:19:756 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000BDC] [Device 12] CSkinny::GenerateDigit: button = 1.

11:43:19:755 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000BDC] [Device 12] CSkinny::GenerateDigit: button = 0.

11:43:19:756 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000BDC] [Device 12] CSkinny::GenerateDigit: button = 1.

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyController::WaitForEvent signalled Data.

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::ProcessData.

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::GetMessage: dwSize = 2048.

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CSkinny::ProcessPacket: dwSize = 24.

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,12) [Thread 0x00000A24] [Device 12] Incoming Skinny Message: StationSetLampMessage: stimulus = 9 (Line) stimulusInstance = 1 lampMode = 2 (LampOn).

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,24) [Thread 0x00000A24] [Device 12] CSkinny::SignalSetLamp stimulus = 9 (Line) lampMode = 2 (LampOn).

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyController::WaitForEvent signalled Data.

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::ProcessData.

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::GetMessage: dwSize = 2048.

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CSkinny::ProcessPacket: dwSize = 28.

11:43:19:771 (CiscoUnity_TSP,116,SkinnyTSP,12) [Thread 0x00000A24] [Device 12] Incoming Skinny Message: StationCallStateMessage: callState = 1 (OffHook) lineInstance = 1 callReference = 16778416.

11:43:19:772 (CiscoUnity_TSP,116,SkinnyTSP,24) [Thread 0x00000A24] [Device 12] CSkinny::SignalCallState: callState = 1 (OffHook).

New Member

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

Euh ..

By any chance ..

Take a look at Partition membership .. and CallSearchspace on VoiceMail Port .. and on MWI .

Martin

TELUS

Cisco Employee

Re: AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

I have reviewed the CallManager and Unity traces. CallManager is processing the call as expected and sending the call proceeding (callState=12). Here is the snippet of the ccm trace:

03/31/2003 18:48:29.472 Cisco CallManager|InboundStim - StationOffHookWithCgpnMessageID CallingPartyNumber=2000 CallingPartyVmbx= tcpHandle=0x6dafb2c|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationD: 6dafb2c StationOutputDisplayText don't need to send, because mIsALegacyDevice = 0|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationD: 6dafb2c SetLamp stimulus=9(Line) stimulusInstance=1 lampMode=2(LampOn).|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationInit: 6dafb2c KeypadButton kpButton=2.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationInit: 6dafb2c KeypadButton kpButton=1.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationInit: 6dafb2c KeypadButton kpButton=0.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.472 Cisco CallManager|StationInit: 6dafb2c KeypadButton kpButton=1.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c CallState callState=1 lineInstance=1 callReference=16777812|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c DisplayPromptStatus timeOutValue=0 promptStatus='Enter Number' content='Enter Number' lineInstance=1 callReference=16777812 ver=0.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c SelectSoftKeys instance=1 reference=16777812 softKeySetIndex=4 validKeyMask=-1.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c ActivateCallPlane lineInstance=1.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c StartTone tone=33(InsideDialTone), direction=0.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c StopTone.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|StationD: 6dafb2c SelectSoftKeys instance=1 reference=16777812 softKeySetIndex=6 validKeyMask=-1.|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|Digit analysis: match(fqcn="3107", cn="2000", pss="partion-1", dd="2")|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.482 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: match(fqcn="3107", cn="2000", pss="partion-1", dd="21")|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: match(fqcn="3107", cn="2000", pss="partion-1", dd="210")|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: match(fqcn="3107", cn="2000", pss="partion-1", dd="2101")|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|Digit analysis: analysis results|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|StationD: 6dafb2c CallState callState=12 lineInstance=1 callReference=16777812|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

03/31/2003 18:48:29.492 Cisco CallManager|StationD: 6dafb2c CallInfo callingPartyName='Voicemail' callingParty=3107 cgpnVoiceMailbox= calledPartyName='' calledParty=2101 cdpnVoiceMailbox= originalCalledPartyName='' originalCalledParty=2101 originalCdpnVoiceMailbox= originalCdpnRedirectReason=0 lastRedirectingPartyName='' lastRedirectingParty= lastRedirectingVoiceMailbox= lastRedirectingReason=0 callType=2(OutBound) lineInstance=1 callReference=16777812. version: 0|<:CCM-CLUSTER><:CCM><:1><:192.168.0.104><:CISCOUM1-VI8>

The Unity trace shows that Unity doesn't receive the call proceeding message, or atleast is not seen in the trace.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,22) [Thread 0x00000C9C] [Device 12] CAvSkinnyController::GetLine: hdLine matches returning m_pTapiLineHandler 013EC3A8 .

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,11) [Thread 0x00000C9C] [Device 12] TSPI_lineDevSpecific hdLine 20878472.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,18) [Thread 0x00000C9C] [Device 12] CAvTapiLine::SetMwi: szExtension 2000 fMWIon 1.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x00000C9C] [Device 12] CSkinny::SetMWIOn szMWIOn szExtension.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000C9C] [Device 12] CSkinny::SendOffHookWithCgpn 2000.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x00000C9C] [Device 12] CSkinny::GenerateDigits 2101 No Delay.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000C9C] [Device 12] CSkinny::GenerateDigit: button = 2.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000C9C] [Device 12] CSkinny::GenerateDigit: button = 1.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000C9C] [Device 12] CSkinny::GenerateDigit: button = 0.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x00000C9C] [Device 12] CSkinny::GenerateDigit: button = 1.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyController::WaitForEvent signalled Data.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::ProcessData.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::GetMessage: dwSize = 2048.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CSkinny::ProcessPacket: dwSize = 24.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,12) [Thread 0x00000A24] [Device 12] Incoming Skinny Message: StationSetLampMessage: stimulus = 9 (Line) stimulusInstance = 1 lampMode = 2 (LampOn).

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,24) [Thread 0x00000A24] [Device 12] CSkinny::SignalSetLamp stimulus = 9 (Line) lampMode = 2 (LampOn).

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyController::WaitForEvent signalled Data.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::ProcessData.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::GetMessage: dwSize = 2048.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CSkinny::ProcessPacket: dwSize = 28.

18:47:24:607 (CiscoUnity_TSP,116,SkinnyTSP,12) [Thread 0x00000A24] [Device 12] Incoming Skinny Message: StationCallStateMessage: callState = 1 (OffHook) lineInstance = 1 callReference = 16777812.

18:47:24:608 (CiscoUnity_TSP,116,SkinnyTSP,24) [Thread 0x00000A24] [Device 12] CSkinny::SignalCallState: callState = 1 (OffHook).

18:47:37:637 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyController::WaitForEvent signalled KeepAlive.

18:47:37:638 (CiscoUnity_TSP,116,SkinnyTSP,23) [Thread 0x00000A24] [Device 12] CAvSkinnyHandler::InitiateKeepAlive: ms 15000.

I have the full traces if someone wants to look at them. Are there any know issues where Unity doesn't process the call proceeding messages?

Douglas now has TSP 7.0.2.

Douglas, you may want to install netmon on the Unity server and capture the actual packets between the CallManager and Unity server. Do you have dual NICS in either the CallManager or the Unity server?

We need to verify if the packets from CallManager are being received by Unity. On the surface this looks like a network issue, but everything else seems to work.

238
Views
0
Helpful
23
Replies
CreatePlease to create content