|
|
This chapter discusses issues concerning the selection of gateways for connecting an IP telephony network to the PSTN or legacy PBX and key systems. Choosing a gateway from some 20 candidates --- ranging from specialized, entry-level stand-alone voice gateways to the high-end, feature-rich integrated router and Catalyst gateways --- can be daunting.
Although your particular VoIP implementation dictates specific gateway requirements, these are common required features:
Any gateway selected for an enterprise network should be able to support these features. In addition, every implementation has its own site-specific feature requirements, which helps you eliminate options.
This chapter includes these sections to address the required common and site-specific features:
Using Cisco CallManager Release 3.0, three types of gateway protocols are supported:
Of these three types, only the Cisco IOS H.323 gateways can today provide full featured routing capabilities as well as VoIP gateway functions. Both the gateways based on the Skinny Gateway Protocol and the VG200 MGCP gateway act as stand-alone, application-specific gateways.
Table 4-1 shows which protocols are supported on each gateway. The following sections discuss how each of these protocols provides support for the three core gateway features.
| Gateway | Skinny Gateway Protocol | H.323 | MGCP |
|---|---|---|---|
VG200 | No | Phase 2 | Yes |
DT-24+ and DE-30+ | Yes | No | No |
Catalyst 4000 WS-X4604-GWY gateway module | Yes, for conferencing and MTP transcoding services | Yes, for PSTN interfaces | Future |
Catalyst 6000 WS-X6608-T1 and WS-X6608-E1 gateway modules | Yes | No | Future |
Cisco 1750 | No | Yes | No |
Cisco 3810 V3 | No | Yes | Future |
Cisco 2600 | No | Yes | Future |
Cisco 3600 | No | Yes | Future |
Cisco 7200 | No | Yes | No |
Cisco 7500 | No | Future | No |
Cisco AS5300 | No | Yes | No |
 |
Note The VG200 supports only Foreign Exchange Station (FXS) and Foreign Exchange Office (FXO) interfaces in MGCP mode. A wider interface selection will be offered when the VG200 supports H.323v2. While the Cisco AS5300 supports MGCP, it is currently incompatible with Cisco CallManager. Although the Cisco 3810, 2600, and 3600 products have MGCP for analog interfaces in Cisco IOS Release 12.1(3)T, they will not be supported by Cisco CallManager until a future release, when the MGCP administrative interface is expanded to incorporate larger numbers of analog interfaces. |
DTMF uses specific pairs of frequencies within the voice band for signaling. Over a 64 kbps pulse code modulation (PCM) voice channel, these signals can be carried without difficulty. However, when using a low bit-rate codec for voice compression, the potential exists for DTMF signal loss or distortion. Using an out-of-band signaling method for carrying DTMF tones across a voice over IP infrastructure provides an elegant solution for these codec-induced symptoms.
The Cisco Access Digital Trunk Gateway DT-24+, the Cisco Access Digital Trunk Gateway DE-30+, and the Catalyst 6000 gateway use the Skinny Gateway Protocol to carry DTMF signals out-of-band using the TCP port 2002. Out-of-band DTMF is the default gateway configuration mode.
The Cisco 1750, 2600, 3600, 7200, and AS5300 series products communicate with Cisco CallManager using H.323. Both Cisco CallManager Release 3.0 and Cisco IOS Release 12.0(7)T include the enhanced H.245 capability for exchanging DTMF signals out-of-band. The following example shows out-of-band DTMF configuration on an Cisco IOS gateway.
dial-peer voice 100 voip destination-pattern 555. session target ipv4:10.1.1.1 codec g729ar8 dtmf-relay h245-alphanumeric preference 0
|
Note Due to memory limitations on the TI542 DSP used on the previous Cisco 3810 version, only the Cisco 3810 V3 with the new voice compression module supports H.245 DTMF relay. |
The VG200 communicates with Cisco CallManager using MGCP. MGCP uses the concept of "packages." The VG200 loads the DTMF package upon start-up. Once the out-of-band DTMF capabilities are configured in the Cisco CallManager MGCP gateway user interface, the VG200 sends "symbols" over the User Datagram Protocol (UDP) control channel to represent any DTMF tones it receives. Cisco CallManager interprets these symbols and passes on the DTMF signals, out-of-band, to the signaling endpoint. Here is the global configuration command for DTMF relay on the VG200:
mgcp dtmf-relay codec all mode out-of-band
Additional configuration parameters must be entered in the Cisco CallManager MGCP gateway configuration interface.
Integral to the Cisco IP telephony solution is the provision for low-cost, distributed PC-based systems to replace expensive and proprietary legacy PBX systems. This distributed design lends itself to the robust, fault-tolerant architecture of clustered Cisco CallManagers. Even in its simplest form (a two-system cluster), a secondary Cisco CallManager should be able to pick up control of all gateways initially managed by the primary Cisco CallManager.
The Cisco Access Digital Trunk Gateway DT-24+, the Cisco Access Digital Trunk Gateway DE-30+, and the Catalyst 6000 digital gateway are provisioned with Cisco CallManager location information when they are booted. When these gateways initialize, a list of Cisco CallManagers is downloaded to the gateways. This list is prioritized into a primary Cisco CallManager and secondary Cisco CallManager. In the event that the primary Cisco CallManager becomes unreachable, the gateway registers with the secondary Cisco CallManager.
Using several enhancements to the dial-peer and voice class commands in Cisco IOS Release 12.1(2)T, Cisco IOS gateways can now support redundant Cisco CallManagers. A new command, h225 tcp timeout seconds, has been added. This command specifies the time it takes for the Cisco IOS gateway to establish an H.225 control connection for H.323 call setup. If the Cisco IOS gateway cannot establish an H.225 connection to the primary Cisco CallManager, it tries a second Cisco CallManager defined in another dial-peer statement. The Cisco IOS gateway shifts to the dial-peer statement with next highest preference setting.
The following example shows the configuration for H.323 gateway failover:
dial-peer voice 101 voip destination-pattern 1111 session target ipv4:10.1.1.101 preference 0 voice class h323 1 dial-peer voice 102 voip destination-pattern 1111 session target ipv4:10.1.1.102 preference 1 voice class h323 1 voice class h323 1 h225 tcp timeout 10
Adding MGCP to the VG200 and Cisco CallManager allows this stand-alone gateway to switch over to a secondary Cisco CallManager in the event communication is lost with the primary Cisco CallManager. Within the VG200 configuration file, the primary Cisco CallManager is identified using the call-agent hostname command, and a list of secondary Cisco CallManager systems is added using the ccm-manager redundant-host command. Keepalives with the actively associated Cisco CallManager are accomplished through the MGCP application-level keepalive mechanism, whereby the gateway sends an empty MGCP NTFY message to the Cisco CallManager and waits for an acknowledgement. Keepalive with the backup Cisco CallManager(s) is accomplished through the TCP keepalive mechanism (UDP will be used in a later version).
If the primary Cisco CallManager becomes available at a later time, the VG200 can revert to the original Cisco CallManager. This fallback can either occur immediately, after a configurable amount of time, or only when all connected sessions have been released. This behavior is enabled through the following VG200 global configuration commands:
ccm-manager redundant-host {hostname1 | ipaddress1} [hostname2 | ipaddress2]Supplementary services provide user functions such as hold, transfer, and conferencing. These are considered fundamental requirements of any voice installation. Any gateway evaluated for use in an Cisco AVVID network should provide native support for supplementary services without the use of a software media termination point (MTP).
The Cisco Access Digital Trunk Gateway DT-24+ and DE-30+ products as well as the Catalyst 6000 series gateways all provide full supplementary service support. These gateways utilize the gateway-to-Cisco CallManager signaling channel and Skinny Gateway Protocol to exchange call control parameters. For more information, see the "Additional Information" section.
Only H.323v1 was supported prior to Cisco CallManager Release 3.0. The inability to modify the destination of an Real-Time Transport Protocol (RTP) stream after H.323v1 call setup prohibited supplementary services such as hold, forward, and transfer. Because H.323v1 provides no capability to move an RTP stream from one destination to another after original call setup, the software MTP tool was used to provide supplementary service support on the Cisco IOS gateways.
MTP, which runs as a software process on either the Cisco CallManager or on a separate Windows NT 4.0 server, terminates the RTP stream from the Cisco IOS gateway and the RTP stream from an IP phone. This workaround enables an IP phone to support supplementary services when using a Cisco IOS VoIP gateway because the RTP stream from the MTP to the Cisco IOS gateway is never modified until call completion. All RTP stream changes are made on the Skinny Station side of the MTP connection. An additional major caveat for using the software MTP is that it supports only G.711 voice streams; no compressed voice calls are supported. This greatly limits WAN systems.
The use of H.323v2 in Cisco IOS Release 12.0(7)T and above (specifically the OpenLogicalChannel, CloseLogicalChannel, and emptyCapabiliySet features) by Cisco IOS gateways and Cisco CallManager Release 3.0 eliminates the requirement for MTP to provide supplementary services. Because MTP is no longer needed to terminate the G.711 RTP streams from both the IP phones and the Cisco IOS gateway, compressed voice calls (G.723.1 and G.729a) are now supported between Cisco IOS gateways and Cisco CallManager endpoints.
Once an H.323v2 call is set up between an Cisco IOS gateway and an IP phone, using the Cisco CallManager as an H.323 proxy, the IP phone can request to modify the bearer connection. Because the RTP stream is directly connected to the IP phone from the Cisco IOS gateway, a supported voice codec can be negotiated.
The following steps illustrate the process that occurs if IP phone 1 wants to transfer the call from the Cisco IOS gateway to IP phone 2:
1. IP phone 1 issues a transfer request to Cisco CallManager using the Skinny Station Protocol.
2. Cisco CallManager translates this request into an H.323v2 CloseLogicalChannel request to the Cisco IOS gateway for the appropriate SessionID.
3. The Cisco IOS gateway closes the RTP channel to IP phone 1.
4. Cisco CallManager issues a request to IP phone 2, using the Skinny Station Protocol, to set up an RTP connection to the Cisco IOS gateway. At the same time, Cisco CallManager issues an OpenLogicalChannel request to the Cisco IOS gateway with the new destination parameters, but using the same SessionID.
5. After the Cisco IOS gateway acknowledges the request, an RTP voice bearer channel is set between IP phone 2 and the Cisco IOS gateway.
The VG200 provides full support for the hold, transfer, and conference features using MGCP. Because MGCP is fundamentally a master-slave protocol, with Cisco CallManager controlling all session intelligence, it can easily manipulate VG200 voice connections. If a Cisco AVVID end point needs to modify the session (for example, transfer the call to another Cisco AVVID end point), the end point would notify Cisco CallManager through the Skinny Station Protocol. Cisco CallManager would then inform the VG200, using the MGCP UDP control connection, to terminate the current RTP stream associated with the SessionID and start a new media session with the new end point information.
Besides the requirements for DMTF relay and supplementary services, each Cisco IP telephony implementation has its own gateway requirements. The following is a sample list of questions regarding required features that should be asked prior to selecting a Cisco IP telephony gateway.
Although this feature list could be much longer, it provides a starting point to help narrow down the possible choices. Once the features have been defined, a gateway selection can be made for configurations ranging from single-site enterprise systems of various sizes and complexities to multi-site enterprise systems. These categories are defined in more depth in the following sections.
To help narrow the focus, the site-specific feature list can be compared to Table 4-2 and Table 4-3, which correlate analog and digital gateways with supported telephony features.
| Gateway | FXS | FXO | E & M1 | Analog DID/CLID |
|---|---|---|---|---|
VG200 | Yes | Yes | In H.323v2 mode | Future |
Cisco Access DT-24+ and Cisco Access DE-30+ | No | No | No | N/A |
Cisco 1750 | Yes | Yes | Yes | Future |
Cisco 3810 V3 | Yes | Yes | Yes | 12.1(4)T/12.1(2)Xx |
Cisco 2600 | Yes | Yes | Yes | 12.1(4)T/12.1(2)Xx |
Cisco 3600 | Yes | Yes | Yes | 12.1(4)T/12.1(2)Xx |
Cisco 7200 | No | No | No | N/A |
Cisco 7500 | No | No | No | N/A |
Cisco AS5300 | No | No | No | N/A |
Catalyst 4000 WS-X4604-GWY gateway module | Yes | Yes | Yes | 12.1(4)T/12.1(2)Xx |
Catalyst 6000 WS-X6608-T1 and WS-X6608-E1 | Yes | No | No | No/Yes |
|
Note For a given feature, for example FXS or FXO, a specific minimum Cisco IOS version is required. |
| Gateway | T1 CAS1 | E1/R2 | E1 CAS | User Side PRI2 | Network Side PRI | User Side BRI3 | Network Side BRI | Digital DID4/CLID5 |
|---|---|---|---|---|---|---|---|---|
VG200 | In H.323v2 mode | No | In H.323v2 mode | No | No | No | No | N/A |
Cisco Access DT-24+ and Cisco Access DE-30+ | No | No | No | Yes | Yes | No | No | Yes |
Cisco 1750 | No | No | No | No | No | Future | Future | N/A |
Cisco 3810 V3 | Yes | No | Yes | No | No | Yes | No | Yes |
Cisco 2600 | Yes | 12.1(2)Xx | 12.1(2)Xx | 12.1(2)Xx | 12.1(2)Xx6 | Yes | Future | Yes/Yes7 |
Cisco 3600 | Yes | 12.1(2)Xx | 12.1(2)Xx | 12.1(2)Xx | 12.1(2)Xx6 | Yes | Future | Yes/Yes7 |
Cisco 7200 | Yes | Future | Future | 12.1(3)T | 12.1(3)T6 | No | No | Yes/Yes7 |
Cisco 7500 | Future | Future | Future | Future | Future | No | No | Yes/Yes7 |
Cisco AS5300 | Yes | Yes | Yes | Yes | 12.0.7T6 | No | No | Yes/Yes |
Catalyst 4000 WS-X4604-GWY gateway module | Yes | Yes | Yes | Yes | Yes | Future | Future | Yes/Yes7 |
Catalyst 6000 WS-X6608-T1 and WS-X6608-E1 gateway modules | No | No | No | Yes | Yes | No | No | Yes/Yes |
Table 4-4 lists the gateways of each type along with the data interfaces, PSTN interfaces, and voice compression supported.
| Gateway Type | Gateway | Data Interfaces | Analog PSTN Interfaces | Digital PSTN Interfaces in DS0s | Voice Compression |
|---|---|---|---|---|---|
| Skinny Gateway Protocol | Cisco Access DT-24+ | 10BaseT | 0 | 24 | G.711, G.723.1 |
Cisco Access DE-30+ | 10BaseT | 0 | 30 | G.711, G.723.1 | |
Catalyst 6000 WS-X6624-FXS | 10/100/1000 Ethernet | 24 | 0 | G.711, G.729a | |
Catalyst 6000 WS-X6608-T1 | 10/100/1000 Ethernet, POS/FlexWAN | 0 | 192 | G.711, G.729a | |
Catalyst 6000 WS-X6608-E1 | 10/100/1000 Ethernet, POS/FlexWAN | 0 | 240 | G.711, G.729a | |
| MGCP | VG200 | 100BaseT | 4 | 0 | G.711, G.729a, G.723.1 |
| H.323 | Cisco 1750 | 10BaseT, T1/E1 serial | 4 | 0 | G.711, G.729 |
VG200 | 100BaseT | 4 | 48/60 | G.711, G.729a, G.723.1 | |
Cisco 2600 | 10/100BaseT, Token Ring, T1/E1 serial | 4 | 48/60 | G.711, G.729a, G.723.1 | |
Cisco 3620 | 10/100BaseT, Token Ring, T1/E1 serial, T1-OC3 ATM | 4 | 48/60 | G.711, G.729a, G.723.1 | |
Cisco 3640 | 10/100BaseT, Token Ring, T1/E1 serial, T1-OC3 ATM | 12 | 136/180 | G.711, G.729a, G.723.1 | |
Catalyst 4000 | 10/100/1000 Ethernet | 6 at FCS | 48/60 | G.711, G.729a, G.723.1 | |
Cisco 3660 | 10/100BaseT, Token Ring, T1/E1 serial, T1-OC3 ATM, HSSI | 24 | 288/360 | G.711, G.729a, G.723.1 | |
Cisco 7200 | 10/100BaseT, Token Ring, T1/E1 serial, T1-OC12 ATM | 0 | 288/360 | G.711, G.729a, G.723.1 |
Posted: Thu Jul 27 10:30:27 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.