--- 1/draft-ietf-sipcore-info-events-07.txt 2010-05-19 11:12:53.000000000 +0200 +++ 2/draft-ietf-sipcore-info-events-08.txt 2010-05-19 11:12:53.000000000 +0200 @@ -1,113 +1,106 @@ SIPCORE C. Holmberg Internet-Draft Ericsson -Obsoletes: RFC 2976 E. Burger -(if approved) NeuStar, Inc. -Intended status: Standards Track H. Kaplan -Expires: August 5, 2010 Acme Packet - February 1, 2010 +Obsoletes: 2976 (if approved) E. Burger +Intended status: Standards Track NeuStar, Inc. +Expires: November 20, 2010 H. Kaplan + Acme Packet + May 19, 2010 Session Initiation Protocol (SIP) INFO Method and Package Framework - draft-ietf-sipcore-info-events-07 + draft-ietf-sipcore-info-events-08 Abstract This document defines a method, INFO, for the Session Initiation - Protocol (SIP) [RFC3261], and an Info Package mechanism. The - document obsoletes [RFC2976]. For backward compatibility the - document also specifies a "legacy" mode of usage of the INFO method - that is compatible with the usage previously defined in [RFC2976], - referred to as "legacy INFO Usage" in this document. + Protocol (SIP), and an Info Package mechanism. The document + obsoletes RFC 2976. For backward compatibility the 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. 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 5, 2010. + This Internet-Draft will expire on November 20, 2010. Copyright Notice Copyright (c) 2010 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. + 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 - 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 - 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 - 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 5 + 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 6 + 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 7 + 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 7 + 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 7 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 - 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 - 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 - 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 - 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 - 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 - 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 - 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 8 + 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 8 + 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 10 + 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 10 + 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 11 + 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11 + 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 - 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 - 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 - 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 - 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 - 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 - 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 - 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 - 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 - 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14 + 7. Info Package Considerations . . . . . . . . . . . . . . . . . 14 + 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14 + 7.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15 + 7.3.1. Alternative SIP signaling plane mechanisms . . . . . . 15 + 7.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16 + 7.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 + 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. Co-existence with Info Package based INFO usage . . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 @@ -138,23 +131,24 @@ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 + A.7. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 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 which use the @@ -234,21 +228,21 @@ 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 4. 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 + If a UA receives a 469 (Bad Info Package) response to an INFO request, based on [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 which 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 UAS (receiver of the initial INVITE request) sends an @@ -257,47 +251,48 @@ the 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 as the remote UA sends a new set of Info Packages for which it is willing to receive INFO requests. 3.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 + 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 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 3.3.1) has a 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. + Section 3.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 in [RFC3261]. 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 which it received in an INFO request, that needs to be done on the application - level. Ie 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. + level. I.e. 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. 3.2.3. SIP Proxies Proxies need no additional behavior beyond that described in [RFC3261] to support INFO. 3.3. INFO Message Body 3.3.1. INFO Request Message Body @@ -363,24 +358,25 @@ 4.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. 4.2.2. UA Procedures A UA which 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. 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, ie a header field without any header field values. + 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. @@ -407,39 +403,39 @@ that the remote UA is willing to receive INFO requests for that Info 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 which 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. + 469 (Bad Info Package) response to, the INFO request. If a UA indicates multiple Info Packages, which 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 specific Info Package specifications, to describe application behavior in such cases. For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO - usages Appendix A. 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. + usages Section 9. 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. 4.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 6.1 lists the SIP @@ -460,23 +456,23 @@ associated request did not contain a Recv-Info header field. NOTE: Different from the rules for generating SDP answers [RFC3264], the receiver of a request which contains a set of Info Packages is not restricted to generate its own set of Info Packages as a subset of the Info Package set received in the Info Package header field of the request. Similar to 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 NOT include a - Recv-Info header field value which is different from a value that the - receiver has already included in a response for the same transaction. + 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. 4.2.4. Info Package fallback rules If the receiver of a request which 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 which 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. @@ -612,20 +609,24 @@ * 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 [RFC3261], a "mandatory" + header field MUST be present in a request, and MUST be understood + by the UAS receiving the request." + 6.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 3 describes the Info-Package header field usage. 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 @@ -653,49 +654,71 @@ 7.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. -7.3. INFO Request Rate and Volume +7.3. Alternative Mechanisms + +7.3.1. Alternative SIP signaling plane mechanisms + +7.3.1.1. General + + This subsection describes some alternative mechanisms for + transporting application information on the SIP signaling plane, + using SIP messages. + +7.3.1.2. 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 the INFO + message is 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 a normal SIP session is rather small. - Some applications, like sending of 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. + Some applications, like sending of 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 UDP MTU [RFC0768]. Appropriate mechanisms for - such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media - plane data transport mechanisms. - -7.4. Alternative Mechanisms - -7.4.1. Alternative SIP signaling plane mechanisms - -7.4.1.1. General + 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. - This subsection describes some alternative mechanisms for - transporting application information on the SIP signaling plane, - using SIP messages. + RFC 5405 [RFC5405] provides additional guidelines for applications + using UDP that may be useful background reading. -7.4.1.2. SUBSCRIBE/NOTIFY +7.3.1.3. SUBSCRIBE/NOTIFY An alternative for application level interaction is to use subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and NOTIFY methods. Using that mechanism, a UA requests state information, such as key pad presses from a device to an application server or key map images from an application server to a device. 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 @@ -715,56 +738,57 @@ and 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 which are part of the dialog route set, but do not have any interest in the application information transported between the end users. -7.4.1.3. MESSAGE +7.3.1.4. MESSAGE The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user. -7.4.2. Media Plane Mechanisms +7.3.2. Media Plane Mechanisms -7.4.2.1. General +7.3.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. 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. -7.4.2.2. MRCPv2 +7.3.2.2. MRCP - One mechanism for media plane exchange of application data is MRCPv2 - [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented - channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is - established. + One mechanism for media plane exchange of application data is the + Media Resource Control Protocol (MRCP) [I-D.ietf-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. -7.4.2.3. MRSP +7.3.2.3. MRSP MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses. -7.4.3. Non-SIP related mechanisms +7.3.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 direct HTTP requests to for the transfer of information. Examples include encoding of a prompt to retrieve in the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- voicexml21-20070619] script. 8. Syntax @@ -792,22 +816,24 @@ 9. Legacy INFO Usage 9.1. General A number of applications, standardized and proprietary, make use of the INFO method as it was previously defined in [RFC2976], referred to as "legacy INFO usage". For backward compatibility purpose, this document does not deprecate such usages, and does not mandate users to define Info Packages for - such usages. However, any new usage of INFO SHALL use the Info - Package mechanism defined in this specification. + such usages. However, it is strongly RECOMMENDED that any new usage + uses 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. 9.2. Problems While legacy INFO usage has been widely adopted for specific application use cases, [RFC2976] did not define a mechanism for SIP UAs to indicate for which types of applications and contexts they support the INFO method. In addition, [RFC2976] did not provide a mechanism to explicitly indicate the type of application and context for which a specific INFO message is associated. @@ -830,28 +856,34 @@ Due to the problems described above, legacy INFO usages often require static configuration about for what type of applications and contexts UAs support the INFO method, and the way they handle application information transported in INFO messages. That has caused interoperability problems in the industry. Therefore, a need for a well defined and documented description of what the information sent in the INFO is used for has been identified. This situation is analogous to the context issue in Internet Mail [RFC3458]. + Section 4.1 describes how the Info Package mechanisms solves the + issues associated with legacy INFO usages. + 9.3. Co-existence with Info Package based INFO usage As described in Section 3, an INFO request associated with an Info Package always contains an Info-Package header field. A UA MUST NOT insert an Info-Package header field in a legacy INFO request. UAs are allowed to enable both legacy INFO usages and Info Package - usages as part of the same invite dialog usage. + usages as part of the same invite dialog usage. However, 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. See Appendix A for examples of existing legacy INFO usages. 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. @@ -864,21 +896,21 @@ Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Packages specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength 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 for the specific Info Package. - Section 7.4 describes alternative mechanisms, which should be + Section 7.3 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 are carried in INFO requests associated with the Info Package, and for what type of applications and functionalities UAs can use the Info Package. @@ -927,32 +958,35 @@ 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 only applicable to the Recv- Info header field, the Info-Package header field, or both. By default, an Info Package parameter is only applicable for the Info Package for which the parameter has been explicitly defined. - NOTE: 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. + 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 [RFC3261]. The registration requirements for option tags are defined in - [I-D.peterson-rai-rfc3427bis]. + [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, which include the syntax, semantics and MIME type of the each body part, or refer to other documents which define the body parts. If multiple message body part MIME types are associated with an Info @@ -989,21 +1023,21 @@ 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 certain level of security, the Info + 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, it MUST be stated in the Info Package specification. NOTE: In some cases, it may not be sufficient to mandate TLS in order to secure the Info Package payload, since intermediaries will have access to the payload, and beyond the first hop, there is no way to @@ -1077,25 +1111,25 @@ 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, and 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 - [I-D.peterson-rai-rfc3427bis] and its successors, if any. + and are governed by other procedures including [RFC5727] and its + successors, if any. The following data elements populate the Info Package Registry. - o Info Package Name: The Info Package Name is a case insensitive + 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 which describes the Info Package. The initial population of this table shall be: Name Reference 11.5. Registration of the Info-Package Content-Disposition @@ -1105,21 +1139,21 @@ Name: info-package Description: the body contains information associated with an Info Package Reference: RFCXXXX 11.6. SIP Response Code 469 Registration Please register the following new response code in the Session Initiation Protocol Parameters - Response Codes registry. Response Code: 469 - Default Reason Phrase: Bad INFO Package + Default Reason Phrase: Bad Info Package Reference: RFCXXXX 12. Examples 12.1. Indication for which Info Packages UAs are willing to receive INFO requests 12.1.1. Initial INVITE request The UAC sends an initial INVITE request, where the UAC indicates that @@ -1316,25 +1350,26 @@ 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 for rogue SIP UAs from 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. Whilst rogue UAs can still - send unrelated INFO requests, this mechanism provides mechanisms for - which the UAS and other security devices can filter for approved Info - Packages. + requests, as described in Section 9.2, we expect this document's + clarification of the use of INFO to improve the security of the + Internet. Whilst rogue UAs can still send unrelated INFO requests, + this mechanism provides mechanisms for which the UAS and other + security devices can associate INFO requests with Info Packages that + have been negotiated for a session. 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 (B2BUA's), which the user may not trust. The INFO request transports application level information. One implication of this is INFO messages may require a higher level of protection than the underlying SIP dialog signaling. In particular, @@ -1376,20 +1411,25 @@ Specifications: ABNF", STD 68, RFC 5234, January 2008. [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 @@ -1432,91 +1472,93 @@ [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. - [I-D.peterson-rai-rfc3427bis] - Peterson, J., Jennings, C., and R. Sparks, "Change Process - for the Session Initiation Protocol (SIP) and the Real- - time Applications and Infrastructure Area", - draft-peterson-rai-rfc3427bis-04 (work in progress), - October 2009. + [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] - Lee, A., Burnett, D., Carter, J., Auburn, R., Candell, E., - Porter, B., Oshry, M., McGlashan, S., Rehor, K., Bodell, - M., Burke, D., and P. Baggia, "Voice Extensible Markup - Language (VoiceXML) 2.1", World Wide Web Consortium + Porter, B., Oshry, M., Bodell, M., Rehor, K., McGlashan, + S., Burke, D., Auburn, R., Candell, E., Burnett, D., + Carter, J., Baggia, P., and A. Lee, "Voice Extensible + Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, . [I-D.ietf-speechsc-mrcpv2] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-20 (work in progress), August 2009. - [I-D.saleem-msml] - Saleem, A. and G. Sharratt, "Media Server Markup Language - (MSML)", draft-saleem-msml-09 (work in progress), - July 2009. - - [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Message - Specification", RFC 5751, January 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. Appendix A. Legacy INFO Usage A.1. General This section provides examples of existing legacy INFO usages. The section is not meant to be a comprehensive catalog of legacy INFO usages, but it should give the reader a flavor for current legacy INFO usages. A.2. ISUP - [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. - ITU-T and 3GPP have specified similar procedures. + [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP + message bodies. ITU-T and 3GPP have specified similar procedures. A.3. QSIG [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. A.4. MSCML [RFC5022] specifies how INFO is used as a transport mechanism by the - MSCML protocol. MSCML uses an option-tag in the Require header field - to ensure that the receiver understands the INFO content. + 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. A.5. MSML - [I-D.saleem-msml] specifies how INFO us used as a transport mechanism - by the MSML protocol. + [RFC5707] specifies how INFO us used as a transport mechanism by the + Media Server Markup Language (MSML) protocol. A.6. Video Fast Update Companies have been using INFO messages in order to request fast video update. Currently a standardized mechanism, based on RTCP, has been specified in [RFC5168] +A.7. DTMF + + Companies have been using INFO messages in order to transport DTMF + tones. All mechanisms are proprietary, and have not been + standardized. + Appendix B. Acknowledgements The work on this document was influenced by the "INFO Considered Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and by the "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" draft (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 @@ -1541,20 +1583,32 @@ 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. Appendix C. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] + Changes from draft-ietf-sipcore-info-events-08 + o Further changes based on IESG comments + o Editorial changes + o Section 7.3 removed + o New section 7.4.1.2. added, containing text from old section 7.3 + + Changes from draft-ietf-sipcore-info-events-07 + o Further changes based on WGLC comments + o Editorial changes + o IANA registry procedures clarified + o Reference to RFC 5727 added + Changes from draft-ietf-sipcore-info-events-05 o Further changes based on WGLC comments o Editorial changes o IANA registry procedures clarified Changes from draft-ietf-sipcore-info-events-04 o Further changes based on WGLC comments o OPTIONS processing removed o Clarification of Recv-Info header field in INFO 469 response added o IANA registry procedures clarified