rfc8851xml2.original.xml   rfc8851.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 --> nsus="true" docName="draft-ietf-mmusic-rid-15" indexInclude="true" ipr="trust200
902" number="8851" prepTime="2021-01-16T23:55:17" scripts="Common,Latin" sortRef
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ s="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" upd
]> ates="4855" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid-15" rel="pr
<?rfc toc="yes"?> ev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8851" rel="alternate"/>
<?rfc symrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<rfc ipr="trust200902" docName="draft-ietf-mmusic-rid-15" category="std" updates
="4855">
<front> <front>
<title abbrev="RTP Restrictions">RTP Payload Format Restrictions</title> <title abbrev="RTP Restrictions">RTP Payload Format Restrictions</title>
<seriesInfo name="RFC" value="8851" stream="IETF"/>
<author initials="A.B." surname="Roach (Editor)" fullname="Adam Roach"> <author initials="A.B." surname="Roach" fullname="Adam Roach" role="editor">
<organization>Mozilla</organization> <organization showOnFrontPage="true">Mozilla</organization>
<address> <address>
<email>adam@nostrum.com</email> <email>adam@nostrum.com</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date year="2018" month="May" day="15"/> <keyword>WebRTC</keyword>
<keyword>Multiplexing</keyword>
<abstract> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">In this specification, we define a f
<t>In this specification, we define a framework for specifying restrictions ramework for specifying restrictions
on RTP streams in the Session Description Protocol. on RTP streams in the Session Description Protocol (SDP).
This framework defines a new “rid” (“restriction identifier”) SDP attribute to u This framework defines a new "rid" ("restriction identifier") SDP attribute to
nambiguously unambiguously identify the RTP streams within an RTP session and restrict the
identify the RTP Streams within an RTP Session and restrict the streams’ payload streams' payload format parameters in a codec-agnostic way beyond what is
format parameters in a codec-agnostic way beyond what is provided with the provided with the regular payload types.</t>
regular Payload Types.</t> <t indent="0" pn="section-abstract-2">This specification updates RFC 4855
to give additional guidance on choice of
<t>This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions
Format Parameter (fmtp) names, and on their relation to the restrictions
defined by this document.</t> defined by this document.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8851" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-key-words-for-
requirements">Key Words for Requirements</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-sdp-arid-media-level-attrib">SDP "
a=rid" Media Level Attribute</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-arid-restrictions">"a=rid" Restric
tions</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-sdp-offer-answer-procedures">SDP O
ffer/Answer Procedures</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-generating-the-initial
-sdp-">Generating the Initial SDP Offer</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-answerer-processing-th
e-sdp">Answerer Processing the SDP Offer</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derived
Content="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-arid-unawa
re-answerer">"a=rid"-Unaware Answerer</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derived
Content="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-arid-aware
-answerer">"a=rid"-Aware Answerer</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-generating-the-sdp-ans
wer">Generating the SDP Answer</xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-offerer-processing-of-
the-s">Offerer Processing of the SDP Answer</xref></t>
</li>
<li pn="section-toc.1-1.6.2.5">
<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
"6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-modifying-the-session"
>Modifying the Session</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-use-with-declarative-sdp">Use with
Declarative SDP</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-interaction-with-other-tech">Inter
action with Other Techniques</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-interaction-with-vp8-f
ormat">Interaction with VP8 Format Parameters</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.1.2">
<li pn="section-toc.1-1.8.2.1.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derived
Content="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-fr-max
imum-frame-rate">max-fr - Maximum Frame Rate</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.2">
<t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derived
Content="8.1.2" format="counter" sectionFormat="of" target="section-8.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-fs-max
imum-frame-size-i">max-fs - Maximum Frame Size, in VP8 Macroblocks</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-interaction-with-h264-
forma">Interaction with H.264 Format Parameters</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.2.2">
<li pn="section-toc.1-1.8.2.2.2.1">
<t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derived
Content="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-profile-le
vel-id-and-max-re">profile-level-id and max-recv-level - Negotiated Subprofile</
xref></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.2.2.1"><xref derived
Content="8.2.2" format="counter" sectionFormat="of" target="section-8.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-br-max
br-maximum-video-">max-br / MaxBR - Maximum Video Bitrate</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.3">
<t indent="0" pn="section-toc.1-1.8.2.2.2.3.1"><xref derived
Content="8.2.3" format="counter" sectionFormat="of" target="section-8.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-fs-max
fs-maximum-frame-">max-fs / MaxFS - Maximum Frame Size, in H.264 Macroblocks</xr
ef></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.4">
<t indent="0" pn="section-toc.1-1.8.2.2.2.4.1"><xref derived
Content="8.2.4" format="counter" sectionFormat="of" target="section-8.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-mbps-m
axmbps-maximum-ma">max-mbps / MaxMBPS - Maximum Macroblock Processing Rate</xref
></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.5">
<t indent="0" pn="section-toc.1-1.8.2.2.2.5.1"><xref derived
Content="8.2.5" format="counter" sectionFormat="of" target="section-8.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-max-smbps-
maximum-decoded-p">max-smbps - Maximum Decoded Picture Buffer</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-redundancy-formats-and
-payl">Redundancy Formats and Payload Type Restrictions</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-format-parameters-for-futur">Forma
t Parameters for Future Payloads</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-formal-grammar">Formal Grammar</
xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-sdp-examples">SDP Examples</xref
></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-many-bundled-stream
s-using-">Many Bundled Streams Using Many Codecs</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-scalable-layers">Sc
alable Layers</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-new-sdp-media-level
-attribu">New SDP Media-Level Attribute</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-registry-for-rid-le
vel-para">Registry for RID-Level Parameters</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.14.2">
<li pn="section-toc.1-1.14.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
<section anchor="terminology" title="Terminology"> se" pn="section-1">
<name slugifiedName="name-terminology">Terminology</name>
<t>The terms “Source RTP Stream”, “Endpoint”, “RTP Session”, and “RTP Stream” <t indent="0" pn="section-1-1">The terms "source RTP stream", "endpoint",
are used as defined in <xref target="RFC7656"/>.</t> "RTP session", and "RTP stream"
are used as defined in <xref target="RFC7656" format="default" sectionFormat="of
<t><xref target="RFC4566"/> and <xref target="RFC3264"/> terminology is also use " derivedContent="RFC7656"/>.</t>
d where appropriate.</t> <t indent="0" pn="section-1-2"><xref target="RFC4566" format="default" sec
tionFormat="of" derivedContent="RFC4566"/> and <xref target="RFC3264" format="de
</section> fault" sectionFormat="of" derivedContent="RFC3264"/> terminology is also used wh
<section anchor="sec-intro" title="Introduction"> ere appropriate.</t>
</section>
<t>The Payload Type (PT) field in RTP provides a mapping between the RTP payload <section anchor="sec-intro" numbered="true" toc="include" removeInRFC="false
format and the associated SDP media description. The SDP rtpmap and/or fmtp " pn="section-2">
attributes are used, for a given PT, to describe the properties of <name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-2-1">The payload type (PT) field in RTP provides
a mapping between the RTP payload
format and the associated SDP media description. For a given PT, the SDP
rtpmap and/or fmtp attributes are used to describe the properties of
the media that is carried in the RTP payload.</t> the media that is carried in the RTP payload.</t>
<t indent="0" pn="section-2-2">Recent advances in standards have given ris
<t>Recent advances in standards have given rise to rich e to rich
multimedia applications requiring support for multiple RTP Streams within an multimedia applications requiring support for either multiple RTP streams within
RTP session <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, an
<xref target="I-D.ietf-mmusic-sdp-simulcast"/> or having to support a large numb RTP session <xref target="RFC8843" format="default" sectionFormat="of" derivedCo
er of codecs. ntent="RFC8843"/> <xref target="RFC8853" format="default" sectionFormat="of" der
ivedContent="RFC8853"/> or a
large number of codecs.
These demands have unearthed challenges inherent with:</t> These demands have unearthed challenges inherent with:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3
<t><list style="symbols"> ">
<t>The restricted RTP PT space in specifying the various payload <li pn="section-2-3.1">The restricted RTP PT space in specifying the var
configurations,</t> ious payload
<t>The codec-specific constructs for the payload formats in SDP,</t> configurations</li>
<t>Missing or underspecified payload format parameters,</t> <li pn="section-2-3.2">The codec-specific constructs for the payload for
<t>Overloading of PTs to indicate not just codec configurations, but mats in SDP</li>
individual streams within an RTP session.</t> <li pn="section-2-3.3">Missing or underspecified payload format paramete
</list></t> rs</li>
<li pn="section-2-3.4">Overloading of PTs to indicate not just codec con
<t>To expand on these points: <xref target="RFC3550"/> assigns 7 bits for the PT figurations, but
in the RTP individual streams within an RTP session</li>
header. However, the assignment of static mapping of RTP payload type numbers </ul>
to payload formats and multiplexing of RTP with other protocols (such as RTCP) <t indent="0" pn="section-2-4">To expand on these points: <xref target="RF
could result in a limited number of payload type numbers available for C3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>
application usage. In scenarios where the number of possible RTP payload assigns 7 bits for the PT in the RTP header. However, the assignment of
configurations exceeds the available PT space within an RTP Session, there is static mapping of RTP payload type numbers to payload formats and
a need for a way to represent the additional restrictions on payload configurati multiplexing of RTP with other protocols (such as the RTP Control
ons Protocol (RTCP)) could result in a limited number of payload type
and to effectively map an RTP Stream to its corresponding restrictions. This numbers available for application usage. In scenarios where the number
issue is exacerbated by the increase in techniques – such as simulcast and of possible RTP payload configurations exceeds the available PT space
layered codecs – which introduce additional streams into RTP Sessions.</t> within an RTP session, there is a need for a way to represent the
additional restrictions on payload configurations and effectively map an
<t>This specification defines a new SDP framework for restricting Source RTP RTP stream to its corresponding restrictions. This issue is exacerbated
Streams (Section 2.1.10 <xref target="RFC7656"/>), along with by the increase in techniques -- such as simulcast and layered codecs --
that introduce additional streams into RTP sessions.</t>
<t indent="0" pn="section-2-5">This specification defines a new SDP framew
ork for restricting source RTP
streams (Section 2.1.10 of <xref target="RFC7656" format="default" sectionFormat
="of" derivedContent="RFC7656"/>), along with
the SDP attributes to restrict payload formats in a codec-agnostic way. 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 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” the media format parameters are specified in SDP today, via the "a=fmtp"
attribute.</t> attribute.</t>
<t indent="0" pn="section-2-6">The additional restrictions on individual s
<t>The additional restrictions on individual streams are indicated with a new treams are indicated with a new
“a=rid” (“restriction identifier”) SDP attribute. Note that the restrictions com "a=rid" ("restriction identifier") SDP attribute. Note that the restrictions com
municated via this municated via this
attribute only serve to further restrict the parameters that are established 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> on a PT format. They do not relax any restrictions imposed by other mechanisms.< /t>
<t indent="0" pn="section-2-7">This specification makes use of the RTP Str
<t>This specification makes use of the RTP Stream Identifier Source Description eam Identifier Source Description
(SDES) RTCP item defined in <xref target="I-D.ietf-avtext-rid"/> to provide cor (SDES) RTCP item defined in <xref target="RFC8852" format="default" sectionForma
relation t="of" derivedContent="RFC8852"/> to provide correlation
between the RTP Packets and their format specification in the SDP.</t> between the RTP packets and their format specification in the SDP.</t>
<t indent="0" pn="section-2-8">As described in <xref target="sec-rid_unawa
<t>As described in <xref target="sec-rid_unaware"/>, this mechanism achieves bac re" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>, this m
kwards echanism achieves backwards
compatibility via the normal SDP processing rules, which require unknown a= compatibility via the normal SDP processing rules, which require unknown "a="
lines to be ignored. This means that implementations need to be prepared lines to be ignored. This means that implementations need to be prepared
to handle successful offers and answers from other implementations that to handle successful offers and answers from other implementations that
neither indicate nor honor the restrictions requested by this mechanism.</t> neither indicate nor honor the restrictions requested by this mechanism.</t>
<t indent="0" pn="section-2-9">Further, as described in <xref target="sec-
<t>Further, as described in <xref target="sec-sdp_o_a"/> and its subsections, th sdp_o_a" format="default" sectionFormat="of" derivedContent="Section 6"/> and it
is mechanism s subsections, this mechanism
achieves extensibility by: (a) having offerers include all supported achieves extensibility by: (a) having offerers include all supported
restrictions in their offer, and (b) having answerers ignore “a=rid” lines that restrictions in their offer, and (b) having answerers ignore "a=rid" lines that
specify unknown restrictions.</t> specify unknown restrictions.</t>
</section>
</section> <section anchor="key-words-for-requirements" numbered="true" toc="include" r
<section anchor="key-words-for-requirements" title="Key Words for Requirements"> emoveInRFC="false" pn="section-3">
<name slugifiedName="name-key-words-for-requirements">Key Words for Requir
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL ements</name>
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, <t indent="0" pn="section-3-1">
“MAY”, and “OPTIONAL” in this document are to be interpreted as The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
only when, they D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
appear in all capitals, as shown here.</t> OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
<section anchor="sec-rid_attribute" title="SDP “a=rid” Media Level Attribute"> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
<t>This section defines new SDP media-level attribute <xref target="RFC4566"/>, mat="of" derivedContent="RFC8174"/>
“a=rid”, when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="sec-rid_attribute" numbered="true" toc="include" removeInRF
C="false" pn="section-4">
<name slugifiedName="name-sdp-arid-media-level-attrib">SDP "a=rid" Media L
evel Attribute</name>
<t indent="0" pn="section-4-1">This section defines new SDP media-level at
tribute <xref target="RFC4566" format="default" sectionFormat="of" derivedConten
t="RFC4566"/>, "a=rid",
used to communicate a set of restrictions to be used to communicate a set of restrictions to be
applied to an identified RTP Stream. Roughly speaking, this attribute takes the applied to an identified RTP stream. Roughly speaking, this attribute takes
following form (see <xref target="sec-abnf"/> for a formal definition).</t> the following form (see <xref target="sec-abnf" format="default" sectionFormat="
of" derivedContent="Section 10"/> for a
<figure><artwork><![CDATA[ formal definition):</t>
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>... <sourcecode type="sdp" markers="false" pn="section-4-2">
a=rid:&lt;rid-id&gt; &lt;direction&gt; [pt=&lt;fmt-list&gt;;]&lt;restriction&gt;
]]></artwork></figure> =&lt;value&gt;...
</sourcecode>
<t>An “a=rid” SDP media attribute specifies restrictions defining a unique <t indent="0" pn="section-4-3">An "a=rid" SDP media attribute specifies re
RTP payload configuration identified via the “rid-id” field. This strictions defining a unique
value binds the restriction to the RTP Stream identified by its RTP RTP payload configuration identified via the "rid-id" field. This
Stream Identifier Source Description (SDES) item <xref target="I-D.ietf-avtext-r value binds the restriction to the RTP stream identified by its RTP
id"/>. Stream Identifier Source Description (SDES) item <xref target="RFC8852" format="
Implementations that use the “a=rid” parameter in SDP MUST support default" sectionFormat="of" derivedContent="RFC8852"/>.
the RtpStreamId SDES item described in <xref target="I-D.ietf-avtext-rid"/>. Suc Implementations that use the "a=rid" parameter in SDP <bcp14>MUST</bcp14> suppor
h t
implementations MUST send that SDES item for all streams in an SDP media descrip the RtpStreamId SDES item described in <xref target="RFC8852" format="default" s
tion ectionFormat="of" derivedContent="RFC8852"/>. Such
(“m=”) that have “a=rid” lines remaining after applying the rules in implementations <bcp14>MUST</bcp14> send that SDES item for all streams in an SD
<xref target="sec-sdp_o_a"/> and its subsections.</t> P media description
("m=") that have "a=rid" lines remaining after applying the rules in
<t>Implementations that use the “a=rid” parameter in SDP and that <xref target="sec-sdp_o_a" format="default" sectionFormat="of" derivedContent="S
make use of redundancy RTP streams <xref target="RFC7656"/>, e.g. RTP RTX ection 6"/> and its subsections.</t>
<xref target="RFC4588"/> or FEC <xref target="RFC5109"/>, <t indent="0" pn="section-4-4">Implementations that use the "a=rid" parame
for any of the source RTP streams that have “a=rid” lines remaining ter in SDP and make use of
after applying the rules in <xref target="sec-sdp_o_a"/> and its subsections, MU redundancy RTP streams <xref target="RFC7656" format="default" sectionFormat="of
ST " derivedContent="RFC7656"/> -- e.g., RTP RTX
<xref target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC45
88"/> or Forward Error Correction (FEC) <xref target="RFC5109" format="default"
sectionFormat="of" derivedContent="RFC5109"/> -- for any of the
source RTP streams that have "a=rid" lines remaining
after applying the rules in <xref target="sec-sdp_o_a" format="default" sectionF
ormat="of" derivedContent="Section 6"/> and its subsections <bcp14>MUST</bcp14>
support the RepairedRtpStreamId SDES item described in support the RepairedRtpStreamId SDES item described in
<xref target="I-D.ietf-avtext-rid"/> for those redundancy RTP streams. RepairedR <xref target="RFC8852" format="default" sectionFormat="of" derivedContent="RFC88
tpStreamId 52"/> for those redundancy RTP streams. RepairedRtpStreamId
MUST be used for redundancy RTP streams to which it can be applied. <bcp14>MUST</bcp14> be used for redundancy RTP streams to which it can be applie
d.
Use of RepairedRtpStreamId is not applicable for Use of RepairedRtpStreamId is not applicable for
redundancy formats that directly associate RTP streams redundancy formats that directly associate RTP streams
through shared SSRCs (for example <xref target="I-D.ietf-payload-flexible-fec-sc heme"/>) through shared synchronization sources (SSRCs) -- for example, <xref target="RFC 8627" format="default" sectionFormat="of" derivedContent="RFC8627"/> --
or other cases that RepairedRtpStreamId cannot support, such as referencing or other cases that RepairedRtpStreamId cannot support, such as referencing
multiple source streams.</t> multiple source streams.</t>
<t indent="0" pn="section-4-5">RepairedRtpStreamId is used to provide the
<t>RepairedRtpStreamId is used to provide the binding between the redundancy RTP binding between the redundancy RTP
stream and its source RTP stream, by setting the RepairedRtpStreamId value for stream and its source RTP stream by setting the RepairedRtpStreamId value for
the redundancy RTP stream to the RtpStreamId value of the source RTP stream. the redundancy RTP stream to the RtpStreamId value of the source RTP stream.
The redundancy RTP stream MAY (but need not) have an “a=rid” line of its own, The redundancy RTP stream <bcp14>MAY</bcp14> (but need not) have an "a=rid" line of its own,
in which case the RtpStreamId SDES item value will be different from the in which case the RtpStreamId SDES item value will be different from the
corresponding source RTP stream.</t> corresponding source RTP stream.</t>
<t indent="0" pn="section-4-6">It is important to note that this indirecti
<t>It is important to note that this indirection may result in the temporary on may result in the temporary
inability to correctly associate source and redundancy data when the SSRC inability to correctly associate source and redundancy data when the SSRC
associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed
during the RTP session. This can be avoided if all RTP packets, source and during the RTP session. This can be avoided if all RTP packets, source and
repair, after the change include their RtpStreamId or RepairedRtpStreamId, repair, include their RtpStreamId or RepairedRtpStreamId,
respectively. To maximize the probability of reception and utility of respectively, after the change. To maximize the probability of reception and ut
ility of
redundancy information after such a change, all the source packets referenced redundancy information after such a change, all the source packets referenced
by the first several repair packets SHOULD include such information. It is by the first several repair packets <bcp14>SHOULD</bcp14> include such informati
RECOMMENDED that the number of such packets is large enough to give a high on. It is
probability of actual updated association. Section 4.1.1 of <xref target="RFC828 <bcp14>RECOMMENDED</bcp14> that the number of such packets is large enough to gi
5"/> ve a high
probability of actual updated association. Section 4.1.1 of <xref target="RFC828
5" format="default" sectionFormat="of" derivedContent="RFC8285"/>
provides relevant guidance for RTP header extension transmission provides relevant guidance for RTP header extension transmission
considerations. Alternatively, to avoid this issue, redundancy mechanisms considerations. Alternatively, to avoid this issue, redundancy mechanisms
that directly reference its source data may be used, such as that directly reference its source data may be used, such as
<xref target="I-D.ietf-payload-flexible-fec-scheme"/>.</t> <xref target="RFC8627" format="default" sectionFormat="of" derivedContent="RFC86
27"/>.</t>
<t>The “direction” field identifies the direction of the RTP Stream packets to <t indent="0" pn="section-4-7">The "direction" field identifies the direct
which the indicated restrictions are applied. It may be either “send” or ion of the RTP stream packets to
“recv”. Note that these restriction directions are expressed independently of which the indicated restrictions are applied. It may be either "send" or
any “inactive”, “sendonly”, “recvonly”, or “sendrecv” attributes associated "recv". Note that these restriction directions are expressed independently of
with the media section. It is, for example, valid to indicate “recv” any "inactive", "sendonly", "recvonly", or "sendrecv" attributes associated
restrictions on a “sendonly” stream; those restrictions would apply if, at a with the media section. It is, for example, valid to indicate "recv"
future point in time, the stream were changed to “sendrecv” or “recvonly”.</t> restrictions on a "sendonly" stream; those restrictions would apply if, at a
future point in time, the stream were changed to "sendrecv" or "recvonly".</t>
<t>The optional “pt=&lt;fmt-list&gt;” lists one or more PT values that can be us <t indent="0" pn="section-4-8">The optional "pt=&lt;fmt-list&gt;" lists on
ed e or more PT values that can be used
in the associated RTP Stream. If the “a=rid” attribute contains in the associated RTP stream. If the "a=rid" attribute contains
no “pt”, then any of the PT values specified in the corresponding “m=” no "pt", then any of the PT values specified in the corresponding "m="
line may be used.</t> line may be used.</t>
<t indent="0" pn="section-4-9">The list of zero or more codec-agnostic res
<t>The list of zero or more codec-agnostic restrictions trictions
(<xref target="sec-rid_level_restrictions"/>) describe the restrictions that the (<xref target="sec-rid_level_restrictions" format="default" sectionFormat="of" d
corresponding RTP Stream will conform to.</t> erivedContent="Section 5"/>) describes the restrictions that the
corresponding RTP stream will conform to.</t>
<t>This framework MAY be used in combination with the “a=fmtp” SDP attribute <t indent="0" pn="section-4-10">This framework <bcp14>MAY</bcp14> be used
for describing the media format parameters for a given RTP Payload Type. In in combination with the "a=fmtp" SDP attribute
such scenarios, the “a=rid” restrictions (<xref target="sec-rid_level_restrictio for describing the media format parameters for a given RTP payload type. In
ns"/>) such scenarios, the "a=rid" restrictions (<xref target="sec-rid_level_restrictio
further restrict the equivalent “a=fmtp” attributes.</t> ns" format="default" sectionFormat="of" derivedContent="Section 5"/>)
further restrict the equivalent "a=fmtp" attributes.</t>
<t>A given SDP media description MAY have zero or more “a=rid” lines describing <t indent="0" pn="section-4-11">A given SDP media description <bcp14>MAY</
various possible RTP payload configurations. A given “rid-id” MUST NOT bcp14> have zero or more "a=rid" lines describing
be repeated in a given media description (“m=” section).</t> various possible RTP payload configurations. A given "rid-id" <bcp14>MUST NOT</b
cp14>
<t>The “a=rid” media attribute MAY be used for any RTP-based media transport. I be repeated in a given media description ("m=" section).</t>
t <t indent="0" pn="section-4-12">The "a=rid" media attribute <bcp14>MAY</bc
p14> be used for any RTP-based media transport. It
is not defined for other transports, although other documents may extend its is not defined for other transports, although other documents may extend its
semantics for such transports.</t> semantics for such transports.</t>
<t indent="0" pn="section-4-13">Though the restrictions specified by the "
<t>Though the restrictions specified by the “rid” restrictions follow a rid" restrictions follow a
syntax similar to session-level and media-level parameters, they are defined syntax similar to session-level and media-level parameters, they are defined
independently. All “rid” restrictions MUST be registered with IANA, using independently. All "rid" restrictions <bcp14>MUST</bcp14> be registered with IA
the registry defined in <xref target="sec-iana"/>.</t> NA, using
the registry defined in <xref target="sec-iana" format="default" sectionFormat="
<t><xref target="sec-abnf"/> gives a formal Augmented Backus-Naur Form (ABNF) <x of" derivedContent="Section 12"/>.</t>
ref target="RFC5234"/> <t indent="0" pn="section-4-14"><xref target="sec-abnf" format="default" s
grammar for the “rid” attribute. The “a=rid” media attribute is not dependent ectionFormat="of" derivedContent="Section 10"/> gives a formal Augmented Backus-
Naur Form (ABNF) <xref target="RFC5234" format="default" sectionFormat="of" deri
vedContent="RFC5234"/>
grammar for the "rid" attribute. The "a=rid" media attribute is not dependent
on charset.</t> on charset.</t>
</section>
</section> <section anchor="sec-rid_level_restrictions" numbered="true" toc="include" r
<section anchor="sec-rid_level_restrictions" title="“a=rid” restrictions"> emoveInRFC="false" pn="section-5">
<name slugifiedName="name-arid-restrictions">"a=rid" Restrictions</name>
<t>This section defines the “a=rid” restrictions that can be used to restrict <t indent="0" pn="section-5-1">
the RTP payload encoding format in a codec-agnostic way.</t> This section defines the "a=rid" restrictions that can be used to restrict the
RTP payload encoding format in a codec-agnostic way. Please also see
<t>The following restrictions are intended to apply to video codecs in a the preceding section for a description of how the "pt" parameter is used.
</t>
<t indent="0" pn="section-5-2">The following restrictions are intended to
apply to video codecs in a
codec-independent fashion.</t> codec-independent fashion.</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-3
<t><list style="symbols"> ">
<t>max-width, for spatial resolution in pixels. In the case that stream <li pn="section-5-3.1">
orientation signaling is used to modify the intended display orientation, <strong>max-width</strong>, for spatial resolution in pixels. In the
this attribute refers to the width of the stream when a rotation of zero case that
degrees is encoded.</t> stream-orientation signaling is used to modify the intended display
<t>max-height, for spatial resolution in pixels. In the case that stream orientation, this attribute refers to the width of the stream when a
orientation signaling is used to modify the intended display orientation, rotation of zero degrees is encoded.</li>
<li pn="section-5-3.2">
<strong>max-height</strong>, for spatial resolution in pixels. In the
case that
stream-orientation signaling is used to modify the intended display
orientation,
this attribute refers to the height of the stream when a rotation of zero this attribute refers to the height of the stream when a rotation of zero
degrees is encoded.</t> degrees is encoded.</li>
<t>max-fps, for frame rate in frames per second. For encoders that do not use <li pn="section-5-3.3">
a fixed framerate for encoding, this value is used to restrict the minimum <strong>max-fps</strong>, for frame rate in frames per second. For en
coders that do not use
a fixed frame rate for encoding, this value is used to restrict the minimum
amount of time between frames: the time between any two consecutive frames amount of time between frames: the time between any two consecutive frames
SHOULD NOT be less than 1/max-fps seconds.</t> <bcp14>SHOULD NOT</bcp14> be less than 1/max-fps seconds.</li>
<t>max-fs, for frame size in pixels per frame. This is the product of frame <li pn="section-5-3.4">
width and frame height, in pixels, for rectangular frames.</t> <strong>max-fs</strong>, for frame size in pixels per frame. This is t
<t>max-br, for bit rate in bits per second. The restriction applies to the he product of frame
media payload only, and does not include overhead introduced by other layers width and frame height, in pixels, for rectangular frames.</li>
<li pn="section-5-3.5">
<strong>max-br</strong>, for bitrate in bits per second. The restrict
ion applies to the
media payload only and does not include overhead introduced by other layers
(e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this (e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this
limit are left up to the implementation, and instantaneous excursions limit are left up to the implementation, and instantaneous excursions
outside the limit are permissible. For any given one-second sliding window, 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 however, the total number of bits in the payload portion of RTP <bcp14>SHOULD NO
exceed the value specified in “max-br.”</t> T</bcp14>
<t>max-pps, for pixel rate in pixels per second. This value SHOULD be handled exceed the value specified in "max-br."</li>
<li pn="section-5-3.6">
<strong>max-pps</strong>, for pixel rate in pixels per second. This v
alue <bcp14>SHOULD</bcp14> be handled
identically to max-fps, after performing the following conversion: max-fps = identically to max-fps, after performing the following conversion: max-fps =
max-pps / (width * height). If the stream resolution changes, this value is max-pps / (width * height). If the stream resolution changes, this value is
recalculated. Due to this recalculation, excursions outside the specified recalculated. Due to this recalculation, excursions outside the specified
maximum are possible near resolution change boundaries.</t> maximum are possible near resolution-change boundaries.</li>
<t>max-bpp, for maximum number of bits per pixel, calculated as an average of <li pn="section-5-3.7">
<strong>max-bpp</strong>, for maximum number of bits per pixel, calcul
ated as an average of
all samples of any given coded picture. This is expressed as 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 a floating point value, with an allowed range of 0.0001 to 48.0. These
values MUST NOT be encoded with more than four digits to the right of the values <bcp14>MUST NOT</bcp14> be encoded with more than four digits to the righ
decimal point.</t> t of the
<t>depend, to identify other streams that the stream depends on. The value decimal point.</li>
<li pn="section-5-3.8">
<strong>depend</strong>, to identify other streams that the stream dep
ends on. The value
is a comma-separated list of rid-ids. These rid-ids identify RTP streams 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. that this stream depends on in order to allow for proper interpretation.
The mechanism defined in this document allows for such dependencies The mechanism defined in this document allows for such dependencies
to be expressed only when the streams are in the same media section.</t> to be expressed only when the streams are in the same media section.</li>
</list></t> </ul>
<t indent="0" pn="section-5-4">All the restrictions are optional and subje
<t>All the restrictions are optional and are subject to negotiation based on the ct to negotiation based on the
SDP Offer/Answer rules described in <xref target="sec-sdp_o_a"/>.</t> SDP offer/answer rules described in <xref target="sec-sdp_o_a" format="default"
sectionFormat="of" derivedContent="Section 6"/>.</t>
<t>This list is intended to be an initial set of restrictions. Future documents <t indent="0" pn="section-5-5">This list is intended to be an initial set
may define additional restrictions; see <xref target="sec-iana_rid"/>. While th of restrictions. Future documents
is document may define additional restrictions; see <xref target="sec-iana_rid" format="defa
ult" sectionFormat="of" derivedContent="Section 12.2"/>. While this document
does not define restrictions for audio codecs or any media types other than does not define restrictions for audio codecs or any media types other than
video, there is no reason such video, there is no reason such
restrictions should be precluded from definition and registration by other restrictions should be precluded from definition and registration by other
documents.</t> documents.</t>
<t indent="0" pn="section-5-6"><xref target="sec-abnf" format="default" se
<t><xref target="sec-abnf"/> provides formal Augmented Backus-Naur Form (ABNF) < ctionFormat="of" derivedContent="Section 10"/> provides formal Augmented Backus-
xref target="RFC5234"/> Naur Form (ABNF) <xref target="RFC5234" format="default" sectionFormat="of" deri
grammar for each of the “a=rid” restrictions defined in this section.</t> vedContent="RFC5234"/>
grammar for each of the "a=rid" restrictions defined in this section.</t>
</section> </section>
<section anchor="sec-sdp_o_a" title="SDP Offer/Answer Procedures"> <section anchor="sec-sdp_o_a" numbered="true" toc="include" removeInRFC="fal
se" pn="section-6">
<t>This section describes the SDP Offer/Answer <xref target="RFC3264"/> procedur <name slugifiedName="name-sdp-offer-answer-procedures">SDP Offer/Answer Pr
es when ocedures</name>
<t indent="0" pn="section-6-1">This section describes the SDP offer/answer
procedures <xref target="RFC3264" format="default" sectionFormat="of" derivedCo
ntent="RFC3264"/> when
using this framework.</t> using this framework.</t>
<t indent="0" pn="section-6-2">Note that "rid-id" values are only required
<t>Note that “rid-id” values are only required to be unique within a to be unique within a
media section (“m-line”); they do not necessarily need to be unique within an media section ("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 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, own unique 5-tuple (that is: combination of sending address, sending port,
receiving address, receiving port, and transport protocol), which provides an receiving address, receiving port, and transport protocol), which provides an
unambiguous scope. Similarly, when using BUNDLE unambiguous scope.
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, MID values associate RT
P 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.</t>
<section anchor="sec-gen_offer" title="Generating the Initial SDP Offer">
<t>For each RTP media description in the offer, the offerer MAY choose to includ Similarly, when using BUNDLE <xref target="RFC8843" format="default" sectionForm
e one at="of" derivedContent="RFC8843"/>,
or more “a=rid” lines to specify a configuration profile for the given set of Media Identification (MID) values associate RTP streams
RTP Payload Types.</t> uniquely to a single media description.
<t>In order to construct a given “a=rid” line, the offerer must follow these When restriction identifier (RID) is used with the BUNDLE
mechanism, streams will be associated with both MID and RID SDES items.</t>
<section anchor="sec-gen_offer" numbered="true" toc="include" removeInRFC=
"false" pn="section-6.1">
<name slugifiedName="name-generating-the-initial-sdp-">Generating the In
itial SDP Offer</name>
<t indent="0" pn="section-6.1-1">For each RTP media description in the o
ffer, the offerer <bcp14>MAY</bcp14> choose to include one
or more "a=rid" lines to specify a configuration profile for the given set of
RTP payload types.</t>
<t indent="0" pn="section-6.1-2">In order to construct a given "a=rid" l
ine, the offerer must follow these
steps:</t> steps:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.
<t><list style="numbers"> 1-3">
<t>It MUST generate a “rid-id” that is unique within a media <li pn="section-6.1-3.1" derivedCounter="1.">It <bcp14>MUST</bcp14> ge
description</t> nerate a "rid-id" that is unique within a media
<t>It MUST set the direction for the “rid-id” to one of description.</li>
“send” or “recv”</t> <li pn="section-6.1-3.2" derivedCounter="2.">It <bcp14>MUST</bcp14> se
<t>It MAY include a listing of SDP media formats (usually corresponding to RTP t the direction for the "rid-id" to one of
payload types) allowed to appear in the RTP Stream. Any Payload Types "send" or "recv".</li>
chosen MUST be a valid payload type for the media section (that is, it must <li pn="section-6.1-3.3" derivedCounter="3.">It <bcp14>MAY</bcp14> inc
be listed on the “m=” line). The order of the listed formats is lude a listing of SDP media formats (usually corresponding to RTP
payload types) allowed to appear in the RTP stream. Any payload type
chosen <bcp14>MUST</bcp14> be a valid payload type for the media section (that i
s, it must
be listed on the "m=" line). The order of the listed formats is
significant; the alternatives are listed from (left) most preferred to significant; the alternatives are listed from (left) most preferred to
(right) least preferred. When using RID, this preference overrides the (right) least preferred. When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on the normal codec preference as expressed by format type ordering on the
“m=”-line, using regular SDP rules.</t> "m=" line, using regular SDP rules.</li>
<t>The Offerer then chooses zero or more “a=rid” restrictions <li pn="section-6.1-3.4" derivedCounter="4.">The offerer then chooses
(<xref target="sec-rid_level_restrictions"/>) to be applied to the RTP Stream, a zero or more "a=rid" restrictions
nd (<xref target="sec-rid_level_restrictions" format="default" sectionFormat="of" d
adds them to the “a=rid” line.</t> erivedContent="Section 5"/>) to be applied to the RTP stream and
<t>If the offerer wishes the answerer to have the ability to specify a adds them to the "a=rid" line.</li>
restriction, but does not wish to set a value itself, it includes the <li pn="section-6.1-3.5" derivedCounter="5.">If the offerer wishes the
name of the restriction in the “a=rid” line, but without any indicated answerer to have the ability to specify a
value.</t> restriction but does not wish to set a value itself, it includes the
</list></t> name of the restriction in the "a=rid" line, but without any indicated
value.</li>
<t>Note: If an “a=fmtp” attribute is also used to provide media-format-specific </ol>
parameters, then the “a=rid” restrictions will further restrict the <t indent="0" pn="section-6.1-4">Note: If an "a=fmtp" attribute is also
equivalent “a=fmtp” parameters for the given Payload Type for the specified used to provide media-format-specific
RTP Stream.</t> parameters, then the "a=rid" restrictions will further restrict the
equivalent "a=fmtp" parameters for the given payload type for the specified
<t>If a given codec would require an “a=fmtp” line when used without “a=rid” the RTP stream.</t>
n <t indent="0" pn="section-6.1-5">If a given codec would require an "a=fm
the offer MUST include a valid corresponding “a=fmtp” line even when using tp" line when used without "a=rid", then
“a=rid”.</t> the offer <bcp14>MUST</bcp14> include a valid corresponding "a=fmtp" line even w
hen using
</section> "a=rid".</t>
<section anchor="answerer-processing-the-sdp-offer" title="Answerer processing t </section>
he SDP Offer"> <section anchor="answerer-processing-the-sdp-offer" numbered="true" toc="i
nclude" removeInRFC="false" pn="section-6.2">
<section anchor="sec-rid_unaware" title="“a=rid”-unaware Answerer"> <name slugifiedName="name-answerer-processing-the-sdp">Answerer Processi
ng the SDP Offer</name>
<t>If the receiver doesn’t support the framework defined in this <section anchor="sec-rid_unaware" numbered="true" toc="include" removeIn
specification, the entire “a=rid” line is ignored following the standard RFC="false" pn="section-6.2.1">
<xref target="RFC3264"/> Offer/Answer rules.</t> <name slugifiedName="name-arid-unaware-answerer">"a=rid"-Unaware Answe
rer</name>
<t><xref target="sec-gen_offer"/> requires the offer to include a valid “a=fmtp” <t indent="0" pn="section-6.2.1-1">If the receiver doesn't support the
line framework defined in this
for any media formats that otherwise require it (in other words, the “a=rid” specification, the entire "a=rid" line is ignored following the standard
line cannot be used to replace “a=fmtp” configuration). As a result, offer/answer rules <xref target="RFC3264" format="default" sectionFormat="of" de
ignoring the “a=rid” line is always guaranteed to result in a valid rivedContent="RFC3264"/>.</t>
<t indent="0" pn="section-6.2.1-2"><xref target="sec-gen_offer" format
="default" sectionFormat="of" derivedContent="Section 6.1"/> requires the offer
to include a valid "a=fmtp" line
for any media formats that otherwise require it (in other words, the "a=rid"
line cannot be used to replace "a=fmtp" configuration). As a result,
ignoring the "a=rid" line is always guaranteed to result in a valid
session description.</t> session description.</t>
</section>
</section> <section anchor="sec-rid_offer_recv" numbered="true" toc="include" remov
<section anchor="sec-rid_offer_recv" title="“a=rid”-aware Answerer"> eInRFC="false" pn="section-6.2.2">
<name slugifiedName="name-arid-aware-answerer">"a=rid"-Aware Answerer<
<t>If the answerer supports the “a=rid” attribute, the following verification /name>
steps are executed, in order, for each “a=rid” line in a received offer:</t> <t indent="0" pn="section-6.2.2-1">If the answerer supports the "a=rid
" attribute, the following verification
<t><list style="numbers"> steps are executed, in order, for each "a=rid" line in a received offer:</t>
<t>The answerer ensures that the “a=rid” line is syntactically well <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-
formed. In the case of a syntax error, the “a=rid” line is discarded.</t> 6.2.2-2">
<t>The answerer extracts the rid-id from the “a=rid” line and verifies its <li pn="section-6.2.2-2.1" derivedCounter="1.">The answerer ensures
that the "a=rid" line is syntactically well
formed. In the case of a syntax error, the "a=rid" line is discarded.</li>
<li pn="section-6.2.2-2.2" derivedCounter="2.">The answerer extracts
the rid-id from the "a=rid" line and verifies its
uniqueness within a media section. In the case of a duplicate, the entire uniqueness within a media section. In the case of a duplicate, the entire
“a=rid” line, and all “a=rid” lines with rid-ids that duplicate this line, "a=rid" line, and all "a=rid" lines with rid-ids that duplicate this line,
are discarded and MUST NOT be included in the SDP Answer.</t> are discarded and <bcp14>MUST NOT</bcp14> be included in the SDP answer.</li>
<t>If the “a=rid” line contains a “pt=”, the list of payload types <li pn="section-6.2.2-2.3" derivedCounter="3.">If the "a=rid" line c
ontains a "pt=", the list of payload types
is verified against the list of valid payload types for the media section is verified against the list of valid payload types for the media section
(that is, those listed on the “m=” line). Any PT missing from the “m=” line (that is, those listed on the "m=" line). Any PT missing from the "m=" line
is discarded from the set of values in the “pt=”. If no values are left is discarded from the set of values in the "pt=". If no values are left
in the “pt=” parameter after this processing, then the “a=rid” line is discarded in the "pt=" parameter after this processing, then the "a=rid" line is discarded
.</t> .</li>
<t>If the “direction” field is “recv”, the answerer ensures that the specified <li pn="section-6.2.2-2.4" derivedCounter="4.">If the "direction" fi
“a=rid” restrictions are supported. In the case of an unsupported eld is "recv", the answerer ensures that the specified
restriction, the “a=rid” line is discarded.</t> "a=rid" restrictions are supported. In the case of an unsupported
<t>If the “depend” restriction is included, the answerer MUST make restriction, the "a=rid" line is discarded.</li>
<li pn="section-6.2.2-2.5" derivedCounter="5.">If the "depend" restr
iction is included, the answerer <bcp14>MUST</bcp14> make
sure that the listed rid-ids unambiguously match the sure that the listed rid-ids unambiguously match the
rid-ids in the media description. Any “depend” “a=rid” lines that do not are rid-ids in the media description. Any "depend" "a=rid" lines that do not are
discarded.</t> discarded.</li>
<t>The answerer verifies that the restrictions are consistent <li pn="section-6.2.2-2.6" derivedCounter="6.">The answerer verifies
with at least one of the codecs to be used with the RTP Stream. If the that the restrictions are consistent
“a=rid” line contains a “pt=”, it contains the list of such with at least one of the codecs to be used with the RTP stream. If the
"a=rid" line contains a "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the associated codecs; otherwise, the list of such codecs is taken from the associated
“m=” line. See <xref target="sec-feature_interactions"/> for more detail. If th "m=" line. See <xref target="sec-feature_interactions" format="default" section
e Format="of" derivedContent="Section 8"/> for more detail. If the
“a=rid” restrictions are incompatible with the other codec properties "a=rid" restrictions are incompatible with the other codec properties
for all codecs, then the “a=rid” line is discarded.</t> for all codecs, then the "a=rid" line is discarded.</li>
</list></t> </ol>
<t indent="0" pn="section-6.2.2-3">Note that the answerer does not nee
<t>Note that the answerer does not need to understand every restriction present d to understand every restriction present
in a “send” line: if a stream sender restricts the stream in a way that the in a "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> receiver does not understand, this causes no issues with interoperability.</t>
</section>
</section> </section>
</section> <section anchor="sec-rid_answer_send" numbered="true" toc="include" remove
<section anchor="sec-rid_answer_send" title="Generating the SDP Answer"> InRFC="false" pn="section-6.3">
<name slugifiedName="name-generating-the-sdp-answer">Generating the SDP
<t>Having performed verification of the SDP offer as described in Answer</name>
<xref target="sec-rid_offer_recv"/>, the answerer shall perform the following st <t indent="0" pn="section-6.3-1">Having performed verification of the SD
eps to P offer as described in
<xref target="sec-rid_offer_recv" format="default" sectionFormat="of" derivedCon
tent="Section 6.2.2"/>, the answerer shall perform the following steps to
generate the SDP answer.</t> generate the SDP answer.</t>
<t indent="0" pn="section-6.3-2">For each "a=rid" line that has not been
<t>For each “a=rid” line that has not been discarded by previous processing:</t> discarded by previous processing:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.
<t><list style="numbers"> 3-3">
<t>The value of the “direction” field is reversed: “send” is changed <li pn="section-6.3-3.1" derivedCounter="1.">The value of the "directi
to “recv”, and “recv” is changed to “send”.</t> on" field is reversed: "send" is changed
<t>The answerer MAY choose to modify specific “a=rid” restriction values in to "recv", and "recv" is changed to "send".</li>
the answer SDP. In such a case, the modified value MUST be more restrictive <li pn="section-6.3-3.2" derivedCounter="2.">The answerer <bcp14>MAY</
than the ones specified in the offer. The answer MUST NOT include any bcp14> choose to modify specific "a=rid" restriction values in
restrictions that were not present in the offer.</t> the answer SDP. In such a case, the modified value <bcp14>MUST</bcp14> be more r
<t>The answerer MUST NOT modify the “rid-id” present in the offer.</t> estrictive
<t>If the “a=rid” line contains a “pt=”, the answerer is allowed to than the ones specified in the offer. The answer <bcp14>MUST NOT</bcp14> includ
discard one or more media formats from a given “a=rid” line. If the answerer e any
chooses to discard all the media formats from an “a=rid” line, the restrictions that were not present in the offer.</li>
answerer MUST discard the entire “a=rid” line. If the offer did not contain <li pn="section-6.3-3.3" derivedCounter="3.">The answerer <bcp14>MUST
a “pt=” for a given “a=rid” line, then the answer MUST NOT NOT</bcp14> modify the "rid-id" present in the offer.</li>
contain a “pt=” in the corresponding line.</t> <li pn="section-6.3-3.4" derivedCounter="4.">If the "a=rid" line conta
<t>In cases where the answerer is unable to support the payload configuration ins a "pt=", the answerer is allowed to
specified in a given “a=rid” line with a direction of “recv” in the offer, discard one or more media formats from a given "a=rid" line. If the answerer
the answerer MUST discard the corresponding “a=rid” line. This includes chooses to discard all the media formats from an "a=rid" line, the
answerer <bcp14>MUST</bcp14> discard the entire "a=rid" line. If the offer did n
ot contain
a "pt=" for a given "a=rid" line, then the answer <bcp14>MUST NOT</bcp14>
contain a "pt=" in the corresponding line.</li>
<li pn="section-6.3-3.5" derivedCounter="5.">In cases where the answer
er is unable to support the payload configuration
specified in a given "a=rid" line with a direction of "recv" in the offer,
the answerer <bcp14>MUST</bcp14> discard the corresponding "a=rid" line. This i
ncludes
situations in which the answerer does not understand one or more of the situations in which the answerer does not understand one or more of the
restrictions in an “a=rid” line with a direction of “recv”.</t> restrictions in an "a=rid" line with a direction of "recv".</li>
</list></t> </ol>
<t indent="0" pn="section-6.3-4">Note: In the case that the answerer use
<t>Note: in the case that the answerer uses different PT values to represent a s different PT values to represent a
codec than the offerer did, the “a=rid” values in the answer use the PT values codec than the offerer did, the "a=rid" values in the answer use the PT values
that are present in its answer.</t> that are present in its answer.</t>
</section>
</section> <section anchor="sec-rid_answer_recv" numbered="true" toc="include" remove
<section anchor="sec-rid_answer_recv" title="Offerer Processing of the SDP Answe InRFC="false" pn="section-6.4">
r"> <name slugifiedName="name-offerer-processing-of-the-s">Offerer Processin
g of the SDP Answer</name>
<t>The offerer SHALL follow these steps when processing the answer:</t> <t indent="0" pn="section-6.4-1">The offerer <bcp14>SHALL</bcp14> follow
these steps when processing the answer:</t>
<t><list style="numbers"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.
<t>The offerer matches the “a=rid” line in the answer to the “a=rid” line 4-2">
in the offer using the “rid-id”. If no matching line can be located <li pn="section-6.4-2.1" derivedCounter="1.">The offerer matches the "
in the offer, the “a=rid” line is ignored.</t> a=rid" line in the answer to the "a=rid" line
<t>If the answer contains any restrictions that were not present in the offer, in the offer using the "rid-id". If no matching line can be located
then the offerer SHALL discard the “a=rid” line.</t> in the offer, the "a=rid" line is ignored.</li>
<t>If the restrictions have been changed between the offer and the <li pn="section-6.4-2.2" derivedCounter="2.">If the answer contains an
answer, the offerer MUST ensure that the modifications are more restrictive y restrictions that were not present in the offer,
than they were in the original offer, and that they can be supported; if then the offerer <bcp14>SHALL</bcp14> discard the "a=rid" line.</li>
not, the offerer SHALL discard the “a=rid” line.</t> <li pn="section-6.4-2.3" derivedCounter="3.">If the restrictions have
<t>If the “a=rid” line in the answer contains a “pt=” but the been changed between the offer and the
offer did not, the offerer SHALL discard the “a=rid” line.</t> answer, the offerer <bcp14>MUST</bcp14> ensure that the modifications are more r
<t>If the “a=rid” line in the answer contains a “pt=” and the estrictive
than they were in the original offer and that they can be supported; if
not, the offerer <bcp14>SHALL</bcp14> discard the "a=rid" line.</li>
<li pn="section-6.4-2.4" derivedCounter="4.">If the "a=rid" line in th
e answer contains a "pt=" but the
offer did not, the offerer <bcp14>SHALL</bcp14> discard the "a=rid" line.</li>
<li pn="section-6.4-2.5" derivedCounter="5.">If the "a=rid" line in th
e answer contains a "pt=" and the
offer did as well, the offerer verifies that the list of payload types is a offer did as well, the offerer verifies that the list of payload types is a
subset of those sent in the corresponding “a=rid” line in the offer. Note subset of those sent in the corresponding "a=rid" line in the offer. Note
that this matching must be performed semantically rather than on literal PT 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 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” line in the answer, of this comparison: for each PT listed on the "a=rid" line in the answer,
the offerer looks up the corresponding “a=rtpmap” and “a=fmtp” lines in the the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" lines in the
answer. It then searches the list of “pt=” values indicated in the offer, answer. It then searches the list of "pt=" values indicated in the offer
and attempts to find one with an equivalent set of “a=rtpmap” and “a=fmtp” and attempts to find one with an equivalent set of "a=rtpmap" and "a=fmtp"
lines in the offer. If all PTs in the answer can be matched, then the “pt=” lines in the offer. If all PTs in the answer can be matched, then the "pt="
values pass validation; otherwise, it fails. If this validation fails, the values pass validation; otherwise, it fails. If this validation fails, the
offerer SHALL discard the “a=rid” line. Note that this semantic comparison offerer <bcp14>SHALL</bcp14> discard the "a=rid" line. Note that this semantic c omparison
necessarily requires an understanding of the meaning of codec parameters, necessarily requires an understanding of the meaning of codec parameters,
rather than a rote byte-wise comparison of their values.</t> rather than a rote byte-wise comparison of their values.</li>
<t>If the “a=rid” line contains a “pt=”, the offerer verifies that <li pn="section-6.4-2.6" derivedCounter="6.">If the "a=rid" line conta
the attribute values provided in the “a=rid” attributes are consistent ins a "pt=", the offerer verifies that
the attribute values provided in the "a=rid" attributes are consistent
with the corresponding codecs and their other parameters. See with the corresponding codecs and their other parameters. See
<xref target="sec-feature_interactions"/> for more detail. If the “a=rid” restri ctions <xref target="sec-feature_interactions" format="default" sectionFormat="of" deri vedContent="Section 8"/> for more detail. If the "a=rid" restrictions
are incompatible with the other codec properties, then the offerer are incompatible with the other codec properties, then the offerer
SHALL discard the “a=rid” line.</t> <bcp14>SHALL</bcp14> discard the "a=rid" line.</li>
<t>The offerer verifies that the restrictions are consistent <li pn="section-6.4-2.7" derivedCounter="7.">The offerer verifies that
with at least one of the codecs to be used with the RTP Stream. If the the restrictions are consistent
“a=rid” line contains a “pt=”, it contains the list of such with at least one of the codecs to be used with the RTP stream. If the
"a=rid" line contains a "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the associated codecs; otherwise, the list of such codecs is taken from the associated
“m=” line. See <xref target="sec-feature_interactions"/> for more detail. If th "m=" line. See <xref target="sec-feature_interactions" format="default" section
e Format="of" derivedContent="Section 8"/> for more detail. If the
“a=rid” restrictions are incompatible with the other codec properties "a=rid" restrictions are incompatible with the other codec properties
for all codecs, then the offerer SHALL discard the “a=rid” line.</t> for all codecs, then the offerer <bcp14>SHALL</bcp14> discard the "a=rid" line.<
</list></t> /li>
</ol>
<t>Any “a=rid” line present in the offer that was not matched by step 1 above <t indent="0" pn="section-6.4-3">Any "a=rid" line present in the offer t
has been discarded by the answerer, and does not form part of the negotiated hat was not matched by step 1 above
restrictions on an RTP Stream. The offerer MAY still apply any restrictions has been discarded by the answerer and does not form part of the negotiated
it indicated in an “a=rid” line with a direction field of “send”, but restrictions on an RTP stream. The offerer <bcp14>MAY</bcp14> still apply any re
strictions
it indicated in an "a=rid" line with a direction field of "send", but
it is not required to do so.</t> it is not required to do so.</t>
<t indent="0" pn="section-6.4-4">It is important to note that there are
<t>It is important to note that there are several ways in which an offer can several ways in which an offer can
contain a media section with “a=rid” lines, but the corresponding media contain a media section with "a=rid" lines, although the corresponding media
section in the response does not. This includes situations in which the section in the response does not. This includes situations in which the
answerer does not support “a=rid” at all, or does not support the indicated answerer does not support "a=rid" at all or does not support the indicated
restrictions. Under such circumstances, the offerer MUST be prepared to restrictions. Under such circumstances, the offerer <bcp14>MUST</bcp14> be prepa
red to
receive a media stream to which no restrictions have been applied.</t> receive a media stream to which no restrictions have been applied.</t>
</section>
</section> <section anchor="modifying-the-session" numbered="true" toc="include" remo
<section anchor="modifying-the-session" title="Modifying the Session"> veInRFC="false" pn="section-6.5">
<name slugifiedName="name-modifying-the-session">Modifying the Session</
<t>Offers and answers inside an existing session follow the rules for initial name>
session negotiation. Such an offer MAY propose a change in the number of RIDs <t indent="0" pn="section-6.5-1">Offers and answers inside an existing s
ession follow the rules for initial
session negotiation. Such an offer <bcp14>MAY</bcp14> propose a change in the n
umber of RIDs
in use. To avoid race conditions with media, any RIDs with proposed changes in use. To avoid race conditions with media, any RIDs with proposed changes
SHOULD use a new ID, rather than re-using one from the previous offer/answer <bcp14>SHOULD</bcp14> use a new ID rather than reusing one from the previous off
exchange. RIDs without proposed changes SHOULD re-use the ID from the previous er/answer
exchange. RIDs without proposed changes <bcp14>SHOULD</bcp14> reuse the ID from
the previous
exchange.</t> exchange.</t>
</section>
</section> </section>
</section> <section anchor="sec-declarative_sdp" numbered="true" toc="include" removeIn
<section anchor="sec-declarative_sdp" title="Use with Declarative SDP"> RFC="false" pn="section-7">
<name slugifiedName="name-use-with-declarative-sdp">Use with Declarative S
<t>This document does not define the use of RID in declarative SDP. If DP</name>
<t indent="0" pn="section-7-1">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 concrete use cases for RID in declarative SDP use are identified
in the future, we expect that additional specifications will address in the future, we expect that additional specifications will address
such use.</t> such use.</t>
</section>
</section> <section anchor="sec-feature_interactions" numbered="true" toc="include" rem
<section anchor="sec-feature_interactions" title="Interaction with Other Techniq oveInRFC="false" pn="section-8">
ues"> <name slugifiedName="name-interaction-with-other-tech">Interaction with Ot
her Techniques</name>
<t>Historically, a number of other approaches have been defined that allow <t indent="0" pn="section-8-1">Historically, a number of other approaches
have been defined that allow
restricting media streams via SDP. These include:</t> restricting media streams via SDP. These include:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-2
<t><list style="symbols"> ">
<t>Codec-specific configuration set via format parameters (“a=fmtp”); for <li pn="section-8-2.1">Codec-specific configuration set via format param
example, the H.264 “max-fs” format parameter <xref target="RFC6184"/></t> eters ("a=fmtp") -- for
<t>Size restrictions imposed by image attribute attributes (“a=imageattr”) example, the H.264 "max-fs" format parameter <xref target="RFC6184" format="defa
<xref target="RFC6236"/></t> ult" sectionFormat="of" derivedContent="RFC6184"/></li>
</list></t> <li pn="section-8-2.2">Size restrictions imposed by the "a=imageattr" at
tribute
<t>When the mechanism described in this document is used in conjunction with <xref target="RFC6236" format="default" sectionFormat="of" derivedContent="RFC62
36"/></li>
</ul>
<t indent="0" pn="section-8-3">When the mechanism described in this docume
nt is used in conjunction with
these other restricting mechanisms, it is intended to impose additional these other restricting mechanisms, it is intended to impose additional
restrictions beyond those communicated in other techniques.</t> restrictions beyond those communicated in other techniques.</t>
<t indent="0" pn="section-8-4">In an offer, this means that "a=rid" lines,
<t>In an offer, this means that “a=rid” lines, when combined with other when combined with other
restrictions on the media stream, are expected to result in a non-empty intersec tion. restrictions on the media stream, are expected to result in a non-empty intersec tion.
For example, if image attributes are used to indicate that a PT has a minimum For example, if image attributes are used to indicate that a PT has a minimum
width of 640, then specification of “max-width=320” in an “a=rid” line that is width of 640, then specification of "max-width=320" in an "a=rid" line that is
then applied to that PT is nonsensical. According to the rules of then applied to that PT is nonsensical. According to the rules of
<xref target="sec-rid_offer_recv"/>, this will result in the corresponding “a=ri d” line <xref target="sec-rid_offer_recv" format="default" sectionFormat="of" derivedCon tent="Section 6.2.2"/>, this will result in the corresponding "a=rid" line
being ignored by the recipient.</t> being ignored by the recipient.</t>
<t indent="0" pn="section-8-5">In an answer, the "a=rid" lines, when combi
<t>In an answer, the “a=rid” lines, when combined with the other ned with the other
restrictions on the media stream, are also expected to result in a non-empty 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 intersection. If the implementation generating an answer wishes to restrict a
property of the stream below that which would be allowed by other parameters property of the stream below that which would be allowed by other parameters
(e.g., those specified in “a=fmtp” or “a=imageattr”), its only recourse is to (e.g., those specified in "a=fmtp" or "a=imageattr"), its only recourse is to
discard the “a=rid” line altogether, as described in <xref target="sec-rid_answe discard the "a=rid" line altogether, as described in <xref target="sec-rid_answe
r_send"/>. r_send" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.
If it instead attempts to restrict the stream beyond what is allowed by other If it instead attempts to restrict the stream beyond what is allowed by other
mechanisms, then the offerer will ignore the corresponding “a=rid” line, as mechanisms, then the offerer will ignore the corresponding "a=rid" line, as
described in <xref target="sec-rid_answer_recv"/>.</t> described in <xref target="sec-rid_answer_recv" format="default" sectionFormat="
of" derivedContent="Section 6.4"/>.</t>
<t>The following subsections demonstrate these interactions using commonly-used <t indent="0" pn="section-8-6">The following subsections demonstrate these
interactions using commonly used
video codecs. These descriptions are illustrative of the interaction principles video codecs. These descriptions are illustrative of the interaction principles
outlined above, and are not normative.</t> outlined above and are not normative.</t>
<section anchor="interaction-with-vp8-format-parameters" numbered="true" t
<section anchor="interaction-with-vp8-format-parameters" title="Interaction with oc="include" removeInRFC="false" pn="section-8.1">
VP8 Format Parameters"> <name slugifiedName="name-interaction-with-vp8-format">Interaction with
VP8 Format Parameters</name>
<t><xref target="RFC7741"/> defines two format parameters for the VP8 codec. <t indent="0" pn="section-8.1-1"><xref target="RFC7741" format="default"
Both correspond to restrictions on receiver capabilities, and never sectionFormat="of" derivedContent="RFC7741"/> defines two format parameters for
the VP8 codec.
Both correspond to restrictions on receiver capabilities and never
indicate sending restrictions.</t> indicate sending restrictions.</t>
<section anchor="max-fr-maximum-framerate" numbered="true" toc="include"
<section anchor="max-fr-maximum-framerate" title="max-fr - Maximum Framerate"> removeInRFC="false" pn="section-8.1.1">
<name slugifiedName="name-max-fr-maximum-frame-rate">max-fr - Maximum
<t>The VP8 “max-fr” format parameter corresponds to the “max-fps” restriction Frame Rate</name>
<t indent="0" pn="section-8.1.1-1">The VP8 "max-fr" format parameter c
orresponds to the "max-fps" restriction
defined in this specification. If an RTP sender is generating a stream using defined in this specification. If an RTP sender is generating a stream using
a format defined with this format parameter, and the sending restrictions a format defined with this format parameter, and the sending restrictions
defined via “a=rid” include a “max-fps” parameter, then the sent stream defined via "a=rid" include a "max-fps" parameter, then the sent stream
will conform to the smaller of the two values.</t> will conform to the smaller of the two values.</t>
</section>
</section> <section anchor="max-fs-maximum-framesize-in-vp8-macroblocks" numbered="
<section anchor="max-fs-maximum-framesize-in-vp8-macroblocks" title="max-fs - Ma true" toc="include" removeInRFC="false" pn="section-8.1.2">
ximum Framesize, in VP8 Macroblocks"> <name slugifiedName="name-max-fs-maximum-frame-size-i">max-fs - Maximu
m Frame Size, in VP8 Macroblocks</name>
<t>The VP8 “max-fs” format parameter corresponds to the “max-fs” <t indent="0" pn="section-8.1.2-1">The VP8 "max-fs" format parameter c
orresponds to the "max-fs"
restriction defined in this document, by way of a conversion factor of the 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 number of pixels per macroblock (typically 256). If an RTP sender is
generating a stream using a format defined with this format parameter, and generating a stream using a format defined with this format parameter, and
the sending restrictions defined via “a=rid” include a “max-fs” parameter, the sending restrictions defined via "a=rid" include a "max-fs" parameter,
then the sent stream will conform to the smaller of the two values; 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> that is, the number of pixels per frame will not exceed:</t>
<sourcecode markers="false" pn="section-8.1.2-2">
<figure><artwork><![CDATA[
min(rid_max_fs, fmtp_max_fs * macroblock_size) min(rid_max_fs, fmtp_max_fs * macroblock_size)
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-8.1.2-3">This fmtp parameter also has bearin
g on the
max-height and max-width parameters.
<t>This fmtp parameter also has bearing on the <xref section="6.1" sectionFormat="of" target="RFC7741" format="default" derived
max-height and max-width parameters. Section 6.1 of Link="https://rfc-editor.org/rfc/rfc7741#section-6.1" derivedContent="RFC7741"/>
<xref target="RFC7741"/> requires that the width and height of the frame in requires that the width and height of the frame in
macroblocks are also required to be less than int(sqrt(fmtp_max_fs * 8)). macroblocks be less than int(sqrt(fmtp_max_fs * 8)).
Accordingly, the maximum width of a transmitted stream will be limited to:</t> Accordingly, the maximum width of a transmitted stream will be limited to:</t>
<sourcecode markers="false" pn="section-8.1.2-4">
<figure><artwork><![CDATA[
min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width)
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-8.1.2-5">Similarly, the stream's height will
<t>Similarly, the stream’s height will be limited to:</t> be limited to:</t>
<sourcecode markers="false" pn="section-8.1.2-6">
<figure><artwork><![CDATA[
min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height)
]]></artwork></figure> </sourcecode>
</section>
</section> </section>
</section> <section anchor="interaction-with-h264-format-parameters" numbered="true"
<section anchor="interaction-with-h264-format-parameters" title="Interaction wit toc="include" removeInRFC="false" pn="section-8.2">
h H.264 Format Parameters"> <name slugifiedName="name-interaction-with-h264-forma">Interaction with
H.264 Format Parameters</name>
<t><xref target="RFC6184"/> defines format parameters for the H.264 video codec. <t indent="0" pn="section-8.2-1"><xref target="RFC6184" format="default"
The majority sectionFormat="of" derivedContent="RFC6184"/> defines format parameters for the
H.264 video codec. The majority
of these parameters do not correspond to codec-independent restrictions:</t> of these parameters do not correspond to codec-independent restrictions:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
<t><list style="symbols"> .2-2">
<t>deint-buf-cap</t> <li pn="section-8.2-2.1">deint-buf-cap</li>
<t>in-band-parameter-sets</t> <li pn="section-8.2-2.2">in-band-parameter-sets</li>
<t>level-asymmetry-allowed</t> <li pn="section-8.2-2.3">level-asymmetry-allowed</li>
<t>max-rcmd-nalu-size</t> <li pn="section-8.2-2.4">max-rcmd-nalu-size</li>
<t>max-cpb</t> <li pn="section-8.2-2.5">max-cpb</li>
<t>max-dpb</t> <li pn="section-8.2-2.6">max-dpb</li>
<t>packetization-mode</t> <li pn="section-8.2-2.7">packetization-mode</li>
<t>redundant-pic-cap</t> <li pn="section-8.2-2.8">redundant-pic-cap</li>
<t>sar-supported</t> <li pn="section-8.2-2.9">sar-supported</li>
<t>sar-understood</t> <li pn="section-8.2-2.10">sar-understood</li>
<t>sprop-deint-buf-req</t> <li pn="section-8.2-2.11">sprop-deint-buf-req</li>
<t>sprop-init-buf-time</t> <li pn="section-8.2-2.12">sprop-init-buf-time</li>
<t>sprop-interleaving-depth</t> <li pn="section-8.2-2.13">sprop-interleaving-depth</li>
<t>sprop-level-parameter-sets</t> <li pn="section-8.2-2.14">sprop-level-parameter-sets</li>
<t>sprop-max-don-diff</t> <li pn="section-8.2-2.15">sprop-max-don-diff</li>
<t>sprop-parameter-sets</t> <li pn="section-8.2-2.16">sprop-parameter-sets</li>
<t>use-level-src-parameter-sets</t> <li pn="section-8.2-2.17">use-level-src-parameter-sets</li>
</list></t> </ul>
<t indent="0" pn="section-8.2-3">Note that the max-cpb and max-dpb forma
<t>Note that the max-cpb and max-dpb format parameters for H.264 correspond to t parameters for H.264 correspond to
restrictions on the stream, but they are specific to the way the H.264 codec restrictions on the stream, but they are specific to the way the H.264 codec
operates, and do not have codec-independent equivalents.</t> operates, and do not have codec-independent equivalents.</t>
<t indent="0" pn="section-8.2-4">The <xref target="RFC6184" format="defa
<t>The <xref target="RFC6184"/> codec format parameters covered in the following ult" sectionFormat="of" derivedContent="RFC6184"/> codec format parameters cover
sections ed in the following sections
correspond to restrictions on receiver capabilities, and never indicate correspond to restrictions on receiver capabilities and never indicate
sending restrictions.</t> sending restrictions.</t>
<section anchor="profile-level-id-and-max-recv-level-negotiated-sub-prof
<section anchor="profile-level-id-and-max-recv-level-negotiated-sub-profile" tit ile" numbered="true" toc="include" removeInRFC="false" pn="section-8.2.1">
le="profile-level-id and max-recv-level - Negotiated Sub-Profile"> <name slugifiedName="name-profile-level-id-and-max-re">profile-level-i
d and max-recv-level - Negotiated Subprofile</name>
<t>These parameters include a “level” indicator, which acts as an index <t indent="0" pn="section-8.2.1-1">These parameters include a "level"
into Table A-1 of <xref target="H264"/>. This table contains a number of paramet indicator, which acts as an index
ers, into Table A-1 of <xref target="H264" format="default" sectionFormat="of" derive
dContent="H264"/>. This table contains a number of parameters,
several of which correspond to the restrictions defined in this several of which correspond to the restrictions defined in this
document. <xref target="RFC6184"/> also defines format parameters for the H.264 document. <xref target="RFC6184" format="default" sectionFormat="of" derivedCont ent="RFC6184"/> also defines format parameters for the H.264
codec that may increase the maximum values indicated by the negotiated codec that may increase the maximum values indicated by the negotiated
level. The following sections describe the interaction between these level. The following sections describe the interaction between these
parameters and the restrictions defined by this document. In all cases, parameters and the restrictions defined by this document. In all cases,
the H.264 parameters being discussed are the maximum of those indicated the H.264 parameters being discussed are the maximum of those indicated
by <xref target="H264"></xref> Table A-1 and those indicated in the correspondin by <xref target="H264" format="default" sectionFormat="of" derivedContent="H264"
g “a=fmtp” line.</t> /> Table A-1 and those indicated in the corresponding "a=fmtp" line.</t>
</section>
</section> <section anchor="max-br-maxbr-maximum-video-bitrate" numbered="true" toc
<section anchor="max-br-maxbr-maximum-video-bitrate" title="max-br / MaxBR - Max ="include" removeInRFC="false" pn="section-8.2.2">
imum Video Bitrate"> <name slugifiedName="name-max-br-maxbr-maximum-video-">max-br / MaxBR
- Maximum Video Bitrate</name>
<t>The H.264 “MaxBR” parameter (and its equivalent “max-br” format <t indent="0" pn="section-8.2.2-1">The H.264 "MaxBR" parameter (and it
parameter) corresponds to the “max-bps” restriction s equivalent "max-br" format
parameter) corresponds to the "max-bps" restriction
defined in this specification, by way of a conversion factor of 1000 defined in this specification, by way of a conversion factor of 1000
or 1200; see <xref target="RFC6184"/> for details regarding which factor gets or 1200; see <xref target="RFC6184" format="default" sectionFormat="of" derivedC ontent="RFC6184"/> for details regarding which factor gets
used under differing circumstances.</t> used under differing circumstances.</t>
<t indent="0" pn="section-8.2.2-2">If an RTP sender is generating a st
<t>If an RTP sender is generating a stream using ream using
a format defined with this format parameter, and the sending restrictions a format defined with this format parameter, and the sending restrictions
defined via “a=rid” include a “max-fps” parameter, then the sent stream defined via "a=rid" include a "max-fps" parameter, then the sent stream
will conform to the smaller of the two values – that is:</t> will conform to the smaller of the two values -- that is:</t>
<sourcecode markers="false" pn="section-8.2.2-3">
<figure><artwork><![CDATA[
min(rid_max_br, h264_MaxBR * conversion_factor) min(rid_max_br, h264_MaxBR * conversion_factor)
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="max-fs-maxfs-maximum-framesize-in-h264-macroblocks" num
<section anchor="max-fs-maxfs-maximum-framesize-in-h264-macroblocks" title="max- bered="true" toc="include" removeInRFC="false" pn="section-8.2.3">
fs / MaxFS - Maximum Framesize, in H.264 Macroblocks"> <name slugifiedName="name-max-fs-maxfs-maximum-frame-">max-fs / MaxFS
- Maximum Frame Size, in H.264 Macroblocks</name>
<t>The H.264 “MaxFs” parameter (and its equivalent “max-fs” <t indent="0" pn="section-8.2.3-1">The H.264 "MaxFs" parameter (and it
format parameter) corresponds roughly to the “max-fs” restriction s equivalent "max-fs"
format parameter) corresponds roughly to the "max-fs" restriction
defined in this document, by way of a conversion factor of 256 defined in this document, by way of a conversion factor of 256
(the number of pixels per macroblock).</t> (the number of pixels per macroblock).</t>
<t indent="0" pn="section-8.2.3-2">If an RTP sender is generating a st
<t>If an RTP sender is generating a stream using ream using
a format defined with this format parameter, and the sending restrictions a format defined with this format parameter, and the sending restrictions
defined via “a=rid” include a “max-fs” parameter, then the sent stream defined via "a=rid" include a "max-fs" parameter, then the sent stream
will conform to the smaller of the two values – that is:</t> will conform to the smaller of the two values -- that is:</t>
<sourcecode markers="false" pn="section-8.2.3-3">
<figure><artwork><![CDATA[
min(rid_max_fs, h264_MaxFs * 256) min(rid_max_fs, h264_MaxFs * 256)
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="sec-h264_max_mbps" numbered="true" toc="include" remove
<section anchor="sec-h264_max_mbps" title="max-mbps / MaxMBPS - Maximum Macroblo InRFC="false" pn="section-8.2.4">
ck Processing Rate"> <name slugifiedName="name-max-mbps-maxmbps-maximum-ma">max-mbps / MaxM
BPS - Maximum Macroblock Processing Rate</name>
<t>The H.264 “MaxMBPS” parameter (and its equivalent “max-mbps” <t indent="0" pn="section-8.2.4-1">The H.264 "MaxMBPS" parameter (and
format parameter) corresponds roughly to the “max-pps” restriction its equivalent "max-mbps"
format parameter) corresponds roughly to the "max-pps" restriction
defined in this document, by way of a conversion factor of 256 defined in this document, by way of a conversion factor of 256
(the number of pixels per macroblock).</t> (the number of pixels per macroblock).</t>
<t indent="0" pn="section-8.2.4-2">If an RTP sender is generating a st
<t>If an RTP sender is generating a stream using ream using
a format defined with this format parameter, and the sending restrictions a format defined with this format parameter, and the sending restrictions
defined via “a=rid” include a “max-pps” parameter, then the sent stream defined via "a=rid" include a "max-pps" parameter, then the sent stream
will conform to the smaller of the two values – that is:</t> will conform to the smaller of the two values -- that is:</t>
<sourcecode markers="false" pn="section-8.2.4-3">
<figure><artwork><![CDATA[
min(rid_max_pps, h264_MaxMBPS * 256) min(rid_max_pps, h264_MaxMBPS * 256)
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="max-smbps-maximum-decoded-picture-buffer" numbered="tru
<section anchor="max-smbps-maximum-decoded-picture-buffer" title="max-smbps - Ma e" toc="include" removeInRFC="false" pn="section-8.2.5">
ximum Decoded Picture Buffer"> <name slugifiedName="name-max-smbps-maximum-decoded-p">max-smbps - Max
imum Decoded Picture Buffer</name>
<t>The H.264 “max-smbps” format parameter operates the same way as the <t indent="0" pn="section-8.2.5-1">The H.264 "max-smbps" format parame
“max-mpbs” format parameter, under the hypothetical assumption that all ter 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 macroblocks are static macroblocks. It is handled by applying the
conversion factor described in Section 8.1 of <xref target="RFC6184"/>, and the conversion factor described in Section 8.1 of <xref target="RFC6184" format="def ault" sectionFormat="of" derivedContent="RFC6184"/>, and the
result of this conversion is applied as described in result of this conversion is applied as described in
<xref target="sec-h264_max_mbps"/>.</t> <xref target="sec-h264_max_mbps" format="default" sectionFormat="of" derivedCont
ent="Section 8.2.4"/>.</t>
</section> </section>
</section> </section>
<section anchor="redundancy-formats-and-payload-type-restrictions" title="Redund <section anchor="redundancy-formats-and-payload-type-restrictions" numbere
ancy Formats and Payload Type Restrictions"> d="true" toc="include" removeInRFC="false" pn="section-8.3">
<name slugifiedName="name-redundancy-formats-and-payl">Redundancy Format
<t><xref target="sec-rid_attribute"/> specifies that redundancy formats using re s and Payload Type Restrictions</name>
dundancy RTP streams bind <t indent="0" pn="section-8.3-1"><xref target="sec-rid_attribute" format
="default" sectionFormat="of" derivedContent="Section 4"/> specifies that redund
ancy formats using redundancy RTP streams bind
the redundancy RTP stream to the source RTP stream with either the the redundancy RTP stream to the source RTP stream with either the
RepairedRtpStreamId SDES item, or other mechanisms. However, there exist RepairedRtpStreamId SDES item or other mechanisms. However, there exist
redundancy RTP payload formats that result in the redundancy being included in redundancy RTP payload formats that result in the redundancy being included in
the source RTP stream. An example of this is “RTP Payload for Redundant Audio the source RTP stream. An example of this is "RTP Payload for Redundant Audio
Data” <xref target="RFC2198"/>, which encapsulates one source stream with one or Data" <xref target="RFC2198" format="default" sectionFormat="of" derivedContent=
more "RFC2198"/>, which encapsulates one source stream with one or more
redundancy streams in the same RTP payload. Formats defining the source and redundancy streams in the same RTP payload. Formats defining the source and
redundancy encodings as regular RTP payload types require some consideration redundancy encodings as regular RTP payload types require some consideration
for how the “a=rid” restrictions are defined. The “a=rid” line “pt=” parameter for how the "a=rid" restrictions are defined. The "a=rid" line "pt=" parameter
can be used to indicate whether the redundancy RTP payload type and/or the 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> individual source RTP payload type(s) are part of the restriction.</t>
<t indent="0" pn="section-8.3-2">Example (SDP excerpt):</t>
<t>Example (SDP Excerpt):</t> <sourcecode type="sdp" markers="false" pn="section-8.3-3">
<figure><artwork><![CDATA[
m=audio 49200 RTP/AVP 97 98 99 100 101 102 m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo a=mid:foo
a=rtpmap:97 G711/8000 a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000 a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1 a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1 a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000 a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000 a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1; usedtx=0 a=fmtp:99 useinbandfec=1; usedtx=0
a=fmtp:100 97/98 a=fmtp:100 97/98
a=fmtp:102 0-15 a=fmtp:102 0-15
a=ptime:20 a=ptime:20
a=maxptime:40 a=maxptime:40
a=rid:5 send pt=99,102;max-br=64000 a=rid:5 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102 a=rid:6 send pt=100,97,101,102
</sourcecode>
]]></artwork></figure> <t indent="0" pn="section-8.3-4">The RID with ID=6 restricts the payload
types for this RID to 100
<t>The RID with ID=6 restricts the payload types for this RID to 100 (the redund (the redundancy format), 97 (G.711), 101 (Comfort Noise), and 102
ancy (dual-tone multi-frequency (DTMF) tones). This means that RID 6 can
format), 97 (G.711), 101 (Comfort Noise) and 102 (DTMF tones). This means that either contain the Redundant Audio Data (RED) format, encapsulating
RID 6 can either contain the RED format, encapsulating encodings of the source encodings of the source media stream using payload type 97 and 98, 97
media stream using payload type 97 and 98, 97 without RED encapsulation, without RED encapsulation, Comfort noise, or DTMF tones. Payload type
Comfort noise, or DTMF tones. Payload type 98 is not included in the RID, and 98 is not included in the RID, and can thus not be sent except as
can thus not be sent except as redundancy information in RED encapsulation. If redundancy information in RED encapsulation. If 97 were to be excluded
97 were to be excluded from the pt parameter, it would instead mean that from the pt parameter, it would instead mean that payload types 97 and
payload types 97 and 98 are only allowed via RED encapsulation.</t> 98 are only allowed via RED encapsulation.</t>
</section>
</section> </section>
</section> <section anchor="format-parameters-for-future-payloads" numbered="true" toc=
<section anchor="format-parameters-for-future-payloads" title="Format Parameters "include" removeInRFC="false" pn="section-9">
for Future Payloads"> <name slugifiedName="name-format-parameters-for-futur">Format Parameters f
or Future Payloads</name>
<t>Registrations of future RTP payload format specifications that define media <t indent="0" pn="section-9-1">Registrations of future RTP payload format
specifications that define media
types that have parameters matching the RID restrictions specified in this memo types that have parameters matching the RID restrictions specified in this memo
SHOULD name those parameters in a manner that matches the names of those RID <bcp14>SHOULD</bcp14> name those parameters in a manner that matches the names o
restrictions, and SHOULD explicitly state what media type parameters are f those RID
restrictions and <bcp14>SHOULD</bcp14> explicitly state what media-type paramete
rs are
restricted by what RID restrictions.</t> restricted by what RID restrictions.</t>
</section>
</section> <section anchor="sec-abnf" numbered="true" toc="include" removeInRFC="false"
<section anchor="sec-abnf" title="Formal Grammar"> pn="section-10">
<name slugifiedName="name-formal-grammar">Formal Grammar</name>
<t>This section gives a formal Augmented Backus-Naur Form (ABNF) <xref target="R <t indent="0" pn="section-10-1">This section gives a formal Augmented Back
FC5234"/> us-Naur Form (ABNF) <xref target="RFC5234" format="default" sectionFormat="of" d
grammar, with the case-sensitive extensions described in <xref target="RFC7405"/ erivedContent="RFC5234"/>
>, for each grammar, with the case-sensitive extensions described in <xref target="RFC7405"
of the new media and “a=rid” attributes defined in this document.</t> format="default" sectionFormat="of" derivedContent="RFC7405"/>, for each
of the new media and "a=rid" attributes defined in this document.</t>
<figure><artwork><![CDATA[ <sourcecode type="abnf" markers="false" pn="section-10-2">
rid-syntax = %s"a=rid:" rid-id SP rid-dir rid-syntax = %s"a=rid:" rid-id SP rid-dir
[ rid-pt-param-list / rid-param-list ] [ rid-pt-param-list / rid-param-list ]
rid-id = 1*(alpha-numeric / "-" / "_") rid-id = 1*(alpha-numeric / "-" / "_")
alpha-numeric = < as defined in {{RFC4566}} &gt; alpha-numeric = < as defined in [RFC4566] &gt;
rid-dir = %s"send" / %s"recv" rid-dir = %s"send" / %s"recv"
rid-pt-param-list = SP rid-fmt-list *(";" rid-param) rid-pt-param-list = SP rid-fmt-list *(";" rid-param)
rid-param-list = SP rid-param *(";" rid-param) rid-param-list = SP rid-param *(";" rid-param)
rid-fmt-list = %s"pt=" fmt *( "," fmt ) rid-fmt-list = %s"pt=" fmt *( "," fmt )
fmt = < as defined in {{RFC4566}} &gt; fmt = < as defined in [RFC4566] &gt;
rid-param = rid-width-param rid-param = rid-width-param
/ rid-height-param / rid-height-param
/ rid-fps-param / rid-fps-param
/ rid-fs-param / rid-fs-param
/ rid-br-param / rid-br-param
/ rid-pps-param / rid-pps-param
/ rid-bpp-param / rid-bpp-param
/ rid-depend-param / rid-depend-param
/ rid-param-other / rid-param-other
skipping to change at line 811 skipping to change at line 912
rid-depend-param = %s"depend=" rid-list rid-depend-param = %s"depend=" rid-list
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
rid-list = rid-id *( "," rid-id ) rid-list = rid-id *( "," rid-id )
int-param-val = 1*DIGIT int-param-val = 1*DIGIT
float-param-val = 1*DIGIT "." 1*DIGIT float-param-val = 1*DIGIT "." 1*DIGIT
param-val = *( %x20-58 / %x60-7E ) param-val = *(%x20-3A / %x3C-7E)
; Any printable character except semicolon ; Any printable character except semicolon
</sourcecode>
]]></artwork></figure> </section>
<section anchor="sdp-examples" numbered="true" toc="include" removeInRFC="fa
</section> lse" pn="section-11">
<section anchor="sdp-examples" title="SDP Examples"> <name slugifiedName="name-sdp-examples">SDP Examples</name>
<t indent="0" pn="section-11-1">Note: See <xref target="RFC8853" format="d
<t>Note: see <xref target="I-D.ietf-mmusic-sdp-simulcast"/> for examples of RID efault" sectionFormat="of" derivedContent="RFC8853"/> for examples of RID used
used
in simulcast scenarios.</t> in simulcast scenarios.</t>
<section anchor="many-bundled-streams-using-many-codecs" numbered="true" t
<section anchor="many-bundled-streams-using-many-codecs" title="Many Bundled Str oc="include" removeInRFC="false" pn="section-11.1">
eams using Many Codecs"> <name slugifiedName="name-many-bundled-streams-using-">Many Bundled Stre
ams Using Many Codecs</name>
<t>In this scenario, the offerer supports the Opus, G.722, G.711 and DTMF audio <t indent="0" pn="section-11.1-1">In this scenario, the offerer supports
codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP) and the Opus, G.722, G.711, and DTMF audio
codecs and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP), and
H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send 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 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 at max resolution and 6 recvonly at smaller resolutions), all bundled on the
same port, using 3 different resolutions. The resolutions include:</t> same port, using 3 different resolutions. The resolutions include:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<t><list style="symbols"> 1.1-2">
<t>1 receive stream of 720p resolution is offered for the active speaker.</t> <li pn="section-11.1-2.1">1 receive stream of 720p resolution is offer
<t>2 receive streams of 360p resolution are offered for the prior 2 active ed for the active speaker.</li>
speakers.</t> <li pn="section-11.1-2.2">2 receive streams of 360p resolution are off
<t>4 receive streams of 180p resolution are offered for others in the call.</t ered for the prior 2 active
> speakers.</li>
</list></t> <li pn="section-11.1-2.3">4 receive streams of 180p resolution are off
ered for others in the call.</li>
<t>NOTE: The SDP given below skips a few lines to keep the example short and </ul>
focused, as indicated by either the “…” or the comments inserted.</t> <t indent="0" pn="section-11.1-3">NOTE: The SDP given below skips a few
lines to
<t>The offer for this scenario is shown below.</t> keep the example short and focused, as indicated by either the "..."
or the comments inserted.</t>
<figure><artwork><![CDATA[ <t indent="0" pn="section-11.1-4">The offer for this scenario is shown
below.</t>
<sourcecode type="sdp" markers="false" pn="section-11.1-5">
... ...
m=audio 10000 RTP/SAVPF 96 9 8 0 123 m=audio 10000 RTP/SAVPF 96 9 8 0 123
a=rtpmap:96 OPUS/48000 a=rtpmap:96 OPUS/48000
a=rtpmap:9 G722/8000 a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:123 telephone-event/8000 a=rtpmap:123 telephone-event/8000
a=mid:a1 a=mid:a1
... ...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
skipping to change at line 906 skipping to change at line 1002
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
a=recvonly a=recvonly
a=mid:v4 (small resolution) a=mid:v4 (small resolution)
a=rid:4 recv max-width=320;max-height=180;max-fps=15 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 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=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)...
... ...
</sourcecode>
]]></artwork></figure> </section>
<section anchor="scalable-layers" numbered="true" toc="include" removeInRF
</section> C="false" pn="section-11.2">
<section anchor="scalable-layers" title="Scalable Layers"> <name slugifiedName="name-scalable-layers">Scalable Layers</name>
<t indent="0" pn="section-11.2-1">Adding scalable layers to a session wi
<t>Adding scalable layers to a session within a multiparty conference gives a thin a multiparty conference gives a
selective forwarding unit (SFU) further flexibility to selectively forward selective forwarding unit (SFU) further flexibility to selectively forward
packets from a source that best match the bandwidth and capabilities of packets from a source that best match the bandwidth and capabilities of
diverse receivers. Scalable encodings have dependencies between layers, unlike diverse receivers. Scalable encodings have dependencies between layers, unlike
independent simulcast streams. RIDs can be used to express these dependencies independent simulcast streams. RIDs can be used to express these dependencies
using the “depend” restriction. In the example below, the highest resolution is using the "depend" restriction. In the example below, the highest resolution is
offered to be sent as 2 scalable temporal layers (using MRST). offered to be sent as 2 scalable temporal layers (using
See <xref target="I-D.ietf-mmusic-sdp-simulcast"/> for additional detail about s Multiple RTP Streams on a Single Media Transport (MRST)).
imulcast usage.</t> See <xref target="RFC8853" format="default" sectionFormat="of" derivedContent="R
FC8853"/> for additional detail about simulcast usage.</t>
<figure><artwork><![CDATA[ <sourcecode type="sdp" markers="false" pn="section-11.2-2">
Offer: Offer:
... ...
m=audio ...same as previous example ... m=audio ...same as previous example ...
... ...
m=video ...same as previous example ... m=video ...same as previous example ...
...same rtpmap/fmtp as previous example ... ...same rtpmap/fmtp as previous example ...
a=sendrecv a=sendrecv
a=mid:v1 (max resolution) a=mid:v1 (max resolution)
a=rid:0 send max-width=1280;max-height=720;max-fps=15 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: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: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: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=rid:6 send max-width=320;max-height=180;max-fps=15
a=simulcast: send rid=0;1;5;6 recv rid=2 a=simulcast: send rid=0;1;5;6 recv rid=2
... ...
...same m=video sections as previous example for mid:v2-v7... ...same m=video sections as previous example for mid:v2-v7...
... ...
</sourcecode>
]]></artwork></figure> </section>
</section>
</section> <section anchor="sec-iana" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-12">
<section anchor="sec-iana" title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-12-1">This specification updates <xref target="R
<t>This specification updates <xref target="RFC4855"/> to give additional guidan FC4855" format="default" sectionFormat="of" derivedContent="RFC4855"/>
ce on choice to give additional guidance on choice of Format Parameter (fmtp) names
of Format Parameter (fmtp) names, and on their relation to RID restrictions.</t> and their relation to RID restrictions.</t>
<section anchor="new-sdp-media-level-attribute" numbered="true" toc="inclu
<section anchor="new-sdp-media-level-attribute" title="New SDP Media-Level attri de" removeInRFC="false" pn="section-12.1">
bute"> <name slugifiedName="name-new-sdp-media-level-attribu">New SDP Media-Lev
el Attribute</name>
<t>This document defines “rid” as SDP media-level attribute. This attribute must <t indent="0" pn="section-12.1-1">This document defines "rid" as an SDP
be registered by IANA under “Session Description Protocol (SDP) Parameters” media-level attribute. This
under “att-field (media level only)”.</t> attribute has been registered by IANA under "Session Description Protocol
(SDP) Parameters" under "att-field (media level only)".</t>
<t>The “rid” attribute is used to identify properties of RTP stream with in <t indent="0" pn="section-12.1-2">The "rid" attribute is used to identif
an RTP Session. Its format is defined in <xref target="sec-abnf"/>.</t> y the properties of an RTP
stream within an RTP session. Its format is defined in <xref target="sec-
<t>The formal registration information for this attribute follows.</t> abnf" format="default" sectionFormat="of" derivedContent="Section 10"/>.</t>
<t indent="0" pn="section-12.1-3">The formal registration information fo
<figure><artwork><![CDATA[ r this attribute follows.</t>
Contact name, email address, and telephone number <dl newline="true" indent="3" spacing="normal" pn="section-12.1-4">
<dt pn="section-12.1-4.1">
IETF MMUSIC Working Group Contact name, email address, and telephone number
mmusic@ietf.org </dt>
+1 510 492 4080 <dd pn="section-12.1-4.2">
<artwork align="left" pn="section-12.1-4.2.1">
Attribute name (as it will appear in SDP) IETF MMUSIC Working Group
mmusic@ietf.org
rid +1 510 492 4080
</artwork>
Long-form attribute name in English </dd>
<dt pn="section-12.1-4.3">
Restriction Identifier Attribute name (as it will appear in SDP)
</dt>
Type of attribute (session level, media level, or both) <dd pn="section-12.1-4.4">
rid
Media Level </dd>
<dt pn="section-12.1-4.5">
Whether the attribute value is subject to the charset attribute Long-form attribute name in English
</dt>
The attribute is not dependent on charset. <dd pn="section-12.1-4.6">
Restriction Identifier
A one-paragraph explanation of the purpose of the attribute </dd>
<dt pn="section-12.1-4.7">
The "rid" SDP attribute is used to to unambiguously identify Type of attribute (session level, media level, or both)
the RTP Streams within an RTP Session and restrict the </dt>
streams' payload format parameters in a codec-agnostic way <dd pn="section-12.1-4.8">
beyond what is provided with the regular Payload Types. Media Level
</dd>
A specification of appropriate attribute values for this attribute <dt pn="section-12.1-4.9">
Whether the attribute value is subject to the charset attribute
Valid values are defined by the ABNF in [RFCXXXXX] </dt>
<dd pn="section-12.1-4.10">
Multiplexing (Mux) Category The attribute is not dependent on charset.
</dd>
SPECIAL <dt pn="section-12.1-4.11">
]]></artwork></figure> A one-paragraph explanation of the purpose of the attribute
</dt>
</section> <dd pn="section-12.1-4.12">
<section anchor="sec-iana_rid" title="Registry for RID-Level Parameters"> The "rid" SDP attribute is used to unambiguously identify
the RTP streams within an RTP session and restrict the
<t>This specification creates a new IANA registry named “rid attribute parameter streams' payload format parameters in a codec-agnostic way
s” beyond what is provided with the regular payload types.
within the SDP parameters registry. The “a=rid” restrictions MUST be </dd>
<dt pn="section-12.1-4.13">
A specification of appropriate attribute values for this attribute
</dt>
<dd pn="section-12.1-4.14">
Valid values are defined by the ABNF in RFC 8851
</dd>
<dt pn="section-12.1-4.15">
Multiplexing (Mux) Category
</dt>
<dd pn="section-12.1-4.16">
SPECIAL
</dd>
</dl>
</section>
<section anchor="sec-iana_rid" numbered="true" toc="include" removeInRFC="
false" pn="section-12.2">
<name slugifiedName="name-registry-for-rid-level-para">Registry for RID-
Level Parameters</name>
<t indent="0" pn="section-12.2-1">This specification creates a new IANA
registry named "RID Attribute Parameters"
within the SDP parameters registry. The "a=rid" restrictions <bcp14>MUST</bcp14
> be
registered with IANA and documented under the same rules as for SDP registered with IANA and documented under the same rules as for SDP
session-level and media-level attributes as specified in <xref target="RFC4566"/ session-level and media-level attributes as specified in <xref target="RFC4566"
>.</t> format="default" sectionFormat="of" derivedContent="RFC4566"/>.</t>
<t indent="0" pn="section-12.2-2">Parameters for "a=rid" lines that modi
<t>Parameters for “a=rid” lines that modify the nature of encoded media MUST be fy the nature of encoded media <bcp14>MUST</bcp14> be
of the form that the result of applying the modification to the stream results 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 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 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> a subset of what is otherwise allowable, and never expand it.</t>
<t indent="0" pn="section-12.2-3">New restriction registrations are acce
<t>New restriction registrations are accepted according to the “Specification pted according to the "Specification
Required” policy of <xref target="RFC5226"/>. The registration MUST contain the Required" policy of <xref target="RFC8126" format="default" sectionFormat="of" d
RID erivedContent="RFC8126"/>. The registration <bcp14>MUST</bcp14> contain the RID
parameter name and a reference to the corresponding specification. The parameter name and a reference to the corresponding specification. The
specification itself must contain the following information (not all of which specification itself must contain the following information (not all of which
appears in the registry):</t> appears in the registry):</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<t><list style="symbols"> 2.2-4">
<t>restriction name (as it will appear in SDP)</t> <li pn="section-12.2-4.1">restriction name (as it will appear in SDP)<
<t>an explanation of the purpose of the restriction</t> /li>
<t>a specification of appropriate attribute values for this restriction</t> <li pn="section-12.2-4.2">an explanation of the purpose of the restric
<t>an ABNF definition of the restriction</t> tion</li>
</list></t> <li pn="section-12.2-4.3">a specification of appropriate attribute val
ues for this restriction</li>
<t>The initial set of “a=rid” restriction names, with definitions in <li pn="section-12.2-4.4">an ABNF definition of the restriction</li>
<xref target="sec-rid_level_restrictions"/> of this document, is given below:</t </ul>
> <t indent="0" pn="section-12.2-5">The initial set of "a=rid" restriction
names, with definitions in
<figure><artwork><![CDATA[ <xref target="sec-rid_level_restrictions" format="default" sectionFormat="of" de
RID Parameter Name Reference rivedContent="Section 5"/> of this document,
------------------ --------- is given below:</t>
max-width [RFCXXXX] <table anchor="RID-params" align="center" pn="table-1">
max-height [RFCXXXX] <name slugifiedName="name-arid-restriction-names">"a=rid" restriction
max-fps [RFCXXXX] names</name>
max-fs [RFCXXXX] <thead>
max-br [RFCXXXX] <tr>
max-pps [RFCXXXX] <th align="left" colspan="1" rowspan="1">RID Parameter Name</th>
max-bpp [RFCXXXX] <th align="left" colspan="1" rowspan="1">Reference</th>
depend [RFCXXXX] </tr>
</thead>
]]></artwork></figure> <tbody>
<tr>
<t>It is conceivable that a future document wants to define a RID-level <td align="left" colspan="1" rowspan="1">pt</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-width</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-height</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-fps</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-fs</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-br</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-pps</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">max-bpp</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">depend</td>
<td align="left" colspan="1" rowspan="1">RFC 8851</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-12.2-7">It is conceivable that a future docume
nt will want to define RID-level
restrictions that contain string values. These extensions need to take care to 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 conform to the ABNF defined for rid-param-other. In particular, this means
that such extensions will need to define escaping mechanisms if they that such extensions will need to define escaping mechanisms if they
want to allow semicolons, unprintable characters, or byte values want to allow semicolons, unprintable characters, or byte values
greater than 127 in the string.</t> greater than 127 in the string.</t>
</section>
</section> </section>
</section> <section anchor="security-considerations" numbered="true" toc="include" remo
<section anchor="security-considerations" title="Security Considerations"> veInRFC="false" pn="section-13">
<name slugifiedName="name-security-considerations">Security Considerations
<t>As with most SDP parameters, a failure to provide integrity protection over </name>
the “a=rid” attributes provides attackers a way to modify the session in <t indent="0" pn="section-13-1">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. This could result in an implementation sending potentially unwanted ways. This could result in an implementation sending
greater amounts of data than a recipient wishes to receive. In general, greater amounts of data than a recipient wishes to receive. In general,
however, since the “a=rid” attribute can only restrict a stream to be a subset however, since the "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 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 stream that is of higher bandwidth than would be sent to an implementation
that does not support this mechanism.</t> that does not support this mechanism.</t>
<t indent="0" pn="section-13-2">The actual identifiers used for RIDs are e
<t>The actual identifiers used for RIDs are expected to be opaque. As such, they xpected to be opaque. As such, they
are not expected to contain information that would be sensitive, were it are not expected to contain information that would be sensitive, were it
observed by third-parties.</t> observed by third parties.</t>
</section>
</section>
<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>
</section>
</middle> </middle>
<back> <back>
<references pn="section-14">
<references title='Normative References'> <name slugifiedName="name-references">References</name>
<references pn="section-14.1">
<reference anchor="I-D.ietf-avtext-rid"> <name slugifiedName="name-normative-references">Normative References</na
<front> me>
<title>RTP Stream Identifier Source Description (SDES)</title> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<author initials='A' surname='Roach' fullname='Adam Roach'> <front>
<organization /> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
</author> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <date year="1997" month="March"/>
<abstract>
<author initials='P' surname='Thatcher' fullname='Peter Thatcher'> <t indent="0">In many standards track documents several words are
<organization /> used to signify the requirements in the specification. These words are often ca
</author> pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
<date month='October' day='6' year='2016' /> e Internet Community, and requests discussion and suggestions for improvements.<
/t>
<abstract><t>This document defines and registers two new RTCP Stream Identifier </abstract>
Source Description (SDES) items. One, named RtpStreamId, is used for unique ide </front>
ntification of RTP streams. The other, RepairedRtpStreamId, can be used to iden <seriesInfo name="BCP" value="14"/>
tify which stream a redundancy RTP stream is to be used to repair.</t></abstract <seriesInfo name="RFC" value="2119"/>
> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
</front> <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
264" quoteTitle="true" derivedAnchor="RFC3264">
<seriesInfo name='Internet-Draft' value='draft-ietf-avtext-rid-09' /> <front>
<format type='TXT' <title>An Offer/Answer Model with Session Description Protocol (SDP)
target='http://www.ietf.org/internet-drafts/draft-ietf-avtext-rid-09.txt </title>
' /> <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<front> ">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <organization showOnFrontPage="true"/>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ </author>
author> <date year="2002" month="June"/>
<date year='1997' month='March' /> <abstract>
<abstract><t>In many standards track documents several words are used to signify <t indent="0">This document defines a mechanism by which two entit
the requirements in the specification. These words are often capitalized. This ies can make use of the Session Description Protocol (SDP) to arrive at a common
document defines these words as they should be interpreted in IETF documents. view of a multimedia session between them. In the model, one participant offer
This document specifies an Internet Best Current Practices for the Internet Comm s the other a description of the desired session from their perspective, and the
unity, and requests discussion and suggestions for improvements.</t></abstract> other participant answers with the desired session from their perspective. Thi
</front> s offer/answer model is most useful in unicast sessions where information from b
<seriesInfo name='BCP' value='14'/> oth participants is needed for the complete view of the session. The offer/answ
<seriesInfo name='RFC' value='2119'/> er model is used by protocols like the Session Initiation Protocol (SIP). [STAN
<seriesInfo name='DOI' value='10.17487/RFC2119'/> DARDS-TRACK]</t>
</reference> </abstract>
</front>
<reference anchor="RFC3264" target='https://www.rfc-editor.org/info/rfc3264'> <seriesInfo name="RFC" value="3264"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC3264"/>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title> </reference>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
/></author> 550" quoteTitle="true" derivedAnchor="RFC3550">
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat <front>
ion /></author> <title>RTP: A Transport Protocol for Real-Time Applications</title>
<date year='2002' month='June' /> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<abstract><t>This document defines a mechanism by which two entities can make us ">
e of the Session Description Protocol (SDP) to arrive at a common view of a mult <organization showOnFrontPage="true"/>
imedia session between them. In the model, one participant offers the other a d </author>
escription of the desired session from their perspective, and the other particip <author initials="S." surname="Casner" fullname="S. Casner">
ant answers with the desired session from their perspective. This offer/answer <organization showOnFrontPage="true"/>
model is most useful in unicast sessions where information from both participant </author>
s is needed for the complete view of the session. The offer/answer model is use <author initials="R." surname="Frederick" fullname="R. Frederick">
d by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t <organization showOnFrontPage="true"/>
></abstract> </author>
</front> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<seriesInfo name='RFC' value='3264'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/> </author>
</reference> <date year="2003" month="July"/>
<abstract>
<reference anchor="RFC3550" target='https://www.rfc-editor.org/info/rfc3550'> <t indent="0">This memorandum describes RTP, the real-time transpo
<front> rt protocol. RTP provides end-to-end network transport functions suitable for a
<title>RTP: A Transport Protocol for Real-Time Applications</title> pplications transmitting real-time data, such as audio, video or simulation data
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat , over multicast or unicast network services. RTP does not address resource res
ion /></author> ervation and does not guarantee quality-of- service for real-time services. The
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></au data transport is augmented by a control protocol (RTCP) to allow monitoring of
thor> the data delivery in a manner scalable to large multicast networks, and to prov
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization ide minimal control and identification functionality. RTP and RTCP are designed
/></author> to be independent of the underlying transport and network layers. The protocol
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /> supports the use of RTP-level translators and mixers. Most of the text in this
</author> memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
<date year='2003' month='July' /> the packet formats on the wire, only changes to the rules and algorithms govern
<abstract><t>This memorandum describes RTP, the real-time transport protocol. R ing how the protocol is used. The biggest change is an enhancement to the scalab
TP provides end-to-end network transport functions suitable for applications tra le timer algorithm for calculating when to send RTCP packets in order to minimiz
nsmitting real-time data, such as audio, video or simulation data, over multicas e transmission in excess of the intended rate when many participants join a sess
t or unicast network services. RTP does not address resource reservation and do ion simultaneously. [STANDARDS-TRACK]</t>
es not guarantee quality-of- service for real-time services. The data transport </abstract>
is augmented by a control protocol (RTCP) to allow monitoring of the data deliv </front>
ery in a manner scalable to large multicast networks, and to provide minimal con <seriesInfo name="STD" value="64"/>
trol and identification functionality. RTP and RTCP are designed to be independ <seriesInfo name="RFC" value="3550"/>
ent of the underlying transport and network layers. The protocol supports the u <seriesInfo name="DOI" value="10.17487/RFC3550"/>
se of RTP-level translators and mixers. Most of the text in this memorandum is i </reference>
dentical to RFC 1889 which it obsoletes. There are no changes in the packet for <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
mats on the wire, only changes to the rules and algorithms governing how the pro 566" quoteTitle="true" derivedAnchor="RFC4566">
tocol is used. The biggest change is an enhancement to the scalable timer algori <front>
thm for calculating when to send RTCP packets in order to minimize transmission <title>SDP: Session Description Protocol</title>
in excess of the intended rate when many participants join a session simultaneou <author initials="M." surname="Handley" fullname="M. Handley">
sly. [STANDARDS-TRACK]</t></abstract> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='STD' value='64'/> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<seriesInfo name='RFC' value='3550'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/> </author>
</reference> <author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
<reference anchor="RFC4566" target='https://www.rfc-editor.org/info/rfc4566'> </author>
<front> <date year="2006" month="July"/>
<title>SDP: Session Description Protocol</title> <abstract>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></ <t indent="0">This memo defines the Session Description Protocol (
author> SDP). SDP is intended for describing multimedia sessions for the purposes of se
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /> ssion announcement, session invitation, and other forms of multimedia session in
</author> itiation. [STANDARDS-TRACK]</t>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></ </abstract>
author> </front>
<date year='2006' month='July' /> <seriesInfo name="RFC" value="4566"/>
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is i <seriesInfo name="DOI" value="10.17487/RFC4566"/>
ntended for describing multimedia sessions for the purposes of session announcem </reference>
ent, session invitation, and other forms of multimedia session initiation. [STA <reference anchor="RFC4855" target="https://www.rfc-editor.org/info/rfc4
NDARDS-TRACK]</t></abstract> 855" quoteTitle="true" derivedAnchor="RFC4855">
</front> <front>
<seriesInfo name='RFC' value='4566'/> <title>Media Type Registration of RTP Payload Formats</title>
<seriesInfo name='DOI' value='10.17487/RFC4566'/> <author initials="S." surname="Casner" fullname="S. Casner">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC4855" target='https://www.rfc-editor.org/info/rfc4855'> <date year="2007" month="February"/>
<front> <abstract>
<title>Media Type Registration of RTP Payload Formats</title> <t indent="0">This document specifies the procedure to register RT
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></au P payload formats as audio, video, or other media subtype names. This is useful
thor> in a text-based format description or control protocol to identify the type of
<date year='2007' month='February' /> an RTP transmission. [STANDARDS-TRACK]</t>
<abstract><t>This document specifies the procedure to register RTP payload forma </abstract>
ts as audio, video, or other media subtype names. This is useful in a text-base </front>
d format description or control protocol to identify the type of an RTP transmis <seriesInfo name="RFC" value="4855"/>
sion. [STANDARDS-TRACK]</t></abstract> <seriesInfo name="DOI" value="10.17487/RFC4855"/>
</front> </reference>
<seriesInfo name='RFC' value='4855'/> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
<seriesInfo name='DOI' value='10.17487/RFC4855'/> 234" quoteTitle="true" derivedAnchor="RFC5234">
</reference> <front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<reference anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'> <author initials="D." surname="Crocker" fullname="D. Crocker" role="
<front> editor">
<title>Augmented BNF for Syntax Specifications: ABNF</title> <organization showOnFrontPage="true"/>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><org </author>
anization /></author> <author initials="P." surname="Overell" fullname="P. Overell">
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<date year='2008' month='January' /> <date year="2008" month="January"/>
<abstract><t>Internet technical specifications often need to define a formal syn <abstract>
tax. Over the years, a modified version of Backus-Naur Form (BNF), called Augme <t indent="0">Internet technical specifications often need to defi
nted BNF (ABNF), has been popular among many Internet specifications. The curre ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF
nt specification documents ABNF. It balances compactness and simplicity with rea ), called Augmented BNF (ABNF), has been popular among many Internet specificati
sonable representational power. The differences between standard BNF and ABNF i ons. The current specification documents ABNF. It balances compactness and simp
nvolve naming rules, repetition, alternatives, order-independence, and value ran licity with reasonable representational power. The differences between standard
ges. This specification also supplies additional rule definitions and encoding BNF and ABNF involve naming rules, repetition, alternatives, order-independence
for a core lexical analyzer of the type common to several Internet specification , and value ranges. This specification also supplies additional rule definition
s. [STANDARDS-TRACK]</t></abstract> s and encoding for a core lexical analyzer of the type common to several Interne
</front> t specifications. [STANDARDS-TRACK]</t>
<seriesInfo name='STD' value='68'/> </abstract>
<seriesInfo name='RFC' value='5234'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC5234'/> <seriesInfo name="STD" value="68"/>
</reference> <seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
<reference anchor="RFC7405" target='https://www.rfc-editor.org/info/rfc7405'> </reference>
<front> <reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7
<title>Case-Sensitive String Support in ABNF</title> 405" quoteTitle="true" derivedAnchor="RFC7405">
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'><organization /></ <front>
author> <title>Case-Sensitive String Support in ABNF</title>
<date year='2014' month='December' /> <author initials="P." surname="Kyzivat" fullname="P. Kyzivat">
<abstract><t>This document extends the base definition of ABNF (Augmented Backus <organization showOnFrontPage="true"/>
-Naur Form) to include a way to specify US-ASCII string literals that are matche </author>
d in a case-sensitive manner.</t></abstract> <date year="2014" month="December"/>
</front> <abstract>
<seriesInfo name='RFC' value='7405'/> <t indent="0">This document extends the base definition of ABNF (A
<seriesInfo name='DOI' value='10.17487/RFC7405'/> ugmented Backus-Naur Form) to include a way to specify US-ASCII string literals
</reference> that are matched in a case-sensitive manner.</t>
</abstract>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> </front>
<front> <seriesInfo name="RFC" value="7405"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <seriesInfo name="DOI" value="10.17487/RFC7405"/>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth </reference>
or> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<date year='2017' month='May' /> 174" quoteTitle="true" derivedAnchor="RFC8174">
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s <front>
pecifications. This document aims to reduce the ambiguity by clarifying that on <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs tle>
tract> <author initials="B." surname="Leiba" fullname="B. Leiba">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='BCP' value='14'/> </author>
<seriesInfo name='RFC' value='8174'/> <date year="2017" month="May"/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/> <abstract>
</reference> <t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
</references> rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
<references title='Informative References'> </abstract>
</front>
<reference anchor="I-D.ietf-mmusic-sdp-bundle-negotiation"> <seriesInfo name="BCP" value="14"/>
<front> <seriesInfo name="RFC" value="8174"/>
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SD <seriesInfo name="DOI" value="10.17487/RFC8174"/>
P)</title> </reference>
<reference anchor="RFC8852" target="https://www.rfc-editor.org/info/rfc8
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'> 852" quoteTitle="true" derivedAnchor="RFC8852">
<organization /> <front>
</author> <title>RTP Stream Identifier Source Description (SDES)</title>
<author initials="A.B." surname="Roach" fullname="Adam Roach"/>
<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
<organization /> "/>
</author> <author initials="P" surname="Thatcher" fullname="Peter Thatcher"/>
<date month="January" year="2021"/>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'> </front>
<organization /> <seriesInfo name="RFC" value="8852"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC8852"/>
</reference>
<date month='December' day='14' year='2018' /> </references>
<references pn="section-14.2">
<abstract><t>This specification defines a new Session Description Protocol (SDP) <name slugifiedName="name-informative-references">Informative References
Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP </name>
Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) f <reference anchor="H264" target="https://www.itu.int/rec/T-REC-H.264" qu
or sending and receiving media described by multiple SDP media descriptions ("m= oteTitle="true" derivedAnchor="H264">
" sections). Such transport is referred to as a BUNDLE transport, and the media <front>
is referred to as bundled media. The "m=" sections that use the BUNDLE transpo <title>Advanced video coding for generic audiovisual services</title
rt form a BUNDLE group. This specification updates RFC 3264, to also allow assi >
gning a zero port value to a "m=" section in cases where the media described by <seriesInfo name="ITU-T Recommendation" value="H.264"/>
the "m=" section is not disabled or rejected. This specification updates RFC 58 <author>
88, to also allow an SDP 'group' attribute to contain an identification-tag that <organization showOnFrontPage="true">International Telecommunicati
identifies a "m=" section with the port set to zero. This specification define on Union</organization>
s a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP </author>
header extension that can be used to correlate bundled RTP/RTCP packets with th <date year="2019" month="June"/>
eir appropriate "m=" section. This specification updates RFC 7941, by adding an </front>
exception, for the MID RTP header extension, to the requirement regarding prote </reference>
ction of an SDES RTP header extension carrying an SDES item for the MID RTP head <reference anchor="RFC2198" target="https://www.rfc-editor.org/info/rfc2
er extension.</t></abstract> 198" quoteTitle="true" derivedAnchor="RFC2198">
<front>
</front> <title>RTP Payload for Redundant Audio Data</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-bundle-negotiatio <organization showOnFrontPage="true"/>
n-54' /> </author>
<format type='TXT' <author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle <organization showOnFrontPage="true"/>
-negotiation-54.txt' /> </author>
</reference> <author initials="O." surname="Hodson" fullname="O. Hodson">
<organization showOnFrontPage="true"/>
<reference anchor="I-D.ietf-mmusic-sdp-simulcast"> </author>
<front> <author initials="V." surname="Hardman" fullname="V. Hardman">
<title>Using Simulcast in SDP and RTP Sessions</title> <organization showOnFrontPage="true"/>
</author>
<author initials='B' surname='Burman' fullname='Bo Burman'> <author initials="M." surname="Handley" fullname="M. Handley">
<organization /> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J.C." surname="Bolot" fullname="J.C. Bolot">
<author initials='M' surname='Westerlund' fullname='Magnus Westerlund'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <author initials="A." surname="Vega-Garcia" fullname="A. Vega-Garcia
">
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <author initials="S." surname="Fosse-Parisis" fullname="S. Fosse-Par
isis">
<author initials='M' surname='Zanaty' fullname='Mo Zanaty'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <date year="1997" month="September"/>
<abstract>
<date month='June' day='27' year='2018' /> <t indent="0">This document describes a payload format for use wit
h the real-time transport protocol (RTP), version 2, for encoding redundant audi
<abstract><t>In some application scenarios it may be desirable to send multiple o data. [STANDARDS-TRACK]</t>
differently encoded versions of the same media source in different RTP streams. </abstract>
This is called simulcast. This document describes how to accomplish simulcast </front>
in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP ide <seriesInfo name="RFC" value="2198"/>
ntification method to identify RTP streams belonging to the same media source, a <seriesInfo name="DOI" value="10.17487/RFC2198"/>
nd makes an extension to SDP to relate those RTP streams as being different simu </reference>
lcast formats of that media source. The SDP extension consists of a new media l <reference anchor="RFC4588" target="https://www.rfc-editor.org/info/rfc4
evel SDP attribute that expresses capability to send and/or receive simulcast RT 588" quoteTitle="true" derivedAnchor="RFC4588">
P streams.</t></abstract> <front>
<title>RTP Retransmission Payload Format</title>
</front> <author initials="J." surname="Rey" fullname="J. Rey">
<organization showOnFrontPage="true"/>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-simulcast-13' /> </author>
<format type='TXT' <author initials="D." surname="Leon" fullname="D. Leon">
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-simulc <organization showOnFrontPage="true"/>
ast-13.txt' /> </author>
</reference> <author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
<organization showOnFrontPage="true"/>
<reference anchor="I-D.ietf-payload-flexible-fec-scheme"> </author>
<front> <author initials="V." surname="Varsa" fullname="V. Varsa">
<title>RTP Payload Format for Flexible Forward Error Correction (FEC)</title> <organization showOnFrontPage="true"/>
</author>
<author initials='M' surname='Zanaty' fullname='Mo Zanaty'> <author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
<organization /> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2006" month="July"/>
<author initials='V' surname='Singh' fullname='Varun Singh'> <abstract>
<organization /> <t indent="0">RTP retransmission is an effective packet loss recov
</author> ery technique for real-time applications with relaxed delay bounds. This docume
nt describes an RTP payload format for performing retransmissions. Retransmitted
<author initials='A' surname='Begen' fullname='Ali Begen'> RTP packets are sent in a separate stream from the original RTP stream. It is
<organization /> assumed that feedback from receivers to senders is available. In particular, it
</author> 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 avail
<author initials='G' surname='Mandyam' fullname='Giridhar Mandyam'> able in this memo. [STANDARDS-TRACK]</t>
<organization /> </abstract>
</author> </front>
<seriesInfo name="RFC" value="4588"/>
<date month='December' day='11' year='2018' /> <seriesInfo name="DOI" value="10.17487/RFC4588"/>
</reference>
<abstract><t>This document defines new RTP payload formats for the Forward Error <reference anchor="RFC5109" target="https://www.rfc-editor.org/info/rfc5
Correction (FEC) packets that are generated by the non-interleaved and interlea 109" quoteTitle="true" derivedAnchor="RFC5109">
ved parity codes from source media encapsulated in RTP. These parity codes are s <front>
ystematic codes, where a number of FEC repair packets are generated from a set o <title>RTP Payload Format for Generic Forward Error Correction</titl
f source packets from one or more source RTP streams. These FEC repair packets e>
are sent in a redundancy RTP stream separate from the source RTP stream(s) that <author initials="A." surname="Li" fullname="A. Li" role="editor">
carries the source packets. RTP source packets that were lost in transmission c <organization showOnFrontPage="true"/>
an be reconstructed using the source and repair packets that were received. The </author>
non-interleaved and interleaved parity codes which are defined in this specific <date year="2007" month="December"/>
ation offer a good protection against random and bursty packet losses, respectiv <abstract>
ely, at a cost of decent complexity. The RTP payload formats that are defined i <t indent="0">This document specifies a payload format for generic
n this document address scalability issues experienced with the earlier specific Forward Error Correction (FEC) for media data encapsulated in RTP. It is based
ations, and offer several improvements. Due to these changes, the new payload f on the exclusive-or (parity) operation. The payload format described in this d
ormats are not backward compatible with earlier specifications, but endpoints th ocument allows end systems to apply protection using various protection lengths
at do not implement this specification can still work by simply ignoring the FEC and levels, in addition to using various protection group sizes to adapt to diff
repair packets.</t></abstract> erent media and channel characteristics. It enables complete recovery of the pro
tected packets or partial recovery of the critical parts of the payload dependin
</front> g on the packet loss situation. This scheme is completely compatible with non-F
EC-capable hosts, so the receivers in a multicast group that do not implement FE
<seriesInfo name='Internet-Draft' value='draft-ietf-payload-flexible-fec-scheme- C can still work by simply ignoring the protection data. This specification obs
13' /> oletes RFC 2733 and RFC 3009. The FEC specified in this document is not backwar
<format type='TXT' d compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]</t>
target='http://www.ietf.org/internet-drafts/draft-ietf-payload-flexible- </abstract>
fec-scheme-13.txt' /> </front>
<format type='PDF' <seriesInfo name="RFC" value="5109"/>
target='http://www.ietf.org/internet-drafts/draft-ietf-payload-flexible- <seriesInfo name="DOI" value="10.17487/RFC5109"/>
fec-scheme-13.pdf' /> </reference>
</reference> <reference anchor="RFC6184" target="https://www.rfc-editor.org/info/rfc6
184" quoteTitle="true" derivedAnchor="RFC6184">
<reference anchor="RFC2198" target='https://www.rfc-editor.org/info/rfc2198'> <front>
<front> <title>RTP Payload Format for H.264 Video</title>
<title>RTP Payload for Redundant Audio Data</title> <author initials="Y.-K." surname="Wang" fullname="Y.-K. Wang">
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /> <author initials="R." surname="Even" fullname="R. Even">
</author> <organization showOnFrontPage="true"/>
<author initials='O.' surname='Hodson' fullname='O. Hodson'><organization /></au </author>
thor> <author initials="T." surname="Kristensen" fullname="T. Kristensen">
<author initials='V.' surname='Hardman' fullname='V. Hardman'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></ <author initials="R." surname="Jesup" fullname="R. Jesup">
author> <organization showOnFrontPage="true"/>
<author initials='J.C.' surname='Bolot' fullname='J.C. Bolot'><organization /></ </author>
author> <date year="2011" month="May"/>
<author initials='A.' surname='Vega-Garcia' fullname='A. Vega-Garcia'><organizat <abstract>
ion /></author> <t indent="0">This memo describes an RTP Payload format for the IT
<author initials='S.' surname='Fosse-Parisis' fullname='S. Fosse-Parisis'><organ U-T Recommendation H.264 video codec and the technically identical ISO/IEC Inter
ization /></author> national Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC
<date year='1997' month='September' /> ) extension and the Multiview Video Coding extension, for which the RTP payload
<abstract><t>This document describes a payload format for use with the real-time formats are defined elsewhere. The RTP payload format allows for packetization o
transport protocol (RTP), version 2, for encoding redundant audio data. [STANDA f one or more Network Abstraction Layer Units (NALUs), produced by an H.264 vide
RDS-TRACK]</t></abstract> o encoder, in each RTP payload. The payload format has wide applicability, as i
</front> t supports applications from simple low bitrate conversational usage, to Interne
<seriesInfo name='RFC' value='2198'/> t video streaming with interleaved transmission, to high bitrate video-on-demand
<seriesInfo name='DOI' value='10.17487/RFC2198'/> .</t>
</reference> <t indent="0">This memo obsoletes RFC 3984. Changes from RFC 3984
are summarized in Section 14. Issues on backward compatibility to RFC 3984 are
<reference anchor="RFC4588" target='https://www.rfc-editor.org/info/rfc4588'> discussed in Section 15. [STANDARDS-TRACK]</t>
<front> </abstract>
<title>RTP Retransmission Payload Format</title> </front>
<author initials='J.' surname='Rey' fullname='J. Rey'><organization /></author> <seriesInfo name="RFC" value="6184"/>
<author initials='D.' surname='Leon' fullname='D. Leon'><organization /></author <seriesInfo name="DOI" value="10.17487/RFC6184"/>
> </reference>
<author initials='A.' surname='Miyazaki' fullname='A. Miyazaki'><organization /> <reference anchor="RFC6236" target="https://www.rfc-editor.org/info/rfc6
</author> 236" quoteTitle="true" derivedAnchor="RFC6236">
<author initials='V.' surname='Varsa' fullname='V. Varsa'><organization /></auth <front>
or> <title>Negotiation of Generic Image Attributes in the Session Descri
<author initials='R.' surname='Hakenberg' fullname='R. Hakenberg'><organization ption Protocol (SDP)</title>
/></author> <author initials="I." surname="Johansson" fullname="I. Johansson">
<date year='2006' month='July' /> <organization showOnFrontPage="true"/>
<abstract><t>RTP retransmission is an effective packet loss recovery technique f </author>
or real-time applications with relaxed delay bounds. This document describes an <author initials="K." surname="Jung" fullname="K. Jung">
RTP payload format for performing retransmissions. Retransmitted RTP packets ar <organization showOnFrontPage="true"/>
e sent in a separate stream from the original RTP stream. It is assumed that fe </author>
edback from receivers to senders is available. In particular, it is assumed tha <date year="2011" month="May"/>
t Real-time Transport Control Protocol (RTCP) feedback as defined in the extende <abstract>
d RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this me <t indent="0">This document proposes a new generic session setup a
mo. [STANDARDS-TRACK]</t></abstract> ttribute to make it possible to negotiate different image attributes such as ima
</front> ge size. A possible use case is to make it possible for a \%low-end \%hand- hel
<seriesInfo name='RFC' value='4588'/> d terminal to display video without the need to rescale the image, something tha
<seriesInfo name='DOI' value='10.17487/RFC4588'/> t may consume large amounts of memory and processing power. The document also h
</reference> elps to maintain an optimal bitrate for video as only the image size that is des
ired by the receiver is transmitted. [STANDARDS-TRACK]</t>
<reference anchor="RFC5109" target='https://www.rfc-editor.org/info/rfc5109'> </abstract>
<front> </front>
<title>RTP Payload Format for Generic Forward Error Correction</title> <seriesInfo name="RFC" value="6236"/>
<author initials='A.' surname='Li' fullname='A. Li' role='editor'><organization <seriesInfo name="DOI" value="10.17487/RFC6236"/>
/></author> </reference>
<date year='2007' month='December' /> <reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7
<abstract><t>This document specifies a payload format for generic Forward Error 656" quoteTitle="true" derivedAnchor="RFC7656">
Correction (FEC) for media data encapsulated in RTP. It is based on the exclusi <front>
ve-or (parity) operation. The payload format described in this document allows <title>A Taxonomy of Semantics and Mechanisms for Real-Time Transpor
end systems to apply protection using various protection lengths and levels, in t Protocol (RTP) Sources</title>
addition to using various protection group sizes to adapt to different media and <author initials="J." surname="Lennox" fullname="J. Lennox">
channel characteristics. It enables complete recovery of the protected packets <organization showOnFrontPage="true"/>
or partial recovery of the critical parts of the payload depending on the packet </author>
loss situation. This scheme is completely compatible with non-FEC-capable host <author initials="K." surname="Gross" fullname="K. Gross">
s, so the receivers in a multicast group that do not implement FEC can still wor <organization showOnFrontPage="true"/>
k by simply ignoring the protection data. This specification obsoletes RFC 2733 </author>
and RFC 3009. The FEC specified in this document is not backward compatible wi <author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
th RFC 2733 and RFC 3009. [STANDARDS-TRACK]</t></abstract> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='RFC' value='5109'/> <author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
<seriesInfo name='DOI' value='10.17487/RFC5109'/> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="B." surname="Burman" fullname="B. Burman" role="ed
<reference anchor="RFC5226" target='https://www.rfc-editor.org/info/rfc5226'> itor">
<front> <organization showOnFrontPage="true"/>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title> </author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au <date year="2015" month="November"/>
thor> <abstract>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organizatio <t indent="0">The terminology about, and associations among, Real-
n /></author> time Transport Protocol (RTP) sources can be complex and somewhat opaque. This
<date year='2008' month='May' /> document describes a number of existing and proposed properties and relationship
<abstract><t>Many protocols make use of identifiers consisting of constants and s among RTP sources and defines common terminology for discussing protocol entit
other well-known values. Even after a protocol has been defined and deployment ies and their relationships.</t>
has begun, new values may need to be assigned (e.g., for a new option type in DH </abstract>
CP, or a new encryption or authentication transform for IPsec). To ensure that </front>
such quantities have consistent values and interpretations across all implementa <seriesInfo name="RFC" value="7656"/>
tions, their assignment must be administered by a central authority. For IETF p <seriesInfo name="DOI" value="10.17487/RFC7656"/>
rotocols, that role is provided by the Internet Assigned Numbers Authority (IANA </reference>
).</t><t>In order for IANA to manage a given namespace prudently, it needs guide <reference anchor="RFC7741" target="https://www.rfc-editor.org/info/rfc7
lines describing the conditions under which new values can be assigned or when m 741" quoteTitle="true" derivedAnchor="RFC7741">
odifications to existing values can be made. If IANA is expected to play a role <front>
in the management of a namespace, IANA must be given clear and concise instruct <title>RTP Payload Format for VP8 Video</title>
ions describing that role. This document discusses issues that should be consid <author initials="P." surname="Westin" fullname="P. Westin">
ered in formulating a policy for assigning values to a namespace and provides gu <organization showOnFrontPage="true"/>
idelines for authors on the specific text that must be included in documents tha </author>
t place demands on IANA.</t><t>This document obsoletes RFC 2434. This document <author initials="H." surname="Lundin" fullname="H. Lundin">
specifies an Internet Best Current Practices for the Internet Community, and re <organization showOnFrontPage="true"/>
quests discussion and suggestions for improvements.</t></abstract> </author>
</front> <author initials="M." surname="Glover" fullname="M. Glover">
<seriesInfo name='RFC' value='5226'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/> </author>
</reference> <author initials="J." surname="Uberti" fullname="J. Uberti">
<organization showOnFrontPage="true"/>
<reference anchor="RFC6184" target='https://www.rfc-editor.org/info/rfc6184'> </author>
<front> <author initials="F." surname="Galligan" fullname="F. Galligan">
<title>RTP Payload Format for H.264 Video</title> <organization showOnFrontPage="true"/>
<author initials='Y.-K.' surname='Wang' fullname='Y.-K. Wang'><organization /></ </author>
author> <date year="2016" month="March"/>
<author initials='R.' surname='Even' fullname='R. Even'><organization /></author <abstract>
> <t indent="0">This memo describes an RTP payload format for the VP
<author initials='T.' surname='Kristensen' fullname='T. Kristensen'><organizatio 8 video codec. The payload format has wide applicability, as it supports applica
n /></author> tions from low-bitrate peer-to-peer usage to high-bitrate video conferences.</t>
<author initials='R.' surname='Jesup' fullname='R. Jesup'><organization /></auth </abstract>
or> </front>
<date year='2011' month='May' /> <seriesInfo name="RFC" value="7741"/>
<abstract><t>This memo describes an RTP Payload format for the ITU-T Recommendat <seriesInfo name="DOI" value="10.17487/RFC7741"/>
ion H.264 video codec and the technically identical ISO/IEC International Standa </reference>
rd 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
the Multiview Video Coding extension, for which the RTP payload formats are def 126" quoteTitle="true" derivedAnchor="RFC8126">
ined elsewhere. The RTP payload format allows for packetization of one or more N <front>
etwork Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in e <title>Guidelines for Writing an IANA Considerations Section in RFCs
ach RTP payload. The payload format has wide applicability, as it supports appl </title>
ications from simple low bitrate conversational usage, to Internet video streami <author initials="M." surname="Cotton" fullname="M. Cotton">
ng with interleaved transmission, to high bitrate video-on-demand.</t><t>This me <organization showOnFrontPage="true"/>
mo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Iss </author>
ues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDAR <author initials="B." surname="Leiba" fullname="B. Leiba">
DS-TRACK]</t></abstract> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='RFC' value='6184'/> <author initials="T." surname="Narten" fullname="T. Narten">
<seriesInfo name='DOI' value='10.17487/RFC6184'/> <organization showOnFrontPage="true"/>
</reference> </author>
<date year="2017" month="June"/>
<reference anchor="RFC6236" target='https://www.rfc-editor.org/info/rfc6236'> <abstract>
<front> <t indent="0">Many protocols make use of points of extensibility t
<title>Negotiation of Generic Image Attributes in the Session Description Protoc hat use constants to identify various protocol parameters. To ensure that the v
ol (SDP)</title> alues in these fields do not have conflicting uses and to promote interoperabili
<author initials='I.' surname='Johansson' fullname='I. Johansson'><organization ty, their allocations are often coordinated by a central record keeper. For IET
/></author> F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
<author initials='K.' surname='Jung' fullname='K. Jung'><organization /></author A).</t>
> <t indent="0">To make assignments in a given registry prudently, g
<date year='2011' month='May' /> uidance describing the conditions under which new values should be assigned, as
<abstract><t>This document proposes a new generic session setup attribute to mak well as when and how modifications to existing values can be made, is needed. T
e it possible to negotiate different image attributes such as image size. A pos his document defines a framework for the documentation of these guidelines by sp
sible use case is to make it possible for a \%low-end \%hand- held terminal to d ecification authors, in order to assure that the provided guidance for the IANA
isplay video without the need to rescale the image, something that may consume l Considerations is clear and addresses the various issues that are likely in the
arge amounts of memory and processing power. The document also helps to maintai operation of a registry.</t>
n an optimal bitrate for video as only the image size that is desired by the rec <t indent="0">This is the third edition of this document; it obsol
eiver is transmitted. [STANDARDS-TRACK]</t></abstract> etes RFC 5226.</t>
</front> </abstract>
<seriesInfo name='RFC' value='6236'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC6236'/> <seriesInfo name="BCP" value="26"/>
</reference> <seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
<reference anchor="RFC7656" target='https://www.rfc-editor.org/info/rfc7656'> </reference>
<front> <reference anchor="RFC8285" target="https://www.rfc-editor.org/info/rfc8
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol ( 285" quoteTitle="true" derivedAnchor="RFC8285">
RTP) Sources</title> <front>
<author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></au <title>A General Mechanism for RTP Header Extensions</title>
thor> <author initials="D." surname="Singer" fullname="D. Singer">
<author initials='K.' surname='Gross' fullname='K. Gross'><organization /></auth <organization showOnFrontPage="true"/>
or> </author>
<author initials='S.' surname='Nandakumar' fullname='S. Nandakumar'><organizatio <author initials="H." surname="Desineni" fullname="H. Desineni">
n /></author> <organization showOnFrontPage="true"/>
<author initials='G.' surname='Salgueiro' fullname='G. Salgueiro'><organization </author>
/></author> <author initials="R." surname="Even" fullname="R. Even" role="editor
<author initials='B.' surname='Burman' fullname='B. Burman' role='editor'><organ ">
ization /></author> <organization showOnFrontPage="true"/>
<date year='2015' month='November' /> </author>
<abstract><t>The terminology about, and associations among, Real-time Transport <date year="2017" month="October"/>
Protocol (RTP) sources can be complex and somewhat opaque. This document descri <abstract>
bes a number of existing and proposed properties and relationships among RTP sou <t indent="0">This document provides a general mechanism to use th
rces and defines common terminology for discussing protocol entities and their r e header extension feature of RTP (the Real-time Transport Protocol). It provid
elationships.</t></abstract> es the option to use a small number of small extensions in each RTP packet, wher
</front> e the universe of possible extensions is large and registration is decentralized
<seriesInfo name='RFC' value='7656'/> . The actual extensions in use in a session are signaled in the setup informati
<seriesInfo name='DOI' value='10.17487/RFC7656'/> on for that session. This document obsoletes RFC 5285.</t>
</reference> </abstract>
</front>
<reference anchor="RFC7741" target='https://www.rfc-editor.org/info/rfc7741'> <seriesInfo name="RFC" value="8285"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC8285"/>
<title>RTP Payload Format for VP8 Video</title> </reference>
<author initials='P.' surname='Westin' fullname='P. Westin'><organization /></au <reference anchor="RFC8627" target="https://www.rfc-editor.org/info/rfc8
thor> 627" quoteTitle="true" derivedAnchor="RFC8627">
<author initials='H.' surname='Lundin' fullname='H. Lundin'><organization /></au <front>
thor> <title>RTP Payload Format for Flexible Forward Error Correction (FEC
<author initials='M.' surname='Glover' fullname='M. Glover'><organization /></au )</title>
thor> <author initials="M." surname="Zanaty" fullname="M. Zanaty">
<author initials='J.' surname='Uberti' fullname='J. Uberti'><organization /></au <organization showOnFrontPage="true"/>
thor> </author>
<author initials='F.' surname='Galligan' fullname='F. Galligan'><organization /> <author initials="V." surname="Singh" fullname="V. Singh">
</author> <organization showOnFrontPage="true"/>
<date year='2016' month='March' /> </author>
<abstract><t>This memo describes an RTP payload format for the VP8 video codec. <author initials="A." surname="Begen" fullname="A. Begen">
The payload format has wide applicability, as it supports applications from low- <organization showOnFrontPage="true"/>
bitrate peer-to-peer usage to high-bitrate video conferences.</t></abstract> </author>
</front> <author initials="G." surname="Mandyam" fullname="G. Mandyam">
<seriesInfo name='RFC' value='7741'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC7741'/> </author>
</reference> <date year="2019" month="July"/>
<abstract>
<reference anchor="RFC8285" target='https://www.rfc-editor.org/info/rfc8285'> <t indent="0">This document defines new RTP payload formats for th
<front> e Forward Error Correction (FEC) packets that are generated by the non-interleav
<title>A General Mechanism for RTP Header Extensions</title> ed and interleaved parity codes from source media encapsulated in RTP. These par
<author initials='D.' surname='Singer' fullname='D. Singer'><organization /></au ity codes are systematic codes (Flexible FEC, or "FLEX F
thor> EC"), where a number of FEC repair packets are generated from a set of source pa
<author initials='H.' surname='Desineni' fullname='H. Desineni'><organization /> ckets from one or more source RTP streams. These FEC repair packets are sent in
</author> a redundancy RTP stream separate from the source RTP stream(s) that carries the
<author initials='R.' surname='Even' fullname='R. Even' role='editor'><organizat source packets. RTP source packets that were lost in transmission can be recon
ion /></author> structed using the source and repair packets that were received. The non-interl
<date year='2017' month='October' /> eaved and interleaved parity codes that are defined in this specification offer
<abstract><t>This document provides a general mechanism to use the header extens a good protection against random and bursty packet losses, respectively, at a co
ion feature of RTP (the Real-time Transport Protocol). It provides the option t st of complexity. The RTP payload formats that are defined in this document add
o use a small number of small extensions in each RTP packet, where the universe ress scalability issues experienced with the earlier specifications and offer se
of possible extensions is large and registration is decentralized. The actual e veral improvements. Due to these changes, the new payload formats are not backw
xtensions in use in a session are signaled in the setup information for that ses ard compatible with earlier specifications; however, endpoints that do not imple
sion. This document obsoletes RFC 5285.</t></abstract> ment this specification can still work by simply ignoring the FEC repair packets
</front> .</t>
<seriesInfo name='RFC' value='8285'/> </abstract>
<seriesInfo name='DOI' value='10.17487/RFC8285'/> </front>
</reference> <seriesInfo name="RFC" value="8627"/>
<seriesInfo name="DOI" value="10.17487/RFC8627"/>
<reference anchor="H264" target="http://www.itu.int/rec/T-REC-H.264-201304-I"> </reference>
<front> <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8
<title>Advanced video coding for generic audiovisual services (V9)</title> 843" quoteTitle="true" derivedAnchor="RFC8843">
<author > <front>
<organization>ITU-T Recommendation H.264</organization> <title>Negotiating Media Multiplexing Using the Session Description
</author> Protocol (SDP)</title>
<date year="2014" month="February"/> <author initials="C" surname="Holmberg" fullname="Christer Holmberg"
</front> >
</reference> <organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<reference anchor="RFC8853" target="https://www.rfc-editor.org/info/rfc8
853" quoteTitle="true" derivedAnchor="RFC8853">
<front>
<title>Using Simulcast in Session Description Protocol (SDP) and RTP
Sessions</title>
<author initials="B" surname="Burman" fullname="Bo Burman">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlun
d">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Zanaty" fullname="Mo Zanaty">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8853"/>
<seriesInfo name="DOI" value="10.17487/RFC8853"/>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
<section anchor="contributors" title="Contributors"> C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t>The following individuals have contributed significant text to this document. <t indent="0" pn="section-appendix.a-1">Many thanks to <contact fullname="
</t> Cullen Jennings"/>, <contact fullname="Magnus Westerlund"/>, and <contact fullna
me="Paul Kyzivat"/>
<figure><artwork><![CDATA[ for reviewing. Thanks to <contact fullname="Colin Perkins"/> for input
Peter Thatcher on future payload type handling.</t>
Google </section>
Email: pthatcher@google.com <section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.b">
Mo Zanaty <name slugifiedName="name-contributors">Contributors</name>
Cisco Systems <t indent="0" pn="section-appendix.b-1">The following individuals have con
Email: mzanaty@cisco.com tributed significant text to this document.</t>
<contact fullname="Peter Thatcher">
Suhas Nandakumar <organization showOnFrontPage="true">Google</organization>
Cisco Systems <address>
Email: snandaku@cisco.com <email>pthatcher@google.com</email>
</address>
Bo Burman </contact>
Ericsson <contact fullname="Mo Zanaty">
Email: bo.burman@ericsson.com <organization showOnFrontPage="true">Cisco Systems</organization>
<address>
Byron Campen <email>mzanaty@cisco.com</email>
Mozilla </address>
Email: bcampen@mozilla.com </contact>
]]></artwork></figure> <contact fullname="Suhas Nandakumar">
<organization showOnFrontPage="true">Cisco Systems</organization>
</section> <address>
<email>snandaku@cisco.com</email>
</address>
</contact>
<contact fullname="Bo Burman">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<email>bo.burman@ericsson.com</email>
</address>
</contact>
<contact fullname="Byron Campen">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>bcampen@mozilla.com</email>
</address>
</contact>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="A.B." surname="Roach" fullname="Adam Roach" role="editor
">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>adam@nostrum.com</email>
</address>
</author>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIABVkLVwAA+19aXMbR7Lg9/oVFXC8HdILgARFUiRlOkxdNvdZElek7Lc7
4VA0gAbZI6Ab0wdJ2KH97ZtnHY2GSPm9iNmJWUV4BuzuurLyzqyswWBg6qye
pye29/7qwl4kq3mRTO3rolwktX2fVnWZTeqsyKueScbjMr2VL+NX02KSJwvo
xU7LZFYPsrSeDRaLpsomgzKbDkYHZprU8H5vd3Q02D3ABxN4cF2UqxNb1VOT
LcsTW5dNVe/t7h7v7plmiS2qE7t/dHBgTFUn+fRjMi9y6GWVVmaZndi/1sWk
b6uirMt0VsGv1QJ//GZM0tQ3RXliBsbCvyyHfs6Gz4f2fZFMbuzWq2lWF+U2
veSJn02TBb+lh0V5fWLfFL9n83lCD9JFks1PbAKf/ZAXsPZmMZwUC2NyAlV2
m57Ad+eDl0Nae3Jbp/c1rh0fv3/9Ym80OpafT/YO9/XnwcGu/Nw/ODzUn7Bi
+Xmw90S/fbq/q0+PRk/hqcnyWefgAvhquhyMm3w6Twc5QLrOEtytTV9W2aKZ
T5Kqjj5YMkIMZvP0PhtDT7MUPp/cpIvULez4yC3hSH8ejHaP3RL2dGGHoyNd
zeHeE3369PDA/Xy6P9I17h3BcuH3TwIuaxVTz6a3ST5Jp/Y2m6aFnRTTLL+2
AAt7neYpYKVNmmlW3GZVk8xtlZa32SSt7NYvx9s96ohx8XU6LpukXCFS7tNz
xRprHQ6cX30YXAG2w14v0nxKILQ/DWFOPKWkvE7rE3tT18uTnZ27u7thVjfD
LK93ynSyczV4/+rFgD4fwChPdvcH58aYwWBgkzEgUTKpjTnPbX2TVbZappNs
lk1ojL69S+00nWV5ahM7KwFJ74ryE62SP1zhosuADA3MDEkTnqTJogKsh35T
e5lWFU76ZVpNymxJC7goCyCdYj40Vziy755HrGDIPL2zPcDfnt3qBaNYAHle
wzTTsrdtL19e2KSGd+OmTm1d2AaoaZxdN0VTzVdGvl3RPHBqlzK1uwxWnNuE
J6wzBAp3C6ImspK/WEFDw/gOf+KE67SkRSaIAYCWyTUSJuz+XbKy43RVQHd3
N/A5rHBZFogsUxoZ+zZlet3Mk9KxvKvVMq2GhgESbYUVVqSkieu8BpoDZgBs
BD4AJLtusinipIXPJzdFhr9mRtjohU7Xbs0W9XKbWA6wK1xvQZuUlbDwOY8G
vePao53lbZna8YpRBfhtA+hYDxmXFtkUqNyYb+xVWi6yvJgX1ytcCuwJPKhs
77Joykm4B72+7b3Kp8sCUBV/B/vQ45n1go9NUqa2qWAGSWV1MgD6P/4Q+v38
GaZCfyEf+/yZeqC/kdvB37WfGO5HMq8K7vDuJoW+kyXs0LIEFpUOcR3neV0W
04ZR7o9vKtjeDB995lWFm2a3Lq62LSDknKaEs5bdRjReQM9IKOO0vkvT3GFi
C6NwuvgqqapigrOYEm4v0mmWwIId5QwtDo+vynoJfWPDHSBJ3FfjKAEGFnj1
iWATwhcgu6s+bi/3N05pRFx3WtYZNAKMwSc8aC2YO0nKMmNot+YOgAK+BFgA
iEgMkaiBBGVSTit7kwCO8sBlVhF5AkLdGODzdcaDAHDmguUVYNzfm6xEYFXN
cglCleZOXy/nG+jXEMMR+v3jj8eJoM+f+6b7WyeEAGNgbFgBTgcmrjNK7Bw5
rs2bxRjoqZgx7VfIyNIKOeYCli9rb/I0KQFoUyDJZD5P82sCESIcAA3XAALm
W9pRpTb4lvSgK2ABCRAMAtRzW9yA26TMgLs5BJoU+QwYXslA7GuHzJKUj8Cf
OeoMk7oioNLGCw4zBtLeAV5RB28yACiMB18C8IDNcTcwubhRwAip3bvbtMTX
1HYGq6gQdlk+xT0GoBW1/RtoWDw525q5Bcw1lr4G4iHJ2cmtZbeRVRY2vV96
LgbwJ34CyhaTPmg3yArg+2vAr6d2nAXrBxh7nDY3aQILHYK4L+5SWEZfyRGa
IqfD9QBqI3tXkoYnATXYGnkB40VlYNlt+OI8FZnvg/YkEQoYrURaJLEIukLV
gJ4IzO791YuLbdjkZk6yCdqzyJlniwyxxSNi1zxscgtqYwKKE07DBOQG3CG5
TofA6GwFNIxIVQkvxIUH3RYAg/E85lrx1sEuTNIUsJ5A5kZ0SNwpbQnAMFpW
GRT26VQ4FQpP5BTpEpaLgKdOvaQL5RLuuy47npIhhgr4MQOFERXU+coyuwz4
CCEn7MykKKHXJcjrtkqD7BYmCOTQ4ExhobCeckz8ecxqRZZPoK+KSLVOJzd5
9vcGyBykom6hYyqIAmaerGDZU+Eb+N3dDXBFm4nEiRbrVSmYagC8DYpCrD2h
lIgVN7c0WKaXyEa56tZlygJvbzgajnZD6boNMhlsn2vaS5ISkepV8ZaJ6tTB
Wbp0pDXlbwK7Q1KpaK5viOKSilougGSQCFFZBrMmzatAUYGeArG1rqGhKPQM
jLkctJ0mqz4o8An10UtOUYL2vAgdsqD/AuJ1MCocSrmdqHq0FQb6/ypVdmjf
FqjQogxuK2MIj0WTyyC8AiQipwYXOSA7Wh0kcmdNSbwlUmwD8NAYOHF4D2Sb
VSCvUJNPkH4ZmqR0rEDpIw6OiuI9oPIqnlW2AE7BZMHMbAHEkORZtdiArIvk
E+ANKCm40bGCbs8dZBRPA+vBbF2+fHW5TawR6DddxBphhw0MQgBBIWoZ0ztr
u6atl10kk0+pcGtWjAWj4smrbfPyAhZ3VjmVSuaA+iKM+xHMkTuALSgcrDc7
mFgw9DOQM5Udw4B3qC8ZxHPofZzNs3rlUJPs+zmhB8x/krJkLps5avDMOlhx
Qn3jU17cwdadmjnxAVgz0BNIsAI4DvMymEKSy65njq54C4kLcxtgvoAjgAnw
J8wYFChkZzj6rJnDhs2IsgBG0Nkd/p6VxUI2vt0tjmXyNOOXXhkA/arIRRhH
qITrgb8De8PBDaD9mhG6z6bAGthBjftYfEzEBED2XjXjihlb1d4G47ZB2IoA
f7w6sVvJtiqAtF629ibzBjAItDlVCQFGMR2oQUWN2JTZGruuGF7UF22LVdYg
O4awEo3P7WckkdA6+Xegxl8L1LGRq7/n7UeIV8y1PsH7O3rfe/Ph8grtK/x/
+/Yd/X7/6n9+OH//6iX+vvzp7Oef3Q8jX1z+9O7Dzy/9L9/yxbs3b169fcmN
4amNHpnem7P/pfbbu4ur83dvz37uMUwCs5H4jSBnDlwIsK0m285EG/oc6Hu0
z2II/Vewp/Qb3U/wG7SVXI1Y4Hj8J8B+hXoOaN4kd2CjJskyq8HgI4ypbhCi
qHkAJAGUSFe6BW9IgvwM+DC3Z46dsvWH1OxY7GdlaCIvVe6q1CVRNJhTR54v
B+ZpX8fsGzJC6yLk6sB7q5TkX4RZBDDW4bhJEoiQacA+QYt9jyIUxQAA4hPg
nSB+4Csh7ouOiFkxnxd34sFagOaZpkJKyTifAZxZL5sxH6KlkkjcBgD+n/if
MbSqk+/Q55pNv7ffTQExafrf278u69PvQMoOQMbU3z/77btgcd+ffnebzJv0
++Gwq9ez3O2Rt4r9WlS6VzG8eKpIc0BJqJWZUF2P9MUQjk4n4EX02LQXTZBm
CXZELtpuKM5FHwnEWNArcDLkRV7d+rKMsyLjSLxtkGlDc97BaUmiik5DEHOy
XnUfYgXCvUhzel8veU7n6HV4dalCNeKt3VOwl6DkmjbH5xFSEqEwI98nodI8
1GsRiTs9HWartzgFvYh6IHM65pQlesR5e2e4OKQLZySTeITezSNkAvKBPwfI
RBZoUJVRTQaEJtjMST5ZRc7QQJfu23R4PaS376/+Q71WR0fsc3j96gV/jC5s
9FQQzEDbEi2p8p407ftBEJkvgOhxYhN31KgThHAG9AOg7enDuGM2qWRsiIPS
uAFmw65BDOHWWLyBbNR0AhyoUQyrWg0LYZ1D84G3qmsNwCRRyRVLWQ3nYAw1
agjozN6Azzq/XTgHIK4S+TAIHdSl7OXl+xdgZeGkwZBElAvp6guhDrC/DDRi
9QosSVEUOhcAa8UFyF71nRVapqjD5BNEB+dTE2RSgKNDrxMkKqRUg0YMQCbY
9mzGe2G4X49RbdTtI1sEUVcrUnYNzywXd2F9BOnHsd61ZpuIhvx1GzoDFQY0
tqZmfRiAuc3EleQRfWHfuCrQJ/oG6IixDXdnbS6eMHhWdxnwQEDIaUaKJShE
pD6jNI59ER3zNufklkVzq6wT9I+QWeaMRXyXO7ELVtYq8BvV5JHHpmBKw6QT
0XdJ/yjXcFmG57iIA9U0qRPSttgEAqQ2gdtaAxwRAEhL7cSs6SpPFkBpcxgY
lfJr0KenTekQInD4WTZglJhvCwqoZDOSKCzayXbrB/M2JQ3bFyGBXfIoTpVn
Zf3hyfZRzV+qMwknUwBw77NF9rtzpI8VniQHJimLcgRfU+uLkJe4ACp+RRNk
apU59mllAf7KAh0tA6zECzXLygqIHj2X5KrA6bvPRYfXFdMYwdCwFsIpE6jy
3vXgPYHUTvuEjWBPeJoTi3MxKXuTXd+YFjCSSY1+Eg5kTR2G0eDqdNpHpxN+
zDr+3tHB58/GRVLAYE9vEd1dpItMH9h19tyGfqESjKxFRkiDnsoKOhC3ICz1
bA5wzhPeRgqHECYJ5aCjrx8iu/dimJjjuz0IWRuRxoLCfxJ+EfZrHsvoxe/U
cxTc09CSqouseHoKX/ee6B7VhWGmxH5K9UtFSnJSermIaCCTF2u9h0pcDyjC
9GC4217LL1XFCrCbE3eb3qMLtyIlYJouoSdYwZxoAPWZHrAfoia0JHEctOLw
N44kvwuZAg0euhs9wzGO4bAKKTqLIjUHwETc9pH/ZtMoKMELM23vXhLMSXjv
M6etBJ/ekWeeNCtgRUCxoDuYWVM3pQQjiO1mi7QfRJQtugCU3eFsgkXikh0E
BBuKpfgge2BD/bd5/cyZUSiKKhRCKI9Ku0CPwsUVixlREoRfIjoaEQEBuw6t
xvNZpO96AwuIqAZNsjJ5gVPo0VryUCv1Y0auVuK3kURDpZ68UyGZyDJxKdjh
72lZuNW0/MZRWHrLe9rI2P4YvgWlKY50xsa0oHBL4AZUREIarUS0iutCnZje
XY16giqisFYw4EElYmbucFIdy7F7l3R6mZtKuk3u6zB+G6ZIYegZkTw3xGJc
EKcf7WG05ofAZTp9xehdgr1FLcWtxlMiuj9ldp1mHEGJ1KdoV2NDxYPCuPBm
R9ipFeMZWh3Zmerq5TJj3O5lSihO4Qf+cH16ZGUq09hW7iuzazsawh1Xswzm
Nxgn+ETi5ih9UDcjDmTEnlAP9cyp8e479EvNOeYhr9RNVhGNkGAjBdpUGF0G
KmCsoH333dDcWRa3kd3TpKgLvXXkYDcQMK9qBcR+j1GrDPNTMPjNCpg6tPJp
5OAKYsDkfSPeL+s1Eecn6TvvGlyNujK9Bh5A8TEiofOzt2d9gDdiBq8K35er
2ONP2RlJnkgSSOC6wl2vvPPqrLlGuEK75yAim2rwNmlKSja0W2fP377eFst7
78k+6B7XsK5FUrqAcS/mipyKsQlV3L7L6g0l5iQlWDvkwu0kUO9q7KDPDT7H
jdTeZv5hiM60UjlAi/NZbMiANobsiD68y3BNl0B/bj4V/yRJRfjh8uQw4old
G+46wA47S6obDuubb1GxHtxl0/qmLwlnQPEcgivmjQZgltl9Oq+IB7KgYdML
YzXEwQ2m0GXq1LEYyQfpD5MODNoFrHqmgVyZ+TSrlnMgvKBxH/pqOVBJ/6tc
EBIn66xNESAkI21ZyAREskFX0/S6TFNSognwJAF51WCNXN/U/yzL5tn+V6x7
thRVjeSrLVE1g8XSXyAN0DRKgf2Dkor0Ks01fCmRSVgdDALUDhCaclPqZ6YN
vCOc7fAAIpHIW2R5tmgQksmiaDj5A3U45+vgaZ2wPR2+QIlQ3xWUb5NOGlRv
5WPozMdSkCbnwFVx+rkd7QgEZI2Vh0oElApNTYcBBBR6IZG9rFI7FBPXcM70
FgZm7ETGzR0pkrm++uJJm9SgklJaIk/aTWRc8ifjrHZ7Q9k00c5cxYJHDAvF
FpgIc0llOqjicgBnWqTML9VGLcCQRcPOp0UEkWVKoUCAbqEjtY+MrG8/vIT/
Ob8gm+EVfpan9bbMCdM2aol8Alg+pSkl8EheCoXPLWfUEA+bpzNApqUieezd
5gmDMozOlyRPUVlJ7ydNSXkZSHxNXamPzPe5xPxDVmmGhMGIKayUgO4+YBDa
CqwTnhmYHndIfjdhOlINJDUPLHLaAVGzFaioCwjVkTLrcA464zwdSSNDAoiU
9R5v9LCnm75UmiQkcfseoF+w846oZETAcA4cTzGpi4xX9vLUhSd4dnpATyh2
VBP20gU6h7UjYE+0jT1FNOLJ2R27xaj9raD0tjNihBcFrJPNrarFAKA3QPtk
PgGsr9EGftmkvPFZFbyhjffbHG2yAyLPDDkHb7mqsJgGuD4TOy7QyQDcFsnM
Cp0tlwxy7ai12Qh0gn/f+klTmgxQGzp/rinxF3PJMcxCVi/hvEc34rvQyQRt
VM86vLWeVNTezgCfyDPLdixBrC9ZLRRZBdScAlbkNKbdHe7u7o4QdvtHw13S
jogfq2Goujm5F5j7c2dkEBAjnBWgjk2z66x2EqYMBAx2BmpDhqoczYnhxjoE
uXJcwjcziihAEmAFt0CrmZU4miH2nkm+0SIBikTFFqGrZikbGZWsTP/0Y4ae
f0zNd/7YtVGRiooSvVaoJZHeTWRGqbg+JM4OMuzrigxEzR0JlN9WWB27CowD
1a4mWcpTopC732kXNw+Ao2ocP0JpEftVwN4Tp+Sa7ufcFJQYgmlXzfhv6YRd
1D791rK5xDmbBq3Gd+gG3zmj1AgJTH0ps0NNcdoY8nd7nXNMfnoKUdPZi7Uw
OnBf9s44K8uglaVHHbrzvZ5ZHxVHS+OjRD/trzfZPI13wThhJn22zKyST4eo
OiyiQIxHPASgBiLstiHN2adKQrcWsw1Rr8PAa2zl3ZAvirN3SIxOOa7gY/bi
yicjSvZCaMU4cLRtKOeC/U8bUSmefSpiJ9N6xD5AbI9znKgR4ckFZkNNYSfV
blL8WDOUGJMqzdiKuwkPCSx9l0gVhgxPnopz+8BkvA/UOR6ExxEV5OQdppwc
RUnOP3CJsCYiKfRBDNAR0tt+xha06LN5iglXICGgwyA3q9VZbpD/lK1YyTn5
wR0yU7Zvn3cgHpwghSpuTi4GzI6RAQ4GdYNBwi05CnASubgwIJCy0wyIBhlK
3z2gyKPBCEh2G33gH3FwkiLo6sFw6c/bmtjmz1HAXviTPbaaFOj8umQXBSqR
xMR4u55/ePvy51cbEvw7DwPYN+cv3Q52BnIZIqy8AOhgmHnadTjjV5zGe+hN
LQvnCJRZOSbeD7LbORjYjqGNgS5pZggk7NNFESkJ7Bv7Ix42S1zs9Fx4nsNw
IYvrNP9IuWhAGK+VCnFx684w4fqSueZ+Qlfo+ZrcFAUf43Baep6abo8eeo0k
iy1ppdrAps4yjqvTEKyVMKc2bQ8nLvU8EJbuHINz6YXjxnNe4FEDcWtRsMJU
dbqsTowZUaiDFJJrBiIGrhwx69GXFqExwFgJ8WkqZs93houIgzOh74j7LthX
TzqaC69oFMI84c4A2i7VkMScnBfwLlZNQ9hq8JAhBk8jPzani+MY4bGAatup
beyekSy5OH40tGcgkKJdwI4mGPzInasukVhKdOxAl9vibwLQPuZi4K5gd2P2
9ztFgCIDtItqtfGmi7yQb11KOU0JfRuUk5vXzziw4YN7zIy1GYrBLbTrtgFb
K2Q16MdgBo09bZGeuQ2mXxK+JQnvOAsQoVgPSx/9Q0u1JCYlGqok7PIZl+DD
JNSxx5pIwnCjpdIe59oNgmPASM2j64FBOvyFOhKQxj7rr+8E4ykqw2Radfvb
o/AJrvuhCIqoVD7pMMYVYuFkLkw5I87lYoR0CTM9cJaZkucdpprLmRFJirWU
bXzLZlWQm+BYCY4UzJDODHnnAfbI/uqa0bOh4Gw6nxHmCUX5jULlVtArSsvP
1xbAAyEjAMOP9DUXTnUWjigGJ7hOThVpxUric4dBNg170xkf3JEt0/Krx5OK
Y5AoQbpiN6YrdtOKLXkWHB1q1FfeuA0YBPDkmWPAjOh3ckKJM9HD9VOwT+Sz
yDYEoq4El2YcXjB78byPeUwrhBj1nOIcvPjXoxYsIs8UsYLU+UgLxK+cM34g
6fq+mXfIayY/LZ0xBlUZitakVf4Xl3HFLozWgWan0prWIWsKsLH6FuUWZZof
Pg3cIWyk8fFKE+qt6/aTU+K99P+su1N5MgyFuQI7Aq/LPoylDjF0shvuMoqI
87YDkW2haUuISAnoUTSS476SoBZFJZZzPCfmRo4UBhAHZ2iWcxZT3xBcFBxt
oCXzu2RV2esGkBxsFOfbdefmaI1GT4yGyluMChsRgeD2EcW1xwXHvwQH4qiM
YwD9lnsLsMehAusmkjeBnmNMHlE3Qd+bT/GCyc/OiDjlHWXt5iqcVJpXTZkG
XpA20CjiN1H/3F06nyNTw72mpJAgzICOJCsBQhB7Rdnv7HCaVRPAUXLv77Vn
c09lByR9mrQil/0Wd4R6L4MIQwY1yStWyXJ0ncdqWZj30Z7wtOFjj2lIbyRj
IxZPXguMT0aaLOni6uvhaIN2x7oANSYRiE4FXTn1Frq8hMxcWgSyIEavIat9
s3UIaN4FKqfL+pTzLpw/KtLsxHsl8ILhr7FhHTVYV9iqbo2NNAOntHHWy2Zl
jbTFK7uQQ8N+M/UbmZuHjftE/DNie6ngxaUSQPIiNKxRfaOugs+CpGzN8ONq
C8LtO0RnF5Lue/ivJ15Vop33Y1pfI6vQD9wtqNknJseGOjAVTW9/rKit6zy0
iINgEeT468VqjTu+NG2thNAUc9hJp27K4OCh7Lrif1ReA5rUnFxGU1V3aB7g
U2QcE6K4qa2fe1K3R8LEGS7tsMVEHFvoPiGZUN5QXuHkc8IZ9lrXot+zBcaw
Zy+ceFYik309NarNMzoIFLPN9WFIe+SuQyuKxnvmhWd/7TMXKK/olE7uySXI
ehMLgdVray+de3KWJuje/Ehe5EQVeY4pFJSZAZObd62oI5avRxLnqQeLZKGL
eaPFI0Ri8IErmv8jSS8+6Op22Cn16vjiQgSo/aDKV0anT62cFTeZS9zjwU4o
PVgd8Pg80JCrMCRALensuSaGRQoex5fdFMQMnCRNRe84cVSEBUEe4SIWTKe3
xrP/8IAZPfiI8wTl4ic+MSjRsXQa6QuKv9gPq3Kt45DGW3aByvK5RfoVFqbQ
IVrqCWskYB87H4kOmKjcet2plsh5FAbaGMPinvWD4Qubdcs5Xo5Ne60lStvv
ZMYlbj8Q6oluNG6EZI5zjEPZNZ1C5KxK/41Lt+x1KCexm0uyJFwRjQ5C8aKL
Qz7aF50MpuIKktCdKKVTp3TOjFaq7hSiTdfxbSoRJHHI5V2JlbSt4iuRUZ3C
4ZT6fNWSI8IzKQMV90fLLESdkkZytSYjsOcgdcQ5tTb0sf81Wo0bibR4dVIF
giDKcY3NEWKQXQ5BNwHtXRxZ5CDBSjjStebZd3Xb4WIkbS+CjHa0wZ6LnR/w
NZ0rUUhwuJX1mTDdc23cPMQwl+tIUoU6cr10pt4GnphcThH5gh8h+EHKI8cP
yt7UQYJBZJyRxhAiZtfctRJClLOuhBm6nGMa6oLtmicgALGEssXLw/7Buknc
sWyfC78uZQLpEqKZjzu3z3i3DwNtXqLzC2WBtrcu8EiS+ANBQRJ3WAxFMucC
1iDeNECpWEOMdWrBGT3S6Ho3rvxDQMMZ1T8QFg+iS92LF96JEkifTVJMTOSr
YJJ0xjxyyYuQIf9Ny0fD3XjJ4Nz6qHW2Eh/VGg6W2uGGDIwHpsPGDaasTM0O
GkSJRrMo54Xz+K1HSja4b1jIRFwoYIDtIhoPs2alkXj3GbAhobTcr97AjMYj
ZytJaJWO4Wk+0Su4Eobnea3IEJIo20Ieq1nIaWEvRK8vybcVL1mXWWbXGcYs
gwIK2vFKt8JZSc9Aw2Ove93/OpBskE4xFrVlFfmBBRoRL//KwQ/+1ODBVvjB
Qc9Cl008gXUDqdNrQMKWrb6x2OJs7Yd4t5nntjQRZHNx5osjI4rFjdNAmdVc
dvI5gTDRlAf0MIDWTOfYLq58/hBVb2AEXqDJgDnxmLjhfImksq4WixRRDGuP
cZ4dia6mxOI0DDdR3dGyKbMKU8uccw3YYsvNsXFznKxSiM+L4lNFWYOdIKNq
fbyDkYNVObQnLz65RCRepUnpeJ1uIKOCY+96qmuNSZA7q8bTnpxNNctEuGkG
VxAckL3fMFHsLZyr7vc5H73EMm8txGUiZU49DQ1BnHuQE7YEi5bdUsQqIrM4
w5zwjDOdZdP8l/yqH1HDw3QXnV6jxAfGwQAbiJcEeRfOZ07OGVUSAhGIWaXy
p9jEQU08VBwC1KakaGC4qzodkOPcjyvdZaWAhp0ej1efOwnf6VMuBKVw13Kk
rVhXq4Jkhw9lHbvFW+ELJkktOwcGPOJJu/RnHBQbI5df66AIsFBghb08yKif
xsrH/3c8/VM5nh4tj8k1GQK4S/cS9UwcG8LdqIQBKLF2ZJNxAYoNOj7WnR6h
rt/KeSfXC5CLO0eh2Unt0lKFr6Eo2BGiJvouqhpDwXzupq1cGgqBB+LiQROG
XS4oF8hfwhU6s1rPNoU5blOwFYuHixNQqV10gstBdQrWOdMMhT/BGeSH8SZt
nExCs4ycx31VylqMidN1XJ6bVqjA91ipVcA/jM3GTTajWbcZ1Tj2zBORkA4g
rH2DQ/uUgTgf9QN5JZkAs3LSLFDETIRjxXp2UJkNnSPiovQwctUweN55sUnd
d6VQ0L57Qy4d55nk2Kgx79arvGV0mJ6Uh3vJStJQqrfqJIMXiVLycF28Nci7
Q97RhJuO+Itkjepn4qs0MEW4LPj35y8rdPMCxxxiCQY+vF9i+BiPImSaEVFL
nmOfD2lCK34oI0z1OICR4woNjYoFvDDJJxTaZTpg5RKZt+OIzolJk99hAJn0
nrsd+hEx16E9qJ6RoK7ZIj9/ud637w4TYLFoDS3hZTqZY2o67jwa4Gx5T/3T
j9V0CZb3HycnXDW+/oxJ23LEFHAcTFM8AQBIVCzA0qJD+dRzxzbhDsBHrMSZ
NT2BVD1KaglOQk9bE/QkxRmSxou71qf9dZM4rHfGqZVCRuZG0E3c+pwFHlci
rb2Dv9ajqZKkyomF4fiNysR1t7MSHyX4qf/YSH25iBlxUexsmdH5XUDYNjDQ
ZtFN31CTASi7SueYOL9WrhZ6AxnXj1LoQeXKqfwupmJNkiWHHfhYyR8nOx4H
rqLDAu00dZyQ1LBiMLenjqIb2fIEq/XRp+xEpEIcnS2YqlCgu0JoWoKASyTQ
LQPp/ZIOCZAnKqh9G2bKSJKTJBLzkXdkAVKrXRUORqp3RLxXvhgvU0ingmLM
T8DIipIN0T7yAMdrWOGg0vAJmWGef2paD08aOZ9n6ip6XIYvVpQj+F2Ry0tE
DdX+frFWpjvIlEVsu+0sCrClptn2M6qMZH2FCwQuXfjA57lmVW+tPee842UY
nz/jJC7xXOGmYq7ZAs8UeYIPTAScBb3GZz28zYQ73ntyiB3/qlpYeHIlONUR
n13RjGmqpJD/rcn9hhp2FfJ2xGDW4iyc4BcfBeFFBCgVa1NyQwP7O6Kaui6F
yddzZm6hssqVEXWlVFsKCfkzOVteOR2fsmjrc7ULOmhFLKmcklIt+FbyUl7k
A7TnVxxjdMcjXoclTrJZe8/8dQBR5RPGXXR63FCdZT316s4yH+7vii4dF79F
jdCd0D59srfb61InJX/EUAdRAmlC7m3SIkETA5UCaG9ozyagvmnyslcjitkX
IpmZ8IW4wtVmh5UZp3QSWlLrRC8vlWG7XQ4dnQ9vrTNOHrm9JC8f3GMT7bGa
w/FhVE1f58qy6n7RzNpAECZGLCZfR5BlyjhlrQ0NG9IZ7/QQkQbh3LFbz3+M
HLwVX2F0iFSdW5jUHrGHPldL49Mxk6IpK/KTg7DbZJdhOndxndZfqPbbjppj
UcwZJ/uCUZbEHrAutaB1T0t70SZkMWtmJeGe1PH9MuL114rbrs2fsXqtwkJQ
hhFvl6DzDxKLr6R8rsgy8YEiK0MoD6jiT1h6QQVQkJUj9vZ83vCJsFvnnwh6
BlURZBYWDKwMqLNzwnwydvvuqB+lauhtUFRat0Mw/3JxpFd7XXhk4lRWvHrp
82df1uKu2FAMByeHHdGahuY5HpPxgA/3WanQZXKEyhFPPUdD1DiWqAeY2hWX
YTEkTEs7sG/kZO5rrS/AO4ZTYolbdkhcP0F3srUnJ5oj/4dZOwIXcl52hbp7
MFjtrSImoHjNydBOd9BuhV9l1doUNdDSDQQ3L9RHFLF95rBfS9CfIxdypEhx
ilZVJX6/wNtR3FEP3HrnBHWgr9qgx2oIlCKLkH+TTMpiPC8mn6r2dnQpQBu3
o4oqgW08aUuFKzFbiPJL/TF1OwN0L3QlJrhFw5+ZX7ip2q16tZQIyN7B4Xb3
9pqN22u/dnvNpu21j9neaHdN1+62a2Z9eXefmSDFNLpypFXfgrtFDsMFDE58
iWg8cp/lW8hGYY4fqV4GiB/5gw7VK7Q/IsJs+5ZSzgu+DpNIUTSzBy8JD+T4
0ixc/0i1n8jN7UoZHlIhw4ivBbn34jj2RTniKiq85Cw3fuqVVxtaB0t9ERHg
11vV38t6K17/0fb20DjViioeok4ihORUvUSrJtaokoS7OU7dXTN1AZDfBHop
17N5GvFm0OfhbgSHOb14/kulwOmcy4ap+PImj5uL1I4IJtMpvdiq2iS/2Jxy
8muz7OJuArnMbtxF8jewQkHtYzSooks6JDM2FnPrNZRCkibzcgrqbj0YN7MB
iD74O8sHY8C4get6ADZmBS/o8NcgkfjpaiB6kBQCKSeL6QAMqGaANCQPJ8ux
/JrSL646mf1OkmqwgMnBQ62kWQ+A0ckkqgSGdVnO/LeE1oqCHqCuOvBzB5x3
T9GjSA+x7E7wFNYyTylhEhouwWbUV7yytQXzS5o9zBbzbtzDtW9BkZJuqnLS
ft1KYBXIOC4BsNmAC4wH0ZZ22g+uVHJTB04s9Rj4S3AC5CLMMJSCWqumIyhE
Lox1zPGx4Eo00BCpOeayvowJHn70UcRAaRWN1fznFDPv6/uCYibniWWHsqkD
PSrUUqNuYN+6mIq9bMaDC25k5Nq26EJHJ/WobU8ngYddJE6BucNccwVheG/o
eqYrSpo7G0gN25/oaJZEF2p6FwTtwmu7fLhYwyLwWKpJR+BbCze2D5e5axmj
3SO58Ui+5NPLuBSsu90qlBpruQdiRwdxKwIdM7Z1rIjLcoaGRpB9VKXBCUin
m3Yuf+1WSkxw5Js/KsAn4wkj6JE9AWh6Nlz1powX6VJhfNgGxvkrbutvwV4n
zoW0lorxhVOLgWI7Lu0OKrbP3wcK7i8kHZ5ntbcvxKdHX4bHXra0unp41pM7
VsXXA3J7o+Y7/ipD5BH672h3dxeLA4z2dne1fIrHSS6AigFhTOi+Ttjxw0gv
fVwjdyWnFQkHyY0kCzeMkslh1H8ZmwhvjNOCHBs1ICzXdgP48pER69tgiz4y
eENtJ7CxCBVfX260tRgL16wtj5yvq0chJxpabWjHyFnKDTYt8+yLOPoV5hnY
W2Zro9nhlcPt/8fx6x+CXmhmKXq9RpUardcOhFqMl4JSb55fhEjlEShMKn6f
uOuWqHccCrv43EYy7O1RaIat/wyiLR/ihv96mLb8x3AyqkGouEZYtBHbKkI3
j2QvUy4yd8Gl7uzzhk/8B7jkmnX4iFR95kWQGyJZSRKqYexajjsa9kVeYbOb
1RLdyJTmiklUzYIL7WjYcM3Gd1fMusdDrmOvxRQR38J7fMw6zkVuZnVJHAV3
K7AMdihhJPzgU2Ndj5mPv3cfL4vp9DPnk7z31ye8Di6/jepLvA/RL4jw+DvW
Pgf3ehG8Oi7h0coonTcA4QU1D98Zs3bFClORXICA4PniVUeU7rN24WV8jTBF
9LKqNq2JtO9JlVWGoayghYSu/DFy0zl9PI/trhfSLcUzzGFpJb42UExze4b1
6MzLpE56etne8REiCOtjaQ7mWUWlJvmigejWIIlu+kMz4Sp1K8JyguEN4g4/
3F1twZr4+hbXl1bwrfg2Iy6G076AWW8Rx04Wkoupt39QLQtNGtmYeyisMK7u
TdGo1oFz06qt7YIIdzep4k4b9aJiSXJ1O6JYeJes39Dw6y2s3VSmUZ5gMHcg
vFey51uYePHqfpKWy3o7Zqx2ccq1B/ePQSvHMXbOfrmwx0/t8ZE9PkadHf4b
wX97lGJ7usimJ7Oi4D84NfwEvv7x6Wi0c4QKfvTiyP588aLj+bF9d/Hhcmcf
3+yMonc44vtXL3c6X43si7fr3cHkbJ3O0+UNFs7F8i918BHaWDgi7EqWo69r
lk5OR89ol+r70/ArHPv46c7xUfRsz+4ORgf8aIlOppM9aQRsjh/s64QAOgd8
zx2gxvFxH1o/Y9Pr9HDfzxs+O3Sfwaj946fw6Qg/N5E/OqU8Gq58//L0sHVS
uatwAxA2NgH0w9VsxSgnis92H3d468ch7Br8RrhuvSgWM8xLfFtkVbpN7BmX
vvXy6s1r6C1Pq+21+2INjnRIGV/CHTVHE4eFXRRG1g84BpK0J9zoNi4T5Swy
J4/oAyaN8zo+ovlrLh2OE/SPRcp1MXlBac0AGL8MYMUXUadHmr7aLshB1b04
hQofNHp8mRUcjDwsa2Y9nfc3QS9rU6OMKZx76u47hX6Cypy0rZHukNUSgdcA
NsKfwR/vv4OOLzqpwWvU4tbngqlSa85rQiMpiCpwqjCDzVcIpV2TC23WhVY7
S4vrOHBCGeff8mz9FYWBC8adDhLwb7q0QpXuRbooNF+Tinex4yVy3mEeS5Ln
mqwdHhbMqZS88+vAgJG/lfUh6T69xxovGWZGokqWcoKAL9LaumDcdcQKGn3c
XpDfgLn9UaqisrFDhVZbVUv/K26u6AdHNpIKi4yDNKQYv7ssay2pAiNW+7sH
KP31WJRxael3es0FHw5qHxnZZCStX+lK/A6PXEotIfl3av+t4n5Pelob6PKC
fk0zOq+x9u+v9HZZs1ueLkUCi5Oe+Qe/8WDQW/Dv1I6+3Urmy5tkAJZZiofG
dmxv0MP//djbNiZ+x02+Yz04uHzE3elrv+dRYKbRKLAkrlOwgz+lzuP6pE91
pXq3k/12q/es55eyLa18E+peWtHjDU1cj35GfNZ8gYPYXp9/wtf4f/G/Ry2Z
B/dN8BkF+PhN58bxJnHo7cHPZsvq4W8e/mRcPvjJ8hEjjZfLB7/h0MrDw9Fu
cqqRaYHNyl65YHMPsL1Hp/sVc8CQVuQOIRk05MdfbOmAS/NyLcl1+aVmYaug
2Zdb6Ra0WqGz+gutlt1TXD4wRbdRrcGWS21GNe7XG4a7Jw350SlTF1JTSI5s
AG7mKdsy3NpAnix5hsKmhCrlLyDMeHlWhnp5/uP5FVBtaxHBS9sb9vyHcQ/c
Cwz1b/d7u4ODI2RQ94e7g6ev7HYnyj6jCk6YDCbxrJsEAzdU1I20oypdZJNi
jodHuhi+lvEWS6XSwggcHOgq11xli2YOsquWkIHYtZUmqeuldu47fw+aHG3B
8wTPG3adXIo1yromvaL864rSPjnKIc3jszdRWb93ywZ0BdCm9/bo/0YcBCKV
k6wro8fQ8PEvF6C+/nJx3BeX09aL5xc7L3666OMZ+dSC0bMtrwaXv7wA4w3f
X8IHpJQbfHNgt95c7LwZ7cIzBAKlDpCZfzRAl5SkEmDAa4tOSSyye3Ry4nI0
zI7XukN3IykAz8eGnkpTsdK3KetRgyz6Mjp9VdmtkdW7Cg3pV/fhzRbYO5ot
fH0hnohS75//qNrme03HsiuSYUO+Aa4KzvvzJKiGEbT218zokyihfuRWJ4YF
YMrTvd1ldImSnNrhesK0qXwTJeqcyScqe/Gt3Wv1REj35DDuinTvVl9AIPBr
T/o0Vnvl23T2u7odHX25W+Ivzo2CW41VRd5dvTohYCBRcdkVTuetPmVLUh5B
Y3P1uPHWG2quzqHqBo0mxLIZKGp0W2nSiup6LxgwkuGQsno5tLngC+rASkmp
mF1Q6MObpkpNhIo3WFqe5tetD0L/Rv0TGDxk/8Tl2S8Xr+3xoT22R3bXjvae
GO9YOAwcC8Fj+yPQ5k788MhevHhz1nq4iw8/tB7CEN3+BXaHJCOZKZPH2kzb
jhT47wn8tw//HcB/h/DfU+gKNHAYDNC1KfMTZHsnxJyrE5jF4Abo674+qUA3
p78ZU0AUmNDZAqxl53iXZ8ZujyMJ450Cmu4+k5TV0ychbI6RGbWaHT/YDNeD
ke+4IT5tZ1+c7u/t745mzzrSgU6jDkedHY6+qsORibxCXR3urXd4uL87ecwM
n3R2+OSrOoxmuE8dIp9vd7q/3unBE+w0bH6wsflBR/PDdvNDbH7QbnromkKj
0TPrOjh+EjZ+2tn4adh4r93YywkinNuR3YrFxbZhW49Fik+qPB3tHe0+89rr
KTDwZ6KSClpCK+LPt49v9Q+kWhiaxBuDc4dyTjF/CFPocVqwIBGZCqs9gBUI
3mbRAa4n7YUD/oXrBip26x4d/HOt+8m/6LpBMSRNqWPZ++1lP9mLlj06+mdZ
tntPq9I3XCECgXDQvz3s3z7tAIW0Nt12Bej5l6ATkU3yM98NaM6mFOWu9Dnf
GSj3t8gxZ19BupnXGUZWVhS8lgsbxAUnZ3EznumdpCo1ORY7v3z9YdtV3uf7
3P2lBdpsvtKGRm9ml4KFEushT+U4rWpfUddi6MJniIf5kZhZPs2oBqZLoMQa
K7pS724nf2t4B5jLr2NoYKR6nn1Kw1t6Q1OK9VM5y96KdslVFpKqHF00FlRV
66hD7AqKqxpKKiHbWzeA0AiGSFc3qgizA53L4FWgX7u9xRNeBeZNyiZviYH3
/vJqe2guH21dBoePOTcNEbQJQULXKHWrr++4+nqoxSq+J5UvF6CrVoxWUn3E
t1201fntV4je3a8RvcBd/pTAfia+kz8ruaNI22PZfxR3eyzzBMjpXp9wS+jk
dPfZ6NnBM7Zr6cGeCbdEt9DZyF374pjc3uD2qWNnnV6Sb+jaa/sijF3rGXa6
5lpDBdGh3GY5pQA9u2ePDg4AqYFirqk+iEfs6ybD2BVGjLAQajZJ0b3fjgtZ
OjKxzSETdmS4WgNlygElumOoI8bxjX0LZieapG/oXpOf+dZwDROslSGQxGS5
XbvydxzpfePhhdvRXcR0lVB8azjYrAQ8TsHpSS0T+zK45OpCbhmjQPl2EAvr
GWkFIwy47sMWez94Iiivt3t6RXyrDkZwlbC7ENIXKbJyG2uYMpHlRss7uEvb
ape5lbV87v5CPndClAJD0WV+YTzSGeF+jpyJXXXinUsReFHQZRC09X2bLogN
6v1tlDGktrEktBn2FZ6/unpt37z5cHn+wv5alJ+QA/9YFs2SXzPb/QFZ8LAo
r/nhfx/Zg9EuZiPY/d2jXerpzE2XQnxb6JKQ4z/+wircORkX9oF+/Vzk13SH
TrDgnE9S2Vf59TyrbqRFkHpkz7UwBS+DUpMwlc91saXKAuFA3wYIQZFmvKVN
p0L4bgnf6cmvQSJIqwQbO+fc7ZjkU+Hb4UNKoV6votbte+VtdK88wo/uE0Z9
7bpMljcUyUz8nX3koOJyiPpn14CM3lTruwvFqR57eBWA4jz3QPFcV7fEX9UR
obu4IoPbiqitaB1/aQea21He9cvpuX3rQLerdOdCoZo61L5mjmC3VuiAqn8s
S7oRcK2M3jqNCQh/oZs2grsroqMKqcWQLS7jr8Cr/wP//UYN35AeimokEM/W
m+Z+276Aga+LciUdX168enF+9vNGApb8O+IJK63MIiw4iPp7YUI3mXYKFDz4
QbUjuCoSctVSO0bCmhKSBEBZBpzUXa3Nzslg87QP8eN25mFJuR0TMHZOisFJ
8GEmlh7ucIDLLuOiEQnvDQytpadUmKAy0CVcqE2UchDEOQE7WikTHbdXBIXR
cyo0g+ijFx0z29B16UlPrrnvCwlKFmaY3xmV0nU5i+5ya2hR8a0HrswROt1r
zsNd8PXrrQp6wWZwHiporkKBNE3S0KM7nOIkOb5iie9paxVVCG6aJW3dJEFl
WSVJf28UJaygCh+e+QKGxenc6OIGzAvPY5dRYgodip1g5AnzU9vlQ3qXITqb
93JwtmeXxTybrFw27MHe3iEf1EpjaUq7FaU4nb/0R2lYuFD5A+sv+VNeHh39
aZ3hv8JoR0RqfEkdF8kNB/RHp0LJvkWXpMz9MTHDgtHFB5TEtikiEsLvQZH6
Ldd2e0hkhKnx2ObP8s12PzlzxgCNuga8olNj0Q3PXVcziPIqdca0x8pGd2N0
3Xro0mZ9lj/m4fsAy8mXNCjUib0i/RYh7v+9V0yBDwdr/4IP3TNjg9PmHf9U
hPwmH8p56Yc/BJOnq7+ODzd8t/bhuHzkh8vHDj1eLh/+kHWhB4fevGdStRJL
m6XZLbsUuDbSLL4qHLSMnEvJ6HXhJF4Jh+Kzu9ReSRmf43VvXNNCirAEKVh6
xQ0WXbUTOoiIQeToFIWnCwkJtpIPiGmjCyuboHYTVqjiMgtUMi0YlGsqyMiy
HLCSkmVcWAvLSUH/K3Mn5Tz5unoX6ScnUkdKQMXa8coRvbkmfUKKKo72nrqk
cIIO3/GdTho8A9+yfY0505KOeHdrrFBgyTYsBt1wiqXeqYmnSq+pL7xVWu9k
wGIvYfZ3IP79XdN1jV46TOzjY9VFKNrVHAAmsiywyG9G5TuaHOGDegrIRjFU
J3IlpqvtlLerN8lZHAeaZFE0WjYwqROrRaO1PlVU2Yk8f7TtfEJo3seKiHzo
oMpIGHWtlBx5UoVJi0MFRyLoZl+W2eYhmR2pJsKo2bqROx6DtZtQP6EAPHv7
ysDTSct19afI0YcI1wabkcvC1kqsEsIL4oqVDLiISfWu/mApNoxoxtVauTUY
uFgmf29SunUSiabP+K9FjsKPlcBD6cyltIJFcMplX+44AKgCbMtbd2y5JDKW
co3f2LPJp7y4m6fTa1ow4D7lqSBoPsnG32agFZEH+UUzn4NM+h9pjmcngBTe
gD3UVPbXFLXmeYNlO/nkTTM3/776HZgb1bvVvl6AJpTbixStdS3YumzIphTO
FyVk3yRaORNl1RioBGeMDgNCraKs2sWr/LmGSisPyMdYZcTf3mxr4EzM6tby
Rs0FCVKYNabylubHoriep+YVeiZO7LKW5z9c0/MhaL0As8L+b9RgVuZFVk0K
e7mq8N50bbT4nV7+MMGX3OKywaovb/Fy1U/NIim7G1Y5fxC2fF7Y5w3sfm5e
ATVVWENevh4XwzG9+SGVN9JiVQKEXyQLkFsw1d+BEyeuzYQe/7Dgx9QAgfB/
Aajy8WcqtwAA
</rfc> </rfc>
 End of changes. 126 change blocks. 
1747 lines changed or deleted 1979 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/