Encapsulation is another approach that is only useful for SIP/PSTN gateways. Using this approach, PSTN-to-SIP translation is done to construct the appropriate SIP message, then the PSTN protocol message is encapsulated and included with the SIP message as a message body. If the SIP message is received by another SIP/PSTN gateway, the resulting PSTN signaling message is constructed from both the SIP message and the encapsulated PSTN message that was received by the other gateway. This approach offers the possibility of transparency (i.e., no loss of PSTN information as a call is carried across a SIP network). However, this only works in a network in which only one variation of PSTN protocol is used. Unlike Internet protocols, PSTN protocols vary by region and are not compatible without a special type of PSTN switch capable of converting one message format to another. There are many dozens of protocol variants used throughout the world.

Another disadvantage of encapsulation is that the PSTN message bodies must be encrypted if they are transported over the public Internet, or used in a network with native SIP devices. This is because private information can be carried in PSTN messages because PSTN protocols assume a different trust model than an Internet protocol such as SIP. To prevent accidental disclosure of this information, the message bodies must be encrypted by the originating gateway and decrypted by the terminating gateway, which adds significant processing requirements and call setup delay.

Encapsulated PSTN messages are carried as MIME bodies, which have been standardized for both ISUP and QSIG [6].

11.3 Media Gateway Control Protocols

There are a number of protocols used to decompose the operation of a gateway, which are often used in SIP/PSTN gateways. These protocols are known generally as media gateway control protocols. Their relation to a signaling protocol such as SIP is shown in Figure 11.1. Media gateway control protocols are not peer-level signaling protocols—they do not perform the rendezvous and negotiation functions of a signaling protocol such as SIP. Instead, they allow a gateway to be decomposed into a signaling element and a media component. The media component, a media gateway (MG), can provide PSTN trunks or RTP/ SRTP connections, which are under the control of the media gateway controller (MGC). The MGC in turn uses a signaling protocol such as SIP or PSTN signaling to setup connections with other elements. Media gateway controllers used to be called softswitches. Often, a single or pair of media gateway controllers will control a number of media gateways. Media gateway control protocols are master/slave protocols—the MGC tells the MG what to do—there is no negotiation between them. Some common media gateway control protocols include

Figure 11.1 SIP and media gateway control protocols.

MGCP [7] and H.248 [8]. H.248 was initially jointly published by the ITU-T as H.248 and in the IETF as MEGACO [9]. The current version is maintained by the ITU-T as H.248.1 version 1 [10].

11.4 H.323

A related Internet communications protocol is the ITU recommendation H.323, entitled “Packet-Based Multimedia Communication.” H.323 is introduced as a related protocol to SIP for signaling VoIP and multimedia communication.

11.4.1 Introduction to H.323

H.323 [11] is an umbrella recommendation that covers all aspects of multimedia communication over packet networks. It is part of the H.32x series of protocols that describes multimedia communication over ISDN, broadband (ATM), telephone (PSTN), and packet (IP) networks, as shown in Table 11.1. Originally developed for video conferencing over a single LAN segment, the protocol has been extended to cover the general problem of telephony over the Internet. The first version was approved by the ITU in 1996 and was adopted by early IP telephony networks. Version 2 was adopted in 1998 to fix some of the problems and limitations in version 1. Version 3 was adopted in 1999 and includes modifications and extensions to enable communications over a larger network. Version 4 was adopted in 2000 with some major changes to the protocol. Versions 5 and 6 made very small changes to the protocol.

network with another protocol network, such as the PSTN. An MCU provides conferencing services for terminals.

Some of the protocols referenced by H.323 are shown in Table 11.2. H.225 is used for registration, admission, and status (RAS), which is used for terminal- to-gatekeeper communication. A modified subset of Q.931 is used for call setup signaling between terminals. (The H.323 usage of Q.931 is not compatible with Q.931 as used in an ISDN network.) H.245 is used for control signaling or media negotiation and capability exchange between terminals. T.120 is used for multipoint graphic communications. H.323 audio codecs are specified in the ITU G.7xx series. Video codecs are specified in the H.26x series. H.323 also references two IETF protocols, RTP and RTCP, for the media transport which are described in Chapter 12. The H.235 recommendation covers privacy and encryption, while H.450 covers supplementary services such as those commonly found in the PSTN (e.g., call forwarding, call hold, and call park).

11.4.2 Example of H.323

Figure 11.3 shows a basic call flow involving two terminals and a gatekeeper. The flow shows the interaction between the various elements and the various protocols used to establish the session. The call begins with an exchange of H.225.0 RAS messages between the calling terminal and the gatekeeper. All RAS messages are transported using UDP. It is assumed that both terminals have already registered with the gatekeeper using the registration request (RRQ) message. The calling terminal sends an admission request (ARQ) message to the gatekeeper containing the address of the called terminal and the type of session desired. The address could be specified as an H.323 alias, E.164 telephone number, e-mail address, or URL [12]. The gatekeeper knows about all calls in the zone it controls; it decides if the user is authorized to make a call and if there is enough bandwidth or other resources available. In this example, there is enough bandwidth, so the gatekeeper allows the call to continue by sending an admission confirmation

Figure 11.3 H.323 call flow example.

(ACF) message. The ACF indicates to the calling terminal that end-point message routing, or the direct exchange of H.225 call signaling messages with the called terminal, is to be used. Alternatively, the gatekeeper can require gatekeeper routed signaling, where the gatekeeper acts like a proxy and forwards all signaling messages between the terminals. The gatekeeper has also translated the destination in the ARQ into a transport address that was returned in the ACF.

The calling terminal is now able to open a TCP connection to the called terminal using the transport address returned in the ACF and send a Q.931 Setup message to the called terminal. The called terminal responds with a Call Proceeding response to the calling terminal. The called terminal must also get permission from the gatekeeper before it accepts the call, so an ARQ is sent to the gatekeeper. When it receives the ACF from the gatekeeper, the called terminal begins alerting the user and sends an Alerting message to the calling terminal. When the user at the calling terminal answers, a Connect message is sent. There is no acknowledgment of messages because all these messages are sent using TCP, which provides reliable transport. These call signaling messages used in H.323 are a subset of the Q.931 protocol that covers ISDN D-channel signaling.

Figure 11.3 shows the use of H.323 FastStart, in which the Setup message contains the TerminalCapabilitySet information. This saves multiple messages and round trips compared to opening a second TCP connection between the