diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6086.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6086.txt')
| -rw-r--r-- | doc/rfc/rfc6086.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc6086.txt b/doc/rfc/rfc6086.txt new file mode 100644 index 0000000..656985f --- /dev/null +++ b/doc/rfc/rfc6086.txt @@ -0,0 +1,2019 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 6086 Ericsson +Obsoletes: 2976 E. Burger +Category: Standards Track Georgetown University +ISSN: 2070-1721 H. Kaplan + Acme Packet + January 2011 + + + Session Initiation Protocol (SIP) INFO Method and Package Framework + +Abstract + + This document defines a method, INFO, for the Session Initiation + Protocol (SIP), and an Info Package mechanism. This document + obsoletes RFC 2976. For backward compatibility, this document also + specifies a "legacy" mode of usage of the INFO method that is + compatible with the usage previously defined in RFC 2976, referred to + as "legacy INFO Usage" in this document. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6086. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Holmberg, et al. Standards Track [Page 1] + +RFC 6086 INFO Framework January 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Motivation ......................................................4 + 3. Applicability and Backward Compatibility ........................5 + 4. The INFO Method .................................................6 + 4.1. General ....................................................6 + 4.2. INFO Request ...............................................6 + 4.2.1. INFO Request Sender .................................6 + 4.2.2. INFO Request Receiver ...............................7 + 4.2.3. SIP Proxies .........................................8 + 4.3. INFO Message Body ..........................................8 + 4.3.1. INFO Request Message Body ...........................8 + 4.3.2. INFO Response Message Body ..........................9 + 4.4. Order of Delivery ..........................................9 + 5. Info Packages ...................................................9 + 5.1. General ....................................................9 + 5.2. User Agent Behavior .......................................10 + 5.2.1. General ............................................10 + 5.2.2. UA Procedures ......................................10 + 5.2.3. Recv-Info Header Field Rules .......................11 + 5.2.4. Info Package Fallback Rules ........................12 + 5.3. REGISTER Processing .......................................12 + 6. Formal INFO Method Definition ..................................13 + 6.1. INFO Method ...............................................13 + 7. INFO Header Fields .............................................15 + 7.1. General ...................................................15 + 7.2. Info-Package Header Field .................................15 + 7.3. Recv-Info Header Field ....................................16 + 8. Info Package Considerations ....................................16 + 8.1. General ...................................................16 + 8.2. Appropriateness of Info Package Usage .....................16 + 8.3. INFO Request Rate and Volume ..............................16 + 8.4. Alternative Mechanisms ....................................17 + 8.4.1. Alternative SIP Signaling Plane Mechanisms .........17 + 8.4.2. Media Plane Mechanisms .............................18 + 8.4.3. Non-SIP-Related Mechanisms .........................19 + 9. Syntax .........................................................19 + 9.1. General ...................................................19 + 9.2. ABNF ......................................................19 + 10. Info Package Requirements .....................................20 + 10.1. General ..................................................20 + 10.2. Overall Description ......................................20 + 10.3. Applicability ............................................20 + 10.4. Info Package Name ........................................21 + 10.5. Info Package Parameters ..................................21 + 10.6. SIP Option-Tags ..........................................22 + + + +Holmberg, et al. Standards Track [Page 2] + +RFC 6086 INFO Framework January 2011 + + + 10.7. INFO Message Body Parts ..................................22 + 10.8. Info Package Usage Restrictions ..........................22 + 10.9. Rate of INFO Requests ....................................23 + 10.10. Info Package Security Considerations ....................23 + 10.11. Implementation Details ..................................23 + 10.12. Examples ................................................24 + 11. IANA Considerations ...........................................24 + 11.1. Update to Registration of SIP INFO Method ................24 + 11.2. Registration of the Info-Package Header Field ............24 + 11.3. Registration of the Recv-Info Header Field ...............24 + 11.4. Creation of the Info Packages Registry ...................25 + 11.5. Registration of the Info-Package Content-Disposition .....25 + 11.6. SIP Response Code 469 Registration .......................26 + 12. Examples ......................................................26 + 12.1. Indication of Willingness to Receive INFO Requests + for Info Packages ........................................26 + 12.1.1. Initial INVITE Request ............................26 + 12.1.2. Target Refresh ....................................27 + 12.2. INFO Request Associated with Info Package ................28 + 12.2.1. Single Payload ....................................28 + 12.2.2. Multipart INFO ....................................28 + 13. Security Considerations .......................................30 + 14. References ....................................................31 + 14.1. Normative References .....................................31 + 14.2. Informative References ...................................32 + Appendix A. Acknowledgements .....................................35 + +1. Introduction + + This document defines a method, INFO, for the Session Initiation + Protocol (SIP) [RFC3261]. + + The purpose of the INFO message is to carry application level + information between endpoints, using the SIP dialog signaling path. + Note that the INFO method is not used to update characteristics of a + SIP dialog or session, but to allow the applications that use the SIP + session to exchange information (which might update the state of + those applications). + + Use of the INFO method does not constitute a separate dialog usage. + INFO messages are always part of, and share the fate of, an invite + dialog usage [RFC5057]. INFO messages cannot be sent as part of + other dialog usages, or outside an existing dialog. + + This document also defines an Info Package mechanism. An Info + Package specification defines the content and semantics of the + information carried in an INFO message associated with the Info + Package. The Info Package mechanism also provides a way for user + + + +Holmberg, et al. Standards Track [Page 3] + +RFC 6086 INFO Framework January 2011 + + + agents (UAs) to indicate for which Info Packages they are willing to + receive INFO requests, and which Info Package a specific INFO request + is associated with. + + A UA uses the Recv-Info header field, on a per-dialog basis, to + indicate for which Info Packages it is willing to receive INFO + requests. A UA can indicate an initial set of Info Packages during + dialog establishment and can indicate a new set during the lifetime + of the invite dialog usage. + + NOTE: A UA can use an empty Recv-Info header field (a header field + without a value) to indicate that it is not willing to receive + INFO requests for any Info Package, while still informing other + UAs that it supports the Info Package mechanism. + + When a UA sends an INFO request, it uses the Info-Package header + field to indicate which Info Package is associated with the request. + One particular INFO request can only be associated with a single Info + Package. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Motivation + + A number of applications, standardized and proprietary, make use of + the INFO method as it was previously defined in RFC 2976 [RFC2976], + here referred to as "legacy INFO usage". These include but are not + limited to the following: + + o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part + (ISUP) in SIP message bodies. ITU-T and the Third Generation + Partnership Project (3GPP) have specified similar procedures. + + o [ECMA-355] specifies the encapsulation of "QSIG" in SIP message + bodies. + + o RFC 5022 [RFC5022] specifies how INFO is used as a transport + mechanism by the Media Server Control Markup Language (MSCML) + protocol. MSCML uses an option-tag in the Require header field to + ensure that the receiver understands the INFO content. + + o RFC 5707 [RFC5707] specifies how INFO is used as a transport + mechanism by the Media Server Markup Language (MSML) protocol. + + + + +Holmberg, et al. Standards Track [Page 4] + +RFC 6086 INFO Framework January 2011 + + + o Companies have been using INFO messages in order to request fast + video update. Currently, a standardized mechanism, based on the + Real-time Transport Control Protocol (RTCP), has been specified in + RFC 5168 [RFC5168]. + + o Companies have been using INFO messages in order to transport + Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are + proprietary and have not been standardized. + + Some legacy INFO usages are also recognized as being shortcuts to + more appropriate and flexible mechanisms. + + Furthermore, RFC 2976 did not define mechanisms that would enable a + SIP UA to indicate (1) the types of applications and contexts in + which the UA supports the INFO method or (2) the types of + applications and contexts with which a specific INFO message is + associated. + + Because legacy INFO usages do not have associated Info Packages, it + is not possible to use the Recv-Info and Info-Package header fields + with legacy INFO usages. That is, a UA cannot use the Recv-Info + header field to indicate for which legacy INFO usages it is willing + to receive INFO requests, and a UA cannot use the Info-Package header + field to indicate with which legacy INFO usage an INFO request is + associated. + + Due to the problems described above, legacy INFO usages often require + static configuration to indicate the types of applications and + contexts for which the UAs support the INFO method, and the way they + handle application information transported in INFO messages. This + has caused interoperability problems in the industry. + + To overcome these problems, the SIP Working Group has spent + significant discussion time over many years coming to agreement on + whether it was more appropriate to fix INFO (by defining a + registration mechanism for the ways in which it was used) or to + deprecate it altogether (with the usage described in RFC 3398 + [RFC3398] being grandfathered as the sole legitimate usage). + Although it required substantial consensus building and concessions + by those more inclined to completely deprecate INFO, the eventual + direction of the working group was to publish a framework for + registration of Info Packages as defined in this specification. + +3. Applicability and Backward Compatibility + + This document defines a method, INFO, for the Session Initiation + Protocol (SIP) [RFC3261], and an Info Package mechanism. This + document obsoletes RFC 2976 [RFC2976]. For backward compatibility, + + + +Holmberg, et al. Standards Track [Page 5] + +RFC 6086 INFO Framework January 2011 + + + this document also specifies a "legacy" mode of usage of the INFO + method that is compatible with the usage previously defined in + RFC 2976, here referred to as "legacy INFO Usage". + + For backward compatibility purposes, this document does not deprecate + legacy INFO usages, and does not mandate users to define Info + Packages for such usages. However: + + 1. A UA MUST NOT insert an Info-Package header field in a legacy + INFO request (as described in Section 4.2.1, an INFO request + associated with an Info Package always contains an Info-Package + header field). + + 2. Any new usage MUST use the Info Package mechanism defined in this + specification, since it does not share the issues associated with + legacy INFO usage, and since Info Packages can be registered with + IANA. + + 3. UAs are allowed to enable both legacy INFO usages and Info + Package usages as part of the same invite dialog usage, but UAs + SHALL NOT mix legacy INFO usages and Info Package usages in order + to transport the same application level information. If + possible, UAs SHALL prefer the usage of an Info Package. + +4. The INFO Method + +4.1. General + + The INFO method provides a mechanism for transporting application + level information that can further enhance a SIP application. + Section 8 gives more details on the types of applications for which + the use of INFO is appropriate. + + This section describes how a UA handles INFO requests and responses, + as well as the message bodies included in INFO messages. + +4.2. INFO Request + +4.2.1. INFO Request Sender + + An INFO request can be associated with an Info Package (see + Section 5), or associated with a legacy INFO usage (see Section 2). + + The construction of the INFO request is the same as any other + non-target refresh request within an existing invite dialog usage as + described in Section 12.2 of RFC 3261. + + + + + +Holmberg, et al. Standards Track [Page 6] + +RFC 6086 INFO Framework January 2011 + + + When a UA sends an INFO request associated with an Info Package, it + MUST include an Info-Package header field that indicates which Info + Package is associated with the request. A specific INFO request can + be used only for a single Info Package. + + When a UA sends an INFO request associated with a legacy INFO usage, + there is no Info Package associated with the request, and the UA MUST + NOT include an Info-Package header field in the request. + + The INFO request MUST NOT contain a Recv-Info header field. A UA can + only indicate a set of Info Packages for which it is willing to + receive INFO requests by using the SIP methods (and their responses) + listed in Section 5. + + A UA MUST NOT send an INFO request outside an invite dialog usage and + MUST NOT send an INFO request for an Info Package inside an invite + dialog usage if the remote UA has not indicated willingness to + receive that Info Package within that dialog. + + If a UA receives a 469 (Bad Info Package) response to an INFO + request, based on RFC 5057 [RFC5057], the response represents a + Transaction Only failure, and the UA MUST NOT terminate the invite + dialog usage. + + Due to the possibility of forking, the UA that sends the initial + INVITE request MUST be prepared to receive INFO requests from + multiple remote UAs during the early dialog phase. In addition, the + UA MUST be prepared to receive different Recv-Info header field + values from different remote UAs. + + NOTE: If the User Agent Server (UAS) (receiver of the initial + INVITE request) sends an INFO request just after it has sent the + response that creates the dialog, the UAS needs to be prepared for + the possibility that the INFO request will reach the User Agent + Client (UAC) before the dialog-creating response, and might + therefore be rejected by the UAC. In addition, an INFO request + might be rejected due to a race condition, if a UA sends the INFO + request at the same time that the remote UA sends a new set of + Info Packages for which it is willing to receive INFO requests. + +4.2.2. INFO Request Receiver + + If a UA receives an INFO request associated with an Info Package that + the UA has not indicated willingness to receive, the UA MUST send a + 469 (Bad Info Package) response (see Section 11.6), which contains a + Recv-Info header field with Info Packages for which the UA is willing + + + + + +Holmberg, et al. Standards Track [Page 7] + +RFC 6086 INFO Framework January 2011 + + + to receive INFO requests. The UA MUST NOT use the response to update + the set of Info Packages, but simply to indicate the current set. In + the terminology of multiple dialog usages [RFC5057], this represents + a Transaction Only failure, and does not terminate the invite dialog + usage. + + If a UA receives an INFO request associated with an Info Package, and + the message body part with Content-Disposition "Info-Package" (see + Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) + type that the UA supports but not in the context of that Info + Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media + Type) response. + + The UA MAY send other error responses, such as Request Failure (4xx), + Server Failure (5xx), and Global Failure (6xx), in accordance with + the error-handling procedures defined in RFC 3261. + + Otherwise, if the INFO request is syntactically correct and well + structured, the UA MUST send a 200 (OK) response. + + NOTE: If the application needs to reject the information that it + received in an INFO request, that needs to be done on the + application level. That is, the application needs to trigger a + new INFO request, which contains information that the previously + received application data was not accepted. Individual Info + Package specifications need to describe the details for such + procedures. + +4.2.3. SIP Proxies + + Proxies need no additional behavior beyond that described in RFC 3261 + to support INFO. + +4.3. INFO Message Body + +4.3.1. INFO Request Message Body + + The purpose of the INFO request is to carry application level + information between SIP UAs. The application information data is + carried in the payload of the message body of the INFO request. + + NOTE: An INFO request associated with an Info Package can also + include information associated with the Info Package using + Info-Package header field parameters. + + + + + + + +Holmberg, et al. Standards Track [Page 8] + +RFC 6086 INFO Framework January 2011 + + + If an INFO request associated with an Info Package contains a message + body part, the body part is identified by a Content-Disposition + header field "Info-Package" value. The body part can contain a + single MIME type, or it can be a multipart [RFC5621] that contains + other body parts associated with the Info Package. + + UAs MUST support multipart body parts in accordance with RFC 5621. + + NOTE: An INFO request can also contain other body parts that are + meaningful within the context of an invite dialog usage but are + not specifically associated with the INFO method and the + application concerned. + + When a UA supports a specific Info Package, the UA MUST also support + message body MIME types in accordance with that Info Package. + However, in accordance with RFC 3261, the UA still indicates the + supported MIME types using the Accept header. + +4.3.2. INFO Response Message Body + + A UA MUST NOT include a message body associated with an Info Package + in an INFO response. Message bodies associated with Info Packages + MUST only be sent in INFO requests. + + A UA MAY include a message body that is not associated with an Info + Package in an INFO response. + +4.4. Order of Delivery + + The Info Package mechanism does not define a delivery order + mechanism. Info Packages can rely on the CSeq header field [RFC3261] + to detect if an INFO request is received out of order. + + If specific applications need additional mechanisms for order of + delivery, those mechanisms, and related procedures, are specified as + part of the associated Info Package (e.g., the use of sequence + numbers within the application data). + +5. Info Packages + +5.1. General + + An Info Package specification defines the content and semantics of + the information carried in an INFO message associated with an Info + Package. The Info Package mechanism provides a way for UAs to + indicate for which Info Packages they are willing to receive INFO + requests, and with which Info Package a specific INFO request is + associated. + + + +Holmberg, et al. Standards Track [Page 9] + +RFC 6086 INFO Framework January 2011 + + +5.2. User Agent Behavior + +5.2.1. General + + This section describes how a UA handles Info Packages, how a UA uses + the Recv-Info header field, and how the UA acts in re-INVITE rollback + situations. + +5.2.2. UA Procedures + + A UA that supports the Info Package mechanism MUST indicate, using + the Recv-Info header field, the set of Info Packages for which it is + willing to receive INFO requests for a specific session. A UA can + list multiple Info Packages in a single Recv-Info header field, and + the UA can use multiple Recv-Info header fields. A UA can use an + empty Recv-Info header field, i.e., a header field without any header + field values. + + A UA provides its set of Info Packages for which it is willing to + receive INFO requests during the dialog establishment. A UA can + update the set of Info Packages during the invite dialog usage. + + If a UA is not willing to receive INFO requests for any Info + Packages, during dialog establishment or later during the invite + dialog usage, the UA MUST indicate this by including an empty + Recv-Info header field. This informs other UAs that the UA still + supports the Info Package mechanism. + + Example: If a UA has previously indicated Info Packages "foo" and + "bar" in a Recv-Info header field, and the UA during the lifetime of + the invite dialog usage wants to indicate that it does not want to + receive INFO requests for any Info Packages anymore, the UA sends a + message with an empty Recv-Info header field. + + Once a UA has sent a message with a Recv-Info header field containing + a set of Info Packages, the set is valid until the UA sends a new + Recv-Info header field containing a new, or empty, set of Info + Packages. + + Once a UA has indicated that it is willing to receive INFO requests + for a specific Info Package, and a dialog has been established, the + UA MUST be prepared to receive INFO requests associated with that + Info Package until the UA indicates that it is no longer willing to + receive INFO requests associated with that Info Package. + + For a specific dialog usage, a UA MUST NOT send an INFO request + associated with an Info Package until it has received an indication + that the remote UA is willing to receive INFO requests for that Info + + + +Holmberg, et al. Standards Track [Page 10] + +RFC 6086 INFO Framework January 2011 + + + Package, or after the UA has received an indication that the remote + UA is no longer willing to receive INFO requests associated with that + Info Package. + + NOTE: When a UA sends a message that contains a Recv-Info header + field with a new set of Info Packages for which the UA is willing + to receive INFO requests, the remote UA might, before it receives + the message, send an INFO request based on the old set of Info + Packages. In this case, the receiver of the INFO requests + rejects, and sends a 469 (Bad Info Package) response to, the INFO + request. + + If a UA indicates multiple Info Packages that provide similar + functionality, it is not possible to indicate a priority order of the + Info Packages, or to indicate that the UA wishes to only receive INFO + requests for one of the Info Packages. It is up to the application + logic associated with the Info Packages, and particular Info Package + specifications, to describe application behavior in such cases. + + For backward compatibility purposes, even if a UA indicates support + of the Info Package mechanism, it is still allowed to enable legacy + INFO usages. In addition, if a UA indicates support of the INFO + method using the Allow header field [RFC3261], it does not implicitly + indicate support of the Info Package mechanism. A UA MUST use the + Recv-Info header field in order to indicate that it supports the Info + Package mechanism. Likewise, even if a UA uses the Recv-Info header + field to indicate that it supports the Info Package mechanism, in + addition the UA still indicates support of the INFO method using the + Allow header. + + This document does not define a SIP option-tag [RFC3261] for the Info + Package mechanism. However, an Info Package specification can define + an option-tag associated with the specific Info Package, as described + in Section 10.6. + +5.2.3. Recv-Info Header Field Rules + + The text below defines rules on when a UA is required to include a + Recv-Info header field in SIP messages. Section 7.1 lists the SIP + methods for which a UA can insert a Recv-Info header field in + requests and responses. + + o The sender of an initial INVITE request MUST include a Recv-Info + header field in the initial INVITE request, even if the sender is + not willing to receive INFO requests associated with any Info + Package. + + + + + +Holmberg, et al. Standards Track [Page 11] + +RFC 6086 INFO Framework January 2011 + + + o The receiver of a request that contains a Recv-Info header field + MUST include a Recv-Info header field in a reliable 18x/2xx + response to the request, even if the request contains an empty + Recv-Info header field, and even if the header field value of the + receiver has not changed since the previous time it sent a + Recv-Info header field. + + o A UA MUST NOT include a Recv-Info header field in a response if + the associated request did not contain a Recv-Info header field. + + NOTE: In contrast to the rules for generating Session Description + Protocol (SDP) answers [RFC3264], the receiver of a request is not + restricted to generating its own set of Info Packages as a subset + of the Info Package set received in the Info-Package header field + of the request. + + As with SDP answers, the receiver can include the same Recv-Info + header field value in multiple responses (18x/2xx) for the same + INVITE/re-INVITE transaction, but the receiver MUST use the same + Recv-Info header field value (if included) in all responses for the + same transaction. + +5.2.4. Info Package Fallback Rules + + If the receiver of a request that contains a Recv-Info header field + rejects the request, both the sender and receiver of the request MUST + roll back to the set of Info Packages that was used before the + request was sent. This also applies to the case where the receiver + of an INVITE/re-INVITE request has included a Recv-Info header field + in a provisional response, but later rejects the request. + + NOTE: The dialog state rollback rules for Info Packages might + differ from the rules for other types of dialog state information + (SDP, target, etc.). + +5.3. REGISTER Processing + + This document allows a UA to insert a Recv-Info header field in a + REGISTER request. However, a UA SHALL NOT include a header value for + a specific Info Package unless the particular Info Package + specification describes how the header field value shall be + interpreted and used by the registrar, e.g., in order to determine + request targets. + + + + + + + + +Holmberg, et al. Standards Track [Page 12] + +RFC 6086 INFO Framework January 2011 + + + Rather than using the Recv-Info header field in order to determine + request targets, it is recommended to use more appropriate + mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this + document does not define a feature tag for the Info Package + mechanism, or a mechanism to define feature tags for specific Info + Packages. + +6. Formal INFO Method Definition + +6.1. INFO Method + + This document describes one new SIP method: INFO. This document + replaces the definition and registrations found in RFC 2976 + [RFC2976]. + + This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. + + Header field where INFO + -------------------------------------------- + Accept R o + Accept 415 o + Accept-Encoding R o + Accept-Encoding 2xx o + Accept-Encoding 415 c + Accept-Language R o + Accept-Language 2xx o + Accept-Language 415 o + Accept-Resource-Priority 2xx,417 o + Alert-Info - + Allow R o + Allow 405 m + Allow r o + Authentication-Info 2xx o + Authorization R o + Call-ID c m + Call-Info o + Contact - + Content-Disposition o + Content-Encoding o + Content-Language o + Content-Length o + Content-Type * + CSeq c m + Date o + Error-Info 3xx-6xx o + Expires - + From c m + Geolocation R o + + + +Holmberg, et al. Standards Track [Page 13] + +RFC 6086 INFO Framework January 2011 + + + Geolocation-Error r o + Max-Breadth R - + Max-Forwards R o + MIME-Version o + Min-Expires - + Organization - + Priority R - + Privacy o + Proxy-Authenticate 401 o + Proxy-Authenticate 407 m + Proxy-Authorization R o + Proxy-Require R o + Reason R o + Record-Route R o + Record-Route 2xx,18x o + Referred-By R o + Request-Disposition R o + Require o + Resource-Priority o + Retry-After R - + Retry-After 404,413,480,486 o + Retry-After 500,503 o + Retry-After 600,603 o + Route R o + Security-Client R o + Security-Server 421,494 o + Security-Verify R o + Server r o + Subject R o + Supported R o + Supported 2xx o + Timestamp o + To c m (w/ Tag) + Unsupported 420 o + User-Agent o + Via m + Warning r o + WWW-Authenticate 401 m + WWW-Authenticate 407 o + + Table 1: Summary of Header Fields + + + + + + + + + + +Holmberg, et al. Standards Track [Page 14] + +RFC 6086 INFO Framework January 2011 + + +7. INFO Header Fields + +7.1. General + + This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. + + Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD + ------------------------------------------------------------------ + Info-Package R - - - - - - - m* - - + Recv-Info R - - - m - o o - - o + Recv-Info 2xx - - - o** - - o***- - o*** + Recv-Info 1xx - - - o** - - - - - - + Recv-Info 469 - - - - - - - m* - - + Recv-Info r - - - o - - o - - o + + Header field where SUB NOT RFR + -------------------------------- + Info-Package R - - - + Recv-Info R - - - + Recv-Info 2xx - - - + Recv-Info 1xx - - - + Recv-Info 469 - - - + Recv-Info r - - - + + Table 2: INFO-Related Header Fields + + The support and usage of the Info-Package and Recv-Info header fields + are not applicable to UAs that only support legacy INFO usages. + + * Not applicable to INFO requests and responses associated with + legacy INFO usages. + + ** Mandatory in at least one reliable 18x/2xx response, if sent, to + the INVITE request, if the associated INVITE request contained a + Recv-Info header field. + + *** Mandatory if the associated request contained a Recv-Info header + field. + + As defined in Section 20 of RFC 3261, a "mandatory" header field MUST + be present in a request, and MUST be understood by the UAS receiving + the request. + +7.2. Info-Package Header Field + + This document adds "Info-Package" to the definition of the element + "message-header" in the SIP message grammar [RFC3261]. Section 4 + describes the Info-Package header field usage. + + + +Holmberg, et al. Standards Track [Page 15] + +RFC 6086 INFO Framework January 2011 + + + For the purposes of matching Info Package types indicated in + Recv-Info with those in the Info-Package header field value, one + compares the Info-package-name portion of the Info-package-type + portion of the Info-Package header field octet by octet with that of + the Recv-Info header field value. That is, the Info Package name is + case sensitive. Info-package-param is not part of the comparison- + checking algorithm. + + This document does not define values for Info-Package types. + Individual Info Package specifications define these values. + +7.3. Recv-Info Header Field + + This document adds Recv-Info to the definition of the element + "message-header" in the SIP message grammar [RFC3261]. Section 5 + describes the Recv-Info header field usage. + +8. Info Package Considerations + +8.1. General + + This section covers considerations to take into account when deciding + whether the usage of an Info Package is appropriate for transporting + application information for a specific use-case. + +8.2. Appropriateness of Info Package Usage + + When designing an Info Package, for application level information + exchange, it is important to consider: is signaling, using INFO + requests, within a SIP dialog, an appropriate mechanism for the use- + case? Is it because it is the most reasonable and appropriate + choice, or merely because "it's easy"? Choosing an inappropriate + mechanism for a specific use-case can cause negative effects in SIP + networks where the mechanism is used. + +8.3. INFO Request Rate and Volume + + INFO messages differ from many other sorts of SIP messages in that + they carry application information, and the size and rate of INFO + messages are directly determined by the application. This can cause + application information traffic to interfere with other traffic on + that infrastructure, or to self-interfere when data rates become too + high. + + There is no default throttling mechanism for INFO requests. Apart + from the SIP session establishment, the number of SIP messages + exchanged during the lifetime of a normal SIP session is rather + small. + + + +Holmberg, et al. Standards Track [Page 16] + +RFC 6086 INFO Framework January 2011 + + + Some applications, like those sending Dual-Tone Multi-Frequency + (DTMF) tones, can generate a burst of up to 20 messages per second. + Other applications, like constant GPS location updates, could + generate a high rate of INFO requests during the lifetime of the + invite dialog usage. + + A designer of an Info Package, and the application that uses it, need + to consider the impact that the size and the rate of the INFO + messages have on the network and on other traffic, since it normally + cannot be ensured that INFO messages will be carried over a + congestion-controlled transport protocol end-to-end. Even if an INFO + message is sent over such a transport protocol, a downstream SIP + entity might forward the message over a transport protocol that does + not provide congestion control. + + Furthermore, SIP messages tend to be relatively small, on the order + of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct + exchange of bulk data beyond these limits, especially if the headers + plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. + Appropriate mechanisms for such traffic include the Hypertext + Transfer Protocol (HTTP) [RFC2616], the Message Session Relay + Protocol (MSRP) [RFC4975], or other media plane data transport + mechanisms. + + RFC 5405 [RFC5405] provides additional guidelines for applications + using UDP that may be useful background reading. + +8.4. Alternative Mechanisms + +8.4.1. Alternative SIP Signaling Plane Mechanisms + +8.4.1.1. General + + This subsection describes some alternative mechanisms for + transporting application information on the SIP signaling plane, + using SIP messages. + +8.4.1.2. SUBSCRIBE/NOTIFY + + An alternative for application level interaction is to use + subscription-based events [RFC3265] that use the SIP SUBSCRIBE and + NOTIFY methods. Using that mechanism, a UA requests state + information, such as keypad presses from a device to an application + server, or key-map images from an application server to a device. + + + + + + + +Holmberg, et al. Standards Track [Page 17] + +RFC 6086 INFO Framework January 2011 + + + Event Packages [RFC3265] perform the role of disambiguating the + context of a message for subscription-based events. The Info Package + mechanism provides similar functionality for application information + exchange using invite dialog usages [RFC5057]. + + While an INFO request is always part of, and shares the fate of, an + existing invite dialog usage, a SUBSCRIBE request creates a separate + dialog usage [RFC5057], and is normally sent outside an existing + dialog usage. + + The subscription-based mechanism can be used by SIP entities to + receive state information about SIP dialogs and sessions, without + requiring the entities to be part of the route set of those dialogs + and sessions. + + As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies + and back-to-back user agents (B2BUAs), the resource impact caused by + the subscription dialogs needs to be considered. The number of + subscription dialogs per user also needs to be considered. + + As for any other SIP-signaling-plane-based mechanism for transporting + application information, the SUBSCRIBE/NOTIFY messages can put a + significant burden on intermediate SIP entities that are part of the + dialog route set, but do not have any interest in the application + information transported between the end users. + +8.4.1.3. MESSAGE + + The MESSAGE method [RFC3428] defines one-time instant message + exchange, typically for sending MIME contents for rendering to the + user. + +8.4.2. Media Plane Mechanisms + +8.4.2.1. General + + In SIP, media plane channels associated with SIP dialogs are + established using SIP signaling, but the data exchanged on the media + plane channel does not traverse SIP signaling intermediates, so if + there will be a lot of information exchanged, and there is no need + for the SIP signaling intermediaries to examine the information, it + is recommended to use a media plane mechanism, rather than a SIP- + signaling-based mechanism. + + A low-latency requirement for the exchange of information is one + strong indicator for using a media channel. Exchanging information + through the SIP routing network can introduce hundreds of + milliseconds of latency. + + + +Holmberg, et al. Standards Track [Page 18] + +RFC 6086 INFO Framework January 2011 + + +8.4.2.2. MRCP + + One mechanism for media plane exchange of application data is the + Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2], where a + media plane connection-oriented channel, such as a Transmission + Control Protocol (TCP) [RFC0793] or Stream Control Transmission + Protocol (SCTP) [RFC4960] stream is established. + +8.4.2.3. MSRP + + MSRP [RFC4975] defines session-based instant messaging as well as + bulk file transfer and other such large-volume uses. + +8.4.3. Non-SIP-Related Mechanisms + + Another alternative is to use a SIP-independent mechanism, such as + HTTP [RFC2616]. In this model, the UA knows about a rendezvous point + to which it can direct HTTP requests for the transfer of information. + Examples include encoding of a prompt to retrieve in the SIP Request + URI [RFC4240] or the encoding of a SUBMIT target in a VoiceXML + [W3C.REC-voicexml21-20070619] script. + +9. Syntax + +9.1. General + + This section describes the syntax extensions to the ABNF syntax + defined in RFC 3261 required for the INFO method, and adds + definitions for the Info-Package and Recv-Info header fields. The + previous sections describe the semantics. The ABNF defined in this + specification is conformant to RFC 5234 [RFC5234]. + +9.2. ABNF + + INFOm = %x49.4E.46.4F ; INFO in caps + Method =/ INFOm + + message-header =/ (Info-Package / Recv-Info) CRLF + Info-Package = "Info-Package" HCOLON Info-package-type + Recv-Info = "Recv-Info" HCOLON [Info-package-list] + Info-package-list = Info-package-type *( COMMA Info-package-type ) + Info-package-type = Info-package-name *( SEMI Info-package-param ) + Info-package-name = token + Info-package-param = generic-param + + + + + + + +Holmberg, et al. Standards Track [Page 19] + +RFC 6086 INFO Framework January 2011 + + +10. Info Package Requirements + +10.1. General + + This section provides guidance on how to define an Info Package, and + what information needs to exist in an Info Package specification. + + If, for an Info Package, there is a need to extend or modify the + behavior described in this document, that behavior MUST be described + in the Info Package specification. It is bad practice for Info + Package specifications to repeat procedures defined in this document, + unless needed for purposes of clarification or emphasis. + + Info Package specifications MUST NOT weaken any behavior designated + with "SHOULD" or "MUST" in this specification. However, Info Package + specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" + requirements to "MUST" if applications associated with the Info + Package require it. + + Info Package specifications MUST address the issues defined in the + following subsections, or document why an issue is not applicable to + the specific Info Package. + + Section 8.4 describes alternative mechanisms, which should be + considered as part of the process for solving a specific use-case, + when there is a need for transporting application information. + +10.2. Overall Description + + The Info Package specification MUST contain an overall description of + the Info Package: what type of information is carried in INFO + requests associated with the Info Package, and for what types of + applications and functionalities UAs can use the Info Package. + + If the Info Package is defined for a specific application, the Info + Package specification MUST state which application UAs can use the + Info Package with. + +10.3. Applicability + + The Info Package specification MUST describe why the Info Package + mechanism, rather than some other mechanism, has been chosen for the + specific use-case to transfer application information between SIP + endpoints. Common reasons can be a requirement for SIP proxies or + + + + + + + +Holmberg, et al. Standards Track [Page 20] + +RFC 6086 INFO Framework January 2011 + + + back-to-back user agents (B2BUAs) to see the transported application + information (which would not be the case if the information was + transported on a media path), or that it is not seen as feasible to + establish separate dialogs (subscription) in order to transport the + information. + + Section 8 provides more information and describes alternative + mechanisms that one should consider for solving a specific use-case. + +10.4. Info Package Name + + The Info Package specification MUST define an Info Package name, + which UAs use as a header field value (e.g., "infoX") to identify the + Info Package in the Recv-Info and Info-Package header fields. The + header field value MUST conform to the ABNF defined in Section 9.2. + + The Info Package mechanism does not support package versioning. + Specific Info Package message body payloads can contain version + information, which is handled by the applications associated with the + Info Package. However, such a feature is outside the scope of the + generic Info Package mechanism. + + NOTE: Even if an Info Package name contains version numbering + (e.g., foo_v2), the Info Package mechanism does not distinguish a + version number from the rest of the Info Package name. + +10.5. Info Package Parameters + + The Info Package specification MAY define Info Package parameters, + which can be used in the Recv-Info or Info-Package header fields, + together with the header field value that indicates the Info Package + name (see Section 10.4). + + The Info Package specification MUST define the syntax and semantics + of the defined parameters. In addition, the specification MUST + define whether a specific parameter is applicable to only the + Recv-Info header field, only the Info-Package header field, or to + both. + + By default, an Info Package parameter is only applicable to the Info + Package for which the parameter has been explicitly defined. + + + + + + + + + + +Holmberg, et al. Standards Track [Page 21] + +RFC 6086 INFO Framework January 2011 + + + Info Package parameters defined for specific Info Packages can share + the name with parameters defined for other Info Packages, but the + parameter semantics are specific to the Info Package for which they + are defined. However, when choosing the name of a parameter, it is + RECOMMENDED to not use the same name as an existing parameter for + another Info Package, if the semantics of the parameters are + different. + +10.6. SIP Option-Tags + + The Info Package specification MAY define SIP option-tags, which can + be used as described in RFC 3261. + + The registration requirements for option-tags are defined in RFC 5727 + [RFC5727]. + +10.7. INFO Message Body Parts + + The Info Package specification MUST define which message body part + MIME types are associated with the Info Package. The specification + MUST either define those body parts, including the syntax, semantics, + and MIME type of each body part, or refer to other documents that + define the body parts. + + If multiple message body part MIME types are associated with an Info + Package, the Info Package specification MUST define whether UAs need + to use multipart body parts, in order to include multiple body parts + in a single INFO request. + +10.8. Info Package Usage Restrictions + + If there are restrictions on how UAs can use an Info Package, the + Info Package specification MUST document such restrictions. + + There can be restrictions related to whether UAs are allowed to send + overlapping (outstanding) INFO requests associated with the Info + Package, or whether the UA has to wait for the response for a + previous INFO request associated with the same Info Package. + + There can also be restrictions related to whether UAs need to support + and use other SIP extensions and capabilities when they use the Info + Package, and if there are restrictions related to how UAs can use the + Info Package together with other Info Packages. + + + + + + + + +Holmberg, et al. Standards Track [Page 22] + +RFC 6086 INFO Framework January 2011 + + + As the SIP stack might not be aware of Info Package specific + restrictions, it cannot be assumed that overlapping requests would be + rejected. As defined in Section 4.2.2, UAs will normally send a 200 + (OK) response to an INFO request. The application logic associated + with the Info Package needs to handle situations where UAs do not + follow restrictions associated with the Info Package. + +10.9. Rate of INFO Requests + + If there is a maximum or minimum rate at which UAs can send INFO + requests associated with the Info Package within a dialog, the Info + Package specification MUST document the rate values. + + If the rates can vary, the Info Package specification MAY define Info + Package parameters that UAs can use to indicate or negotiate the + rates. Alternatively, the rate information can be part of the + application data information associated with the Info Package. + +10.10. Info Package Security Considerations + + If the application information carried in INFO requests associated + with the Info Package requires a certain level of security, the Info + Package specification MUST describe the mechanisms that UAs need to + use in order to provide the required security. + + If the Info Package specification does not require any additional + security, other than what the underlying SIP protocol provides, this + MUST be stated in the Info Package specification. + + NOTE: In some cases, it may not be sufficient to mandate Transport + Layer Security (TLS) [RFC5246] in order to secure the Info Package + payload, since intermediaries will have access to the payload, and + because beyond the first hop, there is no way to assure subsequent + hops will not forward the payload in clear text. The best way to + ensure secure transport at the application level is to have the + security at the application level. One way of achieving this is + to use end-to-end security techniques such as Secure/Multipurpose + Internet Mail Extensions (S/MIME) [RFC5751]. + +10.11. Implementation Details + + It is strongly RECOMMENDED that the Info Package specification define + the procedure regarding how implementors shall implement and use the + Info Package, or refer to other locations where implementors can find + that information. + + + + + + +Holmberg, et al. Standards Track [Page 23] + +RFC 6086 INFO Framework January 2011 + + + NOTE: Sometimes an Info Package designer might choose to not + reveal the details of an Info Package. However, in order to allow + multiple implementations to support the Info Package, Info Package + designers are strongly encouraged to provide the implementation + details. + +10.12. Examples + + It is RECOMMENDED that the Info Package specification provide + demonstrative message flow diagrams, paired with complete messages + and message descriptions. + + Note that example flows are by definition informative, and do not + replace normative text. + +11. IANA Considerations + +11.1. Update to Registration of SIP INFO Method + + IANA updated the existing registration in the "Methods and Response + Codes" registry under "Session Initiation Protocol (SIP) Parameters" + from: + + Method: INFO + Reference: [RFC2976] + + to: + + Method: INFO + Reference: [RFC6086] + +11.2. Registration of the Info-Package Header Field + + IANA added the following new SIP header field in the "Header Fields" + registry under "Session Initiation Protocol (SIP) Parameters". + + Header Name: Info-Package + Compact Form: (none) + Reference: [RFC6086] + +11.3. Registration of the Recv-Info Header Field + + IANA added the following new SIP header field in the "Header Fields" + registry under "Session Initiation Protocol (SIP) Parameters". + + Header Name: Recv-Info + Compact Form: (none) + Reference: [RFC6086] + + + +Holmberg, et al. Standards Track [Page 24] + +RFC 6086 INFO Framework January 2011 + + +11.4. Creation of the Info Packages Registry + + IANA created the following registry under "Session Initiation + Protocol (SIP) Parameters": + + Info Packages + + Note to the reviewer: + + The policy for review of Info Packages is "Specification + Required", as defined in [RFC5226]. This policy was selected + because Info Packages re-use an existing mechanism for transport + of arbitrary session-associated data within SIP; therefore, new + Info Packages do not require the more extensive review required by + specifications that make fundamental protocol changes. However, + the reviewer is expected to verify that each Info Package + registration is in fact consistent with this definition. Changes + to the SIP protocol and state machine are outside of the allowable + scope for an Info Package and are governed by other procedures + including RFC 5727 and its successors, if any. + + The following data elements populate the Info Packages Registry. + + o Info Package Name: The Info Package Name is a case-sensitive + token. In addition, IANA shall not register multiple Info Package + names that have identical case-insensitive values. + + o Reference: A reference to a specification that describes the Info + Package. + + The initial population of this table shall be: + + Name Reference + +11.5. Registration of the Info-Package Content-Disposition + + IANA added the following new header field value to the "Mail Content + Disposition Values" registry under "Mail Content Disposition Values + and Parameters". + + Name: info-package + Description: The body contains information associated with an + Info Package + Reference: RFC6086 + + + + + + + +Holmberg, et al. Standards Track [Page 25] + +RFC 6086 INFO Framework January 2011 + + +11.6. SIP Response Code 469 Registration + + IANA registered the following new response code in the "Session + Initiation Protocol (SIP) Parameters" -- "Response Codes" registry. + + Response Code: 469 + Default Reason Phrase: Bad Info Package + Reference: RFC6086 + +12. Examples + +12.1. Indication of Willingness to Receive INFO Requests for Info + Packages + +12.1.1. Initial INVITE Request + + The UAC sends an initial INVITE request, where the UAC indicates that + it is willing to receive INFO requests for Info Packages P and R. + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 + Max-Forwards: 70 + To: Bob <sip:bob@example.com> + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.example.com + CSeq: 314159 INVITE + Recv-Info: P, R + Contact: <sip:alice@pc33.example.com> + Content-Type: application/sdp + Content-Length: ... + + ... + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 26] + +RFC 6086 INFO Framework January 2011 + + + The UAS sends a 200 (OK) response back to the UAC, where the UAS + indicates that it is willing to receive INFO requests for Info + Packages R and T. + + SIP/2.0 200 OK + Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776; + received=192.0.2.1 + To: Bob <sip:bob@example.com>;tag=a6c85cf + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.example.com + CSeq: 314159 INVITE + Contact: <sip:bob@pc33.example.com> + Recv-Info: R, T + Content-Type: application/sdp + Content-Length: ... + + ... + + The UAC sends an ACK request. + + ACK sip:bob@pc33.example.com SIP/2.0 + Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 + Max-Forwards: 70 + To: Bob <sip:bob@example.com>;tag=a6c85cf + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.example.com + CSeq: 314159 ACK + Content-Length: 0 + +12.1.2. Target Refresh + + The UAC sends an UPDATE request within the invite dialog usage, where + the UAC indicates (using an empty Recv-Info header field) that it is + not willing to receive INFO requests for any Info Packages. + + UPDATE sip:bob@pc33.example.com SIP/2.0 + Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 + Max-Forwards: 70 + To: Bob <sip:bob@example.com>;tag=a6c85cf + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.example.com + CSeq: 314163 UPDATE + Recv-Info: + Contact: <sip:alice@pc33.example.com> + Content-Type: application/sdp + Content-Length: ... + + ... + + + +Holmberg, et al. Standards Track [Page 27] + +RFC 6086 INFO Framework January 2011 + + + The UAS sends a 200 (OK) response back to the UAC, where the UAS + indicates that it is willing to receive INFO requests for Info + Packages R and T. + + SIP/2.0 200 OK + Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893; + received=192.0.2.1 + To: Bob <sip:bob@example.com>;tag=a6c85cf + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-ID: a84b4c76e66710@pc33.example.com + CSeq: 314163 INVITE + Contact: <sip:alice@pc33.example.com> + Recv-Info: R, T + Content-Type: application/sdp + Content-Length: ... + + ... + +12.2. INFO Request Associated with Info Package + +12.2.1. Single Payload + + The UA sends an INFO request associated with Info Package "foo". + + INFO sip:alice@pc33.example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef + To: Bob <sip:bob@example.com>;tag=a6c85cf + From: Alice <sip:alice@example.com>;tag=1928301774 + Call-Id: a84b4c76e66710@pc33.example.com + CSeq: 314333 INFO + Info-Package: foo + Content-type: application/foo + Content-Disposition: Info-Package + Content-length: 24 + + I am a foo message type + +12.2.2. Multipart INFO + +12.2.2.1. Non-Info Package Body Part + + SIP extensions can sometimes add body part payloads into an INFO + request, independent of the Info Package. In this case, the Info + Package payload gets put into a multipart MIME body, with a + Content-Disposition header field that indicates which body part is + associated with the Info Package. + + + + + +Holmberg, et al. Standards Track [Page 28] + +RFC 6086 INFO Framework January 2011 + + + INFO sip:alice@pc33.example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef + To: Alice <sip:alice@example.net>;tag=1234567 + From: Bob <sip:bob@example.com>;tag=abcdefg + Call-Id: a84b4c76e66710@pc33.example.com + CSeq: 314400 INFO + Info-Package: foo + Content-Type: multipart/mixed;boundary="theboundary" + Content-Length: ... + + --theboundary + Content-Type: application/mumble + ... + + <mumble stuff> + + --theboundary + Content-Type: application/foo-x + Content-Disposition: Info-Package + Content-length: 59 + + I am a foo-x message type, and I belong to Info Package foo + --theboundary-- + +12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body + Part + + Multiple body part payloads can be associated with a single Info + Package. In this case, the body parts are put into a multipart MIME + body, with a Content-Disposition header field that indicates which + body part is associated with the Info Package. + + INFO sip:alice@pc33.example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef + To: Alice <sip:alice@example.net>;tag=1234567 + From: Bob <sip:bob@example.com>;tag=abcdefg + Call-Id: a84b4c76e66710@pc33.example.com + CSeq: 314423 INFO + Info-Package: foo + Content-Type: multipart/mixed;boundary="theboundary" + Content-Disposition: Info-Package + Content-Length: ... + + --theboundary + Content-Type: application/foo-x + Content-length: 59 + + + + + +Holmberg, et al. Standards Track [Page 29] + +RFC 6086 INFO Framework January 2011 + + + I am a foo-x message type, and I belong to Info Package foo + + <mumble stuff> + + --theboundary + Content-Type: application/foo-y + Content-length: 59 + + I am a foo-y message type, and I belong to Info Package foo + --theboundary-- + +12.2.2.3. Info Package with Single Body Part inside Multipart Body Part + + The body part payload associated with the Info Package can have a + Content-Disposition header field value other than "Info-Package". In + this case, the body part is put into a multipart MIME body, with a + Content-Disposition header field that indicates which body part is + associated with the Info Package. + + INFO sip:alice@pc33.example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef + To: Alice <sip:alice@example.net>;tag=1234567 + From: Bob <sip:bob@example.com>;tag=abcdefg + Call-Id: a84b4c76e66710@pc33.example.com + CSeq: 314423 INFO + Info-Package: foo + Content-Type: multipart/mixed;boundary="theboundary" + Content-Disposition: Info-Package + Content-Length: ... + + --theboundary + Content-Type: application/foo-x + Content-Disposition: icon + Content-length: 59 + + I am a foo-x message type, and I belong to Info Package foo + --theboundary-- + +13. Security Considerations + + By eliminating multiple usages of INFO messages without adequate + community review, and by eliminating the possibility of rogue SIP UAs + confusing another UA by purposely sending unrelated INFO requests, we + expect this document's clarification of the use of INFO to improve + the security of the Internet. While rogue UAs can still send + unrelated INFO requests, this mechanism enables the UAS and other + security devices to associate INFO requests with Info Packages that + have been negotiated for a session. + + + +Holmberg, et al. Standards Track [Page 30] + +RFC 6086 INFO Framework January 2011 + + + If the content of the Info Package payload is private, UAs will need + to use end-to-end encryption, such as S/MIME, to prevent access to + the content. This is particularly important, as transport of INFO is + likely not to be end-to-end, but through SIP proxies and back-to-back + user agents (B2BUAs), which the user may not trust. + + The INFO request transports application level information. One + implication of this is that INFO messages may require a higher level + of protection than the underlying SIP dialog signaling. In + particular, if one does not protect the SIP signaling from + eavesdropping or authentication and repudiation attacks, for example + by using TLS transport, then the INFO request and its contents will + be vulnerable as well. Even with SIP/TLS, any SIP hop along the path + from UAC to UAS can view, modify, or intercept INFO requests, as they + can with any SIP request. This means some applications may require + end-to-end encryption of the INFO payload, beyond, for example, hop- + by-hop protection of the SIP signaling itself. Since the application + dictates the level of security required, individual Info Packages + have to enumerate these requirements. In any event, the Info Package + mechanism described by this document provides the tools for such + secure, end-to-end transport of application data. + + One interesting property of Info Package usage is that one can re-use + the same digest-challenge mechanism used for INVITE-based + authentication for the INFO request. For example, one could use a + quality-of-protection (qop) value of authentication with integrity + (auth-int), to challenge the request and its body, and prevent + intermediate devices from modifying the body. However, this assumes + the device that knows the credentials in order to perform the INVITE + challenge is still in the path for the INFO request, or that the far- + end UAS knows such credentials. + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + + + + + +Holmberg, et al. Standards Track [Page 31] + +RFC 6086 INFO Framework January 2011 + + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC5621] Camarillo, G., "Message Body Handling in the Session + Initiation Protocol (SIP)", RFC 5621, September 2009. + + [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process + for the Session Initiation Protocol (SIP) and the Real- + time Applications and Infrastructure Area", BCP 67, + RFC 5727, March 2010. + +14.2. Informative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, + October 2000. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. + + [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, + "Integrated Services Digital Network (ISDN) User Part + (ISUP) to Session Initiation Protocol (SIP) Mapping", + RFC 3398, December 2002. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, August 2004. + + [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol + for Telephones (SIP-T): Context and Architectures", + BCP 63, RFC 3372, September 2002. + + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific + Event Notification", RFC 3265, June 2002. + + + + +Holmberg, et al. Standards Track [Page 32] + +RFC 6086 INFO Framework January 2011 + + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., + and D. Gurle, "Session Initiation Protocol (SIP) Extension + for Instant Messaging", RFC 3428, December 2002. + + [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network + Media Services with SIP", RFC 4240, December 2005. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message + Session Relay Protocol (MSRP)", RFC 4975, September 2007. + + [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server + Control Markup Language (MSCML) and Protocol", RFC 5022, + September 2007. + + [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session + Initiation Protocol", RFC 5057, November 2007. + + [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for + Media Control", RFC 5168, March 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines + for Application Designers", BCP 145, RFC 5405, + November 2008. + + [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup + Language (MSML)", RFC 5707, February 2010. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [W3C.REC-voicexml21-20070619] + Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M., + Carter, J., Burke, D., Baggia, P., Candell, E., Burnett, + D., McGlashan, S., and A. Lee, "Voice Extensible Markup + Language (VoiceXML) 2.1", World Wide Web Consortium + Recommendation REC-voicexml21-20070619, June 2007, + <http://www.w3.org/TR/2007/REC-voicexml21-20070619>. + + + + + + + +Holmberg, et al. Standards Track [Page 33] + +RFC 6086 INFO Framework January 2011 + + + [SPEECHSC-MRCPv2] + Burnett, D. and S. Shanmugham, "Media Resource Control + Protocol Version 2 (MRCPv2)", Work in Progress, + November 2010. + + [ECMA-355] + "Standard ECMA-355 Corporate Telecommunication Networks - + Tunnelling of QSIG over SIP", ECMA http:// + www.ecma-international.org/publications/standards/ + Ecma-355.htm, June 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 34] + +RFC 6086 INFO Framework January 2011 + + +Appendix A. Acknowledgements + + The work on this document was influenced by "The Session Initiation + Protocol (SIP) INFO Considered Harmful" (26 December 2002) written by + Jonathan Rosenberg, and by "Packaging and Negotiation of INFO Methods + for the Session Initiation Protocol" (15 January 2003) written by + Dean Willis. + + The following individuals have been involved in the work, and have + provided input and feedback on this document: + + Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben + Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris + Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean + Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon + Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James + Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Jonathan + Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, + Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul + Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, + Robert Sparks, Roland Jesske, Roni Even, Salvatore Loreto, Sam + Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit + Garg, and Xavier Marjoum. + + John Elwell and Francois Audet helped with QSIG references. In + addition, Francois Audet provided text for the revised abstract. + Keith Drage provided comments and helped immensely with Table 1. + + Arun Arunachalam, Brett Tate, John Elwell, Keith Drage, and Robert + Sparks provided valuable feedback during the working group last call + process, in order to prepare this document for publication. + + Adam Roach, Dean Willis, John Elwell, and Paul Kyzivat provided + valuable input in order to sort out the message body part usage for + Info Packages. + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 35] + +RFC 6086 INFO Framework January 2011 + + +Authors' Addresses + + Christer Holmberg + Ericsson + Hirsalantie 11 + Jorvas, 02420 + Finland + + EMail: christer.holmberg@ericsson.com + + + Eric W. Burger + Georgetown University + + EMail: eburger@standardstrack.com + URI: http://www.standardstrack.com + + + Hadriel Kaplan + Acme Packet + 100 Crosby Drive + Bedford, MA 01730 + USA + + EMail: hkaplan@acmepacket.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 36] + |