idnits 2.17.1 draft-ietf-sipcore-info-events-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2976], [RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 545 has weird spacing: '...3xx-6xx o...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 2, 2009) is 5258 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1064, but not defined == Unused Reference: 'RFC3080' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1396, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: 'RFC4028' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 1433, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-20 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE E. Burger 3 Internet-Draft NeuStar, Inc. 4 Obsoletes: RFC 2976 H. Kaplan 5 (if approved) Acme Packet 6 Expires: June 5, 2010 C. Holmberg 7 Ericsson 8 December 2, 2009 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-03 13 Abstract 15 This document defines a new method, INFO, for the Session Initiation 16 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 17 document obsoletes [RFC2976]. For backward compatibility the 18 document also specifies a "legacy" mode of usage of the INFO method 19 that is compatible with the usage previously defined in [RFC2976], 20 referred to as "legacy INFO Usage" in this document. 22 Conventions Used in this Document 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 The terminology in this document conforms to the Internet Security 28 Glossary [RFC4949]. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on June 5, 2010. 53 Copyright Notice 55 Copyright (c) 2009 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 76 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 77 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 78 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 79 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 80 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 81 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 82 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 84 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 86 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 87 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 88 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 89 4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 90 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 91 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 92 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 93 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 95 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 96 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 97 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 99 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 100 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 101 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 102 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 103 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 104 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 108 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 109 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 110 9.3. Co-existence with Info Package based INFO usage . . . . . 19 111 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 112 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 114 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 115 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 116 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 117 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 118 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 119 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 120 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 121 10.10. Info Package Security Considerations . . . . . . . . . . 22 122 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 123 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 124 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 125 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 126 11.2. Registration of the Info-Package Header Field . . . . . . 24 127 11.3. Registration of the Recv-Info Header Field . . . . . . . 24 128 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 129 11.5. Registration of the Info-Package Content-Disposition . . 25 130 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 131 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 132 12.1. Indication for which Info Packages UAs are willing to 133 receive INFO requests . . . . . . . . . . . . . . . . . . 25 134 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 135 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 136 12.2. INFO request associated with Info Package . . . . . . . . 27 137 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 138 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 139 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 140 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 141 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 142 14.2. Informative References . . . . . . . . . . . . . . . . . 31 143 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 144 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 145 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 146 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 147 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 148 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 149 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 150 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 151 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 154 1. Introduction 156 This document defines a new method, INFO, for the Session Initiation 157 Protocol (SIP) [RFC3261]. 159 The purpose of the INFO message is to carry application level 160 information between endpoints, using the SIP dialog signaling path. 161 Note that the INFO method is not used to update characteristics of a 162 SIP dialog or session, but to allow the applications which use the 163 SIP session to exchange information (which might update the state of 164 those applications). 166 Use of the INFO method does not constitute a separate dialog usage. 167 INFO messages are always part of, and share the fate of, an invite 168 dialog usage [RFC5057]. INFO messages cannot be sent as part of 169 other dialog usages, or outside an existing dialog. 171 This document also defines an Info Package mechanism. An Info 172 Package specification defines the content and semantics of the 173 information carried in an INFO message associated with the Info 174 Package. The Info Package mechanism also provides a way for UAs to 175 indicate for which Info Packages they are willing to receive INFO 176 requests, and which Info Package a specific INFO request is 177 associated with. 179 A UA uses the Recv-Info header field, on a per-dialog basis, to 180 indicate for which Info Packages it is willing to receive INFO 181 requests. A UA can indicate an initial set of Info Packages during 182 dialog establishment and can indicate a new set during the lifetime 183 of the invite dialog usage. 185 NOTE: A UA can use an empty Recv-Info header field (a header field 186 without a value) to indicate that it is not willing to receive INFO 187 requests for any Info-Package, but to inform other UAs that it still 188 supports the Info Package mechanism. 190 When a UA sends an INFO request, it uses the Info-Package header 191 field to indicate which Info Package is associated with the request. 192 One particular INFO request can only be associated with a single Info 193 Package. 195 This document obsoletes [RFC2976]. However, for backward 196 compatibility it specifies a "legacy" mode of usage of the INFO 197 method that is compatible with the usage previously defined in 198 [RFC2976], referred to as "legacy INFO Usage" in this document. 200 2. Applicability 202 This document defines a new method, INFO, for the Session Initiation 203 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 204 document obsoletes [RFC2976]. For backward compatibility the 205 document also specifies a "legacy" mode of usage of the INFO method 206 that is compatible with the usage previously defined in [RFC2976], 207 referred to as "legacy INFO Usage" in this document. 209 3. The INFO Method 211 3.1. General 213 The INFO method provides a mechanism for transporting application 214 level information that can further enhance a SIP application. Annex 215 A gives more details on the types of applications for which the use 216 of INFO is appropriate. 218 This section describes how a UA handles INFO requests and responses, 219 as well as the message bodies included in INFO messages. 221 3.2. INFO Request 223 3.2.1. INFO Request Sender 225 An INFO request can be associated with an Info Package (see X), or 226 associated with a legacy INFO usage (see Y). 228 The construction of the INFO request is the same as any other request 229 within an existing invite dialog usage. A UA can send INFO requests 230 both within early and confirmed dialogs. 232 When a UA sends an INFO request associated with an Info Package, it 233 MUST include an Info-Package header field that indicates which Info 234 Package is associated with the request. A specific INFO request can 235 be used only for a single Info Package. 237 When a UA sends an INFO request associated with an legacy INFO usage 238 there is no Info Package associated with the request, and the UA MUST 239 NOT include an Info-Package header field in the request. 241 The INFO request MUST NOT contain a Recv-Info header field. A UA can 242 only indicate a set of Info Packages for which it is willing to 243 receive INFO requests by using the SIP methods (and their responses) 244 listed in Section 4. 246 A UA MUST NOT use the INFO method outside an invite dialog usage. 248 UAs indicate, per-dialog basis, for which Info Packages they are 249 willing to receive INFO requests. The set of Info Packages cannot 250 automatically be used within other dialogs. 252 If a UA receives a 469 (Bad INFO Package) response to an INFO 253 request, based on [RFC5057] the response represents a Transaction 254 Only failure, and the UA MUST NOT terminate the invite dialog usage. 256 Due to the possibility of forking, the UA whichs sends the initial 257 INVITE reqest MUST be prepared to receive INFO requests from multiple 258 remote UAs during the early dialog phase. In addition, the UA MUST 259 be prepared to receive different Recv-Info header field values from 260 different remote UAs. 262 NOTE: If the UAS (receiver of the initial INVITE request) sends an 263 INFO request just after it has sent the response which creates the 264 dialog, the UAS needs to be prepared that the INFO request can reach 265 the UAC before the dialog creating response, and might therefore be 266 rejected by the UAC. In addition, an INFO request might be rejected 267 due to a race condition, if a UA sends the INFO request at the same 268 time as the remote UA sends a new set of Info Packages for which it 269 is willing to receive INFO requests. 271 3.2.2. INFO Request Receiver 273 If a UA receives an INFO request associated with an Info Package that 274 the UA has not indicated willingness to receive, the UA MUST send a 275 469 (Bad INFO Package) response (see Section 11.6). In the 276 terminology of Multiple Dialog Usages [RFC5057], this represents a 277 Transaction Only failure, and does not terminate the invite dialog 278 usage. 280 If a UA receives an INFO request associated with an Info Package, and 281 the message body part associated with the Info Package contains a 282 message body MIME type that the UA support, but which usage is not 283 defined for the specific Info Package, it is RECOMMENDED that the UA 284 sends a 415 (Unsupported Media Type) response. 286 The UA MAY send other error responses, such as Request Failure (4xx), 287 Server Failure (5xx) and Global Failure (6xx), in accordance with the 288 error handling procedures in [RFC3261]. 290 Otherwise, if the INFO request is syntactically correct and well 291 structured, the UA MUST send a 200 (OK) response. 293 NOTE: If the application needs to reject the information which it 294 received in an INFO request, that needs to be done on the application 295 level. Ie the application needs to trigger a new INFO request, which 296 contains information that the previously received application data 297 was not accepted. Individual Info Package specifications need to 298 describe the details for such procedures. 300 3.3. INFO Message Body 302 3.3.1. INFO Request Message Body 304 The purpose of the INFO request is to carry application level 305 information between SIP UAs. The application information data is 306 carried in the payload of the message body of the INFO request. 308 NOTE: An INFO request assocated with an Info Package can also include 309 information associated with the Info Package using Info-Package 310 header field parameters. 312 If an INFO request associated with an Info Package contains a message 313 body part, the body part is identified by a Content-Disposition 314 header field 'Info-Package' value. The body part can contain a 315 single MIME type, or it can be a multipart [RFC5621] which contains 316 other body parts associated with the Info Package. 318 UAs MUST conform to [RFC5621] to support multipart body parts. 320 NOTE: Some SIP functions that are orthogonal to INFO can insert body 321 parts unrelated to the Info Package. 323 When a UA supports a specific Info-Package, the UA also support all 324 message body MIME types associated with that Info-Package. However, 325 in accordance with [RFC3261] the UA still indicates the supported 326 MIME types using the Accept header. 328 3.3.2. INFO Response Message Body 330 A UA MUST NOT include a message body associated with an Info Package 331 in an INFO response. Message bodies associated with Info Packages 332 MUST only be sent in INFO requests. 334 A UA MAY include a message body which is not associated with an Info 335 Package in an INFO response. 337 3.4. Order of Delivery 339 The Info Package mechanism does not define a delivery order 340 mechanism. Info Packages can rely on the CSeq header field to detect 341 if an INFO request is received out of order. 343 If specific applications need additional mechanisms for order of 344 delivery, those mechanisms, and related procedures, are specified as 345 part of the associated Info Package, and possible sequence numbers 346 etc must be defined as application data. 348 4. Info Packages 350 4.1. General 352 An Info Package specification defines the content and semantics of 353 the information carried in an INFO message associated with an Info 354 Package. The Info Package mechanism provides a way for UAs to 355 indicate for which Info Packages they are willing to receive INFO 356 requests, and which Info Package a specific INFO request is 357 associated with. 359 4.2. User Agent Behavior 361 4.2.1. General 363 This section describes how a UA handles Info Packages, how a UA uses 364 the Recv-Info header field, and how the UA acts in re-INVITE rollback 365 situations. 367 4.2.2. UA Procedures 369 A UA which supports the Info Package mechanism MUST indicate, using 370 the Revc-Info header field, the set of Info Packages for which it is 371 willing to receive INFO requests. A UA can list multiple Info 372 Packages in a single Recv-Info header field, and the UA can use 373 multiple Recv-Info header fields. A UA can an empty Recv-Info header 374 field, ie a header field without any header field values. 376 A UA provides its set of Info Packages for which it is willing to 377 receive INFO requests during the dialog establishment. A UA can 378 update the set of Info Packages during the invite dialog usage. 380 If a UA is not willing to receive INFO requests for any Info 381 Packages, during dialog establishment or later during the invite 382 dialog usage, the UA MUST indicate this by including an empty Recv- 383 Info header field. This informs other UAs that the UA still supports 384 the Info Package mechanism. 386 Example: If a UA has previously indicated Info Packages 'foo' and 387 'bar' in a Recv-Info header field, and the UA during the lifetime of 388 the invite dialog usage wants to indicate that it does not want to 389 receive INFO requests for any Info Packages anymore, the UA sends a 390 message with an empty Recv-Info header field. 392 Once a UA has sent a set of Info Packages, the set is valid until the 393 UA sends a new set, or an empty Recv-Info header field. 395 Once a UA has indicated that it is willing to receive INFO requests 396 for a specific Info Package, and a dialog has been established, the 397 UA MUST be prepared to receive INFO request associated with that Info 398 Package until the UA indicates that it is no longer willing to 399 receive INFO requests associated with that Info Package. 401 For a specific dialog usage, a UA MUST NOT send an INFO request 402 associated with an Info Package until it has received an indication 403 that the remote UA is willing to receive INFO requests for that Info 404 Package, or after the UA has received an indication that the remote 405 UA is no longer willing to receive INFO requests associated with that 406 Info Package. 408 NOTE: When a UA sends a message which contains a Recv-Info header 409 field with a new set of Info Packages for which the UA is willing to 410 receive INFO requests the remote UA might, before it receives the 411 message, send an INFO request based on the old set of Info Packages. 412 In this case the receiver of the INFO requests rejects, and sends a 413 469 (Bad INFO Package) response to, the INFO request. 415 If a UA indicates multiple Info Packages, which provide similar 416 functionality, it is not possible to indicate a priority order of the 417 Info Packages, or that that the UA wishes to only receive INFO 418 request for one of the Info Packages. It is up to the application 419 logic associated with the Info Packages, and specific Info Package 420 specifications, to describe application behavior in such cases. 422 For backward compatibility purpose, even if a UA indicates support of 423 the Info Package mechanism, it is still allowed to enable legacy INFO 424 usages Appendix A. In addition, if a UA indicates support of the 425 INFO method using the Allow header field [RFC3261], it does not 426 implicitly indicate support of the Info Package mechanism. A UA MUST 427 use the Recv-Info header field in order to indicate that it supports 428 the Info Package mechanism. Likewise, even if a UA uses the Recv- 429 Info header field to indicate that it supports the Info Package 430 mechanism, in addition the UA still indicates support of the INFO 431 method using the Allow header. 433 This document does not define a SIP option tag [RFC3261] for the Info 434 Package mechanism. However, an Info Package specification can define 435 an option-tag associated with the specific Info Package, as described 436 in Section 10.6. 438 4.2.3. Recv-Info header field rules 440 The text below defines rules on when a UA is required to include a 441 Recv-Info header field in SIP messages. Section 6.1 lists the SIP 442 methods, for which a UA can insert a Recv-Info header field in 443 requests and responses. 445 - The sender of an initial INVITE request MUST include a Recv-Info 446 header field in the initial INVITE request, even if the sender is not 447 willing to receive INFO requests asscoiated with any Info Package. 449 - The receiver of a request which contains a Recv-Info header field 450 MUST include a Recv-Info header field in a reliable 18x/2xx response 451 to the request, even if the request contains an empty Recv-Info 452 header field, and even if the header field value of the receiver has 453 not changed since the previous time it sent a Recv-Info header field. 455 - A UA MUST NOT include a Recv-Info header field in a response if the 456 associated request did not contain a Recv-Info header field. 458 NOTE: Different from the rules for generating SDP answers, the 459 receiver of a request which contains a set of Info Packages is not 460 restricted to generate its own set of Info Packages as a subset of 461 the Info Package set received in the Info Package header field of the 462 request. 464 NOTE: Similar to SDP answers, the receiver can include the same Recv- 465 Info header field value in multiple responses (18x/2xx) for the same 466 INVITE/re-INVITE transaction, but the receiver is not allowed to 467 include a Recv-Info header field value which is different from a 468 value that the receiver has already included in a response for the 469 same transaction. 471 4.2.4. Info Package fallback rules 473 If the receiver of a request which contains a Recv-Info header field 474 rejects the request, both the sender and receiver of the request MUST 475 roll back to the set of Info Packages which was used before the 476 request was sent. This also applies to the case where the receiver 477 of an INVITE/re-INVITE request has included a Recv-Info header field 478 in a provisional response, but later rejects the request. 480 NOTE: The dialog state rollback rules for Info Packages might differ 481 from the rules for other types of dialog state information (SDP, 482 target, etc). 484 4.3. REGISTER Processing 486 This document allows a UA to insert a Recv-Info header field in a 487 REGISTER request. However, a UA SHALL NOT include a header value for 488 a specific Info Package unless the specific Info Package 489 specification describes how the header field value shall be 490 interpreted and used by the registrar, e.g. in order to determine 491 request targets. 493 Rather than using the Recv-Info header field in order to determine 494 request targets, it is recommended to use more appropriate 495 mechanisms, e.g. based on [RFC3840]. However, this document does not 496 define a feature tag for the Info Package mechanism, or a mechanism 497 to define feature tags for specific Info Packages. 499 4.4. OPTIONS Processing 501 If a UA sends an OPTIONS request, or a response, the UA SHALL include 502 Recv-Info header field in the message, and list the Info Packages 503 that it supports to receive. 505 NOTE: As for any other capability and extension, for a specific 506 dialog UAs need to indicate which Info Packages they are willing to 507 receive within that dialog. 509 5. Formal INFO Method Definition 511 5.1. INFO Method 513 This document describes one new SIP method: INFO. This document 514 replaces the definition and registrations found in [RFC2976]. 516 This table expands on Tables 2 and 3 in [RFC3261]. 518 Header Where INFO 519 ------ ----- ---- 520 Accept R o 521 Accept 415 o 522 Accept-Encoding R o 523 Accept-Encoding 2xx o 524 Accept-Encoding 415 c 525 Accept-Language R o 526 Accept-Language 2xx o 527 Accept-Language 415 o 528 Accept-Resource-Priority 2xx,417 o 529 Alert-Info - 530 Allow R o 531 Allow 405 m 532 Allow r o 533 Authentication-Info 2xx o 534 Authorization R o 535 Call-ID c m 536 Call-Info o 537 Contact - 538 Content-Disposition o 539 Content-Encoding o 540 Content-Language o 541 Content-Length o 542 Content-Type * 543 CSeq c m 544 Date o 545 Error-Info 3xx-6xx o 546 Expires - 547 From c m 548 Geolocation R o 549 Geolocation-Error r o 550 Max-Breadth R - 551 Max-Forwards R o 552 MIME-Version o 553 Min-Expires - 554 Organization - 555 Priority R - 556 Privacy o 557 Proxy-Authenticate 401 m 558 Proxy-Authenticate 407 o 559 Proxy-Authorization R o 560 Proxy-Require R o 561 Reason R o 562 Record-Route R o 563 Record-Route 2xx,18x o 564 Referred-By R o 565 Request-Disposition R o 566 Require o 567 Resource-Priority o 568 Retry-After R - 569 Retry-After 404,413,480,486 o 570 Retry-After 500,503 o 571 Retry-After 600,603 o 572 Route R o 573 Security-Client R o 574 Security-Server 421,494 o 575 Security-Verify R o 576 Server r o 577 Subject R o 578 Supported R o 579 Supported 2xx o 580 Timestamp o 581 To c m (w/ Tag) 582 Unsupported 420 o 583 User-Agent o 584 Via m 585 Warning r o 586 WWW-Authenticate 401 m 587 WWW-Authenticate 407 o 589 Figure 1: Table 1: Summary of Header Fields 591 6. INFO Header Fields 593 6.1. General 595 This table expands on tables 2 and 3 in [RFC3261]. 597 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR 598 ------------------------------------------------------------------------ 599 Info-Package R - - - - - - - m* - - - - - 600 Info-Package 469 - - - - - - - m* - - - - - 601 Recv-Info R - - - m m o o - - o - - - 602 Recv-Info 2xx - - - o** m - o***- - o***- - - 603 Recv-Info 1xx - - - o** - - - - - - - - - 604 Recv-Info r - - - o o - o - - o - - - 606 The support and usage of the Info-Package and Recv-Info header fields 607 is not applicalbe to UAs that only support legacy INFO usages. * Not 608 applicalbe to INFO requests and responses associated with legacy INFO 609 usages. ** Mandatory in at least one reliable 18x/2xx response, if 610 sent, to the INVITE request, if the associated INVITE request 611 contained a Recv-Info header field. *** Mandatory if the associated 612 request contained a Recv-Info header field. 614 Table 2: INFO-related Header Fields 616 6.2. Info-Package header field 618 This document adds Info-Package to the definition of the element 619 "message-header" in the SIP message grammar [RFC3261]. Section 3 620 describes the Info-Package header field usage. 622 For the purposes of matching Info Package types indicated in Recv- 623 Info with those in the Info-Package header field value, one compares 624 the Info-package-name portion of the Info-package-type portion of the 625 Info-Package header field octet-by-octet with that of the Recv-Info 626 header field value. That is, the Info Package name is case 627 sensitive. Info-package-param is not part of the comparison-checking 628 algorithm. 630 This document does not define values for Info-Package types. 631 Individual Info Package specifications define these values. 633 6.3. Recv-Info header field 635 This document adds Recv-Info to the definition of the element 636 "message-header" in the SIP message grammar [RFC3261]. Section 4 637 describes the Recv-Info header field usage. 639 7. Info Package Considerations 641 7.1. General 643 This section covers considerations to take into account when deciding 644 whether the usage of an Info Package is appropriate for transporting 645 of application information for a specific use-case. 647 7.2. Appropriateness of Info Package Usage 649 When designing an Info Package, for application level information 650 exchange, it is important to consider: is signaling, using INFO 651 requests, within a SIP dialog, an appropriate mechanism for the use- 652 case? Is it because it is the most reasonable and appropriate 653 choice, or merely because "it's easy"? Choosing an inappropriate 654 mechanism for a specific use-case can cause negative effects in SIP 655 networks where the mechanism is used. 657 7.3. INFO Request Rate and Volume 659 There is no default throttling mechanism for INFO requests. Apart 660 from the SIP session establishment, the number of SIP messages 661 exchanged during the lifetime a normal SIP session is rather small. 663 Some applications, like sending of DTMF tones, can generate a burst 664 of up to 20 messages per second. Other applications, like constant 665 GPS location updates, could generate a high rate of INFO requests 666 during the lifetime of the invite dialog usage. 668 Furthermore, SIP messages tend to be relatively small, on the order 669 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 670 exchange of bulk data beyond these limits, especially if the headers 671 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 672 such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user 673 plane data transport mechanisms. 675 7.4. Alternative Mechanisms 677 7.4.1. Alternative SIP signaling plane mechanisms 679 7.4.1.1. General 681 This subsection describes some alternative mechanisms for 682 transporting application information on the SIP signaling plane, 683 using SIP messages. 685 7.4.1.2. SUBSCRIBE/NOTIFY 687 An alternative for application level interaction is to use 688 subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and 689 NOTIFY methods. Using that mechanism, a UA requests state 690 information, such as key pad presses from a device to an application 691 server or key map images from an application server to a device. 693 Event Packages [RFC3265] perform the role of disambiguating the 694 context of a message for subscription-based events. The Info Package 695 mechanism provides similar functionality for application information 696 exchange using invite dialog usages [RFC5057]. 698 While an INFO request is always part of, and shares the fate of, an 699 existing invite dialog usage, a SUBSCRIBE request creates a separate 700 dialog usage [RFC5057], and is normally sent outside an existing 701 dialog usage. 703 The subscription-based mechanism can be used by SIP entities to 704 receive state information about SIP dialogs and sessions, without 705 requiring the entities to be part of the route set of those dialogs 706 and sessions. 708 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 709 and B2BUAs, the resource impact caused by the subscription dialogs 710 needs to be considered. The number of subscription dialogs per user 711 also needs to be considered. 713 As for any other SIP signaling plane based mechanism for transporting 714 application information, the SUBSCRIBE/NOTIFY messages can put a 715 significant burden on intermediate SIP entities which are part of the 716 dialog route set, but do not have any interest in the application 717 information transported between the end users. 719 7.4.1.3. MESSAGE 721 The MESSAGE method [RFC3428] defines one-time instant message 722 exchange, typically for sending MIME contents for rendering to the 723 ser. 725 7.4.2. Media Plane Mechanisms 727 7.4.2.1. General 729 In SIP, media plane channels associated with SIP dialogs are 730 established using SIP signaling, but the data exchanged on the media 731 plane channel does not traverse SIP signaling intermediates, so if 732 there will be a lot of information exchanged, and there is no need 733 for the SIP signaling intermediates routing to examine the 734 information, it is recommended to use a media plane mechanism, rather 735 than a SIP signaling based. 737 A low latency requirement for the exchange of information is one 738 strong indicator for using a media channel. Exchanging information 739 through the SIP routing network can introduce hundreds of 740 milliseconds of latency. 742 7.4.2.2. MRCPv2 744 One mechanism for media plane exchange of application data is MRCPv2 745 [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented 746 channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is 747 established. 749 7.4.2.3. MRSP 751 MSRP [RFC4975] defines session-based instant messaging as well as 752 bulk file transfer and other such large-volume uses. 754 7.4.3. Non-SIP related mechanisms 756 Another alternative is to use a totally externally signaled channel, 757 such as HTTP [RFC2616]. In this model, the UA knows about a 758 rendezvous point to direct HTTP requests to for the transfer of 759 information. Examples include encoding of a prompt to retrieve in 760 the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target 761 in a VoiceXML [W3C.REC-voicexml21-20070619] script. 763 8. Syntax 764 8.1. General 766 This section describes the syntax extensions required for the INFO 767 method. The previous sections describe the semantics. Note the 768 formal syntax definitions described in this document use the ABNF 769 format used in [RFC3261] and contain references to elements defined 770 therein. 772 8.2. ABNF 774 INFOm = %x49.4E.46.4F ; INFO in caps 775 extension-method = INFOm / token 777 Info-Package = "Info-Package" HCOLON Info-package-type 778 Recv-Info = "Recv-Info" HCOLON [Info-package-list] 779 Info-package-list = Info-package-type *( COMMA Info-package-type ) 780 Info-package-type = Info-package-name *( SEMI Info-package-param) 781 Info-package-name = token 782 Info-package-param = generic-param 784 9. Legacy INFO Usage 786 9.1. General 788 A number of applications, standardized and proprietary, make use of 789 the INFO method as it was previously defined in [RFC2976], referred 790 to as "legacy INFO usage". 792 For backward compatibility purpose, this document does not deprecate 793 such usages, and does not mandate users to define Info Packages for 794 such usages. However, any new usage of INFO SHALL use the Info 795 Package mechanism defined in this specification. 797 9.2. Problems 799 While legacy INFO usage has been widely adopted for specific 800 application use cases, [RFC2976] did not define a mechanism for SIP 801 UAs to indicate for which types of applications and contexts they 802 support the INFO method. In addition, [RFC2976] did not provide a 803 mechanism to explicitly indicate the type of application and context 804 for which a specific INFO message is associated. 806 Example: If the Content-Type is "image/jpeg", the MIME-attached 807 content is a JPEG image. Still, there are many useful ways a UA can 808 render an image. The image could be a caller-id picture, a contact 809 icon, a photo for sharing, and so on. The sender does not know which 810 image to send to the receiver if the receiver supports an image 811 content type. Likewise, the receiver does not know the context of an 812 image the client is sending if the receiver supports receiving more 813 than one image content type. 815 Since legacy INFO usages do not have associated Info Packages, it is 816 not possible to use the Recv-Info and Info-Package header fields with 817 legacy INFO usages. That is, a UA cannot use the Recv-Info header 818 field to indicate for which legacy INFO usages it is willing to 819 receive INFO requests, and a UA cannot use the Info-Package header 820 field to indicate for which legacy INFO usage an INFO request is 821 associated with. 823 Due to the problems described above, legacy INFO usages often require 824 static configuration about for what type of applications and contexts 825 UAs support the INFO method, and the way they handle application 826 information transported in INFO messages. That has caused 827 interoperability problems in the industry. Therefore, a need for a 828 well defined and documented description of what the information sent 829 in the INFO is used for has been identified. This situation is 830 analogous to the context issue in Internet Mail [RFC3458]. 832 9.3. Co-existence with Info Package based INFO usage 834 As described in Section 3, an INFO request associated with an Info 835 Package always contains an Info-Package header field. A UA MUST NOT 836 insert an Info-Package header field in a legacy INFO request. 838 UAs are allowed to enable both legacy INFO usages and Info Package 839 usages as part of the same invite dialog usage. 841 See Appendix A for examples of existing legacy INFO usages. 843 10. Info Package Requirements 845 10.1. General 847 This section provides guidance on how to define an Info Package, and 848 what information needs to exist in an Info Package specification. 850 If, for an Info Package, there is a need to extend or modify the 851 behavior described in this document, that behaviour MUST be described 852 in the Info Package specification. It is bad practice for Info 853 Package specifications to repeat procedures defined in this document, 854 unless needed for clarification or emphasis purpose. 856 Info Package specifications MUST NOT weaken any behavior designated 857 with "SHOULD" or "MUST" in this specification. However, Info 858 Packages specifications MAY strengthen "SHOULD", "MAY", or 859 "RECOMMENDED" requirements to "MUST" strength if applications 860 associated with the Info Package requires it. 862 Info Package specifications MUST address the issues defined in the 863 following subsections, or document why an issue is not applicable for 864 the specific Info Package. 866 Section 7.4 describes alternative mechanisms, which should be 867 considered as part of the process for solving a specific use-case, 868 when for transporting application information. 870 10.2. Overal Description 872 The Info Package specification MUST contain an overlap description of 873 the Info Package: what type of information are carried in INFO 874 requests associated with the Info Package, and for what type of 875 applications and functionalities UAs can use the Info Package. 877 If the Info Package is defined for a specific application, the Info 878 Package specification MUST state which application UAs can use the 879 Info Package with. 881 10.3. Applicability 883 The Info Package specification MUST describe why the Info Package 884 mechanism, rather than some other mechanism, has been chosen for the 885 specific use-case to transfer application information between SIP 886 endpoints. Common reasons can be a requirement for SIP Proxies or 887 back-to-back user agents (B2BUAs) to see the transported application 888 information (which would not be the case if the information was 889 transported on a media path), or that it is not seen feasible to 890 establish separate dialogs (subscription) in order to transport the 891 information. 893 Annex A provides more information, and describes alternative 894 mechanisms which one should consider for solving a specific use-case. 896 10.4. Info Package Name 898 The Info Package specification MUST define an Info Package name, 899 which UAs use as a header field value (e.g. "infoX") to be identify 900 the Info Package in the Recv-Info and Info-Package header fields. 901 The header field value MUST conform to the ABNF defined in 902 Section 8.2. 904 The Info Package mechanism does not support package versioning. 905 Specific Info Package message body payloads can contain version 906 information, which is handled by the applications associated with the 907 Info Package. However, such feature is outside the scope of the 908 generic Info Package mechanism. 910 NOTE: Even if an Info Package name contains version numbering (e.g. 911 foo_v2), the Info Package mechanism does not distinguish a version 912 number from the rest of the Info Package name. 914 The IANA registration requirements for Info Package names are defined 915 in Section 10.5. 917 10.5. Info Package Parameters 919 The Info Package specification MAY define Info Package parameters, 920 which can be used in the Recv-Info or Info-Package header fields, 921 together with the header field value which indicates the Info Package 922 name (see Section 10.4. 924 The Info Package specification MUST define the syntax and semantics 925 of the defined parameters. In addition, the specification MUST 926 define whether a specific parameter is only applicable to the Recv- 927 Info header field, the Info-Package header field, or both. 929 By default, an Info Package parameter is only applicable for the Info 930 Package for which the parameter has been explicitly defined. 932 NOTE: Info Package parameters defined for specific Info Packages can 933 share the name with parameters defined for other Info Packages, but 934 the parameter semantics are specific to the Info Package for which 935 they are defined. 937 10.6. SIP Option Tags 939 The Info Package specification MAY define SIP option tags, which can 940 be used as described in [RFC3261]. 942 The registration requirements for option tags are defined in 943 [I-D.peterson-rai-rfc3427bis]. 945 10.7. INFO Message Body Parts 947 The Info Package specification MUST define which message body part 948 MIME types are associated with the Info Package. The specification 949 MUST either define those body parts, which include the syntax, 950 semantics and MIME type of the each body part, or refer to other 951 documents which define the body parts. 953 If multiple message body part MIME types are associated with an Info 954 Package, the Info Package specification MUST define whether UAs need 955 to use multipart body parts in order to include multiple body parts 956 in a single INFO request. 958 10.8. Info Package Usage Restrictions 960 If there are restrictions on how UAs can use an Info Package, the 961 Info Package specification MUST document such restrictions. 963 There can be restrictions related to whether UAs are allowed to send 964 overlapping (outstanding) INFO requests associated with the Info 965 Package, or whether the UA has to wait for the response for a 966 previous INFO request associated with the same Info Package. 968 There can also be restrictions related to whether UAs need to support 969 and use other SIP extensions and capabilities when they use the Info 970 Package, and if there are restrictions related to how UAs can use the 971 Info-Package together with other Info Packages. 973 As the SIP stack might not be aware of Info Package specific 974 restrictions, it cannot be assumed that overlapping requests would be 975 rejected. As defined in Section 3.2.2, UAs will normally send a 200 976 (OK) response to an INFO request. The application logic associated 977 with the Info Package needs to handle situations where UAs do not 978 follow restrictions associated with the Info Package. 980 10.9. Rate of INFO Requests 982 If there is a maximum or minumum rate at which UAs can send INFO 983 requests associated with the Info Package within a dialog, the Info 984 Package specification MUST document the rate values. 986 If the rates can vary, the Info Package specification MAY define Info 987 Package parameters that UAs can use to indicate or negotiate the 988 rates. Alternatively the rate information can be part of the 989 application data information associated with the Info Package. 991 10.10. Info Package Security Considerations 993 If the application information carried in INFO requests associated 994 with the Info Package requires certain level of security, the Info 995 Package specification MUST describe the mechanisms that UAs need to 996 use in order to provide the required security. 998 If the Info Package specification does not require any additional 999 security, other than what the underlying SIP protocol provides, it 1000 MUST be stated in the Info Package specification. 1002 NOTE: In some cases, it may not be sufficient to mandate TLS in order 1003 to secure the Info Package payload, since intermediaries will have 1004 access to the payload, and beyond the first hop, there is no way to 1005 assure subsequent hops will not forwards the payload in clear text. 1006 The best way to ensure secure transport at the application level is 1007 to have the security at the application level. One way of achieving 1008 this is to use end-to-end security techniques such as S/MIME 1009 [RFC3851]. 1011 10.11. Implementation Details 1013 It is strongly RECOMMENDED that the Info Package specification 1014 defines the procedure how implementors shall implement and use the 1015 Info Package, or refer to other locations where implementors can find 1016 that information. 1018 NOTE: Sometimes Info Package designer might choose to not reveal the 1019 details of an Info Package. However, in order to allow multiple 1020 implementations to support the Info Package, Info Package designers 1021 are stronly encouraged to provide the implementation details. 1023 10.12. Examples 1025 It is RECOMMENDED that the Info Package specification provides 1026 demonstrative message flow diagrams, paired with complete messages 1027 and message descriptions. 1029 Note that example flows are by definition informative, and do not 1030 replace normative text. 1032 11. IANA Considerations 1034 11.1. Update to Registration of SIP INFO Method 1036 Please update the existing registration in the SIP Methods and 1037 Response Codes registry under the SIP Parameters registry that 1038 states: 1040 Method: INFO 1041 Reference: [RFC2976] 1043 to: 1045 Method: INFO 1046 Reference: [RFCXXXX] 1048 11.2. Registration of the Info-Package Header Field 1050 Please add the following new SIP header field in the Header Fields 1051 subregistry under the SIP Parameters registry. 1053 Header Name: Info-Package 1054 Compact Form: (none) 1055 Reference: [RFCXXXX] 1057 11.3. Registration of the Recv-Info Header Field 1059 Please add the following new SIP header field in the Header Fields 1060 subregistry under the SIP Parameters registry. 1062 Header Name: Recv-Info 1063 Compact Form: (none) 1064 Reference: [RFCXXXX] 1066 11.4. Creation of the Info Packages Registry 1068 Please create a subregistry in the SIP Parameters registry for Info 1069 Packages. 1071 Based on [RFC5226], IANA assigns an expert in order to review an Info 1072 Package which is to be registered. The Info Package specification is 1073 provided to the reviewer, who ensures that the Info Package is 1074 described in a proper way. 1076 The reviewer does not consider the applicability of the Info Package 1077 for the usage for which it is defined. 1079 The following data elements populate the Info Package Registry. 1080 o Info Package Name: The Info Package Name is a case insensitive 1081 token. In addition, IANA shall not register multiple Info Package 1082 names that have identical case-insensitive values. 1083 o Reference: A reference to a specification which describes the Info 1084 Package. 1086 The initial population of this table shall be: 1088 Name Reference 1090 11.5. Registration of the Info-Package Content-Disposition 1092 Please add the following new header field value to the Content- 1093 Disposition registry. 1094 Name: info-package 1095 Description: the body contains information associated with an Info Package 1096 Reference: RFCXXXX 1098 11.6. SIP Response Code 469 Registration 1100 Please register the following new response code in the Session 1101 Initiation Protocol Parameters - Response Codes registry. 1102 Response Code: 469 1103 Default Reason Phrase: Bad INFO Package 1104 Reference: RFCXXXX 1106 12. Examples 1108 12.1. Indication for which Info Packages UAs are willing to receive 1109 INFO requests 1111 12.1.1. Initial INVITE request 1113 The UAC sends an initial INVITE request, where the UAC indicates that 1114 it is willing to receive INFO requests for Info Packages P and R. 1116 INVITE sip:bob@example.com SIP/2.0 1117 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1118 Max-Forwards: 70 1119 To: Bob 1120 From: Alice ;tag=1928301774 1121 Call-ID: a84b4c76e66710@pc33.example.com 1122 CSeq: 314159 INVITE 1123 Recv-Info: P, R 1124 Contact: 1125 Content-Type: application/sdp 1126 Content-Length: ... 1128 ... 1130 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1131 indicates that it is willing to receive INFO requests for Info 1132 Packages R and T. 1134 SIP/2.0 200 OK 1135 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 1136 To: Bob ;tag=a6c85cf 1137 From: Alice ;tag=1928301774 1138 Call-ID: a84b4c76e66710@pc33.example.com 1139 CSeq: 314159 INVITE 1140 Contact: 1141 Recv-Info: R, T 1142 Content-Type: application/sdp 1143 Content-Length: ... 1145 ... 1147 The UAC sends an ACK request. 1149 ACK sip:bob@pc33.example.com SIP/2.0 1150 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 1151 Max-Forwards: 70 1152 To: Bob ;tag=a6c85cf 1153 From: Alice ;tag=1928301774 1154 Call-ID: a84b4c76e66710@pc33.example.com 1155 CSeq: 314159 ACK 1156 Content-Length: 0 1158 12.1.2. Target refresh 1160 The UAC sends an UPDATE request within the invite dialog usage, where 1161 the UAC indicates (using an empty Recv-Info header field) that it is 1162 not willing to receive INFO requests for any Info Packages. 1164 UPDATE sip:bob@pc33.example.com SIP/2.0 1165 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1166 Max-Forwards: 70 1167 To: Bob ;tag=a6c85cf 1168 From: Alice ;tag=1928301774 1169 Call-ID: a84b4c76e66710@pc33.example.com 1170 CSeq: 314163 UPDATE 1171 Recv-Info: 1172 Contact: 1173 Content-Type: application/sdp 1174 Content-Length: ... 1176 ... 1178 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1179 indicates that it is willing to receive INFO requests for Info 1180 Packages R. 1182 SIP/2.0 200 OK 1183 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 1184 To: Bob ;tag=a6c85cf 1185 From: Alice ;tag=1928301774 1186 Call-ID: a84b4c76e66710@pc33.example.com 1187 CSeq: 314163 INVITE 1188 Contact: 1189 Recv-Info: R, T 1190 Content-Type: application/sdp 1191 Content-Length: ... 1193 ... 1195 12.2. INFO request associated with Info Package 1197 12.2.1. Single payload 1199 The UA sends an INFO request associated with Info Package foo. 1201 INFO sip:alice@pc33.example.com SIP/2.0 1202 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1203 To: Bob ;tag=a6c85cf 1204 From: Alice ;tag=1928301774 1205 Call-Id: a84b4c76e66710@pc33.example.com 1206 CSeq: 314333 INFO 1207 Info-Package: foo 1208 Content-type: application/foo 1209 Content-Disposition: Info-Package 1210 Content-length: 24 1212 I am a foo message type 1214 12.2.2. Multipart INFO 1216 12.2.2.1. Non-Info Package body part 1218 SIP extensions can sometimes add body part payloads into an INFO 1219 request, independent of the Info Package. In this case, the Info 1220 Package payload gets put into a Multipart MIME body, with a Content- 1221 Disposition header field that indicates which body part is associated 1222 with the Info Package. 1224 INFO sip:alice@pc33.example.com SIP/2.0 1225 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1226 To: Alice ;tag=1234567 1227 From: Bob ;tag=abcdefg 1228 Call-Id: a84b4c76e66710@pc33.example.com 1229 CSeq: 314400 INFO 1230 Info-Package: foo 1231 Content-Type: multipart/mixed;boundary="theboundary" 1232 Content-Length: ... 1234 --theboundary 1235 Content-Type: application/mumble 1236 ... 1238 1240 --theboundary 1241 Content-Type: application/foo-x 1242 Content-Disposition: Info-Package 1243 Content-length: 59 1245 I am a foo-x message type, and I belong to Info Package foo 1246 --theboundary-- 1248 12.2.2.2. Info Package with multiple body parts inside multipart body 1249 part 1251 Multiple body part payloads can be associated with a single Info 1252 Package. In this case, the body parts are put into a Multipart MIME 1253 body, with a Content-Disposition header field that indicates which 1254 body part is associated with the Info Package. 1256 INFO sip:alice@pc33.example.com SIP/2.0 1257 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1258 To: Alice ;tag=1234567 1259 From: Bob ;tag=abcdefg 1260 Call-Id: a84b4c76e66710@pc33.example.com 1261 CSeq: 314423 INFO 1262 Info-Package: foo 1263 Content-Type: multipart/mixed;boundary="theboundary" 1264 Content-Disposition: Info-Package 1265 Content-Length: ... 1267 --theboundary 1268 Content-Type: application/foo-x 1269 Content-length: 59 1271 I am a foo-x message type, and I belong to Info Package foo 1273 1275 --theboundary 1276 Content-Type: application/foo-y 1277 Content-length: 59 1279 I am a foo-y message type, and I belong to Info Package foo 1280 --theboundary-- 1282 12.2.2.3. Info Package with single body part inside multipart body part 1284 The body part payload associated with the Info Package can have a 1285 Content-Disposition header field value other than "Info-Package". In 1286 this case, the body part is put into a Multipart MIME body, with a 1287 Content-Disposition header field that indicates which body part is 1288 associated with the Info Package. 1290 INFO sip:alice@pc33.example.com SIP/2.0 1291 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1292 To: Alice ;tag=1234567 1293 From: Bob ;tag=abcdefg 1294 Call-Id: a84b4c76e66710@pc33.example.com 1295 CSeq: 314423 INFO 1296 Info-Package: foo 1297 Content-Type: multipart/mixed;boundary="theboundary" 1298 Content-Disposition: Info-Package 1299 Content-Length: ... 1301 --theboundary 1302 Content-Type: application/foo-x 1303 Content-Disposition: icon 1304 Content-length: 59 1306 I am a foo-x message type, and I belong to Info Package foo 1307 --theboundary-- 1309 13. Security Considerations 1311 By eliminating multiple usages of INFO messages without adequate 1312 community review and by eliminating the possibility for rogue SIP UAs 1313 from confusing another UA by purposely sending unrelated INFO 1314 requests, we expect this document's clarification of the use of INFO 1315 to improve the security of the Internet. Whilst rogue UAs can still 1316 send unrelated INFO requests, this mechanism provides mechanisms for 1317 which the UAS and other security devices can filter for approved Info 1318 Packages. 1320 If the content of the Info Package payload is private, UAs will need 1321 to use end-to-end encryption, such as S/MIME, to prevent access to 1322 the content. This is particularly important as transport of INFO is 1323 likely not to be end-to-end, but through SIP proxies and back-to-back 1324 user agents (B2BUA's), which the user may not trust. 1326 The INFO request transports application level information. One 1327 implication of this is INFO messages may require a higher level of 1328 protection than the underlying SIP dialog signaling. In particular, 1329 if one does not protect the SIP signaling from eavesdropping or 1330 authentication and repudiation attacks, for example by using TLS 1331 transport, then the INFO request and its contents will be vulnerable, 1332 as well. Even with SIP/TLS, any SIP hop along the path from UAC to 1333 UAS can view, modify, or intercept INFO requests, as they can with 1334 any SIP request. This means some applications may require end-to-end 1335 encryption of the INFO payload, beyond, for example, hop-by-hop 1336 protection of the SIP signaling itself. Since the application 1337 dictates the level of security required, individual Info Packages 1338 have to enumerate these requirements. In any event, the Info Package 1339 mechanism described by this document provides the tools for such 1340 secure, end-to-end transport of application data. 1342 One interesting property of Info Package use is one can reuse the 1343 same digest-challenge mechanism used for INVITE based authentication 1344 for the INFO request. For example, one could use a quality-of- 1345 protection (qop) value of authentication with integrity (auth-int), 1346 to challenge the request and its body, and prevent intermediate 1347 devices from modifying the body. However this assumes the device 1348 which knows the credentials in order to perform the INVITE challenge 1349 is still in the path for the INFO, or that the far-end UAS knows such 1350 credentials. 1352 14. References 1354 14.1. Normative References 1356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, March 1997. 1359 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1360 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1361 May 2008. 1363 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1364 A., Peterson, J., Sparks, R., Handley, M., and E. 1365 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1366 June 2002. 1368 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1369 Initiation Protocol (SIP)", RFC 5621, September 2009. 1371 14.2. Informative References 1373 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1374 RFC 793, September 1981. 1376 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1377 October 2000. 1379 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1380 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1381 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1383 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1384 August 1980. 1386 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1387 RFC 4949, August 2007. 1389 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1390 RFC 3080, March 2001. 1392 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1393 Extensions (S/MIME) Version 3.1 Message Specification", 1394 RFC 3851, July 2004. 1396 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1397 Camarillo, "Best Current Practices for Third Party Call 1398 Control (3pcc) in the Session Initiation Protocol (SIP)", 1399 BCP 85, RFC 3725, April 2004. 1401 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1402 "Indicating User Agent Capabilities in the Session 1403 Initiation Protocol (SIP)", RFC 3840, August 2004. 1405 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1406 Preferences for the Session Initiation Protocol (SIP)", 1407 RFC 3841, August 2004. 1409 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1410 for Telephones (SIP-T): Context and Architectures", 1411 BCP 63, RFC 3372, September 2002. 1413 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1414 Event Notification", RFC 3265, June 2002. 1416 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1417 Context for Internet Mail", RFC 3458, January 2003. 1419 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1420 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1421 for Instant Messaging", RFC 3428, December 2002. 1423 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1424 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1426 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1427 the Session Description Protocol (SDP)", RFC 4145, 1428 September 2005. 1430 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1431 Media Services with SIP", RFC 4240, December 2005. 1433 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1434 (SIP) Event Package for Key Press Stimulus (KPML)", 1435 RFC 4730, November 2006. 1437 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1438 RFC 4960, September 2007. 1440 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1441 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1443 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1444 Control Markup Language (MSCML) and Protocol", RFC 5022, 1445 September 2007. 1447 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1448 Initiation Protocol", RFC 5057, November 2007. 1450 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1451 Media Control", RFC 5168, March 2008. 1453 [I-D.peterson-rai-rfc3427bis] 1454 Peterson, J., Jennings, C., and R. Sparks, "Change Process 1455 for the Session Initiation Protocol (SIP) and the Real- 1456 time Applications and Infrastructure Area", 1457 draft-peterson-rai-rfc3427bis-04 (work in progress), 1458 October 2009. 1460 [W3C.REC-voicexml21-20070619] 1461 Lee, A., Porter, B., Oshry, M., Burnett, D., Rehor, K., 1462 Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, 1463 E., Carter, J., and S. McGlashan, "Voice Extensible Markup 1464 Language (VoiceXML) 2.1", World Wide Web Consortium 1465 Recommendation REC-voicexml21-20070619, June 2007, 1466 . 1468 [I-D.ietf-speechsc-mrcpv2] 1469 Shanmugham, S. and D. Burnett, "Media Resource Control 1470 Protocol Version 2 (MRCPv2)", 1471 draft-ietf-speechsc-mrcpv2-20 (work in progress), 1472 August 2009. 1474 [I-D.saleem-msml] 1475 Saleem, A. and G. Sharratt, "Media Server Markup Language 1476 (MSML)", draft-saleem-msml-09 (work in progress), 1477 July 2009. 1479 [Ecma-355] 1480 "Standard ECMA-355 Corporate Telecommunication Networks - 1481 Tunnelling of QSIG over SIP", ECMA http:// 1482 www.ecma-international.org/publications/standards/ 1483 Ecma-355.htm, June 2008. 1485 Appendix A. Legacy INFO Usage 1487 A.1. General 1489 This section provides examples of existing legacy INFO usages. The 1490 section is not meant to be a comprehensive catalog of legacy INFO 1491 usages, but it should give the reader a flavor for current legacy 1492 INFO usages. 1494 A.2. ISUP 1496 [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. 1497 ITU-T and 3GPP have specified similar procedures. 1499 A.3. QSIG 1501 [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. 1503 A.4. MSCML 1505 [RFC5022] specifies how INFO is used as a transport mechanism by the 1506 MSCML protocol. MSCML uses an option-tag in the Require header field 1507 to ensure that the receiver understands the INFO content. 1509 A.5. MSML 1511 [I-D.saleem-msml] specifies how INFO us used as a transport mechanism 1512 by the MSML protocol. 1514 A.6. Video Fast Update 1516 Companies have been using INFO messages in order to request fast 1517 video update. Currently a standardized mechanism, based on RTCP, has 1518 been specified in [RFC5168] 1520 Appendix B. Acknowledgements 1522 The work on this document was influenced by the "INFO Considered 1523 Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and 1524 by the "Packaging and Negotiation of INFO Methods for the Session 1525 Initiation Protocol" draft (15 January 2003) written by Dean Willis. 1527 The following individuals have been involved in the work, and have 1528 provided input and feedback on this document: 1529 Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben 1530 Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris 1531 Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean 1532 Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon 1533 Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James 1534 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1535 Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 1536 Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael 1537 Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, 1538 Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore 1539 Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve 1540 Langstaff, Sumit Garg and Xavier Marjoum. 1542 John Elwell and Francois Audet helped with QSIG references. In 1543 addition, Francois Audet provided text for the revised abstract. 1544 Keith Drage provided comments and helped immensely with Figure 1. 1546 Brett Tate, John Elwell, Keith Drage and Robert Sparks provided 1547 valuable feedback during the WGLC process, in order to prepare this 1548 document for publication. 1550 Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided 1551 valuable input in order to sort out the message body part usage for 1552 Info Packages. 1554 Appendix C. Change Log 1556 [RFC EDITOR NOTE: Please remove this section when publishing] 1558 Changes from draft-ietf-sipcore-info-events-02 1559 o Further changes based on WGLC comments 1560 o Allignment with "specification" and "definition" terminology 1561 o Location switch of sections 3 and 4 1562 o Corrections in header table 1563 o IANA Info Package registration input changed 1564 o Clarifiaction regarding which SIP messages can contain the Recv- 1565 Info header field 1566 o Recv-Info 'nil' value removed 1567 o Rules on usage of Recv-Info header clarified 1568 o Recv-Info fallback rules added 1569 o Additional examples added 1571 Changes from draft-ietf-sipcore-info-events-01 1572 o Further changes based on WGLC comments 1573 o Appending A moved into the main part of the document 1574 o Section name changed from "Modifications to SIP Change Process" to 1575 "Security Considerations" 1576 o "Syntax" section moved further up in the document 1577 o Clarification on usage of Info Package related message body parts, 1578 and the usage of the Content-Disposition header field with those 1579 body parts 1580 o Removed REFER and NOTIFY from the INFO Headers table 1581 o Clarified usage of the Recv-Info header field in the REGISTER and 1582 OPTIONS requests 1583 o Major re-write of the Introduction section 1584 o Text about legacy INFO and subscription-based events moved from 1585 the Introduction to the main part of the document 1586 o Wording about receiving Info-Packages has been replaced with 1587 wording about receiving INFO requests for Info-Packages 1588 o The text about the usage of message body, and body parts, 1589 associated with Info Packages, has been clarified 1591 Changes from draft-ietf-sip-info-events-04 1592 o Major re-write of the document, due to problems to implement WGLC 1593 comments into the existing text structure 1594 o Wording allignment 1595 o Clarification or roles 1597 Changes from draft-ietf-sip-info-events-03 1598 o Clarified Abstract language 1599 o All SIP dialogs are now refered to as sessions 1600 o Clarified the image example in the Introduction 1601 o Clarified the relationship (none) between SIP Event Packages and 1602 SIP Info Packages 1603 o Really, really clarified the protocol is NOT a negotiation but an 1604 advertisement 1605 o Split Section 3 into UAS and UAC behavior 1606 o Moved the example in section 3 into its own sub-section, and used 1607 full SIP header fields 1608 o Clarified forking behavior 1609 o Clarified language around when to send a body 1610 o Added 469 error response, instead of reusing 489 1611 o Clarified overlapping INFO method handling 1612 o Fixed table 1 to follow 3261, not 2543 1613 o Added REFER to the INFO Headers table 1614 o replaced token-nodot with token for Info-Package header field 1615 values 1616 o Clarified end-to-end security considerations 1617 o Info Package parameters are semi-colon delimited, not dot 1618 delimited 1620 Changes from -02 1621 o Applicability statement explicitly says we're backwards compatible 1622 o Explicitly state we work like UPDATE (both early and confirmed 1623 dialogs) 1624 o Agreed text for IANA Considerations package registry 1626 Changes from -01 1627 o One and only one Info Package per INFO 1628 o Removed Send-Info header field, greatly simplifying negotiation 1629 o Multiple body part identification through Content-Disposition: 1630 Info-Package 1631 o Note that forking INVITEs may result in multiple INFOs coming back 1632 to INVITE originator 1633 o Describe how a UAS can enforce strict adherence to this document 1634 o Remove CANCEL INFO faux pas 1635 o Better explained overlapping INFO issues and resolutions 1636 o Token names are now really case sensitive 1637 o Moved Info Package Considerations to an Appendix 1638 o Introduced stronger, yet more open, IANA registration process 1639 o Took a few more paragraphs from INFO Litmus to cover all bases. 1640 o Added RFC 5168 to legacy usages 1642 Changes from -00 1643 o Corrected ABNF. 1644 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1645 messages was already here. 1646 o Negotiation is not Offer/Answer, it is Offer/Offer. 1647 o Created the explicit "nil" Info Package to indicate no info 1648 package. 1649 o Fixed CANCEL impacting future transactions. 1650 o Added Registrar behavior. 1651 o Added OPTIONS processing. 1652 o Clarified overlapping INFO method processing. 1653 o Described multiple INFO bodies in a single INFO method. 1654 o Took out Info-Package as a header field for responses to the INFO 1655 method. 1656 o Expanded on risks of using INFO and filled-in more on the 1657 alternatives 1658 o Moved definitions of INFO into the body of the text and cleaned up 1659 IANA Considerations section 1660 o Added legacy usages descriptions 1662 Authors' Addresses 1664 Eric W. Burger 1665 NeuStar, Inc. 1666 46000 Center Oak Plaza 1667 Sterling, VA 20166-6579 1668 USA 1670 Email: eburger@standardstrack.com 1671 URI: http://www.standardstrack.com 1673 Hadriel Kaplan 1674 Acme Packet 1675 71 Third Ave. 1676 Burlington, MA 01803 1677 USA 1679 Phone: 1680 Fax: 1681 Email: hkaplan@acmepacket.com 1682 URI: 1684 Christer Holmberg 1685 Ericsson 1686 Hirsalantie 11 1687 Jorvas, 02420 1688 Finland 1690 Phone: 1691 Fax: 1692 Email: christer.holmberg@ericsson.com 1693 URI: