rfc9429.original.xml   rfc9429.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" <!DOCTYPE rfc [
docName="draft-uberti-rtcweb-rfc8829bis-04" number="8829" consensus="true" <!ENTITY nbsp "&#160;">
ipr="trust200902" obsoletes="8829" updates="" submissionType="IETF" <!ENTITY zwsp "&#8203;">
xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" <!ENTITY nbhy "&#8209;">
tocDepth="4" version="3"> <!ENTITY wj "&#8288;">
<!-- xml2rfc v2v3 conversion 2.34.0 --> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
std" consensus="true" docName="draft-uberti-rtcweb-rfc8829bis-05" number="9429"
ipr="trust200902" obsoletes="8829" updates="" xml:lang="en" tocInclude="true" sy
mRefs="true" sortRefs="true" tocDepth="4" version="3">
<!-- xml2rfc v2v3 conversion 2.34.0 -->
<front> <front>
<title abbrev="JSEP">JavaScript Session Establishment Protocol (JSEP)</title > <title abbrev="JSEP">JavaScript Session Establishment Protocol (JSEP)</title >
<seriesInfo name="RFC" value="8829"/> <seriesInfo name="RFC" value="9429"/>
<author fullname="Justin Uberti" initials="J." surname="Uberti"> <author fullname="Justin Uberti" initials="J." surname="Uberti">
<address> <address>
<email>justin@uberti.name</email> <email>justin@uberti.name</email>
</address> </address>
</author> </author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings"> <author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>400 3rd Avenue SW</street> <street>400 3rd Avenue SW</street>
skipping to change at line 37 skipping to change at line 40
</postal> </postal>
<email>fluffy@iii.ca</email> <email>fluffy@iii.ca</email>
</address> </address>
</author> </author>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla" role="edit or"> <author fullname="Eric Rescorla" initials="E." surname="Rescorla" role="edit or">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date month="February" year="2024"/>
<date day="23" month="Jan" year="2023"/> <area>art</area>
<workgroup>rtcweb</workgroup>
<keyword>webrtc</keyword> <keyword>webrtc</keyword>
<keyword>sdp</keyword> <keyword>sdp</keyword>
<keyword>negotiation</keyword> <keyword>negotiation</keyword>
<keyword>signaling</keyword> <keyword>signaling</keyword>
<keyword>peerconnection</keyword> <keyword>peerconnection</keyword>
<keyword>api</keyword> <keyword>api</keyword>
<keyword>ice</keyword> <keyword>ice</keyword>
<keyword>rtp</keyword> <keyword>rtp</keyword>
<keyword>offer</keyword> <keyword>offer</keyword>
<keyword>answer</keyword> <keyword>answer</keyword>
skipping to change at line 206 skipping to change at line 208
addressed by using a library like the one mentioned above, it addressed by using a library like the one mentioned above, it
basically forces the use of said library even for a simple basically forces the use of said library even for a simple
example. Providing createOffer/createAnswer avoids this example. Providing createOffer/createAnswer avoids this
problem.</t> problem.</t>
</section> </section>
<section> <section>
<name>Changes from RFC 8829</name> <name>Changes from RFC 8829</name>
<t> <t>
When <xref target="RFC8829"/> was published, inconsistencies regarding BUNDLE When <xref target="RFC8829"/> was published, inconsistencies regarding BUNDLE
<xref target="RFC8843"/> operation were identified with regard to <xref target="RFC8843"/> operation were identified with regard to
both the specification text as well as implementation behavior. The both the specification text and implementation behavior. The
former concern was addressed via an update to BUNDLE (see <xref target ="RFC9143"/>). former concern was addressed via an update to BUNDLE (see <xref target ="RFC9143"/>).
For the latter concern, it was observed that some implementations For the latter concern, it was observed that some implementations
implemented the "max-bundle" bundle policy defined in <xref target="RF C8829"/> implemented the "max-bundle" bundle policy defined in <xref target="RF C8829"/>
by assuming that bundling had already been negotiated, rather than mar king "m=" sections by assuming that bundling had already been negotiated, rather than mar king "m=" sections
as bundle-only as indicated by the BUNDLE specification. as bundle-only as indicated by the BUNDLE specification.
In order to prevent unexpected changes to applications relying In order to prevent unexpected changes to applications relying
on the pre-standard behavior, the decision on the pre-standard behavior, the decision
was made to deprecate "max-bundle" and instead was made to deprecate "max-bundle" and instead
introduce an identically defined "must-bundle" policy that, when selec ted, introduce an identically defined "must-bundle" policy that, when selec ted,
provides the behavior originally specified by <xref target="RFC8829"/> . provides the behavior originally specified by <xref target="RFC8829"/> .
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec.terminology" numbered="true" toc="default"> <section anchor="sec.terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC8174"/> when, and only when, they appear in all capitals, <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
as shown here.</t> when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="sec.semantics-and-syntax" numbered="true" toc="default"> <section anchor="sec.semantics-and-syntax" numbered="true" toc="default">
<name>Semantics and Syntax</name> <name>Semantics and Syntax</name>
<section anchor="sec.signaling-model" numbered="true" toc="default"> <section anchor="sec.signaling-model" numbered="true" toc="default">
<name>Signaling Model</name> <name>Signaling Model</name>
<t>JSEP does not specify a particular signaling model or state <t>JSEP does not specify a particular signaling model or state
machine, other than the generic need to exchange session machine, other than the generic need to exchange session
descriptions in the fashion described by descriptions in the fashion described by
<xref target="RFC3264" format="default"/> (offer/answer) in order for bo th <xref target="RFC3264" format="default"/> (offer/answer) in order for bo th
sides of the session to know how to conduct the session. JSEP sides of the session to know how to conduct the session. JSEP
skipping to change at line 283 skipping to change at line 285
<t>Whether a session description applies to the local side or <t>Whether a session description applies to the local side or
the remote side affects the meaning of that description. For the remote side affects the meaning of that description. For
example, the list of codecs sent to a remote party indicates example, the list of codecs sent to a remote party indicates
what the local side is willing to receive, which, when what the local side is willing to receive, which, when
intersected with the set of codecs the remote side supports, intersected with the set of codecs the remote side supports,
specifies what the remote side should send. However, not all specifies what the remote side should send. However, not all
parameters follow this rule; some parameters are declarative, parameters follow this rule; some parameters are declarative,
and the remote side must either accept them or reject them and the remote side must either accept them or reject them
altogether. An example of such a parameter is the TLS altogether. An example of such a parameter is the TLS
fingerprints <xref target="RFC8122" format="default"/> fingerprints <xref target="RFC8122" format="default"/>
as used in the context of DTLS <xref target="RFC6347" format="default"/> ; as used in the context of DTLS <xref target="RFC6347" format="default"/> <xref target="RFC9147"/>;
these fingerprints are calculated based on these fingerprints are calculated based on
the local certificate(s) offered and are not subject to the local certificate(s) offered and are not subject to
negotiation. negotiation.
</t> </t>
<t>In addition, various RFCs put different conditions on the <t>In addition, various RFCs put different conditions on the
format of offers versus answers. For example, an offer may format of offers versus answers. For example, an offer may
propose an arbitrary number of "m=" sections (i.e., media propose an arbitrary number of "m=" sections (i.e., media
descriptions as described in descriptions as described in
<xref target="RFC4566" sectionFormat="comma" section="5.14"/>), but an a nswer must <xref target="RFC4566" sectionFormat="comma" section="5.14"/>), but an a nswer must
contain the exact same number as the offer.</t> contain the exact same number as the offer.</t>
skipping to change at line 449 skipping to change at line 451
an RtpSender and an RtpReceiver, which an application can use an RtpSender and an RtpReceiver, which an application can use
to control the sending and receiving of RTP media. The to control the sending and receiving of RTP media. The
application may also modify the RtpTransceiver directly, for application may also modify the RtpTransceiver directly, for
instance, by stopping it.</t> instance, by stopping it.</t>
<t>RtpTransceivers generally have a 1:1 mapping with "m=" <t>RtpTransceivers generally have a 1:1 mapping with "m="
sections, although there may be more RtpTransceivers than "m=" sections, although there may be more RtpTransceivers than "m="
sections when RtpTransceivers are created but not yet sections when RtpTransceivers are created but not yet
associated with an "m=" section, or if RtpTransceivers have been associated with an "m=" section, or if RtpTransceivers have been
stopped and disassociated from "m=" sections. An RtpTransceiver stopped and disassociated from "m=" sections. An RtpTransceiver
is said to be associated with an "m=" section if its is said to be associated with an "m=" section if its
media identification (mid) property is non-null; otherwise, it is said mid property is non-null, i.e., set to a valid Media Identification
to be (MID) value; otherwise, it is said to be
disassociated. The associated "m=" section is determined using disassociated. The associated "m=" section is determined using
a mapping between transceivers and "m=" section indices, formed a mapping between transceivers and "m=" section indices, formed
when creating an offer or applying a remote offer.</t> when creating an offer or applying a remote offer.</t>
<t>An RtpTransceiver is never associated with more than one <t>An RtpTransceiver is never associated with more than one
"m=" section, and once a session description is applied, an "m=" "m=" section, and once a session description is applied, an "m="
section is always associated with exactly one RtpTransceiver. section is always associated with exactly one RtpTransceiver.
However, in certain cases where an "m=" section has been However, in certain cases where an "m=" section has been
rejected, as discussed in rejected, as discussed in
<xref target="sec.subsequent-offers" format="default"/> below, that "m =" section <xref target="sec.subsequent-offers" format="default"/> below, that "m =" section
will be "recycled" and associated with a new RtpTransceiver will be "recycled" and associated with a new RtpTransceiver
skipping to change at line 709 skipping to change at line 712
<section anchor="sec.creating-imageattr" numbered="true" toc="default"> <section anchor="sec.creating-imageattr" numbered="true" toc="default">
<name>Creating an imageattr Attribute</name> <name>Creating an imageattr Attribute</name>
<t>The receiver will first combine any known local limits <t>The receiver will first combine any known local limits
(e.g., hardware decoder capabilities or local policy) to (e.g., hardware decoder capabilities or local policy) to
determine the absolute minimum and maximum sizes it can determine the absolute minimum and maximum sizes it can
receive. If there are no known local limits, the receive. If there are no known local limits, the
"a=imageattr" attribute <bcp14>SHOULD</bcp14> be omitted. If these loc al "a=imageattr" attribute <bcp14>SHOULD</bcp14> be omitted. If these loc al
limits preclude receiving any video, i.e., the degenerate limits preclude receiving any video, i.e., the degenerate
case of no permitted resolutions, the "a=imageattr" attribute case of no permitted resolutions, the "a=imageattr" attribute
<bcp14>MUST</bcp14> be omitted, and the "m=" section <bcp14>MUST</bcp1 4> be marked as <bcp14>MUST</bcp14> be omitted, and the "m=" section <bcp14>MUST</bcp1 4> be marked as
sendonly/inactive, as appropriate.</t> "sendonly"/"inactive", as appropriate.</t>
<t>Otherwise, an "a=imageattr" attribute is created with a <t>Otherwise, an "a=imageattr" attribute is created with a
"recv" direction, and the resulting resolution space formed "recv" direction, and the resulting resolution space formed
from the aforementioned intersection is used to specify its from the aforementioned intersection is used to specify its
minimum and maximum "x=" and "y=" values.</t> minimum and maximum "x=" and "y=" values.</t>
<t>The rules here express a single set of preferences, and <t>The rules here express a single set of preferences, and
therefore, the "a=imageattr" "q=" value is not important. It therefore, the "a=imageattr" "q=" value is not important. It
<bcp14>SHOULD</bcp14> be set to "1.0".</t> <bcp14>SHOULD</bcp14> be set to "1.0".</t>
<t>The "a=imageattr" field is payload type specific. When all <t>The "a=imageattr" field is payload type specific. When all
video codecs supported have the same capabilities, use of a video codecs supported have the same capabilities, use of a
single attribute, with the wildcard payload type (*), is single attribute, with the wildcard payload type (*), is
skipping to change at line 882 skipping to change at line 885
encoding, as specified in encoding, as specified in
<xref target="RFC8851" sectionFormat="comma" section="4"/>; the use of <xref target="RFC8851" sectionFormat="comma" section="4"/>; the use of
Restriction Identifiers (RIDs, also called rid-ids or RtpStreamIds) Restriction Identifiers (RIDs, also called rid-ids or RtpStreamIds)
allows the individual encodings to be allows the individual encodings to be
disambiguated even though they are all part of the same "m=" disambiguated even though they are all part of the same "m="
section.</t> section.</t>
</section> </section>
<section anchor="sec.interactions-with-forking" numbered="true" toc="defau lt"> <section anchor="sec.interactions-with-forking" numbered="true" toc="defau lt">
<name>Interactions with Forking</name> <name>Interactions with Forking</name>
<t>Some call signaling systems allow various types of forking <t>Some call signaling systems allow various types of forking
where an SDP Offer may be provided to more than one device. For where an SDP offer may be provided to more than one device. For
example, SIP example, SIP
<xref target="RFC3261" format="default"/> defines both a "parallel searc h" <xref target="RFC3261" format="default"/> defines both a "parallel searc h"
and "sequential search". Although these are primarily signaling-level is sues that are outside the scope of JSEP, they do have and "sequential search". Although these are primarily signaling-level is sues that are outside the scope of JSEP, they do have
some impact on the configuration of the media plane that is some impact on the configuration of the media plane that is
relevant. When forking happens at the signaling layer, the relevant. When forking happens at the signaling layer, the
JavaScript application responsible for the signaling needs to JavaScript application responsible for the signaling needs to
make the decisions about what media should be sent or received make the decisions about what media should be sent or received
at any point in time, as well as which remote endpoint it at any point in time, as well as which remote endpoint it
should communicate with; JSEP is used to make sure the media should communicate with; JSEP is used to make sure the media
engine can make the RTP and media perform as required by the engine can make the RTP and media perform as required by the
skipping to change at line 1060 skipping to change at line 1063
<dt>max-compat:</dt> <dt>max-compat:</dt>
<dd>All "m=" sections will contain <dd>All "m=" sections will contain
transport parameters; none will be marked as bundle-only. transport parameters; none will be marked as bundle-only.
This policy makes no assumptions about the remote endpoint and This policy makes no assumptions about the remote endpoint and
as such will allow all streams to be received by as such will allow all streams to be received by
non-bundle-aware endpoints, but as a result requires separate non-bundle-aware endpoints, but as a result requires separate
candidates to be gathered for each media stream.</dd> candidates to be gathered for each media stream.</dd>
<dt>must-bundle:</dt> <dt>must-bundle:</dt>
<dd>Only the first "m=" section will <dd>Only the first "m=" section will
contain transport parameters; all streams other than the contain transport parameters; all streams other than the
first will be marked as bundle-only. This policy presumes first will be marked as bundle-only. This policy presumes that
the remote endpoint supports multiplexing and accordingly aims to the remote endpoint supports multiplexing and accordingly aims to
minimize candidate gathering, at minimize candidate gathering, at
the cost of less compatibility with legacy endpoints. When the cost of less compatibility with legacy endpoints. When
acting as answerer, the implementation will reject any "m=" acting as answerer, the implementation will reject any "m="
sections other than the first "m=" section, unless they are sections other than the first "m=" section, unless they are
in the same bundle group as that "m=" section.</dd> in the same bundle group as that "m=" section.</dd>
</dl> </dl>
<t>As it provides the best trade-off between performance and <t>As it provides the best trade-off between performance and
compatibility with legacy endpoints, the default bundle compatibility with legacy endpoints, the default bundle
policy <bcp14>MUST</bcp14> be set to "balanced".</t> policy <bcp14>MUST</bcp14> be set to "balanced".</t>
<t><xref target="RFC8829" format="default"/> defined a policy <t><xref target="RFC8829" format="default"/> defined a policy
known as "max-bundle", which, while defined identically to the known as "max-bundle", which, while defined identically to the
"must-bundle" policy described above, was implemented "must-bundle" policy described above, was implemented
by some implementations according to an earlier, pre-standard definiti on by some implementations according to an earlier, pre-standard definiti on
(in which, for example, no "m=" sections were marked as bundle-only). (in which, for example, no "m=" sections were marked as bundle-only).
As a result, "max-bundle" is considered deprecated, and implementation s As a result, "max-bundle" is considered deprecated, and implementation s
compliant with this specification SHOULD ignore attempts by the applic ation to select compliant with this specification <bcp14>SHOULD</bcp14> ignore attempt s by the application to select
this bundle policy (although some phase-out period may be necessary this bundle policy (although some phase-out period may be necessary
to avoid application breakage). to avoid application breakage).
</t> </t>
<t>The application can specify its preferred policy regarding <t>The application can specify its preferred policy regarding the
use of RTP/RTCP multiplexing use of RTP/RTCP multiplexing
<xref target="RFC5761" format="default"/> using one of the following <xref target="RFC5761" format="default"/> using one of the following
policies: policies:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>negotiate:</dt> <dt>negotiate:</dt>
<dd>The JSEP implementation will <dd>The JSEP implementation will
gather both RTP and RTCP candidates but also will offer gather both RTP and RTCP candidates but also will offer
"a=rtcp-mux", thus allowing for compatibility with either "a=rtcp-mux", thus allowing for compatibility with either
multiplexing or non-multiplexing endpoints.</dd> multiplexing or non-multiplexing endpoints.</dd>
skipping to change at line 1131 skipping to change at line 1134
will be created, as described in will be created, as described in
<xref target="sec.addTransceiver" format="default"/>.</t> <xref target="sec.addTransceiver" format="default"/>.</t>
</section> </section>
<section anchor="sec.removeTrack" numbered="true" toc="default"> <section anchor="sec.removeTrack" numbered="true" toc="default">
<name>removeTrack</name> <name>removeTrack</name>
<t>The removeTrack method removes a MediaStreamTrack from the <t>The removeTrack method removes a MediaStreamTrack from the
PeerConnection, using the RtpSender argument to indicate PeerConnection, using the RtpSender argument to indicate
which sender should have its track removed. The sender's which sender should have its track removed. The sender's
track is cleared, and the sender stops sending. Future calls track is cleared, and the sender stops sending. Future calls
to createOffer will mark the "m=" section associated with the to createOffer will mark the "m=" section associated with the
sender as recvonly (if transceiver.direction is sendrecv) or sender as "recvonly" (if transceiver.direction is "sendrecv") or
as inactive (if transceiver.direction is sendonly).</t> as "inactive" (if transceiver.direction is "sendonly").</t>
</section> </section>
<section anchor="sec.addTransceiver" numbered="true" toc="default"> <section anchor="sec.addTransceiver" numbered="true" toc="default">
<name>addTransceiver</name> <name>addTransceiver</name>
<t>The addTransceiver method adds a new RtpTransceiver to the <t>The addTransceiver method adds a new RtpTransceiver to the
PeerConnection. If a MediaStreamTrack argument is provided, PeerConnection. If a MediaStreamTrack argument is provided,
then the transceiver will be configured with that media type then the transceiver will be configured with that media type
and the track will be attached to the transceiver. Otherwise, and the track will be attached to the transceiver. Otherwise,
the application <bcp14>MUST</bcp14> explicitly specify the type; this mode the application <bcp14>MUST</bcp14> explicitly specify the type; this mode
is useful for creating recvonly transceivers as well as for is useful for creating "recvonly" transceivers as well as for
creating transceivers to which a track can be attached at creating transceivers to which a track can be attached at
some later point.</t> some later point.</t>
<t>At the time of creation, the application can also specify <t>At the time of creation, the application can also specify
a transceiver direction attribute, a set of MediaStreams a transceiver direction attribute, a set of MediaStreams
that the transceiver is associated with (allowing "LS" group that the transceiver is associated with (allowing "LS" group
assignments), and a set of encodings for the media (used for assignments), and a set of encodings for the media (used for
simulcast as described in simulcast as described in
<xref target="sec.simulcast" format="default"/>).</t> <xref target="sec.simulcast" format="default"/>).</t>
</section> </section>
<section anchor="sec.onaddtrack" numbered="true" toc="default"> <section anchor="sec.onaddtrack" numbered="true" toc="default">
skipping to change at line 1185 skipping to change at line 1188
<name>ondatachannel Event</name> <name>ondatachannel Event</name>
<t>The ondatachannel event is dispatched to the application when a <t>The ondatachannel event is dispatched to the application when a
new data channel has been negotiated by the remote side, which can new data channel has been negotiated by the remote side, which can
occur at any time after the underlying SCTP/DTLS association has been occur at any time after the underlying SCTP/DTLS association has been
established. The new data channel object is supplied in the event. established. The new data channel object is supplied in the event.
</t> </t>
</section> </section>
<section anchor="sec.createoffer" numbered="true" toc="default"> <section anchor="sec.createoffer" numbered="true" toc="default">
<name>createOffer</name> <name>createOffer</name>
<t>The createOffer method generates a blob of SDP that <t>The createOffer method generates a blob of SDP that
contains an offer per <xref target="RFC3264" format="default"/> with t contains an offer per <xref target="RFC3264" format="default"/> with t
he supported he
configurations for the session, including descriptions of the configurations for the session that are supported by the application,
including descriptions of the
media added to this PeerConnection, the codec, RTP, and RTCP media added to this PeerConnection, the codec, RTP, and RTCP
options supported by this implementation, and any candidates options supported by this implementation, and any candidates
that have been gathered by the ICE agent. An options that have been gathered by the ICE agent. An options
parameter may be supplied to provide additional control over parameter may be supplied to provide additional control over
the generated offer. This options parameter allows an the generated offer. This options parameter allows an
application to trigger an ICE restart, for the purpose of application to trigger an ICE restart, for the purpose of
reestablishing connectivity.</t> reestablishing connectivity.</t>
<t>In the initial offer, the generated SDP will contain all <t>In the initial offer, the generated SDP will contain all
desired functionality for the session (functionality that is desired functionality for the session (functionality that is
supported but not desired by default may be omitted); for supported but not desired by default may be omitted); for
skipping to change at line 1208 skipping to change at line 1211
process defined for generating an initial offer from the process defined for generating an initial offer from the
specification that defines the given SDP line. The exact specification that defines the given SDP line. The exact
handling of initial offer generation is detailed in handling of initial offer generation is detailed in
<xref target="sec.initial-offers" format="default"/> below.</t> <xref target="sec.initial-offers" format="default"/> below.</t>
<t>In the event createOffer is called after the session is <t>In the event createOffer is called after the session is
established, createOffer will generate an offer to modify the established, createOffer will generate an offer to modify the
current session based on any changes that have been made to current session based on any changes that have been made to
the session, e.g., adding or stopping RtpTransceivers, or the session, e.g., adding or stopping RtpTransceivers, or
requesting an ICE restart. For each existing stream, the requesting an ICE restart. For each existing stream, the
generation of each SDP line <bcp14>MUST</bcp14> follow the process def ined generation of each SDP line <bcp14>MUST</bcp14> follow the process def ined
for generating an updated offer from the RFC that specifies for generating an updated offer from the specification that defines
the given SDP line. For each new stream, the generation of the given SDP line. For each new stream, the generation of
the SDP <bcp14>MUST</bcp14> follow the process of generating an initia l the SDP <bcp14>MUST</bcp14> follow the process of generating an initia l
offer, as mentioned above. If no changes have been made, or offer, as mentioned above. The exact handling of subsequent
for SDP lines that are unaffected by the requested changes,
the offer will only contain the parameters negotiated by the
last offer/answer exchange. The exact handling of subsequent
offer generation is detailed in offer generation is detailed in
<xref target="sec.subsequent-offers" format="default"/> below.</t> <xref target="sec.subsequent-offers" format="default"/> below.</t>
<t>Session descriptions generated by createOffer <bcp14>MUST</bcp14> b e <t>Session descriptions generated by createOffer <bcp14>MUST</bcp14> b e
immediately usable by setLocalDescription; if a system has immediately usable by setLocalDescription; if a system has
limited resources (e.g., a finite number of decoders), limited resources (e.g., a finite number of decoders),
createOffer <bcp14>SHOULD</bcp14> return an offer that reflects the cu rrent createOffer <bcp14>SHOULD</bcp14> return an offer that reflects the cu rrent
state of the system, so that setLocalDescription will succeed state of the system, so that setLocalDescription will succeed
when it attempts to acquire those resources.</t> when it attempts to acquire those resources.</t>
<t>Calling this method may do things such as generating new <t>Calling this method may do things such as generating new
ICE credentials, but it does not change the PeerConnection ICE credentials, but it does not change the PeerConnection
skipping to change at line 1239 skipping to change at line 1239
</section> </section>
<section anchor="sec.createanswer" numbered="true" toc="default"> <section anchor="sec.createanswer" numbered="true" toc="default">
<name>createAnswer</name> <name>createAnswer</name>
<t>The createAnswer method generates a blob of SDP that <t>The createAnswer method generates a blob of SDP that
contains an SDP answer per <xref target="RFC3264" format="default"/> w ith the supported contains an SDP answer per <xref target="RFC3264" format="default"/> w ith the supported
configuration for the session that is compatible with the configuration for the session that is compatible with the
parameters supplied in the most recent call to parameters supplied in the most recent call to
setRemoteDescription; setRemoteDescription <bcp14>MUST</bcp14> have be en called prior to setRemoteDescription; setRemoteDescription <bcp14>MUST</bcp14> have be en called prior to
calling createAnswer. Like createOffer, the returned blob calling createAnswer. Like createOffer, the returned blob
contains descriptions of the media added to this contains descriptions of the media added to this
PeerConnection, the codec/RTP/RTCP options negotiated for PeerConnection; the codec, RTP, and RTCP options supported by the appl
this session, and any candidates that have been gathered by ication; and any candidates that have been gathered by
the ICE agent. An options parameter may be supplied to the ICE agent. An options parameter may be supplied to
provide additional control over the generated answer.</t> provide additional control over the generated answer.</t>
<t>As an answer, the generated SDP will contain a specific <t>As an answer, the generated SDP will contain a specific
configuration that specifies how the media plane should be configuration that specifies how the media plane should be
established; for each SDP line, the generation of the SDP established; for each SDP line, the generation of the SDP
<bcp14>MUST</bcp14> follow the process defined for generating an answe r from <bcp14>MUST</bcp14> follow the process defined for generating an answe r from
the specification that defines the given SDP line. The exact the specification that defines the given SDP line. The exact
handling of answer generation is detailed in handling of answer generation is detailed in
<xref target="sec.generating-an-answer" format="default"/> below.</t> <xref target="sec.generating-an-answer" format="default"/> below.</t>
<t>Session descriptions generated by createAnswer <bcp14>MUST</bcp14> be <t>Session descriptions generated by createAnswer <bcp14>MUST</bcp14> be
skipping to change at line 1278 skipping to change at line 1277
<t>"offer" indicates that a description <bcp14>MUST</bcp14> be parsed as <t>"offer" indicates that a description <bcp14>MUST</bcp14> be parsed as
an offer; said description may include many possible media an offer; said description may include many possible media
configurations. A description used as an "offer" may be configurations. A description used as an "offer" may be
applied any time the PeerConnection is in a "stable" state or applied any time the PeerConnection is in a "stable" state or
applied as an update to a previously supplied but unanswered applied as an update to a previously supplied but unanswered
"offer".</t> "offer".</t>
<t>"pranswer" indicates that a description <bcp14>MUST</bcp14> be pars ed <t>"pranswer" indicates that a description <bcp14>MUST</bcp14> be pars ed
as an answer, but not a final answer, and so <bcp14>MUST NOT</bcp14> as an answer, but not a final answer, and so <bcp14>MUST NOT</bcp14>
result in the freeing of allocated resources. It may result result in the freeing of allocated resources. It may result
in the start of media transmission, if the answer does not in the start of media transmission, if the answer does not
specify an inactive media direction. A description used as a specify an "inactive" media direction. A description used as a
"pranswer" may be applied as a response to an "offer" or as an "pranswer" may be applied as a response to an "offer" or as an
update to a previously sent "pranswer".</t> update to a previously sent "pranswer".</t>
<t>"answer" indicates that a description <bcp14>MUST</bcp14> be parsed as <t>"answer" indicates that a description <bcp14>MUST</bcp14> be parsed as
an answer, the offer/answer exchange <bcp14>MUST</bcp14> be considered an answer, the offer/answer exchange <bcp14>MUST</bcp14> be considered
complete, and any resources (decoders, candidates) that are complete, and any resources (decoders, candidates) that are
no longer needed <bcp14>SHOULD</bcp14> be released. A description used as an no longer needed <bcp14>SHOULD</bcp14> be released. A description used as an
"answer" may be applied as a response to an "offer" or as an "answer" may be applied as a response to an "offer" or as an
update to a previously sent "pranswer".</t> update to a previously sent "pranswer".</t>
<t>The only difference between a provisional and final answer <t>The only difference between a provisional and final answer
is that the final answer results in the freeing of any unused is that the final answer results in the freeing of any unused
skipping to change at line 1327 skipping to change at line 1326
offer to update the previous offer/answer pair and start offer to update the previous offer/answer pair and start
bidirectional media flow. While this could also be done bidirectional media flow. While this could also be done
with a "sendonly" pranswer followed by a "sendrecv" with a "sendonly" pranswer followed by a "sendrecv"
answer, the initial pranswer leaves the offer/answer answer, the initial pranswer leaves the offer/answer
exchange open, which means that the caller cannot send an exchange open, which means that the caller cannot send an
updated offer during this time. </t> updated offer during this time. </t>
<t>As an example, consider a typical JSEP application that <t>As an example, consider a typical JSEP application that
wants to set up audio and video as quickly as possible. wants to set up audio and video as quickly as possible.
When the callee receives an offer with audio and video When the callee receives an offer with audio and video
MediaStreamTracks, it will send an immediate answer MediaStreamTracks, it will send an immediate answer
accepting these tracks as sendonly (meaning that the caller accepting these tracks as "sendonly" (meaning that the caller
will not send the callee any media yet, and because the will not send the callee any media yet, and because the
callee has not yet added its own MediaStreamTracks, the callee has not yet added its own MediaStreamTracks, the
callee will not send any media either). It will then ask callee will not send any media either). It will then ask
the user to accept the call and acquire the needed local the user to accept the call and acquire the needed local
tracks. Upon acceptance by the user, the application will tracks. Upon acceptance by the user, the application will
plug in the tracks it has acquired, which, because ICE handshaking plug in the tracks it has acquired, which, because ICE handshaking
and DTLS handshaking have likely completed by this point, can and DTLS handshaking have likely completed by this point, can
start transmitting immediately. The application will also start transmitting immediately. The application will also
send a new offer to the remote side indicating call send a new offer to the remote side indicating call
acceptance and moving the audio and video to be two-way acceptance and moving the audio and video to be two-way
skipping to change at line 1492 skipping to change at line 1491
<xref target="sec.ice-candidate-trickling" format="default"/>, JSEP <xref target="sec.ice-candidate-trickling" format="default"/>, JSEP
implementations always provide candidates to the application implementations always provide candidates to the application
individually, consistent with what is needed for Trickle ICE. individually, consistent with what is needed for Trickle ICE.
However, applications can use the canTrickleIceCandidates However, applications can use the canTrickleIceCandidates
property to determine whether their peer can actually do property to determine whether their peer can actually do
Trickle ICE, i.e., whether it is safe to send an initial Trickle ICE, i.e., whether it is safe to send an initial
offer or answer followed later by candidates as they are offer or answer followed later by candidates as they are
gathered. As "true" is the only value that definitively gathered. As "true" is the only value that definitively
indicates remote Trickle ICE support, an application that indicates remote Trickle ICE support, an application that
compares canTrickleIceCandidates against "true" will by compares canTrickleIceCandidates against "true" will by
default attempt Half Trickle on initial offers and Full default attempt half trickle on initial offers and full
Trickle on subsequent interactions with a Trickle trickle on subsequent interactions with a Trickle
ICE-compatible agent.</t> ICE-compatible agent.</t>
</section> </section>
<section anchor="sec.setconfiguration" numbered="true" toc="default"> <section anchor="sec.setconfiguration" numbered="true" toc="default">
<name>setConfiguration</name> <name>setConfiguration</name>
<t>The setConfiguration method allows the global <t>The setConfiguration method allows the global
configuration of the PeerConnection, which was initially set configuration of the PeerConnection, which was initially set
by constructor parameters, to be changed during the session. by constructor parameters, to be changed during the session.
The effects of calling this method depend on when it is invoked, The effects of calling this method depend on when it is invoked,
and they will differ, depending on which specific parameters are and they will differ, depending on which specific parameters are
changed: </t> changed: </t>
skipping to change at line 1568 skipping to change at line 1567
ICE candidate generation. However, if both fields are null ICE candidate generation. However, if both fields are null
for a new remote candidate, this <bcp14>MUST</bcp14> be treated as an for a new remote candidate, this <bcp14>MUST</bcp14> be treated as an
invalid condition, as specified below.</t> invalid condition, as specified below.</t>
<t>If any IceCandidate fields contain invalid values or an <t>If any IceCandidate fields contain invalid values or an
error occurs during the processing of the IceCandidate error occurs during the processing of the IceCandidate
object, the supplied IceCandidate <bcp14>MUST</bcp14> be ignored and a n object, the supplied IceCandidate <bcp14>MUST</bcp14> be ignored and a n
error <bcp14>MUST</bcp14> be returned.</t> error <bcp14>MUST</bcp14> be returned.</t>
<t>Otherwise, the new remote candidate or end-of-candidates <t>Otherwise, the new remote candidate or end-of-candidates
indication is supplied to the ICE agent. In the case of a new indication is supplied to the ICE agent. In the case of a new
remote candidate, connectivity checks will be sent to the new remote candidate, connectivity checks will be sent to the new
candidate, assuming setLocalDescription has already been candidate, assuming that setLocalDescription has already been
called to initialize the ICE gathering process.</t> called to initialize the ICE gathering process.</t>
</section> </section>
<section anchor="sec.onicecandidate" numbered="true" toc="default"> <section anchor="sec.onicecandidate" numbered="true" toc="default">
<name>onicecandidate Event</name> <name>onicecandidate Event</name>
<t>The onicecandidate event is dispatched to the application in two <t>The onicecandidate event is dispatched to the application in two
situations: (1) when the ICE agent has discovered a new allowed local situations: (1) when the ICE agent has discovered a new allowed local
ICE candidate during ICE gathering, as outlined in ICE candidate during ICE gathering, as outlined in
<xref target="sec.ice-gather-overview" format="default"></xref> and <xref target="sec.ice-gather-overview" format="default"></xref> and
subject to the restrictions discussed in subject to the restrictions discussed in
<xref target="sec.ice-candidate-policy" format="default"></xref>, or <xref target="sec.ice-candidate-policy" format="default"></xref>, or
skipping to change at line 1594 skipping to change at line 1593
This candidate will also be added to the current and/or pending local This candidate will also be added to the current and/or pending local
description according to the rules defined for Trickle ICE.</t> description according to the rules defined for Trickle ICE.</t>
<t>In the second case, the event's IceCandidate object <t>In the second case, the event's IceCandidate object
<bcp14>MUST</bcp14> have its candidate field set to null to indicate <bcp14>MUST</bcp14> have its candidate field set to null to indicate
that the current gathering phase is complete, i.e., there will be no that the current gathering phase is complete, i.e., there will be no
further onicecandidate events in this phase. However, the further onicecandidate events in this phase. However, the
IceCandidate's ufrag field <bcp14>MUST</bcp14> be specified to IceCandidate's ufrag field <bcp14>MUST</bcp14> be specified to
indicate which ICE candidate generation is ending. The IceCandidate's indicate which ICE candidate generation is ending. The IceCandidate's
"m=" section index and MID fields <bcp14>MAY</bcp14> be specified to i ndicate that "m=" section index and MID fields <bcp14>MAY</bcp14> be specified to i ndicate that
the event applies to a specific "m=" section, or set to null to the event applies to a specific "m=" section, or set to null to
indicate it applies to all "m=" sections in the current ICE candidate indicate that it applies to all "m=" sections in the current ICE candi date
generation. This event can be used by the application to generate an generation. This event can be used by the application to generate an
end-of-candidates indication, as defined in end-of-candidates indication, as defined in
<xref target="RFC8838" sectionFormat="comma" section="13"/>.</t> <xref target="RFC8838" sectionFormat="comma" section="13"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec.transceiver" numbered="true" toc="default"> <section anchor="sec.transceiver" numbered="true" toc="default">
<name>RtpTransceiver</name> <name>RtpTransceiver</name>
<section anchor="sec.transceiver-stop" numbered="true" toc="default"> <section anchor="sec.transceiver-stop" numbered="true" toc="default">
<name>stop</name> <name>stop</name>
<t>The stop method stops an RtpTransceiver. This will cause <t>The stop method stops an RtpTransceiver. This will cause
skipping to change at line 1634 skipping to change at line 1633
createAnswer. The permitted values for direction are createAnswer. The permitted values for direction are
"recvonly", "sendrecv", "sendonly", and "inactive", mirroring "recvonly", "sendrecv", "sendonly", and "inactive", mirroring
the identically named direction attributes defined in the identically named direction attributes defined in
<xref target="RFC4566" sectionFormat="comma" section="6"/>.</t> <xref target="RFC4566" sectionFormat="comma" section="6"/>.</t>
<t>When creating offers, the transceiver direction is <t>When creating offers, the transceiver direction is
directly reflected in the output, even for re-offers. When directly reflected in the output, even for re-offers. When
creating answers, the transceiver direction is intersected creating answers, the transceiver direction is intersected
with the offered direction, as explained in with the offered direction, as explained in
<xref target="sec.generating-an-answer" format="default"/> below.</t> <xref target="sec.generating-an-answer" format="default"/> below.</t>
<t>Note that while setDirection sets the direction property <t>Note that while setDirection sets the direction property
of the transceiver immediately (<xref target="sec.transceiver-directio n" format="default"/>), this property (<xref target="sec.transceiver-direction" format="default"/>) of the t ransceiver immediately, this property
does not immediately affect whether the transceiver's does not immediately affect whether the transceiver's
RtpSender will send or its RtpReceiver will receive. The RtpSender will send or its RtpReceiver will receive. The
direction in effect is represented by the currentDirection direction in effect is represented by the currentDirection
property, which is only updated when an answer is property, which is only updated when an answer is
applied.</t> applied.</t>
</section> </section>
<section anchor="sec.transceiver-direction" numbered="true" toc="default "> <section anchor="sec.transceiver-direction" numbered="true" toc="default ">
<name>direction</name> <name>direction</name>
<t>The direction property indicates the last value passed <t>The direction property indicates the last value passed
into setDirection. If setDirection has never been called, it into setDirection. If setDirection has never been called, it
is set to the direction the transceiver was initialized is set to the direction the transceiver was initialized
with.</t> with.</t>
</section> </section>
<section anchor="sec.transceiver-current-direction" numbered="true" toc= "default"> <section anchor="sec.transceiver-current-direction" numbered="true" toc= "default">
<name>currentDirection</name> <name>currentDirection</name>
<t>The currentDirection property indicates the last <t>The currentDirection property indicates the last
negotiated direction for the transceiver's associated "m=" negotiated direction for the transceiver's associated "m="
section. More specifically, it indicates the section. More specifically, it indicates the
direction attribute <xref target="RFC3264" format="default"/> of the direction attribute <xref target="RFC3264" format="default"/> of the
associated "m=" section in the last applied answer (including associated "m=" section in the last applied answer (including
provisional answers), with "send" and "recv" directions provisional answers), with the direction
reversed if it was a remote answer. For example, if the reversed if it was a remote answer. For example, if the
direction attribute for the associated "m=" section in a direction attribute for the associated "m=" section in a
remote answer is "recvonly", currentDirection is set to remote answer is "recvonly", currentDirection is set to
"sendonly".</t> "sendonly".</t>
<t>If an answer that references this transceiver has not yet <t>If an answer that references this transceiver has not yet
been applied or if the transceiver is stopped, been applied or if the transceiver is stopped,
currentDirection is set to "null".</t> currentDirection is set to null.</t>
</section> </section>
<section anchor="sec.transceiver-set-codec-preferences" numbered="true" toc="default"> <section anchor="sec.transceiver-set-codec-preferences" numbered="true" toc="default">
<name>setCodecPreferences</name> <name>setCodecPreferences</name>
<t>The setCodecPreferences method sets the codec preferences <t>The setCodecPreferences method sets the codec preferences
of a transceiver, which in turn affect the presence and order of a transceiver, which in turn affect the presence and order
of codecs of the associated "m=" section on future calls to of codecs of the associated "m=" section on future calls to
createOffer and createAnswer. Note that setCodecPreferences createOffer and createAnswer. Note that setCodecPreferences
does not directly affect which codec the implementation does not directly affect which codec the implementation
decides to send. It only affects which codecs the decides to send. It only affects which codecs the
implementation indicates that it prefers to receive, via the implementation indicates that it prefers to receive, via the
skipping to change at line 1715 skipping to change at line 1714
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>ICE, as specified in <li>ICE, as specified in
<xref target="RFC8445" format="default"/>, <bcp14>MUST</bcp14> be us ed. Note that the <xref target="RFC8445" format="default"/>, <bcp14>MUST</bcp14> be us ed. Note that the
remote endpoint may use a lite implementation; remote endpoint may use a lite implementation;
implementations <bcp14>MUST</bcp14> properly handle remote endpoints that implementations <bcp14>MUST</bcp14> properly handle remote endpoints that
use ICE-lite. The remote endpoint may also use use ICE-lite. The remote endpoint may also use
an older version of ICE; implementations <bcp14>MUST</bcp14> properly handle rem ote endpoints that use ICE an older version of ICE; implementations <bcp14>MUST</bcp14> properly handle rem ote endpoints that use ICE
as specified in <xref target="RFC5245" format="default"/>.</li> as specified in <xref target="RFC5245" format="default"/>.</li>
<li>DTLS <li>DTLS
<xref target="RFC6347" format="default"/> or DTLS-SRTP <xref target="RFC6347" format="default"/> <xref target="RFC9147"/> o r DTLS-SRTP
<xref target="RFC5763" format="default"/> <bcp14>MUST</bcp14> be use d, as <xref target="RFC5763" format="default"/> <bcp14>MUST</bcp14> be use d, as
appropriate for the media type, as specified in appropriate for the media type, as specified in
<xref target="RFC8827" format="default"/>.</li> <xref target="RFC8827" format="default"/>.
Note: RFC 8827 requires implementations to support
DTLS 1.2 <xref target="RFC6347" format="default"/> and permits the use of DTLS 1
.3 <xref target="RFC9147"/>.</li>
</ul> </ul>
<t>The SDP security descriptions mechanism for SRTP keying <t>The SDP security descriptions mechanism for Secure Real-time Transp ort Protocol (SRTP) keying
<xref target="RFC4568" format="default"/> <bcp14>MUST NOT</bcp14> be u sed, as discussed in <xref target="RFC4568" format="default"/> <bcp14>MUST NOT</bcp14> be u sed, as discussed in
<xref target="RFC8827" format="default"/>.</t> <xref target="RFC8827" format="default"/>.</t>
</section> </section>
<section anchor="sec.profile-names" numbered="true" toc="default"> <section anchor="sec.profile-names" numbered="true" toc="default">
<name>Profile Names and Interoperability</name> <name>Profile Names and Interoperability</name>
<t>For media "m=" sections, JSEP implementations <bcp14>MUST</bcp14> s upport <t>For media "m=" sections, JSEP implementations <bcp14>MUST</bcp14> s upport
the "UDP/TLS/RTP/SAVPF" profile specified in the "UDP/TLS/RTP/SAVPF" profile specified in
<xref target="RFC5764" format="default"/> as well as the "TCP/DTLS/RTP /SAVPF" <xref target="RFC5764" format="default"/> as well as the "TCP/DTLS/RTP /SAVPF"
profile specified in <xref target="RFC7850" format="default"/> and <bc p14>MUST</bcp14> indicate profile specified in <xref target="RFC7850" format="default"/> and <bc p14>MUST</bcp14> indicate
one of these profiles for each media "m=" line they produce in an offe r. one of these profiles for each media "m=" line they produce in an offe r.
skipping to change at line 1893 skipping to change at line 1894
values <bcp14>MUST</bcp14> be session-level attributes.</t> values <bcp14>MUST</bcp14> be session-level attributes.</t>
<t>Each "m=" section <bcp14>MUST</bcp14> be generated as specified in <t>Each "m=" section <bcp14>MUST</bcp14> be generated as specified in
<xref target="RFC4566" sectionFormat="comma" section="5.14"/>. For the "m=" line <xref target="RFC4566" sectionFormat="comma" section="5.14"/>. For the "m=" line
itself, the following rules <bcp14>MUST</bcp14> be followed: itself, the following rules <bcp14>MUST</bcp14> be followed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the "m=" section is marked as bundle-only, then the <li>If the "m=" section is marked as bundle-only, then the
&lt;port&gt; value <bcp14>MUST</bcp14> be set to zero. Otherwise, th e &lt;port&gt; value is &lt;port&gt; value <bcp14>MUST</bcp14> be set to zero. Otherwise, th e &lt;port&gt; value is
set to the port of the default ICE candidate for this "m=" set to the port of the default ICE candidate for this "m="
section, but given that no candidates are available yet, section, but given that no candidates are available yet,
the default port value of 9 (Discard) <bcp14>MUST</bcp14> be used, a s the default &lt;port&gt; value of 9 (Discard) <bcp14>MUST</bcp14> be used, as
indicated in indicated in
<xref target="RFC8840" sectionFormat="comma" section="4.1.1"/>.</li> <xref target="RFC8840" sectionFormat="comma" section="4.1.1"/>.</li>
<li>To properly indicate use of DTLS, the &lt;proto&gt; <li>To properly indicate use of DTLS, the &lt;proto&gt;
field <bcp14>MUST</bcp14> be set to "UDP/TLS/RTP/SAVPF", as specifie d in field <bcp14>MUST</bcp14> be set to "UDP/TLS/RTP/SAVPF", as specifie d in
<xref target="RFC5764" sectionFormat="comma" section="8"/>.</li> <xref target="RFC5764" sectionFormat="comma" section="8"/>.</li>
<li>If codec preferences have been set for the associated <li>If codec preferences have been set for the associated
transceiver, media formats <bcp14>MUST</bcp14> be generated in the transceiver, media formats <bcp14>MUST</bcp14> be generated in the
corresponding order and <bcp14>MUST</bcp14> exclude any codecs not corresponding order and <bcp14>MUST</bcp14> exclude any codecs not
present in the codec preferences.</li> present in the codec preferences.</li>
<li>Unless excluded by the above restrictions, the media <li>Unless excluded by the above restrictions, the media
skipping to change at line 1953 skipping to change at line 1954
associated transceiver.</li> associated transceiver.</li>
<li>For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" lines, as specified in <li>For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" lines, as specified in
<xref target="RFC4566" sectionFormat="comma" section="6"/> and <xref target="RFC4566" sectionFormat="comma" section="6"/> and
<xref target="RFC3264" sectionFormat="comma" section="5.1"/>.</li> <xref target="RFC3264" sectionFormat="comma" section="5.1"/>.</li>
<li>For each primary codec where RTP retransmission should <li>For each primary codec where RTP retransmission should
be used, a corresponding "a=rtpmap" line indicating "rtx" be used, a corresponding "a=rtpmap" line indicating "rtx"
with the clock rate of the primary codec and an "a=fmtp" with the clock rate of the primary codec and an "a=fmtp"
line that references the payload type of the primary line that references the payload type of the primary
codec, as specified in codec, as specified in
<xref target="RFC4588" sectionFormat="comma" section="8.1"/>.</li> <xref target="RFC4588" sectionFormat="comma" section="8.1"/>.</li>
<li>For each supported Forward Error Correction (FEC) mechanism, "a= rtpmap" and <li>For each Forward Error Correction (FEC) mechanism supported by t he application, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" sectionFormat="comma" section="6"/>. The FE C <xref target="RFC4566" sectionFormat="comma" section="6"/>. The FE C
mechanisms that <bcp14>MUST</bcp14> be supported are specified in mechanisms that <bcp14>MUST</bcp14> be supported are specified in
<xref target="RFC8854" sectionFormat="comma" section="7"/>, <xref target="RFC8854" sectionFormat="comma" section="7"/>,
and specific usage for each media type is outlined in and specific usage for each media type is outlined in
Sections <xref target="sec.interface" format="counter"/> and <xref Sections&nbsp;<xref target="RFC8854" section="4"
target="sec.sdp-interaction-procedure" sectionFormat="bare"/> and <xref target="RFC8854" section="5"
format="counter"/>.</li> sectionFormat="bare"/> of <xref target="RFC8854"/>.</li>
<li>If this "m=" section is for media with configurable <li>If this "m=" section is for media with configurable
durations of media per packet, e.g., audio, an durations of media per packet, e.g., audio, an
"a=maxptime" line, indicating the maximum amount of "a=maxptime" line, indicating the maximum amount of
media, specified in milliseconds, that can be media, specified in milliseconds, that can be
encapsulated in each packet, as specified in encapsulated in each packet, as specified in
<xref target="RFC4566" sectionFormat="comma" section="6"/>. This v alue is <xref target="RFC4566" sectionFormat="comma" section="6"/>. This v alue is
set to the smallest of the maximum duration values across set to the smallest of the maximum duration values across
all the codecs included in the "m=" section.</li> all the codecs included in the "m=" section.</li>
<li>If this "m=" section is for video media and there are <li>If this "m=" section is for video media and there are
known limitations on the size of images that can be known limitations on the size of images that can be
decoded, an "a=imageattr" line, as specified in decoded, an "a=imageattr" line, as specified in
<xref target="sec.imageattr" format="default"/>.</li> <xref target="sec.imageattr" format="default"/>.</li>
<li>For each supported RTP header extension, an "a=extmap" <li>For each RTP header extension supported by the application, an " a=extmap"
line, as specified in line, as specified in
<xref target="RFC5285" sectionFormat="comma" section="5"/>. <xref target="RFC5285" sectionFormat="comma" section="5"/>.
The list of The list of
header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> b e supported is header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> b e supported is
specified in specified in
<xref target="RFC8834" sectionFormat="comma" section="5.2"/>. Any header extensions that require encryption <bcp14>MUST</bcp14> <xref target="RFC8834" sectionFormat="comma" section="5.2"/>. Any header extensions that require encryption <bcp14>MUST</bcp14>
be specified as indicated in be specified as indicated in
<xref target="RFC6904" sectionFormat="comma" section="4"/>.</li> <xref target="RFC6904" sectionFormat="comma" section="4"/>.</li>
<li>For each supported RTCP feedback mechanism, an <li>For each RTCP feedback mechanism supported by the application, a n
"a=rtcp-fb" line, as specified in "a=rtcp-fb" line, as specified in
<xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The list of <xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The list of
RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</b cp14> be supported is RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</b cp14> be supported is
specified in specified in
<xref target="RFC8834" sectionFormat="comma" section="5.1"/>.</li> <xref target="RFC8834" sectionFormat="comma" section="5.1"/>.</li>
<li> <li>
<t>If the RtpTransceiver has a sendrecv or sendonly <t>If the RtpTransceiver has a "sendrecv" or "sendonly"
direction: direction:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>For each MediaStream that was associated with the <li>For each MediaStream that was associated with the
transceiver when it was created via addTrack or transceiver when it was created via addTrack or
addTransceiver, an "a=msid" line, as specified in addTransceiver, an "a=msid" line, as specified in
<xref target="RFC8830" sectionFormat="comma" section="2"/>, <xref target="RFC8830" sectionFormat="comma" section="2"/>,
but omitting the "appdata" field.</li> but omitting the "appdata" field.</li>
</ul> </ul>
</li> </li>
<li>If the RtpTransceiver has a sendrecv or sendonly <li>If the RtpTransceiver has a "sendrecv" or "sendonly"
direction, and the application has specified a rid-id for an encod ing, direction, and the application has specified a rid-id for an encod ing,
or has specified more than one encoding in the or has specified more than one encoding in the
RtpSenders's parameters, an "a=rid" line for each RtpSenders's parameters, an "a=rid" line for each
encoding specified. The "a=rid" line is specified in encoding specified. The "a=rid" line is specified in
<xref target="RFC8851" format="default"/>, and its <xref target="RFC8851" format="default"/>, and its
direction <bcp14>MUST</bcp14> be "send". If the application has ch osen a direction <bcp14>MUST</bcp14> be "send". If the application has ch osen a
rid-id, it <bcp14>MUST</bcp14> be used; rid-id, it <bcp14>MUST</bcp14> be used;
otherwise, a rid-id <bcp14>MUST</bcp14> be generated by the otherwise, a rid-id <bcp14>MUST</bcp14> be generated by the
implementation. rid-ids <bcp14>MUST</bcp14> be generated in a fash ion implementation. &nbsp;rid-ids <bcp14>MUST</bcp14> be generated in a fashion
that does not leak user information, e.g., randomly or that does not leak user information, e.g., randomly or
using a per-PeerConnection counter (see guidance at the end using a per-PeerConnection counter (see guidance at the end
of <xref target="RFC8852" sectionFormat="comma" section="3.3"/>), and <bcp14>SHOULD</bcp14> be 3 bytes of <xref target="RFC8852" sectionFormat="comma" section="3.3"/>), and <bcp14>SHOULD</bcp14> be 3 bytes
or less, to allow them to efficiently fit into the RTP or less, to allow them to efficiently fit into the RTP
header extensions defined in header extensions defined in
<xref target="RFC8852" sectionFormat="comma" section="3.3"/>. <xref target="RFC8852" sectionFormat="comma" section="3.3"/>.
If no encodings have been specified, or only one encoding is If no encodings have been specified, or only one encoding is
specified but without a rid-id, then no "a=rid" lines specified but without a rid-id, then no "a=rid" lines
are generated.</li> are generated.</li>
<li>If the RtpTransceiver has a sendrecv or sendonly <li>If the RtpTransceiver has a "sendrecv" or "sendonly"
direction and more than one "a=rid" line has been direction and more than one "a=rid" line has been
generated, an "a=simulcast" line, with direction "send", generated, an "a=simulcast" line, with direction "send",
as defined in as defined in
<xref target="RFC8853" sectionFormat="comma" <xref target="RFC8853" sectionFormat="comma"
section="5.1"/>. The associated set of rid-ids <bcp14>MUST</bcp14> section="5.1"/>. The associated set of rid-ids <bcp14>MUST</bcp14>
include all of the rid-ids used in the "a=rid" lines for this "m=" include all of the rid-ids used in the "a=rid" lines for this "m="
section.</li> section.</li>
<li>If (1) the bundle policy for this PeerConnection is set to <li>If (1) the bundle policy for this PeerConnection is set to
"must-bundle" and this is not the first "m=" section or (2) "must-bundle" and this is not the first "m=" section or (2)
the bundle policy is set to "balanced" and this is not the bundle policy is set to "balanced" and this is not
skipping to change at line 2071 skipping to change at line 2073
<xref target="RFC8858" sectionFormat="comma" section="4"/>.</li> <xref target="RFC8858" sectionFormat="comma" section="4"/>.</li>
<li>An "a=rtcp-rsize" line, as specified in <li>An "a=rtcp-rsize" line, as specified in
<xref target="RFC5506" sectionFormat="comma" section="5"/>.</li> <xref target="RFC5506" sectionFormat="comma" section="5"/>.</li>
</ul> </ul>
<t>Lastly, if a data channel has been created, an "m=" section <t>Lastly, if a data channel has been created, an "m=" section
<bcp14>MUST</bcp14> be generated for data. The &lt;media&gt; field <bc p14>MUST</bcp14> be <bcp14>MUST</bcp14> be generated for data. The &lt;media&gt; field <bc p14>MUST</bcp14> be
set to "application", and the &lt;proto&gt; field <bcp14>MUST</bcp14> be set set to "application", and the &lt;proto&gt; field <bcp14>MUST</bcp14> be set
to "UDP/DTLS/SCTP" to "UDP/DTLS/SCTP"
<xref target="RFC8841" format="default"/>. The &lt;fmt&gt; <xref target="RFC8841" format="default"/>. The &lt;fmt&gt;
value <bcp14>MUST</bcp14> be set to "webrtc-datachannel" as specified in value <bcp14>MUST</bcp14> be set to "webrtc-datachannel" as specified in
<xref target="RFC8841" sectionFormat="comma" section="4.2.2"/>. <xref target="RFC8841" sectionFormat="comma" section="4.4.2"/>.</t>
</t>
<t>Within the data "m=" section, an "a=mid" line <bcp14>MUST</bcp14> b e <t>Within the data "m=" section, an "a=mid" line <bcp14>MUST</bcp14> b e
generated and included as described above, along with an generated and included as described above, along with an
"a=sctp-port" line referencing the SCTP port number, as "a=sctp-port" line referencing the SCTP port number, as
defined in defined in
<xref target="RFC8841" sectionFormat="comma" section="5.1"/>; <xref target="RFC8841" sectionFormat="comma" section="5.1"/>;
and, if appropriate, an "a=max-message-size" line, as defined and, if appropriate, an "a=max-message-size" line, as defined
in in
<xref target="RFC8841" sectionFormat="comma" section="6.1"/>.</t> <xref target="RFC8841" sectionFormat="comma" section="6.1"/>.</t>
<t>As discussed above, the following attributes of category <t>As discussed above, the following attributes of category
IDENTICAL or TRANSPORT are included only if the data "m=" IDENTICAL or TRANSPORT are included only if the data "m="
skipping to change at line 2096 skipping to change at line 2097
<ul spacing="normal"> <ul spacing="normal">
<li>"a=ice-ufrag"</li> <li>"a=ice-ufrag"</li>
<li>"a=ice-pwd"</li> <li>"a=ice-pwd"</li>
<li>"a=fingerprint"</li> <li>"a=fingerprint"</li>
<li>"a=setup"</li> <li>"a=setup"</li>
<li>"a=tls-id"</li> <li>"a=tls-id"</li>
</ul> </ul>
<t>Once all "m=" sections have been generated, a session-level <t>Once all "m=" sections have been generated, a session-level
"a=group" attribute <bcp14>MUST</bcp14> be added as specified in "a=group" attribute <bcp14>MUST</bcp14> be added as specified in
<xref target="RFC5888" format="default"/>. This attribute <bcp14>MUST< /bcp14> have <xref target="RFC5888" format="default"/>. This attribute <bcp14>MUST< /bcp14> have
semantics "BUNDLE" and <bcp14>MUST</bcp14> include the mid identifiers of semantics "BUNDLE" and <bcp14>MUST</bcp14> include the MID identifiers of
each "m=" section. The effect of this is that the JSEP each "m=" section. The effect of this is that the JSEP
implementation offers all "m=" sections as one bundle group. implementation offers all "m=" sections as one bundle group.
However, whether the "m=" sections are bundle-only or not However, whether the "m=" sections are bundle-only or not
depends on the bundle policy.</t> depends on the bundle policy.</t>
<t>The next step is to generate session-level lip sync groups <t>The next step is to generate session-level lip sync groups
as defined in as defined in
<xref target="RFC5888" sectionFormat="comma" section="7"/>. For each M ediaStream <xref target="RFC5888" sectionFormat="comma" section="7"/>. For each M ediaStream
referenced by more than one RtpTransceiver (by passing those referenced by more than one RtpTransceiver (by passing those
MediaStreams as arguments to the addTrack and addTransceiver MediaStreams as arguments to the addTrack and addTransceiver
methods), a group of type "LS" <bcp14>MUST</bcp14> be added that conta ins methods), a group of type "LS" <bcp14>MUST</bcp14> be added that conta ins
skipping to change at line 2275 skipping to change at line 2276
transceiver and also <bcp14>MUST</bcp14> include all currently avail able transceiver and also <bcp14>MUST</bcp14> include all currently avail able
formats. Media formats that were previously offered but are formats. Media formats that were previously offered but are
no longer available (e.g., a shared hardware codec) <bcp14>MAY</bcp1 4> be no longer available (e.g., a shared hardware codec) <bcp14>MAY</bcp1 4> be
excluded.</li> excluded.</li>
<li>Unless codec preferences have been set for the <li>Unless codec preferences have been set for the
associated transceiver, the media formats on the "m=" line associated transceiver, the media formats on the "m=" line
<bcp14>MUST</bcp14> be generated in the same order as in the most re cent <bcp14>MUST</bcp14> be generated in the same order as in the most re cent
answer. Any media formats that were not present in the most answer. Any media formats that were not present in the most
recent answer <bcp14>MUST</bcp14> be added after all existing format s.</li> recent answer <bcp14>MUST</bcp14> be added after all existing format s.</li>
<li>The RTP header extensions <bcp14>MUST</bcp14> only include those that <li>The RTP header extensions <bcp14>MUST</bcp14> only include those that
are present in the most recent answer.</li> are supported by the application on the associated transceiver.</li>
<li>The RTCP feedback mechanisms <bcp14>MUST</bcp14> only include th ose <li>The RTCP feedback mechanisms <bcp14>MUST</bcp14> only include th ose
that are present in the most recent answer, except for the that are supported by the application on the associated transceiver.
case of format-specific mechanisms that are referencing a </li>
newly added media format.</li>
<li>The "a=rtcp" line <bcp14>MUST NOT</bcp14> be added if the most r ecent <li>The "a=rtcp" line <bcp14>MUST NOT</bcp14> be added if the most r ecent
answer included an "a=rtcp-mux" line.</li> answer included an "a=rtcp-mux" line.</li>
<li>The "a=rtcp-mux" line <bcp14>MUST</bcp14> be the same as that in the <li>The "a=rtcp-mux" line <bcp14>MUST</bcp14> be the same as that in the
most recent answer.</li> most recent answer.</li>
<li>The "a=rtcp-mux-only" line <bcp14>MUST NOT</bcp14> be added.</li > <li>The "a=rtcp-mux-only" line <bcp14>MUST NOT</bcp14> be added.</li >
<li>The "a=rtcp-rsize" line <bcp14>MUST NOT</bcp14> be added unless present <li>The "a=rtcp-rsize" line <bcp14>MUST NOT</bcp14> be added unless present
in the most recent answer.</li> in the most recent answer.</li>
<li>An "a=bundle-only" line, as defined in <li>An "a=bundle-only" line, as defined in
<xref target="RFC9143" sectionFormat="comma" section="6"/>, <xref target="RFC9143" sectionFormat="comma" section="6"/>,
<bcp14>MUST NOT</bcp14> be added. <bcp14>MUST NOT</bcp14> be added.
skipping to change at line 2314 skipping to change at line 2313
into a preceding non-bundle-only media "m=" section.</li> into a preceding non-bundle-only media "m=" section.</li>
</ul> </ul>
<t>The "a=group:BUNDLE" attribute <bcp14>MUST</bcp14> include the MID <t>The "a=group:BUNDLE" attribute <bcp14>MUST</bcp14> include the MID
identifiers specified in the bundle group in the most recent identifiers specified in the bundle group in the most recent
answer, minus any "m=" sections that have been marked as answer, minus any "m=" sections that have been marked as
rejected, plus any newly added or re-enabled "m=" sections. In rejected, plus any newly added or re-enabled "m=" sections. In
other words, the bundle attribute <bcp14>MUST</bcp14> contain all "m=" other words, the bundle attribute <bcp14>MUST</bcp14> contain all "m="
sections that were previously bundled, as long as they are sections that were previously bundled, as long as they are
still alive, as well as any new "m=" sections.</t> still alive, as well as any new "m=" sections.</t>
<t>Note that if bundling has been negotiated, unbundling is no longer <t>Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only. This i possible, and media sections will not be marked as bundle-only. Althou
s gh this is
by design, but could cause issues in the rare case of sending a by design, it could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint subsequent offer as an initial offer to a non-bundle-aware endpoint
via Third Party Call Control (3PCC), as discussed in <xref target="RFC 9143" sectionFormat="comma" section="7.6"/>.</t> via Third Party Call Control (3PCC), as discussed in <xref target="RFC 9143" sectionFormat="comma" section="7.6"/>.</t>
<t>"a=group:LS" attributes are generated in the same way as <t>"a=group:LS" attributes are generated in the same way as
for initial offers, with the additional stipulation that any for initial offers, with the additional stipulation that any
lip sync groups that were present in the most recent answer lip sync groups that were present in the most recent answer
<bcp14>MUST</bcp14> continue to exist and <bcp14>MUST</bcp14> contain any previously <bcp14>MUST</bcp14> continue to exist and <bcp14>MUST</bcp14> contain any previously
existing MID identifiers, as long as the identified "m=" existing MID identifiers, as long as the identified "m="
sections still exist and are not rejected, and the group sections still exist and are not rejected, and the group
still contains at least two MID identifiers. This ensures still contains at least two MID identifiers. This ensures
that any synchronized "recvonly" "m=" sections continue to be that any synchronized "recvonly" "m=" sections continue to be
skipping to change at line 2340 skipping to change at line 2339
<t>The createOffer method takes as a parameter an <t>The createOffer method takes as a parameter an
RTCOfferOptions object. Special processing is performed when RTCOfferOptions object. Special processing is performed when
generating an SDP description if the following options are generating an SDP description if the following options are
present.</t> present.</t>
<section anchor="sec.icerestart" numbered="true" toc="default"> <section anchor="sec.icerestart" numbered="true" toc="default">
<name>IceRestart</name> <name>IceRestart</name>
<t>If the IceRestart option is specified, with a value of <t>If the IceRestart option is specified, with a value of
"true", the offer <bcp14>MUST</bcp14> indicate an ICE restart by "true", the offer <bcp14>MUST</bcp14> indicate an ICE restart by
generating new ICE ufrag and pwd attributes, as specified generating new ICE ufrag and pwd attributes, as specified
in in
<xref target="RFC8839" sectionFormat="comma" section="4.4.3.1.1"/>. If this <xref target="RFC8839" sectionFormat="comma" section="4.4.1.1.1"/>. If this
option is specified on an initial offer, it has no effect option is specified on an initial offer, it has no effect
(since a new ICE ufrag and pwd are already generated). (since a new ICE ufrag and pwd are already generated).
Similarly, if the ICE configuration has changed, this Similarly, if the ICE configuration has changed, this
option has no effect, since new ufrag and pwd attributes option has no effect, since new ufrag and pwd attributes
will be generated automatically. This option is primarily will be generated automatically. This option is primarily
useful for reestablishing connectivity in cases where useful for reestablishing connectivity in cases where
failures are detected by the application.</t> failures are detected by the application.</t>
</section> </section>
<section anchor="sec.voiceactivitydetection1" numbered="true" toc="def ault"> <section anchor="sec.voiceactivitydetection1" numbered="true" toc="def ault">
<name>VoiceActivityDetection</name> <name>VoiceActivityDetection</name>
<t>Silence suppression, also known as discontinuous <t>Silence suppression, also known as discontinuous
transmission ("DTX"), can reduce the bandwidth used for transmission ("DTX"), can reduce the bandwidth used for
audio by switching to a special encoding when voice audio by switching to a special encoding when voice
activity is not detected, at the cost of some fidelity.</t> activity is not detected, at the cost of some fidelity.</t>
<t>If the "VoiceActivityDetection" option is specified, <t>If the VoiceActivityDetection option is specified,
with a value of "true", the offer <bcp14>MUST</bcp14> indicate suppo rt for with a value of "true", the offer <bcp14>MUST</bcp14> indicate suppo rt for
silence suppression in the audio it receives by including silence suppression in the audio it receives by including
comfort noise ("CN") codecs for each offered audio codec, comfort noise ("CN") codecs for each offered audio codec,
as specified in as specified in
<xref target="RFC3389" sectionFormat="comma" section="5.1"/>, except for <xref target="RFC3389" sectionFormat="comma" section="5.1"/>, except for
codecs that have their own internal silence suppression codecs that have their own internal silence suppression
support. For codecs that have their own internal silence support. For codecs that have their own internal silence
suppression support, the appropriate fmtp parameters for suppression support, the appropriate fmtp parameters for
that codec <bcp14>MUST</bcp14> be specified to indicate that silence each such codec <bcp14>MUST</bcp14> be specified to indicate that si lence
suppression for received audio is desired. For example, suppression for received audio is desired. For example,
when using the Opus codec when using the Opus codec
<xref target="RFC6716" format="default"/>, the "usedtx=1" parameter, <xref target="RFC6716" format="default"/>, the "usedtx=1" parameter,
specified in specified in
<xref target="RFC7587" format="default"/>, would be used in the offe r.</t> <xref target="RFC7587" format="default"/>, would be used in the offe r.</t>
<t>If the "VoiceActivityDetection" option is specified, <t>If the VoiceActivityDetection option is specified,
with a value of "false", the JSEP implementation <bcp14>MUST NOT</bc p14> with a value of "false", the JSEP implementation <bcp14>MUST NOT</bc p14>
emit "CN" codecs. For codecs that have their own internal emit "CN" codecs. For codecs that have their own internal
silence suppression support, the appropriate fmtp silence suppression support, the appropriate fmtp
parameters for that codec <bcp14>MUST</bcp14> be specified to indica te parameters for each such codec <bcp14>MUST</bcp14> be specified to i ndicate
that silence suppression for received audio is not desired. that silence suppression for received audio is not desired.
For example, when using the Opus codec, the "usedtx=0" For example, when using the Opus codec, the "usedtx=0"
parameter would be specified in the offer. In addition, the parameter would be specified in the offer. In addition, the
implementation <bcp14>MUST NOT</bcp14> use silence suppression for m edia implementation <bcp14>MUST NOT</bcp14> use silence suppression for m edia
it generates, regardless of whether the "CN" codecs or it generates, regardless of whether the "CN" codecs or
related fmtp parameters appear in the peer's description. related fmtp parameters appear in the peer's description.
The impact of these rules is that silence suppression in The impact of these rules is that silence suppression in
JSEP depends on mutual agreement of both sides, which JSEP depends on mutual agreement of both sides, which
ensures consistent handling regardless of which codec is ensures consistent handling regardless of which codec is
used.</t> used.</t>
<t>The "VoiceActivityDetection" option does not have any <t>The VoiceActivityDetection option does not have any
impact on the setting of the "vad" value in the signaling impact on the setting of the "vad" value in the signaling
of the client-to-mixer audio level header extension of the client-to-mixer audio level header extension
described in described in
<xref target="RFC6464" sectionFormat="comma" section="4"/>.</t> <xref target="RFC6464" sectionFormat="comma" section="4"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec.generating-an-answer" numbered="true" toc="default"> <section anchor="sec.generating-an-answer" numbered="true" toc="default">
<name>Generating an Answer</name> <name>Generating an Answer</name>
<t>When createAnswer is called, a new SDP description <bcp14>MUST</bcp14 > be <t>When createAnswer is called, a new SDP description <bcp14>MUST</bcp14 > be
skipping to change at line 2490 skipping to change at line 2489
<sourcecode name="" type="sdp"><![CDATA[ <sourcecode name="" type="sdp"><![CDATA[
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=recvonly a=recvonly
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=recvonly ]]></sourcecode> a=recvonly ]]></sourcecode>
<t>The example in <xref target="sec.detailed-example" format="default" /> shows a more involved case of "LS" group <t>The example in <xref target="sec.detailed-example" format="default" /> shows a more involved case of "LS" group
generation.</t> generation.</t>
<t>The next step is to generate a "m=" section for each "m=" <t>The next step is to generate an "m=" section for each "m="
section that is present in the remote offer, as specified in section that is present in the remote offer, as specified in
<xref target="RFC3264" sectionFormat="comma" section="6"/>. For the pu rposes <xref target="RFC3264" sectionFormat="comma" section="6"/>. For the pu rposes
of this discussion, any session-level attributes in the offer of this discussion, any session-level attributes in the offer
that are also valid as media-level attributes are considered that are also valid as media-level attributes are considered
to be present in each "m=" section. Each offered "m=" section to be present in each "m=" section. Each offered "m=" section
will have an associated RtpTransceiver, as described in will have an associated RtpTransceiver, as described in
<xref target="sec.applying-a-remote-desc" format="default"/>. If there are <xref target="sec.applying-a-remote-desc" format="default"/>. If there are
more RtpTransceivers than there are "m=" sections, the more RtpTransceivers than there are "m=" sections, the
unmatched RtpTransceivers will need to be associated in a unmatched RtpTransceivers will need to be associated in a
subsequent offer.</t> subsequent offer.</t>
skipping to change at line 2591 skipping to change at line 2590
"recvonly" direction.</li> "recvonly" direction.</li>
<li>For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" lines, as specified in <li>For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" lines, as specified in
<xref target="RFC4566" sectionFormat="comma" section="6"/> and <xref target="RFC4566" sectionFormat="comma" section="6"/> and
<xref target="RFC3264" sectionFormat="comma" section="6.1"/>.</li> <xref target="RFC3264" sectionFormat="comma" section="6.1"/>.</li>
<li>If "rtx" is present in the offer, for each primary codec <li>If "rtx" is present in the offer, for each primary codec
where RTP retransmission should be used, a corresponding where RTP retransmission should be used, a corresponding
"a=rtpmap" line indicating "rtx" with the clock rate of the "a=rtpmap" line indicating "rtx" with the clock rate of the
primary codec and an "a=fmtp" line that references the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in payload type of the primary codec, as specified in
<xref target="RFC4588" sectionFormat="comma" section="8.1"/>.</li> <xref target="RFC4588" sectionFormat="comma" section="8.1"/>.</li>
<li>For each supported FEC mechanism, "a=rtpmap" and <li>For each FEC mechanism supported by the application, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" sectionFormat="comma" section="6"/>. The FEC <xref target="RFC4566" sectionFormat="comma" section="6"/>. The FEC
mechanisms that <bcp14>MUST</bcp14> be supported are specified in mechanisms that <bcp14>MUST</bcp14> be supported are specified in
<xref target="RFC8854" sectionFormat="comma" section="7"/>, and <xref target="RFC8854" sectionFormat="comma" section="7"/>, and
specific usage for each media type is outlined in Sections specific usage for each media type is outlined in
<xref target="sec.interface" format="counter"/> and <xref Sections&nbsp;<xref target="RFC8854" section="4"
target="sec.sdp-interaction-procedure" format="counter"/>.</li> sectionFormat="bare"/> and <xref target="RFC8854" section="5"
sectionFormat="bare"/> of <xref target="RFC8854"/>.</li>
<li>If this "m=" section is for media with configurable <li>If this "m=" section is for media with configurable
durations of media per packet, e.g., audio, an "a=maxptime" durations of media per packet, e.g., audio, an "a=maxptime"
line, as described in line, as described in
<xref target="sec-create-offer" format="default"/>.</li> <xref target="sec-create-offer" format="default"/>.</li>
<li>If this "m=" section is for video media and there are <li>If this "m=" section is for video media and there are
known limitations on the size of images that can be known limitations on the size of images that can be
decoded, an "a=imageattr" line, as specified in decoded, an "a=imageattr" line, as specified in
<xref target="sec.imageattr" format="default"/>.</li> <xref target="sec.imageattr" format="default"/>.</li>
<li>For each supported RTP header extension that is present <li>For each RTP header extension supported by the application and p resent
in the offer, an "a=extmap" line, as specified in in the offer, an "a=extmap" line, as specified in
<xref target="RFC5285" sectionFormat="comma" section="5"/>. The list of <xref target="RFC5285" sectionFormat="comma" section="5"/>. The list of
header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> be supported is header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> be supported is
specified in specified in
<xref target="RFC8834" sectionFormat="comma" section="5.2"/>. Any he ader extensions that require encryption <bcp14>MUST</bcp14> be <xref target="RFC8834" sectionFormat="comma" section="5.2"/>. Any he ader extensions that require encryption <bcp14>MUST</bcp14> be
specified as indicated in specified as indicated in
<xref target="RFC6904" sectionFormat="comma" section="4"/>.</li> <xref target="RFC6904" sectionFormat="comma" section="4"/>.</li>
<li>For each supported RTCP feedback mechanism that is <li>For each RTCP feedback mechanism supported by the application an d
present in the offer, an "a=rtcp-fb" line, as specified in present in the offer, an "a=rtcp-fb" line, as specified in
<xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The li st of <xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The li st of
RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp 14> be supported is RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp 14> be supported is
specified in specified in
<xref target="RFC8834" sectionFormat="comma" section="5.1"/>.</li> <xref target="RFC8834" sectionFormat="comma" section="5.1"/>.</li>
<li> <li>
<t>If the RtpTransceiver has a sendrecv or sendonly <t>If the RtpTransceiver has a "sendrecv" or "sendonly"
direction: direction:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>For each MediaStream that was associated with the <li>For each MediaStream that was associated with the
transceiver when it was created via addTrack or transceiver when it was created via addTrack or
addTransceiver, an "a=msid" line, as specified in addTransceiver, an "a=msid" line, as specified in
<xref target="RFC8830" sectionFormat="comma" section="2"/>, <xref target="RFC8830" sectionFormat="comma" section="2"/>,
but omitting the "appdata" field.</li> but omitting the "appdata" field.</li>
</ul> </ul>
</li> </li>
skipping to change at line 2696 skipping to change at line 2696
<li>"a=ice-pwd"</li> <li>"a=ice-pwd"</li>
<li>"a=fingerprint"</li> <li>"a=fingerprint"</li>
<li>"a=setup"</li> <li>"a=setup"</li>
<li>"a=tls-id"</li> <li>"a=tls-id"</li>
</ul> </ul>
<t>Note that if media "m=" sections are bundled into a data "m=" <t>Note that if media "m=" sections are bundled into a data "m="
section, then certain TRANSPORT and IDENTICAL attributes may section, then certain TRANSPORT and IDENTICAL attributes may
also appear in the data "m=" section even if they would also appear in the data "m=" section even if they would
otherwise only be appropriate for a media "m=" section (e.g., otherwise only be appropriate for a media "m=" section (e.g.,
"a=rtcp-mux").</t> "a=rtcp-mux").</t>
<t>If "a=group" attributes with semantics of "BUNDLE" are <t>If "a=group" attributes with semantics "BUNDLE" are
offered, corresponding session-level "a=group" attributes offered, corresponding session-level "a=group" attributes
<bcp14>MUST</bcp14> be added as specified in <bcp14>MUST</bcp14> be added as specified in
<xref target="RFC5888" format="default"/>. These attributes <bcp14>MUS T</bcp14> have <xref target="RFC5888" format="default"/>. These attributes <bcp14>MUS T</bcp14> have
semantics "BUNDLE" and <bcp14>MUST</bcp14> include all mid identifiers semantics "BUNDLE" and <bcp14>MUST</bcp14> include all MID identifiers
from the offered bundle groups that have not been rejected. from the offered bundle groups that have not been rejected.
Note that regardless of the presence of "a=bundle-only" in Note that regardless of the presence of "a=bundle-only" in
the offer, all "m=" sections in the answer <bcp14>MUST NOT</bcp14> hav e an the offer, all "m=" sections in the answer <bcp14>MUST NOT</bcp14> hav e an
"a=bundle-only" line.</t> "a=bundle-only" line.</t>
<t>Attributes that are common between all "m=" sections <bcp14>MAY</bc p14> be <t>Attributes that are common between all "m=" sections <bcp14>MAY</bc p14> be
moved to the session level if explicitly defined to be valid at moved to the session level if explicitly defined to be valid at
the session level.</t> the session level.</t>
<t>The attributes prohibited in the creation of offers are <t>The attributes prohibited in the creation of offers are
also prohibited in the creation of answers.</t> also prohibited in the creation of answers.</t>
</section> </section>
skipping to change at line 2796 skipping to change at line 2796
</ul> </ul>
</section> </section>
<section anchor="sec.options-handling2" numbered="true" toc="default"> <section anchor="sec.options-handling2" numbered="true" toc="default">
<name>Options Handling</name> <name>Options Handling</name>
<t>The createAnswer method takes as a parameter an <t>The createAnswer method takes as a parameter an
RTCAnswerOptions object. The set of parameters for RTCAnswerOptions object. The set of parameters for
RTCAnswerOptions is different than those supported in RTCAnswerOptions is different than those supported in
RTCOfferOptions; the IceRestart option is unnecessary, as ICE RTCOfferOptions; the IceRestart option is unnecessary, as ICE
credentials will automatically be changed for all "m=" sections credentials will automatically be changed for all "m=" sections
where the offerer chose to perform ICE restart.</t> where the offerer chose to perform ICE restart.</t>
<t>The following options are supported in <t>The following option is supported in
RTCAnswerOptions.</t> RTCAnswerOptions.</t>
<section anchor="sec.voiceactivitydetection2" numbered="true" toc="def ault"> <section anchor="sec.voiceactivitydetection2" numbered="true" toc="def ault">
<name>VoiceActivityDetection</name> <name>VoiceActivityDetection</name>
<t>Silence suppression in the answer is handled as <t>Silence suppression in the answer is handled as
described in described in
<xref target="sec.voiceactivitydetection1" format="default"/>, with <xref target="sec.voiceactivitydetection1" format="default"/>, with
one exception: if support for silence suppression was not one exception: if support for silence suppression was not
indicated in the offer, the VoiceActivityDetection indicated in the offer, the VoiceActivityDetection
parameter has no effect, and the answer <bcp14>MUST</bcp14> be gener ated parameter has no effect, and the answer <bcp14>MUST</bcp14> be gener ated
as if VoiceActivityDetection was set to "false". This is done as if VoiceActivityDetection was set to "false". This is done
on a per-codec basis (e.g., if the offerer somehow offered on a per-codec basis (e.g., if the offerer somehow offered
support for CN but set "usedtx=0" for Opus, setting support for CN but set "usedtx=0" for Opus, setting
VoiceActivityDetection to "true" would result in an answer VoiceActivityDetection to "true" would result in an answer
with CN codecs and "usedtx=0"). The impact of this rule is with "CN" codecs and "usedtx=0"). The impact of this rule is
that an answerer will not try to use silence suppression that an answerer will not try to use silence suppression
with any endpoint that does not offer it, making silence with any endpoint that does not offer it, making silence
suppression support bilateral even with non-JSEP suppression support bilateral even with non-JSEP
endpoints.</t> endpoints.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec.modifying-sdp" numbered="true" toc="default"> <section anchor="sec.modifying-sdp" numbered="true" toc="default">
<name>Modifying an Offer or Answer</name> <name>Modifying an Offer or Answer</name>
<t>The SDP returned from createOffer or createAnswer <bcp14>MUST NOT</bc p14> <t>The SDP returned from createOffer or createAnswer <bcp14>MUST NOT</bc p14>
skipping to change at line 2932 skipping to change at line 2932
once the answerer has performed setLocalDescription with its once the answerer has performed setLocalDescription with its
answer, this cannot be rolled back.</t> answer, this cannot be rolled back.</t>
<t>The effect of rollback <bcp14>MUST</bcp14> be the same regardless of <t>The effect of rollback <bcp14>MUST</bcp14> be the same regardless of
whether setLocalDescription or setRemoteDescription is whether setLocalDescription or setRemoteDescription is
called.</t> called.</t>
<t>In order to process rollback, a JSEP implementation abandons <t>In order to process rollback, a JSEP implementation abandons
the current offer/answer transaction, sets the signaling state the current offer/answer transaction, sets the signaling state
to "stable", and sets the pending local and/or remote to "stable", and sets the pending local and/or remote
description (see Sections description (see Sections
<xref target="sec.pendinglocaldescription" format="counter"/> and <xref target="sec.pendinglocaldescription" format="counter"/> and
<xref target="sec.pendingremotedescription" format="counter"/>) to "null ". Any <xref target="sec.pendingremotedescription" format="counter"/>) to null. Any
resources or candidates that were allocated by the abandoned resources or candidates that were allocated by the abandoned
local description are discarded; any media that is received is local description are discarded; any media that is received is
processed according to the previous local and remote processed according to the previous local and remote
descriptions.</t> descriptions.</t>
<t>A rollback disassociates any RtpTransceivers that were <t>A rollback disassociates any RtpTransceivers that were
associated with "m=" sections by the application of the associated with "m=" sections by the application of the
rolled-back session description (see Sections rolled-back session description (see Sections
<xref target="sec.applying-a-remote-desc" format="counter"/> and <xref target="sec.applying-a-remote-desc" format="counter"/> and
<xref target="sec.applying-a-local-desc" format="counter"/>). <xref target="sec.applying-a-local-desc" format="counter"/>).
This means that This means that
some RtpTransceivers that were previously associated will no some RtpTransceivers that were previously associated will no
longer be associated with any "m=" section; in such cases, the longer be associated with any "m=" section; in such cases, the
value of the RtpTransceiver's mid property <bcp14>MUST</bcp14> be set to "null", value of the RtpTransceiver's mid property <bcp14>MUST</bcp14> be set to null,
and the mapping between the transceiver and its "m=" section and the mapping between the transceiver and its "m=" section
index <bcp14>MUST</bcp14> be discarded. RtpTransceivers that were create d by index <bcp14>MUST</bcp14> be discarded. RtpTransceivers that were create d by
applying a remote offer that was subsequently rolled back <bcp14>MUST</b cp14> applying a remote offer that was subsequently rolled back <bcp14>MUST</b cp14>
be stopped and removed from the PeerConnection. However, an be stopped and removed from the PeerConnection. However, an
RtpTransceiver <bcp14>MUST NOT</bcp14> be removed if a track was attache d to RtpTransceiver <bcp14>MUST NOT</bcp14> be removed if a track was attache d to
the RtpTransceiver via the addTrack method. This is so that an the RtpTransceiver via the addTrack method. This is so that an
application may call addTrack, then call setRemoteDescription application may call addTrack, then call setRemoteDescription
with an offer, then roll back that offer, then call createOffer with an offer, then roll back that offer, then call createOffer
and have an "m=" section for the added track appear in the and have an "m=" section for the added track appear in the
generated offer.</t> generated offer.</t>
skipping to change at line 3020 skipping to change at line 3020
<xref target="RFC4566" sectionFormat="comma" section="5.8"/>, and th e bwtype and <xref target="RFC4566" sectionFormat="comma" section="5.8"/>, and th e bwtype and
bandwidth values stored.</li> bandwidth values stored.</li>
</ul> </ul>
<t>Finally, the attribute lines are processed. Specific <t>Finally, the attribute lines are processed. Specific
processing <bcp14>MUST</bcp14> be applied for the following session-le vel processing <bcp14>MUST</bcp14> be applied for the following session-le vel
attribute ("a=") lines: attribute ("a=") lines:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Any "a=group" lines are parsed as specified in <li>Any "a=group" lines are parsed as specified in
<xref target="RFC5888" sectionFormat="comma" section="5"/>, and the group's <xref target="RFC5888" sectionFormat="comma" section="5"/>, and the group's
semantics and mids are stored.</li> semantics and MID values are stored.</li>
<li>If present, a single "a=ice-lite" line is parsed as <li>If present, a single "a=ice-lite" line is parsed as
specified in specified in
<xref target="RFC8839" sectionFormat="comma" section="5.3"/>, and a value <xref target="RFC8839" sectionFormat="comma" section="5.3"/>, and a value
indicating the presence of ice-lite is stored.</li> indicating the presence of an "a=ice-lite" line is stored.</li>
<li>If present, a single "a=ice-ufrag" line is parsed as <li>If present, a single "a=ice-ufrag" line is parsed as
specified in specified in
<xref target="RFC8839" sectionFormat="comma" section="5.4"/>, and th e ufrag value is stored.</li> <xref target="RFC8839" sectionFormat="comma" section="5.4"/>, and th e ufrag value is stored.</li>
<li>If present, a single "a=ice-pwd" line is parsed as <li>If present, a single "a=ice-pwd" line is parsed as
specified in specified in
<xref target="RFC8839" sectionFormat="comma" section="5.4"/>, and th e password value is stored.</li> <xref target="RFC8839" sectionFormat="comma" section="5.4"/>, and th e password value is stored.</li>
<li>If present, a single "a=ice-options" line is parsed as <li>If present, a single "a=ice-options" line is parsed as
specified in specified in
<xref target="RFC8839" sectionFormat="comma" section="5.6"/>, and th e set of specified options is stored.</li> <xref target="RFC8839" sectionFormat="comma" section="5.6"/>, and th e set of specified options is stored.</li>
<li>Any "a=fingerprint" lines are parsed as specified in <li>Any "a=fingerprint" lines are parsed as specified in
skipping to change at line 3426 skipping to change at line 3426
<li>If an "a=end-of-candidates" attribute is present, process <li>If an "a=end-of-candidates" attribute is present, process
the end-of-candidates indication as described in the end-of-candidates indication as described in
<xref target="RFC8838" sectionFormat="comma" section="14"/>.</li> <xref target="RFC8838" sectionFormat="comma" section="14"/>.</li>
<li> <li>
<t>If the "m=" section &lt;proto&gt; value indicates use of RTP: <t>If the "m=" section &lt;proto&gt; value indicates use of RTP:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the "m=" section is being recycled (see <li>If the "m=" section is being recycled (see
<xref target="sec.subsequent-offers" format="default"/>), disassoci ate <xref target="sec.subsequent-offers" format="default"/>), disassoci ate
the currently associated RtpTransceiver by setting its mid the currently associated RtpTransceiver by setting its mid
property to "null", and discard the mapping between the property to null, and discard the mapping between the
transceiver and its "m=" section index.</li> transceiver and its "m=" section index.</li>
<li> <li>
<t>If the "m=" section is not associated with any <t>If the "m=" section is not associated with any
RtpTransceiver (possibly because it was disassociated in the RtpTransceiver (possibly because it was disassociated in the
previous step), either find an RtpTransceiver or create one previous step), either find an RtpTransceiver or create one
according to the following steps: according to the following steps:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the "m=" section is sendrecv or recvonly, and there <li>If the "m=" section is "sendrecv" or "recvonly", and ther e
are RtpTransceivers of the same type that were added to are RtpTransceivers of the same type that were added to
the PeerConnection by addTrack and are not associated the PeerConnection by addTrack and are not associated
with any "m=" section and are not stopped, find the first with any "m=" section and are not stopped, find the first
(according to the canonical order described in (according to the canonical order described in
<xref target="sec.initial-offers" format="default"/>) such <xref target="sec.initial-offers" format="default"/>) such
RtpTransceiver.</li> RtpTransceiver.</li>
<li>If no RtpTransceiver was found in the previous step, <li>If no RtpTransceiver was found in the previous step,
create one with a recvonly direction.</li> create one with a "recvonly" direction.</li>
<li>Associate the found or created RtpTransceiver with the <li>Associate the found or created RtpTransceiver with the
"m=" section by setting the value of the RtpTransceiver's "m=" section by setting the value of the RtpTransceiver's
mid property to the MID of the "m=" section, and establish mid property to the MID of the "m=" section, and establish
a mapping between the transceiver and the index of the "m=" a mapping between the transceiver and the index of the "m="
section. If the "m=" section does not include a MID (i.e., section. If the "m=" section does not include a MID (i.e.,
the remote endpoint does not support the MID extension), the remote endpoint does not support the MID extension),
generate a value for the RtpTransceiver mid property, generate a value for the RtpTransceiver mid property,
following the guidance for "a=mid" mentioned in following the guidance for "a=mid" mentioned in
<xref target="sec.initial-offers" format="default"/>.</li> <xref target="sec.initial-offers" format="default"/>.</li>
</ul> </ul>
</li> </li>
<li>For each specified media format that is also supported <li>For each specified media format that is also supported
by the local implementation, establish a mapping between by the local application, establish a mapping between
the specified payload type and the media format, as the specified payload type and the media format, as
described in described in
<xref target="RFC3264" sectionFormat="comma" section="6.1"/>. Speci fically, this <xref target="RFC3264" sectionFormat="comma" section="6.1"/>. Speci fically, this
means that the implementation records the payload type to means that the implementation records the payload type to
be used in outgoing RTP packets when sending each specified be used in outgoing RTP packets when sending each specified
media format, as well as the relative preference for each media format, as well as the relative preference for each
format that is indicated in their ordering. If any format that is indicated in their ordering. If any
indicated media format is not supported by the local indicated media format is not supported by the local
implementation, it <bcp14>MUST</bcp14> be ignored.</li> application, it <bcp14>MUST</bcp14> be ignored.</li>
<li>For each specified "rtx" media format, establish a <li>For each specified "rtx" media format, establish a
mapping between the RTX payload type and its associated mapping between the RTX payload type and its associated
primary payload type, as described in primary payload type, as described in
<xref target="RFC4588" sectionFormat="comma" section="4"/>. If any referenced <xref target="RFC4588" sectionFormat="comma" section="4"/>. If any referenced
primary payload types are not present, this <bcp14>MUST</bcp14> res ult in primary payload types are not present, this <bcp14>MUST</bcp14> res ult in
an error. Note that RTX payload types may refer to primary an error. Note that RTX payload types may refer to primary
payload types that are not supported by the local media payload types that are not supported by the local media
implementation, in which case the RTX payload type <bcp14>MUST</bcp 14> implementation, in which case the RTX payload type <bcp14>MUST</bcp 14>
also be ignored.</li> also be ignored.</li>
<li>For each specified fmtp parameter that is supported by <li>For each specified fmtp parameter that is supported by
the local implementation, enable them on the associated the local application, enable them on the associated
media formats.</li> media formats.</li>
<li>For each specified Synchronization Source (SSRC) that is sign aled in the "m=" <li>For each specified Synchronization Source (SSRC) that is sign aled in the "m="
section, prepare to demux RTP streams intended for this "m=" section, prepare to demux RTP streams intended for this "m="
section using that SSRC, as described in section using that SSRC, as described in
<xref target="RFC9143" sectionFormat="comma" section="9.2"/>.</li> <xref target="RFC9143" sectionFormat="comma" section="9.2"/>.</li>
<li>For each specified RTP header extension that is also <li>For each specified RTP header extension that is also
supported by the local implementation, establish a mapping supported by the local application, establish a mapping
between the extension ID and URI, as described in between the extension ID and URI, as described in
<xref target="RFC5285" sectionFormat="comma" section="5"/>. Specifi cally, this <xref target="RFC5285" sectionFormat="comma" section="5"/>. Specifi cally, this
means that the implementation records the extension ID to means that the implementation records the extension ID to
be used in outgoing RTP packets when sending each specified be used in outgoing RTP packets when sending each specified
header extension. If any indicated RTP header extension is header extension. If any indicated RTP header extension is
not supported by the local implementation, it <bcp14>MUST</bcp14> b e not supported by the local application, it <bcp14>MUST</bcp14> be
ignored.</li> ignored.</li>
<li>For each specified RTCP feedback mechanism that is <li>For each specified RTCP feedback mechanism that is also
supported by the local implementation, enable them on the supported by the local application, enable them on the
associated media formats.</li> associated media formats.</li>
<li> <li>
<t>For any specified "TIAS" ("Transport <t>For any specified "TIAS" ("Transport
Independent Application Specific Maximum") bandwidth value, set this value Independent Application Specific (maximum)") bandwidth value, set this valu e
as a constraint on the maximum RTP bitrate to be used when as a constraint on the maximum RTP bitrate to be used when
sending media, as specified in sending media, as specified in
<xref target="RFC3890" format="default"/>. If a "TIAS" value is not <xref target="RFC3890" format="default"/>. If a "TIAS" value is not
present but an "AS" value is specified, generate a "TIAS" present but an "AS" value is specified, generate a "TIAS"
value using this formula: value using this formula:
</t> </t>
<ul empty="true"> <t indent="3">
<li>TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)</li> TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)
</ul> </t>
<t> <t>
The 1000 changes the unit from kbps to bps (as required The 1000 changes the unit from kbps to bps (as required
by TIAS), and the 0.95 is to allocate 5% to RTCP. by TIAS), and the 0.95 is to allocate 5% to RTCP.
An estimate of header overhead is then subtracted out, in which An estimate of header overhead is then subtracted out, in which
the 50 is based on 50 packets per second, the 40 is based on the 50 is based on 50 packets per second, the 40 is based on
typical header size (in bytes), and the 8 converts bytes to bits. typical header size (in bytes), and the 8 converts bytes to bits.
Note that "TIAS" is preferred over Note that "TIAS" is preferred over
"AS" because it provides more accurate "AS" because it provides more accurate
control of bandwidth.</t> control of bandwidth.</t>
</li> </li>
skipping to change at line 3567 skipping to change at line 3567
local or remote description, the following steps are performed local or remote description, the following steps are performed
when processing a description of type "pranswer" or when processing a description of type "pranswer" or
"answer".</t> "answer".</t>
<t>For each "m=" section, the following steps <bcp14>MUST</bcp14> be pe rformed: <t>For each "m=" section, the following steps <bcp14>MUST</bcp14> be pe rformed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the "m=" section has been rejected (i.e., the &lt;port&gt; val ue is set to <li>If the "m=" section has been rejected (i.e., the &lt;port&gt; val ue is set to
zero in the answer), stop any reception or transmission of zero in the answer), stop any reception or transmission of
media for this section, and, unless a non-rejected "m=" section media for this section, and, unless a non-rejected "m=" section
is bundled with this "m=" section, discard any associated ICE is bundled with this "m=" section, discard any associated ICE
components, as described in components, as described in the second bullet item in
<xref target="RFC8839" sectionFormat="comma" section="4.4.3.1"/>.</li > <xref target="RFC8839" sectionFormat="comma" section="4.4.3.1"/>.</li >
<li>If the remote DTLS fingerprint has been changed or the <li>If the remote DTLS fingerprint has been changed or the
value of the "a=tls-id" attribute has changed, tear down the DTLS co nnection. This value of the "a=tls-id" attribute has changed, tear down the DTLS co nnection. This
includes the case when the PeerConnection state is includes the case when the PeerConnection state is
"have-remote-pranswer". If a DTLS connection needs to be torn "have-remote-pranswer". If a DTLS connection needs to be torn
down but the answer does not indicate an ICE restart or, in down but the answer does not indicate an ICE restart or, in
the case of "have-remote-pranswer", new ICE credentials, an the case of "have-remote-pranswer", new ICE credentials, an
error <bcp14>MUST</bcp14> be generated. If an ICE restart is perform ed error <bcp14>MUST</bcp14> be generated. If an ICE restart is perform ed
without a change in the tls-id value or fingerprint, then the same D TLS without a change in the tls-id value or fingerprint, then the same D TLS
connection is continued over the new ICE channel. Note that connection is continued over the new ICE channel. Note that
skipping to change at line 3724 skipping to change at line 3724
"m=" section is defined in "m=" section is defined in
<xref target="RFC9143" sectionFormat="comma" section="9.2"/>. When not b undling, the proper "m=" section is clear from the <xref target="RFC9143" sectionFormat="comma" section="9.2"/>. When not b undling, the proper "m=" section is clear from the
ICE component over which the RTP/RTCP is received.</t> ICE component over which the RTP/RTCP is received.</t>
<t>Once the proper "m=" section or sections are known, RTP/RTCP is deliv ered <t>Once the proper "m=" section or sections are known, RTP/RTCP is deliv ered
to the RtpTransceiver(s) associated with the "m=" section(s) and to the RtpTransceiver(s) associated with the "m=" section(s) and
further processing of the RTP/RTCP is done at the RtpTransceiver further processing of the RTP/RTCP is done at the RtpTransceiver
level. This includes using the RID mechanism level. This includes using the RID mechanism
<xref target="RFC8851" format="default"/> and its associated RtpStreamId and <xref target="RFC8851" format="default"/> and its associated RtpStreamId and
RepairedRtpStreamId identifiers to distinguish between RepairedRtpStreamId identifiers to distinguish between
multiple encoded streams and determine which Source RTP multiple encoded streams and determine which Source RTP
stream should be repaired by a given redundancy RTP stream.</t> Stream should be repaired by a given redundancy RTP stream.</t>
</section> </section>
<section anchor="sec.examples" numbered="true" toc="default"> <section anchor="sec.examples" numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<t>Note that this example section shows several SDP fragments. To <t>Note that this example section shows several SDP fragments. To
accommodate RFC line-length restrictions, some of the SDP lines have bee n split accommodate RFC line-length restrictions, some of the SDP lines have bee n split
into multiple lines, where leading whitespace indicates that a into multiple lines, where leading whitespace indicates that a
line is a continuation of the previous line. In addition, some line is a continuation of the previous line. In addition, some
blank lines have been added to improve readability but are not blank lines have been added to improve readability but are not
valid in SDP.</t> valid in SDP.</t>
<t>More examples of SDP for WebRTC call flows, including examples <t>More examples of SDP for WebRTC call flows, including examples
with IPv6 addresses, can be found in with IPv6 addresses, can be found in
<xref target="I-D.ietf-rtcweb-sdp" format="default"/>.</t> <xref target="SDP4WebRTC" format="default"/>.</t>
<section anchor="sec.simple-examples" numbered="true" toc="default"> <section anchor="sec.simple-examples" numbered="true" toc="default">
<name>Simple Example</name> <name>Simple Example</name>
<t>This section shows a very simple example that sets up a <t>This section shows a very simple example that sets up a
minimal audio/video call between two JSEP endpoints without minimal audio/video call between two JSEP endpoints without
using Trickle ICE. The example in the following section using Trickle ICE. The example in the following section
provides a more detailed example of what could happen in a JSEP provides a more detailed example of what could happen in a JSEP
session.</t> session.</t>
<t>The code flow below shows Alice's endpoint initiating the <t>The code flow below shows Alice's endpoint initiating the
session to Bob's endpoint. The messages from the JavaScript session to Bob's endpoint. The messages from the JavaScript
application in Alice's browser to the JavaScript in Bob's application in Alice's browser to the JavaScript in Bob's
skipping to change at line 3936 skipping to change at line 3936
<name>Detailed Example</name> <name>Detailed Example</name>
<t>This section shows a more involved example of a session <t>This section shows a more involved example of a session
between two JSEP endpoints. Trickle ICE is used in full trickle between two JSEP endpoints. Trickle ICE is used in full trickle
mode, with a bundle policy of "must-bundle", an RTCP mux policy mode, with a bundle policy of "must-bundle", an RTCP mux policy
of "require", and a single TURN server. Initially, both Alice of "require", and a single TURN server. Initially, both Alice
and Bob establish an audio channel and a data channel. Later, and Bob establish an audio channel and a data channel. Later,
Bob adds two video flows -- one for his video feed and one for Bob adds two video flows -- one for his video feed and one for
screen sharing, both supporting FEC -- with the video feed screen sharing, both supporting FEC -- with the video feed
configured for simulcast. Alice accepts these video flows but configured for simulcast. Alice accepts these video flows but
does not add video flows of her own, so they are handled as does not add video flows of her own, so they are handled as
recvonly. Alice also specifies a maximum video decoder "recvonly". Alice also specifies a maximum video decoder
resolution.</t> resolution.</t>
<artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
// set up local media state // set up local media state
AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: create new PeerConnection
AliceJS->AliceUA: addTrack with an audio track AliceJS->AliceUA: addTrack with an audio track
AliceJS->AliceUA: createDataChannel to get data channel AliceJS->AliceUA: createDataChannel to get data channel
AliceJS->AliceUA: createOffer to get |offer-B1| AliceJS->AliceUA: createOffer to get |offer-B1|
AliceJS->AliceUA: setLocalDescription with |offer-B1| AliceJS->AliceUA: setLocalDescription with |offer-B1|
skipping to change at line 4164 skipping to change at line 4164
ufrag 7sFv ufrag 7sFv
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay
raddr 198.51.100.200 rport 11200 ]]></sourcecode> raddr 198.51.100.200 rport 11200 ]]></sourcecode>
<t>The SDP for |offer-B2| is shown below. In addition to the <t>The SDP for |offer-B2| is shown below. In addition to the
new "m=" sections for video, both of which are offering FEC and new "m=" sections for video, both of which are offering FEC and
one of which is offering simulcast, note the increment of the one of which is offering simulcast, note the increment of the
version number in the "o=" line; changes to the "c=" line, version number in the "o=" line; changes to the "c=" line,
indicating the local candidate that was selected; and the indicating the local candidate that was selected; and the
inclusion of gathered candidates as a=candidate lines.</t> inclusion of gathered candidates as "a=candidate" lines.</t>
<sourcecode name="offer-B2" type="sdp"><![CDATA[ <sourcecode name="offer-B2" type="sdp"><![CDATA[
v=0 v=0
o=- 7729291447651054566 2 IN IP4 0.0.0.0 o=- 7729291447651054566 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
skipping to change at line 4254 skipping to change at line 4254
a=rtpmap:103 rtx/90000 a=rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=rtpmap:104 flexfec/90000 a=rtpmap:104 flexfec/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae ]]></sourcecode> a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae ]]></sourcecode>
<t>The SDP for |answer-B2| is shown below. In addition to the <t>The SDP for |answer-B2| is shown below. In addition to the
acceptance of the video "m=" sections, the use of a=recvonly to acceptance of the video "m=" sections, the use of "a=recvonly" to
indicate one-way video, and the use of a=imageattr to limit the indicate one-way video, and the use of "a=imageattr" to limit the
received resolution, note the use of setup:passive to maintain received resolution, note the use of "a=setup:passive" to maintain
the existing DTLS roles.</t> the existing DTLS roles.</t>
<sourcecode name="answer-B2" type="sdp"><![CDATA[ <sourcecode name="answer-B2" type="sdp"><![CDATA[
v=0 v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0 o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1 a=group:LS a1 v1
skipping to change at line 4348 skipping to change at line 4348
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli ]]></sourcecode> a=rtcp-fb:100 nack pli ]]></sourcecode>
</section> </section>
<section anchor="sec.warmup-example" numbered="true" toc="default"> <section anchor="sec.warmup-example" numbered="true" toc="default">
<name>Early Transport Warmup Example</name> <name>Early Transport Warmup Example</name>
<t>This example demonstrates the early-warmup technique <t>This example demonstrates the early-warmup technique
described in described in
<xref target="sec.use-of-provisional-answer" format="default"/>. Here, Alice's <xref target="sec.use-of-provisional-answer" format="default"/>. Here, Alice's
endpoint sends an offer to Bob's endpoint to start an endpoint sends an offer to Bob's endpoint to start an
audio/video call. Bob immediately responds with an answer that audio/video call. Bob immediately responds with an answer that
accepts the audio/video "m=" sections but marks them as sendonly accepts the audio/video "m=" sections but marks them as "sendonly"
(from his perspective), meaning that Alice will not yet send (from his perspective), meaning that Alice will not yet send
media. This allows the JSEP implementation to start negotiating media. This allows the JSEP implementation to start negotiating
ICE and DTLS immediately. Bob's endpoint then prompts him to ICE and DTLS immediately. Bob's endpoint then prompts him to
answer the call, and when he does, his endpoint sends a second answer the call, and when he does, his endpoint sends a second
offer, which enables the audio and video "m=" sections, and offer, which enables the audio and video "m=" sections, and
thereby bidirectional media transmission. The advantage of such thereby bidirectional media transmission. The advantage of such
a flow is that as soon as the first answer is received, the a flow is that as soon as the first answer is received, the
implementation can proceed with ICE and DTLS negotiation and implementation can proceed with ICE and DTLS negotiation and
establish the session transport. If the transport setup establish the session transport. If the transport setup
completes before the second offer is sent, then media can be completes before the second offer is sent, then media can be
skipping to change at line 4702 skipping to change at line 4702
derived from createOffer or createAnswer, there is no derived from createOffer or createAnswer, there is no
guarantee that applications do so. The JSEP implementation <bcp14>MUST</ bcp14> guarantee that applications do so. The JSEP implementation <bcp14>MUST</ bcp14>
be prepared for the JavaScript to pass in bogus data instead.</t> be prepared for the JavaScript to pass in bogus data instead.</t>
<t>Conversely, the application programmer needs to be aware that <t>Conversely, the application programmer needs to be aware that
the JavaScript does not have complete control of endpoint the JavaScript does not have complete control of endpoint
behavior. One case that bears particular mention is that editing behavior. One case that bears particular mention is that editing
ICE candidates out of the SDP or suppressing trickled candidates ICE candidates out of the SDP or suppressing trickled candidates
does not have the expected behavior: implementations will still does not have the expected behavior: implementations will still
perform checks from those candidates even if they are not sent to perform checks from those candidates even if they are not sent to
the other side. Thus, for instance, it is not possible to prevent the other side. Thus, for instance, it is not possible to prevent
the remote peer from learning your public IP address by removing the remote peer from learning an application's public IP address by remo ving
server-reflexive candidates. Applications that wish to conceal server-reflexive candidates. Applications that wish to conceal
their public IP address <bcp14>MUST</bcp14> instead configure the ICE ag ent to their public IP address <bcp14>MUST</bcp14> instead configure the ICE ag ent to
use only relay candidates.</t> use only relay candidates.</t>
</section> </section>
<section anchor="sec.iana-considerations" numbered="true" toc="default"> <section anchor="sec.iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-rtcweb-sdp" to="SDP4WebRTC"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8840" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8840.xml"
c8840"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8852.xml"
<title>A Session Initiation Protocol (SIP) Usage for Incremental />
Provisioning of Candidates for the Interactive Connectivity <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8838.xml"
Establishment (Trickle ICE)</title> />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8842.xml"
<author initials="E" surname="Ivov" fullname="Emil Ivov"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8839.xml"
</author> />
<author initials="T" surname="Stach" fullname="Thomas Stach"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8830.xml"
<organization/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8858.xml"
<author initials="E" surname="Marocco" fullname="Enrico Marocco"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8851.xml"
</author> />
<author initials="C" surname="Holmberg" fullname="Christer Holmber <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8841.xml"
g"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8859.xml"
</author> />
<date month="January" year="2021"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8853.xml"
</front> />
<seriesInfo name="RFC" value="8840"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8854.xml"
<seriesInfo name="DOI" value="10.17487/RFC8840"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8834.xml"
/>
<reference anchor="RFC8852" target="https://www.rfc-editor.org/info/rfc8852"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8826.xml"
<front> />
<title>RTP Stream Identifier Source Description (SDES)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8827.xml"
<author initials="A.B." surname="Roach" fullname="Adam Roach"/> />
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar"/>
<author initials="P" surname="Thatcher" fullname="Peter Thatcher"/>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8852"/>
<seriesInfo name="DOI" value="10.17487/RFC8852"/>
</reference>
<reference anchor="RFC8838" target="https://www.rfc-editor.org/info/rfc8838">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol</title>
<author initials="E" surname="Ivov" fullname="Emil Ivov">
<organization />
</author>
<author initials="J" surname="Uberti" fullname="Justin Uberti">
<organization />
</author>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8838" />
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>
<reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8842">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</tit
le>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization />
</author>
<author initials="R." surname="Shpount" fullname="Roman Shpount">
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8842" />
<seriesInfo name="DOI" value="10.17487/RFC8842"/>
</reference>
<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactiv
e Connectivity Establishment (ICE)</title>
<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
<organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='A' surname='Keränen' fullname='Ari Keränen'>
<organization />
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'>
<organization />
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>
<reference anchor="RFC8830" target="https://www.rfc-editor.org/info/rfc8830">
<front>
<title>WebRTC MediaStream Identification in the Session Description Protocol
</title>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8830" />
<seriesInfo name="DOI" value="10.17487/RFC8830"/>
</reference>
<reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<front>
<title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<date month="January" year='2021' />
</front>
<seriesInfo name='RFC' value='8858' />
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>
<reference anchor="RFC8851" target="https://www.rfc-editor.org/info/rfc8851">
<front>
<title>RTP Payload Format Restrictions</title>
<author initials="A.B." surname="Roach" fullname="Adam Roach" role="editor">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8851"/>
<seriesInfo name="DOI" value="10.17487/RFC8851"/>
</reference>
<reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for
Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer
Security (DTLS) Transport</title>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization />
</author>
<author initials="R." surname="Shpount" fullname="Roman Shpount">
<organization />
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization />
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8841" />
<seriesInfo name="DOI" value="10.17487/RFC8841"/>
</reference>
<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
<front>
<title>A Framework for Session Description Protocol (SDP)
Attributes When Multiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference>
<reference anchor="RFC8853" target="https://www.rfc-editor.org/info/rfc8853">
<front>
<title>Using Simulcast in Session Description Protocol (SDP) and RTP
Sessions</title>
<author initials="B" surname="Burman" fullname="Bo Burman">
<organization/>
</author>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlund">
<organization/>
</author>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
<organization/>
</author>
<author initials="M" surname="Zanaty" fullname="Mo Zanaty">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8853"/>
<seriesInfo name="DOI" value="10.17487/RFC8853"/>
</reference>
<reference anchor="RFC8854" target="https://www.rfc-editor.org/info/rfc8854">
<front>
<title>WebRTC Forward Error Correction Requirements</title>
<author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8854"/>
<seriesInfo name="DOI" value="10.17487/RFC8854"/>
</reference>
<reference anchor="RFC8834" target="https://www.rfc-editor.org/info/rfc8834">
<front>
<title>Media Transport and Use of RTP in WebRTC</title>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization />
</author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization />
</author>
<author initials="J." surname="Ott" fullname="Jörg Ott">
<organization />
</author>
<date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8834" />
<seriesInfo name="DOI" value="10.17487/RFC8834"/>
</reference>
<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3605. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3605.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3890. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3890.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4145. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4145.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5285. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5285.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5761. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5761.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5888. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5888.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6236. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6236.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6716. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6716.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7160. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7160.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7587. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7587.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7742. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7742.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7850. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7850.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7874. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7874.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8108. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8108.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8122. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8122.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8829. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8829.xml"
xml"/> />
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9143. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9143.xml"
xml"/> />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"
/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8828" target="https://www.rfc-editor.org/info/rfc8828"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8828.xml"
/>
<!-- draft-ietf-rtcweb-sdp (Expired (IESG: Dead)) ("long way" to fix author
initials) -->
<reference anchor="SDP4WebRTC">
<front> <front>
<title>WebRTC IP Address Handling Requirements</title> <title>Annotated Example SDP for WebRTC</title>
<author initials="J" surname="Uberti" fullname="Justin Uberti"> <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
<organization /> <organization>Cisco</organization>
</author> </author>
<author initials="G" surname="Shieh" fullname="Guo-wei Shieh"> <author fullname="Cullen Jennings" initials="C. F." surname="Jennings">
<organization /> <organization>Cisco</organization>
</author> </author>
<date day="17" month="December" year="2020"/>
<date month="January" year="2021" />
</front> </front>
<seriesInfo name="RFC" value="8828" /> <seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-sdp-14"/>
<seriesInfo name="DOI" value="10.17487/RFC8828"/>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3389.xml"
-rtcweb-sdp.xml"/> />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3389. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4588.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4733.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4588. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5245.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4733. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5245. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5576.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5506. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5576. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6464.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6120. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3556.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3960.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3556. />
xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8843.xml"
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3960. />
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8843.
xml"/>
<reference anchor="W3C.webrtc" <reference anchor="W3C.webrtc"
target="https://www.w3.org/TR/2021/REC-webrtc-20210126/"> target="https://www.w3.org/TR/2023/REC-webrtc-20230306/">
<front> <front>
<title>WebRTC 1.0: Real-time Communication Between Browsers</title> <title>WebRTC: Real-time Communication Between Browsers</title>
<author fullname="Cullen Jennings" initials="C." <author fullname="Cullen Jennings" initials="C."
surname="Jennings" role="editor"> surname="Jennings" role="editor">
<organization>Cisco</organization> <organization>Cisco</organization>
</author> </author>
<author fullname="Florent Castelli" initials="F." surname="Castelli"
role="editor">
<organization>Google</organization>
</author>
<author <author
fullname="Henrik Boström" fullname="Henrik Boström"
asciiFullname="Henrik Bostrom" asciiFullname="Henrik Bostrom"
initials="H." initials="H."
surname="Boström" surname="Boström"
asciiSurname="Bostrom" asciiSurname="Bostrom"
role="editor"> role="editor">
<organization>Google</organization> <organization>Google</organization>
</author> </author>
<author fullname="Jan-Ivar Bruaroey" initials="J." <author fullname="Jan-Ivar Bruaroey" initials="J-I."
surname="Bruaroey" role="editor"> surname="Bruaroey" role="editor">
<organization>Mozilla</organization> <organization>Mozilla</organization>
</author> </author>
<date month="Jan" year="2021"/> <date month="March" year="2023"/>
</front> </front>
<refcontent>World Wide Web Consortium Recommendation</refcontent> <refcontent>W3C Recommendation</refcontent>
</reference> </reference>
<reference anchor="TS26.114" target="https://www.3gpp.org/DynaReport/261 14.htm"> <reference anchor="TS26.114" target="https://www.3gpp.org/DynaReport/261 14.htm">
<front> <front>
<title>3rd Generation Partnership Project; Technical <title>3rd Generation Partnership Project; Technical Specification G
Specification Group Services and System Aspects; IP roup Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Tele
Multimedia Subsystem (IMS); Multimedia Telephony; Media phony; Media handling and interaction (Release 18)</title>
handling and interaction (Release 16)</title>
<seriesInfo name="3GPP TS" value="26.114 V16.3.0"/>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year="2019" month="September"/> <date year="2023" month="September"/>
</front> </front>
<refcontent>3GPP TS 26.114 V18.4.0</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="sec.appendix-a" numbered="true" toc="default"> <section anchor="sec.appendix-a" numbered="true" toc="default">
<name>SDP ABNF Syntax</name> <name>SDP ABNF Syntax</name>
<t>For the syntax validation performed in <t>For the syntax validation performed in
<xref target="sec.parsing-a-desc" format="default"/>, the following list o f ABNF <xref target="sec.parsing-a-desc" format="default"/>, the following list o f ABNF
definitions is used:</t> definitions is used:</t>
<table anchor="sdp-abnf" align="center"> <table anchor="sdp-abnf" align="center">
skipping to change at line 5130 skipping to change at line 4876
<xref target="RFC4566" sectionFormat="of" section="6"/></td> <xref target="RFC4566" sectionFormat="of" section="6"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rtpmap</td> <td align="left">rtpmap</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="6"/></td> <xref target="RFC4566" sectionFormat="of" section="6"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">recvonly</td> <td align="left">recvonly</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="9"/></td> Sections <xref target="RFC4566" section="6" sectionFormat="bare"/>
and <xref target="RFC4566" section="9" sectionFormat="bare"/> of <xref
target="RFC4566"/>
</td>
</tr> </tr>
<tr> <tr>
<td align="left">sendrecv</td> <td align="left">sendrecv</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="9"/></td> Sections <xref target="RFC4566" section="6" sectionFormat="bare"/>
and <xref target="RFC4566" section="9" sectionFormat="bare"/> of <xref
target="RFC4566"/>
</td>
</tr> </tr>
<tr> <tr>
<td align="left">sendonly</td> <td align="left">sendonly</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="9"/></td> Sections <xref target="RFC4566" section="6" sectionFormat="bare"/>
and <xref target="RFC4566" section="9" sectionFormat="bare"/> of <xref
target="RFC4566"/>
</td>
</tr> </tr>
<tr> <tr>
<td align="left">inactive</td> <td align="left">inactive</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="9"/></td> Sections <xref target="RFC4566" section="6" sectionFormat="bare"/>
and <xref target="RFC4566" section="9" sectionFormat="bare"/> of <xref
target="RFC4566"/>
</td>
</tr> </tr>
<tr> <tr>
<td align="left">fmtp</td> <td align="left">fmtp</td>
<td align="left"> <td align="left">
<xref target="RFC4566" sectionFormat="of" section="9"/></td> Sections <xref target="RFC4566" section="6" sectionFormat="bare"/>
and <xref target="RFC4566" section="9" sectionFormat="bare"/> of <xref
target="RFC4566"/>
</td>
</tr> </tr>
<tr> <tr>
<td align="left">rtcp</td> <td align="left">rtcp</td>
<td align="left"> <td align="left">
<xref target="RFC3605" sectionFormat="of" section="2.1"/></td> <xref target="RFC3605" sectionFormat="of" section="2.1"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">setup</td> <td align="left">setup</td>
<td align="left"> <td align="left">
<xref target="RFC4145" section="4" sectionFormat="of"/></td> <xref target="RFC4145" section="4" sectionFormat="of"/></td>
skipping to change at line 5249 skipping to change at line 5010
<td align="left"> <td align="left">
<xref target="RFC8853" sectionFormat="of" section="5.1"/></td> <xref target="RFC8853" sectionFormat="of" section="5.1"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">tls-id</td> <td align="left">tls-id</td>
<td align="left"> <td align="left">
<xref target="RFC8842" sectionFormat="of" section="4"/></td> <xref target="RFC8842" sectionFormat="of" section="4"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec.acknowledgements" numbered="false" toc="default"> <section anchor="sec.acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t><contact fullname="Harald Alvestrand"/>, <contact fullname="Taylor <t><contact fullname="Harald Alvestrand"/>, <contact fullname="Taylor
Brandstetter"/>, <contact fullname="Suhas Nandakumar"/>, and Brandstetter"/>, <contact fullname="Suhas Nandakumar"/>, and
<contact fullname="Peter Thatcher"/> provided significant text for this <contact fullname="Peter Thatcher"/> provided significant text for
document. <contact fullname="Bernard Aboba"/>, <contact fullname="Adam RFC 8829 (and thereby this document). <contact fullname="Bernard Aboba"/>,
<contact fullname="Adam
Bergkvist"/>, <contact fullname="Jan-Ivar Bruaroey"/>, Bergkvist"/>, <contact fullname="Jan-Ivar Bruaroey"/>,
<contact fullname="Dan Burnett"/>, <contact fullname="Ben <contact fullname="Dan Burnett"/>, <contact fullname="Ben
Campbell"/>, <contact fullname="Alissa Cooper"/>, Campbell"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Richard Ejzak"/>, <contact fullname="Stefan <contact fullname="Richard Ejzak"/>, <contact fullname="Stefan
Håkansson"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Christe r Holmberg"/>, Håkansson"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Christe r Holmberg"/>,
<contact fullname="Andrew Hutton"/>, <contact fullname="Randell <contact fullname="Andrew Hutton"/>, <contact fullname="Randell
Jesup"/>, <contact fullname="Matthew Kaufman"/>, <contact fullname="Anant Narayanan"/>, Jesup"/>, <contact fullname="Matthew Kaufman"/>, <contact fullname="Anant Narayanan"/>,
<contact fullname="Adam Roach"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Adam Roach"/>, <contact fullname="Robert Sparks"/>,
<contact fullname="Neil Stratford"/>, <contact fullname="Martin <contact fullname="Neil Stratford"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Sean Thomson"/>, <contact fullname="Sean
Turner"/>, and <contact fullname="Magnus Westerlund"/> all provided valuab le feedback on Turner"/>, and <contact fullname="Magnus Westerlund"/> all provided valuab le feedback on
this document.</t> RFC 8829 (and thereby this document).</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 108 change blocks. 
517 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.48.