This section defines new SDP media-level attribute [RFC 4566
], "a=rid", used to communicate a set of restrictions to be applied to an identified RTP stream. Roughly speaking, this attribute takes the following form (see Section 10
for a formal definition):
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
An "a=rid" SDP media attribute specifies restrictions defining a unique RTP payload configuration identified via the "rid-id" field. This value binds the restriction to the RTP stream identified by its RTP Stream Identifier Source Description (SDES) item [RFC 8852
]. Implementations that use the "a=rid" parameter in SDP MUST
support the RtpStreamId SDES item described in [RFC 8852
]. Such implementations MUST
send that SDES item for all streams in an SDP media description ("m=") that have "a=rid" lines remaining after applying the rules in Section 6
and its subsections.
Implementations that use the "a=rid" parameter in SDP and make use of redundancy RTP streams [RFC 7656
] -- e.g., RTP RTX [RFC 4588
] or Forward Error Correction (FEC) [RFC 5109
] -- for any of the source RTP streams that have "a=rid" lines remaining after applying the rules in Section 6
and its subsections MUST
support the RepairedRtpStreamId SDES item described in [RFC 8852
] for those redundancy RTP streams. RepairedRtpStreamId MUST
be used for redundancy RTP streams to which it can be applied. Use of RepairedRtpStreamId is not applicable for redundancy formats that directly associate RTP streams through shared synchronization sources (SSRCs) -- for example, [RFC 8627
] -- or other cases that RepairedRtpStreamId cannot support, such as referencing multiple source streams.
RepairedRtpStreamId is used to provide the binding between the redundancy RTP stream and its source RTP stream by setting the RepairedRtpStreamId value for the redundancy RTP stream to the RtpStreamId value of the source RTP stream. The redundancy RTP stream MAY
(but need not) have an "a=rid" line of its own, in which case the RtpStreamId SDES item value will be different from the corresponding source RTP stream.
It is important to note that this indirection may result in the temporary inability to correctly associate source and redundancy data when the SSRC associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed during the RTP session. This can be avoided if all RTP packets, source and repair, include their RtpStreamId or RepairedRtpStreamId, respectively, after the change. To maximize the probability of reception and utility of redundancy information after such a change, all the source packets referenced by the first several repair packets SHOULD
include such information. It is RECOMMENDED
that the number of such packets is large enough to give a high probability of actual updated association. Section 4.1.1 of [RFC 8285
] provides relevant guidance for RTP header extension transmission considerations. Alternatively, to avoid this issue, redundancy mechanisms that directly reference its source data may be used, such as [RFC 8627
The "direction" field identifies the direction of the RTP stream packets to which the indicated restrictions are applied. It may be either "send" or "recv". Note that these restriction directions are expressed independently of any "inactive", "sendonly", "recvonly", or "sendrecv" attributes associated with the media section. It is, for example, valid to indicate "recv" restrictions on a "sendonly" stream; those restrictions would apply if, at a future point in time, the stream were changed to "sendrecv" or "recvonly".
The optional "pt=<fmt-list>" lists one or more PT values that can be used in the associated RTP stream. If the "a=rid" attribute contains no "pt", then any of the PT values specified in the corresponding "m=" line may be used.
The list of zero or more codec-agnostic restrictions (Section 5
) describes the restrictions that the corresponding RTP stream will conform to.
This framework MAY
be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP payload type. In such scenarios, the "a=rid" restrictions (Section 5
) further restrict the equivalent "a=fmtp" attributes.
A given SDP media description MAY
have zero or more "a=rid" lines describing various possible RTP payload configurations. A given "rid-id" MUST NOT
be repeated in a given media description ("m=" section).
The "a=rid" media attribute MAY
be used for any RTP-based media transport. It is not defined for other transports, although other documents may extend its semantics for such transports.
Though the restrictions specified by the "rid" restrictions follow a syntax similar to session-level and media-level parameters, they are defined independently. All "rid" restrictions MUST
be registered with IANA, using the registry defined in Section 12
gives a formal Augmented Backus-Naur Form (ABNF) [RFC 5234
] grammar for the "rid" attribute. The "a=rid" media attribute is not dependent on charset.