draft-ietf-mmusic-rfc4756bis-07.txt   draft-ietf-mmusic-rfc4756bis-08.txt 
MMUSIC A. Begen MMUSIC A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Updates: 4756, 3388bis, 5576 April 2, 2010 Obsoletes: 4756 April 28, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 4, 2010 Expires: October 30, 2010
Forward Error Correction Grouping Semantics in Session Description Forward Error Correction Grouping Semantics in Session Description
Protocol Protocol
draft-ietf-mmusic-rfc4756bis-07 draft-ietf-mmusic-rfc4756bis-08
Abstract Abstract
The Session Description Protocol (SDP) supports grouping media lines. The Session Description Protocol (SDP) supports grouping media lines.
SDP also has semantics defined for grouping the associated source and SDP also has semantics defined for grouping the associated source and
Forward Error Correction (FEC)-based repair flows. However, the Forward Error Correction (FEC)-based repair flows. However, the
semantics that was defined in RFC 4756 generally fail to provide the semantics that were defined in RFC 4756 generally fail to provide the
specific grouping relationships between the source and repair flows specific grouping relationships between the source and repair flows
when there are more than one source and/or repair flows in the same when there is more than one source and/or repair flow in the same
group. Furthermore, the existing semantics does not support group. Furthermore, the existing semantics do not support describing
describing additive repair flows. This document addresses these additive repair flows. This document addresses these issues by
issues by introducing new FEC grouping semantics. SSRC-level introducing new FEC grouping semantics. Synchronization Source
grouping semantics is also introduced in this document for Real-time (SSRC)-level grouping semantics are also introduced in this document
Transport Protocol (RTP) streams using SSRC multiplexing. for Real-time Transport Protocol (RTP) streams using SSRC
multiplexing.
Note to the RFC Editor: In the "Updates" line above, please replace
that with the RFC number for draft-ietf-mmusic-rfc3388bis-04 when
that draft is published as an RFC .
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 4, 2010. This Internet-Draft will expire on October 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 22 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5 3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5
3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 3.1. Source and Repair Flow Associations . . . . . . . . . . . 5
3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6
4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6 4.1. Old "FEC" Grouping Semantics . . . . . . . . . . . . . . . 6
4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. New "FEC-FR" Grouping Semantics . . . . . . . . . . . . . 7
4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 4.3. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. SDP Offer-Answer Model and Backward Compatibility 4.4. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8
4.5. SDP Offer/Answer Model and Backward-Compatibility
Considerations . . . . . . . . . . . . . . . . . . . . . . 10 Considerations . . . . . . . . . . . . . . . . . . . . . . 10
4.5. ABNF Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Any application that needs a reliable transmission over an unreliable Any application that needs a reliable transmission over an unreliable
packet network has to cope with packet losses. Forward Error packet network has to cope with packet losses. Forward Error
Correction (FEC) is an effective approach that provides reliable Correction (FEC) is an effective approach that improves the
transmission particularly in multicast and broadcast applications reliabilty of the transmission particularly in multicast and
where the feedback from the receiver(s) is potentially limited. broadcast applications where the feedback from the receiver(s) is
potentially limited.
In a nutshell, FEC groups source packets into blocks and applies In a nutshell, FEC groups source packets into blocks and applies
protection to generate a desired number of repair packets. These protection to generate a desired number of repair packets. These
repair packets may be sent on demand or independently of any receiver repair packets may be sent on demand or independently of any receiver
feedback. The choice depends on the FEC scheme, the packet loss feedback. The choice depends on the FEC scheme, the packet loss
characteristics of the underlying network, the transport scheme characteristics of the underlying network, the transport scheme
(e.g., unicast, multicast and broadcast) and the application. At the (e.g., unicast, multicast and broadcast) and the application. At the
receiver side, lost packets can be recovered by erasure decoding receiver side, lost packets can be recovered by erasure decoding
provided that a sufficient number of source and repair packets have provided that a sufficient number of source and repair packets have
been received. been received.
skipping to change at page 3, line 52 skipping to change at page 4, line 5
purpose. purpose.
In order to provide applications more flexibility, the FEC Framework In order to provide applications more flexibility, the FEC Framework
[I-D.ietf-fecframe-framework] allows a source flow to be protected by [I-D.ietf-fecframe-framework] allows a source flow to be protected by
multiple FEC schemes, each of which requires an instance of the FEC multiple FEC schemes, each of which requires an instance of the FEC
Framework. Thus, multiple instances of the FEC Framework may exist Framework. Thus, multiple instances of the FEC Framework may exist
at the sender and the receiver(s). Furthermore, within a single FEC at the sender and the receiver(s). Furthermore, within a single FEC
Framework instance, multiple source flows may be grouped and Framework instance, multiple source flows may be grouped and
protected by one or more repair flows. protected by one or more repair flows.
It should be noted that the FEC Framework requires the source and The FEC Framework requires the source and repair packets to be
repair packets to be carried in different streams. When Real-time carried in different streams. When Real-time Transport Protocol
Transport Protocol (RTP) [RFC3550] is used to carry the source and (RTP) [RFC3550] is used to carry the source and repair streams, the
repair streams, the FEC Framework recommends that each stream is FEC Framework recommends that each stream is carried in its own RTP
carried in its own RTP session. This provides flexibility in using session. This provides flexibility in using FEC in a backward-
FEC in a backward-compatible manner. However, in some scenarios, a compatible manner. However, in some scenarios, a single RTP session
single RTP session may be desired to carry multiple RTP streams via may be desired to carry multiple RTP streams via Synchronization
SSRC multiplexing in order to reduce the port usage. For such Source (SSRC) multiplexing in order to reduce the port usage. For
scenarios, an appropriate grouping semantics is also required. such scenarios, appropriate grouping semantics are also required.
A basic example scenario is shown in Figure 1. Here, source flow S1 A basic example scenario is shown in Figure 1. Here, source flow S1
is protected by repair flow R1. Also, source flows S1 and S2 are is protected by repair flow R1. Also, source flows S1 and S2 are
grouped and protected together by repair flow R2. grouped and protected together by repair flow R2.
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
| S1: Source Flow |--------| R1: Repair Flow | S1: Source Flow |--------| R1: Repair Flow
+---| +---|
| | S2: Source Flow | | S2: Source Flow
| |
skipping to change at page 4, line 38 skipping to change at page 4, line 40
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 The grouping semantics defined in this document offer the flexibility
document offers the flexibility to determine how source streams are to determine how source streams are grouped together prior to
grouped together prior to applying FEC protection. However, not all applying FEC protection. However, not all FEC schemes may support
FEC schemes support the full range of the possible scenarios (e.g., the full range of the possible scenarios (e.g., when the source
when the source streams carry different top-level media types such as streams carry different top-level media types such as audio and
audio and video). 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 to
receiving the appropriate repair flow(s) that they can support and receive 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
is particularly useful in multicast scenarios where different is particularly useful in multicast scenarios where different
receivers may experience different packet loss rates and each receivers may experience different packet loss rates and each
receiver can choose the repair flow that is tailored to its needs. receiver can choose the repair flow that is tailored to its needs.
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
skipping to change at page 5, line 42 skipping to change at page 5, line 43
4. One or more repair flows protect a group of source flows. 4. One or more repair flows protect a group of source flows.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Requirements and Changes from RFC 4756 3. Requirements and Changes from RFC 4756
3.1. Source and Repair Flow Association 3.1. Source and Repair Flow Associations
The FEC grouping semantics and 'group' attribute defined in this The FEC grouping semantics and 'group' attribute defined in this
document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to
associate source and repair flows together. This document also associate source and repair flows. This document also specifies how
specifies how the 'group' attribute in SDP is used to group multiple the 'group' attribute [I-D.ietf-mmusic-rfc3388bis] in SDP is used to
repair flows with one or more source flows. group multiple repair flows with one or more source flows.
[I-D.ietf-mmusic-rfc3388bis] updates [RFC3388] to allow an "m" line [I-D.ietf-mmusic-rfc3388bis] obsoletes [RFC3388] to allow an "m" line
identified by its 'mid' attribute to appear in more than one identified by its 'mid' attribute to appear in more than one
"a=group" line using the same semantics. With this change and other "a=group" line using the same semantics. With this change and other
required changes in the grouping semantics for FEC, a sender is required changes in the grouping semantics for FEC, a sender is
allowed to indicate the specific associations between the source and allowed to indicate the specific associations between the source and
repair flows, and a receiver can determine which repair flow(s) repair flows, and a receiver can determine which repair flow(s)
protect which source flow(s). protect which source flow(s).
This document introduces the changes required in the FEC grouping This document introduces the changes required in the FEC grouping
semantics and updates [RFC4756]. New implementations SHOULD use the semantics and obsoletes [RFC4756]. New implementations SHOULD use
new semantics introduced in this document whenever possible, but they the new semantics introduced in Section 4.2 and Section 4.4 of this
may need to use [RFC4756] semantics when backward compatibility is document whenever possible, but they may need to use the obsoleted
desired, as described in Section 4.4. semantics given in Section 4.1 when backward compatibility is
desired, as described in Section 4.5.
3.2. Support for Additivity 3.2. Support for Additivity
The FEC Framework also supports additive repair flows. Additivity The FEC Framework also supports additive repair flows. Additivity
among the repair flows means that multiple repair flows may be among the repair flows means that multiple repair flows may be
decoded jointly to improve the recovery chances of the missing decoded jointly to improve the recovery chances of the missing
packets in a single or the same set of source flows. Additive repair packets in a single or the same set of source flows. Additive repair
flows can be generated by the same FEC scheme or different FEC flows can be generated by the same FEC scheme or different FEC
schemes. schemes.
skipping to change at page 6, line 45 skipping to change at page 6, line 46
| |
|---------| FEC FRAMEWORK INSTANCE #2 |---------| FEC FRAMEWORK INSTANCE #2
| R7: Repair Flow | R7: Repair Flow
Figure 3: Example scenario with two FEC Framework instances, where Figure 3: Example scenario with two FEC Framework instances, where
two repair flows in the first instance and a single repair flow in two repair flows in the first instance and a single repair flow in
the second instance protect the same source flow S4 the second instance protect the same source flow S4
4. FEC Grouping 4. FEC Grouping
4.1. New Grouping Semantics 4.1. Old "FEC" Grouping Semantics
The old "FEC" grouping semantics had been introduced in [RFC4756],
and were based on [RFC3388]. The "FEC" semantics used the "a=group"
line to form an FEC Group to indicate the association relationship
between the source and repair flows.
In the "FEC" semantics, a source or repair flow could only appear in
a single "a=group:FEC" line. Thus, all the source and repair flows
that are somehow related to each other have to be listed in the same
"a=group:FEC" line. For example, for the scenario sketched in
Figure 1, we must write "a=group:FEC S1 S2 R1 R2" regardless of which
repair flows protect which particular source flows. Similarly, for
the scenario sketched in Figure 3, we must write "a=group:FEC S4 R5
R6 R7" regardless of which repair flows are additive.
In certain simple scenarios such as where there is one source flow or
one repair flow, these limitations will not be a concern. In
scenarios where using the "FEC" grouping semantics will provide an
exact association among the source and repair flows and will not
create any ambiguity, the "FEC" semantics can be safely used when
backward compatibility is essential.
4.2. New "FEC-FR" Grouping Semantics
Each "a=group" line is used to indicate an association relationship Each "a=group" line is used to indicate an association relationship
between the source and repair flows. The flows included in one between the source and repair flows. The flows included in one
"a=group" line are called an FEC Group. If there are more than one "a=group" line are called an FEC Group. If there is more than one
repair flows included in an FEC group, they MUST be considered to be repair flow included in an FEC group, they MUST be considered to be
additive. Repair flows that are not additive MUST be indicated in additive. Repair flows that are not additive MUST be indicated in
separate FEC groups. However, if two (or more) repair flows are separate FEC groups. However, if two (or more) repair flows are
additive in an FEC group, it does not necessarily mean that these additive in an FEC group, it does not necessarily mean that these
repair flows will also be additive in any other FEC group. repair flows will also be additive in any other FEC group.
Generally, in order to express multiple relations between the source Generally, in order to express multiple relations between the source
and repair flows, each source and repair flow MAY appear in more than and repair flows, each source and repair flow MAY appear in more than
one FEC group. one FEC group.
By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-FR" as the By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-FR" as the
new grouping semantics that can support the features of the FEC new grouping semantics that can support the features of the FEC
Framework. Framework.
The "a=group:FEC-FR" semantics MUST always be used to associate the The "a=group:FEC-FR" semantics MUST always be used to associate the
source and repair flows except when the source and repair flows are source and repair flows except when the source and repair flows are
specified in the same media description, i.e., in the same "m" line. specified in the same media description, i.e., in the same "m" line.
Note that additivity is not necessarily a transitive relation. Thus, Note that additivity is not necessarily a transitive relationship.
each set of additive repair flows MUST be stated explicitly. Thus, each set of additive repair flows MUST be stated explicitly.
4.2. SDP Example 4.3. SDP Example
For the scenario sketched in Figure 1, we need to write the following For the scenario sketched in Figure 1, we need to write the following
SDP: SDP:
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 s=New FEC Grouping Semantics
t=0 0 t=0 0
a=group:FEC-FR S1 R1 a=group:FEC-FR S1 R1
a=group:FEC-FR S1 S2 R2 a=group:FEC-FR S1 S2 R2
skipping to change at page 8, line 42 skipping to change at page 8, line 42
FEC-FR" lines. FEC-FR" 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-FR S4 R5 R6 a=group:FEC-FR S4 R5 R6
a=group:FEC-FR S4 R7 a=group:FEC-FR S4 R7
If none of the repair flows are additive, we must write If none of the repair flows is additive, we must write
a=group:FEC-FR S4 R5 a=group:FEC-FR S4 R5
a=group:FEC-FR S4 R6 a=group:FEC-FR S4 R6
a=group:FEC-FR S4 R7 a=group:FEC-FR S4 R7
4.3. Grouping for SSRC-Multiplexed RTP Streams 4.4. Grouping for SSRC-Multiplexed RTP Streams
[RFC5576] defines a grouping attribute, called 'ssrc-group', for the [RFC5576] defines a grouping attribute, called 'ssrc-group', for the
RTP streams that are SSRC multiplexed and carried in the same RTP RTP streams that are SSRC multiplexed and carried in the same RTP
session. The grouping is based on the Synchronization Source (SSRC) session. The grouping is based on the Synchronization Source (SSRC)
identifiers. Since SSRC-multiplexed RTP streams are defined in the identifiers. Since SSRC-multiplexed RTP streams are defined in the
same "m" line, the 'group' attribute cannot be used. same "m" line, the 'group' attribute cannot be used.
This document extends [RFC5576] in two ways. First, we define how This document extends [RFC5576] in two ways. First, we define how
FEC is applied to source and repair flows for SSRC-multiplexed FEC is applied to source and repair flows for SSRC-multiplexed
streams using the 'ssrc-group' attribute. We then specify how the streams using the 'ssrc-group' attribute. We then specify how the
additivity of the repair flows is expressed for the SSRC-multiplexed additivity of the repair flows is expressed for the SSRC-multiplexed
streams. streams.
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 [RFC5576]. The semantics of "FEC-FR" for the 'ssrc- media level [RFC5576]. The semantics of "FEC-FR" for the 'ssrc-
group' attribute is exactly the same as the one defined for the group' attribute are exactly the same as 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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
a=ssrc-group:FEC-FR 1000 2110 a=ssrc-group:FEC-FR 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
payload type. payload type.
The additivity of the repair flows is handled in the same way as The additivity of the repair flows is handled in the same way as
described in Section 4.2. In other words, the repair flows that are described in Section 4.3. In other words, the repair flows that are
included in an "a=ssrc-group" line MUST be additive. Repair flows included in an "a=ssrc-group" line MUST be additive. Repair flows
that are not additive MUST be indicated in separate "a=ssrc-group" that are not additive MUST be indicated in separate "a=ssrc-group"
lines. lines.
4.4. SDP Offer-Answer Model and Backward Compatibility Considerations 4.5. SDP Offer/Answer Model and Backward-Compatibility Considerations
When offering FEC grouping using SDP in an Offer/Answer model When offering FEC grouping using SDP in an Offer/Answer model
[RFC3264], the following considerations apply. [RFC3264], the following considerations apply.
A node that is receiving an offer from a sender may or may not A node that is receiving an offer from a sender may or may not
understand line grouping. It is also possible that the node understand line grouping. It is also possible that the node
understands line grouping but it does not understand the "FEC-FR" understands line grouping but it does not understand the "FEC-FR"
semantics. From the viewpoint of the sender of the offer, these semantics. From the viewpoint of the sender of the offer, these
cases are indistinguishable. cases are indistinguishable.
When a node is offered a session with the "FEC-FR" grouping semantics When a node is offered a session with the "FEC-FR" grouping semantics
but it does not support line grouping or the FEC grouping semantics, but it does not support line grouping or the FEC grouping semantics,
the node SHOULD respond to the offer either: the node responds to the offer either:
o With an answer that ignores the grouping attribute. o With an answer that ignores the grouping attribute.
In this case, the original sender of the offer MUST first check In this case, the original sender of the offer MUST first check
whether using the "FEC" grouping semantics will create any whether using the "FEC" grouping semantics from Section 4.1 will
ambiguity or not, while keeping its limitations in mind. If using create any ambiguity or not, while keeping its limitations in
the "FEC" semantics rather than the "FEC-FR" semantics still mind. If using the "FEC" semantics rather than the "FEC-FR"
provides an exact association among the source and repair flows, semantics still provides an exact association among the source and
the sender of the offer MUST send a new offer using the "FEC" repair flows, the sender of the offer MUST send a new offer using
semantics. However, if an exact association cannot be described, the "FEC" semantics. However, if an exact association cannot be
the sender MUST send a new offer without FEC. described, the sender MUST send a new offer without FEC.
o With a refusal to the request (e.g., 488 Not Acceptable Here or o With a refusal to the request (e.g., 488 Not Acceptable Here or
606 Not Acceptable in SIP). 606 Not Acceptable in SIP).
In this case, if the sender of the offer still wishes to establish In this case, if the sender of the offer still wishes to establish
the session, it MUST first check whether using the "FEC" grouping the session, it MUST first check whether using the "FEC" grouping
semantics will create any ambiguity or not, while keeping its semantics from Section 4.1 will create any ambiguity or not, while
limitations in mind. If using the "FEC" semantics rather than the keeping its limitations in mind. If using the "FEC" semantics
"FEC-FR" semantics still provides an exact association among the rather than the "FEC-FR" semantics still provides an exact
source and repair flows, the sender of the offer SHOULD send a new association among the source and repair flows, the sender of the
offer using the "FEC" semantics. However, if an exact association offer SHOULD send a new offer using the "FEC" semantics. However,
cannot be described, the sender SHOULD send a new offer without if an exact association cannot be described, the sender SHOULD
FEC. send a new offer without FEC.
Note that in both cases described above, when the sender of the offer This behaviour is as specified in [I-D.ietf-mmusic-rfc3388bis]. Note
that in both cases described above, when the sender of the offer
sends a new offer with the "FEC" semantics, and the node understands sends a new offer with the "FEC" semantics, and the node understands
it, the session will be established and the rules pertaining to it, the session will be established and the rules pertaining to the
[RFC4756] will apply. "FEC" semantics will apply.
However, if the node does not understand the "FEC" semantics, it
SHOULD respond to the offer either (1) with an answer that ignores
the grouping attribute, or (2) with a refusal to the request. In the
first case, the sender MUST send a new offer without FEC. In the
second case, if the sender of the offer still wishes to establish the
session, it SHOULD retry the request with an offer without FEC.
4.5. ABNF Syntax
Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC.
A new semantics ("FEC-FR") is defined for the 'group' attribute
[I-D.ietf-mmusic-rfc3388bis]. Its formatting in SDP is described by
the following ABNF [RFC5234]:
group-attribute = "a=group:" semantics
*(space identification-tag)
semantics = "LS" / "FID" /
"FEC" / ; from [RFC4756] for backward
; compatibility
"FEC-FR" ; from [RFCXXXX]
identification-tag = token
The identification tags MUST be unique within an SDP session If the node does not understand the "FEC" semantics, it responds to
description. the offer, as specified in [I-D.ietf-mmusic-rfc3388bis], either (1)
with an answer that ignores the grouping attribute, or (2) with a
refusal to the request. In the first case, the sender MUST send a
new offer without FEC. In the second case, if the sender of the
offer still wishes to establish the session, it SHOULD retry the
request with an offer without FEC.
5. Security Considerations 5. Security Considerations
There is a weak threat for the receiver that the FEC grouping can be There is a weak threat for the receiver that the FEC grouping can be
modified to indicate FEC relationships that do not exist. Such modified to indicate FEC relationships that do not exist. Such
attacks may result in failure of FEC to protect, and/or mishandling attacks may result in failure of FEC to protect, and/or mishandle
of other media payload streams. It is RECOMMENDED that the receiver other media payload streams. The receiver SHOULD do an integrity
SHOULD do integrity check on SDP and follow the security check on SDP and follow the security considerations of SDP [RFC4566]
considerations of SDP [RFC4566] to only trust SDP from trusted to only trust SDP from trusted sources.
sources.
6. IANA Considerations 6. IANA Considerations
This document registers the following semantics with IANA in This document registers the following semantics with IANA in
Semantics for the 'group' SDP Attribute under SDP Parameters: Semantics for the 'group' SDP Attribute under SDP Parameters:
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
Semantics Token Reference Semantics Token Reference
skipping to change at page 13, line 5 skipping to change at page 12, line 23
Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters:
Semantics Token Reference Semantics Token Reference
--------------------------- ------ --------- --------------------------- ------ ---------
Forward Error Correction FR FEC-FR [RFCXXXX] Forward Error Correction FR FEC-FR [RFCXXXX]
7. Acknowledgments 7. Acknowledgments
Some parts of this document are based on [RFC4756]. Thus, the author Some parts of this document are based on [RFC4756]. Thus, the author
would like to thank those who contributed to [RFC4756]. Also, thanks would like to thank those who contributed to [RFC4756]. Also, thanks
to Jonathan Lennox who has contributed to Section 4.3. to Jonathan Lennox who has contributed to Section 4.4.
8. References 8. References
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.
skipping to change at page 13, line 35 skipping to change at page 13, line 6
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.
[RFC5576] 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 Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 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-07 (work in progress), draft-ietf-fecframe-framework-07 (work in progress),
March 2010. March 2010.
[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. [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.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
 End of changes. 40 change blocks. 
123 lines changed or deleted 123 lines changed or added

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