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

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/