Chapter 4
`
`(RIP) is an IGP based on the distance vector algorithm and the Open Short-
`est Path First (OSPF) protocol is an IGP based on the link state algorithm.
`Where one network needs to communicate with another, it uses an Exterior
`Gateway Protocol (EGP). One example of an EGP is the Border Gateway
`Protocol (BGP).
`
`Routing Information Protocol (RIP) RIP is a distance vector protocol
`that uses a hop count (the number of routers it passes through on its route
`to its destination) as its metric. RIP is widely used for routing traffic on the
`Internet and is an IGP, which means that it performs routing within a sin—
`gle autonomous system. EGPs, such as BGP, perform routing between dif-
`ferent autonomous systems. RIP itself evolved as an Internet routing
`protocol, and other protocol suites use modified versions of RIP.
`
`hello packets to its neighbors and receives their hello packets. In addition
`
`Open Shortest Path First (OSPF) Protocol OSPF is a routing proto-
`col developed for IP networks by the 1GP Working Group of the IETF. The
`Working Group was formed in 1988 to design an IGP based on the Short-
`est Path First (SPF) algorithm for use on the Internet. Similar to the Inte-
`rior Gateway Routing Protocol (IGRP), OSPF was created because in the
`mid-1980s RIP was increasingly incapable of serving large, heterogeneous
`internetworks.
`OSPF has two primary characteristics. The first is that the protocol is
`open, which means that its specification is in the public domain. The OSPF
`specification is published as the IETF’s RFC 1247. The second principal
`characteristic is that OSPF is based on the SPF algorithm, which some—
`times is referred to as the Dijkstra algorithm, named for the person credited
`with its creation.
`‘
`OSPF is a link—state routing protocol that calls for the sending of link-
`state advertisements (LSAs) to all other routers within the same hierarchi-
`cal area. Information on attached interfaces, the metrics used, and other
`variables are included in OSPF LSAS. As OSPF renters accumulate link-
`state information, they use the SPF algorithm to calculate the shortest path
`to each node.
`
`SPF Algorithm The SPF routing algorithm is the basis for OSPF oper-
`ations. When an SPF router is powered up, it initializes its routing-protocol
`data structures and then waits for indications from lower-layer protocols
`that its interfaces are functional. After a router is assured that its inter-
`faces are functioning, it uses the OSPF Hello protocol to acquire neighbors,
`which are routers with interfaces to a common network. The router sends
`
`AT&T, Exh. 1003, p. 686
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 686
`
`

`

`Voice over Internet Protocol
`
`PPENDIX P
`
`I
`
`to helping acquire neighbors, Hello packets also act as keep—alives to let
`routers know that other routers are still functional.
`
`Each router periodically sends an LSA to provide information on a
`router’s adjacencies or to inform others when a router’s state changes. By
`comparing established adjacencies to link states, failed routers can be
`detected quickly and the network’s topology altered appropriately From the
`topological database generated from LSAs, each router calculates a
`shortest—path tree, with itself as root. The shortest—path tree, in turn, yields
`a routing table.11
`
`11Cisoo Systems. “Open Shortest Path First.”A white paper from Cisco Systems, www.ciscocom.
`
`Border Gateway Protocol BGP performs interdomain routing in
`TCP/IP networks. BGP is an EGP, which means that it performs routing
`between multiple autonomous systems or domains and exchanges routing
`and reachability information with other BGP systems. BGP was developed
`to replace its predecessor, the now obsolete EGP, as the standard exterior
`gateway-routing protocol used on the global Internet. BGP solves serious
`problems with EGP and scales to Internet growth more efficiently.
`BGP performs three types of routing: interautonomous system routing,
`intra—autonomous system routing, and passthrough autonomous system
`
`routing. Interautonomous system routing occurs between two or more BGP
`routers in different autonomous systems. Peer routers in these systems use
`
`BGP to maintain a consistent view of the internetwork topology BGP
`neighbors communicating between autonomous systems must reside on the
`same physical network. The Internet serves as an example of an entity that
`uses this type of routing because it is comprised of autonomous systems or
`administrative domains. Many of these domains represent the various
`institutions= corporations, and entities that make up the Internet. BGP is
`frequently used to provide path determination to provide optimal routing
`within the Internet.
`
`Intro-autonomous system routing occurs between two or more BGP
`routers located Within the same autonomous system. Peer routers within
`the same autonomous system use BGP to maintain a consistent view of the
`system topology. BGP also is used to determine which router will serve as
`the connection point for specific external autonomous systems. Once again,
`the Internet provides an example of interautonomous system routing. An
`
`organization, such as a university, could make use of BGP to provide opti-
`mal routing within its own administrative domain or autonomous system.
`The BGP protocol can provide both inter— and intra-autonomous system
`routing services.
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 687
`
`

`

`Chapter 4
`
`Passthmugh autonomous system routing occurs between two or more
`BGP peer routers that exchange traific across an autonomous system that
`does not run BGP. In a passthrough autonomous system environment, the
`BGP traffic does not originate within the autonomous system in question
`and is not destined for a node in the autonomOus system. BGP must inter-
`act with whatever intra—autonomous system routing protocol is being used
`to successfully transport BGP traffic through that autonomous system.
`
`
`
`BGP Routing As with any routing protocol, BGP maintains routing
`tables, transmits routing updates, and bases routing decisions on routing
`metrics. The primary function of a BGP system is to exchange network—
`reachability information,
`including information about
`the list of
`autonomous system paths, with other BGP systems. This information can
`be used to construct a graph of autonomous system connectivity from which
`routing loops can be pruned and with which autonom0us—system-level pol-
`icy decisions can be enforced.
`Each BGP router maintains a routing table that lists all feasible paths to
`a particular network. The renter does not refresh the routing table, how—
`ever. Instead, routing information received from peer routers is retained
`until an incremental update is received. BGP devices exchange routing
`information upon an initial data exchange and alter incremental updates.
`When a router first connects to the network, BGP routers exchange their
`entire BGP routing tables. Similarly, when the routing table changes,
`routers send the portion of their routmg table that has changed. BGP
`routers do not send regularly scheduled routing updates, and BGP renting
`updates advertise only the optimal path to a network.
`BGP uses a single routing metric to determine the best path to a given
`network. This metric consists of an arbitrary unit number that specifies the
`degree of preference of a particular link. The BGP metric typically is
`assigned to each link by the network administrator. The value assigned to
`a link can be based on any number of criteria, including the number of
`autonomous systems through which the path passes, stability, speed, delay,
`or cost.12
`
`Resource Reservation Protocol (RSVP) The Resource Reservation
`Protocol (RSVP) is a network control protocol that enables Internet appli-
`cations to obtain special qualities of service (@2083) for their data flows.
`
`
`
`12Cisco Systems. “Border Gateway Protocol.” A white paper from Cisco Systems. www.cisoo.
`com, June 1999.
`
`AT&T, Exh. 1003, p. 688
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 688
`
`

`

`Voice over Internet Protocol
`
`PPEN DIX P
`
`RSVP is not a routing protocol; instead, it works in conjunction with rout-
`
`ing protocols and installs the equivalent of dynamic access lists along the
`routes that routing protocols calculate. RSVP occupies the place of a trans-
`port protocol in the 081 Model seven-layer protocol stack. The IETF is now
`working toward standardization through an RSVP working group. RSVP
`operational topics discussed in this chapter include data flows, Q08, session
`startup, reservation style, and soft state implementation.
`In RSVP, a data flow is a sequence of messages that have the same
`source, destination (one or more), and QoS. QoS requirements are commu-
`nicated through a network via a flow specification, which is a data structure
`used by internetwork hosts to request special services from the internet-
`work. A flow specification often guarantees how the internetwork will han-
`dle some of its host traffic.
`
`ally substantially smaller than key frames. As a result, rates vary quite a
`
`RSVP supports three traffic types: best-efi'ort, rate-sensitive, and delay—
`sensitive. The type of data-flow service used to support these traffic types
`
`depends on the QoS implemented. The following paragraphs address these
`traffic types and associated services. For information regarding Q08, refer
`to the appropriate section later in this chapter.
`Best-effort traffic is traditional IP traffic. Applications include file trans—
`fers, Such as mail transmissions, disk mounts, interactive logins, and trans-
`action traffic. The service supporting best-effort trafiic is called best-effort
`service. Rate-sensitive traffic is willing to give up timeliness for guaranteed
`rate. Rate-sensitive traffic, for example, might request 100 Kbps of band-
`width. If it actually sends 200 Kbps for an extended period, a router can
`delay traffic. Rate-sensitive traflic is not intended to run over a circuit—
`switched network; however, it usually is associated with an application that
`
`has been ported from a circuit-switched network (such as ISDN) and is run-
`ning on a datagram network (1P).
`An example of such an application is H.323 videoconferencing, which is
`designed to run on ISDN (H.320) or ATM (H.310) but is found on the Inter-
`net. H.323 encoding is a constant rate or nearly constant rate, and it
`requires a constant transport rate. The RSVP service supporting rate-
`sensitive traffic is called guaranteed bit-rate service. Delay-sensitive traffic
`is traffic that requires the timeliness of delivery and varies its rate accord—
`ingly. MPEG-II video, for example, averages about 3 to 7 Mbps depending
`on the amount of change in the picture. As an example, 3 Mbps might be a
`picture of a painted wall, although 7 Mbps would be required for a picture
`of waves on the ocean. MPEG-II video sources send key and delta frames.
`Typically, 1 or 2 key frames per second describe the whole picture, and 13
`or 28 frames describe the change from the key frame. Delta frames are usu-
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 689
`
`

`

`Chapter 4
`
`bit from frame to frame. A single frame, however, requires delivery within
`a frame time or the codec is unable to do its job. A specific priority must be
`negotiated for delta-frame traffic. RSVP services supporting delay-sensitive
`trafiic are referred to as controlled-delay service (nonreal time service) and
`
`predictive service (real-time service).
`In the context of RSVP, QoS is an attribute specified in flow specifica-
`tions that is used to determine the way in which data interchanges are han-
`dled by participating entities (routers, receivers, and senders). RSVP is
`used to specify the QoS by both hosts and routers. Hosts use RSVP to
`request a 6208 level from the network on behalf of an application data
`stream. Routers use RSVP to deliver QoS requests to other routers along
`the path(s) of the data stream. In doing so, RSVP maintains the router and
`host state to provide the requested service.13
`
`Transport Protocols
`
`Figure 4-1 shows that the actual VoIP conversation takes place over a chan-
`nel separate from the signaling channel. The following paragraphs describe
`RTP, the transport protocol.
`
`ciscosystemscom, June 1999.
`
`Real-Time Protocol (RTP) RTP is the most popular of the VoIP trans—
`port protocols. It is specified in RFC 1889 under the title of “RTP: A Trans-
`port Protocol for Real Time Applications.” This RFC describes both RTP and
`another protocol, RTCP. As the name would suggest, these two protocols are
`necessary to support real-time applications like voice and video. RTP oper-
`ates on the layer above UDP, which does not avoid packet loss or guarantee
`the correct order for the delivery of packets. RTP packets overcome those
`shortcomings by including sequence numbers that help applications using
`RTP to detect lost packets and ensure packet delivery in the correct order.
`RTP packets include a timestamp that gives the time when the packet is
`sampled from its source media stream. This timestamp assists the destina—
`tion application to determine the synchronized playout to the destination
`user and to calculate delay and jitter, two very important detractors ofvoice
`quality. RTP does not have the capacity to correct delay and jitter, but it
`does provide additional information to a higher-layer application so that the
`application can make determinations as to how a packet of voice or data is
`best handled.
`
`
`LaCisco Systems. “Resource Reservation Protocol.” A white paper from Cisco Systems, WWW.
`
`AT&T, EXh. 1003, p. 690
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 690
`
`

`

`
`
`APPENDIX P
`
`
`
`
`
`
`
`Voice over Internet Protocol
`
`iiié;
`
`_
`
`8 5
`
`RTCP provides a number of messages that are exchanged between ses-
`sion users and that provide feedback regarding the quality of the session.
`The type of information includes details such as the numbers of lost RTP
`packets, delays, and interarrival jitter. As voice packets are transported in
`RTP packets, RTCP packets transfer quality feedback. Whenever an RTP
`session opens, an RTCP session is also opened. That is, when a UDP port
`number is assigned to an RTP session for the transfer of media packets,
`another port number is assigned for RTCP messages.
`
`RTP Payload: RTP carries the digitally encoded voice by taking one or more
`digitally encoded voice samples and attaching an RTP header to provide
`RTP packets, which are made up of an RTP header and a payload of the
`voice samples. These RTP packets are sent to UDP, where a UDP header
`is attached. This combination then goes to E where an 113 header is
`attached and the resulting IP datagram is routed to the destination. At the
`destination, the headers are used to pass the packet up the stack to the
`
`
`
`
`appropriate application.
`
`
`
`
`
`
`
`
`
`voice sample.
`
`
`RTP Headers RTP carries the carried voice in a packet. The RTP payload
`is comprised of digitally coded samples. The RTP header is attached to this
`payload and the packet is sent to the UDP layer. The RTP header contains
`the necessary information for the destination to reconstruct the original
`
`
`
`
`
`
`
`RTP Control Protocol (RTCP) RTCP enables exchanges of control
`information between session participants with the goal of providing
`quality-related feedback. This feedback is used to detect and correct distri-
`bution issues. The combination of RTCP and IP multicast enables a net—
`
`
`
`
`
`
`
`where possible to improve quality.
`
`
`work operator to monitor session quality. RTCP provides information on the
`quality of an RTP session. RTCP empowers network operators to obtain
`information about delay, jitter, and packet loss and to take corrective action
`
`
`
`
`
`
`The previous discussion assumed the use of Internet Protocol version 4
`(IPv4), the predominant version of IP in use today. A new version, IPv6, is
`now coming on the market. The explosion of Internet addresses necessitates
`
` IPv6
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 691
`
`

`

`Chapter 4
`
`the deployment of IPv6. IPv6 makes possible infinitely more addresses than
`IPv4. Enhancements offered by IPv6 over IPv4 include
`
`a Expanded address space Each address is allocated 128 bits
`instead of 32 bits in IPv4.
`
`g Simplified header format This enables easier processing of IP
`datagrams.
`
`Improved support for headers and extensions This enables
`
`greater flexibility for the introduction of new options.
`
`Flow-labeling capability This enables the identification of traffic
`flows for real—time applications.
`
`Authentication and privacy Support for authentication, data
`
`integrity, and data confidentiality are supported at the IP level rather
`than through separate protocols or mechanisms above IP.
`
`tecture for the next few years.
`
`three elements of access, switching, and transport,VoIP can be summarized
`as a study of three types of protocols: signaling, routing, and transport. The
`proper selection of VoIP signaling protocols for a network is an issue of
`almost religious proportions among network builders. Although protocols
`will continue to evolve and new protocols will emerge, those addressed in
`this chapter will constitute the predominant structure of softswitch archi-
`
`Conclusion
`
`This chapter addressed the building blocks of VoIP. It will be necessary in
`future chapters to understand many of the concepts contained in this chap-
`ter. Just as the PSTN and softswitch networks can be broken down into the
`
`AT&T EXh. 1003 .692
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 692
`
`

`

`APPENDIX Q
`
`AT&T, Exh. 1003, p. 693
`
`

`

`APPENDIX Q
`
` The MCGmW'Hm Companies
`
`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 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
`
`Marjorie Spencer and the production supervisor
`The sponsoring editor for this book
`was Pamela A. Pelton. It was set in N61 Century Schoolbook by MacAIlister Publishing
`Services, LLC.
`
`Printed and bound by RR Donnie“
`
`quantity discounts to use as premiums and
`McGraWaHill books are available a:
`programs. For more information,
`sales promotions, or for use in enzyme;
`please write to the Director of Sales, Professional Publishing, McGrmv-Hill,
`Two Penn Plaza, New York, NY 1"} Or contact your local bookstore.
`
`
`
`been obtained by The McGraw-Hill
`Information contained in
`sources believed to be reliable. However,
`Companies, Inc. (“McGraw-Hi‘
`glrantee the accuracy or completeness of
`neither McGraerill nor its
`neither McGraW-Hill nor its authors
`any information published
`
`shall be responsible for any 371': :r—izsions, or damages arising out of use of
`this information. This work ‘5 99 '
`' #5; with the understanding that McGraW—
`
`Hill and its authors are supp;
`_ mafion but are not attempting to render
`engineering or other pror kli
`If such services are required, the
`assistance of an appropriate
`should be sought.
`
`
`
`
`I! This book is printed on Fh'jF'ir’Z; azri-i-ee paper containing a
`‘3 50 percent recycled de—iri-‘ei in:
`
`of
`
`AT&T, EXh. 1003, p. 694
`__——_
`
`
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 694
`
`

`

`APPENDIX Q
`
`9V0.“anreRA
`
`Architecture?
`
`hCt.1wSfl0S
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 695
`
`
`

`

`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.
`
`vices, a number of different standards and protocols must come together—
`
`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 ‘lt’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-
`
`AT&T, EXh. 1003, p. 66
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 696
`
`

`

`SIP: Alternative Softswitch Architecture?
`
`PPENDIX Q
`
`m =
`Figure 5—1
`SIP is a signaling
`protocol and RTP
`transports the
`conversation
`
`protocol
`
`
`
`SIP phone
`
`
`
`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 [RADIUSD, and scale to
`meet anticipated growth curves.
`
`What Is 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).
`
`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-
`tacts the user. A response from the user to the UA server results in an SIP
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 697
`
`

`

`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
`
`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.
`
`
`
`
`
`(1) Invite_____—__—’
`
`(2) 180 Ringing
`4—___—
`
`(3) 200 OK
`‘____—___.
`
`(4) ACK——’_
`
`coarsening;
`
`
`
`m F
`
`igure 5-2
`SIP UA server to UA
`servercafl
`
`AT&T, Exh. 1003, p. 698
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 698
`
`

`

`PPENDIX Q
`
`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.
`
`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
`
`
`
`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
`SDP parameters for the media type and format provided by the receiving
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 699
`
`

`

`Chapter 5
`
`Table 5-2
`
`Comparison of SIP
`and PSTN signals
`
`TRYING
`
`RINGING
`
`ACK
`
`Q.931 Call Proceeding
`
`Q33 1 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 prOxies. 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 cell. As all
`messages are sent via UDP, no further action is required.
`
`AT&T Xh. 1003 .700
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 700
`
`

`

`APPENDIX
`
`
`
`A
`
`1 93
`
`_
`
`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
`
`SIP: Alternative Softswiteh Architecture?
`
`Table5-3
`
`v
`
`SIP response codes
`
`100
`
`180
`
`181
`
`182
`
`183
`
`200
`
`202
`
`300
`
`301
`
`302
`
`Trying
`
`Ringing
`
`Call is being
`forwarded
`
`Queued
`
`Session progress
`
`OK
`
`Accepted
`
`Multiple choices
`
`Moved permanently
`
`Moved temporarily
`
`w
`
`j
`
`413
`
`414
`
`415
`
`420
`
`480
`
`481
`
`482
`
`' 483
`
`484
`
`485
`
`486
`
`
`
`Length required
`411
`_____________———————-
`Source: Camarillo
`
`487
`
`488
`
`500
`
`501
`
`502
`
`503
`
`504
`
`505
`
`600
`
`603
`
`604
`
`606
`
`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
`
`305
`
`380
`
`400
`
`401
`
`402
`
`403
`
`404
`
`405
`
`406
`
`407
`
`408
`
`409
`
`410
`
`Use proxy
`
`Alternative service
`
`Bad request
`
`Unauthorized
`
`Payment required
`
`Forbidden
`
`Not found
`
`Method not allowed
`
`Not acceptable
`
`Proxy authentication
`
`Request timeout
`
`Conflict
`
`Gone
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 701
`
`

`

`Chapter 5
`
`SIP call using a proxy
`server
`
`Calller
`
`SIP PROXY
`
`Calllee
`
`(1) Invite
`
`I
`(2) lnvnte
`__————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 par