<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="std" docName="draft-lennox-payload-ulp-ssrc-mux-00"
     ipr="trust200902" updates="5109">
  <front>
    <title abbrev="ULP FEC Source Multiplexing">Supporting Source-Multiplexing of the Real-Time Transport Protocol (RTP) Payload for Generic Forward Error Correction</title>

    <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
      <organization abbrev="Vidyo">Vidyo, Inc.</organization>

      <address>
        <postal>
          <street>433 Hackensack Avenue</street>
          <street>Seventh Floor</street>
          <city>Hackensack</city>
          <region>NJ</region>
          <code>07601</code>
          <country>US</country>
        </postal>

        <email>jonathan@vidyo.com</email>
      </address>
    </author>

    <date/>

    <area>RAI</area>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <!-- TODO: more keywords -->

    <abstract>
      <t>The Real-Time Transport Protocol (RTP) Payload format for Generic
      Forward Error Correction (FEC), specified in RFC 5109, forbids transmitting FEC repair
      flows as separate sources in the same RTP session as the flows
      being repaired.  This document updates RFC 5109 to lift that restriction, as long
      as the association between original and repair flows is
      properly signaled and negotiated.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">

	  <t>The <xref target="RFC3550">Real-Time Transport Protocol
	  (RTP)</xref> <xref target="RFC5109">payload format for
	  Generic Forward Error Correction (FEC)</xref> defines two mechanisms by
	  which the Forward Error Correction stream can be transmitted
	  alongside the payload stream.  As defined in Section 14 of that
	  document, the packets can either be sent in separate SDP media
	  streams, i.e. a separate RTP session, associated
	  through <xref target="RFC5956">the "FEC" semantics</xref> of
	  <xref target="RFC5888">the SDP grouping framework</xref>; or they can be sent in the
	  same packets, in an <xref target="RFC2198"/> redundant
	  coding.</t>

	  <t>The payload format specifically says that "the
	  FEC and the payload MUST NOT be multiplexed by SSRC into one
	  single RTP session since they always have the same SSRC."
	  However, this constraint is only necessary as a consequence of the
	  fact that <xref target="RFC5109"/> chose to use SSRC alignment
	  to associate the payload and the repair streams sent in separate
	  RTP sessions.  The mechanism described by which the forward error
	  correction packets are used to reconstruct missing payload
	  packets does not actually rely on this SSRC alignment
	  property.  The "MUST NOT" results from the absence of any
	  alternative mechanism by which payload and repair streams can be
	  associated.</t>

	  <t>The <xref target="RFC5576">Source-Specific Media
	  Attributes</xref> specification defines an "ssrc-group"
	  semantic, "FEC", which is designed to address this problem -- it
	  allows endpoints to indicate, in SDP, the associations among
	  source flows and repair flows within a single RTP session, through
	  a similar mechanism to the <xref target="RFC5888"/> /
	  <xref target="RFC5956"/> grouping of RTP sessions.</t>

	  <t>However, <xref target="RFC5576"/> did not update the "MUST
	  NOT" statement in <xref target="RFC5109"/>, so the FEC
	  ssrc-group semantics arguably cannot be used.  This document
	  fixes that oversight, updating <xref target="RFC5109"/> to
	  clarify when SSRC-multiplexed payload and repair streams can be
	  used.</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> and indicate
		requirement levels for compliant implementations.</t>

	</section>

	<section title="Change to RFC 5109">

	  <t>This sentence, the final sentence of the third paragraph of
	  section 14.1 of <xref target="RFC5109"/>:</t>

	  <t><list><t>In addition, the FEC and the payload MUST
			NOT be multiplexed by SSRC into one single RTP session since they
			always have the same SSRC.</t></list></t>

	  <t>is updated instead to read:</t>


	  <t><list><t>The FEC and the payload MAY also
			be multiplexed by SSRC into one single RTP session, with
			separate SSRC values, if the association between FEC and
			payload streams are communicated to all members of the
			session.  If SDP is used, this association MAY be communicated through
			<xref target="RFC5576">the FEC ssrc-group
			semantic</xref>; other mechanisms are also
			possible.  Receivers MUST NOT attempt to interpret FEC
			streams for which they do not have information
			to associate them with the corresponding payload streams.</t></list></t>

	</section>

	<section title="Other mechanisms">

	  <t>The wording about "other mechanisms" in the previous section is designed to address the
	  possibility that non-SDP mechanisms could also be used to associate FEC
	  and payload streams.  Potential examples of this would be 
	  the <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> or
		<xref target="I-D.westerlund-avtext-rtcp-sdes-srcname">SRCNAME</xref>
		proposals, if standardized.</t>

	</section>

    <section anchor="security" title="Security Considerations">
	  <t>An attacker who could force a receiver to mis-associate
	  payload streams and repair streams could potentially trick a
	  receiver into mis-decoding streams.  Thus, the association
	  between payload streams and repair streams MUST be
	  integrity-protected with at least the same strength of security
	  as the streams are themselves.</t>
    </section>

	<!--

    <section title="Open Issues">
    </section>

	-->

    <section anchor="iana" title="IANA Considerations">

	  <t>This document makes no request of IANA.</t>

	</section>

  </middle>

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

	  <?rfc include="reference.RFC.2119"?>

	  <?rfc include="reference.RFC.5109"?>

	  <?rfc include="reference.RFC.5576"?>

	</references>

    <references title="Informative References">
	  <?rfc include="reference.RFC.3550"?>

	  <?rfc include="reference.RFC.2198"?>

	  <?rfc include="reference.RFC.5888"?>
	  
	  <?rfc include="reference.RFC.5956"?>

	  <?rfc include="reference.I-D.westerlund-avtext-rtcp-sdes-srcname"?>

	  <?rfc include="reference.I-D.ietf-mmusic-sdp-bundle-negotiation"?>

    </references>

	<!-- Add this after version -00.

    <section title="Changes From Earlier Versions">
      <t>Note to the RFC-Editor: please remove this section prior to
      publication as an RFC.</t>

      <section title="Changes From Draft -00">
        <t><list style="symbols">
            <t></t>
        </list></t>
      </section>
    </section>

	-->


  </back>
</rfc>
