Media Gateway Control Protocol (MGCP), a successor to Simple Gateway Control Protocol (SGCP), is an implementation of the MGCP architecture for controlling media gateways on IP networks connected to the plain old telephone service (POTS). MGCP is defined in RFC 3435 and is a text-based master/slave protocol, with a call-control agent as master and a controlled gateway as slave. MGCP uses Session Description Protocol (SDP) for specifying and negotiating the media streams. MGCP leverages UDP port 2427 for control traffic and TCP port 2428 for backhaul (explained later in this section). Due to its master/slave nature, MGCP allows the centralization of dial plans because the dial plan intelligence is with CUCM.
The MGCP architecture defines MGCP Media Gateway Control (MGC) and Media Gateway (MG). MGC is a call-control agent such as CUCM and has the call-control intel-ligence, thus it controls the MG’s analog (FXS/FXO) or digital (T1-PRI/T1-CAS) port/
endpoint/trunk.
Command from a call-control agent to an MGCP-controlled gate-way for creating a new connection between two MGCP endpoints.
The connection creation is based on parameters such as codec, allowable bandwidth, gain control, silence suppression, and so on.
ModifyConnection (MDCX)
Command from a call-control agent to an MGCP-controlled gateway that modifies the parameters associated with an existing connection.
DeleteConnection (DLCX)
Bidirectional command that is used by a call-control agent to inform the gateway that it should terminate a connection. A gateway can also send this command to indicate that a connection needs to be terminated. The gateway also sends statistics associated with the connection when contacting the call-control agent.
EndpointConfiguration (EPCF)
Configuration command from a call-control agent to an MGCP-controlled gateway. It configures the gateway with the bearer infor-mation, which specifies whether audio calls will be encoded using mu-law or A-law.
ptg13358382 MGCP Call State Description
NotificationRequest (RQNT)
Command from a call-control agent to an MGCP-controlled gate-way to instruct the gategate-way to inform the call-control agent when specific events such as on-hook/off-hook actions or DTMF tones occur on a specified endpoint.
AuditEndpoint (AUEP) Command from a call-control agent to an MGCP-controlled gate-way to audit the status of an endpoint (port), such as bearer infor-mation, signal status, and event status.
AuditConnection (AUCX)
Command from a call-control agent to an MGCP-controlled gate-way to discover the status of a connection, such as connection mode, call ID, and connection parameters.
Notify (NTFY) Command from a gateway to a call-control agent to inform the call-control agent when requested events occur such as on-hook/off-hook and digit reception.
RestartInProgress (RSIP) Command from a gateway to a control agent to inform the call-control agent that the gateway is taking an endpoint or group of endpoints out of service or returning an endpoint or group of end-points to service. There are three types of restart: Restart (endpoint in service), Graceful (wait until call clearing), and Forced (endpoint out of service).
MGCP also uses certain return codes that reflect different events occurring on the gate-way and, accordingly, enables the gategate-way to update the call-control agent. Following are the types of MGCP return codes defined in RFC 3661:
■ 000: Response acknowledgement message ■ 1XX: Transaction execution-related messages ■ 2XX: Transaction successful messages ■ 4XX: Transient error messages ■ 5XX: Permanent error messages
MGCP messages are sent on UDP port 2427, and TCP port 2428 is used to exchange kee-palive packets between an MGCP-controlled gateway and CUCM. This allows for MGCP PRI/BRI backhaul between an MGCP gateway and CUCM wherein the backhaul is used to transport ISDN Q.931 (D channel signaling) information from the gateway to CUCM.
This allows CUCM to recognize the status of ISDN Layer 3 for the port/endpoint/trunk being controlled on the MGCP gateway.
Example 3-1 shows the MGCP configuration for a voice gateway.
ptg13358382 VoIP Signaling Protocols 63
Example 3-1 MGCP Gateway Configuration
MGCPRouter(config)# ccm-manager fallback-mgcp MGCPRouter(config)# ccm-manager switchback graceful
MGCPRouter(config)# ccm-manager redundant-host 10.76.108.146 10.76.108.147 MGCPRouter(config)# ccm-manager music−on-hold
MGCPRouter(config)# ccm-manager mgcp
!
MGCPRouter(config)# mgcp
MGCPRouter(config)# mgcp call-agent 10.76.108.146 2427 service-type mgcp version 0.1 MGCPRouter(config)# mgcp bind control source- interface loopback 0
MGCPRouter(config)# mgcp bind media source-interface loopback 0/0 MGCPRouter(config)# mgcp dtmf-relay codec all mode out-of-band
!
MGCPRouter(config)# dial-peer voice 999 pots MGCPRouter(config-dial-peer)# service mgcpapp MGCPRouter(config-dial-peer)# port 1/0/1:23
In Example 3-1 , the ccm-manager fallback-mgcp command enables CUCM fallback when a CUCM server is unavailable. The command ccm-manager switchback graceful enables graceful switchback from one CUCM server to another in case of a CUCM server failure. Other options are immediate , never , schedule-time , and uptime-delay . The com-mand ccm-manager redundant-host defines redundant hosts (CUCM servers) for the MGCP gateway to connect with. The command ccm-manager music-on-hold enables MoH.
The command mgcp call-agent defines call-control agents for the MGCP gateway. The commands mgcp bind control source-interface and mgcp bind media source-interface bind signaling and media, respectively, to the desired interface (physical, logical, or loop-back). The command mgcp dtmf-relay codec defines DTMF-related parameters. Finally, mgcpapp associates a dial peer with an MGCP application.
Optionally, the MGCP gateway can download the configuration from CUCM and auto-configure per the parameters defined on CUCM:
UCRouter(config)# ccm-manager config server 10.76.108.146 UCRouter(config)# ccm-manager config
In the previous configuration, the command ccm-manager config server defines the server that the gateway should contact for downloading the XML config file, and ccm-manager config enables the download.
From the Library of Juan Arcaya
ptg13358382 To add an MGCP gateway in CUCM, follow these steps:
1. Go to the Cisco Unified CM Administration page and choose Device > Gateway . 2. Click Add New .
3. From the Gateway Type drop-down menu, choose the MGCP gateway type that you want to add, followed by MGCP as the protocol.
4. Enter the gateway Domain Name (such as MGCPRouter.corp.com), enter a descrip-tion, and select the appropriate CUCM Group.
5. Configure the Slot/VIC/Endpoint. Click Save .
6. Select the subunit (depending on the router model number) and configure the same.
An MGCP gateway registers to its preferred CUCM server (as defined in CUCM Group and on the gateway itself). Figure 3-3 illustrates the MGCP call flow between a CUCM server and MGCP endpoints registered to it.
Notification Request (RQNT)
MGCP Gateway A CUCM MGCP Gateway B
Notification Request (RQNT) RQNT Response
CRCX with RQNT CRCX Response
RTP
DLCX DLCX Response RQNT Response
Notify (NTFY) (Off Hook and Dial) Create Connection (CRCX)
CRCX Response
Modify Connection (MDCX) MDCX Response
RTP NTFY (On Hook)
DLCX DLCX Response
V V
Figure 3-3 MGCP Call Flow Between Two Gateways Registered to Same CUCM Server
ptg13358382 VoIP Signaling Protocols 65
The following events occur during the MGCP call flow illustrated in Figure 3-3 :
1. The call-control agent (CUCM) sends a notification request (RQNT) to each gateway.
The request instructs the gateways to wait for an off-hook transition (event). When the off-hook transition event occurs, the call-control agent instructs the gateways to supply a dial tone (signal).
2. The gateways respond to the request (RQNT). The gateways and the call-control agent wait for a triggering event.
3. An endpoint/user on Gateway A goes off-hook. The gateway provides a dial tone.
4. Gateway A sends a notify (NTFY) to CUCM to advise that a requested event has occurred, followed by identifying the endpoint and the event (that is, the dialed digits).
5. CUCM does digit analysis and, after confirming that a call is possible based on the dialed digits, instructs Gateway A to create a connection (CRCX) with its endpoint (port/trunk).
6. The gateway responds with a session description if it is able to accommodate the connection. The session description identifies (at least) an IP address and UDP port for use in a subsequent RTP session.
7. CUCM sends a connection request to Gateway B. In the request, CUCM provides the session description obtained from Gateway A. CUCM also sends a notification request that instructs Gateway B about the signals and events that it should now con-sider relevant, such as ringing and the endpoint’s off-hook transition.
8. Gateway B responds to the request with its session description to CUCM.
9. CUCM relays the session description received from Gateway B to Gateway A in a modify connection request (MDCX). This request might contain an encapsulated notify request that describes the relevant signals and events at this stage of the call setup. Gateway A responds to the request.
10. Now that Gateway A and Gateway B have the required session descriptions to estab-lish the RTP session, they open an RTP stream over pre-negotiated (CUCM relayed) IP addresses and UDP ports.
11. The endpoint/user on Gateway A terminates the call and goes on-hook. CUCM requested a notification of such an event, so Gateway A notifies CUCM.
12. CUCM sends a delete connection (DLCX) request to each gateway so the session can be terminated.
13. The gateways delete the connection and respond to CUCM.