SIP E. Burger Internet-Draft BEA Systems, Inc. Updates: RFC 2976 August 7, 2007 (if approved) Intended status: Standards Track Expires: February 8, 2008 Session Initiation Protocol (SIP) INFO Method Use draft-burger-sip-info-01 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 February 8, 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 February 8, 2008 [Page 1] Internet-Draft INFO Use August 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 call establishment signaling, as 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 dialed digits for ISUP or other call setup o Transport of user stimulus to proxies and UAs o Transport of generic DTMF digit entry 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, also known as SIP-T. ECMA- 355 describes a similar use of INFO for QSIG. RFC 4722 [5] describes a use of INFO for media server control. Clearly, there must be some advantages to using INFO, or people would not be using it. First and foremost, for many of these uses, INFO was the only option at the time. For example, MSCML's inception predated SUBSCRIBE/NOTIFY by 18 months. Moreover, one of the driving Burger Expires February 8, 2008 [Page 2] Internet-Draft INFO Use August 2007 concepts in MSCML is the concept of doing an operation on "this" leg. It is much easier to send a message on the SIP dialog, following an already established routing path, than to establish another end-to- end communication channel, such as a new SIP dialog, and referencing the target dialog. One advantage of using any method in the signaling plane is reliable delivery. A common service provider customer service issue is end user devices not being able to transmit DTMF tones reliably across the service network. This is because the media plane does not have reliable delivery characteristics. This is by design, as the goal is to trade-off network latency and jitter for reliable packet delivery. Another advantage is that if the endpoint is only interested in the user signaling, they only need a signaling stack and access to the much lower packet rate signaling channel, as opposed to having a media stack and receiving all of the media. 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, where one entity controls the endpoints. For example, 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 be scaled to receive media server control messages, as that can be independent of subscriber size (call volume). Furthermore, a Voice-over-IP service provider may supply or strictly mandate the manufacturer and firmware for customer-premises equipment such as terminal adapters. 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 covers 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 Burger Expires February 8, 2008 [Page 3] Internet-Draft INFO Use August 2007 argument saying the User Agent can figure it out. The content of the INFO request will have a MIME type. For example, SIP-T [6] messages will have a MIME type of application/ISUP, while MSCML [5] messages will have a MIME type of application/mediaservercontrol+xml. Likewise, the endpoints can negotiate what MIME types they support, thus advertising their capabilities. 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 message sent by mistake. In addition, there are times when an endpoint will be hosting a number of different applications, each looking for different DTMF patterns. For example, a call management application may be looking for a long "#", while a messaging application may be looking for digits. Using INFO, or named tones, for that matter, each application has to examine each digit. Using subscription-based protocols such as KPML, one can limit the traffic and processing to only the tones the application has interest. For that matter, there are application scenarios where an application separate from the endpoint needs to monitor for user stimulus. For example, a calling card application might want to monitor for a re- origination signal. Likewise, a lawful intercept trap and trace application wants to monitor only the user's entered digits. With the INFO method, that application must insert itself in the signaling path. This requires the application to become a Back-to-Back User Agent (B2BUA), which means that it must handle all of the state transactions in the dialogs, as well as intrusively be in the call path. 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, is one may wish the request to traverse the proxy. The problem is there is no way for proxies to know whether or not they have an interest in INFO requests. Getting the requests is an all-or-nothing proposition, driven by Record-Route. Let us consider these issues with respect to DTMF transport. First of all, if the end device is using a compressed codec, the Burger Expires February 8, 2008 [Page 4] Internet-Draft INFO Use August 2007 device will most likely use named tones [8]. If the device also sends DTMF in INFO messages, the device will be sending the digits multiple times. This would not be a problem if the endpoints could negotiate the use of INFO for DTMF transport. If they could, then each device would know to ignore the named tone packets, which do not have reliable delivery characteristics. However, since there is no negotiation, the endpoints have to assume, when they receive a named tone packet, the packet represents DTMF user stimulus. When an INFO arrives with DTMF in it, the endpoint will double detect the digit. One might argue that upon receipt of an INFO message with DTMF in it, the recipient could ignore named tone packets in the media stream. However, in almost all scenarios, the media stream will reach the end device well before an INFO will. A negotiation mechanism would solve this problem. If the endpoints explicitly agree to transport user signaling in the signaling channel, then they can safely ignore named tones in the media stream. Unless the signaling path is secure, using S/MIME or sips, user digit entry is in the clear. This has clear security and privacy implications with respect to credit card numbers, account numbers, personal identification numbers, and so on. One argument often heard for using INFO for DTMF is that it is easy and does not use very much bandwidth. However, studies of, for example, KPML versus INFO for DTMF [9], show significantly better bandwidth utilization for KPML [10], even with the supposed overhead of the SUBSCRIBE / NOTIFY [11] mechanism. This is because sending tones digit-by-digit in an INFO message is very inefficient. There is no throttling mechanism for INFO. Consider that most call signaling occurs on the order of 3 messages per minute. DTMF tones occur in bursts at a rate of 240 messages per minute. This is a considerably higher rate than for call signaling. 3. INFO Alternatives What alternatives to INFO are there for 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 Burger Expires February 8, 2008 [Page 5] Internet-Draft INFO Use August 2007 3.1. State Updates This is the broad class of one User Agent updating another with changes in state. The design goal of the SUBSCRIBE/NOTIFY [11] event framework is to meet just this need. 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 [10]. 3.3. Direct Signaling Channel State updates and user stimulus tend to have relatively few messages per session. Sometimes, User Agents need to exchange 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 [12] or MRCPv2 [13] is appropriate. In addition, not every situation requires a SIP solution. Some signaling is really just one-shot to third-party endpoints. That situation may better be handled using an appropriate protocol, such as HTTP [14]. 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 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 Burger Expires February 8, 2008 [Page 6] Internet-Draft INFO Use August 2007 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]. 3.5. Example: Malicious Indicator Take the case of Malicious Indicator. This is where a subscriber receives a call, realizes it is a malicious call (threatening, SPIT, etc.). They then press the SPIT button (or press *xx), which tells their service provider to mark the UAC as a bad actor. One might be tempted to think that INFO would be a great option for this service. It follows the return path of the INVITE, and so the INFO will hit the caller's inbound proxy, which it can learn the caller is (statistically) a bad actor. That way the inbound proxy can do stuff like notify law enforcement, add a vote to "this is a SPIT source," or other useful action. However, consider a few issues. First, since INFO lives exclusively within an established dialog, there is no way to assert this message after the call completes. Second, this mechanism *relies* on an active service provider topology. If there is no proxy in the chain that will eat the INFO, the caller will see the "this is a bad guy" message, which may have consequences in the real world. Third, there is no a'priori way for the UAS to know whether or not it can issue the INFO. The caller CERTAINLY will not advertise, "please tell me if I am bad, particularly I know in advance that I *am* a bad actor." One approach is for the service provider's proxy to SUBSCRIBE for the SPIT event at the UAS. At this point, life is good, interoperable, and works across networks. This enables events after the dialog is torn down, as presumably the SPIT event will refer not to, "this dialog," which does not exist, but to "that dialog identifier," which exists (and is theoretically unique) forever. Another approach that saves considerably on the overhead of subscriptions would be for the service provider to insert a HTTP URI in the initial INVITE, noting it is for reporting malicious behavior. When the subscriber presses the SPIT button, an HTTP POST gets executed, delivering the call information to the service provider. The service provider can encode basic call information in the HTTP URI and can instruct the device to send whatever arbitrary data is necessary in the POST. This method has the added benefit of being entirely outside the real-time SIP proxy network. Burger Expires February 8, 2008 [Page 7] Internet-Draft INFO Use August 2007 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 [4] for ISUP and ECMA-355 for QSIG. 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 proliferation 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 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. [4] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, Burger Expires February 8, 2008 [Page 8] Internet-Draft INFO Use August 2007 RFC 3372, September 2002. 7.2. Informative References [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] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006. [9] Burger, E., "A Novel System for Remote Control of Household Devices Using Digital IP Phones", Transactions on Consumer Electronics 52(2), May 2006. [10] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [12] Campbell, B., , R., and C. Jennings, "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-19 (work in progress), February 2005. [13] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-12 (work in progress), March 2005. [14] 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. Appendix A. Acknowledgements Standing on the shoulders of giants. Jonathan Rosenberg did the original "INFO Considered Harmful" on Inernet Draft on 26 December 2002, which influenced the work group and this document. Likewise, Dean Willis influenced the text from his Internet Draft, "Packaging Burger Expires February 8, 2008 [Page 9] Internet-Draft INFO Use August 2007 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! John Elwell and Francois Audet helped with QSIG references. Adam Roach, Dale Worley, Dean Willis, Hadriel Kaplan, Jeroen van Bemmel, Johnathan Rosenberg, Martin Dolly, Paul Kyzivat, Roland Jesske, Sam Ganesan, Spencer Dawkins, and Xavier Marjou gave valuable feedback, commentary and suggested text. Christer Holmberg provided numerous counter examples that helped hone the message of this document. Author's Address Eric W. Burger BEA Systems, Inc. USA Email: eburger@standardstrack.com URI: http://www.standardstrack.com Burger Expires February 8, 2008 [Page 10] Internet-Draft INFO Use August 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 February 8, 2008 [Page 11]