draft-ietf-rtcweb-jsep-26.original.v2v3.xml   draft-ietf-rtcweb-jsep-26.form.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
tf-rtcweb-jsep-26" ipr="trust200902" obsoletes="" updates="" submissionType="IET docName="draft-ietf-rtcweb-jsep-26" number="0000" consensus="true"
F" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
tocDepth="4" version="3">
<!-- xml2rfc v2v3 conversion 2.34.0 --> <!-- xml2rfc v2v3 conversion 2.34.0 -->
<front> <front>
<title abbrev="JSEP">JavaScript Session Establishment <title abbrev="JSEP">JavaScript Session Establishment
Protocol</title> Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-jsep-26"/> <seriesInfo name="RFC" value="0000"/>
<author fullname="Justin Uberti" initials="J." surname="Uberti"> <author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>747 6th St S</street> <street>747 6th St S</street>
<city>Kirkland</city> <city>Kirkland</city>
<region>WA</region> <region>WA</region>
<code>98033</code> <code>98033</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<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>
<city>Calgary</city> <city>Calgary</city>
skipping to change at line 43 skipping to change at line 47
</address> </address>
</author> </author>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla" role="ed itor"> <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla" role="ed itor">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<postal> <postal>
<street>331 Evelyn Ave</street> <street>331 Evelyn Ave</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94041</code> <code>94041</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date/> <date month="May" year="2020"/>
<area>RAI</area>
<abstract> <abstract>
<t>This document describes the mechanisms for allowing a <t>This document describes the mechanisms for allowing a
JavaScript application to control the signaling plane of a JavaScript application to control the signaling plane of a
multimedia session via the interface specified in the W3C multimedia session via the interface specified in the W3C
RTCPeerConnection API, and discusses how this relates to existing RTCPeerConnection API, and discusses how this relates to existing
signaling protocols.</t> signaling protocols.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec.introduction" numbered="true" toc="default"> <section anchor="sec.introduction" numbered="true" toc="default">
skipping to change at line 124 skipping to change at line 128
<xref target="RFC8445" format="default"/>, JSEP decouples the ICE state <xref target="RFC8445" format="default"/>, JSEP decouples the ICE state
machine from the overall signaling state machine, as the ICE machine from the overall signaling state machine, as the ICE
state machine must remain in the JSEP implementation, because state machine must remain in the JSEP implementation, because
only the implementation has the necessary knowledge of only the implementation has the necessary knowledge of
candidates and other transport information. Performing this candidates and other transport information. Performing this
separation provides additional flexibility in protocols that separation provides additional flexibility in protocols that
decouple session descriptions from transport. For instance, in decouple session descriptions from transport. For instance, in
traditional SIP, each offer or answer is self-contained, traditional SIP, each offer or answer is self-contained,
including both the session descriptions and the transport including both the session descriptions and the transport
information. However, information. However,
<xref target="I-D.ietf-mmusic-trickle-ice-sip" format="default"/> allows SIP to <xref target="RFCYYY8" format="default"/> allows SIP to
be used with trickle ICE be used with trickle ICE
<xref target="I-D.ietf-ice-trickle" format="default"/>, in which the ses sion <xref target="RFCYYY6" format="default"/>, in which the session
description can be sent immediately and the transport description can be sent immediately and the transport
information can be sent when available. Sending transport information can be sent when available. Sending transport
information separately can allow for faster ICE and DTLS information separately can allow for faster ICE and DTLS
startup, since ICE checks can start as soon as any transport startup, since ICE checks can start as soon as any transport
information is available rather than waiting for all of it. information is available rather than waiting for all of it.
JSEP's decoupling of the ICE and signaling state machines JSEP's decoupling of the ICE and signaling state machines
allows it to accommodate either model.</t> allows it to accommodate either model.</t>
<t>Through its abstraction of signaling, the JSEP approach does <t>Through its abstraction of signaling, the JSEP approach does
require the application to be aware of the signaling process. require the application to be aware of the signaling process.
While the application does not need to understand the contents While the application does not need to understand the contents
skipping to change at line 161 skipping to change at line 165
</section> </section>
<section anchor="sec.other-approaches-consider" numbered="true" toc="defau lt"> <section anchor="sec.other-approaches-consider" numbered="true" toc="defau lt">
<name>Other Approaches Considered</name> <name>Other Approaches Considered</name>
<t>One approach that was considered instead of JSEP was to <t>One approach that was considered instead of JSEP was to
include a lightweight signaling protocol. Instead of providing include a lightweight signaling protocol. Instead of providing
session descriptions to the API, the API would produce and session descriptions to the API, the API would produce and
consume messages from this protocol. While providing a more consume messages from this protocol. While providing a more
high-level API, this put more control of signaling within the high-level API, this put more control of signaling within the
JSEP implementation, forcing it to have to understand and JSEP implementation, forcing it to have to understand and
handle concepts like signaling glare (see handle concepts like signaling glare (see
<xref target="RFC3264" format="default"/>, Section 4).</t> <xref target="RFC3264" sectionFormat="comma" section="4"/>).</t>
<t>A second approach that was considered but not chosen was to <t>A second approach that was considered but not chosen was to
decouple the management of the media control objects from decouple the management of the media control objects from
session descriptions, instead offering APIs that would control session descriptions, instead offering APIs that would control
each component directly. This was rejected based on the each component directly. This was rejected based on the
argument that requiring exposure of this level of complexity to argument that requiring exposure of this level of complexity to
the application programmer would not be beneficial; it would the application programmer would not be beneficial; it would
result in an API where even a simple example would require a result in an API where even a simple example would require a
significant amount of code to orchestrate all the needed significant amount of code to orchestrate all the needed
interactions, as well as creating a large API surface that interactions, as well as creating a large API surface that
needed to be agreed upon and documented. In addition, these API needed to be agreed upon and documented. In addition, these API
skipping to change at line 196 skipping to change at line 200
how to generate the correct answer from an arbitrary offer and how to generate the correct answer from an arbitrary offer and
the supported capabilities. While this could certainly be the supported capabilities. While this could certainly be
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>
<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 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119" format="default"/>.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only 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 222 skipping to change at line 230
apply them to a session. However, the JSEP implementation is apply them to a session. However, the JSEP implementation is
totally decoupled from the actual mechanism by which these totally decoupled from the actual mechanism by which these
offers and answers are communicated to the remote side, offers and answers are communicated to the remote side,
including addressing, retransmission, forking, and glare including addressing, retransmission, forking, and glare
handling. These issues are left entirely up to the application; handling. These issues are left entirely up to the application;
the application has complete control over which offers and the application has complete control over which offers and
answers get handed to the implementation, and when.</t> answers get handed to the implementation, and when.</t>
<figure anchor="fig-sigModel"> <figure anchor="fig-sigModel">
<name>JSEP Signaling Model</name> <name>JSEP Signaling Model</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+ +-----------+
+-----------+ +-----------+ | Web App |<--- App-Specific Signaling -->| Web App |
| Web App |<--- App-Specific Signaling -->| Web App | +-----------+ +-----------+
+-----------+ +-----------+ ^ ^
^ ^ | SDP | SDP
| SDP | SDP V V
V V +-----------+ +-----------+
+-----------+ +-----------+ | JSEP |<----------- Media ------------>| JSEP |
| JSEP |<----------- Media ------------>| JSEP | | Impl. | | Impl. |
| Impl. | | Impl. | +-----------+ +-----------+ ]]></artwork>
+-----------+ +-----------+
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sec.session-descriptions-and-state-machine" numbered="tru e" toc="default"> <section anchor="sec.session-descriptions-and-state-machine" numbered="tru e" toc="default">
<name>Session Descriptions and State Machine</name> <name>Session Descriptions and State Machine</name>
<t>In order to establish the media plane, the JSEP <t>In order to establish the media plane, the JSEP
implementation needs specific parameters to indicate what to implementation needs specific parameters to indicate what to
transmit to the remote side, as well as how to handle the media transmit to the remote side, as well as how to handle the media
that is received. These parameters are determined by the that is received. These parameters are determined by the
exchange of session descriptions in offers and answers, and exchange of session descriptions in offers and answers, and
there are certain details to this process that must be handled there are certain details to this process that must be handled
in the JSEP APIs.</t> in the JSEP APIs.</t>
<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 <bcp14>MUST</bcp14> either accept them or reject the m
altogether. An example of such a parameter is the DTLS altogether. An example of such a parameter is the DTLS
fingerprints fingerprints
<xref target="RFC8122" format="default"/>, which are calculated based on <xref target="RFC8122" format="default"/>, which 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.</t> negotiation.</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" format="default"/>, Section 5.14), but an answer 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>
<t>Lastly, while the exact media parameters are only known only <t>Lastly, while the exact media parameters are only known only
after an offer and an answer have been exchanged, the offerer after an offer and an answer have been exchanged, the offerer
may receive ICE checks, and possibly media (e.g., in the case may receive ICE checks, and possibly media (e.g., in the case
of a re-offer after a connection has been established) before of a re-offer after a connection has been established) before
it receives an answer. To properly process incoming media in it receives an answer. To properly process incoming media in
this case, the offerer's media handler must be aware of the this case, the offerer's media handler must be aware of the
details of the offer before the answer arrives.</t> details of the offer before the answer arrives.</t>
<t>Therefore, in order to handle session descriptions properly, <t>Therefore, in order to handle session descriptions properly,
the JSEP implementation needs: the JSEP implementation needs:
skipping to change at line 298 skipping to change at line 303
setLocalDescription(sdp [offer]) and then later setLocalDescription(sdp [offer]) and then later
setRemoteDescription(sdp [answer]), as well as for the setRemoteDescription(sdp [answer]), as well as for the
answerer, who first calls setRemoteDescription(sdp [offer]) and answerer, who first calls setRemoteDescription(sdp [offer]) and
then later setLocalDescription(sdp [answer]).</t> then later setLocalDescription(sdp [answer]).</t>
<t>During the offer/answer exchange, the outstanding offer is <t>During the offer/answer exchange, the outstanding offer is
considered to be "pending" at the offerer and the answerer, as considered to be "pending" at the offerer and the answerer, as
it may either be accepted or rejected. If this is a re-offer, it may either be accepted or rejected. If this is a re-offer,
each side will also have "current" local and remote each side will also have "current" local and remote
descriptions, which reflect the result of the last offer/answer descriptions, which reflect the result of the last offer/answer
exchange. Sections exchange. Sections
<xref target="sec.pendinglocaldescription" format="default"/>, <xref target="sec.pendinglocaldescription" format="counter"/>,
<xref target="sec.pendingremotedescription" format="default"/>, <xref target="sec.pendingremotedescription" format="counter"/>,
<xref target="sec.currentlocaldescription" format="default"/>, and <xref target="sec.currentlocaldescription" format="counter"/>, and
<xref target="sec.currentremotedescription" format="default"/>, provide <xref target="sec.currentremotedescription" format="counter"/>, provide
more more
detail on pending and current descriptions.</t> detail on pending and current descriptions.</t>
<t>JSEP also allows for an answer to be treated as provisional <t>JSEP also allows for an answer to be treated as provisional
by the application. Provisional answers provide a way for an by the application. Provisional answers provide a way for an
answerer to communicate initial session parameters back to the answerer to communicate initial session parameters back to the
offerer, in order to allow the session to begin, while allowing offerer, in order to allow the session to begin, while allowing
a final answer to be specified later. This concept of a final a final answer to be specified later. This concept of a final
answer is important to the offer/answer model; when such an answer is important to the offer/answer model; when such an
answer is received, any extra resources allocated by the caller answer is received, any extra resources allocated by the caller
can be released, now that the exact session configuration is can be released, now that the exact session configuration is
known. These "resources" can include things like extra ICE known. These "resources" can include things like extra ICE
skipping to change at line 371 skipping to change at line 375
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| have- | setRemote(PRANSWER) |have- | | have- | setRemote(PRANSWER) |have- |
| local-offer |------------------- >|remote-pranswer| | local-offer |------------------- >|remote-pranswer|
| | | | | | | |
| |----\ | |----\ | |----\ | |----\
+---------------+ | +---------------+ | +---------------+ | +---------------+ |
^ | ^ | ^ | ^ |
| | | | | | | |
\-----/ \-----/ \-----/ \-----/
setLocal(OFFER) setRemote(PRANSWER) setLocal(OFFER) setRemote(PRANSWER) ]]></artwo
rk>
]]></artwork>
</figure> </figure>
<t>Aside from these state transitions there is no other <t>Aside from these state transitions there is no other
difference between the handling of provisional ("pranswer") and difference between the handling of provisional ("pranswer") and
final ("answer") answers.</t> final ("answer") answers.</t>
</section> </section>
<section anchor="sec.session-description-forma" numbered="true" toc="defau lt"> <section anchor="sec.session-description-forma" numbered="true" toc="defau lt">
<name>Session Description Format</name> <name>Session Description Format</name>
<t>JSEP's session descriptions use SDP syntax for their <t>JSEP's session descriptions use SDP syntax for their
internal representation. While this format is not optimal for internal representation. While this format is not optimal for
manipulation from JavaScript, it is widely accepted, and manipulation from JavaScript, it is widely accepted, and
skipping to change at line 495 skipping to change at line 497
description. Finally, when all candidates have been gathered, description. Finally, when all candidates have been gathered,
an event will be dispatched to signal that the gathering an event will be dispatched to signal that the gathering
process is complete.</t> process is complete.</t>
<t>Note that gathering phases only gather the candidates <t>Note that gathering phases only gather the candidates
needed by new/recycled/restarting m= sections; other m= needed by new/recycled/restarting m= sections; other m=
sections continue to use their existing candidates. Also, if sections continue to use their existing candidates. Also, if
an m= section is bundled (either by a successful bundle an m= section is bundled (either by a successful bundle
negotiation or by being marked as bundle-only), then negotiation or by being marked as bundle-only), then
candidates will be gathered and exchanged for that m= section candidates will be gathered and exchanged for that m= section
if and only if its MID is a BUNDLE-tag, as described in if and only if its MID is a BUNDLE-tag, as described in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default" />.</t> <xref target="RFCYYYB" format="default"/>.</t>
</section> </section>
<section anchor="sec.ice-candidate-trickling" numbered="true" toc="defau lt"> <section anchor="sec.ice-candidate-trickling" numbered="true" toc="defau lt">
<name>ICE Candidate Trickling</name> <name>ICE Candidate Trickling</name>
<t>Candidate trickling is a technique through which a caller <t>Candidate trickling is a technique through which a caller
may incrementally provide candidates to the callee after the may incrementally provide candidates to the callee after the
initial offer has been dispatched; the semantics of "Trickle initial offer has been dispatched; the semantics of "Trickle
ICE" are defined in ICE" are defined in
<xref target="I-D.ietf-ice-trickle" format="default"/>. This process <xref target="RFCYYY6" format="default"/>. This process
allows the callee to begin acting upon the call and setting allows the callee to begin acting upon the call and setting
up the ICE (and perhaps DTLS) connections immediately, up the ICE (and perhaps DTLS) connections immediately,
without having to wait for the caller to gather all possible without having to wait for the caller to gather all possible
candidates. This results in faster media setup in cases where candidates. This results in faster media setup in cases where
gathering is not performed prior to initiating the call.</t> gathering is not performed prior to initiating the call.</t>
<t>JSEP supports optional candidate trickling by providing <t>JSEP supports optional candidate trickling by providing
APIs, as described above, that provide control and feedback APIs, as described above, that provide control and feedback
on the ICE candidate gathering process. Applications that on the ICE candidate gathering process. Applications that
support candidate trickling can send the initial offer support candidate trickling can send the initial offer
immediately and send individual candidates when they get the immediately and send individual candidates when they get the
skipping to change at line 530 skipping to change at line 532
the ICE agent to start using the new remote candidates for the ICE agent to start using the new remote candidates for
connectivity checks.</t> connectivity checks.</t>
<section anchor="sec.ice-candidate-format" numbered="true" toc="defaul t"> <section anchor="sec.ice-candidate-format" numbered="true" toc="defaul t">
<name>ICE Candidate Format</name> <name>ICE Candidate Format</name>
<t>In JSEP, ICE candidates are abstracted by an <t>In JSEP, ICE candidates are abstracted by an
IceCandidate object, and as with session descriptions, SDP IceCandidate object, and as with session descriptions, SDP
syntax is used for the internal representation.</t> syntax is used for the internal representation.</t>
<t>The candidate details are specified in an IceCandidate <t>The candidate details are specified in an IceCandidate
field, using the same SDP syntax as the field, using the same SDP syntax as the
"candidate-attribute" field defined in "candidate-attribute" field defined in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.1"/>. Note t
Section 4.1. Note that this hat this
field does not contain an "a=" prefix, as indicated in the field does not contain an "a=" prefix, as indicated in the
following example:</t> following example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <!-- Reviewer: Labeled as "sdp" but not sure this one's correct.
Note: After this point, if the authors used a name in
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host the "<artwork alt=" field, I moved it to the "name" field
(i.e., starting with "offer-A1" around line 3700 or so). -->
]]></artwork> <sourcecode name="" type="sdp"><![CDATA[
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode>
<t>The IceCandidate object contains a field to indicate <t>The IceCandidate object contains a field to indicate
which ICE ufrag it is associated with, as defined in which ICE ufrag it is associated with, as defined in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>. This v
Section 4.4. This value is used alue is used
to determine which session description (and thereby which to determine which session description (and thereby which
gathering phase) this IceCandidate belongs to, which helps gathering phase) this IceCandidate belongs to, which helps
resolve ambiguities during ICE restarts. If this field is resolve ambiguities during ICE restarts. If this field is
absent in a received IceCandidate (perhaps when absent in a received IceCandidate (perhaps when
communicating with a non-JSEP endpoint), the most recently communicating with a non-JSEP endpoint), the most recently
received session description is assumed.</t> received session description is assumed.</t>
<t>The IceCandidate object also contains fields to indicate <t>The IceCandidate object also contains fields to indicate
which m= section it is associated with, which can be which m= section it is associated with, which can be
identified in one of two ways, either by a m= section identified in one of two ways, either by a m= section
index, or a MID. The m= section index is a zero-based index, or a MID. The m= section index is a zero-based
index, with index N referring to the N+1th m= section in index, with index N referring to the N+1th m= section in
the session description referenced by this IceCandidate. the session description referenced by this IceCandidate.
The MID is a "media stream identification" value, as The MID is a "media stream identification" value, as
defined in defined in
<xref target="RFC5888" format="default"/>, Section 4, which provides a <xref target="RFC5888" sectionFormat="comma" section="4"/>, which pr ovides a
more robust way to identify the m= section in the session more robust way to identify the m= section in the session
description, using the MID of the associated RtpTransceiver description, using the MID of the associated RtpTransceiver
object (which may have been locally generated by the object (which may have been locally generated by the
answerer when interacting with a non-JSEP endpoint that answerer when interacting with a non-JSEP endpoint that
does not support the MID attribute, as discussed in does not support the MID attribute, as discussed in
<xref target="sec.applying-a-remote-desc" format="default"/> below). If the <xref target="sec.applying-a-remote-desc" format="default"/> below). If the
MID field is present in a received IceCandidate, it MUST be MID field is present in a received IceCandidate, it <bcp14>MUST</bcp 14> be
used for identification; otherwise, the m= section index is used for identification; otherwise, the m= section index is
used instead.</t> used instead.</t>
<t>When creating an IceCandidate object, JSEP <t>When creating an IceCandidate object, JSEP
implementations MUST populate each of the candidate, ufrag, implementations <bcp14>MUST</bcp14> populate each of the candidate,
m= section index, and MID fields. Implementations MUST also ufrag,
m= section index, and MID fields. Implementations <bcp14>MUST</bcp14
> also
be prepared to receive objects with some fields missing, as be prepared to receive objects with some fields missing, as
mentioned above.</t> mentioned above.</t>
</section> </section>
</section> </section>
<section anchor="sec.ice-candidate-policy" numbered="true" toc="default" > <section anchor="sec.ice-candidate-policy" numbered="true" toc="default" >
<name>ICE Candidate Policy</name> <name>ICE Candidate Policy</name>
<t>Typically, when gathering ICE candidates, the JSEP <t>Typically, when gathering ICE candidates, the JSEP
implementation will gather all possible forms of initial implementation will gather all possible forms of initial
candidates - host, server reflexive, and relay. However, in candidates - host, server reflexive, and relay. However, in
certain cases, applications may want to have more specific certain cases, applications may want to have more specific
control over the gathering process, due to privacy or related control over the gathering process, due to privacy or related
concerns. For example, one may want to only use relay concerns. For example, one may want to only use relay
candidates, to leak as little location information as candidates, to leak as little location information as
possible (keeping in mind that this choice comes with possible (keeping in mind that this choice comes with
corresponding operational costs). To accomplish this, JSEP corresponding operational costs). To accomplish this, JSEP
allows the application to restrict which ICE candidates are allows the application to restrict which ICE candidates are
used in a session. Note that this filtering is applied on top used in a session. Note that this filtering is applied on top
of any restrictions the implementation chooses to enforce of any restrictions the implementation chooses to enforce
regarding which IP addresses are permitted for the regarding which IP addresses are permitted for the
application, as discussed in application, as discussed in
<xref target="I-D.ietf-rtcweb-ip-handling" format="default"/>.</t> <xref target="RFCYYY3" format="default"/>.</t>
<t>There may also be cases where the application wants to <t>There may also be cases where the application wants to
change which types of candidates are used while the session change which types of candidates are used while the session
is active. A prime example is where a callee may initially is active. A prime example is where a callee may initially
want to use only relay candidates, to avoid leaking location want to use only relay candidates, to avoid leaking location
information to an arbitrary caller, but then change to use information to an arbitrary caller, but then change to use
all candidates (for lower operational cost) once the user has all candidates (for lower operational cost) once the user has
indicated they want to take the call. For this scenario, the indicated they want to take the call. For this scenario, the
JSEP implementation MUST allow the candidate policy to be JSEP implementation <bcp14>MUST</bcp14> allow the candidate policy to be
changed in mid-session, subject to the aforementioned changed in mid-session, subject to the aforementioned
interactions with local policy.</t> interactions with local policy.</t>
<t>To administer the ICE candidate policy, the JSEP <t>To administer the ICE candidate policy, the JSEP
implementation will determine the current setting at the implementation will determine the current setting at the
start of each gathering phase. Then, during the gathering start of each gathering phase. Then, during the gathering
phase, the implementation MUST NOT expose candidates phase, the implementation <bcp14>MUST NOT</bcp14> expose candidates
disallowed by the current policy to the application, use them disallowed by the current policy to the application, use them
as the source of connectivity checks, or indirectly expose as the source of connectivity checks, or indirectly expose
them via other fields, such as the raddr/rport attributes for them via other fields, such as the raddr/rport attributes for
other ICE candidates. Later, if a different policy is other ICE candidates. Later, if a different policy is
specified by the application, the application can apply it by specified by the application, the application can apply it by
kicking off a new gathering phase via an ICE restart.</t> kicking off a new gathering phase via an ICE restart.</t>
</section> </section>
<section anchor="sec.ice-candidate-pool" numbered="true" toc="default"> <section anchor="sec.ice-candidate-pool" numbered="true" toc="default">
<name>ICE Candidate Pool</name> <name>ICE Candidate Pool</name>
<t>JSEP applications typically inform the JSEP implementation <t>JSEP applications typically inform the JSEP implementation
to begin ICE gathering via the information supplied to to begin ICE gathering via the information supplied to
setLocalDescription, as the local description indicates the setLocalDescription, as the local description indicates the
number of ICE components which will be needed and for which number of ICE components which will be needed and for which
candidates must be gathered. However, to accelerate cases candidates must be gathered. However, to accelerate cases
where the application knows the number of ICE components to where the application knows the number of ICE components to
use ahead of time, it may ask the implementation to gather a use ahead of time, it may ask the implementation to gather a
pool of potential ICE candidates to help ensure rapid media pool of potential ICE candidates to help ensure rapid media
setup.</t> setup.</t>
<t>When setLocalDescription is eventually called, and the <t>When setLocalDescription is eventually called, and the
JSEP implementation goes to gather the needed ICE candidates, JSEP implementation goes to gather the needed ICE candidates,
it SHOULD start by checking if any candidates are available it <bcp14>SHOULD</bcp14> start by checking if any candidates are avail
in the pool. If there are candidates in the pool, they SHOULD able
in the pool. If there are candidates in the pool, they <bcp14>SHOULD</
bcp14>
be handed to the application immediately via the ICE be handed to the application immediately via the ICE
candidate event. If the pool becomes depleted, either because candidate event. If the pool becomes depleted, either because
a larger-than-expected number of ICE components is used, or a larger-than-expected number of ICE components is used, or
because the pool has not had enough time to gather because the pool has not had enough time to gather
candidates, the remaining candidates are gathered as usual. candidates, the remaining candidates are gathered as usual.
This only occurs for the first offer/answer exchange, after This only occurs for the first offer/answer exchange, after
which the candidate pool is emptied and no longer used.</t> which the candidate pool is emptied and no longer used.</t>
<t>One example of where this concept is useful is an <t>One example of where this concept is useful is an
application that expects an incoming call at some point in application that expects an incoming call at some point in
the future, and wants to minimize the time it takes to the future, and wants to minimize the time it takes to
skipping to change at line 654 skipping to change at line 655
using.</t> using.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>ICE Versions</name> <name>ICE Versions</name>
<t>While this specification formally relies on <xref target="RFC8445" format="default"/>, at the time of its publication, the <t>While this specification formally relies on <xref target="RFC8445" format="default"/>, at the time of its publication, the
majority of WebRTC implementations support the version majority of WebRTC implementations support the version
of ICE described in <xref target="RFC5245" format="default"/>. The use of of ICE described in <xref target="RFC5245" format="default"/>. The use of
the "ice2" attribute defined in <xref target="RFC8445" format="default "/> the "ice2" attribute defined in <xref target="RFC8445" format="default "/>
can be used to detect the version in use by a remote endpoint can be used to detect the version in use by a remote endpoint
and to provide a smooth transition from the older specification and to provide a smooth transition from the older specification
to the newer one. Implementations MUST be able to accept remote to the newer one. Implementations <bcp14>MUST</bcp14> be able to acce pt remote
descriptions that do not have the "ice2" attribute.</t> descriptions that do not have the "ice2" attribute.</t>
</section> </section>
</section> </section>
<section anchor="sec.imageattr" numbered="true" toc="default"> <section anchor="sec.imageattr" numbered="true" toc="default">
<name>Video Size Negotiation</name> <name>Video Size Negotiation</name>
<t>Video size negotiation is the process through which a <t>Video size negotiation is the process through which a
receiver can use the "a=imageattr" SDP attribute receiver can use the "a=imageattr" SDP attribute
<xref target="RFC6236" format="default"/> to indicate what video frame s izes it <xref target="RFC6236" format="default"/> to indicate what video frame s izes it
is capable of receiving. A receiver may have hard limits on is capable of receiving. A receiver may have hard limits on
what its video decoder can process, or it may have some maximum what its video decoder can process, or it may have some maximum
set by policy. By specifying these limits in an "a=imageattr" set by policy. By specifying these limits in an "a=imageattr"
attribute, JSEP endpoints can attempt to ensure that the remote attribute, JSEP endpoints can attempt to ensure that the remote
sender transmits video at an acceptable resolution. However, sender transmits video at an acceptable resolution. However,
when communicating with a non-JSEP endpoint that does not when communicating with a non-JSEP endpoint that does not
understand this attribute, any signaled limits may be exceeded, understand this attribute, any signaled limits may be exceeded,
and the JSEP implementation MUST handle this gracefully, e.g., and the JSEP implementation <bcp14>MUST</bcp14> handle this gracefully, e.g.,
by discarding the video.</t> by discarding the video.</t>
<t>Note that certain codecs support transmission of samples <t>Note that certain codecs support transmission of samples
with aspect ratios other than 1.0 (i.e., non-square pixels). with aspect ratios other than 1.0 (i.e., non-square pixels).
JSEP implementations will not transmit non-square pixels, but JSEP implementations will not transmit non-square pixels, but
SHOULD receive and render such video with the correct aspect <bcp14>SHOULD</bcp14> receive and render such video with the correct asp ect
ratio. However, sample aspect ratio has no impact on the size ratio. However, sample aspect ratio has no impact on the size
negotiation described below; all dimensions are measured in negotiation described below; all dimensions are measured in
pixels, whether square or not.</t> pixels, whether square or not.</t>
<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 intersect any known local limits <t>The receiver will first intersect any known local limits
(e.g., hardware decoder capababilities, local policy) to (e.g., hardware decoder capababilities, 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 SHOULD be omitted. If these local "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
MUST be omitted, and the m= section MUST be marked as <bcp14>MUST</bcp14> be omitted, and the m= section <bcp14>MUST</bcp14> be marked as
sendonly/inactive, as appropriate.</t> sendonly/inactive, as appropriate.</t>
<t>Otherwise, an "a=imageattr" attribute is created with <t>Otherwise, an "a=imageattr" attribute is created with
"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
SHOULD 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
RECOMMENDED. However, when the supported video codecs have <bcp14>RECOMMENDED</bcp14>. However, when the supported video codecs h
different limitations, specific "a=imageattr" attributes MUST ave
different limitations, specific "a=imageattr" attributes <bcp14>MUST</
bcp14>
be inserted for each payload type.</t> be inserted for each payload type.</t>
<t>As an example, consider a system with a multiformat video <t>As an example, consider a system with a multiformat video
decoder, which is capable of decoding any resolution from decoder, which is capable of decoding any resolution from
48x48 to 720p, In this case, the implementation would 48x48 to 720p, In this case, the implementation would
generate this attribute:</t> generate this attribute:</t>
<t>a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]</t> <t>a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]</t>
<t>This declaration indicates that the receiver is capable of <t>This declaration indicates that the receiver is capable of
decoding any image resolution from 48x48 up to 1280x720 decoding any image resolution from 48x48 up to 1280x720
pixels.</t> pixels.</t>
</section> </section>
skipping to change at line 725 skipping to change at line 726
<xref target="RFC6236" format="default"/> defines "a=imageattr" to be an <xref target="RFC6236" format="default"/> defines "a=imageattr" to be an
advisory field. This means that it does not absolutely advisory field. This means that it does not absolutely
constrain the video formats that the sender can use, but constrain the video formats that the sender can use, but
gives an indication of the preferred values.</t> gives an indication of the preferred values.</t>
<t>This specification prescribes more specific behavior. When <t>This specification prescribes more specific behavior. When
a MediaStreamTrack, which is producing video of a certain a MediaStreamTrack, which is producing video of a certain
resolution (the "track resolution"), is attached to a resolution (the "track resolution"), is attached to a
RtpSender, which is encoding the track video at the same or RtpSender, which is encoding the track video at the same or
lower resolution(s) (the "encoder resolutions"), and a remote lower resolution(s) (the "encoder resolutions"), and a remote
description is applied that references the sender and description is applied that references the sender and
contains valid "a=imageattr recv" attributes, it MUST follow contains valid "a=imageattr recv" attributes, it <bcp14>MUST</bcp14> f ollow
the rules below to ensure the sender does not transmit a the rules below to ensure the sender does not transmit a
resolution that would exceed the size criteria specified in resolution that would exceed the size criteria specified in
the attributes. These rules MUST be followed as long as the the attributes. These rules <bcp14>MUST</bcp14> be followed as long as the
attributes remain present in the remote description, attributes remain present in the remote description,
including cases in which the track changes its resolution, or including cases in which the track changes its resolution, or
is replaced with a different track.</t> is replaced with a different track.</t>
<t>Depending on how the RtpSender is configured, it may be <t>Depending on how the RtpSender is configured, it may be
producing a single encoding at a certain resolution, or, if producing a single encoding at a certain resolution, or, if
simulcast simulcast
<xref target="sec.simulcast" format="default"/> has been negotiated, m ultiple <xref target="sec.simulcast" format="default"/> has been negotiated, m ultiple
encodings, each at their own specific resolution. In encodings, each at their own specific resolution. In
addition, depending on the configuration, each encoding may addition, depending on the configuration, each encoding may
have the flexibility to reduce resolution when needed, or may have the flexibility to reduce resolution when needed, or may
skipping to change at line 759 skipping to change at line 760
that while JSEP endpoints will include at most one that while JSEP endpoints will include at most one
"a=imageattr recv" attribute per media format, JSEP endpoints "a=imageattr recv" attribute per media format, JSEP endpoints
may receive session descriptions from non-JSEP endpoints with may receive session descriptions from non-JSEP endpoints with
m= sections that contain multiple such attributes.</t> m= sections that contain multiple such attributes.</t>
<t>For each "a=imageattr recv" attribute, the following rules <t>For each "a=imageattr recv" attribute, the following rules
are applied. If this processing is successful, the encoding are applied. If this processing is successful, the encoding
is transmitted accordingly, and no further attributes are is transmitted accordingly, and no further attributes are
considered for that encoding. Otherwise, the next attribute considered for that encoding. Otherwise, the next attribute
is evaluated, in the aforementioned order. If none of the is evaluated, in the aforementioned order. If none of the
supplied attributes can be processed successfully, the supplied attributes can be processed successfully, the
encoding MUST NOT be transmitted, and an error SHOULD be encoding <bcp14>MUST NOT</bcp14> be transmitted, and an error <bcp14>S HOULD</bcp14> be
raised to the application. raised to the application.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The limits from the attribute are compared to the <li>The limits from the attribute are compared to the
encoder resolution. Only the specific limits mentioned encoder resolution. Only the specific limits mentioned
below are considered; any other values, such as picture below are considered; any other values, such as picture
aspect ratio, MUST be ignored. When considering a aspect ratio, <bcp14>MUST</bcp14> be ignored. When considering a
MediaStreamTrack that is producing rotated video, the MediaStreamTrack that is producing rotated video, the
unrotated resolution MUST be used for the checks. This is unrotated resolution <bcp14>MUST</bcp14> be used for the checks. Thi s is
required regardless of whether the receiver supports required regardless of whether the receiver supports
performing receive-side rotation (e.g., through CVO performing receive-side rotation (e.g., through CVO
<xref target="TS26.114" format="default"/>), as it significantly sim plifies <xref target="TS26.114" format="default"/>), as it significantly sim plifies
the matching logic.</li> the matching logic.</li>
<li>If the attribute includes a "sar=" (sample aspect ratio) <li>If the attribute includes a "sar=" (sample aspect ratio)
value set to something other than "1.0", indicating the value set to something other than "1.0", indicating the
receiver wants to receive non-square pixels, this cannot be receiver wants to receive non-square pixels, this cannot be
satisfied and the attribute MUST NOT be used.</li> satisfied and the attribute <bcp14>MUST NOT</bcp14> be used.</li>
<li>If the encoder resolution exceeds the maximum size <li>If the encoder resolution exceeds the maximum size
permitted by the attribute, and the encoder is allowed to permitted by the attribute, and the encoder is allowed to
adjust its resolution, the encoder SHOULD apply downscaling adjust its resolution, the encoder <bcp14>SHOULD</bcp14> apply downs
in order to satisfy the limits. Downscaling MUST NOT change caling
in order to satisfy the limits. Downscaling <bcp14>MUST NOT</bcp14>
change
the picture aspect ratio of the encoding, ignoring any the picture aspect ratio of the encoding, ignoring any
trivial differences due to rounding. For example, if the trivial differences due to rounding. For example, if the
encoder resolution is 1280x720, and the attribute specified encoder resolution is 1280x720, and the attribute specified
a maximum of 640x480, the expected output resolution would a maximum of 640x480, the expected output resolution would
be 640x360. If downscaling cannot be applied, the attribute be 640x360. If downscaling cannot be applied, the attribute
MUST NOT be used.</li> <bcp14>MUST NOT</bcp14> be used.</li>
<li>If the encoder resolution is less than the minimum size <li>If the encoder resolution is less than the minimum size
permitted by the attribute, the attribute MUST NOT be used; permitted by the attribute, the attribute <bcp14>MUST NOT</bcp14> be
the encoder MUST NOT apply upscaling. JSEP implementations used;
SHOULD avoid this situation by allowing receipt of the encoder <bcp14>MUST NOT</bcp14> apply upscaling. JSEP implementa
tions
<bcp14>SHOULD</bcp14> avoid this situation by allowing receipt of
arbitrarily small resolutions, perhaps via fallback to a arbitrarily small resolutions, perhaps via fallback to a
software decoder.</li> software decoder.</li>
<li>If the encoder resolution is within the maximum and <li>If the encoder resolution is within the maximum and
minimum sizes, no action is needed.</li> minimum sizes, no action is needed.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="sec.simulcast" numbered="true" toc="default"> <section anchor="sec.simulcast" numbered="true" toc="default">
<name>Simulcast</name> <name>Simulcast</name>
<t>JSEP supports simulcast transmission of a MediaStreamTrack, <t>JSEP supports simulcast transmission of a MediaStreamTrack,
skipping to change at line 842 skipping to change at line 843
This means that setting up simulcast in the case where the JSEP This means that setting up simulcast in the case where the JSEP
endpoint receives the initial offer requires out-of-band endpoint receives the initial offer requires out-of-band
signaling or SDP inspection. However, in the case where the signaling or SDP inspection. However, in the case where the
JSEP endpoint sets up simulcast in its in initial offer, any JSEP endpoint sets up simulcast in its in initial offer, any
established simulcast streams will continue to work upon established simulcast streams will continue to work upon
receipt of an incoming re-offer. Future versions of this receipt of an incoming re-offer. Future versions of this
specification may add additional APIs to handle the incoming specification may add additional APIs to handle the incoming
initial offer scenario.</t> initial offer scenario.</t>
<t>When using JSEP to transmit multiple encodings from a <t>When using JSEP to transmit multiple encodings from a
RtpSender, the techniques from RtpSender, the techniques from
<xref target="I-D.ietf-mmusic-sdp-simulcast" format="default"/> and <xref target="RFCYYYE" format="default"/> and
<xref target="I-D.ietf-mmusic-rid" format="default"/> are used. Specific <xref target="RFCYYYC" format="default"/> are used. Specifically,
ally,
when multiple encodings have been configured for a RtpSender, when multiple encodings have been configured for a RtpSender,
the m= section for the RtpSender will include an "a=simulcast" the m= section for the RtpSender will include an "a=simulcast"
attribute, as defined in attribute, as defined in
<xref target="I-D.ietf-mmusic-sdp-simulcast" format="default"/>, Section 6.2, <xref target="RFCYYYE" sectionFormat="comma" section="6.2"/>,
with a "send" simulcast stream description that lists each with a "send" simulcast stream description that lists each
desired encoding, and no "recv" simulcast stream description. desired encoding, and no "recv" simulcast stream description.
The m= section will also include an "a=rid" attribute for each The m= section will also include an "a=rid" attribute for each
encoding, as specified in encoding, as specified in
<xref target="I-D.ietf-mmusic-rid" format="default"/>, Section 4; the us e of <xref target="RFCYYYC" sectionFormat="comma" section="4"/>; the use of
RID identifiers allows the individual encodings to be RID identifiers 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"
skipping to change at line 913 skipping to change at line 914
final answer.</t> final answer.</t>
</section> </section>
<section anchor="sec.parallel-forking" numbered="true" toc="default"> <section anchor="sec.parallel-forking" numbered="true" toc="default">
<name>Parallel Forking</name> <name>Parallel Forking</name>
<t>Parallel forking involves a call being dispatched to <t>Parallel forking involves a call being dispatched to
multiple remote callees, where each callee can accept the multiple remote callees, where each callee can accept the
call, and multiple simultaneous active signaling sessions can call, and multiple simultaneous active signaling sessions can
be established as a result. If multiple callees send media at be established as a result. If multiple callees send media at
the same time, the possibilities for handling this are the same time, the possibilities for handling this are
described in described in
<xref target="RFC3960" format="default"/>, Section 3.1. Most SIP devic es <xref target="RFC3960" sectionFormat="comma" section="3.1"/>. Most SIP devices
today only support exchanging media with a single device at a today only support exchanging media with a single device at a
time, and do not try to mix multiple early media audio time, and do not try to mix multiple early media audio
sources, as that could result in a confusing situation. For sources, as that could result in a confusing situation. For
example, consider having a European ringback tone mixed example, consider having a European ringback tone mixed
together with the North American ringback tone - the together with the North American ringback tone - the
resulting sound would not be like either tone, and would resulting sound would not be like either tone, and would
confuse the user. If the signaling application wishes to only confuse the user. If the signaling application wishes to only
exchange media with one of the remote endpoints at a time, exchange media with one of the remote endpoints at a time,
then from a media engine point of view, this is exactly like then from a media engine point of view, this is exactly like
the sequential forking case.</t> the sequential forking case.</t>
skipping to change at line 979 skipping to change at line 980
<xref target="sec.ice-candidate-policy" format="default"/>, causing th e JSEP <xref target="sec.ice-candidate-policy" format="default"/>, causing th e JSEP
implementation to only surface the permitted candidates implementation to only surface the permitted candidates
(including any implementation-internal filtering) to the (including any implementation-internal filtering) to the
application, and only use those candidates for connectivity application, and only use those candidates for connectivity
checks. The set of available policies is as follows: checks. The set of available policies is as follows:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>all:</dt> <dt>all:</dt>
<dd>All candidates permitted by <dd>All candidates permitted by
implementation policy will be gathered and used.</dd> implementation policy will be gathered and used.</dd>
<dt/>
<dd/>
<dt>relay:</dt> <dt>relay:</dt>
<dd>All candidates except relay candidates <dd>All candidates except relay candidates
will be filtered out. This obfuscates the location will be filtered out. This obfuscates the location
information that might be ascertained by the remote peer information that might be ascertained by the remote peer
from the received candidates. Depending on how the from the received candidates. Depending on how the
application deploys and chooses relay servers, this could application deploys and chooses relay servers, this could
obfuscate location to a metro or possibly even global obfuscate location to a metro or possibly even global
level.</dd> level.</dd>
</dl> </dl>
<t>The default ICE candidate policy MUST be set to "all" as <t>The default ICE candidate policy <bcp14>MUST</bcp14> be set to "all " as
this is generally the desired policy, and also typically this is generally the desired policy, and also typically
reduces use of application TURN server resources reduces use of application TURN server resources
significantly.</t> significantly.</t>
<t>If a size is specified for the ICE candidate pool, this <t>If a size is specified for the ICE candidate pool, this
indicates the number of ICE components to pre-gather indicates the number of ICE components to pre-gather
candidates for. Because pre-gathering results in utilizing candidates for. Because pre-gathering results in utilizing
STUN/TURN server resources for potentially long periods of STUN/TURN server resources for potentially long periods of
time, this must only occur upon application request, and time, this must only occur upon application request, and
therefore the default candidate pool size MUST be zero.</t> therefore the default candidate pool size <bcp14>MUST</bcp14> be zero. </t>
<t>The application can specify its preferred policy regarding <t>The application can specify its preferred policy regarding
use of bundle, the multiplexing mechanism defined in use of bundle, the multiplexing mechanism defined in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default" > <xref target="RFCYYYB" format="default">
</xref>. Regardless of policy, the application will always </xref>. Regardless of policy, the application will always
try to negotiate bundle onto a single transport, and will try to negotiate bundle onto a single transport, and will
offer a single bundle group across all m= sections; use of offer a single bundle group across all m= sections; use of
this single transport is contingent upon the answerer this single transport is contingent upon the answerer
accepting bundle. However, by specifying a policy from the accepting bundle. However, by specifying a policy from the
list below, the application can control exactly how list below, the application can control exactly how
aggressively it will try to bundle media streams together, aggressively it will try to bundle media streams together,
which affects how it will interoperate with a which affects how it will interoperate with a
non-bundle-aware endpoint. When negotiating with a non-bundle-aware endpoint. When negotiating with a
non-bundle-aware endpoint, only the streams not marked as non-bundle-aware endpoint, only the streams not marked as
skipping to change at line 1030 skipping to change at line 1029
parameters, which will allow an answerer to unbundle that parameters, which will allow an answerer to unbundle that
section. The second and any subsequent m= section of each section. The second and any subsequent m= section of each
type will be marked bundle-only. The result is that if type will be marked bundle-only. The result is that if
there are N distinct media types, then candidates will be there are N distinct media types, then candidates will be
gathered for for N media streams. This policy balances gathered for for N media streams. This policy balances
desire to multiplex with the need to ensure basic audio and desire to multiplex with the need to ensure basic audio and
video can still be negotiated in legacy cases. When acting video can still be negotiated in legacy cases. When acting
as answerer, if there is no bundle group in the offer, the as answerer, if there is no bundle group in the offer, the
implementation will reject all but the first m= section of implementation will reject all but the first m= section of
each type.</dd> each type.</dd>
<dt/>
<dd/>
<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 will allow all streams to be received by This policy will allow all streams to be received by
non-bundle-aware endpoints, but require separate candidates non-bundle-aware endpoints, but require separate candidates
to be gathered for each media stream.</dd> to be gathered for each media stream.</dd>
<dt/>
<dd/>
<dt>max-bundle:</dt> <dt>max-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 aims to first will be marked as bundle-only. This policy aims to
minimize candidate gathering and maximize multiplexing, at minimize candidate gathering and maximize multiplexing, 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 tradeoff between performance and <t>As it provides the best tradeoff between performance and
compatibility with legacy endpoints, the default bundle compatibility with legacy endpoints, the default bundle
policy MUST be set to "balanced".</t> policy <bcp14>MUST</bcp14> be set to "balanced".</t>
<t>The application can specify its preferred policy regarding <t>The application can specify its preferred policy regarding
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>
<dt>require:</dt> <dt>require:</dt>
<dd>The JSEP implementation will only <dd>The JSEP implementation will only
gather RTP candidates and will insert an "a=rtcp-mux-only" gather RTP candidates and will insert an "a=rtcp-mux-only"
indication into any new m= sections in offers it generates. indication into any new m= sections in offers it generates.
This halves the number of candidates that the offerer needs This halves the number of candidates that the offerer needs
to gather. Applying a description with an m= section that to gather. Applying a description with an m= section that
does not contain an "a=rtcp-mux" attribute will cause an does not contain an "a=rtcp-mux" attribute will cause an
error to be returned.</dd> error to be returned.</dd>
</dl> </dl>
<t>The default multiplexing policy MUST be set to "require". <t>The default multiplexing policy <bcp14>MUST</bcp14> be set to "requ
Implementations MAY choose to reject attempts by the ire".
Implementations <bcp14>MAY</bcp14> choose to reject attempts by the
application to set the multiplexing policy to application to set the multiplexing policy to
"negotiate".</t> "negotiate".</t>
</section> </section>
<section anchor="sec.addTrack" numbered="true" toc="default"> <section anchor="sec.addTrack" numbered="true" toc="default">
<name>addTrack</name> <name>addTrack</name>
<t>The addTrack method adds a MediaStreamTrack to the <t>The addTrack method adds a MediaStreamTrack to the
PeerConnection, using the MediaStream argument to associate PeerConnection, using the MediaStream argument to associate
the track with other tracks in the same MediaStream, so that the track with other tracks in the same MediaStream, so that
they can be added to the same "LS" group when creating an they can be added to the same "LS" group when creating an
offer or answer. Adding tracks to the same "LS" group offer or answer. Adding tracks to the same "LS" group
indicates that the playback of these tracks should be indicates that the playback of these tracks should be
synchronized for proper lip sync, as described in synchronized for proper lip sync, as described in
<xref target="RFC5888" format="default"/>, Section 7. addTrack attempt s <xref target="RFC5888" sectionFormat="comma" section="7"/>. addTrack a ttempts
to minimize the number of transceivers as follows: If the to minimize the number of transceivers as follows: If the
PeerConnection is in the "have-remote-offer" state, the track PeerConnection is in the "have-remote-offer" state, the track
will be attached to the first compatible transceiver that was will be attached to the first compatible transceiver that was
created by the most recent call to setRemoteDescription() and created by the most recent call to setRemoteDescription() and
does not have a local track. Otherwise, a new transceiver does not have a local track. Otherwise, a new transceiver
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>
skipping to change at line 1112 skipping to change at line 1107
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 MUST 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
which the transceiver is associated with (allowing LS group which 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>
skipping to change at line 1193 skipping to change at line 1188
does not become the pending local description, until does not become the pending local description, until
setLocalDescription is called.</t> setLocalDescription is called.</t>
</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 a contains a
<xref target="RFC3264" format="default"/> SDP answer with the supporte d <xref target="RFC3264" format="default"/> SDP answer with the supporte d
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, which MUST have been called prior to setRemoteDescription, which <bcp14>MUST</bcp14> have been 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/RTCP options negotiated for
this session, and any candidates that have been gathered by this session, 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
must follow the process defined for generating an answer from must follow the process defined for generating an answer from
skipping to change at line 1259 skipping to change at line 1254
change the type of the session description as needed. For change the type of the session description as needed. For
example, in a serial forking scenario, an application may example, in a serial forking scenario, an application may
receive multiple "final" answers, one from each remote receive multiple "final" answers, one from each remote
endpoint. The application could choose to accept the initial endpoint. The application could choose to accept the initial
answers as provisional answers, and only apply an answer as answers as provisional answers, and only apply an answer as
final when it receives one that meets its criteria (e.g. a final when it receives one that meets its criteria (e.g. a
live user instead of voicemail).</t> live user instead of voicemail).</t>
<t>"rollback" is a special session description type implying <t>"rollback" is a special session description type implying
that the state machine should be rolled back to the previous that the state machine should be rolled back to the previous
stable state, as described in stable state, as described in
<xref target="sec.rollback" format="default"/>. The contents MUST be <xref target="sec.rollback" format="default"/>. The contents <bcp14>MU ST</bcp14> be
empty.</t> empty.</t>
<section anchor="sec.use-of-provisional-answer" numbered="true" toc="d efault"> <section anchor="sec.use-of-provisional-answer" numbered="true" toc="d efault">
<name>Use of Provisional Answers</name> <name>Use of Provisional Answers</name>
<t>Most applications will not need to create answers using <t>Most applications will not need to create answers using
the "pranswer" type. While it is good practice to send an the "pranswer" type. While it is good practice to send an
immediate response to an offer, in order to warm up the immediate response to an offer, in order to warm up the
session transport and prevent media clipping, the preferred session transport and prevent media clipping, the preferred
handling for a JSEP application is to create and send a handling for a JSEP application is to create and send a
"sendonly" final answer with a null MediaStreamTrack "sendonly" final answer with a null MediaStreamTrack
immediately after receiving the offer, which will prevent immediately after receiving the offer, which will prevent
skipping to change at line 1482 skipping to change at line 1477
and new candidates will be gathered from the new and new candidates will be gathered from the new
servers.</li> servers.</li>
<li>Any change to the ICE candidate policy affects the <li>Any change to the ICE candidate policy affects the
next gathering phase. If an ICE gathering phase has next gathering phase. If an ICE gathering phase has
already started or completed, the 'needs-ice-restart' bit already started or completed, the 'needs-ice-restart' bit
will be set. Either way, changes to the policy have no will be set. Either way, changes to the policy have no
effect on the candidate pool, because pooled candidates effect on the candidate pool, because pooled candidates
are not made available to the application until a are not made available to the application until a
gathering phase occurs, and so any necessary filtering gathering phase occurs, and so any necessary filtering
can still be done on any pooled candidates.</li> can still be done on any pooled candidates.</li>
<li>The ICE candidate pool size MUST NOT be changed after <li>The ICE candidate pool size <bcp14>MUST NOT</bcp14> be changed a fter
applying a local description. If a local description has applying a local description. If a local description has
not yet been applied, any changes to the ICE candidate not yet been applied, any changes to the ICE candidate
pool size take effect immediately; if increased, pool size take effect immediately; if increased,
additional candidates are pre-gathered; if decreased, the additional candidates are pre-gathered; if decreased, the
now-superfluous candidates are discarded.</li> now-superfluous candidates are discarded.</li>
<li>The bundle and RTCP-multiplexing policies MUST NOT be <li>The bundle and RTCP-multiplexing policies <bcp14>MUST NOT</bcp14 > be
changed after the construction of the PeerConnection.</li> changed after the construction of the PeerConnection.</li>
</ul> </ul>
<t>This call may result in a change to the state of the ICE <t>This call may result in a change to the state of the ICE
Agent.</t> Agent.</t>
</section> </section>
<section anchor="sec.addicecandidate" numbered="true" toc="default"> <section anchor="sec.addicecandidate" numbered="true" toc="default">
<name>addIceCandidate</name> <name>addIceCandidate</name>
<t>The addIceCandidate method provides an update to the ICE <t>The addIceCandidate method provides an update to the ICE
agent via an IceCandidate object agent via an IceCandidate object
<xref target="sec.ice-candidate-format" format="default"/>. If the <xref target="sec.ice-candidate-format" format="default"/>. If the
IceCandidate's candidate field is filled in, the IceCandidate IceCandidate's candidate field is filled in, the IceCandidate
is treated as a new remote ICE candidate, which will be added is treated as a new remote ICE candidate, which will be added
to the current and/or pending remote description according to to the current and/or pending remote description according to
the rules defined for Trickle ICE. Otherwise, the the rules defined for Trickle ICE. Otherwise, the
IceCandidate is treated as an end-of-candidates indication, IceCandidate is treated as an end-of-candidates indication,
as defined in as defined in
<xref target="I-D.ietf-ice-trickle" format="default"/>.</t> <xref target="RFCYYY6" format="default"/>.</t>
<t>In either case, the m= section index, MID, and ufrag <t>In either case, the m= section index, MID, and ufrag
fields from the supplied IceCandidate are used to determine fields from the supplied IceCandidate are used to determine
which m= section and ICE candidate generation the which m= section and ICE candidate generation the
IceCandidate belongs to, as described in IceCandidate belongs to, as described in
<xref target="sec.ice-candidate-format" format="default"/> above. In t he case <xref target="sec.ice-candidate-format" format="default"/> above. In t he case
of an end-of-candidates indication, the absence of both the of an end-of-candidates indication, the absence of both the
m= section index and MID fields is interpreted to mean that m= section index and MID fields is interpreted to mean that
the indication applies to all m= sections in the specified the indication applies to all m= sections in the specified
ICE candidate generation. However, if both fields are absent ICE candidate generation. However, if both fields are absent
for a new remote candidate, this MUST 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 MUST be ignored and an object, the supplied IceCandidate <bcp14>MUST</bcp14> be ignored and a
error MUST be returned.</t> n
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.</t> candidate.</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>
skipping to change at line 1554 skipping to change at line 1549
restarted.</t> restarted.</t>
</section> </section>
<section anchor="sec.transceiver-set-direction" numbered="true" toc="def ault"> <section anchor="sec.transceiver-set-direction" numbered="true" toc="def ault">
<name>setDirection</name> <name>setDirection</name>
<t>The setDirection method sets the direction of a <t>The setDirection method sets the direction of a
transceiver, which affects the direction property of the transceiver, which affects the direction property of the
associated m= section on future calls to createOffer and associated m= section on future calls to createOffer and
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 directional attributes defined in the identically-named directional attributes defined in
<xref target="RFC4566" format="default"/>, 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 ( of the transceiver immediately (
<xref target="sec.transceiver-direction" format="default"/>), this pro perty <xref target="sec.transceiver-direction" format="default"/>), this pro perty
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
skipping to change at line 1630 skipping to change at line 1625
<t>This section describes the specific procedures to be followed <t>This section describes the specific procedures to be followed
when creating and parsing SDP objects.</t> when creating and parsing SDP objects.</t>
<section anchor="sec.requirements-overview" numbered="true" toc="default"> <section anchor="sec.requirements-overview" numbered="true" toc="default">
<name>Requirements Overview</name> <name>Requirements Overview</name>
<t>JSEP implementations must comply with the specifications <t>JSEP implementations must comply with the specifications
listed below that govern the creation and processing of offers listed below that govern the creation and processing of offers
and answers.</t> and answers.</t>
<section anchor="sec.usage-requirements" numbered="true" toc="default"> <section anchor="sec.usage-requirements" numbered="true" toc="default">
<name>Usage Requirements</name> <name>Usage Requirements</name>
<t>All session descriptions handled by JSEP implementations, <t>All session descriptions handled by JSEP implementations,
both local and remote, MUST indicate support for the both local and remote, <bcp14>MUST</bcp14> indicate support for the
following specifications. If any of these are absent, this following specifications. If any of these are absent, this
omission MUST be treated as an error. omission <bcp14>MUST</bcp14> be treated as an error.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>ICE, as specified in <li>ICE, as specified in
<xref target="RFC8445" format="default"/>, MUST be used. Note that t he <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 MUST properly handle remote endpoints which implementations <bcp14>MUST</bcp14> properly handle remote endpoints which
do ICE-Lite.</li> do ICE-Lite.</li>
<li>DTLS <li>DTLS
<xref target="RFC6347" format="default"/> or DTLS-SRTP <xref target="RFC6347" format="default"/> or DTLS-SRTP
<xref target="RFC5763" format="default"/>, MUST be used, as <xref target="RFC5763" format="default"/>, <bcp14>MUST</bcp14> be us ed, as
appropriate for the media type, as specified in appropriate for the media type, as specified in
<xref target="I-D.ietf-rtcweb-security-arch" format="default"/></li> <xref target="RFCYYY2" format="default"/></li>
</ul> </ul>
<t>The SDES SRTP keying mechanism from <t>The SDES SRTP keying mechanism from
<xref target="RFC4568" format="default"/> MUST NOT be used, as discuss <xref target="RFC4568" format="default"/> <bcp14>MUST NOT</bcp14> be u
ed in sed, as discussed in
<xref target="I-D.ietf-rtcweb-security-arch" format="default"/>.</t> <xref target="RFCYYY2" 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 MUST support <t>For media m= sections, JSEP implementations <bcp14>MUST</bcp14> sup port
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 MU ST indicate profile specified in <xref target="RFC7850" format="default"/>, and <b cp14>MUST</bcp14> indicate
one of these profiles for each media m= line they produce in an offer. one of these profiles for each media m= line they produce in an offer.
For data m= sections, implementations MUST support the For data m= sections, implementations <bcp14>MUST</bcp14> support the
"UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and
MUST indicate one of these profiles for each data m= line they produce <bcp14>MUST</bcp14> indicate one of these profiles for each data m= li ne they produce
in an offer. The exact profile to use is determined by the protocol in an offer. The exact profile to use is determined by the protocol
associated with the current default or selected ICE candidate, as associated with the current default or selected ICE candidate, as
described in described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, Section <xref target="RFCYYY7" sectionFormat="comma" section="3.2.1.2"/>.</t>
3.2.1.2.
</t>
<t>Unfortunately, in an attempt at compatibility, some <t>Unfortunately, in an attempt at compatibility, some
endpoints generate other profile strings even when they mean endpoints generate other profile strings even when they mean
to support one of these profiles. For instance, an endpoint to support one of these profiles. For instance, an endpoint
might generate "RTP/AVP" but supply "a=fingerprint" and might generate "RTP/AVP" but supply "a=fingerprint" and
"a=rtcp-fb" attributes, indicating its willingness to support "a=rtcp-fb" attributes, indicating its willingness to support
"UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". In order to "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". In order to
simplify compatibility with such endpoints, JSEP simplify compatibility with such endpoints, JSEP
implementations MUST follow the following rules when implementations <bcp14>MUST</bcp14> follow the following rules when
processing the media m= sections in a received offer:</t> processing the media m= sections in a received offer:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Any profile in the offer matching one of the following <t>Any profile in the offer matching one of the following
MUST be accepted: <bcp14>MUST</bcp14> be accepted:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>"RTP/AVP" (Defined in <li>"RTP/AVP" (Defined in
<xref target="RFC4566" format="default"/>, Section 8.2.2)</li> <xref target="RFC4566" sectionFormat="comma" section="8.2.2"/>)< /li>
<li>"RTP/AVPF" (Defined in <li>"RTP/AVPF" (Defined in
<xref target="RFC4585" format="default"/>, Section 9)</li> <xref target="RFC4585" sectionFormat="comma" section="9"/>)</li>
<li>"RTP/SAVP" (Defined in <li>"RTP/SAVP" (Defined in
<xref target="RFC3711" format="default"/>, Section 12)</li> <xref target="RFC3711" sectionFormat="comma" section="12"/>)</li >
<li>"RTP/SAVPF" (Defined in <li>"RTP/SAVPF" (Defined in
<xref target="RFC5124" format="default"/>, Section 6)</li> <xref target="RFC5124" sectionFormat="comma" section="6"/>)</li>
<li>"TCP/DTLS/RTP/SAVP" (Defined in <li>"TCP/DTLS/RTP/SAVP" (Defined in
<xref target="RFC7850" format="default"/>, Section 3.4)</li> <xref target="RFC7850" sectionFormat="comma" section="3.4"/>)</l i>
<li>"TCP/DTLS/RTP/SAVPF" (Defined in <li>"TCP/DTLS/RTP/SAVPF" (Defined in
<xref target="RFC7850" format="default"/>, Section 3.5)</li> <xref target="RFC7850" sectionFormat="comma" section="3.5"/>)</l i>
<li>"UDP/TLS/RTP/SAVP" (Defined in <li>"UDP/TLS/RTP/SAVP" (Defined in
<xref target="RFC5764" format="default"/>, Section 9)</li> <xref target="RFC5764" sectionFormat="comma" section="9"/>)</li>
<li>"UDP/TLS/RTP/SAVPF" (Defined in <li>"UDP/TLS/RTP/SAVPF" (Defined in
<xref target="RFC5764" format="default"/>, Section 9)</li> <xref target="RFC5764" sectionFormat="comma" section="9"/>)</li>
</ul> </ul>
</li> </li>
<li>The profile in any "m=" line in any generated answer <li>The profile in any "m=" line in any generated answer
MUST exactly match the profile provided in the offer.</li> <bcp14>MUST</bcp14> exactly match the profile provided in the offe
<li>Because DTLS-SRTP is REQUIRED, the choice of SAVP or r.</li>
<li>Because DTLS-SRTP is <bcp14>REQUIRED</bcp14>, the choice of SAVP
or
AVP has no effect; support for DTLS-SRTP is determined by AVP has no effect; support for DTLS-SRTP is determined by
the presence of one or more "a=fingerprint" attribute. the presence of one or more "a=fingerprint" attribute.
Note that lack of an "a=fingerprint" attribute will lead Note that lack of an "a=fingerprint" attribute will lead
to negotiation failure.</li> to negotiation failure.</li>
<li>The use of AVPF or AVP simply controls the timing <li>The use of AVPF or AVP simply controls the timing
rules used for RTCP feedback. If AVPF is provided, or an rules used for RTCP feedback. If AVPF is provided, or an
"a=rtcp-fb" attribute is present, assume AVPF timing, "a=rtcp-fb" attribute is present, assume AVPF timing,
i.e., a default value of "trr-int=0". Otherwise, assume i.e., a default value of "trr-int=0". Otherwise, assume
that AVPF is being used in an AVP compatible mode and use that AVPF is being used in an AVP compatible mode and use
a value of "trr-int=4000".</li> a value of "trr-int=4000".</li>
<li>For data m= sections, implementations MUST support <li>For data m= sections, implementations <bcp14>MUST</bcp14> suppor t
receiving the "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or receiving the "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or
"DTLS/SCTP" (for backwards compatibility) profiles.</li> "DTLS/SCTP" (for backwards compatibility) profiles.</li>
</ul> </ul>
<t>Note that re-offers by JSEP implementations MUST use the <t>Note that re-offers by JSEP implementations <bcp14>MUST</bcp14> use the
correct profile strings even if the initial offer/answer correct profile strings even if the initial offer/answer
exchange used an (incorrect) older profile string. This exchange used an (incorrect) older profile string. This
simplifies JSEP behavior, with minimal downside, as any simplifies JSEP behavior, with minimal downside, as any
remote endpoint that fails to handle such a re-offer will remote endpoint that fails to handle such a re-offer will
also fail to handle a JSEP endpoint's initial offer.</t> also fail to handle a JSEP endpoint's initial offer.</t>
</section> </section>
</section> </section>
<section anchor="sec-create-offer" numbered="true" toc="default"> <section anchor="sec-create-offer" numbered="true" toc="default">
<name>Constructing an Offer</name> <name>Constructing an Offer</name>
<t>When createOffer is called, a new SDP description must be <t>When createOffer is called, a new SDP description must be
created that includes the functionality specified in created that includes the functionality specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>. The exact <xref target="RFCYYY5" format="default"/>. The exact
details of this process are explained below.</t> details of this process are explained below.</t>
<section anchor="sec.initial-offers" numbered="true" toc="default"> <section anchor="sec.initial-offers" numbered="true" toc="default">
<name>Initial Offers</name> <name>Initial Offers</name>
<t>When createOffer is called for the first time, the result <t>When createOffer is called for the first time, the result
is known as the initial offer.</t> is known as the initial offer.</t>
<t>The first step in generating an initial offer is to <t>The first step in generating an initial offer is to
generate session-level attributes, as specified in generate session-level attributes, as specified in
<xref target="RFC4566" format="default"/>, Section 5. Specifically: <xref target="RFC4566" sectionFormat="comma" section="5"/>. Specifical ly:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The first SDP line MUST be "v=0", as specified in <li>The first SDP line <bcp14>MUST</bcp14> be "v=0", as specified in
<xref target="RFC4566" format="default"/>, Section 5.1</li> <xref target="RFC4566" sectionFormat="comma" section="5.1"/></li>
<li>The second SDP line MUST be an "o=" line, as specified <li>The second SDP line <bcp14>MUST</bcp14> be an "o=" line, as spec
ified
in in
<xref target="RFC4566" format="default"/>, Section 5.2. The value of <xref target="RFC4566" sectionFormat="comma" section="5.2"/>. The va
the &lt;username&gt; field SHOULD be "-". The sess-id MUST lue of
the &lt;username&gt; field <bcp14>SHOULD</bcp14> be "-". The sess-id
<bcp14>MUST</bcp14>
be representable by a 64-bit signed integer, and the be representable by a 64-bit signed integer, and the
value MUST be less than (2**63)-1. It is RECOMMENDED that the value <bcp14>MUST</bcp14> be less than (2**63)-1. It is <bcp14>RECOM MENDED</bcp14> that the
sess-id be constructed by generating a 64-bit quantity with sess-id be constructed by generating a 64-bit quantity with
the highest bit set to zero and the remaining 63 the highest bit set to zero and the remaining 63
bits being cryptographically random. The value of the bits being cryptographically random. The value of the
&lt;nettype&gt; &lt;addrtype&gt; &lt;unicast-address&gt; &lt;nettype&gt; &lt;addrtype&gt; &lt;unicast-address&gt;
tuple SHOULD be set to a non-meaningful address, such as IN tuple <bcp14>SHOULD</bcp14> be set to a non-meaningful address, such as IN
IP4 0.0.0.0, to prevent leaking a local IP address in this IP4 0.0.0.0, to prevent leaking a local IP address in this
field; this problem is discussed in field; this problem is discussed in
<xref target="I-D.ietf-rtcweb-ip-handling" format="default"/>. As me ntioned in <xref target="RFCYYY3" format="default"/>. As mentioned in
<xref target="RFC4566" format="default"/>, the entire o= line needs to <xref target="RFC4566" format="default"/>, the entire o= line needs to
be unique, but selecting a random number for be unique, but selecting a random number for
&lt;sess-id&gt; is sufficient to accomplish this.</li> &lt;sess-id&gt; is sufficient to accomplish this.</li>
<li>The third SDP line MUST be a "s=" line, as specified in <li>The third SDP line <bcp14>MUST</bcp14> be a "s=" line, as specif
<xref target="RFC4566" format="default"/>, Section 5.3; to match the ied in
"o=" line, a single dash SHOULD be used as the session <xref target="RFC4566" sectionFormat="comma" section="5.3"/>; to mat
ch the
"o=" line, a single dash <bcp14>SHOULD</bcp14> be used as the sessio
n
name, e.g. "s=-". Note that this differs from the advice in name, e.g. "s=-". Note that this differs from the advice in
<xref target="RFC4566" format="default"/> which proposes a single sp ace, but <xref target="RFC4566" format="default"/> which proposes a single sp ace, but
as both "o=" and "s=" are meaningless in JSEP, having the as both "o=" and "s=" are meaningless in JSEP, having the
same meaningless value seems clearer.</li> same meaningless value seems clearer.</li>
<li>Session Information ("i="), URI ("u="), Email Address <li>Session Information ("i="), URI ("u="), Email Address
("e="), Phone Number ("p="), Repeat Times ("r="), and Time ("e="), Phone Number ("p="), Repeat Times ("r="), and Time
Zones ("z=") lines are not useful in this context and Zones ("z=") lines are not useful in this context and
SHOULD NOT be included.</li> <bcp14>SHOULD NOT</bcp14> be included.</li>
<li>Encryption Keys ("k=") lines do not provide sufficient <li>Encryption Keys ("k=") lines do not provide sufficient
security and MUST NOT be included.</li> security and <bcp14>MUST NOT</bcp14> be included.</li>
<li>A "t=" line MUST be added, as specified in <li>A "t=" line <bcp14>MUST</bcp14> be added, as specified in
<xref target="RFC4566" format="default"/>, Section 5.9; both <xref target="RFC4566" sectionFormat="comma" section="5.9"/>; both
&lt;start-time&gt; and &lt;stop-time&gt; SHOULD be set to &lt;start-time&gt; and &lt;stop-time&gt; <bcp14>SHOULD</bcp14> be se
t to
zero, e.g. "t=0 0".</li> zero, e.g. "t=0 0".</li>
<li>An "a=ice-options" line with the "trickle" and "ice2" <li>An "a=ice-options" line with the "trickle" and "ice2"
options MUST be added, as specified in <xref target="I-D.ietf-ice-tr options <bcp14>MUST</bcp14> be added, as specified in <xref
ickle" format="default"/>, Section 3 and target="RFCYYY6" sectionFormat="comma" section="3"/> and
<xref target="RFC8445" format="default"/>, Section 10.</li> <xref target="RFC8445" sectionFormat="comma" section="10"/>.</li>
<li>If WebRTC identity is being used, an "a=identity" line <li>If WebRTC identity is being used, an "a=identity" line
as described in as described in
<xref target="I-D.ietf-rtcweb-security-arch" format="default"/>, Sec <xref target="RFCYYY2" sectionFormat="comma" section="5"/>.</li>
tion
5.</li>
</ul> </ul>
<t>The next step is to generate m= sections, as specified in <t>The next step is to generate m= sections, as specified in
<xref target="RFC4566" format="default"/>, Section 5.14. An m= section is <xref target="RFC4566" sectionFormat="comma" section="5.14"/>. An m= s ection is
generated for each RtpTransceiver that has been added to the generated for each RtpTransceiver that has been added to the
PeerConnection, excluding any stopped RtpTransceivers; this PeerConnection, excluding any stopped RtpTransceivers; this
is done in the order the RtpTransceivers were added to the is done in the order the RtpTransceivers were added to the
PeerConnection. If there are no such RtpTransceivers, no m= PeerConnection. If there are no such RtpTransceivers, no m=
sections are generated; more can be added later, as discussed sections are generated; more can be added later, as discussed
in in
<xref target="RFC3264" format="default"/>, Section 5.</t> <xref target="RFC3264" sectionFormat="comma" section="5"/>.</t>
<t>For each m= section generated for an RtpTransceiver, <t>For each m= section generated for an RtpTransceiver,
establish a mapping between the transceiver and the index of establish a mapping between the transceiver and the index of
the generated m= section.</t> the generated m= section.</t>
<t>Each m= section, provided it is not marked as bundle-only, <t>Each m= section, provided it is not marked as bundle-only,
MUST generate a unique set of ICE credentials and gather its <bcp14>MUST</bcp14> generate a unique set of ICE credentials and gathe r its
own unique set of ICE candidates. Bundle-only m= sections own unique set of ICE candidates. Bundle-only m= sections
MUST NOT contain any ICE credentials and MUST NOT gather any <bcp14>MUST NOT</bcp14> contain any ICE credentials and <bcp14>MUST NO T</bcp14> gather any
candidates.</t> candidates.</t>
<t>For DTLS, all m= sections MUST use all the certificate(s) <t>For DTLS, all m= sections <bcp14>MUST</bcp14> use all the certifica te(s)
that have been specified for the PeerConnection; as a result, that have been specified for the PeerConnection; as a result,
they MUST all have the same they <bcp14>MUST</bcp14> all have the same
<xref target="RFC8122" format="default"/> fingerprint value(s), or the se <xref target="RFC8122" format="default"/> fingerprint value(s), or the se
value(s) MUST be session-level attributes.</t> value(s) <bcp14>MUST</bcp14> be session-level attributes.</t>
<t>Each m= section should be generated as specified in <t>Each m= section should be generated as specified in
<xref target="RFC4566" format="default"/>, Section 5.14. For the m= li <xref target="RFC4566" sectionFormat="comma" section="5.14"/>. For the
ne m= line
itself, the following rules MUST 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
port value MUST be set to 0. Otherwise, the port value is port value <bcp14>MUST</bcp14> be set to 0. Otherwise, the port valu e 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 "dummy" port value of 9 (Discard) MUST be used, as the "dummy" port value of 9 (Discard) <bcp14>MUST</bcp14> be used, a s
indicated in indicated in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section <xref target="RFCYYY6" sectionFormat="comma" section="5.1"/>.</li>
5.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 MUST be set to "UDP/TLS/RTP/SAVPF", as specified in field <bcp14>MUST</bcp14> be set to "UDP/TLS/RTP/SAVPF", as specifie
<xref target="RFC5764" format="default"/>, Section 8.</li> d in
<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 MUST be generated in the transceiver, media formats <bcp14>MUST</bcp14> be generated in the
corresponding order, and MUST 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
formats MUST include the mandatory audio/video codecs as formats <bcp14>MUST</bcp14> include the mandatory audio/video codecs as
specified in specified in
<xref target="RFC7874" format="default"/>, Section 3, and <xref target="RFC7874" sectionFormat="comma" section="3"/>, and
<xref target="RFC7742" format="default"/>, Section 5.</li> <xref target="RFC7742" sectionFormat="comma" section="5"/>.</li>
</ul> </ul>
<t>The m= line MUST be followed immediately by a "c=" line, <t>The m= line <bcp14>MUST</bcp14> be followed immediately by a "c=" l ine,
as specified in as specified in
<xref target="RFC4566" format="default"/>, Section 5.7. Again, as no <xref target="RFC4566" sectionFormat="comma" section="5.7"/>. Again, a s no
candidates are available yet, the "c=" line must contain the candidates are available yet, the "c=" line must contain the
"dummy" value "IN IP4 0.0.0.0", as defined in "dummy" value "IN IP4 0.0.0.0", as defined in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 5.1.</ t> <xref target="RFCYYY6" sectionFormat="comma" section="5.1"/>.</t>
<t> <t>
<xref target="I-D.ietf-mmusic-sdp-mux-attributes" format="default"/> g roups <xref target="RFCYYYH" format="default"/> groups
SDP attributes into different categories. To avoid SDP attributes into different categories. To avoid
unnecessary duplication when bundling, attributes of category unnecessary duplication when bundling, attributes of category
IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= IDENTICAL or TRANSPORT <bcp14>MUST NOT</bcp14> be repeated in bundled m=
sections, repeating the guidance from sections, repeating the guidance from
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default" <xref target="RFCYYYB"
/>, sectionFormat="comma" section="8.1"/>. This includes m= sections for w
Section 8.1. This includes m= sections for which bundling has hich bundling has
been negotiated and is still desired, as well as m= sections been negotiated and is still desired, as well as m= sections
marked as bundle-only.</t> marked as bundle-only.</t>
<t>The following attributes, which are of a category other <t>The following attributes, which are of a category other
than IDENTICAL or TRANSPORT, MUST be included in each m= than IDENTICAL or TRANSPORT, <bcp14>MUST</bcp14> be included in each m =
section:</t> section:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An "a=mid" line, as specified in <li>An "a=mid" line, as specified in
<xref target="RFC5888" format="default"/>, Section 4. All MID valu <xref target="RFC5888" sectionFormat="comma" section="4"/>. All MI
es D values
MUST be generated in a fashion that does not leak user <bcp14>MUST</bcp14> be generated in a fashion that does not leak u
ser
information, e.g., randomly or using a per-PeerConnection information, e.g., randomly or using a per-PeerConnection
counter, and SHOULD be 3 bytes or less, to allow them to counter, and <bcp14>SHOULD</bcp14> be 3 bytes or less, to allow th em to
efficiently fit into the RTP header extension defined in efficiently fit into the RTP header extension defined in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defa <xref target="RFCYYYB" sectionFormat="comma" section="14"/>. Note
ult"> that this does not set the
</xref>, Section 14. Note that this does not set the
RtpTransceiver mid property, as that only occurs when the RtpTransceiver mid property, as that only occurs when the
description is applied. The generated MID value can be description is applied. The generated MID value can be
considered a "proposed" MID at this point.</li> considered a "proposed" MID at this point.</li>
<li>A direction attribute which is the same as that of the <li>A direction attribute which is the same as that of the
associated transceiver.</li> associated transceiver.</li>
<li>For each media format on the m= line, "a=rtpmap" and <li>For each media format on the m= line, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" format="default"/>, Section 6, and <xref target="RFC4566" sectionFormat="comma" section="6"/>, and
<xref target="RFC3264" format="default"/>, 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" format="default"/>, 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 supported FEC mechanism, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" format="default"/>, Section 6. The FEC <xref target="RFC4566" sectionFormat="comma" section="6"/>. The FE
mechanisms that MUST be supported are specified in C
<xref target="I-D.ietf-rtcweb-fec" format="default"/>, Section 6, mechanisms that <bcp14>MUST</bcp14> be supported are specified in
<xref target="RFCYYYF" sectionFormat="comma" section="6"/>,
and specific usage for each media type is outlined in and specific usage for each media type is outlined in
Sections 4 and 5.</li> Sections <xref target="sec.interface" format="counter"/> and <xref
target="sec.sdp-interaction-procedure"
format="counter"/>.</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" format="default"/>, Section 6. This value i s <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 which can be known limitations on the size of images which 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 supported RTP header extension, an "a=extmap"
line, as specified in line, as specified in
<xref target="RFC5285" format="default"/>, Section 5. The list of <xref target="RFC5285" sectionFormat="comma" section="5"/>. The li
header extensions that SHOULD/MUST be supported is st of
header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> b
e supported is
specified in specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>, Secti <xref target="RFCYYY5" sectionFormat="comma" section="5.2"/>. Any
on header extensions that require encryption <bcp14>MUST</bcp14>
5.2. Any header extensions that require encryption MUST
be specified as indicated in be specified as indicated in
<xref target="RFC6904" format="default"/>, Section 4.</li> <xref target="RFC6904" sectionFormat="comma" section="4"/>.</li>
<li>For each supported RTCP feedback mechanism, an <li>For each supported RTCP feedback mechanism, an
"a=rtcp-fb" line, as specified in "a=rtcp-fb" line, as specified in
<xref target="RFC4585" format="default"/>, Section 4.2. The list o <xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The
f list of
RTCP feedback mechanisms that SHOULD/MUST be supported is RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</b
cp14> be supported is
specified in specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>, Secti <xref target="RFCYYY5" sectionFormat="comma" section="5.1"/>.</li>
on
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="I-D.ietf-mmusic-msid" format="default"/>, Section 2, <xref target="RFCYYY4" 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 RID values direction, and the application has specified RID values
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="I-D.ietf-mmusic-rid" format="default"/>, and its <xref target="RFCYYYC" format="default"/>, and its
direction MUST be "send". If the application has chosen a direction <bcp14>MUST</bcp14> be "send". If the application has ch
RID value, it MUST be used as the rid-identifier; osen a
otherwise a RID value MUST be generated by the RID value, it <bcp14>MUST</bcp14> be used as the rid-identifier;
implementation. RID values MUST be generated in a fashion otherwise a RID value <bcp14>MUST</bcp14> be generated by the
implementation. RID values <bcp14>MUST</bcp14> be generated in a f
ashion
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, and SHOULD be 3 bytes using a per-PeerConnection counter, 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 extension defined in header extension defined in
<xref target="I-D.ietf-avtext-rid" format="default"/>, Section 3. If <xref target="RFCYYYD" sectionFormat="comma" section="3"/>. If
no encodings have been specified, or only one encoding is no encodings have been specified, or only one encoding is
specified but without a RID value, then no "a=rid" lines specified but without a RID value, 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="I-D.ietf-mmusic-sdp-simulcast" format="default"/>, <xref target="RFCYYYE" sectionFormat="comma" section="6.2"/>. The
Section 6.2. The list of RIDs MUST include all of the RID list of RIDs <bcp14>MUST</bcp14> include all of the RID
identifiers used in the "a=rid" lines for this m= identifiers used in the "a=rid" lines for this m=
section.</li> section.</li>
<li>If the bundle policy for this PeerConnection is set to <li>If the bundle policy for this PeerConnection is set to
"max-bundle", and this is not the first m= section, or "max-bundle", and this is not the first m= section, or
the bundle policy is set to "balanced", and this is not the bundle policy is set to "balanced", and this is not
the first m= section for this media type, an the first m= section for this media type, an
"a=bundle-only" line.</li> "a=bundle-only" line.</li>
</ul> </ul>
<t>The following attributes, which are of category IDENTICAL <t>The following attributes, which are of category IDENTICAL
or TRANSPORT, MUST appear only in "m=" sections which either or TRANSPORT, <bcp14>MUST</bcp14> appear only in "m=" sections which e ither
have a unique address or which are associated with the have a unique address or which are associated with the
bundle-tag. (In initial offers, this means those "m=" bundle-tag. (In initial offers, this means those "m="
sections which do not contain an "a=bundle-only" sections which do not contain an "a=bundle-only"
attribute.)</t> attribute.)</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"a=ice-ufrag" and "a=ice-pwd" lines, as specified in <li>"a=ice-ufrag" and "a=ice-pwd" lines, as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>.</li>
Section 4.4.</li>
<li>For each desired digest algorithm, one or more <li>For each desired digest algorithm, one or more
"a=fingerprint" lines for each of the endpoint's "a=fingerprint" lines for each of the endpoint's
certificates, as specified in certificates, as specified in
<xref target="RFC8122" format="default"/>, Section 5.</li> <xref target="RFC8122" sectionFormat="comma" section="5"/>.</li>
<li>An "a=setup" line, as specified in <li>An "a=setup" line, as specified in
<xref target="RFC4145" format="default"/>, Section 4, and clarifie d <xref target="RFC4145" sectionFormat="comma" section="4"/>, and cl arified
for use in DTLS-SRTP scenarios in for use in DTLS-SRTP scenarios in
<xref target="RFC5763" format="default"/>, Section 5. The role val <xref target="RFC5763" sectionFormat="comma" section="5"/>. The ro
ue le value
in the offer MUST be "actpass".</li> in the offer <bcp14>MUST</bcp14> be "actpass".</li>
<li>An "a=tls-id" line, as specified in <li>An "a=tls-id" line, as specified in
<xref target="I-D.ietf-mmusic-dtls-sdp" format="default"/>, Sectio <xref target="RFCYYYA" sectionFormat="comma" section="5.2"/>.</li>
n
5.2.</li>
<li>An "a=rtcp" line, as specified in <li>An "a=rtcp" line, as specified in
<xref target="RFC3605" format="default"/>, Section 2.1, containing <xref target="RFC3605" sectionFormat="comma" section="2.1"/>, cont aining
the dummy value "9 IN IP4 0.0.0.0", because no candidates the dummy value "9 IN IP4 0.0.0.0", because no candidates
have yet been gathered.</li> have yet been gathered.</li>
<li>An "a=rtcp-mux" line, as specified in <li>An "a=rtcp-mux" line, as specified in
<xref target="RFC5761" format="default"/>, Section 5.1.3.</li> <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>.</l i>
<li>If the RTP/RTCP multiplexing policy is "require", an <li>If the RTP/RTCP multiplexing policy is "require", an
"a=rtcp-mux-only" line, as specified in "a=rtcp-mux-only" line, as specified in
<xref target="I-D.ietf-mmusic-mux-exclusive" format="default"/>, S <xref target="RFCYYYG" sectionFormat="comma" section="4"/>.</li>
ection
4.</li>
<li>An "a=rtcp-rsize" line, as specified in <li>An "a=rtcp-rsize" line, as specified in
<xref target="RFC5506" format="default"/>, Section 5.</li> <xref target="RFC5506" sectionFormat="comma" section="5"/>.</li>
</ul> </ul>
<t>Lastly, if a data channel has been created, a m= section <t>Lastly, if a data channel has been created, a m= section
MUST be generated for data. The &lt;media&gt; field MUST be <bcp14>MUST</bcp14> be generated for data. The &lt;media&gt; field <bc
set to "application" and the &lt;proto&gt; field MUST be set p14>MUST</bcp14> be
set to "application" and the &lt;proto&gt; field <bcp14>MUST</bcp14> b
e set
to "UDP/DTLS/SCTP" to "UDP/DTLS/SCTP"
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>. The "fmt" <xref target="RFCYYY9" format="default"/>. The "fmt"
value MUST be set to "webrtc-datachannel" as specified in value <bcp14>MUST</bcp14> be set to "webrtc-datachannel" as specified
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section in
4.1.</t> <xref target="RFCYYY9" sectionFormat="comma" section="4.1"/>.</t>
<t>Within the data m= section, an "a=mid" line MUST be <t>Within the data m= section, an "a=mid" line <bcp14>MUST</bcp14> be
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="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section 5. 1, <xref target="RFCYYY9" 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="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section <xref target="RFCYYY9" sectionFormat="comma" section="6.1"/>.</t>
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=
section either has a unique address or is associated with the section either has a unique address or is associated with the
bundle-tag (e.g., if it is the only m= section): bundle-tag (e.g., if it is the only m= section):
</t> </t>
<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 MUST be added as specified in "a=group" attribute <bcp14>MUST</bcp14> be added as specified in
<xref target="RFC5888" format="default"/>. This attribute MUST have <xref target="RFC5888" format="default"/>. This attribute <bcp14>MUST<
semantics "BUNDLE", and MUST include the mid identifiers of /bcp14> have
semantics "BUNDLE", and <bcp14>MUST</bcp14> include the mid identifier
s 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" format="default"/>, Section 7. For each MediaSt ream <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" MUST be added that contains methods), a group of type "LS" <bcp14>MUST</bcp14> be added that conta ins
the mid values for each RtpTransceiver.</t> the mid values for each RtpTransceiver.</t>
<t>Attributes which SDP permits to either be at the session <t>Attributes which SDP permits to either be at the session
level or the media level SHOULD generally be at the media level or the media level <bcp14>SHOULD</bcp14> generally be at the med ia
level even if they are identical. This assists development level even if they are identical. This assists development
and debugging by making it easier to understand individual and debugging by making it easier to understand individual
media sections, especially if one of a set of initially media sections, especially if one of a set of initially
identical attributes is subsequently changed. However, identical attributes is subsequently changed. However,
implementations MAY choose to aggregate attributes at the implementations <bcp14>MAY</bcp14> choose to aggregate attributes at t
session level and JSEP implementations MUST be prepared to he
session level and JSEP implementations <bcp14>MUST</bcp14> be prepared
to
receive attributes in either location.</t> receive attributes in either location.</t>
<t>Attributes other than the ones specified above MAY be <t>Attributes other than the ones specified above <bcp14>MAY</bcp14> b e
included, except for the following attributes which are included, except for the following attributes which are
specifically incompatible with the requirements of specifically incompatible with the requirements of
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>, and MUST <xref target="RFCYYY5" format="default"/>, and <bcp14>MUST
NOT be included: NOT</bcp14> be included:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>"a=crypto"</li> <li>"a=crypto"</li>
<li>"a=key-mgmt"</li> <li>"a=key-mgmt"</li>
<li>"a=ice-lite"</li> <li>"a=ice-lite"</li>
</ul> </ul>
<t>Note that when bundle is used, any additional attributes <t>Note that when bundle is used, any additional attributes
that are added MUST follow the advice in that are added <bcp14>MUST</bcp14> follow the advice in
<xref target="I-D.ietf-mmusic-sdp-mux-attributes" format="default"/> o <xref target="RFCYYYH" format="default"/> on
n
how those attributes interact with bundle.</t> how those attributes interact with bundle.</t>
<t>Note that these requirements are in some cases stricter <t>Note that these requirements are in some cases stricter
than those of SDP. Implementations MUST be prepared to accept than those of SDP. Implementations <bcp14>MUST</bcp14> be prepared to accept
compliant SDP even if it would not conform to the compliant SDP even if it would not conform to the
requirements for generating SDP in this specification.</t> requirements for generating SDP in this specification.</t>
</section> </section>
<section anchor="sec.subsequent-offers" numbered="true" toc="default"> <section anchor="sec.subsequent-offers" numbered="true" toc="default">
<name>Subsequent Offers</name> <name>Subsequent Offers</name>
<t>When createOffer is called a second (or later) time, or is <t>When createOffer is called a second (or later) time, or is
called after a local description has already been installed, called after a local description has already been installed,
the processing is somewhat different than for an initial the processing is somewhat different than for an initial
offer.</t> offer.</t>
<t>If the previous offer was not applied using <t>If the previous offer was not applied using
setLocalDescription, meaning the PeerConnection is still in setLocalDescription, meaning the PeerConnection is still in
the "stable" state, the steps for generating an initial offer the "stable" state, the steps for generating an initial offer
should be followed, subject to the following restriction: should be followed, subject to the following restriction:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The fields of the "o=" line MUST stay the same except <li>The fields of the "o=" line <bcp14>MUST</bcp14> stay the same ex
for the &lt;session-version&gt; field, which MUST increment cept
for the &lt;session-version&gt; field, which <bcp14>MUST</bcp14> inc
rement
by one on each call to createOffer if the offer might by one on each call to createOffer if the offer might
differ from the output of the previous call to createOffer; differ from the output of the previous call to createOffer;
implementations MAY opt to increment implementations <bcp14>MAY</bcp14> opt to increment
&lt;session-version&gt; on every call. The value of the &lt;session-version&gt; on every call. The value of the
generated &lt;session-version&gt; is independent of the generated &lt;session-version&gt; is independent of the
&lt;session-version&gt; of the current local description; &lt;session-version&gt; of the current local description;
in particular, in the case where the current version is N, in particular, in the case where the current version is N,
an offer is created and applied with version N+1, and then an offer is created and applied with version N+1, and then
that offer is rolled back so that the current version is that offer is rolled back so that the current version is
again N, the next generated offer will still have version again N, the next generated offer will still have version
N+2.</li> N+2.</li>
</ul> </ul>
<t>Note that if the application creates an offer by reading <t>Note that if the application creates an offer by reading
skipping to change at line 2104 skipping to change at line 2089
use createOffer to ensure a unique use createOffer to ensure a unique
&lt;session-version&gt;.</t> &lt;session-version&gt;.</t>
<t>If the previous offer was applied using <t>If the previous offer was applied using
setLocalDescription, but a corresponding answer from the setLocalDescription, but a corresponding answer from the
remote side has not yet been applied, meaning the remote side has not yet been applied, meaning the
PeerConnection is still in the "have-local-offer" state, an PeerConnection is still in the "have-local-offer" state, an
offer is generated by following the steps in the "stable" offer is generated by following the steps in the "stable"
state above, along with these exceptions: state above, along with these exceptions:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The "s=" and "t=" lines MUST stay the same.</li> <li>The "s=" and "t=" lines <bcp14>MUST</bcp14> stay the same.</li>
<li>If any RtpTransceiver has been added, and there exists <li>If any RtpTransceiver has been added, and there exists
an m= section with a zero port in the current local an m= section with a zero port in the current local
description or the current remote description, that m= description or the current remote description, that m=
section MUST be recycled by generating an m= section for section <bcp14>MUST</bcp14> be recycled by generating an m= section for
the added RtpTransceiver as if the m= section were being the added RtpTransceiver as if the m= section were being
added to the session description (including a new MID added to the session description (including a new MID
value), and placing it at the same index as the m= section value), and placing it at the same index as the m= section
with a zero port.</li> with a zero port.</li>
<li>If an RtpTransceiver is stopped and is not associated <li>If an RtpTransceiver is stopped and is not associated
with an m= section, an m= section MUST NOT be generated for with an m= section, an m= section <bcp14>MUST NOT</bcp14> be generat ed for
it. This prevents adding back RtpTransceivers whose m= it. This prevents adding back RtpTransceivers whose m=
sections were recycled and used for a new RtpTransceiver in sections were recycled and used for a new RtpTransceiver in
a previous offer/ answer exchange, as described above.</li> a previous offer/ answer exchange, as described above.</li>
<li>If an RtpTransceiver has been stopped and is associated <li>If an RtpTransceiver has been stopped and is associated
with an m= section, and the m= section is not being with an m= section, and the m= section is not being
recycled as described above, an m= section MUST be recycled as described above, an m= section <bcp14>MUST</bcp14> be
generated for it with the port set to zero and all "a=msid" generated for it with the port set to zero and all "a=msid"
lines removed.</li> lines removed.</li>
<li>For RtpTransceivers that are not stopped, the "a=msid" <li>For RtpTransceivers that are not stopped, the "a=msid"
line(s) MUST stay the same if they are present in the line(s) <bcp14>MUST</bcp14> stay the same if they are present in the
current description, regardless of changes to the current description, regardless of changes to the
transceiver's direction or track. If no "a=msid" line is transceiver's direction or track. If no "a=msid" line is
present in the current description, "a=msid" line(s) MUST present in the current description, "a=msid" line(s) <bcp14>MUST</bc p14>
be generated according to the same rules as for an initial be generated according to the same rules as for an initial
offer.</li> offer.</li>
<li>Each "m=" and c=" line MUST be filled in with the port, <li>Each "m=" and c=" line <bcp14>MUST</bcp14> be filled in with the port,
relevant RTP profile, and address of the default candidate for the relevant RTP profile, and address of the default candidate for the
m= section, as described in m= section, as described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="3.2.1.2"/>, an
Section 3.2.1.2, and clarified in d clarified in
<xref target="sec.profile-names" format="default"/>. <xref target="sec.profile-names" format="default"/>.
If no RTP candidates have yet been gathered, dummy If no RTP candidates have yet been gathered, dummy
values MUST still be used, as described above.</li> values <bcp14>MUST</bcp14> still be used, as described above.</li>
<li>Each "a=mid" line MUST stay the same.</li> <li>Each "a=mid" line <bcp14>MUST</bcp14> stay the same.</li>
<li>Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the <li>Each "a=ice-ufrag" and "a=ice-pwd" line <bcp14>MUST</bcp14> stay
the
same, unless the ICE configuration has changed (either same, unless the ICE configuration has changed (either
changes to the supported STUN/TURN servers, or the ICE changes to the supported STUN/TURN servers, or the ICE
candidate policy), or the "IceRestart" option ( candidate policy), or the "IceRestart" option (
<xref target="sec.icerestart" format="default"/> was specified. If t he m= <xref target="sec.icerestart" format="default"/> was specified. If t he m=
section is bundled into another m= section, it still MUST section is bundled into another m= section, it still <bcp14>MUST
NOT contain any ICE credentials.</li> NOT</bcp14> contain any ICE credentials.</li>
<li>If the m= section is not bundled into another m= <li>If the m= section is not bundled into another m=
section, its "a=rtcp" attribute line MUST be filled in with section, its "a=rtcp" attribute line <bcp14>MUST</bcp14> be filled i n with
the port and address of the default RTCP candidate, as the port and address of the default RTCP candidate, as
indicated in indicated in
<xref target="RFC5761" format="default"/>, Section 5.1.3. If no RTCP <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>. If n
candidates have yet been gathered, dummy values MUST be o RTCP
candidates have yet been gathered, dummy values <bcp14>MUST</bcp14>
be
used, as described in the initial offer section above.</li> used, as described in the initial offer section above.</li>
<li>If the m= section is not bundled into another m= <li>If the m= section is not bundled into another m=
section, for each candidate that has been gathered during section, for each candidate that has been gathered during
the most recent gathering phase (see the most recent gathering phase (see
<xref target="sec.ice-gather-overview" format="default"/>), an <xref target="sec.ice-gather-overview" format="default"/>), an
"a=candidate" line MUST be added, as defined in "a=candidate" line <bcp14>MUST</bcp14> be added, as defined in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, Secti <xref target="RFCYYY7" sectionFormat="comma" section="4.1"/>.
on 4.1.
If candidate gathering for the section has completed, an If candidate gathering for the section has completed, an
"a=end-of-candidates" attribute MUST be added, as described "a=end-of-candidates" attribute <bcp14>MUST</bcp14> be added, as des cribed
in in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 9.3. <xref target="RFCYYY6" sectionFormat="comma" section="9.3"/>.
If the m= section is bundled into another m= section, both If the m= section is bundled into another m= section, both
"a=candidate" and "a=end-of-candidates" MUST be "a=candidate" and "a=end-of-candidates" <bcp14>MUST</bcp14> be
omitted.</li> omitted.</li>
<li>For RtpTransceivers that are still present, the "a=rid" <li>For RtpTransceivers that are still present, the "a=rid"
lines MUST stay the same.</li> lines <bcp14>MUST</bcp14> stay the same.</li>
<li>For RtpTransceivers that are still present, any <li>For RtpTransceivers that are still present, any
"a=simulcast" line MUST stay the same.</li> "a=simulcast" line <bcp14>MUST</bcp14> stay the same.</li>
</ul> </ul>
<t>If the previous offer was applied using <t>If the previous offer was applied using
setLocalDescription, and a corresponding answer from the setLocalDescription, and a corresponding answer from the
remote side has been applied using setRemoteDescription, remote side has been applied using setRemoteDescription,
meaning the PeerConnection is in the "have-remote-pranswer" meaning the PeerConnection is in the "have-remote-pranswer"
or "stable" states, an offer is generated based on the or "stable" states, an offer is generated based on the
negotiated session descriptions by following the steps negotiated session descriptions by following the steps
mentioned for the "have-local-offer" state above.</t> mentioned for the "have-local-offer" state above.</t>
<t>In addition, for each existing, non-recycled, non-rejected <t>In addition, for each existing, non-recycled, non-rejected
m= section in the new offer, the following adjustments are m= section in the new offer, the following adjustments are
made based on the contents of the corresponding m= section in made based on the contents of the corresponding m= section in
the current local or remote description, as appropriate: the current local or remote description, as appropriate:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The m= line and corresponding "a=rtpmap" and "a=fmtp" <li>The m= line and corresponding "a=rtpmap" and "a=fmtp"
lines MUST only include media formats which have not been lines <bcp14>MUST</bcp14> only include media formats which have not been
excluded by the codec preferences of the associated excluded by the codec preferences of the associated
transceiver, and MUST include all currently available transceiver, and <bcp14>MUST</bcp14> include all currently available
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) MAY 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
MUST be generated in the same order as in the most recent <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 MUST be added after all existing formats.</li> recent answer <bcp14>MUST</bcp14> be added after all existing format
<li>The RTP header extensions MUST only include those that s.</li>
<li>The RTP header extensions <bcp14>MUST</bcp14> only include those
that
are present in the most recent answer.</li> are present in the most recent answer.</li>
<li>The RTCP feedback mechanisms MUST only include those <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 present in the most recent answer, except for the
case of format-specific mechanisms that are referencing a case of format-specific mechanisms that are referencing a
newly-added media format.</li> newly-added media format.</li>
<li>The "a=rtcp" line MUST NOT be added if the most recent <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 MUST 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 MUST NOT be added.</li> <li>The "a=rtcp-mux-only" line <bcp14>MUST NOT</bcp14> be added.</li
<li>The "a=rtcp-rsize" line MUST NOT 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 MUST NOT be added, as indicated <li>An "a=bundle-only" line <bcp14>MUST NOT</bcp14> be added, as ind icated
in in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="6"/>. Instead,
t"/>, JSEP implementations <bcp14>MUST</bcp14> simply omit
Section 6. Instead, JSEP implementations MUST simply omit
parameters in the IDENTICAL and TRANSPORT categories for parameters in the IDENTICAL and TRANSPORT categories for
bundled m= sections, as described in bundled m= sections, as described in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="8.1"/>.</li>
t"/>,
Section 8.1.</li>
<li>Note that if media m= sections are bundled into a data <li>Note that if media m= sections are bundled into a data
m= section, then certain TRANSPORT and IDENTICAL attributes m= section, then certain TRANSPORT and IDENTICAL attributes
may appear in the data m= section even if they would may 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"). This cannot happen in initial offers because "a=rtcp-mux"). This cannot happen in initial offers because
in the initial offer JSEP implementations always list media in the initial offer JSEP implementations always list media
m= sections (if any) before the data m= section (if any), m= sections (if any) before the data m= section (if any),
and at least one of those media m= sections will not have and at least one of those media m= sections will not have
the "a=bundle-only" attribute. Therefore, in initial the "a=bundle-only" attribute. Therefore, in initial
offers, any "a=bundle-only" m= sections will be bundled offers, any "a=bundle-only" m= sections will be bundled
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 MUST 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 must contain all m= other words, the bundle attribute must 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>"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
MUST continue to exist and MUST 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
synchronized in the new offer.</t> synchronized in the new offer.</t>
</section> </section>
<section anchor="sec.options-handling1" numbered="true" toc="default"> <section anchor="sec.options-handling1" numbered="true" toc="default">
<name>Options Handling</name> <name>Options Handling</name>
<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 a SDP description if the following options are generating a 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 MUST 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="3.4.1.1.1"/>.
Section 3.4.1.1.1. If this 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 MUST indicate support 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" format="default"/>, 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 MUST be specified to indicate that silence that codec <bcp14>MUST</bcp14> be specified to indicate that silence
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 MUST NOT 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 MUST be specified to indicate parameters for that codec <bcp14>MUST</bcp14> be specified to indica te
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 MUST NOT use silence suppression for media 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" format="default"/>, 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 must be <t>When createAnswer is called, a new SDP description must be
created that is compatible with the supplied remote description created that is compatible with the supplied remote description
as well as the requirements specified in as well as the requirements specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>. The exact <xref target="RFCYYY5" format="default"/>. The exact
details of this process are explained below.</t> details of this process are explained below.</t>
<section anchor="sec.initial-answers" numbered="true" toc="default"> <section anchor="sec.initial-answers" numbered="true" toc="default">
<name>Initial Answers</name> <name>Initial Answers</name>
<t>When createAnswer is called for the first time after a <t>When createAnswer is called for the first time after a
remote description has been provided, the result is known as remote description has been provided, the result is known as
the initial answer. If no remote description has been the initial answer. If no remote description has been
installed, an answer cannot be generated, and an error MUST installed, an answer cannot be generated, and an error <bcp14>MUST</bc p14>
be returned.</t> be returned.</t>
<t>Note that the remote description SDP may not have been <t>Note that the remote description SDP may not have been
created by a JSEP endpoint and may not conform to all the created by a JSEP endpoint and may not conform to all the
requirements listed in requirements listed in
<xref target="sec-create-offer" format="default"/>. For many cases, th is <xref target="sec-create-offer" format="default"/>. For many cases, th is
is not a problem. However, if any mandatory SDP attributes is not a problem. However, if any mandatory SDP attributes
are missing, or functionality listed as mandatory-to-use are missing, or functionality listed as mandatory-to-use
above is not present, this MUST be treated as an error, and above is not present, this <bcp14>MUST</bcp14> be treated as an error,
MUST cause the affected m= sections to be marked as and
<bcp14>MUST</bcp14> cause the affected m= sections to be marked as
rejected.</t> rejected.</t>
<t>The first step in generating an initial answer is to <t>The first step in generating an initial answer is to
generate session-level attributes. The process here is generate session-level attributes. The process here is
identical to that indicated in the initial offers section identical to that indicated in the initial offers section
above, except that the "a=ice-options" line, with the above, except that the "a=ice-options" line, with the
"trickle" option as specified in "trickle" option as specified in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 3, <xref target="RFCYYY6" sectionFormat="comma" section="3"/>,
and the "ice2" option as specified in and the "ice2" option as specified in
<xref target="RFC8445" format="default"/>, Section 10, is <xref target="RFC8445" sectionFormat="comma" section="10"/>, is
only included if such an option was present in the offer.</t> only included if such an option was present in the offer.</t>
<t>The next step is to generate session-level lip sync <t>The next step is to generate session-level lip sync
groups, as defined in groups, as defined in
<xref target="RFC5888" format="default"/>, Section 7. For each group o f type <xref target="RFC5888" sectionFormat="comma" section="7"/>. For each g roup of type
"LS" present in the offer, select the local RtpTransceivers "LS" present in the offer, select the local RtpTransceivers
that are referenced by the MID values in the specified group, that are referenced by the MID values in the specified group,
and determine which of them either reference a common local and determine which of them either reference a common local
MediaStream (specified in the calls to MediaStream (specified in the calls to
addTrack/addTransceiver used to create them), or have no addTrack/addTransceiver used to create them), or have no
MediaStream to reference because they were not created by MediaStream to reference because they were not created by
addTrack/addTransceiver. If at least two such RtpTransceivers addTrack/addTransceiver. If at least two such RtpTransceivers
exist, a group of type "LS" with the mid values of these exist, a group of type "LS" with the mid values of these
RtpTransceivers MUST be added. Otherwise the offered "LS" RtpTransceivers <bcp14>MUST</bcp14> be added. Otherwise the offered "L
group MUST be ignored and no corresponding group generated in S"
group <bcp14>MUST</bcp14> be ignored and no corresponding group genera
ted in
the answer.</t> the answer.</t>
<t>As a simple example, consider the following offer of a <t>As a simple example, consider the following offer of a
single audio and single video track contained in the same single audio and single video track contained in the same
MediaStream. SDP lines not relevant to this example have been MediaStream. SDP lines not relevant to this example have been
removed for clarity. As explained in removed for clarity. As explained in
<xref target="sec-create-offer" format="default"/>, a group of type "L S" has <xref target="sec-create-offer" format="default"/>, a group of type "L S" has
been added that references each track's RtpTransceiver.</t> been added that references each track's RtpTransceiver.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="sdp"><![CDATA[
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10000 UDP/TLS/RTP/SAVPF 0 m=audio 10000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=msid:ms1 a=msid:ms1
m=video 10001 UDP/TLS/RTP/SAVPF 96 m=video 10001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms1 a=msid:ms1 ]]></sourcecode>
]]></artwork>
<t>If the answerer uses a single MediaStream when it adds its <t>If the answerer uses a single MediaStream when it adds its
tracks, both of its transceivers will reference this stream, tracks, both of its transceivers will reference this stream,
and so the subsequent answer will contain a "LS" group and so the subsequent answer will contain a "LS" group
identical to that in the offer, as shown below:</t> identical to that in the offer, as shown below:</t>
<artwork name="" type="" align="left" alt=""><![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=msid:ms2 a=msid:ms2
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms2 a=msid:ms2 ]]></sourcecode>
]]></artwork>
<t>However, if the answerer groups its tracks into separate <t>However, if the answerer groups its tracks into separate
MediaStreams, its transceivers will reference different MediaStreams, its transceivers will reference different
streams, and so the subsequent answer will not contain a "LS" streams, and so the subsequent answer will not contain a "LS"
group.</t> group.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="sdp"><![CDATA[
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=msid:ms2a a=msid:ms2a
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=msid:ms2b a=msid:ms2b ]]></sourcecode>
]]></artwork>
<t>Finally, if the answerer does not add any tracks, its <t>Finally, if the answerer does not add any tracks, its
transceivers will not reference any MediaStreams, causing the transceivers will not reference any MediaStreams, causing the
preferences of the offerer to be maintained, and so the preferences of the offerer to be maintained, and so the
subsequent answer will contain an identical "LS" group.</t> subsequent answer will contain an identical "LS" group.</t>
<artwork name="" type="" align="left" alt=""><![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 a=recvonly ]]></sourcecode>
]]></artwork>
<t>The <t>The
<xref target="sec.detailed-example" format="default"/> example later i n this <xref target="sec.detailed-example" format="default"/> example later i n this
document shows a more involved case of "LS" group document shows a more involved case of "LS" group
generation.</t> generation.</t>
<t>The next step is to generate m= sections for each m= <t>The next step is to generate m= sections 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" format="default"/>, Section 6. For the purposes <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>
<t>For each offered m= section, if any of the following <t>For each offered m= section, if any of the following
conditions are true, the corresponding m= section in the conditions are true, the corresponding m= section in the
answer MUST be marked as rejected by setting the port in the answer <bcp14>MUST</bcp14> be marked as rejected by setting the port i n the
m= line to zero, as indicated in m= line to zero, as indicated in
<xref target="RFC3264" format="default"/>, Section 6, and further <xref target="RFC3264" sectionFormat="comma" section="6"/>, and furthe r
processing for this m= section can be skipped: processing for this m= section can be skipped:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The associated RtpTransceiver has been stopped.</li> <li>The associated RtpTransceiver has been stopped.</li>
<li>None of the offered media formats are supported and, if <li>None of the offered media formats are supported and, if
applicable, allowed by codec preferences.</li> applicable, allowed by codec preferences.</li>
<li>The bundle policy is "max-bundle", and this is not the <li>The bundle policy is "max-bundle", and this is not the
first m= section or in the same bundle group as the first first m= section or in the same bundle group as the first
m= section.</li> m= section.</li>
<li>The bundle policy is "balanced", and this is not the <li>The bundle policy is "balanced", and this is not the
first m= section for this media type or in the same bundle first m= section for this media type or in the same bundle
group as the first m= section for this media type.</li> group as the first m= section for this media type.</li>
<li>This m= section is in a bundle group, and the group's <li>This m= section is in a bundle group, and the group's
offerer tagged m= section is being rejected due to one of offerer tagged m= section is being rejected due to one of
the above reasons. This requires all m= sections in the the above reasons. This requires all m= sections in the
bundle group to be rejected, as specified in bundle group to be rejected, as specified in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="7.3.3"/>.</li>
t"/>,
Section 7.3.3.</li>
</ul> </ul>
<t>Otherwise, each m= section in the answer should then be <t>Otherwise, each m= section in the answer should then be
generated as specified in generated as specified in
<xref target="RFC3264" format="default"/>, Section 6.1. For the m= lin e <xref target="RFC3264" sectionFormat="comma" section="6.1"/>. For the m= line
itself, the following rules must be followed: itself, the following rules must be followed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The port value would normally be set to the port of the <li>The port value would normally be set to the port of the
default ICE candidate for this m= section, but given that default ICE candidate for this m= section, but given that
no candidates are available yet, the "dummy" port value of no candidates are available yet, the "dummy" port value of
9 (Discard) MUST be used, as indicated in 9 (Discard) <bcp14>MUST</bcp14> be used, as indicated in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section <xref target="RFCYYY6" sectionFormat="comma" section="5.1"/>.</li>
5.1.</li> <li>The &lt;proto&gt; field <bcp14>MUST</bcp14> be set to exactly ma
<li>The &lt;proto&gt; field MUST be set to exactly match the tch the
&lt;proto&gt; field for the corresponding m= line in the &lt;proto&gt; field for the corresponding m= line in the
offer.</li> offer.</li>
<li>If codec preferences have been set for the associated <li>If codec preferences have been set for the associated
transceiver, media formats MUST be generated in the transceiver, media formats <bcp14>MUST</bcp14> be generated in the
corresponding order, regardless of what was offered, and corresponding order, regardless of what was offered, and
MUST exclude any codecs not present in the codec <bcp14>MUST</bcp14> exclude any codecs not present in the codec
preferences.</li> preferences.</li>
<li>Otherwise, the media formats on the m= line MUST be <li>Otherwise, the media formats on the m= line <bcp14>MUST</bcp14> be
generated in the same order as those offered in the current generated in the same order as those offered in the current
remote description, excluding any currently unsupported remote description, excluding any currently unsupported
formats. Any currently available media formats that are not formats. Any currently available media formats that are not
present in the current remote description MUST be added present in the current remote description <bcp14>MUST</bcp14> be add ed
after all existing formats.</li> after all existing formats.</li>
<li>In either case, the media formats in the answer MUST <li>In either case, the media formats in the answer <bcp14>MUST</bcp 14>
include at least one format that is present in the offer, include at least one format that is present in the offer,
but MAY include formats that are locally supported but not but <bcp14>MAY</bcp14> include formats that are locally supported bu t not
present in the offer, as mentioned in present in the offer, as mentioned in
<xref target="RFC3264" format="default"/>, Section 6.1. If no common format <xref target="RFC3264" sectionFormat="comma" section="6.1"/>. If no common format
exists, the m= section is rejected as described above.</li> exists, the m= section is rejected as described above.</li>
</ul> </ul>
<t>The m= line MUST be followed immediately by a "c=" line, <t>The m= line <bcp14>MUST</bcp14> be followed immediately by a "c=" l ine,
as specified in as specified in
<xref target="RFC4566" format="default"/>, Section 5.7. Again, as no <xref target="RFC4566" sectionFormat="comma" section="5.7"/>. Again, a s no
candidates are available yet, the "c=" line must contain the candidates are available yet, the "c=" line must contain the
"dummy" value "IN IP4 0.0.0.0", as defined in "dummy" value "IN IP4 0.0.0.0", as defined in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 5.1.</ t> <xref target="RFCYYY6" sectionFormat="comma" section="5.1"/>.</t>
<t>If the offer supports bundle, all m= sections to be <t>If the offer supports bundle, all m= sections to be
bundled must use the same ICE credentials and candidates; all bundled must use the same ICE credentials and candidates; all
m= sections not being bundled must use unique ICE credentials m= sections not being bundled must use unique ICE credentials
and candidates. Each m= section MUST contain the following and candidates. Each m= section <bcp14>MUST</bcp14> contain the follow ing
attributes (which are of attribute types other than IDENTICAL attributes (which are of attribute types other than IDENTICAL
and TRANSPORT): and TRANSPORT):
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If and only if present in the offer, an "a=mid" line, as <li>If and only if present in the offer, an "a=mid" line, as
specified in specified in
<xref target="RFC5888" format="default"/>, Section 9.1. The "mid" <xref target="RFC5888" sectionFormat="comma" section="9.1"/>. The "m
value MUST match that specified in the offer.</li> id"
value <bcp14>MUST</bcp14> match that specified in the offer.</li>
<li>A direction attribute, determined by applying the rules <li>A direction attribute, determined by applying the rules
regarding the offered direction specified in regarding the offered direction specified in
<xref target="RFC3264" format="default"/>, Section 6.1, and then <xref target="RFC3264" sectionFormat="comma" section="6.1"/>, and th en
intersecting with the direction of the associated intersecting with the direction of the associated
RtpTransceiver. For example, in the case where an m= RtpTransceiver. For example, in the case where an m=
section is offered as "sendonly", and the local transceiver section is offered as "sendonly", and the local transceiver
is set to "sendrecv", the result in the answer is a is set to "sendrecv", the result in the answer is a
"recvonly" direction.</li> "recvonly" direction.</li>
<li>For each media format on the m= line, "a=rtpmap" and <li>For each media format on the m= line, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" format="default"/>, Section 6, and <xref target="RFC4566" sectionFormat="comma" section="6"/>, and
<xref target="RFC3264" format="default"/>, 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" format="default"/>, 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 supported FEC mechanism, "a=rtpmap" and
"a=fmtp" lines, as specified in "a=fmtp" lines, as specified in
<xref target="RFC4566" format="default"/>, Section 6. The FEC <xref target="RFC4566" sectionFormat="comma" section="6"/>. The FEC
mechanisms that MUST be supported are specified in mechanisms that <bcp14>MUST</bcp14> be supported are specified in
<xref target="I-D.ietf-rtcweb-fec" format="default"/>, Section 6, an <xref target="RFCYYYF" sectionFormat="comma" section="6"/>, and
d
specific usage for each media type is outlined in Sections specific usage for each media type is outlined in Sections
4 and 5.</li> <xref target="sec.interface" format="counter"/> and <xref
target="sec.sdp-interaction-procedure" format="counter"/>.</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 which can be known limitations on the size of images which 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 supported RTP header extension that is present
in the offer, an "a=extmap" line, as specified in in the offer, an "a=extmap" line, as specified in
<xref target="RFC5285" format="default"/>, Section 5. The list of <xref target="RFC5285" sectionFormat="comma" section="5"/>. The list
header extensions that SHOULD/MUST be supported is of
header extensions that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> be
supported is
specified in specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>, Section <xref target="RFCYYY5" sectionFormat="comma" section="5.2"/>. Any he
5.2. Any header extensions that require encryption MUST be ader extensions that require encryption <bcp14>MUST</bcp14> be
specified as indicated in specified as indicated in
<xref target="RFC6904" format="default"/>, Section 4.</li> <xref target="RFC6904" sectionFormat="comma" section="4"/>.</li>
<li>For each supported RTCP feedback mechanism that is <li>For each supported RTCP feedback mechanism that is
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" format="default"/>, Section 4.2. The list of <xref target="RFC4585" sectionFormat="comma" section="4.2"/>. The li
RTCP feedback mechanisms that SHOULD/MUST be supported is st of
RTCP feedback mechanisms that <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp
14> be supported is
specified in specified in
<xref target="I-D.ietf-rtcweb-rtp-usage" format="default"/>, Section <xref target="RFCYYY5" sectionFormat="comma" section="5.1"/>.</li>
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="I-D.ietf-mmusic-msid" format="default"/>, Section 2, <xref target="RFCYYY4" sectionFormat="comma" section="2"/>,
but omitting the "appdata" field.</li> but omitting the "appdata" field.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Each m= section which is not bundled into another m= <t>Each m= section which is not bundled into another m=
section, MUST contain the following attributes (which are of section, <bcp14>MUST</bcp14> contain the following attributes (which a re of
category IDENTICAL or TRANSPORT):</t> category IDENTICAL or TRANSPORT):</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"a=ice-ufrag" and "a=ice-pwd" lines, as specified in <li>"a=ice-ufrag" and "a=ice-pwd" lines, as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>.</li>
Section 4.4.</li>
<li>For each desired digest algorithm, one or more <li>For each desired digest algorithm, one or more
"a=fingerprint" lines for each of the endpoint's "a=fingerprint" lines for each of the endpoint's
certificates, as specified in certificates, as specified in
<xref target="RFC8122" format="default"/>, Section 5.</li> <xref target="RFC8122" sectionFormat="comma" section="5"/>.</li>
<li>An "a=setup" line, as specified in <li>An "a=setup" line, as specified in
<xref target="RFC4145" format="default"/>, Section 4, and clarifie d <xref target="RFC4145" sectionFormat="comma" section="4"/>, and cl arified
for use in DTLS-SRTP scenarios in for use in DTLS-SRTP scenarios in
<xref target="RFC5763" format="default"/>, Section 5. The role val <xref target="RFC5763" sectionFormat="comma" section="5"/>. The ro
ue le value
in the answer MUST be "active" or "passive". When the in the answer <bcp14>MUST</bcp14> be "active" or "passive". When t
he
offer contains the "actpass" value, as will always be the offer contains the "actpass" value, as will always be the
case with JSEP endpoints, the answerer SHOULD use the case with JSEP endpoints, the answerer <bcp14>SHOULD</bcp14> use t
"active" role. Offers from non-JSEP endpoints MAY send he
other values for "a=setup", in which case the answer MUST "active" role. Offers from non-JSEP endpoints <bcp14>MAY</bcp14> s
end
other values for "a=setup", in which case the answer <bcp14>MUST</
bcp14>
use a value consistent with the value in the offer.</li> use a value consistent with the value in the offer.</li>
<li>An "a=tls-id" line, as specified in <li>An "a=tls-id" line, as specified in
<xref target="I-D.ietf-mmusic-dtls-sdp" format="default"/>, Sectio <xref target="RFCYYYA" sectionFormat="comma" section="5.3"/>.</li>
n
5.3.</li>
<li>If present in the offer, an "a=rtcp-mux" line, as <li>If present in the offer, an "a=rtcp-mux" line, as
specified in specified in
<xref target="RFC5761" format="default"/>, Section 5.1.3. Otherwis e, <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>. Ot herwise,
an "a=rtcp" line, as specified in an "a=rtcp" line, as specified in
<xref target="RFC3605" format="default"/>, Section 2.1, containing <xref target="RFC3605" sectionFormat="comma" section="2.1"/>, cont aining
the dummy value "9 IN IP4 0.0.0.0" (because no candidates the dummy value "9 IN IP4 0.0.0.0" (because no candidates
have yet been gathered).</li> have yet been gathered).</li>
<li>If present in the offer, an "a=rtcp-rsize" line, as <li>If present in the offer, an "a=rtcp-rsize" line, as
specified in specified in
<xref target="RFC5506" format="default"/>, Section 5.</li> <xref target="RFC5506" sectionFormat="comma" section="5"/>.</li>
</ul> </ul>
<t>If a data channel m= section has been offered, a m= <t>If a data channel m= section has been offered, a m=
section MUST also be generated for data. The &lt;media&gt; section <bcp14>MUST</bcp14> also be generated for data. The &lt;media&
field MUST be set to "application" and the &lt;proto&gt; and gt;
&lt;fmt&gt; fields MUST be set to exactly match the fields in field <bcp14>MUST</bcp14> be set to "application" and the &lt;proto&gt
; and
&lt;fmt&gt; fields <bcp14>MUST</bcp14> be set to exactly match the fie
lds in
the offer.</t> the offer.</t>
<t>Within the data m= section, an "a=mid" line MUST be <t>Within the data m= section, an "a=mid" line <bcp14>MUST</bcp14> be
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="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section 5. 1, <xref target="RFCYYY9" 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="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section <xref target="RFCYYY9" sectionFormat="comma" section="6.1"/>.</t>
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=
section is not bundled into another m= section: section is not bundled into another m= section:
</t> </t>
<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>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 of "BUNDLE" are
offered, corresponding session-level "a=group" attributes offered, corresponding session-level "a=group" attributes
MUST be added as specified in <bcp14>MUST</bcp14> be added as specified in
<xref target="RFC5888" format="default"/>. These attributes MUST have <xref target="RFC5888" format="default"/>. These attributes <bcp14>MUS
semantics "BUNDLE", and MUST include the all mid identifiers T</bcp14> have
semantics "BUNDLE", and <bcp14>MUST</bcp14> include the all mid identi
fiers
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, no m= sections in the answer should have an the offer, no m= sections in the answer should have an
"a=bundle-only" line.</t> "a=bundle-only" line.</t>
<t>Attributes that are common between all m= sections MAY be <t>Attributes that are common between all m= sections <bcp14>MAY</bcp1 4> be
moved to session-level, if explicitly defined to be valid at moved to session-level, if explicitly defined to be valid at
session-level.</t> 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>
<section anchor="sec.subsequent-answers" numbered="true" toc="default"> <section anchor="sec.subsequent-answers" numbered="true" toc="default">
<name>Subsequent Answers</name> <name>Subsequent Answers</name>
<t>When createAnswer is called a second (or later) time, or <t>When createAnswer is called a second (or later) time, or
is called after a local description has already been is called after a local description has already been
installed, the processing is somewhat different than for an installed, the processing is somewhat different than for an
initial answer.</t> initial answer.</t>
<t>If the previous answer was not applied using <t>If the previous answer was not applied using
setLocalDescription, meaning the PeerConnection is still in setLocalDescription, meaning the PeerConnection is still in
the "have-remote-offer" state, the steps for generating an the "have-remote-offer" state, the steps for generating an
initial answer should be followed, subject to the following initial answer should be followed, subject to the following
restriction: restriction:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The fields of the "o=" line MUST stay the same except <li>The fields of the "o=" line <bcp14>MUST</bcp14> stay the same ex
for the &lt;session-version&gt; field, which MUST increment cept
for the &lt;session-version&gt; field, which <bcp14>MUST</bcp14> inc
rement
if the session description changes in any way from the if the session description changes in any way from the
previously generated answer.</li> previously generated answer.</li>
</ul> </ul>
<t>If any session description was previously supplied to <t>If any session description was previously supplied to
setLocalDescription, an answer is generated by following the setLocalDescription, an answer is generated by following the
steps in the "have-remote-offer" state above, along with steps in the "have-remote-offer" state above, along with
these exceptions: these exceptions:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The "s=" and "t=" lines MUST stay the same.</li> <li>The "s=" and "t=" lines <bcp14>MUST</bcp14> stay the same.</li>
<li>Each "m=" and c=" line MUST be filled in with the port <li>Each "m=" and c=" line <bcp14>MUST</bcp14> be filled in with the
port
and address of the default candidate for the m= section, as and address of the default candidate for the m= section, as
described in described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="3.2.1.2"/>. No
Section 3.2.1.2. Note that in certain cases, the m= line protocol te that in certain cases, the m= line protocol
may not match that of the default candidate, because the m= line may not match that of the default candidate, because the m= line
protocol value MUST match what was supplied in the offer, as protocol value <bcp14>MUST</bcp14> match what was supplied in the of fer, as
described above.</li> described above.</li>
<li>Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the <li>Each "a=ice-ufrag" and "a=ice-pwd" line <bcp14>MUST</bcp14> stay the
same, unless the m= section is restarting, in which case same, unless the m= section is restarting, in which case
new ICE credentials must be created as specified in new ICE credentials must be created as specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="3.4.1.1.1"/>.
Section 3.4.1.1.1. If the m= If the m=
section is bundled into another m= section, it still MUST section is bundled into another m= section, it still <bcp14>MUST
NOT contain any ICE credentials.</li> NOT</bcp14> contain any ICE credentials.</li>
<li>Each "a=tls-id" line MUST stay the same unless the <li>Each "a=tls-id" line <bcp14>MUST</bcp14> stay the same unless th
e
offerer's "a=tls-id" line changed, in which case a new offerer's "a=tls-id" line changed, in which case a new
"a=tls-id" value MUST be created, as described in "a=tls-id" value <bcp14>MUST</bcp14> be created, as described in
<xref target="I-D.ietf-mmusic-dtls-sdp" format="default"/>, Section <xref target="RFCYYYA" sectionFormat="comma" section="5.2"/>.</li>
5.2.</li> <li>Each "a=setup" line <bcp14>MUST</bcp14> use an "active" or "pass
<li>Each "a=setup" line MUST use an "active" or "passive" ive"
role value consistent with the existing DTLS association, role value consistent with the existing DTLS association,
if the association is being continued by the offerer.</li> if the association is being continued by the offerer.</li>
<li>RTCP multiplexing must be used, and an "a=rtcp-mux" line <li>RTCP multiplexing must be used, and an "a=rtcp-mux" line
inserted if and only if the m= section previously used RTCP inserted if and only if the m= section previously used RTCP
multiplexing.</li> multiplexing.</li>
<li>If the m= section is not bundled into another m= section <li>If the m= section is not bundled into another m= section
and RTCP multiplexing is not active, an "a=rtcp" attribute and RTCP multiplexing is not active, an "a=rtcp" attribute
line MUST be filled in with the port and address of the line <bcp14>MUST</bcp14> be filled in with the port and address of t he
default RTCP candidate. If no RTCP candidates have yet been default RTCP candidate. If no RTCP candidates have yet been
gathered, dummy values MUST be used, as described in the gathered, dummy values <bcp14>MUST</bcp14> be used, as described in the
initial answer section above.</li> initial answer section above.</li>
<li>If the m= section is not bundled into another m= <li>If the m= section is not bundled into another m=
section, for each candidate that has been gathered during section, for each candidate that has been gathered during
the most recent gathering phase (see the most recent gathering phase (see
<xref target="sec.ice-gather-overview" format="default"/>), an <xref target="sec.ice-gather-overview" format="default"/>), an
"a=candidate" line MUST be added, as defined in "a=candidate" line <bcp14>MUST</bcp14> be added, as defined in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.1"/>.
Section 4.1.
If candidate gathering for the section has completed, an If candidate gathering for the section has completed, an
"a=end-of-candidates" attribute MUST be added, as described "a=end-of-candidates" attribute <bcp14>MUST</bcp14> be added, as des cribed
in in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 9.3. <xref target="RFCYYY6" sectionFormat="comma" section="9.3"/>.
If the m= section is bundled into another m= section, both If the m= section is bundled into another m= section, both
"a=candidate" and "a=end-of-candidates" MUST be "a=candidate" and "a=end-of-candidates" <bcp14>MUST</bcp14> be
omitted.</li> omitted.</li>
<li>For RtpTransceivers that are not stopped, the "a=msid" <li>For RtpTransceivers that are not stopped, the "a=msid"
line(s) MUST stay the same, regardless of changes to the line(s) <bcp14>MUST</bcp14> stay the same, regardless of changes to the
transceiver's direction or track. If no "a=msid" line is transceiver's direction or track. If no "a=msid" line is
present in the current description, "a=msid" line(s) MUST present in the current description, "a=msid" line(s) <bcp14>MUST</bc p14>
be generated according to the same rules as for an initial be generated according to the same rules as for an initial
answer.</li> answer.</li>
</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
skipping to change at line 2762 skipping to change at line 2721
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 MUST NOT <t>The SDP returned from createOffer or createAnswer <bcp14>MUST NOT</bc p14>
be changed before passing it to setLocalDescription. If precise be changed before passing it to setLocalDescription. If precise
control over the SDP is needed, the aforementioned control over the SDP is needed, the aforementioned
createOffer/createAnswer options or RtpTransceiver APIs MUST be createOffer/createAnswer options or RtpTransceiver APIs <bcp14>MUST</bcp 14> be
used.</t> used.</t>
<t>After calling setLocalDescription with an offer or answer, <t>After calling setLocalDescription with an offer or answer,
the application MAY modify the SDP to reduce its capabilities the application <bcp14>MAY</bcp14> modify the SDP to reduce its capabili ties
before sending it to the far side, as long as it follows the before sending it to the far side, as long as it follows the
rules above that define a valid JSEP offer or answer. Likewise, rules above that define a valid JSEP offer or answer. Likewise,
an application that has received an offer or answer from a peer an application that has received an offer or answer from a peer
MAY modify the received SDP, subject to the same constraints, <bcp14>MAY</bcp14> modify the received SDP, subject to the same constrai nts,
before calling setRemoteDescription.</t> before calling setRemoteDescription.</t>
<t>As always, the application is solely responsible for what it <t>As always, the application is solely responsible for what it
sends to the other party, and all incoming SDP will be sends to the other party, and all incoming SDP will be
processed by the JSEP implementation to the extent of its processed by the JSEP implementation to the extent of its
capabilities. It is an error to assume that all SDP is capabilities. It is an error to assume that all SDP is
well-formed; however, one should be able to assume that any well-formed; however, one should be able to assume that any
implementation of this specification will be able to process, implementation of this specification will be able to process,
as a remote offer or answer, unmodified SDP coming from any as a remote offer or answer, unmodified SDP coming from any
other implementation of this specification.</t> other implementation of this specification.</t>
</section> </section>
<section anchor="sec.processing-a-local-desc" numbered="true" toc="default "> <section anchor="sec.processing-a-local-desc" numbered="true" toc="default ">
<name>Processing a Local Description</name> <name>Processing a Local Description</name>
<t>When a SessionDescription is supplied to <t>When a SessionDescription is supplied to
setLocalDescription, the following steps MUST be performed: setLocalDescription, the following steps <bcp14>MUST</bcp14> be performe d:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the description is of type "rollback", follow the <li>If the description is of type "rollback", follow the
processing defined in processing defined in
<xref target="sec.processing-a-rollback" format="default"/> and skip t he <xref target="sec.processing-a-rollback" format="default"/> and skip t he
processing described in the rest of this section.</li> processing described in the rest of this section.</li>
<li> <li>
<t>Otherwise, the type of the SessionDescription is checked <t>Otherwise, the type of the SessionDescription is checked
against the current state of the PeerConnection: against the current state of the PeerConnection:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the type is "offer", the PeerConnection state MUST be <li>If the type is "offer", the PeerConnection state <bcp14>MUST</ bcp14> be
either "stable" or "have-local-offer".</li> either "stable" or "have-local-offer".</li>
<li>If the type is "pranswer" or "answer", the <li>If the type is "pranswer" or "answer", the
PeerConnection state MUST be either "have-remote-offer" or PeerConnection state <bcp14>MUST</bcp14> be either "have-remote-offe r" or
"have-local-pranswer".</li> "have-local-pranswer".</li>
</ul> </ul>
</li> </li>
<li>If the type is not correct for the current state, <li>If the type is not correct for the current state,
processing MUST stop and an error MUST be returned.</li> processing <bcp14>MUST</bcp14> stop and an error <bcp14>MUST</bcp14> b e returned.</li>
<li>The SessionDescription is then checked to ensure that its <li>The SessionDescription is then checked to ensure that its
contents are identical to those generated in the last call to contents are identical to those generated in the last call to
createOffer/createAnswer, and thus have not been altered, as createOffer/createAnswer, and thus have not been altered, as
discussed in discussed in
<xref target="sec.modifying-sdp" format="default"/>; otherwise, proces sing <xref target="sec.modifying-sdp" format="default"/>; otherwise, proces sing
MUST stop and an error MUST be returned.</li> <bcp14>MUST</bcp14> stop and an error <bcp14>MUST</bcp14> be returned. </li>
<li>Next, the SessionDescription is parsed into a data <li>Next, the SessionDescription is parsed into a data
structure, as described in structure, as described in
<xref target="sec.parsing-a-desc" format="default"/> below.</li> <xref target="sec.parsing-a-desc" format="default"/> below.</li>
<li>Finally, the parsed SessionDescription is applied as <li>Finally, the parsed SessionDescription is applied as
described in described in
<xref target="sec.applying-a-local-desc" format="default"/> below.</li > <xref target="sec.applying-a-local-desc" format="default"/> below.</li >
</ul> </ul>
</section> </section>
<section anchor="sec.processing-a-remote-desc" numbered="true" toc="defaul t"> <section anchor="sec.processing-a-remote-desc" numbered="true" toc="defaul t">
<name>Processing a Remote Description</name> <name>Processing a Remote Description</name>
<t>When a SessionDescription is supplied to <t>When a SessionDescription is supplied to
setRemoteDescription, the following steps MUST be performed: setRemoteDescription, the following steps <bcp14>MUST</bcp14> be perform ed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the description is of type "rollback", follow the <li>If the description is of type "rollback", follow the
processing defined in processing defined in
<xref target="sec.processing-a-rollback" format="default"/> and skip t he <xref target="sec.processing-a-rollback" format="default"/> and skip t he
processing described in the rest of this section.</li> processing described in the rest of this section.</li>
<li> <li>
<t>Otherwise, the type of the SessionDescription is checked <t>Otherwise, the type of the SessionDescription is checked
against the current state of the PeerConnection: against the current state of the PeerConnection:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the type is "offer", the PeerConnection state MUST be <li>If the type is "offer", the PeerConnection state <bcp14>MUST</ bcp14> be
either "stable" or "have-remote-offer".</li> either "stable" or "have-remote-offer".</li>
<li>If the type is "pranswer" or "answer", the <li>If the type is "pranswer" or "answer", the
PeerConnection state MUST be either "have-local-offer" or PeerConnection state <bcp14>MUST</bcp14> be either "have-local-offer " or
"have-remote-pranswer".</li> "have-remote-pranswer".</li>
</ul> </ul>
</li> </li>
<li>If the type is not correct for the current state, <li>If the type is not correct for the current state,
processing MUST stop and an error MUST be returned.</li> processing <bcp14>MUST</bcp14> stop and an error <bcp14>MUST</bcp14> b e returned.</li>
<li>Next, the SessionDescription is parsed into a data <li>Next, the SessionDescription is parsed into a data
structure, as described in structure, as described in
<xref target="sec.parsing-a-desc" format="default"/> below. If parsing fails <xref target="sec.parsing-a-desc" format="default"/> below. If parsing fails
for any reason, processing MUST stop and an error MUST be for any reason, processing <bcp14>MUST</bcp14> stop and an error <bcp1 4>MUST</bcp14> be
returned.</li> returned.</li>
<li>Finally, the parsed SessionDescription is applied as <li>Finally, the parsed SessionDescription is applied as
described in described in
<xref target="sec.applying-a-remote-desc" format="default"/> below.</l i> <xref target="sec.applying-a-remote-desc" format="default"/> below.</l i>
</ul> </ul>
</section> </section>
<section anchor="sec.processing-a-rollback" numbered="true" toc="default"> <section anchor="sec.processing-a-rollback" numbered="true" toc="default">
<name>Processing a Rollback</name> <name>Processing a Rollback</name>
<t>A rollback may be performed if the PeerConnection is in any <t>A rollback may be performed if the PeerConnection is in any
state except for "stable". This means that both offers and state except for "stable". This means that both offers and
provisional answers can be rolled back. Rollback can only be provisional answers can be rolled back. Rollback can only be
used to cancel proposed changes; there is no support for used to cancel proposed changes; there is no support for
rolling back from a stable state to a previous stable state. If rolling back from a stable state to a previous stable state. If
a rollback is attempted in the "stable" state, processing MUST a rollback is attempted in the "stable" state, processing <bcp14>MUST</b
stop and an error MUST be returned. Note that this implies that cp14>
stop and an error <bcp14>MUST</bcp14> be returned. Note that this implie
s that
once the answerer has performed setLocalDescription with his once the answerer has performed setLocalDescription with his
answer, this cannot be rolled back.</t> answer, this cannot be rolled back.</t>
<t>The effect of rollback MUST 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 description (see Sections
<xref target="sec.pendinglocaldescription" format="default"/> and <xref target="sec.pendinglocaldescription" format="counter"/> and
<xref target="sec.pendingremotedescription" format="default"/>) to null. <xref target="sec.pendingremotedescription" format="counter"/>) to null.
Any 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 rolled-back session description (see Sections
<xref target="sec.applying-a-remote-desc" format="default"/> and <xref target="sec.applying-a-remote-desc" format="counter"/> and
<xref target="sec.applying-a-local-desc" format="default"/>). This means <xref target="sec.applying-a-local-desc" format="counter"/>). This means
that 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 MUST 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 MUST be discarded. RtpTransceivers that were created by index <bcp14>MUST</bcp14> be discarded. RtpTransceivers that were create
applying a remote offer that was subsequently rolled back MUST d by
applying a remote offer that was subsequently rolled back <bcp14>MUST</b
cp14>
be stopped and removed from the PeerConnection. However, a be stopped and removed from the PeerConnection. However, a
RtpTransceiver MUST NOT be removed if a track was attached 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 a m= section for the added track appear in the and have a m= section for the added track appear in the
generated offer.</t> generated offer.</t>
</section> </section>
<section anchor="sec.parsing-a-desc" numbered="true" toc="default"> <section anchor="sec.parsing-a-desc" numbered="true" toc="default">
<name>Parsing a Session Description</name> <name>Parsing a Session Description</name>
<t>The SDP contained in the session description object consists <t>The SDP contained in the session description object consists
of a sequence of text lines, each containing a key-value of a sequence of text lines, each containing a key-value
expression, as described in expression, as described in
<xref target="RFC4566" format="default"/>, Section 5. The SDP is read, <xref target="RFC4566" sectionFormat="comma" section="5"/>. The SDP is r ead,
line-by-line, and converted to a data structure that contains line-by-line, and converted to a data structure that contains
the deserialized information. However, SDP allows many types of the deserialized information. However, SDP allows many types of
lines, not all of which are relevant to JSEP applications. For lines, not all of which are relevant to JSEP applications. For
each line, the implementation will first ensure it is each line, the implementation will first ensure it is
syntactically correct according to its defining ABNF, check syntactically correct according to its defining ABNF, check
that it conforms to that it conforms to
<xref target="RFC4566" format="default"/> and <xref target="RFC4566" format="default"/> and
<xref target="RFC3264" format="default"/> semantics, and then either par se and <xref target="RFC3264" format="default"/> semantics, and then either par se and
store or discard the provided value, as described below.</t> store or discard the provided value, as described below.</t>
<t>If any line is not well-formed, or cannot be parsed as <t>If any line is not well-formed, or cannot be parsed as
described, the parser MUST stop with an error and reject the described, the parser <bcp14>MUST</bcp14> stop with an error and reject the
session description, even if the value is to be discarded. This session description, even if the value is to be discarded. This
ensures that implementations do not accidentally misinterpret ensures that implementations do not accidentally misinterpret
ambiguous SDP.</t> ambiguous SDP.</t>
<section anchor="sec.session-level-parse" numbered="true" toc="default"> <section anchor="sec.session-level-parse" numbered="true" toc="default">
<name>Session-Level Parsing</name> <name>Session-Level Parsing</name>
<t>First, the session-level lines are checked and parsed. <t>First, the session-level lines are checked and parsed.
These lines MUST occur in a specific order, and with a These lines <bcp14>MUST</bcp14> occur in a specific order, and with a
specific syntax, as defined in specific syntax, as defined in
<xref target="RFC4566" format="default"/>, Section 5. Note that while <xref target="RFC4566" sectionFormat="comma" section="5"/>. Note that
the while the
specific line types (e.g. "v=", "c=") MUST occur in the specific line types (e.g. "v=", "c=") <bcp14>MUST</bcp14> occur in the
defined order, lines of the same type (typically "a=") can defined order, lines of the same type (typically "a=") can
occur in any order.</t> occur in any order.</t>
<t>The following non-attribute lines are not meaningful in <t>The following non-attribute lines are not meaningful in
the JSEP context and MAY be discarded once they have been the JSEP context and <bcp14>MAY</bcp14> be discarded once they have be en
checked. checked.
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>The "c=" line MUST be checked for syntax but its value <li>The "c=" line <bcp14>MUST</bcp14> be checked for syntax but its
value
is only used for ICE mismatch detection, as defined in is only used for ICE mismatch detection, as defined in
<xref target="RFC8445" format="default"/>, Section 5.4. Note that JS EP <xref target="RFC8445" sectionFormat="comma" section="5.4"/>. Note t hat JSEP
implementations should never encounter this condition implementations should never encounter this condition
because ICE is required for WebRTC.</li> because ICE is required for WebRTC.</li>
<li>The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" <li>The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k="
lines are not used by this specification; they MUST be lines are not used by this specification; they <bcp14>MUST</bcp14> b e
checked for syntax but their values are not used.</li> checked for syntax but their values are not used.</li>
</ul> </ul>
<t>The remaining non-attribute lines are processed as <t>The remaining non-attribute lines are processed as
follows: follows:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>The "v=" line MUST have a version of 0, as specified in <li>The "v=" line <bcp14>MUST</bcp14> have a version of 0, as specif
<xref target="RFC4566" format="default"/>, Section 5.1.</li> ied in
<li>The "o=" line MUST be parsed as specified in <xref target="RFC4566" sectionFormat="comma" section="5.1"/>.</li>
<xref target="RFC4566" format="default"/>, Section 5.2.</li> <li>The "o=" line <bcp14>MUST</bcp14> be parsed as specified in
<li>The "b=" line, if present, MUST be parsed as specified <xref target="RFC4566" sectionFormat="comma" section="5.2"/>.</li>
<li>The "b=" line, if present, <bcp14>MUST</bcp14> be parsed as spec
ified
in in
<xref target="RFC4566" format="default"/>, Section 5.8, and the bwty pe 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 MUST be applied for the following session-level 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" format="default"/>, 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 mids 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.3"/>, and a
Section 4.3, and a value value
indicating the presence of ice-lite is stored.</li> indicating the presence of ice-lite 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>, and th
Section 4.4, and the ufrag value is stored.</li> 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>, and th
Section 4.4, and the password value is stored.</li> 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.6"/>, and th
Section 4.6, and the set of specified options is stored.</li> 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
<xref target="RFC8122" format="default"/>, Section 5, and the set of <xref target="RFC8122" sectionFormat="comma" section="5"/>, and the set of
fingerprint and algorithm values is stored.</li> fingerprint and algorithm values is stored.</li>
<li>If present, a single "a=setup" line is parsed as <li>If present, a single "a=setup" line is parsed as
specified in specified in
<xref target="RFC4145" format="default"/>, Section 4, and the setup value <xref target="RFC4145" sectionFormat="comma" section="4"/>, and the setup value
is stored.</li> is stored.</li>
<li>If present, a single "a=tls-id" line is parsed as <li>If present, a single "a=tls-id" line is parsed as
specified in specified in <xref target="RFCYYYA" sectionFormat="comma" section="5
<xref target="I-D.ietf-mmusic-dtls-sdp" format="default"/> Section 5 "/>, and
, and
the tls-id value is stored.</li> the tls-id value is stored.</li>
<li>Any "a=identity" lines are parsed and the identity <li>Any "a=identity" lines are parsed and the identity
values stored for subsequent verification, as specified values stored for subsequent verification, as specified
<xref target="I-D.ietf-rtcweb-security-arch" format="default"/>, Sec <xref target="RFCYYY2" sectionFormat="comma" section="5"/>.</li>
tion
5.</li>
<li>Any "a=extmap" lines are parsed as specified in <li>Any "a=extmap" lines are parsed as specified in
<xref target="RFC5285" format="default"/>, Section 5, and their valu es are <xref target="RFC5285" sectionFormat="comma" section="5"/>, and thei r values are
stored.</li> stored.</li>
</ul> </ul>
<t>Other attributes that are not relevant to JSEP may also be <t>Other attributes that are not relevant to JSEP may also be
present, and implementations SHOULD process any that they present, and implementations <bcp14>SHOULD</bcp14> process any that th ey
recognize. As required by recognize. As required by
<xref target="RFC4566" format="default"/>, Section 5.13, unknown <xref target="RFC4566" sectionFormat="comma" section="5.13"/>, unknown
attribute lines MUST be ignored.</t> attribute lines <bcp14>MUST</bcp14> be ignored.</t>
<t>Once all the session-level lines have been parsed, <t>Once all the session-level lines have been parsed,
processing continues with the lines in m= sections.</t> processing continues with the lines in m= sections.</t>
</section> </section>
<section anchor="sec.media-level-parse" numbered="true" toc="default"> <section anchor="sec.media-level-parse" numbered="true" toc="default">
<name>Media Section Parsing</name> <name>Media Section Parsing</name>
<t>Like the session-level lines, the media section lines MUST <t>Like the session-level lines, the media section lines <bcp14>MUST</ bcp14>
occur in the specific order and with the specific syntax occur in the specific order and with the specific syntax
defined in defined in
<xref target="RFC4566" format="default"/>, Section 5.</t> <xref target="RFC4566" sectionFormat="comma" section="5"/>.</t>
<t>The "m=" line itself MUST be parsed as described in <t>The "m=" line itself <bcp14>MUST</bcp14> be parsed as described in
<xref target="RFC4566" format="default"/>, Section 5.14, and the media <xref target="RFC4566" sectionFormat="comma" section="5.14"/>, and the
, port, media, port,
proto, and fmt values stored.</t> proto, and fmt values stored.</t>
<t>Following the "m=" line, specific processing MUST be <t>Following the "m=" line, specific processing <bcp14>MUST</bcp14> be
applied for the following non-attribute lines: applied for the following non-attribute lines:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>As with the "c=" line at the session level, the "c=" <li>As with the "c=" line at the session level, the "c="
line MUST be parsed according to line <bcp14>MUST</bcp14> be parsed according to
<xref target="RFC4566" format="default"/>, Section 5.7, but its valu <xref target="RFC4566" sectionFormat="comma" section="5.7"/>, but it
e is s value is
not used.</li> not used.</li>
<li>The "b=" line, if present, MUST be parsed as specified <li>The "b=" line, if present, <bcp14>MUST</bcp14> be parsed as spec ified
in in
<xref target="RFC4566" format="default"/>, Section 5.8, and the bwty pe 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>Specific processing MUST also be applied for the following <t>Specific processing <bcp14>MUST</bcp14> also be applied for the fol lowing
attribute lines: attribute lines:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>, and th
Section 4.4, and the ufrag value is stored.</li> 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>, and th
Section 4.4, and the password value is stored.</li> 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="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, Secti on 4.6, <xref target="RFCYYY7" sectionFormat="comma" section="4.6"/>,
and the set of specified options is stored.</li> and the set of specified options is stored.</li>
<li>Any "a=candidate" attributes MUST be parsed as specified <li>Any "a=candidate" attributes <bcp14>MUST</bcp14> be parsed as sp ecified
in in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.1"/>, and th
Section 4.1, and their values stored.</li> eir values stored.</li>
<li>Any "a=remote-candidates" attributes MUST be parsed as <li>Any "a=remote-candidates" attributes <bcp14>MUST</bcp14> be pars
ed as
specified in specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="4.2"/>, but th
Section 4.2, but their values are ignored.</li> eir values are ignored.</li>
<li>If present, a single "a=end-of-candidates" attribute <li>If present, a single "a=end-of-candidates" attribute
MUST be parsed as specified in <bcp14>MUST</bcp14> be parsed as specified in
<xref target="I-D.ietf-ice-trickle" format="default"/>, Section 8.2, <xref target="RFCYYY6" sectionFormat="comma" section="8.2"/>, and
and
its presence or absence flagged and stored.</li> its presence or absence flagged and stored.</li>
<li>Any "a=fingerprint" lines are parsed as specified in <li>Any "a=fingerprint" lines are parsed as specified in
<xref target="RFC8122" format="default"/>, Section 5, and the set of <xref target="RFC8122" sectionFormat="comma" section="5"/>, and the set of
fingerprint and algorithm values is stored.</li> fingerprint and algorithm values is stored.</li>
</ul> </ul>
<t>If the "m=" proto value indicates use of RTP, as described <t>If the "m=" proto value indicates use of RTP, as described
in in
<xref target="sec.profile-names" format="default"/> above, the followi ng <xref target="sec.profile-names" format="default"/> above, the followi ng
attribute lines MUST be processed: attribute lines <bcp14>MUST</bcp14> be processed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The "m=" fmt value MUST be parsed as specified in <li>The "m=" fmt value <bcp14>MUST</bcp14> be parsed as specified in
<xref target="RFC4566" format="default"/>, Section 5.14, and the ind <xref target="RFC4566" sectionFormat="comma" section="5.14"/>, and t
ividual he individual
values stored.</li> values stored.</li>
<li>Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as <li>Any "a=rtpmap" or "a=fmtp" lines <bcp14>MUST</bcp14> be parsed a s
specified in specified in
<xref target="RFC4566" format="default"/>, Section 6, and their valu es <xref target="RFC4566" sectionFormat="comma" section="6"/>, and thei r values
stored.</li> stored.</li>
<li>If present, a single "a=ptime" line MUST be parsed as <li>If present, a single "a=ptime" line <bcp14>MUST</bcp14> be parse d as
described in described in
<xref target="RFC4566" format="default"/>, Section 6, and its value <xref target="RFC4566" sectionFormat="comma" section="6"/>, and its value
stored.</li> stored.</li>
<li>If present, a single "a=maxptime" line MUST be parsed as <li>If present, a single "a=maxptime" line <bcp14>MUST</bcp14> be pa rsed as
described in described in
<xref target="RFC4566" format="default"/>, Section 6, and its value <xref target="RFC4566" sectionFormat="comma" section="6"/>, and its value
stored.</li> stored.</li>
<li>If present, a single direction attribute line (e.g. <li>If present, a single direction attribute line (e.g.
"a=sendrecv") MUST be parsed as described in "a=sendrecv") <bcp14>MUST</bcp14> be parsed as described in
<xref target="RFC4566" format="default"/>, Section 6, and its value <xref target="RFC4566" sectionFormat="comma" section="6"/>, and its
value
stored.</li> stored.</li>
<li>Any "a=ssrc" attributes MUST be parsed as specified in <li>Any "a=ssrc" attributes <bcp14>MUST</bcp14> be parsed as specifi
<xref target="RFC5576" format="default"/>, Section 4.1, and their va ed in
lues <xref target="RFC5576" sectionFormat="comma" section="4.1"/>, and th
eir values
stored.</li> stored.</li>
<li>Any "a=extmap" attributes MUST be parsed as specified in <li>Any "a=extmap" attributes <bcp14>MUST</bcp14> be parsed as speci fied in
<xref target="RFC5285" format="default"/>, Section 5, and their valu es <xref target="RFC5285" sectionFormat="comma" section="5"/>, and thei r values
stored.</li> stored.</li>
<li>Any "a=rtcp-fb" attributes MUST be parsed as specified <li>Any "a=rtcp-fb" attributes <bcp14>MUST</bcp14> be parsed as spec ified
in in
<xref target="RFC4585" format="default"/>, Section 4.2., and their v alues <xref target="RFC4585" sectionFormat="comma" section="4.2"/>, and th eir values
stored.</li> stored.</li>
<li>If present, a single "a=rtcp-mux" attribute MUST be <li>If present, a single "a=rtcp-mux" attribute <bcp14>MUST</bcp14> be
parsed as specified in parsed as specified in
<xref target="RFC5761" format="default"/>, Section 5.1.3, and its <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>, and its
presence or absence flagged and stored.</li> presence or absence flagged and stored.</li>
<li>If present, a single "a=rtcp-mux-only" attribute MUST be <li>If present, a single "a=rtcp-mux-only" attribute <bcp14>MUST</bc p14> be
parsed as specified in parsed as specified in
<xref target="I-D.ietf-mmusic-mux-exclusive" format="default"/>, Sec tion 3, <xref target="RFCYYYG" sectionFormat="comma" section="3"/>,
and its presence or absence flagged and stored.</li> and its presence or absence flagged and stored.</li>
<li>If present, a single "a=rtcp-rsize" attribute MUST be <li>If present, a single "a=rtcp-rsize" attribute <bcp14>MUST</bcp14 > be
parsed as specified in parsed as specified in
<xref target="RFC5506" format="default"/>, Section 5, and its presen ce or <xref target="RFC5506" sectionFormat="comma" section="5"/>, and its presence or
absence flagged and stored.</li> absence flagged and stored.</li>
<li>If present, a single "a=rtcp" attribute MUST be parsed <li>If present, a single "a=rtcp" attribute <bcp14>MUST</bcp14> be p arsed
as specified in as specified in
<xref target="RFC3605" format="default"/>, Section 2.1, but its valu e is <xref target="RFC3605" sectionFormat="comma" section="2.1"/>, but it s value is
ignored, as this information is superfluous when using ignored, as this information is superfluous when using
ICE.</li> ICE.</li>
<li>If present, "a=msid" attributes MUST be parsed as <li>If present, "a=msid" attributes <bcp14>MUST</bcp14> be parsed as
specified in specified in
<xref target="I-D.ietf-mmusic-msid" format="default"/>, Section 3.2, and <xref target="RFCYYY4" sectionFormat="comma" section="3.2"/>, and
their values stored, ignoring any "appdata" field. If no "a=msid" their values stored, ignoring any "appdata" field. If no "a=msid"
attributes are present, a random msid-id value is generated for a attributes are present, a random msid-id value is generated for a
"default" MediaStream for the session, if not already present, and "default" MediaStream for the session, if not already present, and
this value is stored.</li> this value is stored.</li>
<li>Any "a=imageattr" attributes MUST be parsed as specified <li>Any "a=imageattr" attributes <bcp14>MUST</bcp14> be parsed as sp ecified
in in
<xref target="RFC6236" format="default"/>, Section 3, and their valu es <xref target="RFC6236" sectionFormat="comma" section="3"/>, and thei r values
stored.</li> stored.</li>
<li>Any "a=rid" lines MUST be parsed as specified in <li>Any "a=rid" lines <bcp14>MUST</bcp14> be parsed as specified in
<xref target="I-D.ietf-mmusic-rid" format="default"/>, Section 10, a <xref target="RFCYYYC" sectionFormat="comma" section="10"/>, and
nd
their values stored.</li> their values stored.</li>
<li>If present, a single "a=simulcast" line MUST be parsed <li>If present, a single "a=simulcast" line <bcp14>MUST</bcp14> be p arsed
as specified in as specified in
<xref target="I-D.ietf-mmusic-sdp-simulcast" format="default"/>, and <xref target="RFCYYYE" format="default"/>, and
its values stored.</li> its values stored.</li>
</ul> </ul>
<t>Otherwise, if the "m=" proto value indicates use of SCTP, <t>Otherwise, if the "m=" proto value indicates use of SCTP,
the following attribute lines MUST be processed: the following attribute lines <bcp14>MUST</bcp14> be processed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The "m=" fmt value MUST be parsed as specified in <li>The "m=" fmt value <bcp14>MUST</bcp14> be parsed as specified in
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section <xref target="RFCYYY9" sectionFormat="comma" section="4.3"/>,
4.3,
and the application protocol value stored.</li> and the application protocol value stored.</li>
<li>An "a=sctp-port" attribute MUST be present, and it MUST <li>An "a=sctp-port" attribute <bcp14>MUST</bcp14> be present, and i t <bcp14>MUST</bcp14>
be parsed as specified in be parsed as specified in
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section 5.2, <xref target="RFCYYY9" sectionFormat="comma" section="5.2"/>,
and the value stored.</li> and the value stored.</li>
<li>If present, a single "a=max-message-size" attribute MUST <li>If present, a single "a=max-message-size" attribute <bcp14>MUST< /bcp14>
be parsed as specified in be parsed as specified in
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section 6, and <xref target="RFCYYY9" sectionFormat="comma" section="6"/>, and
the value stored. Otherwise, use the specified default.</li> the value stored. Otherwise, use the specified default.</li>
</ul> </ul>
<t>Other attributes that are not relevant to JSEP may also be <t>Other attributes that are not relevant to JSEP may also be
present, and implementations SHOULD process any that they present, and implementations <bcp14>SHOULD</bcp14> process any that th ey
recognize. As required by recognize. As required by
<xref target="RFC4566" format="default"/>, Section 5.13, unknown <xref target="RFC4566" sectionFormat="comma" section="5.13"/>, unknown
attribute lines MUST be ignored.</t> attribute lines <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Semantics Verification</name> <name>Semantics Verification</name>
<t>Assuming parsing completes successfully, the parsed <t>Assuming parsing completes successfully, the parsed
description is then evaluated to ensure internal consistency description is then evaluated to ensure internal consistency
as well as proper support for mandatory features. as well as proper support for mandatory features.
Specifically, the following checks are performed: Specifically, the following checks are performed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>For each m= section, valid values for each of the <t>For each m= section, valid values for each of the
mandatory-to-use features enumerated in mandatory-to-use features enumerated in
<xref target="sec.usage-requirements" format="default"/> MUST be pre <xref target="sec.usage-requirements" format="default"/> <bcp14>MUST
sent. </bcp14> be present.
These values MAY either be present at the media level, or These values <bcp14>MAY</bcp14> either be present at the media level
, or
inherited from the session level. inherited from the session level.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>ICE ufrag and password values, which MUST comply with <li>ICE ufrag and password values, which <bcp14>MUST</bcp14> com ply with
the size limits specified in the size limits specified in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, Sec <xref target="RFCYYY7" sectionFormat="comma" section="4.4"/>.</li>
tion 4.4.</li> <li>tls-id value, which <bcp14>MUST</bcp14> be set according to
<li>tls-id value, which MUST be set according to <xref target="RFCYYYA" sectionFormat="comma" section="5"/>. If
<xref target="I-D.ietf-mmusic-dtls-sdp" format="default"/>, Sectio
n 5. If
this is a re-offer or a response to a re-offer and the this is a re-offer or a response to a re-offer and the
tls-id value is different from that presently in use, the tls-id value is different from that presently in use, the
DTLS connection is not being continued and the remote DTLS connection is not being continued and the remote
description MUST be part of an ICE restart, together with description <bcp14>MUST</bcp14> be part of an ICE restart, togethe r with
new ufrag and password values.</li> new ufrag and password values.</li>
<li>DTLS setup value, which MUST be set according to the <li>DTLS setup value, which <bcp14>MUST</bcp14> be set according to the
rules specified in rules specified in
<xref target="RFC5763" format="default"/>, Section 5 and MUST be <xref target="RFC5763" sectionFormat="comma" section="5"/> and <bc p14>MUST</bcp14> be
consistent with the selected role of the current DTLS consistent with the selected role of the current DTLS
connection, if one exists and is being continued.</li> connection, if one exists and is being continued.</li>
<li>DTLS fingerprint values, where at least one <li>DTLS fingerprint values, where at least one
fingerprint MUST be present.</li> fingerprint <bcp14>MUST</bcp14> be present.</li>
</ul> </ul>
</li> </li>
<li>All RID values referenced in an "a=simulcast" line MUST <li>All RID values referenced in an "a=simulcast" line <bcp14>MUST</ bcp14>
exist as "a=rid" lines.</li> exist as "a=rid" lines.</li>
<li>Each m= section is also checked to ensure prohibited <li>Each m= section is also checked to ensure prohibited
features are not used.</li> features are not used.</li>
<li>If the RTP/RTCP multiplexing policy is "require", each <li>If the RTP/RTCP multiplexing policy is "require", each
m= section MUST contain an "a=rtcp-mux" attribute. If an m= m= section <bcp14>MUST</bcp14> contain an "a=rtcp-mux" attribute. If an m=
section contains an "a=rtcp-mux-only" attribute, that section contains an "a=rtcp-mux-only" attribute, that
section MUST also contain an "a=rtcp-mux" attribute.</li> section <bcp14>MUST</bcp14> also contain an "a=rtcp-mux" attribute.< /li>
<li>If an m= section was present in the previous answer, the <li>If an m= section was present in the previous answer, the
state of RTP/RTCP multiplexing MUST match what was state of RTP/RTCP multiplexing <bcp14>MUST</bcp14> match what was
previously negotiated.</li> previously negotiated.</li>
</ul> </ul>
<t>If this session description is of type "pranswer" or <t>If this session description is of type "pranswer" or
"answer", the following additional checks are applied: "answer", the following additional checks are applied:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The session description must follow the rules defined in <li>The session description must follow the rules defined in
<xref target="RFC3264" format="default"/>, Section 6, including the <xref target="RFC3264" sectionFormat="comma" section="6"/>, includin
requirement that the number of m= sections MUST exactly g the
requirement that the number of m= sections <bcp14>MUST</bcp14> exact
ly
match the number of m= sections in the associated match the number of m= sections in the associated
offer.</li> offer.</li>
<li>For each m= section, the media type and protocol values <li>For each m= section, the media type and protocol values
MUST exactly match the media type and protocol values in <bcp14>MUST</bcp14> exactly match the media type and protocol values in
the corresponding m= section in the associated offer.</li> the corresponding m= section in the associated offer.</li>
</ul> </ul>
<t>If any of the preceding checks failed, processing MUST <t>If any of the preceding checks failed, processing <bcp14>MUST</bcp1
stop and an error MUST be returned.</t> 4>
stop and an error <bcp14>MUST</bcp14> be returned.</t>
</section> </section>
</section> </section>
<section anchor="sec.applying-a-local-desc" numbered="true" toc="default"> <section anchor="sec.applying-a-local-desc" numbered="true" toc="default">
<name>Applying a Local Description</name> <name>Applying a Local Description</name>
<t>The following steps are performed at the media engine level <t>The following steps are performed at the media engine level
to apply a local description. If an error is returned, the to apply a local description. If an error is returned, the
session MUST be restored to the state it was in before session <bcp14>MUST</bcp14> be restored to the state it was in before
performing these steps.</t> performing these steps.</t>
<t>First, m= sections are processed. For each m= section, the <t>First, m= sections are processed. For each m= section, the
following steps MUST be performed; if any parameters are out of following steps <bcp14>MUST</bcp14> be performed; if any parameters are
bounds, or cannot be applied, processing MUST stop and an error out of
MUST be returned. bounds, or cannot be applied, processing <bcp14>MUST</bcp14> stop and an
error
<bcp14>MUST</bcp14> be returned.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If this m= section is new, begin gathering candidates for <li>If this m= section is new, begin gathering candidates for
it, as defined in it, as defined in
<xref target="RFC8445" format="default"/>, Section 5.1.1, unless it is <xref target="RFC8445" sectionFormat="comma" section="5.1.1"/>, unless it is
definitively being bundled (either this is an offer and the definitively being bundled (either this is an offer and the
m= section is marked bundle-only, or it is an answer and the m= section is marked bundle-only, or it is an answer and the
m= section is bundled into into another m= section.)</li> m= section is bundled into into another m= section.)</li>
<li>Or, if the ICE ufrag and password values have changed, <li>Or, if the ICE ufrag and password values have changed,
trigger the ICE agent to start an ICE restart as described in trigger the ICE agent to start an ICE restart as described in
<xref target="RFC8445" format="default"/>, Section 9, and begin <xref target="RFC8445" sectionFormat="comma" section="9"/>, and begin
gathering new candidates for the m= section. If this gathering new candidates for the m= section. If this
description is an answer, also start checks on that media description is an answer, also start checks on that media
section.</li> section.</li>
<li> <li>
<t>If the m= section proto value indicates use of RTP: <t>If the m= section proto value indicates use of RTP:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If there is no RtpTransceiver associated with this m= <t>If there is no RtpTransceiver associated with this m=
section, find one and associate it with this m= section section, find one and associate it with this m= section
skipping to change at line 3263 skipping to change at line 3212
<ul spacing="normal"> <ul spacing="normal">
<li>Find the RtpTransceiver that corresponds to this m= <li>Find the RtpTransceiver that corresponds to this m=
section, using the mapping between transceivers and m= section, using the mapping between transceivers and m=
section indices established when creating the offer.</li> section indices established when creating the offer.</li>
<li>Set the value of this RtpTransceiver's mid property to <li>Set the value of this RtpTransceiver's mid property to
the MID of the m= section.</li> the MID of the m= section.</li>
</ul> </ul>
</li> </li>
<li>If RTCP mux is indicated, prepare to demux RTP and RTCP <li>If RTCP mux is indicated, prepare to demux RTP and RTCP
from the RTP ICE component, as specified in from the RTP ICE component, as specified in
<xref target="RFC5761" format="default"/>, Section 5.1.3.</li> <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>.</li>
<li>For each specified RTP header extension, establish a <li>For each specified RTP header extension, establish a
mapping between the extension ID and URI, as described in mapping between the extension ID and URI, as described in
<xref target="RFC5285" format="default"/>, Section 6.</li> <xref target="RFC5285" sectionFormat="comma" section="6"/>.</li>
<li>If the MID header extension is supported, prepare to <li>If the MID header extension is supported, prepare to
demux RTP streams intended for this m= section based on the demux RTP streams intended for this m= section based on the
MID header extension, as described in MID header extension, as described in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="15"/>.</li>
t"/>,
Section 15.</li>
<li>For each specified media format, establish a mapping <li>For each specified media format, establish a mapping
between the payload type and the actual media format, as between the payload type and the actual media format, as
described in described in
<xref target="RFC3264" format="default"/>, Section 6.1. In addition, <xref target="RFC3264" sectionFormat="comma" section="6.1"/>. In add ition,
prepare to demux RTP streams intended for this m= section prepare to demux RTP streams intended for this m= section
based on the media formats supported by this m= section, as based on the media formats supported by this m= section, as
described in described in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="10.2"/>.</li>
t"/>,
Section 10.2.</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" format="default"/>, Sections 8.6 and 8.7.</li > Sections <xref target="RFC4588" section="8.6" sectionFormat="bare"/> and <xref target="RFC4588" section="8.7" sectionFormat="bare"/> of <xref target ="RFC4588"/>.</li>
<li>If the directional attribute is of type "sendrecv" or <li>If the directional attribute is of type "sendrecv" or
"recvonly", enable receipt and decoding of media.</li> "recvonly", enable receipt and decoding of media.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Finally, if this description is of type "pranswer" or <t>Finally, if this description is of type "pranswer" or
"answer", follow the processing defined in "answer", follow the processing defined in
<xref target="sec.applying-an-answer" format="default"/> below.</t> <xref target="sec.applying-an-answer" format="default"/> below.</t>
</section> </section>
<section anchor="sec.applying-a-remote-desc" numbered="true" toc="default" > <section anchor="sec.applying-a-remote-desc" numbered="true" toc="default" >
<name>Applying a Remote Description</name> <name>Applying a Remote Description</name>
<t>The following steps are performed to apply a remote <t>The following steps are performed to apply a remote
description. If an error is returned, the session MUST be description. If an error is returned, the session <bcp14>MUST</bcp14> be
restored to the state it was in before performing these restored to the state it was in before performing these
steps.</t> steps.</t>
<t>If the answer contains any "a=ice-options" attributes where <t>If the answer contains any "a=ice-options" attributes where
"trickle" is listed as an attribute, update the PeerConnection "trickle" is listed as an attribute, update the PeerConnection
canTrickle property to be true. Otherwise, set this property to canTrickle property to be true. Otherwise, set this property to
false.</t> false.</t>
<t>The following steps MUST be performed for attributes at the <t>The following steps <bcp14>MUST</bcp14> be performed for attributes a t the
session level; if any parameters are out of bounds, or cannot session level; if any parameters are out of bounds, or cannot
be applied, processing MUST stop and an error MUST be returned. be applied, processing <bcp14>MUST</bcp14> stop and an error <bcp14>MUST </bcp14> be returned.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>For any specified "CT" bandwidth value, set this as the <li>For any specified "CT" bandwidth value, set this as the
limit for the maximum total bitrate for all m= sections, as limit for the maximum total bitrate for all m= sections, as
specified in specified in
<xref target="RFC4566" format="default"/>, Section 5.8. Within this <xref target="RFC4566" sectionFormat="comma" section="5.8"/>. Within t his
overall limit, the implementation can dynamically decide how overall limit, the implementation can dynamically decide how
to best allocate the available bandwidth between m= sections, to best allocate the available bandwidth between m= sections,
respecting any specific limits that have been specified for respecting any specific limits that have been specified for
individual m= sections.</li> individual m= sections.</li>
<li>For any specified "RR" or "RS" bandwidth values, handle as <li>For any specified "RR" or "RS" bandwidth values, handle as
specified in specified in
<xref target="RFC3556" format="default"/>, Section 2.</li> <xref target="RFC3556" sectionFormat="comma" section="2"/>.</li>
<li>Any "AS" bandwidth value MUST be ignored, as the meaning <li>Any "AS" bandwidth value <bcp14>MUST</bcp14> be ignored, as the me
aning
of this construct at the session level is not well of this construct at the session level is not well
defined.</li> defined.</li>
</ul> </ul>
<t>For each m= section, the following steps MUST be performed; <t>For each m= section, the following steps <bcp14>MUST</bcp14> be perfo rmed;
if any parameters are out of bounds, or cannot be applied, if any parameters are out of bounds, or cannot be applied,
processing MUST stop and an error MUST be returned. processing <bcp14>MUST</bcp14> stop and an error <bcp14>MUST</bcp14> be returned.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the ICE ufrag or password changed from the previous <t>If the ICE ufrag or password changed from the previous
remote description: remote description:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the description is of type "offer", the <li>If the description is of type "offer", the
implementation MUST note that an ICE restart is needed, as implementation <bcp14>MUST</bcp14> note that an ICE restart is neede d, as
described in described in
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, <xref target="RFCYYY7" sectionFormat="comma" section="3.4.1.1.1"/></
Section 3.4.1.1.1</li> li>
<li>If the description is of type "answer" or "pranswer", <li>If the description is of type "answer" or "pranswer",
then check to see if the current local description is an then check to see if the current local description is an
ICE restart, and if not, generate an error. If the ICE restart, and if not, generate an error. If the
PeerConnection state is "have-remote-pranswer", and the ICE PeerConnection state is "have-remote-pranswer", and the ICE
ufrag or password changed from the previous provisional ufrag or password changed from the previous provisional
answer, then signal the ICE agent to discard any previous answer, then signal the ICE agent to discard any previous
ICE check list state for the m= section. Finally, signal ICE check list state for the m= section. Finally, signal
the ICE agent to begin checks.</li> the ICE agent to begin checks.</li>
</ul> </ul>
</li> </li>
<li>If the current local description indicates an ICE restart, <li>If the current local description indicates an ICE restart,
and either the ICE ufrag or password has not changed from the and either the ICE ufrag or password has not changed from the
previous remote description, as prescribed by previous remote description, as prescribed by
<xref target="RFC8445" format="default"/>, Section 9, generate an <xref target="RFC8445" sectionFormat="comma" section="9"/>, generate a n
error.</li> error.</li>
<li>Configure the ICE components associated with this media <li>Configure the ICE components associated with this media
section to use the supplied ICE remote ufrag and password for section to use the supplied ICE remote ufrag and password for
their connectivity checks.</li> their connectivity checks.</li>
<li>Pair any supplied ICE candidates with any gathered local <li>Pair any supplied ICE candidates with any gathered local
candidates, as described in candidates, as described in
<xref target="RFC8445" format="default"/>, Section 6.1.2, and start <xref target="RFC8445" sectionFormat="comma" section="6.1.2"/>, and st art
connectivity checks with the appropriate credentials.</li> connectivity checks with the appropriate credentials.</li>
<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="I-D.ietf-ice-trickle" format="default"/>, Section 11.</l i> <xref target="RFCYYY6" sectionFormat="comma" section="11"/>.</li>
<li> <li>
<t>If the m= section proto value indicates use of RTP: <t>If the m= section proto 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"/>), dissociate <xref target="sec.subsequent-offers" format="default"/>), dissociate
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>
skipping to change at line 3405 skipping to change at line 3351
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 implementation, 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" format="default"/>, Section 6.1. Specifically , this <xref target="RFC3264" sectionFormat="comma" section="6.1"/>. Specif ically, 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 MUST be ignored.</li> implementation, 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" format="default"/>, Section 4. If any referen <xref target="RFC4588" sectionFormat="comma" section="4"/>. If any r
ced eferenced
primary payload types are not present, this MUST result in primary payload types are not present, this <bcp14>MUST</bcp14> resu
lt 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 which are not supported by the local media payload types which are not supported by the local media
implementation, in which case, the RTX payload type MUST 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 implementation, enable them on the associated
media formats.</li> media formats.</li>
<li>For each specified SSRC that is signaled in the m= <li>For each specified SSRC that is signaled 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="I-D.ietf-mmusic-sdp-bundle-negotiation" format="defaul <xref target="RFCYYYB" sectionFormat="comma" section="10.2"/>.</li>
t"/>,
Section 10.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 implementation, establish a mapping
between the extension ID and URI, as described in between the extension ID and URI, as described in
<xref target="RFC5285" format="default"/>, Section 5. Specifically, this <xref target="RFC5285" sectionFormat="comma" section="5"/>. Specific ally, 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 MUST be not supported by the local implementation, 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
supported by the local implementation, enable them on the supported by the local implementation, enable them on the
associated media formats.</li> associated media formats.</li>
<li> <li>
<t>For any specified "TIAS" bandwidth value, set this value <t>For any specified "TIAS" bandwidth value, set this value
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 spacing="normal"> <ul empty="true">
<li>TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)</li> <li>TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)</li>
</ul> </ul>
<t> <t>
The 50 is based on 50 packets per second, the 40 is The 50 is based on 50 packets per second, the 40 is
based on an estimate of total header size, the 1000 changes based on an estimate of total header size, the 1000 changes
the unit from kbps to bps (as required by TIAS), and the the unit from kbps to bps (as required by TIAS), and the
0.95 is to allocate 5% to RTCP. "TIAS" is used in 0.95 is to allocate 5% to RTCP. "TIAS" is used in
preference to "AS" because it provides more accurate preference to "AS" because it provides more accurate
control of bandwidth.</t> control of bandwidth.</t>
</li> </li>
<li>For any "RR" or "RS" bandwidth values, handle as <li>For any "RR" or "RS" bandwidth values, handle as
specified in specified in
<xref target="RFC3556" format="default"/>, Section 2.</li> <xref target="RFC3556" sectionFormat="comma" section="2"/>.</li>
<li>Any specified "CT" bandwidth value MUST be ignored, as <li>Any specified "CT" bandwidth value <bcp14>MUST</bcp14> be igno
red, as
the meaning of this construct at the media level is not the meaning of this construct at the media level is not
well defined.</li> well defined.</li>
<li> <li>
<t>If the m= section is of type audio: <t>If the m= section is of type audio:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>For each specified "CN" media format, configure <li>For each specified "CN" media format, configure
silence suppression for all supported media formats with silence suppression for all supported media formats with
the same clockrate, as described in the same clockrate, as described in
<xref target="RFC3389" format="default"/>, Section 5, except for f ormats <xref target="RFC3389" sectionFormat="comma" section="5"/>, except for formats
that have their own internal silence suppression that have their own internal silence suppression
mechanisms. Silence suppression for such formats (e.g., mechanisms. Silence suppression for such formats (e.g.,
Opus) is controlled via fmtp parameters, as discussed in Opus) is controlled via fmtp parameters, as discussed in
<xref target="sec.voiceactivitydetection1" format="default"/>.</li > <xref target="sec.voiceactivitydetection1" format="default"/>.</li >
<li>For each specified "telephone-event" media format, <li>For each specified "telephone-event" media format,
enable DTMF transmission for all supported media formats enable DTMF transmission for all supported media formats
with the same clockrate, as described in with the same clockrate, as described in
<xref target="RFC4733" format="default"/>, Section 2.5.1.2. If the re are <xref target="RFC4733" sectionFormat="comma" section="2.5.1.2"/>. If there are
any supported media formats that do not have a any supported media formats that do not have a
corresponding telephone-event format, disable DTMF corresponding telephone-event format, disable DTMF
transmission for those formats.</li> transmission for those formats.</li>
<li>For any specified "ptime" value, configure the <li>For any specified "ptime" value, configure the
available media formats to use the specified packet size available media formats to use the specified packet size
when sending. If the specified size is not supported for when sending. If the specified size is not supported for
a media format, use the next closest value instead.</li> a media format, use the next closest value instead.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
skipping to change at line 3504 skipping to change at line 3449
<t>Finally, if this description is of type "pranswer" or <t>Finally, if this description is of type "pranswer" or
"answer", follow the processing defined in "answer", follow the processing defined in
<xref target="sec.applying-an-answer" format="default"/> below.</t> <xref target="sec.applying-an-answer" format="default"/> below.</t>
</section> </section>
<section anchor="sec.applying-an-answer" numbered="true" toc="default"> <section anchor="sec.applying-an-answer" numbered="true" toc="default">
<name>Applying an Answer</name> <name>Applying an Answer</name>
<t>In addition to the steps mentioned above for processing a <t>In addition to the steps mentioned above for processing a
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 MUST be performed: <t>For each m= section, the following steps <bcp14>MUST</bcp14> be perfo rmed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the m= section has been rejected (i.e. port is set to <li>If the m= section has been rejected (i.e. port 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
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/>, Section 3.4.3.1.</li> <xref target="RFCYYY7" sectionFormat="comma" section="3.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
tls-id has changed, tear down the DTLS connection. This tls-id has changed, tear down the DTLS connection. 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 MUST be generated. If an ICE restart is performed error <bcp14>MUST</bcp14> be generated. If an ICE restart is performed
without a change in tls-id or fingerprint, then the same DTLS without a change in tls-id or fingerprint, then the same DTLS
connection is continued over the new ICE channel. Note that connection is continued over the new ICE channel. Note that
although JSEP requires that answerers change the tls-id value although JSEP requires that answerers change the tls-id value
if and only if the offerer does, non-JSEP answerers are if and only if the offerer does, non-JSEP answerers are
permitted to change the tls-id as long as the offer contained permitted to change the tls-id as long as the offer contained
an ICE restart. Thus, JSEP implementations which process DTLS an ICE restart. Thus, JSEP implementations which process DTLS
data prior to receiving an answer MUST be prepared to receive data prior to receiving an answer <bcp14>MUST</bcp14> be prepared to r eceive
either a ClientHello or data from the previous DTLS either a ClientHello or data from the previous DTLS
connection.</li> connection.</li>
<li>If no valid DTLS connection exists, prepare to start a <li>If no valid DTLS connection exists, prepare to start a
DTLS connection, using the specified roles and fingerprints, DTLS connection, using the specified roles and fingerprints,
on any underlying ICE components, once they are active.</li> on any underlying ICE components, once they are active.</li>
<li> <li>
<t>If the m= section proto value indicates use of RTP: <t>If the m= section proto value indicates use of RTP:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the m= section references RTCP feedback mechanisms <li>If the m= section references RTCP feedback mechanisms
that were not present in the corresponding m= section in that were not present in the corresponding m= section in
the offer, this indicates a negotiation problem and MUST the offer, this indicates a negotiation problem and <bcp14>MUST</bcp 14>
result in an error. However, new media formats and new RTP result in an error. However, new media formats and new RTP
header extension values are permitted in the answer, as header extension values are permitted in the answer, as
described in described in
<xref target="RFC3264" format="default"/>, Section 7, and <xref target="RFC3264" sectionFormat="comma" section="7"/>, and
<xref target="RFC5285" format="default"/>, Section 6.</li> <xref target="RFC5285" sectionFormat="comma" section="6"/>.</li>
<li>If the m= section has RTCP mux enabled, discard the RTCP <li>If the m= section has RTCP mux enabled, discard the RTCP
ICE component, if one exists, and begin or continue muxing ICE component, if one exists, and begin or continue muxing
RTCP over the RTP ICE component, as specified in RTCP over the RTP ICE component, as specified in
<xref target="RFC5761" format="default"/>, Section 5.1.3. Otherwise, <xref target="RFC5761" sectionFormat="comma" section="5.1.3"/>. Othe rwise,
prepare to transmit RTCP over the RTCP ICE component; if no prepare to transmit RTCP over the RTCP ICE component; if no
RTCP ICE component exists, because RTCP mux was previously RTCP ICE component exists, because RTCP mux was previously
enabled, this MUST result in an error.</li> enabled, this <bcp14>MUST</bcp14> result in an error.</li>
<li>If the m= section has reduced-size RTCP enabled, <li>If the m= section has reduced-size RTCP enabled,
configure the RTCP transmission for this m= section to use configure the RTCP transmission for this m= section to use
reduced-size RTCP, as specified in reduced-size RTCP, as specified in
<xref target="RFC5506" format="default"/>.</li> <xref target="RFC5506" format="default"/>.</li>
<li>If the directional attribute in the answer indicates <li>If the directional attribute in the answer indicates
that the JSEP implementation should be sending media that the JSEP implementation should be sending media
("sendonly" for local answers, "recvonly" for remote ("sendonly" for local answers, "recvonly" for remote
answers, or "sendrecv" for either type of answer), choose answers, or "sendrecv" for either type of answer), choose
the media format to send as the most preferred media format the media format to send as the most preferred media format
from the remote description that is also locally supported, from the remote description that is also locally supported,
as discussed in as discussed in Sections <xref target="RFC3264" section="6.1"
<xref target="RFC3264" format="default"/>, Sections 6.1 and 7, and s sectionFormat="bare"/> and <xref target="RFC3264" section="7" sectionFormat="bar
tart e"/> of <xref target="RFC3264"/>, and start
transmitting RTP media using that format once the transmitting RTP media using that format once the
underlying transport layers have been established. If an underlying transport layers have been established. If an
SSRC has not already been chosen for this outgoing RTP SSRC has not already been chosen for this outgoing RTP
stream, choose a random one. If media is already being stream, choose a random one. If media is already being
transmitted, the same SSRC SHOULD be used unless the transmitted, the same SSRC <bcp14>SHOULD</bcp14> be used unless the
clockrate of the new codec is different, in which case a clockrate of the new codec is different, in which case a
new SSRC MUST be chosen, as specified in new SSRC <bcp14>MUST</bcp14> be chosen, as specified in
<xref target="RFC7160" format="default"/>, Section 3.1.</li> <xref target="RFC7160" sectionFormat="comma" section="3.1"/>.</li>
<li>The payload type mapping from the remote description is <li>The payload type mapping from the remote description is
used to determine payload types for the outgoing RTP used to determine payload types for the outgoing RTP
streams, including the payload type for the send media streams, including the payload type for the send media
format chosen above. Any RTP header extensions that were format chosen above. Any RTP header extensions that were
negotiated should be included in the outgoing RTP streams, negotiated should be included in the outgoing RTP streams,
using the extension mapping from the remote description; if using the extension mapping from the remote description; if
the RID header extension has been negotiated, and RID the RID header extension has been negotiated, and RID
values are specified, include the RID header extension in values are specified, include the RID header extension in
the outgoing RTP streams, as indicated in the outgoing RTP streams, as indicated in
<xref target="I-D.ietf-mmusic-rid" format="default"/>, Section 4.</l i> <xref target="RFCYYYC" sectionFormat="comma" section="4"/>.</li>
<li>If the m= section is of type audio, and silence <li>If the m= section is of type audio, and silence
suppression was configured for the send media format as a suppression was configured for the send media format as a
result of processing the remote description, and is also result of processing the remote description, and is also
enabled for that format in the local description, use enabled for that format in the local description, use
silence suppression for outgoing media, in accordance with silence suppression for outgoing media, in accordance with
the guidance in the guidance in
<xref target="sec.voiceactivitydetection1" format="default"/>. If th ese <xref target="sec.voiceactivitydetection1" format="default"/>. If th ese
conditions are not met, silence suppression MUST NOT be conditions are not met, silence suppression <bcp14>MUST NOT</bcp14> be
used for outgoing media.</li> used for outgoing media.</li>
<li>If simulcast has been negotiated, send the number of <li>If simulcast has been negotiated, send the number of
Source RTP Streams as specified in Source RTP Streams as specified in
<xref target="I-D.ietf-mmusic-sdp-simulcast" format="default"/>, <xref target="RFCYYYE" sectionFormat="comma" section="6.2.2"/>.</li>
Section 6.2.2.</li>
<li>If the send media format chosen above has a <li>If the send media format chosen above has a
corresponding "rtx" media format, or a FEC mechanism has corresponding "rtx" media format, or a FEC mechanism has
been negotiated, establish a Redundancy RTP Stream with a been negotiated, establish a Redundancy RTP Stream with a
random SSRC for each Source RTP Stream, and start or random SSRC for each Source RTP Stream, and start or
continue transmitting RTX/FEC packets as needed.</li> continue transmitting RTX/FEC packets as needed.</li>
<li>If the send media format chosen above has a <li>If the send media format chosen above has a
corresponding "red" media format of the same clockrate, corresponding "red" media format of the same clockrate,
allow redundant encoding using the specified format for allow redundant encoding using the specified format for
resiliency purposes, as discussed in resiliency purposes, as discussed in
<xref target="I-D.ietf-rtcweb-fec" format="default"/>, Section 3.2. Note <xref target="RFCYYYF" sectionFormat="comma" section="3.2"/>. Note
that unlike RTX or FEC media formats, the "red" format is that unlike RTX or FEC media formats, the "red" format is
transmitted on the Source RTP Stream, not the Redundancy transmitted on the Source RTP Stream, not the Redundancy
RTP Stream.</li> RTP Stream.</li>
<li>Enable the RTCP feedback mechanisms referenced in the <li>Enable the RTCP feedback mechanisms referenced in the
media section for all Source RTP Streams using the media section for all Source RTP Streams using the
specified media formats. Specifically, begin or continue specified media formats. Specifically, begin or continue
sending the requested feedback types and reacting to sending the requested feedback types and reacting to
received feedback, as specified in received feedback, as specified in
<xref target="RFC4585" format="default"/>, Section 4.2. When sending RTCP <xref target="RFC4585" sectionFormat="comma" section="4.2"/>. When s ending RTCP
feedback, follow the rules and recommendations from feedback, follow the rules and recommendations from
<xref target="RFC8108" format="default"/> Section 5.4.1, to select <xref target="RFC8108" sectionFormat="comma" section="5.4.1"/>, to select
which SSRC to use.</li> which SSRC to use.</li>
<li>If the directional attribute in the answer indicates <li>If the directional attribute in the answer indicates
that the JSEP implementation should not be sending media that the JSEP implementation should not be sending media
("recvonly" for local answers, "sendonly" for remote ("recvonly" for local answers, "sendonly" for remote
answers, or "inactive" for either type of answer) stop answers, or "inactive" for either type of answer) stop
transmitting all RTP media, but continue sending RTCP, as transmitting all RTP media, but continue sending RTCP, as
described in described in
<xref target="RFC3264" format="default"/>, Section 5.1.</li> <xref target="RFC3264" sectionFormat="comma" section="5.1"/>.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>If the m= section proto value indicates use of SCTP: <t>If the m= section proto value indicates use of SCTP:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If an SCTP association exists, and the remote SCTP port <li>If an SCTP association exists, and the remote SCTP port
has changed, discard the existing SCTP association. This has changed, discard the existing SCTP association. This
includes the case when the PeerConnection state is includes the case when the PeerConnection state is
"have-remote-pranswer".</li> "have-remote-pranswer".</li>
<li>If no valid SCTP association exists, prepare to initiate <li>If no valid SCTP association exists, prepare to initiate
a SCTP association over the associated ICE component and a SCTP association over the associated ICE component and
DTLS connection, using the local SCTP port value from the DTLS connection, using the local SCTP port value from the
local description, and the remote SCTP port value from the local description, and the remote SCTP port value from the
remote description, as described in remote description, as described in
<xref target="I-D.ietf-mmusic-sctp-sdp" format="default"/>, Section <xref target="RFCYYY9" sectionFormat="comma" section="10.2"/>.</li>
10.2.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>If the answer contains valid bundle groups, discard any ICE <t>If the answer contains valid bundle groups, discard any ICE
components for the m= sections that will be bundled onto the components for the m= sections that will be bundled onto the
primary ICE components in each bundle, and begin muxing these primary ICE components in each bundle, and begin muxing these
m= sections accordingly, as described in m= sections accordingly, as described in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default"/> <xref target="RFCYYYB" sectionFormat="comma" section="8.2"/>.</t>
,
Section 8.2.</t>
<t>If the description is of type "answer", and there are still <t>If the description is of type "answer", and there are still
remaining candidates in the ICE candidate pool, discard remaining candidates in the ICE candidate pool, discard
them.</t> them.</t>
</section> </section>
</section> </section>
<section anchor="sec.rtp.demux" numbered="true" toc="default"> <section anchor="sec.rtp.demux" numbered="true" toc="default">
<name>Processing RTP/RTCP</name> <name>Processing RTP/RTCP</name>
<t>When bundling, associating incoming RTP/RTCP with the proper <t>When bundling, associating incoming RTP/RTCP with the proper
m= section is defined in m= section is defined in
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation" format="default"/>, <xref target="RFCYYYB" sectionFormat="comma" section="10.2"/>. When not bu
Section ndling, the proper m= section is clear from the
10.2. When not bundling, 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(s) are known, RTP/RTCP is delivered <t>Once the proper m= section(s) are known, RTP/RTCP is delivered
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 RID level. This includes using RID
<xref target="I-D.ietf-mmusic-rid" format="default"/> to distinguish betwe en <xref target="RFCYYYC" format="default"/> to distinguish between
multiple Encoded Streams, as well as determine which Source RTP multiple Encoded Streams, as well as 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
format in 72 columns, some of the lines in SDP have been split format in 72 columns, some of the lines in SDP have been 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
skipping to change at line 3699 skipping to change at line 3640
application in Alice's browser to the JavaScript in Bob's application in Alice's browser to the JavaScript in Bob's
browser, abbreviated as AliceJS and BobJS respectively, are browser, abbreviated as AliceJS and BobJS respectively, are
assumed to flow over some signaling protocol via a web server. assumed to flow over some signaling protocol via a web server.
The JavaScript on both Alice's side and Bob's side waits for The JavaScript on both Alice's side and Bob's side waits for
all candidates before sending the offer or answer, so the all candidates before sending the offer or answer, so the
offers and answers are complete; trickle ICE is not used. The offers and answers are complete; trickle ICE is not used. The
user agents (JSEP implementations) in Alice and Bob's browsers, user agents (JSEP implementations) in Alice and Bob's browsers,
abbreviated as AliceUA and BobUA respectively, are using the abbreviated as AliceUA and BobUA respectively, are using the
default bundle policy of "balanced", and the default RTCP mux default bundle policy of "balanced", and the default RTCP mux
policy of "require".</t> policy of "require".</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <!-- Reviewer: This looks like pseudocode to me; please fix if wrong -->
<sourcecode name="" type="pseudocode"><![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 two tracks: audio and video AliceJS->AliceUA: addTrack with two tracks: audio and video
AliceJS->AliceUA: createOffer to get offer AliceJS->AliceUA: createOffer to get offer
AliceJS->AliceUA: setLocalDescription with offer AliceJS->AliceUA: setLocalDescription with offer
AliceUA->AliceJS: multiple onicecandidate events with candidates AliceUA->AliceJS: multiple onicecandidate events with candidates
// wait for ICE gathering to complete // wait for ICE gathering to complete
AliceUA->AliceJS: onicecandidate event with null candidate AliceUA->AliceJS: onicecandidate event with null candidate
AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription
skipping to change at line 3741 skipping to change at line 3682
// |answer-A1| is sent over signaling protocol to Alice // |answer-A1| is sent over signaling protocol to Alice
BobJS->WebServer: signaling with |answer-A1| BobJS->WebServer: signaling with |answer-A1|
WebServer->AliceJS: signaling with |answer-A1| WebServer->AliceJS: signaling with |answer-A1|
// |answer-A1| arrives at Alice // |answer-A1| arrives at Alice
AliceJS->AliceUA: setRemoteDescription with |answer-A1| AliceJS->AliceUA: setRemoteDescription with |answer-A1|
AliceUA->AliceJS: ontrack events for audio and video tracks AliceUA->AliceJS: ontrack events for audio and video tracks
// media flows // media flows
BobUA->AliceUA: media sent from Bob to Alice BobUA->AliceUA: media sent from Bob to Alice
AliceUA->BobUA: media sent from Alice to Bob AliceUA->BobUA: media sent from Alice to Bob ]]></sourcecode>
]]></artwork>
<t>The SDP for |offer-A1| looks like:</t> <t>The SDP for |offer-A1| looks like:</t>
<artwork alt="offer-A1" name="" type="" align="left"><![CDATA[ <sourcecode name="offer-A1" type="sdp"><![CDATA[
v=0 v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0 o=- 4962303333179871722 1 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 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.100 c=IN IP4 203.0.113.100
skipping to change at line 3813 skipping to change at line 3751
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:
BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=tls-id:91bbf309c0990a6bec11e38ba2933cee
a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp:10103 IN IP4 203.0.113.100
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host
a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host
a=end-of-candidates a=end-of-candidates ]]></sourcecode>
]]></artwork>
<t>The SDP for |answer-A1| looks like:</t> <t>The SDP for |answer-A1| looks like:</t>
<artwork alt="answer-A1" name="" type="" align="left"><![CDATA[ <sourcecode name="answer-A1" type="sdp"><![CDATA[
v=0 v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0 o=- 6729291447651054566 1 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 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.200 c=IN IP4 203.0.113.200
skipping to change at line 3870 skipping to change at line 3805
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
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:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae ]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="sec.detailed-example" numbered="true" toc="default"> <section anchor="sec.detailed-example" numbered="true" toc="default">
<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 "max-bundle", an RTCP mux policy mode, with a bundle policy of "max-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
screensharing, both supporting FEC, and with the video feed screensharing, both supporting FEC, and 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="" align="left" alt=""><![CDATA[ <!-- Reviewer: labeled as pseudocode; please fix if wrong -->
<sourcecode name="" type="pseudocode"><![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|
// |offer-B1| is sent over signaling protocol to Bob // |offer-B1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-B1| AliceJS->WebServer: signaling with |offer-B1|
WebServer->BobJS: signaling with |offer-B1| WebServer->BobJS: signaling with |offer-B1|
skipping to change at line 3980 skipping to change at line 3913
AliceJS->AliceUA: createAnswer to get |answer-B2| AliceJS->AliceUA: createAnswer to get |answer-B2|
AliceJS->AliceUA: setLocalDescription with |answer-B2| AliceJS->AliceUA: setLocalDescription with |answer-B2|
// |answer-B2| is sent over signaling protocol to Bob // |answer-B2| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |answer-B2| AliceJS->WebServer: signaling with |answer-B2|
WebServer->BobJS: signaling with |answer-B2| WebServer->BobJS: signaling with |answer-B2|
BobJS->BobUA: setRemoteDescription with |answer-B2| BobJS->BobUA: setRemoteDescription with |answer-B2|
// media is flowing between endpoints // media is flowing between endpoints
BobUA->AliceUA: audio+video+data sent from Bob to Alice BobUA->AliceUA: audio+video+data sent from Bob to Alice
AliceUA->BobUA: audio+video+data sent from Alice to Bob AliceUA->BobUA: audio+video+data sent from Alice to Bob ]]></sourcecode>
]]></artwork>
<t>The SDP for |offer-B1| looks like:</t> <t>The SDP for |offer-B1| looks like:</t>
<artwork alt="offer-B1" name="" type="" align="left"><![CDATA[ <sourcecode name="offer-B1" type="sdp"><![CDATA[
v=0 v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0 o=- 4962303333179871723 1 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 a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
skipping to change at line 4024 skipping to change at line 3954
a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
m=application 0 UDP/DTLS/SCTP webrtc-datachannel m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=sctp-port:5000 a=sctp-port:5000
a=max-message-size:65536 a=max-message-size:65536
a=bundle-only a=bundle-only ]]></sourcecode>
]]></artwork>
<t>|offer-B1-candidate-1| looks like:</t> <t>|offer-B1-candidate-1| looks like:</t>
<artwork alt="offer-B1-candidate-1" name="" type="" align="left"><![CDAT <!-- Reviewer: Guessing sdp, because they're "offers"; pls fix if wrong -->
A[ <sourcecode name="offer-B1-candidate-1" type="sdp"><![CDATA[
ufrag ATEn ufrag ATEn
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host ]]></sourcecode>
]]></artwork>
<t>|offer-B1-candidate-2| looks like:</t> <t>|offer-B1-candidate-2| looks like:</t>
<artwork alt="offer-B1-candidate-2" name="" type="" align="left"><![CDAT <sourcecode name="offer-B1-candidate-2" type="sdp"><![CDATA[
A[
ufrag ATEn ufrag ATEn
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx
raddr 203.0.113.100 rport 10100 raddr 203.0.113.100 rport 10100 ]]></sourcecode>
]]></artwork>
<t>|offer-B1-candidate-3| looks like:</t> <t>|offer-B1-candidate-3| looks like:</t>
<artwork alt="offer-B1-candidate-3" name="" type="" align="left"><![CDAT <sourcecode name="offer-B1-candidate-3" type="sdp"><![CDATA[
A[
ufrag ATEn ufrag ATEn
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay
raddr 198.51.100.100 rport 11100 raddr 198.51.100.100 rport 11100 ]]></sourcecode>
]]></artwork>
<t>The SDP for |answer-B1| looks like:</t> <t>The SDP for |answer-B1| looks like:</t>
<artwork alt="answer-B1" name="" type="" align="left"><![CDATA[ <sourcecode name="answer-B1" type="sdp"><![CDATA[
v=0 v=0
o=- 7729291447651054566 1 IN IP4 0.0.0.0 o=- 7729291447651054566 1 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 a=group:BUNDLE a1 d1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:a1 a=mid:a1
skipping to change at line 4096 skipping to change at line 4015
a=setup:active a=setup:active
a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtcp-rsize a=rtcp-rsize
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=sctp-port:5000 a=sctp-port:5000
a=max-message-size:65536 a=max-message-size:65536 ]]></sourcecode>
]]></artwork>
<t>|answer-B1-candidate-1| looks like:</t> <t>|answer-B1-candidate-1| looks like:</t>
<artwork alt="answer-B1-candidate-1" name="" type="" align="left"><![CDA <!-- Reviewer: Again guessing sdp for the following.... -->
TA[ <sourcecode name="answer-B1-candidate-1" type="sdp"><![CDATA[
ufrag 7sFv ufrag 7sFv
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host ]]></sourcecode>
]]></artwork>
<t>|answer-B1-candidate-2| looks like:</t> <t>|answer-B1-candidate-2| looks like:</t>
<artwork alt="answer-B1-candidate-2" name="" type="" align="left"><![CDA <sourcecode name="answer-B1-candidate-2" type="sdp"><![CDATA[
TA[
ufrag 7sFv ufrag 7sFv
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx
raddr 203.0.113.200 rport 10200 raddr 203.0.113.200 rport 10200 ]]></sourcecode>
]]></artwork>
<t>|answer-B1-candidate-3| looks like:</t> <t>|answer-B1-candidate-3| looks like:</t>
<artwork alt="answer-B1-candidate-3" name="" type="" align="left"><![CDA <sourcecode name="answer-B1-candidate-3" type="sdp"><![CDATA[
TA[
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 raddr 198.51.100.200 rport 11200 ]]></sourcecode>
]]></artwork>
<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>
<artwork alt="offer-B2" name="" type="" align="left"><![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
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
skipping to change at line 4222 skipping to change at line 4130
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =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 a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae ]]></sourcecode>
]]></artwork>
<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 setup:passive to maintain
the existing DTLS roles.</t> the existing DTLS roles.</t>
<artwork alt="answer-B2" name="" type="" align="left"><![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
m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.100 c=IN IP4 192.0.2.100
skipping to change at line 4312 skipping to change at line 4217
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0]
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 ]]></sourcecode>
]]></artwork>
</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, A lice's <xref target="sec.use-of-provisional-answer" format="default"/>. Here, A lice'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
skipping to change at line 4342 skipping to change at line 4245
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
transmitted immediately by the callee immediately upon transmitted immediately by the callee immediately upon
answering the call, minimizing perceived post-dial-delay. The answering the call, minimizing perceived post-dial-delay. The
second offer/answer exchange can also change the preferred second offer/answer exchange can also change the preferred
codecs or other session parameters.</t> codecs or other session parameters.</t>
<t>This example also makes use of the "relay" ICE candidate <t>This example also makes use of the "relay" ICE candidate
policy described in policy described in
<xref target="sec.ice-candidate-policy" format="default"/> to minimize t he ICE <xref target="sec.ice-candidate-policy" format="default"/> to minimize t he ICE
gathering and checking needed.</t> gathering and checking needed.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <!-- Reviewer: More pseudocode, I think. -->
<sourcecode name="" type="pseudocode"><![CDATA[
// set up local media state // set up local media state
AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy
AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: addTrack with two tracks: audio and video
AliceJS->AliceUA: createOffer to get |offer-C1| AliceJS->AliceUA: createOffer to get |offer-C1|
AliceJS->AliceUA: setLocalDescription with |offer-C1| AliceJS->AliceUA: setLocalDescription with |offer-C1|
// |offer-C1| is sent over signaling protocol to Bob // |offer-C1| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |offer-C1| AliceJS->WebServer: signaling with |offer-C1|
WebServer->BobJS: signaling with |offer-C1| WebServer->BobJS: signaling with |offer-C1|
skipping to change at line 4410 skipping to change at line 4313
// |offer-C2| (sendrecv) arrives at Alice // |offer-C2| (sendrecv) arrives at Alice
AliceJS->AliceUA: setRemoteDescription with |offer-C2| AliceJS->AliceUA: setRemoteDescription with |offer-C2|
AliceJS->AliceUA: createAnswer AliceJS->AliceUA: createAnswer
AliceJS->AliceUA: setLocalDescription with |answer-C2| AliceJS->AliceUA: setLocalDescription with |answer-C2|
AliceUA->BobUA: media sent from Alice to Bob AliceUA->BobUA: media sent from Alice to Bob
// |answer-C2| is sent over signaling protocol to Bob // |answer-C2| is sent over signaling protocol to Bob
AliceJS->WebServer: signaling with |answer-C2| AliceJS->WebServer: signaling with |answer-C2|
WebServer->BobJS: signaling with |answer-C2| WebServer->BobJS: signaling with |answer-C2|
BobJS->BobUA: setRemoteDescription with |answer-C2| BobJS->BobUA: setRemoteDescription with |answer-C2| ]]></sourcecode>
]]></artwork>
<t>The SDP for |offer-C1| looks like:</t> <t>The SDP for |offer-C1| looks like:</t>
<artwork alt="offer-C1" name="" type="" align="left"><![CDATA[ <sourcecode name="offer-C1" type="sdp"><![CDATA[
v=0 v=0
o=- 1070771854436052752 1 IN IP4 0.0.0.0 o=- 1070771854436052752 1 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 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
skipping to change at line 4467 skipping to change at line 4367
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
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:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce
a=bundle-only a=bundle-only ]]></sourcecode>
]]></artwork>
<t>|offer-C1-candidate-1| looks like:</t> <t>|offer-C1-candidate-1| looks like:</t>
<artwork alt="offer-C1-candidate-1" name="" type="" align="left"><![CDAT <sourcecode name="offer-C1-candidate-1" type="sdp"><![CDATA[
A[
ufrag 4ZcD ufrag 4ZcD
index 0 index 0
mid a1 mid a1
attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay
raddr 0.0.0.0 rport 0 raddr 0.0.0.0 rport 0 ]]></sourcecode>
]]></artwork>
<t>The SDP for |answer-C1| looks like:</t> <t>The SDP for |answer-C1| looks like:</t>
<artwork alt="answer-C1" name="" type="" align="left"><![CDATA[ <sourcecode name="answer-C1" type="sdp"><![CDATA[
v=0 v=0
o=- 6386516489780559513 1 IN IP4 0.0.0.0 o=- 6386516489780559513 1 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 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
skipping to change at line 4533 skipping to change at line 4427
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
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:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b ]]></sourcecode>
]]></artwork>
<t>|answer-C1-candidate-1| looks like:</t> <t>|answer-C1-candidate-1| looks like:</t>
<artwork alt="answer-C1-candidate-1" name="" type="" align="left"><![CDA <sourcecode name="answer-C1-candidate-1" type="sdp"><![CDATA[
TA[
ufrag TpaA ufrag TpaA
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 0.0.0.0 rport 0 raddr 0.0.0.0 rport 0 ]]></sourcecode>
]]></artwork>
<t>The SDP for |offer-C2| looks like:</t> <t>The SDP for |offer-C2| looks like:</t>
<artwork alt="offer-C2" name="" type="" align="left"><![CDATA[ <sourcecode name="offer-C2" type="sdp"><![CDATA[
v=0 v=0
o=- 6386516489780559513 2 IN IP4 0.0.0.0 o=- 6386516489780559513 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 v1 a=group:BUNDLE a1 v1
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
c=IN IP4 192.0.2.200 c=IN IP4 192.0.2.200
skipping to change at line 4602 skipping to change at line 4490
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
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:751f239e-4ae0-c549-aa3d-890de772998b a=msid:751f239e-4ae0-c549-aa3d-890de772998b ]]></sourcecode>
]]></artwork>
<t>The SDP for |answer-C2| looks like:</t> <t>The SDP for |answer-C2| looks like:</t>
<artwork alt="answer-C2" name="" type="" align="left"><![CDATA[ <sourcecode name="answer-C2" type="sdp"><![CDATA[
v=0 v=0
o=- 1070771854436052752 2 IN IP4 0.0.0.0 o=- 1070771854436052752 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 v1 a=group:BUNDLE a1 v1
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.100 c=IN IP4 192.0.2.100
skipping to change at line 4661 skipping to change at line 4546
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000 a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100 a=fmtp:102 apt=100
=rtpmap:103 rtx/90000 =rtpmap:103 rtx/90000
a=fmtp:103 apt=101 a=fmtp:103 apt=101
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:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce ]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="sec.security-considerations" numbered="true" toc="default"> <section anchor="sec.security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The IETF has published separate documents <t>The IETF has published separate documents
<xref target="I-D.ietf-rtcweb-security-arch" format="default"/> <xref target="RFCYYY2" format="default"/>
<xref target="I-D.ietf-rtcweb-security" format="default"/> describing th <xref target="RFCYYY1" format="default"/> describing the security
e security
architecture for WebRTC as a whole. The remainder of this section architecture for WebRTC as a whole. The remainder of this section
describes security considerations for this document.</t> describes security considerations for this document.</t>
<t>While formally the JSEP interface is an API, it is better to <t>While formally the JSEP interface is an API, it is better to
think of it as an Internet protocol, with the application think of it as an Internet protocol, with the application
JavaScript being untrustworthy from the perspective of the JSEP JavaScript being untrustworthy from the perspective of the JSEP
implementation. Thus, the threat model of implementation. Thus, the threat model of
<xref target="RFC3552" format="default"/> applies. In particular, JavaScri pt can <xref target="RFC3552" format="default"/> applies. In particular, JavaScri pt can
call the API in any order and with any inputs, including call the API in any order and with any inputs, including
malicious ones. This is particularly relevant when we consider malicious ones. This is particularly relevant when we consider
the SDP which is passed to setLocalDescription(). While correct the SDP which is passed to setLocalDescription(). While correct
API usage requires that the application pass in SDP which was API usage requires that the application pass in SDP which was
derived from createOffer() or createAnswer(), there is no derived from createOffer() or createAnswer(), there is no
guarantee that applications do so. The JSEP implementation MUST guarantee that applications do so. The JSEP implementation <bcp14>MUST</bc p14>
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 your public IP address by removing
server reflexive candidates. Applications which wish to conceal server reflexive candidates. Applications which wish to conceal
their public IP address should instead configure the ICE agent to their public IP address should instead configure the ICE agent 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 requires no actions from IANA.</t> <t>This document requires no actions from IANA.</t>
</section> </section>
<section anchor="sec.acknowledgements" numbered="true" toc="default"> <section anchor="sec.acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and <t><contact fullname="Harald Alvestrand"/>, <contact fullname="Taylor
Peter Thatcher provided significant text for this draft. Bernard Brandstetter"/>, <contact fullname="Suhas Nandakumar"/>, and
Aboba, Adam Bergkvist, Dan Burnett, Ben Campbell, Alissa Cooper, <contact fullname="Peter Thatcher"/> provided significant text for this
Richard Ejzak, Stefan Hakansson, Ted Hardie, Christer Holmberg draft. <contact fullname="Bernard Aboba"/>, <contact fullname="Adam
Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Narayanan, Bergkvist"/>, <contact fullname="Dan Burnett"/>, <contact fullname="Ben
Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Sean Campbell"/>, <contact fullname="Alissa Cooper"/>,
Turner, and Magnus Westerlund all provided valuable feedback on <contact fullname="Richard Ejzak"/>, <contact fullname="Stefan
Håkansson"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Christe
r Holmberg"/>
<contact fullname="Andrew Hutton"/>, <contact fullname="Randell
Jesup"/>, <contact fullname="Matthew Kaufman"/>, <contact fullname="Anant
Narayanan"/>,
<contact fullname="Adam Roach"/>, <contact fullname="Robert Sparks"/>,
<contact fullname="Neil Stratford"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Sean
Turner"/>, and <contact fullname="Magnus Westerlund"/> all provided valuab
le feedback on
this proposal.</t> this proposal.</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="I-D.ietf-avtext-rid" target="http://www.ietf.org/inte <!-- draft-ietf-avtext-rid (RFC YYYD) -->
rnet-drafts/draft-ietf-avtext-rid-09.txt"> <reference anchor="RFCYYYD" target="https://www.rfc-editor.org/info/rfcY
YYD">
<front> <front>
<title>RTP Stream Identifier Source Description (SDES)</title> <title>RTP Stream Identifier Source Description (SDES)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-avtext-rid-09"/> <seriesInfo name="RFC" value="YYYD"/>
<author initials="A" surname="Roach" fullname="Adam Roach"> <seriesInfo name="DOI" value="10.17487/RFCYYYD"/>
<author initials="A.B." surname="Roach" fullname="Adam Roach">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar "> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar ">
<organization/> <organization/>
</author> </author>
<author initials="P" surname="Thatcher" fullname="Peter Thatcher"> <author initials="P" surname="Thatcher" fullname="Peter Thatcher">
<organization/> <organization/>
</author> </author>
<date month="October" day="6" year="2016"/> <date month="May" year="2020"/>
<abstract>
<t>This document defines and registers two new RTCP Stream Identif
ier Source Description (SDES) items. One, named RtpStreamId, is used for unique
identification of RTP streams. The other, RepairedRtpStreamId, can be used to
identify which stream a redundancy RTP stream is to be used to repair.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-ice-trickle" target="http://www.ietf.org/int
ernet-drafts/draft-ietf-ice-trickle-21.txt"> <!-- draft-ietf-ice-trickle (RFC YYY6) -->
<reference anchor="RFCYYY6" target="https://www.rfc-editor.org/info/rfcY
YY6">
<front> <front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the I nteractive Connectivity Establishment (ICE) Protocol</title> <title>Trickle ICE: Incremental Provisioning of Candidates for the I nteractive Connectivity Establishment (ICE) Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ice-trickle-21"/ <seriesInfo name="RFC" value="YYY6"/>
> <seriesInfo name="DOI" value="10.17487/RFCYYY6"/>
<author initials="E" surname="Ivov" fullname="Emil Ivov"> <author initials="E" surname="Ivov" fullname="Emil Ivov">
<organization/> <organization/>
</author> </author>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla"> <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Uberti" fullname="Justin Uberti"> <author initials="J" surname="Uberti" fullname="Justin Uberti">
<organization/> <organization/>
</author> </author>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-And re"> <author initials="P" surname="Saint-Andre" fullname="Peter Saint-And re">
<organization/> <organization/>
</author> </author>
<date month="April" day="15" year="2018"/> <date month="May" year="2020"/>
<abstract>
<t>This document describes "Trickle ICE", an extension to the Inte
ractive Connectivity Establishment (ICE) protocol that enables ICE agents to beg
in connectivity checks while they are still gathering candidates, by incremental
ly exchanging candidates over time instead of all at once. This method can cons
iderably accelerate the process of establishing a communication session.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-dtls-sdp" target="http://www.ietf.org
/internet-drafts/draft-ietf-mmusic-dtls-sdp-32.txt"> <!-- draft-ietf-mmusic-dtls-sdp (RFC YYYA) -->
<reference anchor="RFCYYYA" target="https://www.rfc-editor.org/info/rfcY
YYA">
<front> <front>
<title>Session Description Protocol (SDP) Offer/Answer Consideration s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS )</title> <title>Session Description Protocol (SDP) Offer/Answer Consideration s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS )</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-dtls-sdp- <seriesInfo name="RFC" value="YYYA"/>
32"/> <seriesInfo name="DOI" value="10.17487/RFCYYYA"/>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" <author initials="C.H." surname="Holmberg" fullname="Christer Holmbe
> rg">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Shpount" fullname="Roman Shpount"> <author initials="R.S." surname="Shpount" fullname="Roman Shpount">
<organization/> <organization/>
</author> </author>
<date month="October" day="29" year="2017"/> <date month="May" year="2020"/>
<abstract>
<t>This document defines the Session Description Protocol (SDP) of
fer/ answer procedures for negotiating and establishing a Datagram Transport Lay
er Security (DTLS) association. The document also defines the criteria for when
a new DTLS association must be established. The document updates RFC 5763 and
RFC 7345, by replacing common SDP offer/answer procedures with a reference to th
is specification. This document defines a new SDP media-level attribute, 'tls-i
d'. This document also defines how the 'tls-id' attribute can be used for negot
iating and establishing a Transport Layer Security (TLS) connection, in conjunct
ion with the procedures in RFC 4145 and RFC 8122.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-ice-sip-sdp" target="http://www.ietf.
org/internet-drafts/draft-ietf-mmusic-ice-sip-sdp-39.txt"> <!-- draft-ietf-mmusic-ice-sip-sdp (RFC YYY7) -->
<reference anchor="RFCYYY7" target="https://www.rfc-editor.org/info/rfcY
YY7">
<front> <front>
<title>Session Description Protocol (SDP) Offer/Answer procedures fo <title>Session Description Protocol (SDP) Offer/Answer Procedures
r Interactive Connectivity Establishment (ICE)</title> for Interactive Connectivity Establishment (ICE)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-ice-sip-s <seriesInfo name="RFC" value="YYY7"/>
dp-39"/> <seriesInfo name="DOI" value="10.17487/RFCYYY7"/>
<author initials="M" surname="Petit-Huguenin" fullname="Marc Petit-H uguenin"> <author initials="M" surname="Petit-Huguenin" fullname="Marc Petit-H uguenin">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar "> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar ">
<organization/> <organization/>
</author> </author>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" > <author initials="C" surname="Holmberg" fullname="Christer Holmberg" >
<organization/> <organization/>
</author> </author>
<author initials="A" surname="Keranen" fullname="Ari Keranen"> <author initials="A" surname="Keränen" fullname="Ari Keränen">
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Shpount" fullname="Roman Shpount"> <author initials="R" surname="Shpount" fullname="Roman Shpount">
<organization/> <organization/>
</author> </author>
<date month="August" day="13" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>This document describes Session Description Protocol (SDP) Offe
r/ Answer procedures for carrying out Interactive Connectivity Establishment (IC
E) between the agents. This document obsoletes RFC 5245.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-msid" target="http://www.ietf.org/int
ernet-drafts/draft-ietf-mmusic-msid-17.txt"> <!-- draft-ietf-mmusic-msid (RFC YYY4) -->
<reference anchor="RFCYYY4" target="https://www.rfc-editor.org/info/rfcY
YY4">
<front> <front>
<title>WebRTC MediaStream Identification in the Session Description <title>WebRTC MediaStream Identification in the Session
Protocol</title> Description Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-msid-17"/ <seriesInfo name="RFC" value="YYY4"/>
> <seriesInfo name="DOI" value="10.17487/RFCYYY4"/>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran <author initials="H. T." surname="Alvestrand" fullname="Harald Alves
d"> trand">
<organization/> <organization/>
</author> </author>
<date month="December" day="13" year="2018"/> <date month="May" year="2020"/>
<abstract>
<t>This document specifies a Session Description Protocol (SDP) Gr
ouping mechanism for RTP media streams that can be used to specify relations bet
ween media streams. This mechanism is used to signal the association between th
e SDP concept of "media description" and the WebRTC concept of "MediaStream" / "
MediaStreamTrack" using SDP signaling. This document is a work item of the MMUS
IC WG, whose discussion list is mmusic@ietf.org.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-mux-exclusive" target="http://www.iet
f.org/internet-drafts/draft-ietf-mmusic-mux-exclusive-12.txt"> <!-- draft-ietf-mmusic-mux-exclusive (RFC YYYG) -->
<reference anchor="RFCYYYG" target="https://www.rfc-editor.org/info/rfcY
YYG">
<front> <front>
<title>Indicating Exclusive Support of RTP/RTCP Multiplexing using S <title>Indicating Exclusive Support of RTP/RTCP Multiplexing Using
DP</title> the Session Description Protocol (SDP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-mux-exclu <seriesInfo name="RFC" value="YYYG"/>
sive-12"/> <seriesInfo name="DOI" value="10.17487/RFCYYYG"/>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" > <author initials="C" surname="Holmberg" fullname="Christer Holmberg" >
<organization/> <organization/>
</author> </author>
<date month="May" day="5" year="2017"/> <date month="May" year="2020"/>
<abstract>
<t>This document defines a new SDP media-level attribute, 'rtcp-mu
x- only', that can be used by an endpoint to indicate exclusive support of RTP/R
TCP multiplexing. The document also updates RFC 5761, by clarifying that an off
erer can use a mechanism to indicate that it is not able to send and receive RTC
P on separate ports.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-rid" target="http://www.ietf.org/inte
rnet-drafts/draft-ietf-mmusic-rid-15.txt"> <!-- draft-ietf-mmusic-rid (RFC YYYC) -->
<reference anchor="RFCYYYC" target="https://www.rfc-editor.org/info/rfcY
YYC">
<front> <front>
<title>RTP Payload Format Restrictions</title> <title>RTP Payload Format Restrictions</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-rid-15"/> <seriesInfo name="RFC" value="YYYC"/>
<author initials="A" surname="Roach" fullname="Adam Roach"> <seriesInfo name="DOI" value="10.17487/RFCYYYC"/>
<author initials="A.B." surname="Roach" fullname="Adam Roach" role="
editor">
<organization/> <organization/>
</author> </author>
<date month="May" day="15" year="2018"/> <date month="May" year="2020"/>
<abstract>
<t>In this specification, we define a framework for specifying res
trictions on RTP streams in the Session Description Protocol. This framework def
ines a new "rid" ("restriction identifier") SDP attribute to unambiguously ident
ify the RTP Streams within an RTP Session and restrict the streams' payload form
at parameters in a codec-agnostic way beyond what is provided with the regular P
ayload Types. This specification updates RFC4855 to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to the restricti
ons defined by this document.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-sctp-sdp" target="http://www.ietf.org
/internet-drafts/draft-ietf-mmusic-sctp-sdp-26.txt"> <!-- draft-ietf-mmusic-sctp-sdp (RFC YYY9) -->
<reference anchor="RFCYYY9" target="https://www.rfc-editor.org/info/rfcY
YY9">
<front> <front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures Fo <title>Session Description Protocol (SDP) Offer/Answer Procedures
r Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Secu for Stream Control Transmission Protocol (SCTP) over Datagram
rity (DTLS) Transport.</title> Transport Layer Security (DTLS) Transport</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sctp-sdp- <seriesInfo name="RFC" value="YYY9"/>
26"/> <seriesInfo name="DOI" value="10.17487/RFCYYY9"/>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" > <author initials="C" surname="Holmberg" fullname="Christer Holmberg" >
<organization/> <organization/>
</author> </author>
<author initials="R" surname="Shpount" fullname="Roman Shpount"> <author initials="R.S." surname="Shpount" fullname="Roman Shpount">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<organization/> <organization/>
</author> </author>
<author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo "> <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo ">
<organization/> <organization/>
</author> </author>
<date month="April" day="20" year="2017"/> <date month="May" year="2020"/>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) is a transport
protocol used to establish associations between two endpoints. draft-ietf-tsvwg-
sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transp
ort Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specifi
cation defines the following new Session Description Protocol (SDP) protocol ide
ntifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification
also specifies how to use the new proto values with the SDP Offer/Answer mechan
ism for negotiating SCTP-over-DTLS associations.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-sdp-bundle-negotiation" target="http:
//www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-54.txt"> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC YYYB) -->
<reference anchor="RFCYYYB" target="https://www.rfc-editor.org/info/rfcY
YYB">
<front> <front>
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title> <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sdp-bundl <seriesInfo name="RFC" value="YYYB"/>
e-negotiation-54"/> <seriesInfo name="DOI" value="10.17487/RFCYYYB"/>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" <author initials="C.H." surname="Holmberg" fullname="Christer Holmbe
> rg">
<organization/> <organization/>
</author> </author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran d"> <author initials="H. T." surname="Alvestrand" fullname="Harald Alves trand">
<organization/> <organization/>
</author> </author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings"> <author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/> <organization/>
</author> </author>
<date month="December" day="14" year="2018"/> <date month="May" year="2020"/>
<abstract>
<t>This specification defines a new Session Description Protocol (
SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the
SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tupl
e) for sending and receiving media described by multiple SDP media descriptions
("m=" sections). Such transport is referred to as a BUNDLE transport, and the m
edia is referred to as bundled media. The "m=" sections that use the BUNDLE tra
nsport form a BUNDLE group. This specification updates RFC 3264, to also allow
assigning a zero port value to a "m=" section in cases where the media described
by the "m=" section is not disabled or rejected. This specification updates RF
C 5888, to also allow an SDP 'group' attribute to contain an identification-tag
that identifies a "m=" section with the port set to zero. This specification de
fines a new RTP Control Protocol (RTCP) source description (SDES) item and a new
RTP header extension that can be used to correlate bundled RTP/RTCP packets wit
h their appropriate "m=" section. This specification updates RFC 7941, by addin
g an exception, for the MID RTP header extension, to the requirement regarding p
rotection of an SDES RTP header extension carrying an SDES item for the MID RTP
header extension.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-sdp-mux-attributes" target="http://ww
w.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-mux-attributes-17.txt"> <!-- draft-ietf-mmusic-sdp-mux-attributes (RFC YYYH) -->
<reference anchor="RFCYYYH" target="https://www.rfc-editor.org/info/rfcY
YYH">
<front> <front>
<title>A Framework for SDP Attributes when Multiplexing</title> <title>A Framework for Session Description Protocol (SDP)
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sdp-mux-a Attributes When Multiplexing</title>
ttributes-17"/> <seriesInfo name="RFC" value="YYYH"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYH"/>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar "> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar ">
<organization/> <organization/>
</author> </author>
<date month="February" day="28" year="2018"/> <date month="May" year="2020"/>
<abstract>
<t>The purpose of this specification is to provide a framework for
analyzing the multiplexing characteristics of Session Description Protocol (SDP
) attributes when SDP is used to negotiate the usage of single 5-tuple for sendi
ng and receiving media associated with multiple media descriptions. This specif
ication also categorizes the existing SDP attributes based on the framework desc
ribed herein.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-sdp-simulcast" target="http://www.iet
f.org/internet-drafts/draft-ietf-mmusic-sdp-simulcast-14.txt"> <!-- draft-ietf-mmusic-sdp-simulcast (RFC YYYE) -->
<reference anchor="RFCYYYE" target="https://www.rfc-editor.org/info/rfcY
YYE">
<front> <front>
<title>Using Simulcast in SDP and RTP Sessions</title> <title>Using Simulcast in Session Description Protocol (SDP) and
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sdp-simul RTP Sessions</title>
cast-14"/> <seriesInfo name="RFC" value="YYYE"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYE"/>
<author initials="B" surname="Burman" fullname="Bo Burman"> <author initials="B" surname="Burman" fullname="Bo Burman">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlun d"> <author initials="M" surname="Westerlund" fullname="Magnus Westerlun d">
<organization/> <organization/>
</author> </author>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar "> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar ">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Zanaty" fullname="Mo Zanaty"> <author initials="M" surname="Zanaty" fullname="Mo Zanaty">
<organization/> <organization/>
</author> </author>
<date month="March" day="5" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>In some application scenarios it may be desirable to send multi
ple differently encoded versions of the same media source in different RTP strea
ms. This is called simulcast. This document describes how to accomplish simulc
ast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP
identification method to identify RTP streams belonging to the same media sourc
e, and makes an extension to SDP to relate those RTP streams as being different
simulcast formats of that media source. The SDP extension consists of a new med
ia level SDP attribute that expresses capability to send and/or receive simulcas
t RTP streams.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-rtcweb-fec" target="http://www.ietf.org/inte
rnet-drafts/draft-ietf-rtcweb-fec-10.txt"> <!-- draft-ietf-rtcweb-fec (RFC YYYF) -->
<reference anchor="RFCYYYF" target="https://www.rfc-editor.org/info/rfcY
YYF">
<front> <front>
<title>WebRTC Forward Error Correction Requirements</title> <title>WebRTC Forward Error Correction Requirements</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-fec-10"/> <seriesInfo name="RFC" value="YYYF"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYF"/>
<author initials="J" surname="Uberti" fullname="Justin Uberti"> <author initials="J" surname="Uberti" fullname="Justin Uberti">
<organization/> <organization/>
</author> </author>
<date month="July" day="16" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>This document provides information and requirements for how For
ward Error Correction (FEC) should be used by WebRTC implementations.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-rtcweb-rtp-usage" target="http://www.ietf.or
g/internet-drafts/draft-ietf-rtcweb-rtp-usage-26.txt"> <!-- draft-ietf-rtcweb-rtp-usage (RFC YYY5) -->
<reference anchor="RFCYYY5" target="https://www.rfc-editor.org/info/rfcY
YY5">
<front> <front>
<title>Web Real-Time Communication (WebRTC): Media Transport and Use of RTP</title> <title>Web Real-Time Communication (WebRTC): Media Transport and Use of RTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-rtp-usage <seriesInfo name="RFC" value="YYY5"/>
-26"/> <seriesInfo name="DOI" value="10.17487/RFCYYY5"/>
<author initials="C" surname="Perkins" fullname="Colin Perkins"> <author initials="C" surname="Perkins" fullname="Colin Perkins">
<organization/> <organization/>
</author> </author>
<author initials="M" surname="Westerlund" fullname="Magnus Westerlun d"> <author initials="M" surname="Westerlund" fullname="Magnus Westerlun d">
<organization/> <organization/>
</author> </author>
<author initials="J" surname="Ott" fullname="Joerg Ott"> <author initials="J" surname="Ott" fullname="Joerg Ott">
<organization/> <organization/>
</author> </author>
<date month="March" day="17" year="2016"/> <date month="May" year="2020"/>
<abstract>
<t>The Web Real-Time Communication (WebRTC) framework provides sup
port for direct interactive rich communication using audio, video, text, collabo
ration, games, etc. between two peers' web-browsers. This memo describes the me
dia transport aspects of the WebRTC framework. It specifies how the Real-time Tr
ansport Protocol (RTP) is used in the WebRTC context, and gives requirements for
which RTP features, profiles, and extensions need to be supported.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-rtcweb-security" target="http://www.ietf.org
/internet-drafts/draft-ietf-rtcweb-security-12.txt"> <!-- draft-ietf-rtcweb-security (RFC YYY1) -->
<reference anchor="RFCYYY1" target="https://www.rfc-editor.org/info/rfcY
YY1">
<front> <front>
<title>Security Considerations for WebRTC</title> <title>Security Considerations for WebRTC</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-security- <seriesInfo name="RFC" value="YYY1"/>
12"/> <seriesInfo name="DOI" value="10.17487/RFCYYY1"/>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla"> <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
<organization/> <organization/>
</author> </author>
<date month="July" day="5" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>WebRTC is a protocol suite for use with real-time applications
that can be deployed in browsers - "real time communication on the Web". This do
cument defines the WebRTC threat model and analyzes the security threats of WebR
TC in that model.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-rtcweb-security-arch" target="http://www.iet
f.org/internet-drafts/draft-ietf-rtcweb-security-arch-20.txt"> <!-- draft-ietf-rtcweb-security-arch (RFC YYY2) -->
<reference anchor="RFCYYY2" target="https://www.rfc-editor.org/info/rfcY
YY2">
<front> <front>
<title>WebRTC Security Architecture</title> <title>WebRTC Security Architecture</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-security- <seriesInfo name="RFC" value="YYY2"/>
arch-20"/> <seriesInfo name="DOI" value="10.17487/RFCYYY2"/>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla"> <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
<organization/> <organization/>
</author> </author>
<date month="July" day="22" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>This document defines the security architecture for WebRTC, a p
rotocol suite intended for use with real-time applications that can be deployed
in browsers - "real time communication on the Web".</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
261">
<front>
<title>SIP: Session Initiation Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
<seriesInfo name="RFC" value="3261"/>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization/>
</author>
<author initials="A." surname="Johnston" fullname="A. Johnston">
<organization/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization/>
</author>
<author initials="R." surname="Sparks" fullname="R. Sparks">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="E." surname="Schooler" fullname="E. Schooler">
<organization/>
</author>
<date year="2002" month="June"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet
telephone calls, multimedia distribution, and multimedia conferences. [STANDARD
S-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
264">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)
</title>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
<seriesInfo name="RFC" value="3264"/>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization/>
</author>
<date year="2002" month="June"/>
<abstract>
<t>This document defines a mechanism by which two entities can mak
e use of the Session Description Protocol (SDP) to arrive at a common view of a
multimedia session between them. In the model, one participant offers the other
a description of the desired session from their perspective, and the other part
icipant answers with the desired session from their perspective. This offer/ans
wer model is most useful in unicast sessions where information from both partici
pants is needed for the complete view of the session. The offer/answer model is
used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK
]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3
552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</t
itle>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="BCP" value="72"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<author initials="B." surname="Korver" fullname="B. Korver">
<organization/>
</author>
<date year="2003" month="July"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section
. Historically, such sections have been relatively weak. This document provides
guidelines to RFC authors on how to write a good Security Considerations sectio
n. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3605" target="https://www.rfc-editor.org/info/rfc3
605">
<front>
<title>Real Time Control Protocol (RTCP) attribute in Session Descri
ption Protocol (SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC3605"/>
<seriesInfo name="RFC" value="3605"/>
<author initials="C." surname="Huitema" fullname="C. Huitema">
<organization/>
</author>
<date year="2003" month="October"/>
<abstract>
<t>The Session Description Protocol (SDP) is used to describe the
parameters of media streams used in multimedia sessions. When a session require
s multiple ports, SDP assumes that these ports have consecutive numbers. Howeve
r, when the session crosses a network address translation device that also uses
port mapping, the ordering of ports can be destroyed by the translation. To han
dle this, we propose an extension attribute to SDP.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3890" target="https://www.rfc-editor.org/info/rfc3
890">
<front>
<title>A Transport Independent Bandwidth Modifier for the Session De
scription Protocol (SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC3890"/>
<seriesInfo name="RFC" value="3890"/>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<date year="2004" month="September"/>
<abstract>
<t>This document defines a Session Description Protocol (SDP) Tran
sport Independent Application Specific Maximum (TIAS) bandwidth modifier that do
es not include transport overhead; instead an additional packet rate attribute i
s defined. The transport independent bit-rate value together with the maximum p
acket rate can then be used to calculate the real bit-rate over the transport ac
tually used. </t>
<t> The existing SDP bandwidth modifiers and their values include
the bandwidth needed for the transport and IP layers. When using SDP with proto
cols like the Session Announcement Protocol (SAP), the Session Initiation Protoc
ol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hos
ts has different transport overhead, for example due to different IP versions, t
he interpretation of what lower layer bandwidths are included is not clear. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4145" target="https://www.rfc-editor.org/info/rfc4
145">
<front>
<title>TCP-Based Media Transport in the Session Description Protocol
(SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC4145"/>
<seriesInfo name="RFC" value="4145"/>
<author initials="D." surname="Yon" fullname="D. Yon">
<organization/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization/>
</author>
<date year="2005" month="September"/>
<abstract>
<t>This document describes how to express media transport over TCP
using the Session Description Protocol (SDP). It defines the SDP 'TCP' protoco
l identifier, the SDP 'setup' attribute, which describes the connection setup pr
ocedure, and the SDP 'connection' attribute, which handles connection reestablis
hment. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
566">
<front>
<title>SDP: Session Description Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC4566"/>
<seriesInfo name="RFC" value="4566"/>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date year="2006" month="July"/>
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of session annou
ncement, session invitation, and other forms of multimedia session initiation.
[STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4
585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<seriesInfo name="DOI" value="10.17487/RFC4585"/>
<seriesInfo name="RFC" value="4585"/>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization/>
</author>
<author initials="S." surname="Wenger" fullname="S. Wenger">
<organization/>
</author>
<author initials="N." surname="Sato" fullname="N. Sato">
<organization/>
</author>
<author initials="C." surname="Burmeister" fullname="C. Burmeister">
<organization/>
</author>
<author initials="J." surname="Rey" fullname="J. Rey">
<organization/>
</author>
<date year="2006" month="July"/>
<abstract>
<t>Real-time media streams that use RTP are, to some degree, resil
ient against packet losses. Receivers may use the base mechanisms of the Real-t
ime Transport Control Protocol (RTCP) to report packet reception statistics and
thus allow a sender to adapt its transmission behavior in the mid-term. This is
the sole means for feedback and feedback-based error repair (besides a few code
c-specific mechanisms). This document defines an extension to the Audio-visual
Profile (AVP) that enables receivers to provide, statistically, more immediate f
eedback to the senders and thus allows for short-term adaptation and efficient f
eedback-based repair mechanisms to be implemented. This early feedback profile
(AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalabilit
y to large groups. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5
124">
<front>
<title>Extended Secure RTP Profile for Real-time Transport Control P
rotocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
<seriesInfo name="DOI" value="10.17487/RFC5124"/>
<seriesInfo name="RFC" value="5124"/>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization/>
</author>
<date year="2008" month="February"/>
<abstract>
<t>An RTP profile (SAVP) for secure real-time communications and a
nother profile (AVPF) to provide timely feedback from the receivers to a sender
are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the com
bination of both profiles to enable secure RTP communications with feedback. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5285" target="https://www.rfc-editor.org/info/rfc5
285">
<front>
<title>A General Mechanism for RTP Header Extensions</title>
<seriesInfo name="DOI" value="10.17487/RFC5285"/>
<seriesInfo name="RFC" value="5285"/>
<author initials="D." surname="Singer" fullname="D. Singer">
<organization/>
</author>
<author initials="H." surname="Desineni" fullname="H. Desineni">
<organization/>
</author>
<date year="2008" month="July"/>
<abstract>
<t>This document provides a general mechanism to use the header ex
tension feature of RTP (the Real-Time Transport Protocol). It provides the opti
on to use a small number of small extensions in each RTP packet, where the unive
rse of possible extensions is large and registration is de-centralized. The act
ual extensions in use in a session are signaled in the setup information for tha
t session. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5
761">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</t
itle>
<seriesInfo name="DOI" value="10.17487/RFC5761"/>
<seriesInfo name="RFC" value="5761"/>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<date year="2010" month="April"/>
<abstract>
<t>This memo discusses issues that arise when multiplexing RTP dat
a packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updat
es RFC 3550 and RFC 3551 to describe when such multiplexing is and is not approp
riate, and it explains how the Session Description Protocol (SDP) can be used to
signal multiplexed sessions. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5888" target="https://www.rfc-editor.org/info/rfc5
888">
<front>
<title>The Session Description Protocol (SDP) Grouping Framework</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC5888"/>
<seriesInfo name="RFC" value="5888"/>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>In this specification, we define a framework to group "m" lines
in the Session Description Protocol (SDP) for different purposes. This framewo
rk uses the "group" and "mid" SDP attributes, both of which are defined in this
specification. Additionally, we specify how to use the framework for two differ
ent purposes: for lip synchronization and for receiving a media flow consisting
of several media streams on different transport addresses. This document obsole
tes RFC 3388. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6236" target="https://www.rfc-editor.org/info/rfc6
236">
<front>
<title>Negotiation of Generic Image Attributes in the Session Descri
ption Protocol (SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC6236"/>
<seriesInfo name="RFC" value="6236"/>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization/>
</author>
<author initials="K." surname="Jung" fullname="K. Jung">
<organization/>
</author>
<date year="2011" month="May"/>
<abstract>
<t>This document proposes a new generic session setup attribute to
make it possible to negotiate different image attributes such as image size. A
possible use case is to make it possible for a \%low-end \%hand- held terminal
to display video without the need to rescale the image, something that may consu
me large amounts of memory and processing power. The document also helps to mai
ntain an optimal bitrate for video as only the image size that is desired by the
receiver is transmitted. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
<seriesInfo name="RFC" value="6347"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization/>
</author>
<date year="2012" month="January"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol. This document updates D
TLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6716" target="https://www.rfc-editor.org/info/rfc6
716">
<front>
<title>Definition of the Opus Audio Codec</title>
<seriesInfo name="DOI" value="10.17487/RFC6716"/>
<seriesInfo name="RFC" value="6716"/>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization/>
</author>
<author initials="K." surname="Vos" fullname="K. Vos">
<organization/>
</author>
<author initials="T." surname="Terriberry" fullname="T. Terriberry">
<organization/>
</author>
<date year="2012" month="September"/>
<abstract>
<t>This document defines the Opus interactive speech and audio cod
ec. Opus is designed to handle a wide range of interactive audio applications, i
ncluding Voice over IP, videoconferencing, in-game chat, and even live, distribu
ted music performances. It scales from low bitrate narrowband speech at 6 kbit/
s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Predic
tion (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good comp
ression of both speech and music. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6904" target="https://www.rfc-editor.org/info/rfc6
904">
<front>
<title>Encryption of Header Extensions in the Secure Real-time Trans
port Protocol (SRTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC6904"/>
<seriesInfo name="RFC" value="6904"/>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization/>
</author>
<date year="2013" month="April"/>
<abstract>
<t>The Secure Real-time Transport Protocol (SRTP) provides authent
ication, but not encryption, of the headers of Real-time Transport Protocol (RTP
) packets. However, RTP header extensions may carry sensitive information for w
hich participants in multimedia sessions want confidentiality. This document pr
ovides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP
header extensions in SRTP.</t>
<t>This document updates RFC 3711, the Secure Real-time Transport
Protocol specification, to require that all future SRTP encryption transforms sp
ecify how RTP header extensions are to be encrypted.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7160" target="https://www.rfc-editor.org/info/rfc7
160">
<front>
<title>Support for Multiple Clock Rates in an RTP Session</title>
<seriesInfo name="DOI" value="10.17487/RFC7160"/>
<seriesInfo name="RFC" value="7160"/>
<author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Hu
guenin">
<organization/>
</author>
<author initials="G." surname="Zorn" fullname="G. Zorn" role="editor
">
<organization/>
</author>
<date year="2014" month="April"/>
<abstract>
<t>This document clarifies the RTP specification regarding the use
of different clock rates in an RTP session. It also provides guidance on how l
egacy RTP implementations that use multiple clock rates can interoperate with RT
P implementations that use the algorithm described in this document. It updates
RFC 3550.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7587" target="https://www.rfc-editor.org/info/rfc7
587">
<front>
<title>RTP Payload Format for the Opus Speech and Audio Codec</title
>
<seriesInfo name="DOI" value="10.17487/RFC7587"/>
<seriesInfo name="RFC" value="7587"/>
<author initials="J." surname="Spittka" fullname="J. Spittka">
<organization/>
</author>
<author initials="K." surname="Vos" fullname="K. Vos">
<organization/>
</author>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization/>
</author>
<date year="2015" month="June"/>
<abstract>
<t>This document defines the Real-time Transport Protocol (RTP) pa
yload format for packetization of Opus-encoded speech and audio data necessary t
o integrate the codec in the most compatible way. It also provides an applicabi
lity statement for the use of Opus over RTP. Further, it describes media type re
gistrations for the RTP payload format.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7742" target="https://www.rfc-editor.org/info/rfc7
742">
<front>
<title>WebRTC Video Processing and Codec Requirements</title>
<seriesInfo name="DOI" value="10.17487/RFC7742"/>
<seriesInfo name="RFC" value="7742"/>
<author initials="A.B." surname="Roach" fullname="A.B. Roach">
<organization/>
</author>
<date year="2016" month="March"/>
<abstract>
<t>This specification provides the requirements and considerations
for WebRTC applications to send and receive video across a network. It specifi
es the video processing that is required as well as video codecs and their param
eters.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7850" target="https://www.rfc-editor.org/info/rfc7
850">
<front>
<title>Registering Values of the SDP 'proto' Field for Transporting
RTP Media over TCP under Various RTP Profiles</title>
<seriesInfo name="DOI" value="10.17487/RFC7850"/>
<seriesInfo name="RFC" value="7850"/>
<author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
<organization/>
</author>
<date year="2016" month="April"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) specification establishe
s a registry of profile names for use by higher-level control protocols, such as
the Session Description Protocol (SDP), to refer to the transport methods. Thi
s specification describes the following new SDP transport protocol identifiers f
or transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAV
PF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/
RTP/AVPF'.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7874" target="https://www.rfc-editor.org/info/rfc7
874">
<front>
<title>WebRTC Audio Codec and Processing Requirements</title>
<seriesInfo name="DOI" value="10.17487/RFC7874"/>
<seriesInfo name="RFC" value="7874"/>
<author initials="JM." surname="Valin" fullname="JM. Valin">
<organization/>
</author>
<author initials="C." surname="Bran" fullname="C. Bran">
<organization/>
</author>
<date year="2016" month="May"/>
<abstract>
<t>This document outlines the audio codec and processing requireme
nts for WebRTC endpoints.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8108" target="https://www.rfc-editor.org/info/rfc8
108">
<front>
<title>Sending Multiple RTP Streams in a Single RTP Session</title>
<seriesInfo name="DOI" value="10.17487/RFC8108"/>
<seriesInfo name="RFC" value="8108"/>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<author initials="Q." surname="Wu" fullname="Q. Wu">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>This memo expands and clarifies the behavior of Real-time Trans
port Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs).
This occurs, for example, when an endpoint sends multiple RTP streams in a sin
gle RTP session. This memo updates RFC 3550 with regard to handling multiple SS
RCs per endpoint in RTP sessions, with a particular focus on RTP Control Protoco
l (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculati
on of the timeout of SSRCs and the inclusion of feedback messages.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8122" target="https://www.rfc-editor.org/info/rfc8
122">
<front>
<title>Connection-Oriented Media Transport over the Transport Layer
Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC8122"/>
<seriesInfo name="RFC" value="8122"/>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>This document specifies how to establish secure connection-orie
nted media transport sessions over the Transport Layer Security (TLS) protocol u
sing the Session Description Protocol (SDP). It defines the SDP protocol identi
fier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerpri
nt' attribute that identifies the certificate that will be presented for the TLS
session. This mechanism allows media transport over TLS connections to be esta
blished securely, so long as the integrity of session descriptions is assured.</
t>
<t>This document obsoletes RFC 4572 by clarifying the usage of mul
tiple fingerprints.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
445">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
<seriesInfo name="RFC" value="8445"/>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization/>
</author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>This document describes a protocol for Network Address Translat
or (NAT) traversal for UDP-based communication. This protocol is called Interac
tive Connectivity Establishment (ICE). ICE makes use of the Session Traversal U
tilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (T
URN).</t>
<t>This document obsoletes RFC 5245.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3
711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
<seriesInfo name="RFC" value="3711"/>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<organization/>
</author>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization/>
</author>
<author initials="M." surname="Naslund" fullname="M. Naslund">
<organization/>
</author>
<author initials="E." surname="Carrara" fullname="E. Carrara">
<organization/>
</author>
<author initials="K." surname="Norrman" fullname="K. Norrman">
<organization/>
</author>
<date year="2004" month="March"/>
<abstract>
<t>This document describes the Secure Real-time Transport Protocol
(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide
confidentiality, message authentication, and replay protection to the RTP traffi
c and to the control traffic for RTP, the Real-time Transport Control Protocol (
RTCP). [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3605.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3890.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4145.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5285.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5761.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5888.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6236.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6716.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7160.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7587.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7742.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7850.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7874.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8108.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8122.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.
xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-rtcweb-ip-handling" target="http://www.ietf. <!-- draft-ietf-rtcweb-ip-handling (RFC YYY3) -->
org/internet-drafts/draft-ietf-rtcweb-ip-handling-12.txt"> <reference anchor="RFCYYY3" target="https://www.rfc-editor.org/info/rfcY
YY3">
<front> <front>
<title>WebRTC IP Address Handling Requirements</title> <title>WebRTC IP Address Handling Requirements</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-ip-handli <seriesInfo name="RFC" value="YYY3"/>
ng-12"/> <seriesInfo name="DOI" value="10.17487/RFCYYY3"/>
<author initials="J" surname="Uberti" fullname="Justin Uberti"> <author initials="J." surname="Uberti" fullname="Justin Uberti">
<organization/> <organization/>
</author> </author>
<date month="July" day="2" year="2019"/> <date month="May" year="2020"/>
<abstract>
<t>This document provides information and requirements for how IP
addresses should be handled by WebRTC implementations.</t>
</abstract>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-mmusic-trickle-ice-sip" target="http://www.i
etf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-18.txt"> <!-- draft-ietf-mmusic-trickle-ice-sip (RFC YYY8) -->
<reference anchor="RFCYYY8" target="https://www.rfc-editor.org/info/rfcY
YY8">
<front> <front>
<title>A Session Initiation Protocol (SIP) Usage for Incremental Pro <title>A Session Initiation Protocol (SIP) Usage for Incremental
visioning of Candidates for the Interactive Connectivity Establishment (Trickle Provisioning of Candidates for the Interactive Connectivity Establish
ICE)</title> ment (Trickle ICE)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-trickle-i <seriesInfo name="RFC" value="YYY8"/>
ce-sip-18"/> <seriesInfo name="DOI" value="10.17487/RFCYYY8"/>
<author initials="E" surname="Ivov" fullname="Emil Ivov"> <author initials="E" surname="Ivov" fullname="Emil Ivov">
<organization/> <organization/>
</author> </author>
<author initials="T" surname="Stach" fullname="Thomas Stach"> <author initials="T" surname="Stach" fullname="Thomas Stach">
<organization/> <organization/>
</author> </author>
<author initials="E" surname="Marocco" fullname="Enrico Marocco"> <author initials="E" surname="Marocco" fullname="Enrico Marocco">
<organization/> <organization/>
</author> </author>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg" <author initials="C.H." surname="Holmberg" fullname="Christer Holmbe
> rg">
<organization/>
</author>
<date month="June" day="23" year="2018"/>
<abstract>
<t>The Interactive Connectivity Establishment (ICE) protocol descr
ibes a Network Address Translator (NAT) traversal mechanism for UDP-based multim
edia sessions established with the Offer/Answer model. The ICE extension for In
cremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allo
ws ICE Agents to shorten session establishment delays by making the candidate ga
thering and connectivity checking phases of ICE non-blocking and by executing th
em in parallel. This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP). The document also defines a new SIP Info Pac
kage to support this usage together with the corresponding media type. Addition
ally, a new SDP 'end-of- candidates' attribute and a new SIP Option Tag 'trickle
-ice' are defined.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-rtcweb-sdp" target="http://www.ietf.org/inte
rnet-drafts/draft-ietf-rtcweb-sdp-11.txt">
<front>
<title>Annotated Example SDP for WebRTC</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-sdp-11"/>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="October" day="9" year="2018"/>
<abstract>
<t>The Real-Time Communications in WEB-browsers (Rtcweb) working g
roup is charged to provide protocol support for direct interactive rich communic
ation using audio, video and data between two peers' web browsers. With in the
Rtcweb framework, Session Description protocol (SDP) is used for negotiating ses
sion capabilities between the peers. Such a negotiation happens based on the SDP
Offer/Answer exchange mechanism. This document provides an informational refer
ence in describing the role of SDP and the Offer/Answer exchange mechanism for t
he most common Rtcweb use-cases.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3389" target="https://www.rfc-editor.org/info/rfc3
389">
<front>
<title>Real-time Transport Protocol (RTP) Payload for Comfort Noise
(CN)</title>
<seriesInfo name="DOI" value="10.17487/RFC3389"/>
<seriesInfo name="RFC" value="3389"/>
<author initials="R." surname="Zopf" fullname="R. Zopf">
<organization/>
</author>
<date year="2002" month="September"/>
</front>
</reference>
<reference anchor="RFC3960" target="https://www.rfc-editor.org/info/rfc3
960">
<front>
<title>Early Media and Ringing Tone Generation in the Session Initia
tion Protocol (SIP)</title>
<seriesInfo name="DOI" value="10.17487/RFC3960"/>
<seriesInfo name="RFC" value="3960"/>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization/>
</author>
<date year="2004" month="December"/>
<abstract>
<t>This document describes how to manage early media in the Sessio
n Initiation Protocol (SIP) using two models: the gateway model and the applicat
ion server model. It also describes the inputs one needs to consider in definin
g local policies for ringing tone generation. This memo provides information fo
r the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4568" target="https://www.rfc-editor.org/info/rfc4
568">
<front>
<title>Session Description Protocol (SDP) Security Descriptions for
Media Streams</title>
<seriesInfo name="DOI" value="10.17487/RFC4568"/>
<seriesInfo name="RFC" value="4568"/>
<author initials="F." surname="Andreasen" fullname="F. Andreasen">
<organization/>
</author>
<author initials="M." surname="Baugher" fullname="M. Baugher">
<organization/>
</author>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization/>
</author>
<date year="2006" month="July"/>
<abstract>
<t>This document defines a Session Description Protocol (SDP) cryp
tographic attribute for unicast media streams. The attribute describes a crypto
graphic key and other parameters that serve to configure security for a unicast
media stream in either a single message or a roundtrip exchange. The attribute
can be used with a variety of SDP media transports, and this document defines ho
w to use it for the Secure Real-time Transport Protocol (SRTP) unicast media str
eams. The SDP crypto attribute requires the services of a data security protoco
l to secure the SDP message. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4588" target="https://www.rfc-editor.org/info/rfc4
588">
<front>
<title>RTP Retransmission Payload Format</title>
<seriesInfo name="DOI" value="10.17487/RFC4588"/>
<seriesInfo name="RFC" value="4588"/>
<author initials="J." surname="Rey" fullname="J. Rey">
<organization/>
</author>
<author initials="D." surname="Leon" fullname="D. Leon">
<organization/>
</author>
<author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
<organization/>
</author>
<author initials="V." surname="Varsa" fullname="V. Varsa">
<organization/>
</author>
<author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
<organization/>
</author>
<date year="2006" month="July"/>
<abstract>
<t>RTP retransmission is an effective packet loss recovery techniq
ue for real-time applications with relaxed delay bounds. This document describe
s an RTP payload format for performing retransmissions. Retransmitted RTP packet
s are sent in a separate stream from the original RTP stream. It is assumed tha
t feedback from receivers to senders is available. In particular, it is assumed
that Real-time Transport Control Protocol (RTCP) feedback as defined in the ext
ended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in thi
s memo. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4733" target="https://www.rfc-editor.org/info/rfc4
733">
<front>
<title>RTP Payload for DTMF Digits, Telephony Tones, and Telephony S
ignals</title>
<seriesInfo name="DOI" value="10.17487/RFC4733"/>
<seriesInfo name="RFC" value="4733"/>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization/>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor">
<organization/>
</author>
<date year="2006" month="December"/>
<abstract>
<t>This memo describes how to carry dual-tone multifrequency (DTMF
) signalling, other tone signals, and telephony events in RTP packets. It obsole
tes RFC 2833.</t>
<t>This memo captures and expands upon the basic framework defined
in RFC 2833, but retains only the most basic event codes. It sets up an IANA r
egistry to which other event code assignments may be added. Companion documents
add event codes to this registry relating to modem, fax, text telephony, and cha
nnel-associated signalling events. The remainder of the event codes defined in R
FC 2833 are conditionally reserved in case other documents revive their use.</t>
<t>This document provides a number of clarifications to the origin
al document. However, it specifically differs from RFC 2833 by removing the req
uirement that all compliant implementations support the DTMF events. Instead, c
ompliant implementations taking part in out-of-band negotiations of media stream
content indicate what events they support. This memo adds three new procedures
to the RFC 2833 framework: subdivision of long events into segments, reporting
of multiple events in a single packet, and the concept and reporting of state ev
ents. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5245" target="https://www.rfc-editor.org/info/rfc5
245">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<seriesInfo name="DOI" value="10.17487/RFC5245"/>
<seriesInfo name="RFC" value="5245"/>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<date year="2010" month="April"/>
<abstract>
<t>This document describes a protocol for Network Address Translat
or (NAT) traversal for UDP-based multimedia sessions established with the offer/
answer model. This protocol is called Interactive Connectivity Establishment (I
CE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol a
nd its extension, Traversal Using Relay NAT (TURN). ICE can be used by any prot
ocol utilizing the offer/answer model, such as the Session Initiation Protocol (
SIP). [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5506" target="https://www.rfc-editor.org/info/rfc5
506">
<front>
<title>Support for Reduced-Size Real-Time Transport Control Protocol
(RTCP): Opportunities and Consequences</title>
<seriesInfo name="DOI" value="10.17487/RFC5506"/>
<seriesInfo name="RFC" value="5506"/>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<date year="2009" month="April"/>
<abstract>
<t>This memo discusses benefits and issues that arise when allowin
g Real-time Transport Protocol (RTCP) packets to be transmitted with reduced siz
e. The size can be reduced if the rules on how to create compound packets outli
ned in RFC 3550 are removed or changed. Based on that analysis, this memo defin
es certain changes to the rules to allow feedback messages to be sent as Reduced
-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time T
ransport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This
document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5576" target="https://www.rfc-editor.org/info/rfc5
576">
<front>
<title>Source-Specific Media Attributes in the Session Description P
rotocol (SDP)</title>
<seriesInfo name="DOI" value="10.17487/RFC5576"/>
<seriesInfo name="RFC" value="5576"/>
<author initials="J." surname="Lennox" fullname="J. Lennox">
<organization/>
</author>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization/>
</author>
<author initials="T." surname="Schierl" fullname="T. Schierl">
<organization/>
</author>
<date year="2009" month="June"/>
<abstract>
<t>The Session Description Protocol (SDP) provides mechanisms to d
escribe attributes of multimedia sessions and of individual media streams (e.g.,
Real-time Transport Protocol (RTP) sessions) within a multimedia session, but d
oes not provide any mechanism to describe individual media sources within a medi
a stream. This document defines a mechanism to describe RTP media sources, whic
h are identified by their synchronization source (SSRC) identifiers, in SDP, to
associate attributes with these sources, and to express relationships among sour
ces. It also defines several source-level attributes that can be used to descri
be properties of media sources. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5
763">
<front>
<title>Framework for Establishing a Secure Real-time Transport Proto
col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC5763"/>
<seriesInfo name="RFC" value="5763"/>
<author initials="J." surname="Fischl" fullname="J. Fischl">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2010" month="May"/>
<abstract>
<t>This document specifies how to use the Session Initiation Proto
col (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security con
text using the Datagram Transport Layer Security (DTLS) protocol. It describes
a mechanism of transporting a fingerprint attribute in the Session Description P
rotocol (SDP) that identifies the key that will be presented during the DTLS han
dshake. The key exchange travels along the media path as opposed to the signali
ng path. The SIP Identity mechanism can be used to protect the integrity of the
fingerprint attribute from modification by intermediate proxies. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5
764">
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establi
sh Keys for the Secure Real-time Transport Protocol (SRTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC5764"/>
<seriesInfo name="RFC" value="5764"/>
<author initials="D." surname="McGrew" fullname="D. McGrew">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2010" month="May"/>
<abstract>
<t>This document describes a Datagram Transport Layer Security (DT
LS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Pro
tocol (SRTCP) flows. DTLS keying happens on the media path, independent of any
out-of-band signalling channel present. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6
464">
<front>
<title>A Real-time Transport Protocol (RTP) Header Extension for Cli
ent-to-Mixer Audio Level Indication</title>
<seriesInfo name="DOI" value="10.17487/RFC6464"/>
<seriesInfo name="RFC" value="6464"/>
<author initials="J." surname="Lennox" fullname="J. Lennox" role="ed
itor">
<organization/>
</author>
<author initials="E." surname="Ivov" fullname="E. Ivov">
<organization/>
</author>
<author initials="E." surname="Marocco" fullname="E. Marocco">
<organization/>
</author>
<date year="2011" month="December"/>
<abstract>
<t>This document defines a mechanism by which packets of Real-time
Transport Protocol (RTP) audio streams can indicate, in an RTP header extension
, the audio level of the audio sample carried in the RTP packet. In large confe
rences, this can reduce the load on an audio mixer or other middlebox that wants
to forward only a few of the loudest audio streams, without requiring it to dec
ode and measure every stream that is received. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6544" target="https://www.rfc-editor.org/info/rfc6
544">
<front>
<title>TCP Candidates with Interactive Connectivity Establishment (I
CE)</title>
<seriesInfo name="DOI" value="10.17487/RFC6544"/>
<seriesInfo name="RFC" value="6544"/>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/>
</author>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization/>
</author>
<author initials="B. B." surname="Lowekamp" fullname="B. B. Lowekamp
">
<organization/>
</author>
<author initials="A. B." surname="Roach" fullname="A. B. Roach">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>Interactive Connectivity Establishment (ICE) defines a mechanis
m for NAT traversal for multimedia communication protocols based on the offer/an
swer model of session negotiation. ICE works by providing a set of candidate tr
ansport addresses for each media stream, which are then validated with peer-to-p
eer connectivity checks based on Session Traversal Utilities for NAT (STUN). IC
E provides a general framework for describing candidates but only defines UDP-ba
sed media streams. This specification extends ICE to TCP-based media, including
the ability to offer a mix of TCP and UDP-based candidates for a single stream.
[STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3556" target="https://www.rfc-editor.org/info/rfc3
556">
<front>
<title>Session Description Protocol (SDP) Bandwidth Modifiers for RT
P Control Protocol (RTCP) Bandwidth</title>
<seriesInfo name="DOI" value="10.17487/RFC3556"/>
<seriesInfo name="RFC" value="3556"/>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization/> <organization/>
</author> </author>
<date year="2003" month="July"/> <date month="May" year="2020"/>
<abstract>
<t>This document defines an extension to the Session Description P
rotocol (SDP) to specify two additional modifiers for the bandwidth attribute. T
hese modifiers may be used to specify the bandwidth allowed for RTP Control Prot
ocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS
-TRACK]</t>
</abstract>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-rtcweb-sdp.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3389.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4588.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4733.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5245.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5506.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5576.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6544.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3556.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3960.
xml"/>
<reference anchor="W3C.webrtc" target="https://www.w3.org/TR/2017/WD-web rtc-20170515/"> <reference anchor="W3C.webrtc" target="https://www.w3.org/TR/2017/WD-web rtc-20170515/">
<front> <front>
<title>WebRTC 1.0: Real-time Communication Between <title>WebRTC 1.0: Real-time Communication Between
Browsers</title> Browsers</title>
<seriesInfo name="World Wide Web Consortium WD" value="WD-webrtc-201 70515"/>
<author fullname="Adam Bergkvist" initials="A." surname="Bergkvist"> <author fullname="Adam Bergkvist" initials="A." surname="Bergkvist">
<organization>Ericsson</organization> <organization>Ericsson</organization>
</author> </author>
<author fullname="Daniel C. Burnett" initials="D." surname="Burnett" > <author fullname="Daniel C. Burnett" initials="D." surname="Burnett" >
<organization/> <organization/>
</author> </author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings"> <author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization> <organization>Cisco</organization>
</author> </author>
<author fullname="Anant Narayanan" initials="A." surname="Narayanan" > <author fullname="Anant Narayanan" initials="A." surname="Narayanan" >
<organization>Mozilla</organization> <organization>Mozilla</organization>
</author> </author>
<author fullname="Bernard Aboba" initials="B." surname="Aboba"> <author fullname="Bernard Aboba" initials="B." surname="Aboba">
<organization>Microsoft Corporation</organization> <organization>Microsoft Corporation</organization>
</author> </author>
<author fullname="Taylor Brandstetter" initials="T." surname="Brands tetter"> <author fullname="Taylor Brandstetter" initials="T." surname="Brands tetter">
<organization>Google</organization> <organization>Google</organization>
</author> </author>
<date day="15" month="May" year="2017"/> <date month="May" year="2017"/>
</front> </front>
<refcontent>World Wide Web Consortium WD WD-webrtc-20170515</refcont ent>
</reference> </reference>
<reference anchor="TS26.114" target="http://www.3gpp.org/DynaReport/2611 4.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 Group Services and System Aspects; IP Specification Group Services and System Aspects; IP
Multimedia Subsystem (IMS); Multimedia Telephony; Media Multimedia Subsystem (IMS); Multimedia Telephony; Media
handling and interaction (Release 12)</title> handling and interaction (Release 12)</title>
<seriesInfo name="3GPP TS" value="26.114 V12.8.0"/>
<author> <author>
<organization>3GPP TS 26.114 V12.8.0</organization> <organization>3GPP</organization>
</author> </author>
<date year="2014" month="December"/> <date year="2014" month="December"/>
</front> </front>
</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>Appendix A</name> <name>Appendix A</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
skipping to change at line 5806 skipping to change at line 5011
<thead> <thead>
<tr> <tr>
<th align="left">Attribute</th> <th align="left">Attribute</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ptime</td> <td align="left">ptime</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">maxptime</td> <td align="left">maxptime</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rtpmap</td> <td align="left">rtpmap</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">recvonly</td> <td align="left">recvonly</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">sendrecv</td> <td align="left">sendrecv</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">sendonly</td> <td align="left">sendonly</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">inactive</td> <td align="left">inactive</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">framerate</td> <td align="left">framerate</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">fmtp</td> <td align="left">fmtp</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">quality</td> <td align="left">quality</td>
<td align="left"> <td align="left">
<xref target="RFC4566" format="default"/> Section 9</td> <xref target="RFC4566" sectionFormat="of" section="9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rtcp</td> <td align="left">rtcp</td>
<td align="left"> <td align="left">
<xref target="RFC3605" format="default"/> 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" format="default"/> Sections 3, 4, and 5</td Sections <xref target="RFC4145" section="3"
> sectionFormat="bare"/>,
<xref target="RFC4145" section="4" sectionFormat="bare"/>, and
<xref target="RFC4145" section="5" sectionFormat="bare"/> of
<xref target="RFC4145"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">connection</td> <td align="left">connection</td>
<td align="left"> <td align="left">
<xref target="RFC4145" format="default"/> Sections 3, 4, and 5</td Sections <xref target="RFC4145" section="3"
> sectionFormat="bare"/>,
<xref target="RFC4145" section="4" sectionFormat="bare"/>, and
<xref target="RFC4145" section="5" sectionFormat="bare"/> of
<xref target="RFC4145"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">fingerprint</td> <td align="left">fingerprint</td>
<td align="left"> <td align="left">
<xref target="RFC8122" format="default"/> Section 5</td> <xref target="RFC8122" sectionFormat="of" section="5"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rtcp-fb</td> <td align="left">rtcp-fb</td>
<td align="left"> <td align="left">
<xref target="RFC4585" format="default"/> Section 4.2</td> <xref target="RFC4585" sectionFormat="of" section="4.2"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">extmap</td> <td align="left">extmap</td>
<td align="left"> <td align="left">
<xref target="RFC5285" format="default"/> Section 7</td> <xref target="RFC5285" sectionFormat="of" section="7"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">mid</td> <td align="left">mid</td>
<td align="left"> <td align="left">
<xref target="RFC5888" format="default"/> Sections 4 and 5</td> Sections <xref target="RFC5888" section="4"
sectionFormat="bare"/> and
<xref target="RFC5888" section="5" sectionFormat="bare"/> of
<xref target="RFC5888"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">group</td> <td align="left">group</td>
<td align="left"> <td align="left">
<xref target="RFC5888" format="default"/> Sections 4 and 5</td> Sections <xref target="RFC5888" section="4"
sectionFormat="bare"/> and
<xref target="RFC5888" section="5" sectionFormat="bare"/> of
<xref target="RFC5888"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">imageattr</td> <td align="left">imageattr</td>
<td align="left"> <td align="left">
<xref target="RFC6236" format="default"/> Section 3.1</td> <xref target="RFC6236" sectionFormat="of" section="3.1"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">extmap (encrypt option)</td> <td align="left">extmap (encrypt option)</td>
<td align="left"> <td align="left">
<xref target="RFC6904" format="default"/> Section 4</td> <xref target="RFC6904" sectionFormat="of" section="4"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">candidate</td> <td align="left">candidate</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.1</td> <xref target="RFCYYY7" sectionFormat="of" section="4.1"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">remote-candidates</td> <td align="left">remote-candidates</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.2</td> <xref target="RFCYYY7" sectionFormat="of" section="4.2"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ice-lite</td> <td align="left">ice-lite</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.3</td> <xref target="RFCYYY7" sectionFormat="of" section="4.3"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ice-ufrag</td> <td align="left">ice-ufrag</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.4</td> <xref target="RFCYYY7" sectionFormat="of" section="4.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ice-pwd</td> <td align="left">ice-pwd</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.4</td> <xref target="RFCYYY7" sectionFormat="of" section="4.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ice-options</td> <td align="left">ice-options</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-ice-sip-sdp" format="default"/> Sect ion 4.6</td> <xref target="RFCYYY7" sectionFormat="of" section="4.6"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">msid</td> <td align="left">msid</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-msid" format="default"/> Section 2</ td> <xref target="RFCYYY4" sectionFormat="of" section="2"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">rid</td> <td align="left">rid</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-rid" format="default"/> Section 10</ td> <xref target="RFCYYYC" sectionFormat="of" section="10"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">simulcast</td> <td align="left">simulcast</td>
<td align="left"> <td align="left">
<xref target="I-D.ietf-mmusic-sdp-simulcast" format="default"/> Se ction 6.1</td> <xref target="RFCYYYE" sectionFormat="of" section="6.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="I-D.ietf-mmusic-dtls-sdp" format="default"/> Section 4</td> <xref target="RFCYYYA" sectionFormat="of" section="4"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec.change-log" numbered="true" toc="default"> <section anchor="sec.change-log" numbered="true" toc="default">
<name>Change log</name> <name>Change log</name>
<t>Note to RFC Editor: Please remove this section before <t>Note to RFC Editor: Please remove this section before
publication.</t> publication.</t>
<t>Changes in draft-26:</t> <t>Changes in draft-26:</t>
<ul spacing="normal"> <ul spacing="normal">
 End of changes. 587 change blocks. 
2155 lines changed or deleted 1074 lines changed or added

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