Implementing MGCP Gateways
Basic implementation of an MGCP gateway involves enabling MGCP on the gateway, telling the gateway how to find the CallManagers, and then adding the gateway and its endpoints to the CallManager configuration. You have a choice of doing all of configuration manually or downloading a good part of it from CallManager. The following sections describe some common configuration tasks.
Basic MGCP Gateway Configuration
Before you enable MGCP, configure the router with a hostname, IP addressing, and routing information. Then the basic tasks to configure MGCP on the router are enabling MGCP, telling it how to reach its call agent, and telling it that the call agent is a Cisco CallManager. The commands to do this at global configuration mode are as follows:
VoiceGW(config)#mgcp VoiceGW(config)#mgcp call-agent [ip-address|hostname] [port] service-type mgcp [version 0.1 | 1.0 | rfc3435-1.0] VoiceGW(config)#ccm-manager mgcp
If you would like the gateway to download much of its MGCP configuration from CallManager, you must code that and give it the IP address or DNS name for the TFTP server (usually CallManager). This downloads XML files with configuration such as MGCP packages, RTP settings, and fax settings. The commands to enable this are as follows:
VoiceGW(config)#ccm-manager config server {ip-address | dns-name} VoiceGW(config)#ccm-manager config
This file is downloaded when the gateway first communicates with CallManager, before it sends the RSIP message. The file is refreshed if changes are made to CallManager that require the gateway to be reset. Be sure to save any manual configuration to NVRAM, or it might be overwritten if the router downloads a new XML file. If you manually configure both MGCP and H.323 dial peers, be sure to configure the MGCP ones first if you are using this auto-config feature.
If the download is successful, you see a message on the gateway similar to what follows:
VoiceGW# Loading VoiceGW.cnf.xml from 10.6.2.10 (via FastEthernet0/0): ! [OK - 4445 bytes]
Next, you need to bind MGCP to the voice ports. You do this by configuring a dial peer for each voice port and binding MGCP to it using the application MGCPAPP command. This command is case sensitive in some IOS releases. To be safe, code MGCPAPP (all capital letters) unless you know that your release is not case sensitive.
VoiceGW(config)#dial-peer voice 100 pots VoiceGW(config-dial-peer)#application MGCPAPP VoiceGW(config-dial-peer)#port 1/0/0
When you make a change to the MGCP configuration, such as adding or changing endpoints, it is a good idea to reinitialize MGCP by issuing no mgcp and then mgcp global configuration commands.
Configuring MGCP Fallback
To use MGCP fallback, you must tell the router to use its default call-routing application, H.323, when it loses contact with the CallManager. The command for this varies depending on IOS versions. For IOS releases 12.3(13)T or earlier, use the global command call application alternate default. For IOS releases 12.3(14)T or later, the command is a bit more complicated:
VoiceGW(config)#application VoiceGW(config-app)#global VoiceGW(config-app-global)#service alternate Default
When using MGCP fallback, you must also configure at least one dial peer with a destination pattern so that it can route outbound calls when CallManager is not available. That dial pattern is typically a wildcard that matches all outbound calls, such as "9T." Use the incoming called-number. wildcard if you want to enable the gateway to answer incoming calls on that port.
VoiceGW(config)#dial-peer voice 200 pots VoiceGW(config-dial-peer)#destination-pattern 9T VoiceGW(config-dial-peer)#incoming called-number .
Assigning an MGCP Source IP Address
By default, MGCP sources its messages from the IP address of Loopback 0 if it is present. If not, they are sourced from the outgoing interface. You can designate a specific interface to be used as the source IP address for either MGCP signaling, RTP media, or both. First configure the loopback interface, and then use the global configuration command mgcp bind {control | media} source-interface interface-number. After configuring this, reinitialize MGCP.
Configuring MGCP PRI and BRI Backhaul
MGCP passes the ISDN Q.931 call setup and teardown information to its CallManager. You configure this under the BRI or PRI interface, with the command isdn bind-l3 ccm-manager. When you are setting up the PRI-group timeslots on the controller for the PRI interface, add service mgcp to the end of the pri-group timeslots command. In addition, you must add that interface to CallManager as an MGCP endpoint and link it to a route pattern. You might need to include the application mgcpapp command under the dial peer for that interface, depending on your IOS version. For Cisco IOS Software Release 12.3(7)T and later, do not include this command under dial peers for ISDN interfaces that will use backhaul.
Verify MGCP Backhaul with the command show ccm-manager backhaul. You should see the ports being backhauled, in addition to information about the connection. The show isdn status command should show Layer 3 bound to CCM Manager.
Enabling Multicast Music on Hold
You might want to enable music on hold so that an off-net caller can receive streaming music as a multicast, rather than as a unicast. The command to enable multicast music on hold is given under global configuration mode: ccm-manager music-on-hold. You also must configure the CallManager to support music on hold.
Configuring Cisco CallManager
You need to configure the CallManager to recognize and control the gateway and its endpoints. The screen shots that follow were taken from CallManager 4.1. If you have a different version, your menus might differ.
|
Step 1. |
To add a new gateway, select Device from the CallManager Administration menu, and then click on Gateway, as shown in Figure 2-4.
Figure 2-4. CallManager Administration Menu |
|
Step 2. |
At the next screen, shown in Figure 2-5, select the Add a New Gateway link.
Figure 2-5. Adding a New Gateway to CallManager |
|
Step 3. |
This link takes you to the screen in Figure 2-6, where you select the type of gateway you are adding. For an MGCP gateway, choose the device type, such as router model or VG type. In this example, a Cisco 2821 router was selected. After you select the gateway type, the only option available under Device Protocol is "MGCP." Notice that you cannot configure CallManager to recognize the same device as both an MGCP and an H.323 gateway.
Figure 2-6. Selecting the Type of Gateway |
|
Step 4. |
Selecting Next brings you to the Gateway Configuration screen, illustrated in Figure 2-7. In the domain name field, enter the hostname of the router. (MGCP gateways are identified by hostname, not IP address.) If the router is also configured with a domain name, append that to the hostname, such as VGateway.myco.com. This name is case sensitive. Enter a description if desired. You must choose a CallManager group to use, even if it is just the default one.
Figure 2-7. CallManager Gateway Configuration |
|
Step 5. |
On the same screen, begin configuring the endpoints. The available router slots are listed, as is a drop-down menu to select the type of voice module they contain, if any. ISR routers contain four WIC/VWIC slots that are not part of a separate module. These are listed in the drop-down menu as "NM-4VWIC-MBRD." Be sure to choose this option, as shown in the example, if you intend to use these slots.
You can choose the type of Switchback, if desired. When a CallManager becomes unreachable and the gateway fails over to a backup CallManager, that is called Switchover. If the primary CallManager returns to service, the gateway reregisters with it. That is called Switchback. Active calls are preserved by default during both events. The Switchback Timing determines how a gateway will switch back to its primary CallManager.
When you have finished this configuration, click Insert.
|
|
Step 6. |
You then specify the endpoints that CallManager will control, by selecting subunits within the modules and configuring each port. Figure 2-8 shows an example with one PRI, four FXO, and four FXS interfaces. CallManager will control all six endpoints in this one MGCP gateway. To configure a specific port, click on the link for it. The necessary configuration depends on the type of endpoint. Configure the directory number for FXS ports here, rather than on the router.
Figure 2-8. Configuring MGCP Endpoints |
|
Step 7. |
The next step is to reset the gateway, as shown in Figure 2-9. Note that resetting an MGCP gateway drops any calls that are using that gateway.
Figure 2-9. Resetting the Gateway |
|
Step 8. |
To verify that the gateway is registered, go back to the Find and List Gateways screen. Click on Find, and the gateway should be listed, as shown in Figure 2-10. Any registered endpoints are also listed.
Figure 2-10. Verifying Gateway Registration with CallManager |
In addition, you must configure the CallManager with the appropriate route patterns, route groups, and route lists. After you do that, add the endpoints on the MGCP gateway to a route group or route list so that you can route calls to it. For dialing out to the PSTN, add the appropriate endpoints to a route pattern.
Configuring CallManager Redundancy
Because MGCP needs to communicate with a call agent for the gateway to have full functionality, the protocol allows you to specify up to three CallManagers. You configure the primary one using the global mgcp call-agent ip-address|hostname command. You can identify additional CallManagers with a global ccm-manager redundant-host ip-address1|hostname1 [ip-address2|hostname2] command.
The gateway sends normal MGCP keepalives (an empty NTFY message) to the primary CallManager. It also establishes a TCP session with the first redundant CallManager, using port 2428, and exchanges keepalives. If the primary CallManager becomes unreachable, the gateway quickly fails over to the secondary. It then starts sending TCP keepalives to the next CallManager that is listed.
If the primary CallManager returns, the gateway switches back to using it. It does this when all the established calls have ended, by default. However, you can configure it with the call-manager redundancy switchback {graceful | immediate | never | schedule-time | uptime-delay} command.
Configuring DTMF Relay
DTMF tones are created when a digit is dialed on a telephone. By default, the gateway sends these tones within the voice RTP stream. When voice is sent uncompressed, these tones arrive in their original state. However, when voice is compressed, such as with the G.729 codec, the tones might be distorted or part of the signal lost. DTMF Relay addresses this by separating these tones from the rest of the voice and sending them in a different way. You have a choice of four types of DTMF Relay in an MGCP gatewayCisco proprietary, Named Service Event (NSE), Named Telephony Event (NTE), and out-of-band.
The Cisco proprietary method sends the tones in the same RTP stream as voice, but it codes them differently to enable the receiver to identify them as DTMF signals.
NSE is specified in RFC 2833. It also sends the tones within the RTP stream, in a special NTE packet. This is similar to Cisco implementation, but it is based on standards.
The MGCP implementation of NTE has two flavors: gateway controlled (NTE-GW) and call agent controlled (NTE-CA). In NTE-GW, the two gateways negotiate the use of DTMF relay in SDP messages. In NTE-CA, the call agent tells its gateways the type of DTMF relay they are using.
Out-of-band DTMF relay sends the tones as signals to the CallManager, out-of-band over the control channel. CallManager interprets the signals and passes them on.
The DTMF package is loaded by default on Cisco gateways. To enable a specific type of DTMF relay, use the global command mgcp dtmf-relay voip codec {all | low-bit-rate} mode {cisco | nse | nte-ca | nte-gw | out-of-band}. This can be verified with the show mgcp command. The following line shows out-of-band DTMF relay:
mgcp dtmf-relay voip codec all mode out-of-band
You must also configure the CallManager to support the type of DTMF relay you choose.