MGCP Gateways

MGCP was defined by the IETF in RFC 2705. Many companies, including Cisco, have chosen to support the IETF draft and have interoperability among products.

MGCP is a text-based protocol, which means that, given the raw data used to encode an MGCP message, if your computer were asked to print it, you could read the message. In contrast, H.323 is binary-based, so printing raw Q.931 messages results in a string of gobbledy-gook punctuated with entertaining beeps.

Unlike H.323, which is a peer-to-peer protocol, MGCP is more like a client/server protocol. MGCP is based on the concept of a Media Gateway Controller (MGC). The MGC serves as the call signaling and media control signaling intelligence for gateway devices (termed "endpoints," as in H.323) that are essentially slaves to the MGC. Gateway devices terminate circuit-switched signaling interfaces and, via MGCP, provide a set of primitives whereby the MGC can establish, modify, and tear down media, as well as receive rudimentary call-related signaling and feature invocations.

Therefore, MGCP is quite different in philosophy from H.323. While H.323 defines a protocol by which quite intelligent, self-contained endpoints can communicate, MGCP provides a protocol that pushes many call-related decisions to the MGC. On one hand, this reduces the amount of duplicate configuration neededwith an MGCP gateway, CallManager provides the call routing intelligence, while with a Cisco H.323 gateway, you must configure dial peers to handle the routing of circuit-switched calls to the packet side and vice versa.

On the other hand, MGCP gateways are like every other VoIP device that CallManager controls. While each CallManager endpoint supports a variety of call signaling (SCCP, MGCP, H.225, SIP, SGCP) and media control (SCCP, MGCP, H.245, SDP, SGCP) protocols, when the call is finally established, endpoints encapsulate the media using RTP.

MGCP Messages

MGCP commands are the interface whereby CallManager receives basic signaling notifications from MGCP gateways and directs the gateway to establish, modify, and tear down media connections.

The gateway communicates these notifications and CallManager sends these commands using User Datagram Protocol (UDP).

Table 4-9 summarizes these commands, which fall into three classes:

• Event triggers and notifications enable CallManager and the MGCP gateway to communicate call signaling events. The events communicated are sufficient to support such analog interfaces such as FXO and FXS, but not digital interfaces.
• Media establishment, modification, and teardown commands enable CallManager to manage connections on the gateway's IP interfaces to establish VoIP calls between the gateway and other VoIP devices.
• Restart- and failover-related messages enable CallManager to manage the gateway during registration and determine the state of existing calls when the gateway has lost its connection to a primary CallManager.

Table 4-9. MGCP Command Summary

Command Code	Command	Description
Event Triggers and Notifications
RQNT request	Requests gateway to send notifications of specified events such as off-hook events and digit keypresses.
NTFY	Notify	Allows a gateway to report the occurrence of the requested events.
Media Establishment, Modification, and Teardown Commands
CRCX connection	Requests the gateway to create a connection to another endpoint.
MDCX	Modify connection	Modifies the characteristic of an existing gateway connection.
DLCX	Delete connection	Deletes a gateway connection.
Restart- and Failover-Related Messages
AUEP of an endpoint, including connection state, codecs, and so on.
AUCX	Audit connection	Audits a connection to get the call ID.
EPCF	Endpoint configuration	Specifies the encoding of the signals an endpoint receives. For example, in certain international telephony configurations, some calls carry m-law-encoded audio signals and others use A-law.
RSIP	Restart in progress	Allows a gateway to notify CallManager that a restart has occurred.

 

Q.931 Backhaul

MGCP is designed primarily for managing media. The word, after all, is part of the protocol's name. The signaling primitives aren't inherently powerful enough to communicate the information that circuit-oriented digital protocols such as Q.931 provide.

As a result, Cisco MGCP gateways running circuit-switched digital protocols such as PRI rely on a practice called backhauling. Although MGCP gateways that support digital interfaces do terminate the ITU-T Q.921 protocol (which ensures message integrity over the trunk itself), rather than terminate the call signaling protocol these gateways simply pass the Q.931 messages to CallManager for processing.

Figure 4-22 compares the practice of backhauling in MGCP versus the architecture of H.323. In H.323, the H.323 endpoint serves as a gateway for the media, for the media control signaling, and for the call signaling. In Cisco MGCP gateways, however, the gateway serves as a gateway for just the media (RTP on one side/circuit-switched media on the other) and the media control (MGCP on one side/Q.931 bearer negotiation on the other), but not for the call signaling, which is negotiated directly from the MGC to the circuit-switched network. (In contrast to the Layer 3 signaling, the gateway does terminate the Layer 2 signaling.)

Figure 4-22. Signal Backhauling with MGCP

Figure 4-23 demonstrates the signaling that occurs when CallManager receives a call from an MGCP FXS/FXO gateway. In this diagram, all messages are MGCP. All MGCP messages have acknowledgement messages. This message flow diagram eliminates acknowledgement messages in the interest of brevity, with the exception of one: the arrow labeled "200 c = IN IP4 10.83.129.8 m = audio 16396" indicates the successful receipt by the gateway of the CallManager's command to create a connection and provides the IP address and port to be used for the media.

Figure 4-23. Analog MGCP Call

Figure 4-24 demonstrates the signaling that occurs when CallManager receives a call from an MGCP PRI gateway. This diagram contains a mixture of MGCP and PRI signaling and omits most MGCP acknowledgement messages. Backhauled signaling passes through the gateway either from or to the right side of the figure.

Figure 4-24. Digital MGCP Call

 

MGCP Gateway Failover

MGCP gateways register with CallManager based on their gateway configuration information. Once the gateway determines the IP address of CallManager, it establishes a TCP connection with CallManager for the purpose of sending backhauled Q.931 messages and sends a registration request.

If an MGCP gateway loses its connection to CallManager, there might be several calls in progress on the gateway. CallManager supports a feature called call preservation, which allows users on established calls to continue conversing. Though gateways and other endpoints must have connectivity to CallManager to establish calls, once the call has been answered, the signaling and media control channels are not actively used. By default, call preservation is available only for Cisco MGCP gateways, because the H.323 standards require existing calls to clear if the H.225 or H.245 connection is lost. However, you can override this behavior in Cisco IOS gateways using the no h225 timeout keepalive command.

Cisco MGCP gateways backhaul their Q.931 signaling, but not their Q.921 signaling. As a result, if the connection from the gateway to CallManager drops, the circuit-switched side of the call need not be aware. Because, in VoIP, media streams directly from one endpoint to another, if an MGCP gateway loses its connection to CallManager for an already-active call, rather than clear the circuit-switched connection it can leave its connection up and continue to send and receive media on the IP side. When the circuit-switched side hangs up, or when the gateway begins receiving ICMP "destination unreachable" or "port unreachable" message on its IP media connection(s), the gateway can free up the circuit resource. When an MGCP gateway loses its connection to CallManager, the gateway automatically clears calls that have not yet reached an active state.

Until the gateway reregisters, unused channels on the gateway are unavailable to place or receive calls, because MGCP relies on a VoIP signaling connection to CallManager. Conversely, if the gateway immediately reregisters, it must have some way to inform its new CallManager which channels are in use; otherwise, CallManager might attempt to offer a new call to one of the circuits already in use.

So when an MGCP gateway loses its connection, it sends the Restart in Progress (RSIP) message to its backup CallManager. If the MGCP gateway is supporting an FXS/FXO or T1-CAS interface, CallManager responds with a Notification Request (RQNT), requesting to be notified of off-hook events from each configured endpoint on the MGCP gateway. CallManager then sends Audit Endpoint (AUEP) messages to each channel the gateway manages, and the gateway responds with the idle, busy, and out-of-service status of each endpoint. Once initialized, the MGCP gateway maintains existing calls and starts the initialization sequence with the tertiary CallManager node in the case of a failure of the secondary while simultaneously monitoring the connection to the primary CallManager so it can reregister should it become available again. After the gateway sends the registration to CallManager, CallManager creates a device process to handle the gateway communication and then informs the device manager process of the gateway registration. The device manager propagates the device registration information to all CallManager servers in the cluster so that the route list information is accurate for all CallManagers in the cluster. The gateway is available to place and receive calls again.