[cisco-voip] 7975 reset problem
Abebe Amare
abucho at gmail.com
Mon Sep 19 03:18:34 EDT 2011
Hi Wes, we are using Tranzeo wireless routers to connect the office with HQ
and sometimes the connection flaps randomly. I will investigate this issue
but I am grateful for the workaround you gave me.
thanks
Abebe
On Fri, Sep 16, 2011 at 7:26 PM, Wes Sisk <wsisk at cisco.com> wrote:
> Hi Abebe,
>
> Note that change the TCP algorithm will only attempts to conceal underlying
> network issues. If a user attempts to use the phone while network is down
> they will have a suboptimal user experience. In my experience most users
> expect very responsive phones even though they are willing to refresh or
> retry web pages and checking email. Consider pursuing the network issue.
>
> Otherwise, TCP retransmit algorithm is on the device configuration page:
>
>
> Detect Unified CM Connection Failure: This field determines the
> sensitivity that the phone has for detecting a connection failure to Cisco
> Unified Communications Manager (Unified CM), which is the first step before
> device failover to a backup Unified CM/SRST occurs. Valid values specify
> Normal (detection of a Unified CM connection failure occurs at the
> standard system rate) or Delayed (detection of a Unified CM connection
> failover occurs approximately four times slower than Normal). For faster
> recognition of a Unified CM connection failure, choose Normal. If you prefer
> failover to be delayed slightly to give the connection the opportunity
> to reestablish, choose Delayed. Note that the precise time
> difference between Normal and Delayed connection failure detection depends
> on many variables that are constantly changing. Default = Normal This is a
> required field. Default: Normal
>
> Regards,
> Wes
>
> On Sep 16, 2011, at 10:33 AM, Abebe Amare wrote:
>
> Hi Wes, thanks for your customary brilliant assistance.
>
> How can I enable Geometric TCP failover?
>
> best regards,
>
> Abebe
>
> On Fri, Sep 16, 2011 at 5:29 PM, Wes Sisk <wsisk at cisco.com> wrote:
>
>> Last=TCP-timeout
>>
>> That seems pretty clear. Phone tried to send a message to CUCM and never
>> received TCP ACK. Most likely over a poor network connection (wireless?).
>> Possibly this phone has geometric TCP enabled where others have it
>> disabled?
>>
>> CSCsm81227 Allow Geometric TCP phone failover to be configurable
>>
>> This affects the rate and timing of TCP retries.
>>
>> regards,
>> Wes
>>
>> On Sep 16, 2011, at 9:43 AM, Abebe Amare wrote:
>>
>> Dears,
>>
>> I have included the debug message from one of the phones
>>
>> 15:44:19 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 14:00:24 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 14:01:05 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 14:01:05 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 14:00:30 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 14:01:01 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 14:01:01 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 18:23:29 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:24:30 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:35:57 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:35:57 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout:
>> CTFFile.tlv
>> 18:35:57 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:35:57 17: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=KeepaliveTO
>> 18:37:22 14: Name=SEP00230432DB6D Load= SCCP75.8-4-2S
>> Last=UCM-closed-TCP
>> 18:37:22 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:37:22 14: Name=SEP00230432DB6D Load= SCCP75.8-4-2S
>> Last=UCM-closed-TCP
>> 18:38:38 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:41:22 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:42:22 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:42:47 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:42:47 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 18:43:53 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:48:24 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:49:20 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 18:49:47 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 18:49:51 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:50:39 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 18:52:16 7: Name=SEP00230432DB6D Load= SCCP75.8-4-2S TFTP Timeout
>> 19:01:44 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 19:02:21 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 19:02:21 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 20:51:25 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 20:51:57 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 20:51:57 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 13:19:45 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 13:20:16 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 13:20:16 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 15:35:48 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 15:36:18 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 15:36:18 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 19:40:18 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 19:40:48 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 19:40:48 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 11:07:04 23: Name=SEP00230432DB6D Load= SCCP75.8-4-2S
>> Last=Reset-Restart
>> 19:20:44 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 19:21:15 18: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=Failback
>> 10:18:31 23: Name=SEP00230432DB6D Load= SCCP75.8-4-2S
>> Last=Reset-Restart
>> 14:00:32 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>> 14:00:36 23: Name=SEP00230432DB6D Load= SCCP75.8-4-2S
>> Last=Reset-Restart
>> 15:51:29 10: Name=SEP00230432DB6D Load= SCCP75.8-4-2S Last=TCP-timeout
>>
>> regards,
>>
>> Abebe
>>
>> ---------- Forwarded message ----------
>> From: Abebe Amare <abucho at gmail.com>
>> Date: Fri, Sep 16, 2011 at 4:02 PM
>> Subject: 7975 reset problem
>> To: cisco voip <cisco-voip at puck.nether.net>
>>
>>
>> Dears,
>>
>> I have few 7975 IP Phones which reset by themselves randomly. They reside
>> in an office which has a wireless connection to the Call Manager location.
>> All other phones (7911, 7941 and 7962) in the same office don't exhibit the
>> same problem. Could this be a firmware issue?
>>
>> CM version : 6.1.3.1000-16
>> Device firmware: SCCP75.8-4-2S
>>
>> best regards,
>>
>> Abebe Amare
>>
>>
>>
>> _______________________________________________
>> 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/20110919/ff58ad80/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 18268 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110919/ff58ad80/attachment.tiff>
More information about the cisco-voip
mailing list