The Session Description Protocol (SDP) Grouping Framework
Extracted elements (24)
Media alignment in SIP offer/answer is deliberately kept based on matching nth 'm' lines rather than 'mid' labels, because using 'mid' for alignment would not bring any gain but would add complexity to implementations.
No new group semantics were defined for layered encoding because the existing SDP multicast address grouping mechanism (multiple 'c' lines or the /ttl/numaddresses syntax) already covers the most useful scenarios, avoiding unnecessary complexity.
The restriction from RFC 3388 that an 'm' line identifier could only appear in a single group using a given semantics was lifted in RFC 5888. Legacy implementations enforced this only for supported semantics, so lifting it does not cause backward-compatibility issues when new semantics are introduced.
For backward compatibility, if a SIP user agent does not understand the 'group' attribute, it simply ignores it per standard SDP fall-back; no 'Require' header is defined. An answerer not supporting 'group' may incorrectly treat FID-grouped streams as independent parallel streams.
For capability negotiation, a client that understands 'group' and 'mid' but does not want to use them can indicate support by including empty 'a=group' lines for each supported semantics value. A server receiving such an offer SHOULD add its capabilities in the same form in the answer.
'a=group' lines MUST NOT contain identification-tags that correspond to 'm' lines with the port set to zero. When identification-tags in the answer are a subset of those in the offer, the 'group' value to be used in the session MUST be the one present in the answer.
'a=group' lines that contain identification-tags that do not correspond to any 'm' line within the session description MUST be ignored; the application acts as if the 'a=group' line did not exist.
A media agent handling a media flow that comprises several 'm' lines MUST send a copy of the media to every 'm' line that is part of the flow, as long as the codecs and the direction attribute present in a particular 'm' line allow it.
A SIP entity that receives an offer with an 'a=group' line with semantics it does not understand MUST return an answer without the 'group' line, but 'mid' lines MUST still be present. A SIP entity that understands the semantics MUST return an answer containing an 'a=group' line with the same semantics.
All 'm' lines in a session description that uses 'group' MUST be identified with a 'mid' attribute, whether they appear in the group line(s) or not. If any 'm' line lacks a 'mid' identification, the application MUST NOT perform any grouping.
An application that encodes the same media using different codecs simultaneously MUST NOT use FID to group those media lines, since FID is only appropriate when one codec is used at a time (alternative codecs, not parallel encodings).
An application that receives a session description with 'm' lines grouped using LS semantics MUST synchronize the playout of the corresponding media streams. If non-RTP streams are involved, the application MUST recover the original timing relationship using whatever mechanism is available.
FID MUST NOT be used to group 'm' lines that do not represent the same information; specifically, FID MUST NOT be used to group the different layers of layered encoding schemes.
Grouping of 'm' lines MUST always be requested by the offerer, never by the answerer, because an answerer that requested grouping would not know whether the 'group' attribute was accepted.
If media streams using several different codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same 'm' line MUST be used. FID MUST NOT be used to group 'm' lines with the same IP address/port; two 'm' lines grouped using FID MUST differ in their transport addresses.
In SIP offer/answer, the 'mid' value in the offer MUST be the same as the 'mid' value in the answer. Subsequent offers SHOULD use the same 'mid' value for already existing media streams.
SIP systems MUST perform media alignment by matching nth 'm' lines regardless of the presence of 'group' or 'mid' attributes. If a 'mid' identifier in the offer differs from the 'mid' in the answer, all 'mid' and 'group' lines must be ignored.
The identification-tag in a 'mid' attribute MUST be unique within an SDP session description.
Flow Identification (FID) semantics: several 'm' lines grouped together using FID form a media flow, defined as a single media instance (e.g., audio or video stream) that may comprise one or more RTP sessions.
Lip Synchronization (LS) semantics: 'm' lines grouped with LS indicate that their corresponding media streams must be played out in a synchronized manner. Synchronization for RTP streams is typically performed using RTCP.
The 'group' session-level attribute groups together different media streams. Its ABNF syntax is: group-attribute = "a=group:" semantics *(SP identification-tag), where semantics is "LS" / "FID" / semantics-extension.
The 'mid' (media stream identification) attribute identifies individual media streams within an SDP session description. Its ABNF syntax is: mid-attribute = "a=mid:" identification-tag, where identification-tag is a token as defined in RFC 4566.
IANA maintains a registry of SDP grouping semantics. Values are registered following the Standards Action policy. Current entries include LS (RFC 5888), FID (RFC 5888), SRF (RFC 3524), ANAT (RFC 4091), FEC (RFC 4756), and DDP (RFC 5583). Each entry requires a brief description, a token (SHOULD be ≤4 characters), and a reference to a standards track RFC.
Using 'group' with FID semantics, an attacker who can modify exchanged session descriptions could force participants to send media copies to an arbitrary destination. Integrity mechanisms such as S/MIME (end-to-end) or TLS (hop-by-hop) in SIP MUST be used to prevent this attack.