idnits 2.17.1 draft-lennox-payload-ulp-ssrc-mux-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5109, updated by this document, for RFC5378 checks: 2000-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-03 == Outdated reference: A later version (-03) exists of draft-westerlund-avtext-rtcp-sdes-srcname-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lennox 3 Internet-Draft Vidyo 4 Updates: 5109 (if approved) February 18, 2013 5 Intended status: Standards Track 6 Expires: August 22, 2013 8 Supporting Source-Multiplexing of the Real-Time Transport Protocol (RTP) 9 Payload for Generic Forward Error Correction 10 draft-lennox-payload-ulp-ssrc-mux-00 12 Abstract 14 The Real-Time Transport Protocol (RTP) Payload format for Generic 15 Forward Error Correction (FEC), specified in RFC 5109, forbids 16 transmitting FEC repair flows as separate sources in the same RTP 17 session as the flows being repaired. This document updates RFC 5109 18 to lift that restriction, as long as the association between original 19 and repair flows is properly signaled and negotiated. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 22, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Change to RFC 5109 . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Other mechanisms . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The Real-Time Transport Protocol (RTP) [RFC3550] payload format for 69 Generic Forward Error Correction (FEC) [RFC5109] defines two 70 mechanisms by which the Forward Error Correction stream can be 71 transmitted alongside the payload stream. As defined in Section 14 72 of that document, the packets can either be sent in separate SDP 73 media streams, i.e. a separate RTP session, associated through the 74 "FEC" semantics [RFC5956] of the SDP grouping framework [RFC5888]; or 75 they can be sent in the same packets, in an [RFC2198] redundant 76 coding. 78 The payload format specifically says that "the FEC and the payload 79 MUST NOT be multiplexed by SSRC into one single RTP session since 80 they always have the same SSRC." However, this constraint is only 81 necessary as a consequence of the fact that [RFC5109] chose to use 82 SSRC alignment to associate the payload and the repair streams sent 83 in separate RTP sessions. The mechanism described by which the 84 forward error correction packets are used to reconstruct missing 85 payload packets does not actually rely on this SSRC alignment 86 property. The "MUST NOT" results from the absence of any alternative 87 mechanism by which payload and repair streams can be associated. 89 The Source-Specific Media Attributes [RFC5576] specification defines 90 an "ssrc-group" semantic, "FEC", which is designed to address this 91 problem -- it allows endpoints to indicate, in SDP, the associations 92 among source flows and repair flows within a single RTP session, 93 through a similar mechanism to the [RFC5888] / [RFC5956] grouping of 94 RTP sessions. 96 However, [RFC5576] did not update the "MUST NOT" statement in 97 [RFC5109], so the FEC ssrc-group semantics arguably cannot be used. 98 This document fixes that oversight, updating [RFC5109] to clarify 99 when SSRC-multiplexed payload and repair streams can be used. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119] and 106 indicate requirement levels for compliant implementations. 108 3. Change to RFC 5109 110 This sentence, the final sentence of the third paragraph of section 111 14.1 of [RFC5109]: 113 In addition, the FEC and the payload MUST NOT be multiplexed by 114 SSRC into one single RTP session since they always have the same 115 SSRC. 117 is updated instead to read: 119 The FEC and the payload MAY also be multiplexed by SSRC into one 120 single RTP session, with separate SSRC values, if the association 121 between FEC and payload streams are communicated to all members of 122 the session. If SDP is used, this association MAY be communicated 123 through the FEC ssrc-group semantic [RFC5576]; other mechanisms 124 are also possible. Receivers MUST NOT attempt to interpret FEC 125 streams for which they do not have information to associate them 126 with the corresponding payload streams. 128 4. Other mechanisms 130 The wording about "other mechanisms" in the previous section is 131 designed to address the possibility that non-SDP mechanisms could 132 also be used to associate FEC and payload streams. Potential 133 examples of this would be the BUNDLE 134 [I-D.ietf-mmusic-sdp-bundle-negotiation] or SRCNAME 135 [I-D.westerlund-avtext-rtcp-sdes-srcname] proposals, if standardized. 137 5. Security Considerations 139 An attacker who could force a receiver to mis-associate payload 140 streams and repair streams could potentially trick a receiver into 141 mis-decoding streams. Thus, the association between payload streams 142 and repair streams MUST be integrity-protected with at least the same 143 strength of security as the streams are themselves. 145 6. IANA Considerations 147 This document makes no request of IANA. 149 7. References 151 7.1. Normative References 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, March 1997. 156 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 157 Correction", RFC 5109, December 2007. 159 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 160 Media Attributes in the Session Description Protocol 161 (SDP)", RFC 5576, June 2009. 163 7.2. Informative References 165 [I-D.ietf-mmusic-sdp-bundle-negotiation] 166 Holmberg, C., Alvestrand, H., and C. Jennings, 167 "Multiplexing Negotiation Using Session Description 168 Protocol (SDP) Port Numbers", 169 draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in 170 progress), February 2013. 172 [I-D.westerlund-avtext-rtcp-sdes-srcname] 173 Westerlund, M., Burman, B., and P. Sandgren, "RTCP SDES 174 Item SRCNAME to Label Individual Sources", 175 draft-westerlund-avtext-rtcp-sdes-srcname-02 (work in 176 progress), October 2012. 178 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 179 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 180 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 181 September 1997. 183 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 184 Jacobson, "RTP: A Transport Protocol for Real-Time 185 Applications", STD 64, RFC 3550, July 2003. 187 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 188 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 190 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 191 the Session Description Protocol", RFC 5956, 192 September 2010. 194 Author's Address 196 Jonathan Lennox 197 Vidyo, Inc. 198 433 Hackensack Avenue 199 Seventh Floor 200 Hackensack, NJ 07601 201 US 203 Email: jonathan@vidyo.com