--- 1/draft-ietf-mmusic-rfc4756bis-02.txt 2009-09-23 21:12:14.000000000 +0200 +++ 2/draft-ietf-mmusic-rfc4756bis-03.txt 2009-09-23 21:12:14.000000000 +0200 @@ -1,21 +1,21 @@ MMUSIC A. Begen Internet-Draft Cisco Systems -Obsoletes: 4756 April 30, 2009 +Obsoletes: 4756 September 23, 2009 (if approved) Intended status: Standards Track -Expires: November 1, 2009 +Expires: March 27, 2010 Forward Error Correction Grouping Semantics in Session Description Protocol - draft-ietf-mmusic-rfc4756bis-02 + draft-ietf-mmusic-rfc4756bis-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -24,21 +24,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 1, 2009. + This Internet-Draft will expire on March 27, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -153,20 +153,27 @@ Grouping source flows before applying FEC protection may allow us to achieve a better coding performance. As a typical scenario, suppose that source flows S1 and S2 in Figure 1 correspond to the base and enhancement layers in a layered video content, respectively. Repair flow R2 protects the combination of the base and enhancement layers for the receivers who receive both layers, and repair flow R1 protects the base layer only, for the receivers who want the base layer only, or who receive both layers but prefer FEC protection for the base layer only due to a bandwidth and/or any other limitation. + It should be noted that the grouping semantics defined in this + document offers flexibility about which source streams can be grouped + together prior to FEC protection. However, not all FEC schemes + support the full range of the possible scenarios (e.g., when the + source streams carry different top-level media types such as audio + and video). + Using multiple FEC Framework instances for a single source flow provides flexibility to the receivers. An example scenario is sketched in Figure 2. Different instances may offer repair flows that are generated by different FEC schemes, and receivers choose receiving the appropriate repair flow(s) that they can support and decode. Alternatively, different instances (whether they use the same FEC scheme or not) may use larger and smaller source block sizes, which accommodate the receivers that have looser and tighter latency requirements, respectively. In addition, different instances may also provide FEC protection at different redundancy levels. This @@ -285,35 +293,36 @@ c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=mid:S1 m=video 30000 RTP/AVP 101 c=IN IP4 233.252.0.2/127 a=rtpmap:101 MP2T/90000 a=mid:S2 m=application 30000 RTP/AVP 110 c=IN IP4 233.252.0.3/127 a=rtpmap:110 1d-interleaved-parityfec/90000 - a=fmtp:110 L:5; D:10; repair-window: 200000 + a=fmtp:110 L=5; D=10; repair-window=200000 a=mid:R1 m=application 30000 RTP/AVP 111 c=IN IP4 233.252.0.4/127 a=rtpmap:111 1d-interleaved-parityfec/90000 - a=fmtp:111 L:10; D:10; repair-window: 400000 + a=fmtp:111 L=10; D=10; repair-window=400000 a=mid:R2 In this example, the source and repair flows are carried in their own RTP sessions and the grouping is achieved through the "a=group: FEC-XR" lines. For the additivity issues, let us consider the scenario sketched in Figure 3. Suppose that repair flows R5 and R6 are additive but repair flow R7 is not additive with any of the other repair flows. + In this case, we MUST write a=group:FEC-XR S4 R5 R6 a=group:FEC-XR S4 R7 If none of the repair flows are additive, we MUST write a=group:FEC-XR S4 R5 a=group:FEC-XR S4 R6 a=group:FEC-XR S4 R7 @@ -316,34 +325,34 @@ a=group:FEC-XR S4 R5 a=group:FEC-XR S4 R6 a=group:FEC-XR S4 R7 Note that additivity is not necessarily a transitive relation. Thus, each set of additive repair flows MUST be stated explicitly. 4.3. Grouping for SSRC-Multiplexed RTP Streams - [I-D.ietf-mmusic-sdp-source-attributes] defines a grouping attribute, - called 'ssrc-group', for the RTP streams that are SSRC multiplexed - and carried in the same RTP session. The grouping is based on the - Synchronization Source (SSRC) identifiers. Since SSRC-multiplexed - RTP streams are defined in the same "m" line, the 'group' attribute - cannot be used. Instead, the 'ssrc-group' attribute MUST be used. + [RFC5576] defines a grouping attribute, called 'ssrc-group', for the + RTP streams that are SSRC multiplexed and carried in the same RTP + session. The grouping is based on the Synchronization Source (SSRC) + identifiers. Since SSRC-multiplexed RTP streams are defined in the + same "m" line, the 'group' attribute cannot be used. Instead, the + 'ssrc-group' attribute MUST be used. Per [RFC3550], the SSRC identifiers for the RTP streams that are carried in the same RTP session MUST be unique. However, the SSRC identifiers are not guaranteed to be unique among different RTP sessions. Thus, the 'ssrc-group' attribute MUST only be used at the - media level [I-D.ietf-mmusic-sdp-source-attributes]. The semantics - of "FEC-XR" for the 'ssrc-group' attribute is exactly the same as the - one defined for the 'group' attribute. + media level [RFC5576]. The semantics of "FEC-XR" for the 'ssrc- + group' attribute is exactly the same as the one defined for the + 'group' attribute. Let us consider the following scenario where there are two source flows (e.g., one video and one audio) and a single repair flow that protects only one of the source flows (e.g., video). Suppose that all these flows are separate RTP streams that are SSRC multiplexed in the same RTP session. SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 S5: Source Flow |--------| R8: Repair Flow S6: Source Flow @@ -355,21 +364,21 @@ v=0 o=ali 1122334455 1122334466 IN IP4 fec.example.com s=New FEC Grouping Semantics for SSRC Multiplexing t=0 0 m=video 30000 RTP/AVP 100 101 110 c=IN IP4 233.252.0.1/127 a=rtpmap:100 JPEG/90000 a=rtpmap:101 L16/32000/2 a=rtpmap:110 1d-interleaved-parityfec/90000 - a=fmtp:110 L:5; D:10; repair-window: 200000 + a=fmtp:110 L=5; D=10; repair-window=200000 a=ssrc:1000 cname:fec@example.com a=ssrc:1010 cname:fec@example.com a=ssrc:2110 cname:fec@example.com a=ssrc-group:FEC-XR 1000 2110 a=mid:Group1 Note that in actual use, SSRC values, which are random 32-bit numbers, may be much larger than the ones shown in this example. Also note that before receiving an RTP packet for each stream, the receiver cannot know which SSRC identifier is associated with which @@ -472,43 +481,41 @@ 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [I-D.ietf-mmusic-rfc3388bis] Camarillo, G., "The SDP (Session Description Protocol) - Grouping Framework", draft-ietf-mmusic-rfc3388bis-02 (work - in progress), January 2009. + Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work + in progress), July 2009. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. - [I-D.ietf-mmusic-sdp-source-attributes] - Lennox, J., Ott, J., and T. Schierl, "Source-Specific + [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol - (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work - in progress), October 2008. + (SDP)", RFC 5576, June 2009. 8.2. Informative References [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", - draft-ietf-fecframe-framework-03 (work in progress), - October 2008. + draft-ietf-fecframe-framework-05 (work in progress), + July 2009. [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. Author's Address