One document matched: draft-jennings-mmusic-media-req-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-jennings-mmusic-media-req-00"
     ipr="noDerivativesTrust200902">
  <front>
    <title abbrev="Media Requirements">Requirements from various WG for MMUSIC</title>


    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>

       <address>
        <postal>
          <street>400 3rd Avenue SW, Suite 350</street>

          <city>Calgary</city>

          <region>AB</region>

          <code>T2P 4H2</code>

          <country>Canada</country>
        </postal>

        <email>fluffy@iii.ca</email>
      </address>
    </author>

    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization>Google</organization>

      <address>
        <postal>
          <street>747 6th Ave S</street>

          <city>Kirkland</city>

          <region>WA</region>

          <code>98033</code>

          <country>USA</country>
        </postal>

        <email>justin@uberti.name</email>
      </address>
    </author>

    <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
      <organization> Mozilla </organization>

      <address>
        <phone>+1 650 678 2350</phone>

        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date day="13" month="February" year="2013" />

    <abstract>
      <t>This document outlines some of the requirements driving
      various consideration related to multiplexing in the MMUSIC working group to meet the
      needs of WebRTC, CLUE, and other working groups. </t>
      
      <t> This document is only meant to be used to help drive the
      discussion of solutions and is not intended to become an RFC. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t> For the past several meetings, there has been discussions
      around various mechanism to reduce the number of UDP ports needed
      by applications for RTP. This document attempts to capture some
      of the requirements that are important in selecting the solution
      for how to represent the SDP to negotiate the RTP media that is
      using reduced ports.
      </t>
    </section>


    <section 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">RFC 2119</xref>. This document
      generically uses RTP to mean RTP and SRTP.  </t>
    </section>


    <section title="Requirements">
      <t>This section covers the requirements from various WG for
      setting up media. Obviously it does not try and cover all the
      requirements but it tries to cover a set that seem relevant to
      decisions around multiplexing onto few UDP ports. </t>

      <t>High Priority Requirements:<list style="numbers">
          
	<t> Support many media flows but minimize the number of
	transport flows. For instance, all media flows--or perhaps
        all media flows of a given type--might
        be multiplexed over a single transport flow.
	</t>

	<t>Be able to successfully negotiate media with both legacy
	SIP devices and new devices (whether SIP or RTCWEB) with a
	single offer/answer exchange.  If both endpoints support
	multiplexed media, then multiplexing should be
	negotiated. Otherwise, non-multiplexed media should be
	used. In many cases, each endpoints will have no prior knowledge of
	capabilities of the other endpoint.
        </t>
     </list></t>
 
   <t>Other Requirements:<list style="numbers">
   
	<t>Need a uniform way to allow specifications of new SDP
	parameters to easily explain any implications that multiplexing
	has on the new parameters in that specification. </t>

        <!--  These appear to be redundant with what I rewrote above.

	<t>Negotiation when both ends have different capabilities. </t>

	<t>No knowledge of capabilities of the other side before
	generating an SDP offer. </t>

	<t>Can reduce down to a small number of UDP transport flow within one
	offer/answer signaling roundtrip in cases where both sides implement all
	the WebRTC requirement. </t>
        -->


	<t>Allow different sources (E.g. cameras) to use different
	codecs. For example, if one camera had hardware encoders for
	VP8 while another had encoders for H.264, the device may wish
	to negotiate different codecs. </t>

	<t>Be able to to independently set parameters such as resolution
	bandwidth, independently for each RTCWeb Track, preferably
        even when they are all multiplexed over the same transport flow.
        </t>

	<t>Be able to identify the RTCWeb tracks with an identifier
	that is stable over the duration of the session. More
	information can be found in <xref
	target="I-D.alvestrand-mmusic-msid" />. </t>

<!--
	<t>For two RTCWeb implementations that both know the other
	support special signaling for adding and removing one way
	video flows, an approach that allows adding named video flows
	with a low chance of glare and remove of named video flows
	with simple glare resolution rules. </t>
-->

      </list></t>
    </section>
 

   <section title="Non-Requirements">
      <t> Some items are not a major goal. If methods are found that
      work for these as well, that is great, but they are not a
      priority item. </t>

      <t><list style="numbers">
          
<!--
	<t>Support of non RTP media. [EKR: I don't agree with this. Why can't
        we mux the data channel? It seems like a goal, even if we can't do it,
        and bundle would let you.]</t>
-->

	<t> Working with SIP proxies or B2BUA that are not compliant
	with the standards. The reason for this is it is just not
	possible to design for every possible thing that does not do
	what the standards require. </t>

      </list></t>
    </section>


    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>


    <section anchor="Security" title="Security Considerations">
      <t>These requirements have no additional security considerations
      other than those captured in <xref
      target="I-D.ietf-rtcweb-security-arch"></xref>.</t>
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t> Thanks to ...</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">

<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate
Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
 target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970'
 target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777'
 target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>


<reference anchor='I-D.ietf-rtcweb-security-arch'>
<front>
<title>RTCWEB Security Architecture</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='October' day='22' year='2012' />


</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-06.txt' />
</reference>

    </references>
   <references title="Informative References">


<reference anchor='I-D.alvestrand-mmusic-msid'>
<front>
<title>Cross Session Stream Identification in the Session Description Protocol</title>

<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>

<date month='December' day='13' year='2012' />

<abstract><t>This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams within different RTP sessions as well as within a single RTP session.  This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" using SDP signaling.  This document is an input document for discussion.  It should be discussed in the MMUSIC WG list, mmusic@ietf.org.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-alvestrand-mmusic-msid-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-02.txt' />
</reference>

    </references>

  </back>
</rfc>