throbber
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 1027
`AT&Tv. VoIP, IPR 2017-01383
`Page 1
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`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 1027
`AT&Tv. VoIP, IPR 2017-01383
`Page 2
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 2
`
`

`

`et)
`
`Architecture?
`
`©>5O(e=©ae<<
`&>)+°paSop)on©op
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 3
`
`
`

`

`Page 4
`
`If the worldwide Public Switched Telephone Network (PSTN) could be
`replaced overnight,the best candidate architecture, at the time ofthis writ-
`ing, would be based on Voice over IP (VoIP) and the Session Initiation Pro-
`tocol (SIP). Much of the VoIP industry has been basedon offering solutions
`that leverage existing circuit-switched infrastructure (such as VoIP gate-
`ways that interface a private branch exchange [PBX] and an Internet Pro-
`tocol [IP] network). At best, these solutions offer a compromise between
`circuit- and packet-switching architectures with resulting liabilities of lim-
`ited features, expensive-to-maintain circuit-switched gear, and questionable
`quality ofservice (QoS) as a call is routed between networks based on those
`technologies. SIP is an architecture that potentially offers more features
`than a circuit-switched network.
`SIP is a signaling protocol. It uses a text-based syntax similar to the
`Hypertext Transfer Protocol (HTTP)like that used in web addresses. Pro-
`gramsthat are designed for the parsing of HTTP can be adaptedeasily for
`use with SIP. SIP addresses, known as SIP uniform resource locators
`(URLs) take the form of web addresses. A web address can be the equiva-
`lent of a telephone number in an SIP network. In addition, PSTN phone
`numbers can be incorporated into an SIP address for interfacing with the
`PSTN.An email addressis portable. Using the proxy concept, one can check
`his or her email from any Internet-connected terminal in the world. Tele-
`phone numbers, simply put, are not portable. They only ring at one physi-
`cal location. SIP offers a mobility function that can follow subscribers to
`whatever phonetheyare nearest to at a given time.
`Like H.323, SIP handles the setup, modification, and teardown of multi-
`media sessions, including voice. Although it works with most transport pro-
`tocols, its optimal transport protocol is the Real Time Protocol (RTP)(refer
`to Chapter3, “Softswitch Architectureor‘It’s the Architecture, Stupid!” for
`more information on RTP). Figure 5-1 shows how SIP functions as a sig-
`naling protocol while RTP is the transport protocol for a voice conversation.
`SIP was designed as a part of the Internet Engineering Task Force IETF)
`multimedia data and control architecture. It is designed to interwork with
`other IETF protocols such as the Session Description Protocol (SDP), RTP,
`and the Session AnnouncementProtocol (SAP). It is described in the IETF’s
`RFC 2543. Many in the VoIP and softswitch industry believe that SIP will
`replace H.323 as the standard signaling protocol for VoIP.
`SIP is part of the IETF standards process and is modeled upon other
`Internet protocols such as the Simple Mail Transfer Protocol (SMTP) and
`HTTPIt is used to establish, change, and tear down (end) calls between one
`or more users in an IP-based network. In order to provide telephony ser-
`vices, a number ofdifferent standards and protocols must come together—
`
`Chapter 5
`
`AT&T Exhibit 1027
`AT&Tv. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 4
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`Ee :
`Figure 5-1
`SIP is a signaling
`protocol and RTP
`transports the
`conversation
`
`protocol.
`
`
`
`SIP phone
`
`:
`
`SIP phone
`
`tacts the user. A response from the user to the UA server results in an SIP
`
`SIP is focused on two classes of network entities: clients (also called user
`agents [UAs]) and servers. VoIP calls on SIP to originate at a client andter-
`minateat a server. Typesof clients in the technology currently available for
`SIP telephony include a PC loaded with a telephony agent or an SIP tele-
`phone.Clients can also reside on the same platform asa server. For example,
`a PC on acorporate wide area network (WAN) might be the server for the SIP
`telephony application, but it may also be used as a user's telephone(client).
`
`specifically to ensure transport (RTP), provide signaling with the PSTN,
`guarantee voice quality (Resource Reservation Setup Protocol [RSVP]), pro-
`vide directories (Lightweight Directory Access Protocol [LDAP]), authenti-
`cate users (Remote Access Dial-In User Service [RADIUS]), and scale to
`meet anticipated growth curves.
`
`What Is SIP?
`
`SIP Architecture
`
`STPis a client-server architecture. The client in this architectureis the UA,
`which interacts with the user. It usually has an interface towards the user
`in the form of a PC or an IP phone(an SIP phonein this case). Four types
`of SIP servers exist. The type of SIP server used determines the architec-
`ture ofthe network. Those servers are the user agent server (UAS),the redi-
`rect server, the proxy server, and a registrar.
`
`SIP Calls via a UA Server
`
`<A UA server accepts SIP requests and con-
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 5
`
`

`

`Page 6
`
`response representing the user. An SIP device will function as both a UA
`client (UAC) and as a UA server. As a UAC, the SIP device can initiate SIP
`requests. As a UA server, the device can receive and respond to SIP
`requests. As a standalone device, the UA can initiate and receive calls that
`empowers SIP to be used for peer-to-peer communications. Figure 5-2
`describes the UA server.
`The function of SIP is best understood via the HTTP model upon which
`it is based. SIP is a request/responseprotocol. A client is an SIP entity that
`generates a request. A server is an SIP entity that receives requests and
`returns responses. When a web site is desired, the client generates a
`request by typing in the URL, such as www.mcgrawhill.com. The server
`upon which the web site is hosted responds with McGraw-Hill’s web page.
`SIP uses the same procedure. The UA sending the request is known as a
`UAC, and the UA returning the response is the UAS. This exchange is
`knownas an SIP transaction.
`Per Figure 5-2, a call initiates with the UA ofthe calling party sending
`an INVITE command caller@righthere.org to the called party,
`callee@theotherside.com. The UAfor the caller has translated the namefor
`the called party into an IP address via a Domain Name System (DNS)
`query accessible via their own domain. The INVITE commandis sent to an
`SIP User Datagram Protocol (UDP) port and contains information such as
`media format and the From, To, and Via information. The TRYING infor-
`mational response (180) from the calling party's call agent is analogous to
`the Q.931 CALL PROCEEDING message used in the PSTN,indicating the
`call is being routed. In the direct call model, a TRYINGresponseis unlikely,
`but for proxy and redirect models it is used to monitor call progress. SIP
`
`Chapter 5
`
`(1) Invite(a
`
`(2) 180 Ringingee
`
`Calllee
`
`eae
`Figure 5-2
`SIP UA server to UA
`servercall
`
`Calller
`
`
`
`(3) 200 OK
`—————Ee
`
`(4) ACK
`——————EE
`
`Conversation
`
`(6) 200 OK
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 6
`
`

`

`SDP parameters for the media type and format provided by the receiving
`
`uses six methods of signaling, as shown in Table 5-1. Additional methods
`are underconsideration by the IETF at this time.
`Whenthecall arrives at the remote endpoint, the phone rings and a new
`responseis sent to that endpoint: RINGING(180). This is analogous to the
`Q.931 ALERTING message used in the PSTN. The time between the user
`dialing the last digit and the time RINGINGis received by the caller is
`known asthe postdial delay (PDD)for SIP call setup. If a telephone num-
`ber is involved in addressing the call, the numbers must be translated into
`an IP address. Table 5-2 provides a comparison of SIP and PSTNsignals.
`Whenthe called party answers the phone, a 200 response is sent to the
`calling party’s UA. The UA sends another request, ACK, acknowledging the
`response to the INVITE request. At that moment, media begins to flow on
`the transport addresses of the two endpoints. The ACK maycarry the final
`
`OPTIONS
`
`This queries a server about its capabilities, including which methods
`and which SDPsit supports. This determines which media types a
`remote user supports before placingthecall.
`
`This is used to abandon sessions. In two-party sessions, abandon-
`mentby oneof the parties implies that the session is terminated. A
`return BYE from the other party is not necessary.
`
`This method cancels pending transactions. The CANCEL method
`identifies the call via the call ID, call sequence, and To and From val-
`ues in the SIP header.
`
`REGISTER
`
`These requests are sent by users to inform a server about their cur-
`rent location. SIP servers are co-located with SIP registrars. This
`enables the SIP server to find a user.
`
`a S
`
`ource: Camarillo
`
`SIP: Alternative Softswitch Architecture?
`
`Table 5-1
`
`SIP signaling
`methods
`
`The first message sent by a calling party to invite users to partici-
`pate in a session. It contains information in the SIP header that
`identifies the calling party, call ID, called party, and call and
`sequence numbers.It indicatesa call is being initiated. When a mul-
`tiple choice of SDP parametersis offered, the ones chosen are
`returned with the success (200) code in the response message.
`
`This is used to acknowledge the reception of a final response to an
`INVITE. A client originating an INVITE request issues an ACK
`request whenit receives a final response for the INVITE, providing a
`three-way handshake.
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 7
`
`

`

`Table 5-2
`
`oa
`
`5
`
`se amerar
`
`Chapter 5
`
`Page 8
`
`SIP Calls via a Proxy Server Proxy servers in the SIP sense are sim-
`ilar in function to proxy servers that serve a website (mail relay via SMTP)
`for a corporate local area network (LAN). An SIP client in this case would
`send a request to the proxy server that would either handle it or pass it on
`to another proxy server that, after some translation, would take thecall.
`The secondary servers would see the call as coming from the client. By
`virtue of receiving and sending requests, the proxy serveris both a server
`and a client. Proxy servers function well in call forwarding and follow-me
`services.
`Proxy servers can beclassified by the amount of state information they
`store in a session. SIP defines three types of proxy servers: call stateful,
`stateful, and stateless. Call stateful proxies need to be informedofall the
`SIP transactions that occur during the session and are always in the path
`taken by SIP messages traveling between end users. These proxies store
`state information from the moment the session is established until the
`momentit ends. A stateful proxy is sometimes called a transaction stateful
`proxy as the transactionis its sole concern. A stateful proxy stores a state
`related to a given transaction until the transaction concludes. It does not
`need to be in the path taken by the SIP messages for subsequent transac-
`tions. Forking proxies are good examples of stateful proxies. Forking prox-
`ies are used whena proxyservertries more than onelocation for the user;
`thatis, it “forks” the invitation.
`
`Comparison ofSIP
`and PSTN signals
`
`TRYING
`
`Q.931 Call Proceeding
`
`RINGING
`
`Q.931 Alerting
`
`ACK
`
`Q.931 Connect
`
`Q.931 Connect
`XINVITE
`$$
`
`endpoint. The sequence ofthe INVITE and following ACK messagesis sim-
`ilar to the Q.931 CONNECT message. ACKs do not require a response.
`Table 5-3 displays the response codes for SIP.
`At this pointin the call sequence,as seen in Figure 5-1, media flows over
`RTP, with the Real-Time Control Protocol (RTCP) providing the monitoring
`of the quality of the connection andits associated statistics. Next, as the
`name would imply, a BYE request from either party ends the call. As all
`messages are sent via UDP, nofurther action is required.
`
`AT&T Exhibit 1027
`ATA&Tv. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 8
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`
`
`Table 5-3
`
`SIP response codes
`
`
`
`100
`
`180
`
`181
`
`182
`
`183
`
`200
`
`202
`
`300
`
`301
`
`302
`
`305
`
`Trying
`
`Ringing
`
`Call is being
`forwarded
`
`Queued
`
`Session progress
`
`OK
`
`Accepted
`
`Multiple choices
`
`Moved permanently
`
`Moved temporarily
`
`Use proxy
`
`‘Numbercode Description :
`413
`
`Request, entity too large
`
`414
`
`415
`
`420
`
`480
`
`481
`
`482
`
`"483
`
`484
`
`485
`
`486
`
`A487
`
`Request, URI too large
`
`Unsupported media type
`
`Bad extension
`
`Temporarily not available
`
`Call leg/transaction does
`not exist
`
`Loop detected
`
`Too many hops
`
`Address incomplete
`
`Ambiguous
`
`Busy here
`
`Request cancelled
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`380
`
`400
`
`401
`
`402
`
`403
`
`404
`
`405
`
`406
`
`A407
`
`408
`
`409
`
`Alternative service
`
`Bad request
`
`Unauthorized
`
`Payment required
`
`Forbidden
`
`Not found
`
`Methodnot allowed
`
`Not acceptable
`
`Proxy authentication
`
`Request timeout
`
`Conflict
`
`410
`
`Gone
`
`488
`
`500
`
`501
`
`502
`
`503
`
`504
`
`505
`
`600
`
`603
`
`604
`
`606
`
`Not acceptable here
`
`Internal severe error
`
`Not implemented
`
`Bad gateway
`
`Service unavailable
`
`Gateway timeout
`
`SIP version not supported
`
`Busy everywhere
`
`Decline
`
`Does not exist anywhere
`
`Not acceptable
`
`Length required
`Oo ———————
`Source: Camarillo
`
`411
`
`
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 9
`
`

`

`Page 10
`
`Stateless proxies keep with nostate. They receive a request, forwardit to
`the next hop, and immediately delete all states related to that request.
`Whena stateless proxy receives a response, it determines routing based
`solely on the Via headerandit does not maintain a statefor it."
`An SIPcall using a proxy serveris a little more complicated than the
`simple SIP call model described previously (see Figure 5-3). In this call, the
`caller is configured with the called party's SIP server. An INVITEis sent to
`the called party’s SIP server with the called party’s text address in the To
`field. The called party’s server determinesifthe called party is registered in
`that server. If the called party is registered on that server, it then deter-
`mines the called party’s current location on the network. Thisis called the
`mobility feature.
`Oncethe called partyis located via the mobility feature, the proxy server
`generates an INVITE request with no alteration of the headers of the
`request, except to add its own name in the Via field. Multiple servers may
`be involved in tracking down thecalled party.
`Next the server must retain state information on the call. The server
`does this by correlating Cseq numbers, call IDs, and other elements ofthe
`headers as they pass through the proxy server. The server sends a TRYING
`message backto the calling party’s agent. Whenthe called party answersat
`the new location, a RINGINGresponseis sent to the proxy server via the
`remote server (the called party’s server). Both servers have Via entries in
`the response message to the calling party. Finally, ACK messages are
`
`Chapter 5
`
`Calller
`
`SIP PROXY
`
`Calllee
`
`. =
`SIP call using a proxy
`server
`(3) 200 OK
`(4) 200 OK
`qn nn,|
`(5) ACK
`(6) ACK
`
`(1) Invite
`
`J
`(2) Invite
`
`Conversation
`
`(7) BYE
`
`(8) BYE
`
`(10) 200 OK
`<<
`
`(9) 200 OKpl
`
`
`1Camarillo, Gonzalo. SIP Demystified. New York: McGraw-Hill, 2002, p. 126-129.
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 10
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`exchanged,thecall is established, and the media flow over RTP can begin.
`The call is terminated via a BYE request.
`What makes the proxy server marketable is its user mobility feature.
`The called party can be logged in at multiple locations at once. This results
`in the proxy server generating the INVITEto all nameson the list until the
`called party is found (preferably RINGING,but also TRYING or OK).?
`A redirect server accepts SIP requests, maps the destination address to
`zero or more new addresses, and returns the translated addressto the orig-
`inator of the request. After that, the originator of the request can send
`requests to the addresses returned by the redirect server. The redirect
`server originates no requests of its own. Redirect servers pose an alterna-
`tive means ofcall forwarding and follow-me services. What differentiates
`the redirect server from a proxyserveris that the originating client redi-
`rects the call. The redirect server provides the intelligence to enable the
`originating client to perform this task as the redirect server is no longer
`involved.
`The redirect server call model is a mix of the two previously described
`call models. Here a proxy model reverts to the direct call model once the
`called party is located. The redirect server returns a redirection response to
`the INVITE with code 301 or 302 indicating the called party is at the loca-
`tion listed in the Contact field of the message body. The calling party’s
`Media Gateway Controller (MGC) closes its signaling with the redirect
`server and initiates another INVITEto the located returnedin the redirect
`response. After that, the call flow is that of the direct model. If the called
`party is registered at a numberoflocations, the redirect server will return
`a list of names (URI) to be contacted. The calling party can then contact
`those addresses directly.
`
`3Collins, Daniel. Carrier Grade Voice over IP. New York: McGraw Hill, 2000, pp. 167-168.
`
`Registrar A registrar is a server that accepts SIP REGISTER requests.
`SIP includes the concept of user registration wherea usertells the network
`that he is available at a given address. This registration occurs by issuing
`a REGISTERrequest by the userto theregistrar. A registrar is often com-
`bined with a proxy orredirect server. Practical implementations often com-
`bine the UAC and UAS with registrars with either proxy servers or
`redirection servers. This can result in a network having only UAs andredi-
`rection or proxy servers.®
`
`
`2Douskalis, Bill. IP Telephony: The Integration ofRobust VoIP Services. New York: Prentice Hall,
`2000, pg. 74.
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 11
`
`

`

`Chapter 5
`
`Location Servers Location servers are not SIP entities but are an
`important part ofSIP architecture.Alocation server stores and returns pos-
`sible locations for users. It can make use of information from registrars or
`from other databases. Most registrars upload location updates to a location
`server upon receipt. SIP is not used between location servers and SIP
`servers. Some location servers use the Lightweight Directory Access Proto-
`col (LDAP, see IETF RFC 1777) to communicate with SIP servers.*
`
`New Standards for SIP
`New standards efforts are aimed toward using the IP networkfor nonvoice
`interactions. Here are a few ofthe more exciting standards developments:
`«= PSTN to Internet Interworking (PINT) The PINT (RFC 2848)
`standardseffort defines “click-to-dial” services—interworking between
`a web page and a PSTN gateway element, or PINT server. PINTis
`helping to standardize service delivery, including request to eall,
`request to fax, request to hear content, and, in the future, request to
`
`Page 12
`
`conference.
`; Services in the PSTNIIN Requesting Internet Services (SPIRITS)
`This working group is providing a framework for standardizing the
`mechanismsfor controlling critical call altering and call-completion
`processes from the Internet by exposing the Internet domain to the
`PSTN’s call model. The goal is to create a framework for Internet call-
`waiting-type services that will be applicable to wireline, wireless, and
`broadband(cable and x-Type Digital Subscriber Line [xDSL])
`environments. Proposed SPIRITS-enabled network events include voice
`mail arrival, incoming call notification, attempts to dial numbers,
`dropping dialed connection, completing Internet service provider (ISP)
`connections, attempts to forwardcalls, and attempts to
`subscribe/unsubscribe to a PSTN service.
`Signaling Translation (SIGTRAN) The IETF standard that deals
`with Signaling System 7 (887; specifically Transaction Capabilities
`Application Part or TCAP over IP). A later chapter will cover SIGTRAN
`in greater detail.
`Telephone Number Mapping (ENUM) The IETF standard that
`defines address mapping among phone numbers and Internet devices.
`
`
`‘Thid., p.105.
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 12
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`97 .
`
`It provides a way to reach multiple communication services via a single
`phone number. ENUMprovidesa process for converting a phone
`number into a DNS address (URL). It translates e.164 telephone
`numbers into Internet addresses.°
`TRIPis a policy-driven
`Telephony Routing over IP (TRIP)
`interadministrative domain protocol for advertising the reachability of
`telephony destinations between location servers and for advertising
`attributes of the routes to those destinations. TRIP’s operation is
`independentof any signaling protocol; hence, TRIP can serve as the
`telephony routing protocol for any signaling protocol.®
`
`Some SIP Configurations
`
`http://www.iec.org/online/tutorials/ip_in/topic05.html, pp. 5—6.
`
`SIP, givenits simplicity and flexibility (discussed later in this chapter), sim-
`plifies the establishment of an alternative voice network. Figure 5-4 sug-
`gests a numberof applications for SIP. The figure illustrates a corporate
`voice network that utilizes its corporate WAN to transport its interoffice
`voice traffic. This company can protect their investment in legacy phones
`and PBXs byinstalling an SIP gateway to interface the TDM technology
`with the SIP-based VoIP network. The SIP gateways also provide an inter-
`face with the PSTN.
`In new offices and for remote workers, SIP phones provide a simple
`meansof eliminating long-distance charges and connecting those workers
`to the rest of the network. Failing an expensive SIP phone, PC-based UAs
`such as those contained in Microsoft’s XP (see the end of this chapter) can
`also function as a telephony agent connecting the worker to the network.
`Providing the intelligence for this network is the SIP proxy server to con-
`trol the calls. The application server providescritical corporate voice ser-
`vices such as voice mail, follow me, conferencing, call forwarding, unified
`messaging, voice-activated services, web-based provisioning, and new fea-
`tures that can be custom developed by the corporation, the SIP equipment
`vendor, or third-party vendors.
`
`
`
`5Wolter, Charlotte. “ENUM Brings VoIP into Telephone Mainstream.” Sounding Board Maga-
`zine, June 2001, p.12
`®“Interworking Switched Circuit and Voice-over-IP Networks.” A white paper by Performance
`Technologies
`and the
`International Engineering Consortium,
`available online at
`
`*
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 13
`
`

`

`Figure 5-4
`SIP gateways in long-
`distance bypass and
`enterprise telephony
`
`Application Server
`
`
`
`
`
`
`
`PC based SIP
`User Agent
`
`
`
`SIP Proxy Server
`
`Page 14
`
`Comparison of SIP to H.323
`H.323 is a blanket specification, meaning that it is not a protocol by itself,
`but rather defines how touse other protocols in a specific manner to create
`a service. H.323 was developed by the International Telecommunications
`Union (ITU) in the mid-1990s and consists of several protocols, including
`H.225 registration, admission, and status (RAS) signaling, H.225.0 call sig-
`naling, H.245 control signaling, and RTP. It also includes several standards
`for voice and video digitization and compression.
`H.323 wasoriginally designed to implement multimedia conferences on
`a LAN.Inits original form, it was intended that certain conferences would
`be announced, or advertised in advance, and interested parties would sub-
`scribe or register to participate in the conference. These conferences may be
`interactive or may be broadcast events with participants viewingor listen-
`ing only.
`The applications were expanded to include participants who were not
`located on the same LAN aswell as more general calling capabilities. This
`resulted in more complexity to the protocol and underlying applications.
`1.323 is a very large protocol suite, requiring a large amount ofmemory for
`
`Chapter 5
`
`SIP phone
`
`SIP phone
`
`Telephone
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 14
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`code and data space. H.323 used a messaging schemecalled Abstract Syn-
`tax Notation (ASN.1). ASN.1 is widely used by the ITU,but it is difficult for
`users to read and understand directly. The use of ASN.1 requires special
`test equipmentto be built that can decode the ASN.1 messages and trans-
`late them into human-readable format for easier network testing and
`debugging.
`The IETF sought to create a much simpler, yet powerful protocol that
`could be used for call setup and management in support of VoIP applica-
`tions. A working group was formed, and the result of that effort was the
`development of the SIP, which was ratified by the IETF as RFC 2543 in
`1999. H.323 and SIP havefourfields of comparison: complexity, extensibil-
`ity, scalability, and services.
`
`Complexity of H.323 Versus SIP
`
`Force, January 1997.
`
`As VoIP protocols evolve, they become more efficient. Simplicity fosters
`acceptance.In this case, SIP is a marked improvement over H.323 primar-
`ily due to its greater simplicity, which translates to greaterreliability. Given
`its simplicity relative to H.323, SIP enjoys a fastercall setup, a prerequisite
`for carrier-grade voice applications.
`H.323 is a rather complex protocol. The sum total of the base specifica-
`tions alone is 736 pages.SIP, on the other hand, along withits call control
`extensions and SDPs totals 276 pages in RFC 3261. H.323 defines hun-
`dreds of elements, while SIP has only 37 headers(32 in the base specitica-
`tion, 5 in the call control extensions), each with a small number of values
`and parameters, but that contain more information.
`A basic but interoperable SIP Internet telephony implementation can get
`by with four headers (To, From, Call-ID, and CSeq) and three request types
`(IN-VITE, ACK, and BYE)and is small enough to be assigned as a homework
`programming problem. A fully functional SIP client agent with a graphical
`user interface (GUI) has been implemented in just two man-months.
`H.323 uses a binary representation for its messages, based on ASN.1 and
`the packed encoding rules (PER). SIP, on the other hand, encodes its mes-
`sages as text, similar to HTTP’ and the Real-Time Streaming Protocol
`
`
`"Fielding, R., J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee. Request for Comments (Pro-
`posed Standard) 2068: “Hypertext transfer protocol—HTTP/1.1.” Internet Engineering Task
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 15
`
`

`

`Chapter 5
`
`Page 16
`
`(RTSP).® This leads to simple parsing and generation, particularly when
`done with powerful text-processing languages such as Perl. The textual
`encoding also simplifies debugging, allowing for manual entry and the
`perusing of messages. Its similarity to HTTP also allows for code reuse;
`existing HTTP parsers can be quickly modified for SIP usage.°
`Oneofthe biggest criticisms of H.323 is that it can result in the transmis-
`sion ofmany unnecessary messagesacross the network. This causes H.323 to
`not scale well. That is, for a large system, the overhead associated with han-
`dling a large number of messages hasa significant effect on the system per-
`formance. A more heavily loaded system will result in poorer voice quality.
`QoS measures do not address networktraffic and call setup issues in H.323.
`H.323’s complexity also stems from its use of several protocol compo-
`nents. There is no clean separation of these components; many services
`require interactions between several of them. (Call forward, for example,
`requires components of H.450, H.225.0, and H.245.) The use of several dif-
`ferent protocols also complicates firewall traversal. Firewalls must act as
`application-level proxies,’ parsing the entire message to arrive at the
`required fields. The operation is stateful since several messages are
`involvedin call setup. SIP, on the other hand,uses a single request that con-
`tains all necessary information.
`Figure 5-5 illustrates the messages required to set up a call, assuming
`that the caller already knows the addressof the callee. Without going into
`the details of the messages, it can be seen that setting up thecall requires
`the exchange of 16 messages across the network. This number grows con-
`siderably ifthe two terminals are located on different LANs or are managed
`by the Terminal Capability Set messages. This allows the two endsto agree
`on the parameters to be usedfor thecall. In the case of SIP, this information
`is exchanged in the Invite and 200:OK messages(see Figure 5-6). Separate
`messages are not required. Likewise, in H.323, separate messages are
`exchanged to create logical connections between the two endpoints over
`which the voice information is passed (using the Open Logical Channel
`messages). In SIP, this information is also passed in the Invite and the
`200:0K message."!
`
`8Schulzrinne, H., R. Lanphier, and A. Rao. Request for Comments (Proposed Standard) 2326:
`“Real-time streaming protocol (RTSP).” Internet Engineering Task Force, April 1998.
`°Schulzrenne, Henning, and Jonathan Rosenberg. “A Comparison of SIP and H.323 for Internet
`Telephony.” White paper available at www.cs.columbia.edu/sip/papers.html.
`10Packet-Based Multimedia Communications Systems,” H.323, ITU, February 1998.
`“STP vs. H.323, A Business Analysis.” White paper from Windriver, available at www.
`sipcenter.com/files/Wind_River_SIP_H323.pdf.
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 16
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`=
`
`Terminal
`
`me ft fs
`Figure 5-5
`Gall setup process
`for 1.323
`
`7
`
`Gatekeeper
`=
`
`OPEN LOGICAL CHANNEL ACK
`
`Conversation
`
`ing. This significantly limits the ability to makecalls to multiple locations,
`
`To counter this obvious weakness in H.328, procedures were added to
`enable H.323 to connect basic calls much quicker. This procedure is referred
`to as Fast Start andis illustrated in Figure 5-7. Fast Start eliminates sev-
`eral of the messages by requiring each side to have detailed knowledge of
`the parametersfor the call and to have preassigned ports for communicat-
`
`| Se
`
`Le
`Figure 5-6
`(Il setup process
`for SIP
`
`Calller
`
`;
`
`(1) Invite
`
`Calllee
`
`op
`
`(2) 180 Ringing6).
`
`(3) 200 OK
`
`(4) ACK
`
`(5) BYE
`
`(6) 200 OK
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01383
`Page 17
`
`

`

`Terminal
`
`Terminal
`
`Gatekeeper
`
`H.323 using
`Fast Start
`
`Chapter 5
`
`SETUP FAST START
`
`CALL PROCEEDING
`
`CONNECT
`
`Page 18
`
`as the terminals must have configuration information forall locations they
`will contact using the Fast Start procedur

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket