This document describes the Media Gateway Control Protocol (MGCP) and the mechanisms behind the Messages. More specifically, it disects an MGCP Message in order to better understand each of their components, and what makes them important. In addition to the protocol MGCP as a whole, this document also includes how to configure and troubleshoot MGCP.
This document utilizes configuration examples as well as debug and show command outputs as reference points. The many features in this document are clearly marked with the version the feature was introduced to both IOS and IOS-XE.
Cisco recommends that you have knowledge of these topics:
There are no formal requirements when you read this document. It is meant to be an introduction into MGCP.
Cisco Unfied Communications Manager 11.5
The Call Control elements that play the Master role and provide centralized call intelligence.
The Endpoints are the devices that the Call Agents control. Such as: FXO, FXS, or a DS0 channel
Public Switched Telephone Network
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 in production, ensure that you understand the potential impact of any command.
The Media Gateway Control Protocol (MGCP) is defined by RFC 2705. MGCP is a master/slave protocol, where the Endpoint (Slave) is controlled by a Call Agent (Master) of some type. The entire control intelligence is controlled by a Master who instructs the endpoint what action to take once an event is detected. MGCP uses TCP port 2428 and UDP port 2427.
TCP port 2428 in MGCP is used to open a new socket with the Call Agent to determine if the connection can be established. Without this new socket, subsequent MGCP Messages cannot be exchanged. It is also used to Send/Receive Backhaul Messages between PRI Endpoints and the Call Agent it is registered to. Finally, TCP port 2428 is used to failover to backup Call Agents in the event a Primary Call Agent is unresponsive.
UDP Port 2427 in MGCP is used for MGCP Messages exchanged between the Endpoints and the Call Agents.
This is an example of a basic MGCP Flow. You can see in the Example that the gateway receives a new call from the PSTN on this Voice Gateway (Endpoint). The Gateway then notifies the Call Agent (CUCM) of this new call that is received, the Call Agent then instructs the Gateway to create a connection for this new call. Finally, the Gateway sends an OK back to the Call Agent to establish the call.
An identifier is needed per endpoint for the Call Agent to be able to determine whom it needs to send an event, or where an event comes from. Endpoints Identifiers have two main components:
Local Name within that Gateway (case insensitive).
Domain Name of that Gateway that is manages the endpoint (case sensitive).
Basic Configuration of MGCP
This document has broken out each of the configuration components into individual steps.
Gateway CLI Configuration
On the Analog Gateway that you plan to register to CUCM, this is the minimal configuration that is actually required. You only need to add this configuration to start the registration process, as the rest of the configuration is then downloaded from CUCM:
VG320(config)# mgcp call-agent 18.104.22.168 2427 service-type mgcp version 0.1
VG320(config)# ccm-manager config server 22.214.171.124
VG320(config)# ccm-manager config
VG320(config)# ccm-manager mgcp
**Note on the ISR4000s if you fail to down load your configuration file, you must add the command:
VG320(config)# ip tftp source-interface GigabitEthernet x/x/x
In order to configure the MGCP Gateway in CUCM you need to log in to Cisco Unified CM Administration. Once logged in, navigate to Device > Gateway:
The previous selection starts you at the Find and List Gateway page. On this, you want to select the Add New button with a plus sign:
After you select Add New you are prompted to select a Gateway Type. Use this drop down in order to select the hardware you plan to register, and select Next to select the protocol you want for this device (you need to select MGCP):
Now that you have selected the hardware and protocol used, you need to configure the Domain Name, Cisco Unified Communications Manager Group, and the Module Information. These are the major fields that are required to register an endpoint via MGCP.
The Domain Name is comprised of 1 to 2 parts. At a minimum in the Domain Name field you need to enter the Host Name of the router. In my scenario, the Host Name is:
However, if you have a domain name configured on the gateway, you need to configure the Fully Qualified Domain Name of this device:
Now, you must hit Save. This updates the page and allow you to select a Subunit now. Once you select a Subunit, select Save again. You can now see your configurable ports:
In order to configure an endpoint now, click the port in which you have your analog device plugged into (In our case, it is 0/0/0). Once you select a port you are prompted to configure the port type:
In this case, you select POTS. Once this is selected, you can enter all the necessary values for the device information like you would for any other Call Manager Endpoint. The only required field is Device Pool, however you might want to enter values for things such as a Calling Search Space. Once you have done this, you can then click Save. At this point you now see the left-hand pane has populated the Add a new DN field for you. You can now associate a DN with this port, save, and the apply the configuration. Once this is done, back at the port configuration page you can now see the port as registered:
Endpoint Registration & Call Setup
In this section, you cover the basics of MGCP Endpoint Registration and Call Setup. This includes the Commands Messages seen as the Gateway interacts with the Call Agent. In this scenario, CUCM is our Call Agent.
MGCP Endpoint Registration
For an MGCP Endpoint to register to CUCM, the Gateway opens TCP socket 2428 to CUCM, from here it uses UDP port 2427 to send command messages. Once the socket it open, the Gateway sends an RSIP Command to the CUCM to inform it that the Endpoint must be taken out of service while the restart occurs, and CUCM sends a simple acknowledgment to this. After the Restart is complete, CUCM sends a RQNT with the parameter R: L/hd. What this does is denotes that the Gateway must notify CUCM of an Off-hook event.
At this point, the CUCM sends an AUEP (Audit Endpoint) to the Gateway to determine the status of the given Endpoint. The response from the Gateway is an ACK with the endpoints capabilities. Once this is complete the Endpoint is registered with the CUCM. This is a sample debug output:
The previous image is an example of an outbound call.
You can see that your Call Agent, in this case CUCM, starts with a CRCX that has recvonly to the Gateway to establish connection for the call. The Gateway responds back with a 200 OK that contains SDP for what it supports. Once this exchange is done, the CUCM sends an RQNT message to the Gateway with the parameter S: G/rt. This tells the Gateway to play ringback to the device. After the far end receives the call, and picks up, CUCM then sends a MDCX with SDP to the Gateway to let it know of the media information for the far end device. The Gateway sends back a simple 200 OK to acknowledge this, and at this point you have two-way media.
Now that the call has been answered, CUCM sends another RQNT with the parameter R: D/[0-9ABCD*#]. This is tells the Gateway to let CUCM know of any DTMF that is pressed while the call is active so that it can be relayed to the next device.
Once the call is over with, CUCM sends a MDCX to the Gateway with M: recvonly to terminate the media, followed by a DLCX to disconnect the call. This is a sample debug output:
When you troubleshoot MGCP there are some helpful show commands and debugs that you can view in order to determine why registration or a call has failed. A great place to start, is to check if your MGCP Gateway is Registered to the Call Agent. You can check this via the show command show ccm-manager or show mgcp:
VG320# show ccm-manager
MGCP Domain Name: VG320.dillbrowLab.local
Priority Status Host
Primary Registered <CUCM IP>
First Backup None
Second Backup None
Current active Call Manager: <CUCM IP>
Backhaul/Redundant link port: 2428
Failover Interval: 30 seconds
Keepalive Interval: 15 seconds
Last keepalive sent: 17:42:40 UTC Jul 12 2019 (elapsed time: 00:00:15)
Last MGCP traffic time: 17:42:55 UTC Jul 12 2019 (elapsed time: 00:00:00)
VG320# show mgcp
MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE
MGCP call-agent: <CUCM IP> 2427 Initial protocol service is MGCP 0.1
MGCP validate call-agent source-ipaddr DISABLED
MGCP validate domain name DISABLED
MGCP block-newcalls DISABLED
These commands have been shortened to contain just the pertinent output. For additional information, you can look at these show outputs:
show mgcp show mgcp endpoint show mgcp connection show ccm-manager show voice port summary show isdn status show controller [t1/e1] x/x/x show call active voice brief show voice call summary show voice call status
If the previous show commands check out, you can run these debugs on the device to further determine why your call has failed:
debug mgcp [endpoint | error | events | packets] debug mgcp all (for advanced debugging) debug ccm-manager [backhaul | config-download | error | events] debug voip ccapi inout debug vpm signal debug voip vtsp session debug isdn q931
The previous debugs are a great place to start for what you need to troubleshoot registration and call setup issues.