SIP E. Burger Internet-Draft BEA Systems, Inc. Updates: RFC 2976 July 1, 2007 (if approved) Intended status: Standards Track Expires: January 2, 2008 Session Initiation Protocol (SIP) INFO Method Context draft-burger-sip-info-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. 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 January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The purpose of the INFO request for the Session Initiation Protocol (SIP), as described by RFC 2976, is to provide mid-session SIP User Agent (UA)-to-SIP UA application data transport. In the years since the introduction of the INFO request, experience with the use of the INFO request indicates a number of problems. This document explains why there are INFO-based, proprietary protocols in the wild; the Burger Expires January 2, 2008 [Page 1] Internet-Draft INFO Context July 2007 flaws of using INFO; and explains why it is not possible to create a framework to rescue INFO for general purpose use. Thus, this document restricts the use of INFO to that described in RFC 3372 (SIP-T). 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 [1]. The snippets of ABNF assume the definitions found in SIP [2]. 1. Introduction There is a need for mid-session, Session Initiation Protocol (SIP) User Agent (UA)-to-SIP User Agent session layer signaling. Examples of such signaling include the following. o Transporting foreign, non-SIP protocol messages for ISUP call setup o Transport of supplemental dialled digits for ISUP or other call setup o Transport of user stimulus to proxies and UAs o SIP media server control o SIP video encoding control o SIP floor control o Transport of application-specific data The INFO [3] request transports mid-session signaling between two User Agents. These messages follow the signaling path established by the SIP INVITE, including visiting proxies that inserted themselves in the Record-Route path. All of the examples above have implementations using the INFO request. There have been numerous Internet Drafts proposing the transport of DTMF using INFO. Likewise, there have been Internet Drafts describing the use of INFO for video encoding control (such as fast frame refresh requests) and conference floor control. RFC 3372 [4] describes the use of INFO for ISUP and QSIG, also known as SIP-T. RFC 4722 [5] describes a use of INFO for media server control. It is clear there are existence proofs for the use of INFO. However, there is a serious flaw with the INFO request. The INFO request itself has neither a context for interpreting any given message nor a negotiation method for accepting different INFO request types. One of the main reasons why INFO appears to work is most of the uses to date have been in limited or controlled deployments. For example, Burger Expires January 2, 2008 [Page 2] Internet-Draft INFO Context July 2007 application servers, in a session with a media server, will not expect to receive user stimulus. Likewise, a routing proxy, such as the 3GPP IMS S-CSCF, will not expect to receive media server control messages. However, with the further adoption of SIP, such collisions and misinterpretation of context becomes highly likely. This document first describes the flaws with INFO. Then it offers alternatives for INFO that cover most of the use cases for which the work group has seen Internet Drafts in the past. This document describes how one can unambiguously create application session signaling that does require proxy traversal by using new SIP methods. Lastly, this document formally restricts the use of INFO to that described by RFC 3372 [4]. 2. Flaws With INFO There is no programmatic way of determining what the content of an INFO request means. From the User Agent's point of view, a INFO request appears. Is this INFO request conveying a DTMF digit, a SIP-T encapsulated message, or a video update request? There is an argument saying the User Agent can figure it out. The content of the INFO request will have a MIME type. For example, SIP-T messages will have a MIME type of application/ISUP [6], while MSCML messages will have a MIME type of application/mediaservercontrol+xml. However, as we learned in the messaging community [7], relying on the MIME type alone is not sufficient to determine the context of the message. Clearly, as shown in the previous paragraph, the message content type relates to the message context. However, it is quite easy to imagine situations where the same content type has multiple meanings for a User Agent. For example, a DTMF digit type could be for user stimulus, post-dial digit collection, simple transport of a digit (no signaling context), or a mistake. An interesting issue is every INFO request traverses the same proxy path as any other dialog-related SIP request. Proxies in the path that have no interest in INFO requests still must process the request. This may put undue load on those proxies. What makes this issue interesting, and not necessarily a proxy, is one may wish the request to traverse the proxy. The problem is there is no way for proxies to not whether or not they have an interest in INFO requests. Getting the requests is an all-or-nothing proposition, driven by Record-Route. Burger Expires January 2, 2008 [Page 3] Internet-Draft INFO Context July 2007 3. INFO Alternatives What if you think you need UA-to-UA application session signaling? There are four broad classes of session signaling available. The choice depends on the circumstances. o State updates o User stimulus o Direct signaling channel o Proxy-aware signaling 3.1. State Updates This is the broad class of one User Agent updating another with changes in state. Clearly, state updates are the provenance of the SUBSCRIBE/NOTIFY [8] event framework. 3.2. User Stimulus: Touch Tones and Others This is the class of the user entering stimulus at one User Agent, and the User Agent transporting that stimulus to the other. A key thing to realize is key presses on the telephone keypad is user stimulus. Thus, the appropriate mechanism to use here is KPML [9]. 3.3. Direct Signaling Channel State updates and user stimulus tend to have relatively few messages per session. Sometimes, User Agents have a need for exchanging a relatively high number of messages. In addition, User Agents may have a need for a relatively low-latency exchange of messages. In this latter case, the User Agent may not be able to tolerate the latency introduced by intermediate proxies. Likewise, the intermediate proxies may have no interest in processing all of that data. In this case, establishing a separate, direct control channel, as in MSRP [10] or MRCPv2 [11] is appropriate. 3.4. Proxy-Aware Signaling Sometimes, one does want proxies to be in the signaling path for UA- to-UA application signaling. In this case, the use of a SIP request is appropriate. To date, there are no mechanisms for completely disambiguating INFO requests. For example, one could create a registry of INFO packages. The definition of the package would define the contexts for the various MIME Content-Types, as well as the context of the request itself. However, a package can have multiple content types. Moreover, having the context, or package identifier, at the SIP level precludes bundling multiple contexts Burger Expires January 2, 2008 [Page 4] Internet-Draft INFO Context July 2007 responding in the same INFO request. For example, a User Agent might want to bundle two different responses in a multipart/mixed MIME body type. Because there is no difference in either the protocol machinery or registration process due to these factors, we will not create an INFO framework. If one needs a SIP User Agent-to-SIP User Agent application session signaling transport protocol that touches all Record-Route proxies in a path, one MUST create a new SIP method as described in Section 27.4 of RFC 3261 [2]. 4. INFO Use Clarification There is no way to unambiguously use the INFO request in a general framework. The IETF has already standardized use of INFO for SIP-T [4]. Thus we will not deprecate the use of INFO for that purpose. However, this document explicitly updates INFO [3], in that one MUST NOT use the INFO request for anything other than the use described by SIP-T. In recognition of existing, proprietary use of INFO, proxies MUST NOT take any action other than that described by RFC 3261 and RFC 2976 with respect to handling INFO requests. OPEN ISSUE: Do we bow to reality, and say, "INFO is the Port 80 of the 2000's. SBC's will never keep up with newly minted SIP method requests, so we keep INFO so we can have a poliferation of protocols tunneled over SIP?" 5. Security Considerations By eliminating the multiple uses of INFO messages without adequate community review, and by eliminating the possibility for rogue SIP User Agents from confusing another User Agent by purposely sending unrelated INFO messages, we expect the INFO use clarification to improve the security of the Internet. 6. IANA Considerations None. 7. References Burger Expires January 2, 2008 [Page 5] Internet-Draft INFO Context July 2007 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] 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. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 7.2. Informative References [4] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [5] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 4722, November 2006. [6] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [7] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003. [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [9] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [10] Campbell, B., , R., and C. Jennings, "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-19 (work in progress), February 2005. [11] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-12 (work in progress), March 2005. Appendix A. Acknowledgements Standing on the shoulders of giants. Jonathan Rosenberg did the original "INFO Considered Harmful" on 26 December 2002, which influenced the work group and this document. Likewise, Dean Willis Burger Expires January 2, 2008 [Page 6] Internet-Draft INFO Context July 2007 influenced the text from his "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" of 15 January 2003. My, we have been working on this for a long time! Author's Address Eric W. Burger BEA Systems, Inc. USA Email: eburger@standardstrack.com URI: http://www.standardstrack.com Burger Expires January 2, 2008 [Page 7] Internet-Draft INFO Context July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Burger Expires January 2, 2008 [Page 8]