draft-ietf-fecframe-sdp-elements-00.txt   draft-ietf-fecframe-sdp-elements-01.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track February 08, 2008 Intended status: Standards Track July 14, 2008
Expires: August 11, 2008 Expires: January 15, 2009
SDP Elements for FEC Framework SDP Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-00 draft-ietf-fecframe-sdp-elements-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 11, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies the use of Session Description Protocol (SDP) This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the Correction (FEC) Framework Configuration Information between the
skipping to change at page 2, line 12 skipping to change at page 2, line 12
applications that simultaneously use multiple instances of the FEC applications that simultaneously use multiple instances of the FEC
Framework. Framework.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4
3.3. FEC Framework Configuration Information . . . . . . . . . 4 3.3. FEC Framework Configuration Information . . . . . . . . . 5
4. FEC Framework Descriptors . . . . . . . . . . . . . . . . . . 6 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 6
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12
5.1. Session Announcement Considerations . . . . . . . . . . . 12 5.1. Session Announcement Considerations . . . . . . . . . . . 12
5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12 5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 13 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 13
5.3.2. Two Source Flows, One Repair Flow and One FEC 5.3.2. Two Source Flows, One Repair Flow and One FEC
Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14 Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.3. Two Source Flows, Two Repair Flows and Two FEC 5.3.3. Two Source Flows, Two Repair Flows and Two FEC
Schemes . . . . . . . . . . . . . . . . . . . . . . . 15 Schemes . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18 9.1. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
The Forward Error Correction (FEC) Framework, described in The Forward Error Correction (FEC) Framework, described in
[I-D.ietf-fecframe-framework], outlines a general framework for using [I-D.ietf-fecframe-framework], outlines a general framework for using
FEC-based error recovery in packet flows carrying media content. FEC-based error recovery in packet flows carrying media content.
While a continuous signaling between the sender(s) and receiver(s) is While a continuous signaling between the sender(s) and receiver(s) is
not required for a Content Delivery Protocol (CDP) that uses the FEC not required for a Content Delivery Protocol (CDP) that uses the FEC
Framework, a set of parameters pertaining to the FEC Framework MUST Framework, a set of parameters pertaining to the FEC Framework MUST
be initially communicated between the sender(s) and receiver(s). be initially communicated between the sender(s) and receiver(s). A
signaling protocol (such as the one described in
[I-D.ietf-fecframe-config-signaling]) is required to enable such
communication and the parameters must be appropriately encoded so
that they can be carried by the signaling protocol.
One way to communicate this information is to use the Session One format to encode the parameters is the Session Description
Description Protocol (SDP) [RFC4566]. SDP provides a simple text- Protocol (SDP) [RFC4566]. SDP provides a simple text-based format
based format for announcements and invitations to describe multimedia for announcements and invitations to describe multimedia sessions.
sessions. These SDP announcements and invitations include sufficient These SDP announcements and invitations include sufficient
information for the sender(s) and receiver(s) to participate in the information for the sender(s) and receiver(s) to participate in the
multimedia sessions. SDP also provides a framework for capability multimedia sessions. SDP also provides a framework for capability
negotiation, which MAY be used to negotiate all or a subset of the negotiation, which MAY be used to negotiate all or a subset of the
parameters pertaining to the individual sessions. parameters pertaining to the individual sessions.
The purpose of this document is to introduce the SDP elements that The purpose of this document is to introduce the SDP elements that
MUST be used by the CDPs using the FEC Framework that choose SDP MUST be used by the CDPs using the FEC Framework that choose SDP
[RFC4566] as their session description protocol. [RFC4566] as their session description protocol.
2. Requirements Notation 2. Requirements Notation
skipping to change at page 6, line 34 skipping to change at page 6, line 41
The variable-length opaque SS-FSSI and RS-FSSI containers transmit The variable-length opaque SS-FSSI and RS-FSSI containers transmit
the information in the form of an octet string. The FEC schemes the information in the form of an octet string. The FEC schemes
define the structure of this octet string, which MAY contain multiple define the structure of this octet string, which MAY contain multiple
distinct elements. If the FEC scheme does not require any specific distinct elements. If the FEC scheme does not require any specific
information, the FSSI MAY be null. For the fully-specified FEC information, the FSSI MAY be null. For the fully-specified FEC
schemes, a full description of the encoded information in both schemes, a full description of the encoded information in both
containers MUST be provided. See [I-D.ietf-fecframe-framework] for containers MUST be provided. See [I-D.ietf-fecframe-framework] for
details. details.
4. FEC Framework Descriptors 4. SDP Descriptors for FEC Framework
This section defines the SDP elements that MUST be used to describe This section defines the SDP elements that MUST be used to describe
the FEC Framework Configuration Information in multimedia sessions by the FEC Framework Configuration Information in multimedia sessions by
the CDPs that choose SDP [RFC4566] as their session description the CDPs that choose SDP [RFC4566] as their session description
protocol. Example SDP configurations can be found in Section 5. protocol. Example SDP configurations can be found in Section 5.
4.1. Transport Protocol Identifiers 4.1. Transport Protocol Identifiers
This specification defines a class of new transport protocol This specification defines a class of new transport protocol
identifiers for SDP media descriptions. For all existing identifiers identifiers for SDP media descriptions. For all existing identifiers
skipping to change at page 7, line 40 skipping to change at page 7, line 46
example, consider a layered video source that consists of one base example, consider a layered video source that consists of one base
layer (e.g., source flow 0) and one enhancement layer (e.g., source layer (e.g., source flow 0) and one enhancement layer (e.g., source
flow 1), where each layer is carried in a separate flow. Repair flow flow 1), where each layer is carried in a separate flow. Repair flow
3 protects the combination of the base and enhancement layers for the 3 protects the combination of the base and enhancement layers for the
receivers who receive both layers, and repair flow 4 protects the receivers who receive both layers, and repair flow 4 protects the
base layer only, for the receivers who want the base layer only, or base layer only, for the receivers who want the base layer only, or
who receive both layers but prefer FEC protection for the base layer who receive both layers but prefer FEC protection for the base layer
only due to their bandwidth and/or processing limitations. only due to their bandwidth and/or processing limitations.
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. Some instances may use larger provides flexibility to the receivers. Different instances may use
or smaller source block sizes, which accommodate the receivers that larger or smaller source block sizes, which accommodate the receivers
have looser and tighter latency requirements, respectively. that have looser and tighter latency requirements, respectively.
Different instances may also provide FEC protection at different Different instances may also provide FEC protection at different
redundancy levels. This enables the receivers experiencing different redundancy levels. This enables the receivers experiencing different
packet loss rates to choose the repair flows that are tailored to packet loss rates to choose the repair flows that are tailored to
their needs. their needs.
____| FEC FRAMEWORK ____| FEC FRAMEWORK
/ | INSTANCE / | INSTANCE
/ | 3: Repair Flow / | 3: Repair Flow
/ /
SOURCE FLOWS / __| FEC FRAMEWORK SOURCE FLOWS / | FEC FRAMEWORK
0: Source Flow |___/ |---' | INSTANCE 0: Source Flow |___/ |------| INSTANCE
1: Source Flow | |____ | 4: Repair Flow __| 1: Source Flow | | 4: Repair Flow
2: Source Flow | \ | | 2: Source Flow
\ | FEC FRAMEWORK | | FEC FRAMEWORK
\_| INSTANCE |__________________________| INSTANCE
| 5: Repair Flow | 5: Repair Flow
| 6: Repair Flow | 6: Repair Flow
| 7: Repair Flow | 7: Repair Flow
Figure 1: Example scenario with multiple FEC Framework instances Figure 1: Example scenario with multiple FEC Framework instances
The 'group' attribute and the FEC grouping semantics defined in The 'group' attribute and the FEC grouping semantics defined in
[RFC4756] are used to associate source and repair flows together with [RFC4756] are used to associate source and repair flows together with
the following additional requirement: the following additional requirement:
skipping to change at page 10, line 26 skipping to change at page 10, line 26
sender-info = *CHAR sender-info = *CHAR
receiver-side-scheme-specific = "rs-fssi=" receiver-info receiver-side-scheme-specific = "rs-fssi=" receiver-info
receiver-info = *CHAR receiver-info = *CHAR
The MANDATORY parameter 'encoding-id' is used to identify the FEC The MANDATORY parameter 'encoding-id' is used to identify the FEC
scheme used to generate this repair flow. These identifiers MUST be scheme used to generate this repair flow. These identifiers MUST be
registered with IANA by the FEC schemes that use the FEC Framework. registered with IANA by the FEC schemes that use the FEC Framework.
The OPTIONAL parameter 'priority' is used to indicate the priorities The OPTIONAL parameter 'priority' is used to indicate the priorities
of the repair flows when multiple repair flows are grouped together of the repair flows. The exact usage of the parameter 'priority' and
to be used in an additive manner within a single FEC Framework the pertaining rules SHOULD be defined by the FEC scheme or the CDP.
instance. The exact usage of the parameter 'priority' and the If no value is specified for the parameter 'priority', it means that
pertaining rules SHOULD be defined by the FEC scheme or the CDP. If the receiver(s) MAY receive and use the repair flows in any order.
no value is specified for the parameter 'priority', it means that the
receiver(s) MAY receive and use the repair flows in any order.
However, if a priority is assigned to the repair flow(s), the However, if a priority is assigned to the repair flow(s), the
receivers MUST follow the specified order in receiving and using the receivers MUST follow the specified order in receiving and using the
repair flow(s). repair flow(s).
The OPTIONAL parameters 'ss-fssi' and 'rs-fssi' are opaque containers The OPTIONAL parameters 'ss-fssi' and 'rs-fssi' are opaque containers
to convey the FEC-Scheme-Specific Information (FSSI) that includes to convey the FEC-Scheme-Specific Information (FSSI) that includes
the information that is specific to the FEC scheme used by the CDP the information that is specific to the FEC scheme used by the CDP
and is necessary for proper FEC encoding and decoding operations. and is necessary for proper FEC encoding and decoding operations.
The FSSI required only by the sender (called Sender-Side FSSI) MUST The FSSI required only by the sender (called Sender-Side FSSI) MUST
be communicated in the container specified by the parameter 'ss- be communicated in the container specified by the parameter 'ss-
skipping to change at page 13, line 42 skipping to change at page 13, line 38
same values for identifying the media streams and source flows is NOT same values for identifying the media streams and source flows is NOT
RECOMMENDED, even when 'mid' values are integers. RECOMMENDED, even when 'mid' values are integers.
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 1: Repair Flow 0: Source Flow |---------| 1: Repair Flow
Figure 6: Scenario #1 Figure 6: Scenario #1
In this example, we have one source video stream (mid:S1) and one FEC In this example, we have one source video flow (mid:S1) and one FEC
repair stream (mid:R1). We form one FEC group with the "a=group:FEC repair flow (mid:R1). We form one FEC group with the "a=group:FEC S1
S1 R1" line. The source and repair streams are sent to the same port R1" line. The source and repair flows are sent to the same port on
on different multicast groups. The repair window is set to 150 ms. different multicast groups. The repair window is set to 150 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC S1 R1 a=group:FEC S1 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S1
m=video 30000 RTP/AVP 110 m=application 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 parityfec/90000 a=rtpmap:110 1d-interleaved-parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 150 a=repair-window: 150
a=mid:R1 a=mid:R1
5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |_________| 2: Repair Flow 0: Source Flow |_________| 2: Repair Flow
1: Source Flow | 1: Source Flow |
Figure 8: Scenario #2 Figure 8: Scenario #2
In this example, we have two source video streams (mid:S1 and mid:S2) In this example, we have two source video flows (mid:S1 and mid:S2)
and one FEC repair stream (mid:R1), protecting both source streams. and one FEC repair flow (mid:R1), protecting both source flows. We
We form one FEC group with the "a=group:FEC S1 S2 R1" line. The form one FEC group with the "a=group:FEC S1 S2 R1" line. The source
source and repair streams are sent to the same port on different and repair flows are sent to the same port on different multicast
multicast groups. The repair window is set to 150500 us. groups. The repair window is set to 150500 us.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC S1 S2 R1 a=group:FEC S1 S2 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
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 224.1.1.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S2
m=video 30000 RTP/AVP 110 m=application 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 parityfec/90000 a=rtpmap:110 1d-interleaved-parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 150500 us a=repair-window: 150500 us
a=mid:R1 a=mid:R1
5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 2: Repair Flow 0: Source Flow |---------| 2: Repair Flow
1: Source Flow |_ 1: Source Flow |_
\-------| INSTANCE #2 \-------| INSTANCE #2
| 3: Repair Flow | 3: Repair Flow
Figure 10: Scenario #3 Figure 10: Scenario #3
In this example, we have two source video streams (mid:S1 and mid:S2) In this example, we have two source video flows (mid:S1 and mid:S2)
and two FEC repair streams (mid:R1 and mid:R2). The source streams and two FEC repair flows (mid:R1 and mid:R2). The source flows
mid:S1 and mid:S2 are protected by the repair streams mid:R1 and mid:S1 and mid:S2 are protected by the repair flows mid:R1 and
mid:R2, respectively. We form two FEC groups with the "a=group:FEC mid:R2, respectively. We form two FEC groups with the "a=group:FEC
S1 R1" and "a=group:FEC S2 R2" lines. The source and repair streams S1 R1" and "a=group:FEC S2 R2" lines. The source and repair flows
are sent to the same port on different multicast groups. The repair are sent to the same port on different multicast groups. The repair
window is set to 200 ms and 400 ms for the first and second FEC window is set to 200 ms and 400 ms for the first and second FEC
group, respectively. group, respectively.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC S1 R1 a=group:FEC S1 R1
a=group:FEC S2 R2 a=group:FEC 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 224.1.1.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
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 224.1.1.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S2
m=video 30000 RTP/AVP 110 m=application 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 parityfec/90000 a=rtpmap:110 1d-interleaved-parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 200 ms a=repair-window: 200 ms
a=mid:R1 a=mid:R1
m=video 30000 RTP/AVP 111 m=application 30000 RTP/AVP 111
c=IN IP4 224.1.2.2/127 c=IN IP4 224.1.2.2/127
a=rtpmap:111 parityfec/90000 a=rtpmap:111 1d-interleaved-parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX
a=repair-window: 400 ms a=repair-window: 400 ms
a=mid:R2 a=mid:R2
6. Security Considerations 6. Security Considerations
For the general security considerations related to SDP, refer to For the general security considerations related to SDP, refer to
[RFC4566]. For the security considerations related to source/FEC [RFC4566]. For the security considerations related to source/FEC
media stream grouping in SDP and use of source address filters in media stream grouping in SDP and use of source address filters in
SDP, refer to [RFC4756] and [RFC4570], respectively. SDP, refer to [RFC4756] and [RFC4570], respectively.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
Reference: This document Reference: This document
Values: See this document Values: See this document
8. Acknowledgments 8. Acknowledgments
The author would like to thank the FEC Framework Design Team for The author would like to thank the FEC Framework Design Team for
their inputs, suggestions and contributions. their inputs, suggestions and contributions.
9. Change Log 9. Change Log
9.1. draft-ietf-fecframe-sdp-elements-00 9.1. draft-ietf-fecframe-sdp-elements-01
The following are the major changes compared to version 00:
o Additive repair flows can now be from different instances. The
sender may also assign different levels of priorities to each
repair flow regardless of whether the repair flows are additive or
not.
o SDP examples are fixed.
o Comments posted in the mailing list are incorporated.
9.2. draft-ietf-fecframe-sdp-elements-00
This is the initial version, which is based on an earlier individual This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that submission. The following are the major changes compared to that
document: document:
o The opaque container in the FEC Framework Configuration o The opaque container in the FEC Framework Configuration
Information (FEC-Scheme-Specific Information) is now divided into Information (FEC-Scheme-Specific Information) is now divided into
two parts: information needed only by the sender and information two parts: information needed only by the sender and information
needed by the receiver. The repair flow descriptors are also needed by the receiver. The repair flow descriptors are also
updated accordingly. updated accordingly.
skipping to change at page 18, line 40 skipping to change at page 19, line 9
framework draft. framework draft.
o Some other editorial changes. o Some other editorial changes.
10. References 10. References
10.1. Normative References 10.1. Normative 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-01 (work in progress), draft-ietf-fecframe-framework-02 (work in progress),
November 2007. July 2008.
[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.
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
(SDP) Source Filters", RFC 4570, July 2006. (SDP) Source Filters", RFC 4570, July 2006.
skipping to change at page 19, line 23 skipping to change at page 19, line 39
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004. RFC 3890, September 2004.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[I-D.ietf-fecframe-config-signaling]
Asati, R., "Signaling Protocol to convey FEC Framework
Configuration Information",
draft-ietf-fecframe-config-signaling-00 (work in
progress), July 2008.
[I-D.ietf-mmusic-sdp-capability-negotiation] [I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation", Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007. progress), December 2007.
10.2. Informative References 10.2. Informative References
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
 End of changes. 27 change blocks. 
58 lines changed or deleted 80 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/