P1L1 P1L2 P1L3 P1L4 Network Working Group J. Rosenberg P1L5 Request for Comments: 3261 dynamicsoft P1L6 Obsoletes: 2543 H. Schulzrinne P1L7 Category: Standards Track Columbia U. P1L8 G. Camarillo P1L9 Ericsson P1L10 A. Johnston P1L11 WorldCom P1L12 J. Peterson P1L13 Neustar P1L14 R. Sparks P1L15 dynamicsoft P1L16 M. Handley P1L17 ICIR P1L18 E. Schooler P1L19 AT&T P1L20 June 2002 P1L21 P1L22 SIP: Session Initiation Protocol P1L23 P1L24 Status of this Memo P1L25 P1L26 This document specifies an Internet standards track protocol for the P1L27 Internet community, and requests discussion and suggestions for P1L28 improvements. Please refer to the current edition of the "Internet P1L29 Official Protocol Standards" (STD 1) for the standardization state P1L30 and status of this protocol. Distribution of this memo is unlimited. P1L31 P1L32 Copyright Notice P1L33 P1L34 Copyright (C) The Internet Society (2002). All Rights Reserved. P1L35 P1L36 Abstract P1L37 P1L38 This document describes Session Initiation Protocol (SIP), an P1L39 application-layer control (signaling) protocol for creating, P1L40 modifying, and terminating sessions with one or more participants. P1L41 These sessions include Internet telephone calls, multimedia P1L42 distribution, and multimedia conferences. P1L43 P1L44 SIP invitations used to create sessions carry session descriptions P1L45 that allow participants to agree on a set of compatible media types. P1L46 SIP makes use of elements called proxy servers to help route requests P1L47 to the user's current location, authenticate and authorize users for P1L48 services, implement provider call-routing policies, and provide P1L49 features to users. SIP also provides a registration function that P1L50 allows users to upload their current locations for use by proxy P1L51 servers. SIP runs on top of several different transport protocols. P2L1 Table of Contents P2L2 P2L3 1 Introduction ........................................ 8 P2L4 2 Overview of SIP Functionality ....................... 9 P2L5 3 Terminology ......................................... 10 P2L6 4 Overview of Operation ............................... 10 P2L7 5 Structure of the Protocol ........................... 18 P2L8 6 Definitions ......................................... 20 P2L9 7 SIP Messages ........................................ 26 P2L10 7.1 Requests ............................................ 27 P2L11 7.2 Responses ........................................... 28 P2L12 7.3 Header Fields ....................................... 29 P2L13 7.3.1 Header Field Format ................................. 30 P2L14 7.3.2 Header Field Classification ......................... 32 P2L15 7.3.3 Compact Form ........................................ 32 P2L16 7.4 Bodies .............................................. 33 P2L17 7.4.1 Message Body Type ................................... 33 P2L18 7.4.2 Message Body Length ................................. 33 P2L19 7.5 Framing SIP Messages ................................ 34 P2L20 8 General User Agent Behavior ......................... 34 P2L21 8.1 UAC Behavior ........................................ 35 P2L22 8.1.1 Generating the Request .............................. 35 P2L23 8.1.1.1 Request-URI ......................................... 35 P2L24 8.1.1.2 To .................................................. 36 P2L25 8.1.1.3 From ................................................ 37 P2L26 8.1.1.4 Call-ID ............................................. 37 P2L27 8.1.1.5 CSeq ................................................ 38 P2L28 8.1.1.6 Max-Forwards ........................................ 38 P2L29 8.1.1.7 Via ................................................. 39 P2L30 8.1.1.8 Contact ............................................. 40 P2L31 8.1.1.9 Supported and Require ............................... 40 P2L32 8.1.1.10 Additional Message Components ....................... 41 P2L33 8.1.2 Sending the Request ................................. 41 P2L34 8.1.3 Processing Responses ................................ 42 P2L35 8.1.3.1 Transaction Layer Errors ............................ 42 P2L36 8.1.3.2 Unrecognized Responses .............................. 42 P2L37 8.1.3.3 Vias ................................................ 43 P2L38 8.1.3.4 Processing 3xx Responses ............................ 43 P2L39 8.1.3.5 Processing 4xx Responses ............................ 45 P2L40 8.2 UAS Behavior ........................................ 46 P2L41 8.2.1 Method Inspection ................................... 46 P2L42 8.2.2 Header Inspection ................................... 46 P2L43 8.2.2.1 To and Request-URI .................................. 46 P2L44 8.2.2.2 Merged Requests ..................................... 47 P2L45 8.2.2.3 Require ............................................. 47 P2L46 8.2.3 Content Processing .................................. 48 P2L47 8.2.4 Applying Extensions ................................. 49 P2L48 8.2.5 Processing the Request .............................. 49 P3L1 8.2.6 Generating the Response ............................. 49 P3L2 8.2.6.1 Sending a Provisional Response ...................... 49 P3L3 8.2.6.2 Headers and Tags .................................... 50 P3L4 8.2.7 Stateless UAS Behavior .............................. 50 P3L5 8.3 Redirect Servers .................................... 51 P3L6 9 Canceling a Request ................................. 53 P3L7 9.1 Client Behavior ..................................... 53 P3L8 9.2 Server Behavior ..................................... 55 P3L9 10 Registrations ....................................... 56 P3L10 10.1 Overview ............................................ 56 P3L11 10.2 Constructing the REGISTER Request ................... 57 P3L12 10.2.1 Adding Bindings ..................................... 59 P3L13 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 P3L14 10.2.1.2 Preferences among Contact Addresses ................. 61 P3L15 10.2.2 Removing Bindings ................................... 61 P3L16 10.2.3 Fetching Bindings ................................... 61 P3L17 10.2.4 Refreshing Bindings ................................. 61 P3L18 10.2.5 Setting the Internal Clock .......................... 62 P3L19 10.2.6 Discovering a Registrar ............................. 62 P3L20 10.2.7 Transmitting a Request .............................. 62 P3L21 10.2.8 Error Responses ..................................... 63 P3L22 10.3 Processing REGISTER Requests ........................ 63 P3L23 11 Querying for Capabilities ........................... 66 P3L24 11.1 Construction of OPTIONS Request ..................... 67 P3L25 11.2 Processing of OPTIONS Request ....................... 68 P3L26 12 Dialogs ............................................. 69 P3L27 12.1 Creation of a Dialog ................................ 70 P3L28 12.1.1 UAS behavior ........................................ 70 P3L29 12.1.2 UAC Behavior ........................................ 71 P3L30 12.2 Requests within a Dialog ............................ 72 P3L31 12.2.1 UAC Behavior ........................................ 73 P3L32 12.2.1.1 Generating the Request .............................. 73 P3L33 12.2.1.2 Processing the Responses ............................ 75 P3L34 12.2.2 UAS Behavior ........................................ 76 P3L35 12.3 Termination of a Dialog ............................. 77 P3L36 13 Initiating a Session ................................ 77 P3L37 13.1 Overview ............................................ 77 P3L38 13.2 UAC Processing ...................................... 78 P3L39 13.2.1 Creating the Initial INVITE ......................... 78 P3L40 13.2.2 Processing INVITE Responses ......................... 81 P3L41 13.2.2.1 1xx Responses ....................................... 81 P3L42 13.2.2.2 3xx Responses ....................................... 81 P3L43 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 P3L44 13.2.2.4 2xx Responses ....................................... 82 P3L45 13.3 UAS Processing ...................................... 83 P3L46 13.3.1 Processing of the INVITE ............................ 83 P3L47 13.3.1.1 Progress ............................................ 84 P3L48 13.3.1.2 The INVITE is Redirected ............................ 84 P4L1 13.3.1.3 The INVITE is Rejected .............................. 85 P4L2 13.3.1.4 The INVITE is Accepted .............................. 85 P4L3 14 Modifying an Existing Session ....................... 86 P4L4 14.1 UAC Behavior ........................................ 86 P4L5 14.2 UAS Behavior ........................................ 88 P4L6 15 Terminating a Session ............................... 89 P4L7 15.1 Terminating a Session with a BYE Request ............ 90 P4L8 15.1.1 UAC Behavior ........................................ 90 P4L9 15.1.2 UAS Behavior ........................................ 91 P4L10 16 Proxy Behavior ...................................... 91 P4L11 16.1 Overview ............................................ 91 P4L12 16.2 Stateful Proxy ...................................... 92 P4L13 16.3 Request Validation .................................. 94 P4L14 16.4 Route Information Preprocessing ..................... 96 P4L15 16.5 Determining Request Targets ......................... 97 P4L16 16.6 Request Forwarding .................................. 99 P4L17 16.7 Response Processing ................................. 107 P4L18 16.8 Processing Timer C .................................. 114 P4L19 16.9 Handling Transport Errors ........................... 115 P4L20 16.10 CANCEL Processing ................................... 115 P4L21 16.11 Stateless Proxy ..................................... 116 P4L22 16.12 Summary of Proxy Route Processing ................... 118 P4L23 16.12.1 Examples ............................................ 118 P4L24 16.12.1.1 Basic SIP Trapezoid ................................. 118 P4L25 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 P4L26 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 P4L27 17 Transactions ........................................ 122 P4L28 17.1 Client Transaction .................................. 124 P4L29 17.1.1 INVITE Client Transaction ........................... 125 P4L30 17.1.1.1 Overview of INVITE Transaction ...................... 125 P4L31 17.1.1.2 Formal Description .................................. 125 P4L32 17.1.1.3 Construction of the ACK Request ..................... 129 P4L33 17.1.2 Non-INVITE Client Transaction ....................... 130 P4L34 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 P4L35 17.1.2.2 Formal Description .................................. 131 P4L36 17.1.3 Matching Responses to Client Transactions ........... 132 P4L37 17.1.4 Handling Transport Errors ........................... 133 P4L38 17.2 Server Transaction .................................. 134 P4L39 17.2.1 INVITE Server Transaction ........................... 134 P4L40 17.2.2 Non-INVITE Server Transaction ....................... 137 P4L41 17.2.3 Matching Requests to Server Transactions ............ 138 P4L42 17.2.4 Handling Transport Errors ........................... 141 P4L43 18 Transport ........................................... 141 P4L44 18.1 Clients ............................................. 142 P4L45 18.1.1 Sending Requests .................................... 142 P4L46 18.1.2 Receiving Responses ................................. 144 P4L47 18.2 Servers ............................................. 145 P4L48 18.2.1 Receiving Requests .................................. 145 P5L1 18.2.2 Sending Responses ................................... 146 P5L2 18.3 Framing ............................................. 147 P5L3 18.4 Error Handling ...................................... 147 P5L4 19 Common Message Components ........................... 147 P5L5 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 P5L6 19.1.1 SIP and SIPS URI Components ......................... 148 P5L7 19.1.2 Character Escaping Requirements ..................... 152 P5L8 19.1.3 Example SIP and SIPS URIs ........................... 153 P5L9 19.1.4 URI Comparison ...................................... 153 P5L10 19.1.5 Forming Requests from a URI ......................... 156 P5L11 19.1.6 Relating SIP URIs and tel URLs ...................... 157 P5L12 19.2 Option Tags ......................................... 158 P5L13 19.3 Tags ................................................ 159 P5L14 20 Header Fields ....................................... 159 P5L15 20.1 Accept .............................................. 161 P5L16 20.2 Accept-Encoding ..................................... 163 P5L17 20.3 Accept-Language ..................................... 164 P5L18 20.4 Alert-Info .......................................... 164 P5L19 20.5 Allow ............................................... 165 P5L20 20.6 Authentication-Info ................................. 165 P5L21 20.7 Authorization ....................................... 165 P5L22 20.8 Call-ID ............................................. 166 P5L23 20.9 Call-Info ........................................... 166 P5L24 20.10 Contact ............................................. 167 P5L25 20.11 Content-Disposition ................................. 168 P5L26 20.12 Content-Encoding .................................... 169 P5L27 20.13 Content-Language .................................... 169 P5L28 20.14 Content-Length ...................................... 169 P5L29 20.15 Content-Type ........................................ 170 P5L30 20.16 CSeq ................................................ 170 P5L31 20.17 Date ................................................ 170 P5L32 20.18 Error-Info .......................................... 171 P5L33 20.19 Expires ............................................. 171 P5L34 20.20 From ................................................ 172 P5L35 20.21 In-Reply-To ......................................... 172 P5L36 20.22 Max-Forwards ........................................ 173 P5L37 20.23 Min-Expires ......................................... 173 P5L38 20.24 MIME-Version ........................................ 173 P5L39 20.25 Organization ........................................ 174 P5L40 20.26 Priority ............................................ 174 P5L41 20.27 Proxy-Authenticate .................................. 174 P5L42 20.28 Proxy-Authorization ................................. 175 P5L43 20.29 Proxy-Require ....................................... 175 P5L44 20.30 Record-Route ........................................ 175 P5L45 20.31 Reply-To ............................................ 176 P5L46 20.32 Require ............................................. 176 P5L47 20.33 Retry-After ......................................... 176 P5L48 20.34 Route ............................................... 177 P6L1 20.35 Server .............................................. 177 P6L2 20.36 Subject ............................................. 177 P6L3 20.37 Supported ........................................... 178 P6L4 20.38 Timestamp ........................................... 178 P6L5 20.39 To .................................................. 178 P6L6 20.40 Unsupported ......................................... 179 P6L7 20.41 User-Agent .......................................... 179 P6L8 20.42 Via ................................................. 179 P6L9 20.43 Warning ............................................. 180 P6L10 20.44 WWW-Authenticate .................................... 182 P6L11 21 Response Codes ...................................... 182 P6L12 21.1 Provisional 1xx ..................................... 182 P6L13 21.1.1 100 Trying .......................................... 183 P6L14 21.1.2 180 Ringing ......................................... 183 P6L15 21.1.3 181 Call Is Being Forwarded ......................... 183 P6L16 21.1.4 182 Queued .......................................... 183 P6L17 21.1.5 183 Session Progress ................................ 183 P6L18 21.2 Successful 2xx ...................................... 183 P6L19 21.2.1 200 OK .............................................. 183 P6L20 21.3 Redirection 3xx ..................................... 184 P6L21 21.3.1 300 Multiple Choices ................................ 184 P6L22 21.3.2 301 Moved Permanently ............................... 184 P6L23 21.3.3 302 Moved Temporarily ............................... 184 P6L24 21.3.4 305 Use Proxy ....................................... 185 P6L25 21.3.5 380 Alternative Service ............................. 185 P6L26 21.4 Request Failure 4xx ................................. 185 P6L27 21.4.1 400 Bad Request ..................................... 185 P6L28 21.4.2 401 Unauthorized .................................... 185 P6L29 21.4.3 402 Payment Required ................................ 186 P6L30 21.4.4 403 Forbidden ....................................... 186 P6L31 21.4.5 404 Not Found ....................................... 186 P6L32 21.4.6 405 Method Not Allowed .............................. 186 P6L33 21.4.7 406 Not Acceptable .................................. 186 P6L34 21.4.8 407 Proxy Authentication Required ................... 186 P6L35 21.4.9 408 Request Timeout ................................. 186 P6L36 21.4.10 410 Gone ............................................ 187 P6L37 21.4.11 413 Request Entity Too Large ........................ 187 P6L38 21.4.12 414 Request-URI Too Long ............................ 187 P6L39 21.4.13 415 Unsupported Media Type .......................... 187 P6L40 21.4.14 416 Unsupported URI Scheme .......................... 187 P6L41 21.4.15 420 Bad Extension ................................... 187 P6L42 21.4.16 421 Extension Required .............................. 188 P6L43 21.4.17 423 Interval Too Brief .............................. 188 P6L44 21.4.18 480 Temporarily Unavailable ......................... 188 P6L45 21.4.19 481 Call/Transaction Does Not Exist ................. 188 P6L46 21.4.20 482 Loop Detected ................................... 188 P6L47 21.4.21 483 Too Many Hops ................................... 189 P6L48 21.4.22 484 Address Incomplete .............................. 189 P7L1 21.4.23 485 Ambiguous ....................................... 189 P7L2 21.4.24 486 Busy Here ....................................... 189 P7L3 21.4.25 487 Request Terminated .............................. 190 P7L4 21.4.26 488 Not Acceptable Here ............................. 190 P7L5 21.4.27 491 Request Pending ................................. 190 P7L6 21.4.28 493 Undecipherable .................................. 190 P7L7 21.5 Server Failure 5xx .................................. 190 P7L8 21.5.1 500 Server Internal Error ........................... 190 P7L9 21.5.2 501 Not Implemented ................................. 191 P7L10 21.5.3 502 Bad Gateway ..................................... 191 P7L11 21.5.4 503 Service Unavailable ............................. 191 P7L12 21.5.5 504 Server Time-out ................................. 191 P7L13 21.5.6 505 Version Not Supported ........................... 192 P7L14 21.5.7 513 Message Too Large ............................... 192 P7L15 21.6 Global Failures 6xx ................................. 192 P7L16 21.6.1 600 Busy Everywhere ................................. 192 P7L17 21.6.2 603 Decline ......................................... 192 P7L18 21.6.3 604 Does Not Exist Anywhere ......................... 192 P7L19 21.6.4 606 Not Acceptable .................................. 192 P7L20 22 Usage of HTTP Authentication ........................ 193 P7L21 22.1 Framework ........................................... 193 P7L22 22.2 User-to-User Authentication ......................... 195 P7L23 22.3 Proxy-to-User Authentication ........................ 197 P7L24 22.4 The Digest Authentication Scheme .................... 199 P7L25 23 S/MIME .............................................. 201 P7L26 23.1 S/MIME Certificates ................................. 201 P7L27 23.2 S/MIME Key Exchange ................................. 202 P7L28 23.3 Securing MIME bodies ................................ 205 P7L29 23.4 SIP Header Privacy and Integrity using S/MIME: P7L30 Tunneling SIP ....................................... 207 P7L31 23.4.1 Integrity and Confidentiality Properties of SIP P7L32 Headers ............................................. 207 P7L33 23.4.1.1 Integrity ........................................... 207 P7L34 23.4.1.2 Confidentiality ..................................... 208 P7L35 23.4.2 Tunneling Integrity and Authentication .............. 209 P7L36 23.4.3 Tunneling Encryption ................................ 211 P7L37 24 Examples ............................................ 213 P7L38 24.1 Registration ........................................ 213 P7L39 24.2 Session Setup ....................................... 214 P7L40 25 Augmented BNF for the SIP Protocol .................. 219 P7L41 25.1 Basic Rules ......................................... 219 P7L42 26 Security Considerations: Threat Model and Security P7L43 Usage Recommendations ............................... 232 P7L44 26.1 Attacks and Threat Models ........................... 233 P7L45 26.1.1 Registration Hijacking .............................. 233 P7L46 26.1.2 Impersonating a Server .............................. 234 P7L47 26.1.3 Tampering with Message Bodies ....................... 235 P7L48 26.1.4 Tearing Down Sessions ............................... 235 P8L1 26.1.5 Denial of Service and Amplification ................. 236 P8L2 26.2 Security Mechanisms ................................. 237 P8L3 26.2.1 Transport and Network Layer Security ................ 238 P8L4 26.2.2 SIPS URI Scheme ..................................... 239 P8L5 26.2.3 HTTP Authentication ................................. 240 P8L6 26.2.4 S/MIME .............................................. 240 P8L7 26.3 Implementing Security Mechanisms .................... 241 P8L8 26.3.1 Requirements for Implementers of SIP ................ 241 P8L9 26.3.2 Security Solutions .................................. 242 P8L10 26.3.2.1 Registration ........................................ 242 P8L11 26.3.2.2 Interdomain Requests ................................ 243 P8L12 26.3.2.3 Peer-to-Peer Requests ............................... 245 P8L13 26.3.2.4 DoS Protection ...................................... 246 P8L14 26.4 Limitations ......................................... 247 P8L15 26.4.1 HTTP Digest ......................................... 247 P8L16 26.4.2 S/MIME .............................................. 248 P8L17 26.4.3 TLS ................................................. 249 P8L18 26.4.4 SIPS URIs ........................................... 249 P8L19 26.5 Privacy ............................................. 251 P8L20 27 IANA Considerations ................................. 252 P8L21 27.1 Option Tags ......................................... 252 P8L22 27.2 Warn-Codes .......................................... 252 P8L23 27.3 Header Field Names .................................. 253 P8L24 27.4 Method and Response Codes ........................... 253 P8L25 27.5 The "message/sip" MIME type. ....................... 254 P8L26 27.6 New Content-Disposition Parameter Registrations ..... 255 P8L27 28 Changes From RFC 2543 ............................... 255 P8L28 28.1 Major Functional Changes ............................ 255 P8L29 28.2 Minor Functional Changes ............................ 260 P8L30 29 Normative References ................................ 261 P8L31 30 Informative References .............................. 262 P8L32 A Table of Timer Values ............................... 265 P8L33 Acknowledgments ................................................ 266 P8L34 Authors' Addresses ............................................. 267 P8L35 Full Copyright Statement ....................................... 269 P8L36 P8L37 1 Introduction P8L38 P8L39 There are many applications of the Internet that require the creation P8L40 and management of a session, where a session is considered an P8L41 exchange of data between an association of participants. The P8L42 implementation of these applications is complicated by the practices P8L43 of participants: users may move between endpoints, they may be P8L44 addressable by multiple names, and they may communicate in several P8L45 different media - sometimes simultaneously. Numerous protocols have P8L46 been authored that carry various forms of real-time multimedia P8L47 session data such as voice, video, or text messages. The Session P8L48 Initiation Protocol (SIP) works in concert with these protocols by P9L1 enabling Internet endpoints (called user agents) to discover one P9L2 another and to agree on a characterization of a session they would P9L3 like to share. For locating prospective session participants, and P9L4 for other functions, SIP enables the creation of an infrastructure of P9L5 network hosts (called proxy servers) to which user agents can send P9L6 registrations, invitations to sessions, and other requests. SIP is P9L7 an agile, general-purpose tool for creating, modifying, and P9L8 terminating sessions that works independently of underlying transport P9L9 protocols and without dependency on the type of session that is being P9L10 established. P9L11 P9L12 2 Overview of SIP Functionality P9L13 P9L14 SIP is an application-layer control protocol that can establish, P9L15 modify, and terminate multimedia sessions (conferences) such as P9L16 Internet telephony calls. SIP can also invite participants to P9L17 already existing sessions, such as multicast conferences. Media can P9L18 be added to (and removed from) an existing session. SIP P9L19 transparently supports name mapping and redirection services, which P9L20 supports personal mobility [27] - users can maintain a single P9L21 externally visible identifier regardless of their network location. P9L22 P9L23 SIP supports five facets of establishing and terminating multimedia P9L24 communications: P9L25 P9L26 User location: determination of the end system to be used for P9L27 communication; P9L28 P9L29 User availability: determination of the willingness of the called P9L30 party to engage in communications; P9L31 P9L32 User capabilities: determination of the media and media parameters P9L33 to be used; P9L34 P9L35 Session setup: "ringing", establishment of session parameters at P9L36 both called and calling party; P9L37 P9L38 Session management: including transfer and termination of P9L39 sessions, modifying session parameters, and invoking P9L40 services. P9L41 P9L42 SIP is not a vertically integrated communications system. SIP is P9L43 rather a component that can be used with other IETF protocols to P9L44 build a complete multimedia architecture. Typically, these P9L45 architectures will include protocols such as the Real-time Transport P9L46 Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and P9L47 providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC P9L48 2326 [29]) for controlling delivery of streaming media, the Media P10L1 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling P10L2 gateways to the Public Switched Telephone Network (PSTN), and the P10L3 Session Description Protocol (SDP) (RFC 2327 [1]) for describing P10L4 multimedia sessions. Therefore, SIP should be used in conjunction P10L5 with other protocols in order to provide complete services to the P10L6 users. However, the basic functionality and operation of SIP does P10L7 not depend on any of these protocols. P10L8 P10L9 SIP does not provide services. Rather, SIP provides primitives that P10L10 can be used to implement different services. For example, SIP can P10L11 locate a user and deliver an opaque object to his current location. P10L12 If this primitive is used to deliver a session description written in P10L13 SDP, for instance, the endpoints can agree on the parameters of a P10L14 session. If the same primitive is used to deliver a photo of the P10L15 caller as well as the session description, a "caller ID" service can P10L16 be easily implemented. As this example shows, a single primitive is P10L17 typically used to provide several different services. P10L18 P10L19 SIP does not offer conference control services such as floor control P10L20 or voting and does not prescribe how a conference is to be managed. P10L21 SIP can be used to initiate a session that uses some other conference P10L22 control protocol. Since SIP messages and the sessions they establish P10L23 can pass through entirely different networks, SIP cannot, and does P10L24 not, provide any kind of network resource reservation capabilities. P10L25 P10L26 The nature of the services provided make security particularly P10L27 important. To that end, SIP provides a suite of security services, P10L28 which include denial-of-service prevention, authentication (both user P10L29 to user and proxy to user), integrity protection, and encryption and P10L30 privacy services. P10L31 P10L32 SIP works with both IPv4 and IPv6. P10L33 P10L34 3 Terminology P10L35 P10L36 In this document, the key words "MUST", "MUST NOT", "REQUIRED", P10L37 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT P10L38 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as P10L39 described in BCP 14, RFC 2119 [2] and indicate requirement levels for P10L40 compliant SIP implementations. P10L41 P10L42 4 Overview of Operation P10L43 P10L44 This section introduces the basic operations of SIP using simple P10L45 examples. This section is tutorial in nature and does not contain P10L46 any normative statements. P10L47 P10L48 P11L1 The first example shows the basic functions of SIP: location of an P11L2 end point, signal of a desire to communicate, negotiation of session P11L3 parameters to establish the session, and teardown of the session once P11L4 established. P11L5 P11L6 Figure 1 shows a typical example of a SIP message exchange between P11L7 two users, Alice and Bob. (Each message is labeled with the letter P11L8 "F" and a number for reference by the text.) In this example, Alice P11L9 uses a SIP application on her PC (referred to as a softphone) to call P11L10 Bob on his SIP phone over the Internet. Also shown are two SIP proxy P11L11 servers that act on behalf of Alice and Bob to facilitate the session P11L12 establishment. This typical arrangement is often referred to as the P11L13 "SIP trapezoid" as shown by the geometric shape of the dotted lines P11L14 in Figure 1. P11L15 P11L16 Alice "calls" Bob using his SIP identity, a type of Uniform Resource P11L17 Identifier (URI) called a SIP URI. SIP URIs are defined in Section P11L18 19.1. It has a similar form to an email address, typically P11L19 containing a username and a host name. In this case, it is P11L20 sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP P11L21 service provider. Alice has a SIP URI of sip:alice@atlanta.com. P11L22 Alice might have typed in Bob's URI or perhaps clicked on a hyperlink P11L23 or an entry in an address book. SIP also provides a secure URI, P11L24 called a SIPS URI. An example would be sips:bob@biloxi.com. A call P11L25 made to a SIPS URI guarantees that secure, encrypted transport P11L26 (namely TLS) is used to carry all SIP messages from the caller to the P11L27 domain of the callee. From there, the request is sent securely to P11L28 the callee, but with security mechanisms that depend on the policy of P11L29 the domain of the callee. P11L30 P11L31 SIP is based on an HTTP-like request/response transaction model. P11L32 Each transaction consists of a request that invokes a particular P11L33 method, or function, on the server and at least one response. In P11L34 this example, the transaction begins with Alice's softphone sending P11L35 an INVITE request addressed to Bob's SIP URI. INVITE is an example P11L36 of a SIP method that specifies the action that the requestor (Alice) P11L37 wants the server (Bob) to take. The INVITE request contains a number P11L38 of header fields. Header fields are named attributes that provide P11L39 additional information about a message. The ones present in an P11L40 INVITE include a unique identifier for the call, the destination P11L41 address, Alice's address, and information about the type of session P11L42 that Alice wishes to establish with Bob. The INVITE (message F1 in P11L43 Figure 1) might look like this: P11L44 P11L45 P11L46 P11L47 P11L48 P12L1 atlanta.com . . . biloxi.com P12L2 . proxy proxy . P12L3 . . P12L4 Alice's . . . . . . . . . . . . . . . . . . . . Bob's P12L5 softphone SIP Phone P12L6 | | | | P12L7 | INVITE F1 | | | P12L8 |--------------->| INVITE F2 | | P12L9 | 100 Trying F3 |--------------->| INVITE F4 | P12L10 |<---------------| 100 Trying F5 |--------------->| P12L11 | |<-------------- | 180 Ringing F6 | P12L12 | | 180 Ringing F7 |<---------------| P12L13 | 180 Ringing F8 |<---------------| 200 OK F9 | P12L14 |<---------------| 200 OK F10 |<---------------| P12L15 | 200 OK F11 |<---------------| | P12L16 |<---------------| | | P12L17 | ACK F12 | P12L18 |------------------------------------------------->| P12L19 | Media Session | P12L20 |<================================================>| P12L21 | BYE F13 | P12L22 |<-------------------------------------------------| P12L23 | 200 OK F14 | P12L24 |------------------------------------------------->| P12L25 | | P12L26 P12L27 Figure 1: SIP session setup example with SIP trapezoid P12L28 P12L29 INVITE sip:bob@biloxi.com SIP/2.0 P12L30 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds P12L31 Max-Forwards: 70 P12L32 To: Bob P12L33 From: Alice ;tag=1928301774 P12L34 Call-ID: a84b4c76e66710@pc33.atlanta.com P12L35 CSeq: 314159 INVITE P12L36 Contact: P12L37 Content-Type: application/sdp P12L38 Content-Length: 142 P12L39 P12L40 (Alice's SDP not shown) P12L41 P12L42 The first line of the text-encoded message contains the method name P12L43 (INVITE). The lines that follow are a list of header fields. This P12L44 example contains a minimum required set. The header fields are P12L45 briefly described below: P12L46 P12L47 P12L48 P13L1 Via contains the address (pc33.atlanta.com) at which Alice is P13L2 expecting to receive responses to this request. It also contains a P13L3 branch parameter that identifies this transaction. P13L4 P13L5 To contains a display name (Bob) and a SIP or SIPS URI P13L6 (sip:bob@biloxi.com) towards which the request was originally P13L7 directed. Display names are described in RFC 2822 [3]. P13L8 P13L9 From also contains a display name (Alice) and a SIP or SIPS URI P13L10 (sip:alice@atlanta.com) that indicate the originator of the request. P13L11 This header field also has a tag parameter containing a random string P13L12 (1928301774) that was added to the URI by the softphone. It is used P13L13 for identification purposes. P13L14 P13L15 Call-ID contains a globally unique identifier for this call, P13L16 generated by the combination of a random string and the softphone's P13L17 host name or IP address. The combination of the To tag, From tag, P13L18 and Call-ID completely defines a peer-to-peer SIP relationship P13L19 between Alice and Bob and is referred to as a dialog. P13L20 P13L21 CSeq or Command Sequence contains an integer and a method name. The P13L22 CSeq number is incremented for each new request within a dialog and P13L23 is a traditional sequence number. P13L24 P13L25 Contact contains a SIP or SIPS URI that represents a direct route to P13L26 contact Alice, usually composed of a username at a fully qualified P13L27 domain name (FQDN). While an FQDN is preferred, many end systems do P13L28 not have registered domain names, so IP addresses are permitted. P13L29 While the Via header field tells other elements where to send the P13L30 response, the Contact header field tells other elements where to send P13L31 future requests. P13L32 P13L33 Max-Forwards serves to limit the number of hops a request can make on P13L34 the way to its destination. It consists of an integer that is P13L35 decremented by one at each hop. P13L36 P13L37 Content-Type contains a description of the message body (not shown). P13L38 P13L39 Content-Length contains an octet (byte) count of the message body. P13L40 P13L41 The complete set of SIP header fields is defined in Section 20. P13L42 P13L43 The details of the session, such as the type of media, codec, or P13L44 sampling rate, are not described using SIP. Rather, the body of a P13L45 SIP message contains a description of the session, encoded in some P13L46 other protocol format. One such format is the Session Description P13L47 Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the P13L48 P14L1 example) is carried by the SIP message in a way that is analogous to P14L2 a document attachment being carried by an email message, or a web P14L3 page being carried in an HTTP message. P14L4 P14L5 Since the softphone does not know the location of Bob or the SIP P14L6 server in the biloxi.com domain, the softphone sends the INVITE to P14L7 the SIP server that serves Alice's domain, atlanta.com. The address P14L8 of the atlanta.com SIP server could have been configured in Alice's P14L9 softphone, or it could have been discovered by DHCP, for example. P14L10 P14L11 The atlanta.com SIP server is a type of SIP server known as a proxy P14L12 server. A proxy server receives SIP requests and forwards them on P14L13 behalf of the requestor. In this example, the proxy server receives P14L14 the INVITE request and sends a 100 (Trying) response back to Alice's P14L15 softphone. The 100 (Trying) response indicates that the INVITE has P14L16 been received and that the proxy is working on her behalf to route P14L17 the INVITE to the destination. Responses in SIP use a three-digit P14L18 code followed by a descriptive phrase. This response contains the P14L19 same To, From, Call-ID, CSeq and branch parameter in the Via as the P14L20 INVITE, which allows Alice's softphone to correlate this response to P14L21 the sent INVITE. The atlanta.com proxy server locates the proxy P14L22 server at biloxi.com, possibly by performing a particular type of DNS P14L23 (Domain Name Service) lookup to find the SIP server that serves the P14L24 biloxi.com domain. This is described in [4]. As a result, it P14L25 obtains the IP address of the biloxi.com proxy server and forwards, P14L26 or proxies, the INVITE request there. Before forwarding the request, P14L27 the atlanta.com proxy server adds an additional Via header field P14L28 value that contains its own address (the INVITE already contains P14L29 Alice's address in the first Via). The biloxi.com proxy server P14L30 receives the INVITE and responds with a 100 (Trying) response back to P14L31 the atlanta.com proxy server to indicate that it has received the P14L32 INVITE and is processing the request. The proxy server consults a P14L33 database, generically called a location service, that contains the P14L34 current IP address of Bob. (We shall see in the next section how P14L35 this database can be populated.) The biloxi.com proxy server adds P14L36 another Via header field value with its own address to the INVITE and P14L37 proxies it to Bob's SIP phone. P14L38 P14L39 Bob's SIP phone receives the INVITE and alerts Bob to the incoming P14L40 call from Alice so that Bob can decide whether to answer the call, P14L41 that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 P14L42 (Ringing) response, which is routed back through the two proxies in P14L43 the reverse direction. Each proxy uses the Via header field to P14L44 determine where to send the response and removes its own address from P14L45 the top. As a result, although DNS and location service lookups were P14L46 required to route the initial INVITE, the 180 (Ringing) response can P14L47 be returned to the caller without lookups or without state being P14L48 P15L1 maintained in the proxies. This also has the desirable property that P15L2 each proxy that sees the INVITE will also see all responses to the P15L3 INVITE. P15L4 P15L5 When Alice's softphone receives the 180 (Ringing) response, it passes P15L6 this information to Alice, perhaps using an audio ringback tone or by P15L7 displaying a message on Alice's screen. P15L8 P15L9 In this example, Bob decides to answer the call. When he picks up P15L10 the handset, his SIP phone sends a 200 (OK) response to indicate that P15L11 the call has been answered. The 200 (OK) contains a message body P15L12 with the SDP media description of the type of session that Bob is P15L13 willing to establish with Alice. As a result, there is a two-phase P15L14 exchange of SDP messages: Alice sent one to Bob, and Bob sent one P15L15 back to Alice. This two-phase exchange provides basic negotiation P15L16 capabilities and is based on a simple offer/answer model of SDP P15L17 exchange. If Bob did not wish to answer the call or was busy on P15L18 another call, an error response would have been sent instead of the P15L19 200 (OK), which would have resulted in no media session being P15L20 established. The complete list of SIP response codes is in Section P15L21 21. The 200 (OK) (message F9 in Figure 1) might look like this as P15L22 Bob sends it out: P15L23 P15L24 SIP/2.0 200 OK P15L25 Via: SIP/2.0/UDP server10.biloxi.com P15L26 ;branch=z9hG4bKnashds8;received=192.0.2.3 P15L27 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com P15L28 ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 P15L29 Via: SIP/2.0/UDP pc33.atlanta.com P15L30 ;branch=z9hG4bK776asdhds ;received=192.0.2.1 P15L31 To: Bob ;tag=a6c85cf P15L32 From: Alice ;tag=1928301774 P15L33 Call-ID: a84b4c76e66710@pc33.atlanta.com P15L34 CSeq: 314159 INVITE P15L35 Contact: P15L36 Content-Type: application/sdp P15L37 Content-Length: 131 P15L38 P15L39 (Bob's SDP not shown) P15L40 P15L41 The first line of the response contains the response code (200) and P15L42 the reason phrase (OK). The remaining lines contain header fields. P15L43 The Via, To, From, Call-ID, and CSeq header fields are copied from P15L44 the INVITE request. (There are three Via header field values - one P15L45 added by Alice's SIP phone, one added by the atlanta.com proxy, and P15L46 one added by the biloxi.com proxy.) Bob's SIP phone has added a tag P15L47 parameter to the To header field. This tag will be incorporated by P15L48 both endpoints into the dialog and will be included in all future P16L1 requests and responses in this call. The Contact header field P16L2 contains a URI at which Bob can be directly reached at his SIP phone. P16L3 The Content-Type and Content-Length refer to the message body (not P16L4 shown) that contains Bob's SDP media information. P16L5 P16L6 In addition to DNS and location service lookups shown in this P16L7 example, proxy servers can make flexible "routing decisions" to P16L8 decide where to send a request. For example, if Bob's SIP phone P16L9 returned a 486 (Busy Here) response, the biloxi.com proxy server P16L10 could proxy the INVITE to Bob's voicemail server. A proxy server can P16L11 also send an INVITE to a number of locations at the same time. This P16L12 type of parallel search is known as forking. P16L13 P16L14 In this case, the 200 (OK) is routed back through the two proxies and P16L15 is received by Alice's softphone, which then stops the ringback tone P16L16 and indicates that the call has been answered. Finally, Alice's P16L17 softphone sends an acknowledgement message, ACK, to Bob's SIP phone P16L18 to confirm the reception of the final response (200 (OK)). In this P16L19 example, the ACK is sent directly from Alice's softphone to Bob's SIP P16L20 phone, bypassing the two proxies. This occurs because the endpoints P16L21 have learned each other's address from the Contact header fields P16L22 through the INVITE/200 (OK) exchange, which was not known when the P16L23 initial INVITE was sent. The lookups performed by the two proxies P16L24 are no longer needed, so the proxies drop out of the call flow. This P16L25 completes the INVITE/200/ACK three-way handshake used to establish P16L26 SIP sessions. Full details on session setup are in Section 13. P16L27 P16L28 Alice and Bob's media session has now begun, and they send media P16L29 packets using the format to which they agreed in the exchange of SDP. P16L30 In general, the end-to-end media packets take a different path from P16L31 the SIP signaling messages. P16L32 P16L33 During the session, either Alice or Bob may decide to change the P16L34 characteristics of the media session. This is accomplished by P16L35 sending a re-INVITE containing a new media description. This re- P16L36 INVITE references the existing dialog so that the other party knows P16L37 that it is to modify an existing session instead of establishing a P16L38 new session. The other party sends a 200 (OK) to accept the change. P16L39 The requestor responds to the 200 (OK) with an ACK. If the other P16L40 party does not accept the change, he sends an error response such as P16L41 488 (Not Acceptable Here), which also receives an ACK. However, the P16L42 failure of the re-INVITE does not cause the existing call to fail - P16L43 the session continues using the previously negotiated P16L44 characteristics. Full details on session modification are in Section P16L45 14. P16L46 P16L47 P16L48 P17L1 At the end of the call, Bob disconnects (hangs up) first and P17L2 generates a BYE message. This BYE is routed directly to Alice's P17L3 softphone, again bypassing the proxies. Alice confirms receipt of P17L4 the BYE with a 200 (OK) response, which terminates the session and P17L5 the BYE transaction. No ACK is sent - an ACK is only sent in P17L6 response to a response to an INVITE request. The reasons for this P17L7 special handling for INVITE will be discussed later, but relate to P17L8 the reliability mechanisms in SIP, the length of time it can take for P17L9 a ringing phone to be answered, and forking. For this reason, P17L10 request handling in SIP is often classified as either INVITE or non- P17L11 INVITE, referring to all other methods besides INVITE. Full details P17L12 on session termination are in Section 15. P17L13 P17L14 Section 24.2 describes the messages shown in Figure 1 in full. P17L15 P17L16 In some cases, it may be useful for proxies in the SIP signaling path P17L17 to see all the messaging between the endpoints for the duration of P17L18 the session. For example, if the biloxi.com proxy server wished to P17L19 remain in the SIP messaging path beyond the initial INVITE, it would P17L20 add to the INVITE a required routing header field known as Record- P17L21 Route that contained a URI resolving to the hostname or IP address of P17L22 the proxy. This information would be received by both Bob's SIP P17L23 phone and (due to the Record-Route header field being passed back in P17L24 the 200 (OK)) Alice's softphone and stored for the duration of the P17L25 dialog. The biloxi.com proxy server would then receive and proxy the P17L26 ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently P17L27 decide to receive subsequent messages, and those messages will pass P17L28 through all proxies that elect to receive it. This capability is P17L29 frequently used for proxies that are providing mid-call features. P17L30 P17L31 Registration is another common operation in SIP. Registration is one P17L32 way that the biloxi.com server can learn the current location of Bob. P17L33 Upon initialization, and at periodic intervals, Bob's SIP phone sends P17L34 REGISTER messages to a server in the biloxi.com domain known as a SIP P17L35 registrar. The REGISTER messages associate Bob's SIP or SIPS URI P17L36 (sip:bob@biloxi.com) with the machine into which he is currently P17L37 logged (conveyed as a SIP or SIPS URI in the Contact header field). P17L38 The registrar writes this association, also called a binding, to a P17L39 database, called the location service, where it can be used by the P17L40 proxy in the biloxi.com domain. Often, a registrar server for a P17L41 domain is co-located with the proxy for that domain. It is an P17L42 important concept that the distinction between types of SIP servers P17L43 is logical, not physical. P17L44 P17L45 Bob is not limited to registering from a single device. For example, P17L46 both his SIP phone at home and the one in the office could send P17L47 registrations. This information is stored together in the location P17L48 P18L1 service and allows a proxy to perform various types of searches to P18L2 locate Bob. Similarly, more than one user can be registered on a P18L3 single device at the same time. P18L4 P18L5 The location service is just an abstract concept. It generally P18L6 contains information that allows a proxy to input a URI and receive a P18L7 set of zero or more URIs that tell the proxy where to send the P18L8 request. Registrations are one way to create this information, but P18L9 not the only way. Arbitrary mapping functions can be configured at P18L10 the discretion of the administrator. P18L11 P18L12 Finally, it is important to note that in SIP, registration is used P18L13 for routing incoming SIP requests and has no role in authorizing P18L14 outgoing requests. Authorization and authentication are handled in P18L15 SIP either on a request-by-request basis with a challenge/response P18L16 mechanism, or by using a lower layer scheme as discussed in Section P18L17 26. P18L18 P18L19 The complete set of SIP message details for this registration example P18L20 is in Section 24.1. P18L21 P18L22 Additional operations in SIP, such as querying for the capabilities P18L23 of a SIP server or client using OPTIONS, or canceling a pending P18L24 request using CANCEL, will be introduced in later sections. P18L25 P18L26 5 Structure of the Protocol P18L27 P18L28 SIP is structured as a layered protocol, which means that its P18L29 behavior is described in terms of a set of fairly independent P18L30 processing stages with only a loose coupling between each stage. The P18L31 protocol behavior is described as layers for the purpose of P18L32 presentation, allowing the description of functions common across P18L33 elements in a single section. It does not dictate an implementation P18L34 in any way. When we say that an element "contains" a layer, we mean P18L35 it is compliant to the set of rules defined by that layer. P18L36 P18L37 Not every element specified by the protocol contains every layer. P18L38 Furthermore, the elements specified by SIP are logical elements, not P18L39 physical ones. A physical realization can choose to act as different P18L40 logical elements, perhaps even on a transaction-by-transaction basis. P18L41 P18L42 The lowest layer of SIP is its syntax and encoding. Its encoding is P18L43 specified using an augmented Backus-Naur Form grammar (BNF). The P18L44 complete BNF is specified in Section 25; an overview of a SIP P18L45 message's structure can be found in Section 7. P18L46 P18L47 P18L48 P19L1 The second layer is the transport layer. It defines how a client P19L2 sends requests and receives responses and how a server receives P19L3 requests and sends responses over the network. All SIP elements P19L4 contain a transport layer. The transport layer is described in P19L5 Section 18. P19L6 P19L7 The third layer is the transaction layer. Transactions are a P19L8 fundamental component of SIP. A transaction is a request sent by a P19L9 client transaction (using the transport layer) to a server P19L10 transaction, along with all responses to that request sent from the P19L11 server transaction back to the client. The transaction layer handles P19L12 application-layer retransmissions, matching of responses to requests, P19L13 and application-layer timeouts. Any task that a user agent client P19L14 (UAC) accomplishes takes place using a series of transactions. P19L15 Discussion of transactions can be found in Section 17. User agents P19L16 contain a transaction layer, as do stateful proxies. Stateless P19L17 proxies do not contain a transaction layer. The transaction layer P19L18 has a client component (referred to as a client transaction) and a P19L19 server component (referred to as a server transaction), each of which P19L20 are represented by a finite state machine that is constructed to P19L21 process a particular request. P19L22 P19L23 The layer above the transaction layer is called the transaction user P19L24 (TU). Each of the SIP entities, except the stateless proxy, is a P19L25 transaction user. When a TU wishes to send a request, it creates a P19L26 client transaction instance and passes it the request along with the P19L27 destination IP address, port, and transport to which to send the P19L28 request. A TU that creates a client transaction can also cancel it. P19L29 When a client cancels a transaction, it requests that the server stop P19L30 further processing, revert to the state that existed before the P19L31 transaction was initiated, and generate a specific error response to P19L32 that transaction. This is done with a CANCEL request, which P19L33 constitutes its own transaction, but references the transaction to be P19L34 cancelled (Section 9). P19L35 P19L36 The SIP elements, that is, user agent clients and servers, stateless P19L37 and stateful proxies and registrars, contain a core that P19L38 distinguishes them from each other. Cores, except for the stateless P19L39 proxy, are transaction users. While the behavior of the UAC and UAS P19L40 cores depends on the method, there are some common rules for all P19L41 methods (Section 8). For a UAC, these rules govern the construction P19L42 of a request; for a UAS, they govern the processing of a request and P19L43 generating a response. Since registrations play an important role in P19L44 SIP, a UAS that handles a REGISTER is given the special name P19L45 registrar. Section 10 describes UAC and UAS core behavior for the P19L46 REGISTER method. Section 11 describes UAC and UAS core behavior for P19L47 the OPTIONS method, used for determining the capabilities of a UA. P19L48 P20L1 Certain other requests are sent within a dialog. A dialog is a P20L2 peer-to-peer SIP relationship between two user agents that persists P20L3 for some time. The dialog facilitates sequencing of messages and P20L4 proper routing of requests between the user agents. The INVITE P20L5 method is the only way defined in this specification to establish a P20L6 dialog. When a UAC sends a request that is within the context of a P20L7 dialog, it follows the common UAC rules as discussed in Section 8 but P20L8 also the rules for mid-dialog requests. Section 12 discusses dialogs P20L9 and presents the procedures for their construction and maintenance, P20L10 in addition to construction of requests within a dialog. P20L11 P20L12 The most important method in SIP is the INVITE method, which is used P20L13 to establish a session between participants. A session is a P20L14 collection of participants, and streams of media between them, for P20L15 the purposes of communication. Section 13 discusses how sessions are P20L16 initiated, resulting in one or more SIP dialogs. Section 14 P20L17 discusses how characteristics of that session are modified through P20L18 the use of an INVITE request within a dialog. Finally, section 15 P20L19 discusses how a session is terminated. P20L20 P20L21 The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal P20L22 entirely with the UA core (Section 9 describes cancellation, which P20L23 applies to both UA core and proxy core). Section 16 discusses the P20L24 proxy element, which facilitates routing of messages between user P20L25 agents. P20L26 P20L27 6 Definitions P20L28 P20L29 The following terms have special significance for SIP. P20L30 P20L31 Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI P20L32 that points to a domain with a location service that can map P20L33 the URI to another URI where the user might be available. P20L34 Typically, the location service is populated through P20L35 registrations. An AOR is frequently thought of as the "public P20L36 address" of the user. P20L37 P20L38 Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a P20L39 logical entity that receives a request and processes it as a P20L40 user agent server (UAS). In order to determine how the request P20L41 should be answered, it acts as a user agent client (UAC) and P20L42 generates requests. Unlike a proxy server, it maintains dialog P20L43 state and must participate in all requests sent on the dialogs P20L44 it has established. Since it is a concatenation of a UAC and P20L45 UAS, no explicit definitions are needed for its behavior. P20L46 P20L47 P20L48 P21L1 Call: A call is an informal term that refers to some communication P21L2 between peers, generally set up for the purposes of a P21L3 multimedia conversation. P21L4 P21L5 Call Leg: Another name for a dialog [31]; no longer used in this P21L6 specification. P21L7 P21L8 Call Stateful: A proxy is call stateful if it retains state for a P21L9 dialog from the initiating INVITE to the terminating BYE P21L10 request. A call stateful proxy is always transaction stateful, P21L11 but the converse is not necessarily true. P21L12 P21L13 Client: A client is any network element that sends SIP requests P21L14 and receives SIP responses. Clients may or may not interact P21L15 directly with a human user. User agent clients and proxies are P21L16 clients. P21L17 P21L18 Conference: A multimedia session (see below) that contains P21L19 multiple participants. P21L20 P21L21 Core: Core designates the functions specific to a particular type P21L22 of SIP entity, i.e., specific to either a stateful or stateless P21L23 proxy, a user agent or registrar. All cores, except those for P21L24 the stateless proxy, are transaction users. P21L25 P21L26 Dialog: A dialog is a peer-to-peer SIP relationship between two P21L27 UAs that persists for some time. A dialog is established by P21L28 SIP messages, such as a 2xx response to an INVITE request. A P21L29 dialog is identified by a call identifier, local tag, and a P21L30 remote tag. A dialog was formerly known as a call leg in RFC P21L31 2543. P21L32 P21L33 Downstream: A direction of message forwarding within a transaction P21L34 that refers to the direction that requests flow from the user P21L35 agent client to user agent server. P21L36 P21L37 Final Response: A response that terminates a SIP transaction, as P21L38 opposed to a provisional response that does not. All 2xx, 3xx, P21L39 4xx, 5xx and 6xx responses are final. P21L40 P21L41 Header: A header is a component of a SIP message that conveys P21L42 information about the message. It is structured as a sequence P21L43 of header fields. P21L44 P21L45 Header Field: A header field is a component of the SIP message P21L46 header. A header field can appear as one or more header field P21L47 rows. Header field rows consist of a header field name and zero P21L48 or more header field values. Multiple header field values on a P22L1 given header field row are separated by commas. Some header P22L2 fields can only have a single header field value, and as a P22L3 result, always appear as a single header field row. P22L4 P22L5 Header Field Value: A header field value is a single value; a P22L6 header field consists of zero or more header field values. P22L7 P22L8 Home Domain: The domain providing service to a SIP user. P22L9 Typically, this is the domain present in the URI in the P22L10 address-of-record of a registration. P22L11 P22L12 Informational Response: Same as a provisional response. P22L13 P22L14 Initiator, Calling Party, Caller: The party initiating a session P22L15 (and dialog) with an INVITE request. A caller retains this P22L16 role from the time it sends the initial INVITE that established P22L17 a dialog until the termination of that dialog. P22L18 P22L19 Invitation: An INVITE request. P22L20 P22L21 Invitee, Invited User, Called Party, Callee: The party that P22L22 receives an INVITE request for the purpose of establishing a P22L23 new session. A callee retains this role from the time it P22L24 receives the INVITE until the termination of the dialog P22L25 established by that INVITE. P22L26 P22L27 Location Service: A location service is used by a SIP redirect or P22L28 proxy server to obtain information about a callee's possible P22L29 location(s). It contains a list of bindings of address-of- P22L30 record keys to zero or more contact addresses. The bindings P22L31 can be created and removed in many ways; this specification P22L32 defines a REGISTER method that updates the bindings. P22L33 P22L34 Loop: A request that arrives at a proxy, is forwarded, and later P22L35 arrives back at the same proxy. When it arrives the second P22L36 time, its Request-URI is identical to the first time, and other P22L37 header fields that affect proxy operation are unchanged, so P22L38 that the proxy would make the same processing decision on the P22L39 request it made the first time. Looped requests are errors, P22L40 and the procedures for detecting them and handling them are P22L41 described by the protocol. P22L42 P22L43 Loose Routing: A proxy is said to be loose routing if it follows P22L44 the procedures defined in this specification for processing of P22L45 the Route header field. These procedures separate the P22L46 destination of the request (present in the Request-URI) from P22L47 P22L48 P23L1 the set of proxies that need to be visited along the way P23L2 (present in the Route header field). A proxy compliant to P23L3 these mechanisms is also known as a loose router. P23L4 P23L5 Message: Data sent between SIP elements as part of the protocol. P23L6 SIP messages are either requests or responses. P23L7 P23L8 Method: The method is the primary function that a request is meant P23L9 to invoke on a server. The method is carried in the request P23L10 message itself. Example methods are INVITE and BYE. P23L11 P23L12 Outbound Proxy: A proxy that receives requests from a client, even P23L13 though it may not be the server resolved by the Request-URI. P23L14 Typically, a UA is manually configured with an outbound proxy, P23L15 or can learn about one through auto-configuration protocols. P23L16 P23L17 Parallel Search: In a parallel search, a proxy issues several P23L18 requests to possible user locations upon receiving an incoming P23L19 request. Rather than issuing one request and then waiting for P23L20 the final response before issuing the next request as in a P23L21 sequential search, a parallel search issues requests without P23L22 waiting for the result of previous requests. P23L23 P23L24 Provisional Response: A response used by the server to indicate P23L25 progress, but that does not terminate a SIP transaction. 1xx P23L26 responses are provisional, other responses are considered P23L27 final. P23L28 P23L29 Proxy, Proxy Server: An intermediary entity that acts as both a P23L30 server and a client for the purpose of making requests on P23L31 behalf of other clients. A proxy server primarily plays the P23L32 role of routing, which means its job is to ensure that a P23L33 request is sent to another entity "closer" to the targeted P23L34 user. Proxies are also useful for enforcing policy (for P23L35 example, making sure a user is allowed to make a call). A P23L36 proxy interprets, and, if necessary, rewrites specific parts of P23L37 a request message before forwarding it. P23L38 P23L39 Recursion: A client recurses on a 3xx response when it generates a P23L40 new request to one or more of the URIs in the Contact header P23L41 field in the response. P23L42 P23L43 Redirect Server: A redirect server is a user agent server that P23L44 generates 3xx responses to requests it receives, directing the P23L45 client to contact an alternate set of URIs. P23L46 P23L47 P23L48 P24L1 Registrar: A registrar is a server that accepts REGISTER requests P24L2 and places the information it receives in those requests into P24L3 the location service for the domain it handles. P24L4 P24L5 Regular Transaction: A regular transaction is any transaction with P24L6 a method other than INVITE, ACK, or CANCEL. P24L7 P24L8 Request: A SIP message sent from a client to a server, for the P24L9 purpose of invoking a particular operation. P24L10 P24L11 Response: A SIP message sent from a server to a client, for P24L12 indicating the status of a request sent from the client to the P24L13 server. P24L14 P24L15 Ringback: Ringback is the signaling tone produced by the calling P24L16 party's application indicating that a called party is being P24L17 alerted (ringing). P24L18 P24L19 Route Set: A route set is a collection of ordered SIP or SIPS URI P24L20 which represent a list of proxies that must be traversed when P24L21 sending a particular request. A route set can be learned, P24L22 through headers like Record-Route, or it can be configured. P24L23 P24L24 Server: A server is a network element that receives requests in P24L25 order to service them and sends back responses to those P24L26 requests. Examples of servers are proxies, user agent servers, P24L27 redirect servers, and registrars. P24L28 P24L29 Sequential Search: In a sequential search, a proxy server attempts P24L30 each contact address in sequence, proceeding to the next one P24L31 only after the previous has generated a final response. A 2xx P24L32 or 6xx class final response always terminates a sequential P24L33 search. P24L34 P24L35 Session: From the SDP specification: "A multimedia session is a P24L36 set of multimedia senders and receivers and the data streams P24L37 flowing from senders to receivers. A multimedia conference is P24L38 an example of a multimedia session." (RFC 2327 [1]) (A session P24L39 as defined for SDP can comprise one or more RTP sessions.) As P24L40 defined, a callee can be invited several times, by different P24L41 calls, to the same session. If SDP is used, a session is P24L42 defined by the concatenation of the SDP user name, session id, P24L43 network type, address type, and address elements in the origin P24L44 field. P24L45 P24L46 SIP Transaction: A SIP transaction occurs between a client and a P24L47 server and comprises all messages from the first request sent P24L48 from the client to the server up to a final (non-1xx) response P25L1 sent from the server to the client. If the request is INVITE P25L2 and the final response is a non-2xx, the transaction also P25L3 includes an ACK to the response. The ACK for a 2xx response to P25L4 an INVITE request is a separate transaction. P25L5 P25L6 Spiral: A spiral is a SIP request that is routed to a proxy, P25L7 forwarded onwards, and arrives once again at that proxy, but P25L8 this time differs in a way that will result in a different P25L9 processing decision than the original request. Typically, this P25L10 means that the request's Request-URI differs from its previous P25L11 arrival. A spiral is not an error condition, unlike a loop. A P25L12 typical cause for this is call forwarding. A user calls P25L13 joe@example.com. The example.com proxy forwards it to Joe's P25L14 PC, which in turn, forwards it to bob@example.com. This P25L15 request is proxied back to the example.com proxy. However, P25L16 this is not a loop. Since the request is targeted at a P25L17 different user, it is considered a spiral, and is a valid P25L18 condition. P25L19 P25L20 Stateful Proxy: A logical entity that maintains the client and P25L21 server transaction state machines defined by this specification P25L22 during the processing of a request, also known as a transaction P25L23 stateful proxy. The behavior of a stateful proxy is further P25L24 defined in Section 16. A (transaction) stateful proxy is not P25L25 the same as a call stateful proxy. P25L26 P25L27 Stateless Proxy: A logical entity that does not maintain the P25L28 client or server transaction state machines defined in this P25L29 specification when it processes requests. A stateless proxy P25L30 forwards every request it receives downstream and every P25L31 response it receives upstream. P25L32 P25L33 Strict Routing: A proxy is said to be strict routing if it follows P25L34 the Route processing rules of RFC 2543 and many prior work in P25L35 progress versions of this RFC. That rule caused proxies to P25L36 destroy the contents of the Request-URI when a Route header P25L37 field was present. Strict routing behavior is not used in this P25L38 specification, in favor of a loose routing behavior. Proxies P25L39 that perform strict routing are also known as strict routers. P25L40 P25L41 Target Refresh Request: A target refresh request sent within a P25L42 dialog is defined as a request that can modify the remote P25L43 target of the dialog. P25L44 P25L45 Transaction User (TU): The layer of protocol processing that P25L46 resides above the transaction layer. Transaction users include P25L47 the UAC core, UAS core, and proxy core. P25L48 P26L1 Upstream: A direction of message forwarding within a transaction P26L2 that refers to the direction that responses flow from the user P26L3 agent server back to the user agent client. P26L4 P26L5 URL-encoded: A character string encoded according to RFC 2396, P26L6 Section 2.4 [5]. P26L7 P26L8 User Agent Client (UAC): A user agent client is a logical entity P26L9 that creates a new request, and then uses the client P26L10 transaction state machinery to send it. The role of UAC lasts P26L11 only for the duration of that transaction. In other words, if P26L12 a piece of software initiates a request, it acts as a UAC for P26L13 the duration of that transaction. If it receives a request P26L14 later, it assumes the role of a user agent server for the P26L15 processing of that transaction. P26L16 P26L17 UAC Core: The set of processing functions required of a UAC that P26L18 reside above the transaction and transport layers. P26L19 P26L20 User Agent Server (UAS): A user agent server is a logical entity P26L21 that generates a response to a SIP request. The response P26L22 accepts, rejects, or redirects the request. This role lasts P26L23 only for the duration of that transaction. In other words, if P26L24 a piece of software responds to a request, it acts as a UAS for P26L25 the duration of that transaction. If it generates a request P26L26 later, it assumes the role of a user agent client for the P26L27 processing of that transaction. P26L28 P26L29 UAS Core: The set of processing functions required at a UAS that P26L30 resides above the transaction and transport layers. P26L31 P26L32 User Agent (UA): A logical entity that can act as both a user P26L33 agent client and user agent server. P26L34 P26L35 The role of UAC and UAS, as well as proxy and redirect servers, are P26L36 defined on a transaction-by-transaction basis. For example, the user P26L37 agent initiating a call acts as a UAC when sending the initial INVITE P26L38 request and as a UAS when receiving a BYE request from the callee. P26L39 Similarly, the same software can act as a proxy server for one P26L40 request and as a redirect server for the next request. P26L41 P26L42 Proxy, location, and registrar servers defined above are logical P26L43 entities; implementations MAY combine them into a single application. P26L44 P26L45 7 SIP Messages P26L46 P26L47 SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 P26L48 [7]). P27L1 A SIP message is either a request from a client to a server, or a P27L2 response from a server to a client. P27L3 P27L4 Both Request (section 7.1) and Response (section 7.2) messages use P27L5 the basic format of RFC 2822 [3], even though the syntax differs in P27L6 character set and syntax specifics. (SIP allows header fields that P27L7 would not be valid RFC 2822 header fields, for example.) Both types P27L8 of messages consist of a start-line, one or more header fields, an P27L9 empty line indicating the end of the header fields, and an optional P27L10 message-body. P27L11 P27L12 generic-message = start-line P27L13 *message-header P27L14 CRLF P27L15 [ message-body ] P27L16 start-line = Request-Line / Status-Line P27L17 P27L18 The start-line, each message-header line, and the empty line MUST be P27L19 terminated by a carriage-return line-feed sequence (CRLF). Note that P27L20 the empty line MUST be present even if the message-body is not. P27L21 P27L22 Except for the above difference in character sets, much of SIP's P27L23 message and header field syntax is identical to HTTP/1.1. Rather P27L24 than repeating the syntax and semantics here, we use [HX.Y] to refer P27L25 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). P27L26 P27L27 However, SIP is not an extension of HTTP. P27L28 P27L29 7.1 Requests P27L30 P27L31 SIP requests are distinguished by having a Request-Line for a start- P27L32 line. A Request-Line contains a method name, a Request-URI, and the P27L33 protocol version separated by a single space (SP) character. P27L34 P27L35 The Request-Line ends with CRLF. No CR or LF are allowed except in P27L36 the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed P27L37 in any of the elements. P27L38 P27L39 Request-Line = Method SP Request-URI SP SIP-Version CRLF P27L40 P27L41 Method: This specification defines six methods: REGISTER for P27L42 registering contact information, INVITE, ACK, and CANCEL for P27L43 setting up sessions, BYE for terminating sessions, and P27L44 OPTIONS for querying servers about their capabilities. SIP P27L45 extensions, documented in standards track RFCs, may define P27L46 additional methods. P27L47 P27L48 P28L1 Request-URI: The Request-URI is a SIP or SIPS URI as described in P28L2 Section 19.1 or a general URI (RFC 2396 [5]). It indicates P28L3 the user or service to which this request is being addressed. P28L4 The Request-URI MUST NOT contain unescaped spaces or control P28L5 characters and MUST NOT be enclosed in "<>". P28L6 P28L7 SIP elements MAY support Request-URIs with schemes other than P28L8 "sip" and "sips", for example the "tel" URI scheme of RFC P28L9 2806 [9]. SIP elements MAY translate non-SIP URIs using any P28L10 mechanism at their disposal, resulting in SIP URI, SIPS URI, P28L11 or some other scheme. P28L12 P28L13 SIP-Version: Both request and response messages include the P28L14 version of SIP in use, and follow [H3.1] (with HTTP replaced P28L15 by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version P28L16 ordering, compliance requirements, and upgrading of version P28L17 numbers. To be compliant with this specification, P28L18 applications sending SIP messages MUST include a SIP-Version P28L19 of "SIP/2.0". The SIP-Version string is case-insensitive, P28L20 but implementations MUST send upper-case. P28L21 P28L22 Unlike HTTP/1.1, SIP treats the version number as a literal P28L23 string. In practice, this should make no difference. P28L24 P28L25 7.2 Responses P28L26 P28L27 SIP responses are distinguished from requests by having a Status-Line P28L28 as their start-line. A Status-Line consists of the protocol version P28L29 followed by a numeric Status-Code and its associated textual phrase, P28L30 with each element separated by a single SP character. P28L31 P28L32 No CR or LF is allowed except in the final CRLF sequence. P28L33 P28L34 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF P28L35 P28L36 The Status-Code is a 3-digit integer result code that indicates the P28L37 outcome of an attempt to understand and satisfy a request. The P28L38 Reason-Phrase is intended to give a short textual description of the P28L39 Status-Code. The Status-Code is intended for use by automata, P28L40 whereas the Reason-Phrase is intended for the human user. A client P28L41 is not required to examine or display the Reason-Phrase. P28L42 P28L43 While this specification suggests specific wording for the reason P28L44 phrase, implementations MAY choose other text, for example, in the P28L45 language indicated in the Accept-Language header field of the P28L46 request. P28L47 P28L48 P29L1 The first digit of the Status-Code defines the class of response. P29L2 The last two digits do not have any categorization role. For this P29L3 reason, any response with a status code between 100 and 199 is P29L4 referred to as a "1xx response", any response with a status code P29L5 between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows P29L6 six values for the first digit: P29L7 P29L8 1xx: Provisional -- request received, continuing to process the P29L9 request; P29L10 P29L11 2xx: Success -- the action was successfully received, understood, P29L12 and accepted; P29L13 P29L14 3xx: Redirection -- further action needs to be taken in order to P29L15 complete the request; P29L16 P29L17 4xx: Client Error -- the request contains bad syntax or cannot be P29L18 fulfilled at this server; P29L19 P29L20 5xx: Server Error -- the server failed to fulfill an apparently P29L21 valid request; P29L22 P29L23 6xx: Global Failure -- the request cannot be fulfilled at any P29L24 server. P29L25 P29L26 Section 21 defines these classes and describes the individual codes. P29L27 P29L28 7.3 Header Fields P29L29 P29L30 SIP header fields are similar to HTTP header fields in both syntax P29L31 and semantics. In particular, SIP header fields follow the [H4.2] P29L32 definitions of syntax for the message-header and the rules for P29L33 extending header fields over multiple lines. However, the latter is P29L34 specified in HTTP with implicit whitespace and folding. This P29L35 specification conforms to RFC 2234 [10] and uses only explicit P29L36 whitespace and folding as an integral part of the grammar. P29L37 P29L38 [H4.2] also specifies that multiple header fields of the same field P29L39 name whose value is a comma-separated list can be combined into one P29L40 header field. That applies to SIP as well, but the specific rule is P29L41 different because of the different grammars. Specifically, any SIP P29L42 header whose grammar is of the form P29L43 P29L44 header = "header-name" HCOLON header-value *(COMMA header-value) P29L45 P29L46 allows for combining header fields of the same name into a comma- P29L47 separated list. The Contact header field allows a comma-separated P29L48 list unless the header field value is "*". P30L1 7.3.1 Header Field Format P30L2 P30L3 Header fields follow the same generic header format as that given in P30L4 Section 2.2 of RFC 2822 [3]. Each header field consists of a field P30L5 name followed by a colon (":") and the field value. P30L6 P30L7 field-name: field-value P30L8 P30L9 The formal grammar for a message-header specified in Section 25 P30L10 allows for an arbitrary amount of whitespace on either side of the P30L11 colon; however, implementations should avoid spaces between the field P30L12 name and the colon and use a single space (SP) between the colon and P30L13 the field-value. P30L14 P30L15 Subject: lunch P30L16 Subject : lunch P30L17 Subject :lunch P30L18 Subject: lunch P30L19 P30L20 Thus, the above are all valid and equivalent, but the last is the P30L21 preferred form. P30L22 P30L23 Header fields can be extended over multiple lines by preceding each P30L24 extra line with at least one SP or horizontal tab (HT). The line P30L25 break and the whitespace at the beginning of the next line are P30L26 treated as a single SP character. Thus, the following are P30L27 equivalent: P30L28 P30L29 Subject: I know you're there, pick up the phone and talk to me! P30L30 Subject: I know you're there, P30L31 pick up the phone P30L32 and talk to me! P30L33 P30L34 The relative order of header fields with different field names is not P30L35 significant. However, it is RECOMMENDED that header fields which are P30L36 needed for proxy processing (Via, Route, Record-Route, Proxy-Require, P30L37 Max-Forwards, and Proxy-Authorization, for example) appear towards P30L38 the top of the message to facilitate rapid parsing. The relative P30L39 order of header field rows with the same field name is important. P30L40 Multiple header field rows with the same field-name MAY be present in P30L41 a message if and only if the entire field-value for that header field P30L42 is defined as a comma-separated list (that is, if follows the grammar P30L43 defined in Section 7.3). It MUST be possible to combine the multiple P30L44 header field rows into one "field-name: field-value" pair, without P30L45 changing the semantics of the message, by appending each subsequent P30L46 field-value to the first, each separated by a comma. The exceptions P30L47 to this rule are the WWW-Authenticate, Authorization, Proxy- P30L48 Authenticate, and Proxy-Authorization header fields. Multiple header P31L1 field rows with these names MAY be present in a message, but since P31L2 their grammar does not follow the general form listed in Section 7.3, P31L3 they MUST NOT be combined into a single header field row. P31L4 P31L5 Implementations MUST be able to process multiple header field rows P31L6 with the same name in any combination of the single-value-per-line or P31L7 comma-separated value forms. P31L8 P31L9 The following groups of header field rows are valid and equivalent: P31L10 P31L11 Route: P31L12 Subject: Lunch P31L13 Route: P31L14 Route: P31L15 P31L16 Route: , P31L17 Route: P31L18 Subject: Lunch P31L19 P31L20 Subject: Lunch P31L21 Route: , , P31L22 P31L23 P31L24 Each of the following blocks is valid but not equivalent to the P31L25 others: P31L26 P31L27 Route: P31L28 Route: P31L29 Route: P31L30 P31L31 Route: P31L32 Route: P31L33 Route: P31L34 P31L35 Route: ,, P31L36 P31L37 P31L38 The format of a header field-value is defined per header-name. It P31L39 will always be either an opaque sequence of TEXT-UTF8 octets, or a P31L40 combination of whitespace, tokens, separators, and quoted strings. P31L41 Many existing header fields will adhere to the general form of a P31L42 value followed by a semi-colon separated sequence of parameter-name, P31L43 parameter-value pairs: P31L44 P31L45 field-name: field-value *(;parameter-name=parameter-value) P31L46 P31L47 P31L48 P32L1 Even though an arbitrary number of parameter pairs may be attached to P32L2 a header field value, any given parameter-name MUST NOT appear more P32L3 than once. P32L4 P32L5 When comparing header fields, field names are always case- P32L6 insensitive. Unless otherwise stated in the definition of a P32L7 particular header field, field values, parameter names, and parameter P32L8 values are case-insensitive. Tokens are always case-insensitive. P32L9 Unless specified otherwise, values expressed as quoted strings are P32L10 case-sensitive. For example, P32L11 P32L12 Contact: ;expires=3600 P32L13 P32L14 is equivalent to P32L15 P32L16 CONTACT: ;ExPiReS=3600 P32L17 P32L18 and P32L19 P32L20 Content-Disposition: session;handling=optional P32L21 P32L22 is equivalent to P32L23 P32L24 content-disposition: Session;HANDLING=OPTIONAL P32L25 P32L26 The following two header fields are not equivalent: P32L27 P32L28 Warning: 370 devnull "Choose a bigger pipe" P32L29 Warning: 370 devnull "CHOOSE A BIGGER PIPE" P32L30 P32L31 7.3.2 Header Field Classification P32L32 P32L33 Some header fields only make sense in requests or responses. These P32L34 are called request header fields and response header fields, P32L35 respectively. If a header field appears in a message not matching P32L36 its category (such as a request header field in a response), it MUST P32L37 be ignored. Section 20 defines the classification of each header P32L38 field. P32L39 P32L40 7.3.3 Compact Form P32L41 P32L42 SIP provides a mechanism to represent common header field names in an P32L43 abbreviated form. This may be useful when messages would otherwise P32L44 become too large to be carried on the transport available to it P32L45 (exceeding the maximum transmission unit (MTU) when using UDP, for P32L46 example). These compact forms are defined in Section 20. A compact P32L47 form MAY be substituted for the longer form of a header field name at P32L48 any time without changing the semantics of the message. A header P33L1 field name MAY appear in both long and short forms within the same P33L2 message. Implementations MUST accept both the long and short forms P33L3 of each header name. P33L4 P33L5 7.4 Bodies P33L6 P33L7 Requests, including new requests defined in extensions to this P33L8 specification, MAY contain message bodies unless otherwise noted. P33L9 The interpretation of the body depends on the request method. P33L10 P33L11 For response messages, the request method and the response status P33L12 code determine the type and interpretation of any message body. All P33L13 responses MAY include a body. P33L14 P33L15 7.4.1 Message Body Type P33L16 P33L17 The Internet media type of the message body MUST be given by the P33L18 Content-Type header field. If the body has undergone any encoding P33L19 such as compression, then this MUST be indicated by the Content- P33L20 Encoding header field; otherwise, Content-Encoding MUST be omitted. P33L21 If applicable, the character set of the message body is indicated as P33L22 part of the Content-Type header-field value. P33L23 P33L24 The "multipart" MIME type defined in RFC 2046 [11] MAY be used within P33L25 the body of the message. Implementations that send requests P33L26 containing multipart message bodies MUST send a session description P33L27 as a non-multipart message body if the remote implementation requests P33L28 this through an Accept header field that does not contain multipart. P33L29 P33L30 SIP messages MAY contain binary bodies or body parts. When no P33L31 explicit charset parameter is provided by the sender, media subtypes P33L32 of the "text" type are defined to have a default charset value of P33L33 "UTF-8". P33L34 P33L35 7.4.2 Message Body Length P33L36 P33L37 The body length in bytes is provided by the Content-Length header P33L38 field. Section 20.14 describes the necessary contents of this header P33L39 field in detail. P33L40 P33L41 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. P33L42 (Note: The chunked encoding modifies the body of a message in order P33L43 to transfer it as a series of chunks, each with its own size P33L44 indicator.) P33L45 P33L46 P33L47 P33L48 P34L1 7.5 Framing SIP Messages P34L2 P34L3 Unlike HTTP, SIP implementations can use UDP or other unreliable P34L4 datagram protocols. Each such datagram carries one request or P34L5 response. See Section 18 on constraints on usage of unreliable P34L6 transports. P34L7 P34L8 Implementations processing SIP messages over stream-oriented P34L9 transports MUST ignore any CRLF appearing before the start-line P34L10 [H4.1]. P34L11 P34L12 The Content-Length header field value is used to locate the end of P34L13 each SIP message in a stream. It will always be present when SIP P34L14 messages are sent over stream-oriented transports. P34L15 P34L16 8 General User Agent Behavior P34L17 P34L18 A user agent represents an end system. It contains a user agent P34L19 client (UAC), which generates requests, and a user agent server P34L20 (UAS), which responds to them. A UAC is capable of generating a P34L21 request based on some external stimulus (the user clicking a button, P34L22 or a signal on a PSTN line) and processing a response. A UAS is P34L23 capable of receiving a request and generating a response based on P34L24 user input, external stimulus, the result of a program execution, or P34L25 some other mechanism. P34L26 P34L27 When a UAC sends a request, the request passes through some number of P34L28 proxy servers, which forward the request towards the UAS. When the P34L29 UAS generates a response, the response is forwarded towards the UAC. P34L30 P34L31 UAC and UAS procedures depend strongly on two factors. First, based P34L32 on whether the request or response is inside or outside of a dialog, P34L33 and second, based on the method of a request. Dialogs are discussed P34L34 thoroughly in Section 12; they represent a peer-to-peer relationship P34L35 between user agents and are established by specific SIP methods, such P34L36 as INVITE. P34L37 P34L38 In this section, we discuss the method-independent rules for UAC and P34L39 UAS behavior when processing requests that are outside of a dialog. P34L40 This includes, of course, the requests which themselves establish a P34L41 dialog. P34L42 P34L43 Security procedures for requests and responses outside of a dialog P34L44 are described in Section 26. Specifically, mechanisms exist for the P34L45 UAS and UAC to mutually authenticate. A limited set of privacy P34L46 features are also supported through encryption of bodies using P34L47 S/MIME. P34L48 P35L1 8.1 UAC Behavior P35L2 P35L3 This section covers UAC behavior outside of a dialog. P35L4 P35L5 8.1.1 Generating the Request P35L6 P35L7 A valid SIP request formulated by a UAC MUST, at a minimum, contain P35L8 the following header fields: To, From, CSeq, Call-ID, Max-Forwards, P35L9 and Via; all of these header fields are mandatory in all SIP P35L10 requests. These six header fields are the fundamental building P35L11 blocks of a SIP message, as they jointly provide for most of the P35L12 critical message routing services including the addressing of P35L13 messages, the routing of responses, limiting message propagation, P35L14 ordering of messages, and the unique identification of transactions. P35L15 These header fields are in addition to the mandatory request line, P35L16 which contains the method, Request-URI, and SIP version. P35L17 P35L18 Examples of requests sent outside of a dialog include an INVITE to P35L19 establish a session (Section 13) and an OPTIONS to query for P35L20 capabilities (Section 11). P35L21 P35L22 8.1.1.1 Request-URI P35L23 P35L24 The initial Request-URI of the message SHOULD be set to the value of P35L25 the URI in the To field. One notable exception is the REGISTER P35L26 method; behavior for setting the Request-URI of REGISTER is given in P35L27 Section 10. It may also be undesirable for privacy reasons or P35L28 convenience to set these fields to the same value (especially if the P35L29 originating UA expects that the Request-URI will be changed during P35L30 transit). P35L31 P35L32 In some special circumstances, the presence of a pre-existing route P35L33 set can affect the Request-URI of the message. A pre-existing route P35L34 set is an ordered set of URIs that identify a chain of servers, to P35L35 which a UAC will send outgoing requests that are outside of a dialog. P35L36 Commonly, they are configured on the UA by a user or service provider P35L37 manually, or through some other non-SIP mechanism. When a provider P35L38 wishes to configure a UA with an outbound proxy, it is RECOMMENDED P35L39 that this be done by providing it with a pre-existing route set with P35L40 a single URI, that of the outbound proxy. P35L41 P35L42 When a pre-existing route set is present, the procedures for P35L43 populating the Request-URI and Route header field detailed in Section P35L44 12.2.1.1 MUST be followed (even though there is no dialog), using the P35L45 desired Request-URI as the remote target URI. P35L46 P35L47 P35L48 P36L1 8.1.1.2 To P36L2 P36L3 The To header field first and foremost specifies the desired P36L4 "logical" recipient of the request, or the address-of-record of the P36L5 user or resource that is the target of this request. This may or may P36L6 not be the ultimate recipient of the request. The To header field P36L7 MAY contain a SIP or SIPS URI, but it may also make use of other URI P36L8 schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. P36L9 All SIP implementations MUST support the SIP URI scheme. Any P36L10 implementation that supports TLS MUST support the SIPS URI scheme. P36L11 The To header field allows for a display name. P36L12 P36L13 A UAC may learn how to populate the To header field for a particular P36L14 request in a number of ways. Usually the user will suggest the To P36L15 header field through a human interface, perhaps inputting the URI P36L16 manually or selecting it from some sort of address book. Frequently, P36L17 the user will not enter a complete URI, but rather a string of digits P36L18 or letters (for example, "bob"). It is at the discretion of the UA P36L19 to choose how to interpret this input. Using the string to form the P36L20 user part of a SIP URI implies that the UA wishes the name to be P36L21 resolved in the domain to the right-hand side (RHS) of the at-sign in P36L22 the SIP URI (for instance, sip:bob@example.com). Using the string to P36L23 form the user part of a SIPS URI implies that the UA wishes to P36L24 communicate securely, and that the name is to be resolved in the P36L25 domain to the RHS of the at-sign. The RHS will frequently be the P36L26 home domain of the requestor, which allows for the home domain to P36L27 process the outgoing request. This is useful for features like P36L28 "speed dial" that require interpretation of the user part in the home P36L29 domain. The tel URL may be used when the UA does not wish to specify P36L30 the domain that should interpret a telephone number that has been P36L31 input by the user. Rather, each domain through which the request P36L32 passes would be given that opportunity. As an example, a user in an P36L33 airport might log in and send requests through an outbound proxy in P36L34 the airport. If they enter "411" (this is the phone number for local P36L35 directory assistance in the United States), that needs to be P36L36 interpreted and processed by the outbound proxy in the airport, not P36L37 the user's home domain. In this case, tel:411 would be the right P36L38 choice. P36L39 P36L40 A request outside of a dialog MUST NOT contain a To tag; the tag in P36L41 the To field of a request identifies the peer of the dialog. Since P36L42 no dialog is established, no tag is present. P36L43 P36L44 For further information on the To header field, see Section 20.39. P36L45 The following is an example of a valid To header field: P36L46 P36L47 To: Carol P36L48 P37L1 8.1.1.3 From P37L2 P37L3 The From header field indicates the logical identity of the initiator P37L4 of the request, possibly the user's address-of-record. Like the To P37L5 header field, it contains a URI and optionally a display name. It is P37L6 used by SIP elements to determine which processing rules to apply to P37L7 a request (for example, automatic call rejection). As such, it is P37L8 very important that the From URI not contain IP addresses or the FQDN P37L9 of the host on which the UA is running, since these are not logical P37L10 names. P37L11 P37L12 The From header field allows for a display name. A UAC SHOULD use P37L13 the display name "Anonymous", along with a syntactically correct, but P37L14 otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the P37L15 identity of the client is to remain hidden. P37L16 P37L17 Usually, the value that populates the From header field in requests P37L18 generated by a particular UA is pre-provisioned by the user or by the P37L19 administrators of the user's local domain. If a particular UA is P37L20 used by multiple users, it might have switchable profiles that P37L21 include a URI corresponding to the identity of the profiled user. P37L22 Recipients of requests can authenticate the originator of a request P37L23 in order to ascertain that they are who their From header field P37L24 claims they are (see Section 22 for more on authentication). P37L25 P37L26 The From field MUST contain a new "tag" parameter, chosen by the UAC. P37L27 See Section 19.3 for details on choosing a tag. P37L28 P37L29 For further information on the From header field, see Section 20.20. P37L30 Examples: P37L31 P37L32 From: "Bob" ;tag=a48s P37L33 From: sip:+12125551212@phone2net.com;tag=887s P37L34 From: Anonymous ;tag=hyh8 P37L35 P37L36 8.1.1.4 Call-ID P37L37 P37L38 The Call-ID header field acts as a unique identifier to group P37L39 together a series of messages. It MUST be the same for all requests P37L40 and responses sent by either UA in a dialog. It SHOULD be the same P37L41 in each registration from a UA. P37L42 P37L43 In a new request created by a UAC outside of any dialog, the Call-ID P37L44 header field MUST be selected by the UAC as a globally unique P37L45 identifier over space and time unless overridden by method-specific P37L46 behavior. All SIP UAs must have a means to guarantee that the Call- P37L47 ID header fields they produce will not be inadvertently generated by P37L48 any other UA. Note that when requests are retried after certain P38L1 failure responses that solicit an amendment to a request (for P38L2 example, a challenge for authentication), these retried requests are P38L3 not considered new requests, and therefore do not need new Call-ID P38L4 header fields; see Section 8.1.3.5. P38L5 P38L6 Use of cryptographically random identifiers (RFC 1750 [12]) in the P38L7 generation of Call-IDs is RECOMMENDED. Implementations MAY use the P38L8 form "localid@host". Call-IDs are case-sensitive and are simply P38L9 compared byte-by-byte. P38L10 P38L11 Using cryptographically random identifiers provides some P38L12 protection against session hijacking and reduces the likelihood of P38L13 unintentional Call-ID collisions. P38L14 P38L15 No provisioning or human interface is required for the selection of P38L16 the Call-ID header field value for a request. P38L17 P38L18 For further information on the Call-ID header field, see Section P38L19 20.8. P38L20 P38L21 Example: P38L22 P38L23 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com P38L24 P38L25 8.1.1.5 CSeq P38L26 P38L27 The CSeq header field serves as a way to identify and order P38L28 transactions. It consists of a sequence number and a method. The P38L29 method MUST match that of the request. For non-REGISTER requests P38L30 outside of a dialog, the sequence number value is arbitrary. The P38L31 sequence number value MUST be expressible as a 32-bit unsigned P38L32 integer and MUST be less than 2**31. As long as it follows the above P38L33 guidelines, a client may use any mechanism it would like to select P38L34 CSeq header field values. P38L35 P38L36 Section 12.2.1.1 discusses construction of the CSeq for requests P38L37 within a dialog. P38L38 P38L39 Example: P38L40 P38L41 CSeq: 4711 INVITE P38L42 P38L43 P38L44 P38L45 P38L46 P38L47 P38L48 P39L1 8.1.1.6 Max-Forwards P39L2 P39L3 The Max-Forwards header field serves to limit the number of hops a P39L4 request can transit on the way to its destination. It consists of an P39L5 integer that is decremented by one at each hop. If the Max-Forwards P39L6 value reaches 0 before the request reaches its destination, it will P39L7 be rejected with a 483(Too Many Hops) error response. P39L8 P39L9 A UAC MUST insert a Max-Forwards header field into each request it P39L10 originates with a value that SHOULD be 70. This number was chosen to P39L11 be sufficiently large to guarantee that a request would not be P39L12 dropped in any SIP network when there were no loops, but not so large P39L13 as to consume proxy resources when a loop does occur. Lower values P39L14 should be used with caution and only in networks where topologies are P39L15 known by the UA. P39L16 P39L17 8.1.1.7 Via P39L18 P39L19 The Via header field indicates the transport used for the transaction P39L20 and identifies the location where the response is to be sent. A Via P39L21 header field value is added only after the transport that will be P39L22 used to reach the next hop has been selected (which may involve the P39L23 usage of the procedures in [4]). P39L24 P39L25 When the UAC creates a request, it MUST insert a Via into that P39L26 request. The protocol name and protocol version in the header field P39L27 MUST be SIP and 2.0, respectively. The Via header field value MUST P39L28 contain a branch parameter. This parameter is used to identify the P39L29 transaction created by that request. This parameter is used by both P39L30 the client and the server. P39L31 P39L32 The branch parameter value MUST be unique across space and time for P39L33 all requests sent by the UA. The exceptions to this rule are CANCEL P39L34 and ACK for non-2xx responses. As discussed below, a CANCEL request P39L35 will have the same value of the branch parameter as the request it P39L36 cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx P39L37 response will also have the same branch ID as the INVITE whose P39L38 response it acknowledges. P39L39 P39L40 The uniqueness property of the branch ID parameter, to facilitate P39L41 its use as a transaction ID, was not part of RFC 2543. P39L42 P39L43 The branch ID inserted by an element compliant with this P39L44 specification MUST always begin with the characters "z9hG4bK". These P39L45 7 characters are used as a magic cookie (7 is deemed sufficient to P39L46 ensure that an older RFC 2543 implementation would not pick such a P39L47 value), so that servers receiving the request can determine that the P39L48 branch ID was constructed in the fashion described by this P40L1 specification (that is, globally unique). Beyond this requirement, P40L2 the precise format of the branch token is implementation-defined. P40L3 P40L4 The Via header maddr, ttl, and sent-by components will be set when P40L5 the request is processed by the transport layer (Section 18). P40L6 P40L7 Via processing for proxies is described in Section 16.6 Item 8 and P40L8 Section 16.7 Item 3. P40L9 P40L10 8.1.1.8 Contact P40L11 P40L12 The Contact header field provides a SIP or SIPS URI that can be used P40L13 to contact that specific instance of the UA for subsequent requests. P40L14 The Contact header field MUST be present and contain exactly one SIP P40L15 or SIPS URI in any request that can result in the establishment of a P40L16 dialog. For the methods defined in this specification, that includes P40L17 only the INVITE request. For these requests, the scope of the P40L18 Contact is global. That is, the Contact header field value contains P40L19 the URI at which the UA would like to receive requests, and this URI P40L20 MUST be valid even if used in subsequent requests outside of any P40L21 dialogs. P40L22 P40L23 If the Request-URI or top Route header field value contains a SIPS P40L24 URI, the Contact header field MUST contain a SIPS URI as well. P40L25 P40L26 For further information on the Contact header field, see Section P40L27 20.10. P40L28 P40L29 8.1.1.9 Supported and Require P40L30 P40L31 If the UAC supports extensions to SIP that can be applied by the P40L32 server to the response, the UAC SHOULD include a Supported header P40L33 field in the request listing the option tags (Section 19.2) for those P40L34 extensions. P40L35 P40L36 The option tags listed MUST only refer to extensions defined in P40L37 standards-track RFCs. This is to prevent servers from insisting that P40L38 clients implement non-standard, vendor-defined features in order to P40L39 receive service. Extensions defined by experimental and P40L40 informational RFCs are explicitly excluded from usage with the P40L41 Supported header field in a request, since they too are often used to P40L42 document vendor-defined extensions. P40L43 P40L44 If the UAC wishes to insist that a UAS understand an extension that P40L45 the UAC will apply to the request in order to process the request, it P40L46 MUST insert a Require header field into the request listing the P40L47 option tag for that extension. If the UAC wishes to apply an P40L48 extension to the request and insist that any proxies that are P41L1 traversed understand that extension, it MUST insert a Proxy-Require P41L2 header field into the request listing the option tag for that P41L3 extension. P41L4 P41L5 As with the Supported header field, the option tags in the Require P41L6 and Proxy-Require header fields MUST only refer to extensions defined P41L7 in standards-track RFCs. P41L8 P41L9 8.1.1.10 Additional Message Components P41L10 P41L11 After a new request has been created, and the header fields described P41L12 above have been properly constructed, any additional optional header P41L13 fields are added, as are any header fields specific to the method. P41L14 P41L15 SIP requests MAY contain a MIME-encoded message-body. Regardless of P41L16 the type of body that a request contains, certain header fields must P41L17 be formulated to characterize the contents of the body. For further P41L18 information on these header fields, see Sections 20.11 through 20.15. P41L19 P41L20 8.1.2 Sending the Request P41L21 P41L22 The destination for the request is then computed. Unless there is P41L23 local policy specifying otherwise, the destination MUST be determined P41L24 by applying the DNS procedures described in [4] as follows. If the P41L25 first element in the route set indicated a strict router (resulting P41L26 in forming the request as described in Section 12.2.1.1), the P41L27 procedures MUST be applied to the Request-URI of the request. P41L28 Otherwise, the procedures are applied to the first Route header field P41L29 value in the request (if one exists), or to the request's Request-URI P41L30 if there is no Route header field present. These procedures yield an P41L31 ordered set of address, port, and transports to attempt. Independent P41L32 of which URI is used as input to the procedures of [4], if the P41L33 Request-URI specifies a SIPS resource, the UAC MUST follow the P41L34 procedures of [4] as if the input URI were a SIPS URI. P41L35 P41L36 Local policy MAY specify an alternate set of destinations to attempt. P41L37 If the Request-URI contains a SIPS URI, any alternate destinations P41L38 MUST be contacted with TLS. Beyond that, there are no restrictions P41L39 on the alternate destinations if the request contains no Route header P41L40 field. This provides a simple alternative to a pre-existing route P41L41 set as a way to specify an outbound proxy. However, that approach P41L42 for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing P41L43 route set with a single URI SHOULD be used instead. If the request P41L44 contains a Route header field, the request SHOULD be sent to the P41L45 locations derived from its topmost value, but MAY be sent to any P41L46 server that the UA is certain will honor the Route and Request-URI P41L47 policies specified in this document (as opposed to those in RFC P41L48 2543). In particular, a UAC configured with an outbound proxy SHOULD P42L1 attempt to send the request to the location indicated in the first P42L2 Route header field value instead of adopting the policy of sending P42L3 all messages to the outbound proxy. P42L4 P42L5 This ensures that outbound proxies that do not add Record-Route P42L6 header field values will drop out of the path of subsequent P42L7 requests. It allows endpoints that cannot resolve the first Route P42L8 URI to delegate that task to an outbound proxy. P42L9 P42L10 The UAC SHOULD follow the procedures defined in [4] for stateful P42L11 elements, trying each address until a server is contacted. Each try P42L12 constitutes a new transaction, and therefore each carries a different P42L13 topmost Via header field value with a new branch parameter. P42L14 Furthermore, the transport value in the Via header field is set to P42L15 whatever transport was determined for the target server. P42L16 P42L17 8.1.3 Processing Responses P42L18 P42L19 Responses are first processed by the transport layer and then passed P42L20 up to the transaction layer. The transaction layer performs its P42L21 processing and then passes the response up to the TU. The majority P42L22 of response processing in the TU is method specific. However, there P42L23 are some general behaviors independent of the method. P42L24 P42L25 8.1.3.1 Transaction Layer Errors P42L26 P42L27 In some cases, the response returned by the transaction layer will P42L28 not be a SIP message, but rather a transaction layer error. When a P42L29 timeout error is received from the transaction layer, it MUST be P42L30 treated as if a 408 (Request Timeout) status code has been received. P42L31 If a fatal transport error is reported by the transport layer P42L32 (generally, due to fatal ICMP errors in UDP or connection failures in P42L33 TCP), the condition MUST be treated as a 503 (Service Unavailable) P42L34 status code. P42L35 P42L36 8.1.3.2 Unrecognized Responses P42L37 P42L38 A UAC MUST treat any final response it does not recognize as being P42L39 equivalent to the x00 response code of that class, and MUST be able P42L40 to process the x00 response code for all classes. For example, if a P42L41 UAC receives an unrecognized response code of 431, it can safely P42L42 assume that there was something wrong with its request and treat the P42L43 response as if it had received a 400 (Bad Request) response code. A P42L44 UAC MUST treat any provisional response different than 100 that it P42L45 does not recognize as 183 (Session Progress). A UAC MUST be able to P42L46 process 100 and 183 responses. P42L47 P42L48 P43L1 8.1.3.3 Vias P43L2 P43L3 If more than one Via header field value is present in a response, the P43L4 UAC SHOULD discard the message. P43L5 P43L6 The presence of additional Via header field values that precede P43L7 the originator of the request suggests that the message was P43L8 misrouted or possibly corrupted. P43L9 P43L10 8.1.3.4 Processing 3xx Responses P43L11 P43L12 Upon receipt of a redirection response (for example, a 301 response P43L13 status code), clients SHOULD use the URI(s) in the Contact header P43L14 field to formulate one or more new requests based on the redirected P43L15 request. This process is similar to that of a proxy recursing on a P43L16 3xx class response as detailed in Sections 16.5 and 16.6. A client P43L17 starts with an initial target set containing exactly one URI, the P43L18 Request-URI of the original request. If a client wishes to formulate P43L19 new requests based on a 3xx class response to that request, it places P43L20 the URIs to try into the target set. Subject to the restrictions in P43L21 this specification, a client can choose which Contact URIs it places P43L22 into the target set. As with proxy recursion, a client processing P43L23 3xx class responses MUST NOT add any given URI to the target set more P43L24 than once. If the original request had a SIPS URI in the Request- P43L25 URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD P43L26 inform the user of the redirection to an insecure URI. P43L27 P43L28 Any new request may receive 3xx responses themselves containing P43L29 the original URI as a contact. Two locations can be configured to P43L30 redirect to each other. Placing any given URI in the target set P43L31 only once prevents infinite redirection loops. P43L32 P43L33 As the target set grows, the client MAY generate new requests to the P43L34 URIs in any order. A common mechanism is to order the set by the "q" P43L35 parameter value from the Contact header field value. Requests to the P43L36 URIs MAY be generated serially or in parallel. One approach is to P43L37 process groups of decreasing q-values serially and process the URIs P43L38 in each q-value group in parallel. Another is to perform only serial P43L39 processing in decreasing q-value order, arbitrarily choosing between P43L40 contacts of equal q-value. P43L41 P43L42 If contacting an address in the list results in a failure, as defined P43L43 in the next paragraph, the element moves to the next address in the P43L44 list, until the list is exhausted. If the list is exhausted, then P43L45 the request has failed. P43L46 P43L47 P43L48 P44L1 Failures SHOULD be detected through failure response codes (codes P44L2 greater than 399); for network errors the client transaction will P44L3 report any transport layer failures to the transaction user. Note P44L4 that some response codes (detailed in 8.1.3.5) indicate that the P44L5 request can be retried; requests that are reattempted should not be P44L6 considered failures. P44L7 P44L8 When a failure for a particular contact address is received, the P44L9 client SHOULD try the next contact address. This will involve P44L10 creating a new client transaction to deliver a new request. P44L11 P44L12 In order to create a request based on a contact address in a 3xx P44L13 response, a UAC MUST copy the entire URI from the target set into the P44L14 Request-URI, except for the "method-param" and "header" URI P44L15 parameters (see Section 19.1.1 for a definition of these parameters). P44L16 It uses the "header" parameters to create header field values for the P44L17 new request, overwriting header field values associated with the P44L18 redirected request in accordance with the guidelines in Section P44L19 19.1.5. P44L20 P44L21 Note that in some instances, header fields that have been P44L22 communicated in the contact address may instead append to existing P44L23 request header fields in the original redirected request. As a P44L24 general rule, if the header field can accept a comma-separated list P44L25 of values, then the new header field value MAY be appended to any P44L26 existing values in the original redirected request. If the header P44L27 field does not accept multiple values, the value in the original P44L28 redirected request MAY be overwritten by the header field value P44L29 communicated in the contact address. For example, if a contact P44L30 address is returned with the following value: P44L31 P44L32 sip:user@host?Subject=foo&Call-Info= P44L33 P44L34 Then any Subject header field in the original redirected request is P44L35 overwritten, but the HTTP URL is merely appended to any existing P44L36 Call-Info header field values. P44L37 P44L38 It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID P44L39 used in the original redirected request, but the UAC MAY also choose P44L40 to update the Call-ID header field value for new requests, for P44L41 example. P44L42 P44L43 Finally, once the new request has been constructed, it is sent using P44L44 a new client transaction, and therefore MUST have a new branch ID in P44L45 the top Via field as discussed in Section 8.1.1.7. P44L46 P44L47 P44L48 P45L1 In all other respects, requests sent upon receipt of a redirect P45L2 response SHOULD re-use the header fields and bodies of the original P45L3 request. P45L4 P45L5 In some instances, Contact header field values may be cached at UAC P45L6 temporarily or permanently depending on the status code received and P45L7 the presence of an expiration interval; see Sections 21.3.2 and P45L8 21.3.3. P45L9 P45L10 8.1.3.5 Processing 4xx Responses P45L11 P45L12 Certain 4xx response codes require specific UA processing, P45L13 independent of the method. P45L14 P45L15 If a 401 (Unauthorized) or 407 (Proxy Authentication Required) P45L16 response is received, the UAC SHOULD follow the authorization P45L17 procedures of Section 22.2 and Section 22.3 to retry the request with P45L18 credentials. P45L19 P45L20 If a 413 (Request Entity Too Large) response is received (Section P45L21 21.4.11), the request contained a body that was longer than the UAS P45L22 was willing to accept. If possible, the UAC SHOULD retry the P45L23 request, either omitting the body or using one of a smaller length. P45L24 P45L25 If a 415 (Unsupported Media Type) response is received (Section P45L26 21.4.13), the request contained media types not supported by the UAS. P45L27 The UAC SHOULD retry sending the request, this time only using P45L28 content with types listed in the Accept header field in the response, P45L29 with encodings listed in the Accept-Encoding header field in the P45L30 response, and with languages listed in the Accept-Language in the P45L31 response. P45L32 P45L33 If a 416 (Unsupported URI Scheme) response is received (Section P45L34 21.4.14), the Request-URI used a URI scheme not supported by the P45L35 server. The client SHOULD retry the request, this time, using a SIP P45L36 URI. P45L37 P45L38 If a 420 (Bad Extension) response is received (Section 21.4.15), the P45L39 request contained a Require or Proxy-Require header field listing an P45L40 option-tag for a feature not supported by a proxy or UAS. The UAC P45L41 SHOULD retry the request, this time omitting any extensions listed in P45L42 the Unsupported header field in the response. P45L43 P45L44 In all of the above cases, the request is retried by creating a new P45L45 request with the appropriate modifications. This new request P45L46 constitutes a new transaction and SHOULD have the same value of the P45L47 Call-ID, To, and From of the previous request, but the CSeq should P45L48 contain a new sequence number that is one higher than the previous. P46L1 With other 4xx responses, including those yet to be defined, a retry P46L2 may or may not be possible depending on the method and the use case. P46L3 P46L4 8.2 UAS Behavior P46L5 P46L6 When a request outside of a dialog is processed by a UAS, there is a P46L7 set of processing rules that are followed, independent of the method. P46L8 Section 12 gives guidance on how a UAS can tell whether a request is P46L9 inside or outside of a dialog. P46L10 P46L11 Note that request processing is atomic. If a request is accepted, P46L12 all state changes associated with it MUST be performed. If it is P46L13 rejected, all state changes MUST NOT be performed. P46L14 P46L15 UASs SHOULD process the requests in the order of the steps that P46L16 follow in this section (that is, starting with authentication, then P46L17 inspecting the method, the header fields, and so on throughout the P46L18 remainder of this section). P46L19 P46L20 8.2.1 Method Inspection P46L21 P46L22 Once a request is authenticated (or authentication is skipped), the P46L23 UAS MUST inspect the method of the request. If the UAS recognizes P46L24 but does not support the method of a request, it MUST generate a 405 P46L25 (Method Not Allowed) response. Procedures for generating responses P46L26 are described in Section 8.2.6. The UAS MUST also add an Allow P46L27 header field to the 405 (Method Not Allowed) response. The Allow P46L28 header field MUST list the set of methods supported by the UAS P46L29 generating the message. The Allow header field is presented in P46L30 Section 20.5. P46L31 P46L32 If the method is one supported by the server, processing continues. P46L33 P46L34 8.2.2 Header Inspection P46L35 P46L36 If a UAS does not understand a header field in a request (that is, P46L37 the header field is not defined in this specification or in any P46L38 supported extension), the server MUST ignore that header field and P46L39 continue processing the message. A UAS SHOULD ignore any malformed P46L40 header fields that are not necessary for processing requests. P46L41 P46L42 8.2.2.1 To and Request-URI P46L43 P46L44 The To header field identifies the original recipient of the request P46L45 designated by the user identified in the From field. The original P46L46 recipient may or may not be the UAS processing the request, due to P46L47 call forwarding or other proxy operations. A UAS MAY apply any P46L48 policy it wishes to determine whether to accept requests when the To P47L1 header field is not the identity of the UAS. However, it is P47L2 RECOMMENDED that a UAS accept requests even if they do not recognize P47L3 the URI scheme (for example, a tel: URI) in the To header field, or P47L4 if the To header field does not address a known or current user of P47L5 this UAS. If, on the other hand, the UAS decides to reject the P47L6 request, it SHOULD generate a response with a 403 (Forbidden) status P47L7 code and pass it to the server transaction for transmission. P47L8 P47L9 However, the Request-URI identifies the UAS that is to process the P47L10 request. If the Request-URI uses a scheme not supported by the UAS, P47L11 it SHOULD reject the request with a 416 (Unsupported URI Scheme) P47L12 response. If the Request-URI does not identify an address that the P47L13 UAS is willing to accept requests for, it SHOULD reject the request P47L14 with a 404 (Not Found) response. Typically, a UA that uses the P47L15 REGISTER method to bind its address-of-record to a specific contact P47L16 address will see requests whose Request-URI equals that contact P47L17 address. Other potential sources of received Request-URIs include P47L18 the Contact header fields of requests and responses sent by the UA P47L19 that establish or refresh dialogs. P47L20 P47L21 8.2.2.2 Merged Requests P47L22 P47L23 If the request has no tag in the To header field, the UAS core MUST P47L24 check the request against ongoing transactions. If the From tag, P47L25 Call-ID, and CSeq exactly match those associated with an ongoing P47L26 transaction, but the request does not match that transaction (based P47L27 on the matching rules in Section 17.2.3), the UAS core SHOULD P47L28 generate a 482 (Loop Detected) response and pass it to the server P47L29 transaction. P47L30 P47L31 The same request has arrived at the UAS more than once, following P47L32 different paths, most likely due to forking. The UAS processes P47L33 the first such request received and responds with a 482 (Loop P47L34 Detected) to the rest of them. P47L35 P47L36 8.2.2.3 Require P47L37 P47L38 Assuming the UAS decides that it is the proper element to process the P47L39 request, it examines the Require header field, if present. P47L40 P47L41 The Require header field is used by a UAC to tell a UAS about SIP P47L42 extensions that the UAC expects the UAS to support in order to P47L43 process the request properly. Its format is described in Section P47L44 20.32. If a UAS does not understand an option-tag listed in a P47L45 Require header field, it MUST respond by generating a response with P47L46 status code 420 (Bad Extension). The UAS MUST add an Unsupported P47L47 header field, and list in it those options it does not understand P47L48 amongst those in the Require header field of the request. P48L1 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL P48L2 request, or in an ACK request sent for a non-2xx response. These P48L3 header fields MUST be ignored if they are present in these requests. P48L4 P48L5 An ACK request for a 2xx response MUST contain only those Require and P48L6 Proxy-Require values that were present in the initial request. P48L7 P48L8 Example: P48L9 P48L10 UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 P48L11 Require: 100rel P48L12 P48L13 UAS->UAC: SIP/2.0 420 Bad Extension P48L14 Unsupported: 100rel P48L15 P48L16 This behavior ensures that the client-server interaction will P48L17 proceed without delay when all options are understood by both P48L18 sides, and only slow down if options are not understood (as in the P48L19 example above). For a well-matched client-server pair, the P48L20 interaction proceeds quickly, saving a round-trip often required P48L21 by negotiation mechanisms. In addition, it also removes ambiguity P48L22 when the client requires features that the server does not P48L23 understand. Some features, such as call handling fields, are only P48L24 of interest to end systems. P48L25 P48L26 8.2.3 Content Processing P48L27 P48L28 Assuming the UAS understands any extensions required by the client, P48L29 the UAS examines the body of the message, and the header fields that P48L30 describe it. If there are any bodies whose type (indicated by the P48L31 Content-Type), language (indicated by the Content-Language) or P48L32 encoding (indicated by the Content-Encoding) are not understood, and P48L33 that body part is not optional (as indicated by the Content- P48L34 Disposition header field), the UAS MUST reject the request with a 415 P48L35 (Unsupported Media Type) response. The response MUST contain an P48L36 Accept header field listing the types of all bodies it understands, P48L37 in the event the request contained bodies of types not supported by P48L38 the UAS. If the request contained content encodings not understood P48L39 by the UAS, the response MUST contain an Accept-Encoding header field P48L40 listing the encodings understood by the UAS. If the request P48L41 contained content with languages not understood by the UAS, the P48L42 response MUST contain an Accept-Language header field indicating the P48L43 languages understood by the UAS. Beyond these checks, body handling P48L44 depends on the method and type. For further information on the P48L45 processing of content-specific header fields, see Section 7.4 as well P48L46 as Section 20.11 through 20.15. P48L47 P48L48 P49L1 8.2.4 Applying Extensions P49L2 P49L3 A UAS that wishes to apply some extension when generating the P49L4 response MUST NOT do so unless support for that extension is P49L5 indicated in the Supported header field in the request. If the P49L6 desired extension is not supported, the server SHOULD rely only on P49L7 baseline SIP and any other extensions supported by the client. In P49L8 rare circumstances, where the server cannot process the request P49L9 without the extension, the server MAY send a 421 (Extension Required) P49L10 response. This response indicates that the proper response cannot be P49L11 generated without support of a specific extension. The needed P49L12 extension(s) MUST be included in a Require header field in the P49L13 response. This behavior is NOT RECOMMENDED, as it will generally P49L14 break interoperability. P49L15 P49L16 Any extensions applied to a non-421 response MUST be listed in a P49L17 Require header field included in the response. Of course, the server P49L18 MUST NOT apply extensions not listed in the Supported header field in P49L19 the request. As a result of this, the Require header field in a P49L20 response will only ever contain option tags defined in standards- P49L21 track RFCs. P49L22 P49L23 8.2.5 Processing the Request P49L24 P49L25 Assuming all of the checks in the previous subsections are passed, P49L26 the UAS processing becomes method-specific. Section 10 covers the P49L27 REGISTER request, Section 11 covers the OPTIONS request, Section 13 P49L28 covers the INVITE request, and Section 15 covers the BYE request. P49L29 P49L30 8.2.6 Generating the Response P49L31 P49L32 When a UAS wishes to construct a response to a request, it follows P49L33 the general procedures detailed in the following subsections. P49L34 Additional behaviors specific to the response code in question, which P49L35 are not detailed in this section, may also be required. P49L36 P49L37 Once all procedures associated with the creation of a response have P49L38 been completed, the UAS hands the response back to the server P49L39 transaction from which it received the request. P49L40 P49L41 8.2.6.1 Sending a Provisional Response P49L42 P49L43 One largely non-method-specific guideline for the generation of P49L44 responses is that UASs SHOULD NOT issue a provisional response for a P49L45 non-INVITE request. Rather, UASs SHOULD generate a final response to P49L46 a non-INVITE request as soon as possible. P49L47 P49L48 P50L1 When a 100 (Trying) response is generated, any Timestamp header field P50L2 present in the request MUST be copied into this 100 (Trying) P50L3 response. If there is a delay in generating the response, the UAS P50L4 SHOULD add a delay value into the Timestamp value in the response. P50L5 This value MUST contain the difference between the time of sending of P50L6 the response and receipt of the request, measured in seconds. P50L7 P50L8 8.2.6.2 Headers and Tags P50L9 P50L10 The From field of the response MUST equal the From header field of P50L11 the request. The Call-ID header field of the response MUST equal the P50L12 Call-ID header field of the request. The CSeq header field of the P50L13 response MUST equal the CSeq field of the request. The Via header P50L14 field values in the response MUST equal the Via header field values P50L15 in the request and MUST maintain the same ordering. P50L16 P50L17 If a request contained a To tag in the request, the To header field P50L18 in the response MUST equal that of the request. However, if the To P50L19 header field in the request did not contain a tag, the URI in the To P50L20 header field in the response MUST equal the URI in the To header P50L21 field; additionally, the UAS MUST add a tag to the To header field in P50L22 the response (with the exception of the 100 (Trying) response, in P50L23 which a tag MAY be present). This serves to identify the UAS that is P50L24 responding, possibly resulting in a component of a dialog ID. The P50L25 same tag MUST be used for all responses to that request, both final P50L26 and provisional (again excepting the 100 (Trying)). Procedures for P50L27 the generation of tags are defined in Section 19.3. P50L28 P50L29 8.2.7 Stateless UAS Behavior P50L30 P50L31 A stateless UAS is a UAS that does not maintain transaction state. P50L32 It replies to requests normally, but discards any state that would P50L33 ordinarily be retained by a UAS after a response has been sent. If a P50L34 stateless UAS receives a retransmission of a request, it regenerates P50L35 the response and resends it, just as if it were replying to the first P50L36 instance of the request. A UAS cannot be stateless unless the request P50L37 processing for that method would always result in the same response P50L38 if the requests are identical. This rules out stateless registrars, P50L39 for example. Stateless UASs do not use a transaction layer; they P50L40 receive requests directly from the transport layer and send responses P50L41 directly to the transport layer. P50L42 P50L43 The stateless UAS role is needed primarily to handle unauthenticated P50L44 requests for which a challenge response is issued. If P50L45 unauthenticated requests were handled statefully, then malicious P50L46 floods of unauthenticated requests could create massive amounts of P50L47 P50L48 P51L1 transaction state that might slow or completely halt call processing P51L2 in a UAS, effectively creating a denial of service condition; for P51L3 more information see Section 26.1.5. P51L4 P51L5 The most important behaviors of a stateless UAS are the following: P51L6 P51L7 o A stateless UAS MUST NOT send provisional (1xx) responses. P51L8 P51L9 o A stateless UAS MUST NOT retransmit responses. P51L10 P51L11 o A stateless UAS MUST ignore ACK requests. P51L12 P51L13 o A stateless UAS MUST ignore CANCEL requests. P51L14 P51L15 o To header tags MUST be generated for responses in a stateless P51L16 manner - in a manner that will generate the same tag for the P51L17 same request consistently. For information on tag construction P51L18 see Section 19.3. P51L19 P51L20 In all other respects, a stateless UAS behaves in the same manner as P51L21 a stateful UAS. A UAS can operate in either a stateful or stateless P51L22 mode for each new request. P51L23 P51L24 8.3 Redirect Servers P51L25 P51L26 In some architectures it may be desirable to reduce the processing P51L27 load on proxy servers that are responsible for routing requests, and P51L28 improve signaling path robustness, by relying on redirection. P51L29 P51L30 Redirection allows servers to push routing information for a request P51L31 back in a response to the client, thereby taking themselves out of P51L32 the loop of further messaging for this transaction while still aiding P51L33 in locating the target of the request. When the originator of the P51L34 request receives the redirection, it will send a new request based on P51L35 the URI(s) it has received. By propagating URIs from the core of the P51L36 network to its edges, redirection allows for considerable network P51L37 scalability. P51L38 P51L39 A redirect server is logically constituted of a server transaction P51L40 layer and a transaction user that has access to a location service of P51L41 some kind (see Section 10 for more on registrars and location P51L42 services). This location service is effectively a database P51L43 containing mappings between a single URI and a set of one or more P51L44 alternative locations at which the target of that URI can be found. P51L45 P51L46 A redirect server does not issue any SIP requests of its own. After P51L47 receiving a request other than CANCEL, the server either refuses the P51L48 request or gathers the list of alternative locations from the P52L1 location service and returns a final response of class 3xx. For P52L2 well-formed CANCEL requests, it SHOULD return a 2xx response. This P52L3 response ends the SIP transaction. The redirect server maintains P52L4 transaction state for an entire SIP transaction. It is the P52L5 responsibility of clients to detect forwarding loops between redirect P52L6 servers. P52L7 P52L8 When a redirect server returns a 3xx response to a request, it P52L9 populates the list of (one or more) alternative locations into the P52L10 Contact header field. An "expires" parameter to the Contact header P52L11 field values may also be supplied to indicate the lifetime of the P52L12 Contact data. P52L13 P52L14 The Contact header field contains URIs giving the new locations or P52L15 user names to try, or may simply specify additional transport P52L16 parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) P52L17 response may also give the same location and username that was P52L18 targeted by the initial request but specify additional transport P52L19 parameters such as a different server or multicast address to try, or P52L20 a change of SIP transport from UDP to TCP or vice versa. P52L21 P52L22 However, redirect servers MUST NOT redirect a request to a URI equal P52L23 to the one in the Request-URI; instead, provided that the URI does P52L24 not point to itself, the server MAY proxy the request to the P52L25 destination URI, or MAY reject it with a 404. P52L26 P52L27 If a client is using an outbound proxy, and that proxy actually P52L28 redirects requests, a potential arises for infinite redirection P52L29 loops. P52L30 P52L31 Note that a Contact header field value MAY also refer to a different P52L32 resource than the one originally called. For example, a SIP call P52L33 connected to PSTN gateway may need to deliver a special informational P52L34 announcement such as "The number you have dialed has been changed." P52L35 P52L36 A Contact response header field can contain any suitable URI P52L37 indicating where the called party can be reached, not limited to SIP P52L38 URIs. For example, it could contain URIs for phones, fax, or irc (if P52L39 they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 P52L40 discusses implications and limitations of redirecting a SIPS URI to a P52L41 non-SIPS URI. P52L42 P52L43 The "expires" parameter of a Contact header field value indicates how P52L44 long the URI is valid. The value of the parameter is a number P52L45 indicating seconds. If this parameter is not provided, the value of P52L46 the Expires header field determines how long the URI is valid. P52L47 Malformed values SHOULD be treated as equivalent to 3600. P52L48 P53L1 This provides a modest level of backwards compatibility with RFC P53L2 2543, which allowed absolute times in this header field. If an P53L3 absolute time is received, it will be treated as malformed, and P53L4 then default to 3600. P53L5 P53L6 Redirect servers MUST ignore features that are not understood P53L7 (including unrecognized header fields, any unknown option tags in P53L8 Require, or even method names) and proceed with the redirection of P53L9 the request in question. P53L10 P53L11 9 Canceling a Request P53L12 P53L13 The previous section has discussed general UA behavior for generating P53L14 requests and processing responses for requests of all methods. In P53L15 this section, we discuss a general purpose method, called CANCEL. P53L16 P53L17 The CANCEL request, as the name implies, is used to cancel a previous P53L18 request sent by a client. Specifically, it asks the UAS to cease P53L19 processing the request and to generate an error response to that P53L20 request. CANCEL has no effect on a request to which a UAS has P53L21 already given a final response. Because of this, it is most useful P53L22 to CANCEL requests to which it can take a server long time to P53L23 respond. For this reason, CANCEL is best for INVITE requests, which P53L24 can take a long time to generate a response. In that usage, a UAS P53L25 that receives a CANCEL request for an INVITE, but has not yet sent a P53L26 final response, would "stop ringing", and then respond to the INVITE P53L27 with a specific error response (a 487). P53L28 P53L29 CANCEL requests can be constructed and sent by both proxies and user P53L30 agent clients. Section 15 discusses under what conditions a UAC P53L31 would CANCEL an INVITE request, and Section 16.10 discusses proxy P53L32 usage of CANCEL. P53L33 P53L34 A stateful proxy responds to a CANCEL, rather than simply forwarding P53L35 a response it would receive from a downstream element. For that P53L36 reason, CANCEL is referred to as a "hop-by-hop" request, since it is P53L37 responded to at each stateful proxy hop. P53L38 P53L39 9.1 Client Behavior P53L40 P53L41 A CANCEL request SHOULD NOT be sent to cancel a request other than P53L42 INVITE. P53L43 P53L44 Since requests other than INVITE are responded to immediately, P53L45 sending a CANCEL for a non-INVITE request would always create a P53L46 race condition. P53L47 P53L48 P54L1 The following procedures are used to construct a CANCEL request. The P54L2 Request-URI, Call-ID, To, the numeric part of CSeq, and From header P54L3 fields in the CANCEL request MUST be identical to those in the P54L4 request being cancelled, including tags. A CANCEL constructed by a P54L5 client MUST have only a single Via header field value matching the P54L6 top Via value in the request being cancelled. Using the same values P54L7 for these header fields allows the CANCEL to be matched with the P54L8 request it cancels (Section 9.2 indicates how such matching occurs). P54L9 However, the method part of the CSeq header field MUST have a value P54L10 of CANCEL. This allows it to be identified and processed as a P54L11 transaction in its own right (See Section 17). P54L12 P54L13 If the request being cancelled contains a Route header field, the P54L14 CANCEL request MUST include that Route header field's values. P54L15 P54L16 This is needed so that stateless proxies are able to route CANCEL P54L17 requests properly. P54L18 P54L19 The CANCEL request MUST NOT contain any Require or Proxy-Require P54L20 header fields. P54L21 P54L22 Once the CANCEL is constructed, the client SHOULD check whether it P54L23 has received any response (provisional or final) for the request P54L24 being cancelled (herein referred to as the "original request"). P54L25 P54L26 If no provisional response has been received, the CANCEL request MUST P54L27 NOT be sent; rather, the client MUST wait for the arrival of a P54L28 provisional response before sending the request. If the original P54L29 request has generated a final response, the CANCEL SHOULD NOT be P54L30 sent, as it is an effective no-op, since CANCEL has no effect on P54L31 requests that have already generated a final response. When the P54L32 client decides to send the CANCEL, it creates a client transaction P54L33 for the CANCEL and passes it the CANCEL request along with the P54L34 destination address, port, and transport. The destination address, P54L35 port, and transport for the CANCEL MUST be identical to those used to P54L36 send the original request. P54L37 P54L38 If it was allowed to send the CANCEL before receiving a response P54L39 for the previous request, the server could receive the CANCEL P54L40 before the original request. P54L41 P54L42 Note that both the transaction corresponding to the original request P54L43 and the CANCEL transaction will complete independently. However, a P54L44 UAC canceling a request cannot rely on receiving a 487 (Request P54L45 Terminated) response for the original request, as an RFC 2543- P54L46 compliant UAS will not generate such a response. If there is no P54L47 final response for the original request in 64*T1 seconds (T1 is P54L48 P55L1 defined in Section 17.1.1.1), the client SHOULD then consider the P55L2 original transaction cancelled and SHOULD destroy the client P55L3 transaction handling the original request. P55L4 P55L5 9.2 Server Behavior P55L6 P55L7 The CANCEL method requests that the TU at the server side cancel a P55L8 pending transaction. The TU determines the transaction to be P55L9 cancelled by taking the CANCEL request, and then assuming that the P55L10 request method is anything but CANCEL or ACK and applying the P55L11 transaction matching procedures of Section 17.2.3. The matching P55L12 transaction is the one to be cancelled. P55L13 P55L14 The processing of a CANCEL request at a server depends on the type of P55L15 server. A stateless proxy will forward it, a stateful proxy might P55L16 respond to it and generate some CANCEL requests of its own, and a UAS P55L17 will respond to it. See Section 16.10 for proxy treatment of CANCEL. P55L18 P55L19 A UAS first processes the CANCEL request according to the general UAS P55L20 processing described in Section 8.2. However, since CANCEL requests P55L21 are hop-by-hop and cannot be resubmitted, they cannot be challenged P55L22 by the server in order to get proper credentials in an Authorization P55L23 header field. Note also that CANCEL requests do not contain a P55L24 Require header field. P55L25 P55L26 If the UAS did not find a matching transaction for the CANCEL P55L27 according to the procedure above, it SHOULD respond to the CANCEL P55L28 with a 481 (Call Leg/Transaction Does Not Exist). If the transaction P55L29 for the original request still exists, the behavior of the UAS on P55L30 receiving a CANCEL request depends on whether it has already sent a P55L31 final response for the original request. If it has, the CANCEL P55L32 request has no effect on the processing of the original request, no P55L33 effect on any session state, and no effect on the responses generated P55L34 for the original request. If the UAS has not issued a final response P55L35 for the original request, its behavior depends on the method of the P55L36 original request. If the original request was an INVITE, the UAS P55L37 SHOULD immediately respond to the INVITE with a 487 (Request P55L38 Terminated). A CANCEL request has no impact on the processing of P55L39 transactions with any other method defined in this specification. P55L40 P55L41 Regardless of the method of the original request, as long as the P55L42 CANCEL matched an existing transaction, the UAS answers the CANCEL P55L43 request itself with a 200 (OK) response. This response is P55L44 constructed following the procedures described in Section 8.2.6 P55L45 noting that the To tag of the response to the CANCEL and the To tag P55L46 in the response to the original request SHOULD be the same. The P55L47 response to CANCEL is passed to the server transaction for P55L48 transmission. P56L1 10 Registrations P56L2 P56L3 10.1 Overview P56L4 P56L5 SIP offers a discovery capability. If a user wants to initiate a P56L6 session with another user, SIP must discover the current host(s) at P56L7 which the destination user is reachable. This discovery process is P56L8 frequently accomplished by SIP network elements such as proxy servers P56L9 and redirect servers which are responsible for receiving a request, P56L10 determining where to send it based on knowledge of the location of P56L11 the user, and then sending it there. To do this, SIP network P56L12 elements consult an abstract service known as a location service, P56L13 which provides address bindings for a particular domain. These P56L14 address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, P56L15 for example, to one or more URIs that are somehow "closer" to the P56L16 desired user, sip:bob@engineering.biloxi.com, for example. P56L17 Ultimately, a proxy will consult a location service that maps a P56L18 received URI to the user agent(s) at which the desired recipient is P56L19 currently residing. P56L20 P56L21 Registration creates bindings in a location service for a particular P56L22 domain that associates an address-of-record URI with one or more P56L23 contact addresses. Thus, when a proxy for that domain receives a P56L24 request whose Request-URI matches the address-of-record, the proxy P56L25 will forward the request to the contact addresses registered to that P56L26 address-of-record. Generally, it only makes sense to register an P56L27 address-of-record at a domain's location service when requests for P56L28 that address-of-record would be routed to that domain. In most P56L29 cases, this means that the domain of the registration will need to P56L30 match the domain in the URI of the address-of-record. P56L31 P56L32 There are many ways by which the contents of the location service can P56L33 be established. One way is administratively. In the above example, P56L34 Bob is known to be a member of the engineering department through P56L35 access to a corporate database. However, SIP provides a mechanism P56L36 for a UA to create a binding explicitly. This mechanism is known as P56L37 registration. P56L38 P56L39 Registration entails sending a REGISTER request to a special type of P56L40 UAS known as a registrar. A registrar acts as the front end to the P56L41 location service for a domain, reading and writing mappings based on P56L42 the contents of REGISTER requests. This location service is then P56L43 typically consulted by a proxy server that is responsible for routing P56L44 requests for that domain. P56L45 P56L46 An illustration of the overall registration process is given in P56L47 Figure 2. Note that the registrar and proxy server are logical roles P56L48 that can be played by a single device in a network; for purposes of P57L1 clarity the two are separated in this illustration. Also note that P57L2 UAs may send requests through a proxy server in order to reach a P57L3 registrar if the two are separate elements. P57L4 P57L5 SIP does not mandate a particular mechanism for implementing the P57L6 location service. The only requirement is that a registrar for some P57L7 domain MUST be able to read and write data to the location service, P57L8 and a proxy or a redirect server for that domain MUST be capable of P57L9 reading that same data. A registrar MAY be co-located with a P57L10 particular SIP proxy server for the same domain. P57L11 P57L12 10.2 Constructing the REGISTER Request P57L13 P57L14 REGISTER requests add, remove, and query bindings. A REGISTER P57L15 request can add a new binding between an address-of-record and one or P57L16 more contact addresses. Registration on behalf of a particular P57L17 address-of-record can be performed by a suitably authorized third P57L18 party. A client can also remove previous bindings or query to P57L19 determine which bindings are currently in place for an address-of- P57L20 record. P57L21 P57L22 Except as noted, the construction of the REGISTER request and the P57L23 behavior of clients sending a REGISTER request is identical to the P57L24 general UAC behavior described in Section 8.1 and Section 17.1. P57L25 P57L26 A REGISTER request does not establish a dialog. A UAC MAY include a P57L27 Route header field in a REGISTER request based on a pre-existing P57L28 route set as described in Section 8.1. The Record-Route header field P57L29 has no meaning in REGISTER requests or responses, and MUST be ignored P57L30 if present. In particular, the UAC MUST NOT create a new route set P57L31 based on the presence or absence of a Record-Route header field in P57L32 any response to a REGISTER request. P57L33 P57L34 The following header fields, except Contact, MUST be included in a P57L35 REGISTER request. A Contact header field MAY be included: P57L36 P57L37 Request-URI: The Request-URI names the domain of the location P57L38 service for which the registration is meant (for example, P57L39 "sip:chicago.com"). The "userinfo" and "@" components of the P57L40 SIP URI MUST NOT be present. P57L41 P57L42 To: The To header field contains the address of record whose P57L43 registration is to be created, queried, or modified. The To P57L44 header field and the Request-URI field typically differ, as P57L45 the former contains a user name. This address-of-record MUST P57L46 be a SIP URI or SIPS URI. P57L47 P57L48 P58L1 From: The From header field contains the address-of-record of the P58L2 person responsible for the registration. The value is the P58L3 same as the To header field unless the request is a third- P58L4 party registration. P58L5 P58L6 Call-ID: All registrations from a UAC SHOULD use the same Call-ID P58L7 header field value for registrations sent to a particular P58L8 registrar. P58L9 P58L10 If the same client were to use different Call-ID values, a P58L11 registrar could not detect whether a delayed REGISTER request P58L12 might have arrived out of order. P58L13 P58L14 CSeq: The CSeq value guarantees proper ordering of REGISTER P58L15 requests. A UA MUST increment the CSeq value by one for each P58L16 REGISTER request with the same Call-ID. P58L17 P58L18 Contact: REGISTER requests MAY contain a Contact header field with P58L19 zero or more values containing address bindings. P58L20 P58L21 UAs MUST NOT send a new registration (that is, containing new Contact P58L22 header field values, as opposed to a retransmission) until they have P58L23 received a final response from the registrar for the previous one or P58L24 the previous REGISTER request has timed out. P58L25 P58L26 P58L27 P58L28 P58L29 P58L30 P58L31 P58L32 P58L33 P58L34 P58L35 P58L36 P58L37 P58L38 P58L39 P58L40 P58L41 P58L42 P58L43 P58L44 P58L45 P58L46 P58L47 P58L48 P59L1 bob P59L2 +----+ P59L3 | UA | P59L4 | | P59L5 +----+ P59L6 | P59L7 |3)INVITE P59L8 | carol@chicago.com P59L9 chicago.com +--------+ V P59L10 +---------+ 2)Store|Location|4)Query +-----+ P59L11 |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com P59L12 +---------+ +--------+=======>+-----+ P59L13 A 5)Resp | P59L14 | | P59L15 | | P59L16 1)REGISTER| | P59L17 | | P59L18 +----+ | P59L19 | UA |<-------------------------------+ P59L20 cube2214a| | 6)INVITE P59L21 +----+ carol@cube2214a.chicago.com P59L22 carol P59L23 P59L24 Figure 2: REGISTER example P59L25 P59L26 The following Contact header parameters have a special meaning in P59L27 REGISTER requests: P59L28 P59L29 action: The "action" parameter from RFC 2543 has been deprecated. P59L30 UACs SHOULD NOT use the "action" parameter. P59L31 P59L32 expires: The "expires" parameter indicates how long the UA would P59L33 like the binding to be valid. The value is a number P59L34 indicating seconds. If this parameter is not provided, the P59L35 value of the Expires header field is used instead. P59L36 Implementations MAY treat values larger than 2**32-1 P59L37 (4294967295 seconds or 136 years) as equivalent to 2**32-1. P59L38 Malformed values SHOULD be treated as equivalent to 3600. P59L39 P59L40 10.2.1 Adding Bindings P59L41 P59L42 The REGISTER request sent to a registrar includes the contact P59L43 address(es) to which SIP requests for the address-of-record should be P59L44 forwarded. The address-of-record is included in the To header field P59L45 of the REGISTER request. P59L46 P59L47 P59L48 P60L1 The Contact header field values of the request typically consist of P60L2 SIP or SIPS URIs that identify particular SIP endpoints (for example, P60L3 "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. P60L4 A SIP UA can choose to register telephone numbers (with the tel URL, P60L5 RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) P60L6 as Contacts for an address-of-record, for example. P60L7 P60L8 For example, Carol, with address-of-record "sip:carol@chicago.com", P60L9 would register with the SIP registrar of the domain chicago.com. Her P60L10 registrations would then be used by a proxy server in the chicago.com P60L11 domain to route requests for Carol's address-of-record to her SIP P60L12 endpoint. P60L13 P60L14 Once a client has established bindings at a registrar, it MAY send P60L15 subsequent registrations containing new bindings or modifications to P60L16 existing bindings as necessary. The 2xx response to the REGISTER P60L17 request will contain, in a Contact header field, a complete list of P60L18 bindings that have been registered for this address-of-record at this P60L19 registrar. P60L20 P60L21 If the address-of-record in the To header field of a REGISTER request P60L22 is a SIPS URI, then any Contact header field values in the request P60L23 SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs P60L24 under a SIPS address-of-record when the security of the resource P60L25 represented by the contact address is guaranteed by other means. P60L26 This may be applicable to URIs that invoke protocols other than SIP, P60L27 or SIP devices secured by protocols other than TLS. P60L28 P60L29 Registrations do not need to update all bindings. Typically, a UA P60L30 only updates its own contact addresses. P60L31 P60L32 10.2.1.1 Setting the Expiration Interval of Contact Addresses P60L33 P60L34 When a client sends a REGISTER request, it MAY suggest an expiration P60L35 interval that indicates how long the client would like the P60L36 registration to be valid. (As described in Section 10.3, the P60L37 registrar selects the actual time interval based on its local P60L38 policy.) P60L39 P60L40 There are two ways in which a client can suggest an expiration P60L41 interval for a binding: through an Expires header field or an P60L42 "expires" Contact header parameter. The latter allows expiration P60L43 intervals to be suggested on a per-binding basis when more than one P60L44 binding is given in a single REGISTER request, whereas the former P60L45 suggests an expiration interval for all Contact header field values P60L46 that do not contain the "expires" parameter. P60L47 P60L48 P61L1 If neither mechanism for expressing a suggested expiration time is P61L2 present in a REGISTER, the client is indicating its desire for the P61L3 server to choose. P61L4 P61L5 10.2.1.2 Preferences among Contact Addresses P61L6 P61L7 If more than one Contact is sent in a REGISTER request, the P61L8 registering UA intends to associate all of the URIs in these Contact P61L9 header field values with the address-of-record present in the To P61L10 field. This list can be prioritized with the "q" parameter in the P61L11 Contact header field. The "q" parameter indicates a relative P61L12 preference for the particular Contact header field value compared to P61L13 other bindings for this address-of-record. Section 16.6 describes P61L14 how a proxy server uses this preference indication. P61L15 P61L16 10.2.2 Removing Bindings P61L17 P61L18 Registrations are soft state and expire unless refreshed, but can P61L19 also be explicitly removed. A client can attempt to influence the P61L20 expiration interval selected by the registrar as described in Section P61L21 10.2.1. A UA requests the immediate removal of a binding by P61L22 specifying an expiration interval of "0" for that contact address in P61L23 a REGISTER request. UAs SHOULD support this mechanism so that P61L24 bindings can be removed before their expiration interval has passed. P61L25 P61L26 The REGISTER-specific Contact header field value of "*" applies to P61L27 all registrations, but it MUST NOT be used unless the Expires header P61L28 field is present with a value of "0". P61L29 P61L30 Use of the "*" Contact header field value allows a registering UA P61L31 to remove all bindings associated with an address-of-record P61L32 without knowing their precise values. P61L33 P61L34 10.2.3 Fetching Bindings P61L35 P61L36 A success response to any REGISTER request contains the complete list P61L37 of existing bindings, regardless of whether the request contained a P61L38 Contact header field. If no Contact header field is present in a P61L39 REGISTER request, the list of bindings is left unchanged. P61L40 P61L41 10.2.4 Refreshing Bindings P61L42 P61L43 Each UA is responsible for refreshing the bindings that it has P61L44 previously established. A UA SHOULD NOT refresh bindings set up by P61L45 other UAs. P61L46 P61L47 P61L48 P62L1 The 200 (OK) response from the registrar contains a list of Contact P62L2 fields enumerating all current bindings. The UA compares each P62L3 contact address to see if it created the contact address, using P62L4 comparison rules in Section 19.1.4. If so, it updates the expiration P62L5 time interval according to the expires parameter or, if absent, the P62L6 Expires field value. The UA then issues a REGISTER request for each P62L7 of its bindings before the expiration interval has elapsed. It MAY P62L8 combine several updates into one REGISTER request. P62L9 P62L10 A UA SHOULD use the same Call-ID for all registrations during a P62L11 single boot cycle. Registration refreshes SHOULD be sent to the same P62L12 network address as the original registration, unless redirected. P62L13 P62L14 10.2.5 Setting the Internal Clock P62L15 P62L16 If the response for a REGISTER request contains a Date header field, P62L17 the client MAY use this header field to learn the current time in P62L18 order to set any internal clocks. P62L19 P62L20 10.2.6 Discovering a Registrar P62L21 P62L22 UAs can use three ways to determine the address to which to send P62L23 registrations: by configuration, using the address-of-record, and P62L24 multicast. A UA can be configured, in ways beyond the scope of this P62L25 specification, with a registrar address. If there is no configured P62L26 registrar address, the UA SHOULD use the host part of the address- P62L27 of-record as the Request-URI and address the request there, using the P62L28 normal SIP server location mechanisms [4]. For example, the UA for P62L29 the user "sip:carol@chicago.com" addresses the REGISTER request to P62L30 "sip:chicago.com". P62L31 P62L32 Finally, a UA can be configured to use multicast. Multicast P62L33 registrations are addressed to the well-known "all SIP servers" P62L34 multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- P62L35 known IPv6 multicast address has been allocated; such an allocation P62L36 will be documented separately when needed. SIP UAs MAY listen to P62L37 that address and use it to become aware of the location of other P62L38 local users (see [33]); however, they do not respond to the request. P62L39 P62L40 Multicast registration may be inappropriate in some environments, P62L41 for example, if multiple businesses share the same local area P62L42 network. P62L43 P62L44 10.2.7 Transmitting a Request P62L45 P62L46 Once the REGISTER method has been constructed, and the destination of P62L47 the message identified, UACs follow the procedures described in P62L48 Section 8.1.2 to hand off the REGISTER to the transaction layer. P63L1 If the transaction layer returns a timeout error because the REGISTER P63L2 yielded no response, the UAC SHOULD NOT immediately re-attempt a P63L3 registration to the same registrar. P63L4 P63L5 An immediate re-attempt is likely to also timeout. Waiting some P63L6 reasonable time interval for the conditions causing the timeout to P63L7 be corrected reduces unnecessary load on the network. No specific P63L8 interval is mandated. P63L9 P63L10 10.2.8 Error Responses P63L11 P63L12 If a UA receives a 423 (Interval Too Brief) response, it MAY retry P63L13 the registration after making the expiration interval of all contact P63L14 addresses in the REGISTER request equal to or greater than the P63L15 expiration interval within the Min-Expires header field of the 423 P63L16 (Interval Too Brief) response. P63L17 P63L18 10.3 Processing REGISTER Requests P63L19 P63L20 A registrar is a UAS that responds to REGISTER requests and maintains P63L21 a list of bindings that are accessible to proxy servers and redirect P63L22 servers within its administrative domain. A registrar handles P63L23 requests according to Section 8.2 and Section 17.2, but it accepts P63L24 only REGISTER requests. A registrar MUST not generate 6xx responses. P63L25 P63L26 A registrar MAY redirect REGISTER requests as appropriate. One P63L27 common usage would be for a registrar listening on a multicast P63L28 interface to redirect multicast REGISTER requests to its own unicast P63L29 interface with a 302 (Moved Temporarily) response. P63L30 P63L31 Registrars MUST ignore the Record-Route header field if it is P63L32 included in a REGISTER request. Registrars MUST NOT include a P63L33 Record-Route header field in any response to a REGISTER request. P63L34 P63L35 A registrar might receive a request that traversed a proxy which P63L36 treats REGISTER as an unknown request and which added a Record- P63L37 Route header field value. P63L38 P63L39 A registrar has to know (for example, through configuration) the set P63L40 of domain(s) for which it maintains bindings. REGISTER requests MUST P63L41 be processed by a registrar in the order that they are received. P63L42 REGISTER requests MUST also be processed atomically, meaning that a P63L43 particular REGISTER request is either processed completely or not at P63L44 all. Each REGISTER message MUST be processed independently of any P63L45 other registration or binding changes. P63L46 P63L47 P63L48 P64L1 When receiving a REGISTER request, a registrar follows these steps: P64L2 P64L3 1. The registrar inspects the Request-URI to determine whether it P64L4 has access to bindings for the domain identified in the P64L5 Request-URI. If not, and if the server also acts as a proxy P64L6 server, the server SHOULD forward the request to the addressed P64L7 domain, following the general behavior for proxying messages P64L8 described in Section 16. P64L9 P64L10 2. To guarantee that the registrar supports any necessary P64L11 extensions, the registrar MUST process the Require header field P64L12 values as described for UASs in Section 8.2.2. P64L13 P64L14 3. A registrar SHOULD authenticate the UAC. Mechanisms for the P64L15 authentication of SIP user agents are described in Section 22. P64L16 Registration behavior in no way overrides the generic P64L17 authentication framework for SIP. If no authentication P64L18 mechanism is available, the registrar MAY take the From address P64L19 as the asserted identity of the originator of the request. P64L20 P64L21 4. The registrar SHOULD determine if the authenticated user is P64L22 authorized to modify registrations for this address-of-record. P64L23 For example, a registrar might consult an authorization P64L24 database that maps user names to a list of addresses-of-record P64L25 for which that user has authorization to modify bindings. If P64L26 the authenticated user is not authorized to modify bindings, P64L27 the registrar MUST return a 403 (Forbidden) and skip the P64L28 remaining steps. P64L29 P64L30 In architectures that support third-party registration, one P64L31 entity may be responsible for updating the registrations P64L32 associated with multiple addresses-of-record. P64L33 P64L34 5. The registrar extracts the address-of-record from the To header P64L35 field of the request. If the address-of-record is not valid P64L36 for the domain in the Request-URI, the registrar MUST send a P64L37 404 (Not Found) response and skip the remaining steps. The URI P64L38 MUST then be converted to a canonical form. To do that, all P64L39 URI parameters MUST be removed (including the user-param), and P64L40 any escaped characters MUST be converted to their unescaped P64L41 form. The result serves as an index into the list of bindings. P64L42 P64L43 P64L44 P64L45 P64L46 P64L47 P64L48 P65L1 6. The registrar checks whether the request contains the Contact P65L2 header field. If not, it skips to the last step. If the P65L3 Contact header field is present, the registrar checks if there P65L4 is one Contact field value that contains the special value "*" P65L5 and an Expires field. If the request has additional Contact P65L6 fields or an expiration time other than zero, the request is P65L7 invalid, and the server MUST return a 400 (Invalid Request) and P65L8 skip the remaining steps. If not, the registrar checks whether P65L9 the Call-ID agrees with the value stored for each binding. If P65L10 not, it MUST remove the binding. If it does agree, it MUST P65L11 remove the binding only if the CSeq in the request is higher P65L12 than the value stored for that binding. Otherwise, the update P65L13 MUST be aborted and the request fails. P65L14 P65L15 7. The registrar now processes each contact address in the Contact P65L16 header field in turn. For each address, it determines the P65L17 expiration interval as follows: P65L18 P65L19 - If the field value has an "expires" parameter, that value P65L20 MUST be taken as the requested expiration. P65L21 P65L22 - If there is no such parameter, but the request has an P65L23 Expires header field, that value MUST be taken as the P65L24 requested expiration. P65L25 P65L26 - If there is neither, a locally-configured default value MUST P65L27 be taken as the requested expiration. P65L28 P65L29 The registrar MAY choose an expiration less than the requested P65L30 expiration interval. If and only if the requested expiration P65L31 interval is greater than zero AND smaller than one hour AND P65L32 less than a registrar-configured minimum, the registrar MAY P65L33 reject the registration with a response of 423 (Interval Too P65L34 Brief). This response MUST contain a Min-Expires header field P65L35 that states the minimum expiration interval the registrar is P65L36 willing to honor. It then skips the remaining steps. P65L37 P65L38 Allowing the registrar to set the registration interval P65L39 protects it against excessively frequent registration refreshes P65L40 while limiting the state that it needs to maintain and P65L41 decreasing the likelihood of registrations going stale. The P65L42 expiration interval of a registration is frequently used in the P65L43 creation of services. An example is a follow-me service, where P65L44 the user may only be available at a terminal for a brief P65L45 period. Therefore, registrars should accept brief P65L46 registrations; a request should only be rejected if the P65L47 interval is so short that the refreshes would degrade registrar P65L48 performance. P66L1 For each address, the registrar then searches the list of P66L2 current bindings using the URI comparison rules. If the P66L3 binding does not exist, it is tentatively added. If the P66L4 binding does exist, the registrar checks the Call-ID value. If P66L5 the Call-ID value in the existing binding differs from the P66L6 Call-ID value in the request, the binding MUST be removed if P66L7 the expiration time is zero and updated otherwise. If they are P66L8 the same, the registrar compares the CSeq value. If the value P66L9 is higher than that of the existing binding, it MUST update or P66L10 remove the binding as above. If not, the update MUST be P66L11 aborted and the request fails. P66L12 P66L13 This algorithm ensures that out-of-order requests from the same P66L14 UA are ignored. P66L15 P66L16 Each binding record records the Call-ID and CSeq values from P66L17 the request. P66L18 P66L19 The binding updates MUST be committed (that is, made visible to P66L20 the proxy or redirect server) if and only if all binding P66L21 updates and additions succeed. If any one of them fails (for P66L22 example, because the back-end database commit failed), the P66L23 request MUST fail with a 500 (Server Error) response and all P66L24 tentative binding updates MUST be removed. P66L25 P66L26 8. The registrar returns a 200 (OK) response. The response MUST P66L27 contain Contact header field values enumerating all current P66L28 bindings. Each Contact value MUST feature an "expires" P66L29 parameter indicating its expiration interval chosen by the P66L30 registrar. The response SHOULD include a Date header field. P66L31 P66L32 11 Querying for Capabilities P66L33 P66L34 The SIP method OPTIONS allows a UA to query another UA or a proxy P66L35 server as to its capabilities. This allows a client to discover P66L36 information about the supported methods, content types, extensions, P66L37 codecs, etc. without "ringing" the other party. For example, before P66L38 a client inserts a Require header field into an INVITE listing an P66L39 option that it is not certain the destination UAS supports, the P66L40 client can query the destination UAS with an OPTIONS to see if this P66L41 option is returned in a Supported header field. All UAs MUST support P66L42 the OPTIONS method. P66L43 P66L44 The target of the OPTIONS request is identified by the Request-URI, P66L45 which could identify another UA or a SIP server. If the OPTIONS is P66L46 addressed to a proxy server, the Request-URI is set without a user P66L47 part, similar to the way a Request-URI is set for a REGISTER request. P66L48 P67L1 Alternatively, a server receiving an OPTIONS request with a Max- P67L2 Forwards header field value of 0 MAY respond to the request P67L3 regardless of the Request-URI. P67L4 P67L5 This behavior is common with HTTP/1.1. This behavior can be used P67L6 as a "traceroute" functionality to check the capabilities of P67L7 individual hop servers by sending a series of OPTIONS requests P67L8 with incremented Max-Forwards values. P67L9 P67L10 As is the case for general UA behavior, the transaction layer can P67L11 return a timeout error if the OPTIONS yields no response. This may P67L12 indicate that the target is unreachable and hence unavailable. P67L13 P67L14 An OPTIONS request MAY be sent as part of an established dialog to P67L15 query the peer on capabilities that may be utilized later in the P67L16 dialog. P67L17 P67L18 11.1 Construction of OPTIONS Request P67L19 P67L20 An OPTIONS request is constructed using the standard rules for a SIP P67L21 request as discussed in Section 8.1.1. P67L22 P67L23 A Contact header field MAY be present in an OPTIONS. P67L24 P67L25 An Accept header field SHOULD be included to indicate the type of P67L26 message body the UAC wishes to receive in the response. Typically, P67L27 this is set to a format that is used to describe the media P67L28 capabilities of a UA, such as SDP (application/sdp). P67L29 P67L30 The response to an OPTIONS request is assumed to be scoped to the P67L31 Request-URI in the original request. However, only when an OPTIONS P67L32 is sent as part of an established dialog is it guaranteed that future P67L33 requests will be received by the server that generated the OPTIONS P67L34 response. P67L35 P67L36 Example OPTIONS request: P67L37 P67L38 OPTIONS sip:carol@chicago.com SIP/2.0 P67L39 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 P67L40 Max-Forwards: 70 P67L41 To: P67L42 From: Alice ;tag=1928301774 P67L43 Call-ID: a84b4c76e66710 P67L44 CSeq: 63104 OPTIONS P67L45 Contact: P67L46 Accept: application/sdp P67L47 Content-Length: 0 P67L48 P68L1 11.2 Processing of OPTIONS Request P68L2 P68L3 The response to an OPTIONS is constructed using the standard rules P68L4 for a SIP response as discussed in Section 8.2.6. The response code P68L5 chosen MUST be the same that would have been chosen had the request P68L6 been an INVITE. That is, a 200 (OK) would be returned if the UAS is P68L7 ready to accept a call, a 486 (Busy Here) would be returned if the P68L8 UAS is busy, etc. This allows an OPTIONS request to be used to P68L9 determine the basic state of a UAS, which can be an indication of P68L10 whether the UAS will accept an INVITE request. P68L11 P68L12 An OPTIONS request received within a dialog generates a 200 (OK) P68L13 response that is identical to one constructed outside a dialog and P68L14 does not have any impact on the dialog. P68L15 P68L16 This use of OPTIONS has limitations due to the differences in proxy P68L17 handling of OPTIONS and INVITE requests. While a forked INVITE can P68L18 result in multiple 200 (OK) responses being returned, a forked P68L19 OPTIONS will only result in a single 200 (OK) response, since it is P68L20 treated by proxies using the non-INVITE handling. See Section 16.7 P68L21 for the normative details. P68L22 P68L23 If the response to an OPTIONS is generated by a proxy server, the P68L24 proxy returns a 200 (OK), listing the capabilities of the server. P68L25 The response does not contain a message body. P68L26 P68L27 Allow, Accept, Accept-Encoding, Accept-Language, and Supported header P68L28 fields SHOULD be present in a 200 (OK) response to an OPTIONS P68L29 request. If the response is generated by a proxy, the Allow header P68L30 field SHOULD be omitted as it is ambiguous since a proxy is method P68L31 agnostic. Contact header fields MAY be present in a 200 (OK) P68L32 response and have the same semantics as in a 3xx response. That is, P68L33 they may list a set of alternative names and methods of reaching the P68L34 user. A Warning header field MAY be present. P68L35 P68L36 A message body MAY be sent, the type of which is determined by the P68L37 Accept header field in the OPTIONS request (application/sdp is the P68L38 default if the Accept header field is not present). If the types P68L39 include one that can describe media capabilities, the UAS SHOULD P68L40 include a body in the response for that purpose. Details on the P68L41 construction of such a body in the case of application/sdp are P68L42 described in [13]. P68L43 P68L44 P68L45 P68L46 P68L47 P68L48 P69L1 Example OPTIONS response generated by a UAS (corresponding to the P69L2 request in Section 11.1): P69L3 P69L4 SIP/2.0 200 OK P69L5 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 P69L6 ;received=192.0.2.4 P69L7 To: ;tag=93810874 P69L8 From: Alice ;tag=1928301774 P69L9 Call-ID: a84b4c76e66710 P69L10 CSeq: 63104 OPTIONS P69L11 Contact: P69L12 Contact: P69L13 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE P69L14 Accept: application/sdp P69L15 Accept-Encoding: gzip P69L16 Accept-Language: en P69L17 Supported: foo P69L18 Content-Type: application/sdp P69L19 Content-Length: 274 P69L20 P69L21 (SDP not shown) P69L22 P69L23 12 Dialogs P69L24 P69L25 A key concept for a user agent is that of a dialog. A dialog P69L26 represents a peer-to-peer SIP relationship between two user agents P69L27 that persists for some time. The dialog facilitates sequencing of P69L28 messages between the user agents and proper routing of requests P69L29 between both of them. The dialog represents a context in which to P69L30 interpret SIP messages. Section 8 discussed method independent UA P69L31 processing for requests and responses outside of a dialog. This P69L32 section discusses how those requests and responses are used to P69L33 construct a dialog, and then how subsequent requests and responses P69L34 are sent within a dialog. P69L35 P69L36 A dialog is identified at each UA with a dialog ID, which consists of P69L37 a Call-ID value, a local tag and a remote tag. The dialog ID at each P69L38 UA involved in the dialog is not the same. Specifically, the local P69L39 tag at one UA is identical to the remote tag at the peer UA. The P69L40 tags are opaque tokens that facilitate the generation of unique P69L41 dialog IDs. P69L42 P69L43 A dialog ID is also associated with all responses and with any P69L44 request that contains a tag in the To field. The rules for computing P69L45 the dialog ID of a message depend on whether the SIP element is a UAC P69L46 or UAS. For a UAC, the Call-ID value of the dialog ID is set to the P69L47 Call-ID of the message, the remote tag is set to the tag in the To P69L48 field of the message, and the local tag is set to the tag in the From P70L1 field of the message (these rules apply to both requests and P70L2 responses). As one would expect for a UAS, the Call-ID value of the P70L3 dialog ID is set to the Call-ID of the message, the remote tag is set P70L4 to the tag in the From field of the message, and the local tag is set P70L5 to the tag in the To field of the message. P70L6 P70L7 A dialog contains certain pieces of state needed for further message P70L8 transmissions within the dialog. This state consists of the dialog P70L9 ID, a local sequence number (used to order requests from the UA to P70L10 its peer), a remote sequence number (used to order requests from its P70L11 peer to the UA), a local URI, a remote URI, remote target, a boolean P70L12 flag called "secure", and a route set, which is an ordered list of P70L13 URIs. The route set is the list of servers that need to be traversed P70L14 to send a request to the peer. A dialog can also be in the "early" P70L15 state, which occurs when it is created with a provisional response, P70L16 and then transition to the "confirmed" state when a 2xx final P70L17 response arrives. For other responses, or if no response arrives at P70L18 all on that dialog, the early dialog terminates. P70L19 P70L20 12.1 Creation of a Dialog P70L21 P70L22 Dialogs are created through the generation of non-failure responses P70L23 to requests with specific methods. Within this specification, only P70L24 2xx and 101-199 responses with a To tag, where the request was P70L25 INVITE, will establish a dialog. A dialog established by a non-final P70L26 response to a request is in the "early" state and it is called an P70L27 early dialog. Extensions MAY define other means for creating P70L28 dialogs. Section 13 gives more details that are specific to the P70L29 INVITE method. Here, we describe the process for creation of dialog P70L30 state that is not dependent on the method. P70L31 P70L32 UAs MUST assign values to the dialog ID components as described P70L33 below. P70L34 P70L35 12.1.1 UAS behavior P70L36 P70L37 When a UAS responds to a request with a response that establishes a P70L38 dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route P70L39 header field values from the request into the response (including the P70L40 URIs, URI parameters, and any Record-Route header field parameters, P70L41 whether they are known or unknown to the UAS) and MUST maintain the P70L42 order of those values. The UAS MUST add a Contact header field to P70L43 the response. The Contact header field contains an address where the P70L44 UAS would like to be contacted for subsequent requests in the dialog P70L45 (which includes the ACK for a 2xx response in the case of an INVITE). P70L46 Generally, the host portion of this URI is the IP address or FQDN of P70L47 the host. The URI provided in the Contact header field MUST be a SIP P70L48 or SIPS URI. If the request that initiated the dialog contained a P71L1 SIPS URI in the Request-URI or in the top Record-Route header field P71L2 value, if there was any, or the Contact header field if there was no P71L3 Record-Route header field, the Contact header field in the response P71L4 MUST be a SIPS URI. The URI SHOULD have global scope (that is, the P71L5 same URI can be used in messages outside this dialog). The same way, P71L6 the scope of the URI in the Contact header field of the INVITE is not P71L7 limited to this dialog either. It can therefore be used in messages P71L8 to the UAC even outside this dialog. P71L9 P71L10 The UAS then constructs the state of the dialog. This state MUST be P71L11 maintained for the duration of the dialog. P71L12 P71L13 If the request arrived over TLS, and the Request-URI contained a SIPS P71L14 URI, the "secure" flag is set to TRUE. P71L15 P71L16 The route set MUST be set to the list of URIs in the Record-Route P71L17 header field from the request, taken in order and preserving all URI P71L18 parameters. If no Record-Route header field is present in the P71L19 request, the route set MUST be set to the empty set. This route set, P71L20 even if empty, overrides any pre-existing route set for future P71L21 requests in this dialog. The remote target MUST be set to the URI P71L22 from the Contact header field of the request. P71L23 P71L24 The remote sequence number MUST be set to the value of the sequence P71L25 number in the CSeq header field of the request. The local sequence P71L26 number MUST be empty. The call identifier component of the dialog ID P71L27 MUST be set to the value of the Call-ID in the request. The local P71L28 tag component of the dialog ID MUST be set to the tag in the To field P71L29 in the response to the request (which always includes a tag), and the P71L30 remote tag component of the dialog ID MUST be set to the tag from the P71L31 From field in the request. A UAS MUST be prepared to receive a P71L32 request without a tag in the From field, in which case the tag is P71L33 considered to have a value of null. P71L34 P71L35 This is to maintain backwards compatibility with RFC 2543, which P71L36 did not mandate From tags. P71L37 P71L38 The remote URI MUST be set to the URI in the From field, and the P71L39 local URI MUST be set to the URI in the To field. P71L40 P71L41 12.1.2 UAC Behavior P71L42 P71L43 When a UAC sends a request that can establish a dialog (such as an P71L44 INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., P71L45 the same SIP URI can be used in messages outside this dialog) in the P71L46 Contact header field of the request. If the request has a Request- P71L47 URI or a topmost Route header field value with a SIPS URI, the P71L48 Contact header field MUST contain a SIPS URI. P72L1 When a UAC receives a response that establishes a dialog, it P72L2 constructs the state of the dialog. This state MUST be maintained P72L3 for the duration of the dialog. P72L4 P72L5 If the request was sent over TLS, and the Request-URI contained a P72L6 SIPS URI, the "secure" flag is set to TRUE. P72L7 P72L8 The route set MUST be set to the list of URIs in the Record-Route P72L9 header field from the response, taken in reverse order and preserving P72L10 all URI parameters. If no Record-Route header field is present in P72L11 the response, the route set MUST be set to the empty set. This route P72L12 set, even if empty, overrides any pre-existing route set for future P72L13 requests in this dialog. The remote target MUST be set to the URI P72L14 from the Contact header field of the response. P72L15 P72L16 The local sequence number MUST be set to the value of the sequence P72L17 number in the CSeq header field of the request. The remote sequence P72L18 number MUST be empty (it is established when the remote UA sends a P72L19 request within the dialog). The call identifier component of the P72L20 dialog ID MUST be set to the value of the Call-ID in the request. P72L21 The local tag component of the dialog ID MUST be set to the tag in P72L22 the From field in the request, and the remote tag component of the P72L23 dialog ID MUST be set to the tag in the To field of the response. A P72L24 UAC MUST be prepared to receive a response without a tag in the To P72L25 field, in which case the tag is considered to have a value of null. P72L26 P72L27 This is to maintain backwards compatibility with RFC 2543, which P72L28 did not mandate To tags. P72L29 P72L30 The remote URI MUST be set to the URI in the To field, and the local P72L31 URI MUST be set to the URI in the From field. P72L32 P72L33 12.2 Requests within a Dialog P72L34 P72L35 Once a dialog has been established between two UAs, either of them P72L36 MAY initiate new transactions as needed within the dialog. The UA P72L37 sending the request will take the UAC role for the transaction. The P72L38 UA receiving the request will take the UAS role. Note that these may P72L39 be different roles than the UAs held during the transaction that P72L40 established the dialog. P72L41 P72L42 Requests within a dialog MAY contain Record-Route and Contact header P72L43 fields. However, these requests do not cause the dialog's route set P72L44 to be modified, although they may modify the remote target URI. P72L45 Specifically, requests that are not target refresh requests do not P72L46 modify the dialog's remote target URI, and requests that are target P72L47 refresh requests do. For dialogs that have been established with an P72L48 P73L1 INVITE, the only target refresh request defined is re-INVITE (see P73L2 Section 14). Other extensions may define different target refresh P73L3 requests for dialogs established in other ways. P73L4 P73L5 Note that an ACK is NOT a target refresh request. P73L6 P73L7 Target refresh requests only update the dialog's remote target URI, P73L8 and not the route set formed from the Record-Route. Updating the P73L9 latter would introduce severe backwards compatibility problems with P73L10 RFC 2543-compliant systems. P73L11 P73L12 12.2.1 UAC Behavior P73L13 P73L14 12.2.1.1 Generating the Request P73L15 P73L16 A request within a dialog is constructed by using many of the P73L17 components of the state stored as part of the dialog. P73L18 P73L19 The URI in the To field of the request MUST be set to the remote URI P73L20 from the dialog state. The tag in the To header field of the request P73L21 MUST be set to the remote tag of the dialog ID. The From URI of the P73L22 request MUST be set to the local URI from the dialog state. The tag P73L23 in the From header field of the request MUST be set to the local tag P73L24 of the dialog ID. If the value of the remote or local tags is null, P73L25 the tag parameter MUST be omitted from the To or From header fields, P73L26 respectively. P73L27 P73L28 Usage of the URI from the To and From fields in the original P73L29 request within subsequent requests is done for backwards P73L30 compatibility with RFC 2543, which used the URI for dialog P73L31 identification. In this specification, only the tags are used for P73L32 dialog identification. It is expected that mandatory reflection P73L33 of the original To and From URI in mid-dialog requests will be P73L34 deprecated in a subsequent revision of this specification. P73L35 P73L36 The Call-ID of the request MUST be set to the Call-ID of the dialog. P73L37 Requests within a dialog MUST contain strictly monotonically P73L38 increasing and contiguous CSeq sequence numbers (increasing-by-one) P73L39 in each direction (excepting ACK and CANCEL of course, whose numbers P73L40 equal the requests being acknowledged or cancelled). Therefore, if P73L41 the local sequence number is not empty, the value of the local P73L42 sequence number MUST be incremented by one, and this value MUST be P73L43 placed into the CSeq header field. If the local sequence number is P73L44 empty, an initial value MUST be chosen using the guidelines of P73L45 Section 8.1.1.5. The method field in the CSeq header field value P73L46 MUST match the method of the request. P73L47 P73L48 P74L1 With a length of 32 bits, a client could generate, within a single P74L2 call, one request a second for about 136 years before needing to P74L3 wrap around. The initial value of the sequence number is chosen P74L4 so that subsequent requests within the same call will not wrap P74L5 around. A non-zero initial value allows clients to use a time- P74L6 based initial sequence number. A client could, for example, P74L7 choose the 31 most significant bits of a 32-bit second clock as an P74L8 initial sequence number. P74L9 P74L10 The UAC uses the remote target and route set to build the Request-URI P74L11 and Route header field of the request. P74L12 P74L13 If the route set is empty, the UAC MUST place the remote target URI P74L14 into the Request-URI. The UAC MUST NOT add a Route header field to P74L15 the request. P74L16 P74L17 If the route set is not empty, and the first URI in the route set P74L18 contains the lr parameter (see Section 19.1.1), the UAC MUST place P74L19 the remote target URI into the Request-URI and MUST include a Route P74L20 header field containing the route set values in order, including all P74L21 parameters. P74L22 P74L23 If the route set is not empty, and its first URI does not contain the P74L24 lr parameter, the UAC MUST place the first URI from the route set P74L25 into the Request-URI, stripping any parameters that are not allowed P74L26 in a Request-URI. The UAC MUST add a Route header field containing P74L27 the remainder of the route set values in order, including all P74L28 parameters. The UAC MUST then place the remote target URI into the P74L29 Route header field as the last value. P74L30 P74L31 For example, if the remote target is sip:user@remoteua and the route P74L32 set contains: P74L33 P74L34 ,,, P74L35 P74L36 The request will be formed with the following Request-URI and Route P74L37 header field: P74L38 P74L39 METHOD sip:proxy1 P74L40 Route: ,,, P74L41 P74L42 If the first URI of the route set does not contain the lr P74L43 parameter, the proxy indicated does not understand the routing P74L44 mechanisms described in this document and will act as specified in P74L45 RFC 2543, replacing the Request-URI with the first Route header P74L46 field value it receives while forwarding the message. Placing the P74L47 Request-URI at the end of the Route header field preserves the P74L48 P75L1 information in that Request-URI across the strict router (it will P75L2 be returned to the Request-URI when the request reaches a loose- P75L3 router). P75L4 P75L5 A UAC SHOULD include a Contact header field in any target refresh P75L6 requests within a dialog, and unless there is a need to change it, P75L7 the URI SHOULD be the same as used in previous requests within the P75L8 dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. P75L9 As discussed in Section 12.2.2, a Contact header field in a target P75L10 refresh request updates the remote target URI. This allows a UA to P75L11 provide a new contact address, should its address change during the P75L12 duration of the dialog. P75L13 P75L14 However, requests that are not target refresh requests do not affect P75L15 the remote target URI for the dialog. P75L16 P75L17 The rest of the request is formed as described in Section 8.1.1. P75L18 P75L19 Once the request has been constructed, the address of the server is P75L20 computed and the request is sent, using the same procedures for P75L21 requests outside of a dialog (Section 8.1.2). P75L22 P75L23 The procedures in Section 8.1.2 will normally result in the P75L24 request being sent to the address indicated by the topmost Route P75L25 header field value or the Request-URI if no Route header field is P75L26 present. Subject to certain restrictions, they allow the request P75L27 to be sent to an alternate address (such as a default outbound P75L28 proxy not represented in the route set). P75L29 P75L30 12.2.1.2 Processing the Responses P75L31 P75L32 The UAC will receive responses to the request from the transaction P75L33 layer. If the client transaction returns a timeout, this is treated P75L34 as a 408 (Request Timeout) response. P75L35 P75L36 The behavior of a UAC that receives a 3xx response for a request sent P75L37 within a dialog is the same as if the request had been sent outside a P75L38 dialog. This behavior is described in Section 8.1.3.4. P75L39 P75L40 Note, however, that when the UAC tries alternative locations, it P75L41 still uses the route set for the dialog to build the Route header P75L42 of the request. P75L43 P75L44 When a UAC receives a 2xx response to a target refresh request, it P75L45 MUST replace the dialog's remote target URI with the URI from the P75L46 Contact header field in that response, if present. P75L47 P75L48 P76L1 If the response for a request within a dialog is a 481 P76L2 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC P76L3 SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if P76L4 no response at all is received for the request (the client P76L5 transaction would inform the TU about the timeout.) P76L6 P76L7 For INVITE initiated dialogs, terminating the dialog consists of P76L8 sending a BYE. P76L9 P76L10 12.2.2 UAS Behavior P76L11 P76L12 Requests sent within a dialog, as any other requests, are atomic. If P76L13 a particular request is accepted by the UAS, all the state changes P76L14 associated with it are performed. If the request is rejected, none P76L15 of the state changes are performed. P76L16 P76L17 Note that some requests, such as INVITEs, affect several pieces of P76L18 state. P76L19 P76L20 The UAS will receive the request from the transaction layer. If the P76L21 request has a tag in the To header field, the UAS core computes the P76L22 dialog identifier corresponding to the request and compares it with P76L23 existing dialogs. If there is a match, this is a mid-dialog request. P76L24 In that case, the UAS first applies the same processing rules for P76L25 requests outside of a dialog, discussed in Section 8.2. P76L26 P76L27 If the request has a tag in the To header field, but the dialog P76L28 identifier does not match any existing dialogs, the UAS may have P76L29 crashed and restarted, or it may have received a request for a P76L30 different (possibly failed) UAS (the UASs can construct the To tags P76L31 so that a UAS can identify that the tag was for a UAS for which it is P76L32 providing recovery). Another possibility is that the incoming P76L33 request has been simply misrouted. Based on the To tag, the UAS MAY P76L34 either accept or reject the request. Accepting the request for P76L35 acceptable To tags provides robustness, so that dialogs can persist P76L36 even through crashes. UAs wishing to support this capability must P76L37 take into consideration some issues such as choosing monotonically P76L38 increasing CSeq sequence numbers even across reboots, reconstructing P76L39 the route set, and accepting out-of-range RTP timestamps and sequence P76L40 numbers. P76L41 P76L42 If the UAS wishes to reject the request because it does not wish to P76L43 recreate the dialog, it MUST respond to the request with a 481 P76L44 (Call/Transaction Does Not Exist) status code and pass that to the P76L45 server transaction. P76L46 P76L47 P76L48 P77L1 Requests that do not change in any way the state of a dialog may be P77L2 received within a dialog (for example, an OPTIONS request). They are P77L3 processed as if they had been received outside the dialog. P77L4 P77L5 If the remote sequence number is empty, it MUST be set to the value P77L6 of the sequence number in the CSeq header field value in the request. P77L7 If the remote sequence number was not empty, but the sequence number P77L8 of the request is lower than the remote sequence number, the request P77L9 is out of order and MUST be rejected with a 500 (Server Internal P77L10 Error) response. If the remote sequence number was not empty, and P77L11 the sequence number of the request is greater than the remote P77L12 sequence number, the request is in order. It is possible for the P77L13 CSeq sequence number to be higher than the remote sequence number by P77L14 more than one. This is not an error condition, and a UAS SHOULD be P77L15 prepared to receive and process requests with CSeq values more than P77L16 one higher than the previous received request. The UAS MUST then set P77L17 the remote sequence number to the value of the sequence number in the P77L18 CSeq header field value in the request. P77L19 P77L20 If a proxy challenges a request generated by the UAC, the UAC has P77L21 to resubmit the request with credentials. The resubmitted request P77L22 will have a new CSeq number. The UAS will never see the first P77L23 request, and thus, it will notice a gap in the CSeq number space. P77L24 Such a gap does not represent any error condition. P77L25 P77L26 When a UAS receives a target refresh request, it MUST replace the P77L27 dialog's remote target URI with the URI from the Contact header field P77L28 in that request, if present. P77L29 P77L30 12.3 Termination of a Dialog P77L31 P77L32 Independent of the method, if a request outside of a dialog generates P77L33 a non-2xx final response, any early dialogs created through P77L34 provisional responses to that request are terminated. The mechanism P77L35 for terminating confirmed dialogs is method specific. In this P77L36 specification, the BYE method terminates a session and the dialog P77L37 associated with it. See Section 15 for details. P77L38 P77L39 13 Initiating a Session P77L40 P77L41 13.1 Overview P77L42 P77L43 When a user agent client desires to initiate a session (for example, P77L44 audio, video, or a game), it formulates an INVITE request. The P77L45 INVITE request asks a server to establish a session. This request P77L46 may be forwarded by proxies, eventually arriving at one or more UAS P77L47 that can potentially accept the invitation. These UASs will P77L48 frequently need to query the user about whether to accept the P78L1 invitation. After some time, those UASs can accept the invitation P78L2 (meaning the session is to be established) by sending a 2xx response. P78L3 If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is P78L4 sent, depending on the reason for the rejection. Before sending a P78L5 final response, the UAS can also send provisional responses (1xx) to P78L6 advise the UAC of progress in contacting the called user. P78L7 P78L8 After possibly receiving one or more provisional responses, the UAC P78L9 will get one or more 2xx responses or one non-2xx final response. P78L10 Because of the protracted amount of time it can take to receive final P78L11 responses to INVITE, the reliability mechanisms for INVITE P78L12 transactions differ from those of other requests (like OPTIONS). P78L13 Once it receives a final response, the UAC needs to send an ACK for P78L14 every final response it receives. The procedure for sending this ACK P78L15 depends on the type of response. For final responses between 300 and P78L16 699, the ACK processing is done in the transaction layer and follows P78L17 one set of rules (See Section 17). For 2xx responses, the ACK is P78L18 generated by the UAC core. P78L19 P78L20 A 2xx response to an INVITE establishes a session, and it also P78L21 creates a dialog between the UA that issued the INVITE and the UA P78L22 that generated the 2xx response. Therefore, when multiple 2xx P78L23 responses are received from different remote UAs (because the INVITE P78L24 forked), each 2xx establishes a different dialog. All these dialogs P78L25 are part of the same call. P78L26 P78L27 This section provides details on the establishment of a session using P78L28 INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and P78L29 BYE. P78L30 P78L31 13.2 UAC Processing P78L32 P78L33 13.2.1 Creating the Initial INVITE P78L34 P78L35 Since the initial INVITE represents a request outside of a dialog, P78L36 its construction follows the procedures of Section 8.1.1. Additional P78L37 processing is required for the specific case of INVITE. P78L38 P78L39 An Allow header field (Section 20.5) SHOULD be present in the INVITE. P78L40 It indicates what methods can be invoked within a dialog, on the UA P78L41 sending the INVITE, for the duration of the dialog. For example, a P78L42 UA capable of receiving INFO requests within a dialog [34] SHOULD P78L43 include an Allow header field listing the INFO method. P78L44 P78L45 A Supported header field (Section 20.37) SHOULD be present in the P78L46 INVITE. It enumerates all the extensions understood by the UAC. P78L47 P78L48 P79L1 An Accept (Section 20.1) header field MAY be present in the INVITE. P79L2 It indicates which Content-Types are acceptable to the UA, in both P79L3 the response received by it, and in any subsequent requests sent to P79L4 it within dialogs established by the INVITE. The Accept header field P79L5 is especially useful for indicating support of various session P79L6 description formats. P79L7 P79L8 The UAC MAY add an Expires header field (Section 20.19) to limit the P79L9 validity of the invitation. If the time indicated in the Expires P79L10 header field is reached and no final answer for the INVITE has been P79L11 received, the UAC core SHOULD generate a CANCEL request for the P79L12 INVITE, as per Section 9. P79L13 P79L14 A UAC MAY also find it useful to add, among others, Subject (Section P79L15 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) P79L16 header fields. They all contain information related to the INVITE. P79L17 P79L18 The UAC MAY choose to add a message body to the INVITE. Section P79L19 8.1.1.10 deals with how to construct the header fields -- Content- P79L20 Type among others -- needed to describe the message body. P79L21 P79L22 There are special rules for message bodies that contain a session P79L23 description - their corresponding Content-Disposition is "session". P79L24 SIP uses an offer/answer model where one UA sends a session P79L25 description, called the offer, which contains a proposed description P79L26 of the session. The offer indicates the desired communications means P79L27 (audio, video, games), parameters of those means (such as codec P79L28 types) and addresses for receiving media from the answerer. The P79L29 other UA responds with another session description, called the P79L30 answer, which indicates which communications means are accepted, the P79L31 parameters that apply to those means, and addresses for receiving P79L32 media from the offerer. An offer/answer exchange is within the P79L33 context of a dialog, so that if a SIP INVITE results in multiple P79L34 dialogs, each is a separate offer/answer exchange. The offer/answer P79L35 model defines restrictions on when offers and answers can be made P79L36 (for example, you cannot make a new offer while one is in progress). P79L37 This results in restrictions on where the offers and answers can P79L38 appear in SIP messages. In this specification, offers and answers P79L39 can only appear in INVITE requests and responses, and ACK. The usage P79L40 of offers and answers is further restricted. For the initial INVITE P79L41 transaction, the rules are: P79L42 P79L43 o The initial offer MUST be in either an INVITE or, if not there, P79L44 in the first reliable non-failure message from the UAS back to P79L45 the UAC. In this specification, that is the final 2xx P79L46 response. P79L47 P79L48 P80L1 o If the initial offer is in an INVITE, the answer MUST be in a P80L2 reliable non-failure message from UAS back to UAC which is P80L3 correlated to that INVITE. For this specification, that is P80L4 only the final 2xx response to that INVITE. That same exact P80L5 answer MAY also be placed in any provisional responses sent P80L6 prior to the answer. The UAC MUST treat the first session P80L7 description it receives as the answer, and MUST ignore any P80L8 session descriptions in subsequent responses to the initial P80L9 INVITE. P80L10 P80L11 o If the initial offer is in the first reliable non-failure P80L12 message from the UAS back to UAC, the answer MUST be in the P80L13 acknowledgement for that message (in this specification, ACK P80L14 for a 2xx response). P80L15 P80L16 o After having sent or received an answer to the first offer, the P80L17 UAC MAY generate subsequent offers in requests based on rules P80L18 specified for that method, but only if it has received answers P80L19 to any previous offers, and has not sent any offers to which it P80L20 hasn't gotten an answer. P80L21 P80L22 o Once the UAS has sent or received an answer to the initial P80L23 offer, it MUST NOT generate subsequent offers in any responses P80L24 to the initial INVITE. This means that a UAS based on this P80L25 specification alone can never generate subsequent offers until P80L26 completion of the initial transaction. P80L27 P80L28 Concretely, the above rules specify two exchanges for UAs compliant P80L29 to this specification alone - the offer is in the INVITE, and the P80L30 answer in the 2xx (and possibly in a 1xx as well, with the same P80L31 value), or the offer is in the 2xx, and the answer is in the ACK. P80L32 All user agents that support INVITE MUST support these two exchanges. P80L33 P80L34 The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be P80L35 supported by all user agents as a means to describe sessions, and its P80L36 usage for constructing offers and answers MUST follow the procedures P80L37 defined in [13]. P80L38 P80L39 The restrictions of the offer-answer model just described only apply P80L40 to bodies whose Content-Disposition header field value is "session". P80L41 Therefore, it is possible that both the INVITE and the ACK contain a P80L42 body message (for example, the INVITE carries a photo (Content- P80L43 Disposition: render) and the ACK a session description (Content- P80L44 Disposition: session)). P80L45 P80L46 If the Content-Disposition header field is missing, bodies of P80L47 Content-Type application/sdp imply the disposition "session", while P80L48 other content types imply "render". P81L1 Once the INVITE has been created, the UAC follows the procedures P81L2 defined for sending requests outside of a dialog (Section 8). This P81L3 results in the construction of a client transaction that will P81L4 ultimately send the request and deliver responses to the UAC. P81L5 P81L6 13.2.2 Processing INVITE Responses P81L7 P81L8 Once the INVITE has been passed to the INVITE client transaction, the P81L9 UAC waits for responses for the INVITE. If the INVITE client P81L10 transaction returns a timeout rather than a response the TU acts as P81L11 if a 408 (Request Timeout) response had been received, as described P81L12 in Section 8.1.3. P81L13 P81L14 13.2.2.1 1xx Responses P81L15 P81L16 Zero, one or multiple provisional responses may arrive before one or P81L17 more final responses are received. Provisional responses for an P81L18 INVITE request can create "early dialogs". If a provisional response P81L19 has a tag in the To field, and if the dialog ID of the response does P81L20 not match an existing dialog, one is constructed using the procedures P81L21 defined in Section 12.1.2. P81L22 P81L23 The early dialog will only be needed if the UAC needs to send a P81L24 request to its peer within the dialog before the initial INVITE P81L25 transaction completes. Header fields present in a provisional P81L26 response are applicable as long as the dialog is in the early state P81L27 (for example, an Allow header field in a provisional response P81L28 contains the methods that can be used in the dialog while this is in P81L29 the early state). P81L30 P81L31 13.2.2.2 3xx Responses P81L32 P81L33 A 3xx response may contain one or more Contact header field values P81L34 providing new addresses where the callee might be reachable. P81L35 Depending on the status code of the 3xx response (see Section 21.3), P81L36 the UAC MAY choose to try those new addresses. P81L37 P81L38 13.2.2.3 4xx, 5xx and 6xx Responses P81L39 P81L40 A single non-2xx final response may be received for the INVITE. 4xx, P81L41 5xx and 6xx responses may contain a Contact header field value P81L42 indicating the location where additional information about the error P81L43 can be found. Subsequent final responses (which would only arrive P81L44 under error conditions) MUST be ignored. P81L45 P81L46 All early dialogs are considered terminated upon reception of the P81L47 non-2xx final response. P81L48 P82L1 After having received the non-2xx final response the UAC core P82L2 considers the INVITE transaction completed. The INVITE client P82L3 transaction handles the generation of ACKs for the response (see P82L4 Section 17). P82L5 P82L6 13.2.2.4 2xx Responses P82L7 P82L8 Multiple 2xx responses may arrive at the UAC for a single INVITE P82L9 request due to a forking proxy. Each response is distinguished by P82L10 the tag parameter in the To header field, and each represents a P82L11 distinct dialog, with a distinct dialog identifier. P82L12 P82L13 If the dialog identifier in the 2xx response matches the dialog P82L14 identifier of an existing dialog, the dialog MUST be transitioned to P82L15 the "confirmed" state, and the route set for the dialog MUST be P82L16 recomputed based on the 2xx response using the procedures of Section P82L17 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be P82L18 constructed using the procedures of Section 12.1.2. P82L19 P82L20 Note that the only piece of state that is recomputed is the route P82L21 set. Other pieces of state such as the highest sequence numbers P82L22 (remote and local) sent within the dialog are not recomputed. The P82L23 route set only is recomputed for backwards compatibility. RFC P82L24 2543 did not mandate mirroring of the Record-Route header field in P82L25 a 1xx, only 2xx. However, we cannot update the entire state of P82L26 the dialog, since mid-dialog requests may have been sent within P82L27 the early dialog, modifying the sequence numbers, for example. P82L28 P82L29 The UAC core MUST generate an ACK request for each 2xx received from P82L30 the transaction layer. The header fields of the ACK are constructed P82L31 in the same way as for any request sent within a dialog (see Section P82L32 12) with the exception of the CSeq and the header fields related to P82L33 authentication. The sequence number of the CSeq header field MUST be P82L34 the same as the INVITE being acknowledged, but the CSeq method MUST P82L35 be ACK. The ACK MUST contain the same credentials as the INVITE. If P82L36 the 2xx contains an offer (based on the rules above), the ACK MUST P82L37 carry an answer in its body. If the offer in the 2xx response is not P82L38 acceptable, the UAC core MUST generate a valid answer in the ACK and P82L39 then send a BYE immediately. P82L40 P82L41 Once the ACK has been constructed, the procedures of [4] are used to P82L42 determine the destination address, port and transport. However, the P82L43 request is passed to the transport layer directly for transmission, P82L44 rather than a client transaction. This is because the UAC core P82L45 handles retransmissions of the ACK, not the transaction layer. The P82L46 ACK MUST be passed to the client transport every time a P82L47 retransmission of the 2xx final response that triggered the ACK P82L48 arrives. P83L1 The UAC core considers the INVITE transaction completed 64*T1 seconds P83L2 after the reception of the first 2xx response. At this point all the P83L3 early dialogs that have not transitioned to established dialogs are P83L4 terminated. Once the INVITE transaction is considered completed by P83L5 the UAC core, no more new 2xx responses are expected to arrive. P83L6 P83L7 If, after acknowledging any 2xx response to an INVITE, the UAC does P83L8 not want to continue with that dialog, then the UAC MUST terminate P83L9 the dialog by sending a BYE request as described in Section 15. P83L10 P83L11 13.3 UAS Processing P83L12 P83L13 13.3.1 Processing of the INVITE P83L14 P83L15 The UAS core will receive INVITE requests from the transaction layer. P83L16 It first performs the request processing procedures of Section 8.2, P83L17 which are applied for both requests inside and outside of a dialog. P83L18 P83L19 Assuming these processing states are completed without generating a P83L20 response, the UAS core performs the additional processing steps: P83L21 P83L22 1. If the request is an INVITE that contains an Expires header P83L23 field, the UAS core sets a timer for the number of seconds P83L24 indicated in the header field value. When the timer fires, the P83L25 invitation is considered to be expired. If the invitation P83L26 expires before the UAS has generated a final response, a 487 P83L27 (Request Terminated) response SHOULD be generated. P83L28 P83L29 2. If the request is a mid-dialog request, the method-independent P83L30 processing described in Section 12.2.2 is first applied. It P83L31 might also modify the session; Section 14 provides details. P83L32 P83L33 3. If the request has a tag in the To header field but the dialog P83L34 identifier does not match any of the existing dialogs, the UAS P83L35 may have crashed and restarted, or may have received a request P83L36 for a different (possibly failed) UAS. Section 12.2.2 provides P83L37 guidelines to achieve a robust behavior under such a situation. P83L38 P83L39 Processing from here forward assumes that the INVITE is outside of a P83L40 dialog, and is thus for the purposes of establishing a new session. P83L41 P83L42 The INVITE may contain a session description, in which case the UAS P83L43 is being presented with an offer for that session. It is possible P83L44 that the user is already a participant in that session, even though P83L45 the INVITE is outside of a dialog. This can happen when a user is P83L46 invited to the same multicast conference by multiple other P83L47 participants. If desired, the UAS MAY use identifiers within the P83L48 session description to detect this duplication. For example, SDP P84L1 contains a session id and version number in the origin (o) field. If P84L2 the user is already a member of the session, and the session P84L3 parameters contained in the session description have not changed, the P84L4 UAS MAY silently accept the INVITE (that is, send a 2xx response P84L5 without prompting the user). P84L6 P84L7 If the INVITE does not contain a session description, the UAS is P84L8 being asked to participate in a session, and the UAC has asked that P84L9 the UAS provide the offer of the session. It MUST provide the offer P84L10 in its first non-failure reliable message back to the UAC. In this P84L11 specification, that is a 2xx response to the INVITE. P84L12 P84L13 The UAS can indicate progress, accept, redirect, or reject the P84L14 invitation. In all of these cases, it formulates a response using P84L15 the procedures described in Section 8.2.6. P84L16 P84L17 13.3.1.1 Progress P84L18 P84L19 If the UAS is not able to answer the invitation immediately, it can P84L20 choose to indicate some kind of progress to the UAC (for example, an P84L21 indication that a phone is ringing). This is accomplished with a P84L22 provisional response between 101 and 199. These provisional P84L23 responses establish early dialogs and therefore follow the procedures P84L24 of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY P84L25 send as many provisional responses as it likes. Each of these MUST P84L26 indicate the same dialog ID. However, these will not be delivered P84L27 reliably. P84L28 P84L29 If the UAS desires an extended period of time to answer the INVITE, P84L30 it will need to ask for an "extension" in order to prevent proxies P84L31 from canceling the transaction. A proxy has the option of canceling P84L32 a transaction when there is a gap of 3 minutes between responses in a P84L33 transaction. To prevent cancellation, the UAS MUST send a non-100 P84L34 provisional response at every minute, to handle the possibility of P84L35 lost provisional responses. P84L36 P84L37 An INVITE transaction can go on for extended durations when the P84L38 user is placed on hold, or when interworking with PSTN systems P84L39 which allow communications to take place without answering the P84L40 call. The latter is common in Interactive Voice Response (IVR) P84L41 systems. P84L42 P84L43 13.3.1.2 The INVITE is Redirected P84L44 P84L45 If the UAS decides to redirect the call, a 3xx response is sent. A P84L46 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved P84L47 Temporarily) response SHOULD contain a Contact header field P84L48 P85L1 containing one or more URIs of new addresses to be tried. The P85L2 response is passed to the INVITE server transaction, which will deal P85L3 with its retransmissions. P85L4 P85L5 13.3.1.3 The INVITE is Rejected P85L6 P85L7 A common scenario occurs when the callee is currently not willing or P85L8 able to take additional calls at this end system. A 486 (Busy Here) P85L9 SHOULD be returned in such a scenario. If the UAS knows that no P85L10 other end system will be able to accept this call, a 600 (Busy P85L11 Everywhere) response SHOULD be sent instead. However, it is unlikely P85L12 that a UAS will be able to know this in general, and thus this P85L13 response will not usually be used. The response is passed to the P85L14 INVITE server transaction, which will deal with its retransmissions. P85L15 P85L16 A UAS rejecting an offer contained in an INVITE SHOULD return a 488 P85L17 (Not Acceptable Here) response. Such a response SHOULD include a P85L18 Warning header field value explaining why the offer was rejected. P85L19 P85L20 13.3.1.4 The INVITE is Accepted P85L21 P85L22 The UAS core generates a 2xx response. This response establishes a P85L23 dialog, and therefore follows the procedures of Section 12.1.1 in P85L24 addition to those of Section 8.2.6. P85L25 P85L26 A 2xx response to an INVITE SHOULD contain the Allow header field and P85L27 the Supported header field, and MAY contain the Accept header field. P85L28 Including these header fields allows the UAC to determine the P85L29 features and extensions supported by the UAS for the duration of the P85L30 call, without probing. P85L31 P85L32 If the INVITE request contained an offer, and the UAS had not yet P85L33 sent an answer, the 2xx MUST contain an answer. If the INVITE did P85L34 not contain an offer, the 2xx MUST contain an offer if the UAS had P85L35 not yet sent an offer. P85L36 P85L37 Once the response has been constructed, it is passed to the INVITE P85L38 server transaction. Note, however, that the INVITE server P85L39 transaction will be destroyed as soon as it receives this final P85L40 response and passes it to the transport. Therefore, it is necessary P85L41 to periodically pass the response directly to the transport until the P85L42 ACK arrives. The 2xx response is passed to the transport with an P85L43 interval that starts at T1 seconds and doubles for each P85L44 retransmission until it reaches T2 seconds (T1 and T2 are defined in P85L45 Section 17). Response retransmissions cease when an ACK request for P85L46 the response is received. This is independent of whatever transport P85L47 protocols are used to send the response. P85L48 P86L1 Since 2xx is retransmitted end-to-end, there may be hops between P86L2 UAS and UAC that are UDP. To ensure reliable delivery across P86L3 these hops, the response is retransmitted periodically even if the P86L4 transport at the UAS is reliable. P86L5 P86L6 If the server retransmits the 2xx response for 64*T1 seconds without P86L7 receiving an ACK, the dialog is confirmed, but the session SHOULD be P86L8 terminated. This is accomplished with a BYE, as described in Section P86L9 15. P86L10 P86L11 14 Modifying an Existing Session P86L12 P86L13 A successful INVITE request (see Section 13) establishes both a P86L14 dialog between two user agents and a session using the offer-answer P86L15 model. Section 12 explains how to modify an existing dialog using a P86L16 target refresh request (for example, changing the remote target URI P86L17 of the dialog). This section describes how to modify the actual P86L18 session. This modification can involve changing addresses or ports, P86L19 adding a media stream, deleting a media stream, and so on. This is P86L20 accomplished by sending a new INVITE request within the same dialog P86L21 that established the session. An INVITE request sent within an P86L22 existing dialog is known as a re-INVITE. P86L23 P86L24 Note that a single re-INVITE can modify the dialog and the P86L25 parameters of the session at the same time. P86L26 P86L27 Either the caller or callee can modify an existing session. P86L28 P86L29 The behavior of a UA on detection of media failure is a matter of P86L30 local policy. However, automated generation of re-INVITE or BYE is P86L31 NOT RECOMMENDED to avoid flooding the network with traffic when there P86L32 is congestion. In any case, if these messages are sent P86L33 automatically, they SHOULD be sent after some randomized interval. P86L34 P86L35 Note that the paragraph above refers to automatically generated P86L36 BYEs and re-INVITEs. If the user hangs up upon media failure, the P86L37 UA would send a BYE request as usual. P86L38 P86L39 14.1 UAC Behavior P86L40 P86L41 The same offer-answer model that applies to session descriptions in P86L42 INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC P86L43 that wants to add a media stream, for example, will create a new P86L44 offer that contains this media stream, and send that in an INVITE P86L45 request to its peer. It is important to note that the full P86L46 description of the session, not just the change, is sent. This P86L47 supports stateless session processing in various elements, and P86L48 supports failover and recovery capabilities. Of course, a UAC MAY P87L1 send a re-INVITE with no session description, in which case the first P87L2 reliable non-failure response to the re-INVITE will contain the offer P87L3 (in this specification, that is a 2xx response). P87L4 P87L5 If the session description format has the capability for version P87L6 numbers, the offerer SHOULD indicate that the version of the session P87L7 description has changed. P87L8 P87L9 The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set P87L10 following the same rules as for regular requests within an existing P87L11 dialog, described in Section 12. P87L12 P87L13 A UAC MAY choose not to add an Alert-Info header field or a body with P87L14 Content-Disposition "alert" to re-INVITEs because UASs do not P87L15 typically alert the user upon reception of a re-INVITE. P87L16 P87L17 Unlike an INVITE, which can fork, a re-INVITE will never fork, and P87L18 therefore, only ever generate a single final response. The reason a P87L19 re-INVITE will never fork is that the Request-URI identifies the P87L20 target as the UA instance it established the dialog with, rather than P87L21 identifying an address-of-record for the user. P87L22 P87L23 Note that a UAC MUST NOT initiate a new INVITE transaction within a P87L24 dialog while another INVITE transaction is in progress in either P87L25 direction. P87L26 P87L27 1. If there is an ongoing INVITE client transaction, the TU MUST P87L28 wait until the transaction reaches the completed or terminated P87L29 state before initiating the new INVITE. P87L30 P87L31 2. If there is an ongoing INVITE server transaction, the TU MUST P87L32 wait until the transaction reaches the confirmed or terminated P87L33 state before initiating the new INVITE. P87L34 P87L35 However, a UA MAY initiate a regular transaction while an INVITE P87L36 transaction is in progress. A UA MAY also initiate an INVITE P87L37 transaction while a regular transaction is in progress. P87L38 P87L39 If a UA receives a non-2xx final response to a re-INVITE, the session P87L40 parameters MUST remain unchanged, as if no re-INVITE had been issued. P87L41 Note that, as stated in Section 12.2.1.2, if the non-2xx final P87L42 response is a 481 (Call/Transaction Does Not Exist), or a 408 P87L43 (Request Timeout), or no response at all is received for the re- P87L44 INVITE (that is, a timeout is returned by the INVITE client P87L45 transaction), the UAC will terminate the dialog. P87L46 P87L47 P87L48 P88L1 If a UAC receives a 491 response to a re-INVITE, it SHOULD start a P88L2 timer with a value T chosen as follows: P88L3 P88L4 1. If the UAC is the owner of the Call-ID of the dialog ID P88L5 (meaning it generated the value), T has a randomly chosen value P88L6 between 2.1 and 4 seconds in units of 10 ms. P88L7 P88L8 2. If the UAC is not the owner of the Call-ID of the dialog ID, T P88L9 has a randomly chosen value of between 0 and 2 seconds in units P88L10 of 10 ms. P88L11 P88L12 When the timer fires, the UAC SHOULD attempt the re-INVITE once more, P88L13 if it still desires for that session modification to take place. For P88L14 example, if the call was already hung up with a BYE, the re-INVITE P88L15 would not take place. P88L16 P88L17 The rules for transmitting a re-INVITE and for generating an ACK for P88L18 a 2xx response to re-INVITE are the same as for the initial INVITE P88L19 (Section 13.2.1). P88L20 P88L21 14.2 UAS Behavior P88L22 P88L23 Section 13.3.1 describes the procedure for distinguishing incoming P88L24 re-INVITEs from incoming initial INVITEs and handling a re-INVITE for P88L25 an existing dialog. P88L26 P88L27 A UAS that receives a second INVITE before it sends the final P88L28 response to a first INVITE with a lower CSeq sequence number on the P88L29 same dialog MUST return a 500 (Server Internal Error) response to the P88L30 second INVITE and MUST include a Retry-After header field with a P88L31 randomly chosen value of between 0 and 10 seconds. P88L32 P88L33 A UAS that receives an INVITE on a dialog while an INVITE it had sent P88L34 on that dialog is in progress MUST return a 491 (Request Pending) P88L35 response to the received INVITE. P88L36 P88L37 If a UA receives a re-INVITE for an existing dialog, it MUST check P88L38 any version identifiers in the session description or, if there are P88L39 no version identifiers, the content of the session description to see P88L40 if it has changed. If the session description has changed, the UAS P88L41 MUST adjust the session parameters accordingly, possibly after asking P88L42 the user for confirmation. P88L43 P88L44 Versioning of the session description can be used to accommodate P88L45 the capabilities of new arrivals to a conference, add or delete P88L46 media, or change from a unicast to a multicast conference. P88L47 P88L48 P89L1 If the new session description is not acceptable, the UAS can reject P89L2 it by returning a 488 (Not Acceptable Here) response for the re- P89L3 INVITE. This response SHOULD include a Warning header field. P89L4 P89L5 If a UAS generates a 2xx response and never receives an ACK, it P89L6 SHOULD generate a BYE to terminate the dialog. P89L7 P89L8 A UAS MAY choose not to generate 180 (Ringing) responses for a re- P89L9 INVITE because UACs do not typically render this information to the P89L10 user. For the same reason, UASs MAY choose not to use an Alert-Info P89L11 header field or a body with Content-Disposition "alert" in responses P89L12 to a re-INVITE. P89L13 P89L14 A UAS providing an offer in a 2xx (because the INVITE did not contain P89L15 an offer) SHOULD construct the offer as if the UAS were making a P89L16 brand new call, subject to the constraints of sending an offer that P89L17 updates an existing session, as described in [13] in the case of SDP. P89L18 Specifically, this means that it SHOULD include as many media formats P89L19 and media types that the UA is willing to support. The UAS MUST P89L20 ensure that the session description overlaps with its previous P89L21 session description in media formats, transports, or other parameters P89L22 that require support from the peer. This is to avoid the need for P89L23 the peer to reject the session description. If, however, it is P89L24 unacceptable to the UAC, the UAC SHOULD generate an answer with a P89L25 valid session description, and then send a BYE to terminate the P89L26 session. P89L27 P89L28 15 Terminating a Session P89L29 P89L30 This section describes the procedures for terminating a session P89L31 established by SIP. The state of the session and the state of the P89L32 dialog are very closely related. When a session is initiated with an P89L33 INVITE, each 1xx or 2xx response from a distinct UAS creates a P89L34 dialog, and if that response completes the offer/answer exchange, it P89L35 also creates a session. As a result, each session is "associated" P89L36 with a single dialog - the one which resulted in its creation. If an P89L37 initial INVITE generates a non-2xx final response, that terminates P89L38 all sessions (if any) and all dialogs (if any) that were created P89L39 through responses to the request. By virtue of completing the P89L40 transaction, a non-2xx final response also prevents further sessions P89L41 from being created as a result of the INVITE. The BYE request is P89L42 used to terminate a specific session or attempted session. In this P89L43 case, the specific session is the one with the peer UA on the other P89L44 side of the dialog. When a BYE is received on a dialog, any session P89L45 associated with that dialog SHOULD terminate. A UA MUST NOT send a P89L46 BYE outside of a dialog. The caller's UA MAY send a BYE for either P89L47 confirmed or early dialogs, and the callee's UA MAY send a BYE on P89L48 confirmed dialogs, but MUST NOT send a BYE on early dialogs. P90L1 However, the callee's UA MUST NOT send a BYE on a confirmed dialog P90L2 until it has received an ACK for its 2xx response or until the server P90L3 transaction times out. If no SIP extensions have defined other P90L4 application layer states associated with the dialog, the BYE also P90L5 terminates the dialog. P90L6 P90L7 The impact of a non-2xx final response to INVITE on dialogs and P90L8 sessions makes the use of CANCEL attractive. The CANCEL attempts to P90L9 force a non-2xx response to the INVITE (in particular, a 487). P90L10 Therefore, if a UAC wishes to give up on its call attempt entirely, P90L11 it can send a CANCEL. If the INVITE results in 2xx final response(s) P90L12 to the INVITE, this means that a UAS accepted the invitation while P90L13 the CANCEL was in progress. The UAC MAY continue with the sessions P90L14 established by any 2xx responses, or MAY terminate them with BYE. P90L15 P90L16 The notion of "hanging up" is not well defined within SIP. It is P90L17 specific to a particular, albeit common, user interface. P90L18 Typically, when the user hangs up, it indicates a desire to P90L19 terminate the attempt to establish a session, and to terminate any P90L20 sessions already created. For the caller's UA, this would imply a P90L21 CANCEL request if the initial INVITE has not generated a final P90L22 response, and a BYE to all confirmed dialogs after a final P90L23 response. For the callee's UA, it would typically imply a BYE; P90L24 presumably, when the user picked up the phone, a 2xx was P90L25 generated, and so hanging up would result in a BYE after the ACK P90L26 is received. This does not mean a user cannot hang up before P90L27 receipt of the ACK, it just means that the software in his phone P90L28 needs to maintain state for a short while in order to clean up P90L29 properly. If the particular UI allows for the user to reject a P90L30 call before its answered, a 403 (Forbidden) is a good way to P90L31 express that. As per the rules above, a BYE can't be sent. P90L32 P90L33 15.1 Terminating a Session with a BYE Request P90L34 P90L35 15.1.1 UAC Behavior P90L36 P90L37 A BYE request is constructed as would any other request within a P90L38 dialog, as described in Section 12. P90L39 P90L40 Once the BYE is constructed, the UAC core creates a new non-INVITE P90L41 client transaction, and passes it the BYE request. The UAC MUST P90L42 consider the session terminated (and therefore stop sending or P90L43 listening for media) as soon as the BYE request is passed to the P90L44 client transaction. If the response for the BYE is a 481 P90L45 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no P90L46 P90L47 P90L48 P91L1 response at all is received for the BYE (that is, a timeout is P91L2 returned by the client transaction), the UAC MUST consider the P91L3 session and the dialog terminated. P91L4 P91L5 15.1.2 UAS Behavior P91L6 P91L7 A UAS first processes the BYE request according to the general UAS P91L8 processing described in Section 8.2. A UAS core receiving a BYE P91L9 request checks if it matches an existing dialog. If the BYE does not P91L10 match an existing dialog, the UAS core SHOULD generate a 481 P91L11 (Call/Transaction Does Not Exist) response and pass that to the P91L12 server transaction. P91L13 P91L14 This rule means that a BYE sent without tags by a UAC will be P91L15 rejected. This is a change from RFC 2543, which allowed BYE P91L16 without tags. P91L17 P91L18 A UAS core receiving a BYE request for an existing dialog MUST follow P91L19 the procedures of Section 12.2.2 to process the request. Once done, P91L20 the UAS SHOULD terminate the session (and therefore stop sending and P91L21 listening for media). The only case where it can elect not to are P91L22 multicast sessions, where participation is possible even if the other P91L23 participant in the dialog has terminated its involvement in the P91L24 session. Whether or not it ends its participation on the session, P91L25 the UAS core MUST generate a 2xx response to the BYE, and MUST pass P91L26 that to the server transaction for transmission. P91L27 P91L28 The UAS MUST still respond to any pending requests received for that P91L29 dialog. It is RECOMMENDED that a 487 (Request Terminated) response P91L30 be generated to those pending requests. P91L31 P91L32 16 Proxy Behavior P91L33 P91L34 16.1 Overview P91L35 P91L36 SIP proxies are elements that route SIP requests to user agent P91L37 servers and SIP responses to user agent clients. A request may P91L38 traverse several proxies on its way to a UAS. Each will make routing P91L39 decisions, modifying the request before forwarding it to the next P91L40 element. Responses will route through the same set of proxies P91L41 traversed by the request in the reverse order. P91L42 P91L43 Being a proxy is a logical role for a SIP element. When a request P91L44 arrives, an element that can play the role of a proxy first decides P91L45 if it needs to respond to the request on its own. For instance, the P91L46 request may be malformed or the element may need credentials from the P91L47 client before acting as a proxy. The element MAY respond with any P91L48 P92L1 appropriate error code. When responding directly to a request, the P92L2 element is playing the role of a UAS and MUST behave as described in P92L3 Section 8.2. P92L4 P92L5 A proxy can operate in either a stateful or stateless mode for each P92L6 new request. When stateless, a proxy acts as a simple forwarding P92L7 element. It forwards each request downstream to a single element P92L8 determined by making a targeting and routing decision based on the P92L9 request. It simply forwards every response it receives upstream. A P92L10 stateless proxy discards information about a message once the message P92L11 has been forwarded. A stateful proxy remembers information P92L12 (specifically, transaction state) about each incoming request and any P92L13 requests it sends as a result of processing the incoming request. It P92L14 uses this information to affect the processing of future messages P92L15 associated with that request. A stateful proxy MAY choose to "fork" P92L16 a request, routing it to multiple destinations. Any request that is P92L17 forwarded to more than one location MUST be handled statefully. P92L18 P92L19 In some circumstances, a proxy MAY forward requests using stateful P92L20 transports (such as TCP) without being transaction-stateful. For P92L21 instance, a proxy MAY forward a request from one TCP connection to P92L22 another transaction statelessly as long as it places enough P92L23 information in the message to be able to forward the response down P92L24 the same connection the request arrived on. Requests forwarded P92L25 between different types of transports where the proxy's TU must take P92L26 an active role in ensuring reliable delivery on one of the transports P92L27 MUST be forwarded transaction statefully. P92L28 P92L29 A stateful proxy MAY transition to stateless operation at any time P92L30 during the processing of a request, so long as it did not do anything P92L31 that would otherwise prevent it from being stateless initially P92L32 (forking, for example, or generation of a 100 response). When P92L33 performing such a transition, all state is simply discarded. The P92L34 proxy SHOULD NOT initiate a CANCEL request. P92L35 P92L36 Much of the processing involved when acting statelessly or statefully P92L37 for a request is identical. The next several subsections are written P92L38 from the point of view of a stateful proxy. The last section calls P92L39 out those places where a stateless proxy behaves differently. P92L40 P92L41 16.2 Stateful Proxy P92L42 P92L43 When stateful, a proxy is purely a SIP transaction processing engine. P92L44 Its behavior is modeled here in terms of the server and client P92L45 transactions defined in Section 17. A stateful proxy has a server P92L46 transaction associated with one or more client transactions by a P92L47 higher layer proxy processing component (see figure 3), known as a P92L48 proxy core. An incoming request is processed by a server P93L1 transaction. Requests from the server transaction are passed to a P93L2 proxy core. The proxy core determines where to route the request, P93L3 choosing one or more next-hop locations. An outgoing request for P93L4 each next-hop location is processed by its own associated client P93L5 transaction. The proxy core collects the responses from the client P93L6 transactions and uses them to send responses to the server P93L7 transaction. P93L8 P93L9 A stateful proxy creates a new server transaction for each new P93L10 request received. Any retransmissions of the request will then be P93L11 handled by that server transaction per Section 17. The proxy core P93L12 MUST behave as a UAS with respect to sending an immediate provisional P93L13 on that server transaction (such as 100 Trying) as described in P93L14 Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 P93L15 (Trying) responses to non-INVITE requests. P93L16 P93L17 This is a model of proxy behavior, not of software. An P93L18 implementation is free to take any approach that replicates the P93L19 external behavior this model defines. P93L20 P93L21 For all new requests, including any with unknown methods, an element P93L22 intending to proxy the request MUST: P93L23 P93L24 1. Validate the request (Section 16.3) P93L25 P93L26 2. Preprocess routing information (Section 16.4) P93L27 P93L28 3. Determine target(s) for the request (Section 16.5) P93L29 P93L30 +--------------------+ P93L31 | | +---+ P93L32 | | | C | P93L33 | | | T | P93L34 | | +---+ P93L35 +---+ | Proxy | +---+ CT = Client Transaction P93L36 | S | | "Higher" Layer | | C | P93L37 | T | | | | T | ST = Server Transaction P93L38 +---+ | | +---+ P93L39 | | +---+ P93L40 | | | C | P93L41 | | | T | P93L42 | | +---+ P93L43 +--------------------+ P93L44 P93L45 Figure 3: Stateful Proxy Model P93L46 P93L47 P93L48 P94L1 4. Forward the request to each target (Section 16.6) P94L2 P94L3 5. Process all responses (Section 16.7) P94L4 P94L5 16.3 Request Validation P94L6 P94L7 Before an element can proxy a request, it MUST verify the message's P94L8 validity. A valid message must pass the following checks: P94L9 P94L10 1. Reasonable Syntax P94L11 P94L12 2. URI scheme P94L13 P94L14 3. Max-Forwards P94L15 P94L16 4. (Optional) Loop Detection P94L17 P94L18 5. Proxy-Require P94L19 P94L20 6. Proxy-Authorization P94L21 P94L22 If any of these checks fail, the element MUST behave as a user agent P94L23 server (see Section 8.2) and respond with an error code. P94L24 P94L25 Notice that a proxy is not required to detect merged requests and P94L26 MUST NOT treat merged requests as an error condition. The endpoints P94L27 receiving the requests will resolve the merge as described in Section P94L28 8.2.2.2. P94L29 P94L30 1. Reasonable syntax check P94L31 P94L32 The request MUST be well-formed enough to be handled with a server P94L33 transaction. Any components involved in the remainder of these P94L34 Request Validation steps or the Request Forwarding section MUST be P94L35 well-formed. Any other components, well-formed or not, SHOULD be P94L36 ignored and remain unchanged when the message is forwarded. For P94L37 instance, an element would not reject a request because of a P94L38 malformed Date header field. Likewise, a proxy would not remove a P94L39 malformed Date header field before forwarding a request. P94L40 P94L41 This protocol is designed to be extended. Future extensions may P94L42 define new methods and header fields at any time. An element MUST P94L43 NOT refuse to proxy a request because it contains a method or P94L44 header field it does not know about. P94L45 P94L46 P94L47 P94L48 P95L1 2. URI scheme check P95L2 P95L3 If the Request-URI has a URI whose scheme is not understood by the P95L4 proxy, the proxy SHOULD reject the request with a 416 (Unsupported P95L5 URI Scheme) response. P95L6 P95L7 3. Max-Forwards check P95L8 P95L9 The Max-Forwards header field (Section 20.22) is used to limit the P95L10 number of elements a SIP request can traverse. P95L11 P95L12 If the request does not contain a Max-Forwards header field, this P95L13 check is passed. P95L14 P95L15 If the request contains a Max-Forwards header field with a field P95L16 value greater than zero, the check is passed. P95L17 P95L18 If the request contains a Max-Forwards header field with a field P95L19 value of zero (0), the element MUST NOT forward the request. If P95L20 the request was for OPTIONS, the element MAY act as the final P95L21 recipient and respond per Section 11. Otherwise, the element MUST P95L22 return a 483 (Too many hops) response. P95L23 P95L24 4. Optional Loop Detection check P95L25 P95L26 An element MAY check for forwarding loops before forwarding a P95L27 request. If the request contains a Via header field with a sent- P95L28 by value that equals a value placed into previous requests by the P95L29 proxy, the request has been forwarded by this element before. The P95L30 request has either looped or is legitimately spiraling through the P95L31 element. To determine if the request has looped, the element MAY P95L32 perform the branch parameter calculation described in Step 8 of P95L33 Section 16.6 on this message and compare it to the parameter P95L34 received in that Via header field. If the parameters match, the P95L35 request has looped. If they differ, the request is spiraling, and P95L36 processing continues. If a loop is detected, the element MAY P95L37 return a 482 (Loop Detected) response. P95L38 P95L39 5. Proxy-Require check P95L40 P95L41 Future extensions to this protocol may introduce features that P95L42 require special handling by proxies. Endpoints will include a P95L43 Proxy-Require header field in requests that use these features, P95L44 telling the proxy not to process the request unless the feature is P95L45 understood. P95L46 P95L47 P95L48 P96L1 If the request contains a Proxy-Require header field (Section P96L2 20.29) with one or more option-tags this element does not P96L3 understand, the element MUST return a 420 (Bad Extension) P96L4 response. The response MUST include an Unsupported (Section P96L5 20.40) header field listing those option-tags the element did not P96L6 understand. P96L7 P96L8 6. Proxy-Authorization check P96L9 P96L10 If an element requires credentials before forwarding a request, P96L11 the request MUST be inspected as described in Section 22.3. That P96L12 section also defines what the element must do if the inspection P96L13 fails. P96L14 P96L15 16.4 Route Information Preprocessing P96L16 P96L17 The proxy MUST inspect the Request-URI of the request. If the P96L18 Request-URI of the request contains a value this proxy previously P96L19 placed into a Record-Route header field (see Section 16.6 item 4), P96L20 the proxy MUST replace the Request-URI in the request with the last P96L21 value from the Route header field, and remove that value from the P96L22 Route header field. The proxy MUST then proceed as if it received P96L23 this modified request. P96L24 P96L25 This will only happen when the element sending the request to the P96L26 proxy (which may have been an endpoint) is a strict router. This P96L27 rewrite on receive is necessary to enable backwards compatibility P96L28 with those elements. It also allows elements following this P96L29 specification to preserve the Request-URI through strict-routing P96L30 proxies (see Section 12.2.1.1). P96L31 P96L32 This requirement does not obligate a proxy to keep state in order P96L33 to detect URIs it previously placed in Record-Route header fields. P96L34 Instead, a proxy need only place enough information in those URIs P96L35 to recognize them as values it provided when they later appear. P96L36 P96L37 If the Request-URI contains a maddr parameter, the proxy MUST check P96L38 to see if its value is in the set of addresses or domains the proxy P96L39 is configured to be responsible for. If the Request-URI has a maddr P96L40 parameter with a value the proxy is responsible for, and the request P96L41 was received using the port and transport indicated (explicitly or by P96L42 default) in the Request-URI, the proxy MUST strip the maddr and any P96L43 non-default port or transport parameter and continue processing as if P96L44 those values had not been present in the request. P96L45 P96L46 P96L47 P96L48 P97L1 A request may arrive with a maddr matching the proxy, but on a P97L2 port or transport different from that indicated in the URI. Such P97L3 a request needs to be forwarded to the proxy using the indicated P97L4 port and transport. P97L5 P97L6 If the first value in the Route header field indicates this proxy, P97L7 the proxy MUST remove that value from the request. P97L8 P97L9 16.5 Determining Request Targets P97L10 P97L11 Next, the proxy calculates the target(s) of the request. The set of P97L12 targets will either be predetermined by the contents of the request P97L13 or will be obtained from an abstract location service. Each target P97L14 in the set is represented as a URI. P97L15 P97L16 If the Request-URI of the request contains an maddr parameter, the P97L17 Request-URI MUST be placed into the target set as the only target P97L18 URI, and the proxy MUST proceed to Section 16.6. P97L19 P97L20 If the domain of the Request-URI indicates a domain this element is P97L21 not responsible for, the Request-URI MUST be placed into the target P97L22 set as the only target, and the element MUST proceed to the task of P97L23 Request Forwarding (Section 16.6). P97L24 P97L25 There are many circumstances in which a proxy might receive a P97L26 request for a domain it is not responsible for. A firewall proxy P97L27 handling outgoing calls (the way HTTP proxies handle outgoing P97L28 requests) is an example of where this is likely to occur. P97L29 P97L30 If the target set for the request has not been predetermined as P97L31 described above, this implies that the element is responsible for the P97L32 domain in the Request-URI, and the element MAY use whatever mechanism P97L33 it desires to determine where to send the request. Any of these P97L34 mechanisms can be modeled as accessing an abstract Location Service. P97L35 This may consist of obtaining information from a location service P97L36 created by a SIP Registrar, reading a database, consulting a presence P97L37 server, utilizing other protocols, or simply performing an P97L38 algorithmic substitution on the Request-URI. When accessing the P97L39 location service constructed by a registrar, the Request-URI MUST P97L40 first be canonicalized as described in Section 10.3 before being used P97L41 as an index. The output of these mechanisms is used to construct the P97L42 target set. P97L43 P97L44 If the Request-URI does not provide sufficient information for the P97L45 proxy to determine the target set, it SHOULD return a 485 (Ambiguous) P97L46 response. This response SHOULD contain a Contact header field P97L47 containing URIs of new addresses to be tried. For example, an INVITE P97L48 P98L1 to sip:John.Smith@company.com may be ambiguous at a proxy whose P98L2 location service has multiple John Smiths listed. See Section P98L3 21.4.23 for details. P98L4 P98L5 Any information in or about the request or the current environment of P98L6 the element MAY be used in the construction of the target set. For P98L7 instance, different sets may be constructed depending on contents or P98L8 the presence of header fields and bodies, the time of day of the P98L9 request's arrival, the interface on which the request arrived, P98L10 failure of previous requests, or even the element's current level of P98L11 utilization. P98L12 P98L13 As potential targets are located through these services, their URIs P98L14 are added to the target set. Targets can only be placed in the P98L15 target set once. If a target URI is already present in the set P98L16 (based on the definition of equality for the URI type), it MUST NOT P98L17 be added again. P98L18 P98L19 A proxy MUST NOT add additional targets to the target set if the P98L20 Request-URI of the original request does not indicate a resource this P98L21 proxy is responsible for. P98L22 P98L23 A proxy can only change the Request-URI of a request during P98L24 forwarding if it is responsible for that URI. If the proxy is not P98L25 responsible for that URI, it will not recurse on 3xx or 416 P98L26 responses as described below. P98L27 P98L28 If the Request-URI of the original request indicates a resource this P98L29 proxy is responsible for, the proxy MAY continue to add targets to P98L30 the set after beginning Request Forwarding. It MAY use any P98L31 information obtained during that processing to determine new targets. P98L32 For instance, a proxy may choose to incorporate contacts obtained in P98L33 a redirect response (3xx) into the target set. If a proxy uses a P98L34 dynamic source of information while building the target set (for P98L35 instance, if it consults a SIP Registrar), it SHOULD monitor that P98L36 source for the duration of processing the request. New locations P98L37 SHOULD be added to the target set as they become available. As P98L38 above, any given URI MUST NOT be added to the set more than once. P98L39 P98L40 Allowing a URI to be added to the set only once reduces P98L41 unnecessary network traffic, and in the case of incorporating P98L42 contacts from redirect requests prevents infinite recursion. P98L43 P98L44 For example, a trivial location service is a "no-op", where the P98L45 target URI is equal to the incoming request URI. The request is sent P98L46 to a specific next hop proxy for further processing. During request P98L47 P98L48 P99L1 forwarding of Section 16.6, Item 6, the identity of that next hop, P99L2 expressed as a SIP or SIPS URI, is inserted as the top-most Route P99L3 header field value into the request. P99L4 P99L5 If the Request-URI indicates a resource at this proxy that does not P99L6 exist, the proxy MUST return a 404 (Not Found) response. P99L7 P99L8 If the target set remains empty after applying all of the above, the P99L9 proxy MUST return an error response, which SHOULD be the 480 P99L10 (Temporarily Unavailable) response. P99L11 P99L12 16.6 Request Forwarding P99L13 P99L14 As soon as the target set is non-empty, a proxy MAY begin forwarding P99L15 the request. A stateful proxy MAY process the set in any order. It P99L16 MAY process multiple targets serially, allowing each client P99L17 transaction to complete before starting the next. It MAY start P99L18 client transactions with every target in parallel. It also MAY P99L19 arbitrarily divide the set into groups, processing the groups P99L20 serially and processing the targets in each group in parallel. P99L21 P99L22 A common ordering mechanism is to use the qvalue parameter of targets P99L23 obtained from Contact header fields (see Section 20.10). Targets are P99L24 processed from highest qvalue to lowest. Targets with equal qvalues P99L25 may be processed in parallel. P99L26 P99L27 A stateful proxy must have a mechanism to maintain the target set as P99L28 responses are received and associate the responses to each forwarded P99L29 request with the original request. For the purposes of this model, P99L30 this mechanism is a "response context" created by the proxy layer P99L31 before forwarding the first request. P99L32 P99L33 For each target, the proxy forwards the request following these P99L34 steps: P99L35 P99L36 1. Make a copy of the received request P99L37 P99L38 2. Update the Request-URI P99L39 P99L40 3. Update the Max-Forwards header field P99L41 P99L42 4. Optionally add a Record-route header field value P99L43 P99L44 5. Optionally add additional header fields P99L45 P99L46 6. Postprocess routing information P99L47 P99L48 7. Determine the next-hop address, port, and transport P100L1 8. Add a Via header field value P100L2 P100L3 9. Add a Content-Length header field if necessary P100L4 P100L5 10. Forward the new request P100L6 P100L7 11. Set timer C P100L8 P100L9 Each of these steps is detailed below: P100L10 P100L11 1. Copy request P100L12 P100L13 The proxy starts with a copy of the received request. The copy P100L14 MUST initially contain all of the header fields from the P100L15 received request. Fields not detailed in the processing P100L16 described below MUST NOT be removed. The copy SHOULD maintain P100L17 the ordering of the header fields as in the received request. P100L18 The proxy MUST NOT reorder field values with a common field P100L19 name (See Section 7.3.1). The proxy MUST NOT add to, modify, P100L20 or remove the message body. P100L21 P100L22 An actual implementation need not perform a copy; the primary P100L23 requirement is that the processing for each next hop begin with P100L24 the same request. P100L25 P100L26 2. Request-URI P100L27 P100L28 The Request-URI in the copy's start line MUST be replaced with P100L29 the URI for this target. If the URI contains any parameters P100L30 not allowed in a Request-URI, they MUST be removed. P100L31 P100L32 This is the essence of a proxy's role. This is the mechanism P100L33 through which a proxy routes a request toward its destination. P100L34 P100L35 In some circumstances, the received Request-URI is placed into P100L36 the target set without being modified. For that target, the P100L37 replacement above is effectively a no-op. P100L38 P100L39 3. Max-Forwards P100L40 P100L41 If the copy contains a Max-Forwards header field, the proxy P100L42 MUST decrement its value by one (1). P100L43 P100L44 If the copy does not contain a Max-Forwards header field, the P100L45 proxy MUST add one with a field value, which SHOULD be 70. P100L46 P100L47 Some existing UAs will not provide a Max-Forwards header field P100L48 in a request. P101L1 4. Record-Route P101L2 P101L3 If this proxy wishes to remain on the path of future requests P101L4 in a dialog created by this request (assuming the request P101L5 creates a dialog), it MUST insert a Record-Route header field P101L6 value into the copy before any existing Record-Route header P101L7 field values, even if a Route header field is already present. P101L8 P101L9 Requests establishing a dialog may contain a preloaded Route P101L10 header field. P101L11 P101L12 If this request is already part of a dialog, the proxy SHOULD P101L13 insert a Record-Route header field value if it wishes to remain P101L14 on the path of future requests in the dialog. In normal P101L15 endpoint operation as described in Section 12, these Record- P101L16 Route header field values will not have any effect on the route P101L17 sets used by the endpoints. P101L18 P101L19 The proxy will remain on the path if it chooses to not insert a P101L20 Record-Route header field value into requests that are already P101L21 part of a dialog. However, it would be removed from the path P101L22 when an endpoint that has failed reconstitutes the dialog. P101L23 P101L24 A proxy MAY insert a Record-Route header field value into any P101L25 request. If the request does not initiate a dialog, the P101L26 endpoints will ignore the value. See Section 12 for details on P101L27 how endpoints use the Record-Route header field values to P101L28 construct Route header fields. P101L29 P101L30 Each proxy in the path of a request chooses whether to add a P101L31 Record-Route header field value independently - the presence of P101L32 a Record-Route header field in a request does not obligate this P101L33 proxy to add a value. P101L34 P101L35 The URI placed in the Record-Route header field value MUST be a P101L36 SIP or SIPS URI. This URI MUST contain an lr parameter (see P101L37 Section 19.1.1). This URI MAY be different for each P101L38 destination the request is forwarded to. The URI SHOULD NOT P101L39 contain the transport parameter unless the proxy has knowledge P101L40 (such as in a private network) that the next downstream element P101L41 that will be in the path of subsequent requests supports that P101L42 transport. P101L43 P101L44 The URI this proxy provides will be used by some other element P101L45 to make a routing decision. This proxy, in general, has no way P101L46 of knowing the capabilities of that element, so it must P101L47 restrict itself to the mandatory elements of a SIP P101L48 implementation: SIP URIs and either the TCP or UDP transports. P102L1 The URI placed in the Record-Route header field MUST resolve to P102L2 the element inserting it (or a suitable stand-in) when the P102L3 server location procedures of [4] are applied to it, so that P102L4 subsequent requests reach the same SIP element. If the P102L5 Request-URI contains a SIPS URI, or the topmost Route header P102L6 field value (after the post processing of bullet 6) contains a P102L7 SIPS URI, the URI placed into the Record-Route header field P102L8 MUST be a SIPS URI. Furthermore, if the request was not P102L9 received over TLS, the proxy MUST insert a Record-Route header P102L10 field. In a similar fashion, a proxy that receives a request P102L11 over TLS, but generates a request without a SIPS URI in the P102L12 Request-URI or topmost Route header field value (after the post P102L13 processing of bullet 6), MUST insert a Record-Route header P102L14 field that is not a SIPS URI. P102L15 P102L16 A proxy at a security perimeter must remain on the perimeter P102L17 throughout the dialog. P102L18 P102L19 If the URI placed in the Record-Route header field needs to be P102L20 rewritten when it passes back through in a response, the URI P102L21 MUST be distinct enough to locate at that time. (The request P102L22 may spiral through this proxy, resulting in more than one P102L23 Record-Route header field value being added). Item 8 of P102L24 Section 16.7 recommends a mechanism to make the URI P102L25 sufficiently distinct. P102L26 P102L27 The proxy MAY include parameters in the Record-Route header P102L28 field value. These will be echoed in some responses to the P102L29 request such as the 200 (OK) responses to INVITE. Such P102L30 parameters may be useful for keeping state in the message P102L31 rather than the proxy. P102L32 P102L33 If a proxy needs to be in the path of any type of dialog (such P102L34 as one straddling a firewall), it SHOULD add a Record-Route P102L35 header field value to every request with a method it does not P102L36 understand since that method may have dialog semantics. P102L37 P102L38 The URI a proxy places into a Record-Route header field is only P102L39 valid for the lifetime of any dialog created by the transaction P102L40 in which it occurs. A dialog-stateful proxy, for example, MAY P102L41 refuse to accept future requests with that value in the P102L42 Request-URI after the dialog has terminated. Non-dialog- P102L43 stateful proxies, of course, have no concept of when the dialog P102L44 has terminated, but they MAY encode enough information in the P102L45 value to compare it against the dialog identifier of future P102L46 requests and MAY reject requests not matching that information. P102L47 Endpoints MUST NOT use a URI obtained from a Record-Route P102L48 header field outside the dialog in which it was provided. See P103L1 Section 12 for more information on an endpoint's use of P103L2 Record-Route header fields. P103L3 P103L4 Record-routing may be required by certain services where the P103L5 proxy needs to observe all messages in a dialog. However, it P103L6 slows down processing and impairs scalability and thus proxies P103L7 should only record-route if required for a particular service. P103L8 P103L9 The Record-Route process is designed to work for any SIP P103L10 request that initiates a dialog. INVITE is the only such P103L11 request in this specification, but extensions to the protocol P103L12 MAY define others. P103L13 P103L14 5. Add Additional Header Fields P103L15 P103L16 The proxy MAY add any other appropriate header fields to the P103L17 copy at this point. P103L18 P103L19 6. Postprocess routing information P103L20 P103L21 A proxy MAY have a local policy that mandates that a request P103L22 visit a specific set of proxies before being delivered to the P103L23 destination. A proxy MUST ensure that all such proxies are P103L24 loose routers. Generally, this can only be known with P103L25 certainty if the proxies are within the same administrative P103L26 domain. This set of proxies is represented by a set of URIs P103L27 (each of which contains the lr parameter). This set MUST be P103L28 pushed into the Route header field of the copy ahead of any P103L29 existing values, if present. If the Route header field is P103L30 absent, it MUST be added, containing that list of URIs. P103L31 P103L32 If the proxy has a local policy that mandates that the request P103L33 visit one specific proxy, an alternative to pushing a Route P103L34 value into the Route header field is to bypass the forwarding P103L35 logic of item 10 below, and instead just send the request to P103L36 the address, port, and transport for that specific proxy. If P103L37 the request has a Route header field, this alternative MUST NOT P103L38 be used unless it is known that next hop proxy is a loose P103L39 router. Otherwise, this approach MAY be used, but the Route P103L40 insertion mechanism above is preferred for its robustness, P103L41 flexibility, generality and consistency of operation. P103L42 Furthermore, if the Request-URI contains a SIPS URI, TLS MUST P103L43 be used to communicate with that proxy. P103L44 P103L45 If the copy contains a Route header field, the proxy MUST P103L46 inspect the URI in its first value. If that URI does not P103L47 contain an lr parameter, the proxy MUST modify the copy as P103L48 follows: P104L1 - The proxy MUST place the Request-URI into the Route header P104L2 field as the last value. P104L3 P104L4 - The proxy MUST then place the first Route header field value P104L5 into the Request-URI and remove that value from the Route P104L6 header field. P104L7 P104L8 Appending the Request-URI to the Route header field is part of P104L9 a mechanism used to pass the information in that Request-URI P104L10 through strict-routing elements. "Popping" the first Route P104L11 header field value into the Request-URI formats the message the P104L12 way a strict-routing element expects to receive it (with its P104L13 own URI in the Request-URI and the next location to visit in P104L14 the first Route header field value). P104L15 P104L16 7. Determine Next-Hop Address, Port, and Transport P104L17 P104L18 The proxy MAY have a local policy to send the request to a P104L19 specific IP address, port, and transport, independent of the P104L20 values of the Route and Request-URI. Such a policy MUST NOT be P104L21 used if the proxy is not certain that the IP address, port, and P104L22 transport correspond to a server that is a loose router. P104L23 However, this mechanism for sending the request through a P104L24 specific next hop is NOT RECOMMENDED; instead a Route header P104L25 field should be used for that purpose as described above. P104L26 P104L27 In the absence of such an overriding mechanism, the proxy P104L28 applies the procedures listed in [4] as follows to determine P104L29 where to send the request. If the proxy has reformatted the P104L30 request to send to a strict-routing element as described in P104L31 step 6 above, the proxy MUST apply those procedures to the P104L32 Request-URI of the request. Otherwise, the proxy MUST apply P104L33 the procedures to the first value in the Route header field, if P104L34 present, else the Request-URI. The procedures will produce an P104L35 ordered set of (address, port, transport) tuples. P104L36 Independently of which URI is being used as input to the P104L37 procedures of [4], if the Request-URI specifies a SIPS P104L38 resource, the proxy MUST follow the procedures of [4] as if the P104L39 input URI were a SIPS URI. P104L40 P104L41 As described in [4], the proxy MUST attempt to deliver the P104L42 message to the first tuple in that set, and proceed through the P104L43 set in order until the delivery attempt succeeds. P104L44 P104L45 For each tuple attempted, the proxy MUST format the message as P104L46 appropriate for the tuple and send the request using a new P104L47 client transaction as detailed in steps 8 through 10. P104L48 P105L1 Since each attempt uses a new client transaction, it represents P105L2 a new branch. Thus, the branch parameter provided with the Via P105L3 header field inserted in step 8 MUST be different for each P105L4 attempt. P105L5 P105L6 If the client transaction reports failure to send the request P105L7 or a timeout from its state machine, the proxy continues to the P105L8 next address in that ordered set. If the ordered set is P105L9 exhausted, the request cannot be forwarded to this element in P105L10 the target set. The proxy does not need to place anything in P105L11 the response context, but otherwise acts as if this element of P105L12 the target set returned a 408 (Request Timeout) final response. P105L13 P105L14 8. Add a Via header field value P105L15 P105L16 The proxy MUST insert a Via header field value into the copy P105L17 before the existing Via header field values. The construction P105L18 of this value follows the same guidelines of Section 8.1.1.7. P105L19 This implies that the proxy will compute its own branch P105L20 parameter, which will be globally unique for that branch, and P105L21 contain the requisite magic cookie. Note that this implies that P105L22 the branch parameter will be different for different instances P105L23 of a spiraled or looped request through a proxy. P105L24 P105L25 Proxies choosing to detect loops have an additional constraint P105L26 in the value they use for construction of the branch parameter. P105L27 A proxy choosing to detect loops SHOULD create a branch P105L28 parameter separable into two parts by the implementation. The P105L29 first part MUST satisfy the constraints of Section 8.1.1.7 as P105L30 described above. The second is used to perform loop detection P105L31 and distinguish loops from spirals. P105L32 P105L33 Loop detection is performed by verifying that, when a request P105L34 returns to a proxy, those fields having an impact on the P105L35 processing of the request have not changed. The value placed P105L36 in this part of the branch parameter SHOULD reflect all of P105L37 those fields (including any Route, Proxy-Require and Proxy- P105L38 Authorization header fields). This is to ensure that if the P105L39 request is routed back to the proxy and one of those fields P105L40 changes, it is treated as a spiral and not a loop (see Section P105L41 16.3). A common way to create this value is to compute a P105L42 cryptographic hash of the To tag, From tag, Call-ID header P105L43 field, the Request-URI of the request received (before P105L44 translation), the topmost Via header, and the sequence number P105L45 from the CSeq header field, in addition to any Proxy-Require P105L46 and Proxy-Authorization header fields that may be present. The P105L47 P105L48 P106L1 algorithm used to compute the hash is implementation-dependent, P106L2 but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a P106L3 reasonable choice. (Base64 is not permissible for a token.) P106L4 P106L5 If a proxy wishes to detect loops, the "branch" parameter it P106L6 supplies MUST depend on all information affecting processing of P106L7 a request, including the incoming Request-URI and any header P106L8 fields affecting the request's admission or routing. This is P106L9 necessary to distinguish looped requests from requests whose P106L10 routing parameters have changed before returning to this P106L11 server. P106L12 P106L13 The request method MUST NOT be included in the calculation of P106L14 the branch parameter. In particular, CANCEL and ACK requests P106L15 (for non-2xx responses) MUST have the same branch value as the P106L16 corresponding request they cancel or acknowledge. The branch P106L17 parameter is used in correlating those requests at the server P106L18 handling them (see Sections 17.2.3 and 9.2). P106L19 P106L20 9. Add a Content-Length header field if necessary P106L21 P106L22 If the request will be sent to the next hop using a stream- P106L23 based transport and the copy contains no Content-Length header P106L24 field, the proxy MUST insert one with the correct value for the P106L25 body of the request (see Section 20.14). P106L26 P106L27 10. Forward Request P106L28 P106L29 A stateful proxy MUST create a new client transaction for this P106L30 request as described in Section 17.1 and instructs the P106L31 transaction to send the request using the address, port and P106L32 transport determined in step 7. P106L33 P106L34 11. Set timer C P106L35 P106L36 In order to handle the case where an INVITE request never P106L37 generates a final response, the TU uses a timer which is called P106L38 timer C. Timer C MUST be set for each client transaction when P106L39 an INVITE request is proxied. The timer MUST be larger than 3 P106L40 minutes. Section 16.7 bullet 2 discusses how this timer is P106L41 updated with provisional responses, and Section 16.8 discusses P106L42 processing when it fires. P106L43 P106L44 P106L45 P106L46 P106L47 P106L48 P107L1 16.7 Response Processing P107L2 P107L3 When a response is received by an element, it first tries to locate a P107L4 client transaction (Section 17.1.3) matching the response. If none P107L5 is found, the element MUST process the response (even if it is an P107L6 informational response) as a stateless proxy (described below). If a P107L7 match is found, the response is handed to the client transaction. P107L8 P107L9 Forwarding responses for which a client transaction (or more P107L10 generally any knowledge of having sent an associated request) is P107L11 not found improves robustness. In particular, it ensures that P107L12 "late" 2xx responses to INVITE requests are forwarded properly. P107L13 P107L14 As client transactions pass responses to the proxy layer, the P107L15 following processing MUST take place: P107L16 P107L17 1. Find the appropriate response context P107L18 P107L19 2. Update timer C for provisional responses P107L20 P107L21 3. Remove the topmost Via P107L22 P107L23 4. Add the response to the response context P107L24 P107L25 5. Check to see if this response should be forwarded immediately P107L26 P107L27 6. When necessary, choose the best final response from the P107L28 response context P107L29 P107L30 If no final response has been forwarded after every client P107L31 transaction associated with the response context has been terminated, P107L32 the proxy must choose and forward the "best" response from those it P107L33 has seen so far. P107L34 P107L35 The following processing MUST be performed on each response that is P107L36 forwarded. It is likely that more than one response to each request P107L37 will be forwarded: at least each provisional and one final response. P107L38 P107L39 7. Aggregate authorization header field values if necessary P107L40 P107L41 8. Optionally rewrite Record-Route header field values P107L42 P107L43 9. Forward the response P107L44 P107L45 10. Generate any necessary CANCEL requests P107L46 P107L47 P107L48 P108L1 Each of the above steps are detailed below: P108L2 P108L3 1. Find Context P108L4 P108L5 The proxy locates the "response context" it created before P108L6 forwarding the original request using the key described in P108L7 Section 16.6. The remaining processing steps take place in P108L8 this context. P108L9 P108L10 2. Update timer C for provisional responses P108L11 P108L12 For an INVITE transaction, if the response is a provisional P108L13 response with status codes 101 to 199 inclusive (i.e., anything P108L14 but 100), the proxy MUST reset timer C for that client P108L15 transaction. The timer MAY be reset to a different value, but P108L16 this value MUST be greater than 3 minutes. P108L17 P108L18 3. Via P108L19 P108L20 The proxy removes the topmost Via header field value from the P108L21 response. P108L22 P108L23 If no Via header field values remain in the response, the P108L24 response was meant for this element and MUST NOT be forwarded. P108L25 The remainder of the processing described in this section is P108L26 not performed on this message, the UAC processing rules P108L27 described in Section 8.1.3 are followed instead (transport P108L28 layer processing has already occurred). P108L29 P108L30 This will happen, for instance, when the element generates P108L31 CANCEL requests as described in Section 10. P108L32 P108L33 4. Add response to context P108L34 P108L35 Final responses received are stored in the response context P108L36 until a final response is generated on the server transaction P108L37 associated with this context. The response may be a candidate P108L38 for the best final response to be returned on that server P108L39 transaction. Information from this response may be needed in P108L40 forming the best response, even if this response is not chosen. P108L41 P108L42 If the proxy chooses to recurse on any contacts in a 3xx P108L43 response by adding them to the target set, it MUST remove them P108L44 from the response before adding the response to the response P108L45 context. However, a proxy SHOULD NOT recurse to a non-SIPS URI P108L46 if the Request-URI of the original request was a SIPS URI. If P108L47 P108L48 P109L1 the proxy recurses on all of the contacts in a 3xx response, P109L2 the proxy SHOULD NOT add the resulting contactless response to P109L3 the response context. P109L4 P109L5 Removing the contact before adding the response to the response P109L6 context prevents the next element upstream from retrying a P109L7 location this proxy has already attempted. P109L8 P109L9 3xx responses may contain a mixture of SIP, SIPS, and non-SIP P109L10 URIs. A proxy may choose to recurse on the SIP and SIPS URIs P109L11 and place the remainder into the response context to be P109L12 returned, potentially in the final response. P109L13 P109L14 If a proxy receives a 416 (Unsupported URI Scheme) response to P109L15 a request whose Request-URI scheme was not SIP, but the scheme P109L16 in the original received request was SIP or SIPS (that is, the P109L17 proxy changed the scheme from SIP or SIPS to something else P109L18 when it proxied a request), the proxy SHOULD add a new URI to P109L19 the target set. This URI SHOULD be a SIP URI version of the P109L20 non-SIP URI that was just tried. In the case of the tel URL, P109L21 this is accomplished by placing the telephone-subscriber part P109L22 of the tel URL into the user part of the SIP URI, and setting P109L23 the hostpart to the domain where the prior request was sent. P109L24 See Section 19.1.6 for more detail on forming SIP URIs from tel P109L25 URLs. P109L26 P109L27 As with a 3xx response, if a proxy "recurses" on the 416 by P109L28 trying a SIP or SIPS URI instead, the 416 response SHOULD NOT P109L29 be added to the response context. P109L30 P109L31 5. Check response for forwarding P109L32 P109L33 Until a final response has been sent on the server transaction, P109L34 the following responses MUST be forwarded immediately: P109L35 P109L36 - Any provisional response other than 100 (Trying) P109L37 P109L38 - Any 2xx response P109L39 P109L40 If a 6xx response is received, it is not immediately forwarded, P109L41 but the stateful proxy SHOULD cancel all client pending P109L42 transactions as described in Section 10, and it MUST NOT create P109L43 any new branches in this context. P109L44 P109L45 This is a change from RFC 2543, which mandated that the proxy P109L46 was to forward the 6xx response immediately. For an INVITE P109L47 transaction, this approach had the problem that a 2xx response P109L48 could arrive on another branch, in which case the proxy would P110L1 have to forward the 2xx. The result was that the UAC could P110L2 receive a 6xx response followed by a 2xx response, which should P110L3 never be allowed to happen. Under the new rules, upon P110L4 receiving a 6xx, a proxy will issue a CANCEL request, which P110L5 will generally result in 487 responses from all outstanding P110L6 client transactions, and then at that point the 6xx is P110L7 forwarded upstream. P110L8 P110L9 After a final response has been sent on the server transaction, P110L10 the following responses MUST be forwarded immediately: P110L11 P110L12 - Any 2xx response to an INVITE request P110L13 P110L14 A stateful proxy MUST NOT immediately forward any other P110L15 responses. In particular, a stateful proxy MUST NOT forward P110L16 any 100 (Trying) response. Those responses that are candidates P110L17 for forwarding later as the "best" response have been gathered P110L18 as described in step "Add Response to Context". P110L19 P110L20 Any response chosen for immediate forwarding MUST be processed P110L21 as described in steps "Aggregate Authorization Header Field P110L22 Values" through "Record-Route". P110L23 P110L24 This step, combined with the next, ensures that a stateful P110L25 proxy will forward exactly one final response to a non-INVITE P110L26 request, and either exactly one non-2xx response or one or more P110L27 2xx responses to an INVITE request. P110L28 P110L29 6. Choosing the best response P110L30 P110L31 A stateful proxy MUST send a final response to a response P110L32 context's server transaction if no final responses have been P110L33 immediately forwarded by the above rules and all client P110L34 transactions in this response context have been terminated. P110L35 P110L36 The stateful proxy MUST choose the "best" final response among P110L37 those received and stored in the response context. P110L38 P110L39 If there are no final responses in the context, the proxy MUST P110L40 send a 408 (Request Timeout) response to the server P110L41 transaction. P110L42 P110L43 Otherwise, the proxy MUST forward a response from the responses P110L44 stored in the response context. It MUST choose from the 6xx P110L45 class responses if any exist in the context. If no 6xx class P110L46 responses are present, the proxy SHOULD choose from the lowest P110L47 response class stored in the response context. The proxy MAY P110L48 select any response within that chosen class. The proxy SHOULD P111L1 give preference to responses that provide information affecting P111L2 resubmission of this request, such as 401, 407, 415, 420, and P111L3 484 if the 4xx class is chosen. P111L4 P111L5 A proxy which receives a 503 (Service Unavailable) response P111L6 SHOULD NOT forward it upstream unless it can determine that any P111L7 subsequent requests it might proxy will also generate a 503. P111L8 In other words, forwarding a 503 means that the proxy knows it P111L9 cannot service any requests, not just the one for the Request- P111L10 URI in the request which generated the 503. If the only P111L11 response that was received is a 503, the proxy SHOULD generate P111L12 a 500 response and forward that upstream. P111L13 P111L14 The forwarded response MUST be processed as described in steps P111L15 "Aggregate Authorization Header Field Values" through "Record- P111L16 Route". P111L17 P111L18 For example, if a proxy forwarded a request to 4 locations, and P111L19 received 503, 407, 501, and 404 responses, it may choose to P111L20 forward the 407 (Proxy Authentication Required) response. P111L21 P111L22 1xx and 2xx responses may be involved in the establishment of P111L23 dialogs. When a request does not contain a To tag, the To tag P111L24 in the response is used by the UAC to distinguish multiple P111L25 responses to a dialog creating request. A proxy MUST NOT P111L26 insert a tag into the To header field of a 1xx or 2xx response P111L27 if the request did not contain one. A proxy MUST NOT modify P111L28 the tag in the To header field of a 1xx or 2xx response. P111L29 P111L30 Since a proxy may not insert a tag into the To header field of P111L31 a 1xx response to a request that did not contain one, it cannot P111L32 issue non-100 provisional responses on its own. However, it P111L33 can branch the request to a UAS sharing the same element as the P111L34 proxy. This UAS can return its own provisional responses, P111L35 entering into an early dialog with the initiator of the P111L36 request. The UAS does not have to be a discreet process from P111L37 the proxy. It could be a virtual UAS implemented in the same P111L38 code space as the proxy. P111L39 P111L40 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx P111L41 response, the element is effectively acting as a UAS, issuing P111L42 its own response, usually based on the responses received from P111L43 downstream elements. An element SHOULD preserve the To tag P111L44 when simply forwarding a 3-6xx response to a request that did P111L45 not contain a To tag. P111L46 P111L47 A proxy MUST NOT modify the To tag in any forwarded response to P111L48 a request that contains a To tag. P112L1 While it makes no difference to the upstream elements if the P112L2 proxy replaced the To tag in a forwarded 3-6xx response, P112L3 preserving the original tag may assist with debugging. P112L4 P112L5 When the proxy is aggregating information from several P112L6 responses, choosing a To tag from among them is arbitrary, and P112L7 generating a new To tag may make debugging easier. This P112L8 happens, for instance, when combining 401 (Unauthorized) and P112L9 407 (Proxy Authentication Required) challenges, or combining P112L10 Contact values from unencrypted and unauthenticated 3xx P112L11 responses. P112L12 P112L13 7. Aggregate Authorization Header Field Values P112L14 P112L15 If the selected response is a 401 (Unauthorized) or 407 (Proxy P112L16 Authentication Required), the proxy MUST collect any WWW- P112L17 Authenticate and Proxy-Authenticate header field values from P112L18 all other 401 (Unauthorized) and 407 (Proxy Authentication P112L19 Required) responses received so far in this response context P112L20 and add them to this response without modification before P112L21 forwarding. The resulting 401 (Unauthorized) or 407 (Proxy P112L22 Authentication Required) response could have several WWW- P112L23 Authenticate AND Proxy-Authenticate header field values. P112L24 P112L25 This is necessary because any or all of the destinations the P112L26 request was forwarded to may have requested credentials. The P112L27 client needs to receive all of those challenges and supply P112L28 credentials for each of them when it retries the request. P112L29 Motivation for this behavior is provided in Section 26. P112L30 P112L31 8. Record-Route P112L32 P112L33 If the selected response contains a Record-Route header field P112L34 value originally provided by this proxy, the proxy MAY choose P112L35 to rewrite the value before forwarding the response. This P112L36 allows the proxy to provide different URIs for itself to the P112L37 next upstream and downstream elements. A proxy may choose to P112L38 use this mechanism for any reason. For instance, it is useful P112L39 for multi-homed hosts. P112L40 P112L41 If the proxy received the request over TLS, and sent it out P112L42 over a non-TLS connection, the proxy MUST rewrite the URI in P112L43 the Record-Route header field to be a SIPS URI. If the proxy P112L44 received the request over a non-TLS connection, and sent it out P112L45 over TLS, the proxy MUST rewrite the URI in the Record-Route P112L46 header field to be a SIP URI. P112L47 P112L48 P113L1 The new URI provided by the proxy MUST satisfy the same P113L2 constraints on URIs placed in Record-Route header fields in P113L3 requests (see Step 4 of Section 16.6) with the following P113L4 modifications: P113L5 P113L6 The URI SHOULD NOT contain the transport parameter unless the P113L7 proxy has knowledge that the next upstream (as opposed to P113L8 downstream) element that will be in the path of subsequent P113L9 requests supports that transport. P113L10 P113L11 When a proxy does decide to modify the Record-Route header P113L12 field in the response, one of the operations it performs is P113L13 locating the Record-Route value that it had inserted. If the P113L14 request spiraled, and the proxy inserted a Record-Route value P113L15 in each iteration of the spiral, locating the correct value in P113L16 the response (which must be the proper iteration in the reverse P113L17 direction) is tricky. The rules above recommend that a proxy P113L18 wishing to rewrite Record-Route header field values insert P113L19 sufficiently distinct URIs into the Record-Route header field P113L20 so that the right one may be selected for rewriting. A P113L21 RECOMMENDED mechanism to achieve this is for the proxy to P113L22 append a unique identifier for the proxy instance to the user P113L23 portion of the URI. P113L24 P113L25 When the response arrives, the proxy modifies the first P113L26 Record-Route whose identifier matches the proxy instance. The P113L27 modification results in a URI without this piece of data P113L28 appended to the user portion of the URI. Upon the next P113L29 iteration, the same algorithm (find the topmost Record-Route P113L30 header field value with the parameter) will correctly extract P113L31 the next Record-Route header field value inserted by that P113L32 proxy. P113L33 P113L34 Not every response to a request to which a proxy adds a P113L35 Record-Route header field value will contain a Record-Route P113L36 header field. If the response does contain a Record-Route P113L37 header field, it will contain the value the proxy added. P113L38 P113L39 9. Forward response P113L40 P113L41 After performing the processing described in steps "Aggregate P113L42 Authorization Header Field Values" through "Record-Route", the P113L43 proxy MAY perform any feature specific manipulations on the P113L44 selected response. The proxy MUST NOT add to, modify, or P113L45 remove the message body. Unless otherwise specified, the proxy P113L46 MUST NOT remove any header field values other than the Via P113L47 header field value discussed in Section 16.7 Item 3. In P113L48 particular, the proxy MUST NOT remove any "received" parameter P114L1 it may have added to the next Via header field value while P114L2 processing the request associated with this response. The P114L3 proxy MUST pass the response to the server transaction P114L4 associated with the response context. This will result in the P114L5 response being sent to the location now indicated in the P114L6 topmost Via header field value. If the server transaction is P114L7 no longer available to handle the transmission, the element P114L8 MUST forward the response statelessly by sending it to the P114L9 server transport. The server transaction might indicate P114L10 failure to send the response or signal a timeout in its state P114L11 machine. These errors would be logged for diagnostic purposes P114L12 as appropriate, but the protocol requires no remedial action P114L13 from the proxy. P114L14 P114L15 The proxy MUST maintain the response context until all of its P114L16 associated transactions have been terminated, even after P114L17 forwarding a final response. P114L18 P114L19 10. Generate CANCELs P114L20 P114L21 If the forwarded response was a final response, the proxy MUST P114L22 generate a CANCEL request for all pending client transactions P114L23 associated with this response context. A proxy SHOULD also P114L24 generate a CANCEL request for all pending client transactions P114L25 associated with this response context when it receives a 6xx P114L26 response. A pending client transaction is one that has P114L27 received a provisional response, but no final response (it is P114L28 in the proceeding state) and has not had an associated CANCEL P114L29 generated for it. Generating CANCEL requests is described in P114L30 Section 9.1. P114L31 P114L32 The requirement to CANCEL pending client transactions upon P114L33 forwarding a final response does not guarantee that an endpoint P114L34 will not receive multiple 200 (OK) responses to an INVITE. 200 P114L35 (OK) responses on more than one branch may be generated before P114L36 the CANCEL requests can be sent and processed. Further, it is P114L37 reasonable to expect that a future extension may override this P114L38 requirement to issue CANCEL requests. P114L39 P114L40 16.8 Processing Timer C P114L41 P114L42 If timer C should fire, the proxy MUST either reset the timer with P114L43 any value it chooses, or terminate the client transaction. If the P114L44 client transaction has received a provisional response, the proxy P114L45 MUST generate a CANCEL request matching that transaction. If the P114L46 client transaction has not received a provisional response, the proxy P114L47 MUST behave as if the transaction received a 408 (Request Timeout) P114L48 response. P115L1 Allowing the proxy to reset the timer allows the proxy to dynamically P115L2 extend the transaction's lifetime based on current conditions (such P115L3 as utilization) when the timer fires. P115L4 P115L5 16.9 Handling Transport Errors P115L6 P115L7 If the transport layer notifies a proxy of an error when it tries to P115L8 forward a request (see Section 18.4), the proxy MUST behave as if the P115L9 forwarded request received a 503 (Service Unavailable) response. P115L10 P115L11 If the proxy is notified of an error when forwarding a response, it P115L12 drops the response. The proxy SHOULD NOT cancel any outstanding P115L13 client transactions associated with this response context due to this P115L14 notification. P115L15 P115L16 If a proxy cancels its outstanding client transactions, a single P115L17 malicious or misbehaving client can cause all transactions to fail P115L18 through its Via header field. P115L19 P115L20 16.10 CANCEL Processing P115L21 P115L22 A stateful proxy MAY generate a CANCEL to any other request it has P115L23 generated at any time (subject to receiving a provisional response to P115L24 that request as described in section 9.1). A proxy MUST cancel any P115L25 pending client transactions associated with a response context when P115L26 it receives a matching CANCEL request. P115L27 P115L28 A stateful proxy MAY generate CANCEL requests for pending INVITE P115L29 client transactions based on the period specified in the INVITE's P115L30 Expires header field elapsing. However, this is generally P115L31 unnecessary since the endpoints involved will take care of signaling P115L32 the end of the transaction. P115L33 P115L34 While a CANCEL request is handled in a stateful proxy by its own P115L35 server transaction, a new response context is not created for it. P115L36 Instead, the proxy layer searches its existing response contexts for P115L37 the server transaction handling the request associated with this P115L38 CANCEL. If a matching response context is found, the element MUST P115L39 immediately return a 200 (OK) response to the CANCEL request. In P115L40 this case, the element is acting as a user agent server as defined in P115L41 Section 8.2. Furthermore, the element MUST generate CANCEL requests P115L42 for all pending client transactions in the context as described in P115L43 Section 16.7 step 10. P115L44 P115L45 If a response context is not found, the element does not have any P115L46 knowledge of the request to apply the CANCEL to. It MUST statelessly P115L47 forward the CANCEL request (it may have statelessly forwarded the P115L48 associated request previously). P116L1 16.11 Stateless Proxy P116L2 P116L3 When acting statelessly, a proxy is a simple message forwarder. Much P116L4 of the processing performed when acting statelessly is the same as P116L5 when behaving statefully. The differences are detailed here. P116L6 P116L7 A stateless proxy does not have any notion of a transaction, or of P116L8 the response context used to describe stateful proxy behavior. P116L9 Instead, the stateless proxy takes messages, both requests and P116L10 responses, directly from the transport layer (See section 18). As a P116L11 result, stateless proxies do not retransmit messages on their own. P116L12 They do, however, forward all retransmissions they receive (they do P116L13 not have the ability to distinguish a retransmission from the P116L14 original message). Furthermore, when handling a request statelessly, P116L15 an element MUST NOT generate its own 100 (Trying) or any other P116L16 provisional response. P116L17 P116L18 A stateless proxy MUST validate a request as described in Section P116L19 16.3 P116L20 P116L21 A stateless proxy MUST follow the request processing steps described P116L22 in Sections 16.4 through 16.5 with the following exception: P116L23 P116L24 o A stateless proxy MUST choose one and only one target from the P116L25 target set. This choice MUST only rely on fields in the P116L26 message and time-invariant properties of the server. In P116L27 particular, a retransmitted request MUST be forwarded to the P116L28 same destination each time it is processed. Furthermore, P116L29 CANCEL and non-Routed ACK requests MUST generate the same P116L30 choice as their associated INVITE. P116L31 P116L32 A stateless proxy MUST follow the request processing steps described P116L33 in Section 16.6 with the following exceptions: P116L34 P116L35 o The requirement for unique branch IDs across space and time P116L36 applies to stateless proxies as well. However, a stateless P116L37 proxy cannot simply use a random number generator to compute P116L38 the first component of the branch ID, as described in Section P116L39 16.6 bullet 8. This is because retransmissions of a request P116L40 need to have the same value, and a stateless proxy cannot tell P116L41 a retransmission from the original request. Therefore, the P116L42 component of the branch parameter that makes it unique MUST be P116L43 the same each time a retransmitted request is forwarded. Thus P116L44 for a stateless proxy, the branch parameter MUST be computed as P116L45 a combinatoric function of message parameters which are P116L46 invariant on retransmission. P116L47 P116L48 P117L1 The stateless proxy MAY use any technique it likes to guarantee P117L2 uniqueness of its branch IDs across transactions. However, the P117L3 following procedure is RECOMMENDED. The proxy examines the P117L4 branch ID in the topmost Via header field of the received P117L5 request. If it begins with the magic cookie, the first P117L6 component of the branch ID of the outgoing request is computed P117L7 as a hash of the received branch ID. Otherwise, the first P117L8 component of the branch ID is computed as a hash of the topmost P117L9 Via, the tag in the To header field, the tag in the From header P117L10 field, the Call-ID header field, the CSeq number (but not P117L11 method), and the Request-URI from the received request. One of P117L12 these fields will always vary across two different P117L13 transactions. P117L14 P117L15 o All other message transformations specified in Section 16.6 P117L16 MUST result in the same transformation of a retransmitted P117L17 request. In particular, if the proxy inserts a Record-Route P117L18 value or pushes URIs into the Route header field, it MUST place P117L19 the same values in retransmissions of the request. As for the P117L20 Via branch parameter, this implies that the transformations P117L21 MUST be based on time-invariant configuration or P117L22 retransmission-invariant properties of the request. P117L23 P117L24 o A stateless proxy determines where to forward the request as P117L25 described for stateful proxies in Section 16.6 Item 10. The P117L26 request is sent directly to the transport layer instead of P117L27 through a client transaction. P117L28 P117L29 Since a stateless proxy must forward retransmitted requests to P117L30 the same destination and add identical branch parameters to P117L31 each of them, it can only use information from the message P117L32 itself and time-invariant configuration data for those P117L33 calculations. If the configuration state is not time-invariant P117L34 (for example, if a routing table is updated) any requests that P117L35 could be affected by the change may not be forwarded P117L36 statelessly during an interval equal to the transaction timeout P117L37 window before or after the change. The method of processing P117L38 the affected requests in that interval is an implementation P117L39 decision. A common solution is to forward them transaction P117L40 statefully. P117L41 P117L42 Stateless proxies MUST NOT perform special processing for CANCEL P117L43 requests. They are processed by the above rules as any other P117L44 requests. In particular, a stateless proxy applies the same Route P117L45 header field processing to CANCEL requests that it applies to any P117L46 other request. P117L47 P117L48 P118L1 Response processing as described in Section 16.7 does not apply to a P118L2 proxy behaving statelessly. When a response arrives at a stateless P118L3 proxy, the proxy MUST inspect the sent-by value in the first P118L4 (topmost) Via header field value. If that address matches the proxy, P118L5 (it equals a value this proxy has inserted into previous requests) P118L6 the proxy MUST remove that header field value from the response and P118L7 forward the result to the location indicated in the next Via header P118L8 field value. The proxy MUST NOT add to, modify, or remove the P118L9 message body. Unless specified otherwise, the proxy MUST NOT remove P118L10 any other header field values. If the address does not match the P118L11 proxy, the message MUST be silently discarded. P118L12 P118L13 16.12 Summary of Proxy Route Processing P118L14 P118L15 In the absence of local policy to the contrary, the processing a P118L16 proxy performs on a request containing a Route header field can be P118L17 summarized in the following steps. P118L18 P118L19 1. The proxy will inspect the Request-URI. If it indicates a P118L20 resource owned by this proxy, the proxy will replace it with P118L21 the results of running a location service. Otherwise, the P118L22 proxy will not change the Request-URI. P118L23 P118L24 2. The proxy will inspect the URI in the topmost Route header P118L25 field value. If it indicates this proxy, the proxy removes it P118L26 from the Route header field (this route node has been P118L27 reached). P118L28 P118L29 3. The proxy will forward the request to the resource indicated P118L30 by the URI in the topmost Route header field value or in the P118L31 Request-URI if no Route header field is present. The proxy P118L32 determines the address, port and transport to use when P118L33 forwarding the request by applying the procedures in [4] to P118L34 that URI. P118L35 P118L36 If no strict-routing elements are encountered on the path of the P118L37 request, the Request-URI will always indicate the target of the P118L38 request. P118L39 P118L40 16.12.1 Examples P118L41 P118L42 16.12.1.1 Basic SIP Trapezoid P118L43 P118L44 This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with P118L45 both proxies record-routing. Here is the flow. P118L46 P118L47 P118L48 P119L1 U1 sends: P119L2 P119L3 INVITE sip:callee@domain.com SIP/2.0 P119L4 Contact: sip:caller@u1.example.com P119L5 P119L6 to P1. P1 is an outbound proxy. P1 is not responsible for P119L7 domain.com, so it looks it up in DNS and sends it there. It also P119L8 adds a Record-Route header field value: P119L9 P119L10 INVITE sip:callee@domain.com SIP/2.0 P119L11 Contact: sip:caller@u1.example.com P119L12 Record-Route: P119L13 P119L14 P2 gets this. It is responsible for domain.com so it runs a location P119L15 service and rewrites the Request-URI. It also adds a Record-Route P119L16 header field value. There is no Route header field, so it resolves P119L17 the new Request-URI to determine where to send the request: P119L18 P119L19 INVITE sip:callee@u2.domain.com SIP/2.0 P119L20 Contact: sip:caller@u1.example.com P119L21 Record-Route: P119L22 Record-Route: P119L23 P119L24 The callee at u2.domain.com gets this and responds with a 200 OK: P119L25 P119L26 SIP/2.0 200 OK P119L27 Contact: sip:callee@u2.domain.com P119L28 Record-Route: P119L29 Record-Route: P119L30 P119L31 The callee at u2 also sets its dialog state's remote target URI to P119L32 sip:caller@u1.example.com and its route set to: P119L33 P119L34 (,) P119L35 P119L36 This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its P119L37 dialog state's remote target URI to sip:callee@u2.domain.com and its P119L38 route set to: P119L39 P119L40 (,) P119L41 P119L42 Since all the route set elements contain the lr parameter, U1 P119L43 constructs the following BYE request: P119L44 P119L45 BYE sip:callee@u2.domain.com SIP/2.0 P119L46 Route: , P119L47 P119L48 P120L1 As any other element (including proxies) would do, it resolves the P120L2 URI in the topmost Route header field value using DNS to determine P120L3 where to send the request. This goes to P1. P1 notices that it is P120L4 not responsible for the resource indicated in the Request-URI so it P120L5 doesn't change it. It does see that it is the first value in the P120L6 Route header field, so it removes that value, and forwards the P120L7 request to P2: P120L8 P120L9 BYE sip:callee@u2.domain.com SIP/2.0 P120L10 Route: P120L11 P120L12 P2 also notices it is not responsible for the resource indicated by P120L13 the Request-URI (it is responsible for domain.com, not P120L14 u2.domain.com), so it doesn't change it. It does see itself in the P120L15 first Route header field value, so it removes it and forwards the P120L16 following to u2.domain.com based on a DNS lookup against the P120L17 Request-URI: P120L18 P120L19 BYE sip:callee@u2.domain.com SIP/2.0 P120L20 P120L21 16.12.1.2 Traversing a Strict-Routing Proxy P120L22 P120L23 In this scenario, a dialog is established across four proxies, each P120L24 of which adds Record-Route header field values. The third proxy P120L25 implements the strict-routing procedures specified in RFC 2543 and P120L26 many works in progress. P120L27 P120L28 U1->P1->P2->P3->P4->U2 P120L29 P120L30 The INVITE arriving at U2 contains: P120L31 P120L32 INVITE sip:callee@u2.domain.com SIP/2.0 P120L33 Contact: sip:caller@u1.example.com P120L34 Record-Route: P120L35 Record-Route: P120L36 Record-Route: P120L37 Record-Route: P120L38 P120L39 Which U2 responds to with a 200 OK. Later, U2 sends the following P120L40 BYE request to P4 based on the first Route header field value. P120L41 P120L42 BYE sip:caller@u1.example.com SIP/2.0 P120L43 Route: P120L44 Route: P120L45 Route: P120L46 Route: P120L47 P120L48 P121L1 P4 is not responsible for the resource indicated in the Request-URI P121L2 so it will leave it alone. It notices that it is the element in the P121L3 first Route header field value so it removes it. It then prepares to P121L4 send the request based on the now first Route header field value of P121L5 sip:p3.middle.com, but it notices that this URI does not contain the P121L6 lr parameter, so before sending, it reformats the request to be: P121L7 P121L8 BYE sip:p3.middle.com SIP/2.0 P121L9 Route: P121L10 Route: P121L11 Route: P121L12 P121L13 P3 is a strict router, so it forwards the following to P2: P121L14 P121L15 BYE sip:p2.example.com;lr SIP/2.0 P121L16 Route: P121L17 Route: P121L18 P121L19 P2 sees the request-URI is a value it placed into a Record-Route P121L20 header field, so before further processing, it rewrites the request P121L21 to be: P121L22 P121L23 BYE sip:caller@u1.example.com SIP/2.0 P121L24 Route: P121L25 P121L26 P2 is not responsible for u1.example.com, so it sends the request to P121L27 P1 based on the resolution of the Route header field value. P121L28 P121L29 P1 notices itself in the topmost Route header field value, so it P121L30 removes it, resulting in: P121L31 P121L32 BYE sip:caller@u1.example.com SIP/2.0 P121L33 P121L34 Since P1 is not responsible for u1.example.com and there is no Route P121L35 header field, P1 will forward the request to u1.example.com based on P121L36 the Request-URI. P121L37 P121L38 16.12.1.3 Rewriting Record-Route Header Field Values P121L39 P121L40 In this scenario, U1 and U2 are in different private namespaces and P121L41 they enter a dialog through a proxy P1, which acts as a gateway P121L42 between the namespaces. P121L43 P121L44 U1->P1->U2 P121L45 P121L46 P121L47 P121L48 P122L1 U1 sends: P122L2 P122L3 INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 P122L4 Contact: P122L5 P122L6 P1 uses its location service and sends the following to U2: P122L7 P122L8 INVITE sip:callee@rightprivatespace.com SIP/2.0 P122L9 Contact: P122L10 Record-Route: P122L11 P122L12 U2 sends this 200 (OK) back to P1: P122L13 P122L14 SIP/2.0 200 OK P122L15 Contact: P122L16 Record-Route: P122L17 P122L18 P1 rewrites its Record-Route header parameter to provide a value that P122L19 U1 will find useful, and sends the following to U1: P122L20 P122L21 SIP/2.0 200 OK P122L22 Contact: P122L23 Record-Route: P122L24 P122L25 Later, U1 sends the following BYE request to P1: P122L26 P122L27 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 P122L28 Route: P122L29 P122L30 which P1 forwards to U2 as: P122L31 P122L32 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 P122L33 P122L34 17 Transactions P122L35 P122L36 SIP is a transactional protocol: interactions between components take P122L37 place in a series of independent message exchanges. Specifically, a P122L38 SIP transaction consists of a single request and any responses to P122L39 that request, which include zero or more provisional responses and P122L40 one or more final responses. In the case of a transaction where the P122L41 request was an INVITE (known as an INVITE transaction), the P122L42 transaction also includes the ACK only if the final response was not P122L43 a 2xx response. If the response was a 2xx, the ACK is not considered P122L44 part of the transaction. P122L45 P122L46 The reason for this separation is rooted in the importance of P122L47 delivering all 200 (OK) responses to an INVITE to the UAC. To P122L48 deliver them all to the UAC, the UAS alone takes responsibility P123L1 for retransmitting them (see Section 13.3.1.4), and the UAC alone P123L2 takes responsibility for acknowledging them with ACK (see Section P123L3 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is P123L4 effectively considered its own transaction. P123L5 P123L6 Transactions have a client side and a server side. The client side P123L7 is known as a client transaction and the server side as a server P123L8 transaction. The client transaction sends the request, and the P123L9 server transaction sends the response. The client and server P123L10 transactions are logical functions that are embedded in any number of P123L11 elements. Specifically, they exist within user agents and stateful P123L12 proxy servers. Consider the example in Section 4. In this example, P123L13 the UAC executes the client transaction, and its outbound proxy P123L14 executes the server transaction. The outbound proxy also executes a P123L15 client transaction, which sends the request to a server transaction P123L16 in the inbound proxy. That proxy also executes a client transaction, P123L17 which in turn sends the request to a server transaction in the UAS. P123L18 This is shown in Figure 4. P123L19 P123L20 +---------+ +---------+ +---------+ +---------+ P123L21 | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | P123L22 | |C||------->||S| |C||------->||S| |C||------->||S| | P123L23 | |l|| ||e| |l|| ||e| |l|| ||e| | P123L24 | |i|| ||r| |i|| ||r| |i|| ||r| | P123L25 | |e|| ||v| |e|| ||v| |e|| ||v| | P123L26 | |n|| ||e| |n|| ||e| |n|| ||e| | P123L27 | |t|| ||r| |t|| ||r| |t|| ||r| | P123L28 | | || || | | || || | | || || | | P123L29 | |T|| ||T| |T|| ||T| |T|| ||T| | P123L30 | |r|| ||r| |r|| ||r| |r|| ||r| | P123L31 | |a|| ||a| |a|| ||a| |a|| ||a| | P123L32 | |n|| ||n| |n|| ||n| |n|| ||n| | P123L33 | |s||Response||s| |s||Response||s| |s||Response||s| | P123L34 | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | P123L35 +---------+ +---------+ +---------+ +---------+ P123L36 UAC Outbound Inbound UAS P123L37 Proxy Proxy P123L38 P123L39 Figure 4: Transaction relationships P123L40 P123L41 A stateless proxy does not contain a client or server transaction. P123L42 The transaction exists between the UA or stateful proxy on one side, P123L43 and the UA or stateful proxy on the other side. As far as SIP P123L44 transactions are concerned, stateless proxies are effectively P123L45 transparent. The purpose of the client transaction is to receive a P123L46 request from the element in which the client is embedded (call this P123L47 element the "Transaction User" or TU; it can be a UA or a stateful P123L48 proxy), and reliably deliver the request to a server transaction. P124L1 The client transaction is also responsible for receiving responses P124L2 and delivering them to the TU, filtering out any response P124L3 retransmissions or disallowed responses (such as a response to ACK). P124L4 Additionally, in the case of an INVITE request, the client P124L5 transaction is responsible for generating the ACK request for any P124L6 final response accepting a 2xx response. P124L7 P124L8 Similarly, the purpose of the server transaction is to receive P124L9 requests from the transport layer and deliver them to the TU. The P124L10 server transaction filters any request retransmissions from the P124L11 network. The server transaction accepts responses from the TU and P124L12 delivers them to the transport layer for transmission over the P124L13 network. In the case of an INVITE transaction, it absorbs the ACK P124L14 request for any final response excepting a 2xx response. P124L15 P124L16 The 2xx response and its ACK receive special treatment. This P124L17 response is retransmitted only by a UAS, and its ACK generated only P124L18 by the UAC. This end-to-end treatment is needed so that a caller P124L19 knows the entire set of users that have accepted the call. Because P124L20 of this special handling, retransmissions of the 2xx response are P124L21 handled by the UA core, not the transaction layer. Similarly, P124L22 generation of the ACK for the 2xx is handled by the UA core. Each P124L23 proxy along the path merely forwards each 2xx response to INVITE and P124L24 its corresponding ACK. P124L25 P124L26 17.1 Client Transaction P124L27 P124L28 The client transaction provides its functionality through the P124L29 maintenance of a state machine. P124L30 P124L31 The TU communicates with the client transaction through a simple P124L32 interface. When the TU wishes to initiate a new transaction, it P124L33 creates a client transaction and passes it the SIP request to send P124L34 and an IP address, port, and transport to which to send it. The P124L35 client transaction begins execution of its state machine. Valid P124L36 responses are passed up to the TU from the client transaction. P124L37 P124L38 There are two types of client transaction state machines, depending P124L39 on the method of the request passed by the TU. One handles client P124L40 transactions for INVITE requests. This type of machine is referred P124L41 to as an INVITE client transaction. Another type handles client P124L42 transactions for all requests except INVITE and ACK. This is P124L43 referred to as a non-INVITE client transaction. There is no client P124L44 transaction for ACK. If the TU wishes to send an ACK, it passes one P124L45 directly to the transport layer for transmission. P124L46 P124L47 P124L48 P125L1 The INVITE transaction is different from those of other methods P125L2 because of its extended duration. Normally, human input is required P125L3 in order to respond to an INVITE. The long delays expected for P125L4 sending a response argue for a three-way handshake. On the other P125L5 hand, requests of other methods are expected to complete rapidly. P125L6 Because of the non-INVITE transaction's reliance on a two-way P125L7 handshake, TUs SHOULD respond immediately to non-INVITE requests. P125L8 P125L9 17.1.1 INVITE Client Transaction P125L10 P125L11 17.1.1.1 Overview of INVITE Transaction P125L12 P125L13 The INVITE transaction consists of a three-way handshake. The client P125L14 transaction sends an INVITE, the server transaction sends responses, P125L15 and the client transaction sends an ACK. For unreliable transports P125L16 (such as UDP), the client transaction retransmits requests at an P125L17 interval that starts at T1 seconds and doubles after every P125L18 retransmission. T1 is an estimate of the round-trip time (RTT), and P125L19 it defaults to 500 ms. Nearly all of the transaction timers P125L20 described here scale with T1, and changing T1 adjusts their values. P125L21 The request is not retransmitted over reliable transports. After P125L22 receiving a 1xx response, any retransmissions cease altogether, and P125L23 the client waits for further responses. The server transaction can P125L24 send additional 1xx responses, which are not transmitted reliably by P125L25 the server transaction. Eventually, the server transaction decides P125L26 to send a final response. For unreliable transports, that response P125L27 is retransmitted periodically, and for reliable transports, it is P125L28 sent once. For each final response that is received at the client P125L29 transaction, the client transaction sends an ACK, the purpose of P125L30 which is to quench retransmissions of the response. P125L31 P125L32 17.1.1.2 Formal Description P125L33 P125L34 The state machine for the INVITE client transaction is shown in P125L35 Figure 5. The initial state, "calling", MUST be entered when the TU P125L36 initiates a new client transaction with an INVITE request. The P125L37 client transaction MUST pass the request to the transport layer for P125L38 transmission (see Section 18). If an unreliable transport is being P125L39 used, the client transaction MUST start timer A with a value of T1. P125L40 If a reliable transport is being used, the client transaction SHOULD P125L41 NOT start timer A (Timer A controls request retransmissions). For P125L42 any transport, the client transaction MUST start timer B with a value P125L43 of 64*T1 seconds (Timer B controls transaction timeouts). P125L44 P125L45 When timer A fires, the client transaction MUST retransmit the P125L46 request by passing it to the transport layer, and MUST reset the P125L47 timer with a value of 2*T1. The formal definition of retransmit P125L48 P126L1 within the context of the transaction layer is to take the message P126L2 previously sent to the transport layer and pass it to the transport P126L3 layer once more. P126L4 P126L5 When timer A fires 2*T1 seconds later, the request MUST be P126L6 retransmitted again (assuming the client transaction is still in this P126L7 state). This process MUST continue so that the request is P126L8 retransmitted with intervals that double after each transmission. P126L9 These retransmissions SHOULD only be done while the client P126L10 transaction is in the "calling" state. P126L11 P126L12 The default value for T1 is 500 ms. T1 is an estimate of the RTT P126L13 between the client and server transactions. Elements MAY (though it P126L14 is NOT RECOMMENDED) use smaller values of T1 within closed, private P126L15 networks that do not permit general Internet connection. T1 MAY be P126L16 chosen larger, and this is RECOMMENDED if it is known in advance P126L17 (such as on high latency access links) that the RTT is larger. P126L18 Whatever the value of T1, the exponential backoffs on retransmissions P126L19 described in this section MUST be used. P126L20 P126L21 If the client transaction is still in the "Calling" state when timer P126L22 B fires, the client transaction SHOULD inform the TU that a timeout P126L23 has occurred. The client transaction MUST NOT generate an ACK. The P126L24 value of 64*T1 is equal to the amount of time required to send seven P126L25 requests in the case of an unreliable transport. P126L26 P126L27 If the client transaction receives a provisional response while in P126L28 the "Calling" state, it transitions to the "Proceeding" state. In the P126L29 "Proceeding" state, the client transaction SHOULD NOT retransmit the P126L30 request any longer. Furthermore, the provisional response MUST be P126L31 passed to the TU. Any further provisional responses MUST be passed P126L32 up to the TU while in the "Proceeding" state. P126L33 P126L34 When in either the "Calling" or "Proceeding" states, reception of a P126L35 response with status code from 300-699 MUST cause the client P126L36 transaction to transition to "Completed". The client transaction P126L37 MUST pass the received response up to the TU, and the client P126L38 transaction MUST generate an ACK request, even if the transport is P126L39 reliable (guidelines for constructing the ACK from the response are P126L40 given in Section 17.1.1.3) and then pass the ACK to the transport P126L41 layer for transmission. The ACK MUST be sent to the same address, P126L42 port, and transport to which the original request was sent. The P126L43 client transaction SHOULD start timer D when it enters the P126L44 "Completed" state, with a value of at least 32 seconds for unreliable P126L45 transports, and a value of zero seconds for reliable transports. P126L46 Timer D reflects the amount of time that the server transaction can P126L47 remain in the "Completed" state when unreliable transports are used. P126L48 This is equal to Timer H in the INVITE server transaction, whose P127L1 default is 64*T1. However, the client transaction does not know the P127L2 value of T1 in use by the server transaction, so an absolute minimum P127L3 of 32s is used instead of basing Timer D on T1. P127L4 P127L5 Any retransmissions of the final response that are received while in P127L6 the "Completed" state MUST cause the ACK to be re-passed to the P127L7 transport layer for retransmission, but the newly received response P127L8 MUST NOT be passed up to the TU. A retransmission of the response is P127L9 defined as any response which would match the same client transaction P127L10 based on the rules of Section 17.1.3. P127L11 P127L12 P127L13 P127L14 P127L15 P127L16 P127L17 P127L18 P127L19 P127L20 P127L21 P127L22 P127L23 P127L24 P127L25 P127L26 P127L27 P127L28 P127L29 P127L30 P127L31 P127L32 P127L33 P127L34 P127L35 P127L36 P127L37 P127L38 P127L39 P127L40 P127L41 P127L42 P127L43 P127L44 P127L45 P127L46 P127L47 P127L48 P128L1 |INVITE from TU P128L2 Timer A fires |INVITE sent P128L3 Reset A, V Timer B fires P128L4 INVITE sent +-----------+ or Transport Err. P128L5 +---------| |---------------+inform TU P128L6 | | Calling | | P128L7 +-------->| |-------------->| P128L8 +-----------+ 2xx | P128L9 | | 2xx to TU | P128L10 | |1xx | P128L11 300-699 +---------------+ |1xx to TU | P128L12 ACK sent | | | P128L13 resp. to TU | 1xx V | P128L14 | 1xx to TU -----------+ | P128L15 | +---------| | | P128L16 | | |Proceeding |-------------->| P128L17 | +-------->| | 2xx | P128L18 | +-----------+ 2xx to TU | P128L19 | 300-699 | | P128L20 | ACK sent, | | P128L21 | resp. to TU| | P128L22 | | | NOTE: P128L23 | 300-699 V | P128L24 | ACK sent +-----------+Transport Err. | transitions P128L25 | +---------| |Inform TU | labeled with P128L26 | | | Completed |-------------->| the event P128L27 | +-------->| | | over the action P128L28 | +-----------+ | to take P128L29 | ^ | | P128L30 | | | Timer D fires | P128L31 +--------------+ | - | P128L32 | | P128L33 V | P128L34 +-----------+ | P128L35 | | | P128L36 | Terminated|<--------------+ P128L37 | | P128L38 +-----------+ P128L39 P128L40 Figure 5: INVITE client transaction P128L41 P128L42 If timer D fires while the client transaction is in the "Completed" P128L43 state, the client transaction MUST move to the terminated state. P128L44 P128L45 When in either the "Calling" or "Proceeding" states, reception of a P128L46 2xx response MUST cause the client transaction to enter the P128L47 "Terminated" state, and the response MUST be passed up to the TU. P128L48 The handling of this response depends on whether the TU is a proxy P129L1 core or a UAC core. A UAC core will handle generation of the ACK for P129L2 this response, while a proxy core will always forward the 200 (OK) P129L3 upstream. The differing treatment of 200 (OK) between proxy and UAC P129L4 is the reason that handling of it does not take place in the P129L5 transaction layer. P129L6 P129L7 The client transaction MUST be destroyed the instant it enters the P129L8 "Terminated" state. This is actually necessary to guarantee correct P129L9 operation. The reason is that 2xx responses to an INVITE are treated P129L10 differently; each one is forwarded by proxies, and the ACK handling P129L11 in a UAC is different. Thus, each 2xx needs to be passed to a proxy P129L12 core (so that it can be forwarded) and to a UAC core (so it can be P129L13 acknowledged). No transaction layer processing takes place. P129L14 Whenever a response is received by the transport, if the transport P129L15 layer finds no matching client transaction (using the rules of P129L16 Section 17.1.3), the response is passed directly to the core. Since P129L17 the matching client transaction is destroyed by the first 2xx, P129L18 subsequent 2xx will find no match and therefore be passed to the P129L19 core. P129L20 P129L21 17.1.1.3 Construction of the ACK Request P129L22 P129L23 This section specifies the construction of ACK requests sent within P129L24 the client transaction. A UAC core that generates an ACK for 2xx P129L25 MUST instead follow the rules described in Section 13. P129L26 P129L27 The ACK request constructed by the client transaction MUST contain P129L28 values for the Call-ID, From, and Request-URI that are equal to the P129L29 values of those header fields in the request passed to the transport P129L30 by the client transaction (call this the "original request"). The To P129L31 header field in the ACK MUST equal the To header field in the P129L32 response being acknowledged, and therefore will usually differ from P129L33 the To header field in the original request by the addition of the P129L34 tag parameter. The ACK MUST contain a single Via header field, and P129L35 this MUST be equal to the top Via header field of the original P129L36 request. The CSeq header field in the ACK MUST contain the same P129L37 value for the sequence number as was present in the original request, P129L38 but the method parameter MUST be equal to "ACK". P129L39 P129L40 P129L41 P129L42 P129L43 P129L44 P129L45 P129L46 P129L47 P129L48 P130L1 If the INVITE request whose response is being acknowledged had Route P130L2 header fields, those header fields MUST appear in the ACK. This is P130L3 to ensure that the ACK can be routed properly through any downstream P130L4 stateless proxies. P130L5 P130L6 Although any request MAY contain a body, a body in an ACK is special P130L7 since the request cannot be rejected if the body is not understood. P130L8 Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, P130L9 but if done, the body types are restricted to any that appeared in P130L10 the INVITE, assuming that the response to the INVITE was not 415. If P130L11 it was, the body in the ACK MAY be any type listed in the Accept P130L12 header field in the 415. P130L13 P130L14 For example, consider the following request: P130L15 P130L16 INVITE sip:bob@biloxi.com SIP/2.0 P130L17 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff P130L18 To: Bob P130L19 From: Alice ;tag=88sja8x P130L20 Max-Forwards: 70 P130L21 Call-ID: 987asjd97y7atg P130L22 CSeq: 986759 INVITE P130L23 P130L24 The ACK request for a non-2xx final response to this request would P130L25 look like this: P130L26 P130L27 ACK sip:bob@biloxi.com SIP/2.0 P130L28 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff P130L29 To: Bob ;tag=99sa0xk P130L30 From: Alice ;tag=88sja8x P130L31 Max-Forwards: 70 P130L32 Call-ID: 987asjd97y7atg P130L33 CSeq: 986759 ACK P130L34 P130L35 17.1.2 Non-INVITE Client Transaction P130L36 P130L37 17.1.2.1 Overview of the non-INVITE Transaction P130L38 P130L39 Non-INVITE transactions do not make use of ACK. They are simple P130L40 request-response interactions. For unreliable transports, requests P130L41 are retransmitted at an interval which starts at T1 and doubles until P130L42 it hits T2. If a provisional response is received, retransmissions P130L43 continue for unreliable transports, but at an interval of T2. The P130L44 server transaction retransmits the last response it sent, which can P130L45 be a provisional or final response, only when a retransmission of the P130L46 request is received. This is why request retransmissions need to P130L47 continue even after a provisional response; they are to ensure P130L48 reliable delivery of the final response. P131L1 Unlike an INVITE transaction, a non-INVITE transaction has no special P131L2 handling for the 2xx response. The result is that only a single 2xx P131L3 response to a non-INVITE is ever delivered to a UAC. P131L4 P131L5 17.1.2.2 Formal Description P131L6 P131L7 The state machine for the non-INVITE client transaction is shown in P131L8 Figure 6. It is very similar to the state machine for INVITE. P131L9 P131L10 The "Trying" state is entered when the TU initiates a new client P131L11 transaction with a request. When entering this state, the client P131L12 transaction SHOULD set timer F to fire in 64*T1 seconds. The request P131L13 MUST be passed to the transport layer for transmission. If an P131L14 unreliable transport is in use, the client transaction MUST set timer P131L15 E to fire in T1 seconds. If timer E fires while still in this state, P131L16 the timer is reset, but this time with a value of MIN(2*T1, T2). P131L17 When the timer fires again, it is reset to a MIN(4*T1, T2). This P131L18 process continues so that retransmissions occur with an exponentially P131L19 increasing interval that caps at T2. The default value of T2 is 4s, P131L20 and it represents the amount of time a non-INVITE server transaction P131L21 will take to respond to a request, if it does not respond P131L22 immediately. For the default values of T1 and T2, this results in P131L23 intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. P131L24 P131L25 If Timer F fires while the client transaction is still in the P131L26 "Trying" state, the client transaction SHOULD inform the TU about the P131L27 timeout, and then it SHOULD enter the "Terminated" state. If a P131L28 provisional response is received while in the "Trying" state, the P131L29 response MUST be passed to the TU, and then the client transaction P131L30 SHOULD move to the "Proceeding" state. If a final response (status P131L31 codes 200-699) is received while in the "Trying" state, the response P131L32 MUST be passed to the TU, and the client transaction MUST transition P131L33 to the "Completed" state. P131L34 P131L35 If Timer E fires while in the "Proceeding" state, the request MUST be P131L36 passed to the transport layer for retransmission, and Timer E MUST be P131L37 reset with a value of T2 seconds. If timer F fires while in the P131L38 "Proceeding" state, the TU MUST be informed of a timeout, and the P131L39 client transaction MUST transition to the terminated state. If a P131L40 final response (status codes 200-699) is received while in the P131L41 "Proceeding" state, the response MUST be passed to the TU, and the P131L42 client transaction MUST transition to the "Completed" state. P131L43 P131L44 Once the client transaction enters the "Completed" state, it MUST set P131L45 Timer K to fire in T4 seconds for unreliable transports, and zero P131L46 seconds for reliable transports. The "Completed" state exists to P131L47 buffer any additional response retransmissions that may be received P131L48 (which is why the client transaction remains there only for P132L1 unreliable transports). T4 represents the amount of time the network P132L2 will take to clear messages between client and server transactions. P132L3 The default value of T4 is 5s. A response is a retransmission when P132L4 it matches the same transaction, using the rules specified in Section P132L5 17.1.3. If Timer K fires while in this state, the client transaction P132L6 MUST transition to the "Terminated" state. P132L7 P132L8 Once the transaction is in the terminated state, it MUST be destroyed P132L9 immediately. P132L10 P132L11 17.1.3 Matching Responses to Client Transactions P132L12 P132L13 When the transport layer in the client receives a response, it has to P132L14 determine which client transaction will handle the response, so that P132L15 the processing of Sections 17.1.1 and 17.1.2 can take place. The P132L16 branch parameter in the top Via header field is used for this P132L17 purpose. A response matches a client transaction under two P132L18 conditions: P132L19 P132L20 1. If the response has the same value of the branch parameter in P132L21 the top Via header field as the branch parameter in the top P132L22 Via header field of the request that created the transaction. P132L23 P132L24 2. If the method parameter in the CSeq header field matches the P132L25 method of the request that created the transaction. The P132L26 method is needed since a CANCEL request constitutes a P132L27 different transaction, but shares the same value of the branch P132L28 parameter. P132L29 P132L30 If a request is sent via multicast, it is possible that it will P132L31 generate multiple responses from different servers. These responses P132L32 will all have the same branch parameter in the topmost Via, but vary P132L33 in the To tag. The first response received, based on the rules P132L34 above, will be used, and others will be viewed as retransmissions. P132L35 That is not an error; multicast SIP provides only a rudimentary P132L36 "single-hop-discovery-like" service that is limited to processing a P132L37 single response. See Section 18.1.1 for details. P132L38 P132L39 P132L40 P132L41 P132L42 P132L43 P132L44 P132L45 P132L46 P132L47 P132L48 P133L1 17.1.4 Handling Transport Errors P133L2 P133L3 |Request from TU P133L4 |send request P133L5 Timer E V P133L6 send request +-----------+ P133L7 +---------| |-------------------+ P133L8 | | Trying | Timer F | P133L9 +-------->| | or Transport Err.| P133L10 +-----------+ inform TU | P133L11 200-699 | | | P133L12 resp. to TU | |1xx | P133L13 +---------------+ |resp. to TU | P133L14 | | | P133L15 | Timer E V Timer F | P133L16 | send req +-----------+ or Transport Err. | P133L17 | +---------| | inform TU | P133L18 | | |Proceeding |------------------>| P133L19 | +-------->| |-----+ | P133L20 | +-----------+ |1xx | P133L21 | | ^ |resp to TU | P133L22 | 200-699 | +--------+ | P133L23 | resp. to TU | | P133L24 | | | P133L25 | V | P133L26 | +-----------+ | P133L27 | | | | P133L28 | | Completed | | P133L29 | | | | P133L30 | +-----------+ | P133L31 | ^ | | P133L32 | | | Timer K | P133L33 +--------------+ | - | P133L34 | | P133L35 V | P133L36 NOTE: +-----------+ | P133L37 | | | P133L38 transitions | Terminated|<------------------+ P133L39 labeled with | | P133L40 the event +-----------+ P133L41 over the action P133L42 to take P133L43 P133L44 Figure 6: non-INVITE client transaction P133L45 P133L46 When the client transaction sends a request to the transport layer to P133L47 be sent, the following procedures are followed if the transport layer P133L48 indicates a failure. P134L1 The client transaction SHOULD inform the TU that a transport failure P134L2 has occurred, and the client transaction SHOULD transition directly P134L3 to the "Terminated" state. The TU will handle the failover P134L4 mechanisms described in [4]. P134L5 P134L6 17.2 Server Transaction P134L7 P134L8 The server transaction is responsible for the delivery of requests to P134L9 the TU and the reliable transmission of responses. It accomplishes P134L10 this through a state machine. Server transactions are created by the P134L11 core when a request is received, and transaction handling is desired P134L12 for that request (this is not always the case). P134L13 P134L14 As with the client transactions, the state machine depends on whether P134L15 the received request is an INVITE request. P134L16 P134L17 17.2.1 INVITE Server Transaction P134L18 P134L19 The state diagram for the INVITE server transaction is shown in P134L20 Figure 7. P134L21 P134L22 When a server transaction is constructed for a request, it enters the P134L23 "Proceeding" state. The server transaction MUST generate a 100 P134L24 (Trying) response unless it knows that the TU will generate a P134L25 provisional or final response within 200 ms, in which case it MAY P134L26 generate a 100 (Trying) response. This provisional response is P134L27 needed to quench request retransmissions rapidly in order to avoid P134L28 network congestion. The 100 (Trying) response is constructed P134L29 according to the procedures in Section 8.2.6, except that the P134L30 insertion of tags in the To header field of the response (when none P134L31 was present in the request) is downgraded from MAY to SHOULD NOT. P134L32 The request MUST be passed to the TU. P134L33 P134L34 The TU passes any number of provisional responses to the server P134L35 transaction. So long as the server transaction is in the P134L36 "Proceeding" state, each of these MUST be passed to the transport P134L37 layer for transmission. They are not sent reliably by the P134L38 transaction layer (they are not retransmitted by it) and do not cause P134L39 a change in the state of the server transaction. If a request P134L40 retransmission is received while in the "Proceeding" state, the most P134L41 recent provisional response that was received from the TU MUST be P134L42 passed to the transport layer for retransmission. A request is a P134L43 retransmission if it matches the same server transaction based on the P134L44 rules of Section 17.2.3. P134L45 P134L46 If, while in the "Proceeding" state, the TU passes a 2xx response to P134L47 the server transaction, the server transaction MUST pass this P134L48 response to the transport layer for transmission. It is not P135L1 retransmitted by the server transaction; retransmissions of 2xx P135L2 responses are handled by the TU. The server transaction MUST then P135L3 transition to the "Terminated" state. P135L4 P135L5 While in the "Proceeding" state, if the TU passes a response with P135L6 status code from 300 to 699 to the server transaction, the response P135L7 MUST be passed to the transport layer for transmission, and the state P135L8 machine MUST enter the "Completed" state. For unreliable transports, P135L9 timer G is set to fire in T1 seconds, and is not set to fire for P135L10 reliable transports. P135L11 P135L12 This is a change from RFC 2543, where responses were always P135L13 retransmitted, even over reliable transports. P135L14 P135L15 When the "Completed" state is entered, timer H MUST be set to fire in P135L16 64*T1 seconds for all transports. Timer H determines when the server P135L17 transaction abandons retransmitting the response. Its value is P135L18 chosen to equal Timer B, the amount of time a client transaction will P135L19 continue to retry sending a request. If timer G fires, the response P135L20 is passed to the transport layer once more for retransmission, and P135L21 timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when P135L22 timer G fires, the response is passed to the transport again for P135L23 transmission, and timer G is reset with a value that doubles, unless P135L24 that value exceeds T2, in which case it is reset with the value of P135L25 T2. This is identical to the retransmit behavior for requests in the P135L26 "Trying" state of the non-INVITE client transaction. Furthermore, P135L27 while in the "Completed" state, if a request retransmission is P135L28 received, the server SHOULD pass the response to the transport for P135L29 retransmission. P135L30 P135L31 If an ACK is received while the server transaction is in the P135L32 "Completed" state, the server transaction MUST transition to the P135L33 "Confirmed" state. As Timer G is ignored in this state, any P135L34 retransmissions of the response will cease. P135L35 P135L36 If timer H fires while in the "Completed" state, it implies that the P135L37 ACK was never received. In this case, the server transaction MUST P135L38 transition to the "Terminated" state, and MUST indicate to the TU P135L39 that a transaction failure has occurred. P135L40 P135L41 P135L42 P135L43 P135L44 P135L45 P135L46 P135L47 P135L48 P136L1 |INVITE P136L2 |pass INV to TU P136L3 INVITE V send 100 if TU won't in 200ms P136L4 send response+-----------+ P136L5 +--------| |--------+101-199 from TU P136L6 | | Proceeding| |send response P136L7 +------->| |<-------+ P136L8 | | Transport Err. P136L9 | | Inform TU P136L10 | |--------------->+ P136L11 +-----------+ | P136L12 300-699 from TU | |2xx from TU | P136L13 send response | |send response | P136L14 | +------------------>+ P136L15 | | P136L16 INVITE V Timer G fires | P136L17 send response+-----------+ send response | P136L18 +--------| |--------+ | P136L19 | | Completed | | | P136L20 +------->| |<-------+ | P136L21 +-----------+ | P136L22 | | | P136L23 ACK | | | P136L24 - | +------------------>+ P136L25 | Timer H fires | P136L26 V or Transport Err.| P136L27 +-----------+ Inform TU | P136L28 | | | P136L29 | Confirmed | | P136L30 | | | P136L31 +-----------+ | P136L32 | | P136L33 |Timer I fires | P136L34 |- | P136L35 | | P136L36 V | P136L37 +-----------+ | P136L38 | | | P136L39 | Terminated|<---------------+ P136L40 | | P136L41 +-----------+ P136L42 P136L43 Figure 7: INVITE server transaction P136L44 P136L45 P136L46 P136L47 P136L48 P137L1 The purpose of the "Confirmed" state is to absorb any additional ACK P137L2 messages that arrive, triggered from retransmissions of the final P137L3 response. When this state is entered, timer I is set to fire in T4 P137L4 seconds for unreliable transports, and zero seconds for reliable P137L5 transports. Once timer I fires, the server MUST transition to the P137L6 "Terminated" state. P137L7 P137L8 Once the transaction is in the "Terminated" state, it MUST be P137L9 destroyed immediately. As with client transactions, this is needed P137L10 to ensure reliability of the 2xx responses to INVITE. P137L11 P137L12 17.2.2 Non-INVITE Server Transaction P137L13 P137L14 The state machine for the non-INVITE server transaction is shown in P137L15 Figure 8. P137L16 P137L17 The state machine is initialized in the "Trying" state and is passed P137L18 a request other than INVITE or ACK when initialized. This request is P137L19 passed up to the TU. Once in the "Trying" state, any further request P137L20 retransmissions are discarded. A request is a retransmission if it P137L21 matches the same server transaction, using the rules specified in P137L22 Section 17.2.3. P137L23 P137L24 While in the "Trying" state, if the TU passes a provisional response P137L25 to the server transaction, the server transaction MUST enter the P137L26 "Proceeding" state. The response MUST be passed to the transport P137L27 layer for transmission. Any further provisional responses that are P137L28 received from the TU while in the "Proceeding" state MUST be passed P137L29 to the transport layer for transmission. If a retransmission of the P137L30 request is received while in the "Proceeding" state, the most P137L31 recently sent provisional response MUST be passed to the transport P137L32 layer for retransmission. If the TU passes a final response (status P137L33 codes 200-699) to the server while in the "Proceeding" state, the P137L34 transaction MUST enter the "Completed" state, and the response MUST P137L35 be passed to the transport layer for transmission. P137L36 P137L37 When the server transaction enters the "Completed" state, it MUST set P137L38 Timer J to fire in 64*T1 seconds for unreliable transports, and zero P137L39 seconds for reliable transports. While in the "Completed" state, the P137L40 server transaction MUST pass the final response to the transport P137L41 layer for retransmission whenever a retransmission of the request is P137L42 received. Any other final responses passed by the TU to the server P137L43 transaction MUST be discarded while in the "Completed" state. The P137L44 server transaction remains in this state until Timer J fires, at P137L45 which point it MUST transition to the "Terminated" state. P137L46 P137L47 The server transaction MUST be destroyed the instant it enters the P137L48 "Terminated" state. P138L1 17.2.3 Matching Requests to Server Transactions P138L2 P138L3 When a request is received from the network by the server, it has to P138L4 be matched to an existing transaction. This is accomplished in the P138L5 following manner. P138L6 P138L7 The branch parameter in the topmost Via header field of the request P138L8 is examined. If it is present and begins with the magic cookie P138L9 "z9hG4bK", the request was generated by a client transaction P138L10 compliant to this specification. Therefore, the branch parameter P138L11 will be unique across all transactions sent by that client. The P138L12 request matches a transaction if: P138L13 P138L14 1. the branch parameter in the request is equal to the one in the P138L15 top Via header field of the request that created the P138L16 transaction, and P138L17 P138L18 2. the sent-by value in the top Via of the request is equal to the P138L19 one in the request that created the transaction, and P138L20 P138L21 3. the method of the request matches the one that created the P138L22 transaction, except for ACK, where the method of the request P138L23 that created the transaction is INVITE. P138L24 P138L25 This matching rule applies to both INVITE and non-INVITE transactions P138L26 alike. P138L27 P138L28 The sent-by value is used as part of the matching process because P138L29 there could be accidental or malicious duplication of branch P138L30 parameters from different clients. P138L31 P138L32 If the branch parameter in the top Via header field is not present, P138L33 or does not contain the magic cookie, the following procedures are P138L34 used. These exist to handle backwards compatibility with RFC 2543 P138L35 compliant implementations. P138L36 P138L37 The INVITE request matches a transaction if the Request-URI, To tag, P138L38 From tag, Call-ID, CSeq, and top Via header field match those of the P138L39 INVITE request which created the transaction. In this case, the P138L40 INVITE is a retransmission of the original one that created the P138L41 transaction. The ACK request matches a transaction if the Request- P138L42 URI, From tag, Call-ID, CSeq number (not the method), and top Via P138L43 header field match those of the INVITE request which created the P138L44 transaction, and the To tag of the ACK matches the To tag of the P138L45 response sent by the server transaction. Matching is done based on P138L46 the matching rules defined for each of those header fields. P138L47 Inclusion of the tag in the To header field in the ACK matching P138L48 process helps disambiguate ACK for 2xx from ACK for other responses P139L1 at a proxy, which may have forwarded both responses (This can occur P139L2 in unusual conditions. Specifically, when a proxy forked a request, P139L3 and then crashes, the responses may be delivered to another proxy, P139L4 which might end up forwarding multiple responses upstream). An ACK P139L5 request that matches an INVITE transaction matched by a previous ACK P139L6 is considered a retransmission of that previous ACK. P139L7 P139L8 P139L9 P139L10 P139L11 P139L12 P139L13 P139L14 P139L15 P139L16 P139L17 P139L18 P139L19 P139L20 P139L21 P139L22 P139L23 P139L24 P139L25 P139L26 P139L27 P139L28 P139L29 P139L30 P139L31 P139L32 P139L33 P139L34 P139L35 P139L36 P139L37 P139L38 P139L39 P139L40 P139L41 P139L42 P139L43 P139L44 P139L45 P139L46 P139L47 P139L48 P140L1 |Request received P140L2 |pass to TU P140L3 V P140L4 +-----------+ P140L5 | | P140L6 | Trying |-------------+ P140L7 | | | P140L8 +-----------+ |200-699 from TU P140L9 | |send response P140L10 |1xx from TU | P140L11 |send response | P140L12 | | P140L13 Request V 1xx from TU | P140L14 send response+-----------+send response| P140L15 +--------| |--------+ | P140L16 | | Proceeding| | | P140L17 +------->| |<-------+ | P140L18 +<--------------| | | P140L19 |Trnsprt Err +-----------+ | P140L20 |Inform TU | | P140L21 | | | P140L22 | |200-699 from TU | P140L23 | |send response | P140L24 | Request V | P140L25 | send response+-----------+ | P140L26 | +--------| | | P140L27 | | | Completed |<------------+ P140L28 | +------->| | P140L29 +<--------------| | P140L30 |Trnsprt Err +-----------+ P140L31 |Inform TU | P140L32 | |Timer J fires P140L33 | |- P140L34 | | P140L35 | V P140L36 | +-----------+ P140L37 | | | P140L38 +-------------->| Terminated| P140L39 | | P140L40 +-----------+ P140L41 P140L42 Figure 8: non-INVITE server transaction P140L43 P140L44 For all other request methods, a request is matched to a transaction P140L45 if the Request-URI, To tag, From tag, Call-ID, CSeq (including the P140L46 method), and top Via header field match those of the request that P140L47 created the transaction. Matching is done based on the matching P140L48 P141L1 rules defined for each of those header fields. When a non-INVITE P141L2 request matches an existing transaction, it is a retransmission of P141L3 the request that created that transaction. P141L4 P141L5 Because the matching rules include the Request-URI, the server cannot P141L6 match a response to a transaction. When the TU passes a response to P141L7 the server transaction, it must pass it to the specific server P141L8 transaction for which the response is targeted. P141L9 P141L10 17.2.4 Handling Transport Errors P141L11 P141L12 When the server transaction sends a response to the transport layer P141L13 to be sent, the following procedures are followed if the transport P141L14 layer indicates a failure. P141L15 P141L16 First, the procedures in [4] are followed, which attempt to deliver P141L17 the response to a backup. If those should all fail, based on the P141L18 definition of failure in [4], the server transaction SHOULD inform P141L19 the TU that a failure has occurred, and SHOULD transition to the P141L20 terminated state. P141L21 P141L22 18 Transport P141L23 P141L24 The transport layer is responsible for the actual transmission of P141L25 requests and responses over network transports. This includes P141L26 determination of the connection to use for a request or response in P141L27 the case of connection-oriented transports. P141L28 P141L29 The transport layer is responsible for managing persistent P141L30 connections for transport protocols like TCP and SCTP, or TLS over P141L31 those, including ones opened to the transport layer. This includes P141L32 connections opened by the client or server transports, so that P141L33 connections are shared between client and server transport functions. P141L34 These connections are indexed by the tuple formed from the address, P141L35 port, and transport protocol at the far end of the connection. When P141L36 a connection is opened by the transport layer, this index is set to P141L37 the destination IP, port and transport. When the connection is P141L38 accepted by the transport layer, this index is set to the source IP P141L39 address, port number, and transport. Note that, because the source P141L40 port is often ephemeral, but it cannot be known whether it is P141L41 ephemeral or selected through procedures in [4], connections accepted P141L42 by the transport layer will frequently not be reused. The result is P141L43 that two proxies in a "peering" relationship using a connection- P141L44 oriented transport frequently will have two connections in use, one P141L45 for transactions initiated in each direction. P141L46 P141L47 P141L48 P142L1 It is RECOMMENDED that connections be kept open for some P142L2 implementation-defined duration after the last message was sent or P142L3 received over that connection. This duration SHOULD at least equal P142L4 the longest amount of time the element would need in order to bring a P142L5 transaction from instantiation to the terminated state. This is to P142L6 make it likely that transactions are completed over the same P142L7 connection on which they are initiated (for example, request, P142L8 response, and in the case of INVITE, ACK for non-2xx responses). P142L9 This usually means at least 64*T1 (see Section 17.1.1.1 for a P142L10 definition of T1). However, it could be larger in an element that P142L11 has a TU using a large value for timer C (bullet 11 of Section 16.6), P142L12 for example. P142L13 P142L14 All SIP elements MUST implement UDP and TCP. SIP elements MAY P142L15 implement other protocols. P142L16 P142L17 Making TCP mandatory for the UA is a substantial change from RFC P142L18 2543. It has arisen out of the need to handle larger messages, P142L19 which MUST use TCP, as discussed below. Thus, even if an element P142L20 never sends large messages, it may receive one and needs to be P142L21 able to handle them. P142L22 P142L23 18.1 Clients P142L24 P142L25 18.1.1 Sending Requests P142L26 P142L27 The client side of the transport layer is responsible for sending the P142L28 request and receiving responses. The user of the transport layer P142L29 passes the client transport the request, an IP address, port, P142L30 transport, and possibly TTL for multicast destinations. P142L31 P142L32 If a request is within 200 bytes of the path MTU, or if it is larger P142L33 than 1300 bytes and the path MTU is unknown, the request MUST be sent P142L34 using an RFC 2914 [43] congestion controlled transport protocol, such P142L35 as TCP. If this causes a change in the transport protocol from the P142L36 one indicated in the top Via, the value in the top Via MUST be P142L37 changed. This prevents fragmentation of messages over UDP and P142L38 provides congestion control for larger messages. However, P142L39 implementations MUST be able to handle messages up to the maximum P142L40 datagram packet size. For UDP, this size is 65,535 bytes, including P142L41 IP and UDP headers. P142L42 P142L43 The 200 byte "buffer" between the message size and the MTU P142L44 accommodates the fact that the response in SIP can be larger than P142L45 the request. This happens due to the addition of Record-Route P142L46 header field values to the responses to INVITE, for example. With P142L47 the extra buffer, the response can be about 170 bytes larger than P142L48 the request, and still not be fragmented on IPv4 (about 30 bytes P143L1 is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when P143L2 path MTU is not known, based on the assumption of a 1500 byte P143L3 Ethernet MTU. P143L4 P143L5 If an element sends a request over TCP because of these message size P143L6 constraints, and that request would have otherwise been sent over P143L7 UDP, if the attempt to establish the connection generates either an P143L8 ICMP Protocol Not Supported, or results in a TCP reset, the element P143L9 SHOULD retry the request, using UDP. This is only to provide P143L10 backwards compatibility with RFC 2543 compliant implementations that P143L11 do not support TCP. It is anticipated that this behavior will be P143L12 deprecated in a future revision of this specification. P143L13 P143L14 A client that sends a request to a multicast address MUST add the P143L15 "maddr" parameter to its Via header field value containing the P143L16 destination multicast address, and for IPv4, SHOULD add the "ttl" P143L17 parameter with a value of 1. Usage of IPv6 multicast is not defined P143L18 in this specification, and will be a subject of future P143L19 standardization when the need arises. P143L20 P143L21 These rules result in a purposeful limitation of multicast in SIP. P143L22 Its primary function is to provide a "single-hop-discovery-like" P143L23 service, delivering a request to a group of homogeneous servers, P143L24 where it is only required to process the response from any one of P143L25 them. This functionality is most useful for registrations. In fact, P143L26 based on the transaction processing rules in Section 17.1.3, the P143L27 client transaction will accept the first response, and view any P143L28 others as retransmissions because they all contain the same Via P143L29 branch identifier. P143L30 P143L31 Before a request is sent, the client transport MUST insert a value of P143L32 the "sent-by" field into the Via header field. This field contains P143L33 an IP address or host name, and port. The usage of an FQDN is P143L34 RECOMMENDED. This field is used for sending responses under certain P143L35 conditions, described below. If the port is absent, the default P143L36 value depends on the transport. It is 5060 for UDP, TCP and SCTP, P143L37 5061 for TLS. P143L38 P143L39 For reliable transports, the response is normally sent on the P143L40 connection on which the request was received. Therefore, the client P143L41 transport MUST be prepared to receive the response on the same P143L42 connection used to send the request. Under error conditions, the P143L43 server may attempt to open a new connection to send the response. To P143L44 handle this case, the transport layer MUST also be prepared to P143L45 receive an incoming connection on the source IP address from which P143L46 the request was sent and port number in the "sent-by" field. It also P143L47 P143L48 P144L1 MUST be prepared to receive incoming connections on any address and P144L2 port that would be selected by a server based on the procedures P144L3 described in Section 5 of [4]. P144L4 P144L5 For unreliable unicast transports, the client transport MUST be P144L6 prepared to receive responses on the source IP address from which the P144L7 request is sent (as responses are sent back to the source address) P144L8 and the port number in the "sent-by" field. Furthermore, as with P144L9 reliable transports, in certain cases the response will be sent P144L10 elsewhere. The client MUST be prepared to receive responses on any P144L11 address and port that would be selected by a server based on the P144L12 procedures described in Section 5 of [4]. P144L13 P144L14 For multicast, the client transport MUST be prepared to receive P144L15 responses on the same multicast group and port to which the request P144L16 is sent (that is, it needs to be a member of the multicast group it P144L17 sent the request to.) P144L18 P144L19 If a request is destined to an IP address, port, and transport to P144L20 which an existing connection is open, it is RECOMMENDED that this P144L21 connection be used to send the request, but another connection MAY be P144L22 opened and used. P144L23 P144L24 If a request is sent using multicast, it is sent to the group P144L25 address, port, and TTL provided by the transport user. If a request P144L26 is sent using unicast unreliable transports, it is sent to the IP P144L27 address and port provided by the transport user. P144L28 P144L29 18.1.2 Receiving Responses P144L30 P144L31 When a response is received, the client transport examines the top P144L32 Via header field value. If the value of the "sent-by" parameter in P144L33 that header field value does not correspond to a value that the P144L34 client transport is configured to insert into requests, the response P144L35 MUST be silently discarded. P144L36 P144L37 If there are any client transactions in existence, the client P144L38 transport uses the matching procedures of Section 17.1.3 to attempt P144L39 to match the response to an existing transaction. If there is a P144L40 match, the response MUST be passed to that transaction. Otherwise, P144L41 the response MUST be passed to the core (whether it be stateless P144L42 proxy, stateful proxy, or UA) for further processing. Handling of P144L43 these "stray" responses is dependent on the core (a proxy will P144L44 forward them, while a UA will discard, for example). P144L45 P144L46 P144L47 P144L48 P145L1 18.2 Servers P145L2 P145L3 18.2.1 Receiving Requests P145L4 P145L5 A server SHOULD be prepared to receive requests on any IP address, P145L6 port and transport combination that can be the result of a DNS lookup P145L7 on a SIP or SIPS URI [4] that is handed out for the purposes of P145L8 communicating with that server. In this context, "handing out" P145L9 includes placing a URI in a Contact header field in a REGISTER P145L10 request or a redirect response, or in a Record-Route header field in P145L11 a request or response. A URI can also be "handed out" by placing it P145L12 on a web page or business card. It is also RECOMMENDED that a server P145L13 listen for requests on the default SIP ports (5060 for TCP and UDP, P145L14 5061 for TLS over TCP) on all public interfaces. The typical P145L15 exception would be private networks, or when multiple server P145L16 instances are running on the same host. For any port and interface P145L17 that a server listens on for UDP, it MUST listen on that same port P145L18 and interface for TCP. This is because a message may need to be sent P145L19 using TCP, rather than UDP, if it is too large. As a result, the P145L20 converse is not true. A server need not listen for UDP on a P145L21 particular address and port just because it is listening on that same P145L22 address and port for TCP. There may, of course, be other reasons why P145L23 a server needs to listen for UDP on a particular address and port. P145L24 P145L25 When the server transport receives a request over any transport, it P145L26 MUST examine the value of the "sent-by" parameter in the top Via P145L27 header field value. If the host portion of the "sent-by" parameter P145L28 contains a domain name, or if it contains an IP address that differs P145L29 from the packet source address, the server MUST add a "received" P145L30 parameter to that Via header field value. This parameter MUST P145L31 contain the source address from which the packet was received. This P145L32 is to assist the server transport layer in sending the response, P145L33 since it must be sent to the source IP address from which the request P145L34 came. P145L35 P145L36 Consider a request received by the server transport which looks like, P145L37 in part: P145L38 P145L39 INVITE sip:bob@Biloxi.com SIP/2.0 P145L40 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 P145L41 P145L42 The request is received with a source IP address of 192.0.2.4. P145L43 Before passing the request up, the transport adds a "received" P145L44 parameter, so that the request would look like, in part: P145L45 P145L46 INVITE sip:bob@Biloxi.com SIP/2.0 P145L47 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 P145L48 P146L1 Next, the server transport attempts to match the request to a server P146L2 transaction. It does so using the matching rules described in P146L3 Section 17.2.3. If a matching server transaction is found, the P146L4 request is passed to that transaction for processing. If no match is P146L5 found, the request is passed to the core, which may decide to P146L6 construct a new server transaction for that request. Note that when P146L7 a UAS core sends a 2xx response to INVITE, the server transaction is P146L8 destroyed. This means that when the ACK arrives, there will be no P146L9 matching server transaction, and based on this rule, the ACK is P146L10 passed to the UAS core, where it is processed. P146L11 P146L12 18.2.2 Sending Responses P146L13 P146L14 The server transport uses the value of the top Via header field in P146L15 order to determine where to send a response. It MUST follow the P146L16 following process: P146L17 P146L18 o If the "sent-protocol" is a reliable transport protocol such as P146L19 TCP or SCTP, or TLS over those, the response MUST be sent using P146L20 the existing connection to the source of the original request P146L21 that created the transaction, if that connection is still open. P146L22 This requires the server transport to maintain an association P146L23 between server transactions and transport connections. If that P146L24 connection is no longer open, the server SHOULD open a P146L25 connection to the IP address in the "received" parameter, if P146L26 present, using the port in the "sent-by" value, or the default P146L27 port for that transport, if no port is specified. If that P146L28 connection attempt fails, the server SHOULD use the procedures P146L29 in [4] for servers in order to determine the IP address and P146L30 port to open the connection and send the response to. P146L31 P146L32 o Otherwise, if the Via header field value contains a "maddr" P146L33 parameter, the response MUST be forwarded to the address listed P146L34 there, using the port indicated in "sent-by", or port 5060 if P146L35 none is present. If the address is a multicast address, the P146L36 response SHOULD be sent using the TTL indicated in the "ttl" P146L37 parameter, or with a TTL of 1 if that parameter is not present. P146L38 P146L39 o Otherwise (for unreliable unicast transports), if the top Via P146L40 has a "received" parameter, the response MUST be sent to the P146L41 address in the "received" parameter, using the port indicated P146L42 in the "sent-by" value, or using port 5060 if none is specified P146L43 explicitly. If this fails, for example, elicits an ICMP "port P146L44 unreachable" response, the procedures of Section 5 of [4] P146L45 SHOULD be used to determine where to send the response. P146L46 P146L47 P146L48 P147L1 o Otherwise, if it is not receiver-tagged, the response MUST be P147L2 sent to the address indicated by the "sent-by" value, using the P147L3 procedures in Section 5 of [4]. P147L4 P147L5 18.3 Framing P147L6 P147L7 In the case of message-oriented transports (such as UDP), if the P147L8 message has a Content-Length header field, the message body is P147L9 assumed to contain that many bytes. If there are additional bytes in P147L10 the transport packet beyond the end of the body, they MUST be P147L11 discarded. If the transport packet ends before the end of the P147L12 message body, this is considered an error. If the message is a P147L13 response, it MUST be discarded. If the message is a request, the P147L14 element SHOULD generate a 400 (Bad Request) response. If the message P147L15 has no Content-Length header field, the message body is assumed to P147L16 end at the end of the transport packet. P147L17 P147L18 In the case of stream-oriented transports such as TCP, the Content- P147L19 Length header field indicates the size of the body. The Content- P147L20 Length header field MUST be used with stream oriented transports. P147L21 P147L22 18.4 Error Handling P147L23 P147L24 Error handling is independent of whether the message was a request or P147L25 response. P147L26 P147L27 If the transport user asks for a message to be sent over an P147L28 unreliable transport, and the result is an ICMP error, the behavior P147L29 depends on the type of ICMP error. Host, network, port or protocol P147L30 unreachable errors, or parameter problem errors SHOULD cause the P147L31 transport layer to inform the transport user of a failure in sending. P147L32 Source quench and TTL exceeded ICMP errors SHOULD be ignored. P147L33 P147L34 If the transport user asks for a request to be sent over a reliable P147L35 transport, and the result is a connection failure, the transport P147L36 layer SHOULD inform the transport user of a failure in sending. P147L37 P147L38 19 Common Message Components P147L39 P147L40 There are certain components of SIP messages that appear in various P147L41 places within SIP messages (and sometimes, outside of them) that P147L42 merit separate discussion. P147L43 P147L44 P147L45 P147L46 P147L47 P147L48 P148L1 19.1 SIP and SIPS Uniform Resource Indicators P148L2 P148L3 A SIP or SIPS URI identifies a communications resource. Like all P148L4 URIs, SIP and SIPS URIs may be placed in web pages, email messages, P148L5 or printed literature. They contain sufficient information to P148L6 initiate and maintain a communication session with the resource. P148L7 P148L8 Examples of communications resources include the following: P148L9 P148L10 o a user of an online service P148L11 P148L12 o an appearance on a multi-line phone P148L13 P148L14 o a mailbox on a messaging system P148L15 P148L16 o a PSTN number at a gateway service P148L17 P148L18 o a group (such as "sales" or "helpdesk") in an organization P148L19 P148L20 A SIPS URI specifies that the resource be contacted securely. This P148L21 means, in particular, that TLS is to be used between the UAC and the P148L22 domain that owns the URI. From there, secure communications are used P148L23 to reach the user, where the specific security mechanism depends on P148L24 the policy of the domain. Any resource described by a SIP URI can be P148L25 "upgraded" to a SIPS URI by just changing the scheme, if it is P148L26 desired to communicate with that resource securely. P148L27 P148L28 19.1.1 SIP and SIPS URI Components P148L29 P148L30 The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. P148L31 They use a form similar to the mailto URL, allowing the specification P148L32 of SIP request-header fields and the SIP message-body. This makes it P148L33 possible to specify the subject, media type, or urgency of sessions P148L34 initiated by using a URI on a web page or in an email message. The P148L35 formal syntax for a SIP or SIPS URI is presented in Section 25. Its P148L36 general form, in the case of a SIP URI, is: P148L37 P148L38 sip:user:password@host:port;uri-parameters?headers P148L39 P148L40 The format for a SIPS URI is the same, except that the scheme is P148L41 "sips" instead of sip. These tokens, and some of the tokens in their P148L42 expansions, have the following meanings: P148L43 P148L44 user: The identifier of a particular resource at the host being P148L45 addressed. The term "host" in this context frequently refers P148L46 to a domain. The "userinfo" of a URI consists of this user P148L47 field, the password field, and the @ sign following them. The P148L48 userinfo part of a URI is optional and MAY be absent when the P149L1 destination host does not have a notion of users or when the P149L2 host itself is the resource being identified. If the @ sign is P149L3 present in a SIP or SIPS URI, the user field MUST NOT be empty. P149L4 P149L5 If the host being addressed can process telephone numbers, for P149L6 instance, an Internet telephony gateway, a telephone- P149L7 subscriber field defined in RFC 2806 [9] MAY be used to P149L8 populate the user field. There are special escaping rules for P149L9 encoding telephone-subscriber fields in SIP and SIPS URIs P149L10 described in Section 19.1.2. P149L11 P149L12 password: A password associated with the user. While the SIP and P149L13 SIPS URI syntax allows this field to be present, its use is NOT P149L14 RECOMMENDED, because the passing of authentication information P149L15 in clear text (such as URIs) has proven to be a security risk P149L16 in almost every case where it has been used. For instance, P149L17 transporting a PIN number in this field exposes the PIN. P149L18 P149L19 Note that the password field is just an extension of the user P149L20 portion. Implementations not wishing to give special P149L21 significance to the password portion of the field MAY simply P149L22 treat "user:password" as a single string. P149L23 P149L24 host: The host providing the SIP resource. The host part contains P149L25 either a fully-qualified domain name or numeric IPv4 or IPv6 P149L26 address. Using the fully-qualified domain name form is P149L27 RECOMMENDED whenever possible. P149L28 P149L29 port: The port number where the request is to be sent. P149L30 P149L31 URI parameters: Parameters affecting a request constructed from P149L32 the URI. P149L33 P149L34 URI parameters are added after the hostport component and are P149L35 separated by semi-colons. P149L36 P149L37 URI parameters take the form: P149L38 P149L39 parameter-name "=" parameter-value P149L40 P149L41 Even though an arbitrary number of URI parameters may be P149L42 included in a URI, any given parameter-name MUST NOT appear P149L43 more than once. P149L44 P149L45 This extensible mechanism includes the transport, maddr, ttl, P149L46 user, method and lr parameters. P149L47 P149L48 P150L1 The transport parameter determines the transport mechanism to P150L2 be used for sending SIP messages, as specified in [4]. SIP can P150L3 use any network transport protocol. Parameter names are P150L4 defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP P150L5 (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST P150L6 indicate a reliable transport. P150L7 P150L8 The maddr parameter indicates the server address to be P150L9 contacted for this user, overriding any address derived from P150L10 the host field. When an maddr parameter is present, the port P150L11 and transport components of the URI apply to the address P150L12 indicated in the maddr parameter value. [4] describes the P150L13 proper interpretation of the transport, maddr, and hostport in P150L14 order to obtain the destination address, port, and transport P150L15 for sending a request. P150L16 P150L17 The maddr field has been used as a simple form of loose source P150L18 routing. It allows a URI to specify a proxy that must be P150L19 traversed en-route to the destination. Continuing to use the P150L20 maddr parameter this way is strongly discouraged (the P150L21 mechanisms that enable it are deprecated). Implementations P150L22 should instead use the Route mechanism described in this P150L23 document, establishing a pre-existing route set if necessary P150L24 (see Section 8.1.1.1). This provides a full URI to describe P150L25 the node to be traversed. P150L26 P150L27 The ttl parameter determines the time-to-live value of the UDP P150L28 multicast packet and MUST only be used if maddr is a multicast P150L29 address and the transport protocol is UDP. For example, to P150L30 specify a call to alice@atlanta.com using multicast to P150L31 239.255.255.1 with a ttl of 15, the following URI would be P150L32 used: P150L33 P150L34 sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 P150L35 P150L36 The set of valid telephone-subscriber strings is a subset of P150L37 valid user strings. The user URI parameter exists to P150L38 distinguish telephone numbers from user names that happen to P150L39 look like telephone numbers. If the user string contains a P150L40 telephone number formatted as a telephone-subscriber, the user P150L41 parameter value "phone" SHOULD be present. Even without this P150L42 parameter, recipients of SIP and SIPS URIs MAY interpret the P150L43 pre-@ part as a telephone number if local restrictions on the P150L44 name space for user name allow it. P150L45 P150L46 The method of the SIP request constructed from the URI can be P150L47 specified with the method parameter. P150L48 P151L1 The lr parameter, when present, indicates that the element P151L2 responsible for this resource implements the routing mechanisms P151L3 specified in this document. This parameter will be used in the P151L4 URIs proxies place into Record-Route header field values, and P151L5 may appear in the URIs in a pre-existing route set. P151L6 P151L7 This parameter is used to achieve backwards compatibility with P151L8 systems implementing the strict-routing mechanisms of RFC 2543 P151L9 and the rfc2543bis drafts up to bis-05. An element preparing P151L10 to send a request based on a URI not containing this parameter P151L11 can assume the receiving element implements strict-routing and P151L12 reformat the message to preserve the information in the P151L13 Request-URI. P151L14 P151L15 Since the uri-parameter mechanism is extensible, SIP elements P151L16 MUST silently ignore any uri-parameters that they do not P151L17 understand. P151L18 P151L19 Headers: Header fields to be included in a request constructed P151L20 from the URI. P151L21 P151L22 Headers fields in the SIP request can be specified with the "?" P151L23 mechanism within a URI. The header names and values are P151L24 encoded in ampersand separated hname = hvalue pairs. The P151L25 special hname "body" indicates that the associated hvalue is P151L26 the message-body of the SIP request. P151L27 P151L28 Table 1 summarizes the use of SIP and SIPS URI components based on P151L29 the context in which the URI appears. The external column describes P151L30 URIs appearing anywhere outside of a SIP message, for instance on a P151L31 web page or business card. Entries marked "m" are mandatory, those P151L32 marked "o" are optional, and those marked "-" are not allowed. P151L33 Elements processing URIs SHOULD ignore any disallowed components if P151L34 they are present. The second column indicates the default value of P151L35 an optional element if it is not present. "--" indicates that the P151L36 element is either not optional, or has no default value. P151L37 P151L38 URIs in Contact header fields have different restrictions depending P151L39 on the context in which the header field appears. One set applies to P151L40 messages that establish and maintain dialogs (INVITE and its 200 (OK) P151L41 response). The other applies to registration and redirection P151L42 messages (REGISTER, its 200 (OK) response, and 3xx class responses to P151L43 any method). P151L44 P151L45 P151L46 P151L47 P151L48 P152L1 19.1.2 Character Escaping Requirements P152L2 P152L3 dialog P152L4 reg./redir. Contact/ P152L5 default Req.-URI To From Contact R-R/Route external P152L6 user -- o o o o o o P152L7 password -- o o o o o o P152L8 host -- m m m m m m P152L9 port (1) o - - o o o P152L10 user-param ip o o o o o o P152L11 method INVITE - - - - - o P152L12 maddr-param -- o - - o o o P152L13 ttl-param 1 o - - o - o P152L14 transp.-param (2) o - - o o o P152L15 lr-param -- o - - - o o P152L16 other-param -- o o o o o o P152L17 headers -- - - - o - o P152L18 P152L19 (1): The default port value is transport and scheme dependent. The P152L20 default is 5060 for sip: using UDP, TCP, or SCTP. The default is P152L21 5061 for sip: using TLS over TCP and sips: over TCP. P152L22 P152L23 (2): The default transport is scheme dependent. For sip:, it is UDP. P152L24 For sips:, it is TCP. P152L25 P152L26 Table 1: Use and default values of URI components for SIP header P152L27 field values, Request-URI and references P152L28 P152L29 SIP follows the requirements and guidelines of RFC 2396 [5] when P152L30 defining the set of characters that must be escaped in a SIP URI, and P152L31 uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]: P152L32 P152L33 The set of characters actually reserved within any given URI P152L34 component is defined by that component. In general, a character P152L35 is reserved if the semantics of the URI changes if the character P152L36 is replaced with its escaped US-ASCII encoding [5]. Excluded US- P152L37 ASCII characters (RFC 2396 [5]), such as space and control P152L38 characters and characters used as URI delimiters, also MUST be P152L39 escaped. URIs MUST NOT contain unescaped space and control P152L40 characters. P152L41 P152L42 For each component, the set of valid BNF expansions defines exactly P152L43 which characters may appear unescaped. All other characters MUST be P152L44 escaped. P152L45 P152L46 For example, "@" is not in the set of characters in the user P152L47 component, so the user "j@s0n" must have at least the @ sign encoded, P152L48 as in "j%40s0n". P153L1 Expanding the hname and hvalue tokens in Section 25 show that all URI P153L2 reserved characters in header field names and values MUST be escaped. P153L3 P153L4 The telephone-subscriber subset of the user component has special P153L5 escaping considerations. The set of characters not reserved in the P153L6 RFC 2806 [9] description of telephone-subscriber contains a number of P153L7 characters in various syntax elements that need to be escaped when P153L8 used in SIP URIs. Any characters occurring in a telephone-subscriber P153L9 that do not appear in an expansion of the BNF for the user rule MUST P153L10 be escaped. P153L11 P153L12 Note that character escaping is not allowed in the host component of P153L13 a SIP or SIPS URI (the % character is not valid in its expansion). P153L14 This is likely to change in the future as requirements for P153L15 Internationalized Domain Names are finalized. Current P153L16 implementations MUST NOT attempt to improve robustness by treating P153L17 received escaped characters in the host component as literally P153L18 equivalent to their unescaped counterpart. The behavior required to P153L19 meet the requirements of IDN may be significantly different. P153L20 P153L21 19.1.3 Example SIP and SIPS URIs P153L22 P153L23 sip:alice@atlanta.com P153L24 sip:alice:secretword@atlanta.com;transport=tcp P153L25 sips:alice@atlanta.com?subject=project%20x&priority=urgent P153L26 sip:+1-212-555-1212:1234@gateway.com;user=phone P153L27 sips:1212@gateway.com P153L28 sip:alice@192.0.2.4 P153L29 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com P153L30 sip:alice;day=tuesday@atlanta.com P153L31 P153L32 The last sample URI above has a user field value of P153L33 "alice;day=tuesday". The escaping rules defined above allow a P153L34 semicolon to appear unescaped in this field. For the purposes of P153L35 this protocol, the field is opaque. The structure of that value is P153L36 only useful to the SIP element responsible for the resource. P153L37 P153L38 19.1.4 URI Comparison P153L39 P153L40 Some operations in this specification require determining whether two P153L41 SIP or SIPS URIs are equivalent. In this specification, registrars P153L42 need to compare bindings in Contact URIs in REGISTER requests (see P153L43 Section 10.3.). SIP and SIPS URIs are compared for equality P153L44 according to the following rules: P153L45 P153L46 o A SIP and SIPS URI are never equivalent. P153L47 P153L48 P154L1 o Comparison of the userinfo of SIP and SIPS URIs is case- P154L2 sensitive. This includes userinfo containing passwords or P154L3 formatted as telephone-subscribers. Comparison of all other P154L4 components of the URI is case-insensitive unless explicitly P154L5 defined otherwise. P154L6 P154L7 o The ordering of parameters and header fields is not significant P154L8 in comparing SIP and SIPS URIs. P154L9 P154L10 o Characters other than those in the "reserved" set (see RFC 2396 P154L11 [5]) are equivalent to their ""%" HEX HEX" encoding. P154L12 P154L13 o An IP address that is the result of a DNS lookup of a host name P154L14 does not match that host name. P154L15 P154L16 o For two URIs to be equal, the user, password, host, and port P154L17 components must match. P154L18 P154L19 A URI omitting the user component will not match a URI that P154L20 includes one. A URI omitting the password component will not P154L21 match a URI that includes one. P154L22 P154L23 A URI omitting any component with a default value will not P154L24 match a URI explicitly containing that component with its P154L25 default value. For instance, a URI omitting the optional port P154L26 component will not match a URI explicitly declaring port 5060. P154L27 The same is true for the transport-parameter, ttl-parameter, P154L28 user-parameter, and method components. P154L29 P154L30 Defining sip:user@host to not be equivalent to P154L31 sip:user@host:5060 is a change from RFC 2543. When deriving P154L32 addresses from URIs, equivalent addresses are expected from P154L33 equivalent URIs. The URI sip:user@host:5060 will always P154L34 resolve to port 5060. The URI sip:user@host may resolve to P154L35 other ports through the DNS SRV mechanisms detailed in [4]. P154L36 P154L37 o URI uri-parameter components are compared as follows: P154L38 P154L39 - Any uri-parameter appearing in both URIs must match. P154L40 P154L41 - A user, ttl, or method uri-parameter appearing in only one P154L42 URI never matches, even if it contains the default value. P154L43 P154L44 - A URI that includes an maddr parameter will not match a URI P154L45 that contains no maddr parameter. P154L46 P154L47 - All other uri-parameters appearing in only one URI are P154L48 ignored when comparing the URIs. P155L1 o URI header components are never ignored. Any present header P155L2 component MUST be present in both URIs and match for the URIs P155L3 to match. The matching rules are defined for each header field P155L4 in Section 20. P155L5 P155L6 The URIs within each of the following sets are equivalent: P155L7 P155L8 sip:%61lice@atlanta.com;transport=TCP P155L9 sip:alice@AtLanTa.CoM;Transport=tcp P155L10 P155L11 sip:carol@chicago.com P155L12 sip:carol@chicago.com;newparam=5 P155L13 sip:carol@chicago.com;security=on P155L14 P155L15 sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com P155L16 sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com P155L17 P155L18 sip:alice@atlanta.com?subject=project%20x&priority=urgent P155L19 sip:alice@atlanta.com?priority=urgent&subject=project%20x P155L20 P155L21 The URIs within each of the following sets are not equivalent: P155L22 P155L23 SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) P155L24 sip:alice@AtLanTa.CoM;Transport=UDP P155L25 P155L26 sip:bob@biloxi.com (can resolve to different ports) P155L27 sip:bob@biloxi.com:5060 P155L28 P155L29 sip:bob@biloxi.com (can resolve to different transports) P155L30 sip:bob@biloxi.com;transport=udp P155L31 P155L32 sip:bob@biloxi.com (can resolve to different port and transports) P155L33 sip:bob@biloxi.com:6000;transport=tcp P155L34 P155L35 sip:carol@chicago.com (different header component) P155L36 sip:carol@chicago.com?Subject=next%20meeting P155L37 P155L38 sip:bob@phone21.boxesbybob.com (even though that's what P155L39 sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) P155L40 P155L41 Note that equality is not transitive: P155L42 P155L43 o sip:carol@chicago.com and sip:carol@chicago.com;security=on are P155L44 equivalent P155L45 P155L46 o sip:carol@chicago.com and sip:carol@chicago.com;security=off P155L47 are equivalent P155L48 P156L1 o sip:carol@chicago.com;security=on and P156L2 sip:carol@chicago.com;security=off are not equivalent P156L3 P156L4 19.1.5 Forming Requests from a URI P156L5 P156L6 An implementation needs to take care when forming requests directly P156L7 from a URI. URIs from business cards, web pages, and even from P156L8 sources inside the protocol such as registered contacts may contain P156L9 inappropriate header fields or body parts. P156L10 P156L11 An implementation MUST include any provided transport, maddr, ttl, or P156L12 user parameter in the Request-URI of the formed request. If the URI P156L13 contains a method parameter, its value MUST be used as the method of P156L14 the request. The method parameter MUST NOT be placed in the P156L15 Request-URI. Unknown URI parameters MUST be placed in the message's P156L16 Request-URI. P156L17 P156L18 An implementation SHOULD treat the presence of any headers or body P156L19 parts in the URI as a desire to include them in the message, and P156L20 choose to honor the request on a per-component basis. P156L21 P156L22 An implementation SHOULD NOT honor these obviously dangerous header P156L23 fields: From, Call-ID, CSeq, Via, and Record-Route. P156L24 P156L25 An implementation SHOULD NOT honor any requested Route header field P156L26 values in order to not be used as an unwitting agent in malicious P156L27 attacks. P156L28 P156L29 An implementation SHOULD NOT honor requests to include header fields P156L30 that may cause it to falsely advertise its location or capabilities. P156L31 These include: Accept, Accept-Encoding, Accept-Language, Allow, P156L32 Contact (in its dialog usage), Organization, Supported, and User- P156L33 Agent. P156L34 P156L35 An implementation SHOULD verify the accuracy of any requested P156L36 descriptive header fields, including: Content-Disposition, Content- P156L37 Encoding, Content-Language, Content-Length, Content-Type, Date, P156L38 Mime-Version, and Timestamp. P156L39 P156L40 If the request formed from constructing a message from a given URI is P156L41 not a valid SIP request, the URI is invalid. An implementation MUST P156L42 NOT proceed with transmitting the request. It should instead pursue P156L43 the course of action due an invalid URI in the context it occurs. P156L44 P156L45 The constructed request can be invalid in many ways. These P156L46 include, but are not limited to, syntax error in header fields, P156L47 invalid combinations of URI parameters, or an incorrect P156L48 description of the message body. P157L1 Sending a request formed from a given URI may require capabilities P157L2 unavailable to the implementation. The URI might indicate use of an P157L3 unimplemented transport or extension, for example. An implementation P157L4 SHOULD refuse to send these requests rather than modifying them to P157L5 match their capabilities. An implementation MUST NOT send a request P157L6 requiring an extension that it does not support. P157L7 P157L8 For example, such a request can be formed through the presence of P157L9 a Require header parameter or a method URI parameter with an P157L10 unknown or explicitly unsupported value. P157L11 P157L12 19.1.6 Relating SIP URIs and tel URLs P157L13 P157L14 When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the P157L15 entire telephone-subscriber portion of the tel URL, including any P157L16 parameters, is placed into the userinfo part of the SIP or SIPS URI. P157L17 P157L18 Thus, tel:+358-555-1234567;postd=pp22 becomes P157L19 P157L20 sip:+358-555-1234567;postd=pp22@foo.com;user=phone P157L21 P157L22 or P157L23 sips:+358-555-1234567;postd=pp22@foo.com;user=phone P157L24 P157L25 not P157L26 sip:+358-555-1234567@foo.com;postd=pp22;user=phone P157L27 P157L28 or P157L29 P157L30 sips:+358-555-1234567@foo.com;postd=pp22;user=phone P157L31 P157L32 In general, equivalent "tel" URLs converted to SIP or SIPS URIs in P157L33 this fashion may not produce equivalent SIP or SIPS URIs. The P157L34 userinfo of SIP and SIPS URIs are compared as a case-sensitive P157L35 string. Variance in case-insensitive portions of tel URLs and P157L36 reordering of tel URL parameters does not affect tel URL equivalence, P157L37 but does affect the equivalence of SIP URIs formed from them. P157L38 P157L39 For example, P157L40 P157L41 tel:+358-555-1234567;postd=pp22 P157L42 tel:+358-555-1234567;POSTD=PP22 P157L43 P157L44 are equivalent, while P157L45 P157L46 sip:+358-555-1234567;postd=pp22@foo.com;user=phone P157L47 sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone P157L48 P158L1 are not. P158L2 P158L3 Likewise, P158L4 P158L5 tel:+358-555-1234567;postd=pp22;isub=1411 P158L6 tel:+358-555-1234567;isub=1411;postd=pp22 P158L7 P158L8 are equivalent, while P158L9 P158L10 sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone P158L11 sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone P158L12 P158L13 are not. P158L14 P158L15 To mitigate this problem, elements constructing telephone-subscriber P158L16 fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold P158L17 any case-insensitive portion of telephone-subscriber to lower case, P158L18 and order the telephone-subscriber parameters lexically by parameter P158L19 name, excepting isdn-subaddress and post-dial, which occur first and P158L20 in that order. (All components of a tel URL except for future- P158L21 extension parameters are defined to be compared case-insensitive.) P158L22 P158L23 Following this suggestion, both P158L24 P158L25 tel:+358-555-1234567;postd=pp22 P158L26 tel:+358-555-1234567;POSTD=PP22 P158L27 P158L28 become P158L29 P158L30 sip:+358-555-1234567;postd=pp22@foo.com;user=phone P158L31 P158L32 and both P158L33 P158L34 tel:+358-555-1234567;tsp=a.b;phone-context=5 P158L35 tel:+358-555-1234567;phone-context=5;tsp=a.b P158L36 P158L37 become P158L38 P158L39 sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone P158L40 P158L41 19.2 Option Tags P158L42 P158L43 Option tags are unique identifiers used to designate new options P158L44 (extensions) in SIP. These tags are used in Require (Section 20.32), P158L45 Proxy-Require (Section 20.29), Supported (Section 20.37) and P158L46 Unsupported (Section 20.40) header fields. Note that these options P158L47 appear as parameters in those header fields in an option-tag = token P158L48 form (see Section 25 for the definition of token). P159L1 Option tags are defined in standards track RFCs. This is a change P159L2 from past practice, and is instituted to ensure continuing multi- P159L3 vendor interoperability (see discussion in Section 20.32 and Section P159L4 20.37). An IANA registry of option tags is used to ensure easy P159L5 reference. P159L6 P159L7 19.3 Tags P159L8 P159L9 The "tag" parameter is used in the To and From header fields of SIP P159L10 messages. It serves as a general mechanism to identify a dialog, P159L11 which is the combination of the Call-ID along with two tags, one from P159L12 each participant in the dialog. When a UA sends a request outside of P159L13 a dialog, it contains a From tag only, providing "half" of the dialog P159L14 ID. The dialog is completed from the response(s), each of which P159L15 contributes the second half in the To header field. The forking of P159L16 SIP requests means that multiple dialogs can be established from a P159L17 single request. This also explains the need for the two-sided dialog P159L18 identifier; without a contribution from the recipients, the P159L19 originator could not disambiguate the multiple dialogs established P159L20 from a single request. P159L21 P159L22 When a tag is generated by a UA for insertion into a request or P159L23 response, it MUST be globally unique and cryptographically random P159L24 with at least 32 bits of randomness. A property of this selection P159L25 requirement is that a UA will place a different tag into the From P159L26 header of an INVITE than it would place into the To header of the P159L27 response to the same INVITE. This is needed in order for a UA to P159L28 invite itself to a session, a common case for "hairpinning" of calls P159L29 in PSTN gateways. Similarly, two INVITEs for different calls will P159L30 have different From tags, and two responses for different calls will P159L31 have different To tags. P159L32 P159L33 Besides the requirement for global uniqueness, the algorithm for P159L34 generating a tag is implementation-specific. Tags are helpful in P159L35 fault tolerant systems, where a dialog is to be recovered on an P159L36 alternate server after a failure. A UAS can select the tag in such a P159L37 way that a backup can recognize a request as part of a dialog on the P159L38 failed server, and therefore determine that it should attempt to P159L39 recover the dialog and any other state associated with it. P159L40 P159L41 20 Header Fields P159L42 P159L43 The general syntax for header fields is covered in Section 7.3. This P159L44 section lists the full set of header fields along with notes on P159L45 syntax, meaning, and usage. Throughout this section, we use [HX.Y] P159L46 to refer to Section X.Y of the current HTTP/1.1 specification RFC P159L47 2616 [8]. Examples of each header field are given. P159L48 P160L1 Information about header fields in relation to methods and proxy P160L2 processing is summarized in Tables 2 and 3. P160L3 P160L4 The "where" column describes the request and response types in which P160L5 the header field can be used. Values in this column are: P160L6 P160L7 R: header field may only appear in requests; P160L8 P160L9 r: header field may only appear in responses; P160L10 P160L11 2xx, 4xx, etc.: A numerical value or range indicates response P160L12 codes with which the header field can be used; P160L13 P160L14 c: header field is copied from the request to the response. P160L15 P160L16 An empty entry in the "where" column indicates that the header P160L17 field may be present in all requests and responses. P160L18 P160L19 The "proxy" column describes the operations a proxy may perform on a P160L20 header field: P160L21 P160L22 a: A proxy can add or concatenate the header field if not present. P160L23 P160L24 m: A proxy can modify an existing header field value. P160L25 P160L26 d: A proxy can delete a header field value. P160L27 P160L28 r: A proxy must be able to read the header field, and thus this P160L29 header field cannot be encrypted. P160L30 P160L31 The next six columns relate to the presence of a header field in a P160L32 method: P160L33 P160L34 c: Conditional; requirements on the header field depend on the P160L35 context of the message. P160L36 P160L37 m: The header field is mandatory. P160L38 P160L39 m*: The header field SHOULD be sent, but clients/servers need to P160L40 be prepared to receive messages without that header field. P160L41 P160L42 o: The header field is optional. P160L43 P160L44 t: The header field SHOULD be sent, but clients/servers need to be P160L45 prepared to receive messages without that header field. P160L46 P160L47 If a stream-based protocol (such as TCP) is used as a P160L48 transport, then the header field MUST be sent. P161L1 *: The header field is required if the message body is not empty. P161L2 See Sections 20.14, 20.15 and 7.4 for details. P161L3 P161L4 -: The header field is not applicable. P161L5 P161L6 "Optional" means that an element MAY include the header field in a P161L7 request or response, and a UA MAY ignore the header field if present P161L8 in the request or response (The exception to this rule is the Require P161L9 header field discussed in 20.32). A "mandatory" header field MUST be P161L10 present in a request, and MUST be understood by the UAS receiving the P161L11 request. A mandatory response header field MUST be present in the P161L12 response, and the header field MUST be understood by the UAC P161L13 processing the response. "Not applicable" means that the header P161L14 field MUST NOT be present in a request. If one is placed in a P161L15 request by mistake, it MUST be ignored by the UAS receiving the P161L16 request. Similarly, a header field labeled "not applicable" for a P161L17 response means that the UAS MUST NOT place the header field in the P161L18 response, and the UAC MUST ignore the header field in the response. P161L19 P161L20 A UA SHOULD ignore extension header parameters that are not P161L21 understood. P161L22 P161L23 A compact form of some common header field names is also defined for P161L24 use when overall message size is an issue. P161L25 P161L26 The Contact, From, and To header fields contain a URI. If the URI P161L27 contains a comma, question mark or semicolon, the URI MUST be P161L28 enclosed in angle brackets (< and >). Any URI parameters are P161L29 contained within these brackets. If the URI is not enclosed in angle P161L30 brackets, any semicolon-delimited parameters are header-parameters, P161L31 not URI parameters. P161L32 P161L33 20.1 Accept P161L34 P161L35 The Accept header field follows the syntax defined in [H14.1]. The P161L36 semantics are also identical, with the exception that if no Accept P161L37 header field is present, the server SHOULD assume a default value of P161L38 application/sdp. P161L39 P161L40 An empty Accept header field means that no formats are acceptable. P161L41 P161L42 P161L43 P161L44 P161L45 P161L46 P161L47 P161L48 P162L1 Example: P162L2 P162L3 Header field where proxy ACK BYE CAN INV OPT REG P162L4 ___________________________________________________________ P162L5 Accept R - o - o m* o P162L6 Accept 2xx - - - o m* o P162L7 Accept 415 - c - c c c P162L8 Accept-Encoding R - o - o o o P162L9 Accept-Encoding 2xx - - - o m* o P162L10 Accept-Encoding 415 - c - c c c P162L11 Accept-Language R - o - o o o P162L12 Accept-Language 2xx - - - o m* o P162L13 Accept-Language 415 - c - c c c P162L14 Alert-Info R ar - - - o - - P162L15 Alert-Info 180 ar - - - o - - P162L16 Allow R - o - o o o P162L17 Allow 2xx - o - m* m* o P162L18 Allow r - o - o o o P162L19 Allow 405 - m - m m m P162L20 Authentication-Info 2xx - o - o o o P162L21 Authorization R o o o o o o P162L22 Call-ID c r m m m m m m P162L23 Call-Info ar - - - o o o P162L24 Contact R o - - m o o P162L25 Contact 1xx - - - o - - P162L26 Contact 2xx - - - m o o P162L27 Contact 3xx d - o - o o o P162L28 Contact 485 - o - o o o P162L29 Content-Disposition o o - o o o P162L30 Content-Encoding o o - o o o P162L31 Content-Language o o - o o o P162L32 Content-Length ar t t t t t t P162L33 Content-Type * * - * * * P162L34 CSeq c r m m m m m m P162L35 Date a o o o o o o P162L36 Error-Info 300-699 a - o o o o o P162L37 Expires - - - o - o P162L38 From c r m m m m m m P162L39 In-Reply-To R - - - o - - P162L40 Max-Forwards R amr m m m m m m P162L41 Min-Expires 423 - - - - - m P162L42 MIME-Version o o - o o o P162L43 Organization ar - - - o o o P162L44 P162L45 Table 2: Summary of header fields, A--O P162L46 P162L47 P162L48 P163L1 Header field where proxy ACK BYE CAN INV OPT REG P163L2 ___________________________________________________________________ P163L3 Priority R ar - - - o - - P163L4 Proxy-Authenticate 407 ar - m - m m m P163L5 Proxy-Authenticate 401 ar - o o o o o P163L6 Proxy-Authorization R dr o o - o o o P163L7 Proxy-Require R ar - o - o o o P163L8 Record-Route R ar o o o o o - P163L9 Record-Route 2xx,18x mr - o o o o - P163L10 Reply-To - - - o - - P163L11 Require ar - c - c c c P163L12 Retry-After 404,413,480,486 - o o o o o P163L13 500,503 - o o o o o P163L14 600,603 - o o o o o P163L15 Route R adr c c c c c c P163L16 Server r - o o o o o P163L17 Subject R - - - o - - P163L18 Supported R - o o m* o o P163L19 Supported 2xx - o o m* m* o P163L20 Timestamp o o o o o o P163L21 To c(1) r m m m m m m P163L22 Unsupported 420 - m - m m m P163L23 User-Agent o o o o o o P163L24 Via R amr m m m m m m P163L25 Via rc dr m m m m m m P163L26 Warning r - o o o o o P163L27 WWW-Authenticate 401 ar - m - m m m P163L28 WWW-Authenticate 407 ar - o - o o o P163L29 P163L30 Table 3: Summary of header fields, P--Z; (1): copied with possible P163L31 addition of tag P163L32 P163L33 Accept: application/sdp;level=1, application/x-private, text/html P163L34 P163L35 20.2 Accept-Encoding P163L36 P163L37 The Accept-Encoding header field is similar to Accept, but restricts P163L38 the content-codings [H3.5] that are acceptable in the response. See P163L39 [H14.3]. The semantics in SIP are identical to those defined in P163L40 [H14.3]. P163L41 P163L42 An empty Accept-Encoding header field is permissible. It is P163L43 equivalent to Accept-Encoding: identity, that is, only the identity P163L44 encoding, meaning no encoding, is permissible. P163L45 P163L46 If no Accept-Encoding header field is present, the server SHOULD P163L47 assume a default value of identity. P163L48 P164L1 This differs slightly from the HTTP definition, which indicates that P164L2 when not present, any encoding can be used, but the identity encoding P164L3 is preferred. P164L4 P164L5 Example: P164L6 P164L7 Accept-Encoding: gzip P164L8 P164L9 20.3 Accept-Language P164L10 P164L11 The Accept-Language header field is used in requests to indicate the P164L12 preferred languages for reason phrases, session descriptions, or P164L13 status responses carried as message bodies in the response. If no P164L14 Accept-Language header field is present, the server SHOULD assume all P164L15 languages are acceptable to the client. P164L16 P164L17 The Accept-Language header field follows the syntax defined in P164L18 [H14.4]. The rules for ordering the languages based on the "q" P164L19 parameter apply to SIP as well. P164L20 P164L21 Example: P164L22 P164L23 Accept-Language: da, en-gb;q=0.8, en;q=0.7 P164L24 P164L25 20.4 Alert-Info P164L26 P164L27 When present in an INVITE request, the Alert-Info header field P164L28 specifies an alternative ring tone to the UAS. When present in a 180 P164L29 (Ringing) response, the Alert-Info header field specifies an P164L30 alternative ringback tone to the UAC. A typical usage is for a proxy P164L31 to insert this header field to provide a distinctive ring feature. P164L32 P164L33 The Alert-Info header field can introduce security risks. These P164L34 risks and the ways to handle them are discussed in Section 20.9, P164L35 which discusses the Call-Info header field since the risks are P164L36 identical. P164L37 P164L38 In addition, a user SHOULD be able to disable this feature P164L39 selectively. P164L40 P164L41 This helps prevent disruptions that could result from the use of P164L42 this header field by untrusted elements. P164L43 P164L44 Example: P164L45 P164L46 Alert-Info: P164L47 P164L48 P165L1 20.5 Allow P165L2 P165L3 The Allow header field lists the set of methods supported by the UA P165L4 generating the message. P165L5 P165L6 All methods, including ACK and CANCEL, understood by the UA MUST be P165L7 included in the list of methods in the Allow header field, when P165L8 present. The absence of an Allow header field MUST NOT be P165L9 interpreted to mean that the UA sending the message supports no P165L10 methods. Rather, it implies that the UA is not providing any P165L11 information on what methods it supports. P165L12 P165L13 Supplying an Allow header field in responses to methods other than P165L14 OPTIONS reduces the number of messages needed. P165L15 P165L16 Example: P165L17 P165L18 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE P165L19 P165L20 20.6 Authentication-Info P165L21 P165L22 The Authentication-Info header field provides for mutual P165L23 authentication with HTTP Digest. A UAS MAY include this header field P165L24 in a 2xx response to a request that was successfully authenticated P165L25 using digest based on the Authorization header field. P165L26 P165L27 Syntax and semantics follow those specified in RFC 2617 [17]. P165L28 P165L29 Example: P165L30 P165L31 Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" P165L32 P165L33 20.7 Authorization P165L34 P165L35 The Authorization header field contains authentication credentials of P165L36 a UA. Section 22.2 overviews the use of the Authorization header P165L37 field, and Section 22.4 describes the syntax and semantics when used P165L38 with HTTP authentication. P165L39 P165L40 This header field, along with Proxy-Authorization, breaks the general P165L41 rules about multiple header field values. Although not a comma- P165L42 separated list, this header field name may be present multiple times, P165L43 and MUST NOT be combined into a single header line using the usual P165L44 rules described in Section 7.3. P165L45 P165L46 P165L47 P165L48 P166L1 In the example below, there are no quotes around the Digest P166L2 parameter: P166L3 P166L4 Authorization: Digest username="Alice", realm="atlanta.com", P166L5 nonce="84a4cc6f3082121f32b42a2187831a9e", P166L6 response="7587245234b3434cc3412213e5f113a5432" P166L7 P166L8 20.8 Call-ID P166L9 P166L10 The Call-ID header field uniquely identifies a particular invitation P166L11 or all registrations of a particular client. A single multimedia P166L12 conference can give rise to several calls with different Call-IDs, P166L13 for example, if a user invites a single individual several times to P166L14 the same (long-running) conference. Call-IDs are case-sensitive and P166L15 are simply compared byte-by-byte. P166L16 P166L17 The compact form of the Call-ID header field is i. P166L18 P166L19 Examples: P166L20 P166L21 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com P166L22 i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 P166L23 P166L24 20.9 Call-Info P166L25 P166L26 The Call-Info header field provides additional information about the P166L27 caller or callee, depending on whether it is found in a request or P166L28 response. The purpose of the URI is described by the "purpose" P166L29 parameter. The "icon" parameter designates an image suitable as an P166L30 iconic representation of the caller or callee. The "info" parameter P166L31 describes the caller or callee in general, for example, through a web P166L32 page. The "card" parameter provides a business card, for example, in P166L33 vCard [36] or LDIF [37] formats. Additional tokens can be registered P166L34 using IANA and the procedures in Section 27. P166L35 P166L36 Use of the Call-Info header field can pose a security risk. If a P166L37 callee fetches the URIs provided by a malicious caller, the callee P166L38 may be at risk for displaying inappropriate or offensive content, P166L39 dangerous or illegal content, and so on. Therefore, it is P166L40 RECOMMENDED that a UA only render the information in the Call-Info P166L41 header field if it can verify the authenticity of the element that P166L42 originated the header field and trusts that element. This need not P166L43 be the peer UA; a proxy can insert this header field into requests. P166L44 P166L45 Example: P166L46 P166L47 Call-Info: ;purpose=icon, P166L48 ;purpose=info P167L1 20.10 Contact P167L2 P167L3 A Contact header field value provides a URI whose meaning depends on P167L4 the type of request or response it is in. P167L5 P167L6 A Contact header field value can contain a display name, a URI with P167L7 URI parameters, and header parameters. P167L8 P167L9 This document defines the Contact parameters "q" and "expires". P167L10 These parameters are only used when the Contact is present in a P167L11 REGISTER request or response, or in a 3xx response. Additional P167L12 parameters may be defined in other specifications. P167L13 P167L14 When the header field value contains a display name, the URI P167L15 including all URI parameters is enclosed in "<" and ">". If no "<" P167L16 and ">" are present, all parameters after the URI are header P167L17 parameters, not URI parameters. The display name can be tokens, or a P167L18 quoted string, if a larger character set is desired. P167L19 P167L20 Even if the "display-name" is empty, the "name-addr" form MUST be P167L21 used if the "addr-spec" contains a comma, semicolon, or question P167L22 mark. There may or may not be LWS between the display-name and the P167L23 "<". P167L24 P167L25 These rules for parsing a display name, URI and URI parameters, and P167L26 header parameters also apply for the header fields To and From. P167L27 P167L28 The Contact header field has a role similar to the Location header P167L29 field in HTTP. However, the HTTP header field only allows one P167L30 address, unquoted. Since URIs can contain commas and semicolons P167L31 as reserved characters, they can be mistaken for header or P167L32 parameter delimiters, respectively. P167L33 P167L34 The compact form of the Contact header field is m (for "moved"). P167L35 P167L36 Examples: P167L37 P167L38 Contact: "Mr. Watson" P167L39 ;q=0.7; expires=3600, P167L40 "Mr. Watson" ;q=0.1 P167L41 m: ;expires=60 P167L42 P167L43 P167L44 P167L45 P167L46 P167L47 P167L48 P168L1 20.11 Content-Disposition P168L2 P168L3 The Content-Disposition header field describes how the message body P168L4 or, for multipart messages, a message body part is to be interpreted P168L5 by the UAC or UAS. This SIP header field extends the MIME Content- P168L6 Type (RFC 2183 [18]). P168L7 P168L8 Several new "disposition-types" of the Content-Disposition header are P168L9 defined by SIP. The value "session" indicates that the body part P168L10 describes a session, for either calls or early (pre-call) media. The P168L11 value "render" indicates that the body part should be displayed or P168L12 otherwise rendered to the user. Note that the value "render" is used P168L13 rather than "inline" to avoid the connotation that the MIME body is P168L14 displayed as a part of the rendering of the entire message (since the P168L15 MIME bodies of SIP messages oftentimes are not displayed to users). P168L16 For backward-compatibility, if the Content-Disposition header field P168L17 is missing, the server SHOULD assume bodies of Content-Type P168L18 application/sdp are the disposition "session", while other content P168L19 types are "render". P168L20 P168L21 The disposition type "icon" indicates that the body part contains an P168L22 image suitable as an iconic representation of the caller or callee P168L23 that could be rendered informationally by a user agent when a message P168L24 has been received, or persistently while a dialog takes place. The P168L25 value "alert" indicates that the body part contains information, such P168L26 as an audio clip, that should be rendered by the user agent in an P168L27 attempt to alert the user to the receipt of a request, generally a P168L28 request that initiates a dialog; this alerting body could for example P168L29 be rendered as a ring tone for a phone call after a 180 Ringing P168L30 provisional response has been sent. P168L31 P168L32 Any MIME body with a "disposition-type" that renders content to the P168L33 user should only be processed when a message has been properly P168L34 authenticated. P168L35 P168L36 The handling parameter, handling-param, describes how the UAS should P168L37 react if it receives a message body whose content type or disposition P168L38 type it does not understand. The parameter has defined values of P168L39 "optional" and "required". If the handling parameter is missing, the P168L40 value "required" SHOULD be assumed. The handling parameter is P168L41 described in RFC 3204 [19]. P168L42 P168L43 If this header field is missing, the MIME type determines the default P168L44 content disposition. If there is none, "render" is assumed. P168L45 P168L46 Example: P168L47 P168L48 Content-Disposition: session P169L1 20.12 Content-Encoding P169L2 P169L3 The Content-Encoding header field is used as a modifier to the P169L4 "media-type". When present, its value indicates what additional P169L5 content codings have been applied to the entity-body, and thus what P169L6 decoding mechanisms MUST be applied in order to obtain the media-type P169L7 referenced by the Content-Type header field. Content-Encoding is P169L8 primarily used to allow a body to be compressed without losing the P169L9 identity of its underlying media type. P169L10 P169L11 If multiple encodings have been applied to an entity-body, the P169L12 content codings MUST be listed in the order in which they were P169L13 applied. P169L14 P169L15 All content-coding values are case-insensitive. IANA acts as a P169L16 registry for content-coding value tokens. See [H3.5] for a P169L17 definition of the syntax for content-coding. P169L18 P169L19 Clients MAY apply content encodings to the body in requests. A P169L20 server MAY apply content encodings to the bodies in responses. The P169L21 server MUST only use encodings listed in the Accept-Encoding header P169L22 field in the request. P169L23 P169L24 The compact form of the Content-Encoding header field is e. P169L25 Examples: P169L26 P169L27 Content-Encoding: gzip P169L28 e: tar P169L29 P169L30 20.13 Content-Language P169L31 P169L32 See [H14.12]. Example: P169L33 P169L34 Content-Language: fr P169L35 P169L36 20.14 Content-Length P169L37 P169L38 The Content-Length header field indicates the size of the message- P169L39 body, in decimal number of octets, sent to the recipient. P169L40 Applications SHOULD use this field to indicate the size of the P169L41 message-body to be transferred, regardless of the media type of the P169L42 entity. If a stream-based protocol (such as TCP) is used as P169L43 transport, the header field MUST be used. P169L44 P169L45 The size of the message-body does not include the CRLF separating P169L46 header fields and body. Any Content-Length greater than or equal to P169L47 zero is a valid value. If no body is present in a message, then the P169L48 Content-Length header field value MUST be set to zero. P170L1 The ability to omit Content-Length simplifies the creation of P170L2 cgi-like scripts that dynamically generate responses. P170L3 P170L4 The compact form of the header field is l. P170L5 P170L6 Examples: P170L7 P170L8 Content-Length: 349 P170L9 l: 173 P170L10 P170L11 20.15 Content-Type P170L12 P170L13 The Content-Type header field indicates the media type of the P170L14 message-body sent to the recipient. The "media-type" element is P170L15 defined in [H3.7]. The Content-Type header field MUST be present if P170L16 the body is not empty. If the body is empty, and a Content-Type P170L17 header field is present, it indicates that the body of the specific P170L18 type has zero length (for example, an empty audio file). P170L19 P170L20 The compact form of the header field is c. P170L21 P170L22 Examples: P170L23 P170L24 Content-Type: application/sdp P170L25 c: text/html; charset=ISO-8859-4 P170L26 P170L27 20.16 CSeq P170L28 P170L29 A CSeq header field in a request contains a single decimal sequence P170L30 number and the request method. The sequence number MUST be P170L31 expressible as a 32-bit unsigned integer. The method part of CSeq is P170L32 case-sensitive. The CSeq header field serves to order transactions P170L33 within a dialog, to provide a means to uniquely identify P170L34 transactions, and to differentiate between new requests and request P170L35 retransmissions. Two CSeq header fields are considered equal if the P170L36 sequence number and the request method are identical. Example: P170L37 P170L38 CSeq: 4711 INVITE P170L39 P170L40 20.17 Date P170L41 P170L42 The Date header field contains the date and time. Unlike HTTP/1.1, P170L43 SIP only supports the most recent RFC 1123 [20] format for dates. As P170L44 in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while P170L45 RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. P170L46 P170L47 The Date header field reflects the time when the request or response P170L48 is first sent. P171L1 The Date header field can be used by simple end systems without a P171L2 battery-backed clock to acquire a notion of current time. P171L3 However, in its GMT form, it requires clients to know their offset P171L4 from GMT. P171L5 P171L6 Example: P171L7 P171L8 Date: Sat, 13 Nov 2010 23:29:00 GMT P171L9 P171L10 20.18 Error-Info P171L11 P171L12 The Error-Info header field provides a pointer to additional P171L13 information about the error status response. P171L14 P171L15 SIP UACs have user interface capabilities ranging from pop-up P171L16 windows and audio on PC softclients to audio-only on "black" P171L17 phones or endpoints connected via gateways. Rather than forcing a P171L18 server generating an error to choose between sending an error P171L19 status code with a detailed reason phrase and playing an audio P171L20 recording, the Error-Info header field allows both to be sent. P171L21 The UAC then has the choice of which error indicator to render to P171L22 the caller. P171L23 P171L24 A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if P171L25 it were a Contact in a redirect and generate a new INVITE, resulting P171L26 in a recorded announcement session being established. A non-SIP URI P171L27 MAY be rendered to the user. P171L28 P171L29 Examples: P171L30 P171L31 SIP/2.0 404 The number you have dialed is not in service P171L32 Error-Info: P171L33 P171L34 20.19 Expires P171L35 P171L36 The Expires header field gives the relative time after which the P171L37 message (or content) expires. P171L38 P171L39 The precise meaning of this is method dependent. P171L40 P171L41 The expiration time in an INVITE does not affect the duration of the P171L42 actual session that may result from the invitation. Session P171L43 description protocols may offer the ability to express time limits on P171L44 the session duration, however. P171L45 P171L46 The value of this field is an integral number of seconds (in decimal) P171L47 between 0 and (2**32)-1, measured from the receipt of the request. P171L48 P172L1 Example: P172L2 P172L3 Expires: 5 P172L4 P172L5 20.20 From P172L6 P172L7 The From header field indicates the initiator of the request. This P172L8 may be different from the initiator of the dialog. Requests sent by P172L9 the callee to the caller use the callee's address in the From header P172L10 field. P172L11 P172L12 The optional "display-name" is meant to be rendered by a human user P172L13 interface. A system SHOULD use the display name "Anonymous" if the P172L14 identity of the client is to remain hidden. Even if the "display- P172L15 name" is empty, the "name-addr" form MUST be used if the "addr-spec" P172L16 contains a comma, question mark, or semicolon. Syntax issues are P172L17 discussed in Section 7.3.1. P172L18 P172L19 Two From header fields are equivalent if their URIs match, and their P172L20 parameters match. Extension parameters in one header field, not P172L21 present in the other are ignored for the purposes of comparison. This P172L22 means that the display name and presence or absence of angle brackets P172L23 do not affect matching. P172L24 P172L25 See Section 20.10 for the rules for parsing a display name, URI and P172L26 URI parameters, and header field parameters. P172L27 P172L28 The compact form of the From header field is f. P172L29 P172L30 Examples: P172L31 P172L32 From: "A. G. Bell" ;tag=a48s P172L33 From: sip:+12125551212@server.phone2net.com;tag=887s P172L34 f: Anonymous ;tag=hyh8 P172L35 P172L36 20.21 In-Reply-To P172L37 P172L38 The In-Reply-To header field enumerates the Call-IDs that this call P172L39 references or returns. These Call-IDs may have been cached by the P172L40 client then included in this header field in a return call. P172L41 P172L42 This allows automatic call distribution systems to route return P172L43 calls to the originator of the first call. This also allows P172L44 callees to filter calls, so that only return calls for calls they P172L45 originated will be accepted. This field is not a substitute for P172L46 request authentication. P172L47 P172L48 P173L1 Example: P173L2 P173L3 In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com P173L4 P173L5 20.22 Max-Forwards P173L6 P173L7 The Max-Forwards header field must be used with any SIP method to P173L8 limit the number of proxies or gateways that can forward the request P173L9 to the next downstream server. This can also be useful when the P173L10 client is attempting to trace a request chain that appears to be P173L11 failing or looping in mid-chain. P173L12 P173L13 The Max-Forwards value is an integer in the range 0-255 indicating P173L14 the remaining number of times this request message is allowed to be P173L15 forwarded. This count is decremented by each server that forwards P173L16 the request. The recommended initial value is 70. P173L17 P173L18 This header field should be inserted by elements that can not P173L19 otherwise guarantee loop detection. For example, a B2BUA should P173L20 insert a Max-Forwards header field. P173L21 P173L22 Example: P173L23 P173L24 Max-Forwards: 6 P173L25 P173L26 20.23 Min-Expires P173L27 P173L28 The Min-Expires header field conveys the minimum refresh interval P173L29 supported for soft-state elements managed by that server. This P173L30 includes Contact header fields that are stored by a registrar. The P173L31 header field contains a decimal integer number of seconds from 0 to P173L32 (2**32)-1. The use of the header field in a 423 (Interval Too Brief) P173L33 response is described in Sections 10.2.8, 10.3, and 21.4.17. P173L34 P173L35 Example: P173L36 P173L37 Min-Expires: 60 P173L38 P173L39 20.24 MIME-Version P173L40 P173L41 See [H19.4.1]. P173L42 P173L43 Example: P173L44 P173L45 MIME-Version: 1.0 P173L46 P173L47 P173L48 P174L1 20.25 Organization P174L2 P174L3 The Organization header field conveys the name of the organization to P174L4 which the SIP element issuing the request or response belongs. P174L5 P174L6 The field MAY be used by client software to filter calls. P174L7 P174L8 Example: P174L9 P174L10 Organization: Boxes by Bob P174L11 P174L12 20.26 Priority P174L13 P174L14 The Priority header field indicates the urgency of the request as P174L15 perceived by the client. The Priority header field describes the P174L16 priority that the SIP request should have to the receiving human or P174L17 its agent. For example, it may be factored into decisions about call P174L18 routing and acceptance. For these decisions, a message containing no P174L19 Priority header field SHOULD be treated as if it specified a Priority P174L20 of "normal". The Priority header field does not influence the use of P174L21 communications resources such as packet forwarding priority in P174L22 routers or access to circuits in PSTN gateways. The header field can P174L23 have the values "non-urgent", "normal", "urgent", and "emergency", P174L24 but additional values can be defined elsewhere. It is RECOMMENDED P174L25 that the value of "emergency" only be used when life, limb, or P174L26 property are in imminent danger. Otherwise, there are no semantics P174L27 defined for this header field. P174L28 P174L29 These are the values of RFC 2076 [38], with the addition of P174L30 "emergency". P174L31 P174L32 Examples: P174L33 P174L34 Subject: A tornado is heading our way! P174L35 Priority: emergency P174L36 P174L37 or P174L38 P174L39 Subject: Weekend plans P174L40 Priority: non-urgent P174L41 P174L42 20.27 Proxy-Authenticate P174L43 P174L44 A Proxy-Authenticate header field value contains an authentication P174L45 challenge. P174L46 P174L47 The use of this header field is defined in [H14.33]. See Section P174L48 22.3 for further details on its usage. P175L1 Example: P175L2 P175L3 Proxy-Authenticate: Digest realm="atlanta.com", P175L4 domain="sip:ss1.carrier.com", qop="auth", P175L5 nonce="f84f1cec41e6cbe5aea9c8e88d359", P175L6 opaque="", stale=FALSE, algorithm=MD5 P175L7 P175L8 20.28 Proxy-Authorization P175L9 P175L10 The Proxy-Authorization header field allows the client to identify P175L11 itself (or its user) to a proxy that requires authentication. A P175L12 Proxy-Authorization field value consists of credentials containing P175L13 the authentication information of the user agent for the proxy and/or P175L14 realm of the resource being requested. P175L15 P175L16 See Section 22.3 for a definition of the usage of this header field. P175L17 P175L18 This header field, along with Authorization, breaks the general rules P175L19 about multiple header field names. Although not a comma-separated P175L20 list, this header field name may be present multiple times, and MUST P175L21 NOT be combined into a single header line using the usual rules P175L22 described in Section 7.3.1. P175L23 P175L24 Example: P175L25 P175L26 Proxy-Authorization: Digest username="Alice", realm="atlanta.com", P175L27 nonce="c60f3082ee1212b402a21831ae", P175L28 response="245f23415f11432b3434341c022" P175L29 P175L30 20.29 Proxy-Require P175L31 P175L32 The Proxy-Require header field is used to indicate proxy-sensitive P175L33 features that must be supported by the proxy. See Section 20.32 for P175L34 more details on the mechanics of this message and a usage example. P175L35 P175L36 Example: P175L37 P175L38 Proxy-Require: foo P175L39 P175L40 20.30 Record-Route P175L41 P175L42 The Record-Route header field is inserted by proxies in a request to P175L43 force future requests in the dialog to be routed through the proxy. P175L44 P175L45 Examples of its use with the Route header field are described in P175L46 Sections 16.12.1. P175L47 P175L48 P176L1 Example: P176L2 P176L3 Record-Route: , P176L4 P176L5 P176L6 20.31 Reply-To P176L7 P176L8 The Reply-To header field contains a logical return URI that may be P176L9 different from the From header field. For example, the URI MAY be P176L10 used to return missed calls or unestablished sessions. If the user P176L11 wished to remain anonymous, the header field SHOULD either be omitted P176L12 from the request or populated in such a way that does not reveal any P176L13 private information. P176L14 P176L15 Even if the "display-name" is empty, the "name-addr" form MUST be P176L16 used if the "addr-spec" contains a comma, question mark, or P176L17 semicolon. Syntax issues are discussed in Section 7.3.1. P176L18 P176L19 Example: P176L20 P176L21 Reply-To: Bob P176L22 P176L23 20.32 Require P176L24 P176L25 The Require header field is used by UACs to tell UASs about options P176L26 that the UAC expects the UAS to support in order to process the P176L27 request. Although an optional header field, the Require MUST NOT be P176L28 ignored if it is present. P176L29 P176L30 The Require header field contains a list of option tags, described in P176L31 Section 19.2. Each option tag defines a SIP extension that MUST be P176L32 understood to process the request. Frequently, this is used to P176L33 indicate that a specific set of extension header fields need to be P176L34 understood. A UAC compliant to this specification MUST only include P176L35 option tags corresponding to standards-track RFCs. P176L36 P176L37 Example: P176L38 P176L39 Require: 100rel P176L40 P176L41 20.33 Retry-After P176L42 P176L43 The Retry-After header field can be used with a 500 (Server Internal P176L44 Error) or 503 (Service Unavailable) response to indicate how long the P176L45 service is expected to be unavailable to the requesting client and P176L46 with a 404 (Not Found), 413 (Request Entity Too Large), 480 P176L47 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 P176L48 P177L1 (Decline) response to indicate when the called party anticipates P177L2 being available again. The value of this field is a positive integer P177L3 number of seconds (in decimal) after the time of the response. P177L4 P177L5 An optional comment can be used to indicate additional information P177L6 about the time of callback. An optional "duration" parameter P177L7 indicates how long the called party will be reachable starting at the P177L8 initial time of availability. If no duration parameter is given, the P177L9 service is assumed to be available indefinitely. P177L10 P177L11 Examples: P177L12 P177L13 Retry-After: 18000;duration=3600 P177L14 Retry-After: 120 (I'm in a meeting) P177L15 P177L16 20.34 Route P177L17 P177L18 The Route header field is used to force routing for a request through P177L19 the listed set of proxies. Examples of the use of the Route header P177L20 field are in Section 16.12.1. P177L21 P177L22 Example: P177L23 P177L24 Route: , P177L25 P177L26 P177L27 20.35 Server P177L28 P177L29 The Server header field contains information about the software used P177L30 by the UAS to handle the request. P177L31 P177L32 Revealing the specific software version of the server might allow the P177L33 server to become more vulnerable to attacks against software that is P177L34 known to contain security holes. Implementers SHOULD make the Server P177L35 header field a configurable option. P177L36 P177L37 Example: P177L38 P177L39 Server: HomeServer v2 P177L40 P177L41 20.36 Subject P177L42 P177L43 The Subject header field provides a summary or indicates the nature P177L44 of the call, allowing call filtering without having to parse the P177L45 session description. The session description does not have to use P177L46 the same subject indication as the invitation. P177L47 P177L48 The compact form of the Subject header field is s. P178L1 Example: P178L2 P178L3 Subject: Need more boxes P178L4 s: Tech Support P178L5 P178L6 20.37 Supported P178L7 P178L8 The Supported header field enumerates all the extensions supported by P178L9 the UAC or UAS. P178L10 P178L11 The Supported header field contains a list of option tags, described P178L12 in Section 19.2, that are understood by the UAC or UAS. A UA P178L13 compliant to this specification MUST only include option tags P178L14 corresponding to standards-track RFCs. If empty, it means that no P178L15 extensions are supported. P178L16 P178L17 The compact form of the Supported header field is k. P178L18 P178L19 Example: P178L20 P178L21 Supported: 100rel P178L22 P178L23 20.38 Timestamp P178L24 P178L25 The Timestamp header field describes when the UAC sent the request to P178L26 the UAS. P178L27 P178L28 See Section 8.2.6 for details on how to generate a response to a P178L29 request that contains the header field. Although there is no P178L30 normative behavior defined here that makes use of the header, it P178L31 allows for extensions or SIP applications to obtain RTT estimates. P178L32 P178L33 Example: P178L34 P178L35 Timestamp: 54 P178L36 P178L37 20.39 To P178L38 P178L39 The To header field specifies the logical recipient of the request. P178L40 P178L41 The optional "display-name" is meant to be rendered by a human-user P178L42 interface. The "tag" parameter serves as a general mechanism for P178L43 dialog identification. P178L44 P178L45 See Section 19.3 for details of the "tag" parameter. P178L46 P178L47 P178L48 P179L1 Comparison of To header fields for equality is identical to P179L2 comparison of From header fields. See Section 20.10 for the rules P179L3 for parsing a display name, URI and URI parameters, and header field P179L4 parameters. P179L5 P179L6 The compact form of the To header field is t. P179L7 P179L8 The following are examples of valid To header fields: P179L9 P179L10 To: The Operator ;tag=287447 P179L11 t: sip:+12125551212@server.phone2net.com P179L12 P179L13 20.40 Unsupported P179L14 P179L15 The Unsupported header field lists the features not supported by the P179L16 UAS. See Section 20.32 for motivation. P179L17 P179L18 Example: P179L19 P179L20 Unsupported: foo P179L21 P179L22 20.41 User-Agent P179L23 P179L24 The User-Agent header field contains information about the UAC P179L25 originating the request. The semantics of this header field are P179L26 defined in [H14.43]. P179L27 P179L28 Revealing the specific software version of the user agent might allow P179L29 the user agent to become more vulnerable to attacks against software P179L30 that is known to contain security holes. Implementers SHOULD make P179L31 the User-Agent header field a configurable option. P179L32 P179L33 Example: P179L34 P179L35 User-Agent: Softphone Beta1.5 P179L36 P179L37 20.42 Via P179L38 P179L39 The Via header field indicates the path taken by the request so far P179L40 and indicates the path that should be followed in routing responses. P179L41 The branch ID parameter in the Via header field values serves as a P179L42 transaction identifier, and is used by proxies to detect loops. P179L43 P179L44 A Via header field value contains the transport protocol used to send P179L45 the message, the client's host name or network address, and possibly P179L46 the port number at which it wishes to receive responses. A Via P179L47 header field value can also contain parameters such as "maddr", P179L48 "ttl", "received", and "branch", whose meaning and use are described P180L1 in other sections. For implementations compliant to this P180L2 specification, the value of the branch parameter MUST start with the P180L3 magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. P180L4 P180L5 Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". P180L6 "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the P180L7 protocol still indicates "SIP", and the transport protocol is TLS. P180L8 P180L9 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 P180L10 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 P180L11 ;branch=z9hG4bK77asjd P180L12 P180L13 The compact form of the Via header field is v. P180L14 P180L15 In this example, the message originated from a multi-homed host with P180L16 two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong P180L17 as to which network interface would be used. Erlang.bell- P180L18 telephone.com noticed the mismatch and added a parameter to the P180L19 previous hop's Via header field value, containing the address that P180L20 the packet actually came from. P180L21 P180L22 The host or network address and port number are not required to P180L23 follow the SIP URI syntax. Specifically, LWS on either side of the P180L24 ":" or "/" is allowed, as shown here: P180L25 P180L26 Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 P180L27 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 P180L28 P180L29 Even though this specification mandates that the branch parameter be P180L30 present in all requests, the BNF for the header field indicates that P180L31 it is optional. This allows interoperation with RFC 2543 elements, P180L32 which did not have to insert the branch parameter. P180L33 P180L34 Two Via header fields are equal if their sent-protocol and sent-by P180L35 fields are equal, both have the same set of parameters, and the P180L36 values of all parameters are equal. P180L37 P180L38 20.43 Warning P180L39 P180L40 The Warning header field is used to carry additional information P180L41 about the status of a response. Warning header field values are sent P180L42 with responses and contain a three-digit warning code, host name, and P180L43 warning text. P180L44 P180L45 The "warn-text" should be in a natural language that is most likely P180L46 to be intelligible to the human user receiving the response. This P180L47 decision can be based on any available knowledge, such as the P180L48 location of the user, the Accept-Language field in a request, or the P181L1 Content-Language field in a response. The default language is i- P181L2 default [21]. P181L3 P181L4 The currently-defined "warn-code"s are listed below, with a P181L5 recommended warn-text in English and a description of their meaning. P181L6 These warnings describe failures induced by the session description. P181L7 The first digit of warning codes beginning with "3" indicates P181L8 warnings specific to SIP. Warnings 300 through 329 are reserved for P181L9 indicating problems with keywords in the session description, 330 P181L10 through 339 are warnings related to basic network services requested P181L11 in the session description, 370 through 379 are warnings related to P181L12 quantitative QoS parameters requested in the session description, and P181L13 390 through 399 are miscellaneous warnings that do not fall into one P181L14 of the above categories. P181L15 P181L16 300 Incompatible network protocol: One or more network protocols P181L17 contained in the session description are not available. P181L18 P181L19 301 Incompatible network address formats: One or more network P181L20 address formats contained in the session description are not P181L21 available. P181L22 P181L23 302 Incompatible transport protocol: One or more transport P181L24 protocols described in the session description are not P181L25 available. P181L26 P181L27 303 Incompatible bandwidth units: One or more bandwidth P181L28 measurement units contained in the session description were P181L29 not understood. P181L30 P181L31 304 Media type not available: One or more media types contained in P181L32 the session description are not available. P181L33 P181L34 305 Incompatible media format: One or more media formats contained P181L35 in the session description are not available. P181L36 P181L37 306 Attribute not understood: One or more of the media attributes P181L38 in the session description are not supported. P181L39 P181L40 307 Session description parameter not understood: A parameter P181L41 other than those listed above was not understood. P181L42 P181L43 330 Multicast not available: The site where the user is located P181L44 does not support multicast. P181L45 P181L46 331 Unicast not available: The site where the user is located does P181L47 not support unicast communication (usually due to the presence P181L48 of a firewall). P182L1 370 Insufficient bandwidth: The bandwidth specified in the session P182L2 description or defined by the media exceeds that known to be P182L3 available. P182L4 P182L5 399 Miscellaneous warning: The warning text can include arbitrary P182L6 information to be presented to a human user or logged. A P182L7 system receiving this warning MUST NOT take any automated P182L8 action. P182L9 P182L10 1xx and 2xx have been taken by HTTP/1.1. P182L11 P182L12 Additional "warn-code"s can be defined through IANA, as defined in P182L13 Section 27.2. P182L14 P182L15 Examples: P182L16 P182L17 Warning: 307 isi.edu "Session parameter 'foo' not understood" P182L18 Warning: 301 isi.edu "Incompatible network address type 'E.164'" P182L19 P182L20 20.44 WWW-Authenticate P182L21 P182L22 A WWW-Authenticate header field value contains an authentication P182L23 challenge. See Section 22.2 for further details on its usage. P182L24 P182L25 Example: P182L26 P182L27 WWW-Authenticate: Digest realm="atlanta.com", P182L28 domain="sip:boxesbybob.com", qop="auth", P182L29 nonce="f84f1cec41e6cbe5aea9c8e88d359", P182L30 opaque="", stale=FALSE, algorithm=MD5 P182L31 P182L32 21 Response Codes P182L33 P182L34 The response codes are consistent with, and extend, HTTP/1.1 response P182L35 codes. Not all HTTP/1.1 response codes are appropriate, and only P182L36 those that are appropriate are given here. Other HTTP/1.1 response P182L37 codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. P182L38 P182L39 21.1 Provisional 1xx P182L40 P182L41 Provisional responses, also known as informational responses, P182L42 indicate that the server contacted is performing some further action P182L43 and does not yet have a definitive response. A server sends a 1xx P182L44 response if it expects to take more than 200 ms to obtain a final P182L45 response. Note that 1xx responses are not transmitted reliably. P182L46 They never cause the client to send an ACK. Provisional (1xx) P182L47 responses MAY contain message bodies, including session descriptions. P182L48 P183L1 21.1.1 100 Trying P183L2 P183L3 This response indicates that the request has been received by the P183L4 next-hop server and that some unspecified action is being taken on P183L5 behalf of this call (for example, a database is being consulted). P183L6 This response, like all other provisional responses, stops P183L7 retransmissions of an INVITE by a UAC. The 100 (Trying) response is P183L8 different from other provisional responses, in that it is never P183L9 forwarded upstream by a stateful proxy. P183L10 P183L11 21.1.2 180 Ringing P183L12 P183L13 The UA receiving the INVITE is trying to alert the user. This P183L14 response MAY be used to initiate local ringback. P183L15 P183L16 21.1.3 181 Call Is Being Forwarded P183L17 P183L18 A server MAY use this status code to indicate that the call is being P183L19 forwarded to a different set of destinations. P183L20 P183L21 21.1.4 182 Queued P183L22 P183L23 The called party is temporarily unavailable, but the server has P183L24 decided to queue the call rather than reject it. When the callee P183L25 becomes available, it will return the appropriate final status P183L26 response. The reason phrase MAY give further details about the P183L27 status of the call, for example, "5 calls queued; expected waiting P183L28 time is 15 minutes". The server MAY issue several 182 (Queued) P183L29 responses to update the caller about the status of the queued call. P183L30 P183L31 21.1.5 183 Session Progress P183L32 P183L33 The 183 (Session Progress) response is used to convey information P183L34 about the progress of the call that is not otherwise classified. The P183L35 Reason-Phrase, header fields, or message body MAY be used to convey P183L36 more details about the call progress. P183L37 P183L38 21.2 Successful 2xx P183L39 P183L40 The request was successful. P183L41 P183L42 21.2.1 200 OK P183L43 P183L44 The request has succeeded. The information returned with the P183L45 response depends on the method used in the request. P183L46 P183L47 P183L48 P184L1 21.3 Redirection 3xx P184L2 P184L3 3xx responses give information about the user's new location, or P184L4 about alternative services that might be able to satisfy the call. P184L5 P184L6 21.3.1 300 Multiple Choices P184L7 P184L8 The address in the request resolved to several choices, each with its P184L9 own specific location, and the user (or UA) can select a preferred P184L10 communication end point and redirect its request to that location. P184L11 P184L12 The response MAY include a message body containing a list of resource P184L13 characteristics and location(s) from which the user or UA can choose P184L14 the one most appropriate, if allowed by the Accept request header P184L15 field. However, no MIME types have been defined for this message P184L16 body. P184L17 P184L18 The choices SHOULD also be listed as Contact fields (Section 20.10). P184L19 Unlike HTTP, the SIP response MAY contain several Contact fields or a P184L20 list of addresses in a Contact field. UAs MAY use the Contact header P184L21 field value for automatic redirection or MAY ask the user to confirm P184L22 a choice. However, this specification does not define any standard P184L23 for such automatic selection. P184L24 P184L25 This status response is appropriate if the callee can be reached P184L26 at several different locations and the server cannot or prefers P184L27 not to proxy the request. P184L28 P184L29 21.3.2 301 Moved Permanently P184L30 P184L31 The user can no longer be found at the address in the Request-URI, P184L32 and the requesting client SHOULD retry at the new address given by P184L33 the Contact header field (Section 20.10). The requestor SHOULD P184L34 update any local directories, address books, and user location caches P184L35 with this new value and redirect future requests to the address(es) P184L36 listed. P184L37 P184L38 21.3.3 302 Moved Temporarily P184L39 P184L40 The requesting client SHOULD retry the request at the new address(es) P184L41 given by the Contact header field (Section 20.10). The Request-URI P184L42 of the new request uses the value of the Contact header field in the P184L43 response. P184L44 P184L45 P184L46 P184L47 P184L48 P185L1 The duration of the validity of the Contact URI can be indicated P185L2 through an Expires (Section 20.19) header field or an expires P185L3 parameter in the Contact header field. Both proxies and UAs MAY P185L4 cache this URI for the duration of the expiration time. If there is P185L5 no explicit expiration time, the address is only valid once for P185L6 recursing, and MUST NOT be cached for future transactions. P185L7 P185L8 If the URI cached from the Contact header field fails, the Request- P185L9 URI from the redirected request MAY be tried again a single time. P185L10 P185L11 The temporary URI may have become out-of-date sooner than the P185L12 expiration time, and a new temporary URI may be available. P185L13 P185L14 21.3.4 305 Use Proxy P185L15 P185L16 The requested resource MUST be accessed through the proxy given by P185L17 the Contact field. The Contact field gives the URI of the proxy. P185L18 The recipient is expected to repeat this single request via the P185L19 proxy. 305 (Use Proxy) responses MUST only be generated by UASs. P185L20 P185L21 21.3.5 380 Alternative Service P185L22 P185L23 The call was not successful, but alternative services are possible. P185L24 P185L25 The alternative services are described in the message body of the P185L26 response. Formats for such bodies are not defined here, and may be P185L27 the subject of future standardization. P185L28 P185L29 21.4 Request Failure 4xx P185L30 P185L31 4xx responses are definite failure responses from a particular P185L32 server. The client SHOULD NOT retry the same request without P185L33 modification (for example, adding appropriate authorization). P185L34 However, the same request to a different server might be successful. P185L35 P185L36 21.4.1 400 Bad Request P185L37 P185L38 The request could not be understood due to malformed syntax. The P185L39 Reason-Phrase SHOULD identify the syntax problem in more detail, for P185L40 example, "Missing Call-ID header field". P185L41 P185L42 21.4.2 401 Unauthorized P185L43 P185L44 The request requires user authentication. This response is issued by P185L45 UASs and registrars, while 407 (Proxy Authentication Required) is P185L46 used by proxy servers. P185L47 P185L48 P186L1 21.4.3 402 Payment Required P186L2 P186L3 Reserved for future use. P186L4 P186L5 21.4.4 403 Forbidden P186L6 P186L7 The server understood the request, but is refusing to fulfill it. P186L8 Authorization will not help, and the request SHOULD NOT be repeated. P186L9 P186L10 21.4.5 404 Not Found P186L11 P186L12 The server has definitive information that the user does not exist at P186L13 the domain specified in the Request-URI. This status is also P186L14 returned if the domain in the Request-URI does not match any of the P186L15 domains handled by the recipient of the request. P186L16 P186L17 21.4.6 405 Method Not Allowed P186L18 P186L19 The method specified in the Request-Line is understood, but not P186L20 allowed for the address identified by the Request-URI. P186L21 P186L22 The response MUST include an Allow header field containing a list of P186L23 valid methods for the indicated address. P186L24 P186L25 21.4.7 406 Not Acceptable P186L26 P186L27 The resource identified by the request is only capable of generating P186L28 response entities that have content characteristics not acceptable P186L29 according to the Accept header field sent in the request. P186L30 P186L31 21.4.8 407 Proxy Authentication Required P186L32 P186L33 This code is similar to 401 (Unauthorized), but indicates that the P186L34 client MUST first authenticate itself with the proxy. SIP access P186L35 authentication is explained in Sections 26 and 22.3. P186L36 P186L37 This status code can be used for applications where access to the P186L38 communication channel (for example, a telephony gateway) rather than P186L39 the callee requires authentication. P186L40 P186L41 21.4.9 408 Request Timeout P186L42 P186L43 The server could not produce a response within a suitable amount of P186L44 time, for example, if it could not determine the location of the user P186L45 in time. The client MAY repeat the request without modifications at P186L46 any later time. P186L47 P186L48 P187L1 21.4.10 410 Gone P187L2 P187L3 The requested resource is no longer available at the server and no P187L4 forwarding address is known. This condition is expected to be P187L5 considered permanent. If the server does not know, or has no P187L6 facility to determine, whether or not the condition is permanent, the P187L7 status code 404 (Not Found) SHOULD be used instead. P187L8 P187L9 21.4.11 413 Request Entity Too Large P187L10 P187L11 The server is refusing to process a request because the request P187L12 entity-body is larger than the server is willing or able to process. P187L13 The server MAY close the connection to prevent the client from P187L14 continuing the request. P187L15 P187L16 If the condition is temporary, the server SHOULD include a Retry- P187L17 After header field to indicate that it is temporary and after what P187L18 time the client MAY try again. P187L19 P187L20 21.4.12 414 Request-URI Too Long P187L21 P187L22 The server is refusing to service the request because the Request-URI P187L23 is longer than the server is willing to interpret. P187L24 P187L25 21.4.13 415 Unsupported Media Type P187L26 P187L27 The server is refusing to service the request because the message P187L28 body of the request is in a format not supported by the server for P187L29 the requested method. The server MUST return a list of acceptable P187L30 formats using the Accept, Accept-Encoding, or Accept-Language header P187L31 field, depending on the specific problem with the content. UAC P187L32 processing of this response is described in Section 8.1.3.5. P187L33 P187L34 21.4.14 416 Unsupported URI Scheme P187L35 P187L36 The server cannot process the request because the scheme of the URI P187L37 in the Request-URI is unknown to the server. Client processing of P187L38 this response is described in Section 8.1.3.5. P187L39 P187L40 21.4.15 420 Bad Extension P187L41 P187L42 The server did not understand the protocol extension specified in a P187L43 Proxy-Require (Section 20.29) or Require (Section 20.32) header P187L44 field. The server MUST include a list of the unsupported extensions P187L45 in an Unsupported header field in the response. UAC processing of P187L46 this response is described in Section 8.1.3.5. P187L47 P187L48 P188L1 21.4.16 421 Extension Required P188L2 P188L3 The UAS needs a particular extension to process the request, but this P188L4 extension is not listed in a Supported header field in the request. P188L5 Responses with this status code MUST contain a Require header field P188L6 listing the required extensions. P188L7 P188L8 A UAS SHOULD NOT use this response unless it truly cannot provide any P188L9 useful service to the client. Instead, if a desirable extension is P188L10 not listed in the Supported header field, servers SHOULD process the P188L11 request using baseline SIP capabilities and any extensions supported P188L12 by the client. P188L13 P188L14 21.4.17 423 Interval Too Brief P188L15 P188L16 The server is rejecting the request because the expiration time of P188L17 the resource refreshed by the request is too short. This response P188L18 can be used by a registrar to reject a registration whose Contact P188L19 header field expiration time was too small. The use of this response P188L20 and the related Min-Expires header field are described in Sections P188L21 10.2.8, 10.3, and 20.23. P188L22 P188L23 21.4.18 480 Temporarily Unavailable P188L24 P188L25 The callee's end system was contacted successfully but the callee is P188L26 currently unavailable (for example, is not logged in, logged in but P188L27 in a state that precludes communication with the callee, or has P188L28 activated the "do not disturb" feature). The response MAY indicate a P188L29 better time to call in the Retry-After header field. The user could P188L30 also be available elsewhere (unbeknownst to this server). The reason P188L31 phrase SHOULD indicate a more precise cause as to why the callee is P188L32 unavailable. This value SHOULD be settable by the UA. Status 486 P188L33 (Busy Here) MAY be used to more precisely indicate a particular P188L34 reason for the call failure. P188L35 P188L36 This status is also returned by a redirect or proxy server that P188L37 recognizes the user identified by the Request-URI, but does not P188L38 currently have a valid forwarding location for that user. P188L39 P188L40 21.4.19 481 Call/Transaction Does Not Exist P188L41 P188L42 This status indicates that the UAS received a request that does not P188L43 match any existing dialog or transaction. P188L44 P188L45 21.4.20 482 Loop Detected P188L46 P188L47 The server has detected a loop (Section 16.3 Item 4). P188L48 P189L1 21.4.21 483 Too Many Hops P189L2 P189L3 The server received a request that contains a Max-Forwards (Section P189L4 20.22) header field with the value zero. P189L5 P189L6 21.4.22 484 Address Incomplete P189L7 P189L8 The server received a request with a Request-URI that was incomplete. P189L9 Additional information SHOULD be provided in the reason phrase. P189L10 P189L11 This status code allows overlapped dialing. With overlapped P189L12 dialing, the client does not know the length of the dialing P189L13 string. It sends strings of increasing lengths, prompting the P189L14 user for more input, until it no longer receives a 484 (Address P189L15 Incomplete) status response. P189L16 P189L17 21.4.23 485 Ambiguous P189L18 P189L19 The Request-URI was ambiguous. The response MAY contain a listing of P189L20 possible unambiguous addresses in Contact header fields. Revealing P189L21 alternatives can infringe on privacy of the user or the organization. P189L22 It MUST be possible to configure a server to respond with status 404 P189L23 (Not Found) or to suppress the listing of possible choices for P189L24 ambiguous Request-URIs. P189L25 P189L26 Example response to a request with the Request-URI P189L27 sip:lee@example.com: P189L28 P189L29 SIP/2.0 485 Ambiguous P189L30 Contact: Carol Lee P189L31 Contact: Ping Lee P189L32 Contact: Lee M. Foote P189L33 P189L34 Some email and voice mail systems provide this functionality. A P189L35 status code separate from 3xx is used since the semantics are P189L36 different: for 300, it is assumed that the same person or service P189L37 will be reached by the choices provided. While an automated P189L38 choice or sequential search makes sense for a 3xx response, user P189L39 intervention is required for a 485 (Ambiguous) response. P189L40 P189L41 21.4.24 486 Busy Here P189L42 P189L43 The callee's end system was contacted successfully, but the callee is P189L44 currently not willing or able to take additional calls at this end P189L45 system. The response MAY indicate a better time to call in the P189L46 Retry-After header field. The user could also be available P189L47 P189L48 P190L1 elsewhere, such as through a voice mail service. Status 600 (Busy P190L2 Everywhere) SHOULD be used if the client knows that no other end P190L3 system will be able to accept this call. P190L4 P190L5 21.4.25 487 Request Terminated P190L6 P190L7 The request was terminated by a BYE or CANCEL request. This response P190L8 is never returned for a CANCEL request itself. P190L9 P190L10 21.4.26 488 Not Acceptable Here P190L11 P190L12 The response has the same meaning as 606 (Not Acceptable), but only P190L13 applies to the specific resource addressed by the Request-URI and the P190L14 request may succeed elsewhere. P190L15 P190L16 A message body containing a description of media capabilities MAY be P190L17 present in the response, which is formatted according to the Accept P190L18 header field in the INVITE (or application/sdp if not present), the P190L19 same as a message body in a 200 (OK) response to an OPTIONS request. P190L20 P190L21 21.4.27 491 Request Pending P190L22 P190L23 The request was received by a UAS that had a pending request within P190L24 the same dialog. Section 14.2 describes how such "glare" situations P190L25 are resolved. P190L26 P190L27 21.4.28 493 Undecipherable P190L28 P190L29 The request was received by a UAS that contained an encrypted MIME P190L30 body for which the recipient does not possess or will not provide an P190L31 appropriate decryption key. This response MAY have a single body P190L32 containing an appropriate public key that should be used to encrypt P190L33 MIME bodies sent to this UA. Details of the usage of this response P190L34 code can be found in Section 23.2. P190L35 P190L36 21.5 Server Failure 5xx P190L37 P190L38 5xx responses are failure responses given when a server itself has P190L39 erred. P190L40 P190L41 21.5.1 500 Server Internal Error P190L42 P190L43 The server encountered an unexpected condition that prevented it from P190L44 fulfilling the request. The client MAY display the specific error P190L45 condition and MAY retry the request after several seconds. P190L46 P190L47 If the condition is temporary, the server MAY indicate when the P190L48 client may retry the request using the Retry-After header field. P191L1 21.5.2 501 Not Implemented P191L2 P191L3 The server does not support the functionality required to fulfill the P191L4 request. This is the appropriate response when a UAS does not P191L5 recognize the request method and is not capable of supporting it for P191L6 any user. (Proxies forward all requests regardless of method.) P191L7 P191L8 Note that a 405 (Method Not Allowed) is sent when the server P191L9 recognizes the request method, but that method is not allowed or P191L10 supported. P191L11 P191L12 21.5.3 502 Bad Gateway P191L13 P191L14 The server, while acting as a gateway or proxy, received an invalid P191L15 response from the downstream server it accessed in attempting to P191L16 fulfill the request. P191L17 P191L18 21.5.4 503 Service Unavailable P191L19 P191L20 The server is temporarily unable to process the request due to a P191L21 temporary overloading or maintenance of the server. The server MAY P191L22 indicate when the client should retry the request in a Retry-After P191L23 header field. If no Retry-After is given, the client MUST act as if P191L24 it had received a 500 (Server Internal Error) response. P191L25 P191L26 A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD P191L27 attempt to forward the request to an alternate server. It SHOULD NOT P191L28 forward any other requests to that server for the duration specified P191L29 in the Retry-After header field, if present. P191L30 P191L31 Servers MAY refuse the connection or drop the request instead of P191L32 responding with 503 (Service Unavailable). P191L33 P191L34 21.5.5 504 Server Time-out P191L35 P191L36 The server did not receive a timely response from an external server P191L37 it accessed in attempting to process the request. 408 (Request P191L38 Timeout) should be used instead if there was no response within the P191L39 period specified in the Expires header field from the upstream P191L40 server. P191L41 P191L42 21.5.6 505 Version Not Supported P191L43 P191L44 The server does not support, or refuses to support, the SIP protocol P191L45 version that was used in the request. The server is indicating that P191L46 it is unable or unwilling to complete the request using the same P191L47 major version as the client, other than with this error message. P191L48 P192L1 21.5.7 513 Message Too Large P192L2 P192L3 The server was unable to process the request since the message length P192L4 exceeded its capabilities. P192L5 P192L6 21.6 Global Failures 6xx P192L7 P192L8 6xx responses indicate that a server has definitive information about P192L9 a particular user, not just the particular instance indicated in the P192L10 Request-URI. P192L11 P192L12 21.6.1 600 Busy Everywhere P192L13 P192L14 The callee's end system was contacted successfully but the callee is P192L15 busy and does not wish to take the call at this time. The response P192L16 MAY indicate a better time to call in the Retry-After header field. P192L17 If the callee does not wish to reveal the reason for declining the P192L18 call, the callee uses status code 603 (Decline) instead. This status P192L19 response is returned only if the client knows that no other end point P192L20 (such as a voice mail system) will answer the request. Otherwise, P192L21 486 (Busy Here) should be returned. P192L22 P192L23 21.6.2 603 Decline P192L24 P192L25 The callee's machine was successfully contacted but the user P192L26 explicitly does not wish to or cannot participate. The response MAY P192L27 indicate a better time to call in the Retry-After header field. This P192L28 status response is returned only if the client knows that no other P192L29 end point will answer the request. P192L30 P192L31 21.6.3 604 Does Not Exist Anywhere P192L32 P192L33 The server has authoritative information that the user indicated in P192L34 the Request-URI does not exist anywhere. P192L35 P192L36 21.6.4 606 Not Acceptable P192L37 P192L38 The user's agent was contacted successfully but some aspects of the P192L39 session description such as the requested media, bandwidth, or P192L40 addressing style were not acceptable. P192L41 P192L42 A 606 (Not Acceptable) response means that the user wishes to P192L43 communicate, but cannot adequately support the session described. P192L44 The 606 (Not Acceptable) response MAY contain a list of reasons in a P192L45 Warning header field describing why the session described cannot be P192L46 supported. Warning reason codes are listed in Section 20.43. P192L47 P192L48 P193L1 A message body containing a description of media capabilities MAY be P193L2 present in the response, which is formatted according to the Accept P193L3 header field in the INVITE (or application/sdp if not present), the P193L4 same as a message body in a 200 (OK) response to an OPTIONS request. P193L5 P193L6 It is hoped that negotiation will not frequently be needed, and when P193L7 a new user is being invited to join an already existing conference, P193L8 negotiation may not be possible. It is up to the invitation P193L9 initiator to decide whether or not to act on a 606 (Not Acceptable) P193L10 response. P193L11 P193L12 This status response is returned only if the client knows that no P193L13 other end point will answer the request. P193L14 P193L15 22 Usage of HTTP Authentication P193L16 P193L17 SIP provides a stateless, challenge-based mechanism for P193L18 authentication that is based on authentication in HTTP. Any time P193L19 that a proxy server or UA receives a request (with the exceptions P193L20 given in Section 22.1), it MAY challenge the initiator of the request P193L21 to provide assurance of its identity. Once the originator has been P193L22 identified, the recipient of the request SHOULD ascertain whether or P193L23 not this user is authorized to make the request in question. No P193L24 authorization systems are recommended or discussed in this document. P193L25 P193L26 The "Digest" authentication mechanism described in this section P193L27 provides message authentication and replay protection only, without P193L28 message integrity or confidentiality. Protective measures above and P193L29 beyond those provided by Digest need to be taken to prevent active P193L30 attackers from modifying SIP requests and responses. P193L31 P193L32 Note that due to its weak security, the usage of "Basic" P193L33 authentication has been deprecated. Servers MUST NOT accept P193L34 credentials using the "Basic" authorization scheme, and servers also P193L35 MUST NOT challenge with "Basic". This is a change from RFC 2543. P193L36 P193L37 22.1 Framework P193L38 P193L39 The framework for SIP authentication closely parallels that of HTTP P193L40 (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, P193L41 challenge, realm, realm-value, and credentials is identical (although P193L42 the usage of "Basic" as a scheme is not permitted). In SIP, a UAS P193L43 uses the 401 (Unauthorized) response to challenge the identity of a P193L44 UAC. Additionally, registrars and redirect servers MAY make use of P193L45 401 (Unauthorized) responses for authentication, but proxies MUST P193L46 NOT, and instead MAY use the 407 (Proxy Authentication Required) P193L47 P193L48 P194L1 response. The requirements for inclusion of the Proxy-Authenticate, P194L2 Proxy-Authorization, WWW-Authenticate, and Authorization in the P194L3 various messages are identical to those described in RFC 2617 [17]. P194L4 P194L5 Since SIP does not have the concept of a canonical root URL, the P194L6 notion of protection spaces is interpreted differently in SIP. The P194L7 realm string alone defines the protection domain. This is a change P194L8 from RFC 2543, in which the Request-URI and the realm together P194L9 defined the protection domain. P194L10 P194L11 This previous definition of protection domain caused some amount P194L12 of confusion since the Request-URI sent by the UAC and the P194L13 Request-URI received by the challenging server might be different, P194L14 and indeed the final form of the Request-URI might not be known to P194L15 the UAC. Also, the previous definition depended on the presence P194L16 of a SIP URI in the Request-URI and seemed to rule out alternative P194L17 URI schemes (for example, the tel URL). P194L18 P194L19 Operators of user agents or proxy servers that will authenticate P194L20 received requests MUST adhere to the following guidelines for P194L21 creation of a realm string for their server: P194L22 P194L23 o Realm strings MUST be globally unique. It is RECOMMENDED that P194L24 a realm string contain a hostname or domain name, following the P194L25 recommendation in Section 3.2.1 of RFC 2617 [17]. P194L26 P194L27 o Realm strings SHOULD present a human-readable identifier that P194L28 can be rendered to a user. P194L29 P194L30 For example: P194L31 P194L32 INVITE sip:bob@biloxi.com SIP/2.0 P194L33 Authorization: Digest realm="biloxi.com", <...> P194L34 P194L35 Generally, SIP authentication is meaningful for a specific realm, a P194L36 protection domain. Thus, for Digest authentication, each such P194L37 protection domain has its own set of usernames and passwords. If a P194L38 server does not require authentication for a particular request, it P194L39 MAY accept a default username, "anonymous", which has no password P194L40 (password of ""). Similarly, UACs representing many users, such as P194L41 PSTN gateways, MAY have their own device-specific username and P194L42 password, rather than accounts for particular users, for their realm. P194L43 P194L44 While a server can legitimately challenge most SIP requests, there P194L45 are two requests defined by this document that require special P194L46 handling for authentication: ACK and CANCEL. P194L47 P194L48 P195L1 Under an authentication scheme that uses responses to carry values P195L2 used to compute nonces (such as Digest), some problems come up for P195L3 any requests that take no response, including ACK. For this reason, P195L4 any credentials in the INVITE that were accepted by a server MUST be P195L5 accepted by that server for the ACK. UACs creating an ACK message P195L6 will duplicate all of the Authorization and Proxy-Authorization P195L7 header field values that appeared in the INVITE to which the ACK P195L8 corresponds. Servers MUST NOT attempt to challenge an ACK. P195L9 P195L10 Although the CANCEL method does take a response (a 2xx), servers MUST P195L11 NOT attempt to challenge CANCEL requests since these requests cannot P195L12 be resubmitted. Generally, a CANCEL request SHOULD be accepted by a P195L13 server if it comes from the same hop that sent the request being P195L14 canceled (provided that some sort of transport or network layer P195L15 security association, as described in Section 26.2.1, is in place). P195L16 P195L17 When a UAC receives a challenge, it SHOULD render to the user the P195L18 contents of the "realm" parameter in the challenge (which appears in P195L19 either a WWW-Authenticate header field or Proxy-Authenticate header P195L20 field) if the UAC device does not already know of a credential for P195L21 the realm in question. A service provider that pre-configures UAs P195L22 with credentials for its realm should be aware that users will not P195L23 have the opportunity to present their own credentials for this realm P195L24 when challenged at a pre-configured device. P195L25 P195L26 Finally, note that even if a UAC can locate credentials that are P195L27 associated with the proper realm, the potential exists that these P195L28 credentials may no longer be valid or that the challenging server P195L29 will not accept these credentials for whatever reason (especially P195L30 when "anonymous" with no password is submitted). In this instance a P195L31 server may repeat its challenge, or it may respond with a 403 P195L32 Forbidden. A UAC MUST NOT re-attempt requests with the credentials P195L33 that have just been rejected (though the request may be retried if P195L34 the nonce was stale). P195L35 P195L36 22.2 User-to-User Authentication P195L37 P195L38 When a UAS receives a request from a UAC, the UAS MAY authenticate P195L39 the originator before the request is processed. If no credentials P195L40 (in the Authorization header field) are provided in the request, the P195L41 UAS can challenge the originator to provide credentials by rejecting P195L42 the request with a 401 (Unauthorized) status code. P195L43 P195L44 The WWW-Authenticate response-header field MUST be included in 401 P195L45 (Unauthorized) response messages. The field value consists of at P195L46 least one challenge that indicates the authentication scheme(s) and P195L47 parameters applicable to the realm. P195L48 P196L1 An example of the WWW-Authenticate header field in a 401 challenge P196L2 is: P196L3 P196L4 WWW-Authenticate: Digest P196L5 realm="biloxi.com", P196L6 qop="auth,auth-int", P196L7 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", P196L8 opaque="5ccc069c403ebaf9f0171e9517f40e41" P196L9 P196L10 When the originating UAC receives the 401 (Unauthorized), it SHOULD, P196L11 if it is able, re-originate the request with the proper credentials. P196L12 The UAC may require input from the originating user before P196L13 proceeding. Once authentication credentials have been supplied P196L14 (either directly by the user, or discovered in an internal keyring), P196L15 UAs SHOULD cache the credentials for a given value of the To header P196L16 field and "realm" and attempt to re-use these values on the next P196L17 request for that destination. UAs MAY cache credentials in any way P196L18 they would like. P196L19 P196L20 If no credentials for a realm can be located, UACs MAY attempt to P196L21 retry the request with a username of "anonymous" and no password (a P196L22 password of ""). P196L23 P196L24 Once credentials have been located, any UA that wishes to P196L25 authenticate itself with a UAS or registrar -- usually, but not P196L26 necessarily, after receiving a 401 (Unauthorized) response -- MAY do P196L27 so by including an Authorization header field with the request. The P196L28 Authorization field value consists of credentials containing the P196L29 authentication information of the UA for the realm of the resource P196L30 being requested as well as parameters required in support of P196L31 authentication and replay protection. P196L32 P196L33 An example of the Authorization header field is: P196L34 P196L35 Authorization: Digest username="bob", P196L36 realm="biloxi.com", P196L37 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", P196L38 uri="sip:bob@biloxi.com", P196L39 qop=auth, P196L40 nc=00000001, P196L41 cnonce="0a4f113b", P196L42 response="6629fae49393a05397450978507c4ef1", P196L43 opaque="5ccc069c403ebaf9f0171e9517f40e41" P196L44 P196L45 When a UAC resubmits a request with its credentials after receiving a P196L46 401 (Unauthorized) or 407 (Proxy Authentication Required) response, P196L47 it MUST increment the CSeq header field value as it would normally P196L48 when sending an updated request. P197L1 22.3 Proxy-to-User Authentication P197L2 P197L3 Similarly, when a UAC sends a request to a proxy server, the proxy P197L4 server MAY authenticate the originator before the request is P197L5 processed. If no credentials (in the Proxy-Authorization header P197L6 field) are provided in the request, the proxy can challenge the P197L7 originator to provide credentials by rejecting the request with a 407 P197L8 (Proxy Authentication Required) status code. The proxy MUST populate P197L9 the 407 (Proxy Authentication Required) message with a Proxy- P197L10 Authenticate header field value applicable to the proxy for the P197L11 requested resource. P197L12 P197L13 The use of Proxy-Authenticate and Proxy-Authorization parallel that P197L14 described in [17], with one difference. Proxies MUST NOT add values P197L15 to the Proxy-Authorization header field. All 407 (Proxy P197L16 Authentication Required) responses MUST be forwarded upstream toward P197L17 the UAC following the procedures for any other response. It is the P197L18 UAC's responsibility to add the Proxy-Authorization header field P197L19 value containing credentials for the realm of the proxy that has P197L20 asked for authentication. P197L21 P197L22 If a proxy were to resubmit a request adding a Proxy-Authorization P197L23 header field value, it would need to increment the CSeq in the new P197L24 request. However, this would cause the UAC that submitted the P197L25 original request to discard a response from the UAS, as the CSeq P197L26 value would be different. P197L27 P197L28 When the originating UAC receives the 407 (Proxy Authentication P197L29 Required) it SHOULD, if it is able, re-originate the request with the P197L30 proper credentials. It should follow the same procedures for the P197L31 display of the "realm" parameter that are given above for responding P197L32 to 401. P197L33 P197L34 If no credentials for a realm can be located, UACs MAY attempt to P197L35 retry the request with a username of "anonymous" and no password (a P197L36 password of ""). P197L37 P197L38 The UAC SHOULD also cache the credentials used in the re-originated P197L39 request. P197L40 P197L41 The following rule is RECOMMENDED for proxy credential caching: P197L42 P197L43 If a UA receives a Proxy-Authenticate header field value in a 401/407 P197L44 response to a request with a particular Call-ID, it should P197L45 incorporate credentials for that realm in all subsequent requests P197L46 that contain the same Call-ID. These credentials MUST NOT be cached P197L47 across dialogs; however, if a UA is configured with the realm of its P197L48 local outbound proxy, when one exists, then the UA MAY cache P198L1 credentials for that realm across dialogs. Note that this does mean P198L2 a future request in a dialog could contain credentials that are not P198L3 needed by any proxy along the Route header path. P198L4 P198L5 Any UA that wishes to authenticate itself to a proxy server -- P198L6 usually, but not necessarily, after receiving a 407 (Proxy P198L7 Authentication Required) response -- MAY do so by including a Proxy- P198L8 Authorization header field value with the request. The Proxy- P198L9 Authorization request-header field allows the client to identify P198L10 itself (or its user) to a proxy that requires authentication. The P198L11 Proxy-Authorization header field value consists of credentials P198L12 containing the authentication information of the UA for the proxy P198L13 and/or realm of the resource being requested. P198L14 P198L15 A Proxy-Authorization header field value applies only to the proxy P198L16 whose realm is identified in the "realm" parameter (this proxy may P198L17 previously have demanded authentication using the Proxy-Authenticate P198L18 field). When multiple proxies are used in a chain, a Proxy- P198L19 Authorization header field value MUST NOT be consumed by any proxy P198L20 whose realm does not match the "realm" parameter specified in that P198L21 value. P198L22 P198L23 Note that if an authentication scheme that does not support realms is P198L24 used in the Proxy-Authorization header field, a proxy server MUST P198L25 attempt to parse all Proxy-Authorization header field values to P198L26 determine whether one of them has what the proxy server considers to P198L27 be valid credentials. Because this is potentially very time- P198L28 consuming in large networks, proxy servers SHOULD use an P198L29 authentication scheme that supports realms in the Proxy-Authorization P198L30 header field. P198L31 P198L32 If a request is forked (as described in Section 16.7), various proxy P198L33 servers and/or UAs may wish to challenge the UAC. In this case, the P198L34 forking proxy server is responsible for aggregating these challenges P198L35 into a single response. Each WWW-Authenticate and Proxy-Authenticate P198L36 value received in responses to the forked request MUST be placed into P198L37 the single response that is sent by the forking proxy to the UA; the P198L38 ordering of these header field values is not significant. P198L39 P198L40 When a proxy server issues a challenge in response to a request, P198L41 it will not proxy the request until the UAC has retried the P198L42 request with valid credentials. A forking proxy may forward a P198L43 request simultaneously to multiple proxy servers that require P198L44 authentication, each of which in turn will not forward the request P198L45 until the originating UAC has authenticated itself in their P198L46 respective realm. If the UAC does not provide credentials for P198L47 P198L48 P199L1 each challenge, the proxy servers that issued the challenges will P199L2 not forward requests to the UA where the destination user might be P199L3 located, and therefore, the virtues of forking are largely lost. P199L4 P199L5 When resubmitting its request in response to a 401 (Unauthorized) or P199L6 407 (Proxy Authentication Required) that contains multiple P199L7 challenges, a UAC MAY include an Authorization value for each WWW- P199L8 Authenticate value and a Proxy-Authorization value for each Proxy- P199L9 Authenticate value for which the UAC wishes to supply a credential. P199L10 As noted above, multiple credentials in a request SHOULD be P199L11 differentiated by the "realm" parameter. P199L12 P199L13 It is possible for multiple challenges associated with the same realm P199L14 to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication P199L15 Required). This can occur, for example, when multiple proxies within P199L16 the same administrative domain, which use a common realm, are reached P199L17 by a forking request. When it retries a request, a UAC MAY therefore P199L18 supply multiple credentials in Authorization or Proxy-Authorization P199L19 header fields with the same "realm" parameter value. The same P199L20 credentials SHOULD be used for the same realm. P199L21 P199L22 22.4 The Digest Authentication Scheme P199L23 P199L24 This section describes the modifications and clarifications required P199L25 to apply the HTTP Digest authentication scheme to SIP. The SIP P199L26 scheme usage is almost completely identical to that for HTTP [17]. P199L27 P199L28 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], P199L29 SIP servers supporting RFC 2617 MUST ensure they are backwards P199L30 compatible with RFC 2069. Procedures for this backwards P199L31 compatibility are specified in RFC 2617. Note, however, that SIP P199L32 servers MUST NOT accept or request Basic authentication. P199L33 P199L34 The rules for Digest authentication follow those defined in [17], P199L35 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following P199L36 differences: P199L37 P199L38 1. The URI included in the challenge has the following BNF: P199L39 P199L40 URI = SIP-URI / SIPS-URI P199L41 P199L42 2. The BNF in RFC 2617 has an error in that the 'uri' parameter P199L43 of the Authorization header field for HTTP Digest P199L44 P199L45 P199L46 P199L47 P199L48 P200L1 authentication is not enclosed in quotation marks. (The P200L2 example in Section 3.5 of RFC 2617 is correct.) For SIP, the P200L3 'uri' MUST be enclosed in quotation marks. P200L4 P200L5 3. The BNF for digest-uri-value is: P200L6 P200L7 digest-uri-value = Request-URI ; as defined in Section 25 P200L8 P200L9 4. The example procedure for choosing a nonce based on Etag does P200L10 not work for SIP. P200L11 P200L12 5. The text in RFC 2617 [17] regarding cache operation does not P200L13 apply to SIP. P200L14 P200L15 6. RFC 2617 [17] requires that a server check that the URI in the P200L16 request line and the URI included in the Authorization header P200L17 field point to the same resource. In a SIP context, these two P200L18 URIs may refer to different users, due to forwarding at some P200L19 proxy. Therefore, in SIP, a server MAY check that the P200L20 Request-URI in the Authorization header field value P200L21 corresponds to a user for whom the server is willing to accept P200L22 forwarded or direct requests, but it is not necessarily a P200L23 failure if the two fields are not equivalent. P200L24 P200L25 7. As a clarification to the calculation of the A2 value for P200L26 message integrity assurance in the Digest authentication P200L27 scheme, implementers should assume, when the entity-body is P200L28 empty (that is, when SIP messages have no body) that the hash P200L29 of the entity-body resolves to the MD5 hash of an empty P200L30 string, or: P200L31 P200L32 H(entity-body) = MD5("") = P200L33 "d41d8cd98f00b204e9800998ecf8427e" P200L34 P200L35 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an P200L36 Authorization (and by extension Proxy-Authorization) header P200L37 field if no qop directive has been sent. Therefore, any P200L38 algorithms that have a dependency on the cnonce (including P200L39 "MD5-Sess") require that the qop directive be sent. Use of P200L40 the "qop" parameter is optional in RFC 2617 for the purposes P200L41 of backwards compatibility with RFC 2069; since RFC 2543 was P200L42 based on RFC 2069, the "qop" parameter must unfortunately P200L43 remain optional for clients and servers to receive. However, P200L44 servers MUST always send a "qop" parameter in WWW-Authenticate P200L45 and Proxy-Authenticate header field values. If a client P200L46 receives a "qop" parameter in a challenge header field, it P200L47 MUST send the "qop" parameter in any resulting authorization P200L48 header field. P201L1 RFC 2543 did not allow usage of the Authentication-Info header field P201L2 (it effectively used RFC 2069). However, we now allow usage of this P201L3 header field, since it provides integrity checks over the bodies and P201L4 provides mutual authentication. RFC 2617 [17] defines mechanisms for P201L5 backwards compatibility using the qop attribute in the request. P201L6 These mechanisms MUST be used by a server to determine if the client P201L7 supports the new mechanisms in RFC 2617 that were not specified in P201L8 RFC 2069. P201L9 P201L10 23 S/MIME P201L11 P201L12 SIP messages carry MIME bodies and the MIME standard includes P201L13 mechanisms for securing MIME contents to ensure both integrity and P201L14 confidentiality (including the 'multipart/signed' and P201L15 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] P201L16 and RFC 2633 [24]). Implementers should note, however, that there P201L17 may be rare network intermediaries (not typical proxy servers) that P201L18 rely on viewing or modifying the bodies of SIP messages (especially P201L19 SDP), and that secure MIME may prevent these sorts of intermediaries P201L20 from functioning. P201L21 P201L22 This applies particularly to certain types of firewalls. P201L23 P201L24 The PGP mechanism for encrypting the header fields and bodies of P201L25 SIP messages described in RFC 2543 has been deprecated. P201L26 P201L27 23.1 S/MIME Certificates P201L28 P201L29 The certificates that are used to identify an end-user for the P201L30 purposes of S/MIME differ from those used by servers in one important P201L31 respect - rather than asserting that the identity of the holder P201L32 corresponds to a particular hostname, these certificates assert that P201L33 the holder is identified by an end-user address. This address is P201L34 composed of the concatenation of the "userinfo" "@" and "domainname" P201L35 portions of a SIP or SIPS URI (in other words, an email address of P201L36 the form "bob@biloxi.com"), most commonly corresponding to a user's P201L37 address-of-record. P201L38 P201L39 These certificates are also associated with keys that are used to P201L40 sign or encrypt bodies of SIP messages. Bodies are signed with the P201L41 private key of the sender (who may include their public key with the P201L42 message as appropriate), but bodies are encrypted with the public key P201L43 of the intended recipient. Obviously, senders must have P201L44 foreknowledge of the public key of recipients in order to encrypt P201L45 message bodies. Public keys can be stored within a UA on a virtual P201L46 keyring. P201L47 P201L48 P202L1 Each user agent that supports S/MIME MUST contain a keyring P202L2 specifically for end-users' certificates. This keyring should map P202L3 between addresses of record and corresponding certificates. Over P202L4 time, users SHOULD use the same certificate when they populate the P202L5 originating URI of signaling (the From header field) with the same P202L6 address-of-record. P202L7 P202L8 Any mechanisms depending on the existence of end-user certificates P202L9 are seriously limited in that there is virtually no consolidated P202L10 authority today that provides certificates for end-user applications. P202L11 However, users SHOULD acquire certificates from known public P202L12 certificate authorities. As an alternative, users MAY create self- P202L13 signed certificates. The implications of self-signed certificates P202L14 are explored further in Section 26.4.2. Implementations may also use P202L15 pre-configured certificates in deployments in which a previous trust P202L16 relationship exists between all SIP entities. P202L17 P202L18 Above and beyond the problem of acquiring an end-user certificate, P202L19 there are few well-known centralized directories that distribute P202L20 end-user certificates. However, the holder of a certificate SHOULD P202L21 publish their certificate in any public directories as appropriate. P202L22 Similarly, UACs SHOULD support a mechanism for importing (manually or P202L23 automatically) certificates discovered in public directories P202L24 corresponding to the target URIs of SIP requests. P202L25 P202L26 23.2 S/MIME Key Exchange P202L27 P202L28 SIP itself can also be used as a means to distribute public keys in P202L29 the following manner. P202L30 P202L31 Whenever the CMS SignedData message is used in S/MIME for SIP, it P202L32 MUST contain the certificate bearing the public key necessary to P202L33 verify the signature. P202L34 P202L35 When a UAC sends a request containing an S/MIME body that initiates a P202L36 dialog, or sends a non-INVITE request outside the context of a P202L37 dialog, the UAC SHOULD structure the body as an S/MIME P202L38 'multipart/signed' CMS SignedData body. If the desired CMS service P202L39 is EnvelopedData (and the public key of the target user is known), P202L40 the UAC SHOULD send the EnvelopedData message encapsulated within a P202L41 SignedData message. P202L42 P202L43 When a UAS receives a request containing an S/MIME CMS body that P202L44 includes a certificate, the UAS SHOULD first validate the P202L45 certificate, if possible, with any available root certificates for P202L46 certificate authorities. The UAS SHOULD also determine the subject P202L47 of the certificate (for S/MIME, the SubjectAltName will contain the P202L48 appropriate identity) and compare this value to the From header field P203L1 of the request. If the certificate cannot be verified, because it is P203L2 self-signed, or signed by no known authority, or if it is verifiable P203L3 but its subject does not correspond to the From header field of P203L4 request, the UAS MUST notify its user of the status of the P203L5 certificate (including the subject of the certificate, its signer, P203L6 and any key fingerprint information) and request explicit permission P203L7 before proceeding. If the certificate was successfully verified and P203L8 the subject of the certificate corresponds to the From header field P203L9 of the SIP request, or if the user (after notification) explicitly P203L10 authorizes the use of the certificate, the UAS SHOULD add this P203L11 certificate to a local keyring, indexed by the address-of-record of P203L12 the holder of the certificate. P203L13 P203L14 When a UAS sends a response containing an S/MIME body that answers P203L15 the first request in a dialog, or a response to a non-INVITE request P203L16 outside the context of a dialog, the UAS SHOULD structure the body as P203L17 an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS P203L18 service is EnvelopedData, the UAS SHOULD send the EnvelopedData P203L19 message encapsulated within a SignedData message. P203L20 P203L21 When a UAC receives a response containing an S/MIME CMS body that P203L22 includes a certificate, the UAC SHOULD first validate the P203L23 certificate, if possible, with any appropriate root certificate. The P203L24 UAC SHOULD also determine the subject of the certificate and compare P203L25 this value to the To field of the response; although the two may very P203L26 well be different, and this is not necessarily indicative of a P203L27 security breach. If the certificate cannot be verified because it is P203L28 self-signed, or signed by no known authority, the UAC MUST notify its P203L29 user of the status of the certificate (including the subject of the P203L30 certificate, its signator, and any key fingerprint information) and P203L31 request explicit permission before proceeding. If the certificate P203L32 was successfully verified, and the subject of the certificate P203L33 corresponds to the To header field in the response, or if the user P203L34 (after notification) explicitly authorizes the use of the P203L35 certificate, the UAC SHOULD add this certificate to a local keyring, P203L36 indexed by the address-of-record of the holder of the certificate. P203L37 If the UAC had not transmitted its own certificate to the UAS in any P203L38 previous transaction, it SHOULD use a CMS SignedData body for its P203L39 next request or response. P203L40 P203L41 On future occasions, when the UA receives requests or responses that P203L42 contain a From header field corresponding to a value in its keyring, P203L43 the UA SHOULD compare the certificate offered in these messages with P203L44 the existing certificate in its keyring. If there is a discrepancy, P203L45 the UA MUST notify its user of a change of the certificate P203L46 (preferably in terms that indicate that this is a potential security P203L47 breach) and acquire the user's permission before continuing to P203L48 P204L1 process the signaling. If the user authorizes this certificate, it P204L2 SHOULD be added to the keyring alongside any previous value(s) for P204L3 this address-of-record. P204L4 P204L5 Note well however, that this key exchange mechanism does not P204L6 guarantee the secure exchange of keys when self-signed certificates, P204L7 or certificates signed by an obscure authority, are used - it is P204L8 vulnerable to well-known attacks. In the opinion of the authors, P204L9 however, the security it provides is proverbially better than P204L10 nothing; it is in fact comparable to the widely used SSH application. P204L11 These limitations are explored in greater detail in Section 26.4.2. P204L12 P204L13 If a UA receives an S/MIME body that has been encrypted with a public P204L14 key unknown to the recipient, it MUST reject the request with a 493 P204L15 (Undecipherable) response. This response SHOULD contain a valid P204L16 certificate for the respondent (corresponding, if possible, to any P204L17 address of record given in the To header field of the rejected P204L18 request) within a MIME body with a 'certs-only' "smime-type" P204L19 parameter. P204L20 P204L21 A 493 (Undecipherable) sent without any certificate indicates that P204L22 the respondent cannot or will not utilize S/MIME encrypted messages, P204L23 though they may still support S/MIME signatures. P204L24 P204L25 Note that a user agent that receives a request containing an S/MIME P204L26 body that is not optional (with a Content-Disposition header P204L27 "handling" parameter of "required") MUST reject the request with a P204L28 415 Unsupported Media Type response if the MIME type is not P204L29 understood. A user agent that receives such a response when S/MIME P204L30 is sent SHOULD notify its user that the remote device does not P204L31 support S/MIME, and it MAY subsequently resend the request without P204L32 S/MIME, if appropriate; however, this 415 response may constitute a P204L33 downgrade attack. P204L34 P204L35 If a user agent sends an S/MIME body in a request, but receives a P204L36 response that contains a MIME body that is not secured, the UAC P204L37 SHOULD notify its user that the session could not be secured. P204L38 However, if a user agent that supports S/MIME receives a request with P204L39 an unsecured body, it SHOULD NOT respond with a secured body, but if P204L40 it expects S/MIME from the sender (for example, because the sender's P204L41 From header field value corresponds to an identity on its keychain), P204L42 the UAS SHOULD notify its user that the session could not be secured. P204L43 P204L44 A number of conditions that arise in the previous text call for the P204L45 notification of the user when an anomalous certificate-management P204L46 event occurs. Users might well ask what they should do under these P204L47 circumstances. First and foremost, an unexpected change in a P204L48 certificate, or an absence of security when security is expected, are P205L1 causes for caution but not necessarily indications that an attack is P205L2 in progress. Users might abort any connection attempt or refuse a P205L3 connection request they have received; in telephony parlance, they P205L4 could hang up and call back. Users may wish to find an alternate P205L5 means to contact the other party and confirm that their key has P205L6 legitimately changed. Note that users are sometimes compelled to P205L7 change their certificates, for example when they suspect that the P205L8 secrecy of their private key has been compromised. When their P205L9 private key is no longer private, users must legitimately generate a P205L10 new key and re-establish trust with any users that held their old P205L11 key. P205L12 P205L13 Finally, if during the course of a dialog a UA receives a certificate P205L14 in a CMS SignedData message that does not correspond with the P205L15 certificates previously exchanged during a dialog, the UA MUST notify P205L16 its user of the change, preferably in terms that indicate that this P205L17 is a potential security breach. P205L18 P205L19 23.3 Securing MIME bodies P205L20 P205L21 There are two types of secure MIME bodies that are of interest to P205L22 SIP: use of these bodies should follow the S/MIME specification [24] P205L23 with a few variations. P205L24 P205L25 o "multipart/signed" MUST be used only with CMS detached P205L26 signatures. P205L27 P205L28 This allows backwards compatibility with non-S/MIME- P205L29 compliant recipients. P205L30 P205L31 o S/MIME bodies SHOULD have a Content-Disposition header field, P205L32 and the value of the "handling" parameter SHOULD be "required." P205L33 P205L34 o If a UAC has no certificate on its keyring associated with the P205L35 address-of-record to which it wants to send a request, it P205L36 cannot send an encrypted "application/pkcs7-mime" MIME message. P205L37 UACs MAY send an initial request such as an OPTIONS message P205L38 with a CMS detached signature in order to solicit the P205L39 certificate of the remote side (the signature SHOULD be over a P205L40 "message/sip" body of the type described in Section 23.4). P205L41 P205L42 Note that future standardization work on S/MIME may define P205L43 non-certificate based keys. P205L44 P205L45 o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" P205L46 (see Section 2.5.2 of [24]) attribute to express their P205L47 capabilities and preferences for further communications. Note P205L48 especially that senders MAY use the "preferSignedData" P206L1 capability to encourage receivers to respond with CMS P206L2 SignedData messages (for example, when sending an OPTIONS P206L3 request as described above). P206L4 P206L5 o S/MIME implementations MUST at a minimum support SHA1 as a P206L6 digital signature algorithm, and 3DES as an encryption P206L7 algorithm. All other signature and encryption algorithms MAY P206L8 be supported. Implementations can negotiate support for these P206L9 algorithms with the "SMIMECapabilities" attribute. P206L10 P206L11 o Each S/MIME body in a SIP message SHOULD be signed with only P206L12 one certificate. If a UA receives a message with multiple P206L13 signatures, the outermost signature should be treated as the P206L14 single certificate for this body. Parallel signatures SHOULD P206L15 NOT be used. P206L16 P206L17 The following is an example of an encrypted S/MIME SDP body P206L18 within a SIP message: P206L19 P206L20 INVITE sip:bob@biloxi.com SIP/2.0 P206L21 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P206L22 To: Bob P206L23 From: Alice ;tag=1928301774 P206L24 Call-ID: a84b4c76e66710 P206L25 CSeq: 314159 INVITE P206L26 Max-Forwards: 70 P206L27 Contact: P206L28 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; P206L29 name=smime.p7m P206L30 Content-Disposition: attachment; filename=smime.p7m P206L31 handling=required P206L32 P206L33 ******************************************************* P206L34 * Content-Type: application/sdp * P206L35 * * P206L36 * v=0 * P206L37 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * P206L38 * s=- * P206L39 * t=0 0 * P206L40 * c=IN IP4 pc33.atlanta.com * P206L41 * m=audio 3456 RTP/AVP 0 1 3 99 * P206L42 * a=rtpmap:0 PCMU/8000 * P206L43 ******************************************************* P206L44 P206L45 P206L46 P206L47 P206L48 P207L1 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP P207L2 P207L3 As a means of providing some degree of end-to-end authentication, P207L4 integrity or confidentiality for SIP header fields, S/MIME can P207L5 encapsulate entire SIP messages within MIME bodies of type P207L6 "message/sip" and then apply MIME security to these bodies in the P207L7 same manner as typical SIP bodies. These encapsulated SIP requests P207L8 and responses do not constitute a separate dialog or transaction, P207L9 they are a copy of the "outer" message that is used to verify P207L10 integrity or to supply additional information. P207L11 P207L12 If a UAS receives a request that contains a tunneled "message/sip" P207L13 S/MIME body, it SHOULD include a tunneled "message/sip" body in the P207L14 response with the same smime-type. P207L15 P207L16 Any traditional MIME bodies (such as SDP) SHOULD be attached to the P207L17 "inner" message so that they can also benefit from S/MIME security. P207L18 Note that "message/sip" bodies can be sent as a part of a MIME P207L19 "multipart/mixed" body if any unsecured MIME types should also be P207L20 transmitted in a request. P207L21 P207L22 23.4.1 Integrity and Confidentiality Properties of SIP Headers P207L23 P207L24 When the S/MIME integrity or confidentiality mechanisms are used, P207L25 there may be discrepancies between the values in the "inner" message P207L26 and values in the "outer" message. The rules for handling any such P207L27 differences for all of the header fields described in this document P207L28 are given in this section. P207L29 P207L30 Note that for the purposes of loose timestamping, all SIP messages P207L31 that tunnel "message/sip" SHOULD contain a Date header in both the P207L32 "inner" and "outer" headers. P207L33 P207L34 23.4.1.1 Integrity P207L35 P207L36 Whenever integrity checks are performed, the integrity of a header P207L37 field should be determined by matching the value of the header field P207L38 in the signed body with that in the "outer" messages using the P207L39 comparison rules of SIP as described in 20. P207L40 P207L41 Header fields that can be legitimately modified by proxy servers are: P207L42 Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- P207L43 Authorization. If these header fields are not intact end-to-end, P207L44 implementations SHOULD NOT consider this a breach of security. P207L45 Changes to any other header fields defined in this document P207L46 constitute an integrity violation; users MUST be notified of a P207L47 discrepancy. P207L48 P208L1 23.4.1.2 Confidentiality P208L2 P208L3 When messages are encrypted, header fields may be included in the P208L4 encrypted body that are not present in the "outer" message. P208L5 P208L6 Some header fields must always have a plaintext version because they P208L7 are required header fields in requests and responses - these include: P208L8 P208L9 To, From, Call-ID, CSeq, Contact. While it is probably not useful to P208L10 provide an encrypted alternative for the Call-ID, CSeq, or Contact, P208L11 providing an alternative to the information in the "outer" To or From P208L12 is permitted. Note that the values in an encrypted body are not used P208L13 for the purposes of identifying transactions or dialogs - they are P208L14 merely informational. If the From header field in an encrypted body P208L15 differs from the value in the "outer" message, the value within the P208L16 encrypted body SHOULD be displayed to the user, but MUST NOT be used P208L17 in the "outer" header fields of any future messages. P208L18 P208L19 Primarily, a user agent will want to encrypt header fields that have P208L20 an end-to-end semantic, including: Subject, Reply-To, Organization, P208L21 Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, P208L22 Authentication-Info, Expires, In-Reply-To, Require, Supported, P208L23 Unsupported, Retry-After, User-Agent, Server, and Warning. If any of P208L24 these header fields are present in an encrypted body, they should be P208L25 used instead of any "outer" header fields, whether this entails P208L26 displaying the header field values to users or setting internal P208L27 states in the UA. They SHOULD NOT however be used in the "outer" P208L28 headers of any future messages. P208L29 P208L30 If present, the Date header field MUST always be the same in the P208L31 "inner" and "outer" headers. P208L32 P208L33 Since MIME bodies are attached to the "inner" message, P208L34 implementations will usually encrypt MIME-specific header fields, P208L35 including: MIME-Version, Content-Type, Content-Length, Content- P208L36 Language, Content-Encoding and Content-Disposition. The "outer" P208L37 message will have the proper MIME header fields for S/MIME bodies. P208L38 These header fields (and any MIME bodies they preface) should be P208L39 treated as normal MIME header fields and bodies received in a SIP P208L40 message. P208L41 P208L42 It is not particularly useful to encrypt the following header fields: P208L43 Min-Expires, Timestamp, Authorization, Priority, and WWW- P208L44 Authenticate. This category also includes those header fields that P208L45 can be changed by proxy servers (described in the preceding section). P208L46 UAs SHOULD never include these in an "inner" message if they are not P208L47 P208L48 P209L1 included in the "outer" message. UAs that receive any of these P209L2 header fields in an encrypted body SHOULD ignore the encrypted P209L3 values. P209L4 P209L5 Note that extensions to SIP may define additional header fields; the P209L6 authors of these extensions should describe the integrity and P209L7 confidentiality properties of such header fields. If a SIP UA P209L8 encounters an unknown header field with an integrity violation, it P209L9 MUST ignore the header field. P209L10 P209L11 23.4.2 Tunneling Integrity and Authentication P209L12 P209L13 Tunneling SIP messages within S/MIME bodies can provide integrity for P209L14 SIP header fields if the header fields that the sender wishes to P209L15 secure are replicated in a "message/sip" MIME body signed with a CMS P209L16 detached signature. P209L17 P209L18 Provided that the "message/sip" body contains at least the P209L19 fundamental dialog identifiers (To, From, Call-ID, CSeq), then a P209L20 signed MIME body can provide limited authentication. At the very P209L21 least, if the certificate used to sign the body is unknown to the P209L22 recipient and cannot be verified, the signature can be used to P209L23 ascertain that a later request in a dialog was transmitted by the P209L24 same certificate-holder that initiated the dialog. If the recipient P209L25 of the signed MIME body has some stronger incentive to trust the P209L26 certificate (they were able to validate it, they acquired it from a P209L27 trusted repository, or they have used it frequently) then the P209L28 signature can be taken as a stronger assertion of the identity of the P209L29 subject of the certificate. P209L30 P209L31 In order to eliminate possible confusions about the addition or P209L32 subtraction of entire header fields, senders SHOULD replicate all P209L33 header fields from the request within the signed body. Any message P209L34 bodies that require integrity protection MUST be attached to the P209L35 "inner" message. P209L36 P209L37 If a Date header is present in a message with a signed body, the P209L38 recipient SHOULD compare the header field value with its own internal P209L39 clock, if applicable. If a significant time discrepancy is detected P209L40 (on the order of an hour or more), the user agent SHOULD alert the P209L41 user to the anomaly, and note that it is a potential security breach. P209L42 P209L43 If an integrity violation in a message is detected by its recipient, P209L44 the message MAY be rejected with a 403 (Forbidden) response if it is P209L45 a request, or any existing dialog MAY be terminated. UAs SHOULD P209L46 notify users of this circumstance and request explicit guidance on P209L47 how to proceed. P209L48 P210L1 The following is an example of the use of a tunneled "message/sip" P210L2 body: P210L3 P210L4 INVITE sip:bob@biloxi.com SIP/2.0 P210L5 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P210L6 To: Bob P210L7 From: Alice ;tag=1928301774 P210L8 Call-ID: a84b4c76e66710 P210L9 CSeq: 314159 INVITE P210L10 Max-Forwards: 70 P210L11 Date: Thu, 21 Feb 2002 13:02:03 GMT P210L12 Contact: P210L13 Content-Type: multipart/signed; P210L14 protocol="application/pkcs7-signature"; P210L15 micalg=sha1; boundary=boundary42 P210L16 Content-Length: 568 P210L17 P210L18 --boundary42 P210L19 Content-Type: message/sip P210L20 P210L21 INVITE sip:bob@biloxi.com SIP/2.0 P210L22 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P210L23 To: Bob P210L24 From: Alice ;tag=1928301774 P210L25 Call-ID: a84b4c76e66710 P210L26 CSeq: 314159 INVITE P210L27 Max-Forwards: 70 P210L28 Date: Thu, 21 Feb 2002 13:02:03 GMT P210L29 Contact: P210L30 Content-Type: application/sdp P210L31 Content-Length: 147 P210L32 P210L33 v=0 P210L34 o=UserA 2890844526 2890844526 IN IP4 here.com P210L35 s=Session SDP P210L36 c=IN IP4 pc33.atlanta.com P210L37 t=0 0 P210L38 m=audio 49172 RTP/AVP 0 P210L39 a=rtpmap:0 PCMU/8000 P210L40 P210L41 --boundary42 P210L42 Content-Type: application/pkcs7-signature; name=smime.p7s P210L43 Content-Transfer-Encoding: base64 P210L44 Content-Disposition: attachment; filename=smime.p7s; P210L45 handling=required P210L46 P210L47 P210L48 P211L1 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 P211L2 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj P211L3 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 P211L4 7GhIGfHfYT64VQbnj756 P211L5 P211L6 --boundary42- P211L7 P211L8 23.4.3 Tunneling Encryption P211L9 P211L10 It may also be desirable to use this mechanism to encrypt a P211L11 "message/sip" MIME body within a CMS EnvelopedData message S/MIME P211L12 body, but in practice, most header fields are of at least some use to P211L13 the network; the general use of encryption with S/MIME is to secure P211L14 message bodies like SDP rather than message headers. Some P211L15 informational header fields, such as the Subject or Organization P211L16 could perhaps warrant end-to-end security. Headers defined by future P211L17 SIP applications might also require obfuscation. P211L18 P211L19 Another possible application of encrypting header fields is selective P211L20 anonymity. A request could be constructed with a From header field P211L21 that contains no personal information (for example, P211L22 sip:anonymous@anonymizer.invalid). However, a second From header P211L23 field containing the genuine address-of-record of the originator P211L24 could be encrypted within a "message/sip" MIME body where it will P211L25 only be visible to the endpoints of a dialog. P211L26 P211L27 Note that if this mechanism is used for anonymity, the From header P211L28 field will no longer be usable by the recipient of a message as an P211L29 index to their certificate keychain for retrieving the proper P211L30 S/MIME key to associated with the sender. The message must first P211L31 be decrypted, and the "inner" From header field MUST be used as an P211L32 index. P211L33 P211L34 In order to provide end-to-end integrity, encrypted "message/sip" P211L35 MIME bodies SHOULD be signed by the sender. This creates a P211L36 "multipart/signed" MIME body that contains an encrypted body and a P211L37 signature, both of type "application/pkcs7-mime". P211L38 P211L39 P211L40 P211L41 P211L42 P211L43 P211L44 P211L45 P211L46 P211L47 P211L48 P212L1 In the following example, of an encrypted and signed message, the P212L2 text boxed in asterisks ("*") is encrypted: P212L3 P212L4 INVITE sip:bob@biloxi.com SIP/2.0 P212L5 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P212L6 To: Bob P212L7 From: Anonymous ;tag=1928301774 P212L8 Call-ID: a84b4c76e66710 P212L9 CSeq: 314159 INVITE P212L10 Max-Forwards: 70 P212L11 Date: Thu, 21 Feb 2002 13:02:03 GMT P212L12 Contact: P212L13 Content-Type: multipart/signed; P212L14 protocol="application/pkcs7-signature"; P212L15 micalg=sha1; boundary=boundary42 P212L16 Content-Length: 568 P212L17 P212L18 --boundary42 P212L19 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; P212L20 name=smime.p7m P212L21 Content-Transfer-Encoding: base64 P212L22 Content-Disposition: attachment; filename=smime.p7m P212L23 handling=required P212L24 Content-Length: 231 P212L25 P212L26 *********************************************************** P212L27 * Content-Type: message/sip * P212L28 * * P212L29 * INVITE sip:bob@biloxi.com SIP/2.0 * P212L30 * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * P212L31 * To: Bob * P212L32 * From: Alice ;tag=1928301774 * P212L33 * Call-ID: a84b4c76e66710 * P212L34 * CSeq: 314159 INVITE * P212L35 * Max-Forwards: 70 * P212L36 * Date: Thu, 21 Feb 2002 13:02:03 GMT * P212L37 * Contact: * P212L38 * * P212L39 * Content-Type: application/sdp * P212L40 * * P212L41 * v=0 * P212L42 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * P212L43 * s=Session SDP * P212L44 * t=0 0 * P212L45 * c=IN IP4 pc33.atlanta.com * P212L46 * m=audio 3456 RTP/AVP 0 1 3 99 * P212L47 * a=rtpmap:0 PCMU/8000 * P212L48 *********************************************************** P213L1 --boundary42 P213L2 Content-Type: application/pkcs7-signature; name=smime.p7s P213L3 Content-Transfer-Encoding: base64 P213L4 Content-Disposition: attachment; filename=smime.p7s; P213L5 handling=required P213L6 P213L7 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 P213L8 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj P213L9 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 P213L10 7GhIGfHfYT64VQbnj756 P213L11 P213L12 --boundary42- P213L13 P213L14 24 Examples P213L15 P213L16 In the following examples, we often omit the message body and the P213L17 corresponding Content-Length and Content-Type header fields for P213L18 brevity. P213L19 P213L20 24.1 Registration P213L21 P213L22 Bob registers on start-up. The message flow is shown in Figure 9. P213L23 Note that the authentication usually required for registration is not P213L24 shown for simplicity. P213L25 P213L26 biloxi.com Bob's P213L27 registrar softphone P213L28 | | P213L29 | REGISTER F1 | P213L30 |<---------------| P213L31 | 200 OK F2 | P213L32 |--------------->| P213L33 P213L34 Figure 9: SIP Registration Example P213L35 P213L36 F1 REGISTER Bob -> Registrar P213L37 P213L38 REGISTER sip:registrar.biloxi.com SIP/2.0 P213L39 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 P213L40 Max-Forwards: 70 P213L41 To: Bob P213L42 From: Bob ;tag=456248 P213L43 Call-ID: 843817637684230@998sdasdh09 P213L44 CSeq: 1826 REGISTER P213L45 Contact: P213L46 Expires: 7200 P213L47 Content-Length: 0 P213L48 P214L1 The registration expires after two hours. The registrar responds P214L2 with a 200 OK: P214L3 P214L4 F2 200 OK Registrar -> Bob P214L5 P214L6 SIP/2.0 200 OK P214L7 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 P214L8 ;received=192.0.2.4 P214L9 To: Bob ;tag=2493k59kd P214L10 From: Bob ;tag=456248 P214L11 Call-ID: 843817637684230@998sdasdh09 P214L12 CSeq: 1826 REGISTER P214L13 Contact: P214L14 Expires: 7200 P214L15 Content-Length: 0 P214L16 P214L17 24.2 Session Setup P214L18 P214L19 This example contains the full details of the example session setup P214L20 in Section 4. The message flow is shown in Figure 1. Note that P214L21 these flows show the minimum required set of header fields - some P214L22 other header fields such as Allow and Supported would normally be P214L23 present. P214L24 P214L25 F1 INVITE Alice -> atlanta.com proxy P214L26 P214L27 INVITE sip:bob@biloxi.com SIP/2.0 P214L28 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P214L29 Max-Forwards: 70 P214L30 To: Bob P214L31 From: Alice ;tag=1928301774 P214L32 Call-ID: a84b4c76e66710 P214L33 CSeq: 314159 INVITE P214L34 Contact: P214L35 Content-Type: application/sdp P214L36 Content-Length: 142 P214L37 P214L38 (Alice's SDP not shown) P214L39 P214L40 P214L41 P214L42 P214L43 P214L44 P214L45 P214L46 P214L47 P214L48 P215L1 F2 100 Trying atlanta.com proxy -> Alice P215L2 P215L3 SIP/2.0 100 Trying P215L4 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P215L5 ;received=192.0.2.1 P215L6 To: Bob P215L7 From: Alice ;tag=1928301774 P215L8 Call-ID: a84b4c76e66710 P215L9 CSeq: 314159 INVITE P215L10 Content-Length: 0 P215L11 P215L12 F3 INVITE atlanta.com proxy -> biloxi.com proxy P215L13 P215L14 INVITE sip:bob@biloxi.com SIP/2.0 P215L15 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P215L16 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P215L17 ;received=192.0.2.1 P215L18 Max-Forwards: 69 P215L19 To: Bob P215L20 From: Alice ;tag=1928301774 P215L21 Call-ID: a84b4c76e66710 P215L22 CSeq: 314159 INVITE P215L23 Contact: P215L24 Content-Type: application/sdp P215L25 Content-Length: 142 P215L26 P215L27 (Alice's SDP not shown) P215L28 P215L29 F4 100 Trying biloxi.com proxy -> atlanta.com proxy P215L30 P215L31 SIP/2.0 100 Trying P215L32 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P215L33 ;received=192.0.2.2 P215L34 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P215L35 ;received=192.0.2.1 P215L36 To: Bob P215L37 From: Alice ;tag=1928301774 P215L38 Call-ID: a84b4c76e66710 P215L39 CSeq: 314159 INVITE P215L40 Content-Length: 0 P215L41 P215L42 P215L43 P215L44 P215L45 P215L46 P215L47 P215L48 P216L1 F5 INVITE biloxi.com proxy -> Bob P216L2 P216L3 INVITE sip:bob@192.0.2.4 SIP/2.0 P216L4 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 P216L5 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P216L6 ;received=192.0.2.2 P216L7 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P216L8 ;received=192.0.2.1 P216L9 Max-Forwards: 68 P216L10 To: Bob P216L11 From: Alice ;tag=1928301774 P216L12 Call-ID: a84b4c76e66710 P216L13 CSeq: 314159 INVITE P216L14 Contact: P216L15 Content-Type: application/sdp P216L16 Content-Length: 142 P216L17 P216L18 (Alice's SDP not shown) P216L19 P216L20 F6 180 Ringing Bob -> biloxi.com proxy P216L21 P216L22 SIP/2.0 180 Ringing P216L23 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 P216L24 ;received=192.0.2.3 P216L25 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P216L26 ;received=192.0.2.2 P216L27 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P216L28 ;received=192.0.2.1 P216L29 To: Bob ;tag=a6c85cf P216L30 From: Alice ;tag=1928301774 P216L31 Call-ID: a84b4c76e66710 P216L32 Contact: P216L33 CSeq: 314159 INVITE P216L34 Content-Length: 0 P216L35 P216L36 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy P216L37 P216L38 SIP/2.0 180 Ringing P216L39 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P216L40 ;received=192.0.2.2 P216L41 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P216L42 ;received=192.0.2.1 P216L43 To: Bob ;tag=a6c85cf P216L44 From: Alice ;tag=1928301774 P216L45 Call-ID: a84b4c76e66710 P216L46 Contact: P216L47 CSeq: 314159 INVITE P216L48 Content-Length: 0 P217L1 F8 180 Ringing atlanta.com proxy -> Alice P217L2 P217L3 SIP/2.0 180 Ringing P217L4 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P217L5 ;received=192.0.2.1 P217L6 To: Bob ;tag=a6c85cf P217L7 From: Alice ;tag=1928301774 P217L8 Call-ID: a84b4c76e66710 P217L9 Contact: P217L10 CSeq: 314159 INVITE P217L11 Content-Length: 0 P217L12 P217L13 F9 200 OK Bob -> biloxi.com proxy P217L14 P217L15 SIP/2.0 200 OK P217L16 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 P217L17 ;received=192.0.2.3 P217L18 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P217L19 ;received=192.0.2.2 P217L20 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P217L21 ;received=192.0.2.1 P217L22 To: Bob ;tag=a6c85cf P217L23 From: Alice ;tag=1928301774 P217L24 Call-ID: a84b4c76e66710 P217L25 CSeq: 314159 INVITE P217L26 Contact: P217L27 Content-Type: application/sdp P217L28 Content-Length: 131 P217L29 P217L30 (Bob's SDP not shown) P217L31 P217L32 F10 200 OK biloxi.com proxy -> atlanta.com proxy P217L33 P217L34 SIP/2.0 200 OK P217L35 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 P217L36 ;received=192.0.2.2 P217L37 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P217L38 ;received=192.0.2.1 P217L39 To: Bob ;tag=a6c85cf P217L40 From: Alice ;tag=1928301774 P217L41 Call-ID: a84b4c76e66710 P217L42 CSeq: 314159 INVITE P217L43 Contact: P217L44 Content-Type: application/sdp P217L45 Content-Length: 131 P217L46 P217L47 (Bob's SDP not shown) P217L48 P218L1 F11 200 OK atlanta.com proxy -> Alice P218L2 P218L3 SIP/2.0 200 OK P218L4 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 P218L5 ;received=192.0.2.1 P218L6 To: Bob ;tag=a6c85cf P218L7 From: Alice ;tag=1928301774 P218L8 Call-ID: a84b4c76e66710 P218L9 CSeq: 314159 INVITE P218L10 Contact: P218L11 Content-Type: application/sdp P218L12 Content-Length: 131 P218L13 P218L14 (Bob's SDP not shown) P218L15 P218L16 F12 ACK Alice -> Bob P218L17 P218L18 ACK sip:bob@192.0.2.4 SIP/2.0 P218L19 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 P218L20 Max-Forwards: 70 P218L21 To: Bob ;tag=a6c85cf P218L22 From: Alice ;tag=1928301774 P218L23 Call-ID: a84b4c76e66710 P218L24 CSeq: 314159 ACK P218L25 Content-Length: 0 P218L26 P218L27 The media session between Alice and Bob is now established. P218L28 P218L29 Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq P218L30 numbering space, which, in this example, begins with 231. Since Bob P218L31 is making the request, the To and From URIs and tags have been P218L32 swapped. P218L33 P218L34 F13 BYE Bob -> Alice P218L35 P218L36 BYE sip:alice@pc33.atlanta.com SIP/2.0 P218L37 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 P218L38 Max-Forwards: 70 P218L39 From: Bob ;tag=a6c85cf P218L40 To: Alice ;tag=1928301774 P218L41 Call-ID: a84b4c76e66710 P218L42 CSeq: 231 BYE P218L43 Content-Length: 0 P218L44 P218L45 P218L46 P218L47 P218L48 P219L1 F14 200 OK Alice -> Bob P219L2 P219L3 SIP/2.0 200 OK P219L4 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 P219L5 From: Bob ;tag=a6c85cf P219L6 To: Alice ;tag=1928301774 P219L7 Call-ID: a84b4c76e66710 P219L8 CSeq: 231 BYE P219L9 Content-Length: 0 P219L10 P219L11 The SIP Call Flows document [40] contains further examples of SIP P219L12 messages. P219L13 P219L14 25 Augmented BNF for the SIP Protocol P219L15 P219L16 All of the mechanisms specified in this document are described in P219L17 both prose and an augmented Backus-Naur Form (BNF) defined in RFC P219L18 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that P219L19 are used by this specification, and not repeated here. Implementers P219L20 need to be familiar with the notation and content of RFC 2234 in P219L21 order to understand this specification. Certain basic rules are in P219L22 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle P219L23 brackets are used within definitions to clarify the use of rule P219L24 names. P219L25 P219L26 The use of square brackets is redundant syntactically. It is used as P219L27 a semantic hint that the specific parameter is optional to use. P219L28 P219L29 25.1 Basic Rules P219L30 P219L31 The following rules are used throughout this specification to P219L32 describe basic parsing constructs. The US-ASCII coded character set P219L33 is defined by ANSI X3.4-1986. P219L34 P219L35 alphanum = ALPHA / DIGIT P219L36 P219L37 P219L38 P219L39 P219L40 P219L41 P219L42 P219L43 P219L44 P219L45 P219L46 P219L47 P219L48 P220L1 Several rules are incorporated from RFC 2396 [5] but are updated to P220L2 make them compliant with RFC 2234 [10]. These include: P220L3 P220L4 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" P220L5 / "$" / "," P220L6 unreserved = alphanum / mark P220L7 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" P220L8 / "(" / ")" P220L9 escaped = "%" HEXDIG HEXDIG P220L10 P220L11 SIP header field values can be folded onto multiple lines if the P220L12 continuation line begins with a space or horizontal tab. All linear P220L13 white space, including folding, has the same semantics as SP. A P220L14 recipient MAY replace any linear white space with a single SP before P220L15 interpreting the field value or forwarding the message downstream. P220L16 This is intended to behave exactly as HTTP/1.1 as described in RFC P220L17 2616 [8]. The SWS construct is used when linear white space is P220L18 optional, generally between tokens and separators. P220L19 P220L20 LWS = [*WSP CRLF] 1*WSP ; linear whitespace P220L21 SWS = [LWS] ; sep whitespace P220L22 P220L23 To separate the header name from the rest of value, a colon is used, P220L24 which, by the above rule, allows whitespace before, but no line P220L25 break, and whitespace after, including a linebreak. The HCOLON P220L26 defines this construct. P220L27 P220L28 HCOLON = *( SP / HTAB ) ":" SWS P220L29 P220L30 The TEXT-UTF8 rule is only used for descriptive field contents and P220L31 values that are not intended to be interpreted by the message parser. P220L32 Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC P220L33 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field P220L34 contents that are n t quoted strings, where leading and trailing LWS P220L35 is not meaningful. In this regard, SIP differs from HTTP, which uses P220L36 the ISO 8859-1 character set. P220L37 P220L38 TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) P220L39 TEXT-UTF8char = %x21-7E / UTF8-NONASCII P220L40 UTF8-NONASCII = %xC0-DF 1UTF8-CONT P220L41 / %xE0-EF 2UTF8-CONT P220L42 / %xF0-F7 3UTF8-CONT P220L43 / %xF8-Fb 4UTF8-CONT P220L44 / %xFC-FD 5UTF8-CONT P220L45 UTF8-CONT = %x80-BF P220L46 P220L47 P220L48 P221L1 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of P221L2 a header field continuation. It is expected that the folding LWS P221L3 will be replaced with a single SP before interpretation of the TEXT- P221L4 UTF8-TRIM value. P221L5 P221L6 Hexadecimal numeric characters are used in several protocol elements. P221L7 Some elements (authentication) force hex alphas to be lower case. P221L8 P221L9 LHEX = DIGIT / %x61-66 ;lowercase a-f P221L10 P221L11 Many SIP header field values consist of words separated by LWS or P221L12 special characters. Unless otherwise stated, tokens are case- P221L13 insensitive. These special characters MUST be in a quoted string to P221L14 be used within a parameter value. The word construct is used in P221L15 Call-ID to allow most separators to be used. P221L16 P221L17 token = 1*(alphanum / "-" / "." / "!" / "%" / "*" P221L18 / "_" / "+" / "`" / "'" / "~" ) P221L19 separators = "(" / ")" / "<" / ">" / "@" / P221L20 "," / ";" / ":" / "\" / DQUOTE / P221L21 "/" / "[" / "]" / "?" / "=" / P221L22 "{" / "}" / SP / HTAB P221L23 word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / P221L24 "_" / "+" / "`" / "'" / "~" / P221L25 "(" / ")" / "<" / ">" / P221L26 ":" / "\" / DQUOTE / P221L27 "/" / "[" / "]" / "?" / P221L28 "{" / "}" ) P221L29 P221L30 When tokens are used or separators are used between elements, P221L31 whitespace is often allowed before or after these characters: P221L32 P221L33 STAR = SWS "*" SWS ; asterisk P221L34 SLASH = SWS "/" SWS ; slash P221L35 EQUAL = SWS "=" SWS ; equal P221L36 LPAREN = SWS "(" SWS ; left parenthesis P221L37 RPAREN = SWS ")" SWS ; right parenthesis P221L38 RAQUOT = ">" SWS ; right angle quote P221L39 LAQUOT = SWS "<"; left angle quote P221L40 COMMA = SWS "," SWS ; comma P221L41 SEMI = SWS ";" SWS ; semicolon P221L42 COLON = SWS ":" SWS ; colon P221L43 LDQUOT = SWS DQUOTE; open double quotation mark P221L44 RDQUOT = DQUOTE SWS ; close double quotation mark P221L45 P221L46 P221L47 P221L48 P222L1 Comments can be included in some SIP header fields by surrounding the P222L2 comment text with parentheses. Comments are only allowed in fields P222L3 containing "comment" as part of their field value definition. In all P222L4 other fields, parentheses are considered part of the field value. P222L5 P222L6 comment = LPAREN *(ctext / quoted-pair / comment) RPAREN P222L7 ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII P222L8 / LWS P222L9 P222L10 ctext includes all chars except left and right parens and backslash. P222L11 A string of text is parsed as a single word if it is quoted using P222L12 double-quote marks. In quoted strings, quotation marks (") and P222L13 backslashes (\) need to be escaped. P222L14 P222L15 quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE P222L16 qdtext = LWS / %x21 / %x23-5B / %x5D-7E P222L17 / UTF8-NONASCII P222L18 P222L19 The backslash character ("\") MAY be used as a single-character P222L20 quoting mechanism only within quoted-string and comment constructs. P222L21 Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this P222L22 mechanism to avoid conflict with line folding and header separation. P222L23 P222L24 quoted-pair = "\" (%x00-09 / %x0B-0C P222L25 / %x0E-7F) P222L26 P222L27 SIP-URI = "sip:" [ userinfo ] hostport P222L28 uri-parameters [ headers ] P222L29 SIPS-URI = "sips:" [ userinfo ] hostport P222L30 uri-parameters [ headers ] P222L31 userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" P222L32 user = 1*( unreserved / escaped / user-unreserved ) P222L33 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" P222L34 password = *( unreserved / escaped / P222L35 "&" / "=" / "+" / "$" / "," ) P222L36 hostport = host [ ":" port ] P222L37 host = hostname / IPv4address / IPv6reference P222L38 hostname = *( domainlabel "." ) toplabel [ "." ] P222L39 domainlabel = alphanum P222L40 / alphanum *( alphanum / "-" ) alphanum P222L41 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum P222L42 P222L43 P222L44 P222L45 P222L46 P222L47 P222L48 P223L1 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT P223L2 IPv6reference = "[" IPv6address "]" P223L3 IPv6address = hexpart [ ":" IPv4address ] P223L4 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] P223L5 hexseq = hex4 *( ":" hex4) P223L6 hex4 = 1*4HEXDIG P223L7 port = 1*DIGIT P223L8 P223L9 The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, P223L10 however, that any characters allowed there that are not allowed in P223L11 the user part of the SIP URI MUST be escaped. P223L12 P223L13 uri-parameters = *( ";" uri-parameter) P223L14 uri-parameter = transport-param / user-param / method-param P223L15 / ttl-param / maddr-param / lr-param / other-param P223L16 transport-param = "transport=" P223L17 ( "udp" / "tcp" / "sctp" / "tls" P223L18 / other-transport) P223L19 other-transport = token P223L20 user-param = "user=" ( "phone" / "ip" / other-user) P223L21 other-user = token P223L22 method-param = "method=" Method P223L23 ttl-param = "ttl=" ttl P223L24 maddr-param = "maddr=" host P223L25 lr-param = "lr" P223L26 other-param = pname [ "=" pvalue ] P223L27 pname = 1*paramchar P223L28 pvalue = 1*paramchar P223L29 paramchar = param-unreserved / unreserved / escaped P223L30 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" P223L31 P223L32 headers = "?" header *( "&" header ) P223L33 header = hname "=" hvalue P223L34 hname = 1*( hnv-unreserved / unreserved / escaped ) P223L35 hvalue = *( hnv-unreserved / unreserved / escaped ) P223L36 hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" P223L37 P223L38 SIP-message = Request / Response P223L39 Request = Request-Line P223L40 *( message-header ) P223L41 CRLF P223L42 [ message-body ] P223L43 Request-Line = Method SP Request-URI SP SIP-Version CRLF P223L44 Request-URI = SIP-URI / SIPS-URI / absoluteURI P223L45 absoluteURI = scheme ":" ( hier-part / opaque-part ) P223L46 hier-part = ( net-path / abs-path ) [ "?" query ] P223L47 net-path = "//" authority [ abs-path ] P223L48 abs-path = "/" path-segments P224L1 opaque-part = uric-no-slash *uric P224L2 uric = reserved / unreserved / escaped P224L3 uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" P224L4 / "&" / "=" / "+" / "$" / "," P224L5 path-segments = segment *( "/" segment ) P224L6 segment = *pchar *( ";" param ) P224L7 param = *pchar P224L8 pchar = unreserved / escaped / P224L9 ":" / "@" / "&" / "=" / "+" / "$" / "," P224L10 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) P224L11 authority = srvr / reg-name P224L12 srvr = [ [ userinfo "@" ] hostport ] P224L13 reg-name = 1*( unreserved / escaped / "$" / "," P224L14 / ";" / ":" / "@" / "&" / "=" / "+" ) P224L15 query = *uric P224L16 SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT P224L17 P224L18 message-header = (Accept P224L19 / Accept-Encoding P224L20 / Accept-Language P224L21 / Alert-Info P224L22 / Allow P224L23 / Authentication-Info P224L24 / Authorization P224L25 / Call-ID P224L26 / Call-Info P224L27 / Contact P224L28 / Content-Disposition P224L29 / Content-Encoding P224L30 / Content-Language P224L31 / Content-Length P224L32 / Content-Type P224L33 / CSeq P224L34 / Date P224L35 / Error-Info P224L36 / Expires P224L37 / From P224L38 / In-Reply-To P224L39 / Max-Forwards P224L40 / MIME-Version P224L41 / Min-Expires P224L42 / Organization P224L43 / Priority P224L44 / Proxy-Authenticate P224L45 / Proxy-Authorization P224L46 / Proxy-Require P224L47 / Record-Route P224L48 / Reply-To P225L1 / Require P225L2 / Retry-After P225L3 / Route P225L4 / Server P225L5 / Subject P225L6 / Supported P225L7 / Timestamp P225L8 / To P225L9 / Unsupported P225L10 / User-Agent P225L11 / Via P225L12 / Warning P225L13 / WWW-Authenticate P225L14 / extension-header) CRLF P225L15 P225L16 INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps P225L17 ACKm = %x41.43.4B ; ACK in caps P225L18 OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps P225L19 BYEm = %x42.59.45 ; BYE in caps P225L20 CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps P225L21 REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps P225L22 Method = INVITEm / ACKm / OPTIONSm / BYEm P225L23 / CANCELm / REGISTERm P225L24 / extension-method P225L25 extension-method = token P225L26 Response = Status-Line P225L27 *( message-header ) P225L28 CRLF P225L29 [ message-body ] P225L30 P225L31 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF P225L32 Status-Code = Informational P225L33 / Redirection P225L34 / Success P225L35 / Client-Error P225L36 / Server-Error P225L37 / Global-Failure P225L38 / extension-code P225L39 extension-code = 3DIGIT P225L40 Reason-Phrase = *(reserved / unreserved / escaped P225L41 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) P225L42 P225L43 Informational = "100" ; Trying P225L44 / "180" ; Ringing P225L45 / "181" ; Call Is Being Forwarded P225L46 / "182" ; Queued P225L47 / "183" ; Session Progress P225L48 P226L1 Success = "200" ; OK P226L2 P226L3 Redirection = "300" ; Multiple Choices P226L4 / "301" ; Moved Permanently P226L5 / "302" ; Moved Temporarily P226L6 / "305" ; Use Proxy P226L7 / "380" ; Alternative Service P226L8 P226L9 Client-Error = "400" ; Bad Request P226L10 / "401" ; Unauthorized P226L11 / "402" ; Payment Required P226L12 / "403" ; Forbidden P226L13 / "404" ; Not Found P226L14 / "405" ; Method Not Allowed P226L15 / "406" ; Not Acceptable P226L16 / "407" ; Proxy Authentication Required P226L17 / "408" ; Request Timeout P226L18 / "410" ; Gone P226L19 / "413" ; Request Entity Too Large P226L20 / "414" ; Request-URI Too Large P226L21 / "415" ; Unsupported Media Type P226L22 / "416" ; Unsupported URI Scheme P226L23 / "420" ; Bad Extension P226L24 / "421" ; Extension Required P226L25 / "423" ; Interval Too Brief P226L26 / "480" ; Temporarily not available P226L27 / "481" ; Call Leg/Transaction Does Not Exist P226L28 / "482" ; Loop Detected P226L29 / "483" ; Too Many Hops P226L30 / "484" ; Address Incomplete P226L31 / "485" ; Ambiguous P226L32 / "486" ; Busy Here P226L33 / "487" ; Request Terminated P226L34 / "488" ; Not Acceptable Here P226L35 / "491" ; Request Pending P226L36 / "493" ; Undecipherable P226L37 P226L38 Server-Error = "500" ; Internal Server Error P226L39 / "501" ; Not Implemented P226L40 / "502" ; Bad Gateway P226L41 / "503" ; Service Unavailable P226L42 / "504" ; Server Time-out P226L43 / "505" ; SIP Version not supported P226L44 / "513" ; Message Too Large P226L45 P226L46 P226L47 P226L48 P227L1 Global-Failure = "600" ; Busy Everywhere P227L2 / "603" ; Decline P227L3 / "604" ; Does not exist anywhere P227L4 / "606" ; Not Acceptable P227L5 P227L6 Accept = "Accept" HCOLON P227L7 [ accept-range *(COMMA accept-range) ] P227L8 accept-range = media-range *(SEMI accept-param) P227L9 media-range = ( "*/*" P227L10 / ( m-type SLASH "*" ) P227L11 / ( m-type SLASH m-subtype ) P227L12 ) *( SEMI m-parameter ) P227L13 accept-param = ("q" EQUAL qvalue) / generic-param P227L14 qvalue = ( "0" [ "." 0*3DIGIT ] ) P227L15 / ( "1" [ "." 0*3("0") ] ) P227L16 generic-param = token [ EQUAL gen-value ] P227L17 gen-value = token / host / quoted-string P227L18 P227L19 Accept-Encoding = "Accept-Encoding" HCOLON P227L20 [ encoding *(COMMA encoding) ] P227L21 encoding = codings *(SEMI accept-param) P227L22 codings = content-coding / "*" P227L23 content-coding = token P227L24 P227L25 Accept-Language = "Accept-Language" HCOLON P227L26 [ language *(COMMA language) ] P227L27 language = language-range *(SEMI accept-param) P227L28 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) P227L29 P227L30 Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) P227L31 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) P227L32 P227L33 Allow = "Allow" HCOLON [Method *(COMMA Method)] P227L34 P227L35 Authorization = "Authorization" HCOLON credentials P227L36 credentials = ("Digest" LWS digest-response) P227L37 / other-response P227L38 digest-response = dig-resp *(COMMA dig-resp) P227L39 dig-resp = username / realm / nonce / digest-uri P227L40 / dresponse / algorithm / cnonce P227L41 / opaque / message-qop P227L42 / nonce-count / auth-param P227L43 username = "username" EQUAL username-value P227L44 username-value = quoted-string P227L45 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT P227L46 digest-uri-value = rquest-uri ; Equal to request-uri as specified P227L47 by HTTP/1.1 P227L48 message-qop = "qop" EQUAL qop-value P228L1 cnonce = "cnonce" EQUAL cnonce-value P228L2 cnonce-value = nonce-value P228L3 nonce-count = "nc" EQUAL nc-value P228L4 nc-value = 8LHEX P228L5 dresponse = "response" EQUAL request-digest P228L6 request-digest = LDQUOT 32LHEX RDQUOT P228L7 auth-param = auth-param-name EQUAL P228L8 ( token / quoted-string ) P228L9 auth-param-name = token P228L10 other-response = auth-scheme LWS auth-param P228L11 *(COMMA auth-param) P228L12 auth-scheme = token P228L13 P228L14 Authentication-Info = "Authentication-Info" HCOLON ainfo P228L15 *(COMMA ainfo) P228L16 ainfo = nextnonce / message-qop P228L17 / response-auth / cnonce P228L18 / nonce-count P228L19 nextnonce = "nextnonce" EQUAL nonce-value P228L20 response-auth = "rspauth" EQUAL response-digest P228L21 response-digest = LDQUOT *LHEX RDQUOT P228L22 P228L23 Call-ID = ( "Call-ID" / "i" ) HCOLON callid P228L24 callid = word [ "@" word ] P228L25 P228L26 Call-Info = "Call-Info" HCOLON info *(COMMA info) P228L27 info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) P228L28 info-param = ( "purpose" EQUAL ( "icon" / "info" P228L29 / "card" / token ) ) / generic-param P228L30 P228L31 Contact = ("Contact" / "m" ) HCOLON P228L32 ( STAR / (contact-param *(COMMA contact-param))) P228L33 contact-param = (name-addr / addr-spec) *(SEMI contact-params) P228L34 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT P228L35 addr-spec = SIP-URI / SIPS-URI / absoluteURI P228L36 display-name = *(token LWS)/ quoted-string P228L37 P228L38 contact-params = c-p-q / c-p-expires P228L39 / contact-extension P228L40 c-p-q = "q" EQUAL qvalue P228L41 c-p-expires = "expires" EQUAL delta-seconds P228L42 contact-extension = generic-param P228L43 delta-seconds = 1*DIGIT P228L44 P228L45 Content-Disposition = "Content-Disposition" HCOLON P228L46 disp-type *( SEMI disp-param ) P228L47 disp-type = "render" / "session" / "icon" / "alert" P228L48 / disp-extension-token P229L1 disp-param = handling-param / generic-param P229L2 handling-param = "handling" EQUAL P229L3 ( "optional" / "required" P229L4 / other-handling ) P229L5 other-handling = token P229L6 disp-extension-token = token P229L7 P229L8 Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON P229L9 content-coding *(COMMA content-coding) P229L10 P229L11 Content-Language = "Content-Language" HCOLON P229L12 language-tag *(COMMA language-tag) P229L13 language-tag = primary-tag *( "-" subtag ) P229L14 primary-tag = 1*8ALPHA P229L15 subtag = 1*8ALPHA P229L16 P229L17 Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT P229L18 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type P229L19 media-type = m-type SLASH m-subtype *(SEMI m-parameter) P229L20 m-type = discrete-type / composite-type P229L21 discrete-type = "text" / "image" / "audio" / "video" P229L22 / "application" / extension-token P229L23 composite-type = "message" / "multipart" / extension-token P229L24 extension-token = ietf-token / x-token P229L25 ietf-token = token P229L26 x-token = "x-" token P229L27 m-subtype = extension-token / iana-token P229L28 iana-token = token P229L29 m-parameter = m-attribute EQUAL m-value P229L30 m-attribute = token P229L31 m-value = token / quoted-string P229L32 P229L33 CSeq = "CSeq" HCOLON 1*DIGIT LWS Method P229L34 P229L35 Date = "Date" HCOLON SIP-date P229L36 SIP-date = rfc1123-date P229L37 rfc1123-date = wkday "," SP date1 SP time SP "GMT" P229L38 date1 = 2DIGIT SP month SP 4DIGIT P229L39 ; day month year (e.g., 02 Jun 1982) P229L40 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT P229L41 ; 00:00:00 - 23:59:59 P229L42 wkday = "Mon" / "Tue" / "Wed" P229L43 / "Thu" / "Fri" / "Sat" / "Sun" P229L44 month = "Jan" / "Feb" / "Mar" / "Apr" P229L45 / "May" / "Jun" / "Jul" / "Aug" P229L46 / "Sep" / "Oct" / "Nov" / "Dec" P229L47 P229L48 Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) P230L1 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) P230L2 P230L3 Expires = "Expires" HCOLON delta-seconds P230L4 From = ( "From" / "f" ) HCOLON from-spec P230L5 from-spec = ( name-addr / addr-spec ) P230L6 *( SEMI from-param ) P230L7 from-param = tag-param / generic-param P230L8 tag-param = "tag" EQUAL token P230L9 P230L10 In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) P230L11 P230L12 Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT P230L13 P230L14 MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT P230L15 P230L16 Min-Expires = "Min-Expires" HCOLON delta-seconds P230L17 P230L18 Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] P230L19 P230L20 Priority = "Priority" HCOLON priority-value P230L21 priority-value = "emergency" / "urgent" / "normal" P230L22 / "non-urgent" / other-priority P230L23 other-priority = token P230L24 P230L25 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge P230L26 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) P230L27 / other-challenge P230L28 other-challenge = auth-scheme LWS auth-param P230L29 *(COMMA auth-param) P230L30 digest-cln = realm / domain / nonce P230L31 / opaque / stale / algorithm P230L32 / qop-options / auth-param P230L33 realm = "realm" EQUAL realm-value P230L34 realm-value = quoted-string P230L35 domain = "domain" EQUAL LDQUOT URI P230L36 *( 1*SP URI ) RDQUOT P230L37 URI = absoluteURI / abs-path P230L38 nonce = "nonce" EQUAL nonce-value P230L39 nonce-value = quoted-string P230L40 opaque = "opaque" EQUAL quoted-string P230L41 stale = "stale" EQUAL ( "true" / "false" ) P230L42 algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" P230L43 / token ) P230L44 qop-options = "qop" EQUAL LDQUOT qop-value P230L45 *("," qop-value) RDQUOT P230L46 qop-value = "auth" / "auth-int" / token P230L47 P230L48 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials P231L1 Proxy-Require = "Proxy-Require" HCOLON option-tag P231L2 *(COMMA option-tag) P231L3 option-tag = token P231L4 P231L5 Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) P231L6 rec-route = name-addr *( SEMI rr-param ) P231L7 rr-param = generic-param P231L8 P231L9 Reply-To = "Reply-To" HCOLON rplyto-spec P231L10 rplyto-spec = ( name-addr / addr-spec ) P231L11 *( SEMI rplyto-param ) P231L12 rplyto-param = generic-param P231L13 Require = "Require" HCOLON option-tag *(COMMA option-tag) P231L14 P231L15 Retry-After = "Retry-After" HCOLON delta-seconds P231L16 [ comment ] *( SEMI retry-param ) P231L17 P231L18 retry-param = ("duration" EQUAL delta-seconds) P231L19 / generic-param P231L20 P231L21 Route = "Route" HCOLON route-param *(COMMA route-param) P231L22 route-param = name-addr *( SEMI rr-param ) P231L23 P231L24 Server = "Server" HCOLON server-val *(LWS server-val) P231L25 server-val = product / comment P231L26 product = token [SLASH product-version] P231L27 product-version = token P231L28 P231L29 Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] P231L30 P231L31 Supported = ( "Supported" / "k" ) HCOLON P231L32 [option-tag *(COMMA option-tag)] P231L33 P231L34 Timestamp = "Timestamp" HCOLON 1*(DIGIT) P231L35 [ "." *(DIGIT) ] [ LWS delay ] P231L36 delay = *(DIGIT) [ "." *(DIGIT) ] P231L37 P231L38 To = ( "To" / "t" ) HCOLON ( name-addr P231L39 / addr-spec ) *( SEMI to-param ) P231L40 to-param = tag-param / generic-param P231L41 P231L42 Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) P231L43 User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) P231L44 P231L45 P231L46 P231L47 P231L48 P232L1 Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) P232L2 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) P232L3 via-params = via-ttl / via-maddr P232L4 / via-received / via-branch P232L5 / via-extension P232L6 via-ttl = "ttl" EQUAL ttl P232L7 via-maddr = "maddr" EQUAL host P232L8 via-received = "received" EQUAL (IPv4address / IPv6address) P232L9 via-branch = "branch" EQUAL token P232L10 via-extension = generic-param P232L11 sent-protocol = protocol-name SLASH protocol-version P232L12 SLASH transport P232L13 protocol-name = "SIP" / token P232L14 protocol-version = token P232L15 transport = "UDP" / "TCP" / "TLS" / "SCTP" P232L16 / other-transport P232L17 sent-by = host [ COLON port ] P232L18 ttl = 1*3DIGIT ; 0 to 255 P232L19 P232L20 Warning = "Warning" HCOLON warning-value *(COMMA warning-value) P232L21 warning-value = warn-code SP warn-agent SP warn-text P232L22 warn-code = 3DIGIT P232L23 warn-agent = hostport / pseudonym P232L24 ; the name or pseudonym of the server adding P232L25 ; the Warning header, for use in debugging P232L26 warn-text = quoted-string P232L27 pseudonym = token P232L28 P232L29 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge P232L30 P232L31 extension-header = header-name HCOLON header-value P232L32 header-name = token P232L33 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) P232L34 message-body = *OCTET P232L35 P232L36 26 Security Considerations: Threat Model and Security Usage P232L37 Recommendations P232L38 P232L39 SIP is not an easy protocol to secure. Its use of intermediaries, P232L40 its multi-faceted trust relationships, its expected usage between P232L41 elements with no trust at all, and its user-to-user operation make P232L42 security far from trivial. Security solutions are needed that are P232L43 deployable today, without extensive coordination, in a wide variety P232L44 of environments and usages. In order to meet these diverse needs, P232L45 several distinct mechanisms applicable to different aspects and P232L46 usages of SIP will be required. P232L47 P232L48 P233L1 Note that the security of SIP signaling itself has no bearing on the P233L2 security of protocols used in concert with SIP such as RTP, or with P233L3 the security implications of any specific bodies SIP might carry P233L4 (although MIME security plays a substantial role in securing SIP). P233L5 Any media associated with a session can be encrypted end-to-end P233L6 independently of any associated SIP signaling. Media encryption is P233L7 outside the scope of this document. P233L8 P233L9 The considerations that follow first examine a set of classic threat P233L10 models that broadly identify the security needs of SIP. The set of P233L11 security services required to address these threats is then detailed, P233L12 followed by an explanation of several security mechanisms that can be P233L13 used to provide these services. Next, the requirements for P233L14 implementers of SIP are enumerated, along with exemplary deployments P233L15 in which these security mechanisms could be used to improve the P233L16 security of SIP. Some notes on privacy conclude this section. P233L17 P233L18 26.1 Attacks and Threat Models P233L19 P233L20 This section details some threats that should be common to most P233L21 deployments of SIP. These threats have been chosen specifically to P233L22 illustrate each of the security services that SIP requires. P233L23 P233L24 The following examples by no means provide an exhaustive list of the P233L25 threats against SIP; rather, these are "classic" threats that P233L26 demonstrate the need for particular security services that can P233L27 potentially prevent whole categories of threats. P233L28 P233L29 These attacks assume an environment in which attackers can P233L30 potentially read any packet on the network - it is anticipated that P233L31 SIP will frequently be used on the public Internet. Attackers on the P233L32 network may be able to modify packets (perhaps at some compromised P233L33 intermediary). Attackers may wish to steal services, eavesdrop on P233L34 communications, or disrupt sessions. P233L35 P233L36 26.1.1 Registration Hijacking P233L37 P233L38 The SIP registration mechanism allows a user agent to identify itself P233L39 to a registrar as a device at which a user (designated by an address P233L40 of record) is located. A registrar assesses the identity asserted in P233L41 the From header field of a REGISTER message to determine whether this P233L42 request can modify the contact addresses associated with the P233L43 address-of-record in the To header field. While these two fields are P233L44 frequently the same, there are many valid deployments in which a P233L45 third-party may register contacts on a user's behalf. P233L46 P233L47 P233L48 P234L1 The From header field of a SIP request, however, can be modified P234L2 arbitrarily by the owner of a UA, and this opens the door to P234L3 malicious registrations. An attacker that successfully impersonates P234L4 a party authorized to change contacts associated with an address-of- P234L5 record could, for example, de-register all existing contacts for a P234L6 URI and then register their own device as the appropriate contact P234L7 address, thereby directing all requests for the affected user to the P234L8 attacker's device. P234L9 P234L10 This threat belongs to a family of threats that rely on the absence P234L11 of cryptographic assurance of a request's originator. Any SIP UAS P234L12 that represents a valuable service (a gateway that interworks SIP P234L13 requests with traditional telephone calls, for example) might want to P234L14 control access to its resources by authenticating requests that it P234L15 receives. Even end-user UAs, for example SIP phones, have an P234L16 interest in ascertaining the identities of originators of requests. P234L17 P234L18 This threat demonstrates the need for security services that enable P234L19 SIP entities to authenticate the originators of requests. P234L20 P234L21 26.1.2 Impersonating a Server P234L22 P234L23 The domain to which a request is destined is generally specified in P234L24 the Request-URI. UAs commonly contact a server in this domain P234L25 directly in order to deliver a request. However, there is always a P234L26 possibility that an attacker could impersonate the remote server, and P234L27 that the UA's request could be intercepted by some other party. P234L28 P234L29 For example, consider a case in which a redirect server at one P234L30 domain, chicago.com, impersonates a redirect server at another P234L31 domain, biloxi.com. A user agent sends a request to biloxi.com, but P234L32 the redirect server at chicago.com answers with a forged response P234L33 that has appropriate SIP header fields for a response from P234L34 biloxi.com. The forged contact addresses in the redirection response P234L35 could direct the originating UA to inappropriate or insecure P234L36 resources, or simply prevent requests for biloxi.com from succeeding. P234L37 P234L38 This family of threats has a vast membership, many of which are P234L39 critical. As a converse to the registration hijacking threat, P234L40 consider the case in which a registration sent to biloxi.com is P234L41 intercepted by chicago.com, which replies to the intercepted P234L42 registration with a forged 301 (Moved Permanently) response. This P234L43 response might seem to come from biloxi.com yet designate chicago.com P234L44 as the appropriate registrar. All future REGISTER requests from the P234L45 originating UA would then go to chicago.com. P234L46 P234L47 Prevention of this threat requires a means by which UAs can P234L48 authenticate the servers to whom they send requests. P235L1 26.1.3 Tampering with Message Bodies P235L2 P235L3 As a matter of course, SIP UAs route requests through trusted proxy P235L4 servers. Regardless of how that trust is established (authentication P235L5 of proxies is discussed elsewhere in this section), a UA may trust a P235L6 proxy server to route a request, but not to inspect or possibly P235L7 modify the bodies contained in that request. P235L8 P235L9 Consider a UA that is using SIP message bodies to communicate session P235L10 encryption keys for a media session. Although it trusts the proxy P235L11 server of the domain it is contacting to deliver signaling properly, P235L12 it may not want the administrators of that domain to be capable of P235L13 decrypting any subsequent media session. Worse yet, if the proxy P235L14 server were actively malicious, it could modify the session key, P235L15 either acting as a man-in-the-middle, or perhaps changing the P235L16 security characteristics requested by the originating UA. P235L17 P235L18 This family of threats applies not only to session keys, but to most P235L19 conceivable forms of content carried end-to-end in SIP. These might P235L20 include MIME bodies that should be rendered to the user, SDP, or P235L21 encapsulated telephony signals, among others. Attackers might P235L22 attempt to modify SDP bodies, for example, in order to point RTP P235L23 media streams to a wiretapping device in order to eavesdrop on P235L24 subsequent voice communications. P235L25 P235L26 Also note that some header fields in SIP are meaningful end-to-end, P235L27 for example, Subject. UAs might be protective of these header fields P235L28 as well as bodies (a malicious intermediary changing the Subject P235L29 header field might make an important request appear to be spam, for P235L30 example). However, since many header fields are legitimately P235L31 inspected or altered by proxy servers as a request is routed, not all P235L32 header fields should be secured end-to-end. P235L33 P235L34 For these reasons, the UA might want to secure SIP message bodies, P235L35 and in some limited cases header fields, end-to-end. The security P235L36 services required for bodies include confidentiality, integrity, and P235L37 authentication. These end-to-end services should be independent of P235L38 the means used to secure interactions with intermediaries such as P235L39 proxy servers. P235L40 P235L41 26.1.4 Tearing Down Sessions P235L42 P235L43 Once a dialog has been established by initial messaging, subsequent P235L44 requests can be sent that modify the state of the dialog and/or P235L45 session. It is critical that principals in a session can be certain P235L46 that such requests are not forged by attackers. P235L47 P235L48 P236L1 Consider a case in which a third-party attacker captures some initial P236L2 messages in a dialog shared by two parties in order to learn the P236L3 parameters of the session (To tag, From tag, and so forth) and then P236L4 inserts a BYE request into the session. The attacker could opt to P236L5 forge the request such that it seemed to come from either P236L6 participant. Once the BYE is received by its target, the session P236L7 will be torn down prematurely. P236L8 P236L9 Similar mid-session threats include the transmission of forged re- P236L10 INVITEs that alter the session (possibly to reduce session security P236L11 or redirect media streams as part of a wiretapping attack). P236L12 P236L13 The most effective countermeasure to this threat is the P236L14 authentication of the sender of the BYE. In this instance, the P236L15 recipient needs only know that the BYE came from the same party with P236L16 whom the corresponding dialog was established (as opposed to P236L17 ascertaining the absolute identity of the sender). Also, if the P236L18 attacker is unable to learn the parameters of the session due to P236L19 confidentiality, it would not be possible to forge the BYE. However, P236L20 some intermediaries (like proxy servers) will need to inspect those P236L21 parameters as the session is established. P236L22 P236L23 26.1.5 Denial of Service and Amplification P236L24 P236L25 Denial-of-service attacks focus on rendering a particular network P236L26 element unavailable, usually by directing an excessive amount of P236L27 network traffic at its interfaces. A distributed denial-of-service P236L28 attack allows one network user to cause multiple network hosts to P236L29 flood a target host with a large amount of network traffic. P236L30 P236L31 In many architectures, SIP proxy servers face the public Internet in P236L32 order to accept requests from worldwide IP endpoints. SIP creates a P236L33 number of potential opportunities for distributed denial-of-service P236L34 attacks that must be recognized and addressed by the implementers and P236L35 operators of SIP systems. P236L36 P236L37 Attackers can create bogus requests that contain a falsified source P236L38 IP address and a corresponding Via header field that identify a P236L39 targeted host as the originator of the request and then send this P236L40 request to a large number of SIP network elements, thereby using P236L41 hapless SIP UAs or proxies to generate denial-of-service traffic P236L42 aimed at the target. P236L43 P236L44 Similarly, attackers might use falsified Route header field values in P236L45 a request that identify the target host and then send such messages P236L46 to forking proxies that will amplify messaging sent to the target. P236L47 P236L48 P237L1 Record-Route could be used to similar effect when the attacker is P237L2 certain that the SIP dialog initiated by the request will result in P237L3 numerous transactions originating in the backwards direction. P237L4 P237L5 A number of denial-of-service attacks open up if REGISTER requests P237L6 are not properly authenticated and authorized by registrars. P237L7 Attackers could de-register some or all users in an administrative P237L8 domain, thereby preventing these users from being invited to new P237L9 sessions. An attacker could also register a large number of contacts P237L10 designating the same host for a given address-of-record in order to P237L11 use the registrar and any associated proxy servers as amplifiers in a P237L12 denial-of-service attack. Attackers might also attempt to deplete P237L13 available memory and disk resources of a registrar by registering P237L14 huge numbers of bindings. P237L15 P237L16 The use of multicast to transmit SIP requests can greatly increase P237L17 the potential for denial-of-service attacks. P237L18 P237L19 These problems demonstrate a general need to define architectures P237L20 that minimize the risks of denial-of-service, and the need to be P237L21 mindful in recommendations for security mechanisms of this class of P237L22 attacks. P237L23 P237L24 26.2 Security Mechanisms P237L25 P237L26 From the threats described above, we gather that the fundamental P237L27 security services required for the SIP protocol are: preserving the P237L28 confidentiality and integrity of messaging, preventing replay attacks P237L29 or message spoofing, providing for the authentication and privacy of P237L30 the participants in a session, and preventing denial-of-service P237L31 attacks. Bodies within SIP messages separately require the security P237L32 services of confidentiality, integrity, and authentication. P237L33 P237L34 Rather than defining new security mechanisms specific to SIP, SIP P237L35 reuses wherever possible existing security models derived from the P237L36 HTTP and SMTP space. P237L37 P237L38 Full encryption of messages provides the best means to preserve the P237L39 confidentiality of signaling - it can also guarantee that messages P237L40 are not modified by any malicious intermediaries. However, SIP P237L41 requests and responses cannot be naively encrypted end-to-end in P237L42 their entirety because message fields such as the Request-URI, Route, P237L43 and Via need to be visible to proxies in most network architectures P237L44 so that SIP requests are routed correctly. Note that proxy servers P237L45 need to modify some features of messages as well (such as adding Via P237L46 header field values) in order for SIP to function. Proxy servers P237L47 must therefore be trusted, to some degree, by SIP UAs. To this P237L48 purpose, low-layer security mechanisms for SIP are recommended, which P238L1 encrypt the entire SIP requests or responses on the wire on a hop- P238L2 by-hop basis, and that allow endpoints to verify the identity of P238L3 proxy servers to whom they send requests. P238L4 P238L5 SIP entities also have a need to identify one another in a secure P238L6 fashion. When a SIP endpoint asserts the identity of its user to a P238L7 peer UA or to a proxy server, that identity should in some way be P238L8 verifiable. A cryptographic authentication mechanism is provided in P238L9 SIP to address this requirement. P238L10 P238L11 An independent security mechanism for SIP message bodies supplies an P238L12 alternative means of end-to-end mutual authentication, as well as P238L13 providing a limit on the degree to which user agents must trust P238L14 intermediaries. P238L15 P238L16 26.2.1 Transport and Network Layer Security P238L17 P238L18 Transport or network layer security encrypts signaling traffic, P238L19 guaranteeing message confidentiality and integrity. P238L20 P238L21 Oftentimes, certificates are used in the establishment of lower-layer P238L22 security, and these certificates can also be used to provide a means P238L23 of authentication in many architectures. P238L24 P238L25 Two popular alternatives for providing security at the transport and P238L26 network layer are, respectively, TLS [25] and IPSec [26]. P238L27 P238L28 IPSec is a set of network-layer protocol tools that collectively can P238L29 be used as a secure replacement for traditional IP (Internet P238L30 Protocol). IPSec is most commonly used in architectures in which a P238L31 set of hosts or administrative domains have an existing trust P238L32 relationship with one another. IPSec is usually implemented at the P238L33 operating system level in a host, or on a security gateway that P238L34 provides confidentiality and integrity for all traffic it receives P238L35 from a particular interface (as in a VPN architecture). IPSec can P238L36 also be used on a hop-by-hop basis. P238L37 P238L38 In many architectures IPSec does not require integration with SIP P238L39 applications; IPSec is perhaps best suited to deployments in which P238L40 adding security directly to SIP hosts would be arduous. UAs that P238L41 have a pre-shared keying relationship with their first-hop proxy P238L42 server are also good candidates to use IPSec. Any deployment of P238L43 IPSec for SIP would require an IPSec profile describing the protocol P238L44 tools that would be required to secure SIP. No such profile is given P238L45 in this document. P238L46 P238L47 P238L48 P239L1 TLS provides transport-layer security over connection-oriented P239L2 protocols (for the purposes of this document, TCP); "tls" (signifying P239L3 TLS over TCP) can be specified as the desired transport protocol P239L4 within a Via header field value or a SIP-URI. TLS is most suited to P239L5 architectures in which hop-by-hop security is required between hosts P239L6 with no pre-existing trust association. For example, Alice trusts P239L7 her local proxy server, which after a certificate exchange decides to P239L8 trust Bob's local proxy server, which Bob trusts, hence Bob and Alice P239L9 can communicate securely. P239L10 P239L11 TLS must be tightly coupled with a SIP application. Note that P239L12 transport mechanisms are specified on a hop-by-hop basis in SIP, thus P239L13 a UA that sends requests over TLS to a proxy server has no assurance P239L14 that TLS will be used end-to-end. P239L15 P239L16 The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at P239L17 a minimum by implementers when TLS is used in a SIP application. For P239L18 purposes of backwards compatibility, proxy servers, redirect servers, P239L19 and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. P239L20 Implementers MAY also support any other ciphersuite. P239L21 P239L22 26.2.2 SIPS URI Scheme P239L23 P239L24 The SIPS URI scheme adheres to the syntax of the SIP URI (described P239L25 in 19), although the scheme string is "sips" rather than "sip". The P239L26 semantics of SIPS are very different from the SIP URI, however. SIPS P239L27 allows resources to specify that they should be reached securely. P239L28 P239L29 A SIPS URI can be used as an address-of-record for a particular user P239L30 - the URI by which the user is canonically known (on their business P239L31 cards, in the From header field of their requests, in the To header P239L32 field of REGISTER requests). When used as the Request-URI of a P239L33 request, the SIPS scheme signifies that each hop over which the P239L34 request is forwarded, until the request reaches the SIP entity P239L35 responsible for the domain portion of the Request-URI, must be P239L36 secured with TLS; once it reaches the domain in question it is P239L37 handled in accordance with local security and routing policy, quite P239L38 possibly using TLS for any last hop to a UAS. When used by the P239L39 originator of a request (as would be the case if they employed a SIPS P239L40 URI as the address-of-record of the target), SIPS dictates that the P239L41 entire request path to the target domain be so secured. P239L42 P239L43 The SIPS scheme is applicable to many of the other ways in which SIP P239L44 URIs are used in SIP today in addition to the Request-URI, including P239L45 in addresses-of-record, contact addresses (the contents of Contact P239L46 headers, including those of REGISTER methods), and Route headers. In P239L47 each instance, the SIPS URI scheme allows these existing fields to P239L48 P240L1 designate secure resources. The manner in which a SIPS URI is P240L2 dereferenced in any of these contexts has its own security properties P240L3 which are detailed in [4]. P240L4 P240L5 The use of SIPS in particular entails that mutual TLS authentication P240L6 SHOULD be employed, as SHOULD the ciphersuite P240L7 TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the P240L8 authentication process SHOULD be validated with root certificates P240L9 held by the client; failure to validate a certificate SHOULD result P240L10 in the failure of the request. P240L11 P240L12 Note that in the SIPS URI scheme, transport is independent of TLS, P240L13 and thus "sips:alice@atlanta.com;transport=tcp" and P240L14 "sips:alice@atlanta.com;transport=sctp" are both valid (although P240L15 note that UDP is not a valid transport for SIPS). The use of P240L16 "transport=tls" has consequently been deprecated, partly because P240L17 it was specific to a single hop of the request. This is a change P240L18 since RFC 2543. P240L19 P240L20 Users that distribute a SIPS URI as an address-of-record may elect to P240L21 operate devices that refuse requests over insecure transports. P240L22 P240L23 26.2.3 HTTP Authentication P240L24 P240L25 SIP provides a challenge capability, based on HTTP authentication, P240L26 that relies on the 401 and 407 response codes as well as header P240L27 fields for carrying challenges and credentials. Without significant P240L28 modification, the reuse of the HTTP Digest authentication scheme in P240L29 SIP allows for replay protection and one-way authentication. P240L30 P240L31 The usage of Digest authentication in SIP is detailed in Section 22. P240L32 P240L33 26.2.4 S/MIME P240L34 P240L35 As is discussed above, encrypting entire SIP messages end-to-end for P240L36 the purpose of confidentiality is not appropriate because network P240L37 intermediaries (like proxy servers) need to view certain header P240L38 fields in order to route messages correctly, and if these P240L39 intermediaries are excluded from security associations, then SIP P240L40 messages will essentially be non-routable. P240L41 P240L42 However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, P240L43 securing these bodies end-to-end without affecting message headers. P240L44 S/MIME can provide end-to-end confidentiality and integrity for P240L45 message bodies, as well as mutual authentication. It is also P240L46 possible to use S/MIME to provide a form of integrity and P240L47 confidentiality for SIP header fields through SIP message tunneling. P240L48 P241L1 The usage of S/MIME in SIP is detailed in Section 23. P241L2 P241L3 26.3 Implementing Security Mechanisms P241L4 P241L5 26.3.1 Requirements for Implementers of SIP P241L6 P241L7 Proxy servers, redirect servers, and registrars MUST implement TLS, P241L8 and MUST support both mutual and one-way authentication. It is P241L9 strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also P241L10 be capable of acting as a TLS server. Proxy servers, redirect P241L11 servers, and registrars SHOULD possess a site certificate whose P241L12 subject corresponds to their canonical hostname. UAs MAY have P241L13 certificates of their own for mutual authentication with TLS, but no P241L14 provisions are set forth in this document for their use. All SIP P241L15 elements that support TLS MUST have a mechanism for validating P241L16 certificates received during TLS negotiation; this entails possession P241L17 of one or more root certificates issued by certificate authorities P241L18 (preferably well-known distributors of site certificates comparable P241L19 to those that issue root certificates for web browsers). P241L20 P241L21 All SIP elements that support TLS MUST also support the SIPS URI P241L22 scheme. P241L23 P241L24 Proxy servers, redirect servers, registrars, and UAs MAY also P241L25 implement IPSec or other lower-layer security protocols. P241L26 P241L27 When a UA attempts to contact a proxy server, redirect server, or P241L28 registrar, the UAC SHOULD initiate a TLS connection over which it P241L29 will send SIP messages. In some architectures, UASs MAY receive P241L30 requests over such TLS connections as well. P241L31 P241L32 Proxy servers, redirect servers, registrars, and UAs MUST implement P241L33 Digest Authorization, encompassing all of the aspects required in 22. P241L34 Proxy servers, redirect servers, and registrars SHOULD be configured P241L35 with at least one Digest realm, and at least one "realm" string P241L36 supported by a given server SHOULD correspond to the server's P241L37 hostname or domainname. P241L38 P241L39 UAs MAY support the signing and encrypting of MIME bodies, and P241L40 transference of credentials with S/MIME as described in Section 23. P241L41 If a UA holds one or more root certificates of certificate P241L42 authorities in order to validate certificates for TLS or IPSec, it P241L43 SHOULD be capable of reusing these to verify S/MIME certificates, as P241L44 appropriate. A UA MAY hold root certificates specifically for P241L45 validating S/MIME certificates. P241L46 P241L47 P241L48 P242L1 Note that is it anticipated that future security extensions may P242L2 upgrade the normative strength associated with S/MIME as S/MIME P242L3 implementations appear and the problem space becomes better P242L4 understood. P242L5 P242L6 26.3.2 Security Solutions P242L7 P242L8 The operation of these security mechanisms in concert can follow the P242L9 existing web and email security models to some degree. At a high P242L10 level, UAs authenticate themselves to servers (proxy servers, P242L11 redirect servers, and registrars) with a Digest username and P242L12 password; servers authenticate themselves to UAs one hop away, or to P242L13 another server one hop away (and vice versa), with a site certificate P242L14 delivered by TLS. P242L15 P242L16 On a peer-to-peer level, UAs trust the network to authenticate one P242L17 another ordinarily; however, S/MIME can also be used to provide P242L18 direct authentication when the network does not, or if the network P242L19 itself is not trusted. P242L20 P242L21 The following is an illustrative example in which these security P242L22 mechanisms are used by various UAs and servers to prevent the sorts P242L23 of threats described in Section 26.1. While implementers and network P242L24 administrators MAY follow the normative guidelines given in the P242L25 remainder of this section, these are provided only as example P242L26 implementations. P242L27 P242L28 26.3.2.1 Registration P242L29 P242L30 When a UA comes online and registers with its local administrative P242L31 domain, it SHOULD establish a TLS connection with its registrar P242L32 (Section 10 describes how the UA reaches its registrar). The P242L33 registrar SHOULD offer a certificate to the UA, and the site P242L34 identified by the certificate MUST correspond with the domain in P242L35 which the UA intends to register; for example, if the UA intends to P242L36 register the address-of-record 'alice@atlanta.com', the site P242L37 certificate must identify a host within the atlanta.com domain (such P242L38 as sip.atlanta.com). When it receives the TLS Certificate message, P242L39 the UA SHOULD verify the certificate and inspect the site identified P242L40 by the certificate. If the certificate is invalid, revoked, or if it P242L41 does not identify the appropriate party, the UA MUST NOT send the P242L42 REGISTER message and otherwise proceed with the registration. P242L43 P242L44 When a valid certificate has been provided by the registrar, the P242L45 UA knows that the registrar is not an attacker who might redirect P242L46 the UA, steal passwords, or attempt any similar attacks. P242L47 P242L48 P243L1 The UA then creates a REGISTER request that SHOULD be addressed to a P243L2 Request-URI corresponding to the site certificate received from the P243L3 registrar. When the UA sends the REGISTER request over the existing P243L4 TLS connection, the registrar SHOULD challenge the request with a 401 P243L5 (Proxy Authentication Required) response. The "realm" parameter P243L6 within the Proxy-Authenticate header field of the response SHOULD P243L7 correspond to the domain previously given by the site certificate. P243L8 When the UAC receives the challenge, it SHOULD either prompt the user P243L9 for credentials or take an appropriate credential from a keyring P243L10 corresponding to the "realm" parameter in the challenge. The P243L11 username of this credential SHOULD correspond with the "userinfo" P243L12 portion of the URI in the To header field of the REGISTER request. P243L13 Once the Digest credentials have been inserted into an appropriate P243L14 Proxy-Authorization header field, the REGISTER should be resubmitted P243L15 to the registrar. P243L16 P243L17 Since the registrar requires the user agent to authenticate P243L18 itself, it would be difficult for an attacker to forge REGISTER P243L19 requests for the user's address-of-record. Also note that since P243L20 the REGISTER is sent over a confidential TLS connection, attackers P243L21 will not be able to intercept the REGISTER to record credentials P243L22 for any possible replay attack. P243L23 P243L24 Once the registration has been accepted by the registrar, the UA P243L25 SHOULD leave this TLS connection open provided that the registrar P243L26 also acts as the proxy server to which requests are sent for users in P243L27 this administrative domain. The existing TLS connection will be P243L28 reused to deliver incoming requests to the UA that has just completed P243L29 registration. P243L30 P243L31 Because the UA has already authenticated the server on the other P243L32 side of the TLS connection, all requests that come over this P243L33 connection are known to have passed through the proxy server - P243L34 attackers cannot create spoofed requests that appear to have been P243L35 sent through that proxy server. P243L36 P243L37 26.3.2.2 Interdomain Requests P243L38 P243L39 Now let's say that Alice's UA would like to initiate a session with a P243L40 user in a remote administrative domain, namely "bob@biloxi.com". We P243L41 will also say that the local administrative domain (atlanta.com) has P243L42 a local outbound proxy. P243L43 P243L44 The proxy server that handles inbound requests for an administrative P243L45 domain MAY also act as a local outbound proxy; for simplicity's sake P243L46 we'll assume this to be the case for atlanta.com (otherwise the user P243L47 agent would initiate a new TLS connection to a separate server at P243L48 this point). Assuming that the client has completed the registration P244L1 process described in the preceding section, it SHOULD reuse the TLS P244L2 connection to the local proxy server when it sends an INVITE request P244L3 to another user. The UA SHOULD reuse cached credentials in the P244L4 INVITE to avoid prompting the user unnecessarily. P244L5 P244L6 When the local outbound proxy server has validated the credentials P244L7 presented by the UA in the INVITE, it SHOULD inspect the Request-URI P244L8 to determine how the message should be routed (see [4]). If the P244L9 "domainname" portion of the Request-URI had corresponded to the local P244L10 domain (atlanta.com) rather than biloxi.com, then the proxy server P244L11 would have consulted its location service to determine how best to P244L12 reach the requested user. P244L13 P244L14 Had "alice@atlanta.com" been attempting to contact, say, P244L15 "alex@atlanta.com", the local proxy would have proxied to the P244L16 request to the TLS connection Alex had established with the P244L17 registrar when he registered. Since Alex would receive this P244L18 request over his authenticated channel, he would be assured that P244L19 Alice's request had been authorized by the proxy server of the P244L20 local administrative domain. P244L21 P244L22 However, in this instance the Request-URI designates a remote domain. P244L23 The local outbound proxy server at atlanta.com SHOULD therefore P244L24 establish a TLS connection with the remote proxy server at P244L25 biloxi.com. Since both of the participants in this TLS connection P244L26 are servers that possess site certificates, mutual TLS authentication P244L27 SHOULD occur. Each side of the connection SHOULD verify and inspect P244L28 the certificate of the other, noting the domain name that appears in P244L29 the certificate for comparison with the header fields of SIP P244L30 messages. The atlanta.com proxy server, for example, SHOULD verify P244L31 at this stage that the certificate received from the remote side P244L32 corresponds with the biloxi.com domain. Once it has done so, and TLS P244L33 negotiation has completed, resulting in a secure channel between the P244L34 two proxies, the atlanta.com proxy can forward the INVITE request to P244L35 biloxi.com. P244L36 P244L37 The proxy server at biloxi.com SHOULD inspect the certificate of the P244L38 proxy server at atlanta.com in turn and compare the domain asserted P244L39 by the certificate with the "domainname" portion of the From header P244L40 field in the INVITE request. The biloxi proxy MAY have a strict P244L41 security policy that requires it to reject requests that do not match P244L42 the administrative domain from which they have been proxied. P244L43 P244L44 Such security policies could be instituted to prevent the SIP P244L45 equivalent of SMTP 'open relays' that are frequently exploited to P244L46 generate spam. P244L47 P244L48 P245L1 This policy, however, only guarantees that the request came from the P245L2 domain it ascribes to itself; it does not allow biloxi.com to P245L3 ascertain how atlanta.com authenticated Alice. Only if biloxi.com P245L4 has some other way of knowing atlanta.com's authentication policies P245L5 could it possibly ascertain how Alice proved her identity. P245L6 biloxi.com might then institute an even stricter policy that forbids P245L7 requests that come from domains that are not known administratively P245L8 to share a common authentication policy with biloxi.com. P245L9 P245L10 Once the INVITE has been approved by the biloxi proxy, the proxy P245L11 server SHOULD identify the existing TLS channel, if any, associated P245L12 with the user targeted by this request (in this case P245L13 "bob@biloxi.com"). The INVITE should be proxied through this channel P245L14 to Bob. Since the request is received over a TLS connection that had P245L15 previously been authenticated as the biloxi proxy, Bob knows that the P245L16 From header field was not tampered with and that atlanta.com has P245L17 validated Alice, although not necessarily whether or not to trust P245L18 Alice's identity. P245L19 P245L20 Before they forward the request, both proxy servers SHOULD add a P245L21 Record-Route header field to the request so that all future requests P245L22 in this dialog will pass through the proxy servers. The proxy P245L23 servers can thereby continue to provide security services for the P245L24 lifetime of this dialog. If the proxy servers do not add themselves P245L25 to the Record-Route, future messages will pass directly end-to-end P245L26 between Alice and Bob without any security services (unless the two P245L27 parties agree on some independent end-to-end security such as P245L28 S/MIME). In this respect the SIP trapezoid model can provide a nice P245L29 structure where conventions of agreement between the site proxies can P245L30 provide a reasonably secure channel between Alice and Bob. P245L31 P245L32 An attacker preying on this architecture would, for example, be P245L33 unable to forge a BYE request and insert it into the signaling P245L34 stream between Bob and Alice because the attacker has no way of P245L35 ascertaining the parameters of the session and also because the P245L36 integrity mechanism transitively protects the traffic between P245L37 Alice and Bob. P245L38 P245L39 26.3.2.3 Peer-to-Peer Requests P245L40 P245L41 Alternatively, consider a UA asserting the identity P245L42 "carol@chicago.com" that has no local outbound proxy. When Carol P245L43 wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate P245L44 a TLS connection with the biloxi proxy directly (using the mechanism P245L45 described in [4] to determine how to best to reach the given P245L46 Request-URI). When her UA receives a certificate from the biloxi P245L47 proxy, it SHOULD be verified normally before she passes her INVITE P245L48 across the TLS connection. However, Carol has no means of proving P246L1 her identity to the biloxi proxy, but she does have a CMS-detached P246L2 signature over a "message/sip" body in the INVITE. It is unlikely in P246L3 this instance that Carol would have any credentials in the biloxi.com P246L4 realm, since she has no formal association with biloxi.com. The P246L5 biloxi proxy MAY also have a strict policy that precludes it from P246L6 even bothering to challenge requests that do not have biloxi.com in P246L7 the "domainname" portion of the From header field - it treats these P246L8 users as unauthenticated. P246L9 P246L10 The biloxi proxy has a policy for Bob that all non-authenticated P246L11 requests should be redirected to the appropriate contact address P246L12 registered against 'bob@biloxi.com', namely . P246L13 Carol receives the redirection response over the TLS connection she P246L14 established with the biloxi proxy, so she trusts the veracity of the P246L15 contact address. P246L16 P246L17 Carol SHOULD then establish a TCP connection with the designated P246L18 address and send a new INVITE with a Request-URI containing the P246L19 received contact address (recomputing the signature in the body as P246L20 the request is readied). Bob receives this INVITE on an insecure P246L21 interface, but his UA inspects and, in this instance, recognizes the P246L22 From header field of the request and subsequently matches a locally P246L23 cached certificate with the one presented in the signature of the P246L24 body of the INVITE. He replies in similar fashion, authenticating P246L25 himself to Carol, and a secure dialog begins. P246L26 P246L27 Sometimes firewalls or NATs in an administrative domain could P246L28 preclude the establishment of a direct TCP connection to a UA. In P246L29 these cases, proxy servers could also potentially relay requests P246L30 to UAs in a way that has no trust implications (for example, P246L31 forgoing an existing TLS connection and forwarding the request P246L32 over cleartext TCP) as local policy dictates. P246L33 P246L34 26.3.2.4 DoS Protection P246L35 P246L36 In order to minimize the risk of a denial-of-service attack against P246L37 architectures using these security solutions, implementers should P246L38 take note of the following guidelines. P246L39 P246L40 When the host on which a SIP proxy server is operating is routable P246L41 from the public Internet, it SHOULD be deployed in an administrative P246L42 domain with defensive operational policies (blocking source-routed P246L43 traffic, preferably filtering ping traffic). Both TLS and IPSec can P246L44 also make use of bastion hosts at the edges of administrative domains P246L45 that participate in the security associations to aggregate secure P246L46 tunnels and sockets. These bastion hosts can also take the brunt of P246L47 denial-of-service attacks, ensuring that SIP hosts within the P246L48 administrative domain are not encumbered with superfluous messaging. P247L1 No matter what security solutions are deployed, floods of messages P247L2 directed at proxy servers can lock up proxy server resources and P247L3 prevent desirable traffic from reaching its destination. There is a P247L4 computational expense associated with processing a SIP transaction at P247L5 a proxy server, and that expense is greater for stateful proxy P247L6 servers than it is for stateless proxy servers. Therefore, stateful P247L7 proxies are more susceptible to flooding than stateless proxy P247L8 servers. P247L9 P247L10 UAs and proxy servers SHOULD challenge questionable requests with P247L11 only a single 401 (Unauthorized) or 407 (Proxy Authentication P247L12 Required), forgoing the normal response retransmission algorithm, and P247L13 thus behaving statelessly towards unauthenticated requests. P247L14 P247L15 Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication P247L16 Required) status response amplifies the problem of an attacker P247L17 using a falsified header field value (such as Via) to direct P247L18 traffic to a third party. P247L19 P247L20 In summary, the mutual authentication of proxy servers through P247L21 mechanisms such as TLS significantly reduces the potential for rogue P247L22 intermediaries to introduce falsified requests or responses that can P247L23 deny service. This commensurately makes it harder for attackers to P247L24 make innocent SIP nodes into agents of amplification. P247L25 P247L26 26.4 Limitations P247L27 P247L28 Although these security mechanisms, when applied in a judicious P247L29 manner, can thwart many threats, there are limitations in the scope P247L30 of the mechanisms that must be understood by implementers and network P247L31 operators. P247L32 P247L33 26.4.1 HTTP Digest P247L34 P247L35 One of the primary limitations of using HTTP Digest in SIP is that P247L36 the integrity mechanisms in Digest do not work very well for SIP. P247L37 Specifically, they offer protection of the Request-URI and the method P247L38 of a message, but not for any of the header fields that UAs would P247L39 most likely wish to secure. P247L40 P247L41 The existing replay protection mechanisms described in RFC 2617 also P247L42 have some limitations for SIP. The next-nonce mechanism, for P247L43 example, does not support pipelined requests. The nonce-count P247L44 mechanism should be used for replay protection. P247L45 P247L46 Another limitation of HTTP Digest is the scope of realms. Digest is P247L47 valuable when a user wants to authenticate themselves to a resource P247L48 with which they have a pre-existing association, like a service P248L1 provider of which the user is a customer (which is quite a common P248L2 scenario and thus Digest provides an extremely useful function). By P248L3 way of contrast, the scope of TLS is interdomain or multirealm, since P248L4 certificates are often globally verifiable, so that the UA can P248L5 authenticate the server with no pre-existing association. P248L6 P248L7 26.4.2 S/MIME P248L8 P248L9 The largest outstanding defect with the S/MIME mechanism is the lack P248L10 of a prevalent public key infrastructure for end users. If self- P248L11 signed certificates (or certificates that cannot be verified by one P248L12 of the participants in a dialog) are used, the SIP-based key exchange P248L13 mechanism described in Section 23.2 is susceptible to a man-in-the- P248L14 middle attack with which an attacker can potentially inspect and P248L15 modify S/MIME bodies. The attacker needs to intercept the first P248L16 exchange of keys between the two parties in a dialog, remove the P248L17 existing CMS-detached signatures from the request and response, and P248L18 insert a different CMS-detached signature containing a certificate P248L19 supplied by the attacker (but which seems to be a certificate for the P248L20 proper address-of-record). Each party will think they have exchanged P248L21 keys with the other, when in fact each has the public key of the P248L22 attacker. P248L23 P248L24 It is important to note that the attacker can only leverage this P248L25 vulnerability on the first exchange of keys between two parties - on P248L26 subsequent occasions, the alteration of the key would be noticeable P248L27 to the UAs. It would also be difficult for the attacker to remain in P248L28 the path of all future dialogs between the two parties over time (as P248L29 potentially days, weeks, or years pass). P248L30 P248L31 SSH is susceptible to the same man-in-the-middle attack on the first P248L32 exchange of keys; however, it is widely acknowledged that while SSH P248L33 is not perfect, it does improve the security of connections. The use P248L34 of key fingerprints could provide some assistance to SIP, just as it P248L35 does for SSH. For example, if two parties use SIP to establish a P248L36 voice communications session, each could read off the fingerprint of P248L37 the key they received from the other, which could be compared against P248L38 the original. It would certainly be more difficult for the man-in- P248L39 the-middle to emulate the voices of the participants than their P248L40 signaling (a practice that was used with the Clipper chip-based P248L41 secure telephone). P248L42 P248L43 The S/MIME mechanism allows UAs to send encrypted requests without P248L44 preamble if they possess a certificate for the destination address- P248L45 of-record on their keyring. However, it is possible that any P248L46 particular device registered for an address-of-record will not hold P248L47 the certificate that has been previously employed by the device's P248L48 current user, and that it will therefore be unable to process an P249L1 encrypted request properly, which could lead to some avoidable error P249L2 signaling. This is especially likely when an encrypted request is P249L3 forked. P249L4 P249L5 The keys associated with S/MIME are most useful when associated with P249L6 a particular user (an address-of-record) rather than a device (a UA). P249L7 When users move between devices, it may be difficult to transport P249L8 private keys securely between UAs; how such keys might be acquired by P249L9 a device is outside the scope of this document. P249L10 P249L11 Another, more prosaic difficulty with the S/MIME mechanism is that it P249L12 can result in very large messages, especially when the SIP tunneling P249L13 mechanism described in Section 23.4 is used. For that reason, it is P249L14 RECOMMENDED that TCP should be used as a transport protocol when P249L15 S/MIME tunneling is employed. P249L16 P249L17 26.4.3 TLS P249L18 P249L19 The most commonly voiced concern about TLS is that it cannot run over P249L20 UDP; TLS requires a connection-oriented underlying transport P249L21 protocol, which for the purposes of this document means TCP. P249L22 P249L23 It may also be arduous for a local outbound proxy server and/or P249L24 registrar to maintain many simultaneous long-lived TLS connections P249L25 with numerous UAs. This introduces some valid scalability concerns, P249L26 especially for intensive ciphersuites. Maintaining redundancy of P249L27 long-lived TLS connections, especially when a UA is solely P249L28 responsible for their establishment, could also be cumbersome. P249L29 P249L30 TLS only allows SIP entities to authenticate servers to which they P249L31 are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, P249L32 nor any other mechanism specified in this document, allows clients to P249L33 authenticate proxy servers to whom they cannot form a direct TCP P249L34 connection. P249L35 P249L36 26.4.4 SIPS URIs P249L37 P249L38 Actually using TLS on every segment of a request path entails that P249L39 the terminating UAS must be reachable over TLS (perhaps registering P249L40 with a SIPS URI as a contact address). This is the preferred use of P249L41 SIPS. Many valid architectures, however, use TLS to secure part of P249L42 the request path, but rely on some other mechanism for the final hop P249L43 to a UAS, for example. Thus SIPS cannot guarantee that TLS usage P249L44 will be truly end-to-end. Note that since many UAs will not accept P249L45 incoming TLS connections, even those UAs that do support TLS may be P249L46 required to maintain persistent TLS connections as described in the P249L47 TLS limitations section above in order to receive requests over TLS P249L48 as a UAS. P250L1 Location services are not required to provide a SIPS binding for a P250L2 SIPS Request-URI. Although location services are commonly populated P250L3 by user registrations (as described in Section 10.2.1), various other P250L4 protocols and interfaces could conceivably supply contact addresses P250L5 for an AOR, and these tools are free to map SIPS URIs to SIP URIs as P250L6 appropriate. When queried for bindings, a location service returns P250L7 its contact addresses without regard for whether it received a P250L8 request with a SIPS Request-URI. If a redirect server is accessing P250L9 the location service, it is up to the entity that processes the P250L10 Contact header field of a redirection to determine the propriety of P250L11 the contact addresses. P250L12 P250L13 Ensuring that TLS will be used for all of the request segments up to P250L14 the target domain is somewhat complex. It is possible that P250L15 cryptographically authenticated proxy servers along the way that are P250L16 non-compliant or compromised may choose to disregard the forwarding P250L17 rules associated with SIPS (and the general forwarding rules in P250L18 Section 16.6). Such malicious intermediaries could, for example, P250L19 retarget a request from a SIPS URI to a SIP URI in an attempt to P250L20 downgrade security. P250L21 P250L22 Alternatively, an intermediary might legitimately retarget a request P250L23 from a SIP to a SIPS URI. Recipients of a request whose Request-URI P250L24 uses the SIPS URI scheme thus cannot assume on the basis of the P250L25 Request-URI alone that SIPS was used for the entire request path P250L26 (from the client onwards). P250L27 P250L28 To address these concerns, it is RECOMMENDED that recipients of a P250L29 request whose Request-URI contains a SIP or SIPS URI inspect the To P250L30 header field value to see if it contains a SIPS URI (though note that P250L31 it does not constitute a breach of security if this URI has the same P250L32 scheme but is not equivalent to the URI in the To header field). P250L33 Although clients may choose to populate the Request-URI and To header P250L34 field of a request differently, when SIPS is used this disparity P250L35 could be interpreted as a possible security violation, and the P250L36 request could consequently be rejected by its recipient. Recipients P250L37 MAY also inspect the Via header chain in order to double-check P250L38 whether or not TLS was used for the entire request path until the P250L39 local administrative domain was reached. S/MIME may also be used by P250L40 the originating UAC to help ensure that the original form of the To P250L41 header field is carried end-to-end. P250L42 P250L43 If the UAS has reason to believe that the scheme of the Request-URI P250L44 has been improperly modified in transit, the UA SHOULD notify its P250L45 user of a potential security breach. P250L46 P250L47 P250L48 P251L1 As a further measure to prevent downgrade attacks, entities that P251L2 accept only SIPS requests MAY also refuse connections on insecure P251L3 ports. P251L4 P251L5 End users will undoubtedly discern the difference between SIPS and P251L6 SIP URIs, and they may manually edit them in response to stimuli. P251L7 This can either benefit or degrade security. For example, if an P251L8 attacker corrupts a DNS cache, inserting a fake record set that P251L9 effectively removes all SIPS records for a proxy server, then any P251L10 SIPS requests that traverse this proxy server may fail. When a user, P251L11 however, sees that repeated calls to a SIPS AOR are failing, they P251L12 could on some devices manually convert the scheme from SIPS to SIP P251L13 and retry. Of course, there are some safeguards against this (if the P251L14 destination UA is truly paranoid it could refuse all non-SIPS P251L15 requests), but it is a limitation worth noting. On the bright side, P251L16 users might also divine that 'SIPS' would be valid even when they are P251L17 presented only with a SIP URI. P251L18 P251L19 26.5 Privacy P251L20 P251L21 SIP messages frequently contain sensitive information about their P251L22 senders - not just what they have to say, but with whom they P251L23 communicate, when they communicate and for how long, and from where P251L24 they participate in sessions. Many applications and their users P251L25 require that this sort of private information be hidden from any P251L26 parties that do not need to know it. P251L27 P251L28 Note that there are also less direct ways in which private P251L29 information can be divulged. If a user or service chooses to be P251L30 reachable at an address that is guessable from the person's name and P251L31 organizational affiliation (which describes most addresses-of- P251L32 record), the traditional method of ensuring privacy by having an P251L33 unlisted "phone number" is compromised. A user location service can P251L34 infringe on the privacy of the recipient of a session invitation by P251L35 divulging their specific whereabouts to the caller; an implementation P251L36 consequently SHOULD be able to restrict, on a per-user basis, what P251L37 kind of location and availability information is given out to certain P251L38 classes of callers. This is a whole class of problem that is P251L39 expected to be studied further in ongoing SIP work. P251L40 P251L41 In some cases, users may want to conceal personal information in P251L42 header fields that convey identity. This can apply not only to the P251L43 From and related headers representing the originator of the request, P251L44 but also the To - it may not be appropriate to convey to the final P251L45 destination a speed-dialing nickname, or an unexpanded identifier for P251L46 a group of targets, either of which would be removed from the P251L47 Request-URI as the request is routed, but not changed in the To P251L48 P252L1 header field if the two were initially identical. Thus it MAY be P252L2 desirable for privacy reasons to create a To header field that P252L3 differs from the Request-URI. P252L4 P252L5 27 IANA Considerations P252L6 P252L7 All method names, header field names, status codes, and option tags P252L8 used in SIP applications are registered with IANA through P252L9 instructions in an IANA Considerations section in an RFC. P252L10 P252L11 The specification instructs the IANA to create four new sub- P252L12 registries under http://www.iana.org/assignments/sip-parameters: P252L13 Option Tags, Warning Codes (warn-codes), Methods and Response Codes, P252L14 added to the sub-registry of Header Fields that is already present P252L15 there. P252L16 P252L17 27.1 Option Tags P252L18 P252L19 This specification establishes the Option Tags sub-registry under P252L20 http://www.iana.org/assignments/sip-parameters. P252L21 P252L22 Option tags are used in header fields such as Require, Supported, P252L23 Proxy-Require, and Unsupported in support of SIP compatibility P252L24 mechanisms for extensions (Section 19.2). The option tag itself is a P252L25 string that is associated with a particular SIP option (that is, an P252L26 extension). It identifies the option to SIP endpoints. P252L27 P252L28 Option tags are registered by the IANA when they are published in P252L29 standards track RFCs. The IANA Considerations section of the RFC P252L30 must include the following information, which appears in the IANA P252L31 registry along with the RFC number of the publication. P252L32 P252L33 o Name of the option tag. The name MAY be of any length, but P252L34 SHOULD be no more than twenty characters long. The name MUST P252L35 consist of alphanum (Section 25) characters only. P252L36 P252L37 o Descriptive text that describes the extension. P252L38 P252L39 27.2 Warn-Codes P252L40 P252L41 This specification establishes the Warn-codes sub-registry under P252L42 http://www.iana.org/assignments/sip-parameters and initiates its P252L43 population with the warn-codes listed in Section 20.43. Additional P252L44 warn-codes are registered by RFC publication. P252L45 P252L46 P252L47 P252L48 P253L1 The descriptive text for the table of warn-codes is: P253L2 P253L3 Warning codes provide information supplemental to the status code in P253L4 SIP response messages when the failure of the transaction results P253L5 from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. P253L6 P253L7 The "warn-code" consists of three digits. A first digit of "3" P253L8 indicates warnings specific to SIP. Until a future specification P253L9 describes uses of warn-codes other than 3xx, only 3xx warn-codes may P253L10 be registered. P253L11 P253L12 Warnings 300 through 329 are reserved for indicating problems with P253L13 keywords in the session description, 330 through 339 are warnings P253L14 related to basic network services requested in the session P253L15 description, 370 through 379 are warnings related to quantitative QoS P253L16 parameters requested in the session description, and 390 through 399 P253L17 are miscellaneous warnings that do not fall into one of the above P253L18 categories. P253L19 P253L20 27.3 Header Field Names P253L21 P253L22 This obsoletes the IANA instructions about the header sub-registry P253L23 under http://www.iana.org/assignments/sip-parameters. P253L24 P253L25 The following information needs to be provided in an RFC publication P253L26 in order to register a new header field name: P253L27 P253L28 o The RFC number in which the header is registered; P253L29 P253L30 o the name of the header field being registered; P253L31 P253L32 o a compact form version for that header field, if one is P253L33 defined; P253L34 P253L35 Some common and widely used header fields MAY be assigned one-letter P253L36 compact forms (Section 7.3.3). Compact forms can only be assigned P253L37 after SIP working group review, followed by RFC publication. P253L38 P253L39 27.4 Method and Response Codes P253L40 P253L41 This specification establishes the Method and Response-Code sub- P253L42 registries under http://www.iana.org/assignments/sip-parameters and P253L43 initiates their population as follows. The initial Methods table is: P253L44 P253L45 P253L46 P253L47 P253L48 P254L1 INVITE [RFC3261] P254L2 ACK [RFC3261] P254L3 BYE [RFC3261] P254L4 CANCEL [RFC3261] P254L5 REGISTER [RFC3261] P254L6 OPTIONS [RFC3261] P254L7 INFO [RFC2976] P254L8 P254L9 The response code table is initially populated from Section 21, the P254L10 portions labeled Informational, Success, Redirection, Client-Error, P254L11 Server-Error, and Global-Failure. The table has the following P254L12 format: P254L13 P254L14 Type (e.g., Informational) P254L15 Number Default Reason Phrase [RFC3261] P254L16 P254L17 The following information needs to be provided in an RFC publication P254L18 in order to register a new response code or method: P254L19 P254L20 o The RFC number in which the method or response code is P254L21 registered; P254L22 P254L23 o the number of the response code or name of the method being P254L24 registered; P254L25 P254L26 o the default reason phrase for that response code, if P254L27 applicable; P254L28 P254L29 27.5 The "message/sip" MIME type. P254L30 P254L31 This document registers the "message/sip" MIME media type in order to P254L32 allow SIP messages to be tunneled as bodies within SIP, primarily for P254L33 end-to-end security purposes. This media type is defined by the P254L34 following information: P254L35 P254L36 Media type name: message P254L37 Media subtype name: sip P254L38 Required parameters: none P254L39 P254L40 Optional parameters: version P254L41 version: The SIP-Version number of the enclosed message (e.g., P254L42 "2.0"). If not present, the version defaults to "2.0". P254L43 Encoding scheme: SIP messages consist of an 8-bit header P254L44 optionally followed by a binary MIME data object. As such, SIP P254L45 messages must be treated as binary. Under normal circumstances P254L46 SIP messages are transported over binary-capable transports, no P254L47 special encodings are needed. P254L48 P255L1 Security considerations: see below P255L2 Motivation and examples of this usage as a security mechanism P255L3 in concert with S/MIME are given in 23.4. P255L4 P255L5 27.6 New Content-Disposition Parameter Registrations P255L6 P255L7 This document also registers four new Content-Disposition header P255L8 "disposition-types": alert, icon, session and render. The authors P255L9 request that these values be recorded in the IANA registry for P255L10 Content-Dispositions. P255L11 P255L12 Descriptions of these "disposition-types", including motivation and P255L13 examples, are given in Section 20.11. P255L14 P255L15 Short descriptions suitable for the IANA registry are: P255L16 P255L17 alert the body is a custom ring tone to alert the user P255L18 icon the body is displayed as an icon to the user P255L19 render the body should be displayed to the user P255L20 session the body describes a communications session, for P255L21 example, as RFC 2327 SDP body P255L22 P255L23 28 Changes From RFC 2543 P255L24 P255L25 This RFC revises RFC 2543. It is mostly backwards compatible with P255L26 RFC 2543. The changes described here fix many errors discovered in P255L27 RFC 2543 and provide information on scenarios not detailed in RFC P255L28 2543. The protocol has been presented in a more cleanly layered P255L29 model here. P255L30 P255L31 We break the differences into functional behavior that is a P255L32 substantial change from RFC 2543, which has impact on P255L33 interoperability or correct operation in some cases, and functional P255L34 behavior that is different from RFC 2543 but not a potential source P255L35 of interoperability problems. There have been countless P255L36 clarifications as well, which are not documented here. P255L37 P255L38 28.1 Major Functional Changes P255L39 P255L40 o When a UAC wishes to terminate a call before it has been answered, P255L41 it sends CANCEL. If the original INVITE still returns a 2xx, the P255L42 UAC then sends BYE. BYE can only be sent on an existing call leg P255L43 (now called a dialog in this RFC), whereas it could be sent at any P255L44 time in RFC 2543. P255L45 P255L46 o The SIP BNF was converted to be RFC 2234 compliant. P255L47 P255L48 P256L1 o SIP URL BNF was made more general, allowing a greater set of P256L2 characters in the user part. Furthermore, comparison rules were P256L3 simplified to be primarily case-insensitive, and detailed handling P256L4 of comparison in the presence of parameters was described. The P256L5 most substantial change is that a URI with a parameter with the P256L6 default value does not match a URI without that parameter. P256L7 P256L8 o Removed Via hiding. It had serious trust issues, since it relied P256L9 on the next hop to perform the obfuscation process. Instead, Via P256L10 hiding can be done as a local implementation choice in stateful P256L11 proxies, and thus is no longer documented. P256L12 P256L13 o In RFC 2543, CANCEL and INVITE transactions were intermingled. P256L14 They are separated now. When a user sends an INVITE and then a P256L15 CANCEL, the INVITE transaction still terminates normally. A UAS P256L16 needs to respond to the original INVITE request with a 487 P256L17 response. P256L18 P256L19 o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 P256L20 allowed the UAS not to send a response to INVITE when a BYE was P256L21 received. That is disallowed here. The original INVITE needs a P256L22 response. P256L23 P256L24 o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs P256L25 need to support both UDP and TCP. P256L26 P256L27 o In RFC 2543, a forking proxy only passed up one challenge from P256L28 downstream elements in the event of multiple challenges. In this P256L29 RFC, proxies are supposed to collect all challenges and place them P256L30 into the forwarded response. P256L31 P256L32 o In Digest credentials, the URI needs to be quoted; this is unclear P256L33 from RFC 2617 and RFC 2069 which are both inconsistent on it. P256L34 P256L35 o SDP processing has been split off into a separate specification P256L36 [13], and more fully specified as a formal offer/answer exchange P256L37 process that is effectively tunneled through SIP. SDP is allowed P256L38 in INVITE/200 or 200/ACK for baseline SIP implementations; RFC P256L39 2543 alluded to the ability to use it in INVITE, 200, and ACK in a P256L40 single transaction, but this was not well specified. More complex P256L41 SDP usages are allowed in extensions. P256L42 P256L43 P256L44 P256L45 P256L46 P256L47 P256L48 P257L1 o Added full support for IPv6 in URIs and in the Via header field. P257L2 Support for IPv6 in Via has required that its header field P257L3 parameters allow the square bracket and colon characters. These P257L4 characters were previously not permitted. In theory, this could P257L5 cause interop problems with older implementations. However, we P257L6 have observed that most implementations accept any non-control P257L7 ASCII character in these parameters. P257L8 P257L9 o DNS SRV procedure is now documented in a separate specification P257L10 [4]. This procedure uses both SRV and NAPTR resource records and P257L11 no longer combines data from across SRV records as described in P257L12 RFC 2543. P257L13 P257L14 o Loop detection has been made optional, supplanted by a mandatory P257L15 usage of Max-Forwards. The loop detection procedure in RFC 2543 P257L16 had a serious bug which would report "spirals" as an error P257L17 condition when it was not. The optional loop detection procedure P257L18 is more fully and correctly specified here. P257L19 P257L20 o Usage of tags is now mandatory (they were optional in RFC 2543), P257L21 as they are now the fundamental building blocks of dialog P257L22 identification. P257L23 P257L24 o Added the Supported header field, allowing for clients to indicate P257L25 what extensions are supported to a server, which can apply those P257L26 extensions to the response, and indicate their usage with a P257L27 Require in the response. P257L28 P257L29 o Extension parameters were missing from the BNF for several header P257L30 fields, and they have been added. P257L31 P257L32 o Handling of Route and Record-Route construction was very P257L33 underspecified in RFC 2543, and also not the right approach. It P257L34 has been substantially reworked in this specification (and made P257L35 vastly simpler), and this is arguably the largest change. P257L36 Backwards compatibility is still provided for deployments that do P257L37 not use "pre-loaded routes", where the initial request has a set P257L38 of Route header field values obtained in some way outside of P257L39 Record-Route. In those situations, the new mechanism is not P257L40 interoperable. P257L41 P257L42 o In RFC 2543, lines in a message could be terminated with CR, LF, P257L43 or CRLF. This specification only allows CRLF. P257L44 P257L45 P257L46 P257L47 P257L48 P258L1 o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. P258L2 It is now well specified; if a request had a Route header field, P258L3 its CANCEL or ACK for a non-2xx response to the request need to P258L4 carry the same Route header field values. ACKs for 2xx responses P258L5 use the Route values learned from the Record-Route of the 2xx P258L6 responses. P258L7 P258L8 o RFC 2543 allowed multiple requests in a single UDP packet. This P258L9 usage has been removed. P258L10 P258L11 o Usage of absolute time in the Expires header field and parameter P258L12 has been removed. It caused interoperability problems in elements P258L13 that were not time synchronized, a common occurrence. Relative P258L14 times are used instead. P258L15 P258L16 o The branch parameter of the Via header field value is now P258L17 mandatory for all elements to use. It now plays the role of a P258L18 unique transaction identifier. This avoids the complex and bug- P258L19 laden transaction identification rules from RFC 2543. A magic P258L20 cookie is used in the parameter value to determine if the previous P258L21 hop has made the parameter globally unique, and comparison falls P258L22 back to the old rules when it is not present. Thus, P258L23 interoperability is assured. P258L24 P258L25 o In RFC 2543, closure of a TCP connection was made equivalent to a P258L26 CANCEL. This was nearly impossible to implement (and wrong) for P258L27 TCP connections between proxies. This has been eliminated, so P258L28 that there is no coupling between TCP connection state and SIP P258L29 processing. P258L30 P258L31 o RFC 2543 was silent on whether a UA could initiate a new P258L32 transaction to a peer while another was in progress. That is now P258L33 specified here. It is allowed for non-INVITE requests, disallowed P258L34 for INVITE. P258L35 P258L36 o PGP was removed. It was not sufficiently specified, and not P258L37 compatible with the more complete PGP MIME. It was replaced with P258L38 S/MIME. P258L39 P258L40 o Added the "sips" URI scheme for end-to-end TLS. This scheme is P258L41 not backwards compatible with RFC 2543. Existing elements that P258L42 receive a request with a SIPS URI scheme in the Request-URI will P258L43 likely reject the request. This is actually a feature; it ensures P258L44 that a call to a SIPS URI is only delivered if all path hops can P258L45 be secured. P258L46 P258L47 P258L48 P259L1 o Additional security features were added with TLS, and these are P259L2 described in a much larger and complete security considerations P259L3 section. P259L4 P259L5 o In RFC 2543, a proxy was not required to forward provisional P259L6 responses from 101 to 199 upstream. This was changed to MUST. P259L7 This is important, since many subsequent features depend on P259L8 delivery of all provisional responses from 101 to 199. P259L9 P259L10 o Little was said about the 503 response code in RFC 2543. It has P259L11 since found substantial use in indicating failure or overload P259L12 conditions in proxies. This requires somewhat special treatment. P259L13 Specifically, receipt of a 503 should trigger an attempt to P259L14 contact the next element in the result of a DNS SRV lookup. Also, P259L15 503 response is only forwarded upstream by a proxy under certain P259L16 conditions. P259L17 P259L18 o RFC 2543 defined, but did no sufficiently specify, a mechanism for P259L19 UA authentication of a server. That has been removed. Instead, P259L20 the mutual authentication procedures of RFC 2617 are allowed. P259L21 P259L22 o A UA cannot send a BYE for a call until it has received an ACK for P259L23 the initial INVITE. This was allowed in RFC 2543 but leads to a P259L24 potential race condition. P259L25 P259L26 o A UA or proxy cannot send CANCEL for a transaction until it gets a P259L27 provisional response for the request. This was allowed in RFC P259L28 2543 but leads to potential race conditions. P259L29 P259L30 o The action parameter in registrations has been deprecated. It was P259L31 insufficient for any useful services, and caused conflicts when P259L32 application processing was applied in proxies. P259L33 P259L34 o RFC 2543 had a number of special cases for multicast. For P259L35 example, certain responses were suppressed, timers were adjusted, P259L36 and so on. Multicast now plays a more limited role, and the P259L37 protocol operation is unaffected by usage of multicast as opposed P259L38 to unicast. The limitations as a result of that are documented. P259L39 P259L40 o Basic authentication has been removed entirely and its usage P259L41 forbidden. P259L42 P259L43 P259L44 P259L45 P259L46 P259L47 P259L48 P260L1 o Proxies no longer forward a 6xx immediately on receiving it. P260L2 Instead, they CANCEL pending branches immediately. This avoids a P260L3 potential race condition that would result in a UAC getting a 6xx P260L4 followed by a 2xx. In all cases except this race condition, the P260L5 result will be the same - the 6xx is forwarded upstream. P260L6 P260L7 o RFC 2543 did not address the problem of request merging. This P260L8 occurs when a request forks at a proxy and later rejoins at an P260L9 element. Handling of merging is done only at a UA, and procedures P260L10 are defined for rejecting all but the first request. P260L11 P260L12 28.2 Minor Functional Changes P260L13 P260L14 o Added the Alert-Info, Error-Info, and Call-Info header fields for P260L15 optional content presentation to users. P260L16 P260L17 o Added the Content-Language, Content-Disposition and MIME-Version P260L18 header fields. P260L19 P260L20 o Added a "glare handling" mechanism to deal with the case where P260L21 both parties send each other a re-INVITE simultaneously. It uses P260L22 the new 491 (Request Pending) error code. P260L23 P260L24 o Added the In-Reply-To and Reply-To header fields for supporting P260L25 the return of missed calls or messages at a later time. P260L26 P260L27 o Added TLS and SCTP as valid SIP transports. P260L28 P260L29 o There were a variety of mechanisms described for handling failures P260L30 at any time during a call; those are now generally unified. BYE P260L31 is sent to terminate. P260L32 P260L33 o RFC 2543 mandated retransmission of INVITE responses over TCP, but P260L34 noted it was really only needed for 2xx. That was an artifact of P260L35 insufficient protocol layering. With a more coherent transaction P260L36 layer defined here, that is no longer needed. Only 2xx responses P260L37 to INVITEs are retransmitted over TCP. P260L38 P260L39 o Client and server transaction machines are now driven based on P260L40 timeouts rather than retransmit counts. This allows the state P260L41 machines to be properly specified for TCP and UDP. P260L42 P260L43 o The Date header field is used in REGISTER responses to provide a P260L44 simple means for auto-configuration of dates in user agents. P260L45 P260L46 o Allowed a registrar to reject registrations with expirations that P260L47 are too short in duration. Defined the 423 response code and the P260L48 Min-Expires for this purpose. P261L1 29 Normative References P261L2 P261L3 [1] Handley, M. and V. Jacobson, "SDP: Session Description P261L4 Protocol", RFC 2327, April 1998. P261L5 P261L6 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement P261L7 Levels", BCP 14, RFC 2119, March 1997. P261L8 P261L9 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. P261L10 P261L11 [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", P261L12 RFC 3263, June 2002. P261L13 P261L14 [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource P261L15 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. P261L16 P261L17 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for P261L18 Transport Layer Security (TLS)", RFC 3268, June 2002. P261L19 P261L20 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC P261L21 2279, January 1998. P261L22 P261L23 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., P261L24 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- P261L25 HTTP/1.1", RFC 2616, June 1999. P261L26 P261L27 [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April P261L28 2000. P261L29 P261L30 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax P261L31 Specifications: ABNF", RFC 2234, November 1997. P261L32 P261L33 [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail P261L34 Extensions (MIME) Part Two: Media Types", RFC 2046, November P261L35 1996. P261L36 P261L37 [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness P261L38 Recommendations for Security", RFC 1750, December 1994. P261L39 P261L40 [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with P261L41 SDP", RFC 3264, June 2002. P261L42 P261L43 [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August P261L44 1980. P261L45 P261L46 [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC P261L47 761, January 1980. P261L48 P262L1 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, P262L2 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, P262L3 "Stream Control Transmission Protocol", RFC 2960, October 2000. P262L4 P262L5 [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., P262L6 Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: P262L7 Basic and Digest Access Authentication", RFC 2617, June 1999. P262L8 P262L9 [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation P262L10 Information in Internet Messages: The Content-Disposition Header P262L11 Field", RFC 2183, August 1997. P262L12 P262L13 [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., P262L14 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG P262L15 Objects", RFC 3204, December 2001. P262L16 P262L17 [20] Braden, R., "Requirements for Internet Hosts - Application and P262L18 Support", STD 3, RFC 1123, October 1989. P262L19 P262L20 [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", P262L21 BCP 18, RFC 2277, January 1998. P262L22 P262L23 [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security P262L24 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", P262L25 RFC 1847, October 1995. P262L26 P262L27 [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June P262L28 1999. P262L29 P262L30 [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, P262L31 June 1999. P262L32 P262L33 [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC P262L34 2246, January 1999. P262L35 P262L36 [26] Kent, S. and R. Atkinson, "Security Architecture for the P262L37 Internet Protocol", RFC 2401, November 1998. P262L38 P262L39 30 Informative References P262L40 P262L41 [27] R. Pandya, "Emerging mobile and personal communication systems," P262L42 IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. P262L43 P262L44 [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, P262L45 "RTP: A Transport Protocol for Real-Time Applications", RFC P262L46 1889, January 1996. P262L47 P262L48 P263L1 [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming P263L2 Protocol (RTSP)", RFC 2326, April 1998. P263L3 P263L4 [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and P263L5 J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November P263L6 2000. P263L7 P263L8 [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, P263L9 "SIP: Session Initiation Protocol", RFC 2543, March 1999. P263L10 P263L11 [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL P263L12 scheme", RFC 2368, July 1998. P263L13 P263L14 [33] E. M. Schooler, "A multicast user directory service for P263L15 synchronous rendezvous," Master's Thesis CS-TR-96-18, Department P263L16 of Computer Science, California Institute of Technology, P263L17 Pasadena, California, Aug. 1996. P263L18 P263L19 [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. P263L20 P263L21 [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April P263L22 1992. P263L23 P263L24 [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC P263L25 2426, September 1998. P263L26 P263L27 [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical P263L28 Specification", RFC 2849, June 2000. P263L29 P263L30 [38] Palme, J., "Common Internet Message Headers", RFC 2076, P263L31 February 1997. P263L32 P263L33 [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., P263L34 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: P263L35 Digest Access Authentication", RFC 2069, January 1997. P263L36 P263L37 [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, P263L38 D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call P263L39 Flow Examples", Work in Progress. P263L40 P263L41 [41] E. M. Schooler, "Case study: multimedia conference control in a P263L42 packet-switched teleconferencing system," Journal of P263L43 Internetworking: Research and Experience, Vol. 4, pp. 99--120, P263L44 June 1993. ISI reprint series ISI/RS-93-359. P263L45 P263L46 P263L47 P263L48 P264L1 [42] H. Schulzrinne, "Personal mobility for multimedia services in P264L2 the Internet," in European Workshop on Interactive Distributed P264L3 Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. P264L4 1996. P264L5 P264L6 [43] Floyd, S., "Congestion Control Principles", RFC 2914, September P264L7 2000. P264L8 P264L9 P264L10 P264L11 P264L12 P264L13 P264L14 P264L15 P264L16 P264L17 P264L18 P264L19 P264L20 P264L21 P264L22 P264L23 P264L24 P264L25 P264L26 P264L27 P264L28 P264L29 P264L30 P264L31 P264L32 P264L33 P264L34 P264L35 P264L36 P264L37 P264L38 P264L39 P264L40 P264L41 P264L42 P264L43 P264L44 P264L45 P264L46 P264L47 P264L48 P265L1 A Table of Timer Values P265L2 P265L3 Table 4 summarizes the meaning and defaults of the various timers P265L4 used by this specification. P265L5 P265L6 Timer Value Section Meaning P265L7 ---------------------------------------------------------------------- P265L8 T1 500ms default Section 17.1.1.1 RTT Estimate P265L9 T2 4s Section 17.1.2.2 The maximum retransmit P265L10 interval for non-INVITE P265L11 requests and INVITE P265L12 responses P265L13 T4 5s Section 17.1.2.2 Maximum duration a P265L14 message will P265L15 remain in the network P265L16 Timer A initially T1 Section 17.1.1.2 INVITE request retransmit P265L17 interval, for UDP only P265L18 Timer B 64*T1 Section 17.1.1.2 INVITE transaction P265L19 timeout timer P265L20 Timer C > 3min Section 16.6 proxy INVITE transaction P265L21 bullet 11 timeout P265L22 Timer D > 32s for UDP Section 17.1.1.2 Wait time for response P265L23 0s for TCP/SCTP retransmits P265L24 Timer E initially T1 Section 17.1.2.2 non-INVITE request P265L25 retransmit interval, P265L26 UDP only P265L27 Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction P265L28 timeout timer P265L29 Timer G initially T1 Section 17.2.1 INVITE response P265L30 retransmit interval P265L31 Timer H 64*T1 Section 17.2.1 Wait time for P265L32 ACK receipt P265L33 Timer I T4 for UDP Section 17.2.1 Wait time for P265L34 0s for TCP/SCTP ACK retransmits P265L35 Timer J 64*T1 for UDP Section 17.2.2 Wait time for P265L36 0s for TCP/SCTP non-INVITE request P265L37 retransmits P265L38 Timer K T4 for UDP Section 17.1.2.2 Wait time for P265L39 0s for TCP/SCTP response retransmits P265L40 P265L41 Table 4: Summary of timers P265L42 P265L43 P265L44 P265L45 P265L46 P265L47 P265L48 P266L1 Acknowledgments P266L2 P266L3 We wish to thank the members of the IETF MMUSIC and SIP WGs for their P266L4 comments and suggestions. Detailed comments were provided by Ofir P266L5 Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, P266L6 Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John P266L7 Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, P266L8 Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders P266L9 Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William P266L10 Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe P266L11 J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick P266L12 Workman. P266L13 P266L14 Brian Rosen provided the compiled BNF. P266L15 P266L16 Jean Mahoney provided technical writing assistance. P266L17 P266L18 This work is based, inter alia, on [41,42]. P266L19 P266L20 P266L21 P266L22 P266L23 P266L24 P266L25 P266L26 P266L27 P266L28 P266L29 P266L30 P266L31 P266L32 P266L33 P266L34 P266L35 P266L36 P266L37 P266L38 P266L39 P266L40 P266L41 P266L42 P266L43 P266L44 P266L45 P266L46 P266L47 P266L48 P267L1 Authors' Addresses P267L2 P267L3 Authors addresses are listed alphabetically for the editors, the P267L4 writers, and then the original authors of RFC 2543. All listed P267L5 authors actively contributed large amounts of text to this document. P267L6 P267L7 Jonathan Rosenberg P267L8 dynamicsoft P267L9 72 Eagle Rock Ave P267L10 East Hanover, NJ 07936 P267L11 USA P267L12 P267L13 EMail: jdrosen@dynamicsoft.com P267L14 P267L15 P267L16 Henning Schulzrinne P267L17 Dept. of Computer Science P267L18 Columbia University P267L19 1214 Amsterdam Avenue P267L20 New York, NY 10027 P267L21 USA P267L22 P267L23 EMail: schulzrinne@cs.columbia.edu P267L24 P267L25 P267L26 Gonzalo Camarillo P267L27 Ericsson P267L28 Advanced Signalling Research Lab. P267L29 FIN-02420 Jorvas P267L30 Finland P267L31 P267L32 EMail: Gonzalo.Camarillo@ericsson.com P267L33 P267L34 P267L35 Alan Johnston P267L36 WorldCom P267L37 100 South 4th Street P267L38 St. Louis, MO 63102 P267L39 USA P267L40 P267L41 EMail: alan.johnston@wcom.com P267L42 P267L43 P267L44 P267L45 P267L46 P267L47 P267L48 P268L1 Jon Peterson P268L2 NeuStar, Inc P268L3 1800 Sutter Street, Suite 570 P268L4 Concord, CA 94520 P268L5 USA P268L6 P268L7 EMail: jon.peterson@neustar.com P268L8 P268L9 P268L10 Robert Sparks P268L11 dynamicsoft, Inc. P268L12 5100 Tennyson Parkway P268L13 Suite 1200 P268L14 Plano, Texas 75024 P268L15 USA P268L16 P268L17 EMail: rsparks@dynamicsoft.com P268L18 P268L19 P268L20 Mark Handley P268L21 International Computer Science Institute P268L22 1947 Center St, Suite 600 P268L23 Berkeley, CA 94704 P268L24 USA P268L25 P268L26 EMail: mjh@icir.org P268L27 P268L28 P268L29 Eve Schooler P268L30 AT&T Labs-Research P268L31 75 Willow Road P268L32 Menlo Park, CA 94025 P268L33 USA P268L34 P268L35 EMail: schooler@research.att.com P268L36 P268L37 P268L38 P268L39 P268L40 P268L41 P268L42 P268L43 P268L44 P268L45 P268L46 P268L47 P268L48 P269L1 Full Copyright Statement P269L2 P269L3 Copyright (C) The Internet Society (2002). All Rights Reserved. P269L4 P269L5 This document and translations of it may be copied and furnished to P269L6 others, and derivative works that comment on or otherwise explain it P269L7 or assist in its implementation may be prepared, copied, published P269L8 and distributed, in whole or in part, without restriction of any P269L9 kind, provided that the above copyright notice and this paragraph are P269L10 included on all such copies and derivative works. However, this P269L11 document itself may not be modified in any way, such as by removing P269L12 the copyright notice or references to the Internet Society or other P269L13 Internet organizations, except as needed for the purpose of P269L14 developing Internet standards in which case the procedures for P269L15 copyrights defined in the Internet Standards process must be P269L16 followed, or as required to translate it into languages other than P269L17 English. P269L18 P269L19 The limited permissions granted above are perpetual and will not be P269L20 revoked by the Internet Society or its successors or assigns. P269L21 P269L22 This document and the information contained herein is provided on an P269L23 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING P269L24 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING P269L25 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION P269L26 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF P269L27 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. P269L28 P269L29 Acknowledgement P269L30 P269L31 Funding for the RFC Editor function is currently provided by the P269L32 Internet Society. P269L33 P269L34 P269L35 P269L36 P269L37 P269L38 P269L39 P269L40 P269L41 P269L42 P269L43 P269L44 P269L45 P269L46 P269L47 P269L48