Internet DRAFT - draft-wenger-clue-transport


Network Working Group                                          S. Wenger
Internet-Draft                                                     Vidyo
Intended status: Standards Track                              M. Eubanks
Expires: September 13, 2012                               AmericaFree.TV
                                                                 R. Even
                                                            G. Camarillo
                                                          March 12, 2012

                       Transport Options for Clue


   This memo describes the assumption and the proposed options for the
   coding and transport of CLUE messages as outlined in version 01 of
   the framework draft.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wenger, et al.         Expires September 13, 2012               [Page 1]
Internet-Draft               clue-transport                   March 2012

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Transport for CLUE messages  . . . . . . . . . . . . . . . . .  5
     3.1.  Option 1 : Piggy-pack on SIP . . . . . . . . . . . . . . .  6
       3.1.1.  Option 1.1: Using SDP (in an offer-answer context)
               for CLUE information . . . . . . . . . . . . . . . . .  6
       3.1.2.  Option 1.2: Using an SDP MIME body to carry the
               CLUE information in an INVITE or UPDATE exchange . . .  7
       3.1.3.  Option 1.3: Using a SIP INFO package . . . . . . . . .  7
       3.1.4.  Option 1.4: SIP signaling options  . . . . . . . . . .  7
     3.2.  Option 2: CLUE control channel on the media plane over
           UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Option 3: Other Work . . . . . . . . . . . . . . . . . . .  8
   4.  Content Representation . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Option 1 : SDP . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Option 2 : XML . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Option 3 : ASN.1 . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Option 4 : Clue Defined Format . . . . . . . . . . . . . . 10
     4.5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.6.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Clue Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Option 1 : CLUE discovery as a side effect of opening
           a CLUE control channel . . . . . . . . . . . . . . . . . . 11
     5.2.  Option 2 : SIP Message Transport . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Wenger, et al.         Expires September 13, 2012               [Page 2]
Internet-Draft               clue-transport                   March 2012

1.  Introduction

   The CLUE WG is chartered to design a protocol to enable communication
   about media streams for videoconferencing and telepresence working in
   conjunction with the IETFOs protocol suites of choice, namely SIP for
   basic call setup and control and RTP for media transport.  (It should
   be noted that ITU-T Q.xx/16 has informally expressed a desire that
   parts or all of the work of the CLUE WG can be re-used in an H.323
   environment.  Therefore, occasionally, we comment on the re-use of
   CLUE work outside of SIP systems.  This does not mean that we want to
   extent the charter; however, it seems sensible at least to us that if
   a cross protocol solution and a SIP-only solution to the CLUE problem
   could be devised, and both solutions are comparable in in their
   complexity etc etc, a solution with applicability beyond SIP may be
   the appropriate choice.)

   This document describes options for the coding and transport of CLUE
   messages in a SIP / RTP environment.  Specifically, three issues are

   First, while the framework draft conceptually describes message
   flows, it does not specify how those messages are actually
   transferred "on the wire" and how they relate to the SIP offer/answer
   [RFC3264].  This document lists (hopefully all) the options that have
   been proposed in CLUE to date.

   Second, the framework-01 draft describes three messages between the
   producer and the consumer in an abstract form, without specifying the
   details of the representation of those messages.  This memo lists
   (some of) the options for the representation of the abstract messages
   of the framework draft.

   Third, before any CLUE messages can be meaningfully exchanged, it is
   necessary to discover whether the involved systems are actually CLUE-
   capable.  This memo discusses the proposed options for CLUE
   capability discovery.

   In this memo we only present the options discussed to date in the
   working group.  Deciding on the appropriate mechanism (or mechanisms,
   as it is not always appropriate to have a single solution for a given
   problem, though this is of course desirable from an interoperability
   viewpoint) is left for further discussion in the working group.  That
   does not mean that the authors do not have preferences, and/or
   specific knowledge of certain mechanisms, and may as a result go in
   greater depth in describing one mechanism than another.

Wenger, et al.         Expires September 13, 2012               [Page 3]
Internet-Draft               clue-transport                   March 2012

2.  Assumptions

   The Basic Clue data model is specified in the framework document.
   The framework defines three messages that carry the Clue data:

   Consumer Capability Message

   Provider Capabilities Announcement

   Consumer Configure Request

   (There is no clear consensus that the Consumer Capability Message is
   needed, but for the time being we attempt to document how it fits in
   the different options.)

   CLUE messages may need to be sent at the initialization of a call,
   and possibly also at irregular intervals within a call, spaced in the
   order of seconds, minutes or even longer.  There is also no hard
   real-time transmission requirement for CLUE messages; latencies in
   the seconds range are acceptable.  More specifically, there appears
   not to be an issue with system reaction delay larger than the maximum
   round trip delay for reasonable operation of a telepresence system.

   The Clue message handshake as required by the framework (independent
   from the issue related to the need of the Consumer Capability
   Message) is different from the offer/answer (o/A) exchange [RFC3264],
   primarily because the CLUE exchange is uni-directional, requiring a
   similar exchange for each side of the media flow, while one offer/
   answer exchange defines both sides of the media flow.  (Note that
   asymmetry in SIP may require a second offer answer exchange, but this
   is not the typical case)

   There is no hard requirement for synchronization of CLUE messages,
   though there may be a need for sequencing, (TBD).

   CLUE messages may need to describe the characteristics of all
   endpoints in a conference (TBD), and that conference can potentially
   include dozens of endpoints.

   It appears to be consensus within the CLUE WG that there will be an
   SDP offer/answer exchange as part of the solution.  It further
   appears to be the consensus that the offer/answer will be used to
   establish the media channels and negotiate those SDP parameters
   negotiable with media types (i.e. as defined in RTP payload formats),
   as well as to allow interoperability with systems that do not support
   the CLUE protocol.  It appears to be a sensible design goal that the
   CLUE data does not duplicate SDP attributes.

Wenger, et al.         Expires September 13, 2012               [Page 4]
Internet-Draft               clue-transport                   March 2012

   In order to achieve interoperability with systems that do not support
   CLUE, the first offer answer exchange could be used to negotiate CLUE

   An open issue is whether there needs to be a final offer answer
   exchange, after initial o/A exchange(s) as well as CLUE exchange(s),
   with an SDP reflecting the negotiated media flows, in order to
   address requirements imposed by intermediaries like Session Border
   Controllers (SBC).  This topic was discussed in different contexts
   before, and there is some text about it in RFC5939 section 3.12

   The size of a CLUE message is far from final yet but when selecting a
   solution the issue of message size and fragmentation (if applicable)
   needs to be addressed.

3.  Transport for CLUE messages

   CLUE messages need to be conveyed from one CLUE capable system to
   another, i.e., there needs to be "transport" of CLUE messages.  It
   should be clear that the message transport can be based on a
   transport layer (layer 4 in ISO/OSI) protocol or other layers, such
   as the application layer.

   In contrast to the "content representation", the transport of CLUE
   messages is somewhat more tightly bound to the environment.  In some
   scenarios it may be possible to reuse most of the mechanisms defined
   in an option for transport between SIP and H.323, while in others
   this is not possible.

   The selection of the transport may have some affect on the content
   representation, in that certain transports in the aforementioned
   sense are defined only to carry certain types of messages.  For
   example, offer-answer is defined for the use in conjunction with SDP
   as content representation.  In contrast, obviously, a CLUE-defined
   transport mechanism could carry any format specified by CLUE.

   The CLUE protocol enables the CLUE systems to negotiate the semantic
   relationships of the media streams, mostly with respect to spatial
   relations.  Another aspect that has recently risen to prominence is
   the negotiation of media codec settings, taking into account that in
   practical telepresence systems, certain combinations of codec
   settings may not be supported by the hardware ("codec alternatives"

   The apparently generally agreed need for interoperability with non
   CLUE systems requires defining an initial offer involving CLUE

Wenger, et al.         Expires September 13, 2012               [Page 5]
Internet-Draft               clue-transport                   March 2012

   support, and guidance on how to progress the call setup based on the
   answer.  The CLUE WG discussed a couple of options including two
   stage offer answer, using grouping similar to
   [I-D.ietf-mmusic-sdp-bundle-negotiation], and using the capability
   negotiation of [RFC5939].

   We would like to consider the following options:

3.1.  Option 1 : Piggy-pack on SIP

   SIP includes a number of methods that can carry (directly or through
   content indirection) CLUE messages.  Many of these messages can be
   exchanged during the lifetime of a session.  Piggy-packing CLUE
   messages on SIP has the advantage that any built-in transport and
   reliability mechanisms of SIP can be re-used.  (Whether this is an
   advantage in practice is somewhat questionable, considering that the
   vast majority of SIP systems use UDP for the transport of SIP
   messages, and that their SIP messages are typically small enough to
   fit into an MTU--something that like is not true for some CLUE
   messages.)  It also has the feature (advantage?) that CLUE signaling
   is being conveyed in the signaling plane rather than in the media
   plane (making things such as decomposition potentially easier and
   certainly more intuitive).

   There are three sub-options to consider

3.1.1.  Option 1.1: Using SDP (in an offer-answer context) for CLUE

   In this option, the CLUE protocol is specified through the addition
   of CLUE-specific SDP codepoints in the (essentially unmodified)
   offer/answer process, for essentially all CLUE functionalities.  The
   stream semantics associated with spatial relations of streams are
   represented as new SDP attributes .  Codec alternatives may be
   negotiated based on draft-ietf-mmusic-sdp-media-capabilities.

   The nature of spatial relations currently envisioned by some CLUE
   participants have some simultaneous restrictions due to the
   limitations of physical capture devices.  For this reason, it may
   become necessary to separate the negotiation process into a session
   negotiation that defines RTP sessions, and a session negotiated that
   deals with the spatial relations.

   It is noted that, at the time of writing, there is no proposal on the
   table that would suggest that offer-answer only is a sensible--or
   even possible--design choice.

Wenger, et al.         Expires September 13, 2012               [Page 6]
Internet-Draft               clue-transport                   March 2012

3.1.2.  Option 1.2: Using an SDP MIME body to carry the CLUE information
        in an INVITE or UPDATE exchange

   In order to separate the RTP session negotiation from the CLUE media
   capture selection, a clean solution appears to be to carry the CLUE
   information in a body separate from the classic media negotiation
   information, with a parallel negotiation using INVITE and UPDATE for
   the CLUE information.  A similar approach is proposed in

   There were concerns about using re-invite, claiming that it takes too
   long since that commonly implies codec boxes teardown of every
   existing media session during re-invites.  [RFC3311]suggests that
   although UPDATE can be used on confirmed dialogs, it is RECOMMENDED
   that a re-INVITE be used instead.  This is because an UPDATE needs to
   be answered immediately, ruling out the possibility of user approval.
   Such approval may be needed, and is possible only with a re-INVITE.

3.1.3.  Option 1.3: Using a SIP INFO package

   Another option may be to define a new SIP INFO package [RFC6086].
   The SIP-INFO method is very flexible in that the package can define,
   at least to a large extent, the semantics of a SIP-INFO exchange.
   However, SIP-INFO is subject to SIPOs limitations, for example in
   terms of message size when SIP messages are transported over UDP
   (which, we understand, is the common operation point.

3.1.4.  Option 1.4: SIP signaling options

   There may be other options using SIP signaling, such as subscribe/
   notify or Message method, see [RFC6086] section 8.4.1.  Note that, in
   those cases, a subscribe creates a separate dialog usage and is
   normally sent outside of existing dialog.  Within this document, we
   are not discussing the implications of such a possible implementation

3.2.  Option 2: CLUE control channel on the media plane over UDP

   During the initial SIP handshake, a secure(?)  CLUE channel is
   established (if both systems are CLUE capable).  This channel may be
   UDP or TCP based.  Using UDP may require an additional reliability
   mechanism, perhaps using a mechanism similar to BFCP over UDP, and
   addressing fragmentation is likely to be necessary due to message
   size.  These complications are not required for a TCP based solution.
   On the other hand, using ICE to address firewall and NAT traversal as
   well as working with intermediaries like SBCs works better with UDP.
   Note that even under this option, we assume that the actual protocol
   exchange to negotiate and open media channels is being conducted

Wenger, et al.         Expires September 13, 2012               [Page 7]
Internet-Draft               clue-transport                   March 2012

   using an SDP content representation, quite possibly through a
   "fincal" offer-answer exchange that nails down the actual media flows
   to be used, for the benefit of SBCs and similar middleboxes.

3.3.  Option 3: Other Work

   At least three other individual submissions address similar topics as
   this section, and the the readerOs attention is drawn to those.

   [I-D.hansen-clue-protocol-choices-evaluation] goes into some detail
   in analyzing the pros and cons of a previous version of our document.
   The authors arrive at a conclusion that can be summarized as that
   there is a need for a transport mechanism that is not based on SIP,
   but using a UDP session negotiated using SIP and Offer/Answer for the
   transport of CLUE messages.  CLUE messages in this case probably
   ought to be interpreted narrowly in that they relate to spatial
   relationships and related issues, in contrast to codec parameter

   [I-D.romanow-clue-sdp-usage] arrives at a similar conclusion.  The
   draft lists those codepoints that could be conveyed using SDP in an
   offer-answer setting: video properties (bandwidth and resolution),
   and bandwidth-related group settings.  Everything else, including
   spatial relationship of captures, is suggested to be conveyed over a
   CLUE-specific protocol, conveyed over a UDP(?) session negotiated in
   SIP during the early (first) offer/answer exchange.

   [I-D.cazeaux-clue-sip-signaling] signaling appears to advocate a
   solution in which SDP based O/A is used to negotiate media.  The
   negotiated media appear to be a superset of the media later being
   used.  CLUE specific information, such as spatial relationships, but
   also the details of the media sessions (including restrictions of
   provider content selection based on consumer capabilities), appear to
   be relegated to signaling conveyed over a SIP/OA negotiated CLUE

   All three aforementioned drafts appear to acknowledge the need for a
   CLUE signaling channel, possibly conveyed directly over UDP (in
   contrast to a being conveyed over SIP-info or something similar),
   although these drafts vary in the degree to which they use the CLUE
   signaling channel.

4.  Content Representation

   The data model in the framework-03 draft does not include a
   specification of the representation of the data.  Many different

Wenger, et al.         Expires September 13, 2012               [Page 8]
Internet-Draft               clue-transport                   March 2012

   representation languages, for example XML, possibly SDP, ASN.1, and
   others can be used, and we need to decide on one, possibly for each
   data structure defined in a CLUE solution (that is, for example, it's
   possible that some data points of CLUE can be conveyed in SDP,
   whereas others use XML).  Depending on the transport decision, we may
   be restricted to certain representations for certain data structures,
   or we may have freedom of choice.  Referring to the options suggested
   above, it is clear that option 3.1.1 mandates SDP for representing
   CLUE.  However, all other options appear not to require any pre-
   defined choice, at least for some (though not necessarily for all) of
   the CLUE-defined codepoints.

   One observation that has to be made at this point (described in
   greater detail above) is that the framework-01 draft's message
   exchange system requires more than one end to end exchange due to the
   asymmetry.  Another observation is that the advertisement describes
   the sending options, which makes the CLUE exchange different from the
   offer/answer mechanism SIP videoconferencing endpoints use today.
   For this reason we do not think that the option in 3.1.1 is a good
   direction.  Therefore, there appears not to be a hard requirement to
   use SDP exclusively for the representation of CLUE messages.  For
   some messages, SDP may be an appropriate choice, but for others,
   there is no precedence: We have a freedom of choice here, which is
   why this section exists.

   It is very well possible that even moderately complex CLUE messages
   may exceed MTU sizes commonly found in todayOs Internet.  There has
   been discussion in CLUE of sessions with thousands of participantsNa
   very real requirement for at least one of the authors of this draft,
   who routinely participates in multipoint videoconferences with 200+
   participants.  Even if a CLUE message can be compressed into a few
   bytes for each endpoint, such sessions will violate the commonly
   found Ethernet 1492-byte MTU.  Accordingly, message transport
   protocols will have to be prepared to split CLUE messages into
   fragments, which has implications on the design complexity of those
   protocols.  This problem is especially an issue for verbose
   representations, such as XML.

4.1.  Option 1 : SDP

   SDP and its various extensions are used in SIP based systems for the
   offer/answer exchange, and, therefore, those systems include SDP
   parsers that could probably be extended to support CLUE messages.
   SDP is also a fairly compact, but still (though barely) human
   readable .  Even though it does not appear to us to make overly much
   sense to use SDP for CLUE, since it will require a separate blob for
   describing the CLUE relations between the media captures, it still
   viable to use text based representation for CLUE if using any of the

Wenger, et al.         Expires September 13, 2012               [Page 9]
Internet-Draft               clue-transport                   March 2012

   options which is not 3.1.1.  [I-D.romanow-clue-sdp-usage] suggests
   that an SDP-only representation of CLUE based parameters is an
   (impossible/suboptimal) bad choice.  We concur.  As mentioned before,
   though, those parameters that can reasonably be negotiated using SDP
   o/A (with however many round trip it takes) should in our opinion be
   represented in SDP.  We shouldn't be in SDP-ng's business.

4.2.  Option 2 : XML

   XML is very flexible, and the representation of choice for many IETF
   technologies not bound to a certain legacy.  It certainly allows for
   all flexibility needed to represent all CLUE messages currently
   considered.  It also is naturally extensible in a way SDP is not.  On
   the downside, XML is fairly verbose, which has implications on the
   transport.  Even considering this verboseness, we believe that XML
   may be an appropriate representation for CLUE messages that cannot be
   represented in SDP.

4.3.  Option 3 : ASN.1

   ASN.1 is similarly flexible and extensible as XML, and (in its binary
   representation) fairly compact.  While it is commonly used in H.323,
   and while the video conferencing industry certainly has access to the
   tools necessary to deploy ASN.1 (a major obstacle in other
   industries), it is not widely used by SIP implementations.

4.4.  Option 4 : Clue Defined Format

   It is, of course, possible that the CLUE WG defines its own format,
   possibly compact, possibly binary and possibly extensible
   representation language or format for CLUE messages.

4.5.  Examples

   An example or examples should be added here when possible

4.6.  Proposal

   The preferred solution can be XML-based for codepoints not easily
   (currently?) representable in SDP, and SDP based for everything else.
   ] With respect to XMLOs verboseness, fragmentation support in the
   transport protocol may be needed and the transport probably should
   include a fragmentation and reassembly support beyond IP
   fragmentation/re-assembly.  Such support may require an encapsulation
   of the message with headers that will allow fragmentation and
   reassembly support.

Wenger, et al.         Expires September 13, 2012              [Page 10]
Internet-Draft               clue-transport                   March 2012

5.  Clue Discovery

   This section summarizes ways to discover whether systems involved are
   CLUE-capable.  For simplicity, point-to-point scenarios are assumed.
   Multipoint scenarios are similar since we are considering centralized
   conference models only.

   Discovery appears to be necessarily bound to the capability exchange
   of the involved systems.

5.1.  Option 1 : CLUE discovery as a side effect of opening a CLUE
      control channel

   If, for the transport of CLUE messages (or at least a subset
   thereof), a media plane control channel were used (section 3.2), then
   the discovery of CLUE capability would be a side effect of the
   opening of this control channel during the initial offer/answer
   exchange.  At this point in time, there is no proposal on the table
   that suggest that we can avoid a CLUE control channel.

5.2.  Option 2 : SIP Message Transport

   Very roughly speaking, if we use the INFO message for the transport
   of all CLUE messages, then by using the Recv-Info header field the
   support for the CLUE package can be signaled.  If using a second MIME
   body the support of the MIME body in the offer answer can be used.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

7.  Security Considerations

   Any method for bypassing NAT/Firewall protections of course brings
   security issues, which need to be dealt with.

8.  Acknowledgements

   The list of authors needs to grow.

Wenger, et al.         Expires September 13, 2012              [Page 11]
Internet-Draft               clue-transport                   March 2012

9.  Informative References

              Cazeaux, S. and E. Bertin, "Requirements for ControLling
              mUltiple streams for tElepresence (CLUE) signaling.",
              draft-cazeaux-clue-sip-signaling-00 (work in progress),
              March 2012.

              Hansen, R. and A. Romanow, "Evaluation of using SIP or an
              independent protocol for CLUE messaging",
              draft-hansen-clue-protocol-choices-evaluation-00 (work in
              progress), November 2011.

              Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
              Using Session Description Protocol (SDP) Port Numbers",
              draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
              progress), February 2012.

              Portman, L., Lum, H., Johnston, A., and A. Hutton,
              "Session Recording Protocol",
              draft-ietf-siprec-protocol-03 (work in progress),
              March 2012.

              Romanow, A., Andreasen, F., and A. Krishna, "Investigation
              of Session Description Protocol (SDP) Usage for
              ControLling mUltiple streams for tElepresence (CLUE)",
              draft-romanow-clue-sdp-usage-00 (work in progress),
              March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
              Capability Negotiation", RFC 5939, September 2010.

   [RFC6086]  Holmberg, C., Burger, E., and H. Kaplan, "Session
              Initiation Protocol (SIP) INFO Method and Package

Wenger, et al.         Expires September 13, 2012              [Page 12]
Internet-Draft               clue-transport                   March 2012

              Framework", RFC 6086, January 2011.

Authors' Addresses

   Dr. Stephan Wenger
   433 Hackensack Ave
   Hackensack, NJ  07601


   Marshall Eubanks
   P.O. Box 141
   Clifton, Virginia  20124

   Phone: +1-703-501-4376

   Roni Even


   Gonzalo Camarillo


Wenger, et al.         Expires September 13, 2012              [Page 13]