The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to configure and troubleshoot the Media Gateway Control Protocol (MGCP). MGCP is a Call Agent/Endpoint protocol.
There are no specific requirements for this document.
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, ensure that you understand the potential impact of any command.
Note: 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 Cisco IOS® and Cisco IOS® XE.
Attribute
Definition
Call Agent
The Call Control elements that play the Primary role and provide centralized call intelligence.
Endpoints
The Endpoints are the devices that the Call Agents control. Such as: FXO, FXS, or a DS0 channel.
PSTN
Public Switched Telephone Network.
The Media Gateway Control Protocol (MGCP) is defined by RFC 2705. MGCP is a Call Agent/Endpoint protocol, where the Endpoint is controlled by a Call Agent of some type. The entire control intelligence is controlled by a Call Agent 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:
Examples:
This document has broken out each of the configuration components into individual steps.
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 10.50.217.100 2427 service-type mgcp version 0.1 VG320(config)# ccm-manager config server 10.50.217.100 VG320(config)# ccm-manager config VG320(config)# ccm-manager mgcp VG320(config)# 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 choose a Gateway Type. Use this drop down in order to choose the hardware you plan to register, and select Next to choose 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:
VG320
However, if you have a domain name configured on the gateway, you need to configure the Fully Qualified Domain Name of this device:
Now, choose Save. This updates the page and allows you to select a Subunit. Once you select a Subunit, choose 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 can enter additional values 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:
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.
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 is 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 about this. After the Restart is complete, CUCM sends a RQNT with the parameter R: L/hd. What this does is denote that the Gateway must notify CUCM of an Off-hook event.
At this point, the CUCM sends an Audit Endpoint (AUEP) 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:
000138: *Apr 23 19:41:49.010: MGCP Packet sent to :2427---> RSIP 39380951 aaln/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 RM: restart <--- 000139: *Apr 23 19:41:49.030: MGCP Packet received from :2427---> 200 39380951 <--- 000140: *Apr 23 19:41:49.030: MGCP Packet received from :2427---> RQNT 3 AALN/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 X: 2 R: L/hd Q: process,loop <--- 000141: *Apr 23 19:41:49.030: MGCP Packet sent to :2427---> 200 3 OK <--- 000142: *Apr 23 19:41:49.050: MGCP Packet received from :2427---> AUEP 4 AALN/S0/SU0/0@VG320.dillbrowLab.local MGCP 0.1 F: X, A, I <--- 000143: *Apr 23 19:41:49.050: MGCP Packet sent to :2427---> 200 4 I: X: 2 L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-110, a:G.726-16;G.728, b:16, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-70, a:G.726-24, b:24, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:10-50, a:G.726-32, b:32, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, gc:1, s:on, t:10, r:g, nt:IN, v:T;G;D;L;H;R;ATM;SST;PRE M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtestMGCP Call Setup
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 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 finished, 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:
001005: *May 13 14:28:15.633: MGCP Packet received from :2427---> CRCX 174 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 X: 21 L: p:20, a:PCMU, s:off, t:b8 M: recvonly R: L/hu Q: process,loop <--- 001006: *May 13 14:28:15.637: MGCP Packet sent to :2427---> 200 174 OK I: 6 v=0 c=IN IP4 m=audio 16410 RTP/AVP 0 101 100 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 <--- 001007: *May 13 14:28:15.789: MGCP Packet received from :2427---> RQNT 175 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 X: 22 R: L/hu S: G/rt Q: process,loop <--- 001008: *May 13 14:28:15.789: MGCP Packet sent to :2427---> 200 175 OK <--- 001009: *May 13 14:28:17.793: MGCP Packet received from :2427---> MDCX 176 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 I: 6 X: 23 L: p:20, a:PCMU, s:off, t:b8 M: sendrecv R: L/hu, L/hf, D/[0-9ABCD*#] S: Q: process,loop v=0 o=- 6 0 IN EPN AALN/S0/SU1/0@VG320.dillbrowLab.local s=Cisco SDP 0 t=0 0 m=audio 18946 RTP/AVP 0 101 c=IN IP4 a=rtpmap:101 telephone-event a=fmtp:101 0-15 <--- 001010: *May 13 14:28:17.797: MGCP Packet sent to :2427---> 200 176 OK <--- 001011: *May 13 14:28:17.797: MGCP Packet received from :2427---> RQNT 177 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 X: 24 R: L/hu, D/[0-9ABCD*#], L/hf S: Q: process,loop <--- 001012: *May 13 14:28:17.797: MGCP Packet sent to :2427---> 200 177 OK <--- 001015: *May 13 14:28:20.813: MGCP Packet received from :2427---> DLCX 178 AALN/S0/SU1/0@VG320.dillbrowLab.local MGCP 0.1 C: A000000001b79063000000F5 I: 6 X: 25 R: L/hd S: Q: process,loop <--- 001016: *May 13 14:28:20.845: MGCP Packet sent to :2427---> 250 178 OK P: PS=151, OS=24160, PR=146, OR=23360, PL=0, JI=0, LA=0Troubleshoot MGCP
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 First Backup None Second Backup None Current active Call Manager: 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: 2427 Initial protocol service is MGCP 0.1 MGCP validate call-agent source-ipaddr DISABLED MGCP validate domain name DISABLED MGCP block-newcalls DISABLEDThese 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 statusIf 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 q931The previous debugs are a great place to start for what you need to troubleshoot registration and call setup issues.
