[cisco-voip] Unity MWI Delay

[Jason Burns]

I'd pay closer attention to the following message:

CCM|StationD:    (3331359) SetLamp mode=2, stim=15 stimInst=1

Mode 2 = on
Stim 15 = VM
StimInst 1 = turn line 1 red for a newer model phone, and display the
envelope next to the line on the LCD.

StimInst 0 = The big red light LED under the handset.

If you don't see StimInst=0 being turned to state 2 then the big red light
wasn't told to turn on.

Pay close attention to the Message Waiting Policy settings under

CCM Service Parameters
Device Specific Config (in 4.X only)
CCMUser Device Line configuration

Message Waiting Policy settings can cause unexpected behavior.

Also, make sure no one has alternate extensions configured in Unity for
their MWI settings. That can cause lights to turn on and off unexpectedly.

On Wed, Dec 3, 2008 at 11:09 AM, Ed Leatherman <ealeatherman at gmail.com>wrote:

> I found the StationOffHookWithCgpnMessageID for this particular call that
> Unity send during the MWI process. I hopped over to the CM node with the
> phone registered to it, and found (I think) the corresponding SetLamp and
> DisplayPromptStatus from when CM turned on the MWI on the phone. It looks
> like it also references the IP and port of the voicemail server that turned
> on the light in this message, should make it easy to find these in the
> future if I had to track them down:
>
> 12/01/2008 16:09:30.992 CCM|StationD:    (3331359) SetLamp mode=2, stim=15
> stimInst=1.|<CLID::OWP-PUB-Cluster><NID::10.X.X.X><CT::2,100,61,1.681851247><IP::
> *Unity IP Address Here*><DEV::CiscoUM1-VI64><LVL::State
> Transition><MASK::0020>
>
> Now to explain to this doctor that he's just not seeing the light turn on
> :)
>
> Thanks for the suggestion!
>
>
> On Tue, Dec 2, 2008 at 11:47 AM, Justin Steinberg <jsteinberg at gmail.com>wrote:
>
>> I would pull arbitary/detailed CM SDI traces for 16:09.   You will either
>> see the SCCP MWI message or you won't.    I would consider this a definitive
>> answer as to whether this is a technical problem or a user issue.
>>
>> grab the trace file and run it through triple x.
>>
>> http://www.employees.org/~tiryaki/tc/<http://www.employees.org/%7Etiryaki/tc/>
>>
>>
>> On Tue, Dec 2, 2008 at 10:11 AM, Ed Leatherman <ealeatherman at gmail.com>wrote:
>>
>>> Hi folks!
>>>
>>> I have MWI issues it seems like every few months. Finally got someone to
>>> give me the actual time and account that had the problem so I could do
>>> something with it. Faculty member had a message left for them at 16:09 and
>>> claims the MWI never turned on until 16:55.
>>>
>>> From the subscriber message activity report for him, I got:
>>>
>>> 12/1/2008 16:09:30 NEW MESSAGE
>>> 12/1/2008 16:09:30 MWI ON REQUESTED
>>> 12/1/2008 16:09:31 MWI ON COMPLETED
>>> 12/1/2008 16:57:08 LOGIN
>>> 12/1/2008 16:57:16 MESSAGE READ
>>> 12/1/2008 16:57:16 MWI OFF REQUESTED
>>> 12/1/2008 16:57:17 MWI OFF COMPLETED
>>>
>>> I've asked our exchange admin to look at the message tracking for it, but
>>> from what I see, it was delivered on-time and Unity even thinks the MWI
>>> request completed on-time. Normally I'd write this guy off as having just
>>> not noticed the light right away, but this isn't the first time he has
>>> reported it.
>>>
>>> Anyone with experience chasing these problems down? Does the above report
>>> indicate that the MWI ON request was merely successfully queued up, or that
>>> the MWI call out in fact cleared successfully? It would be really odd that
>>> the MWI functionality of the phone + callmanager was causing the delay but
>>> that's what it appears from this report.
>>> Unity 4.2, CM 5.1.3. VM-Only system.
>>>
>>> Thanks!
>>>
>>
>
> --
> Ed Leatherman
> Assistant Director, Voice Services
> West Virginia University
> Telecommunications and Network Operations
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20081204/62ace23c/attachment.html>