Media Gateway Control Protocol (MGCP) is a plain-text protocol used by
call-control devices to manage IP Telephony gateways. This document addresses
how the protocol functions and how it is implemented in Cisco CallManager.
MGCP (defined under
) is a
master/slave protocol that allows a call control device (such as Cisco
CallManager) to take control of a specific port on a gateway. This has the
advantage of centralized gateway administration and provides for largely
scalable IP Telephony solutions. With this protocol, the Cisco CallManager
knows and controls the state of each individual port on the gateway. It allows
complete control of the dial plan from Cisco CallManager, and gives CallManager
per-port control of connections to the public switched telephone network
(PSTN), legacy PBX, voice mail systems, plain old telephone service (POTS)
phones, and so forth. This is implemented with the use of a series of
plain-text commands sent over User Datagram Protocol (UDP) port 2427 between
the Cisco CallManager and the gateway. A list of the possible commands and
their functions is provided later in this document.
Another concept relevant to the MGCP implementation with Cisco
CallManager is PRI Backhaul. This occurs when Cisco CallManager takes control
of the Q.931 signaling data used on an ISDN PRI.
It is also important to note that for an MGCP interaction to take place
with Cisco CallManager, the gateway must have CallManager support. Use the
(registered customers only)
tool to make sure that your
platform as well as the version of Cisco IOS® Software or Catalyst Operating
System (CatOS) is compatible with Cisco CallManager for MGCP.
Note: BRI backhauling is supported in recent Cisco IOS Software Releases.
MGCP-Controlled Backhaul of BRI Signaling in Conjunction with Cisco
CallManager for more information on BRI backhauling.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and
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.
Technical Tips Conventions for more information on document
These sections discuss the two attributes of MGCP that allow it to
function. Endpoints are references to specific voice ports on a gateway while
call-agents are the control devices that administer the gateways.
Endpoints are any of the voice ports on the designated gateway. These
voice ports provide connectivity to both analog ports (such as Foreign Exchange
Office (FXO)/Foreign Exchange Station (FXS)) and digital trunks (such as a T1
or E1) to the PSTN. Ports on gateways are identified by endpoints in very
specific ways. It is important to note that gateways can have multiple
endpoints dependent on the number of ports it contains, and that the endpoints
are case insensitive. This is a sample endpoint and an analysis of each portion
AALN—Analog Access Line eNdpoints. This name is used
to designate that the type of endpoint is analog. This means that either FXO or
FXS voice interface cards (VICs) are in use. This value changes dependent on
what type of endpoint is in use. For example, if a DS3 interface is used, this
value would be "ds3". More on the digital endpoint specification is given later
in this document.
S1—Slot 1. This is the slot number on the chassis
that holds the voice network module.
SU0—Subunit 0. This is the slot number on the voice
network module that holds VICs and voice/WAN interface cards
0—This is the voice port number on a specific VIC or
av-vg200-1.cisco.com—This is the hostname of the
sample endpoint. If the gateway has been configured with a domain name, it is
appended to the hostname as seen in this
In this endpoint, the voice port 1/0/0 on a gateway with a hostname of
av-vg200-1 and a domain name of cisco.com is described. AALN describes this to
be an analog port, S1 describes that the network module is in slot 1, and SU0/0
indicates the interface card and port number on the network module.
Here is an example of an MGCP endpoint identifier for T1 PRI. Note the
only difference is the trunk type and the B-channel. The trunk type designates
what type of trunk the endpoint describes. Some examples of valid trunk types
are ds1, ds3, e1, and e3. The B-channel specifies which B-channel on the trunk
this endpoint is associated with.
Call agents are external control devices in a voice system. Cisco
CallManager is the call agent referenced in this document. In MGCP, the call
agent is the device that has complete control of the gateway. This is a very
efficient system as all the administration is performed by the call agent.
There is very little setup required on the end of the gateway, as all route
patterns and dial-plans are configured on the Cisco CallManager.
MGCP is implemented by a set of commands and responses between the call
agent and the gateway transmitted in plain text. Because plain text is used, it
can be very useful to understand these commands to troubleshoot problems
related to MGCP. These commands are transmitted and received across UDP port
2427. There are eight different types of MGCP commands. This table defines
Determines the status of a given endpoint.
Retrieves all the parameters associated with a
Creates a connection between two endpoints.
From CallManager: Terminates a current
From Gateway: Indicates that a connection
can no longer be sustained.
Changes the parameters associated with an established
Instructs the gateway to watch for special events such as hooks
or DTMF tones. It is also used to instruct the gateway to provide a signal to
the endpoint (for example, dial tone and busy tone).
Informs the Cisco CallManager when requested events
Informs the Cisco CallManager that an endpoint or group of
endpoints are taken out or placed back into service.
Parameters are sent along with commands to specify exactly what is
required or what information is given. Refer to
of Debug MGCP Packets for detailed explanations on parameters. This
information is beyond the scope of this document.
It is important to remember that this protocol is used for control
purposes only. No voice data is transmitted through the MGCP protocol itself.
All the voice data transfer occurs directly between the phone and the gateway.
This diagram explains these relationships:
The Cisco 7960 IP phones in this example use the Skinny Call Control
Protocol (SCCP) to communicate with the Cisco CallManager. The actual voice
data is transferred through Real-time Transport Protocol (RTP) directly between
the two devices. MGCP is used by the Cisco CallManager only to control the
Cisco CallManager's implementation of MGCP uses specific command
sequences to perform a variety of tasks. These are several examples of how
calls are made and how the gateways are registered. The concept of PRI
Backhauling is also covered in this section.
This diagram describes how Cisco CallManager registers voice gateways
in its database with use of MGCP. The acknowledgment (ACK) commands are
standard TCP acknowledgements of the received
This diagram shows a sample FXS call flow (dialing and
Note: In Cisco IOS Software Release 12.3(8)XY and later, the pre-package
keyword is supported for the
command. The mgcp
package-capability pre-package command can be configured in the
gateway to solve issues like outbound call failures in a T1 CAS gateway. Refer
MGCP Gateway Support for Cisco CallManager for more information.
The one thing that distinguishes a PRI from other interfaces is the
fact that the data that is received from the PSTN on the D-channel and needs to
be carried in its raw form back to the Cisco CallManager to be processed. The
gateway does not process or change this signaling data, it simply passes it
onto the Cisco CallManager through TCP port 2428. The gateway is still
responsible for the termination of the Layer 2 data. That means that all the
Q.921 data-link layer connection protocols are terminated on the gateway, but
everything above that (Q.931 network layer data and beyond) is passed onto the
Cisco CallManager. This also means that the gateway does not bring up the
D-channel unless it can communicate with Cisco CallManager to backhaul the
Q.931 messages contained in the D-channel. This figure illustrates these
For more information on these topics, the Cisco Press book
Troubleshooting Cisco IP Telephony
provides an in-depth
overview on MGCP and its interactions with Cisco CallManager.