At the heart of any gateway is the capability of converting a stream of voice-carrying signals (either analog or digital) from a telephone line or trunk into a stream of RTP packets (transmitted over a shared channel, which in general should be expected to have a much lower bandwidth). Part of such a conversion involves compression, which compensates for bandwidth reduction. Conversely, every gateway has the capability of converting a stream of RTP packets (and possibly decompressing the data) into a stream of signals acceptable by existing traditional telephony systems. The conversion is performed by coder/decoder modules, or codecs, which can be purchased separately and subsequently integrated into gateways. The role of codecs is central to the basic function of any gateway, because their performance affects crispness and clarity of sound. Other important gateway capabilities that affect the quality of sound are echo cancellation and compression. Overall, it is a legitimate requirement in today’s market that the audio capabilities of gateways enable full-duplex conversations. Another important requirement is that gateways used by the switches (for example, PBXs) for toll saving monitor the quality of IP-transmitted sound (by employing RTCP, for example) and generate an appropriate signal to the switches when sound quality falls below a customer-set threshold. Upon reception of a poor-quality signal, the switches can automatically select a PSTN trunk to continue the call.
We have not addressed codec standards in detail because much literature on the subject is available (see Minoli and Minoli, 1998b) and such a treatment is beyond the scope. We will provide recommendations on what to expect (and request) of vendors. The role of codec standards is hard to overestimate because, in principle, gateways cannot interoperate if they do not support the same sets of codecs. Thus, compliance with codec standards is an essential factor when evaluating gateways purchased from different manufacturers.
As we have said before, major codec standards are produced by ITU-T in its G Series of Recommendations. First of all, the G.711 standard (for ISDN voice channels; yields 64 kbps of digital audio) must be supported by any gateway. In connection with regional standards, all gateways that interoperate with the North American telephone system must support the A-law scheme; all gateways that interoperate with the European telephone system must support the A-law scheme. In addition, advanced gateways may support low-bandwidth connections with G.723.1 or G.729A codecs. In that case, the support of transporting DTMF tones using a non-RTP path is important because the low-bandwidth codecs are not designed to reliably pass DTMF tones as part of a compressed voice stream. This feature allows the regeneration of the DTMF tones at the receiving gateway and improves overall call performance, in particular for applications (for example, voice mail) that require correct detection of DTMF tones.
Voice compression makes it difficult, if not impossible, to transcode (that is, translate from one encoding scheme to another). Transcoding is well understood for the compression schemes defined in the G.729 and G.729A standards. Thus, if compression is supported, it should adhere to these standards. Some gateway products attempt to realize much-needed bandwidth savings by monitoring sound activity. When silence is detected by the transmitting gateway, it stops the sound transmission and informs the receiving gateway about the background noise. Then the receiving gateway emits comfort noise to create the perception of uninterrupted transmission. Unfortunately, this feature always seems to affect voice quality negatively—much more research is needed to develop the necessary heuristics. G.729 and G.729A are two codec standards that support some degree of implementation of this feature, but there are so many incompatible solutions among current products that it is essential to require any products that support this feature to provide a means to turn it off. Finally, when this feature is implemented for G.729 or G.729A, the G.729B standard should be complied with.
Another essential aspect of all gateway products is their ability to use signaling (for call establishment rather than voice transport) at the appropriate level of interconnection. For example, a two-stage gateway that provides a toll bypass (or trunk replacement) service must support call establishment signaling (in most cases, SS No. 7 ISUP) with the access switch. Similarly, a one-stage enterprise gateway that connects to a PBX must support access (typically Q.931) signaling. Even the lowest-end gateway products—one-port residential gateways that interconnect analog telephones with the Internet—must still comply with the standard in-band signaling (that is, provision of dial tone, acceptance of dialed tones, and recognition of on-hook/off-hook events) in order to work with the telephone. Thus, on the traditional telephony side, gateway products destined for a particular function must support appropriate in-band signaling. On the IP side, gateway products should support (and all advertised products invariably do support) the H.323 family of standards. In particular, at the time of this writing, H.323 version 2 is supported by leading products. In addition, some products also support the SIP protocol as an add-on, since several providers—especially those integrating cable networks—require SIP compliance. To this end, industry attention to SIP is growing steadily at the moment of this writing.
One function present in several products, is gateway self-discovery. This is a novel feature particularly relevant to the gateways at the edge of the PSTN. For a phone-to-phone toll bypass service, calling party access to a (local) gateway is achieved through a local telephone call. For the service to be cost effective, the called party must also be dialed from its local exchange, so the local terminating gateway must be the endpoint for the IP-carried part of the call. The IP addresses of the gateways (relative to the local PSTN numbers they serve best) are currently hard-coded, but products that support dynamic discovery of the gateway are emerging. (Note that, as an alternative, gatekeepers could perform self-discovery.) To handle the case in which a local terminating gateway cannot be reached (because of network congestion, gateway overload, or network server failure), advanced gateways often support PSTN fallback. This feature allows a phone-to-phone toll bypass call that otherwise cannot be completed to be completed entirely over the PSTN.
Gateway products fall into three general categories:
- Small (branch office or residential) gateway products. One- to four-port interfaces to which POTS telephones are connected.
- Enterprise-grade (access gateway) gateway products. Support up to a thousand ports. On the traditional telephony side, enterprise-grade gateway products typically interface with a PBX (and employ Q.931 signaling) and are usually located on the enterprise premises. As an exception, they can be located at an ISP or LEC, but with the sole purpose of providing PBX-emulating Centrex services to a particular enterprise that does not own a PBX. Enterprise gateways support one-stage dialing: PBXs divert voice-over-IP traffic based on either a specific number or an algorithm computed by the PBX.
- Carrier-grade (trunking gateway) gateway products. Support up to 10,000 ports located on the premises of IP telephony providers (for example, ISPs, IXCs, and LECs). The connection (and, therefore, the signaling arrangements with the PSTN) requires the use of Signalling System No. 7 (SS No. 7) ISUP. If the SS No. 7 transaction capabilities (TC) are supported, then the VoIP gateways equipped with the application supporting the Intelligent Network Application Protocol (INAP) can also benefit from using Intelligent Network. To get the SS No. 7 support, the VoIP gateways can be paired with the SS7 gateways.
The rest of this section deals with carrier- and enterprise-grade gateway products.
The gateway hardware invariably consists of line modules (cards) mounted on a rack and a management board that is responsible for the control of line modules. Communications among the line modules and the management card are carried through fast-switching fabric, such as an asynchronous transfer mode (ATM) cell backplane, at a high rate (100 to 200 Mbps in the case of the ATM fabric). Switching fabric components are augmented by Ethernet cards and ports (and necessary wiring) as well as the cooling system (typically fans). Cooling is important because of the highly CPU-bound nature of codec software, which necessitates the employment of multiple digital signal processors (DSPs). In fact, the two major limitation factors for scalability of gateways are heat and space. The system is administered via the operator console, which may (but does not have to) be part of a particular offering; however, console ports are provided on the gateway chassis. In high-end products, the line modules are hot-swappable: Any line card can be replaced by another one without the need for reconfiguration—it will automatically load its configuration from the management board once it is in the slot.
As you may recall, the ISDN primary rate interface (PRI) service provides bandwidths of 1.544 Mbps for T1 lines in the United States and 2.048 Mbps over E1 lines in Europe. This translates to twenty-three and thirty 64-kbps bearer (B) channels, respectively, augmented by a 64-kbps data (D) channel. In high-end gateway products, the capacity is measured in quad-T1 and tri-E1, corresponding to four T1 and three E1 circuits, respectively—the capacity of one card. Cards can be added to a system, and systems can be stacked on top of each other.
In addition to PRI, a number of other trunking services (which we do not cover) are supported by the high-end products. Note that ISDN is a typical and widely deployed use of trunking services; while a T1 line is normally associated with a single telephone number, when it is set up for ISDN B channels, each can be assigned a separate number. The lines can be configured for both inbound and combined inbound and outbound calling. Another configuration option is alternating circuit-switched voice and data, which permits modem calls.
As far as software is concerned, each line module’s central processing unit (CPU) executes the gateway operating system independently. The operating systems themselves are often proprietary. High-end products provide both command-line and graphical user interfaces for monitoring, maintenance, and operations of the gateway via the console or telnet connection. In addition, most systems support Simple Network Management Protocol (SNMP) for the same purposes. To this end, an important feature of a gateway is provision of SNMP alarms for a number of causes, including power failure and overheating. Another important feature is automatic turn-off of the overheated or otherwise problematic line modules by the management board.
An important function of gateway software is billing. Gateways should generate call detail records, whose attributes are described in more detail in the next section, and then pass them to the gatekeeper responsible for billing. Part of the software is libraries that provide the application programmer’s interface (API) that allows the use of third-party billing software in support of various paying methods, such as prepaid calling cards or credit cards. (A key feature of a prepaid billing system is to send a call drop request to the originating gateway when the caller runs out of prepaid funds.) Billing is of course inseparable from authentication. In two-stage calling, the user is identified by a personal identification number (PIN); the Automatic Number Identification (ANI) parameter passed from the PSTN is also used for authentication. Again, the authentication may be performed by gatekeepers.
Proprietary coding and compression techniques often make gateways from different vendors noninteroperable. While enterprise network managers can solve this problem by purchasing a matching set of gateways from a single vendor or ensuring that the gateways from selected vendors do interoperate, neither ISPs nor telephone companies can presently ensure that calls originating or terminating in another ISP’s or telephone company’s network can be successfully handled by the receiving gateway. This interoperability issue is one reason (QoS is the second) why the quality of voice-over-IP calls has been reported to be high in the enterprise networks, but remains problematic over the Internet.
Finally, it is important to note that distributed implementations of VoIP gateways are emerging. These implementations are generally associated with so-called soft switches and media gateways. Soft switches provide call control and signaling interworking, while media gateways handle the transcoding of voice streams tailored for different networks. The aim is to make distributed VoIP gateways more scalable and programmable than their monolithic cousins and ultimately to ease the introduction of new services.
