rfc-4756

Forward Error Correction Grouping Semantics in Session Description Protocol

A. Li
date2006-11 streamIETF areaart wgmmusic statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc4756 doi10.17487/RFC4756
This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]

obsoleted by

Extracted elements (12)

design-rationale §3

FEC data can be sent either multiplexed with the original payload (as in RFC 2198) or as a separate stream. This document addresses only the separate-stream case, where SDP grouping is needed to indicate the association.

realtime, rtp

design-rationale §4.1

FEC grouping only indicates the association relationship between streams; detailed FEC protection scheme parameters (e.g., protection level and length for ULP) are conveyed in-band within the FEC stream itself, keeping SDP signaling minimal.

realtime, rtp

interoperability-note §4.2

Backward compatibility in the SDP offer/answer exchange for FEC grouping is handled as specified in RFC 3388 (Grouping of Media Lines in SDP), which this document extends with the FEC semantics token.

realtime, rtp

normative-requirement §4.2 SHOULD

A node that does not understand FEC grouping SHOULD respond to an offer containing FEC grouping either by ignoring the grouping attribute in the answer, or by refusing the request (e.g., SIP 488 or 606).

realtime, rtp

normative-requirement §4.2 MUST

If the answerer ignores the FEC grouping attribute, the original offeror MUST establish the connection without FEC.

realtime, rtp

normative-requirement §4.2 SHOULD

If the answerer refuses the offer containing FEC grouping and the offeror still wishes to establish the session, it SHOULD re-try the request with an offer that does not include FEC.

realtime, rtp

normative-requirement §5 SHOULD

The receiver SHOULD perform an integrity check on SDP and follow the security considerations of RFC 4566 (SDP), accepting SDP only from trusted sources, to mitigate the risk of FEC grouping tampering.

security, realtime

protocol-element §4.1

A FEC Group may contain one or more FEC streams and one or more payload streams, enabling configurations such as one payload stream protected by multiple FEC streams or multiple payload streams sharing a single FEC stream.

realtime, rtp

protocol-element §4.1

The FEC grouping semantics use the 'a=group:FEC' line to indicate association relationships between FEC streams and the payload streams they protect. Streams included in one 'a=group' line form a 'FEC Group'.

realtime, rtp

registry §6

IANA registered 'FEC' as a new semantics token for the 'group' SDP attribute under SDP Parameters, referencing RFC 4756. The full entry is: Semantics = 'Forward Error Correction', Token = 'FEC'.

registry, realtime

security-consideration §5

There is a weak threat that an attacker could modify the FEC grouping in SDP to indicate FEC relationships that do not exist, potentially causing FEC protection to fail or mishandling of media payload streams.

security, realtime

wire-format §4.3

The FEC group is expressed as 'a=group:FEC <mid-list>' in SDP, where each mid value in the list corresponds to an 'm' line identified by an 'a=mid' attribute. Multiple FEC groups may appear in a single session description.

realtime, rtp