Gateways

A gateway provides transcoding services such as address translation, network protocol translation and audio/video coding translation between dissimilar conferencing technologies. This concept means that a user using one type of service - H.323 for example - could expect to connect to and communicate with another user that is using perhaps even a radically different type of service. This potential ability not only provides a bridge between differing technology that might be present at any given time but also technology as it has changed over time, extending the useful life of technology that was built on previous standards.

One of the most common gateways for use with H.323 is designed to transcode between H.320 ISDN videoconferencing and H.323 IP videoconferencing. Since many campuses have already invested heavily in H.320 and have mature H.320 applications, it is advisable to consider a model for H.323 deployment that includes such gateways as a complement to the IP-based service. This also permits existing and future communications with areas that do not have high-performance IP networks available or where ISDN may be a more affordable option. A secondary use for the H.320-to-H.323 gateway could be to provide redundancy for a LAN-based MCU service. Should a network break occur, a conference could be routed alternately from one MCU, across a local LAN, through an H.320 gateway over ISDN, back through a second gateway and onto the LAN local to the second MCU.

There are also common communication scenarios that call for the inclusion of traditional voice calls over the PSTN (public switched telephone network) in an H.323 communication. This may be as simple as needing to communicate with someone who has not yet implemented H.323 to extending H.323 services to users when they are mobile (e.g., using a cellular phone.) To enable this type of interconnection, an H.323/VoIP/voice gateway may be deployed. This scenario is growing in popularity, as it does not require that every participant have access to an h.323 endpoint and a quality IP connection. The scenario where some endpoint use h.323 video and others use voice works well for 'real life' deployments, where some users may be traveling or working from home without IP access. Further, the voice gateway provides a 'lowest common denominator' connectivity option which is useful for troubleshooting the more advanced video connections.

An emerging issue is the need to gateway between SIP and other network types, particularly h.323. SIP is gaining popularity in the VoIP space, and is also popular as a soft video endpoint. Bringing SIP soft endpoints together in conferences with larger H.323 room systems is important for many deployments. Several vendors offer MCU's which can bridge both protocols, functioning as a kind of gateway.

Whenever creating a gateway between the PSTN and the IP network, it becomes important to translate between the various addressing schemes. In general, the IP network is very flexible in regard to addressing and supports both numeric addresses like the Global Dialing Scheme (GDS) as well as alphanumeric addresses such as h.323 URL's of the form user@gatekeeper.hsww.edu. Therefore, the primary issue to examine is how PSTN calls will get routed on the IP network.

One possibility is to use Interactive Voice Response (IVR). In this scenario, the user on the PSTN network dials a telephone number associated with an ISDN line connected to the gateway. The IVR answers and says 'Thank you for calling. Please dial the extension of the party you wish to reach.' At that point the user dials the number and is routed to the appropriate IP destination. There is no correlation between IP numeric addresses and PSTN e.164 addresses. This scenario usually works for telephones, but is problematic for H.320 terminals, which often lack the capability of dialing extensions. In this case, it is necessary to use Direct Inward Dial, or DID. This means that for each e.164 telephone number there is an identical number registered on the gatekeeper. When the call comes into the gateway from the PSTN, the gatekeeper sees that the dialed number matches an endpoint on the IP network and connects the call directly without having to dial through the IVR. Keep in mind, that this requires a dedicated phone number for every terminal requiring this capability, which can get expensive.

There are several emerging technologies which focus on the issue of matching PSTN numbers with Internet addresses. These include ENUM, TRIP, and the tel URL. Each of these are IETF technologies and details can be found at the IETF web site. While they each solve an important problem, acceptance is not widespread. In particular, there are privacy issues associated with allowing individuals' telephone numbers and address information to be published on the Internet. The majority of these issues are expected to be worked out in the context of large VoIP deployments. Smaller video deployments should consider balancing DID and IVR approaches.

Other gateways - H.320-to-H.321 (ATM), H.323-to-H.321, and H.323-to-VRVS (Virtual Room Video Service, http://www.vrvs.org) also exist and should be included where needed.

Some CPU intensive audio transcoding can cause significantly delayed audio, resulting in an objectionable lack of audio/video synchronization. H.323 systems use G.723 and G.711 while H.320 systems use G.728 and G.711. G.711, the protocol in common, provides toll quality audio but uses 64Kbps. Disabling transcoding minimizes the audio delay due to the transcoding but would leave only 64Kbps available for video in a 128Kbps single circuit ISDN call. Enabling G.728-G.711 transcoding would reduce the audio bandwidth requirement to 16Kbps and free an additional 40Kbps for video. In a 384Kbps triple circuit bonded ISDN call, minimizing the audio delay might be deemed worth the minimal video degradation. Whether or not to permit audio transcoding should be decided on a call-by-call basis.

Supporting gateways can be operationally complex. Some service providers have recommended that users implement dual-technology codecs. For example, many group conferencing systems support h.323 and h.320. By recommending these systems, a service provider can centrally support the more desirable h.323 IP-based technology while allowing the user to manage (and pay for) their own dedicated ISDN BRI lines for h.320 compatibility. This has then benefit of ensuring the user has access to legacy technology if needed, but at a cost that encourages migration to more modern protocols.