Voice over IP - cepis.org Naming and Addressing in Voice over IP Networks ... The distinction between voice and data communication has been a ... “ﬂat cost” schemes of the Internet

The European Online Magazine for the IT Professionalhttp://www.upgrade-cepis.org

Vol. II, No. 3, Jun. 2001

Voice over IP

1

UPGRADE is the European Online Magazine for the Information Technology Professional, published bimonthly athttp://www.upgrade-cepis.org/

PublisherUPGRADE is published on behalf of CEPIS (Council of European Professional Informatics Societies, http://www.cepis.org/) by Novática (http://www.ati.es/novatica/) and Informatik/Informatique (http://www.svifsi.ch/revue/)

Chief EditorsFrançois Louis Nicolet, Zurich <[email protected]>Rafael Fernández Calvo, Madrid <[email protected]>

Editorial BoardPeter Morrogh, CEPIS PresidentProf. Wolffried Stucky, CEPIS Vice PresidentFernando Sanjuán de la Rocha and Rafael Fernández Calvo, ATIProf. Carl August Zehnder and François Louis Nicolet, SVI/FSI

English Editors: Michael Hird, Alasdair MacLeod

Cover page designed by Antonio Crespo Foix, © ATI 2001

Layout: Pascale Schürmann

E-mail addresses for editorial correspondence:<[email protected]> and <[email protected]>

E-mail address for advertising correspondence:<[email protected]>

Copyright © Novática and Informatik/Informatique. All rights reserved. Abstracting is permitted with credit to the source. For copying, reprint, or republication permission, write to the editors.

The opinions expressed by the authors are their exclusive responsibility.

The European Online Magazine for the IT Professionalhttp://www.upgrade-cepis.org

Vol. II, No. 3, June 2001

Joint issue with NOVÁTICA and INFORMATIK/INFORMATIQUE

2 Introduction: The Revolution in Telephone Networks – David Fernández and Eberhard Zangger, Guest Editors

4 Parameters Affecting QoS in Voice over Packet Networks – Antonio Estepa, Rafael Estepa and Juan M. VozmedianoFactors that negatively affect speech quality in the increasingly popular area of voice over IP are packet network-related as well as terminal-related.

10 Signalling in Voice over IP Networks – José Ignacio Moreno, Ignacio Soto and David LarrabeitiVoice signalling protocols have evolved, keeping with the move from circuit to packet switched networks. Standardization bodies have provided solutions for carrying voice over packet networks while manufacturers are providing products in workgroup, enterprise, or operator portfolio.

18 Naming and Addressing in Voice over IP Networks – David Fernández, John Michael Walker, José A. G. Cabrera, Juan Carlos DueñasAll entities in a network must be uniquely identified to allow data to be directed to them. In IP networks there is a clear distinction between names and addresses.

24 Multimedia Services over the IP Multicast Network – Antonio F. Gómez-Skarmeta, Angel L. Mateo, Pedro M. RuizVoIP makes use of a variety of technologies. The development and experimentation of video conferencing applications over IP multicast networks have contributed to the maturation of these technologies.

29 Implementing Voice over IP – André J. Hes and Ronald van TeeffelenVoIP, integrated with data traffic, creates a foundation for new possibilities that can significantly reduce cost for voice calls. This, in turn, opens up numerous possibilities for offering value-added services in this new integrated space.

33 Voice over IP Virtual Private Networking – Olivier HersentThe most crucial feature of a VoIP Virtual Private Network is the ability to connect many corporate sites to a single network while preserving a virtual isolation of each group that communicates on the shared infrastructure.

37 VoIP in Public Networks: Issues, Challenges and Approaches – Francisco González VidalThe basic problems found for conveying voice in a public environment are related to the quality of service the subscribers are currently used to.

44 Voice Communication over the Data Network Convergence of Services by LAN Telephony – Robert BertelsToday, voice communication can be carried out on a local data network by means of the Internet Protocol. As a result, in new buildings, a telephone network as such is no longer necessary.

47 Glossary of Acronyms and Technical Terms

Voice over IPGuest Editors: David Fernández Cambronero and Eberhard Zangger

Coming issue: “Present and Future of the Informatics Profession”

Voice over IP

2 UPGRADE Vol. II, No. 3, June 2001 © Novática and Informatik/Informatique

Introduction

The Revolution in Telephone Networks

David Fernández and Eberhard Zangger

This monograph is dedicated to an emergent technology inthe world of telecommunications: Voice over IP (VoIP). Itsorigin goes back many years to the first voice transmissionexperiments with packet networks. Its importance has recentlygrown tremendously, giving rise to great efforts and invest-ments that, no doubt, will revolutionize telephone networks andservices.

Traditionally, telephony and data services have been servedby separate networks with distinct technologies. Voice was car-ried over conventional switching networks specially suited tothe needs of voice traffic: a traffic of – initially analog, and laterdigital – signals characterized by a constant flow of informationover resources assigned to each call.

Data traffic, in contrast, is generally characterized by a lackof continuity. To predict or to model data traffic generated byapplications is tremendously difficult. This is why packet com-mutation technology, in which the information is chopped intoinformation units for transmission, and the packets transmittedwithout a priori reservation of resources, is far better suited tothis type of traffic.

The distinction between voice and data communication hasbeen a constant, for example, in corporate networks. Insidecompanies, there was not only a clear distinction between thetechnologies and the equipment used in the two networks, butthe responsibility for their management and maintenance wasalso undertaken by different personnel.

However, the development and maturation of voice transmis-sion over package networks technologies called for an integra-tion of voice traffic into data networks – called “convergence ofnetworks” or “convergence of voice and data”.

VoIP technologies use the networks’ bandwidth much moreefficiently, reducing in some cases the 64 kbits/s of telephonecalls over conventional networks by as much as an order ofmagnitude. Also housing a single network for both servicesreduces the costs of network management and operation.

This tendency is driven, however, by the applications: Theintegration of networks facilitates the creation of new applica-tions that integrate voice and data, such as unified mail (elec-tronic mail, fax, telephones, answering machines, etc.), whichoffers a single user interface and is accessible from any part ofthe network; or the integration of call centres into corporateWeb servers which facilitates better customer care; or video-conferencing, teleteaching applications etc. All are applica-tions that would be difficult to implement on separate networks.

In conventional telephone networks, intelligence resides inthe network, implemented by complex nodes and simple termi-

nals. The Internet, in contrast, is based on a model in whichintelligence resides in the peripheral systems and the networkdesign focuses on efficient transmission (this principle is called“end-to-end”). This model greatly facilitates the introductionof new services.

VoIP replaces a technology that was established more than ahundred years ago and has since reached a high level of matu-rity and reliability. Its introduction is hindered by a number offactors:• Quality of service (QoS). IP networks presently cannot

guarantee an acceptable level of quality of service for eachcall. Compared to switched networks which assign resourc-es to each call, the “best effort” service offered by IP isinadequate. In spite of all of the efforts invested, a widelyaccepted model that provides QoS on Internet telephony hasnot yet been found. In the meantime, VoIP is restricted toLAN IP.

• Reliability. The reliability of the present wire networks isvery high: 99.999%. The technologies used with the Internetfor VoIP are still far from reaching such a high percentage ofreliability.

• Security. The security in IP networks and the Internet isdeficient in many aspects. Denial of service and conversa-tion confidentiality violations are, among others, problemsthat must be solved before VoIP will be put to use on a largescale.

• Tariff. The operators of conventional telephony base theirincome on the accounting of calls made by each user. The“flat cost” schemes of the Internet are radically different. Itis necessary to harmonize both tariff schemes.

• Human Resources. The universality and quality of thepresent telephone service rest on a host of people trained incircuit switching technologies. The transition to VoIP willdemand more attention to the retraining of this personnel.

Henning Schulzrinne, one of the gurus in the domain of VoIP,once remarked that we presently have the opportunity to rede-sign a basic piece of our telecommunications infrastructure. Wemust not succumb to the temptation to reproduce the presenttelephone networks on a new infrastructure such as IP net-works. Instead, we must turn this new technology into an openplatform that allows us to experiment in order to create newservices, and finally, to create the applications of the future.

VoIP monographThe articles in this monograph can be classified into two

categories: those that describe the basic technologies used in

Voice over IP

© Novática and Informatik/Informatique UPGRADE Vol. II, No. 3, June 2001 3

VoIP, and those that describe experiences and problems with,reflections on or recommendations for the application of thistechnology.

Within the first group, Antonio Estepa, Rafael Estepa andJuan M. Vozmediano study the factors that influence the qualityof telephone communications over IP networks. They distin-guish the factors related to the networks from those attributableto the terminals. (“Parameters Affecting QoS in Voice overPacket Networks”).

José I. Moreno, Ignacio Soto and David Larrabeiti providein their article a panoramic view on how the signalling in wirenetworks has evolved. Starting with present systems based onthe well-known “Signalling System number 7” (SS7), theysummarize the characteristics of the main proposals for VoIP,they arrive at the future mobile networks of third generationcompletely based on IP (“Signalling in Voice over IP Net-works”).

David Fernández, John M. Walker, José A. G. Cabrera andJuan C. Dueñas offer a vision for how to harmonize the namingand addressing systems for VoIP, stressing the ENUM initia-tive, one of the most advanced in this aspect. (“Naming andAddressing in Voice over IP Networks”).

Finally, Antonio F. Gómez-Skarmeta, Angel L. Mateo andPedro M. Ruiz describe experiences with video conferencemultimedia applications on the Internet using IP multicastservice. They show how some of the solutions designed for thishave later been incorporated into VoIP. (“Multimedia servicesover the IP multicast network”)

In the second group of articles, André J. Hes and Ronald vanTeeffelen present a series of recommendations for deployingVoIP in a local IP network. (“Implementing Voice to over IP”).

Olivier Hersent describes the advantages of the integration ofVoIP technology into virtual private networks. (“Voice overVirtual IP Private Networking”)

Francisco González Vidal analyses in his article what thedevelopment of public networks in their evolution toward VoIPwill be. He presents a design project for new equipment thataims to facilitate this evolution. (“VoIP in Public Networks:Issues, Challenges and Approaches”)

Finally, Robert Bertels presents an interesting implementa-tion of LAN telephony as a step toward the convergence ofservices. (“Voice communication over the data network. Con-vergence of services by LAN Telephony”).

More information on VoIPBooks:

Olivier Hersent, David Gurle and Jean-Pierre Petit, “IP Telephony.Packet-based multimedia communications systems”, Addison-Wes-ley, 2000.

Bill Douskalis, “IP Telephony: The Integration of Robust VoIP Serv-ices”, Prentice-Hall, 2000.Articles:

Bjarne Munch. “IP Telephony Signalling”. Ericsson White Paper, Henning Shulzrinne, “Internet Telephony: A Second Chance”. First IP

Telephony Workshop, Berlin, April 2000.Jerome H. Saltzer, David P. Reed, and David D. Clark. End-to-End Ar-

guments in System Design. Included in Craig Partridge, editor Inno-vations in internetworking. Artech House, Norwood, MA, 1988,pages 195-206. ISBN 0-89006-337-0. Web sites:

Session Initiation Protocol (SIP). http://www.cs.columbia.edu/~hgs/sip/Real Time Protocol. http://www.cs.columbia.edu/~hgs/rtp/

Congresses:IP Telephony Workshop.

http://www.fokus.gmd.de/events/iptel2000/

The Guest Editors

Eberhard Zangger is Director of Corporate Communications atKPNQwest in Zurich. Already between 1984 and 1988, during hisdoctoral studies at Stanford University, Zangger was deeply engagedin the ongoing PC revolution. Now at KPNQwest, he is experiencingthe second revolution of the IT-industry – the one brought about bybroadband communications. He focuses on communicating the bene-fits of next generation information technology to general and expertaudiences. <[email protected]>

KPNQwest is one of Europe’s leading data and Internet communi-cations companies and provides a full range of business connectivity,networking and hosting services, and a range of hosted applications,consultancy and wholesale services based on the virtually unlimitedbandwidth of the companys fully-owned 20,000km EuroRings net-work. <http://www.kpnqwest.com>

David Fernández is an Associate Professor at the Telematic SytemsEngineering Department of the Universidad Politécnica de Madrid(DIT-UPM). He received a Ph.D. degree on Telematics Engineeringfrom that university in 1993. He has participated in several nationaland international research projects on formal description techniques,computer-supported cooperative work and advanced Internet proto-cols. His current research focuses on advanced Internet protocols.<[email protected]>

DIT-UPM is one of the largest and active university research groupson Telematics in Spain. Its research focuses on telematic services andnetworks, interactive multimedia applications, communication soft-ware engineering, between others. DIT-UPM has a long history of par-ticipation in national and international research projects. <http://www.dit.upm.es>

The English Editors

The articles of this issue have been edited by Richard Butchart,Arthur Cook, Kim Crawley, Nick Dunn, Hilary Green, Michael Hird,

Jim Holder, Alsdair MacLeod, Pat Moody, Adam David Moss,Phil Parkin.

Voice over IP


Parameters Affecting QoS in Voice over Packet Networks

Antonio Estepa, Rafael Estepa and Juan M. Vozmediano

This article presents an overview of the factors that negatively affect speech quality in the increasinglypopular area of voice over IP networks. These factors are packet network-related as well as terminal-related.Methods available to control speech quality within each of these areas are considered.

Keywords: QoS, terminals, VoIP

IntroductionTraditionally, voice and data networks have been sup-

ported by two separated infrastructures. The voice transportover IP (VoIP) offers service providers the advantage of inte-grating their networks into a single infrastructure. The substitu-tion of traditional voice networks by VoIP will depend on thecapability to offer to the end user a similar quality.

The speech communication quality is a subjective concept: itdepends on the level to which users’ expectations are met.Opinions on the quality of a call are based on several factorsrelated to the subjective perception of the call: overall quality,volume, intelligibility, speaker identification and naturalness.Physical factors such as loss, echo, delay and noise also affectthe perception of the speech [Rix et al. 00].

These factors are physically located in three points: termi-nals, the IP network and when needed, in interconnectiondevices between the IP and PTSN networks called gateways.This article addresses the call quality in a scenario with PC-based terminals where the voice packets traverse only an IPnetwork.

The paper is organised as follows. The next section describesthe main factors that impact the call quality. Later, qualityaspects are analysed within the IP network and terminals insections 3 and 4 respectively. Finally, section 5 concludes thepaper.

Impairments Affecting the Call QualityThere are several well-known impairments that have

traditionally been associated with speech quality in plain oldtelephone services (POTS). The main impairments come from[ETSI 96]:• Loudness Ratings. Loudness ratings are objective measures

of the loudness loss, i.e. a weighted, electro-acoustic lossbetween certain interfaces in the network. Usually expressedin dB, the Overall Loudness Rating (OLR) defines the soundpower loss between the acoustical signal at the microphoneand the listener’s ear.

• Echo. The echo is a copy of the original sound with a delaylong enough to be perceived as a second, undesired, sound.The negative impact of the echo will depend on both thepower and delay of this second sound. The talker can receive

the echo of his own voice (talker echo), while the listenercan receive multiple copies of the original sound differentlydelayed (listener echo). The main echo sources in VoIP arefocused in terminals and will be examined in the terminalsQoS section.

• Sidetone. The sidetone is the sound emanating from the sur-roundings and perceived by the listening ear at the sametime as the speech. It can be decomposed into ambient noise(listener sidetone) and the sound of the listener’s voice (talk-er sidetone). Note that only the listening ear is considered,as the brain hearing mechanism ignores the free ear. Talkerand listener sidetones are characterized in the form of Loud-ness Ratings.

• Delay. The delay is usually higher in packet switching net-works than in circuit networks, so it becomes an importantimpairment in the VoIP QoS. The packet network, terminals,and gateways will add delay to the communication. Theadditive effects of these delays will impose a limit on theachievable quality [Vleeschauwer et al. 00]. According to[ITU 96], delays longer than 400 ms will cause a lack ofinteractivity in conversations.Delays take place in:• IP Networks. Network delay in packet networks is due to

transmission delay in every link along the path to the des-tination and queuing delay in every router. Transmissiondelay depends on subnetwork technology, while queuingdelay depends on queuing policies at the routers.

1

2Juan M. Vozmediano received the M.S. and Ph.D. degrees in

telecommunications engineering from the Technical University ofMadrid, Spain, in 1989 and 1994 respectively. In 1993, he joinedthe Area of Telematic Engineering of the University of Seville, asAssociated Professor. <[email protected]>

Antonio Estepa-Alonso received the M.S. degree in telecom-munications engineering from the University of Seville, Spain, in1999. Since 2000, he has been working as Assistant Professor inthe Area of Telematic Engineering of the University of Seville.<[email protected]>

Rafael Estepa-Alonso received the M.S. degree in telecommu-nications engineering from the University of Seville, Spain, in1998. Since 1999, he has been working as Assistant Professor inthe Area of Telematic Engineering of the University of Seville.<[email protected]>

Voice over IP


• Terminals. Terminal delay will strongly depend on termi-nal type and processing power. Software-based terminalswill show higher delay than hardware-based ones.

• Special Equipment and Noise. Special equipment such aslow rate codecs is necessary to reduce network load, but thiswill also degrade speech quality by increasing quantizingnoise, distortion and delay.The noise sources come from the power sum of electriccircuit noise, and room noise. Noise sources at each end ofthe communication can be easily controlled by propertuning of the loudness ratings and listener sidetone.

The network basically affects the network delay (and jitter)and also the packet loss, but, as delay and packet loss in the net-work are correlated [Jiang/Schulzrine 99], it could be statedthat a network with a limited delay will also have a negligiblepacket loss. In the next section, the methods available to controlpacket loss and delay are examined.

Terminals contribute to increase the delay: they are also themain source of echo in the system. Sidetone, low rate codecs,and quantization distortion also impair the quality perceived bythe users.

QoS in the IP networkIP offers an unreliable, connectionless network-layer

service that is subject to packet loss, reordering and duplica-tion, all of which, together with queuing delay in router buffers,

will increase with network load. Because of the lack of any firmguarantees, the traditional IP delivery model is often refered toas “best-effort” and an additional higher layer end-to-end pro-tocols such as TCP is required to provide end-to-end reliability.As the traffic in the network increases, network servicedegrades gracefully causing problems for applications withreal-time requirements such as telephony.

QoS protocols provide additional capabilities to the networkallowing it to distinguish traffic with real-time requirementsfrom that which can tolerate delay, jitter and loss.

There are two strategies for QoS provisioning:• Resource Reservation (Integrated Services): network re-

sources are apportioned according to an application’s QoSrequest and subject to a bandwidth management policy.

• Prioritization (Differentiated Services): network traffic isclassified and apportioned network resources according tobandwidth management policy criteria. To enable QoS, net-work routers give preferential treatment to classificationsidentified as having more demanding requirements.

These strategies can be applied to individual applicationflows or to flow aggregates. A flow is defined as an individual,uni-directional data stream between two applications (senderand receiver) uniquely identified by a 5-tuple (transport proto-col, source address and port number and destination addressand port number). Two or more flows with something incommon are named aggregates.

3

SenderReceiver

Path

Path

PathPath

Path

Resv

Resv

Resv Resv

Resv

Resv

Path

Fig. 1: RSVP End-to-End

Voice over IP


Applications, network topology and policy dictate whichtype of QoS is most appropriate in a given situation. To accom-modate the need for these types of qualities there are differentprotocols and algorithms:• Reservation Protocol (RSVP): provides signalling to enable

Integrated Services. Typically used in a per-flow basis.• Differentiated services (DiffServ): provides a coarse and

simple way to categorize and manage network traffic (flow)aggregates.

• Multi Protocol Label Switching (MPLS): provides band-width management for aggregates via network routing con-trol according to labels in (encapsulating) packet headers.

These protocols are introduced in more detail in the next sub-sections.

3.1 Integrated Services (IntServ) and RSVPIntegrated Services enable the coexistence of best-effort

datagram delivery and enhanced quality of service deliveryclasses with regard to bandwidth, packet queuing delay andloss. The level of QoS provided by these enhanced classes isprogrammable on a per-flow basis according to requests fromthe end applications. These requests can be passed to therouters by network management or, more commonly, using areservation protocol such as RSVP.

IntServ basically offers two additional delivery services (aswell as the traditional best-effort) to end applications: • Guaranteed Service: this service guarantees bandwidth as

well as establishing a bound on end-to-end delay which isvery important for the VoIP applications.

• Controlled Load: this is equivalent to “best effort serviceunder unloaded conditions”. It is better than best-effort butcannot provide the strictly bounded service that guaranteesthe real-time requirements.

For traffic control, IntServ performs: admission control,packet classifying, packet scheduling and a setup protocol(RSVP) [IETF 94].

RSPV is a signalling protocol that provides reservation setupand control and enables the integrated services (IntServ) [IETF97].

RSVP-enabled senders characterize outgoing traffic in termsof the upper and lower bounds of bandwidth and jitter. RSVPsenders periodically transmit PATH messages that contain thistraffic specification (Tspec) information to the (unicast ormulticast receiver(s)) destination address. Each of any RSVP-enabled router along the downstream route establishes a “path-state” that includes information from the previous sourceaddress of the PATH message.

To make a resource reservation, receivers send a RESV(reservation request) message upstream. In addition to Tspec,the RESV message indicates the type of integrated servicerequired either Controlled Load or Guaranteed, indicating afilter specification (filter spec). VoIP packets could then indi-cate the bounds for the delay and jitter of the communication.

When an RSVP router along the upstream path receives theRESV message, it uses the admission control process toauthenticate the request and allocate the necessary resourcesfor that flow and sends the RESV upstream to the next router.Reservations in each router are “soft”, which implies the needfor periodical refreshing. For scalability reasons, this mecha-nism is not recommended for the core routers of the network.

When the last router receives the RESV and accepts therequest, it sends a confirmation back to the receiver.

Although RSVP traffic can traverse non-RSVP routers, thiscreates a weak-link in the chain where service falls-back tobest-effort. Another weakness of this protocol is that reserva-tions are receiver-based and it does not consider special mech-anisms for multicast receiver groups.

RSVP allows an application to request QoS with a high levelof granularity and with the best guarantees of service delivery.All these possibilities come at the price of complexity and over-head.

Classifier

Marker Meter

Conditioner

There are two types of classifiers:

• Behaviour aggregate (uses only DSCP value)

•Multi-field (MF):uses other header info (addresses, ports, etc..)

For BA, the DSCP is essentially an index into the PHB table

• Adds DSCP when none exists or as mapped from RSVP reservation

• Changes to map from DSCP to IP TOS, or back

•Changes DSCP as local policy dictates

Metering. Accumulates statistics, most likely in a SNMP MIB

Applies the PHB. Behaviours may include marking or metering but also queue selection and treat-ment policing in order to conform the traffic profile described in the SLA with destination or source. Could also autenticate the traffic for admission control.

Fig. 2: Differentiated Services architecture. This functionality is enabled in every DiffServ enabled router, although not all functions are used all the time.

Voice over IP


3.2 Differentiated Services (DiffServ)Differentiated Services provides a simple method of classify-

ing services offered to various applications. Service classes areidentified, packets are marked as belonging to a particularservice sent on its way and routers in the path examine headersto determine the treatment for the aggregate flow [IETF 98].

There are currently two standard per hop behaviours (PHBs)defined that effectively represent two service levels:• Expedited Forwarding (EF): it has a single codepoint (Diff-

serv value). EF minimizes delay, jitter and provides thehighest level of aggregate quality of service. Any traffic thatexceeds the traffic profile (which is defined by local policy)is discarded.

• Assured Forwarding (AF): it has four classes and three drop-precedences within each class (a total of twelve codepoints).Excess AF traffic is not delivered with as high probability asindicated in the traffic profile, which means that it may bedelayed, but not necessarily dropped.

As illustrated in figure 2, PHBs are applied to traffic by theconditioner at a network ingress point (network border entry)according to pre-determined policy criteria. The traffic may bemarked at that point, and routed according to the mark, thenunmarked at the network egress point.

Diffserv assumes the existence of a service level agreement(SLA) between adjacent networks. The SLA establishes thepolicy criteria, and defines the traffic profile. It is expected thatit will be policed and smoothed at egress points according tothe SLA, and any traffic above the upper bound at an ingresspoint, is not guaranteed (or may incur extra costs, according tothe SLA).

When applied, the protocol mechanism makes use of bits inthe “DS-byte”. The DS-byte denotes the service that the packetshould receive, and travels in the Type Of Service field in IPv4and in the Traffic Class Octet field in IPv6.

The simplicity of DiffServ to priorize traffic belies its flexi-bility and power. In contrast with RSVP, the amount of stateinformation depends on the number of classes, not the numberof flows. Sophisticated classification, authentication and,marking and shaping operations are only needed atboundaries and it is the sender who requests resources,not the receiver.

3.3 MPLSMulti-Protocol Label Switching (MPLS) works by

building engineered paths across the core of an IP net-work, then sending packets along those predefined paths.

When a packet enters the network, an edge route looksup the destination address of the packet and tags it with alabel that specifies the route and, optionally, class of serv-ice (CoS) attributes. The idea of MPLS is that by usingthe label to determine the next hop, routers have less workto do and can act like simple switches. As the labelledpacket moves across the network, each router uses thelabel to choose the destination, and optionally the CoS, ofthe packet, rather than looking up the destination addressfor each packet in a routing table. As the packet leaves thecore of the network, an edge router uses the destination

address to direct the packet to its final destination. Subsequentpackets in the data stream are quickly and automaticallylabelled in this way, as they can be anticipated.

Label switch routers (LSRs) build the path that a packet takesacross the core of the network, called a label switched path(LSP). Labels stored by each router define the path, which canfollow specific routes or constraints. LSRs at the core of thenetwork participate in routing topology exchanges and becometrue peers with the edge routers. The number of peers each edgerouter must communicate with is reduced to the immediatelyadjacent LSRs and routers.

Labels can be used to identify traffic that should receivespecial treatment to meet QoS requirements. By using sophis-ticated traffic management techniques for the LSPs defined bythe LSR, guaranteed service level agreements can be deliveredin an IP network environment.

A more complex aspect of MPLS involves the distributionand management of labels among MPLS routers, to ensure theyagree on the meaning of various labels [Rix et al. 00]. TheLabel Distribution Protocol (LDP) is specifically designed forthis purpose, but it is not the only possibility.

3.4 QoS ArchitecturesIn real-world use, it is unlikely that these protocols will be

used independently, and in fact they are designed for use withother QoS technologies to provide end-to-end QoS betweensenders and receivers.

IntServ/DiffServ: RSVP provisions resources for networktraffic, whereas Diffserv simply marks and prioritizes. RSVP ismore complex and demanding than DiffServ in terms of routerrequirements, so it can negatively affect the backbone routers.This is why DiffServ is preferred in the backbone.

DiffServ is a perfect complement to RSVP, as the combina-tion enables end-to-end QoS. End hosts may use RSVP requestwith high granularity (e.g. bandwidth, jitter threshold, delay…). Border routers at backbone ingress points can then mapthose RSVP reservations to a class of traffic indicated by a DS-

Fig. 3: MPLS label stack entry used to “encapsulate” IP header.

Link LayerMPLS SHIM

Network Layer Other Layers Headers and Data

Label value Exp S Time-to-Live (TTL)

20-bits: Label value used by LSR tolookup either next-hop, operation toperform, or outgoing data-link

Flag: “bottom of the stack”

Header Header

0 1 2... 20 21 22 23 24 25 26... 31

encapsulation.

Voice over IP


byte. At the backbone egress point, the RSVP provisioning maybe honoured again, to the final destination.

MPLS and IntServ/DiffServ: in coexistence with RSVP, it ispossible for MPLS to assign labels according to the RSVPflows.

MPLS and DiffServ are similar with respect to the qualitativeQoS support, so the mapping of DiffServ traffic to MPLS tagsis relatively simple. Supporting the DiffServ per-hop modelalso requires the allocation of a set of aggregate forwardingresources for each DiffServ forwarding class in each LSR.Additionally, an LSR may need to associate the packet with aparticular drop precedence.

QoS in terminalsAs seen above, QoS mechanisms allow network delay

and jitter to be controlled. However, terminals collect the restof the impairments of the calls.

Terminals can be classified into digital terminals and adapt-ers for traditional analog terminals. Digital terminals can beimplemented as software programs running on a PC (PC-basedterminals) or as hardware devices (cards, IP telephone sets).According to the audio system used, digital terminals can befurther classified into handset terminals, headset terminals andspeaker phone terminals.

4.1 EchoIn a scenario with two PC-based terminals, the main echo

source will be the acoustical path, as all the circuits are 4-wire.Echo sources will always be located at terminals unless thereare gateways to circuit switching networks.

A PC terminal with loudspeakers and a microphone will beseverely affected by acoustic echo, with a negligible echo loss.Stability problems may arise, as the speakers can amplify thesignal up to the saturation point. For digital terminals withhandsets or headsets, typical echo loss values are greater than45 dB [Janssen et al. 00], which assures a negligible echo. Forspeaker phone terminals, echo loss decreases to 15 dB (evenlower than in PTSN) so exhaustive acoustic echo control isnecessary in the terminal.

4.2 Delay in TerminalsWhichever the type, terminal delay will be due to the follow-

ing elements:• Codecs: they will add an algorithmic delay, depending on

the processing power and codec type; a prediction delay, dueto look-ahead algorithms; and a frame-filling delay due topacketing time. For instance, look-ahead delay for G.723.1codecs is 7.5 ms, and frame delay in G.723 is 30 ms.

• Protocol overhead: each protocol layer will add headers andprocessing time. Delay due to protocol overhead willdepend on the number of codec frames per IP packet. Withfew frames per IP packet, the overhead will be high. Withmany frames, the protocol overhead will be smaller but thefilling-up time will increase.

• Transmission delay: at the terminal, this delay will linearlyincrease with packet size.

• Buffering delays due to devices associated with the operat-ing system, such as buffers to handle the sound card, net-work interface and the used client application.

• Playout Buffer: upon receiving a frame, it will be placed intothe jitter buffer. The frame will be delayed an amount of timedepending on the jitter control needs. Packets arriving laterthan their scheduled playout time (jitter buffer delay includ-ed) will be discarded and it will result into an increment ofpacket loss. However a big buffer size will derive into agrowth of the overall delay.

4.3 Special Equipments: Low Rate CodecsAlmost any type of low rate codec [Hersent et al. 00] will

increase the distortion and quantizing noise when compared toG.711 coding. Their response can also be affected by voicesignal level, voice tone, room noise, transmission errors anddelay variations.

Moreover, the impact of packet loss will depend directly onthe codec. While a single lost packet may be unnoticed inG.711 coding, it may affect a rather long piece of speech in lowrate codecs. Effects of low rate codecs are usually perceived asvoice clipping [ITU 99].

4.4 Loudness Loss and SidetoneIn a typical sound card the sidetone path goes from the

microphone to the loudspeaker. As this path is via hardware,the delay of the sidetone signal is not longer than 2 ms, so it cannot be confused with an echo signal.

The microphone gain of the sound card can be set to optimizethe talker sidetone loss (STMR). Sidetone in PC-based termi-nals should be tuned to approximate STMR values of 15dB.

With regard to loudness loss in VoIP terminals, the gains canbe easily tuned by the users themselves (i.e. values tuned to alevel comfortable for users). Thus, theoretically, the optimalvalues for the end-to-end communication can be chosen. Opti-mal values will also minimize other effects such as the echo.

ConclusionsTraditional impairments sources in POTS have evolved in

the VoIP scenario. In VoIP calls, delay (and jitter) and acousticecho are the main factors determining the quality. Specialdevices such as low rate codecs should also be considered,specially when packet losses are occurring.

In this article, impairments and methods to attenuate theirinfluence have been examined. In section 3, quality aspectsreferred to the network have been addressed. Mixed architec-tures can provide the IP-network with extra capabilities thatmeet the requirements of real-time applications.

In the last section, QoS factors within terminals have beendescribed. Delay and acoustic echo have been examined inmore detail. The terminal delay can be kept under control, butecho must be controlled by local echo control procedures whennecessary.

The existence of QoS mechanisms to limit delay, packet lossand jitter in the network; and the possibility of controlling theecho at the terminals, can facilitate a fast deployment of VoIP.

4

5

Voice over IP


AcknowledgementsThe work leading to this article has been partly supported by

CICYT and the EU under contract number 1FD97-1003-C03-03.

References[ETSI 96]

ETSI ETR 250. Speech communication quality from mouth to earfor 3,1 kHz handset telephony across networks. (7/96).

[Hersent et al. 00]O. Hersent, D. Gurle, J.P. Petit. IP Telephony. Addison-Wesley.2000. ISBN 0201-61910-5.

[IEC]Multiprotocol label Switching (MPLS). The International Engi-neering Consortium.

[IETF 94]IETF RFC 1633. Integrated Services in the Internet Architecture:an Overview. (6-1994)

[IETF 97]IETF RFC 2205. Resource ReSerVation Protocol (RSVP) –Version 1 Functional Specification. (7-1997)

[IETF 98]IETF RFC 2475. An Architecture for Differentiated Services.(12-1998)

[ITU 99]ITU-T Recommendation G.113 Appendix I. Provisional PlanningValues for the Equipment Impairment Factor Ie. (09/99)

[ITU 96]ITU-T Recommendation G.114. One-Way Transmission Time.(02/96)

[Janssen et al. 00]J. Janssen, D. Vleeschauwer, G.Petit. Delay and DistortionBounds for Packetized Voice Calls of Traditional PSTN Quality.IPTEL 2000, (12–13/4/00) Berlin.

[Jiang/Schulzrine 99]W. Jiang, H. Schulzrine. QoS Measurements of Internet Real-Time multimedia Services. (12/99)

[Rix et al. 00]A. Rix, J. Beerends, M. Hollier, A. Hekstra. PESQ – the new ITUstandard for end-to-end speech quality assessment. AES 109thCONVENTION. LOS ANGELES, 2000 SEPTEMBER 22–25.

[Vleeschauwer et al. 00]D. Vleeschauwer, J.Janssen, G.H. Petit, F. Poppe. Limites decalidad para el transporte de paquetes de voz. Alcatel Telecom-munications Review. First quarter 2000.

Voice over IP


Signalling in Voice over IP Networks

José Ignacio Moreno, Ignacio Soto and David Larrabeiti

Voice signalling protocols have evolved, keeping with the prevalent move from circuit to packet switched net-works. Standardization bodies have provided solutions for carrying voice traffic over packet networks whilethe main manufacturers are already providing products in workgroup, enterprise, or operator portfolio. Thistrend will accrue in next years due to the evolution of UMTS mobile networks to an “all-IP” environment.In this paper we present the various architectures that are proposed for signalling in VoIP, mainly: H.323,SIP and MGCP. We also include a brief summary about signalling in classical telephone networks and, atthe end, we give some ideas about the proposed “all-IP” architectures in UMTS 3G mobile networks.

Signalling in telephone networksSignalling in classic telephone networks has evolved

dramatically during the 20th century, at the pace driven by thedevelopment of circuit switching technologies these networksare based on. The manual switches in use at the end of the 19thcentury were replaced by electro-mechanical switching in theadvent of the 20th century. This technological stage would lastuntil the 60s. Signalling was carried “in-band” (level changeand tones inside the telephone channel), and was interpreted byelectromechanical and electronic elements (relays and filters)on its way through the network. End-to-end physical connec-tivity quickly evolved to logical connectivity, and transmission,formerly analog FDM, moved to digital TDM structured as 64Kb/s channels.

In the middle 60s, transmission and switching integrated dig-ital network merged with the advent of digital exchanges andCPU-controlled switching (Stored Program Control concept).The 64 Kb/s synchronous channels are byte-by-byte switchedin space and in time. These exchanges are integrally controlledby processors that exchanges a signalling protocol with otherexchanges’ processors. The first signalling protocols used inthese systems were based on the status of a few bits in the TDMframe permanently attached to each voice channel, just as bina-ry representations of predecessor analog systems. The quantumleap in the history of telephone signalling was the applicationof computer networks technology to the design of the signal-ling system. Signals became messages exchanged by systemsover an independent packet switching network exclusively ded-icated to this task.

Although this type of operation is now almost ubiquitous inthe public telephone network, the last segment to be digitised –the subscriber loop – remains analog, with a small deploymentof fully digital accesses (ISDN). As a result, existing user-net-work signalling has evolved very little as compared to the rev-olution observed in the network-to-network architecture, thathas enabled the development of many additional services, mo-bile telephony, intelligent network services, broadband ISDNand internetworking with VoIP systems.

The network-to-network signalling system that has support-ed this evolution is the Signalling System number 7 (SS7). Thefirst CCITT standard is dated 1981 (“Yellow Book”), and hasbeen refined and enhanced in successive editions in 1985 (“RedBook”), in 1989 (“Blue Book”) [SS7 89] and following ITU-Tstandards.

SS7 is a complete protocol stack where signalling units aremessages issued by signalling applications transported in pack-ets. The essential features of this system are:• Bundles of signalling links and nodes build a packet switch-

ing network that is logically independent from the circuitswitching one, with a specific numbering plan and interna-tionally defined by ITU-T.

• SS7 is a common channel signalling system. A set of chan-nels between Signalling Points at exchanges (and SignallingTransfer Points) is dedicated to transport signalling to setup,release, supervise, etc. any voice or data 64 Kb/s channel. Inprevious signalling systems, a signalling associated to eachvoice circuit was transported over a transmission channelexclusively dedicated to it.

• SS7 is a 4-level protocol stack (Figure 1).

1

Jose Ignacio Moreno is Assistant Professor of Computer Net-working at Universidad Carlos III of Madrid. He obtained hisPh.D. at the Technical University of Madrid in 1996. From 1991,he has participated in several national and international researchprojects in the field of telematic services and networks.<[email protected]>

Ignacio Soto is Associate Professor of Computer Networkingat Universidad Carlos III of Madrid. He obtained his Ph.D. atVigo University and worked in different National and Europeanresearch projects. <[email protected]>

David Larrabeiti is Assistant Professor of Computer Network-ing at Universidad Carlos III of Madrid. He obtained his Ph.D. atthe Technical University of Madrid in 1996. From 1991, he hasparticipated in several European research projects related to thestudy and deployment of next generation networks and services.<[email protected]>

Voice over IP


Telephony signalling networks have been specifically de-signed to – and implicitly constrained to – operate and manage64 Kb/s circuit switched channels. There is now a strong ten-dency to move towards the use of packet switched networks. Itis interesting to observe how packet switching, introduced inlegacy networks to add flexibility and reliability to signalling inthe control plane of protocol stacks, is being extended today to

the user plane to carry packetized voice, merging again controland voice traffic.

Videoconference over packet Networks: H.323ITU-T was the first standardization body which created

an standard for transferring multimedia traffic over IP net-works. The standard H.323 version 1 appeared on 1996 andwas called “Visual telephony systems and terminal equipmentfor local area networks which provide a non-guaranteed qualityof service”. As a result, H.323 started the way to provide mul-timedia –and therefore voice transmission– over packet net-works. The main contribution of H.323 was the provision ofsignalling protocols for controlling all of these communica-tions, as media transmission architecture (voice, video, data)was adopted from previous works of IETF (mainly RTP/RTCP[RFC 1889] protocols tested on MBONE initiative).

After this initial version, on 1998 H.323v2 appeared with anew name, “Packet based multimedia communications sys-tems”, which have remained until now (version 4 was approvedon Nov. 2000 [ITU 00a]). H.323 is considered an umbrella ofstandards and consists of 4 types of functional elements (Figure2):

Figure 2: H.323 Architectural Model• H.323 Terminal, is an endpoint on the network which pro-

vides for real-time, two-way communications with anotherH.323 terminal, Gateway, or Multipoint Control Unit. Aterminal may provide speech only, speech and data, speechand video, or speech, data and video. The block functionalstructure of an H.323 terminal is shown in the Figure 3.

2TCAP ISUP TUP

SCCP

Signalling link

Signalling network

Signalling data link

Level 2

Level 1

Level 4:User Parts

MTP

OSI Layers 4–7

OSI Layer 3

OSI Layer 2

OSI Layer 1

Q.7xx (1988) X.200

Users of CCS 7

Level 3

Fig. 1: The SS7 protocol stack from the OSI perspective

SpeechV.70Terminal Terminal

H.324Terminal

H.310Terminal

H.321Terminal

H.320Terminal

SpeechTerminal

H.322Terminal

H.323Gatekeeper

H.323MCU

H.323Terminal

H.323Terminal

H.323Terminal

H.323Gateway

IPNetwork

QoSPSTN B-ISDN N-ISDN LAN

Fig. 2: H.323 Architectural Model

Voice over IP


• H.323 Gateway (GW), is an endpoint on the H.323 networkwhich provides for real time, two-way communicationsbetween H.323 Terminals and other ITU Terminals connect-ed, for example, to PSTN, ISDN, broadband ISDN (ATM),or QoS enhanced LANs. The purpose of the Gateway is toreflect the characteristics of a network endpoint to a SwitchCircuits Network (SCN) endpoint, and the reverse, in atransparent way. Functions like translation between trans-mission formats and between communications proceduresmust be provided.

• Multipoint Control Unit (MCU), is an endpoint on the net-work which provides the capability for three or more termi-nals and Gateways to participate in a multipoint conference.It may also connect two terminals in a point-to-point con-ference which may be later developed into a multipointconference. The MCU consists of two parts: a mandatoryMultipoint Controller (MC) which provides capability nego-tiation between all terminals to achieve common levels ofcommunications and optional Multipoint Processors (MP),which performs mixing or switching of audio, video anddata. This functionality could be integrated in an H.323terminal.

• Gatekeeper (GK), is an H.323 entity on thenetwork that provides call control services tothe H.323 endpoints. This element is the keyblock of the H.323 architecture for develop-ment of services and for the application of thistechnology in a medium-large environment. Inprinciple the GK is an optional block of thearchitecture that was decided in order to boostthe development of H.323 terminals withoutthe requirement of a complex element, butwithout this element the model is quite limit-ed. GK provides important services like:address translation and directory services,

admission and bandwidth control, callcontrol signalling or call authorization.

The complete protocol stack used in H.323is shown in the Figure 4, including media andsignalling transmission planes. Most of thecontrol channels use TCP as transport proto-col, but from version 3 on, UDP can also beused.

H.323 entities establish connections indifferent phases. Considering a normal sce-nario, an H.323 session between two entitiesin the same zone (that is, depending on thesame GK), will involve the following steps(Figure 5):1. Phase A: Call Setup. The Calling entity

uses RAS (Registration Admission andStatus) protocol to send an AdmissionRequest Message (ARQ) to the GK,requesting authorization to make a calland providing the identification of thecalled party. The GK can accept the call

by sending a confirmation (ACF message) or reject it (ARJmessage). When the call is accepted, the calling party estab-lishes a new TCP connection to the address provided by theGK in the ACF message. This connection uses H.225.0 pro-tocol to send a Setup Q.931 message. The Called party mustfirst connect to the GK and ask for permission to accept theconnection. When granted, the called party sends a Connectmessage, including the H.245 Control Channel TransportAddress for use in the next phase.

2. Phase B: Initial communication and capability exchange(H.245). In this phase, a new TCP connection is establishedbetween calling and called party to exchange ability andinformation about media channels using H.245 protocol.After this step, both parties have agreed on the media param-eters (codecs, samples per frame, etc.) and exchanged infor-mation about media channels (ports, etc.). This TCP connec-tion must remain until call termination phase and is used toopen or close media channels or modify their parameters.

3. Phase C: Establishment of audiovisual communication. Inthis step, both entities exchange multimedia informationdirectly using a RTP/UDP/IP for the media channels. They

Video I/O equip.

Audio I/O equip.

User Data Appl.T.120, etc.

System ControlUser Interface

Video CodecH.261, H.263

Audio CodecG.711, G.722, G.723,

G. 728, G.729

System Control

H.245 Control

Call ControlH.225.0 (“Q.931”)

RAS ControlH.225.0

ReceivePathdelay

H.225.0LocalArea

NetworkInterface

Fig. 3: H.323 Terminal structure

Control Data Audio Video A/V Ctrl Control

H.225.0 H.245 T.120G.7xx H.26x

RTCP

GatekeeperRegist

AdmissionStatus(RAS)RTP

TCP/UDP v3 UDP

IP

Fig 4: H.323 protocol stack

Voice over IP


also use RTCP messages as a control channel to get feed-back information about how their flows are being received.

4. Phase D: Call termination. H.323 entities must inform eachother about the call termination by sending an EndSession-Command message, which will produce the closing ofH.245 channel. Besides, they must send a DisengageRequest (DRQ) to the GK, by using RAS channel, in orderto inform the GK about the termination of the call. GK thenperforms actions such as release resources, provide billinginformation, etc.

The previous example shows that H.323 requires a lot of con-nections before terminals can exchange information. This isone of the main drawbacks of H.323v1 that was partially solvedin version 2 using two possible optional modes: Fast ConnectProcedure, which allow to open media channels during H.225.0phase; and H.245 tunnelling which uses the same channel fortransmitting H.225.0 and H.245 messages.

IETF’s proposal for VoIP: SIPThe Session Initiation Protocol (SIP) is an application

protocol, defined in RFC2543 [RFC 2543], that is being de-signed by the IETF MMUSIC (Multiparty Multimedia SessionControl) working group to enable users to participate in multi-media sessions, that is, to establish, modify and terminate mul-timedia sessions calls. MMUSIC working group [MMUSIC]focus on loosely coupled conferences as they exists today onthe MBONE. One of the main issues in this area is related withhow to inform users about forthcoming sessions, media

requirements, addresses, etc. There are two basic ways to locateand to participate in a multimedia session:• Advertisement. Sessions are advertised in various ways like

e-mail, web pages, newsgroups or a multicast advertise-ments via Sessions Announcement Protocol (SAP) like inthe MBONE.

• Invitation. Users are invited by others to participate by usingthe Session Initiation Protocol (SIP).

SIP has been proposed as a generic unicast and multicastinitiation protocol and also as an IP Telephony call set-up pro-tocol. It is based on a client-server protocol. SIP clients send aRequest Message for a service, and a server handles the request,answering with a Response Message. SIP terminals can bothgenerate and receive request as they are composed by a UserAgent Client (UAC) and a User Agent Server (UAS).

SIP terminals can establish voice calls directly withoutrequiring any other element. Figure 6 shows an example inwhich user1 calls user2 by sending an INVITE Request primi-tive containing user1 supported capabilities for receiving audioand a UDP port (port 12345 and mlaw codec). When user2receives INIVITE Request, he can establish a voice channel to12345 UDP port of user1 while he accepts the request by send-ing an OK Response message. In addition, user2 responseincludes its own media capabilities, which are used by user1 toestablish a voice channel (GSM codec at 54321 port in theexample) and send an ACK message to acknowledge user2’sresponse. In order to terminate the connection, any of the

3

110 GKR 210Aro (dest=210)

ACF (addr=X.X.X.X:Y)

Setup

ARQ (dest=110)

ACF (addr=Y.Y.Y.Y:X)

Connect

H.245 messages:

TermCapabilitySet, openlogicalchannel

RTP StreamRTP StreamRTCP Stream

H.245 messages:(Closelogicalchannel, EndSessionCommand)

DRQDRQ

DCFDCF

RAS&

Q.931

H.245

RAS

MediaInfo.Exch

Fig. 5: Generic Call Flow

Voice over IP


parties can send a BYE Message, which must be acknowledgedby an OK response.

SIP messages are encoded using HTTP/1.1 message syntax[RFC 2068], and the content of each message follows sessiondescription protocol (SDP) [RFC 2327], heavily used in thecontext of MBONE for distributing information aboutMBONE sessions.

In addition to SIP terminals which represent an IP telephonesor Gateways, SIP architecture is based on four different serversentities:• Proxy server, which forwards requests to its final destina-

tion. Like the Gatekeeper in H.323 model, it receivesrequests and sends them to the appropriate destination. Inthis case the Via field in the request/response message indi-cates the intermediate proxies which participate in therequest process. This avoids routing loops as well as permitsto force the responses to follow the same route back. Proxyservers do not need to relay the media except in case oftranscoding operations (they only need to relay controlinformation).

• Redirect Server, which, on the contrary to proxies, does notforward INVITE requests but responds to clients with aredirection message that informs about the next hop.

• Registrar server, that keeps track of the current location of auser by accepting registration request messages. Registrar

server are discovered by using well-known multicastaddresses or preconfigured unicast addresses.

• Call Agent, which is a service that handles incoming andoutgoing calls on behalf of a user. It is a mixture of a proxy,a registrar and a redirect server. A call agent can performtasks like:• Try to find a user by redirecting the call setup message to

the proper location or locations.• Implement call redirection rules such as call forwarding

on busy, call forward on no answer, etc.• Implement call filtering with origin/time-dependant

rules.• Record unsuccessful call attempts for future reference.• Perform any other call management task on behalf of the

user.The objects addressed by SIP are users at hosts or servers

identified by Uniform Resource Identifiers [RFC 2396]. TheSIP URI has the form: “user@host”, where “user” is a username or a telephone number and “host” is a domain name or anumeric network address.

Figure 7 shows a complete example of an interactionbetween SIP servers. David from company.es wants to [email protected]. So, he sends a request to his SIP server(sip.company.es), which acts as a proxy and relies the INVITErequest to the SIP server of upm.es (sip.upm.es). This server,

[email protected] [email protected]

INVITE sip:user2@ 172.16.1.2 SIP/2.0From:sip: user1@ 172.16.10.1C=IN IP4 172.16.10.1m=audio 12345 RTP/AVP 0

µlaw

Port 12345200 OKC=IN IP4 172.16.1.2m=audio 54321 RTP/AVP 3

GSM

ACK Port 54321

Exchange of Voice

BYE sip:user1@ 172.16.10.1 SIP/2.0From: sip: user2@ 172.16.1.2To: sip: user1@ 172.16.10.1Cseq: 2 BYE

200 OKFrom: sip: user1@ 172.16.10.1 SIP/2.0To: sip: user2@ 172.16.1.2Cseq: 2 BYE Fig 6:

Simple SIP call

Voice over IP


which acts as a redirect server, redirects the call by answeringwith a moved permanent pointing to the new [email protected]. SIP server at company.es progresses thecall contacting SIP server at uc3m.es. This server, which act asCall agent, relays the request to the usual location of jmorenoat host1.uc3m.es, but after a timeout without answer fromjmoreno, CANCELs the previous request and redirects the callto another usual location of this user in a different branch office(host2.uc3m.es). The user answers the call by sending a 200response which is sent back to the calling party.

One of the main advantages of SIP is its simplicity, whichtranslates into simpler implementations and shorter delays.While H.323v1 needs 4 or 5 round-trips to establish a connex-ion, SIP requires only one. As mentioned before, this keyaspect was corrected in H.323 from version 2 on.

VoIP in the core: MEGACO and MGCPH.323 and SIP were developed bearing in mind terminals

connected directly to IP networks. Both of them considerconnections between IP terminals or between IP terminals andconventional SCN terminals by means of Gateways. The goalof MEGACO architecture is, in addition, to establish connec-tions between SCN terminals through IP-based networks. Themain idea comes from operators, especially incomers: Whatabout deploying IP-based core infrastructure for new invest-

ments in the network while providing the same telephoneservice?

MEGACO solves this problem mainly by splitting Gatewaysinto three different entities: • Media Gateway Controller (MGC), which provides the

H.323 or SIP signalling and performs mapping betweenSCN signalling protocols and IP-based signalling protocols.

• Media Gateway (MC), which provides media mapping andtranscoding functions. It terminates SCN (PCM signaltypically) and packet media signals and performs addresstranslation, echo cancellation, playing announcements,receiving/sending DTMF digits, etc.

• Signalling Gateway (SG), which provides signalling media-tion between IP and SCN domains.

In a common scenario, these three elements are intended tobe physically separated, providing advantages like, concentra-tion of many MG in a few MGC controlled by a SG. Figure 1shows MEGACO architecture.

Media Gateway Control Protocol (MGCP) provides a simpleclient/server model to control Media Gateways. MGCP is theresult of previous protocols and has been proposed to differentstandardization groups like MEGACO IETF working group[RFC 2705] [RFC 30115] and ITU-T [ITU 00b]. MGCP usesSDP to exchange parameters to the gateway (IP, UDP port,media, etc.).

4

INVITE(1)[email protected]

200 OK (10)

ACK (11)

SIP Proxysip.compny.es

INVITE (2)[email protected]

SIP redirectsip.upm.es

301 moved permanently (3)([email protected])


Call Agentsip.uc3m.es



Call agent try to findjmoreno at their office andafter a time out try inanother location

200

OK (9

)AC

K (1

2)

CANCEL (6)

ACK (13)

ACK 14200 OK (8)

Fig. 7: Example of SIP servers

Voice over IP


Third Generation Mobile Networks: Towards and All-IP architecture

The Third Generation Partnership Project (3GPP) [3GPP00a] works in the standardization of a 3G mobile system basedon an evolved GSM core network and WCDMA radio access

technologies. This system is the UniversalMobile Telecommunication System(UMTS) that will be launched to the marketin the near future.

The first phase of the specification ofUMTS was finished at the beginning ofyear 2000 and was called Release 1999(R99). The 3GPP continues developingspecifications to set the path of the evolu-tion of UMTS systems. Release 4 andRelease 5 (with target dates as of December2001) are the following stages on this evo-lution. In this section we briefly describethe UMTS R99 architecture and theplanned evolution for this architecturetowards the inclusion of VoIP protocols in it[3GPP 00b].

As shown in Figure 9, the UMTS R99architecture [3GPP 00c is basically aGSM/GPRS network [Bettstetter et al. 99with a new access network named UTRAN(UMTS Terrestrial Radio Access Network).UTRAN is made of Radio Network Con-

trollers (RNC) and B Nodes, that can coexist with classicalGSM access network nodes (BTS and BSC). The architectureis clearly divided in two parts: Circuit Switched (CS) domain,used to carry voice traffic (made of MSC and GMSC nodes);and Packet Switched (PS) domain, used to transport data traffic

5

SG

MGC

MG

SS7, ISDN,Q.sig

GSTNT1/E1/PRI, OcxE&M, FXO, FXS

ISUP/IP, H.323, SIP

RTP/UDP/IPATM

SG

MGC

MG

SS7

GSTN

ISUP/IP

MGCP,H.248

Fig 8: Megaco Architecture

SGSN GGSN

MSC GMSC

BSC

AuCHLREIR

VLR

ExternalData

Networks

PSTN, ISDN

RNC

RNC

SGSN GGSN

MSC GMSC

ExternalData

Networks

PSTN, ISDN

VLR

MSC

UmBTS

Abis

BSC

BTS

UE

Uu Iubis

RNC

RNC

Iur

IuCS

IuPS

SGSN

Gb

Gs

MAP MAP MAP

MAP MAP

EIR HLR AuCH

GGSN

GMSC

PSTN,ISDN

ExternalData

Networks

IP

User data and signalling

Signalling

A

Abis

TDM / ISUP

TDM / ISUP

MAP

IP

Fig. 9: UMTS R99 Architecture

Voice over IP


(made of SGSN and GGSN nodes). Other nodes in the archi-tecture are used to keep information about users (VLR, HLR,EIR, AuC).

The main advantage of this design is that allows an easyevolution towards UMTS systems starting from existingGSM/GPRS networks. However, there is a clear tendency tounify both domains using an IP based core network, as Release4 and 5 point out. Even, IP could be used as the packet switch-ing technology in the access network – not only in the core – asdifferent European projects are proposing [MobyDick]. All thisproposals have been globally named the “all-IP architecture”[Bos/Leroy 01]. The reason behind this tendency is that packetswitching networks are cheaper, efficient and capable of carry-ing all the different classes of traffic. Besides, IP is a provedprotocol that allows a seamless intercommunication with Inter-net.

Release 4 and 5 of UMTS specifications define the evolutionsteps towards the “all-IP” architecture. Key points on this pathare:• The CS domain, which was originally designed to use “clas-

sical” TDM technologies, is evolved to make it independentof the transport technology, allowing it to work over IP andATM core networks. This evolution is highly based on theideas developed in MEGACO architecture. For example,MSC nodes are divided in two elements, the MSC serverresponsible for all signalling and control functions, and theMedia Gateway (MGW) responsible of data transport func-tions. It also uses other VoIP protocols like H.245 or RTP.

• A new subsystem, named “IP multimedia” (IM), is added tothe PS domain, in order to support IP multimedia servicesbased on SIP. The central entity in IM is the Call State Con-trol Function (CSCF), which is in charge of call set-up andtermination, routing of incoming calls, address handling,etc. It basically includes much of the functionality found onSIP servers (proxies, registrars, etc.). One of the main con-tributions of IM subsystem will be the use of “SIP phones”,that is, mobile terminals that directly support SIP signalling.

ConclusionsSignalling in telephone networks is clearly evolving from

circuit switch SS7 based networks to IP centric solutions. Arich set of standardized and proprietary solutions have ap-peared in recent years to carry voice traffic over IP networksand cope with problems like addressing, admission and callcontrol, internetworking with existing networks, etc. Work hasconcentrated over two main scenarios: voice terminals directlyconnected through IP networks, and operators that use IP back-bones to connect traditional switched circuit networks. The firstscenario can be solved by means of H.323 or SIP proposals,and the later by MEGACO or H.248.

Today, different operators and enterprises are using or begin-ning to use these technologies to carry voice traffic over packet

networks. The trend will be increased in the near future with theevolution of mobile UMTS networks towards an “all-IP” tech-nology, in which multimedia services will be deployed. As aresult, in the future voice traffic will be mainly carried over IPtechnology. However, the path towards “all-IP” networks willnot be easy, there is still a lot of problems to be solved, most ofthem related to interoperability with existing networks, and itwill take a long time, investment in traditional networks has tobe recovered.

7. References[SS7 89]

Specifications of Signalling System Nº 7. CCITT Blue Book,fascicle VI.7, recommendations Q.701-Q.716, Q.721-Q.766,Q.771-Q.795. ITU, 1989.

[RFC 1889]RFC 1889. H. Shulzrinne, S. Castner, R. Frederick, V. Jacobson.RTP: A transport protocol for real time protocol.

[ITU 00a] ITU-T Recommendation H.323: “Packet-based MultimediaCommunications Systems”, November 2000

[RFC 2543] RFC 2543. M. Handley, H. Shulzrinne, E. Schooler, E. Rosen-berg. SIP: Session Initiation Protocol.

[MMUSIC] MMUSIC web site. http://www.ietf.org/mmusic

[RFC 2068] RFC 2068. R. Fielding and others. Hypertext Transfer Protocol -– HTTP/1.1

[RFC 2327] RFC 2327. 2327 M. Handley, V. Jacobson. SDP: SessionDescription Protocol.

[RFC 2396] RFC 2396. T. Berners-Lee, R. Fielding, Uniform Resource Iden-tifiers (URI): generic syntax.

[RFC 2705] RFC 2705. M. Arango et al., “Media Gateway Control Protocol(MGCP)”.

[RFC 30115] RFC 3015. F. Cuervo, N. Greene, A. Rayhan et al., “Megaco Pro-tocol Version 1.0”

[ITU 00b] ITU-T Recommendation H.248: “Gateway Control Protocol”,June 2000

[3GPP 00a] 3GPP web site: http://www.3gpp.org.

[3GPP 00b] 3GPP Technical Specification TS 23.002, v5.0.0: Network Archi-tecture (Release 5). October, 2000.

[3GPP 00c3GPP Technical Specification TS 23.002, v3.3.0: Network Archi-tecture (Release 1999). March, 2000.

[Bettstetter et al. 99C. Bettstetter, H.-J. Vögel, J. Eberspächer; GSM Phase 2+, Gen-eral Packet Radio Service GPRS: Architecture, Protocols, and AirInterface; IEEE Communications Surveys Vol. 2, No. 3, 1999.

[MobyDick] MobyDick Project. http://www-int.berkom.de/mobydick

[Bos/Leroy 01] Lieve Bos, Suresh Leroy; Toward an All-IP-Based UMTS SystemArchitecture; IEEE Network, Vol. 15, No. 1; 2001.

6

Voice over IP


Naming and Addressing in Voice over IP Networks

David Fernández, John Michael Walker, José A. G. Cabrera, Juan Carlos Dueñas

This paper describes how naming and addressing is being organized in Voice over IP technologies andscenarios. After describing naming and addressing schemes used in different protocols, we concentrate onspecific problems found in complex VoIP scenarios. Later, we present the ENUM proposal to populate E.164numbers into the Internet DNS system, as a solution to manage the resolution between names and addresses.Finally, we briefly analyse the role of administrations as regulators of the ENUM technology.

Keywords: ENUM, VoIP, E.164, DNS, Naming, Addressing

IntroductionNaming and addressing is an important function of

communication networks. All entities in a network must beuniquely identified to allow data to be directed to them. Intoday’s networks there is a clear distinction between Namesand Addresses:• A Name uniquely identifies an end-user or any other entity

(e.g., an application) that can be communicated to via thenetwork. Names are typically designed to be used bypersons and they are composed of a combination of symbols(characters or numbers) organized in a way that can beeasily remembered (e.g. hierarchical names). Usually theydo not indicate the network or location of the named entity.

• An Address is a string or combination of digits and symbolsthat identifies the specific termination points of a connectionor session and is used for routing. An address specifies thelocation of the entity in terms of network structure. It typi-cally includes the identity of the network it is connected toand some information about the location within that net-work.

Naming and addressing takes place at different layers incommunications architectures. For example, a typical IP hostconnected to a LAN has a subnetwork address (MAC), an IPaddress, an IP name associated with that address and severalnames and addresses used for the different applications andusers using it. There are complex relationships between allthese names and addresses and resolution functions have to beused, either locally or by means of external directories, to asso-ciate names with addresses, names with other names, or evenaddresses with names.

This paper deals with how naming and addressing is organ-ized in VoIP proposals. It is organized as follows: first, wepresent the naming and addressing schemes found in commoncomputer networks and applications. Then we discuss the needfor resolution capabilities as a way to cope with heterogeneousnetwork scenarios and we present DNS and ENUM as a centralproposal to be used in VoIP scenarios. Later, we give someideas about how portability can be achieved inside ENUM.

Finally, some thoughts about the role of administrations inENUM are outlined before coming to the conclusions.

Naming and Addressing schemesTraditionally, telephone networks have not made a

distinction between addresses and names. They have usednumbers, based on the ITU-T E.164 recommendation [ITU97], as addresses to access terminals. Assignation of E.164numbers is made hierarchically: ITU-T assigns each country aunique country code (CC), and the naming authority in eachcountry is in charge of delegating the rest of the numbers andassigning codes to geographic regions or different operators.

Typically, E.164 numbers have been related precisely to net-work architecture. In this context, they were indistinguishably

12

David Fernández is an Assistant Professor at the Departmentof Telematics Engineering of Universidad Politécnica de Madrid,since 1995. He received a Ph.D. degree on Telematics Engineer-ing from that university in 1993. His current research focuses onadvanced Internet protocols. <[email protected]>

John Michael Walker works as a Systems Engineer for GSMand UMTS at Ericsson. He is a member of the Numbering, Nam-ing and Addressing (NNA) team in the System Management forThird Generation Data Bases department at Ericsson (R&D) inMadrid. He holds a Telecommunication Engineering degree fromUniversidad Politécnica de Madrid. <[email protected]>

José Angel García Cabrera works at the Comisión del Merca-do de las Telecomunicaciones as Deputy Director of the TechnicalDepartment since 1997. He is member of the ECTRA ProjectTeam on Numbering since 1996, member of the Cuerpo Superiorde Sistemas y Tecnologías de la Información de la Administracióndel Estado since 1995. He received a B.Sc. degree in Telecommu-nications Engineering from Universidad del País Vasco in 1991.<[email protected]>

Juan Carlos Dueñas is an Assistant Professor at theDepartment of Telematics Engineering of Universidad Politécni-ca de Madrid, since 1998. He holds a doctorate degree onTelematics from the same university. His current research is onsoftware technology for telecommunication systems.<[email protected]>

Voice over IP


used as names and addresses. But the liberalisation that hassignificantly increased the number of operators, and the imple-mentation of new functionalities like number portability, havechanged this fact. Nowadays, there is a clear distinctionbetween names, used by customers to make calls, and address-es (or routing numbers), used by the network to route calls.However, both of them are still based on the E.164 specifica-tion. As we will mention in section 4, the mapping betweennames and addresses is normally done using a database.

On the other hand, in IP networks there is a clear distinctionbetween names and addresses. Names take the well knownhierarchical form of domain names separated by dots, e.g.greco.dit.upm.es. Addresses are 32 bits long (or 128 bits in the caseof the new version of the IP protocol, IPv6) and identify an in-terface of a host connected to an IP network (multihomed hostsor routers have as many addresses as they have interfaces). Theassociation between names and addresses is at IP level and isresolved using the Domain Name System (DNS) application,which is a world wide distributed directory.

Taking a look at naming and addressing at the applicationlayer, we see different schemes. Basic applications like telnet(remote login) or ftp (file transfers) directly use IP names,which are translated to IP addresses by the DNS. As these kindof applications are basically end-to-end (with no intermediatenodes) and sessions are normally established with machines(and not with users), the solution is quite simple.

Electronic mail uses a more elaborated scheme. E-mailnames have the form “user@host”, where “host” is a domainname, which is translated to the address or addresses of thehosts that provide e-mail services to the user being namedusing the DNS (and the MX records stored in it).

WWW naming is based on the well known UniformResource Locator (URL) names. URLs, which have beengeneralised and named Uniform Resource Identifiers (URI)[Berners-Lee et al. 98], are becoming the standard way ofnaming resources on the Internet.

That is the case, for example, of SIP [Hersent et al. 00], oneof the main VoIP signalling proposals. SIP uses SIP-URLs toidentify “users at hosts”. They take a form similar to mailtoURLs (e.g., mailto:user@domain), for example:• sip:[email protected], which is the simplest form of SIP-URL

and identifies a user (david) in a domain (dit.upm.es),• sip:david:[email protected], which is the same as the previous

example but includes a password,• sip:+1-212-555-1212:[email protected];user=phone, which identifies

a telephone number which is accessible through a gatewaylocated at the domain gateway.com (1234 specifies a password).

There are also other naming schemes based on URL formatsbeing used in VoIP. The most common one is the tel-URLscheme [Vaha-Sipila 00], that allows the specification of E.164numbers inside a URL (e.g., tel:+358-555-1234567). There are alsoformats to specify fax and modem numbers.

Finally, in H.323 [Hersent et al. 00], calls are directed tohosts where H.323 applications reside. That is why H.323bases its naming and addressing scheme on IP names andaddresses. However, in order to add flexibility, H.323 includesa complex system of aliases that allows users to make calls

using, for example, e-mail addresses, E.164 numbers or eventhe new H.323 URLs defined in the latest version of H.323. TheGatekeeper, which is the entity that controls H.323 systems ina zone, is in charge of translating the aliases into the networkaddress for the destination terminal, using its internal transla-tion tables or external directories like DNS.

Resolution in VoIP NetworksEach naming and addressing scheme defines its own rules

to make resolutions possible, that is, to define the functions thatallow the conversion between names and addresses at the sameor different communication layers. Resolution can be carriedout in very different ways depending on the scenario. In somecases, a simple table can solve the problem. That could be thecase, for example, for a small VoIP network based on H.323with only one Gatekeeper that centralises the information aboutterminals registered in its zone. Terminals will just ask theGatekeeper when they need to resolve a name or address.

But in general, VoIP scenarios are much more complex thanthe one described above for several reasons: • Scalability: VoIP solutions are being designed to scale to the

size of present telephone networks or even larger,• Reliability: VoIP solutions should reach reliability figures

similar to present telephone network switches (“five nines”,that is, 99.999%),

• Interoperability: VoIP scenarios are not going to be homoge-neous; interoperability between VoIP networks based ondifferent solutions (e.g. SIP and H.323) and, of course, withthe present telephone networks have to be guaranteed.

All these facts, and particularly the last one, raise thecomplex problem of having to harmonize all of the naming andaddressing plans involved in VoIP scenarios. To study the prob-lem in detail, TIPHON (Telecommunications and Internet Pro-tocol Harmonization Over Networks), a project inside ETSI,has defined five different scenarios for a telephone call [ETSI99]:• Scenario 0: a call between two IP terminals,• Scenario 1: a call from an IP terminal to a Circuit Switched

(CS) terminal that goes through a gateway,• Scenario 2: a call from an CS terminal to an IP terminal

through a gateway,• Scenario 3: a call between two CS terminals that go through

an IP backbone (traversing two gateways), and• Scenario 4: a call between two IP terminals that go through

a CS network (traversing two gateways).For example, Figure 1 presents the steps to be carried out in

scenario 2. As shown, several resolutions have to be made tocomplete a telephone call. First, an initial resolution could bemade by users to get the number (strictly speaking, the name)of the person they want to call. Then a Service Resolution hasto be carried out in order to get the address of the networkwhere the destination is. Service Resolution could be used tosupport number portability or non-geographic services such asfreephone. Finally, Routing Resolution has to be invoked,maybe several times, to route the call to the destination.

At present, several proposals are being discussed for per-forming this resolution on a large scale. Some of these propose

3

Voice over IP


reusing the solutions, protocols and experience gained from theInternet using the Domain Name System (DNS). DNS is aworld wide hierarchical distributed database that provides thecapability of discovering the IP address of a certain networkelement, once its name is given. DNS is also able to carry outother types of resolutions, for example, from mail domains tomail server addresses or from IP addresses to names (inverseresolution).

ENUM is the main initiative in this field. It basically propos-es including E.164 numbers in the DNS information tree andusing them as the key to look for information about the servicesassociated with a number. ENUM is described in detail in thefollowing subsections.

3.1 E.164 Numbers and the Domain Name System (DNS)E.164 numbers identify many different types of end termi-

nals, supporting many different services and protocols: ordi-nary phones, fax machines, pagers, data modems, e-mailclients, text terminals for the hearing impaired, etc. This leadsto the following problem: how can users discover services andprotocols supported by each E.164 number?

A working group named ENUM was set up in IETF toaddress the above challenge via DNS-based architecture andprotocols for mapping a telephone number to a set of attributes(e.g. URIs) that can be used to contact a resource associatedwith that number. The result of this working group has beenRFC 2916 [Faltstrom 00] that proposes the use of DNS to storeE.164 numbers and to identify services linked to it.

The actual transformation of E.164 numbers into DNS namesis realised as outlined in the following example. Take an E.164

number written in its full form, including the country codewithout any non-digit characters, except the international “+”sign, e.g. +34918761234. The “+” sign is removed and dots areplaced between each digit, e.g. 3.4.9.1.8.7.6.1.2.3.4. Finally,the number is placed in reverse order and the string “e164.arpa”is appended, e.g. 4.3.2.1.6.7.8.1.9.4.3.e164.arpa

E.164 numbers populated into the DNS must comply withthe hierarchical model inherent to the DNS. Hence it wasagreed that they should all be populated under a specificdomain “e164”. The Top level domain “.arpa” was chosen; as thisdomain allows reverse address lookups, that is, allows the map-ping of an IP address to a domain name. In a similar manner,ENUM maps a number (understood here as an address) to aURI that may be another domain name. Another reason behindchoosing “.arpa” versus other possible top level domains is thatthe domain was redefined as an acronym for “address and rout-ing parameters area” (previously it was short for ARPAnet).The object of this is to centralise all of the infrastructure do-mains (e.g. .e164) under one top level domain.

Both the DNS and E.164 numbering scheme are hierarchicaland delegated structures. Figure 2 shows an example of how anE.164 number is delegated throughout different DNS serverswhile keeping to the E.164 hierarchy.

Each server is delegated a certain section of the number.Under .e164 a set of country code servers would cover anadministrative (or sovereign) E.164 domain, e.g. “.6.4.” forSweden. The higher level country-code server then containsentries for each operator in that administrative domain and soon.

Search Resolution(White pages, etc.)

Directory

Query E.164

A

Num. E.164

Service Resolution(Portability, Personal

Numbers, etc)

ServiceInformation

CalledE.164

RoutingE.164

SwitchPSTN

RoutingRouting

Routing Resolution(Get next hop or destination)

E.164Routing

InfoNext Hop

Gatekeeper Gatekeeper

Gateway

IPNetwork

B

IP address, URI

Signalisation VoIP

E.164Routing

InfoTerminal

Fig. 1: Resolutions in TIPHON Scenario 2

Voice over IP


3.2 Converging NetworksENUM is judged as one of the principal mechanisms for

convergence between the Internet world and the PTSN environ-ment. Many people are referring to ENUM as the “Internet’sGlueball infrastructure1” due to ENUM’s ability to bond anE.164 number to a range of internet-based services via URIs.ENUM is considered an internet-PSTN convergence enablerdue to Naming Authority Pointers, NAPTRs, defined in RFC2915 [Mealling/Daniel 00].

Domain names identify nodes that store resource informationin what are known as resource records (RR). These RRs maystore IP addresses, names of other servers, pointers to otherparts of the domain name space2, etc. The NAPTR is an RRtype that includes a regular expression that can be used by aclient program to rewrite a string into the domain name.

While ENUM can make use of resource records that mayresolve a telephone number into an IP address, another hostname, etc, its real potential lies in bonding a number to NAPTRresource records. This means that an E.164 number may bemapped into another URI. This in turn means linking a numberto many new services identified by those URIs.

The example in Figure 3 is taken from RFC2916.

In the above example, a DNS query for number+4689761234 results in a list of NAPTRresource records. The records for this numbershow the following services as being available:multimedia (SIP), e-mail (mailto) and voicetelephony (tel). Note that each service is a newcommunication medium linked to a new identi-fier.

The DNS client must be able to handle themultiple NAPTR records returned. The clientwill apply all substitutions and performs alllookups, not the DNS servers. The client uses thefollowing key fields in the records to process theresponse: • Order, which is a value that sorts multiple

NAPTR records in a response.• Preference, which indicates the preferred

service from amongst those with the sameorder value.

• “U”, which is a flag indicating that a URI mustbe returned.

• “E2U”, which is a service that indicates anE.164 number is mapped to the URI.

• “Regular expression” which indicates the URIrewrite rule; this will replace the number withthe specified URI.

In the previous example, the preferred commu-nication method is SIP as it has highest order.

The rewrite rule should replace the E.164 number with therequired SIP URI. The client should be able to detect loops incase the last TEL URI is chosen.

Other standardisation forums are already applying ENUM asa mechanism for convergence between networks. In particular,3GPP3 have recently introduced ENUM for translation ofE.164 numbers to SIP URIs in the multimedia subsystem.

Number Portability Issues and ENUMNumber portability refers to the ability of a subscriber to

change service provider without a change in telephone number.E.164 number portability is addressed in recommendationITU-T E.164 Supplement 2. In other words, ENUM must alsobe able to cope with portability as it can be considered aninherent property of all E.164 numbers. Another more basic1. Glueballs are special kinds of particles in sub-atomic physics that

are believed to hold everything together.2. The reader is referred to RFC 1034 “Domain Names – Concepts

and Facilities” [Mockapetris 87] for more on this. 3. Third generation partnership project, www.3gpp.org

4

$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. order pref flag service regexp

IN NAPTR 10 10 “u” “sip+E2U” “!^.*$!sip:[email protected]!”.IN NAPTR 102 10 “u” “mailto+E2U” “!^.*$!mailto:[email protected]!”.IN NAPTR 102 10 “u” “tel+E2U” “!^.*$!tel:+4689761234!”.

Fig. 3: Example from RFC 2916

+46-8-976123 3.2.1.6.7.9.8.6.4.e164.arpa

Root servere164.arpa. IN NS. ns.ripe.netns.ripe.net. IN A 193.0.0.193

ns.ripe.nete164.arpa.IN NS ns.ripe.net.

6.4.e164.arpa. IN NS ns.e164.se.ns.ns.e164.se.IN A 192.168.0.1

ns.e164.se6.4.e164.arpa IN NS ns.e164.se.

7.9.8.6.4.e164.se. IN NS e 164.telco.se.e164.telia.se. IN A 192.168.1.1

e164.telco.se7.9.8.6.4.e164.se.IN NS e 164.telco.se

3.2.1.6.7.9.8.6.4.e164.arpa.IN NS ns.eservice.net

ns.eservice.net.3.2.1.6.7.9.8.6.4.e164.arpa.IN NS eservice.net.

3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR.....

Fig. 2: Example of E.164 number delegation in the DNS

Voice over IP


reason for ENUM being able to deal with number portability isbecause it is a regulatory requirement.

In the PSTN environment, the number portability problemrequires a means of routing towards a new service provider fora given E.164 number. This implies performing a databaselookup to obtain additional routing information, returningeither a routing number or a directory number.

In the DNS world, the problem is treated as a re-delegationof the E.164 entry to a new service provider. In practice, this isachieved by changing the name server records “NS” to point tothe new provider. A higher level authority, presumably theregistry / national-regulatory-authority running the country-code database for a sovereign E.164 region, should oversee theportability process for an ENUM based mechanism.

Another case of portability that appears with ENUM is whena specific service for a given telephone number is changed to anew provider. The NAPTR record indicating the specificservice must be updated to show this change. This processwould be coordinated by the ENUM service registrar (theservice provider that actually links a number to a set of NAPTRrecords on their name server).

Actual administrative and technical problems regardingnumber portability and ENUM are still under consideration.Both ITU-T and IETF are proposing solutions that will ensurecorrect administrative procedures and allow for compatibilitywith number portability solutions in the PSTN environment.

Role of Administrations ENUM is a key technology based on DNS and other

resources from the IP networks, developed by the Internetworld. Nevertheless, as the input to perform ENUM transla-tions is an E.164 number, the IITU-T as well as the nationalauthorities in charge of numbering plans management, plays acrucial role in the implementation of ENUM systems andservices.

The outcome of several meetings amongstpeople from the Internet Engineering TaskForce (IETF) and the ITU-T [ITU 00] hasbeen a decision on how to focus on some veryrelevant issues of an administrative nature.

Although most of the questions are stillopen, key regulatory points that fall withinthe scope of the ITU itself and of the NationalRegulatory Authorities (NRAs) have beenidentified. In fact, most ENUM service andadministrative decisions are national issuesunder the purview of NRAs, since ordinaryE.164 resources are managed nationally.

At the top level, the ITU-T has the respon-sibility for providing E.164 assignment infor-mation to DNS administrators, for perform-ing the administrative function. The ITU willensure that each NRA has authorised theinclusion of their country code informationfor input into the DNS. Below this layer, eachNRA has the entire responsibility of the reg-ulation of ENUM and provides the E.164

assignment information to DNS administrators for performingthe administrative function.

The most important challenges for regulators in order tofacilitate the implementation of ENUM, and to guarantee alevel playing field for the development of fair competition, arethe following: • NRAs shall decide on the way that administration and con-

trol tasks are structured in hierarchical levels. This aspect isseen as a key point as the administrative side of ENUM isconsidered to be more complex than it is technical.

• NRAs also have to ensure that all parties have the informa-tion needed to perform its task, taking into account the needfor accuracy of the information held in the ENUM serviceand the rights of privacy of the end users. The NRA itself hasto make available all the information related to numberingallocation and number portability.

• ENUM allows ISPs to easily provide public voice telephony,requiring E.164 numbering resources for the identificationof dial-up access users. Some countries may have difficultyin accommodating growth in demand for geographicnumbers.

• It is the role of each NRA to select and appoint registries forthe part of the DNS that relates to their country.

• NRAs shall promote the openness of the ENUM architec-ture to competition, in order to prevent entry barriers to themarket and other causes of distortion of competition.

The European Commission as well as European regulators,individually or together in the project teams of the EuropeanCommittee for Telecommunications Regulatory Affairs(ECTRA), are studying ENUM matters with the aim of allow-ing the deployment of this technology under a fair and nondiscriminatory competitive framework.

For the time being no regulatory decisions have been takenregarding ENUM, but regulatory bodies are working in thisfield in order to prepare the framework for the provision of this

5

DNS NameServer

Proxy Queries DNS for SIPAddress based on TN

ENUM resolution4.3.2.1.6.7.9.8.6.4.4164.arpa

SIP Proxies

Dialled digitsB-party=+4689761234

New B-party URIsip:[email protected]

Fig. 4: ENUM as an enabler of communication between PSTN and multimedia users

Voice over IP


kind of service. NRAs, according to the minimal interventionprinciple, have to allow the deployment of all the types of serv-ices that this technology is capable of providing, and at thesame time have to ensure that the provision of such servicesabides by market and privacy legislation.

ConclusionsThis article has presented an overview of how naming

and addressing is being organized in VoIP networks. Thecomplexity of the scenarios in which VoIP technology is goingto be deployed, in terms of scalability, reliability or heteroge-neity, poses important challenges in the solutions beingdesigned. ENUM is a leading initiative that tries to contributeand incorporate all the experience gained in the Internet’s DNSsystem to the solution of some of these important problems.there are, however, still some uncertainties about how the DNSwill behave when managing a number of entries one order ofmagnitude higher than the number being supported now.

However we believe that in the near future ENUM will playan important role in VoIP networks, not only as a mechanism tobe used for resolution purposes, but, what it is most important,as an enabling technology to allow the deployment of newapplications, which is in fact the main reason behind all theefforts being invested in VoIP nowadays.

References[Berners-Lee et al. 98]

T. Berners-Lee, R. Fielding, L. Masinter. “Uniform ResourceIdentifiers (URI): Generic Syntax”. RFC 2396, August 1998.

[ETSI 99]ETSI TS 101 324. “TIPHON; Numbering; Scenarios 1, 2, 3 and4", November 1999.

[Faltstrom 00]P. Faltstrom. “E.164 number and DNS”. RFC 2916, September2000.

[Hersent et al. 00]O. Hersent, D. Gurle, J.P. Petit. “IP Telephony”, Addison-Wesley,2000.

[ITU 97]ITU-T E.164 Recommendation. “The international public tele-communication numbering plan”, 1997.

[ITU 00]“ITU-T SG2 Liaison to IETF/ISOC on ENUM”. ITU-T WorkingParty 1/2, Berlin, 19-26 October 2000. http://www.itu.int/infocom/enum/wp1-39_rev1.htm

[Mealling/Daniel 00]M. Mealling, R. Daniel “The Naming Authority Pointer(NAPTR) DNS Resource Record”, RFC 2915, September 2000.

[Mockapetris 87]P. Mockapetris, “Domain Names-Concepts and Facilities”, RFC1034, November 1987.

[Vaha-Sipila 00]A. Vaha-Sipila. “URLs for Telephone Calls”. RFC 2806, April2000.

6

Voice over IP


Multimedia Services over the IP Multicast Network

Antonio F. Gómez-Skarmeta, Angel L. Mateo, Pedro M. Ruiz

Voice over IP (VoIP) is one of the most important and complex new services that are being introduced inInternet. VoIP makes use of several different technologies like signalling, streaming of real time data, sessionmanagement, etc. The development and the experimentation of video conferencing applications over IPmulticast networks have contributed greatly to the maturation of some of these technologies. This articlesummarizes the most important topics related with IP Multicast technology and video conferecing over IPMulticast networks. After introducing IP multicast technology as a mean to support many-to-manycommunications, we present some of the protocols and the applications used over IP multicast service.Finally, we outline some of the problems that preclude IP multicast to be widely deployed.

Keywords: IP Multicast, MBone, MBone Tools, RTP, SAP,SDP, Multicast Routing

Introduction to IP MulticastWe are presently go through a revolution in the Internet

world as it happened with the WWW. Terms like e-commerce,video conferencing, streaming, video on demand and manyothers are becoming common usage in day-to-day life. VoIP isone of the technologies contributing to this revolution. How-ever, the present IP networks are not adequately adapted to sup-port this kind of services. For example, there are no mecha-nisms that guarantee a satisfactory quality of service (QoS) forVoIP communications. To support many-to-many communica-tion, IP multicast offers a much more efficient mechanism thanthe current IP unicast networks.

1.1 Unicast vs. MulticastThe typical Internet services are based on the IP unicast mod-

el, that is to say: datagrams are addressed to only one host.Such communication is called “one-to-one”. In some othersituations, when there are more than two parties, the use of IPunicast can be very inefficient because the same informationhas to be sent to several destinations, and this process couldoverload the senders and the network (Figure 1).

How can we avoid this problem? Traditionally, it has beensolved using “reflectors” (or Multipoint Control Units – MCU– according to H.323 terminology). A reflector is the equip-ment responsible for sending a packet from a source to all des-tinations taking place in the communication. This approach hasseveral drawbacks, the most important being the excessivebandwidth consumption.

As an alternative, IP multicast can be used to make a data-gram reach all the destinations that belong to a group. The con-cept of group is implemented using a special range of IPaddresses. When a host is interested in receiving the datagramsaddressed to a group, it has to join that group by signalling it tothe network. This subscription is completely dynamic. The

important fact behind IP multicast is that the source only sendsone packet and the network is responsible for making the nec-essary copies to reach all destinations. This copying is made sothat only one instance of the packet is transmitted over eachlink.

1

Antonio F. Gómez-Skarmeta is an Assistant Professor at theDepartment of Communications and Information Engineering ofthe Universidad de Murcia since 1996 where he received a Ph.D.degree in Computer Science from that university. His currentresearch focuses on multimedia Internet protocols and quality ofservices. <[email protected]>

Angel L. Mateo is a telematic service manager at the Universi-dad de Murcia, where he is also an associate professor at theDepartment of Communications and Information Engineering.He is working on his Ph.D. degree and he is the responsible ofvideo conferencing services in that university. <[email protected]>

Pedro M. Ruiz graduated from the Universidad de Murcia witha degree in Computer Science. He is currently an associate profes-sor at the Universidad Carlos III of Madrid and works in the net-work engineering area of the Spanish National Research Network(RedIRIS). His main interests are advanced network services andprotocols. <[email protected]>

Figure 1: Distribution of one only packet to multiple receivers

Voice over IP


1.2 Multicast AddressingWhen the IP addressing scheme was designed, several class-

es of addresses were defined, as depicted in Figure 2. The classD addresses were reserved for multicast. So, IP multicast usesthe range 224.0.0.0 to 239.255.255.255. These addresses arecommonly called group addresses or multicast addresses. Fromthe whole range of multicast addresses, some are reserved forspecific purposes, and the rest can be used by multicast appli-cations.

1.3 Internet Group Management Protocol (IGMP)As we mentioned before, the way IP multicast works can be

summed up as follows: receivers join the group they are inter-ested in, and the network makes the datagrams sent to thatgroup delivered to every receiver that joined the group. Amechanism is needed for the hosts to tell the router that they areinterested in joining a certain group. This mechanism is theIGMP protocol [Deering 89], that defines the behaviour ofhosts and routers when informing about joining or leaving agroup.

When a host wants to join a group, it sends an IGMP reportmessage to the 224.0.0.1 address (which should be includedwith every multicast-enabled host). When the router receivesthis message, it takes into account that there is at least one hostinterested in receiving that group on that interface.

Periodically, the router sends IGMP query messages to the IPmulticast address of the group to ask for renewals. If there arestill receivers, one of them must answer with an IGMP reportaddressed to the group it wants to renew. The IGMPv2 is nowcommonly used, however IGMPv3 implementations start com-ing up.

1.4 Mrouters and tunnelsMost of the first Internet routers were manufactured without

taking into account IP multicast traffic1. In order to experimentwith IP multicast over Internet, it was necessary to define a wayto interconnect IP multicast-enabled networks through net-works without IP multicast support. This activities broughtabout what we know today as the Multicast Backbone, or sim-ply MBONE [Macedonia/Brutzman 94].

IP multicast-enabled routers are sometimes called mrouters.They must satisfy two basic requirements:• Implement the IGMP protocol.• Use some IP multicast routing algorithm.

In order to connect a network to MBONE, one of theirmrouters has to be connected to the rest of the IP multicastclouds. If our Internet Service Provider (ISP) offers the nativeIP multicast service, a simple configuration will suffice to dothe task. Otherwise, we will need to configure a “tunnel” toanother router connected to the MBone. This tunnel will beused to encapsulate every IP multicast datagram that has to betransmitted between these two routers into IP unicast data-grams addressed to the other end of the tunnel. So, an IP mul-ticast-disabled network can be traversed (Figure 3).

1.5 Multicast routingIP multicast routing is in charge of making the datagrams to

flow from sources to every destination joined to a group. Agood routing algorithm should guarantee that• an IP multicast datagram addressed to a multicast group G,

reaches all the hosts that have joined G,• there are no loops, i.e., a datagram reaches its destination

only once and, if possible, using the shortest path.The IP multicast routing protocols are usually classified

according to the way they work: There are protocols that workin dense mode like Distance Vector Multicast Routing Protocol(DVMRP [Waitzman et al. 98]). Some others work in sparsemode like Protocol Independent Multicast Sparse Mode (PIM-SM [Estrin et al. 98]). There are algorithms that do not fitexactly in one of these two models, an example is MulticastOpen Shortest Path First (MOSPF [Moy 94]). The commonpractice is to use PIM-sparse-dense mode as intradomain mul-ticast routing protocol because it is very efficient and needs nospecial routing messages interchanged between neighbours.Instead, it uses the unicast routing table in the router to do thecalculations and decide on the better paths.

Multicast routing algorithms are usually much more compli-cated and difficult to configure than the unicast ones.

Services over IP Multicast

2.1 Multimedia ProtocolsIP multicast as a network service offers no service directly to

the user. But it offers an excellent framework for many-to-many multimedia data internetworking. Many protocols havecome up in the IP multicast and multimedia content distribution

1. Almost every router manufactured today implements at leastIGMP and one or more IP multicast routing protocols.

2LAN 1mr-1

LAN 2 LAN 3mr-2 mr-3

Tunnel Router IP multicast Router IP unicast

Figure 3: A multicast tunnel schema

Class A

Class B

Class C

Class D

Class E

0

1 0

1 1 0

1 1 1 0

1 1 1 1

Network Id. Host Id.



Network Id.

0 8 16 24

Figure 2: IP Address classification

Voice over IP


environment (Figure 4). This set of protocols range from gener-ic protocols like those used for audio and video streaming (i.e.RTP), or to manage multimedia sessions (i.e. SAP, SDP, SIP);to others much more specific used only for certain applications.It is important to note that some of these protocols, althoughdesigned, developed and tested over MBONE, have been wide-ly adopted in other frameworks like VoIP.

2.2 Real Time Protocol (RTP)Internet follows a best-effort delivery model. That means

that, when a datagram is sent, the network does guarantee nei-ther the delivery nor that the different datagrams sent arrive incorrect sequence or in time. The network only guarantees thatit will do as well as possible in delivering the datagram. Insome cases, specially with real-time data like VoIP traffic, thismodel does not work properly.

Besides, when sending continuous media (like digitisedvoice or video) over a packet network, it is essential to providethe means for the receiver to be able to reconstruct the originalinformation. The packets generated at the origin – typically aflow of packets equally spaced in time – will arrive to thereceiver possibly out of sequence, with losses or changes ininter-packet times (jitter). A mechanism is needed for thereceiver to be able to reproduce the audio or video being sent insuch environment.

Real-Time Transport Protocol (RTP, [Schulzrinne et al. 96])is the protocol defined by the IETF for real-time data transportover the Internet. The protocol basically labels each datagramto be sent, attaching them information like the time when theywere generated or the type of codec being used, so that whenthey reach the receiver, it can reproduce the original flow ade-quately.

It is important to note that RTP provides no mechanism foron-time delivery or any other QoS guarantees. In order to offerQoS support for real-time communications, RTP have to beused together with other protocols or solutions like IntegratedServices or Differenciated Services QoS models. However,RTP provides specific means to control the quality of the dis-tributed data, the Real Time Control protocol (RTCP), thatallows the senders and receivers to know, for example, thepacket loss rate in a session. In addition, RTCP provides iden-tification mechanisms for RTP communications.

RTP has become the de facto standard tosend continuous media over packet (mainly IP)networks. It is used by most of VoIP proposalslike H.323, MEGACO or SIP.

2.3 SAP and SDPIn a multicast environment where all parti-

cipants can send and receive data betweenthem, the concepts of client and server makesno more sense. Hence there is a need for amechanism to allow for the user to locate aconference he is interested in. This mechanismmust be based in the concept of session, whichis an aggregation of related contents. For

example, in a video conference, a session would be defined asthe multicast group used for audio transmission, the multicastgroup used for audio transmission, the codecs being used bothfor audio and video, and so on.

For session management, two protocols have come up inMBONE: SDP and SAP. SAP (Session Announcement Proto-col [Handley et al. 00]) defines the use of specific multicastgroups to distribute session information. The session creator isresponsible for periodically reannouncing it so that people join-ing the special “announcement group” after the creation canstill know about the session. The information used to describethe session is specified by SDP (Session Description Protocol[Handley/Jacobson 98]).

As RTP, SDP protocol has been reused in other environ-ments, for example, it has been incorporated into MEGACOVoIP proposal.

2.4 SIPThe SDP/SAP model requires the user to look for the session

he wants to attend. However, in some scenarios like IP teleph-ony, a way to invite other parties to participate in a session isneeded. The Session Initiation Protocol (SIP, [Handley et al.99]) came up for covering this need.

SIP defines the signalling mechanisms that are necessary toestablish a session and to negotiate the parameters to be used init, such as codecs, media, location, etc. As other protocols men-tioned, SIP has surpassed the MBONE environment were itwas originally created and now it has become one of the mainproposals for VoIP. In fact, SIP has been recently selected by3GPP to be used as the VoIP protocol for 3G mobile networksbased on “All-IP” proposal.

MBone ToolsSeveral applications have been developed to test the

advantages of the IP multicast model at the initial stages of theMBone. These tools, commonly known as the MBone Toolsallow us to participate in different kinds of video conferencesand meetings using IP multicast as the network technology.The typical MBone tools are (Figure 5):• SDR. This tool is equivalent to a TV guide. It shows all

planned and ongoing MBONE sessions. Recent versionsalso allow us to use a “quick call” service based on SIP.

3

Integrated Services Forwarding

IP

UDP TCP

RSVP RTP and RTCP SDAP HTTP

SDP

SharedTools

Conf. Control Audio Video Session Directory (9.0 pr)

SMTP

Figure 4: Multimedia protocols

Voice over IP


• VIC. This tool is used for video transmission with a greatvariety of codecs available. It can be used on almost everyplatform and is compatible with several standards for cap-turing video. So, it allows a simple personal computer tosend video without needing to buy an expensive video cap-turing hardware.

• VAT and RAT are used for audio conferencing. They are alsoavailable for many platforms and support several codecs likeGSM, PCM, DVI, and so on.

• WB. This tool is a distributed shared whiteboard that can beused by all the participants and offer the same functionalityas the usual blackboard in a classroom.

• NTE stands for Network Text Editor and offers the function-ality of a distributed word processor. It supports tokens forasking permission to write and is quite comprehensive.

Recent applications using IP multicast are more complex butoffer new important functionalities. The goal is to integrate allthese tools into one specific tool possibly in the Web. In fact,some big projects like MASH are working on Web integration.Some of these “new generation multicast tools” are:

• DLB is an improved version of an electronic whiteboard thatsupports two modes (on-line and off-line). It thus allows forediting slides off-line and then present them on-line.

• MiNT is a very complete application developed by the Ger-man GMD that supports the SIP protocol, includes an RSVPagent for bandwidth reservation and even an integrated GUIfor audio and video transmission.

• MASH is a very big project initiated at Berkeley and itsmain goal is to integrate the typical MBone Tools into acommon GUI. In addition, tools for playing and recordingsessions are offered. They are also deploying “mashlets”that aim to integrate the GUI into the WWW.

• RELATE (REmote LAnguage TEaching). This tool wasdeveloped at the University College London and is veryinteresting for teaching on-line. Although it was initiallythought for language teaching it can also be used to teachsome other subjects. This tool integrates into the same GUIthe audio, video, whiteboard and text editor applications.

Figure 5: Some of the MBone tools

Voice over IP


Advanced services over IP MulticastAs mentioned in this article, video conferencing over IP

Multicast initiatives led to an important number of applicationsand protocols. Many are used in other environments, mainly inVoIP architectures (i.e. RTP, SIP, SDP, codecs, etc).

However, IP multicast and its video conferencing tools havelimitations that hindered the deployment of MBONE tools.

4.1 Multimedia services integrationMultimedia services over IP multicast present the following

limitations:• No integration with solutions based on some other technol-

ogies. It is desirable to have a solution to integrate IP multi-cast with H.320, H.323 and other VoIP solutions in general.SIP will be very useful as a glue element between all thesetechnologies.

• No integration between the MBone tools. Currently, one dif-ferent tool is used for every service (i.e. VIC for video, VATfor audio and so on). Although this model simplifies thedesign and development of the tools, it becomes an issue dueto the lack of synchronization and user interface integrationbetween tools. Nowadays, several proposals are coming upwithin the IETF to solve this problem. There are two basicmodels: mbus (Multicast Bus) and SCCP (Simple Confer-ence Control Protocol).

4.2 Security and access control in multicast environmentsIn the same way that the video conferencing tools over IP

Multicast present several limitations that are slowing its de-ployment, the limitations of the IP Multicast model are makingISPs to think twice before offering the IP Multicast service totheir customers. The main problems of that model can besummed up as:• Denial of Service (DoS) attacks.• Policy of use, because there is not a defined method to con-

trol access to the network.• Authentication.• Address allocation.

To avoid these problems, several working groups at the IETFare defining new protocols or even updates to the current IPmulticast model. Some such initiatives are:• BGMP (Border Gateway Multicast Protocol). It is thought

to be the successor of the currently used MBGP (Multipro-tocol BGP). This protocol is very scalable and, if combinedwith other protocols for address allocation like MASC, isable to solve the address allocation problem.

• MSEC (Multicast SECurity). It is a new IETF workinggroup that is responsible for studying and solving securityconcerns in IP multicast.

• SSM (Source Specific Multicast). This is a new multicastmodel based on the concept of channel: a pair of a sourceand a multicast group. The key concept in SSM is that rout-ing decisions are taken based on channels instead of multi-cast groups.

• GLOP. This mechanism divides statically and according tothe AS (autonomous system) number, the 233.0.0.0/24range so that there won’t be collisions between ASs when

selecting an IP multicast group. Figure 6 shows how to knowwhat groups belong to what Autonomous System. For exam-ple, in the case of RedIRIS, the AS number is 766, so therange 233.2.254.0/24 is available for being used within theRedIRIS AS without worrying about possible collisions.

ConclusionsIn this article, we have covered the most important topics

related with IP Multicast technology and video conferecingover IP Multicast networks. We have showed how importantprotocols developed inside MBONE initiative have been laterreused in the most outstanding VoIP proposals like H.323, SIPor MEGACO. Although multimedia over packet networks is awide subject and has been vastly investigated and experiment-ed, we can consider MBONE as an important testbed wherebasic technologies nowadays used in VoIP have been matured.

Although multicast video conferencing is not popular at thismoment – most of present VoIP scenarios resemble the onesfound in conventional telephone networks, and so, they are uni-cast –, IP multicast opens possibilities for new applications,improving the use of network resources. But, as mentionedbefore, much more development and research is needed toimprove multimedia conferencing over IP Multicast.

References[Deering 89]

S. Deering, Host Extensions for IP Multicasting, RFC 1112, 1989[Estrin et al. 98]

D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, ProtocolIndependent Multicast-Sparse Mode (PIM-SM): ProtocolSpecification, RFC 2362, 1998

[Macedonia/Brutzman 94]R. Macedonia, D. P. Brutzman. MBone Provides Video andAudio for Internet Across the Internet. IEEE Computer, Vol. 27,April 1994, pp. 30–36

[Meyer 98]D. Meyer, Administratively Scoped IP Multicast, RFC 2365,1998

[Moy 94]J. Moy, Multicast Extensions to OSPF, RFC 1584, 1994

[Schulzrinne et al. 96]H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: ATransport Protocol for Real-Time Applications, RFC 1889,1996

[Handley et al. 00]M. Handley, C. Perkins, E. Whelan, Session AnnouncementProtocol, RFC 2974, 2000

[Handley/Jacobson 98]M. Handley, V. Jacobson, SDP: Session Description Protocol,RFC 2327, 1998

[Handley et al. 99]M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP:Session Initiation Protocol, RFC 2543, 1999

[Waitzman et al. 98]D. Waitzman, C. Partridge, S. Deering, Distance Vector MulticastRouting Protocol, RFC 1075, 1998

4

5

Figure 6: Structure of GLOP addressing

0 8 16 24233 16 bits AS local bits

Voice over IP


Implementing Voice over IP

André J. Hes and Ronald van Teeffelen

This paper describes the implementation of Voice over IP services on a wholly owned IP infrastructure. Thebenefits, minimum requirements and the sensitivity of IP data packages are outlined based on research andexperience gained during large-scale pan-European wide Voice over IP implementations.

Keywords: VoIP, Gateway, Gatekeeper, packet loss, jitter,packet queuing, packet buffering

IntroductionVoIP allows customers to use the access service for voice

in two ways. First, customers can use the PSTN breakout serv-ice that allows them to offload their H.323 VoIP traffic to thenetwork, and have their telephone calls sent out onto the PSTNin the country closest to the dialled subscriber. This least-costrouting functionality reduces long-distance telephone costs foroff net calling.

The second service for customers is the possibility to use theIP network for on net calls. Customer PBXs at various officelocations throughout Europe are coupled via the IP network,enabling them to route calls between their offices across onenetwork, via CPE gateways. In effect, the existing IP infra-structure is used for both voice and data traffic. It is also possi-ble to run incoming calls on IP via gateways. This functionalityis available for service numbers only (e.g. free-phone num-bers).

VoIP, integrated with data traffic, creates a foundation fornew possibilities that can significantly reduce cost for voicecalls. This, in turn, opens up numerous possibilities for offeringvalue-added services in this new integrated space. To take justone example, international call centres can use their resourcesmore effectively using both language and skill-based routing,in conjunction with knowledge databases. In theory, integrateddata and voice can fully handle the call with pre-recordeddigitised messages by identifying your customer, and theirpotential question or problem. This provides a level of callintelligence, well in advance, of current call centre capabilities.

Minimum requirementsCustomers are connected via the wholly owned IP infra-

structure. The breakout possibility to PSTN is provided by theVoIP gateways. In general voice services can be provided overIP when:• Customers have dedicated access to the network (minimum

256kbit/s connection required),• Quality of Service (QoS) must be provided,• Any firewalls or network address translation devices in the

network path must be H.323 aware,

• Link layer QoS mechanisms should be in place for customernetworks and networks that are not over-provisioned, aswell as for the local tail,

• PSTN-Gateways will be located at the Points of Presence(PoPs).

Telephony systems supported by KPNQwest VoIP servicesmust meet one of the following criteria:• PBX with ISDN PRI or BRI interface • PBX with E&M or analogous FXO interface• Telephone with analogous FXS interface

Voice over Internet Protocol (VoIP); how it worksFigure 1 shows the general network layout of Voice over

IP.

VoIP has two physical components:• PSTN Gateways: Terminate calls from physical sources

within the network to the PSTN. The gateways are located atPoPs in the IP backbone.

• Customer equipment: A VoIP gateway at the customerpremises is used to connect a customer PSTN switch or PBXto the VoIP cloud. Usually, the customer also has a PSTNconnection on his PBX and incoming calls are routed overthis connection. The VoIP gateway can also be integrated inthe Customer Premises Equipment (CPE) router. The gate-keepers provide registration, admission and status (RAS)functionality and Least Cost Routing services. Gatekeepersalso control the VoIP switching logic. The centrally located

1

2

3

André J. Hes is Senior Project Manager at KPNQwest, current-ly working on the merging of four regional European call centresto one virtual centre. He has over 15 years experience in IT, asbusiness consultant, Project and IT-Manager, Graduate in Busi-ness Information Technology, and Postgraduate EDP-Auditing atthe Amsterdam Business School. Receiver of the KPNQwestHero award for the Nokia-game project. Previous employers; Tan-don, KLM, Atos-Origin, Philips. <[email protected]>

Ronald van Teeffelen is currently working with KPNQwest asa Technical Consultant on VoIP within Technical Development.His main responsibility is the development of new VoIP services.He is also interested in IP VPN services. Van Teeffelen holds aMasters Degree in Information Engineering, has over five years ofexperience in networking. <[email protected]>

Voice over IP


Command Centres contain the routing tables. This set upallows a simple standard configuration of dial peers on thegateways and central management of the routing tables andLeast Cost Routing service.

There are three basic types of traffic:• RAS messages between the VoIP gateways and the Gate-

keeper. These messages follow the standards H.323 andespecially H.225 and H.245. To set up a voice connection,the initiator starts on an H.225 connection over TCP to theGatekeeper at port number 1720. In this session a portnumber for the following H.245 connection is exchanged.The initiator then opens an H.245 connection to the gate-keeper over TCP (ephemeral port), in which ports for theactual voice traffic between two H.323 terminals (e.g. CPEGateway and PSTN-Gateway) are exchanged (RTP traffic,ephemeral UDP ports). While the H.225 connection couldbe torn down after the H.245 ports have been exchanged, itwill in practice stay up until the call is over.The Gatekeeper itself will also open connections to the ter-minating H.323 terminal in order to be able to negotiate theports that should be used between the initiating and the ter-minating H.323 terminal.

• Actual voice traffic. The actual voice traffic flows over RTPbetween two H.323 terminals. For this reason, two RTP andone or two RTCP flow are established (over UDP). The portsto be used for these RTP flows have been exchanged in thepreceding, (see above) H.245 connection.

• Administrative traffic, which includes administration (overtelnet, ssh, http and https) of gateways and gatekeepers andlogging of information like SNMP traps or call data records.

How the process works:• When the CPE VoIP gateway

receives a call, it contacts agatekeeper. The gatekeeperlocates the correct PSTN gate-way to route the call to, andforwards the IP address of thePSTN gateway.

• The gateways then open up anH.323 call. In the event of aPSTN gateway failure, callswill still be routed to their des-tination.

• If one of the gateways fails, thegatekeeper automaticallyroutes the call to a backupgateway.

• Calls will be routed to the gate-way depending on the countrycode dialled. For example,calls to Germany will be routedto Frankfurt, and will leave thenetwork from there as a localcall.

• The gatekeeper uses authentication to prevent unauthorisedusage. If the voice interface (PRI/BRI) to the gateway fails,the PBX will route the call over the PSTN.

• The backbone provides reliability and availability for callsin progress.

Voice data packet sensitivityUnlike data traffic, voice traffic is intolerant of packet

loss and delay, primarily because these conditions degrade thequality of voice transmission delivered to the end user. Delaymust be constant for voice applications. The ITU-T G.114recommendation specifies that for good voice quality, no morethan 150 milliseconds of one-way, end-to-end delay shouldoccur. KPNQwest, for example, guarantees 80 ms over itsentire IP backbone.

IP Packets that are to be sent to a specific interface on a routerare first put into a queue, from which they are sent. Whenqueues fill up, this will add latency for packets that freshly enterthe queue. This can happen if the sender is able to send data ata higher speed than the speed of the access line. In order to pre-vent this filling up of the queues having negative impact on thevoice quality due to latency, alternative queuing strategies mustbe used, which prefer voice packets to other packets (Fig. 2).

In this scenario, a separate queue for voice packets exist.Voice and non voice packets are sent alternately on the wire, re-ducing latency for the voice packets.

Delay variation versus time: jitterAs VoIP is a packet switched service, it will show a vari-

able delay in packet delivery time, known as jitter. Packetstransmitted between Coder and Decoder through an IP networkwill experience different delays and will arrive at a non-uniform rate. The main causes for jitter are the buffering and

4

5

Fig. 1: General network layout of Voice over IP

PSTN country 1

VoIPGateway country 2

Country network

demarcation line

IP transit

PSTN

Customer BIP Network

customer VoIPgateway


Global IP Backbone

PSTN country 2

VoIPGateway country 1

Command Centre

Gatekeeper

Data

demarcation line

PSTN

Customer AIP Network


IP transit

Voice over IP


queuing processes in each of the IP ‘hops’. In addition, thesimultaneous transport of data through a relatively low-band-width local tail will cause jitter in the VoIP packets.

Since the Decoder must decode the IP packets into a constantvoice stream, a buffering mechanism is needed. This buffermust be implemented at the receiving side in the gateway toabsorb the fluctuation in packet arrival rate. The delay of an IPpacket through the network is composed of a fix part character-istic of the propagation delays and the average queuing length,and a variable part characterising the jitter. The jitter buffer willhold arriving packets in memory for a certain time before send-ing them to the decoder. The larger this jitter buffer is, the morejitter on the packets can be absorbed. However, the delay intro-duced by the jitter buffer reflects in the one-way, end-to-enddelay directly. In essence, a trade-off must be made betweenpacket loss and introduced delay.

In practice, two types of jitter buffers can be implemented:• Dynamic jitter buffer: terminals use heuristics to determine

the size of the jitter buffer. Starting, for example with a smalljitter buffer and progressively increase it until the packetdrop is below a specified percentage.

• Fixed jitter buffer: The size of the jitter buffer can be set toa fixed value.

The effect of jitter will be most pronounced when voice anddata is transported over a low band width link. A 1,500 bytes IPdata packet transported over a 512 kbit/s link can cause a jitterin VoIP packets of approximately 1500*8/512k = 23 ms.

Other QoS MechanismsAs previously mentioned, voice traffic is sensitive to

packet loss and delays. This could be the result of an overfullconnection on the local tail, the access line between the nearestPoint of Presence (POP) and the Customer Premises Equip-ment (CPE router). To prevent this, quality of service (QoS)mechanisms need to be put in place.

In order to achieve an optimum voice quality, the POP andCPE router will have to be capable of treating voice traffic in adifferent manner to the rest of the network data. In addition, the

minimum requirement for a local tail of 256 kbit/s for a VoIPcustomer, and to ensure that delay sensitive voice traffic istreated with priority, some of the following queuing mecha-nisms need to be used:• IP Real Time Protocol (RTP) compression will be employed

if the local tail bandwidth is below 2 Mbit/s (E1 speed); thedelay overhead for compression quashes any gains whenlink speeds are over 2 Mbit/s and can only be implementedon PPP, ISDN, HDLC and frame relay links.

• IP RTP prioritisation will be used to provide a strict priorityqueuing scheme for voice traffic.

• Class-Based Weighted Fair Queuing (CBWFQ).One of the intrinsic values of WFQ in the data-only world is

its fairness. WFQ is designed to fairly share available resourcesbetween bursty traffic types. This particular aspect of WFQ,that is so beneficial to data, is what renders it inadequate forpacketised voice traffic. Although voice traffic can be assignedan IP Precedence of 5 to give it a weight that grants it greaterpriority than other flows, if a large number of competing flowsexist, voice traffic may not be allocated sufficient bandwidth tomaintain the required kind of quality. The quality of controlledconstancy of delay and packet loss is required all the time,regardless of the priority assigned to the packet. Therefore, toensure that VoIP traffic always gets the bandwidth it requires,IP RTP Priority (and other features) can be used for voice traf-fic, and CBWFQ for all other traffic.

Other issues

Echo cancellationFeedback chains in analogous equipment like the telephone

handset can impose a certain echo that travels back up the lineto the original speaker. The VoIP gateways can do a certainamount of echo cancellation by “remembering” the last fewmilliseconds of speech and subtracting these from the signalcoming back to the gateway. If the local loop (the distance fromthe analogous interface to the connected equipment producingthe echo) is longer, the value of time to be remembered shouldbe extended.

6

7

Fig. 2: Queuing strategies for voice packets

Normal queuing:

Newpackets

Alternative VoIP queuing strategy:

Newpackets

Newpackets

VoIP VoIPVoIP ftp 20ms ftp 20ms

VoIP VoIPVoIP

ftp 20ms ftp 20ms

VoIP VoIPVoIPftp 20ms ftp 20ms

send

send

Voice over IP


If a longer time is configured for this feature, it will take theecho canceller longer to converge; in this case, the user mighthear a slight echo when the connection is initially set up. If theconfigured value for this command is too short, the user mighthear some echo for the duration of the call because the echocanceller is not cancelling the longer delay echoes. The voiceports can be configured for input gain, output attenuation andecho-cancellation.

Silence detectionIn order to reduce network bandwidth, the VoIP gateway can

detect pauses in speaking and not transmit data for the durationof these pauses. This results not only in reduced bandwidth, butalso in a sort of ‘total silence’ for the receiver that is uncomfort-able for most humans. The VoIP gateway is also capable of pro-ducing some “comfort noise”. The generation of comfort noiseshould be turned on, if silence detection is turned on. In prac-tice, silence detection should be turned off, unless bandwidth isrestricted. By default, silence detection and comfort noise is en-abled, so VAD must be disabled in the VoIP dial peer.

ClockingPSTN equipment needs to be synchronised in order to be able

to achieve a common sense on the understanding of time slots.For this purpose, a PBX gets clock information from the publicswitching equipment.

SignallingFor signalling within the H.323 cloud, all H.323v2 signalling

standards as Q.931, H.323, H.245, H.225 and RTCP are sup-ported. For signalling towards the PSTN side, ISDN BRI andPRI (EDSS-1) are supported for digital connections. For anal-ogous connections, standards supported are E/M, FXS (onlylow-end version of product) and FXO.

General Voice CodecsG.711 with A-law encoding is the default codec; customers

can use G729 or G726 as well.

Voice gateways support different numbers of simultaneouscalls depending on the codec complexity. Only for medium orlow complexity codecs, the full number (equals to the numberof access channels) of simultaneous calls are supported. Forhigh complexity codecs, the number is lower.

ConclusionBesides the minimum requirements stated above, due to

the sensitivity and intolerance of VoIP data, maintaining a VoIPnetwork and benefiting from cost-savings and future applica-tions through combining voice and data over one network,requires a well-equipped and skilled organisation to guaranteeoptimal voice transmission.

8

Codec Voice Bandwidth

Transport Bandwidth Default Packet size

Packetisation delayMs

Coding Delay Ms

Complexity (accord-ing to Cisco)

Quality MOS value

KPNQwest VoIP

G.711 64 kBit/s 80 kbit/s (with RTP header compression about 65 kbit/s)

160 20 0.375 Low Normal 4.1 ✔

G.729 8 kbit/s 12 kbit/s (RTP comp.)24 kbit/s (without rtp comp.)

20 20 35 Medium Normal 3.92 ✔

G.726 16 kbit/s 32 kbit/s (with RTP header compression about 17 kbit/s)

40 20 0.375 Medium Analog ✔


60 20 0.375 Medium Normal ✔


80 15 0.375 Medium Normal ✔

Fax, T.38 Medium N/A N/A ✔

Voice over IP


Voice over IP Virtual Private Networking

Olivier Hersent

This article describes the various aspects of the integration of Voice over IP (VoIP) into a Virtual PrivateNetwork. Key factors of deploying a VoIP Virtual Private Network service are pointed out, showing theservice provider and the customer point of view. Value-added services such as off-net to on-net connectivityand unified messaging are outlined. In addition, architectural strategies of dialling plans and group prefixesare summarised. Quality of Service is also addressed.

Keywords: Voice over IP, IP VPN, PSTN, iPBX, numberexpansion strategy, Quality of Service

IntroductionOrganisations around the world are constantly seeking to

reduce communications costs and increase organisational pro-ductivity. Significant improvements in just these areas can bemade today by using VoIP. When it comes to value-added serv-ices, especially in a distributed environment, VoIP is muchmore efficient than circuit-switched networks. It allows usageof a network that not only converges voice, data and video, butalso facilitates the introduction of new applications.

The most crucial feature of a VoIP Virtual Private Network(VPN) is the ability to connect many corporate sites to a singlenetwork while preserving a virtual isolation of each group thatcommunicates on the shared infrastructure. Each group can useoptimised private dialling plans, relying on the VoIP VPN tomanage the communications among themselves as well as pub-lic networks and groups.

The VoIP VPN is an application level overlay on top of anyIP connectivity technology, and can be deployed with or with-out a data level VPN using technologies such as IPSec (IPLevel Security Standard).

Deploying a VoIP VPN serviceWhen selecting value added services, a change on the

customer premises should be stringently avoided. Replacingthe leased lines between Private Branch Exchanges (PBX’s) –or the equivalent Intelligent Network Closed User Group serv-ice – with a VoIP VPN is an ideal example of a service that re-quires no change on the customer’s side.

Technically, the VoIP VPN service does not require signifi-cant changes in the VoIP network architecture. It is an exactreplacement of existing Public Swtiched Telephone Network(PSTN) technologies. The initial investment is therefore limit-ed to one CCS (Call Control Server) Softswitch capable ofVoIP VPN operation, and the installation of dedicated or sharedVoIP gateways connected to corporate PBX’s.

The VoIP VPN service is also an excellent means of introduc-ing new VoIP value-added services in the future. For example,remote workers can be included on the corporate VoIP VPN.

Advanced number routing and virtual call center services canbe offered as well.

2.1 The VoIP service providerMost of the investment that VoIP service providers need to

make is used to purchase network infrastructure (such as VoIPgateways) and to install this infrastracture in multiple points ofpresence. This includes a basic call control infrastructure inorder to route phone-to-phone calls. This infrastructure mayalso provide simple prepaid telephony and PC-to-phone servic-es. Initial services usually use about 20–40% of the deployedcapacity.

The opening up of the VoIP network to value added servicesis an opportunity to use some of the spare capacity of the de-ployed network for applications that are less sensitive to price.The VPN feature allows the core VoIP network to behave as ahub aggregating many different telephony services on the samebackbone: corporate PBX’s, corporate or hosted Internet Proto-col Private Branch Exchanges (IPBX’s), residential gatewaysand IP phones can all be connected to the VoIP VPN core. Thisenables VoIP Service providers to offer services to the wholerange of end-user devices, from blackphones on PBX’s to IPPhones on IPBX’s.

Most corporations are permanently connected by data con-nectivity service providers for their e-mail, intranet, extranetand Internet services. Corporations with multiple sites alreadyhave a need for top quality connectivity services. These samecorporate customers are also those who probably already have

1

2

Olivier Hersent, NetCentrex Founder and Chief ExecutiveOfficer, started NetCentrex in 1998. Previously, he was the leadVoIP architect for France Telecom R&D laboratories (CNET)where he focused on IP security, Multicast and QoS. Hersent is anactive player of the VoIP industry through his participation instandards organizations such as ETSI TIPHON and technical con-ferences. He a published on the subject of VoIP, IP Telephony,Packet-based multimedia communication systems (Addison Wes-ley Longman). Hersent graduated from Ecole Polytechnique inParis and completed a postgraduate telecom engineering programat Telecom Paris. <[email protected]>

Voice over IP


a voice VPN in place, albeit using traditional circuit switchedtechnology.

2.2 The VoIP customerBy converging both voice and data services on the data net-

work, all internal, site-to-site calls use only IP resources andare therefore included in the current monthly fee already paidfor the data network. The previous architecture of leasedtelephony lines disappears. In addition, off-net calls are nolonger routed through the corporate site that was closest to thedestination, as in the previous circuit-switched architecture.With the VoIP VPN architecture, all off-net calls are routedthrough the VoIP gateways of the service providers, and use theroutes and termination gateways chosen by the service provid-er. A change to the internal telephony infrastructure already inplace is not required.

Opening the voice network to IP services also brings manynew network-based services such as video conferencing, datasharing, virtual call centers, click-to-call back and click-to-call.

VoIP VPN Services

3.1 On-net to on-net callsThe core feature of the VoIP VPN service is to allow corpo-

ration sites to call each other as well as home workers over thevoice intranet. The IP network carries all telephony trafficamong corporate VPN sites and home workers. The architec-ture is also much more flexible when an office relocates, mainlybecause the same telephone numbers can be retained. VoIP also

facilitates the integration of various brandsof PBX’s.

The VoIP VPN architecture also allowsthe definition of a simplified dial plan thatcan span several different companies with avoice extranet.

3.2 On-net to off-netThe core VoIP VPN architecture should

include a set of least cost routing featuresallowing selection of the best terminationsaccording to load conditions and prices.The VoIP VPN uses the home DSL or cableconnection to extend the VoIP VPN reachinto the home office. Single-step dialling ispossible, and the user experience is thesame regardless of the size of the office.There are no local call costs, and each userbenefits from the discount plans negotiatedfor the entire VPN.

3.3 Off-net to on-netBasic off-net to on-net connectivity

allows endpoints in the voice VPN to becalled from the PSTN using direct exten-

sions. A VoIP VPN provides additional services such as VirtualLocal Extensions and Voice Remote Access Interactive VoiceResponse (IVR).

For multinational companies, travelling workers frequentlyneed to call their home office. By allocating virtual local phonenumbers for some VoIP extensions, the PSTN no longer has toroute calls to the home office in several steps over the PSTN.For example, it allows people travelling in Spain to call a localSpanish number rather than calling a long-distance number totheir home office in another country.

The virtual attendant service, Voice Remote Access IVR,allows travelling employees to dial a specific number that asksthem which internal VPN number they wish to call. With anoptional identification procedure, they can also be allowed tomake off-net calls at no charge or on a prepaid account.

3.4 Additional servicesA “Subscriber Policy Engine” service can be very beneficial

and can help reduce the difficulty of reaching people on themove by providing “follow-me” type of services. Roamingusers simply need to be allocated numbers in a recognisablerange. This service can be offered by the service provider as aspecific class of service for roaming users, without requiringany specific installation within the core VoIP VPN architecture.

“Unified Messaging” allows users to retrieve and managetheir voice mail as part of routine e-mail checks. This savestime and enhances the responsiveness of the entire organisa-tion. A Unified Messaging system can easily be added as partof the core VPN architecture, i.e., the offering of the serviceprovider, and should not require additional on-site hardware.

3

Fig. 1: VoIP VPN architecture

Voice over IP


Architecture

4.1 Overlapping dialling plans, group prefixesWith the number expansion strategy, the CCS Softswitch

learns the physical location of an IP phone through the registra-tion process. In the H.323 standard, the phone sends a registra-tion request message to the gatekeeper with its alias (name ortelephone number) and current IP address.

For example, if both groups A and B have a ‘1010’ extension,the CCS Softswitch needs to know that whenever a member ofgroup A dials ‘1010’, the call needs to be routed to the ‘1010’phone within group A, not group B. The correct strategy for im-plementing a VoIP VPN is to make the phone alias unique byadding a group prefix to each short telephone number.

If group A is assigned prefix 111 and group B is assigned pre-fix 222, then:• the ‘1010’ IP phone within group A registers as 1111010• the ‘1010’ IP phone within group B registers as 2221010

When dialling out from a phone in a VPN group, the H.323phone will use its registered alias as the Calling Party Numberinformation element of the H.225 Setup message used to estab-lish the call. By looking at the group prefix of the calling partynumber, any call from group A can be recognised.

Similarly, the corporate gateways connected to PBX’s mustadd the group prefix to the calling party number for any callrouted to the VPN network. This requires from the CCS Softs-witch implementing the VPN:• Simultaneous Source and Destination-based routing (ability

to also route a call based on the calling party number)• Calling Party Number and Called Party number expansion

and truncation. A variation in this configuration can be, for example, on net-

works with no IP phones (only gateways), it is possible to havea gateway add the group prefix to the Called Party Numberinstead of to the Calling Party number. This allows the imple-mentation of a VPN network with a gatekeeper that does nothave source-based routing capabilities.

Another strategy is to virtually isolate a VPN by using the listof H.323 ID’s of the gateways participating in the VPN. Thegatekeeper is provided with a list of H.323 ID’s for each gate-way. Therefore, whenever a call ar-rives from that gateway, it can de-cide to which VPN the call belongsand route it accordingly.

4.2 Communications with the public network

Most VoIP VPNs need to bereachable from the PSTN as well asbe able to dial out to the PSTN. Di-alling out to the PSTN is easy andonly requires an escape access codethat prevents mixing short VPNnumbers and short PSTN numbers.In Europe, this is usually the digit

‘0’. The only difficulty is in properly choosing the egress gate-way and in rewriting the Calling and Called Party numbers ac-cordingly.• In the Calling Party number, the VPN prefixes must be

replaced by the PSTN prefix. • In the Called Party number, the escape access digit must be

removed and the number needs to be rewritten according tothe local PSTN dial plan applicable in the country of theselected egress gateway.

• If a sequence of Direct Inward Dialling has been allocated tothe VPN, then it is also possible to dial-in. When the gate-keeper receives a SETUP message from a gateway, it needsto rewrite the Calling and Called Party numbers.

• The Calling Party number needs to be prefixed with theappropriate escape code.

• The Called Party number needs to be rewritten using theVPN group and site prefixes.

The PSTN gateways are now shared. Some VPN groups mayrequire a specific number of ports to be allocated for their ownuse.

4.3 Scalability, Upgradability, Availability The technologies that are used on the core VPN platform are

determined by the need of service providers to reach a criticaltraffic volume and negotiate better termination tariffs. The plat-form should support hundreds of calls per second while main-taining a very low call set-up time (in the 300ms range at most)at peak-loads. This precludes the use of relational databases inthe softswitch call processing. Relational databases can be usedonly for the provisioning architecture, but the softswitch itselfshould use only in-memory, real-time telecom-grade databases.User profiles should be retrieved from read-optimised servers.

Very specific route indexing techniques, which guarantee acall set-up time largely independent of the number of routes,should be used. The provisioning framework should allowcomplete automation of operations for adding and removingsites. This makes it necessary to offer a command line inter-face, in addition to graphical user interfaces, since most provi-sioning database frameworks use a shell interface with thirdparty systems. The softswitch system has to be hot-upgradable,

4

Fig. 2: A call example

COMPANY ASite 1

Group Prefix 111Site prefix 1

COMPANY ASite 2

Site prefix 2

1000

1010

1020

2000

Set up (CgPn 11111000, CdPn



Set up (CgPn 1020, CdPn 11121000)

Called Number (CdPn) starts with 1:we want to dial somebody in site 1.Therefore the number we want to call is really 11111010.

Called Number (CdPn) starts with 2:we want to dial somebody in site 2.Therefore the number we want to call is really 11122000.

Voice over IP


both in terms of capacity and in terms of software release. Serv-ices should never be interrupted.

The softswitch system should be able to resist any singlecomponent failure, including software switches. A monitoringsystem should be able to detect and report hardware, operatingsystem and application failures in almost real-time.

4.4 QoS – Quality Of ServiceIf transit delay in the IP network and packet loss can be con-

trolled, the voice quality of VoIP can be comparable to that ofPSTN.

In the corporation itself, on-site VoIP equipment and regulardata hosts should use two separate levels of QoS. In a LocalArea Network (LAN) architecture, the disruptions to a host bytraffic originating from another host can be minimised. Usingswitches or Virtual LANs already provides a sufficient level ofisolation. Under bandwidth constraints, voice packets shouldbe prioritised using a priority scheme for all User DatagramProtocol (UDP) packets, or only for Real-Time Protocol (RTP)packets. For the leased line between the corporation and thecore IP network, since it is usually under stringent bandwidthconstraints, it is vital to use priority schemes for voice packets.

At the network peering points, the best situation would beone in which all used the same IP network providers. If not,dedicated symmetrical bandwidth should be provided in orderto support the peering agreement among the networks. Publicpeering nodes and satellite links should be avoided.

Monitoring the physical integrity of all VoIP VPN compo-nents is essential in order to ensure a high service availability.A proactive monitoring approach, which continuously verifiesthe availability of the service at the application level, and canprovide near real-time reports to administrators, is preferable.

ConclusionUsing VoIP in place of circuit-switched networks can cre-

ate significant savings. In addition, the VPN feature allows thecore VoIP network to behave as a hub aggregating many differ-ent telephony services on the same backbone to offer servicesto the whole range of end-user devices. Quality of service iscomparable to PSTN, with additional services to come. Open-ing a telephony network to IP services affords the opportunityfor many additional, new, network-based services.

5

Voice over IP


VoIP in Public Networks: Issues, Challenges and Approaches

Francisco González Vidal

The present article introduces the basic problems found for conveying voice in a public environment,providing the quality of service the subscribers are currently used to. We schematically present the currentmethods for providing an estimation of the voice quality, as well as the performance of the current codingschemes and their interworking. A discussion about public network architectures based on VoIP follows, asan evolution scenario from the current Public Switching Network, Time Division Multiplex based, to thefuture Next Generation Network, Packet based. The network elements of the new paradigm are introduced:Softswitch, Trunk Gateway, Access Gateway. Finally, a brief description of a current project on DistributedAccess Gateways for supporting the above described evolution scenarios is presented.

Keywords: VoIP, QoS, Access Gateway, Next GenerationNetwork

Towards the Next Generation NetworkThere is an industry consensus that the telecommunica-

tion network of the future will have the following main traits:• Network intelligence will migrate to the periphery, either to

the user terminals or to servers where high level applicationsare located.

• There will be only one multiservice telecommunication net-work supporting all the current and future telecommunica-tion services.

• Data applications will be dominant with regard to bandwidthconsumption.

• As for the current state of the technology, IP is considered asthe network protocol of choice, the federating protocol.

Although the debate is open on some of these points, e.g.when video services were widely deployed would still dataapplications be so dominant in bandwidth? what kind of videoservices will be deployed? But the shift of the present voicecentric Time Domain Multiplexed network towards a packetparadigm seems to be clear. What it is still not clear is the paceand the shape this major change will take. In this article weaddress the challenges and issues that have to be confronted inoffering a voice service, more specifically, a voice service up tothe standards of current telephonic service in this new packetoriented scenario.

The paper is organized as follows. First, we present thequality issues that arise in conveying voice over packets,specifically on IP that seems to be the technology of choice.Then, we address the proposed architecture for the NextGeneration Network (NGN) from the point of view of the voiceservice. Finally, we describe a current project we are involvedin Alcatel for providing a Distributed Voice over IP Gateway on

top of an Integrated Multiservice Access Platform (IMAP).This approach is aimed at easing the migration from the currentTime Division Multiplexing (TDM) network paradigm to theNGN in a way that keeps the vast investment that operatorshave to do in the access environment.

1

Francisco González Vidal is Telecommunication Engineer, andhas a Ph.D., in the Universidad Politécnica de Madrid. He isAssociate Professor in the Information and TelecommunicationTechnology Department ETSI Telecommunication in Madrid. In1973, he joined Standard Eléctrica S.A., now Alcatel Spain,where he has developed his expertise in the Switching division(S12 and Broadband ATM). Presently, he is worldwide technicalDirector Access Systems of Alcatel.

high

best

medium

low

(very) poor

Traditional PSTN quality

5

4.5

4

3.5

3

2.5

2

1.51

0 10 20 30 40 50 60 70 80 90 100

Rating R

MO

S

Figure 1: Mean Opinion Source (MOS) and Rating factor (R) are used to measure subjective voice quality

Voice over IP


Voice Quality issues in an IP network

Voice quality is by nature a sub-jective matter that is measured by aset of currently standardised sub-jective tests. At present, two mainindicators are used to measurevoice quality:• Mean Opinion Score (MOS) in

a scale of 1 to 5• Rating factor (R) in a scale of 0

to 100Figure 1 shows how these two

indicators relate to each other. Wecan appreciate that voice quality intraditional Public SwitchedTelephony rates from medium tobest in performance. The subjec-tive quality of a telephone call as afunction of the network parametersis predicted with a model, calledthe E-model [ITU-T G.107]. TheE-model is expressed as:

R = R0 - Is - Id - Ie + AWhere:

• R0 groups the effect of noise, either background or circuitnoise

• Is includes impairments simultaneous to the voice signal:due to quantization, too loud a connection, too loud sidetone

• Id encompasses delayed impairments, included those causedby talker and listener echo or loss of interactivity

• Ie covers the impairments caused by the use of special equip-ment; for example, each low bit rate codec has an associatedimpairment value. This impairment value can also be used totake into account the influence of packet loss.

2Origin Standard Type codec bit

rate (kb/s)

voiceframe(ms)

lookahead(ms)

algorithmicdelay (ms) le Intrinsic

quality

ITU-T

G.711 PCM 64

0.125 0 0.125

0 94.3

G.726G.727 ADPCM

16 50 44.3

24 25 69.3

32 7 87.3

40 0.125 0 0.125 2 92.3

G-728 LD-CELP12.8

0.625 0 0.62520 74.3

16 7 87.3

G.729(A) CS-ACELP 8 10 5 15 10 84.3

G.723.1ACELP 5.3

30 7.5 37.519 75.3

MP-MLQ 6.3 15 79.3

ETSI

GSM-FR RPE-LTP 13 20 0 20 20 74.3

GSM-HR VSELP 5.6 20 0 20 23 71.3

GSM-EFR ACELP 12.2 20 0 20 5 89.3

Table 1: Intrinsic characteristics of standardized codex

x

x x x x x x x x x x x x x x x x xxx

x x x x x x x x x x x x x x x x x x x

90

80

70

60

50

40

30

20

10

0

100

0 100 200 300 400

Interactivity limit 150 ms

x

PSTNquality

ratin

g R

EL = 11 dBEL = 21 dBEL = 31 dBEL = 41 dBEL = 51 dBEL = Infinity

mouth-to-ear delay (ns)

Figure 2: Effect of echo attenuation (EL = Echo Loss) on the rating R assuming no packet loss

packet loss = 0.0

Voice over IP


• Term A is the expectation factor. It expresses the decrease inthe rating R a user is willing to tolerate in favour of the“access advantage” some systems have over wire-boundtelephony. As an example, the expectation factor for mobiletelephony is 10.

Two impairments mainly hamper the subjective VoIP quality:• The impairment Ie associated with the use of “special equip-

ment”, like coding or transcoding systems, or distortion, likethe one produced by packet losses.

• The impairment Id associated with the mouth-to-ear (M2E)delay, produced, for example, by the loss of interactivity orthe echo (talker and listener echo).

With regard to Ie, Table 1 shows the intrinsic characteristicsof standardized codecs. This table shows that the intrinsic qual-ity of most coding schemes is between medium to best per-formance (exceptions are ADPCM 16 and 24 kbps). Simula-tions performed in [De Vleeschauwer et al. 00] and [DeVleeschauwer et al. 99] show that transcoding is somethingthat must be avoided as much as possible.

Id is an important factor to take into consideration in packetbased networks, as delay will be always higher than in conven-tional public telephony networks. The delay introduced whenusing a packet networks to carry voice traffic is made of:• encoding-decoding delay (table 1), that is, the time needed

to code and decode a set of voice samples using a codecalgorithm,

• packetization delay, that is, the time needed to build a voicepacket. For example, in G.723.1, each voice packet carries30 ms of digitized voice (table 1),

• propagation delay, that is the time needed by electrical oroptical signals to propagate (most important in the case ofsatellite links),

• queuing and transmission delay, that is, the time taken totransmit packets through the network, and

• dejittering delay, that is the delay introduced by the use ofbuffers at the destination to absorb delay variations in packetnetworks.

We have seen that Id covers the impairments caused by talkerand listener echo, and the loss of interactivity. The first ones canbe treated by introducing echo control.

In Figure 2, we show the effect of echo attenuation (EL =echo loss) on the rating R for G.711 coding, assuming 0% pack-et loss. Note that, from 150 ms on, the rating decreases, due tothe perceived loss of interactivity. Values above 400ms areunacceptable.

Finally, in Figure 3, we can see the effect of packet loss onthe codec’s intrinsic performance, i.e. without accounting foradditional impairments. The beneficial effect of packet lossconcealment, i.e. a strategy to replace the lost packets is alsoshown. A more detailed discussion of the combined effects ofimpairments can be found in [De Vleeschauwer et al. 99].

Finally, we can conclude that offering interactive VoIP withPSTN quality is perfectly feasible for a set of standardizedcodecs provided that:• perfect echo control is performed as close as possible to the

source of the echo (a hybrid in the PSTN or a PC terminalwith low coupling loss),

• transcoding steps are avoided as much as possible,• IP network resources for voice are decently managed (so

that packet loss is low or negligible)• Mouth-to-ear delays are bounded, that is:

– voice packets get head-of-line over data packets in bothaccess and backbone networks,

– long data packets are segmented or interrupted as soon asvoice packets arrive (e.g. in low speed access networks)

x

x

x

x

0

10

20

30

40

50

60

70

80

90

100

0 2 4 6 8 10 12 14 16

PSTNquality

Intri

nsic

ratin

g R

int

packet loss ratio (%)

x

G.729(A) + [email protected] kb/s + VADGSM-EFRG.711 with PLCG.711 without PLC

Figure 3:Effect of packet loss on the intrinsic performance

PLC = Packet Loss Concealment

Voice over IP


– dejittering and packetiza-tion delays are properly en-gineered.

Next Generation Network Reference Model

In this section we concentrateon the network elements neededto provide the telephony service.We leave aside elements pertinentto other services like data andvideo, although some of the ele-ments can play a role in multime-dia scenarios that include voice.

Figure 4 represents the NextGeneration Network (NGN)reference architecture for provid-ing voice services. Note that wehave included in the picture thecurrent Public SwitchedTelephony Network (PSTN), aswell as the current telephone sets,as they are going to remain inservice for any sensibly foreseeable future (keep in mind thatPSTN world-wide has more than one billion main lines today).

In Figure 4 we can identify the main components of this newscenario, namely the Gateways and the Call Server:• Trunk Gateway (TGW): it performs at the bearer plane the

necessary transcoding functions from the coding used in thePSTN network (normally PCM G.711) to whatever coding

scheme we have decided to use in the packet network. In ad-dition, at the control plane it has to perform the signallinggateway function between the legacy PSTN signallingsystem, (nowadays normally based on ITU-T SignallingSystem N. 7) and the signalling system chosen for the NGN,H.248 in the figure.

3

AccessGW

CPEGW

Call Server

TGW

PSTN

IMAP

H.323

#7

DataATM, IP

H.248H.248

Figure 4: Next Generation Network (NGN) refer-ence architecture for voice services

Userpremises

DataATM, IP

AccessGW

Call Server

DataATM, IP

Access Edge Backbone

TGW

Userpremises

Userpremises

Access

Access

Edge

Edge

Backbone

Backbone

Call Server

EVOLUTION

Figure 5:Migration from the current network towards NGN

Voice over IP


• Customer Premises Equipment Gateway (CPEGW): this is the VoIP application residing on thecustomers premises that will be used in the finalscenario when all voice sets have become “IPphones”. In a near future VoIP gateways will beembedded either in IP-PABX or in IntegratedAccess Devices, both for business users (of asignificant size we should add). For the timebeing, VoIP Gateways for residential users arenot economically reasonable.

• Access Gateways: these elements concentrateusers having standard telephonic gear (analogueor digital phone sets, fax machines, keysystems, analogue or digital PABX). It performsthe corresponding gateway function both in thebearer plane, as we saw in the Trunk Gateway,as well as in the control plane, where the signal-ling conversion is done between subscriber sig-nalling system (either analogue or ISDN) andthe NGN signalling scheme, H.248 in thisexample.

To make this happen, a sensible migration path from the cur-rent network towards the NGN has to be planned. Currentindustry thinking favours an evolution starting in the backboneand progressing towards the user. Figure 5 provides a coarseview of this strategy.

Finally, we would like to add some considerations on theevolution scenario presented in Figure 5. In the case of newoperators without a large TDM installed base, some intermedi-ate steps in the evolution can be skipped. Of course, this willdepend on the starting point of the new operator, as almost noneof them start from scratch (typically all of them already have aTDM based backbone network).

If they come from the long distance interconnection business,they can start in a safer way from the intermediate step shownin the figure. Access Nodes providing traditional TDM

subscriber concentration functions, over e.g. standard V5.2interfaces, and with the capability to be enhanced with VoIPGateway functionality, will prove to be an invaluable tool tofacilitate the migration. In our opinion, the last equipments tobe migrated to VoIP should be the ones in customer premises,due to the economic impact of their volumes. Again, an inter-mediate node like the Access Gateway we describe in the nextsection, will help in making a business sensible transition.

An Integrated Multiservice Access Platform with VoIP Gateway embedded

Digital Line Concentrators (DLC) have been around sincelong ago as a mean to extending the reach of Local Exchangesin such a way that they can cover larger areas of service, inparticular, when covering disseminated population distribu-tions. In principle, a DLC is a remote switching unit that is

4

LL/TDM

PSTN

ATM

IP

Network side

Mirror/V5.1/V5.2

PDHn x 2MBPSCun x 2MBPS FO

SDH- VC3

ATM/SDHSTM1

ATM/IMA

Customer side

POTS

ISDN BAISDN PRA

2Mb/sNx64 kb/s< 64 kb/sAnalog LL

ADSLSDSL

HDB3or

HDSL

Litespan-1540

Figure 6: Integrated Multiservice Platform (IMAP)

Aggregate

BBcontroller

NBcontroller

SDH

STM1/4ptpt & ring16 x 2 Mb opticG.FSAN PON

PDH

PDH

2.4 Gb/s 16 x 155 /622 Mb/s

2 x 155 Mb/sATM2 x 51 Mb/s

TDM

(4+1)x 8MBPS

NB LIMs

BB LIMs low traffic(e.g. ADSL)

BB LIMs or BB Server Cardshigh traffic(e.g. STM-1, APON)STM-O, VDSL

NB/BB LIMs(e.g. ADSL/POTS)

Server Cards(e.g. VOIP, FR)

Figure 7:Internal architecture of IMAP

Voice over IP


controlled from a Local Exchange, and that provides eithermultiplexing or better concentration of telephony calls forsaving transmission resources between the remote location andthe exchange.

DLCs have evolved in some important ways:• Providing standard signalling interfaces to the Local

Exchange (e.g. GR-303, V5.1/2), that has made independentthe access nodes from the switches, and as a consequenceopening the access market.

• Integrating different transmission technologies towards theexchange (copper, fibre, PDH, SDH), i.e. the same concen-trating electronic node can incorporate whatever transmis-sion technology is best suited to the deployment scenario.

• Providing a full set of user interfaces for supporting differentservices: from traditional telephony service (POTS), narrowband digital integrated services (ISDN), to any flavour ofleased lines for narrow band data: data n x 64kbps, subrates,analogue data, etc.

• Providing the grooming of telephony and data services, i.e.the separation (network direction) of these services to thecorresponding overlay network.

• Integrating Broadband Access: ADSL, HDSL, SDSL, …xDSL, which constitutes the major evolutionary step inthese new generation access elements.

This conforms what is known as the New Generation DigitalLoop Concentrators, or as we name it in this paper, an Integrat-ed Multiservice Access Platform (IMAP). Figure 6 showsschematically this IMAP definition (see also reference[González Vidal 00]).

The internal architecture of an IMAP will support the follow-ing design principles, in order to provide an Operator with thenecessary flexibility for its network application:• Universal shelf and Universal slots, for subscriber and

network sides: for providing the required flexibility when

planning and dimensioning the access network, as the pene-tration of each type of service is very difficult to predict, andvaries from application to application.

• Fully redundant: carrier grade, compliant with the stringentreliability requirements that public telecommunicationnetwork adheres to.

• Designed for in/outdoor configurations• Standard compliance: in both signalling and management,

to provide the basis for an open market in the accessIn the platform we have developed, we have made provision

for server cards, that can be located in a universal slot position.These server cards are based on digital signal processing tech-nology and are programmed to provide VoIP, FoIP (Fax overIP), voice band data over IP. The server can also be pro-grammed to work as a Modem Bank for providing dial-up IPservice for analogue modems.

The internal architecture of the platform under discussioncan be seen in Figure 7. Figure 8 shows the physical aspect ofthe implementation.

In our approach, TDM calls are terminated in the serverboard, where the bearer plane conversion takes place from64kbps PCM channels to the voice coding scheme chosen inthe IP network. Then, the voice is packetized and sent overRTP/ IP/AAL5/ATM. Packetized voice over ATM is multi-plexed with data on ATM coming, for instance, from the ADSLLine Modules. ATM has been chosen as the best way to provideQoS in the access domain, and providing service multiplexing.

As for the control plane, subscriber signalling is terminatedin the narrow band controlled and converted to access signal-ling (V5). The server card provides the interworking betweenthis TDM signalling and the H.248 signalling towards the CallServer.

One important feature of this approach is that we can provideconcurrently VoIP and traditional TDM services, by provision-

BB c

ontro

ller

BB c

ontro

ller

NB

cont

rolle

rN

B co

ntro

ller

Aggr

egat

e Tr

ansm

issi

onAg

greg

ate

Tran

smis

sion

Fram

e R

elay

Ser

ver

Voic

e ov

er IP

ser

ver

ADSL

LIM

POTS

LIM

ISD

N B

RA

LIM

ISD

N P

RA

LIM

HD

B3 tr

ansm

issi

on2M

ATM

IMA

LT2M

/ n

x 64

k LI

MSD

SL L

TxD

SL L

T4

/ 16

X 2

Mbi

t opt

ical

LT

HD

SL L

T=

< 64

kbi

t / s

loca

l int

erfa

ceAT

MFo

rum

25

Mbi

t / s

Frontal Access

• STM1/4• add/drop• PDH• optical

Aggregates

Servercards

Linecards tributaries

LocalIntf.

Lite

span

– 1

540

Universal slots

Figure 8: Physical aspect of the IMAP implementation

Voice over IP


ing those subscribers we can serve with either technology. Thisfeature provides a safe evolution path for operators migratingtowards a voice packet network. We sketch this feature inFigure 9.

ConclusionsQuoting a high rank industry guru, “The only thing we

can be sure about Telecommunications future is that we cannotpredict it” we believe that there is a strong trend towards apacketized multiservice network. Most likely, this network willbe based on Internet Protocol. the challenge is to replace themore-than-a-century-old telephony service.

In this paper we have briefly discussed some of the issues weare confronted to: • what are the requirements that we have to put on IP networks

for conveying voice with the adequate quality?• what are the present models the industry is working on?• what is the shape this Next Generation Network is going to

have and what are its basic constituent elements? and • what can be the evolution path from the current networks to

the future ones?Finally, we have described a network element that can play a

major role in this transition period, that, for sure, will be long

lasting, and that, in our view, it is a crucial piece in making thisevolution economically sensible.

References[ITU-T G.107]

ITU-T Recommendation G.107, The E-model, a computationalmodel for use in transmission planning.

[De Vleeschauwer et al. 00]D. De Vleeschauwer, J. Janssen, G.H. Petit and F. Poppe, “Qual-ity Bounds for Packetized Voice Transport”, Alcatel TelecomReview, 1st Q2000.

[De Vleeschauwer et al. 99]D. De Vleeschauwer, J. Janssen, G.H. Petit, “Voice over IP inAccess Networks”, Proceedings of the Seventh IFIP Workshopon Performance Modelling and Evaluation of ATM/IP Networks,Antwerp (Belgium), 28-30 June 1999.

[González Vidal 00]F. González Vidal, “Plataforma de Acceso Multiservicio: unseguro de la inversión frente a las incertidumbres de evolución delmercado de las Telecomunicaciones”, Infrastructure & Applica-tion Summit, ITU Telecom Americas 2000.

AcknowledgementsFigures 1, 2, 3, and Table 1 are courtesy of the Alcatel Telecommu-

nications review.

5

Alcatel 1000 S12/E10Other supplier’s switch

Alcatel 1000Call Server

Access gatewayIP Plug-in Gateway Board

V5(+)TDM

IP/ATM

LL/ATM/IPnetwork

MGCP Megacosignalling

TDM

+ ATM

+ IP/ATM

Services

POTS

ISDN

Data

xDSL

voice-IPfax-IPmodem-IP

Figure 9:IMAP provides concurrently VoIP and conventional TDM services

Voice over IP


Voice Communication over the Data NetworkConvergence of Services by LAN Telephony

Robert Bertels

In the past, voice and data traffic were transmitted over completely separated systems. Today, voicecommunication can be carried on an local data network by means of the Internet Protocol (Voice over IP orLAN Telephony). As a result, in new buildings at least, a telephone network as such is no longer necessary.

Keywords: VoIP, Internet Telephony, Convergence of Com-munication Services, Integrated Business Solutions, Quality ofService.

In today’s office, access to the local data network is as impor-tant and normal as the telephone connection. On both net-works, information is transmitted in digital form. Yet, in mostcases, voice and data are carried over entirely distinct systems,a relic of the time when telephony used analogue signal trans-mission and computers were at an early development stage.

Voice and data on the same networkCurrent developments mean that the separation between

voice and data transmission is no longer necessary inside acompany. Local Area Network (LAN) telephony (better:Intranet telephony or VoIP) is a reality. The telephone receivercan be connected to a desktop PC and calls between offices canbe made over the local data network, with no telephone lineinvolved. Voice and data service have converged with bothusing the same network, opening up a basis for “IntegratedBusiness Solutions”.

Until recently, rapid progress with VoIP was predicted, alongwith an early end to conventional telephony. In the light of realexperience, such euphoria has given way to a more realisticassessment: VoIP does not yet offer the same mix of functionsand services as conventional telephony (except at very greatexpense) and the technical standards indispensable for a break-through at the global level are not yet in place. There is also alack of know-how and experience among many vendors andpotential customers. In addition, the development of VoIP isaffected by the cultural chasm that exists between telephoneand computer worlds as demonstrated by the fact that responsi-bility for voice and data transmission is divided between differ-ent departments in many companies. Despite this, the potentialof VoIP should not be underestimated.

In new office buildings it can already make sense to dispensewith the installation of a telephone system with exchanges andlines and use the internal data network instead for the transmis-sion of internal telephone calls. For outside calls, a simpleinterface (gateway) is sufficient to provide a telephone service.At the new headquarters of Bison Switzerland AG (a computercompany, at the time Agro Data AG) in Sursee (Switzerland),this new technology has been installed. Each work station has

been equipped with a PC that also serves as a telephone. Bisonadopted this revolutionary approach because of the obviousadvantages of VoIP, namely:

• simple installation and administration,• fast installation of new system features as well as easy

upgrading (only software changes are required),• open interfaces to other systems and applications (e.g. cus-

tomer administration). In existing buildings with conventional telephone systems

not yet fully depreciated, total conversion is not essential and amore gradual transition to the new technology to meet currentpriorities is recommended. A typical example is the publisherof the Neue Zürcher Zeitung. The company’s customer carecentre was equipped with an LAN-supported communicationssystem at the end of 1999. Calls from the subscribers are nowdirected into the local data network and answered from compu-ter terminals on which the customer’s data is immediatelyavailable on screen. Because it was possible to integrate theVoIP system into the existing workflow software, investmentcosts were relatively low. The advantages show on two levels: • improved efficiency and quality of service, fewer customer

complaints and subscription cancellations.• from the operational point of view, the improved work envi-

ronment means lower employee turnover with a consequentreduction in training costs and less need for temporaryworkers.

As both factors have such positive economic effects, the sys-tem will pay for itself inside a year.

In simple terms, the model can be described as follows: theconventional local telephone system with its switchboard, tele-

Robert Bertels is head of the Venture Group for VoIP & CallCentre of Siemens Switzerland AG. He is responsible for thesales of the VoIP and Call Centre activities in the area SiemensSwitzerland Enterprise networks. <[email protected]>

Siemens has been operating in Switzerland for more than hun-dred years. Its main area of activity is communication where itsresearch and production function employs more than thousandpeople. It is thus one of the largest development centres in Swit-zerland. The business unit, Enterprise Networks, develops con-cepts and supports customers’ technical installations.

Voice over IP


phone lines and the usual multifunctional telephone hand setsremains in operation throughout the office, except for the cus-tomer care centre. The local data network between individualworkstations is also in place. In the customer care centre (andonly there), the conventionaltelephone infrastructure ismissing. PC workstations areequipped with a telephone re-ceiver and the correspondingsoftware to support the voicetransmission. The interfacebetween the two networks is anumber of special gateways.The end result is that, after thechange, there appears to be nodifference in “telephone”usage and quality comparedwith the previous situation.

Strategic projectCompanies considering the

possibility of a gradualchange to VoIP would be welladvised to treat such a project as a high priority strategic one.Migration paths and speed must be optimised to ensure that thecompany’s business processes are fully supported in eachphase of the change if a positive added value is to be achieved.The choice of the system vendor is of particular importance.The vendor must be competent in both data transmission andconventional telephony to guarantee that the existing telephonesystem remains an effective element of the overall system dur-ing a possibly long transition period. All this involves concernfor operational matters and the need to protect existing invest-ment. In Switzerland, many companies have very modern andefficient telephone systems which, with the necessary exper-tise, can easily remain in operation until the initial investmenthas been paid back.

The problem Conventional telephony is based upon the transmission of

voice data over a dedicated line. In contrast, data transmissionover the LAN is more flexible but also more difficult to control.

On the LAN, information is chopped in small packets whichmay reach their destination via different paths. If the -networkbecomes overloaded, packets might be delayed and arrive outof sequence. Packets can also get lost or destroyed and must be

resent until they have all reached their destination. Once there,they are then recombined in the correct sequence. This processnaturally takes time.

In the case of pure data this is not a problem. Voice data, how-ever, needs to be transmittedinstantaneously. There shouldbe no perceptible time differ-ence between what is spokenat one end of the line and whatis heard at the other. suchinstantaneous transmissionwas not part of the originalLAN specification but effortis now being made to achievesuch a level of service. Thisincludes greater bandwidthand its effective management,redundancy to obtain lowerfailure rates, and prioritiza-tion of voice data with the aimof guaranteeing a full tele-phone quality of service. VoIPhas already been successfully

implemented in many company Intranets, and is well on theway to becoming the generally accepted solution in the WideArea Network field too.

References[Davidson/Peters 00]

Jonathan Davidson und James Peters. Voice Over IP. Grundlagen,Konzepte, Technologien, Anwendungen. Cisco Press, 2000 (ISBN 3827258006)

[Douskalis 99]Bill Douskalis. IP Telephony. The Integration of Robust VoIPServices. Prentice Hall, 12/99 (ISBN 0-130141186).

[Foth 01]Egmont Foth. Handbuch IP-Telefonie. Fossil Verlag, Köln, 2001(ISBN 3-931959-33-3).

[Goncalves 98]Marcus Goncalves. Voice over IP Networks. McGraw Hill, 1998(ISBN: 0-07-913783).

[Held 98]Gilbert Held. Voice over Data Networks. Covering IP and FrameRelay. McGraw Hill, 1998 (ISBN: 0-07-028135-1).

[Karapetkov 99]Stefan Karapetkov. Siemens Information and Broadband Net-works. November 30, 1999

[Minoli 98]Daniel Minoli. Delivering Voice Over IP Networks. Wiley Cana-da, 1998 (ISBN: 0-471-25482-7).

Voice over IP


IP telephony for enterprisesBecause of possible significant cost

advantages for long intercontinental calls,private users welcomed the facility to com-municate between PCs around the globe(often pre-arranging the session by tele-phone.). This is not practicable for enterpriseswhose average calls, lasting but a few min-utes, require an on-demand connection.

IP telephony gateways offer the solution:they do not just link individual terminals suchas PCs together over the LAN, they link com-plete telecommunication systems at differentlocations. The familiar infrastructure (tele-phone, performance characteristics and dial-ling behaviour) is preserved for the users.But, imperceptible to the user, the call is rout-ed by the telecommunication system over an

IP telephony gateway and the LAN, with thehelp of the Least Cost Routing (LCR) func-tionality.

Practically, professional users require-ments cannot be provided solely by the LANwith its ever varying capacity, delay and jitter(variation of the delay). This is why IP tele-phony gateways are today predominantlyfound in the companies that are equippedwith sufficient bandwidth in their own corpo-rate intranet. Whether this voice/data integra-tion occurs in the corporate backbone, overthe IP protocol, frame relay (FR), or ATMdoesn’t matter. What does matter is the savingin telephone costs that can be realised in thelong-distance domain. The necessary invest-ment – an IP telephony gateway at each loca-

tion – rapidly pays off despite the rate reduc-tion arising from the current liberalisation ofthe German telecommunication market. Thisis especially true when the call is to a foreignlocation. It is a great advantage of the IPtelephony that only one gateway is necessaryat each location – the routing is taken over bythe LAN. Classical implementation of corpo-rate networks requires either complete net-working of all the locations, or implementa-tion of a switching node at selected locations(with the attendant problems during multiplecompression). The prerequisite is, always,that sufficient bandwidth is available in thecorporate LAN.

IP telephony for carriersBoth companies with a corporate LAN and

Internet Service Providers (ISP) operateessentially the same network, but there is adifference: The corporate LAN is there tosave costs, the ISP wants to earn money, andone way of doing that is to offer added valueservices. To earn more money the ISP willoffer more and more voice communicationover the Intranet and will evolve into anInternet Telephony Service Provider (ITSP)and end up in direct competition with the con-ventional telecommunications companies.Technically, the ITSP functions like the cor-porate LAN, i.e. routers and IP telephonygateways are installed within the access area.These are usually located at customer sites,like the access routers, and they are directlyconnected to the customer telecommunica-tion system. Since an ITSP is aimed at a het-erogeneous clientele, it normally supportsonly standard interfaces with its IP telephonygateway, such as E-DSS1. Further location-independent services are not normally sup-ported.

Conventional telephone companies react tothe ITSP threat by doing the opposite: they

retain and use the existing infrastructure (i.e.the normal telephone connection) in theaccess area, but use the Internet (or the sec-tion of it administered by themselves) forcheap transmission within the long-distancetraffic area.

To do this, they equip their large switchingnodes with IP telephony gateways, but unlikethe IP telephony gateways described so far,they differ in dimension. In this context it isinteresting to speculate upon the impact of thedeveloping the tariff policy. For instance It isconceivable that the quality of the telephonecalls routed over the Internet will become sogood (due to the control conventional tele-communication companies have over parts ofthe Internet) that the user perceives no differ-ence between voice communication overlines and the packet switched transmissionservice. Another possibility is that calls viathe IP backbone will be offered at a lowerprice because of the subjectively lower quali-ty. In this way the conventional telecommuni-cation companies would secure a portion ofthe low cost telephone market present muchstiffer competition to the ITSPs.

However, future competition will not onlybe based on price, because this would harmall stakeholders, anyway the prices of conven-tional telephony and IP telephony will contin-ue to converge. It is not yet necessary for aITSP to hold a license according to telecom-munication law. Should this change, thelicense and its incumbent costs (e.g. monitor-ing) would result in an inevitable price rise.More likely value added services (VAS) willcome to predominate and conventional tele-communications companies and the ITSPswill be offering more and more of these. AllVAS share the need for an interactionbetween the Internet and telephone networkon the signalling level, i.e. in the characterchannel No. 7; appropriate products arealready being developed or are already avail-able. As the smooth integration of the IPTelephony into the intelligent network (IN)continues, so will IP telephony lose its repu-tation of “second class telephony” and devel-op into an acceptable alternative with its owndistinct profile.

Voice over IP


Glossary of Acronyms and Technical Terms

AcronymsATM

Asynchronous Transfer ModeCCITT

Consultative Committee for International Telegraph and Telephone

CPECustomer Premises Equipment

CTIComputer Telephony Integration

DiffServDifferentiated Services Internet QoS model

DNSDomain Name System

E.164ITU-T recommendation for international telecommunication numbering, especially in ISDN, BISDN, and SMDS.

ENUMTelephone Number Mapping

FDMFrequency Division Multiplexing

FoIPFax over IP

H.323ITU-T standard for real-time interactive voice and videoconferencing over LANs and the Internet.

IETFInternet Engineering Task Force

IGMPInternet Group Management Protocol

INIntelligent Network

IntServIntegrated Services Internet QoS model

IPInternet Protocol

IP MulticastExtension to Internet Protocol to support multipoint communications

IPBXInternet Protocol Private Branch Exchange

IPSecIP Security Protocol

ISDNIntegrated Services Data Network

ISPInternet Service Provider

ITSPInternet Telephony Service Provider

ITU-TInternational Telecommunications Union -Telecommunication

LDPLabel Distribution Protocol

LSRLabel Switching Router

MBONEMulticast Backbone

MCUMultipoint Control Unit

MEGACOMedia Gateway Control

MGCPMedia Gateway Control Protocol

MOSMean Opinion Score

MPLSMultiprotocol Label Switching

OLROverall Loudness Rating

PBXPrivate Branch Exchange

PHBPer Hop Behaviour

PoPPoint of Presence

POTSPlain Old Telephone Service

PPPPoint to Point Protocol

PSTNPublic Switched Telephone Network

QoSQuality of Service

RASRegistration, Authentication and Status

RSVPReservation Protocol

RTCPReal Time Control Protocol

RTPReal Time Protocol

SAPSession Annunciation Protocol

SCNSwitched Circuit Network

SDPSession Description Protocol

SIPSession Initiation Protocol

SLAService Level Agreement

SS7Signalling System Number 7

STMRSide Tone Masking Rating

TCPTransmission Control Protocol

TDMTime Division Multiplexing

TIPHONTelecommunications and Internet Protocol Harmonization Over Networks

UDPUser Datagram Protocol

UMTSUniversal Mobile Telephone System

VLANVirtual Local Area Network

VPNVirtual Private Network

xDSLOne of the Digital Subscriber Line Technologies, like ADSL.

Voice over IP


Technical TermsJitter

A term that refers to the amount of variation in delay that a network introduces. A network with zero jitter takes exactly the same amount of time to transfer each packet of information, while a network with high jitter takes much longer to deliver some packets than it does others. Jitter is important when sending audio or video, which must arrive at regular intervals to avoid jerkiness or unintelligible sounds.

SoftswitchA softswitch is essentially a software that performs the functions of a telephone switch. It replaces the circuit switch, emulating many of its functions in directing voice traffic but adding flexibility and features unique to packet traffic.

VoIP, IP TelephonyVoice over IP. A method of sending voice information over a packet-switched network, such as the Internet, using TCP/IP.

GatewayA device used to connect networks which use different communication protocols so that information can be passed from one to the other. A gateway transfers information and converts it to a form compatible with the protocols used by the second network for transport and delivery. In VoIP, two main types of gateways exist: Media Gateways, to convert

voice data; and Signalling Gateway, to convert signalling (control) information.

GatekeeperAn H.323 entity on the network which provides address translation and controls access to the network for H.323 terminals, gateways, and MCUs. It may also provide other services such as locating gateways.

Circuit switchingA switching technique in which a dedicated channel (or circuit) is established for the duration of a transmission. The most ubiquitous circuit-switching network is the telephone system, which links together wire segments to create a single unbroken line for each telephone call.

Packet switchingA switching technique in which messages are divided into packets before they are sent. Each packet is then transmitted individually and can even follow different routes to its destination. Once all the packets forming a message arrive at the destination, they are recompiled into the original message.

CodecA software algorithm used to compress/decompress speech or audio signals. They are characterized by several parameters like the bit rate, frame size, processing delays, etc.

Examples of typical codecs used are G.711, G.723.1, G.729 or G.726.

ExtranetAn extranet is a network that allows a company to share information within its Intranet with other businesses and customers. Extranets transmit information over the Internet and include strong security mechanisms in order to protect the data on internal company servers.

ImpairmentsThe effects that degrade the voice quality when transmitted over a network. Typical impairments are caused by noise, delay, echo or packet looses.

RouterThe basic node of an IP network. It is in charge of forwarding packets (datagrams) to other routers or to their destination in case it is directly accessible.

IntranetAn intranet is basically an internal network based on TCP/IP protocols and applications designed to be used within the confines of a company, university, or organization.

Referenceshttp://www.evar.com/voip_glossary.htmlhttp://www.netspeak.com/tools/glossary.htmlhttp://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/

index.htmhttp://webopedia.lycos.com/

Documents

Voice over IP - cepis.org Naming and Addressing in Voice over IP Networks ... The distinction between voice and data communication has been a ... “ﬂat cost” schemes of the Internet