idnits 2.17.1 draft-ietf-sipcore-info-events-09.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 599 has weird spacing: '...3xx-6xx o...' == Line 651 has weird spacing: '...d where prox...' -- The document date (September 28, 2010) is 4959 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 1101, 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-21 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: April 1, 2011 H. Kaplan 7 Acme Packet 8 September 28, 2010 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-09 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 April 1, 2011. 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Applicability and Backward Compatibility . . . . . . . . . . . 6 65 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 7 69 4.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 8 70 4.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 71 4.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 72 4.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 73 4.3.2. INFO Response Message Body . . . . . . . . . . . . . . 9 74 4.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 9 75 5. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 10 78 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 10 80 5.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 81 5.2.4. Info Package fallback rules . . . . . . . . . . . . . 12 82 5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 83 6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 84 6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 85 7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 86 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.2. Info-Package header field . . . . . . . . . . . . . . . . 15 88 7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16 89 8. Info Package Considerations . . . . . . . . . . . . . . . . . 16 90 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16 92 8.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 93 8.3.1. Alternative SIP signaling plane mechanisms . . . . . . 16 94 8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18 95 8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19 96 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 100 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 102 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 103 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21 104 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 105 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 106 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22 107 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 108 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 109 10.10. Info Package Security Considerations . . . . . . . . . . 23 110 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 111 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 113 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 114 11.2. Registration of the Info-Package header field . . . . . . 24 115 11.3. Registration of the Recv-Info header field . . . . . . . 24 116 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 117 11.5. Registration of the Info-Package Content-Disposition . . 25 118 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 119 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 120 12.1. Indication for which Info Packages UAs are willing to 121 receive INFO requests . . . . . . . . . . . . . . . . . . 25 122 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 123 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 124 12.2. INFO request associated with Info Package . . . . . . . . 27 125 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 126 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28 127 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 129 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 130 14.2. Informative References . . . . . . . . . . . . . . . . . 32 131 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 132 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 135 1. Introduction 137 This document defines a method, INFO, for the Session Initiation 138 Protocol (SIP) [RFC3261]. 140 The purpose of the INFO message is to carry application level 141 information between endpoints, using the SIP dialog signaling path. 142 Note that the INFO method is not used to update characteristics of a 143 SIP dialog or session, but to allow the applications which use the 144 SIP session to exchange information (which might update the state of 145 those applications). 147 Use of the INFO method does not constitute a separate dialog usage. 148 INFO messages are always part of, and share the fate of, an invite 149 dialog usage [RFC5057]. INFO messages cannot be sent as part of 150 other dialog usages, or outside an existing dialog. 152 This document also defines an Info Package mechanism. An Info 153 Package specification defines the content and semantics of the 154 information carried in an INFO message associated with the Info 155 Package. The Info Package mechanism also provides a way for UAs to 156 indicate for which Info Packages they are willing to receive INFO 157 requests, and which Info Package a specific INFO request is 158 associated with. 160 A UA uses the Recv-Info header field, on a per-dialog basis, to 161 indicate for which Info Packages it is willing to receive INFO 162 requests. A UA can indicate an initial set of Info Packages during 163 dialog establishment and can indicate a new set during the lifetime 164 of the invite dialog usage. 166 NOTE: A UA can use an empty Recv-Info header field (a header field 167 without a value) to indicate that it is not willing to receive INFO 168 requests for any Info-Package, but to inform other UAs that it still 169 supports the Info Package mechanism. 171 When a UA sends an INFO request, it uses the Info-Package header 172 field to indicate which Info Package is associated with the request. 173 One particular INFO request can only be associated with a single Info 174 Package. 176 2. Motivation 178 A number of applications, standardized and proprietary, make use of 179 the INFO method as it was previously defined in RFC 2976 [RFC2976], 180 referred to as "legacy INFO usage". These include but are not 181 limited to: 183 o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part 184 (ISUP) in SIP message bodies. ITU-T and 3GPP have specified 185 similar procedures. 186 o [Ecma-355] specifies the encapsulation of QSIG in SIP message 187 bodies. 188 o RFC 5022 [RFC5022] specifies how INFO is used as a transport 189 mechanism by the Media Server Control Markup Language (MSCML) 190 protocol. MSCML uses an option-tag in the Require header field to 191 ensure that the receiver understands the INFO content. 192 o RFC 5707 [RFC5707] specifies how INFO us used as a transport 193 mechanism by the Media Server Markup Language (MSML) protocol. 194 o Companies have been using INFO messages in order to request fast 195 video update. Currently a standardized mechanism, based on RTCP, 196 has been specified in RFC 5168 [RFC5168]. 197 o Companies have been using INFO messages in order to transport DTMF 198 tones. All mechanisms are proprietary, and have not been 199 standardized. 201 Some legacy INFO usages are also recognized as being shortcuts to 202 more appropriate and flexible mechanisms. 204 Furthermore, RFC 2976 did not define mechanisms that would enable a 205 SIP UA to indicate (1) the types of applications and contexts in 206 which they support the INFO method or (2) the types of application 207 and context with which a specific INFO message is associated. 209 Because legacy INFO usages do not have associated Info Packages, it 210 is not possible to use the Recv-Info and Info-Package header fields 211 with legacy INFO usages. That is, a UA cannot use the Recv-Info 212 header field to indicate for which legacy INFO usages it is willing 213 to receive INFO requests, and a UA cannot use the Info-Package header 214 field to indicate for which legacy INFO usage an INFO request is 215 associated with. 217 Due to the problems described above, legacy INFO usages often require 218 static configuration about for what type of applications and contexts 219 UAs support the INFO method, and the way they handle application 220 information transported in INFO messages. That has caused 221 interoperability problems in the industry. 223 To overcome these problems, the SIP Working Group has spent 224 significant discussion time over many years coming to agreement on 225 whether it was more appropriate to fix INFO (by defining a 226 registration mechanism for the ways in which it was used) or to 227 deprecate it altogether (with the usage described in RFC 3398 228 [RFC3398] being grandfathered as the sole legitimate usage). 229 Although it required substantial consensus building and concessions 230 by those more inclined to completely deprecate INFO, the eventual 231 direction of the working group was to publish a framework for 232 registration of INFO packages as defined in this specification. 234 3. Applicability and Backward Compatibility 236 This document defines a method, INFO, for the Session Initiation 237 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 238 document obsoletes RFC 2976 [RFC2976]. For backward compatibility, 239 the document also specifies a "legacy" mode of usage of the INFO 240 method that is compatible with the usage previously defined in RFC 241 2976, referred to as "legacy INFO Usage". 243 For backward compatibility purposes, this document does not deprecate 244 legacy INFO usages, and does not mandate users to define Info 245 Packages for such usages. However: 247 1. A UA MUST NOT insert an Info-Package header field in a legacy 248 INFO request (as described in Section 3, an INFO request 249 associated with an Info Package always contains an Info-Package 250 header field). 251 2. It is strongly RECOMMENDED that any new usage uses the Info 252 Package mechanism defined in this specification, since it does 253 not share the issues associated with legacy INFO usage, and since 254 Info Packages can be registered with IANA. 255 3. UAs are allowed to enable both legacy INFO usages and Info 256 Package usages as part of the same invite dialog usage, but UAs 257 SHALL NOT mix legacy INFO usages and Info Package usages in order 258 to transport the same application level information. If 259 possible, UAs SHALL prefer the usage of an Info Package. 261 4. The INFO Method 263 4.1. General 265 The INFO method provides a mechanism for transporting application 266 level information that can further enhance a SIP application. Annex 267 A gives more details on the types of applications for which the use 268 of INFO is appropriate. 270 This section describes how a UA handles INFO requests and responses, 271 as well as the message bodies included in INFO messages. 273 4.2. INFO Request 274 4.2.1. INFO Request Sender 276 An INFO request can be associated with an Info Package (see 277 Section 5), or associated with a legacy INFO usage (see Section 2). 279 The construction of the INFO request is the same as any other non- 280 target refresh request within an existing invite dialog usage as 281 described in Section 12.2 of RFC 3261. 283 When a UA sends an INFO request associated with an Info Package, it 284 MUST include an Info-Package header field that indicates which Info 285 Package is associated with the request. A specific INFO request can 286 be used only for a single Info Package. 288 When a UA sends an INFO request associated with an legacy INFO usage 289 there is no Info Package associated with the request, and the UA MUST 290 NOT include an Info-Package header field in the request. 292 The INFO request MUST NOT contain a Recv-Info header field. A UA can 293 only indicate a set of Info Packages for which it is willing to 294 receive INFO requests by using the SIP methods (and their responses) 295 listed in Section 5. 297 A UA MUST NOT send an INFO request outside an invite dialog usage and 298 MUST NOT send an INFO request for an Info Package inside an invite 299 dialog usage if the remote UA has not indicated willingness to 300 receive that Info-Package within that dialog. 302 If a UA receives a 469 (Bad Info Package) response to an INFO 303 request, based on RFC 5057 the response represents a Transaction Only 304 failure, and the UA MUST NOT terminate the invite dialog usage. 306 Due to the possibility of forking, the UA which sends the initial 307 INVITE request MUST be prepared to receive INFO requests from 308 multiple remote UAs during the early dialog phase. In addition, the 309 UA MUST be prepared to receive different Recv-Info header field 310 values from different remote UAs. 312 NOTE: If the UAS (receiver of the initial INVITE request) sends an 313 INFO request just after it has sent the response which creates the 314 dialog, the UAS needs to be prepared that the INFO request can reach 315 the UAC before the dialog creating response, and might therefore be 316 rejected by the UAC. In addition, an INFO request might be rejected 317 due to a race condition, if a UA sends the INFO request at the same 318 time as the remote UA sends a new set of Info Packages for which it 319 is willing to receive INFO requests. 321 4.2.2. INFO Request Receiver 323 If a UA receives an INFO request associated with an Info Package that 324 the UA has not indicated willingness to receive, the UA MUST send a 325 469 (Bad Info Package) response (see Section 11.6), which contains a 326 Recv-Info header field with Info Packages for which the UA is willing 327 to receive INFO requests. The UA MUST NOT use the response to update 328 the set of Info Packages, but simply to indicate the current set. In 329 the terminology of Multiple Dialog Usages [RFC5057], this represents 330 a Transaction Only failure, and does not terminate the invite dialog 331 usage. 333 If a UA receives an INFO request associated with an Info Package and 334 the message body part with Content-Disposition 'Info-Package' (see 335 Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) 336 type that the UA supports but not in the context of that Info 337 Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media 338 Type) response. 340 The UA MAY send other error responses, such as Request Failure (4xx), 341 Server Failure (5xx) and Global Failure (6xx), in accordance with the 342 error handling procedures defined in RFC 3261. 344 Otherwise, if the INFO request is syntactically correct and well 345 structured, the UA MUST send a 200 (OK) response. 347 NOTE: If the application needs to reject the information which it 348 received in an INFO request, that needs to be done on the application 349 level. I.e. the application needs to trigger a new INFO request, 350 which contains information that the previously received application 351 data was not accepted. Individual Info Package specifications need 352 to describe the details for such procedures. 354 4.2.3. SIP Proxies 356 Proxies need no additional behavior beyond that described in RFC 3261 357 to support INFO. 359 4.3. INFO Message Body 361 4.3.1. INFO Request Message Body 363 The purpose of the INFO request is to carry application level 364 information between SIP UAs. The application information data is 365 carried in the payload of the message body of the INFO request. 367 NOTE: An INFO request associated with an Info Package can also 368 include information associated with the Info Package using Info- 369 Package header field parameters. 371 If an INFO request associated with an Info Package contains a message 372 body part, the body part is identified by a Content-Disposition 373 header field 'Info-Package' value. The body part can contain a 374 single MIME type, or it can be a multipart [RFC5621] which contains 375 other body parts associated with the Info Package. 377 UAs MUST support multipart body parts in accordance with RFC 5621. 379 NOTE: An INFO request can also contain other body parts that are 380 meaningful within the context of an invite dialog usage but are not 381 specifically associated with the INFO method and the application 382 concerned. 384 When a UA supports a specific Info-Package, the UA MUST also support 385 message body MIME types in accordance with that Info-Package. 386 However, in accordance with RFC 3261 the UA still indicates the 387 supported MIME types using the Accept header. 389 4.3.2. INFO Response Message Body 391 A UA MUST NOT include a message body associated with an Info Package 392 in an INFO response. Message bodies associated with Info Packages 393 MUST only be sent in INFO requests. 395 A UA MAY include a message body which is not associated with an Info 396 Package in an INFO response. 398 4.4. Order of Delivery 400 The Info Package mechanism does not define a delivery order 401 mechanism. Info Packages can rely on the CSeq header field to detect 402 if an INFO request is received out of order. 404 If specific applications need additional mechanisms for order of 405 delivery, those mechanisms, and related procedures, are specified as 406 part of the associated Info Package (e.g. the use of sequence numbers 407 within the application data). 409 5. Info Packages 411 5.1. General 413 An Info Package specification defines the content and semantics of 414 the information carried in an INFO message associated with an Info 415 Package. The Info Package mechanism provides a way for UAs to 416 indicate for which Info Packages they are willing to receive INFO 417 requests, and which Info Package a specific INFO request is 418 associated with. 420 5.2. User Agent Behavior 422 5.2.1. General 424 This section describes how a UA handles Info Packages, how a UA uses 425 the Recv-Info header field, and how the UA acts in re-INVITE rollback 426 situations. 428 5.2.2. UA Procedures 430 A UA which supports the Info Package mechanism MUST indicate, using 431 the Recv-Info header field, the set of Info Packages for which it is 432 willing to receive INFO requests for a specific session. A UA can 433 list multiple Info Packages in a single Recv-Info header field, and 434 the UA can use multiple Recv-Info header fields. A UA can use an 435 empty Recv-Info header field, i.e. a header field without any header 436 field values. 438 A UA provides its set of Info Packages for which it is willing to 439 receive INFO requests during the dialog establishment. A UA can 440 update the set of Info Packages during the invite dialog usage. 442 If a UA is not willing to receive INFO requests for any Info 443 Packages, during dialog establishment or later during the invite 444 dialog usage, the UA MUST indicate this by including an empty Recv- 445 Info header field. This informs other UAs that the UA still supports 446 the Info Package mechanism. 448 Example: If a UA has previously indicated Info Packages 'foo' and 449 'bar' in a Recv-Info header field, and the UA during the lifetime of 450 the invite dialog usage wants to indicate that it does not want to 451 receive INFO requests for any Info Packages anymore, the UA sends a 452 message with an empty Recv-Info header field. 454 Once a UA has sent a message with a Recv-Info header field containing 455 a set of Info Packages, the set is valid until the UA sends a new 456 Recv-Info header field containing a new, or empty, set of Info 457 Packages. 459 Once a UA has indicated that it is willing to receive INFO requests 460 for a specific Info Package, and a dialog has been established, the 461 UA MUST be prepared to receive INFO request associated with that Info 462 Package until the UA indicates that it is no longer willing to 463 receive INFO requests associated with that Info Package. 465 For a specific dialog usage, a UA MUST NOT send an INFO request 466 associated with an Info Package until it has received an indication 467 that the remote UA is willing to receive INFO requests for that Info 468 Package, or after the UA has received an indication that the remote 469 UA is no longer willing to receive INFO requests associated with that 470 Info Package. 472 NOTE: When a UA sends a message which contains a Recv-Info header 473 field with a new set of Info Packages for which the UA is willing to 474 receive INFO requests the remote UA might, before it receives the 475 message, send an INFO request based on the old set of Info Packages. 476 In this case the receiver of the INFO requests rejects, and sends a 477 469 (Bad Info Package) response to, the INFO request. 479 If a UA indicates multiple Info Packages, which provide similar 480 functionality, it is not possible to indicate a priority order of the 481 Info Packages, or to indicate that the UA wishes to only receive INFO 482 requests for one of the Info Packages. It is up to the application 483 logic associated with the Info Packages, and specific Info Package 484 specifications, to describe application behavior in such cases. 486 For backward compatibility purpose, even if a UA indicates support of 487 the Info Package mechanism, it is still allowed to enable legacy INFO 488 usages. In addition, if a UA indicates support of the INFO method 489 using the Allow header field [RFC3261], it does not implicitly 490 indicate support of the Info Package mechanism. A UA MUST use the 491 Recv-Info header field in order to indicate that it supports the Info 492 Package mechanism. Likewise, even if a UA uses the Recv-Info header 493 field to indicate that it supports the Info Package mechanism, in 494 addition the UA still indicates support of the INFO method using the 495 Allow header. 497 This document does not define a SIP option tag [RFC3261] for the Info 498 Package mechanism. However, an Info Package specification can define 499 an option-tag associated with the specific Info Package, as described 500 in Section 10.6. 502 5.2.3. Recv-Info header field rules 504 The text below defines rules on when a UA is required to include a 505 Recv-Info header field in SIP messages. Section 7.1 lists the SIP 506 methods, for which a UA can insert a Recv-Info header field in 507 requests and responses. 509 - The sender of an initial INVITE request MUST include a Recv-Info 510 header field in the initial INVITE request, even if the sender is not 511 willing to receive INFO requests associated with any Info Package. 513 - The receiver of a request which contains a Recv-Info header field 514 MUST include a Recv-Info header field in a reliable 18x/2xx response 515 to the request, even if the request contains an empty Recv-Info 516 header field, and even if the header field value of the receiver has 517 not changed since the previous time it sent a Recv-Info header field. 519 - A UA MUST NOT include a Recv-Info header field in a response if the 520 associated request did not contain a Recv-Info header field. 522 NOTE: Different from the rules for generating SDP answers [RFC3264], 523 the receiver of a request which contains a set of Info Packages is 524 not restricted to generate its own set of Info Packages as a subset 525 of the Info Package set received in the Info Package header field of 526 the request. 528 Similar to SDP answers, the receiver can include the same Recv-Info 529 header field value in multiple responses (18x/2xx) for the same 530 INVITE/re-INVITE transaction, but the receiver MUST use the same 531 Recv-Info header field value (if included) in all responses for the 532 same transaction. 534 5.2.4. Info Package fallback rules 536 If the receiver of a request which contains a Recv-Info header field 537 rejects the request, both the sender and receiver of the request MUST 538 roll back to the set of Info Packages which was used before the 539 request was sent. This also applies to the case where the receiver 540 of an INVITE/re-INVITE request has included a Recv-Info header field 541 in a provisional response, but later rejects the request. 543 NOTE: The dialog state rollback rules for Info Packages might differ 544 from the rules for other types of dialog state information (SDP, 545 target, etc). 547 5.3. REGISTER Processing 549 This document allows a UA to insert a Recv-Info header field in a 550 REGISTER request. However, a UA SHALL NOT include a header value for 551 a specific Info Package unless the specific Info Package 552 specification describes how the header field value shall be 553 interpreted and used by the registrar, e.g. in order to determine 554 request targets. 556 Rather than using the Recv-Info header field in order to determine 557 request targets, it is recommended to use more appropriate 558 mechanisms, e.g. based on RFC 3840 [RFC3840]. However, this document 559 does not define a feature tag for the Info Package mechanism, or a 560 mechanism to define feature tags for specific Info Packages. 562 6. Formal INFO Method Definition 564 6.1. INFO Method 566 This document describes one new SIP method: INFO. This document 567 replaces the definition and registrations found in RFC 2976 568 [RFC2976]. 570 This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. 572 Header Where INFO 573 ------ ----- ---- 574 Accept R o 575 Accept 415 o 576 Accept-Encoding R o 577 Accept-Encoding 2xx o 578 Accept-Encoding 415 c 579 Accept-Language R o 580 Accept-Language 2xx o 581 Accept-Language 415 o 582 Accept-Resource-Priority 2xx,417 o 583 Alert-Info - 584 Allow R o 585 Allow 405 m 586 Allow r o 587 Authentication-Info 2xx o 588 Authorization R o 589 Call-ID c m 590 Call-Info o 591 Contact - 592 Content-Disposition o 593 Content-Encoding o 594 Content-Language o 595 Content-Length o 596 Content-Type * 597 CSeq c m 598 Date o 599 Error-Info 3xx-6xx o 600 Expires - 601 From c m 602 Geolocation R o 603 Geolocation-Error r o 604 Max-Breadth R - 605 Max-Forwards R o 606 MIME-Version o 607 Min-Expires - 608 Organization - 609 Priority R - 610 Privacy o 611 Proxy-Authenticate 401 o 612 Proxy-Authenticate 407 m 613 Proxy-Authorization R o 614 Proxy-Require R o 615 Reason R o 616 Record-Route R o 617 Record-Route 2xx,18x o 618 Referred-By R o 619 Request-Disposition R o 620 Require o 621 Resource-Priority o 622 Retry-After R - 623 Retry-After 404,413,480,486 o 624 Retry-After 500,503 o 625 Retry-After 600,603 o 626 Route R o 627 Security-Client R o 628 Security-Server 421,494 o 629 Security-Verify R o 630 Server r o 631 Subject R o 632 Supported R o 633 Supported 2xx o 634 Timestamp o 635 To c m (w/ Tag) 636 Unsupported 420 o 637 User-Agent o 638 Via m 639 Warning r o 640 WWW-Authenticate 401 m 641 WWW-Authenticate 407 o 643 Figure 1: Table 1: Summary of Header Fields 645 7. INFO Header Fields 647 7.1. General 649 This table expands on tables 2 and 3 in RFC 3261 [RFC3261]. 651 Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD 652 ------------------------------------------------------------------ 653 Info-Package R - - - - - - - m* - - 654 Recv-Info R - - - m - o o - - o 655 Recv-Info 2xx - - - o** - - o***- - o*** 656 Recv-Info 1xx - - - o** - - - - - - 657 Recv-Info 469 - - - - - - - m* - - 658 Recv-Info r - - - o - - o - - o 660 Header field where SUB NOT RFR 661 -------------------------------- 662 Info-Package R - - - 663 Recv-Info R - - - 664 Recv-Info 2xx - - - 665 Recv-Info 1xx - - - 666 Recv-Info 469 - - - 667 Recv-Info r - - - 669 Table 2: INFO-related Header Fields 671 The support and usage of the Info-Package and Recv-Info header fields 672 is not applicable to UAs that only support legacy INFO usages. 674 * Not applicable to INFO requests and responses associated with 675 legacy INFO usages. 677 ** Mandatory in at least one reliable 18x/2xx response, if sent, 678 to the INVITE request, if the associated INVITE request contained 679 a Recv-Info header field. 681 *** Mandatory if the associated request contained a Recv-Info 682 header field. 684 As defined in section 20 of RFC 3261, a "mandatory" header field 685 MUST be present in a request, and MUST be understood by the UAS 686 receiving the request." 688 7.2. Info-Package header field 690 This document adds Info-Package to the definition of the element 691 "message-header" in the SIP message grammar [RFC3261]. Section 4 692 describes the Info-Package header field usage. 694 For the purposes of matching Info Package types indicated in Recv- 695 Info with those in the Info-Package header field value, one compares 696 the Info-package-name portion of the Info-package-type portion of the 697 Info-Package header field octet-by-octet with that of the Recv-Info 698 header field value. That is, the Info Package name is case 699 sensitive. Info-package-param is not part of the comparison-checking 700 algorithm. 702 This document does not define values for Info-Package types. 703 Individual Info Package specifications define these values. 705 7.3. Recv-Info header field 707 This document adds Recv-Info to the definition of the element 708 "message-header" in the SIP message grammar [RFC3261]. Section 5 709 describes the Recv-Info header field usage. 711 8. Info Package Considerations 713 8.1. General 715 This section covers considerations to take into account when deciding 716 whether the usage of an Info Package is appropriate for transporting 717 of application information for a specific use-case. 719 8.2. Appropriateness of Info Package Usage 721 When designing an Info Package, for application level information 722 exchange, it is important to consider: is signaling, using INFO 723 requests, within a SIP dialog, an appropriate mechanism for the use- 724 case? Is it because it is the most reasonable and appropriate 725 choice, or merely because "it's easy"? Choosing an inappropriate 726 mechanism for a specific use-case can cause negative effects in SIP 727 networks where the mechanism is used. 729 8.3. Alternative Mechanisms 731 8.3.1. Alternative SIP signaling plane mechanisms 733 8.3.1.1. General 735 This subsection describes some alternative mechanisms for 736 transporting application information on the SIP signaling plane, 737 using SIP messages. 739 8.3.1.2. INFO Request Rate and Volume 741 INFO messages differ from many other sorts of SIP messages in that 742 they carry application information, and the size and rate of the INFO 743 message is directly determined by the application. This can cause 744 application information traffic to interfere with other traffic on 745 that infrastructure, or to self-interfere when data rates become too 746 high. 748 There is no default throttling mechanism for INFO requests. Apart 749 from the SIP session establishment, the number of SIP messages 750 exchanged during the lifetime a normal SIP session is rather small. 752 Some applications, like sending of Dual-Tone Multi-Frequency (DTMF) 753 tones, can generate a burst of up to 20 messages per second. Other 754 applications, like constant GPS location updates, could generate a 755 high rate of INFO requests during the lifetime of the invite dialog 756 usage. 758 A designer of an Info Package, and the application that uses it, need 759 to consider the impact that the size and the rate of the INFO 760 messages have on the network and on other traffic, since it normally 761 cannot be ensured that INFO messages will be carried over a 762 congestion-controlled transport protocol end-to-end. Even if an INFO 763 message is sent over such a transport protocol, a downstream SIP 764 entity might forward the message over a transport protocol that does 765 not provide congestion control. 767 Furthermore, SIP messages tend to be relatively small, on the order 768 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 769 exchange of bulk data beyond these limits, especially if the headers 770 plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. 771 Appropriate mechanisms for such traffic include the Hypertext 772 Transfer Protocol (HTTP) [RFC2616], the Message Session Relay 773 Protocol (MSRP) [RFC4975], or other media plane data transport 774 mechanisms. 776 RFC 5405 [RFC5405] provides additional guidelines for applications 777 using UDP that may be useful background reading. 779 8.3.1.3. SUBSCRIBE/NOTIFY 781 An alternative for application level interaction is to use 782 subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and 783 NOTIFY methods. Using that mechanism, a UA requests state 784 information, such as key pad presses from a device to an application 785 server or key map images from an application server to a device. 787 Event Packages [RFC3265] perform the role of disambiguating the 788 context of a message for subscription-based events. The Info Package 789 mechanism provides similar functionality for application information 790 exchange using invite dialog usages [RFC5057]. 792 While an INFO request is always part of, and shares the fate of, an 793 existing invite dialog usage, a SUBSCRIBE request creates a separate 794 dialog usage [RFC5057], and is normally sent outside an existing 795 dialog usage. 797 The subscription-based mechanism can be used by SIP entities to 798 receive state information about SIP dialogs and sessions, without 799 requiring the entities to be part of the route set of those dialogs 800 and sessions. 802 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 803 and B2BUAs, the resource impact caused by the subscription dialogs 804 needs to be considered. The number of subscription dialogs per user 805 also needs to be considered. 807 As for any other SIP signaling plane based mechanism for transporting 808 application information, the SUBSCRIBE/NOTIFY messages can put a 809 significant burden on intermediate SIP entities which are part of the 810 dialog route set, but do not have any interest in the application 811 information transported between the end users. 813 8.3.1.4. MESSAGE 815 The MESSAGE method [RFC3428] defines one-time instant message 816 exchange, typically for sending MIME contents for rendering to the 817 user. 819 8.3.2. Media Plane Mechanisms 821 8.3.2.1. General 823 In SIP, media plane channels associated with SIP dialogs are 824 established using SIP signaling, but the data exchanged on the media 825 plane channel does not traverse SIP signaling intermediates, so if 826 there will be a lot of information exchanged, and there is no need 827 for the SIP signaling intermediaries to examine the information, it 828 is recommended to use a media plane mechanism, rather than a SIP 829 signaling based. 831 A low latency requirement for the exchange of information is one 832 strong indicator for using a media channel. Exchanging information 833 through the SIP routing network can introduce hundreds of 834 milliseconds of latency. 836 8.3.2.2. MRCP 838 One mechanism for media plane exchange of application data is the 839 Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2], 840 where a media plane connection-oriented channel, such as a 841 Transmission Control Protocol (TCP) [RFC0793] or Stream Control 842 Transmission Protocol (SCTP) [RFC4960] stream is established. 844 8.3.2.3. MRSP 846 MSRP [RFC4975] defines session-based instant messaging as well as 847 bulk file transfer and other such large-volume uses. 849 8.3.3. Non-SIP related mechanisms 851 Another alternative is to use a SIP-independent mechanism, such as 852 HTTP [RFC2616]. In this model, the UA knows about a rendezvous point 853 to direct HTTP requests to for the transfer of information. Examples 854 include encoding of a prompt to retrieve in the SIP Request URI in 855 [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- 856 voicexml21-20070619] script. 858 9. Syntax 860 9.1. General 862 This section describes the syntax extensions to the ABNF syntax 863 defined in RFC 3261 required for the INFO method, and adds 864 definitions for the Info-Package and Recv-Info header fields. The 865 previous sections describe the semantics. The ABNF defined in this 866 specification is conformant to RFC 5234 [RFC5234]. 868 9.2. ABNF 870 INFOm = %x49.4E.46.4F ; INFO in caps 871 Method =/ INFOm 873 message-header =/ (Info-Package / Recv-Info) CRLF 874 Info-Package = "Info-Package" HCOLON Info-package-type 875 Recv-Info = "Recv-Info" HCOLON [Info-package-list] 876 Info-package-list = Info-package-type *( COMMA Info-package-type ) 877 Info-package-type = Info-package-name *( SEMI Info-package-param) 878 Info-package-name = token 879 Info-package-param = generic-param 881 10. Info Package Requirements 883 10.1. General 885 This section provides guidance on how to define an Info Package, and 886 what information needs to exist in an Info Package specification. 888 If, for an Info Package, there is a need to extend or modify the 889 behavior described in this document, that behavior MUST be described 890 in the Info Package specification. It is bad practice for Info 891 Package specifications to repeat procedures defined in this document, 892 unless needed for clarification or emphasis purpose. 894 Info Package specifications MUST NOT weaken any behavior designated 895 with "SHOULD" or "MUST" in this specification. However, Info 896 Packages specifications MAY strengthen "SHOULD", "MAY", or 897 "RECOMMENDED" requirements to "MUST" strength if applications 898 associated with the Info Package require it. 900 Info Package specifications MUST address the issues defined in the 901 following subsections, or document why an issue is not applicable for 902 the specific Info Package. 904 Section 8.3 describes alternative mechanisms, which should be 905 considered as part of the process for solving a specific use-case, 906 when there is a need for transporting application information. 908 10.2. Overall Description 910 The Info Package specification MUST contain an overall description of 911 the Info Package: what type of information are carried in INFO 912 requests associated with the Info Package, and for what type of 913 applications and functionalities UAs can use the Info Package. 915 If the Info Package is defined for a specific application, the Info 916 Package specification MUST state which application UAs can use the 917 Info Package with. 919 10.3. Applicability 921 The Info Package specification MUST describe why the Info Package 922 mechanism, rather than some other mechanism, has been chosen for the 923 specific use-case to transfer application information between SIP 924 endpoints. Common reasons can be a requirement for SIP Proxies or 925 back-to-back user agents (B2BUAs) to see the transported application 926 information (which would not be the case if the information was 927 transported on a media path), or that it is not seen feasible to 928 establish separate dialogs (subscription) in order to transport the 929 information. 931 Annex A provides more information, and describes alternative 932 mechanisms which one should consider for solving a specific use-case. 934 10.4. Info Package Name 936 The Info Package specification MUST define an Info Package name, 937 which UAs use as a header field value (e.g. "infoX") to identify the 938 Info Package in the Recv-Info and Info-Package header fields. The 939 header field value MUST conform to the ABNF defined in Section 9.2. 941 The Info Package mechanism does not support package versioning. 942 Specific Info Package message body payloads can contain version 943 information, which is handled by the applications associated with the 944 Info Package. However, such feature is outside the scope of the 945 generic Info Package mechanism. 947 NOTE: Even if an Info Package name contains version numbering (e.g. 948 foo_v2), the Info Package mechanism does not distinguish a version 949 number from the rest of the Info Package name. 951 10.5. Info Package Parameters 953 The Info Package specification MAY define Info Package parameters, 954 which can be used in the Recv-Info or Info-Package header fields, 955 together with the header field value which indicates the Info Package 956 name (see Section 10.4. 958 The Info Package specification MUST define the syntax and semantics 959 of the defined parameters. In addition, the specification MUST 960 define whether a specific parameter is only applicable to the Recv- 961 Info header field, the Info-Package header field, or both. 963 By default, an Info Package parameter is only applicable for the Info 964 Package for which the parameter has been explicitly defined. 966 Info Package parameters defined for specific Info Packages can share 967 the name with parameters defined for other Info Packages, but the 968 parameter semantics are specific to the Info Package for which they 969 are defined. However, when choosing the name of a parameter it is 970 RECOMMENDED to not use the same name as an existing parameter for 971 another Info Package, if the semantics of the parameters are 972 different. 974 10.6. SIP Option Tags 976 The Info Package specification MAY define SIP option tags, which can 977 be used as described in RFC 3261. 979 The registration requirements for option tags are defined in RFC 5727 980 [RFC5727]. 982 10.7. INFO Message Body Parts 984 The Info Package specification MUST define which message body part 985 MIME types are associated with the Info Package. The specification 986 MUST either define those body parts, which include the syntax, 987 semantics and MIME type of the each body part, or refer to other 988 documents which define the body parts. 990 If multiple message body part MIME types are associated with an Info 991 Package, the Info Package specification MUST define whether UAs need 992 to use multipart body parts in order to include multiple body parts 993 in a single INFO request. 995 10.8. Info Package Usage Restrictions 997 If there are restrictions on how UAs can use an Info Package, the 998 Info Package specification MUST document such restrictions. 1000 There can be restrictions related to whether UAs are allowed to send 1001 overlapping (outstanding) INFO requests associated with the Info 1002 Package, or whether the UA has to wait for the response for a 1003 previous INFO request associated with the same Info Package. 1005 There can also be restrictions related to whether UAs need to support 1006 and use other SIP extensions and capabilities when they use the Info 1007 Package, and if there are restrictions related to how UAs can use the 1008 Info-Package together with other Info Packages. 1010 As the SIP stack might not be aware of Info Package specific 1011 restrictions, it cannot be assumed that overlapping requests would be 1012 rejected. As defined in Section 4.2.2, UAs will normally send a 200 1013 (OK) response to an INFO request. The application logic associated 1014 with the Info Package needs to handle situations where UAs do not 1015 follow restrictions associated with the Info Package. 1017 10.9. Rate of INFO Requests 1019 If there is a maximum or minimum rate at which UAs can send INFO 1020 requests associated with the Info Package within a dialog, the Info 1021 Package specification MUST document the rate values. 1023 If the rates can vary, the Info Package specification MAY define Info 1024 Package parameters that UAs can use to indicate or negotiate the 1025 rates. Alternatively the rate information can be part of the 1026 application data information associated with the Info Package. 1028 10.10. Info Package Security Considerations 1030 If the application information carried in INFO requests associated 1031 with the Info Package requires a certain level of security, the Info 1032 Package specification MUST describe the mechanisms that UAs need to 1033 use in order to provide the required security. 1035 If the Info Package specification does not require any additional 1036 security, other than what the underlying SIP protocol provides, it 1037 MUST be stated in the Info Package specification. 1039 NOTE: In some cases, it may not be sufficient to mandate TLS in order 1040 to secure the Info Package payload, since intermediaries will have 1041 access to the payload, and beyond the first hop, there is no way to 1042 assure subsequent hops will not forwards the payload in clear text. 1043 The best way to ensure secure transport at the application level is 1044 to have the security at the application level. One way of achieving 1045 this is to use end-to-end security techniques such as S/MIME 1046 [RFC5751]. 1048 10.11. Implementation Details 1050 It is strongly RECOMMENDED that the Info Package specification 1051 defines the procedure how implementors shall implement and use the 1052 Info Package, or refer to other locations where implementors can find 1053 that information. 1055 NOTE: Sometimes Info Package designer might choose to not reveal the 1056 details of an Info Package. However, in order to allow multiple 1057 implementations to support the Info Package, Info Package designers 1058 are strongly encouraged to provide the implementation details. 1060 10.12. Examples 1062 It is RECOMMENDED that the Info Package specification provides 1063 demonstrative message flow diagrams, paired with complete messages 1064 and message descriptions. 1066 Note that example flows are by definition informative, and do not 1067 replace normative text. 1069 11. IANA Considerations 1071 11.1. Update to Registration of SIP INFO Method 1073 Please update the existing registration in the SIP Methods and 1074 Response Codes registry under the SIP Parameters registry that 1075 states: 1077 Method: INFO 1078 Reference: [RFC2976] 1080 to: 1082 Method: INFO 1083 Reference: [RFCXXXX] 1085 11.2. Registration of the Info-Package header field 1087 Please add the following new SIP header field in the Header Fields 1088 subregistry under the SIP Parameters registry. 1090 Header Name: Info-Package 1091 Compact Form: (none) 1092 Reference: [RFCXXXX] 1094 11.3. Registration of the Recv-Info header field 1096 Please add the following new SIP header field in the Header Fields 1097 subregistry under the SIP Parameters registry. 1099 Header Name: Recv-Info 1100 Compact Form: (none) 1101 Reference: [RFCXXXX] 1103 11.4. Creation of the Info Packages Registry 1105 Please create a subregistry in the SIP Parameters registry for Info 1106 Packages. 1108 Note to the reviewer: 1110 The policy for review of Info Packages is "Specification Required", 1111 as defined in [RFC5226]. This policy was selected because Info 1112 Packages re-use an existing mechanism for transport of arbitrary 1113 session-associated data within SIP, and therefore new Info Packages 1114 do not require the more extensive review required by specifications 1115 that make fundamental protocol changes. However, the reviewer is 1116 expected to verify that each Info Package registration is in fact 1117 consistent with this definition. Changes to the SIP protocol and 1118 state machine are outside of the allowable scope for an Info Package 1119 and are governed by other procedures including RFC 5727 and its 1120 successors, if any. 1122 The following data elements populate the Info Package Registry. 1124 o Info Package Name: The Info Package Name is a case-sensitive 1125 token. In addition, IANA shall not register multiple Info Package 1126 names that have identical case-insensitive values. 1127 o Reference: A reference to a specification which describes the Info 1128 Package. 1130 The initial population of this table shall be: 1132 Name Reference 1134 11.5. Registration of the Info-Package Content-Disposition 1136 Please add the following new header field value to the Content- 1137 Disposition registry. 1138 Name: info-package 1139 Description: the body contains information associated with an 1140 Info Package 1141 Reference: RFCXXXX 1143 11.6. SIP Response Code 469 Registration 1145 Please register the following new response code in the Session 1146 Initiation Protocol Parameters - Response Codes registry. 1147 Response Code: 469 1148 Default Reason Phrase: Bad Info Package 1149 Reference: RFCXXXX 1151 12. Examples 1153 12.1. Indication for which Info Packages UAs are willing to receive 1154 INFO requests 1156 12.1.1. Initial INVITE request 1158 The UAC sends an initial INVITE request, where the UAC indicates that 1159 it is willing to receive INFO requests for Info Packages P and R. 1161 INVITE sip:bob@example.com SIP/2.0 1162 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1163 Max-Forwards: 70 1164 To: Bob 1165 From: Alice ;tag=1928301774 1166 Call-ID: a84b4c76e66710@pc33.example.com 1167 CSeq: 314159 INVITE 1168 Recv-Info: P, R 1169 Contact: 1170 Content-Type: application/sdp 1171 Content-Length: ... 1173 ... 1175 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1176 indicates that it is willing to receive INFO requests for Info 1177 Packages R and T. 1178 SIP/2.0 200 OK 1179 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 1180 To: Bob ;tag=a6c85cf 1181 From: Alice ;tag=1928301774 1182 Call-ID: a84b4c76e66710@pc33.example.com 1183 CSeq: 314159 INVITE 1184 Contact: 1185 Recv-Info: R, T 1186 Content-Type: application/sdp 1187 Content-Length: ... 1189 ... 1191 The UAC sends an ACK request. 1193 ACK sip:bob@pc33.example.com SIP/2.0 1194 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 1195 Max-Forwards: 70 1196 To: Bob ;tag=a6c85cf 1197 From: Alice ;tag=1928301774 1198 Call-ID: a84b4c76e66710@pc33.example.com 1199 CSeq: 314159 ACK 1200 Content-Length: 0 1202 12.1.2. Target refresh 1204 The UAC sends an UPDATE request within the invite dialog usage, where 1205 the UAC indicates (using an empty Recv-Info header field) that it is 1206 not willing to receive INFO requests for any Info Packages. 1208 UPDATE sip:bob@pc33.example.com SIP/2.0 1209 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1210 Max-Forwards: 70 1211 To: Bob ;tag=a6c85cf 1212 From: Alice ;tag=1928301774 1213 Call-ID: a84b4c76e66710@pc33.example.com 1214 CSeq: 314163 UPDATE 1215 Recv-Info: 1216 Contact: 1217 Content-Type: application/sdp 1218 Content-Length: ... 1220 ... 1222 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1223 indicates that it is willing to receive INFO requests for Info 1224 Packages R, T. 1225 SIP/2.0 200 OK 1226 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 1227 To: Bob ;tag=a6c85cf 1228 From: Alice ;tag=1928301774 1229 Call-ID: a84b4c76e66710@pc33.example.com 1230 CSeq: 314163 INVITE 1231 Contact: 1232 Recv-Info: R, T 1233 Content-Type: application/sdp 1234 Content-Length: ... 1236 ... 1238 12.2. INFO request associated with Info Package 1240 12.2.1. Single payload 1242 The UA sends an INFO request associated with Info Package foo. 1244 INFO sip:alice@pc33.example.com SIP/2.0 1245 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1246 To: Bob ;tag=a6c85cf 1247 From: Alice ;tag=1928301774 1248 Call-Id: a84b4c76e66710@pc33.example.com 1249 CSeq: 314333 INFO 1250 Info-Package: foo 1251 Content-type: application/foo 1252 Content-Disposition: Info-Package 1253 Content-length: 24 1255 I am a foo message type 1257 12.2.2. Multipart INFO 1259 12.2.2.1. Non-Info Package body part 1261 SIP extensions can sometimes add body part payloads into an INFO 1262 request, independent of the Info Package. In this case, the Info 1263 Package payload gets put into a Multipart MIME body, with a Content- 1264 Disposition header field that indicates which body part is associated 1265 with the Info Package. 1267 INFO sip:alice@pc33.example.com SIP/2.0 1268 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1269 To: Alice ;tag=1234567 1270 From: Bob ;tag=abcdefg 1271 Call-Id: a84b4c76e66710@pc33.example.com 1272 CSeq: 314400 INFO 1273 Info-Package: foo 1274 Content-Type: multipart/mixed;boundary="theboundary" 1275 Content-Length: ... 1277 --theboundary 1278 Content-Type: application/mumble 1279 ... 1281 1283 --theboundary 1284 Content-Type: application/foo-x 1285 Content-Disposition: Info-Package 1286 Content-length: 59 1288 I am a foo-x message type, and I belong to Info Package foo 1289 --theboundary-- 1291 12.2.2.2. Info Package with multiple body parts inside multipart body 1292 part 1294 Multiple body part payloads can be associated with a single Info 1295 Package. In this case, the body parts are put into a Multipart MIME 1296 body, with a Content-Disposition header field that indicates which 1297 body part is associated with the Info Package. 1299 INFO sip:alice@pc33.example.com SIP/2.0 1300 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1301 To: Alice ;tag=1234567 1302 From: Bob ;tag=abcdefg 1303 Call-Id: a84b4c76e66710@pc33.example.com 1304 CSeq: 314423 INFO 1305 Info-Package: foo 1306 Content-Type: multipart/mixed;boundary="theboundary" 1307 Content-Disposition: Info-Package 1308 Content-Length: ... 1310 --theboundary 1311 Content-Type: application/foo-x 1312 Content-length: 59 1314 I am a foo-x message type, and I belong to Info Package foo 1316 1318 --theboundary 1319 Content-Type: application/foo-y 1320 Content-length: 59 1322 I am a foo-y message type, and I belong to Info Package foo 1323 --theboundary-- 1325 12.2.2.3. Info Package with single body part inside multipart body part 1327 The body part payload associated with the Info Package can have a 1328 Content-Disposition header field value other than "Info-Package". In 1329 this case, the body part is put into a Multipart MIME body, with a 1330 Content-Disposition header field that indicates which body part is 1331 associated with the Info Package. 1333 INFO sip:alice@pc33.example.com SIP/2.0 1334 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1335 To: Alice ;tag=1234567 1336 From: Bob ;tag=abcdefg 1337 Call-Id: a84b4c76e66710@pc33.example.com 1338 CSeq: 314423 INFO 1339 Info-Package: foo 1340 Content-Type: multipart/mixed;boundary="theboundary" 1341 Content-Disposition: Info-Package 1342 Content-Length: ... 1344 --theboundary 1345 Content-Type: application/foo-x 1346 Content-Disposition: icon 1347 Content-length: 59 1349 I am a foo-x message type, and I belong to Info Package foo 1350 --theboundary-- 1352 13. Security Considerations 1354 By eliminating multiple usages of INFO messages without adequate 1355 community review and by eliminating the possibility for rogue SIP UAs 1356 from confusing another UA by purposely sending unrelated INFO 1357 requests, we expect this document's clarification of the use of INFO 1358 to improve the security of the Internet. Whilst rogue UAs can still 1359 send unrelated INFO requests, this mechanism provides mechanisms for 1360 which the UAS and other security devices can associate INFO requests 1361 with Info Packages that have been negotiated for a session. 1363 If the content of the Info Package payload is private, UAs will need 1364 to use end-to-end encryption, such as S/MIME, to prevent access to 1365 the content. This is particularly important as transport of INFO is 1366 likely not to be end-to-end, but through SIP proxies and back-to-back 1367 user agents (B2BUA's), which the user may not trust. 1369 The INFO request transports application level information. One 1370 implication of this is INFO messages may require a higher level of 1371 protection than the underlying SIP dialog signaling. In particular, 1372 if one does not protect the SIP signaling from eavesdropping or 1373 authentication and repudiation attacks, for example by using TLS 1374 transport, then the INFO request and its contents will be vulnerable, 1375 as well. Even with SIP/TLS, any SIP hop along the path from UAC to 1376 UAS can view, modify, or intercept INFO requests, as they can with 1377 any SIP request. This means some applications may require end-to-end 1378 encryption of the INFO payload, beyond, for example, hop-by-hop 1379 protection of the SIP signaling itself. Since the application 1380 dictates the level of security required, individual Info Packages 1381 have to enumerate these requirements. In any event, the Info Package 1382 mechanism described by this document provides the tools for such 1383 secure, end-to-end transport of application data. 1385 One interesting property of Info Package use is one can reuse the 1386 same digest-challenge mechanism used for INVITE based authentication 1387 for the INFO request. For example, one could use a quality-of- 1388 protection (qop) value of authentication with integrity (auth-int), 1389 to challenge the request and its body, and prevent intermediate 1390 devices from modifying the body. However this assumes the device 1391 which knows the credentials in order to perform the INVITE challenge 1392 is still in the path for the INFO, or that the far-end UAS knows such 1393 credentials. 1395 14. References 1397 14.1. Normative References 1399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1400 Requirement Levels", BCP 14, RFC 2119, March 1997. 1402 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1403 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1404 May 2008. 1406 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1407 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1409 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1410 A., Peterson, J., Sparks, R., Handley, M., and E. 1411 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1412 June 2002. 1414 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1415 Initiation Protocol (SIP)", RFC 5621, September 2009. 1417 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1418 for the Session Initiation Protocol (SIP) and the Real- 1419 time Applications and Infrastructure Area", BCP 67, 1420 RFC 5727, March 2010. 1422 14.2. Informative References 1424 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1425 RFC 793, September 1981. 1427 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1428 October 2000. 1430 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1431 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1432 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1434 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1435 August 1980. 1437 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1438 with Session Description Protocol (SDP)", RFC 3264, 1439 June 2002. 1441 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, 1442 "Integrated Services Digital Network (ISDN) User Part 1443 (ISUP) to Session Initiation Protocol (SIP) Mapping", 1444 RFC 3398, December 2002. 1446 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1447 "Indicating User Agent Capabilities in the Session 1448 Initiation Protocol (SIP)", RFC 3840, August 2004. 1450 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1451 for Telephones (SIP-T): Context and Architectures", 1452 BCP 63, RFC 3372, September 2002. 1454 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1455 Event Notification", RFC 3265, June 2002. 1457 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1458 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1459 for Instant Messaging", RFC 3428, December 2002. 1461 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1462 Media Services with SIP", RFC 4240, December 2005. 1464 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1465 RFC 4960, September 2007. 1467 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1468 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1470 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1471 Control Markup Language (MSCML) and Protocol", RFC 5022, 1472 September 2007. 1474 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1475 Initiation Protocol", RFC 5057, November 2007. 1477 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1478 Media Control", RFC 5168, March 2008. 1480 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1481 for Application Designers", BCP 145, RFC 5405, 1482 November 2008. 1484 [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup 1485 Language (MSML)", RFC 5707, February 2010. 1487 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1488 Mail Extensions (S/MIME) Version 3.2 Message 1489 Specification", RFC 5751, January 2010. 1491 [W3C.REC-voicexml21-20070619] 1492 Rehor, K., Bodell, M., Burke, D., Baggia, P., Auburn, R., 1493 Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, 1494 A., Porter, B., and M. Oshry, "Voice Extensible Markup 1495 Language (VoiceXML) 2.1", World Wide Web Consortium 1496 Recommendation REC-voicexml21-20070619, June 2007, 1497 . 1499 [I-D.ietf-speechsc-mrcpv2] 1500 Burnett, D. and S. Shanmugham, "Media Resource Control 1501 Protocol Version 2 (MRCPv2)", 1502 draft-ietf-speechsc-mrcpv2-21 (work in progress), 1503 July 2010. 1505 [Ecma-355] 1506 "Standard ECMA-355 Corporate Telecommunication Networks - 1507 Tunnelling of QSIG over SIP", ECMA http:// 1508 www.ecma-international.org/publications/standards/ 1509 Ecma-355.htm, June 2008. 1511 Appendix A. Acknowledgements 1513 The work on this document was influenced by the "INFO Considered 1514 Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and 1515 by the "Packaging and Negotiation of INFO Methods for the Session 1516 Initiation Protocol" draft (15 January 2003) written by Dean Willis. 1518 The following individuals have been involved in the work, and have 1519 provided input and feedback on this document: 1521 Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben 1522 Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris 1523 Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean 1524 Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon 1525 Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James 1526 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1527 Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 1528 Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael 1529 Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, 1530 Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore 1531 Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve 1532 Langstaff, Sumit Garg and Xavier Marjoum. 1534 John Elwell and Francois Audet helped with QSIG references. In 1535 addition, Francois Audet provided text for the revised abstract. 1536 Keith Drage provided comments and helped immensely with Figure 1. 1538 Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert 1539 Sparks provided valuable feedback during the WGLC process, in order 1540 to prepare this document for publication. 1542 Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided 1543 valuable input in order to sort out the message body part usage for 1544 Info Packages. 1546 Appendix B. Change Log 1548 [RFC EDITOR NOTE: Please remove this section when publishing] 1550 Changes from draft-ietf-sipcore-info-events-09 1551 o New Motivation section added 1552 o Old section 9 and Annex A removed 1554 Changes from draft-ietf-sipcore-info-events-08 1555 o Further changes based on IESG comments 1556 o Editorial changes 1557 o Section 7.3 removed 1558 o New section 7.4.1.2. added, containing text from old section 7.3 1560 Changes from draft-ietf-sipcore-info-events-07 1561 o Further changes based on WGLC comments 1562 o Editorial changes 1563 o IANA registry procedures clarified 1564 o Reference to RFC 5727 added 1566 Changes from draft-ietf-sipcore-info-events-05 1567 o Further changes based on WGLC comments 1568 o Editorial changes 1569 o IANA registry procedures clarified 1571 Changes from draft-ietf-sipcore-info-events-04 1572 o Further changes based on WGLC comments 1573 o OPTIONS processing removed 1574 o Clarification of Recv-Info header field in INFO 469 response added 1575 o IANA registry procedures clarified 1577 Changes from draft-ietf-sipcore-info-events-03 1578 o Further changes based on WGLC comments 1579 o New section 3.2.3 added 1581 Changes from draft-ietf-sipcore-info-events-02 1582 o Further changes based on WGLC comments 1583 o alignment with "specification" and "definition" terminology 1584 o Location switch of sections 3 and 4 1585 o Corrections in header table 1586 o IANA Info Package registration input changed 1587 o Clarification regarding which SIP messages can contain the Recv- 1588 Info header field 1589 o Recv-Info 'nil' value removed 1590 o Rules on usage of Recv-Info header clarified 1591 o Recv-Info fallback rules added 1592 o Additional examples added 1594 Changes from draft-ietf-sipcore-info-events-01 1595 o Further changes based on WGLC comments 1596 o Appending A moved into the main part of the document 1597 o Section name changed from "Modifications to SIP Change Process" to 1598 "Security Considerations" 1599 o "Syntax" section moved further up in the document 1600 o Clarification on usage of Info Package related message body parts, 1601 and the usage of the Content-Disposition header field with those 1602 body parts 1603 o Removed REFER and NOTIFY from the INFO Headers table 1604 o Clarified usage of the Recv-Info header field in the REGISTER and 1605 OPTIONS requests 1606 o Major re-write of the Introduction section 1607 o Text about legacy INFO and subscription-based events moved from 1608 the Introduction to the main part of the document 1609 o Wording about receiving Info-Packages has been replaced with 1610 wording about receiving INFO requests for Info-Packages 1611 o The text about the usage of message body, and body parts, 1612 associated with Info Packages, has been clarified 1614 Changes from draft-ietf-sip-info-events-04 1615 o Major re-write of the document, due to problems to implement WGLC 1616 comments into the existing text structure 1617 o Wording alignment 1618 o Clarification or roles 1620 Changes from draft-ietf-sip-info-events-03 1621 o Clarified Abstract language 1622 o All SIP dialogs are now referred to as sessions 1623 o Clarified the image example in the Introduction 1624 o Clarified the relationship (none) between SIP Event Packages and 1625 SIP Info Packages 1626 o Really, really clarified the protocol is NOT a negotiation but an 1627 advertisement 1628 o Split Section 3 into UAS and UAC behavior 1629 o Moved the example in section 3 into its own sub-section, and used 1630 full SIP header fields 1631 o Clarified forking behavior 1632 o Clarified language around when to send a body 1633 o Added 469 error response, instead of reusing 489 1634 o Clarified overlapping INFO method handling 1635 o Fixed table 1 to follow 3261, not 2543 1636 o Added REFER to the INFO Headers table 1637 o Replaced token-nodot with token for Info-Package header field 1638 values 1639 o Clarified end-to-end security considerations 1640 o Info Package parameters are semi-colon delimited, not dot 1641 delimited 1643 Changes from -02 1644 o Applicability statement explicitly says we're backwards compatible 1645 o Explicitly state we work like UPDATE (both early and confirmed 1646 dialogs) 1647 o Agreed text for IANA Considerations package registry 1649 Changes from -01 1650 o One and only one Info Package per INFO 1651 o Removed Send-Info header field, greatly simplifying negotiation 1652 o Multiple body part identification through Content-Disposition: 1653 Info-Package 1654 o Note that forking INVITEs may result in multiple INFOs coming back 1655 to INVITE originator 1656 o Describe how a UAS can enforce strict adherence to this document 1657 o Remove CANCEL INFO faux pas 1658 o Better explained overlapping INFO issues and resolutions 1659 o Token names are now really case sensitive 1660 o Moved Info Package Considerations to an Appendix 1661 o Introduced stronger, yet more open, IANA registration process 1662 o Took a few more paragraphs from INFO Litmus to cover all bases. 1663 o Added RFC 5168 to legacy usages 1665 Changes from -00 1666 o Corrected ABNF. 1667 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1668 messages was already here. 1669 o Negotiation is not Offer/Answer, it is Offer/Offer. 1670 o Created the explicit "nil" Info Package to indicate no info 1671 package. 1672 o Fixed CANCEL impacting future transactions. 1673 o Added Registrar behavior. 1674 o Added OPTIONS processing. 1675 o Clarified overlapping INFO method processing. 1676 o Described multiple INFO bodies in a single INFO method. 1677 o Took out Info-Package as a header field for responses to the INFO 1678 method. 1679 o Expanded on risks of using INFO and filled-in more on the 1680 alternatives 1681 o Moved definitions of INFO into the body of the text and cleaned up 1682 IANA Considerations section 1683 o Added legacy usages descriptions 1685 Authors' Addresses 1687 Christer Holmberg 1688 Ericsson 1689 Hirsalantie 11 1690 Jorvas, 02420 1691 Finland 1693 Phone: 1694 Fax: 1695 Email: christer.holmberg@ericsson.com 1696 URI: 1698 Eric W. Burger 1699 NeuStar, Inc. 1700 46000 Center Oak Plaza 1701 Sterling, VA 20166-6579 1702 USA 1704 Email: eburger@standardstrack.com 1705 URI: http://www.standardstrack.com 1706 Hadriel Kaplan 1707 Acme Packet 1708 71 Third Ave. 1709 Burlington, MA 01803 1710 USA 1712 Phone: 1713 Fax: 1714 Email: hkaplan@acmepacket.com 1715 URI: