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

`

` Deiatnileee
`
`Cataloging-in-Publication Data is on file with the Library of Congress.
`
`Copyright © 2003 by The McGraw-Hill Companies,Inc. All rights reserved.
`Printed in the United States ofAmerica. Except as permitted under the United
`States Copyright Act of 1976, no part ofthis publication may be reproduced or
`distributed in any form or by any Means, or stored in a data base orretrieval
`system, without the prior written permission of the publisher.
`234567890 DOCMOC 0987654
`
`ISBN 0-07-140977-7
`The sponsoring editorfor this book was Marjorie Spencer and theproductionsupervisor
`was Pamela A. Pelton. It was set in New Century Schoolbook by MacAllister Publishing
`Services, LLC.
`Printed and bound by RR Donnelley.
`
`McGraw-Hill books are available at special quantity discounts to use as premiums and
`sales promotions,or for use in corperste training programs. For more information,
`please write to the Director ofSpecial Seles, Professional Publishing, McGraw-Hill,
`Two Penn Plaza, New York, NY 10121-2298. Or contact your local bookstore.
`
`
`Information contained in this war& has been obtained by The McGraw-Hill
`Companies,Inc. (“McGraw-Hill”) Sam sources believed to be reliable. However,
`
`neither McGraw-Hill nor its aathers suarantee the accuracy or completeness of
`
`any information published b= 4 neither McGraw-Hill nor its authors
`shall be responsible for any === =issions, or damages arising out of use of
`
`this information. This work is paltitsed with the understanding that McGraw-
`
`Hill andits authors are supply=ag imfrmationbutare not attempting to render
`engineering or other professiamal services. If such services are required, the
`assistance of an appropriate prat=ssiemal should be sought.
`
`
`
`This book is printed on T=ape==_ S==ee paper containing a minimum of
`rere
`a,
`©! 50 percent recycled deins== ===
`
`AT&T Exhibit 1026
`AT&Tv. VoIP, IPR 2017-01384
`Page 2
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 2
`
`

`

`eeee
`
`eeeeSEas
`
`Voice over
`Internet
`Protocol
`
`
`
`
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`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)andto 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 attemptto coverit in detail. The importance ofVoIP protocolsrelative
`to softswitch is that they are the building blocks that make VoIP possible.
`
`Page 4
`
`In November 1988, Republic Telcom (yes, one “e”) of Boulder, Colorado,
`received patent number 4,782,485 for a “Multiplexed Digital Packet Tele-
`phone System.” Theplaque from the Patent and Trademark Office describes
`it as follows: “A method for communicating speech signals fromafirst 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;transformingat least two of said groups of
`binary digital samples into corresponding framesofdigital compression.”
`Republic and its acquiring company, Netrix Corporation, applied this
`voice over data technology to the data technologies of the times (X.25 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-distancebills), offices where no
`PSTN existed (installations for mining and oil companies), and for long-
`distance bypasses(legitimate andillegitimate).
`
`Origins
`
`AT&T Exhibit 1026
`AT&Tv. VoIP, IPR 2017-01384
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 4
`
`

`

`Voice over Internet Protocol
`
`The popularity and applications of VoIP 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, 100-year-old industry, it is clear that VoIP will continue to capture more
`market share.
`
`How Does VoIP Work?
`
`www.TeleGeography.com.
`
`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. Thefirst process in an IP voice
`system is the digitization ofthe speaker’s voice. The next step (and thefirst
`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
`examinesthe recently digitized information to determineif 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
`enable noise suppression and the compression of voice streams.
`Compression algorithms include G.723, G.728, and G.729.
`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
`addressof its destination, a sequencing numberin 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
`encapsulating one packet inside another and, and as data movesalong,
`repackaging, readdressing, and reassembling the data.
`
`“TeleGeography 2002—Global Traffic Statistics and Commentary,’ TeleGeography, 2001,
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 5
`
`

`

`Page 6
`
`Wheneach packetarrives at the destination computer, its sequencingis
`checked to place the packets in the properorder. 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 heldin the jitter buffer varies depending
`on the characteristics of the network.
`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 tofill
`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. Therest of the chapter will describe the building blocks of a VoIP
`network:its protocols.
`
`Report to Congress on Universal Service, CC Docket No. 96-45, White Paper on IP Voice Ser-
`vices, March 18,1998 (www.von.org/docs/whitepap.pdf).
`
`AT&T Exhibit 1026
`AT&Tv. VoIP, IPR 2017-01384
`
`Chapter 4
`
`Protocols Related to VoIP
`
`The softswitch revolution was madepossible by the emergenceof voice over
`data, more specifically, VoIP. It should be noted here that softswitch solu-
`tions use TDM and ATM.However, the consensusin the industry is that the
`future is an IP network ultimately dictating a VoIP solution. Before outlin-
`ing softswitch solutions, it will first be necessary to understand VoIP. VoIP
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 6
`
`

`

`
`
`Voice over Internet Protocol
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`is best understoodas 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 [SIP]) 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 (Real-Time Transport Protocol
`[RTP]) the media stream (conversation) once the route of the media stream
`has been established are the functions of routing and transport protocols.
`Routing protocols such as UDP and TCP could be comparedto the “switch-
`ing” function described in Chapter 2, “The Public Switched Telephone Net-
`work (PSTN),” and Chapter 3, “Softswitch Architecture or ‘It’s the
`Architecture, Stupid!”
`RTP would be analogous to the “transport” 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, thatis, the conversation.
`
`
`
`
`
`
`
`
`
`
`
`
`
`Signaling Protocols
`
`
`The process of setting up a VoIPcall 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
`
`
`andthe signaling criteria is established, the media stream over which the
`packetized voice conversation willflow is established. Signaling establishes
`
`
`the virtual circuit over the network for that media stream. Signaling is
`independentof the media flow. It determines the type of media to be used
`
`
`in a call. Signaling is concurrent throughoutthe call. Twotypes of signaling
`are currently popular in VoIP: H.323 and SIP.
`
`
`
`
`*Douskalis, Bill, IP Telephony The Integration ofRobust VoIP Services. New York: Prentice Hall,
`
`2000.
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 7
`
`

`

`
`Figure 4-1
`Signaling and
`transport protocols
`used in VoIP
`
`Signaling (H.323, SIP)
`
`Transport
`
`Chapter 4
`
` AT&T Exhibit 1026
`
`H.323 1.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
`designedspecifically 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 numberof subprotocols. It uses protocol H.225.0
`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 (QoS). As a transport, H.323 uses RTP, an Internet Engt-
`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 ofinteroperability between diverse ven-
`dors platforms did not materialize with the adoption of H.328. Given the
`gravity ofthis protocol,it will be covered in a separate following chapter.
`
`Telephone
`
`Figure 4-1 details the relationship between signaling and media flow.
`This relationship between transport and signaling is very similar to the
`PSTNin that Signaling System 7 (SS7)is out-of-channelsignaling, such as
`that used in VoIP.
`
`AT&T v. VoIP, IPR 2017-01384
`Page 8
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 8
`
`

`

`Voice over Internet Protocol
`
`73 ©
`
`H.323 network.
`
`Terminals Usedfor real-time bidirectional multimedia communications, an
`1.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 ofH.323 is to interwork with other multimediater-
`minals. H.323 terminals are compatible with H.324 terminals on SCN and
`wireless networks, H.310 terminals on BroadbandIntegrated 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.
`
`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 Internetpacket exchange
`(IPX)-based local area networks (LANs), enterprise networks (ENs), metro-
`politan area networks (MANs), and wide area networks (WANs). H.323 can
`be applied in a variety ofmechanisms: 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 ofcomponents, which, when networkedtogether, provide
`the point-to-point and point-to-multipoint multimedia communication ser-
`vices: terminals, gateways, gatekeepers, and multipoint control units (MCUs).
`
`Gateways A gateway connects two dissimilar networks. An H.323 gateway
`provides connectivitybetween an 1.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 different 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-01384
`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
`mayalso providecall-routing services.
`Multipoint Control Units (MCUs) MCUsprovide 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 purposeofdetermining the
`audio or video coder/decoder (codec) to use, and may handle the media
`stream. The gatekeepers, gateways, and MCUsarelogically separate com-
`ponents of the H.323 standard but can be implemented as a single physi-
`
`Page 10
`
`cal device.
`H.323 Zone An H.323 zone is a collection ofall terminals, gateways, and
`MCUs managed by a single gatekeeper. A zone includes at least one ter-
`minal and may include gateways or MCUs. A zonehas only one gatekeeper.
`A zone may be independent ofnetwork topology and may be comprised of
`multiple network segments that are connected using routers or other
`devices.
`Additional protocols specified by H.323 arelisted in the following sec-
`tions. H.323 is independentof 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-Time Control Proto-
`col (RTCP).
`Audio Codec An audio codecencodes 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 speakeron the receiving H.3283 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 G.711 recommendation (audio coding at 64 Kbps).
`Additional audio codec recommendations such as G.722 (64, 56, and 48
`Kbps), G.723.1 (5.3 and 6.3 Kbps), G.728 (16 Kbps), and G.729 (8 Kbps) may
`also be supported.
`Video Codec Avideo codec encodes video from the camerafor transmission
`on the transmitting H.323 terminal and decodes the received video code
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`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 ofvideo 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 (RAS) 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 IP-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. UDPpro-
`vides multiplexing and checksum services. RTP can also be used with other
`transport protocols.
`
`H.225 Call Signaling The H.225call 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 andclosing of logical channels used to carry
`media streams, flow-control messages, general commands,and indications.
`
`ReaLTime 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 RTICP
`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-01384
`Page 11
`
`

`

`SIP SIP isatext-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 addressis
`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.® SIP plays such a pivotalrole in the evolution ofVoIP and softswitch-
`ing that it must be covered in the separate, following chapter.
`
`Page 12
`
`
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`
`Chapter 4
`
`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 befacilitated. 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 IP). Media gateways coordinate call control and status. Gate-
`way control protocols are signaling protocols.
`
`MGCP MGCPis 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 andthe telephony gateway to be
`controlled.
`MGCPassumesa call control architecture where thecall control intelli-
`gence is outside the gateways and is handled by external call control ele-
`ments. The MGCP assumesthat these call control elements,or call agents,
`will synchronize with each other to send coherent commandsto the gate-
`ways undertheir control. MGCPis a master/slave protocol, where the gate-
`ways are expected to execute commandssent 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-01384
`Page 12
`
`

`

`Voice over Internet Protocol
`
`
`‘Internet Engineering Task Force. Request For Comments (RFC) 2705, Media Gateway Control
`
`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
`exampleofa virtual endpoint is an audio source in an audio-content server.
`The creation of physical endpoints requires hardwareinstallation, while
`the creation of virtual endpoints can be done by software. Endpoint identi-
`fiers have two components, the domain nameof 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 beeither 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 andcalls 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 bea tele-
`phonegoing offhook, while a signal may bethe 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 analogline, 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, MGCPwill be the controlling protocol. MGCPwill con-
`tinue to be an integral element in any softswitch architecture.® Figure 4-2
`details the function of MGCPin softswitch architecture and Table 4-1 out-
`lines the signaling protocols and their softswitch components.
`
`Protocol, October 1999.
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 13
`
`

`

`Figure 4-2
`The relationship
`between signaling
`protocols and
`softswitch
`architecture
`components
`
`Chapter4
`
`Feature/Application Server
`
`Signaling Gateway
`
`Softswitch
`
`Media Gateway
`
`Page 14
`
`BICC Bearer Independent Call Control (BICC) is a newer protocol used
`for media-gateway-to-media-gateway communications. It provides a means
`of supporting narrowband ISDNservices 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.”
`
`Table 4-1
`
`Signaling protocols
`and associated
`softswitch
`components
`
`Media gateway—softswitch
`
`Media gateway—media gateway
`Media gateway—softswitch
`
`Softswitch—SS7 network
`
`Softswitch or application server
`
`Source: Internet Telephony
`
`"Ratta, Greg. “Bearer Independent Call Control and its application of H.248 in public net-
`works.” ITU-T IP/MediaComm Workshop 2004. www.itu.int/itudoc/itu-t/com13/ipexpert/
`ipmedia/71396.html. April 26, 2001, pg.3.
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 14
`
`

`

`Voice over Internet Protocol
`
`Routing Protocols
`
`VoIP is routed over an IP networkvia routers. In orderto 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 techniqueasit adapts to changing network conditions. The
`router uses a metric ofthe shortest distance between two endpoints to help
`determine the optimum path. The router determines the least cost (most
`efficient) path from the origin to the destination.
`Twoalgorithms are used to determine theleast cost route. They are dis-
`tance vector and link state. Protocols that make use ofthese algorithmsare
`called Interior Gateway Protocols (IGPs). The Routing Information 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 ISDN User Part (SUP) 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 andtear downcircuit-switched voice
`calls between a softswitch/signaling gateway and an STP. ISUP determines
`the proceduresfor call setup and teardown on the SS7 network.®
`TCAP is a peerprotocol to ISUP in the SS7 protocol hierarchy for end-to-
`end signaling not associated with call setup or specific trunks in the PSTN
`network. Someof its main uses aretoll-free 800 number translations for
`routing across the network andlocal numberportability (LNP). It also pro-
`vides the interface between databases and SCPs.° TCAP providesservices
`to any numberof application parts. Common application parts include the
`Intelligent Network Application Part (INAP) and the Mobile Application
`Part (MAP).This book will address the interworkings of SS7 and VoIP net-
`works in greater detail in a following chapter.
`
`WCollins, Michael. Carrier Grade Voice Quer LP. New York: McGraw-Hill, 2001. pg. 311.
`
`
`8Newton, Harry. Newton’s Telecom Dictionary, 16th edition. New York: CMPBooks.pg. 486.
`*Douskalis, pg. 9.
`
`AT&T Exhibit 1026
`AT&T v. VoIP, IPR 2017-01384
`Page 15
`
`

`

`Chapter4
`
`Page 16
`
`(RIP) is an IGP based onthe distance vector algorithm and the Open Short-
`est Path First (OSPF)protocol is an IGP based onthelink state algorithm.
`Whereone network needs to communicate with another, it uses an Exterior
`Gateway Protocol (EGP). One example of an EGPis the Border Gateway
`Protocol (BGP).
`Routing Information Protocol (RIP) RIP isa distance vector protocol
`that uses a hop count (the number ofrouters it passes throughon its route
`to its destination) as its metric. RIP is widely used for routing traffic on the
`Internet andis an IGP, which meansthatit 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 isa routing proto-
`col developed for IP networks by the IGP 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.
`OSPF has two primary characteristics. The first is that the protocolis
`open, which meansthatits specification is in the public domain. The OSPF
`specification is published as the IETF’s RFC 1247. The second principal
`characteristic is tha