MGCP Overview

MGCP is an extension of the earlier version of the protocol Simple Gateway Control Protocol (SGCP) and supports SGCP functionality in addition to several enhancements. Systems using SGCP can easily migrate to MGCP, and MGCP commands are available to enable SGCP capabilities.

MGCP uses endpoints and connections to construct a call. Endpoints are sources of or destinations for data, and can be physical or logical locations in a device. Connections can be point-to-point or multipoint.

Similar to SGCP, MGCP uses User Datagram Protocol (UDP) for establishing audio connections over IP networks. However, MGCP also uses hairpinning to return a call to the PSTN when the packet network is not available.

MGCP packets are unlike those generated by many other protocols. Usually wrapped in UDP port 2427, the MGCP datagrams are formatted with whitespace, much like you would expect to find in TCP protocols. An MGCP packet is either a command or a response.

Commands begin with a four-letter verb. Responses begin with a three number response code.

There are nine (9) command verbs:

 AUEP, AUCX, CRCX, DLCX, EPCF, MDCX, NTFY, RQNT, RSIP

Two verbs are used by a Call Agent to query (the state of) a Media Gateway:

 AUEP - Audit Endpoint

 AUCX - Audit Connection

Three verbs are used by a Call Agent to manage an RTP connection on a Media Gateway (a Media Gateway can also send a DLCX when it needs to delete a connection for its self-management):

 CRCX - Create Connection

 DLCX - Delete Connection

 MDCX - Modify Connection

One verb is used by a Call Agent to request notification of events on the Media Gateway, and to request a Media Gateway to apply signals:

 RQNT - Request for Notification

One verb is used by a Call Agent to modify coding characteristics expected by the "line-side" on the Media Gateway:

 EPCF - Endpoint Configuration

One verb is used by a Media Gateway to indicate to the Call Agent that it has detected an event for which the Call Agent had previously requested notification of (via the RQNT command verb):

 NTFY - Notify

One verb is used by a Media Gateway to indicate to the Call Agent that it is in the process of restarting:

 RSIP - Restart In Progress

MGCP Architecture

The distributed system is composed of a Call Agent (or Media Gateway Controller), at least one Media Gateway (MG) that performs the conversion of media signals between circuits and packets, and at least one Signaling gateway (SG) when connected to the PSTN.

The Call Agent uses MGCP to tell the Media Gateway:

• what events should be reported to the Call Agent
• how endpoints should be connected together
• what signals should be played on endpoints.

MGCP also allows the Call Agent to audit the current state of endpoints on a Media Gateway.

The Media Gateway uses MGCP to report events (such as off-hook, or dialed digits) to the Call Agent.

(While any Signaling Gateway is usually on the same physical switch as a Media Gateway, this needn't be so. The Call Agent does not use MGCP to control the Signaling Gateway; rather, SIGTRAN protocols are used to backhaul signaling between the Signaling Gateway and Call Agent).

Every issued MGCP command has a transaction ID and receives a response.

Typically, a Media Gateway is configured with a list of Call Agents from which it may accept programming (where that list normally comprises only one or two Call Agents). In principle, event notifications may be sent to different Call Agents for each endpoint on the gateway (as programmed by the Call Agents, by setting the NotifiedEntity parameter). In practice, however, it is usually desirable that at any given moment all endpoints on a gateway should be controlled by the same Call Agent; other Call Agents are available only to provide redundancy in the event that the primary Call Agent fails, or loses contact with the Media Gateway. In the event of such a failure it is the backup Call Agent's responsibility to reprogram the MG so that the gateway comes under the control of the backup Call Agent. Care is needed in such cases; two Call Agents may know that they have lost contact with one another, but this does not guarantee that they are not both attempting to control the same gateway. The ability to audit the gateway to determine which Call Agent is currently controlling can be used to resolve such conflicts.

MGCP assumes that the multiple Call Agents will maintain knowledge of device state among themselves (presumably with an unspecified protocol) or rebuild it if necessary (in the face of catastrophic failure). Its failover features take into account both planned and unplanned outages.

MGCP Call Flows

This section illustrates a few typical call flows with an explanation of the semantics of each message. The call flows are presented in order of increasing complexity. Note that the call flows presented here are shown as an example for illustration purposes. An implementation for a particular vendor of MGCP might follow a different call flow.

Basic MGCP Call Flow

A simple point-to-point call is set up using two different commands: CreateConnection and ModifyConnection.

Figure M-01 shows a call flow for a call setup between two endpoints. The endpoints are assumed to be on different gateways, and the MGC controls both the gateways. Only the relevant portions of the messages are shown in the figure. The originating side and a terminating side of this two-party call are labeled with suffixes Orig and Term, respectively. Messages in the figure are labeled numerically, and the corresponding label is referenced in the explanation that follows. Of course, the labels are not part of the MGCP messages.

Figure M-01

The call agent sends an initial CRCX to the GW-Orig and specifies endpoint S1/DS1-0/1. The connection mode is set to recvonly. This setting indicates to the GW-Orig that the endpoint should receive media from the IP network but not send media to the IP network. This is necessary because the call agent has not set up the connection on GW-Term and hence does not know the session description at that end.

GW-Orig responds with a 200/OK indicating that the connection was created successfully and providing a local session description (encoded per SDP specification). This session description includes the local IP and port (1.1.1.1 and 11111) that the gateway has opened to receive RTP streams. SDP also indicates that the codec being used is G.711µ-law (denoted by RTP/AVP 0).

The call agent then sends a CRCX to endpoint S1/DS1-0/1 on GW-Term. The session description received from GW-Orig is included in the RemoteConnectionDescriptor of this CRCX, and the mode is set to sendrecv.

GW-Term responds with a 200/OK and includes its own session description in the response.

The call agent passes the SDP of GW-Term to GW-Orig in a MDCX command and changes the connection mode to sendrecv.

After GW-Orig executes the MDCX command and responds with 200/OK, call setup is complete and RTP streams flow between GW-Orig and GW-Term.