`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 1007
`
`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 ........................................
`1.1 Overview of SIP Functionality .......................
`1.2 Terminology .........................................
`1.3 Definitions .........................................
`1.4 Overview of SIP Operation ...........................
`1.4.1 SIP Addressing ......................................
`1.4.2 Locating a SIP Server ...............................
`1.4.3 SIP Transaction .....................................
`1.4.4 SIP Invitation ......................................
`1.4.5 Locating a User .....................................
`1.4.6 Changing an Existing Session ........................
`1.4.7 Registration Services ...............................
`1.5 Protocol Properties .................................
`1.5.1 Minimal State .......................................
`1.5.2 Lower-Layer-Protocol Neutral ........................
`1.5.3 Text-Based ..........................................
`2 SIP Uniform Resource Locators .......................
`3 SIP Message Overview ................................
`4 Request .............................................
`4.1 Request-Line ........................................
`4.2 Methods .............................................
`4.2.1 INVITE ..............................................
`4.2.2 ACK .................................................
`4.2.3 OPTIONS .............................................
`4.2.4 BYE .................................................
`4.2.5 CANCEL ..............................................
`4.2.6 REGISTER ............................................
`4.3 Request-URI .........................................
`4.3.1 SIP Version .........................................
`4.4 Option Tags .........................................
`4.4.1 Registering New Option Tags with IANA ...............
`5 Response ............................................
`5.1 Status-Line .........................................
`5.1.1 Status Codes and Reason Phrases .....................
`6 Header Field Definitions ............................
`6.1 General Header Fields ...............................
`6.2 Entity Header Fields ................................
`6.3 Request Header Fields ...............................
`
`7
`7
`8
`9
`12
`12
`13
`14
`15
`17
`18
`18
`18
`18
`18
`20
`20
`24
`26
`26
`27
`28
`29
`29
`30
`30
`31
`34
`35
`35
`35
`36
`36
`37
`39
`41
`42
`43
`
`Handley, et al. Standards Track [Page 2]
`
`2
`
`
`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
`6.4 Response Header Fields ..............................
`6.5 End-to-end and Hop-by-hop Headers ...................
`6.6 Header Field Format .................................
`6.7 Accept ..............................................
`6.8 Accept-Encoding .....................................
`6.9 Accept-Language .....................................
`6.10 Allow ...............................................
`6.11 Authorization .......................................
`6.12 Call-ID .............................................
`6.13 Contact .............................................
`6.14 Content-Encoding ....................................
`6.15 Content-Length ......................................
`6.16 Content-Type ........................................
`6.17 CSeq ................................................
`6.18 Date ................................................
`6.19 Encryption ..........................................
`6.20 Expires .............................................
`6.21 From ................................................
`6.22 Hide ................................................
`6.23 Max-Forwards ........................................
`6.24 Organization ........................................
`6.25 Priority ............................................
`6.26 Proxy-Authenticate ..................................
`6.27 Proxy-Authorization .................................
`6.28 Proxy-Require .......................................
`6.29 Record-Route ........................................
`6.30 Require .............................................
`6.31 Response-Key ........................................
`6.32 Retry-After .........................................
`6.33 Route ...............................................
`6.34 Server ..............................................
`6.35 Subject .............................................
`6.36 Timestamp ...........................................
`6.37 To ..................................................
`6.38 Unsupported .........................................
`6.39 User-Agent ..........................................
`6.40 Via .................................................
`6.40.1 Requests ............................................
`6.40.2 Receiver-tagged Via Header Fields ...................
`6.40.3 Responses ...........................................
`6.40.4 User Agent and Redirect Servers .....................
`6.40.5 Syntax ..............................................
`6.41 Warning .............................................
`6.42 WWW-Authenticate ....................................
`7 Status Code Definitions .............................
`7.1 Informational 1xx ...................................
`7.1.1 100 Trying ..........................................
`7.1.2 180 Ringing .........................................
`
`43
`43
`43
`44
`44
`45
`45
`45
`46
`47
`50
`51
`51
`52
`53
`54
`55
`56
`57
`59
`59
`60
`60
`61
`61
`62
`63
`63
`64
`65
`65
`65
`66
`66
`68
`68
`68
`68
`69
`70
`70
`71
`72
`74
`75
`75
`75
`75
`
`Handley, et al. Standards Track [Page 3]
`
`3
`
`
`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
`7.1.3 181 Call Is Being Forwarded .........................
`7.1.4 182 Queued ..........................................
`7.2 Successful 2xx ......................................
`7.2.1 200 OK ..............................................
`7.3 Redirection 3xx .....................................
`7.3.1 300 Multiple Choices ................................
`7.3.2 301 Moved Permanently ...............................
`7.3.3 302 Moved Temporarily ...............................
`7.3.4 305 Use Proxy .......................................
`7.3.5 380 Alternative Service .............................
`7.4 Request Failure 4xx .................................
`7.4.1 400 Bad Request .....................................
`7.4.2 401 Unauthorized ....................................
`7.4.3 402 Payment Required ................................
`7.4.4 403 Forbidden .......................................
`7.4.5 404 Not Found .......................................
`7.4.6 405 Method Not Allowed ..............................
`7.4.7 406 Not Acceptable ..................................
`7.4.8 407 Proxy Authentication Required ...................
`7.4.9 408 Request Timeout .................................
`7.4.10 409 Conflict ........................................
`7.4.11 410 Gone ............................................
`7.4.12 411 Length Required .................................
`7.4.13 413 Request Entity Too Large ........................
`7.4.14 414 Request-URI Too Long ............................
`7.4.15 415 Unsupported Media Type ..........................
`7.4.16 420 Bad Extension ...................................
`7.4.17 480 Temporarily Unavailable .........................
`7.4.18 481 Call Leg/Transaction Does Not Exist .............
`7.4.19 482 Loop Detected ...................................
`7.4.20 483 Too Many Hops ...................................
`7.4.21 484 Address Incomplete ..............................
`7.4.22 485 Ambiguous .......................................
`7.4.23 486 Busy Here .......................................
`7.5 Server Failure 5xx ..................................
`7.5.1 500 Server Internal Error ...........................
`7.5.2 501 Not Implemented .................................
`7.5.3 502 Bad Gateway .....................................
`7.5.4 503 Service Unavailable .............................
`7.5.5 504 Gateway Time-out ................................
`7.5.6 505 Version Not Supported ...........................
`7.6 Global Failures 6xx .................................
`7.6.1 600 Busy Everywhere .................................
`7.6.2 603 Decline .........................................
`7.6.3 604 Does Not Exist Anywhere .........................
`7.6.4 606 Not Acceptable ..................................
`8 SIP Message Body ....................................
`8.1 Body Inclusion ......................................
`
`75
`76
`76
`76
`76
`77
`77
`77
`77
`78
`78
`78
`78
`78
`78
`78
`78
`79
`79
`79
`79
`79
`79
`80
`80
`80
`80
`80
`81
`81
`81
`81
`81
`82
`82
`82
`82
`82
`83
`83
`83
`83
`83
`84
`84
`84
`84
`84
`
`Handley, et al. Standards Track [Page 4]
`
`4
`
`
`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
`88
`88
`88
`89
`
`85
`85
`85
`86
`86
`86
`87
`
`8.2 Message Body Type ...................................
`8.3 Message Body Length .................................
`9 Compact Form ........................................
`10 Behavior of SIP Clients and Servers .................
`10.1 General Remarks .....................................
`10.1.1 Requests ............................................
`10.1.2 Responses ...........................................
` 10.2 Source Addresses, Destination Addresses and
` Connections .........................................
`10.2.1 Unicast UDP .........................................
`10.2.2 Multicast UDP .......................................
`10.3 TCP .................................................
` 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
`90
` Requests ............................................
`90
`10.4.1 UDP .................................................
`91
`10.4.2 TCP .................................................
`91
`10.5 Reliability for INVITE Requests .....................
`92
`10.5.1 UDP .................................................
`95
`10.5.2 TCP .................................................
`95
`10.6 Reliability for ACK Requests ........................
`95
`10.7 ICMP Handling .......................................
`95
`11 Behavior of SIP User Agents .........................
`96
`11.1 Caller Issues Initial INVITE Request ................
`96
`11.2 Callee Issues Response ..............................
`96
`11.3 Caller Receives Response to Initial Request .........
`97
`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 .....................................
`98
`12.2 User Agent Server ...................................
`98
`12.3 Proxy Server ........................................
`98
`12.3.1 Proxying Requests ...................................
`99
`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 ......................
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`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]
`
`11
`
`
`
`RFC 2543 SIP: Session Initiation Protocol March 1999
`
` invite others to conferences and as a user agent server to accept
` invitations. The properties of the different SIP server types are
` summarized in Table 1.
`
` property redirect proxy user agent registrar
` server server server
` __________________________________________________________________
` also acts as a SIP client no yes no no
` returns 1xx status yes yes yes yes
` returns 2xx status no yes yes yes
` returns 3xx status yes yes yes yes
` returns 4xx status yes yes yes yes
` returns 5xx status yes yes yes yes
` returns 6xx status no yes yes yes
` inserts