Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
Extracted elements (30)
Alternative simulcast formats (comma-separated rid-ids) within a simulcast stream override normal codec preference ordering on the 'm=' line to allow separation of general codec preferences from simulcast-stream configuration preferences. However, no mechanism forces the answerer to choose the same alternative for multiple simulcast streams.
If media formats would be effectively equivalent across simulcast streams, RTP duplication (RFC 7104) is RECOMMENDED instead of simulcast, to avoid implementation complexity. Simulcast is intended for meaningfully different encoded versions of the same media source.
RtpStreamId (RFC 8852) is chosen as the RTP-level identification mechanism for simulcast streams rather than SSRC alone, because SSRC values can collide and change. RtpStreamId provides stable stream identity that survives SSRC changes, and both RTCP SDES and RTP header extension methods are supported for rapid initial reception.
Simulcast uses a single SDP media description (and thus a single RTP session) for all simulcast streams of a media source. This enables joint congestion control and simpler signaling but precludes applying different QoS to different simulcast streams via separate RTP sessions or different multicast groups — a deliberate trade-off favoring simplicity and reduced middlebox load.
The initially paused 'recv'-direction stream is defined as causing the remote sender to enter an unsolicited locally paused state (rather than being treated as an explicit pause request) because when TMMBR/TMMBN is used for pause/resume, the pausing RTP sender cannot know which receiving SSRC owns the restriction since the receiver's SSRC may not yet be known.
An answerer that does not understand simulcast will not recognize 'a=simulcast' and will remove it in the SDP answer per existing offer/answer procedures (RFC 3264), resulting in fallback to non-simulcast operation without any special handling required from the offerer.
In cases where RTP payload type uniquely maps to a corresponding RtpStreamId, an RTP receiver MAY use RTP PT to relate simulcast streams even before receiving RtpStreamId in RTCP SDES or RTP header extensions, enabling decoding to begin earlier.
The redundant audio data format (RFC 2198) may be used alongside simulcast for loss-protection purposes without conflict. When used as a simulcast stream, the 'red' format rather than the carried formats SHOULD be listed on the 'a=simulcast' line.
When an RTP middlebox (media-switching mixer) forwards simulcast to receivers, any MID SDES item from the originating media source MUST be removed and not associated with the mixer's SSRC, to prevent receivers from incorrectly treating it as an SSRC collision. CSRC may carry the originating SSRC.
When using BUNDLE (RFC 8843), the SDES MID mechanism relates RTP streams to individual media descriptions, after which RtpStreamId relations can be used for simulcast identification. It is recommended to carry both MID and RtpStreamId as RTP header extensions (RFC 7941) to ensure rapid initial reception.
An answerer that receives an offer with multiple 'a=simulcast' attributes in the same media description SHALL disable simulcast by removing all 'a=simulcast' lines for that media description in the answer. An answerer receiving 'a=simulcast' at the session level SHALL remove it in the answer.
An answerer that understands simulcast and wants to support it SHALL reverse directionality of the direction parameters ('send' becomes 'recv' and vice versa). The answerer MUST NOT add alternative rid-ids in the 'send' direction that were not present in the offer's receive direction, and MUST NOT add simulcast streams not present in the offer.
An offerer that receives an answer where some rid-ids are removed MUST NOT send any RTP packets corresponding to the removed rid-ids and MAY release the corresponding resources in its receive direction.
An offerer that receives an answer without 'a=simulcast' MUST NOT use simulcast towards the answerer. An offerer that receives an answer with 'a=simulcast' but without any rid-id in a specified direction MUST NOT use simulcast in that direction.
An offerer wanting to use simulcast for a media description SHALL include one 'a=simulcast' attribute in that media description. An offerer listing receive simulcast streams in the offer MUST be prepared to receive RTP streams for any of those simulcast streams from the answerer.
If RTP stream pause/resume (RFC 7728) is supported and a rid-id is marked as initially paused (prefixed by '~'), support for RTP stream pause/resume MUST also be included under the same 'm=' line, and all related RTP payload types MUST be listed as pause/resume capable.
Implementations MUST NOT use the 'a=simulcast' attribute at the session level and MUST ignore it if received at the session level. Each SDP media description MUST contain at most one 'a=simulcast' line.
RTP streams MUST only use a single alternative rid-id at a time (based on RTP timestamps) but MAY change format (and rid-id) on a per-RTP packet basis, corresponding to the existing SDP offer/answer behavior for multiple formats on an 'm=' line.
Simulcast RTP streams MUST be related at the RTP level through RtpStreamId (RFC 8852). Implementers MUST support the RTCP SDES item method and SHOULD support the RTP header extension method to signal RtpStreamId on the RTP level.
When bitrate adaptation is necessary, what simulcast streams to prioritize SHOULD be taken from the simulcast stream order on the 'a=simulcast' line and ordering of alternative simulcast formats. Streams with pause/resume capability that would receive insufficient bitrate MAY be temporarily paused.
When listing multiple directions on a single 'a=simulcast' line, each direction ('send' or 'recv') MUST NOT occur more than once on the same line. A single rid-id MUST NOT occur more than once per 'a=simulcast' line.
A new media-level SDP attribute 'a=simulcast' is defined. It describes, independently for 'send' and 'receive' directions, the number of simulcast RTP streams and potential alternative formats for each, with each stream identified by a rid-id from RFC 8851. The attribute MUST NOT be used at the session level.
The order of listed simulcast streams in the 'send' direction suggests a proposed order of preference in decreasing order (leftmost = most preferred). In the 'recv' direction, leftmost is most preferred. This ordering guides simulcast stream selection when adaptation requires reducing the number of active streams.
The '~' prefix on a rid-id in the 'a=simulcast' attribute indicates that the corresponding simulcast stream is initially paused. An initially paused 'send'-direction stream is treated as an unsolicited locally paused stream; a 'recv'-direction initially paused stream SHOULD cause the remote RTP sender to put its stream in a locally paused state.
The rid-id on the 'a=simulcast' line is the simulcast stream identifier, defined by 'a=rid' lines per RFC 8851. Each simulcast stream is separated by ';'; alternative formats within a stream are separated by ','. The leftmost listed stream or format is most preferred.
This document registers a new media-level SDP attribute 'simulcast' (long-form: 'Simulcast stream description') in the 'att-field (media level only)' registry within the 'Session Description Protocol (SDP) Parameters' registry. Mux category: NORMAL. Value syntax defined in Section 5.1.
A false inclusion of 'a=simulcast' may cause simultaneous transmission of multiple RTP streams, increasing the number of streams competing for bandwidth of the jointly bounded media description. A hostile removal of 'a=simulcast' silently disables simulcast. Integrity protection and source authentication of all SDP signaling, including simulcast attributes, can mitigate these risks.
Security considerations for 'a=rid' and the RtpStreamId SDES item as used in this specification are covered by RFC 8851 and RFC 8852 respectively. No additional security concerns are introduced by their use in the simulcast context.
An initially paused simulcast stream transitions between paused and active states per RFC 7728 pause/resume signaling. States: paused (stream with '~' prefix or explicitly paused via TMMBR/TMMBN); active (resumed). Triggers: RTCP-based pause/resume messages; bitrate adaptation logic; negotiation of initially paused state in SDP.
The simulcast attribute value (sc-value) is defined in ABNF as: sc-value = (sc-send [SP sc-recv]) / (sc-recv [SP sc-send]); sc-send = %s"send" SP sc-str-list; sc-recv = %s"recv" SP sc-str-list; sc-str-list = sc-alt-list *(";"; sc-alt-list); sc-alt-list = sc-id *("," sc-id); sc-id = ["~"] rid-id. Semicolons separate simulcast streams; commas separate alternative formats within a stream; "~" prefix indicates initially paused.