Basics of VoIP by Michael Elcock

The Basics of Voice over Internet Protocol

Presented by the International Engineering Consortium

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 publications@iec.org • www.iec.org

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 industryuniversity 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.

iii

IEC University 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 following sponsoring organizations make this valuable program possible. For more information about the program, please call +1-312-559-4103 or send an e-mail to universityprogram@iec.org.

These are some of the universities that participate in the University Grant Program: The University of Arizona Arizona State University Auburn University University of California at Berkeley University of California, Davis University of California, Santa Barbara Carnegie Mellon University Case Western Reserve University Clemson University University of Colorado at Boulder Columbia University Cornell University Drexel 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 Edinburgh University of Florida Georgia Institute of Technology

University of Glasgow Howard University Illinois Institute of Technology University of Illinois at Chicago University of Illinois at Urbana/Champaign Imperial College of Science, Technology and Medicine Institut National Polytechnique de Grenoble Instituto Tecnológico y de Estudios Superiores de Monterrey Iowa State University KAIST The University of Kansas University of Kentucky Lehigh University University College London Marquette University University of Maryland at College Park Massachusetts Institute of Technology University of Massachusetts

McGill University Michigan State University The University of Michigan University of Minnesota Mississippi State University The University of Mississippi University of Missouri-Columbia University of Missouri-Rolla Technische Universität München Universidad Nacional Autónoma de México North Carolina State University at Raleigh Northwestern University University of Notre Dame The Ohio State University Oklahoma State University The University of Oklahoma Oregon State University Université d’Ottawa The Pennsylvania State University University of Pennsylvania

University of Pittsburgh Polytechnic University Purdue University The Queen’s University of Belfast Rensselaer Polytechnic Institute University of Southampton University of Southern California Stanford University Syracuse University University of Tennessee, Knoxville Texas A&M University The University of Texas at Austin University of Toronto VA Polytechnic Institute and State University University of Virginia University of Washington University of Wisconsin-Madison Worcester Polytechnic Institute

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

The University of Arizona

Columbia University

The University of Kansas

The University of Minnesota

The Pennsylvania State University

Texas A&M University

Arizona State University

Cornell University

The University of Kentucky

The University of MissouriColumbia

The University of Pennsylvania

The University of Texas at Austin

Auburn University

Drexel University

Lehigh University

The University of MissouriRolla

The University of Pittsburgh

VA Polynechnic Institute and State University

University of California at Berkeley

The University of Florida

Marquette University

North Carolina State University at Raleigh

Polytechnic University

The University of Virginia

University of California, Davis

Georgia Institute of Technology

The University of Maryland at College Park

Northwestern University

Purdue University

The University of Washington

University of California, Santa Barbara

Howard University

Massachusetts Institute of Technology

University of Notre Dame

Rensselar Polytechnic University

The University of WisconsinMadison

Carnegie Mellon University

Illinois Institute of Technology

The University of Massachusetts

The Ohio State University

University of Southern California

Worcester Polytechnic Institute

Case Western Reserve University

University of Illinois at Chicago

Michigan State University

Oklahoma State University

Stanford University

Clemson University

University of Illinois at Urbana/Champaign

The University of Michigan

The University of Oklahoma

Syracuse Univesity

The University of Colorado at Boulder

Iowa State University

Mississippi State University

Oregon State University

University of Tennessee, Knoxville

International Affiliated Universities Ecole Supérieure d’Électricité

McGill University

Ecole Nationale Supérieure des

Technische Universität München

Télécommunications de Bretagne

The Queen’s University of Belfast

Ecole Nationale Supérieure des

Universidad Nacional Autónoma de México

Télécommunications de Paris

Université d’Ottawa

Imperial College of Science, Technology and Medicine

University of Edinburgh

Institut National Polytechnique de Grenoble

University of Southampton

Instituto Tecnológico y de Estudios Superiores de Monterrey

University College London

KAIST

University of Glasgow

University of Toronto

IEC Media Partners 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 Avenue Suite 600 Santa Ana, CA 92707-8700 714-513-8400 www.americasnetwork.com

Reed Business Information 275 Washington Street Newton, MA 02458 617-964-3030 www.commvergemag.com

One IBM Plaza Suite 2300 Chicago, IL 60611 312-595-1080 www.internettelphony.com

1909 Avenue G Rosenberg, TX 77071 877-588-1649 www.privatebroadband.com

98 Spit Brook Road Nashua, NH 03062-5737 603-891-0123 www.light-wave.com

8878 South Barrons Boulevard Highlands Ranch, CO 80129-2345 303-470-4875 www.wirelessweek.com

Shorecliff Communications LLC 26311 Junipero Serra Road, Suite 110 San Juan Capistrano, CA 92675 800-608-9641 www.shorecliffcommunications.com

2615 Three Oaks Road Suite 1B Cary, IL 60013 847-639-2200 www.ospmag.com

3300 North Central Avenue, Suite 2500 Phoenix, AZ 85012 480-990-1101 www.x-changemag.com

999 Oakmont Plaza Drive, Suite 100 Westmont, IL 60559-1381 800-227-1234 / 630-986-1432 www.bcr.com

P.O. Box 40079 Phoenix, AZ 85067-0079 480-990-1101 www.phoneplusmag.com

2500 Tamiami Trail North Nokomis, FL 34275 941-966-9521 www.comnews.com

777 East Speer Boulevard Denver, CO 80203-4214 303-733-2500 www.rcrnews.com

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

vii

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

portion of their inter-site voice traffic on their private data networks. But given VoIPâ&#x20AC;&#x2122;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 Weblike 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

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 longdistance 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â&#x20AC;&#x201D;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â&#x20AC;&#x2122;s fundamental architecture, which is based upon a fixed starconnection 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

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;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 interconnected by means of carrier long-distance networks.

Metro Net

Metropolitan Network Carrier PoP

Carrier PoP

National Carrier Backbone Network

Carrier PoP

Metropolitan Network

Carrier PoP

Carrier PoP Carrier PoP Carrier PoP

Metropolitan 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

Chapter 1: Introduction

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â&#x20AC;&#x2122;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 rewiring. 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â&#x20AC;&#x2122;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

The Basics of Voice over Internet Protocol

federal ruling on access charges. This is the real VoIP issue from a long-distance carrier standpointâ&#x20AC;&#x201D;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â&#x20AC;&#x2122;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

Chapter 1: Introduction

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â&#x20AC;&#x2122;s (ISPâ&#x20AC;&#x2122;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â&#x20AC;&#x2122;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.

The Basics of Voice over Internet Protocol

Residence Customer

Central Office

Public and Private Internet IS P

Carrier POP

Business Customer

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.

Chapter 1: Introduction

Central Office

IP Telephony Adapter

PS TN

DS L Modem Public and Private Internet

Cable Modem Cable Head End Office

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.

The Basics of Voice over Internet Protocol

Cable Modem

Cable Head End Office

DSL Modem Telephone Modem

Dial-up Analog Line

DS LAM Public and Private Internet Central Office

IS P

Carrier POP

Public Metro Net

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.

Chapter 1: Introduction

PSTN

PBX

IP Networks Private Line, WAN, Public Internet IP

PBX

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.

The Basics of Voice over Internet Protocol

MPLS Path Handler

Call Agent

Call Agent SS7

SS7

LOCAL PS TN

Voice

National IP Network

PRI

LOCAL PS TN PRI

MPLS Path Handler

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â&#x20AC;&#x201D;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 12

Chapter 1: Introduction

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 longdistance 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 prestandardization 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.

The Basics of Voice over Internet Protocol

Who will standardize the protocols used by VoIP? Fortunately, this task doesnâ&#x20AC;&#x2122;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â&#x20AC;&#x201C;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

Chapter 1: Introduction

that enables a gateway device at the edge of a enterpriseâ&#x20AC;&#x2122;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â&#x20AC;&#x2122;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. S tandard Telephone Network V.70, V.90, V92 Dial Terminals H.324 PC Terminal

H.323 V0IP Network

H.323 Gatekeeper Server

S tandard Telephone IP Network IS DN Network H.320 Phone

H.323 Gateway Router

H.323 PC Terminal H.323 IP Telephone

H.323 Message Control Unit

Digital Telephone

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

The Basics of Voice over Internet Protocol

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.

Video Equipment

Audio Equipment

User and System Data Applications

Video Codec H.261 and H.263 Audio Codec G.711, G.722, G.723, G.728 G.729 T.120 and H.225 Data Transfer

H.245 Control System Control

H.225 Call Control H.225 RAS Control

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

Chapter 1: Introduction

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â&#x20AC;&#x201C;based architecture, and voice traffic seems to be moving in this common direction.

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.

The Basics of Voice over Internet Protocol

Voice Channel Voice Signal Output Voltage

Frequency (K-Hertz) .2

Tone Dialing Signals

S ystems Control Signals

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

Chapter 2: Characteristics of Voice and IP Traffic

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.

Voice - the Most Restrictive and Smallest Tolerable Level of Delay

CB Quality S atellite Quality

FAX and Broadcast Quality

Voice Quality

0 800

100

200

300

400

500

600

700

Time in msecs 150 msec Maximum Target Voice Delay

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 linesetup signal and the call itself are delivered as a continuous analog signal, which is then digitized at the CO switch and sent over

The Basics of Voice over Internet Protocol

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.

Chapter 2: Characteristics of Voice and IP Traffic

Video Conferencing Standards NetType

ISDN

ATM

PSTN

POTS

LANS

Standard

H.320

H.321

H.322

H.324

H323

Year Std

1990

1995

1996

Audio

G.711

G.723.1

Codec

G.722,28 G.722,28 G.722,28 G.72

Audio Rates 64 kbps 64 kbps

1996-98 G.711 G.72-29

64 kbps 6-8 kbps 6- 64 kbp

Video

H.261

Codec

H.263

Data

T.120

Control

H.230,42 H.242

H.242,30 H.245

H.245 H.225

Multiplexing H.221

H.221

Signaling

Q.931

H.223

H.261

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 connectionoriented 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.

The Basics of Voice over Internet Protocol

H.323 PROTOCOL MULTIMEDIA OVER LANs VIDEO

AUDIO

CONTROL/ MANAGEMENT

H.261

G.711, 722

RAS

H.263

G.723

H.225

Signaling

DATA

Control

H.225

H.245

T.124

G.728,29 RTP UDP

X.224 Class 0

T.125

TCP

T.123

IP LAN Layer 2

T.123 IEEE 802.3

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 localloop 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

Chapter 2: Characteristics of Voice and IP Traffic

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

The Basics of Voice over Internet Protocol

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 â&#x20AC;&#x153;toll qualityâ&#x20AC;? 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.

45 msec Sample

Encode

64 msec Packetize

< 100 msec Transmit

Speaking Network

Hearing Output

45 msec Decode

64 msec Jitter Buffer

Reconstruct

Receive

Total of Less Than 250 msecs of Delay is Tolerable But Delay of Less than 150 msec is the Standard

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 26

Chapter 2: Characteristics of Voice and IP Traffic

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

Voice Quality Delay From Various Compression Methods Delay Compression Method (msec) 64K PCM (G.711)

0.75

32K ADPCM (G.726)

16K LD-CELP (G.728)

3â&#x20AC;&#x201C;5

8K CS-ACELP (G.729)

8K CS-ACELP (G.729a)

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â&#x20AC;&#x2122; recommended WRED, or weighted random early detection, of selected packets).

The Basics of Voice over Internet Protocol

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).

PBX

PBX Gateway Router

Local S witch

PBX

PSTN

Edge Router

WAN Services

Public and Private Internet

PBX Gateway Router

Edge Router

Local S witch

Figure 2.4 Inter-Site Voice Connection Alternatives

Chapter 2: Characteristics of Voice and IP Traffic

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.

The Basics of Voice over Internet Protocol

Telephone C.O. Switch

Destination IP Telephone

S D

m e ri d a i n

IP Phone

ua M

ode

e r

id a

D S

i r oc

Du a Mo d e

2 A BC 3 D EF

4 I 5 7 *

8 0

Mi o c

L 6 M NO

V 9 #

e n a e a

IP Server/PBX

Gatekeeper

C is c o7 0 0 C IS OS Y S E C M TS R W O

is c o 7 0 C IS C C OS S YT E MS

ER IE S

WR O

A C B

S 8

V Z #

DE 3 F

MN 6 O 9

ne a a e

E R IE S

IP Network

LAN LAN

Gateway Router

Source PC Telephone

1 4 7

Destination PC Telephone

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 cablemodem 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. Cablemodem 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.

Chapter 2: Characteristics of Voice and IP Traffic

Central Office

IP Telephony Adapter

PS TN

DS L Modem Public and Private Internet

Cable Modem Cable Head End Office

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.

The Basics of Voice over Internet Protocol

The Standard VOIP Packet Format VoIP Packet Link

UDP

RTP

Voice

Header

Payload

12 Bytes

X Bytes

20 Bytes

8 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

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 32

Chapter 2: Characteristics of Voice and IP Traffic

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.

The Basics of Voice over Internet Protocol

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, callproceeding 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â&#x20AC;&#x2122;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.

H.225 Call Setup

H.323

Call Proceeding H.245 Invite

SIP

Acknowledge

MGCP

Acknowledgement

SDP

PSTN SS7 Signaling Network

CRC SDP

Figure 2.8 Connecting VoIP to Telephone Signaling Networks 34

Chapter 2: Characteristics of Voice and IP Traffic

Assigning IP Telephone Addresses â&#x20AC;&#x201C; 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 myname@earthlink.net). 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 callassisting 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â&#x20AC;&#x2122;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

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;s data network.

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 flatrate 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â&#x20AC;&#x2122; 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â&#x20AC;&#x2122; 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.

The Basics of Voice over Internet Protocol

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 delaysensitive 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

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

IP Phone

PSTN IP PBX

Public Internet Gateway VOIP Router

Private Interne t

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 siteto-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.

The Basics of Voice over Internet Protocol

IP Phone

PSTN IP Phone

IP PBX

Public Internet

IP PBX

Gateway VOIP Router

Private Line or Private Internet

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.

Chapter 3: VoIP Models for Connection

IP Phone

PSTN IP Phone

IP PBX

Public Internet

IP PB X

Gateway VOIP Router

Gateway VOIP Router IP Phone

Private Internet IP PB X

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 41

The Basics of Voice over Internet Protocol

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.

Telephone Central Office Building

PSTN

Public Internet Dialup Modem

MultiService Switch

Gateway VOIP Router

Private Internet

Figure 3.4 Residence Dial RBOCâ&#x20AC;&#x201C;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â&#x20AC;&#x2122;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 42

Chapter 3: VoIP Models for Connection

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.

Telephone Central Office Building

PSTN

DSL Mode m

DSLAM

Gateway VOIP Router

Public Internet

Figure 3.5 Residence DSL VoIP

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;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.

PSTN Cable Head End Office

Cable Modem

Public Internet CMTS

Gateway VOIP Router

Private Internet

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â&#x20AC;&#x2122;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.

Chapter 3: VoIP Models for Connection

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â&#x20AC;&#x2122;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â&#x20AC;&#x201C;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

The Basics of Voice over Internet Protocol

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 trunkbased 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

Chapter 3: VoIP Models for Connection

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.

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-topoint 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 49

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x201D;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.

VoIPâ&#x20AC;&#x201D;Uses Audio Component of H.323 SSystem ystemControl Control and User Interface

Video Video I/O Equipment

Audio Audio I/O Equipment

Video Codec H.261, H263

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

S ystem Control H.245 Control Call Control H.225. 0 RAS Control H.225. 0

User User Data Data Applications T.120

Session Layer and Above

Receive Path Delay H.225.0 Layer LAN S tack

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.

Chapter 4: VoIP Using the H.323 Protocol

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â&#x20AC;&#x201C;based telephone network with a private-lineâ&#x20AC;&#x201C;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 circuitswitched 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

The Basics of Voice over Internet Protocol

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, interconnected 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â&#x20AC;&#x201C;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, lessrestrictive 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

Chapter 4: VoIP Using the H.323 Protocol

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.

Reliable TCP Delivery Unreliable UDP Delivery H.245

H.225

Audio/Video Streams

Call Control RAS

TCP

RTCP and RTP

UDP IP Media Payload

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â&#x20AC;&#x201D;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.

The Basics of Voice over Internet Protocol

H.323 VoIP Model Signaling and Transport Caller E.164 Phone # Audio Codec (G.711, G729, G.723.1) H.225, H.245, RTP, RTCP UDP Port #

IP Address MAC Address 802.3, ATM VPI, VCI Frame Relay DLCI Physical V.35, T1, DS-3

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 localarea 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

Chapter 4: VoIP Using the H.323 Protocol

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

The Basics of Voice over Internet Protocol

data transmission. Figure 4.4 presents the complete set of signaling messages exchanged prior to the eventual streaming of the realtime 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.

H.323 Call Setup Signaling Admission Request Admission Confirm H.323 Gateway

Setup Connect

RAS H.323 Gateway H.225 (Q.931)

Capabilities Exchange Open Logical Channel Open Logical Channel Acknowledge

H.245

Path Resv RTP Stream RTP Stream RTCP Stream

RSVP

Gatekeeper

Media

Figure 4.4 The Complete H.323 Signaling Steps for Admission and Call Setup

Chapter 4: VoIP Using the H.323 Protocol

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. Gatekeeper

Du a

RRQ, RCF

ARQ

ACF

RRQ, RCF H.225Call Set up

Gateway

ACF

H.225Call Set up Response

Gateway

H.245 Call Management Real Time Message Transfer Flow

Figure 4.5 H.323 Call Setup and Transfer Messages through a Gateway and Gatekeeper

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;s edge seeks admission, addressing, and routing information from the central gatekeeper and requests the gatekeeper to pass the callsetup signals to the destination site. Then, the subsequent conversation message packets can be passed directly from one area to another across the IP network.

Gatekeeper 2 Gatekeeper 1 Du a

Gatekeeper 3

Gateway 1

Zone 1

ua M

Gateway 2

Zone 2

Gateway 3

Zone 3

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 58

Chapter 4: VoIP Using the H.323 Protocol

means of acknowledging receipt, RTP is usually employed to supplement the â&#x20AC;&#x153;best-effortâ&#x20AC;? 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.

The Basics of Voice over Internet Protocol

RTP Header

X CC M

PT Ti mestamp

Sequence Number

Synchronization Source Identifier

UDP Header

Source Port

Destinati on Port Checksum

Length Version

IHL

Type of Service

Identification

IP Header

Ti me to Li ve

Total Length

Fl ags Protocol

Fragment Offset Header Checksum

Source Address Destinati on Address Opti ons

Paddi ng

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.

Chapter 4: VoIP Using the H.323 Protocol

20 bytes IP Header

8 bytes

12 bytes

20 to 160 bytes

UDP Header

RTP Header

Voice or Medi a Payload

40 byte Header Compressed to 2 Byte Header Compressed Header

2 to 4 bytes

Voice or Medi a Payload

20 to 160 bytes

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 finetuning the timing of the delivery of the voice signal to make it appear normal to the receiverâ&#x20AC;&#x2122;s ear.

The Basics of Voice over Internet Protocol

Once a connection has been made from endpoint to endpoint using traditional Q.931 ISDNâ&#x20AC;&#x201C;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. Realtime Transfer Protocol Contribution to H.323 Q.931Signaling H.323 Gateway Messages

H.323 Gateway TC P Connection

Messages

Setup Alert

Connect H.245 Address

H.245 Gatekeeper Messages

Open Logical Channel Open Logical Channel Acknowledge

Q.931 Signaling Over TCP

Gatekeeper Messages H.245 Over TCP

Realtime Transfer Protocol Contribution RTP Stream RTP Stream RTP Stream RTCP Stream

RTP Timed Streaming Voice Media Transfer over UDP

Figure 4.9 RTP Added to H.323â&#x20AC;&#x2122;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 62

Chapter 4: VoIP Using the H.323 Protocol

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.

Gatekeeper Dua M

Registration Request Gateway

RCF Registration Confirm

Voice Communication Packets

Address Exchange

WAN Network

RRQ

Gateway

Voice Communication Packets

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.

The Basics of Voice over Internet Protocol

National VoIP

Public Circuit Switched Telephone Network

Gatekeeper

Public and Private Internets

Gateway

Gatekeeper Router

Local VOIP Network

PBX

S tandard Analog and Digital Telephones

Gateway

H.323 Over Local IP and Ethernet Network IP Phones

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.

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.

The Basics of Voice over Internet Protocol

Application Services

SIP Servers

SIP Proxy, Locate, Register, Redirect Processes

SIP SIP SIP

PSTN SIP RT P/UDP

PBX

IP Device w ith SIP Agents

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â&#x20AC;&#x2122;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â&#x20AC;&#x201C; 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

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.

The Basics of Voice over Internet Protocol

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

Calling IP Phone SIP Signaling (TCP)

Invite

Invite Code 100 Try

Code 100 Try Code 180 Ring

Code 180 Ring

Code 200 OK

ACK

Media Transfer UDP and RTP

Called IP Phone

ACK

Media Transfer RTP 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.

Chapter 5: SIP for VoIP Transmission

Gopher Kerb SMTP Telnet FTP SIP

SNMP RPC

UDP

TCP

IP Local Area or Wide Area Net Interface

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 textbased protocol, so it is easy to implement and is well adjusted to the Internet. It is supported by the IETFâ&#x20AC;&#x2122;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â&#x20AC;&#x2122;s requests. These agents exist in IP phones, IP servers, and gateway devices.

The Basics of Voice over Internet Protocol

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.

D MA G E L

D MA GE L

User Agent Server

SIP Servers Proxy Redirect Location Register

User Agent Client

User Agent Server User Agent Client

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: • •

myname@bsu.edu Physical addresses such as 55555555555@182.182.282.182

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

Chapter 5: SIP for VoIP Transmission

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â&#x20AC;&#x2122;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â&#x20AC;&#x2122;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 (myname@earthlink.net) 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.

The Basics of Voice over Internet Protocol

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 â&#x20AC;&#x153;loanedâ&#x20AC;? 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.

Proxy Server

Invite

Redirect Server

Invite Client

Client

IP-Based Network

User Agent User Agent

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

Chapter 5: SIP for VoIP Transmission

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.

Proxy Server

Response Code 200

Client

Redirect Server

Response Code 200 indicating Success

Client

IP-Based Network

User Agent User Agent

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 callsetup Invite to ensure the connection establishment), as the calling parties can not tolerate the delay associated with acknowledgement

The Basics of Voice over Internet Protocol

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.

Proxy Server

ACK

User Agent

Redirect Server

AC K Acknow ledgement

RTP Voice Transfer

User Agent

IP-based Network Client

Client

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

Chapter 5: SIP for VoIP Transmission

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,

The Basics of Voice over Internet Protocol

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. SIP Server

Invite

Calling IP Phone

Invite Code 100 Try

SIP Signaling (TCP )

Code 100 Try Code 180 Ring Code 200 OK

Code 180 Ring Code 200 OK

AC K

Media Transfer UDP and RTP

Called IP Phone

ACK

RTP Stream

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 â&#x20AC;&#x153;Inviteâ&#x20AC;? 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.

Chapter 5: SIP for VoIP Transmission

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.

SIP Servers and Offered Services Register

1. Register “I am Frank Groom ”

Redirect

User Locations

SIP Proxy Server

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

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

2. Invite “I w ant to talk to another User Agent”

IP Devices w ith SIP Agents

4. Relocate “Kevin is now at kgrm @earthlink.com ”

SIP RT P/UDP

Frank’s IP Phone

PBX

Kevin’s IP Phone

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

The Basics of Voice over Internet Protocol

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

Local PSTN

IP Telephone

IP Telephone Enterprise IP Network

Enterprise IP Network

Local Standard PSTN Te le phone

Carrier SIP Service

National IP Network

IP Telephone

Enterprise IP Network

Local PSTN

Standard Te lephone

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

Chapter 5: SIP for VoIP Transmission

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.

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

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x201D; 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â&#x20AC;&#x201D;and thus performance issues.

Chapter 6: Gateways and Gatekeeper Protocols

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

The Basics of Voice over Internet Protocol

• • • • •

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.

Chapter 6: Gateways and Gatekeeper Protocols

MGCP Call Agent

MGCP Messages

IP NETWORK Media Gatway

Media Gatway

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.

The Basics of Voice over Internet Protocol

SS7 Signal

Call Agent

PSTN MGC P Media G ateway

MGCP Call Setup Signaling

IP Network Media G ateway

Voice Messages

Media G ateway

Figure 6.2 Call Agent Signaling to IP or PSTN Networks Figure 6.3 expands on the PSTNâ&#x20AC;&#x2122;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.

Chapter 6: Gateways and Gatekeeper Protocols

Call Agent

SS7 Signaling Network

SS7 Signal

Trunk

Traditional Telephone Dial Link

Media Gateway

MGC P Call Setup Signaling

IP Network Voice Messages

Trunk

Media Gateway

Traditional Telephone Dial Link

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.

The Basics of Voice over Internet Protocol

• • •

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

Chapter 6: Gateways and Gatekeeper Protocols

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â&#x20AC;&#x2122; 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 â&#x20AC;&#x201C; 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 callsetup 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

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;s sequencing, timing, and synchronization information. This results in a real-time stream of the voicecontaining IP packets (termed RTP streams) from the source IP phone to the destination IP phone by means of edge routers at each site.

Call Control Module Call Setup Call Management Du a M

ode

Skinny Protocol Signaling

C IS C OS Y S E T WR O W

C is c o 7 0 0 ER

0 IE S

Real Ti me Protocol Signaling

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

Chapter 6: Gateways and Gatekeeper Protocols

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

H.323 Architecture Media Types Scope of Network

SIP

MGCP

MEGACO Master/ Slave

Peer to Peer

Master/ Slave

Voice, data, Limited Data

Voice, Video Data

Voice

Intranet and Internet

Intranet Only

Medium

Voice, Video

Extensibility

Low

High

Scalability

Medium

High

Low

Deploy Ease

Low

High

Medium

Standardization

ITU

IETF

IETF/ITU

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.

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 93

The Basics of Voice over Internet Protocol

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â&#x20AC;&#x2122;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 FrameRelay 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 FrameRelay 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â&#x20AC;&#x2122;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â&#x20AC;&#x2122;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 FrameRelay 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

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.

Analog Voice Traffic Stream Priority 1

FR Edge S witch

Digital Voice Packets Priority 2

Bursty Data Traffic

Frame Relay Frames to Frame Relay Edge S witch

Enterprise Edge Access Router

Figure 7.1 Enterprise Edge Router Integrating Prioritized Voice and Data Traffic

The process performed by this edge router on the enterpriseâ&#x20AC;&#x2122;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 FrameRelay 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.

The Basics of Voice over Internet Protocol

Voice over Frame Relay Signaling Telephone Dials IP Phone

Du a Mo d e

Dial Mapped to PVC and DLCI

Mi c o

IS C O Y S C TM ES WR O W

Du a Mo d e

Analog Phone

Mi o c

Cisco 7 E 000 IE S R

Convert FR Setup Signal to Dial Signal

FRF.11 Frame Relay Network

C IS C O WR O

SSY TE M S

Cisco70 R E 0IES0

Call Setup and Control Along PVC Frame Relay Call Setup Frame Sent Over PVC

Frame Relay Call Accepted

Telephone Rings

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.

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

Router C IS COY ST EM S WR W O

Cisco70 ER I00 S E

LAN

Frame Relay Network

PBX

LAN

Router C IS COY ST EM S WR W O

Cisco70 ER I00 S E

Router Cisco70 I0S R E 0 E

IS C C OS YT EM S WR W O

LAN

PBX

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-

The Basics of Voice over Internet Protocol

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.

Addressing and Routing All PVCs are connected to One Central Site with Static mapping of E.164 addresses to PVCs IS C O Y T C SM ES WR O

Source PVC E.164 IC C S OY S TM ES OR W W

Csi co70 ER I00 S E

Central Frame Relay Voice Routing Site Destination PVC Site C Csi co70 00

I C C S OY S TM ES OR W W

E R IE S

Csi co70 00 R IE E S

Site A IC C S OY S TM ES OR W W

Csi co70 00 R IE E S

Frame Relay Service PVC PVC

E.164 C IS COY S TES M WR W O

Ci sco70 00 R IE E S

Site D Site B

E.164

Figure 7.4 Central Routing of Frame-Relayâ&#x20AC;&#x201C;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

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

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

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 Total Transport Delay

5 msec 180 msec

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

The Basics of Voice over Internet Protocol

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. FULLY MESHED FR SWITCHED NETWORK Carrying Site-to-Site Voice Traffic Site E

C IS COY S TM ES R W O W

ER I S E

Cisco7000

IS C O Y C STM ES WR O W

R IE S E

Site A

IS C C O WR O

Frame Relay Service

S YE T MS W

i sco700 C 0

R IE S E

Site D

C IS C O WR O

Site B

Cisco 7 000

S YT EM S

Csi co70 R E 0I0 S E

SW SW Frame Relay Network

IS C O Y S C E MS T WR O

Cisco7000 R IE S E

Site C

Static mapping of E.164 address to PVC

Figure 7.5 Voice Traffic over a Fully Meshed Frame-Relay Network Frame Relay is considered the â&#x20AC;&#x153;fastâ&#x20AC;? 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 100

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

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.

101

The Basics of Voice over Internet Protocol

•

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 circuitestablishment 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 5byte header, is the approach most vendors support for their business customers when employing an ATM network. Figure 7.6

102

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

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

AAL Type 5 For Voice Traffic 5 Bytes ATM Header

48 Bytes

Portion of Voice Conversation

48 Bytes of Voice Payload 8 Bytes reserved on the Last Cell of a S tream for AAL-5 Trailer Information

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.

103

The Basics of Voice over Internet Protocol

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 besteffort cell production process.

VOICE CONVERSATION Constant Bit Rate AAL 1 PROCESS

Variable Bit Rate AAL 5 PROCESS

QUALITY OF S ERVIC E REQUIREMENTS

S EGMENT FRAMES INTO CELLS

ATM Cells

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: •

104

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

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

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 preassigned 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 105

The Basics of Voice over Internet Protocol

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 highspeed 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

106

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

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â&#x20AC;&#x201C;based network or a standard analog telephone network. These three approaches for employing ATM to carry voice traffic are portrayed in Figure 7.8. CBR S VCs for Voice Transport

PVC for ATM S ignaling

ATM Network

2. Non-ATM Network

ATM Network CBR S VCs for Voice Transport PBX with ATM Module

3. Non-ATM Network

S VC PVC

Signaling PVC

S VC â&#x20AC;&#x201C; Voice Transmission

PBX with ATM Module

ATM Network

Non-ATM Network

PVC for ATM S ignaling

Figure 7.8 Three Approaches for Voice over ATM

107

The Basics of Voice over Internet Protocol

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.

VOICE OVER ATM IS C C O WR O

IS C C O WR O

SSTWY ME S

T S YM ES

Cisco70 00 R IE E S

C IS O CY T SM ES WR W O

Cisco70 00 I S R E E

Cisco70 R E 0I0 S E Cisco70 00

IS C C OY T E SM S WR W O

I C C O S OR W

R IE E S

IS C C OY T E S MS WR W O

C IS COY ST EM S R W W O

I S R E E

Cisco70 00

SSTY ME S

Cisco70 I00 R E S E

Csc i o7 00

ER IE S

PBX

IS C C OY T E SS M WR W O

C IS COY SE TM S R W O W

Cisco70 00

I S R E E

C IS COY S EM T S WR W O

Cisco70 00 I S R E

PBX

Cisco7 000 ER IE S

IS C C OY T E SS M WR W O

Cisco70 00 I S R E E

I C C S OS YT MS E OR W

i sco7 C R E 00 IE S

ATM PNNI Routing For Switch Updates

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

108

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

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.

PUBLIC AND PRIVATE SIGNALING INTERWORKING Public Network Private Network Q.931 UNI 4.0 Private ATM Network P-NNI

ATM Inter-working Interface

AAL-1 to

Q-S IG

AAL-1

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

Public ATM Network

Private ATM Network

Private Network

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

109

The Basics of Voice over Internet Protocol

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.

AAL-5

ATM Network

AAL - 5 Cell 5 Bytes Header

48 Bytes

Voice

Inter- working and Conversion Function 5 Bytes Header

1 Byte Seq/Synch

AAL - 1 Cell

10.875 msec Conversion plus Buffering Delay 47 Bytes Voice

ATM Network

AAL-1

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.

110

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

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 24hour 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.

111

112

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.

113

The Basics of Voice over Internet Protocol

Company

Price

Service

AT&T

$39.99/mo.

Local and Long Distance

SBC

$29-40/mo.

Local and Long Distance

Availability 100 U.S. mkts 2004 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

$9.95/mo.

Reseller Program announced

i2 Telecom

2004

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

2004

8x8

2004

$20/mo.

Res. and Small Bus., Local, LD

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 114

Chapter 8: Service-Provider VoIP Offerings

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

115

The Basics of Voice over Internet Protocol

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.

116

Chapter 8: Service-Provider VoIP Offerings

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 highspeed Internet connections. AT&T’s services will also offer residence consumers advanced callmanagement 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 longdistance 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 longdistance calling in New Jersey at $39.99 per month with a sixmonth 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.

117

The Basics of Voice over Internet Protocol

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: •

118

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

Chapter 8: Service-Provider VoIP Offerings

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 voicemail, 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 119

The Basics of Voice over Internet Protocol

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 circuitoriented 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).

120

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. 121

The Basics of Voice over Internet Protocol

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.

122

Chapter 9: Strategies for Vendors, Regulators, and Customers

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 metropolitanarea 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 localloop 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 longdistance service, Internet access, IP services, as well as to the local

123

The Basics of Voice over Internet Protocol

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 longdistance 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 longdistance carrierâ&#x20AC;&#x2122;s future strategies, given that they have discarded their cable facilities and, at least in AT&Tâ&#x20AC;&#x2122;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â&#x20AC;&#x201C;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 localloop 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

124

Chapter 9: Strategies for Vendors, Regulators, and Customers

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â&#x20AC;&#x201C;based facilities and begin offering competitive VoIP local and long-distance services.

125

The Basics of Voice over Internet Protocol

3. Begin investing in fiber to the neighborhoods to replace the majority of the length of the local loop, leaving only the â&#x20AC;&#x153;last mileâ&#x20AC;? 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.

126

Chapter 9: Strategies for Vendors, Regulators, and Customers

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â&#x20AC;&#x201C;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

127

The Basics of Voice over Internet Protocol

phones ($100 â&#x20AC;&#x201C; $300) and IP servers ($3,000 â&#x20AC;&#x201C; $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â&#x20AC;&#x201C;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.

128

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â&#x20AC;&#x2122;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.

129

130

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

131

The Basics of Voice over Internet Protocol

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

132

Appendix: VoIP Terminals and Other Equipment

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

133

The Basics of Voice over Internet Protocol

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

134

Appendix: VoIP Terminals and Other Equipment

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

135

The Basics of Voice over Internet Protocol

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

136

Appendix: VoIP Terminals and Other Equipment

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

137

The Basics of Voice over Internet Protocol

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

138

Appendix: VoIP Terminals and Other Equipment

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

139

The Basics of Voice over Internet Protocol

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

Catalyst 4000 10/100BaseT Switching Module

48 ports per module

$5,995

Catalyst 4000 Access Gateway Module

192 user ports

$7,495

Catalyst 4000 AGM 8-Port RJ21 FXS Module

8 ports per module

$1,995

Catalyst 4006 Chassis

6 slots

$9,995

Catalyst 6000 10/100 BaseT Switching Module

48 ports per module

$12,995

Catalyst 6000 FXS Analog Station Interface Module

24 ports per module

$9,995

Catalyst 6000 Voice T1 + Services Module

8 ports per module

$19,995

Centralized Management & Monitoring

Per 100 IP Phones

$4,000

Cisco 7960 Expansion Module

1/phone/ exec. assist.

$395

Cisco CallManager 3.1 Software for the MCS

1 per server

$5,995

140

List Price

Appendix: VoIP Terminals and Other Equipment Description

Capacity

List Price

Cisco Digital PBX Adapter (DPA) 7630

Supports 24 digital lines

Cisco IP Phone 7960, Manager Set

1 per employee

Cisco IP Softphone CD/100 licenses

100 users

Cisco VG200 Voice Gateway Module

1 per office

$995

Dual-Port 48 Channel T1 Voice Network Module

2 T1 ports per VG200

$9,800

MCS-7835 Server

For 2,500 IP Phones

$11,595

$6,995 $645 $10,500

Avaya Gateway and Module Component Costs Description

Capacity

List Price

4612 IP Telephone

1 per employee

$440

4624 IP Telephone

1 per executive assistant

$769

Avaya VisAbility Software

1,500 users

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 with G.729

$9,000

$55,000

141

The Basics of Voice over Internet Protocol Description

Capacity

MultiVantage Software

1 per media server

$25,000

S8700 Media Server

1 per system

$20,000

142

List Price

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.

143

The Basics of Voice over Internet Protocol

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.

144

Glossary AAL–[x] ARC ARJ ARQ ASCII ATM B–ICI CBR CCM CIR CLEC CO DHCP DLCI DNS DSL DSLAM DS–[x] ETSI FCC GIF HIPCS HTML HTTP IETF ILEC IP ISDN ISP ITU IWF IXC JPEG LAN

ATM adaptation layer–x admission confirmation admission rejection admission-to-the-network requests American Standard Code for Information Interchange asynchronous transfer mode broadband inter-carrier interchange constant bit rate call control module committed information rate competitive local-exchange carrier central office dynamic host configuration protocol data link control indicator domain name server digital subscriber line [also xDSL] digital subscriber line access multiplexer (or module) digital signal [level x] European Telecommunications Standards Institute Federal Communications Commission graphics interface format hosted IP communication service hypertext markup language hypertext transfer protocol Internet Engineering Task Force incumbent local-exchange carrier Internet protocol integrated services digital network Internet service provider International Telecommunication Union interworking function interexchange carrier Joint Photographic Experts Group local-area network

145

The Basics of Voice over Internet Protocol

LANE LATA LDAP LNP MAC MEGACO MGCP MPLS NAT NIC OSPF PBX PCM Pâ&#x20AC;&#x201C;NNI PoP PPP PSC PSTN PVC QoS RBOC RCF RRQ RTSP RTCP RTP SAP SDP SIP SONET SS7 TCP TIPHON UDP UNEâ&#x20AC;&#x201C;P URL VBR VoIP VPN

146

local-area network emulation local access and transport area lightweight directory access protocol local number portability media access control media gateway control media gateway control protocol multiprotocol label switching network address translation network interface card open shortest path first private branch exchange pulse code modulation private network node interface point of presence point-to-point protocol Public Service Commission public switched telephone network permanent virtual circuit quality of service regional Bell operating company registration confirmation registration request real-time streaming protocol real-time conferencing protocol real-time transport protocol session announcement protocol session description protocol session initiation protocol synchronous optical network signaling system 7 transmission control protocol Telecommunications and Internet Protocol Harmonization over Networks user datagram protocol Unbundled Network Element Platform universal resource locator variable bit rate voice over IP virtual private network

Glossary

WAN WRED

wide-area network weighted random early detection

147

148