<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mmusic-rid-15"
     category="std" updates="4855"> updates="4855" number="8851" submissionType="IETF"
     consensus="true" obsoletes="" xml:lang="en" tocInclude="true"
     sortRefs="true" symRefs="true" version="3"

  <!-- xml2rfc v2v3 conversion 2.30.0 -->
    <title abbrev="RTP Restrictions">RTP Payload Format Restrictions</title>
    <seriesInfo name="RFC" value="8851"/>
    <author initials="A.B." surname="Roach (Editor)" surname="Roach" fullname="Adam Roach"> Roach" role="editor">
    <date year="2018" month="May" day="15"/> month="April" year="2020"/>
    <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
      <t>In this specification, we define a framework for specifying restrictions
on RTP streams in the Session Description Protocol. Protocol (SDP).
This framework defines a new “rid” (“restriction identifier”) "rid" ("restriction identifier") SDP attribute to
unambiguously identify the RTP Streams streams within an RTP Session session and restrict the streams’
streams' payload format parameters in a codec-agnostic way beyond what is
provided with the regular Payload Types.</t> payload types.</t>
      <t>This specification updates RFC4855 RFC 4855 to give additional guidance on choice of
Format Parameter (fmtp) names, names and on their relation to the restrictions
defined by this document.</t>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <t>The terms “Source "source RTP Stream”, “Endpoint”, “RTP Session”, stream", "endpoint", "RTP session", and “RTP Stream” "RTP stream"
are used as defined in <xref target="RFC7656"/>.</t> target="RFC7656" format="default"/>.</t>
      <t><xref target="RFC4566"/> target="RFC4566" format="default"/> and <xref target="RFC3264"/> target="RFC3264" format="default"/> terminology is also used where appropriate.</t>
    <section anchor="sec-intro" title="Introduction"> numbered="true" toc="default">
      <t>The Payload Type payload type (PT) field in RTP provides a mapping between the RTP payload
format and the associated SDP media description. The For a given PT, the SDP
rtpmap and/or fmtp attributes are used, for a given PT, used to describe the properties of
the media that is carried in the RTP payload.</t>
      <t>Recent advances in standards have given rise to rich
multimedia applications requiring support for either multiple RTP Streams streams within an
RTP session <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, target="RFC8843" format="default"/> <xref target="I-D.ietf-mmusic-sdp-simulcast"/> target="RFC8853" format="default"/> or having to support a
large number of codecs.
These demands have unearthed challenges inherent with:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>The restricted RTP PT space in specifying the various payload
        <li>The codec-specific constructs for the payload formats in SDP,</t>
  <t>Missing SDP</li>
        <li>Missing or underspecified payload format parameters,</t>
  <t>Overloading parameters</li>
        <li>Overloading of PTs to indicate not just codec configurations, but
individual streams within an RTP session.</t>
</list></t> session</li>
      <t>To expand on these points: <xref target="RFC3550"/> target="RFC3550" format="default"/>
      assigns 7 bits for the PT in the RTP header.  However, the assignment of
      static mapping of RTP payload type numbers to payload formats and
      multiplexing of RTP with other protocols (such as RTCP) the RTP Control
      Protocol (RTCP)) could result in a limited number of payload type
      numbers available for application usage. In scenarios where the number
      of possible RTP payload configurations exceeds the available PT space
      within an RTP Session, session, there is a need for a way to represent the
      additional restrictions on payload configurations and to effectively map an
      RTP Stream stream to its corresponding restrictions. This issue is exacerbated
      by the increase in techniques  -- such as simulcast and layered codecs – which --
      that introduce additional streams into RTP Sessions.</t> sessions.</t>
      <t>This specification defines a new SDP framework for restricting Source source RTP
streams (Section 2.1.10 of <xref target="RFC7656"/>), target="RFC7656" format="default"/>), along with
the SDP attributes to restrict payload formats in a codec-agnostic way.
This framework can be thought of as a complementary extension to the way
the media format parameters are specified in SDP today, via the “a=fmtp” "a=fmtp"
      <t>The additional restrictions on individual streams are indicated with a new
“a=rid” (“restriction identifier”)
"a=rid" ("restriction identifier") SDP attribute. Note that the restrictions communicated via this
attribute only serve to further restrict the parameters that are established
on a PT format. They do not relax any restrictions imposed by other mechanisms.</t>
      <t>This specification makes use of the RTP Stream Identifier Source Description
(SDES) RTCP item defined in <xref target="I-D.ietf-avtext-rid"/> target="RFC8852" format="default"/>  to provide correlation
between the RTP Packets packets and their format specification in the SDP.</t>
      <t>As described in <xref target="sec-rid_unaware"/>, target="sec-rid_unaware" format="default"/>, this mechanism achieves backwards
compatibility via the normal SDP processing rules, which require unknown a= "a="
lines to be ignored. This means that implementations need to be prepared
to handle successful offers and answers from other implementations that
neither indicate nor honor the restrictions requested by this mechanism.</t>
      <t>Further, as described in <xref target="sec-sdp_o_a"/> target="sec-sdp_o_a" format="default"/> and its subsections, this mechanism
achieves extensibility by: (a) having offerers include all supported
restrictions in their offer, and (b) having answerers ignore “a=rid” "a=rid" lines that
specify unknown restrictions.</t>
    <section anchor="key-words-for-requirements" title="Key numbered="true" toc="default">
      <name>Key Words for Requirements">

<t>The Requirements</name>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
“MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
    <section anchor="sec-rid_attribute" title="SDP “a=rid” numbered="true" toc="default">
      <name>SDP "a=rid" Media Level Attribute"> Attribute</name>
      <t>This section defines new SDP media-level attribute <xref target="RFC4566"/>, “a=rid”,
      target="RFC4566" format="default"/>, "a=rid",
used to communicate a set of restrictions to be
applied to an identified RTP Stream. stream.  Roughly speaking, this attribute takes
the following form (see <xref target="sec-abnf"/> target="sec-abnf" format="default"/> for a
formal definition).</t>

<figure><artwork><![CDATA[ definition):</t>

<sourcecode type="sdp"><![CDATA[
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...


      <t>An “a=rid” "a=rid" SDP media attribute specifies restrictions defining a unique
RTP payload configuration identified via the “rid-id” "rid-id" field. This
value binds the restriction to the RTP Stream stream identified by its RTP
Stream Identifier Source Description (SDES) item <xref target="I-D.ietf-avtext-rid"/>. target="RFC8852" format="default"/>.
Implementations that use the “a=rid” "a=rid" parameter in SDP MUST <bcp14>MUST</bcp14> support
the RtpStreamId SDES item described in <xref target="I-D.ietf-avtext-rid"/>. target="RFC8852" format="default"/>. Such
implementations MUST <bcp14>MUST</bcp14> send that SDES item for all streams in an SDP media description
("m=") that have “a=rid” "a=rid" lines remaining after applying the rules in
<xref target="sec-sdp_o_a"/> target="sec-sdp_o_a" format="default"/> and its subsections.</t>
      <t>Implementations that use the “a=rid” "a=rid" parameter in SDP and that make use of
redundancy RTP streams <xref target="RFC7656"/>, e.g. target="RFC7656" format="default"/> -- e.g., RTP RTX
<xref target="RFC4588"/> target="RFC4588" format="default"/> or FEC Forward Error Correction (FEC) <xref target="RFC5109"/>, target="RFC5109" format="default"/> -- for any of the
source RTP streams that have “a=rid” "a=rid" lines remaining
after applying the rules in <xref target="sec-sdp_o_a"/> target="sec-sdp_o_a" format="default"/> and its subsections, MUST subsections <bcp14>MUST</bcp14>
support the RepairedRtpStreamId SDES item described in
<xref target="I-D.ietf-avtext-rid"/> target="RFC8852" format="default"/> for those redundancy RTP streams. RepairedRtpStreamId
<bcp14>MUST</bcp14> 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 SSRCs (for example synchronization sources (SSRCs) -- for example, <xref target="I-D.ietf-payload-flexible-fec-scheme"/>)
target="RFC8627" format="default"/> --
or other cases that RepairedRtpStreamId cannot support, such as referencing
multiple source streams.</t>
      <t>RepairedRtpStreamId is used to provide the binding between the redundancy RTP
stream and its source RTP stream, 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 <bcp14>MAY</bcp14> (but need not) have an “a=rid” "a=rid" line of its own,
in which case the RtpStreamId SDES item value will be different from the
corresponding source RTP stream.</t>
      <t>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, after the change 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 <bcp14>SHOULD</bcp14> include such information.  It is
<bcp14>RECOMMENDED</bcp14> that the number of such packets is large enough to give a high
probability of actual updated association. Section 4.1.1 of <xref target="RFC8285"/> target="RFC8285" format="default"/>
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
<xref target="I-D.ietf-payload-flexible-fec-scheme"/>.</t> target="RFC8627" format="default"/>.</t>
      <t>The “direction” "direction" field identifies the direction of the RTP Stream stream packets to
which the indicated restrictions are applied. It may be either “send” "send" or
"recv". Note that these restriction directions are expressed independently of
any “inactive”, “sendonly”, “recvonly”, "inactive", "sendonly", "recvonly", or “sendrecv” "sendrecv" attributes associated
with the media section.  It is, for example, valid to indicate “recv” "recv"
restrictions on a “sendonly” "sendonly" stream; those restrictions would apply if, at a
future point in time, the stream were changed to “sendrecv” "sendrecv" or “recvonly”.</t> "recvonly".</t>
      <t>The optional “pt=&lt;fmt-list&gt;” "pt=&lt;fmt-list&gt;" lists one or more PT values that can be used
in the associated RTP Stream. stream. If the “a=rid” "a=rid" attribute contains
no “pt”, "pt", then any of the PT values specified in the corresponding “m=” "m="
line may be used.</t>
      <t>The list of zero or more codec-agnostic restrictions
(<xref target="sec-rid_level_restrictions"/>) describe target="sec-rid_level_restrictions" format="default"/>) describes the restrictions that the
corresponding RTP Stream stream will conform to.</t>
      <t>This framework MAY <bcp14>MAY</bcp14> be used in combination with the “a=fmtp” "a=fmtp" SDP attribute
for describing the media format parameters for a given RTP Payload Type. payload type.  In
such scenarios, the “a=rid” "a=rid" restrictions (<xref target="sec-rid_level_restrictions"/>) target="sec-rid_level_restrictions" format="default"/>)
further restrict the equivalent “a=fmtp” "a=fmtp" attributes.</t>
      <t>A given SDP media description MAY <bcp14>MAY</bcp14> have zero or more “a=rid” "a=rid" lines describing
various possible RTP payload configurations. A given “rid-id” MUST NOT "rid-id" <bcp14>MUST NOT</bcp14>
be repeated in a given media description (“m=” ("m=" section).</t>
      <t>The “a=rid” "a=rid" media attribute MAY <bcp14>MAY</bcp14> 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.</t>
      <t>Though the restrictions specified by the “rid” "rid" restrictions follow a
syntax similar to session-level and media-level parameters, they are defined
independently.  All “rid” "rid" restrictions MUST <bcp14>MUST</bcp14> be registered with IANA, using
the registry defined in <xref target="sec-iana"/>.</t> target="sec-iana" format="default"/>.</t>
      <t><xref target="sec-abnf"/> target="sec-abnf" format="default"/> gives a formal Augmented Backus-Naur Form (ABNF) <xref target="RFC5234"/> target="RFC5234" format="default"/>
grammar for the “rid” "rid" attribute. The “a=rid” "a=rid" media attribute is not dependent
on charset.</t>
    <section anchor="sec-rid_level_restrictions" title="“a=rid” restrictions"> numbered="true" toc="default">
      <name>"a=rid" Restrictions</name>
      <t>This section defines the “a=rid” "a=rid" restrictions that can be used to restrict
the RTP payload encoding format in a codec-agnostic way.</t>
      <t>The following restrictions are intended to apply to video codecs in a
codec-independent fashion.</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>max-width, for spatial resolution in pixels.  In the case that stream
  stream-orientation signaling is used to modify the intended display
  orientation, this attribute refers to the width of the stream when a
  rotation of zero degrees is encoded.</t>
  <t>max-height, encoded.</li>
        <li>max-height, for spatial resolution in pixels.  In the case that stream
  stream-orientation signaling is used to modify the intended display
this attribute refers to the height of the stream when a rotation of zero
degrees is encoded.</t>
  <t>max-fps, encoded.</li>
        <li>max-fps, for frame rate in frames per second.  For encoders that do not use
a fixed framerate frame rate for encoding, this value is used to restrict the minimum
amount of time between frames: the time between any two consecutive frames
<bcp14>SHOULD NOT</bcp14> be less than 1/max-fps seconds.</t>
  <t>max-fs, seconds.</li>
        <li>max-fs, for frame size in pixels per frame. This is the product of frame
width and frame height, in pixels, for rectangular frames.</t>
  <t>max-br, frames.</li>
        <li>max-br, for bit rate bitrate in bits per second.  The restriction applies to the
media payload only, only and does not include overhead introduced by other layers
(e.g., RTP, UDP, IP, or Ethernet).  The exact means of keeping within this
limit are left up to the implementation, and instantaneous excursions
outside the limit are permissible. For any given one-second sliding window,
however, the total number of bits in the payload portion of RTP SHOULD NOT <bcp14>SHOULD NOT</bcp14>
exceed the value specified in “max-br.”</t>
  <t>max-pps, "max-br."</li>
        <li>max-pps, for pixel rate in pixels per second.  This value SHOULD <bcp14>SHOULD</bcp14> be handled
identically to max-fps, after performing the following conversion: max-fps =
max-pps / (width * height). If the stream resolution changes, this value is
recalculated. Due to this recalculation, excursions outside the specified
maximum are possible near resolution change boundaries.</t>
  <t>max-bpp, resolution-change boundaries.</li>
        <li>max-bpp, for maximum number of bits per pixel, calculated as an average of
all samples of any given coded picture. This is expressed as
a floating point value, with an allowed range of 0.0001 to 48.0. These
values MUST NOT <bcp14>MUST NOT</bcp14> be encoded with more than four digits to the right of the
decimal point.</t>
  <t>depend, point.</li>
        <li>depend, to identify other streams that the stream depends on. The value
is a comma-separated list of rid-ids. These rid-ids identify RTP streams
that this stream depends on in order to allow for proper interpretation.
The mechanism defined in this document allows for such dependencies
to be expressed only when the streams are in the same media section.</t>
</list></t> section.</li>
      <t>All the restrictions are optional and are subject to negotiation based on the
SDP Offer/Answer offer/answer rules described in <xref target="sec-sdp_o_a"/>.</t> target="sec-sdp_o_a" format="default"/>.</t>
      <t>This list is intended to be an initial set of restrictions. Future documents
may define additional restrictions; see <xref target="sec-iana_rid"/>. target="sec-iana_rid" format="default"/>.  While this document
does not define restrictions for audio codecs or any media types other than
video, there is no reason such
restrictions should be precluded from definition and registration by other
      <t><xref target="sec-abnf"/> target="sec-abnf" format="default"/> provides formal Augmented Backus-Naur Form (ABNF) <xref target="RFC5234"/> target="RFC5234" format="default"/>
grammar for each of the “a=rid” "a=rid" restrictions defined in this section.</t>
    <section anchor="sec-sdp_o_a" title="SDP numbered="true" toc="default">
      <name>SDP Offer/Answer Procedures"> Procedures</name>
      <t>This section describes the SDP Offer/Answer <xref target="RFC3264"/> offer/answer procedures <xref target="RFC3264" format="default"/> when
using this framework.</t>
      <t>Note that “rid-id” "rid-id" values are only required to be unique within a
media section (“m-line”); ("m=" line); they do not necessarily need to be unique within an
entire RTP session. In traditional usage, each media section is sent on its
own unique 5-tuple (that is: combination of sending address, sending port,
receiving address, receiving port, and transport protocol), which provides an
unambiguous scope.

<!--[rfced] "MID" has been expanded as "Media Identification" here
per draft-ietf-mmusic-sdp-bundle-negotiation (RFC-to-be 8843), and
"RID" has been expanded as "Restriction Identification";
please review. (We note "restriction identifier" is used elsewhere.)

   when using BUNDLE
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, [I-D.ietf-mmusic-sdp-bundle-negotiation], MID
   values associate RTP streams uniquely to a single media description.
   When RID is used with the BUNDLE mechanism, streams will be
   associated with both MID and RID SDES items.

   when using BUNDLE [RFC8843], MID values associate RTP streams
   uniquely to a single media description.  When RID is used with the
   BUNDLE mechanism, streams will be associated with both MID and RID
   SDES items.

Similarly, when using BUNDLE <xref target="RFC8843" format="default"/>,
Media Identification (MID) values associate RTP streams
uniquely to a single media description.

 When Restriction Identification (RID) is used with the BUNDLE
mechanism, streams will be associated with both MID and RID SDES items.</t>
      <section anchor="sec-gen_offer" title="Generating numbered="true" toc="default">
        <name>Generating the Initial SDP Offer"> Offer</name>
        <t>For each RTP media description in the offer, the offerer MAY <bcp14>MAY</bcp14> choose to include one
or more “a=rid” "a=rid" lines to specify a configuration profile for the given set of
RTP Payload Types.</t> payload types.</t>
        <t>In order to construct a given “a=rid” "a=rid" line, the offerer must follow these

<t><list style="numbers">
  <t>It MUST
        <ol spacing="normal" type="1">
          <li>It <bcp14>MUST</bcp14> generate a “rid-id” "rid-id" that is unique within a media
  <t>It MUST
          <li>It <bcp14>MUST</bcp14> set the direction for the “rid-id” "rid-id" to one of
"send" or “recv”</t>
  <t>It MAY "recv".</li>
          <li>It <bcp14>MAY</bcp14> include a listing of SDP media formats (usually corresponding to RTP
payload types) allowed to appear in the RTP Stream. stream. Any Payload Types payload type
chosen MUST <bcp14>MUST</bcp14> be a valid payload type for the media section (that is, it must
be listed on the “m=” "m=" line).  The order of the listed formats is
significant; the alternatives are listed from (left) most preferred to
(right) least preferred.  When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on the
"m=" line, using regular SDP rules.</t>
  <t>The Offerer rules.</li>
          <li>The offerer then chooses zero or more “a=rid” "a=rid" restrictions
(<xref target="sec-rid_level_restrictions"/>) target="sec-rid_level_restrictions" format="default"/>) to be applied to the RTP Stream, stream and
adds them to the “a=rid” line.</t>
  <t>If "a=rid" line.</li>
          <li>If the offerer wishes the answerer to have the ability to specify a
restriction but does not wish to set a value itself, it includes the
name of the restriction in the “a=rid” "a=rid" line, but without any indicated
        <t>Note: If an “a=fmtp” "a=fmtp" attribute is also used to provide media-format-specific
parameters, then the “a=rid” "a=rid" restrictions will further restrict the
equivalent “a=fmtp” "a=fmtp" parameters for the given Payload Type payload type for the specified
RTP Stream.</t> stream.</t>
        <t>If a given codec would require an “a=fmtp” "a=fmtp" line when used without “a=rid” "a=rid", then
the offer MUST <bcp14>MUST</bcp14> include a valid corresponding “a=fmtp” "a=fmtp" line even when using
      <section anchor="answerer-processing-the-sdp-offer" title="Answerer processing numbered="true" toc="default">
        <name>Answerer Processing the SDP Offer"> Offer</name>
        <section anchor="sec-rid_unaware" title="“a=rid”-unaware Answerer"> numbered="true" toc="default">
          <name>"a=rid"-Unaware Answerer</name>
          <t>If the receiver doesn’t doesn't support the framework defined in this
specification, the entire “a=rid” "a=rid" line is ignored following the standard
offer/answer rules <xref target="RFC3264"/> Offer/Answer rules.</t> target="RFC3264" format="default"/>.</t>
          <t><xref target="sec-gen_offer"/> target="sec-gen_offer" format="default"/> requires the offer to include a valid “a=fmtp” "a=fmtp" line
for any media formats that otherwise require it (in other words, the “a=rid” "a=rid"
line cannot be used to replace “a=fmtp” "a=fmtp" configuration). As a result,
ignoring the “a=rid” "a=rid" line is always guaranteed to result in a valid
session description.</t>
        <section anchor="sec-rid_offer_recv" title="“a=rid”-aware Answerer"> numbered="true" toc="default">
          <name>"a=rid"-Aware Answerer</name>
          <t>If the answerer supports the “a=rid” "a=rid" attribute, the following verification
steps are executed, in order, for each “a=rid” "a=rid" line in a received offer:</t>

<t><list style="numbers">
          <ol spacing="normal" type="1">
            <li>The answerer ensures that the “a=rid” "a=rid" line is syntactically well
formed. In the case of a syntax error, the “a=rid” "a=rid" line is discarded.</t>
  <t>The discarded.</li>
            <li>The answerer extracts the rid-id from the “a=rid” "a=rid" line and verifies its
uniqueness within a media section.  In the case of a duplicate, the entire
"a=rid" line, and all “a=rid” "a=rid" lines with rid-ids that duplicate this line,
are discarded and MUST NOT <bcp14>MUST NOT</bcp14> be included in the SDP Answer.</t>
  <t>If answer.</li>
            <li>If the “a=rid” "a=rid" line contains a “pt=”, "pt=", the list of payload types
is verified against the list of valid payload types for the media section
(that is, those listed on the “m=” "m=" line). Any PT missing from the “m=” "m=" line
is discarded from the set of values in the “pt=”. "pt=". If no values are left
in the “pt=” "pt=" parameter after this processing, then the “a=rid” "a=rid" line is discarded.</t>
  <t>If discarded.</li>
            <li>If the “direction” "direction" field is “recv”, "recv", the answerer ensures that the specified
"a=rid" restrictions are supported.  In the case of an unsupported
restriction, the “a=rid” "a=rid" line is discarded.</t>
  <t>If discarded.</li>
            <li>If the “depend” "depend" restriction is included, the answerer MUST <bcp14>MUST</bcp14> make
sure that the listed rid-ids unambiguously match the
rid-ids in the media description.  Any “depend” “a=rid” "depend" "a=rid" lines that do not are
            <li>The answerer verifies that the restrictions are consistent
with at least one of the codecs to be used with the RTP Stream. stream. If the
"a=rid" line contains a “pt=”, "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the associated
"m=" line.  See <xref target="sec-feature_interactions"/> target="sec-feature_interactions" format="default"/> for more detail. If the
"a=rid" restrictions are incompatible with the other codec properties
for all codecs, then the “a=rid” "a=rid" line is discarded.</t>
</list></t> discarded.</li>
          <t>Note that the answerer does not need to understand every restriction present
in a “send” "send" line: if a stream sender restricts the stream in a way that the
receiver does not understand, this causes no issues with interoperability.</t>
      <section anchor="sec-rid_answer_send" title="Generating numbered="true" toc="default">
        <name>Generating the SDP Answer"> Answer</name>
        <t>Having performed verification of the SDP offer as described in
<xref target="sec-rid_offer_recv"/>, target="sec-rid_offer_recv" format="default"/>, the answerer shall perform the following steps to
generate the SDP answer.</t>
        <t>For each “a=rid” "a=rid" line that has not been discarded by previous processing:</t>

<t><list style="numbers">
        <ol spacing="normal" type="1">
          <li>The value of the “direction” "direction" field is reversed: “send” "send" is changed
to “recv”, "recv", and “recv” "recv" is changed to “send”.</t>
  <t>The "send".</li>
          <li>The answerer MAY <bcp14>MAY</bcp14> choose to modify specific “a=rid” "a=rid" restriction values in
the answer SDP. In such a case, the modified value MUST <bcp14>MUST</bcp14> be more restrictive
than the ones specified in the offer.  The answer MUST NOT <bcp14>MUST NOT</bcp14> include any
restrictions that were not present in the offer.</t>
  <t>The offer.</li>
          <li>The answerer MUST NOT <bcp14>MUST NOT</bcp14> modify the “rid-id” "rid-id" present in the offer.</t>
  <t>If offer.</li>
          <li>If the “a=rid” "a=rid" line contains a “pt=”, "pt=", the answerer is allowed to
discard one or more media formats from a given “a=rid” "a=rid" line. If the answerer
chooses to discard all the media formats from an “a=rid” "a=rid" line, the
answerer MUST <bcp14>MUST</bcp14> discard the entire “a=rid” "a=rid" line. If the offer did not contain
a “pt=” "pt=" for a given “a=rid” "a=rid" line, then the answer MUST NOT <bcp14>MUST NOT</bcp14>
contain a “pt=” "pt=" in the corresponding line.</t>
  <t>In line.</li>
          <li>In cases where the answerer is unable to support the payload configuration
specified in a given “a=rid” "a=rid" line with a direction of “recv” "recv" in the offer,
the answerer MUST <bcp14>MUST</bcp14> discard the corresponding “a=rid” "a=rid" line.  This includes
situations in which the answerer does not understand one or more of the
restrictions in an “a=rid” "a=rid" line with a direction of “recv”.</t>
</list></t> "recv".</li>
        <t>Note: in In the case that the answerer uses different PT values to represent a
codec than the offerer did, the “a=rid” "a=rid" values in the answer use the PT values
that are present in its answer.</t>
      <section anchor="sec-rid_answer_recv" title="Offerer numbered="true" toc="default">
        <name>Offerer Processing of the SDP Answer"> Answer</name>
        <t>The offerer SHALL <bcp14>SHALL</bcp14> follow these steps when processing the answer:</t>

<t><list style="numbers">
        <ol spacing="normal" type="1">
          <li>The offerer matches the “a=rid” "a=rid" line in the answer to the “a=rid” "a=rid" line
in the offer using the “rid-id”. "rid-id". If no matching line can be located
in the offer, the “a=rid” "a=rid" line is ignored.</t>
  <t>If ignored.</li>
          <li>If the answer contains any restrictions that were not present in the offer,
then the offerer SHALL <bcp14>SHALL</bcp14> discard the “a=rid” line.</t>
  <t>If "a=rid" line.</li>
          <li>If the restrictions have been changed between the offer and the
answer, the offerer MUST <bcp14>MUST</bcp14> ensure that the modifications are more restrictive
than they were in the original offer, offer and that they can be supported; if
not, the offerer SHALL <bcp14>SHALL</bcp14> discard the “a=rid” line.</t>
  <t>If "a=rid" line.</li>
          <li>If the “a=rid” "a=rid" line in the answer contains a “pt=” "pt=" but the
offer did not, the offerer SHALL <bcp14>SHALL</bcp14> discard the “a=rid” line.</t>
  <t>If "a=rid" line.</li>
          <li>If the “a=rid” "a=rid" line in the answer contains a “pt=” "pt=" and the
offer did as well, the offerer verifies that the list of payload types is a
subset of those sent in the corresponding “a=rid” "a=rid" line in the offer. Note
that this matching must be performed semantically rather than on literal PT
values, as the remote end may not be using symmetric PTs. For the purpose
of this comparison: for each PT listed on the “a=rid” "a=rid" line in the answer,
the offerer looks up the corresponding “a=rtpmap” "a=rtpmap" and “a=fmtp” "a=fmtp" lines in the
answer.  It then searches the list of “pt=” "pt=" values indicated in the offer, offer
and attempts to find one with an equivalent set of “a=rtpmap” "a=rtpmap" and “a=fmtp” "a=fmtp"
lines in the offer. If all PTs in the answer can be matched, then the “pt=” "pt="
values pass validation; otherwise, it fails.  If this validation fails, the
offerer SHALL <bcp14>SHALL</bcp14> discard the “a=rid” "a=rid" line. Note that this semantic comparison
necessarily requires an understanding of the meaning of codec parameters,
rather than a rote byte-wise comparison of their values.</t>
  <t>If values.</li>
          <li>If the “a=rid” "a=rid" line contains a “pt=”, "pt=", the offerer verifies that
the attribute values provided in the “a=rid” "a=rid" attributes are consistent
with the corresponding codecs and their other parameters. See
<xref target="sec-feature_interactions"/> target="sec-feature_interactions" format="default"/> for more detail. If the “a=rid” "a=rid" restrictions
are incompatible with the other codec properties, then the offerer
<bcp14>SHALL</bcp14> discard the “a=rid” line.</t>
  <t>The "a=rid" line.</li>
          <li>The offerer verifies that the restrictions are consistent
with at least one of the codecs to be used with the RTP Stream. stream. If the
"a=rid" line contains a “pt=”, "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the associated
"m=" line.  See <xref target="sec-feature_interactions"/> target="sec-feature_interactions" format="default"/> for more detail. If the
"a=rid" restrictions are incompatible with the other codec properties
for all codecs, then the offerer SHALL <bcp14>SHALL</bcp14> discard the “a=rid” line.</t>
</list></t> "a=rid" line.</li>
        <t>Any “a=rid” "a=rid" line present in the offer that was not matched by step 1 above
has been discarded by the answerer, answerer and does not form part of the negotiated
restrictions on an RTP Stream. stream. The offerer MAY <bcp14>MAY</bcp14> still apply any restrictions
it indicated in an “a=rid” "a=rid" line with a direction field of “send”, "send", but
it is not required to do so.</t>
        <t>It is important to note that there are several ways in which an offer can
contain a media section with “a=rid” "a=rid" lines, but although the corresponding media
section in the response does not. This includes situations in which the
answerer does not support “a=rid” "a=rid" at all, all or does not support the indicated
restrictions. Under such circumstances, the offerer MUST <bcp14>MUST</bcp14> be prepared to
receive a media stream to which no restrictions have been applied.</t>
      <section anchor="modifying-the-session" title="Modifying numbered="true" toc="default">
        <name>Modifying the Session"> Session</name>
        <t>Offers and answers inside an existing session follow the rules for initial
session negotiation.  Such an offer MAY <bcp14>MAY</bcp14> propose a change in the number of RIDs
in use. To avoid race conditions with media, any RIDs with proposed changes
<bcp14>SHOULD</bcp14> use a new ID, ID rather than re-using reusing one from the previous offer/answer
exchange. RIDs without proposed changes SHOULD re-use <bcp14>SHOULD</bcp14> reuse the ID from the previous
    <section anchor="sec-declarative_sdp" title="Use numbered="true" toc="default">
      <name>Use with Declarative SDP"> SDP</name>
      <t>This document does not define the use of a RID in declarative SDP. If
concrete use cases for RID in declarative SDP use are identified
in the future, we expect that additional specifications will address
such use.</t>
    <section anchor="sec-feature_interactions" title="Interaction numbered="true" toc="default">
      <name>Interaction with Other Techniques"> Techniques</name>
      <t>Historically, a number of other approaches have been defined that allow
restricting media streams via SDP. These include:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>Codec-specific configuration set via format parameters (“a=fmtp”); ("a=fmtp") -- for
example, the H.264 “max-fs” "max-fs" format parameter <xref target="RFC6184"/></t>
  <t>Size target="RFC6184" format="default"/></li>

<!--[rfced] Is the repetition of "attribute attributes" intentional?

   o  Size restrictions imposed by image attribute attributes
      ("a=imageattr") [RFC6236]

   o  Size restrictions imposed by the "a=imageattr" attribute
        <li>Size restrictions imposed by image attribute attributes (“a=imageattr”) ("a=imageattr")
<xref target="RFC6236"/></t>
</list></t> target="RFC6236" format="default"/></li>
      <t>When the mechanism described in this document is used in conjunction with
these other restricting mechanisms, it is intended to impose additional
restrictions beyond those communicated in other techniques.</t>
      <t>In an offer, this means that “a=rid” "a=rid" lines, when combined with other
restrictions on the media stream, are expected to result in a non-empty intersection.
For example, if image attributes are used to indicate that a PT has a minimum
width of 640, then specification of “max-width=320” "max-width=320" in an “a=rid” "a=rid" line that is
then applied to that PT is nonsensical. According to the rules of
<xref target="sec-rid_offer_recv"/>, target="sec-rid_offer_recv" format="default"/>, this will result in the corresponding “a=rid” "a=rid" line
being ignored by the recipient.</t>
      <t>In an answer, the “a=rid” "a=rid" lines, when combined with the other
restrictions on the media stream, are also expected to result in a non-empty
intersection. If the implementation generating an answer wishes to restrict a
property of the stream below that which would be allowed by other parameters
(e.g., those specified in “a=fmtp” "a=fmtp" or “a=imageattr”), "a=imageattr"), its only recourse is to
discard the “a=rid” "a=rid" line altogether, as described in <xref target="sec-rid_answer_send"/>. target="sec-rid_answer_send" format="default"/>.
If it instead attempts to restrict the stream beyond what is allowed by other
mechanisms, then the offerer will ignore the corresponding “a=rid” "a=rid" line, as
described in <xref target="sec-rid_answer_recv"/>.</t> target="sec-rid_answer_recv" format="default"/>.</t>
      <t>The following subsections demonstrate these interactions using commonly-used commonly used
video codecs. These descriptions are illustrative of the interaction principles
outlined above, above and are not normative.</t>
      <section anchor="interaction-with-vp8-format-parameters" title="Interaction numbered="true" toc="default">
        <name>Interaction with VP8 Format Parameters"> Parameters</name>
        <t><xref target="RFC7741"/> target="RFC7741" format="default"/> defines two format parameters for the VP8 codec.
Both correspond to restrictions on receiver capabilities, capabilities and never
indicate sending restrictions.</t>
        <section anchor="max-fr-maximum-framerate" title="max-fr numbered="true" toc="default">
          <name>max-fr - Maximum Framerate"> Frame Rate</name>
          <t>The VP8 “max-fr” "max-fr" format parameter corresponds to the “max-fps” "max-fps" restriction
defined in this specification.  If an RTP sender is generating a stream using
a format defined with this format parameter, and the sending restrictions
defined via “a=rid” "a=rid" include a “max-fps” "max-fps" parameter, then the sent stream
will conform to the smaller of the two values.</t>
        <section anchor="max-fs-maximum-framesize-in-vp8-macroblocks" title="max-fs numbered="true" toc="default">
          <name>max-fs - Maximum Framesize, Frame Size, in VP8 Macroblocks"> Macroblocks</name>
          <t>The VP8 “max-fs” "max-fs" format parameter corresponds to the “max-fs” "max-fs"
restriction defined in this document, by way of a conversion factor of the
number of pixels per macroblock (typically 256).  If an RTP sender is
generating a stream using a format defined with this format parameter, and
the sending restrictions defined via “a=rid” "a=rid" include a “max-fs” "max-fs" parameter,
then the sent stream will conform to the smaller of the two values;
that is, the number of pixels per frame will not exceed:</t>


  min(rid_max_fs, fmtp_max_fs * macroblock_size)
          <t>This fmtp parameter also has bearing on the
max-height and max-width parameters.

<!-- [rfced] This seems to redundantly repeat "required";
may it be rephrased as follows or otherwise?

   Section 6.1 of [RFC7741] requires that the width and
   height of the frame in macroblocks are also required to be less than
   int(sqrt(fmtp_max_fs * 8)).

   Section 6.1 of [RFC7741] requires that the width and
   height of the frame in macroblocks be less than
   int(sqrt(fmtp_max_fs * 8)).

<xref target="RFC7741"/> section="6.1" sectionFormat="of" target="RFC7741" format="default"/> requires that the width and height of the frame in
macroblocks are also required to be less than int(sqrt(fmtp_max_fs * 8)).
Accordingly, the maximum width of a transmitted stream will be limited to:</t>


  min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width)

          <t>Similarly, the stream’s stream's height will be limited to:</t>


  min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height)
      <section anchor="interaction-with-h264-format-parameters" title="Interaction numbered="true" toc="default">
        <name>Interaction with H.264 Format Parameters"> Parameters</name>
        <t><xref target="RFC6184"/> target="RFC6184" format="default"/> defines format parameters for the H.264 video codec. The majority
of these parameters do not correspond to codec-independent restrictions:</t>

<t><list style="symbols">
        <ul spacing="normal">
        <t>Note that the max-cpb and max-dpb format parameters for H.264 correspond to
restrictions on the stream, but they are specific to the way the H.264 codec
operates, and do not have codec-independent equivalents.</t>
        <t>The <xref target="RFC6184"/> target="RFC6184" format="default"/> codec format parameters covered in the following sections
correspond to restrictions on receiver capabilities, capabilities and never indicate
sending restrictions.</t>
        <section anchor="profile-level-id-and-max-recv-level-negotiated-sub-profile" title="profile-level-id numbered="true" toc="default">
          <name>profile-level-id and max-recv-level - Negotiated Sub-Profile"> Subprofile</name>
          <t>These parameters include a “level” "level" indicator, which acts as an index
into Table A-1 of <xref target="H264"/>. target="H264" format="default"/>. This table contains a number of parameters,
several of which correspond to the restrictions defined in this
document. <xref target="RFC6184"/> target="RFC6184" format="default"/> also defines format parameters for the H.264
codec that may increase the maximum values indicated by the negotiated
level. The following sections describe the interaction between these
parameters and the restrictions defined by this document. In all cases,
the H.264 parameters being discussed are the maximum of those indicated
by <xref target="H264"></xref> target="H264" format="default"/> Table A-1 and those indicated in the corresponding “a=fmtp” "a=fmtp" line.</t>
        <section anchor="max-br-maxbr-maximum-video-bitrate" title="max-br numbered="true" toc="default">
          <name>max-br / MaxBR - Maximum Video Bitrate"> Bitrate</name>
          <t>The H.264 “MaxBR” "MaxBR" parameter (and its equivalent “max-br” "max-br" format
parameter) corresponds to the “max-bps” "max-bps" restriction
defined in this specification, by way of a conversion factor of 1000
or 1200; see <xref target="RFC6184"/> target="RFC6184" format="default"/> for details regarding which factor gets
used under differing circumstances.</t>
          <t>If an RTP sender is generating a stream using
a format defined with this format parameter, and the sending restrictions
defined via “a=rid” "a=rid" include a “max-fps” "max-fps" parameter, then the sent stream
will conform to the smaller of the two values  -- that is:</t>


  min(rid_max_br, h264_MaxBR * conversion_factor)
        <section anchor="max-fs-maxfs-maximum-framesize-in-h264-macroblocks" title="max-fs numbered="true" toc="default">
          <name>max-fs / MaxFS - Maximum Framesize, Frame Size, in H.264 Macroblocks"> Macroblocks</name>
          <t>The H.264 “MaxFs” "MaxFs" parameter (and its equivalent “max-fs” "max-fs"
format parameter) corresponds roughly to the “max-fs” "max-fs" restriction
defined in this document, by way of a conversion factor of 256
(the number of pixels per macroblock).</t>
          <t>If an RTP sender is generating a stream using
a format defined with this format parameter, and the sending restrictions
defined via “a=rid” "a=rid" include a “max-fs” "max-fs" parameter, then the sent stream
will conform to the smaller of the two values  -- that is:</t>

  min(rid_max_fs, h264_MaxFs * 256)
        <section anchor="sec-h264_max_mbps" title="max-mbps numbered="true" toc="default">
          <name>max-mbps / MaxMBPS - Maximum Macroblock Processing Rate"> Rate</name>
          <t>The H.264 “MaxMBPS” "MaxMBPS" parameter (and its equivalent “max-mbps” "max-mbps"
format parameter) corresponds roughly to the “max-pps” "max-pps" restriction
defined in this document, by way of a conversion factor of 256
(the number of pixels per macroblock).</t>
          <t>If an RTP sender is generating a stream using
a format defined with this format parameter, and the sending restrictions
defined via “a=rid” "a=rid" include a “max-pps” "max-pps" parameter, then the sent stream
will conform to the smaller of the two values  -- that is:</t>

  min(rid_max_pps, h264_MaxMBPS * 256)
        <section anchor="max-smbps-maximum-decoded-picture-buffer" title="max-smbps numbered="true" toc="default">
          <name>max-smbps - Maximum Decoded Picture Buffer"> Buffer</name>
          <t>The H.264 “max-smbps” "max-smbps" format parameter operates the same way as the
"max-mbps" format parameter, under the hypothetical assumption that all
macroblocks are static macroblocks. It is handled by applying the
conversion factor described in Section 8.1 of <xref target="RFC6184"/>, target="RFC6184" format="default"/>, and the
result of this conversion is applied as described in
<xref target="sec-h264_max_mbps"/>.</t> target="sec-h264_max_mbps" format="default"/>.</t>
      <section anchor="redundancy-formats-and-payload-type-restrictions" title="Redundancy numbered="true" toc="default">
        <name>Redundancy Formats and Payload Type Restrictions"> Restrictions</name>
        <t><xref target="sec-rid_attribute"/> target="sec-rid_attribute" format="default"/> specifies that redundancy formats using redundancy RTP streams bind
the redundancy RTP stream to the source RTP stream with either the
RepairedRtpStreamId SDES item, item or other mechanisms.  However, there exist
redundancy RTP payload formats that result in the redundancy being included in
the source RTP stream. An example of this is “RTP "RTP Payload for Redundant Audio
Data" <xref target="RFC2198"/>, target="RFC2198" format="default"/>, which encapsulates one source stream with one or more
redundancy streams in the same RTP payload. Formats defining the source and
redundancy encodings as regular RTP payload types require some consideration
for how the “a=rid” "a=rid" restrictions are defined. The “a=rid” "a=rid" line “pt=” "pt=" parameter
can be used to indicate whether the redundancy RTP payload type and/or the
individual source RTP payload type(s) are part of the restriction.</t>
        <t>Example (SDP Excerpt):</t>

<figure><artwork><![CDATA[ excerpt):</t>
        <sourcecode type="sdp">
   m=audio 49200 RTP/AVP 97 98 99 100 101 102
   a=rtpmap:97 G711/8000
   a=rtpmap:98 LPC/8000
   a=rtpmap:99 OPUS/48000/1
   a=rtpmap:100 RED/8000/1
   a=rtpmap:101 CN/8000
   a=rtpmap:102 telephone-event/8000
   a=fmtp:99 useinbandfec=1; usedtx=0
   a=fmtp:100 97/98
   a=fmtp:102 0-15
   a=rid:5 send pt=99,102;max-br=64000
   a=rid:6 send pt=100,97,101,102


        <t>The RID with ID=6 restricts the payload types for this RID to 100
        (the redundancy format), 97 (G.711), 101 (Comfort Noise) Noise), and 102 (DTMF
        (dual-tone multi-frequency (DTMF) tones). This means that RID 6 can
        either contain the RED Redundant Audio Data (RED) format, encapsulating
        encodings of the source media stream using payload type 97 and 98, 97
        without RED encapsulation, Comfort noise, or DTMF tones.  Payload type
        98 is not included in the RID, and can thus not be sent except as
        redundancy information in RED encapsulation. If 97 were to be excluded
        from the pt parameter, it would instead mean that payload types 97 and
        98 are only allowed via RED encapsulation.</t>
    <section anchor="format-parameters-for-future-payloads" title="Format numbered="true" toc="default">
      <name>Format Parameters for Future Payloads"> Payloads</name>
      <t>Registrations of future RTP payload format specifications that define media
types that have parameters matching the RID restrictions specified in this memo
<bcp14>SHOULD</bcp14> name those parameters in a manner that matches the names of those RID
restrictions and SHOULD <bcp14>SHOULD</bcp14> explicitly state what media type media-type parameters are
restricted by what RID restrictions.</t>
    <section anchor="sec-abnf" title="Formal Grammar"> numbered="true" toc="default">
      <name>Formal Grammar</name>
      <t>This section gives a formal Augmented Backus-Naur Form (ABNF) <xref target="RFC5234"/> target="RFC5234" format="default"/>
grammar, with the case-sensitive extensions described in <xref target="RFC7405"/>, target="RFC7405" format="default"/>, for each
of the new media and “a=rid” "a=rid" attributes defined in this document.</t>


      <sourcecode type="abnf"><![CDATA[
rid-syntax        = %s"a=rid:" rid-id SP rid-dir
                    [ rid-pt-param-list / rid-param-list ]

rid-id            = 1*(alpha-numeric / "-" / "_")

alpha-numeric     = < as defined in {{RFC4566}} [RFC4566] >

rid-dir           = %s"send" / %s"recv"

rid-pt-param-list = SP rid-fmt-list *(";" rid-param)

rid-param-list    = SP rid-param *(";" rid-param)

rid-fmt-list      = %s"pt=" fmt *( "," fmt )

fmt               = < as defined in {{RFC4566}} [RFC4566] >

rid-param         = rid-width-param
                    / rid-height-param
                    / rid-fps-param
                    / rid-fs-param
                    / rid-br-param
                    / rid-pps-param
                    / rid-bpp-param
                    / rid-depend-param
                    / rid-param-other

rid-width-param   = %s"max-width" [ "=" int-param-val ]

rid-height-param  = %s"max-height" [ "=" int-param-val ]

rid-fps-param     = %s"max-fps" [ "=" int-param-val ]

rid-fs-param      = %s"max-fs" [ "=" int-param-val ]

rid-br-param      = %s"max-br" [ "=" int-param-val ]

rid-pps-param     = %s"max-pps" [ "=" int-param-val ]

rid-bpp-param     = %s"max-bpp" [ "=" float-param-val ]

rid-depend-param  = %s"depend=" rid-list

rid-param-other   = 1*(alpha-numeric / "-") [ "=" param-val ]

rid-list          = rid-id *( "," rid-id )

int-param-val     = 1*DIGIT

float-param-val   = 1*DIGIT "." 1*DIGIT

param-val         = *(%0x20-3A / 0x3C-7E)
                    ; Any printable character except semicolon

<!--[rfced] "param-val" (above) has been updated per an email
from the author (1 Mar 2019) as follows. However, when parsing
the ABNF, the new line gives an error (Illegal character '%').

Are any changes necessary? Perhaps it should be as follows?

ORIGINAL: param-val         = *( %x20-58 / %x60-7E )
Per Adam: param-val         = *(%0x20-3A / 0x3C-7E)
PERHAPS:  param-val         = *(%x20-3A / %x3C-7E)

Subject: Fwd: Typo in BNF at

> I'm implementing simulcast and found a typo in rid-15 BNF.
> https://tools.ietf.org/html/draft-ietf-mmusic-rid-15#section-10
>    param-val         = *( %x20-58 / %x60-7E )
>                        ; Any printable character except semicolon

> semicolon is 59 in decimal, 0x3B in Hex
> so, it seems
> param-val = *(%0x20-3A / 0x3C-7E)
    <section anchor="sdp-examples" title="SDP Examples"> numbered="true" toc="default">
      <name>SDP Examples</name>
      <t>Note: see See <xref target="I-D.ietf-mmusic-sdp-simulcast"/> target="RFC8853" format="default"/> for examples of RID used
in simulcast scenarios.</t>
      <section anchor="many-bundled-streams-using-many-codecs" title="Many numbered="true" toc="default">
        <name>Many Bundled Streams using Using Many Codecs"> Codecs</name>
        <t>In this scenario, the offerer supports the Opus, G.722, G.711 G.711, and DTMF audio
codecs and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP) (SCBP/SCHP), and
H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send
1 and receive 7 video streams) by offering 7 video media sections (1 sendrecv
at max resolution and 6 recvonly at smaller resolutions), all bundled on the
same port, using 3 different resolutions.  The resolutions include:</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>1 receive stream of 720p resolution is offered for the active speaker.</t>
  <t>2 speaker.</li>
          <li>2 receive streams of 360p resolution are offered for the prior 2 active
          <li>4 receive streams of 180p resolution are offered for others in the call.</t>
</list></t> call.</li>
        <t>NOTE: The SDP given below skips a few lines to keep the example short and
focused, as indicated by either the “…” "..." or the comments inserted.</t>
        <t>The offer for this scenario is shown below.</t>


        <sourcecode type="sdp">
m=audio 10000 RTP/SAVPF 96 9 8 0 123
a=rtpmap:96 OPUS/48000
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:123 telephone-event/8000
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtpmap:98 VP8/90000
a=fmtp:98 max-fs=3600; max-fr=30
a=rtpmap:99 VP9/90000
a=fmtp:99 max-fs=3600; max-fr=30
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42401f; packetization-mode=0
a=rtpmap:101 H264/90000
a=fmtp:101 profile-level-id=42401f; packetization-mode=1
a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=640c1f; packetization-mode=0
a=rtpmap:103 H264/90000
a=fmtp:103 profile-level-id=640c1f; packetization-mode=1
a=rtpmap:104 H264-SVC/90000
a=fmtp:104 profile-level-id=530c1f
a=rtpmap:105 H264-SVC/90000
a=fmtp:105 profile-level-id=560c1f
a=rtpmap:106 H265/90000
a=fmtp:106 profile-id=1; level-id=93
a=rtpmap:107 H265/90000
a=fmtp:107 profile-id=2; level-id=93
a=mid:v1 (max resolution)
a=rid:1 send max-width=1280;max-height=720;max-fps=30
a=rid:2 recv max-width=1280;max-height=720;max-fps=30
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above...
a=mid:v2 (medium resolution)
a=rid:3 recv max-width=640;max-height=360;max-fps=15
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above...
a=mid:v3 (medium resolution)
a=rid:3 recv max-width=640;max-height=360;max-fps=15
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above...
a=mid:v4 (small resolution)
a=rid:4 recv max-width=320;max-height=180;max-fps=15
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above...
...same rid:4 as above for mid:v5,v6,v7 (small resolution)...

      <section anchor="scalable-layers" title="Scalable Layers"> numbered="true" toc="default">
        <name>Scalable Layers</name>
        <t>Adding scalable layers to a session within a multiparty conference gives a
selective forwarding unit (SFU) further flexibility to selectively forward
packets from a source that best match the bandwidth and capabilities of
diverse receivers. Scalable encodings have dependencies between layers, unlike
independent simulcast streams. RIDs can be used to express these dependencies
using the “depend” "depend" restriction. In the example below, the highest resolution is
offered to be sent as 2 scalable temporal layers (using MRST).
Multiple RTP Streams on a Single Media Transport (MRST)).
See <xref target="I-D.ietf-mmusic-sdp-simulcast"/> target="RFC8853" format="default"/> for additional detail about simulcast usage.</t>

        <sourcecode type="sdp">
m=audio ...same as previous example ...
m=video ...same as previous example ...
...same rtpmap/fmtp as previous example ...
a=mid:v1 (max resolution)
a=rid:0 send max-width=1280;max-height=720;max-fps=15
a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0
a=rid:2 recv max-width=1280;max-height=720;max-fps=30
a=rid:5 send max-width=640;max-height=360;max-fps=15
a=rid:6 send max-width=320;max-height=180;max-fps=15
a=simulcast: send rid=0;1;5;6 recv rid=2
...same m=video sections as previous example for mid:v2-v7...

    <section anchor="sec-iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This specification updates <xref target="RFC4855"/> target="RFC4855" format="default"/>
      to give additional guidance on choice of Format Parameter (fmtp) names, names
      and on their relation to RID restrictions.</t>

      <section anchor="new-sdp-media-level-attribute" title="New numbered="true" toc="default">
        <name>New SDP Media-Level attribute"> Attribute</name>

  <t>This document defines “rid” "rid" as an SDP media-level attribute. This
  attribute must
be has been registered by IANA under “Session "Session Description Protocol
  (SDP) Parameters” Parameters" under “att-field "att-field (media level only)”.</t> only)".</t>
        <t>The “rid” "rid" attribute is used to identify the properties of an RTP
	stream with in within an RTP Session. session. Its format is defined in <xref target="sec-abnf"/>.</t>
	target="sec-abnf" format="default"/>.</t>
        <t>The formal registration information for this attribute follows.</t>


	<dl newline="true">
	    Contact name, email address, and telephone number
IETF MMUSIC Working Group
+1 510 492 4080
	    Attribute name (as it will appear in SDP)
	    Long-form attribute name in English
	    Restriction Identifier
	    Type of attribute (session level, media level, or both)
	    Media Level
	    Whether the attribute value is subject to the charset attribute
	    The attribute is not dependent on charset.
	    A one-paragraph explanation of the purpose of the attribute
	    The "rid" SDP attribute is used to to unambiguously identify
	    the RTP Streams streams within an RTP Session session and restrict the
	    streams' payload format parameters in a codec-agnostic way
	    beyond what is provided with the regular Payload Types. payload types.
	    A specification of appropriate attribute values for this attribute
	    Valid values are defined by the ABNF in [RFCXXXXX] RFC 8851
	    Multiplexing (Mux) Category

      <section anchor="sec-iana_rid" title="Registry numbered="true" toc="default">
        <name>Registry for RID-Level Parameters"> Parameters</name>
        <t>This specification creates a new IANA registry named “rid attribute parameters” "RID Attribute Parameters"
within the SDP parameters registry.  The “a=rid” "a=rid" restrictions MUST <bcp14>MUST</bcp14> be
registered with IANA and documented under the same rules as for SDP
session-level and media-level attributes as specified in <xref target="RFC4566"/>.</t> target="RFC4566" format="default"/>.</t>
        <t>Parameters for “a=rid” "a=rid" lines that modify the nature of encoded media MUST <bcp14>MUST</bcp14> be
of the form that the result of applying the modification to the stream results
in a stream that still complies with the other parameters that affect the
media. In other words, restrictions always have to restrict the definition to be
a subset of what is otherwise allowable, and never expand it.</t>

        <t>New restriction registrations are accepted according to the “Specification
Required” "Specification
Required" policy of <xref target="RFC5226"/>. target="RFC8126" format="default"/>. The registration MUST <bcp14>MUST</bcp14> contain the RID
parameter name and a reference to the corresponding specification. The
specification itself must contain the following information (not all of which
appears in the registry):</t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>restriction name (as it will appear in SDP)</t>
  <t>an SDP)</li>
          <li>an explanation of the purpose of the restriction</t>
  <t>a restriction</li>
          <li>a specification of appropriate attribute values for this restriction</t>
  <t>an restriction</li>
          <li>an ABNF definition of the restriction</t>

<t>The restriction</li>

<!-- [rfced] We note that Section 5 does not include the pt parameter
in its list; should text about it be added to Section 5?
Rationale: It's in the IANA registry, so we've included it in
Table 1, which is preceded by this text:

   The initial set of “a=rid” "a=rid" restriction names, with definitions in
<xref target="sec-rid_level_restrictions"/>
   Section 5 of this document, is given below:</t>

  RID Parameter Name           Reference
  ------------------           ---------
  max-width                    [RFCXXXX]
  max-height                   [RFCXXXX]
  max-fps                      [RFCXXXX]
  max-fs                       [RFCXXXX]
  max-br                       [RFCXXXX]
  max-pps                      [RFCXXXX]
  max-bpp                      [RFCXXXX]
  depend                       [RFCXXXX]

]]></artwork></figure> below:

        <t>The initial set of "a=rid" restriction names, with definitions in
<xref target="sec-rid_level_restrictions" format="default"/> of this document,
	is given below:</t>

<table anchor="RID-params">
  <name>"a=rid" restriction names</name>
      <th>RID Parameter Name</th>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>
      <td>RFC 8851</td>

        <t>It is conceivable that a future document wants will want to define a RID-level
restrictions that contain string values. These extensions need to take care to
conform to the ABNF defined for rid-param-other. In particular, this means
that such extensions will need to define escaping mechanisms if they
want to allow semicolons, unprintable characters, or byte values
greater than 127 in the string.</t>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

<!-- [rfced] May "provides" be changed to"gives" here? This is to avoid
the repetition of "provide[s]" in one sentence.

   As with most SDP parameters, a failure to provide integrity
   protection over the "a=rid" attributes provides attackers a way to
   modify the session in potentially unwanted ways.

   As with most SDP parameters, a failure to provide integrity
   protection over the "a=rid" attributes gives attackers a way to
   modify the session in potentially unwanted ways.

      <t>As with most SDP parameters, a failure to provide integrity protection over
the “a=rid” "a=rid" attributes provides attackers a way to modify the session in
potentially unwanted ways. This could result in an implementation sending
greater amounts of data than a recipient wishes to receive. In general,
however, since the “a=rid” "a=rid" attribute can only restrict a stream to be a subset
of what is otherwise allowable, modification of the value cannot result in a
stream that is of higher bandwidth than would be sent to an implementation
that does not support this mechanism.</t>
      <t>The actual identifiers used for RIDs are expected to be opaque. As such, they
are not expected to contain information that would be sensitive, were it
observed by third-parties.</t>

<section anchor="acknowledgements" title="Acknowledgements">

<t>Many thanks to review from Cullen Jennings, Magnus Westerlund, and Paul
Kyzivat. Thanks to Colin Perkins for input on future payload type handing.</t> third parties.</t>

    <references title='Normative References'>
        <name>Normative References</name>
<reference anchor="I-D.ietf-avtext-rid"> anchor="RFC8852" target="https://www.rfc-editor.org/info/rfc8852">
    <title>RTP Stream Identifier Source Description (SDES)</title>
    <author initials='A' surname='Roach' fullname='Adam Roach'>
    <organization />

<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />
</author> initials="A.B." surname="Roach" fullname="Adam Roach"/>
    <author initials='P' surname='Thatcher' fullname='Peter Thatcher'>
    <organization />
</author> initials="S" surname="Nandakumar" fullname="Suhas Nandakumar"/>
    <author initials="P" surname="Thatcher" fullname="Peter Thatcher"/>
    <date month='October' day='6' year='2016' />

<abstract><t>This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items.  One, named RtpStreamId, is used for unique identification of RTP streams.  The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair.</t></abstract> month="April" year="2020"/>
    <seriesInfo name='Internet-Draft' value='draft-ietf-avtext-rid-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-avtext-rid-09.txt' /> name="DOI" value="10.17487/RFC8852"/>
    <seriesInfo name="RFC" value="8852"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <name>Informative References</name>

<!-- draft-ietf-mmusic-sdp-bundle-negotiation in C238 -->

        <reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>

            <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
            <author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author> initials="C" surname="Jennings" fullname="Cullen Jennings">
	    <date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> month="April" year="2020"/>
            <seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/> name="DOI" value="10.17487/RFC8843"/>
            <seriesInfo name='DOI' value='10.17487/RFC2119'/> name="RFC" value="8843"/>

        <!-- draft-ietf-mmusic-sdp-simulcast in C238 -->
        <reference  anchor="RFC3264" target='https://www.rfc-editor.org/info/rfc3264'> anchor="RFC8853" target="https://www.rfc-editor.org/info/rfc8853">
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <title>Using Simulcast in SDP and RTP Sessions</title>

            <author initials="B" surname="Burman" fullname="Bo Burman">
            <author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author> initials="M" surname="Westerlund" fullname="Magnus Westerlund">
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
            <author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author> initials="M" surname="Zanaty" fullname="Mo Zanaty">
            <date year='2002' month='June' />
<abstract><t>This document defines a mechanism by which two entities can make use month="April" year="2020"/>
            <seriesInfo name="DOI" value="10.17487/RFC8853"/>
            <seriesInfo name="RFC" value="8853"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2198.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4588.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5109.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6184.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6236.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7741.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8285.xml"/>

<!--[rfced] The latest version of ITU-T Recommendation H.264 is from April
2017, as compared to the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>

<reference  anchor="RFC3550" target='https://www.rfc-editor.org/info/rfc3550'>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<date year='2003' month='July' />
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>

<reference  anchor="RFC4566" target='https://www.rfc-editor.org/info/rfc4566'>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>

<reference  anchor="RFC4855" target='https://www.rfc-editor.org/info/rfc4855'>
<title>Media Type Registration of RTP Payload Formats</title>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<date year='2007' month='February' />
<abstract><t>This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names.  This is useful in a text-based format description or control protocol to identify the type of an RTP transmission.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='4855'/>
<seriesInfo name='DOI' value='10.17487/RFC4855'/>

<reference  anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>

<reference  anchor="RFC7405" target='https://www.rfc-editor.org/info/rfc7405'>
<title>Case-Sensitive String Support in ABNF</title>
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t></abstract>
<seriesInfo name='RFC' value='7405'/>
<seriesInfo name='DOI' value='10.17487/RFC7405'/>

<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>


    <references title='Informative References'>

<reference anchor="I-D.ietf-mmusic-sdp-bundle-negotiation">
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>

<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />

<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />

<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
    <organization />

<date month='December' day='14' year='2018' />

<abstract><t>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'.  The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections).  Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media.  The "m=" sections that use the BUNDLE transport form a BUNDLE group.  This specification updates RFC 3264, to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected.  This specification updates RFC 5888, to also allow an SDP 'group' attribute to contain an identification-tag that identifies a "m=" section with the port set to zero.  This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that can be used to correlate bundled RTP/RTCP packets with their appropriate "m=" section.  This specification updates RFC 7941, by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension.</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-bundle-negotiation-54' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-54.txt' />

<reference anchor="I-D.ietf-mmusic-sdp-simulcast">
<title>Using Simulcast in SDP and RTP Sessions</title>

<author initials='B' surname='Burman' fullname='Bo Burman'>
    <organization />

<author initials='M' surname='Westerlund' fullname='Magnus Westerlund'>
    <organization />

<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />

<author initials='M' surname='Zanaty' fullname='Mo Zanaty'>
    <organization />

<date month='June' day='27' year='2018' />

<abstract><t>In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams.  This is called simulcast.  This document describes how to accomplish simulcast in RTP and how to signal it in SDP.  The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source.  The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-simulcast-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-simulcast-13.txt' />

<reference anchor="I-D.ietf-payload-flexible-fec-scheme">
<title>RTP Payload Format for Flexible Forward Error Correction (FEC)</title>

<author initials='M' surname='Zanaty' fullname='Mo Zanaty'>
    <organization />

<author initials='V' surname='Singh' fullname='Varun Singh'>
    <organization />

<author initials='A' surname='Begen' fullname='Ali Begen'>
    <organization />

<author initials='G' surname='Mandyam' fullname='Giridhar Mandyam'>
    <organization />

<date month='December' day='11' year='2018' />

<abstract><t>This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams.  These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets.  RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received.  The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity.  The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications, and offer several improvements.  Due to these changes, the new payload formats are not backward compatible with earlier specifications, but endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.</t></abstract>


<seriesInfo name='Internet-Draft' value='draft-ietf-payload-flexible-fec-scheme-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-payload-flexible-fec-scheme-13.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-payload-flexible-fec-scheme-13.pdf' />

<reference  anchor="RFC2198" target='https://www.rfc-editor.org/info/rfc2198'>
<title>RTP Payload for Redundant Audio Data</title>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /></author>
<author initials='O.' surname='Hodson' fullname='O. Hodson'><organization /></author>
<author initials='V.' surname='Hardman' fullname='V. Hardman'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='J.C.' surname='Bolot' fullname='J.C. Bolot'><organization /></author>
<author initials='A.' surname='Vega-Garcia' fullname='A. Vega-Garcia'><organization /></author>
<author initials='S.' surname='Fosse-Parisis' fullname='S. Fosse-Parisis'><organization /></author>
<date year='1997' month='September' />
<abstract><t>This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='2198'/>
<seriesInfo name='DOI' value='10.17487/RFC2198'/>

<reference  anchor="RFC4588" target='https://www.rfc-editor.org/info/rfc4588'>
<title>RTP Retransmission Payload Format</title>
<author initials='J.' surname='Rey' fullname='J. Rey'><organization /></author>
<author initials='D.' surname='Leon' fullname='D. Leon'><organization /></author>
<author initials='A.' surname='Miyazaki' fullname='A. Miyazaki'><organization /></author>
<author initials='V.' surname='Varsa' fullname='V. Varsa'><organization /></author>
<author initials='R.' surname='Hakenberg' fullname='R. Hakenberg'><organization /></author>
<date year='2006' month='July' />
<abstract><t>RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds.  This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream.  It is assumed that feedback from receivers to senders is available.  In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='4588'/>
<seriesInfo name='DOI' value='10.17487/RFC4588'/>

<reference  anchor="RFC5109" target='https://www.rfc-editor.org/info/rfc5109'>
<title>RTP Payload Format for Generic Forward Error Correction</title>
<author initials='A.' surname='Li' fullname='A. Li' role='editor'><organization /></author>
<date year='2007' month='December' />
<abstract><t>This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP.  It is based on the exclusive-or (parity) operation.  The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation.  This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data.  This specification obsoletes RFC 2733 and RFC 3009.  The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='5109'/>
<seriesInfo name='DOI' value='10.17487/RFC5109'/>

<reference  anchor="RFC5226" target='https://www.rfc-editor.org/info/rfc5226'>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>

<reference  anchor="RFC6184" target='https://www.rfc-editor.org/info/rfc6184'>
<title>RTP Payload Format for H.264 Video</title>
<author initials='Y.-K.' surname='Wang' fullname='Y.-K. Wang'><organization /></author>
<author initials='R.' surname='Even' fullname='R. Even'><organization /></author>
<author initials='T.' surname='Kristensen' fullname='T. Kristensen'><organization /></author>
<author initials='R.' surname='Jesup' fullname='R. Jesup'><organization /></author>
<date year='2011' month='May' />
<abstract><t>This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload.  The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.</t><t>This memo obsoletes RFC 3984.  Changes from RFC 3984 are summarized in Section 14.  Issues on backward compatibility to RFC 3984 are discussed in Section 15.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='6184'/>
<seriesInfo name='DOI' value='10.17487/RFC6184'/>

<reference  anchor="RFC6236" target='https://www.rfc-editor.org/info/rfc6236'>
<title>Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)</title>
<author initials='I.' surname='Johansson' fullname='I. Johansson'><organization /></author>
<author initials='K.' surname='Jung' fullname='K. Jung'><organization /></author>
<date year='2011' month='May' />
<abstract><t>This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size.  A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power.  The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted.  [STANDARDS-TRACK]</t></abstract>
<seriesInfo name='RFC' value='6236'/>
<seriesInfo name='DOI' value='10.17487/RFC6236'/>

<reference  anchor="RFC7656" target='https://www.rfc-editor.org/info/rfc7656'>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources</title>
<author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></author>
<author initials='K.' surname='Gross' fullname='K. Gross'><organization /></author>
<author initials='S.' surname='Nandakumar' fullname='S. Nandakumar'><organization /></author>
<author initials='G.' surname='Salgueiro' fullname='G. Salgueiro'><organization /></author>
<author initials='B.' surname='Burman' fullname='B. Burman' role='editor'><organization /></author>
<date year='2015' month='November' />
<abstract><t>The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque.  This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.</t></abstract>
<seriesInfo name='RFC' value='7656'/>
<seriesInfo name='DOI' value='10.17487/RFC7656'/>

<reference  anchor="RFC7741" target='https://www.rfc-editor.org/info/rfc7741'>
<title>RTP Payload Format for VP8 Video</title>
<author initials='P.' surname='Westin' fullname='P. Westin'><organization /></author>
<author initials='H.' surname='Lundin' fullname='H. Lundin'><organization /></author>
<author initials='M.' surname='Glover' fullname='M. Glover'><organization /></author>
<author initials='J.' surname='Uberti' fullname='J. Uberti'><organization /></author>
<author initials='F.' surname='Galligan' fullname='F. Galligan'><organization /></author>
<date year='2016' month='March' />
<abstract><t>This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.</t></abstract>
<seriesInfo name='RFC' value='7741'/>
<seriesInfo name='DOI' value='10.17487/RFC7741'/>

<reference  anchor="RFC8285" target='https://www.rfc-editor.org/info/rfc8285'>
<title>A General Mechanism for RTP Header Extensions</title>
<author initials='D.' surname='Singer' fullname='D. Singer'><organization /></author>
<author initials='H.' surname='Desineni' fullname='H. Desineni'><organization /></author>
<author initials='R.' surname='Even' fullname='R. Even' role='editor'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol).  It provides the option cited version (February 2014). May we update to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized.  The actual extensions in use in a session are signaled in
the setup information for that session.  This document obsoletes RFC 5285.</t></abstract>
<seriesInfo name='RFC' value='8285'/>
<seriesInfo name='DOI' value='10.17487/RFC8285'/>
</reference> latest? -->
        <reference anchor="H264" target="http://www.itu.int/rec/T-REC-H.264-201304-I"> target="https://www.itu.int/rec/T-REC-H.264">
            <title>Advanced video coding for generic audiovisual services (V9)</title>
    <author >
      <organization>ITU-T Recommendation H.264</organization> services</title>
            <seriesInfo name="ITU-T Recommendation" value="H.264"/>
              <organization>International Telecommunication Union</organization>
            <date year="2014" month="February"/>
    <section anchor="acknowledgements" numbered="false" toc="default">
<!--[rfced] Please confirm the change from "handing" to "handling" here.

Thanks to Colin Perkins for input on future payload
type handing.

Thanks to Colin Perkins for input on future payload
type handling.

      <t>Many thanks to <contact fullname="Cullen Jennings"/>, <contact
      fullname="Magnus Westerlund"/>, and <contact fullname="Paul Kyzivat"/>
      for reviewing. Thanks to <contact fullname="Colin Perkins"/> for input
      on future payload type handling.</t>
    <section anchor="contributors" title="Contributors"> numbered="false" toc="default">
      <t>The following individuals have contributed significant text to this document.</t>

Peter Thatcher
Email: pthatcher@google.com

Mo Zanaty
Cisco Systems
Email: mzanaty@cisco.com

Suhas Nandakumar
Cisco Systems
Email: snandaku@cisco.com

Bo Burman
Email: bo.burman@ericsson.com

Byron Campen
Email: bcampen@mozilla.com

      <contact fullname="Peter Thatcher">

      <contact fullname="Mo Zanaty">
	<organization>Cisco Systems</organization>

      <contact fullname="Suhas Nandakumar">
	<organization>Cisco Systems</organization>

      <contact fullname="Bo Burman">

      <contact fullname="Byron Campen">

<!-- ##markdown-source: