draft-ietf-mmusic-rfc4756bis-03.txt   draft-ietf-mmusic-rfc4756bis-04.txt 
MMUSIC A. Begen MMUSIC A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 4756 September 23, 2009 Obsoletes: 4756 October 15, 2009
(if approved)
Updates: 3388bis, 5576
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: March 27, 2010 Expires: April 18, 2010
Forward Error Correction Grouping Semantics in Session Description Forward Error Correction Grouping Semantics in Session Description
Protocol Protocol
draft-ietf-mmusic-rfc4756bis-03 draft-ietf-mmusic-rfc4756bis-04
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 37
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 March 27, 2010. This Internet-Draft will expire on April 18, 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 2, line 23 skipping to change at page 2, line 23
group. Furthermore, the existing semantics does not support group. Furthermore, the existing semantics does not support
describing additive repair flows. This document addresses these describing additive repair flows. This document addresses these
issues by introducing new FEC grouping semantics. SSRC-level issues by introducing new FEC grouping semantics. SSRC-level
grouping semantics is also introduced in this document for Real-time grouping semantics is also introduced in this document for Real-time
Transport Protocol (RTP) streams using SSRC multiplexing. 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 Changes from 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. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8
4.4. Offer-Answer Model Considerations . . . . . . . . . . . . 9 4.4. SDP Offer-Answer Model and Backward Compatibility
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.5. ABNF Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 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
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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 It should be noted that the grouping semantics defined in this
document offers flexibility about which source streams can be grouped document offers the flexibility to determine how source streams are
together prior to FEC protection. However, not all FEC schemes grouped together prior to applying FEC protection. However, not all
support the full range of the possible scenarios (e.g., when the FEC schemes support the full range of the possible scenarios (e.g.,
source streams carry different top-level media types such as audio when the source streams carry different top-level media types such as
and video). 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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
To summarize, the FEC Framework supports the following: In summary, based on the FEC Framework [I-D.ietf-fecframe-framework],
the SDP grouping semantics for FEC MUST support the ability to
indicate that:
1. A source flow MAY be protected by multiple different FEC schemes. 1. A given source flow is protected by multiple different FEC
schemes.
2. An FEC scheme MAY generate multiple repair flows. 2. Multiple repair flows are associated with a given FEC scheme.
3. Source flows MAY be grouped prior to FEC protection. That is, 3. Multiple source flows are grouped prior to applying FEC
one or more repair flows MAY protect a group of source flows. protection.
To fully benefit from the flexibility provided by the FEC Framework, 4. One or more repair flows protect a group of source flows.
the grouping semantics for FEC MUST support these features.
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 Issues with RFC 4756 3. Requirements and Changes from RFC 4756
3.1. Source and Repair Flow Association 3.1. Source and Repair Flow Association
Currently, the 'group' attribute and the FEC grouping semantics The FEC grouping semantics and 'group' attribute defined in this
defined in [RFC3388] and [RFC4756], respectively, are used to document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to
associate source and repair flows together. associate source and repair flows together. This document also
specifies how the 'group' attribute in SDP is used to group multiple
The 'group' attribute is used to group multiple repair flows with one repair flows with one or more source flows.
or more source flows. However, [RFC3388] prohibits an "m" line
identified by its 'mid' attribute from appearing in more than one
"a=group" line using the same semantics. This limitation prevents us
from indicating specific associations between the source and repair
flows by using an "a=group:FEC" line per FEC Framework instance. For
example, for the scenario sketched in Figure 1, [RFC3388] mandates us
to write
a=group:FEC S1 S2 R1 R2
Clearly, this "a=group:FEC" line does not say anything specific about [I-D.ietf-mmusic-rfc3388bis] updates [RFC3388] to allow an "m" line
which repair flows are protecting which source flows. identified by its 'mid' attribute to appear in more than one
"a=group" line using the same semantics. With this change and other
required changes in the grouping semantics for FEC, a sender is
allowed to indicate the specific associations between the source and
repair flows, and a receiver can determine which repair flow(s)
protect which source flow(s).
A new work ([I-D.ietf-mmusic-rfc3388bis]) is currently in progress in This document introduces the changes required in the FEC grouping
the MMUSIC WG to remove this limitation in [RFC3388]. However, semantics and obsoletes [RFC4756].
[RFC4756] also needs to be updated according to the FEC Framework
requirements.
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 50 skipping to change at page 6, line 47
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 MUST be considered to be
additive. Repair flows that are in different FEC groups are non- additive. Repair flows that are not additive MUST be indicated in
additive. separate FEC groups.
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.
The "a=group:FEC-XR" semantics MUST always be used to associate the 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 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.
4.2. SDP Example 4.2. SDP Example
For the scenario sketched in Figure 1, we can write the following For the scenario sketched in Figure 1, we MUST 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:FEC-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 233.252.0.1/127 c=IN IP4 233.252.0.1/127
skipping to change at page 8, line 25 skipping to change at page 8, line 20
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
[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. Instead, the same "m" line, the 'group' attribute cannot be used.
'ssrc-group' attribute MUST be used.
This document extends [RFC5576] in two ways. First, we define how
FEC is applied to source and repair flows for SSRC-multiplexed
streams using the 'ssrc-group' attribute. We then specify how the
additivity of the repair flows is expressed for the SSRC-multiplexed
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-XR" for the 'ssrc- 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 is 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
skipping to change at page 9, line 29 skipping to change at page 9, line 29
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.2. In other words, the repair flows that are
included in an "a=ssrc-group" line are additive. Repair flows that included in an "a=ssrc-group" line MUST be additive. Repair flows
are in different "a=ssrc-group" lines are non-additive. that are not additive MUST be indicated in separate "a=ssrc-group"
lines.
4.4. Offer-Answer Model Considerations 4.4. 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-XR" understands line grouping but it does not understand the "FEC-XR"
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-XR" grouping semantics 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, but it does not support line grouping or the FEC grouping semantics,
the node SHOULD respond to the offer either: the node SHOULD respond 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 of [RFC4756] will create whether using the "FEC" grouping semantics will create any
any ambiguity or not, while keeping in mind the limitations ambiguity or not, while keeping in mind the limitations explained
explained in Section 3.1. If using the "FEC" semantics rather in Section 3.1. If using the "FEC" semantics rather than the
than the "FEC-XR" semantics still provides an exact association "FEC-XR" semantics still provides an exact association among the
among the source and repair flows, the sender of the offer MUST source and repair flows, the sender of the offer MUST send a new
send a new offer using the "FEC" semantics. However, if an exact offer using the "FEC" semantics. However, if an exact association
association cannot be described, the sender MUST send a new offer cannot be described, the sender MUST send a new offer without FEC.
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 of [RFC4756] will create any ambiguity or not, while semantics will create any ambiguity or not, while keeping in mind
keeping in mind the limitations explained in Section 3.1. If the limitations explained in Section 3.1. If using the "FEC"
using the "FEC" semantics rather than the "FEC-XR" semantics still semantics rather than the "FEC-XR" semantics still provides an
provides an exact association among the source and repair flows, exact association among the source and repair flows, the sender of
the sender of the offer SHOULD send a new offer using the "FEC" the offer SHOULD send a new offer using the "FEC" semantics.
semantics. However, if an exact association cannot be described, However, if an exact association cannot be described, the sender
the sender SHOULD send a new offer without FEC. SHOULD send a new offer without FEC.
Note that in both cases described above, when the sender of the offer 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
[RFC4756] will be valid. [RFC4756] will be valid.
However, if the node does not understand the "FEC" semantics, it However, if the node does not understand the "FEC" semantics, it
SHOULD respond to the offer either (1) with an answer that ignores 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 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 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 second case, if the sender of the offer still wishes to establish the
session, it SHOULD retry the request with an offer without FEC. 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-XR") 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-XR" ; from [RFCXXXX]
identification-tag = token
The identification tags MUST be unique within an SDP session
description.
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.
skipping to change at page 12, line 5 skipping to change at page 12, line 34
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-05 (work in progress), draft-ietf-fecframe-framework-05 (work in progress),
July 2009. 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.
 End of changes. 27 change blocks. 
69 lines changed or deleted 98 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/