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 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. IANA Considerations This document makes no request of IANA. 7. 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]