7970 hangs on requests

Unanswered Question
Oct 11th, 2007

Hi,

We write a service that runs on the 7970 phones, and have noticed that on occasion the phone hangs on a request to our server.

It will clear itself in about 20 or so seconds, but we are trying to improve the performance.

This is reproducible in the field with call managers with large systems, and on our local test system where we use the call manager simulator directly attached to the same switch as the application server it is communicating with.

We have had no problem with these same requests being made from browsers over the same network - there are multiple interfaces that reference the same application, full browser based, pda "simple web" based, and phone based - the phone is the only problem point. We are confident that our server is responding in a timely fashion.

Wireshark was used to capture packets and the results of three hangs have been condensed into one file with a couple of extra lines of info on each side of the incident to make sure that the entire sequence is captured - in truth this was from a much longer test period, but if you look at times the grouping is obvious - 1-11, 12-23 and 24 to 34. That file is attached. 23.128.25.211 is the application server running tomcat, and 23.128.25.39 is the IP Phone in the attached file.

What happens is that [SYN] commands are repeatedly sent, about 1.5 seconds apart, they fail about a half dozen times, then either the user represses the button - which is seen in the first two hangs in the file. If the request times out, the sequence number increases, and the request is passed.

We would be very interested in hearing suggestions on how to fine tune the system, and any information on why requests seem to go into this blocked state. To our untrained eyes it looks like the phone is not receiving an [ACK] reply that it expects, but we could use some low level TCP-IP advice on this.

Thank you,

Keith

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kdturner2008 Wed, 10/17/2007 - 11:16

Many 7970s where we see this are installed and maintained by Cisco in Cisco's CBCs, FSOs, etc. outside our control. Cisco Eschborn in particular prompted this queary.

These are assumed to be current.

In our test lab, we are using a 7970 on our test system with Call Manager Simulator, and there are several different Firmware items as below, which is where the log files attached were generated:

Version 6.0(2.0S)

Load File ID

TERM70.6-0-2-0S

App Load ID

Jar70.2-8-0-98.sbn

JVM Load ID

Jvm70.PMS499KR79.sbn

OS Load ID

Cnu70.2-7-3-101.sbn

Boot Load ID

7970_64060118.bin

Paolo Bevilacqua Thu, 10/18/2007 - 14:46

Since the releases you are testing with are no more recommended by cisco with any version of CM, you might try using the latest 8.2.2SR4 and if positive check with the cisco guys if they agree to upgrade too.

kdturner2008 Mon, 10/22/2007 - 05:47

This is happening with 8.3, so not a firmware issue.

Here's one phone's info, with the Wireshark log from Germany. The event is at lines 392-399 of the log.

MAC Address 001B2A8XXXXX

Host Name SEP001B2AXXXXX

Phone DN 8496XXXX

App Load ID Jar70sccp.8-3-0-50.sbn

Boot Load ID 7970_020706_cert.bin

Version SCCP70.8-3-1S

Expansion Module 1

Expansion Module 2

Hardware Revision 1.3

Serial Number FCH1106A5DN

Model Number CP-7970G

Message Waiting No

UDI phone

Cisco IP Phone 7970G, Global

CP-7970G

V01

FCH1106A5DN

Time 15:36:58

Time Zone W. Europe Standard/Daylight Time

Date 22/10/07

Note: We have upgraded the firmware for the phones on our test system as well. We use call manager simulator, not CM on it. These logs were generated on a system with a full CM attached, though the service requests do not pass though it.

Attachment: 
Paolo Bevilacqua Fri, 10/26/2007 - 09:51

Hi,

Is not because 8.3 is newer than 8.2.2SR4 thay you can assume is not a firmware issue, as indeed it may be.

FW 8.3 including latest still have like 232 bugs documented (not kidding - check yourself the release notes). So the recommended release for general deployment now is 8.2.(2)SR4.

kdturner2008 Fri, 10/26/2007 - 11:09

Thanks.

I take it from what you say that this may be beyond our control and we need to wait until the bugs are fixed. (We did end up filing a tac request, but what they urge is an upgrade to 8.3.2)

Keith

Actions

This Discussion