Configuring MGCP Gateways

Hi all!
Today we will consider one of the options for connecting Cisco Unified Communications Manager (hereinafter referred to as CUCM) to the Public Switch Telephony Network (or PSTN). This is usually done with the voice gateways. A voice gateway is a device that combines two different telephone networks together, for example, when connecting an VOIP network to a traditional telephony network.
As you know, gateways can communicate with CUCM using the following signaling protocols:
– H323;
– SIP;
– MGCP.

The MGCP signaling protocol is used in corporate networks when we want to minimize the configuration done on the gateways themselves, as well as gain centralized control over them with a call processing server. In this bundle, the gateway always obeys the commands of the server, which in the terminology of the MGCP protocol is called the Call Agent. Thus, the MGCP protocol belongs to the category of “client-server” or “master-slave” signaling protocols. Note that without a server, an MGCP gateway cannot handle calls on its own.
So, what needs to be done to configure a Cisco voice gateway that integrates to the CUCM via MGCP? Let’s consider this on the example of connecting to the PSTN by E1 PRI link with EuroISDN (DSS1) signaling. We will illustrate the process with screenshots from the our lab CUCM.
Open the CUCM administration web interface and select Gateway in the Device tab:
Next, click on the Add New button to create a new gateway:

Then we select the Cisco gateway model (in this example, the 2811 router is used) and the MGCP signaling protocol:

The next step is to specify the name of the gateway (important!!! – it must match the hostname of the IOS gateway, otherwise the gateway will not register on the server), the type of slot, where the voice card is installed (in the example, the NM-HDV2 card located in the slot 1), and the type of signaling that will be used on all E1 links presented at the gateway. Information about the type of card and its slot number in the gateway can be obtained using the sh diag command (entered at the gateway). After all this, click the Save button:

After that, configure the subunit number in the slot and the type of the voice card. In our example, we use the E1 port built in the NM-HDV2 board. Don’t forget to click Save again:

The voice port icon appears:

Left click the appeared icon and go to the settings of the E1 link (there is a rather extensive area of ​​settings, so there are a few screenshots). First, specify which Device Pool the port belongs to:

Then we set the type of signaling for this E1 port (PRI EURO), the side of PRI interface Network / User, usually PBX in relation to the PSTN is always User, the method of seizing B-time slots Top Down / Bottom Up, as well as the law of speech companding (A-law / mu-Law). In addition, in the Call Routing Information – Outbound Call section, you can optionally set the type (TON) of the calling and called numbers, which is often required at the request of the PSTN service provider (shown in green):
At the very bottom of the settings area, you can find the settings responsible for the operation of the physical and frame levels of the E1 link. These are the type of digital line coding (HDB3), the frame structure (with or without CRC4), and the source of stream synchronization (External for connecting to the PSTN, since PBX synchronization is usually made by receiving a signal from the PSTN). At the end of the settings, click the Save button, in new versions of CUCM, you must also click the Apply Config button. Then don’t forget to Reset !!! the gateway in the CUCM web interface:
This completes the configuration on the CUCM side. CUCM also automatically creates a voice gateway configuration file in *.xml format, which is placed on a TFTP server (usually one of the servers in the CUCM cluster). This allows automatic voice gateway configuration.
Before you start downloading the configuration file to the gateway, you need to check whether the card type command is configured on the gateway, which determines the type of ports (E1 or T1) of the voice interface card. This command is required only for the voice card supporting both E1 and T1 links. If you have such a dual-mode voice card and this command is missing on the gateway, it must be configured as follows:
Router(config)#card type e1 s m – where s is the slot number and m is the subunit number for the port being configured
For our example (NM-HDV2 card in the slot 1 of the 2811 router), this command should be written like this:
Router(config)#card type e1 1 1
Without this command, the gateway with dual-mode voice card does not accept the configuration data for the E1 ports and, accordingly, then does not register on the CUCM. If you have just a single-mode voice card, this command is not used.
In order for the gateway to be able to load the configuration file, you need to implement the following Cisco IOS commands:
Router(config)#ccm-manager config server A.B.C.D
Router(config)#ccm-manager config
The first command is required to specify the IP address of the TFTP server where the gateway xml configuration file is stored. The second command enables the loading of the configuration file and automatic configuration of the gateway:
After that, the configuration file will be loaded into the gateway. The gateway parses the xml configuration and turns it into Cisco IOS settings. In the gateway configuration, MGCP relate IOS commands appear along with the settings of the E1 port.
The gateway registration check is performed on both the gateway and CUCM. First of all, using the sh mgcp command on the gateway, we check that the MGCP protocol is enabled and the gateway can see its CUCM server:

We check the status of the voice channels of the E1 link using the sh mgcp endpoint command. The voice channels must be assigned a conditional name (for example, S1/ds1-0/5@HQ-2) and its state must be active (UP):

Then you should check the state of the physical and frame layers of the E1 link, in other words, look at the state of the D-channel (16 Ts). With the correct settings, the D-channel will be activated (“up“), which corresponds to the state MULTIPLE_FRAME_ESTABLISHED. We check it on the gateway using the sh isdn status command. With this command, you can also see that the correct physical connection of the devices has been made (LAYER 1 STATUS: ACTIVE); in addition, it can be seen that the L3 signaling (Q.931) is tunneled to the call processing server (Q.931 IS BACKHAULED TO CCM MANAGER):

On the CUCM server, you can also see that the voice channels are registered (Device -> Gateway):

Necessary operations for configuring the MGCP gateway have been completed. Our gateway is ready to go. It remains to configure call routing on CUCM, and after that we will have a connection to the PSTN. Remember that the routing configuration order is as follows:
– Gateway / Trunk;
– Route Group;
– route list;
– Route pattern.
If there are problems with the operation of the MGCP gateway, the debug mgcp events and debug mgcp packets commands can be used to clarify the problem.