One document matched: draft-rosenberg-sip-info-litmus-02.txt
Differences from draft-rosenberg-sip-info-litmus-01.txt
SIP J. Rosenberg
Internet-Draft Cisco
Intended status: Informational November 3, 2008
Expires: May 7, 2009
Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO
Method
draft-rosenberg-sip-info-litmus-02
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 May 7, 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 May 7, 2009 [Page 1]
Internet-Draft INFO Litmus November 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 May 7, 2009 [Page 2]
Internet-Draft INFO Litmus November 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.ietf-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 May 7, 2009 [Page 3]
Internet-Draft INFO Litmus November 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 May 7, 2009 [Page 4]
Internet-Draft INFO Litmus November 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 May 7, 2009 [Page 5]
Internet-Draft INFO Litmus November 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 May 7, 2009 [Page 6]
Internet-Draft INFO Litmus November 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-01 (work in
progress), July 2008.
[I-D.ietf-sip-info-events]
Burger, E., Kaplan, H., and C. Holmberg, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", draft-ietf-sip-info-events-00 (work in
progress), October 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 May 7, 2009 [Page 7]
Internet-Draft INFO Litmus November 2008
Author's Address
Jonathan Rosenberg
Cisco
Iselin, NJ
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires May 7, 2009 [Page 8]
Internet-Draft INFO Litmus November 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 May 7, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 20:23:04 |