diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3261.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3261.txt')
| -rw-r--r-- | doc/rfc/rfc3261.txt | 15067 |
1 files changed, 15067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3261.txt b/doc/rfc/rfc3261.txt new file mode 100644 index 0000000..00456a9 --- /dev/null +++ b/doc/rfc/rfc3261.txt @@ -0,0 +1,15067 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 3261 dynamicsoft +Obsoletes: 2543 H. Schulzrinne +Category: Standards Track Columbia U. + G. Camarillo + Ericsson + A. Johnston + WorldCom + J. Peterson + Neustar + R. Sparks + dynamicsoft + M. Handley + ICIR + E. Schooler + AT&T + June 2002 + + 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 (2002). All Rights Reserved. + +Abstract + + This document describes Session Initiation Protocol (SIP), an + application-layer control (signaling) protocol for creating, + modifying, and terminating sessions with one or more participants. + These sessions include Internet telephone calls, multimedia + distribution, and multimedia conferences. + + SIP invitations used to create sessions carry session descriptions + that allow participants to agree on a set of compatible media types. + SIP makes use of elements called proxy servers to help route requests + to the user's current location, authenticate and authorize users for + services, implement provider call-routing policies, and provide + features to users. SIP also provides a registration function that + allows users to upload their current locations for use by proxy + servers. SIP runs on top of several different transport protocols. + + + +Rosenberg, et. al. Standards Track [Page 1] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Table of Contents + + 1 Introduction ........................................ 8 + 2 Overview of SIP Functionality ....................... 9 + 3 Terminology ......................................... 10 + 4 Overview of Operation ............................... 10 + 5 Structure of the Protocol ........................... 18 + 6 Definitions ......................................... 20 + 7 SIP Messages ........................................ 26 + 7.1 Requests ............................................ 27 + 7.2 Responses ........................................... 28 + 7.3 Header Fields ....................................... 29 + 7.3.1 Header Field Format ................................. 30 + 7.3.2 Header Field Classification ......................... 32 + 7.3.3 Compact Form ........................................ 32 + 7.4 Bodies .............................................. 33 + 7.4.1 Message Body Type ................................... 33 + 7.4.2 Message Body Length ................................. 33 + 7.5 Framing SIP Messages ................................ 34 + 8 General User Agent Behavior ......................... 34 + 8.1 UAC Behavior ........................................ 35 + 8.1.1 Generating the Request .............................. 35 + 8.1.1.1 Request-URI ......................................... 35 + 8.1.1.2 To .................................................. 36 + 8.1.1.3 From ................................................ 37 + 8.1.1.4 Call-ID ............................................. 37 + 8.1.1.5 CSeq ................................................ 38 + 8.1.1.6 Max-Forwards ........................................ 38 + 8.1.1.7 Via ................................................. 39 + 8.1.1.8 Contact ............................................. 40 + 8.1.1.9 Supported and Require ............................... 40 + 8.1.1.10 Additional Message Components ....................... 41 + 8.1.2 Sending the Request ................................. 41 + 8.1.3 Processing Responses ................................ 42 + 8.1.3.1 Transaction Layer Errors ............................ 42 + 8.1.3.2 Unrecognized Responses .............................. 42 + 8.1.3.3 Vias ................................................ 43 + 8.1.3.4 Processing 3xx Responses ............................ 43 + 8.1.3.5 Processing 4xx Responses ............................ 45 + 8.2 UAS Behavior ........................................ 46 + 8.2.1 Method Inspection ................................... 46 + 8.2.2 Header Inspection ................................... 46 + 8.2.2.1 To and Request-URI .................................. 46 + 8.2.2.2 Merged Requests ..................................... 47 + 8.2.2.3 Require ............................................. 47 + 8.2.3 Content Processing .................................. 48 + 8.2.4 Applying Extensions ................................. 49 + 8.2.5 Processing the Request .............................. 49 + + + +Rosenberg, et. al. Standards Track [Page 2] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 8.2.6 Generating the Response ............................. 49 + 8.2.6.1 Sending a Provisional Response ...................... 49 + 8.2.6.2 Headers and Tags .................................... 50 + 8.2.7 Stateless UAS Behavior .............................. 50 + 8.3 Redirect Servers .................................... 51 + 9 Canceling a Request ................................. 53 + 9.1 Client Behavior ..................................... 53 + 9.2 Server Behavior ..................................... 55 + 10 Registrations ....................................... 56 + 10.1 Overview ............................................ 56 + 10.2 Constructing the REGISTER Request ................... 57 + 10.2.1 Adding Bindings ..................................... 59 + 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 + 10.2.1.2 Preferences among Contact Addresses ................. 61 + 10.2.2 Removing Bindings ................................... 61 + 10.2.3 Fetching Bindings ................................... 61 + 10.2.4 Refreshing Bindings ................................. 61 + 10.2.5 Setting the Internal Clock .......................... 62 + 10.2.6 Discovering a Registrar ............................. 62 + 10.2.7 Transmitting a Request .............................. 62 + 10.2.8 Error Responses ..................................... 63 + 10.3 Processing REGISTER Requests ........................ 63 + 11 Querying for Capabilities ........................... 66 + 11.1 Construction of OPTIONS Request ..................... 67 + 11.2 Processing of OPTIONS Request ....................... 68 + 12 Dialogs ............................................. 69 + 12.1 Creation of a Dialog ................................ 70 + 12.1.1 UAS behavior ........................................ 70 + 12.1.2 UAC Behavior ........................................ 71 + 12.2 Requests within a Dialog ............................ 72 + 12.2.1 UAC Behavior ........................................ 73 + 12.2.1.1 Generating the Request .............................. 73 + 12.2.1.2 Processing the Responses ............................ 75 + 12.2.2 UAS Behavior ........................................ 76 + 12.3 Termination of a Dialog ............................. 77 + 13 Initiating a Session ................................ 77 + 13.1 Overview ............................................ 77 + 13.2 UAC Processing ...................................... 78 + 13.2.1 Creating the Initial INVITE ......................... 78 + 13.2.2 Processing INVITE Responses ......................... 81 + 13.2.2.1 1xx Responses ....................................... 81 + 13.2.2.2 3xx Responses ....................................... 81 + 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 + 13.2.2.4 2xx Responses ....................................... 82 + 13.3 UAS Processing ...................................... 83 + 13.3.1 Processing of the INVITE ............................ 83 + 13.3.1.1 Progress ............................................ 84 + 13.3.1.2 The INVITE is Redirected ............................ 84 + + + +Rosenberg, et. al. Standards Track [Page 3] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 13.3.1.3 The INVITE is Rejected .............................. 85 + 13.3.1.4 The INVITE is Accepted .............................. 85 + 14 Modifying an Existing Session ....................... 86 + 14.1 UAC Behavior ........................................ 86 + 14.2 UAS Behavior ........................................ 88 + 15 Terminating a Session ............................... 89 + 15.1 Terminating a Session with a BYE Request ............ 90 + 15.1.1 UAC Behavior ........................................ 90 + 15.1.2 UAS Behavior ........................................ 91 + 16 Proxy Behavior ...................................... 91 + 16.1 Overview ............................................ 91 + 16.2 Stateful Proxy ...................................... 92 + 16.3 Request Validation .................................. 94 + 16.4 Route Information Preprocessing ..................... 96 + 16.5 Determining Request Targets ......................... 97 + 16.6 Request Forwarding .................................. 99 + 16.7 Response Processing ................................. 107 + 16.8 Processing Timer C .................................. 114 + 16.9 Handling Transport Errors ........................... 115 + 16.10 CANCEL Processing ................................... 115 + 16.11 Stateless Proxy ..................................... 116 + 16.12 Summary of Proxy Route Processing ................... 118 + 16.12.1 Examples ............................................ 118 + 16.12.1.1 Basic SIP Trapezoid ................................. 118 + 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 + 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 + 17 Transactions ........................................ 122 + 17.1 Client Transaction .................................. 124 + 17.1.1 INVITE Client Transaction ........................... 125 + 17.1.1.1 Overview of INVITE Transaction ...................... 125 + 17.1.1.2 Formal Description .................................. 125 + 17.1.1.3 Construction of the ACK Request ..................... 129 + 17.1.2 Non-INVITE Client Transaction ....................... 130 + 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 + 17.1.2.2 Formal Description .................................. 131 + 17.1.3 Matching Responses to Client Transactions ........... 132 + 17.1.4 Handling Transport Errors ........................... 133 + 17.2 Server Transaction .................................. 134 + 17.2.1 INVITE Server Transaction ........................... 134 + 17.2.2 Non-INVITE Server Transaction ....................... 137 + 17.2.3 Matching Requests to Server Transactions ............ 138 + 17.2.4 Handling Transport Errors ........................... 141 + 18 Transport ........................................... 141 + 18.1 Clients ............................................. 142 + 18.1.1 Sending Requests .................................... 142 + 18.1.2 Receiving Responses ................................. 144 + 18.2 Servers ............................................. 145 + 18.2.1 Receiving Requests .................................. 145 + + + +Rosenberg, et. al. Standards Track [Page 4] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 18.2.2 Sending Responses ................................... 146 + 18.3 Framing ............................................. 147 + 18.4 Error Handling ...................................... 147 + 19 Common Message Components ........................... 147 + 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 + 19.1.1 SIP and SIPS URI Components ......................... 148 + 19.1.2 Character Escaping Requirements ..................... 152 + 19.1.3 Example SIP and SIPS URIs ........................... 153 + 19.1.4 URI Comparison ...................................... 153 + 19.1.5 Forming Requests from a URI ......................... 156 + 19.1.6 Relating SIP URIs and tel URLs ...................... 157 + 19.2 Option Tags ......................................... 158 + 19.3 Tags ................................................ 159 + 20 Header Fields ....................................... 159 + 20.1 Accept .............................................. 161 + 20.2 Accept-Encoding ..................................... 163 + 20.3 Accept-Language ..................................... 164 + 20.4 Alert-Info .......................................... 164 + 20.5 Allow ............................................... 165 + 20.6 Authentication-Info ................................. 165 + 20.7 Authorization ....................................... 165 + 20.8 Call-ID ............................................. 166 + 20.9 Call-Info ........................................... 166 + 20.10 Contact ............................................. 167 + 20.11 Content-Disposition ................................. 168 + 20.12 Content-Encoding .................................... 169 + 20.13 Content-Language .................................... 169 + 20.14 Content-Length ...................................... 169 + 20.15 Content-Type ........................................ 170 + 20.16 CSeq ................................................ 170 + 20.17 Date ................................................ 170 + 20.18 Error-Info .......................................... 171 + 20.19 Expires ............................................. 171 + 20.20 From ................................................ 172 + 20.21 In-Reply-To ......................................... 172 + 20.22 Max-Forwards ........................................ 173 + 20.23 Min-Expires ......................................... 173 + 20.24 MIME-Version ........................................ 173 + 20.25 Organization ........................................ 174 + 20.26 Priority ............................................ 174 + 20.27 Proxy-Authenticate .................................. 174 + 20.28 Proxy-Authorization ................................. 175 + 20.29 Proxy-Require ....................................... 175 + 20.30 Record-Route ........................................ 175 + 20.31 Reply-To ............................................ 176 + 20.32 Require ............................................. 176 + 20.33 Retry-After ......................................... 176 + 20.34 Route ............................................... 177 + + + +Rosenberg, et. al. Standards Track [Page 5] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 20.35 Server .............................................. 177 + 20.36 Subject ............................................. 177 + 20.37 Supported ........................................... 178 + 20.38 Timestamp ........................................... 178 + 20.39 To .................................................. 178 + 20.40 Unsupported ......................................... 179 + 20.41 User-Agent .......................................... 179 + 20.42 Via ................................................. 179 + 20.43 Warning ............................................. 180 + 20.44 WWW-Authenticate .................................... 182 + 21 Response Codes ...................................... 182 + 21.1 Provisional 1xx ..................................... 182 + 21.1.1 100 Trying .......................................... 183 + 21.1.2 180 Ringing ......................................... 183 + 21.1.3 181 Call Is Being Forwarded ......................... 183 + 21.1.4 182 Queued .......................................... 183 + 21.1.5 183 Session Progress ................................ 183 + 21.2 Successful 2xx ...................................... 183 + 21.2.1 200 OK .............................................. 183 + 21.3 Redirection 3xx ..................................... 184 + 21.3.1 300 Multiple Choices ................................ 184 + 21.3.2 301 Moved Permanently ............................... 184 + 21.3.3 302 Moved Temporarily ............................... 184 + 21.3.4 305 Use Proxy ....................................... 185 + 21.3.5 380 Alternative Service ............................. 185 + 21.4 Request Failure 4xx ................................. 185 + 21.4.1 400 Bad Request ..................................... 185 + 21.4.2 401 Unauthorized .................................... 185 + 21.4.3 402 Payment Required ................................ 186 + 21.4.4 403 Forbidden ....................................... 186 + 21.4.5 404 Not Found ....................................... 186 + 21.4.6 405 Method Not Allowed .............................. 186 + 21.4.7 406 Not Acceptable .................................. 186 + 21.4.8 407 Proxy Authentication Required ................... 186 + 21.4.9 408 Request Timeout ................................. 186 + 21.4.10 410 Gone ............................................ 187 + 21.4.11 413 Request Entity Too Large ........................ 187 + 21.4.12 414 Request-URI Too Long ............................ 187 + 21.4.13 415 Unsupported Media Type .......................... 187 + 21.4.14 416 Unsupported URI Scheme .......................... 187 + 21.4.15 420 Bad Extension ................................... 187 + 21.4.16 421 Extension Required .............................. 188 + 21.4.17 423 Interval Too Brief .............................. 188 + 21.4.18 480 Temporarily Unavailable ......................... 188 + 21.4.19 481 Call/Transaction Does Not Exist ................. 188 + 21.4.20 482 Loop Detected ................................... 188 + 21.4.21 483 Too Many Hops ................................... 189 + 21.4.22 484 Address Incomplete .............................. 189 + + + +Rosenberg, et. al. Standards Track [Page 6] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 21.4.23 485 Ambiguous ....................................... 189 + 21.4.24 486 Busy Here ....................................... 189 + 21.4.25 487 Request Terminated .............................. 190 + 21.4.26 488 Not Acceptable Here ............................. 190 + 21.4.27 491 Request Pending ................................. 190 + 21.4.28 493 Undecipherable .................................. 190 + 21.5 Server Failure 5xx .................................. 190 + 21.5.1 500 Server Internal Error ........................... 190 + 21.5.2 501 Not Implemented ................................. 191 + 21.5.3 502 Bad Gateway ..................................... 191 + 21.5.4 503 Service Unavailable ............................. 191 + 21.5.5 504 Server Time-out ................................. 191 + 21.5.6 505 Version Not Supported ........................... 192 + 21.5.7 513 Message Too Large ............................... 192 + 21.6 Global Failures 6xx ................................. 192 + 21.6.1 600 Busy Everywhere ................................. 192 + 21.6.2 603 Decline ......................................... 192 + 21.6.3 604 Does Not Exist Anywhere ......................... 192 + 21.6.4 606 Not Acceptable .................................. 192 + 22 Usage of HTTP Authentication ........................ 193 + 22.1 Framework ........................................... 193 + 22.2 User-to-User Authentication ......................... 195 + 22.3 Proxy-to-User Authentication ........................ 197 + 22.4 The Digest Authentication Scheme .................... 199 + 23 S/MIME .............................................. 201 + 23.1 S/MIME Certificates ................................. 201 + 23.2 S/MIME Key Exchange ................................. 202 + 23.3 Securing MIME bodies ................................ 205 + 23.4 SIP Header Privacy and Integrity using S/MIME: + Tunneling SIP ....................................... 207 + 23.4.1 Integrity and Confidentiality Properties of SIP + Headers ............................................. 207 + 23.4.1.1 Integrity ........................................... 207 + 23.4.1.2 Confidentiality ..................................... 208 + 23.4.2 Tunneling Integrity and Authentication .............. 209 + 23.4.3 Tunneling Encryption ................................ 211 + 24 Examples ............................................ 213 + 24.1 Registration ........................................ 213 + 24.2 Session Setup ....................................... 214 + 25 Augmented BNF for the SIP Protocol .................. 219 + 25.1 Basic Rules ......................................... 219 + 26 Security Considerations: Threat Model and Security + Usage Recommendations ............................... 232 + 26.1 Attacks and Threat Models ........................... 233 + 26.1.1 Registration Hijacking .............................. 233 + 26.1.2 Impersonating a Server .............................. 234 + 26.1.3 Tampering with Message Bodies ....................... 235 + 26.1.4 Tearing Down Sessions ............................... 235 + + + +Rosenberg, et. al. Standards Track [Page 7] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 26.1.5 Denial of Service and Amplification ................. 236 + 26.2 Security Mechanisms ................................. 237 + 26.2.1 Transport and Network Layer Security ................ 238 + 26.2.2 SIPS URI Scheme ..................................... 239 + 26.2.3 HTTP Authentication ................................. 240 + 26.2.4 S/MIME .............................................. 240 + 26.3 Implementing Security Mechanisms .................... 241 + 26.3.1 Requirements for Implementers of SIP ................ 241 + 26.3.2 Security Solutions .................................. 242 + 26.3.2.1 Registration ........................................ 242 + 26.3.2.2 Interdomain Requests ................................ 243 + 26.3.2.3 Peer-to-Peer Requests ............................... 245 + 26.3.2.4 DoS Protection ...................................... 246 + 26.4 Limitations ......................................... 247 + 26.4.1 HTTP Digest ......................................... 247 + 26.4.2 S/MIME .............................................. 248 + 26.4.3 TLS ................................................. 249 + 26.4.4 SIPS URIs ........................................... 249 + 26.5 Privacy ............................................. 251 + 27 IANA Considerations ................................. 252 + 27.1 Option Tags ......................................... 252 + 27.2 Warn-Codes .......................................... 252 + 27.3 Header Field Names .................................. 253 + 27.4 Method and Response Codes ........................... 253 + 27.5 The "message/sip" MIME type. ....................... 254 + 27.6 New Content-Disposition Parameter Registrations ..... 255 + 28 Changes From RFC 2543 ............................... 255 + 28.1 Major Functional Changes ............................ 255 + 28.2 Minor Functional Changes ............................ 260 + 29 Normative References ................................ 261 + 30 Informative References .............................. 262 + A Table of Timer Values ............................... 265 + Acknowledgments ................................................ 266 + Authors' Addresses ............................................. 267 + Full Copyright Statement ....................................... 269 + +1 Introduction + + There are many applications of the Internet that require the creation + and management of a session, where a session is considered an + exchange of data between an association of participants. The + implementation of these applications is complicated by the practices + of participants: users may move between endpoints, they may be + addressable by multiple names, and they may communicate in several + different media - sometimes simultaneously. Numerous protocols have + been authored that carry various forms of real-time multimedia + session data such as voice, video, or text messages. The Session + Initiation Protocol (SIP) works in concert with these protocols by + + + +Rosenberg, et. al. Standards Track [Page 8] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + enabling Internet endpoints (called user agents) to discover one + another and to agree on a characterization of a session they would + like to share. For locating prospective session participants, and + for other functions, SIP enables the creation of an infrastructure of + network hosts (called proxy servers) to which user agents can send + registrations, invitations to sessions, and other requests. SIP is + an agile, general-purpose tool for creating, modifying, and + terminating sessions that works independently of underlying transport + protocols and without dependency on the type of session that is being + established. + +2 Overview of SIP Functionality + + SIP is an application-layer control protocol that can establish, + modify, and terminate multimedia sessions (conferences) such as + Internet telephony calls. SIP can also invite participants to + already existing sessions, such as multicast conferences. Media can + be added to (and removed from) an existing session. SIP + transparently supports name mapping and redirection services, which + supports personal mobility [27] - users can maintain a single + externally visible identifier regardless of their network location. + + SIP supports five facets of establishing and terminating multimedia + communications: + + User location: determination of the end system to be used for + communication; + + User availability: determination of the willingness of the called + party to engage in communications; + + User capabilities: determination of the media and media parameters + to be used; + + Session setup: "ringing", establishment of session parameters at + both called and calling party; + + Session management: including transfer and termination of + sessions, modifying session parameters, and invoking + services. + + SIP is not a vertically integrated communications system. SIP is + rather a component that can be used with other IETF protocols to + build a complete multimedia architecture. Typically, these + architectures will include protocols such as the Real-time Transport + Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and + providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC + 2326 [29]) for controlling delivery of streaming media, the Media + + + +Rosenberg, et. al. Standards Track [Page 9] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling + gateways to the Public Switched Telephone Network (PSTN), and the + Session Description Protocol (SDP) (RFC 2327 [1]) for describing + multimedia sessions. Therefore, SIP should be used in conjunction + with other protocols in order to provide complete services to the + users. However, the basic functionality and operation of SIP does + not depend on any of these protocols. + + SIP does not provide services. Rather, SIP provides primitives that + can be used to implement different services. For example, SIP can + locate a user and deliver an opaque object to his current location. + If this primitive is used to deliver a session description written in + SDP, for instance, the endpoints can agree on the parameters of a + session. If the same primitive is used to deliver a photo of the + caller as well as the session description, a "caller ID" service can + be easily implemented. As this example shows, a single primitive is + typically used to provide several different services. + + SIP does not offer conference control services such as floor control + or voting and does not prescribe how a conference is to be managed. + SIP can be used to initiate a session that uses some other conference + control protocol. Since SIP messages and the sessions they establish + can pass through entirely different networks, SIP cannot, and does + not, provide any kind of network resource reservation capabilities. + + The nature of the services provided make security particularly + important. To that end, SIP provides a suite of security services, + which include denial-of-service prevention, authentication (both user + to user and proxy to user), integrity protection, and encryption and + privacy services. + + SIP works with both IPv4 and IPv6. + +3 Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as + described in BCP 14, RFC 2119 [2] and indicate requirement levels for + compliant SIP implementations. + +4 Overview of Operation + + This section introduces the basic operations of SIP using simple + examples. This section is tutorial in nature and does not contain + any normative statements. + + + + + +Rosenberg, et. al. Standards Track [Page 10] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The first example shows the basic functions of SIP: location of an + end point, signal of a desire to communicate, negotiation of session + parameters to establish the session, and teardown of the session once + established. + + Figure 1 shows a typical example of a SIP message exchange between + two users, Alice and Bob. (Each message is labeled with the letter + "F" and a number for reference by the text.) In this example, Alice + uses a SIP application on her PC (referred to as a softphone) to call + Bob on his SIP phone over the Internet. Also shown are two SIP proxy + servers that act on behalf of Alice and Bob to facilitate the session + establishment. This typical arrangement is often referred to as the + "SIP trapezoid" as shown by the geometric shape of the dotted lines + in Figure 1. + + Alice "calls" Bob using his SIP identity, a type of Uniform Resource + Identifier (URI) called a SIP URI. SIP URIs are defined in Section + 19.1. It has a similar form to an email address, typically + containing a username and a host name. In this case, it is + sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP + service provider. Alice has a SIP URI of sip:alice@atlanta.com. + Alice might have typed in Bob's URI or perhaps clicked on a hyperlink + or an entry in an address book. SIP also provides a secure URI, + called a SIPS URI. An example would be sips:bob@biloxi.com. A call + made to a SIPS URI guarantees that secure, encrypted transport + (namely TLS) is used to carry all SIP messages from the caller to the + domain of the callee. From there, the request is sent securely to + the callee, but with security mechanisms that depend on the policy of + the domain of the callee. + + SIP is based on an HTTP-like request/response transaction model. + Each transaction consists of a request that invokes a particular + method, or function, on the server and at least one response. In + this example, the transaction begins with Alice's softphone sending + an INVITE request addressed to Bob's SIP URI. INVITE is an example + of a SIP method that specifies the action that the requestor (Alice) + wants the server (Bob) to take. The INVITE request contains a number + of header fields. Header fields are named attributes that provide + additional information about a message. The ones present in an + INVITE include a unique identifier for the call, the destination + address, Alice's address, and information about the type of session + that Alice wishes to establish with Bob. The INVITE (message F1 in + Figure 1) might look like this: + + + + + + + + +Rosenberg, et. al. Standards Track [Page 11] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + atlanta.com . . . biloxi.com + . proxy proxy . + . . + Alice's . . . . . . . . . . . . . . . . . . . . Bob's + softphone SIP Phone + | | | | + | INVITE F1 | | | + |--------------->| INVITE F2 | | + | 100 Trying F3 |--------------->| INVITE F4 | + |<---------------| 100 Trying F5 |--------------->| + | |<-------------- | 180 Ringing F6 | + | | 180 Ringing F7 |<---------------| + | 180 Ringing F8 |<---------------| 200 OK F9 | + |<---------------| 200 OK F10 |<---------------| + | 200 OK F11 |<---------------| | + |<---------------| | | + | ACK F12 | + |------------------------------------------------->| + | Media Session | + |<================================================>| + | BYE F13 | + |<-------------------------------------------------| + | 200 OK F14 | + |------------------------------------------------->| + | | + + Figure 1: SIP session setup example with SIP trapezoid + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds + Max-Forwards: 70 + To: Bob <sip:bob@biloxi.com> + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.atlanta.com + CSeq: 314159 INVITE + Contact: <sip:alice@pc33.atlanta.com> + Content-Type: application/sdp + Content-Length: 142 + + (Alice's SDP not shown) + + The first line of the text-encoded message contains the method name + (INVITE). The lines that follow are a list of header fields. This + example contains a minimum required set. The header fields are + briefly described below: + + + + + + +Rosenberg, et. al. Standards Track [Page 12] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Via contains the address (pc33.atlanta.com) at which Alice is + expecting to receive responses to this request. It also contains a + branch parameter that identifies this transaction. + + To contains a display name (Bob) and a SIP or SIPS URI + (sip:bob@biloxi.com) towards which the request was originally + directed. Display names are described in RFC 2822 [3]. + + From also contains a display name (Alice) and a SIP or SIPS URI + (sip:alice@atlanta.com) that indicate the originator of the request. + This header field also has a tag parameter containing a random string + (1928301774) that was added to the URI by the softphone. It is used + for identification purposes. + + Call-ID contains a globally unique identifier for this call, + generated by the combination of a random string and the softphone's + host name or IP address. The combination of the To tag, From tag, + and Call-ID completely defines a peer-to-peer SIP relationship + between Alice and Bob and is referred to as a dialog. + + CSeq or Command Sequence contains an integer and a method name. The + CSeq number is incremented for each new request within a dialog and + is a traditional sequence number. + + Contact contains a SIP or SIPS URI that represents a direct route to + contact Alice, usually composed of a username at a fully qualified + domain name (FQDN). While an FQDN is preferred, many end systems do + not have registered domain names, so IP addresses are permitted. + While the Via header field tells other elements where to send the + response, the Contact header field tells other elements where to send + future requests. + + Max-Forwards serves to limit the number of hops a request can make on + the way to its destination. It consists of an integer that is + decremented by one at each hop. + + Content-Type contains a description of the message body (not shown). + + Content-Length contains an octet (byte) count of the message body. + + The complete set of SIP header fields is defined in Section 20. + + The details of the session, such as the type of media, codec, or + sampling rate, are not described using SIP. Rather, the body of a + SIP message contains a description of the session, encoded in some + other protocol format. One such format is the Session Description + Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the + + + + +Rosenberg, et. al. Standards Track [Page 13] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + example) is carried by the SIP message in a way that is analogous to + a document attachment being carried by an email message, or a web + page being carried in an HTTP message. + + Since the softphone does not know the location of Bob or the SIP + server in the biloxi.com domain, the softphone sends the INVITE to + the SIP server that serves Alice's domain, atlanta.com. The address + of the atlanta.com SIP server could have been configured in Alice's + softphone, or it could have been discovered by DHCP, for example. + + The atlanta.com SIP server is a type of SIP server known as a proxy + server. A proxy server receives SIP requests and forwards them on + behalf of the requestor. In this example, the proxy server receives + the INVITE request and sends a 100 (Trying) response back to Alice's + softphone. The 100 (Trying) response indicates that the INVITE has + been received and that the proxy is working on her behalf to route + the INVITE to the destination. Responses in SIP use a three-digit + code followed by a descriptive phrase. This response contains the + same To, From, Call-ID, CSeq and branch parameter in the Via as the + INVITE, which allows Alice's softphone to correlate this response to + the sent INVITE. The atlanta.com proxy server locates the proxy + server at biloxi.com, possibly by performing a particular type of DNS + (Domain Name Service) lookup to find the SIP server that serves the + biloxi.com domain. This is described in [4]. As a result, it + obtains the IP address of the biloxi.com proxy server and forwards, + or proxies, the INVITE request there. Before forwarding the request, + the atlanta.com proxy server adds an additional Via header field + value that contains its own address (the INVITE already contains + Alice's address in the first Via). The biloxi.com proxy server + receives the INVITE and responds with a 100 (Trying) response back to + the atlanta.com proxy server to indicate that it has received the + INVITE and is processing the request. The proxy server consults a + database, generically called a location service, that contains the + current IP address of Bob. (We shall see in the next section how + this database can be populated.) The biloxi.com proxy server adds + another Via header field value with its own address to the INVITE and + proxies it to Bob's SIP phone. + + Bob's SIP phone receives the INVITE and alerts Bob to the incoming + call from Alice so that Bob can decide whether to answer the call, + that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 + (Ringing) response, which is routed back through the two proxies in + the reverse direction. Each proxy uses the Via header field to + determine where to send the response and removes its own address from + the top. As a result, although DNS and location service lookups were + required to route the initial INVITE, the 180 (Ringing) response can + be returned to the caller without lookups or without state being + + + + +Rosenberg, et. al. Standards Track [Page 14] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + maintained in the proxies. This also has the desirable property that + each proxy that sees the INVITE will also see all responses to the + INVITE. + + When Alice's softphone receives the 180 (Ringing) response, it passes + this information to Alice, perhaps using an audio ringback tone or by + displaying a message on Alice's screen. + + In this example, Bob decides to answer the call. When he picks up + the handset, his SIP phone sends a 200 (OK) response to indicate that + the call has been answered. The 200 (OK) contains a message body + with the SDP media description of the type of session that Bob is + willing to establish with Alice. As a result, there is a two-phase + exchange of SDP messages: Alice sent one to Bob, and Bob sent one + back to Alice. This two-phase exchange provides basic negotiation + capabilities and is based on a simple offer/answer model of SDP + exchange. If Bob did not wish to answer the call or was busy on + another call, an error response would have been sent instead of the + 200 (OK), which would have resulted in no media session being + established. The complete list of SIP response codes is in Section + 21. The 200 (OK) (message F9 in Figure 1) might look like this as + Bob sends it out: + + SIP/2.0 200 OK + Via: SIP/2.0/UDP server10.biloxi.com + ;branch=z9hG4bKnashds8;received=192.0.2.3 + Via: SIP/2.0/UDP bigbox3.site3.atlanta.com + ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 + Via: SIP/2.0/UDP pc33.atlanta.com + ;branch=z9hG4bK776asdhds ;received=192.0.2.1 + To: Bob <sip:bob@biloxi.com>;tag=a6c85cf + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.atlanta.com + CSeq: 314159 INVITE + Contact: <sip:bob@192.0.2.4> + Content-Type: application/sdp + Content-Length: 131 + + (Bob's SDP not shown) + + The first line of the response contains the response code (200) and + the reason phrase (OK). The remaining lines contain header fields. + The Via, To, From, Call-ID, and CSeq header fields are copied from + the INVITE request. (There are three Via header field values - one + added by Alice's SIP phone, one added by the atlanta.com proxy, and + one added by the biloxi.com proxy.) Bob's SIP phone has added a tag + parameter to the To header field. This tag will be incorporated by + both endpoints into the dialog and will be included in all future + + + +Rosenberg, et. al. Standards Track [Page 15] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + requests and responses in this call. The Contact header field + contains a URI at which Bob can be directly reached at his SIP phone. + The Content-Type and Content-Length refer to the message body (not + shown) that contains Bob's SDP media information. + + In addition to DNS and location service lookups shown in this + example, proxy servers can make flexible "routing decisions" to + decide where to send a request. For example, if Bob's SIP phone + returned a 486 (Busy Here) response, the biloxi.com proxy server + could proxy the INVITE to Bob's voicemail server. A proxy server can + also send an INVITE to a number of locations at the same time. This + type of parallel search is known as forking. + + In this case, the 200 (OK) is routed back through the two proxies and + is received by Alice's softphone, which then stops the ringback tone + and indicates that the call has been answered. Finally, Alice's + softphone sends an acknowledgement message, ACK, to Bob's SIP phone + to confirm the reception of the final response (200 (OK)). In this + example, the ACK is sent directly from Alice's softphone to Bob's SIP + phone, bypassing the two proxies. This occurs because the endpoints + have learned each other's address from the Contact header fields + through the INVITE/200 (OK) exchange, which was not known when the + initial INVITE was sent. The lookups performed by the two proxies + are no longer needed, so the proxies drop out of the call flow. This + completes the INVITE/200/ACK three-way handshake used to establish + SIP sessions. Full details on session setup are in Section 13. + + Alice and Bob's media session has now begun, and they send media + packets using the format to which they agreed in the exchange of SDP. + In general, the end-to-end media packets take a different path from + the SIP signaling messages. + + During the session, either Alice or Bob may decide to change the + characteristics of the media session. This is accomplished by + sending a re-INVITE containing a new media description. This re- + INVITE references the existing dialog so that the other party knows + that it is to modify an existing session instead of establishing a + new session. The other party sends a 200 (OK) to accept the change. + The requestor responds to the 200 (OK) with an ACK. If the other + party does not accept the change, he sends an error response such as + 488 (Not Acceptable Here), which also receives an ACK. However, the + failure of the re-INVITE does not cause the existing call to fail - + the session continues using the previously negotiated + characteristics. Full details on session modification are in Section + 14. + + + + + + +Rosenberg, et. al. Standards Track [Page 16] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + At the end of the call, Bob disconnects (hangs up) first and + generates a BYE message. This BYE is routed directly to Alice's + softphone, again bypassing the proxies. Alice confirms receipt of + the BYE with a 200 (OK) response, which terminates the session and + the BYE transaction. No ACK is sent - an ACK is only sent in + response to a response to an INVITE request. The reasons for this + special handling for INVITE will be discussed later, but relate to + the reliability mechanisms in SIP, the length of time it can take for + a ringing phone to be answered, and forking. For this reason, + request handling in SIP is often classified as either INVITE or non- + INVITE, referring to all other methods besides INVITE. Full details + on session termination are in Section 15. + + Section 24.2 describes the messages shown in Figure 1 in full. + + In some cases, it may be useful for proxies in the SIP signaling path + to see all the messaging between the endpoints for the duration of + the session. For example, if the biloxi.com proxy server wished to + remain in the SIP messaging path beyond the initial INVITE, it would + add to the INVITE a required routing header field known as Record- + Route that contained a URI resolving to the hostname or IP address of + the proxy. This information would be received by both Bob's SIP + phone and (due to the Record-Route header field being passed back in + the 200 (OK)) Alice's softphone and stored for the duration of the + dialog. The biloxi.com proxy server would then receive and proxy the + ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently + decide to receive subsequent messages, and those messages will pass + through all proxies that elect to receive it. This capability is + frequently used for proxies that are providing mid-call features. + + Registration is another common operation in SIP. Registration is one + way that the biloxi.com server can learn the current location of Bob. + Upon initialization, and at periodic intervals, Bob's SIP phone sends + REGISTER messages to a server in the biloxi.com domain known as a SIP + registrar. The REGISTER messages associate Bob's SIP or SIPS URI + (sip:bob@biloxi.com) with the machine into which he is currently + logged (conveyed as a SIP or SIPS URI in the Contact header field). + The registrar writes this association, also called a binding, to a + database, called the location service, where it can be used by the + proxy in the biloxi.com domain. Often, a registrar server for a + domain is co-located with the proxy for that domain. It is an + important concept that the distinction between types of SIP servers + is logical, not physical. + + Bob is not limited to registering from a single device. For example, + both his SIP phone at home and the one in the office could send + registrations. This information is stored together in the location + + + + +Rosenberg, et. al. Standards Track [Page 17] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + service and allows a proxy to perform various types of searches to + locate Bob. Similarly, more than one user can be registered on a + single device at the same time. + + The location service is just an abstract concept. It generally + contains information that allows a proxy to input a URI and receive a + set of zero or more URIs that tell the proxy where to send the + request. Registrations are one way to create this information, but + not the only way. Arbitrary mapping functions can be configured at + the discretion of the administrator. + + Finally, it is important to note that in SIP, registration is used + for routing incoming SIP requests and has no role in authorizing + outgoing requests. Authorization and authentication are handled in + SIP either on a request-by-request basis with a challenge/response + mechanism, or by using a lower layer scheme as discussed in Section + 26. + + The complete set of SIP message details for this registration example + is in Section 24.1. + + Additional operations in SIP, such as querying for the capabilities + of a SIP server or client using OPTIONS, or canceling a pending + request using CANCEL, will be introduced in later sections. + +5 Structure of the Protocol + + SIP is structured as a layered protocol, which means that its + behavior is described in terms of a set of fairly independent + processing stages with only a loose coupling between each stage. The + protocol behavior is described as layers for the purpose of + presentation, allowing the description of functions common across + elements in a single section. It does not dictate an implementation + in any way. When we say that an element "contains" a layer, we mean + it is compliant to the set of rules defined by that layer. + + Not every element specified by the protocol contains every layer. + Furthermore, the elements specified by SIP are logical elements, not + physical ones. A physical realization can choose to act as different + logical elements, perhaps even on a transaction-by-transaction basis. + + The lowest layer of SIP is its syntax and encoding. Its encoding is + specified using an augmented Backus-Naur Form grammar (BNF). The + complete BNF is specified in Section 25; an overview of a SIP + message's structure can be found in Section 7. + + + + + + +Rosenberg, et. al. Standards Track [Page 18] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The second layer is the transport layer. It defines how a client + sends requests and receives responses and how a server receives + requests and sends responses over the network. All SIP elements + contain a transport layer. The transport layer is described in + Section 18. + + The third layer is the transaction layer. Transactions are a + fundamental component of SIP. A transaction is a request sent by a + client transaction (using the transport layer) to a server + transaction, along with all responses to that request sent from the + server transaction back to the client. The transaction layer handles + application-layer retransmissions, matching of responses to requests, + and application-layer timeouts. Any task that a user agent client + (UAC) accomplishes takes place using a series of transactions. + Discussion of transactions can be found in Section 17. User agents + contain a transaction layer, as do stateful proxies. Stateless + proxies do not contain a transaction layer. The transaction layer + has a client component (referred to as a client transaction) and a + server component (referred to as a server transaction), each of which + are represented by a finite state machine that is constructed to + process a particular request. + + The layer above the transaction layer is called the transaction user + (TU). Each of the SIP entities, except the stateless proxy, is a + transaction user. When a TU wishes to send a request, it creates a + client transaction instance and passes it the request along with the + destination IP address, port, and transport to which to send the + request. A TU that creates a client transaction can also cancel it. + When a client cancels a transaction, it requests that the server stop + further processing, revert to the state that existed before the + transaction was initiated, and generate a specific error response to + that transaction. This is done with a CANCEL request, which + constitutes its own transaction, but references the transaction to be + cancelled (Section 9). + + The SIP elements, that is, user agent clients and servers, stateless + and stateful proxies and registrars, contain a core that + distinguishes them from each other. Cores, except for the stateless + proxy, are transaction users. While the behavior of the UAC and UAS + cores depends on the method, there are some common rules for all + methods (Section 8). For a UAC, these rules govern the construction + of a request; for a UAS, they govern the processing of a request and + generating a response. Since registrations play an important role in + SIP, a UAS that handles a REGISTER is given the special name + registrar. Section 10 describes UAC and UAS core behavior for the + REGISTER method. Section 11 describes UAC and UAS core behavior for + the OPTIONS method, used for determining the capabilities of a UA. + + + + +Rosenberg, et. al. Standards Track [Page 19] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Certain other requests are sent within a dialog. A dialog is a + peer-to-peer SIP relationship between two user agents that persists + for some time. The dialog facilitates sequencing of messages and + proper routing of requests between the user agents. The INVITE + method is the only way defined in this specification to establish a + dialog. When a UAC sends a request that is within the context of a + dialog, it follows the common UAC rules as discussed in Section 8 but + also the rules for mid-dialog requests. Section 12 discusses dialogs + and presents the procedures for their construction and maintenance, + in addition to construction of requests within a dialog. + + The most important method in SIP is the INVITE method, which is used + to establish a session between participants. A session is a + collection of participants, and streams of media between them, for + the purposes of communication. Section 13 discusses how sessions are + initiated, resulting in one or more SIP dialogs. Section 14 + discusses how characteristics of that session are modified through + the use of an INVITE request within a dialog. Finally, section 15 + discusses how a session is terminated. + + The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal + entirely with the UA core (Section 9 describes cancellation, which + applies to both UA core and proxy core). Section 16 discusses the + proxy element, which facilitates routing of messages between user + agents. + +6 Definitions + + The following terms have special significance for SIP. + + Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI + that points to a domain with a location service that can map + the URI to another URI where the user might be available. + Typically, the location service is populated through + registrations. An AOR is frequently thought of as the "public + address" of the user. + + Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a + logical entity that receives a request and processes it as a + user agent server (UAS). In order to determine how the request + should be answered, it acts as a user agent client (UAC) and + generates requests. Unlike a proxy server, it maintains dialog + state and must participate in all requests sent on the dialogs + it has established. Since it is a concatenation of a UAC and + UAS, no explicit definitions are needed for its behavior. + + + + + + +Rosenberg, et. al. Standards Track [Page 20] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Call: A call is an informal term that refers to some communication + between peers, generally set up for the purposes of a + multimedia conversation. + + Call Leg: Another name for a dialog [31]; no longer used in this + specification. + + Call Stateful: A proxy is call stateful if it retains state for a + dialog from the initiating INVITE to the terminating BYE + request. A call stateful proxy is always transaction stateful, + but the converse is not necessarily true. + + Client: A client is any network element that sends SIP requests + and receives SIP responses. Clients may or may not interact + directly with a human user. User agent clients and proxies are + clients. + + Conference: A multimedia session (see below) that contains + multiple participants. + + Core: Core designates the functions specific to a particular type + of SIP entity, i.e., specific to either a stateful or stateless + proxy, a user agent or registrar. All cores, except those for + the stateless proxy, are transaction users. + + Dialog: A dialog is a peer-to-peer SIP relationship between two + UAs that persists for some time. A dialog is established by + SIP messages, such as a 2xx response to an INVITE request. A + dialog is identified by a call identifier, local tag, and a + remote tag. A dialog was formerly known as a call leg in RFC + 2543. + + Downstream: A direction of message forwarding within a transaction + that refers to the direction that requests flow from the 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. + + Header: A header is a component of a SIP message that conveys + information about the message. It is structured as a sequence + of header fields. + + Header Field: A header field is a component of the SIP message + header. A header field can appear as one or more header field + rows. Header field rows consist of a header field name and zero + or more header field values. Multiple header field values on a + + + +Rosenberg, et. al. Standards Track [Page 21] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + given header field row are separated by commas. Some header + fields can only have a single header field value, and as a + result, always appear as a single header field row. + + Header Field Value: A header field value is a single value; a + header field consists of zero or more header field values. + + Home Domain: The domain providing service to a SIP user. + Typically, this is the domain present in the URI in the + address-of-record of a registration. + + Informational Response: Same as a provisional response. + + Initiator, Calling Party, Caller: The party initiating a session + (and dialog) with an INVITE request. A caller retains this + role from the time it sends the initial INVITE that established + a dialog until the termination of that dialog. + + Invitation: An INVITE request. + + Invitee, Invited User, Called Party, Callee: The party that + receives an INVITE request for the purpose of establishing a + new session. A callee retains this role from the time it + receives the INVITE until the termination of the dialog + established by that INVITE. + + Location Service: A location service is used by a SIP redirect or + proxy server to obtain information about a callee's possible + location(s). It contains a list of bindings of address-of- + record keys to zero or more contact addresses. The bindings + can be created and removed in many ways; this specification + defines a REGISTER method that updates the bindings. + + Loop: A request that arrives at a proxy, is forwarded, and later + arrives back at the same proxy. When it arrives the second + time, its Request-URI is identical to the first time, and other + header fields that affect proxy operation are unchanged, so + that the proxy would make the same processing decision on the + request it made the first time. Looped requests are errors, + and the procedures for detecting them and handling them are + described by the protocol. + + Loose Routing: A proxy is said to be loose routing if it follows + the procedures defined in this specification for processing of + the Route header field. These procedures separate the + destination of the request (present in the Request-URI) from + + + + + +Rosenberg, et. al. Standards Track [Page 22] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + the set of proxies that need to be visited along the way + (present in the Route header field). A proxy compliant to + these mechanisms is also known as a loose router. + + Message: Data sent between SIP elements as part of the protocol. + SIP messages are either requests or responses. + + Method: The method is the primary function that a request is meant + to invoke on a server. The method is carried in the request + message itself. Example methods are INVITE and BYE. + + Outbound Proxy: A proxy that receives requests from a client, even + though it may not be the server resolved by the Request-URI. + Typically, a UA is manually configured with an outbound proxy, + or can learn about one through auto-configuration protocols. + + 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 entity that acts as both a + server and a client for the purpose of making requests on + behalf of other clients. A proxy server primarily plays the + role of routing, which means its job is to ensure that a + request is sent to another entity "closer" to the targeted + user. Proxies are also useful for enforcing policy (for + example, making sure a user is allowed to make a call). A + proxy interprets, and, if necessary, rewrites specific parts of + a request message before forwarding it. + + Recursion: A client recurses on a 3xx response when it generates a + new request to one or more of the URIs in the Contact header + field in the response. + + Redirect Server: A redirect server is a user agent server that + generates 3xx responses to requests it receives, directing the + client to contact an alternate set of URIs. + + + + + + +Rosenberg, et. al. Standards Track [Page 23] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Registrar: A registrar is a server that accepts REGISTER requests + and places the information it receives in those requests into + the location service for the domain it handles. + + Regular Transaction: A regular transaction is any transaction with + a method other than INVITE, ACK, or CANCEL. + + Request: A SIP message sent from a client to a server, for the + purpose of invoking a particular operation. + + Response: A SIP message sent from a server to a client, for + indicating the status of a request sent from the client to the + server. + + Ringback: Ringback is the signaling tone produced by the calling + party's application indicating that a called party is being + alerted (ringing). + + Route Set: A route set is a collection of ordered SIP or SIPS URI + which represent a list of proxies that must be traversed when + sending a particular request. A route set can be learned, + through headers like Record-Route, or it can be configured. + + Server: A server is a network element that receives requests in + order to service them and sends back responses to those + requests. Examples of servers are proxies, user agent servers, + redirect servers, and registrars. + + Sequential Search: In a sequential search, a proxy server attempts + each contact address in sequence, proceeding to the next one + only after the previous has generated a final response. A 2xx + or 6xx class final response always terminates a sequential + search. + + 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 [1]) (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 SDP 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 + + + +Rosenberg, et. al. Standards Track [Page 24] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + sent from the server to the client. If the request is INVITE + and the final response is a non-2xx, the transaction also + includes an ACK to the response. The ACK for a 2xx response to + an INVITE request is a separate transaction. + + Spiral: A spiral is a SIP request that is routed to a proxy, + forwarded onwards, and arrives once again at that proxy, but + this time differs in a way that will result in a different + processing decision than the original request. Typically, this + means that the request's Request-URI differs from its previous + arrival. A spiral is not an error condition, unlike a loop. A + typical cause for this is call forwarding. A user calls + joe@example.com. The example.com proxy forwards it to Joe's + PC, which in turn, forwards it to bob@example.com. This + request is proxied back to the example.com proxy. However, + this is not a loop. Since the request is targeted at a + different user, it is considered a spiral, and is a valid + condition. + + Stateful Proxy: A logical entity that maintains the client and + server transaction state machines defined by this specification + during the processing of a request, also known as a transaction + stateful proxy. The behavior of a stateful proxy is further + defined in Section 16. A (transaction) stateful proxy is not + the same as a call stateful proxy. + + Stateless Proxy: A logical entity that does not maintain the + client or server transaction state machines defined in this + specification when it processes requests. A stateless proxy + forwards every request it receives downstream and every + response it receives upstream. + + Strict Routing: A proxy is said to be strict routing if it follows + the Route processing rules of RFC 2543 and many prior work in + progress versions of this RFC. That rule caused proxies to + destroy the contents of the Request-URI when a Route header + field was present. Strict routing behavior is not used in this + specification, in favor of a loose routing behavior. Proxies + that perform strict routing are also known as strict routers. + + Target Refresh Request: A target refresh request sent within a + dialog is defined as a request that can modify the remote + target of the dialog. + + Transaction User (TU): The layer of protocol processing that + resides above the transaction layer. Transaction users include + the UAC core, UAS core, and proxy core. + + + + +Rosenberg, et. al. Standards Track [Page 25] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Upstream: A direction of message forwarding within a transaction + that refers to the direction that responses flow from the user + agent server back to the user agent client. + + URL-encoded: A character string encoded according to RFC 2396, + Section 2.4 [5]. + + User Agent Client (UAC): A user agent client is a logical entity + that creates a new request, and then uses the client + transaction state machinery to send it. The role of UAC lasts + only for the duration of that transaction. In other words, if + a piece of software initiates a request, it acts as a UAC for + the duration of that transaction. If it receives a request + later, it assumes the role of a user agent server for the + processing of that transaction. + + UAC Core: The set of processing functions required of a UAC that + reside above the transaction and transport layers. + + User Agent Server (UAS): A user agent server is a logical entity + that generates a response to a SIP request. The response + accepts, rejects, or redirects the request. This role lasts + only for the duration of that transaction. In other words, if + a piece of software responds to a request, it acts as a UAS for + the duration of that transaction. If it generates a request + later, it assumes the role of a user agent client for the + processing of that transaction. + + UAS Core: The set of processing functions required at a UAS that + resides above the transaction and transport layers. + + User Agent (UA): A logical entity that can act as both a user + agent client and user agent server. + + The role of UAC and UAS, as well as proxy and redirect servers, are + defined on a transaction-by-transaction basis. For example, the user + agent initiating a call acts as a UAC when sending the initial INVITE + request and as a UAS when receiving a BYE request from the callee. + Similarly, the same software can act as a proxy server for one + request and as a redirect server for the next request. + + Proxy, location, and registrar servers defined above are logical + entities; implementations MAY combine them into a single application. + +7 SIP Messages + + SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 + [7]). + + + +Rosenberg, et. al. Standards Track [Page 26] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + A SIP message is either a request from a client to a server, or a + response from a server to a client. + + Both Request (section 7.1) and Response (section 7.2) messages use + the basic format of RFC 2822 [3], even though the syntax differs in + character set and syntax specifics. (SIP allows header fields that + would not be valid RFC 2822 header fields, for example.) Both types + of messages consist of a start-line, one or more header fields, an + empty line indicating the end of the header fields, and an optional + message-body. + + generic-message = start-line + *message-header + CRLF + [ message-body ] + start-line = Request-Line / Status-Line + + The start-line, each message-header line, and the empty line MUST be + terminated by a carriage-return line-feed sequence (CRLF). Note that + the empty line MUST be present even if the message-body is not. + + Except for the above difference in character sets, much of SIP's + message and header field syntax is 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 2616 [8]). + + However, SIP is not an extension of HTTP. + +7.1 Requests + + SIP requests are distinguished by having a Request-Line for a start- + line. A Request-Line contains a method name, a Request-URI, and the + protocol version separated by a single space (SP) character. + + The Request-Line ends with CRLF. No CR or LF are allowed except in + the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed + in any of the elements. + + Request-Line = Method SP Request-URI SP SIP-Version CRLF + + Method: This specification defines six methods: REGISTER for + registering contact information, INVITE, ACK, and CANCEL for + setting up sessions, BYE for terminating sessions, and + OPTIONS for querying servers about their capabilities. SIP + extensions, documented in standards track RFCs, may define + additional methods. + + + + + +Rosenberg, et. al. Standards Track [Page 27] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Request-URI: The Request-URI is a SIP or SIPS URI as described in + Section 19.1 or a general URI (RFC 2396 [5]). It indicates + the user or service to which this request is being addressed. + The Request-URI MUST NOT contain unescaped spaces or control + characters and MUST NOT be enclosed in "<>". + + SIP elements MAY support Request-URIs with schemes other than + "sip" and "sips", for example the "tel" URI scheme of RFC + 2806 [9]. SIP elements MAY translate non-SIP URIs using any + mechanism at their disposal, resulting in SIP URI, SIPS URI, + or some other scheme. + + 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". The SIP-Version string is case-insensitive, + but implementations MUST send upper-case. + + Unlike HTTP/1.1, SIP treats the version number as a literal + string. In practice, this should make no difference. + +7.2 Responses + + SIP responses are distinguished from requests by having a Status-Line + as their start-line. A Status-Line consists of the protocol version + followed by a numeric Status-Code and its associated textual phrase, + with each element separated by a single SP character. + + No CR or LF is allowed except in the final CRLF sequence. + + Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF + + The Status-Code is a 3-digit integer result code that indicates the + outcome of an attempt to understand and satisfy a 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. A client + is not required to examine or display the Reason-Phrase. + + While this specification suggests specific wording for the reason + phrase, implementations MAY choose other text, for example, in the + language indicated in the Accept-Language header field of the + request. + + + + + +Rosenberg, et. al. Standards Track [Page 28] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The first digit of the Status-Code defines the class of response. + The last two digits do not have any categorization role. For this + reason, any response with a status code between 100 and 199 is + referred to as a "1xx response", any response with a status code + between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows + six values for the first digit: + + 1xx: Provisional -- 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. + + Section 21 defines these classes and describes the individual codes. + +7.3 Header Fields + + SIP header fields are similar to HTTP header fields in both syntax + and semantics. In particular, SIP header fields follow the [H4.2] + definitions of syntax for the message-header and the rules for + extending header fields over multiple lines. However, the latter is + specified in HTTP with implicit whitespace and folding. This + specification conforms to RFC 2234 [10] and uses only explicit + whitespace and folding as an integral part of the grammar. + + [H4.2] also specifies that multiple header fields of the same field + name whose value is a comma-separated list can be combined into one + header field. That applies to SIP as well, but the specific rule is + different because of the different grammars. Specifically, any SIP + header whose grammar is of the form + + header = "header-name" HCOLON header-value *(COMMA header-value) + + allows for combining header fields of the same name into a comma- + separated list. The Contact header field allows a comma-separated + list unless the header field value is "*". + + + +Rosenberg, et. al. Standards Track [Page 29] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +7.3.1 Header Field Format + + Header fields follow the same generic header format as that given in + Section 2.2 of RFC 2822 [3]. Each header field consists of a field + name followed by a colon (":") and the field value. + + field-name: field-value + + The formal grammar for a message-header specified in Section 25 + allows for an arbitrary amount of whitespace on either side of the + colon; however, implementations should avoid spaces between the field + name and the colon and use a single space (SP) between the colon and + the field-value. + + Subject: lunch + Subject : lunch + Subject :lunch + Subject: lunch + + Thus, the above are all valid and equivalent, but the last is the + preferred form. + + Header fields can be extended over multiple lines by preceding each + extra line with at least one SP or horizontal tab (HT). The line + break and the whitespace at the beginning of the next line are + treated as a single SP character. Thus, the following are + equivalent: + + Subject: I know you're there, pick up the phone and talk to me! + Subject: I know you're there, + pick up the phone + and talk to me! + + The relative order of header fields with different field names is not + significant. However, it is RECOMMENDED that header fields which are + needed for proxy processing (Via, Route, Record-Route, Proxy-Require, + Max-Forwards, and Proxy-Authorization, for example) appear towards + the top of the message to facilitate rapid parsing. The relative + order of header field rows with the same field name is important. + Multiple header field rows 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 (that is, if follows the grammar + defined in Section 7.3). It MUST be possible to combine the multiple + header field rows 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 exceptions + to this rule are the WWW-Authenticate, Authorization, Proxy- + Authenticate, and Proxy-Authorization header fields. Multiple header + + + +Rosenberg, et. al. Standards Track [Page 30] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + field rows with these names MAY be present in a message, but since + their grammar does not follow the general form listed in Section 7.3, + they MUST NOT be combined into a single header field row. + + Implementations MUST be able to process multiple header field rows + with the same name in any combination of the single-value-per-line or + comma-separated value forms. + + The following groups of header field rows are valid and equivalent: + + Route: <sip:alice@atlanta.com> + Subject: Lunch + Route: <sip:bob@biloxi.com> + Route: <sip:carol@chicago.com> + + Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> + Route: <sip:carol@chicago.com> + Subject: Lunch + + Subject: Lunch + Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, + <sip:carol@chicago.com> + + Each of the following blocks is valid but not equivalent to the + others: + + Route: <sip:alice@atlanta.com> + Route: <sip:bob@biloxi.com> + Route: <sip:carol@chicago.com> + + Route: <sip:bob@biloxi.com> + Route: <sip:alice@atlanta.com> + Route: <sip:carol@chicago.com> + + Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, + <sip:bob@biloxi.com> + + The format of a header field-value is defined per header-name. It + will always be either an opaque sequence of TEXT-UTF8 octets, or a + combination of whitespace, tokens, separators, and quoted strings. + Many existing header fields will adhere to the general form of a + value followed by a semi-colon separated sequence of parameter-name, + parameter-value pairs: + + field-name: field-value *(;parameter-name=parameter-value) + + + + + + +Rosenberg, et. al. Standards Track [Page 31] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Even though an arbitrary number of parameter pairs may be attached to + a header field value, any given parameter-name MUST NOT appear more + than once. + + When comparing header fields, field names are always case- + insensitive. Unless otherwise stated in the definition of a + particular header field, field values, parameter names, and parameter + values are case-insensitive. Tokens are always case-insensitive. + Unless specified otherwise, values expressed as quoted strings are + case-sensitive. For example, + + Contact: <sip:alice@atlanta.com>;expires=3600 + + is equivalent to + + CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 + + and + + Content-Disposition: session;handling=optional + + is equivalent to + + content-disposition: Session;HANDLING=OPTIONAL + + The following two header fields are not equivalent: + + Warning: 370 devnull "Choose a bigger pipe" + Warning: 370 devnull "CHOOSE A BIGGER PIPE" + +7.3.2 Header Field Classification + + Some header fields only make sense in requests or responses. These + are called request header fields and response header fields, + respectively. If a header field appears in a message not matching + its category (such as a request header field in a response), it MUST + be ignored. Section 20 defines the classification of each header + field. + +7.3.3 Compact Form + + SIP provides a mechanism to represent common header field names in an + abbreviated form. This may be useful when messages would otherwise + become too large to be carried on the transport available to it + (exceeding the maximum transmission unit (MTU) when using UDP, for + example). These compact forms are defined in Section 20. A compact + form MAY be substituted for the longer form of a header field name at + any time without changing the semantics of the message. A header + + + +Rosenberg, et. al. Standards Track [Page 32] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + field name MAY appear in both long and short forms within the same + message. Implementations MUST accept both the long and short forms + of each header name. + +7.4 Bodies + + Requests, including new requests defined in extensions to this + specification, MAY contain message bodies unless otherwise noted. + The interpretation of the body depends on the request method. + + 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. + +7.4.1 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. + + The "multipart" MIME type defined in RFC 2046 [11] MAY be used within + the body of the message. Implementations that send requests + containing multipart message bodies MUST send a session description + as a non-multipart message body if the remote implementation requests + this through an Accept header field that does not contain multipart. + + SIP messages MAY contain binary bodies or body parts. When no + explicit charset parameter is provided by the sender, media subtypes + of the "text" type are defined to have a default charset value of + "UTF-8". + +7.4.2 Message Body Length + + The body length in bytes is provided by the Content-Length header + field. Section 20.14 describes the necessary contents of this header + field 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.) + + + + + + + +Rosenberg, et. al. Standards Track [Page 33] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +7.5 Framing SIP Messages + + Unlike HTTP, SIP implementations can use UDP or other unreliable + datagram protocols. Each such datagram carries one request or + response. See Section 18 on constraints on usage of unreliable + transports. + + Implementations processing SIP messages over stream-oriented + transports MUST ignore any CRLF appearing before the start-line + [H4.1]. + + The Content-Length header field value is used to locate the end of + each SIP message in a stream. It will always be present when SIP + messages are sent over stream-oriented transports. + +8 General User Agent Behavior + + A user agent represents an end system. It contains a user agent + client (UAC), which generates requests, and a user agent server + (UAS), which responds to them. A UAC is capable of generating a + request based on some external stimulus (the user clicking a button, + or a signal on a PSTN line) and processing a response. A UAS is + capable of receiving a request and generating a response based on + user input, external stimulus, the result of a program execution, or + some other mechanism. + + When a UAC sends a request, the request passes through some number of + proxy servers, which forward the request towards the UAS. When the + UAS generates a response, the response is forwarded towards the UAC. + + UAC and UAS procedures depend strongly on two factors. First, based + on whether the request or response is inside or outside of a dialog, + and second, based on the method of a request. Dialogs are discussed + thoroughly in Section 12; they represent a peer-to-peer relationship + between user agents and are established by specific SIP methods, such + as INVITE. + + In this section, we discuss the method-independent rules for UAC and + UAS behavior when processing requests that are outside of a dialog. + This includes, of course, the requests which themselves establish a + dialog. + + Security procedures for requests and responses outside of a dialog + are described in Section 26. Specifically, mechanisms exist for the + UAS and UAC to mutually authenticate. A limited set of privacy + features are also supported through encryption of bodies using + S/MIME. + + + + +Rosenberg, et. al. Standards Track [Page 34] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.1 UAC Behavior + + This section covers UAC behavior outside of a dialog. + +8.1.1 Generating the Request + + A valid SIP request formulated by a UAC MUST, at a minimum, contain + the following header fields: To, From, CSeq, Call-ID, Max-Forwards, + and Via; all of these header fields are mandatory in all SIP + requests. These six header fields are the fundamental building + blocks of a SIP message, as they jointly provide for most of the + critical message routing services including the addressing of + messages, the routing of responses, limiting message propagation, + ordering of messages, and the unique identification of transactions. + These header fields are in addition to the mandatory request line, + which contains the method, Request-URI, and SIP version. + + Examples of requests sent outside of a dialog include an INVITE to + establish a session (Section 13) and an OPTIONS to query for + capabilities (Section 11). + +8.1.1.1 Request-URI + + The initial Request-URI of the message SHOULD be set to the value of + the URI in the To field. One notable exception is the REGISTER + method; behavior for setting the Request-URI of REGISTER is given in + Section 10. It may also be undesirable for privacy reasons or + convenience to set these fields to the same value (especially if the + originating UA expects that the Request-URI will be changed during + transit). + + In some special circumstances, the presence of a pre-existing route + set can affect the Request-URI of the message. A pre-existing route + set is an ordered set of URIs that identify a chain of servers, to + which a UAC will send outgoing requests that are outside of a dialog. + Commonly, they are configured on the UA by a user or service provider + manually, or through some other non-SIP mechanism. When a provider + wishes to configure a UA with an outbound proxy, it is RECOMMENDED + that this be done by providing it with a pre-existing route set with + a single URI, that of the outbound proxy. + + When a pre-existing route set is present, the procedures for + populating the Request-URI and Route header field detailed in Section + 12.2.1.1 MUST be followed (even though there is no dialog), using the + desired Request-URI as the remote target URI. + + + + + + +Rosenberg, et. al. Standards Track [Page 35] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.1.1.2 To + + The To header field first and foremost specifies the desired + "logical" recipient of the request, or the address-of-record of the + user or resource that is the target of this request. This may or may + not be the ultimate recipient of the request. The To header field + MAY contain a SIP or SIPS URI, but it may also make use of other URI + schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. + All SIP implementations MUST support the SIP URI scheme. Any + implementation that supports TLS MUST support the SIPS URI scheme. + The To header field allows for a display name. + + A UAC may learn how to populate the To header field for a particular + request in a number of ways. Usually the user will suggest the To + header field through a human interface, perhaps inputting the URI + manually or selecting it from some sort of address book. Frequently, + the user will not enter a complete URI, but rather a string of digits + or letters (for example, "bob"). It is at the discretion of the UA + to choose how to interpret this input. Using the string to form the + user part of a SIP URI implies that the UA wishes the name to be + resolved in the domain to the right-hand side (RHS) of the at-sign in + the SIP URI (for instance, sip:bob@example.com). Using the string to + form the user part of a SIPS URI implies that the UA wishes to + communicate securely, and that the name is to be resolved in the + domain to the RHS of the at-sign. The RHS will frequently be the + home domain of the requestor, which allows for the home domain to + process the outgoing request. This is useful for features like + "speed dial" that require interpretation of the user part in the home + domain. The tel URL may be used when the UA does not wish to specify + the domain that should interpret a telephone number that has been + input by the user. Rather, each domain through which the request + passes would be given that opportunity. As an example, a user in an + airport might log in and send requests through an outbound proxy in + the airport. If they enter "411" (this is the phone number for local + directory assistance in the United States), that needs to be + interpreted and processed by the outbound proxy in the airport, not + the user's home domain. In this case, tel:411 would be the right + choice. + + A request outside of a dialog MUST NOT contain a To tag; the tag in + the To field of a request identifies the peer of the dialog. Since + no dialog is established, no tag is present. + + For further information on the To header field, see Section 20.39. + The following is an example of a valid To header field: + + To: Carol <sip:carol@chicago.com> + + + + +Rosenberg, et. al. Standards Track [Page 36] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.1.1.3 From + + The From header field indicates the logical identity of the initiator + of the request, possibly the user's address-of-record. Like the To + header field, it contains a URI and optionally a display name. It is + used by SIP elements to determine which processing rules to apply to + a request (for example, automatic call rejection). As such, it is + very important that the From URI not contain IP addresses or the FQDN + of the host on which the UA is running, since these are not logical + names. + + The From header field allows for a display name. A UAC SHOULD use + the display name "Anonymous", along with a syntactically correct, but + otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the + identity of the client is to remain hidden. + + Usually, the value that populates the From header field in requests + generated by a particular UA is pre-provisioned by the user or by the + administrators of the user's local domain. If a particular UA is + used by multiple users, it might have switchable profiles that + include a URI corresponding to the identity of the profiled user. + Recipients of requests can authenticate the originator of a request + in order to ascertain that they are who their From header field + claims they are (see Section 22 for more on authentication). + + The From field MUST contain a new "tag" parameter, chosen by the UAC. + See Section 19.3 for details on choosing a tag. + + For further information on the From header field, see Section 20.20. + Examples: + + From: "Bob" <sips:bob@biloxi.com> ;tag=a48s + From: sip:+12125551212@phone2net.com;tag=887s + From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 + +8.1.1.4 Call-ID + + The Call-ID header field acts as a unique identifier to group + together a series of messages. It MUST be the same for all requests + and responses sent by either UA in a dialog. It SHOULD be the same + in each registration from a UA. + + In a new request created by a UAC outside of any dialog, the Call-ID + header field MUST be selected by the UAC as a globally unique + identifier over space and time unless overridden by method-specific + behavior. All SIP UAs must have a means to guarantee that the Call- + ID header fields they produce will not be inadvertently generated by + any other UA. Note that when requests are retried after certain + + + +Rosenberg, et. al. Standards Track [Page 37] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + failure responses that solicit an amendment to a request (for + example, a challenge for authentication), these retried requests are + not considered new requests, and therefore do not need new Call-ID + header fields; see Section 8.1.3.5. + + Use of cryptographically random identifiers (RFC 1750 [12]) in the + generation of Call-IDs is RECOMMENDED. Implementations MAY use the + form "localid@host". Call-IDs are case-sensitive and are simply + compared byte-by-byte. + + Using cryptographically random identifiers provides some + protection against session hijacking and reduces the likelihood of + unintentional Call-ID collisions. + + No provisioning or human interface is required for the selection of + the Call-ID header field value for a request. + + For further information on the Call-ID header field, see Section + 20.8. + + Example: + + Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com + +8.1.1.5 CSeq + + The CSeq header field serves as a way to identify and order + transactions. It consists of a sequence number and a method. The + method MUST match that of the request. For non-REGISTER requests + outside of a dialog, the sequence number value is arbitrary. The + sequence number value MUST be expressible as a 32-bit unsigned + integer and MUST be less than 2**31. As long as it follows the above + guidelines, a client may use any mechanism it would like to select + CSeq header field values. + + Section 12.2.1.1 discusses construction of the CSeq for requests + within a dialog. + + Example: + + CSeq: 4711 INVITE + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 38] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.1.1.6 Max-Forwards + + The Max-Forwards header field serves to limit the number of hops a + request can transit on the way to its destination. It consists of an + integer that is decremented by one at each hop. If the Max-Forwards + value reaches 0 before the request reaches its destination, it will + be rejected with a 483(Too Many Hops) error response. + + A UAC MUST insert a Max-Forwards header field into each request it + originates with a value that SHOULD be 70. This number was chosen to + be sufficiently large to guarantee that a request would not be + dropped in any SIP network when there were no loops, but not so large + as to consume proxy resources when a loop does occur. Lower values + should be used with caution and only in networks where topologies are + known by the UA. + +8.1.1.7 Via + + The Via header field indicates the transport used for the transaction + and identifies the location where the response is to be sent. A Via + header field value is added only after the transport that will be + used to reach the next hop has been selected (which may involve the + usage of the procedures in [4]). + + When the UAC creates a request, it MUST insert a Via into that + request. The protocol name and protocol version in the header field + MUST be SIP and 2.0, respectively. The Via header field value MUST + contain a branch parameter. This parameter is used to identify the + transaction created by that request. This parameter is used by both + the client and the server. + + The branch parameter value MUST be unique across space and time for + all requests sent by the UA. The exceptions to this rule are CANCEL + and ACK for non-2xx responses. As discussed below, a CANCEL request + will have the same value of the branch parameter as the request it + cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx + response will also have the same branch ID as the INVITE whose + response it acknowledges. + + The uniqueness property of the branch ID parameter, to facilitate + its use as a transaction ID, was not part of RFC 2543. + + The branch ID inserted by an element compliant with this + specification MUST always begin with the characters "z9hG4bK". These + 7 characters are used as a magic cookie (7 is deemed sufficient to + ensure that an older RFC 2543 implementation would not pick such a + value), so that servers receiving the request can determine that the + branch ID was constructed in the fashion described by this + + + +Rosenberg, et. al. Standards Track [Page 39] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + specification (that is, globally unique). Beyond this requirement, + the precise format of the branch token is implementation-defined. + + The Via header maddr, ttl, and sent-by components will be set when + the request is processed by the transport layer (Section 18). + + Via processing for proxies is described in Section 16.6 Item 8 and + Section 16.7 Item 3. + +8.1.1.8 Contact + + The Contact header field provides a SIP or SIPS URI that can be used + to contact that specific instance of the UA for subsequent requests. + The Contact header field MUST be present and contain exactly one SIP + or SIPS URI in any request that can result in the establishment of a + dialog. For the methods defined in this specification, that includes + only the INVITE request. For these requests, the scope of the + Contact is global. That is, the Contact header field value contains + the URI at which the UA would like to receive requests, and this URI + MUST be valid even if used in subsequent requests outside of any + dialogs. + + If the Request-URI or top Route header field value contains a SIPS + URI, the Contact header field MUST contain a SIPS URI as well. + + For further information on the Contact header field, see Section + 20.10. + +8.1.1.9 Supported and Require + + If the UAC supports extensions to SIP that can be applied by the + server to the response, the UAC SHOULD include a Supported header + field in the request listing the option tags (Section 19.2) for those + extensions. + + The option tags listed MUST only refer to extensions defined in + standards-track RFCs. This is to prevent servers from insisting that + clients implement non-standard, vendor-defined features in order to + receive service. Extensions defined by experimental and + informational RFCs are explicitly excluded from usage with the + Supported header field in a request, since they too are often used to + document vendor-defined extensions. + + If the UAC wishes to insist that a UAS understand an extension that + the UAC will apply to the request in order to process the request, it + MUST insert a Require header field into the request listing the + option tag for that extension. If the UAC wishes to apply an + extension to the request and insist that any proxies that are + + + +Rosenberg, et. al. Standards Track [Page 40] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + traversed understand that extension, it MUST insert a Proxy-Require + header field into the request listing the option tag for that + extension. + + As with the Supported header field, the option tags in the Require + and Proxy-Require header fields MUST only refer to extensions defined + in standards-track RFCs. + +8.1.1.10 Additional Message Components + + After a new request has been created, and the header fields described + above have been properly constructed, any additional optional header + fields are added, as are any header fields specific to the method. + + SIP requests MAY contain a MIME-encoded message-body. Regardless of + the type of body that a request contains, certain header fields must + be formulated to characterize the contents of the body. For further + information on these header fields, see Sections 20.11 through 20.15. + +8.1.2 Sending the Request + + The destination for the request is then computed. Unless there is + local policy specifying otherwise, the destination MUST be determined + by applying the DNS procedures described in [4] as follows. If the + first element in the route set indicated a strict router (resulting + in forming the request as described in Section 12.2.1.1), the + procedures MUST be applied to the Request-URI of the request. + Otherwise, the procedures are applied to the first Route header field + value in the request (if one exists), or to the request's Request-URI + if there is no Route header field present. These procedures yield an + ordered set of address, port, and transports to attempt. Independent + of which URI is used as input to the procedures of [4], if the + Request-URI specifies a SIPS resource, the UAC MUST follow the + procedures of [4] as if the input URI were a SIPS URI. + + Local policy MAY specify an alternate set of destinations to attempt. + If the Request-URI contains a SIPS URI, any alternate destinations + MUST be contacted with TLS. Beyond that, there are no restrictions + on the alternate destinations if the request contains no Route header + field. This provides a simple alternative to a pre-existing route + set as a way to specify an outbound proxy. However, that approach + for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing + route set with a single URI SHOULD be used instead. If the request + contains a Route header field, the request SHOULD be sent to the + locations derived from its topmost value, but MAY be sent to any + server that the UA is certain will honor the Route and Request-URI + policies specified in this document (as opposed to those in RFC + 2543). In particular, a UAC configured with an outbound proxy SHOULD + + + +Rosenberg, et. al. Standards Track [Page 41] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + attempt to send the request to the location indicated in the first + Route header field value instead of adopting the policy of sending + all messages to the outbound proxy. + + This ensures that outbound proxies that do not add Record-Route + header field values will drop out of the path of subsequent + requests. It allows endpoints that cannot resolve the first Route + URI to delegate that task to an outbound proxy. + + The UAC SHOULD follow the procedures defined in [4] for stateful + elements, trying each address until a server is contacted. Each try + constitutes a new transaction, and therefore each carries a different + topmost Via header field value with a new branch parameter. + Furthermore, the transport value in the Via header field is set to + whatever transport was determined for the target server. + +8.1.3 Processing Responses + + Responses are first processed by the transport layer and then passed + up to the transaction layer. The transaction layer performs its + processing and then passes the response up to the TU. The majority + of response processing in the TU is method specific. However, there + are some general behaviors independent of the method. + +8.1.3.1 Transaction Layer Errors + + In some cases, the response returned by the transaction layer will + not be a SIP message, but rather a transaction layer error. When a + timeout error is received from the transaction layer, it MUST be + treated as if a 408 (Request Timeout) status code has been received. + If a fatal transport error is reported by the transport layer + (generally, due to fatal ICMP errors in UDP or connection failures in + TCP), the condition MUST be treated as a 503 (Service Unavailable) + status code. + +8.1.3.2 Unrecognized Responses + + A UAC MUST treat any final response it does not recognize as being + equivalent to the x00 response code of that class, and MUST be able + to process the x00 response code for all classes. For example, if a + UAC 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. A + UAC MUST treat any provisional response different than 100 that it + does not recognize as 183 (Session Progress). A UAC MUST be able to + process 100 and 183 responses. + + + + + +Rosenberg, et. al. Standards Track [Page 42] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.1.3.3 Vias + + If more than one Via header field value is present in a response, the + UAC SHOULD discard the message. + + The presence of additional Via header field values that precede + the originator of the request suggests that the message was + misrouted or possibly corrupted. + +8.1.3.4 Processing 3xx Responses + + Upon receipt of a redirection response (for example, a 301 response + status code), clients SHOULD use the URI(s) in the Contact header + field to formulate one or more new requests based on the redirected + request. This process is similar to that of a proxy recursing on a + 3xx class response as detailed in Sections 16.5 and 16.6. A client + starts with an initial target set containing exactly one URI, the + Request-URI of the original request. If a client wishes to formulate + new requests based on a 3xx class response to that request, it places + the URIs to try into the target set. Subject to the restrictions in + this specification, a client can choose which Contact URIs it places + into the target set. As with proxy recursion, a client processing + 3xx class responses MUST NOT add any given URI to the target set more + than once. If the original request had a SIPS URI in the Request- + URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD + inform the user of the redirection to an insecure URI. + + Any new request may receive 3xx responses themselves containing + the original URI as a contact. Two locations can be configured to + redirect to each other. Placing any given URI in the target set + only once prevents infinite redirection loops. + + As the target set grows, the client MAY generate new requests to the + URIs in any order. A common mechanism is to order the set by the "q" + parameter value from the Contact header field value. Requests to the + URIs MAY be generated serially or in parallel. One approach is to + process groups of decreasing q-values serially and process the URIs + in each q-value group in parallel. Another is to perform only serial + processing in decreasing q-value order, arbitrarily choosing between + contacts of equal q-value. + + If contacting an address in the list results in a failure, as defined + in the next paragraph, the element moves to the next address in the + list, until the list is exhausted. If the list is exhausted, then + the request has failed. + + + + + + +Rosenberg, et. al. Standards Track [Page 43] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Failures SHOULD be detected through failure response codes (codes + greater than 399); for network errors the client transaction will + report any transport layer failures to the transaction user. Note + that some response codes (detailed in 8.1.3.5) indicate that the + request can be retried; requests that are reattempted should not be + considered failures. + + When a failure for a particular contact address is received, the + client SHOULD try the next contact address. This will involve + creating a new client transaction to deliver a new request. + + In order to create a request based on a contact address in a 3xx + response, a UAC MUST copy the entire URI from the target set into the + Request-URI, except for the "method-param" and "header" URI + parameters (see Section 19.1.1 for a definition of these parameters). + It uses the "header" parameters to create header field values for the + new request, overwriting header field values associated with the + redirected request in accordance with the guidelines in Section + 19.1.5. + + Note that in some instances, header fields that have been + communicated in the contact address may instead append to existing + request header fields in the original redirected request. As a + general rule, if the header field can accept a comma-separated list + of values, then the new header field value MAY be appended to any + existing values in the original redirected request. If the header + field does not accept multiple values, the value in the original + redirected request MAY be overwritten by the header field value + communicated in the contact address. For example, if a contact + address is returned with the following value: + + sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> + + Then any Subject header field in the original redirected request is + overwritten, but the HTTP URL is merely appended to any existing + Call-Info header field values. + + It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID + used in the original redirected request, but the UAC MAY also choose + to update the Call-ID header field value for new requests, for + example. + + Finally, once the new request has been constructed, it is sent using + a new client transaction, and therefore MUST have a new branch ID in + the top Via field as discussed in Section 8.1.1.7. + + + + + + +Rosenberg, et. al. Standards Track [Page 44] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + In all other respects, requests sent upon receipt of a redirect + response SHOULD re-use the header fields and bodies of the original + request. + + In some instances, Contact header field values may be cached at UAC + temporarily or permanently depending on the status code received and + the presence of an expiration interval; see Sections 21.3.2 and + 21.3.3. + +8.1.3.5 Processing 4xx Responses + + Certain 4xx response codes require specific UA processing, + independent of the method. + + If a 401 (Unauthorized) or 407 (Proxy Authentication Required) + response is received, the UAC SHOULD follow the authorization + procedures of Section 22.2 and Section 22.3 to retry the request with + credentials. + + If a 413 (Request Entity Too Large) response is received (Section + 21.4.11), the request contained a body that was longer than the UAS + was willing to accept. If possible, the UAC SHOULD retry the + request, either omitting the body or using one of a smaller length. + + If a 415 (Unsupported Media Type) response is received (Section + 21.4.13), the request contained media types not supported by the UAS. + The UAC SHOULD retry sending the request, this time only using + content with types listed in the Accept header field in the response, + with encodings listed in the Accept-Encoding header field in the + response, and with languages listed in the Accept-Language in the + response. + + If a 416 (Unsupported URI Scheme) response is received (Section + 21.4.14), the Request-URI used a URI scheme not supported by the + server. The client SHOULD retry the request, this time, using a SIP + URI. + + If a 420 (Bad Extension) response is received (Section 21.4.15), the + request contained a Require or Proxy-Require header field listing an + option-tag for a feature not supported by a proxy or UAS. The UAC + SHOULD retry the request, this time omitting any extensions listed in + the Unsupported header field in the response. + + In all of the above cases, the request is retried by creating a new + request with the appropriate modifications. This new request + constitutes a new transaction and SHOULD have the same value of the + Call-ID, To, and From of the previous request, but the CSeq should + contain a new sequence number that is one higher than the previous. + + + +Rosenberg, et. al. Standards Track [Page 45] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + With other 4xx responses, including those yet to be defined, a retry + may or may not be possible depending on the method and the use case. + +8.2 UAS Behavior + + When a request outside of a dialog is processed by a UAS, there is a + set of processing rules that are followed, independent of the method. + Section 12 gives guidance on how a UAS can tell whether a request is + inside or outside of a dialog. + + Note that request processing is atomic. If a request is accepted, + all state changes associated with it MUST be performed. If it is + rejected, all state changes MUST NOT be performed. + + UASs SHOULD process the requests in the order of the steps that + follow in this section (that is, starting with authentication, then + inspecting the method, the header fields, and so on throughout the + remainder of this section). + +8.2.1 Method Inspection + + Once a request is authenticated (or authentication is skipped), the + UAS MUST inspect the method of the request. If the UAS recognizes + but does not support the method of a request, it MUST generate a 405 + (Method Not Allowed) response. Procedures for generating responses + are described in Section 8.2.6. The UAS MUST also add an Allow + header field to the 405 (Method Not Allowed) response. The Allow + header field MUST list the set of methods supported by the UAS + generating the message. The Allow header field is presented in + Section 20.5. + + If the method is one supported by the server, processing continues. + +8.2.2 Header Inspection + + If a UAS does not understand a header field in a request (that is, + the header field is not defined in this specification or in any + supported extension), the server MUST ignore that header field and + continue processing the message. A UAS SHOULD ignore any malformed + header fields that are not necessary for processing requests. + +8.2.2.1 To and Request-URI + + The To header field identifies the original recipient of the request + designated by the user identified in the From field. The original + recipient may or may not be the UAS processing the request, due to + call forwarding or other proxy operations. A UAS MAY apply any + policy it wishes to determine whether to accept requests when the To + + + +Rosenberg, et. al. Standards Track [Page 46] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + header field is not the identity of the UAS. However, it is + RECOMMENDED that a UAS accept requests even if they do not recognize + the URI scheme (for example, a tel: URI) in the To header field, or + if the To header field does not address a known or current user of + this UAS. If, on the other hand, the UAS decides to reject the + request, it SHOULD generate a response with a 403 (Forbidden) status + code and pass it to the server transaction for transmission. + + However, the Request-URI identifies the UAS that is to process the + request. If the Request-URI uses a scheme not supported by the UAS, + it SHOULD reject the request with a 416 (Unsupported URI Scheme) + response. If the Request-URI does not identify an address that the + UAS is willing to accept requests for, it SHOULD reject the request + with a 404 (Not Found) response. Typically, a UA that uses the + REGISTER method to bind its address-of-record to a specific contact + address will see requests whose Request-URI equals that contact + address. Other potential sources of received Request-URIs include + the Contact header fields of requests and responses sent by the UA + that establish or refresh dialogs. + +8.2.2.2 Merged Requests + + If the request has no tag in the To header field, the UAS core MUST + check the request against ongoing transactions. If the From tag, + Call-ID, and CSeq exactly match those associated with an ongoing + transaction, but the request does not match that transaction (based + on the matching rules in Section 17.2.3), the UAS core SHOULD + generate a 482 (Loop Detected) response and pass it to the server + transaction. + + The same request has arrived at the UAS more than once, following + different paths, most likely due to forking. The UAS processes + the first such request received and responds with a 482 (Loop + Detected) to the rest of them. + +8.2.2.3 Require + + Assuming the UAS decides that it is the proper element to process the + request, it examines the Require header field, if present. + + The Require header field is used by a UAC to tell a UAS about SIP + extensions that the UAC expects the UAS to support in order to + process the request properly. Its format is described in Section + 20.32. If a UAS does not understand an option-tag listed in a + Require header field, it MUST respond by generating a response with + status code 420 (Bad Extension). The UAS MUST add an Unsupported + header field, and list in it those options it does not understand + amongst those in the Require header field of the request. + + + +Rosenberg, et. al. Standards Track [Page 47] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL + request, or in an ACK request sent for a non-2xx response. These + header fields MUST be ignored if they are present in these requests. + + An ACK request for a 2xx response MUST contain only those Require and + Proxy-Require values that were present in the initial request. + + Example: + + UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 + Require: 100rel + + UAS->UAC: SIP/2.0 420 Bad Extension + Unsupported: 100rel + + This behavior ensures 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. + +8.2.3 Content Processing + + Assuming the UAS understands any extensions required by the client, + the UAS examines the body of the message, and the header fields that + describe it. If there are any bodies whose type (indicated by the + Content-Type), language (indicated by the Content-Language) or + encoding (indicated by the Content-Encoding) are not understood, and + that body part is not optional (as indicated by the Content- + Disposition header field), the UAS MUST reject the request with a 415 + (Unsupported Media Type) response. The response MUST contain an + Accept header field listing the types of all bodies it understands, + in the event the request contained bodies of types not supported by + the UAS. If the request contained content encodings not understood + by the UAS, the response MUST contain an Accept-Encoding header field + listing the encodings understood by the UAS. If the request + contained content with languages not understood by the UAS, the + response MUST contain an Accept-Language header field indicating the + languages understood by the UAS. Beyond these checks, body handling + depends on the method and type. For further information on the + processing of content-specific header fields, see Section 7.4 as well + as Section 20.11 through 20.15. + + + + + +Rosenberg, et. al. Standards Track [Page 48] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +8.2.4 Applying Extensions + + A UAS that wishes to apply some extension when generating the + response MUST NOT do so unless support for that extension is + indicated in the Supported header field in the request. If the + desired extension is not supported, the server SHOULD rely only on + baseline SIP and any other extensions supported by the client. In + rare circumstances, where the server cannot process the request + without the extension, the server MAY send a 421 (Extension Required) + response. This response indicates that the proper response cannot be + generated without support of a specific extension. The needed + extension(s) MUST be included in a Require header field in the + response. This behavior is NOT RECOMMENDED, as it will generally + break interoperability. + + Any extensions applied to a non-421 response MUST be listed in a + Require header field included in the response. Of course, the server + MUST NOT apply extensions not listed in the Supported header field in + the request. As a result of this, the Require header field in a + response will only ever contain option tags defined in standards- + track RFCs. + +8.2.5 Processing the Request + + Assuming all of the checks in the previous subsections are passed, + the UAS processing becomes method-specific. Section 10 covers the + REGISTER request, Section 11 covers the OPTIONS request, Section 13 + covers the INVITE request, and Section 15 covers the BYE request. + +8.2.6 Generating the Response + + When a UAS wishes to construct a response to a request, it follows + the general procedures detailed in the following subsections. + Additional behaviors specific to the response code in question, which + are not detailed in this section, may also be required. + + Once all procedures associated with the creation of a response have + been completed, the UAS hands the response back to the server + transaction from which it received the request. + +8.2.6.1 Sending a Provisional Response + + One largely non-method-specific guideline for the generation of + responses is that UASs SHOULD NOT issue a provisional response for a + non-INVITE request. Rather, UASs SHOULD generate a final response to + a non-INVITE request as soon as possible. + + + + + +Rosenberg, et. al. Standards Track [Page 49] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + When a 100 (Trying) response is generated, any Timestamp header field + present in the request MUST be copied into this 100 (Trying) + response. If there is a delay in generating the response, the UAS + SHOULD add a delay value into the Timestamp value in the response. + This value MUST contain the difference between the time of sending of + the response and receipt of the request, measured in seconds. + +8.2.6.2 Headers and Tags + + The From field of the response MUST equal the From header field of + the request. The Call-ID header field of the response MUST equal the + Call-ID header field of the request. The CSeq header field of the + response MUST equal the CSeq field of the request. The Via header + field values in the response MUST equal the Via header field values + in the request and MUST maintain the same ordering. + + If a request contained a To tag in the request, the To header field + in the response MUST equal that of the request. However, if the To + header field in the request did not contain a tag, the URI in the To + header field in the response MUST equal the URI in the To header + field; additionally, the UAS MUST add a tag to the To header field in + the response (with the exception of the 100 (Trying) response, in + which a tag MAY be present). This serves to identify the UAS that is + responding, possibly resulting in a component of a dialog ID. The + same tag MUST be used for all responses to that request, both final + and provisional (again excepting the 100 (Trying)). Procedures for + the generation of tags are defined in Section 19.3. + +8.2.7 Stateless UAS Behavior + + A stateless UAS is a UAS that does not maintain transaction state. + It replies to requests normally, but discards any state that would + ordinarily be retained by a UAS after a response has been sent. If a + stateless UAS receives a retransmission of a request, it regenerates + the response and resends it, just as if it were replying to the first + instance of the request. A UAS cannot be stateless unless the request + processing for that method would always result in the same response + if the requests are identical. This rules out stateless registrars, + for example. Stateless UASs do not use a transaction layer; they + receive requests directly from the transport layer and send responses + directly to the transport layer. + + The stateless UAS role is needed primarily to handle unauthenticated + requests for which a challenge response is issued. If + unauthenticated requests were handled statefully, then malicious + floods of unauthenticated requests could create massive amounts of + + + + + +Rosenberg, et. al. Standards Track [Page 50] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + transaction state that might slow or completely halt call processing + in a UAS, effectively creating a denial of service condition; for + more information see Section 26.1.5. + + The most important behaviors of a stateless UAS are the following: + + o A stateless UAS MUST NOT send provisional (1xx) responses. + + o A stateless UAS MUST NOT retransmit responses. + + o A stateless UAS MUST ignore ACK requests. + + o A stateless UAS MUST ignore CANCEL requests. + + o To header tags MUST be generated for responses in a stateless + manner - in a manner that will generate the same tag for the + same request consistently. For information on tag construction + see Section 19.3. + + In all other respects, a stateless UAS behaves in the same manner as + a stateful UAS. A UAS can operate in either a stateful or stateless + mode for each new request. + +8.3 Redirect Servers + + In some architectures it may be desirable to reduce the processing + load on proxy servers that are responsible for routing requests, and + improve signaling path robustness, by relying on redirection. + + Redirection allows servers to push routing information for a request + back in a response to the client, thereby taking themselves out of + the loop of further messaging for this transaction while still aiding + in locating the target of the request. When the originator of the + request receives the redirection, it will send a new request based on + the URI(s) it has received. By propagating URIs from the core of the + network to its edges, redirection allows for considerable network + scalability. + + A redirect server is logically constituted of a server transaction + layer and a transaction user that has access to a location service of + some kind (see Section 10 for more on registrars and location + services). This location service is effectively a database + containing mappings between a single URI and a set of one or more + alternative locations at which the target of that URI can be found. + + A redirect server does not issue any SIP requests of its own. After + receiving a request other than CANCEL, the server either refuses the + request or gathers the list of alternative locations from the + + + +Rosenberg, et. al. Standards Track [Page 51] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + location service and returns a final response of class 3xx. For + well-formed CANCEL requests, it SHOULD return a 2xx response. This + response ends the SIP transaction. The redirect server maintains + transaction state for an entire SIP transaction. It is the + responsibility of clients to detect forwarding loops between redirect + servers. + + When a redirect server returns a 3xx response to a request, it + populates the list of (one or more) alternative locations into the + Contact header field. An "expires" parameter to the Contact header + field values may also be supplied to indicate the lifetime of the + Contact data. + + The Contact header field contains URIs giving the new locations or + user names to try, or may simply specify additional transport + parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) + response may also give the same location and username that was + targeted by the initial request 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. + + However, redirect servers MUST NOT redirect a request to a URI equal + to the one in the Request-URI; instead, provided that the URI does + not point to itself, the server MAY proxy the request to the + destination URI, or MAY reject it with a 404. + + If a client is using an outbound proxy, and that proxy actually + redirects requests, a potential arises for infinite redirection + loops. + + Note that a Contact header field value MAY also refer to a different + resource than the one originally called. For example, a SIP call + connected to PSTN gateway may need to deliver a special informational + 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 + URIs. For example, it could contain URIs for phones, fax, or irc (if + they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 + discusses implications and limitations of redirecting a SIPS URI to a + non-SIPS URI. + + The "expires" parameter of a Contact header field value indicates how + long the URI is valid. The value of the parameter is a number + indicating seconds. If this parameter is not provided, the value of + the Expires header field determines how long the URI is valid. + Malformed values SHOULD be treated as equivalent to 3600. + + + + +Rosenberg, et. al. Standards Track [Page 52] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + This provides a modest level of backwards compatibility with RFC + 2543, which allowed absolute times in this header field. If an + absolute time is received, it will be treated as malformed, and + then default to 3600. + + Redirect servers MUST ignore features that are not understood + (including unrecognized header fields, any unknown option tags in + Require, or even method names) and proceed with the redirection of + the request in question. + +9 Canceling a Request + + The previous section has discussed general UA behavior for generating + requests and processing responses for requests of all methods. In + this section, we discuss a general purpose method, called CANCEL. + + The CANCEL request, as the name implies, is used to cancel a previous + request sent by a client. Specifically, it asks the UAS to cease + processing the request and to generate an error response to that + request. CANCEL has no effect on a request to which a UAS has + already given a final response. Because of this, it is most useful + to CANCEL requests to which it can take a server long time to + respond. For this reason, CANCEL is best for INVITE requests, which + can take a long time to generate a response. In that usage, a UAS + that receives a CANCEL request for an INVITE, but has not yet sent a + final response, would "stop ringing", and then respond to the INVITE + with a specific error response (a 487). + + CANCEL requests can be constructed and sent by both proxies and user + agent clients. Section 15 discusses under what conditions a UAC + would CANCEL an INVITE request, and Section 16.10 discusses proxy + usage of CANCEL. + + A stateful proxy responds to a CANCEL, rather than simply forwarding + a response it would receive from a downstream element. For that + reason, CANCEL is referred to as a "hop-by-hop" request, since it is + responded to at each stateful proxy hop. + +9.1 Client Behavior + + A CANCEL request SHOULD NOT be sent to cancel a request other than + INVITE. + + Since requests other than INVITE are responded to immediately, + sending a CANCEL for a non-INVITE request would always create a + race condition. + + + + + +Rosenberg, et. al. Standards Track [Page 53] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The following procedures are used to construct a CANCEL request. The + Request-URI, Call-ID, To, the numeric part of CSeq, and From header + fields in the CANCEL request MUST be identical to those in the + request being cancelled, including tags. A CANCEL constructed by a + client MUST have only a single Via header field value matching the + top Via value in the request being cancelled. Using the same values + for these header fields allows the CANCEL to be matched with the + request it cancels (Section 9.2 indicates how such matching occurs). + However, the method part of the CSeq header field MUST have a value + of CANCEL. This allows it to be identified and processed as a + transaction in its own right (See Section 17). + + If the request being cancelled contains a Route header field, the + CANCEL request MUST include that Route header field's values. + + This is needed so that stateless proxies are able to route CANCEL + requests properly. + + The CANCEL request MUST NOT contain any Require or Proxy-Require + header fields. + + Once the CANCEL is constructed, the client SHOULD check whether it + has received any response (provisional or final) for the request + being cancelled (herein referred to as the "original request"). + + If no provisional response has been received, the CANCEL request MUST + NOT be sent; rather, the client MUST wait for the arrival of a + provisional response before sending the request. If the original + request has generated a final response, the CANCEL SHOULD NOT be + sent, as it is an effective no-op, since CANCEL has no effect on + requests that have already generated a final response. When the + client decides to send the CANCEL, it creates a client transaction + for the CANCEL and passes it the CANCEL request along with the + destination address, port, and transport. The destination address, + port, and transport for the CANCEL MUST be identical to those used to + send the original request. + + If it was allowed to send the CANCEL before receiving a response + for the previous request, the server could receive the CANCEL + before the original request. + + Note that both the transaction corresponding to the original request + and the CANCEL transaction will complete independently. However, a + UAC canceling a request cannot rely on receiving a 487 (Request + Terminated) response for the original request, as an RFC 2543- + compliant UAS will not generate such a response. If there is no + final response for the original request in 64*T1 seconds (T1 is + + + + +Rosenberg, et. al. Standards Track [Page 54] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + defined in Section 17.1.1.1), the client SHOULD then consider the + original transaction cancelled and SHOULD destroy the client + transaction handling the original request. + +9.2 Server Behavior + + The CANCEL method requests that the TU at the server side cancel a + pending transaction. The TU determines the transaction to be + cancelled by taking the CANCEL request, and then assuming that the + request method is anything but CANCEL or ACK and applying the + transaction matching procedures of Section 17.2.3. The matching + transaction is the one to be cancelled. + + The processing of a CANCEL request at a server depends on the type of + server. A stateless proxy will forward it, a stateful proxy might + respond to it and generate some CANCEL requests of its own, and a UAS + will respond to it. See Section 16.10 for proxy treatment of CANCEL. + + A UAS first processes the CANCEL request according to the general UAS + processing described in Section 8.2. However, since CANCEL requests + are hop-by-hop and cannot be resubmitted, they cannot be challenged + by the server in order to get proper credentials in an Authorization + header field. Note also that CANCEL requests do not contain a + Require header field. + + If the UAS did not find a matching transaction for the CANCEL + according to the procedure above, it SHOULD respond to the CANCEL + with a 481 (Call Leg/Transaction Does Not Exist). If the transaction + for the original request still exists, the behavior of the UAS on + receiving a CANCEL request depends on whether it has already sent a + final response for the original request. If it has, the CANCEL + request has no effect on the processing of the original request, no + effect on any session state, and no effect on the responses generated + for the original request. If the UAS has not issued a final response + for the original request, its behavior depends on the method of the + original request. If the original request was an INVITE, the UAS + SHOULD immediately respond to the INVITE with a 487 (Request + Terminated). A CANCEL request has no impact on the processing of + transactions with any other method defined in this specification. + + Regardless of the method of the original request, as long as the + CANCEL matched an existing transaction, the UAS answers the CANCEL + request itself with a 200 (OK) response. This response is + constructed following the procedures described in Section 8.2.6 + noting that the To tag of the response to the CANCEL and the To tag + in the response to the original request SHOULD be the same. The + response to CANCEL is passed to the server transaction for + transmission. + + + +Rosenberg, et. al. Standards Track [Page 55] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +10 Registrations + +10.1 Overview + + SIP offers a discovery capability. If a user wants to initiate a + session with another user, SIP must discover the current host(s) at + which the destination user is reachable. This discovery process is + frequently accomplished by SIP network elements such as proxy servers + and redirect servers which are responsible for receiving a request, + determining where to send it based on knowledge of the location of + the user, and then sending it there. To do this, SIP network + elements consult an abstract service known as a location service, + which provides address bindings for a particular domain. These + address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, + for example, to one or more URIs that are somehow "closer" to the + desired user, sip:bob@engineering.biloxi.com, for example. + Ultimately, a proxy will consult a location service that maps a + received URI to the user agent(s) at which the desired recipient is + currently residing. + + Registration creates bindings in a location service for a particular + domain that associates an address-of-record URI with one or more + contact addresses. Thus, when a proxy for that domain receives a + request whose Request-URI matches the address-of-record, the proxy + will forward the request to the contact addresses registered to that + address-of-record. Generally, it only makes sense to register an + address-of-record at a domain's location service when requests for + that address-of-record would be routed to that domain. In most + cases, this means that the domain of the registration will need to + match the domain in the URI of the address-of-record. + + There are many ways by which the contents of the location service can + be established. One way is administratively. In the above example, + Bob is known to be a member of the engineering department through + access to a corporate database. However, SIP provides a mechanism + for a UA to create a binding explicitly. This mechanism is known as + registration. + + Registration entails sending a REGISTER request to a special type of + UAS known as a registrar. A registrar acts as the front end to the + location service for a domain, reading and writing mappings based on + the contents of REGISTER requests. This location service is then + typically consulted by a proxy server that is responsible for routing + requests for that domain. + + An illustration of the overall registration process is given in + Figure 2. Note that the registrar and proxy server are logical roles + that can be played by a single device in a network; for purposes of + + + +Rosenberg, et. al. Standards Track [Page 56] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + clarity the two are separated in this illustration. Also note that + UAs may send requests through a proxy server in order to reach a + registrar if the two are separate elements. + + SIP does not mandate a particular mechanism for implementing the + location service. The only requirement is that a registrar for some + domain MUST be able to read and write data to the location service, + and a proxy or a redirect server for that domain MUST be capable of + reading that same data. A registrar MAY be co-located with a + particular SIP proxy server for the same domain. + +10.2 Constructing the REGISTER Request + + REGISTER requests add, remove, and query bindings. A REGISTER + request can add a new binding between an address-of-record and one or + more contact addresses. Registration on behalf of a particular + address-of-record can be performed by a suitably authorized third + party. A client can also remove previous bindings or query to + determine which bindings are currently in place for an address-of- + record. + + Except as noted, the construction of the REGISTER request and the + behavior of clients sending a REGISTER request is identical to the + general UAC behavior described in Section 8.1 and Section 17.1. + + A REGISTER request does not establish a dialog. A UAC MAY include a + Route header field in a REGISTER request based on a pre-existing + route set as described in Section 8.1. The Record-Route header field + has no meaning in REGISTER requests or responses, and MUST be ignored + if present. In particular, the UAC MUST NOT create a new route set + based on the presence or absence of a Record-Route header field in + any response to a REGISTER request. + + The following header fields, except Contact, MUST be included in a + REGISTER request. A Contact header field MAY be included: + + Request-URI: The Request-URI names the domain of the location + service for which the registration is meant (for example, + "sip:chicago.com"). The "userinfo" and "@" components of the + SIP URI MUST NOT be present. + + To: The To header field contains the address of record whose + registration is to be created, queried, or modified. The To + header field and the Request-URI field typically differ, as + the former contains a user name. This address-of-record MUST + be a SIP URI or SIPS URI. + + + + + +Rosenberg, et. al. Standards Track [Page 57] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + From: The From header field contains the address-of-record of the + person responsible for the registration. The value is the + same as the To header field unless the request is a third- + party registration. + + Call-ID: All registrations from a UAC SHOULD use the same Call-ID + header field value for registrations sent to a particular + registrar. + + If the same client were to use different Call-ID values, a + registrar could not detect whether a delayed REGISTER request + might have arrived out of order. + + CSeq: The CSeq value guarantees proper ordering of REGISTER + requests. A UA MUST increment the CSeq value by one for each + REGISTER request with the same Call-ID. + + Contact: REGISTER requests MAY contain a Contact header field with + zero or more values containing address bindings. + + UAs MUST NOT send a new registration (that is, containing new Contact + header field values, as opposed to a retransmission) until they have + received a final response from the registrar for the previous one or + the previous REGISTER request has timed out. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 58] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + bob + +----+ + | UA | + | | + +----+ + | + |3)INVITE + | carol@chicago.com + chicago.com +--------+ V + +---------+ 2)Store|Location|4)Query +-----+ + |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com + +---------+ +--------+=======>+-----+ + A 5)Resp | + | | + | | + 1)REGISTER| | + | | + +----+ | + | UA |<-------------------------------+ + cube2214a| | 6)INVITE + +----+ carol@cube2214a.chicago.com + carol + + Figure 2: REGISTER example + + The following Contact header parameters have a special meaning in + REGISTER requests: + + action: The "action" parameter from RFC 2543 has been deprecated. + UACs SHOULD NOT use the "action" parameter. + + expires: The "expires" parameter indicates how long the UA would + like the binding to be valid. The value is a number + indicating seconds. If this parameter is not provided, the + value of the Expires header field is used instead. + Implementations MAY treat values larger than 2**32-1 + (4294967295 seconds or 136 years) as equivalent to 2**32-1. + Malformed values SHOULD be treated as equivalent to 3600. + +10.2.1 Adding Bindings + + The REGISTER request sent to a registrar includes the contact + address(es) to which SIP requests for the address-of-record should be + forwarded. The address-of-record is included in the To header field + of the REGISTER request. + + + + + + +Rosenberg, et. al. Standards Track [Page 59] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The Contact header field values of the request typically consist of + SIP or SIPS URIs that identify particular SIP endpoints (for example, + "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. + A SIP UA can choose to register telephone numbers (with the tel URL, + RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) + as Contacts for an address-of-record, for example. + + For example, Carol, with address-of-record "sip:carol@chicago.com", + would register with the SIP registrar of the domain chicago.com. Her + registrations would then be used by a proxy server in the chicago.com + domain to route requests for Carol's address-of-record to her SIP + endpoint. + + Once a client has established bindings at a registrar, it MAY send + subsequent registrations containing new bindings or modifications to + existing bindings as necessary. The 2xx response to the REGISTER + request will contain, in a Contact header field, a complete list of + bindings that have been registered for this address-of-record at this + registrar. + + If the address-of-record in the To header field of a REGISTER request + is a SIPS URI, then any Contact header field values in the request + SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs + under a SIPS address-of-record when the security of the resource + represented by the contact address is guaranteed by other means. + This may be applicable to URIs that invoke protocols other than SIP, + or SIP devices secured by protocols other than TLS. + + Registrations do not need to update all bindings. Typically, a UA + only updates its own contact addresses. + +10.2.1.1 Setting the Expiration Interval of Contact Addresses + + When a client sends a REGISTER request, it MAY suggest an expiration + interval that indicates how long the client would like the + registration to be valid. (As described in Section 10.3, the + registrar selects the actual time interval based on its local + policy.) + + There are two ways in which a client can suggest an expiration + interval for a binding: through an Expires header field or an + "expires" Contact header parameter. The latter allows expiration + intervals to be suggested on a per-binding basis when more than one + binding is given in a single REGISTER request, whereas the former + suggests an expiration interval for all Contact header field values + that do not contain the "expires" parameter. + + + + + +Rosenberg, et. al. Standards Track [Page 60] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If neither mechanism for expressing a suggested expiration time is + present in a REGISTER, the client is indicating its desire for the + server to choose. + +10.2.1.2 Preferences among Contact Addresses + + If more than one Contact is sent in a REGISTER request, the + registering UA intends to associate all of the URIs in these Contact + header field values with the address-of-record present in the To + field. This list can be prioritized with the "q" parameter in the + Contact header field. The "q" parameter indicates a relative + preference for the particular Contact header field value compared to + other bindings for this address-of-record. Section 16.6 describes + how a proxy server uses this preference indication. + +10.2.2 Removing Bindings + + Registrations are soft state and expire unless refreshed, but can + also be explicitly removed. A client can attempt to influence the + expiration interval selected by the registrar as described in Section + 10.2.1. A UA requests the immediate removal of a binding by + specifying an expiration interval of "0" for that contact address in + a REGISTER request. UAs SHOULD support this mechanism so that + bindings can be removed before their expiration interval has passed. + + The REGISTER-specific Contact header field value of "*" applies to + all registrations, but it MUST NOT be used unless the Expires header + field is present with a value of "0". + + Use of the "*" Contact header field value allows a registering UA + to remove all bindings associated with an address-of-record + without knowing their precise values. + +10.2.3 Fetching Bindings + + A success response to any REGISTER request contains the complete list + of existing bindings, regardless of whether the request contained a + Contact header field. If no Contact header field is present in a + REGISTER request, the list of bindings is left unchanged. + +10.2.4 Refreshing Bindings + + Each UA is responsible for refreshing the bindings that it has + previously established. A UA SHOULD NOT refresh bindings set up by + other UAs. + + + + + + +Rosenberg, et. al. Standards Track [Page 61] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The 200 (OK) response from the registrar contains a list of Contact + fields enumerating all current bindings. The UA compares each + contact address to see if it created the contact address, using + comparison rules in Section 19.1.4. If so, it updates the expiration + time interval according to the expires parameter or, if absent, the + Expires field value. The UA then issues a REGISTER request for each + of its bindings before the expiration interval has elapsed. It MAY + combine several updates into one REGISTER request. + + A UA SHOULD use the same Call-ID for all registrations during a + single boot cycle. Registration refreshes SHOULD be sent to the same + network address as the original registration, unless redirected. + +10.2.5 Setting the Internal Clock + + If the response for a REGISTER request contains a Date header field, + the client MAY use this header field to learn the current time in + order to set any internal clocks. + +10.2.6 Discovering a Registrar + + UAs can use three ways to determine the address to which to send + registrations: by configuration, using the address-of-record, and + multicast. A UA can be configured, in ways beyond the scope of this + specification, with a registrar address. If there is no configured + registrar address, the UA SHOULD use the host part of the address- + of-record as the Request-URI and address the request there, using the + normal SIP server location mechanisms [4]. For example, the UA for + the user "sip:carol@chicago.com" addresses the REGISTER request to + "sip:chicago.com". + + Finally, a UA can be configured to use multicast. Multicast + registrations are addressed to the well-known "all SIP servers" + multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- + known IPv6 multicast address has been allocated; such an allocation + will be documented separately when needed. SIP UAs MAY listen to + that address and use it to become aware of the location of other + local users (see [33]); however, they do not respond to the request. + + Multicast registration may be inappropriate in some environments, + for example, if multiple businesses share the same local area + network. + +10.2.7 Transmitting a Request + + Once the REGISTER method has been constructed, and the destination of + the message identified, UACs follow the procedures described in + Section 8.1.2 to hand off the REGISTER to the transaction layer. + + + +Rosenberg, et. al. Standards Track [Page 62] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If the transaction layer returns a timeout error because the REGISTER + yielded no response, the UAC SHOULD NOT immediately re-attempt a + registration to the same registrar. + + An immediate re-attempt is likely to also timeout. Waiting some + reasonable time interval for the conditions causing the timeout to + be corrected reduces unnecessary load on the network. No specific + interval is mandated. + +10.2.8 Error Responses + + If a UA receives a 423 (Interval Too Brief) response, it MAY retry + the registration after making the expiration interval of all contact + addresses in the REGISTER request equal to or greater than the + expiration interval within the Min-Expires header field of the 423 + (Interval Too Brief) response. + +10.3 Processing REGISTER Requests + + A registrar is a UAS that responds to REGISTER requests and maintains + a list of bindings that are accessible to proxy servers and redirect + servers within its administrative domain. A registrar handles + requests according to Section 8.2 and Section 17.2, but it accepts + only REGISTER requests. A registrar MUST not generate 6xx responses. + + A registrar MAY redirect REGISTER requests as appropriate. One + common usage would be for a registrar listening on a multicast + interface to redirect multicast REGISTER requests to its own unicast + interface with a 302 (Moved Temporarily) response. + + Registrars MUST ignore the Record-Route header field if it is + included in a REGISTER request. Registrars MUST NOT include a + Record-Route header field in any response to a REGISTER request. + + A registrar might receive a request that traversed a proxy which + treats REGISTER as an unknown request and which added a Record- + Route header field value. + + A registrar has to know (for example, through configuration) the set + of domain(s) for which it maintains bindings. REGISTER requests MUST + be processed by a registrar in the order that they are received. + REGISTER requests MUST also be processed atomically, meaning that a + particular REGISTER request is either processed completely or not at + all. Each REGISTER message MUST be processed independently of any + other registration or binding changes. + + + + + + +Rosenberg, et. al. Standards Track [Page 63] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + When receiving a REGISTER request, a registrar follows these steps: + + 1. The registrar inspects the Request-URI to determine whether it + has access to bindings for the domain identified in the + Request-URI. If not, and if the server also acts as a proxy + server, the server SHOULD forward the request to the addressed + domain, following the general behavior for proxying messages + described in Section 16. + + 2. To guarantee that the registrar supports any necessary + extensions, the registrar MUST process the Require header field + values as described for UASs in Section 8.2.2. + + 3. A registrar SHOULD authenticate the UAC. Mechanisms for the + authentication of SIP user agents are described in Section 22. + Registration behavior in no way overrides the generic + authentication framework for SIP. If no authentication + mechanism is available, the registrar MAY take the From address + as the asserted identity of the originator of the request. + + 4. The registrar SHOULD determine if the authenticated user is + authorized to modify registrations for this address-of-record. + For example, a registrar might consult an authorization + database that maps user names to a list of addresses-of-record + for which that user has authorization to modify bindings. If + the authenticated user is not authorized to modify bindings, + the registrar MUST return a 403 (Forbidden) and skip the + remaining steps. + + In architectures that support third-party registration, one + entity may be responsible for updating the registrations + associated with multiple addresses-of-record. + + 5. The registrar extracts the address-of-record from the To header + field of the request. If the address-of-record is not valid + for the domain in the Request-URI, the registrar MUST send a + 404 (Not Found) response and skip the remaining steps. The URI + MUST then be converted to a canonical form. To do that, all + URI parameters MUST be removed (including the user-param), and + any escaped characters MUST be converted to their unescaped + form. The result serves as an index into the list of bindings. + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 64] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 6. The registrar checks whether the request contains the Contact + header field. If not, it skips to the last step. If the + Contact header field is present, the registrar checks if there + is one Contact field value that contains the special value "*" + and an Expires field. If the request has additional Contact + fields or an expiration time other than zero, the request is + invalid, and the server MUST return a 400 (Invalid Request) and + skip the remaining steps. If not, the registrar checks whether + the Call-ID agrees with the value stored for each binding. If + not, it MUST remove the binding. If it does agree, it MUST + remove the binding only if the CSeq in the request is higher + than the value stored for that binding. Otherwise, the update + MUST be aborted and the request fails. + + 7. The registrar now processes each contact address in the Contact + header field in turn. For each address, it determines the + expiration interval as follows: + + - If the field value has an "expires" parameter, that value + MUST be taken as the requested expiration. + + - If there is no such parameter, but the request has an + Expires header field, that value MUST be taken as the + requested expiration. + + - If there is neither, a locally-configured default value MUST + be taken as the requested expiration. + + The registrar MAY choose an expiration less than the requested + expiration interval. If and only if the requested expiration + interval is greater than zero AND smaller than one hour AND + less than a registrar-configured minimum, the registrar MAY + reject the registration with a response of 423 (Interval Too + Brief). This response MUST contain a Min-Expires header field + that states the minimum expiration interval the registrar is + willing to honor. It then skips the remaining steps. + + Allowing the registrar to set the registration interval + protects it against excessively frequent registration refreshes + while limiting the state that it needs to maintain and + decreasing the likelihood of registrations going stale. The + expiration interval of a registration is frequently used in the + creation of services. An example is a follow-me service, where + the user may only be available at a terminal for a brief + period. Therefore, registrars should accept brief + registrations; a request should only be rejected if the + interval is so short that the refreshes would degrade registrar + performance. + + + +Rosenberg, et. al. Standards Track [Page 65] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + For each address, the registrar then searches the list of + current bindings using the URI comparison rules. If the + binding does not exist, it is tentatively added. If the + binding does exist, the registrar checks the Call-ID value. If + the Call-ID value in the existing binding differs from the + Call-ID value in the request, the binding MUST be removed if + the expiration time is zero and updated otherwise. If they are + the same, the registrar compares the CSeq value. If the value + is higher than that of the existing binding, it MUST update or + remove the binding as above. If not, the update MUST be + aborted and the request fails. + + This algorithm ensures that out-of-order requests from the same + UA are ignored. + + Each binding record records the Call-ID and CSeq values from + the request. + + The binding updates MUST be committed (that is, made visible to + the proxy or redirect server) if and only if all binding + updates and additions succeed. If any one of them fails (for + example, because the back-end database commit failed), the + request MUST fail with a 500 (Server Error) response and all + tentative binding updates MUST be removed. + + 8. The registrar returns a 200 (OK) response. The response MUST + contain Contact header field values enumerating all current + bindings. Each Contact value MUST feature an "expires" + parameter indicating its expiration interval chosen by the + registrar. The response SHOULD include a Date header field. + +11 Querying for Capabilities + + The SIP method OPTIONS allows a UA to query another UA or a proxy + server as to its capabilities. This allows a client to discover + information about the supported methods, content types, extensions, + codecs, etc. without "ringing" the other party. For example, before + a client inserts a Require header field into an INVITE listing an + option that it is not certain the destination UAS supports, the + client can query the destination UAS with an OPTIONS to see if this + option is returned in a Supported header field. All UAs MUST support + the OPTIONS method. + + The target of the OPTIONS request is identified by the Request-URI, + which could identify another UA or a SIP server. If the OPTIONS is + addressed to a proxy server, the Request-URI is set without a user + part, similar to the way a Request-URI is set for a REGISTER request. + + + + +Rosenberg, et. al. Standards Track [Page 66] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Alternatively, a server receiving an OPTIONS request with a Max- + Forwards header field value of 0 MAY respond to the request + regardless of the Request-URI. + + This behavior is common with HTTP/1.1. This behavior can be used + as a "traceroute" functionality to check the capabilities of + individual hop servers by sending a series of OPTIONS requests + with incremented Max-Forwards values. + + As is the case for general UA behavior, the transaction layer can + return a timeout error if the OPTIONS yields no response. This may + indicate that the target is unreachable and hence unavailable. + + An OPTIONS request MAY be sent as part of an established dialog to + query the peer on capabilities that may be utilized later in the + dialog. + +11.1 Construction of OPTIONS Request + + An OPTIONS request is constructed using the standard rules for a SIP + request as discussed in Section 8.1.1. + + A Contact header field MAY be present in an OPTIONS. + + An Accept header field SHOULD be included to indicate the type of + message body the UAC wishes to receive in the response. Typically, + this is set to a format that is used to describe the media + capabilities of a UA, such as SDP (application/sdp). + + The response to an OPTIONS request is assumed to be scoped to the + Request-URI in the original request. However, only when an OPTIONS + is sent as part of an established dialog is it guaranteed that future + requests will be received by the server that generated the OPTIONS + response. + + Example OPTIONS request: + + OPTIONS sip:carol@chicago.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 + Max-Forwards: 70 + To: <sip:carol@chicago.com> + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 63104 OPTIONS + Contact: <sip:alice@pc33.atlanta.com> + Accept: application/sdp + Content-Length: 0 + + + + +Rosenberg, et. al. Standards Track [Page 67] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +11.2 Processing of OPTIONS Request + + The response to an OPTIONS is constructed using the standard rules + for a SIP response as discussed in Section 8.2.6. The response code + chosen MUST be the same that would have been chosen had the request + been an INVITE. That is, a 200 (OK) would be returned if the UAS is + ready to accept a call, a 486 (Busy Here) would be returned if the + UAS is busy, etc. This allows an OPTIONS request to be used to + determine the basic state of a UAS, which can be an indication of + whether the UAS will accept an INVITE request. + + An OPTIONS request received within a dialog generates a 200 (OK) + response that is identical to one constructed outside a dialog and + does not have any impact on the dialog. + + This use of OPTIONS has limitations due to the differences in proxy + handling of OPTIONS and INVITE requests. While a forked INVITE can + result in multiple 200 (OK) responses being returned, a forked + OPTIONS will only result in a single 200 (OK) response, since it is + treated by proxies using the non-INVITE handling. See Section 16.7 + for the normative details. + + If the response to an OPTIONS is generated by a proxy server, the + proxy returns a 200 (OK), listing the capabilities of the server. + The response does not contain a message body. + + Allow, Accept, Accept-Encoding, Accept-Language, and Supported header + fields SHOULD be present in a 200 (OK) response to an OPTIONS + request. If the response is generated by a proxy, the Allow header + field SHOULD be omitted as it is ambiguous since a proxy is method + agnostic. Contact header fields MAY be present in a 200 (OK) + response and have the same semantics as in a 3xx response. That is, + they may list a set of alternative names and methods of reaching the + user. A Warning header field MAY be present. + + A message body MAY be sent, the type of which is determined by the + Accept header field in the OPTIONS request (application/sdp is the + default if the Accept header field is not present). If the types + include one that can describe media capabilities, the UAS SHOULD + include a body in the response for that purpose. Details on the + construction of such a body in the case of application/sdp are + described in [13]. + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 68] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example OPTIONS response generated by a UAS (corresponding to the + request in Section 11.1): + + SIP/2.0 200 OK + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 + ;received=192.0.2.4 + To: <sip:carol@chicago.com>;tag=93810874 + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 63104 OPTIONS + Contact: <sip:carol@chicago.com> + Contact: <mailto:carol@chicago.com> + Allow: INVITE, ACK, CANCEL, OPTIONS, BYE + Accept: application/sdp + Accept-Encoding: gzip + Accept-Language: en + Supported: foo + Content-Type: application/sdp + Content-Length: 274 + + (SDP not shown) + +12 Dialogs + + A key concept for a user agent is that of a dialog. A dialog + represents a peer-to-peer SIP relationship between two user agents + that persists for some time. The dialog facilitates sequencing of + messages between the user agents and proper routing of requests + between both of them. The dialog represents a context in which to + interpret SIP messages. Section 8 discussed method independent UA + processing for requests and responses outside of a dialog. This + section discusses how those requests and responses are used to + construct a dialog, and then how subsequent requests and responses + are sent within a dialog. + + A dialog is identified at each UA with a dialog ID, which consists of + a Call-ID value, a local tag and a remote tag. The dialog ID at each + UA involved in the dialog is not the same. Specifically, the local + tag at one UA is identical to the remote tag at the peer UA. The + tags are opaque tokens that facilitate the generation of unique + dialog IDs. + + A dialog ID is also associated with all responses and with any + request that contains a tag in the To field. The rules for computing + the dialog ID of a message depend on whether the SIP element is a UAC + or UAS. For a UAC, the Call-ID value of the dialog ID is set to the + Call-ID of the message, the remote tag is set to the tag in the To + field of the message, and the local tag is set to the tag in the From + + + +Rosenberg, et. al. Standards Track [Page 69] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + field of the message (these rules apply to both requests and + responses). As one would expect for a UAS, the Call-ID value of the + dialog ID is set to the Call-ID of the message, the remote tag is set + to the tag in the From field of the message, and the local tag is set + to the tag in the To field of the message. + + A dialog contains certain pieces of state needed for further message + transmissions within the dialog. This state consists of the dialog + ID, a local sequence number (used to order requests from the UA to + its peer), a remote sequence number (used to order requests from its + peer to the UA), a local URI, a remote URI, remote target, a boolean + flag called "secure", and a route set, which is an ordered list of + URIs. The route set is the list of servers that need to be traversed + to send a request to the peer. A dialog can also be in the "early" + state, which occurs when it is created with a provisional response, + and then transition to the "confirmed" state when a 2xx final + response arrives. For other responses, or if no response arrives at + all on that dialog, the early dialog terminates. + +12.1 Creation of a Dialog + + Dialogs are created through the generation of non-failure responses + to requests with specific methods. Within this specification, only + 2xx and 101-199 responses with a To tag, where the request was + INVITE, will establish a dialog. A dialog established by a non-final + response to a request is in the "early" state and it is called an + early dialog. Extensions MAY define other means for creating + dialogs. Section 13 gives more details that are specific to the + INVITE method. Here, we describe the process for creation of dialog + state that is not dependent on the method. + + UAs MUST assign values to the dialog ID components as described + below. + +12.1.1 UAS behavior + + When a UAS responds to a request with a response that establishes a + dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route + header field values from the request into the response (including the + URIs, URI parameters, and any Record-Route header field parameters, + whether they are known or unknown to the UAS) and MUST maintain the + order of those values. The UAS MUST add a Contact header field to + the response. The Contact header field contains an address where the + UAS would like to be contacted for subsequent requests in the dialog + (which includes the ACK for a 2xx response in the case of an INVITE). + Generally, the host portion of this URI is the IP address or FQDN of + the host. The URI provided in the Contact header field MUST be a SIP + or SIPS URI. If the request that initiated the dialog contained a + + + +Rosenberg, et. al. Standards Track [Page 70] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + SIPS URI in the Request-URI or in the top Record-Route header field + value, if there was any, or the Contact header field if there was no + Record-Route header field, the Contact header field in the response + MUST be a SIPS URI. The URI SHOULD have global scope (that is, the + same URI can be used in messages outside this dialog). The same way, + the scope of the URI in the Contact header field of the INVITE is not + limited to this dialog either. It can therefore be used in messages + to the UAC even outside this dialog. + + The UAS then constructs the state of the dialog. This state MUST be + maintained for the duration of the dialog. + + If the request arrived over TLS, and the Request-URI contained a SIPS + URI, the "secure" flag is set to TRUE. + + The route set MUST be set to the list of URIs in the Record-Route + header field from the request, taken in order and preserving all URI + parameters. If no Record-Route header field is present in the + request, the route set MUST be set to the empty set. This route set, + even if empty, overrides any pre-existing route set for future + requests in this dialog. The remote target MUST be set to the URI + from the Contact header field of the request. + + The remote sequence number MUST be set to the value of the sequence + number in the CSeq header field of the request. The local sequence + number MUST be empty. The call identifier component of the dialog ID + MUST be set to the value of the Call-ID in the request. The local + tag component of the dialog ID MUST be set to the tag in the To field + in the response to the request (which always includes a tag), and the + remote tag component of the dialog ID MUST be set to the tag from the + From field in the request. A UAS MUST be prepared to receive a + request without a tag in the From field, in which case the tag is + considered to have a value of null. + + This is to maintain backwards compatibility with RFC 2543, which + did not mandate From tags. + + The remote URI MUST be set to the URI in the From field, and the + local URI MUST be set to the URI in the To field. + +12.1.2 UAC Behavior + + When a UAC sends a request that can establish a dialog (such as an + INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., + the same SIP URI can be used in messages outside this dialog) in the + Contact header field of the request. If the request has a Request- + URI or a topmost Route header field value with a SIPS URI, the + Contact header field MUST contain a SIPS URI. + + + +Rosenberg, et. al. Standards Track [Page 71] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + When a UAC receives a response that establishes a dialog, it + constructs the state of the dialog. This state MUST be maintained + for the duration of the dialog. + + If the request was sent over TLS, and the Request-URI contained a + SIPS URI, the "secure" flag is set to TRUE. + + The route set MUST be set to the list of URIs in the Record-Route + header field from the response, taken in reverse order and preserving + all URI parameters. If no Record-Route header field is present in + the response, the route set MUST be set to the empty set. This route + set, even if empty, overrides any pre-existing route set for future + requests in this dialog. The remote target MUST be set to the URI + from the Contact header field of the response. + + The local sequence number MUST be set to the value of the sequence + number in the CSeq header field of the request. The remote sequence + number MUST be empty (it is established when the remote UA sends a + request within the dialog). The call identifier component of the + dialog ID MUST be set to the value of the Call-ID in the request. + The local tag component of the dialog ID MUST be set to the tag in + the From field in the request, and the remote tag component of the + dialog ID MUST be set to the tag in the To field of the response. A + UAC MUST be prepared to receive a response without a tag in the To + field, in which case the tag is considered to have a value of null. + + This is to maintain backwards compatibility with RFC 2543, which + did not mandate To tags. + + The remote URI MUST be set to the URI in the To field, and the local + URI MUST be set to the URI in the From field. + +12.2 Requests within a Dialog + + Once a dialog has been established between two UAs, either of them + MAY initiate new transactions as needed within the dialog. The UA + sending the request will take the UAC role for the transaction. The + UA receiving the request will take the UAS role. Note that these may + be different roles than the UAs held during the transaction that + established the dialog. + + Requests within a dialog MAY contain Record-Route and Contact header + fields. However, these requests do not cause the dialog's route set + to be modified, although they may modify the remote target URI. + Specifically, requests that are not target refresh requests do not + modify the dialog's remote target URI, and requests that are target + refresh requests do. For dialogs that have been established with an + + + + +Rosenberg, et. al. Standards Track [Page 72] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + INVITE, the only target refresh request defined is re-INVITE (see + Section 14). Other extensions may define different target refresh + requests for dialogs established in other ways. + + Note that an ACK is NOT a target refresh request. + + Target refresh requests only update the dialog's remote target URI, + and not the route set formed from the Record-Route. Updating the + latter would introduce severe backwards compatibility problems with + RFC 2543-compliant systems. + +12.2.1 UAC Behavior + +12.2.1.1 Generating the Request + + A request within a dialog is constructed by using many of the + components of the state stored as part of the dialog. + + The URI in the To field of the request MUST be set to the remote URI + from the dialog state. The tag in the To header field of the request + MUST be set to the remote tag of the dialog ID. The From URI of the + request MUST be set to the local URI from the dialog state. The tag + in the From header field of the request MUST be set to the local tag + of the dialog ID. If the value of the remote or local tags is null, + the tag parameter MUST be omitted from the To or From header fields, + respectively. + + Usage of the URI from the To and From fields in the original + request within subsequent requests is done for backwards + compatibility with RFC 2543, which used the URI for dialog + identification. In this specification, only the tags are used for + dialog identification. It is expected that mandatory reflection + of the original To and From URI in mid-dialog requests will be + deprecated in a subsequent revision of this specification. + + The Call-ID of the request MUST be set to the Call-ID of the dialog. + Requests within a dialog MUST contain strictly monotonically + increasing and contiguous CSeq sequence numbers (increasing-by-one) + in each direction (excepting ACK and CANCEL of course, whose numbers + equal the requests being acknowledged or cancelled). Therefore, if + the local sequence number is not empty, the value of the local + sequence number MUST be incremented by one, and this value MUST be + placed into the CSeq header field. If the local sequence number is + empty, an initial value MUST be chosen using the guidelines of + Section 8.1.1.5. The method field in the CSeq header field value + MUST match the method of the request. + + + + + +Rosenberg, et. al. Standards Track [Page 73] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + With a length of 32 bits, a client 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 clients to use a time- + based initial sequence number. A client could, for example, + choose the 31 most significant bits of a 32-bit second clock as an + initial sequence number. + + The UAC uses the remote target and route set to build the Request-URI + and Route header field of the request. + + If the route set is empty, the UAC MUST place the remote target URI + into the Request-URI. The UAC MUST NOT add a Route header field to + the request. + + If the route set is not empty, and the first URI in the route set + contains the lr parameter (see Section 19.1.1), the UAC MUST place + the remote target URI into the Request-URI and MUST include a Route + header field containing the route set values in order, including all + parameters. + + If the route set is not empty, and its first URI does not contain the + lr parameter, the UAC MUST place the first URI from the route set + into the Request-URI, stripping any parameters that are not allowed + in a Request-URI. The UAC MUST add a Route header field containing + the remainder of the route set values in order, including all + parameters. The UAC MUST then place the remote target URI into the + Route header field as the last value. + + For example, if the remote target is sip:user@remoteua and the route + set contains: + + <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> + + The request will be formed with the following Request-URI and Route + header field: + + METHOD sip:proxy1 + Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> + + If the first URI of the route set does not contain the lr + parameter, the proxy indicated does not understand the routing + mechanisms described in this document and will act as specified in + RFC 2543, replacing the Request-URI with the first Route header + field value it receives while forwarding the message. Placing the + Request-URI at the end of the Route header field preserves the + + + + +Rosenberg, et. al. Standards Track [Page 74] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + information in that Request-URI across the strict router (it will + be returned to the Request-URI when the request reaches a loose- + router). + + A UAC SHOULD include a Contact header field in any target refresh + requests within a dialog, and unless there is a need to change it, + the URI SHOULD be the same as used in previous requests within the + dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. + As discussed in Section 12.2.2, a Contact header field in a target + refresh request updates the remote target URI. This allows a UA to + provide a new contact address, should its address change during the + duration of the dialog. + + However, requests that are not target refresh requests do not affect + the remote target URI for the dialog. + + The rest of the request is formed as described in Section 8.1.1. + + Once the request has been constructed, the address of the server is + computed and the request is sent, using the same procedures for + requests outside of a dialog (Section 8.1.2). + + The procedures in Section 8.1.2 will normally result in the + request being sent to the address indicated by the topmost Route + header field value or the Request-URI if no Route header field is + present. Subject to certain restrictions, they allow the request + to be sent to an alternate address (such as a default outbound + proxy not represented in the route set). + +12.2.1.2 Processing the Responses + + The UAC will receive responses to the request from the transaction + layer. If the client transaction returns a timeout, this is treated + as a 408 (Request Timeout) response. + + The behavior of a UAC that receives a 3xx response for a request sent + within a dialog is the same as if the request had been sent outside a + dialog. This behavior is described in Section 8.1.3.4. + + Note, however, that when the UAC tries alternative locations, it + still uses the route set for the dialog to build the Route header + of the request. + + When a UAC receives a 2xx response to a target refresh request, it + MUST replace the dialog's remote target URI with the URI from the + Contact header field in that response, if present. + + + + + +Rosenberg, et. al. Standards Track [Page 75] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If the response for a request within a dialog is a 481 + (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC + SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if + no response at all is received for the request (the client + transaction would inform the TU about the timeout.) + + For INVITE initiated dialogs, terminating the dialog consists of + sending a BYE. + +12.2.2 UAS Behavior + + Requests sent within a dialog, as any other requests, are atomic. If + a particular request is accepted by the UAS, all the state changes + associated with it are performed. If the request is rejected, none + of the state changes are performed. + + Note that some requests, such as INVITEs, affect several pieces of + state. + + The UAS will receive the request from the transaction layer. If the + request has a tag in the To header field, the UAS core computes the + dialog identifier corresponding to the request and compares it with + existing dialogs. If there is a match, this is a mid-dialog request. + In that case, the UAS first applies the same processing rules for + requests outside of a dialog, discussed in Section 8.2. + + If the request has a tag in the To header field, but the dialog + identifier does not match any existing dialogs, the UAS may have + crashed and restarted, or it may have received a request for a + different (possibly failed) UAS (the UASs can construct the To tags + so that a UAS can identify that the tag was for a UAS for which it is + providing recovery). Another possibility is that the incoming + request has been simply misrouted. Based on the To tag, the UAS MAY + either accept or reject the request. Accepting the request for + acceptable To tags provides robustness, so that dialogs can persist + even through crashes. UAs wishing to support this capability must + take into consideration some issues such as choosing monotonically + increasing CSeq sequence numbers even across reboots, reconstructing + the route set, and accepting out-of-range RTP timestamps and sequence + numbers. + + If the UAS wishes to reject the request because it does not wish to + recreate the dialog, it MUST respond to the request with a 481 + (Call/Transaction Does Not Exist) status code and pass that to the + server transaction. + + + + + + +Rosenberg, et. al. Standards Track [Page 76] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Requests that do not change in any way the state of a dialog may be + received within a dialog (for example, an OPTIONS request). They are + processed as if they had been received outside the dialog. + + If the remote sequence number is empty, it MUST be set to the value + of the sequence number in the CSeq header field value in the request. + If the remote sequence number was not empty, but the sequence number + of the request is lower than the remote sequence number, the request + is out of order and MUST be rejected with a 500 (Server Internal + Error) response. If the remote sequence number was not empty, and + the sequence number of the request is greater than the remote + sequence number, the request is in order. It is possible for the + CSeq sequence number to be higher than the remote sequence number by + more than one. This is not an error condition, and a UAS SHOULD be + prepared to receive and process requests with CSeq values more than + one higher than the previous received request. The UAS MUST then set + the remote sequence number to the value of the sequence number in the + CSeq header field value in the request. + + If a proxy challenges a request generated by the UAC, the UAC has + to resubmit the request with credentials. The resubmitted request + will have a new CSeq number. The UAS will never see the first + request, and thus, it will notice a gap in the CSeq number space. + Such a gap does not represent any error condition. + + When a UAS receives a target refresh request, it MUST replace the + dialog's remote target URI with the URI from the Contact header field + in that request, if present. + +12.3 Termination of a Dialog + + Independent of the method, if a request outside of a dialog generates + a non-2xx final response, any early dialogs created through + provisional responses to that request are terminated. The mechanism + for terminating confirmed dialogs is method specific. In this + specification, the BYE method terminates a session and the dialog + associated with it. See Section 15 for details. + +13 Initiating a Session + +13.1 Overview + + When a user agent client desires to initiate a session (for example, + audio, video, or a game), it formulates an INVITE request. The + INVITE request asks a server to establish a session. This request + may be forwarded by proxies, eventually arriving at one or more UAS + that can potentially accept the invitation. These UASs will + frequently need to query the user about whether to accept the + + + +Rosenberg, et. al. Standards Track [Page 77] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + invitation. After some time, those UASs can accept the invitation + (meaning the session is to be established) by sending a 2xx response. + If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is + sent, depending on the reason for the rejection. Before sending a + final response, the UAS can also send provisional responses (1xx) to + advise the UAC of progress in contacting the called user. + + After possibly receiving one or more provisional responses, the UAC + will get one or more 2xx responses or one non-2xx final response. + Because of the protracted amount of time it can take to receive final + responses to INVITE, the reliability mechanisms for INVITE + transactions differ from those of other requests (like OPTIONS). + Once it receives a final response, the UAC needs to send an ACK for + every final response it receives. The procedure for sending this ACK + depends on the type of response. For final responses between 300 and + 699, the ACK processing is done in the transaction layer and follows + one set of rules (See Section 17). For 2xx responses, the ACK is + generated by the UAC core. + + A 2xx response to an INVITE establishes a session, and it also + creates a dialog between the UA that issued the INVITE and the UA + that generated the 2xx response. Therefore, when multiple 2xx + responses are received from different remote UAs (because the INVITE + forked), each 2xx establishes a different dialog. All these dialogs + are part of the same call. + + This section provides details on the establishment of a session using + INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and + BYE. + +13.2 UAC Processing + +13.2.1 Creating the Initial INVITE + + Since the initial INVITE represents a request outside of a dialog, + its construction follows the procedures of Section 8.1.1. Additional + processing is required for the specific case of INVITE. + + An Allow header field (Section 20.5) SHOULD be present in the INVITE. + It indicates what methods can be invoked within a dialog, on the UA + sending the INVITE, for the duration of the dialog. For example, a + UA capable of receiving INFO requests within a dialog [34] SHOULD + include an Allow header field listing the INFO method. + + A Supported header field (Section 20.37) SHOULD be present in the + INVITE. It enumerates all the extensions understood by the UAC. + + + + + +Rosenberg, et. al. Standards Track [Page 78] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + An Accept (Section 20.1) header field MAY be present in the INVITE. + It indicates which Content-Types are acceptable to the UA, in both + the response received by it, and in any subsequent requests sent to + it within dialogs established by the INVITE. The Accept header field + is especially useful for indicating support of various session + description formats. + + The UAC MAY add an Expires header field (Section 20.19) to limit the + validity of the invitation. If the time indicated in the Expires + header field is reached and no final answer for the INVITE has been + received, the UAC core SHOULD generate a CANCEL request for the + INVITE, as per Section 9. + + A UAC MAY also find it useful to add, among others, Subject (Section + 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) + header fields. They all contain information related to the INVITE. + + The UAC MAY choose to add a message body to the INVITE. Section + 8.1.1.10 deals with how to construct the header fields -- Content- + Type among others -- needed to describe the message body. + + There are special rules for message bodies that contain a session + description - their corresponding Content-Disposition is "session". + SIP uses an offer/answer model where one UA sends a session + description, called the offer, which contains a proposed description + of the session. The offer indicates the desired communications means + (audio, video, games), parameters of those means (such as codec + types) and addresses for receiving media from the answerer. The + other UA responds with another session description, called the + answer, which indicates which communications means are accepted, the + parameters that apply to those means, and addresses for receiving + media from the offerer. An offer/answer exchange is within the + context of a dialog, so that if a SIP INVITE results in multiple + dialogs, each is a separate offer/answer exchange. The offer/answer + model defines restrictions on when offers and answers can be made + (for example, you cannot make a new offer while one is in progress). + This results in restrictions on where the offers and answers can + appear in SIP messages. In this specification, offers and answers + can only appear in INVITE requests and responses, and ACK. The usage + of offers and answers is further restricted. For the initial INVITE + transaction, the rules are: + + o The initial offer MUST be in either an INVITE or, if not there, + in the first reliable non-failure message from the UAS back to + the UAC. In this specification, that is the final 2xx + response. + + + + + +Rosenberg, et. al. Standards Track [Page 79] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o If the initial offer is in an INVITE, the answer MUST be in a + reliable non-failure message from UAS back to UAC which is + correlated to that INVITE. For this specification, that is + only the final 2xx response to that INVITE. That same exact + answer MAY also be placed in any provisional responses sent + prior to the answer. The UAC MUST treat the first session + description it receives as the answer, and MUST ignore any + session descriptions in subsequent responses to the initial + INVITE. + + o If the initial offer is in the first reliable non-failure + message from the UAS back to UAC, the answer MUST be in the + acknowledgement for that message (in this specification, ACK + for a 2xx response). + + o After having sent or received an answer to the first offer, the + UAC MAY generate subsequent offers in requests based on rules + specified for that method, but only if it has received answers + to any previous offers, and has not sent any offers to which it + hasn't gotten an answer. + + o Once the UAS has sent or received an answer to the initial + offer, it MUST NOT generate subsequent offers in any responses + to the initial INVITE. This means that a UAS based on this + specification alone can never generate subsequent offers until + completion of the initial transaction. + + Concretely, the above rules specify two exchanges for UAs compliant + to this specification alone - the offer is in the INVITE, and the + answer in the 2xx (and possibly in a 1xx as well, with the same + value), or the offer is in the 2xx, and the answer is in the ACK. + All user agents that support INVITE MUST support these two exchanges. + + The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be + supported by all user agents as a means to describe sessions, and its + usage for constructing offers and answers MUST follow the procedures + defined in [13]. + + The restrictions of the offer-answer model just described only apply + to bodies whose Content-Disposition header field value is "session". + Therefore, it is possible that both the INVITE and the ACK contain a + body message (for example, the INVITE carries a photo (Content- + Disposition: render) and the ACK a session description (Content- + Disposition: session)). + + If the Content-Disposition header field is missing, bodies of + Content-Type application/sdp imply the disposition "session", while + other content types imply "render". + + + +Rosenberg, et. al. Standards Track [Page 80] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Once the INVITE has been created, the UAC follows the procedures + defined for sending requests outside of a dialog (Section 8). This + results in the construction of a client transaction that will + ultimately send the request and deliver responses to the UAC. + +13.2.2 Processing INVITE Responses + + Once the INVITE has been passed to the INVITE client transaction, the + UAC waits for responses for the INVITE. If the INVITE client + transaction returns a timeout rather than a response the TU acts as + if a 408 (Request Timeout) response had been received, as described + in Section 8.1.3. + +13.2.2.1 1xx Responses + + Zero, one or multiple provisional responses may arrive before one or + more final responses are received. Provisional responses for an + INVITE request can create "early dialogs". If a provisional response + has a tag in the To field, and if the dialog ID of the response does + not match an existing dialog, one is constructed using the procedures + defined in Section 12.1.2. + + The early dialog will only be needed if the UAC needs to send a + request to its peer within the dialog before the initial INVITE + transaction completes. Header fields present in a provisional + response are applicable as long as the dialog is in the early state + (for example, an Allow header field in a provisional response + contains the methods that can be used in the dialog while this is in + the early state). + +13.2.2.2 3xx Responses + + A 3xx response may contain one or more Contact header field values + providing new addresses where the callee might be reachable. + Depending on the status code of the 3xx response (see Section 21.3), + the UAC MAY choose to try those new addresses. + +13.2.2.3 4xx, 5xx and 6xx Responses + + A single non-2xx final response may be received for the INVITE. 4xx, + 5xx and 6xx responses may contain a Contact header field value + indicating the location where additional information about the error + can be found. Subsequent final responses (which would only arrive + under error conditions) MUST be ignored. + + All early dialogs are considered terminated upon reception of the + non-2xx final response. + + + + +Rosenberg, et. al. Standards Track [Page 81] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + After having received the non-2xx final response the UAC core + considers the INVITE transaction completed. The INVITE client + transaction handles the generation of ACKs for the response (see + Section 17). + +13.2.2.4 2xx Responses + + Multiple 2xx 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 dialog, with a distinct dialog identifier. + + If the dialog identifier in the 2xx response matches the dialog + identifier of an existing dialog, the dialog MUST be transitioned to + the "confirmed" state, and the route set for the dialog MUST be + recomputed based on the 2xx response using the procedures of Section + 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be + constructed using the procedures of Section 12.1.2. + + Note that the only piece of state that is recomputed is the route + set. Other pieces of state such as the highest sequence numbers + (remote and local) sent within the dialog are not recomputed. The + route set only is recomputed for backwards compatibility. RFC + 2543 did not mandate mirroring of the Record-Route header field in + a 1xx, only 2xx. However, we cannot update the entire state of + the dialog, since mid-dialog requests may have been sent within + the early dialog, modifying the sequence numbers, for example. + + The UAC core MUST generate an ACK request for each 2xx received from + the transaction layer. The header fields of the ACK are constructed + in the same way as for any request sent within a dialog (see Section + 12) with the exception of the CSeq and the header fields related to + authentication. The sequence number of the CSeq header field MUST be + the same as the INVITE being acknowledged, but the CSeq method MUST + be ACK. The ACK MUST contain the same credentials as the INVITE. If + the 2xx contains an offer (based on the rules above), the ACK MUST + carry an answer in its body. If the offer in the 2xx response is not + acceptable, the UAC core MUST generate a valid answer in the ACK and + then send a BYE immediately. + + Once the ACK has been constructed, the procedures of [4] are used to + determine the destination address, port and transport. However, the + request is passed to the transport layer directly for transmission, + rather than a client transaction. This is because the UAC core + handles retransmissions of the ACK, not the transaction layer. The + ACK MUST be passed to the client transport every time a + retransmission of the 2xx final response that triggered the ACK + arrives. + + + +Rosenberg, et. al. Standards Track [Page 82] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The UAC core considers the INVITE transaction completed 64*T1 seconds + after the reception of the first 2xx response. At this point all the + early dialogs that have not transitioned to established dialogs are + terminated. Once the INVITE transaction is considered completed by + the UAC core, no more new 2xx responses are expected to arrive. + + If, after acknowledging any 2xx response to an INVITE, the UAC does + not want to continue with that dialog, then the UAC MUST terminate + the dialog by sending a BYE request as described in Section 15. + +13.3 UAS Processing + +13.3.1 Processing of the INVITE + + The UAS core will receive INVITE requests from the transaction layer. + It first performs the request processing procedures of Section 8.2, + which are applied for both requests inside and outside of a dialog. + + Assuming these processing states are completed without generating a + response, the UAS core performs the additional processing steps: + + 1. If the request is an INVITE that contains an Expires header + field, the UAS core sets a timer for the number of seconds + indicated in the header field value. When the timer fires, the + invitation is considered to be expired. If the invitation + expires before the UAS has generated a final response, a 487 + (Request Terminated) response SHOULD be generated. + + 2. If the request is a mid-dialog request, the method-independent + processing described in Section 12.2.2 is first applied. It + might also modify the session; Section 14 provides details. + + 3. If the request has a tag in the To header field but the dialog + identifier does not match any of the existing dialogs, the UAS + may have crashed and restarted, or may have received a request + for a different (possibly failed) UAS. Section 12.2.2 provides + guidelines to achieve a robust behavior under such a situation. + + Processing from here forward assumes that the INVITE is outside of a + dialog, and is thus for the purposes of establishing a new session. + + The INVITE may contain a session description, in which case the UAS + is being presented with an offer for that session. It is possible + that the user is already a participant in that session, even though + the INVITE is outside of a dialog. This can happen when a user is + invited to the same multicast conference by multiple other + participants. If desired, the UAS MAY use identifiers within the + session description to detect this duplication. For example, SDP + + + +Rosenberg, et. al. Standards Track [Page 83] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + contains a session id and version number in the origin (o) field. If + the user is already a member of the session, and the session + parameters contained in the session description have not changed, the + UAS MAY silently accept the INVITE (that is, send a 2xx response + without prompting the user). + + If the INVITE does not contain a session description, the UAS is + being asked to participate in a session, and the UAC has asked that + the UAS provide the offer of the session. It MUST provide the offer + in its first non-failure reliable message back to the UAC. In this + specification, that is a 2xx response to the INVITE. + + The UAS can indicate progress, accept, redirect, or reject the + invitation. In all of these cases, it formulates a response using + the procedures described in Section 8.2.6. + +13.3.1.1 Progress + + If the UAS is not able to answer the invitation immediately, it can + choose to indicate some kind of progress to the UAC (for example, an + indication that a phone is ringing). This is accomplished with a + provisional response between 101 and 199. These provisional + responses establish early dialogs and therefore follow the procedures + of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY + send as many provisional responses as it likes. Each of these MUST + indicate the same dialog ID. However, these will not be delivered + reliably. + + If the UAS desires an extended period of time to answer the INVITE, + it will need to ask for an "extension" in order to prevent proxies + from canceling the transaction. A proxy has the option of canceling + a transaction when there is a gap of 3 minutes between responses in a + transaction. To prevent cancellation, the UAS MUST send a non-100 + provisional response at every minute, to handle the possibility of + lost provisional responses. + + An INVITE transaction can go on for extended durations when the + user is placed on hold, or when interworking with PSTN systems + which allow communications to take place without answering the + call. The latter is common in Interactive Voice Response (IVR) + systems. + +13.3.1.2 The INVITE is Redirected + + If the UAS decides to redirect the call, a 3xx response is sent. A + 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved + Temporarily) response SHOULD contain a Contact header field + + + + +Rosenberg, et. al. Standards Track [Page 84] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + containing one or more URIs of new addresses to be tried. The + response is passed to the INVITE server transaction, which will deal + with its retransmissions. + +13.3.1.3 The INVITE is Rejected + + A common scenario occurs when the callee is currently not willing or + able to take additional calls at this end system. A 486 (Busy Here) + SHOULD be returned in such a scenario. If the UAS knows that no + other end system will be able to accept this call, a 600 (Busy + Everywhere) response SHOULD be sent instead. However, it is unlikely + that a UAS will be able to know this in general, and thus this + response will not usually be used. The response is passed to the + INVITE server transaction, which will deal with its retransmissions. + + A UAS rejecting an offer contained in an INVITE SHOULD return a 488 + (Not Acceptable Here) response. Such a response SHOULD include a + Warning header field value explaining why the offer was rejected. + +13.3.1.4 The INVITE is Accepted + + The UAS core generates a 2xx response. This response establishes a + dialog, and therefore follows the procedures of Section 12.1.1 in + addition to those of Section 8.2.6. + + A 2xx response to an INVITE SHOULD contain the Allow header field and + the Supported header field, and MAY contain the Accept header field. + Including these header fields allows the UAC to determine the + features and extensions supported by the UAS for the duration of the + call, without probing. + + If the INVITE request contained an offer, and the UAS had not yet + sent an answer, the 2xx MUST contain an answer. If the INVITE did + not contain an offer, the 2xx MUST contain an offer if the UAS had + not yet sent an offer. + + Once the response has been constructed, it is passed to the INVITE + server transaction. Note, however, that the INVITE server + transaction will be destroyed as soon as it receives this final + response and passes it to the transport. Therefore, it is necessary + to periodically pass the response directly to the transport until the + ACK arrives. The 2xx response is passed to the transport with an + interval that starts at T1 seconds and doubles for each + retransmission until it reaches T2 seconds (T1 and T2 are defined in + Section 17). Response retransmissions cease when an ACK request for + the response is received. This is independent of whatever transport + protocols are used to send the response. + + + + +Rosenberg, et. al. Standards Track [Page 85] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Since 2xx is retransmitted end-to-end, there may be hops between + UAS and UAC that are UDP. To ensure reliable delivery across + these hops, the response is retransmitted periodically even if the + transport at the UAS is reliable. + + If the server retransmits the 2xx response for 64*T1 seconds without + receiving an ACK, the dialog is confirmed, but the session SHOULD be + terminated. This is accomplished with a BYE, as described in Section + 15. + +14 Modifying an Existing Session + + A successful INVITE request (see Section 13) establishes both a + dialog between two user agents and a session using the offer-answer + model. Section 12 explains how to modify an existing dialog using a + target refresh request (for example, changing the remote target URI + of the dialog). This section describes how to modify the actual + session. This modification can involve changing addresses or ports, + adding a media stream, deleting a media stream, and so on. This is + accomplished by sending a new INVITE request within the same dialog + that established the session. An INVITE request sent within an + existing dialog is known as a re-INVITE. + + Note that a single re-INVITE can modify the dialog and the + parameters of the session at the same time. + + Either the caller or callee can modify an existing session. + + The behavior of a UA on detection of media failure is a matter of + local policy. However, automated generation of re-INVITE or BYE is + NOT RECOMMENDED to avoid flooding the network with traffic when there + is congestion. In any case, if these messages are sent + automatically, they SHOULD be sent after some randomized interval. + + Note that the paragraph above refers to automatically generated + BYEs and re-INVITEs. If the user hangs up upon media failure, the + UA would send a BYE request as usual. + +14.1 UAC Behavior + + The same offer-answer model that applies to session descriptions in + INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC + that wants to add a media stream, for example, will create a new + offer that contains this media stream, and send that in an INVITE + request to its peer. It is important to note that the full + description of the session, not just the change, is sent. This + supports stateless session processing in various elements, and + supports failover and recovery capabilities. Of course, a UAC MAY + + + +Rosenberg, et. al. Standards Track [Page 86] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + send a re-INVITE with no session description, in which case the first + reliable non-failure response to the re-INVITE will contain the offer + (in this specification, that is a 2xx response). + + If the session description format has the capability for version + numbers, the offerer SHOULD indicate that the version of the session + description has changed. + + The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set + following the same rules as for regular requests within an existing + dialog, described in Section 12. + + A UAC MAY choose not to add an Alert-Info header field or a body with + Content-Disposition "alert" to re-INVITEs because UASs do not + typically alert the user upon reception of a re-INVITE. + + Unlike an INVITE, which can fork, a re-INVITE will never fork, and + therefore, only ever generate a single final response. The reason a + re-INVITE will never fork is that the Request-URI identifies the + target as the UA instance it established the dialog with, rather than + identifying an address-of-record for the user. + + Note that a UAC MUST NOT initiate a new INVITE transaction within a + dialog while another INVITE transaction is in progress in either + direction. + + 1. If there is an ongoing INVITE client transaction, the TU MUST + wait until the transaction reaches the completed or terminated + state before initiating the new INVITE. + + 2. If there is an ongoing INVITE server transaction, the TU MUST + wait until the transaction reaches the confirmed or terminated + state before initiating the new INVITE. + + However, a UA MAY initiate a regular transaction while an INVITE + transaction is in progress. A UA MAY also initiate an INVITE + transaction while a regular transaction is in progress. + + If a UA receives a non-2xx final response to a re-INVITE, the session + parameters MUST remain unchanged, as if no re-INVITE had been issued. + Note that, as stated in Section 12.2.1.2, if the non-2xx final + response is a 481 (Call/Transaction Does Not Exist), or a 408 + (Request Timeout), or no response at all is received for the re- + INVITE (that is, a timeout is returned by the INVITE client + transaction), the UAC will terminate the dialog. + + + + + + +Rosenberg, et. al. Standards Track [Page 87] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If a UAC receives a 491 response to a re-INVITE, it SHOULD start a + timer with a value T chosen as follows: + + 1. If the UAC is the owner of the Call-ID of the dialog ID + (meaning it generated the value), T has a randomly chosen value + between 2.1 and 4 seconds in units of 10 ms. + + 2. If the UAC is not the owner of the Call-ID of the dialog ID, T + has a randomly chosen value of between 0 and 2 seconds in units + of 10 ms. + + When the timer fires, the UAC SHOULD attempt the re-INVITE once more, + if it still desires for that session modification to take place. For + example, if the call was already hung up with a BYE, the re-INVITE + would not take place. + + The rules for transmitting a re-INVITE and for generating an ACK for + a 2xx response to re-INVITE are the same as for the initial INVITE + (Section 13.2.1). + +14.2 UAS Behavior + + Section 13.3.1 describes the procedure for distinguishing incoming + re-INVITEs from incoming initial INVITEs and handling a re-INVITE for + an existing dialog. + + A UAS that receives a second INVITE before it sends the final + response to a first INVITE with a lower CSeq sequence number on the + same dialog MUST return a 500 (Server Internal Error) response to the + second INVITE and MUST include a Retry-After header field with a + randomly chosen value of between 0 and 10 seconds. + + A UAS that receives an INVITE on a dialog while an INVITE it had sent + on that dialog is in progress MUST return a 491 (Request Pending) + response to the received INVITE. + + If a UA receives a re-INVITE for an existing dialog, 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. If the session description has changed, the UAS + 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. + + + + + +Rosenberg, et. al. Standards Track [Page 88] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If the new session description is not acceptable, the UAS can reject + it by returning a 488 (Not Acceptable Here) response for the re- + INVITE. This response SHOULD include a Warning header field. + + If a UAS generates a 2xx response and never receives an ACK, it + SHOULD generate a BYE to terminate the dialog. + + A UAS MAY choose not to generate 180 (Ringing) responses for a re- + INVITE because UACs do not typically render this information to the + user. For the same reason, UASs MAY choose not to use an Alert-Info + header field or a body with Content-Disposition "alert" in responses + to a re-INVITE. + + A UAS providing an offer in a 2xx (because the INVITE did not contain + an offer) SHOULD construct the offer as if the UAS were making a + brand new call, subject to the constraints of sending an offer that + updates an existing session, as described in [13] in the case of SDP. + Specifically, this means that it SHOULD include as many media formats + and media types that the UA is willing to support. The UAS MUST + ensure that the session description overlaps with its previous + session description in media formats, transports, or other parameters + that require support from the peer. This is to avoid the need for + the peer to reject the session description. If, however, it is + unacceptable to the UAC, the UAC SHOULD generate an answer with a + valid session description, and then send a BYE to terminate the + session. + +15 Terminating a Session + + This section describes the procedures for terminating a session + established by SIP. The state of the session and the state of the + dialog are very closely related. When a session is initiated with an + INVITE, each 1xx or 2xx response from a distinct UAS creates a + dialog, and if that response completes the offer/answer exchange, it + also creates a session. As a result, each session is "associated" + with a single dialog - the one which resulted in its creation. If an + initial INVITE generates a non-2xx final response, that terminates + all sessions (if any) and all dialogs (if any) that were created + through responses to the request. By virtue of completing the + transaction, a non-2xx final response also prevents further sessions + from being created as a result of the INVITE. The BYE request is + used to terminate a specific session or attempted session. In this + case, the specific session is the one with the peer UA on the other + side of the dialog. When a BYE is received on a dialog, any session + associated with that dialog SHOULD terminate. A UA MUST NOT send a + BYE outside of a dialog. The caller's UA MAY send a BYE for either + confirmed or early dialogs, and the callee's UA MAY send a BYE on + confirmed dialogs, but MUST NOT send a BYE on early dialogs. + + + +Rosenberg, et. al. Standards Track [Page 89] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + However, the callee's UA MUST NOT send a BYE on a confirmed dialog + until it has received an ACK for its 2xx response or until the server + transaction times out. If no SIP extensions have defined other + application layer states associated with the dialog, the BYE also + terminates the dialog. + + The impact of a non-2xx final response to INVITE on dialogs and + sessions makes the use of CANCEL attractive. The CANCEL attempts to + force a non-2xx response to the INVITE (in particular, a 487). + Therefore, if a UAC wishes to give up on its call attempt entirely, + it can send a CANCEL. If the INVITE results in 2xx final response(s) + to the INVITE, this means that a UAS accepted the invitation while + the CANCEL was in progress. The UAC MAY continue with the sessions + established by any 2xx responses, or MAY terminate them with BYE. + + The notion of "hanging up" is not well defined within SIP. It is + specific to a particular, albeit common, user interface. + Typically, when the user hangs up, it indicates a desire to + terminate the attempt to establish a session, and to terminate any + sessions already created. For the caller's UA, this would imply a + CANCEL request if the initial INVITE has not generated a final + response, and a BYE to all confirmed dialogs after a final + response. For the callee's UA, it would typically imply a BYE; + presumably, when the user picked up the phone, a 2xx was + generated, and so hanging up would result in a BYE after the ACK + is received. This does not mean a user cannot hang up before + receipt of the ACK, it just means that the software in his phone + needs to maintain state for a short while in order to clean up + properly. If the particular UI allows for the user to reject a + call before its answered, a 403 (Forbidden) is a good way to + express that. As per the rules above, a BYE can't be sent. + +15.1 Terminating a Session with a BYE Request + +15.1.1 UAC Behavior + + A BYE request is constructed as would any other request within a + dialog, as described in Section 12. + + Once the BYE is constructed, the UAC core creates a new non-INVITE + client transaction, and passes it the BYE request. The UAC MUST + consider the session terminated (and therefore stop sending or + listening for media) as soon as the BYE request is passed to the + client transaction. If the response for the BYE is a 481 + (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no + + + + + + +Rosenberg, et. al. Standards Track [Page 90] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + response at all is received for the BYE (that is, a timeout is + returned by the client transaction), the UAC MUST consider the + session and the dialog terminated. + +15.1.2 UAS Behavior + + A UAS first processes the BYE request according to the general UAS + processing described in Section 8.2. A UAS core receiving a BYE + request checks if it matches an existing dialog. If the BYE does not + match an existing dialog, the UAS core SHOULD generate a 481 + (Call/Transaction Does Not Exist) response and pass that to the + server transaction. + + This rule means that a BYE sent without tags by a UAC will be + rejected. This is a change from RFC 2543, which allowed BYE + without tags. + + A UAS core receiving a BYE request for an existing dialog MUST follow + the procedures of Section 12.2.2 to process the request. Once done, + the UAS SHOULD terminate the session (and therefore stop sending and + listening for media). The only case where it can elect not to are + multicast sessions, where participation is possible even if the other + participant in the dialog has terminated its involvement in the + session. Whether or not it ends its participation on the session, + the UAS core MUST generate a 2xx response to the BYE, and MUST pass + that to the server transaction for transmission. + + The UAS MUST still respond to any pending requests received for that + dialog. It is RECOMMENDED that a 487 (Request Terminated) response + be generated to those pending requests. + +16 Proxy Behavior + +16.1 Overview + + SIP proxies are elements that route SIP requests to user agent + servers and SIP responses to user agent clients. A request may + traverse several proxies on its way to a UAS. Each will make routing + decisions, modifying the request before forwarding it to the next + element. Responses will route through the same set of proxies + traversed by the request in the reverse order. + + Being a proxy is a logical role for a SIP element. When a request + arrives, an element that can play the role of a proxy first decides + if it needs to respond to the request on its own. For instance, the + request may be malformed or the element may need credentials from the + client before acting as a proxy. The element MAY respond with any + + + + +Rosenberg, et. al. Standards Track [Page 91] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + appropriate error code. When responding directly to a request, the + element is playing the role of a UAS and MUST behave as described in + Section 8.2. + + A proxy can operate in either a stateful or stateless mode for each + new request. When stateless, a proxy acts as a simple forwarding + element. It forwards each request downstream to a single element + determined by making a targeting and routing decision based on the + request. It simply forwards every response it receives upstream. A + stateless proxy discards information about a message once the message + has been forwarded. A stateful proxy remembers information + (specifically, transaction state) about each incoming request and any + requests it sends as a result of processing the incoming request. It + uses this information to affect the processing of future messages + associated with that request. A stateful proxy MAY choose to "fork" + a request, routing it to multiple destinations. Any request that is + forwarded to more than one location MUST be handled statefully. + + In some circumstances, a proxy MAY forward requests using stateful + transports (such as TCP) without being transaction-stateful. For + instance, a proxy MAY forward a request from one TCP connection to + another transaction statelessly as long as it places enough + information in the message to be able to forward the response down + the same connection the request arrived on. Requests forwarded + between different types of transports where the proxy's TU must take + an active role in ensuring reliable delivery on one of the transports + MUST be forwarded transaction statefully. + + A stateful proxy MAY transition to stateless operation at any time + during the processing of a request, so long as it did not do anything + that would otherwise prevent it from being stateless initially + (forking, for example, or generation of a 100 response). When + performing such a transition, all state is simply discarded. The + proxy SHOULD NOT initiate a CANCEL request. + + Much of the processing involved when acting statelessly or statefully + for a request is identical. The next several subsections are written + from the point of view of a stateful proxy. The last section calls + out those places where a stateless proxy behaves differently. + +16.2 Stateful Proxy + + When stateful, a proxy is purely a SIP transaction processing engine. + Its behavior is modeled here in terms of the server and client + transactions defined in Section 17. A stateful proxy has a server + transaction associated with one or more client transactions by a + higher layer proxy processing component (see figure 3), known as a + proxy core. An incoming request is processed by a server + + + +Rosenberg, et. al. Standards Track [Page 92] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + transaction. Requests from the server transaction are passed to a + proxy core. The proxy core determines where to route the request, + choosing one or more next-hop locations. An outgoing request for + each next-hop location is processed by its own associated client + transaction. The proxy core collects the responses from the client + transactions and uses them to send responses to the server + transaction. + + A stateful proxy creates a new server transaction for each new + request received. Any retransmissions of the request will then be + handled by that server transaction per Section 17. The proxy core + MUST behave as a UAS with respect to sending an immediate provisional + on that server transaction (such as 100 Trying) as described in + Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 + (Trying) responses to non-INVITE requests. + + This is a model of proxy behavior, not of software. An + implementation is free to take any approach that replicates the + external behavior this model defines. + + For all new requests, including any with unknown methods, an element + intending to proxy the request MUST: + + 1. Validate the request (Section 16.3) + + 2. Preprocess routing information (Section 16.4) + + 3. Determine target(s) for the request (Section 16.5) + + +--------------------+ + | | +---+ + | | | C | + | | | T | + | | +---+ + +---+ | Proxy | +---+ CT = Client Transaction + | S | | "Higher" Layer | | C | + | T | | | | T | ST = Server Transaction + +---+ | | +---+ + | | +---+ + | | | C | + | | | T | + | | +---+ + +--------------------+ + + Figure 3: Stateful Proxy Model + + + + + + +Rosenberg, et. al. Standards Track [Page 93] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 4. Forward the request to each target (Section 16.6) + + 5. Process all responses (Section 16.7) + +16.3 Request Validation + + Before an element can proxy a request, it MUST verify the message's + validity. A valid message must pass the following checks: + + 1. Reasonable Syntax + + 2. URI scheme + + 3. Max-Forwards + + 4. (Optional) Loop Detection + + 5. Proxy-Require + + 6. Proxy-Authorization + + If any of these checks fail, the element MUST behave as a user agent + server (see Section 8.2) and respond with an error code. + + Notice that a proxy is not required to detect merged requests and + MUST NOT treat merged requests as an error condition. The endpoints + receiving the requests will resolve the merge as described in Section + 8.2.2.2. + + 1. Reasonable syntax check + + The request MUST be well-formed enough to be handled with a server + transaction. Any components involved in the remainder of these + Request Validation steps or the Request Forwarding section MUST be + well-formed. Any other components, well-formed or not, SHOULD be + ignored and remain unchanged when the message is forwarded. For + instance, an element would not reject a request because of a + malformed Date header field. Likewise, a proxy would not remove a + malformed Date header field before forwarding a request. + + This protocol is designed to be extended. Future extensions may + define new methods and header fields at any time. An element MUST + NOT refuse to proxy a request because it contains a method or + header field it does not know about. + + + + + + + +Rosenberg, et. al. Standards Track [Page 94] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 2. URI scheme check + + If the Request-URI has a URI whose scheme is not understood by the + proxy, the proxy SHOULD reject the request with a 416 (Unsupported + URI Scheme) response. + + 3. Max-Forwards check + + The Max-Forwards header field (Section 20.22) is used to limit the + number of elements a SIP request can traverse. + + If the request does not contain a Max-Forwards header field, this + check is passed. + + If the request contains a Max-Forwards header field with a field + value greater than zero, the check is passed. + + If the request contains a Max-Forwards header field with a field + value of zero (0), the element MUST NOT forward the request. If + the request was for OPTIONS, the element MAY act as the final + recipient and respond per Section 11. Otherwise, the element MUST + return a 483 (Too many hops) response. + + 4. Optional Loop Detection check + + An element MAY check for forwarding loops before forwarding a + request. If the request contains a Via header field with a sent- + by value that equals a value placed into previous requests by the + proxy, the request has been forwarded by this element before. The + request has either looped or is legitimately spiraling through the + element. To determine if the request has looped, the element MAY + perform the branch parameter calculation described in Step 8 of + Section 16.6 on this message and compare it to the parameter + received in that Via header field. If the parameters match, the + request has looped. If they differ, the request is spiraling, and + processing continues. If a loop is detected, the element MAY + return a 482 (Loop Detected) response. + + 5. Proxy-Require check + + Future extensions to this protocol may introduce features that + require special handling by proxies. Endpoints will include a + Proxy-Require header field in requests that use these features, + telling the proxy not to process the request unless the feature is + understood. + + + + + + +Rosenberg, et. al. Standards Track [Page 95] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If the request contains a Proxy-Require header field (Section + 20.29) with one or more option-tags this element does not + understand, the element MUST return a 420 (Bad Extension) + response. The response MUST include an Unsupported (Section + 20.40) header field listing those option-tags the element did not + understand. + + 6. Proxy-Authorization check + + If an element requires credentials before forwarding a request, + the request MUST be inspected as described in Section 22.3. That + section also defines what the element must do if the inspection + fails. + +16.4 Route Information Preprocessing + + The proxy MUST inspect the Request-URI of the request. If the + Request-URI of the request contains a value this proxy previously + placed into a Record-Route header field (see Section 16.6 item 4), + the proxy MUST replace the Request-URI in the request with the last + value from the Route header field, and remove that value from the + Route header field. The proxy MUST then proceed as if it received + this modified request. + + This will only happen when the element sending the request to the + proxy (which may have been an endpoint) is a strict router. This + rewrite on receive is necessary to enable backwards compatibility + with those elements. It also allows elements following this + specification to preserve the Request-URI through strict-routing + proxies (see Section 12.2.1.1). + + This requirement does not obligate a proxy to keep state in order + to detect URIs it previously placed in Record-Route header fields. + Instead, a proxy need only place enough information in those URIs + to recognize them as values it provided when they later appear. + + If the Request-URI contains a maddr parameter, the proxy MUST check + to see if its value is in the set of addresses or domains the proxy + is configured to be responsible for. If the Request-URI has a maddr + parameter with a value the proxy is responsible for, and the request + was received using the port and transport indicated (explicitly or by + default) in the Request-URI, the proxy MUST strip the maddr and any + non-default port or transport parameter and continue processing as if + those values had not been present in the request. + + + + + + + +Rosenberg, et. al. Standards Track [Page 96] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + A request may arrive with a maddr matching the proxy, but on a + port or transport different from that indicated in the URI. Such + a request needs to be forwarded to the proxy using the indicated + port and transport. + + If the first value in the Route header field indicates this proxy, + the proxy MUST remove that value from the request. + +16.5 Determining Request Targets + + Next, the proxy calculates the target(s) of the request. The set of + targets will either be predetermined by the contents of the request + or will be obtained from an abstract location service. Each target + in the set is represented as a URI. + + If the Request-URI of the request contains an maddr parameter, the + Request-URI MUST be placed into the target set as the only target + URI, and the proxy MUST proceed to Section 16.6. + + If the domain of the Request-URI indicates a domain this element is + not responsible for, the Request-URI MUST be placed into the target + set as the only target, and the element MUST proceed to the task of + Request Forwarding (Section 16.6). + + There are many circumstances in which a proxy might receive a + request for a domain it is not responsible for. A firewall proxy + handling outgoing calls (the way HTTP proxies handle outgoing + requests) is an example of where this is likely to occur. + + If the target set for the request has not been predetermined as + described above, this implies that the element is responsible for the + domain in the Request-URI, and the element MAY use whatever mechanism + it desires to determine where to send the request. Any of these + mechanisms can be modeled as accessing an abstract Location Service. + This may consist of obtaining information from a location service + created by a SIP Registrar, reading a database, consulting a presence + server, utilizing other protocols, or simply performing an + algorithmic substitution on the Request-URI. When accessing the + location service constructed by a registrar, the Request-URI MUST + first be canonicalized as described in Section 10.3 before being used + as an index. The output of these mechanisms is used to construct the + target set. + + If the Request-URI does not provide sufficient information for the + proxy to determine the target set, it SHOULD return a 485 (Ambiguous) + response. This response SHOULD contain a Contact header field + containing URIs of new addresses to be tried. For example, an INVITE + + + + +Rosenberg, et. al. Standards Track [Page 97] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + to sip:John.Smith@company.com may be ambiguous at a proxy whose + location service has multiple John Smiths listed. See Section + 21.4.23 for details. + + Any information in or about the request or the current environment of + the element MAY be used in the construction of the target set. For + instance, different sets may be constructed depending on contents or + the presence of header fields and bodies, the time of day of the + request's arrival, the interface on which the request arrived, + failure of previous requests, or even the element's current level of + utilization. + + As potential targets are located through these services, their URIs + are added to the target set. Targets can only be placed in the + target set once. If a target URI is already present in the set + (based on the definition of equality for the URI type), it MUST NOT + be added again. + + A proxy MUST NOT add additional targets to the target set if the + Request-URI of the original request does not indicate a resource this + proxy is responsible for. + + A proxy can only change the Request-URI of a request during + forwarding if it is responsible for that URI. If the proxy is not + responsible for that URI, it will not recurse on 3xx or 416 + responses as described below. + + If the Request-URI of the original request indicates a resource this + proxy is responsible for, the proxy MAY continue to add targets to + the set after beginning Request Forwarding. It MAY use any + information obtained during that processing to determine new targets. + For instance, a proxy may choose to incorporate contacts obtained in + a redirect response (3xx) into the target set. If a proxy uses a + dynamic source of information while building the target set (for + instance, if it consults a SIP Registrar), it SHOULD monitor that + source for the duration of processing the request. New locations + SHOULD be added to the target set as they become available. As + above, any given URI MUST NOT be added to the set more than once. + + Allowing a URI to be added to the set only once reduces + unnecessary network traffic, and in the case of incorporating + contacts from redirect requests prevents infinite recursion. + + For example, a trivial location service is a "no-op", where the + target URI is equal to the incoming request URI. The request is sent + to a specific next hop proxy for further processing. During request + + + + + +Rosenberg, et. al. Standards Track [Page 98] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + forwarding of Section 16.6, Item 6, the identity of that next hop, + expressed as a SIP or SIPS URI, is inserted as the top-most Route + header field value into the request. + + If the Request-URI indicates a resource at this proxy that does not + exist, the proxy MUST return a 404 (Not Found) response. + + If the target set remains empty after applying all of the above, the + proxy MUST return an error response, which SHOULD be the 480 + (Temporarily Unavailable) response. + +16.6 Request Forwarding + + As soon as the target set is non-empty, a proxy MAY begin forwarding + the request. A stateful proxy MAY process the set in any order. It + MAY process multiple targets serially, allowing each client + transaction to complete before starting the next. It MAY start + client transactions with every target in parallel. It also MAY + arbitrarily divide the set into groups, processing the groups + serially and processing the targets in each group in parallel. + + A common ordering mechanism is to use the qvalue parameter of targets + obtained from Contact header fields (see Section 20.10). Targets are + processed from highest qvalue to lowest. Targets with equal qvalues + may be processed in parallel. + + A stateful proxy must have a mechanism to maintain the target set as + responses are received and associate the responses to each forwarded + request with the original request. For the purposes of this model, + this mechanism is a "response context" created by the proxy layer + before forwarding the first request. + + For each target, the proxy forwards the request following these + steps: + + 1. Make a copy of the received request + + 2. Update the Request-URI + + 3. Update the Max-Forwards header field + + 4. Optionally add a Record-route header field value + + 5. Optionally add additional header fields + + 6. Postprocess routing information + + 7. Determine the next-hop address, port, and transport + + + +Rosenberg, et. al. Standards Track [Page 99] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 8. Add a Via header field value + + 9. Add a Content-Length header field if necessary + + 10. Forward the new request + + 11. Set timer C + + Each of these steps is detailed below: + + 1. Copy request + + The proxy starts with a copy of the received request. The copy + MUST initially contain all of the header fields from the + received request. Fields not detailed in the processing + described below MUST NOT be removed. The copy SHOULD maintain + the ordering of the header fields as in the received request. + The proxy MUST NOT reorder field values with a common field + name (See Section 7.3.1). The proxy MUST NOT add to, modify, + or remove the message body. + + An actual implementation need not perform a copy; the primary + requirement is that the processing for each next hop begin with + the same request. + + 2. Request-URI + + The Request-URI in the copy's start line MUST be replaced with + the URI for this target. If the URI contains any parameters + not allowed in a Request-URI, they MUST be removed. + + This is the essence of a proxy's role. This is the mechanism + through which a proxy routes a request toward its destination. + + In some circumstances, the received Request-URI is placed into + the target set without being modified. For that target, the + replacement above is effectively a no-op. + + 3. Max-Forwards + + If the copy contains a Max-Forwards header field, the proxy + MUST decrement its value by one (1). + + If the copy does not contain a Max-Forwards header field, the + proxy MUST add one with a field value, which SHOULD be 70. + + Some existing UAs will not provide a Max-Forwards header field + in a request. + + + +Rosenberg, et. al. Standards Track [Page 100] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 4. Record-Route + + If this proxy wishes to remain on the path of future requests + in a dialog created by this request (assuming the request + creates a dialog), it MUST insert a Record-Route header field + value into the copy before any existing Record-Route header + field values, even if a Route header field is already present. + + Requests establishing a dialog may contain a preloaded Route + header field. + + If this request is already part of a dialog, the proxy SHOULD + insert a Record-Route header field value if it wishes to remain + on the path of future requests in the dialog. In normal + endpoint operation as described in Section 12, these Record- + Route header field values will not have any effect on the route + sets used by the endpoints. + + The proxy will remain on the path if it chooses to not insert a + Record-Route header field value into requests that are already + part of a dialog. However, it would be removed from the path + when an endpoint that has failed reconstitutes the dialog. + + A proxy MAY insert a Record-Route header field value into any + request. If the request does not initiate a dialog, the + endpoints will ignore the value. See Section 12 for details on + how endpoints use the Record-Route header field values to + construct Route header fields. + + Each proxy in the path of a request chooses whether to add a + Record-Route header field value independently - the presence of + a Record-Route header field in a request does not obligate this + proxy to add a value. + + The URI placed in the Record-Route header field value MUST be a + SIP or SIPS URI. This URI MUST contain an lr parameter (see + Section 19.1.1). This URI MAY be different for each + destination the request is forwarded to. The URI SHOULD NOT + contain the transport parameter unless the proxy has knowledge + (such as in a private network) that the next downstream element + that will be in the path of subsequent requests supports that + transport. + + The URI this proxy provides will be used by some other element + to make a routing decision. This proxy, in general, has no way + of knowing the capabilities of that element, so it must + restrict itself to the mandatory elements of a SIP + implementation: SIP URIs and either the TCP or UDP transports. + + + +Rosenberg, et. al. Standards Track [Page 101] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The URI placed in the Record-Route header field MUST resolve to + the element inserting it (or a suitable stand-in) when the + server location procedures of [4] are applied to it, so that + subsequent requests reach the same SIP element. If the + Request-URI contains a SIPS URI, or the topmost Route header + field value (after the post processing of bullet 6) contains a + SIPS URI, the URI placed into the Record-Route header field + MUST be a SIPS URI. Furthermore, if the request was not + received over TLS, the proxy MUST insert a Record-Route header + field. In a similar fashion, a proxy that receives a request + over TLS, but generates a request without a SIPS URI in the + Request-URI or topmost Route header field value (after the post + processing of bullet 6), MUST insert a Record-Route header + field that is not a SIPS URI. + + A proxy at a security perimeter must remain on the perimeter + throughout the dialog. + + If the URI placed in the Record-Route header field needs to be + rewritten when it passes back through in a response, the URI + MUST be distinct enough to locate at that time. (The request + may spiral through this proxy, resulting in more than one + Record-Route header field value being added). Item 8 of + Section 16.7 recommends a mechanism to make the URI + sufficiently distinct. + + The proxy MAY include parameters in the Record-Route header + field value. These will be echoed in some responses to the + request such as the 200 (OK) responses to INVITE. Such + parameters may be useful for keeping state in the message + rather than the proxy. + + If a proxy needs to be in the path of any type of dialog (such + as one straddling a firewall), it SHOULD add a Record-Route + header field value to every request with a method it does not + understand since that method may have dialog semantics. + + The URI a proxy places into a Record-Route header field is only + valid for the lifetime of any dialog created by the transaction + in which it occurs. A dialog-stateful proxy, for example, MAY + refuse to accept future requests with that value in the + Request-URI after the dialog has terminated. Non-dialog- + stateful proxies, of course, have no concept of when the dialog + has terminated, but they MAY encode enough information in the + value to compare it against the dialog identifier of future + requests and MAY reject requests not matching that information. + Endpoints MUST NOT use a URI obtained from a Record-Route + header field outside the dialog in which it was provided. See + + + +Rosenberg, et. al. Standards Track [Page 102] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Section 12 for more information on an endpoint's use of + Record-Route header fields. + + Record-routing may be required by certain services where the + proxy needs to observe all messages in a dialog. However, it + slows down processing and impairs scalability and thus proxies + should only record-route if required for a particular service. + + The Record-Route process is designed to work for any SIP + request that initiates a dialog. INVITE is the only such + request in this specification, but extensions to the protocol + MAY define others. + + 5. Add Additional Header Fields + + The proxy MAY add any other appropriate header fields to the + copy at this point. + + 6. Postprocess routing information + + A proxy MAY have a local policy that mandates that a request + visit a specific set of proxies before being delivered to the + destination. A proxy MUST ensure that all such proxies are + loose routers. Generally, this can only be known with + certainty if the proxies are within the same administrative + domain. This set of proxies is represented by a set of URIs + (each of which contains the lr parameter). This set MUST be + pushed into the Route header field of the copy ahead of any + existing values, if present. If the Route header field is + absent, it MUST be added, containing that list of URIs. + + If the proxy has a local policy that mandates that the request + visit one specific proxy, an alternative to pushing a Route + value into the Route header field is to bypass the forwarding + logic of item 10 below, and instead just send the request to + the address, port, and transport for that specific proxy. If + the request has a Route header field, this alternative MUST NOT + be used unless it is known that next hop proxy is a loose + router. Otherwise, this approach MAY be used, but the Route + insertion mechanism above is preferred for its robustness, + flexibility, generality and consistency of operation. + Furthermore, if the Request-URI contains a SIPS URI, TLS MUST + be used to communicate with that proxy. + + If the copy contains a Route header field, the proxy MUST + inspect the URI in its first value. If that URI does not + contain an lr parameter, the proxy MUST modify the copy as + follows: + + + +Rosenberg, et. al. Standards Track [Page 103] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + - The proxy MUST place the Request-URI into the Route header + field as the last value. + + - The proxy MUST then place the first Route header field value + into the Request-URI and remove that value from the Route + header field. + + Appending the Request-URI to the Route header field is part of + a mechanism used to pass the information in that Request-URI + through strict-routing elements. "Popping" the first Route + header field value into the Request-URI formats the message the + way a strict-routing element expects to receive it (with its + own URI in the Request-URI and the next location to visit in + the first Route header field value). + + 7. Determine Next-Hop Address, Port, and Transport + + The proxy MAY have a local policy to send the request to a + specific IP address, port, and transport, independent of the + values of the Route and Request-URI. Such a policy MUST NOT be + used if the proxy is not certain that the IP address, port, and + transport correspond to a server that is a loose router. + However, this mechanism for sending the request through a + specific next hop is NOT RECOMMENDED; instead a Route header + field should be used for that purpose as described above. + + In the absence of such an overriding mechanism, the proxy + applies the procedures listed in [4] as follows to determine + where to send the request. If the proxy has reformatted the + request to send to a strict-routing element as described in + step 6 above, the proxy MUST apply those procedures to the + Request-URI of the request. Otherwise, the proxy MUST apply + the procedures to the first value in the Route header field, if + present, else the Request-URI. The procedures will produce an + ordered set of (address, port, transport) tuples. + Independently of which URI is being used as input to the + procedures of [4], if the Request-URI specifies a SIPS + resource, the proxy MUST follow the procedures of [4] as if the + input URI were a SIPS URI. + + As described in [4], the proxy MUST attempt to deliver the + message to the first tuple in that set, and proceed through the + set in order until the delivery attempt succeeds. + + For each tuple attempted, the proxy MUST format the message as + appropriate for the tuple and send the request using a new + client transaction as detailed in steps 8 through 10. + + + + +Rosenberg, et. al. Standards Track [Page 104] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Since each attempt uses a new client transaction, it represents + a new branch. Thus, the branch parameter provided with the Via + header field inserted in step 8 MUST be different for each + attempt. + + If the client transaction reports failure to send the request + or a timeout from its state machine, the proxy continues to the + next address in that ordered set. If the ordered set is + exhausted, the request cannot be forwarded to this element in + the target set. The proxy does not need to place anything in + the response context, but otherwise acts as if this element of + the target set returned a 408 (Request Timeout) final response. + + 8. Add a Via header field value + + The proxy MUST insert a Via header field value into the copy + before the existing Via header field values. The construction + of this value follows the same guidelines of Section 8.1.1.7. + This implies that the proxy will compute its own branch + parameter, which will be globally unique for that branch, and + contain the requisite magic cookie. Note that this implies that + the branch parameter will be different for different instances + of a spiraled or looped request through a proxy. + + Proxies choosing to detect loops have an additional constraint + in the value they use for construction of the branch parameter. + A proxy choosing to detect loops SHOULD create a branch + parameter separable into two parts by the implementation. The + first part MUST satisfy the constraints of Section 8.1.1.7 as + described above. The second is used to perform loop detection + and distinguish loops from spirals. + + Loop detection is performed by verifying that, when a request + returns to a proxy, those fields having an impact on the + processing of the request have not changed. The value placed + in this part of the branch parameter SHOULD reflect all of + those fields (including any Route, Proxy-Require and Proxy- + Authorization header fields). This is to ensure that if the + request is routed back to the proxy and one of those fields + changes, it is treated as a spiral and not a loop (see Section + 16.3). A common way to create this value is to compute a + cryptographic hash of the To tag, From tag, Call-ID header + field, the Request-URI of the request received (before + translation), the topmost Via header, and the sequence number + from the CSeq header field, in addition to any Proxy-Require + and Proxy-Authorization header fields that may be present. The + + + + + +Rosenberg, et. al. Standards Track [Page 105] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + algorithm used to compute the hash is implementation-dependent, + but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a + reasonable choice. (Base64 is not permissible for a token.) + + If a proxy wishes to detect loops, the "branch" parameter it + supplies MUST depend on all information affecting processing of + a request, including the incoming Request-URI and any header + fields affecting the request's admission or routing. This is + necessary to distinguish looped requests from requests whose + routing parameters have changed before returning to this + server. + + The request method MUST NOT be included in the calculation of + the branch parameter. In particular, CANCEL and ACK requests + (for non-2xx responses) MUST have the same branch value as the + corresponding request they cancel or acknowledge. The branch + parameter is used in correlating those requests at the server + handling them (see Sections 17.2.3 and 9.2). + + 9. Add a Content-Length header field if necessary + + If the request will be sent to the next hop using a stream- + based transport and the copy contains no Content-Length header + field, the proxy MUST insert one with the correct value for the + body of the request (see Section 20.14). + + 10. Forward Request + + A stateful proxy MUST create a new client transaction for this + request as described in Section 17.1 and instructs the + transaction to send the request using the address, port and + transport determined in step 7. + + 11. Set timer C + + In order to handle the case where an INVITE request never + generates a final response, the TU uses a timer which is called + timer C. Timer C MUST be set for each client transaction when + an INVITE request is proxied. The timer MUST be larger than 3 + minutes. Section 16.7 bullet 2 discusses how this timer is + updated with provisional responses, and Section 16.8 discusses + processing when it fires. + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 106] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +16.7 Response Processing + + When a response is received by an element, it first tries to locate a + client transaction (Section 17.1.3) matching the response. If none + is found, the element MUST process the response (even if it is an + informational response) as a stateless proxy (described below). If a + match is found, the response is handed to the client transaction. + + Forwarding responses for which a client transaction (or more + generally any knowledge of having sent an associated request) is + not found improves robustness. In particular, it ensures that + "late" 2xx responses to INVITE requests are forwarded properly. + + As client transactions pass responses to the proxy layer, the + following processing MUST take place: + + 1. Find the appropriate response context + + 2. Update timer C for provisional responses + + 3. Remove the topmost Via + + 4. Add the response to the response context + + 5. Check to see if this response should be forwarded immediately + + 6. When necessary, choose the best final response from the + response context + + If no final response has been forwarded after every client + transaction associated with the response context has been terminated, + the proxy must choose and forward the "best" response from those it + has seen so far. + + The following processing MUST be performed on each response that is + forwarded. It is likely that more than one response to each request + will be forwarded: at least each provisional and one final response. + + 7. Aggregate authorization header field values if necessary + + 8. Optionally rewrite Record-Route header field values + + 9. Forward the response + + 10. Generate any necessary CANCEL requests + + + + + + +Rosenberg, et. al. Standards Track [Page 107] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Each of the above steps are detailed below: + + 1. Find Context + + The proxy locates the "response context" it created before + forwarding the original request using the key described in + Section 16.6. The remaining processing steps take place in + this context. + + 2. Update timer C for provisional responses + + For an INVITE transaction, if the response is a provisional + response with status codes 101 to 199 inclusive (i.e., anything + but 100), the proxy MUST reset timer C for that client + transaction. The timer MAY be reset to a different value, but + this value MUST be greater than 3 minutes. + + 3. Via + + The proxy removes the topmost Via header field value from the + response. + + If no Via header field values remain in the response, the + response was meant for this element and MUST NOT be forwarded. + The remainder of the processing described in this section is + not performed on this message, the UAC processing rules + described in Section 8.1.3 are followed instead (transport + layer processing has already occurred). + + This will happen, for instance, when the element generates + CANCEL requests as described in Section 10. + + 4. Add response to context + + Final responses received are stored in the response context + until a final response is generated on the server transaction + associated with this context. The response may be a candidate + for the best final response to be returned on that server + transaction. Information from this response may be needed in + forming the best response, even if this response is not chosen. + + If the proxy chooses to recurse on any contacts in a 3xx + response by adding them to the target set, it MUST remove them + from the response before adding the response to the response + context. However, a proxy SHOULD NOT recurse to a non-SIPS URI + if the Request-URI of the original request was a SIPS URI. If + + + + + +Rosenberg, et. al. Standards Track [Page 108] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + the proxy recurses on all of the contacts in a 3xx response, + the proxy SHOULD NOT add the resulting contactless response to + the response context. + + Removing the contact before adding the response to the response + context prevents the next element upstream from retrying a + location this proxy has already attempted. + + 3xx responses may contain a mixture of SIP, SIPS, and non-SIP + URIs. A proxy may choose to recurse on the SIP and SIPS URIs + and place the remainder into the response context to be + returned, potentially in the final response. + + If a proxy receives a 416 (Unsupported URI Scheme) response to + a request whose Request-URI scheme was not SIP, but the scheme + in the original received request was SIP or SIPS (that is, the + proxy changed the scheme from SIP or SIPS to something else + when it proxied a request), the proxy SHOULD add a new URI to + the target set. This URI SHOULD be a SIP URI version of the + non-SIP URI that was just tried. In the case of the tel URL, + this is accomplished by placing the telephone-subscriber part + of the tel URL into the user part of the SIP URI, and setting + the hostpart to the domain where the prior request was sent. + See Section 19.1.6 for more detail on forming SIP URIs from tel + URLs. + + As with a 3xx response, if a proxy "recurses" on the 416 by + trying a SIP or SIPS URI instead, the 416 response SHOULD NOT + be added to the response context. + + 5. Check response for forwarding + + Until a final response has been sent on the server transaction, + the following responses MUST be forwarded immediately: + + - Any provisional response other than 100 (Trying) + + - Any 2xx response + + If a 6xx response is received, it is not immediately forwarded, + but the stateful proxy SHOULD cancel all client pending + transactions as described in Section 10, and it MUST NOT create + any new branches in this context. + + This is a change from RFC 2543, which mandated that the proxy + was to forward the 6xx response immediately. For an INVITE + transaction, this approach had the problem that a 2xx response + could arrive on another branch, in which case the proxy would + + + +Rosenberg, et. al. Standards Track [Page 109] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + have to forward the 2xx. The result was that the UAC could + receive a 6xx response followed by a 2xx response, which should + never be allowed to happen. Under the new rules, upon + receiving a 6xx, a proxy will issue a CANCEL request, which + will generally result in 487 responses from all outstanding + client transactions, and then at that point the 6xx is + forwarded upstream. + + After a final response has been sent on the server transaction, + the following responses MUST be forwarded immediately: + + - Any 2xx response to an INVITE request + + A stateful proxy MUST NOT immediately forward any other + responses. In particular, a stateful proxy MUST NOT forward + any 100 (Trying) response. Those responses that are candidates + for forwarding later as the "best" response have been gathered + as described in step "Add Response to Context". + + Any response chosen for immediate forwarding MUST be processed + as described in steps "Aggregate Authorization Header Field + Values" through "Record-Route". + + This step, combined with the next, ensures that a stateful + proxy will forward exactly one final response to a non-INVITE + request, and either exactly one non-2xx response or one or more + 2xx responses to an INVITE request. + + 6. Choosing the best response + + A stateful proxy MUST send a final response to a response + context's server transaction if no final responses have been + immediately forwarded by the above rules and all client + transactions in this response context have been terminated. + + The stateful proxy MUST choose the "best" final response among + those received and stored in the response context. + + If there are no final responses in the context, the proxy MUST + send a 408 (Request Timeout) response to the server + transaction. + + Otherwise, the proxy MUST forward a response from the responses + stored in the response context. It MUST choose from the 6xx + class responses if any exist in the context. If no 6xx class + responses are present, the proxy SHOULD choose from the lowest + response class stored in the response context. The proxy MAY + select any response within that chosen class. The proxy SHOULD + + + +Rosenberg, et. al. Standards Track [Page 110] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + give preference to responses that provide information affecting + resubmission of this request, such as 401, 407, 415, 420, and + 484 if the 4xx class is chosen. + + A proxy which receives a 503 (Service Unavailable) response + SHOULD NOT forward it upstream unless it can determine that any + subsequent requests it might proxy will also generate a 503. + In other words, forwarding a 503 means that the proxy knows it + cannot service any requests, not just the one for the Request- + URI in the request which generated the 503. If the only + response that was received is a 503, the proxy SHOULD generate + a 500 response and forward that upstream. + + The forwarded response MUST be processed as described in steps + "Aggregate Authorization Header Field Values" through "Record- + Route". + + For example, if a proxy forwarded a request to 4 locations, and + received 503, 407, 501, and 404 responses, it may choose to + forward the 407 (Proxy Authentication Required) response. + + 1xx and 2xx responses may be involved in the establishment of + dialogs. When a request does not contain a To tag, the To tag + in the response is used by the UAC to distinguish multiple + responses to a dialog creating request. A proxy MUST NOT + insert a tag into the To header field of a 1xx or 2xx response + if the request did not contain one. A proxy MUST NOT modify + the tag in the To header field of a 1xx or 2xx response. + + Since a proxy may not insert a tag into the To header field of + a 1xx response to a request that did not contain one, it cannot + issue non-100 provisional responses on its own. However, it + can branch the request to a UAS sharing the same element as the + proxy. This UAS can return its own provisional responses, + entering into an early dialog with the initiator of the + request. The UAS does not have to be a discreet process from + the proxy. It could be a virtual UAS implemented in the same + code space as the proxy. + + 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx + response, the element is effectively acting as a UAS, issuing + its own response, usually based on the responses received from + downstream elements. An element SHOULD preserve the To tag + when simply forwarding a 3-6xx response to a request that did + not contain a To tag. + + A proxy MUST NOT modify the To tag in any forwarded response to + a request that contains a To tag. + + + +Rosenberg, et. al. Standards Track [Page 111] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + While it makes no difference to the upstream elements if the + proxy replaced the To tag in a forwarded 3-6xx response, + preserving the original tag may assist with debugging. + + When the proxy is aggregating information from several + responses, choosing a To tag from among them is arbitrary, and + generating a new To tag may make debugging easier. This + happens, for instance, when combining 401 (Unauthorized) and + 407 (Proxy Authentication Required) challenges, or combining + Contact values from unencrypted and unauthenticated 3xx + responses. + + 7. Aggregate Authorization Header Field Values + + If the selected response is a 401 (Unauthorized) or 407 (Proxy + Authentication Required), the proxy MUST collect any WWW- + Authenticate and Proxy-Authenticate header field values from + all other 401 (Unauthorized) and 407 (Proxy Authentication + Required) responses received so far in this response context + and add them to this response without modification before + forwarding. The resulting 401 (Unauthorized) or 407 (Proxy + Authentication Required) response could have several WWW- + Authenticate AND Proxy-Authenticate header field values. + + This is necessary because any or all of the destinations the + request was forwarded to may have requested credentials. The + client needs to receive all of those challenges and supply + credentials for each of them when it retries the request. + Motivation for this behavior is provided in Section 26. + + 8. Record-Route + + If the selected response contains a Record-Route header field + value originally provided by this proxy, the proxy MAY choose + to rewrite the value before forwarding the response. This + allows the proxy to provide different URIs for itself to the + next upstream and downstream elements. A proxy may choose to + use this mechanism for any reason. For instance, it is useful + for multi-homed hosts. + + If the proxy received the request over TLS, and sent it out + over a non-TLS connection, the proxy MUST rewrite the URI in + the Record-Route header field to be a SIPS URI. If the proxy + received the request over a non-TLS connection, and sent it out + over TLS, the proxy MUST rewrite the URI in the Record-Route + header field to be a SIP URI. + + + + + +Rosenberg, et. al. Standards Track [Page 112] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The new URI provided by the proxy MUST satisfy the same + constraints on URIs placed in Record-Route header fields in + requests (see Step 4 of Section 16.6) with the following + modifications: + + The URI SHOULD NOT contain the transport parameter unless the + proxy has knowledge that the next upstream (as opposed to + downstream) element that will be in the path of subsequent + requests supports that transport. + + When a proxy does decide to modify the Record-Route header + field in the response, one of the operations it performs is + locating the Record-Route value that it had inserted. If the + request spiraled, and the proxy inserted a Record-Route value + in each iteration of the spiral, locating the correct value in + the response (which must be the proper iteration in the reverse + direction) is tricky. The rules above recommend that a proxy + wishing to rewrite Record-Route header field values insert + sufficiently distinct URIs into the Record-Route header field + so that the right one may be selected for rewriting. A + RECOMMENDED mechanism to achieve this is for the proxy to + append a unique identifier for the proxy instance to the user + portion of the URI. + + When the response arrives, the proxy modifies the first + Record-Route whose identifier matches the proxy instance. The + modification results in a URI without this piece of data + appended to the user portion of the URI. Upon the next + iteration, the same algorithm (find the topmost Record-Route + header field value with the parameter) will correctly extract + the next Record-Route header field value inserted by that + proxy. + + Not every response to a request to which a proxy adds a + Record-Route header field value will contain a Record-Route + header field. If the response does contain a Record-Route + header field, it will contain the value the proxy added. + + 9. Forward response + + After performing the processing described in steps "Aggregate + Authorization Header Field Values" through "Record-Route", the + proxy MAY perform any feature specific manipulations on the + selected response. The proxy MUST NOT add to, modify, or + remove the message body. Unless otherwise specified, the proxy + MUST NOT remove any header field values other than the Via + header field value discussed in Section 16.7 Item 3. In + particular, the proxy MUST NOT remove any "received" parameter + + + +Rosenberg, et. al. Standards Track [Page 113] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + it may have added to the next Via header field value while + processing the request associated with this response. The + proxy MUST pass the response to the server transaction + associated with the response context. This will result in the + response being sent to the location now indicated in the + topmost Via header field value. If the server transaction is + no longer available to handle the transmission, the element + MUST forward the response statelessly by sending it to the + server transport. The server transaction might indicate + failure to send the response or signal a timeout in its state + machine. These errors would be logged for diagnostic purposes + as appropriate, but the protocol requires no remedial action + from the proxy. + + The proxy MUST maintain the response context until all of its + associated transactions have been terminated, even after + forwarding a final response. + + 10. Generate CANCELs + + If the forwarded response was a final response, the proxy MUST + generate a CANCEL request for all pending client transactions + associated with this response context. A proxy SHOULD also + generate a CANCEL request for all pending client transactions + associated with this response context when it receives a 6xx + response. A pending client transaction is one that has + received a provisional response, but no final response (it is + in the proceeding state) and has not had an associated CANCEL + generated for it. Generating CANCEL requests is described in + Section 9.1. + + The requirement to CANCEL pending client transactions upon + forwarding a final response does not guarantee that an endpoint + will not receive multiple 200 (OK) responses to an INVITE. 200 + (OK) responses on more than one branch may be generated before + the CANCEL requests can be sent and processed. Further, it is + reasonable to expect that a future extension may override this + requirement to issue CANCEL requests. + +16.8 Processing Timer C + + If timer C should fire, the proxy MUST either reset the timer with + any value it chooses, or terminate the client transaction. If the + client transaction has received a provisional response, the proxy + MUST generate a CANCEL request matching that transaction. If the + client transaction has not received a provisional response, the proxy + MUST behave as if the transaction received a 408 (Request Timeout) + response. + + + +Rosenberg, et. al. Standards Track [Page 114] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Allowing the proxy to reset the timer allows the proxy to dynamically + extend the transaction's lifetime based on current conditions (such + as utilization) when the timer fires. + +16.9 Handling Transport Errors + + If the transport layer notifies a proxy of an error when it tries to + forward a request (see Section 18.4), the proxy MUST behave as if the + forwarded request received a 503 (Service Unavailable) response. + + If the proxy is notified of an error when forwarding a response, it + drops the response. The proxy SHOULD NOT cancel any outstanding + client transactions associated with this response context due to this + notification. + + If a proxy cancels its outstanding client transactions, a single + malicious or misbehaving client can cause all transactions to fail + through its Via header field. + +16.10 CANCEL Processing + + A stateful proxy MAY generate a CANCEL to any other request it has + generated at any time (subject to receiving a provisional response to + that request as described in section 9.1). A proxy MUST cancel any + pending client transactions associated with a response context when + it receives a matching CANCEL request. + + A stateful proxy MAY generate CANCEL requests for pending INVITE + client transactions based on the period specified in the INVITE's + Expires header field elapsing. However, this is generally + unnecessary since the endpoints involved will take care of signaling + the end of the transaction. + + While a CANCEL request is handled in a stateful proxy by its own + server transaction, a new response context is not created for it. + Instead, the proxy layer searches its existing response contexts for + the server transaction handling the request associated with this + CANCEL. If a matching response context is found, the element MUST + immediately return a 200 (OK) response to the CANCEL request. In + this case, the element is acting as a user agent server as defined in + Section 8.2. Furthermore, the element MUST generate CANCEL requests + for all pending client transactions in the context as described in + Section 16.7 step 10. + + If a response context is not found, the element does not have any + knowledge of the request to apply the CANCEL to. It MUST statelessly + forward the CANCEL request (it may have statelessly forwarded the + associated request previously). + + + +Rosenberg, et. al. Standards Track [Page 115] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +16.11 Stateless Proxy + + When acting statelessly, a proxy is a simple message forwarder. Much + of the processing performed when acting statelessly is the same as + when behaving statefully. The differences are detailed here. + + A stateless proxy does not have any notion of a transaction, or of + the response context used to describe stateful proxy behavior. + Instead, the stateless proxy takes messages, both requests and + responses, directly from the transport layer (See section 18). As a + result, stateless proxies do not retransmit messages on their own. + They do, however, forward all retransmissions they receive (they do + not have the ability to distinguish a retransmission from the + original message). Furthermore, when handling a request statelessly, + an element MUST NOT generate its own 100 (Trying) or any other + provisional response. + + A stateless proxy MUST validate a request as described in Section + 16.3 + + A stateless proxy MUST follow the request processing steps described + in Sections 16.4 through 16.5 with the following exception: + + o A stateless proxy MUST choose one and only one target from the + target set. This choice MUST only rely on fields in the + message and time-invariant properties of the server. In + particular, a retransmitted request MUST be forwarded to the + same destination each time it is processed. Furthermore, + CANCEL and non-Routed ACK requests MUST generate the same + choice as their associated INVITE. + + A stateless proxy MUST follow the request processing steps described + in Section 16.6 with the following exceptions: + + o The requirement for unique branch IDs across space and time + applies to stateless proxies as well. However, a stateless + proxy cannot simply use a random number generator to compute + the first component of the branch ID, as described in Section + 16.6 bullet 8. This is because retransmissions of a request + need to have the same value, and a stateless proxy cannot tell + a retransmission from the original request. Therefore, the + component of the branch parameter that makes it unique MUST be + the same each time a retransmitted request is forwarded. Thus + for a stateless proxy, the branch parameter MUST be computed as + a combinatoric function of message parameters which are + invariant on retransmission. + + + + + +Rosenberg, et. al. Standards Track [Page 116] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The stateless proxy MAY use any technique it likes to guarantee + uniqueness of its branch IDs across transactions. However, the + following procedure is RECOMMENDED. The proxy examines the + branch ID in the topmost Via header field of the received + request. If it begins with the magic cookie, the first + component of the branch ID of the outgoing request is computed + as a hash of the received branch ID. Otherwise, the first + component of the branch ID is computed as a hash of the topmost + Via, the tag in the To header field, the tag in the From header + field, the Call-ID header field, the CSeq number (but not + method), and the Request-URI from the received request. One of + these fields will always vary across two different + transactions. + + o All other message transformations specified in Section 16.6 + MUST result in the same transformation of a retransmitted + request. In particular, if the proxy inserts a Record-Route + value or pushes URIs into the Route header field, it MUST place + the same values in retransmissions of the request. As for the + Via branch parameter, this implies that the transformations + MUST be based on time-invariant configuration or + retransmission-invariant properties of the request. + + o A stateless proxy determines where to forward the request as + described for stateful proxies in Section 16.6 Item 10. The + request is sent directly to the transport layer instead of + through a client transaction. + + Since a stateless proxy must forward retransmitted requests to + the same destination and add identical branch parameters to + each of them, it can only use information from the message + itself and time-invariant configuration data for those + calculations. If the configuration state is not time-invariant + (for example, if a routing table is updated) any requests that + could be affected by the change may not be forwarded + statelessly during an interval equal to the transaction timeout + window before or after the change. The method of processing + the affected requests in that interval is an implementation + decision. A common solution is to forward them transaction + statefully. + + Stateless proxies MUST NOT perform special processing for CANCEL + requests. They are processed by the above rules as any other + requests. In particular, a stateless proxy applies the same Route + header field processing to CANCEL requests that it applies to any + other request. + + + + + +Rosenberg, et. al. Standards Track [Page 117] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Response processing as described in Section 16.7 does not apply to a + proxy behaving statelessly. When a response arrives at a stateless + proxy, the proxy MUST inspect the sent-by value in the first + (topmost) Via header field value. If that address matches the proxy, + (it equals a value this proxy has inserted into previous requests) + the proxy MUST remove that header field value from the response and + forward the result to the location indicated in the next Via header + field value. The proxy MUST NOT add to, modify, or remove the + message body. Unless specified otherwise, the proxy MUST NOT remove + any other header field values. If the address does not match the + proxy, the message MUST be silently discarded. + +16.12 Summary of Proxy Route Processing + + In the absence of local policy to the contrary, the processing a + proxy performs on a request containing a Route header field can be + summarized in the following steps. + + 1. The proxy will inspect the Request-URI. If it indicates a + resource owned by this proxy, the proxy will replace it with + the results of running a location service. Otherwise, the + proxy will not change the Request-URI. + + 2. The proxy will inspect the URI in the topmost Route header + field value. If it indicates this proxy, the proxy removes it + from the Route header field (this route node has been + reached). + + 3. The proxy will forward the request to the resource indicated + by the URI in the topmost Route header field value or in the + Request-URI if no Route header field is present. The proxy + determines the address, port and transport to use when + forwarding the request by applying the procedures in [4] to + that URI. + + If no strict-routing elements are encountered on the path of the + request, the Request-URI will always indicate the target of the + request. + +16.12.1 Examples + +16.12.1.1 Basic SIP Trapezoid + + This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with + both proxies record-routing. Here is the flow. + + + + + + +Rosenberg, et. al. Standards Track [Page 118] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + U1 sends: + + INVITE sip:callee@domain.com SIP/2.0 + Contact: sip:caller@u1.example.com + + to P1. P1 is an outbound proxy. P1 is not responsible for + domain.com, so it looks it up in DNS and sends it there. It also + adds a Record-Route header field value: + + INVITE sip:callee@domain.com SIP/2.0 + Contact: sip:caller@u1.example.com + Record-Route: <sip:p1.example.com;lr> + + P2 gets this. It is responsible for domain.com so it runs a location + service and rewrites the Request-URI. It also adds a Record-Route + header field value. There is no Route header field, so it resolves + the new Request-URI to determine where to send the request: + + INVITE sip:callee@u2.domain.com SIP/2.0 + Contact: sip:caller@u1.example.com + Record-Route: <sip:p2.domain.com;lr> + Record-Route: <sip:p1.example.com;lr> + + The callee at u2.domain.com gets this and responds with a 200 OK: + + SIP/2.0 200 OK + Contact: sip:callee@u2.domain.com + Record-Route: <sip:p2.domain.com;lr> + Record-Route: <sip:p1.example.com;lr> + + The callee at u2 also sets its dialog state's remote target URI to + sip:caller@u1.example.com and its route set to: + + (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) + + This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its + dialog state's remote target URI to sip:callee@u2.domain.com and its + route set to: + + (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) + + Since all the route set elements contain the lr parameter, U1 + constructs the following BYE request: + + BYE sip:callee@u2.domain.com SIP/2.0 + Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> + + + + + +Rosenberg, et. al. Standards Track [Page 119] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + As any other element (including proxies) would do, it resolves the + URI in the topmost Route header field value using DNS to determine + where to send the request. This goes to P1. P1 notices that it is + not responsible for the resource indicated in the Request-URI so it + doesn't change it. It does see that it is the first value in the + Route header field, so it removes that value, and forwards the + request to P2: + + BYE sip:callee@u2.domain.com SIP/2.0 + Route: <sip:p2.domain.com;lr> + + P2 also notices it is not responsible for the resource indicated by + the Request-URI (it is responsible for domain.com, not + u2.domain.com), so it doesn't change it. It does see itself in the + first Route header field value, so it removes it and forwards the + following to u2.domain.com based on a DNS lookup against the + Request-URI: + + BYE sip:callee@u2.domain.com SIP/2.0 + +16.12.1.2 Traversing a Strict-Routing Proxy + + In this scenario, a dialog is established across four proxies, each + of which adds Record-Route header field values. The third proxy + implements the strict-routing procedures specified in RFC 2543 and + many works in progress. + + U1->P1->P2->P3->P4->U2 + + The INVITE arriving at U2 contains: + + INVITE sip:callee@u2.domain.com SIP/2.0 + Contact: sip:caller@u1.example.com + Record-Route: <sip:p4.domain.com;lr> + Record-Route: <sip:p3.middle.com> + Record-Route: <sip:p2.example.com;lr> + Record-Route: <sip:p1.example.com;lr> + + Which U2 responds to with a 200 OK. Later, U2 sends the following + BYE request to P4 based on the first Route header field value. + + BYE sip:caller@u1.example.com SIP/2.0 + Route: <sip:p4.domain.com;lr> + Route: <sip:p3.middle.com> + Route: <sip:p2.example.com;lr> + Route: <sip:p1.example.com;lr> + + + + + +Rosenberg, et. al. Standards Track [Page 120] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + P4 is not responsible for the resource indicated in the Request-URI + so it will leave it alone. It notices that it is the element in the + first Route header field value so it removes it. It then prepares to + send the request based on the now first Route header field value of + sip:p3.middle.com, but it notices that this URI does not contain the + lr parameter, so before sending, it reformats the request to be: + + BYE sip:p3.middle.com SIP/2.0 + Route: <sip:p2.example.com;lr> + Route: <sip:p1.example.com;lr> + Route: <sip:caller@u1.example.com> + + P3 is a strict router, so it forwards the following to P2: + + BYE sip:p2.example.com;lr SIP/2.0 + Route: <sip:p1.example.com;lr> + Route: <sip:caller@u1.example.com> + + P2 sees the request-URI is a value it placed into a Record-Route + header field, so before further processing, it rewrites the request + to be: + + BYE sip:caller@u1.example.com SIP/2.0 + Route: <sip:p1.example.com;lr> + + P2 is not responsible for u1.example.com, so it sends the request to + P1 based on the resolution of the Route header field value. + + P1 notices itself in the topmost Route header field value, so it + removes it, resulting in: + + BYE sip:caller@u1.example.com SIP/2.0 + + Since P1 is not responsible for u1.example.com and there is no Route + header field, P1 will forward the request to u1.example.com based on + the Request-URI. + +16.12.1.3 Rewriting Record-Route Header Field Values + + In this scenario, U1 and U2 are in different private namespaces and + they enter a dialog through a proxy P1, which acts as a gateway + between the namespaces. + + U1->P1->U2 + + + + + + + +Rosenberg, et. al. Standards Track [Page 121] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + U1 sends: + + INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 + Contact: <sip:caller@u1.leftprivatespace.com> + + P1 uses its location service and sends the following to U2: + + INVITE sip:callee@rightprivatespace.com SIP/2.0 + Contact: <sip:caller@u1.leftprivatespace.com> + Record-Route: <sip:gateway.rightprivatespace.com;lr> + + U2 sends this 200 (OK) back to P1: + + SIP/2.0 200 OK + Contact: <sip:callee@u2.rightprivatespace.com> + Record-Route: <sip:gateway.rightprivatespace.com;lr> + + P1 rewrites its Record-Route header parameter to provide a value that + U1 will find useful, and sends the following to U1: + + SIP/2.0 200 OK + Contact: <sip:callee@u2.rightprivatespace.com> + Record-Route: <sip:gateway.leftprivatespace.com;lr> + + Later, U1 sends the following BYE request to P1: + + BYE sip:callee@u2.rightprivatespace.com SIP/2.0 + Route: <sip:gateway.leftprivatespace.com;lr> + + which P1 forwards to U2 as: + + BYE sip:callee@u2.rightprivatespace.com SIP/2.0 + +17 Transactions + + SIP is a transactional protocol: interactions between components take + place in a series of independent message exchanges. Specifically, a + SIP transaction consists of a single request and any responses to + that request, which include zero or more provisional responses and + one or more final responses. In the case of a transaction where the + request was an INVITE (known as an INVITE transaction), the + transaction also includes the ACK only if the final response was not + a 2xx response. If the response was a 2xx, the ACK is not considered + part of the transaction. + + The reason for this separation is rooted in the importance of + delivering all 200 (OK) responses to an INVITE to the UAC. To + deliver them all to the UAC, the UAS alone takes responsibility + + + +Rosenberg, et. al. Standards Track [Page 122] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + for retransmitting them (see Section 13.3.1.4), and the UAC alone + takes responsibility for acknowledging them with ACK (see Section + 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is + effectively considered its own transaction. + + Transactions have a client side and a server side. The client side + is known as a client transaction and the server side as a server + transaction. The client transaction sends the request, and the + server transaction sends the response. The client and server + transactions are logical functions that are embedded in any number of + elements. Specifically, they exist within user agents and stateful + proxy servers. Consider the example in Section 4. In this example, + the UAC executes the client transaction, and its outbound proxy + executes the server transaction. The outbound proxy also executes a + client transaction, which sends the request to a server transaction + in the inbound proxy. That proxy also executes a client transaction, + which in turn sends the request to a server transaction in the UAS. + This is shown in Figure 4. + + +---------+ +---------+ +---------+ +---------+ + | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | + | |C||------->||S| |C||------->||S| |C||------->||S| | + | |l|| ||e| |l|| ||e| |l|| ||e| | + | |i|| ||r| |i|| ||r| |i|| ||r| | + | |e|| ||v| |e|| ||v| |e|| ||v| | + | |n|| ||e| |n|| ||e| |n|| ||e| | + | |t|| ||r| |t|| ||r| |t|| ||r| | + | | || || | | || || | | || || | | + | |T|| ||T| |T|| ||T| |T|| ||T| | + | |r|| ||r| |r|| ||r| |r|| ||r| | + | |a|| ||a| |a|| ||a| |a|| ||a| | + | |n|| ||n| |n|| ||n| |n|| ||n| | + | |s||Response||s| |s||Response||s| |s||Response||s| | + | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | + +---------+ +---------+ +---------+ +---------+ + UAC Outbound Inbound UAS + Proxy Proxy + + Figure 4: Transaction relationships + + A stateless proxy does not contain a client or server transaction. + The transaction exists between the UA or stateful proxy on one side, + and the UA or stateful proxy on the other side. As far as SIP + transactions are concerned, stateless proxies are effectively + transparent. The purpose of the client transaction is to receive a + request from the element in which the client is embedded (call this + element the "Transaction User" or TU; it can be a UA or a stateful + proxy), and reliably deliver the request to a server transaction. + + + +Rosenberg, et. al. Standards Track [Page 123] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The client transaction is also responsible for receiving responses + and delivering them to the TU, filtering out any response + retransmissions or disallowed responses (such as a response to ACK). + Additionally, in the case of an INVITE request, the client + transaction is responsible for generating the ACK request for any + final response accepting a 2xx response. + + Similarly, the purpose of the server transaction is to receive + requests from the transport layer and deliver them to the TU. The + server transaction filters any request retransmissions from the + network. The server transaction accepts responses from the TU and + delivers them to the transport layer for transmission over the + network. In the case of an INVITE transaction, it absorbs the ACK + request for any final response excepting a 2xx response. + + The 2xx response and its ACK receive special treatment. This + response is retransmitted only by a UAS, and its ACK generated only + by the UAC. This end-to-end treatment is needed so that a caller + knows the entire set of users that have accepted the call. Because + of this special handling, retransmissions of the 2xx response are + handled by the UA core, not the transaction layer. Similarly, + generation of the ACK for the 2xx is handled by the UA core. Each + proxy along the path merely forwards each 2xx response to INVITE and + its corresponding ACK. + +17.1 Client Transaction + + The client transaction provides its functionality through the + maintenance of a state machine. + + The TU communicates with the client transaction through a simple + interface. When the TU wishes to initiate a new transaction, it + creates a client transaction and passes it the SIP request to send + and an IP address, port, and transport to which to send it. The + client transaction begins execution of its state machine. Valid + responses are passed up to the TU from the client transaction. + + There are two types of client transaction state machines, depending + on the method of the request passed by the TU. One handles client + transactions for INVITE requests. This type of machine is referred + to as an INVITE client transaction. Another type handles client + transactions for all requests except INVITE and ACK. This is + referred to as a non-INVITE client transaction. There is no client + transaction for ACK. If the TU wishes to send an ACK, it passes one + directly to the transport layer for transmission. + + + + + + +Rosenberg, et. al. Standards Track [Page 124] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The INVITE transaction is different from those of other methods + because of its extended duration. Normally, human input is required + in order to respond to an INVITE. The long delays expected for + sending a response argue for a three-way handshake. On the other + hand, requests of other methods are expected to complete rapidly. + Because of the non-INVITE transaction's reliance on a two-way + handshake, TUs SHOULD respond immediately to non-INVITE requests. + +17.1.1 INVITE Client Transaction + +17.1.1.1 Overview of INVITE Transaction + + The INVITE transaction consists of a three-way handshake. The client + transaction sends an INVITE, the server transaction sends responses, + and the client transaction sends an ACK. For unreliable transports + (such as UDP), the client transaction retransmits requests at an + interval that starts at T1 seconds and doubles after every + retransmission. T1 is an estimate of the round-trip time (RTT), and + it defaults to 500 ms. Nearly all of the transaction timers + described here scale with T1, and changing T1 adjusts their values. + The request is not retransmitted over reliable transports. After + receiving a 1xx response, any retransmissions cease altogether, and + the client waits for further responses. The server transaction can + send additional 1xx responses, which are not transmitted reliably by + the server transaction. Eventually, the server transaction decides + to send a final response. For unreliable transports, that response + is retransmitted periodically, and for reliable transports, it is + sent once. For each final response that is received at the client + transaction, the client transaction sends an ACK, the purpose of + which is to quench retransmissions of the response. + +17.1.1.2 Formal Description + + The state machine for the INVITE client transaction is shown in + Figure 5. The initial state, "calling", MUST be entered when the TU + initiates a new client transaction with an INVITE request. The + client transaction MUST pass the request to the transport layer for + transmission (see Section 18). If an unreliable transport is being + used, the client transaction MUST start timer A with a value of T1. + If a reliable transport is being used, the client transaction SHOULD + NOT start timer A (Timer A controls request retransmissions). For + any transport, the client transaction MUST start timer B with a value + of 64*T1 seconds (Timer B controls transaction timeouts). + + When timer A fires, the client transaction MUST retransmit the + request by passing it to the transport layer, and MUST reset the + timer with a value of 2*T1. The formal definition of retransmit + + + + +Rosenberg, et. al. Standards Track [Page 125] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + within the context of the transaction layer is to take the message + previously sent to the transport layer and pass it to the transport + layer once more. + + When timer A fires 2*T1 seconds later, the request MUST be + retransmitted again (assuming the client transaction is still in this + state). This process MUST continue so that the request is + retransmitted with intervals that double after each transmission. + These retransmissions SHOULD only be done while the client + transaction is in the "calling" state. + + The default value for T1 is 500 ms. T1 is an estimate of the RTT + between the client and server transactions. Elements MAY (though it + is NOT RECOMMENDED) use smaller values of T1 within closed, private + networks that do not permit general Internet connection. T1 MAY be + chosen larger, and this is RECOMMENDED if it is known in advance + (such as on high latency access links) that the RTT is larger. + Whatever the value of T1, the exponential backoffs on retransmissions + described in this section MUST be used. + + If the client transaction is still in the "Calling" state when timer + B fires, the client transaction SHOULD inform the TU that a timeout + has occurred. The client transaction MUST NOT generate an ACK. The + value of 64*T1 is equal to the amount of time required to send seven + requests in the case of an unreliable transport. + + If the client transaction receives a provisional response while in + the "Calling" state, it transitions to the "Proceeding" state. In the + "Proceeding" state, the client transaction SHOULD NOT retransmit the + request any longer. Furthermore, the provisional response MUST be + passed to the TU. Any further provisional responses MUST be passed + up to the TU while in the "Proceeding" state. + + When in either the "Calling" or "Proceeding" states, reception of a + response with status code from 300-699 MUST cause the client + transaction to transition to "Completed". The client transaction + MUST pass the received response up to the TU, and the client + transaction MUST generate an ACK request, even if the transport is + reliable (guidelines for constructing the ACK from the response are + given in Section 17.1.1.3) and then pass the ACK to the transport + layer for transmission. The ACK MUST be sent to the same address, + port, and transport to which the original request was sent. The + client transaction SHOULD start timer D when it enters the + "Completed" state, with a value of at least 32 seconds for unreliable + transports, and a value of zero seconds for reliable transports. + Timer D reflects the amount of time that the server transaction can + remain in the "Completed" state when unreliable transports are used. + This is equal to Timer H in the INVITE server transaction, whose + + + +Rosenberg, et. al. Standards Track [Page 126] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + default is 64*T1. However, the client transaction does not know the + value of T1 in use by the server transaction, so an absolute minimum + of 32s is used instead of basing Timer D on T1. + + Any retransmissions of the final response that are received while in + the "Completed" state MUST cause the ACK to be re-passed to the + transport layer for retransmission, but the newly received response + MUST NOT be passed up to the TU. A retransmission of the response is + defined as any response which would match the same client transaction + based on the rules of Section 17.1.3. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 127] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + |INVITE from TU + Timer A fires |INVITE sent + Reset A, V Timer B fires + INVITE sent +-----------+ or Transport Err. + +---------| |---------------+inform TU + | | Calling | | + +-------->| |-------------->| + +-----------+ 2xx | + | | 2xx to TU | + | |1xx | + 300-699 +---------------+ |1xx to TU | + ACK sent | | | +resp. to TU | 1xx V | + | 1xx to TU -----------+ | + | +---------| | | + | | |Proceeding |-------------->| + | +-------->| | 2xx | + | +-----------+ 2xx to TU | + | 300-699 | | + | ACK sent, | | + | resp. to TU| | + | | | NOTE: + | 300-699 V | + | ACK sent +-----------+Transport Err. | transitions + | +---------| |Inform TU | labeled with + | | | Completed |-------------->| the event + | +-------->| | | over the action + | +-----------+ | to take + | ^ | | + | | | Timer D fires | + +--------------+ | - | + | | + V | + +-----------+ | + | | | + | Terminated|<--------------+ + | | + +-----------+ + + Figure 5: INVITE client transaction + + If timer D fires while the client transaction is in the "Completed" + state, the client transaction MUST move to the terminated state. + + When in either the "Calling" or "Proceeding" states, reception of a + 2xx response MUST cause the client transaction to enter the + "Terminated" state, and the response MUST be passed up to the TU. + The handling of this response depends on whether the TU is a proxy + + + +Rosenberg, et. al. Standards Track [Page 128] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + core or a UAC core. A UAC core will handle generation of the ACK for + this response, while a proxy core will always forward the 200 (OK) + upstream. The differing treatment of 200 (OK) between proxy and UAC + is the reason that handling of it does not take place in the + transaction layer. + + The client transaction MUST be destroyed the instant it enters the + "Terminated" state. This is actually necessary to guarantee correct + operation. The reason is that 2xx responses to an INVITE are treated + differently; each one is forwarded by proxies, and the ACK handling + in a UAC is different. Thus, each 2xx needs to be passed to a proxy + core (so that it can be forwarded) and to a UAC core (so it can be + acknowledged). No transaction layer processing takes place. + Whenever a response is received by the transport, if the transport + layer finds no matching client transaction (using the rules of + Section 17.1.3), the response is passed directly to the core. Since + the matching client transaction is destroyed by the first 2xx, + subsequent 2xx will find no match and therefore be passed to the + core. + +17.1.1.3 Construction of the ACK Request + + This section specifies the construction of ACK requests sent within + the client transaction. A UAC core that generates an ACK for 2xx + MUST instead follow the rules described in Section 13. + + The ACK request constructed by the client transaction MUST contain + values for the Call-ID, From, and Request-URI that are equal to the + values of those header fields in the request passed to the transport + by the client transaction (call this the "original request"). The To + header field in the ACK MUST equal the To header field in the + response being acknowledged, and therefore will usually differ from + the To header field in the original request by the addition of the + tag parameter. The ACK MUST contain a single Via header field, and + this MUST be equal to the top Via header field of the original + request. The CSeq header field in the ACK MUST contain the same + value for the sequence number as was present in the original request, + but the method parameter MUST be equal to "ACK". + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 129] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + If the INVITE request whose response is being acknowledged had Route + header fields, those header fields MUST appear in the ACK. This is + to ensure that the ACK can be routed properly through any downstream + stateless proxies. + + Although any request MAY contain a body, a body in an ACK is special + since the request cannot be rejected if the body is not understood. + Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, + but if done, the body types are restricted to any that appeared in + the INVITE, assuming that the response to the INVITE was not 415. If + it was, the body in the ACK MAY be any type listed in the Accept + header field in the 415. + + For example, consider the following request: + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff + To: Bob <sip:bob@biloxi.com> + From: Alice <sip:alice@atlanta.com>;tag=88sja8x + Max-Forwards: 70 + Call-ID: 987asjd97y7atg + CSeq: 986759 INVITE + + The ACK request for a non-2xx final response to this request would + look like this: + + ACK sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff + To: Bob <sip:bob@biloxi.com>;tag=99sa0xk + From: Alice <sip:alice@atlanta.com>;tag=88sja8x + Max-Forwards: 70 + Call-ID: 987asjd97y7atg + CSeq: 986759 ACK + +17.1.2 Non-INVITE Client Transaction + +17.1.2.1 Overview of the non-INVITE Transaction + + Non-INVITE transactions do not make use of ACK. They are simple + request-response interactions. For unreliable transports, requests + are retransmitted at an interval which starts at T1 and doubles until + it hits T2. If a provisional response is received, retransmissions + continue for unreliable transports, but at an interval of T2. The + server transaction retransmits the last response it sent, which can + be a provisional or final response, only when a retransmission of the + request is received. This is why request retransmissions need to + continue even after a provisional response; they are to ensure + reliable delivery of the final response. + + + +Rosenberg, et. al. Standards Track [Page 130] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Unlike an INVITE transaction, a non-INVITE transaction has no special + handling for the 2xx response. The result is that only a single 2xx + response to a non-INVITE is ever delivered to a UAC. + +17.1.2.2 Formal Description + + The state machine for the non-INVITE client transaction is shown in + Figure 6. It is very similar to the state machine for INVITE. + + The "Trying" state is entered when the TU initiates a new client + transaction with a request. When entering this state, the client + transaction SHOULD set timer F to fire in 64*T1 seconds. The request + MUST be passed to the transport layer for transmission. If an + unreliable transport is in use, the client transaction MUST set timer + E to fire in T1 seconds. If timer E fires while still in this state, + the timer is reset, but this time with a value of MIN(2*T1, T2). + When the timer fires again, it is reset to a MIN(4*T1, T2). This + process continues so that retransmissions occur with an exponentially + increasing interval that caps at T2. The default value of T2 is 4s, + and it represents the amount of time a non-INVITE server transaction + will take to respond to a request, if it does not respond + immediately. For the default values of T1 and T2, this results in + intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. + + If Timer F fires while the client transaction is still in the + "Trying" state, the client transaction SHOULD inform the TU about the + timeout, and then it SHOULD enter the "Terminated" state. If a + provisional response is received while in the "Trying" state, the + response MUST be passed to the TU, and then the client transaction + SHOULD move to the "Proceeding" state. If a final response (status + codes 200-699) is received while in the "Trying" state, the response + MUST be passed to the TU, and the client transaction MUST transition + to the "Completed" state. + + If Timer E fires while in the "Proceeding" state, the request MUST be + passed to the transport layer for retransmission, and Timer E MUST be + reset with a value of T2 seconds. If timer F fires while in the + "Proceeding" state, the TU MUST be informed of a timeout, and the + client transaction MUST transition to the terminated state. If a + final response (status codes 200-699) is received while in the + "Proceeding" state, the response MUST be passed to the TU, and the + client transaction MUST transition to the "Completed" state. + + Once the client transaction enters the "Completed" state, it MUST set + Timer K to fire in T4 seconds for unreliable transports, and zero + seconds for reliable transports. The "Completed" state exists to + buffer any additional response retransmissions that may be received + (which is why the client transaction remains there only for + + + +Rosenberg, et. al. Standards Track [Page 131] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + unreliable transports). T4 represents the amount of time the network + will take to clear messages between client and server transactions. + The default value of T4 is 5s. A response is a retransmission when + it matches the same transaction, using the rules specified in Section + 17.1.3. If Timer K fires while in this state, the client transaction + MUST transition to the "Terminated" state. + + Once the transaction is in the terminated state, it MUST be destroyed + immediately. + +17.1.3 Matching Responses to Client Transactions + + When the transport layer in the client receives a response, it has to + determine which client transaction will handle the response, so that + the processing of Sections 17.1.1 and 17.1.2 can take place. The + branch parameter in the top Via header field is used for this + purpose. A response matches a client transaction under two + conditions: + + 1. If the response has the same value of the branch parameter in + the top Via header field as the branch parameter in the top + Via header field of the request that created the transaction. + + 2. If the method parameter in the CSeq header field matches the + method of the request that created the transaction. The + method is needed since a CANCEL request constitutes a + different transaction, but shares the same value of the branch + parameter. + + If a request is sent via multicast, it is possible that it will + generate multiple responses from different servers. These responses + will all have the same branch parameter in the topmost Via, but vary + in the To tag. The first response received, based on the rules + above, will be used, and others will be viewed as retransmissions. + That is not an error; multicast SIP provides only a rudimentary + "single-hop-discovery-like" service that is limited to processing a + single response. See Section 18.1.1 for details. + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 132] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +17.1.4 Handling Transport Errors + + |Request from TU + |send request + Timer E V + send request +-----------+ + +---------| |-------------------+ + | | Trying | Timer F | + +-------->| | or Transport Err.| + +-----------+ inform TU | + 200-699 | | | + resp. to TU | |1xx | + +---------------+ |resp. to TU | + | | | + | Timer E V Timer F | + | send req +-----------+ or Transport Err. | + | +---------| | inform TU | + | | |Proceeding |------------------>| + | +-------->| |-----+ | + | +-----------+ |1xx | + | | ^ |resp to TU | + | 200-699 | +--------+ | + | resp. to TU | | + | | | + | V | + | +-----------+ | + | | | | + | | Completed | | + | | | | + | +-----------+ | + | ^ | | + | | | Timer K | + +--------------+ | - | + | | + V | + NOTE: +-----------+ | + | | | + transitions | Terminated|<------------------+ + labeled with | | + the event +-----------+ + over the action + to take + + Figure 6: non-INVITE client transaction + + When the client transaction sends a request to the transport layer to + be sent, the following procedures are followed if the transport layer + indicates a failure. + + + +Rosenberg, et. al. Standards Track [Page 133] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The client transaction SHOULD inform the TU that a transport failure + has occurred, and the client transaction SHOULD transition directly + to the "Terminated" state. The TU will handle the failover + mechanisms described in [4]. + +17.2 Server Transaction + + The server transaction is responsible for the delivery of requests to + the TU and the reliable transmission of responses. It accomplishes + this through a state machine. Server transactions are created by the + core when a request is received, and transaction handling is desired + for that request (this is not always the case). + + As with the client transactions, the state machine depends on whether + the received request is an INVITE request. + +17.2.1 INVITE Server Transaction + + The state diagram for the INVITE server transaction is shown in + Figure 7. + + When a server transaction is constructed for a request, it enters the + "Proceeding" state. The server transaction MUST generate a 100 + (Trying) response unless it knows that the TU will generate a + provisional or final response within 200 ms, in which case it MAY + generate a 100 (Trying) response. This provisional response is + needed to quench request retransmissions rapidly in order to avoid + network congestion. The 100 (Trying) response is constructed + according to the procedures in Section 8.2.6, except that the + insertion of tags in the To header field of the response (when none + was present in the request) is downgraded from MAY to SHOULD NOT. + The request MUST be passed to the TU. + + The TU passes any number of provisional responses to the server + transaction. So long as the server transaction is in the + "Proceeding" state, each of these MUST be passed to the transport + layer for transmission. They are not sent reliably by the + transaction layer (they are not retransmitted by it) and do not cause + a change in the state of the server transaction. If a request + retransmission is received while in the "Proceeding" state, the most + recent provisional response that was received from the TU MUST be + passed to the transport layer for retransmission. A request is a + retransmission if it matches the same server transaction based on the + rules of Section 17.2.3. + + If, while in the "Proceeding" state, the TU passes a 2xx response to + the server transaction, the server transaction MUST pass this + response to the transport layer for transmission. It is not + + + +Rosenberg, et. al. Standards Track [Page 134] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + retransmitted by the server transaction; retransmissions of 2xx + responses are handled by the TU. The server transaction MUST then + transition to the "Terminated" state. + + While in the "Proceeding" state, if the TU passes a response with + status code from 300 to 699 to the server transaction, the response + MUST be passed to the transport layer for transmission, and the state + machine MUST enter the "Completed" state. For unreliable transports, + timer G is set to fire in T1 seconds, and is not set to fire for + reliable transports. + + This is a change from RFC 2543, where responses were always + retransmitted, even over reliable transports. + + When the "Completed" state is entered, timer H MUST be set to fire in + 64*T1 seconds for all transports. Timer H determines when the server + transaction abandons retransmitting the response. Its value is + chosen to equal Timer B, the amount of time a client transaction will + continue to retry sending a request. If timer G fires, the response + is passed to the transport layer once more for retransmission, and + timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when + timer G fires, the response is passed to the transport again for + transmission, and timer G is reset with a value that doubles, unless + that value exceeds T2, in which case it is reset with the value of + T2. This is identical to the retransmit behavior for requests in the + "Trying" state of the non-INVITE client transaction. Furthermore, + while in the "Completed" state, if a request retransmission is + received, the server SHOULD pass the response to the transport for + retransmission. + + If an ACK is received while the server transaction is in the + "Completed" state, the server transaction MUST transition to the + "Confirmed" state. As Timer G is ignored in this state, any + retransmissions of the response will cease. + + If timer H fires while in the "Completed" state, it implies that the + ACK was never received. In this case, the server transaction MUST + transition to the "Terminated" state, and MUST indicate to the TU + that a transaction failure has occurred. + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 135] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + |INVITE + |pass INV to TU + INVITE V send 100 if TU won't in 200ms + send response+-----------+ + +--------| |--------+101-199 from TU + | | Proceeding| |send response + +------->| |<-------+ + | | Transport Err. + | | Inform TU + | |--------------->+ + +-----------+ | + 300-699 from TU | |2xx from TU | + send response | |send response | + | +------------------>+ + | | + INVITE V Timer G fires | + send response+-----------+ send response | + +--------| |--------+ | + | | Completed | | | + +------->| |<-------+ | + +-----------+ | + | | | + ACK | | | + - | +------------------>+ + | Timer H fires | + V or Transport Err.| + +-----------+ Inform TU | + | | | + | Confirmed | | + | | | + +-----------+ | + | | + |Timer I fires | + |- | + | | + V | + +-----------+ | + | | | + | Terminated|<---------------+ + | | + +-----------+ + + Figure 7: INVITE server transaction + + + + + + + + +Rosenberg, et. al. Standards Track [Page 136] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The purpose of the "Confirmed" state is to absorb any additional ACK + messages that arrive, triggered from retransmissions of the final + response. When this state is entered, timer I is set to fire in T4 + seconds for unreliable transports, and zero seconds for reliable + transports. Once timer I fires, the server MUST transition to the + "Terminated" state. + + Once the transaction is in the "Terminated" state, it MUST be + destroyed immediately. As with client transactions, this is needed + to ensure reliability of the 2xx responses to INVITE. + +17.2.2 Non-INVITE Server Transaction + + The state machine for the non-INVITE server transaction is shown in + Figure 8. + + The state machine is initialized in the "Trying" state and is passed + a request other than INVITE or ACK when initialized. This request is + passed up to the TU. Once in the "Trying" state, any further request + retransmissions are discarded. A request is a retransmission if it + matches the same server transaction, using the rules specified in + Section 17.2.3. + + While in the "Trying" state, if the TU passes a provisional response + to the server transaction, the server transaction MUST enter the + "Proceeding" state. The response MUST be passed to the transport + layer for transmission. Any further provisional responses that are + received from the TU while in the "Proceeding" state MUST be passed + to the transport layer for transmission. If a retransmission of the + request is received while in the "Proceeding" state, the most + recently sent provisional response MUST be passed to the transport + layer for retransmission. If the TU passes a final response (status + codes 200-699) to the server while in the "Proceeding" state, the + transaction MUST enter the "Completed" state, and the response MUST + be passed to the transport layer for transmission. + + When the server transaction enters the "Completed" state, it MUST set + Timer J to fire in 64*T1 seconds for unreliable transports, and zero + seconds for reliable transports. While in the "Completed" state, the + server transaction MUST pass the final response to the transport + layer for retransmission whenever a retransmission of the request is + received. Any other final responses passed by the TU to the server + transaction MUST be discarded while in the "Completed" state. The + server transaction remains in this state until Timer J fires, at + which point it MUST transition to the "Terminated" state. + + The server transaction MUST be destroyed the instant it enters the + "Terminated" state. + + + +Rosenberg, et. al. Standards Track [Page 137] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +17.2.3 Matching Requests to Server Transactions + + When a request is received from the network by the server, it has to + be matched to an existing transaction. This is accomplished in the + following manner. + + The branch parameter in the topmost Via header field of the request + is examined. If it is present and begins with the magic cookie + "z9hG4bK", the request was generated by a client transaction + compliant to this specification. Therefore, the branch parameter + will be unique across all transactions sent by that client. The + request matches a transaction if: + + 1. the branch parameter in the request is equal to the one in the + top Via header field of the request that created the + transaction, and + + 2. the sent-by value in the top Via of the request is equal to the + one in the request that created the transaction, and + + 3. the method of the request matches the one that created the + transaction, except for ACK, where the method of the request + that created the transaction is INVITE. + + This matching rule applies to both INVITE and non-INVITE transactions + alike. + + The sent-by value is used as part of the matching process because + there could be accidental or malicious duplication of branch + parameters from different clients. + + If the branch parameter in the top Via header field is not present, + or does not contain the magic cookie, the following procedures are + used. These exist to handle backwards compatibility with RFC 2543 + compliant implementations. + + The INVITE request matches a transaction if the Request-URI, To tag, + From tag, Call-ID, CSeq, and top Via header field match those of the + INVITE request which created the transaction. In this case, the + INVITE is a retransmission of the original one that created the + transaction. The ACK request matches a transaction if the Request- + URI, From tag, Call-ID, CSeq number (not the method), and top Via + header field match those of the INVITE request which created the + transaction, and the To tag of the ACK matches the To tag of the + response sent by the server transaction. Matching is done based on + the matching rules defined for each of those header fields. + Inclusion of the tag in the To header field in the ACK matching + process helps disambiguate ACK for 2xx from ACK for other responses + + + +Rosenberg, et. al. Standards Track [Page 138] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + at a proxy, which may have forwarded both responses (This can occur + in unusual conditions. Specifically, when a proxy forked a request, + and then crashes, the responses may be delivered to another proxy, + which might end up forwarding multiple responses upstream). An ACK + request that matches an INVITE transaction matched by a previous ACK + is considered a retransmission of that previous ACK. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 139] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + |Request received + |pass to TU + V + +-----------+ + | | + | Trying |-------------+ + | | | + +-----------+ |200-699 from TU + | |send response + |1xx from TU | + |send response | + | | + Request V 1xx from TU | + send response+-----------+send response| + +--------| |--------+ | + | | Proceeding| | | + +------->| |<-------+ | + +<--------------| | | + |Trnsprt Err +-----------+ | + |Inform TU | | + | | | + | |200-699 from TU | + | |send response | + | Request V | + | send response+-----------+ | + | +--------| | | + | | | Completed |<------------+ + | +------->| | + +<--------------| | + |Trnsprt Err +-----------+ + |Inform TU | + | |Timer J fires + | |- + | | + | V + | +-----------+ + | | | + +-------------->| Terminated| + | | + +-----------+ + + Figure 8: non-INVITE server transaction + + For all other request methods, a request is matched to a transaction + if the Request-URI, To tag, From tag, Call-ID, CSeq (including the + method), and top Via header field match those of the request that + created the transaction. Matching is done based on the matching + + + + +Rosenberg, et. al. Standards Track [Page 140] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + rules defined for each of those header fields. When a non-INVITE + request matches an existing transaction, it is a retransmission of + the request that created that transaction. + + Because the matching rules include the Request-URI, the server cannot + match a response to a transaction. When the TU passes a response to + the server transaction, it must pass it to the specific server + transaction for which the response is targeted. + +17.2.4 Handling Transport Errors + + When the server transaction sends a response to the transport layer + to be sent, the following procedures are followed if the transport + layer indicates a failure. + + First, the procedures in [4] are followed, which attempt to deliver + the response to a backup. If those should all fail, based on the + definition of failure in [4], the server transaction SHOULD inform + the TU that a failure has occurred, and SHOULD transition to the + terminated state. + +18 Transport + + The transport layer is responsible for the actual transmission of + requests and responses over network transports. This includes + determination of the connection to use for a request or response in + the case of connection-oriented transports. + + The transport layer is responsible for managing persistent + connections for transport protocols like TCP and SCTP, or TLS over + those, including ones opened to the transport layer. This includes + connections opened by the client or server transports, so that + connections are shared between client and server transport functions. + These connections are indexed by the tuple formed from the address, + port, and transport protocol at the far end of the connection. When + a connection is opened by the transport layer, this index is set to + the destination IP, port and transport. When the connection is + accepted by the transport layer, this index is set to the source IP + address, port number, and transport. Note that, because the source + port is often ephemeral, but it cannot be known whether it is + ephemeral or selected through procedures in [4], connections accepted + by the transport layer will frequently not be reused. The result is + that two proxies in a "peering" relationship using a connection- + oriented transport frequently will have two connections in use, one + for transactions initiated in each direction. + + + + + + +Rosenberg, et. al. Standards Track [Page 141] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + It is RECOMMENDED that connections be kept open for some + implementation-defined duration after the last message was sent or + received over that connection. This duration SHOULD at least equal + the longest amount of time the element would need in order to bring a + transaction from instantiation to the terminated state. This is to + make it likely that transactions are completed over the same + connection on which they are initiated (for example, request, + response, and in the case of INVITE, ACK for non-2xx responses). + This usually means at least 64*T1 (see Section 17.1.1.1 for a + definition of T1). However, it could be larger in an element that + has a TU using a large value for timer C (bullet 11 of Section 16.6), + for example. + + All SIP elements MUST implement UDP and TCP. SIP elements MAY + implement other protocols. + + Making TCP mandatory for the UA is a substantial change from RFC + 2543. It has arisen out of the need to handle larger messages, + which MUST use TCP, as discussed below. Thus, even if an element + never sends large messages, it may receive one and needs to be + able to handle them. + +18.1 Clients + +18.1.1 Sending Requests + + The client side of the transport layer is responsible for sending the + request and receiving responses. The user of the transport layer + passes the client transport the request, an IP address, port, + transport, and possibly TTL for multicast destinations. + + If a request is within 200 bytes of the path MTU, or if it is larger + than 1300 bytes and the path MTU is unknown, the request MUST be sent + using an RFC 2914 [43] congestion controlled transport protocol, such + as TCP. If this causes a change in the transport protocol from the + one indicated in the top Via, the value in the top Via MUST be + changed. This prevents fragmentation of messages over UDP and + provides congestion control for larger messages. However, + implementations MUST be able to handle messages up to the maximum + datagram packet size. For UDP, this size is 65,535 bytes, including + IP and UDP headers. + + The 200 byte "buffer" between the message size and the MTU + accommodates the fact that the response in SIP can be larger than + the request. This happens due to the addition of Record-Route + header field values to the responses to INVITE, for example. With + the extra buffer, the response can be about 170 bytes larger than + the request, and still not be fragmented on IPv4 (about 30 bytes + + + +Rosenberg, et. al. Standards Track [Page 142] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when + path MTU is not known, based on the assumption of a 1500 byte + Ethernet MTU. + + If an element sends a request over TCP because of these message size + constraints, and that request would have otherwise been sent over + UDP, if the attempt to establish the connection generates either an + ICMP Protocol Not Supported, or results in a TCP reset, the element + SHOULD retry the request, using UDP. This is only to provide + backwards compatibility with RFC 2543 compliant implementations that + do not support TCP. It is anticipated that this behavior will be + deprecated in a future revision of this specification. + + A client that sends a request to a multicast address MUST add the + "maddr" parameter to its Via header field value containing the + destination multicast address, and for IPv4, SHOULD add the "ttl" + parameter with a value of 1. Usage of IPv6 multicast is not defined + in this specification, and will be a subject of future + standardization when the need arises. + + These rules result in a purposeful limitation of multicast in SIP. + Its primary function is to provide a "single-hop-discovery-like" + service, delivering a request to a group of homogeneous servers, + where it is only required to process the response from any one of + them. This functionality is most useful for registrations. In fact, + based on the transaction processing rules in Section 17.1.3, the + client transaction will accept the first response, and view any + others as retransmissions because they all contain the same Via + branch identifier. + + Before a request is sent, the client transport MUST insert a value of + the "sent-by" field into the Via header field. This field contains + an IP address or host name, and port. The usage of an FQDN is + RECOMMENDED. This field is used for sending responses under certain + conditions, described below. If the port is absent, the default + value depends on the transport. It is 5060 for UDP, TCP and SCTP, + 5061 for TLS. + + For reliable transports, the response is normally sent on the + connection on which the request was received. Therefore, the client + transport MUST be prepared to receive the response on the same + connection used to send the request. Under error conditions, the + server may attempt to open a new connection to send the response. To + handle this case, the transport layer MUST also be prepared to + receive an incoming connection on the source IP address from which + the request was sent and port number in the "sent-by" field. It also + + + + + +Rosenberg, et. al. Standards Track [Page 143] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + MUST be prepared to receive incoming connections on any address and + port that would be selected by a server based on the procedures + described in Section 5 of [4]. + + For unreliable unicast transports, the client transport MUST be + prepared to receive responses on the source IP address from which the + request is sent (as responses are sent back to the source address) + and the port number in the "sent-by" field. Furthermore, as with + reliable transports, in certain cases the response will be sent + elsewhere. The client MUST be prepared to receive responses on any + address and port that would be selected by a server based on the + procedures described in Section 5 of [4]. + + For multicast, the client transport MUST be prepared to receive + responses on the same multicast group and port to which the request + is sent (that is, it needs to be a member of the multicast group it + sent the request to.) + + If a request is destined to an IP address, port, and transport to + which an existing connection is open, it is RECOMMENDED that this + connection be used to send the request, but another connection MAY be + opened and used. + + If a request is sent using multicast, it is sent to the group + address, port, and TTL provided by the transport user. If a request + is sent using unicast unreliable transports, it is sent to the IP + address and port provided by the transport user. + +18.1.2 Receiving Responses + + When a response is received, the client transport examines the top + Via header field value. If the value of the "sent-by" parameter in + that header field value does not correspond to a value that the + client transport is configured to insert into requests, the response + MUST be silently discarded. + + If there are any client transactions in existence, the client + transport uses the matching procedures of Section 17.1.3 to attempt + to match the response to an existing transaction. If there is a + match, the response MUST be passed to that transaction. Otherwise, + the response MUST be passed to the core (whether it be stateless + proxy, stateful proxy, or UA) for further processing. Handling of + these "stray" responses is dependent on the core (a proxy will + forward them, while a UA will discard, for example). + + + + + + + +Rosenberg, et. al. Standards Track [Page 144] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +18.2 Servers + +18.2.1 Receiving Requests + + A server SHOULD be prepared to receive requests on any IP address, + port and transport combination that can be the result of a DNS lookup + on a SIP or SIPS URI [4] that is handed out for the purposes of + communicating with that server. In this context, "handing out" + includes placing a URI in a Contact header field in a REGISTER + request or a redirect response, or in a Record-Route header field in + a request or response. A URI can also be "handed out" by placing it + on a web page or business card. It is also RECOMMENDED that a server + listen for requests on the default SIP ports (5060 for TCP and UDP, + 5061 for TLS over TCP) on all public interfaces. The typical + exception would be private networks, or when multiple server + instances are running on the same host. For any port and interface + that a server listens on for UDP, it MUST listen on that same port + and interface for TCP. This is because a message may need to be sent + using TCP, rather than UDP, if it is too large. As a result, the + converse is not true. A server need not listen for UDP on a + particular address and port just because it is listening on that same + address and port for TCP. There may, of course, be other reasons why + a server needs to listen for UDP on a particular address and port. + + When the server transport receives a request over any transport, it + MUST examine the value of the "sent-by" parameter in the top Via + header field value. If the host portion of the "sent-by" parameter + contains a domain name, or if it contains an IP address that differs + from the packet source address, the server MUST add a "received" + parameter to that Via header field value. This parameter MUST + contain the source address from which the packet was received. This + is to assist the server transport layer in sending the response, + since it must be sent to the source IP address from which the request + came. + + Consider a request received by the server transport which looks like, + in part: + + INVITE sip:bob@Biloxi.com SIP/2.0 + Via: SIP/2.0/UDP bobspc.biloxi.com:5060 + + The request is received with a source IP address of 192.0.2.4. + Before passing the request up, the transport adds a "received" + parameter, so that the request would look like, in part: + + INVITE sip:bob@Biloxi.com SIP/2.0 + Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 + + + + +Rosenberg, et. al. Standards Track [Page 145] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Next, the server transport attempts to match the request to a server + transaction. It does so using the matching rules described in + Section 17.2.3. If a matching server transaction is found, the + request is passed to that transaction for processing. If no match is + found, the request is passed to the core, which may decide to + construct a new server transaction for that request. Note that when + a UAS core sends a 2xx response to INVITE, the server transaction is + destroyed. This means that when the ACK arrives, there will be no + matching server transaction, and based on this rule, the ACK is + passed to the UAS core, where it is processed. + +18.2.2 Sending Responses + + The server transport uses the value of the top Via header field in + order to determine where to send a response. It MUST follow the + following process: + + o If the "sent-protocol" is a reliable transport protocol such as + TCP or SCTP, or TLS over those, the response MUST be sent using + the existing connection to the source of the original request + that created the transaction, if that connection is still open. + This requires the server transport to maintain an association + between server transactions and transport connections. If that + connection is no longer open, the server SHOULD open a + connection to the IP address in the "received" parameter, if + present, using the port in the "sent-by" value, or the default + port for that transport, if no port is specified. If that + connection attempt fails, the server SHOULD use the procedures + in [4] for servers in order to determine the IP address and + port to open the connection and send the response to. + + o Otherwise, if the Via header field value contains a "maddr" + parameter, the response MUST be forwarded to the address listed + there, using the port indicated in "sent-by", or port 5060 if + none is present. If the address is a multicast address, 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. + + o Otherwise (for unreliable unicast transports), if the top Via + has a "received" parameter, the response MUST be sent to the + address in the "received" parameter, using the port indicated + in the "sent-by" value, or using port 5060 if none is specified + explicitly. If this fails, for example, elicits an ICMP "port + unreachable" response, the procedures of Section 5 of [4] + SHOULD be used to determine where to send the response. + + + + + + +Rosenberg, et. al. Standards Track [Page 146] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Otherwise, if it is not receiver-tagged, the response MUST be + sent to the address indicated by the "sent-by" value, using the + procedures in Section 5 of [4]. + +18.3 Framing + + In the case of message-oriented transports (such as UDP), if the + message has a Content-Length header field, the message body is + assumed to contain that many bytes. If there are additional bytes in + the transport packet beyond the end of the body, they MUST be + discarded. If the transport packet ends before the end of the + message body, this is considered an error. If the message is a + response, it MUST be discarded. If the message is a request, the + element SHOULD generate a 400 (Bad Request) response. If the message + has no Content-Length header field, the message body is assumed to + end at the end of the transport packet. + + In the case of stream-oriented transports such as TCP, the Content- + Length header field indicates the size of the body. The Content- + Length header field MUST be used with stream oriented transports. + +18.4 Error Handling + + Error handling is independent of whether the message was a request or + response. + + If the transport user asks for a message to be sent over an + unreliable transport, and the result is an ICMP error, the behavior + depends on the type of ICMP error. Host, network, port or protocol + unreachable errors, or parameter problem errors SHOULD cause the + transport layer to inform the transport user of a failure in sending. + Source quench and TTL exceeded ICMP errors SHOULD be ignored. + + If the transport user asks for a request to be sent over a reliable + transport, and the result is a connection failure, the transport + layer SHOULD inform the transport user of a failure in sending. + +19 Common Message Components + + There are certain components of SIP messages that appear in various + places within SIP messages (and sometimes, outside of them) that + merit separate discussion. + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 147] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +19.1 SIP and SIPS Uniform Resource Indicators + + A SIP or SIPS URI identifies a communications resource. Like all + URIs, SIP and SIPS URIs may be placed in web pages, email messages, + or printed literature. They contain sufficient information to + initiate and maintain a communication session with the resource. + + Examples of communications resources include the following: + + o a user of an online service + + o an appearance on a multi-line phone + + o a mailbox on a messaging system + + o a PSTN number at a gateway service + + o a group (such as "sales" or "helpdesk") in an organization + + A SIPS URI specifies that the resource be contacted securely. This + means, in particular, that TLS is to be used between the UAC and the + domain that owns the URI. From there, secure communications are used + to reach the user, where the specific security mechanism depends on + the policy of the domain. Any resource described by a SIP URI can be + "upgraded" to a SIPS URI by just changing the scheme, if it is + desired to communicate with that resource securely. + +19.1.1 SIP and SIPS URI Components + + The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. + They use a form similar to the mailto URL, allowing the specification + of SIP request-header fields and the SIP message-body. This makes it + possible to specify the subject, media type, or urgency of sessions + initiated by using a URI on a web page or in an email message. The + formal syntax for a SIP or SIPS URI is presented in Section 25. Its + general form, in the case of a SIP URI, is: + + sip:user:password@host:port;uri-parameters?headers + + The format for a SIPS URI is the same, except that the scheme is + "sips" instead of sip. These tokens, and some of the tokens in their + expansions, have the following meanings: + + user: The identifier of a particular resource at the host being + addressed. The term "host" in this context frequently refers + to a domain. The "userinfo" of a URI consists of this user + field, the password field, and the @ sign following them. The + userinfo part of a URI is optional and MAY be absent when the + + + +Rosenberg, et. al. Standards Track [Page 148] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + destination host does not have a notion of users or when the + host itself is the resource being identified. If the @ sign is + present in a SIP or SIPS URI, the user field MUST NOT be empty. + + If the host being addressed can process telephone numbers, for + instance, an Internet telephony gateway, a telephone- + subscriber field defined in RFC 2806 [9] MAY be used to + populate the user field. There are special escaping rules for + encoding telephone-subscriber fields in SIP and SIPS URIs + described in Section 19.1.2. + + password: A password associated with the user. While the SIP and + SIPS URI syntax allows this field to be present, its use 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. For instance, + transporting a PIN number in this field exposes the PIN. + + Note that the password field is just an extension of the user + portion. Implementations not wishing to give special + significance to the password portion of the field MAY simply + treat "user:password" as a single string. + + host: The host providing the SIP resource. The host part contains + either a fully-qualified domain name or numeric IPv4 or IPv6 + address. Using the fully-qualified domain name form is + RECOMMENDED whenever possible. + + port: The port number where the request is to be sent. + + URI parameters: Parameters affecting a request constructed from + the URI. + + URI parameters are added after the hostport component and are + separated by semi-colons. + + URI parameters take the form: + + parameter-name "=" parameter-value + + Even though an arbitrary number of URI parameters may be + included in a URI, any given parameter-name MUST NOT appear + more than once. + + This extensible mechanism includes the transport, maddr, ttl, + user, method and lr parameters. + + + + + +Rosenberg, et. al. Standards Track [Page 149] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The transport parameter determines the transport mechanism to + be used for sending SIP messages, as specified in [4]. SIP can + use any network transport protocol. Parameter names are + defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP + (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST + indicate a reliable transport. + + The maddr parameter indicates the server address to be + contacted for this user, overriding any address derived from + the host field. When an maddr parameter is present, the port + and transport components of the URI apply to the address + indicated in the maddr parameter value. [4] describes the + proper interpretation of the transport, maddr, and hostport in + order to obtain the destination address, port, and transport + for sending a request. + + The maddr field has been used as a simple form of loose source + routing. It allows a URI to specify a proxy that must be + traversed en-route to the destination. Continuing to use the + maddr parameter this way is strongly discouraged (the + mechanisms that enable it are deprecated). Implementations + should instead use the Route mechanism described in this + document, establishing a pre-existing route set if necessary + (see Section 8.1.1.1). This provides a full URI to describe + the node to be traversed. + + 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. For example, to + specify a call to alice@atlanta.com using multicast to + 239.255.255.1 with a ttl of 15, the following URI would be + used: + + sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 + + The set of valid telephone-subscriber strings is a subset of + valid user strings. The user URI parameter exists to + distinguish telephone numbers from user names that happen to + look like telephone numbers. If the user string contains a + telephone number formatted as a telephone-subscriber, the user + parameter value "phone" SHOULD be present. Even without this + parameter, recipients of SIP and SIPS URIs MAY interpret the + pre-@ part as a telephone number if local restrictions on the + name space for user name allow it. + + The method of the SIP request constructed from the URI can be + specified with the method parameter. + + + + +Rosenberg, et. al. Standards Track [Page 150] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The lr parameter, when present, indicates that the element + responsible for this resource implements the routing mechanisms + specified in this document. This parameter will be used in the + URIs proxies place into Record-Route header field values, and + may appear in the URIs in a pre-existing route set. + + This parameter is used to achieve backwards compatibility with + systems implementing the strict-routing mechanisms of RFC 2543 + and the rfc2543bis drafts up to bis-05. An element preparing + to send a request based on a URI not containing this parameter + can assume the receiving element implements strict-routing and + reformat the message to preserve the information in the + Request-URI. + + Since the uri-parameter mechanism is extensible, SIP elements + MUST silently ignore any uri-parameters that they do not + understand. + + Headers: Header fields to be included in a request constructed + from the URI. + + Headers fields in the SIP request can be specified with the "?" + mechanism within a URI. The header names and values are + encoded in ampersand separated hname = hvalue pairs. The + special hname "body" indicates that the associated hvalue is + the message-body of the SIP request. + + Table 1 summarizes the use of SIP and SIPS URI components based on + the context in which the URI appears. The external column describes + URIs appearing anywhere outside of a SIP message, for instance on a + web page or business card. Entries marked "m" are mandatory, those + marked "o" are optional, and those marked "-" are not allowed. + Elements processing URIs SHOULD ignore any disallowed components if + they are present. The second column indicates the default value of + an optional element if it is not present. "--" indicates that the + element is either not optional, or has no default value. + + URIs in Contact header fields have different restrictions depending + on the context in which the header field appears. One set applies to + messages that establish and maintain dialogs (INVITE and its 200 (OK) + response). The other applies to registration and redirection + messages (REGISTER, its 200 (OK) response, and 3xx class responses to + any method). + + + + + + + + +Rosenberg, et. al. Standards Track [Page 151] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +19.1.2 Character Escaping Requirements + + dialog + reg./redir. Contact/ + default Req.-URI To From Contact R-R/Route external +user -- o o o o o o +password -- o o o o o o +host -- m m m m m m +port (1) o - - o o o +user-param ip o o o o o o +method INVITE - - - - - o +maddr-param -- o - - o o o +ttl-param 1 o - - o - o +transp.-param (2) o - - o o o +lr-param -- o - - - o o +other-param -- o o o o o o +headers -- - - - o - o + + (1): The default port value is transport and scheme dependent. The + default is 5060 for sip: using UDP, TCP, or SCTP. The default is + 5061 for sip: using TLS over TCP and sips: over TCP. + + (2): The default transport is scheme dependent. For sip:, it is UDP. + For sips:, it is TCP. + + Table 1: Use and default values of URI components for SIP header + field values, Request-URI and references + + SIP follows the requirements and guidelines of RFC 2396 [5] when + defining the set of characters that must be escaped in a SIP URI, and + uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]: + + The set of characters actually 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 [5]. Excluded US- + ASCII characters (RFC 2396 [5]), such as space and control + characters and characters used as URI delimiters, also MUST be + escaped. URIs MUST NOT contain unescaped space and control + characters. + + For each component, the set of valid BNF expansions defines exactly + which characters may appear unescaped. All other characters MUST be + escaped. + + For example, "@" is not in the set of characters in the user + component, so the user "j@s0n" must have at least the @ sign encoded, + as in "j%40s0n". + + + +Rosenberg, et. al. Standards Track [Page 152] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Expanding the hname and hvalue tokens in Section 25 show that all URI + reserved characters in header field names and values MUST be escaped. + + The telephone-subscriber subset of the user component has special + escaping considerations. The set of characters not reserved in the + RFC 2806 [9] description of telephone-subscriber contains a number of + characters in various syntax elements that need to be escaped when + used in SIP URIs. Any characters occurring in a telephone-subscriber + that do not appear in an expansion of the BNF for the user rule MUST + be escaped. + + Note that character escaping is not allowed in the host component of + a SIP or SIPS URI (the % character is not valid in its expansion). + This is likely to change in the future as requirements for + Internationalized Domain Names are finalized. Current + implementations MUST NOT attempt to improve robustness by treating + received escaped characters in the host component as literally + equivalent to their unescaped counterpart. The behavior required to + meet the requirements of IDN may be significantly different. + +19.1.3 Example SIP and SIPS URIs + + sip:alice@atlanta.com + sip:alice:secretword@atlanta.com;transport=tcp + sips:alice@atlanta.com?subject=project%20x&priority=urgent + sip:+1-212-555-1212:1234@gateway.com;user=phone + sips:1212@gateway.com + sip:alice@192.0.2.4 + sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com + sip:alice;day=tuesday@atlanta.com + + The last sample URI above has a user field value of + "alice;day=tuesday". The escaping rules defined above allow a + semicolon to appear unescaped in this field. For the purposes of + this protocol, the field is opaque. The structure of that value is + only useful to the SIP element responsible for the resource. + +19.1.4 URI Comparison + + Some operations in this specification require determining whether two + SIP or SIPS URIs are equivalent. In this specification, registrars + need to compare bindings in Contact URIs in REGISTER requests (see + Section 10.3.). SIP and SIPS URIs are compared for equality + according to the following rules: + + o A SIP and SIPS URI are never equivalent. + + + + + +Rosenberg, et. al. Standards Track [Page 153] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Comparison of the userinfo of SIP and SIPS URIs is case- + sensitive. This includes userinfo containing passwords or + formatted as telephone-subscribers. Comparison of all other + components of the URI is case-insensitive unless explicitly + defined otherwise. + + o The ordering of parameters and header fields is not significant + in comparing SIP and SIPS URIs. + + o Characters other than those in the "reserved" set (see RFC 2396 + [5]) are equivalent to their ""%" HEX HEX" encoding. + + o An IP address that is the result of a DNS lookup of a host name + does not match that host name. + + o For two URIs to be equal, the user, password, host, and port + components must match. + + A URI omitting the user component will not match a URI that + includes one. A URI omitting the password component will not + match a URI that includes one. + + A URI omitting any component with a default value will not + match a URI explicitly containing that component with its + default value. For instance, a URI omitting the optional port + component will not match a URI explicitly declaring port 5060. + The same is true for the transport-parameter, ttl-parameter, + user-parameter, and method components. + + Defining sip:user@host to not be equivalent to + sip:user@host:5060 is a change from RFC 2543. When deriving + addresses from URIs, equivalent addresses are expected from + equivalent URIs. The URI sip:user@host:5060 will always + resolve to port 5060. The URI sip:user@host may resolve to + other ports through the DNS SRV mechanisms detailed in [4]. + + o URI uri-parameter components are compared as follows: + + - Any uri-parameter appearing in both URIs must match. + + - A user, ttl, or method uri-parameter appearing in only one + URI never matches, even if it contains the default value. + + - A URI that includes an maddr parameter will not match a URI + that contains no maddr parameter. + + - All other uri-parameters appearing in only one URI are + ignored when comparing the URIs. + + + +Rosenberg, et. al. Standards Track [Page 154] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o URI header components are never ignored. Any present header + component MUST be present in both URIs and match for the URIs + to match. The matching rules are defined for each header field + in Section 20. + + The URIs within each of the following sets are equivalent: + + sip:%61lice@atlanta.com;transport=TCP + sip:alice@AtLanTa.CoM;Transport=tcp + + sip:carol@chicago.com + sip:carol@chicago.com;newparam=5 + sip:carol@chicago.com;security=on + + sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com + sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com + + sip:alice@atlanta.com?subject=project%20x&priority=urgent + sip:alice@atlanta.com?priority=urgent&subject=project%20x + + The URIs within each of the following sets are not equivalent: + + SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) + sip:alice@AtLanTa.CoM;Transport=UDP + + sip:bob@biloxi.com (can resolve to different ports) + sip:bob@biloxi.com:5060 + + sip:bob@biloxi.com (can resolve to different transports) + sip:bob@biloxi.com;transport=udp + + sip:bob@biloxi.com (can resolve to different port and transports) + sip:bob@biloxi.com:6000;transport=tcp + + sip:carol@chicago.com (different header component) + sip:carol@chicago.com?Subject=next%20meeting + + sip:bob@phone21.boxesbybob.com (even though that's what + sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) + + Note that equality is not transitive: + + o sip:carol@chicago.com and sip:carol@chicago.com;security=on are + equivalent + + o sip:carol@chicago.com and sip:carol@chicago.com;security=off + are equivalent + + + + +Rosenberg, et. al. Standards Track [Page 155] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o sip:carol@chicago.com;security=on and + sip:carol@chicago.com;security=off are not equivalent + +19.1.5 Forming Requests from a URI + + An implementation needs to take care when forming requests directly + from a URI. URIs from business cards, web pages, and even from + sources inside the protocol such as registered contacts may contain + inappropriate header fields or body parts. + + An implementation MUST include any provided transport, maddr, ttl, or + user parameter in the Request-URI of the formed request. If the URI + contains a method parameter, its value MUST be used as the method of + the request. The method parameter MUST NOT be placed in the + Request-URI. Unknown URI parameters MUST be placed in the message's + Request-URI. + + An implementation SHOULD treat the presence of any headers or body + parts in the URI as a desire to include them in the message, and + choose to honor the request on a per-component basis. + + An implementation SHOULD NOT honor these obviously dangerous header + fields: From, Call-ID, CSeq, Via, and Record-Route. + + An implementation SHOULD NOT honor any requested Route header field + values in order to not be used as an unwitting agent in malicious + attacks. + + An implementation SHOULD NOT honor requests to include header fields + that may cause it to falsely advertise its location or capabilities. + These include: Accept, Accept-Encoding, Accept-Language, Allow, + Contact (in its dialog usage), Organization, Supported, and User- + Agent. + + An implementation SHOULD verify the accuracy of any requested + descriptive header fields, including: Content-Disposition, Content- + Encoding, Content-Language, Content-Length, Content-Type, Date, + Mime-Version, and Timestamp. + + If the request formed from constructing a message from a given URI is + not a valid SIP request, the URI is invalid. An implementation MUST + NOT proceed with transmitting the request. It should instead pursue + the course of action due an invalid URI in the context it occurs. + + The constructed request can be invalid in many ways. These + include, but are not limited to, syntax error in header fields, + invalid combinations of URI parameters, or an incorrect + description of the message body. + + + +Rosenberg, et. al. Standards Track [Page 156] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Sending a request formed from a given URI may require capabilities + unavailable to the implementation. The URI might indicate use of an + unimplemented transport or extension, for example. An implementation + SHOULD refuse to send these requests rather than modifying them to + match their capabilities. An implementation MUST NOT send a request + requiring an extension that it does not support. + + For example, such a request can be formed through the presence of + a Require header parameter or a method URI parameter with an + unknown or explicitly unsupported value. + +19.1.6 Relating SIP URIs and tel URLs + + When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the + entire telephone-subscriber portion of the tel URL, including any + parameters, is placed into the userinfo part of the SIP or SIPS URI. + + Thus, tel:+358-555-1234567;postd=pp22 becomes + + sip:+358-555-1234567;postd=pp22@foo.com;user=phone + + or + sips:+358-555-1234567;postd=pp22@foo.com;user=phone + + not + sip:+358-555-1234567@foo.com;postd=pp22;user=phone + + or + + sips:+358-555-1234567@foo.com;postd=pp22;user=phone + + In general, equivalent "tel" URLs converted to SIP or SIPS URIs in + this fashion may not produce equivalent SIP or SIPS URIs. The + userinfo of SIP and SIPS URIs are compared as a case-sensitive + string. Variance in case-insensitive portions of tel URLs and + reordering of tel URL parameters does not affect tel URL equivalence, + but does affect the equivalence of SIP URIs formed from them. + + For example, + + tel:+358-555-1234567;postd=pp22 + tel:+358-555-1234567;POSTD=PP22 + + are equivalent, while + + sip:+358-555-1234567;postd=pp22@foo.com;user=phone + sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone + + + + +Rosenberg, et. al. Standards Track [Page 157] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + are not. + + Likewise, + + tel:+358-555-1234567;postd=pp22;isub=1411 + tel:+358-555-1234567;isub=1411;postd=pp22 + + are equivalent, while + + sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone + sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone + + are not. + + To mitigate this problem, elements constructing telephone-subscriber + fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold + any case-insensitive portion of telephone-subscriber to lower case, + and order the telephone-subscriber parameters lexically by parameter + name, excepting isdn-subaddress and post-dial, which occur first and + in that order. (All components of a tel URL except for future- + extension parameters are defined to be compared case-insensitive.) + + Following this suggestion, both + + tel:+358-555-1234567;postd=pp22 + tel:+358-555-1234567;POSTD=PP22 + + become + + sip:+358-555-1234567;postd=pp22@foo.com;user=phone + + and both + + tel:+358-555-1234567;tsp=a.b;phone-context=5 + tel:+358-555-1234567;phone-context=5;tsp=a.b + + become + + sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone + +19.2 Option Tags + + Option tags are unique identifiers used to designate new options + (extensions) in SIP. These tags are used in Require (Section 20.32), + Proxy-Require (Section 20.29), Supported (Section 20.37) and + Unsupported (Section 20.40) header fields. Note that these options + appear as parameters in those header fields in an option-tag = token + form (see Section 25 for the definition of token). + + + +Rosenberg, et. al. Standards Track [Page 158] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Option tags are defined in standards track RFCs. This is a change + from past practice, and is instituted to ensure continuing multi- + vendor interoperability (see discussion in Section 20.32 and Section + 20.37). An IANA registry of option tags is used to ensure easy + reference. + +19.3 Tags + + The "tag" parameter is used in the To and From header fields of SIP + messages. It serves as a general mechanism to identify a dialog, + which is the combination of the Call-ID along with two tags, one from + each participant in the dialog. When a UA sends a request outside of + a dialog, it contains a From tag only, providing "half" of the dialog + ID. The dialog is completed from the response(s), each of which + contributes the second half in the To header field. The forking of + SIP requests means that multiple dialogs can be established from a + single request. This also explains the need for the two-sided dialog + identifier; without a contribution from the recipients, the + originator could not disambiguate the multiple dialogs established + from a single request. + + When a tag is generated by a UA for insertion into a request or + response, it MUST be globally unique and cryptographically random + with at least 32 bits of randomness. A property of this selection + requirement is that a UA will place a different tag into the From + header of an INVITE than it would place into the To header of the + response to the same INVITE. This is needed in order for a UA to + invite itself to a session, a common case for "hairpinning" of calls + in PSTN gateways. Similarly, two INVITEs for different calls will + have different From tags, and two responses for different calls will + have different To tags. + + Besides the requirement for global uniqueness, the algorithm for + generating a tag is implementation-specific. Tags are helpful in + fault tolerant systems, where a dialog is to be recovered on an + alternate server after a failure. A UAS can select the tag in such a + way that a backup can recognize a request as part of a dialog on the + failed server, and therefore determine that it should attempt to + recover the dialog and any other state associated with it. + +20 Header Fields + + The general syntax for header fields is covered in Section 7.3. This + section lists the full set of header fields along with notes on + syntax, meaning, and usage. Throughout this section, we use [HX.Y] + to refer to Section X.Y of the current HTTP/1.1 specification RFC + 2616 [8]. Examples of each header field are given. + + + + +Rosenberg, et. al. Standards Track [Page 159] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Information about header fields in relation to methods and proxy + processing is summarized in Tables 2 and 3. + + The "where" column describes the request and response types in which + the header field can be used. Values in this column are: + + R: header field may only appear in requests; + + r: header field may only appear in responses; + + 2xx, 4xx, etc.: A numerical value or range indicates response + codes with which the header field can be used; + + c: header field is copied from the request to the response. + + An empty entry in the "where" column indicates that the header + field may be present in all requests and responses. + + The "proxy" column describes the operations a proxy may perform on a + header field: + + a: A proxy can add or concatenate the header field if not present. + + m: A proxy can modify an existing header field value. + + d: A proxy can delete a header field value. + + r: A proxy must be able to read the header field, and thus this + header field cannot be encrypted. + + The next six columns relate to the presence of a header field in a + method: + + c: Conditional; requirements on the header field depend on the + context of the message. + + m: The header field is mandatory. + + m*: The header field SHOULD be sent, but clients/servers need to + be prepared to receive messages without that header field. + + o: The header field is optional. + + t: The header field SHOULD be sent, but clients/servers need to be + prepared to receive messages without that header field. + + If a stream-based protocol (such as TCP) is used as a + transport, then the header field MUST be sent. + + + +Rosenberg, et. al. Standards Track [Page 160] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + *: The header field is required if the message body is not empty. + See Sections 20.14, 20.15 and 7.4 for details. + + -: The header field is not applicable. + + "Optional" means that an element MAY include the header field in a + request or response, and a UA MAY ignore the header field if present + in the request or response (The exception to this rule is the Require + header field discussed in 20.32). A "mandatory" header field MUST be + present in a request, and MUST be understood by the UAS receiving the + request. A mandatory response header field MUST be present in the + response, and the header field MUST be understood by the UAC + processing the response. "Not applicable" means that the header + field MUST NOT be present in a request. If one is placed in a + request by mistake, it MUST be ignored by the UAS receiving the + request. Similarly, a header field labeled "not applicable" for a + response means that the UAS MUST NOT place the header field in the + response, and the UAC MUST ignore the header field in the response. + + A UA SHOULD ignore extension header parameters that are not + understood. + + A compact form of some common header field names is also defined for + use when overall message size is an issue. + + The Contact, From, and To header fields contain a URI. If the URI + contains a comma, question mark or semicolon, the URI MUST be + enclosed in angle brackets (< and >). Any URI parameters are + contained within these brackets. If the URI is not enclosed in angle + brackets, any semicolon-delimited parameters are header-parameters, + not URI parameters. + +20.1 Accept + + The Accept header field follows the syntax defined in [H14.1]. The + semantics are also identical, with the exception that if no Accept + header field is present, the server SHOULD assume a default value of + application/sdp. + + An empty Accept header field means that no formats are acceptable. + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 161] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + Header field where proxy ACK BYE CAN INV OPT REG + ___________________________________________________________ + Accept R - o - o m* o + Accept 2xx - - - o m* o + Accept 415 - c - c c c + Accept-Encoding R - o - o o o + Accept-Encoding 2xx - - - o m* o + Accept-Encoding 415 - c - c c c + Accept-Language R - o - o o o + Accept-Language 2xx - - - o m* o + Accept-Language 415 - c - c c c + Alert-Info R ar - - - o - - + Alert-Info 180 ar - - - o - - + Allow R - o - o o o + Allow 2xx - o - m* m* o + Allow r - o - o o o + Allow 405 - m - m m m + Authentication-Info 2xx - o - o o o + Authorization R o o o o o o + Call-ID c r m m m m m m + Call-Info ar - - - o o o + Contact R o - - m o o + Contact 1xx - - - o - - + Contact 2xx - - - m o o + Contact 3xx d - o - o o o + Contact 485 - o - o o o + Content-Disposition o o - o o o + Content-Encoding o o - o o o + Content-Language o o - o o o + Content-Length ar t t t t t t + Content-Type * * - * * * + CSeq c r m m m m m m + Date a o o o o o o + Error-Info 300-699 a - o o o o o + Expires - - - o - o + From c r m m m m m m + In-Reply-To R - - - o - - + Max-Forwards R amr m m m m m m + Min-Expires 423 - - - - - m + MIME-Version o o - o o o + Organization ar - - - o o o + + Table 2: Summary of header fields, A--O + + + + + + +Rosenberg, et. al. Standards Track [Page 162] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Header field where proxy ACK BYE CAN INV OPT REG + ___________________________________________________________________ + Priority R ar - - - o - - + Proxy-Authenticate 407 ar - m - m m m + Proxy-Authenticate 401 ar - o o o o o + Proxy-Authorization R dr o o - o o o + Proxy-Require R ar - o - o o o + Record-Route R ar o o o o o - + Record-Route 2xx,18x mr - o o o o - + Reply-To - - - o - - + Require ar - c - c c c + Retry-After 404,413,480,486 - o o o o o + 500,503 - o o o o o + 600,603 - o o o o o + Route R adr c c c c c c + Server r - o o o o o + Subject R - - - o - - + Supported R - o o m* o o + Supported 2xx - o o m* m* o + Timestamp o o o o o o + To c(1) r m m m m m m + Unsupported 420 - m - m m m + User-Agent o o o o o o + Via R amr m m m m m m + Via rc dr m m m m m m + Warning r - o o o o o + WWW-Authenticate 401 ar - m - m m m + WWW-Authenticate 407 ar - o - o o o + + Table 3: Summary of header fields, P--Z; (1): copied with possible + addition of tag + + Accept: application/sdp;level=1, application/x-private, text/html + +20.2 Accept-Encoding + + The Accept-Encoding header field is similar to Accept, but restricts + the content-codings [H3.5] that are acceptable in the response. See + [H14.3]. The semantics in SIP are identical to those defined in + [H14.3]. + + An empty Accept-Encoding header field is permissible. It is + equivalent to Accept-Encoding: identity, that is, only the identity + encoding, meaning no encoding, is permissible. + + If no Accept-Encoding header field is present, the server SHOULD + assume a default value of identity. + + + + +Rosenberg, et. al. Standards Track [Page 163] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + This differs slightly from the HTTP definition, which indicates that + when not present, any encoding can be used, but the identity encoding + is preferred. + + Example: + + Accept-Encoding: gzip + +20.3 Accept-Language + + The Accept-Language header field is used in requests to indicate the + preferred languages for reason phrases, session descriptions, or + status responses carried as message bodies in the response. If no + Accept-Language header field is present, the server SHOULD assume all + languages are acceptable to the client. + + The Accept-Language header field follows the syntax defined in + [H14.4]. The rules for ordering the languages based on the "q" + parameter apply to SIP as well. + + Example: + + Accept-Language: da, en-gb;q=0.8, en;q=0.7 + +20.4 Alert-Info + + When present in an INVITE request, the Alert-Info header field + specifies an alternative ring tone to the UAS. When present in a 180 + (Ringing) response, the Alert-Info header field specifies an + alternative ringback tone to the UAC. A typical usage is for a proxy + to insert this header field to provide a distinctive ring feature. + + The Alert-Info header field can introduce security risks. These + risks and the ways to handle them are discussed in Section 20.9, + which discusses the Call-Info header field since the risks are + identical. + + In addition, a user SHOULD be able to disable this feature + selectively. + + This helps prevent disruptions that could result from the use of + this header field by untrusted elements. + + Example: + + Alert-Info: <http://www.example.com/sounds/moo.wav> + + + + + +Rosenberg, et. al. Standards Track [Page 164] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +20.5 Allow + + The Allow header field lists the set of methods supported by the UA + generating the message. + + All methods, including ACK and CANCEL, understood by the UA MUST be + included in the list of methods in the Allow header field, when + present. The absence of an Allow header field MUST NOT be + interpreted to mean that the UA sending the message supports no + methods. Rather, it implies that the UA is not providing any + information on what methods it supports. + + Supplying an Allow header field in responses to methods other than + OPTIONS reduces the number of messages needed. + + Example: + + Allow: INVITE, ACK, OPTIONS, CANCEL, BYE + +20.6 Authentication-Info + + The Authentication-Info header field provides for mutual + authentication with HTTP Digest. A UAS MAY include this header field + in a 2xx response to a request that was successfully authenticated + using digest based on the Authorization header field. + + Syntax and semantics follow those specified in RFC 2617 [17]. + + Example: + + Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" + +20.7 Authorization + + The Authorization header field contains authentication credentials of + a UA. Section 22.2 overviews the use of the Authorization header + field, and Section 22.4 describes the syntax and semantics when used + with HTTP authentication. + + This header field, along with Proxy-Authorization, breaks the general + rules about multiple header field values. Although not a comma- + separated list, this header field name may be present multiple times, + and MUST NOT be combined into a single header line using the usual + rules described in Section 7.3. + + + + + + + +Rosenberg, et. al. Standards Track [Page 165] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + In the example below, there are no quotes around the Digest + parameter: + + Authorization: Digest username="Alice", realm="atlanta.com", + nonce="84a4cc6f3082121f32b42a2187831a9e", + response="7587245234b3434cc3412213e5f113a5432" + +20.8 Call-ID + + The Call-ID header field uniquely identifies a particular invitation + or all registrations of a particular client. A single multimedia + conference can give rise to several calls with different Call-IDs, + for example, if a user invites a single individual several times to + the same (long-running) conference. Call-IDs are case-sensitive and + are simply compared byte-by-byte. + + The compact form of the Call-ID header field is i. + + Examples: + + Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com + i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 + +20.9 Call-Info + + The Call-Info header field provides additional information about the + caller or callee, depending on whether it is found in a request or + response. The purpose of the URI is described by the "purpose" + parameter. The "icon" parameter designates an image suitable as an + iconic representation of the caller or callee. The "info" parameter + describes the caller or callee in general, for example, through a web + page. The "card" parameter provides a business card, for example, in + vCard [36] or LDIF [37] formats. Additional tokens can be registered + using IANA and the procedures in Section 27. + + Use of the Call-Info header field can pose a security risk. If a + callee fetches the URIs provided by a malicious caller, the callee + may be at risk for displaying inappropriate or offensive content, + dangerous or illegal content, and so on. Therefore, it is + RECOMMENDED that a UA only render the information in the Call-Info + header field if it can verify the authenticity of the element that + originated the header field and trusts that element. This need not + be the peer UA; a proxy can insert this header field into requests. + + Example: + + Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, + <http://www.example.com/alice/> ;purpose=info + + + +Rosenberg, et. al. Standards Track [Page 166] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +20.10 Contact + + A Contact header field value provides a URI whose meaning depends on + the type of request or response it is in. + + A Contact header field value can contain a display name, a URI with + URI parameters, and header parameters. + + This document defines the Contact parameters "q" and "expires". + These parameters are only used when the Contact is present in a + REGISTER request or response, or in a 3xx response. Additional + parameters may be defined in other specifications. + + When the header field value contains a display name, the URI + including all URI parameters is enclosed in "<" and ">". If no "<" + and ">" are present, all parameters after the URI are header + parameters, not URI parameters. The display name can be tokens, or a + quoted string, if a larger character set is desired. + + Even if the "display-name" is empty, the "name-addr" form MUST be + used if the "addr-spec" contains a comma, semicolon, or question + mark. There may or may not be LWS between the display-name and the + "<". + + These rules for parsing a display name, URI and URI parameters, and + header parameters also apply for the header fields To and From. + + The Contact header field has a role similar to the Location header + field in HTTP. However, the HTTP header field 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 compact form of the Contact header field is m (for "moved"). + + Examples: + + Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> + ;q=0.7; expires=3600, + "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1 + m: <sips:bob@192.0.2.4>;expires=60 + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 167] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +20.11 Content-Disposition + + The Content-Disposition header field describes how the message body + or, for multipart messages, a message body part is to be interpreted + by the UAC or UAS. This SIP header field extends the MIME Content- + Type (RFC 2183 [18]). + + Several new "disposition-types" of the Content-Disposition header are + defined by SIP. The value "session" indicates that the body part + describes a session, for either calls or early (pre-call) media. The + value "render" indicates that the body part should be displayed or + otherwise rendered to the user. Note that the value "render" is used + rather than "inline" to avoid the connotation that the MIME body is + displayed as a part of the rendering of the entire message (since the + MIME bodies of SIP messages oftentimes are not displayed to users). + For backward-compatibility, if the Content-Disposition header field + is missing, the server SHOULD assume bodies of Content-Type + application/sdp are the disposition "session", while other content + types are "render". + + The disposition type "icon" indicates that the body part contains an + image suitable as an iconic representation of the caller or callee + that could be rendered informationally by a user agent when a message + has been received, or persistently while a dialog takes place. The + value "alert" indicates that the body part contains information, such + as an audio clip, that should be rendered by the user agent in an + attempt to alert the user to the receipt of a request, generally a + request that initiates a dialog; this alerting body could for example + be rendered as a ring tone for a phone call after a 180 Ringing + provisional response has been sent. + + Any MIME body with a "disposition-type" that renders content to the + user should only be processed when a message has been properly + authenticated. + + The handling parameter, handling-param, describes how the UAS should + react if it receives a message body whose content type or disposition + type it does not understand. The parameter has defined values of + "optional" and "required". If the handling parameter is missing, the + value "required" SHOULD be assumed. The handling parameter is + described in RFC 3204 [19]. + + If this header field is missing, the MIME type determines the default + content disposition. If there is none, "render" is assumed. + + Example: + + Content-Disposition: session + + + +Rosenberg, et. al. Standards Track [Page 168] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +20.12 Content-Encoding + + The Content-Encoding 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-body, the + content codings MUST be listed in the order in which they were + applied. + + All content-coding values are case-insensitive. IANA acts as a + registry for content-coding value tokens. See [H3.5] for a + definition of the syntax for content-coding. + + Clients MAY apply content encodings to the body in requests. A + server MAY apply content encodings to the bodies in responses. The + server MUST only use encodings listed in the Accept-Encoding header + field in the request. + + The compact form of the Content-Encoding header field is e. + Examples: + + Content-Encoding: gzip + e: tar + +20.13 Content-Language + + See [H14.12]. Example: + + Content-Language: fr + +20.14 Content-Length + + The Content-Length header field indicates the size of the message- + body, in decimal number of octets, sent to the recipient. + Applications SHOULD use this field to indicate the size of the + message-body to be transferred, regardless of the media type of the + entity. If a stream-based protocol (such as TCP) is used as + transport, the header field MUST be used. + + The size of the message-body does not include the CRLF separating + header fields and body. 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 value MUST be set to zero. + + + +Rosenberg, et. al. Standards Track [Page 169] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The ability to omit Content-Length simplifies the creation of + cgi-like scripts that dynamically generate responses. + + The compact form of the header field is l. + + Examples: + + Content-Length: 349 + l: 173 + +20.15 Content-Type + + The Content-Type header field indicates the media type of the + message-body sent to the recipient. The "media-type" element is + defined in [H3.7]. The Content-Type header field MUST be present if + the body is not empty. If the body is empty, and a Content-Type + header field is present, it indicates that the body of the specific + type has zero length (for example, an empty audio file). + + The compact form of the header field is c. + + Examples: + + Content-Type: application/sdp + c: text/html; charset=ISO-8859-4 + +20.16 CSeq + + A CSeq header field in a request contains a single decimal sequence + number and the request method. The sequence number MUST be + expressible as a 32-bit unsigned integer. The method part of CSeq is + case-sensitive. The CSeq header field serves to order transactions + within a dialog, to provide a means to uniquely identify + transactions, and to differentiate between new requests and request + retransmissions. Two CSeq header fields are considered equal if the + sequence number and the request method are identical. Example: + + CSeq: 4711 INVITE + +20.17 Date + + The Date header field contains the date and time. Unlike HTTP/1.1, + SIP only supports the most recent RFC 1123 [20] format for dates. As + in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while + RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. + + The Date header field reflects the time when the request or response + is first sent. + + + +Rosenberg, et. al. Standards Track [Page 170] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The Date header field can be used by simple end systems without a + battery-backed clock to acquire a notion of current time. + However, in its GMT form, it requires clients to know their offset + from GMT. + + Example: + + Date: Sat, 13 Nov 2010 23:29:00 GMT + +20.18 Error-Info + + The Error-Info header field provides a pointer to additional + information about the error status response. + + SIP UACs have user interface capabilities ranging from pop-up + windows and audio on PC softclients to audio-only on "black" + phones or endpoints connected via gateways. Rather than forcing a + server generating an error to choose between sending an error + status code with a detailed reason phrase and playing an audio + recording, the Error-Info header field allows both to be sent. + The UAC then has the choice of which error indicator to render to + the caller. + + A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if + it were a Contact in a redirect and generate a new INVITE, resulting + in a recorded announcement session being established. A non-SIP URI + MAY be rendered to the user. + + Examples: + + SIP/2.0 404 The number you have dialed is not in service + Error-Info: <sip:not-in-service-recording@atlanta.com> + +20.19 Expires + + The Expires header field gives the relative time after which the + message (or content) expires. + + The precise meaning of this is method dependent. + + The expiration time in an INVITE does not affect the duration of the + actual session that may result from the invitation. Session + description protocols may offer the ability to express time limits on + the session duration, however. + + The value of this field is an integral number of seconds (in decimal) + between 0 and (2**32)-1, measured from the receipt of the request. + + + + +Rosenberg, et. al. Standards Track [Page 171] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + Expires: 5 + +20.20 From + + The From header field indicates the initiator of the request. This + may be different from the initiator of the dialog. Requests sent by + the callee to the caller use the callee's address in the From header + field. + + 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. 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. Syntax issues are + discussed in Section 7.3.1. + + Two From header fields are equivalent if their URIs match, and their + parameters match. Extension parameters in one header field, not + present in the other are ignored for the purposes of comparison. This + means that the display name and presence or absence of angle brackets + do not affect matching. + + See Section 20.10 for the rules for parsing a display name, URI and + URI parameters, and header field parameters. + + The compact form of the From header field is f. + + Examples: + + From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s + From: sip:+12125551212@server.phone2net.com;tag=887s + f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 + +20.21 In-Reply-To + + The In-Reply-To header field enumerates the Call-IDs that this call + references or returns. These Call-IDs may have been cached by the + client then included in this header field in a return call. + + This allows automatic call distribution systems to route return + calls to the originator of the first call. This also allows + callees to filter calls, so that only return calls for calls they + originated will be accepted. This field is not a substitute for + request authentication. + + + + + +Rosenberg, et. al. Standards Track [Page 172] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com + +20.22 Max-Forwards + + The Max-Forwards header field must 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 that appears to be + failing or looping in mid-chain. + + The Max-Forwards value is an integer in the range 0-255 indicating + the remaining number of times this request message is allowed to be + forwarded. This count is decremented by each server that forwards + the request. The recommended initial value is 70. + + This header field should be inserted by elements that can not + otherwise guarantee loop detection. For example, a B2BUA should + insert a Max-Forwards header field. + + Example: + + Max-Forwards: 6 + +20.23 Min-Expires + + The Min-Expires header field conveys the minimum refresh interval + supported for soft-state elements managed by that server. This + includes Contact header fields that are stored by a registrar. The + header field contains a decimal integer number of seconds from 0 to + (2**32)-1. The use of the header field in a 423 (Interval Too Brief) + response is described in Sections 10.2.8, 10.3, and 21.4.17. + + Example: + + Min-Expires: 60 + +20.24 MIME-Version + + See [H19.4.1]. + + Example: + + MIME-Version: 1.0 + + + + + + +Rosenberg, et. al. Standards Track [Page 173] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +20.25 Organization + + The Organization header field conveys the name of the organization to + which the SIP element issuing the request or response belongs. + + The field MAY be used by client software to filter calls. + + Example: + + Organization: Boxes by Bob + +20.26 Priority + + The Priority header field indicates the urgency of the request as + perceived by the client. The Priority header field describes the + priority that the SIP request should have to the receiving human or + its agent. For example, it may be factored into decisions about call + routing and acceptance. For these decisions, a message containing no + Priority header field SHOULD be treated as if it specified a Priority + of "normal". The Priority header field does not influence the use of + communications resources such as packet forwarding priority in + routers or access to circuits in PSTN gateways. The header field can + have the values "non-urgent", "normal", "urgent", and "emergency", + but additional values can be defined elsewhere. It is RECOMMENDED + that the value of "emergency" only be used when life, limb, or + property are in imminent danger. Otherwise, there are no semantics + defined for this header field. + + These are the values of RFC 2076 [38], with the addition of + "emergency". + + Examples: + + Subject: A tornado is heading our way! + Priority: emergency + + or + + Subject: Weekend plans + Priority: non-urgent + +20.27 Proxy-Authenticate + + A Proxy-Authenticate header field value contains an authentication + challenge. + + The use of this header field is defined in [H14.33]. See Section + 22.3 for further details on its usage. + + + +Rosenberg, et. al. Standards Track [Page 174] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + Proxy-Authenticate: Digest realm="atlanta.com", + domain="sip:ss1.carrier.com", qop="auth", + nonce="f84f1cec41e6cbe5aea9c8e88d359", + opaque="", stale=FALSE, algorithm=MD5 + +20.28 Proxy-Authorization + + The Proxy-Authorization header field allows the client to identify + itself (or its user) to a proxy that requires authentication. A + 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. + + See Section 22.3 for a definition of the usage of this header field. + + This header field, along with Authorization, breaks the general rules + about multiple header field names. Although not a comma-separated + list, this header field name may be present multiple times, and MUST + NOT be combined into a single header line using the usual rules + described in Section 7.3.1. + + Example: + + Proxy-Authorization: Digest username="Alice", realm="atlanta.com", + nonce="c60f3082ee1212b402a21831ae", + response="245f23415f11432b3434341c022" + +20.29 Proxy-Require + + The Proxy-Require header field is used to indicate proxy-sensitive + features that must be supported by the proxy. See Section 20.32 for + more details on the mechanics of this message and a usage example. + + Example: + + Proxy-Require: foo + +20.30 Record-Route + + The Record-Route header field is inserted by proxies in a request to + force future requests in the dialog to be routed through the proxy. + + Examples of its use with the Route header field are described in + Sections 16.12.1. + + + + + +Rosenberg, et. al. Standards Track [Page 175] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + Record-Route: <sip:server10.biloxi.com;lr>, + <sip:bigbox3.site3.atlanta.com;lr> + +20.31 Reply-To + + The Reply-To header field contains a logical return URI that may be + different from the From header field. For example, the URI MAY be + used to return missed calls or unestablished sessions. If the user + wished to remain anonymous, the header field SHOULD either be omitted + from the request or populated in such a way that does not reveal any + private information. + + 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. Syntax issues are discussed in Section 7.3.1. + + Example: + + Reply-To: Bob <sip:bob@biloxi.com> + +20.32 Require + + The Require header field is used by UACs to tell UASs about options + that the UAC expects the UAS to support in order to process the + request. Although an optional header field, the Require MUST NOT be + ignored if it is present. + + The Require header field contains a list of option tags, described in + Section 19.2. Each option tag defines a SIP extension that MUST be + understood to process the request. Frequently, this is used to + indicate that a specific set of extension header fields need to be + understood. A UAC compliant to this specification MUST only include + option tags corresponding to standards-track RFCs. + + Example: + + Require: 100rel + +20.33 Retry-After + + The Retry-After header field can be used with a 500 (Server Internal + Error) or 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), 413 (Request Entity Too Large), 480 + (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 + + + + +Rosenberg, et. al. Standards Track [Page 176] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + (Decline) response to indicate when the called party anticipates + being available again. The value of this field is a positive integer + number of seconds (in decimal) after the time of the response. + + 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. + + Examples: + + Retry-After: 18000;duration=3600 + Retry-After: 120 (I'm in a meeting) + +20.34 Route + + The Route header field is used to force routing for a request through + the listed set of proxies. Examples of the use of the Route header + field are in Section 16.12.1. + + Example: + + Route: <sip:bigbox3.site3.atlanta.com;lr>, + <sip:server10.biloxi.com;lr> + +20.35 Server + + The Server header field contains information about the software used + by the UAS to handle the request. + + Revealing the specific software version of the server might allow the + server to become more vulnerable to attacks against software that is + known to contain security holes. Implementers SHOULD make the Server + header field a configurable option. + + Example: + + Server: HomeServer v2 + +20.36 Subject + + The Subject header field provides a summary or indicates the nature + of the call, allowing call filtering without having to parse the + session description. The session description does not have to use + the same subject indication as the invitation. + + The compact form of the Subject header field is s. + + + +Rosenberg, et. al. Standards Track [Page 177] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Example: + + Subject: Need more boxes + s: Tech Support + +20.37 Supported + + The Supported header field enumerates all the extensions supported by + the UAC or UAS. + + The Supported header field contains a list of option tags, described + in Section 19.2, that are understood by the UAC or UAS. A UA + compliant to this specification MUST only include option tags + corresponding to standards-track RFCs. If empty, it means that no + extensions are supported. + + The compact form of the Supported header field is k. + + Example: + + Supported: 100rel + +20.38 Timestamp + + The Timestamp header field describes when the UAC sent the request to + the UAS. + + See Section 8.2.6 for details on how to generate a response to a + request that contains the header field. Although there is no + normative behavior defined here that makes use of the header, it + allows for extensions or SIP applications to obtain RTT estimates. + + Example: + + Timestamp: 54 + +20.39 To + + The To header field specifies the logical recipient of the request. + + The optional "display-name" is meant to be rendered by a human-user + interface. The "tag" parameter serves as a general mechanism for + dialog identification. + + See Section 19.3 for details of the "tag" parameter. + + + + + + +Rosenberg, et. al. Standards Track [Page 178] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Comparison of To header fields for equality is identical to + comparison of From header fields. See Section 20.10 for the rules + for parsing a display name, URI and URI parameters, and header field + parameters. + + The compact form of the To header field is t. + + The following are examples of valid To header fields: + + To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 + t: sip:+12125551212@server.phone2net.com + +20.40 Unsupported + + The Unsupported header field lists the features not supported by the + UAS. See Section 20.32 for motivation. + + Example: + + Unsupported: foo + +20.41 User-Agent + + The User-Agent header field contains information about the UAC + originating the request. The semantics of this header field are + defined in [H14.43]. + + Revealing the specific software version of the user agent might allow + the user agent to become more vulnerable to attacks against software + that is known to contain security holes. Implementers SHOULD make + the User-Agent header field a configurable option. + + Example: + + User-Agent: Softphone Beta1.5 + +20.42 Via + + The Via header field indicates the path taken by the request so far + and indicates the path that should be followed in routing responses. + The branch ID parameter in the Via header field values serves as a + transaction identifier, and is used by proxies to detect loops. + + A Via header field value contains the transport protocol used to send + the message, the client's host name or network address, and possibly + the port number at which it wishes to receive responses. A Via + header field value can also contain parameters such as "maddr", + "ttl", "received", and "branch", whose meaning and use are described + + + +Rosenberg, et. al. Standards Track [Page 179] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + in other sections. For implementations compliant to this + specification, the value of the branch parameter MUST start with the + magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. + + Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". + "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the + protocol still indicates "SIP", and the transport protocol is TLS. + +Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 +Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 + ;branch=z9hG4bK77asjd + + The compact form of the Via header field is v. + + In this example, the message originated from a multi-homed host with + two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong + as to which network interface would be used. Erlang.bell- + telephone.com noticed the mismatch and added a parameter to the + previous hop's Via header field value, containing the address that + the packet actually came from. + + The host or network address and port number are not required to + follow the SIP URI syntax. Specifically, LWS on either side of the + ":" or "/" is allowed, as shown here: + + Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 + ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 + + Even though this specification mandates that the branch parameter be + present in all requests, the BNF for the header field indicates that + it is optional. This allows interoperation with RFC 2543 elements, + which did not have to insert the branch parameter. + + Two Via header fields are equal if their sent-protocol and sent-by + fields are equal, both have the same set of parameters, and the + values of all parameters are equal. + +20.43 Warning + + The Warning header field is used to carry additional information + about the status of a response. Warning header field values are sent + with responses and contain a three-digit warning code, host name, and + warning text. + + 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 user, the Accept-Language field in a request, or the + + + +Rosenberg, et. al. Standards Track [Page 180] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Content-Language field in a response. The default language is i- + default [21]. + + The currently-defined "warn-code"s are listed below, with a + recommended warn-text in English and a description of their meaning. + These warnings describe failures induced by the session description. + The first digit of warning codes beginning with "3" indicates + warnings specific to SIP. 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. + + 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). + + + +Rosenberg, et. al. Standards Track [Page 181] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 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 can be defined through IANA, as defined in + Section 27.2. + + Examples: + + Warning: 307 isi.edu "Session parameter 'foo' not understood" + Warning: 301 isi.edu "Incompatible network address type 'E.164'" + +20.44 WWW-Authenticate + + A WWW-Authenticate header field value contains an authentication + challenge. See Section 22.2 for further details on its usage. + + Example: + + WWW-Authenticate: Digest realm="atlanta.com", + domain="sip:boxesbybob.com", qop="auth", + nonce="f84f1cec41e6cbe5aea9c8e88d359", + opaque="", stale=FALSE, algorithm=MD5 + +21 Response Codes + + 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. Also, SIP defines a new class, 6xx. + +21.1 Provisional 1xx + + Provisional responses, also known as informational responses, + indicate that the server contacted is performing some further action + and does not yet have a definitive response. A server sends a 1xx + response if it expects to take more than 200 ms to obtain a final + response. Note that 1xx responses are not transmitted reliably. + They never cause the client to send an ACK. Provisional (1xx) + responses MAY contain message bodies, including session descriptions. + + + + +Rosenberg, et. al. Standards Track [Page 182] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.1.1 100 Trying + + This response indicates that the request has been received by the + next-hop server and that some unspecified action is being taken on + behalf of this call (for example, a database is being consulted). + This response, like all other provisional responses, stops + retransmissions of an INVITE by a UAC. The 100 (Trying) response is + different from other provisional responses, in that it is never + forwarded upstream by a stateful proxy. + +21.1.2 180 Ringing + + The UA receiving the INVITE is trying to alert the user. This + response MAY be used to initiate local ringback. + +21.1.3 181 Call Is Being Forwarded + + A server MAY use this status code to indicate that the call is being + forwarded to a different set of destinations. + +21.1.4 182 Queued + + The called party is temporarily unavailable, but the server 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, for example, "5 calls queued; expected waiting + time is 15 minutes". The server MAY issue several 182 (Queued) + responses to update the caller about the status of the queued call. + +21.1.5 183 Session Progress + + The 183 (Session Progress) response is used to convey information + about the progress of the call that is not otherwise classified. The + Reason-Phrase, header fields, or message body MAY be used to convey + more details about the call progress. + +21.2 Successful 2xx + + The request was successful. + +21.2.1 200 OK + + The request has succeeded. The information returned with the + response depends on the method used in the request. + + + + + + +Rosenberg, et. al. Standards Track [Page 183] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.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. + +21.3.1 300 Multiple Choices + + The address in the request resolved to several choices, each with its + own specific location, and the user (or UA) can select a preferred + communication end point and redirect its request to that location. + + The response MAY include a message body containing a list of resource + characteristics and location(s) from which the user or UA can choose + the one most appropriate, if allowed by the Accept request header + field. However, no MIME types have been defined for this message + body. + + The choices SHOULD also be listed as Contact fields (Section 20.10). + Unlike HTTP, the SIP response MAY contain several Contact fields or a + list of addresses in a Contact field. UAs 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. + +21.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 20.10). The requestor SHOULD + update any local directories, address books, and user location caches + with this new value and redirect future requests to the address(es) + listed. + +21.3.3 302 Moved Temporarily + + The requesting client SHOULD retry the request at the new address(es) + given by the Contact header field (Section 20.10). The Request-URI + of the new request uses the value of the Contact header field in the + response. + + + + + + + + +Rosenberg, et. al. Standards Track [Page 184] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The duration of the validity of the Contact URI can be indicated + through an Expires (Section 20.19) header field or an expires + parameter in the Contact header field. Both proxies and UAs MAY + cache this URI for the duration of the expiration time. If there is + no explicit expiration time, the address is only valid once for + recursing, and MUST NOT be cached for future transactions. + + If the URI cached from the Contact header field fails, the Request- + URI from the redirected request MAY be tried again a single time. + + The temporary URI may have become out-of-date sooner than the + expiration time, and a new temporary URI may be available. + +21.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 (Use Proxy) responses MUST only be generated by UASs. + +21.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. + +21.4 Request Failure 4xx + + 4xx responses are definite failure responses from a particular + server. The client SHOULD NOT retry the same request without + modification (for example, adding appropriate authorization). + However, the same request to a different server might be successful. + +21.4.1 400 Bad Request + + The request could not be understood due to malformed syntax. The + Reason-Phrase SHOULD identify the syntax problem in more detail, for + example, "Missing Call-ID header field". + +21.4.2 401 Unauthorized + + The request requires user authentication. This response is issued by + UASs and registrars, while 407 (Proxy Authentication Required) is + used by proxy servers. + + + + + +Rosenberg, et. al. Standards Track [Page 185] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.4.3 402 Payment Required + + Reserved for future use. + +21.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. + +21.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. + +21.4.6 405 Method Not Allowed + + The method specified in the Request-Line is understood, but 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. + +21.4.7 406 Not Acceptable + + The resource identified by the request is only capable of generating + response entities that have content characteristics not acceptable + according to the Accept header field sent in the request. + +21.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. SIP access + authentication is explained in Sections 26 and 22.3. + + This status code can be used for applications where access to the + communication channel (for example, a telephony gateway) rather than + the callee requires authentication. + +21.4.9 408 Request Timeout + + The server could not produce a response within a suitable amount of + time, for example, if it could not determine the location of the user + in time. The client MAY repeat the request without modifications at + any later time. + + + + + +Rosenberg, et. al. Standards Track [Page 186] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.4.10 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. + +21.4.11 413 Request Entity Too Large + + The server is refusing to process a request because the request + entity-body 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. + +21.4.12 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. + +21.4.13 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 server for + the requested method. The server MUST return a list of acceptable + formats using the Accept, Accept-Encoding, or Accept-Language header + field, depending on the specific problem with the content. UAC + processing of this response is described in Section 8.1.3.5. + +21.4.14 416 Unsupported URI Scheme + + The server cannot process the request because the scheme of the URI + in the Request-URI is unknown to the server. Client processing of + this response is described in Section 8.1.3.5. + +21.4.15 420 Bad Extension + + The server did not understand the protocol extension specified in a + Proxy-Require (Section 20.29) or Require (Section 20.32) header + field. The server MUST include a list of the unsupported extensions + in an Unsupported header field in the response. UAC processing of + this response is described in Section 8.1.3.5. + + + + + +Rosenberg, et. al. Standards Track [Page 187] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.4.16 421 Extension Required + + The UAS needs a particular extension to process the request, but this + extension is not listed in a Supported header field in the request. + Responses with this status code MUST contain a Require header field + listing the required extensions. + + A UAS SHOULD NOT use this response unless it truly cannot provide any + useful service to the client. Instead, if a desirable extension is + not listed in the Supported header field, servers SHOULD process the + request using baseline SIP capabilities and any extensions supported + by the client. + +21.4.17 423 Interval Too Brief + + The server is rejecting the request because the expiration time of + the resource refreshed by the request is too short. This response + can be used by a registrar to reject a registration whose Contact + header field expiration time was too small. The use of this response + and the related Min-Expires header field are described in Sections + 10.2.8, 10.3, and 20.23. + +21.4.18 480 Temporarily Unavailable + + The callee's end system was contacted successfully but the callee is + currently unavailable (for example, is not logged in, logged in but + in a state that precludes communication with the callee, or has + activated the "do not disturb" feature). The response MAY indicate a + better time to call in the Retry-After header field. The user could + also be available elsewhere (unbeknownst to this server). The reason + phrase SHOULD indicate a more precise cause as to why the callee is + unavailable. This value SHOULD be settable by the UA. 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 or proxy server that + recognizes the user identified by the Request-URI, but does not + currently have a valid forwarding location for that user. + +21.4.19 481 Call/Transaction Does Not Exist + + This status indicates that the UAS received a request that does not + match any existing dialog or transaction. + +21.4.20 482 Loop Detected + + The server has detected a loop (Section 16.3 Item 4). + + + + +Rosenberg, et. al. Standards Track [Page 188] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.4.21 483 Too Many Hops + + The server received a request that contains a Max-Forwards (Section + 20.22) header field with the value zero. + +21.4.22 484 Address Incomplete + + The server received a request with a Request-URI that was incomplete. + Additional information SHOULD be provided in the reason phrase. + + 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 (Address + Incomplete) status response. + +21.4.23 485 Ambiguous + + The Request-URI was ambiguous. The response MAY contain a listing of + possible unambiguous addresses in Contact header fields. Revealing + alternatives can infringe on privacy 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 for + ambiguous Request-URIs. + + Example response to a request with the Request-URI + sip:lee@example.com: + + SIP/2.0 485 Ambiguous + Contact: Carol Lee <sip:carol.lee@example.com> + Contact: Ping Lee <sip:p.lee@example.com> + Contact: Lee M. Foote <sips:lee.foote@example.com> + + 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 (Ambiguous) response. + +21.4.24 486 Busy Here + + The callee's end system was contacted successfully, but the callee is + currently not willing or able to take additional calls at this end + system. The response MAY indicate a better time to call in the + Retry-After header field. The user could also be available + + + + + +Rosenberg, et. al. Standards Track [Page 189] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + elsewhere, such as through a voice mail service. Status 600 (Busy + Everywhere) SHOULD be used if the client knows that no other end + system will be able to accept this call. + +21.4.25 487 Request Terminated + + The request was terminated by a BYE or CANCEL request. This response + is never returned for a CANCEL request itself. + +21.4.26 488 Not Acceptable Here + + The response has the same meaning as 606 (Not Acceptable), but only + applies to the specific resource addressed by the Request-URI and the + request may succeed elsewhere. + + A message body containing a description of media capabilities MAY be + present in the response, which is formatted according to the Accept + header field in the INVITE (or application/sdp if not present), the + same as a message body in a 200 (OK) response to an OPTIONS request. + +21.4.27 491 Request Pending + + The request was received by a UAS that had a pending request within + the same dialog. Section 14.2 describes how such "glare" situations + are resolved. + +21.4.28 493 Undecipherable + + The request was received by a UAS that contained an encrypted MIME + body for which the recipient does not possess or will not provide an + appropriate decryption key. This response MAY have a single body + containing an appropriate public key that should be used to encrypt + MIME bodies sent to this UA. Details of the usage of this response + code can be found in Section 23.2. + +21.5 Server Failure 5xx + + 5xx responses are failure responses given when a server itself has + erred. + +21.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. + + If the condition is temporary, the server MAY indicate when the + client may retry the request using the Retry-After header field. + + + +Rosenberg, et. al. Standards Track [Page 190] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.5.2 501 Not Implemented + + The server does not support the functionality required to fulfill the + request. This is the appropriate response when a UAS does not + recognize the request method and is not capable of supporting it for + any user. (Proxies forward all requests regardless of method.) + + Note that a 405 (Method Not Allowed) is sent when the server + recognizes the request method, but that method is not allowed or + supported. + +21.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. + +21.5.4 503 Service Unavailable + + The server is temporarily unable to process the request due to a + temporary overloading or maintenance of the server. The server MAY + indicate when the client should retry the request in a Retry-After + header field. If no Retry-After is given, the client MUST act as if + it had received a 500 (Server Internal Error) response. + + A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD + attempt to forward the request to an alternate server. It SHOULD NOT + forward any other requests to that server for the duration specified + in the Retry-After header field, if present. + + Servers MAY refuse the connection or drop the request instead of + responding with 503 (Service Unavailable). + +21.5.5 504 Server Time-out + + The server did not receive a timely response from an external server + it accessed in attempting to process the request. 408 (Request + Timeout) should be used instead if there was no response within the + period specified in the Expires header field from the upstream + server. + +21.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. 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. + + + + +Rosenberg, et. al. Standards Track [Page 191] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +21.5.7 513 Message Too Large + + The server was unable to process the request since the message length + exceeded its capabilities. + +21.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. + +21.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 field. + 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. + +21.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 field. This + status response is returned only if the client knows that no other + end point will answer the request. + +21.6.3 604 Does Not Exist Anywhere + + The server has authoritative information that the user indicated in + the Request-URI does not exist anywhere. + +21.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. Warning reason codes are listed in Section 20.43. + + + + + +Rosenberg, et. al. Standards Track [Page 192] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + A message body containing a description of media capabilities MAY be + present in the response, which is formatted according to the Accept + header field in the INVITE (or application/sdp if not present), the + same as a message body in a 200 (OK) response to an OPTIONS request. + + 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. + + This status response is returned only if the client knows that no + other end point will answer the request. + +22 Usage of HTTP Authentication + + SIP provides a stateless, challenge-based mechanism for + authentication that is based on authentication in HTTP. Any time + that a proxy server or UA receives a request (with the exceptions + given in Section 22.1), it MAY challenge the initiator of the request + to provide assurance of its identity. Once the originator has been + identified, the recipient of the request SHOULD ascertain whether or + not this user is authorized to make the request in question. No + authorization systems are recommended or discussed in this document. + + The "Digest" authentication mechanism described in this section + provides message authentication and replay protection only, without + message integrity or confidentiality. Protective measures above and + beyond those provided by Digest need to be taken to prevent active + attackers from modifying SIP requests and responses. + + Note that due to its weak security, the usage of "Basic" + authentication has been deprecated. Servers MUST NOT accept + credentials using the "Basic" authorization scheme, and servers also + MUST NOT challenge with "Basic". This is a change from RFC 2543. + +22.1 Framework + + The framework for SIP authentication closely parallels that of HTTP + (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, + challenge, realm, realm-value, and credentials is identical (although + the usage of "Basic" as a scheme is not permitted). In SIP, a UAS + uses the 401 (Unauthorized) response to challenge the identity of a + UAC. Additionally, registrars and redirect servers MAY make use of + 401 (Unauthorized) responses for authentication, but proxies MUST + NOT, and instead MAY use the 407 (Proxy Authentication Required) + + + + + +Rosenberg, et. al. Standards Track [Page 193] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + response. The requirements for inclusion of the Proxy-Authenticate, + Proxy-Authorization, WWW-Authenticate, and Authorization in the + various messages are identical to those described in RFC 2617 [17]. + + Since SIP does not have the concept of a canonical root URL, the + notion of protection spaces is interpreted differently in SIP. The + realm string alone defines the protection domain. This is a change + from RFC 2543, in which the Request-URI and the realm together + defined the protection domain. + + This previous definition of protection domain caused some amount + of confusion since the Request-URI sent by the UAC and the + Request-URI received by the challenging server might be different, + and indeed the final form of the Request-URI might not be known to + the UAC. Also, the previous definition depended on the presence + of a SIP URI in the Request-URI and seemed to rule out alternative + URI schemes (for example, the tel URL). + + Operators of user agents or proxy servers that will authenticate + received requests MUST adhere to the following guidelines for + creation of a realm string for their server: + + o Realm strings MUST be globally unique. It is RECOMMENDED that + a realm string contain a hostname or domain name, following the + recommendation in Section 3.2.1 of RFC 2617 [17]. + + o Realm strings SHOULD present a human-readable identifier that + can be rendered to a user. + + For example: + + INVITE sip:bob@biloxi.com SIP/2.0 + Authorization: Digest realm="biloxi.com", <...> + + Generally, SIP authentication is meaningful for a specific realm, a + protection domain. Thus, for Digest authentication, each such + protection domain has its own set of usernames and passwords. If a + server does not require authentication for a particular request, it + MAY accept a default username, "anonymous", which has no password + (password of ""). Similarly, UACs representing many users, such as + PSTN gateways, MAY have their own device-specific username and + password, rather than accounts for particular users, for their realm. + + While a server can legitimately challenge most SIP requests, there + are two requests defined by this document that require special + handling for authentication: ACK and CANCEL. + + + + + +Rosenberg, et. al. Standards Track [Page 194] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Under an authentication scheme that uses responses to carry values + used to compute nonces (such as Digest), some problems come up for + any requests that take no response, including ACK. For this reason, + any credentials in the INVITE that were accepted by a server MUST be + accepted by that server for the ACK. UACs creating an ACK message + will duplicate all of the Authorization and Proxy-Authorization + header field values that appeared in the INVITE to which the ACK + corresponds. Servers MUST NOT attempt to challenge an ACK. + + Although the CANCEL method does take a response (a 2xx), servers MUST + NOT attempt to challenge CANCEL requests since these requests cannot + be resubmitted. Generally, a CANCEL request SHOULD be accepted by a + server if it comes from the same hop that sent the request being + canceled (provided that some sort of transport or network layer + security association, as described in Section 26.2.1, is in place). + + When a UAC receives a challenge, it SHOULD render to the user the + contents of the "realm" parameter in the challenge (which appears in + either a WWW-Authenticate header field or Proxy-Authenticate header + field) if the UAC device does not already know of a credential for + the realm in question. A service provider that pre-configures UAs + with credentials for its realm should be aware that users will not + have the opportunity to present their own credentials for this realm + when challenged at a pre-configured device. + + Finally, note that even if a UAC can locate credentials that are + associated with the proper realm, the potential exists that these + credentials may no longer be valid or that the challenging server + will not accept these credentials for whatever reason (especially + when "anonymous" with no password is submitted). In this instance a + server may repeat its challenge, or it may respond with a 403 + Forbidden. A UAC MUST NOT re-attempt requests with the credentials + that have just been rejected (though the request may be retried if + the nonce was stale). + +22.2 User-to-User Authentication + + When a UAS receives a request from a UAC, the UAS MAY authenticate + the originator before the request is processed. If no credentials + (in the Authorization header field) are provided in the request, the + UAS can challenge the originator to provide credentials by rejecting + the request with a 401 (Unauthorized) status code. + + 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 realm. + + + + +Rosenberg, et. al. Standards Track [Page 195] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + An example of the WWW-Authenticate header field in a 401 challenge + is: + + WWW-Authenticate: Digest + realm="biloxi.com", + qop="auth,auth-int", + nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", + opaque="5ccc069c403ebaf9f0171e9517f40e41" + + When the originating UAC receives the 401 (Unauthorized), it SHOULD, + if it is able, re-originate the request with the proper credentials. + The UAC may require input from the originating user before + proceeding. Once authentication credentials have been supplied + (either directly by the user, or discovered in an internal keyring), + UAs SHOULD cache the credentials for a given value of the To header + field and "realm" and attempt to re-use these values on the next + request for that destination. UAs MAY cache credentials in any way + they would like. + + If no credentials for a realm can be located, UACs MAY attempt to + retry the request with a username of "anonymous" and no password (a + password of ""). + + Once credentials have been located, any UA that wishes to + authenticate itself with a UAS or registrar -- usually, but not + necessarily, after receiving a 401 (Unauthorized) response -- MAY do + so by including an Authorization header field with the request. The + Authorization field value consists of credentials containing the + authentication information of the UA for the realm of the resource + being requested as well as parameters required in support of + authentication and replay protection. + + An example of the Authorization header field is: + + Authorization: Digest username="bob", + realm="biloxi.com", + nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", + uri="sip:bob@biloxi.com", + qop=auth, + nc=00000001, + cnonce="0a4f113b", + response="6629fae49393a05397450978507c4ef1", + opaque="5ccc069c403ebaf9f0171e9517f40e41" + + When a UAC resubmits a request with its credentials after receiving a + 401 (Unauthorized) or 407 (Proxy Authentication Required) response, + it MUST increment the CSeq header field value as it would normally + when sending an updated request. + + + +Rosenberg, et. al. Standards Track [Page 196] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +22.3 Proxy-to-User Authentication + + Similarly, when a UAC sends a request to a proxy server, the proxy + server MAY authenticate the originator before the request is + processed. If no credentials (in the Proxy-Authorization header + field) are provided in the request, the proxy can challenge the + originator to provide credentials by rejecting the request with a 407 + (Proxy Authentication Required) status code. The proxy MUST populate + the 407 (Proxy Authentication Required) message with a Proxy- + Authenticate header field value applicable to the proxy for the + requested resource. + + The use of Proxy-Authenticate and Proxy-Authorization parallel that + described in [17], with one difference. Proxies MUST NOT add values + to the Proxy-Authorization header field. All 407 (Proxy + Authentication Required) responses MUST be forwarded upstream toward + the UAC following the procedures for any other response. It is the + UAC's responsibility to add the Proxy-Authorization header field + value containing credentials for the realm of the proxy that has + asked for authentication. + + If a proxy were to resubmit a request adding a Proxy-Authorization + header field value, it would need to increment the CSeq in the new + request. However, this would cause the UAC that submitted the + original request to discard a response from the UAS, as the CSeq + value would be different. + + When the originating UAC receives the 407 (Proxy Authentication + Required) it SHOULD, if it is able, re-originate the request with the + proper credentials. It should follow the same procedures for the + display of the "realm" parameter that are given above for responding + to 401. + + If no credentials for a realm can be located, UACs MAY attempt to + retry the request with a username of "anonymous" and no password (a + password of ""). + + The UAC SHOULD also cache the credentials used in the re-originated + request. + + The following rule is RECOMMENDED for proxy credential caching: + + If a UA receives a Proxy-Authenticate header field value in a 401/407 + response to a request with a particular Call-ID, it should + incorporate credentials for that realm in all subsequent requests + that contain the same Call-ID. These credentials MUST NOT be cached + across dialogs; however, if a UA is configured with the realm of its + local outbound proxy, when one exists, then the UA MAY cache + + + +Rosenberg, et. al. Standards Track [Page 197] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + credentials for that realm across dialogs. Note that this does mean + a future request in a dialog could contain credentials that are not + needed by any proxy along the Route header path. + + Any UA that wishes to authenticate itself to a proxy server -- + usually, but not necessarily, after receiving a 407 (Proxy + Authentication Required) response -- MAY do so by including a Proxy- + Authorization header field value with the request. The Proxy- + Authorization request-header field allows the client to identify + itself (or its user) to a proxy that requires authentication. The + Proxy-Authorization header field value consists of credentials + containing the authentication information of the UA for the proxy + and/or realm of the resource being requested. + + A Proxy-Authorization header field value applies only to the proxy + whose realm is identified in the "realm" parameter (this proxy may + previously have demanded authentication using the Proxy-Authenticate + field). When multiple proxies are used in a chain, a Proxy- + Authorization header field value MUST NOT be consumed by any proxy + whose realm does not match the "realm" parameter specified in that + value. + + Note that if an authentication scheme that does not support realms is + used in the Proxy-Authorization header field, a proxy server MUST + attempt to parse all Proxy-Authorization header field values to + determine whether one of them has what the proxy server considers to + be valid credentials. Because this is potentially very time- + consuming in large networks, proxy servers SHOULD use an + authentication scheme that supports realms in the Proxy-Authorization + header field. + + If a request is forked (as described in Section 16.7), various proxy + servers and/or UAs may wish to challenge the UAC. In this case, the + forking proxy server is responsible for aggregating these challenges + into a single response. Each WWW-Authenticate and Proxy-Authenticate + value received in responses to the forked request MUST be placed into + the single response that is sent by the forking proxy to the UA; the + ordering of these header field values is not significant. + + When a proxy server issues a challenge in response to a request, + it will not proxy the request until the UAC has retried the + request with valid credentials. A forking proxy may forward a + request simultaneously to multiple proxy servers that require + authentication, each of which in turn will not forward the request + until the originating UAC has authenticated itself in their + respective realm. If the UAC does not provide credentials for + + + + + +Rosenberg, et. al. Standards Track [Page 198] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + each challenge, the proxy servers that issued the challenges will + not forward requests to the UA where the destination user might be + located, and therefore, the virtues of forking are largely lost. + + When resubmitting its request in response to a 401 (Unauthorized) or + 407 (Proxy Authentication Required) that contains multiple + challenges, a UAC MAY include an Authorization value for each WWW- + Authenticate value and a Proxy-Authorization value for each Proxy- + Authenticate value for which the UAC wishes to supply a credential. + As noted above, multiple credentials in a request SHOULD be + differentiated by the "realm" parameter. + + It is possible for multiple challenges associated with the same realm + to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication + Required). This can occur, for example, when multiple proxies within + the same administrative domain, which use a common realm, are reached + by a forking request. When it retries a request, a UAC MAY therefore + supply multiple credentials in Authorization or Proxy-Authorization + header fields with the same "realm" parameter value. The same + credentials SHOULD be used for the same realm. + +22.4 The Digest Authentication Scheme + + This section describes the modifications and clarifications required + to apply the HTTP Digest authentication scheme to SIP. The SIP + scheme usage is almost completely identical to that for HTTP [17]. + + Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], + SIP servers supporting RFC 2617 MUST ensure they are backwards + compatible with RFC 2069. Procedures for this backwards + compatibility are specified in RFC 2617. Note, however, that SIP + servers MUST NOT accept or request Basic authentication. + + The rules for Digest authentication follow those defined in [17], + 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-URI / SIPS-URI + + 2. The BNF in RFC 2617 has an error in that the 'uri' parameter + of the Authorization header field for HTTP Digest + + + + + + + + +Rosenberg, et. al. Standards Track [Page 199] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + authentication is not enclosed in quotation marks. (The + example in Section 3.5 of RFC 2617 is correct.) For SIP, the + 'uri' MUST be enclosed in quotation marks. + + 3. The BNF for digest-uri-value is: + + digest-uri-value = Request-URI ; as defined in Section 25 + + 4. The example procedure for choosing a nonce based on Etag does + not work for SIP. + + 5. The text in RFC 2617 [17] regarding cache operation does not + apply to SIP. + + 6. RFC 2617 [17] requires that a server check that the URI in the + request line and the URI included in the Authorization header + field point to the same resource. In a SIP context, these two + URIs may 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 field value + corresponds to a user for whom the server is willing to accept + forwarded or direct requests, but it is not necessarily a + failure if the two fields are not equivalent. + + 7. As a clarification to the calculation of the A2 value for + message integrity assurance in the Digest authentication + scheme, implementers should assume, when the entity-body is + empty (that is, when SIP messages have no body) that the hash + of the entity-body resolves to the MD5 hash of an empty + string, or: + + H(entity-body) = MD5("") = + "d41d8cd98f00b204e9800998ecf8427e" + + 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an + Authorization (and by extension Proxy-Authorization) header + field if no qop directive has been sent. Therefore, any + algorithms that have a dependency on the cnonce (including + "MD5-Sess") require that the qop directive be sent. Use of + the "qop" parameter is optional in RFC 2617 for the purposes + of backwards compatibility with RFC 2069; since RFC 2543 was + based on RFC 2069, the "qop" parameter must unfortunately + remain optional for clients and servers to receive. However, + servers MUST always send a "qop" parameter in WWW-Authenticate + and Proxy-Authenticate header field values. If a client + receives a "qop" parameter in a challenge header field, it + MUST send the "qop" parameter in any resulting authorization + header field. + + + +Rosenberg, et. al. Standards Track [Page 200] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + RFC 2543 did not allow usage of the Authentication-Info header field + (it effectively used RFC 2069). However, we now allow usage of this + header field, since it provides integrity checks over the bodies and + provides mutual authentication. RFC 2617 [17] defines mechanisms for + backwards compatibility using the qop attribute in the request. + These mechanisms MUST be used by a server to determine if the client + supports the new mechanisms in RFC 2617 that were not specified in + RFC 2069. + +23 S/MIME + + SIP messages carry MIME bodies and the MIME standard includes + mechanisms for securing MIME contents to ensure both integrity and + confidentiality (including the 'multipart/signed' and + 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] + and RFC 2633 [24]). Implementers should note, however, that there + may be rare network intermediaries (not typical proxy servers) that + rely on viewing or modifying the bodies of SIP messages (especially + SDP), and that secure MIME may prevent these sorts of intermediaries + from functioning. + + This applies particularly to certain types of firewalls. + + The PGP mechanism for encrypting the header fields and bodies of + SIP messages described in RFC 2543 has been deprecated. + +23.1 S/MIME Certificates + + The certificates that are used to identify an end-user for the + purposes of S/MIME differ from those used by servers in one important + respect - rather than asserting that the identity of the holder + corresponds to a particular hostname, these certificates assert that + the holder is identified by an end-user address. This address is + composed of the concatenation of the "userinfo" "@" and "domainname" + portions of a SIP or SIPS URI (in other words, an email address of + the form "bob@biloxi.com"), most commonly corresponding to a user's + address-of-record. + + These certificates are also associated with keys that are used to + sign or encrypt bodies of SIP messages. Bodies are signed with the + private key of the sender (who may include their public key with the + message as appropriate), but bodies are encrypted with the public key + of the intended recipient. Obviously, senders must have + foreknowledge of the public key of recipients in order to encrypt + message bodies. Public keys can be stored within a UA on a virtual + keyring. + + + + + +Rosenberg, et. al. Standards Track [Page 201] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Each user agent that supports S/MIME MUST contain a keyring + specifically for end-users' certificates. This keyring should map + between addresses of record and corresponding certificates. Over + time, users SHOULD use the same certificate when they populate the + originating URI of signaling (the From header field) with the same + address-of-record. + + Any mechanisms depending on the existence of end-user certificates + are seriously limited in that there is virtually no consolidated + authority today that provides certificates for end-user applications. + However, users SHOULD acquire certificates from known public + certificate authorities. As an alternative, users MAY create self- + signed certificates. The implications of self-signed certificates + are explored further in Section 26.4.2. Implementations may also use + pre-configured certificates in deployments in which a previous trust + relationship exists between all SIP entities. + + Above and beyond the problem of acquiring an end-user certificate, + there are few well-known centralized directories that distribute + end-user certificates. However, the holder of a certificate SHOULD + publish their certificate in any public directories as appropriate. + Similarly, UACs SHOULD support a mechanism for importing (manually or + automatically) certificates discovered in public directories + corresponding to the target URIs of SIP requests. + +23.2 S/MIME Key Exchange + + SIP itself can also be used as a means to distribute public keys in + the following manner. + + Whenever the CMS SignedData message is used in S/MIME for SIP, it + MUST contain the certificate bearing the public key necessary to + verify the signature. + + When a UAC sends a request containing an S/MIME body that initiates a + dialog, or sends a non-INVITE request outside the context of a + dialog, the UAC SHOULD structure the body as an S/MIME + 'multipart/signed' CMS SignedData body. If the desired CMS service + is EnvelopedData (and the public key of the target user is known), + the UAC SHOULD send the EnvelopedData message encapsulated within a + SignedData message. + + When a UAS receives a request containing an S/MIME CMS body that + includes a certificate, the UAS SHOULD first validate the + certificate, if possible, with any available root certificates for + certificate authorities. The UAS SHOULD also determine the subject + of the certificate (for S/MIME, the SubjectAltName will contain the + appropriate identity) and compare this value to the From header field + + + +Rosenberg, et. al. Standards Track [Page 202] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + of the request. If the certificate cannot be verified, because it is + self-signed, or signed by no known authority, or if it is verifiable + but its subject does not correspond to the From header field of + request, the UAS MUST notify its user of the status of the + certificate (including the subject of the certificate, its signer, + and any key fingerprint information) and request explicit permission + before proceeding. If the certificate was successfully verified and + the subject of the certificate corresponds to the From header field + of the SIP request, or if the user (after notification) explicitly + authorizes the use of the certificate, the UAS SHOULD add this + certificate to a local keyring, indexed by the address-of-record of + the holder of the certificate. + + When a UAS sends a response containing an S/MIME body that answers + the first request in a dialog, or a response to a non-INVITE request + outside the context of a dialog, the UAS SHOULD structure the body as + an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS + service is EnvelopedData, the UAS SHOULD send the EnvelopedData + message encapsulated within a SignedData message. + + When a UAC receives a response containing an S/MIME CMS body that + includes a certificate, the UAC SHOULD first validate the + certificate, if possible, with any appropriate root certificate. The + UAC SHOULD also determine the subject of the certificate and compare + this value to the To field of the response; although the two may very + well be different, and this is not necessarily indicative of a + security breach. If the certificate cannot be verified because it is + self-signed, or signed by no known authority, the UAC MUST notify its + user of the status of the certificate (including the subject of the + certificate, its signator, and any key fingerprint information) and + request explicit permission before proceeding. If the certificate + was successfully verified, and the subject of the certificate + corresponds to the To header field in the response, or if the user + (after notification) explicitly authorizes the use of the + certificate, the UAC SHOULD add this certificate to a local keyring, + indexed by the address-of-record of the holder of the certificate. + If the UAC had not transmitted its own certificate to the UAS in any + previous transaction, it SHOULD use a CMS SignedData body for its + next request or response. + + On future occasions, when the UA receives requests or responses that + contain a From header field corresponding to a value in its keyring, + the UA SHOULD compare the certificate offered in these messages with + the existing certificate in its keyring. If there is a discrepancy, + the UA MUST notify its user of a change of the certificate + (preferably in terms that indicate that this is a potential security + breach) and acquire the user's permission before continuing to + + + + +Rosenberg, et. al. Standards Track [Page 203] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + process the signaling. If the user authorizes this certificate, it + SHOULD be added to the keyring alongside any previous value(s) for + this address-of-record. + + Note well however, that this key exchange mechanism does not + guarantee the secure exchange of keys when self-signed certificates, + or certificates signed by an obscure authority, are used - it is + vulnerable to well-known attacks. In the opinion of the authors, + however, the security it provides is proverbially better than + nothing; it is in fact comparable to the widely used SSH application. + These limitations are explored in greater detail in Section 26.4.2. + + If a UA receives an S/MIME body that has been encrypted with a public + key unknown to the recipient, it MUST reject the request with a 493 + (Undecipherable) response. This response SHOULD contain a valid + certificate for the respondent (corresponding, if possible, to any + address of record given in the To header field of the rejected + request) within a MIME body with a 'certs-only' "smime-type" + parameter. + + A 493 (Undecipherable) sent without any certificate indicates that + the respondent cannot or will not utilize S/MIME encrypted messages, + though they may still support S/MIME signatures. + + Note that a user agent that receives a request containing an S/MIME + body that is not optional (with a Content-Disposition header + "handling" parameter of "required") MUST reject the request with a + 415 Unsupported Media Type response if the MIME type is not + understood. A user agent that receives such a response when S/MIME + is sent SHOULD notify its user that the remote device does not + support S/MIME, and it MAY subsequently resend the request without + S/MIME, if appropriate; however, this 415 response may constitute a + downgrade attack. + + If a user agent sends an S/MIME body in a request, but receives a + response that contains a MIME body that is not secured, the UAC + SHOULD notify its user that the session could not be secured. + However, if a user agent that supports S/MIME receives a request with + an unsecured body, it SHOULD NOT respond with a secured body, but if + it expects S/MIME from the sender (for example, because the sender's + From header field value corresponds to an identity on its keychain), + the UAS SHOULD notify its user that the session could not be secured. + + A number of conditions that arise in the previous text call for the + notification of the user when an anomalous certificate-management + event occurs. Users might well ask what they should do under these + circumstances. First and foremost, an unexpected change in a + certificate, or an absence of security when security is expected, are + + + +Rosenberg, et. al. Standards Track [Page 204] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + causes for caution but not necessarily indications that an attack is + in progress. Users might abort any connection attempt or refuse a + connection request they have received; in telephony parlance, they + could hang up and call back. Users may wish to find an alternate + means to contact the other party and confirm that their key has + legitimately changed. Note that users are sometimes compelled to + change their certificates, for example when they suspect that the + secrecy of their private key has been compromised. When their + private key is no longer private, users must legitimately generate a + new key and re-establish trust with any users that held their old + key. + + Finally, if during the course of a dialog a UA receives a certificate + in a CMS SignedData message that does not correspond with the + certificates previously exchanged during a dialog, the UA MUST notify + its user of the change, preferably in terms that indicate that this + is a potential security breach. + +23.3 Securing MIME bodies + + There are two types of secure MIME bodies that are of interest to + SIP: use of these bodies should follow the S/MIME specification [24] + with a few variations. + + o "multipart/signed" MUST be used only with CMS detached + signatures. + + This allows backwards compatibility with non-S/MIME- + compliant recipients. + + o S/MIME bodies SHOULD have a Content-Disposition header field, + and the value of the "handling" parameter SHOULD be "required." + + o If a UAC has no certificate on its keyring associated with the + address-of-record to which it wants to send a request, it + cannot send an encrypted "application/pkcs7-mime" MIME message. + UACs MAY send an initial request such as an OPTIONS message + with a CMS detached signature in order to solicit the + certificate of the remote side (the signature SHOULD be over a + "message/sip" body of the type described in Section 23.4). + + Note that future standardization work on S/MIME may define + non-certificate based keys. + + o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" + (see Section 2.5.2 of [24]) attribute to express their + capabilities and preferences for further communications. Note + especially that senders MAY use the "preferSignedData" + + + +Rosenberg, et. al. Standards Track [Page 205] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + capability to encourage receivers to respond with CMS + SignedData messages (for example, when sending an OPTIONS + request as described above). + + o S/MIME implementations MUST at a minimum support SHA1 as a + digital signature algorithm, and 3DES as an encryption + algorithm. All other signature and encryption algorithms MAY + be supported. Implementations can negotiate support for these + algorithms with the "SMIMECapabilities" attribute. + + o Each S/MIME body in a SIP message SHOULD be signed with only + one certificate. If a UA receives a message with multiple + signatures, the outermost signature should be treated as the + single certificate for this body. Parallel signatures SHOULD + NOT be used. + + The following is an example of an encrypted S/MIME SDP body + within a SIP message: + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + To: Bob <sip:bob@biloxi.com> + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Max-Forwards: 70 + Contact: <sip:alice@pc33.atlanta.com> + Content-Type: application/pkcs7-mime; smime-type=enveloped-data; + name=smime.p7m + Content-Disposition: attachment; filename=smime.p7m + handling=required + + ******************************************************* + * Content-Type: application/sdp * + * * + * v=0 * + * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * + * s=- * + * t=0 0 * + * c=IN IP4 pc33.atlanta.com * + * m=audio 3456 RTP/AVP 0 1 3 99 * + * a=rtpmap:0 PCMU/8000 * + ******************************************************* + + + + + + + + +Rosenberg, et. al. Standards Track [Page 206] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP + + As a means of providing some degree of end-to-end authentication, + integrity or confidentiality for SIP header fields, S/MIME can + encapsulate entire SIP messages within MIME bodies of type + "message/sip" and then apply MIME security to these bodies in the + same manner as typical SIP bodies. These encapsulated SIP requests + and responses do not constitute a separate dialog or transaction, + they are a copy of the "outer" message that is used to verify + integrity or to supply additional information. + + If a UAS receives a request that contains a tunneled "message/sip" + S/MIME body, it SHOULD include a tunneled "message/sip" body in the + response with the same smime-type. + + Any traditional MIME bodies (such as SDP) SHOULD be attached to the + "inner" message so that they can also benefit from S/MIME security. + Note that "message/sip" bodies can be sent as a part of a MIME + "multipart/mixed" body if any unsecured MIME types should also be + transmitted in a request. + +23.4.1 Integrity and Confidentiality Properties of SIP Headers + + When the S/MIME integrity or confidentiality mechanisms are used, + there may be discrepancies between the values in the "inner" message + and values in the "outer" message. The rules for handling any such + differences for all of the header fields described in this document + are given in this section. + + Note that for the purposes of loose timestamping, all SIP messages + that tunnel "message/sip" SHOULD contain a Date header in both the + "inner" and "outer" headers. + +23.4.1.1 Integrity + + Whenever integrity checks are performed, the integrity of a header + field should be determined by matching the value of the header field + in the signed body with that in the "outer" messages using the + comparison rules of SIP as described in 20. + + Header fields that can be legitimately modified by proxy servers are: + Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- + Authorization. If these header fields are not intact end-to-end, + implementations SHOULD NOT consider this a breach of security. + Changes to any other header fields defined in this document + constitute an integrity violation; users MUST be notified of a + discrepancy. + + + + +Rosenberg, et. al. Standards Track [Page 207] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +23.4.1.2 Confidentiality + + When messages are encrypted, header fields may be included in the + encrypted body that are not present in the "outer" message. + + Some header fields must always have a plaintext version because they + are required header fields in requests and responses - these include: + + To, From, Call-ID, CSeq, Contact. While it is probably not useful to + provide an encrypted alternative for the Call-ID, CSeq, or Contact, + providing an alternative to the information in the "outer" To or From + is permitted. Note that the values in an encrypted body are not used + for the purposes of identifying transactions or dialogs - they are + merely informational. If the From header field in an encrypted body + differs from the value in the "outer" message, the value within the + encrypted body SHOULD be displayed to the user, but MUST NOT be used + in the "outer" header fields of any future messages. + + Primarily, a user agent will want to encrypt header fields that have + an end-to-end semantic, including: Subject, Reply-To, Organization, + Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, + Authentication-Info, Expires, In-Reply-To, Require, Supported, + Unsupported, Retry-After, User-Agent, Server, and Warning. If any of + these header fields are present in an encrypted body, they should be + used instead of any "outer" header fields, whether this entails + displaying the header field values to users or setting internal + states in the UA. They SHOULD NOT however be used in the "outer" + headers of any future messages. + + If present, the Date header field MUST always be the same in the + "inner" and "outer" headers. + + Since MIME bodies are attached to the "inner" message, + implementations will usually encrypt MIME-specific header fields, + including: MIME-Version, Content-Type, Content-Length, Content- + Language, Content-Encoding and Content-Disposition. The "outer" + message will have the proper MIME header fields for S/MIME bodies. + These header fields (and any MIME bodies they preface) should be + treated as normal MIME header fields and bodies received in a SIP + message. + + It is not particularly useful to encrypt the following header fields: + Min-Expires, Timestamp, Authorization, Priority, and WWW- + Authenticate. This category also includes those header fields that + can be changed by proxy servers (described in the preceding section). + UAs SHOULD never include these in an "inner" message if they are not + + + + + +Rosenberg, et. al. Standards Track [Page 208] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + included in the "outer" message. UAs that receive any of these + header fields in an encrypted body SHOULD ignore the encrypted + values. + + Note that extensions to SIP may define additional header fields; the + authors of these extensions should describe the integrity and + confidentiality properties of such header fields. If a SIP UA + encounters an unknown header field with an integrity violation, it + MUST ignore the header field. + +23.4.2 Tunneling Integrity and Authentication + + Tunneling SIP messages within S/MIME bodies can provide integrity for + SIP header fields if the header fields that the sender wishes to + secure are replicated in a "message/sip" MIME body signed with a CMS + detached signature. + + Provided that the "message/sip" body contains at least the + fundamental dialog identifiers (To, From, Call-ID, CSeq), then a + signed MIME body can provide limited authentication. At the very + least, if the certificate used to sign the body is unknown to the + recipient and cannot be verified, the signature can be used to + ascertain that a later request in a dialog was transmitted by the + same certificate-holder that initiated the dialog. If the recipient + of the signed MIME body has some stronger incentive to trust the + certificate (they were able to validate it, they acquired it from a + trusted repository, or they have used it frequently) then the + signature can be taken as a stronger assertion of the identity of the + subject of the certificate. + + In order to eliminate possible confusions about the addition or + subtraction of entire header fields, senders SHOULD replicate all + header fields from the request within the signed body. Any message + bodies that require integrity protection MUST be attached to the + "inner" message. + + If a Date header is present in a message with a signed body, the + recipient SHOULD compare the header field value with its own internal + clock, if applicable. If a significant time discrepancy is detected + (on the order of an hour or more), the user agent SHOULD alert the + user to the anomaly, and note that it is a potential security breach. + + If an integrity violation in a message is detected by its recipient, + the message MAY be rejected with a 403 (Forbidden) response if it is + a request, or any existing dialog MAY be terminated. UAs SHOULD + notify users of this circumstance and request explicit guidance on + how to proceed. + + + + +Rosenberg, et. al. Standards Track [Page 209] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The following is an example of the use of a tunneled "message/sip" + body: + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + To: Bob <sip:bob@biloxi.com> + From: Alice <sip:alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Max-Forwards: 70 + Date: Thu, 21 Feb 2002 13:02:03 GMT + Contact: <sip:alice@pc33.atlanta.com> + Content-Type: multipart/signed; + protocol="application/pkcs7-signature"; + micalg=sha1; boundary=boundary42 + Content-Length: 568 + + --boundary42 + Content-Type: message/sip + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + To: Bob <bob@biloxi.com> + From: Alice <alice@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Max-Forwards: 70 + Date: Thu, 21 Feb 2002 13:02:03 GMT + Contact: <sip:alice@pc33.atlanta.com> + Content-Type: application/sdp + Content-Length: 147 + + v=0 + o=UserA 2890844526 2890844526 IN IP4 here.com + s=Session SDP + c=IN IP4 pc33.atlanta.com + t=0 0 + m=audio 49172 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + + --boundary42 + Content-Type: application/pkcs7-signature; name=smime.p7s + Content-Transfer-Encoding: base64 + Content-Disposition: attachment; filename=smime.p7s; + handling=required + + + + + + +Rosenberg, et. al. Standards Track [Page 210] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 + 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj + n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 + 7GhIGfHfYT64VQbnj756 + + --boundary42- + +23.4.3 Tunneling Encryption + + It may also be desirable to use this mechanism to encrypt a + "message/sip" MIME body within a CMS EnvelopedData message S/MIME + body, but in practice, most header fields are of at least some use to + the network; the general use of encryption with S/MIME is to secure + message bodies like SDP rather than message headers. Some + informational header fields, such as the Subject or Organization + could perhaps warrant end-to-end security. Headers defined by future + SIP applications might also require obfuscation. + + Another possible application of encrypting header fields is selective + anonymity. A request could be constructed with a From header field + that contains no personal information (for example, + sip:anonymous@anonymizer.invalid). However, a second From header + field containing the genuine address-of-record of the originator + could be encrypted within a "message/sip" MIME body where it will + only be visible to the endpoints of a dialog. + + Note that if this mechanism is used for anonymity, the From header + field will no longer be usable by the recipient of a message as an + index to their certificate keychain for retrieving the proper + S/MIME key to associated with the sender. The message must first + be decrypted, and the "inner" From header field MUST be used as an + index. + + In order to provide end-to-end integrity, encrypted "message/sip" + MIME bodies SHOULD be signed by the sender. This creates a + "multipart/signed" MIME body that contains an encrypted body and a + signature, both of type "application/pkcs7-mime". + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 211] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + In the following example, of an encrypted and signed message, the + text boxed in asterisks ("*") is encrypted: + + INVITE sip:bob@biloxi.com SIP/2.0 + Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + To: Bob <sip:bob@biloxi.com> + From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 + Call-ID: a84b4c76e66710 + CSeq: 314159 INVITE + Max-Forwards: 70 + Date: Thu, 21 Feb 2002 13:02:03 GMT + Contact: <sip:pc33.atlanta.com> + Content-Type: multipart/signed; + protocol="application/pkcs7-signature"; + micalg=sha1; boundary=boundary42 + Content-Length: 568 + + --boundary42 + Content-Type: application/pkcs7-mime; smime-type=enveloped-data; + name=smime.p7m + Content-Transfer-Encoding: base64 + Content-Disposition: attachment; filename=smime.p7m + handling=required + Content-Length: 231 + + *********************************************************** + * Content-Type: message/sip * + * * + * INVITE sip:bob@biloxi.com SIP/2.0 * + * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * + * To: Bob <bob@biloxi.com> * + * From: Alice <alice@atlanta.com>;tag=1928301774 * + * Call-ID: a84b4c76e66710 * + * CSeq: 314159 INVITE * + * Max-Forwards: 70 * + * Date: Thu, 21 Feb 2002 13:02:03 GMT * + * Contact: <sip:alice@pc33.atlanta.com> * + * * + * Content-Type: application/sdp * + * * + * v=0 * + * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * + * s=Session SDP * + * t=0 0 * + * c=IN IP4 pc33.atlanta.com * + * m=audio 3456 RTP/AVP 0 1 3 99 * + * a=rtpmap:0 PCMU/8000 * + *********************************************************** + + + +Rosenberg, et. al. Standards Track [Page 212] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + --boundary42 + Content-Type: application/pkcs7-signature; name=smime.p7s + Content-Transfer-Encoding: base64 + Content-Disposition: attachment; filename=smime.p7s; + handling=required + + ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 + 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj + n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 + 7GhIGfHfYT64VQbnj756 + + --boundary42- + +24 Examples + + In the following examples, we often omit the message body and the + corresponding Content-Length and Content-Type header fields for + brevity. + +24.1 Registration + + Bob registers on start-up. The message flow is shown in Figure 9. + Note that the authentication usually required for registration is not + shown for simplicity. + + biloxi.com Bob's + registrar softphone + | | + | REGISTER F1 | + |<---------------| + | 200 OK F2 | + |--------------->| + + Figure 9: SIP Registration Example + + F1 REGISTER Bob -> Registrar + + REGISTER sip:registrar.biloxi.com SIP/2.0 + Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 + Max-Forwards: 70 + To: Bob <sip:bob@biloxi.com> + From: Bob <sip:bob@biloxi.com>;tag=456248 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Contact: <sip:bob@192.0.2.4> + Expires: 7200 + Content-Length: 0 + + + + +Rosenberg, et. al. Standards Track [Page 213] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The registration expires after two hours. The registrar responds + with a 200 OK: + + F2 200 OK Registrar -> Bob + + SIP/2.0 200 OK + Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 + ;received=192.0.2.4 + To: Bob <sip:bob@biloxi.com>;tag=2493k59kd + From: Bob <sip:bob@biloxi.com>;tag=456248 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Contact: <sip:bob@192.0.2.4> + Expires: 7200 + Content-Length: 0 + +24.2 Session Setup + + This example contains the full details of the example session setup + in Section 4. The message flow is shown in Figure 1. Note that + these flows show the minimum required set of header fields - some + other header fields such as Allow and Supported would normally be + present. + +F1 INVITE Alice -> atlanta.com proxy + +INVITE sip:bob@biloxi.com SIP/2.0 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 +Max-Forwards: 70 +To: Bob <sip:bob@biloxi.com> +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:alice@pc33.atlanta.com> +Content-Type: application/sdp +Content-Length: 142 + +(Alice's SDP not shown) + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 214] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +F2 100 Trying atlanta.com proxy -> Alice + +SIP/2.0 100 Trying +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com> +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Content-Length: 0 + +F3 INVITE atlanta.com proxy -> biloxi.com proxy + +INVITE sip:bob@biloxi.com SIP/2.0 +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +Max-Forwards: 69 +To: Bob <sip:bob@biloxi.com> +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:alice@pc33.atlanta.com> +Content-Type: application/sdp +Content-Length: 142 + +(Alice's SDP not shown) + +F4 100 Trying biloxi.com proxy -> atlanta.com proxy + +SIP/2.0 100 Trying +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com> +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Content-Length: 0 + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 215] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +F5 INVITE biloxi.com proxy -> Bob + +INVITE sip:bob@192.0.2.4 SIP/2.0 +Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +Max-Forwards: 68 +To: Bob <sip:bob@biloxi.com> +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:alice@pc33.atlanta.com> +Content-Type: application/sdp +Content-Length: 142 + +(Alice's SDP not shown) + +F6 180 Ringing Bob -> biloxi.com proxy + +SIP/2.0 180 Ringing +Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 + ;received=192.0.2.3 +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +Contact: <sip:bob@192.0.2.4> +CSeq: 314159 INVITE +Content-Length: 0 + +F7 180 Ringing biloxi.com proxy -> atlanta.com proxy + +SIP/2.0 180 Ringing +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +Contact: <sip:bob@192.0.2.4> +CSeq: 314159 INVITE +Content-Length: 0 + + + +Rosenberg, et. al. Standards Track [Page 216] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +F8 180 Ringing atlanta.com proxy -> Alice + +SIP/2.0 180 Ringing +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +Contact: <sip:bob@192.0.2.4> +CSeq: 314159 INVITE +Content-Length: 0 + +F9 200 OK Bob -> biloxi.com proxy + +SIP/2.0 200 OK +Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 + ;received=192.0.2.3 +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:bob@192.0.2.4> +Content-Type: application/sdp +Content-Length: 131 + +(Bob's SDP not shown) + +F10 200 OK biloxi.com proxy -> atlanta.com proxy + +SIP/2.0 200 OK +Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 + ;received=192.0.2.2 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:bob@192.0.2.4> +Content-Type: application/sdp +Content-Length: 131 + +(Bob's SDP not shown) + + + + +Rosenberg, et. al. Standards Track [Page 217] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +F11 200 OK atlanta.com proxy -> Alice + +SIP/2.0 200 OK +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 + ;received=192.0.2.1 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 INVITE +Contact: <sip:bob@192.0.2.4> +Content-Type: application/sdp +Content-Length: 131 + +(Bob's SDP not shown) + +F12 ACK Alice -> Bob + +ACK sip:bob@192.0.2.4 SIP/2.0 +Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 +Max-Forwards: 70 +To: Bob <sip:bob@biloxi.com>;tag=a6c85cf +From: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 314159 ACK +Content-Length: 0 + + The media session between Alice and Bob is now established. + + Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq + numbering space, which, in this example, begins with 231. Since Bob + is making the request, the To and From URIs and tags have been + swapped. + +F13 BYE Bob -> Alice + +BYE sip:alice@pc33.atlanta.com SIP/2.0 +Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 +Max-Forwards: 70 +From: Bob <sip:bob@biloxi.com>;tag=a6c85cf +To: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 231 BYE +Content-Length: 0 + + + + + + + + +Rosenberg, et. al. Standards Track [Page 218] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +F14 200 OK Alice -> Bob + +SIP/2.0 200 OK +Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 +From: Bob <sip:bob@biloxi.com>;tag=a6c85cf +To: Alice <sip:alice@atlanta.com>;tag=1928301774 +Call-ID: a84b4c76e66710 +CSeq: 231 BYE +Content-Length: 0 + + The SIP Call Flows document [40] contains further examples of SIP + messages. + +25 Augmented BNF for the SIP Protocol + + All of the mechanisms specified in this document are described in + both prose and an augmented Backus-Naur Form (BNF) defined in RFC + 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that + are used by this specification, and not repeated here. Implementers + need to be familiar with the notation and content of RFC 2234 in + order to understand this specification. Certain basic rules are in + uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle + brackets are used within definitions to clarify the use of rule + names. + + The use of square brackets is redundant syntactically. It is used as + a semantic hint that the specific parameter is optional to use. + +25.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. + + alphanum = ALPHA / DIGIT + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 219] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Several rules are incorporated from RFC 2396 [5] but are updated to + make them compliant with RFC 2234 [10]. These include: + + reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" + / "$" / "," + unreserved = alphanum / mark + mark = "-" / "_" / "." / "!" / "~" / "*" / "'" + / "(" / ")" + escaped = "%" HEXDIG HEXDIG + + 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. + This is intended to behave exactly as HTTP/1.1 as described in RFC + 2616 [8]. The SWS construct is used when linear white space is + optional, generally between tokens and separators. + + LWS = [*WSP CRLF] 1*WSP ; linear whitespace + SWS = [LWS] ; sep whitespace + + To separate the header name from the rest of value, a colon is used, + which, by the above rule, allows whitespace before, but no line + break, and whitespace after, including a linebreak. The HCOLON + defines this construct. + + HCOLON = *( SP / HTAB ) ":" SWS + + 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 charset (RFC + 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field + contents that are n t quoted strings, where leading and trailing LWS + is not meaningful. In this regard, SIP differs from HTTP, which uses + the ISO 8859-1 character set. + + TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) + TEXT-UTF8char = %x21-7E / UTF8-NONASCII + UTF8-NONASCII = %xC0-DF 1UTF8-CONT + / %xE0-EF 2UTF8-CONT + / %xF0-F7 3UTF8-CONT + / %xF8-Fb 4UTF8-CONT + / %xFC-FD 5UTF8-CONT + UTF8-CONT = %x80-BF + + + + + + +Rosenberg, et. al. Standards Track [Page 220] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + A CRLF is allowed in the definition of TEXT-UTF8-TRIM 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-TRIM value. + + Hexadecimal numeric characters are used in several protocol elements. + Some elements (authentication) force hex alphas to be lower case. + + LHEX = DIGIT / %x61-66 ;lowercase a-f + + Many SIP header field values consist of words separated by LWS or + special characters. Unless otherwise stated, tokens are case- + insensitive. These special characters MUST be in a quoted string to + be used within a parameter value. The word construct is used in + Call-ID to allow most separators to be used. + + token = 1*(alphanum / "-" / "." / "!" / "%" / "*" + / "_" / "+" / "`" / "'" / "~" ) + separators = "(" / ")" / "<" / ">" / "@" / + "," / ";" / ":" / "\" / DQUOTE / + "/" / "[" / "]" / "?" / "=" / + "{" / "}" / SP / HTAB + word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / + "_" / "+" / "`" / "'" / "~" / + "(" / ")" / "<" / ">" / + ":" / "\" / DQUOTE / + "/" / "[" / "]" / "?" / + "{" / "}" ) + + When tokens are used or separators are used between elements, + whitespace is often allowed before or after these characters: + + STAR = SWS "*" SWS ; asterisk + SLASH = SWS "/" SWS ; slash + EQUAL = SWS "=" SWS ; equal + LPAREN = SWS "(" SWS ; left parenthesis + RPAREN = SWS ")" SWS ; right parenthesis + RAQUOT = ">" SWS ; right angle quote + LAQUOT = SWS "<"; left angle quote + COMMA = SWS "," SWS ; comma + SEMI = SWS ";" SWS ; semicolon + COLON = SWS ":" SWS ; colon + LDQUOT = SWS DQUOTE; open double quotation mark + RDQUOT = DQUOTE SWS ; close double quotation mark + + + + + + + +Rosenberg, et. al. Standards Track [Page 221] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + 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 = LPAREN *(ctext / quoted-pair / comment) RPAREN + ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII + / LWS + + ctext includes all chars except left and right parens and backslash. + A string of text is parsed as a single word if it is quoted using + double-quote marks. In quoted strings, quotation marks (") and + backslashes (\) need to be escaped. + + quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE + qdtext = LWS / %x21 / %x23-5B / %x5D-7E + / UTF8-NONASCII + + The backslash character ("\") MAY be used as a single-character + quoting mechanism only within quoted-string and comment constructs. + Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this + mechanism to avoid conflict with line folding and header separation. + +quoted-pair = "\" (%x00-09 / %x0B-0C + / %x0E-7F) + +SIP-URI = "sip:" [ userinfo ] hostport + uri-parameters [ headers ] +SIPS-URI = "sips:" [ userinfo ] hostport + uri-parameters [ headers ] +userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" +user = 1*( unreserved / escaped / user-unreserved ) +user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" +password = *( unreserved / escaped / + "&" / "=" / "+" / "$" / "," ) +hostport = host [ ":" port ] +host = hostname / IPv4address / IPv6reference +hostname = *( domainlabel "." ) toplabel [ "." ] +domainlabel = alphanum + / alphanum *( alphanum / "-" ) alphanum +toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 222] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT +IPv6reference = "[" IPv6address "]" +IPv6address = hexpart [ ":" IPv4address ] +hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] +hexseq = hex4 *( ":" hex4) +hex4 = 1*4HEXDIG +port = 1*DIGIT + + The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, + however, that any characters allowed there that are not allowed in + the user part of the SIP URI MUST be escaped. + +uri-parameters = *( ";" uri-parameter) +uri-parameter = transport-param / user-param / method-param + / ttl-param / maddr-param / lr-param / other-param +transport-param = "transport=" + ( "udp" / "tcp" / "sctp" / "tls" + / other-transport) +other-transport = token +user-param = "user=" ( "phone" / "ip" / other-user) +other-user = token +method-param = "method=" Method +ttl-param = "ttl=" ttl +maddr-param = "maddr=" host +lr-param = "lr" +other-param = pname [ "=" pvalue ] +pname = 1*paramchar +pvalue = 1*paramchar +paramchar = param-unreserved / unreserved / escaped +param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" + +headers = "?" header *( "&" header ) +header = hname "=" hvalue +hname = 1*( hnv-unreserved / unreserved / escaped ) +hvalue = *( hnv-unreserved / unreserved / escaped ) +hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" + +SIP-message = Request / Response +Request = Request-Line + *( message-header ) + CRLF + [ message-body ] +Request-Line = Method SP Request-URI SP SIP-Version CRLF +Request-URI = SIP-URI / SIPS-URI / absoluteURI +absoluteURI = scheme ":" ( hier-part / opaque-part ) +hier-part = ( net-path / abs-path ) [ "?" query ] +net-path = "//" authority [ abs-path ] +abs-path = "/" path-segments + + + +Rosenberg, et. al. Standards Track [Page 223] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +opaque-part = uric-no-slash *uric +uric = reserved / unreserved / escaped +uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" + / "&" / "=" / "+" / "$" / "," +path-segments = segment *( "/" segment ) +segment = *pchar *( ";" param ) +param = *pchar +pchar = unreserved / escaped / + ":" / "@" / "&" / "=" / "+" / "$" / "," +scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) +authority = srvr / reg-name +srvr = [ [ userinfo "@" ] hostport ] +reg-name = 1*( unreserved / escaped / "$" / "," + / ";" / ":" / "@" / "&" / "=" / "+" ) +query = *uric +SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT + +message-header = (Accept + / Accept-Encoding + / Accept-Language + / Alert-Info + / Allow + / Authentication-Info + / Authorization + / Call-ID + / Call-Info + / Contact + / Content-Disposition + / Content-Encoding + / Content-Language + / Content-Length + / Content-Type + / CSeq + / Date + / Error-Info + / Expires + / From + / In-Reply-To + / Max-Forwards + / MIME-Version + / Min-Expires + / Organization + / Priority + / Proxy-Authenticate + / Proxy-Authorization + / Proxy-Require + / Record-Route + / Reply-To + + + +Rosenberg, et. al. Standards Track [Page 224] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + / Require + / Retry-After + / Route + / Server + / Subject + / Supported + / Timestamp + / To + / Unsupported + / User-Agent + / Via + / Warning + / WWW-Authenticate + / extension-header) CRLF + +INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps +ACKm = %x41.43.4B ; ACK in caps +OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps +BYEm = %x42.59.45 ; BYE in caps +CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps +REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps +Method = INVITEm / ACKm / OPTIONSm / BYEm + / CANCELm / REGISTERm + / extension-method +extension-method = token +Response = Status-Line + *( message-header ) + CRLF + [ message-body ] + +Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF +Status-Code = Informational + / Redirection + / Success + / Client-Error + / Server-Error + / Global-Failure + / extension-code +extension-code = 3DIGIT +Reason-Phrase = *(reserved / unreserved / escaped + / UTF8-NONASCII / UTF8-CONT / SP / HTAB) + +Informational = "100" ; Trying + / "180" ; Ringing + / "181" ; Call Is Being Forwarded + / "182" ; Queued + / "183" ; Session Progress + + + + +Rosenberg, et. al. Standards Track [Page 225] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Success = "200" ; OK + +Redirection = "300" ; Multiple Choices + / "301" ; Moved Permanently + / "302" ; Moved Temporarily + / "305" ; Use Proxy + / "380" ; Alternative Service + +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 + / "410" ; Gone + / "413" ; Request Entity Too Large + / "414" ; Request-URI Too Large + / "415" ; Unsupported Media Type + / "416" ; Unsupported URI Scheme + / "420" ; Bad Extension + / "421" ; Extension Required + / "423" ; Interval Too Brief + / "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 + / "487" ; Request Terminated + / "488" ; Not Acceptable Here + / "491" ; Request Pending + / "493" ; Undecipherable + +Server-Error = "500" ; Internal Server Error + / "501" ; Not Implemented + / "502" ; Bad Gateway + / "503" ; Service Unavailable + / "504" ; Server Time-out + / "505" ; SIP Version not supported + / "513" ; Message Too Large + + + + + + + +Rosenberg, et. al. Standards Track [Page 226] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Global-Failure = "600" ; Busy Everywhere + / "603" ; Decline + / "604" ; Does not exist anywhere + / "606" ; Not Acceptable + +Accept = "Accept" HCOLON + [ accept-range *(COMMA accept-range) ] +accept-range = media-range *(SEMI accept-param) +media-range = ( "*/*" + / ( m-type SLASH "*" ) + / ( m-type SLASH m-subtype ) + ) *( SEMI m-parameter ) +accept-param = ("q" EQUAL qvalue) / generic-param +qvalue = ( "0" [ "." 0*3DIGIT ] ) + / ( "1" [ "." 0*3("0") ] ) +generic-param = token [ EQUAL gen-value ] +gen-value = token / host / quoted-string + +Accept-Encoding = "Accept-Encoding" HCOLON + [ encoding *(COMMA encoding) ] +encoding = codings *(SEMI accept-param) +codings = content-coding / "*" +content-coding = token + +Accept-Language = "Accept-Language" HCOLON + [ language *(COMMA language) ] +language = language-range *(SEMI accept-param) +language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) + +Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) +alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) + +Allow = "Allow" HCOLON [Method *(COMMA Method)] + +Authorization = "Authorization" HCOLON credentials +credentials = ("Digest" LWS digest-response) + / other-response +digest-response = dig-resp *(COMMA dig-resp) +dig-resp = username / realm / nonce / digest-uri + / dresponse / algorithm / cnonce + / opaque / message-qop + / nonce-count / auth-param +username = "username" EQUAL username-value +username-value = quoted-string +digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT +digest-uri-value = rquest-uri ; Equal to request-uri as specified + by HTTP/1.1 +message-qop = "qop" EQUAL qop-value + + + +Rosenberg, et. al. Standards Track [Page 227] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +cnonce = "cnonce" EQUAL cnonce-value +cnonce-value = nonce-value +nonce-count = "nc" EQUAL nc-value +nc-value = 8LHEX +dresponse = "response" EQUAL request-digest +request-digest = LDQUOT 32LHEX RDQUOT +auth-param = auth-param-name EQUAL + ( token / quoted-string ) +auth-param-name = token +other-response = auth-scheme LWS auth-param + *(COMMA auth-param) +auth-scheme = token + +Authentication-Info = "Authentication-Info" HCOLON ainfo + *(COMMA ainfo) +ainfo = nextnonce / message-qop + / response-auth / cnonce + / nonce-count +nextnonce = "nextnonce" EQUAL nonce-value +response-auth = "rspauth" EQUAL response-digest +response-digest = LDQUOT *LHEX RDQUOT + +Call-ID = ( "Call-ID" / "i" ) HCOLON callid +callid = word [ "@" word ] + +Call-Info = "Call-Info" HCOLON info *(COMMA info) +info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) +info-param = ( "purpose" EQUAL ( "icon" / "info" + / "card" / token ) ) / generic-param + +Contact = ("Contact" / "m" ) HCOLON + ( STAR / (contact-param *(COMMA contact-param))) +contact-param = (name-addr / addr-spec) *(SEMI contact-params) +name-addr = [ display-name ] LAQUOT addr-spec RAQUOT +addr-spec = SIP-URI / SIPS-URI / absoluteURI +display-name = *(token LWS)/ quoted-string + +contact-params = c-p-q / c-p-expires + / contact-extension +c-p-q = "q" EQUAL qvalue +c-p-expires = "expires" EQUAL delta-seconds +contact-extension = generic-param +delta-seconds = 1*DIGIT + +Content-Disposition = "Content-Disposition" HCOLON + disp-type *( SEMI disp-param ) +disp-type = "render" / "session" / "icon" / "alert" + / disp-extension-token + + + +Rosenberg, et. al. Standards Track [Page 228] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +disp-param = handling-param / generic-param +handling-param = "handling" EQUAL + ( "optional" / "required" + / other-handling ) +other-handling = token +disp-extension-token = token + +Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON + content-coding *(COMMA content-coding) + +Content-Language = "Content-Language" HCOLON + language-tag *(COMMA language-tag) +language-tag = primary-tag *( "-" subtag ) +primary-tag = 1*8ALPHA +subtag = 1*8ALPHA + +Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT +Content-Type = ( "Content-Type" / "c" ) HCOLON media-type +media-type = m-type SLASH m-subtype *(SEMI m-parameter) +m-type = discrete-type / composite-type +discrete-type = "text" / "image" / "audio" / "video" + / "application" / extension-token +composite-type = "message" / "multipart" / extension-token +extension-token = ietf-token / x-token +ietf-token = token +x-token = "x-" token +m-subtype = extension-token / iana-token +iana-token = token +m-parameter = m-attribute EQUAL m-value +m-attribute = token +m-value = token / quoted-string + +CSeq = "CSeq" HCOLON 1*DIGIT LWS Method + +Date = "Date" HCOLON SIP-date +SIP-date = rfc1123-date +rfc1123-date = wkday "," SP date1 SP time SP "GMT" +date1 = 2DIGIT SP month SP 4DIGIT + ; day month year (e.g., 02 Jun 1982) +time = 2DIGIT ":" 2DIGIT ":" 2DIGIT + ; 00:00:00 - 23:59:59 +wkday = "Mon" / "Tue" / "Wed" + / "Thu" / "Fri" / "Sat" / "Sun" +month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + +Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) + + + +Rosenberg, et. al. Standards Track [Page 229] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) + +Expires = "Expires" HCOLON delta-seconds +From = ( "From" / "f" ) HCOLON from-spec +from-spec = ( name-addr / addr-spec ) + *( SEMI from-param ) +from-param = tag-param / generic-param +tag-param = "tag" EQUAL token + +In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) + +Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT + +MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT + +Min-Expires = "Min-Expires" HCOLON delta-seconds + +Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] + +Priority = "Priority" HCOLON priority-value +priority-value = "emergency" / "urgent" / "normal" + / "non-urgent" / other-priority +other-priority = token + +Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge +challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) + / other-challenge +other-challenge = auth-scheme LWS auth-param + *(COMMA auth-param) +digest-cln = realm / domain / nonce + / opaque / stale / algorithm + / qop-options / auth-param +realm = "realm" EQUAL realm-value +realm-value = quoted-string +domain = "domain" EQUAL LDQUOT URI + *( 1*SP URI ) RDQUOT +URI = absoluteURI / abs-path +nonce = "nonce" EQUAL nonce-value +nonce-value = quoted-string +opaque = "opaque" EQUAL quoted-string +stale = "stale" EQUAL ( "true" / "false" ) +algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" + / token ) +qop-options = "qop" EQUAL LDQUOT qop-value + *("," qop-value) RDQUOT +qop-value = "auth" / "auth-int" / token + +Proxy-Authorization = "Proxy-Authorization" HCOLON credentials + + + +Rosenberg, et. al. Standards Track [Page 230] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Proxy-Require = "Proxy-Require" HCOLON option-tag + *(COMMA option-tag) +option-tag = token + +Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) +rec-route = name-addr *( SEMI rr-param ) +rr-param = generic-param + +Reply-To = "Reply-To" HCOLON rplyto-spec +rplyto-spec = ( name-addr / addr-spec ) + *( SEMI rplyto-param ) +rplyto-param = generic-param +Require = "Require" HCOLON option-tag *(COMMA option-tag) + +Retry-After = "Retry-After" HCOLON delta-seconds + [ comment ] *( SEMI retry-param ) + +retry-param = ("duration" EQUAL delta-seconds) + / generic-param + +Route = "Route" HCOLON route-param *(COMMA route-param) +route-param = name-addr *( SEMI rr-param ) + +Server = "Server" HCOLON server-val *(LWS server-val) +server-val = product / comment +product = token [SLASH product-version] +product-version = token + +Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] + +Supported = ( "Supported" / "k" ) HCOLON + [option-tag *(COMMA option-tag)] + +Timestamp = "Timestamp" HCOLON 1*(DIGIT) + [ "." *(DIGIT) ] [ LWS delay ] +delay = *(DIGIT) [ "." *(DIGIT) ] + +To = ( "To" / "t" ) HCOLON ( name-addr + / addr-spec ) *( SEMI to-param ) +to-param = tag-param / generic-param + +Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) +User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) + + + + + + + + +Rosenberg, et. al. Standards Track [Page 231] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) +via-parm = sent-protocol LWS sent-by *( SEMI via-params ) +via-params = via-ttl / via-maddr + / via-received / via-branch + / via-extension +via-ttl = "ttl" EQUAL ttl +via-maddr = "maddr" EQUAL host +via-received = "received" EQUAL (IPv4address / IPv6address) +via-branch = "branch" EQUAL token +via-extension = generic-param +sent-protocol = protocol-name SLASH protocol-version + SLASH transport +protocol-name = "SIP" / token +protocol-version = token +transport = "UDP" / "TCP" / "TLS" / "SCTP" + / other-transport +sent-by = host [ COLON port ] +ttl = 1*3DIGIT ; 0 to 255 + +Warning = "Warning" HCOLON warning-value *(COMMA warning-value) +warning-value = warn-code SP warn-agent SP warn-text +warn-code = 3DIGIT +warn-agent = hostport / pseudonym + ; the name or pseudonym of the server adding + ; the Warning header, for use in debugging +warn-text = quoted-string +pseudonym = token + +WWW-Authenticate = "WWW-Authenticate" HCOLON challenge + +extension-header = header-name HCOLON header-value +header-name = token +header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) +message-body = *OCTET + +26 Security Considerations: Threat Model and Security Usage + Recommendations + + SIP is not an easy protocol to secure. Its use of intermediaries, + its multi-faceted trust relationships, its expected usage between + elements with no trust at all, and its user-to-user operation make + security far from trivial. Security solutions are needed that are + deployable today, without extensive coordination, in a wide variety + of environments and usages. In order to meet these diverse needs, + several distinct mechanisms applicable to different aspects and + usages of SIP will be required. + + + + + +Rosenberg, et. al. Standards Track [Page 232] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Note that the security of SIP signaling itself has no bearing on the + security of protocols used in concert with SIP such as RTP, or with + the security implications of any specific bodies SIP might carry + (although MIME security plays a substantial role in securing SIP). + Any media associated with a session can be encrypted end-to-end + independently of any associated SIP signaling. Media encryption is + outside the scope of this document. + + The considerations that follow first examine a set of classic threat + models that broadly identify the security needs of SIP. The set of + security services required to address these threats is then detailed, + followed by an explanation of several security mechanisms that can be + used to provide these services. Next, the requirements for + implementers of SIP are enumerated, along with exemplary deployments + in which these security mechanisms could be used to improve the + security of SIP. Some notes on privacy conclude this section. + +26.1 Attacks and Threat Models + + This section details some threats that should be common to most + deployments of SIP. These threats have been chosen specifically to + illustrate each of the security services that SIP requires. + + The following examples by no means provide an exhaustive list of the + threats against SIP; rather, these are "classic" threats that + demonstrate the need for particular security services that can + potentially prevent whole categories of threats. + + These attacks assume an environment in which attackers can + potentially read any packet on the network - it is anticipated that + SIP will frequently be used on the public Internet. Attackers on the + network may be able to modify packets (perhaps at some compromised + intermediary). Attackers may wish to steal services, eavesdrop on + communications, or disrupt sessions. + +26.1.1 Registration Hijacking + + The SIP registration mechanism allows a user agent to identify itself + to a registrar as a device at which a user (designated by an address + of record) is located. A registrar assesses the identity asserted in + the From header field of a REGISTER message to determine whether this + request can modify the contact addresses associated with the + address-of-record in the To header field. While these two fields are + frequently the same, there are many valid deployments in which a + third-party may register contacts on a user's behalf. + + + + + + +Rosenberg, et. al. Standards Track [Page 233] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The From header field of a SIP request, however, can be modified + arbitrarily by the owner of a UA, and this opens the door to + malicious registrations. An attacker that successfully impersonates + a party authorized to change contacts associated with an address-of- + record could, for example, de-register all existing contacts for a + URI and then register their own device as the appropriate contact + address, thereby directing all requests for the affected user to the + attacker's device. + + This threat belongs to a family of threats that rely on the absence + of cryptographic assurance of a request's originator. Any SIP UAS + that represents a valuable service (a gateway that interworks SIP + requests with traditional telephone calls, for example) might want to + control access to its resources by authenticating requests that it + receives. Even end-user UAs, for example SIP phones, have an + interest in ascertaining the identities of originators of requests. + + This threat demonstrates the need for security services that enable + SIP entities to authenticate the originators of requests. + +26.1.2 Impersonating a Server + + The domain to which a request is destined is generally specified in + the Request-URI. UAs commonly contact a server in this domain + directly in order to deliver a request. However, there is always a + possibility that an attacker could impersonate the remote server, and + that the UA's request could be intercepted by some other party. + + For example, consider a case in which a redirect server at one + domain, chicago.com, impersonates a redirect server at another + domain, biloxi.com. A user agent sends a request to biloxi.com, but + the redirect server at chicago.com answers with a forged response + that has appropriate SIP header fields for a response from + biloxi.com. The forged contact addresses in the redirection response + could direct the originating UA to inappropriate or insecure + resources, or simply prevent requests for biloxi.com from succeeding. + + This family of threats has a vast membership, many of which are + critical. As a converse to the registration hijacking threat, + consider the case in which a registration sent to biloxi.com is + intercepted by chicago.com, which replies to the intercepted + registration with a forged 301 (Moved Permanently) response. This + response might seem to come from biloxi.com yet designate chicago.com + as the appropriate registrar. All future REGISTER requests from the + originating UA would then go to chicago.com. + + Prevention of this threat requires a means by which UAs can + authenticate the servers to whom they send requests. + + + +Rosenberg, et. al. Standards Track [Page 234] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +26.1.3 Tampering with Message Bodies + + As a matter of course, SIP UAs route requests through trusted proxy + servers. Regardless of how that trust is established (authentication + of proxies is discussed elsewhere in this section), a UA may trust a + proxy server to route a request, but not to inspect or possibly + modify the bodies contained in that request. + + Consider a UA that is using SIP message bodies to communicate session + encryption keys for a media session. Although it trusts the proxy + server of the domain it is contacting to deliver signaling properly, + it may not want the administrators of that domain to be capable of + decrypting any subsequent media session. Worse yet, if the proxy + server were actively malicious, it could modify the session key, + either acting as a man-in-the-middle, or perhaps changing the + security characteristics requested by the originating UA. + + This family of threats applies not only to session keys, but to most + conceivable forms of content carried end-to-end in SIP. These might + include MIME bodies that should be rendered to the user, SDP, or + encapsulated telephony signals, among others. Attackers might + attempt to modify SDP bodies, for example, in order to point RTP + media streams to a wiretapping device in order to eavesdrop on + subsequent voice communications. + + Also note that some header fields in SIP are meaningful end-to-end, + for example, Subject. UAs might be protective of these header fields + as well as bodies (a malicious intermediary changing the Subject + header field might make an important request appear to be spam, for + example). However, since many header fields are legitimately + inspected or altered by proxy servers as a request is routed, not all + header fields should be secured end-to-end. + + For these reasons, the UA might want to secure SIP message bodies, + and in some limited cases header fields, end-to-end. The security + services required for bodies include confidentiality, integrity, and + authentication. These end-to-end services should be independent of + the means used to secure interactions with intermediaries such as + proxy servers. + +26.1.4 Tearing Down Sessions + + Once a dialog has been established by initial messaging, subsequent + requests can be sent that modify the state of the dialog and/or + session. It is critical that principals in a session can be certain + that such requests are not forged by attackers. + + + + + +Rosenberg, et. al. Standards Track [Page 235] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Consider a case in which a third-party attacker captures some initial + messages in a dialog shared by two parties in order to learn the + parameters of the session (To tag, From tag, and so forth) and then + inserts a BYE request into the session. The attacker could opt to + forge the request such that it seemed to come from either + participant. Once the BYE is received by its target, the session + will be torn down prematurely. + + Similar mid-session threats include the transmission of forged re- + INVITEs that alter the session (possibly to reduce session security + or redirect media streams as part of a wiretapping attack). + + The most effective countermeasure to this threat is the + authentication of the sender of the BYE. In this instance, the + recipient needs only know that the BYE came from the same party with + whom the corresponding dialog was established (as opposed to + ascertaining the absolute identity of the sender). Also, if the + attacker is unable to learn the parameters of the session due to + confidentiality, it would not be possible to forge the BYE. However, + some intermediaries (like proxy servers) will need to inspect those + parameters as the session is established. + +26.1.5 Denial of Service and Amplification + + Denial-of-service attacks focus on rendering a particular network + element unavailable, usually by directing an excessive amount of + network traffic at its interfaces. A distributed denial-of-service + attack allows one network user to cause multiple network hosts to + flood a target host with a large amount of network traffic. + + In many architectures, SIP proxy servers face the public Internet in + order to accept requests from worldwide IP endpoints. SIP creates a + number of potential opportunities for distributed denial-of-service + attacks that must be recognized and addressed by the implementers and + operators of SIP systems. + + Attackers can create bogus requests that contain a falsified source + IP address and a corresponding Via header field that identify a + targeted host as the originator of the request and then send this + request to a large number of SIP network elements, thereby using + hapless SIP UAs or proxies to generate denial-of-service traffic + aimed at the target. + + Similarly, attackers might use falsified Route header field values in + a request that identify the target host and then send such messages + to forking proxies that will amplify messaging sent to the target. + + + + + +Rosenberg, et. al. Standards Track [Page 236] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Record-Route could be used to similar effect when the attacker is + certain that the SIP dialog initiated by the request will result in + numerous transactions originating in the backwards direction. + + A number of denial-of-service attacks open up if REGISTER requests + are not properly authenticated and authorized by registrars. + Attackers could de-register some or all users in an administrative + domain, thereby preventing these users from being invited to new + sessions. An attacker could also register a large number of contacts + designating the same host for a given address-of-record in order to + use the registrar and any associated proxy servers as amplifiers in a + denial-of-service attack. Attackers might also attempt to deplete + available memory and disk resources of a registrar by registering + huge numbers of bindings. + + The use of multicast to transmit SIP requests can greatly increase + the potential for denial-of-service attacks. + + These problems demonstrate a general need to define architectures + that minimize the risks of denial-of-service, and the need to be + mindful in recommendations for security mechanisms of this class of + attacks. + +26.2 Security Mechanisms + + From the threats described above, we gather that the fundamental + security services required for the SIP protocol are: preserving the + confidentiality and integrity of messaging, preventing replay attacks + or message spoofing, providing for the authentication and privacy of + the participants in a session, and preventing denial-of-service + attacks. Bodies within SIP messages separately require the security + services of confidentiality, integrity, and authentication. + + Rather than defining new security mechanisms specific to SIP, SIP + reuses wherever possible existing security models derived from the + HTTP and SMTP space. + + Full encryption of messages provides the best means to preserve the + confidentiality of signaling - it can also guarantee that messages + are not modified by any malicious intermediaries. However, SIP + requests and responses cannot be naively encrypted end-to-end in + their entirety because message fields such as the Request-URI, Route, + and Via need to be visible to proxies in most network architectures + so that SIP requests are routed correctly. Note that proxy servers + need to modify some features of messages as well (such as adding Via + header field values) in order for SIP to function. Proxy servers + must therefore be trusted, to some degree, by SIP UAs. To this + purpose, low-layer security mechanisms for SIP are recommended, which + + + +Rosenberg, et. al. Standards Track [Page 237] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + encrypt the entire SIP requests or responses on the wire on a hop- + by-hop basis, and that allow endpoints to verify the identity of + proxy servers to whom they send requests. + + SIP entities also have a need to identify one another in a secure + fashion. When a SIP endpoint asserts the identity of its user to a + peer UA or to a proxy server, that identity should in some way be + verifiable. A cryptographic authentication mechanism is provided in + SIP to address this requirement. + + An independent security mechanism for SIP message bodies supplies an + alternative means of end-to-end mutual authentication, as well as + providing a limit on the degree to which user agents must trust + intermediaries. + +26.2.1 Transport and Network Layer Security + + Transport or network layer security encrypts signaling traffic, + guaranteeing message confidentiality and integrity. + + Oftentimes, certificates are used in the establishment of lower-layer + security, and these certificates can also be used to provide a means + of authentication in many architectures. + + Two popular alternatives for providing security at the transport and + network layer are, respectively, TLS [25] and IPSec [26]. + + IPSec is a set of network-layer protocol tools that collectively can + be used as a secure replacement for traditional IP (Internet + Protocol). IPSec is most commonly used in architectures in which a + set of hosts or administrative domains have an existing trust + relationship with one another. IPSec is usually implemented at the + operating system level in a host, or on a security gateway that + provides confidentiality and integrity for all traffic it receives + from a particular interface (as in a VPN architecture). IPSec can + also be used on a hop-by-hop basis. + + In many architectures IPSec does not require integration with SIP + applications; IPSec is perhaps best suited to deployments in which + adding security directly to SIP hosts would be arduous. UAs that + have a pre-shared keying relationship with their first-hop proxy + server are also good candidates to use IPSec. Any deployment of + IPSec for SIP would require an IPSec profile describing the protocol + tools that would be required to secure SIP. No such profile is given + in this document. + + + + + + +Rosenberg, et. al. Standards Track [Page 238] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + TLS provides transport-layer security over connection-oriented + protocols (for the purposes of this document, TCP); "tls" (signifying + TLS over TCP) can be specified as the desired transport protocol + within a Via header field value or a SIP-URI. TLS is most suited to + architectures in which hop-by-hop security is required between hosts + with no pre-existing trust association. For example, Alice trusts + her local proxy server, which after a certificate exchange decides to + trust Bob's local proxy server, which Bob trusts, hence Bob and Alice + can communicate securely. + + TLS must be tightly coupled with a SIP application. Note that + transport mechanisms are specified on a hop-by-hop basis in SIP, thus + a UA that sends requests over TLS to a proxy server has no assurance + that TLS will be used end-to-end. + + The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at + a minimum by implementers when TLS is used in a SIP application. For + purposes of backwards compatibility, proxy servers, redirect servers, + and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. + Implementers MAY also support any other ciphersuite. + +26.2.2 SIPS URI Scheme + + The SIPS URI scheme adheres to the syntax of the SIP URI (described + in 19), although the scheme string is "sips" rather than "sip". The + semantics of SIPS are very different from the SIP URI, however. SIPS + allows resources to specify that they should be reached securely. + + A SIPS URI can be used as an address-of-record for a particular user + - the URI by which the user is canonically known (on their business + cards, in the From header field of their requests, in the To header + field of REGISTER requests). When used as the Request-URI of a + request, the SIPS scheme signifies that each hop over which the + request is forwarded, until the request reaches the SIP entity + responsible for the domain portion of the Request-URI, must be + secured with TLS; once it reaches the domain in question it is + handled in accordance with local security and routing policy, quite + possibly using TLS for any last hop to a UAS. When used by the + originator of a request (as would be the case if they employed a SIPS + URI as the address-of-record of the target), SIPS dictates that the + entire request path to the target domain be so secured. + + The SIPS scheme is applicable to many of the other ways in which SIP + URIs are used in SIP today in addition to the Request-URI, including + in addresses-of-record, contact addresses (the contents of Contact + headers, including those of REGISTER methods), and Route headers. In + each instance, the SIPS URI scheme allows these existing fields to + + + + +Rosenberg, et. al. Standards Track [Page 239] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + designate secure resources. The manner in which a SIPS URI is + dereferenced in any of these contexts has its own security properties + which are detailed in [4]. + + The use of SIPS in particular entails that mutual TLS authentication + SHOULD be employed, as SHOULD the ciphersuite + TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the + authentication process SHOULD be validated with root certificates + held by the client; failure to validate a certificate SHOULD result + in the failure of the request. + + Note that in the SIPS URI scheme, transport is independent of TLS, + and thus "sips:alice@atlanta.com;transport=tcp" and + "sips:alice@atlanta.com;transport=sctp" are both valid (although + note that UDP is not a valid transport for SIPS). The use of + "transport=tls" has consequently been deprecated, partly because + it was specific to a single hop of the request. This is a change + since RFC 2543. + + Users that distribute a SIPS URI as an address-of-record may elect to + operate devices that refuse requests over insecure transports. + +26.2.3 HTTP Authentication + + SIP provides a challenge capability, based on HTTP authentication, + that relies on the 401 and 407 response codes as well as header + fields for carrying challenges and credentials. Without significant + modification, the reuse of the HTTP Digest authentication scheme in + SIP allows for replay protection and one-way authentication. + + The usage of Digest authentication in SIP is detailed in Section 22. + +26.2.4 S/MIME + + As is discussed above, encrypting entire SIP messages end-to-end for + the purpose of confidentiality is not appropriate because network + intermediaries (like proxy servers) need to view certain header + fields in order to route messages correctly, and if these + intermediaries are excluded from security associations, then SIP + messages will essentially be non-routable. + + However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, + securing these bodies end-to-end without affecting message headers. + S/MIME can provide end-to-end confidentiality and integrity for + message bodies, as well as mutual authentication. It is also + possible to use S/MIME to provide a form of integrity and + confidentiality for SIP header fields through SIP message tunneling. + + + + +Rosenberg, et. al. Standards Track [Page 240] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The usage of S/MIME in SIP is detailed in Section 23. + +26.3 Implementing Security Mechanisms + +26.3.1 Requirements for Implementers of SIP + + Proxy servers, redirect servers, and registrars MUST implement TLS, + and MUST support both mutual and one-way authentication. It is + strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also + be capable of acting as a TLS server. Proxy servers, redirect + servers, and registrars SHOULD possess a site certificate whose + subject corresponds to their canonical hostname. UAs MAY have + certificates of their own for mutual authentication with TLS, but no + provisions are set forth in this document for their use. All SIP + elements that support TLS MUST have a mechanism for validating + certificates received during TLS negotiation; this entails possession + of one or more root certificates issued by certificate authorities + (preferably well-known distributors of site certificates comparable + to those that issue root certificates for web browsers). + + All SIP elements that support TLS MUST also support the SIPS URI + scheme. + + Proxy servers, redirect servers, registrars, and UAs MAY also + implement IPSec or other lower-layer security protocols. + + When a UA attempts to contact a proxy server, redirect server, or + registrar, the UAC SHOULD initiate a TLS connection over which it + will send SIP messages. In some architectures, UASs MAY receive + requests over such TLS connections as well. + + Proxy servers, redirect servers, registrars, and UAs MUST implement + Digest Authorization, encompassing all of the aspects required in 22. + Proxy servers, redirect servers, and registrars SHOULD be configured + with at least one Digest realm, and at least one "realm" string + supported by a given server SHOULD correspond to the server's + hostname or domainname. + + UAs MAY support the signing and encrypting of MIME bodies, and + transference of credentials with S/MIME as described in Section 23. + If a UA holds one or more root certificates of certificate + authorities in order to validate certificates for TLS or IPSec, it + SHOULD be capable of reusing these to verify S/MIME certificates, as + appropriate. A UA MAY hold root certificates specifically for + validating S/MIME certificates. + + + + + + +Rosenberg, et. al. Standards Track [Page 241] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Note that is it anticipated that future security extensions may + upgrade the normative strength associated with S/MIME as S/MIME + implementations appear and the problem space becomes better + understood. + +26.3.2 Security Solutions + + The operation of these security mechanisms in concert can follow the + existing web and email security models to some degree. At a high + level, UAs authenticate themselves to servers (proxy servers, + redirect servers, and registrars) with a Digest username and + password; servers authenticate themselves to UAs one hop away, or to + another server one hop away (and vice versa), with a site certificate + delivered by TLS. + + On a peer-to-peer level, UAs trust the network to authenticate one + another ordinarily; however, S/MIME can also be used to provide + direct authentication when the network does not, or if the network + itself is not trusted. + + The following is an illustrative example in which these security + mechanisms are used by various UAs and servers to prevent the sorts + of threats described in Section 26.1. While implementers and network + administrators MAY follow the normative guidelines given in the + remainder of this section, these are provided only as example + implementations. + +26.3.2.1 Registration + + When a UA comes online and registers with its local administrative + domain, it SHOULD establish a TLS connection with its registrar + (Section 10 describes how the UA reaches its registrar). The + registrar SHOULD offer a certificate to the UA, and the site + identified by the certificate MUST correspond with the domain in + which the UA intends to register; for example, if the UA intends to + register the address-of-record 'alice@atlanta.com', the site + certificate must identify a host within the atlanta.com domain (such + as sip.atlanta.com). When it receives the TLS Certificate message, + the UA SHOULD verify the certificate and inspect the site identified + by the certificate. If the certificate is invalid, revoked, or if it + does not identify the appropriate party, the UA MUST NOT send the + REGISTER message and otherwise proceed with the registration. + + When a valid certificate has been provided by the registrar, the + UA knows that the registrar is not an attacker who might redirect + the UA, steal passwords, or attempt any similar attacks. + + + + + +Rosenberg, et. al. Standards Track [Page 242] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The UA then creates a REGISTER request that SHOULD be addressed to a + Request-URI corresponding to the site certificate received from the + registrar. When the UA sends the REGISTER request over the existing + TLS connection, the registrar SHOULD challenge the request with a 401 + (Proxy Authentication Required) response. The "realm" parameter + within the Proxy-Authenticate header field of the response SHOULD + correspond to the domain previously given by the site certificate. + When the UAC receives the challenge, it SHOULD either prompt the user + for credentials or take an appropriate credential from a keyring + corresponding to the "realm" parameter in the challenge. The + username of this credential SHOULD correspond with the "userinfo" + portion of the URI in the To header field of the REGISTER request. + Once the Digest credentials have been inserted into an appropriate + Proxy-Authorization header field, the REGISTER should be resubmitted + to the registrar. + + Since the registrar requires the user agent to authenticate + itself, it would be difficult for an attacker to forge REGISTER + requests for the user's address-of-record. Also note that since + the REGISTER is sent over a confidential TLS connection, attackers + will not be able to intercept the REGISTER to record credentials + for any possible replay attack. + + Once the registration has been accepted by the registrar, the UA + SHOULD leave this TLS connection open provided that the registrar + also acts as the proxy server to which requests are sent for users in + this administrative domain. The existing TLS connection will be + reused to deliver incoming requests to the UA that has just completed + registration. + + Because the UA has already authenticated the server on the other + side of the TLS connection, all requests that come over this + connection are known to have passed through the proxy server - + attackers cannot create spoofed requests that appear to have been + sent through that proxy server. + +26.3.2.2 Interdomain Requests + + Now let's say that Alice's UA would like to initiate a session with a + user in a remote administrative domain, namely "bob@biloxi.com". We + will also say that the local administrative domain (atlanta.com) has + a local outbound proxy. + + The proxy server that handles inbound requests for an administrative + domain MAY also act as a local outbound proxy; for simplicity's sake + we'll assume this to be the case for atlanta.com (otherwise the user + agent would initiate a new TLS connection to a separate server at + this point). Assuming that the client has completed the registration + + + +Rosenberg, et. al. Standards Track [Page 243] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + process described in the preceding section, it SHOULD reuse the TLS + connection to the local proxy server when it sends an INVITE request + to another user. The UA SHOULD reuse cached credentials in the + INVITE to avoid prompting the user unnecessarily. + + When the local outbound proxy server has validated the credentials + presented by the UA in the INVITE, it SHOULD inspect the Request-URI + to determine how the message should be routed (see [4]). If the + "domainname" portion of the Request-URI had corresponded to the local + domain (atlanta.com) rather than biloxi.com, then the proxy server + would have consulted its location service to determine how best to + reach the requested user. + + Had "alice@atlanta.com" been attempting to contact, say, + "alex@atlanta.com", the local proxy would have proxied to the + request to the TLS connection Alex had established with the + registrar when he registered. Since Alex would receive this + request over his authenticated channel, he would be assured that + Alice's request had been authorized by the proxy server of the + local administrative domain. + + However, in this instance the Request-URI designates a remote domain. + The local outbound proxy server at atlanta.com SHOULD therefore + establish a TLS connection with the remote proxy server at + biloxi.com. Since both of the participants in this TLS connection + are servers that possess site certificates, mutual TLS authentication + SHOULD occur. Each side of the connection SHOULD verify and inspect + the certificate of the other, noting the domain name that appears in + the certificate for comparison with the header fields of SIP + messages. The atlanta.com proxy server, for example, SHOULD verify + at this stage that the certificate received from the remote side + corresponds with the biloxi.com domain. Once it has done so, and TLS + negotiation has completed, resulting in a secure channel between the + two proxies, the atlanta.com proxy can forward the INVITE request to + biloxi.com. + + The proxy server at biloxi.com SHOULD inspect the certificate of the + proxy server at atlanta.com in turn and compare the domain asserted + by the certificate with the "domainname" portion of the From header + field in the INVITE request. The biloxi proxy MAY have a strict + security policy that requires it to reject requests that do not match + the administrative domain from which they have been proxied. + + Such security policies could be instituted to prevent the SIP + equivalent of SMTP 'open relays' that are frequently exploited to + generate spam. + + + + + +Rosenberg, et. al. Standards Track [Page 244] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + This policy, however, only guarantees that the request came from the + domain it ascribes to itself; it does not allow biloxi.com to + ascertain how atlanta.com authenticated Alice. Only if biloxi.com + has some other way of knowing atlanta.com's authentication policies + could it possibly ascertain how Alice proved her identity. + biloxi.com might then institute an even stricter policy that forbids + requests that come from domains that are not known administratively + to share a common authentication policy with biloxi.com. + + Once the INVITE has been approved by the biloxi proxy, the proxy + server SHOULD identify the existing TLS channel, if any, associated + with the user targeted by this request (in this case + "bob@biloxi.com"). The INVITE should be proxied through this channel + to Bob. Since the request is received over a TLS connection that had + previously been authenticated as the biloxi proxy, Bob knows that the + From header field was not tampered with and that atlanta.com has + validated Alice, although not necessarily whether or not to trust + Alice's identity. + + Before they forward the request, both proxy servers SHOULD add a + Record-Route header field to the request so that all future requests + in this dialog will pass through the proxy servers. The proxy + servers can thereby continue to provide security services for the + lifetime of this dialog. If the proxy servers do not add themselves + to the Record-Route, future messages will pass directly end-to-end + between Alice and Bob without any security services (unless the two + parties agree on some independent end-to-end security such as + S/MIME). In this respect the SIP trapezoid model can provide a nice + structure where conventions of agreement between the site proxies can + provide a reasonably secure channel between Alice and Bob. + + An attacker preying on this architecture would, for example, be + unable to forge a BYE request and insert it into the signaling + stream between Bob and Alice because the attacker has no way of + ascertaining the parameters of the session and also because the + integrity mechanism transitively protects the traffic between + Alice and Bob. + +26.3.2.3 Peer-to-Peer Requests + + Alternatively, consider a UA asserting the identity + "carol@chicago.com" that has no local outbound proxy. When Carol + wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate + a TLS connection with the biloxi proxy directly (using the mechanism + described in [4] to determine how to best to reach the given + Request-URI). When her UA receives a certificate from the biloxi + proxy, it SHOULD be verified normally before she passes her INVITE + across the TLS connection. However, Carol has no means of proving + + + +Rosenberg, et. al. Standards Track [Page 245] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + her identity to the biloxi proxy, but she does have a CMS-detached + signature over a "message/sip" body in the INVITE. It is unlikely in + this instance that Carol would have any credentials in the biloxi.com + realm, since she has no formal association with biloxi.com. The + biloxi proxy MAY also have a strict policy that precludes it from + even bothering to challenge requests that do not have biloxi.com in + the "domainname" portion of the From header field - it treats these + users as unauthenticated. + + The biloxi proxy has a policy for Bob that all non-authenticated + requests should be redirected to the appropriate contact address + registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. + Carol receives the redirection response over the TLS connection she + established with the biloxi proxy, so she trusts the veracity of the + contact address. + + Carol SHOULD then establish a TCP connection with the designated + address and send a new INVITE with a Request-URI containing the + received contact address (recomputing the signature in the body as + the request is readied). Bob receives this INVITE on an insecure + interface, but his UA inspects and, in this instance, recognizes the + From header field of the request and subsequently matches a locally + cached certificate with the one presented in the signature of the + body of the INVITE. He replies in similar fashion, authenticating + himself to Carol, and a secure dialog begins. + + Sometimes firewalls or NATs in an administrative domain could + preclude the establishment of a direct TCP connection to a UA. In + these cases, proxy servers could also potentially relay requests + to UAs in a way that has no trust implications (for example, + forgoing an existing TLS connection and forwarding the request + over cleartext TCP) as local policy dictates. + +26.3.2.4 DoS Protection + + In order to minimize the risk of a denial-of-service attack against + architectures using these security solutions, implementers should + take note of the following guidelines. + + When the host on which a SIP proxy server is operating is routable + from the public Internet, it SHOULD be deployed in an administrative + domain with defensive operational policies (blocking source-routed + traffic, preferably filtering ping traffic). Both TLS and IPSec can + also make use of bastion hosts at the edges of administrative domains + that participate in the security associations to aggregate secure + tunnels and sockets. These bastion hosts can also take the brunt of + denial-of-service attacks, ensuring that SIP hosts within the + administrative domain are not encumbered with superfluous messaging. + + + +Rosenberg, et. al. Standards Track [Page 246] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + No matter what security solutions are deployed, floods of messages + directed at proxy servers can lock up proxy server resources and + prevent desirable traffic from reaching its destination. There is a + computational expense associated with processing a SIP transaction at + a proxy server, and that expense is greater for stateful proxy + servers than it is for stateless proxy servers. Therefore, stateful + proxies are more susceptible to flooding than stateless proxy + servers. + + UAs and proxy servers SHOULD challenge questionable requests with + only a single 401 (Unauthorized) or 407 (Proxy Authentication + Required), forgoing the normal response retransmission algorithm, and + thus behaving statelessly towards unauthenticated requests. + + Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication + Required) status response amplifies the problem of an attacker + using a falsified header field value (such as Via) to direct + traffic to a third party. + + In summary, the mutual authentication of proxy servers through + mechanisms such as TLS significantly reduces the potential for rogue + intermediaries to introduce falsified requests or responses that can + deny service. This commensurately makes it harder for attackers to + make innocent SIP nodes into agents of amplification. + +26.4 Limitations + + Although these security mechanisms, when applied in a judicious + manner, can thwart many threats, there are limitations in the scope + of the mechanisms that must be understood by implementers and network + operators. + +26.4.1 HTTP Digest + + One of the primary limitations of using HTTP Digest in SIP is that + the integrity mechanisms in Digest do not work very well for SIP. + Specifically, they offer protection of the Request-URI and the method + of a message, but not for any of the header fields that UAs would + most likely wish to secure. + + The existing replay protection mechanisms described in RFC 2617 also + have some limitations for SIP. The next-nonce mechanism, for + example, does not support pipelined requests. The nonce-count + mechanism should be used for replay protection. + + Another limitation of HTTP Digest is the scope of realms. Digest is + valuable when a user wants to authenticate themselves to a resource + with which they have a pre-existing association, like a service + + + +Rosenberg, et. al. Standards Track [Page 247] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + provider of which the user is a customer (which is quite a common + scenario and thus Digest provides an extremely useful function). By + way of contrast, the scope of TLS is interdomain or multirealm, since + certificates are often globally verifiable, so that the UA can + authenticate the server with no pre-existing association. + +26.4.2 S/MIME + + The largest outstanding defect with the S/MIME mechanism is the lack + of a prevalent public key infrastructure for end users. If self- + signed certificates (or certificates that cannot be verified by one + of the participants in a dialog) are used, the SIP-based key exchange + mechanism described in Section 23.2 is susceptible to a man-in-the- + middle attack with which an attacker can potentially inspect and + modify S/MIME bodies. The attacker needs to intercept the first + exchange of keys between the two parties in a dialog, remove the + existing CMS-detached signatures from the request and response, and + insert a different CMS-detached signature containing a certificate + supplied by the attacker (but which seems to be a certificate for the + proper address-of-record). Each party will think they have exchanged + keys with the other, when in fact each has the public key of the + attacker. + + It is important to note that the attacker can only leverage this + vulnerability on the first exchange of keys between two parties - on + subsequent occasions, the alteration of the key would be noticeable + to the UAs. It would also be difficult for the attacker to remain in + the path of all future dialogs between the two parties over time (as + potentially days, weeks, or years pass). + + SSH is susceptible to the same man-in-the-middle attack on the first + exchange of keys; however, it is widely acknowledged that while SSH + is not perfect, it does improve the security of connections. The use + of key fingerprints could provide some assistance to SIP, just as it + does for SSH. For example, if two parties use SIP to establish a + voice communications session, each could read off the fingerprint of + the key they received from the other, which could be compared against + the original. It would certainly be more difficult for the man-in- + the-middle to emulate the voices of the participants than their + signaling (a practice that was used with the Clipper chip-based + secure telephone). + + The S/MIME mechanism allows UAs to send encrypted requests without + preamble if they possess a certificate for the destination address- + of-record on their keyring. However, it is possible that any + particular device registered for an address-of-record will not hold + the certificate that has been previously employed by the device's + current user, and that it will therefore be unable to process an + + + +Rosenberg, et. al. Standards Track [Page 248] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + encrypted request properly, which could lead to some avoidable error + signaling. This is especially likely when an encrypted request is + forked. + + The keys associated with S/MIME are most useful when associated with + a particular user (an address-of-record) rather than a device (a UA). + When users move between devices, it may be difficult to transport + private keys securely between UAs; how such keys might be acquired by + a device is outside the scope of this document. + + Another, more prosaic difficulty with the S/MIME mechanism is that it + can result in very large messages, especially when the SIP tunneling + mechanism described in Section 23.4 is used. For that reason, it is + RECOMMENDED that TCP should be used as a transport protocol when + S/MIME tunneling is employed. + +26.4.3 TLS + + The most commonly voiced concern about TLS is that it cannot run over + UDP; TLS requires a connection-oriented underlying transport + protocol, which for the purposes of this document means TCP. + + It may also be arduous for a local outbound proxy server and/or + registrar to maintain many simultaneous long-lived TLS connections + with numerous UAs. This introduces some valid scalability concerns, + especially for intensive ciphersuites. Maintaining redundancy of + long-lived TLS connections, especially when a UA is solely + responsible for their establishment, could also be cumbersome. + + TLS only allows SIP entities to authenticate servers to which they + are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, + nor any other mechanism specified in this document, allows clients to + authenticate proxy servers to whom they cannot form a direct TCP + connection. + +26.4.4 SIPS URIs + + Actually using TLS on every segment of a request path entails that + the terminating UAS must be reachable over TLS (perhaps registering + with a SIPS URI as a contact address). This is the preferred use of + SIPS. Many valid architectures, however, use TLS to secure part of + the request path, but rely on some other mechanism for the final hop + to a UAS, for example. Thus SIPS cannot guarantee that TLS usage + will be truly end-to-end. Note that since many UAs will not accept + incoming TLS connections, even those UAs that do support TLS may be + required to maintain persistent TLS connections as described in the + TLS limitations section above in order to receive requests over TLS + as a UAS. + + + +Rosenberg, et. al. Standards Track [Page 249] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Location services are not required to provide a SIPS binding for a + SIPS Request-URI. Although location services are commonly populated + by user registrations (as described in Section 10.2.1), various other + protocols and interfaces could conceivably supply contact addresses + for an AOR, and these tools are free to map SIPS URIs to SIP URIs as + appropriate. When queried for bindings, a location service returns + its contact addresses without regard for whether it received a + request with a SIPS Request-URI. If a redirect server is accessing + the location service, it is up to the entity that processes the + Contact header field of a redirection to determine the propriety of + the contact addresses. + + Ensuring that TLS will be used for all of the request segments up to + the target domain is somewhat complex. It is possible that + cryptographically authenticated proxy servers along the way that are + non-compliant or compromised may choose to disregard the forwarding + rules associated with SIPS (and the general forwarding rules in + Section 16.6). Such malicious intermediaries could, for example, + retarget a request from a SIPS URI to a SIP URI in an attempt to + downgrade security. + + Alternatively, an intermediary might legitimately retarget a request + from a SIP to a SIPS URI. Recipients of a request whose Request-URI + uses the SIPS URI scheme thus cannot assume on the basis of the + Request-URI alone that SIPS was used for the entire request path + (from the client onwards). + + To address these concerns, it is RECOMMENDED that recipients of a + request whose Request-URI contains a SIP or SIPS URI inspect the To + header field value to see if it contains a SIPS URI (though note that + it does not constitute a breach of security if this URI has the same + scheme but is not equivalent to the URI in the To header field). + Although clients may choose to populate the Request-URI and To header + field of a request differently, when SIPS is used this disparity + could be interpreted as a possible security violation, and the + request could consequently be rejected by its recipient. Recipients + MAY also inspect the Via header chain in order to double-check + whether or not TLS was used for the entire request path until the + local administrative domain was reached. S/MIME may also be used by + the originating UAC to help ensure that the original form of the To + header field is carried end-to-end. + + If the UAS has reason to believe that the scheme of the Request-URI + has been improperly modified in transit, the UA SHOULD notify its + user of a potential security breach. + + + + + + +Rosenberg, et. al. Standards Track [Page 250] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + As a further measure to prevent downgrade attacks, entities that + accept only SIPS requests MAY also refuse connections on insecure + ports. + + End users will undoubtedly discern the difference between SIPS and + SIP URIs, and they may manually edit them in response to stimuli. + This can either benefit or degrade security. For example, if an + attacker corrupts a DNS cache, inserting a fake record set that + effectively removes all SIPS records for a proxy server, then any + SIPS requests that traverse this proxy server may fail. When a user, + however, sees that repeated calls to a SIPS AOR are failing, they + could on some devices manually convert the scheme from SIPS to SIP + and retry. Of course, there are some safeguards against this (if the + destination UA is truly paranoid it could refuse all non-SIPS + requests), but it is a limitation worth noting. On the bright side, + users might also divine that 'SIPS' would be valid even when they are + presented only with a SIP URI. + +26.5 Privacy + + SIP messages frequently contain sensitive information about their + senders - not just what they have to say, but with whom they + communicate, when they communicate and for how long, and from where + they participate in sessions. Many applications and their users + require that this sort of private information be hidden from any + parties that do not need to know it. + + Note that there are also less direct ways in which private + information can be divulged. If a user or service chooses to be + reachable at an address that is guessable from the person's name and + organizational affiliation (which describes most addresses-of- + record), the traditional method of ensuring privacy by having an + unlisted "phone number" is compromised. A user location service can + infringe on the privacy of the recipient of a session invitation by + divulging their specific whereabouts to the caller; an implementation + consequently 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. This is a whole class of problem that is + expected to be studied further in ongoing SIP work. + + In some cases, users may want to conceal personal information in + header fields that convey identity. This can apply not only to the + From and related headers representing the originator of the request, + but also the To - it may not be appropriate to convey to the final + destination a speed-dialing nickname, or an unexpanded identifier for + a group of targets, either of which would be removed from the + Request-URI as the request is routed, but not changed in the To + + + + +Rosenberg, et. al. Standards Track [Page 251] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + header field if the two were initially identical. Thus it MAY be + desirable for privacy reasons to create a To header field that + differs from the Request-URI. + +27 IANA Considerations + + All method names, header field names, status codes, and option tags + used in SIP applications are registered with IANA through + instructions in an IANA Considerations section in an RFC. + + The specification instructs the IANA to create four new sub- + registries under http://www.iana.org/assignments/sip-parameters: + Option Tags, Warning Codes (warn-codes), Methods and Response Codes, + added to the sub-registry of Header Fields that is already present + there. + +27.1 Option Tags + + This specification establishes the Option Tags sub-registry under + http://www.iana.org/assignments/sip-parameters. + + Option tags are used in header fields such as Require, Supported, + Proxy-Require, and Unsupported in support of SIP compatibility + mechanisms for extensions (Section 19.2). The option tag itself is a + string that is associated with a particular SIP option (that is, an + extension). It identifies the option to SIP endpoints. + + Option tags are registered by the IANA when they are published in + standards track RFCs. The IANA Considerations section of the RFC + must include the following information, which appears in the IANA + registry along with the RFC number of the publication. + + o Name of the option tag. The name MAY be of any length, but + SHOULD be no more than twenty characters long. The name MUST + consist of alphanum (Section 25) characters only. + + o Descriptive text that describes the extension. + +27.2 Warn-Codes + + This specification establishes the Warn-codes sub-registry under + http://www.iana.org/assignments/sip-parameters and initiates its + population with the warn-codes listed in Section 20.43. Additional + warn-codes are registered by RFC publication. + + + + + + + +Rosenberg, et. al. Standards Track [Page 252] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + The descriptive text for the table of warn-codes is: + + Warning codes provide information supplemental to the status code in + SIP response messages when the failure of the transaction results + from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. + + The "warn-code" consists of three digits. A first digit of "3" + indicates warnings specific to SIP. Until a future specification + describes uses of warn-codes other than 3xx, only 3xx warn-codes may + be registered. + + 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. + +27.3 Header Field Names + + This obsoletes the IANA instructions about the header sub-registry + under http://www.iana.org/assignments/sip-parameters. + + The following information needs to be provided in an RFC publication + in order to register a new header field name: + + o The RFC number in which the header is registered; + + o the name of the header field being registered; + + o a compact form version for that header field, if one is + defined; + + Some common and widely used header fields MAY be assigned one-letter + compact forms (Section 7.3.3). Compact forms can only be assigned + after SIP working group review, followed by RFC publication. + +27.4 Method and Response Codes + + This specification establishes the Method and Response-Code sub- + registries under http://www.iana.org/assignments/sip-parameters and + initiates their population as follows. The initial Methods table is: + + + + + + + + +Rosenberg, et. al. Standards Track [Page 253] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + INVITE [RFC3261] + ACK [RFC3261] + BYE [RFC3261] + CANCEL [RFC3261] + REGISTER [RFC3261] + OPTIONS [RFC3261] + INFO [RFC2976] + + The response code table is initially populated from Section 21, the + portions labeled Informational, Success, Redirection, Client-Error, + Server-Error, and Global-Failure. The table has the following + format: + + Type (e.g., Informational) + Number Default Reason Phrase [RFC3261] + + The following information needs to be provided in an RFC publication + in order to register a new response code or method: + + o The RFC number in which the method or response code is + registered; + + o the number of the response code or name of the method being + registered; + + o the default reason phrase for that response code, if + applicable; + +27.5 The "message/sip" MIME type. + + This document registers the "message/sip" MIME media type in order to + allow SIP messages to be tunneled as bodies within SIP, primarily for + end-to-end security purposes. This media type is defined by the + following information: + + Media type name: message + Media subtype name: sip + Required parameters: none + + Optional parameters: version + version: The SIP-Version number of the enclosed message (e.g., + "2.0"). If not present, the version defaults to "2.0". + Encoding scheme: SIP messages consist of an 8-bit header + optionally followed by a binary MIME data object. As such, SIP + messages must be treated as binary. Under normal circumstances + SIP messages are transported over binary-capable transports, no + special encodings are needed. + + + + +Rosenberg, et. al. Standards Track [Page 254] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Security considerations: see below + Motivation and examples of this usage as a security mechanism + in concert with S/MIME are given in 23.4. + +27.6 New Content-Disposition Parameter Registrations + + This document also registers four new Content-Disposition header + "disposition-types": alert, icon, session and render. The authors + request that these values be recorded in the IANA registry for + Content-Dispositions. + + Descriptions of these "disposition-types", including motivation and + examples, are given in Section 20.11. + + Short descriptions suitable for the IANA registry are: + + alert the body is a custom ring tone to alert the user + icon the body is displayed as an icon to the user + render the body should be displayed to the user + session the body describes a communications session, for + example, as RFC 2327 SDP body + +28 Changes From RFC 2543 + + This RFC revises RFC 2543. It is mostly backwards compatible with + RFC 2543. The changes described here fix many errors discovered in + RFC 2543 and provide information on scenarios not detailed in RFC + 2543. The protocol has been presented in a more cleanly layered + model here. + + We break the differences into functional behavior that is a + substantial change from RFC 2543, which has impact on + interoperability or correct operation in some cases, and functional + behavior that is different from RFC 2543 but not a potential source + of interoperability problems. There have been countless + clarifications as well, which are not documented here. + +28.1 Major Functional Changes + + o When a UAC wishes to terminate a call before it has been answered, + it sends CANCEL. If the original INVITE still returns a 2xx, the + UAC then sends BYE. BYE can only be sent on an existing call leg + (now called a dialog in this RFC), whereas it could be sent at any + time in RFC 2543. + + o The SIP BNF was converted to be RFC 2234 compliant. + + + + + +Rosenberg, et. al. Standards Track [Page 255] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o SIP URL BNF was made more general, allowing a greater set of + characters in the user part. Furthermore, comparison rules were + simplified to be primarily case-insensitive, and detailed handling + of comparison in the presence of parameters was described. The + most substantial change is that a URI with a parameter with the + default value does not match a URI without that parameter. + + o Removed Via hiding. It had serious trust issues, since it relied + on the next hop to perform the obfuscation process. Instead, Via + hiding can be done as a local implementation choice in stateful + proxies, and thus is no longer documented. + + o In RFC 2543, CANCEL and INVITE transactions were intermingled. + They are separated now. When a user sends an INVITE and then a + CANCEL, the INVITE transaction still terminates normally. A UAS + needs to respond to the original INVITE request with a 487 + response. + + o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 + allowed the UAS not to send a response to INVITE when a BYE was + received. That is disallowed here. The original INVITE needs a + response. + + o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs + need to support both UDP and TCP. + + o In RFC 2543, a forking proxy only passed up one challenge from + downstream elements in the event of multiple challenges. In this + RFC, proxies are supposed to collect all challenges and place them + into the forwarded response. + + o In Digest credentials, the URI needs to be quoted; this is unclear + from RFC 2617 and RFC 2069 which are both inconsistent on it. + + o SDP processing has been split off into a separate specification + [13], and more fully specified as a formal offer/answer exchange + process that is effectively tunneled through SIP. SDP is allowed + in INVITE/200 or 200/ACK for baseline SIP implementations; RFC + 2543 alluded to the ability to use it in INVITE, 200, and ACK in a + single transaction, but this was not well specified. More complex + SDP usages are allowed in extensions. + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 256] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Added full support for IPv6 in URIs and in the Via header field. + Support for IPv6 in Via has required that its header field + parameters allow the square bracket and colon characters. These + characters were previously not permitted. In theory, this could + cause interop problems with older implementations. However, we + have observed that most implementations accept any non-control + ASCII character in these parameters. + + o DNS SRV procedure is now documented in a separate specification + [4]. This procedure uses both SRV and NAPTR resource records and + no longer combines data from across SRV records as described in + RFC 2543. + + o Loop detection has been made optional, supplanted by a mandatory + usage of Max-Forwards. The loop detection procedure in RFC 2543 + had a serious bug which would report "spirals" as an error + condition when it was not. The optional loop detection procedure + is more fully and correctly specified here. + + o Usage of tags is now mandatory (they were optional in RFC 2543), + as they are now the fundamental building blocks of dialog + identification. + + o Added the Supported header field, allowing for clients to indicate + what extensions are supported to a server, which can apply those + extensions to the response, and indicate their usage with a + Require in the response. + + o Extension parameters were missing from the BNF for several header + fields, and they have been added. + + o Handling of Route and Record-Route construction was very + underspecified in RFC 2543, and also not the right approach. It + has been substantially reworked in this specification (and made + vastly simpler), and this is arguably the largest change. + Backwards compatibility is still provided for deployments that do + not use "pre-loaded routes", where the initial request has a set + of Route header field values obtained in some way outside of + Record-Route. In those situations, the new mechanism is not + interoperable. + + o In RFC 2543, lines in a message could be terminated with CR, LF, + or CRLF. This specification only allows CRLF. + + + + + + + + +Rosenberg, et. al. Standards Track [Page 257] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. + It is now well specified; if a request had a Route header field, + its CANCEL or ACK for a non-2xx response to the request need to + carry the same Route header field values. ACKs for 2xx responses + use the Route values learned from the Record-Route of the 2xx + responses. + + o RFC 2543 allowed multiple requests in a single UDP packet. This + usage has been removed. + + o Usage of absolute time in the Expires header field and parameter + has been removed. It caused interoperability problems in elements + that were not time synchronized, a common occurrence. Relative + times are used instead. + + o The branch parameter of the Via header field value is now + mandatory for all elements to use. It now plays the role of a + unique transaction identifier. This avoids the complex and bug- + laden transaction identification rules from RFC 2543. A magic + cookie is used in the parameter value to determine if the previous + hop has made the parameter globally unique, and comparison falls + back to the old rules when it is not present. Thus, + interoperability is assured. + + o In RFC 2543, closure of a TCP connection was made equivalent to a + CANCEL. This was nearly impossible to implement (and wrong) for + TCP connections between proxies. This has been eliminated, so + that there is no coupling between TCP connection state and SIP + processing. + + o RFC 2543 was silent on whether a UA could initiate a new + transaction to a peer while another was in progress. That is now + specified here. It is allowed for non-INVITE requests, disallowed + for INVITE. + + o PGP was removed. It was not sufficiently specified, and not + compatible with the more complete PGP MIME. It was replaced with + S/MIME. + + o Added the "sips" URI scheme for end-to-end TLS. This scheme is + not backwards compatible with RFC 2543. Existing elements that + receive a request with a SIPS URI scheme in the Request-URI will + likely reject the request. This is actually a feature; it ensures + that a call to a SIPS URI is only delivered if all path hops can + be secured. + + + + + + +Rosenberg, et. al. Standards Track [Page 258] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Additional security features were added with TLS, and these are + described in a much larger and complete security considerations + section. + + o In RFC 2543, a proxy was not required to forward provisional + responses from 101 to 199 upstream. This was changed to MUST. + This is important, since many subsequent features depend on + delivery of all provisional responses from 101 to 199. + + o Little was said about the 503 response code in RFC 2543. It has + since found substantial use in indicating failure or overload + conditions in proxies. This requires somewhat special treatment. + Specifically, receipt of a 503 should trigger an attempt to + contact the next element in the result of a DNS SRV lookup. Also, + 503 response is only forwarded upstream by a proxy under certain + conditions. + + o RFC 2543 defined, but did no sufficiently specify, a mechanism for + UA authentication of a server. That has been removed. Instead, + the mutual authentication procedures of RFC 2617 are allowed. + + o A UA cannot send a BYE for a call until it has received an ACK for + the initial INVITE. This was allowed in RFC 2543 but leads to a + potential race condition. + + o A UA or proxy cannot send CANCEL for a transaction until it gets a + provisional response for the request. This was allowed in RFC + 2543 but leads to potential race conditions. + + o The action parameter in registrations has been deprecated. It was + insufficient for any useful services, and caused conflicts when + application processing was applied in proxies. + + o RFC 2543 had a number of special cases for multicast. For + example, certain responses were suppressed, timers were adjusted, + and so on. Multicast now plays a more limited role, and the + protocol operation is unaffected by usage of multicast as opposed + to unicast. The limitations as a result of that are documented. + + o Basic authentication has been removed entirely and its usage + forbidden. + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 259] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + o Proxies no longer forward a 6xx immediately on receiving it. + Instead, they CANCEL pending branches immediately. This avoids a + potential race condition that would result in a UAC getting a 6xx + followed by a 2xx. In all cases except this race condition, the + result will be the same - the 6xx is forwarded upstream. + + o RFC 2543 did not address the problem of request merging. This + occurs when a request forks at a proxy and later rejoins at an + element. Handling of merging is done only at a UA, and procedures + are defined for rejecting all but the first request. + +28.2 Minor Functional Changes + + o Added the Alert-Info, Error-Info, and Call-Info header fields for + optional content presentation to users. + + o Added the Content-Language, Content-Disposition and MIME-Version + header fields. + + o Added a "glare handling" mechanism to deal with the case where + both parties send each other a re-INVITE simultaneously. It uses + the new 491 (Request Pending) error code. + + o Added the In-Reply-To and Reply-To header fields for supporting + the return of missed calls or messages at a later time. + + o Added TLS and SCTP as valid SIP transports. + + o There were a variety of mechanisms described for handling failures + at any time during a call; those are now generally unified. BYE + is sent to terminate. + + o RFC 2543 mandated retransmission of INVITE responses over TCP, but + noted it was really only needed for 2xx. That was an artifact of + insufficient protocol layering. With a more coherent transaction + layer defined here, that is no longer needed. Only 2xx responses + to INVITEs are retransmitted over TCP. + + o Client and server transaction machines are now driven based on + timeouts rather than retransmit counts. This allows the state + machines to be properly specified for TCP and UDP. + + o The Date header field is used in REGISTER responses to provide a + simple means for auto-configuration of dates in user agents. + + o Allowed a registrar to reject registrations with expirations that + are too short in duration. Defined the 423 response code and the + Min-Expires for this purpose. + + + +Rosenberg, et. al. Standards Track [Page 260] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +29 Normative References + + [1] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", + RFC 3263, June 2002. + + [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for + Transport Layer Security (TLS)", RFC 3268, June 2002. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., + Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + + [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April + 2000. + + [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + SDP", RFC 3264, June 2002. + + [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC + 761, January 1980. + + + + +Rosenberg, et. al. Standards Track [Page 261] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, + H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, + "Stream Control Transmission Protocol", RFC 2960, October 2000. + + [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: + Basic and Digest Access Authentication", RFC 2617, June 1999. + + [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation + Information in Internet Messages: The Content-Disposition Header + Field", RFC 2183, August 1997. + + [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., + Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG + Objects", RFC 3204, December 2001. + + [20] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, October 1989. + + [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", + BCP 18, RFC 2277, January 1998. + + [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security + Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", + RFC 1847, October 1995. + + [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June + 1999. + + [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, + June 1999. + + [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [26] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + +30 Informative References + + [27] R. Pandya, "Emerging mobile and personal communication systems," + IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. + + [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 1889, January 1996. + + + + + +Rosenberg, et. al. Standards Track [Page 262] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming + Protocol (RTSP)", RFC 2326, April 1998. + + [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and + J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November + 2000. + + [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL + scheme", RFC 2368, July 1998. + + [33] E. M. Schooler, "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. + + [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. + + [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC + 2426, September 1998. + + [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical + Specification", RFC 2849, June 2000. + + [38] Palme, J., "Common Internet Message Headers", RFC 2076, + February 1997. + + [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., + Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: + Digest Access Authentication", RFC 2069, January 1997. + + [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, + D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call + Flow Examples", Work in Progress. + + [41] E. M. Schooler, "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. + + + + + + + +Rosenberg, et. al. Standards Track [Page 263] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + [42] H. Schulzrinne, "Personal mobility for multimedia services in + the Internet," in European Workshop on Interactive Distributed + Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. + 1996. + + [43] Floyd, S., "Congestion Control Principles", RFC 2914, September + 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 264] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +A Table of Timer Values + + Table 4 summarizes the meaning and defaults of the various timers + used by this specification. + +Timer Value Section Meaning +---------------------------------------------------------------------- +T1 500ms default Section 17.1.1.1 RTT Estimate +T2 4s Section 17.1.2.2 The maximum retransmit + interval for non-INVITE + requests and INVITE + responses +T4 5s Section 17.1.2.2 Maximum duration a + message will + remain in the network +Timer A initially T1 Section 17.1.1.2 INVITE request retransmit + interval, for UDP only +Timer B 64*T1 Section 17.1.1.2 INVITE transaction + timeout timer +Timer C > 3min Section 16.6 proxy INVITE transaction + bullet 11 timeout +Timer D > 32s for UDP Section 17.1.1.2 Wait time for response + 0s for TCP/SCTP retransmits +Timer E initially T1 Section 17.1.2.2 non-INVITE request + retransmit interval, + UDP only +Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction + timeout timer +Timer G initially T1 Section 17.2.1 INVITE response + retransmit interval +Timer H 64*T1 Section 17.2.1 Wait time for + ACK receipt +Timer I T4 for UDP Section 17.2.1 Wait time for + 0s for TCP/SCTP ACK retransmits +Timer J 64*T1 for UDP Section 17.2.2 Wait time for + 0s for TCP/SCTP non-INVITE request + retransmits +Timer K T4 for UDP Section 17.1.2.2 Wait time for + 0s for TCP/SCTP response retransmits + + Table 4: Summary of timers + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 265] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Acknowledgments + + We wish to thank the members of the IETF MMUSIC and SIP WGs for their + comments and suggestions. Detailed comments were provided by Ofir + Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, + Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John + Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, + Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders + Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William + Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe + J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick + Workman. + + Brian Rosen provided the compiled BNF. + + Jean Mahoney provided technical writing assistance. + + This work is based, inter alia, on [41,42]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 266] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Authors' Addresses + + Authors addresses are listed alphabetically for the editors, the + writers, and then the original authors of RFC 2543. All listed + authors actively contributed large amounts of text to this document. + + Jonathan Rosenberg + dynamicsoft + 72 Eagle Rock Ave + East Hanover, NJ 07936 + USA + + EMail: jdrosen@dynamicsoft.com + + + Henning Schulzrinne + Dept. of Computer Science + Columbia University + 1214 Amsterdam Avenue + New York, NY 10027 + USA + + EMail: schulzrinne@cs.columbia.edu + + + Gonzalo Camarillo + Ericsson + Advanced Signalling Research Lab. + FIN-02420 Jorvas + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Alan Johnston + WorldCom + 100 South 4th Street + St. Louis, MO 63102 + USA + + EMail: alan.johnston@wcom.com + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 267] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + + Jon Peterson + NeuStar, Inc + 1800 Sutter Street, Suite 570 + Concord, CA 94520 + USA + + EMail: jon.peterson@neustar.com + + + Robert Sparks + dynamicsoft, Inc. + 5100 Tennyson Parkway + Suite 1200 + Plano, Texas 75024 + USA + + EMail: rsparks@dynamicsoft.com + + + Mark Handley + International Computer Science Institute + 1947 Center St, Suite 600 + Berkeley, CA 94704 + USA + + EMail: mjh@icir.org + + + Eve Schooler + AT&T Labs-Research + 75 Willow Road + Menlo Park, CA 94025 + USA + + EMail: schooler@research.att.com + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 268] + +RFC 3261 SIP: Session Initiation Protocol June 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rosenberg, et. al. Standards Track [Page 269] + |