| An understanding of the features and functions of the Media Gateway Control Protocol (MGCP), its components, and the relationships that the components establish with each other is important when implementing a scalable, resilient, and secure MGCP environment. The MGCP environment is an example of a centralized call control model. This section describes how to configure MGCP on a gateway, as well as the features and functions of the MGCP environment. MGCP and Its Associated Standards MGCP defines an environment for controlling telephony gateways from a centralized call control component known as a call agent. MGCP gateways handle the translation of audio between the telephone SCN and the packet-switched network of the Internet. These gateways interact with a call agent that performs signaling and call processing. IETF RFC 2705 defines MGCP. Additionally, RFC 2805 defines an architecture for MGCP. These IETF standards describe MGCP as a centralized device control protocol with simple endpoints. The MGCP protocol allows a central control component, or call agent, to remotely control various devices. This protocol is referred to as a stimulus protocol, because the endpoints and gateways cannot function alone. MGCP incorporates SDP to describe the type of session to initiate. Basic MGCP Components MGCP defines a number of components and concepts. An MGCP component is a physical piece of an MGCP network, whereas an MGCP concept is a logical piece of an MGCP network. Figure 6-34 illustrates the following three MGCP components: Endpoints Represent the point of interconnection between the packet network and the traditional telephony network. Gateways Handle the translation of audio between the SCN and a packet network. A Cisco voice gateway can act as an MGCP gateway. Call agent Exercises control over the operation of a gateway. Cisco Unified CallManager can act as an MGCP call agent.
Figure 6-34. MGCP Components MGCP Endpoints Endpoints represent the point of interconnection between the packet network and the traditional telephony network. Endpoints can be physical, representing an FXS port or a channel in a T1 or E1, or they can be logical, representing an attachment point to an announcement server. To manage an endpoint, the call agent must recognize the characteristics of an endpoint. To aid in this process, endpoints are categorized into several types. The intent is to configure a call agent to manage a type of endpoint rather than to manage each endpoint individually. RFC 2705 defines eight types of endpoints, as follows: Digital Service Level Zero (DS0) Represents a single channel (DS0) in the digital hierarchy. A digital channel endpoint supports more than one connection. Analog line Represents the client-side interface, such as FXS; or switch-side interface, such as FXO; to the traditional telephony network. An analog line endpoint supports more than one connection. Announcement server access point Represents access to an announcement server (for example, to play recorded messages). An announcement server endpoint might have only one connection. Multiple users of the announcement server are modeled to use different logical endpoints. Interactive voice response (IVR) access point Represents access to an IVR service. An IVR endpoint has one connection. Multiple users of the IVR system use different logical endpoints. Conference bridge access point Represents access to a specific conference. Each conference is modeled as a distinct endpoint. A conference bridge endpoint supports more than one connection. Packet relay Represents access that bridges two connections for interconnecting incompatible gateways or relaying them through a firewall environment. A packet relay endpoint has two connections. Wiretap access point Represents access for recording or playing back a connection. A wiretap access point endpoint has one connection. ATM trunk side interface Represents a single instance of an audio channel in the context of an ATM network. An ATM interface supports more than one connection.
When interacting with a gateway, the call agent directs its commands to the gateway for the express purpose of managing an endpoint or a group of endpoints. An endpoint identifier, as its name suggests, provides a name for an endpoint. Endpoint identifiers consist of two parts: a local name of the endpoint in the context of the gateway and the domain name of the gateway itself. The two parts are separated by an at sign (@). If the local part represents a hierarchy, the subparts of the hierarchy are separated by a slash. In Figure 6-35, the local ID might be representative of a particular gateway/circuit #, and the circuit # might in turn be representative of a circuit ID/channel #. In Figure 6-35, mgcp.gateway.cisco.com is the domain name, and t1toSJ/17 refers to channel 17 in the T1 to San Jose. Figure 6-35. MGCP Endpoint Identifier MGCP Gateways Gateways are clustering points for endpoints. These gateways handle the translation of audio between the SCN and the packet network. Although gateways are implemented in real systems, from a modeling point of view, gateways are logical components. In this context, gateways represent a clustering of a single type and profile of endpoints. Note A gateway interacts with one call agent only. Therefore, a gateway associates with one call agent at a time. RFC 2705 identifies the following seven types of gateways: Trunk gateway Signaling System 7 (SS7) ISDN User Part (ISUP) Supports digital circuit endpoints subject to ISDN signaling Trunk gateway multifrequency (MF) Typically supports digital or analog circuit endpoints that are connected to a service provider of an enterprise switch that is subject to MF signaling Network access server (NAS) Supports an interconnect to endpoints over which data (for example, modem) applications are provided Combined NAS/VoIP gateway Supports an interconnect to endpoints over which a combination of voice and data access is provided Access gateway Supports analog and digital endpoints connected to a PBX Residential gateway Supports endpoints connected to traditional analog interfaces Announcement servers Supports endpoints that represent access to announcement services
Multiple gateway types, and multiple instances of the same type, can be incorporated into a single physical gateway implementation. MGCP Call Agents A call agent, or Media Gateway Controller (MGC), represents the central controller in an MGCP environment, as depicted in Figure 6-36. Figure 6-36. MGCP Call Agent A call agent exercises control over the operation of a gateway and its associated endpoints by requesting that a gateway observe and report events. In response to the events, the call agent instructs the endpoint what signal, if any, the endpoint should send to the attached telephone equipment. This requires a call agent to recognize each endpoint type that it supports and the signaling characteristics of each physical and logical interface attached to a gateway. A call agent uses its directory of endpoints and the relationship that each endpoint has with the dial plan to determine call routing patterns. These call agents also have the responsibility of initiating all VoIP call legs. Basic MGCP Concepts The following are MGCP's basic concepts: Calls and connections Allow end-to-end calls to be established by connecting two or more endpoints Events and signals Allow a call agent to provide instructions for the gateway Packages and digit maps Allow a gateway to determine the call destination
MGCP Sessions End-to-end calls are established by connecting two or more endpoints, as illustrated in Figure 6-37. To establish a call, the call agent instructs the gateway associated with each endpoint to make a connection with a specific endpoint or an endpoint of a particular type. The gateway returns the session parameters of its connection to the call agent, which in turn sends these session parameters to the other gateway. With this method, each gateway acquires the necessary session parameters to establish RTP sessions between the endpoints. All connections associated with the same call share a common call ID and the same media stream. At the conclusion of a call, the call agent sends a delete connection request to each gateway. Figure 6-37. MGCP Calls and Connections To create a multipoint call, the call agent instructs an endpoint to create multiple connections. The endpoint bears the responsibility for mixing audio signals. MGCP Control Commands A call agent uses control commands or messages to direct its gateways and their operational behavior. Gateways use the following control commands in responding to requests from a call agent and notifying the call agent of events and abnormal behavior: EndpointConfiguration (EPCF) Identifies the coding characteristics of the endpoint interface on the line side of the gateway. The call agent issues the command. NotificationRequest (RQNT) Instructs the gateway to watch for events on an endpoint and specifies the action to take when the events occur. The call agent issues the command. Notify (NTFY) Informs the call agent of an event for which notification was requested. The gateway issues the command. CreateConnection (CRCX) Instructs the gateway to establish a connection with an endpoint. The call agent issues the command. ModifyConnection (MDCX) Instructs the gateway to update its connection parameters for a previously established connection. The call agent issues the command. DeleteConnection (DLCX) Informs the recipient to delete a connection. The call agent or the gateway can issue the command. The gateway or the call agent issues the command to advise that it no longer has the resources to sustain the call. AuditEndpoint (AUEP) Requests the status of an endpoint. The call agent issues the command. AuditConnection (AUCX) Requests the status of a connection. The call agent issues the command. RestartInProgress (RSIP) Notifies the call agent that the gateway and its endpoints are removed from service or are being placed back in service. The gateway issues the command.
MGCP Call Flows Figure 6-38 illustrates a dialog between a call agent and two gateways. Figure 6-38. MGCP Call Flows Although the gateways in this example are both residential gateways, the following principles of operation are the same for other gateway types: 1. | The call agent sends a notification request (RQNT) to each gateway. Because the gateways are residential gateways, the request instructs the gateways to wait for an off-hook transition (event). When the off-hook transition event occurs, the call agent instructs the gateways to supply dial tone (signal). The call agent asks the gateway to monitor for other events as well. By providing a digit map in the request, the call agent can have the gateway collect digits before it notifies the call agent. | | | 2. | The gateways respond to the request. At this point, the gateways and the call agent wait for a triggering event. | 3. | A user on Gateway A goes off hook. As instructed by the call agent in its earlier request, the gateway provides dial tone. Because the gateway is provided with a digit map, it begins to collect digits (as they are dialed) until either a match is made or no match is possible. For the remainder of this example, assume that the digits match a digit map entry. | 4. | Gateway A sends a notify (NTFY) to the call agent to advise the call agent that a requested event was observed. The notify message identifies the endpoint, the event, and, in this case, the dialed digits. | 5. | After confirming that a call is possible based on the dialed digits, the call agent instructs Gateway A to create a connection (CRCX) with its endpoint. | 6. | The gateway responds with a session description if it is able to accommodate the connection. The session description identifies at least the IP address and UDP port for use in a subsequent RTP session. The gateway does not have a session description for the remote side of the call, and the connection enters a wait state. | 7. | The call agent prepares and sends a connection request to Gateway B. In the request, the call agent provides the session description obtained from Gateway A. The connection request is targeted to a single endpoint if only one endpoint is capable of handling the call, or to any one of a set of endpoints. The call agent also embeds a notification request that instructs the gateway about the signals and events that it should now consider relevant. In this example, where the gateway is residential, the signal requests ringing, and the event is an off-hook transition. | 8. | Gateway B responds to the request with its session description. Notice that Gateway B has both session descriptions and recognizes how to establish its RTP sessions. | 9. | The call agent relays the session description 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. Now Gateway A and Gateway B have the required session descriptions to establish the RTP sessions over which the audio travels. | 10. | At the conclusion of the call, one of the endpoints recognizes an on-hook transition. In the example, the user on Gateway A hangs up. Because the call agent requested a notification of such an event, Gateway A notifies the call agent. | 11. | The call agent sends a delete connection (DLCX) request to each gateway. | 12. | The gateways delete the connections and respond. |
Robust MGCP Design In the MGCP environment, the call agent controls all call setup processing on the IP and the telephony sides of a gateway. Because a gateway is associated with only one call agent at a time, if that call agent fails or is inaccessible for any reason, the gateway and its endpoints are left uncontrolled and, for all practical purposes, useless. Cisco developed two methods to handle lost communication between a call agent and its gateways: MGCP switchover and switchback and MGCP gateway fallback. The following sections describe how these features operate. MGCP Switchover and Switchback MGCP switchover permits the use of redundant MGCP call agents. This feature requires two or more Cisco Unified CallManager servers to operate as MGCP call agents. One Cisco Unified CallManager server becomes the primary server and functions as the MGCP call agent. The other Cisco Unified CallManager servers remain available as backup servers. The MGCP gateway monitors MGCP messages sent by the Cisco Unified CallManager server. If traffic is undetected, the gateway transmits keepalive packets to which the Cisco Unified CallManager server responds. If the gateway does not detect packets from the Cisco Unified CallManager for a specified period, the gateway tries to establish a new connection with a backup Cisco Unified CallManager server. You can configure a Cisco voice gateway to reestablish connection with the primary Cisco Unified CallManager server when it becomes available again. This is the switchback function. MGCP Gateway Fallback MGCP gateway fallback is a feature that improves the reliability of MGCP branch networks. A WAN link connects the MGCP gateway at the remote site to the Cisco Unified CallManager at the central sites (that is, the MGCP call agent). If the WAN link fails, the fallback feature keeps the gateway working as an H.323 gateway, as depicted in Figure 6-39. Figure 6-39. Survivable Remote Site Telephony
MGCP gateway fallback works in conjunction with the Survivable Remote Site Telephony (SRST) feature. SRST allows Cisco gateways and routers to manage connections temporarily for Cisco IP phones when a connection to a Cisco Unified CallManager is unavailable. Cisco's Implementation of MGCP Cisco provides support for MGCP gateways and the call agent in the following ways: Configuring MGCP Example 6-12 highlights the commands required to configure an MGCP residential gateway. Example 6-12. Configuring an MGCP Residential Gateway| Router(config)#ccm-manager mgcp Router(config)#mgcp Router(config)#mgcp call-agent 172.20.5.20 Router(config)#voice-port 1/0/0 Router(config-voiceport)#voice-port 1/0/1 Router(config-voiceport)#exit Router(config)#dial-peer voice 1 pots Router(config-dial-peer)#application MGCPAPP Router(config-dial-peer)#port 1/0/0 Router(config-dial-peer)#exit Router(config)#dial-peer voice 2 pots Router(config-dial-peer)#application MGCPAPP Router(config-dial-peer)#port 1/0/1 |
MGCP is invoked with the mgcp command. If the call agent expects the gateway to use its default port (UDP 2427), the mgcp command is used without any parameters. If the call agent requires a different port, then the port must be configured as a parameter in the mgcp command. For example, mgcp 5036 tells the gateway to use port 5036 instead of the default port. At least one mgcp call-agent command is required below the mgcp command. This command indicates the location of the call agent. The command identifies the call agent by an IP address or a host name. Using a host name adds a measure of fault tolerance in a network that has multiple call agents. When the gateway asks the DNS for the IP address of the call agent, the DNS can provide more than one address, in which case the gateway can use either one. If multiple instances of the mgcp call-agent command are configured, the gateway uses the first call agent to respond. When the parameters of the MGCP gateway are configured, the active voice ports (endpoints) are associated with the MGCP. Dial peer 1 illustrates an application MGCPAPP subcommand. This command binds the voice port (1/0/0 in this case) to MGCP. Also, notice that the dial peer does not have a destination pattern. A destination pattern is not used because the relationship between the dial number and the port is maintained by the call agent. Note The ccm-manager-mgcp command is required only if the call agent is a Cisco Unified CallManager. Also, in some recent versions of the Cisco IOS, the application MGCPAPP subcommand has been replaced with the service mgcp command. Example 6-13 illustrates the configuration of a trunk gateway. Example 6-13. Configuring an MGCP Trunk Gateway| Router(config)#ccm-manager mgcp Router(config)#mgcp 4000 Router(config)#mgcp call-agent 209.165.202.129 4000 Router(config)#controller t1 1/0 Router(config-controller)#framing esf Router(config-controller)#clock source internal Router(config-controller)#ds0-group 1 timeslots 1-24 type none service mgcp Router(config-controller)#exit Router(config)#controller t1 1/1 Router(config-controller)#framing esf Router(config-controller)#clock source internal Router(config-controller)#ds0-group 1 timeslots 1-24 type none service mgcp Router(config-controller)#exit |
Configuring trunk gateways requires the address or the name of the call agent, which is a requirement common to a residential gateway (RGW). The trunk package is the default for a trunk gateway and does not need to be configured. Again, other parameters are optional. Example 6-13 illustrates commands for configuring a trunk gateway. Instead of using the application mgcpapp command in a dial peer, a trunk endpoint identifies its association with MGCP using the service mgcp parameter in the ds0-group controller subcommand. As always in MGCP, the call agent maintains the relationship between the endpoint (in this case a digital trunk) and its address. Cisco Unified CallManager MGCP Configuration Cisco Unified CallManager acts as a call agent in an MGCP environment. Therefore, a complete MGCP setup requires Unified CallManager configuration in addition to IOS configuration on the voice-enabled gateway. Note The following steps apply to Cisco Unified CallManager version 4.1. Menu options might vary in other releases. Also, in releases prior to 4.1, the URL used to access the CCM administrative interface uses http, as opposed to https. The following set of steps describes how to configure Cisco Unified CallManager as an MGCP call agent for an IOS MGCP gateway: | | Step 1. | Access Cisco Unified CallManager's administrative interface, shown in Figure 6-40, by pointing a browser to the following URL: Figure 6-40. Cisco Unified CallManager Administrative Interface
https://CCM_IP_Address_or_Name/ccmadmin | | | Step 2. | After logging in with the appropriate credentials, select the Device menu and then select the Gateway option. | | | Step 3. | Click the Add a New Gateway link, shown in Figure 6-41. Figure 6-41. Add a New Gateway
| | | Step 4. | From the Gateway Type drop-down menu, select the IOS hardware platform you have configured as an MGCP gateway (for example, 26XX), as shown in Figure 6-42, and click the Next button. Figure 6-42. Selecting a Gateway
| Step 5. | In the Domain Name field, enter the DNS name of the IOS gateway if the gateway's domain name is resolvable. Otherwise, use the host name as defined on the MGCP gateway (for example, R4). | Step 6. | Select an appropriate Unified CallManager group (for example, Default) from the Unified CallManager Group drop-down menu. | | | Step 7. | Identify the module(s) (for example, NM-1V) installed in the gateway's slots, as illustrated in Figure 6-43, and click the Insert button. Figure 6-43. Identifying Network Modules
| | | Step 8. | Once the screen refreshes, you are prompted for the subunits (for example, specific voice interface cards) installed in the module(s) you specified in Step 7. Select the appropriate subunit(s), as shown in Figure 6-44, and click the Update button. Figure 6-44. Identifying Voice Interface Cards
| | | Step 9. | Once the screen refreshes, you see links for the endpoint identifiers for the voice ports in the voice interface card(s) you specified in Step 8, as depicted in Figure 6-45. To configure an endpoint, click the appropriate endpoint identifier (for example, 1/0/0). Figure 6-45. Selecting an Endpoint Identifier
| | | Step 10. | After the screen refreshes, select an appropriate device pool (for example, Default) from the Device Pool drop-down menu, as illustrated in Figure 6-46, and click the Insert button. Figure 6-46. Specifying a Device Pool
| | | Step 11. | After the screen refreshes, you have the option to add a directory number (that is, a DN) to the endpoint. Click the Add DN link in the left pane of the screen, as shown in Figure 6-47. Figure 6-47. Adding a Directory Number
| | | Step 12. | After the screen refreshes, enter the endpoint's directory number (for example, 3333) in the Directory Number field, as illustrated in Figure 6-48, and click the Add button. Figure 6-48. Specifying a Directory Number
| | | Step 13. | After the gateway has registered with the call agent (that is, Cisco Unified CallManager), the Gateway Configuration screen confirms the registration and shows the IP address of the MGCP gateway, as shown in Figure 6-49. Figure 6-49. Verifying Gateway Registration
|
Monitoring and Troubleshooting MGCP Several show and debug commands provide support for monitoring and troubleshooting MGCP. These commands are valuable for examining the current status of the MGCP components and for troubleshooting. You should be familiar with the information provided from each command and how this information can help you. The following show commands are useful for monitoring and troubleshooting MGCP: show call active voice [brief] Displays the status, statistics, and parameters for all active voice calls. When the call is disconnected, this information is transferred to the history records. show call history voice [last n | record | brief] Displays call records from the history buffer. show mgcp Displays basic configuration information about the gateway. show mgcp connection Displays details of the current connections. show mgcp endpoint Displays a list of the voice ports that are configured for MGCP. show mgcp statistics Displays a count of the successful and unsuccessful control commands (shown in Example 6-14). You should investigate a high unsuccessful count. Example 6-14. The show mgcp statistics Output| Router# show mgcp statistics UDP pkts rx 8, tx 9 Unrecognized rx pkts 0, MGCP message parsing errors 0 Duplicate MGCP ack tx 0, Invalid versions count 0 CreateConn rx 4, successful 0, failed 0 DeleteConn rx 2, successful 2, failed 0 ModifyConn rx 4, successful 4, failed 0 DeleteConn tx 0, successful 0, failed 0 NotifyRequest rx 0, successful 4, failed 0 AuditConnection rx 0, successful 0, failed 0 AuditEndpoint rx 0, successful 0, failed 0 RestartInProgress tx 1, successful 1, failed 0 Notify tx 0, successful 0, failed 0 ACK tx 8, NACK tx 0 ACK rx 0, NACK rx 0 IP address based Call Agents statistics: IP address 10.24.167.3, Total msg rx 8, successful 8, failed 0 |
In addition to show commands, the Cisco IOS also provides the following debug commands, which are useful for monitoring and troubleshooting MGCP: debug voip ccapi inout Shows every interaction with the call control API on the telephone interface and the VoIP side. Watching the output allows users to follow the progress of a call from the inbound interface or VoIP peer to the outbound side of the call. This debug is very active. You must use it sparingly in a live network. debug mgcp [ all | errors | events | packets | parser ] Reports all MGCP command activity. You must use this debug to trace the MGCP request and responses.
|