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

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]:

• 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

7.2. Informative References

Author's Address