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:
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:
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:
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 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:
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:
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:
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:
A TCP connection is opened between the gateway and CallManager.
The gateway sends an RSIP message to the CallManager to inform it that it is coming into service.
The CallManager sends the gateway one AUEP message per endpoint. This message requests information on the attributes and capabilities of the endpoint. Figure 2-1 shows just two AUEP messages for the sake of simplicityCallManager actually sends an AUEP message for each DS0 in the PRI.
The gateway acknowledges with an ACK that contains the endpoint information.
The CallManager responds with an RQNT message per endpoint, listing the events it wants to be notified of.
The gateway acknowledges those messages. The gateway, along with its endpoints, is then registered with the CallManager.
Call Flow with MGCP
Part I: Voice Gateways and Gatekeepers
Gateways and Gatekeepers
Part II: Gateways
Media Gateway Control Protocol
Session Initiation Protocol
Connecting to the PSTN
Connecting to PBXs
Connecting to an IP WAN
Influencing Path Selection
Configuring Class of Restrictions
SRST and MGCP Gateway Fallback
Using Tcl Scripts and VoiceXML
Part III: Gatekeepers
Part IV: IP-to-IP Gateways
Cisco Multiservice IP-to-IP Gateway
Appendix A. Answers to Chapter-Ending Review Questions