MGCP Operation

To understand MGCP, you must understand the concepts of endpoints and connections, and events and signals.

An endpoint can be either the source or the destination for a media stream. Some examples are an analog or digital line, or a virtual endpoint such as DSP resources used by a conference bridge. One gateway can support multiple endpoints. Endpoint names have two componentsa local identifier, and a gateway identifier. The entire name consists of the local identifier, followed by the @ symbol, and then the gateway identifier. For example:

local_identifier@gateway_identifier.domain_name

The gateway identifier is its configured hostname, such as "BoiseRTR01." If the gateway is configured with a domain name, it is appended to the end of the hostname, such as "BoiseRTR01.company.com."

The format of a local identifier varies depending on the type of interface. The local identifier for analog ports uses the following syntax:

Endpoint type/Slot #/Subunit #/Port #

For example, an endpoint name for an FXO port might look something like this:

AALN/S0/SU0/1@VoiceGW

where

• AALN (Analog Access Line Endpoint) means that it is either an FXS or FXO interface.
• S0 is the slot number that contains the voice module.
• SU0 (for Subunit 0) is the slot within the network module that holds the voice interface card (VIC) or voice/WAN interface card (VWIC).
• 1 is the number of the voice port on the VIC or VWIC.
• VoiceGW is the hostname of the gateway.

The local identifier for digital interfaces uses the following syntax:

Slot #/Trunk type-Port #/B channel #

For example, the endpoint name for a T1 PRI interface might look something like this:

S0/ds1-0/1@VoiceGW.cisco.com

where

• S0 is the slot number that contains the voice module.
• ds1 means that the trunk type is a DS-1. Other trunk type values include ds3, e1, and e3.
• -0 is the port number within the slot.
• 1 identifies ISDN B-channel number 1.
• VoiceGW.cisco.com is the hostname of the gateway, with its domain name appended.

Connections are created on endpoints when you need to make a call. Connections have properties, such as codec, IP address, port number, bandwidth, and encryption. MGCP uses the Session Description Protocol (or SDP, defined in RFC 2327) to inform CallManager about these details of the connection.

Endpoints generate events, such as when a phone on an FXS port goes off-hook or dials digits. Cisco CallManager can ask to be notified when it receives specific events on its gateways.

The CallManager can then instruct the gateway to send signals, such as dial tone or ringing.

MGCP Messages

MGCP uses nine types of messages between the gateway and CallManager to control the endpoints and connections. The receiver must acknowledge each message. Messages between the CallManager and the gateway are sent by default to port 2427.

Understanding these messages helps in troubleshooting issues with your MGCP gateway. The following is a description of the MGCP messages. Figures 2-1 through 2-3 illustrate their use.

Figure 2-1. Registering an MGCP Gateway with CallManager

When the CallManager needs to make a call to an endpoint that is connected to a gateway, it sends a CreateConnection (CRCX) command. Included in this message are the parameters to be used for the connection. These might include such things as the following:

• Bandwidth to be used for the call
• Codec to be used
• QoS settings
• Encryption
• Voice activity detection (VAD)
• Echo cancellation
• RSVP

The gateway responds to the CRCX message with one of the return codes. If the gateway accepts the request to create the connection, it responds with 200 OK, which includes information about the session such as IP address and media type (RTP audio, for example.) This session information is carried using SDP (RFC 2327).

If the CallManager wants the gateway to watch for certain events on an endpoint, it sends a NotificationRequest (RQNT) listing the type of event to watch for. Typically, the gateway is instructed to look for a phone going off or on hook, or digits being dialed.

The gateway answers with a Notify (NTFY) message. When the CallManager detects one of these events, it uses a NotificationRequest message to instruct the gateway to respond appropriately (for instance, to provide a dial tone.)

Based on the events received, the connection might be changed. For instance, if the gateway sets up the connection for a voice call and then notices fax tones, CallManager changes the encoding. The CallManager changes these parameters with a ModifyConnection (MDCX) command containing the new connection settings.

To terminate a connection, the CallManager sends the gateway a DeleteConnection (DLCX) command.

The gateway then sends a return code in response to the request to delete connection. If the gateway accepts the request, it sends a 200 OK message with the following statistics about the connection to the CallManager:

• Number of packets sent
• Number of bytes sent
• Number of packets received
• Number of bytes received
• Number of packets lost
• Average jitter
• Average transmission delay

The CallManager uses an AuditEndpoint (AUEP) message to find information and status on the endpoint. It sends one AUEP message per endpoint.

The CallManager can learn the parameters that are associated with a connection by using the AuditConnection (AUCX) command.

The EndpointConfiguration (EPCF) command instructs the gateway about configuration to be applied to the endpoint.

The gateway initiates a RestartInProgress (RSIP) message to the CallManager when an endpoint or group of endpoints are going out of or coming into service, or when the gateway will restart. Three types of restarts exist:

• Graceful The restart is delayed to allow any existing connections to finish their calls.
• Forced This restart occurs immediately, and all connections are lost.
• Restart The gateway itself is going to reboot.

Registering with CallManager

An MGCP gateway must register with its CallManager before accepting calls. Figure 2-1 illustrates the process that an MGCP gateway follows when registering with a Cisco CallManager.

The transactions in Figure 2-1 are as follows: