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
This document only addresses QoS packet marking through the use of
DSCP/ToS within the IP header.
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:
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
Refer to the
Technical Tips Conventions for more information on document
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
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
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
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
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
Database replication from publisher to subscriber uses best effort
(DSCP=0) by default.
Directory traffic from the LDAP directory also uses best effort
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.