build voip network

7/29/2019 Build VOIP NEtwork

1/18

Building VOIP Networks Network World 2000 Page 1 of 18

Building Voice over IP Networks -- Network World, May 8, 2000

Regardless of whats in between, a phone conversation between two peoplerequires that each has both a microphone and a speaker. In the traditionaltelephone, 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 atelephone 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 aPC-attached headset. But they could equally well be provided by a traditionalanalog telephone attached to an IP telephony enabled PBX (a so-called iPBX) orby a telephone plugged into a data port that supports IP telephony directly (an IPtelephone). Regardless of whether its a PC or a traditional telephone attached toan 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 atelephone number or clicked on a name, signaling is required to determine thestatus 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, whenthe conversation starts, the analog signal produced by the microphone needs tobe 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 acceptablevoice quality. Finally, it may be necessary for the IP telephony stream to beconverted by a gateway to another format either for interoperation with adifferent IP based multimedia scheme or because you are placing a call to thetraditional public telephone network. The overall technology requirements of anIP 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 discussionsof IP telephony often seem to boil down to an H.323 vs. SIP argument. It isimportant to remember, however, that neither H.323 nor SIP alone make up acomplete set of IP telephony protocols they are just the competing standardsfor signaling. Until recently there was a similar situation with gateway controlprotocols, with competition between IPDC (IP Device Control) and SGCP (SimpleGateway Control Protocol). Now, however, the industry appears to have agreed


2/18


on a third standard, called MGCP (Media Gateway Control Protocol), whichcombines the advantages of its two predecessors. For details on whichstandards relate to signaling, encoding, transport and gateway control, see theprotocol tables below.

Signaling

H.323 ProtocolSuite

H.323 V2 ITU Packet-based multimedia communications systems

H.225.0 ITU Call signaling protocols and media streampacketization for packet-based multimedia (includesQ.931 and RAS)

H.225.0

Annex G

ITU Gatekeeper to gatekeeper (inter-domain)

communicationsH.245 ITU Control protocol for multimedia communications

H.235 ITU Security and encryption for H-series multimediaterminals

H.450.x ITU Supplementary services for multimedia (call transfer,diversion, hold, park and pickup, call waiting, messagewaiting)

H.323 AnnexD

ITU Real-time fax using T.38

H.323 AnnexE

ITU Call connection over UDP

H.323 AnnexF

ITU Single-use device

T.38 ITU Procedures for real-time group 3 facsimilecommunications over IP networks

T.120 series ITU Data protocols for multimedia conferencing

SIP Protocol Suite

SIP (RFC2543)

IETF Session initiation protocol

SDP (RFC2327)

IETF Session description protocol

SAP(InternetDraft)

IETF Session announcement protocol


3/18


Codec Method of Encoding

Codec Differences

Pulse Code Modulation (PCM) Variants:

G.711 ITU Pulse Code Modulation (PCM) 48 to64kbps

G.722 ITU Sub-band ADPCM

G.726 ITU Adaptive Differential PCM (ADPCM) 16to 40kpbs

G.727 ITU AEDPCM

Codebook Excited Linear Prediction (CELP) Variants:

G.723.1 ITU MPE/ACELP

H.728 ITU LD-CELP

G.729 ITU CS-ACELP

G.729 ITU CS-ACELP

Transport Protocols

Transport

RTP (RFC1889)

IETF RTP: Real-time transport protocol

RTCP (RFC1889)

IETF RTCP: Real-time transport control protocol

RTSP (RFC2324)

IETF RTSP: Real-time streaming protocol

MGCP IETF Media gateway control protocol (Internet Draft)

MEGACO IETF MEGACO protocol (Internet Draft)

SGCP IETF Simple gateway control protocol (Internet Draft)

IPDC IETF IP device control (Internet Draft)

H.GCP ITU Proposed recommendations for gateway controlprotocol


4/18


H.323 vs. SIP

Given that two standards currently compete for the dominance of IP telephonysignaling, how do you decide which is more appropriate? The good news is thatthe 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) hasaddressed some key performance issues (call setup delay and statelessprocessing to support UDP), which were initially key SIP advantages.

Most importantly, each suite supports (pretty much equally well) the majority ofrequired end-user functions (including call setup and tear-down, call holding, calltransfer, call forwarding, call waiting, conferencing and click-for-dial). The onlyfunctional differences are message waiting indication (which only H.323supports), third-party control (e.g., a secretary placing a call on behalf of amanager, which only SIP supports, and certain conferencing functions. While therange of functions supported is similar, the H.323 v3 suite (by means of H.245)

provides a somewhat more robust mechanism for "capabilities exchange" thandoes SIP, which relies on the less descriptive Session Description Protocol(SDP). "Capabilities Exchange" is the process by which it is determined whethera particular feature is supported by both participating entities.

However, functionality is by no means the only consideration in the H.323 vs. SIPdebate. Equally important are Quality of Service (QOS), Scalability/Flexibility andInteroperability. Indeed, whereas the suites are relatively similar in terms offunctionality, they differ quite substantially in these areas, as seen in the followingtable. Because SIP is a significantly less complex protocol, it is argued that itshould scale better. This is an important consideration given that the Internet

may well come to support 500 million IP telephony devices. However, it is myopinion that this potential advantage doesnt sufficiently compensate for theprotocols current weaknesses in terms of QOS and interoperability. Mostimportantly, SIP doesnt provide for redundancy (making it unsuitable for carrierapplications), doesnt support the emerging Differentiated Services/PolicyManagement approach to QOS and has a limited interoperability testing trackrecord (largely because the protocol is new, having only been ratified in February1999).


5/18


Similar H.323 v3 Better SIP Better

Quality of Service andManagement

Call setup delay,packet loss

recovery, lack ofresourcereservationcapability

Fault tolerance(H.323 supports

redundantgatekeepers andendpoints),

Admission Control(SIP relies on otherprotocols forbandwidth mgmt,call mgmt andbandwidth control),Policy Control(H.323 has limitedDiffServ support vs.none for SIP)

Loop detection (SIP'salgorithm using "via header"

somewhat superior toH.323's PathValue approach)

Scalability andFlexibility

Statelessprocessing, UDPSupport, Inter-servercommunicationsfor endpointlocation

Location ofendpoints in otheradministrativedomains (SIP doesnot define amethod, butsuggests use ofDNS)

Complexity (SIP is lesscomplex), Extensibility (SIP'suse of hierarchical featurenames and error codeswhich can be IANAregistered is more flexiblethan H.323's vendor-specificsingle extension field"NonStandardParam"), Easeof customization (SIP lesscomplex, and offers text-based protocol encoding)

Interoperability PSTN Signaling

Interoperability (SIPInternet Draft only,H.323 uses Q.931-like messages,which are SS7compatible, thoughonly a subset ofISUP messages),Inter-vendorinteroperability(H.323 moremature, greaterinteroperability track

record, IMTC iNOW!profile to assistimplementation)


6/18


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

From a practical perspective, if you go out and research the IP telephonyproducts 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 enterprisesolutions as opposed to carrier solutions (where H.323 support is morewidespread).

In practice, what is likely to happen is that major vendors will support bothapproaches until it becomes clear either that one standard is going to die, or thatthe two are going to merge. That said, it is certainly worthwhile clarifying vendorsintended strategies with respect to signaling. If you are particularly concernedwith high availability and interoperability, then a SIP-oriented solution might betoo bleeding edge right now. Otherwise, both approaches pretty much deliver thesame in terms of functionality. The only area where there is a noticeable

difference is in the implementation of conferencing capabilities. Because SIP canbe used to invite multiple parties to join a call, simple conference calls can beinitiated without the requirement for a conferencing server (whereas H.323 doesrequire one). In practice however, whether or not this is a constraint depends onthe full vendor solution and approach rather than just the protocols that happento 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 callsbetween offices within the corporate network. Such an approach requireslittle or no change to existing PBX, cabling and handset infrastructures, isrelatively easy to implement and has no PSTN integration issues toconsider.

Total IP telephony. Throw out your existing voice systems, replace thephone handsets with IP telephones that plug straight into 10BASE-T ports

and implement LAN servers to provide (most of) the features your PBXonce provided. Not for the faint of heart, but absolutely feasible withtodays technology.

IP-enabled PBXs. This is the intermediate route dont change theexisting cabling or handset infrastructure, but upgrade the PBXs so thatthe organizations core telephony systems speak IP telephony protocols.That means that PBX users can speak with other IP telephony users (e.g.,


7/18


PC-based NetMeeting users) as they become more prevalent but italso means that your PBXs will rely on IP telephony gateways tocommunicate with the outside world (unless the PBXs themselves providesuch functionality). Two ways to do this either upgrade your existingPBXs or replace them with purpose built IP-PBXs.

The simplest of these strategies from an implementation perspective is probablythe first, so well begin with that approach and then explore the additionalrequirements 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 thealternative 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 namesuggests, is to connect phone calls coming in on trunk lines from the PublicSwitched Telephone Network (PSTN) to the particular extension associated withthe called party (and similarly, in reverse for outbound calls). However, PBXs arenot limited to simply switching calls between the PSTN and the extensions they are equally capable of switching calls to extensions on other connected


8/18


PBXs. In the good old days, these interconnections took the form of leasedanalog voice circuits if there were likely to be 10 conversations occurringbetween two offices at any one time, that meant you needed 10 separate leasedlines. 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, theyare channels allocated on a Time Division Multiplexing (TDM) backbone, whichdivides up bandwidth between voice, various data streams (probably includingIP) and perhaps video conferencing. The problem with both dedicated voice tielines and multiservice TDM backbones is that bandwidth must be permanentlyallocated (and paid for) for each voice circuit despite the fact that the voicecircuits are not used all the time. A better solution is to split the traffic intopackets (or "cells" or "frames") so that all the traffic types can be interwoven inthe 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 achievethis 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 andtransport to an IP format. I call such units VoIP relays (theyre sometimes alsoreferred to as VoIP gateways, but the gateway term is more commonly used forPSTN interconnection, as well discuss later). The VoIP relay connects directly toa router for transport over the IP network, as shown in the following diagram.


9/18


Examples of stand-alone products that can be used in this way include NortelsV/IP and Nokias IP Relay. [Incidentally, as we move through this chapter Illmention 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 differentareas). However, it is emphasized that there are numerous vendors involved inIP 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 aseparate unit you might instead want to implement the functionality in the PBXor in the router itself. For example, both Lucents Definity PBXs and NortelsMagellan offer IP-trunking, while various Cisco routers can provide direct PBXinterfaces (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 functionalperspective the VoIP relay will relay sufficient signaling information to support thefeatures in use on the PBXs. Secondly, youll need to consider whetherstandards are important in your situation while some of the products claimH.323 compliance, many still use proprietary schemes. This may not matter ifyour network is relatively small and you feel comfortable that the vendor iscommitted to standards, but give it consideration. Remember also that H.323comes in three versions Ive not come across any products that currentlysupport H.323 v3 (or SIP), but remember to check whether the H.323 support isv1 or v2. Thirdly, and perhaps most importantly, youll need to figure out howyoure 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 theIP network and your VoIP relays ability to work with those QOS mechanisms.Since encoding and QOS requirements are substantial practical considerations inall IP telephony implementations, well discuss these issues at the end of thischapter.


10/18


A full-blown IP telephony solution

Toll bypass is a straightforward, cost-saving solution that can be implementedeasily today. But what will a complete IP telephony solution look like? Thefollowing 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 IPtelephones (i.e., telephones that rely on client software on PCs or stand-alone IPtelephones). When these devices communicate with one another they do sodirectly, via an IP connection (using RTP). Another component, the gateway, isrequired 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 callsetup functions as well as the advanced features users have come to expectfrom 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, ora headset, plugged into a PC. The problem is that people like telephones. Thatdilemma can be solved in either of two ways: provide a telephone that speaks IPdirectly, or attach a handset to a PC. Examples of the former include Ciscos IPTelephones, Nokias IPCourier range, Siemens HiNet range and LucentsDefintity Hardphone. Each of these ranges includes full-featured handsets that


11/18


seem pretty much the same as regular corporate handsets, except that they havea 10BASE-T port instead of plugging into a phone jack. The only other differencethat users will notice is that these telephones currently need to be plugged into apower jack; however, thats likely to change as we see switches introduced thatprovide 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 becomesquite compelling one cabling system that users can plug any device into.

The disadvantage is also pretty obvious: More cat-5 jacks will be required. Oneway to avoid this, while potentially providing tighter integration with PCapplications, is to use a software-based IP telephony solution in conjunction witha 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 (likeNokias SerialSet) or you can plug a traditional analog phone into a PC card orexternal adapter. And of course there may be some corporate users (likecallcenter operators) for whom the PC-attached headset really is suitable.

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

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

If looking at stand-alone hardware IP telephones, make sure thatthe product chosen doesnt limit your ability to more tightly integrate

with the desktop (e.g., through pop-up windows based on customerdatabase 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 IPtelephony calls. Sounds pretty simple, right? Unfortunately, it's not. The PublicSwitched Telephone Network (PSTN) in the United States (and in much of thedeveloped world) really consists of two logically separate networks one fortransporting the actual voice conversations themselves, the other for transportingsignaling information using the SS7 protocol.


12/18


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

Central Office.Also called an End Office or Local Exchange. This iswhere 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 aLATA).

A Central Office Telephone Switch has not only voice trunks connecting it toother Central Office or Tandem Switches, but also SS7 Signaling Trunks whichconnect to Signal Transfer Points (STPs) -- the message switches that route SS7signaling information. The separation of signaling from voice transport speedsthe setup and teardown of voice calls and smoothes the operation of the networkduring 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 IntelligentNetwork (AIN) services. SCPs are essentially purpose-specific, high-performance computer systems where advanced telephony functions areimplemented in software. This enables the provision of services like 800numbers, call-forwarding and follow-me. Another important function of the SCP isto enable local number portability. In the United States, and in other countries, anear-term regulatory requirement is that local telephone numbers will be portablefrom 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 bepermanently associated with a particular physical port on a switch rather, it willbe necessary for an SCP lookup to be performed to determine where a particularcall should be routed.

An "IP Telephony to PSTN Gateway" can operate without participating in SS7 byusing in-band signaling on voice trunks. This enables calls to be placed from anIP telephony end-device to a traditional PSTN telephone number. However, if IPtelephony users are to have access to Intelligent Network or Advanced IntelligentNetwork services, or to inter-operate with a ported number, another gateway isrequired: the SS7 to IP Telephony Gateway. The SS7 to IP Telephony Gatewayenables IP telephony users to participate in IN and AIN services some ofwhich are pretty important (e.g., calls to an 800 number, a call-forwarded numberor a locally portable number). In practice, the voice and SS7 gateway functionsare usually combined in commercially available gateway products. Make surethat you understand your SS7 gateway requirements and that the gatewayproduct you select supports them.


13/18


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 performedby 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 performsthese 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 applicationcalled a gatekeeper. Any particular vendor solution will provide thesegatekeeper-like functions, and may also include support for additional featureslike voice messaging, voice conferencing and click-to-call in the same IPtelephony server offering. Each vendor has a specific IP telephony serveroffering, and youll simply need to go through the process of making sure thateach required feature is supported by a particular vendor. For a list of the kindsof features youll need to consider and a comparison of Lucent, Nortel and Ciscocheck this URL: http://img.cmpnet.com/nc/1012/graphics/f32.pdf.

A migration strategy

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

Rather than replace the cabling and handsets, just upgrade or replace the PBXso that it speaks IP telephony to the outside world (and makes each of theattached phones appear to the outside world like an IP telephony endpoint). Thesolution would look like that shown in the diagram below.
http://img.cmpnet.com/nc/1012/graphics/f32.pdfhttp://img.cmpnet.com/nc/1012/graphics/f32.pdfhttp://img.cmpnet.com/nc/1012/graphics/f32.pdf


14/18


First of all, check with your existing PBX vendor to determine whether a suitableupgrade is available. Both Lucent and Nortel will shortly be providing suchsupport 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 telephonyand direct PSTN connections (with intelligent routing between the two). Somemodels 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.


15/18


Encoding schemes

When you speak, you cause air molecules to vibrate thats how sound istransported. If you were to plot the displacement of air molecules versus time youwould 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 thiswaveform to an electrical signal. The electrical signal, if plotted against the sametime scale would look the same. This electrical signal is an analog signal atany one time, the signal may have any value between the top and bottom peakvalues (as opposed to a digital signal, which is generated using only two signallevels representing the binary digits zero and one). In order to transport thisanalog voice signal over a digital network it is necessary to convert the analogsignal 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 encodingand decoding is called a codec).

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


16/18


Sampling theory tells us that in order to reproduce the original signal from adigital sample we must sample at a rate at least 2.2 times the maximumfrequency represented in the underlying signal. Since the human voice is madeup of frequencies in the range 300Hz to a bit under 4,000Hz, we can use asampling 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 timesper 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 publictelephone networks. This sampling approach can be refined by doing someadditional processing. Adaptive Differential Pulse Code Modulation (ADPCM), forexample, predicts what the next value will be based on previous values thensends only the difference between the actual and predicted. Since the differenceis smaller than the signal, less bits are required for transport. PCM and ADPCMare 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 humanspeech. This is the approach used for Codebook Excited Linear Prediction(CELP) and its variants; prevalent examples include MPE/ACELP (ITU StandardG.723.1) and CS-ACELP (G.729).

So which encoding scheme should you go for? The standard by which telephonevoice quality is measured is so-called "toll quality," which in effect means thequality delivered by PCM (G.711), which is predominantly used in todays phonenetworks and is what you are used to when you use the public telephone networkin developed countries. The great thing about PCM is that the algorithm itself ispretty straightforward, so not too much processing power is required that

means high performance and relatively inexpensive encoding equipment. Thedownside of PCM is that it uses up a whole 64kbps for each voice circuit notso bad if youre a carrier with bandwidth to burn, but less optimal if youre acorporate customer getting heavily charged for that bandwidth. CELP makes abig difference in bandwidth requirements because the sampling frequency can bemuch lower this means that "near toll quality" can be achieved with 8kbps. Inorder to do that CELP does a lot more processing than PCM, which originallymeant substantially higher costs and lower throughput. All that said, 8kbps issimply 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 standardCELP implementations.

If youre working on calculating how much bandwidth youll need for a particularnumber of voice circuits youll also need to consider packet overhead. Rule ofthumb? Triple the bandwidth requirement. I know that sounds pretty extreme, butheres the rationale: Voice packets need to be kept relatively small to minimizedelay effects. If you assume the use of a G.729 codec, two samples of 10mseach will go into a single 20-byte packet. But the PPP/IP/UDP/RTP header is 49


17/18


bytes not a very efficient arrangement. There are header compressionschemes available (RFC 2508 for RTP compression and RFC 2393 forcompression of all headers except IP), but these are not widely implemented,and RFC 2508 wont operate across an IPSEC VPN. Unless youre implementingMPLS (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 sensitiveto even minor changes in an audio signal (interestingly, the eye is much lesssensitive to imperfect video). What this means is that if a signal is to bepacketized, the packets must arrive predictably with minimal delay (a specificQuality of Service or QOS). These requirements do not apply to data networking,which is pretty tolerant of variable network performance even heavilytransactional data applications wont be affected by the odd 500ms delay.

Unfortunately, IP was originally designed as a data networking protocol so untilrecently 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-servicecapabilities and with the adoption last year of 802.1Q VLAN tags, evenEthernet, 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 EthernetLANs are interconnected by Frame Relay, the 802.1Q tags will do littlegood since they wont be passed.

Type of Service (TOS). Part of every Ipv4 header is the TOS byte, whichincludes 3 bits, allocated to priority (therefore three levels, the same as801.Q) and another four bits used to define the type of service. For this totranslate into something resembling a QOS mechanism, two things needto happen. Firstly, your router network needs to have the functionality to

recognize TOS fields and provide different classes of service based onthem (either automatically or manually, using filters). Secondly, the TOSbits need to be set either by the IP end system (e.g., our VoIP relay) orby the access router detecting the traffic type and setting the TOS bits.


18/18


Resource Reservation Protocol (RSVP). The way that RSVP works isthat at the start of a session (or voice conversation) control packets arefirst sent through the network to reserve resources for the connection. Ifappropriate resources are not available (e.g., theres insufficientbandwidth 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 tollbypass scenario), but it is strategically unsuitable for a world in which alarge proportion of inter-business phone calls are placed via IP.

DiffServ. The Differentiated Services working group has refined the use ofthe TOS byte so that per-hop behaviors can be requested by a sender.This approach focuses on providing classes of service that the networkmakes available and which applications can choose to use, contrasted

with RSVP in which the application dictates its requirements. DiffServ isless complex than RSVP and better suited to meeting long-term, Internet-scale QOS requirements.

Multi-Protocol Label Switching (MPLS). MPLS is another working partylooking at how to improve network layer performance through switching ofpacket labels. In an MPLS network, the IP datagram header is replaced(at the access router) with a much shorter (13 byte) label, which (apartfrom speeding switching performance) can be used to identify the class of

service requirement at the network ingress point so that intermediatenodes can prioritize traffic appropriately. MPLS also provides for routes tobe chosen for a particular stream in response to the QOS required for thatstream.

From a design perspective there are two different issues you need to considerwhen establishing how to provide the required QOS. First of all, clearly youllneed 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 alsointerwork with the router QOS mechanisms. The simplest way for this to work isfor the end systems to indicate the class of service they require by setting theTOS byte (either using the traditional settings or the new uses recommended byDiffServ) and having the routers automatically detect this setting and allocateresources accordingly. Alternatively, under RSVP, the application will need to becapable of making resource requests.

Philip Carden is a managing analyst with no-8.capital and has contributed to two books

on Internet Security. He can be reached at [email protected].
mailto:[email protected]:[email protected]

build voip network

Documents