One document matched: draft-rosenberg-sip-info-litmus-00.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs='yes'?>

<?rfc compact='yes'?>
<?rfc subcompact='no'?>

<rfc ipr="full3978" category="info">


    <front>
        <title abbrev="INFO Litmus">
Litmus Tests for Usage of the Session Initiation Protocol (SIP) 
INFO Method</title>
    
        <author initials="J.R." surname="Rosenberg"
                fullname="Jonathan Rosenberg">
            <organization>Cisco</organization>
    
            <address>
                <postal>
                    <city>Edison</city> <region>NJ</region>
                    <country>US</country>
                </postal>
    
                <phone>+1 973 952-5000</phone>
                <email>jdrosen@cisco.com</email>
                <uri>http://www.jdrosen.net</uri>
            </address>
        </author>
    
        <date month="February" year="2008" />
    
        <area>RAI</area>
        <workgroup>SIP</workgroup>
        <keyword>SIP</keyword>
        <keyword>INFO</keyword>
        <abstract>
            <t>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.</t>
        </abstract>
    </front>

<middle>

<section title="Introduction">


<t>
The Session Initiation Protocol (SIP) <xref target="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).
</t>

<t>
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:
</t>

<list style="hanging">
<t hangText="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. 
</t>

<t hangText="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. 
</t>

<t hangText="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.
</t>

</list>

<t>
SIP provides three general purpose mechanisms that allow a pair of
agents to communicate data during a session. These are:
</t>

<list style="hanging">

<t hangText="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
  <xref target="I-D.ietf-sipping-app-interaction-framework"/>.
</t>

<t hangText="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
  <xref target="I-D.rosenberg-sip-tote"/>.
</t>

<t hangText="INFO Framework:"> A user agent can send the data in a SIP INFO
  message along the existing SIP dialog. This technique is described
  in <xref target="I-D.kaplan-sip-info-events"/>.
</t>

</list>

<t>
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.
</t>

<t>
<xref target="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.
</t>

</section>

<section title="Applicability of a Media Plane Solution">

<t>
The following litmus tests can be employed to help determine if an
application should be based on a media plane solution:
</t>

<list style="symbols">

<t>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. </t>

<t>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.
</t>

<t>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.
</t>

<t>
  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.
</t>

</list>

</section>

<section title="Applicability of the SIP Events Framework">

<t>
The SIP events framework is the ideal choice when:
</t>

<list style="symbols">

<t>
  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
  <xref target="RFC3856"/> is a classic example, as is the
  registration event package <xref target="RFC3680"/>. 
</t>

<t>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. 
</t>

<t>
  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.
</t>

<t>
  The information exchanged may need to be seen by
  intermediaries. This would argue for a sinaling path solution, which
  the event framework is. 
</t>

</list>

</section>

<section title="Applicability of the SIP INFO Framework">

<t>The INFO framework is a good solution when:
</t>

<list style="symbols">

<t>The information that is exchanged is associated with a
  communications session. This is almost the definitional property of
  the INFO events framework. 
</t>

<t>The information that is exchanged may need to be seen by
  intermediaries. 
</t>

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>

<t>The data has no impact on SIP dialog state, transaction state,
  media session states or intermediate proxy or b2bua states.
</t>

</list>

</section>

<section title="Discussion">

<t>
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.
</t>

</section>

<section title="Security Considerations">

<t>
There are no security considerations associated with this
specification.
</t>

</section>

<section title="IANA Considerations">

<t>
None.
</t>

</section>

</middle>

<back>
<references title="Informative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.I-D.ietf-sipping-app-interaction-framework"?>
<?rfc include="reference.I-D.rosenberg-sip-tote"?>
<?rfc include="reference.I-D.kaplan-sip-info-events"?>
<?rfc include="reference.I-D.kaplan-sip-info-use-cases"?>
<?rfc include="reference.RFC.3856"?>
<?rfc include="reference.RFC.3680"?>
</references>

</back>
</rfc>