[cisco-voip] troubleshooting IP phone 7960 keepalives

[Kevin Thorngren]

Yes, it is confusing.  IIRC, it is three KAs but they aren't all 30 
seconds apart.  The timeframe is shortened.  Typically you will see 
around 60 seconds between the last KA and the KA Timeout.

As Wes mentioned you can look at the secondary subscriber's CCM traces 
and search for "Last=" around the timeframe of when the phone 
unregistered.  This will give you the reason for the reset.  You don't 
need to wait for the Alarm message.

Kevin
On Nov 16, 2005, at 3:39 PM, Justin Steinberg wrote:

> This makes sense.  I was confused as to why a small percentage of
> phones were reporting to CallManager that they were not receiving
> KeepAlive Acks.  If they could report that info to CallManager they
> should receive the acks....
>
> So to the untrained eye, the 'StationInit' part of those trace messags
> are a little misleading because I read it as a message coming from the
> phone.  I did see one missed KA from the phone.  Although, I thought
> the phone only resets after three missed KA's.  Or maybe, the KA
> didn't make it to CallManager and the TCP session broke which caused
> the phone to reset quicker.
>
> I will keep an eye on the next occurance to see what alarm message is
> generated as Wes suggested.
>
> Justin
>
> On 16/11/05, Kevin Thorngren <kthorngr at cisco.com> wrote:
>> Hi Justin,
>>
>> Typically when you see the message "StationInit - Keep alive timeout"
>> in the trace it is coming from CallManager.  It seems strange that it
>> would be a StationInit message but the timeout is coming from the
>> StationInit process within the CallManager.   CCM/SDL traces from the
>> same time frame may help to confirm this.  A packet capture of the
>> problem would be best though.
>>
>> At some point, don't remember when, the KeepAliveAck message was taken
>> out of the CCM trace.  One thing you can do is to go backwards in the
>> trace from the "Keep alive timeout" message and see when the last
>> KeepAlive from the phone was.  I suspect you will find one missing.
>>
>> HTH,
>> Kevin
>>
>> On Nov 16, 2005, at 3:01 PM, Justin Steinberg wrote:
>>
>>> I have some phones that periodically reset themselves at random times
>>> during the day, I even have some instances when the phone reset 
>>> itself
>>> while on an active call.
>>>
>>> When I look at a detailed callmanager trace i see the following
>>> entries:
>>>
>>> 11/15/2005 15:21:29.108 CCM|StationInit - Keep alive timeout.:
>>> 000000741|<CLID::xxxCMPUB01-Cluster><NID::10.xxx.xxx.xxx><CT::
>>> 2,100,90,1.1122347><IP::10.xxx.xxx.xxx><DEV::SEP000C853Bxxxx>
>>> 11/15/2005 15:21:29.108 CCM|StationInit - Closing Station connection
>>> DeviceName=SEP000C853Bxxxx, TCPHandle=000000741,
>>> IPAddr=10.xxx.xxx.xxx, Port=52056, Device
>>> Controller=[2,89,737]|<CLID::xxxCMPUB01-Cluster><NID::
>>> 10.xxx.xxx.xxx><CT::2,100,90,1.1122347><IP::10.xxx.xxx.xxx><DEV::
>>> SEP000C853Bxxx>
>>> 11/15/2005 15:21:29.108 CCM|DeviceUnregistered - Device unregistered.
>>> Device name.:SEP000C853Bxxx Device IP address.:10.xxx.xxx.xxx Device
>>> type. [Optional]:7 Device description [Optional].:John Johnson 1128
>>> Reason Code [Optional].:8 App ID:Cisco CallManager Cluster
>>> ID:xxxCMPUB01-Cluster Node
>>>
>>>
>>> It seems like the phone is reporting to the CallManager that it is 
>>> not
>>> receiving keepalives and so the phone reboots.  I noticed that
>>> detailed callmanager traces log the incoming keepalives that the
>>> phones send to CallManager.  But I do not see the callManagers
>>> KeepAliveAcks in the detailed CCM trace log.  Do I have to run a
>>> packet capture to see this?
>>>
>>> Also, the phones and CallManager are on the same lan - so 
>>> latency/loss
>>> SHOULD not be an issue.
>>>
>>> TIA
>>>
>>> justin
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>>
>