7937 Transient Connection Error

Unanswered Question
Jun 5th, 2008
User Badges:

Has anyone else encountered a problem in which the 7937 conference phones unregister? On the phone itself, it will drop a call and then sit there with a Configuring CM List message. In the CCM server's event log, I see errors showing Device Transient Connection and sometimes Device Unregistered errors. The phones usually come back up within 5 minutes, but it is a big disruption to meetings being held in conference rooms. This doesn't seem to affect any of the 7961 desk phones that are plugged into the same Catalyst 3750 switches. The CCM is version 4.1(3)sr6a.


Here is an example of one of the errors:


Event Type: Error

Event Source: Cisco CallManager

Event Category: None

Event ID: 3

Date: 6/4/2008

Time: 2:40:31 PM

User: N/A

Computer: PDXCCM1

Description:

Error: DeviceTransientConnection - Transient connection attempt.

Connecting Port: 2000

Device name [Optional].: SEP0004F2E115B2

Device IP address.: 10.1.30.128

Device type. [Optional]: 431

Reason Code [Optional].: 1

App ID: Cisco CallManager

Cluster ID: StandAloneCluster

Node ID: 10.1.110.10

Explanation: A connection was established and immediately dropped before completing registration. Incomplete registration may indicate a device is rehoming in the middle of registration. The alarm could also indicate a device misconfiguration, database error, or an illegal/unknown device trying to attempt a connection.

Recommended Action: No action is required if this event was issued as a result of a normal device rehome..


Thanks in advance,

Pat

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
irisrios Wed, 06/11/2008 - 06:31
User Badges:
  • Silver, 250 points or more

If this event occurs continuously for some devices, check these items:

If the device exists in the database.

If the devices are located in a particular segment in your network, analyze the connectivity.

If your Cisco CallManager(s) have connection, high CPU memory problems that can cause a slow response.

Make sure that you use the correct DNS server IP address in the gateway configuration.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080111ac2.shtml


patrick.bartos Wed, 06/11/2008 - 06:38
User Badges:

Thanks for the reply. Since my original posting, I have discovered that when a Ghost session is set up to image a computer, all of the 7937 phones plugged in to the same switch as the Ghost server will be unregistered. As soon as the Ghosting is done, the phones come back up.


I am working with TAC and giving them trace files, but it looks like the only thing they can do right now is to create a bug on the problem.

patrick.bartos Mon, 08/25/2008 - 07:53
User Badges:

I thought I would update this posting in case somebody experiences the same problem and goes looking for a solution...


After a failed attempt at throwing a new firmware version at the problem, it turns out that multicast support is a "feature" of the 7937 phones. It interprets a Ghost multicast session as a denial of service event and goes into an unregistered mode as a security feature. (Feature-rich products are such a pain!) Our 7936 and 7961/41 phones simply drop the Ghost traffic at the phone level and have no problems staying active.


It was recommended to me to disable multicast traffic on the phone VLAN at the switch level. Either that, or I could continue to make the hardware technicians set up a separate network for imaging PC's.

Rob Huffman Mon, 08/25/2008 - 08:01
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi Patrick,


Interesting problem (that must have taken awhile to figure out :)+5 points for this very kind follow-up!


Take care,

Rob

mattcalderon Mon, 08/25/2008 - 10:02
User Badges:
  • Silver, 250 points or more

What does not make sense about this, that if that is a "Feature" concerning some type of DoS attack, why the phone drops the call and unregisters....??? This is still a denial of service....

patrick.bartos Mon, 08/25/2008 - 12:34
User Badges:

I had the same thoughts exactly that the security feature was still denying me the ability to make and receive calls. Here is the technical explanation I received, which gives more details about what is happening:


Here is the Design Differentiation between 7936 and 7937 conference station phones.

The New 7937 phones are designed to support multicast. However the side effect of this what we observe during multicast ghost traffic.

GI-01 Remain stable during flooding attack:

During a Reference Flood directed to or through the device, the Standalone Device MUST remain stable which means continuing to operate without reloading its software, and maintaining the integrity and consistency of its internal data structures, and the device MUST recover gracefully after the attack has ended. No human intervention MUST be required. M

In idle state, 7937 may temporarily un register during flooding and re-register with the call manager once the attack is stopped.

This is primarily because of the flooded network which doesn't allow the phone to gets its keepAlive Ack.


In Active call state, 7937 doesn't drop the call in spite of the flooded network. Choppy voice experience as the quality of voice degrades.

It also loses registration.

This is again because of the flooded network blocking skinny and RTP packets.



Voice quality is resumed once the attack is stopped.


M=7937

7937 has the capability to receive both unicast and multicast data.

Multicast support is provided for receiving RTP data for XML services(RTPMrx and RTPMtx).

When ghost process is in progress, all the multicast packets are directed to 7937's voice vlan.

Since 7937's architecture allows all multicast packets on account of its XML services feature, any high rate multicast stream(debug load phones receiving 3000 packets/sec) is equivalent to a DOS attack.

Hence when 7937 is subjected to receive high rate multicast stream, it losses registration.No new socket can be created and the old ones are closed UNDER ATTACK.

7937 keeps sending KeepAliveMessage to the callmanager. Since the network is flooded with multicast traffic, the messages cannot be reached to the CUCM. As per TCP protocol, if a message is not delivered to destination, the stack does the retransmission of the message. The maximum number of retransmissions is 12, and if the message is not delivered within the given number of tries , the socket shuts down causing the phone to lose registration.

When compared to other Cisco phones like 7940\60, these phones have switch that keep discarding the unnecessary multicast traffic.

7936 is tuned to accept multicast data from specified address like CDP address.It doesn't accept multicast data other than the one it is tuned to, so the multicast data received by it , will be discarded at the hardware level.

Whereas in 7937, multicast discarding cannot be done at hardware level because of absence of switch and also cannot be tuned to accept multicast data from specified addresses as it will be a limitation against XML services.

Having said that A workaround to inhibit the ghost traffic for Voice VLAN can help

by changing router / switch interface (eg. ip pim xxxxx ) of voice vlan on which 7937 is running .


Actions

This Discussion