By Paolo Galtieri This article provides an overview of Voice over Internet Protocol (VoIP), one of the many applications taking advantage of the enormous growth of the Internet over the last several years. With VoIP, the Public Switched Telephone Network (PSTN) of today and the Internet are converging. The old circuit-switched PSTN, where resources are wasted through inefficient use, is being replaced by one ubiquitous, packet-switched network. This article discusses one of the popular VoIP protocols, the H.323 specification, developed by the International Telephone Union (ITU). The public switched telephone network The PSTN is the wiring system used for carrying phone traffic around the world. It began strictly as an analog-circuit-based system where voice was transmitted over wires connecting two parties by modulating electrical signals along the wire. In its most basic form, this process required two wires per active connection. This worked well, as long as the phones were relatively close to each other and there were only a small number of people talking at once. As the demand for phone service grew, upgrading and enhancing this system became very expensive and not very practical. To solve this problem, techniques were developed to multiplex many calls on a single wire using a different carrier frequency for each signal. The method worked as long as operators did the job of connecting the two parties. When it became impractical, the operators were replaced by electrical/mechanical switches. Unfortunately, such hardware was expensive to purchase and maintain. As time and technology progressed, the mechanical switches were replaced by digital equipment. Today the PSTN is a combination of analog and digital systems. It includes the well-known wireline telephone network, as well as access points for wireless, cellular, personal communication system (PCS), and other transmission media. A user s access to the PSTN can be either analog (from the phone at home to the central office) or digital (connected to the PSTN via a public branch exchange (PBX) or an integrated services digital network (ISDN). From the PSTN central offices, all phone calls exist in digital, using time division multiplexed (TDM) channels of 64 Kbits/sec each to carry the modulated voice samples. The problem today with the PSTN is that network resources, which are always voice-grade TDM circuits, are tied up for the entire time a call is in progress, regardless of the amount of actual bandwidth being used. For example, when a user surfs the Internet, data is passing along those phone circuits less than 50% of the time. In addition, if the user stays connected for hours, a significant amount of resources are used. To improve the situation within the current PSTN is difficult, if not impossible. There are two reasons for this. The first reason is cost. It can be very expensive to replace existing wire lines and other hardware. The second reason is time. Users are demanding more and more services, for example, caller id, call waiting, call messaging, faxing, and so on. Therefore, upgrading the current infrastructure takes a long time, and users don t want to wait. The time has come to take a revolutionary approach to solving the problem. The solution is to replace the way the current system is used with something new. This approach is not easy, nor is it cheap, but its long-term potential outweighs the short-term drawbacks. One of the proposed solutions is to migrate to a packetbased network such as the Internet. The Internet In the late 1960s to the mid 1970s, the Defense Advanced Research Projects Agency (DARPA) began developing a network of military installations and universities with the goal being to exchange a variety of data between them. The protocols developed for this became what we know today as TCP/IP. Over time, more and more universities, major companies, and other networks were integrated into this early network. By the 1990s, this network evolved into what we know today as the World Wide Web. In the case of the PSTN, most devices perform specific functions, for example, call switching. On the Internet, the devices are computers that are capable of performing many different functions. New high-speed cables are being installed every day across the world to improve Internet access, and more sophisticated and powerful computers are becoming available. These computers are less expensive and easier to maintain than some of the sophisticated switches of today. While PSTN resources are limited, Internet resources are accessible to everyone, as long as there is bandwidth available. If two parties connected over a packet-switched network are not using the full bandwidth of the network, other nodes can use the available bandwidth for transmitting data. All of this data can be of different size and purpose and not constrained to 64 Kbits/sec channels as with the PSTN using TDM. Convergence The explosive growth of the Internet has shown the possibility of having a single network for everything. The Internet is already a ubiquitous network. Almost everyone has access to it, either from home or work. With technology changing as rapidly as it is today, the Internet and the packet-switched PSTN are converging into one single integrated network. The convergence of the Internet and a new packet-switched telephone network is possible in part because the TCP/IP protocol family is the most widely used network protocol today, and the standard to which all applications are beginning to conform. To achieve complete integration, the requirements of voice traffic and data applications must be resolved.
Integrating the requirements for voice traffic and data applications over the same network has proven to be a difficult task. The requirements are often in conflict with each other, and support for older technologies must remain if users are to accept the change. Phones are everywhere in homes and along the streets, and no one wants to throw them out. The PSTN is a 5-nines system, that is, it is available 99.999% of the time, with a high quality of service (QoS) and sound quality. It is rare for calls not to go through or for the quality of the sound to be unacceptable. Any reduction in this availability and quality is going to cause customer dissatisfaction. One of the strong points of the PSTN is that it is a secure network, since much of it is closed to the outside world. This is not true of packet-switched networks. As long as one node has access to the network, it can view all traffic on that network. This security issue is being addressed by new protocols, such as Internet Protocol Security (IPsec), which is a developing standard for security at the network or packet-processing layer of network communication. In today s competitive business environment, time-to-market is a critical factor for companies if they want to take advantage of this convergence. The Internet provides the building blocks for companies to enter the market with new applications without having to wait for older technologies, such as the PSTN, to be upgraded. The integration of PSTN features into the Internet and the World Wide Web (WWW) continues at a hectic pace. The remainder of this article will focus on one of these applications, voice telephony over a packet-switched network. Voice over IP What is Voice over IP (VoIP)? Simply put, it is a set of facilities for managing the delivery of voice information using the Internet Protocol (IP). Voice information is sent in digital form using discrete packets rather than in the traditional, circuit-committed protocols of the PSTN. Voice over IP standards There are currently two major international groups defining standards for VoIP: the ITU, and the Internet Engineering Task Force (IETF). The ITU has defined the standard H.323, which covers VoIP, while the IETF has defined RFC 2543, Session Initiation Protocol, and RFC 27053, Media Gateway Control Protocol. Both SIP and MGCP are RFC-draft standards in the IETF. This article concentrates on the H.323 specification of the ITU. However, in the long term, SIP is likely to become more prevalent. At this time, however, SIP is still a developing standard while H.323 has been in place since the mid 1990s. Consequently, most current implementations use H.323. H.323 overview The H.323 recommendation is an umbrella specification for implementing packet-based multimedia over LANs that cannot guarantee quality of service. The specification defines several basic elements in an H.323 network topology: terminals, gatekeepers (GK), multicast units (MCUs), and gateways (GW). A terminal is defined as a hardware and software device with a signaling endpoint that supports one or more users entering into realtime communications with one or more other parties. Although listed separately, MCUs typically are part of gatekeepers or terminals serving more than one user. The H.323 specification defines the concept of a zone. An H.323 zone contains terminal devices, gateways, and other MCUs managed by one gatekeeper. A zone can span a wide geographical area and can contain multiple LANs connected by routers and switches. Figure 1 depicts an example of a zone with a gatekeeper. H.323 Terminals Gatekeeper (GK) Gatekeeper (GW) PSTN Router Local Area Network Routing Media gateway Switch/ Router H.323 Terminal to other zones Local Area Network H.323 Multipoint Control Unit (MCU) Figure 1: H.323 Zone with Gatekeeper Applied Computing Technologies / Winter 2000
up the connection and negotiate the media format that will be transferred over the connection. A gateway is a device that bridges diverse network architectures, such as the packet-switched Internet to the PSTN. The H.323 specification defines procedures for endpoint registration with a gatekeeper. An endpoint can be a terminal, typically associated with a user, another gatekeeper, or a gateway. The specification also defines procedures for negotiation of call-control and logical-channel capabilities. The H.323 specification references two other ITU specifications, H.225.0 and H.245.0. The H.225.0 specification defines registration, authentication, and status (RAS) procedures for gatekeeper signaling as well as callsetup procedures. The logical-channel and other call-control capabilities are defined in recommendation H.245.0. The H.323 protocol stack is shown in Figure 2. Multimedia Applications Terminal Control and Mgmt As shown in Figure 2, RTP/RTCP data is the payload data of a User Datagram Protocol (UDP) packet. How do the analog signals coming from the endpoint convert into the payload data? This conversion is the function of codecs (coders/decoders). There are different types of codecs and each provides a different quality of sound. The bit rate of most narrow-band codecs today varies from 1.2 Kbits/sec to 64 Kbits/sec; the higher the bit rate, the better sound quality. Some of the more popular codecs are: G.711. This is the oldest of the codecs and was approved by the ITU in 1965. This codec has a sampling rate of 64 Kbits/sec. G.722. Although G.711 has very good quality, there is still some loss in quality for voice frequencies above KHz. The G.722 codec provides better digital encoding of KHz audio at 48, 56, or 64 Kbits/sec. G.723.1. This codec operates at either 5.3 or 6.4 Kbits/sec. Any voice communication using this codec will demonstrate some degradation. G.729. This codec operates at 8 Kbits/sec and is very popular for voice-over-frame relay and V.70 voice and data modems. As noted in Figure 2, the call signaling portion of the H.323 protocol is carried over TCP rather than UDP, because TCP guarantees in-order delivery of packets to the application, while UDP requires the application to make sure all packets arrive and arrive in the right order. G.nnn H.261 H.263 RTP RTCP UDP H.225.0 (RAS) H.225.0 Call Signaling TCP H.245.0 Logical Channel Signaling The following sections describe two examples of how voice data is sent between endpoints. The first example is a simple call between two endpoints over a packet-switched network. The subsequent example shows a call using a gateway to the PSTN. Basic H.323 call model The basic call model for H.323 consists of five phases: The H.323 specification calls out RFC 18890, the Real Time Protocol (RTP), for all media transport. The RTP specification is an IETF draft standard and provides end-to-end transport of realtime data. RTP does not guarantee the quality of service (QoS) of the transmission, however, it does define ways to transmit isochronous data by including: Information on type of data being transmitted Time stamps Sequence numbers The Real Time Control Protocol (RTCP) is part of RFC 1889 and provides end-to-end monitoring of data delivery and QoS by providing information such as: Amount of jitter Average packet loss IP Layer Link Layer Figure 2: H.323 Protocol Stack Jitter is the amount of delay introduced in transmitting data over a wire, if there is insufficient bandwidth available for the packet. The RTP/RTCP standard is not used to do call setup or tear-down. It requires the use of a separate signaling protocol, for example, those called out by the H.225.0 and H.245.0 specifications to set Call setup Initial endpoint communication and terminal capability exchange Establishment of multimedia communication between endpoints Call services request and negotiation Call termination Calls between two endpoints can be either direct or routed through the gatekeeper. In this discussion of a direct call, an endpoint is defined as a point of entry and exit of media flows. The following sections describe the procedure involved in placing a call between two endpoints, A and B, each with an IP address on the same subnet, for example, 10.11.12.13 and 10.11.12.14. Establishing a call between the endpoints requires two TCP connections between them, one for call setup, and one for capability exchange and call control. Phase 1: Call setup The caller, endpoint A, connects to the callee, endpoint B, on a well-known port number, port 17201, and sends the call setup message as defined in the H.225.0 specification. This message includes information such as: Message type in this case, SETUP Bearer capability indicates whether the call is going to be audio only or audio and video Called party number and address Calling party number and address
Protocol Data Unit (PDU), which includes a protocol identifier to indicate what version of H.225 to use a source address field listing sender s alias, for example, an e-mail address, and other information Upon receipt of the setup message, endpoint B must respond with one of the following messages: Release Complete, Alerting, Connect, or Call Proceeding. In this example, endpoint B sends the Alerting message. This message must be received by terminal A before its setup timer expires. After sending this message, the user at terminal B has up to three minutes to accept or refuse the call. When the user picks up the call, a Connect message is sent to endpoint A. At this point, the second phase of the call setup can proceed. Phase 2: Capability exchange Call control and capability exchange messages, as defined in H.245, are sent on the second TCP connection. Endpoint A opens the connection on a dynamically allocated port on the callee s endpoint after receiving the address in one of the following messages: Alerting, Call Proceeding, or Connect. The connection remains active for the entire duration of the call. The control channel is unique for each call between two endpoints, allowing several different media streams to be present. The first message sent is a TerminalCapabilitySet message that includes information as to what codecs a terminal supports. Both terminals will send the message to each other and either acknowledge it with a TerminalCapabilitySetAck message, or reject it with a TerminalCapabilitySetReject message. The two sides will continue to exchange the messages until they agree on the capability set. Once the two sides have agreed on things, the call continues. Phase 3: Beginning the call Once the capability setup is agreed on, the two terminals, A and B, need to set up between themselves the voice channels over which to exchange data. To open logical channels to B, A sends an H.245 OpenLogicalChannel message to B. This message specifies the type of data being sent, for example, which codec to use, such as G.711, G.723, and so on. For voice data, this message also includes the port number that B should use to send RTCP receiver reports. As soon as B is ready to receive data, it sends an OpenLogicalChannelAck message to A. This message contains a port number on which A is to send RTP data and a port number on which to send RTCP data. Endpoint B can be doing the same thing at the same time. Once the channels are established, dialog can begin. Phase 4: Dialog At this point, the two sides can exchange RTP packets containing voice data. Periodically, during this exchange both sides will send RTCP packets. As mentioned earlier, quality of the exchange is monitored by this function. If one side or the other sees that the expected rate of exchange is degrading due to line problems, there are facilities within the H.323 specification to make adjustments. Once the call is completed, and one side or the other hangs up, the final phase begins. Phase 5: Termination To terminate an H.323 call, (user at endpoint A hangs up), Endpoint A has to send an H.245 CloseLogicalChannel message for each channel it has open to B. Endpoint B has to reply to each of those messages with a CloseLogicalChannelAck message. When all the logical channels are closed, A sends an H.245 endsessioncommand. Endpoint A then waits until it has received the same message from B and then closes the channel. Finally, both A and B send an H.225 ReleaseComplete message over the call signaling channel assuming it is still open, which closes that channel and ends the call. This description of an H.323 call using a packet-switched network as the underlying media is very brief. This function can be accomplished today on Linux systems with such products as the PhoneJACK or LineJACK from Quicknet Technologies, Inc., and by using an open source version of the H323 protocol. On NT systems, the same task can be achieved using NetMeeting from Microsoft and a sound card. Though it is useful to explain the principles of the H.323 protocol, this scenario is not likely to happen in reality. In this example, both sides were defined to have known IP addresses. In the real world, most of the Internet Service Providers (ISPs) dynamically allocate the IP addresses of their subscribers. A realistic example showing a gateway is discussed in the next section. PSTN and H.323 interoperability H.323 gateways and gatekeepers The PSTN is unlikely to disappear in the near future. Customers on the new network will need to be able to talk to customers on the PSTN. This interoperability is provided by the H.323 endpoint called the gateway. The H.323 gateway, also called an IP gateway, is a hardware and software device that converts signaling protocols and data transmission protocols from one form to another. This conversion process is shown in Figure 3 below: Gateway Gatekeeper Figure 3: IP Gateway Intranets Internet PSTN Again, there are two users in the process. User A is sitting at a terminal, while the other user, B, is waiting at home by the phone attached to the PSTN. A gatekeeper is also shown in Figure 3. The purpose of this device is to perform all network-based services, such as registration, admission, and status (RAS) functions, and address mapping. For example, if a gatekeeper is present, all endpoints managed by that gatekeeper must register with it during start-up. This function is useful in attempting to call someone the gatekeeper will know whether the other user is accepting calls. It also performs the function of redirecting calls, for example, if a user doesn t answer the phone, the GK might redirect the call to an answering machine. Although a GK does not need to be present, it typically is present. Otherwise, the capabilities it provides would have to be present in the GW, therefore making it more complex. Applied Computing Technologies / Winter 2000
ple, if the GW is in Europe, then the international dial prefix will be removed. As soon as the GW is notified by the PSTN that the phone at user B s house is ringing, it sends the H.225 Alerting response to terminal A. As soon as the phone is picked up, the H.225 Connect message is sent. As part of the Connect message, a transport address that allows terminal A to negotiate codecs and media streams with terminal B is sent. At this point, the same process described in the earlier example applies, regarding the H.225 and H.245 messages. Calling someone via an IP GW is a little more complex than in the prior example. Such a call consists of the following phases: 1. Contacting the GK 2. Requesting permission to call 3. Call signaling 4. Call termination Phase 1: Contacting the gatekeeper The first thing user A s terminal does when a call is initiated is attempt to find a gatekeeper (GK). To do this, it sends out a Gatekeeper Request (GRQ) message and waits for a response. When it receives the Gatekeeper Confirm (GCF) message, the terminal registers with it by sending the Registration Request (RRQ) message and waiting for the Registration Confirm (RCF) message. If more than one GK responds to the GRQ, the terminal will choose to use only one of them. Phase 2: Requesting permission to call Once the registration is complete, user A must first request permission from the gatekeeper to initiate the call. To do this, terminal A sends an Admission Request (ARQ) message to the gatekeeper. This message will include information such as: A sequence number A GK assigned identifier The type of call in this case, point to point The call model to use, either direct or gatekeeper routed The destination information in this case, the phone number of user B An estimation of the amount of bandwidth required, which can always be adjusted later by a Bandwidth Request (BRQ) message to the gatekeeper If the GK allows the call to go through, it sends an Admission Confirm (ACF) message. This message includes the following: The call model used The transport address and port to use for call signaling (in this example, the IP address of the GW) The allowed bandwidth At this point, everything is set up to actually perform the call. Phase 3: Call signaling Now that everything is set up, terminal A can send the Setup message to the GW. Since the destination phone is connected to an analog line (the PSTN), the GW will go off-hook and dial the phone number using digital tone multi frequency (DTMF). In this case, the GW is converting the H.225 signaling into the signaling present in the PSTN. If the remote phone were on an ISDN line, then the GW would convert the H.225 signaling into Signaling System 7 (SS7) protocol messages. Depending on the location of the GW, the number dialed may need to be converted. For exam- In this example, the destination phone is analog. Therefore, it requires the GW to detect the ring, busy, and connect conditions so it can respond appropriately. Phase 4: Call termination As in the prior example, whoever hangs up first needs to close all the channels that were open, using the H.245 CloseLogical Channel message. If the gateway terminates first, it then sends an H.245 EndSessionCommand message to terminal A and waits for the same message from A. The gateway then closes the H.245 channel. Once all channels are closed between terminal A and the GW, each must send a DisengageRequest (DRQ) message to the GK. This message lets the GK know that bandwidth is being released. The GK sends a DisengageConfirm (DCF) message to both the terminal and the gateway. At this point, both the gateway and the terminal could send an UnregistrationRequest (URQ) to the GK, but there is no reason to do so unless one side decides to shut down the telephony software, such as terminate NetMeeting. As long as the gateway remains registered with the GK, it can continue to process calls. This example is realistic of the type of conversation a user is likely to have. Since this is the type of call most likely to occur, the gateway is going to be a critical device in the new packet-switched voice network. It also happens to be the type of device Motorola has the knowledge base and partners to develop. Paolo Galtieri has been with Motorola for seventeen years in various roles. He is currently a senior staff engineer for Motorola Computer Group s Telecom Business with responsibilities for integrating third-party-communications hardware and software into custom telecom solutions. He attended the University of California at Berkeley. References Recommendation H.323 (09/99) Packet-based multimedia communications systems RFC 2543, SIP: Session Initiation Protocol RFC 2705, Media Gateway Control Protocol (MGCP) Version 1.0 Recommendation H.225.0 (02/98) Call signaling protocols and media stream packetization for packet-based multimedia communication systems Recommendation H.245 (09/98) Control protocol for multi media communication RFC 1889, RTP: A Transport Protocol for Real-Time Applications, IETF Publication. Douskalis, Bill, Hewlett-Packard Company (Copyright 2000), IP Telephony, Prentice Hall PTR, Prentice-Hall, Inc. Black, Uyless (Copyright 2000) Voice over IP, Prentice Hall PTR, Prentice-Hall, Inc. Hersent, Olivier, David Gurle, and Jean-Pierre Petit, IP Telephony, Packet-based Multimedia Communications Systems, Copyright Pearson Education Limited.