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.
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 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.
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.
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.
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 .
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...