idnits 2.17.1 draft-ietf-sipcore-info-events-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 534 has weird spacing: '...3xx-6xx o...' == Line 586 has weird spacing: '...d where prox...' -- The document date (May 19, 2010) is 5089 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 1103, but not defined ** 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 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-20 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE C. Holmberg 3 Internet-Draft Ericsson 4 Obsoletes: 2976 (if approved) E. Burger 5 Intended status: Standards Track NeuStar, Inc. 6 Expires: November 20, 2010 H. Kaplan 7 Acme Packet 8 May 19, 2010 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-08 13 Abstract 15 This document defines a method, INFO, for the Session Initiation 16 Protocol (SIP), and an Info Package mechanism. The document 17 obsoletes RFC 2976. For backward compatibility the document also 18 specifies a "legacy" mode of usage of the INFO method that is 19 compatible with the usage previously defined in RFC 2976, referred to 20 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]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 20, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 5 68 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 6 69 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 7 71 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 7 72 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 7 73 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 74 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 8 77 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 8 79 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 10 80 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 10 81 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 11 82 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11 83 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11 84 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 85 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 87 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14 88 7. Info Package Considerations . . . . . . . . . . . . . . . . . 14 89 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14 91 7.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15 92 7.3.1. Alternative SIP signaling plane mechanisms . . . . . . 15 93 7.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16 94 7.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 95 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 99 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 101 9.3. Co-existence with Info Package based INFO usage . . . . . 19 102 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 103 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 105 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 106 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 107 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 108 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 109 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 110 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 111 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 112 10.10. Info Package Security Considerations . . . . . . . . . . 22 113 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 114 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 115 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 116 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 117 11.2. Registration of the Info-Package header field . . . . . . 24 118 11.3. Registration of the Recv-Info header field . . . . . . . 24 119 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 120 11.5. Registration of the Info-Package Content-Disposition . . 25 121 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 122 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 123 12.1. Indication for which Info Packages UAs are willing to 124 receive INFO requests . . . . . . . . . . . . . . . . . . 25 125 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 126 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 127 12.2. INFO request associated with Info Package . . . . . . . . 27 128 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 129 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 130 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 131 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 132 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 133 14.2. Informative References . . . . . . . . . . . . . . . . . 31 134 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33 135 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 33 136 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 137 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 138 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 139 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 140 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 141 A.7. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 34 142 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 143 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 146 1. Introduction 148 This document defines a method, INFO, for the Session Initiation 149 Protocol (SIP) [RFC3261]. 151 The purpose of the INFO message is to carry application level 152 information between endpoints, using the SIP dialog signaling path. 153 Note that the INFO method is not used to update characteristics of a 154 SIP dialog or session, but to allow the applications which use the 155 SIP session to exchange information (which might update the state of 156 those applications). 158 Use of the INFO method does not constitute a separate dialog usage. 159 INFO messages are always part of, and share the fate of, an invite 160 dialog usage [RFC5057]. INFO messages cannot be sent as part of 161 other dialog usages, or outside an existing dialog. 163 This document also defines an Info Package mechanism. An Info 164 Package specification defines the content and semantics of the 165 information carried in an INFO message associated with the Info 166 Package. The Info Package mechanism also provides a way for UAs to 167 indicate for which Info Packages they are willing to receive INFO 168 requests, and which Info Package a specific INFO request is 169 associated with. 171 A UA uses the Recv-Info header field, on a per-dialog basis, to 172 indicate for which Info Packages it is willing to receive INFO 173 requests. A UA can indicate an initial set of Info Packages during 174 dialog establishment and can indicate a new set during the lifetime 175 of the invite dialog usage. 177 NOTE: A UA can use an empty Recv-Info header field (a header field 178 without a value) to indicate that it is not willing to receive INFO 179 requests for any Info-Package, but to inform other UAs that it still 180 supports the Info Package mechanism. 182 When a UA sends an INFO request, it uses the Info-Package header 183 field to indicate which Info Package is associated with the request. 184 One particular INFO request can only be associated with a single Info 185 Package. 187 2. Applicability 189 This document defines a method, INFO, for the Session Initiation 190 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 191 document obsoletes [RFC2976]. For backward compatibility the 192 document also specifies a "legacy" mode of usage of the INFO method 193 that is compatible with the usage previously defined in [RFC2976], 194 referred to as "legacy INFO Usage" in this document. 196 3. The INFO Method 198 3.1. General 200 The INFO method provides a mechanism for transporting application 201 level information that can further enhance a SIP application. Annex 202 A gives more details on the types of applications for which the use 203 of INFO is appropriate. 205 This section describes how a UA handles INFO requests and responses, 206 as well as the message bodies included in INFO messages. 208 3.2. INFO Request 210 3.2.1. INFO Request Sender 212 An INFO request can be associated with an Info Package (see 213 Section 4), or associated with a legacy INFO usage (see Section 9). 215 The construction of the INFO request is the same as any other non- 216 target refresh request within an existing invite dialog usage as 217 described in Section 12.2 of [RFC3261]. 219 When a UA sends an INFO request associated with an Info Package, it 220 MUST include an Info-Package header field that indicates which Info 221 Package is associated with the request. A specific INFO request can 222 be used only for a single Info Package. 224 When a UA sends an INFO request associated with an legacy INFO usage 225 there is no Info Package associated with the request, and the UA MUST 226 NOT include an Info-Package header field in the request. 228 The INFO request MUST NOT contain a Recv-Info header field. A UA can 229 only indicate a set of Info Packages for which it is willing to 230 receive INFO requests by using the SIP methods (and their responses) 231 listed in Section 4. 233 A UA MUST NOT send an INFO request outside an invite dialog usage and 234 MUST NOT send an INFO request for an Info Package inside an invite 235 dialog usage if the remote UA has not indicated willingness to 236 receive that Info-Package within that dialog. 238 If a UA receives a 469 (Bad Info Package) response to an INFO 239 request, based on [RFC5057] the response represents a Transaction 240 Only failure, and the UA MUST NOT terminate the invite dialog usage. 242 Due to the possibility of forking, the UA which sends the initial 243 INVITE request MUST be prepared to receive INFO requests from 244 multiple remote UAs during the early dialog phase. In addition, the 245 UA MUST be prepared to receive different Recv-Info header field 246 values from different remote UAs. 248 NOTE: If the UAS (receiver of the initial INVITE request) sends an 249 INFO request just after it has sent the response which creates the 250 dialog, the UAS needs to be prepared that the INFO request can reach 251 the UAC before the dialog creating response, and might therefore be 252 rejected by the UAC. In addition, an INFO request might be rejected 253 due to a race condition, if a UA sends the INFO request at the same 254 time as the remote UA sends a new set of Info Packages for which it 255 is willing to receive INFO requests. 257 3.2.2. INFO Request Receiver 259 If a UA receives an INFO request associated with an Info Package that 260 the UA has not indicated willingness to receive, the UA MUST send a 261 469 (Bad Info Package) response (see Section 11.6), which contains a 262 Recv-Info header field with Info Packages for which the UA is willing 263 to receive INFO requests. The UA MUST NOT use the response to update 264 the set of Info Packages, but simply to indicate the current set. In 265 the terminology of Multiple Dialog Usages [RFC5057], this represents 266 a Transaction Only failure, and does not terminate the invite dialog 267 usage. 269 If a UA receives an INFO request associated with an Info Package and 270 the message body part with Content-Disposition 'Info-Package' (see 271 Section 3.3.1) has a Multipurpose Internet Mail Extensions (MIME) 272 type that the UA supports but not in the context of that Info 273 Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media 274 Type) response. 276 The UA MAY send other error responses, such as Request Failure (4xx), 277 Server Failure (5xx) and Global Failure (6xx), in accordance with the 278 error handling procedures in [RFC3261]. 280 Otherwise, if the INFO request is syntactically correct and well 281 structured, the UA MUST send a 200 (OK) response. 283 NOTE: If the application needs to reject the information which it 284 received in an INFO request, that needs to be done on the application 285 level. I.e. the application needs to trigger a new INFO request, 286 which contains information that the previously received application 287 data was not accepted. Individual Info Package specifications need 288 to describe the details for such procedures. 290 3.2.3. SIP Proxies 292 Proxies need no additional behavior beyond that described in 293 [RFC3261] to support INFO. 295 3.3. INFO Message Body 297 3.3.1. INFO Request Message Body 299 The purpose of the INFO request is to carry application level 300 information between SIP UAs. The application information data is 301 carried in the payload of the message body of the INFO request. 303 NOTE: An INFO request associated with an Info Package can also 304 include information associated with the Info Package using Info- 305 Package header field parameters. 307 If an INFO request associated with an Info Package contains a message 308 body part, the body part is identified by a Content-Disposition 309 header field 'Info-Package' value. The body part can contain a 310 single MIME type, or it can be a multipart [RFC5621] which contains 311 other body parts associated with the Info Package. 313 UAs MUST support multipart body parts in accordance with [RFC5621]. 315 NOTE: An INFO request can also contain other body parts that are 316 meaningful within the context of an invite dialog usage but are not 317 specifically associated with the INFO method and the application 318 concerned. 320 When a UA supports a specific Info-Package, the UA MUST also support 321 message body MIME types in accordance with that Info-Package. 322 However, in accordance with [RFC3261] the UA still indicates the 323 supported MIME types using the Accept header. 325 3.3.2. INFO Response Message Body 327 A UA MUST NOT include a message body associated with an Info Package 328 in an INFO response. Message bodies associated with Info Packages 329 MUST only be sent in INFO requests. 331 A UA MAY include a message body which is not associated with an Info 332 Package in an INFO response. 334 3.4. Order of Delivery 336 The Info Package mechanism does not define a delivery order 337 mechanism. Info Packages can rely on the CSeq header field to detect 338 if an INFO request is received out of order. 340 If specific applications need additional mechanisms for order of 341 delivery, those mechanisms, and related procedures, are specified as 342 part of the associated Info Package (e.g. the use of sequence numbers 343 within the application data). 345 4. Info Packages 347 4.1. General 349 An Info Package specification defines the content and semantics of 350 the information carried in an INFO message associated with an Info 351 Package. The Info Package mechanism provides a way for UAs to 352 indicate for which Info Packages they are willing to receive INFO 353 requests, and which Info Package a specific INFO request is 354 associated with. 356 4.2. User Agent Behavior 358 4.2.1. General 360 This section describes how a UA handles Info Packages, how a UA uses 361 the Recv-Info header field, and how the UA acts in re-INVITE rollback 362 situations. 364 4.2.2. UA Procedures 366 A UA which supports the Info Package mechanism MUST indicate, using 367 the Recv-Info header field, the set of Info Packages for which it is 368 willing to receive INFO requests for a specific session. A UA can 369 list multiple Info Packages in a single Recv-Info header field, and 370 the UA can use multiple Recv-Info header fields. A UA can use an 371 empty Recv-Info header field, i.e. a header field without any header 372 field values. 374 A UA provides its set of Info Packages for which it is willing to 375 receive INFO requests during the dialog establishment. A UA can 376 update the set of Info Packages during the invite dialog usage. 378 If a UA is not willing to receive INFO requests for any Info 379 Packages, during dialog establishment or later during the invite 380 dialog usage, the UA MUST indicate this by including an empty Recv- 381 Info header field. This informs other UAs that the UA still supports 382 the Info Package mechanism. 384 Example: If a UA has previously indicated Info Packages 'foo' and 385 'bar' in a Recv-Info header field, and the UA during the lifetime of 386 the invite dialog usage wants to indicate that it does not want to 387 receive INFO requests for any Info Packages anymore, the UA sends a 388 message with an empty Recv-Info header field. 390 Once a UA has sent a message with a Recv-Info header field containing 391 a set of Info Packages, the set is valid until the UA sends a new 392 Recv-Info header field containing a new, or empty, set of Info 393 Packages. 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 to indicate that the UA wishes to only receive INFO 418 requests 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 Section 9. In addition, if a UA indicates support of the INFO 425 method using the Allow header field [RFC3261], it does not implicitly 426 indicate support of the Info Package mechanism. A UA MUST use the 427 Recv-Info header field in order to indicate that it supports the Info 428 Package mechanism. Likewise, even if a UA uses the Recv-Info header 429 field to indicate that it supports the Info Package mechanism, in 430 addition the UA still indicates support of the INFO method using the 431 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 associated 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 [RFC3264], 459 the receiver of a request which contains a set of Info Packages is 460 not restricted to generate its own set of Info Packages as a subset 461 of the Info Package set received in the Info Package header field of 462 the request. 464 Similar to SDP answers, the receiver can include the same Recv-Info 465 header field value in multiple responses (18x/2xx) for the same 466 INVITE/re-INVITE transaction, but the receiver MUST use the same 467 Recv-Info header field value (if included) in all responses for the 468 same transaction. 470 4.2.4. Info Package fallback rules 472 If the receiver of a request which contains a Recv-Info header field 473 rejects the request, both the sender and receiver of the request MUST 474 roll back to the set of Info Packages which was used before the 475 request was sent. This also applies to the case where the receiver 476 of an INVITE/re-INVITE request has included a Recv-Info header field 477 in a provisional response, but later rejects the request. 479 NOTE: The dialog state rollback rules for Info Packages might differ 480 from the rules for other types of dialog state information (SDP, 481 target, etc). 483 4.3. REGISTER Processing 485 This document allows a UA to insert a Recv-Info header field in a 486 REGISTER request. However, a UA SHALL NOT include a header value for 487 a specific Info Package unless the specific Info Package 488 specification describes how the header field value shall be 489 interpreted and used by the registrar, e.g. in order to determine 490 request targets. 492 Rather than using the Recv-Info header field in order to determine 493 request targets, it is recommended to use more appropriate 494 mechanisms, e.g. based on [RFC3840]. However, this document does not 495 define a feature tag for the Info Package mechanism, or a mechanism 496 to define feature tags for specific Info Packages. 498 5. Formal INFO Method Definition 500 5.1. INFO Method 502 This document describes one new SIP method: INFO. This document 503 replaces the definition and registrations found in [RFC2976]. 505 This table expands on Tables 2 and 3 in [RFC3261]. 507 Header Where INFO 508 ------ ----- ---- 509 Accept R o 510 Accept 415 o 511 Accept-Encoding R o 512 Accept-Encoding 2xx o 513 Accept-Encoding 415 c 514 Accept-Language R o 515 Accept-Language 2xx o 516 Accept-Language 415 o 517 Accept-Resource-Priority 2xx,417 o 518 Alert-Info - 519 Allow R o 520 Allow 405 m 521 Allow r o 522 Authentication-Info 2xx o 523 Authorization R o 524 Call-ID c m 525 Call-Info o 526 Contact - 527 Content-Disposition o 528 Content-Encoding o 529 Content-Language o 530 Content-Length o 531 Content-Type * 532 CSeq c m 533 Date o 534 Error-Info 3xx-6xx o 535 Expires - 536 From c m 537 Geolocation R o 538 Geolocation-Error r o 539 Max-Breadth R - 540 Max-Forwards R o 541 MIME-Version o 542 Min-Expires - 543 Organization - 544 Priority R - 545 Privacy o 546 Proxy-Authenticate 401 o 547 Proxy-Authenticate 407 m 548 Proxy-Authorization R o 549 Proxy-Require R o 550 Reason R o 551 Record-Route R o 552 Record-Route 2xx,18x o 553 Referred-By R o 554 Request-Disposition R o 555 Require o 556 Resource-Priority o 557 Retry-After R - 558 Retry-After 404,413,480,486 o 559 Retry-After 500,503 o 560 Retry-After 600,603 o 561 Route R o 562 Security-Client R o 563 Security-Server 421,494 o 564 Security-Verify R o 565 Server r o 566 Subject R o 567 Supported R o 568 Supported 2xx o 569 Timestamp o 570 To c m (w/ Tag) 571 Unsupported 420 o 572 User-Agent o 573 Via m 574 Warning r o 575 WWW-Authenticate 401 m 576 WWW-Authenticate 407 o 578 Figure 1: Table 1: Summary of Header Fields 580 6. INFO Header Fields 582 6.1. General 584 This table expands on tables 2 and 3 in [RFC3261]. 586 Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD 587 ------------------------------------------------------------------ 588 Info-Package R - - - - - - - m* - - 589 Recv-Info R - - - m - o o - - o 590 Recv-Info 2xx - - - o** - - o***- - o*** 591 Recv-Info 1xx - - - o** - - - - - - 592 Recv-Info 469 - - - - - - - m* - - 593 Recv-Info r - - - o - - o - - o 595 Header field where SUB NOT RFR 596 -------------------------------- 597 Info-Package R - - - 598 Recv-Info R - - - 599 Recv-Info 2xx - - - 600 Recv-Info 1xx - - - 601 Recv-Info 469 - - - 602 Recv-Info r - - - 604 Table 2: INFO-related Header Fields 606 The support and usage of the Info-Package and Recv-Info header fields 607 is not applicable to UAs that only support legacy INFO usages. 609 * Not applicable to INFO requests and responses associated with 610 legacy INFO usages. 612 ** Mandatory in at least one reliable 18x/2xx response, if sent, 613 to the INVITE request, if the associated INVITE request contained 614 a Recv-Info header field. 616 *** Mandatory if the associated request contained a Recv-Info 617 header field. 619 As defined in section 20 of RFC 3261 [RFC3261], a "mandatory" 620 header field MUST be present in a request, and MUST be understood 621 by the UAS receiving the request." 623 6.2. Info-Package header field 625 This document adds Info-Package to the definition of the element 626 "message-header" in the SIP message grammar [RFC3261]. Section 3 627 describes the Info-Package header field usage. 629 For the purposes of matching Info Package types indicated in Recv- 630 Info with those in the Info-Package header field value, one compares 631 the Info-package-name portion of the Info-package-type portion of the 632 Info-Package header field octet-by-octet with that of the Recv-Info 633 header field value. That is, the Info Package name is case 634 sensitive. Info-package-param is not part of the comparison-checking 635 algorithm. 637 This document does not define values for Info-Package types. 638 Individual Info Package specifications define these values. 640 6.3. Recv-Info header field 642 This document adds Recv-Info to the definition of the element 643 "message-header" in the SIP message grammar [RFC3261]. Section 4 644 describes the Recv-Info header field usage. 646 7. Info Package Considerations 648 7.1. General 650 This section covers considerations to take into account when deciding 651 whether the usage of an Info Package is appropriate for transporting 652 of application information for a specific use-case. 654 7.2. Appropriateness of Info Package Usage 656 When designing an Info Package, for application level information 657 exchange, it is important to consider: is signaling, using INFO 658 requests, within a SIP dialog, an appropriate mechanism for the use- 659 case? Is it because it is the most reasonable and appropriate 660 choice, or merely because "it's easy"? Choosing an inappropriate 661 mechanism for a specific use-case can cause negative effects in SIP 662 networks where the mechanism is used. 664 7.3. Alternative Mechanisms 666 7.3.1. Alternative SIP signaling plane mechanisms 668 7.3.1.1. General 670 This subsection describes some alternative mechanisms for 671 transporting application information on the SIP signaling plane, 672 using SIP messages. 674 7.3.1.2. INFO Request Rate and Volume 676 INFO messages differ from many other sorts of SIP messages in that 677 they carry application information, and the size and rate of the INFO 678 message is directly determined by the application. This can cause 679 application information traffic to interfere with other traffic on 680 that infrastructure, or to self-interfere when data rates become too 681 high. 683 There is no default throttling mechanism for INFO requests. Apart 684 from the SIP session establishment, the number of SIP messages 685 exchanged during the lifetime a normal SIP session is rather small. 687 Some applications, like sending of Dual-Tone Multi-Frequency (DTMF) 688 tones, can generate a burst of up to 20 messages per second. Other 689 applications, like constant GPS location updates, could generate a 690 high rate of INFO requests during the lifetime of the invite dialog 691 usage. 693 A designer of an Info Package, and the application that uses it, need 694 to consider the impact that the size and the rate of the INFO 695 messages have on the network and on other traffic, since it normally 696 cannot be ensured that INFO messages will be carried over a 697 congestion-controlled transport protocol end-to-end. Even if an INFO 698 message is sent over such a transport protocol, a downstream SIP 699 entity might forward the message over a transport protocol that does 700 not provide congestion control. 702 Furthermore, SIP messages tend to be relatively small, on the order 703 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 704 exchange of bulk data beyond these limits, especially if the headers 705 plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. 706 Appropriate mechanisms for such traffic include the Hypertext 707 Transfer Protocol (HTTP) [RFC2616], the Message Session Relay 708 Protocol (MSRP) [RFC4975], or other media plane data transport 709 mechanisms. 711 RFC 5405 [RFC5405] provides additional guidelines for applications 712 using UDP that may be useful background reading. 714 7.3.1.3. SUBSCRIBE/NOTIFY 716 An alternative for application level interaction is to use 717 subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and 718 NOTIFY methods. Using that mechanism, a UA requests state 719 information, such as key pad presses from a device to an application 720 server or key map images from an application server to a device. 722 Event Packages [RFC3265] perform the role of disambiguating the 723 context of a message for subscription-based events. The Info Package 724 mechanism provides similar functionality for application information 725 exchange using invite dialog usages [RFC5057]. 727 While an INFO request is always part of, and shares the fate of, an 728 existing invite dialog usage, a SUBSCRIBE request creates a separate 729 dialog usage [RFC5057], and is normally sent outside an existing 730 dialog usage. 732 The subscription-based mechanism can be used by SIP entities to 733 receive state information about SIP dialogs and sessions, without 734 requiring the entities to be part of the route set of those dialogs 735 and sessions. 737 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 738 and B2BUAs, the resource impact caused by the subscription dialogs 739 needs to be considered. The number of subscription dialogs per user 740 also needs to be considered. 742 As for any other SIP signaling plane based mechanism for transporting 743 application information, the SUBSCRIBE/NOTIFY messages can put a 744 significant burden on intermediate SIP entities which are part of the 745 dialog route set, but do not have any interest in the application 746 information transported between the end users. 748 7.3.1.4. MESSAGE 750 The MESSAGE method [RFC3428] defines one-time instant message 751 exchange, typically for sending MIME contents for rendering to the 752 user. 754 7.3.2. Media Plane Mechanisms 756 7.3.2.1. General 758 In SIP, media plane channels associated with SIP dialogs are 759 established using SIP signaling, but the data exchanged on the media 760 plane channel does not traverse SIP signaling intermediates, so if 761 there will be a lot of information exchanged, and there is no need 762 for the SIP signaling intermediaries to examine the information, it 763 is recommended to use a media plane mechanism, rather than a SIP 764 signaling based. 766 A low latency requirement for the exchange of information is one 767 strong indicator for using a media channel. Exchanging information 768 through the SIP routing network can introduce hundreds of 769 milliseconds of latency. 771 7.3.2.2. MRCP 773 One mechanism for media plane exchange of application data is the 774 Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2], 775 where a media plane connection-oriented channel, such as a 776 Transmission Control Protocol (TCP) [RFC0793] or Stream Control 777 Transmission Protocol (SCTP) [RFC4960] stream is established. 779 7.3.2.3. MRSP 781 MSRP [RFC4975] defines session-based instant messaging as well as 782 bulk file transfer and other such large-volume uses. 784 7.3.3. Non-SIP related mechanisms 786 Another alternative is to use a SIP-independent mechanism, such as 787 HTTP [RFC2616]. In this model, the UA knows about a rendezvous point 788 to direct HTTP requests to for the transfer of information. Examples 789 include encoding of a prompt to retrieve in the SIP Request URI in 790 [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- 791 voicexml21-20070619] script. 793 8. Syntax 795 8.1. General 797 This section describes the syntax extensions to the ABNF syntax 798 defined in [RFC3261] required for the INFO method, and adds 799 definitions for the Info-Package and Recv-Info header fields. The 800 previous sections describe the semantics. The ABNF defined in this 801 specification is conformant to [RFC5234]. 803 8.2. ABNF 805 INFOm = %x49.4E.46.4F ; INFO in caps 806 Method =/ INFOm 808 message-header =/ (Info-Package / Recv-Info) CRLF 809 Info-Package = "Info-Package" HCOLON Info-package-type 810 Recv-Info = "Recv-Info" HCOLON [Info-package-list] 811 Info-package-list = Info-package-type *( COMMA Info-package-type ) 812 Info-package-type = Info-package-name *( SEMI Info-package-param) 813 Info-package-name = token 814 Info-package-param = generic-param 816 9. Legacy INFO Usage 818 9.1. General 820 A number of applications, standardized and proprietary, make use of 821 the INFO method as it was previously defined in [RFC2976], referred 822 to as "legacy INFO usage". 824 For backward compatibility purpose, this document does not deprecate 825 such usages, and does not mandate users to define Info Packages for 826 such usages. However, it is strongly RECOMMENDED that any new usage 827 uses the Info Package mechanism defined in this specification, since 828 it does not share the issues associated with legacy INFO usage, and 829 since Info Packages can be registered with IANA. 831 9.2. Problems 833 While legacy INFO usage has been widely adopted for specific 834 application use cases, [RFC2976] did not define a mechanism for SIP 835 UAs to indicate for which types of applications and contexts they 836 support the INFO method. In addition, [RFC2976] did not provide a 837 mechanism to explicitly indicate the type of application and context 838 for which a specific INFO message is associated. 840 Example: If the Content-Type is "image/jpeg", the MIME-attached 841 content is a JPEG image. Still, there are many useful ways a UA can 842 render an image. The image could be a caller-id picture, a contact 843 icon, a photo for sharing, and so on. The sender does not know which 844 image to send to the receiver if the receiver supports an image 845 content type. Likewise, the receiver does not know the context of an 846 image the client is sending if the receiver supports receiving more 847 than one image content type. 849 Since legacy INFO usages do not have associated Info Packages, it is 850 not possible to use the Recv-Info and Info-Package header fields with 851 legacy INFO usages. That is, a UA cannot use the Recv-Info header 852 field to indicate for which legacy INFO usages it is willing to 853 receive INFO requests, and a UA cannot use the Info-Package header 854 field to indicate for which legacy INFO usage an INFO request is 855 associated with. 857 Due to the problems described above, legacy INFO usages often require 858 static configuration about for what type of applications and contexts 859 UAs support the INFO method, and the way they handle application 860 information transported in INFO messages. That has caused 861 interoperability problems in the industry. Therefore, a need for a 862 well defined and documented description of what the information sent 863 in the INFO is used for has been identified. This situation is 864 analogous to the context issue in Internet Mail [RFC3458]. 866 Section 4.1 describes how the Info Package mechanisms solves the 867 issues associated with legacy INFO usages. 869 9.3. Co-existence with Info Package based INFO usage 871 As described in Section 3, an INFO request associated with an Info 872 Package always contains an Info-Package header field. A UA MUST NOT 873 insert an Info-Package header field in a legacy INFO request. 875 UAs are allowed to enable both legacy INFO usages and Info Package 876 usages as part of the same invite dialog usage. However, UAs SHALL 877 NOT mix legacy INFO usages and Info Package usages in order to 878 transport the same application level information. If possible, UAs 879 SHALL prefer the usage of an Info Package. 881 See Appendix A for examples of existing legacy INFO usages. 883 10. Info Package Requirements 885 10.1. General 887 This section provides guidance on how to define an Info Package, and 888 what information needs to exist in an Info Package specification. 890 If, for an Info Package, there is a need to extend or modify the 891 behavior described in this document, that behavior MUST be described 892 in the Info Package specification. It is bad practice for Info 893 Package specifications to repeat procedures defined in this document, 894 unless needed for clarification or emphasis purpose. 896 Info Package specifications MUST NOT weaken any behavior designated 897 with "SHOULD" or "MUST" in this specification. However, Info 898 Packages specifications MAY strengthen "SHOULD", "MAY", or 899 "RECOMMENDED" requirements to "MUST" strength if applications 900 associated with the Info Package require it. 902 Info Package specifications MUST address the issues defined in the 903 following subsections, or document why an issue is not applicable for 904 the specific Info Package. 906 Section 7.3 describes alternative mechanisms, which should be 907 considered as part of the process for solving a specific use-case, 908 when there is a need for transporting application information. 910 10.2. Overall Description 912 The Info Package specification MUST contain an overall description of 913 the Info Package: what type of information are carried in INFO 914 requests associated with the Info Package, and for what type of 915 applications and functionalities UAs can use the Info Package. 917 If the Info Package is defined for a specific application, the Info 918 Package specification MUST state which application UAs can use the 919 Info Package with. 921 10.3. Applicability 923 The Info Package specification MUST describe why the Info Package 924 mechanism, rather than some other mechanism, has been chosen for the 925 specific use-case to transfer application information between SIP 926 endpoints. Common reasons can be a requirement for SIP Proxies or 927 back-to-back user agents (B2BUAs) to see the transported application 928 information (which would not be the case if the information was 929 transported on a media path), or that it is not seen feasible to 930 establish separate dialogs (subscription) in order to transport the 931 information. 933 Annex A provides more information, and describes alternative 934 mechanisms which one should consider for solving a specific use-case. 936 10.4. Info Package Name 938 The Info Package specification MUST define an Info Package name, 939 which UAs use as a header field value (e.g. "infoX") to identify the 940 Info Package in the Recv-Info and Info-Package header fields. The 941 header field value MUST conform to the ABNF defined in Section 8.2. 943 The Info Package mechanism does not support package versioning. 944 Specific Info Package message body payloads can contain version 945 information, which is handled by the applications associated with the 946 Info Package. However, such feature is outside the scope of the 947 generic Info Package mechanism. 949 NOTE: Even if an Info Package name contains version numbering (e.g. 950 foo_v2), the Info Package mechanism does not distinguish a version 951 number from the rest of the Info Package name. 953 10.5. Info Package Parameters 955 The Info Package specification MAY define Info Package parameters, 956 which can be used in the Recv-Info or Info-Package header fields, 957 together with the header field value which indicates the Info Package 958 name (see Section 10.4. 960 The Info Package specification MUST define the syntax and semantics 961 of the defined parameters. In addition, the specification MUST 962 define whether a specific parameter is only applicable to the Recv- 963 Info header field, the Info-Package header field, or both. 965 By default, an Info Package parameter is only applicable for the Info 966 Package for which the parameter has been explicitly defined. 968 Info Package parameters defined for specific Info Packages can share 969 the name with parameters defined for other Info Packages, but the 970 parameter semantics are specific to the Info Package for which they 971 are defined. However, when choosing the name of a parameter it is 972 RECOMMENDED to not use the same name as an existing parameter for 973 another Info Package, if the semantics of the parameters are 974 different. 976 10.6. SIP Option Tags 978 The Info Package specification MAY define SIP option tags, which can 979 be used as described in [RFC3261]. 981 The registration requirements for option tags are defined in 982 [RFC5727]. 984 10.7. INFO Message Body Parts 986 The Info Package specification MUST define which message body part 987 MIME types are associated with the Info Package. The specification 988 MUST either define those body parts, which include the syntax, 989 semantics and MIME type of the each body part, or refer to other 990 documents which define the body parts. 992 If multiple message body part MIME types are associated with an Info 993 Package, the Info Package specification MUST define whether UAs need 994 to use multipart body parts in order to include multiple body parts 995 in a single INFO request. 997 10.8. Info Package Usage Restrictions 999 If there are restrictions on how UAs can use an Info Package, the 1000 Info Package specification MUST document such restrictions. 1002 There can be restrictions related to whether UAs are allowed to send 1003 overlapping (outstanding) INFO requests associated with the Info 1004 Package, or whether the UA has to wait for the response for a 1005 previous INFO request associated with the same Info Package. 1007 There can also be restrictions related to whether UAs need to support 1008 and use other SIP extensions and capabilities when they use the Info 1009 Package, and if there are restrictions related to how UAs can use the 1010 Info-Package together with other Info Packages. 1012 As the SIP stack might not be aware of Info Package specific 1013 restrictions, it cannot be assumed that overlapping requests would be 1014 rejected. As defined in Section 3.2.2, UAs will normally send a 200 1015 (OK) response to an INFO request. The application logic associated 1016 with the Info Package needs to handle situations where UAs do not 1017 follow restrictions associated with the Info Package. 1019 10.9. Rate of INFO Requests 1021 If there is a maximum or minimum rate at which UAs can send INFO 1022 requests associated with the Info Package within a dialog, the Info 1023 Package specification MUST document the rate values. 1025 If the rates can vary, the Info Package specification MAY define Info 1026 Package parameters that UAs can use to indicate or negotiate the 1027 rates. Alternatively the rate information can be part of the 1028 application data information associated with the Info Package. 1030 10.10. Info Package Security Considerations 1032 If the application information carried in INFO requests associated 1033 with the Info Package requires a certain level of security, the Info 1034 Package specification MUST describe the mechanisms that UAs need to 1035 use in order to provide the required security. 1037 If the Info Package specification does not require any additional 1038 security, other than what the underlying SIP protocol provides, it 1039 MUST be stated in the Info Package specification. 1041 NOTE: In some cases, it may not be sufficient to mandate TLS in order 1042 to secure the Info Package payload, since intermediaries will have 1043 access to the payload, and beyond the first hop, there is no way to 1044 assure subsequent hops will not forwards the payload in clear text. 1045 The best way to ensure secure transport at the application level is 1046 to have the security at the application level. One way of achieving 1047 this is to use end-to-end security techniques such as S/MIME 1048 [RFC5751]. 1050 10.11. Implementation Details 1052 It is strongly RECOMMENDED that the Info Package specification 1053 defines the procedure how implementors shall implement and use the 1054 Info Package, or refer to other locations where implementors can find 1055 that information. 1057 NOTE: Sometimes Info Package designer might choose to not reveal the 1058 details of an Info Package. However, in order to allow multiple 1059 implementations to support the Info Package, Info Package designers 1060 are strongly encouraged to provide the implementation details. 1062 10.12. Examples 1064 It is RECOMMENDED that the Info Package specification provides 1065 demonstrative message flow diagrams, paired with complete messages 1066 and message descriptions. 1068 Note that example flows are by definition informative, and do not 1069 replace normative text. 1071 11. IANA Considerations 1073 11.1. Update to Registration of SIP INFO Method 1075 Please update the existing registration in the SIP Methods and 1076 Response Codes registry under the SIP Parameters registry that 1077 states: 1079 Method: INFO 1080 Reference: [RFC2976] 1082 to: 1084 Method: INFO 1085 Reference: [RFCXXXX] 1087 11.2. Registration of the Info-Package header field 1089 Please add the following new SIP header field in the Header Fields 1090 subregistry under the SIP Parameters registry. 1092 Header Name: Info-Package 1093 Compact Form: (none) 1094 Reference: [RFCXXXX] 1096 11.3. Registration of the Recv-Info header field 1098 Please add the following new SIP header field in the Header Fields 1099 subregistry under the SIP Parameters registry. 1101 Header Name: Recv-Info 1102 Compact Form: (none) 1103 Reference: [RFCXXXX] 1105 11.4. Creation of the Info Packages Registry 1107 Please create a subregistry in the SIP Parameters registry for Info 1108 Packages. 1110 Note to the reviewer: 1112 The policy for review of Info Packages is "Specification Required", 1113 as defined in [RFC5226]. This policy was selected because Info 1114 Packages re-use an existing mechanism for transport of arbitrary 1115 session-associated data within SIP, and therefore new Info Packages 1116 do not require the more extensive review required by specifications 1117 that make fundamental protocol changes. However, the reviewer is 1118 expected to verify that each Info Package registration is in fact 1119 consistent with this definition. Changes to the SIP protocol and 1120 state machine are outside of the allowable scope for an Info Package 1121 and are governed by other procedures including [RFC5727] and its 1122 successors, if any. 1124 The following data elements populate the Info Package Registry. 1125 o Info Package Name: The Info Package Name is a case-sensitive 1126 token. In addition, IANA shall not register multiple Info Package 1127 names that have identical case-insensitive values. 1128 o Reference: A reference to a specification which describes the Info 1129 Package. 1131 The initial population of this table shall be: 1133 Name Reference 1135 11.5. Registration of the Info-Package Content-Disposition 1137 Please add the following new header field value to the Content- 1138 Disposition registry. 1139 Name: info-package 1140 Description: the body contains information associated with an 1141 Info Package 1142 Reference: RFCXXXX 1144 11.6. SIP Response Code 469 Registration 1146 Please register the following new response code in the Session 1147 Initiation Protocol Parameters - Response Codes registry. 1148 Response Code: 469 1149 Default Reason Phrase: Bad Info Package 1150 Reference: RFCXXXX 1152 12. Examples 1154 12.1. Indication for which Info Packages UAs are willing to receive 1155 INFO requests 1157 12.1.1. Initial INVITE request 1159 The UAC sends an initial INVITE request, where the UAC indicates that 1160 it is willing to receive INFO requests for Info Packages P and R. 1162 INVITE sip:bob@example.com SIP/2.0 1163 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1164 Max-Forwards: 70 1165 To: Bob 1166 From: Alice ;tag=1928301774 1167 Call-ID: a84b4c76e66710@pc33.example.com 1168 CSeq: 314159 INVITE 1169 Recv-Info: P, R 1170 Contact: 1171 Content-Type: application/sdp 1172 Content-Length: ... 1174 ... 1176 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1177 indicates that it is willing to receive INFO requests for Info 1178 Packages R and T. 1180 SIP/2.0 200 OK 1181 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 1182 To: Bob ;tag=a6c85cf 1183 From: Alice ;tag=1928301774 1184 Call-ID: a84b4c76e66710@pc33.example.com 1185 CSeq: 314159 INVITE 1186 Contact: 1187 Recv-Info: R, T 1188 Content-Type: application/sdp 1189 Content-Length: ... 1191 ... 1193 The UAC sends an ACK request. 1195 ACK sip:bob@pc33.example.com SIP/2.0 1196 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 1197 Max-Forwards: 70 1198 To: Bob ;tag=a6c85cf 1199 From: Alice ;tag=1928301774 1200 Call-ID: a84b4c76e66710@pc33.example.com 1201 CSeq: 314159 ACK 1202 Content-Length: 0 1204 12.1.2. Target refresh 1206 The UAC sends an UPDATE request within the invite dialog usage, where 1207 the UAC indicates (using an empty Recv-Info header field) that it is 1208 not willing to receive INFO requests for any Info Packages. 1210 UPDATE sip:bob@pc33.example.com SIP/2.0 1211 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1212 Max-Forwards: 70 1213 To: Bob ;tag=a6c85cf 1214 From: Alice ;tag=1928301774 1215 Call-ID: a84b4c76e66710@pc33.example.com 1216 CSeq: 314163 UPDATE 1217 Recv-Info: 1218 Contact: 1219 Content-Type: application/sdp 1220 Content-Length: ... 1222 ... 1224 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1225 indicates that it is willing to receive INFO requests for Info 1226 Packages R, T. 1228 SIP/2.0 200 OK 1229 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 1230 To: Bob ;tag=a6c85cf 1231 From: Alice ;tag=1928301774 1232 Call-ID: a84b4c76e66710@pc33.example.com 1233 CSeq: 314163 INVITE 1234 Contact: 1235 Recv-Info: R, T 1236 Content-Type: application/sdp 1237 Content-Length: ... 1239 ... 1241 12.2. INFO request associated with Info Package 1243 12.2.1. Single payload 1245 The UA sends an INFO request associated with Info Package foo. 1247 INFO sip:alice@pc33.example.com SIP/2.0 1248 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1249 To: Bob ;tag=a6c85cf 1250 From: Alice ;tag=1928301774 1251 Call-Id: a84b4c76e66710@pc33.example.com 1252 CSeq: 314333 INFO 1253 Info-Package: foo 1254 Content-type: application/foo 1255 Content-Disposition: Info-Package 1256 Content-length: 24 1258 I am a foo message type 1260 12.2.2. Multipart INFO 1262 12.2.2.1. Non-Info Package body part 1264 SIP extensions can sometimes add body part payloads into an INFO 1265 request, independent of the Info Package. In this case, the Info 1266 Package payload gets put into a Multipart MIME body, with a Content- 1267 Disposition header field that indicates which body part is associated 1268 with the Info Package. 1270 INFO sip:alice@pc33.example.com SIP/2.0 1271 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1272 To: Alice ;tag=1234567 1273 From: Bob ;tag=abcdefg 1274 Call-Id: a84b4c76e66710@pc33.example.com 1275 CSeq: 314400 INFO 1276 Info-Package: foo 1277 Content-Type: multipart/mixed;boundary="theboundary" 1278 Content-Length: ... 1280 --theboundary 1281 Content-Type: application/mumble 1282 ... 1284 1286 --theboundary 1287 Content-Type: application/foo-x 1288 Content-Disposition: Info-Package 1289 Content-length: 59 1291 I am a foo-x message type, and I belong to Info Package foo 1292 --theboundary-- 1294 12.2.2.2. Info Package with multiple body parts inside multipart body 1295 part 1297 Multiple body part payloads can be associated with a single Info 1298 Package. In this case, the body parts are put into a Multipart MIME 1299 body, with a Content-Disposition header field that indicates which 1300 body part is associated with the Info Package. 1302 INFO sip:alice@pc33.example.com SIP/2.0 1303 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1304 To: Alice ;tag=1234567 1305 From: Bob ;tag=abcdefg 1306 Call-Id: a84b4c76e66710@pc33.example.com 1307 CSeq: 314423 INFO 1308 Info-Package: foo 1309 Content-Type: multipart/mixed;boundary="theboundary" 1310 Content-Disposition: Info-Package 1311 Content-Length: ... 1313 --theboundary 1314 Content-Type: application/foo-x 1315 Content-length: 59 1317 I am a foo-x message type, and I belong to Info Package foo 1319 1321 --theboundary 1322 Content-Type: application/foo-y 1323 Content-length: 59 1325 I am a foo-y message type, and I belong to Info Package foo 1326 --theboundary-- 1328 12.2.2.3. Info Package with single body part inside multipart body part 1330 The body part payload associated with the Info Package can have a 1331 Content-Disposition header field value other than "Info-Package". In 1332 this case, the body part is put into a Multipart MIME body, with a 1333 Content-Disposition header field that indicates which body part is 1334 associated with the Info Package. 1336 INFO sip:alice@pc33.example.com SIP/2.0 1337 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1338 To: Alice ;tag=1234567 1339 From: Bob ;tag=abcdefg 1340 Call-Id: a84b4c76e66710@pc33.example.com 1341 CSeq: 314423 INFO 1342 Info-Package: foo 1343 Content-Type: multipart/mixed;boundary="theboundary" 1344 Content-Disposition: Info-Package 1345 Content-Length: ... 1347 --theboundary 1348 Content-Type: application/foo-x 1349 Content-Disposition: icon 1350 Content-length: 59 1352 I am a foo-x message type, and I belong to Info Package foo 1353 --theboundary-- 1355 13. Security Considerations 1357 By eliminating multiple usages of INFO messages without adequate 1358 community review and by eliminating the possibility for rogue SIP UAs 1359 from confusing another UA by purposely sending unrelated INFO 1360 requests, as described in Section 9.2, we expect this document's 1361 clarification of the use of INFO to improve the security of the 1362 Internet. Whilst rogue UAs can still send unrelated INFO requests, 1363 this mechanism provides mechanisms for which the UAS and other 1364 security devices can associate INFO requests with Info Packages that 1365 have been negotiated for a session. 1367 If the content of the Info Package payload is private, UAs will need 1368 to use end-to-end encryption, such as S/MIME, to prevent access to 1369 the content. This is particularly important as transport of INFO is 1370 likely not to be end-to-end, but through SIP proxies and back-to-back 1371 user agents (B2BUA's), which the user may not trust. 1373 The INFO request transports application level information. One 1374 implication of this is INFO messages may require a higher level of 1375 protection than the underlying SIP dialog signaling. In particular, 1376 if one does not protect the SIP signaling from eavesdropping or 1377 authentication and repudiation attacks, for example by using TLS 1378 transport, then the INFO request and its contents will be vulnerable, 1379 as well. Even with SIP/TLS, any SIP hop along the path from UAC to 1380 UAS can view, modify, or intercept INFO requests, as they can with 1381 any SIP request. This means some applications may require end-to-end 1382 encryption of the INFO payload, beyond, for example, hop-by-hop 1383 protection of the SIP signaling itself. Since the application 1384 dictates the level of security required, individual Info Packages 1385 have to enumerate these requirements. In any event, the Info Package 1386 mechanism described by this document provides the tools for such 1387 secure, end-to-end transport of application data. 1389 One interesting property of Info Package use is one can reuse the 1390 same digest-challenge mechanism used for INVITE based authentication 1391 for the INFO request. For example, one could use a quality-of- 1392 protection (qop) value of authentication with integrity (auth-int), 1393 to challenge the request and its body, and prevent intermediate 1394 devices from modifying the body. However this assumes the device 1395 which knows the credentials in order to perform the INVITE challenge 1396 is still in the path for the INFO, or that the far-end UAS knows such 1397 credentials. 1399 14. References 1401 14.1. Normative References 1403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1404 Requirement Levels", BCP 14, RFC 2119, March 1997. 1406 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1407 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1408 May 2008. 1410 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1411 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1413 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1414 A., Peterson, J., Sparks, R., Handley, M., and E. 1415 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1416 June 2002. 1418 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1419 Initiation Protocol (SIP)", RFC 5621, September 2009. 1421 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1422 for the Session Initiation Protocol (SIP) and the Real- 1423 time Applications and Infrastructure Area", BCP 67, 1424 RFC 5727, March 2010. 1426 14.2. Informative References 1428 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1429 RFC 793, September 1981. 1431 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1432 October 2000. 1434 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1435 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1436 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1438 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1439 August 1980. 1441 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1442 with Session Description Protocol (SDP)", RFC 3264, 1443 June 2002. 1445 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1446 "Indicating User Agent Capabilities in the Session 1447 Initiation Protocol (SIP)", RFC 3840, August 2004. 1449 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1450 for Telephones (SIP-T): Context and Architectures", 1451 BCP 63, RFC 3372, September 2002. 1453 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1454 Event Notification", RFC 3265, June 2002. 1456 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1457 Context for Internet Mail", RFC 3458, January 2003. 1459 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1460 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1461 for Instant Messaging", RFC 3428, December 2002. 1463 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1464 Media Services with SIP", RFC 4240, December 2005. 1466 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1467 RFC 4960, September 2007. 1469 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1470 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1472 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1473 Control Markup Language (MSCML) and Protocol", RFC 5022, 1474 September 2007. 1476 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1477 Initiation Protocol", RFC 5057, November 2007. 1479 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1480 Media Control", RFC 5168, March 2008. 1482 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1483 for Application Designers", BCP 145, RFC 5405, 1484 November 2008. 1486 [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup 1487 Language (MSML)", RFC 5707, February 2010. 1489 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1490 Mail Extensions (S/MIME) Version 3.2 Message 1491 Specification", RFC 5751, January 2010. 1493 [W3C.REC-voicexml21-20070619] 1494 Porter, B., Oshry, M., Bodell, M., Rehor, K., McGlashan, 1495 S., Burke, D., Auburn, R., Candell, E., Burnett, D., 1496 Carter, J., Baggia, P., and A. Lee, "Voice Extensible 1497 Markup Language (VoiceXML) 2.1", World Wide Web Consortium 1498 Recommendation REC-voicexml21-20070619, June 2007, 1499 . 1501 [I-D.ietf-speechsc-mrcpv2] 1502 Shanmugham, S. and D. Burnett, "Media Resource Control 1503 Protocol Version 2 (MRCPv2)", 1504 draft-ietf-speechsc-mrcpv2-20 (work in progress), 1505 August 2009. 1507 [Ecma-355] 1508 "Standard ECMA-355 Corporate Telecommunication Networks - 1509 Tunnelling of QSIG over SIP", ECMA http:// 1510 www.ecma-international.org/publications/standards/ 1511 Ecma-355.htm, June 2008. 1513 Appendix A. Legacy INFO Usage 1515 A.1. General 1517 This section provides examples of existing legacy INFO usages. The 1518 section is not meant to be a comprehensive catalog of legacy INFO 1519 usages, but it should give the reader a flavor for current legacy 1520 INFO usages. 1522 A.2. ISUP 1524 [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP 1525 message bodies. ITU-T and 3GPP have specified similar procedures. 1527 A.3. QSIG 1529 [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. 1531 A.4. MSCML 1533 [RFC5022] specifies how INFO is used as a transport mechanism by the 1534 Media Server Control Markup Language (MSCML) protocol. MSCML uses an 1535 option-tag in the Require header field to ensure that the receiver 1536 understands the INFO content. 1538 A.5. MSML 1540 [RFC5707] specifies how INFO us used as a transport mechanism by the 1541 Media Server Markup Language (MSML) protocol. 1543 A.6. Video Fast Update 1545 Companies have been using INFO messages in order to request fast 1546 video update. Currently a standardized mechanism, based on RTCP, has 1547 been specified in [RFC5168] 1549 A.7. DTMF 1551 Companies have been using INFO messages in order to transport DTMF 1552 tones. All mechanisms are proprietary, and have not been 1553 standardized. 1555 Appendix B. Acknowledgements 1557 The work on this document was influenced by the "INFO Considered 1558 Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and 1559 by the "Packaging and Negotiation of INFO Methods for the Session 1560 Initiation Protocol" draft (15 January 2003) written by Dean Willis. 1562 The following individuals have been involved in the work, and have 1563 provided input and feedback on this document: 1564 Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben 1565 Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris 1566 Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean 1567 Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon 1568 Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James 1569 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1570 Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 1571 Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael 1572 Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, 1573 Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore 1574 Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve 1575 Langstaff, Sumit Garg and Xavier Marjoum. 1577 John Elwell and Francois Audet helped with QSIG references. In 1578 addition, Francois Audet provided text for the revised abstract. 1579 Keith Drage provided comments and helped immensely with Figure 1. 1581 Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert 1582 Sparks provided valuable feedback during the WGLC process, in order 1583 to prepare this document for publication. 1585 Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided 1586 valuable input in order to sort out the message body part usage for 1587 Info Packages. 1589 Appendix C. Change Log 1591 [RFC EDITOR NOTE: Please remove this section when publishing] 1593 Changes from draft-ietf-sipcore-info-events-08 1594 o Further changes based on IESG comments 1595 o Editorial changes 1596 o Section 7.3 removed 1597 o New section 7.4.1.2. added, containing text from old section 7.3 1599 Changes from draft-ietf-sipcore-info-events-07 1600 o Further changes based on WGLC comments 1601 o Editorial changes 1602 o IANA registry procedures clarified 1603 o Reference to RFC 5727 added 1605 Changes from draft-ietf-sipcore-info-events-05 1606 o Further changes based on WGLC comments 1607 o Editorial changes 1608 o IANA registry procedures clarified 1610 Changes from draft-ietf-sipcore-info-events-04 1611 o Further changes based on WGLC comments 1612 o OPTIONS processing removed 1613 o Clarification of Recv-Info header field in INFO 469 response added 1614 o IANA registry procedures clarified 1616 Changes from draft-ietf-sipcore-info-events-03 1617 o Further changes based on WGLC comments 1618 o New section 3.2.3 added 1620 Changes from draft-ietf-sipcore-info-events-02 1621 o Further changes based on WGLC comments 1622 o alignment with "specification" and "definition" terminology 1623 o Location switch of sections 3 and 4 1624 o Corrections in header table 1625 o IANA Info Package registration input changed 1626 o Clarification regarding which SIP messages can contain the Recv- 1627 Info header field 1628 o Recv-Info 'nil' value removed 1629 o Rules on usage of Recv-Info header clarified 1630 o Recv-Info fallback rules added 1631 o Additional examples added 1633 Changes from draft-ietf-sipcore-info-events-01 1634 o Further changes based on WGLC comments 1635 o Appending A moved into the main part of the document 1636 o Section name changed from "Modifications to SIP Change Process" to 1637 "Security Considerations" 1638 o "Syntax" section moved further up in the document 1639 o Clarification on usage of Info Package related message body parts, 1640 and the usage of the Content-Disposition header field with those 1641 body parts 1642 o Removed REFER and NOTIFY from the INFO Headers table 1643 o Clarified usage of the Recv-Info header field in the REGISTER and 1644 OPTIONS requests 1645 o Major re-write of the Introduction section 1646 o Text about legacy INFO and subscription-based events moved from 1647 the Introduction to the main part of the document 1648 o Wording about receiving Info-Packages has been replaced with 1649 wording about receiving INFO requests for Info-Packages 1650 o The text about the usage of message body, and body parts, 1651 associated with Info Packages, has been clarified 1653 Changes from draft-ietf-sip-info-events-04 1654 o Major re-write of the document, due to problems to implement WGLC 1655 comments into the existing text structure 1656 o Wording alignment 1657 o Clarification or roles 1659 Changes from draft-ietf-sip-info-events-03 1660 o Clarified Abstract language 1661 o All SIP dialogs are now referred to as sessions 1662 o Clarified the image example in the Introduction 1663 o Clarified the relationship (none) between SIP Event Packages and 1664 SIP Info Packages 1665 o Really, really clarified the protocol is NOT a negotiation but an 1666 advertisement 1668 o Split Section 3 into UAS and UAC behavior 1669 o Moved the example in section 3 into its own sub-section, and used 1670 full SIP header fields 1671 o Clarified forking behavior 1672 o Clarified language around when to send a body 1673 o Added 469 error response, instead of reusing 489 1674 o Clarified overlapping INFO method handling 1675 o Fixed table 1 to follow 3261, not 2543 1676 o Added REFER to the INFO Headers table 1677 o Replaced token-nodot with token for Info-Package header field 1678 values 1679 o Clarified end-to-end security considerations 1680 o Info Package parameters are semi-colon delimited, not dot 1681 delimited 1683 Changes from -02 1684 o Applicability statement explicitly says we're backwards compatible 1685 o Explicitly state we work like UPDATE (both early and confirmed 1686 dialogs) 1687 o Agreed text for IANA Considerations package registry 1689 Changes from -01 1690 o One and only one Info Package per INFO 1691 o Removed Send-Info header field, greatly simplifying negotiation 1692 o Multiple body part identification through Content-Disposition: 1693 Info-Package 1694 o Note that forking INVITEs may result in multiple INFOs coming back 1695 to INVITE originator 1696 o Describe how a UAS can enforce strict adherence to this document 1697 o Remove CANCEL INFO faux pas 1698 o Better explained overlapping INFO issues and resolutions 1699 o Token names are now really case sensitive 1700 o Moved Info Package Considerations to an Appendix 1701 o Introduced stronger, yet more open, IANA registration process 1702 o Took a few more paragraphs from INFO Litmus to cover all bases. 1703 o Added RFC 5168 to legacy usages 1705 Changes from -00 1706 o Corrected ABNF. 1707 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1708 messages was already here. 1709 o Negotiation is not Offer/Answer, it is Offer/Offer. 1710 o Created the explicit "nil" Info Package to indicate no info 1711 package. 1712 o Fixed CANCEL impacting future transactions. 1713 o Added Registrar behavior. 1715 o Added OPTIONS processing. 1716 o Clarified overlapping INFO method processing. 1717 o Described multiple INFO bodies in a single INFO method. 1718 o Took out Info-Package as a header field for responses to the INFO 1719 method. 1720 o Expanded on risks of using INFO and filled-in more on the 1721 alternatives 1722 o Moved definitions of INFO into the body of the text and cleaned up 1723 IANA Considerations section 1724 o Added legacy usages descriptions 1726 Authors' Addresses 1728 Christer Holmberg 1729 Ericsson 1730 Hirsalantie 11 1731 Jorvas, 02420 1732 Finland 1734 Phone: 1735 Fax: 1736 Email: christer.holmberg@ericsson.com 1737 URI: 1739 Eric W. Burger 1740 NeuStar, Inc. 1741 46000 Center Oak Plaza 1742 Sterling, VA 20166-6579 1743 USA 1745 Email: eburger@standardstrack.com 1746 URI: http://www.standardstrack.com 1748 Hadriel Kaplan 1749 Acme Packet 1750 71 Third Ave. 1751 Burlington, MA 01803 1752 USA 1754 Phone: 1755 Fax: 1756 Email: hkaplan@acmepacket.com 1757 URI: