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

`

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

`

`Alternative
`
`Architecture?
`
`Softswitch
`
`
`
`
`
`
`
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 3
`
`

`

`Chapter 5
`
`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 based on 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-
`grams that are designed for the parsing of HTTP can be adapted easily 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 address is 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 phone they are 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 Chapter 3, “Softswitch Architecture or ‘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 Announcement Protocol (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
`HTTP. It is used to establish, change, and tear down (end) calls between one
`or more users in an lP-based network. In order to provide telephony ser-
`vices, a number of different standards and protocols must come together—
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`_Page 4
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 4
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`m =
`Figure 5—1
`SIP is a signaling
`protocol and RTP
`transports the
`conversation
`
`protocol
`
`
`
`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 [UASD and servers. VoIP calls on SIP to originate at a client and ter—
`minate at a server. Types of 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 as a server. For example,
`a PC on a corporate 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 [RADIUSlL and scale to
`meet anticipated growth curves.
`
`What Is SIP?
`
`SIP Architecture
`
`SIP is a clientnserver architecture. The client in this architecture is 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 phone in this case). Four types
`of SIP servers exist. The type of SIP server used determines the architec-
`ture of the 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
`
`

`

`it is based. SIP is a request/response protocol. 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 wwwmcgrawhillnom. 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
`known as an SIP transaction.
`
`
`
`Figure 5-2
`SIP UA server to UA
`server call
`
`(1) Invite
`
`(2) 180 Ringing
`4—___—
`
`(3) 200 OK
`4—————-—-
`
`(4) ACK——,.
`
`coarsening;
`
`
`
`Chapter 5
`
`response representing the user. An SIP device will function as both a UA 1
`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
`
`Per Figure 5-2, a call initiates with the UA of the calling party sending
`an INVITE command caller@righthere.org to the
`called party,
`callee@theotherside.com. The UA for the caller has translated the name for
`
`the called party into an IP address via a Domain Name System (DNS)
`query accessible via their own domain. The INVITE command is 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 TRYING response is unlikely,
`but for proxy and redirect models it is used to monitor call progress. SIP
`
`AT&T Exhibit 1027
`AT&T V. VolP, IPR 2017-01384
`Page 6
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 6
`
`

`

`OPTIONS
`
`This queries 5 server about its capabilities, including which methods
`and which SDPs it supports. This determines which media types a
`remote user supports before placing the call.
`
`This is used to abandon sessions. In two-party sessions, abandon-
`ment by one of 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.
`__—___—___—.._—_.—-—-——--—~'—
`
`Source: Camarillo
`
`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 indicates a call is being initiated. When a mul-
`tiple choice of SDP parameters is 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 when it receives a final response for the INVITE, providing a
`three-way handshake.
`
`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 under consideration by the IETF at this time.
`When the call arrives at the remote endpoint, the phone rings and a new
`response is sent to that endpoint: RINGING (180). This is analogous to the
`Q9231 ALERTING message used in the PSTN. The time between the user
`dialing the last digit and the time RINGING is received by the caller is
`known as the 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 PSTN signals.
`When the 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 may carry the final
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 7
`
`

`

`Chapter 5
`
`Table 5-2
`
`Comparison of SIP
`and PSTN signals
`
`TRYING
`
`RINGING
`
`ACK
`
`Q.931 Call Proceeding
`
`Q3131 Alerting
`
`62.93 1 Connect
`
`
`
`SIP Calls via a Proxy Server Proxy servers in the SIP sense are sim-
`ilar in function to proxy servers that serve a web site (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 the call.
`The secondary servers would see the call as coming from the client. By
`virtue of receiving and sending requests, the proxy server is both a server
`and a client. Proxy servers function well in call forwarding and follow-me
`services.
`Proxy servers can be classified 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 informed of all 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
`moment it ends. A stateful proxy is sometimes called a transaction stateful
`proxy as the transaction is 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 pr0xies. Forking prox—
`ies are used when a proxy server tries more than one location for the user;
`that is, it “forks” the invitation.
`
`$1.931 Connect
`XIN V [TE
`____________—.———-——-—-
`
`endpoint. The sequence of the INVITE and following ACK messages is 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 point in 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 and its associated statistics. Next, as the
`name would imply, a BYE request from either party ends the call. As all
`messages are sent via UDP, no further action is required.
`
`AT&T Exhibit 1027
`AT&T V. VolP, IPR 2017-01384
`Pa-e8
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 8
`
`

`

`SIP: Alternative Softswiteh Architecture?
`
`
`
`Table 5-3
`
`SIP response codes
`
`Numbemfle Marilee
`
`Numbercgfie‘,“ Desmption
`
`K
`
`
`
`100
`
`180
`
`181.
`
`182
`
`183
`
`200
`
`202
`
`300
`
`301
`
`302
`
`305
`
`Trying
`
`Ringing
`
`Call is being
`forwarded
`
`Queued
`
`Session progress
`
`OK
`
`413
`
`414
`
`415
`
`420
`
`480
`
`481
`
`Accepted
`
`Multiple choices
`
`Moved permanently
`
`Moved temporarily
`
`Use proxy
`
`482
`
`' 483
`
`484
`
`485
`
`486
`
`Request, entity too large
`
`Request, URI too large
`
`Unsupported media type
`
`Bad extension
`
`Temporarily not available
`
`Call legftransaction does
`not exist
`
`Loop detected
`
`Too many hops
`
`Address incomplete
`
`Ambiguous
`
`Busy here
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Length required
`_____________———————-
`Source: Camarillo
`
`Request cancelled
`
`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
`
`380
`
`400
`
`401
`
`402
`
`403
`
`404
`
`405
`
`406
`
`407
`
`408
`
`409
`
`410
`
`411
`
`Alternative service
`
`Bad request
`
`Unauthorized
`
`Payment required
`
`Forbidden
`
`Not found
`
`Method not allowed
`
`Not acceptable
`
`487
`
`488
`
`500
`
`501
`
`502
`
`503
`
`504
`
`505
`
`Proxy authentication
`
`600
`
`Request timeout
`
`Conflict
`
`Gone
`
`603
`
`604
`
`606
`
`
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 9
`
`

`

`Chapter 5
`
`SIP call using a proxy
`server
`
`Caiiler
`
`SIP PROXY
`
`Caillee
`
`(1) invite
`
`.
`(2) inwte
`__————p
`
`(4) 200 OK
`
`(3) 200 OK
`
`Stateless proxies keep with no state. They receive a request, forward it to
`the next hop, and immediately delete all states related to that request.
`When a stateless proxy receives a response, it determines routing based
`solely on the Via header and it does not maintain a state for it.1
`An SIP call using a proxy server is 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’5 SIP server. An INVITE is sent to
`the called party’s SIP server with the called party’s text address in the To
`field. The called party’s server determines ifthe 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. This is called the
`mobility feature.
`Once the called party is 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 the called party.
`Next the server must retain state information on the call. The server
`does this by correlating Cseq numbers, call IDs, and other elements of the
`headers as they pass through the proxy server. The server sends a TRYING
`message back to the calling party’s agent. When the called party answers at
`the new location, a RINGING response is 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
`
`
`
`(10) 200 OK
`‘_____/
`
`4__._—
`(9) 200 OK
`
`
`lCamarillo, Gonzalo. SIP Demystified. New York: McGraW-Hill, 2002, p. 126—129.
`
`AT&T Exhibit 1027
`AT&T V. VolP, IPR 2017-01384
`Page 10
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 10
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`exchanged, the call 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 INVITE to all names on the list until the
`called party is found (preferably RINGING, but also TRYING or OK).2
`A redirect server accepts SIP requests, maps the destination address to
`zero or more new addresses, and returns the translated address to 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 of call forwarding and follow-me services. What differentiates
`the redirect server from a proxy server is 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.
`
`3Collins, Daniel. Carrier Grade Voice over IP. New York: McGraW Hill, 2000, pp. 167—168.
`
`
`
`2DouskaJis, Bill. IP Telephony: The Integration ofRobust VoIP Services. New York: Prentice Hall,
`2000, pg. 74.
`
`The redirect server cell 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 ceiling party’s
`Media Gateway Controller (MGC) closes its signaling with the redirect
`server and initiates another INVITE to the located returned in the redirect
`response. After that, the call flow is that of the direct model. If the called
`party is registered at a number of locations, the redirect server will return
`a list of names (URI) to be contacted. The calling party can then contact
`those addresses directly.
`
`Registrar A registrar is a server that accepts SIP REGISTER requests.
`SIP includes the concept of user registration where a user tells the network
`that he is available at a given address. This registration occurs by issuing
`a REGISTER request by the user to the registrar. A registrar is often com-
`bined with a proxy or redirect 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 and redi-
`
`rection or proxy servers.3
`
`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 of SIP architecture. A location 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 network for nonvoice
`interactions. Here are a few of the more exciting standards developments:
`n PSTN to Internet Interworking (PINT) The PWT (RFC 2848)
`standards effort defines “click—to—dial” services—mterworking between
`a web page and a PSTN gateway element, or PINT server. PINT is
`helping to standardize service delivery, including request to call,
`request to fax, request to hear content, and, in the future, request to
`conference.
`Services in the PSTN/IN Requesting Internet Services (SPIRITS)
`This working group is providing a framework for standardizing the
`mechanisms for 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 axe-Type Digital Subscriber Line [XDSLD
`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 forward calls, and attempts to
`subscribe/unsubscribe to a PSTN service.
`Signaling Translation (SIGTRAN) The IETF standard that deals
`with Signaling System 7 (SS7; specifically Transaction Capabilities
`Application Part or TCAP over IF). A later chapter will cover SIGTRAN
`in greater detail.
`a Telephone Number Mapping (ENUM) The IETF standard that
`defines address mapping among phone numbers and Internet devices.
`
`
`4Ibid., p.105.
`
`AT&T Exhibit 1027
`AT&T V. VolP, IPR 2017-01384
`Page 12
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 12
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`It provides a way to reach multiple communication services via a single
`phone number. ENUM provides a process for converting a phone
`number into a DNS address (URL). It translates e.164 telephone
`numbers into Internet addresses.5
`
`Telephony Routing over IP (TRIP) TRIP is a policy—driven
`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
`
`independent of any signaling protocol; hence, TRIP can serve as the
`telephony routing protocol for any signaling protocol.6
`
`Some SIP Configurations
`
`SIP, given its simplicity and flexibility (discussed later in this chapter), sim-
`plifies the establishment of an alternative voice network. Figure 5—4 sug—
`gests a number of 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 by installing an SIP gateway to interface the TDM technology
`with the SIP-based VoIP network. The SIP gateways also previde an inter—
`face with the PSTN.
`
`http:l/Wwwiec.org/online/tutorials/ip_in/topic05.htnil, pp. 5%.
`
`In new offices and for remote workers, SIP phones provide a simple
`means of 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 provides critical 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.
`
`
`
`5\lVolter, Charlotte. “ENUM Brings VoIP inm Telephone Mainstream.” Sounding Board Mago-
`zine, June 2001, p.12
`6“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
`
`

`

`
`
`H.323 is a blanket specification, meaning that it is not a protocol by itself,
`but rather defines how to use 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 (HAS) 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 was originally designed to implement multimedia conferences on
`a LAN. In its 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 viewing or listen-
`ing only.
`The applications were expanded to include participants who were not
`located on the same LAN as well as more general calling capabilities. This
`resulted in more complexity to the protocol and underlying applications.
`H.323 is a very large protocol suite, requiring a large amount ofmemory for
`
`llllllllllll
`
`lillll E
`llllll
`lliill
`Illlll
`Illlll
`
`y
`"
`'
`Telephone
`
`'
`'
`Telephone
`
`||l||
`Illll
`
`Comparison of SIP to H.323
`
`AT&T Exhibit 1027
`AT&T V. VolP, IPR 2017-01384
`Page 14
`
`.7.
`
`Figure 5-4
`SIP gateways in long-
`distance bypass and
`enterprise telephony
`
`
`
`PC based SlF
`User Agent
`
`Chapter 5
`
`Application Server
`
`
`
`
`
`"m
`
`_ S
`
`IP phone
`
`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 scheme called 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 equipment to 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 have four fields of comparison: complexity, extensibil—
`
`ity, scalability, and services.
`
`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 greater reliability. Given
`its simplicity relative to H.323, SIP enjoys a faster call 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 with its 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 specifica-
`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—1D, 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 HTTP7 and the Beat-Time Streaming Protocol
`
`Complexity of H.323 Versus SIP
`
`
`
`TFielding, R., J. Gettys, J. Mogul, H. Nielsen, and T. Berners~Lee. Request for Comments (Pro—
`posed Standard) 2068: “Hypertext transfer protocoliHTI‘P/ll.” Internet Engineering Task
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 15
`
`

`

`Chapter 5
`
`(RTSP).8 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-9
`One of the biggest criticisms of H.323 is that it can result in the transmis-
`sion of many unnecessary messages across 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 has a significant effect on the system per-
`formance. A more heavily loaded system will result in poorer voice quality.
`QoS measures do not address network traffic 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,10 parsing the entire message to arrive at the
`required fields. The operation is stateful since several messages are
`involved in 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 address of the callee. Without going into
`the details of the messages, it can be seen that setting up the call requires
`the exchange of 16 messages across the network. This number grows con
`siderably if the two terminals are located on different LANs or are managed
`by the Terminal Capability Set messages. This allows the two ends to agree
`on the parameters to be used for the call. In the case of SIP, this information
`is exchanged in the Invite and 200:0K 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.11
`
`5Schulzrinne, H., R. Lanphier, and A. Rao. Request for Comments {Proposed Standard) 2326:
`flReal-time streaming protocol (RTSP).” Internet Engineering Task Force, April 1998.
`gSchulzrenne, Henning, and Jonathan Rosenberg. “A Comparison of SIP and H.323 for Internet
`Telephony.” White paper available at www.cs.colmnbiaedu/sip/papershtml.
`1°“Packet—Based Multimedia Comnmnications Systems,” H.323, ITU, February 1998.
`11“SlIP vs. H.323, A Business Analysis.” White paper from Windriver, available at www.
`sipcenter.com/files/Wind,River;SlP_H323 .pdf.
`
`AT&T Exhibit 1027
`AT&T v. VolP, IPR 2017-01384
`Page 16
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 16
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`Terminal
`
`Terminal
`
`Figure 5—5
`Call setup process
`fer H.323
`
`I F
`
`igure 5—6
`Call setup process
`.Eor SIP
`
`ing. This significantly limits the ability to make calls to multiple locations,
`
`To counter this obvious weakness in H.323, procedures were added to
`enable H.323 to connect basic calls much quicker. This procedure is referred
`to as Fast Start and is illustrated in Figure 5—7. Fast Start eliminates sev-
`eral of the messages by requiring each side to have detailed knowledge of
`the parameters for the call and to have preassigned ports for communicat-
`
`(1) Invite
`
`(2) 180 Ringing
`4—————-—
`
`(3) 200 OK
`
`(4) ACK
`
`4—__—_——
`(5) BYE
`
`(6) 200 OK
`
`AT&T Exhibit 1027
`AT&T v. VoIP, IPR 2017-01384
`Page 17
`
`

`

`
`
`as the terminals must have configuration information for all locations they
`will contact using the Fast