Franklin D. .Ohrtman, Jr.
`
`Softswitch
`Architecture for VoIP
`
`San Juan Seoul Singapore Sydney Toronto
`
`McGraw-Hill
`
`NewYork Chicago San Francisco Lisbon
`London Madrid Mexico City Milan New Delhi
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 1
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 1
`
`

`

`
`
` The MCGmW'Hm Companies
`
`Cataloging-in-Publication Data is on file with the Library of Congress.
`
`Copyright © 2003 by The McGraW-Hfll Companies, Inc. All rights reserved.
`Printed in the United States ofAmerica. Except as permitted under the United
`States Copyright Act of 1976. no part of this publication may be reproduced or
`distributed in any form or by any means, or stored in a data base or retrieval
`system, Without the prior written permission of the publisher.
`234567890 DOC/DOC 0987654
`
`ISBN 0-07—140977-7
`
`The sponsoring editor for this book 3153 Marjorie Spencer and the production supervisor
`was Pamela A. Pelton. It was set in . 13;; Century Schoolbook by MacAIlister Publishing
`Services, LLC.
`
`Printed and bound by RR Donnie.
`
`MCGTaW‘iHfll books are available a: 22:21 quantity discounts to use as premiums and
`sales promotions, or for use in commits raining programs. For more information,
`please write to the Director ofSpecs; Sales. Professional Publishing, McGraW-Hill,
`Two Penn Plaza, New York, NY 10112296. Or contact your local bookstore.
`
`
`
`Information contained in this 525. :as been obtained by The McGraw-Hill
`Companies, Inc. (“MoGraw-Hi‘ 251': sources believed to be reliable. However,
`neither McGraerill nor its 22:15 gmrantee the accuracy or completeness of
`any information published 5225: 1.3 neither McGraW-Hill nor its authors
`
`shall be responsible for any 2:15 :r—izsions, or damages arising out of use of
`this information. This work ‘2 t5 '
`' 12:: with the understanding that McGraW—
`
`Hill and its authors are supp;
`_ mafion but are not attempting to render
`engineering or other pror 111 Emcee. If such services are required, the
`assistance of an appropriate 212551.123 should be sought.
`
`
`
`I! This book is printed on ramifi— 1:33-2:22 paper containing a minimum of
`‘3 50 percent recycled tie—1:22.:— its:
`
`AT&T Exhibit 1026
`AT&T V. VolP, IPR 2017-01382
`Page 2
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 2
`
`

`

`,4. N a
`,
`n
`
`vvwas“'
`
`Voice over
`
`4A?m;mga:»Xewww
`
`Internet
`
`Protocol
`
`
`
`
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 3
`
`

`

`Chapter 4
`
`What Is VoIP?
`
`Softswitch is a product driven by the need to incorporate intelligence into
`Voice over Internet Protocol (VoIP) networks, interface IP networks, and the
`Public Switched Telephone Network (PSTN) and to coordinate features across
`networks. As outlined in the previous chapter, the first applications of
`softswitch were the gatekeepers (aka gateway controllers) that were incor-
`porated in networks of VoIP gateways. In order to better understand a
`softswitched network, it is necessary to dissect VoIP down to the protocol
`level. Many volumes on VoIP can be found on the book market, and this book
`will not attempt to cover it in detail. The importance ofVoIP protocols relative
`to softswitch is that they are the building blocks that make VoIP possible.
`
`
`
`In November 1988, Republic Telcom (yes, one “e”) of Beulder, Colorado,
`received patent number 4,782,485 for a “Multiplexed Digital Packet Tele-
`phone System.” The plaque from the Patent and Trademark Office describes
`it as follows: “A method for communicating speech signals from a first loca-
`tion to a second location over a digital communication medium comprising
`the steps of: providing a speech signal of predetermined bandwidth in ana-
`log signal format at said first location; periodically sampling said speech sig—
`nal at a predetermined sampling rate to provide a succession of analog
`signal samples; representing said analog signal samples in a digital format
`thereby providing a succession of binary digital samples; dividing said suc—
`cession of binary digital samples into groups of binary digital samples
`arranged in a temporal sequence; transforming at least two of said groups of
`binary digital samples into corresponding frames of digital compression.”
`Republic and its acquiring company, Netrix Corporation, applied this
`voice over data technology to the data technologies of the times (X25 and
`Frame Relay) until 1998 when Netrix and other competitors introduced
`VoIP onto their existing voice over data gateways. Although attempts at
`internet telephony had been done from a software—only perspective, com-
`mercial applications were limited to using voice over data gateways that
`could interface the PSTN to data networks. Voice over data applications
`were popular in enterprise networks with offices spread across the globe
`(eliminated international interoffice long-distance bills), offices Where no
`PSTN existed (installations for mining and oil companies), and for long—
`distance bypasses (legitimate and illegitimate).
`
`Origins
`
`AT&T Exhibit 1026
`AT&T V. VolP, IPR 2017-01382
`Page 4
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 4
`
`

`

`Voice over Internet Protocol
`
`The popularity and applications of VolP continued to grow VoIP
`accounted for 6 percent of all international long—distance traffic in 2001.1
`Six percent may not seem like an exciting sum, but given a mere 3 years
`from the introduction of a technology to capturing 6 percent of a trillion dol-
`lar, IOU—year—old industry, it is clear that VoIP will continue to capture more
`market share.
`
`wwaeleGeographycom.
`
`enable noise suppression and the compression of voice streams.
`Compression algorithms include G723, G728, and G729.
`Following compression, voice must be packetized and VoIP protocols
`added. Some storage of data occurs during the process of collecting voice
`data, since the transmitter must wait for a certain amount of voice data to
`be collected before it is combined to form a packet and transmitted via the
`network. Protocols are added to the packet to facilitate its transmission
`across the network. For example, each packet will need to contain the
`address of its destination, a sequencing number in case the packets do not
`arrive in the proper order, and additional data for error checking. Because
`IP is a protocol designed to interconnect networks of varying kinds, sub-
`stantially more processing is required than in smaller networks. The net-
`work addressing system can often be very complex, requiring a process of
`
`How Does VoIP Work?
`
`Softswitch is increasingly considered to be almost synonymous with VoIP.
`However, it also works with Time Division Multiplexing (TDM) and Asyn-
`chronous Transfer Mode (ATM) networks. The first process in an IP voice
`system is the digitization of the speaker’s voice. The next step (and the first
`step when the user is on a handset connected to a gateway using a digital
`PSTN connection) is typically the suppression of unwanted signals and
`compression of the voice signal. This has two stages. First, the system
`examines the recently digitized information to determine if it contains voice
`
`signal or only ambient noise and discards any packets that do not contain
`speech. Secondly, complex algorithms are employed to reduce the amount of
`information that must be sent to the other party. Sophisticated codecs
`
`encapsulating one packet inside another and, and as data moves along,
`repackaging, readdressing, and reassembh'ng the data.
`
`1“TeleGeography 20027Global Trafiic Statistics and Commentary,” TbleGeogr-aphy, 2001,
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 5
`
`

`

`Chapter 4
`
`In IP networks, a percentage of the packets can be lost or delayed, espe-
`cially in periods of congestion. Also, some packets are discarded due to
`errors that occurred during transmission. Lost, delayed, and damaged pack-
`ets result in a substantial deterioration of voice quality. In conventional
`
`error-correction techniques used in other protocols, incoming blocks of data
`containing errors are discarded, and the receiving computer requests the
`retransmission of the packet; thus, the message that is finally delivered to
`the user is exactly the same as the message that originated. As VoIP sys-
`tems are time—sensitive and cannot wait for retransmission, more sophisti-
`
`cated error detection and correction systems are used to create sound to fill
`in the gaps. This process stores a portion of the incoming speaker’s voice
`and then, using a complex algorithm to approximate the contents of the
`missing packets, new sound information is created to enhance the commu-
`nication. Thus, the sound heard by the receiver is not exactly the sound
`transmitted, but rather portions of it have been created by the system to
`enhance the delivered sound?
`
`The previous description details the movement of voice over the IP
`medium. The rest of the chapter will describe the building blocks of a VoIP
`network: its protocols.
`
`When each packet arrives at the destination computer, its sequencing is
`checked to place the packets in the proper order. A decompression algorithm
`is used to restore the data to its original form, and clock synchronization
`and delay-handling techniques are used to ensure proper spacing. Because
`data packets are transported via the network by a variety of routes, they do
`not arrive at their destination in order. To correct this, incoming packets are
`stored for a time in a jitter buffer to wait for late—arriving packets. The
`length of time in which data are held in the jitter buffer varies depending
`on the characteristics of the network.
`
`
`
`Protocols Related to VoIP
`
`The softswitch revolution was made possible by the emergence of voice over
`data, more specifically, VoIP. It should be noted here that softswitch solu—
`tions use TDM and ATM. However, the consensus in the industry is that the
`future is an IP network ultimately dictating a VoIP solution. Before outlin-
`ing softsvvitch solutions, it will first be necessary to understand VoIP. VoIP
`
`2Report to Congress on Universal Service, CC Docket No. 96-45, White Paper on IP Voice Ser-
`vices, March 18,1998 {wwvonorg/docs/whitepappdf).
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 6
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 6
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`Voice over Internet Protocol
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`is best understood as a collection of the protocols that make up its mechan-
`ics. Those protocols are loosely analogous to the PSTN that is broken down
`into three categories: access, switching, and transport. Simply put, three cat-
`egories of protocols are relevant to VoIP: signaling, routing, and transport.
`Signaling (roughly analogous to the switching function described in the
`last two chapters) protocols (H.323 and Session Initiation Protocol [SIPD set
`up the route for the media stream or conversation. Gateway control proto—
`cols such as the Media Gateway Control Protocol (MGCP) and MEGACO
`(also signaling protocols) establish control and status in media and signal—
`ing gateways.
`Routing (using the User Datagram Protocol [UDP] and Transmission
`Control Protocol [TCP]) and transporting (ReaLTime Transport Protocol
`[RTPD the media stream (conversation) once the route of the media stream
`has been established are the fimctions of routing and transport protocols.
`Routing protocols such as UDP and TCP could be compared to the “switch-
`ing” function described in Chapter 2, “The Public Switched Telephone Net-
`work (PSTN),” and Chapter 3, “Soitswitch Architecture or ‘It’s the
`Architecture, Stupid! ”’
`RTP woald be analogous to the “transpo ” function outlined in earlier
`chapters describing the PSTN and softswitch architectures. The signaling
`and routing functions establish what route the media stream will take. The
`routing protocols deliver the bits, that is, the conversation.
`
`
`
`The process of setting up a VoIP call is roughly similar to that of a circuit-
`switched call made on the PSTN. A media gateway must be loaded with the
`parameters to allow proper media encoding and the use of telephony fea-
`tures. Inside the media gateway is an intelligent entity known as an end—
`point. When the calling and called parties agree on how to communicate
`and the signaling criteria is established, the media stream over which the
`packetized voice conversation will flow is established. Signaling establishes
`the virtual circuit over the network for that media stream. Signaling is
`independent of the media flow. It determines the type of media to be used
`in a call. Signaling is concurrent throughout the call. Two types of signaling
`are currently popular in VoIP: H.323 and 8113.3
`
`Signaling Protocols
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`3Donskalis, Bill. IP Telephony The Integration ofRobust VoIP Services. New York: Prentice Hall,
`
`2000.
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 7
`
`

`

`Signaling (H.323, SIP)
`
`Chapter 4
`
`Signaling and
`transport protocols
`used in VolP
`
`Transport
`
`Telephone
`
`I
`
`Telephone
`
`
`
`H.323 H.323 is the International Telecommunication Union—Telecom-
`munications Standardization Sector (ITU—T) recommendation for packet—
`based multimedia communication. H.323 was developed before the
`emergence of VoIP. As it was not specifically designed for VoIP, it has faced
`a good deal of competition from a competing protocol, SIP, which was
`designed specifically for VoIP. However, it has enjoyed a first-mover advan-
`tage and a considerably installed base of H.323 VoIP networks now exists.
`H.323 is comprised of a number of subprotocols. It uses protocol H2250
`for registration, admission, status, call signaling, and control. It also uses pro-
`tocol H.245 for media description and control, terminal capability exchange,
`and general control of the logical channel carrying the media stream(s).
`Other protocols make up the complete H.323 specification, which presents a
`protocol stack for H.323 signaling and media transport. H.323 also defines a
`set of call control, channel setup and codec specifications for transmitting
`real-time video and voice over networks that don’t offer guaranteed service or
`quality of service (Q08). AS a transport, H.323 uses RTP, an Internet Engi-
`neering Task Force (IETF) standard designed to handle the requirements of
`streaming real-time audio and video via the Internet} H.323 was the first
`VoIP protocol for interoperability among the early VOIP gateway/gatekeeper
`vendors. Unfortunately, the promise of interoperability between diverse ven—
`dors platforms did not materialize with the adoption of H.323. Given the
`gravity ofthis protocol, it will be covered in a separate following chapter.
`
`Figure 4-1 details the relationship between signaling and media flow.
`This relationship between transport and signaling is very similar to the
`PSTN in that Signaling System 7 (SS?) is out-of—channel signaling, such as
`that used in VoIP.
`
`
`
`AT&T Exhibit 1026
`AT&T V. VolP, IPR 2017-01382
`Page 8
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 8
`
`

`

`Voice over Internet Protocol
`
`The H.323 standard is a cornerstone technology for the transmission of
`real-time audio, video, and data communications over packet-based net—
`works. It specifies the components, protocols, and procedures providing
`multimedia communication over packet—based networks. Packet-based net—
`works include IP—based (including the Internet) or Internet packet exchange
`(IPX)-based local area networks (LANs), enterprise networks (ENS), metro"
`politon area networks (We), and wide area networks (WANs). H.323 can
`be applied in a variety of mechanisms: audio only (IP telephony); audio and
`video (videotelephony); audio and data; and audio, video, and data. H.323
`can also be applied to multipoint—multimedia communications. H.323 pro-
`vides myriad services and therefore can be applied in a wide variety of
`areas: consumer, business, and entertainment applications.
`
`Interworking with Other Multimedia Networks The H.323 standard
`specifies four kinds of components, which, when networked together, provide
`the point-to-point and point-to—Inultipoint multimedia communication ser-
`vices: terminals, gateways, gatekeepers, and mnltipoint control units (MCUs).
`
`H.323 network.
`
`Terminals Used for real—time bidirectional multimedia communications, an
`H.323 terminal can either be a personal computer (PC) or a stand-alone
`device running an H.323 and the multimedia applications. It supports
`audio communications and can optionally support video or data communi-
`cations. Because the basic service provided by an H.323 terminal is audio
`communications, an H.323 terminal plays a key role in IP—telephony ser-
`vices. The primary goal of H.323 is to interwork with other multimedia ter—
`minals. H.323 terminals are compatible with H.324 terminals on SCN and
`wireless networks, H.310 terminals on Broadband Integrated Services Dig-
`ital Network (B-ISDN), H.320 terminals on ISDN, H.321 terminals on
`B-ISDN, and H.322 terminals on guaranteed QoS LANs. H.323 terminals
`may be used in multipoint conferences.
`
`Gateways A gateway connects two dissimilar networks. An H.323 gateway
`provides connectivity between an H.323 network and a non-H.323 network.
`For example, a gateway can connect and provide communication between
`an H.323 terminal and TDM networks This connectivity of dissimilar net-
`works is achieved by translating protocols for call setup and release, con-
`verting media formats between difierent networks, and transferring
`information between the networks connected by the gateway. A gateway is
`not required, however, for communication between two terminals on an
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 9
`
`

`

`
`
`Chapter 4
`
`Gatekeepers A gatekeeper can be considered the brain of the H.323 net—
`work. It is the focal point for all calls within the H.323 network. Although
`they are not required, gatekeepers provide important services such as
`addressing, authorization, and authentication of terminals and gateways,
`bandwidth management, accounting, billing, and charging. Gatekeepers
`may also provide call-routing services.
`
`Multipoint Control Units {MCUs) MCUs provide support for conferences of
`three or more H.323 terminals. All terminals participating in the confer—
`ence establish a connection with the MCU. The MCU manages conference
`resources, negotiates between terminals for the purpose ofdetermining the
`audio or video coder! decoder (codec) to use, and may handle the media
`stream. The gatekeepers, gateways, and MCUs are logically separate com-
`ponents of the H.323 standard but can be implemented as a single physi-
`cal device.
`
`
`
`H.323 Zone An H.323 zone is a collection of all terminals, gateways, and
`MCUs managed by a single gatekeeper. A zone includes at least one ter-
`minal and may include gateways or MCUs. A zone has only one gatekeeper.
`A zone may be independent of network topology and may be comprised of
`multiple network segments that are connected using routers or other
`devices.
`Additional protocols specified by H.323 are listed in the following sec—
`tions. H.323 is independent of the packet network and the transport proto—
`cols over which it runs and does not specify them. They are audio codecs;
`video codecs; H.225 registration, admission, and status (RAS); H.225 call
`signaling; H.245 control signaling; RTP; and the Real-Slim Control Proto-
`col (RTCP).
`
`Audio Codec An audio codec encodes the audio signal from the microphone
`for transmission on the transmitting H.323 terminal and decodes the
`received audio code that is sent to the speaker on the receiving H.323 ter-
`minal. Because audio is the minimum service provided by the H.323 stan-
`dard, all H.323 terminals must have at least one audio codec support, as
`specified in the ITU-T G711 recommendation (audio coding at 64 Kbps).
`Additional audio codec recommendations such as G722 (64, 56, and 48
`Kbps), G.723.1 (5.3 and 6.3 Kbps), G.728 (16 Hops), and G729 (8 Kbps) may
`also be supported.
`
`Video Codec Avideo codec encodes video from the camera for transmission
`on the transmitting H.323 terminal and decodes the received video code
`
`AT&T Exhibit 1026
`AT&T V. VolP, IPR 2017-01382
`Page 10
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 10
`
`

`

`Voice over Internet Protocol
`
`that is sent to the video display on the receiving H.323 terminal. Because
`H.323 specifies the support of video as optional, the support of video codecs
`is optional as well. However, any H.323 terminal providing video commu-
`nications must support video encoding and decoding as specified in the
`ITU—T H.261 recommendation.
`
`H.225 Registration, Admission, and Status lRAS} RAS is the protocol between
`endpoints (terminals and gateways) and gatekeepers. RAS is used to per—
`form registration, admission control, bandwidth changes, and status, and
`to disengage procedures between endpoints and gatekeepers. An RAS chan-
`nel is used to exchange RAS messages. This signaling channel is opened
`between an endpoint and a gatekeeper prior to the establishment of any
`other channels.
`
`and video.
`
`Real-Time Transport Protocol {RTP} and H.323 RTP, a transport protocol, pro-
`vides end-to-end delivery services of real—time audio and video. Whereas
`H.323 is used to transport data over lP—based networks, RTP is typically
`used to transport data via the UDP. RTP, together with UDP, provides
`transport-protocol functionality. RTP provides payload—type identification,
`sequence numbering, timestamping, and delivery monitoring. UDP pro—
`vides multiplexing and checksum services. RTP can also he used with other
`transport protocols.
`
`H.225 Call Signaling The H.225 call signaling is used to establish a con—
`nection between two H.323 endpoints. This is achieved by exchanging
`H.225 protocol messages on the call—signaling channel, which is opened
`between two H.323 endpoints or between an endpoint and the gatekeeper:
`
`H.245 Control Signaling H.245 control signaling is used to exchange end-
`to-end control messages governing the operation of the H.323 endpoint.
`These control messages carry information related to the following: capa-
`bilities exchange, the opening and closing of logical channels used to carry
`media streams, flow-control messages, general commands, and indications.
`
`Real-Time Transport Control Protocol [RTCP] and H.323 RTCP is the coun—
`terpart of RTP that provides control services. The primary function of RTCP
`is to provide feedback on the quality of the data distribution. Other RTCP
`functions include carrying a transport-level identifier for an RTP source,
`called a canonical name, which is used by receivers to synchronize audio
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 11
`
`

`

`Chapter 4
`
`SIP SIP is a text-based signaling protocol used for creating and control—
`ling multimedia sessions with two or more participants. It is a client-server
`protocol transported over TCP. SIP can interwork with gateways that pro-
`vide signaling protocols and media translations across dissimilar network
`segments such as PSTN to IP networks. SIP uses text—based messages,
`much like HTTP. SIP addressing is built around either a telephone num-
`ber or a web host name. In the case of a web host name, the SIP address is
`based on a uniform resource locator (URL). The URL is translated into an
`IP address through a domain name server {DNS). SIP also negotiates the
`features and capabilities of the session at the time the session is estab—
`lished.5 SIP plays such a pivotal role in the evolution ofVoIP and softswitch-
`ing that it must be covered in the separate, following chapter.
`
`Gateway Control Protocols The most immediate attraction to VoIP is
`to save money on long—distance transport. To date, it has been impractical
`to route VoIP “desktop to desktop,” meaning interworking between PSTN
`and IP networks must be facilitated. This is done with a gateway. The two
`most applied gateways are the media gateway and the signaling gateway.
`Media gateways interconnect dissimilar networks. In this case, they con-
`nect the PSTN to IP networks. To do this successfully, they must interme-
`diate both signaling and transport between the two dissimilar networks
`(PSTN and 1?). Media gateways coordinate call control and status. Gate—
`way control protocols are signaling protocols.
`
`
`
`MGCP MGCP is the protocol used to intermediate the Media Gateway
`Controller (MGC, also known as a call agent) and the media gateway.
`MGCP was developed by the IETF and details the commands and para-
`meters that are passed between the MGC and the telephony gateway to be
`controlled.
`MGCP assumes a call control architecture where the call control intelli—
`gence is outside the gateways and is handled by external call control ele-
`ments. The MGCP assumes that these call control elements, or call agents,
`will synchronize with each other to send coherent commands to the gate-
`ways under their control. MGCP is a master/slave protocol, where the gate-
`ways are expected to execute commands sent by the call agents.
`The purpose of MGCP is to send commands from the call agent to a
`media gateway (see Chapter 3 for descriptions of media gateways). MGCP
`defines both endpoints and connections. Endpoints are sources or sinks of
`
`
`
`AT&T Exhibit 1026
`AT&T V. VoIP, IPR 2017-01382
`Page 12
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 12
`
`

`

`F
`
`Voice over Internet Protocol
`
`data and can be either physical (such as an interface terminating a digital
`trunk or analog line) or virtual (such as a designated audio source). An
`example of a virtual endpoint is an audio source in an audio—content server.
`The creation of physical endpoints requires hardware installation, while
`the creation of virtual endpoints can be done by software. Endpoint identi—
`fiers have two components, the domain name of the gateway that is man-
`aging the endpoint, and a local name within that gateway. Examples of
`physical endpoints include interfaces on gateways that terminate a trunk
`connected to a PSTN switch (Class 5 or Class 4) or an analog Plain Old Tele-
`phone Service (POTS) connection to a phone, key system, PBX, and so on.
`MGCP sends commands from the call agent to a media gateway. MGCP
`
`defines both endpoints and connections.
`Connections can be either point to point or multipoint in nature. Further,
`connections are grouped into calls, where one or more connections can
`belong to one call. A point-to—point connection is an association between two
`endpoints with the purpose of transmitting data between these endpoints.
`Once this association is established for both endpoints, a data transfer
`between these endpoints can take place. A multipoint connection is estab-
`lished by connecting the endpoint to a multipoint session. For point-to-point
`connections, the endpoints of a connection could be in separate gateways or
`in the same gateway.
`The connections and calls are established by the actions of one or more
`call agents. The information communicated between call agents and end—
`points is either events or signals. An example of an event would be a tele-
`phone going offhook, while a signal may be the application of a dial tone to
`an endpoint. These events and signals are grouped into what are called
`packages, which are supported by a particular type of endpoint. One pack-
`age may support events and signals for an analog line, while another pack-
`age may support a group of events and signals for video lines.
`As long as media gateways are interfacing with analog or PSTN connec—
`tions to IP networks, MGCP will be the controlling protocol. MGCP will con—
`tinue to be an integral element in any softswitch architectures Figure 4—2
`details the function of MGCP in softswitch architecture and Table 4—1 out-
`lines the signaling protocols and their softswitch components.
`
`Protocol, October 1999.
`
`
`
`“Internet Engineering Task Force. Request For Comments (RFC) 2705, Media Gateway Control
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 13
`
`

`

`Figure 4-2
`The relationship
`between signaling
`protocols and
`softswitch
`architecture
`
`components
`
`Table 4-1
`
`Signaling protocols
`and associated
`softswitch
`
`components
`
`Signaling Gateway
`
`Softswitch
`
`Media Gateway
`
`Media gateway—softswitch
`
`Media gateway—media gateway
`
`Media gateway—sottswitch
`
`H.323
`
`BICC
`
`MGCP
`
`Softswitch—SS'Y network
`
`ISUP, TCAP
`
`Softswitch or application server
`
`SIP
`
`Source: Internet Telephony
`
`
`
`BICC Bearer Independent Call Control (BICC) is a newer protocol used
`for media-gateway-to-Inedia-gateway communications. It provides a means
`of supporting narrowband ISDN services across a broadband backbone net-
`work Without impacting the interfaces to the existing N—ISDN network and
`end—to—end services. The BICC call control signaling protocol is based on
`N—ISUP signaling.7
`
`Chapter 4
`
`Featurei'Application Server
`
`7Ratta, Greg. “Bearer Independent Call Control and its application of H.248 in public net-
`works.” ITU—T IP/MediaComm Workshop 2004. WWW.itu.inflitudoc/itu—flcom13/ipexpert/
`ipmedia!71396.html. April 26, 2001, pg. 3.
`
`AT&T Exhibit 1026
`AT&T v. VolP, IPR 2017-01382
`Page 14
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 14
`
`

`

`Voice over Internet Protocol
`
`In order for IP telephony networks to interop-
`SS7-Related Protocols
`erate with the PSTN, they must interface with SS7. Softswitch solutions
`must include ISBN User Part (ISUP) and Transaction Capabilities Appli-
`cation Part (TCAP). ISUP, defined by ITU—T Q.761 and Q.764, is the call
`control part of the SS7b protocol. ISUP is an SS7 protocol for signaling the
`parameters and procedures to set up and tear down circuit-switched voice
`calls between a soitswitchfsignaling gateway and an STP. ISUP determines
`the procedures for call setup and teardown on the SS7 network.B
`TCAP is a peer protocol to ISUP in the SS7 protocol hierarchy for end-to-
`end signaling not associated with call setup or specific trunks in the PSTN
`network. Some of its main uses are toll-free 800 number translations for
`routing across the network and local number portability (LNP). It also pro-
`vides the interface between databases and SCPs.9 TCAP provides services
`to any number of application parts. Common application parts include the
`Intelligent Network Application Part (INA?) and the Mobile Application
`Part (MAP).10 This book will address the interworkings of SS7 and VoIP net-
`works in greater detail in a following chapter.
`
`10Collins1 Michael. Carrier Grade Voice Over IP. New York: McGraw-Hill, 2001. pg. 311.
`
`
`SNewton, Harry. Newton’s Telecom Dictionary, 16th edition. New York: 0MP Books. pg. 486.
`gDouskalis, pg. 9.
`
`Routing Protocols
`
`VolP is routed over an IP network via routers. In order to deliver the best
`QoS, voice packets must be given priority over data packets. That means
`communicating to routers which packets have what priority. Router opera—
`tions involve several processes. First, the router creates a routing table to
`gather information from other routers about the optimum path for each
`packet. This table may be static in that it is constructed by the router
`according to the current topology and conditions. Dynamic routing is con«
`sidered a better technique as it adapts to changing network conditions. The
`router uses a metric of the shortest distance between two endpoints to help
`determine the optimum path. The renter determines the least cost (most
`efficient) path from the origin to the destination.
`Two algorithms are used to determine the least cost route. They are dis—
`tance vector and link state. Protocols that make use of these algorithms are
`called Interior Gateway Protocols (IGPs). The Routing Information Protocol
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01382
`Page 15
`
`

`

`Chapter 4
`
`(RIP) is an 1GP based on the distance vector algorithm and the Open Short-
`est Path First (OSPF) protocol is an IGP based on the link state algorithm.
`Where one network needs to communicate with another, it uses an Exterior
`Gateway Protocol (EGP). One example of an EGP is the Border Gateway
`Protocol (BGP).
`
`Routing Information Protocol (RIP) RIP is a distance vector protocol
`that uses a hop count (the number of routers it passes through on its route
`to its destination) as its metric. RIP is widely used for routing traffic on the
`Intemet and is an IGP, which means that it performs routing within a sin—
`gle autonomous system. EGPs, such as BGP, perform routing between dif-
`ferent autonomous systems. RIP itself evolved as an Internet routing
`protocol, and other protocol suites use modified versions of RIP.
`
`
`
`Open Shortest Path First (OSPF) Protocol OSPF is a routing proto-
`col developed for IP networks by the 1GP Working Group of the IETF. The
`Working Group was formed in 1988 to design an IGP based on the Short-
`est Path First (SPF) algorithm for use on the Internet. Similar to the Inte-
`rior Gateway Routing Protocol (IGRP), OSPF was created because in the
`mid-1980s RIP was increasingly incapable of serving large, heterogeneous
`internetworks.
`OSP