--- 1/draft-ietf-sipcore-info-events-09.txt 2010-10-12 17:16:20.000000000 +0200 +++ 2/draft-ietf-sipcore-info-events-10.txt 2010-10-12 17:16:20.000000000 +0200 @@ -1,21 +1,21 @@ SIPCORE C. Holmberg Internet-Draft Ericsson Obsoletes: 2976 (if approved) E. Burger Intended status: Standards Track NeuStar, Inc. -Expires: April 1, 2011 H. Kaplan +Expires: April 15, 2011 H. Kaplan Acme Packet - September 28, 2010 + October 12, 2010 Session Initiation Protocol (SIP) INFO Method and Package Framework - draft-ietf-sipcore-info-events-09 + draft-ietf-sipcore-info-events-10 Abstract This document defines a method, INFO, for the Session Initiation 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. @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering 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." - This Internet-Draft will expire on April 1, 2011. + This Internet-Draft will expire on April 15, 2011. 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 @@ -82,24 +82,26 @@ 5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 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. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 - 8.3.1. Alternative SIP signaling plane mechanisms . . . . . . 16 - 8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18 - 8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . 21 @@ -241,24 +243,24 @@ 2976, 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 3, an INFO request associated with an Info Package always contains an Info-Package header field). - 2. 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. + 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 @@ -719,31 +721,21 @@ 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. Alternative Mechanisms - -8.3.1. Alternative SIP signaling plane mechanisms - -8.3.1.1. General - - This subsection describes some alternative mechanisms for - transporting application information on the SIP signaling plane, - using SIP messages. - -8.3.1.2. INFO Request Rate and Volume +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 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 @@ -769,21 +761,31 @@ 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.3.1.3. SUBSCRIBE/NOTIFY +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], 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 @@ -803,57 +805,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. -8.3.1.4. MESSAGE +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.3.2. Media Plane Mechanisms +8.4.2. Media Plane Mechanisms -8.3.2.1. General +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. 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. -8.3.2.2. MRCP +8.4.2.2. MRCP 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. -8.3.2.3. MRSP +8.4.2.3. MRSP MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses. -8.3.3. Non-SIP related mechanisms +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 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. 9. Syntax @@ -894,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 8.3 describes alternative mechanisms, which should be + 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 are carried in INFO requests associated with the Info Package, and for what type of applications and functionalities UAs can use the Info Package. @@ -1482,23 +1484,23 @@ 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] - Rehor, K., Bodell, M., Burke, D., Baggia, P., Auburn, R., - Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, - A., Porter, B., and M. Oshry, "Voice Extensible Markup + Porter, B., McGlashan, S., Lee, A., Auburn, R., Carter, + J., Rehor, K., Oshry, M., Bodell, M., Burke, D., Baggia, + P., Candell, E., and D. Burnett, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, . [I-D.ietf-speechsc-mrcpv2] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-21 (work in progress), July 2010.