Network Working Group                                          J. Lennox
Internet-Draft                                                     Vidyo
Updates: 5109 (if approved)                            February 18, 2013
Intended status: Standards Track
Expires: August 22, 2013


Supporting Source-Multiplexing of the Real-Time Transport Protocol (RTP)
              Payload for Generic Forward Error Correction
                  draft-lennox-payload-ulp-ssrc-mux-00

Abstract

   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.

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 http://datatracker.ietf.org/drafts/current/.

   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 August 22, 2013.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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



Lennox                   Expires August 22, 2013                [Page 1]

Internet-Draft         ULP FEC Source Multiplexing         February 2013


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Change to RFC 5109  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Other mechanisms  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5


































Lennox                   Expires August 22, 2013                [Page 2]

Internet-Draft         ULP FEC Source Multiplexing         February 2013


.  Introduction

   The Real-Time Transport Protocol (RTP) [RFC3550] payload format for
   Generic Forward Error Correction (FEC) [RFC5109] 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 the
   "FEC" semantics [RFC5956] of the SDP grouping framework [RFC5888]; or
   they can be sent in the same packets, in an [RFC2198] redundant
   coding.

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

   The Source-Specific Media Attributes [RFC5576] 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 [RFC5888] / [RFC5956] grouping of
   RTP sessions.

   However, [RFC5576] did not update the "MUST NOT" statement in
   [RFC5109], so the FEC ssrc-group semantics arguably cannot be used.
   This document fixes that oversight, updating [RFC5109] to clarify
   when SSRC-multiplexed payload and repair streams can be used.


.  Terminology

   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 RFC 2119 [RFC2119] and
   indicate requirement levels for compliant implementations.


.  Change to RFC 5109

   This sentence, the final sentence of the third paragraph of section
   14.1 of [RFC5109]:



Lennox                   Expires August 22, 2013                [Page 3]

Internet-Draft         ULP FEC Source Multiplexing         February 2013


      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.

   is updated instead to read:

      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 the FEC ssrc-group semantic [RFC5576]; 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.


.  Other mechanisms

   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 BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation] or SRCNAME
   [I-D.westerlund-avtext-rtcp-sdes-srcname] proposals, if standardized.


.  Security Considerations

   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.


.  IANA Considerations

   This document makes no request of IANA.


.  References

7.1.  Normative References

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

   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error



Lennox                   Expires August 22, 2013                [Page 4]

Internet-Draft         ULP FEC Source Multiplexing         February 2013


              Correction", RFC 5109, December 2007.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

7.2.  Informative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Multiplexing Negotiation Using Session Description
              Protocol (SDP) Port Numbers",
              draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in
              progress), February 2013.

   [I-D.westerlund-avtext-rtcp-sdes-srcname]
              Westerlund, M., Burman, B., and P. Sandgren, "RTCP SDES
              Item SRCNAME to Label Individual Sources",
              draft-westerlund-avtext-rtcp-sdes-srcname-02 (work in
              progress), October 2012.

   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
              Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
              September 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
              the Session Description Protocol", RFC 5956,
              September 2010.















Lennox                   Expires August 22, 2013                [Page 5]

Internet-Draft         ULP FEC Source Multiplexing         February 2013


Author's Address

   Jonathan Lennox
   Vidyo, Inc.
   433 Hackensack Avenue
   Seventh Floor
   Hackensack, NJ  07601
   US

   Email: jonathan@vidyo.com









































Lennox                   Expires August 22, 2013                [Page 6]