Building Voice over IP

Building Voice over IP

 

Regardless of whats in between, a phone conversation between two people requires that each has both a microphone and a speaker. In the traditional telephone, the microphone is located in the mouthpiece and the speaker is located in the earpiece. In an analog telephone (like the one you have at home), the voice signal produced by the mouthpiece is sent directly along the wire to a telephone exchange or a local PBX.

If youre going to use IP telephony, youll still need a microphone and speaker. Those could be the microphone and speaker supplied with your PC or built into a PC-attached headset. But they could equally well be provided by a traditional analog telephone attached to an IP telephony enabled PBX (a so-called iPBX) or by a telephone plugged into a data port that supports IP telephony directly (an IP telephone). Regardless of whether its a PC or a traditional telephone attached to an iPBX or an IP telephone, the basic mechanics of how an IP telephone call works are the same.

The call

So what happens when you want to make a call? First of all, after youve dialed a telephone number or clicked on a name, signaling is required to determine the status of the called party available or busy -- and to establish the call (signaling is used for many other things too, but more on that later). Next, when the conversation starts, the analog signal produced by the microphone needs to be encoded in a digital format suitable for transmission across an IP network. The IP network itself must then ensure that your real-time conversation is transported across the available media in a manner that produces acceptable voice quality. Finally, it may be necessary for the IP telephony stream to be converted by a gateway to another format either for interoperation with a different IP based multimedia scheme or because you are placing a call to the traditional public telephone network. The overall technology requirements of an IP telephony solution can therefore be split into four categories signaling, encoding, transport and gateway control.

The standards

For each of these areas there exist standards. Unfortunately, in the key area of signaling there are two competing sets of standards H.323 (an ITU standard) and SIP (Session Initiation Protocol, an IETF standard). This is why discussions of IP telephony often seem to boil down to an H.323 vs. SIP argument. It is important to remember, however, that neither H.323 nor SIP alone make up a complete set of IP telephony protocols they are just the competing standards for signaling. Until recently there was a similar situation with gateway control protocols, with competition between IPDC (IP Device Control) and SGCP (Simple Gateway Control Protocol). Now, however, the industry appears to have agreed on a third standard, called MGCP (Media Gateway Control Protocol), which combines the advantages of its two predecessors. For details on which standards relate to signaling, encoding, transport and gateway control, see the protocol tables below.

H.323 vs. SIP

Given that two standards currently compete for the dominance of IP telephony signaling, how do you decide which is more appropriate? The good news is that the two protocol suites appear to be converging picking up good ideas from one another. In particular, the third and latest incarnation of H.323 (H.323 v3) has addressed some key performance issues (call setup delay and stateless processing to support UDP), which were initially key SIP advantages.

Most importantly, each suite supports (pretty much equally well) the majority of required end-user functions (including call setup and tear-down, call holding, call transfer, call forwarding, call waiting, conferencing and click-for-dial). The only functional differences are message waiting indication (which only H.323 supports), third-party control (e.g., a secretary placing a call on behalf of a manager, which only SIP supports, and certain conferencing functions. While the range of functions supported is similar, the H.323 v3 suite (by means of H.245) provides a somewhat more robust mechanism for 'capabilities exchange' than does SIP, which relies on the less descriptive Session Description Protocol (SDP). 'Capabilities Exchange' is the process by which it is determined whether a particular feature is supported by both participating entities.

However, functionality is by no means the only consideration in the H.323 vs. SIP debate. Equally important are Quality of Service (QOS), Scalability/Flexibility and Interoperability. Indeed, whereas the suites are relatively similar in terms of functionality, they differ quite substantially in these areas, as seen in the following table. Because SIP is a significantly less complex protocol, it is argued that it should scale better. This is an important consideration given that the Internet may well come to support 500 million IP telephony devices. However, it is my opinion that this potential advantage doesnt sufficiently compensate for the protocols current weaknesses in terms of QOS and interoperability. Most importantly, SIP doesnt provide for redundancy (making it unsuitable for carrier applications), doesnt support the emerging Differentiated Services/Policy Management approach to QOS and has a limited interoperability testing track record (largely because the protocol is new, having only been ratified in February 1999).

 

Does the H.323 vs. SIP debate even matter?

From a practical perspective, if you go out and research the IP telephony products that are available today youll find that many are still vendor specific, several support H.323 version 1, some support H.323 v2 and very few support either SIP or H.323 v3. This is particularly true of products targeted at enterprise solutions as opposed to carrier solutions (where H.323 support is more widespread).

In practice, what is likely to happen is that major vendors will support both approaches until it becomes clear either that one standard is going to die, or that the two are going to merge. That said it is certainly worthwhile clarifying vendors intended strategies with respect to signaling. If you are particularly concerned with high availability and interoperability, then a SIP-oriented solution might be too bleeding edge right now. Otherwise, both approaches pretty much deliver the same in terms of functionality. The only area where there is a noticeable difference is in the implementation of conferencing capabilities. Because SIP can be used to invite multiple parties to join a call, simple conference calls can be initiated without the requirement for a conferencing server (whereas H.323 does require one). In practice however, whether or not this is a constraint depends on the full vendor solution and approach rather than just the protocols that happen to be used.

 

Strategies for building VoIP networks

So much for the theory. How do you actually implement Voice over IP (VoIP)? There are a few different strategies available, including the following:

Simple toll bypass. Perhaps you just want to use IP to transport calls between offices within the corporate network. Such an approach requires little or no change to existing PBX, cabling and handset infrastructures, is relatively easy to implement and has no PSTN integration issues to consider.

Total IP telephony. Throw out your existing voice systems, replace the phone handsets with IP telephones that plug straight into 10BASE-T ports and implement LAN servers to provide (most of) the features your PBX once provided. Not for the faint of heart, but absolutely feasible with todays technology.

IP-enabled PBXs. This is the intermediate route dont change the existing cabling or handset infrastructure, but upgrade the PBXs so that the organizations core telephony systems speak IP telephony protocols. That means that PBX users can speak with other IP telephony users (e.g., PC-based NetMeeting users) as they become more prevalent but it also means that your PBXs will rely on IP telephony gateways to communicate with the outside world (unless the PBXs themselves provide such functionality). Two ways to do this either upgrade your existing PBXs or replace them with purpose built IP-PBXs.

The simplest of these strategies from an implementation perspective is probably the first, so well begin with that approach and then explore the additional requirements of the other two strategies.

Simple toll bypass

IP telephony toll bypass solutions are relatively straightforward to implement and pretty much similar to other forms of toll bypass (good old Time Division Multiplexing, Voice over Frame, and Voice over ATM). Before we get into the alternative approaches, lets examine what it is that were likely to be replacing. The following diagram shows two interconnected PBXs.

The basic function of a PBX (or Private Branch Exchange), as the name suggests, is to connect phone calls coming in on trunk lines from the Public Switched Telephone Network (PSTN) to the particular extension associated with the called party (and similarly, in reverse for outbound calls). However, PBXs are not limited to simply switching calls between the PSTN and the extensions they are equally capable of switching calls to extensions on other connected PBXs. In the good old days, these interconnections took the form of leased analog voice circuits if there were likely to be 10 conversations occurring between two offices at any one time, that meant you needed 10 separate leased lines. While that approach may still be taken for interconnecting smaller offices, most PBX interconnections today are digital. These digital connections might be T1 circuits dedicated purely to the interconnection of PBXs or, more likely, they are channels allocated on a Time Division Multiplexing (TDM) backbone, which divides up bandwidth between voice, various data streams (probably including IP) and perhaps video conferencing. The problem with both dedicated voice tie lines and multiservice TDM backbones is that bandwidth must be permanently allocated (and paid for) for each voice circuit despite the fact that the voice circuits are not used all the time. A better solution is to split the traffic into packets (or 'cells' or 'frames') so that all the traffic types can be interwoven in the most efficient manner. Each of the so called 'voice over' technologies voice over Frame Relay, voice over ATM and voice over IP are able to achieve this improved efficiency, but it is Voice over IP that best fits with most organizations convergence strategies.

How do you implement Voice over IP for toll bypass? The easiest approach to illustrate is simply to unplug the existing PBX tie line(s) and to plug them into a separate unit that converts the voice signaling and transport to an IP format. I call such units VoIP relays (theyre sometimes also referred to as VoIP gateways, but the gateway term is more commonly used for PSTN interconnection, as well discuss later). The VoIP relay connects directly to a router for transport over the IP network, as shown in the following diagram.

Examples of stand-alone products that can be used in this way include Nortels V/IP and Nokias IP Relay. [Incidentally, as we move through this chapter Ill mention products that illustrate concepts so as to help readers tie back theory to practice (and to provide a flavor for some of the vendors involved in different areas). However, it is emphasized that there are numerous vendors involved in IP telephony and no attempt is made here to provide a comprehensive list.]

There is no reason why the VoIP relay functionality need be provided in a separate unit you might instead want to implement the functionality in the PBX or in the router itself. For example, both Lucents Definity PBXs and Nortels Magellan offer IP-trunking, while various Cisco routers can provide direct PBX interfaces (including the 1750, 2600 and 3600).

Regardless of which approach you take, there are three practical design issues that youll need to address. Firstly, youll need to make sure that from a functional perspective the VoIP relay will relay sufficient signaling information to support the features in use on the PBXs. Secondly, youll need to consider whether standards are important in your situation while some of the products claim H.323 compliance, many still use proprietary schemes. This may not matter if your network is relatively small and you feel comfortable that the vendor is committed to standards, but give it consideration. Remember also that H.323 comes in three versions Ive not come across any products that currently support H.323 v3 (or SIP), but remember to check whether the H.323 support is v1 or v2. Thirdly, and perhaps most importantly, youll need to figure out how youre going to offer the voice quality thats required. This last aspect is a combination of the encoding scheme you choose and the QOS capabilities of the IP network and your VoIP relays ability to work with those QOS mechanisms. Since encoding and QOS requirements are substantial practical considerations in all IP telephony implementations, well discuss these issues at the end of this chapter.

 

A full-blown IP telephony solution

Toll bypass is a straightforward, cost-saving solution that can be implemented easily today. But what will a complete IP telephony solution look like? The following diagram illustrates the major components.

In a full IP telephony solution, all end-user devices (both PCs and phones) connect to the network via LAN connections (typically Ethernet). There are two major classes of end-user device: Software IP telephones and hardware IP telephones (i.e., telephones that rely on client software on PCs or stand-alone IP telephones). When these devices communicate with one another they do so directly, via an IP connection (using RTP). Another component, the gateway, is required so that calls can be placed to and from the public network. And finally, theres the servers that support IP telephony -- helping provide both basic call setup functions as well as the advanced features users have come to expect from traditional PBXs. Lets explore these components in a little more detail.

 

IP telephones

You can, of course, use IP telephony by means of a speaker and microphone, or a headset, plugged into a PC. The problem is that people like telephones. That dilemma can be solved in either of two ways: provide a telephone that speaks IP directly, or attach a handset to a PC. Examples of the former include Ciscos IP Telephones, Nokias IPCourier range, Siemens HiNet range and Lucents Defintity Hardphone. Each of these ranges includes full-featured handsets that seem pretty much the same as regular corporate handsets, except that they have a 10BASE-T port instead of plugging into a phone jack. The only other difference that users will notice is that these telephones currently need to be plugged into a power jack; however, thats likely to change as we see switches introduced that provide power via cat-5 cabling (for example, Cisco claims that its Catalyst 6000 will support this feature). Once the power issue is resolved, the solution becomes quite compelling one cabling system that users can plug any device into.

The disadvantage is also pretty obvious: More cat-5 jacks will be required. One way to avoid this, while potentially providing tighter integration with PC applications, is to use a software-based IP telephony solution in conjunction with a telephone attached to the PC. This may be achieved in a few different ways either you can get a purpose-built phone that attaches to a serial port (like Nokias SerialSet) or you can plug a traditional analog phone into a PC card or external adapter. And of course there may be some corporate users (like callcenter operators) for whom the PC-attached headset really is suitable.

If youre taking the PC-based route youll also need client software capable of supporting IP telephony. The client software may be stand-alone, standards-based IP telephony or multimedia software (such as Microsofts NetMeeting) or it may be part of a broader IP telephony family (most of the major vendors offer such a product).

When youre selecting IP telephones, bear in mind the following considerations:

If looking at stand-alone hardware IP telephones, make sure that the product chosen doesnt limit your ability to more tightly integrate with the desktop (e.g., through pop-up windows based on customer database lookups).

Check that the phones support suitable codec and signaling standards (see later for a discussion of encoding and codecs).

Determine the mechanism by which the phone (either hardware or software) will communicate its QOS requirements to the network (see later discussion of QOS).

Gateways

The function of a gateway is to convert between PSTN telephone calls and IP telephony calls. Sounds pretty simple, right? Unfortunately, it's not. The Public Switched Telephone Network (PSTN) in the United States (and in much of the developed world) really consists of two logically separate networks one for transporting the actual voice conversations themselves, the other for transporting signaling information using the SS7 protocol.

Before we get into the details, let's make sure were familiar with some public telephone network terms:

• Central Office. Also called an End Office or Local Exchange. This is where your local phone lines first connect into the public network.
• Central Office Switch. The local switch in the Central Office.
• Tandem Switch. Switches that provide inter-connection between Central Office Switches in a local area network (or, in the United States, within a LATA).

A Central Office Telephone Switch has not only voice trunks connecting it to other Central Office or Tandem Switches, but also SS7 Signaling Trunks which connect to Signal Transfer Points (STPs) -- the message switches that route SS7 signaling information. The separation of signaling from voice transport speeds the setup and teardown of voice calls and smoothes the operation of the network during periods of congestion. But this is not the only function of the SS7 network. By combining trigger capabilities within switches with Service Control Points (SCPs), SS7 enables Intelligent Network (IN) services and Advanced Intelligent Network (AIN) services. SCPs are essentially purpose-specific, high-performance computer systems where advanced telephony functions are implemented in software. This enables the provision of services like 800 numbers, call-forwarding and follow-me. Another important function of the SCP is to enable local number portability. In the United States, and in other countries, a near-term regulatory requirement is that local telephone numbers will be portable from one carrier to another (so that if you change local phone companies your number stays the same). What this means is that numbers can no longer be permanently associated with a particular physical port on a switch rather, it will be necessary for an SCP lookup to be performed to determine where a particular call should be routed.

An 'IP Telephony to PSTN Gateway' can operate without participating in SS7 by using in-band signaling on voice trunks. This enables calls to be placed from an IP telephony end-device to a traditional PSTN telephone number. However, if IP telephony users are to have access to Intelligent Network or Advanced Intelligent Network services, or to inter-operate with a ported number, another gateway is required: the SS7 to IP Telephony Gateway. The SS7 to IP Telephony Gateway enables IP telephony users to participate in IN and AIN services some of which are pretty important (e.g., calls to an 800 number, a call-forwarded number or a locally portable number). In practice, the voice and SS7 gateway functions are usually combined in commercially available gateway products. Make sure that you understand your SS7 gateway requirements and that the gateway product you select supports them.

 

IP telephony servers

An IP telephony call occurs via a direct IP connection between two points. However, the functions of call control, call routing and billing must be performed by an IP telephony server application (or in the case of large networks, a network of IP telephony servers). The actual term(s) used for the server(s) that performs these functions depends on whether were discussing H.323, SIP or a vendor-specific solution. Under H.323 this set of functions is performed by an application called a gatekeeper. Any particular vendor solution will provide these gatekeeper-like functions, and may also include support for additional features like voice messaging, voice conferencing and click-to-call in the same IP telephony server offering. Each vendor has a specific IP telephony server offering, and youll simply need to go through the process of making sure that each required feature is supported by a particular vendor. For a list of the kinds of features youll need to consider and a comparison of Lucent, Nortel and Cisco check this URL: https://img.cmpnet.com/nc/1012/graphics/f32.pdf.

 

A migration strategy

Moving straight to a full-blown IP telephony solution essentially means loading up your existing voice equipment and moving it out with a forklift, while probably at the same time upgrading your cabling system to ensure there are enough cat-5 outlets available. The sudden equipment and cabling obsolescence combined with the need for retraining of staff quite possibly make this approach a difficult sell to senior management (particularly since the immediate benefits of an IP telephone handset over a traditional phone may not be entirely obvious). There is an alternative approach that can be taken: IP-enabled PBXs.

Rather than replace the cabling and handsets, just upgrade or replace the PBX so that it speaks IP telephony to the outside world (and makes each of the attached phones appear to the outside world like an IP telephony endpoint). The solution would look like that shown in the diagram below.

First of all, check with your existing PBX vendor to determine whether a suitable upgrade is available. Both Lucent and Nortel will shortly be providing such support for their Definity and Magellan PBXs, respectively.

The other alternative is simply to replace your existing PBX with a pure IP PBX or 'iPBX.' This approach tends to be better suited to smaller office environments. Some models only support IP telephony, while others support both IP telephony and direct PSTN connections (with intelligent routing between the two). Some models are PC-based (typically running on Windows NT), while others are stand-alone units. Representative vendors of this class of product include AltiServ, NetPhone, ShoreTelecom and Vertical Networks.

 

Encoding schemes

When you speak, you cause air molecules to vibrate thats how sound is transported. If you were to plot the displacement of air molecules versus time you would be drawing the waveform of human speech, which might look like the graph below.

 

The function of the microphone in the telephone mouthpiece is to convert this waveform to an electrical signal. The electrical signal, if plotted against the same time scale would look the same. This electrical signal is an analog signal at any one time, the signal may have any value between the top and bottom peak values (as opposed to a digital signal, which is generated using only two signal levels representing the binary digits zero and one). In order to transport this analog voice signal over a digital network it is necessary to convert the analog signal to a digital data stream of ones and zeros. The process used to do this is called voice encoding (and the device or software program used for encoding and decoding is called a codec).

There are two basic approaches you can take to encoding. The first is to sample the signal strength itself at a rate higher than the frequency of the signal, as shown in the following diagram.

Sampling theory tells us that in order to reproduce the original signal from a digital sample we must sample at a rate at least 2.2 times the maximum frequency represented in the underlying signal. Since the human voice is made up of frequencies in the range 300Hz to a bit under 4,000Hz, we can use a sampling rate of 8.000 times per second. If for each sample we use 8 bits to represent the signal strength then well need a bandwidth of 8 bits, 8,000 times per second or 64kbps. Such an approach is called Pulse Code Modulation (PCM) and is the most widely used method to transport voice on todays digital public telephone networks. This sampling approach can be refined by doing some additional processing. Adaptive Differential Pulse Code Modulation (ADPCM), for example, predicts what the next value will be based on previous values then sends only the difference between the actual and predicted. Since the difference is smaller than the signal, less bits are required for transport. PCM and ADPCM are used in ITU standards G.711 and G.726, respectively.

The second approach to encoding is to split the voice signal up into substantially larger chunks, which represent whole, recognizable sounds used in human speech. This is the approach used for Codebook Excited Linear Prediction (CELP) and its variants; prevalent examples include MPE/ACELP (ITU Standard G.723.1) and CS-ACELP (G.729).

So which encoding scheme should you go for? The standard by which telephone voice quality is measured is so-called 'toll quality,' which in effect means the quality delivered by PCM (G.711), which is predominantly used in todays phone networks and is what you are used to when you use the public telephone network in developed countries. The great thing about PCM is that the algorithm itself is pretty straightforward, so not too much processing power is required that means high performance and relatively inexpensive encoding equipment. The downside of PCM is that it uses up a whole 64kbps for each voice circuit not so bad if youre a carrier with bandwidth to burn, but less optimal if youre a corporate customer getting heavily charged for that bandwidth. CELP makes a big difference in bandwidth requirements because the sampling frequency can be much lower this means that 'near toll quality' can be achieved with 8kbps. In order to do that CELP does a lot more processing than PCM, which originally meant substantially higher costs and lower throughput. All that said, 8kbps is simply four times better use of bandwidth than PCM and twice as good as ADPCM (which realistically needs 32kbps for near toll quality). For that reason, youll generally want to look for G.723.1 or G.729 encoding the two standard CELP implementations.

If youre working on calculating how much bandwidth youll need for a particular number of voice circuits youll also need to consider packet overhead. Rule of thumb? Triple the bandwidth requirement. I know that sounds pretty extreme, but heres the rationale: Voice packets need to be kept relatively small to minimize delay effects. If you assume the use of a G.729 codec, two samples of 10ms each will go into a single 20-byte packet. But the PPP/IP/UDP/RTP header is 49 bytes not a very efficient arrangement. There are header compression schemes available (RFC 2508 for RTP compression and RFC 2393 for compression of all headers except IP), but these are not widely implemented, and RFC 2508 wont operate across an IPSEC VPN. Unless youre implementing MPLS (discussed later) youre just going to have to put up with this overhead for now.

Quality of Service

Encoding is not the only driver of voice quality. The human ear is very sensitive to even minor changes in an audio signal (interestingly, the eye is much less sensitive to imperfect video). What this means is that if a signal is to be packetized, the packets must arrive predictably with minimal delay (a specific Quality of Service or QOS). These requirements do not apply to data networking, which is pretty tolerant of variable network performance even heavily transactional data applications wont be affected by the odd 500ms delay. Unfortunately, IP was originally designed as a data networking protocol so until recently IP networks offered little in the way of built in Quality of Service.

There are several approaches that can be taken to assure Quality of Service:

Data Link Layer QOS. ATM has well-known, built-in quality-of-service capabilities and with the adoption last year of 802.1Q VLAN tags, even Ethernet, can provide eight levels of prioritization tagging for each frame. The problem with data link approaches is that they only really work if the whole data path is based on the same data link layer. If your Ethernet LANs are interconnected by Frame Relay, the 802.1Q tags will do little good since they wont be passed.

Type of Service (TOS). Part of every Ipv4 header is the TOS byte, which includes 3 bits, allocated to priority (therefore three levels, the same as 801.Q) and another four bits used to define the type of service. For this to translate into something resembling a QOS mechanism, two things need to happen. Firstly, your router network needs to have the functionality to recognize TOS fields and provide different classes of service based on them (either automatically or manually, using filters). Secondly, the TOS bits need to be set either by the IP end system (e.g., our VoIP relay) or by the access router detecting the traffic type and setting the TOS bits.

Resource Reservation Protocol (RSVP). The way that RSVP works is that at the start of a session (or voice conversation) control packets are first sent through the network to reserve resources for the connection. If appropriate resources are not available (e.g., theres insufficient bandwidth available), then the connection is rejected. This approach can provide very strong QOS assurance, but it does not necessarily scale well. It is therefore suitable for intra-corporation requirements (like our toll bypass scenario), but it is strategically unsuitable for a world in which a large proportion of inter-business phone calls are placed via IP.

DiffServ. The Differentiated Services working group has refined the use of the TOS byte so that per-hop behaviors can be requested by a sender. This approach focuses on providing classes of service that the network makes available and which applications can choose to use, contrasted with RSVP in which the application dictates its requirements. DiffServ is less complex than RSVP and better suited to meeting long-term, Internet-scale QOS requirements.

Multi-Protocol Label Switching (MPLS). MPLS is another working party looking at how to improve network layer performance through switching of packet labels. In an MPLS network, the IP datagram header is replaced (at the access router) with a much shorter (13 byte) label, which (apart from speeding switching performance) can be used to identify the class of service requirement at the network ingress point so that intermediate nodes can prioritize traffic appropriately. MPLS also provides for routes to be chosen for a particular stream in response to the QOS required for that stream.

From a design perspective there are two different issues you need to consider when establishing how to provide the required QOS. First of all, clearly youll need to establish the capabilities of your router infrastructure and what, if any, software upgrades would be required to support appropriate QOS capabilities. Secondly, youll need to make sure that the IP telephony end systems can also interwork with the router QOS mechanisms. The simplest way for this to work is for the end systems to indicate the class of service they require by setting the TOS byte (either using the traditional settings or the new uses recommended by DiffServ) and having the routers automatically detect this setting and allocate resources accordingly. Alternatively, under RSVP, the application will need to be capable of making resource requests.