`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-01384
`Page 1
`
`AT&T Exhibit 1027
`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 1027
`AT&Tv. VoIP, IPR 2017-01384
`Page 2
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 2
`
`
`
`et)
`
`Architecture?
`
`©>5O(e=©ae<<
`&>)+°paSop)on©op
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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-01384
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`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-01384
`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