<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC5888 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5888.xml">
  <!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
  <!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
  <!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
  <!ENTITY RFC7205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7205.xml">
  <!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
  <!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">
  <!ENTITY RFC8550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8550.xml">



<!--
<!ENTITY RFC3524 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3524.xml">
<!ENTITY RFC8445 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8445.xml">
<!ENTITY RFC5583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5583.xml">
<!ENTITY RFC5956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5956.xml">
-->

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="2"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-abhishek-mmusic-superimposition-grouping-00" ipr="trust200902">
   <front>
      <title abbrev="Superimposition Group Semantic">SDP Superimposition Grouping framework</title>
      <!-- Authors -->
      <author fullname="Rohit Abhishek" initials="R." surname="Abhishek">
         <organization>Tencent</organization>
         <address>
            <postal>
               <street>2747 Park Blvd</street>
               <city>Palo Alto</city>
               <region />
               <code>94588</code>
               <country>USA</country>
            </postal>
            <email>rabhishek@rabhishek.com</email>
         </address>
      </author>
      
      
      <author fullname="Stephan Wenger" initials="S." surname="Wenger">
         <organization>Tencent</organization>
         <address>
            <postal>
               <street>2747 Park Blvd</street>
               <city>Palo Alto</city>
               <region />
               <code>94588</code>
               <country>USA</country>
            </postal>
            <email>stewe@stewe.org</email>
         </address>
      </author>
      <!--
     
-->
      <date year="2020" />
      <area>art</area>
    <workgroup>mmusic</workgroup>
      <!-- <keyword/> -->
      <!-- <keyword/> -->
      <!-- <keyword/> -->
      <!-- <keyword/> -->
      <abstract>
         <t>
             This document defines semantics that allow for signaling a new SDP group "S" for superimposed media in an SDP session. The "S" attribute can be used by the application to relate all the superimposed media streams enabling them to be added as an overlay on top of any media stream. The superimposition grouping semantics is required, if the media data is separate and transported via different sessions.

            <!-- It can be added to the any particular media stream indicating the stream to be superimposed on top of the immersive video. -->
         </t>
      </abstract>
   </front>
   <middle>
      <section title="Introduction">
         <t>
             Media superimposition can be defined to be a visual media (video/image/text) which is superimposed on top of an already existing visual media such that the resulting foreground and background media can be displayed simultaneously. Superimposition can be recursive in that a visual media that is superimposed against its background can, in turn, be the background of a another superimposed visual media. The superimposed visual media displayed over a background media content may vary in transparency. Examples of video superimposition include real-time multi-party gaming, where these superimposed media maybe used to provide additional details or stats about each player, or multi-party teleconferencing where visual media from users in the teleconference may be superimposed on a background media or over each other. An example is shown in figure below, where three foreground media has been superimposed over a background media with one foreground media being partly superimposed over another foreground media.
           
             <figure anchor="my_figure" title="A example of media superimpostion">
             <preamble></preamble>
             <artwork><![CDATA[
                ----------------------------
               | Background media           |
               |   _________                |
               |  | Media A |               |
               |  |_________|               |
               |              __________    |
               |       ______|__ Media B|   |
               |      |Media |__|_______|   |
               |      |_C_______|           |
                ----------------------------
             
             ]]></artwork>
                <postamble></postamble> </figure>
             </t>
             
           
             
             <t>
                 SDP is being predominantly used for describing the format for multimedia communication sessions. Many SDP-based systems use open standards such as RTP <xref target=" RFC3550"/> for media transport and and SIP <xref target=" RFC3261"/> for session setup and control. An SDP session may contain more than one media description with each media description identified by "m"=line. Each line denotes a single media stream. If multiple visual media lines are present in a session, at present, their spatial relationship at the rendering device is undefined. This memo introduces a mechanism in which certain rendering information becomes available. The rendering information herein is limited to the foreground/background relationship of each grouped media vis-à-vis each other, and optionally a transparency value. Where, spatially, the media is rendered is not covered by this memo and is in many application scenarios a function of the user interface. However, the superimposition grouping as described below enables a compliant receiver/renderer implementation to know the relative relevance of the visual media as coded by the sender(s) and, in a compliant implementation, observed by the renderer through superimposition.
                </t>

             <t>
          <!--   When multiple media is streamed, a relationship between the background and foreground visual media needs to be defined. -->
          
          When multiple superimposed streams are transmitted within a session, the receiver needs to be able to relate the media streams to each other. This is achieved by the SDP grouping framework <xref target="RFC5888" /> by using the "group" attribute that groups different "m" lines in a session. By using a new superimpose group semantic defined in this memo, a group’s media streams can be uniquely identified across multiple SDP descriptions exchanged with different receivers, thereby identifying the streams in terms of their role in the session irrespective of its media type and transport protocol. These superimposed streams within the group may be multiplexed based on the guidelines defined in <xref target="draft-ietf-avtcore-multiplex-guidelines-12" />.
          </t>
          
          <t>
              This document describes a new SDP group semantics for grouping the superimposition in an SDP session. An SDP session description consists of one or multiple media lines know as "m" lines which can be identified by a token carried in a "mid" attribute. The SDP session describes a session-level group level attribute that groups different media lines using a defined group semantics.  The semantics defined in this memo is to be used in conjunction with "The Session    Description Protocol (SDP) Grouping Framework"<xref target="RFC5888" />. <!--The transparency of the superimposed media is currently out of this draft’s scope.-->
          </t>
          
          
      </section>
      
      
    <!--
      <section anchor="Discussion" title="Discussion Venue for this draft">
         <t>
             (Note to RFC Editor - if this document ever reaches you, please
              remove this section) </t>


           <t>   Substantial discussion of this document should take place on the MMUSIC
              working group mailing list ( mmusic@ietf.org).  Subscription and archive
              details are at https://www.ietf.org/mailman/listinfo/mmusic.
         </t>
      </section>
      -->
    
    
    
      
      
      <section anchor="Terminology" title="Terminology">
         <t>
            The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
               "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
               this document are to be interpreted as described in <xref target="RFC2119" />.
         </t>
      </section>
      <!-- section anchor="Definition" title="Definition" -->
      <!--
      <section anchor="Motivation" title="Motivation for new Overlay Label">
    <t>
In an immersive telepresence session, one media  is streamed as an immersive stream whereas other media streams are overlaid on top of the immersive video/image. An end user can stream more than one overlay subject to its decoding capacity.
    </t>
    <t>
        Currently, SDP <xref target="RFC4566" /> does not provide any grouping label for overlays for a CLUE session in a teleconference (eg. , slides, video, image) in a form which can be understood by the application. Although the overlays can be signalled by the server and the end user can see and read the content of the media streams, it is up to the application to determine what to do with them <xref target="RFC5888"/>. When multiple overlays are signalled by SDP, it is necessary to group all overlays within a session description to relate them to each other.
         </t>
      </section>
      -->
      
      <!--
      <section anchor="Overview" title="Overview of Operation (Informative)">
         <t>
             This section includes a non-normative description of SDP superimposition group semantics. An immersive media session may consist of a background visual media and one or more foreground visual media. These background and foreground superimposed streams are signalled in SDP via "m" lines. Each "m" line in the session description is identified by a token carried via the "mid" attribute. When multiple superimposed streams are transmitted within a session, the receiver can relate the media streams to each other with respect to their foreground/background status.
    </t>
    </section>
         
         
   -->

         
      <section anchor="SuperStreamGroup" title="Superimposition Group Identification Attribute">
         <t>
             The "superimposition media stream identification" attribute is used to identify the relationship of superimposed media streams within a session description.  In a superimposition  group, the media lines MAY have different media formats. Its formatting in SDP <xref target="RFC4566" /> is described by the following
            Augmented Backus-Naur Form (ABNF) <xref target="RFC5234" />:

         </t>
         <figure>
            <preamble />
            <artwork><![CDATA[mid-attribute = "a=mid:" identification-tag
identification-tag = token
                     ; token is defined in RFC4566]]></artwork>
            <postamble />
         </figure>
         <t>  This documents defines a new group semantics "S" identification media attribute, which is used to identify super group media streams within a session description. It is used for grouping the foreground media streams to be superimposed on top of a background media stream together within a session. An application that receives a session description that contains "m" lines grouped together using "S" semantics MUST superimpose the corresponding media streams on top of the background media stream. The ordering of the "m" lines is significant: assuming the “m” lines to be counted from 0 to n, for each k within 0..n, a reconstructed sample of the k-th media is superimposed (while perhaps applying an alpha transparency value) on the 0 to k-th reconstructed samples in the same spatial position.
</t>
         <!-->This document defines a standard semantics: Overlay. Semantics extensions follow the Standards Action policy [RFC8126].<-->
      </section>
      


      
      
   
      
      
      
      
      
      <section anchor="groupuse" title="Use of group and mid">
         <t>
             All group and mid attributes MUST follow the rules defined in <xref target="RFC5888" />. The "mid" attribute MUST be used for all "m" lines covering visual media within a session description for which a foreground/background relationship is to be defined. The foreground/background relationship of visual media within a session description that is not covered in a group is undefined. No more than one group MUST be used within one session. If the identification-tags associated with "a=group" lines do not map to any "m" lines, it MUST be ignored.
         </t>
         <figure>
            <preamble />
            <artwork><![CDATA[group-attribute ="a=group:" semantics
                  *(SP identification-tag)
semantics = "S" / semantics-extension
semantics-extension = token
                      ; token is defined in RFC4566]]></artwork>
            <postamble />
         </figure>
      </section>
      
      <section anchor="transparency" title=' "transparency" Attribute for Superimposition Group Identification Attribute'>
          <t>
          This memo defines a new media-level attribute, "transparency", with the following ABNF <xref target="RFC5234"/>. The identification-tag is defined in <xref target="RFC5888" />.
          </t>
          
          <figure>
             <preamble />
             <artwork><![CDATA[
    transparency-attribute =
                 "a=transparency:" transparency-tag
    transparency-tag =tranparency-value *("," tranparency-value) CRLF
    transparency-value= alpha
                      ]]></artwork>
             <postamble />
          </figure>
          
          <t>
          Alpha describes the transparency for the foreground media stream. It is identified by its transparency-tag values in the transparency-attribute. It could be an integer with values between 0 and 100. This is an informative value. Details of interpretion to be left open to the renderer, expect that a value of 0 means foreground media is opaque and value of 100 means that it is transparent.
          </t>
          
          </section>
      
      

      <section anchor="OL" title="Example of S">
         <t>The following example shows a session description for superimposed media stream in
             an SDP session. The "group" line indicates that the "m" lines with tokens 1 and 2 are grouped for the purpose of
             superimpositon and intended to be overlaid on top of a background video. </t>
         
         <t>In the example shown below, two superimposed media streams are being transmitted. Both media types are video with transparency attribute ("transparency").
            The current focus of the draft is defining a group semantics for superimposed media stream. The relationship between the background and foreground media stream maybe defined in the future version of the draft.</t>
        

         <figure>
            <preamble />
            <artwork><![CDATA[
    v=0
    o=Alice 292742730 29277831 IN IP4 233.252.0.74
    c=IN IP4 233.252.0.79
    t=0 0
    a=group:S 1 2
    m=video 30000 RTP/AVP 31
    a=mid:1
    a= transparency: 17
    m=video 30002 RTP/AVP 31
    a=mid:2
    a= transparency: 35
            ]]></artwork>
            <postamble />
         </figure>
    

      </section>
      
      
      <section anchor="ClueRelationship" title="Relationship with CLUE (informative)">
          <t>
      
      Edt. Note: maybe we remove this section later once there is a general understanding why CLUE in its current form is unsuitable.
      The CLUE framework <xref target="I-D.ietf-clue-framework" /> and its associated suite of I-Ds and RFCs describe a telepresence framework that, at the first glance seems to have a lot in common with the technology proposed herein. CLUE defines captures (camera ports), and their geo-spatial relationship to each other. A render can use this information to put the reconstructed samples of the streams from the various captures into a suitable arrangement such that visually pleasant rendering can be achieved. However, CLUE does not describe the relative relevance of the captures. For that reason, CLUE would need to be extended in a spirit very similar to the one described in this memo to achieve the desired functionality.  CLUE has not seen wide deployment outside its intended key application (large room, multiple camera telepresence systems). It’s not reasonable to assume that small systems would willingly implement the overhead the (comparatively complex) CLUE protocols require when a simple SDP extension can serve the same purpose.
      </t>

      </section>
      
      
      <section anchor="Security" title="Security Considerations">
         <t>
            All security considerations as defined in
            <xref target="RFC5888" />
            apply:
         </t>
         <t>Using the "group" parameter with FID semantics, an entity that managed to modify the session descriptions exchanged between the participants to establish a multimedia session could force the participants to send a copy of the media to any destination of its choosing.</t>
         <t>
            Integrity mechanisms provided by protocols used to exchange session descriptions and media encryption can be used to prevent this attack. In SIP, Secure/Multipurpose Internet Mail Extensions (S/MIME)
            <xref target="RFC8550" />
            and Transport Layer Security (TLS)
            <xref target="RFC8446" />
            can be used to protect session description exchanges in an end-to-end and a hop-byhop fashion, respectively.
         </t>
      </section>
      
      
      
      <section anchor="IANA" title="IANA Considerations">
         <!-- Summary of the feature indicated  -->
         <t>The following contact information shall be used for all registrations included here:</t>
         <figure>
            <preamble />
            <artwork><![CDATA[Contact:         Rohit Abhishek
                 email: rabhishek@rabhishek.com
                 tel  : +1-816-585-7500]]></artwork>
            <postamble />
         </figure>
         <t>   This document defines a new SDP group semantics for media superimposition for a
             SDP session.  This attribute can be used by the
             application to group all the foreground media to be superimposed on a background  media in a session.

            Semantics values to be used with this framework should be registered by the IANA following the Standards Action policy
            <xref target="RFC8126" />. This document adds a new group semantics and follows the registry group defined in <xref target="RFC5888" />.
         </t>
         <t>The following semantics needs to be registered by IANA in Semantics for the "group" SDP Attribute under SDP Parameters.</t>
         <figure>
            <preamble />
            <artwork><![CDATA[Semantics             Token          Reference
----------------------------------------------
Superimposition               S              RFCXXXX]]></artwork>
            <postamble />
         </figure>
         <t>
             The "S" attribute is used to group different foreground media streams to be
                superimposed on a background media stream .  Its format is defined in
            <xref target="SuperStreamGroup" />.
         </t>
         
         <t>
             The SDP media-level attribute "transparency" needs to be registered by IANA Semantics for "att-field (media-level only)". The registration procedure  in <xref target="RFC4566" /> applies.
         </t>
                 <figure>
              <preamble>  SDP Attribute ("att-field (media level only)"):    </preamble>
                    <artwork><![CDATA[
                 Attribute name: transparency
                 Long form: superimposition transparency
                 Type of name: att-field
                 Type of attribute: media level only
                 Subject to charset: no
                 Purpose: RFC 5583
                 Reference: RFC 5583
                 Values: alpha
                    ]]></artwork>
                                <postamble />
                             </figure>
             
         
         <!--
         
         Detailed description of the feature value meaning,
          and of the format and meaning of the feature tag values
          for the alternative results.
         
         
         
         The feature tag is intended primarily for use in the following
         applications, protocols, services, or negotiation mechanisms:
         
         -->
         <t>The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.</t>
         <t>
            <list style="symbols">
               <t>A brief description of the semantics.</t>
               <t>Token to be used within the "group" attribute. This token may be of any length, but SHOULD be no more than four characters long.</t>
               <t>Reference to a standards track RFC.</t>
            </list>
         </t>
         <!--
      <figure>
        <preamble>The following are the current entries in the registry:</preamble>
        <artwork><![CDATA[
 Semantics                         Token   Reference
 
 Lip Synchronization                LS     [RFC5888]
 Flow Identification                FID    [RFC5888]
 Single Reservation Flow            SRF    [RFC3524]
 Alternative Network Address Types  ANAT   [RFC8445]
 Forward Error Correction           FEC    [RFC5956]
 Decoding Dependency                DDP    [RFC5583]
]]></artwork>
      <postamble></postamble>
    </figure>
   -->
      </section>
   </middle>
   <back>
      <references title="Normative References">&RFC2119;
      &RFC5888;
      &RFC4566;
      &RFC3550;
      &RFC3261;
      &RFC5234;
      &RFC8126;
      &RFC8446;
      &RFC8550;
      
      
      <!--
      &RFC3524;
      &RFC8445;
      &RFC5583;
      &RFC5956;
      
      -->

      
      </references>
      <references title="Informative References">
         <!-- &RFC7205; -->
          
          <reference anchor="draft-ietf-avtcore-multiplex-guidelines-12">
             <front>
                <title>Guidelines for using the Multiplexing Features of RTP to Support
                    Multiple Media Streams</title>
                <author initials="M" surname="Westerlund" fullname="Magnus Westerlund">
                   <organization />
                </author>
                <author initials="B" surname="Burman" fullname="Bo Burman">
                   <organization />
                </author>
                <author initials="C" surname="Perkins" fullname="Colin Perkins">
                   <organization />
                </author>
                <author initials="H" surname="Alvestrand" fullname="Harald Tveit Alvestrand">
                   <organization />
                </author>
                <author initials="R" surname="Even" fullname=" Roni Even">
                   <organization />
                </author>
                
                
                <date month="June" day="16" year="2020" />
                <abstract>
                   <t>   The Real-time Transport Protocol (RTP) is a flexible protocol that
                       can be used in a wide range of applications, networks, and system
                       topologies.  That flexibility makes for wide applicability, but can
                       complicate the application design process.  One particular design
                       question that has received much attention is how to support multiple
                       media streams in RTP.  This memo discusses the available options and
                       design trade-offs, and provides guidelines on how to use the
                       multiplexing features of RTP to support multiple media streams.</t>
                </abstract>
             </front>
             <seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-multiplex-guidelines-12" />
             <format type="TXT" target="https://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-12.txt" />
          </reference>
          
          <reference anchor="I-D.ietf-clue-framework">
             <front>
                <title>Framework for Telepresence Multi-Streams</title>
                <author initials="M" surname="Duckworth" fullname="Mark Duckworth">
                   <organization />
                </author>
                <author initials="A" surname="Pepperell" fullname="Andrew Pepperell">
                   <organization />
                </author>
                <author initials="S" surname="Wenger" fullname="Stephan Wenger">
                   <organization />
                </author>
                <date month="January" day="8" year="2016" />
                <abstract>
                   <t>This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session.</t>
                </abstract>
             </front>
             <seriesInfo name="Internet-Draft" value="draft-ietf-clue-framework-25" />
             <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-25.txt" />
          </reference>
          
          
          
          
          
          <!--
         <reference anchor="ISO23090">
            <front>
               <title>Information technology — Coded representation of immersive media — Part 2: Omnidirectional MediA Format (OMAF) 2nd Edition</title>
               <author initials="" surname="" fullname="">
                  <organization />
               </author>
               <date month="February" year="2020" />
               <abstract>
                  <t />
               </abstract>
            </front>
            <seriesInfo name="ISO" value="ISO 23090-2:2020(E)" />
            <format type="TXT" target="https://www.iso.org/standard/73310.html" />
         </reference>
         
   
         <reference anchor="TS26.223">
            <front>
               <title>3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telepresence using the IP Multimedia Subsystem (IMS); Media Handling and Interaction</title>
               <author initials="" surname="" fullname="">
                  <organization />
               </author>
               <date month="March" year="2020" />
               <abstract>
                  <t>This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP).</t>
               </abstract>
            </front>
            <seriesInfo name="3GPP" value="TS26.223" />
            <format type="TXT" target="https://www.3gpp.org/ftp//Specs/archive/26_series/26.223/" />
         </reference>
         
         
   
         <reference anchor="I-D.ietf-clue-framework">
            <front>
               <title>Framework for Telepresence Multi-Streams</title>
               <author initials="M" surname="Duckworth" fullname="Mark Duckworth">
                  <organization />
               </author>
               <author initials="A" surname="Pepperell" fullname="Andrew Pepperell">
                  <organization />
               </author>
               <author initials="S" surname="Wenger" fullname="Stephan Wenger">
                  <organization />
               </author>
               <date month="January" day="8" year="2016" />
               <abstract>
                  <t>This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-framework-25" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-25.txt" />
         </reference>
         
         
         <reference anchor="I-D.ietf-clue-signaling">
            <front>
               <title>CLUE Signaling</title>
               <author initials="P" surname="Kyzivat" fullname="Paul Kyzivat">
                  <organization />
               </author>
               <author initials="L" surname="Xiao" fullname="Lennard Xiao">
                  <organization />
               </author>
               <author initials="C" surname="Groves" fullname="Christian Groves">
                  <organization />
               </author>
               <author initials="R" surname="Hansen" fullname="Robert Hansen">
                  <organization />
               </author>
               <date month="August" day="5" year="2015" />
               <abstract>
                  <t>This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-signaling-06" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-signaling-06.txt" />
         </reference>
         
         
         
         <reference anchor="I-D.ietf-clue-datachannel">
            <front>
               <title>CLUE Protocol data channel</title>
               <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
                  <organization />
               </author>
               <date month="September" day="7" year="2015" />
               <abstract>
                  <t>This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-datachannel-10" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-datachannel-10.txt" />
         </reference>
         
         
         <reference anchor="I-D.ietf-clue-data-model-schema">
            <front>
               <title>An XML Schema for the CLUE data model</title>
               <author initials="R" surname="Presta" fullname="Roberta Presta">
                  <organization />
               </author>
               <author initials="S" surname="Romano" fullname="Simon Romano">
                  <organization />
               </author>
               <date month="June" day="29" year="2015" />
               <abstract>
                  <t>This document provides an XML schema file for the definition of CLUE data model types.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-data-model-schema-10" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-data-model-schema-10.txt" />
         </reference>
         
         
         
         <reference anchor="I-D.ietf-clue-protocol">
            <front>
               <title>CLUE protocol</title>
               <author initials="R" surname="Presta" fullname="Roberta Presta">
                  <organization />
               </author>
               <author initials="S" surname="Romano" fullname="Simon Romano">
                  <organization />
               </author>
               <date month="October" day="19" year="2015" />
               <abstract>
                  <t>The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-protocol-06" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-protocol-06.txt" />
         </reference>
         
         
         <reference anchor="I-D.ietf-clue-rtp-mapping">
            <front>
               <title>Mapping RTP streams to CLUE media captures</title>
               <author initials="R" surname="Even" fullname="Roni Even">
                  <organization />
               </author>
               <author initials="J" surname="Lennox" fullname="Jonathan Lennox">
                  <organization />
               </author>
               <date month="October" day="18" year="2015" />
               <abstract>
                  <t>This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures.</t>
               </abstract>
            </front>
            <seriesInfo name="Internet-Draft" value="draft-ietf-clue-rtp-mapping-05" />
            <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-rtp-mapping-05.txt" />
            <format type="PDF" target="http://www.ietf.org/internet-drafts/draft-ietf-clue-rtp-mapping-05.pdf" />
         </reference>
         
         -->
         
         
         
         
      </references>
   </back>
</rfc>
