Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO Method
draft-rosenberg-sip-info-litmus-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 August 19, 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.

Table of Contents

1.  Introduction
2.  Applicability of a Media Plane Solution
3.  Applicability of the SIP Events Framework
4.  Applicability of the SIP INFO Framework
5.  Discussion
6.  Security Considerations
7.  IANA Considerations
8.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Rosenberg, J., “A Framework for Application Interaction in the Session Initiation Protocol (SIP),” July 2005.).

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] (Rosenberg, J., “Session Based Trivial Object Transfer and Exchange (TOTE),” November 2008.).

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] (Kaplan, H. and C. Holmberg, “The SIP INFO Method and Info Package Framework,” February 2008.).

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 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] (Kaplan, H., “SIP INFO Use Cases,” February 2008.) 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:

• 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.
• 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.
• 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.
• 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.

3.  Applicability of the SIP Events Framework

The SIP events framework is the ideal choice when:

• 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] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.) is a classic example, as is the registration event package [RFC3680] (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.).
• 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.
• 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.
• 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:

• The information that is exchanged is associated with a communications session. This is almost the definitional property of the INFO events framework.
• The information that is exchanged may need to be seen by intermediaries.
• 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.
• 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.
• 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.
• 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.
• 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.

7.  IANA Considerations

None.

8. Informative References

Author's Address

Full Copyright Statement

Copyright © 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.