draft-ietf-mmusic-rfc4756bis-01.txt   draft-ietf-mmusic-rfc4756bis-02.txt 
MMUSIC A. Begen MMUSIC A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4756 (if approved) March 8, 2009 Obsoletes: 4756 April 30, 2009
(if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 9, 2009 Expires: November 1, 2009
Forward Error Correction Grouping Semantics in Session Description Forward Error Correction Grouping Semantics in Session Description
Protocol Protocol
draft-ietf-mmusic-rfc4756bis-01 draft-ietf-mmusic-rfc4756bis-02
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 34 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 September 9, 2009. This Internet-Draft will expire on November 1, 2009.
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 2, line 4 skipping to change at page 2, line 8
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
and restrictions with respect to this document. and restrictions with respect to this document.
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 were defined in RFC 4756 generally fail to provide the semantics that was 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 are more than one source and/or repair flows in the same
group. Furthermore, the existing semantics also do not support group. Furthermore, the existing semantics does not support
additive repair flows. This document addresses these issues by describing additive repair flows. This document addresses these
introducing new FEC grouping semantics. issues by introducing new FEC grouping semantics. SSRC-level
grouping semantics is also introduced in this document for Real-time
Transport Protocol (RTP) streams using SSRC multiplexing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Issues with RFC 4756 . . . . . . . . . . . . 5 3. Requirements and Issues with RFC 4756 . . . . . . . . . . . . 5
3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 3.1. Source and Repair Flow Association . . . . . . . . . . . . 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. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6
4.2. Offer-Answer Model Considerations . . . . . . . . . . . . 7 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Example of FEC Grouping . . . . . . . . . . . . . . . . . 7 4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.4. Offer-Answer Model Considerations . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 provides reliable
transmission particularly in multicast and broadcast applications transmission particularly in multicast and broadcast applications
where the feedback from the receiver(s) is potentially limited. 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 or the Content feedback. The choice depends on the FEC scheme, the packet loss
Delivery Protocol used by the application, 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 (e.g., unicast, multicast and broadcast) and the application. At the
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.
For example, one of the most basic FEC schemes is the parity codes, For example, one of the most basic FEC schemes is the parity codes,
where an XOR operation is applied to a group of packets (i.e., source where an exclusive OR (XOR) operation is applied to a group of
block) to generate a single repair packet. At the receiver side, packets (i.e., source block) to generate a single repair packet. At
this scheme achieves a full recovery if only one packet is lost the receiver side, this scheme provides a full recovery if only one
within the source block and the repair packet is received. There are packet is lost within the source block and the repair packet is
various other ways of generating repair packets, possibly with received. There are various other ways of generating repair packets,
different loss-recovery capabilities. possibly with different loss-recovery capabilities.
The FEC Framework [I-D.ietf-fecframe-framework] outlines a general The FEC Framework [I-D.ietf-fecframe-framework] outlines a general
framework for using FEC codes in multimedia applications that stream framework for using FEC codes in multimedia applications that stream
audio, video or other types of multimedia content. The FEC Framework audio, video or other types of multimedia content. The FEC Framework
specification states that source and repair packets MUST be carried specification states that source and repair packets MUST be carried
in different streams, which are referred to as the source and repair in different streams, which are referred to as the source and repair
flows, respectively. At the receiver side, the receivers should know flows, respectively. At the receiver side, the receivers should know
which flows are the source flows and which flows are the repair which flows are the source flows and which flows are the repair
flows. The receivers should also know the exact association of the flows. The receivers should also know the exact association of the
source and repair flows so that they can use the correct data to source and repair flows so that they can use the correct data to
skipping to change at page 4, line 5 skipping to change at page 3, line 52
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
repair packets to be carried in different streams. When Real-time
Transport Protocol (RTP) [RFC3550] is used to carry the source and
repair streams, the FEC Framework recommends that each stream is
carried in its own RTP session. This provides flexibility in using
FEC in a backward-compatible manner. However, in some scenarios, a
single RTP session may be desired to carry multiple RTP streams via
SSRC multiplexing in order to reduce the port usage. For such
scenarios, an appropriate grouping semantics is 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
| |
+______________________________| FEC FRAMEWORK INSTANCE #2 +______________________________| FEC FRAMEWORK INSTANCE #2
| R2: Repair Flow | R2: Repair Flow
Figure 1: Example scenario with two FEC Framework instances where R1 Figure 1: Example scenario with two FEC Framework instances where R1
protects S1, and R2 protects the group of S1 and S2 protects S1, and R2 protects the group of S1 and S2
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 layer 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 processing-power the base layer only due to a bandwidth and/or any other limitation.
limitation.
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
is particularly useful in multicast scenarios where different is particularly useful in multicast scenarios where different
receivers might 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
S3: Source Flow |---------| R3: Repair Flow S3: Source Flow |---------| R3: Repair Flow
| |
|---------| FEC FRAMEWORK INSTANCE #2 |---------| FEC FRAMEWORK INSTANCE #2
| R4: Repair Flow | R4: Repair Flow
Figure 2: Example scenario with two FEC Framework instances, each Figure 2: Example scenario with two FEC Framework instances, each
with a single repair flow protecting the same source flow S3 with a single repair flow protecting the same source flow S3
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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. New 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 are more than one
repair flows included in an FEC group, they are considered to be repair flows included in an FEC group, they are considered to be
additive. Repair flows that are in different FEC groups are non- additive. Repair flows that are in different FEC groups are non-
additive. additive.
By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" as the By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" 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.
4.2. Offer-Answer Model Considerations The "a=group:FEC-XR" semantics MUST always be used to associate the
source and repair flows except when the source and repair flows are
The backward compatibility in offer / answer is generally handled as specified in the same media description, i.e., in the same "m" line.
specified in [RFC3388].
Depending on the implementation, a node that does not understand FEC
grouping (either does not understand line grouping at all, or just
does not understand the FEC grouping semantics) SHOULD respond to an
offer containing FEC grouping either (1) with an answer that ignores
the grouping attribute or (2) with a refusal to the request (e.g.,
488 Not Acceptable Here or 606 Not Acceptable in SIP).
In the first case, the original sender of the offer MUST establish
the connection without FEC. In the second case, if the sender of the
offer still wishes to establish the session, it SHOULD re-try the
request with an offer without FEC.
4.3. Example of FEC Grouping 4.2. SDP Example
For the scenario sketched in Figure 1, we can write the following For the scenario sketched in Figure 1, we can 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-XR S1 R1 a=group:FEC-XR S1 R1
a=group:FEX-XR S1 S2 R2 a=group:FEC-XR S1 S2 R2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.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 224.1.1.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 224.1.2.1/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 224.1.2.2/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
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 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
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.
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.
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
Figure 4: Example scenario with one FEC Framework instance, where a
single repair flow protects only one of the source flows
The following SDP describes the scenario sketched in Figure 4.
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=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
payload type.
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
included in an "a=ssrc-group" line are additive. Repair flows that
are in different "a=ssrc-group" lines are non-additive.
4.4. Offer-Answer Model Considerations
When offering FEC grouping using SDP in an Offer/Answer model
[RFC3264], the following considerations apply.
A node that is receiving an offer from a sender may or may not
understand line grouping. It is also possible that the node
understands line grouping but it does not understand the "FEC-XR"
semantics. From the viewpoint of the sender of the offer, these
cases are indistinguishable.
When a node is offered a session with the "FEC-XR" grouping semantics
but it does not support line grouping or the FEC grouping semantics,
the node SHOULD respond to the offer either:
o With an answer that ignores the grouping attribute.
In this case, the original sender of the offer MUST first check
whether using the FEC grouping semantics of [RFC4756] will create
any ambiguity or not, while keeping in mind the limitations
explained in Section 3.1. If using the "FEC" semantics rather
than the "FEC-XR" semantics still provides an exact association
among the source and repair flows, the sender of the offer MUST
send a new offer using the "FEC" semantics. However, if an exact
association cannot be described, the sender MUST send a new offer
without FEC.
o With a refusal to the request (e.g., 488 Not Acceptable Here or
606 Not Acceptable in SIP).
In this case, if the sender of the offer still wishes to establish
the session, it MUST first check whether using the FEC grouping
semantics of [RFC4756] will create any ambiguity or not, while
keeping in mind the limitations explained in Section 3.1. If
using the "FEC" semantics rather than the "FEC-XR" semantics still
provides an exact association among the source and repair flows,
the sender of the offer SHOULD send a new offer using the "FEC"
semantics. However, if an exact association cannot be described,
the sender SHOULD send a new offer without FEC.
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
it, the session will be established and the rules pertaining to
[RFC4756] will be valid.
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.
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 mishandling
of other media payload streams. It is RECOMMENDED that the receiver of other media payload streams. It is RECOMMENDED that the receiver
SHOULD do integrity check on SDP and follow the security SHOULD do integrity check on SDP and follow the security
considerations of SDP [RFC4566] to only trust SDP from trusted considerations of SDP [RFC4566] 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
the number of this document prior to publication as an RFC.
Semantics Token Reference Semantics Token Reference
--------------------------- ------ ------------- --------------------------- ------ ---------
Forward Error Correction XR FEC-XR This document Forward Error Correction XR FEC-XR [RFCXXXX]
This document also registers the following semantics with IANA in
Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters:
Semantics Token Reference
--------------------------- ------ ---------
Forward Error Correction XR FEC-XR [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]. would like to thank those who contributed to [RFC4756]. Also, thanks
to Jonathan Lennox who has contributed to Section 4.3.
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.
[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-02 (work
in progress), January 2009. in progress), January 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
Media Attributes in the Session Description Protocol
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work
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-03 (work in progress),
October 2008. October 2008.
[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.
 End of changes. 31 change blocks. 
62 lines changed or deleted 202 lines changed or added

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