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 RFC 2705 ) 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 Software Advisor (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. Refer to Configuring 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 hardware 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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
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 of it:
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 VWICs.
0—This is the voice port number on a specific VIC or the VWIC.
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 example.
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 them:
|| Message Name
|| Sent By
|| Determines the status of a given endpoint.
|| Retrieves all the parameters associated with a connection.
|| Creates a connection between two endpoints.
|| From CallManager: Terminates a current connection. From Gateway: Indicates that a connection can no longer be sustained.
|| Changes the parameters associated with an established connection.
|| 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 occur.
|| 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 Sample 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 gateway.
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 command:
This diagram shows a sample FXS call flow (dialing and connection):
Note: In Cisco IOS Software Release 12.3(8)XY and later, the pre-package keyword is supported for the mgcp package-capability 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 to Configuring 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 relationships:
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.