ietf-corpus

rfc-3388

Grouping of Media Lines in the Session Description Protocol (SDP)

G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne
date2002-12 streamIETF areaart wgmmusic statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc3388 doi10.17487/RFC3388
This document defines two SDP attributes: 'groupe' and 'mid'. They allow to group together several 'm' lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams), encoded in different formats during a particular session, in different ports and host interfaces.

obsoleted by

Extracted elements (24)

design-rationale §4

Defining new 'group' semantics beyond LS and FID is explicitly discouraged; implementors are RECOMMENDED to use other session description mechanisms such as SDPng for additional grouping needs. This limits scope creep of the 'group' framework.

realtime

design-rationale §7.1

FID (Flow Identification) semantics were introduced because cellular systems using SIP configure different radio bearers on different port numbers for each codec, requiring multiple RTP sessions to carry a single logical media flow. Existing RTSP/RTP definitions assumed one-to-one mapping of media instances to RTP sessions, which does not hold in these scenarios.

realtime, rtp

design-rationale §8.2

Grouping is restricted to offerers because in the SIP two-way SDP exchange model, an answerer that requested grouping would have no way to know whether the offerer accepted it. An answerer wishing to group media SHOULD issue a subsequent offer (e.g., re-INVITE).

realtime, sip

design-rationale §8.1

Media alignment via 'mid' labels rather than nth-line matching was considered but rejected: it would add implementation complexity without benefit, since 'mid' labels already allow labelling 'm' lines and the nth-line rule already provides the required semantics in offer/answer.

realtime, sip

interoperability-note §8.3

A client that understands 'group' and 'mid' but does not wish to use them in a session MAY advertise capability by including empty 'a=group' lines (one per understood semantics). A server receiving such an offer SHOULD echo empty 'a=group' lines for the semantics it supports.

realtime, sip

interoperability-note §8.4

Backward compatibility relies on standard SDP fall-back: attributes not understood are ignored. If an answerer ignores 'group', for LS it may or may not synchronize streams, and for FID it will treat the session as having multiple independent media streams, with behavior varying by implementation.

realtime, sip

normative-requirement §5 MUST

'a=group' lines containing identification-tags that do not correspond to any 'm' line within the session description MUST be ignored; the application acts as if the line did not exist.

realtime

normative-requirement §8.2 MUST NOT

'a=group' lines MUST NOT contain identification-tags that correspond to 'm' lines with port set to zero (refused streams). Grouping of 'm' lines MUST always be requested by the offerer, never the answerer.

realtime, sip

normative-requirement §7.4 MUST

A media agent handling an FID-grouped media flow MUST send a copy of the media to every 'm' line that is part of the flow, as long as the codecs and direction attribute of that 'm' line permit it. The application uses only one codec at a time; the codec MAY change dynamically.

realtime, rtp

normative-requirement §8.2 MUST

A SIP entity receiving an offer with an 'a=group' line whose semantics are not understood MUST return an answer without the 'group' line (but 'mid' lines MUST still be present). If the semantics are understood, the answer MUST contain an 'a=group' line with the same semantics and identification-tags equal to or a subset of those in the offer.

realtime, sip

normative-requirement §5 MUST

All 'm' lines in a session description that uses 'group' MUST be identified with a 'mid' attribute, whether they appear in the group line or not. If any 'm' line lacks a 'mid' identification, the application MUST NOT perform any grouping of media lines.

realtime

normative-requirement §6 MUST

An application receiving LS-grouped 'm' lines MUST synchronize the playout of the corresponding media streams. For non-RTP streams, the application MUST recover the original timing relationship using whatever available mechanism.

realtime, rtp

normative-requirement §5 MUST NOT

An 'm' line identified by its 'mid' attribute MUST NOT appear in more than one 'a=group' line using the same semantics, though it MAY appear in multiple 'a=group' lines if they use different semantics.

realtime

normative-requirement §7.5.2 MUST NOT

FID MUST NOT be used to group 'm' lines carrying different layers of a layered encoding scheme, because FID requires that all grouped 'm' lines represent the same information.

realtime

normative-requirement §7.5.3 MUST NOT

If several codecs must be sent to the same IP address and port, the traditional SDP syntax of listing multiple codecs in a single 'm' line MUST be used. FID MUST NOT be used to group 'm' lines with the same IP address and port; FID-grouped 'm' lines MUST differ in their transport addresses.

realtime

normative-requirement §8.1 MUST

SIP systems MUST perform media alignment by matching nth 'm' lines regardless of the presence of 'group' or 'mid' attributes. If a stream's 'mid' value differs between offer and answer, the application MUST ignore all 'mid' and 'group' lines in the session description.

realtime, sip

normative-requirement §3 MUST

The identification-tag used in 'a=mid' MUST be unique within an SDP session description.

realtime

normative-requirement §8.1 MUST

The 'mid' value in an SDP answer MUST be the same as the 'mid' value in the corresponding offer. Subsequent offers (e.g., re-INVITE) SHOULD use the same 'mid' value for already existing media streams.

realtime, sip

protocol-element §7.3

A 'media flow' is defined as a single media instance (e.g., audio or video) that may comprise one or more RTP sessions. FID semantics group 'm' lines that together constitute a single media flow, extending the RTSP definition of media stream.

realtime, rtp

protocol-element §4

The 'group' session-level attribute groups together media streams identified by their 'mid' values under a named semantics. This document defines two standard semantics: LS (Lip Synchronization) and FID (Flow Identification). Further semantics must be defined in standards-track RFCs.

realtime, rtp

protocol-element §3

The 'mid' (media stream identification) attribute is defined as 'a=mid:<identification-tag>' where the identification-tag is a token. It labels individual 'm' lines within a session description for use by grouping mechanisms.

realtime, rtp

registry §10

IANA maintains a registry of SDP grouping semantics. New semantics must be defined in standards-track RFCs and include: a brief description, a token (SHOULD be no more than four characters), and the RFC reference. Initial entries: LS (Lip Synchronization) and FID (Flow Identification), both referencing RFC 3388.

registry, realtime

security-consideration §9

An attacker who can modify session descriptions exchanged between participants could use FID semantics to force participants to send media copies to an arbitrary destination. Integrity mechanisms provided by the session description transport protocol and media encryption should be used to prevent this attack.

security, realtime

wire-format §3

The 'mid' attribute BNF is: mid-attribute = "a=mid:" identification-tag; identification-tag = token. The 'group' attribute BNF is: group-attribute = "a=group:" semantics *(space identification-tag); semantics = "LS" | "FID".

realtime