RFC 5956
Forward Error Correction Grouping Semantics in the Session Description Protocol
Forward Error Correction Grouping Semantics in the Session Description Protocol 🎀
Okay bestie, this is RFC 5956 💖 It was written by A. Begen from Cisco and published in September 2010 by the Internet Engineering Task Force (IETF). It's a Standards Track document, so this is the real deal, not a someday-maybe. It also has ISSN 2070-1721. It obsoletes RFC 4756, which means it's the newer version that replaces that one 🦋 The header doesn't list any RFC that it updates.
Abstract ✨
Okay so this doc defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP) 🧚 These semantics are meant to be used with the SDP Grouping Framework (RFC 5888). They let you describe grouping relationships between the source and repair flows when one or more source and/or repair flows are part of the same group, and they support additive repair flows, which is so iconic 🔥 SSRC-level (Synchronization Source) grouping semantics are also defined here for Real-time Transport Protocol (RTP) streams that use SSRC multiplexing 💅
Status of This Memo 🌸
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5956.
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Requirements and Changes from RFC 4756 ..........................5
3.1. FEC Grouping Requirements ..................................5
3.2. Source and Repair Flow Associations ........................6
3.3. Support for Additivity .....................................6
4. FEC Grouping ....................................................7
4.1. "FEC-FR" Grouping Semantics ................................7
4.2. SDP Example ................................................7
4.3. FEC Grouping for SSRC-Multiplexed RTP Streams ..............9
4.4. "FEC" Grouping Semantics ..................................10
4.5. SDP Offer/Answer Model and RFC 4756
Backward-Compatibility Considerations .....................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. Acknowledgments ................................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................141. Introduction ✨
Any application that needs reliable transmission over an unreliable packet network has to deal with packet losses 😭 Forward Error Correction (FEC) is a really effective way to make transmission more reliable, especially in multicast and broadcast apps where feedback from the receiver(s) is potentially limited 🫶
In a nutshell, FEC groups source packets into blocks and applies protection to generate a desired number of repair packets. These repair packets may be sent on demand or independently of any receiver feedback. The choice depends on the FEC scheme, the packet loss characteristics of the underlying network, the transport scheme (for example unicast, multicast, or broadcast), and the application. On the receiver side, lost packets can be recovered by erasure decoding, as long as a sufficient number of source and repair packets have been received ✨
For example, one of the most basic FEC schemes is the parity code 🧁 An exclusive OR (XOR) operation is applied to a group of packets (that is, a source block) to generate a single repair packet. On the receiver side, this scheme gives a full recovery if only one packet is lost within the source block and the repair packet is received. There are various other ways of generating repair packets, which can have different loss-recovery capabilities 💅
The FEC Framework [FEC-FRAMEWK] outlines a general framework for using FEC codes in multimedia apps that stream audio, video, or other types of multimedia content 🎬 The FEC Framework specification says that source and repair packets must be carried in different streams, which are called the source and repair flows, respectively. On the receiver side, receivers should know which flows are the source flows and which are the repair flows. They should also know the exact association between the source and repair flows, so they can use the correct data to repair the original content when there's a packet loss. SDP [RFC4566] uses [RFC5888] and this RFC for this exact purpose 🦋
To give apps more flexibility, the FEC Framework [FEC-FRAMEWK] lets a source flow be protected by multiple FEC schemes, and each of those requires an instance of the FEC Framework. So multiple instances of the FEC Framework may exist at the sender and the receiver(s) 👑 Also, within a single FEC Framework instance, multiple source flows can be grouped and protected by one or more repair flows.
The FEC Framework requires source and repair packets to be carried in different streams. When the Real-time Transport Protocol (RTP) [RFC3550] carries the source and repair streams, the FEC Framework recommends that each stream be carried in its own RTP session. This gives you flexibility to use FEC in a backward-compatible manner 🌈 But in some scenarios, it might be useful for a single RTP session to carry multiple RTP streams through Synchronization Source (SSRC) multiplexing, so you can save on port usage. For those scenarios, appropriate grouping semantics are also required.
A basic example scenario is shown in Figure 1. Here, the source flow S1 is protected by the repair flow R1. The source flows S1 and S2 are also grouped and protected together by the repair flow R2 🧚
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
| S1: Source Flow |--------| R1: Repair Flow
+---|
| | S2: Source Flow
|
+______________________________| FEC FRAMEWORK INSTANCE #2
| R2: Repair FlowFigure 1: Example scenario with two FEC Framework instances where R1 protects S1 and R2 protects the group of S1 and S2
Grouping source flows before applying FEC protection may let us get better coding performance 🔥 As a typical scenario, say source flows S1 and S2 in Figure 1 correspond to the base and enhancement layers in layered video content, respectively. The repair flow R2 protects the combination of the base and enhancement layers for the receivers that receive both layers. The repair flow R1 protects only the base layer, for receivers that want just the base layer, or that receive both layers but prefer FEC protection for the base layer only because of bandwidth or some other limitation 🎀
The grouping semantics defined in this document give you the flexibility to decide how source streams get grouped together before FEC protection is applied. However, not every FEC scheme supports the full range of possible scenarios (for example, when the source streams carry different top-level media types, such as audio and video) 🙈
Using multiple FEC Framework instances for a single source flow gives receivers flexibility. An example scenario is sketched in Figure 2. Different instances may offer repair flows generated by different FEC schemes, and receivers choose the repair flow(s) they can support and decode. Alternatively, different instances (whether or not they use the same FEC scheme) may use larger and smaller source block sizes, which accommodate receivers with looser and tighter latency requirements, respectively. Different instances may also provide FEC protection at different redundancy levels. This is especially useful in multicast scenarios, where different receivers may experience different packet loss rates and each receiver can choose the repair flow that's tailored to its needs 💖
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S3: Source Flow |---------| R3: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R4: Repair FlowFigure 2: Example scenario with two FEC Framework instances, each with a single repair flow protecting the same source flow S3
2. Requirements Notation ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖
3. Requirements and Changes from RFC 4756 💅
3.1. FEC Grouping Requirements
As we saw in the intro, and based on the FEC Framework [FEC-FRAMEWK], the SDP grouping semantics for FEC must support the ability to indicate that:
- A given source flow is protected by multiple different FEC schemes.
- Multiple repair flows are associated with a given FEC scheme.
- Multiple source flows are grouped prior to applying FEC protection.
- One or more repair flows protect a group of source flows.
3.2. Source and Repair Flow Associations 🦋
The FEC grouping semantics defined in this document and the SDP "group" attribute defined in [RFC5888] are used to associate source and repair flows. This document also specifies how the "group" attribute is used to group multiple repair flows with one or more source flows.
Note that [RFC5888] obsoleted [RFC3388] so that an "m" line identified by its "mid" attribute can appear in more than one "a=group" line using the same semantics. With this change and the FEC grouping semantics defined in this document, a sender can indicate the specific associations between the source and repair flows, and a receiver can figure out which repair flow(s) protect which source flow(s) 🫶
This document defines the FEC grouping semantics and obsoletes [RFC4756]. Implementations compliant with this document MUST use the semantics introduced in Sections 4.1 and 4.3. In addition to complying with the requirements defined in Sections 4.1 and 4.3, implementations are RECOMMENDED to support the "FEC" semantics specified in Section 4.4 for backward-compatibility reasons in the scenarios described in Section 4.5 👑
3.3. Support for Additivity
okay bestie 🎀 so the FEC Framework [FEC-FRAMEWK] is where additive repair flows get their moment 💅. Additivity means multiple repair flows can get decoded together to boost the odds of recovering missing packets, either in one source flow or in the same set of source flows ✨. The repair flows can come from the same FEC scheme or from different FEC schemes, no cap 🧚
For example, in Figure 3, repair flows R5 and R6 may be additive within FEC Framework instance #1 💖 Or all three (R5, R6, and R7) could be additive too, which is giving main character energy 👑
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S4: Source Flow |---------| R5: Repair Flow
| | R6: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R7: Repair Flow
Figure 3: Example scenario with two FEC Framework instances where two
repair flows in the first instance and a single repair flow in the
second instance protect the same source flow S4This document is where the mechanisms for supporting additive repair flows that were not in [RFC4756] finally show up 🦋🌈
4. FEC Grouping 🌸
4.1. "FEC-FR" Grouping Semantics
okay so each "a=group" line is how you say "these flows are related" 🫶 All the flows in one "a=group" line are called an FEC group. If an FEC group has more than one repair flow, those repair flows MUST be considered additive 😭 Repair flows that aren't additive MUST be listed in separate FEC groups. BUT (and this is important 🙈) just because two repair flows are additive in one FEC group doesn't mean they're additive in every other group. Like, the relationship isn't automatically carried over. To show lots of relations between source and repair flows, each source and repair flow MAY show up in more than one FEC group, which is so iconic ✨
Using the framework in [RFC5888], this document defines "FEC-FR" as the grouping semantics for signalling FEC Framework support 💅
The "a=group:FEC-FR" semantics MUST be used to link source and repair flows, EXCEPT when they're in the same media description (i.e., the same "m" line, see Section 4.3) 🎀 Also, additivity is not necessarily transitive, so every set of additive repair flows MUST be stated explicitly in SDP. The example below shows how 🧚
4.2. SDP Example
okay for the scenario sketched in Figure 1, we need to write this SDP 💖
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Grouping Semantics
t=0 0
a=group:FEC-FR S1 R1
a=group:FEC-FR S1 S2 R2
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=mid:S2
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.3/127
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=mid:R1
m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.4/127
a=rtpmap:111 1d-interleaved-parityfec/90000
a=fmtp:111 L=10; D=10; repair-window=400000
a=mid:R2Here the source and repair flows each get their own RTP session, and the grouping happens through the a=group:FEC-FR lines 🦋
For the additivity example, look at Figure 3 🌈 Say R5 and R6 are additive but R7 isn't additive with any of the other repair flows. Then we must write:
a=group:FEC-FR S4 R5 R6
a=group:FEC-FR S4 R7And if none of the repair flows are additive, we must write:
a=group:FEC-FR S4 R5
a=group:FEC-FR S4 R6
a=group:FEC-FR S4 R74.3. FEC Grouping for SSRC-Multiplexed RTP Streams
okay so [RFC5576] gives us an SDP media-level attribute called "ssrc-group" for grouping RTP streams that are SSRC multiplexed and sit in the same RTP session 🧚 The grouping is based on the Synchronization Source (SSRC) identifiers. Since SSRC-multiplexed RTP streams live in the same "m" line, the "group" attribute can't be used 😭
This section explains how FEC gets applied to source and repair flows for SSRC-multiplexed streams using the "ssrc-group" attribute [RFC5576] 💅 It also explains how additivity of repair flows gets expressed for those streams ✨
The "FEC-FR" semantics for "ssrc-group" are the same as the ones for the "group" attribute, EXCEPT that SSRC identifiers are used to designate the FEC grouping associations: a=ssrc-group:FEC-FR *(SP ssrc-id) [RFC5576] 🎀
The SSRC identifiers for RTP streams carried in the same RTP session MUST be unique per [RFC3550]. SSRC identifiers are NOT guaranteed to be unique across different RTP sessions though, so the "ssrc-group" attribute MUST only be used at the media level [RFC5576] 🙈
Let's take a scenario with two source flows (say, one video and one audio) and a single repair flow that protects only one of them (the video) 💖 All of these are separate RTP streams, 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 flowsHere's the SDP for the Figure 4 scenario 🧚
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=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-FR 1000 2110
a=mid:Group1Heads up 🙈 in real life, SSRC values are random 32-bit numbers, so they can be way bigger than the ones here. Also, before a receiver gets an RTP packet for each stream, it can't know which SSRC identifier goes with which payload type.
Additivity for these works the same way as in Section 4.2 🌈 So the repair flows included in an "a=ssrc-group" line MUST be additive, and repair flows that aren't additive MUST be listed in separate "a=ssrc-group" lines 💅
4.4. "FEC" Grouping Semantics
okay so this document deprecates the "FEC" semantics 😭 Sessions negotiated between two endpoints that implement this spec MUST use the "FEC-FR" semantics and NOT the "FEC" semantics. Section 4.5 explains how an implementation that follows this spec can spot peers that don't (based on their SDP answer to the initial offer). When that happens, the offering implementation SHOULD start a new offer using the "FEC" semantics described in this section 🫶
The "FEC" grouping semantics were first introduced in [RFC4756]. They used the "a=group" line from [RFC3388] to build an FEC group that shows how source and repair flows are associated 🦋
With "FEC" semantics, a source or repair flow can only show up in a single a=group:FEC line. So every source and repair flow that's related to each other has to go in the same a=group:FEC line 🙈 For Figure 1, for example, we'd have to write "a=group:FEC S1 S2 R1 R2" no matter which repair flows protect which source flows. And for Figure 3, we'd have to write "a=group:FEC S4 R5 R6 R7" no matter which repair flows are additive. The problem? Reading those lines becomes ambiguous 💀
In simple setups, like one source flow and one repair flow, these limits might not be a big deal ✨ In Offer/Answer scenarios where the answerer doesn't understand "FEC-FR", the "FEC" semantics can be offered, as long as they give an exact association between source and repair flows and don't create any ambiguity. See Section 4.5 for the details 🎀
4.5. SDP Offer/Answer Model and RFC 4756 Backward-Compatibility Considerations 💖
okay bestie, this section is about what happens when you offer FEC grouping inside an SDP Offer/Answer exchange [RFC3264] 🦋
A node that gets an offer from a sender might understand line grouping, or it might not. It's also possible it understands line grouping but doesn't know the "FEC-FR" semantics. From the sender's side? Those cases look exactly the same, no cap 🫠
Implementations are RECOMMENDED to support the "FEC" semantics from Section 4.4 for backward-compatibility reasons 🎀 If the sender of the offer supports "FEC" semantics, it SHOULD fall back to using "FEC" when the node doesn't understand "FEC-FR" ✨
Now, when a node is offered a session with "FEC-FR" grouping but doesn't support line grouping or FEC grouping (per [RFC5888]), it responds with one of these two options 👑
- An answer that ignores the grouping attribute. In this case, if the original sender of the offer:
- supports the "FEC" semantics from Section 4.4, it MUST first check whether using the "FEC" semantics will create any ambiguity. If using "FEC" still provides an exact association among the source and repair flows, the sender SHOULD send a new offer using the "FEC" semantics. However, if an exact association cannot be described, it MUST send a new offer without FEC.
- does not support the "FEC" semantics from Section 4.4, it MUST send a new offer without FEC.
- A refusal to the request (e.g., 488 Not Acceptable Here or 606 Not Acceptable in SIP). In this case, if the original sender of the offer:
- supports the "FEC" semantics and still wants to establish the session, it MUST first check whether using the "FEC" semantics will create any ambiguity. If using the "FEC" semantics still provides an exact association among the source and repair flows, the sender SHOULD send a new offer using the "FEC" semantics. However, if an exact association cannot be described, it SHOULD send a new offer without FEC.
- does not support the "FEC" semantics from Section 4.4, it SHOULD send a new offer without FEC.
In both cases 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 for the "FEC" semantics will apply 🎉
As specified in [RFC5888], if the node doesn't understand the "FEC" semantics, it responds to the offer with either (1) an answer that ignores the grouping attribute or (2) 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 still wants to establish the session, it should retry the request with an offer without FEC 🌸
5. Security Considerations 😱
okay this one is serious, so pay attention 🔐 There is a weak threat for the receiver: the FEC grouping can be modified to indicate FEC relationships that don't actually exist. Attacks like that may cause FEC to fail to protect, and/or to mishandle, other media payload streams. So the receiver SHOULD do an integrity check on SDP, and it should follow the security considerations of SDP [RFC4566] and only trust SDP from trusted sources 🛡️
6. IANA Considerations 📋
This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" registry under SDP Parameters:
Semantics Token Reference
------------------------------------- ------ ---------
Forward Error Correction (Deprecated) FEC [RFC5956]
Forward Error Correction FR FEC-FR [RFC5956]This document also registers the following semantics with IANA in the "Semantics for the "ssrc-group" SDP Attribute" registry under SDP Parameters:
Token Semantics Reference
------- ----------------------------- ---------
FEC-FR Forward Error Correction FR [RFC5956]7. Acknowledgments 🫶
Some parts of this document are based on [RFC4756], so the author would like to thank everyone who contributed to [RFC4756]. Also, a big thank you to Jonathan Lennox, who contributed to Section 4.3, and Jean-Francois Mule, who reviewed this document in great detail and suggested text edits 💜
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session
Description Protocol (SDP) Grouping Framework",
RFC 5888, June 2010.8.2. Informative References
[FEC-FRAMEWK] Watson, M., "Forward Error Correction (FEC)
Framework", Work in Progress, September 2010.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
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 💌
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com📦 where this page comes from
- ietf: rfc5956 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms