Cisco Gateway Concepts
A gateway is a device that translates one type of signal into another type of signal. One type of gateway is the voice gateway. A voice gateway is a router or switch that converts IP voice packets to analog or digital signals that are understood by trunks or stations. Gateways are used in several situations, for example, connecting to a PSTN or PBX, or connecting individual devices such as an analog phone or fax.
Note
This chapter provides an overview of the voice gateways that you can use with the Cisco CallManager system and describes their basic configuration. For more information on configuring voice gateways, refer to Authorized Self-Study Guide: Cisco Voice over IP (CVOICE), Second Edition (ISBN: 1-58705-262-8) or Cisco Voice Gateways and Gatekeepers (ISBN: 1-58705-258-X) from Cisco Press.
Analog and Digital Gateways
There are two types of Cisco access gateways: analog and digital. At a high level, the difference between these two types of gateways is their capacity. Analog gateways (and analog connections) receive one line per port. This port could be a connection to the PSTN, an end device such as a fax machine, or a link to a PBX. Regardless of the connection, analog ports only permit one voice path per line. There are two categories of analog gateways:
- Access analog station gateways Access analog station gateways connect Cisco CallManager to plain old telephone service (POTS) analog telephones, interactive voice response (IVR) systems, fax machines, and voice-mail systems. Station gateways provide Foreign eXchange Station (FXS) ports for connecting to analog devices such as telephones and faxes.
- Access analog trunk gateways Access analog trunk gateways connect Cisco CallManager to PSTN central office (CO) or PBX trunks. Trunk gateways provide Foreign eXchange Office (FXO) ports for PSTN or PBX access and E&M (known by various names, primarily receive and transmit, or ear and mouth, or earth and magneto) ports for analog trunk connection to a legacy PBX. Analog Direct Inward Dial (DID) is also available for PSTN connectivity.
Depending on the cards you have installed into a gateway, it could fill both station (FXS) and trunk (FXO) roles.
On the flip side, digital gateways typically allow multiple calls per port. These gateways connect the Cisco CallManager to the PSTN or to a PBX via digital trunks, such as PRI common channel signaling (CCS), BRI, T1 channel-associated signaling (CAS), or E1. Digital T1 PRI trunks might also connect to certain legacy voice-mail systems. Regardless of the connection type, you will typically use a digital gateway to provide a high-capacity connection to an alternate network type.
Core Gateway Requirements
To support modern VoIP networks, your IP telephony gateways must meet these core feature requirements:
- Dual tone multifrequency (DTMF) relay capabilities DTMF signaling tones, which contain the digits a user has dialed, must be processed. Gateways must separate DTMF digits from the voice stream and then send the signaling in voice over IP (VoIP) signaling protocols, such as H.323, Cisco IOS software Media Gateway Control Protocol (MGCP), SIP, and so on.
- Supplementary services support These services are typically basic telephony functions, such as hold, transfer, and conferencing.
- Cisco CallManager redundancy support Cisco CallManager clusters provide for Cisco CallManager redundancy. The gateways must support the ability to re-home to a secondary Cisco CallManager in the event of a primary Cisco CallManager failure, which differs from call survivability in the event of a Cisco CallManager or network failure.
- Call survivability in Cisco CallManager The voice gateway preserves the Real-time Transport Protocol (RTP) bearer stream (the voice conversation) between two IP endpoints when the Cisco CallManager that the endpoint is registered to is no longer reachable.
Any IP telephony gateway that you select for an enterprise deployment should support these core requirements. In addition, every IP telephony implementation has its own site-specific feature requirements, such as analog or digital access, DID, and capacity requirements.
Gateway Communication Overview
For Cisco CallManager to reach other networks (including the PSTN), it must be able to communicate with the gateways connected to these networks. Cisco CallManager 4.x supports these three types of gateway communication protocols:
- H.323 H.323 uses a peer-to-peer model. You perform most of the configuration through Cisco IOS software on the voice gateway device. With the peer-to-peer model, Cisco CallManager does not have control over the gateway, which limits the Cisco CallManager feature support on H.323 gateways. For example, H.323 gateways do not support call survivability, and only devices that support H.323 version 2 (H.323v2) can take advantage of Cisco CallManager supplementary services, such as hold, transfer, and conference features. However, H.323 gateways support additional Cisco IOS features outside of Cisco CallManager that the other gateways do not, such as call admission control, fractional PRI support, FXO caller-id support, NFAS signaling, and Cisco Survivable Remote Site Telephony (SRST).
Examples of Cisco gateway devices that support H.323 include the Cisco VG224 Analog Phone Gateway (FXS only), Cisco 2600, Cisco 2800, Cisco 3700, and Cisco 3800 devices.
- MGCP MGCP uses a client/server model, with voice-routing intelligence that resides in a call agent (the Cisco CallManager). Because of its centralized architecture, MGCP simplifies the configuration of voice gateways (the gateway requires no advanced dial-peer configuration) and supports multiple (redundant) call agents in a network. MGCP gateways provide call survivability (the gateway maintains calls during failover and fallback). If the MGCP gateway loses contact with its Cisco CallManager, it falls back to using H.323 control to support basic call handling of FXS, FXO, T1 CAS, and T1 and E1 PRI interfaces. In addition, MGCP controlled gateways can support the Q Signaling (QSIG) protocol, which is used to communicate with many PBX systems.
Examples of Cisco gateway devices that support MGCP are the Cisco VG224 (FXS only), Cisco 2600, Cisco 2800, Cisco 3700, and Cisco 3800 devices. Examples of non-IOS devices that support MGCP are the Cisco Catalyst 6000 WS-X6608-T1 and -E1.
- SCCP Skinny Client Control Protocol (SCCP, or Skinny), is a client/server protocol that uses Cisco proprietary messages to communicate between IP devices and Cisco CallManager. The Cisco IP Phone is an example of a device that registers and communicates with Cisco CallManager as an SCCP client. During registration, a Cisco IP Phone receives its line and all other configurations from Cisco CallManager. After it registers, it is notified of new incoming calls and can make outgoing calls. SCCP is used for VoIP call signaling and enhanced features such as message waiting indication (MWI).
Examples of Cisco devices that support SCCP are the Cisco VG224 Analog Phone Gateway (FXS only) and the Cisco VG248 Analog Phone Gateway. The Cisco VG224 gateway is 24-port gateway for analog phones, fax machines, modems, and speakerphones using Cisco CallManager or Cisco CallManager Express. The Cisco VG248 device is a 48-port gateway.
Note
SIP can also be used as a gateway control protocol. Most Cisco IOS images that support H.323 and MGCP also support SIP. Cisco CallManager 4.x supports SIP trunks to connect CallManager to distributed SIP networks.
Most gateway devices support multiple gateway protocols. Selecting the protocol to use depends on site-specific requirements and your installed base of equipment. You might prefer MGCP to H.323 because of the simpler configuration of MGCP or its support for call survivability during a Cisco CallManager switchover from a primary to a secondary Cisco CallManager. In addition, you might prefer H.323 to MGCP because of the interface robustness of H.323 or the ability to use it with call admission control or SRST. The Cisco-recommended best practices direct corporations to use MGCP unless they have a specific reason to choose another protocol.
Configuring Access Gateways
|