This document explains the use of Quality of Service (QoS) between devices controlled by a Cisco CallManager cluster. These devices include IP phones, gateways, and other devices when both signaling and voice packets pass through a Layer 3 device, such as a router. This document addresses the various types of Differentiated Services Code Point (DSCP)/Type of Service (ToS) packets employed by Cisco CallManager and other devices on a per-protocol basis (Skinny, H.323, Media Gateway Control Protocol (MGCP), and Real-time Protocol (RTP)).
This document only addresses QoS packet marking through the use of DSCP/ToS within the IP header.
Refer to TCP and UDP Ports Used in a Cisco CallManager Environment for a list of all of the TCP and UDP port numbers that Cisco CallManager utilizes.
There are no specific requirements for this document.
The information in this document is based on these software versions:
All versions of Cisco CallManager 3.x and 4.x
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
These products have specific QoS documents that directly address their requirements:
Cisco Unity – Refer to Cisco Unity and QoS for more information.
Cisco IP Contact Center (IPCC) – For all ICM 4.x versions, controllers use "best effort" or a DSCP value of 0 when it sends "labels" to route calls to agents to Cisco CallManager to route calls.
For ICM version 5.x and later, Microsoft's Windows 2000 QoS Model is used. Refer to Cisco ICM Software Pre-Installation Planning: Network and Site Requirements for more information.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
There are two distinct types of packets/traffic involved with any type of IP Telephony product:
There are several different signaling protocols that Cisco CallManager uses, based upon the devices it communicates with:
Skinny (SCCP) – Between Cisco CallManager and IP phones (can include devices like the ATA 186).
MGCP – Between Cisco CallManager and gateways.
H.323 Protocol Suite – Includes H.225 and possibly H.245 signaling between Cisco CallManager and an H.323 device (phone, gateway, or gatekeeper).
Intra-Cluster Communications – For signaling between Cisco CallManager servers within the same cluster. This is very important to understand if a Layer 3 device sits between the Cisco CallManager nodes/servers because it includes directory and database traffic as well as real-time signaling traffic between the nodes of the cluster.
Note that with the exception of MGCP, all signaling protocols use the TCP protocol stack which offers the resiliency to retransmit packets that were lost between the devices. Regardless of the protocol used, Cisco CallManager itself can be configured on a cluster-wide basis to use the older, yet compatible ToS value. This is found in the Cisco CallManager Service Parameter IpTosCm2Dvce. Although, Cisco strongly recommends that you do not change this value.
Note: Prior to Cisco CallManager 4.0, voice control traffic defaulted to a DSCP value of 26 / AF31. In Cisco CallManager 4.0 and later, this was changed so that voice control traffic is marked with DSCP 24 /CS3 by default. This change reflects the fact that voice control traffic should never be dropped whereas DSCP AF31 traffic can be dropped in certain instances.
The Skinny protocol runs over TCP port 2000, and its DSCP/ToS value is derived from the configurable setting located within the Service Parameter IpTosCm2Dvce mentioned earlier in this document. The default DSCP value is 26 (AF31 or a ToS value of 3, which equals "flash" traffic).
For MGCP analog and T1-channel associated signaling (CAS) devices, only device registration uses TCP, while UDP is used for keepalives and signaling. With the advent of PRI backhaul in Cisco CallManager 3.1 and later, digital PRI backhaul devices use separate channels: MGCP messages for initialization (Restart In Progress (RSIP), Audit Endpoint (AUEP), Audit Connection (AUCX)), media control (Create Connection (CRCX), Modify Connection (MDCX), and Delete Connection (DLCX)) and in-band call progress (Notification Request (RQNT) and Notify (NTFY)) use UDP packets, while the actual Q.931 messages are backhauled/piggybacked over a separate TCP channel. All UDP packets between the end devices and Cisco CallManager are marked with a DSCP value of 26 (AF31 or ToS or IP precedence value of 3). For all TCP backhaul messaging, gateways by default use best effort (DSCP = 0), but are configurable from the CLI.
By default, Cisco CallManager uses a DSCP value of 26 (AF31) to backhaul all signaling (TCP or UDP). This value can be changed within the Cisco CallManager Administration web pages by going to the Service Parameters for the Cisco CallManager service and selecting IpTosCm2Dvce. Although, Cisco strongly recommends that you do not change this value.
When you configure QoS, remember that the Cisco CallManager (the "Call Agent" in MGCP terminology) and end devices use UDP port 2427 and TCP port 2428 respectively.
The H.323 protocol suite uses UDP/IP or TCP/IP protocol for signaling based upon the type of signaling. With Cisco CallManager 3.2(x) and later, the use of FastStart (where the media control signaling can be piggybacked on the H.225 stream instead of the need to open another separate channel for H.245) for inbound signaling is permitted and is the default setting on an IOS-based gateway. All outbound signaling from the Cisco CallManager to the H.323 device still uses both H.225 (UDP Port 1718 for gatekeeper discovery, UDP port 1719 for H.323 Registration, Admission and Status (RAS)/gatekeeper, and TCP port 1720 for peer-to-peer call control) and H.245 (TCP port range from 11000-65535).
For H.323 gateways, the DSCP (or IP Precedence/ToS) value for signaling can be configured through the use of a policy/class map setting (for example, when you use a Low Latency Queuing (LLQ)) solution. Refer to the QoS reference documentation found on the Cisco Technical Support website.
This is traffic between Cisco CallManager nodes/servers themselves, and includes things like Cisco CallManager and computer telephony integration (CTI) Manager SDL communications, SQL replication, Server Message Block (SMB) communications and CTI/Quick Buffer Encoding (QBE) activities. If you have a Layer 3 device that separates Cisco CallManager nodes (by either WAN or LAN), you must have a maximum Round Trip Time (RTT) of 40 ms, or 20 ms delay in either direction.
Database replication from publisher to subscriber uses best effort (DSCP=0) by default.
Directory traffic from the LDAP directory also uses best effort packet marking.
For real-time traffic via Intercluster Communications (ICCS), which includes signaling, call admission control, and so forth, as well as CTI Manager realtime traffic, a DSCP value of 26 (AF31 or IP precedence 3) is used.
This includes any audio-bearing packet that uses the IP/UDP/RTP protocol stack. All UDP packets are unacknowledged. Therefore, the implementation of QoS mechanisms for this type of traffic is critical in order to ensure voice quality from end-to-end. By default, Cisco CallManager always instructs controlled end devices (IP phones, some MGCP gateways, and so forth) to use a DSCP value of 46 (EF or IP precedence 5). For IOS-based gateways (using MGCP or H.323 for signaling), this is the default value but can be changed on the CLI. There is also an option with Cisco CallManager to change this value. However, Cisco very strongly recommends that it not be changed from the default service.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.