Voice Service Interworking for PSTN and IP Networks

T e c h n i c a l P a p e r

11

Voice Service Interworking for PSTN and IP Networks

Contents

Introduction 2

Voice Service Interworking 3

Five Scenarios for Voice Communications 3

The PSTN Voice Service 4

Voice Services over IP 4

H.323 Systems 5

Hybrid Voice Services 6

Signaling and Control 7

Signaling Adaptation Functions 7

SS7 Interoperability 7

Addressing 9

Media Control Functions 10

Media Adaptation Functions 11

QoS- and IP-Based Networks 11

QoS and End Systems 12

Management Issues 14

Service Creation 14

OAM-Like Features 14

Network and System Management 15

Policy Management 15

Security 15

Dependence on the Regulatory Framework 16

Conclusion 16

Acknowledgment 16

References 17

Voice Service Interworking forPSTN and IP Networks

By M. Hamdi, EPFL; O. Verscheure, EPFL;

I. Dalgiç, 3Com Corporation; J.-P. Hubaux,

EPFL; and P. Wang, 3Com Corporation

In recent years, the Internet has proven its abilityto carry real-time data, including voice. Today, asmall amount of voice traffic has already beendiverted from the public switched telephone net-work (PSTN) to the Internet. If it expands, thisphenomenon could completely change the rules ofthe game for telecommunications.

This paper presents an overview of the maintechnical problems to be addressed for the provi-sion of interoperable services between IP tele-phony and the PSTN. The pivotal element of thesolution resides in an interworking function(IWF). This function is typically implemented ina gateway whose requirements and behavior arehere analyzed in terms of signaling and controlprotocols (control plane), user data transfer (userplane), and management features (managementplane).

The presentation is structured around thesethree planes. The control plane defines the set ofsignaling protocols to be used in each networkingcontext and the translation between them.Detailed scenarios illustrate the signal translationin the gateway allowing for the establishment ofa hybrid phone call. The user plane is responsiblefor adapting the user data to the properties ofeach network channel and determines the Qual-ity of Service (QoS) of the voice call in terms ofdelay and speech quality. In the managementplane, the issues of network, service, security, andpolicy management are discussed.

Introduction

IP telephony is becoming a very successfulvoice technology as evidenced by the burgeon-ing market for computer-based telephonyproducts. This was enabled by recent advancesin different technologies. In the signal process-ing field, new speech compression standardsallow voice signals to be coded at very low bit

rates while keeping their quality acceptable forconversational services. Moreover, the increas-ing bandwidth in IP access networks associ-ated with the increasing routing capacity inthe IP backbone makes it possible to reach aninteractivity level similar to that offered bycircuit switched networks. In addition, thedramatic growth of IP terminals with expand-ing processing power, memory, and multime-dia capabilities allows IP-based voice servicesto be deployed on a very large scale.

On the other hand, the PSTN has madevery impressive achievements in terms of cov-erage, reliability, and ease of use. The numberof lines is still increasing today, and will soonreach the milestone of one billion. The avail-ability of the service is such that users areaccustomed to receiving dial tone every timethey pick up the phone and to being con-nected to any selected called party. PSTN ter-minals are also usable by most disabled peopleand people with limited education. In addi-tion, the telephone network is being extendedby cellular networks, which have alreadyattracted more than 200 million subscribers;this growth is almost as dramatic as that of the Internet.

Matching these features with a fully IP-based network is a major engineering chal-lenge. Meeting it may take several decades; infact, there is no consensus today that this willever happen. Some portion of the voice ser-vices currently offered by the PSTN will cer-tainly migrate to an IP-based technology.However, IP telephony and PSTN serviceswill coexist for a considerable time.

For these reasons, the ability to intercon-nect IP telephony users to PSTN users isessential. This paper discusses the mainaspects of interworking between IP telephonyand PSTN voice services.

Two main standardization approaches arebeing carried out for IP/PSTN interworking.In the IP world driven by the Internet Engi-neering Task Force (IETF), interworking withthe PSTN has been the result of a logicalextension to the IP telephony service, which is

22

Acronyms andAbbreviations

API

application programming

interface

BISDN

Broadband ISDN

CLS

controlled load service

COPS

Common Open Policy

Service

DiffServ

Differentiated Services

DMTF

Desktop Management Task

Force

DSS1

Digital Subscriber Signaling

System No. 1

DTMF

dual tone multifrequency

ETSI

European

Telecommunications

Standards Institute

FEC

forward error correction

GS

guaranteed service

IETF

Internet Engineering Task

Force

IMTC

International Multimedia

Teleconferencing

Consortium

IN

intelligent network

IntServ

Integrated Services

IP

Internet Protocol

IRQ

Information Request 1 A modifed version of this paper appeared in IEEE Communications Magazine, Vol. 35, No. 5, May 1999.

seen as one of many IP applications. AVT,IPTEL, MMUSIC, and PINT are the mainIETF working groups concerned with IP tele-phony. In the telecommunications world, theInternational Telecommunication Union/Telecommunication Standardization Sector(ITU-T) and the European Telecommunica-tions Standards Institute (ETSI) are the maincontributors in terms of standards and pre-standard documents.

The ITU-T has initiated various stan-dardization activities (for example, see [11][12] [13] [14] [15]) that captured the atten-tion of most of the industrials involved in thefield. Related to these standards, the ETSIproject Telecommunications and Internet Pro-tocol Harmonization over Networks(TIPHON) undertook the effort to identifyadditional technical agreements required forthe interoperability between IP networks andcircuit switched networks [4]. Some industrialconsortia such as the International Multime-dia Teleconferencing Consortium (IMTC)through its Voice-over-IP (VoIP) group alsoprovide recommendations related to theimplementation interoperability that isrequired in a multivendor context [8].

In this paper, we analyze the mainrequirements for interworking between IPtelephony and the PSTN services. Illustrationsare based on the H.323 standard. For clarity,the interworking features are organized inthree planes: the control plane, the user plane,and the management plane. Control planeinterworking defines the set of signaling pro-tocols to be used in each networking contextand the translation between them. User planeinterworking is responsible for adapting thevoice data to the properties of each networkchannel and determining the Quality of Ser-vice of the voice call in terms of delay andspeech quality. In the management plane, wepresent a brief overview of main managementaspects in the context of hybrid voice services.

The paper is organized into sections asfollows: “Voice Service Interworking” defineshybrid voice services and gives basic commu-nication scenarios for IP/PSTN interworking.The PSTN/ISDN protocols and H.323 sys-tems are briefly reviewed. The interworking

features in the control plane are described inthe section titled “Signaling and Control,” inwhich we discuss signaling adaptation,addressing, and media control functions. Userplane interworking is discussed in “MediaAdaptation Functions.” The impact of endsystems and network design is analyzed interms of speech quality and communicationinteractivity. In “Management Issues,” we discuss some aspects of the management planeand related open issues.

Voice Service Interworking

Interworking of IP and PSTN voice servicescan be considered as part of a much biggereffort undertaken by standardization bodies inthe field of network and service interworking[3] [5] [23]. The most obvious interworkingscenario between IP and the PSTN is whenthe PSTN connection is used as a lower datalayer by the access part of an IP network (forexample, dial-up access to an Internet serviceprovider). We rather focus on service inter-working, and more specifically on interwork-ing of voice services. In the context of PSTNand IP telephony services, interworking is theability to offer a broader service that resultsfrom their peer juxtaposition. For the remain-der of the paper, voice services resulting fromthis interworking will be referred to as hybridvoice services. More concretely, hybrid voiceservices provide connectivity between users ofboth networks as well as between users of thesame network given that part of the commu-nication uses the service of the other network.Therefore, hybrid voice communicationsinvolve both PSTN and IP voice servicesand/or both types of terminals.

In this section, we describe five basic sce-narios for voice communications. We considervoice services over the PSTN and the IP net-work, as well as hybrid combinations. Also, weprovide a brief overview of the H.323 standard.

Five Scenarios for Voice Communications

Figure 1 on page 4 illustrates five basic voicecommunication scenarios. Hybrid voice ser-vices are represented by scenarios 3, 4, and 5.In these scenarios, an interworking function(IWF) is needed to perform all protocol

33

IRR

Information Request

Response

ISDN

Integrated Services Digital

Network

ITU-T

International

Telecommunication

Union/Telecommunication

Standardization Sector

IWF

interworking function

MGCP

Media Gateway Control

Protocol

MIB

management information

base

N-ISUP

Narrowband ISDN User Part

OAM

operations administration

and monitoring

PCM

pulse code modulated

PSTN

public switched telephone

network

QoS

Quality of Service

RAS

Registration, Admission,

and Status

RSVP

Resource Reservation

Protocol

RTP

Real-Time Protocol

SIP

Session Initiation Protocol

SNMP

Simple Network

Management Protocol

TCP

Transmission Control

Protocol

conversions and data adaptations. The IP andPSTN areas represent a protocol concept and do not necessarily involve a real network.Therefore, an IWF device may be used to con-nect two networks (i.e., a network adaptor) or aterminal to a network (i.e., a terminal adaptor).

For voice services, the IWF provides thefollowing mechanisms: • Signaling adaptation consists of the process-

ing and translation of incoming signalingmessages. It mainly concerns the call setupand clearing phases.

• Media control consists of identifying, pro-cessing, and translating service-specific con-trol events that may be generated by theuser or the terminal.

• Media adaptation consists of adapting thevoice data to the data transfer channel of thedownstream network.

The PSTN Voice Service

In scenario 1, two standard phone sets areconnected via the PSTN. Although wellknown by the communications community,we briefly review the main PSTN characteris-tics that will be crucial to further discussion of interworking concepts.

The PSTN core network is based on a circuit switched network in which each circuitcorresponds to a 64 Kbps digital channel. APSTN terminal can be either digital or analog.Standard phone sets are attached to the PSTNby means of an analog access network, which

merely corresponds to the set of subscriberloops (the copper wires that link the cus-tomers to the central office). On an analogaccess network, voice is transmitted as a 3 kHzwideband analog signal and is digitized at theaccess switch. In this case, signaling capa-bilities on the analog part of the access net-work (for example, address notification) arereduced to in-band coding of dual tone multi-frequency (DTMF) tones.

ISDN allows voice terminals to have digi-tal access to the PSTN. In this case, a digitalvoice terminal (or an analog terminal attachedto an adaptor) initiates a signaling dialogusing Q.931 (or the Digital Subscriber Signal-ing System No. 1, DSS1) to connect to thenetwork via a 64 Kbps digital channel. Signal-ing inside the digital core network is based onthe Signaling System No. 7 (SS7). An ISDNterminal seamlessly calls an analog PSTN terminal and vice versa. A unified addressing system is defined in ITU-T RecommendationE.164 [9].

Finally, one essential feature of the PSTNis its service creation and control capabilitiesreferred to as intelligent network (IN) [17].Basic services such as call forwarding rely onthe IN architecture.

Voice Services over IP

Scenario 2 illustrates what is generally referredto as IP telephony. IP telephony follows the IPparadigm: all service-specific processing and

44

TIPHON

Telecommunications and

Internet Protocol

Harmonization over

Networks

TMN

Telecommunications

Management Network

UDP

User Datagram Protocol

VoIP

Voice-over-IP

Ordinary phone

PSTN

IWF

IP

IP Phone

3

1

5

2

4

Figure 1. Voice Communication Scenarios

protocols, such as signaling and media coding,are pushed to the end systems and are trans-parent to the network. Applications can bebuilt on top of the Transmission Control Pro-tocol (TCP) or the User Datagram Protocol(UDP), depending on whether they are loss-sensitive or time-sensitive respectively.

For example, the TCP transport protocolis used to carry the signaling stream since thesignaling channel has to be error-free. How-ever, because of its intrinsic timing constraint,voice traffic is usually transmitted over UDP.The time-continuous property of voice signalsrequires that the transport channel ensure theappropriate streaming needed for data resyn-chronizing at the receiver. For this reason, theReal-Time Protocol (RTP) is used. Thesequence numbering field of RTP packetheaders is used to reorder the receiving packetsin case of out-of-sequence delivery (UDP doesnot ensure packet sequencing); the time-stampfield indicates the temporal playback positionof the data payload. In addition, RTP allowsthe receiver to identify the media coding type(that is, which voice coding standard has beenused at the coder side).

As far as end users are concerned, per-sonal computers are the most common IP ter-minals. The processing and control parts of anIP telephony terminal are therefore usuallyimplemented in software. However, a standardtelephone set can also be connected to an IPtelephony service by means of a network adap-tor that provides a minimal set of the requiredprotocols. This has the advantage of havingthe potential to reach a much larger numberof users than PC holders.

ITU-T Recommendation H.323 [11] andits related set of standards for packet-basedmultimedia communications [12] [13] [14][15]—in addition to the several related effortscarried out by the ETSI, IETF, and theIMTC—certainly constitute the mostadvanced framework that covers essential IPtelephony issues. Although it is not our goalto present a tutorial on H.323, a brief descrip-tion of the standard is required for the follow-ing discussion on interworking. Thepresentation is restricted to the basic voice

aspects of H.323; data and video communica-tions and multipoint aspects are not covered.

H.323 Systems

The H.323 standard defines three types ofequipment: gatekeepers, gateways, and termi-nals. The gatekeeper is an optional piece ofequipment that provides call control servicesto the terminals. Examples of such services areaddress translation, admission control, callauthorization, and directory services. The RAS(Registration, Admission, and Status) protocoldefined in H.225.0 is used to communicatebetween a terminal and a gatekeeper.

The gateway is responsible for providingall translations necessary for transmission for-mats and control procedures between the IPsupported portion and the PSTN/ISDN partof hybrid calls. As gateway functions are morerelated to hybrid calls than pure IP calls, theywill be discussed in “Signaling and Control,”later in this paper.

The H.323 terminal components aredescribed in Figure 2 on page 6. A terminalmay support several standards for voice cod-ing. The G.711 codec (used in ISDN) is,however, mandatory for all terminals. TheH.225.0 recommendation specifies the use oflogical channels based on the RTP/UDP/IPprotocol stack to transfer coded voice data.The system control part of a terminal is composed of three protocols:• The RAS signaling function is used for the

dialog between a terminal and a gatekeeper.The associated channel, called the RASchannel, uses the UDP/IP protocol stack. Amain function of the RAS channel is toallow the terminal to be attached to a gate-keeper by registering itself. Registrationbasically results in an update of the gate-keeper’s address translation table. Thisallows other terminals to locate the regis-tered terminal and to determine its trans-port address in order to initiate a call-signaling channel.

• The call signaling between two H.323 ter-minals is based on Q.931 messages. Thecall-signaling channel uses a TCP/IP proto-col stack. The call setup phase consists ofsending a Setup message to the destination.

55

The setup phase is considered successfulupon reception of the Connect messagefrom the called terminal. The next phase isthe establishment of the H.245 channel.

• The H.245 protocol defines end-to-endcontrol messages used for capability negotia-tion (e.g., the supported codecs), openingand closing of logical channels, flow controlmessages, and so on. The H.245 controlchannel is a reliable channel based on TCP.

Figure 3 shows an example of a controlprotocol diagram between two H.323 termi-nals. A description of some of these messagesis provided in “Addressing,” later in this paper.Finally, it should be noted that H.323 definesa Fast Connect method in order to alleviatethe initiation phase in basic and simple calls.The H.245 dialog is then replaced by addi-tional information elements in the Q.931messages so that, upon reception of the Connect message, all needed voice channelsare activated.

Hybrid Voice Services

In scenario 3, the two terminals involved inthe call use different protocol stacks to com-municate with their access networks. The pro-tocol conversions occur at the networks’

boundaries. Two terminals, of different typesin this case, communicate with each other toensure an ad hoc voice service to the endusers. Scenario 3 requires both the mapping ofmedia and media control channels and themapping between signaling protocols.

In scenarios 4 and 5, the same protocolsare used at the interface of each terminal, buta different protocol is used between them.The protocol conversions in both directionstake place (at least twice) at the boundaries ofthe traversed networks and the presence ofanother network in the middle should betransparent to end users. In these scenarios,both the mapping of media and media controlchannels and the mapping between signalingprotocols are generally required. However,mapping between signaling protocols can beavoided in some configurations. In particular,when the IP network is used only as a back-bone network (scenario 4), all PSTN/ISDNsignaling information can be transferred trans-parently through the IP network.

The gateway is the equipment that gener-ally hosts the interworking functions. How-ever, in the H.323 standard, the gatekeepermay also be involved in some interworkingfunctions such as address translation. In the

66

H.2

25.0

Lay

er

Audio I/O

IP

RTP/RTCP

H.245Media Control

LAN Interface

Voice Codecs

G.711 - G.722G.728 - G.729

G.723.1 H.225.0 Control

System Control/User Interface

TCPUDP

RAS(Gatekeeper

Protocol)

Q.931Call Signaling

Figure 2. H.323 Voice Terminal

next sections, we will generically use “gateway”to describe the equipment in charge of allinterworking functions. In addition, we willonly consider the case where the PSTN/IPgateway is connected to the PSTN via anISDN access. Interworking issues betweenISDN networks and analog PSTN terminalsare not covered in this paper.

Signaling and Control

In this section, we show how call connectionsare set up and how control commands areconveyed during a communication.

Signaling Adaptation Functions

If two different signaling protocols are used inthe interconnected networks, then the IWFshould translate the signaling messages in sucha way that the end-to-end call can be com-pleted. In the H.323 gateway, Q.931 is used inboth the IP network and ISDN access. How-ever, the Q.931 signaling channel between anIP terminal and the gateway is terminated atthe gateway (that is, Q.931 messages areprocessed in the gateway and not simply for-warded). A peer Q.931 channel is then used tosupport the call control on the PSTN side.This is mainly due to the fact that H.323 has

defined a particular use of Q.931 messages, sothat there is not necessarily a perfect correspon-dence with the ISDN use of Q.931 [12] [13].Figure 4a on page 8 shows the IWF protocolstacks in the control plane in scenario 3.

SS7 Interoperability

For historical reasons, IP/PSTN gateways areusually seen as administrative boundariesbetween a network provider (usually the oper-ator) and a network customer (usually a com-pany or Internet service provider). For thisreason, they are connected to the network asterminals. However, the gateway can be con-nected as a network node to the PSTN, tohave access to its SS7.

Consider, for example, the scenariodepicted in Figure 5 on page 9. Two IP tele-phony-based call centers are shown; each isconnected to the PSTN through gateways. Thetwo call centers are combined to form a singlevirtual distributed call center; if all the agentsin one call center are busy, calls are to bediverted to the other one. If the gateways donot have access to the SS7 network of thePSTN, then such a call diversion requires ter-minating the call at the first gateway, and re-initiating a call from the first gateway to the

77

Terminal T1 Gatekeeper

Registration Request

Terminal Capability Set

Terminal Capability Ack

Open Logical Channel

Open Logical Channel

RTP voice packet

RTP voice packet

Setup

Registration Confirm Registration Confirm

Registration Request

Terminal T2

Admission Request

Admission Confirm

Alerting

Call Proceeding

Admission Confirm

Admission Request

Connect

RAS

Terminal 1 Registration

Terminal capability negotiation Terminal capability negotiation

Setting up voice channels Setting up voice channels

Speech Speech

Terminal 1 requests thepermission to set up a call

Terminal 1 sendsSetup message

Terminal 2 Registration

Terminal 2 requests thepermission to answer the call

Ringing…The user accepts the call

Q.931

H.245

Voice

RAS

RAS

Q.931

Q.931

H.245

Voice

Figure 3. Diagram of H.323 Control Protocols

second one. This would tie up two PSTNports of the first gateway, use up two voice cir-cuits in the PSTN, and potentially introduce ahigh delay due to the convoluted route that thevoice signal follows.

On the other hand, if the first gateway hasaccess to SS7, then it can simply divert the callto be directly terminated at the second gate-way, thereby avoiding the above inefficiencies.In this way, the two call centers can seamlesslybe joined to form a virtual call center, whichcan be called at a common phone number. Inthis case, the gateway needs to implement theN-ISUP (Narrowband ISDN User Part) pro-tocol. Figure 4b shows the protocol stackneeded for scenario 3 where the gateway con-nected to the PSTN is an ISDN node.

SS7 is central to the operation of thePSTN. Therefore, the telecommunicationscompanies are very reluctant to expose theirSS7 network to gateway owners. A moreacceptable approach is to provide SS7 accessto a signaling gateway, which would controlone or more media gateways. The signalinggateway would then reside on the premises ofthe telecommunications company, and wouldcommunicate with the media gateways via aspecific protocol. Work is in progress in IETFand ITU-T Study Group 16 to standardizesuch a protocol. Several candidate protocolsexist, such as the Media Gateway Control Pro-tocol (MGCP). Another proposal in consider-ation is to use the H.323 signaling protocolsfor this purpose.

88

Q.931

Q.921

D chD chLayer 2

IPIPIPIP

TCP

Q.931

TCP

Q.931

TCP

Q.931

Layer 2Layer 2Layer 2

PhysicalPhysicalPhysicalPhysicalPhysicalPhysical

IP phoneterminal

IP network IWF(Gateway)

IWFSignaling Adaptation

PSTNaccess via ISDN

PSTNterminal

Call Signaling Channel

a) The IWF Appears as an ISDN Terminal to the PSTN

Layer 2

IP MTP 2IPIPIP

TCP

Q.931

TCP

Q.931MTP 3

N-IS UP

MTP 2

MTP 3

N-ISUP

Layer 2Layer 2Layer 2

PhysicalPhysicalPhysicalPhysicalPhysicalPhysical

IP phoneterminal

IP network IWF(Gateway)

IWFSignaling Adaptation

PSTNaccess via ISDN

PSTNterminal

Call Signaling Channel

b) The IWF Appears as a Network Node to the ISDN

Figure 4. The IWF in the Control Plane

Addressing

In the IP world, terminal addressing is gener-ally based on alphanumerical streams whoseresolution and directoring are based on hier-achically organized servers [21]. Similaraddressing schemes for IP telephony are pro-vided by the Session Initiation Protocol (SIP)[7] defined by the IETF. However, as arequirement of service interworking betweenthe PSTN and IP, each PSTN user should beable to call an IP attached user and vice versa.When the call is initiated from an IP terminaltoward the PSTN, the E.164 destinationaddress can be easily sent to the gateway andthen across the PSTN. Such is the case inboth H.323 and SIP. The problem is morecomplex when the caller is a PSTN terminaland the destination is an IP terminal. This ispartly due to the limited dialing capabilities ofstandard telephone sets, particularly if only analphanumerical type of addressing is definedfor the destination.

A crucial question is whether the numeri-cal expression of an IP address can be explic-itly used in the identification of the IPterminal. An important requirement for ser-vice interworking is that the calling usershould be oblivious of the network (PSTN orIP) to which the callee is attached. The ITU-Tapproach to this problem is to allow an H.323terminal to be identified by several addressaliases of different kinds, typically, an E.164

address and an e-mail–like address [11]. Suchan approach generally requires specific addresstranslation, resolution, and registration ser-vices, which in H.323 are typically performedby the gatekeeper.

Figure 6 on page 10 shows an example ofa call control scenario with address resolution.A PSTN terminal initiates a call to an IP ter-minal using the E.164 address alias. The stepsof this scenario are the following:

1. The IP terminal registers with the gate-keeper by giving a network address,aliases of the network address, and thetransport address of its signaling channel(i.e., the TCP port number and IPaddress). Examples of network addressaliases are user@host and an E.164address. The terminal sends as many Reg-istration Request messages as necessary toregister all its address aliases.

2. The gateway registers with the gatekeeperin the same way.

3. The gateway receives a Setup messagefrom the ISDN access switch. This mes-sage contains the E.164 address of thecalling PSTN/ISDN terminal and theE.164 address of the called IP terminal.

4. The gateway sends back the Call Proceed-ing message to indicate that the call isbeing processed.

5. The gateway sends a Location Requestmessage to the gatekeeper asking for the

99

Gateway 1

Gateway 2

IP network

IP network

PSTN

Busy!

Busy!

Busy!

Figure 5. SS7 Interoperability: A Call Diversion Scenario

channel signaling transport address of thecalled terminal; the E.164 address of thecalled party is provided in the message.

6. The gatekeeper sends back a LocationConfirm message containing the requiredtransport address.

7. The gateway asks for permission to set upthe call by sending an Admission Requestto the gatekeeper. Upon reception of theAdmission Confirm message, the gatewayis ready to start the Q.931 setup phase.

8. The gateway sends a Setup message onthe signaling channel of the destinationIP terminal.

9. If the terminal is alive, a Call Proceedingmessage is sent back.

10. The terminal asks for permission to setup the communication.

11. The terminal sends an Alert message to thegateway indicating that the called user isbeing alerted of the incoming call. Thismay correspond to the usual ringing signal.

12. The Alert message is forwarded to theISDN part.

13. The terminal sends a Connect message tothe gateway indicating that the call isaccepted. The Connect message contains

the transport address needed for theestablishment of the H.245 channel.

14. The terminal and the gateway initiate theH.245 dialog for capability exchange andestablishment of logical channels.

15. After the media channels are activatedbetween the terminal and the gateway,the latter sends a Connect message to theISDN calling party indicating that voicecommunication can start.It should be noted that this diagram depicts

a typical scenario, but there are shorter scenariosthat use the Fast Connect procedure [11].

Media Control Functions

Once the connection is set up, the media con-trol channel is used to carry all control infor-mation generated by the user or the terminal.For voice communications, the main type ofuser-level control information is the DTMFtones, which are used, for example, to interactwith a voice server. Carrying these signals overa hybrid connection requires careful monitor-ing. The standard compression techniquesused today for low bit-rates introduce enoughdistortion to corrupt DTMF analog tones,making the receiving end system unable tocorrectly decode the original signals. There-

1100

IP Terminal Gatekeeper

Registration Request

H.245 Dialog

Voice

Setup

Registration ConfirmRegistration Confirm

Registration Request

Gateway PSTN/ISDN

Location Request

Location Confirm

Alerting

Call Proceeding

Setup

Call Proceeding

Alerting

Connect

Admission Confirm

Admission Request

Connect

Voice

Admission Confirm

Admission Request

1

9

10

11 12

15

13

14

16

2

45

7

8

3

6

Figure 6. Example of Call Control in a Hybrid Voice Communication

fore, DTMF tones need to be separated fromthe audio signal at the sender (if it uses a clas-sical terminal attached to an adaptor) or at thegateway, and conveyed separately to thereceiver.

Two approaches have been recommendedby the VoIP Forum for carrying DTMFinformation. The first is to carry them in-band via RTP using a dedicated payload for-mat. The advantage of this approach is thatthe tones remain temporally synchronizedwith the speech. However, packet delivery isnot guaranteed because of the unreliability ofthe UDP transport protocol. Although packetloss can be kept very low in well-engineerednetworks and has negligible impact on voicequality, the loss of a DTMF tone can result insevere service malfunctions at the user level.The second solution uses out-of-band trans-port of DTMF signals on a separate and reli-able media control channel. The drawback ofthis approach is that the signals lose theirexact temporal position in the voice stream.This latter approach has been recommendedfor H.323 systems—that is, those using theH.245 channel. The protocol stack for themedia control interworking function is shownin Figure 7.

Media Adaptation Functions

The major user plane issue is maintenance ofthe Quality of Service (QoS) required forvoice connections. Instead of worrying aboutthe quality of the transmitted bits, we focus

on the quality of information delivered to theend user. Two main factors may influence theQoS experienced by the end user:• The end-to-end speech quality, which may

be affected by both the successive encod-ing/transcoding operations and the packetloss due to network congestion.

• The end-to-end delay, which mainly impactsthe interaction between the participants of aconversation. It results from the coding/decoding process, packetization, and queu-ing delays.

On the IP network side, the serviceprovider tries to accommodate a maximumnumber of voice connections at a time. There-fore, a key question arises: what are the appro-priate mechanisms to be employed withinboth the end systems (including the gateways)and the network in order to optimize networkutilization while maintaining the desired QoSfor the end users?

In this section, we first give a briefdescription of the techniques that are beingimplemented in IP networks to provide a certain service guarantee. Then we analyzehow the end systems may influence the user-oriented QoS. We focus on the trade-offsamong bandwidth, delay, and computationalcomplexity.

QoS- and IP-Based Networks

While the PSTN network ensures a fixeddelay and no-loss guaranteed service, this isnot necessarily the case for IP-based networks.

1111

Layer 2

IPIPIPIP

TCP

H.245

TCP

H.245 B ch B ch

Layer 2Layer 2Layer 2Physical Physical

PhysicalPhysicalPhysicalPhysical

IP phoneterminal

IP network IWF(Gateway)

IWFMedia Control

PSTNaccess via ISDN

PSTNterminal

Media Control Channel

Figure 7. The IWF in the Control Plane: Carrying DTMF Signals

Indeed, services currently experienced on theInternet are best-effort services. They are char-acterized by the absence of any QoS specifica-tion at all. However, IP telephony applicationswill definitely need some kind of quality guar-antees in terms of absolute delay, delay jitter,and packet loss.

The Integrated Services (IntServ) archi-tecture was designed to provide a set of exten-sions to the best-effort traffic delivery model.For this purpose, it defines two classes: guar-anteed service and controlled load service [1].• Guaranteed service (GS) provides a lossless

transfer with tight delay bounds for flowsthat conform to the parameters negotiatedat the connection setup.

• Controlled load service (CLS) yields a qual-ity corresponding to a lightly loaded IP net-work at best-effort; it is not expressedquantitatively. The admission control isbased on the peak rate declared by a sessioninitiator and on measurements of the loadin the network. This could lead to a highernetwork efficiency compared to admissioncontrol based only on declared sourcedescriptors.

Both GS and CLS connections can beestablished by Resource Reservation Protocol(RSVP) signaling [27]. However, RSVP hassome weaknesses that considerably undermineits wide deployment, mainly due to the soft-state reservations paradigm and the exponen-tial growth of the reservation state tables.

In order to get around the weaknesses ofthe solutions proposed by the IntServ group,

a new group, called the Differentiated Services(DiffServ) group, was formed. The DiffServgroup suggested that instead of maintainingthe state of each and every flow, why not dis-criminate the packets according to their precedence? The precedence of a packet isindicated by the three first bits of the IP Typeof Service field. This idea led to the concept of differentiated services, which also has theadvantage of being “easily” implementable inexisting networks.

As previously mentioned, the objective ofa service provider is to increase the networkefficiency (reduce service cost) by accommo-dating as many voice connections as possible.This leads to higher packet loss ratios anddelays. The sensitivity of IP voice services todata loss strongly depends on the mechanismsimplemented in the end systems.

QoS and End Systems

The heterogeneity of networks causes voicetraffic to be handled differently. Indeed, in thePSTN, voice connections generally operate atthe standard rate of 64 Kbps (pulse code modulated, PCM, signal, or G.711). How-ever, there is no need to keep such a highbandwidth connection within the IP network.Rates ranging from 5.3 Kbps (i.e., G.723.1) to 8 Kbps (i.e., G.729) will usually be moreappropriate. The transcoding (PSTN to IPnetwork) process occurs in the gateways (Figure 8). However, a lower bit rate will generally involve a lower signal quality andhigher delays.

1122

Layer 2

IPIPIPIP

UDP

RTP

UDP

RTP B ch B ch

Layer 2Layer 2Layer 2Physical Physical

PhysicalPhysicalPhysicalPhysical

IP phoneterminal

IP network IWF(Gateway)

IWFMedia Adaptation

PSTNaccess via ISDN

PSTNterminal

Voice Channel

Figure 8. The IWF in the User Plane

Indeed, while both the G.729 and G.711coding standards provide a voice quality com-parable to the usual telephone service quality(toll quality), an encoder based on the G.723.1standard outputs a quality lower than toll qual-ity. The introduced delay results from both ahigher processing delay and an increasingpacketization delay. The processing delay is thedelay required to run the encoding algorithmon the uncompressed voice signal and to createa stream of bytes ready to be sent to the packe-tization layer. The packetization delay repre-sents the time needed to form a packet ofcompressed voice information of a given size.Therefore, when decreasing the encoding bitrate, the service provider can accommodatemore voice connections at the expense ofincreasing signal distortion and delay.

As stated earlier, the RTP/UDP/IP proto-col stack is used for the delivery of delay- andloss-sensitive services over packet networks.

In such a scenario, every single packetcontains 40 bytes of pure header information(assuming no header compression technique is

used). There is thus an inherent trade-offbetween packetization delay and payload-to-header ratio (channel utilization): the higherthe payload-to-header ratio, the higher thepacketization delay for a given encoding stan-dard. For example, if the G.723.1 standard isused, 60 ms are necessary to collect 40 bytesof voice information; this corresponds to a 50percent channel utilization. Figure 9 illustratesthe evolution of packetization delay versusnetwork utilization. However, packetizationdelay can be dramatically reduced by multi-plexing several voice connections in the sameIP packet. A recent Internet draft [25] pro-poses to perform this multiplexing at the RTPlayer (such as gateway-to-gateway communi-cation in scenario 4).

The combination of processing, packeti-zation, and queuing delays forms the end-to-end delay perceived by the end user. Anincreasing end-to-end delay may lead to a bet-ter service implementation from the serviceprovider viewpoint. However, this end-to-enddelay, if strictly lower than 400 ms, should not

1133

Network Utilization

Pa

ck

eti

za

tio

n D

ela

y (

ms

)

700

600

500

400

300

200

100

00 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

G.711 codec: 64 kbits/s

G.729 codec: 8 kbits/s

G.723.1 codec: 5.3 kbits/s

Figure 9. Packetization Delay vs. Network Utilization

affect the interaction between the participantsin a conversation. Delays up to 150 msrequire echo control but do not compromisethe effective interaction between the users.

Equivalently, the distortion introduced byboth the successive encoding/transcodingprocesses and data loss due to network conges-tion affect the end-to-end speech quality. Thisquality must be equal or close to toll quality.Mechanisms such as error correction and errormasking techniques should be used in order totolerate higher data loss while providing thesame service quality. For example, G.723.1interpolates a lost portion of the voice signalby simulating the vocal characteristics of theprevious portion and slowly damping the sig-nal [20]. The efficiency of an error maskingscheme decreases when the number of packetslost at a time increases. Also, forward errorcorrection (FEC) schemes have been proposedto alleviate loss bursts of a small number ofpackets. An RTP payload type for streamswith FEC is being defined by the IETF. Itshould be noted that FEC introduces somepredictable delay.

Although the relationship between all thefactors influencing the service quality and net-work efficiency is intrinsically complex, it isthe key to implementing an optimal voice ser-vice over IP networks.

Management Issues

The management plane generally covers dif-ferent layers such as device, system, and ser-vice management. A complete managementframework for hybrid services is not yetdefined because of the different IETF andITU-T management approaches. Instead, wediscuss here some important management fea-tures and related open issues.

Service Creation

The ITU-T has defined recommendationH.450.1 specifying how new services (calledsupplementary services) can be added toH.323 systems. Two supplementary servicesare already defined in H.450.2 (Call Transfer)and in H.450.3 (Call Diversion), and a fewothers are still under study. The main advan-tage of standardizing the supplementary

services is to ensure their interoperabilityacross different service providers.

IP telephony clearly offers a much moreflexible and open environment for service cre-ation because it relies more on software-basedand intelligent end systems than on networknodes. An important issue in voice servicemanagement is the development of powerfulservice creation environments as well as proto-cols and application programming interfaces(APIs) for uploading these new services in theterminals. Presumably, an approach similar tothe intelligent network, but more open andflexible, is needed for hybrid service manage-ment. A Java-based approach has already beenproposed for this purpose [6].

OAM-Like Features

Up to now, most of the effort spent to achieveIP and PSTN service interworking wasfocused on the control and user planes. Man-agement plane interworking is still an openissue. It is, however, a determinant aspect forthe long-term viability of hybrid voice ser-vices, especially for operators that are intro-ducing the IP technology in their core oraccess networks. This is because global andunified management operations (such as per-formance monitoring and failure detection)are necessary to ensure seamless service qualityfor end users. For ITU-T standardized net-works (ISDN, BISDN, Frame Relay), thesemanagement aspects are referred to as opera-tions administration and monitoring (OAM).Examples of OAM features are detection offailures and defects, loopback activation andperformance measurements. It is then essentialto define and standardize such procedures forIP telephony as well. In particular, for theH.323 standard, some tools that can performOAM-like features are the following:• The exchange of the RAS messages Infor-

mation Request (IRQ) and InformationRequest Response (IRR) between the gate-keeper and terminals provides a way todetect failures in H.323 equipment.

• The H.245 message Round Trip DelayRequest allows an end-point to measure thecommunication delay in real time. This

1144

information can be used for various man-agement decisions.

• The H.245 message Maintenance LoopRequest allows an end-point to set up aconnection in loopback mode with anotherend-point. This procedure can be used forremotely testing the connection availability.

However, more work remains to be doneto provide a unified OAM approach for man-aging a hybrid IP/PSTN platform.

Network and System Management

The philosophy of network and service man-agement is very different in the PSTN than inthe Internet. The telecommunications com-munity has defined and to a large extentimplemented an architecture called theTelecommunications Management Network(TMN) [16]. It is a heavyweight solution inwhich the various network components arerepresented in a sophisticated object-orientedmodel. In this architecture, five functionalareas are identified: fault, configuration,alarms, performance, and security.

For IP telephony systems, ITU-T StudyGroup 16 is working on the definition of sev-eral management information bases (MIBs)for the various H.323 components (for exam-ple, see [19] for the gatekeeper’s MIB). It isnot clear how the TMN functional areas willinterface with the SNMP-based managementof the Internet for the successful provision ofhybrid voice services.

Policy Management

From a service management viewpoint, theSNMP-based approach for device-level man-agement has limitations. For example, it is dif-ficult for a network manager to map thedesired network behavior into individualdevice configuration parameters, especiallyconsidering that the desired behavior maydepend upon many dynamic factors such astraffic conditions, time of day, date, and net-work topology. Furthermore, device-levelmanagement allows only very limited possibil-ities for altering network behavior based onthe sender or receiver of information.

In order to overcome these limitations, thenetworking community has been working onpolicy management, which can be consideredas a level of abstraction above device manage-ment. Policy management allows networkmanagers to specify device-independent poli-cies that describe the network behavior interms of security, quality of service, account-ing/charging, and so on. Such policies arestored in policy servers and downloaded toindividual devices as required. Therefore, a protocol is required to communicate between network devices and policy servers. The IETF-defined Common Open Policy Service (COPS)protocol* can be used for such purposes.

By using the RAS protocol, the H.323devices request from the gatekeeper variousservices such as zone registration, call admis-sion control, address translation, etc. The cur-rent gatekeeper implementations make thesedecisions locally, without taking network con-ditions into consideration. However, a policy-aware gatekeeper would consult the policyserver for making its decisions. This providesgreat flexibility for policy implementation,which would no longer be limited by gate-keeper capabilities. Therefore, the gatekeeperwould be the natural front end to the policyserver for the H.323 systems.

The policy management concept is still inits infancy, and many of its components areyet to be developed and standardized. Theefforts for standardization are being carriedout by bodies such as the Desktop Manage-ment Task Force (DMTF) and the IETF [2].

Security

Security in voice communications is gaininginterest for both the PSTN and IP telephony.User/terminal authentication as well as com-munication privacy are the most frequentlyrequired security features. A number ofdevices are commercialized today to securetelephone and fax communications on thePSTN. On the side of IP networks, many pro-posals have been implemented at the network,transport, and application levels. ConcerningH.323 systems, a security framework has been

1155

* While COPS was originally defined for RSVP policies, it is applicable to other types of policies as well.

defined in recommendation H.235. However,security protocols and algorithms have not yetbeen standardized.

Security mechanisms are usually negoti-ated between the two end-points of the com-munication; however, in hybrid voice services,voice channels as well as signaling channels arealso terminated at the gateway. How this“third-party” will be involved in the authenti-cation procedure is still an open question.This raises the issue of key management in ahybrid environment, a problem that seems tohave been overlooked so far by the researchcommunity.

Dependence on the Regulatory Framework

For historic and strategic reasons, the telecom-munications regulatory bodies have devoted alot of attention to voice service. Even if todayvoice services are being liberalized in mostcountries, the way they are billed is still understrong political monitoring. Therefore, howprofitable the business of IP telephony can bewill also depend on legislative decisions in theyears to come.

In spite of these open questions, themigration of voice services from the PSTN toIP networks is absolutely crucial. Even if databits are becoming more numerous than voicebits, voice still represents more than 70 per-cent of the revenue of the communicationindustry. A wealth of advanced multimediaservices can be envisaged on this basis.

Conclusion

In this paper, we have provided an overview ofthe technical issues involved in the provision ofvoice services over hybrid PSTN and IP net-works. It is difficult to predict the pace atwhich this new technology will be acceptedbecause of the following open issues: • Complexity. The provisioning of voice ser-

vices over the conventional PSTN is alreadyextremely complex and has led to highlysophisticated switches running programs ofmillions of source code lines. In the fivecommunication scenarios discussed in thispaper, the complexity resulting from com-bining voice services could suddenlyincrease by a factor of five. It would be too

optimistic to believe that this problem issolved by the Internet paradigm of intelli-gence at the edge. Indeed, as we have seen,many functions must be implemented inthe gateways and gatekeepers, which arecentralized network devices. Even if com-munications are established (and billed)properly for the five basic scenarios, this willnot necessarily be the case in more complexconfigurations, such as when a user wants toestablish a call from a conventional phoneto an IP terminal that happens to have itscalls forwarded to a cellular phone.

• Quality of service. As we have seen, in ahybrid call user data must go through anumber of transcoding operations. It hasnot been proven that the user-perceivedquality of service will be acceptable in awidely deployed hybrid service. Moreover, if at least one of the terminals happens to be mobile, the combination of the wirelessproblems with packetization delays anddegradation due to transcoding can be aconsiderable challenge.

• Ease of use. It is clear that users appreciatethe ease of use of universal communicationsystems such as the telephone and e-mail,notably because of the simplicity of theaddressing. However, in the case of hybridvoice services, this simplicity will disappear.End users will be in some way aware of theexistence of intermediate devices (gateway,gatekeeper). Proposed mechanisms to shieldusers from these issues by the use of aliasescan be highly vulnerable to such conditionsas changes in telephone or Internet serviceproviders.

Acknowledgment

The authors would like to thank DanielaBourges Waldegg and Constant Gbaguidi for their helpful comments.

1166

References

[1] P. Almquist. Type of Service in the InternetProtocol. IETF RFC1349. July 1992.

[2] J. Boyle, et al. Common Open Policy Service Protocol. Internet Draft. August 1998.

[3] S. Dixit and S. Elby. “Frame Relay andATM Interworking.” IEEE CommunicationsMagazine, Vol. 34, No. 6, June 1996.

[4] ETSI TIPHON Project. In progress doc-uments at www.etsi.fr/tiphon, 1998.

[5] H. J. Fowler and J.W. Murphy. “Net-work Management Considerations for Inter-working ATM Networks with Non-ATMServices.” IEEE Communications Magazine,Vol. 34, No. 6, June 1996.

[6] C. Gbaguidi, J. P. Hubaux, G. Pacifici,and A. N. Tantawi. “An Architecture for theIntegration of Internet and Telecommunica-tion Services.” Submitted to IEEE Journal.EPFL Technical Report SSC/1998/ 025. Also available at http://sscwww.epfl.ch.

[7] M. Handley, H. Schulzrinne, and E. Schooler. SIP: Session Initiation Protocol.Internet Draft, July 1997.

[8] IMTC. Voice-over-IP working group.www.imtc.org, 1998.

[9] ITU-T Recommendation E.164 (1997).The International Public TelecommunicationNumbering Plan.

[10] ITU-T Recommendation G.723.1(1996). Speech Coders: Dual Rate Speech Coderfor Multimedia Communications Transmittingat 5.3 and 6.3 kbit/s.

[11] ITU-T Recommendation H.323 (1998).Packet-Based Multimedia Communications Systems.

[12] ITU-T Recommendation H.225.0(1998). Call Signaling Protocols and MediaStream Packetization for Packet-Based Multime-dia Communication Systems.

[13] ITU-T Recommendation H.245 (1998).Control Protocol for Multimedia Communica-tion.

[14] ITU-T Recommendation H.235 (1998).Security and Encryption for H-Series (H.323-and other H.245-Based) Multimedia Terminals.

[15] ITU-T Recommendation H.450.1(1998). Generic Functional Protocol for theSupport of Supplementary Services in H.323.

[16] ITU-T Recommendation M.3010(1996). Principles for a TelecommunicationsManagement Network.

[17] ITU-T Recommendation Q.1211(1993). Introduction to Intelligent NetworkCapability Set 1.

[18] ITU-T Recommendation Q.931 (1993).ISDN User-Network Interface Layer 3 Specifi-cation for Basic Call Control.

[19] D. Klenke. Multimedia ManagementInformation Base, Annex 2.4 - H.323 Gate-keeper. ITU-T Study Group 16. Q.12-14/16Rapporteur Meeting Cannes, 8–11 June 1998.

[20] T. J. Kostas, M. S. Borella, I. Sidhu, G.M. Schuster, J. Grabiec, and J. Mahler. “Real-Time Voice over Packet-Switched Networks.”IEEE Network, Vol. 12, No. 1, Jan–Feb 1998.

[21] P. Mockapetris. Domain Names: Conceptsand Facilities. IETF RFC 1034. Nov. 1987.

[22] A. R. Modaressi and R. A. Skoog. “Sig-naling System No 7: A Tutorial.” IEEE Com-munications Magazine, July 1990.

[23] B. Petri and D. Schwerje. “NarrowbandISDN and Broadband ISDN Service and Net-work Interworking.” IEEE CommunicationMagazine, Vol. 34, No. 6, June 1996.

[24] J. Rosenberg and H. Schulzrinne. AnRTP Payload Format for Generic Forward ErrorCorrection. Internet Draft, IETF, Mar. 1998.

[25] J. Rosenberg and H. Schulzrinne. AnRTP Payload Format for User Multiplexing.Internet Draft, IETF, Jan. 1998.

[26] H. Schulzrinne, et al. RTP: A TransportProtocol for Real-Time Applications. IETF RFC1889, Jan. 1996.

[27] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. “RSVP: A NewResource ReSerVation Protocol.” IEEE Net-work Magazine, 1993.

1177

About 3Com Corporation

With over 300 million customer connections worldwide, 3Com Corporation connectsmore people and organizations to information and each other in more innovative, sim-ple and reliable ways than any other networking company. 3Com deliverse-Networking solutions through information access products and network systems toenterprises, small businesses, consumers, carriers and network service providers.

3Com Corporation 5400 Bayfront PlazaP.O. Box 58145Santa Clara, CA 95052-8145Phone: 1 800 NET 3Comor 1 408 326 5000

Fax: 1 408 326 5001World Wide Web:

www.3com.com

3Com Americas International

U.S. Headquarters (servingCanada and Latin America)Phone: 1 408 326 6328/1 408326 6075

Fax: 1 408 326 5730/1 408 326 8914

MiamiPhone: 1 305 461 8400Fax: 1 305 461 8401/02

3Com Canada

BurlingtonPhone: 905 336 8168Fax: 905 336 7380

CalgaryPhone: 403 265 3266Fax: 403 265 3268

EdmontonPhone: 780 423 3266Fax: 780 423 2368

MontrealPhone: 514 683 3266Fax: 514 683 5122

OttawaPhone: 613 566 7055Fax: 613 233 9527

TorontoPhone: 416 498 3266Fax: 416 498 1262

VancouverPhone: 604 434 3266Fax: 604 434 3264

3Com Latin America

Argentina (serving Argentina,Paraguay, and Uruguay )Phone: 54 11 4510 3200Fax: 54 11 4314 3329

BrazilPhone: 55 11 5643 2700Fax: 55 11 5643 2701

Chile (serving Chile andArgentina)Phone: 562 240 6200Fax: 562 240 6231

ColombiaPhone: 57 1 629 4110Fax: 57 1 629 4503

Costa RicaPhone: 506 280 8480Fax: 506 280 5859

MexicoPhone: 525 201 0000Fax: 525 201 0001

PeruPhone: 51 1 221 5399Fax: 51 1 221 5499

VenezuelaPhone: 582 267 5550Fax: 582 267 3373

Asia Pacific Rim

Melbourne, AustraliaPhone: 61 3 9934 8888Fax: 61 3 9934 8880

Sydney, AustraliaPhone: 61 2 9937 5000Fax: 61 2 9956 6247

Beijing, ChinaPhone: 8610 6588 0568Fax: 8610 6588 0602

Shanghai, ChinaPhone: 86 21 6350 1581Fax: 86 21 6350 1531

Hong KongPhone: 852 2501 1111Fax: 852 2537 1149

IndiaPhone: 91 11 629 3177Fax: 91 11 623 6509

IndonesiaPhone: 62 21 572 2088Fax: 62 21 572 2089

Osaka, JapanPhone: 81 6 6379 1767Fax: 81 6 6379 0871

Tokyo, JapanPhone: 0120 31 3266 (toll free from Japan)

Phone: 81 3 5977 3266Fax: 81 3 5977 3370

KoreaPhone: 82 2 3455 6300Fax: 82 2 319 4710

MalaysiaPhone: 60 3 715 1333Fax: 60 3 715 2333

New ZealandPhone: 64 9 366 9138Fax: 64 9 366 9139

Philippines Phone: 632 849 3979Fax: 632 849 3970

SingaporePhone: 65 538 9368Fax: 65 538 9369

TaiwanPhone: 886 2 8780 8899Fax: 886 2 8780 8866

ThailandPhone: 662 231 8151 5Fax: 662 231 8158

3Com Austria

Phone: 43 1 580 17 0Fax: 43 1 580 17 20

3Com Benelux B.V.

BelgiumPhone: 32 2 711 94 00Fax: 32 2 711 94 11

NetherlandsPhone: 31 346 58 62 11Fax: 31 346 58 62 22

3Com Eastern Europe/CIS

BulgariaPhone: 359 2 962 5222Fax: 359 2 962 4322

Czech RepublicPhone: 420 2 21845 800Fax: 420 2 21845 811

HungaryPhone: 36 1 250 83 41Fax: 36 1 250 83 47

PolandPhone: 48 22 6451351Fax: 48 22 6451352

RussiaPhone: 7 095 258 09 40Fax: 7 095 258 09 41

Slovak RepublicPhone: 421 7 317 850Fax: 421 7 317 849

3Com France

Phone: 33 1 69 86 68 00 Fax: 33 1 69 07 11 54

3Com GmbH

Phone: 49 89 25000 0Fax: 49 89 25000 111

3Com Iberia

PortugalPhone: 351 1 3404505Fax: 351 1 3404575

SpainPhone: 34 91 509 69 00Fax: 34 91 307 66 63

3Com Italia S.p.A.

Milan, ItalyPhone: 39 02 253011Fax: 39 02 27304244

Rome, ItalyPhone: 39 06 5279941Fax: 39 06 52799423

3Com Middle East

Phone: 971 4 3319533Fax: 971 4 316766

3Com Nordic AB

Denmark Phone: 45 48 10 50 00Fax: 45 48 10 50 50

FinlandPhone: 358 9 435 420 67Fax: 358 9 455 51 66

NorwayPhone: 47 22 58 47 00Fax: 47 22 58 47 01

SwedenPhone: 46 8 587 05 600Fax: 46 8 587 05 601

3Com Southern Africa

Phone: 27 11 700 8600Fax: 27 11 706 0441

3Com Switzerland

Phone: 41 844 833 933Fax: 41 844 833 934

3Com UK Ltd.

EdinburghPhone: 44 131 240 2900Fax: 44 131 240 2903

IrelandPhone: 353 1 823 5000Fax: 353 1 823 5001

ManchesterPhone: 44 161 874 1700Fax: 44 161 874 1737

WinnershPhone: 44 1189 27 8200Fax: 44 1189 695555

To learn more about 3Com products and services, visit our World Wide Web site at www.3com.com. 3Com Corporation is publicly traded on Nasdaq under the symbol COMS.

Copyright © 2000 3Com Corporation. All rights reserved. 3Com and the 3Com logo are registered trademarks of 3Com Corporation. Java is a trademark of Sun Microsystems. All othercompany and product names may be trademarks of their respective companies. All specifications are subject to change without notice.

Printed in U.S.A. on recycled paper 503055-001 2/00