SIP J. Rosenberg Internet-Draft Cisco Intended status: Informational July 14, 2008 Expires: January 15, 2009 Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO Method draft-rosenberg-sip-info-litmus-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 January 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Session Initiation Protocol (SIP) Working Group is considering the standardization of a framework for conveying application data through the INFO method. However, the INFO method is just one of several techniques available in SIP for the transfer of application data. Others include through the SIP events framework and through a media session. This document provides guidelines and litmus tests for determining which is the right technique to use. Rosenberg Expires January 15, 2009 [Page 1]
Internet-Draft INFO Litmus July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability of a Media Plane Solution . . . . . . . . . . . . 4 3. Applicability of the SIP Events Framework . . . . . . . . . . . 5 4. Applicability of the SIP INFO Framework . . . . . . . . . . . . 5 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Rosenberg Expires January 15, 2009 [Page 2]
Internet-Draft INFO Litmus July 2008 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] allows for the establishment, management, and termination of interactive sessions between user agents. These sessions are often used for the exchange of real time media, such as voice, video or text, using protocols such as the Real Time Transport Protocol (RTP). Oftentimes, there is a need for agents to exchange non-real time application data as part of a communications session. Examples of such data include: Camera Controls: Video conferencing systems often allow a participant in the session to control the camera on the far end of the call. This allows them to pan, tilt and zoom in order to see the person or people they are talking to. Pictures: During a voice call, a user can snap a picture and send it to the other participant in the call. This requires a mechanism to transfer the picture from one end to the other. Game Moves: Users engaging in a real time game may need to exchange game moves in addition to having a voice/video chat in concert with the game. SIP provides three general purpose mechanisms that allow a pair of agents to communicate data during a session. These are: SIP Events Framework: One user agent can send a SUBCRIBE request to the other, using an event package specific to the application data that is desired. This subscription is ideally done as part of a separate dialog. This technique is recommended for application interaction, and is described in [I-D.ietf-sipping-app-interaction-framework]. Media: A user agent can use SIP to set up another media session whose purpose is to carry the application specific data. This can be done using the TOTE protocol proposed in [I-D.rosenberg-sip-tote]. INFO Framework: A user agent can send the data in a SIP INFO message along the existing SIP dialog. This technique is described in [I-D.kaplan-sip-info-events]. Each of these mechanisms are different in important ways. The events framework and the INFO framework utilize the signaling plane, while TOTE utilizes the media plane. The INFO framework always follows the path of an INVITE dialog, while the events framework allows arbitrary Rosenberg Expires January 15, 2009 [Page 3]
Internet-Draft INFO Litmus July 2008 connections and can be independent of any dialog. These differences result in differing scopes of applicability. As a consequence, there cannot be just ONE solution for application signaling. All three are needed and serve different purposes. [I-D.kaplan-sip-info-use-cases] defines different use cases for application transfer in SIP, and suggests whether INFO or other mechanisms are appropriate. However, it doesn't propose any specific metrics which could be used to evaluate the options. This draft proposes metrics which can be considered in deciding which of the three techniques to apply. 2. Applicability of a Media Plane Solution The following litmus tests can be employed to help determine if an application should be based on a media plane solution: o The application is trying to deliver data that has low latency requirements. Since a media plane solution takes the most direct path between user agents, it is the ideal choice in these cases. Examples would be far end camera controls and active speaker indications in a conference. o The data consists of a large number of messages that are likely to be sent during the duration of the session. In the signaling plane solutions, these messages would pass through proxies and other servers, increasing their load without any value. Keeping them on the media plane allows them to go direct. Examples of applications in this category are game moves in a multiplayer game and active speaker indications in a conference. o The data is potentially very large in size. SIP is a poor data transfer mechanism for many reasons. Large messages can clog connections between servers and worsen call setup delays. Many servers were not built to handle large messages. For this reason, the media plane is a better choice. Examples of applications meeting this test are picture sharing and file transfer. o The data is something that intermediaries do not typically need to see. The signaling plane is a better choice in such cases. Note that, it is possible for intermediaries to observe media-plane information by acting as a B2BUA; this is common practice for multimedia over RTP. However, if application data will need to be seen by an intermediary, it is more efficient to use the signaling plan. Rosenberg Expires January 15, 2009 [Page 4]
Internet-Draft INFO Litmus July 2008 3. Applicability of the SIP Events Framework The SIP events framework is the ideal choice when: o The data is not associated with a communications session. In cases where the data is associated with a session, it is better to use either a media plane solution or the INFO events framework. Presence [RFC3856] is a classic example, as is the registration event package [RFC3680]. o The entity that wants to receive the data knows with high probability that the peer is capable of sending a notification with the data, and the entity knows what type of data it needs to receive. In other words, the event framework is ideal where an agent needs to ask a question to a source that always knows the answer. o The information will need to be communicated between the entities for a long period of time, possibly continuously. The event framework is a better choice for these cases; it provides features to support long lived associations. o The information exchanged may need to be seen by intermediaries. This would argue for a sinaling path solution, which the event framework is. 4. Applicability of the SIP INFO Framework The INFO framework is a good solution when: o The information that is exchanged is associated with a communications session. This is almost the definitional property of the INFO events framework. o The information that is exchanged may need to be seen by intermediaries. o The recipient of the data has no idea if the sender will ever generate the data; the recipient is just saying that it knows how to handle it, should the sender have something to send. This is an important differentiator with the events framework, which assumes that the recipient wants the data. Examples of this include receiving a picture or a vCard during a session. The receiver doesn't explicitly want or need the data; but if the sender has it, the receiver is willing to take it. Rosenberg Expires January 15, 2009 [Page 5]
Internet-Draft INFO Litmus July 2008 o The recipient could potentially handle many different types of data with the above characteristic. In other words, there are lots of things that the receiver could process if the sender were to send it. If the application data is just one more, it is likely a fit for the INFO framework. o The size of the data that is to be sent is small and infrequent, at most a few times during the session. This is in contrast to the media solutions, which are also session-oriented but are better for larger and more frequent data. o The data needs to be sent reliably and latency is not much of an issue. If latency were an issue, the media plane solution would be better. o The data has no impact on SIP dialog state, transaction state, media session states or intermediate proxy or b2bua states. 5. Discussion The litmus tests do not provide a black and white answer to the question of which mechanism to use. There is overlap between them, and certain applications could arguably use multiple techniques. The media-plane solution is the most inclusive, in that it could arguably be used for any application. Though optimized for large and frequently sent data, it can handle small and infrequent data too. Though optimized for end-to-end communications it can be seen by intermediaries too. Though optimized for usage during media sessions, one could set up a session just for application data. Indeed, one could go as far as to argue that the media plane solution could replace the SIP events framework and the INFO framework entirely. Perhaps, had SIP been earlier in its evolutionary cycle, this might make sense. However, the event framework in particular is in wide usage and mature, and signaling-based channels remain the most reliable and frequently used. Consequently, this document recommends a pragmatic approach whereby all the mechanisms co-exist, and IETF chooses the ideal one for each task. 6. Security Considerations There are no security considerations associated with this specification. Rosenberg Expires January 15, 2009 [Page 6]
Internet-Draft INFO Litmus July 2008 7. IANA Considerations None. 8. Informative References [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. [I-D.ietf-sipping-app-interaction-framework] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", draft-ietf-sipping-app-interaction-framework-05 (work in progress), July 2005. [I-D.rosenberg-sip-tote] Rosenberg, J., "Session Based Trivial Object Transfer and Exchange (TOTE)", draft-rosenberg-sip-tote-00 (work in progress), February 2008. [I-D.kaplan-sip-info-events] Kaplan, H. and C. Holmberg, "The SIP INFO Method and Info Package Framework", draft-kaplan-sip-info-events-01 (work in progress), February 2008. [I-D.kaplan-sip-info-use-cases] Kaplan, H., "SIP INFO Use Cases", draft-kaplan-sip-info-use-cases-01 (work in progress), February 2008. [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. Rosenberg Expires January 15, 2009 [Page 7]
Internet-Draft INFO Litmus July 2008 Author's Address Jonathan Rosenberg Cisco Edison, NJ US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires January 15, 2009 [Page 8]
Internet-Draft INFO Litmus July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Rosenberg Expires January 15, 2009 [Page 9]