Introduction to MGCP

MGCP was created for a centralized architecture, where most of the configuration and call-control intelligence resides on a call agent, such as Cisco CallManager. The traditional role of an MGCP gateway is media translation. PSTN connections, such as Foreign Exchange Office (FXO), Foreign Exchange Station (FXS), and PRI lines, typically terminate in the gateway. The gateway then translates between the PSTN and the IP network. MGCP gateways are sometimes divided into two categories:

• Residential gateways Interfaces between analog (RJ11) ports and the Voice over IP (VoIP) network
• Trunking gateways Interfaces between PSTN trunks such as DS0s or PRIs and the VoIP network

This is somewhat of an artificial distinction, because MGCP gateways can contain both analog and trunk interfacesthus functioning as both types of gateways, in addition to IP WAN interfaces.

An MGCP gateway routes calls in response to instructions from the call agent (in this case the Cisco CallManager). These calls could be to or from a telephone on the PSTN, or across a WAN to an IP or analog phone at a remote site. The gateway does not make call routing decisions. It needs to be able to reach a CallManager before it can handle calls. You can specify multiple CallManagers for the gateway to use. CallManager also controls other aspects of the call, such as the use of Resource Reservation Protocol (RSVP). Caller ID is available on digital lines but not on analog lines.

MGCP is an extensible protocol. Added functionalities are described as packages. In Chapter 8, "Connecting to an IP WAN," the section on WAN security describes the Secure Real-Time Protocol (SRTP) package that you can use to encrypt voice traffic. Other packages include capabilities for Real-Time Protocol (RTP), trunks, dual tone multifrequency (DTMF) tones, and announcement servers. You can see the full list in the output of the global configuration command mgcp package-capability ?.

When you are using an MGCP gateway, all the dial plan knowledge resides on the CallManager. You do not need to configure dial peers, unlike H.323 and SIP. However, this leaves the gateway unable to route calls if it cannot reach a CallManager. To remedy this, the MGCP Fallback feature was developed to allow gateways to fall back to using H.323 when a CallManager is unavailable. Fallback configuration enables the voice ports that were registered to the Cisco CallManager using MGCP to be available for routing calls to the PSTN. This is frequently used in conjunction with Survivable Remote Site Telephony (SRST) on the MGCP gateway. When IP phones register with the SRST router, they can use these voice ports.

MGCP is the protocol of choice when you need any of the following features:

• Centralized dial-plan control and management
• Simplified gateway configuration
• MGCP backhaul for Q Signaling (QSIG) connections, and PRI QSIG facility IE decoding

As with any protocol, MGCP has its pros and cons.

Pros

MGCP pros are as follows:

• Ease of configuration The gateway can download much of its configuration from the CallManager. You need to configure dial peers for any voice ports that you will use for H.323 fallback, such as during SRST operation.
• Ease of administration Because the call intelligence resides in the call agent, the management of multiple gateways is centralized. You can create customized, granular dial plans centrally at the Cisco CallManager, allowing the network to scale to large IP Telephony deployments.
• Call survivability for analog and T1 channel-associated signaling (CAS) calls MGCP gateways preserve active calls using analog these voice ports and T1 CAS ports during failover to a backup CallManager and during transition to SRST. (However, any backhauled PRI and BRI ports are dropped when a connection to the CallManager is lost.)
• Encryption of voice traffic MGCP was the first gateway protocol to support the encryption of voice traffic using SRTP in a Cisco-based network.
• QSIG functionality When connecting to a PBX using QSIG, MGCP BRI/PRI Backhaul enables the decoding of facility IE messages by the CallManager. Calling name and redirect number, which are carried in the facility IE, are therefore available only when using MGCP trunks. You might need this function for voice-mail access. (See Chapter 7, "Connecting to PBXs," for an explanation of QSIG.)

Cons

MGCP cons are as follows:

• Dependence on call agent The lack of call intelligence on the gateway means that it must depend on a call agent, and network administrators must make backup plans in case the call agent becomes unavailable. Otherwise, you cannot place new calls. Thus, you need SRST and H.323 fallback.
• Lack of call survivability for PRI and BRI calls Any active calls using a PRI and BRI port that is being backhauled to the CallManager are dropped when a connection to the CallManager is lost. Although MGCP supports various methods for fax calls, CallManager does not support the signaling and negotiation of any of the fax methods for MGCP gateways.
• Lack of call survivability for PRI and BRI calls Any active calls using a PRI and BRI port that is being backhauled to the CallManager are dropped when a connection to the CallManager is lost.
• Fax calls Although MGCP supports various methods for fax calls, CallManager does not support the signaling and negotiation of any of the fax methods for MGCP gateways. H.323 now supports SRTP.
• No caller ID with FXO ports The current implementation of MGCP does not pass along caller ID information when a call comes from an FXO port.