00001 00002 00003 00004 00005 00006 00007 Internet Engineering Task Force SIP WG 00008 Internet Draft J. Rosenberg 00009 dynamicsoft 00010 H. Schulzrinne 00011 Columbia U. 00012 G. Camarillo 00013 Ericsson 00014 A. Johnston 00015 Worldcom 00016 J. Peterson 00017 Neustar 00018 R. Sparks 00019 dynamicsoft 00020 M. Handley 00021 ACIRI 00022 E. Schooler 00023 AT&T 00024 draft-ietf-sip-rfc2543bis-07.9.txt 00025 February 18, 2002 00026 Expires: Aug 2002 00027 00028 00029 SIP: Session Initiation Protocol 00030 00031 STATUS OF THIS MEMO 00032 00033 This document is an Internet-Draft and is in full conformance with 00034 all provisions of Section 10 of RFC2026. 00035 00036 Internet-Drafts are working documents of the Internet Engineering 00037 Task Force (IETF), its areas, and its working groups. Note that 00038 other groups may also distribute working documents as Internet- 00039 Drafts. 00040 00041 Internet-Drafts are draft documents valid for a maximum of six months 00042 and may be updated, replaced, or obsoleted by other documents at any 00043 time. It is inappropriate to use Internet-Drafts as reference 00044 material or to cite them other than as "work in progress". 00045 00046 The list of current Internet-Drafts can be accessed at 00047 http://www.ietf.org/ietf/1id-abstracts.txt 00048 00049 To view the list Internet-Draft Shadow Directories, see 00050 http://www.ietf.org/shadow.html. 00051 00052 Abstract 00053 00054 The Session Initiation Protocol (SIP) is an application-layer control 00055 00056 00057 00058 J. Rosenberg et. al. [Page 1] 00059 Internet Draft SIP February 18, 2002 00060 00061 00062 (signaling) protocol for creating, modifying, and terminating 00063 sessions with one or more participants. These sessions include 00064 Internet telephone calls, multimedia distribution, and multimedia 00065 conferences. 00066 00067 SIP invitations used to create sessions carry session descriptions 00068 that allow participants to agree on a set of compatible media types. 00069 SIP makes use of elements called proxy servers to help route requests 00070 to the user's current location, authenticate and authorize users for 00071 services, implement provider call-routing policies, and provide 00072 features to users. SIP also provides a registration function that 00073 allows users to upload their current locations for use by proxy 00074 servers. SIP runs on top of several different transport protocols. 00075 00076 00077 00078 00079 00080 00081 00082 00083 00084 00085 00086 00087 00088 00089 00090 00091 00092 00093 00094 00095 00096 00097 00098 00099 00100 00101 00102 00103 00104 00105 00106 00107 00108 00109 00110 00111 00112 00113 J. Rosenberg et. al. [Page 2] 00114 Internet Draft SIP February 18, 2002 00115 00116 00117 00118 00119 00120 00121 Table of Contents 00122 00123 00124 00125 1 Introduction ........................................ 3 00126 2 Overview of SIP Functionality ....................... 3 00127 3 Terminology ......................................... 4 00128 4 Overview of Operation ............................... 5 00129 5 Structure of the Protocol ........................... 12 00130 6 Definitions ......................................... 14 00131 7 SIP Messages ........................................ 21 00132 7.1 Requests ............................................ 21 00133 7.2 Responses ........................................... 22 00134 7.3 Header Fields ....................................... 23 00135 7.3.1 Header Field Format ................................. 24 00136 7.3.2 Header Field Classification ......................... 27 00137 7.3.3 Compact Form ........................................ 27 00138 7.4 Bodies .............................................. 27 00139 7.4.1 Message Body Type ................................... 27 00140 7.4.2 Message Body Length ................................. 28 00141 7.5 Framing SIP messages ................................ 28 00142 8 General User Agent Behavior ......................... 28 00143 8.1 UAC Behavior ........................................ 29 00144 8.1.1 Generating the Request .............................. 29 00145 8.1.1.1 Request-URI ......................................... 29 00146 8.1.1.2 To .................................................. 30 00147 8.1.1.3 From ................................................ 31 00148 8.1.1.4 Call-ID ............................................. 32 00149 8.1.1.5 CSeq ................................................ 33 00150 8.1.1.6 Max-Forwards ........................................ 33 00151 8.1.1.7 Via ................................................. 33 00152 8.1.1.8 Contact ............................................. 34 00153 8.1.1.9 Supported and Require ............................... 35 00154 8.1.1.10 Additional Message Components ....................... 35 00155 8.1.2 Sending the Request ................................. 35 00156 8.1.3 Processing Responses ................................ 36 00157 8.1.3.1 Transaction Layer Errors ............................ 36 00158 8.1.3.2 Unrecognized Responses .............................. 37 00159 8.1.3.3 Vias ................................................ 37 00160 8.1.3.4 Processing 3xx Responses ............................ 37 00161 8.1.3.5 Processing 4xx Responses ............................ 39 00162 8.2 UAS Behavior ........................................ 40 00163 8.2.1 Method Inspection ................................... 41 00164 8.2.2 Header Inspection ................................... 41 00165 8.2.2.1 To and Request-URI .................................. 41 00166 00167 00168 00169 J. Rosenberg et. al. [Page a] 00170 Internet Draft SIP February 18, 2002 00171 00172 00173 8.2.2.2 Merged Requests ..................................... 42 00174 8.2.2.3 Require ............................................. 42 00175 8.2.3 Content Processing .................................. 43 00176 8.2.4 Applying Extensions ................................. 43 00177 8.2.5 Processing the Request .............................. 44 00178 8.2.6 Generating the Response ............................. 44 00179 8.2.6.1 Sending a Provisional Response ...................... 44 00180 8.2.6.2 Headers and Tags .................................... 44 00181 8.2.7 Stateless UAS Behavior .............................. 45 00182 8.3 Redirect Servers .................................... 46 00183 9 Canceling a Request ................................. 47 00184 9.1 Client Behavior ..................................... 48 00185 9.2 Server Behavior ..................................... 49 00186 10 Registrations ....................................... 50 00187 10.1 Overview ............................................ 50 00188 10.2 Constructing the REGISTER Request ................... 51 00189 10.2.1 Adding Bindings ..................................... 54 00190 10.2.1.1 Setting the Expiration Interval of Contact 00191 Addresses ...................................................... 55 00192 10.2.1.2 Preferences among Contact Addresses ................. 55 00193 10.2.2 Removing Bindings ................................... 55 00194 10.2.3 Fetching Bindings ................................... 56 00195 10.2.4 Refreshing Bindings ................................. 56 00196 10.2.5 Setting the Internal Clock .......................... 56 00197 10.2.6 Discovering a Registrar ............................. 56 00198 10.2.7 Transmitting a Request .............................. 57 00199 10.2.8 Error Responses ..................................... 57 00200 10.3 Processing REGISTER Requests ........................ 57 00201 11 Querying for Capabilities ........................... 61 00202 11.1 Construction of OPTIONS Request ..................... 61 00203 11.2 Processing of OPTIONS Request ....................... 62 00204 12 Dialogs ............................................. 64 00205 12.1 Creation of a Dialog ................................ 64 00206 12.1.1 UAS behavior ........................................ 65 00207 12.1.2 UAC Behavior ........................................ 66 00208 12.2 Requests within a Dialog ............................ 67 00209 12.2.1 UAC Behavior ........................................ 67 00210 12.2.1.1 Generating the Request .............................. 67 00211 12.2.1.2 Processing the Responses ............................ 70 00212 12.2.2 UAS Behavior ........................................ 70 00213 12.3 Termination of a Dialog ............................. 72 00214 13 Initiating a Session ................................ 72 00215 13.1 Overview ............................................ 72 00216 13.2 UAC Processing ...................................... 73 00217 13.2.1 Creating the Initial INVITE ......................... 73 00218 13.2.2 Processing INVITE Responses ......................... 75 00219 13.2.2.1 1xx responses ....................................... 75 00220 13.2.2.2 3xx responses ....................................... 76 00221 00222 00223 00224 J. Rosenberg et. al. [Page b] 00225 Internet Draft SIP February 18, 2002 00226 00227 00228 13.2.2.3 4xx, 5xx and 6xx responses .......................... 76 00229 13.2.2.4 2xx responses ....................................... 76 00230 13.3 UAS Processing ...................................... 77 00231 13.3.1 Processing of the INVITE ............................ 77 00232 13.3.1.1 Progress ............................................ 78 00233 13.3.1.2 The INVITE is redirected ............................ 79 00234 13.3.1.3 The INVITE is rejected .............................. 79 00235 13.3.1.4 The INVITE is accepted .............................. 79 00236 14 Modifying an Existing Session ....................... 80 00237 14.1 UAC Behavior ........................................ 81 00238 14.2 UAS Behavior ........................................ 82 00239 15 Terminating a Session ............................... 83 00240 15.1 Terminating a Session with a BYE Request ............ 85 00241 15.1.1 UAC Behavior ........................................ 85 00242 15.1.2 UAS Behavior ........................................ 85 00243 16 Proxy Behavior ...................................... 86 00244 16.1 Overview ............................................ 86 00245 16.2 Stateful Proxy ...................................... 87 00246 16.3 Request Validation .................................. 88 00247 16.4 Route Information Preprocessing ..................... 90 00248 16.5 Determining request targets ......................... 91 00249 16.6 Request Forwarding .................................. 93 00250 16.7 Response Processing ................................. 101 00251 16.8 Processing Timer C .................................. 109 00252 16.9 Handling Transport Errors ........................... 110 00253 16.10 CANCEL Processing ................................... 110 00254 16.11 Stateless Proxy ..................................... 110 00255 16.12 Summary of Proxy Route Processing ................... 113 00256 16.12.1 Examples ............................................ 113 00257 16.12.1.1 Basic SIP Trapezoid ................................. 113 00258 16.12.1.2 Traversing a strict-routing proxy ................... 115 00259 16.12.1.3 Rewriting Record-Route header field values .......... 117 00260 17 Transactions ........................................ 118 00261 17.1 Client Transaction .................................. 120 00262 17.1.1 INVITE Client Transaction ........................... 121 00263 17.1.1.1 Overview of INVITE Transaction ...................... 121 00264 17.1.1.2 Formal Description .................................. 121 00265 17.1.1.3 Construction of the ACK Request ..................... 125 00266 17.1.2 Non-INVITE Client Transaction ....................... 126 00267 17.1.2.1 Overview of the non-INVITE Transaction .............. 126 00268 17.1.2.2 Formal Description .................................. 126 00269 17.1.3 Matching Responses to Client Transactions ........... 127 00270 17.1.4 Handling Transport Errors ........................... 129 00271 17.2 Server Transaction .................................. 129 00272 17.2.1 INVITE Server Transaction ........................... 129 00273 17.2.2 Non-INVITE Server Transaction ....................... 132 00274 17.2.3 Matching Requests to Server Transactions ............ 133 00275 17.2.4 Handling Transport Errors ........................... 135 00276 00277 00278 00279 J. Rosenberg et. al. [Page c] 00280 Internet Draft SIP February 18, 2002 00281 00282 00283 18 Transport ........................................... 136 00284 18.1 Clients ............................................. 136 00285 18.1.1 Sending Requests .................................... 137 00286 18.1.2 Receiving Responses ................................. 139 00287 18.2 Servers ............................................. 139 00288 18.2.1 Receiving Requests .................................. 139 00289 18.2.2 Sending Responses ................................... 140 00290 18.3 Framing ............................................. 141 00291 18.4 Error Handling ...................................... 141 00292 19 Common Message Components ........................... 142 00293 19.1 SIP and SIPS Uniform Resource Indicators ............ 142 00294 19.1.1 SIP and SIPS URI Components ......................... 142 00295 19.1.2 Character Escaping Requirements ..................... 146 00296 19.1.3 Example SIP and SIPS URIs ........................... 147 00297 19.1.4 URI Comparison ...................................... 148 00298 19.1.5 Forming Requests from a URI ......................... 151 00299 19.1.6 Relating SIP URIs and tel URLs ...................... 152 00300 19.2 Option Tags ......................................... 154 00301 19.3 Tags ................................................ 154 00302 20 Header Fields ....................................... 155 00303 20.1 Accept .............................................. 158 00304 20.2 Accept-Encoding ..................................... 159 00305 20.3 Accept-Language ..................................... 159 00306 20.4 Alert-Info .......................................... 160 00307 20.5 Allow ............................................... 160 00308 20.6 Authentication-Info ................................. 161 00309 20.7 Authorization ....................................... 161 00310 20.8 Call-ID ............................................. 161 00311 20.9 Call-Info ........................................... 162 00312 20.10 Contact ............................................. 162 00313 20.11 Content-Disposition ................................. 163 00314 20.12 Content-Encoding .................................... 164 00315 20.13 Content-Language .................................... 165 00316 20.14 Content-Length ...................................... 165 00317 20.15 Content-Type ........................................ 165 00318 20.16 CSeq ................................................ 166 00319 20.17 Date ................................................ 166 00320 20.18 Error-Info .......................................... 166 00321 20.19 Expires ............................................. 167 00322 20.20 From ................................................ 167 00323 20.21 In-Reply-To ......................................... 168 00324 20.22 Max-Forwards ........................................ 168 00325 20.23 Min-Expires ......................................... 169 00326 20.24 MIME-Version ........................................ 169 00327 20.25 Organization ........................................ 169 00328 20.26 Priority ............................................ 170 00329 20.27 Proxy-Authenticate .................................. 170 00330 20.28 Proxy-Authorization ................................. 171 00331 00332 00333 00334 J. Rosenberg et. al. [Page d] 00335 Internet Draft SIP February 18, 2002 00336 00337 00338 20.29 Proxy-Require ....................................... 171 00339 20.30 Record-Route ........................................ 172 00340 20.31 Reply-To ............................................ 172 00341 20.32 Require ............................................. 172 00342 20.33 Retry-After ......................................... 173 00343 20.34 Route ............................................... 173 00344 20.35 Server .............................................. 173 00345 20.36 Subject ............................................. 174 00346 20.37 Supported ........................................... 174 00347 20.38 Timestamp ........................................... 174 00348 20.39 To .................................................. 175 00349 20.40 Unsupported ......................................... 175 00350 20.41 User-Agent .......................................... 176 00351 20.42 Via ................................................. 176 00352 20.43 Warning ............................................. 177 00353 20.44 WWW-Authenticate .................................... 179 00354 21 Response Codes ...................................... 179 00355 21.1 Provisional 1xx ..................................... 179 00356 21.1.1 100 Trying .......................................... 179 00357 21.1.2 180 Ringing ......................................... 179 00358 21.1.3 181 Call Is Being Forwarded ......................... 179 00359 21.1.4 182 Queued .......................................... 180 00360 21.1.5 183 Session Progress ................................ 180 00361 21.2 Successful 2xx ...................................... 180 00362 21.2.1 200 OK .............................................. 180 00363 21.3 Redirection 3xx ..................................... 180 00364 21.3.1 300 Multiple Choices ................................ 180 00365 21.3.2 301 Moved Permanently ............................... 181 00366 21.3.3 302 Moved Temporarily ............................... 181 00367 21.3.4 305 Use Proxy ....................................... 181 00368 21.3.5 380 Alternative Service ............................. 182 00369 21.4 Request Failure 4xx ................................. 182 00370 21.4.1 400 Bad Request ..................................... 182 00371 21.4.2 401 Unauthorized .................................... 182 00372 21.4.3 402 Payment Required ................................ 182 00373 21.4.4 403 Forbidden ....................................... 182 00374 21.4.5 404 Not Found ....................................... 182 00375 21.4.6 405 Method Not Allowed .............................. 182 00376 21.4.7 406 Not Acceptable .................................. 183 00377 21.4.8 407 Proxy Authentication Required ................... 183 00378 21.4.9 408 Request Timeout ................................. 183 00379 21.4.10 410 Gone ............................................ 183 00380 21.4.11 413 Request Entity Too Large ........................ 183 00381 21.4.12 414 Request-URI Too Long ............................ 183 00382 21.4.13 415 Unsupported Media Type .......................... 184 00383 21.4.14 416 Unsupported URI Scheme .......................... 184 00384 21.4.15 420 Bad Extension ................................... 184 00385 21.4.16 421 Extension Required .............................. 184 00386 00387 00388 00389 J. Rosenberg et. al. [Page e] 00390 Internet Draft SIP February 18, 2002 00391 00392 00393 21.4.17 423 Interval Too Brief .............................. 184 00394 21.4.18 480 Temporarily Unavailable ......................... 184 00395 21.4.19 481 Call/Transaction Does Not Exist ................. 185 00396 21.4.20 482 Loop Detected ................................... 185 00397 21.4.21 483 Too Many Hops ................................... 185 00398 21.4.22 484 Address Incomplete .............................. 185 00399 21.4.23 485 Ambiguous ....................................... 185 00400 21.4.24 486 Busy Here ....................................... 186 00401 21.4.25 487 Request Terminated .............................. 186 00402 21.4.26 488 Not Acceptable Here ............................. 186 00403 21.4.27 491 Request Pending ................................. 186 00404 21.4.28 493 Undecipherable .................................. 187 00405 21.5 Server Failure 5xx .................................. 187 00406 21.5.1 500 Server Internal Error ........................... 187 00407 21.5.2 501 Not Implemented ................................. 187 00408 21.5.3 502 Bad Gateway ..................................... 187 00409 21.5.4 503 Service Unavailable ............................. 187 00410 21.5.5 504 Server Time-out ................................. 188 00411 21.5.6 505 Version Not Supported ........................... 188 00412 21.5.7 513 Message Too Large ............................... 188 00413 21.6 Global Failures 6xx ................................. 188 00414 21.6.1 600 Busy Everywhere ................................. 188 00415 21.6.2 603 Decline ......................................... 189 00416 21.6.3 604 Does Not Exist Anywhere ......................... 189 00417 21.6.4 606 Not Acceptable .................................. 189 00418 22 Usage of HTTP Authentication ........................ 189 00419 22.1 Framework ........................................... 190 00420 22.2 User-to-User Authentication ......................... 192 00421 22.3 Proxy-to-User Authentication ........................ 193 00422 22.4 The Digest Authentication Scheme .................... 196 00423 23 S/MIME .............................................. 198 00424 23.1 S/MIME Certificates ................................. 198 00425 23.2 S/MIME Key Exchange ................................. 199 00426 23.3 Securing MIME bodies ................................ 201 00427 23.4 SIP Header Privacy and Integrity using S/MIME: 00428 Tunneling SIP .................................................. 203 00429 23.4.1 Integrity and Confidentiality Properties of SIP 00430 Headers ........................................................ 203 00431 23.4.1.1 Integrity ........................................... 204 00432 23.4.1.2 Confidentiality ..................................... 204 00433 23.4.2 Tunneling Integrity and Authentication .............. 205 00434 23.4.3 Tunneling Encryption ................................ 207 00435 24 Examples ............................................ 209 00436 24.1 Registration ........................................ 209 00437 24.2 Session Setup ....................................... 210 00438 25 Augmented BNF for the SIP Protocol ................. 216 00439 25.1 Basic Rules ......................................... 216 00440 26 Security Considerations: Threat Model and Security 00441 00442 00443 00444 J. Rosenberg et. al. [Page f] 00445 Internet Draft SIP February 18, 2002 00446 00447 00448 Usage Recommendations .......................................... 233 00449 26.1 Attacks and Threat Models ........................... 233 00450 26.1.1 Registration Hijacking .............................. 234 00451 26.1.2 Impersonating a Server .............................. 234 00452 26.1.3 Tampering with Message Bodies ....................... 235 00453 26.1.4 Tearing Down Sessions ............................... 236 00454 26.1.5 Denial of Service and Amplification ................. 236 00455 26.2 Security Mechanisms ................................. 237 00456 26.2.1 Transport and Network Layer Security ................ 238 00457 26.2.2 SIPS URI scheme ..................................... 239 00458 26.2.3 HTTP Authentication ................................. 240 00459 26.2.4 S/MIME .............................................. 241 00460 26.3 Implementing Security Mechanisms .................... 241 00461 26.3.1 Requirements for Implementers of SIP ................ 241 00462 26.3.2 Security Solutions .................................. 242 00463 26.3.2.1 Registration ........................................ 242 00464 26.3.2.2 Interdomain Requests ................................ 244 00465 26.3.2.3 Peer to Peer Requests ............................... 246 00466 26.3.2.4 DoS Protection ...................................... 247 00467 26.4 Limitations ......................................... 248 00468 26.4.1 HTTP Digest ......................................... 248 00469 26.4.2 S/MIME .............................................. 248 00470 26.4.3 TLS ................................................. 249 00471 26.4.4 SIPS URIs ........................................... 250 00472 26.5 Privacy ............................................. 250 00473 27 IANA Considerations ................................. 251 00474 27.1 Option Tags ......................................... 252 00475 27.2 Warn-Codes .......................................... 252 00476 27.3 Header Field Names .................................. 253 00477 27.4 Method and Response Codes ........................... 253 00478 27.5 The "application/sip" MIME type. ................... 254 00479 28 Changes From RFC 2543 ............................... 255 00480 28.1 Major Functional Changes ............................ 255 00481 28.2 Minor Functional Changes ............................ 259 00482 29 Acknowledgments ..................................... 260 00483 30 Authors' Addresses .................................. 260 00484 31 Normative References ................................ 262 00485 32 Non-Normative References ............................ 264 00486 A Table of Timer Values ............................... 265 00487 00488 00489 00490 00491 00492 00493 00494 00495 00496 00497 00498 00499 J. Rosenberg et. al. [Page g] 00500 00501 00502 1 Introduction 00503 00504 There are many applications of the Internet that require the creation 00505 and management of a session, where a session is considered an 00506 exchange of data between an association of participants. The 00507 implementation of these applications is complicated by the practices 00508 of participants: users may move between endpoints, they may be 00509 addressable by multiple names, and they may communicate in several 00510 different media - sometimes simultaneously. Numerous protocols have 00511 been authored that carry various forms of real-time multimedia 00512 session data such as voice, video, or text messages. SIP works in 00513 concert with these protocols by enabling Internet endpoints (called 00514 user agents ) to discover one another and to agree on a 00515 characterization of a session they would like to share. For locating 00516 prospective session participants, and for other functions, SIP 00517 enables creation of an infrastructure of network hosts (called proxy 00518 servers ) to which user agents can send registrations, invitations to 00519 sessions, and other requests. SIP is an agile, general-purpose tool 00520 for creating, modifying, and terminating sessions that works 00521 independently of underlying transport protocols and without 00522 dependency on the type of session that is being established. 00523 00524 2 Overview of SIP Functionality 00525 00526 SIP is an application-layer control protocol that can establish, 00527 modify, and terminate multimedia sessions (conferences) such as 00528 Internet telephony calls. SIP can also invite participants to already 00529 existing sessions, such as multicast conferences. Media can be added 00530 to (and removed from) an existing session. SIP transparently supports 00531 name mapping and redirection services, which supports personal 00532 mobility [26] - users can maintain a single externally visible 00533 identifier regardless of their network location. 00534 00535 SIP supports five facets of establishing and terminating multimedia 00536 communications: 00537 00538 User location: determination of the end system to be used for 00539 communication; 00540 00541 User availability: determination of the willingness of the 00542 called party to engage in communications; 00543 00544 User capabilities: determination of the media and media 00545 parameters to be used; 00546 00547 Session setup: "ringing", establishment of session parameters at 00548 both called and calling party; 00549 00550 00551 00552 00553 J. Rosenberg et. al. [Page 3] 00554 Internet Draft SIP February 18, 2002 00555 00556 00557 Session management: including transfer and termination of 00558 sessions, modifying session parameters, and invoking 00559 services. 00560 00561 SIP is not a vertically integrated communications system. SIP is 00562 rather a component that can be used with other IETF protocols to 00563 build a complete multimedia architecture. Typically, these 00564 architectures will include protocols such as the real-time transport 00565 protocol (RTP) (RFC 1889 [27]) for transporting real-time data and 00566 providing QoS feedback, the real-time streaming protocol (RTSP) (RFC 00567 2326 [28]) for controlling delivery of streaming media, the Media 00568 Gateway Control Protocol (MEGACO) (RFC 3015 [29]) for controlling 00569 gateways to the Public Switched Telephone Network (PSTN), and the 00570 session description protocol (SDP) (RFC 2327 [1]) for describing 00571 multimedia sessions. Therefore, SIP should be used in conjunction 00572 with other protocols in order to provide complete services to the 00573 users. However, the basic functionality and operation of SIP does not 00574 depend on any of these protocols. 00575 00576 SIP does not provide services. SIP rather provides primitives that 00577 can be used to implement different services. For example, SIP can 00578 locate a user and deliver an opaque object to his current location. 00579 If this primitive is used to deliver a session description written in 00580 SDP, for instance, the endpoints can agree on the parameters of a 00581 session. If the same primitive is used to deliver a photo of the 00582 caller as well as the session description, a "caller ID" service can 00583 be easily implemented. As this example shows, a single primitive is 00584 typically used to provide several different services. 00585 00586 SIP does not offer conference control services such as floor control 00587 or voting and does not prescribe how a conference is to be managed. 00588 SIP can be used to initiate a session that uses some other conference 00589 control protocol. Since SIP messages and the sessions they establish 00590 can pass through entirely different networks, SIP cannot, and does 00591 not, provide any kind of network resource reservation capabilities. 00592 00593 The nature of the services provided make security particularly 00594 important. To that end, SIP provides a suite of security services, 00595 which include denial-of-service prevention, authentication (both user 00596 to user and proxy to user), integrity protection, and encryption and 00597 privacy services. 00598 00599 SIP works with both IPv4 and IPv6. 00600 00601 3 Terminology 00602 00603 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 00604 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 00605 00606 00607 00608 J. Rosenberg et. al. [Page 4] 00609 Internet Draft SIP February 18, 2002 00610 00611 00612 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 00613 described in RFC 2119 [2] and indicate requirement levels for 00614 compliant SIP implementations. 00615 00616 4 Overview of Operation 00617 00618 This section introduces the basic operations of SIP using simple 00619 examples. This section is tutorial in nature and does not contain any 00620 normative statements. 00621 00622 The first example shows the basic functions of SIP: location of an 00623 end point, signal of a desire to communicate, negotiation of session 00624 parameters to establish the session, and teardown of the session once 00625 established. 00626 00627 Figure 1 shows a typical example of a SIP message exchange between 00628 two users, Alice and Bob. (Each message is labeled with the letter 00629 "F" and a number for reference by the text.) In this example, Alice 00630 uses a SIP application on her PC (referred to as a softphone) to call 00631 Bob on his SIP phone over the Internet. Also shown are two SIP proxy 00632 servers that act on behalf of Alice and Bob to facilitate the session 00633 establishment. This typical arrangement is often referred to as the 00634 "SIP trapezoid" as shown by the geometric shape of the dashed lines 00635 in Figure 1. 00636 00637 00638 Alice "calls" Bob using his SIP identity, a type of Uniform Resource 00639 Identifier (URI) called a SIP URI and which is defined in Section 00640 19.1. It has a similar form to an email address, typically containing 00641 a username and a host name. In this case, it is sip:bob@biloxi.com, 00642 where biloxi.com is the domain of Bob's SIP service provider (which 00643 can be an enterprise, retail provider, etc). Alice also has a SIP URI 00644 of sip:alice@atlanta.com. Alice might have typed in Bob's URI or 00645 perhaps clicked on a hyperlink or an entry in an address book. SIP 00646 also provides a secure URI, called a SIPS URI. An example would be 00647 sips:bob@biloxi.com. A call made to a SIPS URI guarantees that 00648 secure, encrypted transport (namely TLS) is used to carry all SIP 00649 messages at every hop between the caller and callee. 00650 00651 SIP is based on an HTTP-like request/response transaction model. Each 00652 transaction consists of a request that invokes a particular method , 00653 or function, on the server and at least one response. In this 00654 example, the transaction begins with Alice's softphone sending an 00655 INVITE request addressed to Bob's SIP URI. INVITE is an example of a 00656 SIP method that specifies the action that the requestor (Alice) wants 00657 the server (Bob) to take. The INVITE request contains a number of 00658 header fields. Header fields are named attributes that provide 00659 additional information about a message. The ones present in an INVITE 00660 00661 00662 00663 J. Rosenberg et. al. [Page 5] 00664 Internet Draft SIP February 18, 2002 00665 00666 00667 00668 00669 00670 atlanta.com . . . biloxi.com 00671 . proxy proxy . 00672 . . 00673 Alice's . . . . . . . . . . . . . . . . . . . . Bob's 00674 softphone SIP Phone 00675 | | | | 00676 | INVITE F1 | | | 00677 |--------------->| INVITE F2 | | 00678 | 100 Trying F3 |--------------->| INVITE F4 | 00679 |<---------------| 100 Trying F5 |--------------->| 00680 | |<-------------- | 180 Ringing F6 | 00681 | | 180 Ringing F7 |<---------------| 00682 | 180 Ringing F8 |<---------------| 200 OK F9 | 00683 |<---------------| 200 OK F10 |<---------------| 00684 | 200 OK F11 |<---------------| | 00685 |<---------------| | | 00686 | ACK F12 | 00687 |------------------------------------------------->| 00688 | Media Session | 00689 |<================================================>| 00690 | BYE F13 | 00691 |<-------------------------------------------------| 00692 | 200 OK F14 | 00693 |------------------------------------------------->| 00694 | | 00695 00696 00697 00698 00699 Figure 1: SIP session setup example with SIP trapezoid 00700 00701 00702 include a unique identifier for the call, the destination address, 00703 Alice's address, and information about the type of session that Alice 00704 wishes to establish with Bob. The INVITE (message F1 in Figure 1) 00705 might look like this: 00706 00707 00708 INVITE sip:bob@biloxi.com SIP/2.0 00709 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds 00710 Max-Forwards: 70 00711 To: Bob 00712 From: Alice ;tag=1928301774 00713 Call-ID: a84b4c76e66710@pc33.atlanta.com 00714 CSeq: 314159 INVITE 00715 Contact: 00716 00717 00718 00719 J. Rosenberg et. al. [Page 6] 00720 Internet Draft SIP February 18, 2002 00721 00722 00723 Content-Type: application/sdp 00724 Content-Length: 142 00725 00726 (Alice's SDP not shown) 00727 00728 00729 00730 The first line of the text-encoded message contains the method name 00731 (INVITE). The lines that follow are a list of header fields. This 00732 example contains a minimum required set. The header fields are 00733 briefly described below: 00734 00735 Via contains the address (pc33.atlanta.com) at which Alice is 00736 expecting to receive responses to this request. It also contains a 00737 branch parameter that contains an identifier for this transaction. 00738 00739 To contains a display name (Bob) and a SIP or SIPS URI 00740 (sip:bob@biloxi.com) towards which the request was originally 00741 directed. Display names are described in RFC 2822 [3]. 00742 00743 From also contains a display name (Alice) and a SIP or SIPS URI 00744 (sip:alice@atlanta.com) that indicate the originator of the request. 00745 This header field also has a tag parameter containing a pseudorandom 00746 string (1928301774) that was added to the URI by the softphone. It is 00747 used for identification purposes. 00748 00749 Call-ID contains a globally unique identifier for this call, 00750 generated by the combination of a pseudorandom string and the 00751 softphone's IP address. The combination of the To tag, From tag, and 00752 Call-ID completely define a peer-to-peer SIP relationship between 00753 Alice and Bob and is referred to as a dialog 00754 00755 CSeq or Command Sequence contains an integer and a method name. The 00756 CSeq number is incremented for each new request within a dialog and 00757 is a traditional sequence number. 00758 00759 Contact contains a SIP or SIPS URI that represents a direct route to 00760 contact Alice, usually composed of a username at a fully qualified 00761 domain name (FQDN). While an FQDN is preferred, many end systems do 00762 not have registered domain names, so IP addresses are permitted. 00763 While the Via header field tells other elements where to send the 00764 response, the Contact header field tells other elements where to send 00765 future requests. 00766 00767 Max-Forwards serves to limit the number of hops a request can make on 00768 the way to its destination. It consists of an integer that is 00769 decremented by one at each hop. 00770 00771 00772 00773 00774 J. Rosenberg et. al. [Page 7] 00775 Internet Draft SIP February 18, 2002 00776 00777 00778 Content-Type contains a description of the message body (not shown). 00779 00780 Content-Length contains an octet (byte) count of the message body. 00781 00782 The complete set of SIP header fields is defined in Section 20. 00783 00784 The details of the session, type of media, codec, sampling rate, etc. 00785 are not described using SIP. Rather, the body of a SIP message 00786 contains a description of the session, encoded in some other protocol 00787 format. One such format is Session Description Protocol (SDP) [1]. 00788 This SDP message (not shown in the example) is carried by the SIP 00789 message in a way that is analogous to a document attachment being 00790 carried by an email message, or a web page being carried in an HTTP 00791 message. 00792 00793 Since the softphone does not know the location of Bob or the SIP 00794 server in the biloxi.com domain, the softphone sends the INVITE to 00795 the SIP server that serves Alice's domain, atlanta.com. The address 00796 of the atlanta.com SIP server could have been configured in Alice's 00797 softphone, or it could have been discovered by DHCP, for example. 00798 00799 The atlanta.com SIP server is a type of SIP server known as a proxy 00800 server. A proxy server receives SIP requests and forwards them on 00801 behalf of the requestor. In this example, the proxy server receives 00802 the INVITE request and sends a 100 (Trying) response back to Alice's 00803 softphone. The 100 (Trying) response indicates that the INVITE has 00804 been received and that the proxy is working on her behalf to route 00805 the INVITE to the destination. Responses in SIP use a three-digit 00806 code followed by a descriptive phrase. This response contains the 00807 same To, From, Call-ID,CSeq and branch parameter in the Via as the 00808 INVITE, which allows Alice's softphone to correlate this response to 00809 the sent INVITE. The atlanta.com proxy server locates the proxy 00810 server at biloxi.com, possibly by performing a particular type of DNS 00811 (Domain Name Service) lookup to find the SIP server that serves the 00812 biloxi.com domain. This is described in [4]. As a result, it obtains 00813 the IP address of the biloxi.com proxy server and forwards, or 00814 proxies, the INVITE request there. Before forwarding the request, the 00815 atlanta.com proxy server adds an additional Via header field that 00816 contains its own address (the INVITE already contains Alice's address 00817 in the first Via). The biloxi.com proxy server receives the INVITE 00818 and responds with a 100 (Trying) response back to the atlanta.com 00819 proxy server to indicate that it has received the INVITE and is 00820 processing the request. The proxy server consults a database, 00821 generically called a location service, that contains the current IP 00822 address of Bob. (We shall see in the next section how this database 00823 can be populated.) The biloxi.com proxy server adds another Via 00824 header field value with its own address to the INVITE and proxies it 00825 to Bob's SIP phone. 00826 00827 00828 00829 J. Rosenberg et. al. [Page 8] 00830 Internet Draft SIP February 18, 2002 00831 00832 00833 Bob's SIP phone receives the INVITE and alerts Bob to the incoming 00834 call from Alice so that Bob can decide whether to answer the call, 00835 that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 00836 (Ringing) response, which is routed back through the two proxies in 00837 the reverse direction. Each proxy uses the Via header field to 00838 determine where to send the response and removes its own address from 00839 the top. As a result, although DNS and location service lookups were 00840 required to route the initial INVITE, the 180 (Ringing) response can 00841 be returned to the caller without lookups or without state being 00842 maintained in the proxies. This also has the desirable property that 00843 each proxy that sees the INVITE will also see all responses to the 00844 INVITE. 00845 00846 When Alice's softphone receives the 180 (Ringing) response, it passes 00847 this information to Alice, perhaps using an audio ringback tone or by 00848 displaying a message on Alice's screen. 00849 00850 In this example, Bob decides to answer the call. When he picks up the 00851 handset, his SIP phone sends a 200 (OK) response to indicate that the 00852 call has been answered. The 200 (OK) contains a message body with the 00853 SDP media description of the type of session that Bob is willing to 00854 establish with Alice. As a result, there is a two-phase exchange of 00855 SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. 00856 This two-phase exchange provides basic negotiation capabilities and 00857 is based on a simple offer/answer model of SDP exchange. If Bob did 00858 not wish to answer the call or was busy on another call, an error 00859 response would have been sent instead of the 200 (OK), which would 00860 have resulted in no media session being established. The complete 00861 list of SIP response codes is in Section 21. The 200 (OK) (message F9 00862 in Figure 1) might look like this as Bob sends it out: 00863 00864 00865 SIP/2.0 200 OK 00866 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8 00867 ;received=10.2.1.1 00868 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 00869 ;received=10.1.1.1 00870 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds 00871 ;received=10.1.3.3 00872 To: Bob ;tag=a6c85cf 00873 From: Alice ;tag=1928301774 00874 Call-ID: a84b4c76e66710 00875 CSeq: 314159 INVITE 00876 Contact: 00877 Content-Type: application/sdp 00878 Content-Length: 131 00879 00880 (Bob's SDP not shown) 00881 00882 00883 00884 J. Rosenberg et. al. [Page 9] 00885 Internet Draft SIP February 18, 2002 00886 00887 00888 The first line of the response contains the response code (200) and 00889 the reason phrase (OK). The remaining lines contain header fields. 00890 The Via, To, From, Call-ID, and CSeq header fields are copied from 00891 the INVITE request. (There are three Via header field values - one 00892 added by Alice's SIP phone, one added by the atlanta.com proxy, and 00893 one added by the biloxi.com proxy.) Bob's SIP phone has added a tag 00894 parameter to the To header field. This tag will be incorporated by 00895 both endpoints into the dialog and will be included in all future 00896 requests and responses in this call. The Contact header field 00897 contains a URI at which Bob can be directly reached at his SIP phone. 00898 The Content-Type and Content-Length refer to the message body (not 00899 shown) that contains Bob's SDP media information. 00900 00901 In addition to DNS and location service lookups shown in this 00902 example, proxy servers can make flexible "routing decisions" to 00903 decide where to send a request. For example, if Bob's SIP phone 00904 returned a 486 (Busy Here) response, the biloxi.com proxy server 00905 could proxy the INVITE to Bob's voicemail server. A proxy server can 00906 also send an INVITE to a number of locations at the same time. This 00907 type of parallel search is known as forking 00908 00909 In this case, the 200 (OK) is routed back through the two proxies and 00910 is received by Alice's softphone, which then stops the ringback tone 00911 and indicates that the call has been answered. Finally, Alice's 00912 softphone sends an acknowledgement message, ACK to Bob's SIP phone to 00913 confirm the reception of the final response (200 (OK)). In this 00914 example, the ACK is sent directly from Alice's softphone to Bob's SIP 00915 phone, bypassing the two proxies. This occurs because the endpoints 00916 have learned each other's address from the Contact header fields 00917 through the INVITE/200 (OK) exchange, which was not known when the 00918 initial INVITE was sent. The lookups performed by the two proxies are 00919 no longer needed, so the proxies drop out of the call flow. This 00920 completes the INVITE/200/ACK three-way handshake used to establish 00921 SIP sessions. Full details on session setup are in Section 13. 00922 00923 Alice and Bob's media session has now begun, and they send media 00924 packets using the format to which they agreed in the exchange of SDP. 00925 In general, the end-to-end media packets take a different path from 00926 the SIP signaling messages. 00927 00928 During the session, either Alice or Bob may decide to change the 00929 characteristics of the media session. This is accomplished by sending 00930 a re-INVITE containing a new media description. This re-INVITE 00931 references the existing dialog so that the other party knows that it 00932 is to modify an existing session instead of establishing a new 00933 session. The other party sends a 200 (OK) to accept the change. The 00934 requestor responds to the 200 (OK) with an ACK. If the other party 00935 does not accept the change, he sends an error response such as 406 00936 00937 00938 00939 J. Rosenberg et. al. [Page 10] 00940 Internet Draft SIP February 18, 2002 00941 00942 00943 (Not Acceptable), which also receives an ACK. However, the failure of 00944 the re-INVITE does not cause the existing call to fail - the session 00945 continues using the previously negotiated characteristics. Full 00946 details on session modification are in Section 14. 00947 00948 At the end of the call, Bob disconnects (hangs up) first and 00949 generates a BYE message. This BYE is routed directly to Alice's 00950 softphone, again bypassing the proxies. Alice confirms receipt of the 00951 BYE with a 200 (OK) response, which terminates the session and the 00952 BYE transaction. No ACK is sent - an ACK is only sent in response to 00953 a response to an INVITE request. The reasons for this special 00954 handling for INVITE will be discussed later, but relate to the 00955 reliability mechanisms in SIP, the length of time it can take for a 00956 ringing phone to be answered, and forking. For this reason, request 00957 handling in SIP is often classified as either INVITE or non-INVITE, 00958 referring to all other methods besides INVITE. Full details on 00959 session termination are in Section 15. 00960 00961 Full details of all the messages shown in the example of Figure 1 are 00962 shown in Section 24.2. 00963 00964 In some cases, it may be useful for proxies in the SIP signaling path 00965 to see all the messaging between the endpoints for the duration of 00966 the session. For example, if the biloxi.com proxy server wished to 00967 remain in the SIP messaging path beyond the initial INVITE, it would 00968 add to the INVITE a required routing header field known as Record- 00969 Route that contained a URI resolving to the hostname or IP address of 00970 the proxy. This information would be received by both Bob's SIP phone 00971 and (due to the Record-Route header field being passed back in the 00972 200 (OK)) Alice's softphone and stored for the duration of the 00973 dialog. The biloxi.com proxy server would then receive and proxy the 00974 ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently 00975 decide to receive subsequent messaging, and that messaging will go 00976 through all proxies that elect to receive it. This capability is 00977 frequently used for proxies that are providing mid-call features. 00978 00979 Registration is another common operation in SIP. Registration is one 00980 way that the biloxi.com server can learn the current location of Bob. 00981 Upon initialization, and at periodic intervals, Bob's SIP phone sends 00982 REGISTER messages to a server in the biloxi.com domain known as a SIP 00983 registrar. The REGISTER messages associate Bob's SIP or SIPS URI 00984 (sip:bob@biloxi.com) with the machine into which he is currently 00985 logged (conveyed as a SIP or SIPS URI in the Contact header field). 00986 The registrar writes this association, also called a binding, to a 00987 database, called the location service , where it can be used by the 00988 proxy in the biloxi.com domain. Often, a registrar server for a 00989 domain is co-located with the proxy for that domain. It is an 00990 important concept that the distinction between types of SIP servers 00991 00992 00993 00994 J. Rosenberg et. al. [Page 11] 00995 Internet Draft SIP February 18, 2002 00996 00997 00998 is logical, not physical. 00999 01000 Bob is not limited to registering from a single device. For example, 01001 both his SIP phone at home and the one in the office could send 01002 registrations. This information is stored together in the location 01003 service and allows a proxy to perform various types of searches to 01004 locate Bob. Similarly, more than one user can be registered on a 01005 single device at the same time. 01006 01007 The location service is just an abstract concept. It generally 01008 contains information that allows a proxy to input a URI and receive a 01009 set of zero or more URIs that tell the proxy where to send the 01010 request. Registrations are one way to create this information, but 01011 not the only way. Arbitrary mapping functions can be configured at 01012 the discretion of the administrator. 01013 01014 Finally, it is important to note that in SIP, registration is used 01015 for routing incoming SIP requests and has no role in authorizing 01016 outgoing requests. Authorization and authentication are handled in 01017 SIP either on a request-by-request basis with a challenge/response 01018 mechanism, or by using a lower layer scheme as discussed in Section 01019 26. 01020 01021 The complete set of SIP message details for this registration example 01022 is in Section 24.1. 01023 01024 Additional operations in SIP, such as querying for the capabilities 01025 of a SIP server or client using OPTIONS, or canceling a pending 01026 request using CANCEL, will be introduced in later sections. 01027 01028 5 Structure of the Protocol 01029 01030 SIP is structured as a layered protocol, which means that its 01031 behavior is described in terms of a set of fairly independent 01032 processing stages with only a loose coupling between each stage. The 01033 protocol behavior is described as layers for the purpose of 01034 presentation, allowing the description of functions common across 01035 elements in a single section. It does not dictate an implementation 01036 in any way. When we say that an element "contains" a layer, we mean 01037 it is compliant to the set of rules defined by that layer. 01038 01039 Not every element specified by the protocol contains every layer. 01040 Furthermore, the elements specified by SIP are logical elements, not 01041 physical ones. A physical realization can choose to act as different 01042 logical elements, perhaps even on a transaction-by-transaction basis. 01043 01044 The lowest layer of SIP is its syntax and encoding. Its encoding is 01045 specified using an augmented Backus-Naur Form grammar (BNF). The 01046 01047 01048 01049 J. Rosenberg et. al. [Page 12] 01050 Internet Draft SIP February 18, 2002 01051 01052 01053 complete BNF is specified in Section 25; an overview of a SIP 01054 message's structure can be found in Section 7. 01055 01056 The second layer is the transport layer. It defines how a client 01057 sends requests and receives responses and how a server receives 01058 requests and sends responses over the network. All SIP elements 01059 contain a transport layer. The transport layer is described in 01060 Section 18. 01061 01062 The third layer is the transaction layer. Transactions are a 01063 fundamental component of SIP. A transaction is a request sent by a 01064 client transaction (using the transport layer) to a server 01065 transaction, along with all responses to that request sent from the 01066 server transaction back to the client. The transaction layer handles 01067 application-layer retransmissions, matching of responses to requests, 01068 and application-layer timeouts. Any task that a user agent client 01069 (UAC) accomplishes takes place using a series of transactions. 01070 Discussion of transactions can be found in Section 17. User agents 01071 contain a transaction layer, as do stateful proxies. Stateless 01072 proxies do not contain a transaction layer. The transaction layer has 01073 a client component (referred to as a client transaction) and a server 01074 component (referred to as a server transaction), each of which are 01075 represented by a finite state machine that is constructed to process 01076 a particular request. 01077 01078 The layer above the transaction layer is called the transaction user 01079 (TU). Each of the SIP entities, except the stateless proxy, is a 01080 transaction user. When a TU wishes to send a request, it creates a 01081 client transaction instance and passes it the request along with the 01082 destination IP address, port, and transport to which to send the 01083 request. A TU that creates a client transaction can also cancel it. 01084 When a client cancels a transaction, it requests that the server stop 01085 further processing, revert to the state that existed before the 01086 transaction was initiated, and generate a specific error response to 01087 that transaction. This is done with a CANCEL request, which 01088 constitutes its own transaction, but references the transaction to be 01089 cancelled (Section 9). 01090 01091 The SIP elements, that is, user agent clients and servers, stateless 01092 and stateful proxies and registrars, contain a core that 01093 distinguishes them from each other. Cores, except for the stateless 01094 proxy, are transaction users. While the behavior of the UAC and UAS 01095 cores depends on the method, there are some common rules for all 01096 methods (Section 8). For a UAC, these rules govern the construction 01097 of a request; for a UAS, they govern the processing of a request and 01098 generating a response. Since registrations play an important role in 01099 SIP, a UAS that handles a REGISTER is given the special name 01100 registrar. Section 10 describes UAC and UAS core behavior for the 01101 01102 01103 01104 J. Rosenberg et. al. [Page 13] 01105 Internet Draft SIP February 18, 2002 01106 01107 01108 REGISTER method. Section 11 describes UAC and UAS core behavior for 01109 the OPTIONS method, used for determining the capabilities of a UA. 01110 01111 Certain other requests are sent within a dialog. A dialog is a peer- 01112 to-peer SIP relationship between two user agents that persists for 01113 some time. The dialog facilitates sequencing of messages and proper 01114 routing of requests between the user agents. The INVITE method is the 01115 only way defined in this specification to establish a dialog. When a 01116 UAC sends a request that is within the context of a dialog, it 01117 follows the common UAC rules as discussed in Section 8 but also the 01118 rules for mid-dialog requests. Section 12 discusses dialogs and 01119 presents the procedures for their construction and maintenance, in 01120 addition to construction of requests within a dialog. 01121 01122 The most important method in SIP is the INVITE method, which is used 01123 to establish a session between participants. A session is a 01124 collection of participants, and streams of media between them, for 01125 the purposes of communication. Section 13 discusses how sessions are 01126 initiated, resulting in one or more SIP dialogs. Section 14 discusses 01127 how characteristics of that session are modified through the use of 01128 an INVITE request within a dialog. Finally, section 15 discusses how 01129 a session is terminated. 01130 01131 The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal 01132 entirely with the UA core (Section 9 describes cancellation, which 01133 applies to both UA core and proxy core). Section 16 discusses the 01134 proxy element, which facilitates routing of messages between user 01135 agents. 01136 01137 6 Definitions 01138 01139 This specification uses a number of terms to refer to the roles 01140 played by participants in SIP communications. The terms and generic 01141 syntax of URI and URL are defined in RFC 2396 [5]. The following 01142 terms have special significance for SIP. 01143 01144 Address-of-Record: An address-of-record (AOR) is a SIP or SIPS 01145 URI that points to a domain with a location service that 01146 can map the URI to another URI where the user might be 01147 available. Typically, the location service is populated 01148 through registrations. An AOR is frequently thought of as 01149 the "public address" of the user. 01150 01151 Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a 01152 logical entity that receives a request and processes it as 01153 an user agent server (UAS). In order to determine how the 01154 request should be answered, it acts as an user agent client 01155 (UAC) and generates requests. Unlike a proxy server, it 01156 01157 01158 01159 J. Rosenberg et. al. [Page 14] 01160 Internet Draft SIP February 18, 2002 01161 01162 01163 maintains dialog state and must participate in all requests 01164 sent on the dialogs it has established. Since it is a 01165 concatenation of a UAC and UAS, no explicit definitions are 01166 needed for its behavior. 01167 01168 Call: A call is an informal term that refers to some 01169 communication between peers generally set up for the 01170 purposes of a multimedia conversation. 01171 01172 Call Leg: Another name for a dialog [30]; no longer used in this 01173 specification. 01174 01175 Call Stateful: A proxy is call stateful if it retains state for 01176 a dialog from the initiating INVITE to the terminating BYE 01177 request. A call stateful proxy is always transaction 01178 stateful, but the converse is not necessarily true. 01179 01180 Client: A client is any network element that sends SIP requests 01181 and receives SIP responses. Clients may or may not interact 01182 directly with a human user. User agent clients and proxies 01183 are clients. 01184 01185 Conference: A multimedia session (see below) that contains 01186 multiple participants. 01187 01188 Core: Core designates the functions specific to a particular 01189 type of SIP entity, i.e., specific to either a stateful or 01190 stateless proxy, a user agent or registrar. All cores 01191 except those for the stateless proxy are transaction users. 01192 01193 Dialog: A dialog is a peer-to-peer SIP relationship between two 01194 UAs that persists for some time. A dialog is established by 01195 SIP messages, such as a 2xx response to an INVITE request. 01196 A dialog is identified by a call identifier, local address, 01197 and remote address. A dialog was formerly known as a call 01198 leg in RFC 2543. 01199 01200 Downstream: A direction of message forwarding within a 01201 transaction that refers to the direction that requests flow 01202 from the user agent client to user agent server. 01203 01204 Final Response: A response that terminates a SIP transaction, as 01205 opposed to a provisional response that does not. All 2xx, 01206 3xx, 4xx, 5xx and 6xx responses are final. 01207 01208 Header: A header is a component of a SIP message that conveys 01209 information about the message. It is structured as a 01210 sequence of header fields. 01211 01212 01213 01214 J. Rosenberg et. al. [Page 15] 01215 Internet Draft SIP February 18, 2002 01216 01217 01218 Header field: A header field is a component of the SIP message 01219 header. It consists of one or more header field values 01220 separated by comma or having the same header field name. 01221 01222 Header field value: A header field value consists of a field 01223 name and a field value, separated by a colon. 01224 01225 Home Domain: The domain providing service to a SIP user. 01226 Typically, this is the domain present in the URI in the 01227 address-of-record of a registration. 01228 01229 Informational Response: Same as a provisional response. 01230 01231 Initiator, Calling Party, Caller: The party initiating a session 01232 (and dialog) with an INVITE request. A caller retains this 01233 role from the time it sends the initial INVITE that 01234 established a dialog until the termination of that dialog. 01235 01236 Invitation: An INVITE request. 01237 01238 Invitee, Invited User, Called Party, Callee: The party that 01239 receives an INVITE request for the purposes of establishing 01240 a new session. A callee retains this role from the time it 01241 receives the INVITE until the termination of the dialog 01242 established by that INVITE. 01243 01244 Location Service: A location service is used by a SIP redirect 01245 or proxy server to obtain information about a callee's 01246 possible location(s). It contains a list of bindings of 01247 address-of-record keys to zero or more contact addresses. 01248 The bindings can be created and removed in many ways; this 01249 specification defines a REGISTER method that updates the 01250 bindings. 01251 01252 Loop: A request that arrives at a proxy, is forwarded, and later 01253 arrives back at the same proxy. When it arrives the second 01254 time, its Request-URI is identical to the first time, and 01255 other header fields that affect proxy operation are 01256 unchanged, so that the proxy would make the same processing 01257 decision on the request it made the first time. Looped 01258 requests are errors, and the procedures for detecting them 01259 and handling them are described by the protocol. 01260 01261 Loose Routing: A proxy is said to be loose routing if it follows 01262 the procedures defined in this specification for processing 01263 of the Route header field. These procedures separate the 01264 destination of the request (present in the Request-URI) 01265 from the set of proxies that need to be visited along the 01266 01267 01268 01269 J. Rosenberg et. al. [Page 16] 01270 Internet Draft SIP February 18, 2002 01271 01272 01273 way (present in the Route header field). A proxy compliant 01274 to these mechanisms is also known as a loose router. 01275 01276 Message: Data sent between SIP elements as part of the protocol. 01277 SIP messages are either requests or responses. 01278 01279 Method: The method is the primary function that a request is 01280 meant to invoke on a server. The method is carried in the 01281 request message itself. Example methods are INVITE and BYE. 01282 01283 Outbound Proxy: A proxy that receives requests from a client, 01284 even though it may not be the server resolved by the 01285 Request-URI. Typically, a UA is manually configured with 01286 an outbound proxy, or can learn about one through auto- 01287 configuration protocols. 01288 01289 Parallel Search: In a parallel search, a proxy issues several 01290 requests to possible user locations upon receiving an 01291 incoming request. Rather than issuing one request and then 01292 waiting for the final response before issuing the next 01293 request as in a sequential search , a parallel search 01294 issues requests without waiting for the result of previous 01295 requests. 01296 01297 Provisional Response: A response used by the server to indicate 01298 progress, but that does not terminate a SIP transaction. 01299 1xx responses are provisional, other responses are 01300 considered final. Provisional responses are not sent 01301 reliably. 01302 01303 Proxy, Proxy Server: An intermediary entity that acts as both a 01304 server and a client for the purpose of making requests on 01305 behalf of other clients. A proxy server primarily plays the 01306 role of routing, which means its job is to ensure that a 01307 request is sent to another entity "closer" to the targeted 01308 user. Proxies are also useful for enforcing policy (for 01309 example, making sure a user is allowed to make a call). A 01310 proxy interprets, and, if necessary, rewrites specific 01311 parts of a request message before forwarding it. 01312 01313 Recursion: A client recurses on a 3xx response when it generates 01314 a new request to one or more of the URIs in the Contact 01315 header field in the response. 01316 01317 Redirect Server: A redirect server is a user agent server that 01318 generates 3xx responses to requests it receives, directing 01319 the client to contact an alternate set of URIs. 01320 01321 01322 01323 01324 J. Rosenberg et. al. [Page 17] 01325 Internet Draft SIP February 18, 2002 01326 01327 01328 Registrar: A registrar is a server that accepts REGISTER 01329 requests and places the information it receives in those 01330 requests into the location service for the domain it 01331 handles. 01332 01333 Regular Transaction: A regular transaction is any transaction 01334 with a method other than INVITE, ACK, or CANCEL. 01335 01336 Request: A SIP message sent from a client to a server, for the 01337 purpose of invoking a particular operation. 01338 01339 Response: A SIP message sent from a server to a client, for 01340 indicating the status of a request sent from the client to 01341 the server. 01342 01343 Ringback: Ringback is the signaling tone produced by the calling 01344 party's application indicating that a called party is being 01345 alerted (ringing). 01346 01347 Route Set: A route set is a collection of ordered SIP or SIPS 01348 URI which represent a list of proxies that must be 01349 traversed when sending a particular request. A route set 01350 can be learned, through headers like Record-Route, or it 01351 can be configured. 01352 01353 Server: A server is a network element that receives requests in 01354 order to service them and sends back responses to those 01355 requests. Examples of servers are proxies, user agent 01356 servers, redirect servers, and registrars. 01357 01358 Sequential Search: In a sequential search, a proxy server 01359 attempts each contact address in sequence, proceeding to 01360 the next one only after the previous has generated a final 01361 response. A 2xx or 6xx class final response always 01362 terminates a sequential search. 01363 01364 Session: From the SDP specification: "A multimedia session is a 01365 set of multimedia senders and receivers and the data 01366 streams flowing from senders to receivers. A multimedia 01367 conference is an example of a multimedia session." (RFC 01368 2327 [1]) (A session as defined for SDP can comprise one or 01369 more RTP sessions.) As defined, a callee can be invited 01370 several times, by different calls, to the same session. If 01371 SDP is used, a session is defined by the concatenation of 01372 the SDP user name , session id , network type , address 01373 type , and address elements in the origin field. 01374 01375 SIP Transaction: A SIP transaction occurs between a client and a 01376 01377 01378 01379 J. Rosenberg et. al. [Page 18] 01380 Internet Draft SIP February 18, 2002 01381 01382 01383 server and comprises all messages from the first request 01384 sent from the client to the server up to a final (non-1xx) 01385 response sent from the server to the client. If the 01386 request is INVITE and the final response is a non-2xx, the 01387 transaction also includes an ACK to the response. The ACK 01388 for a 2xx response to an INVITE request is a separate 01389 transaction. 01390 01391 Spiral: A spiral is a SIP request that is routed to a proxy, 01392 forwarded onwards, and arrives once again at that proxy, 01393 but this time differs in a way that will result in a 01394 different processing decision than the original request. 01395 Typically, this means that the request's Request-URI 01396 differs from its previous arrival. A spiral is not an error 01397 condition, unlike a loop. A typical cause for this is call 01398 forwarding. A user calls joe@example.com. The example.com 01399 proxy forwards it to Joe's PC, which in turn, forwards it 01400 to bob@example.com. This request is proxied back to the 01401 example.com proxy. However, this is not a loop. Since the 01402 request is targeted at a different user, it is considered a 01403 spiral, and is a valid condition. 01404 01405 Stateful Proxy: A logical entity that maintains the client and 01406 server transaction state machines defined by this 01407 specification during the processing of a request. Also 01408 known as a transaction stateful proxy. The behavior of a 01409 stateful proxy is further defined in Section 16. A 01410 (transaction) stateful proxy is not the same as a call 01411 stateful proxy. 01412 01413 Stateless Proxy: A logical entity that does not maintain the 01414 client or server transaction state machines defined in this 01415 specification when it processes requests. A stateless proxy 01416 forwards every request it receives downstream and every 01417 response it receives upstream. 01418 01419 Strict Routing: A proxy is said to be strict routing if it 01420 follows the Route processing rules of RFC 2543 and many 01421 prior Internet Draft versions of this RFC. That rule caused 01422 proxies to destroy the contents of the Request-URI when a 01423 Route header field was present. Strict routing behavior is 01424 not used in this specification, in favor of a loose routing 01425 behavior. Proxies that perform strict routing are also 01426 known as strict routers. 01427 01428 Target Refresh Request: A target refresh request sent within a 01429 dialog is defined as a request that can modify the remote 01430 target of the dialog. 01431 01432 01433 01434 J. Rosenberg et. al. [Page 19] 01435 Internet Draft SIP February 18, 2002 01436 01437 01438 Transaction User (TU): The layer of protocol processing that 01439 resides above the transaction layer. Transaction users 01440 include the UAC core, UAS core, and proxy core. 01441 01442 Upstream: A direction of message forwarding within a transaction 01443 that refers to the direction that responses flow from the 01444 user agent server back to the user agent client. 01445 01446 URL-encoded: A character string encoded according to RFC 1738, 01447 Section 2.2 [6]. 01448 01449 User Agent Client (UAC): A user agent client is a logical entity 01450 that creates a new request, and then uses the client 01451 transaction state machinery to send it. The role of UAC 01452 lasts only for the duration of that transaction. In other 01453 words, if a piece of software initiates a request, it acts 01454 as a UAC for the duration of that transaction. If it 01455 receives a request later, it assumes the role of a user 01456 agent server for the processing of that transaction. 01457 01458 UAC Core: The set of processing functions required of a UAC that 01459 reside above the transaction and transport layers. 01460 01461 User Agent Server (UAS): A user agent server is a logical entity 01462 that generates a response to a SIP request. The response 01463 accepts, rejects, or redirects the request. This role lasts 01464 only for the duration of that transaction. In other words, 01465 if a piece of software responds to a request, it acts as a 01466 UAS for the duration of that transaction. If it generates a 01467 request later, it assumes the role of a user agent client 01468 for the processing of that transaction. 01469 01470 UAS Core: The set of processing functions required at a UAS that 01471 reside above the transaction and transport layers. 01472 01473 User Agent (UA): A logical entity that can act as both a user 01474 agent client and user agent server. 01475 01476 The role of UAC and UAS as well as proxy and redirect servers are 01477 defined on a transaction-by-transaction basis. For example, the user 01478 agent initiating a call acts as a UAC when sending the initial INVITE 01479 request and as a UAS when receiving a BYE request from the callee. 01480 Similarly, the same software can act as a proxy server for one 01481 request and as a redirect server for the next request. 01482 01483 Proxy, location, and registrar servers defined above are logical 01484 entities; implementations MAY combine them into a single application. 01485 01486 01487 01488 01489 J. Rosenberg et. al. [Page 20] 01490 Internet Draft SIP February 18, 2002 01491 01492 01493 7 SIP Messages 01494 01495 SIP is a text-based protocol and uses the ISO 10646 character set in 01496 UTF-8 encoding (RFC 2279 [7]). 01497 01498 A SIP message is either a request from a client to a server, or a 01499 response from a server to a client. 01500 01501 Both Request (section 7.1) and Response (section 7.2) messages use 01502 the basic format of RFC 2822 [3], even though the syntax differs in 01503 character set and syntax specifics. (SIP allows header fields that 01504 would not be valid RFC 2822 header fields, for example.) Both types 01505 of messages consist of a start-line, one or more header fields, an 01506 empty line indicating the end of the header fields, and an optional 01507 message-body. 01508 01509 01510 01511 generic-message = start-line 01512 *message-header 01513 CRLF 01514 [ message-body ] 01515 start-line = Request-Line / Status-Line 01516 01517 01518 The start-line, each message-header line, and the empty line MUST be 01519 terminated by a carriage-return line-feed sequence (CRLF). Note that 01520 the empty line MUST be present even if the message-body is not. 01521 01522 Except for the above difference in character sets, much of SIP's 01523 message and header field syntax is identical to HTTP/1.1. Rather than 01524 repeating the syntax and semantics here, we use [HX.Y] to refer to 01525 Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). 01526 01527 However, SIP is not an extension of HTTP. 01528 01529 7.1 Requests 01530 01531 SIP requests are distinguished by having a Request-Line for a start- 01532 line. A Request-Line contains a method name, a Request-URI, and the 01533 protocol version separated by a single space (SP) character. 01534 01535 The Request-Line ends with CRLF. No CR or LF are allowed except in 01536 the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed 01537 in any of the elements. 01538 01539 01540 01541 01542 01543 01544 J. Rosenberg et. al. [Page 21] 01545 Internet Draft SIP February 18, 2002 01546 01547 01548 Request-Line = Method SP Request-URI SP SIP-Version CRLF 01549 01550 01551 Method: 01552 01553 This specification defines six methods: REGISTER for 01554 registering contact information, INVITE, ACK, and CANCEL 01555 for setting up sessions, BYE for terminating sessions, and 01556 OPTIONS for querying servers about their capabilities. SIP 01557 extensions, documented in standards track RFCs, may define 01558 additional methods. 01559 01560 Request-URI: The Request-URI is a SIP or SIPS URI as described 01561 in Section 19.1 or a general URI (RFC 2396 [5]). It 01562 indicates the user or service to which this request is 01563 being addressed. The Request-URI MUST NOT contain unescaped 01564 spaces or control characters and MUST NOT be enclosed in 01565 "<>". 01566 01567 SIP elements MAY support Request-URIs with schemes other 01568 than "sip" and "sips", for example the "tel" URI scheme of 01569 RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using 01570 any mechanism at their disposal, resulting in either SIP 01571 URI, SIPS URI, or some other scheme. 01572 01573 SIP-Version: Both request and response messages include the 01574 version of SIP in use, and follow [H3.1] (with HTTP 01575 replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) 01576 regarding version ordering, compliance requirements, and 01577 upgrading of version numbers. To be compliant with this 01578 specification, applications sending SIP messages MUST 01579 include a SIP-Version of "SIP/2.0". The SIP-Version string 01580 is case-insensitive, but implementations MUST send upper- 01581 case. 01582 01583 01584 Unlike HTTP/1.1, SIP treats the version number as a 01585 literal string. In practice, this should make no 01586 difference. 01587 01588 7.2 Responses 01589 01590 SIP responses are distinguished from requests by having a Status-Line 01591 as their start-line. A Status-Line consists of the protocol version 01592 followed by a numeric Status-Code and its associated textual phrase, 01593 with each element separated by a single SP character. 01594 01595 No CR or LF is allowed except in the final CRLF sequence. 01596 01597 01598 01599 J. Rosenberg et. al. [Page 22] 01600 Internet Draft SIP February 18, 2002 01601 01602 01603 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF 01604 01605 01606 The Status-Code is a 3-digit integer result code that indicates the 01607 outcome of an attempt to understand and satisfy a request. The 01608 Reason-Phrase is intended to give a short textual description of the 01609 Status-Code. The Status-Code is intended for use by automata, whereas 01610 the Reason-Phrase is intended for the human user. A client is not 01611 required to examine or display the Reason-Phrase. 01612 01613 While this specification suggests specific wording for the reason 01614 phrase, implementations MAY choose other text, for example, in the 01615 language indicated in the Accept-Language header field of the 01616 request. 01617 01618 The first digit of the Status-Code defines the class of response. The 01619 last two digits do not have any categorization role. For this reason, 01620 any response with a status code between 100 and 199 is referred to as 01621 a "1xx response", any response with a status code between 200 and 299 01622 as a "2xx response", and so on. SIP/2.0 allows six values for the 01623 first digit: 01624 01625 1xx: Provisional -- request received, continuing to process the 01626 request; 01627 01628 2xx: Success -- the action was successfully received, 01629 understood, and accepted; 01630 01631 3xx: Redirection -- further action needs to be taken in order to 01632 complete the request; 01633 01634 4xx: Client Error -- the request contains bad syntax or cannot 01635 be fulfilled at this server; 01636 01637 5xx: Server Error -- the server failed to fulfill an apparently 01638 valid request; 01639 01640 6xx: Global Failure -- the request cannot be fulfilled at any 01641 server. 01642 01643 Section 21 defines these classes and describes the individual codes. 01644 01645 7.3 Header Fields 01646 01647 SIP header fields are similar to HTTP header fields in both syntax 01648 and semantics. In particular, SIP header fields follow the [H4.2] 01649 definitions of syntax for message-header and the rules for extending 01650 header fields over multiple lines. However, the latter is specified 01651 01652 01653 01654 J. Rosenberg et. al. [Page 23] 01655 Internet Draft SIP February 18, 2002 01656 01657 01658 in HTTP with implicit whitespace and folding. This specification 01659 conforms with RFC 2234 [10] and uses only explicit whitespace and 01660 folding as an integral part of the grammar. 01661 01662 [H4.2] also specifies that multiple header fields of the same field 01663 name whose value is a comma-separated list can be combined into one 01664 header field. That applies to SIP as well, but the specific rule is 01665 different because of the different grammars. Specifically, any SIP 01666 header whose grammar is of the form: 01667 01668 01669 01670 header = "header-name" HCOLON header-value *(COMMA header-value) 01671 01672 01673 allows for combining header fields of the same name into a comma- 01674 separated list. This is also true for the Contact header, as long as 01675 none of the header field values are "*". 01676 01677 7.3.1 Header Field Format 01678 01679 Header fields follow the same generic header format as that given in 01680 Section 2.2 of RFC 2822 [3]. Each header field consists of a field 01681 name followed by a colon (":") and the field value. 01682 field-name: field-value 01683 The formal grammar for a message-header specified in Section 25 01684 allows for an arbitrary amount of whitespace on either side of the 01685 colon; however, implementations should avoid spaces between the field 01686 name and the colon and use a single space (SP) between the colon and 01687 the field-value. Thus, 01688 01689 Subject: lunch 01690 Subject : lunch 01691 Subject :lunch 01692 Subject: lunch 01693 01694 01695 are all valid and equivalent, but the last is the preferred form. 01696 01697 Header fields can be extended over multiple lines by preceding each 01698 extra line with at least one SP or horizontal tab (HT). The line 01699 break and the whitespace at the beginning of the next line are 01700 treated as a single SP character. Thus, the following are equivalent: 01701 01702 01703 Subject: I know you're there, pick up the phone and talk to me! 01704 Subject: I know you're there, 01705 pick up the phone 01706 01707 01708 01709 J. Rosenberg et. al. [Page 24] 01710 Internet Draft SIP February 18, 2002 01711 01712 01713 and talk to me! 01714 01715 01716 01717 The relative order of header fields with different field names is not 01718 significant. However, it is RECOMMENDED that header fields which are 01719 needed for proxy processing (Via, Route, Record-Route, Proxy-Require, 01720 Max-Forwards, and Proxy-Authorization, for example) appear towards 01721 the top of the message to facilitate rapid parsing. The relative 01722 order of header field rows with the same field name is important. 01723 Multiple header field rows with the same field-name MAY be present in 01724 a message if and only if the entire field-value for that header field 01725 is defined as a comma-separated list (that is, if follows the grammar 01726 defined in Section 7.3). It MUST be possible to combine the multiple 01727 header field rows into one "field-name: field-value" pair, without 01728 changing the semantics of the message, by appending each subsequent 01729 field-value to the first, each separated by a comma. The exceptions 01730 to this rule are the WWW-Authenticate, Authorization, Proxy- 01731 Authenticate, and Proxy-Authorization header fields. Multiple header 01732 field rows with these names MAY be present in a message, but since 01733 their grammar does not follow the general form listed in Section 7.3, 01734 they MUST NOT be combined into a single header field row. 01735 01736 Implementations MUST be able to process multiple header field rows 01737 with the same name in any combination of the single-value-per-line or 01738 comma-separated value forms. 01739 01740 The following groups of header field rows are valid and equivalent: 01741 01742 Route: 01743 Subject: Lunch 01744 Route: 01745 Route: 01746 01747 Route: , 01748 Route: 01749 Subject: Lunch 01750 01751 Subject: Lunch 01752 Route: , , 01753 01754 01755 01756 Each of the following blocks is valid but not equivalent to the 01757 others: 01758 01759 Route: 01760 Route: 01761 01762 01763 01764 J. Rosenberg et. al. [Page 25] 01765 Internet Draft SIP February 18, 2002 01766 01767 01768 Route: 01769 01770 Route: 01771 Route: 01772 Route: 01773 01774 Route: ,, 01775 01776 01777 01778 The format of a header field-value is defined per header-name. It 01779 will always be either an opaque sequence of TEXT-UTF8 octets, or a 01780 combination of whitespace, tokens, separators, and quoted strings. 01781 Many existing header fields will adhere to the general form of a 01782 value followed by a semi-colon separated sequence of parameter-name, 01783 parameter-value pairs: 01784 field-name: field-value *(;parameter-name=parameter-value) 01785 01786 Even though an arbitrary number of parameter pairs may be attached to 01787 a header field value, any given parameter-name MUST NOT appear more 01788 than once. 01789 01790 When comparing header fields, field names are always case- 01791 insensitive. Unless otherwise stated in the definition of a 01792 particular header field, field values, parameter names, and parameter 01793 values are case-insensitive. Tokens are always case-insensitive. 01794 Unless specified otherwise, values expressed as quoted strings are 01795 case-sensitive. 01796 01797 For example, 01798 01799 Contact: ;expires=3600 01800 01801 01802 is equivalent to 01803 01804 CONTACT: ;ExPiReS=3600 01805 01806 01807 and 01808 01809 Content-Disposition: session;handling=optional 01810 01811 01812 is equivalent to 01813 01814 content-disposition: Session;HANDLING=OPTIONAL 01815 01816 01817 01818 01819 J. Rosenberg et. al. [Page 26] 01820 Internet Draft SIP February 18, 2002 01821 01822 01823 The following two header fields are not equivalent: 01824 01825 Warning: 370 devnull "Choose a bigger pipe" 01826 Warning: 370 devnull "CHOOSE A BIGGER PIPE" 01827 01828 01829 01830 7.3.2 Header Field Classification 01831 01832 Some header fields only make sense in requests or responses. These 01833 are called request header fields and response header fields, 01834 respectively. If a header field appears in a message not matching 01835 its category (such as a request header field in a response), it MUST 01836 be ignored. Section 20 defines the classification of each header 01837 field. 01838 01839 7.3.3 Compact Form 01840 01841 SIP provides a mechanism to represent common header field names in an 01842 abbreviated form. This may be useful when messages would otherwise 01843 become too large to be carried on the transport available to it 01844 (exceeding the maximum transmission unit (MTU) when using UDP, for 01845 example). These compact forms are defined in Section 20. A compact 01846 form MAY be substituted for the longer form of a header field name at 01847 any time without changing the semantics of the message. A header 01848 field name MAY appear in both long and short forms within the same 01849 message. Implementations MUST accept both the long and short forms of 01850 each header name. 01851 01852 7.4 Bodies 01853 01854 Requests, including new requests defined in extensions to this 01855 specification, MAY contain message bodies unless otherwise noted. 01856 The interpretation of the body depends on the request method. 01857 01858 For response messages, the request method and the response status 01859 code determine the type and interpretation of any message body. All 01860 responses MAY include a body. 01861 01862 7.4.1 Message Body Type 01863 01864 The Internet media type of the message body MUST be given by the 01865 Content-Type header field. If the body has undergone any encoding 01866 such as compression, then this MUST be indicated by the Content- 01867 Encoding header field; otherwise, Content-Encoding MUST be omitted. 01868 If applicable, the character set of the message body is indicated as 01869 part of the Content-Type header-field value. 01870 01871 01872 01873 01874 J. Rosenberg et. al. [Page 27] 01875 Internet Draft SIP February 18, 2002 01876 01877 01878 The "multipart" MIME type defined in RFC 2046 [11] MAY be used within 01879 the body of the message. Implementations that send requests 01880 containing multipart message bodies MUST send a session description 01881 as a non-multipart message body if the remote implementation requests 01882 this through an Accept header field that does not contain multipart. 01883 01884 Note that SIP messages MAY contain binary bodies or body parts. 01885 01886 7.4.2 Message Body Length 01887 01888 The body length in bytes is provided by the Content-Length header 01889 field. Section 20.14 describes the necessary contents of this header 01890 field in detail. 01891 01892 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. 01893 (Note: The chunked encoding modifies the body of a message in order 01894 to transfer it as a series of chunks, each with its own size 01895 indicator.) 01896 01897 7.5 Framing SIP messages 01898 01899 Unlike HTTP, SIP implementations can use UDP or other unreliable 01900 datagram protocols. Each such datagram carries one request or 01901 response. See Section 18 on constraints on usage of unreliable 01902 transports. 01903 01904 Implementations processing SIP messages over stream-oriented 01905 transports MUST ignore any CRLF appearing before the start-line 01906 [H4.1]. 01907 01908 The Content-Length header field value is used to locate the 01909 end of each SIP message in a stream. It will always be 01910 present when SIP messages are sent over stream-oriented 01911 transports. 01912 01913 8 General User Agent Behavior 01914 01915 A user agent represents an end system. It contains a user agent 01916 client (UAC), which generates requests, and a user agent server 01917 (UAS), which responds to them. A UAC is capable of generating a 01918 request based on some external stimulus (the user clicking a button, 01919 or a signal on a PSTN line) and processing a response. A UAS is 01920 capable of receiving a request and generating a response based on 01921 user input, external stimulus, the result of a program execution, or 01922 some other mechanism. 01923 01924 When a UAC sends a request, it will pass through some number of proxy 01925 servers, which forward the request towards the UAS. When the UAS 01926 01927 01928 01929 J. Rosenberg et. al. [Page 28] 01930 Internet Draft SIP February 18, 2002 01931 01932 01933 generates a response, the response is forwarded towards the UAC. 01934 01935 UAC and UAS procedures depend strongly on two factors. First, based 01936 on whether the request or response is inside or outside of a dialog, 01937 and second, based on the method of a request. Dialogs are discussed 01938 thoroughly in Section 12; they represent a peer-to-peer relationship 01939 between user agents and are established by specific SIP methods, such 01940 as INVITE. 01941 01942 In this section, we discuss the method-independent rules for UAC and 01943 UAS behavior when processing requests that are outside of a dialog. 01944 This includes, of course, the requests which themselves establish a 01945 dialog. 01946 01947 Security procedures for requests and responses outside of a dialog 01948 are described in Section 26. Specifically, mechanisms exist for the 01949 UAS and UAC to mutually authenticate. A limited set of privacy 01950 features are also supported through encryption of bodies using 01951 S/MIME. 01952 01953 8.1 UAC Behavior 01954 01955 This section covers UAC behavior outside of a dialog. 01956 01957 8.1.1 Generating the Request 01958 01959 A valid SIP request formulated by a UAC MUST at a minimum contain the 01960 following header fields: To, From, CSeq, Call-ID, Max-Forwards, and 01961 Via; all of these header fields are mandatory in all SIP messages. 01962 These six header fields are the fundamental building blocks of a SIP 01963 message, as they jointly provide for most of the critical message 01964 routing services including the addressing of messages, the routing of 01965 responses, limiting message propagation, ordering of messages, and 01966 the unique identification of transactions. These header fields are in 01967 addition to the mandatory request line, which contains the method, 01968 Request-URI, and SIP version. 01969 01970 Examples of requests sent outside of a dialog include an INVITE to 01971 establish a session (Section 13) and an OPTIONS to query for 01972 capabilities (Section 11). 01973 01974 8.1.1.1 Request-URI 01975 01976 The initial Request-URI of the message SHOULD be set to the value of 01977 the URI in the To field. One notable exception is the REGISTER 01978 method; behavior for setting the Request-URI of REGISTER is given in 01979 Section 10. It may also be undesirable for privacy reasons or 01980 convenience to set these fields to the same value (especially if the 01981 01982 01983 01984 J. Rosenberg et. al. [Page 29] 01985 Internet Draft SIP February 18, 2002 01986 01987 01988 originating UA expects that the Request-URI will be changed during 01989 transit). 01990 01991 In some special circumstances, the presence of a pre-existing route 01992 set can affect the Request-URI of the message. A pre-existing route 01993 set is an ordered set of URIs that identify a chain of servers, to 01994 which a UAC will send outgoing requests that are outside of a dialog. 01995 Commonly, they are configured on the UA by a user or service provider 01996 manually, or through some other non-SIP mechanism. When a provider 01997 wishes to configure a UA with an outbound proxy, it is RECOMMENDED 01998 that this be done by providing it with a pre-existing route set with 01999 a single URI, that of the outbound proxy. 02000 02001 When a pre-existing route set is present, the procedures for 02002 populating the Request-URI and Route header field detailed in Section 02003 12.2.1.1 MUST be followed, even though there is no dialog. If the 02004 Request-URI specifies a SIPS URI, all the SIP URI in the route set 02005 MUST be converted to SIPS URI (by changing the scheme to SIPS) before 02006 performing the processing of Section 12.2.1.1. 02007 02008 8.1.1.2 To 02009 02010 The To header field first and foremost specifies the desired 02011 "logical" recipient of the request, or the address-of-record of the 02012 user or resource that is the target of this request. This may or may 02013 not be the ultimate recipient of the request. The To header field MAY 02014 contain a SIP or SIPS URI, but it may also make use of other URI 02015 schemes (the tel URL [9], for example) when appropriate. All SIP 02016 implementations MUST support the SIP and URI scheme. Any 02017 implementation that supports TLS MUST support the SIPS URI scheme. 02018 The To header field allows for a display name. 02019 02020 A UAC may learn how to populate the To header field for a particular 02021 request in a number of ways. Usually the user will suggest the To 02022 header field through a human interface, perhaps inputting the URI 02023 manually or selecting it from some sort of address book. Frequently, 02024 the user will not enter a complete URI, but rather, a string of 02025 digits or letters (for example, "bob"). It is at the discretion of 02026 the UA to choose how to interpret this input. Using it to form the 02027 user part of a SIP URI implies that the UA wishes the name to be 02028 resolved in the domain to the right-hand side (RHS) of the at-sign in 02029 the SIP URI (for instance, sip:bob@example.com). Using it to form 02030 the user part of a SIPS URI implies that the UA wishes to securely 02031 communicate, and that the name is to be resolved in the domain to the 02032 RHS of the at-sign. The RHS will frequently be the home domain of the 02033 user, which allows for the home domain to process the outgoing 02034 request. This is useful for features like "speed dial" that require 02035 interpretation of the user part in the home domain. The tel URL may 02036 02037 02038 02039 J. Rosenberg et. al. [Page 30] 02040 Internet Draft SIP February 18, 2002 02041 02042 02043 be used when the UA does not wish to specify the domain that should 02044 interpret a telephone number that has been inputted by the user. 02045 Rather, each domain through which the request passes would be given 02046 that opportunity. As an example, a user in an airport might log in 02047 and send requests through an outbound proxy in the airport. If they 02048 enter "411" (this is the phone number for local directory assistance 02049 in the United States), that needs to be interpreted and processed by 02050 the outbound proxy in the airport, not the user's home domain. In 02051 this case, tel:411 would be the right choice. 02052 02053 A request outside of a dialog MUST NOT contain a tag; the tag in the 02054 To field of a request identifies the peer of the dialog. Since no 02055 dialog is established, no tag is present. 02056 02057 For further information on the To header field, see Section 20.39. 02058 The following is an example of valid To header field: 02059 02060 To: Carol 02061 02062 02063 02064 8.1.1.3 From 02065 02066 The From header field indicates the logical identity of the initiator 02067 of the request, possibly the user's address-of-record. Like the To 02068 header field, it contains a URI and optionally a display name. It is 02069 used by SIP elements to determine which processing rules to apply to 02070 a request (for example, automatic call rejection). As such, it is 02071 very important that the From URI not contain IP addresses or the FQDN 02072 of the host on which the UA is running, since these are not logical 02073 names. 02074 02075 The From header field allows for a display name. A UAC SHOULD use the 02076 display name "Anonymous", along with a syntactically correct, but 02077 otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the 02078 identity of the client is to remain hidden. 02079 02080 Usually the value that populates the From header field in requests 02081 generated by a particular UA is pre-provisioned by the user or by the 02082 administrators of the user's local domain. If a particular UA is used 02083 by multiple users, it might have switchable profiles that include a 02084 URI corresponding to the identity of the profiled user. Recipients of 02085 requests can authenticate the originator of a request in order to 02086 ascertain that they are who their From header field claims they are 02087 (see Section 22 for more on authentication). 02088 02089 The From field MUST contain a new "tag" parameter, chosen by the UAC. 02090 See Section 19.3 for details on choosing a tag. 02091 02092 02093 02094 J. Rosenberg et. al. [Page 31] 02095 Internet Draft SIP February 18, 2002 02096 02097 02098 For further information on the From header field, see Section 20.20. 02099 Examples: 02100 02101 02102 From: "Bob" ;tag=a48s 02103 From: sip:+12125551212@phone2net.com;tag=887s 02104 From: Anonymous ;tag=hyh8 02105 02106 02107 02108 8.1.1.4 Call-ID 02109 02110 The Call-ID header field acts as a unique identifier to group 02111 together a series of messages. It MUST be the same for all requests 02112 and responses sent by either UA in a dialog. It SHOULD be the same in 02113 each registration from a UA. 02114 02115 In a new request created by a UAC outside of any dialog, the Call-ID 02116 header field MUST be selected by the UAC as a globally unique 02117 identifier over space and time unless overridden by method-specific 02118 behavior. All SIP UAs must have a means to guarantee that the Call-ID 02119 header fields they produce will not be inadvertently generated by any 02120 other UA. Note that when requests are retried after certain failure 02121 responses that solicit an amendment to a request (for example, a 02122 challenge for authentication), these retried requests are not 02123 considered new requests, and therefore do not need new Call-ID header 02124 fields; see Section 8.1.3.5. 02125 02126 Use of cryptographically random identifiers [12] in the generation of 02127 Call-IDs is RECOMMENDED. Implementations MAY use the form 02128 "localid@host". Call-IDs are case-sensitive and are simply compared 02129 byte-by-byte. 02130 02131 Using cryptographically random identifiers provides some 02132 protection against session hijacking and reduces the 02133 likelihood of unintentional Call-ID collisions. 02134 02135 No provisioning or human interface is required for the selection of 02136 the Call-ID header field value for a request. 02137 02138 For further information on the Call-ID header field, see Section 02139 20.8. 02140 02141 Example: 02142 02143 02144 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 02145 02146 02147 02148 02149 J. Rosenberg et. al. [Page 32] 02150 Internet Draft SIP February 18, 2002 02151 02152 02153 8.1.1.5 CSeq 02154 02155 The CSeq header field serves as a way to identify and order 02156 transactions. It consists of a sequence number and a method. The 02157 method MUST match that of the request. For non-REGISTER requests 02158 outside of a dialog, the sequence number value is arbitrary. The 02159 sequence number value MUST be expressible as a 32-bit unsigned 02160 integer and MUST be less than 2**31. As long as it follows the above 02161 guidelines, a client may use any mechanism it would like to select 02162 CSeq header field values. 02163 02164 Section 12.2.1.1 discusses construction of the CSeq for requests 02165 within a dialog. 02166 02167 Example: 02168 02169 02170 CSeq: 4711 INVITE 02171 02172 02173 02174 8.1.1.6 Max-Forwards 02175 02176 The Max-Forwards header field serves to limit the number of hops a 02177 request can transit on the way to its destination. It consists of an 02178 integer that is decremented by one at each hop. If the Max-Forwards 02179 value reaches 0 before the request reaches its destination, it will 02180 be rejected with a 483(Too Many Hops) error response. 02181 02182 A UAC MUST insert a Max-Forwards header field into each request it 02183 originates with a value which SHOULD be 70. This number was chosen to 02184 be sufficiently large to guarantee that a request would not be 02185 dropped in any SIP network when there were no loops, but not so large 02186 as to consume proxy resources when a loop does occur. Lower values 02187 should be used with caution and only in networks where topologies are 02188 known by the UA. 02189 02190 8.1.1.7 Via 02191 02192 The Via header field is used to indicate the transport used for the 02193 transaction and to identify the location where the response is to be 02194 sent. A Via header field value is added only after the transport 02195 that will be used to reach the next hop has been selected (which may 02196 involve the usage of the procedures in [4]). 02197 02198 When the UAC creates a request, it MUST insert a Via into that 02199 request. The protocol name and protocol version in the header field 02200 MUST be SIP and 2.0, respectively. The Via header field value MUST 02201 02202 02203 02204 J. Rosenberg et. al. [Page 33] 02205 Internet Draft SIP February 18, 2002 02206 02207 02208 contain a branch parameter. This parameter is used to identify the 02209 transaction created by that request. This parameter is used by both 02210 the client and the server. 02211 02212 The branch parameter value MUST be unique across space and time for 02213 all requests sent by the UA. The exceptions to this rule are CANCEL 02214 and ACK for non-2xx responses. As discussed below, a CANCEL request 02215 will have the same value of the branch parameter as the request it 02216 cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx 02217 response will also have the same branch ID as the INVITE whose 02218 response it acknowledges. 02219 02220 02221 The uniqueness property of the branch ID parameter, to 02222 facilitate its use as a transaction ID, was not part of RFC 02223 2543 02224 02225 The branch ID inserted by an element compliant with this 02226 specification MUST always begin with the characters "z9hG4bK". These 02227 7 characters are used as a magic cookie (7 is deemed sufficient to 02228 ensure that an older RFC 2543 implementation would not pick such a 02229 value), so that servers receiving the request can determine that the 02230 branch ID was constructed in the fashion described by this 02231 specification (that is, globally unique). Beyond this requirement, 02232 the precise format of the branch token is implementation-defined. 02233 02234 The Via header maddr, ttl, and sent-by components will be set when 02235 the request is processed by the transport layer (Section 18). 02236 02237 Via processing for proxies is described in Section 16.6 Item 8 and 02238 Section 16.7 Item 3. 02239 02240 8.1.1.8 Contact 02241 02242 The Contact header field provides a SIP URI that can be used to 02243 contact that specific instance of the UA for subsequent requests. The 02244 Contact header field MUST be present and contain exactly one SIP URI 02245 in any request that can result in the establishment of a dialog. For 02246 the methods defined in this specification, that includes only the 02247 INVITE request. For these requests, the scope of the Contact is 02248 global. That is, the Contact header field value contains the URI at 02249 which the UA would like to receive requests, and this URI MUST be 02250 valid even if used in subsequent requests outside of any dialogs. 02251 02252 If the Request-URI contains a SIPS URI, the Contact header field MUST 02253 contain a SIPS URI as well. 02254 02255 For further information on the Contact header field, see Section 02256 02257 02258 02259 J. Rosenberg et. al. [Page 34] 02260 Internet Draft SIP February 18, 2002 02261 02262 02263 20.10. 02264 02265 8.1.1.9 Supported and Require 02266 02267 If the UAC supports extensions to SIP that can be applied by the 02268 server to the response, the UAC SHOULD include a Supported header 02269 field in the request listing the option tags (Section 19.2) for those 02270 extensions. 02271 02272 The option tags listed MUST only refer to extensions defined in 02273 standards-track RFCs. This is to prevent servers from insisting that 02274 clients implement non-standard, vendor-defined features in order to 02275 receive service. Extensions defined by experimental and informational 02276 RFCs are explicitly excluded from usage with the Supported header 02277 field in a request, since they too are often used to document 02278 vendor-defined extensions. 02279 02280 If the UAC wishes to insist that a UAS understand an extension that 02281 the UAC will apply to the request in order to process the request, it 02282 MUST insert a Require header field into the request listing the 02283 option tag for that extension. If the UAC wishes to apply an 02284 extension to the request and insist that any proxies that are 02285 traversed understand that extension, it MUST insert a Proxy-Require 02286 header field into the request listing the option tag for that 02287 extension. 02288 02289 As with the Supported header field, the option tags in the Require 02290 and Proxy-Require header fields MUST only refer to extensions defined 02291 in standards-track RFCs. 02292 02293 8.1.1.10 Additional Message Components 02294 02295 After a new request has been created, and the header fields described 02296 above have been properly constructed, any additional optional header 02297 fields are added, as are any header fields specific to the method. 02298 02299 SIP requests MAY contain a MIME-encoded message-body. Regardless of 02300 the type of body that a request contains, certain header fields must 02301 be formulated to characterize the contents of the body. For further 02302 information on these header fields, see Sections 20.11 through 20.15. 02303 02304 8.1.2 Sending the Request 02305 02306 The destination for the request is then computed. Unless there is 02307 local policy specifying otherwise, then the destination MUST be 02308 determined by applying the DNS procedures described in [4] as 02309 follows. If the first element in the route set indicated a strict 02310 router (resulting in forming the request as described in Section 02311 02312 02313 02314 J. Rosenberg et. al. [Page 35] 02315 Internet Draft SIP February 18, 2002 02316 02317 02318 12.2.1.1), the procedures MUST be applied to the Request-URI of the 02319 request. Otherwise, the procedures are applied to the first Route 02320 header field value in the request (if one exists), or to the 02321 request's Request-URI if there is no Route header field present. 02322 These procedures yield an ordered set of address, port, and 02323 transports to attempt. 02324 02325 Local policy MAY specify an alternate set of destinations to attempt. 02326 If the Request-URI contains a SIPS URI, any alternate destinations 02327 MUST be contacted with TLS. Beyond that, there are no restrictions on 02328 the alternate destinations if the request contains no Route header 02329 field. This provides a simple alternative to a pre-existing route set 02330 as a way to specify an outbound proxy. However, that approach for 02331 configuring an outbound proxy is NOT RECOMMENDED; a pre-existing 02332 route set with a single URI SHOULD be used instead. If the request 02333 contains a Route header field, the request SHOULD be sent to the 02334 locations derived from its topmost value, but MAY be sent to any 02335 server that the UA is certain will honor the Route and Request-URI 02336 policies specified in this document (as opposed to those in RFC 02337 2543). In particular, a UAC configured with an outbound proxy SHOULD 02338 attempt to send the request to the location indicated in the first 02339 Route header field value instead of adopting the policy of sending 02340 all messages to the outbound proxy. 02341 02342 02343 This ensures that outbound proxies choosing not to add 02344 Record-Route header field values will drop out of the path 02345 of subsequent requests. It allows endpoints that cannot 02346 resolve the first Route URI to delegate that task to an 02347 outbound proxy. 02348 02349 The UAC SHOULD follow the procedures defined in [4] for stateful 02350 elements, trying each address until a server is contacted. Each try 02351 constitutes a new transaction, and therefore each carries a different 02352 topmost Via header field value with a new branch parameter. 02353 Furthermore, the transport value in the Via header field is set to 02354 whatever transport was determined for the target server. 02355 02356 8.1.3 Processing Responses 02357 02358 Responses are first processed by the transport layer and then passed 02359 up to the transaction layer. The transaction layer performs its 02360 processing and then passes the response up to the TU. The majority 02361 of response processing in the TU is method specific. However, there 02362 are some general behaviors independent of the method. 02363 02364 8.1.3.1 Transaction Layer Errors 02365 02366 02367 02368 02369 J. Rosenberg et. al. [Page 36] 02370 Internet Draft SIP February 18, 2002 02371 02372 02373 In some cases, the response returned by the transaction layer will 02374 not be a SIP message, but rather a transaction layer error. When a 02375 timeout error is received from the transaction layer, it MUST be 02376 treated as if a 408 (Request Timeout) status code has been received. 02377 If a fatal transport error is reported by the transport layer 02378 (generally, due to fatal ICMP errors in UDP or connection failures in 02379 TCP), the condition MUST be treated as a 503 (Service Unavailable) 02380 status code. 02381 02382 8.1.3.2 Unrecognized Responses 02383 02384 A UAC MUST treat any final response it does not recognize as being 02385 equivalent to the x00 response code of that class, and MUST be able 02386 to process the x00 response code for all classes. For example, if a 02387 UAC receives an unrecognized response code of 431, it can safely 02388 assume that there was something wrong with its request and treat the 02389 response as if it had received a 400 (Bad Request) response code. A 02390 UAC MUST treat any provisional response different than 100 that it 02391 does not recognize as 183 (Session Progress). A UAC MUST be able to 02392 process 100 and 183 responses. 02393 02394 8.1.3.3 Vias 02395 02396 If more than one Via header field value is present in a response, the 02397 UAC SHOULD discard the message. 02398 02399 The presence of additional Via header field values that 02400 precede the originator of the request suggests that the 02401 message was misrouted or possibly corrupted. 02402 02403 8.1.3.4 Processing 3xx Responses 02404 02405 Upon receipt of a redirection response (for example, a 301 response 02406 status code), clients SHOULD use the URI(s) in the Contact header 02407 field to formulate one or more new requests based on the redirected 02408 request. If the original request had a SIPS URI in the Request-URI, 02409 the client MUST discard any Contact header fields which do not 02410 contain SIPS URIs. 02411 02412 If more than one URI is present in Contact header field within the 02413 3xx response, the UA MUST determine an order in which these contact 02414 addresses should be processed. UAs MUST consult the "q" parameter 02415 value of the Contact header field value (see Section 20.10) if 02416 available. Contact addresses MUST be ordered from highest qvalue to 02417 lowest. If no qvalue is present, a contact address is considered to 02418 have a qvalue of 1.0. Note that two or more contact addresses might 02419 have an equal qvalue - these URIs are eligible to be tried in 02420 parallel. 02421 02422 02423 02424 J. Rosenberg et. al. [Page 37] 02425 Internet Draft SIP February 18, 2002 02426 02427 02428 Once an ordered list has been established, UACs MAY remove from the 02429 list any entry that they do not want to try. After this, UACs MUST 02430 try to contact each URI in the ordered list in turn by sending a 02431 request for a single contact address at a time, continuing down the 02432 ordered list only when a final response to the current request has 02433 been received. If there are contact addresses with an equal qvalue, 02434 the UAC MAY decide randomly on an order in which to process these 02435 addresses, or it MAY attempt to process contact addresses of equal 02436 qvalue in parallel. 02437 02438 Note that, for example, the UAC may effectively divide the ordered 02439 list into groups, processing the groups serially and processing the 02440 destinations in each group in parallel. 02441 02442 If contacting an address in the list results in a failure, as defined 02443 in the next paragraph, the element moves to the next address in the 02444 list, until the list is exhausted. If the list is exhausted, then the 02445 request has failed. 02446 02447 Failures SHOULD be detected through failure response codes (codes 02448 greater than 399); for network errors the client transaction will 02449 report any transport layer failures to the transaction user. Note 02450 that some response codes (detailed in 8.1.3.5) indicate that the 02451 request can be retried; requests that are reattempted should not be 02452 considered failures. 02453 02454 When a failure for a particular contact address is received, the 02455 client SHOULD try the next contact address. This will involve 02456 creating a new client transaction to deliver a new request. 02457 02458 In order to create a request based on a contact address in a 3xx 02459 response, a UAC MUST copy the entire URI from the Contact header 02460 field value into the Request-URI, except for the "method-param" and 02461 "header" URI parameters (see Section 19.1.1 for a definition of these 02462 parameters). It uses the "header" parameters to create header field 02463 values for the new request, overwriting header field values 02464 associated with the redirected request in accordance with the 02465 guidelines in Section 19.1.5. 02466 02467 Note that in some instances, header fields that have been 02468 communicated in the contact address may instead append to existing 02469 request header fields in the original redirected request. As a 02470 general rule, if the header field can accept a comma-separated list 02471 of values, then the new header field value MAY be appended to any 02472 existing values in the original redirected request. If the header 02473 field does not accept multiple values, the value in the original 02474 redirected request MAY be overwritten by the header field value 02475 communicated in the contact address. For example, if a contact 02476 02477 02478 02479 J. Rosenberg et. al. [Page 38] 02480 Internet Draft SIP February 18, 2002 02481 02482 02483 address is returned with the following value: 02484 02485 02486 sip:user@host?Subject=foo&Call-Info= 02487 02488 02489 02490 Then any Subject header field in the original redirected request is 02491 overwritten, but the HTTP URL is merely appended to any existing 02492 Call-Info header field values. 02493 02494 It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID 02495 used in the original redirected request, but the UAC MAY also choose 02496 to update the Call-ID header field value for new requests, for 02497 example. 02498 02499 Finally, once the new request has been constructed, it is sent using 02500 a new client transaction, and therefore MUST have a new branch ID in 02501 the top Via field as discussed in Section 8.1.1.7. 02502 02503 In all other respects, requests sent upon receipt of a redirect 02504 response SHOULD re-use the header fields and bodies of the original 02505 request. 02506 02507 Redirections can result in requests that are in turn redirected. For 02508 example, if an initial 3xx response contains multiple contacts, and 02509 the retry of the request to the first of these contacts is in turn 02510 redirected, UACs must reconcile the two resulting sets of URIs. UAs 02511 MUST combine the two sets of contact addresses and recompute the 02512 ordering of the elements following the steps described above. 02513 However, if any two URIs in the set are equivalent, the less 02514 preferred URI, meaning the URI with the numerically highest "q" 02515 value, MUST be discarded. 02516 02517 In some instances, Contact header field values may be cached at UAC 02518 temporarily or permanently depending on the status code received and 02519 the presence of an expiration interval; see Sections 21.3.2 and 02520 21.3.3. 02521 02522 8.1.3.5 Processing 4xx Responses 02523 02524 Certain 4xx response codes require specific UA processing, 02525 independent of the method. 02526 02527 If a 401 (Unauthorized) or 407 (Proxy Authentication Required) 02528 response is received, the UAC SHOULD follow the authorization 02529 procedures of Section 22.2 and Section 22.3 to retry the request with 02530 credentials. 02531 02532 02533 02534 J. Rosenberg et. al. [Page 39] 02535 Internet Draft SIP February 18, 2002 02536 02537 02538 If a 413 (Request Entity Too Large) response is received (Section 02539 21.4.11), the request contained a body that was longer than the UAS 02540 was willing to accept. If possible, the UAC SHOULD retry the request, 02541 either omitting the body or using one of a smaller length. 02542 02543 If a 415 (Unsupported Media Type) response is received (Section 02544 21.4.13), the request contained media types not supported by the UAS. 02545 The UAC SHOULD retry sending the request, this time only using 02546 content with types listed in the Accept header field in the response, 02547 with encodings listed in the Accept-Encoding header field in the 02548 response, and with languages listed in the Accept-Language in the 02549 response. 02550 02551 If a 416 (Unsupported URI Scheme) response is received (Section 02552 21.4.14), the Request-URI used a URI scheme not supported by the 02553 server. The client SHOULD retry the request, this time, using a SIP 02554 URI. 02555 02556 If a 420 (Bad Extension) response is received (Section 21.4.15), the 02557 request contained a Require or Proxy-Require header field listing an 02558 option-tag for a feature not supported by a proxy or UAS. The UAC 02559 SHOULD retry the request, this time omitting any extensions listed in 02560 the Unsupported header field in the response. 02561 02562 In all of the above cases, the request is retried by creating a new 02563 request with the appropriate modifications. This new request SHOULD 02564 have the same value of the Call-ID, To, and From of the previous 02565 request, but the CSeq should contain a new sequence number that is 02566 one higher than the previous. 02567 02568 With other 4xx responses, including those yet to be defined, a retry 02569 may or may not be possible depending on the method and the use case. 02570 02571 8.2 UAS Behavior 02572 02573 When a request outside of a dialog is processed by a UAS, there is a 02574 set of processing rules that are followed, independent of the method. 02575 Section 12 gives guidance on how a UAS can tell whether a request is 02576 inside or outside of a dialog. 02577 02578 Note that request processing is atomic. If a request is accepted, all 02579 state changes associated with it MUST be performed. If it is 02580 rejected, all state changes MUST NOT be performed. 02581 02582 UASs SHOULD process the requests in the order of the steps that 02583 follow in this section (that is, starting with authentication, then 02584 inspecting the method, the header fields, and so on throughout the 02585 remainder of this section). 02586 02587 02588 02589 J. Rosenberg et. al. [Page 40] 02590 Internet Draft SIP February 18, 2002 02591 02592 02593 8.2.1 Method Inspection 02594 02595 Once a request is authenticated (or authentication is skipped), the 02596 UAS MUST inspect the method of the request. If the UAS recognizes but 02597 does not support the method of a request, it MUST generate a 405 02598 (Method Not Allowed) response. Procedures for generating responses 02599 are described in Section 8.2.6. The UAS MUST also add an Allow header 02600 field to the 405 (Method Not Allowed) response. The Allow header 02601 field MUST list the set of methods supported by the UAS generating 02602 the message. The Allow header field is presented in Section 20.5. 02603 02604 If the method is one supported by the server, processing continues. 02605 02606 8.2.2 Header Inspection 02607 02608 If a UAS does not understand a header field in a request (that is, 02609 the header field is not defined in this specification or in any 02610 supported extension), the server MUST ignore that header field and 02611 continue processing the message. A UAS SHOULD ignore any malformed 02612 header fields that are not necessary for processing requests. 02613 02614 8.2.2.1 To and Request-URI 02615 02616 The To header field identifies the original recipient of the request 02617 designated by the user identified in the From field. The original 02618 recipient may or may not be the UAS processing the request, due to 02619 call forwarding or other proxy operations. A UAS MAY apply any policy 02620 it wishes to determine whether to accept requests when the To header 02621 field is not the identity of the UAS. However, it is RECOMMENDED that 02622 a UAS accept requests even if they do not recognize the URI scheme 02623 (for example, a tel: URI) in the To header field, or if the To header 02624 field does not address a known or current user of this UAS. If, on 02625 the other hand, the UAS decides to reject the request, it SHOULD 02626 generate a response with a 403 (Forbidden) status code and pass it to 02627 the server transaction for transmission. 02628 02629 However, the Request-URI identifies the UAS that is to process the 02630 request. If the Request-URI uses a scheme not supported by the UAS, 02631 it SHOULD reject the request with a 416 (Unsupported URI Scheme) 02632 response. If the Request-URI does not identify an address that the 02633 UAS is willing to accept requests for, it SHOULD reject the request 02634 with a 404 (Not Found) response. Typically, a UA that uses the 02635 REGISTER method to bind its address-of-record to a specific contact 02636 address will see requests whose Request-URI equals that contact 02637 address. Other potential sources of received Request-URIs include the 02638 Contact header fields of requests and responses sent by the UA that 02639 establish or refresh dialogs. 02640 02641 02642 02643 02644 J. Rosenberg et. al. [Page 41] 02645 Internet Draft SIP February 18, 2002 02646 02647 02648 8.2.2.2 Merged Requests 02649 02650 If the request has no tag in the To header field, the UAS core MUST 02651 check the request against ongoing transactions. If the To tag, From 02652 tag, Call-ID, CSeq exactly match (including tags) those associated 02653 with an ongoing transaction, but the branch-ID in the topmost Via 02654 does not match , the UAS core SHOULD generate a 482 (Loop Detected) 02655 response and pass it to the server transaction. 02656 02657 The same request has arrived at the UAS more than once, 02658 following different paths, most likely due to forking. The 02659 UAS processes the first such request received and responds 02660 with a 482 (Loop Detected) to the rest of them. 02661 02662 8.2.2.3 Require 02663 02664 Assuming the UAS decides that it is the proper element to process the 02665 request, it examines the Require header field, if present. 02666 02667 The Require header field is used by a UAC to tell a UAS about SIP 02668 extensions that the UAC expects the UAS to support in order to 02669 process the request properly. Its format is described in Section 02670 20.32. If a UAS does not understand an option-tag listed in a Require 02671 header field, it MUST respond by generating a response with status 02672 code 420 (Bad Extension). The UAS MUST add an Unsupported header 02673 field, and list in it those options it does not understand amongst 02674 those in the Require header field of the request. 02675 02676 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL 02677 request, or in an ACK request sent for a non-2xx response. These 02678 header fields MUST be ignored if they are present in these requests. 02679 02680 An ACK request for a 2xx response MUST contain only those Require and 02681 Proxy-Require values that were present in the initial request. 02682 02683 Example: 02684 02685 UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 02686 Require: 100rel 02687 02688 02689 UAS->UAC: SIP/2.0 420 Bad Extension 02690 Unsupported: 100rel 02691 02692 02693 02694 02695 This behavior ensures that the client-server interaction 02696 02697 02698 02699 J. Rosenberg et. al. [Page 42] 02700 Internet Draft SIP February 18, 2002 02701 02702 02703 will proceed without delay when all options are understood 02704 by both sides, and only slow down if options are not 02705 understood (as in the example above). For a well-matched 02706 client-server pair, the interaction proceeds quickly, 02707 saving a round-trip often required by negotiation 02708 mechanisms. In addition, it also removes ambiguity when the 02709 client requires features that the server does not 02710 understand. Some features, such as call handling fields, 02711 are only of interest to end systems. 02712 02713 8.2.3 Content Processing 02714 02715 Assuming the UAS understands any extensions required by the client, 02716 the UAS examines the body of the message, and the header fields that 02717 describe it. If there are any bodies whose type (indicated by the 02718 Content-Type), language (indicated by the Content-Language) or 02719 encoding (indicated by the Content-Encoding) are not understood, and 02720 that body part is not optional (as indicated by the Content- 02721 Disposition header field), the UAS MUST reject the request with a 415 02722 (Unsupported Media Type) response. The response MUST contain an 02723 Accept header field listing the types of all bodies it understands, 02724 in the event the request contained bodies of types not supported by 02725 the UAS. If the request contained content encodings not understood by 02726 the UAS, the response MUST contain an Accept-Encoding header field 02727 listing the encodings understood by the UAS. If the request contained 02728 content with languages not understood by the UAS, the response MUST 02729 contain an Accept-Language header field indicating the languages 02730 understood by the UAS. Beyond these checks, body handling depends on 02731 the method and type. For further information on the processing of 02732 content-specific header fields, see Section 7.4 as well as Section 02733 20.11 through 20.15. 02734 02735 8.2.4 Applying Extensions 02736 02737 A UAS that wishes to apply some extension when generating the 02738 response MUST NOT do so unless support for that extension is 02739 indicated in the Supported header field in the request. If the 02740 desired extension is not supported, the server SHOULD rely only on 02741 baseline SIP and any other extensions supported by the client. In 02742 rare circumstances, where the server cannot process the request 02743 without the extension, the server MAY send a 421 (Extension Required) 02744 response. This response indicates that the proper response cannot be 02745 generated without support of a specific extension. The needed 02746 extension(s) MUST be included in a Require header field in the 02747 response. This behavior is NOT RECOMMENDED, as it will generally 02748 break interoperability. 02749 02750 Any extensions applied to a non-421 response MUST be listed in a 02751 02752 02753 02754 J. Rosenberg et. al. [Page 43] 02755 Internet Draft SIP February 18, 2002 02756 02757 02758 Require header field included in the response. Of course, the server 02759 MUST NOT apply extensions not listed in the Supported header field in 02760 the request. As a result of this, the Require header field in a 02761 response will only ever contain option tags defined in standards- 02762 track RFCs. 02763 02764 8.2.5 Processing the Request 02765 02766 Assuming all of the checks in the previous subsections are passed, 02767 the UAS processing becomes method-specific. Section 10 covers the 02768 REGISTER request, section 11 covers the OPTIONS request, section 13 02769 covers the INVITE request, and section 15 covers the BYE request. 02770 02771 8.2.6 Generating the Response 02772 02773 When a UAS wishes to construct a response to a request, it follows 02774 the general procedures detailed in the following subsections. 02775 Additional behaviors specific to the response code in question, which 02776 are not detailed in this section, may also be required. 02777 02778 Once all procedures associated with the creation of a response have 02779 been completed, the UAS hands the response back to the server 02780 transaction from which it received the request. 02781 02782 8.2.6.1 Sending a Provisional Response 02783 02784 One largely non-method-specific guideline for the generation of 02785 responses is that UASs SHOULD NOT issue a provisional response for a 02786 non-INVITE request. Rather, UASs SHOULD generate a final response to 02787 a non-INVITE request as soon as possible. 02788 02789 When a 100 (Trying) response is generated, any Timestamp header field 02790 present in the request MUST be copied into this 100 (Trying) 02791 response. If there is a delay in generating the response, the UAS 02792 SHOULD add a delay value into the Timestamp value in the response. 02793 This value MUST contain the difference between time of sending of the 02794 response and receipt of the request, measured in seconds. 02795 02796 8.2.6.2 Headers and Tags 02797 02798 The From field of the response MUST equal the From header field of 02799 the request. The Call-ID header field of the response MUST equal the 02800 Call-ID header field of the request. The CSeq header field of the 02801 response MUST equal the CSeq field of the request. The Via header 02802 field values in the response MUST equal the Via header field values 02803 in the request and MUST maintain the same ordering. 02804 02805 If a request contained a To tag in the request, the To header field 02806 02807 02808 02809 J. Rosenberg et. al. [Page 44] 02810 Internet Draft SIP February 18, 2002 02811 02812 02813 in the response MUST equal that of the request. However, if the To 02814 header field in the request did not contain a tag, the URI in the To 02815 header field in the response MUST equal the URI in the To header 02816 field; additionally, the UAS MUST add a tag to the To header field in 02817 the response (with the exception of the 100 (Trying) response, in 02818 which a tag MAY be present). This serves to identify the UAS that is 02819 responding, possibly resulting in a component of a dialog ID. The 02820 same tag MUST be used for all responses to that request, both final 02821 and provisional (again excepting the 100 (Trying)). Procedures for 02822 generation of tags are defined in Section 19.3. 02823 02824 8.2.7 Stateless UAS Behavior 02825 02826 A stateless UAS is a UAS that does not maintain transaction state. It 02827 replies to requests normally, but discards any state that would 02828 ordinarily be retained by a UAS after a response has been sent. If a 02829 stateless UAS receives a retransmission of a request, it regenerates 02830 the response and resends it, just as if it were replying to the first 02831 instance of the request. Stateless UASs do not use a transaction 02832 layer; they receive requests directly from the transport layer and 02833 send responses directly to the transport layer. 02834 02835 The stateless UAS role is needed primarily to handle unauthenticated 02836 requests for which a challenge response is issued. If unauthenticated 02837 requests were handled statefully, then malicious floods of 02838 unauthenticated requests could create massive amounts of transaction 02839 state that might slow or completely halt call processing in a UAS, 02840 effectively creating a denial of service condition; for more 02841 information see Section 26.1.5. 02842 02843 The most important behaviors of a stateless UAS are the following: 02844 02845 o A stateless UAS MUST NOT send provisional (1xx) responses. 02846 02847 o A stateless UAS MUST NOT retransmit responses. 02848 02849 o A stateless UAS MUST ignore ACK requests. 02850 02851 o A stateless UAS MUST ignore CANCEL requests. 02852 02853 o To header tags MUST be generated for responses in a stateless 02854 manner - in a manner that will generate the same tag for the 02855 same request consistently. For information on tag 02856 construction see Section 19.3. 02857 02858 In all other respects, a stateless UAS behaves in the same manner as 02859 a stateful UAS. A UAS can operate in either a stateful or stateless 02860 mode for each new request. 02861 02862 02863 02864 J. Rosenberg et. al. [Page 45] 02865 Internet Draft SIP February 18, 2002 02866 02867 02868 8.3 Redirect Servers 02869 02870 In some architectures it may be desirable to reduce the processing 02871 load on proxy servers that are responsible for routing requests, and 02872 improve signaling path robustness, by relying on redirection. 02873 Redirection allows servers to push routing information for a request 02874 back in a response to the client, thereby taking themselves out of 02875 the loop of further messaging for this transaction while still aiding 02876 in locating the target of the request. When the originator of the 02877 request receives the redirection, it will send a new request based on 02878 the URI(s) it has received. By propagating URIs from the core of the 02879 network to its edges, redirection allows for considerable network 02880 scalability. 02881 02882 A redirect server is logically constituted of a server transaction 02883 layer and a transaction user that has access to a location service of 02884 some kind (see Section 10 for more on registrars and location 02885 services). This location service is effectively a database containing 02886 mappings between a single URI and a set of one or more alternative 02887 locations at which the target of that URI can be found. 02888 02889 A redirect server does not issue any SIP requests of its own. After 02890 receiving a request other than CANCEL, the server either refuses the 02891 request or gathers the list of alternative locations from the 02892 location service and returns a final response of class 3xx. For 02893 well-formed CANCEL requests, it SHOULD return a 2xx response. This 02894 response ends the SIP transaction. The redirect server maintains 02895 transaction state for an entire SIP transaction. It is the 02896 responsibility of clients to detect forwarding loops between redirect 02897 servers. 02898 02899 When a redirect server returns a 3xx response to a request, it 02900 populates the list of (one or more) alternative locations into the 02901 Contact header field. An "expires" parameter to the Contact header 02902 field values may also be supplied to indicate the lifetime of the 02903 Contact data. 02904 02905 The Contact header field contains URIs giving the new locations or 02906 user names to try, or may simply specify additional transport 02907 parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) 02908 response may also give the same location and username that was 02909 targeted by the initial request but specify additional transport 02910 parameters such as a different server or multicast address to try, or 02911 a change of SIP transport from UDP to TCP or vice versa. 02912 02913 However, redirect servers MUST NOT redirect a request to a URI equal 02914 to the one in the Request-URI; instead, provided that the URI does 02915 not point to itself, the redirect server SHOULD proxy the request to 02916 02917 02918 02919 J. Rosenberg et. al. [Page 46] 02920 Internet Draft SIP February 18, 2002 02921 02922 02923 the destination URI. 02924 02925 If a client is using an outbound proxy, and that proxy 02926 actually redirects requests, a potential arises for 02927 infinite redirection loops. 02928 02929 Note that a Contact header field value MAY also refer to a different 02930 resource than the one originally called. For example, a SIP call 02931 connected to PSTN gateway may need to deliver a special informational 02932 announcement such as "The number you have dialed has been changed." 02933 02934 A Contact response header field can contain any suitable URI 02935 indicating where the called party can be reached, not limited to SIP 02936 URIs. For example, it could contain URIs for phones, fax, or irc (if 02937 they were defined) or a mailto: (RFC 2368, [31]) URL. However, if 02938 the Request-URI of the request contained a SIPS URI, the Contact 02939 header fields in the 3xx response MUST all be SIPS URIs. 02940 02941 The "expires" parameter of a Contact header field value indicates how 02942 long the URI is valid. The value of the parameter is a number 02943 indicating seconds. If this parameter is not provided, the value of 02944 the Expires header field determines how long the URI is valid. 02945 Malformed values SHOULD be treated as equivalent to 3600. 02946 02947 02948 This provides a modest level of backwards compatibility 02949 with RFC 2543, which allowed absolute times in this header 02950 field. If an absolute time is received, it will be treated 02951 as malformed, and then default to 3600. 02952 02953 Redirect servers MUST ignore features that are not understood 02954 (including unrecognized header fields, any unknown option tags in 02955 Require, or even method names) and proceed with the redirection of 02956 the request in question. 02957 02958 9 Canceling a Request 02959 02960 The previous section has discussed general UA behavior for generating 02961 requests and processing responses for requests of all methods. In 02962 this section, we discuss a general purpose method, called CANCEL. 02963 02964 The CANCEL request, as the name implies, is used to cancel a previous 02965 request sent by a client. Specifically, it asks the UAS to cease 02966 processing the request and to generate an error response to that 02967 request. CANCEL has no effect on a request to which a UAS has already 02968 given a final response. Because of this, it is most useful to CANCEL 02969 requests to which it can take a server long time to respond. For this 02970 reason, CANCEL is best for INVITE requests, which can take a long 02971 02972 02973 02974 J. Rosenberg et. al. [Page 47] 02975 Internet Draft SIP February 18, 2002 02976 02977 02978 time to generate a response. In that usage, a UAS that receives a 02979 CANCEL request for an INVITE, but has not yet sent a final response, 02980 would "stop ringing", and then respond to the INVITE with a specific 02981 error response (a 487). 02982 02983 CANCEL requests can be constructed and sent by both proxies and user 02984 agent clients. Section 15 discusses under what conditions a UAC would 02985 CANCEL an INVITE request, and Section 16.10 discusses proxy usage of 02986 CANCEL. 02987 02988 A stateful proxy responds to a CANCEL, rather than simply forwarding 02989 a response it would receive from a downstream element. For that 02990 reason, CANCEL is referred to as a "hop-by-hop" request, since it is 02991 responded to at each stateful proxy hop. 02992 02993 9.1 Client Behavior 02994 02995 A CANCEL request SHOULD NOT be sent to cancel a request other than 02996 INVITE. 02997 02998 Since requests other than INVITE are responded to 02999 immediately, sending a CANCEL for a non-INVITE request 03000 would always create a race condition. 03001 03002 The following procedures are used to construct a CANCEL request. The 03003 Request-URI, Call-ID, To, the numeric part of CSeq, and From header 03004 fields in the CANCEL request MUST be identical to those in the 03005 request being cancelled, including tags. A CANCEL constructed by a 03006 client MUST have only a single Via header field value matching the 03007 top Via value in the request being cancelled. Using the same values 03008 for these header fields allows the CANCEL to be matched with the 03009 request it cancels (Section 9.2 indicates how such matching occurs). 03010 However, the method part of the CSeq header field MUST have a value 03011 of CANCEL. This allows it to be identified and processed as a 03012 transaction in its own right (See Section 17). 03013 03014 If the request being cancelled contains a Route header field, the 03015 CANCEL request MUST include that Route header field's values. 03016 03017 This is needed so that stateless proxies are able to route 03018 CANCEL requests properly. 03019 03020 The CANCEL request MUST NOT contain any Require or Proxy-Require 03021 header fields. 03022 03023 Once the CANCEL is constructed, the client SHOULD check whether it 03024 has received any response (provisional or final) for the request 03025 being cancelled (herein referred to as the "original request"). 03026 03027 03028 03029 J. Rosenberg et. al. [Page 48] 03030 Internet Draft SIP February 18, 2002 03031 03032 03033 If no provisional response has been received, the CANCEL request MUST 03034 NOT be sent; rather, the client MUST wait for the arrival of a 03035 provisional response before sending the request. If the original 03036 request has generated a final response, the CANCEL SHOULD NOT be 03037 sent, as it is an effective no-op, since CANCEL has no effect on 03038 requests that have already generated a final response. When the 03039 client decides to send the CANCEL, it creates a client transaction 03040 for the CANCEL and passes it the CANCEL request along with the 03041 destination address, port, and transport. The destination address, 03042 port, and transport for the CANCEL MUST be identical to those used to 03043 send the original request. 03044 03045 03046 If it was allowed to send the CANCEL before receiving a 03047 response for the previous request, the server could receive 03048 the CANCEL before the original request. 03049 03050 Note that both the transaction corresponding to the original request 03051 and the CANCEL transaction will complete independently. However, a 03052 UAC canceling a request cannot rely on receiving a 487 (Request 03053 Terminated) response for the original request, as an RFC 2543- 03054 compliant UAS will not generate such a response. If there is no final 03055 response for the original request in 64*T1 seconds (T1 is defined in 03056 Section 17.1.1.1), the client SHOULD then consider the original 03057 transaction cancelled and SHOULD destroy the client transaction 03058 handling the original request. 03059 03060 9.2 Server Behavior 03061 03062 The CANCEL method requests that the TU at the server side cancel a 03063 pending transaction. The TU determines the transaction to be 03064 cancelled by taking the CANCEL request, and then assuming that the 03065 request method is anything but CANCEL and applying the transaction 03066 matching procedures of Section 17.2.3. The matching transaction is 03067 the one to be cancelled. 03068 03069 The processing of a CANCEL request at a server depends on the type of 03070 server. A stateless proxy will forward it, a stateful proxy might 03071 respond to it and generate some CANCEL requests of its own, and a UAS 03072 will respond to it. See Section 16.10 for proxy treatment of CANCEL. 03073 03074 A UAS first processes the CANCEL request according to the general UAS 03075 processing described in Section 8.2. However, since CANCEL requests 03076 are hop-by-hop and cannot be resubmitted, they cannot be challenged 03077 by the server in order to get proper credentials in an Authorization 03078 header field. Note also that CANCEL requests do not contain a Require 03079 header field. 03080 03081 03082 03083 03084 J. Rosenberg et. al. [Page 49] 03085 Internet Draft SIP February 18, 2002 03086 03087 03088 If the UAS did not find a matching transaction for the CANCEL 03089 according to the procedure above, it SHOULD respond to the CANCEL 03090 with a 481 (Call Leg/Transaction Does Not Exist). If the transaction 03091 for the original request still exists, the behavior of the UAS on 03092 receiving a CANCEL request depends on whether it has already sent a 03093 final response for the original request. If it has, the CANCEL 03094 request has no effect on the processing of the original request, no 03095 effect on any session state, and no effect on the responses generated 03096 for the original request. If the UAS has not issued a final response 03097 for the original request, its behavior depends on the method of the 03098 original request. If the original request was an INVITE, the UAS 03099 SHOULD immediately respond to the INVITE with a 487 (Request 03100 Terminated). The behavior upon reception of a CANCEL request for any 03101 other method defined in this specification is effectively no-op. 03102 03103 Regardless of the method of the original request, as long as the 03104 CANCEL matched an existing transaction, the UAS answers the CANCEL 03105 request itself with a 200 (OK) response. This response is 03106 constructed following the procedures described in Section 8.2.6 03107 noting that the To tag of the response to the CANCEL and the To tag 03108 in the response to the original request SHOULD be the same. The 03109 response to CANCEL is passed to the server transaction for 03110 transmission. 03111 03112 10 Registrations 03113 03114 10.1 Overview 03115 03116 SIP offers a discovery capability. If a user wants to initiate a 03117 session with another user, SIP must discover the current host(s) at 03118 which the destination user is reachable. This discovery process is 03119 frequently accomplished by SIP network elements such as proxy servers 03120 and redirect servers which are responsible for receiving a request, 03121 determining where to send it based on knowledge of the location of 03122 the user, and then sending it there. To do this, SIP network 03123 elements consult an abstract service known as a location service , 03124 which provides address bindings for a particular domain. These 03125 address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com 03126 , for example, to one or more URIs that are somehow "closer" to the 03127 desired user, sip:bob@engineering.biloxi.com , for example. 03128 Ultimately, a proxy will consult a location service that maps a 03129 received URI to the user agent(s) at which the desired recipient is 03130 currently residing. 03131 03132 Registration creates bindings in a location service for a particular 03133 domain that associate an address-of-record URI with one or more 03134 contact addresses. Thus, when a proxy for that domain receives a 03135 request whose Request-URI matches the address-of-record, the proxy 03136 03137 03138 03139 J. Rosenberg et. al. [Page 50] 03140 Internet Draft SIP February 18, 2002 03141 03142 03143 will forward the request to the contact addresses registered to that 03144 address-of-record. Generally, it only makes sense to register an 03145 address-of-record at a domain's location service when requests for 03146 that address-of-record would be routed to that domain. In most cases, 03147 this means that the domain of the registration will need to match the 03148 domain in the URI of the address-of-record. 03149 03150 There are many ways by which the contents of the location service can 03151 be established. One way is administratively. In the above example, 03152 Bob is known to be a member of the engineering department through 03153 access to a corporate database. However, SIP provides a mechanism for 03154 a UA to create a binding explicitly. This mechanism is known as 03155 registration. 03156 03157 Registration entails sending a REGISTER request to a special type of 03158 UAS known as a registrar. A registrar acts as the front end to the 03159 location service for a domain, reading and writing mappings based on 03160 the contents of REGISTER requests. This location service is then 03161 typically consulted by a proxy server that is responsible for routing 03162 requests for that domain. 03163 03164 An illustration of the overall registration process is given in 2. 03165 Note that the registrar and proxy server are logical roles that can 03166 be played by a single device in a network; for purposes of clarity 03167 the two are separated in this illustration. Also note that UAs may 03168 send requests through a proxy server in order to reach a registrar if 03169 the two are separate elements. 03170 03171 SIP does not mandate a particular mechanism for implementing the 03172 location service. The only requirement is that a registrar for some 03173 domain MUST be able to read and write data to the location service, 03174 and a proxy or redirect server for that domain MUST be capable of 03175 reading that same data. A registrar MAY be co-located with a 03176 particular SIP proxy server for the same domain. 03177 03178 03179 10.2 Constructing the REGISTER Request 03180 03181 REGISTER requests add, remove, and query bindings. A REGISTER request 03182 can add a new binding between an address-of-record and one or more 03183 contact addresses. Registration on behalf of a particular address- 03184 of-record can be performed by a suitably authorized third party. A 03185 client can also remove previous bindings or query to determine which 03186 bindings are currently in place for an address-of-record. 03187 03188 Except as noted, the construction of the REGISTER request and the 03189 behavior of clients sending a REGISTER request is identical to the 03190 general UAC behavior described in Section 8.1 and Section 17.1. 03191 03192 03193 03194 J. Rosenberg et. al. [Page 51] 03195 Internet Draft SIP February 18, 2002 03196 03197 03198 A REGISTER request does not establish a dialog. A UAC MAY include a 03199 Route header field in a REGISTER request based on a pre-existing 03200 route set as described in Section 8.1. The Record-Route header field 03201 has no meaning in REGISTER requests or responses, and MUST be ignored 03202 if present. In particular, the UAC MUST NOT create a new route set 03203 based on the presence or absence of a Record-Route header field in 03204 any response to a REGISTER request. 03205 03206 The following header fields, except Contact, MUST be included in a 03207 REGISTER request. A Contact header field MAY be included: 03208 03209 Request-URI: The Request-URI names the domain of the location 03210 service for which the registration is meant (for example, 03211 "sip:chicago.com"). The "userinfo" and "@" components of 03212 the SIP URI MUST NOT be present. 03213 03214 To: The To header field contains the address of record whose 03215 registration is to be created, queried, or modified. The To 03216 header field and the Request-URI field typically differ, as 03217 the former contains a user name. This address-of-record 03218 MUST be a SIP URI or SIPS URI. 03219 03220 From: The From header field contains the address-of-record of 03221 the person responsible for the registration. The value is 03222 the same as the To header field unless the request is a 03223 third-party registration. 03224 03225 Call-ID: All registrations from a UAC SHOULD use the same Call- 03226 ID header field value for registrations sent to a 03227 particular registrar. 03228 03229 03230 If the same client were to use different Call-ID 03231 values, a registrar could not detect whether a delayed 03232 REGISTER request might have arrived out of order. 03233 03234 CSeq: The CSeq value guarantees proper ordering of REGISTER 03235 requests. A UA MUST increment the CSeq value by one for 03236 each REGISTER request with the same Call-ID. 03237 03238 Contact: REGISTER requests MAY contain a Contact header field 03239 with zero or more values containing address bindings. 03240 03241 UAs MUST NOT send a new registration (that is, containing new Contact 03242 header field values, as opposed to a retransmission) until they have 03243 received a final response from the registrar for the previous one or 03244 the previous REGISTER request has timed out. 03245 03246 03247 03248 03249 J. Rosenberg et. al. [Page 52] 03250 Internet Draft SIP February 18, 2002 03251 03252 03253 03254 03255 03256 03257 bob 03258 +----+ 03259 | UA | 03260 | | 03261 +----+ 03262 | 03263 |3)INVITE 03264 | carol@chicago.com 03265 chicago.com +--------+ V 03266 +---------+ 2)Store|Location|4)Query +-----+ 03267 |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com 03268 +---------+ +--------+=======>+-----+ 03269 A 5)Resp | 03270 | | 03271 | | 03272 1)REGISTER| | 03273 | | 03274 +----+ | 03275 | UA |<-------------------------------+ 03276 cube2214a| | 6)INVITE 03277 +----+ carol@cube2214a.chicago.com 03278 carol 03279 03280 03281 03282 03283 03284 03285 03286 03287 03288 03289 03290 03291 03292 03293 03294 03295 03296 03297 03298 03299 03300 03301 03302 03303 Figure 2: REGISTER example 03304 03305 J. Rosenberg et. al. [Page 53] 03306 Internet Draft SIP February 18, 2002 03307 03308 03309 The following Contact header parameters have a special meaning in 03310 REGISTER requests: 03311 03312 action: The "action" parameter from RFC 2543 has been 03313 deprecated. UACs SHOULD NOT use the "action" parameter. 03314 03315 expires: The "expires" parameter indicates how long the UA would 03316 like the binding to be valid. The value is a number 03317 indicating seconds. If this parameter is not provided, the 03318 value of the Expires header field is used instead. 03319 Implementations MAY treat values larger than 2**32-1 03320 (4294967295 seconds or 136 years) as equivalent to 2**32-1. 03321 Malformed values SHOULD be treated as equivalent to 3600. 03322 03323 10.2.1 Adding Bindings 03324 03325 The REGISTER request sent to a registrar includes the contact 03326 address(es) to which SIP requests for the address-of-record should be 03327 forwarded. The address-of-record is included in the To header field 03328 of the REGISTER request. 03329 03330 The Contact header field values of the request typically consist of 03331 SIP or SIPS URIs that identify particular SIP endpoints (for example, 03332 "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. 03333 A SIP UA can choose to register telephone numbers (with the tel URL, 03334 [9]) or email addresses (with a mailto URL, [31]) as Contacts for an 03335 address-of-record, for example. 03336 03337 For example, Carol, with address-of-record "sip:carol@chicago.com", 03338 would register with the SIP registrar of the domain chicago.com. Her 03339 registrations would then be used by a proxy server in the chicago.com 03340 domain to route requests for Carol's address-of-record to her SIP 03341 endpoint. 03342 03343 Once a client has established bindings at a registrar, it MAY send 03344 subsequent registrations containing new bindings or modifications to 03345 existing bindings as necessary. The 2xx response to the REGISTER 03346 request will contain, in a Contact header field, a complete list of 03347 bindings that have been registered for this address-of-record at this 03348 registrar. 03349 03350 If the address-of-record in the To header field of a REGISTER request 03351 is a SIPS URI, then any Contact header field values in the request 03352 MUST also be a SIPS URIs. 03353 03354 Registrations do not need to update all bindings. Typically, a UA 03355 only updates its own contact addresses. 03356 03357 03358 03359 03360 J. Rosenberg et. al. [Page 54] 03361 Internet Draft SIP February 18, 2002 03362 03363 03364 10.2.1.1 Setting the Expiration Interval of Contact Addresses 03365 03366 When a client sends a REGISTER request, it MAY suggest an expiration 03367 interval that indicates how long the client would like the 03368 registration to be valid. (As described in Section 10.3, the 03369 registrar selects the actual time interval based on its local 03370 policy.) 03371 03372 There are two ways in which a client can suggest an expiration 03373 interval for a binding: through an Expires header field or an 03374 "expires" Contact header parameter. The latter allows expiration 03375 intervals to be suggested on a per-binding basis when more than one 03376 binding is given in a single REGISTER request, whereas the former 03377 suggests an expiration interval for all Contact header field values 03378 that do not contain the "expires" parameter. 03379 03380 If neither mechanism for expressing a suggested expiration time is 03381 present in a REGISTER, a default suggestion of one hour SHOULD be 03382 assumed. 03383 03384 10.2.1.2 Preferences among Contact Addresses 03385 03386 If more than one Contact is sent in a REGISTER request, the 03387 registering UA intends to associate all of the URIs in these Contact 03388 header field values with the address-of-record present in the To 03389 field. This list can be prioritized with the "q" parameter in the 03390 Contact header field. The "q" parameter indicates a relative 03391 preference for the particular Contact header field value compared to 03392 other bindings present in this REGISTER message or existing within 03393 the location service of the registrar. Section 16.6 describes how a 03394 proxy server uses this preference indication. 03395 03396 10.2.2 Removing Bindings 03397 03398 Registrations are soft state and expire unless refreshed, but can 03399 also be explicitly removed. A client can attempt to influence the 03400 expiration interval selected by the registrar as described in Section 03401 10.2.1. A UA requests the immediate removal of a binding by 03402 specifying an expiration interval of "0" for that contact address in 03403 a REGISTER request. UAs SHOULD support this mechanism so that 03404 bindings can be removed before their expiration interval has passed. 03405 03406 The REGISTER-specific Contact header field value of "*" applies to 03407 all registrations, but it MUST NOT be used unless the Expires header 03408 field is present with a value of "0". 03409 03410 03411 Use of the "*" Contact header field value allows a 03412 03413 03414 03415 J. Rosenberg et. al. [Page 55] 03416 Internet Draft SIP February 18, 2002 03417 03418 03419 registering UA to remove all of its bindings without 03420 knowing their precise values. 03421 03422 10.2.3 Fetching Bindings 03423 03424 A success response to any REGISTER request contains the complete list 03425 of existing bindings, regardless of whether the request contained a 03426 Contact header field. If no Contact header field is present in a 03427 REGISTER request, the list of bindings is left unchanged. 03428 03429 10.2.4 Refreshing Bindings 03430 03431 Each UA is responsible for refreshing the bindings that it has 03432 previously established. A UA SHOULD NOT refresh bindings set up by 03433 other UAs. 03434 03435 The 200 (OK) response from the registrar contains a list of Contact 03436 fields enumerating all current bindings. The UA compares each contact 03437 address to see if it created the contact address, using comparison 03438 rules in Section 19.1.4. If so, it updates the expiration time 03439 interval according to the expires parameter or, if absent, the 03440 Expires field value. The UA then issues a REGISTER request for each 03441 of its bindings before the expiration interval has elapsed. It MAY 03442 combine several updates into one REGISTER request. 03443 03444 A UA SHOULD use the same Call-ID for all registrations during a 03445 single boot cycle. Registration refreshes SHOULD be sent to the same 03446 network address as the original registration, unless redirected. 03447 03448 10.2.5 Setting the Internal Clock 03449 03450 If the response for a REGISTER request contains a Date header field, 03451 the client MAY use this header field to learn the current time in 03452 order to set any internal clocks. 03453 03454 10.2.6 Discovering a Registrar 03455 03456 UAs can use three ways to determine the address to which to send 03457 registrations: by configuration, using the address-of-record, and 03458 multicast. A UA can be configured, in ways beyond the scope of this 03459 specification, with a registrar address. If there is no configured 03460 registrar address, the UA SHOULD use the host part of the address- 03461 of-record as the Request-URI and address the request there, using the 03462 normal SIP server location mechanisms [4]. For example, the UA for 03463 the user "sip:carol@chicago.com" addresses the REGISTER request to 03464 "sip:chicago.com". 03465 03466 Finally, a UA can be configured to use multicast. Multicast 03467 03468 03469 03470 J. Rosenberg et. al. [Page 56] 03471 Internet Draft SIP February 18, 2002 03472 03473 03474 registrations are addressed to the well-known "all SIP servers" 03475 multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- 03476 known IPv6 multicast address has been allocated; such an allocation 03477 will be documented separately when needed. SIP UAs MAY listen to that 03478 address and use it to become aware of the location of other local 03479 users (see [32]); however, they do not respond to the request. 03480 03481 03482 Multicast registration may be inappropriate in some 03483 environments, for example, if multiple businesses share the 03484 same local area network. 03485 03486 10.2.7 Transmitting a Request 03487 03488 Once the REGISTER method has been constructed, and the destination of 03489 the message identified, UACs follow the procedures described in 03490 Section 8.1.2 to hand off the REGISTER to the transaction layer. 03491 03492 If the transaction layer returns a timeout error because the REGISTER 03493 yielded no response, the UAC SHOULD NOT immediately re-attempt a 03494 registration to the same registrar. 03495 03496 An immediate re-attempt is likely to also timeout. Waiting 03497 some reasonable time interval for the conditions causing 03498 the timeout to be corrected reduces unnecessary load on the 03499 network. No specific interval is mandated. 03500 03501 10.2.8 Error Responses 03502 03503 If a UA receives a 423 (Interval Too Brief) response, it MAY retry 03504 the registration after making the expiration interval of all contact 03505 addresses in the REGISTER request equal to or greater than the 03506 expiration interval within the Min-Expires header field of the 423 03507 (Interval Too Brief) response. 03508 03509 10.3 Processing REGISTER Requests 03510 03511 A registrar is a UAS that responds to REGISTER requests and maintains 03512 a list of bindings that are accessible to proxy servers and redirect 03513 servers within its administrative domain. A registrar handles 03514 requests according to Section 8.2 and Section 17.2, but it accepts 03515 only REGISTER requests. A registrar MUST not generate 6xx responses. 03516 03517 A registrar MAY redirect REGISTER requests as appropriate. One common 03518 usage would be for a registrar listening on a multicast interface to 03519 redirect multicast REGISTER requests to its own unicast interface 03520 with a 302 (Moved Temporarily) response. 03521 03522 03523 03524 03525 J. Rosenberg et. al. [Page 57] 03526 Internet Draft SIP February 18, 2002 03527 03528 03529 Registrars MUST ignore the Record-Route header field if it is 03530 included in a REGISTER request. Registrars MUST NOT include a 03531 Record-Route header field in any response to a REGISTER request. 03532 03533 03534 A registrar might receive a request that traversed a proxy 03535 which treats REGISTER as an unknown request and which added 03536 a Record-Route header field value. 03537 03538 A registrar has to know (for example, through configuration) the set 03539 of domain(s) for which it maintains bindings. REGISTER requests MUST 03540 be processed by a registrar in the order that they are received. 03541 REGISTER requests MUST also be processed atomically, meaning that a 03542 particular REGISTER request is either processed completely or not at 03543 all. Each REGISTER message MUST be processed independently of any 03544 other registration or binding changes. 03545 03546 When receiving a REGISTER request, a registrar follows these steps: 03547 03548 1. The registrar inspects the Request-URI to determine whether 03549 it has access to bindings for the domain identified in the 03550 Request-URI. If not, and if the server also acts as a proxy 03551 server, the server SHOULD forward the request to the 03552 addressed domain, following the general behavior for 03553 proxying messages described in Section 16. 03554 03555 2. To guarantee that the registrar supports any necessary 03556 extensions, the registrar MUST process the Require header 03557 field values as described for UASs in Section 8.2.2. 03558 03559 3. A registrar SHOULD authenticate the UAC. Mechanisms for the 03560 authentication of SIP user agents are described in Section 03561 22. Registration behavior in no way overrides the generic 03562 authentication framework for SIP. If no authentication 03563 mechanism is available, the registrar MAY take the From 03564 address as the asserted identity of the originator of the 03565 request. 03566 03567 4. The registrar SHOULD determine if the authenticated user is 03568 authorized to modify registrations for this address-of- 03569 record. For example, a registrar might consult a 03570 authorization database that maps user names to a list of 03571 addresses-of-record for which that user has authorization 03572 to modify bindings. If the authenticated user is not 03573 authorized to modify bindings, the registrar MUST return a 03574 403 (Forbidden) and skip the remaining steps. 03575 03576 03577 03578 03579 03580 J. Rosenberg et. al. [Page 58] 03581 Internet Draft SIP February 18, 2002 03582 03583 03584 In architectures that support third-party 03585 registration, one entity may be responsible for 03586 updating the registrations associated with multiple 03587 addresses-of-record. 03588 03589 5. The registrar extracts the address-of-record from the To 03590 header field of the request. If the address-of-record is 03591 not valid for the domain in the Request-URI, the registrar 03592 MUST send a 404 (Not Found) response and skip the remaining 03593 steps. The URI MUST then be converted to a canonical form. 03594 To do that, all URI parameters MUST be removed (including 03595 the user-param), and any escaped characters MUST be 03596 converted to their unescaped form. The result serves as an 03597 index into the list of bindings. 03598 03599 6. The registrar checks whether the request contains the 03600 Contact header field. If not, it skips to the last step. 03601 If the Contact header field is present, the registrar 03602 checks if there is one Contact field value that contains 03603 the special value "*" and an Expires field. If the request 03604 has additional Contact fields or an expiration time other 03605 than zero, the request is invalid, and the server MUST 03606 return a 400 Invalid Request and skip the remaining steps. 03607 If not, the registrar checks whether the Call-ID agrees 03608 with the value stored for each binding. If not, it MUST 03609 remove the binding. If it does agree, it MUST remove the 03610 binding only if the CSeq in the request is higher than the 03611 value stored for that binding. Otherwise the registrar MUST 03612 leave the binding as is. It then skips to the last step. 03613 03614 7. If the address-of-record in the To header field of the 03615 request represents a SIPS URI, then the registrar MUST 03616 discard any Contact header field values that do not use the 03617 SIPS URI scheme before performing any further processing. 03618 03619 8. The registrar now processes each contact address in the 03620 Contact header field in turn. For each address, it 03621 determines the expiration interval as follows: 03622 03623 - If the field value has an "expires" parameter, that value 03624 MUST be used. 03625 03626 - If there is no such parameter, but the request has an 03627 Expires header field, that value MUST be used. 03628 03629 - If there is neither, a locally-configured default value 03630 MUST be used. 03631 03632 03633 03634 03635 J. Rosenberg et. al. [Page 59] 03636 Internet Draft SIP February 18, 2002 03637 03638 03639 The registrar MAY shorten the expiration interval. If and 03640 only if the expiration interval is greater than zero AND 03641 smaller than one hour AND less than a registrar-configured 03642 minimum, the registrar MAY reject the registration with a 03643 response of 423 (Registration Too Brief). This response 03644 MUST contain a Min-Expires header field that states the 03645 minimum expiration interval the registrar is willing to 03646 honor. It then skips the remaining steps. 03647 03648 03649 Allowing the registrar to set the registration 03650 interval protects it against excessively frequent 03651 registration refreshes while limiting the state that 03652 it needs to maintain and decreasing the likelihood of 03653 registrations going stale. The expiration interval of 03654 a registration is frequently used in the creation of 03655 services. An example is a follow-me service, where the 03656 user may only be available at a terminal for a brief 03657 period. Therefore, registrars should accept brief 03658 registrations; a request should only be rejected if 03659 the interval is so short that the refreshes would 03660 degrade registrar performance. 03661 03662 For each address, the registrar then searches the list of 03663 current bindings using the URI comparison rules. If the 03664 binding does not exist, it is tentatively added. If the 03665 binding does exist, the registrar checks the Call-ID value. 03666 If the Call-ID value in the existing binding differs from 03667 the Call-ID value in the request, the binding MUST be 03668 removed if the expiration time is zero and updated 03669 otherwise. If they are the same, the registrar compares 03670 the CSeq value. If the value is higher than that of the 03671 existing binding, it MUST update or remove the binding as 03672 above. If not, the update MUST be aborted and the request 03673 fails. 03674 03675 03676 This algorithm ensures that out-of-order requests from 03677 the same UA are ignored. 03678 03679 Each binding record records the Call-ID and CSeq values 03680 from the request. 03681 03682 The binding updates MUST be committed (that is, made 03683 visible to the proxy or redirect server) if and only if all 03684 binding updates and additions succeed. If any one of them 03685 fails (for example, because the back-end database commit 03686 failed), the request MUST fail with a 500 (Server Error) 03687 03688 03689 03690 J. Rosenberg et. al. [Page 60] 03691 Internet Draft SIP February 18, 2002 03692 03693 03694 response and all tentative binding updates MUST be removed. 03695 03696 9. The registrar returns a 200 (OK) response. The response 03697 MUST contain Contact header field values enumerating all 03698 current bindings. Each Contact value MUST feature an 03699 "expires" parameter indicating its expiration interval 03700 chosen by the registrar. The response SHOULD include a 03701 Date header field. 03702 03703 11 Querying for Capabilities 03704 03705 The SIP method OPTIONS allows a UA to query another UA or a proxy 03706 server as to its capabilities. This allows a client to discover 03707 information about the supported methods, content types, extensions, 03708 codecs, etc. without "ringing" the other party. For example, before a 03709 client inserts a Require header field into an INVITE listing an 03710 option that it is not certain the destination UAS supports, the 03711 client can query the destination UAS with an OPTIONS to see if this 03712 option is returned in a Supported header field. 03713 03714 The target of the OPTIONS request is identified by the Request-URI, 03715 which could identify another UA or a SIP server. If the OPTIONS is 03716 addressed to a proxy server, the Request-URI is set without a user 03717 part, similar to the way a Request-URI is set for a REGISTER request. 03718 03719 Alternatively, a server receiving an OPTIONS request with a Max- 03720 Forwards header field value of 0 MAY respond to the request 03721 regardless of the Request-URI. 03722 03723 03724 This behavior is common with HTTP/1.1. This behavior can be 03725 used as a "traceroute" functionality to check the 03726 capabilities of individual hop servers by sending a series 03727 of OPTIONS requests with incremented Max-Forwards values. 03728 03729 As is the case for general UA behavior, the transaction layer can 03730 return a timeout error if the OPTIONS yields no response. This may 03731 indicate that the target is unreachable and hence unavailable. 03732 03733 An OPTIONS request MAY be sent as part of an established dialog to 03734 query the peer on capabilities that may be utilized later in the 03735 dialog. 03736 03737 11.1 Construction of OPTIONS Request 03738 03739 An OPTIONS request is constructed using the standard rules for a SIP 03740 request as discussed Section 8.1.1. 03741 03742 03743 03744 03745 J. Rosenberg et. al. [Page 61] 03746 Internet Draft SIP February 18, 2002 03747 03748 03749 A Contact header field MAY be present in an OPTIONS. 03750 03751 An Accept header field SHOULD be included to indicate the type of 03752 message body the UAC wishes to receive in the response. Typically, 03753 this is set to a format that is used to describe the media 03754 capabilities of a UA, such as SDP (application/sdp). 03755 03756 The response to an OPTIONS request is assumed to be scoped to the 03757 Request-URI in the original request. However, only when an OPTIONS is 03758 sent as part of an established dialog is it guaranteed that future 03759 requests will be received by the server that generated the OPTIONS 03760 response. 03761 03762 Example OPTIONS request: 03763 03764 03765 OPTIONS sip:carol@chicago.com SIP/2.0 03766 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 03767 Max-Forwards: 70 03768 To: 03769 From: Alice ;tag=1928301774 03770 Call-ID: a84b4c76e66710 03771 CSeq: 63104 OPTIONS 03772 Contact: 03773 Accept: application/sdp 03774 Content-Length: 0 03775 03776 03777 03778 11.2 Processing of OPTIONS Request 03779 03780 The response to an OPTIONS is constructed using the standard rules 03781 for a SIP response as discussed in Section 8.2.6. The response code 03782 chosen MUST be the same that would have been chosen had the request 03783 been an INVITE. That is, a 200 (OK) would be returned if the UAS is 03784 ready to accept a call, a 486 (Busy Here) would be returned if the 03785 UAS is busy, etc. This allows an OPTIONS request to be used to 03786 determine the basic state of a UAS, which can be an indication of 03787 whether the UAC will accept an INVITE request. 03788 03789 An OPTIONS request received within a dialog generates a 200 (OK) 03790 response that is identical to one constructed outside a dialog and 03791 does not have any impact on the dialog. 03792 03793 This use of OPTIONS has limitations due the differences in proxy 03794 handling of OPTIONS and INVITE requests. While a forked INVITE can 03795 result in multiple 200 (OK) responses being returned, a forked 03796 OPTIONS will only result in a single 200 (OK) response, since it is 03797 03798 03799 03800 J. Rosenberg et. al. [Page 62] 03801 Internet Draft SIP February 18, 2002 03802 03803 03804 treated by proxies using the non-INVITE handling. See Section 16.7 03805 for the normative details. 03806 03807 If the response to an OPTIONS is generated by a proxy server, the 03808 proxy returns a 200 (OK) listing the capabilities of the server. The 03809 response does not contain a message body. 03810 03811 Allow, Accept, Accept-Encoding, Accept-Language, and Supported header 03812 fields SHOULD be present in a 200 (OK) response to an OPTIONS 03813 request. If the response is generated by a proxy, the Allow header 03814 field SHOULD be omitted as it is ambiguous since a proxy is method 03815 agnostic. Contact header fields MAY be present in a 200 (OK) response 03816 and have the same semantics as in a 3xx response. That is, they may 03817 list a set of alternative names and methods of reaching the user. A 03818 Warning header field MAY be present. 03819 03820 A message body MAY be sent, the type of which is determined by the 03821 Accept header field in the OPTIONS request (application/sdp is the 03822 default if the Accept header field is not present). If the types 03823 include one that can describe media capabilities, the UAS SHOULD 03824 include a body in the response for that purpose. Details on 03825 construction of such a body in the case of application/sdp are 03826 described in [13]. 03827 03828 Example OPTIONS response generated by a UAS (corresponding to the 03829 request in Section 11.1): 03830 03831 03832 SIP/2.0 200 OK 03833 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 03834 ;received=192.0.2.4 03835 To: ;tag=93810874 03836 From: Alice ;tag=1928301774 03837 Call-ID: a84b4c76e66710 03838 CSeq: 63104 OPTIONS 03839 Contact: 03840 Contact: 03841 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE 03842 Accept: application/sdp 03843 Accept-Encoding: gzip 03844 Accept-Language: en 03845 Supported: foo 03846 Content-Type: application/sdp 03847 Content-Length: 274 03848 03849 (SDP not shown) 03850 03851 03852 03853 03854 03855 J. Rosenberg et. al. [Page 63] 03856 Internet Draft SIP February 18, 2002 03857 03858 03859 12 Dialogs 03860 03861 A key concept for a user agent is that of a dialog. A dialog 03862 represents a peer-to-peer SIP relationship between two user agents 03863 that persists for some time. The dialog facilitates sequencing of 03864 messages between the user agents and proper routing of requests 03865 between both of them. The dialog represents a context in which to 03866 interpret SIP messages. Section 8 discussed method independent UA 03867 processing for requests and responses outside of a dialog. This 03868 section discusses how those requests and responses are used to 03869 construct a dialog, and then how subsequent requests and responses 03870 are sent within a dialog. 03871 03872 A dialog is identified at each UA with a dialog ID, which consists of 03873 a Call-ID value, a local tag and a remote tag. The dialog ID at each 03874 UA involved in the dialog is not the same. Specifically, the local 03875 tag at one UA is identical to the remote tag at the peer UA. The tags 03876 are opaque tokens that facilitate the generation of unique dialog 03877 IDs. 03878 03879 A dialog ID is also associated with all responses and with any 03880 request that contains a tag in the To field. The rules for computing 03881 the dialog ID of a message depend on whether the SIP element is a UAC 03882 or UAS. For a UAC, the Call-ID value of the dialog ID is set to the 03883 Call-ID of the message, the remote tag is set to the tag in the To 03884 field of the message, and the local tag is set to the tag in the From 03885 field of the message (these rules apply to both requests and 03886 responses). As one would expect, for a UAS, the Call-ID value of the 03887 dialog ID is set to the Call-ID of the message, the remote tag is set 03888 to the tag in the From field of the message, and the local tag is set 03889 to the tag in the To field of the message. 03890 03891 A dialog contains certain pieces of state needed for further message 03892 transmissions within the dialog. This state consists of the dialog 03893 ID, a local sequence number (used to order requests from the UA to 03894 its peer), a remote sequence number (used to order requests from its 03895 peer to the UA), a local URI, a remote URI, the Contact URI of the 03896 peer, a boolean flag called "secure", and a route set, which is an 03897 ordered list of URIs. The route set is the list of servers that need 03898 to be traversed to send a request to the peer. A dialog can also be 03899 in the "early" state, which occurs when it is created with a 03900 provisional response, and then transition to the "confirmed" state 03901 when a 2xx final response arrives. For other responses, or if no 03902 response arrives at all on that dialog, the early dialog terminates. 03903 03904 12.1 Creation of a Dialog 03905 03906 Dialogs are created through the generation of non-failure responses 03907 03908 03909 03910 J. Rosenberg et. al. [Page 64] 03911 Internet Draft SIP February 18, 2002 03912 03913 03914 to requests with specific methods. Within this specification, only 03915 2xx and 101-199 responses with a To tag to INVITE establish a dialog. 03916 A dialog established by a non-final response to a request is in the 03917 "early" state and it is called an early dialog. Extensions MAY define 03918 other means for creating dialogs. Section 13 gives more details that 03919 are specific to the INVITE method. Here, we describe the process for 03920 creation of dialog state that is not dependent on the method. 03921 03922 UAs MUST assign values to the dialog ID components as described 03923 below. 03924 03925 12.1.1 UAS behavior 03926 03927 When a UAS responds to a request with a response that establishes a 03928 dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route 03929 header field values from the request into the response (including the 03930 URIs, URI parameters, and any Record-Route header field parameters, 03931 whether they are known or unknown to the UAS) and MUST maintain the 03932 order of those values. The UAS MUST add a Contact header field to the 03933 response. The Contact header field contains an address where the UAS 03934 would like to be contacted for subsequent requests in the dialog 03935 (which includes the ACK for a 2xx response in the case of an INVITE). 03936 Generally, the host portion of this URI is the IP address or FQDN of 03937 the host. The URI provided in the Contact header field MUST be a SIP 03938 or SIPS URI. If the request which initiated the dialog contained a 03939 SIPS URI in the Request-URI, the Contact header field MUST be a SIPS 03940 URI. In either case, the URI SHOULD have global scope (that is, the 03941 same URI can be used in messages outside this dialog). The same way, 03942 the scope of the URI in the Contact header field of the INVITE is not 03943 limited to this dialog either. It can therefore be used in messages 03944 to the UAC even outside this dialog. 03945 03946 The UAS then constructs the state of the dialog. This state MUST be 03947 maintained for the duration of the dialog. 03948 03949 If the request arrived over TLS, and the Request-URI contained a SIPS 03950 URI, the "secure" flag is set to TRUE. 03951 03952 The route set MUST be set to the list of URIs in the Record-Route 03953 header field from the request, taken in order and preserving all URI 03954 parameters. If no Record-Route header field is present in the 03955 request, the route set MUST be set to the empty set. This route set, 03956 even if empty, overrides any pre-existing route set for future 03957 requests in this dialog. The remote target MUST be set to the URI 03958 from the Contact header field of the request. If the "secure" flag 03959 is true, the UA MUST convert any SIP URI in the route set and remote 03960 target to SIPS URI (this is done by just changing the scheme). 03961 03962 03963 03964 03965 J. Rosenberg et. al. [Page 65] 03966 Internet Draft SIP February 18, 2002 03967 03968 03969 The remote sequence number MUST be set to the value of the sequence 03970 number in the CSeq header field of the request. The local sequence 03971 number MUST be empty. The call identifier component of the dialog ID 03972 MUST be set to the value of the Call-ID in the request. The local tag 03973 component of the dialog ID MUST be set to the tag in the To field in 03974 the response to the request (which always includes a tag), and the 03975 remote tag component of the dialog ID MUST be set to the tag from the 03976 From field in the request. A UAS MUST be prepared to receive a 03977 request without a tag in the From field, in which case the tag is 03978 considered to have a value of null. 03979 03980 This is to maintain backwards compatibility with RFC 2543, 03981 which did not mandate From tags. 03982 03983 The remote URI MUST be set to the URI in the From field, and the 03984 local URI MUST be set to the URI in the To field. 03985 03986 12.1.2 UAC Behavior 03987 03988 When a UAC sends a request that can establish a dialog (such as an 03989 INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., 03990 the same SIP URI can be used in messages outside this dialog) in the 03991 Contact header field of the request. If the request is sent to a 03992 Request-URI with a SIPS URI, the Contact header MUST be a SIPS URI. 03993 03994 When a UAC receives a response that establishes a dialog, it 03995 constructs the state of the dialog. This state MUST be maintained for 03996 the duration of the dialog. 03997 03998 If the request was sent over TLS, and the Request-URI contained a 03999 SIPS URI, the "secure" flag is set to TRUE. 04000 04001 The route set MUST be set to the list of URIs in the Record-Route 04002 header field from the response, taken in reverse order and preserving 04003 all URI parameters. If no Record-Route header field is present in the 04004 response, the route set MUST be set to the empty set. This route set, 04005 even if empty, overrides any pre-existing route set for future 04006 requests in this dialog. The remote target MUST be set to the URI 04007 from the Contact header field of the response. If the "secure" flag 04008 is true, the UA MUST convert any SIP URI in the route set and remote 04009 target to SIPS URI (this is done by just changing the scheme). 04010 04011 The local sequence number MUST be set to the value of the sequence 04012 number in the CSeq header field of the request. The remote sequence 04013 number MUST be empty (it is established when the remote UA sends a 04014 request within the dialog). The call identifier component of the 04015 dialog ID MUST be set to the value of the Call-ID in the request. The 04016 local tag component of the dialog ID MUST be set to the tag in the 04017 04018 04019 04020 J. Rosenberg et. al. [Page 66] 04021 Internet Draft SIP February 18, 2002 04022 04023 04024 From field in the request, and the remote tag component of the dialog 04025 ID MUST be set to the tag in the To field of the response. A UAC 04026 MUST be prepared to receive a response without a tag in the To field, 04027 in which case the tag is considered to have a value of null. 04028 04029 This is to maintain backwards compatibility with RFC 2543, 04030 which did not mandate To tags. 04031 04032 The remote URI MUST be set to the URI in the To field, and the local 04033 URI MUST be set to the URI in the From field. 04034 04035 12.2 Requests within a Dialog 04036 04037 Once a dialog has been established between two UAs, either of them 04038 MAY initiate new transactions as needed within the dialog. The UA 04039 sending the request will take the UAC role for the transaction. The 04040 UA receiving the request will take the UAS role. Note that these may 04041 be different roles than the UAs held during the transaction that 04042 established the dialog. 04043 04044 Requests within a dialog MAY contain Record-Route and Contact header 04045 fields. However, these requests do not cause the dialog's route set 04046 to be modified, although they may modify the remote target URI. 04047 Specifically, requests that are not target refresh requests do not 04048 modify the dialog's remote target URI, and requests that are target 04049 refresh requests do. For dialogs that have been established with an 04050 INVITE, the only target refresh request defined is re-INVITE (see 04051 Section 14). Other extensions may define different target refresh 04052 requests for dialogs established in other ways. 04053 04054 Note that an ACK is NOT a target refresh request. 04055 04056 Target refresh requests only update the dialog's remote target URI, 04057 and not the route set formed from Record-Route. Updating the latter 04058 would introduce severe backwards compatibility problems with RFC 04059 2543-compliant systems. 04060 04061 12.2.1 UAC Behavior 04062 04063 12.2.1.1 Generating the Request 04064 04065 A request within a dialog is constructed by using many of the 04066 components of the state stored as part of the dialog. 04067 04068 The URI in the To field of the request MUST be set to the remote URI 04069 from the dialog state. The tag in the To header field of the request 04070 MUST be set to the remote tag of the dialog ID. The From URI of the 04071 request MUST be set to the local URI from the dialog state. The tag 04072 04073 04074 04075 J. Rosenberg et. al. [Page 67] 04076 Internet Draft SIP February 18, 2002 04077 04078 04079 in the From header field of the request MUST be set to the local tag 04080 of the dialog ID. If the value of the remote or local tags is null, 04081 the tag parameter MUST be omitted from the To or From header fields, 04082 respectively. 04083 04084 04085 Usage of the URI from the To and From fields in the 04086 original request within subsequent requests is done for 04087 backwards compatibility with RFC 2543, which used the URI 04088 for dialog identification. In this specification, only the 04089 tags are used for dialog identification. It is expected 04090 that mandatory reflection of the original To and From URI 04091 in mid-dialog requests will be deprecated in a subsequent 04092 revision of this specification. 04093 04094 The Call-ID of the request MUST be set to the Call-ID of the dialog. 04095 Requests within a dialog MUST contain strictly monotonically 04096 increasing and contiguous CSeq sequence numbers (increasing-by-one) 04097 in each direction (excepting ACK and CANCEL of course, whose numbers 04098 equal the requests being acknowledged or cancelled). Therefore, if 04099 the local sequence number is not empty, the value of the local 04100 sequence number MUST be incremented by one, and this value MUST be 04101 placed into the CSeq header field. If the local sequence number is 04102 empty, an initial value MUST be chosen using the guidelines of 04103 Section 8.1.1.5. The method field in the CSeq header field value MUST 04104 match the method of the request. 04105 04106 04107 With a length of 32 bits, a client could generate, within a 04108 single call, one request a second for about 136 years 04109 before needing to wrap around. The initial value of the 04110 sequence number is chosen so that subsequent requests 04111 within the same call will not wrap around. A non-zero 04112 initial value allows clients to use a time-based initial 04113 sequence number. A client could, for example, choose the 31 04114 most significant bits of a 32-bit second clock as an 04115 initial sequence number. 04116 04117 The UAC uses the remote target and route set to build the Request-URI 04118 and Route header field of the request. 04119 04120 If the route set is empty, the UAC MUST place the remote target URI 04121 into the Request-URI. The UAC MUST NOT add a Route header field to 04122 the request. 04123 04124 If the route set is not empty, and the first URI in the route set 04125 contains the lr parameter (see Section 19.1.1), the UAC MUST place 04126 the remote target URI into the Request-URI and MUST include a Route 04127 04128 04129 04130 J. Rosenberg et. al. [Page 68] 04131 Internet Draft SIP February 18, 2002 04132 04133 04134 header field containing the route set values in order, including all 04135 parameters. 04136 04137 If the route set is not empty, and its first URI does not contain the 04138 lr parameter, the UAC MUST place the first URI from the route set 04139 into the Request-URI, stripping any parameters that are not allowed 04140 in a Request-URI. The UAC MUST add a Route header field containing 04141 the remainder of the route set values in order, including all 04142 parameters. The UAC MUST then place the remote target URI into the 04143 Route header field as the last value. 04144 04145 For example, if the remote target is sip:user@remoteua and the route 04146 set contains 04147 04148 ,,, 04149 04150 04151 The request will be formed with the following Request-URI and Route 04152 header field: 04153 04154 METHOD sip:proxy1 04155 Route: ,,, 04156 04157 04158 04159 04160 If the first URI of the route set does not contain the lr 04161 parameter, the proxy indicated does not understand the 04162 routing mechanisms described in this document and will act 04163 as specified in RFC 2543, replacing the Request-URI with 04164 the first Route header field value it receives while 04165 forwarding the message. Placing the Request-URI at the end 04166 of the Route header field preserves the information in that 04167 Request-URI across the strict router (it will be returned 04168 to the Request-URI when the request reaches a loose- 04169 router). 04170 04171 A UAC SHOULD include a Contact header field in any target refresh 04172 requests within a dialog, and unless there is a need to change it, 04173 the URI SHOULD be the same as used in previous requests within the 04174 dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. 04175 As discussed in Section 12.2.2, a Contact header field in a target 04176 refresh request updates the remote target URI. This allows a UA to 04177 provide a new contact address, should its address change during the 04178 duration of the dialog. 04179 04180 However, requests that are not target refresh requests do not affect 04181 the remote target URI for the dialog. 04182 04183 04184 04185 J. Rosenberg et. al. [Page 69] 04186 Internet Draft SIP February 18, 2002 04187 04188 04189 The rest of the request is formed as described in Section 8.1.1. 04190 04191 Once the request has been constructed, the address of the server is 04192 computed and the request is sent, using the same procedures for 04193 requests outside of a dialog (Section 8.1.2). 04194 04195 04196 The procedures in Section 8.1.2 will normally result in the 04197 request being sent to the address indicated by the topmost 04198 Route header field value or the Request-URI if no Route 04199 header field is present. Subject to certain restrictions, 04200 they allow the request to be sent to an alternate address 04201 (such as a default outbound proxy not represented in the 04202 route set). 04203 04204 12.2.1.2 Processing the Responses 04205 04206 The UAC will receive responses to the request from the transaction 04207 layer. If the client transaction returns a timeout this is treated as 04208 a 408 (Request Timeout) response. 04209 04210 The behavior of a UAC that receives a 3xx response for a request sent 04211 within a dialog is the same as if the request had been sent outside a 04212 dialog. This behavior is described in Section 8.1.3.4. 04213 04214 04215 Note, however, that when the UAC tries alternative 04216 locations, it still uses the route set for the dialog to 04217 build the Route header of the request. 04218 04219 When a UAC receives a 2xx response to a target refresh request, it 04220 MUST replace the dialog's remote target URI with the URI from the 04221 Contact header field in that response, if present. If the "secure" 04222 flag is true, the UAC MUST convert the URI to a SIPS URI if it is not 04223 one already. 04224 04225 If the response for a request within a dialog is a 481 04226 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC 04227 SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if 04228 no response at all is received for the request (the client 04229 transaction would inform the TU about the timeout.) 04230 04231 For INVITE initiated dialogs, terminating the dialog 04232 consists of sending a BYE. 04233 04234 12.2.2 UAS Behavior 04235 04236 Requests sent within a dialog, as any other requests, are atomic. If 04237 04238 04239 04240 J. Rosenberg et. al. [Page 70] 04241 Internet Draft SIP February 18, 2002 04242 04243 04244 a particular request is accepted by the UAS, all the state changes 04245 associated with it are performed. If the request is rejected, none of 04246 the state changes is performed. 04247 04248 Note that some requests such as INVITEs affect several 04249 pieces of state. 04250 04251 The UAS will receive the request from the transaction layer. If the 04252 request has a tag in the To header field, the UAS core computes the 04253 dialog identifier corresponding to the request and compares it with 04254 existing dialogs. If there is a match, this is a mid-dialog request. 04255 In that case, the UAS first applies the same processing rules for 04256 requests outside of a dialog, discussed in Section 8.2. 04257 04258 If the request has a tag in the To header field, but the dialog 04259 identifier does not match any existing dialogs, the UAS may have 04260 crashed and restarted, or it may have received a request for a 04261 different (possibly failed) UAS (the UASs can construct the To tags 04262 so that a UAS can identify that the tag was for a UAS for which it is 04263 providing recovery). Another possibility is that the incoming request 04264 has been simply misrouted. Based on the To tag, the UAS MAY either 04265 accept or reject the request. Accepting the request for acceptable To 04266 tags provides robustness, so that dialogs can persist even through 04267 crashes. UAs wishing to support this capability must take into 04268 consideration some issues such as choosing monotonically increasing 04269 CSeq sequence numbers even across reboots, reconstructing the route 04270 set, and accepting out-of-range RTP timestamps and sequence numbers. 04271 04272 If the UAS wishes to reject the request, because it does not wish to 04273 recreate the dialog, it MUST respond to the request with a 481 04274 (Call/Transaction Does Not Exist) status code and pass that to the 04275 server transaction. 04276 04277 Requests that do not change in any way the state of a dialog may be 04278 received within a dialog (for example, an OPTIONS request). They are 04279 processed as if they had been received outside the dialog. 04280 04281 If the remote sequence number is empty, it MUST be set to the value 04282 of the sequence number in the CSeq header field value in the request. 04283 If the remote sequence number was not empty, but the sequence number 04284 of the request is lower than the remote sequence number, the request 04285 is out of order and MUST be rejected with a 500 (Server Internal 04286 Error) response. If the remote sequence number was not empty, and the 04287 sequence number of the request is greater than the remote sequence 04288 number, the request is in order. It is possible for the CSeq sequence 04289 number to be higher than the remote sequence number by more than one. 04290 This is not an error condition, and a UAS SHOULD be prepared to 04291 receive and process requests with CSeq values more than one higher 04292 04293 04294 04295 J. Rosenberg et. al. [Page 71] 04296 Internet Draft SIP February 18, 2002 04297 04298 04299 than the previous received request. The UAS MUST then set the remote 04300 sequence number to the value of the sequence number in the CSeq 04301 header field value in the request. 04302 04303 If a proxy challenges a request generated by the UAC, the 04304 UAC has to resubmit the request with credentials. The 04305 resubmitted request will have a new CSeq number. The UAS 04306 will never see the first request, and thus, it will notice 04307 a gap in the CSeq number space. Such a gap does not 04308 represent any error condition. 04309 04310 When a UAS receives a target refresh request, it MUST replace the 04311 dialog's remote target URI with the URI from the Contact header field 04312 in that request, if present. If the "secure" flag is true, the UAC 04313 MUST convert the URI to a SIPS URI if it is not one already. 04314 04315 12.3 Termination of a Dialog 04316 04317 Independent of the method, if a request outside of a dialog generates 04318 a non-2xx final response, any early dialogs created through 04319 provisional responses to that request are terminated. The mechanism 04320 for terminating confirmed dialogs is method specific. In this 04321 specification, the BYE method terminates a session and the dialog 04322 associated with it. See Section 15 for details. 04323 04324 13 Initiating a Session 04325 04326 13.1 Overview 04327 04328 When a user agent client desires to initiate a session (for example, 04329 audio, video, or a game), it formulates an INVITE request. The INVITE 04330 request asks a server to establish a session. This request may be 04331 forwarded by proxies, eventually arriving at one or more UAS that can 04332 potentially accept the invitation. These UASs will frequently need to 04333 query the user about whether to accept the invitation. After some 04334 time, those UAS can accept the invitation (meaning the session is to 04335 be established) by sending a 2xx response. If the invitation is not 04336 accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the 04337 reason for the rejection. Before sending a final response, the UAS 04338 can also send provisional responses (1xx) to advise the UAC of 04339 progress in contacting the called user. 04340 04341 After possibly receiving one or more provisional responses, the UAC 04342 will get one or more 2xx responses or one non-2xx final response. 04343 Because of the protracted amount of time it can take to receive final 04344 responses to INVITE, the reliability mechanisms for INVITE 04345 transactions differ from those of other requests (like OPTIONS). Once 04346 it receives a final response, the UAC needs to send an ACK for every 04347 04348 04349 04350 J. Rosenberg et. al. [Page 72] 04351 Internet Draft SIP February 18, 2002 04352 04353 04354 final response it receives. The procedure for sending this ACK 04355 depends on the type of response. For final responses between 300 and 04356 699, the ACK processing is done in the transaction layer and follows 04357 one set of rules (See Section 17). For 2xx responses, the ACK is 04358 generated by the UAC core. 04359 04360 A 2xx response to an INVITE establishes a session, and it also 04361 creates a dialog between the UA that issued the INVITE and the UA 04362 that generated the 2xx response. Therefore, when multiple 2xx 04363 responses are received from different remote UAs (because the INVITE 04364 forked), each 2xx establishes a different dialog. All these dialogs 04365 are part of the same call. 04366 04367 This section provides details on the establishment of a session using 04368 INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and 04369 BYE. 04370 04371 13.2 UAC Processing 04372 04373 13.2.1 Creating the Initial INVITE 04374 04375 Since the initial INVITE represents a request outside of a dialog, 04376 its construction follows the procedures of Section 8.1.1. Additional 04377 processing is required for the specific case of INVITE. 04378 04379 An Allow header field (Section 20.5) SHOULD be present in the INVITE. 04380 It indicates what methods can be invoked within a dialog, on the UA 04381 sending the INVITE, for the duration of the dialog. For example, a UA 04382 capable of receiving INFO requests within a dialog [33] SHOULD 04383 include an Allow header field listing the INFO method. 04384 04385 A Supported header field (Section 20.37) SHOULD be present in the 04386 INVITE. It enumerates all the extensions understood by the UAC. 04387 04388 An Accept (Section 20.1) header field MAY be present in the INVITE. 04389 It indicates which Content-Types are acceptable to the UA, in both 04390 the response received by it, and in any subsequent requests sent to 04391 it within dialogs established by the INVITE. The Accept header field 04392 is especially useful for indicating support of various session 04393 description formats. 04394 04395 The UAC MAY add an Expires header field (Section 20.19) to limit the 04396 validity of the invitation. If the time indicated in the Expires 04397 header field is reached and no final answer for the INVITE has been 04398 received the UAC core SHOULD generate a CANCEL request for the 04399 INVITE, as per Section 9. 04400 04401 A UAC MAY also find it useful to add, among others, Subject (Section 04402 04403 04404 04405 J. Rosenberg et. al. [Page 73] 04406 Internet Draft SIP February 18, 2002 04407 04408 04409 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) 04410 header fields. They all contain information related to the INVITE. 04411 04412 The UAC MAY choose to add a message body to the INVITE. Section 04413 8.1.1.10 deals with how to construct the header fields -- Content- 04414 Type among others -- needed to describe the message body. 04415 04416 There are special rules for message bodies that contain a session 04417 description - their corresponding Content-Disposition is "session". 04418 SIP uses an offer/answer model where one UA sends a session 04419 description, called the offer, which contains a proposed description 04420 of the session. The offer indicates the desired communications means 04421 (audio, video, games), parameters of those means (such as codec 04422 types) and addresses for receiving media from the answerer. The other 04423 UA responds with another session description, called the answer, 04424 which indicates which communications means are accepted, the 04425 parameters that apply to those means, and addresses for receiving 04426 media from the offerer. The offer/answer model defines restrictions 04427 on when offers and answers can be made. This results in restrictions 04428 on where the offers and answers can appear in SIP messages. In this 04429 specification, offers and answers can only appear in INVITE requests 04430 and responses, and ACK. The usage of offers and answers is further 04431 restricted. For the initial INVITE transaction, the rules are: 04432 04433 o The initial offer MUST be in either an INVITE or, if not 04434 there, in the first reliable non-failure message from the UAS 04435 back to the UAC. In this specification, that is the final 2xx 04436 response. 04437 04438 o If the initial offer is in an INVITE, the answer MUST be in a 04439 reliable non-failure message from UAS back to UAC which is 04440 correlated to that INVITE. For this specification, that is 04441 only the final 2xx response to that INVITE. 04442 04443 o If the initial offer is in the first reliable non-failure 04444 message from the UAS back to UAC, the answer MUST be in the 04445 acknowledgement for that message (in this specification, ACK 04446 for a 2xx response). 04447 04448 o After having sent or received an answer to the first offer, 04449 the UAC MAY generate subsequent offers in requests, but only 04450 if it has received answers to any previous offers, and has not 04451 sent any offers to which it hasn't gotten an answer. 04452 04453 o Once the UAS has sent or received an answer to the initial 04454 offer, it MUST NOT generate subsequent offers in any responses 04455 to the initial INVITE. This means that a UAS based on this 04456 specification alone can never generate subsequent offers until 04457 04458 04459 04460 J. Rosenberg et. al. [Page 74] 04461 Internet Draft SIP February 18, 2002 04462 04463 04464 completion of the initial transaction. 04465 04466 Concretely, the above rules specify two exchanges - the offer is in 04467 the INVITE, and the answer in the 2xx, or the offer is in the 2xx, 04468 and the answer is in the ACK. All user agents that support INVITE 04469 MUST support these two exchanges. 04470 04471 The Session Description Protocol (SDP) [1] MUST be supported by all 04472 user agents as a means to describe sessions, and its usage for 04473 constructing offers and answers MUST follow the procedures defined in 04474 [13]. 04475 04476 The restrictions of the offer-answer model just described only apply 04477 to bodies whose Content-Disposition header field value is "session". 04478 Therefore, it is possible that both the INVITE and the ACK contain a 04479 body message (for example, the INVITE carries a photo (Content- 04480 Disposition: render) and the ACK a session description (Content- 04481 Disposition: session)). 04482 04483 If the Content-Disposition header field is missing, bodies 04484 of Content-Type application/sdp imply the disposition 04485 "session", while other content types imply "render". 04486 04487 Once the INVITE has been created, the UAC follows the procedures 04488 defined for sending requests outside of a dialog (Section 8). This 04489 results in the construction of a client transaction that will 04490 ultimately send the request and deliver responses to the UAC. 04491 04492 13.2.2 Processing INVITE Responses 04493 04494 Once the INVITE has been passed to the INVITE client transaction, the 04495 UAC waits for responses for the INVITE. If the INVITE client 04496 transaction returns a timeout rather than a response the TU acts as 04497 if a 408 (Request Timeout) response had been received, as described 04498 in Section 8.1.3. 04499 04500 13.2.2.1 1xx responses 04501 04502 Zero, one or multiple provisional responses may arrive before one or 04503 more final responses are received. Provisional responses for an 04504 INVITE request can create "early dialogs". If a provisional response 04505 has a tag in the To field, and if the dialog ID of the response does 04506 not match an existing dialog, one is constructed using the procedures 04507 defined in Section 12.1.2. 04508 04509 The early dialog will only be needed if the UAC needs to send a 04510 request to its peer within the dialog before the initial INVITE 04511 transaction completes. Header fields present in a provisional 04512 04513 04514 04515 J. Rosenberg et. al. [Page 75] 04516 Internet Draft SIP February 18, 2002 04517 04518 04519 response are applicable as long as the dialog is in the early state 04520 (for example, an Allow header field in a provisional response 04521 contains the methods that can be used in the dialog while this is in 04522 the early state). 04523 04524 13.2.2.2 3xx responses 04525 04526 A 3xx response may contain one or more Contact header field values 04527 providing new addresses where the callee might be reachable. 04528 Depending on the status code of the 3xx response (see Section 21.3) 04529 the UAC MAY choose to try those new addresses. 04530 04531 13.2.2.3 4xx, 5xx and 6xx responses 04532 04533 A single non-2xx final response may be received for the INVITE. 4xx, 04534 5xx and 6xx responses may contain a Contact header field value 04535 indicating the location where additional information about the error 04536 can be found. 04537 04538 All early dialogs are considered terminated upon reception of the 04539 non-2xx final response. 04540 04541 After having received the non-2xx final response the UAC core 04542 considers the INVITE transaction completed. The INVITE client 04543 transaction handles generation of ACKs for the response (see Section 04544 17). 04545 04546 13.2.2.4 2xx responses 04547 04548 Multiple 2xx responses may arrive at the UAC for a single INVITE 04549 request due to a forking proxy. Each response is distinguished by the 04550 tag parameter in the To header field, and each represents a distinct 04551 dialog, with a distinct dialog identifier. 04552 04553 If the dialog identifier in the 2xx response matches the dialog 04554 identifier of an existing dialog, the dialog MUST be transitioned to 04555 the "confirmed" state, and the route set for the dialog MUST be 04556 recomputed based on the 2xx response using the procedures of Section 04557 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be 04558 constructed using the procedures of Section 12.1.2. 04559 04560 Note that the only piece of state that is recomputed is the 04561 route set. Other pieces of state such as the highest 04562 sequence numbers (remote and local) sent within the dialog 04563 are not recomputed. The route set only is recomputed for 04564 backwards compatibility. RFC 2543 did not mandate mirroring 04565 of the Record-Route header field in a 1xx, only 2xx. 04566 However, we cannot update the entire state of the dialog, 04567 04568 04569 04570 J. Rosenberg et. al. [Page 76] 04571 Internet Draft SIP February 18, 2002 04572 04573 04574 since mid-dialog requests may have been sent within the 04575 early dialog, modifying the sequence numbers, for example. 04576 04577 The UAC core MUST generate an ACK request for each 2xx received from 04578 the transaction layer. The header fields of the ACK are constructed 04579 in the same way as for any request sent within a dialog (see Section 04580 12) with the exception of the CSeq and the header fields related to 04581 authentication. The sequence number of the CSeq header field MUST be 04582 the same as the INVITE being acknowledged, but the CSeq method MUST 04583 be ACK. The ACK MUST contain the same credentials as the INVITE. If 04584 the 2xx contains an offer (based on the rules above), the ACK MUST 04585 carry an answer in its body. If the offer in the 2xx response is not 04586 acceptable, the UAC core MUST generate a valid answer in the ACK and 04587 then send a BYE immediately. 04588 04589 Once the ACK has been constructed, the procedures of [4] are used to 04590 determine the destination address, port and transport. However, the 04591 request is passed to the transport layer directly for transmission, 04592 rather than a client transaction. This is because the UAC core 04593 handles retransmissions of the ACK, not the transaction layer. The 04594 ACK MUST be passed to the client transport every time a 04595 retransmission of the 2xx final response that triggered the ACK 04596 arrives. 04597 04598 The UAC core considers the INVITE transaction completed 64*T1 seconds 04599 after the reception of the first 2xx response. At this point all the 04600 early dialogs that have not transitioned to established dialogs are 04601 terminated. Once the INVITE transaction is considered completed by 04602 the UAC core, no more new 2xx responses are expected to arrive. 04603 04604 If, after acknowledging any 2xx response to an INVITE, the UAC does 04605 not want to continue with that dialog, then the UAC MUST terminate 04606 the dialog by sending a BYE request as described in Section 15. 04607 04608 13.3 UAS Processing 04609 04610 13.3.1 Processing of the INVITE 04611 04612 The UAS core will receive INVITE requests from the transaction layer. 04613 It first performs the request processing procedures of Section 8.2, 04614 which are applied for both requests inside and outside of a dialog. 04615 04616 Assuming these processing states complete without generating a 04617 response, the UAS core performs the additional processing steps: 04618 04619 1. If the request is an INVITE that contains an Expires header 04620 field the UAS core sets a timer for the number of seconds 04621 indicated in the header field value. When the timer fires, 04622 04623 04624 04625 J. Rosenberg et. al. [Page 77] 04626 Internet Draft SIP February 18, 2002 04627 04628 04629 the invitation is considered to be expired. If the 04630 invitation expires before the UAS has generated a final 04631 response, a 487 (Request Terminated) response SHOULD be 04632 generated. 04633 04634 2. If the request is a mid-dialog request, the method- 04635 independent processing described in Section 12.2.2 is first 04636 applied. It might also modify the session; Section 14 04637 provides details. 04638 04639 3. If the request has a tag in the To header field but the 04640 dialog identifier does not match any of the existing 04641 dialogs, the UAS may have crashed and restarted, or may 04642 have received a request for a different (possibly failed) 04643 UAS. Section 12.2.2 provides guidelines to achieve a robust 04644 behavior under such a situation. 04645 04646 Processing from here forward assumes that the INVITE is outside of a 04647 dialog, and is thus for the purposes of establishing a new session. 04648 04649 The INVITE may contain a session description, in which case the UAS 04650 is being presented with an offer for that session. It is possible 04651 that the user is already a participant in that session, even though 04652 the INVITE is outside of a dialog. This can happen when a user is 04653 invited to the same multicast conference by multiple other 04654 participants. If desired, the UAS MAY use identifiers within the 04655 session description to detect this duplication. For example, SDP 04656 contains a session id and version number in the origin (o) field. If 04657 the user is already a member of the session, and the session 04658 parameters contained in the session description have not changed, the 04659 UAS MAY silently accept the INVITE (that is, send a 2xx response 04660 without prompting the user). 04661 04662 If the INVITE does not contain a session description, the UAS is 04663 being asked to participate in a session, and the UAC has asked that 04664 the UAS provide the offer of the session. It MUST provide the offer 04665 in its first non-failure reliable message back to the UAC. In this 04666 specification, that is a 2xx response to the INVITE. 04667 04668 The UAS can indicate progress, accept, redirect, or reject the 04669 invitation. In all of these cases, it formulates a response using the 04670 procedures described in Section 8.2.6. 04671 04672 13.3.1.1 Progress 04673 04674 If the UAS is not able to answer the invitation immediately, it can 04675 choose to indicate some kind of progress to the UAC (for example, an 04676 indication that a phone is ringing). This is accomplished with a 04677 04678 04679 04680 J. Rosenberg et. al. [Page 78] 04681 Internet Draft SIP February 18, 2002 04682 04683 04684 provisional response between 101 and 199. These provisional responses 04685 establish early dialogs and therefore follow the procedures of 04686 Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY send 04687 as many provisional responses as it likes. Each of these MUST 04688 indicate the same dialog ID. However, these will not be delivered 04689 reliably. 04690 04691 If the UAS desires an extended period of time to answer the INVITE, 04692 it will need to ask for an "extension" in order to prevent proxies 04693 from canceling the transaction. A proxy has the option of canceling a 04694 transaction when there is a gap of 3 minutes between messages in a 04695 transaction. To prevent cancellation, the UAS MUST send a non-100 04696 provisional response at every minute, to handle the possibility of 04697 lost provisional responses. 04698 04699 04700 An INVITE transaction can go on for extended durations when 04701 the user is placed on hold, or when interworking with PSTN 04702 systems which allow communications to take place without 04703 answering the call. The latter is common in Interactive 04704 Voice Response (IVR) systems. 04705 04706 13.3.1.2 The INVITE is redirected 04707 04708 If the UAS decides to redirect the call, a 3xx response is sent. A 04709 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved 04710 Temporarily) response SHOULD contain a Contact header field 04711 containing one or more URIs of new addresses to be tried. The 04712 response is passed to the INVITE server transaction, which will deal 04713 with its retransmissions. 04714 04715 13.3.1.3 The INVITE is rejected 04716 04717 A common scenario occurs when the callee is currently not willing or 04718 able to take additional calls at this end system. A 486 (Busy Here) 04719 SHOULD be returned in such scenario. If the UAS knows that no other 04720 end system will be able to accept this call a 600 (Busy Everywhere) 04721 response SHOULD be sent instead. However, it is unlikely that a UAS 04722 will be able to know this in general, and thus this response will not 04723 usually be used. The response is passed to the INVITE server 04724 transaction, which will deal with its retransmissions. 04725 04726 A UAS rejecting an offer contained in an INVITE SHOULD return a 488 04727 (Not Acceptable Here) response. Such a response SHOULD include a 04728 Warning header field value explaining why the offer was rejected. 04729 04730 13.3.1.4 The INVITE is accepted 04731 04732 04733 04734 04735 J. Rosenberg et. al. [Page 79] 04736 Internet Draft SIP February 18, 2002 04737 04738 04739 The UAS core generates a 2xx response. This response establishes a 04740 dialog, and therefore follows the procedures of Section 12.1.1 in 04741 addition to those of Section 8.2.6. 04742 04743 A 2xx response to an INVITE SHOULD contain the Allow header field and 04744 the Supported header field, and MAY contain the Accept header field. 04745 Including these header fields allows the UAC to determine the 04746 features and extensions supported by the UAS for the duration of the 04747 call, without probing. 04748 04749 If the INVITE request contained an offer, and the UAS had not yet 04750 sent an answer, the 2xx MUST contain an answer. If the INVITE did not 04751 contain an offer, the 2xx MUST contain an offer if the UAS had not 04752 yet sent an offer. 04753 04754 Once the response has been constructed it is passed to the INVITE 04755 server transaction. Note, however, that the INVITE server transaction 04756 will be destroyed as soon as it receives this final response and 04757 passes it to the transport. Therefore, it is necessary to pass 04758 periodically the response directly to the transport until the ACK 04759 arrives. The 2xx response is passed to the transport with an interval 04760 that starts at T1 seconds and doubles for each retransmission until 04761 it reaches T2 seconds (T1 and T2 are defined in Section 17). Response 04762 retransmissions cease when an ACK request for the response is 04763 received. This is independent of whatever transport protocols are 04764 used to send the response. 04765 04766 04767 Since 2xx is retransmitted end-to-end, there may be hops 04768 between UAS and UAC that are UDP. To ensure reliable 04769 delivery across these hops, the response is retransmitted 04770 periodically even if the transport at the UAS is reliable. 04771 04772 If the server retransmits the 2xx response for 64*T1 seconds without 04773 receiving an ACK, the dialog is confirmed, but the session SHOULD be 04774 terminated. This is accomplished with a BYE as described in Section 04775 15. 04776 04777 14 Modifying an Existing Session 04778 04779 A successful INVITE request (see Section 13) establishes both a 04780 dialog between two user agents and a session using the offer-answer 04781 model. Section 12 explains how to modify an existing dialog using a 04782 target refresh request (for example, changing the remote target URI 04783 of the dialog). This section describes how to modify the actual 04784 session. This modification can involve changing addresses or ports, 04785 adding a media stream, deleting a media stream, and so on. This is 04786 accomplished by sending a new INVITE request within the same dialog 04787 04788 04789 04790 J. Rosenberg et. al. [Page 80] 04791 Internet Draft SIP February 18, 2002 04792 04793 04794 that established the session. An INVITE request sent within an 04795 existing dialog is known as a re-INVITE. 04796 04797 04798 Note that a single re-INVITE can modify the dialog and the 04799 parameters of the session at the same time. 04800 04801 Either the caller or callee can modify an existing session. 04802 04803 The behavior of a UA on detection of media failure is a matter of 04804 local policy. However, automated generation of re-INVITE or BYE is 04805 NOT RECOMMENDED to avoid flooding the network with traffic when there 04806 is congestion. In any case, if these messages are sent automatically, 04807 they SHOULD be sent after some randomized interval. 04808 04809 Note that the paragraph above refers to automatically 04810 generated BYEs and re-INVITEs. If the user hangs up upon 04811 media failure the UA would send a BYE request as usual. 04812 04813 14.1 UAC Behavior 04814 04815 The same offer-answer model that applies to session descriptions in 04816 INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC 04817 that wants to add a media stream, for example, will create a new 04818 offer that contains this media stream, and send that in an INVITE 04819 request to its peer. It is important to note that the full 04820 description of the session, not just the change, is sent. This 04821 supports stateless session processing in various elements, and 04822 supports failover and recovery capabilities. Of course, a UAC MAY 04823 send a re-INVITE with no session description, in which case the first 04824 reliable non-failure response to the re-INVITE will contain the offer 04825 (in this specification, that is a 2xx response). 04826 04827 If the session description format has the capability for version 04828 numbers, the offerer SHOULD indicate that the version of the session 04829 description has changed. 04830 04831 The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set 04832 following the same rules as for regular requests within an existing 04833 dialog, described in Section 12. 04834 04835 A UAC MAY choose not to add an Alert-Info header field or a body with 04836 Content-Disposition "alert" to re-INVITEs because UASs do not 04837 typically alert the user upon reception of a re-INVITE. 04838 04839 Unlike an INVITE, which can fork, a re-INVITE will never fork, and 04840 therfore, only ever generate a single final response. The reason a 04841 re-INVITE will never fork is that the Request-URI identifies the 04842 04843 04844 04845 J. Rosenberg et. al. [Page 81] 04846 Internet Draft SIP February 18, 2002 04847 04848 04849 target as the UA instance it established the dialog with, rather than 04850 identifying an address-of-record for the user. 04851 04852 Note that a UAC MUST NOT initiate a new INVITE transaction within a 04853 dialog while another INVITE transaction is in progress in either 04854 direction. 04855 04856 1. If there is an ongoing INVITE client transaction, the TU 04857 MUST wait until the transaction reaches the completed or 04858 terminated state before initiating the new INVITE. 04859 04860 2. If there is an ongoing INVITE server transaction, the TU 04861 MUST wait until the transaction reaches the confirmed or 04862 terminated state before initiating the new INVITE. 04863 04864 However, a UA MAY initiate a regular transaction while an INVITE 04865 transaction is in progress. A UA MAY also initiate an INVITE 04866 transaction while a regular transaction is in progress. 04867 04868 If a UA receives a non-2xx final response to a re-INVITE, the session 04869 parameters MUST remain unchanged, as if no re-INVITE had been issued. 04870 Note that, as stated in Section 12.2.1.2, if the non-2xx final 04871 response is a 481 (Call/Transaction Does Not Exist), or a 408 04872 (Request Timeout), or no response at all is received for the re- 04873 INVITE (that is, a timeout is returned by the INVITE client 04874 transaction), the UAC will terminate the dialog. 04875 04876 The rules for transmitting a re-INVITE and for generating an ACK for 04877 a 2xx response to re-INVITE are the same as for the initial INVITE 04878 (Section 13.2.1). 04879 04880 14.2 UAS Behavior 04881 04882 Section 13.3.1 describes the procedure for distinguishing incoming 04883 re-INVITEs from incoming initial INVITEs and handling a re-INVITE for 04884 an existing dialog. 04885 04886 A UAS that receives a second INVITE before it sends the final 04887 response to a first INVITE with a lower CSeq sequence number on the 04888 same dialog MUST return a 500 (Server Internal Error) response to the 04889 second INVITE and MUST include a Retry-After header field with a 04890 randomly chosen value of between 0 and 10 seconds. 04891 04892 A UAS that receives an INVITE on a dialog while an INVITE it had sent 04893 on that dialog is in progress MUST return a 491 (Request Pending) 04894 response to the received INVITE and MUST include a Retry-After header 04895 field with a value chosen as follows: 04896 04897 04898 04899 04900 J. Rosenberg et. al. [Page 82] 04901 Internet Draft SIP February 18, 2002 04902 04903 04904 1. If the UAS is the owner of the Call-ID of the dialog ID 04905 (meaning it generated the value), the Retry-After header 04906 field has a randomly chosen value of between 2.1 and 4 04907 seconds in units of 10 ms. 04908 04909 2. If the UAS is not the owner of the Call-ID of the dialog 04910 ID, the Retry-After header field has a randomly chosen 04911 value of between 0 and 2 seconds in units of 10 ms. 04912 04913 If a UA receives a re-INVITE for an existing dialog, it MUST check 04914 any version identifiers in the session description or, if there are 04915 no version identifiers, the content of the session description to see 04916 if it has changed. If the session description has changed, the UAS 04917 MUST adjust the session parameters accordingly, possibly after asking 04918 the user for confirmation. 04919 04920 Versioning of the session description can be used to 04921 accommodate the capabilities of new arrivals to a 04922 conference, add or delete media, or change from a unicast 04923 to a multicast conference. If the new session description 04924 is not acceptable, the UAS can reject it by returning a 488 04925 (Not Acceptable Here) response for the re-INVITE. This 04926 response SHOULD include a Warning header field. 04927 04928 If a UAS generates a 2xx response and never receives an ACK, it 04929 SHOULD generate a BYE to terminate the dialog. 04930 04931 A UAS MAY choose not to generate 180 (Ringing) responses for a re- 04932 INVITE because UACs do not typically render this information to the 04933 user. For the same reason, UASs MAY choose not to use an Alert-Info 04934 header field or a body with Content-Disposition "alert" in responses 04935 to a re-INVITE. 04936 04937 A UAS providing an offer in a 2xx (because the INVITE did not contain 04938 an offer) SHOULD construct the offer as if the UAS were making a 04939 brand new call, subject to the constraints of sending an offer that 04940 updates an existing session, as described in [13] in the case of SDP. 04941 Specifically, this means that it SHOULD include as many media formats 04942 and media types that the UA is willing to support. The UAS MUST 04943 ensure that the session description overlaps with its previous 04944 session description in media formats, transports, or other parameters 04945 that require support from the peer. This is to avoid the need for the 04946 peer to reject the session description. If, however, it is 04947 unacceptable to the UAC, the UAC SHOULD generate an answer with a 04948 valid session description, and then send a BYE to terminate the 04949 session. 04950 04951 15 Terminating a Session 04952 04953 04954 04955 J. Rosenberg et. al. [Page 83] 04956 Internet Draft SIP February 18, 2002 04957 04958 04959 This section describes the procedures for terminating a session 04960 established by SIP. The state of the session and the state of the 04961 dialog are very closely related. When a session is initiated with an 04962 INVITE, each 1xx or 2xx response from a distinct UAS creates a 04963 dialog, and if that response completes the offer/answer exchange, it 04964 also creates a session. As a result, each session is "associated" 04965 with a single dialog - the one which resulted in its creation. If an 04966 initial INVITE generates a non-2xx final response, that terminates 04967 all sessions (if any) and all dialogs (if any) that were created 04968 through responses to the request. By virtue of completing the 04969 transaction, a non-2xx final response also prevents further sessions 04970 from being created as a result of the INVITE. The BYE request is used 04971 to terminate a specific session or attempted session. In this case, 04972 the specific session is the one with the peer UA on the other side of 04973 the dialog. When a BYE is received on a dialog, any session 04974 associated with that dialog SHOULD terminate. A UA MUST NOT send a 04975 BYE outside of a dialog. The caller's UA MAY send a BYE for either 04976 confirmed or early dialogs, and the callee's UA MAY send a BYE on 04977 confirmed dialogs, but MUST NOT send a BYE on early dialogs. However, 04978 the callee's UA MUST NOT send a BYE on a confirmed dialog until it 04979 has received an ACK for its 2xx response or until the server 04980 transaction times out. If no SIP extensions have defined other 04981 application layer state associated with the dialog, the BYE also 04982 terminates the dialog. 04983 04984 The impact of a non-2xx final response to INVITE on dialogs and 04985 sessions makes the use of CANCEL attractive. The CANCEL attempts to 04986 force a non-2xx response to the INVITE (in particular, a 487). 04987 Therefore, if a UAC wishes to give up on its call attempt entirely, 04988 it can send a CANCEL. If the INVITE results in 2xx final response(s) 04989 to the INVITE, this means that a UAS accepted the invitation while 04990 the CANCEL was in progress. The UAC MAY continue with the sessions 04991 established by any 2xx responses, or MAY terminate them with BYE. 04992 04993 04994 The notion of "hanging up" is not well defined within SIP. 04995 It is specific to a particular, albeit common, user 04996 interface. Typically, when the user hangs up, it indicates 04997 a desire to terminate the attempt to establish a session, 04998 and to terminate any sessions already created. For the 04999 caller's UA, this would imply a CANCEL request if the 05000 initial INVITE has not generated a final response, and a 05001 BYE to all confirmed dialogs after a final response. For 05002 the callee's UA, it would typically imply a BYE; 05003 presumably, when the user picked up the phone, a 2xx was 05004 generated, and so hanging up would result in a BYE after 05005 the ACK is received. This does not mean a user cannot hang 05006 up before receipt of the ACK, it just means that the 05007 05008 05009 05010 J. Rosenberg et. al. [Page 84] 05011 Internet Draft SIP February 18, 2002 05012 05013 05014 software in his phone needs to maintain state for a short 05015 while in order to clean up properly. If the particular UI 05016 allows for the user to reject a call before its answered, a 05017 403 (Forbidden) is a good way to express that. As per the 05018 rules above, a BYE can't be sent. 05019 05020 15.1 Terminating a Session with a BYE Request 05021 05022 15.1.1 UAC Behavior 05023 05024 A BYE request is constructed as would any other request within a 05025 dialog, as described in Section 12. 05026 05027 Once the BYE is constructed, the UAC core creates a new non-INVITE 05028 client transaction, and passes it the BYE request. The UAC MUST 05029 consider the session terminated (and therefore stop sending or 05030 listening for media) as soon as the BYE request is passed to the 05031 client transaction. If the response for the BYE is a 481 05032 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no 05033 response at all is received for the BYE (that is, a timeout is 05034 returned by the client transaction), the UAC MUST consider the 05035 session and the dialog terminated. 05036 05037 15.1.2 UAS Behavior 05038 05039 A UAS first processes the BYE request according to the general UAS 05040 processing described in Section 8.2. A UAS core receiving a BYE 05041 request checks if it matches an existing dialog. If the BYE does not 05042 match an existing dialog, the UAS core SHOULD generate a 481 05043 (Call/Transaction Does Not Exist) response and pass that to the 05044 server transaction. 05045 05046 05047 This rule means that a BYE sent without tags by a UAC will 05048 be rejected. This is a change from RFC 2543, which allowed 05049 BYE without tags. 05050 05051 A UAS core receiving a BYE request for an existing dialog MUST follow 05052 the procedures of Section 12.2.2 to process the request. Once done, 05053 the UAS SHOULD terminate the session (and therefore stop sending and 05054 listening for media). The only case where it can elect not to are 05055 multicast sessions, where participation is possible even if the other 05056 participant in the dialog has terminated its involvement in the 05057 session. Whether or not it ends its participation on the session, the 05058 UAS core MUST generate a 2xx response to the BYE, and MUST pass that 05059 to the server transaction for transmission. 05060 05061 The UAS MUST still respond to any pending requests received for that 05062 05063 05064 05065 J. Rosenberg et. al. [Page 85] 05066 Internet Draft SIP February 18, 2002 05067 05068 05069 dialog. It is RECOMMENDED that a 487 (Request Terminated) response is 05070 generated to those pending requests. 05071 05072 16 Proxy Behavior 05073 05074 16.1 Overview 05075 05076 SIP proxies are elements that route SIP requests to user agent 05077 servers and SIP responses to user agent clients. A request may 05078 traverse several proxies on its way to a UAS. Each will make routing 05079 decisions, modifying the request before forwarding it to the next 05080 element. Responses will route through the same set of proxies 05081 traversed by the request in the reverse order. 05082 05083 Being a proxy is a logical role for a SIP element. When a request 05084 arrives, an element that can play the role of a proxy first decides 05085 if it needs to respond to the request on its own. For instance, the 05086 request may be malformed or the element may need credentials from the 05087 client before acting as a proxy. The element MAY respond with any 05088 appropriate error code. When responding directly to a request, the 05089 element is playing the role of a UAS and MUST behave as described in 05090 Section 8.2. 05091 05092 A proxy can operate in either a stateful or stateless mode for each 05093 new request. When stateless, a proxy acts as a simple forwarding 05094 element. It forwards each request downstream to a single element 05095 determined by making a targeting and routing decision based on the 05096 request. It simply forwards every response it receives upstream. A 05097 stateless proxy discards information about a message once the message 05098 has been forwarded. A stateful proxy remembers information 05099 (specifically, transaction state) about each incoming request and any 05100 requests it sends as a result of processing the incoming request. It 05101 uses this information to affect the processing of future messages 05102 associated with that request. A stateful proxy MAY choose to "fork" a 05103 request, routing it to multiple destinations. Any request that is 05104 forwarded to more than one location MUST be handled statefully. 05105 05106 In some circumstances, a proxy MAY forward requests using stateful 05107 transports (such as TCP) without being transaction-stateful. For 05108 instance, a proxy MAY forward a request from one TCP connection to 05109 another transaction statelessly as long as it places enough 05110 information in the message to be able to forward the response down 05111 the same connection the request arrived on. Requests forwarded 05112 between different types of transports where the proxy's TU must take 05113 an active role in ensuring reliable delivery on one of the transports 05114 MUST be forwarded transaction statefully. 05115 05116 A stateful proxy MAY transition to stateless operation at any time 05117 05118 05119 05120 J. Rosenberg et. al. [Page 86] 05121 Internet Draft SIP February 18, 2002 05122 05123 05124 during the processing of a request, so long as it did not do anything 05125 that would otherwise prevent it from being stateless initially 05126 (forking, for example, or generation of a 100 response). When 05127 performing such a transition, all state is simply discarded. The 05128 proxy SHOULD NOT initiate a CANCEL request. 05129 05130 Much of the processing involved when acting statelessly or statefully 05131 for a request is identical. The next several subsections are written 05132 from the point of view of a stateful proxy. The last section calls 05133 out those places where a stateless proxy behaves differently. 05134 05135 16.2 Stateful Proxy 05136 05137 When stateful, a proxy is purely a SIP transaction processing engine. 05138 Its behavior is modeled here in terms of the server and client 05139 transactions defined in Section 17. A stateful proxy has a server 05140 transaction associated with one or more client transactions by a 05141 higher layer proxy processing component (see figure 3), known as a 05142 proxy core. An incoming request is processed by a server transaction. 05143 Requests from the server transaction are passed to a proxy core. The 05144 proxy core determines where to route the request, choosing one or 05145 more next-hop locations. An outgoing request for each next-hop 05146 location is processed by its own associated client transaction. The 05147 proxy core collects the responses from the client transactions and 05148 uses them to send responses to the server transaction. 05149 05150 A stateful proxy creates a new server transaction for each new 05151 request received. Any retransmissions of the request will then be 05152 handled by that server transaction per Section 17. The proxy core 05153 MUST behave as a UAS with respect to sending an immediate provisional 05154 on that server transaction (such as 100 Trying) as described in 05155 Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 Trying 05156 responses to non-INVITE requests. 05157 05158 This is a model of proxy behavior, not of software. An implementation 05159 is free to take any approach that replicates the external behavior 05160 this model defines. 05161 05162 05163 For all new requests, including any with unknown methods, an element 05164 intending to proxy the request MUST: 05165 05166 1. Validate the request (Section 16.3) 05167 05168 2. Preprocess routing information (Section 16.4) 05169 05170 3. Determine target(s) for the request (Section 16.5) 05171 05172 05173 05174 05175 J. Rosenberg et. al. [Page 87] 05176 Internet Draft SIP February 18, 2002 05177 05178 05179 05180 05181 +--------------------+ 05182 | | +---+ 05183 | | | C | 05184 | | | T | 05185 | | +---+ 05186 +---+ | Proxy | +---+ CT = Client Transaction 05187 | S | | "Higher" Layer | | C | 05188 | T | | | | T | ST = Server Transaction 05189 +---+ | | +---+ 05190 | | +---+ 05191 | | | C | 05192 | | | T | 05193 | | +---+ 05194 +--------------------+ 05195 05196 05197 05198 Figure 3: Stateful Proxy Model 05199 05200 05201 4. Forward the request to each target (Section 16.6) 05202 05203 5. Process all responses (Section 16.7) 05204 05205 16.3 Request Validation 05206 05207 Before an element can proxy a request, it MUST verify the message's 05208 validity. A valid message must pass the following checks: 05209 05210 1. Reasonable Syntax 05211 05212 2. URI scheme 05213 05214 3. Max-Forwards 05215 05216 4. (Optional) Loop Detection 05217 05218 5. Proxy-Require 05219 05220 6. Proxy-Authorization 05221 05222 If any of these checks fail, the element MUST behave as a user agent 05223 server (see Section 8.2) and respond with an error code. 05224 05225 Notice that a proxy is not required to detect merged requests and 05226 MUST NOT treat merged requests as an error condition. The endpoints 05227 receiving the requests will resolve the merge as described in Section 05228 05229 05230 05231 J. Rosenberg et. al. [Page 88] 05232 Internet Draft SIP February 18, 2002 05233 05234 05235 8.2.2.2. 05236 05237 1. Reasonable syntax check 05238 05239 The request MUST be well-formed enough to be handled with a 05240 server transaction. Any components involved in the 05241 remainder of these Request Validation steps or the Request 05242 Forwarding section MUST be well-formed. Any other 05243 components, well-formed or not, SHOULD be ignored and 05244 remain unchanged when the message is forwarded. For 05245 instance, an element would not reject a request because of 05246 a malformed Date header field. Likewise, a proxy would not 05247 remove a malformed Date header field before forwarding a 05248 request. 05249 05250 This protocol is designed to be extended. Future extensions 05251 may define new methods and header fields at any time. An 05252 element MUST NOT refuse to proxy a request because it 05253 contains a method or header field it does not know about. 05254 05255 2. URI scheme check 05256 05257 If the Request-URI has a URI whose scheme is not understood 05258 by the proxy, the proxy SHOULD reject the request with a 05259 416 (Unsupported URI Scheme) response. 05260 05261 3. Max-Forwards check 05262 05263 The Max-Forwards header field (Section 20.22) is used to 05264 limit the number of elements a SIP request can traverse. 05265 05266 If the request does not contain a Max-Forwards header 05267 field, this check is passed. 05268 05269 If the request contains a Max-Forwards header field with a 05270 field value greater than zero, the check is passed. 05271 05272 If the request contains a Max-Forwards header field with a 05273 field value of zero (0), the element MUST NOT forward the 05274 request. If the request was for OPTIONS, the element MAY 05275 act as the final recipient and respond per Section 11. 05276 Otherwise, the element MUST return a 483 (Too many hops) 05277 response. 05278 05279 4. Optional Loop Detection check 05280 05281 An element MAY check for forwarding loops before forwarding 05282 a request. If the request contains a Via header field with 05283 05284 05285 05286 J. Rosenberg et. al. [Page 89] 05287 Internet Draft SIP February 18, 2002 05288 05289 05290 a sent-by value that equals a value placed into previous 05291 requests by the proxy, the request has been forwarded by 05292 this element before. The request has either looped or is 05293 legitimately spiraling through the element. To determine if 05294 the request has looped, the element MAY perform the branch 05295 parameter calculation described in Step 8 of Section 16.6 05296 on this message and compare it to the parameter received in 05297 that Via header field. If the parameters match, the request 05298 has looped. If they differ, the request is spiraling, and 05299 processing continues. If a loop is detected, the element 05300 MAY return a 482 (Loop Detected) response. 05301 05302 5. Proxy-Require check 05303 05304 Future extensions to this protocol may introduce features 05305 that require special handling by proxies. Endpoints will 05306 include a Proxy-Require header field in requests that use 05307 these features, telling the proxy not to process the 05308 request unless the feature is understood. 05309 05310 If the request contains a Proxy-Require header field 05311 (Section 20.29) with one or more option-tags this element 05312 does not understand, the element MUST return a 420 (Bad 05313 Extension) response. The response MUST include an 05314 Unsupported (Section 20.40) header field listing those 05315 option-tags the element did not understand. 05316 05317 6. Proxy-Authorization check 05318 05319 If an element requires credentials before forwarding a 05320 request, the request MUST be inspected as described in 05321 Section 22.3. That section also defines what the element 05322 must do if the inspection fails. 05323 05324 16.4 Route Information Preprocessing 05325 05326 The proxy MUST inspect the Request-URI of the request. If the 05327 Request-URI of the request contains a value this proxy previously 05328 placed into a Record-Route header field (see Section 16.6 item 4), 05329 the proxy MUST replace the Request-URI in the request with the last 05330 value from the Route header field, and remove that value from the 05331 Route header field. The proxy MUST then proceed as if it received 05332 this modified request. 05333 05334 05335 This will only happen when the element sending the request 05336 to the proxy (which may have been an endpoint) is a strict 05337 router. This rewrite on receive is necessary to enable 05338 05339 05340 05341 J. Rosenberg et. al. [Page 90] 05342 Internet Draft SIP February 18, 2002 05343 05344 05345 backwards compatibility with those elements. It also allows 05346 elements following this specification to preserve the 05347 Request-URI through strict-routing proxies (see Section 05348 12.2.1.1). 05349 05350 05351 This requirement does not obligate a proxy to keep state in 05352 order to detect URIs it previously placed in Record-Route 05353 header fields. Instead, a proxy need only place enough 05354 information in those URIs to recognize them as values it 05355 provided when they later appear. 05356 05357 If the Request-URI contains an maddr parameter, the proxy MUST check 05358 to see if its value is in the set of addresses or domains the proxy 05359 is configured to be responsible for. If the Request-URI has an maddr 05360 parameter with a value the proxy is responsible for, and the request 05361 was received using the port and transport indicated (explicitly or by 05362 default) in the Request-URI, the proxy MUST strip the maddr and any 05363 non-default port or transport parameter and continue processing as if 05364 those values had not been present in the request. 05365 05366 05367 A request may arrive with an maddr matching the proxy, but 05368 on a port or transport different from that indicated in the 05369 URI. Such a request needs to be forwarded to the proxy 05370 using the indicated port and transport. 05371 05372 If the first value in the Route header field indicates this proxy, 05373 the proxy MUST remove that value from the request. 05374 05375 16.5 Determining request targets 05376 05377 Next, the proxy calculates the target(s) of the request. The set of 05378 targets will either be predetermined by the contents of the request 05379 or will be obtained from an abstract location service. Each target in 05380 the set is represented as a URI. 05381 05382 If the Request-URI of the request contains an maddr parameter, the 05383 Request-URI MUST be placed into the target set as the only target 05384 URI, and the proxy MUST proceed to Section 16.6. 05385 05386 If the domain of the Request-URI indicates a domain this element is 05387 not responsible for, the Request-URI MUST be placed into the target 05388 set as the only target, and the element MUST proceed to the task of 05389 Request Forwarding (Section 16.6). 05390 05391 05392 There are many circumstances in which a proxy might receive 05393 05394 05395 05396 J. Rosenberg et. al. [Page 91] 05397 Internet Draft SIP February 18, 2002 05398 05399 05400 a request for a domain it is not responsible for. A 05401 firewall proxy handling outgoing calls (the way HTTP 05402 proxies handle outgoing requests) is an example of where 05403 this is likely to occur. 05404 05405 If the target set for the request has not been predetermined as 05406 described above, this implies that the element is responsible for the 05407 domain in the Request-URI, and the element MAY use whatever mechanism 05408 it desires to determine where to send the request. Any of these 05409 mechanisms can be modeled as accessing an abstract Location Service. 05410 This may consist of obtaining information from a location service 05411 created by a SIP Registrar, reading a database, consulting a presence 05412 server, utilizing other protocols, or simply performing an 05413 algorithmic substitution on the Request-URI. When accessing the 05414 location service constructed by a registrar, the Request-URI MUST 05415 first be canonicalized as described in Section 10.3 before being used 05416 as an index. The output of these mechanisms is used to construct the 05417 target set. If the Request-URI contains a SIPS URI, all elements in 05418 the target set MUST be SIPS URIs. 05419 05420 If the Request-URI does not provide sufficient information for the 05421 proxy to determine the target set, it SHOULD return a 485 (Ambiguous) 05422 response. This response SHOULD contain a Contact header field 05423 containing URIs of new addresses to be tried. For example, an INVITE 05424 to sip:John.Smith@company.com may be ambiguous at a proxy whose 05425 location service has multiple John Smiths listed. See Section 21.4.23 05426 for details. 05427 05428 Any information in or about the request or the current environment of 05429 the element MAY be used in the construction of the target set. For 05430 instance, different sets may be constructed depending on contents or 05431 the presence of header fields and bodies, the time of day of the 05432 request's arrival, the interface on which the request arrived, 05433 failure of previous requests, or even the element's current level of 05434 utilization. 05435 05436 As potential targets are located through these services, their URIs 05437 are added to the target set. Targets can only be placed in the 05438 target set once. If a target URI is already present in the set (based 05439 on the definition of equality for the URI type), it MUST NOT be added 05440 again. 05441 05442 A proxy MUST NOT add additional targets to the target set if the 05443 Request-URI of the original request does not indicate a resource this 05444 proxy is responsible for. 05445 05446 05447 A proxy can only change the Request-URI of a request during 05448 05449 05450 05451 J. Rosenberg et. al. [Page 92] 05452 Internet Draft SIP February 18, 2002 05453 05454 05455 forwarding if it is responsible for that URI. If the proxy 05456 is not responsible for that URI, it will not recurse on 3xx 05457 or 416 responses as described below. 05458 05459 If the Request-URI of the original request indicates a resource this 05460 proxy is responsible for, the proxy MAY continue to add targets to 05461 the set after beginning Request Forwarding. It MAY use any 05462 information obtained during that processing to determine new targets. 05463 For instance, a proxy may choose to incorporate contacts obtained in 05464 a redirect response (3xx) into the target set. If a proxy uses a 05465 dynamic source of information while building the target set (for 05466 instance, if it consults a SIP Registrar), it SHOULD monitor that 05467 source for the duration of processing the request. New locations 05468 SHOULD be added to the target set as they become available. As above, 05469 any given URI MUST NOT be added to the set more than once. 05470 05471 05472 Allowing a URI to be added to the set only once reduces 05473 unnecessary network traffic, and in the case of 05474 incorporating contacts from redirect requests prevents 05475 infinite recursion. 05476 05477 For example, a trivial location service is a "no-op", where the 05478 target URI is equal to the incoming request URI. The request is sent 05479 to a specific next hop proxy for further processing. During request 05480 forwarding of Section 16.6, Item 6, the identity of that next hop, 05481 expressed as a SIP or SIPS URI, is inserted as the top-most Route 05482 header field value into the request. 05483 05484 If the Request-URI indicates a resource at this proxy that does not 05485 exist, the proxy MUST return a 404 (Not Found) response. 05486 05487 If the target set remains empty after applying all of the above, the 05488 proxy MUST return an error response, which SHOULD be the 480 05489 (Temporarily Unavailable) response. 05490 05491 16.6 Request Forwarding 05492 05493 As soon as the target set is non-empty, a proxy MAY begin forwarding 05494 the request. A stateful proxy MAY process the set in any order. It 05495 MAY process multiple targets serially, allowing each client 05496 transaction to complete before starting the next. It MAY start client 05497 transactions with every target in parallel. It also MAY arbitrarily 05498 divide the set into groups, processing the groups serially and 05499 processing the targets in each group in parallel. 05500 05501 A common ordering mechanism is to use the qvalue parameter of targets 05502 obtained from Contact header fields (see Section 20.10). Targets are 05503 05504 05505 05506 J. Rosenberg et. al. [Page 93] 05507 Internet Draft SIP February 18, 2002 05508 05509 05510 processed from highest qvalue to lowest. Targets with equal qvalues 05511 may be processed in parallel. 05512 05513 A stateful proxy must have a mechanism to maintain the target set as 05514 responses are received and associate the responses to each forwarded 05515 request with the original request. For the purposes of this model, 05516 this mechanism is a "response context" created by the proxy layer 05517 before forwarding the first request. 05518 05519 For each target, the proxy forwards the request following these 05520 steps: 05521 05522 1. Make a copy of the received request 05523 05524 2. Update the Request-URI 05525 05526 3. Update the Max-Forwards header field 05527 05528 4. Optionally add a Record-route header field value 05529 05530 5. Optionally add additional header fields 05531 05532 6. Postprocess routing information 05533 05534 7. Determine the next-hop address, port, and transport 05535 05536 8. Add a Via header field value 05537 05538 9. Add a Content-Length header field if necessary 05539 05540 10. Forward the new request 05541 05542 11. Set timer C 05543 05544 Each of these steps is detailed below: 05545 05546 1. Copy request 05547 05548 The proxy starts with a copy of the received request. The 05549 copy MUST initially contain all of the header fields from 05550 the received request. Fields not detailed in the 05551 processing described below MUST NOT be removed. The copy 05552 SHOULD maintain the ordering of the header fields as in the 05553 received request. The proxy MUST NOT reorder field values 05554 with a common field name (See Section 7.3.1). The proxy 05555 MUST NOT add to, modify, or remove the message body. 05556 05557 05558 05559 05560 05561 J. Rosenberg et. al. [Page 94] 05562 Internet Draft SIP February 18, 2002 05563 05564 05565 An actual implementation need not perform a copy; the 05566 primary requirement is that the processing for each 05567 next hop begin with the same request. 05568 05569 2. Request-URI 05570 05571 The Request-URI in the copy's start line MUST be replaced 05572 with the URI for this target. If the URI contains any 05573 parameters not allowed in a Request-URI, they MUST be 05574 removed. 05575 05576 This is the essence of a proxy's role. This is the 05577 mechanism through which a proxy routes a request toward its 05578 destination. 05579 05580 In some circumstances, the received Request-URI is placed 05581 into the target set without being modified. For that 05582 target, the replacement above is effectively a no-op. 05583 05584 3. Max-Forwards 05585 05586 If the copy contains a Max-Forwards header field, the proxy 05587 MUST decrement its value by one (1). 05588 05589 If the copy does not contain a Max-Forwards header field, 05590 the proxy MUST add one with a field value which SHOULD be 05591 70. 05592 05593 05594 Some existing UAs will not provide a Max-Forwards 05595 header field in a request. 05596 05597 4. Record-Route 05598 05599 If this proxy wishes to remain on the path of future 05600 requests in a dialog created by this request (assuming the 05601 request creates a dialog), it MUST insert a Record-Route 05602 header field value into the copy before any existing 05603 Record-Route header field values, even if a Route header 05604 field is already present. 05605 05606 05607 Requests establishing a dialog may contain a preloaded 05608 Route header field. 05609 05610 If this request is already part of a dialog, the proxy 05611 SHOULD insert a Record-Route header field value if it 05612 wishes to remain on the path of future requests in the 05613 05614 05615 05616 J. Rosenberg et. al. [Page 95] 05617 Internet Draft SIP February 18, 2002 05618 05619 05620 dialog. In normal endpoint operation as described in 05621 Section 12 these Record-Route header field values will not 05622 have any effect on the route sets used by the endpoints. 05623 05624 05625 The proxy will remain on the path if it chooses to not 05626 insert a Record-Route header field value into requests 05627 that are already part of a dialog. However, it would 05628 be removed from the path when an endpoint that has 05629 failed reconstitutes the dialog. 05630 05631 A proxy MAY insert a Record-Route header field value into 05632 any request. If the request does not initiate a dialog, the 05633 endpoints will ignore the value. See Section 12 for details 05634 on how endpoints use the Record-Route header field values 05635 to construct Route header fields. 05636 05637 Each proxy in the path of a request chooses whether to add 05638 a Record-Route header field value independently - the 05639 presence of a Record-Route header field in a request does 05640 not obligate this proxy to add a value. 05641 05642 The URI placed in the Record-Route header field value MUST 05643 be a SIP URI. This URI MUST contain an lr parameter (see 05644 Section 19.1.1). This URI MAY be different for each 05645 destination the request is forwarded to. The URI SHOULD NOT 05646 contain the transport parameter unless the proxy has 05647 knowledge (such as in a private network) that the next 05648 downstream element that will be in the path of subsequent 05649 requests supports that transport. 05650 05651 05652 The URI this proxy provides will be used by some other 05653 element to make a routing decision. This proxy, in 05654 general, has no way to know what the capabilities of 05655 that element are, so it must restrict itself to the 05656 mandatory elements of a SIP implementation: SIP URIs 05657 and either the TCP or UDP transports. 05658 05659 The URI placed in the Record-Route header field MUST 05660 resolve to the element inserting it (or a suitable stand- 05661 in) when the server location procedures of [4] are applied 05662 to it, so that subsequent requests reach the same SIP 05663 element. If the Request-URI contains a SIPS URI, the URI 05664 placed into the Record-Route header field MUST be a SIPS 05665 URI. 05666 05667 If the URI placed in the Record-Route header field needs to 05668 05669 05670 05671 J. Rosenberg et. al. [Page 96] 05672 Internet Draft SIP February 18, 2002 05673 05674 05675 be rewritten when it passes back through in a response, the 05676 URI MUST be distinct enough to locate at that time. (The 05677 request may spiral through this proxy, resulting in more 05678 than one Record-Route header field value being added). 05679 Item 8 of Section 16.7 recommends a mechanism to make the 05680 URI sufficiently distinct. 05681 05682 The proxy MAY include parameters in the Record-Route header 05683 field value. These will be echoed in some responses to the 05684 request such as the 200 (OK) responses to INVITE. Such 05685 parameters may be useful for keeping state in the message 05686 rather than the proxy. 05687 05688 If a proxy needs to be in the path of any type of dialog 05689 (such as one straddling a firewall), it SHOULD add a 05690 Record-Route header field value to every request with a 05691 method it does not understand since that method may have 05692 dialog semantics. 05693 05694 The URI a proxy places into a Record-Route header field is 05695 only valid for the lifetime of any dialog created by the 05696 transaction in which it occurs. A dialog-stateful proxy, 05697 for example, MAY refuse to accept future requests with that 05698 value in the Request-URI after the dialog has terminated. 05699 Non-dialog-stateful proxies, of course, have no concept of 05700 when the dialog has terminated, but they MAY encode enough 05701 information in the value to compare it against the dialog 05702 identifier of future requests and MAY reject requests not 05703 matching that information. Endpoints MUST NOT use a URI 05704 obtained from a Record-Route header field outside the 05705 dialog in which it was provided. See Section 12 for more 05706 information on an endpoint's use of Record-Route header 05707 fields. 05708 05709 Record-routing may be required by certain services where 05710 the proxy needs to observe all messages in a dialog. 05711 However, it slows down processing and impairs scalability 05712 and thus proxies should only record-route if required for a 05713 particular service. 05714 05715 The Record-Route process is designed to work for any SIP 05716 request that initiates a dialog. INVITE is the only such 05717 request in this specification, but extensions to the 05718 protocol MAY define others. 05719 05720 5. Add Additional Header Fields 05721 05722 The proxy MAY add any other appropriate header fields to 05723 05724 05725 05726 J. Rosenberg et. al. [Page 97] 05727 Internet Draft SIP February 18, 2002 05728 05729 05730 the copy at this point. 05731 05732 6. Postprocess routing information 05733 05734 A proxy MAY have a local policy that mandates that a 05735 request visit a specific set of proxies before being 05736 delivered to the destination. A proxy MUST ensure that all 05737 such proxies are loose routers. Generally, this can only be 05738 known with certainty if the proxies are within the same 05739 administrative domain. This set of proxies is represented 05740 by a set of URIs (each of which contains the lr parameter). 05741 This set MUST be pushed into the Route header field of the 05742 copy ahead of any existing values, if present. If the Route 05743 header field is absent, it MUST be added, containing that 05744 list of URIs. If the Request-URI specifies a SIPS URI, the 05745 set of URIs MUST all be converted to SIPS URI, if they were 05746 not already SIPS URI. 05747 05748 If the proxy has a local policy that mandates that the 05749 request visit one specific proxy, an alternative to pushing 05750 a Route value into the Route header field is to bypass the 05751 forwarding logic of item 10 below, and instead just send 05752 the request to the address, port, and transport for that 05753 specific proxy. If the request has a Route header field, 05754 this alternative MUST NOT be used unless it is known that 05755 next hop proxy is a loose router. Otherwise, this approach 05756 MAY be used, but the Route insertion mechanism above is 05757 preferred for its robustness, flexibility, generality and 05758 consistency of operation. Furthermore, if the Request-URI 05759 contains a SIPS URI, TLS MUST be used to communicate with 05760 that proxy. 05761 05762 If the copy contains a Route header field, the proxy MUST 05763 inspect the URI in its first value. If that URI does not 05764 contain a lr parameter, the proxy MUST modify the copy as 05765 follows: 05766 05767 - The proxy MUST place the Request-URI into the Route 05768 header field as the last value. 05769 05770 - The proxy MUST then place the first Route header field 05771 value into the Request-URI and remove that value from the 05772 Route header field. 05773 05774 05775 Appending the Request-URI to the Route header field is 05776 part of a mechanism used to pass the information in 05777 that Request-URI through strict-routing elements. 05778 05779 05780 05781 J. Rosenberg et. al. [Page 98] 05782 Internet Draft SIP February 18, 2002 05783 05784 05785 "Popping" the first Route header field value into the 05786 Request-URI formats the message the way a strict- 05787 routing element expects to receive it (with its own 05788 URI in the Request-URI and the next location to visit 05789 in the first Route header field value). 05790 05791 7. Determine Next-Hop Address, Port, and Transport 05792 05793 The proxy MAY have a local policy to send the request to a 05794 specific IP address, port, and transport, independent of 05795 the values of the Route and Request-URI. Such a policy MUST 05796 NOT be used if the proxy is not certain that the IP 05797 address, port, and transport correspond to a server that is 05798 a loose router. However, this mechanism for sending the 05799 request through a specific next hop is NOT RECOMMENDED; 05800 instead a Route header field should be used for that 05801 purpose as described above. 05802 05803 In the absence of such an overriding mechanism, the proxy 05804 applies the procedures listed in [4] as follows to 05805 determine where to send the request. If the proxy has 05806 reformatted the request to send to a strict-routing element 05807 as described in step 6 above, the proxy MUST apply those 05808 procedures to the Request-URI of the request. Otherwise, 05809 the proxy MUST apply the procedures to the first value in 05810 the Route header field, if present, else the Request-URI. 05811 The procedures will produce an ordered set of (address, 05812 port, transport) tuples. 05813 05814 As described in [4], the proxy MUST attempt to deliver the 05815 message to the first tuple in that set, and proceed through 05816 the set in order until the delivery attempt succeeds. 05817 05818 For each tuple attempted, the proxy MUST format the message 05819 as appropriate for the tuple and send the request using a 05820 new client transaction as detailed in steps 8 through 10. 05821 Since each attempt uses a new client transaction, it 05822 represents a new branch. Thus, the branch parameter 05823 provided with the Via header field inserted in step 8 MUST 05824 be different for each attempt. 05825 05826 If the client transaction reports failure to send the 05827 request or a timeout from its state machine, the proxy 05828 continues to the next address in that ordered set. If the 05829 ordered set is exhausted, the request cannot be forwarded 05830 to this element in the target set. The proxy does not need 05831 to place anything in the response context, but otherwise 05832 acts as if this element of the target set returned a 408 05833 05834 05835 05836 J. Rosenberg et. al. [Page 99] 05837 Internet Draft SIP February 18, 2002 05838 05839 05840 (Request Timeout) final response. 05841 05842 8. Add a Via header field value 05843 05844 The proxy MUST insert a Via header field value into the 05845 copy before the existing Via header field values. The 05846 construction of this value follows the same guidelines of 05847 Section 8.1.1.7. This implies that the proxy will compute 05848 its own branch parameter, which will be globally unique for 05849 that branch, and contain the requisite magic cookie. 05850 05851 Proxies choosing to detect loops have an additional 05852 constraint in the value they use for construction of the 05853 branch parameter. A proxy choosing to detect loops SHOULD 05854 create a branch parameter separable into two parts by the 05855 implementation. The first part MUST satisfy the constraints 05856 of Section 8.1.1.7 as described above. The second is used 05857 to perform loop detection and distinguish loops from 05858 spirals. 05859 05860 Loop detection is performed by verifying that, when a 05861 request returns to a proxy, those fields having an impact 05862 on the processing of the request have not changed. The 05863 value placed in this part of the branch parameter SHOULD 05864 reflect all of those fields (including any Route, Proxy- 05865 Require and Proxy-Authorization header fields). This is to 05866 ensure that if the request is routed back to the proxy and 05867 one of those fields changes, it is treated as a spiral and 05868 not a loop (Section 16.3 A common way to create this value 05869 is to compute a cryptographic hash of the To tag, From tag, 05870 Call-ID header field, the Request-URI of the request 05871 received (before translation) and the sequence number from 05872 the CSeq header field, in addition to any Proxy-Require and 05873 Proxy-Authorization header fields that may be present. The 05874 algorithm used to compute the hash is implementation- 05875 dependent, but MD5 [34], expressed in hexadecimal, is a 05876 reasonable choice. (Base64 is not permissible for a token.) 05877 05878 05879 If a proxy wishes to detect loops, the "branch" 05880 parameter it supplies MUST depend on all information 05881 affecting processing of a request, including the 05882 incoming Request-URI and any header fields affecting 05883 the request's admission or routing. This is necessary 05884 to distinguish looped requests from requests whose 05885 routing parameters have changed before returning to 05886 this server. 05887 05888 05889 05890 05891 J. Rosenberg et. al. [Page 100] 05892 Internet Draft SIP February 18, 2002 05893 05894 05895 The request method MUST NOT be included in the calculation 05896 of the branch parameter. In particular, CANCEL and ACK 05897 requests (for non-2xx responses) MUST have the same branch 05898 value as the corresponding request they cancel or 05899 acknowledge. The branch parameter is used in correlating 05900 those requests at the server handling them (see Sections 05901 17.2.3 and 9.2). 05902 05903 9. Add a Content-Length header field if necessary 05904 05905 If the request will be sent to the next hop using a 05906 stream-based transport and the copy contains no Content- 05907 Length header field, the proxy MUST insert one with the 05908 correct value for the body of the request (see Section 05909 20.14). 05910 05911 10. Forward Request 05912 05913 A stateful proxy MUST create a new client transaction for 05914 this request as described in Section 17.1 and instructs the 05915 transaction to send the request using the address, port and 05916 transport determined in step 7. 05917 05918 11. Set timer C 05919 05920 In order to handle the case where an INVITE request never 05921 generates a final response, the TU uses a timer which is 05922 called timer C. Timer C MUST be set for each client 05923 transaction when an INVITE request is proxied. The timer 05924 MUST be larger than 3 minutes. Section 16.7 bullet 2 05925 discusses how this timer is updated with provisional 05926 responses, and Section 16.8 discusses processing when it 05927 fires. 05928 05929 16.7 Response Processing 05930 05931 When a response is received by an element, it first tries to locate a 05932 client transaction (Section 17.1.3) matching the response. If none is 05933 found, the element MUST process the response (even if it is an 05934 informational response) as a stateless proxy (described below). If a 05935 match is found, the response is handed to the client transaction. 05936 05937 05938 Forwarding responses for which a client transaction (or 05939 more generally any knowledge of having sent an associated 05940 request) is not found improves robustness. In particular, 05941 it ensures that "late" 2xx responses to INVITE requests are 05942 forwarded properly. 05943 05944 05945 05946 J. Rosenberg et. al. [Page 101] 05947 Internet Draft SIP February 18, 2002 05948 05949 05950 As client transactions pass responses to the proxy layer, the 05951 following processing MUST take place: 05952 05953 1. Find the appropriate response context 05954 05955 2. Update timer C for provisional responses 05956 05957 3. Remove the topmost Via 05958 05959 4. Add the response to the response context 05960 05961 5. Check to see if this response should be forwarded 05962 immediately 05963 05964 6. When necessary, choose the best final response from the 05965 response context 05966 05967 If no final response has been forwarded after every client 05968 transaction associated with the response context has been 05969 terminated, the proxy must choose and forward the "best" 05970 response from those it has seen so far. 05971 05972 The following processing MUST be performed on each response 05973 that is forwarded. It is likely that more than one response 05974 to each request will be forwarded: at least each 05975 provisional and one final response. 05976 05977 7. Aggregate authorization header field values if necessary 05978 05979 8. Optionally rewrite Record-Route header field values 05980 05981 9. Forward the response 05982 05983 10. Generate any necessary CANCEL requests 05984 05985 Each of the above steps are detailed below: 05986 05987 1. Find Context 05988 05989 The proxy locates the "response context" it created before 05990 forwarding the original request using the key described in 05991 Section 16.6. The remaining processing steps take place in 05992 this context. 05993 05994 2. Update timer C for provisional responses 05995 05996 For an INVITE transaction, if the response is a provisional 05997 response with status codes 101 to 199 inclusive (i.e., 05998 05999 06000 06001 J. Rosenberg et. al. [Page 102] 06002 Internet Draft SIP February 18, 2002 06003 06004 06005 anything but 100), the proxy MUST reset timer C for that 06006 client transaction. The timer MAY be reset to a different 06007 value, but this value MUST be greater than 3 minutes. 06008 06009 3. Via 06010 06011 The proxy removes the topmost Via header field value from 06012 the response. 06013 06014 If no Via header field values remain in the response, the 06015 response was meant for this element and MUST NOT be 06016 forwarded. The remainder of the processing described in 06017 this section is not performed on this message, the UAC 06018 processing rules described in Section 8.1.3 are followed 06019 instead (transport layer processing has already occurred). 06020 06021 This will happen, for instance, when the element generates 06022 CANCEL requests as described in Section 10. 06023 06024 4. Add response to context 06025 06026 Final responses received are stored in the response context 06027 until a final response is generated on the server 06028 transaction associated with this context. The response may 06029 be a candidate for the best final response to be returned 06030 on that server transaction. Information from this response 06031 may be needed in forming the best response even if this 06032 response is not chosen. 06033 06034 If the proxy chooses to recurse on any contacts in a 3xx 06035 response by adding them to the target set, it MUST remove 06036 them from the response before adding the response to the 06037 response context. However, a proxy MUST NOT recurse to a 06038 non-SIPS URI if the Request-URI of the original request was 06039 a SIPS URI. If the proxy recurses on all of the contacts 06040 in a 3xx response, the proxy SHOULD NOT add the resulting 06041 contactless response to the response context. 06042 06043 06044 Removing the contact before adding the response to the 06045 response context prevents the next element upstream 06046 from retrying a location this proxy has already 06047 attempted. 06048 06049 3xx responses may contain a mixture of SIP, SIPS, and non- 06050 SIP URIs. A proxy may choose to recurse on the SIP and SIPS 06051 URIs and place the remainder into the response context to 06052 be returned potentially in the final response. 06053 06054 06055 06056 J. Rosenberg et. al. [Page 103] 06057 Internet Draft SIP February 18, 2002 06058 06059 06060 If a proxy receives a 416 (Unsupported URI Scheme) response 06061 to a request whose Request-URI scheme was not SIP, but the 06062 scheme in the original received request was SIP or SIPS 06063 (that is, the proxy changed the scheme from SIP or SIPS to 06064 something else when it proxied a request), the proxy SHOULD 06065 add a new URI to the target set. This URI SHOULD be a SIP 06066 URI version of the non-SIP URI that was just tried. In the 06067 case of the tel URL, this is accomplished by placing the 06068 telephone-subscriber part of the tel URL into the user part 06069 of the SIP URI, and setting the hostpart to the domain 06070 where the prior request was sent. See Section 19.1.6 for 06071 more detail on forming SIP URIs from tel URLs. 06072 06073 As with a 3xx response, if a proxy "recurses" on the 416 by 06074 trying a SIP or SIPS URI instead, the 416 response SHOULD 06075 NOT be added to the response context. 06076 06077 5. Check response for forwarding 06078 06079 Until a final response has been sent on the server 06080 transaction, the following responses MUST be forwarded 06081 immediately: 06082 06083 - Any provisional response other than 100 (Trying) 06084 06085 - Any 2xx response 06086 06087 If a 6xx response is received, it is not immediately 06088 forwarded, but the stateful proxy SHOULD cancel all client 06089 pending transactions as described in Section 10, and it 06090 MUST NOT create any new branches in this context. 06091 06092 06093 This is a change from RFC 2543, which mandated that 06094 the proxy was to forward the 6xx response immediately. 06095 For an INVITE transaction, this approach had the 06096 problem that a 2xx response could arrive on another 06097 branch, in which case the proxy would have to forward 06098 the 2xx. The result was that the UAC could receive a 06099 6xx response followed by a 2xx response, which should 06100 never be allowed to happen. Under the new rules, upon 06101 receiving a 6xx, a proxy will issue a CANCEL request, 06102 which will generally result in 487 responses from all 06103 outstanding client transactions, and then at that 06104 point the 6xx is forwarded upstream. 06105 06106 After a final response has been sent on the server 06107 transaction, the following responses MUST be forwarded 06108 06109 06110 06111 J. Rosenberg et. al. [Page 104] 06112 Internet Draft SIP February 18, 2002 06113 06114 06115 immediately: 06116 06117 - Any 2xx response to an INVITE request 06118 06119 A stateful proxy MUST NOT immediately forward any other 06120 responses. In particular, a stateful proxy MUST NOT forward 06121 any 100 (Trying) response. Those responses that are 06122 candidates for forwarding later as the "best" response have 06123 been gathered as described in step "Add Response to 06124 Context". 06125 06126 Any response chosen for immediate forwarding MUST be 06127 processed as described in steps "Aggregate Authorization 06128 Header Field Values" through "Record-Route". 06129 06130 This step, combined with the next, ensures that a stateful 06131 proxy will forward exactly one final response to a non- 06132 INVITE request, and either exactly one non-2xx response or 06133 one or more 2xx responses to an INVITE request. 06134 06135 6. Choosing the best response 06136 06137 A stateful proxy MUST send a final response to a response 06138 context's server transaction if no final responses have 06139 been immediately forwarded by the above rules and all 06140 client transactions in this response context have been 06141 terminated. 06142 06143 The stateful proxy MUST choose the "best" final response 06144 among those received and stored in the response context. 06145 06146 If there are no final responses in the context, the proxy 06147 MUST send a 408 (Request Timeout) response to the server 06148 transaction. 06149 06150 Otherwise, the proxy MUST forward a response from the 06151 responses stored in the response context. It MUST choose 06152 from the 6xx class responses if any exist in the context. 06153 If no 6xx class responses are present, the proxy SHOULD 06154 choose from the lowest response class stored in the 06155 response context. The proxy MAY select any response within 06156 that chosen class. The proxy SHOULD give preference to 06157 responses that provide information affecting resubmission 06158 of this request, such as 401, 407, 415, 420, and 484 if the 06159 4xx class is chosen. 06160 06161 A proxy which receives a 503 (Service Unavailable) response 06162 SHOULD NOT forward it upstream unless it can determine that 06163 06164 06165 06166 J. Rosenberg et. al. [Page 105] 06167 Internet Draft SIP February 18, 2002 06168 06169 06170 any subsequent requests it might proxy will also generate a 06171 503. In other words, forwarding a 503 means that the proxy 06172 knows it cannot service any requests, not just the one for 06173 the Request-URI in the request which generated the 503. 06174 06175 The forwarded response MUST be processed as described in 06176 steps "Aggregate Authorization Header Field Values" through 06177 "Record-Route". 06178 06179 For example, if a proxy forwarded a request to 4 locations, 06180 and received 503, 407, 501, and 404 responses, it may 06181 choose to forward the 407 (Proxy Authentication Required) 06182 response. 06183 06184 1xx and 2xx responses may be involved in the establishment 06185 of dialogs. When a request does not contain a To tag, the 06186 To tag in the response is used by the UAC to distinguish 06187 multiple responses to a dialog creating request. A proxy 06188 MUST NOT insert a tag into the To header field of a 1xx or 06189 2xx response if the request did not contain one. A proxy 06190 MUST NOT modify the tag in the To header field of a 1xx or 06191 2xx response. 06192 06193 Since a proxy may not insert a tag into the To header field 06194 of a 1xx response to a request that did not contain one, it 06195 cannot issue non-100 provisional responses on its own. 06196 However, it can branch the request to a UAS sharing the 06197 same element as the proxy. This UAS can return its own 06198 provisional responses, entering into an early dialog with 06199 the initiator of the request. The UAS does not have to be a 06200 discreet process from the proxy. It could be a virtual UAS 06201 implemented in the same code space as the proxy. 06202 06203 3-6xx responses are delivered hop-hop. When issuing a 3-6xx 06204 response, the element is effectively acting as a UAS, 06205 issuing its own response, usually based on the responses 06206 received from downstream elements. An element SHOULD 06207 preserve the To tag when simply forwarding a 3-6xx response 06208 to a request that did not contain a To tag. 06209 06210 A proxy MUST NOT modify the To tag in any forwarded 06211 response to a request that contains a To tag. 06212 06213 06214 While it makes no difference to the upstream elements 06215 if the proxy replaced the To tag in a forwarded 3-6xx 06216 response, preserving the original tag may assist with 06217 debugging. 06218 06219 06220 06221 J. Rosenberg et. al. [Page 106] 06222 Internet Draft SIP February 18, 2002 06223 06224 06225 When the proxy is aggregating information from several 06226 responses, choosing a To tag from among them is arbitrary, 06227 and generating a new To tag may make debugging easier. This 06228 happens, for instance, when combining 401 (Unauthorized) 06229 and 407 (Proxy Authentication Required) challenges, or 06230 combining Contact values from unencrypted and 06231 unauthenticated 3xx responses. 06232 06233 7. Aggregate Authorization Header Field Values 06234 06235 If the selected response is a 401 (Unauthorized) or 407 06236 (Proxy Authentication Required), the proxy MUST collect any 06237 WWW-Authenticate and Proxy-Authenticate header field values 06238 from all other 401 (Unauthorized) and 407 (Proxy 06239 Authentication Required) responses received so far in this 06240 response context and add them to this response without 06241 modification before forwarding. The resulting 401 06242 (Unauthorized) or 407 (Proxy Authentication Required) 06243 response could have several WWW-Authenticate AND Proxy- 06244 Authenticate header field values. 06245 06246 This is necessary because any or all of the destinations 06247 the request was forwarded to may have requested 06248 credentials. The client needs to receive all of those 06249 challenges and supply credentials for each of them when it 06250 retries the request. Motivation for this behavior is 06251 provided in Section 26. 06252 06253 8. Record-Route 06254 06255 If the selected response contains a Record-Route header 06256 field value originally provided by this proxy, the proxy 06257 MAY choose to rewrite the value before forwarding the 06258 response. This allows the proxy to provide different URIs 06259 for itself to the next upstream and downstream elements. A 06260 proxy may choose to use this mechanism for any reason. For 06261 instance, it is useful for multi-homed hosts. 06262 06263 The new URI provided by the proxy MUST satisfy the same 06264 constraints on URIs placed in Record-Route header fields in 06265 requests (see Step 4 of Section 16.6) with the following 06266 modifications: 06267 06268 The URI SHOULD NOT contain the transport parameter unless 06269 the proxy has knowledge that the next upstream (as opposed 06270 to downstream) element that will be in the path of 06271 subsequent requests supports that transport. 06272 06273 06274 06275 06276 J. Rosenberg et. al. [Page 107] 06277 Internet Draft SIP February 18, 2002 06278 06279 06280 When a proxy does decide to modify the Record-Route header 06281 field in the response, one of the operations it performs is 06282 locating the Record-Route value that it had inserted. If 06283 the request spiraled, and the proxy inserted a Record-Route 06284 value in each iteration of the spiral, locating the correct 06285 value in the response (which must be the proper iteration 06286 in the reverse direction) is tricky. The rules above 06287 recommend that a proxy wishing to rewrite Record-Route 06288 header field values insert sufficiently distinct URIs into 06289 the Record-Route header field so that the right one may be 06290 selected for rewriting. A RECOMMENDED mechanism to achieve 06291 this is for the proxy to append a unique identifier for the 06292 proxy instance to the user portion of the URI. 06293 06294 When the response arrives, the proxy modifies the first 06295 Record-Route whose identifier matches the proxy instance. 06296 The modification results in a URI without this piece of 06297 data appended to the user portion of the URI. Upon the next 06298 iteration, the same algorithm (find the topmost Record- 06299 Route header field value with the parameter) will correctly 06300 extract the next Record-Route header field value inserted 06301 by that proxy. 06302 06303 06304 Not every response to a request to which a proxy adds 06305 a Record-Route header field value will contain a 06306 Record-Route header field. If the response does 06307 contain a Record-Route header field, it will contain 06308 the value the proxy added. 06309 06310 9. Forward response 06311 06312 After performing the processing described in steps 06313 "Aggregate Authorization Header Field Values" through 06314 "Record-Route", the proxy MAY perform any feature specific 06315 manipulations on the selected response. The proxy MUST NOT 06316 add to, modify, or remove the message body. Unless 06317 otherwise specified, the proxy MUST NOT remove any header 06318 field values other than the Via header field value 06319 discussed in Section 16.7 Item 3. In particular, the proxy 06320 MUST NOT remove any "received" parameter it may have added 06321 to the next Via header field value while processing the 06322 request associated with this response. The proxy MUST pass 06323 the response to the server transaction associated with the 06324 response context. This will result in the response being 06325 sent to the location now indicated in the topmost Via 06326 header field value. If the server transaction is no longer 06327 available to handle the transmission, the element MUST 06328 06329 06330 06331 J. Rosenberg et. al. [Page 108] 06332 Internet Draft SIP February 18, 2002 06333 06334 06335 forward the response statelessly by sending it to the 06336 server transport. The server transaction might indicate 06337 failure to send the response or signal a timeout in its 06338 state machine. These errors would be logged for diagnostic 06339 purposes as appropriate, but the protocol requires no 06340 remedial action from the proxy. 06341 06342 The proxy MUST maintain the response context until all of 06343 its associated transactions have been terminated, even 06344 after forwarding a final response. 06345 06346 10. Generate CANCELs 06347 06348 If the forwarded response was a final response, the proxy 06349 MUST generate a CANCEL request for all pending client 06350 transactions associated with this response context. A proxy 06351 SHOULD also generate a CANCEL request for all pending 06352 client transactions associated with this response context 06353 when it receives a 6xx response. A pending client 06354 transaction is one that has received a provisional 06355 response, but no final response (it is in the proceeding 06356 state) and has not had an associated CANCEL generated for 06357 it. Generating CANCEL requests is described in Section 06358 9.1. 06359 06360 The requirement to CANCEL pending client transactions upon 06361 forwarding a final response does not guarantee that an 06362 endpoint will not receive multiple 200 (OK) responses to an 06363 INVITE. 200 (OK) responses on more than one branch may be 06364 generated before the CANCEL requests can be sent and 06365 processed. Further, it is reasonable to expect that a 06366 future extension may override this requirement to issue 06367 CANCEL requests. 06368 06369 16.8 Processing Timer C 06370 06371 If timer C should fire, the proxy MUST either reset the timer with 06372 any value it chooses, or terminate the client transaction. If the 06373 client transaction has received a provisional response, the proxy 06374 MUST generate a CANCEL request matching that transaction. If the 06375 client transaction has not received a provisional response, the proxy 06376 MUST behave as if the transaction received a 408 (Request Timeout) 06377 response. 06378 06379 Allowing the proxy to reset the timer allows the proxy to dynamically 06380 extend the transaction's lifetime based on current conditions (such 06381 as utilization) when the timer fires. 06382 06383 06384 06385 06386 J. Rosenberg et. al. [Page 109] 06387 Internet Draft SIP February 18, 2002 06388 06389 06390 16.9 Handling Transport Errors 06391 06392 If the transport layer notifies a proxy of an error when it tries to 06393 forward a request (see Section 18.4), the proxy MUST behave as if the 06394 forwarded request received a 400 (Bad Request) response. 06395 06396 If the proxy is notified of an error when forwarding a response, it 06397 drops the response. The proxy SHOULD NOT cancel any outstanding 06398 client transactions associated with this response context due to this 06399 notification. 06400 06401 06402 If a proxy cancels its outstanding client transactions, a 06403 single malicious or misbehaving client can cause all 06404 transactions to fail through its Via header field. 06405 06406 16.10 CANCEL Processing 06407 06408 A stateful proxy MAY generate a CANCEL to any other request it has 06409 generated at any time (subject to receiving a provisional response to 06410 that request as described in section 9.1). A proxy MUST cancel any 06411 pending client transactions associated with a response context when 06412 it receives a matching CANCEL request. 06413 06414 A stateful proxy MAY generate CANCEL requests for pending INVITE 06415 client transactions based on the period specified in the INVITE's 06416 Expires header field elapsing. However, this is generally unnecessary 06417 since the endpoints involved will take care of signaling the end of 06418 the transaction. 06419 06420 While a CANCEL request is handled in a stateful proxy by its own 06421 server transaction, a new response context is not created for it. 06422 Instead, the proxy layer searches its existing response contexts for 06423 the server transaction handling the request associated with this 06424 CANCEL. If a matching response context is found, the element MUST 06425 immediately return a 200 (OK) response to the CANCEL request. In this 06426 case, the element is acting as a user agent server as defined in 06427 Section 8.2. Furthermore, the element MUST generate CANCEL requests 06428 for all pending client transactions in the context as described in 06429 Section 16.7 step 10. 06430 06431 If a response context is not found, the element does not have any 06432 knowledge of the request to apply the CANCEL to. It MUST statelessly 06433 forward the CANCEL request (it may have statelessly forwarded the 06434 associated request previously). 06435 06436 16.11 Stateless Proxy 06437 06438 06439 06440 06441 J. Rosenberg et. al. [Page 110] 06442 Internet Draft SIP February 18, 2002 06443 06444 06445 When acting statelessly, a proxy is a simple message forwarder. Much 06446 of the processing performed when acting statelessly is the same as 06447 when behaving statefully. The differences are detailed here. 06448 06449 A stateless proxy does not have any notion of a transaction, or of 06450 the response context used to describe stateful proxy behavior. 06451 Instead, the stateless proxy takes messages, both requests and 06452 responses, directly from the transport layer (See section 18). As a 06453 result, stateless proxies do not retransmit messages on their own. 06454 They do, however, forward all retransmission they receive (they do 06455 not have the ability to distinguish a retransmission from the 06456 original message). Furthermore, when handling a request statelessly, 06457 an element MUST NOT generate its own 100 (Trying) or any other 06458 provisional response. 06459 06460 A stateless proxy MUST validate a request as described in Section 06461 16.3 06462 06463 A stateless proxy MUST follow the request processing steps described 06464 in Sections 16.4 through 16.5 with the following exception: 06465 06466 o A stateless proxy MUST choose one and only one target from the 06467 target set. This choice MUST only rely on fields in the 06468 message and time-invariant properties of the server. In 06469 particular, a retransmitted request MUST be forwarded to the 06470 same destination each time it is processed. Furthermore, 06471 CANCEL and non-Routed ACK requests MUST generate the same 06472 choice as their associated INVITE. 06473 06474 A stateless proxy MUST follow the request processing steps described 06475 in Section 16.6 with the following exceptions: 06476 06477 o The requirement for unique branch IDs across space and time 06478 applies to stateless proxies as well. However, a stateless 06479 proxy cannot simply use a random number generator to compute 06480 the first component of the branch ID, as described in Section 06481 16.6 bullet 8. This is because retransmissions of a request 06482 need to have the same value, and a stateless proxy cannot tell 06483 a retransmission from the original request. Therefore, the 06484 component of the branch parameter that makes it unique MUST be 06485 the same each time a retransmitted request is forwarded. Thus 06486 for a stateless proxy, the branch parameter MUST be computed 06487 as a combinatoric function of message parameters which are 06488 invariant on retransmission. 06489 06490 The stateless proxy MAY use any technique it likes to 06491 guarantee uniqueness of its branch IDs across transactions. 06492 However, the following procedure is RECOMMENDED. The proxy 06493 06494 06495 06496 J. Rosenberg et. al. [Page 111] 06497 Internet Draft SIP February 18, 2002 06498 06499 06500 examines the branch ID in the topmost Via header field of the 06501 received request. If it begins with the magic cookie, the 06502 first component of the branch ID of the outgoing request is 06503 computed as a hash of the received branch ID. Otherwise, the 06504 first component of the branch ID is computed as a hash of the 06505 topmost Via, the tag in the To header field, the tag in the 06506 From header field, the Call-ID header field, the CSeq number 06507 (but not method), and the Request-URI from the received 06508 request. One of these fields will always vary across two 06509 different transactions. 06510 06511 o All other message transformations specified in Section 16.6 06512 MUST result in the same transformation of a retransmitted 06513 request. In particular, if the proxy inserts a Record-Route 06514 value or pushes URIs into the Route header field, it MUST 06515 place the same values in retransmissions of the request. As 06516 for the Via branch parameter, this implies that the 06517 transformations MUST be based on time-invariant configuration 06518 or retransmission-invariant properties of the request. 06519 06520 o A stateless proxy determines where to forward the request as 06521 described for stateful proxies in Section 16.6 Item 10. The 06522 request is sent directly to the transport layer instead of 06523 through a client transaction. 06524 06525 06526 Since a stateless proxy must forward retransmitted requests 06527 to the same destination and add identical branch parameters 06528 to each of them, it can only use information from the 06529 message itself and time-invariant configuration data for 06530 those calculations. If the configuration state is not 06531 time-invariant (for example, if a routing table is updated) 06532 any requests that could be affected by the change may not 06533 be forwarded statelessly during an interval equal to the 06534 transaction timeout window before or after the change. The 06535 method of processing the affected requests in that interval 06536 is an implementation decision. A common solution is to 06537 forward them transaction statefully. 06538 06539 Stateless proxies MUST NOT perform special processing for CANCEL 06540 requests. They are processed by the above rules as any other 06541 requests. In particular, a stateless proxy applies the same Route 06542 header field processing to CANCEL requests that it applies to any 06543 other request. 06544 06545 Response processing as described in Section 16.7 does not apply to a 06546 proxy behaving statelessly. When a response arrives at a stateless 06547 proxy, the proxy MUST inspect the sent-by value in the first 06548 06549 06550 06551 J. Rosenberg et. al. [Page 112] 06552 Internet Draft SIP February 18, 2002 06553 06554 06555 (topmost) Via header field value. If that address matches the proxy 06556 (it equals a value this proxy has inserted into previous requests) 06557 the proxy MUST remove that header field value from the response and 06558 forward the result to the location indicated in the next Via header 06559 field value. The proxy MUST NOT add to, modify, or remove the 06560 message body. Unless specified otherwise, the proxy MUST NOT remove 06561 any other header field values. If the address does not match the 06562 proxy, the message MUST be silently discarded. 06563 06564 16.12 Summary of Proxy Route Processing 06565 06566 In the absence of local policy to the contrary, the processing a 06567 proxy performs on a request containing a Route header field can be 06568 summarized in the following steps. 06569 06570 1. The proxy will inspect the Request-URI. If it indicates a 06571 resource owned by this proxy, the proxy will replace it 06572 with the results of running a location service. Otherwise, 06573 the proxy will not change the Request-URI. 06574 06575 2. The proxy will inspect the URI in the topmost Route header 06576 field value. If it indicates this proxy, the proxy removes 06577 it from the Route header field (this route node has been 06578 reached). 06579 06580 3. The proxy will forward the request to the resource 06581 indicated by the URI in the topmost Route header field 06582 value or in the Request-URI if no Route header field is 06583 present. The proxy determines the address, port and 06584 transport to use when forwarding the request by applying 06585 the procedures in [4] to that URI. 06586 06587 If no strict-routing elements are encountered on the path of the 06588 request, the Request-URI will always indicate the target of the 06589 request. 06590 06591 16.12.1 Examples 06592 06593 16.12.1.1 Basic SIP Trapezoid 06594 06595 This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with 06596 both proxies record-routing. Here is the flow. 06597 06598 U1 sends: 06599 06600 06601 INVITE sip:callee@domain.com SIP/2.0 06602 Contact: sip:caller@u1.example.com 06603 06604 06605 06606 J. Rosenberg et. al. [Page 113] 06607 Internet Draft SIP February 18, 2002 06608 06609 06610 to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, 06611 so it looks it up in DNS and sends it there. It also adds a Record- 06612 Route header field value: 06613 06614 06615 INVITE sip:callee@domain.com SIP/2.0 06616 Contact: sip:caller@u1.example.com 06617 Record-Route: 06618 06619 06620 06621 P2 gets this. It is responsible for domain.com so it runs a location 06622 service and rewrites the Request-URI. It also adds a Record-Route 06623 header field value. There is no Route header field, so it resolves 06624 the new Request-URI to determine where to send the request: 06625 06626 06627 INVITE sip:callee@u2.domain.com SIP/2.0 06628 Contact: sip:caller@u1.example.com 06629 Record-Route: 06630 Record-Route: 06631 06632 06633 06634 The callee at u2.domain.com gets this and responds with a 200 OK: 06635 06636 06637 SIP/2.0 200 OK 06638 Contact: sip:callee@u2.domain.com 06639 Record-Route: 06640 Record-Route: 06641 06642 06643 06644 The callee at u2 also sets its dialog state's remote target URI to 06645 sip:caller@u1.example.com and its route set to 06646 06647 (,) 06648 06649 06650 06651 This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its 06652 dialog state's remote target URI to sip:callee@u2.domain.com and its 06653 route set to 06654 06655 (,) 06656 06657 06658 06659 06660 06661 J. Rosenberg et. al. [Page 114] 06662 Internet Draft SIP February 18, 2002 06663 06664 06665 Since all the route set elements contain the lr parameter, U1 06666 constructs the following BYE request: 06667 06668 06669 BYE sip:callee@u2.domain.com SIP/2.0 06670 Route: , 06671 06672 06673 06674 As any other element (including proxies) would do, it resolves the 06675 URI in the topmost Route header field value using DNS to determine 06676 where to send the request. This goes to P1. P1 notices that it is 06677 not responsible for the resource indicated in the Request-URI so it 06678 doesn't change it. It does see that it is the first value in the 06679 Route header field, so it removes that value, and forwards the 06680 request to P2: 06681 06682 06683 BYE sip:callee@u2.domain.com SIP/2.0 06684 Route: 06685 06686 06687 06688 P2 also notices it is not responsible for the resource indicated by 06689 the Request-URI (it is responsible for domain.com, not 06690 u2.domain.com), so it doesn't change it. It does see itself in the 06691 first Route header field value, so it removes it and forwards the 06692 following to u2.domain.com based on a DNS lookup against the 06693 Request-URI: 06694 06695 06696 BYE sip:callee@u2.domain.com SIP/2.0 06697 06698 06699 06700 16.12.1.2 Traversing a strict-routing proxy 06701 06702 In this scenario, a dialog is established across four proxies, each 06703 of which adds Record-Route header field values. The third proxy 06704 implements the strict-routing procedures specified in RFC 2543 and 06705 the bis drafts up to bis-05. 06706 06707 06708 U1->P1->P2->P3->P4->U2 06709 06710 06711 06712 The INVITE arriving at U2 contains 06713 06714 06715 06716 J. Rosenberg et. al. [Page 115] 06717 Internet Draft SIP February 18, 2002 06718 06719 06720 INVITE sip:callee@u2.domain.com SIP/2.0 06721 Contact: sip:caller@u1.example.com 06722 Record-Route: 06723 Record-Route: 06724 Record-Route: 06725 Record-Route: 06726 06727 06728 06729 Which U2 responds to with a 200 OK. Later, U2 sends the following BYE 06730 request to P4 based on the first Route header field value. 06731 06732 06733 BYE sip:caller@u1.example.com SIP/2.0 06734 Route: 06735 Route: 06736 Route: 06737 Route: 06738 06739 06740 06741 P4 is not responsible for the resource indicated in the Request-URI 06742 so it will leave it alone. It notices that it is the element in the 06743 first Route header field value so it removes it. It then prepares to 06744 send the request based on the now first Route header field value of 06745 sip:p3.middle.com, but it notices that this URI does not contain the 06746 lr parameter, so before sending, it reformats the request to be: 06747 06748 06749 BYE sip:p3.middle.com SIP/2.0 06750 Route: 06751 Route: 06752 Route: 06753 06754 06755 06756 P3 is a strict router, so it forwards the following to P2: 06757 06758 06759 BYE sip:p2.example.com;lr SIP/2.0 06760 Route: 06761 Route: 06762 06763 06764 06765 P2 sees the request-URI is a value it placed into a Record-Route 06766 header field, so before further processing, it rewrites the request 06767 to be 06768 06769 06770 06771 J. Rosenberg et. al. [Page 116] 06772 Internet Draft SIP February 18, 2002 06773 06774 06775 BYE sip:caller@u1.example.com SIP/2.0 06776 Route: 06777 06778 06779 06780 P2 is not responsible for u1.example.com so it sends the request to 06781 P1 based on the resolution of the Route header field value. 06782 06783 P1 notices itself in the topmost Route header field value, so it 06784 removes it, resulting in: 06785 06786 06787 BYE sip:caller@u1.example.com SIP/2.0 06788 06789 06790 06791 Since P1 is not responsible for u1.example.com and there is no Route 06792 header field, P1 will forward the request to u1.example.com based on 06793 the Request-URI. 06794 06795 16.12.1.3 Rewriting Record-Route header field values 06796 06797 In this scenario, U1 and U2 are in different private namespaces and 06798 they enter a dialog through a proxy P1, which acts as a gateway 06799 between the namespaces. 06800 06801 06802 U1->P1->U2 06803 06804 06805 06806 U1 sends: 06807 06808 06809 INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 06810 Contact: 06811 06812 06813 06814 P1 uses its location service and sends the following to U2: 06815 06816 06817 INVITE sip:callee@rightprivatespace.com SIP/2.0 06818 Contact: 06819 Record-Route: 06820 06821 06822 06823 06824 06825 06826 J. Rosenberg et. al. [Page 117] 06827 Internet Draft SIP February 18, 2002 06828 06829 06830 U2 sends this 200 (OK) back to PI: 06831 06832 06833 SIP/2.0 200 OK 06834 Contact: 06835 Record-Route: 06836 06837 06838 06839 P1 rewrites its Record-Route header parameter to provide a value that 06840 U1 will find useful, and sends the following to U1: 06841 06842 06843 SIP/2.0 200 OK 06844 Contact: 06845 Record-Route: 06846 06847 06848 06849 Later, U1 sends the following BYE request to P1: 06850 06851 06852 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 06853 Route: 06854 06855 06856 06857 which P1 forwards to U2 as 06858 06859 06860 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 06861 06862 06863 06864 17 Transactions 06865 06866 SIP is a transactional protocol: interactions between components take 06867 place in a series of independent message exchanges. Specifically, a 06868 SIP transaction consists of a single request and any responses to 06869 that request, which include zero or more provisional responses and 06870 one or more final responses. In the case of a transaction where the 06871 request was an INVITE (known as an INVITE transaction), the 06872 transaction also includes the ACK only if the final response was not 06873 a 2xx response. If the response was a 2xx, the ACK is not considered 06874 part of the transaction. 06875 06876 The reason for this separation is rooted in the importance 06877 of delivering all 200 (OK) responses to an INVITE to the 06878 06879 06880 06881 J. Rosenberg et. al. [Page 118] 06882 Internet Draft SIP February 18, 2002 06883 06884 06885 UAC. To deliver them all to the UAC, the UAS alone takes 06886 responsibility for retransmitting them (see Section 06887 13.3.1.4), and the UAC alone takes responsibility for 06888 acknowledging them with ACK (see Section 13.2.2.4). Since 06889 this ACK is retransmitted only by the UAC, it is 06890 effectively considered its own transaction. 06891 06892 Transactions have a client side and a server side. The client side is 06893 known as a client transaction and the server side as a server 06894 transaction. The client transaction sends the request, and the server 06895 transaction sends the response. The client and server transactions 06896 are logical functions that are embedded in any number of elements. 06897 Specifically, they exist within user agents and stateful proxy 06898 servers. Consider the example in Section 4. In this example, the UAC 06899 executes the client transaction, and its outbound proxy executes the 06900 server transaction. The outbound proxy also executes a client 06901 transaction, which sends the request to a server transaction in the 06902 inbound proxy. That proxy also executes a client transaction, which 06903 in turn sends the request to a server transaction in the UAS. This is 06904 shown in Figure 4. 06905 06906 06907 A stateless proxy does not contain a client or server transaction. 06908 The transaction exists between the UA or stateful proxy on one side, 06909 and the UA or stateful proxy on the other side. As far as SIP 06910 transactions are concerned, stateless proxies are effectively 06911 transparent. The purpose of the client transaction is to receive a 06912 request from the element in which the client is embedded (call this 06913 element the "Transaction User" or TU; it can be a UA or a stateful 06914 proxy), and reliably deliver the request to a server transaction. The 06915 client transaction is also responsible for receiving responses and 06916 delivering them to the TU, filtering out any response retransmissions 06917 or disallowed responses (such as a response to ACK). Additionally, in 06918 the case of an INVITE request, the client transaction is responsible 06919 for generating the ACK request for any final response excepting a 2xx 06920 response. 06921 06922 Similarly, the purpose of the server transaction is to receive 06923 requests from the transport layer and deliver them to the TU. The 06924 server transaction filters any request retransmissions from the 06925 network. The server transaction accepts responses from the TU and 06926 delivers them to the transport layer for transmission over the 06927 network. In the case of an INVITE transaction, it absorbs the ACK 06928 request for any final response excepting a 2xx response. 06929 06930 The 2xx response and its ACK receive special treatment. This response 06931 is retransmitted only by a UAS, and its ACK generated only by the 06932 UAC. This end-to-end treatment is needed so that a caller knows the 06933 06934 06935 06936 J. Rosenberg et. al. [Page 119] 06937 Internet Draft SIP February 18, 2002 06938 06939 06940 06941 06942 06943 06944 +---------+ +---------+ +---------+ +---------+ 06945 | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | 06946 | |C||------->||S| |C||------->||S| |C||------->||S| | 06947 | |l|| ||e| |l|| ||e| |l|| ||e| | 06948 | |i|| ||r| |i|| ||r| |i|| ||r| | 06949 | |e|| ||v| |e|| ||v| |e|| ||v| | 06950 | |n|| ||e| |n|| ||e| |n|| ||e| | 06951 | |t|| ||r| |t|| ||r| |t|| ||r| | 06952 | | || || | | || || | | || || | | 06953 | |T|| ||T| |T|| ||T| |T|| ||T| | 06954 | |r|| ||r| |r|| ||r| |r|| ||r| | 06955 | |a|| ||a| |a|| ||a| |a|| ||a| | 06956 | |n|| ||n| |n|| ||n| |n|| ||n| | 06957 | |s||Response||s| |s||Response||s| |s||Response||s| | 06958 | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | 06959 +---------+ +---------+ +---------+ +---------+ 06960 UAC Outbound Inbound UAS 06961 Proxy Proxy 06962 06963 06964 06965 06966 06967 06968 06969 06970 Figure 4: Transaction relationships 06971 06972 06973 entire set of users that have accepted the call. Because of this 06974 special handling, retransmissions of the 2xx response are handled by 06975 the UA core, not the transaction layer. Similarly, generation of the 06976 ACK for the 2xx is handled by the UA core. Each proxy along the path 06977 merely forwards each 2xx response to INVITE and its corresponding 06978 ACK. 06979 06980 17.1 Client Transaction 06981 06982 The client transaction provides its functionality through the 06983 maintenance of a state machine. 06984 06985 The TU communicates with the client transaction through a simple 06986 interface. When the TU wishes to initiate a new transaction, it 06987 creates a client transaction and passes it the SIP request to send 06988 and an IP address, port, and transport to which to send it. The 06989 06990 06991 06992 J. Rosenberg et. al. [Page 120] 06993 Internet Draft SIP February 18, 2002 06994 06995 06996 client transaction begins execution of its state machine. Valid 06997 responses are passed up to the TU from the client transaction. 06998 06999 There are two types of client transaction state machines, depending 07000 on the method of the request passed by the TU. One handles client 07001 transactions for INVITE requests. This type of machine is referred to 07002 as an INVITE client transaction. Another type handles client 07003 transactions for all requests except INVITE and ACK. This is referred 07004 to as a non-INVITE client transaction. There is no client transaction 07005 for ACK. If the TU wishes to send an ACK, it passes one directly to 07006 the transport layer for transmission. 07007 07008 The INVITE transaction is different from those of other methods 07009 because of its extended duration. Normally, human input is required 07010 in order to respond to an INVITE. The long delays expected for 07011 sending a response argue for a three-way handshake. On the other 07012 hand, requests of other methods are expected to complete rapidly. 07013 Because of the non-INVITE transaction's reliance on a two-way 07014 handshake, TUs SHOULD respond immediately to non-INVITE requests. 07015 07016 17.1.1 INVITE Client Transaction 07017 07018 17.1.1.1 Overview of INVITE Transaction 07019 07020 The INVITE transaction consists of a three-way handshake. The client 07021 transaction sends an INVITE, the server transaction sends responses, 07022 and the client transaction sends an ACK. For unreliable transports 07023 (such as UDP), the client transaction retransmits requests at an 07024 interval that starts at T1 seconds and doubles after every 07025 retransmission. T1 is an estimate of the round-trip time (RTT), and 07026 it defaults to 500 ms. Nearly all of the transaction timers described 07027 here scale with T1, and changing T1 adjusts their values. The request 07028 is not retransmitted over reliable transports. After receiving a 1xx 07029 response, any retransmissions cease altogether, and the client waits 07030 for further responses. The server transaction can send additional 1xx 07031 responses, which are not transmitted reliably by the server 07032 transaction. Eventually, the server transaction decides to send a 07033 final response. For unreliable transports, that response is 07034 retransmitted periodically, and for reliable transports, it is sent 07035 once. For each final response that is received at the client 07036 transaction, the client transaction sends an ACK, the purpose of 07037 which is to quench retransmissions of the response. 07038 07039 17.1.1.2 Formal Description 07040 07041 07042 The state machine for the INVITE client transaction is shown in 07043 Figure 5. The initial state, "calling", MUST be entered when the TU 07044 07045 07046 07047 J. Rosenberg et. al. [Page 121] 07048 Internet Draft SIP February 18, 2002 07049 07050 07051 initiates a new client transaction with an INVITE request. The client 07052 transaction MUST pass the request to the transport layer for 07053 transmission (see Section 18). If an unreliable transport is being 07054 used, the client transaction MUST start timer A with a value of T1. 07055 If a reliable transport is being used, the client transaction SHOULD 07056 NOT start timer A (Timer A controls request retransmissions). For any 07057 transport, the client transaction MUST start timer B with a value of 07058 64*T1 seconds (Timer B controls transaction timeouts). 07059 07060 When timer A fires, the client transaction MUST retransmit the 07061 request by passing it to the transport layer, and MUST reset the 07062 timer with a value of 2*T1. The formal definition of retransmit 07063 within the context of the transaction layer is to take the message 07064 previously sent to the transport layer and pass it to the transport 07065 layer once more. 07066 07067 When timer A fires 2*T1 seconds later, the request MUST be 07068 retransmitted again (assuming the client transaction is still in this 07069 state). This process MUST continue so that the request is 07070 retransmitted with intervals that double after each transmission. 07071 These retransmissions SHOULD only be done while the client 07072 transaction is in the "calling" state. 07073 07074 The default value for T1 is 500 ms. T1 is an estimate of the RTT 07075 between the client and server transactions. Elements MAY (though it 07076 is NOT RECOMMENDED) use smaller values of T1 within closed, private 07077 networks that do not permit general Internet connection. T1 MAY be 07078 chosen larger, and this is RECOMMENDED if it is known in advance 07079 (such as on high latency access links) that the RTT is larger. 07080 Whatever the value of T1, the exponential backoffs on retransmissions 07081 described in this section MUST be used. 07082 07083 If the client transaction is still in the "calling" state when timer 07084 B fires, the client transaction SHOULD inform the TU that a timeout 07085 has occurred. The client transaction MUST NOT generate an ACK. The 07086 value of 64*T1 is equal to the amount of time required to send seven 07087 requests in the case of an unreliable transport. 07088 07089 If the client transaction receives a provisional response while in 07090 the "Calling" state, it transitions to the "proceeding" state. In the 07091 "proceeding" state, the client transaction SHOULD NOT retransmit the 07092 request any longer. Furthermore, the provisional response MUST be 07093 passed to the TU. Any further provisional responses MUST be passed up 07094 to the TU while in the "proceeding" state. 07095 07096 When in either the "Calling" or "Proceeding" states, reception of a 07097 response with status code from 300-699 MUST cause the client 07098 transaction to transition to "Completed". The client transaction MUST 07099 07100 07101 07102 J. Rosenberg et. al. [Page 122] 07103 Internet Draft SIP February 18, 2002 07104 07105 07106 07107 07108 07109 |INVITE from TU 07110 Timer A fires |INVITE sent 07111 Reset A, V Timer B fires 07112 INVITE sent +-----------+ or Transport Err. 07113 +---------| |---------------+inform TU 07114 | | Calling | | 07115 +-------->| |-------------->| 07116 +-----------+ 2xx | 07117 | | 2xx to TU | 07118 | |1xx | 07119 300-699 +---------------+ |1xx to TU | 07120 ACK sent | | | 07121 resp. to TU | 1xx V | 07122 | 1xx to TU -----------+ | 07123 | +---------| | | 07124 | | |Proceeding |-------------->| 07125 | +-------->| | 2xx | 07126 | +-----------+ 2xx to TU | 07127 | 300-699 | | 07128 | ACK sent, | | 07129 | resp. to TU| | 07130 | | | NOTE: 07131 | 300-699 V | 07132 | ACK sent +-----------+Transport Err. | transitions 07133 | +---------| |Inform TU | labeled with 07134 | | | Completed |-------------->| the event 07135 | +-------->| | | over the action 07136 | +-----------+ | to take 07137 | ^ | | 07138 | | | Timer D fires | 07139 +--------------+ | - | 07140 | | 07141 V | 07142 +-----------+ | 07143 | | | 07144 | Terminated|<--------------+ 07145 | | 07146 +-----------+ 07147 07148 07149 07150 07151 07152 07153 07154 07155 07156 07157 07158 07159 07160 07161 07162 07163 Figure 5: INVITE client transaction 07164 07165 J. Rosenberg et. al. [Page 123] 07166 Internet Draft SIP February 18, 2002 07167 07168 07169 pass the received response up to the TU, and the client transaction 07170 MUST generate an ACK request, even if the transport is reliable 07171 (guidelines for constructing the ACK from the response are given in 07172 Section 17.1.1.3) and then pass the ACK to the transport layer for 07173 transmission. The ACK MUST be sent to the same address, port, and 07174 transport to which the original request was sent. The client 07175 transaction SHOULD start timer D when it enters the "Completed" 07176 state, with a value of at least 32 seconds for unreliable transports, 07177 and a value of zero seconds for reliable transports. Timer D reflects 07178 the amount of time that the server transaction can remain in the 07179 "Completed" state when unreliable transports are used. This is equal 07180 to Timer H in the INVITE server transaction, whose default is 64*T1. 07181 However, the client transaction does not know the value of T1 in use 07182 by the server transaction, so an absolute minimum of 32s is used 07183 instead of basing Timer D on T1. 07184 07185 Any retransmissions of the final response that are received while in 07186 the "Completed" state MUST cause the ACK to be re-passed to the 07187 transport layer for retransmission, but the newly received response 07188 MUST NOT be passed up to the TU. A retransmission of the response is 07189 defined as any response which would match the same client transaction 07190 based on the rules of Section 17.1.3. 07191 07192 If timer D fires while the client transaction is in the "Completed" 07193 state, the client transaction MUST move to the terminated state, and 07194 it MUST inform the TU of the timeout. 07195 07196 When in either the "Calling" or "Proceeding" states, reception of a 07197 2xx response MUST cause the client transaction to enter the 07198 "Terminated" state, and the response MUST be passed up to the TU. The 07199 handling of this response depends on whether the TU is a proxy core 07200 or a UAC core. A UAC core will handle generation of the ACK for this 07201 response, while a proxy core will always forward the 200 (OK) 07202 upstream. The differing treatment of 200 (OK) between proxy and UAC 07203 is the reason that handling of it does not take place in the 07204 transaction layer. 07205 07206 The client transaction MUST be destroyed the instant it enters the 07207 "Terminated" state. This is actually necessary to guarantee correct 07208 operation. The reason is that 2xx responses to an INVITE are treated 07209 differently; each one is forwarded by proxies, and the ACK handling 07210 in a UAC is different. Thus, each 2xx needs to be passed to a proxy 07211 core (so that it can be forwarded) and to a UAC core (so it can be 07212 acknowledged). No transaction layer processing takes place. Whenever 07213 a response is received by the transport, if the transport layer finds 07214 no matching client transaction (using the rules of Section 17.1.3), 07215 the response is passed directly to the core. Since the matching 07216 client transaction is destroyed by the first 2xx, subsequent 2xx will 07217 07218 07219 07220 J. Rosenberg et. al. [Page 124] 07221 Internet Draft SIP February 18, 2002 07222 07223 07224 find no match and therefore be passed to the core. 07225 07226 17.1.1.3 Construction of the ACK Request 07227 07228 This section specifies the construction of ACK requests sent within 07229 the client transaction. A UAC core that generates an ACK for 2xx MUST 07230 instead follow the rules described in Section 13. 07231 07232 The ACK request constructed by the client transaction MUST contain 07233 values for the Call-ID, From, and Request-URI that are equal to the 07234 values of those header fields in the request passed to the transport 07235 by the client transaction (call this the "original request"). The To 07236 header field in the ACK MUST equal the To header field in the 07237 response being acknowledged, and therefore will usually differ from 07238 the To header field in the original request by the addition of the 07239 tag parameter. The ACK MUST contain a single Via header field, and 07240 this MUST be equal to the top Via header field of the original 07241 request. The CSeq header field in the ACK MUST contain the same value 07242 for the sequence number as was present in the original request, but 07243 the method parameter MUST be equal to "ACK". 07244 07245 If the INVITE request whose response is being acknowledged had Route 07246 header fields, those header fields MUST appear in the ACK. This is 07247 to ensure that the ACK can be routed properly through any downstream 07248 stateless proxies. 07249 07250 Although any request MAY contain a body, a body in an ACK is special 07251 since the request cannot be rejected if the body is not understood. 07252 Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, 07253 but if done, the body types are restricted to any that appeared in 07254 the INVITE, assuming that the response to the INVITE was not 415. If 07255 it was, the body in the ACK MAY be any type listed in the Accept 07256 header field in the 415. 07257 07258 For example, consider the following request: 07259 07260 07261 INVITE sip:bob@biloxi.com SIP/2.0 07262 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff 07263 To: Bob 07264 From: Alice ;tag=88sja8x 07265 Max-Forwards: 70 07266 Call-ID: 987asjd97y7atg 07267 CSeq: 986759 INVITE 07268 07269 07270 07271 The ACK request for a non-2xx final response to this request would 07272 07273 07274 07275 J. Rosenberg et. al. [Page 125] 07276 Internet Draft SIP February 18, 2002 07277 07278 07279 look like this: 07280 07281 07282 ACK sip:bob@biloxi.com SIP/2.0 07283 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff 07284 To: Bob ;tag=99sa0xk 07285 From: Alice ;tag=88sja8x 07286 Max-Forwards: 70 07287 Call-ID: 987asjd97y7atg 07288 CSeq: 986759 ACK 07289 07290 07291 07292 17.1.2 Non-INVITE Client Transaction 07293 07294 17.1.2.1 Overview of the non-INVITE Transaction 07295 07296 Non-INVITE transactions do not make use of ACK. They are simple 07297 request-response interactions. For unreliable transports, requests 07298 are retransmitted at an interval which starts at T1 and doubles until 07299 it hits T2. If a provisional response is received, retransmissions 07300 continue for unreliable transports, but at an interval of T2. The 07301 server transaction retransmits the last response it sent, which can 07302 be a provisional or final response, only when a retransmission of the 07303 request is received. This is why request retransmissions need to 07304 continue even after a provisional response, they are to ensure 07305 reliable delivery of the final response. 07306 07307 Unlike an INVITE transaction, a non-INVITE transaction has no special 07308 handling for the 2xx response. The result is that only a single 2xx 07309 response to a non-INVITE is ever delivered to a UAC. 07310 07311 17.1.2.2 Formal Description 07312 07313 07314 The state machine for the non-INVITE client transaction is shown in 07315 Figure 6. It is very similar to the state machine for INVITE. 07316 07317 The "Trying" state is entered when the TU initiates a new client 07318 transaction with a request. When entering this state, the client 07319 transaction SHOULD set timer F to fire in 64*T1 seconds. The request 07320 MUST be passed to the transport layer for transmission. If an 07321 unreliable transport is in use, the client transaction MUST set timer 07322 E to fire in T1 seconds. If timer E fires while still in this state, 07323 the timer is reset, but this time with a value of MIN(2*T1, T2). When 07324 the timer fires again, it is reset to a MIN(4*T1, T2). This process 07325 continues so that retransmissions occur with an exponentially 07326 increasing interval that caps at T2. The default value of T2 is 4s, 07327 07328 07329 07330 J. Rosenberg et. al. [Page 126] 07331 Internet Draft SIP February 18, 2002 07332 07333 07334 and it represents the amount of time a non-INVITE server transaction 07335 will take to respond to a request, if it does not respond 07336 immediately. For the default values of T1 and T2, this results in 07337 intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. 07338 07339 If Timer F fires while the client transaction is still in the 07340 "Trying" state, the client transaction SHOULD inform the TU about the 07341 timeout, and then it SHOULD enter the "Terminated" state. If a 07342 provisional response is received while in the "Trying" state, the 07343 response MUST be passed to the TU, and then the client transaction 07344 SHOULD move to the "Proceeding" state. If a final response (status 07345 codes 200-699) is received while in the "Trying" state, the response 07346 MUST be passed to the TU, and the client transaction MUST transition 07347 to the "Completed" state. 07348 07349 If Timer E fires while in the "Proceeding" state, the request MUST be 07350 passed to the transport layer for retransmission, and Timer E MUST be 07351 reset with a value of T2 seconds. If timer F fires while in the 07352 "Proceeding" state, the TU MUST be informed of a timeout, and the 07353 client transaction MUST transition to the terminated state. If a 07354 final response (status codes 200-699) is received while in the 07355 "Proceeding" state, the response MUST be passed to the TU, and the 07356 client transaction MUST transition to the "Completed" state. 07357 07358 Once the client transaction enters the "Completed" state, it MUST set 07359 Timer K to fire in T4 seconds for unreliable transports, and zero 07360 seconds for reliable transports. The "Completed" state exists to 07361 buffer any additional response retransmissions that may be received 07362 (which is why the client transaction remains there only for 07363 unreliable transports). T4 represents the amount of time the network 07364 will take to clear messages between client and server transactions. 07365 The default value of T4 is 5s. A response is a retransmission when it 07366 matches the same transaction, using the rules specified in Section 07367 17.1.3. If Timer K fires while in this state, the client transaction 07368 MUST transition to the "Terminated" state. 07369 07370 Once the transaction is in the terminated state, it MUST be 07371 destroyed. 07372 07373 17.1.3 Matching Responses to Client Transactions 07374 07375 When the transport layer in the client receives a response, it has to 07376 determine which client transaction will handle the response, so that 07377 the processing of Sections 17.1.1 and 17.1.2 can take place. The 07378 branch parameter in the top Via header field is used for this 07379 purpose. A response matches a client transaction under two 07380 conditions: 07381 07382 07383 07384 07385 J. Rosenberg et. al. [Page 127] 07386 Internet Draft SIP February 18, 2002 07387 07388 07389 07390 07391 07392 |Request from TU 07393 |send request 07394 Timer E V 07395 send request +-----------+ 07396 +---------| |-------------------+ 07397 | | Trying | Timer F | 07398 +-------->| | or Transport Err.| 07399 +-----------+ inform TU | 07400 200-699 | | | 07401 resp. to TU | |1xx | 07402 +---------------+ |resp. to TU | 07403 | | | 07404 | Timer E V Timer F | 07405 | send req +-----------+ or Transport Err. | 07406 | +---------| | inform TU | 07407 | | |Proceeding |------------------>| 07408 | +-------->| |-----+ | 07409 | +-----------+ |1xx | 07410 | | ^ |resp to TU | 07411 | 200-699 | +--------+ | 07412 | resp. to TU | | 07413 | | | 07414 | V | 07415 | +-----------+ | 07416 | | | | 07417 | | Completed | | 07418 | | | | 07419 | +-----------+ | 07420 | ^ | | 07421 | | | Timer K | 07422 +--------------+ | - | 07423 | | 07424 V | 07425 NOTE: +-----------+ | 07426 | | | 07427 transitions | Terminated|<------------------+ 07428 labeled with | | 07429 the event +-----------+ 07430 over the action 07431 to take 07432 07433 07434 07435 07436 07437 07438 07439 07440 07441 07442 07443 07444 Figure 6: non-INVITE client transaction 07445 07446 J. Rosenberg et. al. [Page 128] 07447 Internet Draft SIP February 18, 2002 07448 07449 07450 1. If the response has the same value of the branch parameter 07451 in the top Via header field as the branch parameter in the 07452 top Via header field of the request that created the 07453 transaction. 07454 07455 2. If the method parameter in the CSeq header field matches 07456 the method of the request that created the transaction. The 07457 method is needed since a CANCEL request constitutes a 07458 different transaction, but shares the same value of the 07459 branch parameter. 07460 07461 A response that matches a transaction matched by a previous response 07462 is considered a retransmission of that response. 07463 07464 If a request is sent via multicast, it is possible that it will 07465 generate multiple responses from different servers. These responses 07466 will all have the same branch parameter in the topmost Via, but vary 07467 in the To tag. The first response received, based on the rules above, 07468 will be used, and others will be viewed as retransmissions. That is 07469 not an error; multicast SIP provides only a rudimentary "single-hop- 07470 discovery-like" service that is limited to processing a single 07471 response. See Section 18.1.1 for details. 07472 07473 17.1.4 Handling Transport Errors 07474 07475 When the client transaction sends a request to the transport layer to 07476 be sent, the following procedures are followed if the transport layer 07477 indicates a failure. 07478 07479 The client transaction SHOULD inform the TU that a transport failure 07480 has occurred, and the client transaction SHOULD transition directly 07481 to the "Terminated" state. The TU will handle the failover 07482 mechanisms described in [4]. 07483 07484 17.2 Server Transaction 07485 07486 The server transaction is responsible for the delivery of requests to 07487 the TU and the reliable transmission of responses. It accomplishes 07488 this through a state machine. Server transactions are created by the 07489 core when a request is received, and transaction handling is desired 07490 for that request (this is not always the case). 07491 07492 As with the client transactions, the state machine depends on whether 07493 the received request is an INVITE request. 07494 07495 17.2.1 INVITE Server Transaction 07496 07497 07498 07499 07500 07501 J. Rosenberg et. al. [Page 129] 07502 Internet Draft SIP February 18, 2002 07503 07504 07505 The state diagram for the INVITE server transaction is shown in 07506 Figure 7. 07507 07508 When a server transaction is constructed with a request, it enters 07509 the "Proceeding" state. The server transaction MUST generate a 100 07510 (Trying) response unless it knows that the TU will generate a 07511 provisional or final response within 200 ms, in which case it MAY 07512 generate a 100 (Trying) response. This provisional response is needed 07513 to quench request retransmissions rapidly in order to avoid network 07514 congestion. The 100 (Trying) response is constructed according to the 07515 procedures in Section 8.2.6, except that the insertion of tags in the 07516 To header field of the response (when none was present in the 07517 request) is downgraded from MAY to SHOULD NOT. The request MUST be 07518 passed to the TU. 07519 07520 The TU passes any number of provisional responses to the server 07521 transaction. So long as the server transaction is in the "Proceeding" 07522 state, each of these MUST be passed to the transport layer for 07523 transmission. They are not sent reliably by the transaction layer 07524 (they are not retransmitted by it) and do not cause a change in the 07525 state of the server transaction. If a request retransmission is 07526 received while in the "Proceeding" state, the most recent provisional 07527 response that was received from the TU MUST be passed to the 07528 transport layer for retransmission. A request is a retransmission if 07529 it matches the same server transaction based on the rules of Section 07530 17.2.3. 07531 07532 If, while in the "Proceeding" state, the TU passes a 2xx response to 07533 the server transaction, the server transaction MUST pass this 07534 response to the transport layer for transmission. It is not 07535 retransmitted by the server transaction; retransmissions of 2xx 07536 responses are handled by the TU. The server transaction MUST then 07537 transition to the "Terminated" state. 07538 07539 While in the "Proceeding" state, if the TU passes a response with 07540 status code from 300 to 699 to the server transaction, the response 07541 MUST be passed to the transport layer for transmission, and the state 07542 machine MUST enter the "Completed" state. For unreliable transports, 07543 timer G is set to fire in T1 seconds, and is not set to fire for 07544 reliable transports. 07545 07546 07547 This is a change from RFC 2543, where responses were always 07548 retransmitted, even over reliable transports. 07549 07550 When the "Completed" state is entered, timer H MUST be set to fire in 07551 64*T1 seconds for all transports. Timer H determines when the server 07552 transaction abandons retransmitting the response. Its value is chosen 07553 07554 07555 07556 J. Rosenberg et. al. [Page 130] 07557 Internet Draft SIP February 18, 2002 07558 07559 07560 07561 07562 07563 |INVITE 07564 |pass INV to TU 07565 INVITE V send 100 if TU won't in 200ms 07566 send response+-----------+ 07567 +--------| |--------+101-199 from TU 07568 | | Proceeding| |send response 07569 +------->| |<-------+ 07570 | | Transport Err. 07571 | | Inform TU 07572 | |--------------->+ 07573 +-----------+ | 07574 300-699 from TU | |2xx from TU | 07575 send response | |send response | 07576 | +------------------>+ 07577 | | 07578 INVITE V Timer G fires | 07579 send response+-----------+ send response | 07580 +--------| |--------+ | 07581 | | Completed | | | 07582 +------->| |<-------+ | 07583 +-----------+ | 07584 | | | 07585 ACK | | | 07586 - | +------------------>+ 07587 | Timer H fires | 07588 V or Transport Err.| 07589 +-----------+ Inform TU | 07590 | | | 07591 | Confirmed | | 07592 | | | 07593 +-----------+ | 07594 | | 07595 |Timer I fires | 07596 |- | 07597 | | 07598 V | 07599 +-----------+ | 07600 | | | 07601 | Terminated|<---------------+ 07602 | | 07603 +-----------+ 07604 07605 07606 07607 07608 07609 07610 07611 07612 07613 07614 07615 Figure 7: INVITE server transaction 07616 07617 J. Rosenberg et. al. [Page 131] 07618 Internet Draft SIP February 18, 2002 07619 07620 07621 to equal Timer B, the amount of time a client transaction will 07622 continue to retry sending a request. If timer G fires, the response 07623 is passed to the transport layer once more for retransmission, and 07624 timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when 07625 timer G fires, the response is passed to the transport again for 07626 transmission, and timer G is reset with a value that doubles, unless 07627 that value exceeds T2, in which case it is reset with the value of 07628 T2. This is identical to the retransmit behavior for requests in the 07629 "Trying" state of the non-INVITE client transaction. Furthermore, 07630 while in the "Completed" state, if a request retransmission is 07631 received, the server SHOULD pass the response to the transport for 07632 retransmission. 07633 07634 If an ACK is received while the server transaction is in the 07635 "Completed" state, the server transaction MUST transition to the 07636 "Confirmed" state. As Timer G is ignored in this state, any 07637 retransmissions of the response will cease. 07638 07639 If timer H fires while in the "Completed" state, it implies that the 07640 ACK was never received. In this case, the server transaction MUST 07641 transition to the "Terminated" state, and MUST indicate to the TU 07642 that a transaction failure has occurred. 07643 07644 The purpose of the "Confirmed" state is to absorb any additional ACK 07645 messages that arrive, triggered from retransmissions of the final 07646 response. When this state is entered, timer I is set to fire in T4 07647 seconds for unreliable transports, and zero seconds for reliable 07648 transports. Once timer I fires, the server MUST transition to the 07649 "Terminated" state. 07650 07651 Once the transaction is in the "Terminated" state, it MUST be 07652 destroyed. As with client transactions, this is needed to ensure 07653 reliability of the 2xx responses to INVITE. 07654 07655 17.2.2 Non-INVITE Server Transaction 07656 07657 07658 The state machine for the non-INVITE server transaction is shown in 07659 Figure 8. 07660 07661 The state machine is initialized in the "Trying" state and is passed 07662 a request other than INVITE or ACK when initialized. This request is 07663 passed up to the TU. Once in the "Trying" state, any further request 07664 retransmissions are discarded. A request is a retransmission if it 07665 matches the same server transaction, using the rules specified in 07666 Section 17.2.3. 07667 07668 While in the "Trying" state, if the TU passes a provisional response 07669 07670 07671 07672 J. Rosenberg et. al. [Page 132] 07673 Internet Draft SIP February 18, 2002 07674 07675 07676 to the server transaction, the server transaction MUST enter the 07677 "Proceeding" state. The response MUST be passed to the transport 07678 layer for transmission. Any further provisional responses that are 07679 received from the TU while in the "Proceeding" state MUST be passed 07680 to the transport layer for transmission. If a retransmission of the 07681 request is received while in the "Proceeding" state, the most 07682 recently sent provisional response MUST be passed to the transport 07683 layer for retransmission. If the TU passes a final response (status 07684 codes 200-699) to the server while in the "Proceeding" state, the 07685 transaction MUST enter the "Completed" state, and the response MUST 07686 be passed to the transport layer for transmission. 07687 07688 When the server transaction enters the "Completed" state, it MUST set 07689 Timer J to fire in 64*T1 seconds for unreliable transports, and zero 07690 seconds for reliable transports. While in the "Completed" state, the 07691 server transaction MUST pass the final response to the transport 07692 layer for retransmission whenever a retransmission of the request is 07693 received. Any other final responses passed by the TU to the server 07694 transaction MUST be discarded while in the "Completed" state. The 07695 server transaction remains in this state until Timer J fires, at 07696 which point it MUST transition to the "Terminated" state. 07697 07698 The server transaction MUST be destroyed the instant it enters the 07699 "Terminated" state. 07700 07701 17.2.3 Matching Requests to Server Transactions 07702 07703 When a request is received from the network by the server, it has to 07704 be matched to an existing transaction. This is accomplished in the 07705 following manner. 07706 07707 The branch parameter in the topmost Via header field of the request 07708 is examined. If it is present and begins with the magic cookie 07709 "z9hG4bK", the request was generated by a client transaction 07710 compliant to this specification. Therefore, the branch parameter will 07711 be unique across all transactions sent by that client. The request 07712 matches a transaction if the branch parameter in the request is equal 07713 to the one in the top Via header field of the request that created 07714 the transaction, the sent-by value in the top Via of the request is 07715 equal to the one in the request that created the transaction, and in 07716 the case of a CANCEL request, the method of the request that created 07717 the transaction was also CANCEL. This matching rule applies to both 07718 INVITE and non-INVITE transactions alike. 07719 07720 07721 The sent-by value is used as part of the matching process 07722 because there could be duplication of branch parameters 07723 from different clients; uniqueness in time is mandated for 07724 07725 07726 07727 J. Rosenberg et. al. [Page 133] 07728 Internet Draft SIP February 18, 2002 07729 07730 07731 07732 07733 07734 |Request received 07735 |pass to TU 07736 V 07737 +-----------+ 07738 | | 07739 | Trying |-------------+ 07740 | | | 07741 +-----------+ |200-699 from TU 07742 | |send response 07743 |1xx from TU | 07744 |send response | 07745 | | 07746 Request V 1xx from TU | 07747 send response+-----------+send response| 07748 +--------| |--------+ | 07749 | | Proceeding| | | 07750 +------->| |<-------+ | 07751 +<--------------| | | 07752 |Trnsprt Err +-----------+ | 07753 |Inform TU | | 07754 | | | 07755 | |200-699 from TU | 07756 | |send response | 07757 | Request V | 07758 | send response+-----------+ | 07759 | +--------| | | 07760 | | | Completed |<------------+ 07761 | +------->| | 07762 +<--------------| | 07763 |Trnsprt Err +-----------+ 07764 |Inform TU | 07765 | |Timer J fires 07766 | |- 07767 | | 07768 | V 07769 | +-----------+ 07770 | | | 07771 +-------------->| Terminated| 07772 | | 07773 +-----------+ 07774 07775 07776 07777 07778 07779 07780 07781 07782 07783 07784 07785 07786 Figure 8: non-INVITE server transaction 07787 07788 J. Rosenberg et. al. [Page 134] 07789 Internet Draft SIP February 18, 2002 07790 07791 07792 construction of the parameter, but not uniqueness in space. 07793 07794 If the branch parameter in the top Via header field is not present, 07795 or does not contain the magic cookie, the following procedures are 07796 used. These exist to handle backwards compatibility with RFC 2543 07797 compliant implementations. 07798 07799 The INVITE request matches a transaction if the Request-URI, To tag, 07800 From tag, Call-ID, CSeq, and top Via header field match those of the 07801 INVITE request which created the transaction. In this case, the 07802 INVITE is a retransmission of the original one that created the 07803 transaction. The ACK request matches a transaction if the Request- 07804 URI, From tag, Call-ID, CSeq number (not the method), and top Via 07805 header field match those of the INVITE request which created the 07806 transaction, and the To tag of the ACK matches the To tag of the 07807 response sent by the server transaction. Matching is done based on 07808 the matching rules defined for each of those header fields. The usage 07809 of the tag in the To header field helps disambiguate ACK for 2xx from 07810 ACK for other responses at a proxy, which may have forwarded both 07811 responses (which can occur in unusual conditions). An ACK request 07812 that matches an INVITE transaction matched by a previous ACK is 07813 considered a retransmission of that previous ACK. 07814 07815 For all other request methods, a request is matched to a transaction 07816 if the Request-URI, To tag, From tag, Call-ID Cseq (including the 07817 method), and top Via header field match those of the request that 07818 created the transaction. Matching is done based on the matching rules 07819 defined for each of those header fields. When a non-INVITE request 07820 matches an existing transaction, it is a retransmission of the 07821 request that created that transaction. 07822 07823 Because the matching rules include the Request-URI, the server cannot 07824 match a response to a transaction. When the TU passes a response to 07825 the server transaction, it must pass it to the specific server 07826 transaction for which the response is targeted. 07827 07828 17.2.4 Handling Transport Errors 07829 07830 When the server transaction sends a response to the transport layer 07831 to be sent, the following procedures are followed if the transport 07832 layer indicates a failure. 07833 07834 First, the procedures in [4] are followed, which attempt to deliver 07835 the response to a backup. If those should all fail, based on the 07836 definition of failure in [4], the server transaction SHOULD inform 07837 the TU that a failure has occurred, and SHOULD transition to the 07838 terminated state. 07839 07840 07841 07842 07843 J. Rosenberg et. al. [Page 135] 07844 Internet Draft SIP February 18, 2002 07845 07846 07847 18 Transport 07848 07849 The transport layer is responsible for the actual transmission of 07850 requests and responses over network transports. This includes 07851 determination of the connection to use for a request or response in 07852 the case of connection-oriented transports. 07853 07854 The transport layer is responsible for managing persistent 07855 connections for transport protocols like TCP and SCTP, or TLS over 07856 those, including ones opened to the transport layer. This includes 07857 connections opened by the client or server transports, so that 07858 connections are shared between client and server transport functions. 07859 These connections are indexed by the tuple formed from the address, 07860 port, and transport protocol at the far end of the connection. When 07861 a connection is opened by the transport layer, this index is set to 07862 the destination IP, port and transport. When the connection is 07863 accepted by the transport layer, this index is set to the source IP 07864 address, port number, and transport. Note that, because the source 07865 port is often ephemeral, but it cannot be known whether it is 07866 ephemeral or selected through procedures in [4], connections 07867 accepted by the transport layer will frequently not be reused. The 07868 result is that two proxies in a "peering" relationship using a 07869 connection-oriented transport frequently will have two connections in 07870 use, one for transactions initiated in each direction. 07871 07872 It is RECOMMENDED that connections be kept open for some 07873 implementation-defined duration after the last message was sent or 07874 received over that connection. This duration SHOULD at least equal 07875 the longest amount of time the element would need in order to bring a 07876 transaction from instantiation to the terminated state. This is to 07877 make it likely that transactions complete over the same connection on 07878 which they are initiated (for example, request, response, and in the 07879 case of INVITE, ACK for non-2xx responses). This usually means at 07880 least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, 07881 it could be larger in an element that has a TU using a large value 07882 for timer C (bullet 11 of Section 16.6), for example. 07883 07884 All SIP elements MUST implement UDP and TCP. SIP elements MAY 07885 implement other protocols. 07886 07887 07888 Making TCP mandatory for the UA is a substantial change 07889 from RFC 2543. It has arisen out of the need to handle 07890 larger messages, which MUST use TCP, as discussed below. 07891 Thus, even if an element never sends large messages, it may 07892 receive one and needs to be able to handle them. 07893 07894 18.1 Clients 07895 07896 07897 07898 J. Rosenberg et. al. [Page 136] 07899 Internet Draft SIP February 18, 2002 07900 07901 07902 18.1.1 Sending Requests 07903 07904 The client side of the transport layer is responsible for sending the 07905 request and receiving responses. The user of the transport layer 07906 passes the client transport the request, an IP address, port, 07907 transport, and possibly TTL for multicast destinations. 07908 07909 If a request is within 200 bytes of the path MTU, or if it is larger 07910 than 1300 bytes and the path MTU is unknown, the request MUST be sent 07911 using TCP. This prevents fragmentation of messages over UDP and 07912 provides congestion control for larger messages. However, 07913 implementations MUST be able to handle messages up to the maximum 07914 datagram packet size. For UDP, this size is 65,535 bytes, including 07915 IP and UDP headers. 07916 07917 07918 The 200 byte "buffer" between the message size and the MTU 07919 accommodates the fact that the response in SIP can be 07920 larger than the request. This happens due to the addition 07921 of Record-Route header field values to the responses to 07922 INVITE, for example. With the extra buffer, the response 07923 can be about 170 bytes larger than the request, and still 07924 not be fragmented on IPv4 (about 30 bytes is consumed by 07925 IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is 07926 not known, based on the assumption of a 1500 byte Ethernet 07927 MTU. 07928 07929 If an element sends a request over TCP because of these message size 07930 constraints, and that request would have otherwise been sent over 07931 UDP, if the attempt to establish the connection generates either an 07932 ICMP Protocol Not Supported, or results in a TCP reset, the element 07933 SHOULD retry the request, using UDP. This is only to provide 07934 backwards compatibility with RFC 2543 compliant implementations that 07935 do not support UDP. It is anticipated that this behavior will be 07936 deprecated in a future revision of this specification. 07937 07938 A client that sends a request to a multicast address MUST add the 07939 "maddr" parameter to its Via header field value containing the 07940 destination multicast address, and for IPv4, SHOULD add the "ttl" 07941 parameter with a value of 1. Usage of IPv6 multicast is not defined 07942 in this specification, and will be a subject of future 07943 standardization when the need arises. 07944 07945 These rules result in a purposeful limitation of multicast in SIP. 07946 Its primary function is to provide an "single-hop-discovery-like" 07947 service, delivering a request to a group of homogeneous servers, 07948 where it is only required to process the response from any one of 07949 them. This functionality is most useful for registrations. In fact, 07950 07951 07952 07953 J. Rosenberg et. al. [Page 137] 07954 Internet Draft SIP February 18, 2002 07955 07956 07957 based on the transaction processing rules in Section 17.1.3, the 07958 client transaction will accept the first response, and view any 07959 others as retransmissions because they all contain the same Via 07960 branch identifier. 07961 07962 Before a request is sent, the client transport MUST insert a value of 07963 the "sent-by" field into the Via header field. This field contains an 07964 IP address or host name, and port. The usage of an FQDN is 07965 RECOMMENDED. This field is used for sending responses under certain 07966 conditions, described below. If the port is absent, the default 07967 value depends on the transport. It is 5060 for UDP, TCP and SCTP, 07968 5061 for TLS. 07969 07970 For reliable transports, the response is normally sent on the 07971 connection on which the request was received. Therefore, the client 07972 transport MUST be prepared to receive the response on the same 07973 connection used to send the request. Under error conditions, the 07974 server may attempt to open a new connection to send the response. To 07975 handle this case, the transport layer MUST also be prepared to 07976 receive an incoming connection on the source IP address from which 07977 the request was sent and port number in the "sent-by" field. It also 07978 MUST be prepared to receive incoming connections on any address and 07979 port that would be selected by a server based on the procedures 07980 described in Section 5 of [4]. 07981 07982 For unreliable unicast transports, the client transport MUST be 07983 prepared to receive responses on the source IP address from which the 07984 request is sent (as responses are sent back to the source address) 07985 and the port number in the "sent-by" field. Furthermore, as with 07986 reliable transports, in certain cases the response will be sent 07987 elsewhere. The client MUST be prepared to receive responses on any 07988 address and port that would be selected by a server based on the 07989 procedures described in Section 5 of [4]. 07990 07991 For multicast, the client transport MUST be prepared to receive 07992 responses on the same multicast group and port to which the request 07993 is sent (that is, it needs to be a member of the multicast group it 07994 sent the request to.) 07995 07996 If a request is destined to an IP address, port, and transport to 07997 which an existing connection is open, it is RECOMMENDED that this 07998 connection be used to send the request, but another connection MAY be 07999 opened and used. 08000 08001 If a request is sent using multicast, it is sent to the group 08002 address, port, and TTL provided by the transport user. If a request 08003 is sent using unicast unreliable transports, it is sent to the IP 08004 address and port provided by the transport user. 08005 08006 08007 08008 J. Rosenberg et. al. [Page 138] 08009 Internet Draft SIP February 18, 2002 08010 08011 08012 18.1.2 Receiving Responses 08013 08014 When a response is received, the client transport examines the top 08015 Via header field value. If the value of the "sent-by" parameter in 08016 that header field value does not correspond to a value that the 08017 client transport is configured to insert into requests, the response 08018 MUST be silently discarded. 08019 08020 If there are any client transactions in existence, the client 08021 transport uses the matching procedures of Section 17.1.3 to attempt 08022 to match the response to an existing transaction. If there is a 08023 match, the response MUST be passed to that transaction. Otherwise, 08024 the response MUST be passed to the core (whether it be stateless 08025 proxy, stateful proxy, or UA) for further processing. Handling of 08026 these "stray" responses is dependent on the core (a proxy will 08027 forward them, while a UA will discard, for example). 08028 08029 18.2 Servers 08030 08031 18.2.1 Receiving Requests 08032 08033 A server SHOULD be prepared to received requests on any IP address, 08034 port and transport combination that can be the result of a DNS lookup 08035 on a SIP or SIPS URI [4] that is handed out for the purposes of 08036 communicating with that server. In this context, "handing out" 08037 includes placing a URI in a Contact header field in a REGISTER 08038 request or a any redirect response, or in a Record-Route header field 08039 in a request or response. A URI can also be "handed out" by placing 08040 it on a web page or business card. It is also RECOMMENDED that a 08041 server listen for requests on the default SIP ports on all public 08042 interfaces. The typical exception would be private networks, or when 08043 multiple server instances are running on the same host. For any port 08044 and interface that a server listens on for UDP, it MUST listen on 08045 that same port and interface for TCP. This is because a message may 08046 need to be sent using TCP, rather than UDP, if it is too large. As a 08047 result, the converse is not true. A server need not, and indeed 08048 SHOULD NOT listen for UDP on a particular address and port just 08049 because it is listening on that same address and port for UDP. There 08050 may, of course, be other reasons why a server needs to listen for UDP 08051 on a particular address and port. 08052 08053 When the server transport receives a request over any transport, it 08054 MUST examine the value of the "sent-by" parameter in the top Via 08055 header field value. If the host portion of the "sent-by" parameter 08056 contains a domain name, or if it contains an IP address that differs 08057 from the packet source address, the server MUST add a "received" 08058 parameter to that Via header field value. This parameter MUST contain 08059 the source address from which the packet was received. This is to 08060 08061 08062 08063 J. Rosenberg et. al. [Page 139] 08064 Internet Draft SIP February 18, 2002 08065 08066 08067 assist the server transport layer in sending the response, since it 08068 must be sent to the source IP address from which the request came. 08069 08070 Consider a request received by the server transport which looks like, 08071 in part: 08072 08073 08074 INVITE sip:bob@Biloxi.com SIP/2.0 08075 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 08076 08077 08078 08079 The request is received with a source IP address of 1.2.3.4. Before 08080 passing the request up, the transport adds a "received" parameter, so 08081 that the request would look like, in part: 08082 08083 08084 INVITE sip:bob@Biloxi.com SIP/2.0 08085 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=1.2.3.4 08086 08087 08088 08089 Next, the server transport attempts to match the request to a server 08090 transaction. It does so using the matching rules described in Section 08091 17.2.3. If a matching server transaction is found, the request is 08092 passed to that transaction for processing. If no match is found, the 08093 request is passed to the core, which may decide to construct a new 08094 server transaction for that request. Note that when a UAS core sends 08095 a 2xx response to INVITE, the server transaction is destroyed. This 08096 means that when the ACK arrives, there will be no matching server 08097 transaction, and based on this rule, the ACK is passed to the UAS 08098 core, where it is processed. 08099 08100 18.2.2 Sending Responses 08101 08102 The server transport uses the value of the top Via header field in 08103 order to determine where to send a response. It MUST follow the 08104 following process: 08105 08106 o If the "sent-protocol" is a reliable transport protocol such 08107 as TCP or SCTP, or TLS over those, the response MUST be sent 08108 using the existing connection to the source of the original 08109 request that created the transaction, if that connection is 08110 still open. This requires the server transport to maintain an 08111 association between server transactions and transport 08112 connections. If that connection is no longer open, the server 08113 SHOULD open a connection to the IP address in the "received" 08114 parameter, if present, using the port in the "sent-by" value, 08115 08116 08117 08118 J. Rosenberg et. al. [Page 140] 08119 Internet Draft SIP February 18, 2002 08120 08121 08122 or the default port for that transport, if no port is 08123 specified. If that connection attempt fails, the server 08124 SHOULD use the procedures in [4] for servers in order to 08125 determine the IP address and port to open the connection and 08126 send the response to. 08127 08128 o Otherwise, if the Via header field value contains a "maddr" 08129 parameter, the response MUST be forwarded to the address 08130 listed there, using the port indicated in "sent-by", or port 08131 5060 if none is present. If the address is a multicast 08132 address, the response SHOULD be sent using the TTL indicated 08133 in the "ttl" parameter, or with a TTL of 1 if that parameter 08134 is not present. 08135 08136 o Otherwise (for unreliable unicast transports), if the top Via 08137 has a "received" parameter, the response MUST be sent to the 08138 address in the "received" parameter, using the port indicated 08139 in the "sent-by" value, or using port 5060 if none is 08140 specified explicitly. If this fails, for example, elicits an 08141 ICMP "port unreachable" response, the procedures of Section 5 08142 of [4] SHOULD be used to determine where to send the response. 08143 08144 o Otherwise, if it is not receiver-tagged, the response MUST be 08145 sent to the address indicated by the "sent-by" value, using 08146 the procedures in Section 5 of [4]. 08147 08148 18.3 Framing 08149 08150 In the case of message-oriented transports (such as UDP), if the 08151 message has a Content-Length header field, the message body is 08152 assumed to contain that many bytes. If there are additional bytes in 08153 the transport packet beyond the end of the body, they MUST be 08154 discarded. If the transport packet ends before the end of the message 08155 body, this is considered an error. If the message is a response, it 08156 MUST be discarded. If its a request, the element SHOULD generate a 08157 400 (Bad Request) response. If the message has no Content-Length 08158 header field, the message body is assumed to end at the end of the 08159 transport packet. 08160 08161 In the case of stream-oriented transports such as TCP, the Content- 08162 Length header field indicates the size of the body. The Content- 08163 Length header field MUST be used with stream oriented transports. 08164 08165 18.4 Error Handling 08166 08167 Error handling is independent of whether the message was a request or 08168 response. 08169 08170 08171 08172 08173 J. Rosenberg et. al. [Page 141] 08174 Internet Draft SIP February 18, 2002 08175 08176 08177 If the transport user asks for a message to be sent over an 08178 unreliable transport, and the result is an ICMP error, the behavior 08179 depends on the type of ICMP error. Host, network, port or protocol 08180 unreachable errors, or parameter problem errors SHOULD cause the 08181 transport layer to inform the transport user of a failure in sending. 08182 Source quench and TTL exceeded ICMP errors SHOULD be ignored. 08183 08184 If the transport user asks for a request to be sent over a reliable 08185 transport, and the result is a connection failure, the transport 08186 layer SHOULD inform the transport user of a failure in sending. 08187 08188 19 Common Message Components 08189 08190 There are certain components of SIP messages that appear in various 08191 places within SIP messages (and sometimes, outside of them) that 08192 merit separate discussion. 08193 08194 19.1 SIP and SIPS Uniform Resource Indicators 08195 08196 A SIP or SIPS URI identifies a communications resource. Like all 08197 URIs, SIP and SIPS URIs may be placed in web pages, email messages, 08198 or printed literature. They contain sufficient information to 08199 initiate and maintain a communication session with the resource. 08200 08201 Examples of communications resources include the following: 08202 08203 o a user of an online service 08204 08205 o an appearance on a multi-line phone 08206 08207 o a mailbox on a messaging system 08208 08209 o a PSTN number at a gateway service 08210 08211 o a group (such as "sales" or "helpdesk") in an organization 08212 08213 A SIPS URI specifies that the resource be contacted securely. This 08214 means, in particular, that TLS is to be used between all elements, 08215 starting from the UAC, and ending at the UAS. Any resource described 08216 by a SIP URI can be "upgraded" to a SIPS URI by just changing the 08217 scheme, if it is desired to communicate with that resource securely. 08218 08219 19.1.1 SIP and SIPS URI Components 08220 08221 The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. 08222 They use a form similar to the mailto URL, allowing the specification 08223 of SIP request-header fields and the SIP message-body. This makes it 08224 possible to specify the subject, media type, or urgency of sessions 08225 08226 08227 08228 J. Rosenberg et. al. [Page 142] 08229 Internet Draft SIP February 18, 2002 08230 08231 08232 initiated by using a URI on a web page or in an email message. The 08233 formal syntax for a SIP or SIPS URI is presented in Section 25. Its 08234 general form, in the case of a SIP URI, is 08235 sip:user:password@host:port;uri-parameters?headers 08236 is "sips" instead of sip. These tokens, and some of the tokens in 08237 their expansions, have the following meanings: 08238 08239 user: The identifier of a particular resource at the host being 08240 addressed. The term "host" in this context frequently 08241 refers to a domain. The "userinfo" of a URI consists of 08242 this user field, the password field, and the @ sign 08243 following them. The userinfo part of a URI is optional and 08244 MAY be absent when the destination host does not have a 08245 notion of users or when the host itself is the resource 08246 being identified. If the @ sign is present in a SIP or SIPS 08247 URI, the user field MUST NOT be empty. 08248 08249 If the host being addressed can process telephone numbers, 08250 for instance, an Internet telephony gateway, a telephone- 08251 subscriber field defined in RFC 2806 [9] MAY be used to 08252 populate the user field. There are special escaping rules 08253 for encoding telephone-subscriber fields in SIP and SIPS 08254 URIs described in Section 19.1.2. 08255 08256 password: A password associated with the user. While the SIP 08257 and SIPS URI syntax allows this field to be present, its 08258 use is NOT RECOMMENDED, because the passing of 08259 authentication information in clear text (such as URIs) has 08260 proven to be a security risk in almost every case where it 08261 has been used. For instance, transporting a PIN number in 08262 this field exposes the PIN. 08263 08264 Note that the password field is just an extension of user 08265 portion. Implementations not wishing to give special 08266 significance to the password portion of the field MAY 08267 simply treat "user:password" as a single string. 08268 08269 host: The host providing the SIP resource. The host part 08270 contains either a fully-qualified domain name or numeric 08271 IPv4 or IPv6 address. Using the fully-qualified domain name 08272 form is RECOMMENDED whenever possible. 08273 08274 port: The port number where the request is to be sent. 08275 08276 URI parameters: Parameters affecting a request constructed from 08277 the URI. 08278 08279 URI parameters are added after the hostport component and 08280 08281 08282 08283 J. Rosenberg et. al. [Page 143] 08284 Internet Draft SIP February 18, 2002 08285 08286 08287 are separated by semi-colons. 08288 08289 URI parameters take the form: 08290 parameter-name "=" parameter-value 08291 Even though an arbitrary number of URI parameters may be 08292 included in a URI, any given parameter-name MUST NOT appear 08293 more than once. 08294 08295 This extensible mechanism includes the transport, maddr, 08296 ttl, user, method and lr parameters. 08297 08298 The transport parameter determines the transport mechanism 08299 to be used for sending SIP messages, as specified in [4]. 08300 SIP can use any network transport protocol. Parameter 08301 names are defined for UDP [14], TCP [15], and SCTP [16]. 08302 For a SIPS URI, the transport parameter MUST indicate a 08303 reliable transport. 08304 08305 The maddr parameter indicates the server address to be 08306 contacted for this user, overriding any address derived 08307 from the host field. When an maddr parameter is present, 08308 the port and transport components of the URI apply to the 08309 address indicated in the maddr parameter value. [4] 08310 describes the proper interpretation of the transport, 08311 maddr, and hostport in order to obtain the destination 08312 address, port, and transport for sending a request. 08313 08314 08315 The maddr field has been used as a simple form of 08316 loose source routing. It allows a URI to specify a 08317 proxy that must be traversed en-route to the 08318 destination. Continuing to use the maddr parameter 08319 this way is strongly discouraged (the mechanisms that 08320 enable it are deprecated). Implementations should 08321 instead use the Route mechanism described in this 08322 document, establishing a pre-existing route set if 08323 necessary (see Section 8.1.1.1). This provides a full 08324 URI to describe the node to be traversed. 08325 08326 The ttl parameter determines the time-to-live value of the 08327 UDP multicast packet and MUST only be used if maddr is a 08328 multicast address and the transport protocol is UDP. For 08329 example, to specify to call alice@atlanta.com using 08330 multicast to 239.255.255.1 with a ttl of 15, the following 08331 URI would be used: 08332 08333 08334 sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 08335 08336 08337 08338 J. Rosenberg et. al. [Page 144] 08339 Internet Draft SIP February 18, 2002 08340 08341 08342 The set of valid telephone-subscriber strings is a subset 08343 of valid user strings. The user URI parameter exists to 08344 distinguish telephone numbers from user names that happen 08345 to look like telephone numbers. If the user string 08346 contains a telephone number formatted as a telephone- 08347 subscriber, the user parameter value "phone" SHOULD be 08348 present. Even without this parameter, recipients of SIP and 08349 SIPS URIs MAY interpret the pre-@ part as a telephone 08350 number if local restrictions on the name space for user 08351 name allow it. 08352 08353 The method of the SIP request constructed from the URI can 08354 be specified with the method parameter. 08355 08356 The lr parameter, when present, indicates that the element 08357 responsible for this resource implements the routing 08358 mechanisms specified in this document. This parameter will 08359 be used in the URIs proxies place into Record-Route header 08360 field values, and may appear in the URIs in a pre-existing 08361 route set. 08362 08363 This parameter is used to achieve backwards 08364 compatibility with systems implementing the strict- 08365 routing mechanisms of RFC 2543 and the rfc2543bis 08366 drafts up to bis-05. An element preparing to send a 08367 request based on a URI not containing this parameter 08368 can assume the receiving element implements strict- 08369 routing and reformat the message to preserve the 08370 information in the Request-URI. 08371 08372 Since the uri-parameter mechanism is extensible, SIP 08373 elements MUST silently ignore any uri-parameters that they 08374 do not understand. 08375 08376 Headers: Header fields to be included in a request constructed 08377 from the URI. 08378 08379 Headers fields in the SIP request can be specified with the 08380 "?" mechanism within a URI. The header names and values are 08381 encoded in ampersand separated hname = hvalue pairs. The 08382 special hname "body" indicates that the associated hvalue 08383 is the message-body of the SIP request. 08384 08385 Table 1 summarizes the use of SIP and SIPS URI components based on 08386 the context in which the URI appears. The external column describes 08387 URIs appearing anywhere outside of a SIP message, for instance on a 08388 web page or business card. Entries marked "m" are mandatory, those 08389 marked "o" are optional, and those marked "-" are not allowed. 08390 08391 08392 08393 J. Rosenberg et. al. [Page 145] 08394 Internet Draft SIP February 18, 2002 08395 08396 08397 Elements processing URIs SHOULD ignore any disallowed components if 08398 they are present. The second column indicates the default value of an 08399 optional element if it is not present. "--" indicates that the 08400 element is either not optional, or has no default value. 08401 08402 URIs in Contact header fields have different restrictions depending 08403 on the context in which the header field appears. One set applies to 08404 messages that establish and maintain dialogs (INVITE and its 200 (OK) 08405 response). The other applies to registration and redirection messages 08406 (REGISTER, its 200 (OK) response, and 3xx class responses to any 08407 method). 08408 08409 08410 dialog 08411 reg./redir. Contact/ 08412 default Req.-URI To From Contact R-R/Route external 08413 user -- o o o o o o 08414 password -- o o o o o o 08415 host -- m m m m m m 08416 port (1) o - - o o o 08417 user-param ip o o o o o o 08418 method INVITE - - - - - o 08419 maddr-param -- o - - o o o 08420 ttl-param 1 o - - o - o 08421 transp.-param (2) o - - o o o 08422 lr-param -- o - - - o o 08423 other-param -- o o o o o o 08424 headers -- - - - o - o 08425 08426 08427 (1): The default port value is transport and scheme dependent. The 08428 default is 5060 for sip: using UDP, TCP, or SCTP. The default is 08429 5061 for sip: using TLS over TCP and sips: over TCP. 08430 08431 (2): The default transport is scheme dependent. For sip:, it is UDP. 08432 For sips:, it is TCP. 08433 08434 Table 1: Use and default values of URI components for SIP header 08435 field values, Request-URI and references 08436 08437 08438 19.1.2 Character Escaping Requirements 08439 08440 SIP follows the requirements and guidelines of RFC 2396 [5] when 08441 defining the set of characters that must be escaped in a SIP URI, and 08442 uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396: 08443 08444 08445 08446 08447 08448 J. Rosenberg et. al. [Page 146] 08449 Internet Draft SIP February 18, 2002 08450 08451 08452 The set of characters actually reserved within any given 08453 URI component is defined by that component. In general, a 08454 character is reserved if the semantics of the URI changes 08455 if the character is replaced with its escaped US-ASCII 08456 encoding. [5]. Excluded US-ASCII characters [5], such as 08457 space and control characters and characters used as URI 08458 delimiters, also MUST be escaped. URIs MUST NOT contain 08459 unescaped space and control characters. 08460 08461 For each component, the set of valid BNF expansions defines exactly 08462 which characters may appear unescaped. All other characters MUST be 08463 escaped. 08464 08465 For example, "@" is not in the set of characters in the user 08466 component, so the user "j@s0n" must have at least the @ sign encoded, 08467 as in "j%40s0n". 08468 08469 Expanding the hname and hvalue tokens in Section 25 show that all URI 08470 reserved characters in header field names and values MUST be escaped. 08471 08472 The telephone-subscriber subset of the user component has special 08473 escaping considerations. The set of characters not reserved in the 08474 RFC 2806 [9] description of telephone-subscriber contains a number of 08475 characters in various syntax elements that need to be escaped when 08476 used in SIP URIs. Any characters occurring in a telephone-subscriber 08477 that do not appear in an expansion of the BNF for the user rule MUST 08478 be escaped. 08479 08480 Note that character escaping is not allowed in the host component of 08481 a SIP or SIPS URI (the % character is not valid in its expansion). 08482 This is likely to change in the future as requirements for 08483 Internationalized Domain Names are finalized. Current implementations 08484 MUST NOT attempt to improve robustness by treating received escaped 08485 characters in the host component as literally equivalent to their 08486 unescaped counterpart. The behavior required to meet the 08487 requirements of IDN may be significantly different. 08488 08489 19.1.3 Example SIP and SIPS URIs 08490 08491 08492 sip:alice@atlanta.com 08493 sip:alice:secretword@atlanta.com;transport=tcp 08494 sips:alice@atlanta.com?subject=project 08495 sip:+1-212-555-1212:1234@gateway.com;user=phone 08496 sips:1212@gateway.com 08497 sip:alice@192.0.2.4 08498 sip:atlanta.com;method=REGISTER?to=alice 08499 sip:alice;day=tuesday@atlanta.com 08500 08501 08502 08503 J. Rosenberg et. al. [Page 147] 08504 Internet Draft SIP February 18, 2002 08505 08506 08507 The last sample URI above has a user field value of 08508 "alice;day=tuesday". The escaping rules defined above allow a 08509 semicolon to appear unescaped in this field. For the purposes of this 08510 protocol, the field is opaque. The structure of that value is only 08511 useful to the SIP element responsible for the resource. 08512 08513 19.1.4 URI Comparison 08514 08515 Some operations in this specification require determining whether two 08516 SIP or SIPS URIs are equivalent. In this specification, registrars 08517 need to compare bindings in Contact URIs in REGISTER requests (see 08518 Section 10.3.) SIP and SIPS URIs are compared for equality according 08519 to the following rules: 08520 08521 o A SIP and SIPS URI are not equivalent, even if the rest of the 08522 URIs are equivalent. 08523 08524 o Comparison of the userinfo of SIP and SIPS URIs is case- 08525 sensitive. This includes userinfo containing passwords or 08526 formatted as telephone-subscribers. Comparison of all other 08527 components of the URI is case-insensitive unless explicitly 08528 defined otherwise. 08529 08530 o The ordering of parameters and header fields is not 08531 significant in comparing SIP and SIPS URIs. 08532 08533 o Characters other than those in the "reserved" and "unsafe" 08534 sets (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" 08535 encoding. 08536 08537 o An IP address that is the result of a DNS lookup of a host 08538 name does not match that host name. 08539 08540 o For two URIs to be equal, the user, password, host, and port 08541 components must match. 08542 08543 A URI omitting the user component will not match a URI that 08544 includes one. A URI omitting the password component will not 08545 match a URI that includes one. 08546 08547 A URI omitting any component with a default value will not 08548 match a URI explicitly containing that component with its 08549 default value. For instance, a URI omitting the optional port 08550 component will not match a URI explicitly declaring port 5060. 08551 The same is true for the transport-parameter, ttl-parameter, 08552 user-parameter, and method components. 08553 08554 08555 08556 08557 08558 J. Rosenberg et. al. [Page 148] 08559 Internet Draft SIP February 18, 2002 08560 08561 08562 Defining sip:user@host to not be equivalent to 08563 sip:user@host:5060 is a change from RFC 2543. When 08564 deriving addresses from URIs, equivalent addresses are 08565 expected from equivalent URIs. The URI 08566 sip:user@host:5060 will always resolve to port 5060. 08567 The URI sip:user@host may resolve to other ports 08568 through the DNS SRV mechanisms detailed in [4]. 08569 08570 o URI uri-parameter components are compared as follows 08571 08572 - Any uri-parameter appearing in both URIs must match. 08573 08574 - A user, ttl, or method uri-parameter appearing in only one 08575 URI never matches, even if it contains the default value. 08576 08577 - A URI that includes an maddr parameter will not match a URI 08578 that contains no maddr parameter. 08579 08580 - All other uri-parameters appearing in only one URI are 08581 ignored when comparing the URIs. 08582 08583 o URI header components are never ignored. Any present header 08584 component MUST be present in both URIs and match for the URIs 08585 to match. The matching rules are defined for each header field 08586 in Section 20. 08587 08588 The URIs within each of the following sets are equivalent: 08589 08590 08591 sip:%61lice@atlanta.com;transport=TCP 08592 sip:alice@AtLanTa.CoM;Transport=tcp 08593 08594 08595 08596 08597 sip:carol@chicago.com 08598 sip:carol@chicago.com;newparam=5 08599 sip:carol@chicago.com;security=on 08600 08601 08602 08603 08604 sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com 08605 sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com 08606 08607 08608 08609 08610 08611 08612 08613 J. Rosenberg et. al. [Page 149] 08614 Internet Draft SIP February 18, 2002 08615 08616 08617 sip:alice@atlanta.com?subject=project%20x&priority=urgent 08618 sip:alice@atlanta.com?priority=urgent&subject=project%20x 08619 08620 08621 08622 The URIs within each of the following sets are not equivalent: 08623 08624 08625 SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) 08626 sip:alice@AtLanTa.CoM;Transport=UDP 08627 08628 08629 08630 08631 sip:bob@biloxi.com (can resolve to different ports) 08632 sip:bob@biloxi.com:5060 08633 08634 08635 08636 08637 sip:bob@biloxi.com (can resolve to different transports) 08638 sip:bob@biloxi.com;transport=udp 08639 08640 08641 08642 08643 sip:bob@biloxi.com (can resolve to different port and transports) 08644 sip:bob@biloxi.com:6000;transport=tcp 08645 08646 08647 08648 08649 sip:carol@chicago.com (different header component) 08650 sip:carol@chicago.com?Subject=next%20meeting 08651 08652 08653 08654 08655 sip:bob@phone21.boxesbybob.com (even though that's what 08656 sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) 08657 08658 08659 08660 Note that equality is not transitive: 08661 08662 o sip:carol@chicago.com and sip:carol@chicago.com;security=on 08663 are equivalent 08664 08665 08666 08667 08668 J. Rosenberg et. al. [Page 150] 08669 Internet Draft SIP February 18, 2002 08670 08671 08672 o sip:carol@chicago.com and sip:carol@chicago.com;security=off 08673 are equivalent 08674 08675 o sip:carol@chicago.com;security=on and 08676 sip:carol@chicago.com;security=off are not equivalent 08677 08678 19.1.5 Forming Requests from a URI 08679 08680 An implementation needs to take care when forming requests directly 08681 from a URI. URIs from business cards, web pages, and even from 08682 sources inside the protocol such as registered contacts may contain 08683 inappropriate header fields or body parts. 08684 08685 An implementation MUST include any provided transport, maddr, ttl, or 08686 user parameter in the Request-URI of the formed request. If the URI 08687 contains a method parameter, its value MUST be used as the method of 08688 the request. The method parameter MUST NOT be placed in the Request- 08689 URI. Unknown URI parameters MUST be placed in the message's Request- 08690 URI. 08691 08692 An implementation SHOULD treat the presence of any headers or body 08693 parts in the URI as a desire to include them in the message, and 08694 choose to honor the request on a per-component basis. 08695 08696 An implementation SHOULD NOT honor these obviously dangerous header 08697 fields: From, Call-ID, CSeq, Via, and Record-Route. 08698 08699 An implementation SHOULD NOT honor any requested Route header field 08700 values in order to not be used as an unwitting agent in malicious 08701 attacks. 08702 08703 An implementation SHOULD NOT honor requests to include header fields 08704 that may cause it to falsely advertise its location or capabilities. 08705 These include: Accept, Accept-Encoding, Accept-Language, Allow, 08706 Contact (in its dialog usage), Organization, Supported, and User- 08707 Agent. 08708 08709 An implementation SHOULD verify the accuracy of any requested 08710 descriptive header fields, including: Content-Disposition, Content- 08711 Encoding, Content-Language, Content-Length, Content-Type, Date, 08712 Mime-Version, and Timestamp. 08713 08714 If the request formed from constructing a message from a given URI is 08715 not a valid SIP request, the URI is invalid. An implementation MUST 08716 NOT proceed with transmitting the request. It should instead pursue 08717 the course of action due an invalid URI in the context it occurs. 08718 08719 08720 08721 08722 08723 J. Rosenberg et. al. [Page 151] 08724 Internet Draft SIP February 18, 2002 08725 08726 08727 The constructed request can be invalid in many ways. These 08728 include, but are not limited to, syntax error in header 08729 fields, invalid combinations of URI parameters, or an 08730 incorrect description of the message body. 08731 08732 Sending a request formed from a given URI may require capabilities 08733 unavailable to the implementation. The URI might indicate use of an 08734 unimplemented transport or extension, for example. An implementation 08735 SHOULD refuse to send these requests rather than modifying them to 08736 match their capabilities. An implementation MUST NOT send a request 08737 requiring an extension that it does not support. 08738 08739 08740 For example, such a request can be formed through the 08741 presence of a Require header parameter or a method URI 08742 parameter with an unknown or explicitly unsupported value. 08743 08744 19.1.6 Relating SIP URIs and tel URLs 08745 08746 When a tel URL [9] is converted to a SIP or SIPS URI, the entire 08747 telephone-subscriber portion of the tel URL, including any 08748 parameters, is placed into the userinfo part of the SIP or SIPS URI. 08749 08750 Thus, tel:+358-555-1234567;postd=pp22 becomes 08751 08752 sip:+358-555-1234567;postd=pp22@foo.com;user=phone 08753 or 08754 sips:+358-555-1234567;postd=pp22@foo.com;user=phone 08755 08756 08757 not 08758 08759 sip:+358-555-1234567@foo.com;postd=pp22;user=phone 08760 or 08761 sips:+358-555-1234567@foo.com;postd=pp22;user=phone 08762 08763 08764 08765 In general, equivalent "tel" URLs converted to SIP or SIPS URIs in 08766 this fashion may not produce equivalent SIP or SIPS URIs. The 08767 userinfo of SIP and SIPS URIs are compared as a case-sensitive 08768 string. Variance in case-insensitive portions of tel URLs and 08769 reordering of tel URL parameters does not affect tel URL equivalence, 08770 but does affect the equivalence of SIP URIs formed from them. 08771 08772 For example, 08773 08774 tel:+358-555-1234567;postd=pp22 08775 08776 08777 08778 J. Rosenberg et. al. [Page 152] 08779 Internet Draft SIP February 18, 2002 08780 08781 08782 tel:+358-555-1234567;POSTD=PP22 08783 08784 08785 are equivalent, while 08786 08787 sip:+358-555-1234567;postd=pp22@foo.com;user=phone 08788 sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone 08789 08790 08791 are not. 08792 08793 Likewise, 08794 08795 tel:+358-555-1234567;postd=pp22;isub=1411 08796 tel:+358-555-1234567;isub=1411;postd=pp22 08797 08798 08799 are equivalent, while 08800 08801 sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone 08802 sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone 08803 08804 08805 are not. 08806 08807 To mitigate this problem, elements constructing telephone-subscriber 08808 fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold 08809 any case-insensitive portion of telephone-subscriber to lower case, 08810 and order the telephone-subscriber parameters lexically by parameter 08811 name. (All components of a tel URL except for future-extension 08812 parameters are defined to be compared case-insensitive.) 08813 08814 Following this suggestion, both 08815 08816 tel:+358-555-1234567;postd=pp22 08817 tel:+358-555-1234567;POSTD=PP22 08818 08819 08820 become 08821 08822 sip:+358-555-1234567;postd=pp22@foo.com;user=phone 08823 08824 08825 and both 08826 08827 tel:+358-555-1234567;postd=pp22;isub=1411 08828 tel:+358-555-1234567;isub=1411;postd=pp22 08829 08830 08831 08832 08833 J. Rosenberg et. al. [Page 153] 08834 Internet Draft SIP February 18, 2002 08835 08836 08837 become 08838 08839 sip:+358-555-1234567;isub=1411;postd=pp22;user=phone 08840 08841 08842 08843 19.2 Option Tags 08844 08845 Option tags are unique identifiers used to designate new options 08846 (extensions) in SIP. These tags are used in Require (Section 20.32), 08847 Proxy-Require (Section 20.29), Supported (Section 20.37) and 08848 Unsupported (Section 20.40) header fields. Note that these options 08849 appear as parameters in those header fields in an option-tag = token 08850 form (see Section 25 for the definition of token). 08851 08852 The creator of a new SIP option MUST either prefix the option with 08853 their reverse domain name or register the new option with the 08854 Internet Assigned Numbers Authority (IANA) (See Section 27). 08855 08856 An example of a reverse-domain-name option is "com.foo.mynewfeature", 08857 whose inventor can be reached at "foo.com". For these features, 08858 individual organizations are responsible for ensuring that option 08859 names do not collide within the same domain. The domain name part of 08860 the option MUST use lower-case; the option name is case-insensitive. 08861 08862 Options registered with IANA do not contain periods and are globally 08863 unique. IANA option tags are case-insensitive. 08864 08865 19.3 Tags 08866 08867 The "tag" parameter is used in the To and From header fields of SIP 08868 messages. It serves as a general mechanism to identify a dialog, 08869 which is the combination of the Call-ID along with two tags, one from 08870 each participant in the dialog. When a UA sends a request outside of 08871 a dialog, it contains a From tag only, providing "half" of the dialog 08872 ID. The dialog is completed from the response(s), each of which 08873 contributes the second half in the To header field. The forking of 08874 SIP requests means that multiple dialogs can be established from a 08875 single request. This also explains the need for the two-sided dialog 08876 identifier; without a contribution from the recipients, the 08877 originator could not disambiguate the multiple dialogs established 08878 from a single request. 08879 08880 When a tag is generated by a UA for insertion into a request or 08881 response, it MUST be globally unique and cryptographically random 08882 with at least 32 bits of randomness. A property of this selection 08883 requirement is that a UA will place a different tag into the From 08884 header of an INVITE as it would place into the To header of the 08885 08886 08887 08888 J. Rosenberg et. al. [Page 154] 08889 Internet Draft SIP February 18, 2002 08890 08891 08892 response to the same INVITE. This is needed in order for a UA to 08893 invite itself to a session, a common case for "hairpinning" of calls 08894 in PSTN gateways. Similarly, two INVITEs for different calls will 08895 have different From tags. 08896 08897 Besides the requirement for global uniqueness, the algorithm for 08898 generating a tag is implementation-specific. Tags are helpful in 08899 fault tolerant systems, where a dialog is to be recovered on an 08900 alternate server after a failure. A UAS can select the tag in such a 08901 way that a backup can recognize a request as part of a dialog on the 08902 failed server, and therefore determine that it should attempt to 08903 recover the dialog and any other state associated with it. 08904 08905 20 Header Fields 08906 08907 The general syntax for header fields is covered in Section 7.3. This 08908 section lists the full set of header fields along with notes on 08909 syntax, meaning, and usage. Throughout this section, we use [HX.Y] 08910 to refer to Section X.Y of the current HTTP/1.1 specification RFC 08911 2616 [8]. Examples of each header field are given. 08912 08913 Information about header fields in relation to methods and proxy 08914 processing is summarized in Tables 2 and 3. 08915 08916 The "where" column describes the request and response types in which 08917 the header field can be used. Values in this column are: 08918 08919 R: header field may only appear in requests; 08920 08921 r: header field may only appear in responses; 08922 08923 2xx, 4xx, etc.: A numerical value or range indicates response 08924 codes with which the header field can be used; 08925 08926 c: header field is copied from the request to the response. 08927 08928 An empty entry in the "where" column indicates that the header 08929 field may be present in all requests and responses. 08930 08931 The "proxy" column describes the operations a proxy may perform on a 08932 header field: 08933 08934 a: A proxy can add or concatenate the header field if not 08935 present. 08936 08937 m: A proxy can modify an existing header field value. 08938 08939 d: A proxy can delete a header field value. 08940 08941 08942 08943 J. Rosenberg et. al. [Page 155] 08944 Internet Draft SIP February 18, 2002 08945 08946 08947 r: A proxy must be able to read the header field, and thus this 08948 header field cannot be encrypted. 08949 08950 The next six columns relate to the presence of a header field in a 08951 method: 08952 08953 c: Conditional; the header field is either mandatory or 08954 optional, depending on the presence of a route set or the 08955 response code. 08956 08957 m: The header field is mandatory. 08958 08959 m*: The header field SHOULD be sent, but clients/servers need to 08960 be prepared to receive messages without that header field. 08961 08962 o: The header field is optional. 08963 08964 t: The header field SHOULD be sent, but clients/servers need to 08965 be prepared to receive messages without that header field. 08966 If a stream-based protocol (such as TCP) is used as a 08967 transport, then the header field MUST be sent. 08968 08969 *: The header field is required if the message body is not 08970 empty. See sections 20.14, 20.15 and 7.4 for details. 08971 08972 -: The header field is not applicable. 08973 08974 "Optional" means that a UA MAY include the header field in a request 08975 or response, and a UA MAY ignore the header field if present in the 08976 request or response (The exception to this rule is the Require header 08977 field discussed in 20.32). A "mandatory" header field MUST be present 08978 in a request, and MUST be understood by the UAS receiving the 08979 request. A mandatory response header field MUST be present in the 08980 response, and the header field MUST be understood by the UAC 08981 processing the response. "Not applicable" means that the header field 08982 MUST NOT be present in a request. If one is placed in a request by 08983 mistake, it MUST be ignored by the UAS receiving the request. 08984 Similarly, a header field labeled "not applicable" for a response 08985 means that the UAS MUST NOT place the header field in the response, 08986 and the UAC MUST ignore the header field in the response. 08987 08988 A UA SHOULD ignore extension header parameters that are not 08989 understood. 08990 08991 08992 08993 A compact form of some common header field names is also defined for 08994 use when overall message size is an issue. 08995 08996 08997 08998 J. Rosenberg et. al. [Page 156] 08999 Internet Draft SIP February 18, 2002 09000 09001 09002 09003 Header field where proxy ACK BYE CAN INV OPT REG 09004 ___________________________________________________________ 09005 Accept R - o - o m* o 09006 Accept 2xx - - - o m* o 09007 Accept 415 - o - o o o 09008 Accept-Encoding R - o - o o o 09009 Accept-Encoding 2xx - - - o m* o 09010 Accept-Encoding 415 - o - o o o 09011 Accept-Language R - o - o o o 09012 Accept-Language 2xx - - - o m* o 09013 Accept-Language 415 - o - o o o 09014 Alert-Info R ar - - - o - - 09015 Alert-Info 180 ar - - - o - - 09016 Allow R - o - o o o 09017 Allow 2xx - o - m* m* o 09018 Allow r - o - o o o 09019 Allow 405 - m - m m m 09020 Authentication-Info 2xx - o - o o o 09021 Authorization R o o o o o o 09022 Call-ID c r m m m m m m 09023 Call-Info ar - - - o o o 09024 Contact R o - - m o o 09025 Contact 1xx - - - o - - 09026 Contact 2xx - - - m o o 09027 Contact 3xx d - o - o o o 09028 Contact 485 - o - o o o 09029 Content-Disposition o o - o o o 09030 Content-Encoding o o - o o o 09031 Content-Language o o - o o o 09032 Content-Length ar t t t t t t 09033 Content-Type * * - * * * 09034 CSeq c r m m m m m m 09035 Date a o o o o o o 09036 Error-Info 300-699 a - o o o o o 09037 Expires - - - o - o 09038 From c r m m m m m m 09039 In-Reply-To R - - - o - - 09040 Max-Forwards R amr m m m m m m 09041 Min-Expires 423 - - - - - m 09042 MIME-Version o o - o o o 09043 Organization ar - - - o o o 09044 09045 09046 Table 2: Summary of header fields, A--O 09047 09048 09049 09050 09051 09052 09053 J. Rosenberg et. al. [Page 157] 09054 Internet Draft SIP February 18, 2002 09055 09056 09057 09058 Header field where proxy ACK BYE CAN INV OPT REG 09059 ___________________________________________________________________ 09060 Priority R ar - - - o - - 09061 Proxy-Authenticate 407 - m - m m m 09062 Proxy-Authenticate 401 - o o o o o 09063 Proxy-Authorization R dr o o - o o o 09064 Proxy-Require R ar - o - o o o 09065 Record-Route R ar o o o o o - 09066 Record-Route 2xx,18x mr - o o o o - 09067 Reply-To - - - o - - 09068 Require ar - o - o o o 09069 Retry-After 404,413,480,486 - o o o o o 09070 500,503 - o o o o o 09071 600,603 - o o o o o 09072 Route R adr c c c c c c 09073 Server r - o o o o o 09074 Subject R - - - o - - 09075 Supported R - o o m* o o 09076 Supported 2xx - o o m* m* o 09077 Timestamp o o o o o o 09078 To c(1) r m m m m m m 09079 Unsupported 420 - o o o o o 09080 User-Agent o o o o o o 09081 Via R amr m m m m m m 09082 Via rc dr m m m m m m 09083 Warning r - o o o o o 09084 WWW-Authenticate 401 - m - m m m 09085 WWW-Authenticate 407 - o - o o o 09086 09087 09088 Table 3: Summary of header fields, P--Z; (1): copied with possible 09089 addition of tag 09090 09091 The Contact, From, and To header fields contain a URI. If the URI 09092 contains a comma, question mark or semicolon, the URI MUST be 09093 enclosed in angle brackets (< and >). Any URI parameters are 09094 contained within these brackets. If the URI is not enclosed in angle 09095 brackets, any semicolon-delimited parameters are header-parameters, 09096 not URI parameters. 09097 09098 20.1 Accept 09099 09100 The Accept header field follows the syntax defined in [H14.1]. The 09101 semantics are also identical, with the exception that if no Accept 09102 header field is present, the server SHOULD assume a default value of 09103 application/sdp 09104 09105 09106 09107 09108 J. Rosenberg et. al. [Page 158] 09109 Internet Draft SIP February 18, 2002 09110 09111 09112 An empty Accept header field means that no formats are acceptable. 09113 09114 Example: 09115 09116 09117 Accept: application/sdp;level=1, application/x-private, text/html 09118 09119 09120 09121 20.2 Accept-Encoding 09122 09123 The Accept-Encoding header field is similar to Accept, but restricts 09124 the content-codings [H3.5] that are acceptable in the response. See 09125 [H14.3]. The syntax of this header field is defined in [H14.3]. The 09126 semantics in SIP are identical to those defined in [H14.3]. 09127 09128 An empty Accept-Encoding header field is permissible, even though the 09129 syntax in [H14.3] does not provide for it. It is equivalent to 09130 Accept-Encoding: identity, that is, only the identity encoding, 09131 meaning no encoding, is permissible. 09132 09133 If no Accept-Encoding header field is present, the server SHOULD 09134 assume a default value of identity. 09135 09136 This differs slightly from the HTTP definition, which indicates that 09137 when not present, any encoding can be used, but the identity encoding 09138 is preferred. 09139 09140 Example: 09141 09142 09143 Accept-Encoding: gzip 09144 09145 09146 09147 20.3 Accept-Language 09148 09149 The Accept-Language header field is used in requests to indicate the 09150 preferred languages for reason phrases, session descriptions, or 09151 status responses carried as message bodies in the response. If no 09152 Accept-Language header field is present, the server SHOULD assume all 09153 languages are acceptable to the client. 09154 09155 The Accept-Language header field follows the syntax defined in 09156 [H14.4]. The rules for ordering the languages based on the "q" 09157 parameter apply to SIP as well. 09158 09159 Example: 09160 09161 09162 09163 J. Rosenberg et. al. [Page 159] 09164 Internet Draft SIP February 18, 2002 09165 09166 09167 Accept-Language: da, en-gb;q=0.8, en;q=0.7 09168 09169 09170 09171 20.4 Alert-Info 09172 09173 When present in an INVITE request, the Alert-Info header field 09174 specifies an alternative ring tone to the UAS. When present in a 180 09175 (Ringing) response, the Alert-Info header field specifies an 09176 alternative ringback tone to the UAC. A typical usage is for a proxy 09177 to insert this header field to provide a distinctive ring feature. 09178 09179 The Alert-Info header field can introduce security risks. These risks 09180 and the ways to handle them are discussed in Section 20.9, which 09181 discusses the Call-Info header field since the risks are identical. 09182 09183 In addition, a user SHOULD be able to disable this feature 09184 selectively. 09185 09186 09187 This helps prevent disruptions that could result from the 09188 use of this header field by untrusted elements. 09189 09190 Example: 09191 09192 Alert-Info: 09193 09194 09195 09196 20.5 Allow 09197 09198 The Allow header field lists the set of methods supported by the UA 09199 generating the message. 09200 09201 All methods, including ACK and CANCEL, understood by the UA MUST be 09202 included in the list of methods in the Allow header field, when 09203 present. The absence of an Allow header field MUST NOT be interpreted 09204 to mean that the UA sending the message supports no methods. Rather, 09205 it implies that the UA is not providing any information on what 09206 methods it supports. 09207 09208 Supplying an Allow header field in responses to methods other than 09209 OPTIONS reduces the number of messages needed. 09210 09211 Example: 09212 09213 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 09214 09215 09216 09217 09218 J. Rosenberg et. al. [Page 160] 09219 Internet Draft SIP February 18, 2002 09220 09221 09222 20.6 Authentication-Info 09223 09224 The Authentication-Info header field provides for mutual 09225 authentication with HTTP Digest. A UAS MAY include this header field 09226 in a 2xx response to a request that was successfully authenticated 09227 using digest based on the Authorization header field. 09228 09229 Syntax and semantics follow those specified in RFC 2617 [17]. 09230 09231 Example: 09232 09233 Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" 09234 09235 09236 09237 20.7 Authorization 09238 09239 The Authorization header field contains authentication credentials of 09240 a UA. Section 22.2 overviews the use of the Authorization header 09241 field, and Section 22.4 describes the syntax and semantics when used 09242 with HTTP authentication. 09243 09244 This header field, along with Proxy-Authorization, breaks the general 09245 rules about multiple header field values. Although not a comma- 09246 separated list, this header field name may be present multiple times, 09247 and MUST NOT be combined into a single header line using the usual 09248 rules described in Section 7.3. 09249 09250 In the example below, there are no quotes around the Digest 09251 parameter: 09252 09253 09254 Authorization: Digest username="Alice", realm="atlanta.com", 09255 nonce="84a4cc6f3082121f32b42a2187831a9e", 09256 response="7587245234b3434cc3412213e5f113a5432" 09257 09258 09259 09260 20.8 Call-ID 09261 09262 The Call-ID header field uniquely identifies a particular invitation 09263 or all registrations of a particular client. A single multimedia 09264 conference can give rise to several calls with different Call-IDs, 09265 for example, if a user invites a single individual several times to 09266 the same (long-running) conference. Call-IDs are case-sensitive and 09267 are simply compared byte-by-byte. 09268 09269 The compact form of the Call-ID header field is i. 09270 09271 09272 09273 J. Rosenberg et. al. [Page 161] 09274 Internet Draft SIP February 18, 2002 09275 09276 09277 Examples: 09278 09279 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com 09280 i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 09281 09282 09283 09284 20.9 Call-Info 09285 09286 The Call-Info header field provides additional information about the 09287 caller or callee, depending on whether it is found in a request or 09288 response. The purpose of the URI is described by the "purpose" 09289 parameter. The "icon" parameter designates an image suitable as an 09290 iconic representation of the caller or callee. The "info" parameter 09291 describes the caller or callee in general, for example, through a web 09292 page. The "card" parameter provides a business card, for example, in 09293 vCard [35] or LDIF [36] formats. Additional tokens can be registered 09294 using IANA and the procedures in Section 27. 09295 09296 Use of the Call-Info header field can pose a security risk. If a 09297 callee fetches the URIs provided by a malicious caller, the callee 09298 may be at risk for displaying inappropriate or offensive content, 09299 dangerous or illegal content, and so on. Therefore, it is RECOMMENDED 09300 that a UA only render the information in the Call-Info header field 09301 if it can verify the authenticity of the element that originated the 09302 header field and trusts that element. This need not be the peer UA; a 09303 proxy can insert this header field into requests. 09304 09305 Example: 09306 09307 Call-Info: ;purpose=icon, 09308 ;purpose=info 09309 09310 09311 09312 20.10 Contact 09313 09314 A Contact header field value provides a URI whose meaning depends on 09315 the type of request or response it is in. 09316 09317 A Contact header field value can contain a display name, a URI with 09318 URI parameters, and header parameters. 09319 09320 This document defines the Contact parameters "q" and "expires". These 09321 parameters are only used when the Contact is present in a REGISTER 09322 request or response, or in a 3xx response. Additional parameters may 09323 be defined in other specifications. 09324 09325 09326 09327 09328 J. Rosenberg et. al. [Page 162] 09329 Internet Draft SIP February 18, 2002 09330 09331 09332 When the header field value contains a display name, the URI 09333 including all URI parameters is enclosed in "<" and ">". If no "<" 09334 and ">" are present, all parameters after the URI are header 09335 parameters, not URI parameters. The display name can be tokens, or a 09336 quoted string, if a larger character set is desired. 09337 09338 Even if the "display-name" is empty, the "name-addr" form MUST be 09339 used if the "addr-spec" contains a comma, semicolon, or question 09340 mark. There may or may not be LWS between the display-name and the 09341 "<". 09342 09343 These rules for parsing a display name, URI and URI parameters, and 09344 header parameters also apply for the header fields To and From. 09345 09346 09347 The Contact header field has a role similar to the Location 09348 header field in HTTP. However, the HTTP header field only 09349 allows one address, unquoted. Since URIs can contain commas 09350 and semicolons as reserved characters, they can be mistaken 09351 for header or parameter delimiters, respectively. 09352 09353 The compact form of the Contact header field is m (for "moved"). 09354 09355 The second example below shows a Contact header field value 09356 containing both a URI parameter (transport) and a header parameter 09357 (expires). 09358 09359 09360 Contact: "Mr. Watson" 09361 ;q=0.7; expires=3600, 09362 "Mr. Watson" ;q=0.1 09363 m: ;expires=60 09364 09365 09366 09367 20.11 Content-Disposition 09368 09369 The Content-Disposition header field describes how the message body 09370 or, for multipart messages, a message body part is to be interpreted 09371 by the UAC or UAS. This SIP header field extends the MIME Content- 09372 Type (RFC 2183 [18]). 09373 09374 The value "session" indicates that the body part describes a session, 09375 for either calls or early (pre-call) media. The value "render" 09376 indicates that the body part should be displayed or otherwise 09377 rendered to the user. For backward-compatibility, if the Content- 09378 Disposition header field is missing, the server SHOULD assume bodies 09379 of Content-Type application/sdp are the disposition "session", while 09380 09381 09382 09383 J. Rosenberg et. al. [Page 163] 09384 Internet Draft SIP February 18, 2002 09385 09386 09387 other content types are "render". 09388 09389 The disposition type "icon" indicates that the body part contains an 09390 image suitable as an iconic representation of the caller or callee. 09391 The value "alert" indicates that the body part contains information, 09392 such as an audio clip, that should be rendered instead of ring tone. 09393 09394 The handling parameter, handling-param, describes how the UAS should 09395 react if it receives a message body whose content type or disposition 09396 type it does not understand. The parameter has defined values of 09397 "optional" and "required". If the handling parameter is missing, the 09398 value "required" SHOULD be assumed. 09399 09400 If this header field is missing, the MIME type determines the default 09401 content disposition. If there is none, "render" is assumed. 09402 09403 Example: 09404 09405 Content-Disposition: session 09406 09407 09408 09409 20.12 Content-Encoding 09410 09411 The Content-Encoding header field is used as a modifier to the 09412 "media-type". When present, its value indicates what additional 09413 content codings have been applied to the entity-body, and thus what 09414 decoding mechanisms MUST be applied in order to obtain the media-type 09415 referenced by the Content-Type header field. Content-Encoding is 09416 primarily used to allow a body to be compressed without losing the 09417 identity of its underlying media type. 09418 09419 If multiple encodings have been applied to an entity-body, the 09420 content codings MUST be listed in the order in which they were 09421 applied. 09422 09423 All content-coding values are case-insensitive. IANA acts as a 09424 registry for content-coding value tokens. See [H3.5] for a definition 09425 of the syntax for content-coding. 09426 09427 Clients MAY apply content encodings to the body in requests. A server 09428 MAY apply content encodings to the bodies in responses. The server 09429 MUST only use encodings listed in the Accept-Encoding header field in 09430 the request. 09431 09432 The compact form of the Content-Encoding header field is e. Examples: 09433 09434 Content-Encoding: gzip 09435 09436 09437 09438 J. Rosenberg et. al. [Page 164] 09439 Internet Draft SIP February 18, 2002 09440 09441 09442 e: tar 09443 09444 09445 09446 20.13 Content-Language 09447 09448 See [H14.12]. Example: 09449 09450 Content-Language: fr 09451 09452 09453 09454 20.14 Content-Length 09455 09456 The Content-Length header field indicates the size of the message- 09457 body, in decimal number of octets, sent to the recipient. 09458 Applications SHOULD use this field to indicate the size of the 09459 message-body to be transferred, regardless of the media type of the 09460 entity. If a stream-based protocol (such as TCP) is used as 09461 transport, the header field MUST be used. 09462 09463 The size of the message-body does not include the CRLF separating 09464 headers and body. Any Content-Length greater than or equal to zero is 09465 a valid value. If no body is present in a message, then the Content- 09466 Length header field value MUST be set to zero. 09467 09468 The ability to omit Content-Length simplifies the creation 09469 of cgi-like scripts that dynamically generate responses. 09470 09471 The compact form of the header field is l. 09472 09473 Examples: 09474 09475 Content-Length: 349 09476 l: 173 09477 09478 09479 09480 20.15 Content-Type 09481 09482 The Content-Type header field indicates the media type of the 09483 message-body sent to the recipient. The "media-type" element is 09484 defined in [H3.7]. The Content-Type header field MUST be present if 09485 the body is not empty. If the body is empty, and a Content-Type 09486 header field is present, it indicates that the body of the specific 09487 type has zero length (for example, an empty audio file). 09488 09489 The compact form of the header field is c. 09490 09491 09492 09493 J. Rosenberg et. al. [Page 165] 09494 Internet Draft SIP February 18, 2002 09495 09496 09497 Examples: 09498 09499 Content-Type: application/sdp 09500 c: text/html; charset=ISO-8859-4 09501 09502 09503 09504 20.16 CSeq 09505 09506 A CSeq header field in a request contains a single decimal sequence 09507 number and the request method. The sequence number MUST be 09508 expressible as a 32-bit unsigned integer. The method part of CSeq is 09509 case-sensitive. The CSeq header field serves to order transactions 09510 within a dialog, to provide a means to uniquely identify 09511 transactions, and to differentiate between new requests and request 09512 retransmissions. Two CSeq header fields are considered equal if the 09513 sequence number and the request method are identical. Example: 09514 09515 09516 CSeq: 4711 INVITE 09517 09518 09519 09520 20.17 Date 09521 09522 The Date header field contains a the date and time. Unlike HTTP/1.1, 09523 SIP only supports the most recent RFC 1123 [19] format for dates. As 09524 in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while 09525 RFC 1123 allows any time zone. rfc1123-date is case-sensitive. 09526 09527 The Date header field reflects the time when the request or response 09528 is first sent. 09529 09530 09531 The Date header field can be used by simple end systems 09532 without a battery-backed clock to acquire a notion of 09533 current time. However, in its GMT form, it requires clients 09534 to know their offset from GMT. 09535 09536 Example: 09537 09538 Date: Sat, 13 Nov 2010 23:29:00 GMT 09539 09540 09541 09542 20.18 Error-Info 09543 09544 The Error-Info header field provides a pointer to additional 09545 09546 09547 09548 J. Rosenberg et. al. [Page 166] 09549 Internet Draft SIP February 18, 2002 09550 09551 09552 information about the error status response. 09553 09554 09555 SIP UACs have user interface capabilities ranging from 09556 pop-up windows and audio on PC softclients to audio-only on 09557 "black" phones or endpoints connected via gateways. Rather 09558 than forcing a server generating an error to choose between 09559 sending an error status code with a detailed reason phrase 09560 and playing an audio recording, the Error-Info header field 09561 allows both to be sent. The UAC then has the choice of 09562 which error indicator to render to the caller. 09563 09564 A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if 09565 it were a Contact in a redirect and generate a new INVITE, resulting 09566 in a recorded announcement session being established. A non-SIP URI 09567 MAY be rendered to the user. 09568 09569 Examples: 09570 09571 SIP/2.0 404 The number you have dialed is not in service 09572 Error-Info: 09573 09574 09575 09576 20.19 Expires 09577 09578 The Expires header field gives the relative time after which the 09579 message (or content) expires. 09580 09581 The precise meaning of this is method dependent. 09582 09583 The expiration time in an INVITE does not affect the duration of the 09584 actual session that may result from the invitation. Session 09585 description protocols may offer the ability to express time limits on 09586 the session duration, however. 09587 09588 The value of this field is an integral number of seconds (in decimal) 09589 between 0 and (2**31)-1, measured from the receipt of the request. 09590 09591 Example: 09592 09593 Expires: 5 09594 09595 09596 09597 20.20 From 09598 09599 The From header field indicates the initiator of the request. This 09600 09601 09602 09603 J. Rosenberg et. al. [Page 167] 09604 Internet Draft SIP February 18, 2002 09605 09606 09607 may be different from the initiator of the dialog. Requests sent by 09608 the callee to the caller use the callee's address in the From header 09609 field. 09610 09611 The optional "display-name" is meant to be rendered by a human user 09612 interface. A system SHOULD use the display name "Anonymous" if the 09613 identity of the client is to remain hidden. Even if the "display- 09614 name" is empty, the "name-addr" form MUST be used if the "addr-spec" 09615 contains a comma, question mark, or semicolon. Syntax issues are 09616 discussed in Section 7.3.1. 09617 09618 Section 12 describes how From header fields are compared for the 09619 purpose of matching requests to dialogs. See Section 20.10 for the 09620 rules for parsing a display name, URI and URI parameters, and header 09621 parameters. 09622 09623 The compact form of the From header field is f. 09624 09625 Examples: 09626 09627 From: "A. G. Bell" ;tag=a48s 09628 From: sip:+12125551212@server.phone2net.com;tag=887s 09629 f: Anonymous ;tag=hyh8 09630 09631 09632 09633 20.21 In-Reply-To 09634 09635 The In-Reply-To header field enumerates the Call-IDs that this call 09636 references or returns. These Call-IDs may have been cached by the 09637 client then included in this header field in a return call. 09638 09639 09640 This allows automatic call distribution systems to route 09641 return calls to the originator of the first call. This also 09642 allows callees to filter calls, so that only return calls 09643 for calls they originated will be accepted. This field is 09644 not a substitute for request authentication. 09645 09646 Example: 09647 09648 In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 09649 09650 09651 09652 20.22 Max-Forwards 09653 09654 The Max-Forwards header field must be used with any SIP method to 09655 09656 09657 09658 J. Rosenberg et. al. [Page 168] 09659 Internet Draft SIP February 18, 2002 09660 09661 09662 limit the number of proxies or gateways that can forward the request 09663 to the next downstream server. This can also be useful when the 09664 client is attempting to trace a request chain that appears to be 09665 failing or looping in mid-chain. 09666 09667 The Max-Forwards value is an integer in the range 0-255 indicating 09668 the remaining number of times this request message is allowed to be 09669 forwarded. This count is decremented by each server that forwards the 09670 request. The recommended value is 70. 09671 09672 This header field should be inserted by elements that can not 09673 otherwise guarantee loop detection. For example, a B2BUA should 09674 insert a Max-Forwards header field. 09675 09676 Example: 09677 09678 Max-Forwards: 6 09679 09680 09681 09682 20.23 Min-Expires 09683 09684 The Min-Expires header field conveys the minimum refresh interval 09685 supported for soft-state elements managed by that server. This 09686 includes Contact header fields that are stored by a registrar. The 09687 header field contains a decimal integer number of seconds from 0 to 09688 (2**32)-1. The use of the header field in a 423 (Registration Too 09689 Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17. 09690 09691 Example: 09692 09693 Min-Expires: 60 09694 09695 09696 09697 20.24 MIME-Version 09698 09699 See [H19.4.1]. 09700 09701 Example: 09702 09703 MIME-Version: 1.0 09704 09705 09706 09707 20.25 Organization 09708 09709 The Organization header field conveys the name of the organization to 09710 09711 09712 09713 J. Rosenberg et. al. [Page 169] 09714 Internet Draft SIP February 18, 2002 09715 09716 09717 which the SIP element issuing the request or response belongs. 09718 09719 09720 The field MAY be used by client software to filter calls. 09721 09722 Example: 09723 09724 Organization: Boxes by Bob 09725 09726 09727 09728 20.26 Priority 09729 09730 The Priority header field indicates the urgency of the request as 09731 perceived by the client. The Priority header field describes the 09732 priority that the SIP request should have to the receiving human or 09733 its agent. For example, it may be factored into decisions about call 09734 routing and acceptance. For these decisions, a message containing no 09735 Priority header field SHOULD be treated as if it specified a Priority 09736 of "non-urgent". The Priority header field does not influence the 09737 use of communications resources such as packet forwarding priority in 09738 routers or access to circuits in PSTN gateways. The header field can 09739 have the values "non-urgent", "normal", "urgent", and "emergency", 09740 but additional values can be defined elsewhere. It is RECOMMENDED 09741 that the value of "emergency" only be used when life, limb, or 09742 property are in imminent danger. Otherwise, there are no semantics 09743 defined for this header field. 09744 09745 09746 These are the values of RFC 2076 [37], with the addition of 09747 "emergency". 09748 09749 Examples: 09750 09751 09752 Subject: A tornado is heading our way! 09753 Priority: emergency 09754 09755 09756 or 09757 09758 Subject: Weekend plans 09759 Priority: non-urgent 09760 09761 09762 09763 20.27 Proxy-Authenticate 09764 09765 09766 09767 09768 J. Rosenberg et. al. [Page 170] 09769 Internet Draft SIP February 18, 2002 09770 09771 09772 A Proxy-Authenticate header field value contains an authentication 09773 challenge. 09774 09775 The syntax for this header field and its use is defined in [H14.33]. 09776 See 22.3 for further details on its usage. 09777 09778 Example: 09779 09780 Proxy-Authenticate: Digest realm="atlanta.com", 09781 domain="sip:ss1.carrier.com", 09782 nonce="f84f1cec41e6cbe5aea9c8e88d359", 09783 opaque="", stale=FALSE, algorithm=MD5 09784 09785 09786 09787 20.28 Proxy-Authorization 09788 09789 The Proxy-Authorization header field allows the client to identify 09790 itself (or its user) to a proxy that requires authentication. A 09791 Proxy-Authorization field value consists of credentials containing 09792 the authentication information of the user agent for the proxy and/or 09793 realm of the resource being requested. 09794 09795 See [H14.34] for a definition of the syntax, and section 22.3 for a 09796 discussion of its usage. 09797 09798 This header field, along with Authorization, breaks the general rules 09799 about multiple header field names. Although not a comma-separated 09800 list, this header field name may be present multiple times, and MUST 09801 NOT be combined into a single header line using the usual rules 09802 described in Section 7.3.1. 09803 09804 Example: 09805 09806 Proxy-Authorization: Digest username="Alice", realm="atlanta.com", 09807 nonce="c60f3082ee1212b402a21831ae", 09808 response="245f23415f11432b3434341c022" 09809 09810 09811 09812 20.29 Proxy-Require 09813 09814 The Proxy-Require header field is used to indicate proxy-sensitive 09815 features that must be supported by the proxy. See Section 20.32 for 09816 more details on the mechanics of this message and a usage example. 09817 09818 Example: 09819 09820 09821 09822 09823 J. Rosenberg et. al. [Page 171] 09824 Internet Draft SIP February 18, 2002 09825 09826 09827 Proxy-Require: foo 09828 09829 09830 09831 20.30 Record-Route 09832 09833 The Record-Route header field is inserted by proxies in a request to 09834 force future requests in the dialog to be routed through the proxy. 09835 09836 Examples of its use with the Route header field are described in 09837 Sections 16.12.1. 09838 09839 Example: 09840 09841 Record-Route: , 09842 09843 09844 09845 20.31 Reply-To 09846 09847 The Reply-To header field contains a logical return URI that may be 09848 different from the From header field. For example, the URI MAY be 09849 used to return missed calls or unestablished sessions. If the user 09850 wished to remain anonymous, the header field SHOULD either be omitted 09851 from the request or populated in such a way that does not reveal any 09852 private information. 09853 09854 Even if the "display-name" is empty, the "name-addr" form MUST be 09855 used if the "addr-spec" contains a comma, question mark, or 09856 semicolon. Syntax issues are discussed in Section 7.3.1. 09857 09858 Example: 09859 09860 Reply-To: Bob 09861 09862 09863 09864 20.32 Require 09865 09866 The Require header field is used by UACs to tell UASs about options 09867 that the UAC expects the UAS to support in order to process the 09868 request. Although an optional header field, the Require MUST NOT be 09869 ignored if it is present. 09870 09871 The Require header field contains a list of option tags, described in 09872 Section 19.2. Each option tag defines a SIP extension that MUST be 09873 understood to process the request. Frequently, this is used to 09874 indicate that a specific set of extension header fields need to be 09875 09876 09877 09878 J. Rosenberg et. al. [Page 172] 09879 Internet Draft SIP February 18, 2002 09880 09881 09882 understood. A UAC compliant to this specification MUST only include 09883 option tags corresponding to standards-track RFCs. 09884 09885 Example: 09886 09887 Require: 100rel 09888 09889 09890 09891 20.33 Retry-After 09892 09893 The Retry-After header field can be used with a 503 (Service 09894 Unavailable) response to indicate how long the service is expected to 09895 be unavailable to the requesting client and with a 404 (Not Found), 09896 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 09897 (Busy Here), 600 (Busy), or 603 (Decline) response to indicate when 09898 the called party anticipates being available again. The value of this 09899 field is a positive integer number of seconds (in decimal) after the 09900 time of the response. 09901 09902 An optional comment can be used to indicate additional information 09903 about the time of callback. An optional "duration" parameter 09904 indicates how long the called party will be reachable starting at the 09905 initial time of availability. If no duration parameter is given, the 09906 service is assumed to be available indefinitely. 09907 09908 Examples: 09909 09910 Retry-After: 18000;duration=3600 09911 Retry-After: 120 (I'm in a meeting) 09912 09913 09914 09915 20.34 Route 09916 09917 The Route header field is used to force routing for a request through 09918 the listed set of proxies. Examples of the use of the Record-Route 09919 header field are in Section 16.12.1. 09920 09921 Example: 09922 09923 Route: , 09924 09925 09926 09927 20.35 Server 09928 09929 The Server header field contains information about the software used 09930 09931 09932 09933 J. Rosenberg et. al. [Page 173] 09934 Internet Draft SIP February 18, 2002 09935 09936 09937 by the UAS to handle the request. The syntax for this field is 09938 defined in [H14.38]. 09939 09940 Revealing the specific software version of the server might allow the 09941 server to become more vulnerable to attacks against software that is 09942 known to contain security holes. Implementers SHOULD make the Server 09943 header field a configurable option. 09944 09945 Example: 09946 09947 Server: HomeProxy v2 09948 09949 09950 09951 20.36 Subject 09952 09953 The Subject header field provides a summary or indicates the nature 09954 of the call, allowing call filtering without having to parse the 09955 session description. The session description does not have to use the 09956 same subject indication as the invitation. 09957 09958 The compact form of the Subject header field is s. 09959 09960 Example: 09961 09962 Subject: Need more boxes 09963 s: Tech Support 09964 09965 09966 09967 20.37 Supported 09968 09969 The Supported header field enumerates all the extensions supported by 09970 the UAC or UAS. 09971 09972 The Supported header field contains a list of option tags, described 09973 in Section 19.2, that are understood by the UAC or UAS. A UA 09974 compliant to this specification MUST only include option tags 09975 corresponding to standards-track RFCs. If empty, it means that no 09976 extensions are supported. 09977 09978 Example: 09979 09980 Supported: 100rel 09981 09982 09983 09984 20.38 Timestamp 09985 09986 09987 09988 J. Rosenberg et. al. [Page 174] 09989 Internet Draft SIP February 18, 2002 09990 09991 09992 The Timestamp header field describes when the UAC sent the request to 09993 the UAS. 09994 09995 See Section 8.2.6 for details on how to generate a response to a 09996 request that contains the header field. Although there is no 09997 normative behavior defined here that makes use of the header, it 09998 allows for extensions or SIP applications to obtain RTT estimates. 09999 10000 Example: 10001 10002 Timestamp: 54 10003 10004 10005 10006 20.39 To 10007 10008 The To header field specifies the logical recipient of the request. 10009 10010 The optional "display-name" is meant to be rendered by a human-user 10011 interface. The "tag" parameter serves as a general mechanism for 10012 dialog identification. 10013 10014 See Section 13 for details of the "tag" parameter. 10015 10016 Section 12 describes how To and From header fields are compared for 10017 the purpose of matching requests to dialogs. See Section 20.10 for 10018 the rules for parsing a display name, URI and URI parameters, and 10019 header parameters. 10020 10021 The compact form of the To header field is t. 10022 10023 The following are examples of valid To header fields: 10024 10025 To: The Operator ;tag=287447 10026 t: sip:+12125551212@server.phone2net.com 10027 10028 10029 10030 20.40 Unsupported 10031 10032 The Unsupported header field lists the features not supported by the 10033 UAS. See Section 20.32 for motivation. 10034 10035 Example: 10036 10037 Unsupported: foo 10038 10039 10040 10041 10042 10043 J. Rosenberg et. al. [Page 175] 10044 Internet Draft SIP February 18, 2002 10045 10046 10047 20.41 User-Agent 10048 10049 The User-Agent header field contains information about the UAC 10050 originating the request. The syntax and semantics are defined in 10051 [H14.43]. 10052 10053 Revealing the specific software version of the user agent might allow 10054 the user agent to become more vulnerable to attacks against software 10055 that is known to contain security holes. Implementers SHOULD make the 10056 User-Agent header field a configurable option. 10057 10058 Example: 10059 10060 User-Agent: Softphone Beta1.5 10061 10062 10063 10064 20.42 Via 10065 10066 The Via header field indicates the path taken by the request so far 10067 and indicates the path that should be followed in routing responses. 10068 The branch ID parameter in the Via header field values serves as a 10069 transaction identifier, and is used by proxies to detect loops. 10070 10071 A Via header field value contains the transport protocol used to send 10072 the message, the client's host name or network address, and possibly 10073 the port number at which it wishes to receive responses. A Via header 10074 field value can also contain parameters such as "maddr", "ttl", 10075 "received", and "branch", whose meaning and use are described in 10076 other sections. 10077 10078 Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". 10079 "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the 10080 protocol still indicates "SIP", and the transport protocol is TLS. 10081 10082 10083 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 10084 Via: SIP/2.0/UDP 128.59.16.1:5060 ;received=128.59.19.3;branch=z9hG4bK77asjd 10085 10086 10087 10088 The compact form of the Via header field is v. 10089 10090 In this example, the message originated from a multi-homed host with 10091 two addresses, 128.59.16.1 and 128.59.19.3. The sender guessed wrong 10092 as to which network interface would be used. Erlang.bell- 10093 telephone.com noticed the mismatch and added a parameter to the 10094 previous hop's Via header field value, containing the address that 10095 10096 10097 10098 J. Rosenberg et. al. [Page 176] 10099 Internet Draft SIP February 18, 2002 10100 10101 10102 the packet actually came from. 10103 10104 The host or network address and port number are not required to 10105 follow the SIP URI syntax. Specifically, LWS on either side of the 10106 ":" or "/" is allowed, as shown here: 10107 10108 10109 Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 10110 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 10111 10112 10113 10114 Even though this specification mandates that the branch parameter be 10115 present in all requests, the BNF for the header field indicates that 10116 it is optional. This allows interoperation with RFC 2543 elements, 10117 which did not have to insert the branch parameter. 10118 10119 20.43 Warning 10120 10121 The Warning header field is used to carry additional information 10122 about the status of a response. Warning header field values are sent 10123 with responses and contain a three-digit warning code, host name, and 10124 warning text. 10125 10126 The "warn-text" should be in a natural language that is most likely 10127 to be intelligible to the human user receiving the response. This 10128 decision can be based on any available knowledge, such as the 10129 location of the user, the Accept-Language field in a request, or the 10130 Content-Language field in a response. The default language is i- 10131 default [20]. 10132 10133 The currently-defined "warn-code"s are listed below, with a 10134 recommended warn-text in English and a description of their meaning. 10135 These warnings describe failures induced by the session description. 10136 The first digit of warning codes beginning with "3" indicates 10137 warnings specific to SIP. Warnings 300 through 329 are reserved for 10138 indicating problems with keywords in the session description, 330 10139 through 339 are warnings related to basic network services requested 10140 in the session description, 370 through 379 are warnings related to 10141 quantitative QoS parameters requested in the session description, and 10142 390 through 399 are miscellaneous warnings that do not fall into one 10143 of the above categories. 10144 10145 300 Incompatible network protocol: One or more network protocols 10146 contained in the session description are not available. 10147 10148 301 Incompatible network address formats: One or more network 10149 address formats contained in the session description are 10150 10151 10152 10153 J. Rosenberg et. al. [Page 177] 10154 Internet Draft SIP February 18, 2002 10155 10156 10157 not available. 10158 10159 302 Incompatible transport protocol: One or more transport 10160 protocols described in the session description are not 10161 available. 10162 10163 303 Incompatible bandwidth units: One or more bandwidth 10164 measurement units contained in the session description were 10165 not understood. 10166 10167 304 Media type not available: One or more media types contained 10168 in the session description are not available. 10169 10170 305 Incompatible media format: One or more media formats 10171 contained in the session description are not available. 10172 10173 306 Attribute not understood: One or more of the media 10174 attributes in the session description are not supported. 10175 10176 307 Session description parameter not understood: A parameter 10177 other than those listed above was not understood. 10178 10179 330 Multicast not available: The site where the user is located 10180 does not support multicast. 10181 10182 331 Unicast not available: The site where the user is located 10183 does not support unicast communication (usually due to the 10184 presence of a firewall). 10185 10186 370 Insufficient bandwidth: The bandwidth specified in the 10187 session description or defined by the media exceeds that 10188 known to be available. 10189 10190 399 Miscellaneous warning: The warning text can include 10191 arbitrary information to be presented to a human user or 10192 logged. A system receiving this warning MUST NOT take any 10193 automated action. 10194 10195 10196 1xx and 2xx have been taken by HTTP/1.1. 10197 10198 Additional "warn-code"s can be defined through IANA, as defined in 10199 Section 27.2. 10200 10201 Examples: 10202 10203 Warning: 307 isi.edu "Session parameter 'foo' not understood" 10204 Warning: 301 isi.edu "Incompatible network address type 'E.164'" 10205 10206 10207 10208 J. Rosenberg et. al. [Page 178] 10209 Internet Draft SIP February 18, 2002 10210 10211 10212 20.44 WWW-Authenticate 10213 10214 A WWW-Authenticate header field value contains an authentication 10215 challenge. The syntax for this header field and use is defined in 10216 [H14.47]. See 22.2 for further details on its usage. 10217 10218 Example: 10219 10220 WWW-Authenticate: Digest realm="atlanta.com", 10221 domain="sip:boxesbybob.com", 10222 nonce="f84f1cec41e6cbe5aea9c8e88d359", 10223 opaque="", stale=FALSE, algorithm=MD5 10224 10225 10226 10227 21 Response Codes 10228 10229 The response codes are consistent with, and extend, HTTP/1.1 response 10230 codes. Not all HTTP/1.1 response codes are appropriate, and only 10231 those that are appropriate are given here. Other HTTP/1.1 response 10232 codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. 10233 10234 21.1 Provisional 1xx 10235 10236 Provisional responses, also known as informational responses, 10237 indicate that the server contacted is performing some further action 10238 and does not yet have a definitive response. A server sends a 1xx 10239 response if it expects to take more than 200 ms to obtain a final 10240 response. Note that 1xx responses are not transmitted reliably. 10241 They never cause the client to send an ACK. Provisional (1xx) 10242 responses MAY contain message bodies, including session descriptions. 10243 10244 21.1.1 100 Trying 10245 10246 This response indicates that the request has been received by the 10247 next-hop server and that some unspecified action is being taken on 10248 behalf of this call (for example, a database is being consulted). 10249 This response, like all other provisional responses, stops 10250 retransmissions of an INVITE by a UAC. The 100 (Trying) response is 10251 different from other provisional responses, in that it is never 10252 forwarded upstream by a stateful proxy. 10253 10254 21.1.2 180 Ringing 10255 10256 The UA receiving the INVITE is trying to alert the user. This 10257 response MAY be used to initiate local ringback. 10258 10259 21.1.3 181 Call Is Being Forwarded 10260 10261 10262 10263 J. Rosenberg et. al. [Page 179] 10264 Internet Draft SIP February 18, 2002 10265 10266 10267 A server MAY use this status code to indicate that the call is being 10268 forwarded to a different set of destinations. 10269 10270 21.1.4 182 Queued 10271 10272 The called party is temporarily unavailable, but the server has 10273 decided to queue the call rather than reject it. When the callee 10274 becomes available, it will return the appropriate final status 10275 response. The reason phrase MAY give further details about the status 10276 of the call, for example, "5 calls queued; expected waiting time is 10277 15 minutes". The server MAY issue several 182 (Queued) responses to 10278 update the caller about the status of the queued call. 10279 10280 21.1.5 183 Session Progress 10281 10282 The 183 (Session Progress) response is used to convey information 10283 about the progress of the call that is not otherwise classified. The 10284 Reason-Phrase, header fields, or message body MAY be used to convey 10285 more details about the call progress. 10286 10287 21.2 Successful 2xx 10288 10289 The request was successful. 10290 10291 21.2.1 200 OK 10292 10293 The request has succeeded. The information returned with the response 10294 depends on the method used in the request. 10295 10296 21.3 Redirection 3xx 10297 10298 3xx responses give information about the user's new location, or 10299 about alternative services that might be able to satisfy the call. 10300 10301 21.3.1 300 Multiple Choices 10302 10303 The address in the request resolved to several choices, each with its 10304 own specific location, and the user (or UA) can select a preferred 10305 communication end point and redirect its request to that location. 10306 10307 The response MAY include a message body containing a list of resource 10308 characteristics and location(s) from which the user or UA can choose 10309 the one most appropriate, if allowed by the Accept request header 10310 field. However, no MIME types have been defined for this message 10311 body. 10312 10313 The choices SHOULD also be listed as Contact fields (Section 20.10). 10314 Unlike HTTP, the SIP response MAY contain several Contact fields or a 10315 10316 10317 10318 J. Rosenberg et. al. [Page 180] 10319 Internet Draft SIP February 18, 2002 10320 10321 10322 list of addresses in a Contact field. UAs MAY use the Contact header 10323 field value for automatic redirection or MAY ask the user to confirm 10324 a choice. However, this specification does not define any standard 10325 for such automatic selection. 10326 10327 10328 This status response is appropriate if the callee can be 10329 reached at several different locations and the server 10330 cannot or prefers not to proxy the request. 10331 10332 21.3.2 301 Moved Permanently 10333 10334 The user can no longer be found at the address in the Request-URI, 10335 and the requesting client SHOULD retry at the new address given by 10336 the Contact header field (Section 20.10). The requestor SHOULD update 10337 any local directories, address books, and user location caches with 10338 this new value and redirect future requests to the address(es) 10339 listed. 10340 10341 21.3.3 302 Moved Temporarily 10342 10343 The requesting client SHOULD retry the request at the new address(es) 10344 given by the Contact header field (Section 20.10). The Request-URI 10345 of the new request uses the value of the Contact header field in the 10346 response. 10347 10348 The duration of the validity of the Contact URI can be indicated 10349 through an Expires (Section 20.19) header field or an expires 10350 parameter in the Contact header field. Both proxies and UAs MAY cache 10351 this URI for the duration of the expiration time. If there is no 10352 explicit expiration time, the address is only valid once for 10353 recursing, and MUST NOT be cached for future transactions. 10354 10355 If the URI cached from the Contact header field fails, the Request- 10356 URI from the redirected request MAY be tried again a single time. 10357 10358 10359 The temporary URI may have become out-of-date sooner than 10360 the expiration time, and a new temporary URI may be 10361 available. 10362 10363 21.3.4 305 Use Proxy 10364 10365 The requested resource MUST be accessed through the proxy given by 10366 the Contact field. The Contact field gives the URI of the proxy. The 10367 recipient is expected to repeat this single request via the proxy. 10368 305 (Use Proxy) responses MUST only be generated by UASs. 10369 10370 10371 10372 10373 J. Rosenberg et. al. [Page 181] 10374 Internet Draft SIP February 18, 2002 10375 10376 10377 21.3.5 380 Alternative Service 10378 10379 The call was not successful, but alternative services are possible. 10380 The alternative services are described in the message body of the 10381 response. Formats for such bodies are not defined here, and may be 10382 the subject of future standardization. 10383 10384 21.4 Request Failure 4xx 10385 10386 4xx responses are definite failure responses from a particular 10387 server. The client SHOULD NOT retry the same request without 10388 modification (for example, adding appropriate authorization). 10389 However, the same request to a different server might be successful. 10390 10391 21.4.1 400 Bad Request 10392 10393 The request could not be understood due to malformed syntax. The 10394 Reason-Phrase SHOULD identify the syntax problem in more detail, for 10395 example, "Missing Call-ID header field". 10396 10397 21.4.2 401 Unauthorized 10398 10399 The request requires user authentication. This response is issued by 10400 UASs and registrars, while 407 (Proxy Authentication Required) is 10401 used by proxy servers. 10402 10403 21.4.3 402 Payment Required 10404 10405 Reserved for future use. 10406 10407 21.4.4 403 Forbidden 10408 10409 The server understood the request, but is refusing to fulfill it. 10410 Authorization will not help, and the request SHOULD NOT be repeated. 10411 10412 21.4.5 404 Not Found 10413 10414 The server has definitive information that the user does not exist at 10415 the domain specified in the Request-URI. This status is also returned 10416 if the domain in the Request-URI does not match any of the domains 10417 handled by the recipient of the request. 10418 10419 21.4.6 405 Method Not Allowed 10420 10421 The method specified in the Request-Line is understood, but not 10422 allowed for the address identified by the Request-URI. 10423 10424 The response MUST include an Allow header field containing a list of 10425 10426 10427 10428 J. Rosenberg et. al. [Page 182] 10429 Internet Draft SIP February 18, 2002 10430 10431 10432 valid methods for the indicated address. 10433 10434 21.4.7 406 Not Acceptable 10435 10436 The resource identified by the request is only capable of generating 10437 response entities that have content characteristics not acceptable 10438 according to the Accept header fields sent in the request. 10439 10440 21.4.8 407 Proxy Authentication Required 10441 10442 This code is similar to 401 (Unauthorized), but indicates that the 10443 client MUST first authenticate itself with the proxy. SIP access 10444 authentication is explained in Sections 26 and 22.3. 10445 10446 This status code can be used for applications where access to the 10447 communication channel (for example, a telephony gateway) rather than 10448 the callee requires authentication. 10449 10450 21.4.9 408 Request Timeout 10451 10452 The server could not produce a response within a suitable amount of 10453 time, for example, if it could not determine the location of the user 10454 in time. The client MAY repeat the request without modifications at 10455 any later time. 10456 10457 21.4.10 410 Gone 10458 10459 The requested resource is no longer available at the server and no 10460 forwarding address is known. This condition is expected to be 10461 considered permanent. If the server does not know, or has no facility 10462 to determine, whether or not the condition is permanent, the status 10463 code 404 (Not Found) SHOULD be used instead. 10464 10465 21.4.11 413 Request Entity Too Large 10466 10467 The server is refusing to process a request because the request 10468 entity-body is larger than the server is willing or able to process. 10469 The server MAY close the connection to prevent the client from 10470 continuing the request. 10471 10472 If the condition is temporary, the server SHOULD include a Retry- 10473 After header field to indicate that it is temporary and after what 10474 time the client MAY try again. 10475 10476 21.4.12 414 Request-URI Too Long 10477 10478 The server is refusing to service the request because the Request-URI 10479 is longer than the server is willing to interpret. 10480 10481 10482 10483 J. Rosenberg et. al. [Page 183] 10484 Internet Draft SIP February 18, 2002 10485 10486 10487 21.4.13 415 Unsupported Media Type 10488 10489 The server is refusing to service the request because the message 10490 body of the request is in a format not supported by the server for 10491 the requested method. The server SHOULD return a list of acceptable 10492 formats using the Accept, Accept-Encoding and Accept-Language header 10493 fields. UAC processing of this response is described in Section 10494 8.1.3.5. 10495 10496 21.4.14 416 Unsupported URI Scheme 10497 10498 The server cannot process the request because the scheme of the URI 10499 in the Request-URI is unknown to the server. Client processing of 10500 this response is described in Section 8.1.3.5. 10501 10502 21.4.15 420 Bad Extension 10503 10504 The server did not understand the protocol extension specified in a 10505 Proxy-Require (Section 20.29) or Require (Section 20.32) header 10506 field. The server SHOULD include a list of the unsupported extensions 10507 in an Unsupported header field in the response. UAC processing of 10508 this response is described in Section 8.1.3.5. 10509 10510 21.4.16 421 Extension Required 10511 10512 The UAS needs a particular extension to process the request, but this 10513 extension is not listed in a Supported header field in the request. 10514 Responses with this status code MUST contain a Require header field 10515 listing the required extensions. 10516 10517 A UAS SHOULD NOT use this response unless it truly cannot provide any 10518 useful service to the client. Instead, if a desirable extension is 10519 not listed in the Supported header field, servers SHOULD process the 10520 request using baseline SIP capabilities and any extensions supported 10521 by the client. 10522 10523 21.4.17 423 Interval Too Brief 10524 10525 The server is rejecting the request because the expiration time of 10526 the resource refreshed by the request is too short. This response 10527 can be used by a registrar to reject a registration whose Contact 10528 header field expiration time was too small. The use of this response 10529 and the related Min-Expires header field are described in Sections 10530 10.2.8, 10.3, and 20.23. 10531 10532 21.4.18 480 Temporarily Unavailable 10533 10534 The callee's end system was contacted successfully but the callee is 10535 10536 10537 10538 J. Rosenberg et. al. [Page 184] 10539 Internet Draft SIP February 18, 2002 10540 10541 10542 currently unavailable (for example, is not logged in, logged in but 10543 in a state that precludes communication with the callee, or has 10544 activated the "do not disturb" feature). The response MAY indicate a 10545 better time to call in the Retry-After header field. The user could 10546 also be available elsewhere (unbeknownst to this server). The reason 10547 phrase SHOULD indicate a more precise cause as to why the callee is 10548 unavailable. This value SHOULD be settable by the UA. Status 486 10549 (Busy Here) MAY be used to more precisely indicate a particular 10550 reason for the call failure. 10551 10552 This status is also returned by a redirect or proxy server that 10553 recognizes the user identified by the Request-URI, but does not 10554 currently have a valid forwarding location for that user. 10555 10556 21.4.19 481 Call/Transaction Does Not Exist 10557 10558 This status indicates that the UAS received a request that does not 10559 match any existing dialog or transaction. 10560 10561 21.4.20 482 Loop Detected 10562 10563 The server has detected a loop (Section 16.3 Item 4). 10564 10565 21.4.21 483 Too Many Hops 10566 10567 The server received a request that contains a Max-Forwards (Section 10568 20.22) header field with the value zero. 10569 10570 21.4.22 484 Address Incomplete 10571 10572 The server received a request with a Request-URI that was incomplete. 10573 Additional information SHOULD be provided in the reason phrase. 10574 10575 10576 This status code allows overlapped dialing. With overlapped 10577 dialing, the client does not know the length of the dialing 10578 string. It sends strings of increasing lengths, prompting 10579 the user for more input, until it no longer receives a 484 10580 (Address Incomplete) status response. 10581 10582 21.4.23 485 Ambiguous 10583 10584 The Request-URI was ambiguous. The response MAY contain a listing of 10585 possible unambiguous addresses in Contact header fields. Revealing 10586 alternatives can infringe on privacy of the user or the organization. 10587 It MUST be possible to configure a server to respond with status 404 10588 (Not Found) or to suppress the listing of possible choices for 10589 ambiguous Request-URIs. 10590 10591 10592 10593 J. Rosenberg et. al. [Page 185] 10594 Internet Draft SIP February 18, 2002 10595 10596 10597 Example response to a request with the Request-URI 10598 sip:lee@example.com : 10599 10600 SIP/2.0 485 Ambiguous 10601 Contact: Carol Lee 10602 Contact: Ping Lee 10603 Contact: Lee M. Foote 10604 10605 10606 10607 10608 Some email and voice mail systems provide this 10609 functionality. A status code separate from 3xx is used 10610 since the semantics are different: for 300, it is assumed 10611 that the same person or service will be reached by the 10612 choices provided. While an automated choice or sequential 10613 search makes sense for a 3xx response, user intervention is 10614 required for a 485 (Ambiguous) response. 10615 10616 21.4.24 486 Busy Here 10617 10618 The callee's end system was contacted successfully, but the callee is 10619 currently not willing or able to take additional calls at this end 10620 system. The response MAY indicate a better time to call in the 10621 Retry-After header field. The user could also be available elsewhere, 10622 such as through a voice mail service. Status 600 (Busy Everywhere) 10623 SHOULD be used if the client knows that no other end system will be 10624 able to accept this call. 10625 10626 21.4.25 487 Request Terminated 10627 10628 The request was terminated by a BYE or CANCEL request. This response 10629 is never returned for a CANCEL request itself. 10630 10631 21.4.26 488 Not Acceptable Here 10632 10633 The response has the same meaning as 606 (Not Acceptable), but only 10634 applies to the specific resource addressed by the Request-URI and the 10635 request may succeed elsewhere. 10636 10637 A message body containing a description of media capabilities MAY be 10638 present in the response, which is formatted according to the Accept 10639 header field in the INVITE (or application/sdp if not present), the 10640 same as a message body in a 200 (OK) response to an OPTIONS request. 10641 10642 21.4.27 491 Request Pending 10643 10644 The request was received by a UAS that had a pending request within 10645 10646 10647 10648 J. Rosenberg et. al. [Page 186] 10649 Internet Draft SIP February 18, 2002 10650 10651 10652 the same dialog. Section 14.2 describes how such "glare" situations 10653 are resolved. 10654 10655 21.4.28 493 Undecipherable 10656 10657 The request was received by a UAS that contained an encrypted MIME 10658 body for which the recipient does not possess or will not provide an 10659 appropriate decryption key. This response MAY have a single body 10660 containing an appropriate public key that should be used to encrypt 10661 MIME bodies sent to this UA. Details of the usage of this response 10662 code can be found in Section 23.2. 10663 10664 21.5 Server Failure 5xx 10665 10666 5xx responses are failure responses given when a server itself has 10667 erred. 10668 10669 21.5.1 500 Server Internal Error 10670 10671 The server encountered an unexpected condition that prevented it from 10672 fulfilling the request. The client MAY display the specific error 10673 condition and MAY retry the request after several seconds. 10674 10675 If the condition is temporary, the server MAY indicate when the 10676 client may retry the request using the Retry-After header field. 10677 10678 21.5.2 501 Not Implemented 10679 10680 The server does not support the functionality required to fulfill the 10681 request. This is the appropriate response when a UAS does not 10682 recognize the request method and is not capable of supporting it for 10683 any user. (Proxies forward all requests regardless of method.) 10684 10685 Note that a 405 (Method Not Allowed) is sent when the server 10686 recognizes the request method, but that method is not allowed or 10687 supported. 10688 10689 21.5.3 502 Bad Gateway 10690 10691 The server, while acting as a gateway or proxy, received an invalid 10692 response from the downstream server it accessed in attempting to 10693 fulfill the request. 10694 10695 21.5.4 503 Service Unavailable 10696 10697 The server is temporarily unable to process the request due to a 10698 temporary overloading or maintenance of the server. The server MAY 10699 indicate when the client should retry the request in a Retry-After 10700 10701 10702 10703 J. Rosenberg et. al. [Page 187] 10704 Internet Draft SIP February 18, 2002 10705 10706 10707 header field. If no Retry-After is given, the client MUST act as if 10708 it had received a 500 (Server Internal Error) response. 10709 10710 A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD 10711 attempt to forward the request to an alternate server. It SHOULD NOT 10712 forward any other requests to that server for the duration specified 10713 in the Retry-After header field, if present. 10714 10715 Servers MAY refuse the connection or drop the request instead of 10716 responding with 503 (Service Unavailable). 10717 10718 21.5.5 504 Server Time-out 10719 10720 The server did not receive a timely response from an external server 10721 it accessed in attempting to process the request. 408 (Request 10722 Timeout) should be used instead if there was no response within the 10723 period specified in the Expires header field from the upstream 10724 server. 10725 10726 21.5.6 505 Version Not Supported 10727 10728 The server does not support, or refuses to support, the SIP protocol 10729 version that was used in the request. The server is indicating that 10730 it is unable or unwilling to complete the request using the same 10731 major version as the client, other than with this error message. 10732 10733 21.5.7 513 Message Too Large 10734 10735 The server was unable to process the request since the message length 10736 exceeded its capabilities. 10737 10738 21.6 Global Failures 6xx 10739 10740 6xx responses indicate that a server has definitive information about 10741 a particular user, not just the particular instance indicated in the 10742 Request-URI. 10743 10744 21.6.1 600 Busy Everywhere 10745 10746 The callee's end system was contacted successfully but the callee is 10747 busy and does not wish to take the call at this time. The response 10748 MAY indicate a better time to call in the Retry-After header field. 10749 If the callee does not wish to reveal the reason for declining the 10750 call, the callee uses status code 603 (Decline) instead. This status 10751 response is returned only if the client knows that no other end point 10752 (such as a voice mail system) will answer the request. Otherwise, 486 10753 (Busy Here) should be returned. 10754 10755 10756 10757 10758 J. Rosenberg et. al. [Page 188] 10759 Internet Draft SIP February 18, 2002 10760 10761 10762 21.6.2 603 Decline 10763 10764 The callee's machine was successfully contacted but the user 10765 explicitly does not wish to or cannot participate. The response MAY 10766 indicate a better time to call in the Retry-After header field. This 10767 status response is returned only if the client knows that no other 10768 end point will answer the request. 10769 10770 21.6.3 604 Does Not Exist Anywhere 10771 10772 The server has authoritative information that the user indicated in 10773 the Request-URI does not exist anywhere. 10774 10775 21.6.4 606 Not Acceptable 10776 10777 The user's agent was contacted successfully but some aspects of the 10778 session description such as the requested media, bandwidth, or 10779 addressing style were not acceptable. 10780 10781 A 606 (Not Acceptable) response means that the user wishes to 10782 communicate, but cannot adequately support the session described. The 10783 606 (Not Acceptable) response MAY contain a list of reasons in a 10784 Warning header field describing why the session described cannot be 10785 supported. Warning reason codes are listed in Section 20.43. 10786 10787 A message body containing a description of media capabilities MAY be 10788 present in the response, which is formatted according to the Accept 10789 header field in the INVITE (or application/sdp if not present), the 10790 same as a message body in a 200 (OK) response to an OPTIONS request. 10791 10792 It is hoped that negotiation will not frequently be needed, and when 10793 a new user is being invited to join an already existing conference, 10794 negotiation may not be possible. It is up to the invitation initiator 10795 to decide whether or not to act on a 606 (Not Acceptable) response. 10796 10797 This status response is returned only if the client knows that no 10798 other end point will answer the request. 10799 10800 22 Usage of HTTP Authentication 10801 10802 SIP provides a stateless, challenge-based mechanism for 10803 authentication that is based on authentication in HTTP. Any time that 10804 a proxy server or UA receives a request (with the exceptions given in 10805 Section 22.1), it MAY challenge the initiator of the request to 10806 provide assurance of its identity. Once the originator has been 10807 identified, the recipient of the request SHOULD ascertain whether or 10808 not this user is authorized to make the request in question. No 10809 authorization systems are recommended or discussed in this document. 10810 10811 10812 10813 J. Rosenberg et. al. [Page 189] 10814 Internet Draft SIP February 18, 2002 10815 10816 10817 The "Digest" authentication mechanism described in this section 10818 provides message authentication and replay protection only, without 10819 message integrity or confidentiality. Protective measures above and 10820 beyond those provided by Digest need to be taken to prevent active 10821 attackers from modifying SIP requests and responses. 10822 10823 Note that due to its weak security, the usage of "Basic" 10824 authentication has been deprecated. Servers MUST NOT accept 10825 credentials using the "Basic" authorization scheme, and servers also 10826 MUST NOT challenge with "Basic". This is a change from RFC 2543. 10827 10828 22.1 Framework 10829 10830 The framework for SIP authentication closely parallels that of HTTP 10831 (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, 10832 challenge, realm, realm-value, and credentials is identical (although 10833 the usage of "Basic" as a scheme is not permitted). In SIP, a UAS 10834 uses the 401 (Unauthorized) response to challenge the identity of a 10835 UAC. Additionally, registrars and redirect servers MAY make use of 10836 401 (Unauthorized) responses for authentication, but proxies MUST 10837 NOT, and instead MAY use the 407 (Proxy Authentication Required) 10838 response. The requirements for inclusion of the Proxy-Authenticate, 10839 Proxy-Authorization, WWW-Authenticate, and Authorization in the 10840 various messages are identical to those described in RFC 2617 [17]. 10841 10842 Since SIP does not have the concept of a canonical root URL, the 10843 notion of protection spaces is interpreted differently in SIP. The 10844 realm string alone defines the protection domain. This is a change 10845 from RFC 2543, in which the Request-URI and the realm together 10846 defined the protection domain. 10847 10848 10849 This previous definition of protection domain caused some 10850 amount of confusion since the Request-URI sent by the UAC 10851 and the Request-URI received by the challenging server 10852 might be different, and indeed the final form of the 10853 Request-URI might not be known to the UAC. Also, the 10854 previous definition depended on the presence of a SIP URI 10855 in the Request-URI and seemed to rule out alternative URI 10856 schemes (for example, the tel URL). 10857 10858 Operators of user agents or proxy servers that will authenticate 10859 received requests MUST adhere to the following guidelines for 10860 creation of a realm string for their server: 10861 10862 o Realm strings MUST be globally unique. It is RECOMMENDED that 10863 a realm string contain a hostname or domain name, following 10864 the recommendation in Section 3.2.1 of RFC 2617 [17]. 10865 10866 10867 10868 J. Rosenberg et. al. [Page 190] 10869 Internet Draft SIP February 18, 2002 10870 10871 10872 o Realm strings SHOULD present a human-readable identifier that 10873 can be rendered to a user. 10874 10875 For example: 10876 10877 10878 INVITE sip:bob@biloxi.com SIP/2.0 10879 Authorization: Digest realm="biloxi.com", <...> 10880 10881 10882 10883 Generally, SIP authentication is meaningful for a specific realm, a 10884 protection domain. Thus, for Digest authentication, each such 10885 protection domain has its own set of usernames and passwords. If a 10886 server does not require authentication for a particular request, it 10887 MAY accept a default username, "anonymous", which has no password 10888 (password of ""). Similarly, UACs representing many users, such as 10889 PSTN gateways, MAY have their own device-specific username and 10890 password, rather than accounts for particular users, for their realm. 10891 10892 While a server can legitimately challenge most SIP requests, there 10893 are two requests defined by this document that require special 10894 handling for authentication: ACK and CANCEL. 10895 10896 Under an authentication scheme that uses responses to carry values 10897 used to compute nonces (such as Digest), some problems come up for 10898 any requests that take no response, including ACK. For this reason, 10899 any credentials in the INVITE that were accepted by a server MUST be 10900 accepted by that server for the ACK. UACs creating an ACK message 10901 will duplicate all of the Authorization and Proxy-Authorization 10902 header field values that appeared in the INVITE to which the ACK 10903 corresponds. Servers MUST NOT attempt to challenge an ACK. 10904 10905 Although the CANCEL method does take a response (a 2xx), servers MUST 10906 NOT attempt to challenge CANCEL requests since these requests cannot 10907 be resubmitted. Generally, a CANCEL request SHOULD be accepted by a 10908 server if it comes from the same hop that sent the request being 10909 canceled (provided that some sort of transport or network layer 10910 security association, as described in Section 26.2.1, is in place). 10911 10912 When a UAC receives a challenge, it SHOULD render to the user the 10913 contents of the "realm" parameter in the challenge (which appears in 10914 either a WWW-Authenticate header field or Proxy-Authenticate header 10915 field) if the UAC device does not already know of a credential for 10916 the realm in question. A service provider that pre-configures UAs 10917 with credentials for its realm should be aware that users will not 10918 have the opportunity to present their own credentials for this realm 10919 when challenged at a pre-configured device. 10920 10921 10922 10923 J. Rosenberg et. al. [Page 191] 10924 Internet Draft SIP February 18, 2002 10925 10926 10927 Finally, note that even if a UAC can locate credentials that are 10928 associated with the proper realm, the potential exists that these 10929 credentials may no longer be valid or that the challenging server 10930 will not accept these credentials for whatever reason (especially 10931 when "anonymous" with no password is submitted). In this instance a 10932 server may repeat its challenge, or it may respond with a 403 10933 Forbidden. A UAC MUST NOT re-attempt requests with the credentials 10934 that have just been rejected (though the request may be are retried 10935 if the nonce was stale). 10936 10937 22.2 User-to-User Authentication 10938 10939 When a UAS receives a request from a UAC, the UAS MAY authenticate 10940 the originator before the request is processed. If no credentials (in 10941 the Authorization header field) are provided in the request, the UAS 10942 can challenge the originator to provide credentials by rejecting the 10943 request with a 401 (Unauthorized) status code. 10944 10945 The WWW-Authenticate response-header field MUST be included in 401 10946 (Unauthorized) response messages. The field value consists of at 10947 least one challenge that indicates the authentication scheme(s) and 10948 parameters applicable to the realm. See [H14.47] for a definition of 10949 the syntax. 10950 10951 An example of the WWW-Authenticate header field in a 401 challenge 10952 is: 10953 10954 10955 WWW-Authenticate: Digest 10956 realm="biloxi.com", 10957 qop="auth,auth-int", 10958 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 10959 opaque="5ccc069c403ebaf9f0171e9517f40e41" 10960 10961 10962 10963 When the originating UAC receives the 401 (Unauthorized), it SHOULD, 10964 if it is able, re-originate the request with the proper credentials. 10965 The UAC may require input from the originating user before 10966 proceeding. Once authentication credentials have been supplied 10967 (either directly by the user, or discovered in an internal keyring), 10968 UAs SHOULD cache the credentials for a given value of the To header 10969 field and "realm" and attempt to re-use these values on the next 10970 request for that destination. UAs MAY cache credentials in any way 10971 they would like. 10972 10973 If no credentials for a realm can be located, UACs MAY attempt to 10974 retry the request with a username of "anonymous" and no password (a 10975 10976 10977 10978 J. Rosenberg et. al. [Page 192] 10979 Internet Draft SIP February 18, 2002 10980 10981 10982 password of ""). 10983 10984 Once credentials have been located, any UA that wishes to 10985 authenticate itself with a UAS or registrar -- usually, but not 10986 necessarily, after receiving a 401 (Unauthorized) response -- MAY do 10987 so by including an Authorization header field with the request. The 10988 Authorization field value consists of credentials containing the 10989 authentication information of the UA for the realm of the resource 10990 being requested as well as parameters required in support of 10991 authentication and replay protection. 10992 10993 An example of the Authorization header field is: 10994 10995 10996 Authorization: Digest username="bob", 10997 realm="biloxi.com", 10998 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 10999 uri="sip:bob@biloxi.com", 11000 qop=auth, 11001 nc=00000001, 11002 cnonce="0a4f113b", 11003 response="6629fae49393a05397450978507c4ef1", 11004 opaque="5ccc069c403ebaf9f0171e9517f40e41" 11005 11006 11007 11008 11009 When a UAC resubmits a request with its credentials after receiving a 11010 401 (Unauthorized) or 407 (Proxy Authentication Required) response, 11011 it MUST increment the CSeq header field value as it would normally 11012 when sending an updated request. 11013 11014 22.3 Proxy-to-User Authentication 11015 11016 Similarly, when a UAC sends a request to a proxy server, the proxy 11017 server MAY authenticate the originator before the request is 11018 processed. If no credentials (in the Proxy-Authorization header 11019 field) are provided in the request, the proxy can challenge the 11020 originator to provide credentials by rejecting the request with a 407 11021 (Proxy Authentication Required) status code. The proxy MUST populate 11022 the 407 (Proxy Authentication Required) message with a Proxy- 11023 Authenticate header field value applicable to the proxy for the 11024 requested resource. 11025 11026 The use of Proxy-Authentication and Proxy-Authorization parallel that 11027 described in [17], with one difference. Proxies MUST NOT add values 11028 to the Proxy-Authorization header field. All 407 (Proxy 11029 Authentication Required) responses MUST be forwarded upstream toward 11030 11031 11032 11033 J. Rosenberg et. al. [Page 193] 11034 Internet Draft SIP February 18, 2002 11035 11036 11037 the UAC following the procedures for any other response. It is the 11038 UAC's responsibility to add the Proxy-Authorization header field 11039 value containing credentials for the realm of the proxy that has 11040 asked for authentication. 11041 11042 11043 If a proxy were to resubmit a request adding a Proxy- 11044 Authorization header field value, it would need to 11045 increment the CSeq in the new request. However, this would 11046 cause the UAC that submitted the original request to 11047 discard a response from the UAS, as the CSeq value would be 11048 different. 11049 11050 When the originating UAC receives the 407 (Proxy Authentication 11051 Required) it SHOULD, if it is able, re-originate the request with the 11052 proper credentials. It should follow the same procedures for the 11053 display of the "realm" parameter that are given above for responding 11054 to 401. 11055 11056 If no credentials for a realm can be located, UACs MAY attempt to 11057 retry the request with a username of "anonymous" and no password (a 11058 password of ""). 11059 11060 The UAC SHOULD also cache the credentials used in the re-originated 11061 request. 11062 11063 The following rule is RECOMMENDED for proxy credential caching: 11064 11065 If a UA receives a Proxy-Authenticate header field value in a 401/407 11066 response to a request with a particular Call-ID, it should 11067 incorporate credentials for that realm in all subsequent requests 11068 that contain the same Call-ID. These credentials MUST NOT be cached 11069 across dialogs; however, if a UA is configured with the realm of its 11070 local outbound proxy, when one exists, then the UA MAY cache 11071 credentials for that realm across dialogs. Note that this does mean a 11072 future request in a dialog could contain credentials that are not 11073 needed by any proxy along the Route header path. 11074 11075 Any UA that wishes to authenticate itself to a proxy server -- 11076 usually, but not necessarily, after receiving a 407 (Proxy 11077 Authentication Required) response -- MAY do so by including a Proxy- 11078 Authorization header field value with the request. The Proxy- 11079 Authorization request-header field allows the client to identify 11080 itself (or its user) to a proxy that requires authentication. The 11081 Proxy-Authorization header field value consists of credentials 11082 containing the authentication information of the UA for the proxy 11083 and/or realm of the resource being requested. 11084 11085 11086 11087 11088 J. Rosenberg et. al. [Page 194] 11089 Internet Draft SIP February 18, 2002 11090 11091 11092 A Proxy-Authorization header field value applies only to the proxy 11093 whose realm is identified in the "realm" parameter (this proxy may 11094 previously have demanded authentication using the Proxy-Authenticate 11095 field). When multiple proxies are used in a chain, a Proxy- 11096 Authorization header field value MUST NOT be consumed by any proxy 11097 whose realm does not match the "realm" parameter specified in that 11098 value. 11099 11100 Note that if an authentication scheme that does not support realms is 11101 used in the Proxy-Authorization header field, a proxy server MUST 11102 attempt to parse all Proxy-Authorization header field values to 11103 determine whether one of them has what the proxy server considers to 11104 be valid credentials. Because this is potentially very time-consuming 11105 in large networks, proxy servers SHOULD use an authentication scheme 11106 that supports realms in the Proxy-Authorization header field. 11107 11108 If a request is forked (as described in Section 16.7), various proxy 11109 servers and/or UAs may wish to challenge the UAC. In this case, the 11110 forking proxy server is responsible for aggregating these challenges 11111 into a single response. Each WWW-Authenticate and Proxy-Authenticate 11112 value received in responses to the forked request MUST be placed into 11113 the single response that is sent by the forking proxy to the UA; the 11114 ordering of these header field values is not significant. 11115 11116 11117 When a proxy server issues a challenge in response to a 11118 request, it will not proxy the request until the UAC has 11119 retried the request with valid credentials. A forking proxy 11120 may forward a request simultaneously to multiple proxy 11121 servers that require authentication, each of which in turn 11122 will not forward the request until the originating UAC has 11123 authenticated itself in their respective realm. If the UAC 11124 does not provide credentials for each challenge, then the 11125 proxy servers that issued the challenges will not forward 11126 requests to the UA where the destination user might be 11127 located, and therefore, the virtues of forking are largely 11128 lost. 11129 11130 When resubmitting its request in response to a 401 (Unauthorized) or 11131 407 (Proxy Authentication Required) that contains multiple 11132 challenges, a UAC MAY include an Authorization value for each WWW- 11133 Authenticate value and a Proxy-Authorization value for each Proxy- 11134 Authenticate value for which the UAC wishes to supply a credential. 11135 As noted above, multiple credentials in a request SHOULD be 11136 differentiated by the "realm" parameter. 11137 11138 It is possible for multiple challenges associated with the same realm 11139 to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication 11140 11141 11142 11143 J. Rosenberg et. al. [Page 195] 11144 Internet Draft SIP February 18, 2002 11145 11146 11147 Required). This can occur, for example, when multiple proxies within 11148 the same administrative domain, which use a common realm, are reached 11149 by a forking request. When it retries a request, a UAC MAY therefore 11150 supply multiple credentials in Authorization or Proxy-Authorization 11151 header fields with the same "realm" parameter value. The same 11152 credentials SHOULD be used for the same realm. 11153 11154 See [H14.34] for a definition of the syntax of Proxy-Authentication 11155 and Proxy-Authorization. 11156 11157 22.4 The Digest Authentication Scheme 11158 11159 This section describes the modifications and clarifications required 11160 to apply the HTTP Digest authentication scheme to SIP. The SIP scheme 11161 usage is almost completely identical to that for HTTP [17]. 11162 11163 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [38], 11164 SIP servers supporting RFC 2617 MUST ensure they are backwards 11165 compatible with RFC 2069. Procedures for this backwards compatibility 11166 are specified in RFC 2617. Note, however, that SIP servers MUST NOT 11167 accept or request Basic authentication. 11168 11169 The rules for Digest authentication follow those defined in [17], 11170 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following 11171 differences: 11172 11173 1. The URI included in the challenge has the following BNF: 11174 11175 11176 URI = SIP-URI / SIPS-URI 11177 11178 11179 2. The BNF in RFC 2617 has an error in that the 'uri' 11180 parameter of the Authorization header field for HTTP Digest 11181 authentication is not enclosed in quotation marks. (The 11182 example in Section 3.5 of RFC 2617 is correct.) For SIP, 11183 the 'uri' MUST be enclosed in quotation marks. 11184 11185 3. The BNF for digest-uri-value is: 11186 11187 11188 digest-uri-value = Request-URI ; as defined in 11189 Section 25 11190 11191 11192 4. The example procedure for choosing a nonce based on Etag 11193 does not work for SIP. 11194 11195 11196 11197 11198 J. Rosenberg et. al. [Page 196] 11199 Internet Draft SIP February 18, 2002 11200 11201 11202 5. The text in RFC 2617 [17] regarding cache operation does 11203 not apply to SIP. 11204 11205 6. RFC 2617 [17] requires that a server check that the URI in 11206 the request line and the URI included in the Authorization 11207 header field point to the same resource. In a SIP context, 11208 these two URIs may refer to different users, due to 11209 forwarding at some proxy. Therefore, in SIP, a server MAY 11210 check that the Request-URI in the Authorization header 11211 field value corresponds to a user for whom the server is 11212 willing to accept forwarded or direct requests, but it is 11213 not necessarily a failure if the two fields are not 11214 equivalent. 11215 11216 7. As a clarification to the calculation of the A2 value for 11217 message integrity assurance in the Digest authentication 11218 scheme, implementers should assume, when the entity-body is 11219 empty (that is, when SIP messages have no body) that the 11220 hash of the entity-body resolves to the MD5 hash of an 11221 empty string, or: 11222 11223 11224 11225 H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e" 11226 11227 11228 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an 11229 Authorization (and by extension Proxy-Authorization) header 11230 field if no qop directive has been sent. Therefore, any 11231 algorithms that have a dependency on the cnonce (including 11232 "MD5-Sess") require that the qop directive be sent. Use of 11233 the "qop" parameter is optional in RFC 2617 for the 11234 purposes of backwards compatibility with RFC 2069; since 11235 RFC 2543 was based on RFC 2069, the "qop" parameter must 11236 unfortunately remain optional for clients and servers to 11237 receive. However, servers MUST always send a "qop" 11238 parameter in WWW-Authenticate and Proxy-Authenticate header 11239 field values. If a client receives a "qop" parameter in a 11240 challenge header field, it MUST send the "qop" parameter in 11241 any resulting authorization header field. 11242 11243 RFC 2543 did not allow usage of the Authentication-Info header field 11244 (it effectively used RFC 2069). However, we now allow usage of this 11245 header field, since it provides integrity checks over the bodies and 11246 provides mutual authentication. RFC 2617 [17] defines mechanisms for 11247 backwards compatibility using the qop attribute in the request. These 11248 mechanisms MUST be used by a server to determine if the client 11249 supports the new mechanisms in RFC 2617 that were not specified in 11250 11251 11252 11253 J. Rosenberg et. al. [Page 197] 11254 Internet Draft SIP February 18, 2002 11255 11256 11257 RFC 2069. 11258 11259 23 S/MIME 11260 11261 SIP messages carry MIME bodies and the MIME standard includes 11262 mechanisms for securing MIME contents to ensure both integrity and 11263 confidentiality (including the 'multipart/signed' and 11264 'application/pkcs7-mime' MIME types, see RFC 1847 [21], RFC 2630 [22] 11265 and RFC 2633 [23]). Implementers should note, however, that there may 11266 be rare network intermediaries (not typical proxy servers) that rely 11267 on viewing or modifying the bodies of SIP messages (especially SDP), 11268 and that secure MIME may prevent these sorts of intermediaries from 11269 functioning. 11270 11271 This applies particularly to certain types of firewalls. 11272 11273 11274 The PGP mechanism for encrypting the header fields and 11275 bodies of SIP messages described in RFC 2543 has been 11276 deprecated. 11277 11278 23.1 S/MIME Certificates 11279 11280 The certificates that are used to identify an end-user for the 11281 purposes of S/MIME differ from those used by servers in one important 11282 respect - rather than asserting that the identity of the holder 11283 corresponds to a particular hostname, these certificates assert that 11284 the holder is identified by an end-user address. This address is 11285 composed of the concatenation of the "userinfo" "@" and "domainname" 11286 portions of a SIP or SIPS URI (in other words, an email address of 11287 the form "bob@biloxi.com"), most commonly corresponding to a user's 11288 address-of-record. 11289 11290 These certificates are also associated with keys that are used to 11291 sign or encrypt bodies of SIP messages. Bodies are signed with the 11292 private key of the sender (who may include their public key with the 11293 message as appropriate), but bodies are encrypted with the public key 11294 of the intended recipient. Obviously, senders must have foreknowledge 11295 of the public key of recipients in order to encrypt message bodies. 11296 Public keys can be stored within a UA on a virtual keyring. 11297 11298 Each user agent that supports S/MIME MUST contain a keyring 11299 specifically for end-users' certificates. This keyring should map 11300 between addresses of record and corresponding certificates. Over 11301 time, users SHOULD use the same certificate when they populate the 11302 originating URI of signaling (the From header field) with the same 11303 address-of-record. 11304 11305 11306 11307 11308 J. Rosenberg et. al. [Page 198] 11309 Internet Draft SIP February 18, 2002 11310 11311 11312 Any mechanisms depending on the existence of end-user certificates 11313 are seriously limited in that there is virtually no consolidated 11314 authority today that provides certificates for end-user applications. 11315 However, users SHOULD acquire certificates from known public 11316 certificate authorities. As an alternative, users MAY create self- 11317 signed certificates. The implications of self-signed certificates are 11318 explored further in Section 26.4.2. Implementations may also use 11319 pre-configured certificates in deployments in which a previous trust 11320 relationship exists between all SIP entities. 11321 11322 Above and beyond the problem of acquiring an end-user certificate, 11323 there are few well-known centralized directories that distribute 11324 end-user certificates. However, the holder of a certificate SHOULD 11325 publish their certificate in any public directories as appropriate. 11326 Similarly, UACs SHOULD support a mechanism for importing (manually or 11327 automatically) certificates discovered in public directories 11328 corresponding to the target URIs of SIP requests. 11329 11330 23.2 S/MIME Key Exchange 11331 11332 SIP itself can also be used as a means to distribute public keys in 11333 the following manner. 11334 11335 Whenever the CMS SignedData message is used in S/MIME for SIP, it 11336 MUST contain the certificate bearing the public key necessary to 11337 verify the signature. 11338 11339 When a UAC sends a request containing an S/MIME body that initiates a 11340 dialog, or sends a non-INVITE request outside the context of a 11341 dialog, the UAC SHOULD structure the body as an S/MIME If the desired 11342 CMS service is EnvelopedData (and the public key of the target user 11343 is known), the UAC SHOULD send the EnvelopedData message encapsulated 11344 within a SignedData message. 11345 11346 When a UAS receives a request containing an S/MIME CMS body that 11347 includes a certificate, the UAS SHOULD first verify the certificate, 11348 if possible, with any available certificate authority. The UAS SHOULD 11349 also determine the subject of the certificate and compare this value 11350 to the From header field of the request. If the certificate cannot 11351 be verified, because it is self-signed, or signed by no known 11352 authority, or if it is verifiable but its subject does not correspond 11353 to the From header field of request, the UAS MUST notify its user of 11354 the status of the certificate (including the subject of the 11355 certificate, its signer, and any key fingerprint information) and 11356 request explicit permission before proceeding. If the certificate 11357 was successfully verified and the subject of the certificate 11358 corresponds to the From header field of the SIP request, or if the 11359 user (after notification) explicitly authorizes the use of the 11360 11361 11362 11363 J. Rosenberg et. al. [Page 199] 11364 Internet Draft SIP February 18, 2002 11365 11366 11367 certificate, the UAS SHOULD add this certificate to a local keyring, 11368 indexed by the address-of-record of the holder of the certificate. 11369 11370 When a UAS sends a response containing an S/MIME body that answers 11371 the first request in a dialog, or a response to a non-INVITE request 11372 outside the context of a dialog, the UAS SHOULD structure the body as 11373 an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS 11374 service is EnvelopedData, the UAS SHOULD send the EnvelopedData 11375 message encapsulated within a SignedData message. 11376 11377 When a UAC receives a response containing an S/MIME CMS body that 11378 includes a certificate, the UAC SHOULD first verify the certificate, 11379 if possible, with any available certificate authority. The UAC SHOULD 11380 also determine the subject of the certificate and compare this value 11381 to the To field of the response; although the two may very well be 11382 different, and this is not necessarily indicative of a security 11383 breach. If the certificate cannot be verified because it is self- 11384 signed, or signed by no known authority, the UAC MUST notify its user 11385 of the status of the certificate (including the subject of the 11386 certificate, its signator, and any key fingerprint information) and 11387 request explicit permission before proceeding. If the certificate was 11388 successfully verified, and the subject of the certificate corresponds 11389 to the To header field in the response, or if the user (after 11390 notification) explicitly authorizes the use of the certificate, the 11391 UAC SHOULD add this certificate to a local keyring, indexed by the 11392 address-of-record of the holder of the certificate. If the UAC had 11393 not transmitted its own certificate to the UAS in any previous 11394 transaction, it SHOULD use a CMS SignedData body for its next request 11395 or response. 11396 11397 On future occasions, when the UA receives requests or responses that 11398 contain a From header field corresponding to a value in its keyring, 11399 the UA SHOULD compare the certificate offered in these messages with 11400 the existing certificate in its keyring. If there is a discrepancy, 11401 the UA MUST notify its user of a change of the certificate 11402 (preferably in terms that indicate that this is a potential security 11403 breach) and acquire the user's permission before continuing to 11404 process the signaling. If the user authorizes this certificate, it 11405 SHOULD be added to the keyring alongside any previous value(s) for 11406 this address-of-record. 11407 11408 Note well however, that this key exchange mechanism does not 11409 guarantee the secure exchange of keys when self-signed certificates, 11410 or certificates signed by an obscure authority, are used - it is 11411 vulnerable to well-known attacks. In the opinion of the authors, 11412 however, the security it provides is proverbially better than 11413 nothing; it is in fact comparable to the widely used SSH application. 11414 These limitations are explored in greater detail in Section 26.4.2. 11415 11416 11417 11418 J. Rosenberg et. al. [Page 200] 11419 Internet Draft SIP February 18, 2002 11420 11421 11422 If a UA receives an S/MIME body that has been encrypted with a public 11423 key unknown to the recipient, it MUST reject the request with a 493 11424 (Undecipherable) response. This response SHOULD contain a valid 11425 certificate for the respondent (corresponding, if possible, to any 11426 address of record given in the To header field of the rejected 11427 request) within a MIME body with a `certs-only' "smime-type" 11428 parameter. 11429 11430 A 493 (Undecipherable) sent without any certificate indicates that 11431 the respondent cannot or will not utilize S/MIME encrypted messages, 11432 though they may still support S/MIME signatures. 11433 11434 Note that a user agent that receives a request containing an S/MIME 11435 body that is not optional (with a Content-Disposition header 11436 "handling" parameter of "required") MUST reject the request with a 11437 415 Unsupported Media Type response if the MIME type is not 11438 understood. A user agent that receives such a response when S/MIME is 11439 sent SHOULD notify its user that the remote device does not support 11440 S/MIME, and it MAY subsequently resend the request without S/MIME, if 11441 appropriate; however, this 415 response may constitute a downgrade 11442 attack. 11443 11444 If a user agent sends an S/MIME body in a request, but receives a 11445 response that contains a MIME body that is not secured, the UAC 11446 SHOULD notify its user that the session could not be secured. 11447 However, if a user agent that supports S/MIME receives a request with 11448 an unsecured body, it SHOULD NOT respond with a secured body, but if 11449 it expects S/MIME from the sender (for example, because the sender's 11450 From header field value corresponds to an identity on its keychain), 11451 the UAS SHOULD notify its user that the session could not be secured. 11452 11453 Finally, if during the course of a dialog a UA receives a certificate 11454 in a CMS SignedData message that does not correspond with the 11455 certificates previously exchanged during a dialog, the UA MUST notify 11456 its user of the change, preferably in terms that indicate that this 11457 is a potential security breach. 11458 11459 23.3 Securing MIME bodies 11460 11461 There are two types of secure MIME bodies that are of interest to 11462 SIP: use of these bodies should follow the S/MIME specification [23] 11463 with a few variations. 11464 11465 o "multipart/signed" MUST be used only with CMS detached 11466 signatures. 11467 11468 11469 This allows backwards compatibility with non-S/MIME- 11470 11471 11472 11473 J. Rosenberg et. al. [Page 201] 11474 Internet Draft SIP February 18, 2002 11475 11476 11477 compliant recipients. 11478 11479 o S/MIME bodies SHOULD have a Content-Disposition header field, 11480 and the value of the "handling" parameter SHOULD be 11481 "required." 11482 11483 o If a UAC has no certificate on its keyring associated with the 11484 address-of-record to which it wants to send a request, it 11485 cannot send an encrypted "application/pkcs7-mime" MIME 11486 message. UACs MAY send an initial request such as an OPTIONS 11487 message with a CMS detached signature in order to solicit the 11488 certificate of the remote side (the signature SHOULD be over a 11489 "application/sip" body of the type described in Section 23.4). 11490 11491 11492 Note that future standardization work on S/MIME may 11493 define non-certificate based keys. 11494 11495 o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" 11496 (see Section 2.5.2 of [23]) attribute to express their 11497 capabilities and preferences for further communications. Note 11498 especially that senders MAY use the "preferSignedData" 11499 capability to encourage receivers to respond with CMS 11500 SignedData messages (for example, when sending an OPTIONS 11501 request as described above). 11502 11503 o S/MIME implementations MUST at a minimum support SHA1 as a 11504 digital signature algorithm, and 3DES as an encryption 11505 algorithm. All other signature and encryption algorithms MAY 11506 be supported. Implementations can negotiate support for these 11507 algorithms with the "SMIMECapabilities" attribute. 11508 11509 o Each S/MIME body in a SIP message SHOULD be signed with only 11510 one certificate. If a UA receives a message with multiple 11511 signatures, the outermost signature should be treated as the 11512 single certificate for this body. Parallel signatures SHOULD 11513 NOT be used. 11514 11515 The following is an example of an encrypted S/MIME SDP body 11516 within a SIP message: 11517 11518 11519 INVITE sip:bob@biloxi.com SIP/2.0 11520 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11521 To: Bob 11522 From: Alice ;tag=1928301774 11523 Call-ID: a84b4c76e66710 11524 CSeq: 314159 INVITE 11525 11526 11527 11528 J. Rosenberg et. al. [Page 202] 11529 Internet Draft SIP February 18, 2002 11530 11531 11532 Max-Forwards: 70 11533 Contact: 11534 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 11535 name=smime.p7m 11536 Content-Transfer-Encoding: base64 11537 Content-Disposition: attachment; filename=smime.p7m 11538 handling=required 11539 11540 ******************************************************* 11541 * Content-Type: application/sdp * 11542 * * 11543 * v=0 * 11544 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * 11545 * s=- * 11546 * t=0 0 * 11547 * c=IN IP4 pc33.atlanta.com * 11548 * m=audio 3456 RTP/AVP 0 1 3 99 * 11549 * a=rtpmap:0 PCMU/8000 * 11550 ******************************************************* 11551 11552 11553 11554 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP 11555 11556 As a means of providing some degree of end-to-end authentication, 11557 integrity or confidentiality for SIP header fields, S/MIME can 11558 encapsulate entire SIP messages within MIME bodies of type 11559 "application/sip" and then apply MIME security to these bodies in the 11560 same manner as typical SIP bodies. These encapsulated SIP requests 11561 and responses do not constitute a separate dialog or transaction, 11562 they are a copy of the "outer" message that is used to verify 11563 integrity or to supply additional information. 11564 11565 If a UAS receives a request that contains a tunneled 11566 "application/sip" S/MIME body, it SHOULD include a tunneled 11567 "application/sip" body in the response with the same smime-type. 11568 11569 Any traditional MIME bodies (such as SDP) SHOULD be attached to the 11570 "inner" message so that they can also benefit from S/MIME security. 11571 Note that "application/sip" bodies can be sent as a part of a MIME 11572 "multipart/mixed" body if any unsecured MIME types should also be 11573 transmitted in a request. 11574 11575 23.4.1 Integrity and Confidentiality Properties of SIP Headers 11576 11577 When the S/MIME integrity or confidentiality mechanisms are used, 11578 there may be discrepancies between the values in the "inner" message 11579 and values in the "outer" message. The rules for handling any such 11580 11581 11582 11583 J. Rosenberg et. al. [Page 203] 11584 Internet Draft SIP February 18, 2002 11585 11586 11587 differences for all of the header fields described in this document 11588 are given in this section. 11589 11590 23.4.1.1 Integrity 11591 11592 Whenever integrity checks are performed, the integrity of a header 11593 field should be determined by matching the value of the header field 11594 in the signed body with that in the "outer" messages using the 11595 comparison rules of SIP as described in 20. 11596 11597 Header fields that can be legitimately modified by proxy servers are: 11598 Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- 11599 Authorization. If these header fields are not intact end-to-end, 11600 implementations SHOULD NOT consider this a breach of security. 11601 Changes to any other header fields defined in this document 11602 constitute an integrity violation; users MUST be notified of a 11603 discrepancy. 11604 11605 23.4.1.2 Confidentiality 11606 11607 When messages are encrypted, header fields may be included in the 11608 encrypted body that are not present in the "outer" message. 11609 11610 Some header fields must always have a plaintext version because they 11611 are required header fields in requests and responses - these include: 11612 To, From, Call-ID, CSeq, Contact. While it is probably not useful to 11613 provide an encrypted alternative for the Call-ID, Cseq, or Contact, 11614 providing an alternative to the information in the "outer" To or From 11615 is permitted. Note that the values in an encrypted body are not used 11616 for the purposes of identifying transactions or dialogs - they are 11617 merely informational. If the From header field in an encrypted body 11618 differs from the value in the "outer" message, the value within the 11619 encrypted body SHOULD be displayed to the user, but MUST NOT be used 11620 in the "outer" header fields of any future messages. 11621 11622 Primarily, a user agent will want to encrypt header fields that have 11623 an end-to-end semantic, including: Subject, Reply-To, Organization, 11624 Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, 11625 Authentication-Info, Expires, In-Reply-To, Require, Supported, 11626 Unsupported, Retry-After, User-Agent, Server, and Warning. If any of 11627 these header fields are present in an encrypted body, they should be 11628 used instead of any "outer" header fields, whether this entails 11629 displaying the header field values to users or setting internal 11630 states in the UA. They SHOULD NOT however be used in the "outer" 11631 headers of any future messages. 11632 11633 Since MIME bodies are attached to the "inner" message, 11634 implementations will usually encrypt MIME-specific header fields, 11635 11636 11637 11638 J. Rosenberg et. al. [Page 204] 11639 Internet Draft SIP February 18, 2002 11640 11641 11642 including: MIME-Version, Content-Type, Content-Length, Content- 11643 Language, Content-Encoding and Content-Disposition. The "outer" 11644 message will have the proper MIME header fields for S/MIME bodies. 11645 These header fields (and any MIME bodies they preface) should be 11646 treated as normal MIME header fields and bodies received in a SIP 11647 message. 11648 11649 It is not particularly useful to encrypt the following header fields: 11650 Date, Min-Expires, Timestamp, Authorization, Priority, and WWW- 11651 Authenticate. This category also includes those header fields that 11652 can be changed by proxy servers (described in the preceding section). 11653 UAs SHOULD never include these in an "inner" message if they are not 11654 included in the "outer" message. UAs that receive any of these header 11655 fields in an encrypted body SHOULD ignore the encrypted values. 11656 11657 Note that extensions to SIP may define additional header fields; the 11658 authors of these extensions should describe the integrity and 11659 confidentiality properties of such header fields. If a SIP UA 11660 encounters an unknown header field with an integrity violation, it 11661 MUST ignore the header field. 11662 11663 23.4.2 Tunneling Integrity and Authentication 11664 11665 Tunneling SIP messages within S/MIME bodies can provide integrity for 11666 SIP header fields if the header fields that the sender wishes to 11667 secure are replicated in a "application/sip" MIME body signed with a 11668 CMS detached signature. 11669 11670 Provided that the "application/sip" body contains at least the 11671 fundamental dialog identifiers (To, From, Call-ID, CSeq), then a 11672 signed MIME body can provide limited authentication. At the very 11673 least, if the certificate used to sign the body is unknown to the 11674 recipient and cannot be verified, the signature can be used to 11675 ascertain that a later request in a dialog was transmitted by the 11676 same certificate-holder that initiated the dialog. If the recipient 11677 of the signed MIME body has some stronger incentive to trust the 11678 certificate (they were able to verify it, acquire it from a trusted 11679 repository, or they have used it frequently) then the signature can 11680 be taken as a stronger assertion of the identity of the subject of 11681 the certificate. 11682 11683 In order to eliminate possible confusions about the addition or 11684 subtraction of entire header fields, senders SHOULD replicate all 11685 header fields from the request within the signed body. Any message 11686 bodies that require integrity protection MUST be attached to the 11687 "inner" message. 11688 11689 If an integrity violation in a message is detected by its recipient, 11690 11691 11692 11693 J. Rosenberg et. al. [Page 205] 11694 Internet Draft SIP February 18, 2002 11695 11696 11697 the message MAY be rejected with a 403 (Forbidden) response if it is 11698 a request, or any existing dialog MAY be terminated. UAs SHOULD 11699 notify users of this circumstance and request explicit guidance on 11700 how to proceed. 11701 11702 The following is an example of the use of a tunneled 11703 "application/sip" body: 11704 11705 11706 INVITE sip:bob@biloxi.com SIP/2.0 11707 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11708 To: Bob 11709 From: Alice ;tag=1928301774 11710 Call-ID: a84b4c76e66710 11711 CSeq: 314159 INVITE 11712 Max-Forwards: 70 11713 Contact: 11714 Content-Type: multipart/signed; 11715 protocol="application/pkcs7-signature"; 11716 micalg=sha1; boundary=boundary42 11717 Content-Length: 568 11718 11719 --boundary42 11720 Content-Type: application/sip 11721 11722 INVITE sip:bob@biloxi.com SIP/2.0 11723 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11724 To: Bob 11725 From: Alice ;tag=1928301774 11726 Call-ID: a84b4c76e66710 11727 CSeq: 314159 INVITE 11728 Max-Forwards: 70 11729 Contact: 11730 Content-Type: application/sdp 11731 Content-Length: 147 11732 11733 v=0 11734 o=UserA 2890844526 2890844526 IN IP4 here.com 11735 s=Session SDP 11736 c=IN IP4 pc33.atlanta.com 11737 t=0 0 11738 m=audio 49172 RTP/AVP 0 11739 a=rtpmap:0 PCMU/8000 11740 11741 --boundary42 11742 Content-Type: application/pkcs7-signature; name=smime.p7s 11743 Content-Transfer-Encoding: base64 11744 Content-Disposition: attachment; filename=smime.p7s; 11745 11746 11747 11748 J. Rosenberg et. al. [Page 206] 11749 Internet Draft SIP February 18, 2002 11750 11751 11752 handling=required 11753 11754 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 11755 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 11756 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 11757 7GhIGfHfYT64VQbnj756 11758 11759 --boundary42- 11760 11761 11762 11763 23.4.3 Tunneling Encryption 11764 11765 It may also be desirable to use this mechanism to encrypt a 11766 "application/sip" MIME body within a CMS EnvelopedData message S/MIME 11767 body, but in practice, most header fields are of at least some use to 11768 the network; the general use of encryption with S/MIME is to secure 11769 message bodies like SDP rather than message headers. Some 11770 informational header fields, such as the Subject or Organization 11771 could perhaps warrant end-to-end security. Headers defined by future 11772 SIP applications might also require obfuscation. 11773 11774 Another possible application of encrypting header fields is selective 11775 anonymity. A request could be constructed with a From header field 11776 that contains no personal information (for example, 11777 sip:anonymous@anonymizer.invalid). However, a second From header 11778 field containing the genuine address-of-record of the originator 11779 could be encrypted within a "application/sip" MIME body where it will 11780 only be visible to the endpoints of a dialog. 11781 11782 motivationNote that if this mechanism is used for anonymity, the From 11783 header field will no longer be usable by the recipient of a message 11784 as an index to their certificate keychain for retrieving the proper 11785 S/MIME key to associated with the sender. The message must first be 11786 decrypted, and the "inner" From header field MUST be used as an 11787 index. 11788 11789 In order to provide end-to-end integrity, encrypted "application/sip" 11790 MIME bodies SHOULD be signed by the sender. This creates a 11791 "multipart/signed" MIME body that contains an encrypted body and a 11792 signature, both of type "application/pkcs7-mime". 11793 11794 In the following example, of an encrypted and signed message, the 11795 text boxed in asterisks ("*") is encrypted: 11796 11797 11798 INVITE sip:bob@biloxi.com SIP/2.0 11799 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11800 11801 11802 11803 J. Rosenberg et. al. [Page 207] 11804 Internet Draft SIP February 18, 2002 11805 11806 11807 To: Bob 11808 From: Anonymous ;tag=1928301774 11809 Call-ID: a84b4c76e66710 11810 CSeq: 314159 INVITE 11811 Max-Forwards: 70 11812 Contact: 11813 Content-Type: multipart/signed; 11814 protocol="application/pkcs7-signature"; 11815 micalg=sha1; boundary=boundary42 11816 Content-Length: 568 11817 11818 --boundary42 11819 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 11820 name=smime.p7m 11821 Content-Transfer-Encoding: base64 11822 Content-Disposition: attachment; filename=smime.p7m 11823 handling=required 11824 Content-Length: 231 11825 11826 *********************************************************** 11827 * Content-Type: application/sip * 11828 * * 11829 * INVITE sip:bob@biloxi.com SIP/2.0 * 11830 * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * 11831 * To: Bob * 11832 * From: Alice ;tag=1928301774 * 11833 * Call-ID: a84b4c76e66710 * 11834 * CSeq: 314159 INVITE * 11835 * Max-Forwards: 70 * 11836 * Contact: * 11837 * * 11838 * Content-Type: application/sdp * 11839 * * 11840 * v=0 * 11841 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * 11842 * s=Session SDP * 11843 * t=0 0 * 11844 * c=IN IP4 pc33.atlanta.com * 11845 * m=audio 3456 RTP/AVP 0 1 3 99 * 11846 * a=rtpmap:0 PCMU/8000 * 11847 *********************************************************** 11848 11849 --boundary42 11850 Content-Type: application/pkcs7-signature; name=smime.p7s 11851 Content-Transfer-Encoding: base64 11852 Content-Disposition: attachment; filename=smime.p7s; 11853 handling=required 11854 11855 11856 11857 11858 J. Rosenberg et. al. [Page 208] 11859 Internet Draft SIP February 18, 2002 11860 11861 11862 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 11863 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 11864 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 11865 7GhIGfHfYT64VQbnj756 11866 11867 --boundary42- 11868 11869 11870 11871 24 Examples 11872 11873 In the following examples, we often omit the message body and the 11874 corresponding Content-Length and Content-Type header fields for 11875 brevity. 11876 11877 24.1 Registration 11878 11879 Bob registers on start-up. The message flow is shown in Figure 9. 11880 Note that the authentication usually required for registration is not 11881 shown for simplicity. 11882 11883 11884 11885 11886 biloxi.com Bob's 11887 registrar softphone 11888 | | 11889 | REGISTER F1 | 11890 |<---------------| 11891 | 200 OK F2 | 11892 |--------------->| 11893 11894 11895 11896 11897 Figure 9: SIP Registration Example 11898 11899 11900 11901 11902 11903 F1 REGISTER Bob -> Registrar 11904 11905 REGISTER sip:registrar.biloxi.com SIP/2.0 11906 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 11907 Max-Forwards: 70 11908 To: Bob 11909 From: Bob ;tag=456248 11910 Call-ID: 843817637684230@998sdasdh09 11911 11912 11913 11914 J. Rosenberg et. al. [Page 209] 11915 Internet Draft SIP February 18, 2002 11916 11917 11918 CSeq: 1826 REGISTER 11919 Contact: 11920 Expires: 7200 11921 Content-Length: 0 11922 11923 11924 11925 The registration expires after two hours. The registrar responds with 11926 a 200 OK: 11927 11928 11929 11930 F2 200 OK Registrar -> Bob 11931 11932 SIP/2.0 200 OK 11933 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 11934 ;received=192.0.2.4 11935 To: Bob 11936 From: Bob ;tag=456248 11937 Call-ID: 843817637684230@998sdasdh09 11938 CSeq: 1826 REGISTER 11939 Contact: 11940 Expires: 7200 11941 Content-Length: 0 11942 11943 11944 11945 11946 24.2 Session Setup 11947 11948 This example contains the full details of the example session setup 11949 in Section 4. The message flow is shown in Figure 1. Note that these 11950 flows show the minimum required set of header fields - some other 11951 header fields such as Allow and Supported would normally be present. 11952 11953 11954 11955 F1 INVITE Alice -> atlanta.com proxy 11956 11957 INVITE sip:bob@biloxi.com SIP/2.0 11958 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11959 Max-Forwards: 70 11960 To: Bob 11961 From: Alice ;tag=1928301774 11962 Call-ID: a84b4c76e66710 11963 CSeq: 314159 INVITE 11964 Contact: 11965 Content-Type: application/sdp 11966 11967 11968 11969 J. Rosenberg et. al. [Page 210] 11970 Internet Draft SIP February 18, 2002 11971 11972 11973 Content-Length: 142 11974 11975 (Alice's SDP not shown) 11976 11977 11978 11979 11980 11981 F2 100 Trying atlanta.com proxy -> Alice 11982 11983 SIP/2.0 100 Trying 11984 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 11985 ;received=10.1.3.3 11986 To: Bob 11987 From: Alice ;tag=1928301774 11988 Call-ID: a84b4c76e66710 11989 CSeq: 314159 INVITE 11990 Content-Length: 0 11991 11992 11993 11994 11995 11996 F3 INVITE atlanta.com proxy -> biloxi.com proxy 11997 11998 INVITE sip:bob@biloxi.com SIP/2.0 11999 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12000 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12001 ;received=10.1.3.3 12002 Max-Forwards: 69 12003 To: Bob 12004 From: Alice ;tag=1928301774 12005 Call-ID: a84b4c76e66710 12006 CSeq: 314159 INVITE 12007 Contact: 12008 Content-Type: application/sdp 12009 Content-Length: 142 12010 12011 (Alice's SDP not shown) 12012 12013 12014 12015 12016 12017 F4 100 Trying biloxi.com proxy -> atlanta.com proxy 12018 12019 SIP/2.0 100 Trying 12020 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12021 12022 12023 12024 J. Rosenberg et. al. [Page 211] 12025 Internet Draft SIP February 18, 2002 12026 12027 12028 ;received=10.1.1.1 12029 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12030 ;received=10.1.3.3 12031 To: Bob 12032 From: Alice ;tag=1928301774 12033 Call-ID: a84b4c76e66710 12034 CSeq: 314159 INVITE 12035 Content-Length: 0 12036 12037 12038 12039 12040 12041 F5 INVITE biloxi.com proxy -> Bob 12042 12043 INVITE sip:bob@192.0.2.4 SIP/2.0 12044 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 12045 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12046 ;received=10.1.1.1 12047 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12048 ;received=10.1.3.3 12049 Max-Forwards: 68 12050 To: Bob 12051 From: Alice ;tag=1928301774 12052 Call-ID: a84b4c76e66710 12053 CSeq: 314159 INVITE 12054 Contact: 12055 Content-Type: application/sdp 12056 Content-Length: 142 12057 12058 (Alice's SDP not shown) 12059 12060 12061 12062 12063 12064 F6 180 Ringing Bob -> biloxi.com proxy 12065 12066 SIP/2.0 180 Ringing 12067 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 12068 ;received=10.2.1.1 12069 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12070 ;received=10.1.1.1 12071 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12072 ;received=10.1.3.3 12073 To: Bob ;tag=a6c85cf 12074 From: Alice ;tag=1928301774 12075 Call-ID: a84b4c76e66710 12076 12077 12078 12079 J. Rosenberg et. al. [Page 212] 12080 Internet Draft SIP February 18, 2002 12081 12082 12083 Contact: 12084 CSeq: 314159 INVITE 12085 Content-Length: 0 12086 12087 12088 12089 12090 12091 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy 12092 12093 SIP/2.0 180 Ringing 12094 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12095 ;received=10.1.1.1 12096 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12097 ;received=10.1.3.3 12098 To: Bob ;tag=a6c85cf 12099 From: Alice ;tag=1928301774 12100 Call-ID: a84b4c76e66710 12101 Contact: 12102 CSeq: 314159 INVITE 12103 Content-Length: 0 12104 12105 12106 12107 12108 12109 F8 180 Ringing atlanta.com proxy -> Alice 12110 12111 SIP/2.0 180 Ringing 12112 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12113 ;received=10.1.3.3 12114 To: Bob ;tag=a6c85cf 12115 From: Alice ;tag=1928301774 12116 Call-ID: a84b4c76e66710 12117 Contact: 12118 CSeq: 314159 INVITE 12119 Content-Length: 0 12120 12121 12122 12123 12124 12125 F9 200 OK Bob -> biloxi.com proxy 12126 12127 SIP/2.0 200 OK 12128 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 12129 ;received=10.2.1.1 12130 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12131 12132 12133 12134 J. Rosenberg et. al. [Page 213] 12135 Internet Draft SIP February 18, 2002 12136 12137 12138 ;received=10.1.1.1 12139 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12140 ;received=10.1.3.3 12141 To: Bob ;tag=a6c85cf 12142 From: Alice ;tag=1928301774 12143 Call-ID: a84b4c76e66710 12144 CSeq: 314159 INVITE 12145 Contact: 12146 Content-Type: application/sdp 12147 Content-Length: 131 12148 12149 (Bob's SDP not shown) 12150 12151 12152 12153 12154 12155 F10 200 OK biloxi.com proxy -> atlanta.com proxy 12156 12157 SIP/2.0 200 OK 12158 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 12159 ;received=10.1.1.1 12160 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12161 ;received=10.1.3.3 12162 To: Bob ;tag=a6c85cf 12163 From: Alice ;tag=1928301774 12164 Call-ID: a84b4c76e66710 12165 CSeq: 314159 INVITE 12166 Contact: 12167 Content-Type: application/sdp 12168 Content-Length: 131 12169 12170 (Bob's SDP not shown) 12171 12172 12173 12174 12175 12176 F11 200 OK atlanta.com proxy -> Alice 12177 12178 SIP/2.0 200 OK 12179 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 12180 ;received=10.1.3.3 12181 To: Bob ;tag=a6c85cf 12182 From: Alice ;tag=1928301774 12183 Call-ID: a84b4c76e66710 12184 CSeq: 314159 INVITE 12185 Contact: 12186 12187 12188 12189 J. Rosenberg et. al. [Page 214] 12190 Internet Draft SIP February 18, 2002 12191 12192 12193 Content-Type: application/sdp 12194 Content-Length: 131 12195 12196 (Bob's SDP not shown) 12197 12198 12199 12200 12201 12202 F12 ACK Alice -> Bob 12203 12204 ACK sip:bob@192.0.2.4 SIP/2.0 12205 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 12206 Max-Forwards: 70 12207 To: Bob ;tag=a6c85cf 12208 From: Alice ;tag=1928301774 12209 Call-ID: a84b4c76e66710 12210 CSeq: 314159 ACK 12211 Content-Length: 0 12212 12213 12214 12215 The media session between Alice and Bob is now established. 12216 12217 Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq 12218 numbering space, which, in this example, begins with 231. Since Bob 12219 is making the request, the To and From URIs and tags have been 12220 swapped. 12221 12222 12223 12224 F13 BYE Bob -> Alice 12225 12226 BYE sip:alice@pc33.atlanta.com SIP/2.0 12227 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 12228 Max-Forwards: 70 12229 From: Bob ;tag=a6c85cf 12230 To: Alice ;tag=1928301774 12231 Call-ID: a84b4c76e66710 12232 CSeq: 231 BYE 12233 Content-Length: 0 12234 12235 12236 12237 12238 12239 F14 200 OK Alice -> Bob 12240 12241 12242 12243 12244 J. Rosenberg et. al. [Page 215] 12245 Internet Draft SIP February 18, 2002 12246 12247 12248 SIP/2.0 200 OK 12249 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 12250 ;received=10.1.3.3 12251 From: Bob ;tag=a6c85cf 12252 To: Alice ;tag=1928301774 12253 Call-ID: a84b4c76e66710 12254 CSeq: 231 BYE 12255 Content-Length: 0 12256 12257 12258 12259 The SIP Call Flows document [39] contains further examples of SIP 12260 messages. 12261 12262 25 Augmented BNF for the SIP Protocol 12263 12264 All of the mechanisms specified in this document are described in 12265 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 12266 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that 12267 are used by this specification, and not repeated here. Implementers 12268 need to be familiar with the notation and content of RFC 2234 in 12269 order to understand this specification. Certain basic rules are in 12270 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle 12271 brackets are used within definitions to clarify the use of rule 12272 names. 12273 12274 In some cases, the BNF for a choice will indicate that some elements 12275 are optional through angle brackets. For example: 12276 12277 12278 12279 foo = bar / baz / [boo] 12280 12281 12282 The use of angle brackets is redundant syntactically. It is used as a 12283 semantic hint that the specific parameter is optional to use. 12284 12285 25.1 Basic Rules 12286 12287 The following rules are used throughout this specification to 12288 describe basic parsing constructs. The US-ASCII coded character set 12289 is defined by ANSI X3.4-1986. 12290 12291 12292 12293 alphanum = ALPHA / DIGIT 12294 12295 12296 12297 12298 12299 J. Rosenberg et. al. [Page 216] 12300 Internet Draft SIP February 18, 2002 12301 12302 12303 Several rules are incorporated from RFC 2396 [5] but are updated to 12304 make them compliant with RFC 2234 [10]. These include: 12305 12306 12307 12308 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" 12309 / "$" / "," 12310 unreserved = alphanum / mark 12311 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 12312 / "(" / ")" 12313 escaped = "%" HEXDIG HEXDIG 12314 12315 12316 SIP header field values can be folded onto multiple lines if the 12317 continuation line begins with a space or horizontal tab. All linear 12318 white space, including folding, has the same semantics as SP. A 12319 recipient MAY replace any linear white space with a single SP before 12320 interpreting the field value or forwarding the message downstream. 12321 This is intended to behave exactly as HTTP/1.1 as described in RFC 12322 2616 [8]. The SWS construct is used when linear white space is 12323 optional, generally between tokens and separators. 12324 12325 12326 12327 LWS = [*WSP CRLF] 1*WSP ; linear whitespace 12328 SWS = [LWS] ; sep whitespace 12329 12330 12331 To separate the header name from the rest of value, a colon is used, 12332 which, by the above rule, allows whitespace before, but no line 12333 break, and whitespace after, including a linebreak. The HCOLON 12334 defines this construct. 12335 12336 12337 12338 HCOLON = *( SP / HTAB ) ":" SWS 12339 12340 12341 The TEXT-UTF8 rule is only used for descriptive field contents and 12342 values that are not intended to be interpreted by the message parser. 12343 Words of *TEXT-UTF8 contain characters from the UTF-8 character set 12344 (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field 12345 contents that are not quoted strings, where leading and trailing LWS 12346 is not meaningful. In this regard, SIP differs from HTTP, which uses 12347 the ISO 8859-1 character set. 12348 12349 12350 12351 12352 12353 12354 J. Rosenberg et. al. [Page 217] 12355 Internet Draft SIP February 18, 2002 12356 12357 12358 TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) 12359 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 12360 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 12361 / %xE0-EF 2UTF8-CONT 12362 / %xF0-F7 3UTF8-CONT 12363 / %xF8-Fb 4UTF8-CONT 12364 / %xFC-FD 5UTF8-CONT 12365 UTF8-CONT = %x80-BF 12366 12367 12368 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of 12369 a header field continuation. It is expected that the folding LWS will 12370 be replaced with a single SP before interpretation of the TEXT-UTF8- 12371 TRIM value. 12372 12373 Hexadecimal numeric characters are used in several protocol elements. 12374 Some elements (authentication) force hex alphas to be lower case. 12375 12376 12377 LHEX = DIGIT / %x61-66 ;lowercase a-f 12378 12379 12380 Many SIP header field values consist of words separated by LWS or 12381 special characters. Unless otherwise stated, tokens are case- 12382 insensitive. These special characters MUST be in a quoted string to 12383 be used within a parameter value. The word construct is used in 12384 Call-ID to allow most separators to be used. 12385 12386 12387 12388 token = 1*(alphanum / "-" / "." / "!" / "%" / "*" 12389 / "_" / "+" / "`" / "'" / "~" ) 12390 separators = "(" / ")" / "<" / ">" / "@" / 12391 "," / ";" / ":" / "\" / <"> / 12392 "/" / "[" / "]" / "?" / "=" / 12393 "{" / "}" / SP / HTAB 12394 word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / 12395 "_" / "+" / "`" / "'" / "~" / 12396 "(" / ")" / "<" / ">" / 12397 ":" / "\" / <"> / 12398 "/" / "[" / "]" / "?" / 12399 "{" / "}" ) 12400 12401 12402 When tokens are used or separators are used between elements, 12403 whitespace is often allowed before or after these characters: 12404 12405 12406 12407 12408 12409 J. Rosenberg et. al. [Page 218] 12410 Internet Draft SIP February 18, 2002 12411 12412 12413 STAR = SWS "*" SWS ; asterisk 12414 SLASH = SWS "/" SWS ; slash 12415 EQUAL = SWS "=" SWS ; equal 12416 LPAREN = SWS "(" SWS ; left parenthesis 12417 RPAREN = SWS ")" SWS ; right parenthesis 12418 RAQUOT = ">" SWS ; right angle quote 12419 LAQUOT = SWS "<"; left angle quote 12420 COMMA = SWS "," SWS ; comma 12421 SEMI = SWS ";" SWS ; semicolon 12422 COLON = SWS ":" SWS ; colon 12423 LDQUOT = SWS DQUOTE; open double quotation mark 12424 RDQUOT = DQUOTE SWS ; close double quotation mark 12425 12426 12427 Comments can be included in some SIP header fields by surrounding the 12428 comment text with parentheses. Comments are only allowed in fields 12429 containing "comment" as part of their field value definition. In all 12430 other fields, parentheses are considered part of the field value. 12431 12432 12433 12434 comment = LPAREN *(ctext / quoted-pair / comment) RPAREN 12435 ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII 12436 / LWS 12437 12438 12439 ctext includes all chars except left and right parens and backslash. 12440 A string of text is parsed as a single word if it is quoted using 12441 double-quote marks. In quoted strings, quotation marks (") and 12442 backslashes (\) need to be escaped. 12443 12444 12445 12446 quoted-string = SWS <"> *(qdtext / quoted-pair ) <"> 12447 qdtext = LWS / %x21 / %x23-5B / %x5D-7E 12448 / UTF8-NONASCII 12449 12450 12451 The backslash character ("\") MAY be used as a single-character 12452 quoting mechanism only within quoted-string and comment constructs. 12453 Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this 12454 mechanism to avoid conflict with line folding and header separation. 12455 12456 12457 12458 quoted-pair = "\" (%x00-09 / %x0B-0C 12459 / %x0E-7F) 12460 12461 12462 12463 12464 J. Rosenberg et. al. [Page 219] 12465 Internet Draft SIP February 18, 2002 12466 12467 12468 SIP-URI = "sip:" [ userinfo "@" ] hostport 12469 uri-parameters [ headers ] 12470 SIPS-URI = "sips:" [ userinfo "@" ] hostport 12471 uri-parameters [ headers ] 12472 userinfo = [ user / telephone-subscriber [ ":" password ]] 12473 user = *( unreserved / escaped / user-unreserved ) 12474 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 12475 password = *( unreserved / escaped / 12476 "&" / "=" / "+" / "$" / "," ) 12477 hostport = host [ ":" port ] 12478 host = hostname / IPv4address / IPv6reference 12479 hostname = *( domainlabel "." ) toplabel [ "." ] 12480 domainlabel = alphanum 12481 / alphanum *( alphanum / "-" ) alphanum 12482 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 12483 12484 12485 12486 12487 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 12488 IPv6reference = "[" IPv6address "]" 12489 IPv6address = hexpart [ ":" IPv4address ] 12490 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 12491 hexseq = hex4 *( ":" hex4) 12492 hex4 = 1*4HEXDIG 12493 port = 1*DIGIT 12494 12495 12496 The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, 12497 however, that any characters allowed there that are not allowed in 12498 the user part of the SIP URI MUST be escaped. 12499 12500 12501 12502 uri-parameters = *( ";" uri-parameter) 12503 uri-parameter = transport-param / user-param / method-param 12504 / ttl-param / maddr-param / lr-param / other-param 12505 transport-param = "transport=" 12506 ( "udp" / "tcp" / "sctp" / "tls" 12507 / other-transport) 12508 other-transport = token 12509 user-param = "user=" ( "phone" / "ip" / other-user) 12510 other-user = token 12511 method-param = "method=" Method 12512 ttl-param = "ttl=" ttl 12513 maddr-param = "maddr=" host 12514 lr-param = "lr" 12515 other-param = pname [ "=" pvalue ] 12516 12517 12518 12519 J. Rosenberg et. al. [Page 220] 12520 Internet Draft SIP February 18, 2002 12521 12522 12523 pname = 1*paramchar 12524 pvalue = 1*paramchar 12525 paramchar = param-unreserved / unreserved / escaped 12526 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" 12527 12528 12529 12530 12531 headers = "?" header *( "&" header ) 12532 header = hname "=" hvalue 12533 hname = 1*( hnv-unreserved / unreserved / escaped ) 12534 hvalue = *( hnv-unreserved / unreserved / escaped ) 12535 hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" 12536 12537 12538 12539 12540 SIP-message = Request / Response 12541 Request = Request-Line 12542 *( message-header ) 12543 CRLF 12544 [ message-body ] 12545 Request-Line = Method SP Request-URI SP SIP-Version CRLF 12546 Request-URI = SIP-URI / SIPS-URI / absoluteURI 12547 absoluteURI = scheme ":" ( hier-part / opaque-part ) 12548 hier-part = ( net-path / abs-path ) [ "?" query ] 12549 net-path = "//" authority [ abs-path ] 12550 abs-path = "/" path-segments 12551 opaque-part = uric-no-slash *uric 12552 uric = reserved / unreserved / escaped 12553 uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" 12554 / "&" / "=" / "+" / "$" / "," 12555 path-segments = segment *( "/" segment ) 12556 segment = *pchar *( ";" param ) 12557 param = *pchar 12558 pchar = unreserved / escaped / 12559 ":" / "@" / "&" / "=" / "+" / "$" / "," 12560 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 12561 authority = srvr / reg-name 12562 srvr = [ [ userinfo "@" ] hostport ] 12563 reg-name = 1*( unreserved / escaped / "$" / "," 12564 / ";" / ":" / "@" / "&" / "=" / "+" ) 12565 query = *uric 12566 SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT 12567 12568 12569 12570 12571 12572 12573 12574 J. Rosenberg et. al. [Page 221] 12575 Internet Draft SIP February 18, 2002 12576 12577 12578 message-header = (Accept 12579 / Accept-Encoding 12580 / Accept-Language 12581 / Alert-Info 12582 / Allow 12583 / Authentication-Info 12584 / Authorization 12585 / Call-ID 12586 / Call-Info 12587 / Contact 12588 / Content-Disposition 12589 / Content-Encoding 12590 / Content-Language 12591 / Content-Length 12592 / Content-Type 12593 / CSeq 12594 / Date 12595 / Error-Info 12596 / Expires 12597 / From 12598 / In-Reply-To 12599 / Max-Forwards 12600 / MIME-Version 12601 / Min-Expires 12602 / Organization 12603 / Priority 12604 / Proxy-Authenticate 12605 / Proxy-Authorization 12606 / Proxy-Require 12607 / Record-Route 12608 / Reply-To 12609 / Require 12610 / Retry-After 12611 / Route 12612 / Server 12613 / Subject 12614 / Supported 12615 / Timestamp 12616 / To 12617 / Unsupported 12618 / User-Agent 12619 / Via 12620 / Warning 12621 / WWW-Authenticate 12622 / extension-header) CRLF 12623 12624 12625 12626 12627 12628 12629 J. Rosenberg et. al. [Page 222] 12630 Internet Draft SIP February 18, 2002 12631 12632 12633 INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps 12634 ACKm = %x41.43.4B ; ACK in caps 12635 OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps 12636 BYEm = %x42.59.45 ; BYE in caps 12637 CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps 12638 REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps 12639 Method = INVITEm / ACKm / OPTIONSm / BYEm 12640 / CANCELm / REGISTERm 12641 / extension-method 12642 extension-method = token 12643 Response = Status-Line 12644 *( message-header ) 12645 CRLF 12646 [ message-body ] 12647 12648 12649 12650 12651 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF 12652 Status-Code = Informational 12653 / Redirection 12654 / Success 12655 / Client-Error 12656 / Server-Error 12657 / Global-Failure 12658 / extension-code 12659 extension-code = 3DIGIT 12660 Reason-Phrase = *(reserved / unreserved / escaped 12661 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 12662 12663 12664 12665 12666 Informational = "100" ; Trying 12667 / "180" ; Ringing 12668 / "181" ; Call Is Being Forwarded 12669 / "182" ; Queued 12670 / "183" ; Session Progress 12671 12672 12673 12674 12675 Success = "200" ; OK 12676 12677 12678 12679 12680 Redirection = "300" ; Multiple Choices 12681 12682 12683 12684 J. Rosenberg et. al. [Page 223] 12685 Internet Draft SIP February 18, 2002 12686 12687 12688 / "301" ; Moved Permanently 12689 / "302" ; Moved Temporarily 12690 / "305" ; Use Proxy 12691 / "380" ; Alternative Service 12692 12693 12694 12695 12696 Client-Error = "400" ; Bad Request 12697 / "401" ; Unauthorized 12698 / "402" ; Payment Required 12699 / "403" ; Forbidden 12700 / "404" ; Not Found 12701 / "405" ; Method Not Allowed 12702 / "406" ; Not Acceptable 12703 / "407" ; Proxy Authentication Required 12704 / "408" ; Request Timeout 12705 / "410" ; Gone 12706 / "413" ; Request Entity Too Large 12707 / "414" ; Request-URI Too Large 12708 / "415" ; Unsupported Media Type 12709 / "416" ; Unsupported URI Scheme 12710 / "420" ; Bad Extension 12711 / "421" ; Extension Required 12712 / "423" ; Interval Too Brief 12713 / "480" ; Temporarily not available 12714 / "481" ; Call Leg/Transaction Does Not Exist 12715 / "482" ; Loop Detected 12716 / "483" ; Too Many Hops 12717 / "484" ; Address Incomplete 12718 / "485" ; Ambiguous 12719 / "486" ; Busy Here 12720 / "487" ; Request Terminated 12721 / "488" ; Not Acceptable Here 12722 / "491" ; Request Pending 12723 / "493" ; Undecipherable 12724 12725 12726 12727 12728 Server-Error = "500" ; Internal Server Error 12729 / "501" ; Not Implemented 12730 / "502" ; Bad Gateway 12731 / "503" ; Service Unavailable 12732 / "504" ; Server Time-out 12733 / "505" ; SIP Version not supported 12734 / "513" ; Message Too Large 12735 12736 12737 12738 12739 J. Rosenberg et. al. [Page 224] 12740 Internet Draft SIP February 18, 2002 12741 12742 12743 Global-Failure = "600" ; Busy Everywhere 12744 / "603" ; Decline 12745 / "604" ; Does not exist anywhere 12746 / "606" ; Not Acceptable 12747 12748 12749 12750 12751 Accept = "Accept" HCOLON 12752 ( accept-range *(COMMA accept-range) ) 12753 accept-range = media-range [ accept-params ] 12754 media-range = ( "*/*" 12755 / ( m-type SLASH "*" ) 12756 / ( m-type SLASH m-subtype ) 12757 ) *( SEMI m-parameter ) 12758 accept-params = SEMI "q" EQUAL qvalue *( accept-extension ) 12759 accept-extension = SEMI ae-name [ EQUAL ae-value ] 12760 ae-name = token 12761 ae-value = token / quoted-string 12762 12763 12764 12765 12766 Accept-Encoding = "Accept-Encoding" HCOLON 12767 ( encoding *(COMMA encoding) ) 12768 encoding = codings [ SEMI "q" EQUAL qvalue ] 12769 codings = content-coding / "*" 12770 content-coding = token 12771 qvalue = ( "0" [ "." 0*3DIGIT ] ) 12772 / ( "1" [ "." 0*3("0") ] ) 12773 12774 12775 12776 12777 Accept-Language = "Accept-Language" HCOLON 12778 ( language *(COMMA language) ) 12779 language = language-range [ SEMI "q" EQUAL qvalue ] 12780 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) 12781 12782 12783 12784 12785 Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) 12786 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) 12787 generic-param = token [ EQUAL gen-value ] 12788 gen-value = token / host / quoted-string 12789 12790 12791 12792 12793 12794 J. Rosenberg et. al. [Page 225] 12795 Internet Draft SIP February 18, 2002 12796 12797 12798 Allow = "Allow" HCOLON Method *(COMMA Method) 12799 12800 12801 12802 12803 Authorization = "Authorization" HCOLON credentials 12804 credentials = ("Digest" LWS digest-response) 12805 / other-response 12806 digest-response = dig-resp *(COMMA dig-resp) 12807 dig-resp = username / realm / nonce / digest-uri 12808 / dresponse / [ algorithm ] / [cnonce] 12809 / [opaque] / [message-qop] 12810 / [nonce-count] / [auth-param] 12811 username = "username" EQUAL username-value 12812 username-value = quoted-string 12813 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 12814 digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 12815 message-qop = "qop" EQUAL qop-value 12816 cnonce = "cnonce" EQUAL cnonce-value 12817 cnonce-value = nonce-value 12818 nonce-count = "nc" EQUAL nc-value 12819 nc-value = 8LHEX 12820 dresponse = "response" EQUAL request-digest 12821 request-digest = LDQUOT 32LHEX RDQUOT 12822 auth-param = auth-param-name EQUAL 12823 ( token / quoted-string ) 12824 auth-param-name = token 12825 other-response = auth-scheme LWS auth-param 12826 *(COMMA auth-param) 12827 auth-scheme = token 12828 12829 12830 12831 12832 Authentication-Info = "Authentication-Info" HCOLON ainfo 12833 *(COMMA ainfo) 12834 ainfo = [nextnonce] / [ message-qop ] 12835 / [ response-auth ] / [ cnonce ] 12836 / [nonce-count] 12837 nextnonce = "nextnonce" EQUAL nonce-value 12838 response-auth = "rspauth" EQUAL response-digest 12839 response-digest = LDQUOT *LHEX RDQUOT 12840 12841 12842 12843 12844 Call-ID = ( "Call-ID" / "i" ) HCOLON callid 12845 callid = word [ "@" word ] 12846 12847 12848 12849 J. Rosenberg et. al. [Page 226] 12850 Internet Draft SIP February 18, 2002 12851 12852 12853 Call-Info = "Call-Info" HCOLON info *(COMMA info) 12854 info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) 12855 info-param = ( "purpose" EQUAL ( "icon" / "info" 12856 / "card" / token ) ) / generic-param 12857 12858 12859 12860 12861 Contact = ("Contact" / "m" ) HCOLON 12862 ( STAR / (contact-param *(COMMA contact-param))) 12863 contact-param = (name-addr / addr-spec) *(SEMI contact-params) 12864 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 12865 addr-spec = SIP-URI / SIPS-URI / absoluteURI 12866 display-name = *(token LWS)/ quoted-string 12867 12868 12869 12870 12871 contact-params = c-p-q / c-p-expires 12872 / contact-extension 12873 c-p-q = "q" EQUAL qvalue 12874 c-p-expires = "expires" EQUAL delta-seconds 12875 contact-extension = generic-param 12876 delta-seconds = 1*DIGIT 12877 12878 12879 12880 12881 Content-Disposition = "Content-Disposition" HCOLON 12882 disp-type *( SEMI disp-param ) 12883 disp-type = "render" / "session" / "icon" / "alert" 12884 / disp-extension-token 12885 disp-param = handling-param / generic-param 12886 handling-param = "handling" EQUAL 12887 ( "optional" / "required" 12888 / other-handling ) 12889 other-handling = token 12890 disp-extension-token = token 12891 12892 12893 12894 12895 Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON 12896 content-coding *(COMMA content-coding) 12897 12898 12899 12900 12901 12902 12903 12904 J. Rosenberg et. al. [Page 227] 12905 Internet Draft SIP February 18, 2002 12906 12907 12908 Content-Language = "Content-Language" HCOLON 12909 language-tag *(COMMA language-tag) 12910 language-tag = primary-tag *( "-" subtag ) 12911 primary-tag = 1*8ALPHA 12912 subtag = 1*8ALPHA 12913 12914 12915 12916 12917 Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT 12918 12919 12920 12921 12922 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 12923 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 12924 m-type = discrete-type / composite-type 12925 discrete-type = "text" / "image" / "audio" / "video" 12926 / "application" / extension-token 12927 composite-type = "message" / "multipart" / extension-token 12928 extension-token = ietf-token / x-token 12929 ietf-token = token 12930 x-token = "x-" token 12931 m-subtype = extension-token / iana-token 12932 iana-token = token 12933 m-parameter = m-attribute EQUAL m-value 12934 m-attribute = token 12935 m-value = token / quoted-string 12936 12937 12938 12939 12940 CSeq = "CSeq" HCOLON 1*DIGIT LWS Method 12941 12942 12943 12944 12945 Date = "Date" HCOLON SIP-date 12946 SIP-date = rfc1123-date 12947 rfc1123-date = wkday "," date1 SP time SP "GMT" 12948 date1 = 2DIGIT SP month SP 4DIGIT 12949 ; day month year (e.g., 02 Jun 1982) 12950 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 12951 ; 00:00:00 - 23:59:59 12952 wkday = "Mon" / "Tue" / "Wed" 12953 / "Thu" / "Fri" / "Sat" / "Sun" 12954 month = "Jan" / "Feb" / "Mar" / "Apr" 12955 / "May" / "Jun" / "Jul" / "Aug" 12956 12957 12958 12959 J. Rosenberg et. al. [Page 228] 12960 Internet Draft SIP February 18, 2002 12961 12962 12963 / "Sep" / "Oct" / "Nov" / "Dec" 12964 12965 12966 12967 12968 Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) 12969 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) 12970 12971 12972 12973 12974 Expires = "Expires" HCOLON delta-seconds 12975 From = ( "From" / "f" ) HCOLON from-spec 12976 from-spec = ( name-addr / addr-spec ) 12977 *( SEMI from-param ) 12978 from-param = tag-param / generic-param 12979 tag-param = "tag" EQUAL token 12980 12981 12982 12983 12984 In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) 12985 12986 12987 12988 12989 Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT 12990 12991 12992 12993 12994 MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT 12995 12996 12997 12998 12999 Min-Expires = "Min-Expires" HCOLON delta-seconds 13000 13001 13002 13003 13004 Organization = "Organization" HCOLON TEXT-UTF8-TRIM 13005 13006 13007 13008 13009 Priority = "Priority" HCOLON priority-value 13010 priority-value = "emergency" / "urgent" / "normal" 13011 13012 13013 13014 J. Rosenberg et. al. [Page 229] 13015 Internet Draft SIP February 18, 2002 13016 13017 13018 / "non-urgent" / other-priority 13019 other-priority = token 13020 13021 13022 13023 13024 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge 13025 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 13026 / other-challenge 13027 other-challenge = auth-scheme LWS auth-param 13028 *(COMMA auth-param) 13029 digest-cln = realm / [ domain ] / nonce 13030 / [ opaque ] / [ stale ] / [ algorithm ] 13031 / [ qop-options ] / [auth-param] 13032 realm = "realm" EQUAL realm-value 13033 realm-value = quoted-string 13034 domain = "domain" EQUAL LDQUOT URI 13035 *( 1*SP URI ) RDQUOT 13036 URI = absoluteURI / abs-path 13037 nonce = "nonce" EQUAL nonce-value 13038 nonce-value = quoted-string 13039 opaque = "opaque" EQUAL quoted-string 13040 stale = "stale" EQUAL ( "true" / "false" ) 13041 algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" 13042 / token ) 13043 qop-options = "qop" EQUAL LDQUOT qop-value 13044 *("," qop-value) RDQUOT 13045 qop-value = "auth" / "auth-int" / token 13046 13047 13048 13049 13050 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials 13051 13052 13053 13054 13055 Proxy-Require = "Proxy-Require" HCOLON option-tag 13056 *(COMMA option-tag) 13057 option-tag = token 13058 13059 13060 13061 13062 Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) 13063 rec-route = name-addr *( SEMI rr-param ) 13064 rr-param = generic-param 13065 13066 13067 13068 13069 J. Rosenberg et. al. [Page 230] 13070 Internet Draft SIP February 18, 2002 13071 13072 13073 Reply-To = "Reply-To" HCOLON rplyto-spec 13074 rplyto-spec = ( name-addr / addr-spec ) 13075 *( SEMI rplyto-param ) 13076 rplyto-param = generic-param 13077 Require = "Require" HCOLON option-tag *(COMMA option-tag) 13078 13079 13080 13081 13082 Retry-After = "Retry-After" HCOLON delta-seconds 13083 [ comment ] *( SEMI retry-param ) 13084 retry-param = ("duration" EQUAL delta-seconds) 13085 / generic-param 13086 13087 13088 13089 13090 Route = "Route" HCOLON route-param *(COMMA route-param) 13091 route-param = name-addr *( SEMI rr-param ) 13092 13093 13094 13095 13096 Server = "Server" HCOLON 1*( product / comment ) 13097 product = token [SLASH product-version] 13098 product-version = token 13099 13100 13101 13102 13103 Subject = ( "Subject" / "s" ) HCOLON TEXT-UTF8-TRIM 13104 13105 13106 13107 13108 Supported = ( "Supported" / "k" ) HCOLON 13109 [option-tag *(COMMA option-tag)] 13110 13111 13112 13113 13114 Timestamp = "Timestamp" HCOLON 1*(DIGIT) 13115 [ "." *(DIGIT) ] [ delay ] 13116 delay = *(DIGIT) [ "." *(DIGIT) ] 13117 13118 13119 13120 13121 13122 13123 13124 J. Rosenberg et. al. [Page 231] 13125 Internet Draft SIP February 18, 2002 13126 13127 13128 To = ( "To" / "t" ) HCOLON ( name-addr 13129 / addr-spec ) *( SEMI to-param ) 13130 to-param = tag-param / generic-param 13131 13132 13133 13134 13135 Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) 13136 13137 13138 13139 13140 User-Agent = "User-Agent" HCOLON 1*( product / comment ) 13141 13142 13143 13144 13145 Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) 13146 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 13147 via-params = via-ttl / via-maddr 13148 / via-received / via-branch 13149 / via-extension 13150 via-ttl = "ttl" EQUAL ttl 13151 via-maddr = "maddr" EQUAL host 13152 via-received = "received" EQUAL (IPv4address / IPv6address) 13153 via-branch = "branch" EQUAL token 13154 via-extension = generic-param 13155 sent-protocol = protocol-name SLASH protocol-version 13156 SLASH transport 13157 protocol-name = "SIP" / token 13158 protocol-version = token 13159 transport = "UDP" / "TCP" / "TLS" / "SCTP" 13160 / other-transport 13161 sent-by = host [ COLON port ] 13162 ttl = 1*3DIGIT ; 0 to 255 13163 13164 13165 13166 13167 Warning = "Warning" HCOLON warning-value *(COMMA warning-value) 13168 warning-value = warn-code SP warn-agent SP warn-text 13169 warn-code = 3DIGIT 13170 warn-agent = hostport / pseudonym 13171 ; the name or pseudonym of the server adding 13172 ; the Warning header, for use in debugging 13173 warn-text = quoted-string 13174 pseudonym = token 13175 13176 13177 13178 13179 J. Rosenberg et. al. [Page 232] 13180 Internet Draft SIP February 18, 2002 13181 13182 13183 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge 13184 13185 13186 13187 13188 extension-header = header-name HCOLON header-value 13189 header-name = token 13190 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 13191 13192 13193 13194 13195 message-body = *OCTET 13196 13197 13198 26 Security Considerations: Threat Model and Security Usage 13199 Recommendations 13200 13201 SIP is not an easy protocol to secure. Its use of intermediaries, its 13202 multi-faceted trust relationships, its expected usage between 13203 elements with no trust at all, and its user-to-user operation make 13204 security far from trivial. Security solutions are needed that are 13205 deployable today, without extensive coordination, in a wide variety 13206 of environments and usages. In order to meet these diverse needs, 13207 several distinct mechanisms applicable to different aspects and 13208 usages of SIP will be required. 13209 13210 Note that the security of SIP signaling itself has no bearing on the 13211 security of protocols used in concert with SIP such as RTP, or with 13212 the security implications of any specific bodies SIP might carry 13213 (although MIME security plays a substantial role in securing SIP). 13214 Any media associated with a session can be encrypted end-to-end 13215 independently of any associated SIP signaling. Media encryption is 13216 outside the scope of this document. 13217 13218 The considerations that follow first examine a set of classic threat 13219 models that broadly identify the security needs of SIP. The set of 13220 security services required to address these threats is then detailed, 13221 followed by an explanation of several security mechanisms that can be 13222 used to provide these services. Next, the requirements for 13223 implementers of SIP are enumerated, along with exemplary deployments 13224 in which these security mechanisms could be used to improve the 13225 security of SIP. Some notes on privacy conclude this section. 13226 13227 26.1 Attacks and Threat Models 13228 13229 This section details some threats that should be common to most 13230 deployments of SIP. These threats have been chosen specifically to 13231 13232 13233 13234 J. Rosenberg et. al. [Page 233] 13235 Internet Draft SIP February 18, 2002 13236 13237 13238 illustrate each of the security services that SIP requires. 13239 13240 The following examples by no means provide an exhaustive list of the 13241 threats against SIP; rather, these are "classic" threats that 13242 demonstrate the need for particular security services that can 13243 potentially prevent whole categories of threats. 13244 13245 These attacks assume an environment in which attackers can 13246 potentially read any packet on the network - it is anticipated that 13247 SIP will frequently be used on the public Internet. Attackers on the 13248 network may be able to modify packets (perhaps at some compromised 13249 intermediary). Attackers may wish to steal services, eavesdrop on 13250 communications, or disrupt sessions. 13251 13252 26.1.1 Registration Hijacking 13253 13254 The SIP registration mechanism allows a user agent to identify itself 13255 to a registrar as a device at which a user (designated by an address 13256 of record) is located. A registrar assesses the identity asserted in 13257 the From header field of a REGISTER message to determine whether this 13258 request can modify the contact addresses associated with the 13259 address-of-record in the To header field. While these two fields are 13260 frequently the same, there are many valid deployments in which a 13261 third-party may register contacts on a user's behalf. 13262 13263 The From header field of a SIP request, however, can be modified 13264 arbitrarily by the owner of a UA, and this opens the door to 13265 malicious registrations. An attacker that successfully impersonates a 13266 party authorized to change contacts associated with an address-of- 13267 record could, for example, de-register all existing contacts for a 13268 URI and then register their own device as the appropriate contact 13269 address, thereby directing all requests for the affected user to the 13270 attacker's device. 13271 13272 This threat belongs to a family of threats that rely on the absence 13273 of cryptographic assurance of a request's originator. Any SIP UAS 13274 that represents a valuable service (a gateway that interworks SIP 13275 requests with traditional telephone calls, for example) might want to 13276 control access to its resources by authenticating requests that it 13277 receives. Even end-user UAs, for example SIP phones, have an 13278 interest in ascertaining the identities of originators of requests. 13279 13280 This threat demonstrates the need for security services that enable 13281 SIP entities to authenticate the originators of requests. 13282 13283 26.1.2 Impersonating a Server 13284 13285 The domain to which a request is destined is generally specified in 13286 13287 13288 13289 J. Rosenberg et. al. [Page 234] 13290 Internet Draft SIP February 18, 2002 13291 13292 13293 the Request-URI. UAs commonly contact a server in this domain 13294 directly in order to deliver a request. However, there is always a 13295 possibility that an attacker could impersonate the remote server, and 13296 that the UA's request could be intercepted by some other party. 13297 13298 For example, consider a case in which a redirect server at one 13299 domain, chicago.com, impersonates a redirect server at another 13300 domain, biloxi.com. A user agent sends a request to biloxi.com, but 13301 the redirect server at chicago.com answers with a forged response 13302 that has appropriate SIP header fields for a response from 13303 biloxi.com. The forged contact addresses in the redirection response 13304 could direct the originating UA to inappropriate or insecure 13305 resources, or simply prevent requests for biloxi.com from succeeding. 13306 13307 This family of threats has a vast membership, many of which are 13308 critical. As a converse to the registration hijacking threat, 13309 consider the case in which a registration sent to biloxi.com is 13310 intercepted by chicago.com, which replies to the intercepted 13311 registration with a forged 301 (Moved Permanently) response. This 13312 response might seem to come from biloxi.com yet designate chicago.com 13313 as the appropriate registrar. All future REGISTER requests from the 13314 originating UA would then go to chicago.com. 13315 13316 Prevention of this threat requires a means by which UAs can 13317 authenticate the servers to whom they send requests. 13318 13319 26.1.3 Tampering with Message Bodies 13320 13321 As a matter of course, SIP UAs route requests through trusted proxy 13322 servers. Regardless of how that trust is established (authentication 13323 of proxies is discussed elsewhere in this section), a UA may trust a 13324 proxy server to route a request, but not to inspect or possibly 13325 modify the bodies contained in that request. 13326 13327 Consider a UA that is using SIP message bodies to communicate session 13328 encryption keys for a media session. Although it trusts the proxy 13329 server of the domain it is contacting to deliver signaling properly, 13330 it may not want the administrators of that domain to be capable of 13331 decrypting any subsequent media session. Worse yet, if the proxy 13332 server were actively malicious, it could modify the session key, 13333 either acting as a man-in-the-middle, or perhaps changing the 13334 security characteristics requested by the originating UA. 13335 13336 This family of threats applies not only to session keys, but to most 13337 conceivable forms of content carried end-to-end in SIP. These might 13338 include MIME bodies that should be rendered to the user, SDP, or 13339 encapsulated telephony signals, among others. Attackers might attempt 13340 to modify SDP bodies, for example, in order to point RTP media 13341 13342 13343 13344 J. Rosenberg et. al. [Page 235] 13345 Internet Draft SIP February 18, 2002 13346 13347 13348 streams to a wiretapping device in order to eavesdrop on subsequent 13349 voice communications. 13350 13351 Also note that some header fields in SIP are meaningful end-to-end, 13352 for example, Subject. UAs might be protective of these header fields 13353 as well as bodies (a malicious intermediary changing the Subject 13354 header field might make an important request appear to be spam, for 13355 example). However, since many header fields are legitimately 13356 inspected or altered by proxy servers as a request is routed, not all 13357 header fields should be secured end-to-end. 13358 13359 For these reasons, the UA might want to secure SIP message bodies, 13360 and in some limited cases header fields, end-to-end. The security 13361 services required for bodies include confidentiality, integrity, and 13362 authentication. These end-to-end services should be independent of 13363 the means used to secure interactions with intermediaries such as 13364 proxy servers. 13365 13366 26.1.4 Tearing Down Sessions 13367 13368 Once a dialog has been established by initial messaging, subsequent 13369 requests can be sent that modify the state of the dialog and/or 13370 session. It is critical that principals in a session can be certain 13371 that such requests are not forged by attackers. 13372 13373 Consider a case in which a third-party attacker captures some initial 13374 messages in a dialog shared by two parties in order to learn the 13375 parameters of the session (To tag, From tag, and so forth) and then 13376 inserts a BYE request into the session. The attacker could opt to 13377 forge the request such that it seemed to come from either 13378 participant. Once the BYE is received by its target, the session will 13379 be torn down prematurely. 13380 13381 Similar mid-session threats include the transmission of forged re- 13382 INVITEs that alter the session (possibly to reduce session security 13383 or redirect media streams as part of a wiretapping attack). 13384 13385 The most effective countermeasure to this threat is the 13386 authentication of the sender of the BYE. In this instance, the 13387 recipient needs only know that the BYE came from the same party with 13388 whom the corresponding dialog was established (as opposed to 13389 ascertaining the absolute identity of the sender). Also, if the 13390 attacker is unable to learn the parameters of the session due to 13391 confidentiality, it would not be possible to forge the BYE. However, 13392 some intermediaries (like proxy servers) will need to inspect those 13393 parameters as the session is established. 13394 13395 26.1.5 Denial of Service and Amplification 13396 13397 13398 13399 J. Rosenberg et. al. [Page 236] 13400 Internet Draft SIP February 18, 2002 13401 13402 13403 Denial-of-service attacks focus on rendering a particular network 13404 element unavailable, usually by directing an excessive amount of 13405 network traffic at its interfaces. A distributed denial-of-service 13406 attack allows one network user to cause multiple network hosts to 13407 flood a target host with a large amount of network traffic. 13408 13409 In many architectures, SIP proxy servers face the public Internet in 13410 order to accept requests from worldwide IP endpoints. SIP creates a 13411 number of potential opportunities for distributed denial-of-service 13412 attacks that must be recognized and addressed by the implementers and 13413 operators of SIP systems. 13414 13415 Attackers can create bogus requests that contain a falsified source 13416 IP address and a corresponding Via header field that identify a 13417 targeted host as the originator of the request and then send this 13418 request to a large number of SIP network elements, thereby using 13419 hapless SIP UAs or proxies to generate denial-of-service traffic 13420 aimed at the target. 13421 13422 Similarly, attackers might use falsified Route header field values in 13423 a request that identify the target host and then send such messages 13424 to forking proxies that will amplify messaging sent to the target. 13425 Record-Route could be used to similar effect when the attacker is 13426 certain that the SIP dialog initiated by the request will result in 13427 numerous transactions originating in the backwards direction. 13428 13429 A number of denial-of-service attacks open up if REGISTER requests 13430 are not properly authenticated and authorized by registrars. 13431 Attackers could de-register some or all users in an administrative 13432 domain, thereby preventing these users from being invited to new 13433 sessions. An attacker could also register a large number of contacts 13434 designating the same host for a given address-of-record in order to 13435 use the registrar and any associated proxy servers as amplifiers in a 13436 denial-of-service attack. Attackers might also attempt to deplete 13437 available memory and disk resources of a registrar by registering 13438 huge numbers of bindings. 13439 13440 The use of multicast to transmit SIP requests can greatly increase 13441 the potential for denial-of-service attacks. 13442 13443 These problems demonstrate a general need to define architectures 13444 that minimize the risks of denial-of-service, and the need to be 13445 mindful in recommendations for security mechanisms of this class of 13446 attacks. 13447 13448 26.2 Security Mechanisms 13449 13450 From the threats described above, we gather that the fundamental 13451 13452 13453 13454 J. Rosenberg et. al. [Page 237] 13455 Internet Draft SIP February 18, 2002 13456 13457 13458 security services required for the SIP protocol are: preserving the 13459 confidentiality and integrity of messaging, preventing replay attacks 13460 or message spoofing, providing for the authentication and privacy of 13461 the participants in a session, and preventing denial-of-service 13462 attacks. Bodies within SIP messages separately require the security 13463 services of confidentiality, integrity, and authentication. 13464 13465 Rather than defining new security mechanisms specific to SIP, SIP 13466 reuses wherever possible existing security models derived from the 13467 HTTP and SMTP space. 13468 13469 Full encryption of messages provides the best means to preserve the 13470 confidentiality of signaling - it can also guarantee that messages 13471 are not modified by any malicious intermediaries. However, SIP 13472 requests and responses cannot be naively encrypted end-to-end in 13473 their entirety because message fields such as the Request-URI, Route, 13474 and Via need to be visible to proxies in most network architectures 13475 so that SIP requests are routed correctly. Note that proxy servers 13476 need to modify some features of messages as well (such as adding Via 13477 header field values) in order for SIP to function. Proxy servers must 13478 therefore be trusted, to some degree, by SIP UAs. To this purpose, 13479 low-layer security mechanisms for SIP are recommended, which encrypt 13480 the entire SIP requests or responses on the wire on a hop-by-hop 13481 basis, and that allow endpoints to verify the identity of proxy 13482 servers to whom they send requests. 13483 13484 SIP entities also have a need to identify one another in a secure 13485 fashion. When a SIP endpoint asserts the identity of its user to a 13486 peer UA or to a proxy server, that identity should in some way be 13487 verifiable. A cryptographic authentication mechanism is provided in 13488 SIP to address this requirement. 13489 13490 An independent security mechanism for SIP message bodies supplies an 13491 alternative means of end-to-end mutual authentication, as well as 13492 providing a limit on the degree to which user agents must trust 13493 intermediaries. 13494 13495 26.2.1 Transport and Network Layer Security 13496 13497 Transport or network layer security encrypts signaling traffic, 13498 guaranteeing message confidentiality and integrity. 13499 13500 Oftentimes, certificates are used in the establishment of lower-layer 13501 security, and these certificates can also be used to provide a means 13502 of authentication in many architectures. 13503 13504 Two popular alternatives for providing security at the transport and 13505 network layer are, respectively, TLS [24] and IPSec [25]. 13506 13507 13508 13509 J. Rosenberg et. al. [Page 238] 13510 Internet Draft SIP February 18, 2002 13511 13512 13513 IPSec is a set of network-layer protocol tools that collectively can 13514 be used as a secure replacement for traditional IP (Internet 13515 Protocol). IPSec is most commonly used in architectures in which a 13516 set of hosts or administrative domains have an existing trust 13517 relationship with one another. IPSec is usually implemented at the 13518 operating system level in a host, or on a security gateway that 13519 provides confidentiality and integrity for all traffic it receives 13520 from a particular interface (as in a VPN architecture). IPSec can 13521 also be used on a hop-by-hop basis. 13522 13523 In many architectures IPSec does not require integration with SIP 13524 applications; IPSec is perhaps best suited to deployments in which 13525 adding security directly to SIP hosts would be arduous. UAs that have 13526 a pre-shared keying relationship with their first-hop proxy server 13527 are also good candidates to use IPSec. Any deployment of IPSec for 13528 SIP would require an IPSec profile describing the protocol tools that 13529 would be required to secure SIP. No such profile is given in this 13530 document. 13531 13532 TLS provides transport-layer security over connection-oriented 13533 protocols (for the purposes of this document, TCP); "tls" (signifying 13534 TLS over TCP) can be specified as the desired transport protocol 13535 within a Via header field value or a SIP-URI. TLS is most suited to 13536 architectures in which hop-by-hop security is required between hosts 13537 with no pre-existing trust association. For example, Alice trusts 13538 her local proxy server, which after a certificate exchange decides to 13539 trust Bob's local proxy server, which Bob trusts, hence Bob and Alice 13540 can communicate securely. 13541 13542 TLS must be tightly coupled with a SIP application. Note that 13543 transport mechanisms are specified on a hop-by-hop basis in SIP, thus 13544 a UA that sends requests over TLS to a proxy server has no assurance 13545 that TLS will be used end-to-end. 13546 13547 The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 13548 minimum by implementers when TLS is used in a SIP application. For 13549 purposes of backwards compatibility, proxy servers, redirect servers, 13550 and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. 13551 Implementers MAY also support any other ciphersuite. 13552 13553 26.2.2 SIPS URI scheme 13554 13555 The SIPS URI scheme adheres to the syntax of the SIP URI (described 13556 in 19), although the scheme string is "sips" rather than "sip". The 13557 semantics of SIPS are very different from the SIP URI, however. 13558 13559 A SIPS URI can be used as an address-of-record for a particular user 13560 - the URI by which the user is canonically known (on their business 13561 13562 13563 13564 J. Rosenberg et. al. [Page 239] 13565 Internet Draft SIP February 18, 2002 13566 13567 13568 cards, in the From header field of their requests, in the To header 13569 field of REGISTER requests). When used as the Request-URI of a 13570 request, the SIPS scheme signifies that each hop over which the 13571 request is forwarded must be secured with TLS. When used by the 13572 originator of a request (as would be the case if they encountered a 13573 SIPS URI as the address-of-record of the target), SIPS dictates that 13574 the entire request path be so secured. No other mechanism in SIP 13575 allows the originator of a request to specify security 13576 characteristics that are preferred for the entire request path. 13577 13578 The SIPS scheme is also applicable to many of the other ways in which 13579 SIP URIs are used in SIP today, including in the Request-URI, in 13580 addresses-of-record, contact addresses (populating Contact headers, 13581 including those of REGISTER methods), and Route headers. The SIPS URI 13582 scheme allows these existing fields to designate secure resources. 13583 13584 In effect, using SIPS in the Request-URI ensures that TLS is used on 13585 every segment between the originator of the request and the 13586 destination. This is a handy service, though one that is useful only 13587 in architectures in which it is desirable to use TLS for every hop. 13588 13589 The use of SIPS in particular entails that mutual TLS authentication 13590 SHOULD be employed, as SHOULD the ciphersuite 13591 TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the 13592 authentication process SHOULD be verified against root certificates 13593 in the client; failure to verify a certificate SHOULD result in the 13594 failure of the request. 13595 13596 motivationNote that in the SIPS URI scheme, transport is independent 13597 of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and 13598 "sips:alice@atlanta.com;transport=sctp" are both valid (although note 13599 that UDP is not a valid transport for SIPS). The use of 13600 "transport=tls" has consequently been deprecated, partly because it 13601 was specific to a single hop of the request. This is a change since 13602 RFC 2543. 13603 13604 Users that distribute a SIPS URI as an address-of-record may elect to 13605 operate devices that do not even accept requests over insecure 13606 transports. 13607 13608 26.2.3 HTTP Authentication 13609 13610 SIP provides a challenge capability, based on HTTP authentication, 13611 that relies on the 401 and 407 response codes as well as header 13612 fields for carrying challenges and credentials. Without significant 13613 modification, the reuse of the HTTP Digest authentication scheme in 13614 SIP allows for replay protection and one-way authentication. 13615 13616 13617 13618 13619 J. Rosenberg et. al. [Page 240] 13620 Internet Draft SIP February 18, 2002 13621 13622 13623 The usage of Digest authentication in SIP is detailed in Section 22. 13624 13625 26.2.4 S/MIME 13626 13627 As is discussed above, encrypting entire SIP messages end-to-end for 13628 the purpose of confidentiality is not appropriate because network 13629 intermediaries (like proxy servers) need to view certain header 13630 fields in order to route messages correctly, and if these 13631 intermediaries are excluded from security associations, then SIP 13632 messages will essentially be non-routable. 13633 13634 However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, 13635 securing these bodies end-to-end without affecting message headers. 13636 S/MIME can provide end-to-end confidentiality and integrity for 13637 message bodies, as well as mutual authentication. It is also possible 13638 to use S/MIME to provide a form of integrity and confidentiality for 13639 SIP header fields through SIP message tunneling. 13640 13641 The usage of S/MIME in SIP is detailed in Section 23. 13642 13643 26.3 Implementing Security Mechanisms 13644 13645 26.3.1 Requirements for Implementers of SIP 13646 13647 Proxy servers, redirect servers, and registrars MUST implement TLS, 13648 and MUST support both mutual and one-way authentication. It is 13649 strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also 13650 be capable of acting as a TLS server. Proxy servers, redirect 13651 servers, and registrars SHOULD possess a site certificate whose 13652 subject corresponds to their canonical hostname. UAs MAY have 13653 certificates of their own for mutual authentication with TLS, but no 13654 provisions are set forth in this document for their use. All SIP 13655 elements that support TLS MUST have a mechanism for verifying 13656 certificates received during TLS negotiation; this entails possession 13657 of one or more root certificates issued by certificate authorities 13658 (preferably well-known distributors of site certificates comparable 13659 to those issuing root certificates for web browsers). All SIP 13660 elements that support TLS MUST also support the SIPS URI scheme. 13661 13662 Proxy servers, redirect servers, registrars, and UAs MAY also 13663 implement IPSec or other lower-layer security protocols. 13664 13665 When a UA attempts to contact a proxy server, redirect server, or 13666 registrar, the UAC SHOULD initiate a TLS connection over which it 13667 will send SIP messages. In some architectures, UASs MAY receive 13668 requests over such TLS connections as well. 13669 13670 Proxy servers, redirect servers, registrars, and UAs MUST implement 13671 13672 13673 13674 J. Rosenberg et. al. [Page 241] 13675 Internet Draft SIP February 18, 2002 13676 13677 13678 Digest Authorization, encompassing all of the aspects required in 22. 13679 Proxy servers, redirect servers, and registrars SHOULD be configured 13680 with at least one Digest realm, and at least one "realm" string 13681 supported by a given server SHOULD correspond to the server's 13682 hostname or domainname. 13683 13684 UAs MAY support the signing and encrypting of MIME bodies, and 13685 transference of credentials with S/MIME as described in 23. If a UA 13686 holds one or more root certificates of certificate authorities in 13687 order to verify certificates for TLS or IPSec, it SHOULD be capable 13688 of reusing these to verify S/MIME certificates, as appropriate. A UA 13689 MAY hold root certificates specifically for verifying S/MIME 13690 certificates. 13691 13692 13693 Note that is it anticipated that future security extensions 13694 may upgrade the normative strength associated with S/MIME 13695 as S/MIME implementations appear and the problem space 13696 becomes better understood. 13697 13698 26.3.2 Security Solutions 13699 13700 The operation of these security mechanisms in concert can follow the 13701 existing web and email security models to some degree. At a high 13702 level, UAs authenticate themselves to servers (proxy servers, 13703 redirect servers, and registrars) with a Digest username and 13704 password; servers authenticate themselves to UAs one hop away, or to 13705 another server one hop away (and vice versa), with a site certificate 13706 delivered by TLS. 13707 13708 On a peer-to-peer level, UAs trust the network to authenticate one 13709 another ordinarily; however, S/MIME can also be used to provide 13710 direct authentication when the network does not, or if the network 13711 itself is not trusted. 13712 13713 The following is an illustrative example in which these security 13714 mechanisms are used by various UAs and servers to prevent the sorts 13715 of threats described in Section 26.1. While implementers and network 13716 administrators MAY follow the normative guidelines given in the 13717 remainder of this section, these are provided only as example 13718 implementations. 13719 13720 26.3.2.1 Registration 13721 13722 When a UA comes online and registers with its local administrative 13723 domain, it SHOULD establish a TLS connection with its registrar 13724 (Section 10 describes how the UA reaches its registrar). The 13725 registrar SHOULD offer a certificate to the UA, and the site 13726 13727 13728 13729 J. Rosenberg et. al. [Page 242] 13730 Internet Draft SIP February 18, 2002 13731 13732 13733 identified by the certificate MUST correspond with the domain in 13734 which the UA intends to register; for example, if the UA intends to 13735 register the address-of-record 'alice@atlanta.com', the site 13736 certificate must identify a host within the atlanta.com domain (such 13737 as sip.atlanta.com). When it receives the TLS Certificate message, 13738 the UA SHOULD verify the certificate and inspect the site identified 13739 by the certificate. If the certificate is invalid, revoked, or if it 13740 does not identify the appropriate party, the UA MUST NOT send the 13741 REGISTER message and otherwise proceed with the registration. 13742 13743 13744 When a valid certificate has been provided by the 13745 registrar, the UA knows that the registrar is not an 13746 attacker who might redirect the UA, steal passwords, or 13747 attempt any similar attacks. 13748 13749 The UA then creates a REGISTER request that SHOULD be addressed to a 13750 Request-URI corresponding to the site certificate received from the 13751 registrar. When the UA sends the REGISTER request over the existing 13752 TLS connection, the registrar SHOULD challenge the request with a 401 13753 (Proxy Authentication Required) response. The "realm" parameter 13754 within the Proxy-Authenticate header field of the response SHOULD 13755 correspond to the domain previously given by the site certificate. 13756 When the UAC receives the challenge, it SHOULD either prompt the user 13757 for credentials or take an appropriate credential from a keyring 13758 corresponding to the "realm" parameter in the challenge. The username 13759 of this credential SHOULD correspond with the "userinfo" portion of 13760 the URI in the To header field of the REGISTER request. Once the 13761 Digest credentials have been inserted into an appropriate Proxy- 13762 Authorization header field, the REGISTER should be resubmitted to the 13763 registrar. 13764 13765 13766 Since the registrar requires the user agent to authenticate 13767 itself, it would be difficult for an attacker to forge 13768 REGISTER requests for the user's address-of-record. Also 13769 note that since the REGISTER is sent over a confidential 13770 TLS connection, attackers will not be able to intercept the 13771 REGISTER to record credentials for any possible replay 13772 attack. 13773 13774 Once the registration has been accepted by the registrar, the UA 13775 SHOULD leave this TLS connection open provided that the registrar 13776 also acts as the proxy server to which requests are sent for users in 13777 this administrative domain. The existing TLS connection will be 13778 reused to deliver incoming requests to the UA that has just completed 13779 registration. 13780 13781 13782 13783 13784 J. Rosenberg et. al. [Page 243] 13785 Internet Draft SIP February 18, 2002 13786 13787 13788 Because the UA has already authenticated the server on the 13789 other side of the TLS connection, all requests that come 13790 over this connection are known to have passed through the 13791 proxy server - attackers cannot create spoofed requests 13792 that appear to have been sent through that proxy server. 13793 13794 26.3.2.2 Interdomain Requests 13795 13796 Now let's say that Alice's UA would like to initiate a session with a 13797 user in a remote administrative domain, namely "bob@biloxi.com". We 13798 will also say that the local administrative domain (atlanta.com) has 13799 a local outbound proxy. 13800 13801 The proxy server that handles inbound requests for an administrative 13802 domain MAY also act as a local outbound proxy; for simplicity's sake 13803 we'll assume this to be the case for atlanta.com (otherwise the user 13804 agent would initiate a new TLS connection to a separate server at 13805 this point). Assuming that the client has completed the registration 13806 process described in the preceding section, it SHOULD reuse the TLS 13807 connection to the local proxy server when it sends an INVITE request 13808 to another user. The UA SHOULD reuse cached credentials in the INVITE 13809 to avoid prompting the user unnecessarily. 13810 13811 When the local outbound proxy server has validated the credentials 13812 presented by the UA in the INVITE, it SHOULD inspect the Request-URI 13813 to determine how the message should be routed (see [4]). If the 13814 "domainname" portion of the Request-URI had corresponded to the local 13815 domain (atlanta.com) rather than biloxi.com, then the proxy server 13816 would have consulted its location service to determine how best to 13817 reach the requested user. 13818 13819 13820 Had "alice@atlanta.com" been attempting to contact, say, 13821 "alex@atlanta.com", the local proxy would have proxied to 13822 the request to the TLS connection Alex had established with 13823 the registrar when he registered. Since Alex would receive 13824 this request over his authenticated channel, he would be 13825 assured that Alice's request had been authorized by the 13826 proxy server of the local administrative domain. 13827 13828 However, in this instance the Request-URI designates a remote domain. 13829 The local outbound proxy server at atlanta.com SHOULD therefore 13830 establish a TLS connection with the remote proxy server at 13831 biloxi.com. Since both of the participants in this TLS connection are 13832 servers that possess site certificates, mutual TLS authentication 13833 SHOULD occur. Each side of the connection SHOULD verify and inspect 13834 the certificate of the other, noting the domain name that appears in 13835 the certificate for comparison with the header fields of SIP 13836 13837 13838 13839 J. Rosenberg et. al. [Page 244] 13840 Internet Draft SIP February 18, 2002 13841 13842 13843 messages. The atlanta.com proxy server, for example, SHOULD verify at 13844 this stage that the certificate received from the remote side 13845 corresponds with the biloxi.com domain. Once it has done so, and TLS 13846 negotiation has completed, resulting in a secure channel between the 13847 two proxies, the atlanta.com proxy can forward the INVITE request to 13848 biloxi.com. 13849 13850 The proxy server at biloxi.com SHOULD inspect the certificate of the 13851 proxy server at atlanta.com in turn and compare the domain asserted 13852 by the certificate with the "domainname" portion of the From header 13853 field in the INVITE request. The biloxi proxy MAY have a strict 13854 security policy that requires it to reject requests that do not match 13855 the administrative domain from which they have been proxied. 13856 13857 13858 Such security policies could be instituted to prevent the 13859 SIP equivalent of SMTP 'open relays' that are frequently 13860 exploited to generate spam. 13861 13862 This policy, however, only guarantees that the request came from the 13863 domain it ascribes to itself; it does not allow biloxi.com to 13864 ascertain how atlanta.com authenticated Alice. Only if biloxi.com has 13865 some other way of knowing atlanta.com's authentication policies could 13866 it possibly ascertain how Alice proved her identity. biloxi.com might 13867 then institute an even stricter policy that forbids requests that 13868 come from domains that are not known administratively to share a 13869 common authentication policy with biloxi.com. 13870 13871 Once the INVITE has been approved by the biloxi proxy, the proxy 13872 server SHOULD identify the existing TLS channel, if any, associated 13873 with the user targeted by this request (in this case 13874 "bob@biloxi.com"). The INVITE should be proxied through this channel 13875 to Bob. Since the request is received over a TLS connection that had 13876 previously been authenticated as the biloxi proxy, Bob knows that the 13877 From header field was not tampered with and that atlanta.com has 13878 validated Alice, although not necessarily whether or not to trust 13879 Alice's identity. 13880 13881 Before they forward the request, both proxy servers SHOULD add a 13882 Record-Route header field to the request so that all future requests 13883 in this dialog will pass through the proxy servers. The proxy servers 13884 can thereby continue to provide security services for the lifetime of 13885 this dialog. If the proxy servers do not add themselves to the 13886 Record-Route, future messages will pass directly end-to-end between 13887 Alice and Bob without any security services (unless the two parties 13888 agree on some independent end-to-end security such as S/MIME). In 13889 this respect the SIP trapezoid model can provide a nice structure 13890 where conventions of agreement between the site proxies can provide a 13891 13892 13893 13894 J. Rosenberg et. al. [Page 245] 13895 Internet Draft SIP February 18, 2002 13896 13897 13898 reasonably secure channel between Alice and Bob. 13899 13900 13901 An attacker preying on this architecture would, for 13902 example, be unable to forge a BYE request and insert it 13903 into the signaling stream between Bob and Alice because the 13904 attacker has no way of ascertaining the parameters of the 13905 session and also because the integrity mechanism 13906 transitively protects the traffic between Alice and Bob. 13907 13908 26.3.2.3 Peer to Peer Requests 13909 13910 Alternatively, consider a UA asserting the identity 13911 "carol@chicago.com" that has no local outbound proxy. When Carol 13912 wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate 13913 a TLS connection with the biloxi proxy directly (using the mechanism 13914 described in [4] to determine how to best to reach the given 13915 Request-URI). When her UA receives a certificate from the biloxi 13916 proxy, it SHOULD be verified normally before she passes her INVITE 13917 across the TLS connection. However, Carol has no means of proving her 13918 identity to the biloxi proxy, but she does have a CMS-detached 13919 signature over a "message/sip" body in the INVITE. It is unlikely in 13920 this instance that Carol would have any credentials in the biloxi.com 13921 realm, since she has no formal association with biloxi.com. The 13922 biloxi proxy MAY also have a strict policy that precludes it from 13923 even bothering to challenge requests that do not have biloxi.com in 13924 the "domainname" portion of the From header field - it treats these 13925 users as unauthenticated. 13926 13927 The biloxi proxy has a policy for Bob that all non-authenticated 13928 requests should be redirected to the appropriate contact address 13929 registered against 'bob@biloxi.com', namely . 13930 Carol receives the redirection response over the TLS connection she 13931 established with the biloxi proxy, so she trusts the veracity of the 13932 contact address. 13933 13934 Carol SHOULD then establish a TCP connection with the designated 13935 address and send a new INVITE with a Request-URI containing the 13936 received contact address (recomputing the signature in the body as 13937 the request is readied). Bob receives this INVITE on an insecure 13938 interface, but his UA inspects and, in this instance, recognizes the 13939 From header field of the request and subsequently matches a locally 13940 cached certificate with the one presented in the signature of the 13941 body of the INVITE. He replies in similar fashion, authenticating 13942 himself to Carol, and a secure dialog begins. 13943 13944 13945 Sometimes firewalls or NATs in an administrative domain 13946 13947 13948 13949 J. Rosenberg et. al. [Page 246] 13950 Internet Draft SIP February 18, 2002 13951 13952 13953 could preclude the establishment of a direct TCP connection 13954 to a UA. In these cases, proxy servers could also 13955 potentially relay requests to UAs in a way that has no 13956 trust implications (for example, forgoing an existing TLS 13957 connection and forwarding the request over cleartext TCP) 13958 as local policy dictates. 13959 13960 26.3.2.4 DoS Protection 13961 13962 In order to minimize the risk of a denial-of-service attack against 13963 architectures using these security solutions, implementers should 13964 take note of the following guidelines. 13965 13966 When the host on which a SIP proxy server is operating is routable 13967 from the public Internet, it SHOULD be deployed in an administrative 13968 domain with defensive operational policies (blocking source-routed 13969 traffic, preferably filtering ping traffic). Both TLS and IPSec can 13970 also make use of bastion hosts at the edges of administrative domains 13971 that participate in the security associations to aggregate secure 13972 tunnels and sockets. These bastion hosts can also take the brunt of 13973 denial-of-service attacks, ensuring that SIP hosts within the 13974 administrative domain are not encumbered with superfluous messaging. 13975 13976 No matter what security solutions are deployed, floods of messages 13977 directed at proxy servers can lock up proxy server resources and 13978 prevent desirable traffic from reaching its destination. There is a 13979 computational expense associated with processing a SIP transaction at 13980 a proxy server, and that expense is greater for stateful proxy 13981 servers than it is for stateless proxy servers. Therefore, stateful 13982 proxies are more susceptible to flooding than stateless proxy 13983 servers. 13984 13985 UAs and proxy servers SHOULD challenge questionable requests with 13986 only a single 401 (Unauthorized) or 407 (Proxy Authentication 13987 Required), forgoing the normal response retransmission algorithm, and 13988 thus behaving statelessly towards unauthenticated requests. 13989 13990 13991 Retransmitting the 401 (Unauthorized) or 407 (Proxy 13992 Authentication Required) status response amplifies the 13993 problem of an attacker using a falsified header field value 13994 (such as Via) to direct traffic to a third party. 13995 13996 In summary, the mutual authentication of proxy servers through 13997 mechanisms such as TLS significantly reduces the potential for rogue 13998 intermediaries to introduce falsified requests or responses that can 13999 deny service. This commensurately makes it harder for attackers to 14000 make innocent SIP nodes into agents of amplification. 14001 14002 14003 14004 J. Rosenberg et. al. [Page 247] 14005 Internet Draft SIP February 18, 2002 14006 14007 14008 26.4 Limitations 14009 14010 Although these security mechanisms, when applied in a judicious 14011 manner, can thwart many threats, there are limitations in the scope 14012 of the mechanisms that must be understood by implementers and network 14013 operators. 14014 14015 26.4.1 HTTP Digest 14016 14017 One of the primary limitations of using HTTP Digest in SIP is that 14018 the integrity mechanisms in Digest do not work very well for SIP. 14019 Specifically, they offer protection of the Request-URI and the method 14020 of a message, but not for any of the header fields that UAs would 14021 most likely wish to secure. 14022 14023 The existing replay protection mechanisms described in RFC 2617 also 14024 have some limitations for SIP. The next-nonce mechanism, for example, 14025 does not support pipelined requests. The nonce-count mechanism should 14026 be used for replay protection. 14027 14028 Another limitation of HTTP Digest is the scope of realms. Digest is 14029 valuable when a user wants to authenticate themselves to a resource 14030 with which they have a pre-existing association, like a service 14031 provider of which the user is a customer (which is quite a common 14032 scenario and thus Digest provides an extremely useful function). By 14033 way of contrast, the scope of TLS is interdomain or multirealm, since 14034 certificates are often globally verifiable, so that the UA can 14035 authenticate the server with no pre-existing association. 14036 14037 26.4.2 S/MIME 14038 14039 The largest outstanding defect with the S/MIME mechanism is the lack 14040 of a prevalent public key infrastructure for end users. If self- 14041 signed certificates (or certificates that cannot be verified by one 14042 of the participants in a dialog) are used, the SIP-based key exchange 14043 mechanism described in Section 23.2 is susceptible to a man-in-the- 14044 middle attack with which an attacker can potentially inspect and 14045 modify S/MIME bodies. The attacker needs to intercept the first 14046 exchange of keys between the two parties in a dialog, remove the 14047 existing CMS-detached signatures from the request and response, and 14048 insert a different CMS-detached signature containing a certificate 14049 supplied by the attacker (but which seems to be a certificate for the 14050 proper address-of-record). Each party will think they have exchanged 14051 keys with the other, when in fact each has the public key of the 14052 attacker. 14053 14054 It is important to note that the attacker can only leverage this 14055 vulnerability on the first exchange of keys between two parties - on 14056 14057 14058 14059 J. Rosenberg et. al. [Page 248] 14060 Internet Draft SIP February 18, 2002 14061 14062 14063 subsequent occasions, the alteration of the key would be noticeable 14064 to the UAs. It would also be difficult for the attacker to remain in 14065 the path of all future dialogs between the two parties over time (as 14066 potentially days, weeks, or years pass). 14067 14068 SSH is susceptible to the same man-in-the-middle attack on the first 14069 exchange of keys; however, it is widely acknowledged that while SSH 14070 is not perfect, it does improve the security of connections. The use 14071 of key fingerprints could provide some assistance to SIP, just as it 14072 does for SSH. For example, if two parties use SIP to establish a 14073 voice communications session, each could read off the fingerprint of 14074 the key they received from the other, which could be compared against 14075 the original. It would certainly be more difficult for the man-in- 14076 the-middle to emulate the voices of the participants than their 14077 signaling (a practice that was used with the Clipper chip-based 14078 secure telephone). 14079 14080 The S/MIME mechanism allows UAs to send encrypted requests without 14081 preamble if they possess a certificate for the destination address- 14082 of-record on their keyring. However, it is possible that any 14083 particular device registered for an address-of-record will not hold 14084 the certificate that has been previously employed by the device's 14085 current user, and that it will therefore be unable to process an 14086 encrypted request properly, which could lead to some avoidable error 14087 signaling. This is especially likely when an encrypted request is 14088 forked. 14089 14090 The keys associated with S/MIME are most useful when associated with 14091 a particular user (an address-of-record) rather than a device (a UA). 14092 When users move between devices, it may be difficult to transport 14093 private keys securely between UAs; how such keys might be acquired by 14094 a device is outside the scope of this document. 14095 14096 Another, more prosaic difficulty with the S/MIME mechanism is that it 14097 can result in very large messages, especially when the SIP tunneling 14098 mechanism described in Section 23.4 is used. For that reason, it is 14099 RECOMMENDED that TCP should be used as a transport protocol when 14100 S/MIME tunneling is employed. 14101 14102 26.4.3 TLS 14103 14104 The most commonly voiced concern about TLS is that it cannot run over 14105 UDP; TLS requires a connection-oriented underlying transport 14106 protocol, which for the purposes of this document means TCP. 14107 14108 It may also be arduous for a local outbound proxy server and/or 14109 registrar to maintain many simultaneous long-lived TLS connections 14110 with numerous UAs. This introduces some valid scalability concerns, 14111 14112 14113 14114 J. Rosenberg et. al. [Page 249] 14115 Internet Draft SIP February 18, 2002 14116 14117 14118 especially for intensive ciphersuites. Maintaining redundancy of 14119 long-lived TLS connections, especially when a UA is solely 14120 responsible for their establishment, could also be cumbersome. 14121 14122 TLS only allows SIP entities to authenticate servers to which they 14123 are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, 14124 nor any other mechanism specified in this document, allows clients to 14125 authenticate proxy servers to whom they cannot form a direct TCP 14126 connection. 14127 14128 26.4.4 SIPS URIs 14129 14130 Using TLS on every segment of a request path entails that the 14131 terminating UAS must be reachable over TLS. This means that many 14132 hybrid architectures that use TLS to secure part of the request path, 14133 but rely on some other mechanism for the final hop to a UAS, cannot 14134 make use of the SIPS AoR. Also, since many UAs will not accept 14135 incoming TLS connections, even those UAs that do support TLS may be 14136 required to maintain persistent TLS connections as described in the 14137 TLS limitations section above. 14138 14139 It is very difficult to guarantee that TLS will be used end-to-end. 14140 It is possible that cryptographically authenticated proxy servers 14141 that are non-compliant or compromised may choose to disregard the 14142 forwarding rules associated with SIPS. These intermediaries may, for 14143 example, retarget a request from a SIPS URI to a SIP URI. It is 14144 therefore recommended that recipients of a request to SIP URI inspect 14145 the To header field value to see if it contains a SIPS URI. S/MIME 14146 may also be used to ensure that the original form of the To header 14147 field is carried end-to-end. Entities that accept only SIPS request 14148 may also refuse connections on insecure ports. 14149 14150 End users will undoubtedly discern the difference between SIPS and 14151 SIP URIs, and they may manually edit them in response to stimuli. 14152 This can either benefit or degrade security. For example, if an 14153 attacker corrupts a DNS cache, inserting a fake record set that 14154 effectively removes all SIPS records for a proxy server, then any 14155 SIPS requests that traverse this proxy server may fail. When a user, 14156 however, sees that repeated calls to a SIPS AoR are failing, on some 14157 devices they could manually convert the scheme from SIPS to SIP and 14158 retry. Of course, there are some safeguards against this (if the 14159 destination UA is truly paranoid it could refuse all non-SIPS 14160 requests), but it is a limitation worth noting. On the bright side, 14161 users might also divine that 'SIPS' would be valid even when they are 14162 presented only with a SIP URI. 14163 14164 26.5 Privacy 14165 14166 14167 14168 14169 J. Rosenberg et. al. [Page 250] 14170 Internet Draft SIP February 18, 2002 14171 14172 14173 SIP messages frequently contain sensitive information about their 14174 senders - not just what they have to say, but with whom they 14175 communicate, when they communicate and for how long, and from where 14176 they participate in sessions. Many applications and their users 14177 require that this sort of private information be hidden from any 14178 parties that do not need to know it. 14179 14180 Note that there are also less direct ways in which private 14181 information can be divulged. If a user or service chooses to be 14182 reachable at an address that is guessable from the person's name and 14183 organizational affiliation (which describes most addresses-of- 14184 record), the traditional method of ensuring privacy by having an 14185 unlisted "phone number" is compromised. A user location service can 14186 infringe on the privacy of the recipient of a session invitation by 14187 divulging their specific whereabouts to the caller; an implementation 14188 consequently SHOULD be able to restrict, on a per-user basis, what 14189 kind of location and availability information is given out to certain 14190 classes of callers. This is a whole class of problem that is 14191 expected to be studied further in ongoing SIP work. 14192 14193 In some cases, users may want to conceal personal information in 14194 header fields that convey identity. This can apply not only to the 14195 From and related headers representing the originator of the request, 14196 but also the To - it may not be appropriate to convey to the final 14197 destination a speed-dialing nickname, or an unexpanded identifier for 14198 a group of targets, either of which would be removed from the 14199 Request-URI as the request is routed, but not changed in the To 14200 header field if the two were initially identical. Thus it MAY be 14201 desirable for privacy reasons to create a To header field that 14202 differs from the Request-URI. 14203 14204 27 IANA Considerations 14205 14206 All new or experimental method names, header field names, and status 14207 codes used in SIP applications SHOULD be registered with IANA in 14208 order to prevent potential naming conflicts. It is RECOMMENDED that 14209 new "option-tag"s and "warn-code"s also be registered. Before IANA 14210 registration, new protocol elements SHOULD be described in an 14211 Internet-Draft or, preferably, an RFC. 14212 14213 For Internet-Drafts, IANA is requested to make the draft available as 14214 part of the registration database. 14215 14216 By the time an RFC is published, colliding names may have 14217 already been implemented. 14218 14219 When a registration for either a new header field, new method, or new 14220 status code is created based on an Internet-Draft, and that 14221 14222 14223 14224 J. Rosenberg et. al. [Page 251] 14225 Internet Draft SIP February 18, 2002 14226 14227 14228 Internet-Draft becomes an RFC, the person that performed the 14229 registration MUST notify IANA to change the registration to point to 14230 the RFC instead of the Internet-Draft. 14231 14232 Registrations should be sent to iana@iana.org 14233 14234 27.1 Option Tags 14235 14236 Option tags are used in header fields such as Require, Supported, 14237 Proxy-Require, and Unsupported in support of SIP compatibility 14238 mechanisms for extensions (Section 19.2). The option tag itself is a 14239 string that is associated with a particular SIP option (that is, an 14240 extension). It identifies the option to SIP endpoints. 14241 14242 When registering a new SIP option with IANA, the following 14243 information MUST be provided: 14244 14245 o Name and description of option. The name MAY be of any length, 14246 but SHOULD be no more than twenty characters long. The name 14247 MUST consist of alphanum (Section 25) characters only. 14248 14249 o A listing of any new SIP header fields, header parameter 14250 fields, or parameter values defined by this option. A SIP 14251 option MUST NOT redefine header fields or parameters defined 14252 in either RFC 2543, any standards-track extensions to RFC 14253 2543, or other extensions registered through IANA. 14254 14255 o Indication of who has change control over the option (for 14256 example, IETF, ISO, ITU-T, other international standardization 14257 bodies, a consortium, or a particular company or group of 14258 companies). 14259 14260 o A reference to a further description if available, for example 14261 (in order of preference) an RFC, a published paper, a patent 14262 filing, a technical report, documented source code, or a 14263 computer manual. 14264 14265 o Contact information (postal and email address). 14266 14267 14268 This procedure has been borrowed from RTSP [28] and the RTP 14269 AVP [40]. 14270 14271 27.2 Warn-Codes 14272 14273 Warning codes provide information supplemental to the status code in 14274 SIP response messages when the failure of the transaction results 14275 from a Session Description Protocol (SDP, [1]). New "warn-code" 14276 14277 14278 14279 J. Rosenberg et. al. [Page 252] 14280 Internet Draft SIP February 18, 2002 14281 14282 14283 values can be registered with IANA as they arise. 14284 14285 The "warn-code" consists of three digits. A first digit of "3" 14286 indicates warnings specific to SIP. 14287 14288 Warnings 300 through 329 are reserved for indicating problems with 14289 keywords in the session description, 330 through 339 are warnings 14290 related to basic network services requested in the session 14291 description, 370 through 379 are warnings related to quantitative QoS 14292 parameters requested in the session description, and 390 through 399 14293 are miscellaneous warnings that do not fall into one of the above 14294 categories. 14295 14296 14297 1xx and 2xx have been taken by HTTP/1.1. 14298 14299 27.3 Header Field Names 14300 14301 Header field names do not require working group or working group 14302 chair review prior to IANA registration, but SHOULD be documented in 14303 an RFC or Internet-Draft before IANA is consulted. 14304 14305 The following information needs to be provided to IANA in order to 14306 register a new header field name: 14307 14308 o The name and email address of the individual performing the 14309 registration; 14310 14311 o the name of the header field being registered; 14312 14313 o a compact form version for that header field, if one is 14314 defined; 14315 14316 o the name of the draft or RFC where the header field is 14317 defined; 14318 14319 o a copy of the draft or RFC where the header field is defined. 14320 14321 Header fields SHOULD NOT use the X prefix notation and MUST NOT 14322 duplicate the names of header fields used by SMTP or HTTP unless the 14323 syntax is a compatible superset and the semantics are similar. Some 14324 common and widely used header fields MAY be assigned one-letter 14325 compact forms (Section 7.3.3). Compact forms can only be assigned 14326 after SIP working group review. In the absence of this working group, 14327 a designated expert reviews the request. 14328 14329 27.4 Method and Response Codes 14330 14331 14332 14333 14334 J. Rosenberg et. al. [Page 253] 14335 Internet Draft SIP February 18, 2002 14336 14337 14338 Because the status code space is limited, they do require working 14339 group or working group chair review, and MUST be documented in an RFC 14340 or Internet draft. The same procedures apply to new method names. 14341 14342 The following information needs to be provided to IANA in order to 14343 register a new response code or method: 14344 14345 o The name and email address of the individual performing the 14346 registration; 14347 14348 o the number of the response code or name of the method being 14349 registered; 14350 14351 o the default reason phrase for that status code, if applicable; 14352 14353 o the name of the draft or RFC where the method or status code 14354 is defined; 14355 14356 o a copy of the draft or RFC where the method or status code is 14357 defined. 14358 14359 27.5 The "application/sip" MIME type. 14360 14361 This document registers the "application/sip" MIME media type in 14362 order to allow SIP messages to be tunneled as bodies within SIP, 14363 primarily for end-to-end security purposes. This media type is 14364 defined by the following information: 14365 14366 Media type name: application Media subtype name: sip Required 14367 parameters: none Optional parameters: version 14368 14369 o version: The SIP-Version number of the enclosed message (e.g., 14370 "2.0"). If not present, the version can be determined from the 14371 first line of the body. 14372 14373 Encoding scheme: see below Security considerations: see below 14374 14375 SIP specifies UTF-8 encoding. While most header field names and data 14376 elements will lie in the 7-bit ASCII compatible range, data elements 14377 and SIP bodies may contain 8-bit values. In order to preserve the 14378 readability of SIP messages being carried as the body of other 14379 messages, "application/sip" bodies (including any bodies they in turn 14380 contain) SHOULD be UTF-8 encoded. If transcoding a body to UTF-8 is 14381 not feasible, the "application/sip" part MAY be binary encoded. If 14382 the transport is not 8-bit clean, encoding formats such as base-64 14383 can be used. 14384 14385 Motivation and examples of this usage as a security mechanism in 14386 14387 14388 14389 J. Rosenberg et. al. [Page 254] 14390 Internet Draft SIP February 18, 2002 14391 14392 14393 concert with S/MIME are given in 23.4. 14394 14395 28 Changes From RFC 2543 14396 14397 This RFC revises RFC 2543. It is mostly backwards compatible with RFC 14398 2543. The changes described here fix many errors discovered in RFC 14399 2543 and provide information on scenarios not detailed in RFC 2543. 14400 The protocol has been presented in a more cleanly layered model here. 14401 14402 We break the differences into functional behavior that is a 14403 substantial change from RFC 2543, which has impact on 14404 interoperability or correct operation in some cases, and functional 14405 behavior that is different from RFC 2543 but not a potential source 14406 of interoperability problems. There have been countless 14407 clarifications as well, which are not documented here. 14408 14409 28.1 Major Functional Changes 14410 14411 o When a UAC wishes to terminate a call before it has been 14412 answered, it sends CANCEL. If the original INVITE still 14413 returns a 2xx, the UAC then sends BYE. BYE can only be sent on 14414 an existing call leg (now called a dialog in this RFC), 14415 whereas it could be sent at any time in RFC 2543. 14416 14417 o The SIP BNF was converted to be RFC 2234 compliant. 14418 14419 o SIP URL BNF was made more general, allowing a greater set of 14420 characters in the user part. Furthermore, comparison rules 14421 were simplified to be primarily case-insensitive, and detailed 14422 handling of comparison in the presence of parameters was 14423 described. The most substantial change is that a URI with a 14424 parameter with the default value does not match a URI without 14425 that parameter. 14426 14427 o Removed Via hiding. It had serious trust issues, since it 14428 relied on the next hop to perform the obfuscation process. 14429 Instead, Via hiding can be done as a local implementation 14430 choice in stateful proxies, and thus is no longer documented. 14431 14432 o In RFC 2543, CANCEL and INVITE transactions were intermingled. 14433 They are separated now. When a user sends an INVITE and then a 14434 CANCEL, the INVITE transaction still terminates normally. A 14435 UAS needs to respond to the original INVITE request with a 487 14436 response. 14437 14438 o Similarly, CANCEL and BYE transactions were intermingled; RFC 14439 2543 allowed the UAS not to send a response to INVITE when a 14440 BYE was received. That is disallowed here. The original INVITE 14441 14442 14443 14444 J. Rosenberg et. al. [Page 255] 14445 Internet Draft SIP February 18, 2002 14446 14447 14448 needs a response. 14449 14450 o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs 14451 need to support both UDP and TCP. 14452 14453 o In RFC 2543, a forking proxy only passed up one challenge from 14454 downstream elements in the event of multiple challenges. In 14455 this RFC, proxies are supposed to collect all challenges and 14456 place them into the forwarded response. 14457 14458 o In Digest credentials, the URI needs to be quoted; this is 14459 unclear from RFC 2617 and RFC 2069 which are both inconsistent 14460 on it. 14461 14462 o SDP processing has been split off into a separate 14463 specification [13], and more fully specified as a formal 14464 offer/answer exchange process that is effectively tunneled 14465 through SIP. SDP is allowed in INVITE/200 or 200/ACK for 14466 baseline SIP implementations; RFC 2543 alluded to the ability 14467 to use it in INVITE, 200, and ACK in a single transaction, but 14468 this was not well specified. More complex SDP usages are 14469 allowed in extensions. 14470 14471 o Added full support for IPv6 in URIs and in the Via header 14472 field. Support for IPv6 in Via has required that its header 14473 field parameters allow the square bracket and colon 14474 characters. These characters were previously not permitted. 14475 In theory, this could cause interop problems with older 14476 implementations. However, we have observed that most 14477 implementations accept any non-control ASCII character in 14478 these parameters. 14479 14480 o DNS SRV procedure is now documented in a separate 14481 specification [4]. This procedure uses both SRV and NAPTR 14482 resource records and no longer combines data from across SRV 14483 records as described in RFC 2543. 14484 14485 o Loop detection has been made optional, supplanted by a 14486 mandatory usage of Max-Forwards. The loop detection procedure 14487 in RFC 2543 had a serious bug which would report "spirals" as 14488 an error condition when it was not. The optional loop 14489 detection procedure is more fully and correctly specified 14490 here. 14491 14492 o Usage of tags is now mandatory (they were optional in RFC 14493 2543), as they are now the fundamental building blocks of 14494 dialog identification. 14495 14496 14497 14498 14499 J. Rosenberg et. al. [Page 256] 14500 Internet Draft SIP February 18, 2002 14501 14502 14503 o Added the Supported header field, allowing for clients to 14504 indicate what extensions are supported to a server, which can 14505 apply those extensions to the response, and indicate their 14506 usage with a Require in the response. 14507 14508 o Extension parameters were missing from the BNF for several 14509 header fields, and they have been added. 14510 14511 o Handling of Route and Record-Route construction was very 14512 underspecified in RFC 2543, and also not the right approach. 14513 It has been substantially reworked in this specification (and 14514 made vastly simpler), and this is arguably the largest change. 14515 Backwards compatibility is still provided for deployments that 14516 do not use "pre-loaded routes", where the initial request has 14517 a set of Route header field values obtained in some way 14518 outside of Record-Route. In those situations, the new 14519 mechanism is not interoperable. 14520 14521 o In RFC 2543, lines in a message could be terminated with CR, 14522 LF, or CRLF. This specification only allows CRLF. 14523 14524 o Comments (expressed with rounded brackets) have been removed 14525 from the grammar of SIP. 14526 14527 o Usage of Route in CANCEL and ACK was not well defined in RFC 14528 2543. It is now well specified; if a request had a Route 14529 header field, its CANCEL or ACK for a non-2xx response to the 14530 request need to carry the same Route header field values. ACKs 14531 for 2xx responses use the Route values learned from the 14532 Record-Route of the 2xx responses. 14533 14534 o RFC 2543 allowed multiple requests in a single UDP packet. 14535 This usage has been removed. 14536 14537 o Usage of absolute time in the Expires header field and 14538 parameter has been removed. It caused interoperability 14539 problems in elements that were not time synchronized, a common 14540 occurrence. Relative times are used instead. 14541 14542 o The branch parameter of the Via header field value is now 14543 mandatory for all elements to use. It now plays the role of a 14544 unique transaction identifier. This avoids the complex and 14545 bug-laden transaction identification rules from RFC 2543. A 14546 magic cookie is used in the parameter value to determine if 14547 the previous hop has made the parameter globally unique, and 14548 comparison falls back to the old rules when it is not present. 14549 Thus, interoperability is assured. 14550 14551 14552 14553 14554 J. Rosenberg et. al. [Page 257] 14555 Internet Draft SIP February 18, 2002 14556 14557 14558 o In RFC 2543, closure of a TCP connection was made equivalent 14559 to a CANCEL. This was nearly impossible to implement (and 14560 wrong) for TCP connections between proxies. This has been 14561 eliminated, so that there is no coupling between TCP 14562 connection state and SIP processing. 14563 14564 o RFC 2543 was silent on whether a UA could initiate a new 14565 transaction to a peer while another was in progress. That is 14566 now specified here. It is allowed for non-INVITE requests, 14567 disallowed for INVITE. 14568 14569 o PGP was removed. It was not sufficiently specified, and not 14570 compatible with the more complete PGP MIME. It was replaced 14571 with S/MIME. 14572 14573 o Additional security features were added with TLS, and these 14574 are described in a much larger and complete security 14575 considerations section. 14576 14577 o In RFC 2543, a proxy was not required to forward provisional 14578 responses from 101 to 199 upstream. This was changed to MUST. 14579 This is important, since many subsequent features depend on 14580 delivery of all provisional responses from 101 to 199. 14581 14582 o Little was said about the 503 response code in RFC 2543. It 14583 has since found substantial use in indicating failure or 14584 overload conditions in proxies. This requires somewhat special 14585 treatment. Specifically, receipt of a 503 should trigger an 14586 attempt to contact the next element in the result of a DNS SRV 14587 lookup. Also, 503 response is only forwarded upstream by a 14588 proxy under certain conditions. 14589 14590 o RFC 2543 defined, but did no sufficiently specify, a mechanism 14591 for UA authentication of a server. That has been removed. 14592 Instead, the mutual authentication procedures of RFC 2617 are 14593 allowed. 14594 14595 o A UA cannot send a BYE for a call until it has received an ACK 14596 for the initial INVITE. This was allowed in RFC 2543 but leads 14597 to a potential race condition. 14598 14599 o A UA or proxy cannot send CANCEL for a transaction until it 14600 gets a provisional response for the request. This was allowed 14601 in RFC 2543 but leads to potential race conditions. 14602 14603 o The action parameter in registrations has been deprecated. It 14604 was insufficient for any useful services, and caused conflicts 14605 when application processing was applied in proxies. 14606 14607 14608 14609 J. Rosenberg et. al. [Page 258] 14610 Internet Draft SIP February 18, 2002 14611 14612 14613 o RFC 2543 had a number of special cases for multicast. For 14614 example, certain responses were suppressed, timers were 14615 adjusted, and so on. Multicast now plays a more limited role, 14616 and the protocol operation is unaffected by usage of multicast 14617 as opposed to unicast. The limitations as a result of that are 14618 documented. 14619 14620 o Basic authentication has been removed entirely and its usage 14621 forbidden. 14622 14623 o Proxies no longer forward a 6xx immediately on receiving it. 14624 Instead, they CANCEL pending branches immediately. This avoids 14625 a potential race condition that would result in a UAC getting 14626 a 6xx followed by a 2xx. In all cases except this race 14627 condition, the result will be the same - the 6xx is forwarded 14628 upstream. 14629 14630 o RFC 2543 did not address the problem of request merging. This 14631 occurs when a request forks at a proxy and later rejoins at an 14632 element. Handling of merging is done only at a UA, and 14633 procedures are defined for rejecting all but the first 14634 request. 14635 14636 28.2 Minor Functional Changes 14637 14638 o Added the Alert-Info, Error-Info, and Call-Info header fields 14639 for optional content presentation to users. 14640 14641 o Added the Content-Language, Content-Disposition and MIME- 14642 Version header fields. 14643 14644 o Added a "glare handling" mechanism to deal with the case where 14645 both parties send each other a re-INVITE simultaneously. It 14646 uses the new 491 (Request Pending) error code. 14647 14648 o Added the In-Reply-To and Reply-To header fields for 14649 supporting the return of missed calls or messages at a later 14650 time. 14651 14652 o Added TLS and SCTP as valid SIP transports. 14653 14654 o There were a variety of mechanisms described for handling 14655 failures at any time during a call; those are now generally 14656 unified. BYE is sent to terminate. 14657 14658 o RFC 2543 mandated retransmission of INVITE responses over TCP, 14659 but noted it was really only needed for 2xx. That was an 14660 artifact of insufficient protocol layering. With a more 14661 14662 14663 14664 J. Rosenberg et. al. [Page 259] 14665 Internet Draft SIP February 18, 2002 14666 14667 14668 coherent transaction layer defined here, that is no longer 14669 needed. Only 2xx responses to INVITEs are retransmitted over 14670 TCP. 14671 14672 o Client and server transaction machines are now driven based on 14673 timeouts rather than retransmit counts. This allows the state 14674 machines to be properly specified for TCP and UDP. 14675 14676 o The Date header field is used in REGISTER responses to provide 14677 a simple means for auto-configuration of dates in user agents. 14678 14679 o Allowed a registrar to reject registrations with expirations 14680 that are too short in duration. Defined the 423 response code 14681 and the Min-Expires for this purpose. 14682 14683 o Added the "sips" URI scheme for end-to-end TLS. This scheme is 14684 not backwards compatible with RFC 2543. Existing elements that 14685 receive a request with a SIPS URI scheme in the Request-URI 14686 will likely reject the request. This is actually a feature; it 14687 ensures that a call to a SIPS URI is only delivered if all 14688 path hops can be secured. 14689 14690 29 Acknowledgments 14691 14692 We wish to thank the members of the IETF MMUSIC and SIP WGs for their 14693 comments and suggestions. Detailed comments were provided by Brian 14694 Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, 14695 Cdric Fluckiger, Yaron Goland, John Hearty, Bernie Honeisen, Jo 14696 Hornsby, Phil Hoffer, Christian Huitema, Jean Jervis, Gadi Karmi, 14697 Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin 14698 Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, 14699 Vern Paxson, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric 14700 Tremblay, and Rick Workman. 14701 14702 Brian Rosen provided the compiled BNF. 14703 14704 This work is based, inter alia, on [41,42]. 14705 14706 30 Authors' Addresses 14707 14708 Authors addresses are listed alphabetically for the editors, the 14709 writers, and then the original authors of RFC 2543. All listed 14710 authors actively contributed large amounts of text to this document. 14711 14712 Jonathan Rosenberg 14713 dynamicsoft 14714 72 Eagle Rock Ave 14715 East Hanover, NJ 07936 14716 14717 14718 14719 J. Rosenberg et. al. [Page 260] 14720 Internet Draft SIP February 18, 2002 14721 14722 14723 USA 14724 electronic mail: jdrosen@dynamicsoft.com 14725 14726 Henning Schulzrinne 14727 Dept. of Computer Science 14728 Columbia University 14729 1214 Amsterdam Avenue 14730 New York, NY 10027 14731 USA 14732 electronic mail: schulzrinne@cs.columbia.edu 14733 14734 Gonzalo Camarillo 14735 Ericsson 14736 Advanced Signalling Research Lab. 14737 FIN-02420 Jorvas 14738 Finland 14739 electronic mail: Gonzalo.Camarillo@ericsson.com 14740 14741 Alan Johnston 14742 WorldCom 14743 100 South 4th Street 14744 St. Louis, MO 63102 14745 USA 14746 electronic mail: alan.johnston@wcom.com 14747 14748 Jon Peterson 14749 NeuStar, Inc 14750 1800 Sutter Street, Suite 570 14751 Concord, CA 94520 14752 USA 14753 electronic mail: jon.peterson@neustar.com 14754 14755 Robert Sparks 14756 dynamicsoft, Inc. 14757 5100 Tennyson Parkway 14758 Suite 1200 14759 Plano, Texas 75024 14760 USA 14761 electronic mail: rsparks@dynamicsoft.com 14762 14763 Mark Handley 14764 ACIRI 14765 electronic mail: mjh@aciri.org 14766 14767 Eve Schooler 14768 Computer Science Department 256-80 14769 California Institute of Technology 14770 Pasadena, CA 91125 14771 14772 14773 14774 J. Rosenberg et. al. [Page 261] 14775 Internet Draft SIP February 18, 2002 14776 14777 14778 USA 14779 electronic mail: schooler@cs.caltech.edu 14780 14781 31 Normative References 14782 14783 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 14784 Request for Comments 2327, Internet Engineering Task Force, Apr. 14785 1998. 14786 14787 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 14788 levels," Request for Comments 2119, Internet Engineering Task Force, 14789 Mar. 1997. 14790 14791 [3] P. Resnick and Editor, "Internet message format," Request for 14792 Comments 2822, Internet Engineering Task Force, Apr. 2001. 14793 14794 [4] H. Schulzrinne and J. Rosenberg, "SIP: Session initiation 14795 protocol -- locating SIP servers," Internet Draft, Internet 14796 Engineering Task Force, Mar. 2001. Work in progress. 14797 14798 [5] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 14799 identifiers (URI): generic syntax," Request for Comments 2396, 14800 Internet Engineering Task Force, Aug. 1998. 14801 14802 [6] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 14803 locators (URL)," Request for Comments 1738, Internet Engineering Task 14804 Force, Dec. 1994. 14805 14806 [7] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 14807 Request for Comments 2279, Internet Engineering Task Force, Jan. 14808 1998. 14809 14810 [8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 14811 Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 14812 Request for Comments 2616, Internet Engineering Task Force, June 14813 1999. 14814 14815 [9] A. Vaha-Sipila, "URLs for telephone calls," Request for Comments 14816 2806, Internet Engineering Task Force, Apr. 2000. 14817 14818 [10] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax 14819 specifications: ABNF," Request for Comments 2234, Internet 14820 Engineering Task Force, Nov. 1997. 14821 14822 [11] N. Freed and N. Borenstein, "Multipurpose internet mail 14823 extensions (MIME) part two: Media types," Request for Comments 2046, 14824 Internet Engineering Task Force, Nov. 1996. 14825 14826 14827 14828 14829 J. Rosenberg et. al. [Page 262] 14830 Internet Draft SIP February 18, 2002 14831 14832 14833 [12] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 14834 recommendations for security," Request for Comments 1750, Internet 14835 Engineering Task Force, Dec. 1994. 14836 14837 [13] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 14838 SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002. 14839 Work in progress. 14840 14841 [14] J. Postel, "User datagram protocol," Request for Comments 768, 14842 Internet Engineering Task Force, Aug. 1980. 14843 14844 [15] J. Postel, "DoD standard transmission control protocol," Request 14845 for Comments 761, Internet Engineering Task Force, Jan. 1980. 14846 14847 [16] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 14848 Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control 14849 transmission protocol," Request for Comments 2960, Internet 14850 Engineering Task Force, Oct. 2000. 14851 14852 [17] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 14853 A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest 14854 access authentication," Request for Comments 2617, Internet 14855 Engineering Task Force, June 1999. 14856 14857 [18] R. Troost, S. Dorner, and K. Moore, "Communicating presentation 14858 information in internet messages: The content-disposition header 14859 field," Request for Comments 2183, Internet Engineering Task Force, 14860 Aug. 1997. 14861 14862 [19] R. Braden and Ed, "Requirements for internet hosts - application 14863 and support," Request for Comments 1123, Internet Engineering Task 14864 Force, Oct. 1989. 14865 14866 [20] H. Alvestrand, "IETF policy on character sets and languages," 14867 Request for Comments 2277, Internet Engineering Task Force, Jan. 14868 1998. 14869 14870 [21] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security 14871 multiparts for MIME: multipart/signed and multipart/encrypted," 14872 Request for Comments 1847, Internet Engineering Task Force, Oct. 14873 1995. 14874 14875 [22] R. Housley, "Cryptographic message syntax," Request for Comments 14876 2630, Internet Engineering Task Force, June 1999. 14877 14878 [23] B. Ramsdell and Ed, "S/MIME version 3 message specification," 14879 Request for Comments 2633, Internet Engineering Task Force, June 14880 1999. 14881 14882 14883 14884 J. Rosenberg et. al. [Page 263] 14885 Internet Draft SIP February 18, 2002 14886 14887 14888 [24] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request 14889 for Comments 2246, Internet Engineering Task Force, Jan. 1999. 14890 14891 [25] S. Kent and R. Atkinson, "Security architecture for the internet 14892 protocol," Request for Comments 2401, Internet Engineering Task 14893 Force, Nov. 1998. 14894 14895 32 Non-Normative References 14896 14897 [26] R. Pandya, "Emerging mobile and personal communication systems," 14898 IEEE Communications Magazine , Vol. 33, pp. 44--52, June 1995. 14899 14900 [27] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 14901 a transport protocol for real-time applications," Request for 14902 Comments 1889, Internet Engineering Task Force, Jan. 1996. 14903 14904 [28] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 14905 protocol (RTSP)," Request for Comments 2326, Internet Engineering 14906 Task Force, Apr. 1998. 14907 14908 [29] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, and J. 14909 Segers, "Megaco protocol version 1.0," Request for Comments 3015, 14910 Internet Engineering Task Force, Nov. 2000. 14911 14912 [30] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 14913 session initiation protocol," Request for Comments 2543, Internet 14914 Engineering Task Force, Mar. 1999. 14915 14916 [31] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL 14917 scheme," Request for Comments 2368, Internet Engineering Task Force, 14918 July 1998. 14919 14920 [32] E. M. Schooler, "A multicast user directory service for 14921 synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of 14922 Computer Science, California Institute of Technology, Pasadena, 14923 California, Aug. 1996. 14924 14925 [33] S. Donovan, "The SIP INFO method," Request for Comments 2976, 14926 Internet Engineering Task Force, Oct. 2000. 14927 14928 [34] R. Rivest, "The MD5 message-digest algorithm," Request for 14929 Comments 1321, Internet Engineering Task Force, Apr. 1992. 14930 14931 [35] F. Dawson and T. Howes, "vcard MIME directory profile," Request 14932 for Comments 2426, Internet Engineering Task Force, Sept. 1998. 14933 14934 [36] G. Good, "The LDAP data interchange format (LDIF) - technical 14935 specification," Request for Comments 2849, Internet Engineering Task 14936 14937 14938 14939 J. Rosenberg et. al. [Page 264] 14940 Internet Draft SIP February 18, 2002 14941 14942 14943 Force, June 2000. 14944 14945 [37] J. Palme, "Common internet message headers," Request for 14946 Comments 2076, Internet Engineering Task Force, Feb. 1997. 14947 14948 [38] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, 14949 E. Sink, and L. Stewart, "An extension to HTTP : Digest access 14950 authentication," Request for Comments 2069, Internet Engineering Task 14951 Force, Jan. 1997. 14952 14953 [39] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. 14954 Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow 14955 examples," Internet Draft, Internet Engineering Task Force, Apr. 14956 2001. Work in progress. 14957 14958 [40] H. Schulzrinne, "RTP profile for audio and video conferences 14959 with minimal control," Request for Comments 1890, Internet 14960 Engineering Task Force, Jan. 1996. 14961 14962 [41] E. M. Schooler, "Case study: multimedia conference control in a 14963 packet-switched teleconferencing system," Journal of Internetworking: 14964 Research and Experience , Vol. 4, pp. 99--120, June 1993. ISI 14965 reprint series ISI/RS-93-359. 14966 14967 [42] H. Schulzrinne, "Personal mobility for multimedia services in 14968 the Internet," in European Workshop on Interactive Distributed 14969 Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. 14970 1996. 14971 14972 A Table of Timer Values 14973 14974 Table 4 sumarizes the meaning and defaults of the various timers used 14975 by this specification. 14976 14977 14978 14979 Full Copyright Statement 14980 14981 Copyright (c) The Internet Society (2002). All Rights Reserved. 14982 14983 This document and translations of it may be copied and furnished to 14984 others, and derivative works that comment on or otherwise explain it 14985 or assist in its implementation may be prepared, copied, published 14986 and distributed, in whole or in part, without restriction of any 14987 kind, provided that the above copyright notice and this paragraph are 14988 included on all such copies and derivative works. However, this 14989 document itself may not be modified in any way, such as by removing 14990 the copyright notice or references to the Internet Society or other 14991 14992 14993 14994 J. Rosenberg et. al. [Page 265] 14995 Internet Draft SIP February 18, 2002 14996 14997 14998 14999 Timer Value Section Meaning 15000 __________________________________________________________________________ 15001 T1 500ms default Section 17.1.1.1 RTT Estimate 15002 T2 4s Section 17.1.2.2 The maximum retransmit 15003 interval for non-INVITE 15004 requests and INVITE 15005 responses 15006 T4 5s Section 17.1.2.2 Maximum duration a 15007 message will 15008 remain in the network 15009 Timer A initially T1 Section 17.1.1.2 INVITE request retransmit 15010 interval, for UDP only 15011 Timer B 64*T1 Section 17.1.1.2 INVITE transaction 15012 timeout timer 15013 Timer C > 3min Section Section 16.6 proxy INVITE transaction 15014 bullet 11 timeout 15015 Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 15016 0s for TCP/SCTP retransmits 15017 Timer E initially T1 Section 17.1.2.2 non-INVITE request 15018 retransmit interval, 15019 UDP only 15020 Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction 15021 timeout timer 15022 Timer G initially T1 Section 17.2.1 INVITE response 15023 retransmit interval 15024 Timer H 64*T1 Section 17.2.1 Wait time for 15025 ACK receipt 15026 Timer I T4 for UDP Section 17.2.1 Wait time for 15027 0s for TCP/SCTP ACK retransmits 15028 Timer J 64*T1 for UDP Section 17.2.2 Wait time for 15029 0s for TCP/SCTP non-INVITE request 15030 retransmits 15031 Timer K T4 for UDP Section 17.1.2.2 Wait time for 15032 0s for TCP/SCTP response retransmits 15033 15034 15035 Table 4: Summary of timers 15036 15037 Internet organizations, except as needed for the purpose of 15038 developing Internet standards in which case the procedures for 15039 copyrights defined in the Internet Standards process must be 15040 followed, or as required to translate it into languages other than 15041 English. 15042 15043 The limited permissions granted above are perpetual and will not be 15044 revoked by the Internet Society or its successors or assigns. 15045 15046 15047 15048 15049 J. Rosenberg et. al. [Page 266] 15050 Internet Draft SIP February 18, 2002 15051 15052 15053 This document and the information contained herein is provided on an 15054 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 15055 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 15056 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 15057 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 15058 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 15059 15060 15061 15062 15063 15064 15065 15066 15067 15068 15069 15070 15071 15072 15073 15074 15075 15076 15077 15078 15079 15080 15081 15082 15083 15084 15085 15086 15087 15088 15089 15090 15091 15092 15093 15094 15095 15096 15097 15098 15099 15100 15101 15102 15103 15104 J. Rosenberg et. al. [Page 267]