Network Working Group
`Request for Comments: 2543
`Category: Standards Track
`
`M. Handley
`ACIRI
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 1
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 2
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 3
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 4
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 5
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 6
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 7
`
`

`

`
`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]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 8
`
`

`

`
`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 a globally unique
` call-id (Section 6.12). Thus, if a user is, for example, invited
` to the same multicast session by several people, each of these
` invitations will be a unique call. A point-to-point Internet
` telephony conversation maps into a single SIP call. In a
` multiparty conference unit (MCU) based call-in conference, each
` participant uses a separate call to invite himself to the MCU.
`
` Call leg: A call leg is identified by the combination of Call-ID, To
` and From.
`
` Client: An application program that sends SIP requests. Clients may
` or may not interact directly with a human user. User agents and
` proxies contain clients (and servers).
`
` Conference: A multimedia session (see below), identified by a common
` session description. A conference can have zero or more members
` and includes the cases of a multicast conference, a full-mesh
` conference and a two-party "telephone call", as well as
` combinations of these. Any number of calls can be used to
` create a conference.
`
` Downstream: Requests sent in the direction from the caller to the
` callee (i.e., user agent client to user agent server).
`
` Final response: A response that terminates a SIP transaction, as
` opposed to a provisional response that does not. All 2xx, 3xx,
` 4xx, 5xx and 6xx responses are final.
`
` Initiator, calling party, caller: The party initiating a conference
` invitation. Note that the calling party does not have to be the
` same as the one creating the conference.
`
` Invitation: A request sent to a user (or service) requesting
` participation in a session. A successful SIP invitation consists
` of two transactions: an INVITE request followed by an ACK
` request.
`
`Handley, et al. Standards Track [Page 9]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 9
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` Invitee, invited user, called party, callee: The person or service
` that the calling party is trying to invite to a conference.
`
` Isomorphic request or response: Two requests or responses are defined
` to be isomorphic for the purposes of this document if they have
` the same values for the Call-ID, To, From and CSeq header
` fields. In addition, isomorphic requests have to have the same
` Request-URI.
`
` Location server: See location service.
`
` Location service: A location service is used by a SIP redirect or
` proxy server to obtain information about a callee’s possible
` location(s). Location services are offered by location servers.
` Location servers MAY be co-located with a SIP server, but the
` manner in which a SIP server requests location services is
` beyond the scope of this document.
`
` Parallel search: In a parallel search, a proxy issues several
` requests to possible user locations upon receiving an incoming
` request. Rather than issuing one request and then waiting for
` the final response before issuing the next request as in a
` sequential search , a parallel search issues requests without
` waiting for the result of previous requests.
`
` Provisional response: A response used by the server to indicate
` progress, but that does not terminate a SIP transaction. 1xx
` responses are provisional, other responses are considered final.
`
` Proxy, proxy server: An intermediary program that acts as both a
` server and a client for the purpose of making requests on behalf
` of other clients. Requests are serviced internally or by passing
` them on, possibly after translation, to other servers. A proxy
` interprets, and, if necessary, rewrites a request message before
` forwarding it.
`
` Redirect server: A redirect server is a server that accepts a SIP
` request, maps the address into zero or more new addresses and
` returns these addresses to the client. Unlike a proxy server ,
` it does not initiate its own SIP request. Unlike a user agent
` server , it does not accept calls.
`
` Registrar: A registrar is a server that accepts REGISTER requests. A
` registrar is typically co-located with a proxy or redirect
` server and MAY offer location services.
`
`Handley, et al. Standards Track [Page 10]
`
`IPR2018-00884
`Apple Inc. EX1009 Page 10
`
`

`

`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` Ringback: Ringback is the signaling tone produced by the calling
` client’s application indicating that a called party is being
` alerted (ringing).
`
` Server: A server is an application program that accepts requests in
` order to service requests and sends back responses to those
` requests. Servers are either proxy, redirect or user agent
` servers or registrars.
`
` Session: From the SDP specification: "A multimedia session is a set
` of multimedia senders and receivers and the data streams flowing
` from senders to receivers. A multimedia conference is an example
` of a multimedia session." (RFC 2327 [6]) (A session as defined
` for SDP can comprise one or more RTP sessions.) As defined, a
` callee can be invited several times, by different calls, to the
` same session. If SDP is used, a session is defined by the
` concatenation of the user name , session id , network type ,
` address type and address elements in the origin field.
`
` (SIP) transaction: A SIP transaction occurs between a client and a
` server and comprises all messages from the first request sent
` from the client to the server up to a final (non-1xx) response
` sent from the server to the client. A transaction is identified
` by the CSeq sequence number (Section 6.17) within a single call
` leg. The ACK request has the same CSeq number as the
` corresponding INVITE request, but comprises a transaction of its
` own.
`
` Upstream: Responses sent in the direction from the user agent server
` to the user agent client.
`
` URL-encoded: A character string encoded according to RFC 1738,
` Section 2.2 [13].
`
` User agent client (UAC), calling user agent: A user agent client is a
` client application that initiates the SIP request.
`
` User agent server (UAS), called user agent: A user agent server is a
` server application that contacts the user when a SIP request is
` received and that returns a response on behalf of the user. The
` response accepts, rejects or redirects the request.
`
` User agent (UA): An application which contains both a user agent
` client and user agent server.
`
` An application program MAY be capable of acting both as a client and
` a server. For example, a typical multimedia conference control
` application would act as a user agent client to initiate calls or to
`
`Handley, et al. Standards Track [Page 11]
`
`IPR2018-00884
`Apple Inc. EX1009 Pa