`
`
`
`
`iii l i i i i
`
`DECLARATION OF SANDY GINOZA FOR IETF
`
`RFC 2543: SIP: SESSION INITIATION PROTOCOL
`
`1, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`I am an employee of Association Management Solutions, LLC (AMS), which
`
`acts under contract to the Internet Society (ISOC) as the operator of the RFC Production
`
`Center. The RFC Production Center is part of the "RFC Editor" function, which prepares
`
`documents for pubiication and places files in an online repository for the authoritative
`
`Request for Comments (RFC) series of documents (RFC Series), and preserves records
`
`relating to these documents. The RFC Series includes, among other things, the series of
`
`Internet standards developed by the Internet Engineering Task Force (IETF), an organized
`
`activity of ISOC. I hold the position of Director of the RFC Production Center. I began
`
`employment with AMS in this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, inciuding the creation and maintenance of such records.
`
`3.
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern California (ISI). I held various position titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by ISI under contract to the United
`
`States government prior to 1998. In 1998, ISOC, in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with 181 providing for ISi's performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`Apple Inc.
`EX. 1021 - Page 1
`
`Apple Inc.
`Ex. 1021 - Page 1
`
`

`

`
`
`
`
`
`
`j
`
`saa
`
`ii
`
`iiigii iig ii
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversight Committee). The business records
`
`of the RFC Editor function as it was conducted by ISI are currently housed on the computer
`
`systems of AMS, as contractor to ISOC.
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC was published, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have located it. In particular, the RFCs were indexed and placed in a public repository.
`
`8.
`
`The RFCs are kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performance of its functions.
`
`9.
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`10.
`
`Based on those records, I can state that the publication date of RFC 2543 was
`
`March 1999 (date listed on the RFC), at which time it was reasonably accessible to the public
`
`either on the RFC Editor website or via FTP from a repository. A copy of that RFC is attached
`
`to this declaration as an exhibit.
`
`Apple Inc.
`EX. 1021 - Page 2
`
`Apple Inc.
`Ex. 1021 - Page 2
`
`

`

`5
`E
`
`E
`
`Ii!
`
`
`
`
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of America that the foregoing is true and correct
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`Date:
`
`ll 99“
`
`7f°ifb
`
`By: 533%Ginoza
`
`4845-4040-3825J
`
`ATTACHED CALIF. ACKNOWLEDGMENT
`
`930 “ll {the
`
`Apple Inc.
`Ex. 1021 - Page 3
`
`Apple Inc.
`Ex. 1021 - Page 3
`
`

`

`CIVIL CODE §~1189
`CALIFORNIA ALi.-PURPOSE ACKNOWLEDGMENT
`
`
`A notary public or other officer completing this certificate verifies only the identity of the individuai who signed the
`document to which this certificate is attached, and not the truthfuiness, accuracy, or vaiidity of that document.
`
`)
`State of Catifornla
`,
`
`k
`.
`_
`‘
`)
`County of L05 #tflflflfi
`On 8‘wa lttfigvir before me,
`8 .S - b’ClgfkdlIIU —-» with; while
`
`personally appeared
`mirth}
`@IYW‘ZG
`Namegzjl of Signerhfi
`
`Date
`
`Here insert Name and Title of the Officer
`
`,
`Mz/
`who proved to me on the basis of satisfactory evidence to be the percents) whose ham-sis“) isare
`subs
`ibed to the within instrument and acknowiedg d to me that he s 9 they executed the sa e in
`his/ or their authorized capacityfiéss.) and that b his her their signature
`n the instrument the personlzl',
`or the entity upon behalf of which the personwyacte, executed the instrument.
`l certify under PENALTY OF PERJURY under the laws
`of the State of Catifornia that the foregoing paragraph
`is true and correct.
`
`
`
`
`s,s. DELGADILLO
`_
`--
`_'
`
`Notary Public—California
`f"
`f" ‘
`
`LosAngeles County
`'7 .>
`
`Commissionii2224720
`\ '.
`
`My Comm. Expires Dec9. 2021
`'
`
`
`g
`7
`‘5
`:
`E
`
`WiTNESS my hand and officiai seal.
`
`Signature
`
`Q
`I;
`8 «g .-
`,
`Signature 0
`
`"
`fdle
`.
`otary Public
`
`
`Place Notary Seat Above
`OPTIONAL
`
`Though this section is optional, completing this information can deter alteration of the document or
`fraudulent reattachment of this form to an unintended document.
`
`Description of Attached Document.
`9 5LT
`)7 S “9 5
`Title or Type of Document: I?
`(Mid/I of WW Gil/Wit W IETF 07.190
`Document Date:
`Q I, ‘6“
`Number of Pages: 3
`Signeds) Other Than Named Above: WM
`
`
`
`
`
`{SSIUVI
`
`[Vil’H 5mm
`
`
`
`l
`
`3
`
`9
`
`3
`3
`
`g
`
`E
`
`
`
`Capacitylies) Claimed by Signer(s)
`
`Signer’s Name:
`Signer’s Name:
`El Corporate Officer — Titie(s):
`El Corporate Officer — Titte(s):
`El Partner — El Limited
`[J General
`{Ii Partner m {Ii Limited
`El Generai
`
`El Attorney in Fact
`33 lndividuai
`Cl Attorney in Fact
`[:1 Guardian or Conservator
`IZl Trustee
`El Guardian or Conservator
`
`l3 Other:
`Signer is Representing:
`
`EZI individual
`El Trustee
`El Other:
`Signer is Representing:
`
`
`@2016 NationalNotaryAssociation- www.NationalNotaryorg- 1 —800—US NOTARY (i8008766827)
`item #5907 -
`
`Apple Inc.
`EX. 1021 - Page 4
`
`Apple Inc.
`Ex. 1021 - Page 4
`
`

`

`Network Working Group M. Handley
`Request for Comments: 2543 ACIRI
`Category: Standards Track H. Schulzrinne
` Columbia U.
` E. Schooler
` Cal Tech
` J. Rosenberg
` Bell Labs
` March 1999
`
` SIP: Session Initiation Protocol
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`IESG Note
`
` The IESG intends to charter, in the near future, one or more working
` groups to produce standards for "name lookup", where such names would
` include electronic mail addresses and telephone numbers, and the
` result of such a lookup would be a list of attributes and
` characteristics of the user or terminal associated with the name.
` Groups which are in need of a "name lookup" protocol should follow
` the development of these new working groups rather than using SIP for
` this function. In addition it is anticipated that SIP will migrate
` towards using such protocols, and SIP implementors are advised to
` monitor these efforts.
`
`Abstract
`
` The Session Initiation Protocol (SIP) is an application-layer control
` (signaling) protocol for creating, modifying and terminating sessions
` with one or more participants. These sessions include Internet
` multimedia conferences, Internet telephone calls and multimedia
` distribution. Members in a session can communicate via multicast or
` via a mesh of unicast relations, or a combination of these.
`
`Handley, et al. Standards Track [Page 1]
`
`Apple Inc.
`Ex. 1021 - Page 5
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` SIP invitations used to create sessions carry session descriptions
` which allow participants to agree on a set of compatible media types.
` SIP supports user mobility by proxying and redirecting requests to
` the user’s current location. Users can register their current
` location. SIP is not tied to any particular conference control
` protocol. SIP is designed to be independent of the lower-layer
` transport protocol and can be extended with additional capabilities.
`
`Table of Contents
`
` 1 Introduction ........................................ 7
` 1.1 Overview of SIP Functionality ....................... 7
` 1.2 Terminology ......................................... 8
` 1.3 Definitions ......................................... 9
` 1.4 Overview of SIP Operation ........................... 12
` 1.4.1 SIP Addressing ...................................... 12
` 1.4.2 Locating a SIP Server ............................... 13
` 1.4.3 SIP Transaction ..................................... 14
` 1.4.4 SIP Invitation ...................................... 15
` 1.4.5 Locating a User ..................................... 17
` 1.4.6 Changing an Existing Session ........................ 18
` 1.4.7 Registration Services ............................... 18
` 1.5 Protocol Properties ................................. 18
` 1.5.1 Minimal State ....................................... 18
` 1.5.2 Lower-Layer-Protocol Neutral ........................ 18
` 1.5.3 Text-Based .......................................... 20
` 2 SIP Uniform Resource Locators ....................... 20
` 3 SIP Message Overview ................................ 24
` 4 Request ............................................. 26
` 4.1 Request-Line ........................................ 26
` 4.2 Methods ............................................. 27
` 4.2.1 INVITE .............................................. 28
` 4.2.2 ACK ................................................. 29
` 4.2.3 OPTIONS ............................................. 29
` 4.2.4 BYE ................................................. 30
` 4.2.5 CANCEL .............................................. 30
` 4.2.6 REGISTER ............................................ 31
` 4.3 Request-URI ......................................... 34
` 4.3.1 SIP Version ......................................... 35
` 4.4 Option Tags ......................................... 35
` 4.4.1 Registering New Option Tags with IANA ............... 35
` 5 Response ............................................ 36
` 5.1 Status-Line ......................................... 36
` 5.1.1 Status Codes and Reason Phrases ..................... 37
` 6 Header Field Definitions ............................ 39
` 6.1 General Header Fields ............................... 41
` 6.2 Entity Header Fields ................................ 42
` 6.3 Request Header Fields ............................... 43
`
`Handley, et al. Standards Track [Page 2]
`
`Apple Inc.
`Ex. 1021 - Page 6
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` 6.4 Response Header Fields .............................. 43
` 6.5 End-to-end and Hop-by-hop Headers ................... 43
` 6.6 Header Field Format ................................. 43
` 6.7 Accept .............................................. 44
` 6.8 Accept-Encoding ..................................... 44
` 6.9 Accept-Language ..................................... 45
` 6.10 Allow ............................................... 45
` 6.11 Authorization ....................................... 45
` 6.12 Call-ID ............................................. 46
` 6.13 Contact ............................................. 47
` 6.14 Content-Encoding .................................... 50
` 6.15 Content-Length ...................................... 51
` 6.16 Content-Type ........................................ 51
` 6.17 CSeq ................................................ 52
` 6.18 Date ................................................ 53
` 6.19 Encryption .......................................... 54
` 6.20 Expires ............................................. 55
` 6.21 From ................................................ 56
` 6.22 Hide ................................................ 57
` 6.23 Max-Forwards ........................................ 59
` 6.24 Organization ........................................ 59
` 6.25 Priority ............................................ 60
` 6.26 Proxy-Authenticate .................................. 60
` 6.27 Proxy-Authorization ................................. 61
` 6.28 Proxy-Require ....................................... 61
` 6.29 Record-Route ........................................ 62
` 6.30 Require ............................................. 63
` 6.31 Response-Key ........................................ 63
` 6.32 Retry-After ......................................... 64
` 6.33 Route ............................................... 65
` 6.34 Server .............................................. 65
` 6.35 Subject ............................................. 65
` 6.36 Timestamp ........................................... 66
` 6.37 To .................................................. 66
` 6.38 Unsupported ......................................... 68
` 6.39 User-Agent .......................................... 68
` 6.40 Via ................................................. 68
` 6.40.1 Requests ............................................ 68
` 6.40.2 Receiver-tagged Via Header Fields ................... 69
` 6.40.3 Responses ........................................... 70
` 6.40.4 User Agent and Redirect Servers ..................... 70
` 6.40.5 Syntax .............................................. 71
` 6.41 Warning ............................................. 72
` 6.42 WWW-Authenticate .................................... 74
` 7 Status Code Definitions ............................. 75
` 7.1 Informational 1xx ................................... 75
` 7.1.1 100 Trying .......................................... 75
` 7.1.2 180 Ringing ......................................... 75
`
`Handley, et al. Standards Track [Page 3]
`
`Apple Inc.
`Ex. 1021 - Page 7
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` 7.1.3 181 Call Is Being Forwarded ......................... 75
` 7.1.4 182 Queued .......................................... 76
` 7.2 Successful 2xx ...................................... 76
` 7.2.1 200 OK .............................................. 76
` 7.3 Redirection 3xx ..................................... 76
` 7.3.1 300 Multiple Choices ................................ 77
` 7.3.2 301 Moved Permanently ............................... 77
` 7.3.3 302 Moved Temporarily ............................... 77
` 7.3.4 305 Use Proxy ....................................... 77
` 7.3.5 380 Alternative Service ............................. 78
` 7.4 Request Failure 4xx ................................. 78
` 7.4.1 400 Bad Request ..................................... 78
` 7.4.2 401 Unauthorized .................................... 78
` 7.4.3 402 Payment Required ................................ 78
` 7.4.4 403 Forbidden ....................................... 78
` 7.4.5 404 Not Found ....................................... 78
` 7.4.6 405 Method Not Allowed .............................. 78
` 7.4.7 406 Not Acceptable .................................. 79
` 7.4.8 407 Proxy Authentication Required ................... 79
` 7.4.9 408 Request Timeout ................................. 79
` 7.4.10 409 Conflict ........................................ 79
` 7.4.11 410 Gone ............................................ 79
` 7.4.12 411 Length Required ................................. 79
` 7.4.13 413 Request Entity Too Large ........................ 80
` 7.4.14 414 Request-URI Too Long ............................ 80
` 7.4.15 415 Unsupported Media Type .......................... 80
` 7.4.16 420 Bad Extension ................................... 80
` 7.4.17 480 Temporarily Unavailable ......................... 80
` 7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
` 7.4.19 482 Loop Detected ................................... 81
` 7.4.20 483 Too Many Hops ................................... 81
` 7.4.21 484 Address Incomplete .............................. 81
` 7.4.22 485 Ambiguous ....................................... 81
` 7.4.23 486 Busy Here ....................................... 82
` 7.5 Server Failure 5xx .................................. 82
` 7.5.1 500 Server Internal Error ........................... 82
` 7.5.2 501 Not Implemented ................................. 82
` 7.5.3 502 Bad Gateway ..................................... 82
` 7.5.4 503 Service Unavailable ............................. 83
` 7.5.5 504 Gateway Time-out ................................ 83
` 7.5.6 505 Version Not Supported ........................... 83
` 7.6 Global Failures 6xx ................................. 83
` 7.6.1 600 Busy Everywhere ................................. 83
` 7.6.2 603 Decline ......................................... 84
` 7.6.3 604 Does Not Exist Anywhere ......................... 84
` 7.6.4 606 Not Acceptable .................................. 84
` 8 SIP Message Body .................................... 84
` 8.1 Body Inclusion ...................................... 84
`
`Handley, et al. Standards Track [Page 4]
`
`Apple Inc.
`Ex. 1021 - Page 8
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` 8.2 Message Body Type ................................... 85
` 8.3 Message Body Length ................................. 85
` 9 Compact Form ........................................ 85
` 10 Behavior of SIP Clients and Servers ................. 86
` 10.1 General Remarks ..................................... 86
` 10.1.1 Requests ............................................ 86
` 10.1.2 Responses ........................................... 87
` 10.2 Source Addresses, Destination Addresses and
` Connections ......................................... 88
` 10.2.1 Unicast UDP ......................................... 88
` 10.2.2 Multicast UDP ....................................... 88
` 10.3 TCP ................................................. 89
` 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
` Requests ............................................ 90
` 10.4.1 UDP ................................................. 90
` 10.4.2 TCP ................................................. 91
` 10.5 Reliability for INVITE Requests ..................... 91
` 10.5.1 UDP ................................................. 92
` 10.5.2 TCP ................................................. 95
` 10.6 Reliability for ACK Requests ........................ 95
` 10.7 ICMP Handling ....................................... 95
` 11 Behavior of SIP User Agents ......................... 95
` 11.1 Caller Issues Initial INVITE Request ................ 96
` 11.2 Callee Issues Response .............................. 96
` 11.3 Caller Receives Response to Initial Request ......... 96
` 11.4 Caller or Callee Generate Subsequent Requests ....... 97
` 11.5 Receiving Subsequent Requests ....................... 97
` 12 Behavior of SIP Proxy and Redirect Servers .......... 97
` 12.1 Redirect Server ..................................... 97
` 12.2 User Agent Server ................................... 98
` 12.3 Proxy Server ........................................ 98
` 12.3.1 Proxying Requests ................................... 98
` 12.3.2 Proxying Responses .................................. 99
` 12.3.3 Stateless Proxy: Proxying Responses ................. 99
` 12.3.4 Stateful Proxy: Receiving Requests .................. 99
` 12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
` 12.3.6 Stateful Proxy: Receiving Responses ................. 100
` 12.3.7 Stateless, Non-Forking Proxy ........................ 100
` 12.4 Forking Proxy ....................................... 100
` 13 Security Considerations ............................. 104
` 13.1 Confidentiality and Privacy: Encryption ............. 104
` 13.1.1 End-to-End Encryption ............................... 104
` 13.1.2 Privacy of SIP Responses ............................ 107
` 13.1.3 Encryption by Proxies ............................... 108
` 13.1.4 Hop-by-Hop Encryption ............................... 108
` 13.1.5 Via field encryption ................................ 108
` 13.2 Message Integrity and Access Control:
` Authentication ...................................... 109
`
`Handley, et al. Standards Track [Page 5]
`
`Apple Inc.
`Ex. 1021 - Page 9
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` 13.2.1 Trusting responses .................................. 112
` 13.3 Callee Privacy ...................................... 113
` 13.4 Known Security Problems ............................. 113
` 14 SIP Authentication using HTTP Basic and Digest
` Schemes ............................................. 113
` 14.1 Framework ........................................... 113
` 14.2 Basic Authentication ................................ 114
` 14.3 Digest Authentication ............................... 114
` 14.4 Proxy-Authentication ................................ 115
` 15 SIP Security Using PGP .............................. 115
` 15.1 PGP Authentication Scheme ........................... 115
` 15.1.1 The WWW-Authenticate Response Header ................ 116
` 15.1.2 The Authorization Request Header .................... 117
` 15.2 PGP Encryption Scheme ............................... 118
` 15.3 Response-Key Header Field for PGP ................... 119
` 16 Examples ............................................ 119
` 16.1 Registration ........................................ 119
` 16.2 Invitation to a Multicast Conference ................ 121
` 16.2.1 Request ............................................. 121
` 16.2.2 Response ............................................ 122
` 16.3 Two-party Call ...................................... 123
` 16.4 Terminating a Call .................................. 125
` 16.5 Forking Proxy ....................................... 126
` 16.6 Redirects ........................................... 130
` 16.7 Negotiation ......................................... 131
` 16.8 OPTIONS Request ..................................... 132
` A Minimal Implementation .............................. 134
` A.1 Client .............................................. 134
` A.2 Server .............................................. 135
` A.3 Header Processing ................................... 135
` B Usage of the Session Description Protocol (SDP)...... 136
` B.1 Configuring Media Streams ........................... 136
` B.2 Setting SDP Values for Unicast ...................... 138
` B.3 Multicast Operation ................................. 139
` B.4 Delayed Media Streams ............................... 139
` B.5 Putting Media Streams on Hold ....................... 139
` B.6 Subject and SDP "s=" Line ........................... 140
` B.7 The SDP "o=" Line ................................... 140
` C Summary of Augmented BNF ............................ 141
` C.1 Basic Rules ......................................... 143
` D Using SRV DNS Records ............................... 146
` E IANA Considerations ................................. 148
` F Acknowledgments ..................................... 149
` G Authors’ Addresses .................................. 149
` H Bibliography ........................................ 150
` I Full Copyright Statement ............................ 153
`
`Handley, et al. Standards Track [Page 6]
`
`Apple Inc.
`Ex. 1021 - Page 10
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
`1 Introduction
`
`1.1 Overview of SIP Functionality
`
` The Session Initiation Protocol (SIP) is an application-layer control
` protocol that can establish, modify and terminate multimedia sessions
` or calls. These multimedia sessions include multimedia conferences,
` distance learning, Internet telephony and similar applications. SIP
` can invite both persons and "robots", such as a media storage
` service. SIP can invite parties to both unicast and multicast
` sessions; the initiator does not necessarily have to be a member of
` the session to which it is inviting. Media and participants can be
` added to an existing session.
`
` SIP can be used to initiate sessions as well as invite members to
` sessions that have been advertised and established by other means.
` Sessions can be advertised using multicast protocols such as SAP,
` electronic mail, news groups, web pages or directories (LDAP), among
` others.
`
` SIP transparently supports name mapping and redirection services,
` allowing the implementation of ISDN and Intelligent Network telephony
` subscriber services. These facilities also enable personal mobility.
` In the parlance of telecommunications intelligent network services,
` this is defined as: "Personal mobility is the ability of end users to
` originate and receive calls and access subscribed telecommunication
` services on any terminal in any location, and the ability of the
` network to identify end users as they move. Personal mobility is
` based on the use of a unique personal identity (i.e., personal
` number)." [1]. Personal mobility complements terminal mobility, i.e.,
` the ability to maintain communications when moving a single end
` system from one subnet to another.
`
` SIP supports five facets of establishing and terminating multimedia
` communications:
`
` User location: determination of the end system to be used for
` communication;
`
` User capabilities: determination of the media and media parameters to
` be used;
`
` User availability: determination of the willingness of the called
` party to engage in communications;
`
` Call setup: "ringing", establishment of call parameters at both
` called and calling party;
`
`Handley, et al. Standards Track [Page 7]
`
`Apple Inc.
`Ex. 1021 - Page 11
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` Call handling: including transfer and termination of calls.
`
` SIP can also initiate multi-party calls using a multipoint control
` unit (MCU) or fully-meshed interconnection instead of multicast.
` Internet telephony gateways that connect Public Switched Telephone
` Network (PSTN) parties can also use SIP to set up calls between them.
`
` SIP is designed as part of the overall IETF multimedia data and
` control architecture currently incorporating protocols such as RSVP
` (RFC 2205 [2]) for reserving network resources, the real-time
` transport protocol (RTP) (RFC 1889 [3]) for transporting real-time
` data and providing QOS feedback, the real-time streaming protocol
` (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media,
` the session announcement protocol (SAP) [5] for advertising
` multimedia sessions via multicast and the session description
` protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions.
` However, the functionality and operation of SIP does not depend on
` any of these protocols.
`
` SIP can also be used in conjunction with other call setup and
` signaling protocols. In that mode, an end system uses SIP exchanges
` to determine the appropriate end system address and protocol from a
` given address that is protocol-independent. For example, SIP could be
` used to determine that the party can be reached via H.323 [7], obtain
` the H.245 [8] gateway and user address and then use H.225.0 [9] to
` establish the call.
`
` In another example, SIP might be used to determine that the callee is
` reachable via the PSTN and indicate the phone number to be called,
` possibly suggesting an Internet-to-PSTN gateway to be used.
`
` SIP does not offer conference control services such as floor control
` or voting and does not prescribe how a conference is to be managed,
` but SIP can be used to introduce conference control protocols. SIP
` does not allocate multicast addresses.
`
` SIP can invite users to sessions with and without resource
` reservation. SIP does not reserve resources, but can convey to the
` invited system the information necessary to do this.
`
`1.2 Terminology
`
` In this document, the key words "MUST", "MUST NOT", "REQUIRED",
` "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
` and "OPTIONAL" are to be interpreted as described in RFC 2119 [10]
` and indicate requirement levels for compliant SIP implementations.
`
`Handley, et al. Standards Track [Page 8]
`
`Apple Inc.
`Ex. 1021 - Page 12
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
`1.3 Definitions
`
` This specification uses a number of terms to refer to the roles
` played by participants in SIP communications. The definitions of
` client, server and proxy are similar to those used by the Hypertext
` Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic
` syntax of URI and URL are defined in RFC 2396 [12]. The following
` terms have special significance for SIP.
`
` Call: A call consists of all participants in a conference invited by
` a common source. A SIP call is identified by