idnits 2.17.1 draft-ietf-sipcore-info-events-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2976], [RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 540 has weird spacing: '...3xx-6xx o...' == Line 591 has weird spacing: '...d where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 18, 2010) is 5183 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 1071, but not defined == Unused Reference: 'RFC3080' is defined on line 1398, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: 'RFC4028' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 1446, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-20 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 8 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: RFC 2976 E. Burger 5 (if approved) NeuStar, Inc. 6 Intended status: Standards Track H. Kaplan 7 Expires: July 22, 2010 Acme Packet 8 January 18, 2010 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-05 13 Abstract 15 This document defines a method, INFO, for the Session Initiation 16 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 17 document obsoletes [RFC2976]. For backward compatibility the 18 document also specifies a "legacy" mode of usage of the INFO method 19 that is compatible with the usage previously defined in [RFC2976], 20 referred to as "legacy INFO Usage" in this document. 22 Conventions Used in this Document 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 The terminology in this document conforms to the Internet Security 28 Glossary [RFC4949]. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on July 22, 2010. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 76 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 77 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 78 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 79 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 80 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 81 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 82 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 85 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 87 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 88 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 89 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 90 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 91 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 92 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 93 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 95 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 96 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 97 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 99 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 100 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 101 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 102 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 103 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 104 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 108 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 109 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 110 9.3. Co-existence with Info Package based INFO usage . . . . . 19 111 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 112 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 114 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 115 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 116 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 117 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 118 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 119 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 120 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 121 10.10. Info Package Security Considerations . . . . . . . . . . 22 122 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 123 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 124 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 125 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 126 11.2. Registration of the Info-Package Header Field . . . . . . 24 127 11.3. Registration of the Recv-Info Header Field . . . . . . . 24 128 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 129 11.5. Registration of the Info-Package Content-Disposition . . 24 130 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 131 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 132 12.1. Indication for which Info Packages UAs are willing to 133 receive INFO requests . . . . . . . . . . . . . . . . . . 25 134 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 135 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 136 12.2. INFO request associated with Info Package . . . . . . . . 27 137 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 138 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 139 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 140 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 141 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 142 14.2. Informative References . . . . . . . . . . . . . . . . . 31 143 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 144 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 145 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 146 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 147 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 148 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 149 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 150 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35 151 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 154 1. Introduction 156 This document defines a method, INFO, for the Session Initiation 157 Protocol (SIP) [RFC3261]. 159 The purpose of the INFO message is to carry application level 160 information between endpoints, using the SIP dialog signaling path. 161 Note that the INFO method is not used to update characteristics of a 162 SIP dialog or session, but to allow the applications which use the 163 SIP session to exchange information (which might update the state of 164 those applications). 166 Use of the INFO method does not constitute a separate dialog usage. 167 INFO messages are always part of, and share the fate of, an invite 168 dialog usage [RFC5057]. INFO messages cannot be sent as part of 169 other dialog usages, or outside an existing dialog. 171 This document also defines an Info Package mechanism. An Info 172 Package specification defines the content and semantics of the 173 information carried in an INFO message associated with the Info 174 Package. The Info Package mechanism also provides a way for UAs to 175 indicate for which Info Packages they are willing to receive INFO 176 requests, and which Info Package a specific INFO request is 177 associated with. 179 A UA uses the Recv-Info header field, on a per-dialog basis, to 180 indicate for which Info Packages it is willing to receive INFO 181 requests. A UA can indicate an initial set of Info Packages during 182 dialog establishment and can indicate a new set during the lifetime 183 of the invite dialog usage. 185 NOTE: A UA can use an empty Recv-Info header field (a header field 186 without a value) to indicate that it is not willing to receive INFO 187 requests for any Info-Package, but to inform other UAs that it still 188 supports the Info Package mechanism. 190 When a UA sends an INFO request, it uses the Info-Package header 191 field to indicate which Info Package is associated with the request. 192 One particular INFO request can only be associated with a single Info 193 Package. 195 2. Applicability 197 This document defines a method, INFO, for the Session Initiation 198 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 199 document obsoletes [RFC2976]. For backward compatibility the 200 document also specifies a "legacy" mode of usage of the INFO method 201 that is compatible with the usage previously defined in [RFC2976], 202 referred to as "legacy INFO Usage" in this document. 204 3. The INFO Method 206 3.1. General 208 The INFO method provides a mechanism for transporting application 209 level information that can further enhance a SIP application. Annex 210 A gives more details on the types of applications for which the use 211 of INFO is appropriate. 213 This section describes how a UA handles INFO requests and responses, 214 as well as the message bodies included in INFO messages. 216 3.2. INFO Request 218 3.2.1. INFO Request Sender 220 An INFO request can be associated with an Info Package (see 221 Section 4), or associated with a legacy INFO usage (see Section 9). 223 The construction of the INFO request is the same as any other non- 224 target refresh request within an existing invite dialog usage as 225 described in Section 12.2 of [RFC3261]. 227 When a UA sends an INFO request associated with an Info Package, it 228 MUST include an Info-Package header field that indicates which Info 229 Package is associated with the request. A specific INFO request can 230 be used only for a single Info Package. 232 When a UA sends an INFO request associated with an legacy INFO usage 233 there is no Info Package associated with the request, and the UA MUST 234 NOT include an Info-Package header field in the request. 236 The INFO request MUST NOT contain a Recv-Info header field. A UA can 237 only indicate a set of Info Packages for which it is willing to 238 receive INFO requests by using the SIP methods (and their responses) 239 listed in Section 4. 241 A UA MUST NOT send an INFO request outside an invite dialog usage and 242 MUST NOT send an INFO request for an Info Package inside an invite 243 dialog usage if the remote UA has not indicated willingness to 244 receive that Info-Package within that dialog. 246 If a UA receives a 469 (Bad INFO Package) response to an INFO 247 request, based on [RFC5057] the response represents a Transaction 248 Only failure, and the UA MUST NOT terminate the invite dialog usage. 250 Due to the possibility of forking, the UA whichs sends the initial 251 INVITE reqest MUST be prepared to receive INFO requests from multiple 252 remote UAs during the early dialog phase. In addition, the UA MUST 253 be prepared to receive different Recv-Info header field values from 254 different remote UAs. 256 NOTE: If the UAS (receiver of the initial INVITE request) sends an 257 INFO request just after it has sent the response which creates the 258 dialog, the UAS needs to be prepared that the INFO request can reach 259 the UAC before the dialog creating response, and might therefore be 260 rejected by the UAC. In addition, an INFO request might be rejected 261 due to a race condition, if a UA sends the INFO request at the same 262 time as the remote UA sends a new set of Info Packages for which it 263 is willing to receive INFO requests. 265 3.2.2. INFO Request Receiver 267 If a UA receives an INFO request associated with an Info Package that 268 the UA has not indicated willingness to receive, the UA MUST send a 269 469 (Bad INFO Package) response (see Section 11.6), which contains a 270 Recv-Info Header field with Info Packages for which the UA is willing 271 to receive INFO requests. The UA MUST NOT use the response to update 272 the set of Info Packages, but simply to indicate the current set. In 273 the terminology of Multiple Dialog Usages [RFC5057], this represents 274 a Transaction Only failure, and does not terminate the invite dialog 275 usage. 277 If a UA receives an INFO request associated with an Info Package and 278 the message body part with Content-Disposition 'Info-Package' (see 279 Section 3.3.1) has a MIME type that the UA supports but not in the 280 context of that Info Package, it is RECOMMENDED that the UA send a 281 415 (Unsupported Media Type) response. 283 The UA MAY send other error responses, such as Request Failure (4xx), 284 Server Failure (5xx) and Global Failure (6xx), in accordance with the 285 error handling procedures in [RFC3261]. 287 Otherwise, if the INFO request is syntactically correct and well 288 structured, the UA MUST send a 200 (OK) response. 290 NOTE: If the application needs to reject the information which it 291 received in an INFO request, that needs to be done on the application 292 level. Ie the application needs to trigger a new INFO request, which 293 contains information that the previously received application data 294 was not accepted. Individual Info Package specifications need to 295 describe the details for such procedures. 297 3.2.3. SIP Proxies 299 Proxies need no additional behavior beyond that described in 300 [RFC3261] to support INFO. 302 3.3. INFO Message Body 304 3.3.1. INFO Request Message Body 306 The purpose of the INFO request is to carry application level 307 information between SIP UAs. The application information data is 308 carried in the payload of the message body of the INFO request. 310 NOTE: An INFO request assocated with an Info Package can also include 311 information associated with the Info Package using Info-Package 312 header field parameters. 314 If an INFO request associated with an Info Package contains a message 315 body part, the body part is identified by a Content-Disposition 316 header field 'Info-Package' value. The body part can contain a 317 single MIME type, or it can be a multipart [RFC5621] which contains 318 other body parts associated with the Info Package. 320 UAs MUST support multipart body parts in accordance with [RFC5621]. 322 NOTE: An INFO request can also contain other body parts that are 323 meaningful within the context of an invite dialog usage but are not 324 specifically associated with the INFO method and the application 325 concerned. 327 When a UA supports a specific Info-Package, the UA MUST also support 328 message body MIME types in accordance with that Info-Package. 329 However, in accordance with [RFC3261] the UA still indicates the 330 supported MIME types using the Accept header. 332 3.3.2. INFO Response Message Body 334 A UA MUST NOT include a message body associated with an Info Package 335 in an INFO response. Message bodies associated with Info Packages 336 MUST only be sent in INFO requests. 338 A UA MAY include a message body which is not associated with an Info 339 Package in an INFO response. 341 3.4. Order of Delivery 343 The Info Package mechanism does not define a delivery order 344 mechanism. Info Packages can rely on the CSeq header field to detect 345 if an INFO request is received out of order. 347 If specific applications need additional mechanisms for order of 348 delivery, those mechanisms, and related procedures, are specified as 349 part of the associated Info Package (e.g. the use of sequence numbers 350 within the application data). 352 4. Info Packages 354 4.1. General 356 An Info Package specification defines the content and semantics of 357 the information carried in an INFO message associated with an Info 358 Package. The Info Package mechanism provides a way for UAs to 359 indicate for which Info Packages they are willing to receive INFO 360 requests, and which Info Package a specific INFO request is 361 associated with. 363 4.2. User Agent Behavior 365 4.2.1. General 367 This section describes how a UA handles Info Packages, how a UA uses 368 the Recv-Info header field, and how the UA acts in re-INVITE rollback 369 situations. 371 4.2.2. UA Procedures 373 A UA which supports the Info Package mechanism MUST indicate, using 374 the Recv-Info header field, the set of Info Packages for which it is 375 willing to receive INFO requests. A UA can list multiple Info 376 Packages in a single Recv-Info header field, and the UA can use 377 multiple Recv-Info header fields. A UA can use an empty Recv-Info 378 header field, ie a header field without any header field values. 380 A UA provides its set of Info Packages for which it is willing to 381 receive INFO requests during the dialog establishment. A UA can 382 update the set of Info Packages during the invite dialog usage. 384 If a UA is not willing to receive INFO requests for any Info 385 Packages, during dialog establishment or later during the invite 386 dialog usage, the UA MUST indicate this by including an empty Recv- 387 Info header field. This informs other UAs that the UA still supports 388 the Info Package mechanism. 390 Example: If a UA has previously indicated Info Packages 'foo' and 391 'bar' in a Recv-Info header field, and the UA during the lifetime of 392 the invite dialog usage wants to indicate that it does not want to 393 receive INFO requests for any Info Packages anymore, the UA sends a 394 message with an empty Recv-Info header field. 396 Once a UA has sent a message with a Recv-Info header field containing 397 a set of Info Packages, the set is valid until the UA sends a new 398 Recv-Info header field containing a new, or empty, set of Info 399 Packages. 401 Once a UA has indicated that it is willing to receive INFO requests 402 for a specific Info Package, and a dialog has been established, the 403 UA MUST be prepared to receive INFO request associated with that Info 404 Package until the UA indicates that it is no longer willing to 405 receive INFO requests associated with that Info Package. 407 For a specific dialog usage, a UA MUST NOT send an INFO request 408 associated with an Info Package until it has received an indication 409 that the remote UA is willing to receive INFO requests for that Info 410 Package, or after the UA has received an indication that the remote 411 UA is no longer willing to receive INFO requests associated with that 412 Info Package. 414 NOTE: When a UA sends a message which contains a Recv-Info header 415 field with a new set of Info Packages for which the UA is willing to 416 receive INFO requests the remote UA might, before it receives the 417 message, send an INFO request based on the old set of Info Packages. 418 In this case the receiver of the INFO requests rejects, and sends a 419 469 (Bad INFO Package) response to, the INFO request. 421 If a UA indicates multiple Info Packages, which provide similar 422 functionality, it is not possible to indicate a priority order of the 423 Info Packages, or to indicate that the UA wishes to only receive INFO 424 requests for one of the Info Packages. It is up to the application 425 logic associated with the Info Packages, and specific Info Package 426 specifications, to describe application behavior in such cases. 428 For backward compatibility purpose, even if a UA indicates support of 429 the Info Package mechanism, it is still allowed to enable legacy INFO 430 usages Appendix A. In addition, if a UA indicates support of the 431 INFO method using the Allow header field [RFC3261], it does not 432 implicitly indicate support of the Info Package mechanism. A UA MUST 433 use the Recv-Info header field in order to indicate that it supports 434 the Info Package mechanism. Likewise, even if a UA uses the Recv- 435 Info header field to indicate that it supports the Info Package 436 mechanism, in addition the UA still indicates support of the INFO 437 method using the Allow header. 439 This document does not define a SIP option tag [RFC3261] for the Info 440 Package mechanism. However, an Info Package specification can define 441 an option-tag associated with the specific Info Package, as described 442 in Section 10.6. 444 4.2.3. Recv-Info header field rules 446 The text below defines rules on when a UA is required to include a 447 Recv-Info header field in SIP messages. Section 6.1 lists the SIP 448 methods, for which a UA can insert a Recv-Info header field in 449 requests and responses. 451 - The sender of an initial INVITE request MUST include a Recv-Info 452 header field in the initial INVITE request, even if the sender is not 453 willing to receive INFO requests asscoiated with any Info Package. 455 - The receiver of a request which contains a Recv-Info header field 456 MUST include a Recv-Info header field in a reliable 18x/2xx response 457 to the request, even if the request contains an empty Recv-Info 458 header field, and even if the header field value of the receiver has 459 not changed since the previous time it sent a Recv-Info header field. 461 - A UA MUST NOT include a Recv-Info header field in a response if the 462 associated request did not contain a Recv-Info header field. 464 NOTE: Different from the rules for generating SDP answers [RFC3264], 465 the receiver of a request which contains a set of Info Packages is 466 not restricted to generate its own set of Info Packages as a subset 467 of the Info Package set received in the Info Package header field of 468 the request. 470 Similar to SDP answers, the receiver can include the same Recv-Info 471 header field value in multiple responses (18x/2xx) for the same 472 INVITE/re-INVITE transaction, but the receiver MUST NOT include a 473 Recv-Info header field value which is different from a value that the 474 receiver has already included in a response for the same transaction. 476 4.2.4. Info Package fallback rules 478 If the receiver of a request which contains a Recv-Info header field 479 rejects the request, both the sender and receiver of the request MUST 480 roll back to the set of Info Packages which was used before the 481 request was sent. This also applies to the case where the receiver 482 of an INVITE/re-INVITE request has included a Recv-Info header field 483 in a provisional response, but later rejects the request. 485 NOTE: The dialog state rollback rules for Info Packages might differ 486 from the rules for other types of dialog state information (SDP, 487 target, etc). 489 4.3. REGISTER Processing 491 This document allows a UA to insert a Recv-Info header field in a 492 REGISTER request. However, a UA SHALL NOT include a header value for 493 a specific Info Package unless the specific Info Package 494 specification describes how the header field value shall be 495 interpreted and used by the registrar, e.g. in order to determine 496 request targets. 498 Rather than using the Recv-Info header field in order to determine 499 request targets, it is recommended to use more appropriate 500 mechanisms, e.g. based on [RFC3840]. However, this document does not 501 define a feature tag for the Info Package mechanism, or a mechanism 502 to define feature tags for specific Info Packages. 504 5. Formal INFO Method Definition 506 5.1. INFO Method 508 This document describes one new SIP method: INFO. This document 509 replaces the definition and registrations found in [RFC2976]. 511 This table expands on Tables 2 and 3 in [RFC3261]. 513 Header Where INFO 514 ------ ----- ---- 515 Accept R o 516 Accept 415 o 517 Accept-Encoding R o 518 Accept-Encoding 2xx o 519 Accept-Encoding 415 c 520 Accept-Language R o 521 Accept-Language 2xx o 522 Accept-Language 415 o 523 Accept-Resource-Priority 2xx,417 o 524 Alert-Info - 525 Allow R o 526 Allow 405 m 527 Allow r o 528 Authentication-Info 2xx o 529 Authorization R o 530 Call-ID c m 531 Call-Info o 532 Contact - 533 Content-Disposition o 534 Content-Encoding o 535 Content-Language o 536 Content-Length o 537 Content-Type * 538 CSeq c m 539 Date o 540 Error-Info 3xx-6xx o 541 Expires - 542 From c m 543 Geolocation R o 544 Geolocation-Error r o 545 Max-Breadth R - 546 Max-Forwards R o 547 MIME-Version o 548 Min-Expires - 549 Organization - 550 Priority R - 551 Privacy o 552 Proxy-Authenticate 401 o 553 Proxy-Authenticate 407 m 554 Proxy-Authorization R o 555 Proxy-Require R o 556 Reason R o 557 Record-Route R o 558 Record-Route 2xx,18x o 559 Referred-By R o 560 Request-Disposition R o 561 Require o 562 Resource-Priority o 563 Retry-After R - 564 Retry-After 404,413,480,486 o 565 Retry-After 500,503 o 566 Retry-After 600,603 o 567 Route R o 568 Security-Client R o 569 Security-Server 421,494 o 570 Security-Verify R o 571 Server r o 572 Subject R o 573 Supported R o 574 Supported 2xx o 575 Timestamp o 576 To c m (w/ Tag) 577 Unsupported 420 o 578 User-Agent o 579 Via m 580 Warning r o 581 WWW-Authenticate 401 m 582 WWW-Authenticate 407 o 583 Figure 1: Table 1: Summary of Header Fields 585 6. INFO Header Fields 587 6.1. General 589 This table expands on tables 2 and 3 in [RFC3261]. 591 Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD 592 ------------------------------------------------------------------ 593 Info-Package R - - - - - - - m* - - 594 Recv-Info R - - - m - o o - - o 595 Recv-Info 2xx - - - o** - - o***- - o*** 596 Recv-Info 1xx - - - o** - - - - - - 597 Recv-Info 469 - - - - - - - m* - - 598 Recv-Info r - - - o - - o - - o 600 Header field where SUB NOT RFR 601 -------------------------------- 602 Info-Package R - - - 603 Recv-Info R - - - 604 Recv-Info 2xx - - - 605 Recv-Info 1xx - - - 606 Recv-Info 469 - - - 607 Recv-Info r - - - 609 Table 2: INFO-related Header Fields 611 The support and usage of the Info-Package and Recv-Info header fields 612 is not applicalbe to UAs that only support legacy INFO usages. 614 * Not applicalbe to INFO requests and responses associated with 615 legacy INFO usages. 617 ** Mandatory in at least one reliable 18x/2xx response, if sent, 618 to the INVITE request, if the associated INVITE request contained 619 a Recv-Info header field. 621 *** Mandatory if the associated request contained a Recv-Info 622 header field. 624 6.2. Info-Package header field 626 This document adds Info-Package to the definition of the element 627 "message-header" in the SIP message grammar [RFC3261]. Section 3 628 describes the Info-Package header field usage. 630 For the purposes of matching Info Package types indicated in Recv- 631 Info with those in the Info-Package header field value, one compares 632 the Info-package-name portion of the Info-package-type portion of the 633 Info-Package header field octet-by-octet with that of the Recv-Info 634 header field value. That is, the Info Package name is case 635 sensitive. Info-package-param is not part of the comparison-checking 636 algorithm. 638 This document does not define values for Info-Package types. 639 Individual Info Package specifications define these values. 641 6.3. Recv-Info header field 643 This document adds Recv-Info to the definition of the element 644 "message-header" in the SIP message grammar [RFC3261]. Section 4 645 describes the Recv-Info header field usage. 647 7. Info Package Considerations 649 7.1. General 651 This section covers considerations to take into account when deciding 652 whether the usage of an Info Package is appropriate for transporting 653 of application information for a specific use-case. 655 7.2. Appropriateness of Info Package Usage 657 When designing an Info Package, for application level information 658 exchange, it is important to consider: is signaling, using INFO 659 requests, within a SIP dialog, an appropriate mechanism for the use- 660 case? Is it because it is the most reasonable and appropriate 661 choice, or merely because "it's easy"? Choosing an inappropriate 662 mechanism for a specific use-case can cause negative effects in SIP 663 networks where the mechanism is used. 665 7.3. INFO Request Rate and Volume 667 There is no default throttling mechanism for INFO requests. Apart 668 from the SIP session establishment, the number of SIP messages 669 exchanged during the lifetime a normal SIP session is rather small. 671 Some applications, like sending of DTMF tones, can generate a burst 672 of up to 20 messages per second. Other applications, like constant 673 GPS location updates, could generate a high rate of INFO requests 674 during the lifetime of the invite dialog usage. 676 Furthermore, SIP messages tend to be relatively small, on the order 677 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 678 exchange of bulk data beyond these limits, especially if the headers 679 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 680 such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media 681 plane data transport mechanisms. 683 7.4. Alternative Mechanisms 685 7.4.1. Alternative SIP signaling plane mechanisms 687 7.4.1.1. General 689 This subsection describes some alternative mechanisms for 690 transporting application information on the SIP signaling plane, 691 using SIP messages. 693 7.4.1.2. SUBSCRIBE/NOTIFY 695 An alternative for application level interaction is to use 696 subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and 697 NOTIFY methods. Using that mechanism, a UA requests state 698 information, such as key pad presses from a device to an application 699 server or key map images from an application server to a device. 701 Event Packages [RFC3265] perform the role of disambiguating the 702 context of a message for subscription-based events. The Info Package 703 mechanism provides similar functionality for application information 704 exchange using invite dialog usages [RFC5057]. 706 While an INFO request is always part of, and shares the fate of, an 707 existing invite dialog usage, a SUBSCRIBE request creates a separate 708 dialog usage [RFC5057], and is normally sent outside an existing 709 dialog usage. 711 The subscription-based mechanism can be used by SIP entities to 712 receive state information about SIP dialogs and sessions, without 713 requiring the entities to be part of the route set of those dialogs 714 and sessions. 716 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 717 and B2BUAs, the resource impact caused by the subscription dialogs 718 needs to be considered. The number of subscription dialogs per user 719 also needs to be considered. 721 As for any other SIP signaling plane based mechanism for transporting 722 application information, the SUBSCRIBE/NOTIFY messages can put a 723 significant burden on intermediate SIP entities which are part of the 724 dialog route set, but do not have any interest in the application 725 information transported between the end users. 727 7.4.1.3. MESSAGE 729 The MESSAGE method [RFC3428] defines one-time instant message 730 exchange, typically for sending MIME contents for rendering to the 731 user. 733 7.4.2. Media Plane Mechanisms 735 7.4.2.1. General 737 In SIP, media plane channels associated with SIP dialogs are 738 established using SIP signaling, but the data exchanged on the media 739 plane channel does not traverse SIP signaling intermediates, so if 740 there will be a lot of information exchanged, and there is no need 741 for the SIP signaling intermediaries to examine the information, it 742 is recommended to use a media plane mechanism, rather than a SIP 743 signaling based. 745 A low latency requirement for the exchange of information is one 746 strong indicator for using a media channel. Exchanging information 747 through the SIP routing network can introduce hundreds of 748 milliseconds of latency. 750 7.4.2.2. MRCPv2 752 One mechanism for media plane exchange of application data is MRCPv2 753 [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented 754 channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is 755 established. 757 7.4.2.3. MRSP 759 MSRP [RFC4975] defines session-based instant messaging as well as 760 bulk file transfer and other such large-volume uses. 762 7.4.3. Non-SIP related mechanisms 764 Another alternative is to use a a SIP-independent mechanism, such as 765 HTTP [RFC2616]. In this model, the UA knows about a rendezvous point 766 to direct HTTP requests to for the transfer of information. Examples 767 include encoding of a prompt to retrieve in the SIP Request URI in 768 [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- 769 voicexml21-20070619] script. 771 8. Syntax 773 8.1. General 775 This section describes the syntax extensions to the ABNF syntax 776 defined in [RFC3261] required for the INFO method, and adds 777 definitions for the Info-Package and Recv-Info header fields. The 778 previous sections describe the semantics. The ABNF defined in this 779 specification is conformant to [RFC5234]. 781 8.2. ABNF 783 INFOm = %x49.4E.46.4F ; INFO in caps 784 Method =/ INFOm 786 message-header =/ (Info-Package / Recv-Info) CRLF 787 Info-Package = "Info-Package" HCOLON Info-package-type 788 Recv-Info = "Recv-Info" HCOLON [Info-package-list] 789 Info-package-list = Info-package-type *( COMMA Info-package-type ) 790 Info-package-type = Info-package-name *( SEMI Info-package-param) 791 Info-package-name = token 792 Info-package-param = generic-param 794 9. Legacy INFO Usage 796 9.1. General 798 A number of applications, standardized and proprietary, make use of 799 the INFO method as it was previously defined in [RFC2976], referred 800 to as "legacy INFO usage". 802 For backward compatibility purpose, this document does not deprecate 803 such usages, and does not mandate users to define Info Packages for 804 such usages. However, any new usage of INFO SHALL use the Info 805 Package mechanism defined in this specification. 807 9.2. Problems 809 While legacy INFO usage has been widely adopted for specific 810 application use cases, [RFC2976] did not define a mechanism for SIP 811 UAs to indicate for which types of applications and contexts they 812 support the INFO method. In addition, [RFC2976] did not provide a 813 mechanism to explicitly indicate the type of application and context 814 for which a specific INFO message is associated. 816 Example: If the Content-Type is "image/jpeg", the MIME-attached 817 content is a JPEG image. Still, there are many useful ways a UA can 818 render an image. The image could be a caller-id picture, a contact 819 icon, a photo for sharing, and so on. The sender does not know which 820 image to send to the receiver if the receiver supports an image 821 content type. Likewise, the receiver does not know the context of an 822 image the client is sending if the receiver supports receiving more 823 than one image content type. 825 Since legacy INFO usages do not have associated Info Packages, it is 826 not possible to use the Recv-Info and Info-Package header fields with 827 legacy INFO usages. That is, a UA cannot use the Recv-Info header 828 field to indicate for which legacy INFO usages it is willing to 829 receive INFO requests, and a UA cannot use the Info-Package header 830 field to indicate for which legacy INFO usage an INFO request is 831 associated with. 833 Due to the problems described above, legacy INFO usages often require 834 static configuration about for what type of applications and contexts 835 UAs support the INFO method, and the way they handle application 836 information transported in INFO messages. That has caused 837 interoperability problems in the industry. Therefore, a need for a 838 well defined and documented description of what the information sent 839 in the INFO is used for has been identified. This situation is 840 analogous to the context issue in Internet Mail [RFC3458]. 842 9.3. Co-existence with Info Package based INFO usage 844 As described in Section 3, an INFO request associated with an Info 845 Package always contains an Info-Package header field. A UA MUST NOT 846 insert an Info-Package header field in a legacy INFO request. 848 UAs are allowed to enable both legacy INFO usages and Info Package 849 usages as part of the same invite dialog usage. 851 See Appendix A for examples of existing legacy INFO usages. 853 10. Info Package Requirements 855 10.1. General 857 This section provides guidance on how to define an Info Package, and 858 what information needs to exist in an Info Package specification. 860 If, for an Info Package, there is a need to extend or modify the 861 behavior described in this document, that behaviour MUST be described 862 in the Info Package specification. It is bad practice for Info 863 Package specifications to repeat procedures defined in this document, 864 unless needed for clarification or emphasis purpose. 866 Info Package specifications MUST NOT weaken any behavior designated 867 with "SHOULD" or "MUST" in this specification. However, Info 868 Packages specifications MAY strengthen "SHOULD", "MAY", or 869 "RECOMMENDED" requirements to "MUST" strength if applications 870 associated with the Info Package require it. 872 Info Package specifications MUST address the issues defined in the 873 following subsections, or document why an issue is not applicable for 874 the specific Info Package. 876 Section 7.4 describes alternative mechanisms, which should be 877 considered as part of the process for solving a specific use-case, 878 when there is a need for transporting application information. 880 10.2. Overal Description 882 The Info Package specification MUST contain an overall description of 883 the Info Package: what type of information are carried in INFO 884 requests associated with the Info Package, and for what type of 885 applications and functionalities UAs can use the Info Package. 887 If the Info Package is defined for a specific application, the Info 888 Package specification MUST state which application UAs can use the 889 Info Package with. 891 10.3. Applicability 893 The Info Package specification MUST describe why the Info Package 894 mechanism, rather than some other mechanism, has been chosen for the 895 specific use-case to transfer application information between SIP 896 endpoints. Common reasons can be a requirement for SIP Proxies or 897 back-to-back user agents (B2BUAs) to see the transported application 898 information (which would not be the case if the information was 899 transported on a media path), or that it is not seen feasible to 900 establish separate dialogs (subscription) in order to transport the 901 information. 903 Annex A provides more information, and describes alternative 904 mechanisms which one should consider for solving a specific use-case. 906 10.4. Info Package Name 908 The Info Package specification MUST define an Info Package name, 909 which UAs use as a header field value (e.g. "infoX") to identify the 910 Info Package in the Recv-Info and Info-Package header fields. The 911 header field value MUST conform to the ABNF defined in Section 8.2. 913 The Info Package mechanism does not support package versioning. 915 Specific Info Package message body payloads can contain version 916 information, which is handled by the applications associated with the 917 Info Package. However, such feature is outside the scope of the 918 generic Info Package mechanism. 920 NOTE: Even if an Info Package name contains version numbering (e.g. 921 foo_v2), the Info Package mechanism does not distinguish a version 922 number from the rest of the Info Package name. 924 10.5. Info Package Parameters 926 The Info Package specification MAY define Info Package parameters, 927 which can be used in the Recv-Info or Info-Package header fields, 928 together with the header field value which indicates the Info Package 929 name (see Section 10.4. 931 The Info Package specification MUST define the syntax and semantics 932 of the defined parameters. In addition, the specification MUST 933 define whether a specific parameter is only applicable to the Recv- 934 Info header field, the Info-Package header field, or both. 936 By default, an Info Package parameter is only applicable for the Info 937 Package for which the parameter has been explicitly defined. 939 NOTE: Info Package parameters defined for specific Info Packages can 940 share the name with parameters defined for other Info Packages, but 941 the parameter semantics are specific to the Info Package for which 942 they are defined. 944 10.6. SIP Option Tags 946 The Info Package specification MAY define SIP option tags, which can 947 be used as described in [RFC3261]. 949 The registration requirements for option tags are defined in 950 [I-D.peterson-rai-rfc3427bis]. 952 10.7. INFO Message Body Parts 954 The Info Package specification MUST define which message body part 955 MIME types are associated with the Info Package. The specification 956 MUST either define those body parts, which include the syntax, 957 semantics and MIME type of the each body part, or refer to other 958 documents which define the body parts. 960 If multiple message body part MIME types are associated with an Info 961 Package, the Info Package specification MUST define whether UAs need 962 to use multipart body parts in order to include multiple body parts 963 in a single INFO request. 965 10.8. Info Package Usage Restrictions 967 If there are restrictions on how UAs can use an Info Package, the 968 Info Package specification MUST document such restrictions. 970 There can be restrictions related to whether UAs are allowed to send 971 overlapping (outstanding) INFO requests associated with the Info 972 Package, or whether the UA has to wait for the response for a 973 previous INFO request associated with the same Info Package. 975 There can also be restrictions related to whether UAs need to support 976 and use other SIP extensions and capabilities when they use the Info 977 Package, and if there are restrictions related to how UAs can use the 978 Info-Package together with other Info Packages. 980 As the SIP stack might not be aware of Info Package specific 981 restrictions, it cannot be assumed that overlapping requests would be 982 rejected. As defined in Section 3.2.2, UAs will normally send a 200 983 (OK) response to an INFO request. The application logic associated 984 with the Info Package needs to handle situations where UAs do not 985 follow restrictions associated with the Info Package. 987 10.9. Rate of INFO Requests 989 If there is a maximum or minumum rate at which UAs can send INFO 990 requests associated with the Info Package within a dialog, the Info 991 Package specification MUST document the rate values. 993 If the rates can vary, the Info Package specification MAY define Info 994 Package parameters that UAs can use to indicate or negotiate the 995 rates. Alternatively the rate information can be part of the 996 application data information associated with the Info Package. 998 10.10. Info Package Security Considerations 1000 If the application information carried in INFO requests associated 1001 with the Info Package requires certain level of security, the Info 1002 Package specification MUST describe the mechanisms that UAs need to 1003 use in order to provide the required security. 1005 If the Info Package specification does not require any additional 1006 security, other than what the underlying SIP protocol provides, it 1007 MUST be stated in the Info Package specification. 1009 NOTE: In some cases, it may not be sufficient to mandate TLS in order 1010 to secure the Info Package payload, since intermediaries will have 1011 access to the payload, and beyond the first hop, there is no way to 1012 assure subsequent hops will not forwards the payload in clear text. 1013 The best way to ensure secure transport at the application level is 1014 to have the security at the application level. One way of achieving 1015 this is to use end-to-end security techniques such as S/MIME 1016 [RFC3851]. 1018 10.11. Implementation Details 1020 It is strongly RECOMMENDED that the Info Package specification 1021 defines the procedure how implementors shall implement and use the 1022 Info Package, or refer to other locations where implementors can find 1023 that information. 1025 NOTE: Sometimes Info Package designer might choose to not reveal the 1026 details of an Info Package. However, in order to allow multiple 1027 implementations to support the Info Package, Info Package designers 1028 are stronly encouraged to provide the implementation details. 1030 10.12. Examples 1032 It is RECOMMENDED that the Info Package specification provides 1033 demonstrative message flow diagrams, paired with complete messages 1034 and message descriptions. 1036 Note that example flows are by definition informative, and do not 1037 replace normative text. 1039 11. IANA Considerations 1041 11.1. Update to Registration of SIP INFO Method 1043 Please update the existing registration in the SIP Methods and 1044 Response Codes registry under the SIP Parameters registry that 1045 states: 1047 Method: INFO 1048 Reference: [RFC2976] 1050 to: 1052 Method: INFO 1053 Reference: [RFCXXXX] 1055 11.2. Registration of the Info-Package Header Field 1057 Please add the following new SIP header field in the Header Fields 1058 subregistry under the SIP Parameters registry. 1060 Header Name: Info-Package 1061 Compact Form: (none) 1062 Reference: [RFCXXXX] 1064 11.3. Registration of the Recv-Info Header Field 1066 Please add the following new SIP header field in the Header Fields 1067 subregistry under the SIP Parameters registry. 1069 Header Name: Recv-Info 1070 Compact Form: (none) 1071 Reference: [RFCXXXX] 1073 11.4. Creation of the Info Packages Registry 1075 Please create a subregistry in the SIP Parameters registry for Info 1076 Packages. 1078 The registration policy for the registry is Specification Required 1079 [RFC5226]. 1081 The reviewer does not consider the applicability of the Info Package 1082 for the usage for which it is defined. 1084 The following data elements populate the Info Package Registry. 1085 o Info Package Name: The Info Package Name is a case insensitive 1086 token. In addition, IANA shall not register multiple Info Package 1087 names that have identical case-insensitive values. 1088 o Reference: A reference to a specification which describes the Info 1089 Package. 1091 The initial population of this table shall be: 1093 Name Reference 1095 11.5. Registration of the Info-Package Content-Disposition 1097 Please add the following new header field value to the Content- 1098 Disposition registry. 1099 Name: info-package 1100 Description: the body contains information associated with an 1101 Info Package 1102 Reference: RFCXXXX 1104 11.6. SIP Response Code 469 Registration 1106 Please register the following new response code in the Session 1107 Initiation Protocol Parameters - Response Codes registry. 1108 Response Code: 469 1109 Default Reason Phrase: Bad INFO Package 1110 Reference: RFCXXXX 1112 12. Examples 1114 12.1. Indication for which Info Packages UAs are willing to receive 1115 INFO requests 1117 12.1.1. Initial INVITE request 1119 The UAC sends an initial INVITE request, where the UAC indicates that 1120 it is willing to receive INFO requests for Info Packages P and R. 1122 INVITE sip:bob@example.com SIP/2.0 1123 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1124 Max-Forwards: 70 1125 To: Bob 1126 From: Alice ;tag=1928301774 1127 Call-ID: a84b4c76e66710@pc33.example.com 1128 CSeq: 314159 INVITE 1129 Recv-Info: P, R 1130 Contact: 1131 Content-Type: application/sdp 1132 Content-Length: ... 1134 ... 1136 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1137 indicates that it is willing to receive INFO requests for Info 1138 Packages R and T. 1140 SIP/2.0 200 OK 1141 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 1142 To: Bob ;tag=a6c85cf 1143 From: Alice ;tag=1928301774 1144 Call-ID: a84b4c76e66710@pc33.example.com 1145 CSeq: 314159 INVITE 1146 Contact: 1147 Recv-Info: R, T 1148 Content-Type: application/sdp 1149 Content-Length: ... 1151 ... 1153 The UAC sends an ACK request. 1155 ACK sip:bob@pc33.example.com SIP/2.0 1156 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 1157 Max-Forwards: 70 1158 To: Bob ;tag=a6c85cf 1159 From: Alice ;tag=1928301774 1160 Call-ID: a84b4c76e66710@pc33.example.com 1161 CSeq: 314159 ACK 1162 Content-Length: 0 1164 12.1.2. Target refresh 1166 The UAC sends an UPDATE request within the invite dialog usage, where 1167 the UAC indicates (using an empty Recv-Info header field) that it is 1168 not willing to receive INFO requests for any Info Packages. 1170 UPDATE sip:bob@pc33.example.com SIP/2.0 1171 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1172 Max-Forwards: 70 1173 To: Bob ;tag=a6c85cf 1174 From: Alice ;tag=1928301774 1175 Call-ID: a84b4c76e66710@pc33.example.com 1176 CSeq: 314163 UPDATE 1177 Recv-Info: 1178 Contact: 1179 Content-Type: application/sdp 1180 Content-Length: ... 1182 ... 1184 The UAS sends a 200 (OK) response back to the UAC, where the UAS 1185 indicates that it is willing to receive INFO requests for Info 1186 Packages R, T. 1188 SIP/2.0 200 OK 1189 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 1190 To: Bob ;tag=a6c85cf 1191 From: Alice ;tag=1928301774 1192 Call-ID: a84b4c76e66710@pc33.example.com 1193 CSeq: 314163 INVITE 1194 Contact: 1195 Recv-Info: R, T 1196 Content-Type: application/sdp 1197 Content-Length: ... 1199 ... 1201 12.2. INFO request associated with Info Package 1203 12.2.1. Single payload 1205 The UA sends an INFO request associated with Info Package foo. 1207 INFO sip:alice@pc33.example.com SIP/2.0 1208 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1209 To: Bob ;tag=a6c85cf 1210 From: Alice ;tag=1928301774 1211 Call-Id: a84b4c76e66710@pc33.example.com 1212 CSeq: 314333 INFO 1213 Info-Package: foo 1214 Content-type: application/foo 1215 Content-Disposition: Info-Package 1216 Content-length: 24 1218 I am a foo message type 1220 12.2.2. Multipart INFO 1222 12.2.2.1. Non-Info Package body part 1224 SIP extensions can sometimes add body part payloads into an INFO 1225 request, independent of the Info Package. In this case, the Info 1226 Package payload gets put into a Multipart MIME body, with a Content- 1227 Disposition header field that indicates which body part is associated 1228 with the Info Package. 1230 INFO sip:alice@pc33.example.com SIP/2.0 1231 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1232 To: Alice ;tag=1234567 1233 From: Bob ;tag=abcdefg 1234 Call-Id: a84b4c76e66710@pc33.example.com 1235 CSeq: 314400 INFO 1236 Info-Package: foo 1237 Content-Type: multipart/mixed;boundary="theboundary" 1238 Content-Length: ... 1240 --theboundary 1241 Content-Type: application/mumble 1242 ... 1244 1246 --theboundary 1247 Content-Type: application/foo-x 1248 Content-Disposition: Info-Package 1249 Content-length: 59 1251 I am a foo-x message type, and I belong to Info Package foo 1252 --theboundary-- 1254 12.2.2.2. Info Package with multiple body parts inside multipart body 1255 part 1257 Multiple body part payloads can be associated with a single Info 1258 Package. In this case, the body parts are put into a Multipart MIME 1259 body, with a Content-Disposition header field that indicates which 1260 body part is associated with the Info Package. 1262 INFO sip:alice@pc33.example.com SIP/2.0 1263 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1264 To: Alice ;tag=1234567 1265 From: Bob ;tag=abcdefg 1266 Call-Id: a84b4c76e66710@pc33.example.com 1267 CSeq: 314423 INFO 1268 Info-Package: foo 1269 Content-Type: multipart/mixed;boundary="theboundary" 1270 Content-Disposition: Info-Package 1271 Content-Length: ... 1273 --theboundary 1274 Content-Type: application/foo-x 1275 Content-length: 59 1277 I am a foo-x message type, and I belong to Info Package foo 1279 1281 --theboundary 1282 Content-Type: application/foo-y 1283 Content-length: 59 1285 I am a foo-y message type, and I belong to Info Package foo 1286 --theboundary-- 1288 12.2.2.3. Info Package with single body part inside multipart body part 1290 The body part payload associated with the Info Package can have a 1291 Content-Disposition header field value other than "Info-Package". In 1292 this case, the body part is put into a Multipart MIME body, with a 1293 Content-Disposition header field that indicates which body part is 1294 associated with the Info Package. 1296 INFO sip:alice@pc33.example.com SIP/2.0 1297 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1298 To: Alice ;tag=1234567 1299 From: Bob ;tag=abcdefg 1300 Call-Id: a84b4c76e66710@pc33.example.com 1301 CSeq: 314423 INFO 1302 Info-Package: foo 1303 Content-Type: multipart/mixed;boundary="theboundary" 1304 Content-Disposition: Info-Package 1305 Content-Length: ... 1307 --theboundary 1308 Content-Type: application/foo-x 1309 Content-Disposition: icon 1310 Content-length: 59 1312 I am a foo-x message type, and I belong to Info Package foo 1313 --theboundary-- 1315 13. Security Considerations 1317 By eliminating multiple usages of INFO messages without adequate 1318 community review and by eliminating the possibility for rogue SIP UAs 1319 from confusing another UA by purposely sending unrelated INFO 1320 requests, we expect this document's clarification of the use of INFO 1321 to improve the security of the Internet. Whilst rogue UAs can still 1322 send unrelated INFO requests, this mechanism provides mechanisms for 1323 which the UAS and other security devices can filter for approved Info 1324 Packages. 1326 If the content of the Info Package payload is private, UAs will need 1327 to use end-to-end encryption, such as S/MIME, to prevent access to 1328 the content. This is particularly important as transport of INFO is 1329 likely not to be end-to-end, but through SIP proxies and back-to-back 1330 user agents (B2BUA's), which the user may not trust. 1332 The INFO request transports application level information. One 1333 implication of this is INFO messages may require a higher level of 1334 protection than the underlying SIP dialog signaling. In particular, 1335 if one does not protect the SIP signaling from eavesdropping or 1336 authentication and repudiation attacks, for example by using TLS 1337 transport, then the INFO request and its contents will be vulnerable, 1338 as well. Even with SIP/TLS, any SIP hop along the path from UAC to 1339 UAS can view, modify, or intercept INFO requests, as they can with 1340 any SIP request. This means some applications may require end-to-end 1341 encryption of the INFO payload, beyond, for example, hop-by-hop 1342 protection of the SIP signaling itself. Since the application 1343 dictates the level of security required, individual Info Packages 1344 have to enumerate these requirements. In any event, the Info Package 1345 mechanism described by this document provides the tools for such 1346 secure, end-to-end transport of application data. 1348 One interesting property of Info Package use is one can reuse the 1349 same digest-challenge mechanism used for INVITE based authentication 1350 for the INFO request. For example, one could use a quality-of- 1351 protection (qop) value of authentication with integrity (auth-int), 1352 to challenge the request and its body, and prevent intermediate 1353 devices from modifying the body. However this assumes the device 1354 which knows the credentials in order to perform the INVITE challenge 1355 is still in the path for the INFO, or that the far-end UAS knows such 1356 credentials. 1358 14. References 1360 14.1. Normative References 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, March 1997. 1365 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1366 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1367 May 2008. 1369 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1370 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1372 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1373 A., Peterson, J., Sparks, R., Handley, M., and E. 1374 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1375 June 2002. 1377 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1378 Initiation Protocol (SIP)", RFC 5621, September 2009. 1380 14.2. Informative References 1382 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1383 RFC 793, September 1981. 1385 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1386 October 2000. 1388 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1389 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1390 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1392 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1393 August 1980. 1395 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1396 RFC 4949, August 2007. 1398 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1399 RFC 3080, March 2001. 1401 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1402 with Session Description Protocol (SDP)", RFC 3264, 1403 June 2002. 1405 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1406 Extensions (S/MIME) Version 3.1 Message Specification", 1407 RFC 3851, July 2004. 1409 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1410 Camarillo, "Best Current Practices for Third Party Call 1411 Control (3pcc) in the Session Initiation Protocol (SIP)", 1412 BCP 85, RFC 3725, April 2004. 1414 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1415 "Indicating User Agent Capabilities in the Session 1416 Initiation Protocol (SIP)", RFC 3840, August 2004. 1418 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1419 Preferences for the Session Initiation Protocol (SIP)", 1420 RFC 3841, August 2004. 1422 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1423 for Telephones (SIP-T): Context and Architectures", 1424 BCP 63, RFC 3372, September 2002. 1426 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1427 Event Notification", RFC 3265, June 2002. 1429 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1430 Context for Internet Mail", RFC 3458, January 2003. 1432 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1433 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1434 for Instant Messaging", RFC 3428, December 2002. 1436 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1437 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1439 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1440 the Session Description Protocol (SDP)", RFC 4145, 1441 September 2005. 1443 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1444 Media Services with SIP", RFC 4240, December 2005. 1446 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1447 (SIP) Event Package for Key Press Stimulus (KPML)", 1448 RFC 4730, November 2006. 1450 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1451 RFC 4960, September 2007. 1453 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1454 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1456 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1457 Control Markup Language (MSCML) and Protocol", RFC 5022, 1458 September 2007. 1460 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1461 Initiation Protocol", RFC 5057, November 2007. 1463 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1464 Media Control", RFC 5168, March 2008. 1466 [I-D.peterson-rai-rfc3427bis] 1467 Peterson, J., Jennings, C., and R. Sparks, "Change Process 1468 for the Session Initiation Protocol (SIP) and the Real- 1469 time Applications and Infrastructure Area", 1470 draft-peterson-rai-rfc3427bis-04 (work in progress), 1471 October 2009. 1473 [W3C.REC-voicexml21-20070619] 1474 Oshry, M., Rehor, K., Bodell, M., Burke, D., Auburn, R., 1475 Baggia, P., McGlashan, S., Candell, E., Burnett, D., 1476 Carter, J., Lee, A., and B. Porter, "Voice Extensible 1477 Markup Language (VoiceXML) 2.1", World Wide Web Consortium 1478 Recommendation REC-voicexml21-20070619, June 2007, 1479 . 1481 [I-D.ietf-speechsc-mrcpv2] 1482 Shanmugham, S. and D. Burnett, "Media Resource Control 1483 Protocol Version 2 (MRCPv2)", 1484 draft-ietf-speechsc-mrcpv2-20 (work in progress), 1485 August 2009. 1487 [I-D.saleem-msml] 1488 Saleem, A. and G. Sharratt, "Media Server Markup Language 1489 (MSML)", draft-saleem-msml-09 (work in progress), 1490 July 2009. 1492 [Ecma-355] 1493 "Standard ECMA-355 Corporate Telecommunication Networks - 1494 Tunnelling of QSIG over SIP", ECMA http:// 1495 www.ecma-international.org/publications/standards/ 1496 Ecma-355.htm, June 2008. 1498 Appendix A. Legacy INFO Usage 1500 A.1. General 1502 This section provides examples of existing legacy INFO usages. The 1503 section is not meant to be a comprehensive catalog of legacy INFO 1504 usages, but it should give the reader a flavor for current legacy 1505 INFO usages. 1507 A.2. ISUP 1509 [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. 1510 ITU-T and 3GPP have specified similar procedures. 1512 A.3. QSIG 1514 [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. 1516 A.4. MSCML 1518 [RFC5022] specifies how INFO is used as a transport mechanism by the 1519 MSCML protocol. MSCML uses an option-tag in the Require header field 1520 to ensure that the receiver understands the INFO content. 1522 A.5. MSML 1524 [I-D.saleem-msml] specifies how INFO us used as a transport mechanism 1525 by the MSML protocol. 1527 A.6. Video Fast Update 1529 Companies have been using INFO messages in order to request fast 1530 video update. Currently a standardized mechanism, based on RTCP, has 1531 been specified in [RFC5168] 1533 Appendix B. Acknowledgements 1535 The work on this document was influenced by the "INFO Considered 1536 Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and 1537 by the "Packaging and Negotiation of INFO Methods for the Session 1538 Initiation Protocol" draft (15 January 2003) written by Dean Willis. 1540 The following individuals have been involved in the work, and have 1541 provided input and feedback on this document: 1542 Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben 1543 Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris 1544 Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean 1545 Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon 1546 Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James 1547 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1548 Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 1549 Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael 1550 Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, 1551 Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore 1552 Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve 1553 Langstaff, Sumit Garg and Xavier Marjoum. 1555 John Elwell and Francois Audet helped with QSIG references. In 1556 addition, Francois Audet provided text for the revised abstract. 1557 Keith Drage provided comments and helped immensely with Figure 1. 1559 Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert 1560 Sparks provided valuable feedback during the WGLC process, in order 1561 to prepare this document for publication. 1563 Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided 1564 valuable input in order to sort out the message body part usage for 1565 Info Packages. 1567 Appendix C. Change Log 1569 [RFC EDITOR NOTE: Please remove this section when publishing] 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 Allignment 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 Clarifiaction 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 allignment 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 refered 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. 1671 o Created the explicit "nil" Info Package to indicate no info 1672 package. 1673 o Fixed CANCEL impacting future transactions. 1674 o Added Registrar behavior. 1675 o Added OPTIONS processing. 1676 o Clarified overlapping INFO method processing. 1677 o Described multiple INFO bodies in a single INFO method. 1678 o Took out Info-Package as a header field for responses to the INFO 1679 method. 1680 o Expanded on risks of using INFO and filled-in more on the 1681 alternatives 1682 o Moved definitions of INFO into the body of the text and cleaned up 1683 IANA Considerations section 1684 o Added legacy usages descriptions 1686 Authors' Addresses 1688 Christer Holmberg 1689 Ericsson 1690 Hirsalantie 11 1691 Jorvas, 02420 1692 Finland 1694 Phone: 1695 Fax: 1696 Email: christer.holmberg@ericsson.com 1697 URI: 1699 Eric W. Burger 1700 NeuStar, Inc. 1701 46000 Center Oak Plaza 1702 Sterling, VA 20166-6579 1703 USA 1705 Email: eburger@standardstrack.com 1706 URI: http://www.standardstrack.com 1707 Hadriel Kaplan 1708 Acme Packet 1709 71 Third Ave. 1710 Burlington, MA 01803 1711 USA 1713 Phone: 1714 Fax: 1715 Email: hkaplan@acmepacket.com 1716 URI: