basics of voip

The Basics of Voice over

Internet Protocol

Presented by the International Engineering Consortium

ii

Copyright © 2004 by Professional Education International, Inc. All rights of reproduction, including that of translation into foreign languages, are reserved. Requests for republication privileges should be addressed to Publications Department, International Engineering Consortium, 549 West Randolph Street, Suite 600, Chicago, Illinois 60661-2208, USA. All opinions expressed in The Basics of Voice over Internet Protocol are those of the authors and are not binding on Professional Education International or the International Engineering Consortium. ISBN: 0-931695-26-1 International Engineering Consortium 549 West Randolph Street, Suite 600 Chicago, Illinois 60661-2208, USA +1-312-559-4100 voice • +1-312-559-4111 fax [email protected] • www.iec.org

iii

About the International Engineering Consortium The International Engineering Consortium (IEC) is a nonprofit organization dedicated to catalyzing technology and business progress worldwide in a range of high-technology industries and their university communities. Since 1944, the IEC has provided high-quality educational opportunities for industry professionals, academics, and students. In conjunction with industry-leading companies, the IEC has developed an extensive, free, on-line educational program. The IEC conducts industry-university programs that have substantial impact on curricula. It also conducts research and develops publications, conferences, and technological exhibits that address major opportunities and challenges of the information age. More than 70 leading high-technology universities are IEC affiliates, and the IEC handles the affairs of the Electrical and Computer Engineering Department Heads Association.

About the Authors Frank M. Groom is a Professor at the Graduate Center for Information and Communication Science at Ball State University. His research is concentrated in the areas of high-bandwidth networking, distributed systems, and the storage of multimedia objects. Dr. Groom is the author of six books—among his best known are “The Future of ATM” and “The ATM Handbook”. Dr. Groom received his Ph.D. from the University of Wisconsin – Milwaukee in Information Systems and was formerly Senior Director of Information Systems for Ameritech. Kevin M. Groom is a Senior Member of the Technical Staff for AT&T, where he is involved in provisioning the network that supports the operations support systems that provide information and functionality to the carrier’s long-distance and metro networks. Mr. Groom has a B.A. in Telecommunications and an M.S. in Information and Communication Sciences from Ball State University. He is the co-author of “The Future of IP and Packet Networking” and has presented numerous talks on managing the metropolitan and national carrier networks at networking conferences.

The University of ArizonaArizona State UniversityAuburn UniversityUniversity of California at BerkeleyUniversity of California, DavisUniversity of California, Santa BarbaraCarnegie Mellon UniversityCase Western Reserve UniversityClemson University University of Colorado at BoulderColumbia UniversityCornell UniversityDrexel UniversityÉcole Nationale Supérieure des

Télécommunications de BretagneÉcole Nationale Supérieure des

Télécommunications de ParisÉcole Supérieure d’ÉlectricitéUniversity of EdinburghUniversity of FloridaGeorgia Institute of Technology

University of GlasgowHoward UniversityIllinois Institute of TechnologyUniversity of Illinois at ChicagoUniversity of Illinois at

Urbana/ChampaignImperial College of Science,

Technology and MedicineInstitut National Polytechnique de

GrenobleInstituto Tecnológico y de Estudios

Superiores de MonterreyIowa State University KAISTThe University of KansasUniversity of Kentucky Lehigh UniversityUniversity College LondonMarquette UniversityUniversity of Maryland at College ParkMassachusetts Institute of TechnologyUniversity of Massachusetts

McGill UniversityMichigan State UniversityThe University of MichiganUniversity of MinnesotaMississippi State UniversityThe University of MississippiUniversity of Missouri-ColumbiaUniversity of Missouri-RollaTechnische Universität MünchenUniversidad Nacional Autónoma de

MéxicoNorth Carolina State University at

RaleighNorthwestern UniversityUniversity of Notre DameThe Ohio State UniversityOklahoma State UniversityThe University of OklahomaOregon State UniversityUniversité d’OttawaThe Pennsylvania State UniversityUniversity of Pennsylvania

University of PittsburghPolytechnic University Purdue University The Queen’s University of BelfastRensselaer Polytechnic InstituteUniversity of SouthamptonUniversity of Southern CaliforniaStanford UniversitySyracuse UniversityUniversity of Tennessee, KnoxvilleTexas A&M UniversityThe University of Texas at AustinUniversity of TorontoVA Polytechnic Institute and State

UniversityUniversity of VirginiaUniversity of WashingtonUniversity of Wisconsin-MadisonWorcester Polytechnic Institute

These are some of the universities that participate in the University Grant Program:

Through the University Program, sponsoring organizations provide grants for full-time faculty members and their students to attend IEC Forums. The generous contributions of the followingsponsoring organizations make this valuable program possible. For more information about the program,

please call +1-312-559-4103 or send an e-mail to [email protected].

IEC University Program

The University of Arizona

Arizona State University

Auburn University

University of Californiaat Berkeley

University of California, Davis

University of California,Santa Barbara

Carnegie Mellon University

Case Western ReserveUniversity

Clemson University

The University of Coloradoat Boulder

Columbia University

Cornell University

Drexel University

The University of Florida

Georgia Institute ofTechnology

Howard University

Illinois Institute of Technology

University of Illinois at Chicago

University of Illinois at Urbana/Champaign

Iowa State University

The University of Kansas

The University of Kentucky

Lehigh University

Marquette University

The University of Maryland at College Park

Massachusetts Institute ofTechnology

The University ofMassachusetts

Michigan State University

The University of Michigan

Mississippi State University

The University of Minnesota

The University of Missouri-Columbia

The University of Missouri-Rolla

North Carolina StateUniversity at Raleigh

Northwestern University

University of Notre Dame

The Ohio State University

Oklahoma State University

The University of Oklahoma

Oregon State University

The Pennsylvania StateUniversity

The University of Pennsylvania

The University of Pittsburgh

Polytechnic University

Purdue University

Rensselar PolytechnicUniversity

University of SouthernCalifornia

Stanford University

Syracuse Univesity

University of Tennessee,Knoxville

Texas A&M University

The University of Texas atAustin

VA Polynechnic Instituteand State University

The University of Virginia

The University of Washington

The University of Wisconsin-Madison

Consortium-Affiliated UniversitiesThe International Engineering Consortium is affiliated with the following leading high-tech universities:

International Affiliated Universities

Ecole Supérieure d’Électricité

Ecole Nationale Supérieure des

Télécommunications de Bretagne

Ecole Nationale Supérieure des

Télécommunications de Paris

Imperial College of Science, Technology and Medicine

Institut National Polytechnique de Grenoble

Instituto Tecnológico y de Estudios Superiores de Monterrey

KAIST

McGill University

Technische Universität München

The Queen’s University of Belfast

Universidad Nacional Autónoma de México

Université d’Ottawa

University of Edinburgh

University of Glasgow

University of Southampton

University College London

University of Toronto

Worcester PolytechnicInstitute

The IEC wishes to thank the following publications that support the Consortium and its initiatives throughout the year by participating in the Media Partners program.

201 East Sandpointe AvenueSuite 600

Santa Ana, CA 92707-8700714-513-8400

www.americasnetwork.com

1909 Avenue GRosenberg, TX 77071

877-588-1649www.privatebroadband.com

Shorecliff Communications LLC26311 Junipero Serra Road, Suite 110

San Juan Capistrano, CA 92675800-608-9641

www.shorecliffcommunications.com

999 Oakmont Plaza Drive,Suite 100

Westmont, IL 60559-1381 800-227-1234 / 630-986-1432

www.bcr.com

2500 Tamiami Trail NorthNokomis, FL 34275

941-966-9521www.comnews.com

Reed Business Information275 Washington StreetNewton, MA 02458

617-964-3030www.commvergemag.com

98 Spit Brook RoadNashua, NH 03062-5737

603-891-0123www.light-wave.com

2615 Three Oaks RoadSuite 1B

Cary, IL 60013847-639-2200

www.ospmag.com

P.O. Box 40079Phoenix, AZ 85067-0079

480-990-1101www.phoneplusmag.com

777 East Speer BoulevardDenver, CO 80203-4214

303-733-2500www.rcrnews.com

One IBM PlazaSuite 2300

Chicago, IL 60611312-595-1080

www.internettelphony.com

8878 South Barrons BoulevardHighlands Ranch, CO 80129-2345

303-470-4875www.wirelessweek.com

3300 North Central Avenue, Suite 2500Phoenix, AZ 85012

480-990-1101www.x-changemag.com

IEC Media Partners

vii

Table of Contents About the International Engineering Consortium ............................ iii About the Authors.................................................................................. iii University Program and Sustaining Sponsors .................................... vi Consortium-Affiliated Universities and International

Affiliated Universities .................................................................... vii Media Sponsors and Partners ............................................................. viii Chapter 1: Introduction.......................................................................... 1

Chapter 2: Characteristics of Voice and IP Traffic ........................ 19

Chapter 3: VoIP Models for Connection .......................................... 37

Chapter 4: VoIP Using the H.323 Protocol........................................ 49

Chapter 5: SIP for Voice Transmission ............................................ 65

Chapter 6: Gateways and Gatekeeper Protocols ........................... 81 MGCP................................................................................. 83 MEGACO.......................................................................... 88

Chapter 7: Transmitting Voice over a Public WAN ......................... 93 and IP Network

Frame Relay........................................................................ 93 ATM .................................................................................. 102

Chapter 8: Service-Provider VoIP Offerings.................................. 113

Chapter 9: Strategies for Vendors, Regulators, ........................... 121 and Customers

Chapter 10: Conclusion ..................................................................... 129

Appendix: VoIP Terminals and Other Equipment ......................... 131

References ........................................................................................... 143

Glossary ................................................................................................ 145

1

Chapter 1

Introduction As anyone with even a passing interest in the telephone industry is well aware, voice over Internet protocol (which we’ll refer to henceforth as VoIP) is currently the industry topic du jour. For those who are just catching up, VoIP is the transmission of (traditionally circuit-switched) person-to-person voice conversations over IP–based networks. Currently, long-distance carriers such as AT&T are basing their long-term corporate strategies on VoIP service. Not to be outdone, the local telephone carriers (referred to as RBOCs, or regional Bell operating companies upon their separation from AT&T in 1984), such as Verizon and SBC, are offering the service in their allocated service areas as well and are extending their offerings to their competitors’ areas. And just to complicate matters a bit further, small start-up companies such as Vonage and Net2Phone are offering their own voice communication services, with the conversations being carried over the public Internet. What’s driving the stampede in this direction? With VoIP service, the long-distance carriers (and even smaller companies such as Voyant) see an opportunity to avoid expensive, recurring settlement costs with the local telephone companies for providing access links to their customer for accessing the distance carriers. These heretofore unavoidable costs siphon off a sizable (and, in an increasingly competitive market, unacceptable) portion of the revenue for long-distance calling—funds that are urgently needed elsewhere. The Opportunity for Voice Traffic in IP Networks To be sure, Internet telephone calling has been available for some time, and standards for delivering voice traffic over IP–based networks are hardly a new phenomenon. Indeed, they have been available and evolving for at least a decade, and a number of enterprises have proactively employed these standards to place a

The Basics of Voice over Internet Protocol

2

portion of their inter-site voice traffic on their private data networks. But given VoIP’s new status as the hot topic in networking, additional service suppliers are rapidly leaping into the fray, and (by necessity) employing one of the established standards for their service offerings. Furthermore, a few entrepreneurial long-distance start-up companies have offered long-distance telephone calling over the public Internet or over their private networks using IP. For users of such calling plans, the appearance is that all calling is delivered over the public Internet, regardless of whether the actual delivery networks employed are private facilities or the public Internet. Throughout 2003 and 2004, we have seen the introduction of standardized versions of VoIP applications. At the same time, VoIP has become appealing for an increasing number of customers as well as the providers of the services, while enabling a richer array of services than those with which traditional telephony customers are accustomed. Among these services are a whole array of Web-like phone displays, information services, and data exchange. The initial driver for this change resulted from the challenge to the service offerings of local-exchange carriers coming from those new competitors known as CLECs (competitive local-exchange carriers). The incumbent carriers are interchangeably referred to as the RBOCs or ILECs (incumbent local-exchange carriers). The incumbent RBOCs face a number of competitive challenges. They are required to sub-lease their local access loop facilities to a number of competitive firms at rates that are considered less than their own embedded cost. These competitors (CLECs) are diverting traffic from their customers around the RBOC switches to their own private switches and on to the public Internet or other networks. The growth of the public Internet in the past decade has diverted traffic away from long distance and has become a prime business, research, and entertainment tool for a vast number of individuals. The RBOC facilities are used to access the Internet, but the share of the revenue that they received for distance communications has been lost. In addition, businesses have moved a significant portion of their inter-site communication to virtual private networks (VPNs), which transmit over either the public

Chapter 1: Introduction

3

Internet or over private managed Internet services. And finally, the ubiquitous uses of cellular communications and wireless local-area networks (LANs) have siphoned traffic away from the local switched telephone network, which is the basis for the RBOC revenue stream. Furthermore, with a new regulatory ruling on local number portability (LNP), a customer's telephone number can now be moved to either cellular or CLEC connection services. Each of these technologies has diverted business from traditional telephone companies. Now the threat is that voice traffic is moving to these technologies as well as data traffic. But the overriding question remains: Why would an enterprise move some or all of its traffic to VoIP service, a relatively new (and untested) service with potentially poor call quality and subject to less-reliable connection service? Initially, conventional wisdom held that significant savings could occur in long-distance calling. However, as competition drove the cost of long distance down to the range of $0.05 to $0.07 per minute (and sometimes lower), it became clear that the promise of large savings was an illusion—although even $0.05 per minute can be profitable given sufficient call volume. Another frequently mentioned possible occurrence was that the merging of personnel supporting the data networks with those supporting the telephone networks (as well as the administration personnel for both groups) would result in fewer numbers of network support employees. This, however, also proved quickly to be somewhat of an illusion, as most companies have only a small number of telephone support people (sometimes as few as two or three) while requiring from 20 to hundreds of data network people. Moreover, most of the remaining telephone work is low-tech and performed by union-level or bottom-level technicians, or work contracted out to a maintenance service. However, there are significant non-personnel-related savings to be realized via the merger of the two support functions. This occurs from the inflexibility of the existing telephone system’s fundamental architecture, which is based upon a fixed star- connection of dedicated user telephones, where each user line has its own dedicated port on the central PBX (private branch exchange). This is consistent with the local telephone network


4

architecture, where individual users connect to their local telephone circuit switch by means of a dedicated telephone line connected to a dedicated port on the local circuit switch. There are variations on this model, but this is the standard architecture. For an enterprise customer to receive telephone service, user telephones are connected to the enterprise PBX. The PBX in turn is connected to the local central office (CO) circuit switch by one or more dedicated trunks, which carry a merged set of telephone calls from the customer building. From that local telephone switch, traffic is carried on to the RBOC’s metropolitan network, which interconnects an entire city, and on still further to an intercity and national/international long-distance carrier network. Figure 1.1 portrays these local and metropolitan networks, which are inter-connected by means of carrier long-distance networks.

Metro Net

Carrier PoP

Carrier PoP

Carrier PoP

Carrier PoPCarrier

PoP

Carrier PoP

Carrier PoP

Metropolitan Network

National Carrier

Backbone Network



Figure 1.1 Carrier Networks Interconnecting Metropolitan Networks At a customer site, once the telephone, line, and PBX port are installed and associated, technicians must assist in the reconnection and reassignment of telephones and telephone numbers for subsequent moves and changes of the equipment and updating of


5

information in the PBX. With the advent of IP addressing for telephone equipment, much of this process has become automated as the IP telephone and enterprise server automatically exchange information between themselves once the phone is connected to the local enterprise data network. In fact, many existing telephone lines can be eliminated, as the new IP phones connect over the enterprise data network, often via an Ethernet LAN wired to each employee’s work station. Then, courtesy of DHCP (dynamic host configuration protocol) servers, temporary IP addresses are dynamically downloaded to the IP phone over the local data network. As such, these combined voice and data enterprise networks can grow and users can be relocated and offices can be restructured with much less expense and re-wiring. Another, more complicated question: Why would any service provider (whether it be carrier, RBOC, or CLEC) offer VoIP in competition with their established circuit-switched analog voice service? Once a carrier’s distance network has been installed and support people are operational, it matters little to the carrier whether their distance network carries voice calls (originated as either an analog or digital call) or data traffic. Once the call is on the network, all voice calls are converted into digital form anyway at the local CO, where they are then passed on through the network in digital form. From a technical standpoint, as it happens, most of the national network is constructed as a packet-like network already. Digitized telephone calls are segmented into small pieces, and each piece is placed into small, fixed-sized ATM (asynchronous transfer mode) cells (essentially small, fixed-size packets). These voice-carrying cells are then placed into large SONET (synchronous optical network) frames for bulk transport across the national network. All traffic, whether it is voice, data, video, or Internet, is intermingled and transmitted together as a bundled unit over the national ATM network. However, when a carrier transports telephone calls that originate from a local RBOC, they must pay a sizable portion of the call revenue back to the originating and terminating RBOCs due to the


6

federal ruling on access charges. This is the real VoIP issue from a long-distance carrier standpoint—will the Federal Communications Commission (FCC) let VoIP traffic be exempt from these charges, or will VoIP traffic be treated the same as circuit-switched long distance and subject to the same charges and regulations? It is normally the case that when a call connects to the local RBOC metro network and onto the carrier network as an IP data stream, the local analog telephone switch is bypassed and the recording of individual messages is ignored. In an environment where calls are passed as IP packets, long-distance carriers hope that the FCC will rule that no portion of the long-distance call revenue will be required to be given back to the local originating or terminating RBOCs, even though the access and terminating links are provided by those organizations. The FCC is in the process of examining this issue in the early spring of 2004. Early indications are that the FCC does not want to inhibit the growth of VoIP development. However, the FCC also wishes to reimburse the local RBOCs for carrying the origination and termination portions of the traffic to the long-distance carriers. Some settlement of this issue is likely to occur shortly. But difficulty remains with regard to how to charge for a stream of packets versus a telephone call. And who would collect the measurement and billing information? Furthermore, would a long stream of packets be charged at a larger amount than a smaller stream? And how would it be determined that the packet stream contains a voice conversation in the first place? And furthermore, how would the source bill agent discover the local RBOC at the destination side of the conversation in order to allocate to them a portion of the collected revenue? How would the RBOCs determine the amount for which they should charge and whom among the service providers to charge for the traffic? For the present, VoIP service suppliers have decided to offer the service as a flat-rate anywhere-to-anywhere service in the United States with extended charges for international calling. For example, AT&T’s initial offering is a flat rate of $39.95 per month for unlimited local and long-distance calling (with a lower six month introductory rate of $19.95 to encourage customers to join). There is another factor that may inspire VoIP service introduction. Once voice and data calls are converged onto a combined network


7

and are managed as mere variations in the traffic flow, carriers can establish a combined voice, data, and video call center. These consolidated call centers can handle customer calls associated with problem resolution, temporary capacity increases, and notification of any changes in service, billing, and network requirements. The Help Desks can then be backed up by a combination of network support staff and the administrative unit that supports the staff. The resulting support-staff savings and operational efficiencies can provide increased customer satisfaction while cutting duplicated costs, space, equipment, and training, as well as staff personnel. As a result of these savings, the carriers can afford to price their distance VoIP calling as a flat-rate service. This will be particularly true if they can keep all the revenue and not have to split it with the local telephone companies that originate and terminate the calls. Today, even when calls are delivered to an IP service provider over local analog lines, the calls currently remain rated as local calls. When they carry voice within IP packets and these voice IP packets are passed on to the public Internet or private Internet service, they continue to be treated as data traffic. No long-distance revenue is returned to the local RBOC for delivering the traffic to the service provider beyond the monthly cost to the customer for an access line and to the service provider for a trunk from the RBOC CO to the Internet service provider’s (ISP’s) service office. Figure 1.2 portrays dial-up access from a residential customer to an ISP and the linkage from the ISP through a carrier office via the public Internet. The dial-up access goes directly to the local telephone company premises and progresses through the local switch but is marked as only a local call for the local connection to the ISP. The ISP then connects the packets received from the customer’s local access call to a long-distance carrier as IP traffic (undifferentiated from data). The carrier then passes the IP packets containing the call on to the public Internet or a private Internet facility. In this manner, the call is never classified as a long-distance call by the local telephone company.


8

Figure1.2 Local VoIP Traffic Bypassing

the Telephone Central Office Recording In fact, there are many ways for both residential and business customers to avoid having their IP calls classified as long distance. Approaches 1 and 2 are portrayed in Figure 1.3.

1. They can place the call through their cable modem and pass the call through their cable TV system, which then forwards the calls to the carrier and on to the public or private Internet.

2. They can pass the call through their DSL (digital

subscriber line) connection to the local telephone CO building, and then bypass the local CO circuit switch while passing the call through a digital subscriber line access module (DSLAM). From the DSLAM, the call is forwarded over a trunk to an ISP and on to the carrier and Internet.

CentralOffice

ISP Carrier POP

Public and

Private Internet

Residence Customer

Business Customer


9

Figure 1.3 DSL and Cable Access to the PSTN

and Public and Private Internets

3. A business can transmit over a private trunk through the telephone CO, bypass the telephone circuit switch, and proceed directly onto the ISP as an extension of the private-line trunk. From there, the call can be placed on another private trunk to the carrier point of presence (POP) long-distance access location. This bypasses the classification of the call as a long-distance call at the local telephone company CO.

These long-distance bypassing options (cable connection at the top of the figure, DSL and DSLAM option in the middle portion, and business private-line trunk at the bottom portion) are portrayed in Figure 1.4.

CentralOffice

IP Telephony

Adapter

DSL Modem

Cable Modem

PSTN

Public and

Private Internet

Cable Head End Office


10

Figure 1.4 The Alternative Access Services to Bypass

the Central Office Recording So what do converged voice and data IP networks look like? Generally, they appear as two separate networks. One is the traditional public switched telephone network (PSTN), which has provided service for the past 100 years. The second is a set of public and private data networks that can carry a mix of voice and data traffic, all in IP packets. Although these networks appear to be separate, they both originate some of their traffic via the facilities of the local telephone company, and they terminate their traffic in similar fashion. They overlap in terms of physical facilities, while logically remaining separate networks. And therein we have the current dilemma for the local RBOC telephone companies, as well as opportunities for all service providers (including the RBOCs and all other carriers). Figure 1.5 portrays the telephone and data networks as two separate logical distance networks, ignoring the facility overlap just discussed.

CentralOffice

DSL Modem

Cable Modem

Public Metro Net


ISP

Dial-up Analog Line

TelephoneModem

DSLAM

Carrier POP

Public and

Private Internet


11

Figure 1.5 The Logically Separate Converged Networks

Carrying Voice and Data How do converged carrier IP networks connect to, receive, and carry local PSTN telephone traffic? The basic approach is to set up paths (and calls) by means of intelligent agents that are placed at the edge of the current long-distance backbone network. These agents include high-capacity routers at the entrance and exit points to the long-distance backbone network, which receive and transmit the voice and data packets. Intelligent call agents are then placed at strategic locations in the network to receive call-setup messages from the signaling (SS7) component of the telephone network. The entire network will eventually have a set of multiprotocol label switching (MPLS) path handlers placed at strategic points in the network. These MPLS nodes will allocate paths through the network based upon labels to be placed in each packet transmitted. The labels will indicate the priority of each packet and the nature of its content. This emerging structure of the long-distance backbone network is portrayed in Figure 1.6.

IP NetworksPrivate Line, WAN,

Public Internet

PSTN

IP PBX

IP PBX

IP PBX

IP PBX


12

Figure 1.6 Connecting Local Telephone Traffic Using

a VoIP Carrier Net with MPLS This emerging national IP network, enabled by a set of multiprotocol label switches, will be able to carry all modes of traffic, from standard voice traffic generated from the local telephone network to public and private IP traffic arriving from ISPs and data networks. VoIP traffic will be considered just another set of IP packets, with a special label applied for switching at a priority level through the network. Open Standards for VoIP There are a series of open standards, including H.323, SIP (session initiation protocol), and MGCP (media gateway control protocol), which are available for controlling voice calls that are transmitted using IP. Each protocol is supported by a well-established industry core standards organization—the International Telecommunication Union (ITU) for H.323 and MGCP, and the Internet Engineering Task Force (IETF) for SIP. To read through any discussion of VoIP standards is a tedious process. However, a thorough understanding of the differences between the alternative protocols

Call Agent Call Agent

MPLS Path Handler

LOCAL PSTN

LOCAL PSTN

National IP Network

SS7

Voice

PRI

MPLS Path Handler

SS7

Voice

PRI


13

is critical to enhance the decision-making process, to say nothing of the consequences of choosing one mode of VoIP service over another. These protocols are a set of similar (but competing) variations on a common theme. The older, more established H.323 emerges from the enterprise LAN and videoconferencing world. The data network vendors such as Cisco Systems have been the major supporters of H.323 implementations. Yet it is the international telephone standards institution (the ITU) that provides the H.323 standards, not a data or Internet group as one might have expected. In contrast, the other principal protocol for transmitting voice over an IP–based data network is SIP. SIP has been the protocol used by the telephone companies to offer VoIP–based data networks. Yet SIP is a standard supplied by the Internet group, the IETF. An additional protocol, MGCP defines the gateway function for both SIP and H.323, while MEGACO (media gateway control) provides a slightly different variation. And as one might expect, there were a number of dominant vendors that were involved early in the process of providing VoIP services and products. One such early provider, Cisco Systems, has its own proprietary protocols (such as its “Skinny” protocol, which will be discussed in Chapter 6) and unique software packages (such as its Call Manager package) in addition to supporting the universal H.323, SIP, MGCP, and MEGACO standard protocols, which are in use throughout the industry and have received general industry support. Early entrants in providing VoIP products, as well as services, applications, utilities, terminals, gateways, and gatekeepers, have seized on the opportunities for bypassing the metro and long-distance toll charges. Other entrants specialized in providing PC telephone calling software. And there were still others who provided Internet-based long-distance and international calling services or provided backup and offload alternative long-distance and international connections to the carriers. But now the pre-standardization period is passing, and VoIP is becoming a mainstream service offered by RBOCs, CLECS, long-distance carriers, international carriers, and virtually any entrant to the transport business.


14

Who will standardize the protocols used by VoIP? Fortunately, this task doesn’t require the creation of new standards bodies. The two existing standards bodies, the IETF and the ITU, are extending their standards to incorporate the requirements of VoIP traffic. The real issue, of course, is this: Which of the competing standards is emerging as the industry standard for the future? At this point, it would appear that the answer to this question is SIP, augmented as needed by one or more of the gateway protocols, such as MGCP or MEGACO. The IETF standardizes IP, which is used over the public Internet and over the public and private data networks, which use IP as the principal transport protocol for packetizing and addressing the components of a message. The standards that the IETF has provided are used for VoIP and extended as needed by the IETF to support additional use of the protocol for voice traffic. The ITU currently standardizes global telephone networks and the services that are provided to support and augment them. The ITU standards and the IETF standards can be combined to create the standards for carrying IP traffic over the local, metro, and national networks. A number of VoIP protocols are currently available, some competing with each other. The ITU recommends a standard that has emerged from enterprise networking. H.323 defines a family of specialized protocols that specify a distributed architecture that supports a variety of media and multimedia applications, including voice, data, audio, and videoconferencing. The competing protocol, SIP supported by the IETF is used for the same kinds of multimedia applications and traffic that H.323 supports. The early smart money is on supporting SIP and introducing SIP–oriented phones, switches, and routers. This is despite the fact that H.323 has been around and in use for more than a decade, established the first customer and provider base, and is still the principle supported product offered by many VoIP hardware vendors. There are a number of other protocols available to support both H.323 and SIP traffic. H.248 (from the ITU) defines a protocol


15

that enables a gateway device at the edge of a enterprise’s building or campus to interface their local enterprise network to private-line trunks, wide-area services, or the public telephone network. The IETF provides two standards, IETF RFC 2705 and 2665, which is the present architecture for the creation and support of centralized multimedia applications, including VoIP service. MGCP and a MEGACO are available for creating and offering centralized service to an enterprise VoIP network. So, not only do we not have one standard protocol for VoIP (yet), but we have to interoperate with a litany of other technologies. Furthermore, we can’t simply employ pure VoIP by itself over an IP network. We must also interconnect to the existing telephone network and standard telephones, as well as to other connection services such as the ISDN (integrated services digital network), which has its own unique digital terminal equipment. Figure 1.7 shows the collection of devices used with an H.323 implementation of VoIP, as well as devices in standard PSTNs and ISDNs with which H.323 devices must communicate and to which they must be connected.

Figure 1.7 The H.323 VoIP Family Interfacing with Traditional Protocols and Devices

V.70, V.90, V92 Dial

Terminals

H.324 PC Terminal

Standard Telephone

H.320 Phone

Digital Telephone

H.323 GatewayRouter

H.323 Message

Control Unit

H.323 Gatekeeper

ServerH.323 PC Terminal

H.323 IP Telephone

H.323 V0IP Network

IP Network

Standard Telephone Network

ISDN Network


16

Each of the possible devices that can exist in an H.323 network employs a different sub-protocol of the H.323 set, whether it is voice equipment, other audio equipment, video equipment, or a data device such as a PC. For voice, audio, and video devices, a compression component (codec) and algorithm are included. Each codec follows a different specification, such as H.261 for video and G.711 for audio. However, PCs use the T.120 specification without compressing the transmitted information. The variety of equipment and the protocols they employ are presented in Figure 1.8.

Figure 1.8 Specific Standard-Based Component for Each Source Type

Conclusion Although VoIP service is the hot topic in the telephone industry, multiple standards still exist. Interworking of vendor products and alternative protocols still remains a problem. The quality of the telephone conversations is still questioned, and the savings to be

Video Equipment

Audio Equipment

User and System Data Applications

System Control H.245 Control

H.225 Call Control

H.225 RAS Control

T.120 and H.225Data Transfer

Video Codec H.261 and H.263

Audio Codec G.711, G.722, G.723, G.728

G.729


17

achieved while undergoing a change-out of phones and PBXs, and the addition of gateway and gatekeeper devices, seems to imply a significant initial cost for the uncertain benefits that might accrue. However, the direction of the complete national network is toward an IP–based architecture, and voice traffic seems to be moving in this common direction.

19

Chapter 2

Characteristics of Voice and IP Traffic The telephone network has been constructed, upgraded, modernized, and made universally available for more than a century. Telephony equipment consists of user equipment, such as telephones and faxes, protocols, switching equipment, lines and trunks, and a signaling network The standard telephone is connected to a local CO switch by two wires (with a four-wire connection within the home). The local-loop line is a 64 kbps connection. However, the voice call uses only about 4 kHz of the available analog line capacity. This translates into about 8 kbps of the available 64 kbps line capacity. The line-setup signal and the call itself are delivered as a continuous analog signal. This signal is usually digitized at the switch and sent over inter-office circuits, before being converted back to an analog signal for delivery to the destination home phone. This voice frequency utilization is portrayed in Figure 2.1.


20

Figure 2.1 Voice Using the Low End 4 MHz of

the Frequency Spectrum of the Line Moreover, telephone conversation tends to consist of 50% to 60% silence (pauses), which could be eliminated by compression software at either side in a VoIP environment. Because the call is traversing the telephone local loop at either end of the connection, echoes may need to be suppressed. Furthermore, the human ear is particularly sensitive to delays and irregularity of verbal pacing. Delays of 150 milliseconds or more are irritating to the listener. Delays greater than 150 milliseconds are noticeable and up to 300 milliseconds are annoying. Furthermore, any irregularity of packet arrival (jitter) is also annoying to the listener. Lost sound is even more annoying, with a maximum tolerance for voice packet loss being about 1%, although less than 0.5% is preferable. This is important, as most IP networks have traditionally dropped some packets to anticipate and avoid congestion in the network. The ITU specifies a delay budget (the maximum amount of tolerable one-way delay) of 150 milliseconds (ms) for voice traffic. This compares with a maximum of 500 ms delay for satellite

OutputVoltage

Frequency(K-Hertz)

1 2 3 4.2

Voice Signal

Voice Channel

Tone DialingSignals

Systems ControlSignals

Chapter 2: Characteristics of Voice and IP Traffic

21

transmission, and 800 ms for fax and broadcast transmission as presented in Figure 2.2. Most customers would never tolerate the delay incurred with satellite transmission, although news people and mountain climbers have employed satellite phones for transmitting from difficult locations. IP phones and VoIP processes must deliver their transmission within the tight constraints of the standard 150 ms delay that telephone users have become accustomed to over the years. The real question remains of how customers will react if their voice quality deteriorates toward the level of satellite quality. We know that customers throughout the world have adjusted to the vagaries of cellular quality. But the minimum quality level they will be willing to accept on a permanent basis is uncertain.

Figure 2.2 Where the Tolerable Voice Delay (150 MS)

Fits among Other Broadcasts Public Telephone Network Service versus IP Networking With the public telephone network, as has been stated, the line-setup signal and the call itself are delivered as a continuous analog signal, which is then digitized at the CO switch and sent over

Voice Quality

Satellite Quality

CB Quality

0 100 200 300 400 500 600 700 800 Time in msecs

150 msec Maximum Target Voice Delay

FAX and Broadcast Quality

Voice - the Most Restrictive and Smallest Tolerable Level of Delay


22

interoffice circuits, before being converted back to an analog signal to the destination home phone. In contrast, early PC voice software was symbolized by VocalTec’s Internet Phone, which provided a mobile phone or CB radio quality conversation when two users conversed over a dial-up link to their local ISP and over the Internet. Both users of this service needed to be connected to their ISP; the connection needed to be pre-scheduled; and each needed to know the 32-bit IP address of the other party. In this scenario, IP addresses are dynamically provided to the user by the ISP using a special DHCP when each connection to the ISP is established. Once an IP address is received by the sender from the ISP and the IP address for the destination is received from a domain server in the network, the user’s voice conversation is segmented into packets that contain both the source and destination IP addresses. This process adds addressing overhead to the message (about 6 kbps) resulting in a 10 kbps transmission. However, telephone conversation tends to consist of between 50% to 60% of silence and pauses by the speaker, which can be eliminated by compression software on the PC at either end. This compression brings voice traffic down to a smaller amount to be transmitted each second, thus making IP–based voice an attractive proposition. IP Voice Standards A set of standards are required to control voice traffic so that these problems are alleviated and quality voice is delivered. The telecommunications industry has supported a broad standard set (such as H.323 and SIP) that provides standards for the wide range of voice and multimedia services that are driving networkers to converge around IP–based networking. Table 2.1 presents the wide array of standards under the H.323 version, many of which were initially used for videoconferencing but now provide the basic set of audio and video standards for VoIP, voice over Frame Relay, and voice over ATM networks. Furthermore, they now provide the protocols for the compression and transmission of all forms of multimedia as they continue to evolve.


23

Video Conferencing Standards

NetType ISDN ATM PSTN POTS LANS Standard H.320 H.321 H.322 H.324 H323Year Std 1990 1995 1995 1996 1996-98Audio G.711 G.711 G.711 G.723.1 G.711

Codec G.722,28 G.722,28 G.722,28 G.72 G.72-29Audio Rates 64 kbps 64 kbps 64 kbps 6-8 kbps 6- 64 kbp

Video H.261 H.261 H.261 H.261 H.261Codec H.263 H.263 H.263 H.263

Data T.120 T.120 T.120 T.120 T.120Control H.230,42 H.242 H.242,30 H.245 H.245Multiplexing H.221 H.221 H.221 H.223 H.225Signaling Q.931 Q.931 Q.931 Q.921

Table 2.1 The Array of Multimedia Standards Used

by a Broad Set of Networks Although H.323 is the umbrella standard that is intended for the transmission of visual, voice, and data traffic over packet networks, this standard is independent of the underlying network's topology of bridges, hubs, switches, and routers. H.323 relies on TCP/IP to perform Layer-2 and Layer-3 packet addressing, forwarding, and recovery functions. The protocol begins with the standards for H.323 terminal equipment, including audio devices with compression components (codecs), and includes the sub-standards G.711, 722, 723, 728, and 729. It also includes the video compression standards of H.261 and 263 and the data interface T.120. To provide system control functions, the standards H.245 and H.225 are required. And for interface into other connection-oriented networks, the H.225/Q.931 call-setup standard is employed. Table 2.2 presents an array of many of the sub-standards that are included under the H.323 umbrella standard. This implies that a whole range of standards and their interpretation is required to provide for the transmission of the range of media desired by users.


24

Table 2.2 The H.323 Protocol Sub-Standard Component Family

Basics for Transmitting Voice in IP Packets When voice conversations are transferred over dial-up analog local-loop lines to the local CO switch, the sound pressure that results from the speaker’s vocalization is converted to an electrical signal pulse represented by the continual up-and-down rolling of a sine wave (similar to the ups and downs of hilly terrain). The variations of this rolling sine wave represent the spoken words. At the CO switch, the sine wave carrying the analog voice conversation must be converted from this continuous wave form (the analog signal) to a digital form. The sine wave of the conversation is sampled twice for each up and down portion of the continuous wave that represents the conversation. This sample is digitized into the “0” and “1” (binary) coding of the conversation. The binary coding is then modulated back onto an electrical signal and sent through the switch and on through the metro (and possibly national) network as a digital code. At the destination switch, the binary coding is delivered on a digital trunk to a destination PBX, where it is converted back to an analog signal, or it is directly converted to

H.323 PROTOCOL MULTIMEDIA OVER LANs

VIDEO AUDIO CONTROL/ MANAGEMENT DATA

H.261 G.711, 722 RAS Signaling Control

H.263 G.723 H.225 H.225 H.245 T.124

G.728,29

RTP X.224 Class 0 T.125

UDP TCP T.123

IP T.123

LAN Layer 2 IEEE 802.3


25

analog by the CO switch for transmission to a phone over an analog local loop. As part of this conversion of analog voice to a digital representation, a very fast codec at the telephone CO is used to avoid any delay in the transmission. Silence, usually up to 50% of the conversation time, is often compressed out of the transmission and replaced by a special code to reproduce the silence on the other end. Then, as part of carrying voice in IP packets, when the resultant “packet” has been created, it is transmitted as an unconfirmed “best-effort” UDP segment in an IP packet, rather than a confirmed and guaranteed segment transmitted by TCP (transmission control protocol). TCP performs its guaranteed function by marking each segment with a sequence number and an acknowledgement number so that the standard TCP three-way handshake can occur to confirm reception. If no confirmation occurs, the originating TCP resends the unconfirmed segment or a group of them, which are clustered into a “window” of segments in IP packets. Avoiding the delay associated with confirmation is thus a necessity for VoIP transmission. At the reception side, packets and their enclosed segments are put in order, and silence indicators are used to put back the silence component (up to 50% of the conversation) in analog form. Any echo is cancelled out, and the recreated conversation is passed to either an analog line and then to a telephone, or directly from an IP phone to the human ear in the form of sound waves appropriate for the human ear. The listener should have the impression that the original communication in its original form is being delivered, with no impression of the encoding, digitization, and transmission, and any processing along the way showing in the end product. Frequently, a standard version of “background noise” is filled into the recreated silence portion to make the blank sound period appear natural when it is added at the reception point. All of this process must occur within a delay period that the receiving ear automatically interprets as normal. This is a difficult task. The speaking, sampling, encoding, segmenting, and


26

packetization process can take up to 64 ms. At the receiving end, another 64 ms can occur in the re-conversation of the digital packet and segment back to analog form with the silence reinserted. This adds up to a total of 128 ms in total for both end processes. The standard for “toll quality” calling is a 150 ms delay. This leaves only 22 ms for the transmission over a network, which contains many boxes and processing modules. Delay must be accounted for in the total transmission. Furthermore, there is a normal window of time in which the receiver will wait before expecting to respond and once again before the originator expects to hear a response. Figure 2.3 shows the sending and receiving process with a sequence of timing summations to indicate how narrow the time frame is for the entire process and how small the opportunity is for any correction.

Figure 2.3 The Speaking and Hearing Side Delay Process Sum Totals

Based upon the compression standard employed by the digitizing device (IP phone, IP PBX, telephone switch, or gateway router) that is associated with the transmission speed of the line, originating compression (and receiving decompression) can vary from 0.75 ms to 15 ms. A set of the possible codec compression

Sample Encode Packetize Transmit

45 msec 64 msec < 100 msec

45 msec 64 msec

Output Decode Jitter Reconstruct ReceiveBuffer

Speaking

Hearing

Total of Less Than 250 msecs of Delay is Tolerable

But Delay of Less than 150 msec is the Standard

Network


27

protocols, and the expected delays that they contribute to the process, are presented in Table 2.3.

Table 2.3 Delay Times for Various Compression Standards

Key Parameters for an Acceptable Voice Network The three principle parameters for defining a satisfactory level of quality for voice carrying networks are (1) the maximum amount of delay experienced, (2) the amount of packets that are lost, and (3) the amount of variation or jitter in the arrival rates at the reception phone. Delay is the latency experienced in the flow through the network of packets. As has been indicated, 150 ms is the maximum delay that is deemed tolerable. Packet loss is obvious and can occur due to damage to the packet, buffer overflows, and deliberate approaches suggested by vendors to avoid congestion in the network (such as Cisco Systems’ recommended WRED, or weighted random early detection, of selected packets).

Compression Method Delay(msec)

64K PCM (G.711) 0.75

32K ADPCM (G.726) 1

16K LD-CELP (G.728)

8K CS-ACELP (G.729) 15

8K CS-ACELP (G.729a) 15

3–5

Voice Quality Delay From Various Compression Methods


28

The maximum acceptable packet loss in an IP network has traditionally been 5%. However, at that level of loss, the resulting voice sound can certainly be irritating to users and sound much like cellular calling or satellite telephoning. Jitter is the more ephemeral of the parameters and frequently the most difficult to control. Variation in packet arrival rates at the destination device can occur for a variety of reasons ranging from the volume of traffic on the network to changes in the routing tables, equipment, paths, or specifications employed. Jitter buffers are usually employed at both ends to hold between 30 to 60 ms of voice packets so that the end stations can adjust for any variation in the flow timing. When voiced traffic is sent as an uncompressed digital stream, such as analog voice, which is digitized by pulse code modulation (PCM) and merged with 23 other calls over a T1 digital trunk, the silence is treated as part of the regular voice transmission and is not compressed out. This may double the amount of bits transmitted, but the compression and decompression times do not cause delay or reception variation (see Figure 2.4).

Figure 2.4 Inter-Site Voice Connection Alternatives

PBX

PBX

PBX

PBX

Gateway Router

Gateway Router

Edge Router

Edge Router

Local Switch

Local Switch

PSTN

WAN Services

Public and Private Internet


29

VoIP Overhead and Its Effects Packet and cell-based networks require an overhead for addressing and other indicators added to each packet of up to 10% of the total packet size. This additional transmission requirement, plus the total size of resent packets for data, can provide a significant load on the network beyond the message to be delivered, and this is not good for either the sender or the network. This process places an additional burden on the network and provides more opportunity for delay through the network at buffers and queues in the switches. The General VoIP Architecture Model When considering the transmission of voice over IP–based networks, it helps to have a basic model of how both IP phones and PCs employed in businesses connect to both the public telephone network and IP–based networks. The IP phones connect by way of an Ethernet LAN to an IP PBX or IP server performing the functions of a PBX. That PBX then has the option of converting the call to a digital but non-packetized voice stream and sending it by trunk to the telephone CO for transmission over the public telephone network. Alternatively, the PBX can send the packetized voice traffic to a gateway router for transmission over a number of classes of IP–based networks. This includes IP over private lines, such as T1s, and IP over wide-area networks (WANs), such as Frame Relay or ATM network services. It should be noted that PCs also connect to the same IP networks by means of the gateway router. A similar structure of connections exists at the destination location. This basic VoIP model is presented in Figure 2.5.


30

Figure 2.5 Model for Connection of IP Phones and PCs

to PSTN and IP Networks However, carriers are now targeting residence customers as well as business enterprises for VoIP service due to the number of customers subscribing to broadband services such a DSL or cable-modem connections through their cable TV service. These broadband connections from the home were portrayed in Figure 1.2 in Chapter 1 and are repeated in Figure 2.6 for reference. DSL service connects to IP equipment in the telephone CO. Cable-modem service connects to a router in the head-end office of a cable company. Both then have their IP packets passed on to the Internet or converted to telephone signals and sent on to standard telephone company CO switches.

r

S

C is co 7 0 00

E RIE S

OWR W

C ISCO Y S TEMSS

LAN

Telephone C.O. Switch

Gatekeeper

SDm er idia n

3D EF2 ABC1

6M NO5 L

9Y

8V

#0Z

4 I

7S

*

r

a e

an e

D u a M o d e M i r o c

Cis c o 7 00 0

E R IE S

OWR W

CIS CO YS TE M SS

Source PC Telephone Destination PC Telephone

DestinationIP Telephone

Gateway Router

Gateway Router

S Dme ri d ia n

3 DE F2 AB C1

6 MN O5 L

9Y

8V

#0Z

4 I

7S

*

r

ae

ane

D ua M o d e M i o c

IP Phone

IP Server/PBX

LANIP Network LANLAN


31

Figure 2.6 Residential Voice Access and Transmission Model Voice Content Packetization When voice conversations are transmitted in packets, the voice stream must first be chopped into pieces, and each piece of the conversation placed in its own packet for individual transmission. Once each voice component is placed in packets, these packets have a header formatted in the standard fashion. The header attached to each voice fragment contains a link address for the local network link or a next router link, an IP address for the destination phone, a UDP (user datagram protocol) port for defining what application receives the packet payload, an RTP (real-time transfer protocol) for informing the destination device about packet sequencing and timing, and the conversation fragment itself as the IP payload. The combination frame containing all of these addresses and indicators pre-pended to the voice payload is portrayed in Figure 2.7.

CentralOffice

IP Telephony

Adapter

DSL Modem

Cable Modem

PSTN

Public and

Private Internet



32

Figure 2.7 The Standard VoIP Packet Format

Voice Packet Transmission Having packetized the voice conversation fragments and addressed the destination user’s IP phone or port on an IP PBX, the packets are released to the network. But before they can be released, a first packet must be sent asking for a logical connection to be made to the destination user, and a packet must be received back from that user indicating they are there and ready to receive the call. Much like a standard telephone call has a preliminary dial process—an off-hook with a “hello” from the receiver before the conversation begins—there is the call-setup packet, the acknowledgement returned, and the subsequent transmission of packets, together mimicking that original telephone process. A “hang-up” sequence occurs at the end with a returned connection cancellation message and an acknowledgement from the originator. Voice Packet Reception At the destination site on the user IP phone or PBX, as part of the voice packet reception process, the frame containing each call

The Standard VOIP Packet Format

Link

Header

IP

Header

UDP

Header

RTP

Header

Voice

Payload

VoIPPacket

X Bytes 20 Bytes 8 Bytes 12 Bytes X Bytes

G.711 Standard has a 160 Byte Voice Payload

G.729 Standard has a 20 Byte Voice Payload

G.723.1 Standard has a 24 Byte Voice Payload


33

fragment is unpackaged. The link portion of the header is removed, the IP address is removed, and the UDP port number is examined to determine the appropriate software on the end device, which is expecting to receive the call. The RTP header helps put the conversation pieces in order and assists in the timed release of the conversation to the user. Standards for VoIP Beyond H.323 Although H.323 is well established as the early protocol for session establishment when transmitting voice conversations over IP networks, two other standards (SIP and MGCP) are gaining increasing support and, as has been acknowledged, are likely to become the general standards in the near future. The first, SIP, was developed by the IETF’s Multi-Party Multimedia Session Control Group as a less complex procedure for use over the Internet. SIP is independent of the underlying Layer-2 protocol, which can be ATM, Frame Relay, X.25, or PPP (point-to-point protocol), with IP operating with each. SIP has an Internet-friendly HTTP (hypertext transfer protocol) text-based encoding and includes encryption and authorization functions. The other relevant protocol is MGCP, which provides an alternative to H.323’s gateway control. MGCP operates as a gateway service to transmit between two gateways and a central controller. These gateways and gatekeepers are similar to H.323’s gateway and gatekeeper servers. The gateway servers provide telephone-number-to-IP-address translation, while the central controller provides connection call control and a telephone signaling interface to the PSTN of the RBOCs. In addition, there is the Telecommunications and Internet Protocol Harmonization over Networks (TIPHON) standard, which is a European Telecommunications Standards Institute (ETSI) approach for interoperability between IP and circuit-switched telephone voice networks. Version 1.1.1 of the TIPHON technical specification was released in November 2000 and covers the architecture, call admission and control procedures, address translation, and quality of service (QoS) issues.


34

Interconnecting VoIP Nets to the Public Telephone Network Each of the available competing VoIP approaches has a unique set of messages that are employed to establish a connection over an IP network, much like establishing a connection over the public telephone network. H.323 has its own call-setup messages, call-proceeding messages, and call-control messages. SIP has Invite and Acknowledge messages for call setup. And MGCP has its own call setup and acknowledgement process. These three alternative message streams are portrayed in Figure 2.8. Each of these streams of connection-establishment messages can be converted into the standard dialing process for the telephone network so that VoIP networks can also connect through the public telephone network. Once converted, the signaling digits can be passed to the telephone network’s SS7 signaling network to set up a connection path. Subsequently, the IP voice conversation packets can be converted to telephone format for transmission over the path that has been reserved by the SS7 signaling network in the common fashion of the telephone network.

Figure 2.8 Connecting VoIP to Telephone Signaling Networks

H.323

SIP

MGCP

H.225 Call SetupCall Proceeding

H.245

CRCAcknowledgement

SDP

InviteAcknowledgeSDP

PSTN SS7

Signaling Network


35

Assigning IP Telephone Addresses – DHCP But where do the IP address assignments come from? How do they get assigned? We are familiar with PC NICs (network interface cards) having an Ethernet MAC (media access control) address. And we also have experienced the process of dialing into our ISP from home and having the ISP assign and download an IP address (example: 226.162.140.111) for temporary usage which is then associated with our e-mail alias (such as [email protected]). In a similar fashion, many companies do not allocate permanent IP addresses to their PCs, but rather download an IP address to each PC in the company when that PC is turned on and requests an IP address, if it is attached to the local corporate Ethernet. That IP address either remains assigned to the PC or is changed at the discretion of the network administrator. In similar fashion to the corporate PC address assignment, with VoIP implementation each IP phone has a local MAC address but does not come with an IP address of its own. To supply each phone with its own IP address, an enterprise or service provider must set up a server that stores valid assignable IP addresses that have been authorized by the Internet agencies. Once each IP phone is plugged into an IP network, it broadcasts its MAC address and a request for an IP address. The server then responds with an IP address that the phone can use and the address of any call-assisting devices to log into and use when making telephone calls. Telephone profiles for the phone, including a telephone number and what features are supported by the instrument, are then uploaded from the phone to the server. Furthermore, when an enterprise uses private IP addresses (such as 10.x.x.x or 172.x.x.x) rather than one of the public IP addresses that are known to the Internet, a NAT (network address translation) server maintains a table of a limited number of public IP addresses that the company has acquired for shared use. One of these public IP address can be temporarily loaned out to an IP phone user and cross-related in a table with a user’s private IP address. Then, when outside calls are made, the NAT server can translate local IP addresses to the loaned public IP address for


36

temporary use while the call is in progress. The public IP address can then be reused by another user at the termination of the call. Conclusion Voice traffic places only a small additional load on IP networks. Each call requires about 8 kbps of bandwidth, but when silence is compressed, only 4 kbps is utilized. Of course, many simultaneous calls add up to large capacity requirement, but not everyone in an organization is on the phone at one time. However, the peak business hours of 8:00 am to 10:00 am and 2:00 pm to 3:00 pm, especially on Mondays and Fridays, can present a load problem when added to a data network. But a more difficult issue is that voice traffic is extremely sensitive to delay and variation in arrival times. This means that voice must always be prioritized above all other traffic as it proceeds through the various nodes in an IP network. Voice traffic requires special handling and can not be treated as merely an add-on to an enterprise’s data network.

37

Chapter 3

VoIP Models for Connection As business enterprises and residence customers seek to employ VoIP for some or all of their voice communications, they usually want to preserve their connection to the public telephone network for some of their calling. This may primarily be for local calling within the community or across a metropolitan area. Where flat-rate service pricing in the local area still exists, some of the incentive for this dissipates. However, as the costs for local message calling across the metro area increase, these local calls may move over to the IP network as well. These local call charges may vary based upon the minutes of use, the time of day in which calling occurs, or the distance the call travels across the metropolitan area, with each being subject to rate increases. Thus, the cost of calling can increase due to changes in the RBOC local billing plans or merely due to an increase in the volume of such calls that a consumer makes. All of these issues provide an incentive to move local calling to IP networks and bypass the local telephone network. However, at least in the transition stages, connection to the local telephone network is expected to continue for some time. Once VoIP service has been initiated, IP customers’ principal connections for voice traffic will become the same as for their data traffic, traversing their primary IP connection networks. These IP networks likely include a private-line connection to another site, or sites, across the city and even across the region or nation. These customers’ voice traffic can be placed on the same private lines as their data traffic, with priority given to the voice traffic, since voice communication is the most time-sensitive, as has been noted. If the enterprise has subscribed to a WAN service, such as Frame Relay or ATM, for their data traffic, the enterprise is likely to place their voice traffic on those WAN networks as well and share the existing trunk connections to those services also.


38

As a new alternative to the established services, many carriers and RBOCs are offering VoIP connection over their managed, private IP service, which they use for VPN service and similar managed services. To maintain the QoS, the carrier usually transports delay-sensitive traffic around the more delay-prone public Internet onto the vendor's high-bandwidth fiber links. Over these private links, they operate and control the capacity available to each call and can manage the traffic flow. However, the service provider also still has the option to route the voice traffic directly over the public Internet. Moreover, even when the traffic is routed around the public Internet across the country, the call packets can be still connected to the public Internet near the destination, for delivery to the destination site. Residential users can connect their VoIP traffic in a similar fashion. The residence customer can employ an IP adapter for their standard telephone, such as the service Vonage offers, and access the public Internet by means of a DSL modem and broadband link or cable modem and cable link. They may also use an IP phone and plug that into an Ethernet connection, DSL, or cable modem. It is also possible that they might connect over standard telephone lines to an RBOC CO and that the RBOC might “packetize” the voice traffic and transmit the call by means of a CO router and a link to the public Internet. These RBOC services are not yet offered but are potentials for the future. Enterprise Connection over Public and Private Networks The following figures portray some of the aforementioned principle enterprise (and residence) connections for voice traffic over the various options of the public telephone network, the public Internet, or private-line or WAN connections for private Internet traffic. As shown in Figure 3.1, a single site for an enterprise business can have a basic telephone connection from their PBX to the local telephone network. They can also have a private-line connection to an ISP and onto the public Internet. As an additional alternative, it is possible to use a private-line connection to a carrier’s private Internet network, where they might subscribe to a VPN service for employee call-in while on the road or working at home. These connections to the public and

Chapter 3: VoIP Models for Connection

39

private Internet service can be used to carry their VoIP traffic in early implementations and may eventually completely replace their public telephone connection.

PSTN

Public Internet

Gateway VOIP Router

IP Phone

Private Internet

IP PBX

Figure 3.1 One-Site Enterprise VoIP Connection Options

Many smaller companies may only have two sites between which they have their major communications. For example, they may have an office on one side of town and a production, manufacturing, and/or warehouse site on the other side of town. Frequently, such enterprises choose to connect their two sites with a private-line connection, such as a T1 trunk, for data and for site-to-site e-mail transfer. Under these circumstances, the company can mix their inter-site voice traffic with their data traffic over the leased trunk, or trunks, between the two locations. At the same time, they may still maintain their existing connection to the public telephone network for voice traffic to all other locations. They may also even have a WAN service to any distant site. This is portrayed in Figure 3.2.


40

Figure 3.2 Two-Site Enterprise VoIP Alternative Connections

The more sites a company has and the more states in which they operate, the more likely the company is to employ a variety of network services. Among these services are WAN service and VPN service, as well as connections to the Internet. The company can choose from an array of these options for sending its voice traffic through these various data and Internet connections. Each will deliver that voice traffic in the form of IP packets containing the voice traffic. The company will usually also retain a connection to the public telephone network. Figure 3.3 presents a multi-site connection with an array of potential networks for carrying the voice traffic (as well as the data traffic) between the many sites.

IP PBX

PSTN

Public Internet

Gateway VOIP

Router

IP Phone

Private Line or Private Internet

IP PBX

IP Phone

Gateway VOIP

Router


41

Figure 3.3 Multi-Site VoIP Connections

Residential Connection over Networks In contrast to business approaches to VoIP connections, residences tend to have a reduced volume of calling and only a few telephones and PCs to connect. Residential customers tend to call around their local community and to family members spread throughout the country. This tends to be a less-focused voice communication need, with calling not limited to specific sites, although intra-family connections may mimic a multi-site business connection requirement. As the local telephone companies experience demand for vendors and carriers that offer VoIP service, they may offer IP voice packetization and forwarding from equipment in their local COs, bypassing their own circuit switches, which are primarily used to switch standard telephone calls. These alternate switches are commonly termed “softswitches” or “multiservice switches”. A major aspect of these switches is that they have ports that connect to a variety of network services. They have T1 trunk ports carrying traditional voice; they have trunk ports supporting IP traffic with

IP PBX

PSTN

Public Internet

Gateway VOIP

Router

IP Phone

Private Internet

IP PBX

Gateway VOIP

Router

IP Phone

IP PBX

IP Phone


42

simple PPP; and they have trunk ports supporting Frame Relay and ATM connection services. As such, they are software-based switches, with the software enabling the support of multiple services. The employment of these switches for carrying voice traffic over an IP network is presented in Figure 3.4.

Figure 3.4 Residence Dial RBOC–Supplied VoIP Service

In a similar fashion to the local RBOC, other telephone service providers are moving toward offering VoIP via a special multiservice switch rather than their legacy circuit switch. The prevailing trend among long-distance providers offering VoIP service is to by-pass the local telephone company’s CO switches. To compete with this trend, the RBOCs, such as SBC and Verizon, are offering to bypass their own telephone circuit switches. They are offering to bring broadband DSL voice traffic to multiservice switches and carry the traffic on to the Internet. The carriers also connect customer traffic to their ISP locations over local broadband connections. One approach is to use the existing local telephone loop from the telephone CO to the home but to connect to a DSLAM at the CO rather than the telephone

Telephone Central

Office Building

PSTN

Public Internet

Gateway VOIP

RouterPrivate Internet

MultiService Switch

Dialup Modem


43

switch. The connection can then be made to the public Internet (or a private Internet) service or to the public telephone network. When the calls bypass the local telephone switch, they are no longer tagged as long-distance calls, and the local telephone company no longer gets a portion of the long-distance revenue as a recovery for originating the calls over their local loop facilities. How the FCC is going to treat this recovery process is an important issue for the whole telephone and data networking world. The LECs (RBOCs or local telephone companies), which have great lobbying influence, would like VoIP calls to be subject to the same allocation arrangement as traditional circuit-switched calls. However, they are actually of two minds on the issue, as they would prefer their own DSL service to be treated as an unregulated service, avoiding the requirement to unbundle the facilities and allow competitors to lease lines and services at discount rates. There may also be a reduction of local taxes associated with distance IP calls as well. And the allocation of local, city, and state taxes on calling plans has been a touchy subject for many decades. The DSL connection around the local circuit switch is portrayed in Figure 3.5.

Figure 3.5 Residence DSL VoIP

Telephone Central

Office Building

DSL Modem

DSLAM

PSTN

PublicInternet

Gateway VOIP Router


44

A similar residence connection can be made over a cable-modem connection. This allows voice calls to be added to the downstream cable TV traffic and data traffic on both the upstream and downstream paths. The call is delivered by the cable from the residence phone to the local cable head-end office, where it is forwarded by means of a router and a leased trunk to the chosen ISP. From the ISP, the traffic is passed on to the public Internet. The call can also be delivered by a leased trunk to a carrier’s point of presence (PoP) office for connection over a national or regional WAN service or over a private-line connection directly to another site. Figure 3.6 portrays these various alternative connection modes.

Figure 3.6 Residence Cable VoIP

Currently, companies such as Vonage are offering an adapter so that traditional phones can have their voice communication digitized, packetized, and compressed for transmission over the customer’s broadband connections, such as the aforementioned DSL and cable systems. Using any of these connection models, subscribers have a wide variety of options for VoIP service, and the number of participating vendors, and number of service approaches, continues to expand.

Cable Modem

CMTS

PSTN

Public Internet

Gateway VOIP Router


Private Internet


45

VoIP Terminals As previously stated, there are at least six basic models that customers might follow to obtain VoIP service. These models are primarily based upon whether they concern a business or a residential customer. Furthermore, the implementation model is likely to differ depending upon whether the service-supplying vendor is an RBOC (such as SBC), a CLEC (such as COVAD), a long-distance carrier (such as AT&T), an ISP (such as Earthlink or Iquest), or a software/hardware vendor (such as Vonage). Long-distance carriers find an advantage in offering VoIP service that bypasses the RBOC’s CO switch. Thus, they target customers who have broadband access connections such as DSL or cable modem, which by architecture are physically connected to central devices (DSLAMs and routers) that allow the CO telephone switch to be bypassed. These broadband customers do not require an IP phone to talk over an IP connection but can use a Vonage-type telephone adapter with their regular telephone. They can then dial and talk over their existing phone in a normal fashion, with the adapter doing all the conversion work. The call then goes over the broadband connection, around the CO switch, and on to the public or private Internet. An important issue in VoIP is whether a customer should replace all of the telephones with IP phones. Some of the early revenue to be gained by vendors of VoIP services results from the sale of IP phones and IP servers/PBXs. Small businesses tend to have only one or a small number of sites. As a result, they have only a small number of phones to replace with IP phones. But they also have limited ability to afford this replacement. Large businesses, on the other hand, tend to have larger complexes and a larger number of sites across a region and across the nation. Although they can afford to replace some of their phones with IP phones, they most likely will initially convert only limited groups that have a consistent requirement to communicate over their existent leased lines that carry IP–based data traffic to other locations. Gradually, these companies can migrate other units to IP phones as the benefit matches the affordability. The more expensive IP telephones tend to cost around $300 each, although there are less expensive IP


46

phones for less than $100. As an example of prices from a leading VoIP product vendor, Cisco Systems’ 7900 series IP phones start at about $100 for the 7905 phone and proceed up to $300 for the 7960 phone. Appendix A contains a list of some of the available IP phones and their current prices. When employing IP phones, the customer has also made a mandatory decision to purchase an IP PBX or an IP server to replace their existing PBX or to support a smaller initial VoIP group. That IP server or IP PBX can either connect to a trunk-based IP network via a gateway router or to the public telephone network via another trunk. Furthermore, the gateway router likely provides this multiple trunk connection termination. An IP PBX can cost up to $100,000, such as for Avaya’s Definity G3R PBX. And IP gateways, such as Cisco’s Catalyst 4000, cost about $7,500 for the basic chassis, with $2,000 each for special ports. They can cost up to $18,000, such as for Avaya’s 700 Media Gateway. A sample list of these devices is also contained in Appendix A. Many of IP phones and other devices also can be configured at the factory as either H.323 compatible or SIP standard compatible, and they may be ordered by the customer as part of a local voice system that is implemented as either an H.323 standard compliant system or as a SIP compliant system. H.323 has taken the early lead in implementations from 1999 through 2003, but many analysts believe, as has already been indicated, that there will be a migration to SIP as both the local and national VoIP standard. Companies that have a few sites placed around a city may interconnect these sites with private lines that they have leased from the local telephone company for their inter-site data and e-mail exchange. Initially, they may choose to place their inter-site voice traffic on top of their inter-site data traffic. Meanwhile, they continue to send their voice traffic in traditional fashion over the public telephone network. These customers need not purchase IP phones; rather they could have an IP–enabled output port on an advanced PBX, an inter-working specialized box, or a port on their gateway router whose function is to packetize their inter-site voice traffic as well as to send packetized call setup signaling. Alternately, the inter-site facilities might be placed nationally, and the customer


47

might subscribe to a Frame Relay or ATM WAN service to connect their sites. Or, they might lease a limited set of national private line trunks if they only have a few sites to link. Appendix A contains a sample of some of the IP phones that are available, as well as some of the PBXs, servers, and gateway routers that might be employed with them. Conclusion VoIP traffic can take a variety of forms. A simple form is to add voice traffic to site-to-site data traffic over a private-line trunk. A more complicated model includes voice traffic added to a multi-site data WAN service, such as Frame Relay or ATM. Finally, there is the complicated model of public network areas interconnected by way of a core IP network. The conclusion is that there is no one VoIP model but rather a family of models based upon the number of sites, the traffic to be transmitted, the existing data network structure, and whether the public telephone traffic network needs to be connected as part of the VoIP process.

49

Chapter 4

VoIP Using the H.323 Protocol Throughout the 1990s, the early implementers of VoIP were enterprises that worked with their data processing and data networking suppliers, which already supported them with products for LANs at each site and for inter-site data networking. The suppliers then offered assistance in placing an enterprise’s inter-site voice communication on top of excess capacity in their already existing inter-site trunks, which they leased from the telephone company to carry their data transfer between sites. Since this process grew out of the data-networking world, it was normal that the H.323 protocol was employed, as it was originally used for voice and videoconferencing at a local enterprise’s business site and supported by data networking vendors. Extending the protocol to multiple inter-site communications was a natural extension to what vendors and some companies already had in operation. Thus, most existing vendors supply H.323 services and hardware as a basic part of their VoIP service offering. The ITU H.323 Protocol The ITU’s specification for transmitting video, audio, and data over networks employing IP is the family of protocols that are included under the general umbrella protocol of H.323. This family of protocols covers the following functions:

• Call signaling • Transport of various media types • System control • Special specifications for conferencing, including point-to-

point and multipoint conferencing To perform these functions, the family of specifications that are part of H.323 include (a) the control specifications of H.245 and H.225 for signaling and control of transmission, (b) the video specifications including those for video compression H.261 and


50

H.263, which are performed by a video codec and are required due to the large volume that would be transmitted if left in a raw form, and (c) the data specification of T.120. However, the most crucial H.323 specifications for employment with voice transmission under a VoIP process are those regarding the compression of audio—711, 722, 723, 728, and 729. This compression is performed as a function of the IP handset and is termed the audio codec. The array of these specifications is displayed in Figure 4.1.

Figure 4.1 The Family of Protocols Supported by the H.323 Protocol

Initially, the H.323 standard solely covered devices involved in a multimedia-transmitting network. These included the transmitting terminals, the gateways at the edge of an enterprise network, the gatekeepers in the network, and the control units, including multipoint control units. Once the protocol was established for the early videoconferencing and multimedia transfer applications, it was a natural extension to apply existing protocols to carrying traditional voice calling over IP networks, in a fashion similar to how the existing videoconference traffic was handled.

VoIP—Uses Audio Component of H.323

System ControlSystem ControlH.245

Control

Call ControlH.225. 0

RAS ControlH.225. 0

VideoVideo CodecCodecH.261, H263H.261, H263

User DataUser Data Applications

T.120

H.225.0 Layer

AudioAudio I/O

Equipment

AudioAudio CodecCodecG.711, G.722,G.711, G.722,

G.723,G.723,G.723.1,G.723.1,

G.728, G.729

Receive PathReceive PathDelayDelay

System ControlSystem Control and

User Interface

VideoVideo I/O

Equipment

Session Layer

and Above

LAN Stack

Chapter 4: VoIP Using the H.323 Protocol

51

Terminals The end terminal devices for transmitting and receiving media transmission include not merely IP phones but also terminal equipment ranging from PCs, codecs for compressing the media (voice or video), a control unit element, and a network interface module to connect to the local data network. Gateways Gateways are devices that interconnect a local data network for an enterprise, such as an Ethernet network, employing IP for controlling transmission and the local and national telephone network. Such a gateway can also connect a local PBX–based telephone network with a private-line–based inter-site IP network. The basic function of a gateway is to act as an interface between a local and a distance IP network, and a private or the public circuit-switched telephone network. Gatekeepers These devices are placed out in the network at a central location. They perform services that are difficult for the edge devices at each location of a multi-location enterprise to perform. The employment of gateways at each location and a centralized gatekeeper allow the signaling and control functions to be distributed across both devices. This further allows the gatekeeper to perform authorization to use the VoIP network and to keep track of billing information and cross-charging information within departments of a business enterprise. These gatekeepers are also frequently described as multipoint control units, call-control modules, or call agents. The Operation of an H.323 Network Similar to most data-networking protocols, the H.323 protocol supports the creation of areas and the interchange of information between areas. These areas can be separate areas within a large enterprise campus complex, or each location can be designated as a unique area. Furthermore, clusters of locations can be defined as


52

within a common area. This is a concept that is familiar from both the telephone and the data world. The telephone system is composed of local offices with their own numbering system, inter-connected by means of a city or metropolitan network. At a higher level in the telephone domain, there is a LATA (local access and transport area) containing a number of cities, all commonly addressed with the same LATA number. At the highest level, there is a national number prefix that designates the collection of all LATAs and their individual telephone numbers (CO and line numbers) and customer as a combined unit. IP networks employing the OSPF (open shortest path first) routing protocol also are divided into a set of areas that are interconnected by a set of edge routers. H.323 makes use of this area concept to define one or more areas at each location that can be interconnected by a gateway router (or switch), a centralized gateway call manager with area management responsibility, and a distance-spanning IP–based network. The H.323 Frame Using the H.323 protocol for voice transmission, the voice conversation initiator uses one protocol (TCP) to send a call setup and session establishment set of IP packets and a different, less-restrictive protocol (UDP) for the actual transmission of the conversation packets. UDP, as has already been noted, is considered a "best-effort" protocol, with no acknowledgement of reception and no guarantees. TCP, on the other hand, has mechanisms for assuring that the call setup packet actually was received by the destination phone. Therefore, H.323 uses the reliable TCP to perform call setup to assure that this message is received and uses UDP for actual transmission of voice (or any supported media) messages, since the assurance mechanisms of TCP would make the continuous call sound to the listener as a discontinuous set of word phrases. Furthermore, the H.323 call control and signaling sub-protocols (H.225 and H.245) specify how devices and applications perform the call setup operation using TCP headers and processing along with IP packets and IP addressing. The specialized TCP or UDP header information that


53

is added to the IP packets containing the call setup information or conversation itself is portrayed in Figure4.2. TCP is on the left side of the figure and carries the call-setup message, while UDP is on the right side. It is the UDP frames enclosed in IP packets that carry the fragmented parts of each call.

Figure 4.2 The Multilayered Header of an H.323 Packet

Looking at the operation of a call as a set of layered operations, top to bottom, Figure 4.3 portrays, in a combined figure, the steps of signaling and the steps of transporting a voice call over an already established connection. Starting with the caller at the top of the figure, a destination telephone number is dialed. The telephone numbering scheme follows a standard national E.164 scheme that includes country code (if necessary), area code, CO number, and then line number—e.g., (1) 234 567-8910. For a moment, we will skip the audio codex level and jump down to the H.225 and H.245 level. Software and servers using these protocols will translate the telephone number that is dialed (234 567-8910) to the appropriate IP address to be used to first address the call connection setup packet, and then the subsequent voice content packets so that they can traverse an IP network.

Reliable TCP Delivery Unreliable UDP Delivery

Media Payload

IP

TCP UDP

H.245 H.225 Audio/Video Streams

Call Control RAS RTCP and RTP


54

Figure 4.3 Dialing, Compression, and Header Addressing

Layers of H.323 Transmission Looking at this set of functions again, once the circuit equivalent has been established over the IP network, the caller then sends the conversation through an audio codec (skipping the dialing), which is compressed following one of the audio protocol standards (G.711 possibly) and then placed in a set of UDP segments, then IP addressed, and finally placed in a MAC addressed frame for transport to the enterprise edge, and then sent out over the local-area and subsequently wide-area network. Figure 4.3 collapses the call setup protocols and the subsequent call transfer protocols into one combined sequence of steps. H.323 Audio Coding and Compression As has been discussed, the H.323 protocol defines a series of protocols that provide a set of functions for voice calling. The protocol first provides for sampling the analog voice signal from the speaker by the telephone or PBX, then for converting the analog audio signal to a digital form, then for placing the digital bits into packets for transmission. Alternatively, the digital voice bits

H.323 VoIP ModelSignaling and Transport

CallerE.164 Phone #

Audio Codec(G.711, G729, G.723.1)

H.225, H.245, RTP, RTCPUDP Port #

MAC Address802.3, ATM VPI, VCI

Frame Relay DLCIPhysical V.35, T1, DS-3

IP Address


55

can be re-modulated back onto an analog line by techniques of frequency or amplitude modulation (modifying the height of the pulse or the frequency that the pulse occurs), placing the modulated stream back on a telephone line. As has been mentioned, the H.323 family audio sub-protocol G.711 works with the standard 64-kbps voice transmission line carrying a 4-kHz signal. At 4 kHz, only 8 kbps of the available 64 kbps on the line is actually used for a voice call. This implies that voice calls only impose a small additional load when added to an existing data trunk. Under the G.711 protocol, the H.323 IP phone samples the analog voice stream at 8,000 samples per second. These samples are then modulated as pulses onto a line. Alternatively, the protocol G.726 uses an adapted form of this process and delivers a signal at 15 to 40 kbps. Some additional H.323 approaches for modulating with CELP and Adaptive CELP are G.723.1 signaling at 5.3 to 6.3 kbps, G.728 signaling at 16 kbps, and G.729 signaling at 8 kbps. Regardless of the G.700 standard employed, the IP phone codifies the transmitted voice conversation and compresses it. Some devices also remove the silence portions of a conversation, resulting in a reduction of the transmitted information by as much as 50%. This makes the additional load that is involved with the addition of voice to data traffic a minimal amount. H.323 Call-Setup Signaling and Message Flow Since H.323 is an ITU specification, it is not surprising that it employs the standard Q.931 signaling protocol that is employed in telephone networks and in higher-speed transmission protocols such as in ISDN, Frame Relay, and ATM networks. The Q.931 specification is included within the general H. 225 recommendation from the ITU. The result is that the signaling for H.323 is a familiar process for most networking people who already are accustomed to using it for dynamic signaling with the popular Frame Relay and ATM networks, as well as for earlier ISDN signaling. All of these networks require an acknowledgement of successful call setup before actual transmission of the voice (or data) message and, similar to VoIP, they require no acknowledgement of the actual


56

data transmission. Figure 4.4 presents the complete set of signaling messages exchanged prior to the eventual streaming of the real-time voice message packets. This includes first sending a request for admission to the process of transmitting IP voice and receiving back a confirmation that such admission has been accepted. Then, once accepted, the signaling process is begun under H.225 with the submission of a setup request to the destination (analogous to dialing the user telephone number) and the receipt back of a connect signal (similar to the off-hook signal when the called party picks up the phone). Under H.245, additional messages are then exchanged concerning the establishment of an open logical connection and channel for communicating. If the gatekeeper is required for further authorization, for finding the appropriate area and IP number, and for setting up conditions for cross-charging or billing for the call, additional messages are exchanged with the gatekeeper server under the H.245 protocol. Finally, after all those preliminary messages are exchanged, and only after they have been confirmed, the real-time streaming packets can be transmitted.

Figure 4.4 The Complete H.323 Signaling Steps

for Admission and Call Setup

H.323 Call Setup Signaling

MediaRTP StreamRTP StreamRTCP StreamRTCP Stream

Admission Request

H.323Gateway

H.245Open Logical Channel

Gatekeeper

H.225(Q.931)

SetupConnect

Open Logical Channel Acknowledge

Capabilities Exchange

Admission Confirm RAS

RSVPPath

Resv

RTP StreamRTP Stream

H.323Gateway


57

Operation of Gateways and Gatekeepers in an H.323 Network The general architecture for H.323-based networks that operate between sites employs gateway routers at the edge of each site and one or more gatekeepers in the network itself. The calling IP phone must first issue a registration message to the network (an RRQ, or registration request) and receive back an RCF (registration confirmation). Then, the IP phone and gateway router send and receive a series of admission-to-the-network requests (ARQ) and an admission confirmation (ARC) or admission rejection (ARJ) message. Once the caller (and called party) are both admitted as known, registered users of the IP network, they can issue an H.225 specified call-setup message (a dual signal to the network and to the end phone). An H.225 response is then received back, and, while the two edge gateways control the flow, transfer of the call commences using real-time transfer with the best-effort UDP flow control. This sequence is portrayed in Figure 4.5.

Figure 4.5 H.323 Call Setup and Transfer Messages through

a Gateway and Gatekeeper

D u a M o d e M i o c

H.225Call Set up

H.245 Call Management

H.225Call Set up Response

Real Time Message Transfer Flow

ARQ RRQ, RCF

ACF

Gatekeeper

ACF

RRQ, RCF

ARQ

Gateway Gateway


58

H.323 allows networks to be compartmentalized into separate areas, or zones, similar to those in a standard OSPF IP network. Figure 4.6 portrays three separate zones communicating by means of a controlling area gatekeeper. A gateway router at each zone’s edge seeks admission, addressing, and routing information from the central gatekeeper and requests the gatekeeper to pass the call-setup signals to the destination site. Then, the subsequent conversation message packets can be passed directly from one area to another across the IP network.

Figure 4.6 Three Zones Communicating by Means of

Regional Area Gatekeepers Real-Time Transfer Protocol When transferring data over an IP network, delay usually is not an issue. Many employ TCP in addition to IP addressing to assist in guaranteeing delivery of the data packets. TCP provides for sequencing the packets and acknowledging that they have been received. However, this acknowledgement process delays the transmission. Voice is extremely delay-sensitive. When transmitting such delay-sensitive traffic over an IP network without using a




Zone 1Zone 2 Zone 3

Gatekeeper 1Gatekeeper 2 Gatekeeper 3

Gateway 1 Gateway 2 Gateway 3


59

means of acknowledging receipt, RTP is usually employed to supplement the “best-effort” UDP Layer-4 protocol. Thus, as a result of the delay issue, RTP plus UDP, operating in conjunction with IP, must be employed for transmission of the spoken voice, rather than TCP, since there can be no time allotted for waiting for the acknowledgement by the receiver of the components of the voice traffic as TCP implies. Furthermore, there is no time for the retransmission of the unacknowledged and presumably un-received voice portion that TCP would deliver. However, there is a partial solution to the reliability-of-delivery issue for voice, even though UDP is employed. RTP is added to assist with the difficulties that may be associated with IP transmission. Such problems may be that IP packets can arrive out of sequence and need to be re-sorted by the destination receiver. The packets may also arrive at irregular intervals. The packets may need to be buffered and then time-adjusted to stream in a natural fashion sounding like normally spoken conversation. To assist UDP for reliability enhancement purposes, RTP provides an additional 8-byte header to accompany the UDP 12-byte header that has already been added to the 20-byte IP header. These three headers and all their fields of information are presented in Figure 4.7.


60

Figure 4.7 Full Header with IP, UDP, and RTP Components RTP provides timing and sequencing benefits but at the cost of adding to the considerable UDP/IP header overhead that is attached to each portion of the voice transmission. The UDP header is 12 bytes, the IP header is 20 bytes, and to that the additional 8-byte RTP header is added, totaling a heavy load of 40 additional bytes to every packet that is transmitted. Because of this overhead on each transmitted voice component, a special compression algorithm for just the headers (RTP, UDP, and IP) may optionally be preformed before transmission. This algorithm, RTP compression (CRTP), may be employed, since using it reduces the total header to 2 bytes instead of 40 bytes. Figure 4.8 portrays this process of compressing the headers on each transmitted packet from 40 to 2 bytes.

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options Padding

Source Port Destination Port

Length Checksum

V2 P X CC M PT Sequence NumberTimestamp

Synchronization Source Identifier

RTP Header

UDP Header

IP Header


61

Figure 4.8 The Full Header Compressed to Two Bytes The cost of employing the additional 12 RTP bytes (or compressed 2 bytes) is the burden of the additional overhead that must be transmitted. The benefit of employing RTP is that it provides a time stamp for each voice segment to be used for adjusting the pacing of received voice packets for the human ear. RTP also provides a sequence number for reordering packets that might be delivered out of sequence. This approach is of particular benefit in an IP network, since IP does not guarantee the sequence in which it delivers packets. The listener would never tolerate portions of the voice communication being delivered out of sequence. This benefit is diminished if the IP packets are delivered over a Frame Relay or an ATM WAN service, since these WAN services do guarantee the deliver of their payload, as well as the sequence of this delivery. Moreover, the timing indicator is important to allow the receiving device to have information to assist it in the process of decompressing the received information and releasing it to the listener. The human ear is a sensitive instrument and RTP information helps the receiving device adjust the delivery by fine-tuning the timing of the delivery of the voice signal to make it appear normal to the receiver’s ear.

IP Header UDP Header RTP Header Voice or MediaPayload

Compressed Voice or MediaHeader Payload

20 bytes 8 bytes 12 bytes 20 to 160 bytes

2 to 4 bytes 20 to 160 bytes

40 byte Header Compressed to 2 Byte Header


62

Once a connection has been made from endpoint to endpoint using traditional Q.931 ISDN–like messages over a TCP connection, and once H.245 gatekeeper messages have been exchanged to create an open channel, RTP provides for the ability to stream voice carrying IP packets to a destination over UDP without acknowledgement or retransmission of lost packets. This combined process of Q.931 signaling, H.245 channel creation, and RTP process indicators for packet reordering and retiming at the destination receiver without involvement of the network or the packet originator, is portrayed in Figure 4.9.

Figure 4.9 RTP Added to H.323’s Q.931 Signaling Sequence

However, VoIP transmission does not occur in a vacuum. Business enterprises have already invested in LANs for their buildings and office. They have also interconnected their sites with not only leased lines, but with WAN services (such as Frame Relay and ATM), which they have leased from one or more of the national carriers. Having those connecting services in place and under contract, it makes sense that the VoIP service they implement must be able to inter-work with these existing services. Thus, the

RTP Timed Streaming Voice Media Transfer

over UDPRTP StreamRTP Stream

RTCP StreamRTCP Stream

TCP ConnectionH.323 Gateway Messages

H.245 Over TCP

Open Logical Channel

Q.931 SignalingOver TCP

Setup

Connect H.245 Address

Open Logical Channel Acknowledge

Alert

RTP StreamRTP Stream

Realtime Transfer Protocol Contribution to H.323 Q.931Signaling

H.245 Gatekeeper Messages

Realtime Transfer Protocol Contribution

H.323 GatewayMessages

Gatekeeper Messages


63

gateways at the edge of each site and the gatekeepers in the network must be able to communicate with the WAN services. Addresses and locations must be interchanged. Authorized user lists and allowed services must be maintained, and in some instances exchanged. Figure 4.10 portrays this communication flow.

Figure 4.10 VoIP Gateways and Gatekeepers Exchanging Information

with WAN So, we can envision the local enterprise network as a self-contained unit that can interconnect to other self-contained enterprise locations by means of a router with public, private, and telephone networks. This process is assisted by the address, authorization, and location information that gatekeepers maintain. Also, the gateway units can access the gatekeepers and make their information available to connecting users. This universal connecting scheme is portrayed in Figure 4.11.


Gatekeeper

GatewayGateway

WAN Network

Registration Request

Registration Confirm RRQ

RCF

Address Exchange

Voice Communication Packets

Voice Communication Packets


64

Figure 4.11 A Universal Scheme for Connecting VoIP Traffic

to Multiple Networks Conclusion The H.323 has been the principle VoIP protocol in the earlier implementations of VoIP service. This resulted from H.323’s emergence from the LAN environment and strong support from data network vendors such as Cisco Systems. The family of H.323 protocols addresses a wide range of media types—including audio, video, sound, and conferencing—and has strong backing from the telephone industry’s own standards body—the ITU. The largest supplies of IP phones use the H.323 protocol, and most hardware vendors support this protocol. Thus, H.323 will continue to be implemented in many VoIP situations and supported by many vendors during the next few years, although increasingly only in a dual support basis along with SIP.

H.323 Over Local IP and Ethernet

Network

Public and Private

Internets

Public Circuit Switched

Telephone NetworkGateway

Router

Standard Analog and

Digital Telephones

IP Phones

Gatekeeper

PBX

Gateway

Gatekeeper

Local VOIP Network

National VoIP

65

Chapter 5

SIP for VoIP Transmission The session initiation protocol (SIP) is based upon an IETF standard and is used to transfer the same set of multimedia content—voice, video, and data—that is transferred by the ITU–based H.323 protocol. SIP has the advantage of having quicker call-setup times than H.323 and is much simpler. SIP has a modular design and is structured expressly to allow extensions to be added when needed or when new approaches and technology are developed. SIP is another protocol for creating and subsequently maintaining and terminating a dial-like session from endpoint to endpoint. SIP operates with media-specific applications to initiate such sessions and to transmit the media once a session is established and acknowledged. SIP is an ASCII–based application-layer protocol. Much like the H.323 VoIP protocol, SIP requires an additional header component to the usual TCP/UDP and IP headers for each voice segment transmitted, as portrayed in Figure 5.1. This figure portrays the basic SIP client/server structure of client phones accessing a set of servers that are running selected applications and storing locations and addresses in order to make an IP connection and complete a call.


66

Application Services

SIP Servers SIP Servers

IP Device with SIP Agents

PBX

SIP

RTP/UDP

PSTN

SIP Proxy, Locate, Register, Redirect

Processes

SIP

SIPSIP

Figure 5.1 Basic SIP Overall Network and Services Architecture

SIP determines the location on the network of the destination phone. It then determines whether the destination device is available and the device’s media reception capabilities. Then SIP establishes an end-to-end session between the two endpoint devices and any additional devices. SIP handles all of the calling between the devices and the termination of the call at the end of the conversation. SIP follows a traditional client/server architecture. A client software module exists in all SIP terminals and specifically in SIP–enabled IP phones. In addition, specialized server software exists in a set of SIP servers. The architecture assumes that the client software works in partnership with the server software to perform any given function. Among these functions are identifying the client device to the local network, finding the desired destination device, matching the local source IP address of the client phone with a national IP address, and then sending a dial message to the destination device. After the connection to the destination phone is established, there is the process of managing the call while it is

Chapter 5: SIP for VoIP Transmission

67

under way and finally terminating the call and taking down the connection. SIP defines three servers (two specific to SIP itself). There is the registration and address maintenance server, which all systems must have. Then there is a relocation and redirection server (the SIP redirect server). There is also the optional SIP proxy server, which matches inside private and outside public IP addresses. Each device must first announce itself to the network and register itself. It is then given an IP address and a telephone number. When attempting to connect with another telephone, the dialing phone needs to find the IP address of the destination phone to which it is calling. Of course, the caller needs to at least know the telephone number of the called phone and go through the process of translating that telephone address to a called IP address. Furthermore, the caller must check with the redirector server to find out if and when the IP address that is being called may have changed. This changed destination IP address may occur merely as part of a reassignment by the destination domain name server (DNS). SIP Messages SIP defines the messages that must and can be exchanged by the client phones with the servers and with the destination phones.

1. Register – Each phone must register its existence, its parameters, and its MAC address (likely an Ethernet address). It is then assigned a telephone number and an IP address.

2. Invite – Each phone invites another phone to join a session and to exchange a conversation.

3. Acknowledge – Each phone receives in return an acknowledgement that a calling session has been established and that the destination device agrees to converse.

4. Bye – Each device issues a ‘Bye’ message to hang up and takes down the conversation session.

5. Cancel – Both servers and user devices can issue a cancellation message to stop a request in progress.


68

An example of the SIP exchange of messages from source to destination clients is shown in Figure 5.2.

InviteInvite

Code 100 TryCode 100 Try

Code 180 Ring Code 180 Ring

Code 200 OKCode 200 OKACK ACK

SIP Server

Calling IP Phone

Called IP Phone

SIP Signaling (TCP)

Media Transfer UDP and RTP

Media TransferRTP Stream

Figure 5.2 Sequence of Issuance of Messages between Source

and Destination Agents SIP Headers and the TCP/IP Packet SIP has four headers: one used for requests, one for responses, plus an entity header and a general header.

1. The request header field modifies the request command. 2. The response header field enables servers to send response

information back to the requester. 3. The entity header field indicates information about the

message in the body of the transmitted request/response message.

4. The general header field provides information about the request and response message in the body of the transmitted request/response message. This header format is portrayed in Figure 5.3.


69

Local Area or Wide Area Net Interface

IP

TCP UDP

Gopher Kerb SMTP Telnet FTP SIP SNMP RPC

Figure 5.3 Transmitted Frame with SIP, TCP, UDP, and IP Headers SIP works with a number of other IETF standards, including the same real-time transfer protocols (RTP and RTCP) as H.323, as well as a number of others. These include HTTP for transferring text messages over the Internet and DNS for locating and mapping IP addresses to domains (geographical endpoint clusters attached to the Internet), as well as SDP, SAP, and RSTP. SIP is a text-based protocol, so it is easy to implement and is well adjusted to the Internet. It is supported by the IETF’s RFC 2543 and RFC 3261. Similar to H.323, SIP uses TCP for call establishment and UDP for information (voice) transfer over the established channel. And SIP can operate over IP networks, as well as with IP over Frame Relay or ATM networks. The SIP specification covers three core components of a VoIP system.

1. SIP first covers the application-level user agent and a server agent that can act on behalf or the user agent and receive and respond to the user agent’s requests. These agents exist in IP phones, IP servers, and gateway devices.


70

2. SIP then specifies three types of network servers that act on behalf of clients to initiate, change, and terminate sessions. These are the proxy servers, redirecting servers, and location and registration servers, as shown in Figure 5.4.

User Agent Client

User Agent ServerSIP Servers

ProxyRedirectLocation Register

D

M A G E L A N

User Agent Client

User Agent Server

D

MA G E L A N

Figure 5.4 SIP User Agents Connecting to SIP Proxy, Locate, and Redirection Servers

3. SIP also provides for addressing in the traditional Internet

URL (universal resource locator) fashion, such as with the following aliases:

• [email protected] • Physical addresses such as

[email protected] Proxy servers are devices that act for agents and server agents. Proxy servers maintain a set of addresses. They receive request messages through their address headers from agents’ IP phones or IP servers and rewrite the header with a temporary address from the proxy’s store of addresses. To the outside network, the source


71

appears to be the proxy server, rather than the true device which hides behind the proxy. Proxy servers also are responsible for connecting the user’s call once the appropriate address is provided. Redirecting servers maintain a base of server addresses. They send the appropriate server address and other necessary information back to the originating client suggesting that SIP VoIP requests be sent to that designated server. Location and registration servers maintain a set of user locations. Users must first register with this server before they are authorized to seek and receive the addresses of endpoint terminals with which they intend to communicate and set up a voice session. SIP employs five elements in initiating a call. The user agent in the source IP telephone or PC must know the destination user location, the user’s capabilities, the user address, and whether the user is currently available. Beyond that, the source agent must know how to set up a call in the SIP way, how to maintain the call connection, how to transmit the call content, and the how to terminate the call session. SIP Addressing and Operation A SIP address looks very much like a standard e-mail address ([email protected]) with a personal name (myname) and a domain where the user resides (@earthlink.net). Such addresses can be treated like the standard Internet addresses with which we are all familiar. They can be embedded within documents and Web pages, and one can trigger a connection by merely clicking on them. However, before using these addresses to transfer calls and messages, one must first establish a connection with an initiate request message and one must terminate the connection at the end of communication.


72

The Specifics of User Agents Using SIP Proxy Servers The operation of a SIP client phone as it sets up a connection with the destination phone requires the usage of the SIP servers. Following the flow of the issuance of an Invite command to request a destination phone user to join a connection and establish an ongoing session, the originating SIP client first sends the Invite command to ask a specified destination endpoint telephone to join the session and receive calls. Since many business establishments use a private IP addressing scheme within their local network, a proxy server is employed to convert local IP addresses to public IP addresses. This is done by maintaining a set of public addresses that can be “loaned” to a user while a call is under way and reused with another caller when another session is requested and this one is terminated. Figure 5.5 shows an Invite message sent by means of a proxy server through to the destination IP phone.

Client

Client

User AgentUser Agent

Redirect ServerProxy Server

Invite

IP-Based Network

Invite

Figure 5.5 Initiating a SIP Connection over an IP Network

Upon receiving the Invite message, the destination endpoint replies with a coded Response message, here indicated as Code 200, which


73

indicates that destination user and phone is ready to listen and to talk (or to receive messages), and a session between them is now established. The corresponding response methods are used to send a reply once the destination has received the call Invite request. These standard responses contain a three-digit code ranging from 1XX to 6XX. For example, the response code 180 implies that the destination phone is ringing. The response code 200 indicates that the phone is off hook and the user has answered the call. There are a number of other call response codes using the codes up to 6XX. This process is portrayed in Figure 5.6.

Client

Client

User AgentUser Agent


IP-Based Network

Response Code 200indicating SuccessResponse Code 200

Figure 5.6 Destination Agent Acknowledging a SIP Connection

over the IP Network Once a session has been successfully established, communication and message transfer occurs. This transfer is normally made without acknowledgement (which was employed during the call-setup Invite to ensure the connection establishment), as the calling parties can not tolerate the delay associated with acknowledgement


74

exchanges during a call. Thus, as usual, callers send best-effort UDP–based messages. This best-effort process is assisted, as was already discussed, by the add-on of the RTP, which helps the destination receiver order and time the delivered packets containing the conversation. The RTP’s timestamp and sequence numbering of each sent packet are thus included in the packet header of each packet that makes up the conversation to assist the UDP process. Figure 5.7 shows the acknowledgement that is sent back to the proxy server on session establishment, followed by the two-way conversation between the end parties using the RTP–enhanced UDP over IP protocols.

Client Client

User Agent User Agent


ACK

IP-based Network

ACK Acknowledgement

RTP Voice Transfer

Figure 5.7 Two-Way Communication with a SIP Connection

over an IP Network The More Detailed Flow Using Proxy and Redirect Servers Of course, the process of finding a destination IP address in order to Invite a connection is more complicated than that which was just discussed. The more detailed Invite flow requires not only using a proxy server to translate local IP addresses to public IP


75

addresses, but also finding the appropriate destination IP address when one only knows the destination telephone number. Since the VoIP transmission flows over an IP network, IP addressing is fundamental to establishing a connection. Following SIP, a VoIP conversation begins with an IP phone (the client) sending a request signal to the closest Internet telephone server (IP PBX) or to the closest gateway device. The request is then passed to a gateway at the enterprise edge for a private connection or to a SIP proxy server. A SIP VoIP conversation starts with the user’s IP telephone and its software agent sending a signal through its local gateway device to the closest SIP proxy server. The proxy then sends request messages to the other SIP servers on behalf of each user agent (IP phone). After the IP telephone is registered in the registration database, the proxy sends a request to the location server to find the IP address and other details about the destination IP phone. The location server then sends a response to the proxy server. Finally, the proxy server can send the call-setup signal to the destination phone through the local gateway device connecting to the Internet or to a redirection server to act for it. Subsequently, the IP voice content is transmitted, once an “off-hook” response has been received indicating that the destination end phone is available and the end user wishes to converse. Determining the location and IP address of another user under SIP involves employing SIP location servers in the network that maintain databases of user profiles, user telephone numbers, and current user IP addresses. Traditional Internet protocols for finding another user over an IP network are frequently employed, such as Finger, Rwhois, and multicast broadcasting of finder messages such as the ARP process. The location databases are frequently supported by the LDAP (lightweight directory access protocol), which is a protocol for specifying the structure and operation of an on-line directory service operating over a TCP/IP network. LDAP is structured as a tree-and-branch architecture for quick response in a network’s high-speed operation. One of the advantages of employing a SIP–based VoIP network service is that SIP makes enterprise user and station adds, moves,


76

changes, and relocation a relatively easy process. SIP supports this by providing a both a location server to keep track of user addresses and locations and a redirection server to assist a proxy server in routing traffic to a new location. A user client that seeks to determine the current location of any other user merely uses one of the standard Internet protocols, such as the Whois or referral Whosis (RWhois) software procedure and set of commands, and a formal query process. The complete process of SIP signaling is portrayed in Figure 5.8.

RTP Stream

InviteInvite

Code 100 TryCode 100 Try

Code 180 Ring Code 180 Ring

Code 200 OKCode 200 OK

ACK ACK

SIP Server

Calling IP Phone

Called IP Phone

SIP Signaling (TCP)

Media Transfer UDP and RTP

Figure 5.8 SIP Signaling Sequence and Operation The following the sequence of steps is performed:

1. Register with the registration server. 2. Request with an “Invite” from the proxy server. 3. The proxy server then asks the location server where the

desired individual is located. 4. The redirect server then informs the sending requester of

the URL address where the desired individual is now located.


77

5. The proxy server can then make a connection to the destination user for the caller, substituting a national public IP address for the private local IP address used by many businesses.

This complete set of steps (1 to 5) is presented in Figure 5.9.

IP Devices with SIP Agents

PBX

SIP

RTP/UDP

SIP Servers and Offered Services

RegisterRedirectUser Locations

1. Register“I am Frank Groom”

3. Locate“Where is Kevin Groom at 555-9999?”

4. Relocate“Kevin is now at [email protected]”

2. Invite“I want to talk to another User Agent”

Frank’s IP Phone Kevin’s IP Phone

5. Proxy“I’ll establish the connection for you”

SIP Proxy Server

Figure 5.9 The Process of Locating and Communicating

with Other SIP Users However, the national interexchange carriers (IXCs), such as AT&T, MCI, and Sprint, are interested in migrating much of their national core backbone networks to IP. The RBOCs, such as SBC and Verizon, clearly intend to do the same for their emerging national networks. To operate these national IP backbone networks, these carriers need to be able to transport traffic originating in the local and regional PSTNs as well as local IP networks. They also need to be able to interface with the signaling networks (SS7). Furthermore, they need to be able to connect a call that originates in one type of network, such as the PSTN, to a user who is served by a destination IP network. This array of local


78

networks interconnected by the national carrier or RBOC IP backbone network is portrayed in Figure 5.10.

Carrier SIP Service

Local PSTN

Local PSTNLocal

PSTN

Enterprise IP NetworkIP Telephone

Standard Telephone

Enterprise IP Network

Standard Telephone

IP Telephone

National IP Network

Enterprise IP Network

Standard Telephone

IP Telephone

Figure 5.10 The Architecture of a National IP–Based

SIP–VoIP Service Network So, it should be clear that SIP offers a means to signal and connect such national networks. It should be of no surprise that the carriers and RBOCs are intending to employ SIP as their core network protocol, although they must continue to interface their core network to H.323 due to its prevalence, MGCP, and MEGACO access protocols, as well as traditional PSTN and SS7 networks. Conclusion SIP appears to be taking over as the preferred VoIP protocol, although there are more H.323 IP phones and equipment currently available on the market due to their early implementations. Yet the trend is obviously toward SIP, which benefits from its use of HTML (hypertext markup language) and the fact that it comes from the IETF, the Internet’s own standards organization. With


79

strong support from the telephone industry for SIP and the rapid move by all segments of the telephone industry into the business of offering VoIP services, SIP clearly is rapidly moving to a prominent role as the preferred protocol for distance communication over public network facilities.

81

Chapter 6

Gateways and Gatekeeper Protocols For simple VoIP connections, the H.323 or SIP protocols are satisfactory. However, for more complicated situations, a specialized gateway component with its own gateway protocol is desirable. There are some situations where a special gateway may not be needed. For example, if an enterprise removes its legacy PBX and employs new IP phones and a set of associated IP servers, a specialized gateway may not be necessary. However, if the legacy PBX still remains on site handling a portion of the traffic, and if both analog originated phone calls and IP phone calls must sometimes pass over the PSTN and at other times over an IP network, a gateway node with a specialized gateway signaling protocol is beneficial. Calls transmitted through a standard PBX to an IP network must be converted to IP packets, and the call-setup signal must be transmitted first in its own IP packet. The gateway can perform this function for the PBX, either as a plug-in blade or a module in the edge gateway router, in a separate interworking box, or by software in the PBX itself. In similar fashion, an IP phone may need to place a call over the standard public telephone network (PSTN). The gateway device can assist in converting IP call setup packets to analog signaling information for the PSTN and can convert subsequent IP packets to a stream of analog conversation signals. A separate gateway node can augment either H.323 or SIP protocols in handling a more complicated set of network interconnections. As a result, gateways can be thought of as either an alternative to or extension to the H.323 or SIP protocols. Gateways can help with other issues as well. They can adjust the voice frame sizes to improve the flow through the network. Usually, a small 82-bytes frame goes through the network with


82

minimal delay and can be prioritized with minimal effect on other data packets. Gateways can also provide buffering at both the source and destination sites to adjust the flow and delivery of voice packets with a modest reduction of jitter variability Gateways placed at the edge of an enterprise provide a convenient place to physically terminate telephone lines and trunks as well as perform their function of translating voice signaling to IP signal packets and translating voice content to a series of IP addressed packets. Gatekeepers, on the other hand, provide a place where the enterprise can interconnect sites or areas employing the H.323 signaling protocol with sites or areas employing the SIP signaling protocol if in their implementation plan they should happen to begin with one protocol and decide to change to the other protocol for later implementations. The combination of a set of gateway edge devices at each enterprise site and a gatekeeper in the network allows for the distribution of functionality among a set of gateway devices and a central gatekeeper controller. This allows for the concentration of centralized intelligence in the central gatekeeper— functions such as call-connection control, finder services between areas, appropriate PSTN signaling information for calls when necessary, the equivalent to directory assistance service for each call, the appropriate collection of billing information, and the submission of such information to billing processing site. Furthermore, the gatekeeper provides a repository of appropriate signal information required for signaling to all networks, whether they are PSTN, H.323, or SIP VoIP networks, and the appropriate translations for each. These centralized gatekeepers act as central call agents to provide centralized intelligence and information, control the various enterprise media gateways, and assist in call admission allowance, determining which calling parties are call-restricted and which called parties or locations are call-restricted. Gatekeepers also deal with performance issues. However, the more boxes, components, and protocols employed in a network, the more reliability can be degraded and the more points and processes can contribute to a slow down in transmission—and thus performance issues.

Chapter 6: Gateways and Gatekeeper Protocols

83

Enterprises need to determine the number of gatekeepers required to support all of their network connections. The question of how many calls per minute their gatekeepers can handle also needs to be answered. A further issue is how many call setups the gateway can handle in a unit of time. Furthermore, how many enterprises sites can be supported by a gatekeeper when these sites employ a gateway device? The answer to these questions determines how many such gatekeepers are desirable for a satisfactorily performing network in a combined voice/data situation. There are two principle gateway protocols that will be discussed: MGCP and MEGACO. We will examine each, as well as look briefly at the Skinny protocol, a cut down version of a gateway protocol. Media Gateway Control Protocol – MGCP Certainly the competing VoIP protocols—H.323 and SIP—can operate independently as vehicles to transmit voice and other media without the assistance of additional protocols and devices. However, the principle gateway protocol, MGCP, provides external call control elements that augment the H.323 and SIP protocols. Media gateways using MGCP provide an external control using MGCP’s specialized gateway protocol, whereas, under H.323 and SIP, the call control is provided unassisted by units operating with those protocols themselves. MGCP provides gateway control mechanisms and the interplay between such media gateways and external centralized controllers in the network. Media gateways exist at the edge of enterprise networks and operate as interface devices between enterprise networks and public networks, particularly between IP networks and the PSTN. Furthermore, MGCP supports gateways between a variety of networks. Among these connections are the following:

• Gateways for trunk connections between telephone networks and IP networks

• Gateways interconnecting telephone networks and ATM networks

• Gateways from a standard PBX to a switch interface and further to a voice-carrying IP network


84

• Gateways from a home device or home network to a connection to the Internet primarily through an ISP

• Gateway from a business or residence to the public Internet by means of an analog modem and a dial-up connection through the PSTN.

• Connection, signaling, and call control over the PSTN • A division of the functionality, with part to be provided by

the media gateway and other parts to be provided by a central media controller placed out in the network

• A means of handling signaling and session management for multimedia (voice, video, and data) conferencing

MGCP uses the IETF’s RFC 2705 for its architecture and specification details and the IETF’s session description protocol (SDP) for defining the audio and data access circuits that are supported. Further, it uses SDP for providing standard IP addresses to find and connect to the gateways, as well as TCP and UDP profiles for session establishment. Moreover, MGCP uses the ITU’s E.164 for the phone numbers associated with IP phones, which is similar to the approach employed for address numbering for ISDN and ATM networks. The principle components of a MGCP process include the originating IP phones, the media gateway itself, and the call agent as a centralized assistant placed out in the IP network. These components are portrayed in Figure 6.1.


85

Figure 6.1 MGCP Use of Gateways and Call Agents

MGCP call agents provide a centralized, intelligent control point for managing media (particularly voice) gateways, controlling call admission to the IP network for voice transmission, providing a place for transmitting packets containing call-setup signaling messages over the IP network, providing for signaling to the PSTN where required, and translating protocols such as H.323 and SIP. The call agent IP call-setup function as well as the PSTN SS7 signaling function are portrayed in Figure 6.2.

IP NETWORK

MGCP Call Agent

Media Gatway

Media Gatway

MGCP Messages

MGCP Messages


86

Figure 6.2 Call Agent Signaling to IP or PSTN Networks

Figure 6.3 expands on the PSTN’s signaling system (SS7). The figure shows the extended signaling possibilities that can result from employing and IP network augmented by a call agent to bridge public telephone networks. Figure 6.3 also shows how a call agent can be placed between sites employing traditional telephone signaling to perform the function of converting these signals and voice conversations to IP signals. It also can address the IP packets containing the user conversation.

PSTN

IPNetwork

MGCPCall Setup Signaling

MGCP

Call Agent

Media Gateway

Media Gateway

SS7 Signal

Media Gateway

Voice Messages


87

Figure 6.3 Call Agent Signaling for Traditional Telephone

Transmission through IP The MGCP Commands MGCP implements a set of commands that control the interfaces for the media gateway. These commands are structured as a set, including an origination command and a required response to each command. These commands include the following:

• A Notification Request asks the media gateway to look for activity arriving on a specific port from a specific end-user terminal (IP phone).

• The media gateway sends a Notify response to the call agent that originally made the request to inform when one of those events occurs.

• The terminal’s call agent sends a CreateConnection command to connect to a specific port on the media gateway.

• The terminal can subsequently change any of the parameters of that connection with the issuance of a ModifyConnection command.

IPNetwork

MGCPCall Setup Signaling

Call Agent

Media Gateway

Media Gateway

SS7 Signal

Voice Messages

SS7 Signaling Network

SS7 Signaling Network

Traditional Telephone Dial Link

Traditional Telephone Dial Link

TrunkTrunk


88

• The DelectConnect can be issued either by the terminal or the media gateway when a connection is no longer necessary or can’t be maintained.

• The status of endpoints, connections, and existing calls can be monitored by the call agent by issuing AuditEndpoint or AuditConnect commands.

• The RestartinProgress is a notification message sent to the terminal’s call agent indicating that the media gateway or a set of connected endpoints are being restarted or reconnected.

Media Gateway Control Protocol – MEGACO MEGACO is a standard protocol for allowing sites to interconnect between IP networks and the PSTN. MEGACO utilizes the H.248 protocol and provides a set of rules for the media gateway device and a media gateway controller enabling them to connect and operate as a unit. MEGACO performs the same basic functions as MGCP but allows for a much wider set of network types to be interconnected, including the WAN services of ATM and Frame Relay. The media gateway is a translating device. It takes a stream of information from one network and translates it into a format which is utilized by a different type of network and a format which devices attached to that network use and understand. The media gateway controller is a module that controls the logic used by a media gateway device. For VoIP networks, the voice telephone conversation needs to be translated into a stream of packets. The H.248 protocol describes the process by which the IP–formatted voice conversation is translated into a steam of packets that can be effectively transmitted in a streaming fashion over an IP network. MEGACO is built upon two basic entities: terminations and contexts. A stream that enters or leaves a media gateway is considered a termination. These terminations can cover a number of types, including the following: IP over private-line circuit terminations, analog or digital PSTN terminations, IP over ATM or


89

Frame Relay terminations, and IP over local Ethernet terminations. These are the principle set of terminations, but others are available as well. Each network termination is named and has a set of properties, including port speed, port number, port supported protocol, and port buffer size. A context is a group of these terminations at a media gateway. Terminations and their connections must be managed as a unit by applications such a video or audio conferencing. When a set of users are connected individually to a media gateway, all participate in the same conference. New users can be dynamically added to the conference as required with the appropriate port, speed, buffer, and protocols updated as the connection occurs. Thus MEGACO is broader in its scope than MGCP. It supports a broader set of networks that interwork with a local IP network, and it provides support for a broad range of media types being transported over these connections. Simple Gateway Control Protocol Simple gateway control protocol is a generic name that applies to Cisco Systems’ proprietary skinny gateway control protocol using limited function (skinny) clients and limited function (skinny) gateways. The endpoints of a conversation are considered the clients of the network, and the gateways assist the endpoint clients in setting up calls and the subsequent network connection. The individual links between nodes in the network are considered connections. The gateway device determines a path over which the call proceeds, and the call is the collection of all link connections in that established path across which the conversation proceeds. Skinny Protocol – An Alternative to MGCP and MEGACO With skinny protocol, a call control module (CCM) is placed out in the network in a fashion similar to a reduced function gatekeeper but also performing gateway functions. The CCM performs call-setup functions for the caller and call maintenance functions for the network. Caller IP phones send a special skinny signaling packet to the CCM requesting that it find the proper destination


90

site and phone and that the CCM set up a session with that phone. Upon receipt of a session-establishment acknowledgement from the destination phone, the two phones transmit IP packets containing the voice conversation in best-effort mode (UDP) augmented by RTP’s sequencing, timing, and synchronization information. This results in a real-time stream of the voice-containing IP packets (termed RTP streams) from the source IP phone to the destination IP phone by means of edge routers at each site.

Figure 6.4 Skinny Protocol Employing a Call Control Module

for Signaling Assistance Summary Comparison of the Protocols These VoIP protocols for gateway and gatekeeper devices provide a mixed set of performance, scalability, extensibility, and architectural features. When settling on any one or a combination of such protocols, the designer should be aware not only of the basic purpose and functionality of these protocols, but also the general nature of each protocol. Table 6.1 summarizes the more general nature of each of these gateway protocols and the more


Real Time Protocol Signaling

Skinny Protocol Signaling Skinny Protocol Signaling

C is c o 7 0 0 0E R IE S

OWR WC IS CO Y S TE MSS

Call Control ModuleCall Setup

Call Management


91

basic H.323 and SIP protocols, dealing with such issues as performance, scalability, extensibility, and architectural features.

Table 6.1 Comparison Chart of Signaling Protocols

These protocols vary between peer-to-peer architectures and master/slave architectures. Some are easy to extend and scale, while other have limited capability for additions. However, each is standardized by a national body, whether it is the ITU or the IETF. Also, all such protocols carry voice traffic, while some protocols such as MEGACO are customized to carrying an array of media types.

H.323 SIP MGCP MEGACO

Architecture Peer to Peer Peer to Peer Master/ Master/Slave Slave

Scope of Intranet and Intranet and Intranet IntranetNetwork Internet Internet Only Only

Media Types Voice, data, Voice, Video Voice Voice, Limited Data Data Video

Extensibility Low High Medium Medium

Scalability Medium High Low Low

Deploy Ease Low High Medium Medium

Standardization ITU IETF IETF IETF/ITU

93

Chapter 7

Transmitting Voice over a Public WAN and IP Network

In addition to delivering some of their voice traffic over the public Internet, many companies are also seeking to take advantage of the investment they have made in their metropolitan, regional, national, and international private data networks. They frequently lease private lines such a T1 or DS–3 trunks between their sites, but when they need to communicate between more than three sites, many companies chose to contract for Frame Relay or ATM WAN service from national carriers, such as AT&T, Sprint, and MCI. Where a limited number of sites need to be interconnected, edge routers can be employed at each site to create a private IP–based intranet rather than subscribing to a full Frame Relay or ATM service. However, the process of transmitting voice over these WAN services employs even more switches and nodes than a mere point-to-point private-line connection. Each switch along the path has both input and output buffers with associated queuing delays. Because of the possibility that data packets and voice packets may both arrive at each switch along the path and hold up the voice, with WAN services, voice packets are marked as highest priority and released from queues before the contending data packets. And to further adjust for delays and variation through the switches of a WAN and LAN networks, de-jitter buffers are employed at the destination device (IP phone or IP PBX) to hold and release the message stream in a regular time-synchronized fashion to the human ear. IP Voice over Frame Relay – IP VoFR WAN services allow many connections (and thus many voice conversations) to be established in a parallel multiplexed fashion over a single access line. At the first Frame-Relay switch at the edge of the WAN, the traffic to different destinations is split off and connected to appropriate paths to the desired destinations. While passing through the WAN, the individual data or voice streams are


94

split and multiplexed again with other traffic. At the edges closest to the destinations, the traffic for each specific destination is collected from the entering stream of frames, multiplexed together, and transmitted in a stream to each establishment’s edge router. At that edge router, the traffic is then split up and transmitted to the local office PC, IP PBX, or IP phone. When connecting the traditional local voice network to Frame-Relay service provided by a carrier, the edge router converts the telephone dial signal and voice message (as well as local data traffic) to Frame-Relay frames. This process, portrayed in Figure 7.1, is performed either by an edge router or by a PBX with a Frame-Relay output port module and Frame-Relay addressing and packet creation software. However, companies are increasingly changing out their complete phone systems and replacing them with IP phones, servers, and switches. IP phones are employed that convert the signal and subsequent message directly into packets, which are delivered by means of an IP server to the enterprise’s edge router. It is the function of the edge router to convert the local traffic, whether in the form of IP data packets or IP voice packets, into addressed Frame-Relay frames that carry the packetized content. At that edge router, the voice frames are integrated with the transmitting site’s data frames for transmission to other sites. The FRF.12 standard is followed for the process of integrating the voice frames with data frames and for submission of the frames to the Frame-Relay network. The companion standard, FRF.11, is used for framing and handling of the dialing digits for the call-setup signal, which are used in a voice network. After the frame containing the dial digits has been forwarded to the Frame-Relay network, subsequent frames containing portions of the voice call follow using the FRF.12 standard for carrying the voice packets in Frame-Relay frames. Voice packets encapsulated in Frame-Relay frames following these two standards are transmitted in basically the same fashion as those frames containing data packets. The primary difference is that the voice-carrying frames are likely to have a priority bit set to give them preferential treatment in passing through the network switches. The voice-carrying frames are also likely to be smaller than the data frames (usually about 82 bytes in length) to also allow for fast passage through the switches of the network. Figure 7.1 portrays an edge router offering two priorities,

Chapter 7: Transmitting Voice over a Public WAN and IP Network

95

high and low, for the voice and data streams. The two streams, once assigned a priority, are merged together and sent as a combined stream to the Frame-Relay service.

Figure 7.1 Enterprise Edge Router Integrating Prioritized

Voice and Data Traffic The process performed by this edge router on the enterprise’s site is more complex, though, than merely framing, prioritizing, and merging the voice and data traffic together into a common stream. The edge device selects from a set of pre-established circuits (permanent virtual circuits, or PVCs) and their associated Frame-Relay addresses (termed DLCI, or data link control indicators). Over these PVC circuits using the Frame-Relay DLCI address, the edge router sends the call-setup IP packet in a Frame-Relay frame. Then, once a two-way circuit is established to the destination edge switch, a series of similarly addressed Frame-Relay frames containing the voice message are transmitted to the destination edge device. This destination edge device then forwards the individual voice (or data) to the designated telephone (or PC). Figure 7.2 portrays the edge routers following the FRF.11 standard for setting up and transporting voice call-setup signals over a Frame-Relay network.

Analog Voice Traffic Stream

Frame Relay Frames toFrame Relay Edge S witch

Bursty Data Traffic

Priority 1

Priority 2

Enterprise Edge

Access Router

FREdgeSwitch

Digital Voice Packets


96

Figure 7.2 Setting Up a Voice Traffic Connection over

Frame-Relay WAN Service A more complete multi-site version of the Frame-Relay network interconnecting three sites with Frame-Relay PVCs set up between them is presented in Figure 7.3. Each site contains both PC–based LAN data traffic and PBX–based voice traffic, all carried over a common PVC Frame-Relay circuit.

Call Setup and ControlAlong PVC

Frame RelayCall

Accepted

Dial Mapped to PVC

and DLCI

Frame Relay Call Setup

Frame Sent Over PVC

Telephone Rings

Voice over Frame Relay Signaling

Cisco 7000E RIE S

OWR WCIS C O Y ST EM SS Cisco7000ER IES

OWR WC IS CO YS TE M SS

TelephoneDials

Convert FR Setup Signalto Dial Signal

FRF.11

Frame Relay Network

D ua M o de M i oc

D ua M o de M i oc

IP Phone

Analog Phone


97

Figure 7.3 Frame-Relay Connecting Sites for

a Combination of Data and Voice A more simplified, but little used, approach for linking multiple sites with Frame-Relay WAN service and carrying voice traffic over the WAN is to implement a single router at a site somewhere in the center of the connecting sites and attached to the edge of the Frame-Relay network. Then, all sites send their voice traffic over pre-established PVCs to that central-site router. The central router then picks the appropriate destination PVC to deliver the voice frames to the destination Frame-Relay switch and on to the enterprise site network. The central router acts like a CO switch or PBX for the network. In this approach, each source edge router needs to send all of its traffic only to the middle edge router over single PVC. That router then converts the local telephone E. 164 dial address to one of the set of pre-established PVCs. The central site contains a table used to associate E.164 dialed addresses to Frame-Relay DLCI addresses for retransmission to the destination edge device. The destination device must then convert the Frame-Relay DCLI to the appropriate E.1634 voice dial address. It then first sends the dial-

Cisco7000E RI ESOWR W

C ISC O YS TE MSS

Cisco7000ERI ESOWR WCIS CO YS TE MSS

Cisco7000E RI ESOWR W

C ISC O YS TE MSS

PBX

PBX

PBX

FrameRelay

Network

Router

Router

Router

LAN

LAN

LAN


98

up signal. Once call acceptance occurs (an off-hook signal), the subsequent voice content is transmitted to the destination telephone for human hearing. This central site routing is portrayed in Figure 7.4.

Figure 7.4 Central Routing of Frame-Relay–Carried Voice Traffic

Frame Relay is, by its very nature, a network for transmitting bursty data over a wide area. Frame Relay as a switched network service incurs a number of delays that might affect voice traffic. Buffers are employed at either end of the Frame-Relay network to hold the information while it is being segmented and placed into frames and while addresses are added. This segmentation and addressing process incurs about 15 ms delay at each end of the Frame-Relay network. Additional compression, decompression, and jitter adjustment in buffers that are employed also add to the delay in reception. The Frame-Relay switched network alone adds up to 100 ms in order to transport each frame. The sum of these delays can add up to 180 ms total delay when considering all of the possible delay components. These delays have an effect on the quality of the voice signal being transmitted as perceived by the

Frame RelayService

Site BSite D

Site C

Site A

Addressing and Routing All PVCs are connected to One Central Site

with Static mapping of E.164 addresses to PVCs

Cisco7000E RI ES

OWR W

CIS C O Y ST EM SS

Cisco7000ER IES

O WR WCI SC OY ST EM SS

Ci sco7000ER IES

OWR WC ISC O Y ST E MSS

Cisco7000E R IES


Cisco7000ER IES


Source PVC Destination

PVC

PVCPVC

E.164

E.164 E.164

E.164

Central Frame RelayVoice Routing Site


99

user. The components of Frame-Relay delay are summarized in Table 7.1.

Table 7.1 Delay Components in a Frame-Relay Network

The most prevalent arrangement for Frame-Relay service is the employment of a fully meshed Frame-Relay network connecting a number of sites across a region or across the country. In the mesh example, each edge router at the enterprise site performs the conversion to Frame-Relay frames for all the local users intending to transmit. The edge router also performs the additional task of the addressing each frame containing the voice or data material with Frame-Relay DLCI addresses and submits the frames to the access link to the Frame-Relay service. This submission to a meshed Frame-Relay network is portrayed in Figure 7.5. A static PVC link is created from each site to each of the other sites, with one PVC associated with each connection. The enterprise edge router analyzes the dialed E.164 voice setup, picks the appropriate pre-established PVC to connect to the chosen destination site from a table, converts the dial signal to the appropriate packet and adds the associated DLCI address, and forwards the newly addressed Frame-Relay frames. The destination edge router must then convert the DLCI address in the received frame to a dial E.164

INHERENT FRAME RELAY NETWORK DELAYS

Input Buffer 15 msec

Compression 15 msec

Edge Router Queue 15 msec

Network Transport Delay 100 msec

Jitter Buffer at Destination Router 30 msec

Decompression 5 msec

Total Transport Delay 180 msec


100

signal and all subsequently received frames to analog voice signals for the human ear. This fully meshed multi-site Frame Relay connection approach is portrayed in Figure 7. 5.

Figure 7.5 Voice Traffic over a Fully Meshed Frame-Relay Network

Frame Relay is considered the “fast” version of a packet network, with fast switching and very little error detection and correction. Frame-Relay service takes advantage of the fact that most of the carrier national networks are conducted over fiber links that are much less error prone than electronic circuits, allowing the reduction of error control required due to the quality of the optical facility. The assumption is that the edge devices at the enterprise sites perform any error detection that is required. Between the edge routers at each end, Frame Relay only supplies virtual circuits that can be chosen to deliver the messages based upon the supplied dial signal and the associated DLCI Frame-Relay address. In transmitting frames over the virtual circuits of a Frame-Relay network, special measures are employed to minimize the inevitable delay resulting from the segmentation and addressing process, the transmission through a switched and routed network, and the

Frame Relay Service

Site A

Site C

Site D

Site B

FULLY MESHED FR SWITCHED NETWORKCarrying Site-to-Site Voice Traffic

Cisco7000ER IE S

OWR WCIS C O YS T EM SS

Cisco 7000E RI ES

OWR WC ISC O Y ST EMSS

Ci sco7000ER IE S

OWR WCIS CO YS TE M SS

Cisco7000ER IE S

OWR W

CIS C O Y STE M SS

Cisco7000ER IES

OWR W

C IS CO YS TE MSS

SW SWSW

SW SW

SW

Site E

Static mapping of E.164 address to PVC

Frame RelayNetwork


101

processing at the destination. Furthermore, compensation must be made for any variation in delivery, both from arriving early and from arriving after a delay that a Frame-Relay network might incur. Among these measures are the following:

• Reduce the Frame Size – Places the voice segments into very small frames, usually in the range of 82 bytes in length, which, due to their small size, can flow through the switches at maximum speed with minimum delay for each frame.

• Prioritize the Voice Frames – Implements a prioritization

scheme where voice frames have a higher priority than other data frames. The voice frames will then be released from the ports of each Frame-Relay switch before any other frames that are in the port buffers.

• Provide for Jitter Buffering – Provides buffers at each end of

the Frame-Relay network to adjust the timing of frame delivery and the release of the synchronized voice signal.

• Implement Silence Detection and Suppression – Provides

intelligence to detect silence in the voice signal, to remove it and replace it with a code, and to place only the actual voice conversation itself into the frames being transmitted. The silence indicator is used to recreate pauses for the listener at the other end.

• Implement a Compression Scheme – To minimize the amount

of bandwidth used, the frame information can be compressed at the edge router, PBX, or IP phone and uncompressed at one of the destination devices. A specific standard exists for this purpose in Frame Relay—G.729, also known as CS–ACELP. This compression can be implemented in the edge Frame-Relay devices with decompression occurring at the receiving end of the network.


102

• Implement Echo Cancellation – Echoes can occur when telephone signals are transmitted over trunks. Furthermore, PC–based speakers and microphones can also introduce echoes. Thus, echo suppression technology should be deployed at each source edge router to cancel any echo that might arrive at the router or be involved in the transmission, so that it is not transmitted over the network or received by the destination devices.

• Take Advantage of Small Voice Bandwidth Needs – Voice

traffic requires only 8 kbps of a network. Thus, voice traffic can be transmitted over a slow-speed Frame-Relay connection. Furthermore, the committed information rate (CIR) of only a slow 32 kbps of average connection can be subscribed to and billed. Only 32 kbps is subsequently allocated over the Frame-Relay network, although the transmitted traffic can burst up to a full 64 kbps when required if that is the speed of the access line.

IP Voice over ATM – IP VoATM ATM networks can be thought of as high-speed Frame-Relay networks, although there are many differences in the circuit-establishment process and in the addressing schemes. Frame Relay, however, was intended to carry only bursty data traffic, while ATM was intended from its inception to carry both voice and data traffic. ATM has specific options for mimicking a voice circuit as well as carrying voice traffic along with data traffic. ATM has special “adaptation layer” arrangements that allow it to specialize in carrying specific types of voice traffic, such as for telephone companies. ATM has four basic approaches for carrying traffic. The most common approach is the “best-effort” and simplest ATM adaptation layer–5 (AAL–5) approach. AAL–5 supports the transfer of IP traffic over a lower-level ATM network. It also supports LAN emulation (LANE) approaches for an enterprise site network. This basic approach for transmitting IP packets, which have been fragmented and placed in small 48-byte cells plus a 5-byte header, is the approach most vendors support for their business customers when employing an ATM network. Figure 7.6


103

presents the basic ATM cell structure for an AAL–5 best-effort ATM cell.

AAL Type 5 For Voice Traffic

ATM Header

Portion of Voice Conversation

5 Bytes

48 Bytes of Voice Payload

8 Bytes reserved on the Last Cell of a Stream for AAL-5 Trailer Information

48 Bytes

Figure 7.6 The Best-Effort ATM Cell Structure Produced by the AAL–5 Process

Cisco Systems, for example, offers its MC3810 digital signaling processor for voice compression (to remove silence and pauses primarily), which only works with the simple AAL–5 process. The primary advantage is that AAL–5 is standard, and there is considerable experience with using it. Long-distance carriers in particular have used it for years to run their Frame-Relay service offerings, which are delivered over the carrier’s core ATM national backbone network. Also among ATM services is the constant bit rate (CBR) service offered under the AAL–1 option. AAL–1 is most frequently employed to emulate telephone circuits and to carry voice traffic in a telephone-like network. This AAL–1 service is specifically appropriate for carrying voice over IP packets in a long-distance network that has an ATM network at its core (as exists in much of the United States), with the ATM network emulating the standard telephone circuits, trunks, and, and high-speed facilities that connect from the individual metropolitan networks in each city.


104

Figure 7.7 portrays the process of transferring voice conversation to a number of either AAL–1 CBR cells or to a simpler AAL–5 best-effort cell production process.

Figure 7.7 The Process of Converting Voice Conversation into ATM Cells

Long-distance carriers already transport voice traffic over their core ATM national backbone networks. ATM facilities carry all traffic, whether it is voice, video, data files, TV, Internet requests and responses, or e-mail. The carriers can carry voice traffic in IP packets over their backbone ATM network. This is essentially a VoATM process without all of the signaling between the network protocols. The reason is that the national ATM network is impervious to the kind of traffic it is carrying. It carries everything. VoIP over an ATM network (usually termed VoATM), whether offered as an AAL–1 CBR process or the simpler AAL–5 process, can offer some attractive features for carrying time-sensitive voice traffic. Such features include the following:

• The creation and transmission of small fixed-size cells, which can pass through switches with minimum latency.

VOICE CONVERSATION

Variable Bit Rate Constant Bit Rate

AAL 1 PROCESS

QUALITY OF SERVICE REQUIREMENTS

SEGMENT FRAMES INTO CELLS

ATM Cells

AAL 5 PROCESS


105

This minimizes both delay and variation in delays. Voice is usually chopped into parts and placed in small IP packets that are then broken up (segmented) and delivered by fixed-sized ATM cells.

• The opportunity to transfer cells in the network at a

constant bit rate, if one chooses the AAL–1 form, and delivery them to the destination at the same rate. Further, timing information is contained within the cells to indicate to the destination host how to synchronize the delivery of the recreated analog voice signal in a fashion suitable to the human ear.

• The opportunity to offer a simple approach for

transferring the small cells containing the voice traffic in a best-effort AAL–5 fashion.

• The guaranteeing of known, previously agreed upon, QoS

features including a maximum cell transfer delay, a maximum cell-loss ratio, and a maximum variation in cell delay. These are important features of an ATM network that assist in controlling the quality of the network’s contribution to the delivery of the cells in a regular and unbroken stream.

• The queuing provided to satisfy the requirements of an

ATM virtual circuit.

• The special circuit emulation characteristics required to emulate private-line circuits used in a telephone network.

Three approaches that might be employed by an enterprise for delivering voice traffic over a public ATM network are as follows:

1. End-to-End Full ATM Network – A set of PVCs are pre-assigned for the purpose of signaling to a set of alternative destination sites. Having performed signaling, the source devices can send ATM cells containing segmented voice traffic over this circuit, which was previously established by the signaling process. The traffic can be transferred


106

under either AAL–5, the best-effort version, or AAL–1, which emulates a CBR circuit. There was high optimism for this approach, but with the maturing of high-speed Ethernet in the enterprise solution, this end-to-end ATM design has virtually disappeared.

2. Traffic from a Non–ATM Site at One End to a Full ATM Site

at the Other – An interworking function (IWF) node must be established at the edge of the non–ATM end network to interconnect non–ATM sites to an ATM network. The function of the IWF node at the non–ATM site is to signal over the PVC ATM signaling path, segment the voice message into cells, address the cells, and then send the addressed cells over the ATM network. At the destination ATM site network, the ATM voice cells are then forwarded to the destination station over the local ATM network. With the reduction of ATM enterprise networking, this option has also diminished.

3. Non–ATM Network Site to Non–ATM Network Site – The

most prevalent situation will occur when two enterprise sites employ non–ATM local networks (most likely high-speed Ethernet) to carry traffic throughout the local enterprise site. The most frequent deployment is the use of Ethernet to carry local traffic that is placed in IP packets. When two of these non–ATM networks wish to send voice traffic over a public ATM network, they each employ an edge IWF node, most likely placed as a module in their gateway router or as a box closely connected to that router. This IWF node then initially performs the conversion of the dialed digits to an IP packet and sends it to the gateway device. Then, the edge gateway router must convert the IP packet containing the dialed digits into a set of an ATM cells. These call-setup cells are then transmitted over the appropriate pre-assigned ATM PVC circuit to deliver the signal to the chosen edge gateway node at the destination site. At the destination node, the ATM call-setup signaling cells are reconstituted as an IP packet containing the dial signal to alert the destination phone and sent forward to that phone over the local


107

enterprise network. At the phone or PBX, the IP packet containing the dial signal is converted to an analog dial signal to ring the phone.

After the signal is accepted and a circuit between the two sites has been established, the spoken voice content is also placed in IP packets and subsequently placed into ATM cells at the source edge device. The cells are addressed and sent over the virtual circuit selected by the source edge router to the appropriate destination node. Once the cells arrive, they are converted back into IP packets, transferred over the local site data network, and subsequently delivered to the destination phone, where they are converted to a sound for the human ear. This local delivery network can be an IP–based network or a standard analog telephone network.

These three approaches for employing ATM to carry voice traffic are portrayed in Figure 7.8.

Figure 7.8 Three Approaches for Voice over ATM

ATM NetworkPVC for

ATM Signaling

CBR SVCs for Voice Transport SVC

PVC

Non-ATM Network

PVC forATM Signaling

CBR SVCsfor Voice Transport

SVC – Voice Transmission

Signaling PVC

Non-ATMNetwork

Non-ATMNetwork

ATM Network

PBX withATMModule

PBX withATMModule

ATMNetwork

1.

2.

3.


108

For private ATM networks, the individual switches in an ATM network exchange between themselves the complete topology of the network following the ATM Forum’s recommended Private Network Node Interface (P–NNI) specification. As a result, each edge switch then knows what all the other switches know of the network due to the exchange of the knowledge base of the network nodes and links. They also are aware of how much of the port and link capacities have already been allocated. Any edge switch can then send a call-setup cell (in standard UNI-3.1 format) along a chosen path to the set of ATM switches along the chosen path and require these switches to reserve a portion of their bandwidth capacity for the new circuit that is being established. Figure 7.9 portrays such a P–NNI informed ATM network.

Figure 7.9 Using P–NNI to Inform ATM Switches of the Current

Network Topology When interfacing two private ATM networks, which might be interconnected by a T1, DS–3, or SONET link, one can employ an IWF of two ATM edge switches and an appropriate link and employ a P–NNI (private network node interface) process to discover the core network topologies. Furthermore, when interfacing a private ATM network to a public one, the private

PBXPBX

VOICE OVER ATMCisco7000

ER IESOWR WCIS CO YST EM SS

Cisco7000ERI ES

OWR WCIS CO Y STE MSS

Cisco7000E RIE S

OWR WC ISC O YS TE MSS

Cisco7000ER IES

O WR WCI SCO YST EM SS

Cisco7000E RIE S

OWR WC ISC O YS TE MSS

Cisco7000ER IESOWR WCIS CO YST EM SS

Cisco7000ERI ES

OWR WC IS COY ST EM SS

Cisco7000ERI ES

OWR WCIS CO Y STE MSS Cisco7000

ERIE SOWR W

C ISC O Y STE MSS

Cisco7000ERI ES

OWR WCIS CO Y STE M SS

Cisco7000ERI ES

OWR WCIS CO Y STE MSS

Ci sco7000ER IES

O WR W

CI SC O YS TEM SS

ATM PNNI Routing For Switch Updates


109

NNI and the public one must interconnect and exchange information. Furthermore, where multiple public ATM networks are used in tandem, the broadband inter-carrier interchange (B–ICI) protocol would be used along with the appropriate signaling protocol. The signaling and call-setup connection for private ATM networks connecting to public and private ATM networks is portrayed in Figure 7.10.

Figure 7.10 Interworking the Signaling between Networks

One must be careful that one is setting up and sending cells for the same type of ATM service category. If one is setting up an ATM CBR AAL–1 circuit and cells, then the destination must have an ATM CBR AAL–1 circuit and be prepared to receive the same type of cells. If one can tolerate a less-sensitive AAL–5 variable bit rate (VBR), it also should have the same sort of circuit and cell format, end to end. The conversion of AAL–5 to AAL–1 cells would require converting the information field of the AAL–5 cell to the format of AAL–1. Furthermore, the appropriate sequence and synch bits, which are not included in the AAL–5 cell, must be created and added to the AAL–1 cell. Buffers would need to be created to hold the cells while they are converted and to recreate

Private ATM

Network

Private ATM

Network

Public ATM

NetworkUNI 4.0

Q.931

Q-SIG

ATM Inter-working

Interface

P-NNI

AAL-1 to AAL-1AAL-5 to AAL-5

Never AAL-1 to AAL-5 or the Reverse of AAL-5 to AAL-1

PUBLIC AND PRIVATE SIGNALING INTERWORKING

ATM Inter-working

Interface

Private NetworkPublic Network

Private Network


110

the synchronization timing. At least 10 ms might then be added to the transport time of the voice cells to perform the conversion and some additional time for their entering and removal from the buffer, with a possibility of lowering the quality of the delivered voice message. This cell-format and message conversion process for going from AAL–5 to AAL–1 format is portrayed in Figure 7.11.

Header 5 Bytes 48 Bytes

Header Seq/Synch Voice

5 Bytes 1 Byte 47 Bytes

Inter- working and Conversion Function

ATMNetwork

ATMNetwork

AAL- 5 Cell

AAL- 1 Cell

10.875 msecConversion plus Buffering Delay

AAL-5

AAL-1

Voice

Figure 7.11 Delay Required Converting AAL–5 Voice Cells to AAL–1 Cells

The power of an ATM network, however, is in its ability to handle all types of media, including voice, sound, picture (JPEGs and GIFs), motion pictures (motion JPEGs), video, and voice traffic. When an ATM WAN is already established, voice traffic can be added for no increase, or only a modest increase, in capacity since, as we have already described, the voice traffic for each call adds only 8 kbps of traffic for each call added to the network.


111

Conclusion Most enterprises requiring multi-site distance data networks over the past decade have found Frame-Relay service to be an attractive solution based upon price and the benefits of a continuously managed facility supported by the availability to customers of a 24- hour tech staff at centralized help desks. For high-speed connections, ATM network offer similar benefits. The existence of such network services provides the foundation for companies to move some or all of their inter-site voice traffic as an additional load on their existing Frame-Relay or ATM networks. The extensive experience with these WAN services should provide a sound basis for quick employment of voice service with these existing data services, as both can benefit from the same facilities and centralized support personnel.

113

Chapter 8

Service-Provider VoIP Offerings Many large service providers have begun rolling out VoIP offerings. However, the small service providers have been more aggressive, such as Vonage, 8x8, and Net2Phone, offering software and interface devices to allow residence customers to deliver voice traffic over their local broadband access connections. Recently, however, the larger service-provider companies, such as SBC, Qwest, Verizon, and AT&T, have brought their VoIP services to the market. Meanwhile, in contrast, MCI and Sprint have remained quiet on the issue of VoIP services; although it is assumed that they are also preparing their own versions of such services. Each of these service providers offer VoIP as an offering on top of their ATM or Frame-Relay networks, which already provide an underlying connection-oriented substructure that enables a level of control and consistency to the IP traffic. Table 8.1 presents a small selection of some of the early players that are offering VoIP services.


114

Table 8.1 A Selection of Service-Provider VoIP Offerings

More than 50 filings with a range of arguments have been submitted to the FCC. The RBOCs who have entered this arena, SBC and BellSouth in particular, have asked the FCC to produce a coherent policy on VoIP so that all entrants understand how they should operate. Some FCC commissioners have indicated they prefer that VoIP be developed as an unregulated Web service, although under pressure from the CLECs and some of the RBOCs, they are now attempting to deal with the local-loop facility cost issues associated with who uses those facilities and for what purpose. However, the state public utility regulatory agencies are most reluctant to deregulate VoIP traffic, as they face the loss of tax revenues at a time when state governments are seriously short of revenue. RBOC VoIP Services The RBOCs are in the process of introducing their own VoIP services. As an early entrant, Qwest is introducing a VoIP service in Minnesota in the first quarter of 2004 and will expand its

Company Price Service Availability

AT&T $39.99/mo. Local and Long Distance 100 U.S. mkts 2004

SBC $29-40/mo. Local and Long Distance 100 cities 2004

Verizon n/a Bus. and Res. DSL, Local, LD Initial offer 2004

Bell South n/a Bus. service only announced 2004

Qwest n/a 14-State svc area, Local, LD 2004

Time Warner $39.95/mo. Partner MCI/Sprint, Local, LD Begin 2004

MCI n/a TWC partner svc announced 2004-2005

Sprint n/a TWC partner svc announced 2004-2005

Covad $35- 60/mo. National Bus./ Res. Local, LD 4th qtr. 2004

Vonage $14.99 -34.99 Local and LD 300,000 cust. 2004

i2 Telecom $9.95/mo. Reseller Program announced 2004

GalaxyVoice $19.95-34.95 Bus. and Res. cust.., Local, LD 2004

8x8 $20/mo. Res. and Small Bus., Local, LD 2004

Company Price Service Availability

AT&T $39.99/mo. Local and Long Distance 100 U.S. mkts 2004

SBC $29-40/mo. Local and Long Distance 100 cities 2004

Verizon n/a Bus. and Res. DSL, Local, LD Initial offer 2004

Bell South n/a Bus. service only announced 2004

Qwest n/a 14-State svc area, Local, LD 2004

Time Warner $39.95/mo. Partner MCI/Sprint, Local, LD Begin 2004

MCI n/a TWC partner svc announced 2004-2005

Sprint n/a TWC partner svc announced 2004-2005

Covad $35- 60/mo. National Bus./ Res. Local, LD 4th qtr. 2004

Vonage $14.99 -34.99 Local and LD 300,000 cust. 2004

i2 Telecom $9.95/mo. Reseller Program announced 2004

GalaxyVoice $19.95-34.95 Bus. and Res. cust.., Local, LD 2004

8x8 $20/mo. Res. and Small Bus., Local, LD 2004

Chapter 8: Service-Provider VoIP Offerings

115

offering throughout its 14-state territory by the second quarter of 2004. SBC is in the process of offering its hosted VoIP service at a price starting at $30 per phone on a monthly basis. SBC’s VoIP service is currently available in 18 U.S. cities, including Chicago and Los Angeles. By the end of 2004, SBC will add 15 more locations, among which are New York, Philadelphia, and Boston. In total, SBC plans to offer VoIP capabilities in about 100 cities within the next 12 months. SBC’s brand called PremierSERVSM (a hosted IP communication service, or HIPCS) starts at $30 a month per phone for unlimited local dialing and goes to $40 a month for unlimited local and long distance. The service provides a broad sweep of features, including voice-mail and e-mail, which can be combined in a single inbox that can be accessed and forwarded to the customer. Furthermore, a "plug-and-play" feature enables users to plug in their IP phones from anywhere in their network. Among the features of this service are the following:

• Unified Messaging – Voice-mail and e-mail can be consolidated in a single inbox, and voice-mail can be forwarded like e-mail.

• “Find Me, Follow Me” – Enables employees to forward calls

to a mobile phone, a remote office, or another extension.

• “Click to Call” – Enables one-click calling from a phone set or PC Web browser.

As part of their approach to offering VoIP service, SBC and Verizon are discussing offering IP Centrex service—a hosted voice service offered by means of a set of next-generation softswitches and media gateways that they intend to deploy in their COs to provide new and innovative service offerings. Verizon Communications has selected Nortel Networks as its VoIP equipment provider and is in the process of accelerating the migration of its nationwide wireline network to packet-switching


116

technology. Verizon’s initial VoIP service deployment is scheduled for mid-2004 and will include hosted VoIP and multimedia services for both business and residence customers. In a common approach that many providers are following, Verizon plans to offer VoIP first to its DSL customers as an early 2004 initiative and then present VoIP service offers to business customers later in 2004. To support such IP services, Verizon has invested $55 billion in its network infrastructure since 2000, intending to create the nation’s largest converged IP network. As a result, Verizon intends to offer a suite of bundled services accessed by means of a broadband connection. These include local and long distance VoIP service as well as general Internet access. These services will be offered to both residential and enterprise business customers to be carried over Verizon’s common packet network. For business customers nationwide, Verizon plans to offer bundled local and long-distance voice, data, and new productivity-enhancing multimedia services and applications. Enterprise business customers will be able to augment traditional dial-tone services with more flexible IP services such as instant video calling, unified messaging, Web-based call screening and routing, and address book integration. The employment of Nortel Networks’ portfolio of VoIP solutions and multimedia communications, which includes VoIP VPNs, IP Centrex, and converged multimedia services, will enable Verizon to offer enterprise customers a number of expanded services. Among these are the ability to connect in a simple fashion multiple sites and to link telecommuters and mobile workers nationwide via a single high-speed packet network. This initiative builds upon Verizon’s Enterprise Advance service, a nationwide network buildout first announced in December 2002 that is now operational in 56 markets. Verizon will leverage the Enterprise Advance service to offer voice, data, and multimedia services both within and outside its traditional serving territory. At the more limited end of the spectrum, BellSouth has announced plans to offer VoIP services to its business customers but has yet to state specific services, offering dates, prices, or targeted markets.


117

CLEC VoIP Services Among the surviving CLECs, Covad has been leading the nationwide charge toward offering VoIP service. Covad has a large number of residential DSL customers and expects to offer nationwide local and long-distance calling over its national network to residence customers who have broadband access capability by the fourth quarter of 2004. The price will be $35/month for residence customers and is expected to be $60/month per line for business customers in a future offering, likely to occur in 2005. Long-Distance Carrier VoIP Services Among the IXCs, AT&T will introduce residential consumer VoIP services in a select set of U.S. cities in the first quarter of 2004, with the intent of quickly expanding its VoIP capabilities and targeting consumers in the top 100 U.S. markets. The carrier will offer IP–enabled local and long distance, plus enhanced features such as call forwarding, in these cities for customers with DSL or cable high-speed Internet connections. AT&T’s services will also offer residence consumers advanced call-management capabilities and Web-based features similar to the service already offered to many businesses. For business customers, the carrier intends to market a suite of VoIP–enabled services to a worldwide base of customers. Now, in early 2004, the VoIP offerings in the market range from about $30 to $65 per month for unlimited local, in-state, and long-distance service plus basic telecom services such as voice-mail. It is still uncertain what the other carriers will charge for similar services. However, AT&T has announced unlimited local and long-distance calling in New Jersey at $39.99 per month with a six-month introductory rate of $19.99. This compares to a current unlimited calling plan offering with AT&T’s traditional phone service at $49.95 in the same New Jersey area.


118

Cable VoIP Services Time Warner Cable intends to partner with MCI and Sprint to roll out its VoIP offerings in the United States. As part of this partnership, Time Warner plans a nationwide deployment of Internet phone service, which it currently offers on a limited availability to some of its customers in North Carolina. So far, the residential IP–based phone service (Digital Phone) was introduced earlier in 2004 in Portland, Maine. It will be available to customers in the North Carolina Raleigh–Durham Triangle later in 2004. This phone service package is priced at $39.95/month for unlimited local and long-distance calls within the 48 continental states. Time Warner’s multiple-year deals with MCI and Sprint are expected to help the company eventually expand its offering to 17 markets. However, MCI and Sprint have said little of the prospect of their offering a similar VoIP service on their own in the near future. Small Service-Provider VoIP Services When AT&T, SBC, or Verizon offer a flat-rate package, users see a handful of service fees related to state and federal regulations on their monthly invoice. Until recently, the small service providers such as Vonage and 8x8 did not have to worry about these regulations. However, with the focus of the regulators on VoIP services, they might soon gather a lot of attention to their services and cost allocation to the RBOC facilities. The number of small, independent VoIP service providers in the market continues to expand. Among these are the following: • i2 Telecom – i2 Telecom operates a reseller partnership program,

most recently with Sabio Information Technologies and Cotran Technologies, Ltd. i2 Telecom anticipates offering nationwide long-distance telephone calling for as little as a flat rate of $9.99/month for unlimited calling between subscribers and substantially reduced rates for international long-distance. The i2 Telecom product, InternetTalker, is portable and travels with you to anywhere there is an Internet connection. InternetTalker also can be used with 802.11 wireless LAN


119

access points and even wireless routers providing voice services within 150 feet of a wireless link to an Internet access connection.

• Vonage Holdings – Vonage was founded in January 2001 and has already grown a significant customer base that is completing millions of calls every week. Recently, a federal court judge in Minnesota ruled that Vonage Holdings could offer its VoIP service in Minnesota as an Internet data service. Since the service is considered an Internet data service, it would not be regulated or taxed by the state. The VoIP service offered by Vonage has attracted about 100,000 customers since the beginning of 2003 and expects to have close to 300,000 by the end of 2004. Eighty percent of Vonage’s customer base is residential, with the rest primarily comprising small businesses. The price of Vonage residential service ranges from $14.99 for 500 minutes of residential local and long-distance service to $34.99 for unlimited residential service. This service offers the potential of mixing voice and browser services, such as voice-mail, that customers can access through a Web browser as well as through their VoIP phones.

• Net2Phone – This company intends to offer a VoIP franchise program for cable companies and their subscribers. Liberty Cablevision and Cebridge Connections are expected to be their first franchise customers beginning in 2004.

• 8x8 –8x8 offers its Packet8 broadband VoIP service to

consumers and small businesses starting at a flat rate of $20/month per line for unlimited calling. As a result of this extremely low charge, users can substantially lower their monthly telephone expenses. There will be pricing pressure on the market if this service proves successful.

• GalaxyVoice – This company is offering a set of VoIP services

to residence customers at a flat rate of $19.95/month for unlimited continental U.S. calling. Business customers would pay $34.95 per line for 1,000 minutes of local and long-distance calling. The offered features include traditional caller ID, call waiting, call forwarding, call return, and three-way calling, as


120

well as voice-mail service. Furthermore, GalaxyVoice expects to offer very low international call rates, as well as the ability to optionally block selected calls.

Conclusion Therefore, 2004 is the year that a wide spectrum of carriers, RBOCs, CLECs, and small software and hardware providers are targeting for beginning the change from the traditional circuit-oriented switched network for voice to a converged, routed IP network for voice, data, and all other forms of media. Prices are uniformly planned to initially be flat-rate monthly charges of about $30 to $39 per month for residence customers, in addition to DSL and cable charges (which are usually about $49/month) and Internet service charges (which are usually about $20/month).

121

Chapter 9

Strategies for Vendors, Regulators, and Customers

The overriding question for the various interest groups is how best to exploit the potential of the protocols and products that are available for VoIP networks. Furthermore, how will customers react to products and applications that provide Web-based tools to augment VoIP services, and will this technology become the major vehicle for carrying voice traffic? The potential impact of the new tools and the cheaper transport of voice traffic over IP networks is providing a dilemma for federal regulators, who are torn between the desire to preserve the traditional telephone network, which has served us all so well for 100 years, and the promise that the Internet offers for voice traffic, which is similar to the benefits achieved with data traffic. The service providers have a comparable dilemma, wishing to reap the benefits of IP while fending off invaders into their traditional service areas. The following examines the more prominent interest groups and some of their likely strategies for dealing with VoIP networking. The Federal Communications Commission In the spring of 2004, as this book goes to press, the FCC is in the early stages of holding hearings on VoIP services. They have seemed in recent months to be leaning toward supporting the offering of VoIP service as a standard data service without the regulation long held over telephone voice service. However, the FCC in the spring of 2004 is beginning to tackle this issue with the intent of finding some way to encourage IP voice while at the same time finding a basis for covering the costs associated with maintaining the local telephone access loops. Even the RBOCs are sending mixed messages supporting both sides of the issue, asking for the benefits of regulation in maintaining access charge revenues from the long-distance carriers, while at the same time seeking a regulation-free environment for their broadband access services (DSL) and their own long-distance VoIP services.


122

The FCC is faced with a serious dilemma. Should it actively support the emerging employment of voice traffic over public and private Internets? Should it further assist VoIP growth by disregarding the issue of access charges—charges for the use of RBOC local loops for source and destination connections to carrier-supplied VoIP network service? Or should the FCC follow its previous precedent and dictate that a portion of the carrier’s VoIP revenue must be allocated back to the source and destination RBOCs? And what about local and national taxes derived from this service? These issues have both short- and long-range implications. As such, the following separates the recommended strategies into short- and long-range recommendations. Short-Range Strategies To allow both service-provider companies and customers to experiment with VoIP services, the FCC should follow a “watching and waiting” strategy to assess how the technology develops as well as the customers’ level of tolerance to the quality levels that are realized under various network loads and available bandwidths. Long-Range Strategies In the long run, the FCC must find a way to support the usage of the RBOC local loop for accessing the telephone network and IP–based networks for the purpose of sending long-distance calls. The issue still remains, however, as to what price customers—traditional telephone customers, DSL customers, VoIP customers, CLEC customers—will continue to pay for the usage and maintenance of the telephone local loop and whether they will use the local loop for dial-access to long-distance IP services. Moreover, will the line or the purpose of its usage sway the charges that are incurred by the customer? Generally, the allocation of long-distance revenue should not be a burden carried by the local loop. This is unsustainable in the long run. In any event, too many ways are being found to bypass the current allocation scheme. The local-loop service should be billed entirely as its own entity and not based upon what services are attached to it or how it is used.

Chapter 9: Strategies for Vendors, Regulators, and Customers

123

Another issue is whether VoIP service or any other IP service should be regulated as part of a universal national strategy or whether the larger benefit would arise from the elimination of all IP services regulation. This regulation avoidance is a particularly difficult issue when applied to the local-loop facilities as treated by the Telecommunication Act of 1996's Unbundled Network Element Platform, commonly called UNE–P. Concern has once again been raised about whether voice traffic carried over DSL service (which is carried over standard local-loop copper pairs), changes the nature of the local-loop regulation. The state public service commissions (PSCs) today set the discounted rates, frequently below cost, that the RBOCs can charge carriers and other CLECs for reselling service over the RBOC’s local loops. Additionally, MCI has complained about a BellSouth practice which dictates that customers subscribing to BellSouth’s DSL service must also subscribe to BellSouth local and metropolitan-area voice service. MCI would like to separate the voice spectrum on the local loop from the data spectrum. MCI would then be able to lease the voice spectrum (0 to 4 kHz) of the local-loop pair, while BellSouth offers the data spectrum (26 kHz to 1.1 MHz) for DSL service. Finally, on March 2, 2004, the U.S. Court of Appeals struck down the FCC rules forcing the Bells to lease their local access facilities at exceedingly low rates set by the FCC. It appears that the effective date of this court rejection will be delayed until summer 2004. However, unless all parties can come to a satisfactory agreement on profitable rates, this issue has the potential to upset any plan for voice services as well as Internet access that uses the RBOC local-loop facilities. Interexchange Long-Distance Carriers During the past decade, long-distance carriers have invested in a variety of means to connect to their customers. Of course, they continue to support connection by means of the telephone local loop. But companies (for example, AT&T) have invested in cable companies (now sold to Comcast) and wireless companies (in the process of being sold to Cingular) to connect customers to long-distance service, Internet access, IP services, as well as to the local


124

metropolitan network. These carriers are thus simultaneously customers that are supplying revenue to the local RBOCs, competitors that are sub-leasing the facilities of the RBOCs at discounted rates in order to compete with them for local and long-distance access, and pure competitors that bypass the local access facilities with their wireless and cable facilities. Thus, carriers have played all possible cards in this game, making enemies, suspicious partners, and unsettled and unsatisfied customers with their new and discarded access approaches. So, what should be the long-distance carrier’s future strategies, given that they have discarded their cable facilities and, at least in AT&T’s case, their wireless business and facilities? Short-Range Strategies In the short-range time period of one to five years, the carriers should experiment with VoIP service offerings while understanding that the longer-range results of IP–carried voice traffic will gradually diminish the revenue base that supports the long-distance network. Unlimited, flat-rate, long-distance traffic pricing of IP service offerings will erode the profitability of the long-distance carriers by offering revenue streams at a level too low to cover the embedded cost of the network as well as the maintenance, management, and support costs to engineer, upgrade, redesign, and modernize the network. Long-Range Strategies The carriers must find a way to support revenue-generating applications and database services offered on both public and private Internet networks. Revenue generated from connecting to these services over an IP network will, in the long run, offset any costs paid by the carrier and the customer to the RBOC for local-loop utilization. Additional access means will continue to be found, such as cable today and wireless in the short-range future. Thus, the RBOC local loops will not alone bear the additional burdens not faced by other access means. These burdens include the requirements of universal access, state and local taxing, loop unbundling and resale to competitors at a price below the long-term embedded cost of the facilities, and restrictions on pricing services and earning resulting


125

from regulation. This allocation of a portion of long-distance revenue to cover the embedded costs of local access loops must be removed, or it will increasingly become an incentive to avoid using the existing telephone local loops, stranding them in place without revenue to sustain their maintenance and continued utilization. This investment is too valuable to stumble into obsolescence. Regional Bell Operating Companies The local telephone companies have a long-standing investment in their local-loop access facilities and local CO switches. They are caretakers to this investment for both their shareholders and their customers. Until all the depreciation has been taken on these facilities, the telephone companies must continue to earn on them. Wherever they are made obsolete, their under-appreciated value must be written off the books against current earnings, injuring shareholders directly. As this situation approaches, the telephone companies withhold any maintenance, modernization, and support for the local loops and CO switches soon to be stranded and written off. During this process, customers find themselves injured by poor-quality service and (most likely) increasing costs. As such, customers who find it difficult to move to alternative access services are adversely affected by this obsolescence process. Short-Range Strategies The short-range strategies that the RBOCs should follow include the following:

1. Begin offering more services that are available only by means of the local loop, such as information sources, product ordering, and off-site data storage of user information.

2. Begin placing multiservice switches in the local COs and

begin bypassing their own circuit-switching facilities. Move selected customers to IP–based facilities and begin offering competitive VoIP local and long-distance services.


126

3. Begin investing in fiber to the neighborhoods to replace the majority of the length of the local loop, leaving only the “last mile” in place to connect to the customer.

4. Reduce the costs for long-distance access charged to the

carriers to minimize the incentive to bypass the local loop for long-distance calling. This also reduces the concern of the users of the local loop who already bypass the telephone CO switch and with it the long-distance recording. Engage the FCC and state PSCs in this process.

Long-Range Strategies The long-range strategies include the following:

1. Move a significant number of customers off the current circuit switches to IP switches.

2. Accelerate the depreciation of circuit switches and copper

local-loop facilities.

3. Create a minimum-cost lifeline service using the circuit switches and reduce any maintenance and modernization of these facilities.

Competitive Local-Exchange Carriers The CLECs constitute a mixed bag. Some are principally local-loop and metropolitan network service providers. Others are carriers that also provide CLEC access services for their customers. Still others actually have invested in local access and metropolitan networks of their own. However, the most common situation is for them to lease local loops, metropolitan trunks, and connection services from the local RBOC in order to provided services to their own customers. Their ability to deliver service is based upon the regulated discounts they receive on their leased facilities and the avoidance of regulation and access charges for the IP traffic, particularly VoIP traffic, which they carry.


127

Service Providers ISPs are positioned between all the players in the telephone industry. They provide a means for accessing the public Internet, routers and servers for finding addresses, servers for storing e-mail, and download flow-through sites for delivering and returning information from Web sites on the public Internet. As Internet traffic has intensified, the long-distance carriers, the RBOCs, and the CLECs have all chosen to offer Internet service themselves, either separately or in partnership with existing ISPs. Enterprise Businesses Business enterprises will have the most choices available to them as a result of the availability of voice and other services over IP–based networks. At the same time, these customers have the most to lose during the early migration stages, as well as the uncertain pricing and regulation applied to these services. Residential Customers Residential customers have the least risky set of alternative strategies. Their telephone local loop facility is already in place. It will remain there regardless of the strategy they employ. If they drop their local service to be replaced by cellular or cable telephone service, their old local loop still remains in place to possibly be used at a later date if they re-order the service. They can even migrate their old telephone number to any new service, such as voice over cable telephone, DSL, or cellular. VoIP Hardware and Software Vendors These vendors face the problem of supporting SIP and H.323 protocols as well as the gateway protocols of MGCP and MEGACO, and the skinny and simplified versions of these protocols. As businesses begin using VoIP as an alternative and reach a level of satisfaction with the quality of the sound, they will be encouraged to change out their old telephones and PBXs for IP


128

phones ($100 – $300) and IP servers ($3,000 – $5,000). Profit from these devices will help buttress the relatively low cost ($40/month) for VoIP local and long-distance calling. The profit will be in the devices, not in the service in the short term. Gradually, more and more software will be developed to take advantage of IP voice service, and the new software will carry a further level of profit to the industry. Eventually, VPN services will be offered as a set of private managed communications for specialized businesses such as banking, financial, and the investment industry. Conclusion Each of the preceding interest groups has a set of strategies that will lead to a network that is converged on IP–based services. Such convergence is not without considerable investment and migration cost, but each has clear paths to offer these services in competition with the other players. The reaction of each group to the plans of the others will accelerate all toward the investment in IP voice equipment and services in order to maintain a level of equilibrium with each other. The result will be more services at a cheaper cost to the customer, whether business or residential.

129

Chapter 10

Conclusion The ability to handle time-sensitive voice traffic has become the gold standard for network performance. Many switch vendors are introducing combined voice and data switches to assist in the transition to packetized voice transmission. Most of these switches are smaller products that would primarily serve as remote switches, transition switches, or office switches at a customer’s premises. Additionally, the H.323 family of protocols (to deliver audio and video traffic over a diverse set of networks) is now beginning to replace the earlier H.320 videoconference standard. This is required for end-to-end transmission of voice traffic to a gateway device for placement on private WANs, such as Frame Relay, or for translation to the national phone networks system. Many companies are now have offerings under way, and customers are in the early stages of experimenting with VoIP, Frame Relay, and ATM in order to reduce their telephone costs and consolidate their networks over a single protocol set.

131

Appendix

VoIP Terminals and Other Equipment IP PBX Components and Prices Alcatel OmniPCX Enterprise System ............................................ $300 Avaya S8700 Communications Manager-Based IP PBX .........$1,400 Cisco Call Manager v3.3.3 Based IP PBX...................................$1,300 Mitel 3300 ICP IP PBX .................................................................... $375 Nortel MCS 5100 IP PBX................................................................ $750 IP Phones and Prices (From Ataractic Corporation 2000–2003) Cisco 7920 Wireless IP Phone – CCM Licensed.......................... $745 Cisco 7920 Wireless IP Phone – Spare .......................................... $575 Cisco 7940G Global IP Phone MGCP/SIP ................................. $309 Cisco 7960G Global IP Phone MGCP/SIP ................................. $399 Cisco 7960G IP Phone MGCP/SIP............................................... $345 GrandStream BudgetTone 101 IP Phone........................................ $75 Grandstream BudgetTone 102 SIP Phone ...................................... $85 pDialog SipTone Ethernet Phone................................................... $245 Polycom IP400 – H.323 VoIP Phone ............................................ $399 Polycom IP500 – H.323 VoIP Phone ............................................ $299 Polycom SoundStation 3000 Conference Phone.......................... $999 Polycom SoundStation 3000 Conference Phone.......................... $999

for 3Com NBX QTelNet FreeRide IP–1301 Phone ................................................ $595 QTelNet FreeRide IP–2301 Phone ................................................ $595 Snom 105 IP Phone........................................................................... $225 Snom 200 IP Phone SIP/H323....................................................... $275 Snom 220 IP Phone with No Keypad Module..........................~$315 Snom 220 IP Phone with Optional 20-Button Keypad .............. $399 SoundPoint 600 SIP Deskset ........................................................... $435 SoundPoint H.323/MGCP Deskset ............................................... $375


132

SoundPoint SIP Deskset................................................................... $375 Uniden UIP300 H.323 VoIP Phone with Power Adapter.......... $279 H.323 IP Phones and Prices Cisco 7905G ....................................................................................~$185 Polycom IP400 – H.323 VoIP Phone ............................................ $399 Polycom IP500 – H.323 VoIP Phone ............................................ $299 Uniden UIP300 H.323 VoIP Phone with Power Adapter.......... $279 SIP–Only Phones Cisco 7940G Global IP Phone MGCP/SIP Cisco 7960G Global IP Phone MGCP/SIP Cisco 7960G IP Phone MGCP/SIP ipDialog SipTone Ethernet Phone 1.2.0 Mitel 5055 SIP Phone 2.0 Polycom SoundPoint 600 SIP 1.0.6 Siemens optiPoint Standard SIP Phone 2.2 Snom2000 VoIP Phone 1.165 Zultys ZIP 4x4 General List of IP Phones and Vendors Vendor Product 3Com SIP phone 3e Technologies 3e-710 Telephony Gateway 3e-720 Telephony Gateway 8x8 Company DV324 Desktop Videophone DV325 IP Desktop Videophone DT326 VoIP Telephone ADtech SI 160

Appendix: VoIP Terminals and Other Equipment

133

Vendor Product Alcatel e-Reflexes 4010 e-Reflexes 4020 e-Reflexes 4035 WebTouch One WebTouch Plus Allied HPS netPCphone AltiGen Communications Alti-IP 600 IP Telephone Anyuser.com IP Phone USB Phone Avaya 4602 IP Telephone 4606 IP Telephone 4612 IP Telephone 4620 IP Telephone 4624 IP Telephone 4630 IP Screen Telephone BMC Computers HP300 IP Phone HP400 IP Phone HP500 Wireless IP Phone Bloophone Bloophone Handset Broadmedia IP Phone BTL System e-Phone C&S Technology VoIP IP Phone GVP-4000i Videophone for IP Callserve Internet telephone handset Calypso Wireless 1250i Video Phone


134

Vendor Product Cidco Communications IP17 IP200 IP210 WIP281 Cirilium Power~Suite IP Phone Cisco Systems IP Phone 7902G IP Phone 7912G IP Phone 7910 Wireless IP Phone 7920 IP Conference Station 7935 SIP IP Phone 7940 SIP IP Phone 7960 Clipcomm CP-100 CP-101 Comdial iPrimo CommuniTech Claritel i750 Cosmobridge IP Phone CuPhone CuPhone-USB VideoPhone D-Link India DHP-100 IP Telephone D-Link Systems DVC-1000 i2eye Digital Service Group IN-Call USB Phone DSG Technology InterPhone e-tel FreeRide FR200 FreeRide FR210


135

Vendor Product Elesign ESP1200 ESP1201 ESP1202 Equator Technologies IP Video Phone Ericsson Dialog 3413 ESI IP 40e IP 200e Eutectics IPP 200 Handset IPP 210 Headset Adapter IPP 500 Series Desktop Speaker

Phone IPP 510 USB Speaker Phone IPP 520 USB Speaker Phone IPP 700 Cordless Phone IPP 2000 Standard Telephone

Adapter Formosa Industrial Computing iPH-D00 iPH-E00 Fujitsu SRS-12i SRS-24i GCT-Allwell Taichi II Taichi III Genesis Systems Genesis SOHOTel Hippo 200E 200EP 250E 250EP 300EP


136

Vendor Product InnoMedia MTA 3308 IP Phone MTA 3368 IP VideoPhone Innovaphone IP- Phone tiptel 200 Inter-Fone IF101-M Inter-tel Eclipse IP PhonePlus Axxess IP PhonePlus InterActive Group SoundXchange Intracom netPhone-VoIP Terminal ipDialogue SipTone Ethernet Phone Komodo Technology Komodo Fone 200 Komodo Fone 300 lwatsu SIP Phone Omega-Phone DCKT970 OMEGATREK ilx-5001 IP Phone ilx-5005 IP Phone ilx-5010 IP Phone ilx-5020 IP Phone ilx-5140 IP Phone ilx-5822 IP Phone Micronet Communications SP5100 Internet IP Phone Mitel Networks 5001 IP Phone 5005 IP Phone 5020 IP Phone 5010 IP Phone 5140 IP Applicance 5201 IP Phone


137

Vendor Product Mitel Networks 5205 IP Phone 5215 IP Phone 5220 IP Phone 5230 IP Appliance 5240 IP Appliance Nehftec IP-1001 NSP-21 GVP-4000i NR-1000 Net2Phone IP Phone Yap Phone Netergy Microelectronics Audacity-T2 IP Phone Audacity-T2U Wireless IPPW Netripples RAYphone Nextro IP Phone 1000 IP Phone 1000M NICTEL 1018M 1018 1020U Nortel Networks Meridian Digital Telephone IP

Adapter i2004 Internet Telephone Ortena Networks SIP Netphone Paramax WebTouch One Pigtel xpressa Polycom SoundPoint IP SoundStation IP


138

Vendor Product QiiQ Q-FONE-USB Q-FONE-ALL Quicknet Technologies My Internet Phone Sanyo Multimedia Tottori SIP-1800 SIP-2000 IPP-3200 Siemens optiset E Entry optiset E Basic optiset E Standard optiset E Advance optiset E Advance Conference Skywave SkyPhone Snom Technology snom 100 snom 200 Softfront KISARA Handset Solwise AV-3500 IP/PSTN SpectralLink NetLink Wireless Telephones e340 i640 Super Technologies Super-Phone Swissvoice Group IP10 IP20 Swyx Communications SwyxPhone SysMaster VM 2100 TEK DigiTel V-SERVER iPOTS


139

Vendor Product Telrad Connegy i.Picasso 6000 TelStrat i2732 IP Telephone Texas Instruments TNETV1001 Enterprise IP

Phone TigerJet Network USB handset USB handset with keypad USB telephone interface PCI telephone interface Tone Commander Systems 7210 7220 UniData Communications IPW-2000 IPW-3500 IPC-4000 Uniden America VoIP iMerge VOIX IP-Station WebCall World IP Phone Welltech Computer LAN Phone 101 USB Internet Phone Xilinx VoIP Phone ZipCOM USB Phone Set-B USB Phone Set-C USB Phone Set-D


140

Vendor Product ZMM Technologies PCNet Phone ChatSet ChatPhone PC Phone Converger Zultys Technologies ZIP 4x4 IP Phone Cisco Systems Gateway and Module Component Costs Description Capacity List Price Catalyst 4000 10/100BaseT Switching 48 ports $5,995

Module per module Catalyst 4000 Access Gateway Module 192 user ports $7,495

Catalyst 4000 AGM 8-Port RJ21 FXS 8 ports $1,995

Module per module

Catalyst 4006 Chassis 6 slots $9,995 Catalyst 6000 10/100 BaseT Switching 48 ports $12,995

Module per module Catalyst 6000 FXS Analog Station 24 ports $9,995

Interface Module per module Catalyst 6000 Voice T1 + Services 8 ports $19,995

Module per module Centralized Management & Monitoring Per 100 $4,000

IP Phones Cisco 7960 Expansion Module 1/phone/ $395

exec. assist. Cisco CallManager 3.1 Software 1 per server $5,995

for the MCS


141

Description Capacity List Price Cisco Digital PBX Adapter (DPA) 7630 Supports 24 $6,995

digital lines Cisco IP Phone 7960, Manager Set 1 per employee $645 Cisco IP Softphone CD/100 licenses 100 users $10,500 Cisco VG200 Voice Gateway Module 1 per office $995 Dual-Port 48 Channel T1 Voice Network 2 T1 ports $9,800

Module per VG200 MCS-7835 Server For 2,500 $11,595

IP Phones Avaya Gateway and Module Component Costs Description Capacity List Price 4612 IP Telephone 1 per employee $440 4624 IP Telephone 1 per executive $769

assistant Avaya VisAbility Software 1,500 users $55,000 Control LAN Board Signaling 300 calls $1,250 Definity PBX Software Upgrade Per G3R PBX $9,000 G700 Media Gateway 450 IP phones $19,200 Hardphone Digital Phone 30 users $3,938 IP Softphone 12 users $2,700 IP Softphone 30 users $5,100 Media Processor Board 32 IP calls $9,000

with G.729


142

Description Capacity List Price MultiVantage Software 1 per media $25,000

server S8700 Media Server 1 per system $20,000

143

References Baumgartner, Jeff, “Unlocking the Promise of VoIP,” CEO,

November 2003. Bellamy, John C., Digital Telephony, 3rd Ed. (Wiley, 2000). Brown, Kevin, IP Telephony Unveiled (Cisco Press, 2004). Cole, R.G. and Rosenbluth J.H., “Voice over IP Performance

Monitoring,” ACM SIGMON Computer Communication Review, April 2001.

Cisco, Networkers 1999-2003, Breakout Sessions. Davidson, Jonathan and Peters, James, Voice over IP Fundamentals

(Cisco Press, 2003). Davidson, Paul, “FCC Pushes Phone Companies to Settle Leasing

Dispute,” USA Today, April 1, 2004. Duffy, Jim, “More VoIP Issues Bubbling Up,” Network World,

February 9, 2004. Feder, Barnaby, AT&T Bings Internet Telephone Service to New

Jersey, New York Times, March 30, 2004. Freeman, Brian, “Fundamentals of IP Telephony,” National

Communications Forum, October 1998. Gross, Grant, “Regulation Called a Threat to VoIP,” Network

World, February 9, 2004. IP Phones, http://www.voiptimes.com/research/products/

ip_phones/VoIP Times. IP Phones 2, Atacomm, Ataractic Corporation, 2003.


144

Labaton, Stephen, “Thorny Issues Await F.C.C. as It Takes Up Internet Phones,” New York Times, February 9, 2004.

Markpopoulou, Athina, et al., “Assessing the Quality of Voice

Communications over the Internet Backbones,” IEE/ACM TON, October 2003.

Marsan, Carolyn Duffy, “SIP Rollouts Hit,” Network World,

February 2, 2004. McQuerry, Steve, McGrew, Kelly, and Foy, Stephen, editors, Cisco

Voice over Frame Relay, ATM, and IP (Cisco Press, 2003). Mier, Edwin, “Nortel Leads the Way in VoIP Applications That

Support Teleworkers,” Network World, December 8, 2003. Minoli, Daniel, and Minoli, Emma, Delivering Voice over IP Networks

(Wiley, 1998). Morrissey, Peter, “SIP Packs a Punch,” Network Computing, August

21, 2003. TRA (Telecommunications Research Associates), “Understanding

Voice over IP,” 1998. Varshney, Upkar, et al., “Voice over IP,” CACM, January 2002.

145

Glossary AAL–[x] ATM adaptation layer–x ARC admission confirmation ARJ admission rejection ARQ admission-to-the-network requests ASCII American Standard Code for Information

Interchange ATM asynchronous transfer mode B–ICI broadband inter-carrier interchange CBR constant bit rate CCM call control module CIR committed information rate CLEC competitive local-exchange carrier CO central office DHCP dynamic host configuration protocol DLCI data link control indicator DNS domain name server DSL digital subscriber line [also xDSL] DSLAM digital subscriber line access multiplexer (or

module) DS–[x] digital signal [level x] ETSI European Telecommunications Standards

Institute FCC Federal Communications Commission GIF graphics interface format HIPCS hosted IP communication service HTML hypertext markup language HTTP hypertext transfer protocol IETF Internet Engineering Task Force ILEC incumbent local-exchange carrier IP Internet protocol ISDN integrated services digital network ISP Internet service provider ITU International Telecommunication Union IWF interworking function IXC interexchange carrier JPEG Joint Photographic Experts Group LAN local-area network


146

LANE local-area network emulation LATA local access and transport area LDAP lightweight directory access protocol LNP local number portability MAC media access control MEGACO media gateway control MGCP media gateway control protocol MPLS multiprotocol label switching NAT network address translation NIC network interface card OSPF open shortest path first PBX private branch exchange PCM pulse code modulation P–NNI private network node interface PoP point of presence PPP point-to-point protocol PSC Public Service Commission PSTN public switched telephone network PVC permanent virtual circuit QoS quality of service RBOC regional Bell operating company RCF registration confirmation RRQ registration request RTSP real-time streaming protocol RTCP real-time conferencing protocol RTP real-time transport protocol SAP session announcement protocol SDP session description protocol SIP session initiation protocol SONET synchronous optical network SS7 signaling system 7 TCP transmission control protocol TIPHON Telecommunications and Internet Protocol

Harmonization over Networks UDP user datagram protocol UNE–P Unbundled Network Element Platform URL universal resource locator VBR variable bit rate VoIP voice over IP VPN virtual private network

Glossary

147

WAN wide-area network WRED weighted random early detection

basics of voip

Documents