From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2543.txt | 8564 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 8564 insertions(+) create mode 100644 doc/rfc/rfc2543.txt (limited to 'doc/rfc/rfc2543.txt') diff --git a/doc/rfc/rfc2543.txt b/doc/rfc/rfc2543.txt new file mode 100644 index 0000000..fb9d785 --- /dev/null +++ b/doc/rfc/rfc2543.txt @@ -0,0 +1,8564 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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 Via header no yes no no + accepts ACK yes yes yes no + + + Table 1: Properties of the different SIP server types + + +1.4 Overview of SIP Operation + + This section explains the basic protocol functionality and operation. + Callers and callees are identified by SIP addresses, described in + Section 1.4.1. When making a SIP call, a caller first locates the + appropriate server (Section 1.4.2) and then sends a SIP request + (Section 1.4.3). The most common SIP operation is the invitation + (Section 1.4.4). Instead of directly reaching the intended callee, a + SIP request may be redirected or may trigger a chain of new SIP + requests by proxies (Section 1.4.5). Users can register their + location(s) with SIP servers (Section 4.2.6). + +1.4.1 SIP Addressing + + The "objects" addressed by SIP are users at hosts, identified by a + SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, + i.e., user@host. The user part is a user name or a telephone number. + The host part is either a domain name or a numeric network address. + See section 2 for a detailed discussion of SIP URL's. + + A user's SIP address can be obtained out-of-band, can be learned via + existing media agents, can be included in some mailers' message + headers, or can be recorded during previous invitation interactions. + In many cases, a user's SIP URL can be guessed from their email + address. + + + + +Handley, et al. Standards Track [Page 12] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + A SIP URL address can designate an individual (possibly located at + one of several end systems), the first available person from a group + of individuals or a whole group. The form of the address, for + example, sip:sales@example.com , is not sufficient, in general, to + determine the intent of the caller. + + If a user or service chooses to be reachable at an address that is + guessable from the person's name and organizational affiliation, the + traditional method of ensuring privacy by having an unlisted "phone" + number is compromised. However, unlike traditional telephony, SIP + offers authentication and access control mechanisms and can avail + itself of lower-layer security mechanisms, so that client software + can reject unauthorized or undesired call attempts. + +1.4.2 Locating a SIP Server + + When a client wishes to send a request, the client either sends it to + a locally configured SIP proxy server (as in HTTP), independent of + the Request-URI, or sends it to the IP address and port corresponding + to the Request-URI. + + For the latter case, the client must determine the protocol, port and + IP address of a server to which to send the request. A client SHOULD + follow the steps below to obtain this information, but MAY follow the + alternative, optional procedure defined in Appendix D. At each step, + unless stated otherwise, the client SHOULD try to contact a server at + the port number listed in the Request-URI. If no port number is + present in the Request-URI, the client uses port 5060. If the + Request-URI specifies a protocol (TCP or UDP), the client contacts + the server using that protocol. If no protocol is specified, the + client tries UDP (if UDP is supported). If the attempt fails, or if + the client doesn't support UDP but supports TCP, it then tries TCP. + + A client SHOULD be able to interpret explicit network notifications + (such as ICMP messages) which indicate that a server is not + reachable, rather than relying solely on timeouts. (For socket-based + programs: For TCP, connect() returns ECONNREFUSED if the client could + not connect to a server at that address. For UDP, the socket needs to + be bound to the destination address using connect() rather than + sendto() or similar so that a second write() fails with ECONNREFUSED + if there is no server listening) If the client finds the server is + not reachable at a particular address, it SHOULD behave as if it had + received a 400-class error response to that request. + + The client tries to find one or more addresses for the SIP server by + querying DNS. The procedure is as follows: + + + + + +Handley, et al. Standards Track [Page 13] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 1. If the host portion of the Request-URI is an IP address, + the client contacts the server at the given address. + Otherwise, the client proceeds to the next step. + + 2. The client queries the DNS server for address records for + the host portion of the Request-URI. If the DNS server + returns no address records, the client stops, as it has + been unable to locate a server. By address record, we mean + A RR's, AAAA RR's, or other similar address records, chosen + according to the client's network protocol capabilities. + + + There are no mandatory rules on how to select a host name + for a SIP server. Users are encouraged to name their SIP + servers using the sip.domainname (i.e., sip.example.com) + convention, as specified in RFC 2219 [16]. Users may only + know an email address instead of a full SIP URL for a + callee, however. In that case, implementations may be able + to increase the likelihood of reaching a SIP server for + that domain by constructing a SIP URL from that email + address by prefixing the host name with "sip.". In the + future, this mechanism is likely to become unnecessary as + better DNS techniques, such as the one in Appendix D, + become widely available. + + A client MAY cache a successful DNS query result. A successful query + is one which contained records in the answer, and a server was + contacted at one of the addresses from the answer. When the client + wishes to send a request to the same host, it MUST start the search + as if it had just received this answer from the name server. The + client MUST follow the procedures in RFC1035 [15] regarding DNS cache + invalidation when the DNS time-to-live expires. + +1.4.3 SIP Transaction + + Once the host part has been resolved to a SIP server, the client + sends one or more SIP requests to that server and receives one or + more responses from the server. A request (and its retransmissions) + together with the responses triggered by that request make up a SIP + transaction. All responses to a request contain the same values in + the Call-ID, CSeq, To, and From fields (with the possible addition of + a tag in the To field (section 6.37)). This allows responses to be + matched with requests. The ACK request following an INVITE is not + part of the transaction since it may traverse a different set of + hosts. + + + + + + +Handley, et al. Standards Track [Page 14] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + If TCP is used, request and responses within a single SIP transaction + are carried over the same TCP connection (see Section 10). Several + SIP requests from the same client to the same server MAY use the same + TCP connection or MAY use a new connection for each request. + + If the client sent the request via unicast UDP, the response is sent + to the address contained in the next Via header field (Section 6.40) + of the response. If the request is sent via multicast UDP, the + response is directed to the same multicast address and destination + port. For UDP, reliability is achieved using retransmission (Section + 10). + + The SIP message format and operation is independent of the transport + protocol. + +1.4.4 SIP Invitation + + A successful SIP invitation consists of two requests, INVITE followed + by ACK. The INVITE (Section 4.2.1) request asks the callee to join a + particular conference or establish a two-party conversation. After + the callee has agreed to participate in the call, the caller confirms + that it has received that response by sending an ACK (Section 4.2.2) + request. If the caller no longer wants to participate in the call, it + sends a BYE request instead of an ACK. + + The INVITE request typically contains a session description, for + example written in SDP (RFC 2327 [6]) format, that provides the + called party with enough information to join the session. For + multicast sessions, the session description enumerates the media + types and formats that are allowed to be distributed to that session. + For a unicast session, the session description enumerates the media + types and formats that the caller is willing to use and where it + wishes the media data to be sent. In either case, if the callee + wishes to accept the call, it responds to the invitation by returning + a similar description listing the media it wishes to use. For a + multicast session, the callee SHOULD only return a session + description if it is unable to receive the media indicated in the + caller's description or wants to receive data via unicast. + + The protocol exchanges for the INVITE method are shown in Fig. 1 for + a proxy server and in Fig. 2 for a redirect server. (Note that the + messages shown in the figures have been abbreviated slightly.) In + Fig. 1, the proxy server accepts the INVITE request (step 1), + contacts the location service with all or parts of the address (step + 2) and obtains a more precise location (step 3). The proxy server + then issues a SIP INVITE request to the address(es) returned by the + location service (step 4). The user agent server alerts the user + (step 5) and returns a success indication to the proxy server (step + + + +Handley, et al. Standards Track [Page 15] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 6). The proxy server then returns the success result to the original + caller (step 7). The receipt of this message is confirmed by the + caller using an ACK request, which is forwarded to the callee (steps + 8 and 9). Note that an ACK can also be sent directly to the callee, + bypassing the proxy. All requests and responses have the same Call- + ID. + + + + + + +....... cs.columbia.edu .......+ + : : + : (~~~~~~~~~~) : + : ( location ) : + : ( service ) : + : (~~~~~~~~~~) : + : ^ | : + : | hgs@lab : + : 2| 3| : + : | | : + : henning | : ++.. cs.tu-berlin.de ..+ 1: INVITE : | | : +: : henning@cs.col: | \/ 4: INVITE 5: ring : +: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) : +: <........................( )<.........( ) : +: : 7: 200 OK : ( )6: 200 OK ( ) : +: : : ( work ) ( lab ) : +: : 8: ACK : ( )9: ACK ( ) : +: ========================>(~~~~~~)=========>(~~~~~~) : ++.....................+ +...............................+ + + ====> SIP request + ....> SIP response + + ^ + | non-SIP protocols + | + + + Figure 1: Example of SIP proxy server + + + + The redirect server shown in Fig. 2 accepts the INVITE request (step + 1), contacts the location service as before (steps 2 and 3) and, + instead of contacting the newly found address itself, returns the + address to the caller (step 4), which is then acknowledged via an ACK + + + +Handley, et al. Standards Track [Page 16] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + request (step 5). The caller issues a new request, with the same + call-ID but a higher CSeq, to the address returned by the first + server (step 6). In the example, the call succeeds (step 7). The + caller and callee complete the handshake with an ACK (step 8). + + + The next section discusses what happens if the location service + returns more than one possible alternative. + +1.4.5 Locating a User + + A callee may move between a number of different end systems over + time. These locations can be dynamically registered with the SIP + server (Sections 1.4.7, 4.2.6). A location server MAY also use one or + more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC + 2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or + operating-system dependent mechanisms to actively determine the end + system where a user might be reachable. A location server MAY return + several locations because the user is logged in at several hosts + simultaneously or because the location server has (temporarily) + inaccurate information. The SIP server combines the results to yield + a list of a zero or more locations. + + The action taken on receiving a list of locations varies with the + type of SIP server. A SIP redirect server returns the list to the + client as Contact headers (Section 6.13). A SIP proxy server can + sequentially or in parallel try the addresses until the call is + successful (2xx response) or the callee has declined the call (6xx + response). With sequential attempts, a proxy server can implement an + "anycast" service. + + If a proxy server forwards a SIP request, it MUST add itself to the + beginning of the list of forwarders noted in the Via (Section 6.40) + headers. The Via trace ensures that replies can take the same path + back, ensuring correct operation through compliant firewalls and + avoiding request loops. On the response path, each host MUST remove + its Via, so that routing internal information is hidden from the + callee and outside networks. A proxy server MUST check that it does + not generate a request to a host listed in the Via sent-by, via- + received or via-maddr parameters (Section 6.40). (Note: If a host has + several names or network addresses, this does not always work. Thus, + each host also checks if it is part of the Via list.) + + A SIP invitation may traverse more than one SIP proxy server. If one + of these "forks" the request, i.e., issues more than one request in + response to receiving the invitation request, it is possible that a + client is reached, independently, by more than one copy of the + + + + +Handley, et al. Standards Track [Page 17] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + invitation request. Each of these copies bears the same Call-ID. The + user agent MUST return the same status response returned in the first + response. Duplicate requests are not an error. + +1.4.6 Changing an Existing Session + + In some circumstances, it is desirable to change the parameters of an + existing session. This is done by re-issuing the INVITE, using the + same Call-ID, but a new or different body or header fields to convey + the new information. This re INVITE MUST have a higher CSeq than any + previous request from the client to the server. + + For example, two parties may have been conversing and then want to + add a third party, switching to multicast for efficiency. One of the + participants invites the third party with the new multicast address + and simultaneously sends an INVITE to the second party, with the new + multicast session description, but with the old call identifier. + +1.4.7 Registration Services + + The REGISTER request allows a client to let a proxy or redirect + server know at which address(es) it can be reached. A client MAY also + use it to install call handling features at the server. + +1.5 Protocol Properties + +1.5.1 Minimal State + + A single conference session or call involves one or more SIP + request-response transactions. Proxy servers do not have to keep + state for a particular call, however, they MAY maintain state for a + single SIP transaction, as discussed in Section 12. For efficiency, a + server MAY cache the results of location service requests. + +1.5.2 Lower-Layer-Protocol Neutral + + SIP makes minimal assumptions about the underlying transport and + network-layer protocols. The lower-layer can provide either a packet + or a byte stream service, with reliable or unreliable service. + + In an Internet context, SIP is able to utilize both UDP and TCP as + transport protocols, among others. UDP allows the application to more + carefully control the timing of messages and their retransmission, to + perform parallel searches without requiring TCP connection state for + each outstanding request, and to use multicast. Routers can more + readily snoop SIP UDP packets. TCP allows easier passage through + existing firewalls. + + + + +Handley, et al. Standards Track [Page 18] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + + + +....... cs.columbia.edu .......+ + : : + : (~~~~~~~~~~) : + : ( location ) : + : ( service ) : + : (~~~~~~~~~~) : + : ^ | : + : | hgs@lab : + : 2| 3| : + : | | : + : henning| : ++.. cs.tu-berlin.de ..+ 1: INVITE : | | : +: : henning@cs.col: | \/ : +: cz@cs.tu-berlin.de =======================>(~~~~~~) : +: | ^ | <.......................( ) : +: | . | : 4: 302 Moved : ( ) : +: | . | : hgs@lab : ( work ) : +: | . | : : ( ) : +: | . | : 5: ACK : ( ) : +: | . | =======================>(~~~~~~) : +: | . | : : : ++.......|...|.........+ : : + | . | : : + | . | : : + | . | : : + | . | : : + | . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) : + | . ==================================================> ( ) : + | ..................................................... ( ) : + | 7: 200 OK : ( lab ) : + | : ( ) : + | 8: ACK : ( ) : + ======================================================> (~~~~~~) : + +...............................+ + + ====> SIP request + ....> SIP response + + ^ + | non-SIP protocols + | + + + + + Figure 2: Example of SIP redirect server + +Handley, et al. Standards Track [Page 19] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + When TCP is used, SIP can use one or more connections to attempt to + contact a user or to modify parameters of an existing conference. + Different SIP requests for the same SIP call MAY use different TCP + connections or a single persistent connection, as appropriate. + + For concreteness, this document will only refer to Internet + protocols. However, SIP MAY also be used directly with protocols + such as ATM AAL5, IPX, frame relay or X.25. The necessary naming + conventions are beyond the scope of this document. User agents SHOULD + implement both UDP and TCP transport. Proxy, registrar, and redirect + servers MUST implement both UDP and TCP transport. + +1.5.3 Text-Based + + SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This + allows easy implementation in languages such as Java, Tcl and Perl, + allows easy debugging, and most importantly, makes SIP flexible and + extensible. As SIP is used for initiating multimedia conferences + rather than delivering media data, it is believed that the additional + overhead of using a text-based protocol is not significant. + +2 SIP Uniform Resource Locators + + SIP URLs are used within SIP messages to indicate the originator + (From), current destination (Request-URI) and final recipient (To) of + a SIP request, and to specify redirection addresses (Contact). A SIP + URL can also be embedded in web pages or other hyperlinks to indicate + that a particular user or service can be called via SIP. When used as + a hyperlink, the SIP URL indicates the use of the INVITE method. + + The SIP URL scheme is defined to allow setting SIP request-header + fields and the SIP message-body. + + + This corresponds to the use of mailto: URLs. It makes it + possible, for example, to specify the subject, urgency or + media types of calls initiated through a web page or as + part of an email message. + + A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax + shown in Fig. 3. The syntax is described using Augmented Backus-Naur + Form (See Section C). Note that reserved characters have to be + escaped and that the "set of characters reserved within any given URI + component is defined by that component. In general, a character is + reserved if the semantics of the URI changes if the character is + replaced with its escaped US-ASCII encoding" [12]. + + + + + +Handley, et al. Standards Track [Page 20] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + SIP-URL = "sip:" [ userinfo "@" ] hostport + url-parameters [ headers ] + userinfo = user [ ":" password ] + user = *( unreserved | escaped + | "&" | "=" | "+" | "$" | "," ) + password = *( unreserved | escaped + | "&" | "=" | "+" | "$" | "," ) + hostport = host [ ":" port ] + host = hostname | IPv4address + hostname = *( domainlabel "." ) toplabel [ "." ] + domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum + toplabel = alpha | alpha *( alphanum | "-" ) alphanum + IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit + port = *digit + url-parameters = *( ";" url-parameter ) + url-parameter = transport-param | user-param | method-param + | ttl-param | maddr-param | other-param + transport-param = "transport=" ( "udp" | "tcp" ) + ttl-param = "ttl=" ttl + ttl = 1*3DIGIT ; 0 to 255 + maddr-param = "maddr=" host + user-param = "user=" ( "phone" | "ip" ) + method-param = "method=" Method + tag-param = "tag=" UUID + UUID = 1*( hex | "-" ) + other-param = ( token | ( token "=" ( token | quoted-string ))) + headers = "?" header *( "&" header ) + header = hname "=" hvalue + hname = 1*uric + hvalue = *uric + uric = reserved | unreserved | escaped + reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | + "$" | "," + digits = 1*DIGIT + + + Figure 3: SIP URL syntax + + + + The URI character classes referenced above are described in Appendix + C. + + The components of the SIP URI have the following meanings. + + + + + +Handley, et al. Standards Track [Page 21] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + +telephone-subscriber = global-phone-number | local-phone-number + global-phone-number = "+" 1*phonedigit [isdn-subaddress] + [post-dial] + local-phone-number = 1*(phonedigit | dtmf-digit | + pause-character) [isdn-subaddress] + [post-dial] + isdn-subaddress = ";isub=" 1*phonedigit + post-dial = ";postd=" 1*(phonedigit | dtmf-digit + | pause-character) + phonedigit = DIGIT | visual-separator + visual-separator = "-" | "." + pause-character = one-second-pause | wait-for-dial-tone + one-second-pause = "p" + wait-for-dial-tone = "w" + dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" + + Figure 4: SIP URL syntax; telephone subscriber + + user: If the host is an Internet telephony gateway, the user field + MAY also encode a telephone number using the notation of + telephone-subscriber (Fig. 4). The telephone number is a special + case of a user name and cannot be distinguished by a BNF. Thus, + a URL parameter, user, is added to distinguish telephone numbers + from user names. The phone identifier is to be used when + connecting to a telephony gateway. Even without this parameter, + recipients of SIP URLs MAY interpret the pre-@ part as a phone + number if local restrictions on the name space for user name + allow it. + + password: The SIP scheme MAY use the format "user:password" in the + userinfo field. The use of passwords in the userinfo is NOT + RECOMMENDED, because the passing of authentication information + in clear text (such as URIs) has proven to be a security risk in + almost every case where it has been used. + + host: The mailto: URL and RFC 822 email addresses require that + numeric host addresses ("host numbers") are enclosed in square + brackets (presumably, since host names might be numeric), while + host numbers without brackets are used for all other URLs. The + SIP URL requires the latter form, without brackets. + + The issue of IPv6 literal addresses in URLs is being looked at + elsewhere in the IETF. SIP implementers are advised to keep up to + date on that activity. + + + + +Handley, et al. Standards Track [Page 22] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + port: The port number to send a request to. If not present, the + procedures outlined in Section 1.4.2 are used to determine the + port number to send a request to. + + URL parameters: SIP URLs can define specific parameters of the + request. URL parameters are added after the host component and + are separated by semi-colons. The transport parameter determines + the the transport mechanism (UDP or TCP). UDP is to be assumed + when no explicit transport parameter is included. The maddr + parameter provides the server address to be contacted for this + user, overriding the address supplied in the host field. This + address is typically a multicast address, but could also be the + address of a backup server. The ttl parameter determines the + time-to-live value of the UDP multicast packet and MUST only be + used if maddr is a multicast address and the transport protocol + is UDP. The user parameter was described above. For example, to + specify to call j.doe@big.com using multicast to 239.255.255.1 + with a ttl of 15, the following URL would be used: + + + sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 + + + + The transport, maddr, and ttl parameters MUST NOT be used in the From + and To header fields and the Request-URI; they are ignored if + present. + + Headers: Headers of the SIP request can be defined with the "?" + mechanism within a SIP URL. The special hname "body" indicates + that the associated hvalue is the message-body of the SIP INVITE + request. Headers MUST NOT be used in the From and To header + fields and the Request-URI; they are ignored if present. hname + and hvalue are encodings of a SIP header name and value, + respectively. All URL reserved characters in the header names + and values MUST be escaped. + + Method: The method of the SIP request can be specified with the + method parameter. This parameter MUST NOT be used in the From + and To header fields and the Request-URI; they are ignored if + present. + + Table 2 summarizes where the components of the SIP URL can be used + and what default values they assume if not present. + + + Examples of SIP URLs are: + + + + +Handley, et al. Standards Track [Page 23] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + default Req.-URI To From Contact external + user -- x x x x x + password -- x x x x + host mandatory x x x x x + port 5060 x x x x x + user-param ip x x x x x + method INVITE x x + maddr-param -- x x + ttl-param 1 x x + transp.-param -- x x + headers -- x x + + + Table 2: Use and default values of URL components for SIP headers, + Request-URI and references + + sip:j.doe@big.com + sip:j.doe:secret@big.com;transport=tcp + sip:j.doe@big.com?subject=project + sip:+1-212-555-1212:1234@gateway.com;user=phone + sip:1212@gateway.com + sip:alice@10.1.2.3 + sip:alice@example.com + sip:alice%40example.com@gateway.com + sip:alice@registrar.com;method=REGISTER + + + + Within a SIP message, URLs are used to indicate the source and + intended destination of a request, redirection addresses and the + current destination of a request. Normally all these fields will + contain SIP URLs. + + SIP URLs are case-insensitive, so that for example the two URLs + sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All + URL parameters are included when comparing SIP URLs for equality. + + SIP header fields MAY contain non-SIP URLs. As an example, if a call + from a telephone is relayed to the Internet via SIP, the SIP From + header field might contain a phone URL. + +3 SIP Message Overview + + SIP is a text-based protocol and uses the ISO 10646 character set in + UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a + CRLF, but receivers MUST also interpret CR and LF by themselves as + line terminators. + + + +Handley, et al. Standards Track [Page 24] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Except for the above difference in character sets, much of the + message syntax is and header fields are identical to HTTP/1.1; rather + than repeating the syntax and semantics here we use [HX.Y] to refer + to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [11]). + In addition, we describe SIP in both prose and an augmented Backus- + Naur form (ABNF). See section C for an overview of ABNF. + + Note, however, that SIP is not an extension of HTTP. + + Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP + transactions can be carried in a single TCP connection or UDP + datagram. UDP datagrams, including all headers, SHOULD NOT be larger + than the path maximum transmission unit (MTU) if the MTU is known, or + 1500 bytes if the MTU is unknown. + + + The 1500 bytes accommodates encapsulation within the + "typical" ethernet MTU without IP fragmentation. Recent + studies [22] indicate that an MTU of 1500 bytes is a + reasonable assumption. The next lower common MTU values are + 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191 + [23]). Thus, another reasonable value would be a message + size of 950 bytes, to accommodate packet headers within the + SLIP MTU without fragmentation. + + A SIP message is either a request from a client to a server, or a + response from a server to a client. + + + + SIP-message = Request | Response + + + Both Request (section 4) and Response (section 5) messages use the + generic-message format of RFC 822 [24] for transferring entities (the + body of the message). Both types of messages consist of a start-line, + one or more header fields (also known as "headers"), an empty line + (i.e., a line with nothing preceding the carriage-return line-feed + (CRLF)) indicating the end of the header fields, and an optional + message-body. To avoid confusion with similar-named headers in HTTP, + we refer to the headers describing the message body as entity + headers. These components are described in detail in the upcoming + sections. + + + + generic-message = start-line + *message-header + + + +Handley, et al. Standards Track [Page 25] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + CRLF + [ message-body ] + + start-line = Request-Line | ;Section 4.1 + Status-Line ;Section 5.1 + + + + + message-header = ( general-header + | request-header + | response-header + | entity-header ) + + + + In the interest of robustness, any leading empty line(s) MUST be + ignored. In other words, if the Request or Response message begins + with one or more CRLF, CR, or LFs, these characters MUST be ignored. + +4 Request + + The Request message format is shown below: + + + + Request = Request-Line ; Section 4.1 + *( general-header + | request-header + | entity-header ) + CRLF + [ message-body ] ; Section 8 + + +4.1 Request-Line + + The Request-Line begins with a method token, followed by the + Request-URI and the protocol version, and ending with CRLF. The + elements are separated by SP characters. No CR or LF are allowed + except in the final CRLF sequence. + + + + Request-Line = Method SP Request-URI SP SIP-Version CRLF + + + + + + + +Handley, et al. Standards Track [Page 26] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + general-header = Accept ; Section 6.7 + | Accept-Encoding ; Section 6.8 + | Accept-Language ; Section 6.9 + | Call-ID ; Section 6.12 + | Contact ; Section 6.13 + | CSeq ; Section 6.17 + | Date ; Section 6.18 + | Encryption ; Section 6.19 + | Expires ; Section 6.20 + | From ; Section 6.21 + | Record-Route ; Section 6.29 + | Timestamp ; Section 6.36 + | To ; Section 6.37 + | Via ; Section 6.40 + entity-header = Content-Encoding ; Section 6.14 + | Content-Length ; Section 6.15 + | Content-Type ; Section 6.16 + request-header = Authorization ; Section 6.11 + | Contact ; Section 6.13 + | Hide ; Section 6.22 + | Max-Forwards ; Section 6.23 + | Organization ; Section 6.24 + | Priority ; Section 6.25 + | Proxy-Authorization ; Section 6.27 + | Proxy-Require ; Section 6.28 + | Route ; Section 6.33 + | Require ; Section 6.30 + | Response-Key ; Section 6.31 + | Subject ; Section 6.35 + | User-Agent ; Section 6.39 + response-header = Allow ; Section 6.10 + | Proxy-Authenticate ; Section 6.26 + | Retry-After ; Section 6.32 + | Server ; Section 6.34 + | Unsupported ; Section 6.38 + | Warning ; Section 6.41 + | WWW-Authenticate ; Section 6.42 + + + Table 3: SIP headers + +4.2 Methods + + The methods are defined below. Methods that are not supported by a + proxy or redirect server are treated by that server as if they were + an OPTIONS method and forwarded accordingly. Methods that are not + + + +Handley, et al. Standards Track [Page 27] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + supported by a user agent server or registrar cause a 501 (Not + Implemented) response to be returned (Section 7). As in HTTP, the + Method token is case-sensitive. + + + + Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" + | "CANCEL" | "REGISTER" + + +4.2.1 INVITE + + The INVITE method indicates that the user or service is being invited + to participate in a session. The message body contains a description + of the session to which the callee is being invited. For two-party + calls, the caller indicates the type of media it is able to receive + and possibly the media it is willing to send as well as their + parameters such as network destination. A success response MUST + indicate in its message body which media the callee wishes to receive + and MAY indicate the media the callee is going to send. + + + Not all session description formats have the ability to + indicate sending media. + + A server MAY automatically respond to an invitation for a conference + the user is already participating in, identified either by the SIP + Call-ID or a globally unique identifier within the session + description, with a 200 (OK) response. + + If a user agent receives an INVITE request for an existing call leg + with a higher CSeq sequence number than any previous INVITE for the + same Call-ID, it MUST check any version identifiers in the session + description or, if there are no version identifiers, the content of + the session description to see if it has changed. It MUST also + inspect any other header fields for changes. If there is a change, + the user agent MUST update any internal state or information + generated as a result of that header. If the session description has + changed, the user agent server MUST adjust the session parameters + accordingly, possibly after asking the user for confirmation. + (Versioning of the session description can be used to accommodate the + capabilities of new arrivals to a conference, add or delete media or + change from a unicast to a multicast conference.) + + This method MUST be supported by SIP proxy, redirect and user agent + servers as well as clients. + + + + + +Handley, et al. Standards Track [Page 28] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +4.2.2 ACK + + The ACK request confirms that the client has received a final + response to an INVITE request. (ACK is used only with INVITE + requests.) 2xx responses are acknowledged by client user agents, all + other final responses by the first proxy or client user agent to + receive the response. The Via is always initialized to the host that + originates the ACK request, i.e., the client user agent after a 2xx + response or the first proxy to receive a non-2xx final response. The + ACK request is forwarded as the corresponding INVITE request, based + on its Request-URI. See Section 10 for details. + + The ACK request MAY contain a message body with the final session + description to be used by the callee. If the ACK message body is + empty, the callee uses the session description in the INVITE request. + + A proxy server receiving an ACK request after having sent a 3xx, 4xx, + 5xx, or 6xx response must make a determination about whether the ACK + is for it, or for some user agent or proxy server further downstream. + This determination is made by examining the tag in the To field. If + the tag in the ACK To header field matches the tag in the To header + field of the response, and the From, CSeq and Call-ID header fields + in the response match those in the ACK, the ACK is meant for the + proxy server. Otherwise, the ACK SHOULD be proxied downstream as any + other request. + + + It is possible for a user agent client or proxy server to + receive multiple 3xx, 4xx, 5xx, and 6xx responses to a + request along a single branch. This can happen under + various error conditions, typically when a forking proxy + transitions from stateful to stateless before receiving all + responses. The various responses will all be identical, + except for the tag in the To field, which is different for + each one. It can therefore be used as a means to + disambiguate them. + + This method MUST be supported by SIP proxy, redirect and user agent + servers as well as clients. + +4.2.3 OPTIONS + + The server is being queried as to its capabilities. A server that + believes it can contact the user, such as a user agent where the user + is logged in and has been recently active, MAY respond to this + request with a capability set. A called user agent MAY return a + status reflecting how it would have responded to an invitation, e.g., + + + + +Handley, et al. Standards Track [Page 29] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 600 (Busy). Such a server SHOULD return an Allow header field + indicating the methods that it supports. Proxy and redirect servers + simply forward the request without indicating their capabilities. + + This method MUST be supported by SIP proxy, redirect and user agent + servers, registrars and clients. + +4.2.4 BYE + + The user agent client uses BYE to indicate to the server that it + wishes to release the call. A BYE request is forwarded like an INVITE + request and MAY be issued by either caller or callee. A party to a + call SHOULD issue a BYE request before releasing a call ("hanging + up"). A party receiving a BYE request MUST cease transmitting media + streams specifically directed at the party issuing the BYE request. + + If the INVITE request contained a Contact header, the callee SHOULD + send a BYE request to that address rather than the From address. + + This method MUST be supported by proxy servers and SHOULD be + supported by redirect and user agent SIP servers. + +4.2.5 CANCEL + + The CANCEL request cancels a pending request with the same Call-ID, + To, From and CSeq (sequence number only) header field values, but + does not affect a completed request. (A request is considered + completed if the server has returned a final status response.) + + A user agent client or proxy client MAY issue a CANCEL request at any + time. A proxy, in particular, MAY choose to send a CANCEL to + destinations that have not yet returned a final response after it has + received a 2xx or 6xx response for one or more of the parallel-search + requests. A proxy that receives a CANCEL request forwards the request + to all destinations with pending requests. + + The Call-ID, To, the numeric part of CSeq and From headers in the + CANCEL request are identical to those in the original request. This + allows a CANCEL request to be matched with the request it cancels. + However, to allow the client to distinguish responses to the CANCEL + from those to the original request, the CSeq Method component is set + to CANCEL. The Via header field is initialized to the proxy issuing + the CANCEL request. (Thus, responses to this CANCEL request only + reach the issuing proxy.) + + Once a user agent server has received a CANCEL, it MUST NOT issue a + 2xx response for the cancelled original request. + + + + +Handley, et al. Standards Track [Page 30] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + A redirect or user agent server receiving a CANCEL request responds + with a status of 200 (OK) if the transaction exists and a status of + 481 (Transaction Does Not Exist) if not, but takes no further action. + In particular, any existing call is unaffected. + + + The BYE request cannot be used to cancel branches of a + parallel search, since several branches may, through + intermediate proxies, find the same user agent server and + then terminate the call. To terminate a call instead of + just pending searches, the UAC must use BYE instead of or + in addition to CANCEL. While CANCEL can terminate any + pending request other than ACK or CANCEL, it is typically + useful only for INVITE. 200 responses to INVITE and 200 + responses to CANCEL are distinguished by the method in the + Cseq header field, so there is no ambiguity. + + This method MUST be supported by proxy servers and SHOULD be + supported by all other SIP server types. + +4.2.6 REGISTER + + A client uses the REGISTER method to register the address listed in + the To header field with a SIP server. + + A user agent MAY register with a local server on startup by sending a + REGISTER request to the well-known "all SIP servers" multicast + address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped + to ensure it is not forwarded beyond the boundaries of the + administrative system. This MAY be done with either TTL or + administrative scopes [25], depending on what is implemented in the + network. SIP user agents MAY listen to that address and use it to + become aware of the location of other local users [20]; however, they + do not respond to the request. A user agent MAY also be configured + with the address of a registrar server to which it sends a REGISTER + request upon startup. + + Requests are processed in the order received. Clients SHOULD avoid + sending a new registration (as opposed to a retransmission) until + they have received the response from the server for the previous one. + + + Clients may register from different locations, by necessity + using different Call-ID values. Thus, the CSeq value cannot + be used to enforce ordering. Since registrations are + additive, ordering is less of a problem than if each + REGISTER request completely replaced all earlier ones. + + + + +Handley, et al. Standards Track [Page 31] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The meaning of the REGISTER request-header fields is defined as + follows. We define "address-of-record" as the SIP address that the + registry knows the registrand, typically of the form "user@domain" + rather than "user@host". In third-party registration, the entity + issuing the request is different from the entity being registered. + + To: The To header field contains the address-of-record whose + registration is to be created or updated. + + From: The From header field contains the address-of-record of the + person responsible for the registration. For first-party + registration, it is identical to the To header field value. + + Request-URI: The Request-URI names the destination of the + registration request, i.e., the domain of the registrar. The + user name MUST be empty. Generally, the domains in the Request- + URI and the To header field have the same value; however, it is + possible to register as a "visitor", while maintaining one's + name. For example, a traveler sip:alice@acme.com (To) might + register under the Request-URI sip:atlanta.hiayh.org , with the + former as the To header field and the latter as the Request-URI. + The REGISTER request is no longer forwarded once it has reached + the server whose authoritative domain is the one listed in the + Request-URI. + + Call-ID: All registrations from a client SHOULD use the same Call-ID + header value, at least within the same reboot cycle. + + Cseq: Registrations with the same Call-ID MUST have increasing CSeq + header values. However, the server does not reject out-of-order + requests. + + Contact: The request MAY contain a Contact header field; future non- + REGISTER requests for the URI given in the To header field + SHOULD be directed to the address(es) given in the Contact + header. + + If the request does not contain a Contact header, the registration + remains unchanged. + + This is useful to obtain the current list of registrations + in the response. Registrations using SIP URIs that differ + in one or more of host, port, transport-param or maddr- + param (see Figure 3) from an existing registration are + added to the list of registrations. Other URI types are + compared according to the standard URI equivalency rules + for the URI schema. If the URIs are equivalent to that of + an existing registration, the new registration replaces the + + + +Handley, et al. Standards Track [Page 32] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + old one if it has a higher q value or, for the same value + of q, if the ttl value is higher. All current registrations + MUST share the same action value. Registrations that have + a different action than current registrations for the same + user MUST be rejected with status of 409 (Conflict). + + A proxy server ignores the q parameter when processing non-REGISTER + requests, while a redirect server simply returns that parameter in + its Contact response header field. + + + Having the proxy server interpret the q parameter is not + sufficient to guide proxy behavior, as it is not clear, for + example, how long it is supposed to wait between trying + addresses. + + If the registration is changed while a user agent or proxy server + processes an invitation, the new information SHOULD be used. + + + This allows a service known as "directed pick-up". In the + telephone network, directed pickup permits a user at a + remote station who hears his own phone ringing to pick up + at that station, dial an access code, and be connected to + the calling user as if he had answered his own phone. + + A server MAY choose any duration for the registration lifetime. + Registrations not refreshed after this amount of time SHOULD be + silently discarded. Responses to a registration SHOULD include an + Expires header (Section 6.20) or expires Contact parameters (Section + 6.13), indicating the time at which the server will drop the + registration. If none is present, one hour is assumed. Clients MAY + request a registration lifetime by indicating the time in an Expires + header in the request. A server SHOULD NOT use a higher lifetime than + the one requested, but MAY use a lower one. A single address (if + host-independent) MAY be registered from several different clients. + + A client cancels an existing registration by sending a REGISTER + request with an expiration time (Expires) of zero seconds for a + particular Contact or the wildcard Contact designated by a "*" for + all registrations. Registrations are matched based on the user, host, + port and maddr parameters. + + The server SHOULD return the current list of registrations in the 200 + response as Contact header fields. + + It is particularly important that REGISTER requests are authenticated + since they allow to redirect future requests (see Section 13.2). + + + +Handley, et al. Standards Track [Page 33] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Beyond its use as a simple location service, this method is + needed if there are several SIP servers on a single host. + In that case, only one of the servers can use the default + port number. + + + Support of this method is RECOMMENDED. + +4.3 Request-URI + + The Request-URI is a SIP URL as described in Section 2 or a general + URI. It indicates the user or service to which this request is being + addressed. Unlike the To field, the Request-URI MAY be re-written by + proxies. + + When used as a Request-URI, a SIP-URL MUST NOT contain the + transport-param, maddr-param, ttl-param, or headers elements. A + server that receives a SIP-URL with these elements removes them + before further processing. + + + Typically, the UAC sets the Request-URI and To to the same + SIP URL, presumed to remain unchanged over long time + periods. However, if the UAC has cached a more direct path + to the callee, e.g., from the Contact header field of a + response to a previous request, the To would still contain + the long-term, "public" address, while the Request-URI + would be set to the cached address. + + Proxy and redirect servers MAY use the information in the Request-URI + and request header fields to handle the request and possibly rewrite + the Request-URI. For example, a request addressed to the generic + address sip:sales@acme.com is proxied to the particular person, e.g., + sip:bob@ny.acme.com , with the To field remaining as + sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as + the temporary substitute. + + The host part of the Request-URI typically agrees with one of the + host names of the receiving server. If it does not, the server SHOULD + proxy the request to the address indicated or return a 404 (Not + Found) response if it is unwilling or unable to do so. For example, + the Request-URI and server host name can disagree in the case of a + firewall proxy that handles outgoing calls. This mode of operation is + similar to that of HTTP proxies. + + If a SIP server receives a request with a URI indicating a scheme + other than SIP which that server does not understand, the server MUST + return a 400 (Bad Request) response. It MUST do this even if the To + + + +Handley, et al. Standards Track [Page 34] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + header field contains a scheme it does understand. This is because + proxies are responsible for processing the Request-URI; the To field + is of end-to-end significance. + +4.3.1 SIP Version + + Both request and response messages include the version of SIP in use, + and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced + by SIP/2.0) regarding version ordering, compliance requirements, and + upgrading of version numbers. To be compliant with this + specification, applications sending SIP messages MUST include a SIP- + Version of "SIP/2.0". + +4.4 Option Tags + + Option tags are unique identifiers used to designate new options in + SIP. These tags are used in Require (Section 6.30) and Unsupported + (Section 6.38) fields. + + Syntax: + + + option-tag = token + + + See Section C for a definition of token. The creator of a new SIP + option MUST either prefix the option with their reverse domain name + or register the new option with the Internet Assigned Numbers + Authority (IANA). For example, "com.foo.mynewfeature" is an apt name + for a feature whose inventor can be reached at "foo.com". Individual + organizations are then responsible for ensuring that option names + don't collide. Options registered with IANA have the prefix + "org.iana.sip.", options described in RFCs have the prefix + "org.ietf.rfc.N", where N is the RFC number. Option tags are case- + insensitive. + +4.4.1 Registering New Option Tags with IANA + + When registering a new SIP option, the following information MUST be + provided: + + o Name and description of option. The name MAY be of any + length, but SHOULD be no more than twenty characters long. The + name MUST consist of alphanum (See Figure 3) characters only; + + + + + + + +Handley, et al. Standards Track [Page 35] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + o Indication of who has change control over the option (for + example, IETF, ISO, ITU-T, other international standardization + bodies, a consortium or a particular company or group of + companies); + + o A reference to a further description, if available, for + example (in order of preference) an RFC, a published paper, a + patent filing, a technical report, documented source code or a + computer manual; + + o Contact information (postal and email address); + + Registrations should be sent to iana@iana.org + + + This procedure has been borrowed from RTSP [4] and the RTP + AVP [26]. + +5 Response + + After receiving and interpreting a request message, the recipient + responds with a SIP response message. The response message format is + shown below: + + + + Response = Status-Line ; Section 5.1 + *( general-header + | response-header + | entity-header ) + CRLF + [ message-body ] ; Section 8 + + + SIP's structure of responses is similar to [H6], but is defined + explicitly here. + +5.1 Status-Line + + The first line of a Response message is the Status-Line, consisting + of the protocol version (Section 4.3.1) followed by a numeric + Status-Code and its associated textual phrase, with each element + separated by SP characters. No CR or LF is allowed except in the + final CRLF sequence. + + + + Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF + + + +Handley, et al. Standards Track [Page 36] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +5.1.1 Status Codes and Reason Phrases + + The Status-Code is a 3-digit integer result code that indicates the + outcome of the attempt to understand and satisfy the request. The + Reason-Phrase is intended to give a short textual description of the + Status-Code. The Status-Code is intended for use by automata, whereas + the Reason-Phrase is intended for the human user. The client is not + required to examine or display the Reason-Phrase. + + + + Status-Code = Informational ;Fig. 5 + | Success ;Fig. 5 + | Redirection ;Fig. 6 + | Client-Error ;Fig. 7 + | Server-Error ;Fig. 8 + | Global-Failure ;Fig. 9 + | extension-code + extension-code = 3DIGIT + Reason-Phrase = * + + + We provide an overview of the Status-Code below, and provide full + definitions in Section 7. The first digit of the Status-Code defines + the class of response. The last two digits do not have any + categorization role. SIP/2.0 allows 6 values for the first digit: + + 1xx: Informational -- request received, continuing to process the + request; + + 2xx: Success -- the action was successfully received, understood, and + accepted; + + 3xx: Redirection -- further action needs to be taken in order to + complete the request; + + 4xx: Client Error -- the request contains bad syntax or cannot be + fulfilled at this server; + + 5xx: Server Error -- the server failed to fulfill an apparently valid + request; + + 6xx: Global Failure -- the request cannot be fulfilled at any server. + + Figures 5 through 9 present the individual values of the numeric + response codes, and an example set of corresponding reason phrases + for SIP/2.0. These reason phrases are only recommended; they may be + replaced by local equivalents without affecting the protocol. Note + + + +Handley, et al. Standards Track [Page 37] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response + codes in the range starting at x80 to avoid conflicts with newly + defined HTTP response codes, and adds a new class, 6xx, of response + codes. + + SIP response codes are extensible. SIP applications are not required + to understand the meaning of all registered response codes, though + such understanding is obviously desirable. However, applications MUST + understand the class of any response code, as indicated by the first + digit, and treat any unrecognized response as being equivalent to the + x00 response code of that class, with the exception that an + unrecognized response MUST NOT be cached. For example, if a client + receives an unrecognized response code of 431, it can safely assume + that there was something wrong with its request and treat the + response as if it had received a 400 (Bad Request) response code. In + such cases, user agents SHOULD present to the user the message body + returned with the response, since that message body is likely to + include human-readable information which will explain the unusual + status. + + + + Informational = "100" ; Trying + | "180" ; Ringing + | "181" ; Call Is Being Forwarded + | "182" ; Queued + Success = "200" ; OK + + + Figure 5: Informational and success status codes + + + + + + Redirection = "300" ; Multiple Choices + | "301" ; Moved Permanently + | "302" ; Moved Temporarily + | "303" ; See Other + | "305" ; Use Proxy + | "380" ; Alternative Service + + + Figure 6: Redirection status codes + + + + + + + +Handley, et al. Standards Track [Page 38] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + Client-Error = "400" ; Bad Request + | "401" ; Unauthorized + | "402" ; Payment Required + | "403" ; Forbidden + | "404" ; Not Found + | "405" ; Method Not Allowed + | "406" ; Not Acceptable + | "407" ; Proxy Authentication Required + | "408" ; Request Timeout + | "409" ; Conflict + | "410" ; Gone + | "411" ; Length Required + | "413" ; Request Entity Too Large + | "414" ; Request-URI Too Large + | "415" ; Unsupported Media Type + | "420" ; Bad Extension + | "480" ; Temporarily not available + | "481" ; Call Leg/Transaction Does Not Exist + | "482" ; Loop Detected + | "483" ; Too Many Hops + | "484" ; Address Incomplete + | "485" ; Ambiguous + | "486" ; Busy Here + + + Figure 7: Client error status codes + + + Server-Error = "500" ; Internal Server Error + | "501" ; Not Implemented + | "502" ; Bad Gateway + | "503" ; Service Unavailable + | "504" ; Gateway Time-out + | "505" ; SIP Version not supported + + + Figure 8: Server error status codes + + +6 Header Field Definitions + + SIP header fields are similar to HTTP header fields in both syntax + and semantics. In particular, SIP header fields follow the syntax for + message-header as described in [H4.2]. The rules for extending header + fields over multiple lines, and use of multiple message-header fields + with the same field-name, described in [H4.2] also apply to SIP. The + + + +Handley, et al. Standards Track [Page 39] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + Global-Failure | "600" ; Busy Everywhere + | "603" ; Decline + | "604" ; Does not exist anywhere + | "606" ; Not Acceptable + + + Figure 9: Global failure status codes + + + rules in [H4.2] regarding ordering of header fields apply to SIP, + with the exception of Via fields, see below, whose order matters. + Additionally, header fields which are hop-by-hop MUST appear before + any header fields which are end-to-end. Proxies SHOULD NOT reorder + header fields. Proxies add Via header fields and MAY add other hop- + by-hop header fields. They can modify certain header fields, such as + Max-Forwards (Section 6.23) and "fix up" the Via header fields with + "received" parameters as described in Section 6.40.1. Proxies MUST + NOT alter any fields that are authenticated (see Section 13.2). + + The header fields required, optional and not applicable for each + method are listed in Table 4 and Table 5. The table uses "o" to + indicate optional, "m" mandatory and "-" for not applicable. A "*" + indicates that the header fields are needed only if message body is + not empty. See sections 6.15, 6.16 and 8 for details. + + The "where" column describes the request and response types with + which the header field can be used. "R" refers to header fields that + can be used in requests (that is, request and general header fields). + "r" designates a response or general-header field as applicable to + all responses, while a list of numeric values indicates the status + codes with which the header field can be used. "g" and "e" designate + general (Section 6.1) and entity header (Section 6.2) fields, + respectively. If a header field is marked "c", it is copied from the + request to the response. + + The "enc." column describes whether this message header field MAY be + encrypted end-to-end. A "n" designates fields that MUST NOT be + encrypted, while "c" designates fields that SHOULD be encrypted if + encryption is used. + + The "e-e" column has a value of "e" for end-to-end and a value of "h" + for hop-by-hop header fields. + + + + + + + +Handley, et al. Standards Track [Page 40] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + where enc. e-e ACK BYE CAN INV OPT REG + __________________________________________________________ + Accept R e - - - o o o + Accept 415 e - - - o o o + Accept-Encoding R e - - - o o o + Accept-Encoding 415 e - - - o o o + Accept-Language R e - o o o o o + Accept-Language 415 e - o o o o o + Allow 200 e - - - - m - + Allow 405 e o o o o o o + Authorization R e o o o o o o + Call-ID gc n e m m m m m m + Contact R e o - - o o o + Contact 1xx e - - - o o - + Contact 2xx e - - - o o o + Contact 3xx e - o - o o o + Contact 485 e - o - o o o + Content-Encoding e e o - - o o o + Content-Length e e o - - o o o + Content-Type e e * - - * * * + CSeq gc n e m m m m m m + Date g e o o o o o o + Encryption g n e o o o o o o + Expires g e - - - o - o + From gc n e m m m m m m + Hide R n h o o o o o o + Max-Forwards R n e o o o o o o + Organization g c h - - - o o o + + + Table 4: Summary of header fields, A--O + + Other header fields can be added as required; a server MUST ignore + header fields not defined in this specification that it does not + understand. A proxy MUST NOT remove or modify header fields not + defined in this specification that it does not understand. A compact + form of these header fields is also defined in Section 9 for use over + UDP when the request has to fit into a single packet and size is an + issue. + + Table 6 in Appendix A lists those header fields that different client + and server types MUST be able to parse. + +6.1 General Header Fields + + General header fields apply to both request and response messages. + The "general-header" field names can be extended reliably only in + combination with a change in the protocol version. However, new or + + +Handley, et al. Standards Track [Page 41] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + where enc. e-e ACK BYE CAN INV OPT REG + ___________________________________________________________________ + Proxy-Authenticate 407 n h o o o o o o + Proxy-Authorization R n h o o o o o o + Proxy-Require R n h o o o o o o + Priority R c e - - - o - - + Require R e o o o o o o + Retry-After R c e - - - - - o + Retry-After 404,480,486 c e o o o o o o + 503 c e o o o o o o + 600,603 c e o o o o o o + Response-Key R c e - o o o o o + Record-Route R h o o o o o o + Record-Route 2xx h o o o o o o + Route R h o o o o o o + Server r c e o o o o o o + Subject R c e - - - o - - + Timestamp g e o o o o o o + To gc(1) n e m m m m m m + Unsupported 420 e o o o o o o + User-Agent g c e o o o o o o + Via gc(2) n e m m m m m m + Warning r e o o o o o o + WWW-Authenticate 401 c e o o o o o o + + + Table 5: Summary of header fields, P--Z; (1): copied with possible + addition of tag; (2): UAS removes first Via header field + + experimental header fields MAY be given the semantics of general + header fields if all parties in the communication recognize them to + be "general-header" fields. Unrecognized header fields are treated as + "entity-header" fields. + +6.2 Entity Header Fields + + The "entity-header" fields define meta-information about the + message-body or, if no body is present, about the resource identified + by the request. The term "entity header" is an HTTP 1.1 term where + the response body can contain a transformed version of the message + body. The original message body is referred to as the "entity". We + retain the same terminology for header fields but usually refer to + the "message body" rather then the entity as the two are the same in + SIP. + + + + + + +Handley, et al. Standards Track [Page 42] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.3 Request Header Fields + + The "request-header" fields allow the client to pass additional + information about the request, and about the client itself, to the + server. These fields act as request modifiers, with semantics + equivalent to the parameters of a programming language method + invocation. + + The "request-header" field names can be extended reliably only in + combination with a change in the protocol version. However, new or + experimental header fields MAY be given the semantics of "request- + header" fields if all parties in the communication recognize them to + be request-header fields. Unrecognized header fields are treated as + "entity-header" fields. + +6.4 Response Header Fields + + The "response-header" fields allow the server to pass additional + information about the response which cannot be placed in the Status- + Line. These header fields give information about the server and about + further access to the resource identified by the Request-URI. + + Response-header field names can be extended reliably only in + combination with a change in the protocol version. However, new or + experimental header fields MAY be given the semantics of "response- + header" fields if all parties in the communication recognize them to + be "response-header" fields. Unrecognized header fields are treated + as "entity-header" fields. + +6.5 End-to-end and Hop-by-hop Headers + + End-to-end headers MUST be transmitted unmodified across all proxies, + while hop-by-hop headers MAY be modified or added by proxies. + +6.6 Header Field Format + + Header fields ("general-header", "request-header", "response-header", + and "entity-header") follow the same generic header format as that + given in Section 3.1 of RFC 822 [24]. Each header field consists of a + name followed by a colon (":") and the field value. Field names are + case-insensitive. The field value MAY be preceded by any amount of + leading white space (LWS), though a single space (SP) is preferred. + Header fields can be extended over multiple lines by preceding each + extra line with at least one SP or horizontal tab (HT). Applications + MUST follow HTTP "common form" when generating these constructs, + since there might exist some implementations that fail to accept + anything beyond the common forms. + + + + +Handley, et al. Standards Track [Page 43] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + message-header = field-name ":" [ field-value ] CRLF + field-name = token + field-value = *( field-content | LWS ) + field-content = < the OCTETs making up the field-value + and consisting of either *TEXT-UTF8 + or combinations of token, + separators, and quoted-string> + + + The relative order of header fields with different field names is not + significant. Multiple header fields with the same field-name may be + present in a message if and only if the entire field-value for that + header field is defined as a comma-separated list (i.e., #(values)). + It MUST be possible to combine the multiple header fields into one + "field-name: field-value" pair, without changing the semantics of the + message, by appending each subsequent field-value to the first, each + separated by a comma. The order in which header fields with the same + field-name are received is therefore significant to the + interpretation of the combined field value, and thus a proxy MUST NOT + change the order of these field values when a message is forwarded. + + Field names are not case-sensitive, although their values may be. + +6.7 Accept + + The Accept header follows the syntax defined in [H14.1]. The + semantics are also identical, with the exception that if no Accept + header is present, the server SHOULD assume a default value of + application/sdp. + + This request-header field is used only with the INVITE, OPTIONS and + REGISTER request methods to indicate what media types are acceptable + in the response. + + Example: + + + Accept: application/sdp;level=1, application/x-private, text/html + + + +6.8 Accept-Encoding + + The Accept-Encoding request-header field is similar to Accept, but + restricts the content-codings [H3.4.1] that are acceptable in the + response. See [H14.3]. The syntax of this header is defined in + [H14.3]. The semantics in SIP are identical to those defined in + [H14.3]. + + + +Handley, et al. Standards Track [Page 44] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.9 Accept-Language + + The Accept-Language header follows the syntax defined in [H14.4]. The + rules for ordering the languages based on the q parameter apply to + SIP as well. When used in SIP, the Accept-Language request-header + field can be used to allow the client to indicate to the server in + which language it would prefer to receive reason phrases, session + descriptions or status responses carried as message bodies. A proxy + MAY use this field to help select the destination for the call, for + example, a human operator conversant in a language spoken by the + caller. + + Example: + + + Accept-Language: da, en-gb;q=0.8, en;q=0.7 + + +6.10 Allow + + The Allow entity-header field lists the set of methods supported by + the resource identified by the Request-URI. The purpose of this field + is strictly to inform the recipient of valid methods associated with + the resource. An Allow header field MUST be present in a 405 (Method + Not Allowed) response and SHOULD be present in an OPTIONS response. + + + + Allow = "Allow" ":" 1#Method + + +6.11 Authorization + + A user agent that wishes to authenticate itself with a server -- + usually, but not necessarily, after receiving a 401 response -- MAY + do so by including an Authorization request-header field with the + request. The Authorization field value consists of credentials + containing the authentication information of the user agent for the + realm of the resource being requested. + + Section 13.2 overviews the use of the Authorization header, and + section 15 describes the syntax and semantics when used with PGP + based authentication. + + + + + + + + +Handley, et al. Standards Track [Page 45] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.12 Call-ID + + The Call-ID general-header field uniquely identifies a particular + invitation or all registrations of a particular client. Note that a + single multimedia conference can give rise to several calls with + different Call-IDs, e.g., if a user invites a single individual + several times to the same (long-running) conference. + + For an INVITE request, a callee user agent server SHOULD NOT alert + the user if the user has responded previously to the Call-ID in the + INVITE request. If the user is already a member of the conference and + the conference parameters contained in the session description have + not changed, a callee user agent server MAY silently accept the call, + regardless of the Call-ID. An invitation for an existing Call-ID or + session can change the parameters of the conference. A client + application MAY decide to simply indicate to the user that the + conference parameters have been changed and accept the invitation + automatically or it MAY require user confirmation. + + A user may be invited to the same conference or call using several + different Call-IDs. If desired, the client MAY use identifiers within + the session description to detect this duplication. For example, SDP + contains a session id and version number in the origin (o) field. + + The REGISTER and OPTIONS methods use the Call-ID value to + unambiguously match requests and responses. All REGISTER requests + issued by a single client SHOULD use the same Call-ID, at least + within the same boot cycle. + + + Since the Call-ID is generated by and for SIP, there is no + reason to deal with the complexity of URL-encoding and + case-ignoring string comparison. + + + + Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host + local-id = 1*uric + + + "host" SHOULD be either a fully qualified domain name or a globally + routable IP address. If this is the case, the "local-id" SHOULD be an + identifier consisting of URI characters that is unique within "host". + Use of cryptographically random identifiers [27] is RECOMMENDED. If, + however, host is not an FQDN or globally routable IP address (such as + a net 10 address), the local-id MUST be globally unique, as opposed + + + + + +Handley, et al. Standards Track [Page 46] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + to unique within host. These rules guarantee overall global + uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused + for a different call. Call-IDs are case-sensitive. + + + Using cryptographically random identifiers provides some + protection against session hijacking. Call-ID, To and From + are needed to identify a call leg. The distinction between + call and call leg matters in calls with third-party + control. + + For systems which have tight bandwidth constraints, many of the + mandatory SIP headers have a compact form, as discussed in Section 9. + These are alternate names for the headers which occupy less space in + the message. In the case of Call-ID, the compact form is i. + + For example, both of the following are valid: + + Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com + + + or + + i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com + + + +6.13 Contact + + The Contact general-header field can appear in INVITE, ACK, and + REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In + general, it provides a URL where the user can be reached for further + communications. + + INVITE and ACK requests: INVITE and ACK requests MAY contain Contact + headers indicating from which location the request is + originating. + + + This allows the callee to send future requests, such as + BYE, directly to the caller instead of through a series of + proxies. The Via header is not sufficient since the + desired address may be that of a proxy. + + INVITE 2xx responses: A user agent server sending a definitive, + positive response (2xx) MAY insert a Contact response header + field indicating the SIP address under which it is reachable + most directly for future SIP requests, such as ACK, within the + + + +Handley, et al. Standards Track [Page 47] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + same Call-ID. The Contact header field contains the address of + the server itself or that of a proxy, e.g., if the host is + behind a firewall. The value of this Contact header is copied + into the Request-URI of subsequent requests for this call if the + response did not also contain a Record-Route header. If the + response also contains a Record-Route header field, the address + in the Contact header field is added as the last item in the + Route header field. See Section 6.29 for details. + + + The Contact value SHOULD NOT be cached across calls, as it + may not represent the most desirable location for a + particular destination address. + + INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY + insert a Contact response header. It has the same semantics in a + 1xx response as a 2xx INVITE response. Note that CANCEL requests + MUST NOT be sent to that address, but rather follow the same + path as the original request. + + REGISTER requests: REGISTER requests MAY contain a Contact header + field indicating at which locations the user is reachable. The + REGISTER request defines a wildcard Contact field, "*", which + MUST only be used with Expires: 0 to remove all registrations + for a particular user. An optional "expires" parameter indicates + the desired expiration time of the registration. If a Contact + entry does not have an "expires" parameter, the Expires header + field is used as the default value. If neither of these + mechanisms is used, SIP URIs are assumed to expire after one + hour. Other URI schemes have no expiration times. + + REGISTER 2xx responses: A REGISTER response MAY return all locations + at which the user is currently reachable. An optional "expires" + parameter indicates the expiration time of the registration. If + a Contact entry does not have an "expires" parameter, the value + of the Expires header field indicates the expiration time. If + neither mechanism is used, the expiration time specified in the + request, explicitly or by default, is used. + + 3xx and 485 responses: The Contact response-header field can be used + with a 3xx or 485 (Ambiguous) response codes to indicate one or + more alternate addresses to try. It can appear in responses to + BYE, INVITE and OPTIONS methods. The Contact header field + contains URIs giving the new locations or user names to try, or + may simply specify additional transport parameters. A 300 + (Multiple Choices), 301 (Moved Permanently), 302 (Moved + Temporarily) or 485 (Ambiguous) response SHOULD contain a + Contact field containing URIs of new addresses to be tried. A + + + +Handley, et al. Standards Track [Page 48] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 301 or 302 response may also give the same location and username + that was being tried but specify additional transport parameters + such as a different server or multicast address to try or a + change of SIP transport from UDP to TCP or vice versa. The + client copies the "user", "password", "host", "port" and "user- + param" elements of the Contact URI into the Request-URI of the + redirected request and directs the request to the address + specified by the "maddr" and "port" parameters, using the + transport protocol given in the "transport" parameter. If + "maddr" is a multicast address, the value of "ttl" is used as + the time-to-live value. + + Note that the Contact header field MAY also refer to a different + entity than the one originally called. For example, a SIP call + connected to GSTN gateway may need to deliver a special information + announcement such as "The number you have dialed has been changed." + + A Contact response header field can contain any suitable URI + indicating where the called party can be reached, not limited to SIP + URLs. For example, it could contain URL's for phones, fax, or irc (if + they were defined) or a mailto: (RFC 2368, [28]) URL. + + The following parameters are defined. Additional parameters may be + defined in other specifications. + + q: The "qvalue" indicates the relative preference among the locations + given. "qvalue" values are decimal numbers from 0 to 1, with + higher values indicating higher preference. + + action: The "action" parameter is used only when registering with the + REGISTER request. It indicates whether the client wishes that + the server proxy or redirect future requests intended for the + client. If this parameter is not specified the action taken + depends on server configuration. In its response, the registrar + SHOULD indicate the mode used. This parameter is ignored for + other requests. + + expires: The "expires" parameter indicates how long the URI is valid. + The parameter is either a number indicating seconds or a quoted + string containing a SIP-date. If this parameter is not provided, + the value of the Expires header field determines how long the + URI is valid. Implementations MAY treat values larger than + 2**32-1 (4294967295 seconds or 136 years) as equivalent to + 2**32-1. + + + + Contact = ( "Contact" | "m" ) ":" + ("*" | (1# (( name-addr | addr-spec ) + [ *( ";" contact-params ) ] [ comment ] ))) + + name-addr = [ display-name ] "<" addr-spec ">" + addr-spec = SIP-URL | URI + display-name = *token | quoted-string + + contact-params = "q" "=" qvalue + | "action" "=" "proxy" | "redirect" + | "expires" "=" delta-seconds | <"> SIP-date <"> + | extension-attribute + + extension-attribute = extension-name [ "=" extension-value ] + + only allows one address, unquoted. Since URIs can contain + commas and semicolons as reserved characters, they can be + mistaken for header or parameter delimiters, respectively. + The current syntax corresponds to that for the To and From + header, which also allows the use of display names. + + Example: + + + Contact: "Mr. Watson" + ;q=0.7; expires=3600, + "Mr. Watson" ;q=0.1 + + + +6.14 Content-Encoding + + + + Content-Encoding = ( "Content-Encoding" | "e" ) ":" + 1#content-coding + + + The Content-Encoding entity-header field is used as a modifier to the + "media-type". When present, its value indicates what additional + content codings have been applied to the entity-body, and thus what + decoding mechanisms MUST be applied in order to obtain the media-type + referenced by the Content-Type header field. Content-Encoding is + primarily used to allow a body to be compressed without losing the + identity of its underlying media type. + + If multiple encodings have been applied to an entity, the content + codings MUST be listed in the order in which they were applied. + + All content-coding values are case-insensitive. The Internet Assigned + Numbers Authority (IANA) acts as a registry for content-coding value + tokens. See [3.5] for a definition of the syntax for content-coding. + + Clients MAY apply content encodings to the body in requests. If the + server is not capable of decoding the body, or does not recognize any + of the content-coding values, it MUST send a 415 "Unsupported Media + Type" response, listing acceptable encodings in the Accept-Encoding + + + +Handley, et al. Standards Track [Page 50] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + header. A server MAY apply content encodings to the bodies in + responses. The server MUST only use encodings listed in the Accept- + Encoding header in the request. + +6.15 Content-Length + + The Content-Length entity-header field indicates the size of the + message-body, in decimal number of octets, sent to the recipient. + + + + Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT + + + An example is + + Content-Length: 3495 + + + + Applications SHOULD use this field to indicate the size of the + message-body to be transferred, regardless of the media type of the + entity. Any Content-Length greater than or equal to zero is a valid + value. If no body is present in a message, then the Content-Length + header field MUST be set to zero. If a server receives a UDP request + without Content-Length, it MUST assume that the request encompasses + the remainder of the packet. If a server receives a UDP request with + a Content-Length, but the value is larger than the size of the body + sent in the request, the client SHOULD generate a 400 class response. + If there is additional data in the UDP packet after the last byte of + the body has been read, the server MUST treat the remaining data as a + separate message. This allows several messages to be placed in a + single UDP packet. + + If a response does not contain a Content-Length, the client assumes + that it encompasses the remainder of the UDP packet or the data until + the TCP connection is closed, as applicable. Section 8 describes how + to determine the length of the message body. + +6.16 Content-Type + + The Content-Type entity-header field indicates the media type of the + message-body sent to the recipient. The "media-type" element is + defined in [H3.7]. + + + + Content-Type = ( "Content-Type" | "c" ) ":" media-type + + + +Handley, et al. Standards Track [Page 51] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Examples of this header field are + + Content-Type: application/sdp + Content-Type: text/html; charset=ISO-8859-4 + + + +6.17 CSeq + + Clients MUST add the CSeq (command sequence) general-header field to + every request. A CSeq header field in a request contains the request + method and a single decimal sequence number chosen by the requesting + client, unique within a single value of Call-ID. The sequence number + MUST be expressible as a 32-bit unsigned integer. The initial value + of the sequence number is arbitrary, but MUST be less than 2**31. + Consecutive requests that differ in request method, headers or body, + but have the same Call-ID MUST contain strictly monotonically + increasing and contiguous sequence numbers; sequence numbers do not + wrap around. Retransmissions of the same request carry the same + sequence number, but an INVITE with a different message body or + different header fields (a "re-invitation") acquires a new, higher + sequence number. A server MUST echo the CSeq value from the request + in its response. If the Method value is missing in the received CSeq + header field, the server fills it in appropriately. + + The ACK and CANCEL requests MUST contain the same CSeq value as the + INVITE request that it refers to, while a BYE request cancelling an + invitation MUST have a higher sequence number. A BYE request with a + CSeq that is not higher should cause a 400 response to be generated. + + A user agent server MUST remember the highest sequence number for any + INVITE request with the same Call-ID value. The server MUST respond + to, and then discard, any INVITE request with a lower sequence + number. + + All requests spawned in a parallel search have the same CSeq value as + the request triggering the parallel search. + + + + CSeq = "CSeq" ":" 1*DIGIT Method + + + + Strictly speaking, CSeq header fields are needed for any + SIP request that can be cancelled by a BYE or CANCEL + request or where a client can issue several requests for + the same Call-ID in close succession. Without a sequence + + + +Handley, et al. Standards Track [Page 52] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + number, the response to an INVITE could be mistaken for the + response to the cancellation (BYE or CANCEL). Also, if the + network duplicates packets or if an ACK is delayed until + the server has sent an additional response, the client + could interpret an old response as the response to a re- + invitation issued shortly thereafter. Using CSeq also makes + it easy for the server to distinguish different versions of + an invitation, without comparing the message body. + + The Method value allows the client to distinguish the response to an + INVITE request from that of a CANCEL response. CANCEL requests can be + generated by proxies; if they were to increase the sequence number, + it might conflict with a later request issued by the user agent for + the same call. + + With a length of 32 bits, a server could generate, within a single + call, one request a second for about 136 years before needing to wrap + around. The initial value of the sequence number is chosen so that + subsequent requests within the same call will not wrap around. A + non-zero initial value allows to use a time-based initial sequence + number, if the client desires. A client could, for example, choose + the 31 most significant bits of a 32-bit second clock as an initial + sequence number. + + Forked requests MUST have the same CSeq as there would be ambiguity + otherwise between these forked requests and later BYE issued by the + client user agent. + + Example: + + + CSeq: 4711 INVITE + + + +6.18 Date + + Date is a general-header field. Its syntax is: + + + + SIP-date = rfc1123-date + + + See [H14.19] for a definition of rfc1123-date. Note that unlike + HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting + for dates. + + + + +Handley, et al. Standards Track [Page 53] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The Date header field reflects the time when the request or response + is first sent. Thus, retransmissions have the same Date header field + value as the original. + + + The Date header field can be used by simple end systems + without a battery-backed clock to acquire a notion of + current time. + +6.19 Encryption + + The Encryption general-header field specifies that the content has + been encrypted. Section 13 describes the overall SIP security + architecture and algorithms. This header field is intended for end- + to-end encryption of requests and responses. Requests are encrypted + based on the public key belonging to the entity named in the To + header field. Responses are encrypted based on the public key + conveyed in the Response-Key header field. Note that the public keys + themselves may not be used for the encryption. This depends on the + particular algorithms used. + + For any encrypted message, at least the message body and possibly + other message header fields are encrypted. An application receiving a + request or response containing an Encryption header field decrypts + the body and then concatenates the plaintext to the request line and + headers of the original message. Message headers in the decrypted + part completely replace those with the same field name in the + plaintext part. (Note: If only the body of the message is to be + encrypted, the body has to be prefixed with CRLF to allow proper + concatenation.) Note that the request method and Request-URI cannot + be encrypted. + + + Encryption only provides privacy; the recipient has no + guarantee that the request or response came from the party + listed in the From message header, only that the sender + used the recipient's public key. However, proxies will not + be able to modify the request or response. + + + + Encryption = "Encryption" ":" encryption-scheme 1*SP + #encryption-params + encryption-scheme = token + encryption-params = token "=" ( token | quoted-string ) + + The token indicates the form of encryption used; it is + described in section 13. + + + +Handley, et al. Standards Track [Page 54] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The example in Figure 10 shows a message encrypted with ASCII-armored + PGP that was generated by applying "pgp -ea" to the payload to be + encrypted. + + + INVITE sip:watson@boston.bell-telephone.com SIP/2.0 + Via: SIP/2.0/UDP 169.130.12.5 + From: + To: T. A. Watson + Call-ID: 187602141351@worcester.bell-telephone.com + Content-Length: 885 + Encryption: PGP version=2.6.2,encoding=ascii + + hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red + h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs + ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR + RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA + zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu + X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 + IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ + GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E + WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed + wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO + z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ + 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 + z8X9N4MhMyXEVuC9rt8/AUhmVQ== + =bOW+ + + + + Figure 10: PGP Encryption Example + + + + Since proxies can base their forwarding decision on any combination + of SIP header fields, there is no guarantee that an encrypted request + "hiding" header fields will reach the same destination as an + otherwise identical un-encrypted request. + +6.20 Expires + + The Expires entity-header field gives the date and time after which + the message content expires. + + This header field is currently defined only for the REGISTER and + INVITE methods. For REGISTER, it is a request and response-header + field. In a REGISTER request, the client indicates how long it wishes + the registration to be valid. In the response, the server indicates + + + +Handley, et al. Standards Track [Page 55] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + the earliest expiration time of all registrations. The server MAY + choose a shorter time interval than that requested by the client, but + SHOULD NOT choose a longer one. + + For INVITE requests, it is a request and response-header field. In a + request, the caller can limit the validity of an invitation, for + example, if a client wants to limit the time duration of a search or + a conference invitation. A user interface MAY take this as a hint to + leave the invitation window on the screen even if the user is not + currently at the workstation. This also limits the duration of a + search. If the request expires before the search completes, the proxy + returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) + response, a server can advise the client of the maximal duration of + the redirection. + + The value of this field can be either a SIP-date or an integer number + of seconds (in decimal), measured from the receipt of the request. + The latter approach is preferable for short durations, as it does not + depend on clients and servers sharing a synchronized clock. + Implementations MAY treat values larger than 2**32-1 (4294967295 or + 136 years) as equivalent to 2**32-1. + + + + Expires = "Expires" ":" ( SIP-date | delta-seconds ) + + + Two examples of its use are + + Expires: Thu, 01 Dec 1994 16:00:00 GMT + Expires: 5 + + + +6.21 From + + Requests and responses MUST contain a From general-header field, + indicating the initiator of the request. The From field MAY contain + the "tag" parameter. The server copies the From header field from the + request to the response. The optional "display-name" is meant to be + rendered by a human-user interface. A system SHOULD use the display + name "Anonymous" if the identity of the client is to remain hidden. + + The SIP-URL MUST NOT contain the "transport-param", "maddr-param", + "ttl-param", or "headers" elements. A server that receives a SIP-URL + with these elements removes them before further processing. + + + + + +Handley, et al. Standards Track [Page 56] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Even if the "display-name" is empty, the "name-addr" form MUST be + used if the "addr-spec" contains a comma, question mark, or + semicolon. + + + + From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) + *( ";" addr-params ) + addr-params = tag-param + tag-param = "tag=" UUID + UUID = 1*( hex | "-" ) + + + Examples: + + + From: "A. G. Bell" + From: sip:+12125551212@server.phone2net.com + From: Anonymous + + + + The "tag" MAY appear in the From field of a request. It MUST be + present when it is possible that two instances of a user sharing a + SIP address can make call invitations with the same Call-ID. + + The "tag" value MUST be globally unique and cryptographically random + with at least 32 bits of randomness. A single user maintains the same + tag throughout the call identified by the Call-ID. + + + Call-ID, To and From are needed to identify a call leg. + The distinction between call and call leg matters in calls + with multiple responses to a forked request. The format is + similar to the equivalent RFC 822 [24] header, but with a + URI instead of just an email address. + +6.22 Hide + + A client uses the Hide request header field to indicate that it wants + the path comprised of the Via header fields (Section 6.40) to be + hidden from subsequent proxies and user agents. It can take two + forms: Hide: route and Hide: hop. Hide header fields are typically + added by the client user agent, but MAY be added by any proxy along + the path. + + + + + + +Handley, et al. Standards Track [Page 57] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + If a request contains the "Hide: route" header field, all following + proxies SHOULD hide their previous hop. If a request contains the + "Hide: hop" header field, only the next proxy SHOULD hide the + previous hop and then remove the Hide option unless it also wants to + remain anonymous. + + A server hides the previous hop by encrypting the "host" and "port" + parts of the top-most Via header field with an algorithm of its + choice. Servers SHOULD add additional "salt" to the "host" and "port" + information prior to encryption to prevent malicious downstream + proxies from guessing earlier parts of the path based on seeing + identical encrypted Via headers. Hidden Via fields are marked with + the "hidden" Via option, as described in Section 6.40. + + A server that is capable of hiding Via headers MUST attempt to + decrypt all Via headers marked as "hidden" to perform loop detection. + Servers that are not capable of hiding can ignore hidden Via fields + in their loop detection algorithm. + + + If hidden headers were not marked, a proxy would have to + decrypt all headers to detect loops, just in case one was + encrypted, as the Hide: Hop option may have been removed + along the way. + + A host MUST NOT add such a "Hide: hop" header field unless it can + guarantee it will only send a request for this destination to the + same next hop. The reason for this is that it is possible that the + request will loop back through this same hop from a downstream proxy. + The loop will be detected by the next hop if the choice of next hop + is fixed, but could loop an arbitrary number of times otherwise. + + A client requesting "Hide: route" can only rely on keeping the + request path private if it sends the request to a trusted proxy. + Hiding the route of a SIP request is of limited value if the request + results in data packets being exchanged directly between the calling + and called user agent. + + The use of Hide header fields is discouraged unless path privacy is + truly needed; Hide fields impose extra processing costs and + restrictions for proxies and can cause requests to generate 482 (Loop + Detected) responses that could otherwise be avoided. + + The encryption of Via header fields is described in more detail in + Section 13. + + The Hide header field has the following syntax: + + + + +Handley, et al. Standards Track [Page 58] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Hide = "Hide" ":" ( "route" | "hop" ) + + +6.23 Max-Forwards + + The Max-Forwards request-header field may be used with any SIP method + to limit the number of proxies or gateways that can forward the + request to the next downstream server. This can also be useful when + the client is attempting to trace a request chain which appears to be + failing or looping in mid-chain. + + + + Max-Forwards = "Max-Forwards" ":" 1*DIGIT + + + The Max-Forwards value is a decimal integer indicating the remaining + number of times this request message is allowed to be forwarded. + + Each proxy or gateway recipient of a request containing a Max- + Forwards header field MUST check and update its value prior to + forwarding the request. If the received value is zero (0), the + recipient MUST NOT forward the request. Instead, for the OPTIONS and + REGISTER methods, it MUST respond as the final recipient. For all + other methods, the server returns 483 (Too many hops). + + If the received Max-Forwards value is greater than zero, then the + forwarded message MUST contain an updated Max-Forwards field with a + value decremented by one (1). + + Example: + + Max-Forwards: 6 + + + +6.24 Organization + + The Organization general-header field conveys the name of the + organization to which the entity issuing the request or response + belongs. It MAY also be inserted by proxies at the boundary of an + organization. + + + The field MAY be used by client software to filter calls. + + + + + + +Handley, et al. Standards Track [Page 59] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Organization = "Organization" ":" *TEXT-UTF8 + + +6.25 Priority + + The Priority request-header field indicates the urgency of the + request as perceived by the client. + + + + Priority = "Priority" ":" priority-value + priority-value = "emergency" | "urgent" | "normal" + | "non-urgent" + + + It is RECOMMENDED that the value of "emergency" only be used when + life, limb or property are in imminent danger. + + Examples: + + + Subject: A tornado is heading our way! + Priority: emergency + + Subject: Weekend plans + Priority: non-urgent + + + + + These are the values of RFC 2076 [30], with the addition of + "emergency". + +6.26 Proxy-Authenticate + + The Proxy-Authenticate response-header field MUST be included as part + of a 407 (Proxy Authentication Required) response. The field value + consists of a challenge that indicates the authentication scheme and + parameters applicable to the proxy for this Request-URI. + + Unlike its usage within HTTP, the Proxy-Authenticate header MUST be + passed upstream in the response to the UAC. In SIP, only UAC's can + authenticate themselves to proxies. + + The syntax for this header is defined in [H14.33]. See 14 for further + details on its usage. + + + + + +Handley, et al. Standards Track [Page 60] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + A client SHOULD cache the credentials used for a particular proxy + server and realm for the next request to that server. Credentials + are, in general, valid for a specific value of the Request-URI at a + particular proxy server. If a client contacts a proxy server that has + required authentication in the past, but the client does not have + credentials for the particular Request-URI, it MAY attempt to use the + most-recently used credential. The server responds with 401 + (Unauthorized) if the client guessed wrong. + + + This suggested caching behavior is motivated by proxies + restricting phone calls to authenticated users. It seems + likely that in most cases, all destinations require the + same password. Note that end-to-end authentication is + likely to be destination-specific. + +6.27 Proxy-Authorization + + The Proxy-Authorization request-header field allows the client to + identify itself (or its user) to a proxy which requires + authentication. The Proxy-Authorization field value consists of + credentials containing the authentication information of the user + agent for the proxy and/or realm of the resource being requested. + + Unlike Authorization, the Proxy-Authorization header field applies + only to the next outbound proxy that demanded authentication using + the Proxy- Authenticate field. When multiple proxies are used in a + chain, the Proxy-Authorization header field is consumed by the first + outbound proxy that was expecting to receive credentials. A proxy MAY + relay the credentials from the client request to the next proxy if + that is the mechanism by which the proxies cooperatively authenticate + a given request. + + See [H14.34] for a definition of the syntax, and section 14 for a + discussion of its usage. + +6.28 Proxy-Require + + The Proxy-Require header field is used to indicate proxy-sensitive + features that MUST be supported by the proxy. Any Proxy-Require + header field features that are not supported by the proxy MUST be + negatively acknowledged by the proxy to the client if not supported. + Proxy servers treat this field identically to the Require field. + + See Section 6.30 for more details on the mechanics of this message + and a usage example. + + + + + +Handley, et al. Standards Track [Page 61] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.29 Record-Route + + The Record-Route request and response header field is added to a + request by any proxy that insists on being in the path of subsequent + requests for the same call leg. It contains a globally reachable + Request-URI that identifies the proxy server. Each proxy server adds + its Request-URI to the beginning of the list. + + The server copies the Record-Route header field unchanged into the + response. (Record-Route is only relevant for 2xx responses.) + + The calling user agent client copies the Record-Route header into a + Route header field of subsequent requests within the same call leg, + reversing the order of requests, so that the first entry is closest + to the user agent client. If the response contained a Contact header + field, the calling user agent adds its content as the last Route + header. Unless this would cause a loop, any client MUST send any + subsequent requests for this call leg to the first Request-URI in the + Route request header field and remove that entry. + + The calling user agent MUST NOT use the Record-Route header field in + requests that contain Route header fields. + + + Some proxies, such as those controlling firewalls or in an + automatic call distribution (ACD) system, need to maintain + call state and thus need to receive any BYE and ACK packets + for the call. + + The Record-Route header field has the following syntax: + + + Record-Route = "Record-Route" ":" 1# name-addr + + + Proxy servers SHOULD use the "maddr" URL parameter containing their + address to ensure that subsequent requests are guaranteed to reach + exactly the same server. + + Example for a request that has traversed the hosts ieee.org and + bell-telephone.com , in that order: + + Record-Route: , + + + + + + + + +Handley, et al. Standards Track [Page 62] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.30 Require + + The Require request-header field is used by clients to tell user + agent servers about options that the client expects the server to + support in order to properly process the request. If a server does + not understand the option, it MUST respond by returning status code + 420 (Bad Extension) and list those options it does not understand in + the Unsupported header. + + + + Require = "Require" ":" 1#option-tag + + + Example: + + C->S: INVITE sip:watson@bell-telephone.com SIP/2.0 + Require: com.example.billing + Payment: sheep_skins, conch_shells + + S->C: SIP/2.0 420 Bad Extension + Unsupported: com.example.billing + + + + This is to make sure that the client-server interaction + will proceed without delay when all options are understood + by both sides, and only slow down if options are not + understood (as in the example above). For a well-matched + client-server pair, the interaction proceeds quickly, + saving a round-trip often required by negotiation + mechanisms. In addition, it also removes ambiguity when the + client requires features that the server does not + understand. Some features, such as call handling fields, + are only of interest to end systems. + + Proxy and redirect servers MUST ignore features that are not + understood. If a particular extension requires that intermediate + devices support it, the extension MUST be tagged in the Proxy-Require + field as well (see Section 6.28). + +6.31 Response-Key + + The Response-Key request-header field can be used by a client to + request the key that the called user agent SHOULD use to encrypt the + response with. The syntax is: + + + + + +Handley, et al. Standards Track [Page 63] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param + key-scheme = token + key-param = token "=" ( token | quoted-string ) + + + The "key-scheme" gives the type of encryption to be used for the + response. Section 13 describes security schemes. + + If the client insists that the server return an encrypted response, + it includes a + + Require: org.ietf.sip.encrypt-response + + header field in its request. If the server cannot encrypt for + whatever reason, it MUST follow normal Require header field + procedures and return a 420 (Bad Extension) response. If this Require + header field is not present, a server SHOULD still encrypt if it can. + +6.32 Retry-After + + The Retry-After general-header field can be used with a 503 (Service + Unavailable) response to indicate how long the service is expected to + be unavailable to the requesting client and with a 404 (Not Found), + 600 (Busy), or 603 (Decline) response to indicate when the called + party anticipates being available again. The value of this field can + be either an SIP-date or an integer number of seconds (in decimal) + after the time of the response. + + A REGISTER request MAY include this header field when deleting + registrations with "Contact: * ;expires: 0". The Retry-After value + then indicates when the user might again be reachable. The registrar + MAY then include this information in responses to future calls. + + An optional comment can be used to indicate additional information + about the time of callback. An optional "duration" parameter + indicates how long the called party will be reachable starting at the + initial time of availability. If no duration parameter is given, the + service is assumed to be available indefinitely. + + + + Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds ) + [ comment ] [ ";" "duration" "=" delta-seconds ] + + + Examples of its use are + + Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting) + + + +Handley, et al. Standards Track [Page 64] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Retry-After: Mon, 01 Jan 9999 00:00:00 GMT + (Dear John: Don't call me back, ever) + Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600 + Retry-After: 120 + + + + In the third example, the callee is reachable for one hour starting + at 21:00 GMT. In the last example, the delay is 2 minutes. + +6.33 Route + + The Route request-header field determines the route taken by a + request. Each host removes the first entry and then proxies the + request to the host listed in that entry, also using it as the + Request-URI. The operation is further described in Section 6.29. + + The Route header field has the following syntax: + + + Route = "Route" ":" 1# name-addr + + +6.34 Server + + The Server response-header field contains information about the + software used by the user agent server to handle the request. The + syntax for this field is defined in [H14.39]. + +6.35 Subject + + This is intended to provide a summary, or to indicate the nature, of + the call, allowing call filtering without having to parse the session + description. (Also, the session description does not have to use the + same subject indication as the invitation.) + + + + Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8 + + + Example: + + + Subject: Tune in - they are talking about your work! + + + + + + +Handley, et al. Standards Track [Page 65] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.36 Timestamp + + The timestamp general-header field describes when the client sent the + request to the server. The value of the timestamp is of significance + only to the client and it MAY use any timescale. The server MUST echo + the exact same value and MAY, if it has accurate information about + this, add a floating point number indicating the number of seconds + that have elapsed since it has received the request. The timestamp is + used by the client to compute the round-trip time to the server so + that it can adjust the timeout value for retransmissions. + + + + Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] + delay = *(DIGIT) [ "." *(DIGIT) ] + + + Note that there MUST NOT be any LWS between a DIGIT and the decimal + point. + +6.37 To + + The To general-header field specifies recipient of the request, with + the same SIP URL syntax as the From field. + + + + To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) + *( ";" addr-params ) + + + Requests and responses MUST contain a To general-header field, + indicating the desired recipient of the request. The optional + "display-name" is meant to be rendered by a human-user interface. + The UAS or redirect server copies the To header field into its + response, and MUST add a "tag" parameter if the request contained + more than one Via header field. + + + If there was more than one Via header field, the request + was handled by at least one proxy server. Since the + receiver cannot know whether any of the proxy servers + forked the request, it is safest to assume that they might + have. + + The SIP-URL MUST NOT contain the "transport-param", "maddr-param", + "ttl-param", or "headers" elements. A server that receives a SIP-URL + with these elements removes them before further processing. + + + +Handley, et al. Standards Track [Page 66] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The "tag" parameter serves as a general mechanism to distinguish + multiple instances of a user identified by a single SIP URL. As + proxies can fork requests, the same request can reach multiple + instances of a user (mobile and home phones, for example). As each + can respond, there needs to be a means to distinguish the responses + from each at the caller. The situation also arises with multicast + requests. The tag in the To header field serves to distinguish + responses at the UAC. It MUST be placed in the To field of the + response by each instance when there is a possibility that the + request was forked at an intermediate proxy. The "tag" MUST be added + by UAS, registrars and redirect servers, but MUST NOT be inserted + into responses forwarded upstream by proxies. The "tag" is added for + all definitive responses for all methods, and MAY be added for + informational responses from a UAS or redirect server. All subsequent + transactions between two entities MUST include the "tag" parameter, + as described in Section 11. + + See Section 6.21 for details of the "tag" parameter. + + The "tag" parameter in To headers is ignored when matching responses + to requests that did not contain a "tag" in their To header. + + A SIP server returns a 400 (Bad Request) response if it receives a + request with a To header field containing a URI with a scheme it does + not recognize. + + Even if the "display-name" is empty, the "name-addr" form MUST be + used if the "addr-spec" contains a comma, question mark, or + semicolon. + + The following are examples of valid To headers: + + To: The Operator ;tag=287447 + To: sip:+12125551212@server.phone2net.com + + + + + Call-ID, To and From are needed to identify a call leg. + The distinction between call and call leg matters in calls + with multiple responses from a forked request. The "tag" is + added to the To header field in the response to allow + forking of future requests for the same call by proxies, + while addressing only one of the possibly several + responding user agent servers. It also allows several + instances of the callee to send requests that can be + distinguished. + + + + +Handley, et al. Standards Track [Page 67] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +6.38 Unsupported + + The Unsupported response-header field lists the features not + supported by the server. See Section 6.30 for a usage example and + motivation. + + Syntax: + + + + Unsupported = "Unsupported" ":" 1#option-tag + + +6.39 User-Agent + + The User-Agent general-header field contains information about the + client user agent originating the request. The syntax and semantics + are defined in [H14.42]. + +6.40 Via + + The Via field indicates the path taken by the request so far. This + prevents request looping and ensures replies take the same path as + the requests, which assists in firewall traversal and other unusual + routing situations. + +6.40.1 Requests + + The client originating the request MUST insert into the request a Via + field containing its host name or network address and, if not the + default port number, the port number at which it wishes to receive + responses. (Note that this port number can differ from the UDP source + port number of the request.) A fully-qualified domain name is + RECOMMENDED. Each subsequent proxy server that sends the request + onwards MUST add its own additional Via field before any existing Via + fields. A proxy that receives a redirection (3xx) response and then + searches recursively, MUST use the same Via headers as on the + original proxied request. + + A proxy SHOULD check the top-most Via header field to ensure that it + contains the sender's correct network address, as seen from that + proxy. If the sender's address is incorrect, the proxy MUST add an + additional "received" attribute, as described 6.40.2. + + + A host behind a network address translator (NAT) or + firewall may not be able to insert a network address into + the Via header that can be reached by the next hop beyond + + + +Handley, et al. Standards Track [Page 68] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + the NAT. Use of the received attribute allows SIP requests + to traverse NAT's which only modify the source IP address. + NAT's which modify port numbers, called Network Address + Port Translator's (NAPT) will not properly pass SIP when + transported on UDP, in which case an application layer + gateway is required. When run over TCP, SIP stands a better + chance of traversing NAT's, since its behavior is similar + to HTTP in this case (but of course on different ports). + + A proxy sending a request to a multicast address MUST add the "maddr" + parameter to its Via header field, and SHOULD add the "ttl" + parameter. If a server receives a request which contained an "maddr" + parameter in the topmost Via field, it SHOULD send the response to + the multicast address listed in the "maddr" parameter. + + If a proxy server receives a request which contains its own address + in the Via header value, it MUST respond with a 482 (Loop Detected) + status code. + + A proxy server MUST NOT forward a request to a multicast group which + already appears in any of the Via headers. + + + This prevents a malfunctioning proxy server from causing + loops. Also, it cannot be guaranteed that a proxy server + can always detect that the address returned by a location + service refers to a host listed in the Via list, as a + single host may have aliases or several network interfaces. + +6.40.2 Receiver-tagged Via Header Fields + + Normally, every host that sends or forwards a SIP message adds a Via + field indicating the path traversed. However, it is possible that + Network Address Translators (NATs) changes the source address and + port of the request (e.g., from net-10 to a globally routable + address), in which case the Via header field cannot be relied on to + route replies. To prevent this, a proxy SHOULD check the top-most Via + header field to ensure that it contains the sender's correct network + address, as seen from that proxy. If the sender's address is + incorrect, the proxy MUST add a "received" parameter to the Via + header field inserted by the previous hop. Such a modified Via header + field is known as a receiver-tagged Via header field. An example is: + + + Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 + Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3 + + + + + +Handley, et al. Standards Track [Page 69] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + In this example, the message originated from 10.0.0.1 and traversed a + NAT with the external address border.ieee.org (199.172.136.3) to + reach erlang.bell-telephone.com. The latter noticed the mismatch, + and added a parameter to the previous hop's Via header field, + containing the address that the packet actually came from. (Note that + the NAT border.ieee.org is not a SIP server.) + +6.40.3 Responses + + Via header fields in responses are processed by a proxy or UAC + according to the following rules: + + 1. The first Via header field should indicate the proxy or + client processing this response. If it does not, discard + the message. Otherwise, remove this Via field. + + 2. If there is no second Via header field, this response is + destined for this client. Otherwise, the processing depends + on whether the Via field contains a "maddr" parameter or is + a receiver-tagged field: + + - If the second Via header field contains a "maddr" + parameter, send the response to the multicast address + listed there, using the port indicated in "sent-by", or + port 5060 if none is present. The response SHOULD be sent + using the TTL indicated in the "ttl" parameter, or with a + TTL of 1 if that parameter is not present. For + robustness, responses MUST be sent to the address + indicated in the "maddr" parameter even if it is not a + multicast address. + + - If the second Via header field does not contain a "maddr" + parameter and is a receiver-tagged field (Section + 6.40.2), send the message to the address in the + "received" parameter, using the port indicated in the + "sent-by" value, or using port 5060 if none is present. + + - If neither of the previous cases apply, send the message + to the address indicated by the "sent-by" value in the + second Via header field. + +6.40.4 User Agent and Redirect Servers + + A UAS or redirect server sends a response based on one of the + following rules: + + o If the first Via header field in the request contains a + "maddr" parameter, send the response to the multicast address + + + +Handley, et al. Standards Track [Page 70] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + listed there, using the port indicated in "sent-by", or port + 5060 if none is present. The response SHOULD be sent using the + TTL indicated in the "ttl" parameter, or with a TTL of 1 if + that parameter is not present. For robustness, responses MUST + be sent to the address indicated in the "maddr" parameter even + if it is not a multicast address. + + o If the address in the "sent-by" value of the first Via field + differs from the source address of the packet, send the + response to the actual packet source address, similar to the + treatment for receiver-tagged Via header fields (Section + 6.40.2). + + o If neither of these conditions is true, send the response to + the address contained in the "sent-by" value. If the request + was sent using TCP, use the existing TCP connection if + available. + +6.40.5 Syntax + + The format for a Via header field is shown in Fig. 11. The defaults + for "protocol-name" and "transport" are "SIP" and "UDP", + respectively. The "maddr" parameter, designating the multicast + address, and the "ttl" parameter, designating the time-to-live (TTL) + value, are included only if the request was sent via multicast. The + "received" parameter is added only for receiver-added Via fields + (Section 6.40.2). For reasons of privacy, a client or proxy may wish + to hide its Via information by encrypting it (see Section 6.22). The + "hidden" parameter is included if this header field was hidden by the + upstream proxy (see 6.22). Note that privacy of the proxy relies on + the cooperation of the next hop, as the next-hop proxy will, by + necessity, know the IP address and port number of the source host. + + + The "branch" parameter is included by every forking proxy. The token + MUST be unique for each distinct request generated when a proxy + forks. CANCEL requests MUST have the same branch value as the + corresponding forked request. When a response arrives at the proxy it + can use the branch value to figure out which branch the response + corresponds to. A proxy which generates a single request (non- + forking) MAY also insert the "branch" parameter. The identifier has + to be unique only within a set of isomorphic requests. + + + Via: SIP/2.0/UDP first.example.com:4000;ttl=16 + ;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example) + Via: SIP/2.0/UDP adk8 + + + + +Handley, et al. Standards Track [Page 71] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by + *( ";" via-params ) [ comment ] ) + via-params = via-hidden | via-ttl | via-maddr + | via-received | via-branch + via-hidden = "hidden" + via-ttl = "ttl" "=" ttl + via-maddr = "maddr" "=" maddr + via-received = "received" "=" host + via-branch = "branch" "=" token + sent-protocol = protocol-name "/" protocol-version "/" transport + protocol-name = "SIP" | token + protocol-version = token + transport = "UDP" | "TCP" | token + sent-by = ( host [ ":" port ] ) | ( concealed-host ) + concealed-host = token + ttl = 1*3DIGIT ; 0 to 255 + + + Figure 11: Syntax of Via header field + + +6.41 Warning + + The Warning response-header field is used to carry additional + information about the status of a response. Warning headers are sent + with responses and have the following format: + + + + Warning = "Warning" ":" 1#warning-value + warning-value = warn-code SP warn-agent SP warn-text + warn-code = 3DIGIT + warn-agent = ( host [ ":" port ] ) | pseudonym + ; the name or pseudonym of the server adding + ; the Warning header, for use in debugging + warn-text = quoted-string + + + A response MAY carry more than one Warning header. + + The "warn-text" should be in a natural language that is most likely + to be intelligible to the human user receiving the response. This + decision can be based on any available knowledge, such as the + location of the cache or user, the Accept-Language field in a + request, or the Content-Language field in a response. The default + language is i-default [31]. + + + +Handley, et al. Standards Track [Page 72] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Any server MAY add Warning headers to a response. Proxy servers MUST + place additional Warning headers before any Authorization headers. + Within that constraint, Warning headers MUST be added after any + existing Warning headers not covered by a signature. A proxy server + MUST NOT delete any Warning header field that it received with a + response. + + When multiple Warning headers are attached to a response, the user + agent SHOULD display as many of them as possible, in the order that + they appear in the response. If it is not possible to display all of + the warnings, the user agent first displays warnings that appear + early in the response. + + The warn-code consists of three digits. A first digit of "3" + indicates warnings specific to SIP. + + This is a list of the currently-defined "warn-code"s, each with a + recommended warn-text in English, and a description of its meaning. + Note that these warnings describe failures induced by the session + description. + + Warnings 300 through 329 are reserved for indicating problems with + keywords in the session description, 330 through 339 are warnings + related to basic network services requested in the session + description, 370 through 379 are warnings related to quantitative QoS + parameters requested in the session description, and 390 through 399 + are miscellaneous warnings that do not fall into one of the above + categories. + + 300 Incompatible network protocol: One or more network protocols + contained in the session description are not available. + + 301 Incompatible network address formats: One or more network address + formats contained in the session description are not available. + + 302 Incompatible transport protocol: One or more transport protocols + described in the session description are not available. + + 303 Incompatible bandwidth units: One or more bandwidth measurement + units contained in the session description were not understood. + + 304 Media type not available: One or more media types contained in + the session description are not available. + + 305 Incompatible media format: One or more media formats contained in + the session description are not available. + + + + + +Handley, et al. Standards Track [Page 73] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 306 Attribute not understood: One or more of the media attributes in + the session description are not supported. + + 307 Session description parameter not understood: A parameter other + than those listed above was not understood. + + 330 Multicast not available: The site where the user is located does + not support multicast. + + 331 Unicast not available: The site where the user is located does + not support unicast communication (usually due to the presence + of a firewall). + + 370 Insufficient bandwidth: The bandwidth specified in the session + description or defined by the media exceeds that known to be + available. + + 399 Miscellaneous warning: The warning text can include arbitrary + information to be presented to a human user, or logged. A system + receiving this warning MUST NOT take any automated action. + + + 1xx and 2xx have been taken by HTTP/1.1. + + Additional "warn-code"s, as in the example below, can be defined + through IANA. + + Examples: + + + Warning: 307 isi.edu "Session parameter 'foo' not understood" + Warning: 301 isi.edu "Incompatible network address type 'E.164'" + + + +6.42 WWW-Authenticate + + The WWW-Authenticate response-header field MUST be included in 401 + (Unauthorized) response messages. The field value consists of at + least one challenge that indicates the authentication scheme(s) and + parameters applicable to the Request-URI. See [H14.46] for a + definition of the syntax, and section 14 for an overview of usage. + + The content of the "realm" parameter SHOULD be displayed to the user. + A user agent SHOULD cache the authorization credentials for a given + value of the destination (To header) and "realm" and attempt to re- + use these values on the next request for that destination. + + + + +Handley, et al. Standards Track [Page 74] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + In addition to the "basic" and "digest" authentication schemes + defined in the specifications cited above, SIP defines a new scheme, + PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are + for further study. + +7 Status Code Definitions + + The response codes are consistent with, and extend, HTTP/1.1 response + codes. Not all HTTP/1.1 response codes are appropriate, and only + those that are appropriate are given here. Other HTTP/1.1 response + codes SHOULD NOT be used. Response codes not defined by HTTP/1.1 have + codes x80 upwards to avoid clashes with future HTTP response codes. + Also, SIP defines a new class, 6xx. The default behavior for unknown + response codes is given for each category of codes. + +7.1 Informational 1xx + + Informational responses indicate that the server or proxy contacted + is performing some further action and does not yet have a definitive + response. The client SHOULD wait for a further response from the + server, and the server SHOULD send such a response without further + prompting. A server SHOULD send a 1xx response if it expects to take + more than 200 ms to obtain a final response. A server MAY issue zero + or more 1xx responses, with no restriction on their ordering or + uniqueness. Note that 1xx responses are not transmitted reliably, + that is, they do not cause the client to send an ACK. Servers are + free to retransmit informational responses and clients can inquire + about the current state of call processing by re-sending the request. + +7.1.1 100 Trying + + Some unspecified action is being taken on behalf of this call (e.g., + a database is being consulted), but the user has not yet been + located. + +7.1.2 180 Ringing + + The called user agent has located a possible location where the user + has registered recently and is trying to alert the user. + +7.1.3 181 Call Is Being Forwarded + + A proxy server MAY use this status code to indicate that the call is + being forwarded to a different set of destinations. + + + + + + + +Handley, et al. Standards Track [Page 75] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.1.4 182 Queued + + The called party is temporarily unavailable, but the callee has + decided to queue the call rather than reject it. When the callee + becomes available, it will return the appropriate final status + response. The reason phrase MAY give further details about the status + of the call, e.g., "5 calls queued; expected waiting time is 15 + minutes". The server MAY issue several 182 responses to update the + caller about the status of the queued call. + +7.2 Successful 2xx + + The request was successful and MUST terminate a search. + +7.2.1 200 OK + + The request has succeeded. The information returned with the response + depends on the method used in the request, for example: + + BYE: The call has been terminated. The message body is empty. + + CANCEL: The search has been cancelled. The message body is empty. + + INVITE: The callee has agreed to participate; the message body + indicates the callee's capabilities. + + OPTIONS: The callee has agreed to share its capabilities, included in + the message body. + + REGISTER: The registration has succeeded. The client treats the + message body according to its Content-Type. + +7.3 Redirection 3xx + + 3xx responses give information about the user's new location, or + about alternative services that might be able to satisfy the call. + They SHOULD terminate an existing search, and MAY cause the initiator + to begin a new search if appropriate. + + Any redirection (3xx) response MUST NOT suggest any of the addresses + in the Via (Section 6.40) path of the request in the Contact header + field. (Addresses match if their host and port number match.) + + To avoid forwarding loops, a user agent client or proxy MUST check + whether the address returned by a redirect server equals an address + tried earlier. + + + + + +Handley, et al. Standards Track [Page 76] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.3.1 300 Multiple Choices + + The address in the request resolved to several choices, each with its + own specific location, and the user (or user agent) can select a + preferred communication end point and redirect its request to that + location. + + The response SHOULD include an entity containing a list of resource + characteristics and location(s) from which the user or user agent can + choose the one most appropriate, if allowed by the Accept request + header. The entity format is specified by the media type given in the + Content-Type header field. The choices SHOULD also be listed as + Contact fields (Section 6.13). Unlike HTTP, the SIP response MAY + contain several Contact fields or a list of addresses in a Contact + field. User agents MAY use the Contact header field value for + automatic redirection or MAY ask the user to confirm a choice. + However, this specification does not define any standard for such + automatic selection. + + + This status response is appropriate if the callee can be + reached at several different locations and the server + cannot or prefers not to proxy the request. + +7.3.2 301 Moved Permanently + + The user can no longer be found at the address in the Request-URI and + the requesting client SHOULD retry at the new address given by the + Contact header field (Section 6.13). The caller SHOULD update any + local directories, address books and user location caches with this + new value and redirect future requests to the address(es) listed. + +7.3.3 302 Moved Temporarily + + The requesting client SHOULD retry the request at the new address(es) + given by the Contact header field (Section 6.13). The duration of + the redirection can be indicated through an Expires (Section 6.20) + header. If there is no explicit expiration time, the address is only + valid for this call and MUST NOT be cached for future calls. + +7.3.4 305 Use Proxy + + The requested resource MUST be accessed through the proxy given by + the Contact field. The Contact field gives the URI of the proxy. The + recipient is expected to repeat this single request via the proxy. + 305 responses MUST only be generated by user agent servers. + + + + + +Handley, et al. Standards Track [Page 77] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.3.5 380 Alternative Service + + The call was not successful, but alternative services are possible. + The alternative services are described in the message body of the + response. Formats for such bodies are not defined here, and may be + the subject of future standardization. + +7.4 Request Failure 4xx + + 4xx responses are definite failure responses from a particular + server. The client SHOULD NOT retry the same request without + modification (e.g., adding appropriate authorization). However, the + same request to a different server might be successful. + +7.4.1 400 Bad Request + + The request could not be understood due to malformed syntax. + +7.4.2 401 Unauthorized + + The request requires user authentication. + +7.4.3 402 Payment Required + + Reserved for future use. + +7.4.4 403 Forbidden + + The server understood the request, but is refusing to fulfill it. + Authorization will not help, and the request SHOULD NOT be repeated. + +7.4.5 404 Not Found + + The server has definitive information that the user does not exist at + the domain specified in the Request-URI. This status is also returned + if the domain in the Request-URI does not match any of the domains + handled by the recipient of the request. + +7.4.6 405 Method Not Allowed + + The method specified in the Request-Line is not allowed for the + address identified by the Request-URI. The response MUST include an + Allow header field containing a list of valid methods for the + indicated address. + + + + + + + +Handley, et al. Standards Track [Page 78] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.4.7 406 Not Acceptable + + The resource identified by the request is only capable of generating + response entities which have content characteristics not acceptable + according to the accept headers sent in the request. + +7.4.8 407 Proxy Authentication Required + + This code is similar to 401 (Unauthorized), but indicates that the + client MUST first authenticate itself with the proxy. The proxy MUST + return a Proxy-Authenticate header field (section 6.26) containing a + challenge applicable to the proxy for the requested resource. The + client MAY repeat the request with a suitable Proxy-Authorization + header field (section 6.27). SIP access authentication is explained + in section 13.2 and 14. + + This status code is used for applications where access to the + communication channel (e.g., a telephony gateway) rather than the + callee requires authentication. + +7.4.9 408 Request Timeout + + The server could not produce a response, e.g., a user location, + within the time indicated in the Expires request-header field. The + client MAY repeat the request without modifications at any later + time. + +7.4.10 409 Conflict + + The request could not be completed due to a conflict with the current + state of the resource. This response is returned if the action + parameter in a REGISTER request conflicts with existing + registrations. + +7.4.11 410 Gone + + The requested resource is no longer available at the server and no + forwarding address is known. This condition is expected to be + considered permanent. If the server does not know, or has no facility + to determine, whether or not the condition is permanent, the status + code 404 (Not Found) SHOULD be used instead. + +7.4.12 411 Length Required + + The server refuses to accept the request without a defined Content- + Length. The client MAY repeat the request if it adds a valid + Content-Length header field containing the length of the message-body + in the request message. + + + +Handley, et al. Standards Track [Page 79] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.4.13 413 Request Entity Too Large + + The server is refusing to process a request because the request + entity is larger than the server is willing or able to process. The + server MAY close the connection to prevent the client from continuing + the request. + + If the condition is temporary, the server SHOULD include a Retry- + After header field to indicate that it is temporary and after what + time the client MAY try again. + +7.4.14 414 Request-URI Too Long + + The server is refusing to service the request because the Request-URI + is longer than the server is willing to interpret. + +7.4.15 415 Unsupported Media Type + + The server is refusing to service the request because the message + body of the request is in a format not supported by the requested + resource for the requested method. The server SHOULD return a list of + acceptable formats using the Accept, Accept-Encoding and Accept- + Language header fields. + +7.4.16 420 Bad Extension + + The server did not understand the protocol extension specified in a + Require (Section 6.30) header field. + +7.4.17 480 Temporarily Unavailable + + The callee's end system was contacted successfully but the callee is + currently unavailable (e.g., not logged in or logged in in such a + manner as to preclude communication with the callee). The response + MAY indicate a better time to call in the Retry-After header. The + user could also be available elsewhere (unbeknownst to this host), + thus, this response does not terminate any searches. The reason + phrase SHOULD indicate a more precise cause as to why the callee is + unavailable. This value SHOULD be setable by the user agent. Status + 486 (Busy Here) MAY be used to more precisely indicate a particular + reason for the call failure. + + This status is also returned by a redirect server that recognizes the + user identified by the Request-URI, but does not currently have a + valid forwarding location for that user. + + + + + + +Handley, et al. Standards Track [Page 80] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.4.18 481 Call Leg/Transaction Does Not Exist + + This status is returned under two conditions: The server received a + BYE request that does not match any existing call leg or the server + received a CANCEL request that does not match any existing + transaction. (A server simply discards an ACK referring to an unknown + transaction.) + +7.4.19 482 Loop Detected + + The server received a request with a Via (Section 6.40) path + containing itself. + +7.4.20 483 Too Many Hops + + The server received a request that contains more Via entries (hops) + (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header + field. + +7.4.21 484 Address Incomplete + + The server received a request with a To (Section 6.37) address or + Request-URI that was incomplete. Additional information SHOULD be + provided. + + + This status code allows overlapped dialing. With overlapped + dialing, the client does not know the length of the dialing + string. It sends strings of increasing lengths, prompting + the user for more input, until it no longer receives a 484 + status response. + +7.4.22 485 Ambiguous + + The callee address provided in the request was ambiguous. The + response MAY contain a listing of possible unambiguous addresses in + Contact headers. + + Revealing alternatives can infringe on privacy concerns of the user + or the organization. It MUST be possible to configure a server to + respond with status 404 (Not Found) or to suppress the listing of + possible choices if the request address was ambiguous. + + Example response to a request with the URL lee@example.com : + + 485 Ambiguous SIP/2.0 + Contact: Carol Lee + + + + +Handley, et al. Standards Track [Page 81] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Contact: Ping Lee + Contact: Lee M. Foote + + + + Some email and voice mail systems provide this + functionality. A status code separate from 3xx is used + since the semantics are different: for 300, it is assumed + that the same person or service will be reached by the + choices provided. While an automated choice or sequential + search makes sense for a 3xx response, user intervention is + required for a 485 response. + +7.4.23 486 Busy Here + + The callee's end system was contacted successfully but the callee is + currently not willing or able to take additional calls. The response + MAY indicate a better time to call in the Retry-After header. The + user could also be available elsewhere, such as through a voice mail + service, thus, this response does not terminate any searches. Status + 600 (Busy Everywhere) SHOULD be used if the client knows that no + other end system will be able to accept this call. + +7.5 Server Failure 5xx + + 5xx responses are failure responses given when a server itself has + erred. They are not definitive failures, and MUST NOT terminate a + search if other possible locations remain untried. + +7.5.1 500 Server Internal Error + + The server encountered an unexpected condition that prevented it from + fulfilling the request. The client MAY display the specific error + condition, and MAY retry the request after several seconds. + +7.5.2 501 Not Implemented + + The server does not support the functionality required to fulfill the + request. This is the appropriate response when the server does not + recognize the request method and is not capable of supporting it for + any user. + +7.5.3 502 Bad Gateway + + The server, while acting as a gateway or proxy, received an invalid + response from the downstream server it accessed in attempting to + fulfill the request. + + + + +Handley, et al. Standards Track [Page 82] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.5.4 503 Service Unavailable + + The server is currently unable to handle the request due to a + temporary overloading or maintenance of the server. The implication + is that this is a temporary condition which will be alleviated after + some delay. If known, the length of the delay MAY be indicated in a + Retry-After header. If no Retry-After is given, the client MUST + handle the response as it would for a 500 response. + + Note: The existence of the 503 status code does not imply that a + server has to use it when becoming overloaded. Some servers MAY wish + to simply refuse the connection. + +7.5.5 504 Gateway Time-out + + The server, while acting as a gateway, did not receive a timely + response from the server (e.g., a location server) it accessed in + attempting to complete the request. + +7.5.6 505 Version Not Supported + + The server does not support, or refuses to support, the SIP protocol + version that was used in the request message. The server is + indicating that it is unable or unwilling to complete the request + using the same major version as the client, other than with this + error message. The response MAY contain an entity describing why that + version is not supported and what other protocols are supported by + that server. The format for such an entity is not defined here and + may be the subject of future standardization. + +7.6 Global Failures 6xx + + 6xx responses indicate that a server has definitive information about + a particular user, not just the particular instance indicated in the + Request-URI. All further searches for this user are doomed to failure + and pending searches SHOULD be terminated. + +7.6.1 600 Busy Everywhere + + The callee's end system was contacted successfully but the callee is + busy and does not wish to take the call at this time. The response + MAY indicate a better time to call in the Retry-After header. If the + callee does not wish to reveal the reason for declining the call, the + callee uses status code 603 (Decline) instead. This status response + is returned only if the client knows that no other end point (such as + a voice mail system) will answer the request. Otherwise, 486 (Busy + Here) should be returned. + + + + +Handley, et al. Standards Track [Page 83] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +7.6.2 603 Decline + + The callee's machine was successfully contacted but the user + explicitly does not wish to or cannot participate. The response MAY + indicate a better time to call in the Retry-After header. + +7.6.3 604 Does Not Exist Anywhere + + The server has authoritative information that the user indicated in + the To request field does not exist anywhere. Searching for the user + elsewhere will not yield any results. + +7.6.4 606 Not Acceptable + + The user's agent was contacted successfully but some aspects of the + session description such as the requested media, bandwidth, or + addressing style were not acceptable. + + A 606 (Not Acceptable) response means that the user wishes to + communicate, but cannot adequately support the session described. The + 606 (Not Acceptable) response MAY contain a list of reasons in a + Warning header field describing why the session described cannot be + supported. Reasons are listed in Section 6.41. It is hoped that + negotiation will not frequently be needed, and when a new user is + being invited to join an already existing conference, negotiation may + not be possible. It is up to the invitation initiator to decide + whether or not to act on a 606 (Not Acceptable) response. + +8 SIP Message Body + +8.1 Body Inclusion + + Requests MAY contain message bodies unless otherwise noted. Within + this specification, the BYE request MUST NOT contain a message body. + For ACK, INVITE and OPTIONS, the message body is always a session + description. The use of message bodies for REGISTER requests is for + further study. + + For response messages, the request method and the response status + code determine the type and interpretation of any message body. All + responses MAY include a body. Message bodies for 1xx responses + contain advisory information about the progress of the request. 2xx + responses to INVITE requests contain session descriptions. In 3xx + responses, the message body MAY contain the description of + alternative destinations or services, as described in Section 7.3. + For responses with status 400 or greater, the message body MAY + + + + + +Handley, et al. Standards Track [Page 84] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + contain additional, human-readable information about the reasons for + failure. It is RECOMMENDED that information in 1xx and 300 and + greater responses be of type text/plain or text/html + +8.2 Message Body Type + + The Internet media type of the message body MUST be given by the + Content-Type header field. If the body has undergone any encoding + (such as compression) then this MUST be indicated by the Content- + Encoding header field, otherwise Content-Encoding MUST be omitted. If + applicable, the character set of the message body is indicated as + part of the Content-Type header-field value. + +8.3 Message Body Length + + The body length in bytes SHOULD be given by the Content-Length header + field. Section 6.15 describes the behavior in detail. + + The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. + (Note: The chunked encoding modifies the body of a message in order + to transfer it as a series of chunks, each with its own size + indicator.) + +9 Compact Form + + When SIP is carried over UDP with authentication and a complex + session description, it may be possible that the size of a request or + response is larger than the MTU. To address this problem, a more + compact form of SIP is also defined by using abbreviations for the + common header fields listed below: + + + short field name long field name note + c Content-Type + e Content-Encoding + f From + i Call-ID + m Contact from "moved" + l Content-Length + s Subject + t To + v Via + + + Thus, the message in section 16.2 could also be written: + + + + + + +Handley, et al. Standards Track [Page 85] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + INVITE sip:schooler@vlsi.caltech.edu SIP/2.0 + v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16 + v:SIP/2.0/UDP 128.16.64.19 + f:sip:mjh@isi.edu + t:sip:schooler@cs.caltech.edu + i:62729-27@128.16.64.19 + c:application/sdp + CSeq: 4711 INVITE + l:187 + + v=0 + o=user1 53655765 2353687637 IN IP4 128.3.4.5 + s=Mbone Audio + i=Discussion of Mbone Engineering Issues + e=mbone@somewhere.com + c=IN IP4 224.2.0.1/127 + t=0 0 + m=audio 3456 RTP/AVP 0 + + + + Clients MAY mix short field names and long field names within the + same request. Servers MUST accept both short and long field names for + requests. Proxies MAY change header fields between their long and + short forms, but this MUST NOT be done to fields following an + Authorization header. + +10 Behavior of SIP Clients and Servers + +10.1 General Remarks + + SIP is defined so it can use either UDP (unicast or multicast) or TCP + as a transport protocol; it provides its own reliability mechanism. + +10.1.1 Requests + + Servers discard isomorphic requests, but first retransmit the + appropriate response. (SIP requests are said to be idempotent , i.e., + receiving more than one copy of a request does not change the server + state.) + + After receiving a CANCEL request from an upstream client, a stateful + proxy server MAY send a CANCEL on all branches where it has not yet + received a final response. + + When a user agent receives a request, it checks the Call-ID against + those of in-progress calls. If the Call-ID was found, it compares the + tag value of To with the user's tag and rejects the request if the + + + +Handley, et al. Standards Track [Page 86] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + two do not match. If the From header, including any tag value, + matches the value for an existing call leg, the server compares the + CSeq header field value. If less than or equal to the current + sequence number, the request is a retransmission. Otherwise, it is a + new request. If the From header does not match an existing call leg, + a new call leg is created. + + If the Call-ID was not found, a new call leg is created, with entries + for the To, From and Call-ID headers. In this case, the To header + field should not have contained a tag. The server returns a response + containing the same To value, but with a unique tag added. The tag + MAY be omitted if the request contained only one Via header field. + +10.1.2 Responses + + A server MAY issue one or more provisional responses at any time + before sending a final response. If a stateful proxy, user agent + server, redirect server or registrar cannot respond to a request with + a final response within 200 ms, it SHOULD issue a provisional (1xx) + response as soon as possible. Stateless proxies MUST NOT issue + provisional responses on their own. + + Responses are mapped to requests by the matching To, From, Call-ID, + CSeq headers and the branch parameter of the first Via header. + Responses terminate request retransmissions even if they have Via + headers that cause them to be delivered to an upstream client. + + A stateful proxy may receive a response that it does not have state + for, that is, where it has no a record of an associated request. If + the Via header field indicates that the upstream server used TCP, the + proxy actively opens a TCP connection to that address. Thus, proxies + have to be prepared to receive responses on the incoming side of + passive TCP connections, even though most responses will arrive on + the incoming side of an active connection. (An active connection is a + TCP connection initiated by the proxy, a passive connection is one + accepted by the proxy, but initiated by another entity.) + + 100 responses SHOULD NOT be forwarded, other 1xx responses MAY be + forwarded, possibly after the server eliminates responses with status + codes that had already been sent earlier. 2xx responses are forwarded + according to the Via header. Once a stateful proxy has received a 2xx + response, it MUST NOT forward non-2xx final responses. Responses + with status 300 and higher are retransmitted by each stateful proxy + until the next upstream proxy sends an ACK (see below for timing + details) or CANCEL. + + + + + + +Handley, et al. Standards Track [Page 87] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + A stateful proxy SHOULD maintain state for at least 32 seconds after + the receipt of the first definitive non-200 response, in order to + handle retransmissions of the response. + + + The 32 second window is given by the maximum retransmission + duration of 200-class responses using the default timers, + in case the ACK is lost somewhere on the way to the called + user agent or the next stateful proxy. + +10.2 Source Addresses, Destination Addresses and Connections + +10.2.1 Unicast UDP + + Responses are returned to the address listed in the Via header field + (Section 6.40), not the source address of the request. + + + Recall that responses are not generated by the next-hop + stateless server, but generated by either a proxy server or + the user agent server. Thus, the stateless proxy can only + use the Via header field to forward the response. + +10.2.2 Multicast UDP + + Requests MAY be multicast; multicast requests likely feature a host- + independent Request-URI. This request SHOULD be scoped to ensure it + is not forwarded beyond the boundaries of the administrative system. + This MAY be done with either TTL or administrative scopes[25], + depending on what is implemented in the network. + + A client receiving a multicast query does not have to check whether + the host part of the Request-URI matches its own host or domain name. + If the request was received via multicast, the response is also + returned via multicast. Responses to multicast requests are multicast + with the same TTL as the request, where the TTL is derived from the + ttl parameter in the Via header (Section 6.40). + + To avoid response implosion, servers MUST NOT answer multicast + requests with a status code other than 2xx or 6xx. The server delays + its response by a random interval uniformly distributed between zero + and one second. Servers MAY suppress responses if they hear a lower- + numbered or 6xx response from another group member prior to sending. + Servers do not respond to CANCEL requests received via multicast to + avoid request implosion. A proxy or UAC SHOULD send a CANCEL on + receiving the first 2xx or 6xx response to a multicast request. + + + + + +Handley, et al. Standards Track [Page 88] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Server response suppression is a MAY since it requires a + server to violate some basic message processing rules. Lets + say A sends a multicast request, and it is received by B,C, + and D. B sends a 200 response. The topmost Via field in the + response will contain the address of A. C will also receive + this response, and could use it to suppress its own + response. However, C would normally not examine this + response, as the topmost Via is not its own. Normally, a + response received with an incorrect topmost Via MUST be + dropped, but not in this case. To distinguish this packet + from a misrouted or multicast looped packet is fairly + complex, and for this reason the procedure is a MAY. The + CANCEL, instead, provides a simpler and more standard way + to perform response suppression. It is for this reason that + the use of CANCEL here is a SHOULD + +10.3 TCP + + A single TCP connection can serve one or more SIP transactions. A + transaction contains zero or more provisional responses followed by + one or more final responses. (Typically, transactions contain exactly + one final response, but there are exceptional circumstances, where, + for example, multiple 200 responses can be generated.) + + The client SHOULD keep the connection open at least until the first + final response arrives. If the client closes or resets the TCP + connection prior to receiving the first final response, the server + treats this action as equivalent to a CANCEL request. + + + This behavior makes it less likely that malfunctioning + clients cause a proxy server to keep connection state + indefinitely. + + The server SHOULD NOT close the TCP connection until it has sent its + final response, at which point it MAY close the TCP connection if it + wishes to. However, normally it is the client's responsibility to + close the connection. + + If the server leaves the connection open, and if the client so + desires it MAY re-use the connection for further SIP requests or for + requests from the same family of protocols (such as HTTP or stream + control commands). + + + + + + + + +Handley, et al. Standards Track [Page 89] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + If a server needs to return a response to a client and no longer has + a connection open to that client, it MAY open a connection to the + address listed in the Via header. Thus, a proxy or user agent MUST be + prepared to receive both requests and responses on a "passive" + connection. + +10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests + +10.4.1 UDP + + A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or + REGISTER request with an exponential backoff, starting at a T1 second + interval, doubling the interval for each packet, and capping off at a + T2 second interval. This means that after the first packet is sent, + the second is sent T1 seconds later, the next 2*T1 seconds after + that, the next 4*T1 seconds after that, and so on, until the interval + hits T2. Subsequent retransmissions are spaced by T2 seconds. If the + client receives a provisional response, it continues to retransmit + the request, but with an interval of T2 seconds. Retransmissions + cease when the client has sent a total of eleven packets, or receives + a definitive response. Default values for T1 and T2 are 500 ms and 4 + s, respectively. Clients MAY use larger values, but SHOULD NOT use + smaller ones. Servers retransmit the response upon receipt of a + request retransmission. After the server sends a final response, it + cannot be sure the client has received the response, and thus SHOULD + cache the results for at least 10*T2 seconds to avoid having to, for + example, contact the user or location server again upon receiving a + request retransmission. + + + Use of the exponential backoff is for congestion control + purposes. However, the back-off must cap off, since request + retransmissions are used to trigger response + retransmissions at the server. Without a cap, the loss of a + single response could significantly increase transaction + latencies. + + The value of the initial retransmission timer is smaller than that + that for TCP since it is expected that network paths suitable for + interactive communications have round-trip times smaller than 500 ms. + For congestion control purposes, the retransmission count has to be + bounded. Given that most transactions are expected to consist of one + request and a few responses, round-trip time estimation is not likely + to be very useful. If RTT estimation is desired to more quickly + discover a missing final response, each request retransmission needs + to be labeled with its own Timestamp (Section 6.36), returned in the + response. The server caches the result until it can be sure that the + client will not retransmit the same request again. + + + +Handley, et al. Standards Track [Page 90] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Each server in a proxy chain generates its own final response to a + CANCEL request. The server responds immediately upon receipt of the + CANCEL request rather than waiting until it has received final + responses from the CANCEL requests it generates. + + BYE and OPTIONS final responses are generated by redirect and user + agent servers; REGISTER final responses are generated by registrars. + Note that in contrast to the reliability mechanism described in + Section 10.5, responses to these requests are not retransmitted + periodically and not acknowledged via ACK. + +10.4.2 TCP + + Clients using TCP do not need to retransmit requests. + +10.5 Reliability for INVITE Requests + + Special considerations apply for the INVITE method. + + 1. After receiving an invitation, considerable time can elapse + before the server can determine the outcome. For example, + if the called party is "rung" or extensive searches are + performed, delays between the request and a definitive + response can reach several tens of seconds. If either + caller or callee are automated servers not directly + controlled by a human being, a call attempt could be + unbounded in time. + + 2. If a telephony user interface is modeled or if we need to + interface to the PSTN, the caller's user interface will + provide "ringback", a signal that the callee is being + alerted. (The status response 180 (Ringing) MAY be used to + initiate ringback.) Once the callee picks up, the caller + needs to know so that it can enable the voice path and stop + ringback. The callee's response to the invitation could get + lost. Unless the response is transmitted reliably, the + caller will continue to hear ringback while the callee + assumes that the call exists. + + 3. The client has to be able to terminate an on-going request, + e.g., because it is no longer willing to wait for the + connection or search to succeed. The server will have to + wait several retransmission intervals to interpret the lack + of request retransmissions as the end of a call. If the + call succeeds shortly after the caller has given up, the + callee will "pick up the phone" and not be "connected". + + + + + +Handley, et al. Standards Track [Page 91] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +10.5.1 UDP + + For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an + interval that starts at T1 seconds, and doubles after each packet + transmission. The client ceases retransmissions if it receives a + provisional or definitive response, or once it has sent a total of 7 + request packets. + + A server which transmits a provisional response should retransmit it + upon reception of a duplicate request. A server which transmits a + final response should retransmit it with an interval that starts at + T1 seconds, and doubles for each subsequent packet. Response + retransmissions cease when any one of the following occurs: + + 1. An ACK request for the same transaction is received; + + 2. a BYE request for the same call leg is received; + + 3. a CANCEL request for the same call leg is received and the + final response status was equal or greater to 300; + + 4. the response has been transmitted 7 times. + + Only the user agent client generates an ACK for 2xx final responses, + If the response contained a Contact header field, the ACK MAY be sent + to the address listed in that Contact header field. If the response + did not contain a Contact header, the client uses the same To header + field and Request-URI as for the INVITE request and sends the ACK to + the same destination as the original INVITE request. ACKs for final + responses other than 2xx are sent to the same server that the + original request was sent to, using the same Request-URI as the + original request. Note, however, that the To header field in the ACK + is copied from the response being acknowledged, not the request, and + thus MAY additionally contain the tag parameter. Also note than + unlike 2xx final responses, a proxy generates an ACK for non-2xx + final responses. + + The ACK request MUST NOT be acknowledged to prevent a response-ACK + feedback loop. Fig. 12 and 13 show the client and server state + diagram for invitations. + + + + + The mechanism in Sec. 10.4 would not work well for INVITE + because of the long delays between INVITE and a final + response. If the 200 response were to get lost, the callee + would believe the call to exist, but the voice path would + + + +Handley, et al. Standards Track [Page 92] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + +===========+ + * * + ...........>* Initial *<;;;;;;;;;; + : 7 INVITE * * ; + : sent +===========+ ; + : | ; + : | - ; + : | INVITE ; + : | ; + : v ; + : ************* ; + : T1*2^n <--* * ; + : INVITE -->* Calling *--------+ ; + : * * | ; + : ************* | ; + : : | | ; + :.............: | 1xx xxx | ; + | - ACK | ; + | | ; + v | ; + ************* | ; + * * | ; + * Ringing *<->1xx | ; + * * | ; + ************* | ; + | | ; + |<-------------+ ; + | ; + v ; + ************* ; + xxx <--* * ; + ACK -->* Completed * ; + * * ; + ************* ; + ; 32s (for proxy); + ;;;;;;;;;;;;;;;;;; + + event (xxx=status) + message + + + Figure 12: State transition diagram of client for INVITE method + + + + + + + +Handley, et al. Standards Track [Page 93] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + 7 pkts sent +===============+ ++-------------->* * +| * Initial *<............... +|;;;;;;;;;;;;;;>* * : +|; +===============+ : +|; CANCEL ! : +|; 200 ! INVITE : +|; ! 1xx : +|; ! : +|; v : +|; ***************** BYE : +|; INVITE -->* * 200 : +|; 1xx <--* Call proceed. *..............>: +|; * * : +|;;;;;;;;;;;;;;;***************** : +|; ! ! : +|: ! ! : +|; failure ! ! picks up : +|; >= 300 ! ! 200 : +|; +-------+ +-------+ : +|; v v : +|; *********** *********** : +|;INVITE<* ** *>INVITE : +|;status>* failure *>status<-* success *: + ! ! BYE : + +---------+---------+ 200 : + event ! ACK : +message sent v : + ***************** : + V---* * : + ACK * Confirmed * : + |-->* * : + ***************** . + :......................>: + + + Figure 13: State transition diagram of server for INVITE method + +Handley, et al. Standards Track [Page 94] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + be dead since the caller does not know that the callee has + picked up. Thus, the INVITE retransmission interval would + have to be on the order of a second or two to limit the + duration of this state confusion. Retransmitting the + response with an exponential back-off helps ensure that the + response is received, without placing an undue burden on + the network. + +10.5.2 TCP + + A user agent using TCP MUST NOT retransmit requests, but uses the + same algorithm as for UDP (Section 10.5.1) to retransmit responses + until it receives an ACK. + + + It is necessary to retransmit 2xx responses as their + reliability is assured end-to-end only. If the chain of + proxies has a UDP link in the middle, it could lose the + response, with no possibility of recovery. For simplicity, + we also retransmit non-2xx responses, although that is not + strictly necessary. + +10.6 Reliability for ACK Requests + + The ACK request does not generate responses. It is only generated + when a response to an INVITE request arrives (see Section 10.5). This + behavior is independent of the transport protocol. Note that the ACK + request MAY take a different path than the original INVITE request, + and MAY even cause a new TCP connection to be opened in order to send + it. + +10.7 ICMP Handling + + Handling of ICMP messages in the case of UDP messages is + straightforward. For requests, a host, network, port, or protocol + unreachable error SHOULD be treated as if a 400-class response was + received. For responses, these errors SHOULD cause the server to + cease retransmitting the response. + + Source quench ICMP messages SHOULD be ignored. TTL exceeded errors + SHOULD be ignored. Parameter problem errors SHOULD be treated as if a + 400-class response was received. + +11 Behavior of SIP User Agents + + This section describes the rules for user agent client and servers + for generating and processing requests and responses. + + + + +Handley, et al. Standards Track [Page 95] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +11.1 Caller Issues Initial INVITE Request + + When a user agent client desires to initiate a call, it formulates an + INVITE request. The To field in the request contains the address of + the callee. The Request-URI contains the same address. The From field + contains the address of the caller. If the From address can appear + in requests generated by other user agent clients for the same call, + the caller MUST insert the tag parameter in the From field. A UAC MAY + optionally add a Contact header containing an address where it would + like to be contacted for transactions from the callee back to the + caller. + +11.2 Callee Issues Response + + When the initial INVITE request is received at the callee, the callee + can accept, redirect, or reject the call. In all of these cases, it + formulates a response. The response MUST copy the To, From, Call-ID, + CSeq and Via fields from the request. Additionally, the responding + UAS MUST add the tag parameter to the To field in the response if the + request contained more than one Via header field. Since a request + from a UAC may fork and arrive at multiple hosts, the tag parameter + serves to distinguish, at the UAC, multiple responses from different + UAS's. The UAS MAY add a Contact header field in the response. It + contains an address where the callee would like to be contacted for + subsequent transactions, including the ACK for the current INVITE. + The UAS stores the values of the To and From field, including any + tags. These become the local and remote addresses of the call leg, + respectively. + +11.3 Caller Receives Response to Initial Request + + Multiple responses may arrive at the UAC for a single INVITE request, + due to a forking proxy. Each response is distinguished by the "tag" + parameter in the To header field, and each represents a distinct call + leg. The caller MAY choose to acknowledge or terminate the call with + each responding UAS. To acknowledge, it sends an ACK request, and to + terminate it sends a BYE request. The To header field in the ACK or + BYE MUST be the same as the To field in the 200 response, including + any tag. The From header field MUST be the same as the From header + field in the 200 (OK) response, including any tag. The Request-URI of + the ACK or BYE request MAY be set to whatever address was found in + the Contact header field in the 200 (OK) response, if present. + Alternately, a UAC may copy the address from the To header field into + the Request-URI. The UAC also notes the value of the To and From + header fields in each response. For each call leg, the To header + field becomes the remote address, and the From header field becomes + the local address. + + + + +Handley, et al. Standards Track [Page 96] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +11.4 Caller or Callee Generate Subsequent Requests + + Once the call has been established, either the caller or callee MAY + generate INVITE or BYE requests to change or terminate the call. + Regardless of whether the caller or callee is generating the new + request, the header fields in the request are set as follows. For the + desired call leg, the To header field is set to the remote address, + and the From header field is set to the local address (both including + any tags). The Contact header field MAY be different than the Contact + header field sent in a previous response or request. The Request-URI + MAY be set to the value of the Contact header field received in a + previous request or response from the remote party, or to the value + of the remote address. + +11.5 Receiving Subsequent Requests + + When a request is received subsequently, the following checks are + made: + + 1. If the Call-ID is new, the request is for a new call, + regardless of the values of the To and From header fields. + + 2. If the Call-ID exists, the request is for an existing call. + If the To, From, Call-ID, and CSeq values exactly match + (including tags) those of any requests received previously, + the request is a retransmission. + + 3. If there was no match to the previous step, the To and From + fields are compared against existing call leg local and + remote addresses. If there is a match, and the CSeq in the + request is higher than the last CSeq received on that leg, + the request is a new transaction for an existing call leg. + +12 Behavior of SIP Proxy and Redirect Servers + + This section describes behavior of SIP redirect and proxy servers in + detail. Proxy servers can "fork" connections, i.e., a single incoming + request spawns several outgoing (client) requests. + +12.1 Redirect Server + + A redirect server does not issue any SIP requests of its own. After + receiving a request other than CANCEL, the server gathers the list of + alternative locations and returns a final response of class 3xx or it + refuses the request. For well-formed CANCEL requests, it SHOULD + return a 2xx response. This response ends the SIP transaction. The + + + + + +Handley, et al. Standards Track [Page 97] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + redirect server maintains transaction state for the whole SIP + transaction. It is up to the client to detect forwarding loops + between redirect servers. + +12.2 User Agent Server + + User agent servers behave similarly to redirect servers, except that + they also accept requests and can return a response of class 2xx. + +12.3 Proxy Server + + This section outlines processing rules for proxy servers. A proxy + server can either be stateful or stateless. When stateful, a proxy + remembers the incoming request which generated outgoing requests, and + the outgoing requests. A stateless proxy forgets all information once + an outgoing request is generated. A forking proxy SHOULD be stateful. + Proxies that accept TCP connections MUST be stateful. + + + Otherwise, if the proxy were to lose a request, the TCP + client would never retransmit it. + + A stateful proxy SHOULD NOT become stateless until after it sends a + definitive response upstream, and at least 32 seconds after it + received a definitive response. + + A stateful proxy acts as a virtual UAS/UAC. It implements the server + state machine when receiving requests, and the client state machine + for generating outgoing requests, with the exception of receiving a + 2xx response to an INVITE. Instead of generating an ACK, the 2xx + response is always forwarded upstream towards the caller. + Furthermore, ACK's for 200 responses to INVITE's are always proxied + downstream towards the UAS, as they would be for a stateless proxy. + + A stateless proxy does not act as a virtual UAS/UAC (as this would + require state). Rather, a stateless proxy forwards every request it + receives downstream, and every response it receives upstream. + +12.3.1 Proxying Requests + + To prevent loops, a server MUST check if its own address is already + contained in the Via header field of the incoming request. + + The To, From, Call-ID, and Contact tags are copied exactly from the + original request. The proxy SHOULD change the Request-URI to indicate + the server where it intends to send the request. + + + + + +Handley, et al. Standards Track [Page 98] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + A proxy server always inserts a Via header field containing its own + address into those requests that are caused by an incoming request. + Each proxy MUST insert a "branch" parameter (Section 6.40). + +12.3.2 Proxying Responses + + A proxy only processes a response if the topmost Via field matches + one of its addresses. A response with a non-matching top Via field + MUST be dropped. + +12.3.3 Stateless Proxy: Proxying Responses + + A stateless proxy removes its own Via field, and checks the address + in the next Via field. In the case of UDP, the response is sent to + the address listed in the "maddr" tag if present, otherwise to the + "received" tag if present, and finally to the address in the "sent- + by" field. A proxy MUST remain stateful when handling requests + received via TCP. + + A stateless proxy MUST NOT generate its own provisional responses. + +12.3.4 Stateful Proxy: Receiving Requests + + When a stateful proxy receives a request, it checks the To, From + (including tags), Call-ID and CSeq against existing request records. + If the tuple exists, the request is a retransmission. The provisional + or final response sent previously is retransmitted, as per the server + state machine. If the tuple does not exist, the request corresponds + to a new transaction, and the request should be proxied. + + A stateful proxy server MAY generate its own provisional (1xx) + responses. + +12.3.5 Stateful Proxy: Receiving ACKs + + When an ACK request is received, it is either processed locally or + proxied. To make this determination, the To, From, CSeq and Call-ID + fields are compared against those in previous requests. If there is + no match, the ACK request is proxied as if it were an INVITE request. + If there is a match, and if the server had ever sent a 200 response + upstream, the ACK is proxied. If the server had never sent any + responses upstream, the ACK is also proxied. If the server had sent a + 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is + processed locally if the tag in the To field of the ACK matches the + tag sent by the proxy in the response. + + + + + + +Handley, et al. Standards Track [Page 99] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +12.3.6 Stateful Proxy: Receiving Responses + + When a proxy server receives a response that has passed the Via + checks, the proxy server checks the To (without the tag), From + (including the tag), Call-ID and CSeq against values seen in previous + requests. If there is no match, the response is forwarded upstream to + the address listed in the Via field. If there is a match, the + "branch" tag in the Via field is examined. If it matches a known + branch identifier, the response is for the given branch, and + processed by the virtual client for the given branch. Otherwise, the + response is dropped. + + A stateful proxy should obey the rules in Section 12.4 to determine + if the response should be proxied upstream. If it is to be proxied, + the same rules for stateless proxies above are followed, with the + following addition for TCP. If a request was received via TCP + (indicated by the protocol in the top Via header), the proxy checks + to see if it has a connection currently open to that address. If so, + the response is sent on that connection. Otherwise, a new TCP + connection is opened to the address and port in the Via field, and + the response is sent there. Note that this implies that a UAC or + proxy MUST be prepared to receive responses on the incoming side of a + TCP connection. Definitive non 200-class responses MUST be + retransmitted by the proxy, even over a TCP connection. + +12.3.7 Stateless, Non-Forking Proxy + + Proxies in this category issue at most a single unicast request for + each incoming SIP request, that is, they do not "fork" requests. + However, servers MAY choose to always operate in a mode that allows + issuing of several requests, as described in Section 12.4. + + The server can forward the request and any responses. It does not + have to maintain any state for the SIP transaction. Reliability is + assured by the next redirect or stateful proxy server in the server + chain. + + A proxy server SHOULD cache the result of any address translations + and the response to speed forwarding of retransmissions. After the + cache entry has been expired, the server cannot tell whether an + incoming request is actually a retransmission of an older request. + The server will treat it as a new request and commence another + search. + +12.4 Forking Proxy + + The server MUST respond to the request immediately with a 100 + (Trying) response. + + + +Handley, et al. Standards Track [Page 100] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Successful responses to an INVITE request MAY contain a Contact + header field so that the following ACK or BYE bypasses the proxy + search mechanism. If the proxy requires future requests to be routed + through it, it adds a Record-Route header to the request (Section + 6.29). + + The following C-code describes the behavior of a proxy server issuing + several requests in response to an incoming INVITE request. The + function request(r, a, b) sends a SIP request of type r to address a, + with branch id b. await_response() waits until a response is received + and returns the response. close(a) closes the TCP connection to + client with address a. response(r) sends a response to the client. + ismulticast() returns 1 if the location is a multicast address and + zero otherwise. The variable timeleft indicates the amount of time + left until the maximum response time has expired. The variable + recurse indicates whether the server will recursively try addresses + returned through a 3xx response. A server MAY decide to recursively + try only certain addresses, e.g., those which are within the same + domain as the proxy server. Thus, an initial multicast request can + trigger additional unicast requests. + + + /* request type */ + typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method; + + process_request(Method R, int N, address_t address[]) + { + struct { + int branch; /* branch id */ + int done; /* has responded */ + } outgoing[]; + int done[]; /* address has responded */ + char *location[]; /* list of locations */ + int heard = 0; /* number of sites heard from */ + int class; /* class of status code */ + int timeleft = 120; /* sample timeout value */ + int loc = 0; /* number of locations */ + struct { /* response */ + int status; /* response: CANCEL=-1 */ + int locations; /* number of redirect locations */ + char *location[]; /* redirect locations */ + address_t a; /* address of respondent */ + int branch; /* branch identifier */ + } r, best; /* response, best response */ + int i; + + best.status = 1000; + for (i = 0; i < N; i++) { + + + +Handley, et al. Standards Track [Page 101] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + request(R, address[i], i); + outgoing[i].done = 0; + outgoing[i].branch = i; + } + + while (timeleft > 0 && heard < N) { + r = await_response(); + class = r.status / 100; + + /* If final response, mark branch as done. */ + if (class >= 2) { + heard++; + for (i = 0; i < N; i++) { + if (r.branch == outgoing[i].branch) { + outgoing[i].done = 1; + break; + } + } + } + /* CANCEL: respond, fork and wait for responses */ + else if (class < 0) { + best.status = 200; + response(best); + for (i = 0; i < N; i++) { + if (!outgoing[i].done) + request(CANCEL, address[i], outgoing[i].branch); + } + best.status = -1; + } + + /* Send an ACK */ + + if (class != 2) { + if (R == INVITE) request(ACK, r.a, r.branch); + } + + + if (class == 2) { + if (r.status < best.status) best = r; + break; + } + else if (class == 3) { + /* A server MAY optionally recurse. The server MUST check + * whether it has tried this location before and whether + * the location is part of the Via path of the incoming + * request. This check is omitted here for brevity. + * Multicast locations MUST NOT be returned to the client if + * the server is not recursing. + + + +Handley, et al. Standards Track [Page 102] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + */ + if (recurse) { + multicast = 0; + N += r.locations; + for (i = 0; i < r.locations; i++) { + request(R, r.location[i]); + } + } else if (!ismulticast(r.location)) { + best = r; + } + } + else if (class == 4) { + if (best.status >= 400) best = r; + } + else if (class == 5) { + if (best.status >= 500) best = r; + } + else if (class == 6) { + best = r; + break; + } + } + + /* We haven't heard anything useful from anybody. */ + if (best.status == 1000) { + best.status = 404; + } + if (best.status/100 != 3) loc = 0; + response(best); + } + + + Responses are processed as follows. The process completes (and state + can be freed) when all requests have been answered by final status + responses (for unicast) or 60 seconds have elapsed (for multicast). A + proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to + the client after 60 seconds or more. + + 1xx: The proxy MAY forward the response upstream towards the client. + + 2xx: The proxy MUST forward the response upstream towards the client, + without sending an ACK downstream. After receiving a 2xx, the + server MAY terminate all other pending requests by sending a + CANCEL request and closing the TCP connection, if applicable. + (Terminating pending requests is advisable as searches consume + resources. Also, INVITE requests could "ring" on a number of + workstations if the callee is currently logged in more than + once.) + + + +Handley, et al. Standards Track [Page 103] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact + addresses. Otherwise, the lowest-numbered response is returned + if there were no 2xx responses. + + Location lists are not merged as that would prevent + forwarding of authenticated responses. Also, responses can + have message bodies, so that merging is not feasible. + + 4xx, 5xx: The proxy MUST send an ACK and remember the response if it + has a lower status code than any previous 4xx and 5xx responses. + On completion, the lowest-numbered response is returned if there + were no 2xx or 3xx responses. + + 6xx: The proxy MUST forward the response to the client and send an + ACK. Other pending requests MAY be terminated with CANCEL as + described for 2xx responses. + + A proxy server forwards any response for Call-IDs for which it does + not have a pending transaction according to the response's Via + header. User agent servers respond to BYE requests for unknown call + legs with status code 481 (Transaction Does Not Exist); they drop ACK + requests with unknown call legs silently. + + Special considerations apply for choosing forwarding destinations for + ACK and BYE requests. In most cases, these requests will bypass + proxies and reach the desired party directly, keeping proxies from + having to make forwarding decisions. + + A proxy MAY maintain call state for a period of its choosing. If a + proxy still has list of destinations that it forwarded the last + INVITE to, it SHOULD direct ACK requests only to those downstream + servers. + +13 Security Considerations + +13.1 Confidentiality and Privacy: Encryption + +13.1.1 End-to-End Encryption + + SIP requests and responses can contain sensitive information about + the communication patterns and communication content of individuals. + The SIP message body MAY also contain encryption keys for the session + itself. SIP supports three complementary forms of encryption to + protect privacy: + + o End-to-end encryption of the SIP message body and certain + sensitive header fields; + + + + +Handley, et al. Standards Track [Page 104] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + o hop-by-hop encryption to prevent eavesdropping that tracks + who is calling whom; + + o hop-by-hop encryption of Via fields to hide the route a + request has taken. + + Not all of the SIP request or response can be encrypted end-to-end + because header fields such as To and Via need to be visible to + proxies so that the SIP request can be routed correctly. Hop-by-hop + encryption encrypts the entire SIP request or response on the wire so + that packet sniffers or other eavesdroppers cannot see who is calling + whom. Hop-by-hop encryption can also encrypt requests and responses + that have been end-to-end encrypted. Note that proxies can still see + who is calling whom, and this information is also deducible by + performing a network traffic analysis, so this provides a very + limited but still worthwhile degree of protection. + + SIP Via fields are used to route a response back along the path taken + by the request and to prevent infinite request loops. However, the + information given by them can also provide useful information to an + attacker. Section 6.22 describes how a sender can request that Via + fields be encrypted by cooperating proxies without compromising the + purpose of the Via field. + + End-to-end encryption relies on keys shared by the two user agents + involved in the request. Typically, the message is sent encrypted + with the public key of the recipient, so that only that recipient can + read the message. All implementations SHOULD support PGP-based + encryption [33] and MAY implement other schemes. + + A SIP request (or response) is end-to-end encrypted by splitting the + message to be sent into a part to be encrypted and a short header + that will remain in the clear. Some parts of the SIP message, namely + the request line, the response line and certain header fields marked + with "n" in the "enc." column in Table 4 and 5 need to be read and + returned by proxies and thus MUST NOT be encrypted end-to-end. + Possibly sensitive information that needs to be made available as + plaintext include destination address (To) and the forwarding path + (Via) of the call. The Authorization header field MUST remain in the + clear if it contains a digital signature as the signature is + generated after encryption, but MAY be encrypted if it contains + "basic" or "digest" authentication. The From header field SHOULD + normally remain in the clear, but MAY be encrypted if required, in + which case some proxies MAY return a 401 (Unauthorized) status if + they require a From field. + + + + + + +Handley, et al. Standards Track [Page 105] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Other header fields MAY be encrypted or MAY travel in the clear as + desired by the sender. The Subject, Allow and Content-Type header + fields will typically be encrypted. The Accept, Accept-Language, + Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header + fields will remain in the clear. + + All fields that will remain in the clear MUST precede those that will + be encrypted. The message is encrypted starting with the first + character of the first header field that will be encrypted and + continuing through to the end of the message body. If no header + fields are to be encrypted, encrypting starts with the second CRLF + pair after the last header field, as shown below. Carriage return and + line feed characters have been made visible as "$", and the encrypted + part of the message is outlined. + + + INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ + Via: SIP/2.0/UDP 169.130.12.5$ + To: T. A. Watson $ + From: A. Bell $ + Encryption: PGP version=5.0$ + Content-Length: 224$ + Call-ID: 187602141351@worcester.bell-telephone.com$ + CSeq: 488$ + $ + ******************************************************* + * Subject: Mr. Watson, come here.$ * + * Content-Type: application/sdp$ * + * $ * + * v=0$ * + * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * + * c=IN IP4 135.180.144.94$ * + * m=audio 3456 RTP/AVP 0 3 4 5$ * + ******************************************************* + + + + An Encryption header field MUST be added to indicate the encryption + mechanism used. A Content-Length field is added that indicates the + length of the encrypted body. The encrypted body is preceded by a + blank line as a normal SIP message body would be. + + Upon receipt by the called user agent possessing the correct + decryption key, the message body as indicated by the Content-Length + field is decrypted, and the now-decrypted body is appended to the + clear-text header fields. There is no need for an additional + Content-Length header field within the encrypted body because the + length of the actual message body is unambiguous after decryption. + + + +Handley, et al. Standards Track [Page 106] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Had no SIP header fields required encryption, the message would have + been as below. Note that the encrypted body MUST then include a blank + line (start with CRLF) to disambiguate between any possible SIP + header fields that might have been present and the SIP message body. + + + INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ + Via: SIP/2.0/UDP 169.130.12.5$ + To: T. A. Watson $ + From: A. Bell $ + Encryption: PGP version=5.0$ + Content-Type: application/sdp$ + Content-Length: 107$ + $ + ************************************************* + * $ * + * v=0$ * + * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * + * c=IN IP4 135.180.144.94$ * + * m=audio 3456 RTP/AVP 0 3 4 5$ * + ************************************************* + + + +13.1.2 Privacy of SIP Responses + + SIP requests can be sent securely using end-to-end encryption and + authentication to a called user agent that sends an insecure + response. This is allowed by the SIP security model, but is not a + good idea. However, unless the correct behavior is explicit, it + would not always be possible for the called user agent to infer what + a reasonable behavior was. Thus when end-to-end encryption is used by + the request originator, the encryption key to be used for the + response SHOULD be specified in the request. If this were not done, + it might be possible for the called user agent to incorrectly infer + an appropriate key to use in the response. Thus, to prevent key- + guessing becoming an acceptable strategy, we specify that a called + user agent receiving a request that does not specify a key to be used + for the response SHOULD send that response unencrypted. + + Any SIP header fields that were encrypted in a request SHOULD also be + encrypted in an encrypted response. Contact response fields MAY be + encrypted if the information they contain is sensitive, or MAY be + left in the clear to permit proxies more scope for localized + searches. + + + + + + +Handley, et al. Standards Track [Page 107] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +13.1.3 Encryption by Proxies + + Normally, proxies are not allowed to alter end-to-end header fields + and message bodies. Proxies MAY, however, encrypt an unsigned request + or response with the key of the call recipient. + + + Proxies need to encrypt a SIP request if the end system + cannot perform encryption or to enforce organizational + security policies. + +13.1.4 Hop-by-Hop Encryption + + SIP requests and responses MAY also be protected by security + mechanisms at the transport or network layer. No particular mechanism + is defined or recommended here. Two possibilities are IPSEC [34] or + TLS [35]. The use of a particular mechanism will generally need to be + specified out of band, through manual configuration, for example. + +13.1.5 Via field encryption + + When Via header fields are to be hidden, a proxy that receives a + request containing an appropriate "Hide: hop" header field (as + specified in section 6.22) SHOULD encrypt the header field. As only + the proxy that encrypts the field will decrypt it, the algorithm + chosen is entirely up to the proxy implementor. Two methods satisfy + these requirements: + + o The server keeps a cache of Via header fields and the + associated To header field, and replaces the Via header field + with an index into the cache. On the reverse path, take the + Via header field from the cache rather than the message. + + This is insufficient to prevent message looping, and so an + additional ID MUST be added so that the proxy can detect loops. + This SHOULD NOT normally be the address of the proxy as the goal + is to hide the route, so instead a sufficiently large random + number SHOULD be used by the proxy and maintained in the cache. + + It is possible for replies to get directed to the wrong + originator if the cache entry gets reused, so great care needs + to be taken to ensure this does not happen. + + o The server MAY use a secret key to encrypt the Via field, a + timestamp and an appropriate checksum in any such message with + the same secret key. The checksum is needed to detect whether + successful decoding has occurred, and the timestamp is + + + + +Handley, et al. Standards Track [Page 108] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + required to prevent possible replay attacks and to ensure that + no two requests from the same previous hop have the same + encrypted Via field. This is the preferred solution. + +13.2 Message Integrity and Access Control: Authentication + + Protective measures need to be taken to prevent an active attacker + from modifying and replaying SIP requests and responses. The same + cryptographic measures that are used to ensure the authenticity of + the SIP message also serve to authenticate the originator of the + message. However, the "basic" and "digest" authentication mechanism + offer authentication only, without message integrity. + + Transport-layer or network-layer authentication MAY be used for hop- + by-hop authentication. SIP also extends the HTTP WWW-Authenticate + (Section 6.42) and Authorization (Section 6.11) header field and + their Proxy counterparts to include cryptographically strong + signatures. SIP also supports the HTTP "basic" and "digest" schemes + (see Section 14) and other HTTP authentication schemes to be defined + that offer a rudimentary mechanism of ascertaining the identity of + the caller. + + + Since SIP requests are often sent to parties with which no + prior communication relationship has existed, we do not + specify authentication based on shared secrets. + + SIP requests MAY be authenticated using the Authorization header + field to include a digital signature of certain header fields, the + request method and version number and the payload, none of which are + modified between client and called user agent. The Authorization + header field is used in requests to authenticate the request + originator end-to-end to proxies and the called user agent, and in + responses to authenticate the called user agent or proxies returning + their own failure codes. If required, hop-by-hop authentication can + be provided, for example, by the IPSEC Authentication Header. + + SIP does not dictate which digital signature scheme is used for + authentication, but does define how to provide authentication using + PGP in Section 15. As indicated above, SIP implementations MAY also + use "basic" and "digest" authentication and other authentication + mechanisms defined for HTTP. Note that "basic" authentication has + severe security limitations. The following does not apply to these + schemes. + + To cryptographically sign a SIP request, the order of the SIP header + fields is important. When an Authorization header field is present, + it indicates that all header fields following the Authorization + + + +Handley, et al. Standards Track [Page 109] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + header field have been included in the signature. Therefore, hop- + by-hop header fields which MUST or SHOULD be modified by proxies MUST + precede the Authorization header field as they will generally be + modified or added-to by proxy servers. Hop-by-hop header fields + which MAY be modified by a proxy MAY appear before or after the + Authorization header. When they appear before, they MAY be modified + by a proxy. When they appear after, they MUST NOT be modified by a + proxy. To sign a request, a client constructs a message from the + request method (in upper case) followed, without LWS, by the SIP + version number, followed, again without LWS, by the request headers + to be signed and the message body. The message thus constructed is + then signed. + + For example, if the SIP request is to be: + + INVITE sip:watson@boston.bell-telephone.com SIP/2.0 + Via: SIP/2.0/UDP 169.130.12.5 + Authorization: PGP version=5.0, signature=... + From: A. Bell + To: T. A. Watson + Call-ID: 187602141351@worcester.bell-telephone.com + Subject: Mr. Watson, come here. + Content-Type: application/sdp + Content-Length: ... + + v=0 + o=bell 53655765 2353687637 IN IP4 128.3.4.5 + c=IN IP4 135.180.144.94 + m=audio 3456 RTP/AVP 0 3 4 5 + + + + Then the data block that is signed is: + + INVITESIP/2.0From: A. Bell + To: T. A. Watson + Call-ID: 187602141351@worcester.bell-telephone.com + Subject: Mr. Watson, come here. + Content-Type: application/sdp + Content-Length: ... + + v=0 + o=bell 53655765 2353687637 IN IP4 128.3.4.5 + c=IN IP4 135.180.144.94 + m=audio 3456 RTP/AVP 0 3 4 5 + + + + + + +Handley, et al. Standards Track [Page 110] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Clients wishing to authenticate requests MUST construct the portion + of the message below the Authorization header using a canonical form. + This allows a proxy to parse the message, take it apart, and + reconstruct it, without causing an authentication failure due to + extra white space, for example. Canonical form consists of the + following rules: + + o No short form header fields + + o Header field names are capitalized as shown in this document + + o No white space between the header name and the colon + + o A single space after the colon + + o Line termination with a CRLF + + o No line folding + + o No comma separated lists of header values; each must appear + as a separate header + + o Only a single SP between tokens, between tokens and quoted + strings, and between quoted strings; no SP after last token or + quoted string + + o No LWS between tokens and separators, except as described + above for after the colon in header fields + + Note that if a message is encrypted and authenticated using a digital + signature, when the message is generated encryption is performed + before the digital signature is generated. On receipt, the digital + signature is checked before decryption. + + A client MAY require that a server sign its response by including a + Require: org.ietf.sip.signed-response request header field. The + client indicates the desired authentication method via the WWW- + Authenticate header. + + The correct behavior in handling unauthenticated responses to a + request that requires authenticated responses is described in section + 13.2.1. + + + + + + + + + +Handley, et al. Standards Track [Page 111] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +13.2.1 Trusting responses + + There is the possibility that an eavesdropper listens to requests and + then injects unauthenticated responses that terminate, redirect or + otherwise interfere with a call. (Even encrypted requests contain + enough information to fake a response.) + + Clients need to be particularly careful with 3xx redirection + responses. Thus a client receiving, for example, a 301 (Moved + Permanently) which was not authenticated when the public key of the + called user agent is known to the client, and authentication was + requested in the request SHOULD be treated as suspicious. The correct + behavior in such a case would be for the called-user to form a dated + response containing the Contact field to be used, to sign it, and + give this signed stub response to the proxy that will provide the + redirection. Thus the response can be authenticated correctly. A + client SHOULD NOT automatically redirect such a request to the new + location without alerting the user to the authentication failure + before doing so. + + Another problem might be responses such as 6xx failure responses + which would simply terminate a search, or "4xx" and "5xx" response + failures. + + If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as + valid, as they will not terminate a search. However, fake 6xx + responses from a rogue proxy terminate a search incorrectly. 6xx + responses SHOULD be authenticated if requested by the client, and + failure to do so SHOULD cause such a client to ignore the 6xx + response and continue a search. + + With UDP, the same problem with 6xx responses exists, but also an + active eavesdropper can generate 4xx and 5xx responses that might + cause a proxy or client to believe a failure occurred when in fact it + did not. Typically 4xx and 5xx responses will not be signed by the + called user agent, and so there is no simple way to detect these + rogue responses. This problem is best prevented by using hop-by-hop + encryption of the SIP request, which removes any additional problems + that UDP might have over TCP. + + These attacks are prevented by having the client require response + authentication and dropping unauthenticated responses. A server user + agent that cannot perform response authentication responds using the + normal Require response of 420 (Bad Extension). + + + + + + + +Handley, et al. Standards Track [Page 112] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +13.3 Callee Privacy + + User location and SIP-initiated calls can violate a callee's privacy. + An implementation SHOULD be able to restrict, on a per-user basis, + what kind of location and availability information is given out to + certain classes of callers. + +13.4 Known Security Problems + + With either TCP or UDP, a denial of service attack exists by a rogue + proxy sending 6xx responses. Although a client SHOULD choose to + ignore such responses if it requested authentication, a proxy cannot + do so. It is obliged to forward the 6xx response back to the client. + The client can then ignore the response, but if it repeats the + request it will probably reach the same rogue proxy again, and the + process will repeat. + +14 SIP Authentication using HTTP Basic and Digest Schemes + + SIP implementations MAY use HTTP's basic and digest authentication + mechanisms to provide a rudimentary form of security. This section + overviews usage of these mechanisms in SIP. The basic operation is + almost completely identical to that for HTTP [36]. This section + outlines this operation, pointing to [36] for details, and noting the + differences when used in SIP. + +14.1 Framework + + The framework for SIP authentication parallels that for HTTP [36]. In + particular, the BNF for auth-scheme, auth-param, challenge, realm, + realm-value, and credentials is identical. The 401 response is used + by user agent servers in SIP to challenge the authorization of a user + agent client. Additionally, registrars and redirect servers MAY make + use of 401 responses for authorization, but proxies MUST NOT, and + instead MAY use the 407 response. The requirements for inclusion of + the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and + Authorization in the various messages is identical to [36]. + + Since SIP does not have the concept of a canonical root URL, the + notion of protections spaces are interpreted differently for SIP. The + realm is a protection domain for all SIP URIs with the same value for + the userinfo, host and port part of the SIP Request-URI. For example: + + + INVITE sip:alice.wonderland@example.com SIP/2.0 + WWW-Authenticate: Basic realm="business" + + + + + +Handley, et al. Standards Track [Page 113] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + and + + + INVITE sip:aw@example.com SIP/2.0 + WWW-Authenticate: Basic realm="business" + + + + define different protection realms according to this rule. + + When a UAC resubmits a request with its credentials after receiving a + 401 or 407 response, it MUST increment the CSeq header field as it + would normally do when sending an updated request. + +14.2 Basic Authentication + + The rules for basic authentication follow those defined in [36], but + with the words "origin server" replaced with "user agent server, + redirect server , or registrar". + + Since SIP URIs are not hierarchical, the paragraph in [36] that + states that "all paths at or deeper than the depth of the last + symbolic element in the path field of the Request-URI also are within + the protection space specified by the Basic realm value of the + current challenge" does not apply for SIP. SIP clients MAY + preemptively send the corresponding Authorization header with + requests for SIP URIs within the same protection realm (as defined + above) without receipt of another challenge from the server. + +14.3 Digest Authentication + + The rules for digest authentication follow those defined in [36], + with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following + differences: + + 1. The URI included in the challenge has the following BNF: + + + URI = SIP-URL + + + 2. The BNF for digest-uri-value is: + + + digest-uri-value = Request-URI ; a defined in Section + 4.3 + + + + + +Handley, et al. Standards Track [Page 114] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + 3. The example procedure for choosing a nonce based on Etag + does not work for SIP. + + 4. The Authentication-Info and Proxy-Authentication-Info + fields are not used in SIP. + + 5. The text in [36] regarding cache operation does not apply + to SIP. + + 6. [36] requires that a server check that the URI in the + request line, and the URI included in the Authorization + header, point to the same resource. In a SIP context, these + two URI's may actually refer to different users, due to + forwarding at some proxy. Therefore, in SIP, a server MAY + check that the request-uri in the Authorization header + corresponds to a user that the server is willing to accept + forwarded or direct calls for. + +14.4 Proxy-Authentication + + The use of the Proxy-Authentication and Proxy-Authorization parallel + that as described in [36], with one difference. Proxies MUST NOT add + the Proxy-Authorization header. 407 responses MUST be forwarded + upstream towards the client following the procedures for any other + response. It is the client's responsibility to add the Proxy- + Authorization header containing credentials for the proxy which has + asked for authentication. + + + If a proxy were to resubmit a request with a Proxy- + Authorization header field, it would need to increment the + CSeq in the new request. However, this would mean that the + UAC which submitted the original request would discard a + response from the UAS, as the CSeq value would be + different. + + See sections 6.26 and 6.27 for additional information on usage of + these fields as they apply to SIP. + +15 SIP Security Using PGP + +15.1 PGP Authentication Scheme + + The "pgp" authentication scheme is based on the model that the client + authenticates itself with a request signed with the client's private + key. The server can then ascertain the origin of the request if it + has access to the public key, preferably signed by a trusted third + party. + + + +Handley, et al. Standards Track [Page 115] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +15.1.1 The WWW-Authenticate Response Header + + + + WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge + pgp-challenge = * (";" pgp-params ) + pgp-params = realm | pgp-version | pgp-algorithm | nonce + realm = "realm" "=" realm-value + realm-value = quoted-string + pgp-version = "version" "=" + <"> digit *( "." digit ) *letter <"> + pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token ) + nonce = "nonce" "=" nonce-value + nonce-value = quoted-string + + + + The meanings of the values of the parameters used above are as + follows: + + realm: A string to be displayed to users so they know which identity + to use. This string SHOULD contain at least the name of the host + performing the authentication and MAY additionally indicate the + collection of users who might have access. An example might be " + Users with call-out privileges ". + + pgp-algorithm: The value of this parameter indicates the PGP message + integrity check (MIC) to be used to produce the signature. If + this not present it is assumed to be "md5". The currently + defined values are "md5" for the MD5 checksum, and "sha1" for + the SHA.1 algorithm. + + pgp-version: The version of PGP that the client MUST use. Common + values are "2.6.2" and "5.0". The default is 5.0. + + nonce: A server-specified data string which should be uniquely + generated each time a 401 response is made. It is RECOMMENDED + that this string be base64 or hexadecimal data. Specifically, + since the string is passed in the header lines as a quoted + string, the double-quote character is not allowed. The contents + of the nonce are implementation dependent. The quality of the + implementation depends on a good choice. Since the nonce is used + only to prevent replay attacks and is signed, a time stamp in + units convenient to the server is sufficient. + + + + + + + +Handley, et al. Standards Track [Page 116] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Replay attacks within the duration of the call setup are of + limited interest, so that timestamps with a resolution of a + few seconds are often should be sufficient. In that case, + the server does not have to keep a record of the nonces. + + Example: + + WWW-Authenticate: pgp ;version="5.0" + ;realm="Your Startrek identity, please" ;algorithm=md5 + ;nonce="913082051" + + + +15.1.2 The Authorization Request Header + + The client is expected to retry the request, passing an Authorization + header line, which is defined as follows. + + + + Authorization = "Authorization" ":" "pgp" *( ";" pgp-response ) + pgp-response = realm | pgp-version | pgp-signature + | signed-by | nonce + pgp-signature = "signature" "=" quoted-string + signed-by = "signed-by" "=" <"> URI <"> + + + The client MUST increment the CSeq header before resubmitting the + request. The signature MUST correspond to the From header of the + request unless the signed-by parameter is provided. + + pgp-signature: The PGP ASCII-armored signature [33], as it appears + between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" + delimiters, without the version indication. The signature is + included without any linebreaks. + + The signature is computed across the nonce (if present), request + method, request version and header fields following the Authorization + header and the message body, in the same order as they appear in the + message. The request method and version are prepended to the header + fields without any white space. The signature is computed across the + headers as sent, and the terminating CRLF. The CRLF following the + Authorization header is NOT included in the signature. + + A server MAY be configured not to generate nonces only if replay + attacks are not a concern. + + + + + +Handley, et al. Standards Track [Page 117] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Not generating nonces avoids the additional set of request, + 401 response and possibly ACK messages and reduces delay by + one round-trip time. + + + Using the ASCII-armored version is about 25% less space- + efficient than including the binary signature, but it is + significantly easier for the receiver to piece together. + Versions of the PGP program always include the full + (compressed) signed text in their output unless ASCII- + armored mode ( -sta ) is specified. Typical signatures are + about 200 bytes long. -- The PGP signature mechanism allows + the client to simply pass the request to an external PGP + program. This relies on the requirement that proxy servers + are not allowed to reorder or change header fields. + + realm: The realm is copied from the corresponding WWW-Authenticate + header field parameter. + + signed-by: If and only if the request was not signed by the entity + listed in the From header, the signed-by header indicates the + name of the signing entity, expressed as a URI. + + Receivers of signed SIP messages SHOULD discard any end-to-end header + fields above the Authorization header, as they may have been + maliciously added en route by a proxy. + + Example: + + Authorization: pgp version="5.0" + ;realm="Your Startrek identity, please" + ;nonce="913082051" + ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf + VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt + SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX + =aIrx" + + + +15.2 PGP Encryption Scheme + + The PGP encryption scheme uses the following syntax: + + + + Encryption = "Encryption" ":" "pgp" pgp-eparams + pgp-eparams = 1# ( pgp-version | pgp-encoding ) + pgp-encoding = "encoding" "=" "ascii" | token + + + +Handley, et al. Standards Track [Page 118] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + encoding: Describes the encoding or "armor" used by PGP. The value + "ascii" refers to the standard PGP ASCII armor, without the + lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and + without the version identifier. By default, the encrypted part + is included as binary. + + Example: + + Encryption: pgp version="2.6.2", encoding="ascii" + + + +15.3 Response-Key Header Field for PGP + + + + Response-Key = "Response-Key" ":" "pgp" pgp-eparams + pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key) + pgp-key = "key" "=" quoted-string + + + If ASCII encoding has been requested via the encoding parameter, the + key parameter contains the user's public key as extracted from the + pgp key ring with the "pgp -kxa user ". + + Example: + + Response-Key: pgp version="2.6.2", encoding="ascii", + key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk + mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx + sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu + bmVAY3MuY29sdW1iaWEuZWR1Pg== + =+y19" + + + +16 Examples + + In the following examples, we often omit the message body and the + corresponding Content-Length and Content-Type headers for brevity. + +16.1 Registration + + A user at host saturn.bell-tel.com registers on start-up, via + multicast, with the local SIP server named bell-tel.com. In the + example, the user agent on saturn expects to receive SIP requests on + UDP port 3890. + + + + +Handley, et al. Standards Track [Page 119] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + C->S: REGISTER sip:bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP saturn.bell-tel.com + From: sip:watson@bell-tel.com + To: sip:watson@bell-tel.com + Call-ID: 70710@saturn.bell-tel.com + CSeq: 1 REGISTER + Contact: + Expires: 7200 + + + + The registration expires after two hours. Any future invitations for + watson@bell-tel.com arriving at sip.bell-tel.com will now be + redirected to watson@saturn.bell-tel.com, UDP port 3890. + + If Watson wants to be reached elsewhere, say, an on-line service he + uses while traveling, he updates his reservation after first + cancelling any existing locations: + + + C->S: REGISTER sip:bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP saturn.bell-tel.com + From: sip:watson@bell-tel.com + To: sip:watson@bell-tel.com + Call-ID: 70710@saturn.bell-tel.com + CSeq: 2 REGISTER + Contact: * + Expires: 0 + + C->S: REGISTER sip:bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP saturn.bell-tel.com + From: sip:watson@bell-tel.com + To: sip:watson@bell-tel.com + Call-ID: 70710@saturn.bell-tel.com + CSeq: 3 REGISTER + Contact: sip:tawatson@example.com + + + + Now, the server will forward any request for Watson to the server at + example.com, using the Request-URI tawatson@example.com. For the + server at example.com to reach Watson, he will need to send a + REGISTER there, or inform the server of his current location through + some other means. + + It is possible to use third-party registration. Here, the secretary + jon.diligent registers his boss, T. Watson: + + + + +Handley, et al. Standards Track [Page 120] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + C->S: REGISTER sip:bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP pluto.bell-tel.com + From: sip:jon.diligent@bell-tel.com + To: sip:watson@bell-tel.com + Call-ID: 17320@pluto.bell-tel.com + CSeq: 1 REGISTER + Contact: sip:tawatson@example.com + + + + The request could be sent to either the registrar at bell-tel.com or + the server at example.com. In the latter case, the server at + example.com would proxy the request to the address indicated in the + Request-URI. Then, Max-Forwards header could be used to restrict the + registration to that server. + +16.2 Invitation to a Multicast Conference + + The first example invites schooler@vlsi.cs.caltech.edu to a multicast + session. All examples use the Session Description Protocol (SDP) (RFC + 2327 [6]) as the session description format. + +16.2.1 Request + + + C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0 + Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 + ;maddr=239.128.16.254;ttl=16 + Via: SIP/2.0/UDP north.east.isi.edu + From: Mark Handley + To: Eve Schooler + Call-ID: 2963313058@north.east.isi.edu + CSeq: 1 INVITE + Subject: SIP will be discussed, too + Content-Type: application/sdp + Content-Length: 187 + + v=0 + o=user1 53655765 2353687637 IN IP4 128.3.4.5 + s=Mbone Audio + i=Discussion of Mbone Engineering Issues + e=mbone@somewhere.com + c=IN IP4 224.2.0.1/127 + t=0 0 + m=audio 3456 RTP/AVP 0 + + + + + + +Handley, et al. Standards Track [Page 121] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The From request header above states that the request was initiated + by mjh@isi.edu and addressed to schooler@caltech.edu (From header + fields). The Via fields list the hosts along the path from invitation + initiator (the last element of the list) towards the callee. In the + example above, the message was last multicast to the administratively + scoped group 239.128.16.254 with a ttl of 16 from the host + csvax.cs.caltech.edu. The second Via header field indicates that it + was originally sent from the host north.east.isi.edu. The Request-URI + indicates that the request is currently being being addressed to + schooler@cs.caltech.edu, the local address that csvax looked up for + the callee. + + In this case, the session description is using the Session + Description Protocol (SDP), as stated in the Content-Type header. + + The header is terminated by an empty line and is followed by a + message body containing the session description. + +16.2.2 Response + + The called user agent, directly or indirectly through proxy servers, + indicates that it is alerting ("ringing") the called party: + + + S->C: SIP/2.0 180 Ringing + Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 + ;maddr=239.128.16.254;ttl=16 + Via: SIP/2.0/UDP north.east.isi.edu + From: Mark Handley + To: Eve Schooler ;tag=9883472 + Call-ID: 2963313058@north.east.isi.edu + CSeq: 1 INVITE + + + + A sample response to the invitation is given below. The first line of + the response states the SIP version number, that it is a 200 (OK) + response, which means the request was successful. The Via headers are + taken from the request, and entries are removed hop by hop as the + response retraces the path of the request. A new authentication field + MAY be added by the invited user's agent if required. The Call-ID is + taken directly from the original request, along with the remaining + fields of the request message. The original sense of From field is + preserved (i.e., it is the session initiator). + + In addition, the Contact header gives details of the host where the + user was located, or alternatively the relevant proxy contact point + which should be reachable from the caller's host. + + + +Handley, et al. Standards Track [Page 122] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + S->C: SIP/2.0 200 OK + Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 + ;maddr=239.128.16.254;ttl=16 + Via: SIP/2.0/UDP north.east.isi.edu + From: Mark Handley + To: Eve Schooler ;tag=9883472 + Call-ID: 2963313058@north.east.isi.edu + CSeq: 1 INVITE + Contact: sip:es@jove.cs.caltech.edu + + + + The caller confirms the invitation by sending an ACK request to the + location named in the Contact header: + + + C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0 + Via: SIP/2.0/UDP north.east.isi.edu + From: Mark Handley + To: Eve Schooler ;tag=9883472 + Call-ID: 2963313058@north.east.isi.edu + CSeq: 1 ACK + + + +16.3 Two-party Call + + For two-party Internet phone calls, the response must contain a + description of where to send the data. In the example below, Bell + calls Watson. Bell indicates that he can receive RTP audio codings 0 + (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4). + + + C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Subject: Mr. Watson, come here. + Content-Type: application/sdp + Content-Length: ... + + v=0 + o=bell 53655765 2353687637 IN IP4 128.3.4.5 + s=Mr. Watson, come here. + c=IN IP4 kton.bell-tel.com + m=audio 3456 RTP/AVP 0 3 4 5 + + + +Handley, et al. Standards Track [Page 123] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + S->C: SIP/2.0 100 Trying + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Content-Length: 0 + + S->C: SIP/2.0 180 Ringing + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Content-Length: 0 + + S->C: SIP/2.0 182 Queued, 2 callers ahead + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Content-Length: 0 + + S->C: SIP/2.0 182 Queued, 1 caller ahead + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Content-Length: 0 + + S->C: SIP/2.0 200 OK + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 INVITE + Contact: sip:watson@boston.bell-tel.com + Content-Type: application/sdp + Content-Length: ... + + v=0 + o=watson 4858949 4858949 IN IP4 192.1.2.3 + s=I'm on my way + c=IN IP4 boston.bell-tel.com + m=audio 5004 RTP/AVP 0 3 + + + + +Handley, et al. Standards Track [Page 124] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + The example illustrates the use of informational status responses. + Here, the reception of the call is confirmed immediately (100), then, + possibly after some database mapping delay, the call rings (180) and + is then queued, with periodic status updates. + + Watson can only receive PCMU and GSM. Note that Watson's list of + codecs may or may not be a subset of the one offered by Bell, as each + party indicates the data types it is willing to receive. Watson will + send audio data to port 3456 at c.bell-tel.com, Bell will send to + port 5004 at boston.bell-tel.com. + + By default, the media session is one RTP session. Watson will receive + RTCP packets on port 5005, while Bell will receive them on port 3457. + + Since the two sides have agreed on the set of media, Bell confirms + the call without enclosing another session description: + + + C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 1 ACK + + + +16.4 Terminating a Call + + To terminate a call, caller or callee can send a BYE request: + + + C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP kton.bell-tel.com + From: A. Bell + To: T. A. Watson ;tag=37462311 + Call-ID: 3298420296@kton.bell-tel.com + CSeq: 2 BYE + + + + If the callee wants to abort the call, it simply reverses the To and + From fields. Note that it is unlikely that a BYE from the callee will + traverse the same proxies as the original INVITE. + + + + + + + +Handley, et al. Standards Track [Page 125] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +16.5 Forking Proxy + + In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated + at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At + the time of the call, Watson is logged in at two workstations, + t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has + registered with the IEEE proxy server (P) called sip.ieee.org. The + IEEE server also has a registration for the home machine of Watson, + at watson@h.bell-tel.com (H), as well as a permanent registration at + watson@acm.org (A). For brevity, the examples omit the session + description and Via header fields. + + Bell's user agent sends the invitation to the SIP server for the + ieee.org domain: + + + C->P: INVITE sip:t.watson@ieee.org SIP/2.0 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + The SIP server at ieee.org tries the four addresses in parallel. It + sends the following message to the home machine: + + + P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=1 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + This request immediately yields a 404 (Not Found) response, since + Watson is not currently logged in at home: + + + H->P: SIP/2.0 404 Not Found + Via: SIP/2.0/UDP sip.ieee.org ;branch=1 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=87454273 + + + +Handley, et al. Standards Track [Page 126] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + The proxy ACKs the response so that host H can stop retransmitting + it: + + P->H: ACK sip:watson@h.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=1 + From: A. Bell + To: T. Watson ;tag=87454273 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 ACK + + + + Also, P attempts to reach Watson through the ACM server: + + P->A: INVITE sip:watson@acm.org SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=2 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + In parallel, the next attempt proceeds, with an INVITE to X and Y: + + + P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=3 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=4 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + +Handley, et al. Standards Track [Page 127] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + As it happens, both Watson at X and a colleague in the other lab at + host Y hear the phones ringing and pick up. Both X and Y return 200s + via the proxy to Bell. + + + X->P: SIP/2.0 200 OK + Via: SIP/2.0/UDP sip.ieee.org ;branch=3 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=192137601 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + Contact: sip:t.watson@x.bell-tel.com + + Y->P: SIP/2.0 200 OK + Via: SIP/2.0/UDP sip.ieee.org ;branch=4 + Via: SIP/2.0/UDP c.bell-tel.com + Contact: sip:t.watson@y.bell-tel.com + From: A. Bell + To: T. Watson ;tag=35253448 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + + + + Both responses are forwarded to Bell, using the Via information. At + this point, the ACM server is still searching its database. P can now + cancel this attempt: + + + P->A: CANCEL sip:watson@acm.org SIP/2.0 + Via: SIP/2.0/UDP sip.ieee.org ;branch=2 + From: A. Bell + To: T. Watson + Call-ID: 31415@c.bell-tel.com + CSeq: 1 CANCEL + + + + The ACM server gladly stops its neural-network database search and + responds with a 200. The 200 will not travel any further, since P is + the last Via stop. + + + A->P: SIP/2.0 200 OK + Via: SIP/2.0/UDP sip.ieee.org ;branch=2 + From: A. Bell + To: T. Watson + + + +Handley, et al. Standards Track [Page 128] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Call-ID: 31415@c.bell-tel.com + CSeq: 1 CANCEL + + + + Bell gets the two 200 responses from X and Y in short order. Bell's + reaction now depends on his software. He can either send an ACK to + both if human intelligence is needed to determine who he wants to + talk to or he can automatically reject one of the two calls. Here, he + acknowledges both, separately and directly to the final destination: + + + C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=192137601 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 ACK + + C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=35253448 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 ACK + + + + After a brief discussion between Bell with X and Y, it becomes clear + that Watson is at X. (Note that this is not a three-way call; only + Bell can talk to X and Y, but X and Y cannot talk to each other.) + Thus, Bell sends a BYE to Y, which is replied to: + + + C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0 + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=35253448 + Call-ID: 31415@c.bell-tel.com + CSeq: 2 BYE + + Y->C: SIP/2.0 200 OK + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=35253448 + Call-ID: 31415@c.bell-tel.com + CSeq: 2 BYE + + + + +Handley, et al. Standards Track [Page 129] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +16.6 Redirects + + Replies with status codes 301 (Moved Permanently) or 302 (Moved + Temporarily) specify another location using the Contact field. + Continuing our earlier example, the server P at ieee.org decides to + redirect rather than proxy the request: + + + P->C: SIP/2.0 302 Moved temporarily + Via: SIP/2.0/UDP c.bell-tel.com + From: A. Bell + To: T. Watson ;tag=72538263 + Call-ID: 31415@c.bell-tel.com + CSeq: 1 INVITE + Contact: sip:watson@h.bell-tel.com, + sip:watson@acm.org, sip:t.watson@x.bell-tel.com, + sip:watson@y.bell-tel.com + CSeq: 1 INVITE + + + + As another example, assume Alice (A) wants to delegate her calls to + Bob (B) while she is on vacation until July 29th, 1998. Any calls + meant for her will reach Bob with Alice's To field, indicating to him + what role he is to play. Charlie (C) calls Alice (A), whose server + returns: + + + A->C: SIP/2.0 302 Moved temporarily + From: Charlie + To: Alice ;tag=2332462 + Call-ID: 27182@caller.com + Contact: sip:bob@anywhere.com + Expires: Wed, 29 Jul 1998 9:00:00 GMT + CSeq: 1 INVITE + + + + Charlie then sends the following request to the SIP server of the + anywhere.com domain. Note that the server at anywhere.com forwards + the request to Bob based on the Request-URI. + + + C->B: INVITE sip:bob@anywhere.com SIP/2.0 + From: sip:charlie@caller.com + To: sip:alice@anywhere.com + Call-ID: 27182@caller.com + CSeq: 2 INVITE + + + +Handley, et al. Standards Track [Page 130] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + In the third redirection example, we assume that all outgoing + requests are directed through a local firewall F at caller.com, with + Charlie again inviting Alice: + + + C->F: INVITE sip:alice@anywhere.com SIP/2.0 + From: sip:charlie@caller.com + To: Alice + Call-ID: 27182@caller.com + CSeq: 1 INVITE + + + + The local firewall at caller.com happens to be overloaded and thus + redirects the call from Charlie to a secondary server S: + + + F->C: SIP/2.0 302 Moved temporarily + From: sip:charlie@caller.com + To: Alice + Call-ID: 27182@caller.com + CSeq: 1 INVITE + Contact: + + + + Based on this response, Charlie directs the same invitation to the + secondary server spare.caller.com at port 5080, but maintains the + same Request-URI as before: + + + C->S: INVITE sip:alice@anywhere.com SIP/2.0 + From: sip:charlie@caller.com + To: Alice + Call-ID: 27182@caller.com + CSeq: 2 INVITE + + + +16.7 Negotiation + + An example of a 606 (Not Acceptable) response is: + + + S->C: SIP/2.0 606 Not Acceptable + From: sip:mjh@isi.edu + To: ;tag=7434264 + Call-ID: 14142@north.east.isi.edu + + + +Handley, et al. Standards Track [Page 131] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + CSeq: 1 INVITE + Contact: sip:mjh@north.east.isi.edu + Warning: 370 "Insufficient bandwidth (only have ISDN)", + 305 "Incompatible media format", + 330 "Multicast not available" + Content-Type: application/sdp + Content-Length: 50 + + v=0 + s=Let's talk + b=CT:128 + c=IN IP4 north.east.isi.edu + m=audio 3456 RTP/AVP 5 0 7 + m=video 2232 RTP/AVP 31 + + + + In this example, the original request specified a bandwidth that was + higher than the access link could support, requested multicast, and + requested a set of media encodings. The response states that only 128 + kb/s is available and that (only) DVI, PCM or LPC audio could be + supported in order of preference. + + The response also states that multicast is not available. In such a + case, it might be appropriate to set up a transcoding gateway and + re-invite the user. + +16.8 OPTIONS Request + + A caller Alice can use an OPTIONS request to find out the + capabilities of a potential callee Bob, without "ringing" the + designated address. Bob returns a description indicating that he is + capable of receiving audio encodings PCM Ulaw (payload type 0), 1016 + (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic + payload type 99), and video encodings H.261 (payload type 31) and + H.263 (payload type 34). + + + C->S: OPTIONS sip:bob@example.com SIP/2.0 + From: Alice + To: Bob + Call-ID: 6378@host.anywhere.org + CSeq: 1 OPTIONS + Accept: application/sdp + + S->C: SIP/2.0 200 OK + From: Alice + To: Bob ;tag=376364382 + + + +Handley, et al. Standards Track [Page 132] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + Call-ID: 6378@host.anywhere.org + Content-Length: 81 + Content-Type: application/sdp + + v=0 + m=audio 0 RTP/AVP 0 1 3 99 + m=video 0 RTP/AVP 31 34 + a=rtpmap:99 SX7300/8000 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 133] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +A Minimal Implementation + +A.1 Client + + All clients MUST be able to generate the INVITE and ACK requests. + Clients MUST generate and parse the Call-ID, Content-Length, + Content-Type, CSeq, From and To headers. Clients MUST also parse the + Require header. A minimal implementation MUST understand SDP (RFC + 2327, [6]). It MUST be able to recognize the status code classes 1 + through 6 and act accordingly. + + The following capability sets build on top of the minimal + implementation described in the previous paragraph. In general, each + capability listed below builds on the ones above it: + + Basic: A basic implementation adds support for the BYE method to + allow the interruption of a pending call attempt. It includes a + User-Agent header in its requests and indicates its preferred + language in the Accept-Language header. + + Redirection: To support call forwarding, a client needs to be able to + understand the Contact header, but only the SIP-URL part, not + the parameters. + + Firewall-friendly: A firewall-friendly client understands the Route + and Record-Route header fields and can be configured to use a + local proxy for all outgoing requests. + + Negotiation: A client MUST be able to request the OPTIONS method and + understand the 380 (Alternative Service) status and the Contact + parameters to participate in terminal and media negotiation. It + SHOULD be able to parse the Warning response header to provide + useful feedback to the caller. + + Authentication: If a client wishes to invite callees that require + caller authentication, it MUST be able to recognize the 401 + (Unauthorized) status code, MUST be able to generate the + Authorization request header and MUST understand the WWW- + Authenticate response header. + + If a client wishes to use proxies that require caller authentication, + it MUST be able to recognize the 407 (Proxy Authentication Required) + status code, MUST be able to generate the Proxy-Authorization request + header and understand the Proxy-Authenticate response header. + + + + + + + +Handley, et al. Standards Track [Page 134] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +A.2 Server + + A minimally compliant server implementation MUST understand the + INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also + understand CANCEL. It MUST parse and generate, as appropriate, the + Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max- + Forwards, Require, To and Via headers. It MUST echo the CSeq and + Timestamp headers in the response. It SHOULD include the Server + header in its responses. + +A.3 Header Processing + + Table 6 lists the headers that different implementations support. UAC + refers to a user-agent client (calling user agent), UAS to a user- + agent server (called user-agent). + + The fields in the table have the following meaning. Type is as in + Table 4 and 5. "-" indicates the field is not meaningful to this + system (although it might be generated by it). "m" indicates the + field MUST be understood. "b" indicates the field SHOULD be + understood by a Basic implementation. "r" indicates the field SHOULD + be understood if the system claims to understand redirection. "a" + indicates the field SHOULD be understood if the system claims to + support authentication. "e" indicates the field SHOULD be understood + if the system claims to support encryption. "o" indicates support of + the field is purely optional. Headers whose support is optional for + all implementations are not shown. + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 135] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + + + type UAC proxy UAS registrar + _____________________________________________________ + Accept R - o m m + Accept-Encoding R - - m m + Accept-Language R - b b b + Allow 405 o - - - + Authorization R a o a a + Call-ID g m m m m + Content-Encoding g m - m m + Content-Length g m m m m + Content-Type g m - m m + CSeq g m m m m + Encryption g e - e e + Expires g - o o m + From g m o m m + Hide R - m - - + Contact R - - - m + Contact r r r - - + Max-Forwards R - b - - + Proxy-Authenticate 407 a - - - + Proxy-Authorization R - a - - + Proxy-Require R - m - - + Require R m - m m + Response-Key R - - e e + Route R - m - - + Timestamp g o o m m + To g m m m m + Unsupported r b b - - + User-Agent g b - b - + Via g m m m m + WWW-Authenticate 401 a - - - + + + Table 6: Header Field Processing Requirements + +B Usage of the Session Description Protocol (SDP) + + This section describes the use of the Session Description Protocol + (SDP) (RFC 2327 [6]). + +B.1 Configuring Media Streams + + The caller and callee align their media descriptions so that the nth + media stream ("m=" line) in the caller's session description + corresponds to the nth media stream in the callee's description. + + + + +Handley, et al. Standards Track [Page 136] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + All media descriptions SHOULD contain "a=rtpmap" mappings from RTP + payload types to encodings. + + This allows easier migration away from static payload + types. + + If the callee wants to neither send nor receive a stream offered by + the caller, the callee sets the port number of that stream to zero in + its media description. + + + There currently is no other way than port zero for the + callee to refuse a bidirectional stream offered by the + caller. Both caller and callee need to be aware what media + tools are to be started. + + For example, assume that the caller Alice has included the following + description in her INVITE request. It includes an audio stream and + two bidirectional video streams, using H.261 (payload type 31) and + MPEG (payload type 32). + + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.anywhere.com + c=IN IP4 host.anywhere.com + m=audio 49170 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 51372 RTP/AVP 31 + a=rtpmap:31 H261/90000 + m=video 53000 RTP/AVP 32 + a=rtpmap:32 MPV/90000 + + + + The callee, Bob, does not want to receive or send the first video + stream, so it returns the media description below: + + v=0 + o=bob 2890844730 2890844730 IN IP4 host.example.com + c=IN IP4 host.example.com + m=audio 47920 RTP/AVP 0 1 + a=rtpmap:0 PCMU/8000 + a=rtpmap:1 1016/8000 + m=video 0 RTP/AVP 31 + m=video 53000 RTP/AVP 32 + a=rtpmap:32 MPV/90000 + + + + + +Handley, et al. Standards Track [Page 137] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +B.2 Setting SDP Values for Unicast + + If a session description from a caller contains a media stream which + is listed as send (receive) only, it means that the caller is only + willing to send (receive) this stream, not receive (send). The same + is true for the callee. + + For receive-only and send-or-receive streams, the port number and + address in the session description indicate where the media stream + should be sent to by the recipient of the session description, either + caller or callee. For send-only streams, the address and port number + have no significance and SHOULD be set to zero. + + The list of payload types for each media stream conveys two pieces of + information, namely the set of codecs that the caller or callee is + capable of sending or receiving, and the RTP payload type numbers + used to identify those codecs. For receive-only or send-and-receive + media streams, a caller SHOULD list all of the codecs it is capable + of supporting in the session description in an INVITE or ACK. For + send-only streams, the caller SHOULD indicate only those it wishes to + send for this session. For receive-only streams, the payload type + numbers indicate the value of the payload type field in RTP packets + the caller is expecting to receive for that codec type. For send-only + streams, the payload type numbers indicate the value of the payload + type field in RTP packets the caller is planning to send for that + codec type. For send-and-receive streams, the payload type numbers + indicate the value of the payload type field the caller expects to + both send and receive. + + If a media stream is listed as receive-only by the caller, the callee + lists, in the response, those codecs it intends to use from among the + ones listed in the request. If a media stream is listed as send-only + by the caller, the callee lists, in the response, those codecs it is + willing to receive among the ones listed in the the request. If the + media stream is listed as both send and receive, the callee lists + those codecs it is capable of sending or receiving among the ones + listed by the caller in the INVITE. The actual payload type numbers + in the callee's session description corresponding to a particular + codec MUST be the same as the caller's session description. + + If caller and callee have no media formats in common for a particular + stream, the callee MUST return a session description containing the + particular "m=" line, but with the port number set to zero, and no + payload types listed. + + If there are no media formats in common for all streams, the callee + SHOULD return a 400 response, with a 304 Warning header field. + + + + +Handley, et al. Standards Track [Page 138] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +B.3 Multicast Operation + + The interpretation of send-only and receive-only for multicast media + sessions differs from that for unicast sessions. For multicast, + send-only means that the recipient of the session description (caller + or callee) SHOULD only send media streams to the address and port + indicated. Receive-only means that the recipient of the session + description SHOULD only receive media on the address and port + indicated. + + For multicast, receive and send multicast addresses are the same and + all parties use the same port numbers to receive media data. If the + session description provided by the caller is acceptable to the + callee, the callee can choose not to include a session description or + MAY echo the description in the response. + + A callee MAY, in the response, return a session description with some + of the payload types removed, or port numbers set to zero (but no + other value). This indicates to the caller that the callee does not + support the given stream or media types which were removed. A callee + MUST NOT change whether a given stream is send-only, receive-only, or + send-and-receive. + + If a callee does not support multicast at all, it SHOULD return a 400 + status response and include a 330 Warning. + +B.4 Delayed Media Streams + + In some cases, a caller may not know the set of media formats which + it can support at the time it would like to issue an invitation. This + is the case when the caller is actually a gateway to another protocol + which performs media format negotiation after call setup. When this + occurs, a caller MAY issue an INVITE with a session description that + contains no media lines. The callee SHOULD interpret this to mean + that the caller wishes to participate in a multimedia session + described by the session description, but that the media streams are + not yet known. The callee SHOULD return a session description + indicating the streams and media formats it is willing to support, + however. The caller MAY update the session description either in the + ACK request or in a re-INVITE at a later time, once the streams are + known. + +B.5 Putting Media Streams on Hold + + If a party in a call wants to put the other party "on hold", i.e., + request that it temporarily stops sending one or more media streams, + a party re-invites the other by sending an INVITE request with a + modified session description. The session description is the same as + + + +Handley, et al. Standards Track [Page 139] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + in the original invitation (or response), but the "c" destination + addresses for the media streams to be put on hold are set to zero + (0.0.0.0). + +B.6 Subject and SDP "s=" Line + + The SDP "s=" line and the SIP Subject header field have different + meanings when inviting to a multicast session. The session + description line describes the subject of the multicast session, + while the SIP Subject header field describes the reason for the + invitation. The example in Section 16.2 illustrates this point. For + invitations to two-party sessions, the SDP "s=" line MAY be left + empty. + +B.7 The SDP "o=" Line + + The "o=" line is not strictly necessary for two-party sessions, but + MUST be present to allow re-use of SDP-based tools. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 140] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +C Summary of Augmented BNF + + All of the mechanisms specified in this document are described in + both prose and an augmented Backus-Naur Form (BNF) similar to that + used by RFC 822 [9]. Implementors will need to be familiar with the + notation in order to understand this specification. The augmented BNF + includes the following constructs: + + + + name = definition + + + The name of a rule is simply the name itself (without any enclosing + "<" and ">") and is separated from its definition by the equal "=" + character. White space is only significant in that indentation of + continuation lines is used to indicate a rule definition that spans + more than one line. Certain basic rules are in uppercase, such as SP, + LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within + definitions whenever their presence will facilitate discerning the + use of rule names. + + + "literal" + + + Quotation marks surround literal text. Unless stated otherwise, the + text is case-insensitive. + + + rule1 | rule2 + + + Elements separated by a bar ("|") are alternatives, e.g., "yes | no" + will accept yes or no. + + + (rule1 rule2) + + + Elements enclosed in parentheses are treated as a single element. + Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo + elem" and "elem bar elem". + + + + + + + + +Handley, et al. Standards Track [Page 141] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + *rule + + + The character "*" preceding an element indicates repetition. The full + form is "*element" indicating at least and at most + occurrences of element. Default values are 0 and infinity so that + "*(element)" allows any number, including zero; "1*element" requires + at least one; and "1*2element" allows one or two. + + + [rule] + + + Square brackets enclose optional elements; "[foo bar]" is equivalent + to "*1(foo bar)". + + + N rule + + + Specific repetition: "(element)" is equivalent to + "*(element)"; that is, exactly occurrences of (element). + Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three + alphabetic characters. + + + #rule + + + A construct "#" is defined, similar to "*", for defining lists of + elements. The full form is "# element" indicating at least + and at most elements, each separated by one or more commas (",") + and OPTIONAL linear white space (LWS). This makes the usual form of + lists very easy; a rule such as + + + + ( *LWS element *( *LWS "," *LWS element )) + + + can be shown as 1# element. Wherever this construct is used, null + elements are allowed, but do not contribute to the count of elements + present. That is, "(element), , (element)" is permitted, but counts + as only two elements. Therefore, where at least one element is + required, at least one non-null element MUST be present. Default + values are 0 and infinity so that "#element" allows any number, + including zero; "1#element" requires at least one; and "1#2element" + allows one or two. + + + +Handley, et al. Standards Track [Page 142] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + ; comment + + + A semi-colon, set off some distance to the right of rule text, starts + a comment that continues to the end of line. This is a simple way of + including useful notes in parallel with the specifications. + + + implied *LWS + + + The grammar described by this specification is word-based. Except + where noted otherwise, linear white space (LWS) can be included + between any two adjacent words (token or quoted-string), and between + adjacent tokens and separators, without changing the interpretation + of a field. At least one delimiter (LWS and/or separators) MUST exist + between any two tokens (for the definition of "token" below), since + they would otherwise be interpreted as a single token. + +C.1 Basic Rules + + The following rules are used throughout this specification to + describe basic parsing constructs. The US-ASCII coded character set + is defined by ANSI X3.4-1986. + + + OCTET = + CHAR = + upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | + "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | + "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" + lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | + "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | + "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" + alpha = lowalpha | upalpha + digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | + "8" | "9" + alphanum = alpha | digit + CTL = + CR = %d13 ; US-ASCII CR, carriage return character + LF = %d10 ; US-ASCII LF, line feed character + SP = %d32 ; US-ASCII SP, space character + HT = %d09 ; US-ASCII HT, horizontal tab character + CRLF = CR LF ; typically the end of a line + + + The following are defined in RFC 2396 [12] for the SIP URI: + + + +Handley, et al. Standards Track [Page 143] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + unreserved = alphanum | mark + mark = "-" | "_" | "." | "!" | "~" | "*" | "'" + | "(" | ")" + escaped = "%" hex hex + + + SIP header field values can be folded onto multiple lines if the + continuation line begins with a space or horizontal tab. All linear + white space, including folding, has the same semantics as SP. A + recipient MAY replace any linear white space with a single SP before + interpreting the field value or forwarding the message downstream. + + + + LWS = [CRLF] 1*( SP | HT ) ; linear whitespace + + + The TEXT-UTF8 rule is only used for descriptive field contents and + values that are not intended to be interpreted by the message parser. + Words of *TEXT-UTF8 contain characters from the UTF-8 character set + (RFC 2279 [21]). In this regard, SIP differs from HTTP, which uses + the ISO 8859-1 character set. + + + + TEXT-UTF8 = + + + A CRLF is allowed in the definition of TEXT-UTF8 only as part of a + header field continuation. It is expected that the folding LWS will + be replaced with a single SP before interpretation of the TEXT-UTF8 + value. + + Hexadecimal numeric characters are used in several protocol elements. + + + + hex = "A" | "B" | "C" | "D" | "E" | "F" + | "a" | "b" | "c" | "d" | "e" | "f" | digit + + + Many SIP header field values consist of words separated by LWS or + special characters. These special characters MUST be in a quoted + string to be used within a parameter value. + + + + + + +Handley, et al. Standards Track [Page 144] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + token = 1*< any CHAR except CTL's or separators> + separators = "(" | ")" | "<" | ">" | "@" | + "," | ";" | ":" | "\" | <"> | + "/" | "[" | "]" | "?" | "=" | + "{" | "}" | SP | HT + + + Comments can be included in some SIP header fields by surrounding the + comment text with parentheses. Comments are only allowed in fields + containing "comment" as part of their field value definition. In all + other fields, parentheses are considered part of the field value. + + + + comment = "(" *(ctext | quoted-pair | comment) ")" + ctext = < any TEXT-UTF8 excluding "(" and ")"> + + + A string of text is parsed as a single word if it is quoted using + double-quote marks. + + + + quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) + qdtext = > + + + The backslash character ("\") MAY be used as a single-character + quoting mechanism only within quoted-string and comment constructs. + + + + quoted-pair = " \ " CHAR + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 145] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +D Using SRV DNS Records + + The following procedure is experimental and relies on DNS SRV records + (RFC 2052 [14]). The steps listed below are used in place of the two + steps in section 1.4.2. + + If a step elicits no addresses, the client continues to the next + step. However if a step elicits one or more addresses, but no SIP + server at any of those addresses responds, then the client concludes + the server is down and doesn't continue on to the next step. + + When SRV records are to be used, the protocol to use when querying + for the SRV record is "sip". SRV records contain port numbers for + servers, in addition to IP addresses; the client always uses this + port number when contacting the SIP server. Otherwise, the port + number in the SIP URI is used, if present. If there is no port number + in the URI, the default port, 5060, is used. + + 1. If the host portion of the Request-URI is an IP address, + the client contacts the server at the given address. If the + host portion of the Request-URI is not an IP address, the + client proceeds to the next step. + + 2. The Request-URI is examined. If it contains an explicit + port number, the next two steps are skipped. + + 3. The Request-URI is examined. If it does not specify a + protocol (TCP or UDP), the client queries the name server + for SRV records for both UDP (if supported by the client) + and TCP (if supported by the client) SIP servers. The + format of these queries is defined in RFC 2052 [14]. The + results of the query or queries are merged together and + ordered based on priority. Then, the searching technique + outlined in RFC 2052 [14] is used to select servers in + order. If DNS doesn't return any records, the user goes to + the last step. Otherwise, the user attempts to contact + each server in the order listed. If no server is + contacted, the user gives up. + + 4. If the Request-URI specifies a protocol (TCP or UDP) that + is supported by the client, the client queries the name + server for SRV records for SIP servers of that protocol + type only. If the client does not support the protocol + specified in the Request-URI, it gives up. The searching + technique outlined in RFC 2052 [14] is used to select + servers from the DNS response in order. If DNS doesn't + + + + + +Handley, et al. Standards Track [Page 146] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + return any records, the user goes to the last step. + Otherwise, the user attempts to contact each server in the + order listed. If no server is contacted, the user gives up. + + 5. The client queries the name server for address records for + the host portion of the Request-URI. If there were no + address records, the client stops, as it has been unable to + locate a server. By address record, we mean A RR's, AAAA + RR's, or their most modern equivalent. + + A client MAY cache a successful DNS query result. A successful query + is one which contained records in the answer, and a server was + contacted at one of the addresses from the answer. When the client + wishes to send a request to the same host, it starts the search as if + it had just received this answer from the name server. The server + uses the procedures specified in RFC1035 [15] regarding cache + invalidation when the time-to-live of the DNS result expires. If the + client does not find a SIP server among the addresses listed in the + cached answer, it starts the search at the beginning of the sequence + described above. + + For example, consider a client that wishes to send a SIP request. The + Request-URI for the destination is sip:user@company.com. The client + only supports UDP. It would follow these steps: + + 1. The host portion is not an IP address, so the client goes + to step 2 above. + + 2. The client does a DNS query of QNAME="sip.udp.company.com", + QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it + omits the TCP query. There were no addresses in the DNS + response, so the client goes to the next step. + + 3. The client does a DNS query for A records for + "company.com". An address is found, so that client attempts + to contact a server at that address at port 5060. + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 147] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +E IANA Considerations + + Section 4.4 describes a name space and mechanism for registering SIP + options. + + Section 6.41 describes the name space for registering SIP warn-codes. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 148] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +F Acknowledgments + + We wish to thank the members of the IETF MMUSIC WG for their comments + and suggestions. Detailed comments were provided by Anders + Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian + Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe + J. Sambol, and Eric Tremblay. + + This work is based, inter alia, on [37,38]. + +G Authors' Addresses + + Mark Handley + AT&T Center for Internet Research at ISCI (ACIRI) + 1947 Center St., Suite 600 + Berkeley, CA 94704-119 + USA + Email: mjh@aciri.org + + Henning Schulzrinne + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue + New York, NY 10027 + USA + Email: schulzrinne@cs.columbia.edu + + Eve Schooler + Computer Science Department 256-80 + California Institute of Technology + Pasadena, CA 91125 + USA + Email: schooler@cs.caltech.edu + + Jonathan Rosenberg + Lucent Technologies, Bell Laboratories + Rm. 4C-526 + 101 Crawfords Corner Road + Holmdel, NJ 07733 + USA + Email: jdrosen@bell-labs.com + + + + + + + + + + +Handley, et al. Standards Track [Page 149] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +H Bibliography + + [1] Pandya, R., "Emerging mobile and personal communication systems," + IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995. + + [2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource ReSerVation protocol (RSVP) -- version 1 functional + specification", RFC 2205, October 1997. + + [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: + a transport protocol for real-time applications", RFC 1889, + Internet Engineering Task Force, Jan. 1996. + + [4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming + protocol (RTSP)", RFC 2326, April 1998. + + [5] Handley, M., "SAP: Session announcement protocol," Internet + Draft, Internet Engineering Task Force, Nov. 1996. Work in + progress. + + [6] Handley, M. and V. Jacobson, "SDP: session description protocol", + RFC 2327, April 1998. + + [7] International Telecommunication Union, "Visual telephone systems + and equipment for local area networks which provide a non- + guaranteed quality of service," Recommendation H.323, + Telecommunication Standardization Sector of ITU, Geneva, + Switzerland, May 1996. + + [8] International Telecommunication Union, "Control protocol for + multimedia communication," Recommendation H.245, + Telecommunication Standardization Sector of ITU, Geneva, + Switzerland, Feb. 1998. + + [9] International Telecommunication Union, "Media stream + packetization and synchronization on non-guaranteed quality of + service LANs," Recommendation H.225.0, Telecommunication + Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996. + + [10] Bradner, S., "Key words for use in RFCs to indicate requirement + levels", BCP 14, RFC 2119, Mardch 1997. + + [11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. + Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC + 2068, January 1997. + + [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource + identifiers (URI): generic syntax", RFC 2396, August 1998. + + + +Handley, et al. Standards Track [Page 150] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + [13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource + locators (URL)", RFC 1738, December 1994. + + [14] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2052, October 1996. + + [15] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, Noveberm 1997. + + [16] Hamilton, M. and R. Wright, "Use of DNS aliases for network + services", RFC 2219, October 1997. + + [17] Zimmerman, D., "The finger user information protocol", RFC 1288, + December 1991. + + [18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. + Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167, + June 1997. + + [19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access + protocol", RFC 1777, March 1995. + + [20] Schooler, E., "A multicast user directory service for + synchronous rendezvous," Master's Thesis CS-TR-96-18, Department + of Computer Science, California Institute of Technology, + Pasadena, California, Aug. 1996. + + [21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1. + Reading, Massachusetts: Addison-Wesley, 1994. + + [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [24] Crocker, D., "Standard for the format of ARPA internet text + messages", RFC STD 11, RFC 822, August 1982. + + [25] Meyer, D., "Administratively scoped IP multicast", RFC 2365, + July 1998. + + [26] Schulzrinne, H., "RTP profile for audio and video conferences + with minimal control", RFC 1890, January 1996 + + [27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + recommendations for security", RFC 1750, December 1994. + + + + +Handley, et al. Standards Track [Page 151] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + + [28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL + scheme", RFC 2368, July 1998. + + [29] Braden, B., "Requirements for internet hosts - application and + support", STD 3, RFC 1123, October 1989. + + [30] Palme, J., "Common internet message headers", RFC 2076, February + 1997. + + [31] Alvestrand, H., "IETF policy on character sets and languages", + RFC 2277, January 1998. + + [32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC + 2015, October 1996. + + [33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message + exchange formats", RFC 1991, August 1996. + + [34] Atkinson, R., "Security architecture for the internet protocol", + RFC 2401, November 1998. + + [35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC + 2246, January 1999. + + [36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: + Basic and digest access authentication," Internet Draft, + Internet Engineering Task Force, Sept. 1998. Work in progress. + + [37] Schooler, E., "Case study: multimedia conference control in a + packet-switched teleconferencing system," Journal of + Internetworking: Research and Experience , vol. 4, pp. 99--120, + June 1993. ISI reprint series ISI/RS-93-359. + + [38] Schulzrinne, H., "Personal mobility for multimedia services in + the Internet," in European Workshop on Interactive Distributed + Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. + 1996. + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 152] + +RFC 2543 SIP: Session Initiation Protocol March 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 153] -- cgit v1.2.3