- Introduction
- Fundamentals
- TCP
- SCCP Keepalives
- TCP Acknowledment vs SCCP KeepaliveAck
- Unregistration
- Failover
- Failback
- Related Documents
Introduction
- applies to
- purpose & audience
Fundamentals
TCP
SCCP relies on TCP as a transport protocol. This is different from SIP which can use either TCP or UDP. SCCP communication between IP phones and the registration server is on port 2000 or 2443 (secure connections only).
The first thing a device does when attempting to register is to setup a TCP connection to the server it wishes to register with. This TCP session will be used as long as the device is registered and if the TCP session is lost, torn down, or reset the phone will attempt to failover and register to a backup server.
The establishment of a TCP session is called a 3-way handshake. The phone will initiate the connection by sending a TCP SYN to the server on port 2000. The CUCM server will respond with its own SYN and ACK. The phone will then respond with an ACK and the TCP connection is considered established. At this point the phone would commence sending data over the connection.
The TCP acknowledgment flag (ACK) is the mechanism the protocol uses to guarantee delivery of a packet. Upon receipt of a packet the next packet sent back will include the ACK flag. The ACK can be sent in a data packet or can be sent with no data. The acknowledgment number is used to identify which particular packet the ACK is for. This document will not attempt to explain TCP sequence and acknowledgment numbers.
Keeping the TCP session established with the registration server is critical for an SCCP phone to remain in service. While this may seem obvious it is important to keep this fact in mind when troubleshooting device unregistration issues. If a phone doesn't have a TCP connection it cannot attempt to register.
In addition to the TCP connection to the active server an IP Phone will also establish a TCP session to its first backup server. Unlike the connectio to the primary server the phone will not register to the backup server after the connection is established. The registration will only occur when the connection to the primary server is lost. By not having to go through the 3-way handshake this greatly speeds up failover time.
You can see in the phone's network configuration which server is Active (registered) and which is Standby (TCP connection established, but no registration).
Geometric TCP
The Cisco Unified IP Phone firmware 7.2(1)
introduced a Geometric TCP mechanism to permit IP Phones to measure the
round-trip delay between the IP Phone and Unified CM, then adapt the
keepalive timeout value. This provided a very accurate failover
mechanism when the network delay is consistent.
This means that the lower the RTT between the IP phone and the server it is registered with the faster the phone will expect TCP Acknowedgment frames. This also translates to faster TCP retransmissions, and thus on a fast network only a few seconds of connectivity loss can result in the IP Phone timing out the TCP session with the server and attempting to failover to a backup server.
Without this feature the IP Phones use a fixed TCP retransmit timer regardless of connection speed. Because the initial retransmit timer is fixed and the timer doubles with each subsequent retransmit a connectivity loss of up to several minutes would be required for a phone to timeout a TCP session due to missed TCP Acknowledgments.
However, if the network delay is inconsistent,
this mechanism may cause the IP Phones to inaccurately attempt failover.
The Cisco Unified IP Phone firmware 8.4(2) introduces the ability for
the Network Administrator to disable this behavior, if necessary,
through the Detect Unified CM Connection Failure parameter defined on the IP Phone device configuration. The default value is Normal; this Geometric TCP mechanism can be disabled if the parameter is set to Delayed.
source: IP Phone Firmware 8.4(2) Release Notes
If you find that your phones are timing out TCP sessions too quickly then changing this parameter may help keep the phones stable. If it does not achieve the desired results then change the parameter back to the default value and continue troubleshooting.
SCCP Keepalives
The SCCP Keepalive is a message sent from the SCCP phone to each server it has an active TCP connection to. Normally this will include the active registration server and the first backup server. The expected response to the Keepalive is a SCCP KeepaliveAck. While the phone will send a Keepalive to each server, the response is only required from the server the phone is actively registered to. A CUCM server that receives a Keepalive from a phone that is not registered will not respond to the Keepalive.
The image below shows a Wireshark ladder diagram of the SCCP Keepalive exchange.
TCP Acknowledment vs SCCP KeepaliveAck
Unregistration
- When/How
- Alarms
- Transient Device Connections
Failover
- when/how
- alarms
Failback
- when/how
- alarms
- knobs