Voice over Internet Protocol
`
`to helping acquire neighbors, Hello packets also act as keep-alives to let
`routers know that other routersarestill functional.
`Kach 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.“
`
`Cisco Systems. “Open Shortest Path First.” A white paper from Cisco Systems, www.cisco.com.
`
`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 moreefficiently.
`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 systemsor
`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.
`Intra-autonomous system routing occurs between two or more BGP
`routers located within the same autonomous system. Peer routers within
`the same autonomous system use BGPto 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 provideopti-
`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. 659
`
`

`

`Chapter4
`
`Passthrough autonomous system routing occurs between two or more
`BGP peer routers that exchangetraffic across an autonomous system that
`does not run BGP. In a passthrough autonomoussystem environment, the
`BGPtraffic does not originate within the autonomous system in question
`andis not destined for a node in the autonomous system. BGP mustinter-
`act with whatever intra-autonomous system routing protocol is being used
`to successfully transport BGPtraffic through that autonomous system.
`
`AT&T, Exh. 1003, p. 660
`
`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 usedto construct a graph of autonomous system connectivity from which
`routing loops can be pruned and with which autonomous-system-level pol-
`icy decisions can be enforced.
`Each BGP router maintains a routing table thatlists all feasible paths to
`a particular network. The router 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 after incremental updates.
`When a routerfirst connects to the network, BGP routers exchange their
`entire BGP routing tables. Similarly, when the routing table changes,
`routers send the portion of their routing table that has changed. BGP
`routers do not send regularly scheduled routing updates, and BGP routing
`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 numberthat 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 numberofcriteria, including the number of
`autonomous systems through which the path passes, stability, speed, delay,
`or cost.”
`
`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 (QoSs) for their data flows.
`
`
`
`2Cisco Systems. “Border Gateway Protocol.” A white paper from Cisco Systems. www.cisco.
`com, June 1999.
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 660
`
`

`

`Voice over Internet Protocol
`
`ally substantially smaller than key frames. As a result, rates vary quite a
`
`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 OSI 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, QoS, 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 someofits host traffic.
`RSVP supports three traffic types: best-effort, rate-sensitive, and delay-
`sensitive. The type of data-flow service used to support thesetraffic types
`depends on the QoS implemented. The following paragraphs address these
`traffic types and associated services. For information regarding QoS, refer
`to the appropriate section later in this chapter.
`Best-effort traffic is traditional IP traffic. Applications includefile trans-
`fers, such as mail transmissions, disk mounts, interactive logins, and trans-
`action traffic. The service supporting best-effort traffic 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 traffic ig 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) andis run-
`ning on a datagram network (IP).
`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 amountof changein 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 18
`or 28 frames describe the change from the key frame. Delta frames are usu-
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 661
`
`

`

`Chapter 4
`
`bit from frameto frame. A single frame, however, requires delivery within
`a frame timeor the codec is unable to do its job. A specific priority must be
`negotiated for delta-frametraffic. RSVP services supporting delay-sensitive
`traffic 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 interchangesare 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 QoS 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 maintainsthe router and
`host state to provide the requested service.”
`
`ciscosystems.com, June 1999. AT&T, Exh. 1003, p. 662
`
`Real-Time Protocol (RTP) RTP is the most popular of the VoIP trans-
`port protocols. It is specified in RFC 1889 underthetitle 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
`RTPto detect lost packets and ensure packet delivery in the correct order.
`RTP packets include a timestamp that gives the time whenthe packetis
`sampled from its source media stream. This timestampassists the destina-
`tion application to determine the synchronized playout to the destination
`user and to calculate delay andjitter, 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.
`
`
`Transport Protocols
`
`Figure 4-1 shows that the actual VoIP conversation takes place over a chan-
`nel separate from thesignaling channel. The following paragraphs describe
`RTP, the transport protocol.
`
`Cisco Systems. “Resource Reservation Protocol.” A white paper from Cisco Systems, www.
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 662
`
`

`

`cee
`
`4A
`
`=
`
`85
`
`Voice over Internet Protocol
`
`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 interarrivaljitter. 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
`numberis assigned to an RTP session for the transfer of media packets,
`another port numberis assigned for RTCP messages.
`
`RTP Payloads RTP carries the digitally encoded voice by taking one or more
`digitally encoded voice samples and attaching an RTP headerto 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 IP where an IP 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.
`
`
`
`
`
`
`PPENDIX P
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`RTP Headers RTP carries the carried voice in a packet. The RTP payload
`is comprisedof digitally coded samples. The RTP headeris 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
`
`
`voice sample.
`
`
`
`
`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-
`
`
`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
`where possible to improve quality.
`
`
`
` IPv6
`
`
`
`
`The previous discussion assumed the use of Internet Protocol version 4
`(IPv4), the predominant version of IP in use today. A new version, [Pv6,is
`now coming on the market. The explosion ofInternet addresses necessitates
`
`
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 663
`
`

`

`Chapter 4
`
`the deployment of IPv6. IPv6 makespossible infinitely more addresses than
`IPv4. Enhancementsoffered by [Pv6 over [Pv4 include
`
`e Expanded address space Each addressis allocated 128 bits
`instead of 32 bits in IPv4.
`
`tecture for the next few years.
`
`This chapter addressed the building blocks of VoIP. It will be necessary in
`future chapters to understand manyofthe concepts contained in this chap-
`ter. Just as the PSTN andsoftswitch networks can be broken down into the
`three elementsof access, switching, and transport, VoIP can be summarized
`as a studyofthree 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-
`
`Simplified header format This enables easier processing of IP
`datagrams.
`Improved support for headers and extensions This enables
`greaterflexibility 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 mechanismsaboveIP.
`
`Conclusion
`
`APPENDIX P
`
`AT&T, Exh. 1003, p. 664
`
`

`

`Softswitch
`Architecture for VoIP
`
`San Juan Seoul Singapore Sydney ‘Toronto
`
`Franklin D. Ofrtman,Jr.
`
`APPENDIX Q
`
`McGraw-Hill
`New York Chicago San Francisco Lisbon
`London Madrid Mexico City Milan New Delhi
`
`AT&T, Exh. 1003, p. 665
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 665
`
`

`

`
`err
`
`APPENDIX Q
`
` 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 bookis printed on reepuied seidee paper containing a minimum of
`©! 50 percent recycled deta== Stee
`
`AT&T, Exh. 1003, p. 666
`
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 666
`
`

`

`APPENDIX Q
`
`2.
`
`Architecture?
`
`©>5O(e=©ae<<
`&>)+°paSop)on©op
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 667
`
`
`

`

`Chapter 5
`
`vices, a number ofdifferent standards and protocols must come together— AT&T, Exh. 1003, p. 668
`
`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-
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 668
`
`

`

`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-
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 669
`
`

`

`AT&T, Exh. 1003, p. 670
`
`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
`
`Calllee
`
`(1) Invite(a
`
`(2) 180 Ringingee
`
`(3) 200 OK
`
`Calller
`
`Figure 5-2
`SIP UA server to UA
`servercall
`
`
`
`(4) ACK
`——————EE
`
`Conversation
`
`(6) 200 OK
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 670
`
`

`

`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
`
`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.
`
`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
`
`PPENDIX Q
`
`SIP signaling
`The first message sent by a calling party to invite users to partici-
`methods
`— — 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.
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 671
`
`

`

`Chapter 5
`
`Table 5-2
`
`Comparison ofSIP
`and PSTN signals
`
`TRYING
`
`Q.931 Call Proceeding
`
`RINGING
`
`Q.931 Alerting
`
`ACK
`
`Q.931 Connect
`
`_ AT&T, Exh. 1003, p. 672
`
`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.
`
`Q.931 Connect
`XINVITE
`Ns
`
`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.
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 672
`
`

`

`APPENDIX
`
`7 “
`
`|
`
`
`
`SIP: Alternative Softswitch Architecture?
`
`93
`
`
`
`ena a
`Table 5-3
`
`_Nmbereade_DeseHpeen
`
`SIP response codes
`100
`Trying
`
`180
`Ringing
`
`181
`Call is being
`forwarded
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Loop detected
`Too many hops
`Address incomplete
`Ambiguous
`Busy here
`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
`
`413
`414
`415
`
`420
`480
`481
`
`Request, entity too large
`Request, URI too large
`Unsupported media type
`
`Bad extension
`Temporarily not available
`Call leg/transaction does
`not exist
`
`Queued
`Session progress
`OK
`
`Accepted
`Multiple choices
`Moved permanently
`Moved temporarily
`Use proxy
`Alternative service
`Bad request
`Unauthorized
`Payment required
`Forbidden
`Not found
`Method not allowed
`Not acceptable
`Proxy authentication
`Request timeout
`Conflict
`Gone
`
`482
`" 483
`484
`485
`486
`A8T
`488
`500
`501
`502
`503
`504
`505
`600
`603
`604
`606
`
`182
`183
`200
`
`202
`300
`301
`302
`305
`380
`400
`401
`402
`403
`404
`405
`406
`407
`408
`409
`410
`
`Length required
`411
`EE
`Source: Camarillo
`
`
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 673
`
`

`

`1Camarillo, Gonzalo. SIP Demystified. New York: McGraw-Hill, 2002, p. 126-129. AT&T, Exh. 1003, p. 674
`
`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
`
`Conversation
`
`(7) BYE
`
`(8) BYE
`
`(10) 200 OK
`<<
`
`(9) 200 OKgo
`
`
`
`Chapter 5
`
`. =
`SIP call using a proxy
`server
`
`Calller
`
`SIP PROXY
`
`Calllee
`
`(1) Invite
`
`J
`(2) Invite
`
`(3) 200 OK
`(4) 200 OK
`pene ea
`(5) ACK
`(6) ACK
`
`APPENDIX Q
`
`AT&T, Exh. 1003, p. 674
`
`

`

`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