rfc8829v2.xml   rfc8829.xml 
skipping to change at line 42 skipping to change at line 42
<region>AB</region> <region>AB</region>
<code>T2P 4H2</code> <code>T2P 4H2</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>fluffy@iii.ca</email> <email>fluffy@iii.ca</email>
</address> </address>
</author> </author>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla" role="edit or"> <author fullname="Eric Rescorla" initials="E." surname="Rescorla" role="edit or">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<postal>
<street>331 E. Evelyn Ave.</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>United States of America</country>
</postal>
<email>ekr@rtfm.com</email> <email>ekr@rtfm.com</email>
</address> </address>
</author> </author>
<date month="January" year="2021"/> <date month="January" year="2021"/>
<keyword>webrtc</keyword> <keyword>webrtc</keyword>
<keyword>sdp</keyword> <keyword>sdp</keyword>
<keyword>negotiation</keyword> <keyword>negotiation</keyword>
<keyword>signaling</keyword> <keyword>signaling</keyword>
skipping to change at line 133 skipping to change at line 126
<t>To complete the offer/answer exchange, the remote party uses <t>To complete the offer/answer exchange, the remote party uses
the createAnswer API to generate an appropriate answer, the createAnswer API to generate an appropriate answer,
applies it using the setLocalDescription API, and sends the applies it using the setLocalDescription API, and sends the
answer back to the initiator over the signaling channel. When answer back to the initiator over the signaling channel. When
the initiator gets that answer, it installs it using the the initiator gets that answer, it installs it using the
setRemoteDescription API, and initial setup is complete. This setRemoteDescription API, and initial setup is complete. This
process can be repeated for additional offer/answer process can be repeated for additional offer/answer
exchanges.</t> exchanges.</t>
<t>Regarding ICE <t>Regarding ICE
<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. 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="RFC8840" format="default"/> allows SIP to <xref target="RFC8840" format="default"/> allows SIP to
be used with Trickle ICE be used with Trickle ICE
<xref target="RFC8838" format="default"/>, in which the session <xref target="RFC8838" format="default"/>, in which the session
skipping to change at line 167 skipping to change at line 160
descriptions and ICE information into the defined messages of descriptions and ICE information into the defined messages of
its chosen signaling protocol, and perform the reverse its chosen signaling protocol, and perform the reverse
conversion on the messages it receives from the other side.</t> conversion on the messages it receives from the other side.</t>
<t>One way to make life easier for the application is to <t>One way to make life easier for the application is to
provide a JavaScript library that hides this complexity from provide a JavaScript library that hides this complexity from
the developer; said library would implement a given signaling the developer; said library would implement a given signaling
protocol along with its state machine and serialization code, protocol along with its state machine and serialization code,
presenting a higher-level call-oriented interface to the presenting a higher-level call-oriented interface to the
application developer. For example, libraries exist to provide application developer. For example, libraries exist to provide
implementations of the SIP <xref target="RFC3261"/> and Extensible Messa ging implementations of the SIP <xref target="RFC3261"/> and Extensible Messa ging
and Presence Protocol (XMPP) <xref target="RFC6120"/> signaling and Presence Protocol (XMPP) <xref target="RFC6120"/> signaling
protocols atop the JSEP API. protocols atop the JSEP API.
Thus, JSEP Thus, JSEP
provides greater control for the experienced developer without provides greater control for the experienced developer without
forcing any additional complexity on the novice developer.</t> forcing any additional complexity on the novice developer.</t>
</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
skipping to change at line 215 skipping to change at line 208
its own session descriptions. This increases the amount of work its own session descriptions. This increases the amount of work
that the application needs to do; it needs to know how to that the application needs to do; it needs to know how to
generate session descriptions from capabilities, and especially generate session descriptions from capabilities, and especially
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>
<name>Contradiction regarding bundle-only "m=" sections</name>
<t>Since the approval of the WebRTC specification documents, the IETF has become
aware of an inconsistency between the document specifying JSEP and the document
specifying BUNDLE (this RFC and <xref target="RFC8843"/>, respectively). Rather
than delaying publication further to come to a resolution, the documents are be
ing published as they were originally approved. The IETF intends to restart wor
k on these technologies, and revised versions of these documents will be publish
ed as soon as a resolution becomes available.</t>
<t>The specific issue involves the handling of "m=" sections that are designated
as bundle-only, as discussed in <xref target="sec.pc-constructor"/> of this RFC
. Currently, there is divergence between JSEP and BUNDLE, as well as between the
se specifications and existing browser implementations:</t>
<ul>
<li>JSEP prescribes that said "m=" sections should use port zero and add an "a
=bundle-only" attribute in initial offers, but not in answers or subsequent offe
rs.</li>
<li>BUNDLE prescribes that these "m=" sections should be marked as described i
n the previous point, but in all offers and answers.</li>
<li>Most current browsers do not mark any "m=" sections with port zero and ins
tead use the same port for all bundled "m=" sections; one follows the JSEP behav
ior.</li>
</ul>
</section>
</section> </section>
<section anchor="sec.terminology" numbered="true" toc="default"> <section anchor="sec.terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
skipping to change at line 346 skipping to change at line 350
known. These "resources" can include things like extra ICE known. These "resources" can include things like extra ICE
components, Traversal Using Relays around NAT (TURN) candidates, or vide o decoders. Provisional components, Traversal Using Relays around NAT (TURN) candidates, or vide o decoders. Provisional
answers, on the other hand, do no such deallocation; as a answers, on the other hand, do no such deallocation; as a
result, multiple dissimilar provisional answers, with their own result, multiple dissimilar provisional answers, with their own
codec choices, transport parameters, etc., can be received and codec choices, transport parameters, etc., can be received and
applied during call setup. Note that the final answer itself applied during call setup. Note that the final answer itself
may be different than any received provisional answers.</t> may be different than any received provisional answers.</t>
<t>In <t>In
<xref target="RFC3264" format="default"/>, the constraint at the signali ng <xref target="RFC3264" format="default"/>, the constraint at the signali ng
level is that only one offer can be outstanding for a given level is that only one offer can be outstanding for a given
session, but at the media stack level, a new offer can be session, but at the JSEP level, a new offer can be
generated at any point. For example, when using SIP for generated at any point. For example, when using SIP for
signaling, if one offer is sent and is then canceled using a SIP signaling, if one offer is sent and is then canceled using a SIP
CANCEL, another offer can be generated even though no answer CANCEL, another offer can be generated even though no answer
was received for the first offer. To support this, the JSEP was received for the first offer. To support this, the JSEP
media layer can provide an offer via the createOffer method media layer can provide an offer via the createOffer method
whenever the JavaScript application needs one for the whenever the JavaScript application needs one for the
signaling. The answerer can send back zero or more provisional signaling. The answerer can send back zero or more provisional
answers and then finally end the offer/answer exchange by sending a answers and then finally end the offer/answer exchange by sending a
final answer. The state machine for this is as follows:</t> final answer. The state machine for this is as follows:</t>
<figure anchor="fig-state-machine"> <figure anchor="fig-state-machine">
skipping to change at line 723 skipping to change at line 727
<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
<bcp14>RECOMMENDED</bcp14>. However, when the supported video codecs h ave <bcp14>RECOMMENDED</bcp14>. However, when the supported video codecs h ave
different limitations, specific "a=imageattr" attributes <bcp14>MUST</ bcp14> 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> <sourcecode type="sdp"><![CDATA[
a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]
]]></sourcecode>
<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>
<section anchor="sec.interpreting-imageattr" numbered="true" toc="defaul t"> <section anchor="sec.interpreting-imageattr" numbered="true" toc="defaul t">
<name>Interpreting imageattr Attributes</name> <name>Interpreting imageattr Attributes</name>
<t> <t>
<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
skipping to change at line 1220 skipping to change at line 1226
or stop flowing. Specifically, the offer is not applied, and or stop flowing. Specifically, the offer is not applied, and
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 an SDP answer per <xref target="RFC3264" format="default"/> w ith the supported contains an SDP answer per <xref target="RFC3264" format="default"/> w ith the supported
configuration for the session that is compatible with the configuration for the session that is compatible with the
parameters supplied in the most recent call to parameters supplied in the most recent call to
setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to setRemoteDescription; setRemoteDescription <bcp14>MUST</bcp14> have be en called prior to
calling createAnswer. Like createOffer, the returned blob calling createAnswer. Like createOffer, the returned blob
contains descriptions of the media added to this contains descriptions of the media added to this
PeerConnection, the codec/RTP/RTCP options negotiated for PeerConnection, the codec/RTP/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
<bcp14>MUST</bcp14> follow the process defined for generating an answe r from <bcp14>MUST</bcp14> follow the process defined for generating an answe r from
skipping to change at line 1552 skipping to change at line 1558
ICE candidate generation. However, if both fields are null ICE candidate generation. However, if both fields are null
for a new remote candidate, this <bcp14>MUST</bcp14> be treated as an for a new remote candidate, this <bcp14>MUST</bcp14> be treated as an
invalid condition, as specified below.</t> invalid condition, as specified below.</t>
<t>If any IceCandidate fields contain invalid values or an <t>If any IceCandidate fields contain invalid values or an
error occurs during the processing of the IceCandidate error occurs during the processing of the IceCandidate
object, the supplied IceCandidate <bcp14>MUST</bcp14> be ignored and a n object, the supplied IceCandidate <bcp14>MUST</bcp14> be ignored and a n
error <bcp14>MUST</bcp14> be returned.</t> error <bcp14>MUST</bcp14> be returned.</t>
<t>Otherwise, the new remote candidate or end-of-candidates <t>Otherwise, the new remote candidate or end-of-candidates
indication is supplied to the ICE agent. In the case of a new indication is supplied to the ICE agent. In the case of a new
remote candidate, connectivity checks will be sent to the new remote candidate, connectivity checks will be sent to the new
candidate.</t> candidate, assuming setLocalDescription has already been
called to initialize the ICE gathering process.</t>
</section> </section>
<section anchor="sec.onicecandidate" numbered="true" toc="default"> <section anchor="sec.onicecandidate" numbered="true" toc="default">
<name>onicecandidate Event</name> <name>onicecandidate Event</name>
<t>The onicecandidate event is dispatched to the application in two <t>The onicecandidate event is dispatched to the application in two
situations: (1) when the ICE agent has discovered a new allowed local situations: (1) when the ICE agent has discovered a new allowed local
ICE candidate during ICE gathering, as outlined in ICE candidate during ICE gathering, as outlined in
<xref target="sec.ice-gather-overview" format="default"></xref> and <xref target="sec.ice-gather-overview" format="default"></xref> and
subject to the restrictions discussed in subject to the restrictions discussed in
<xref target="sec.ice-candidate-policy" format="default"></xref>, or <xref target="sec.ice-candidate-policy" format="default"></xref>, or
(2) when an ICE gathering phase completes. The event contains a single (2) when an ICE gathering phase completes. The event contains a single
skipping to change at line 1856 skipping to change at line 1863
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" sectionFormat="comma" 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,
<bcp14>MUST</bcp14> generate a unique set of ICE credentials and gathe <bcp14>MUST</bcp14> contain a unique set of ICE credentials and
r its a unique set of ICE candidates. Bundle-only "m=" sections
own unique set of ICE candidates. Bundle-only "m=" sections
<bcp14>MUST NOT</bcp14> contain any ICE credentials and <bcp14>MUST NO T</bcp14> 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 <bcp14>MUST</bcp14> use any and all cer tificates <t>For DTLS, all "m=" sections <bcp14>MUST</bcp14> use any and all cer tificates
that have been specified for the PeerConnection; as a result, that have been specified for the PeerConnection; as a result,
they <bcp14>MUST</bcp14> all have the same fingerprint value or values they <bcp14>MUST</bcp14> all have the same fingerprint value or values
<xref target="RFC8122" format="default"/>, or these <xref target="RFC8122" format="default"/>, or these
values <bcp14>MUST</bcp14> be session-level attributes.</t> values <bcp14>MUST</bcp14> be session-level attributes.</t>
<t>Each "m=" section <bcp14>MUST</bcp14> be generated as specified in <t>Each "m=" section <bcp14>MUST</bcp14> be generated as specified in
<xref target="RFC4566" sectionFormat="comma" section="5.14"/>. For the "m=" line <xref target="RFC4566" sectionFormat="comma" section="5.14"/>. For the "m=" line
itself, the following rules <bcp14>MUST</bcp14> be followed: itself, the following rules <bcp14>MUST</bcp14> be followed:
skipping to change at line 2466 skipping to change at line 2473
<sourcecode name="" type="sdp"><![CDATA[ <sourcecode name="" type="sdp"><![CDATA[
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0 m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1 a=mid:a1
a=recvonly a=recvonly
m=video 20001 UDP/TLS/RTP/SAVPF 96 m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1 a=mid:v1
a=recvonly ]]></sourcecode> a=recvonly ]]></sourcecode>
<t>The example in <xref target="sec.detailed-example" format="default" /> shows a more involved case of "LS" group <t>The example in <xref target="sec.detailed-example" format="default" /> shows a more involved case of "LS" group
generation.</t> generation.</t>
<t>The next step is to generate "m=" sections for each "m=" <t>The next step is to generate an "m=" section for each "m="
section that is present in the remote offer, as specified in section that is present in the remote offer, as specified in
<xref target="RFC3264" sectionFormat="comma" section="6"/>. For the pu rposes <xref target="RFC3264" sectionFormat="comma" section="6"/>. For the pu rposes
of this discussion, any session-level attributes in the offer of this discussion, any session-level attributes in the offer
that are also valid as media-level attributes are considered that are also valid as media-level attributes are considered
to be present in each "m=" section. Each offered "m=" section to be present in each "m=" section. Each offered "m=" section
will have an associated RtpTransceiver, as described in will have an associated RtpTransceiver, as described in
<xref target="sec.applying-a-remote-desc" format="default"/>. If there are <xref target="sec.applying-a-remote-desc" format="default"/>. If there are
more RtpTransceivers than there are "m=" sections, the more RtpTransceivers than there are "m=" sections, the
unmatched RtpTransceivers will need to be associated in a unmatched RtpTransceivers will need to be associated in a
subsequent offer.</t> subsequent offer.</t>
skipping to change at line 3479 skipping to change at line 3486
associated media formats.</li> associated media formats.</li>
<li> <li>
<t>For any specified "TIAS" ("Transport <t>For any specified "TIAS" ("Transport
Independent Application Specific Maximum") bandwidth value, set this value Independent Application Specific Maximum") bandwidth value, set this 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 empty="true"> <artwork>
<li>TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)</li> TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)
</ul> </artwork>
<t> <t>
The 1000 changes the unit from kbps to bps (as required The 1000 changes the unit from kbps to bps (as required
by TIAS), and the 0.95 is to allocate 5% to RTCP. by TIAS), and the 0.95 is to allocate 5% to RTCP.
An estimate of header overhead is then subtracted out, in which An estimate of header overhead is then subtracted out, in which
the 50 is based on 50 packets per second, the 40 is based on the 50 is based on 50 packets per second, the 40 is based on
typical header size (in bytes), and the 8 converts bytes to bits. typical header size (in bytes), and the 8 converts bytes to bits.
Note that "TIAS" is preferred over Note that "TIAS" is preferred over
"AS" because it provides more accurate "AS" because it provides more accurate
control of bandwidth.</t> control of bandwidth.</t>
</li> </li>
skipping to change at line 3598 skipping to change at line 3605
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 Sections <xref target="RFC3264" section="6.1" as discussed in Sections <xref target="RFC3264" section="6.1"
sectionFormat="bare"/> and <xref target="RFC3264" section="7" sectionFormat=" bare"/> of <xref target="RFC3264"/>, and start sectionFormat="bare"/> and <xref target="RFC3264" section="7" sectionFormat=" bare"/> 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 unique random one. If media is already being
transmitted, the same SSRC <bcp14>SHOULD</bcp14> be used unless th e transmitted, the same SSRC <bcp14>SHOULD</bcp14> be used unless th e
clock rate of the new codec is different, in which case a clock rate of the new codec is different, in which case a
new SSRC <bcp14>MUST</bcp14> be chosen, as specified in new SSRC <bcp14>MUST</bcp14> be chosen, as specified in
<xref target="RFC7160" sectionFormat="comma" section="4.1"/>.</li> <xref target="RFC7160" sectionFormat="comma" section="4.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 the MI D using the extension mapping from the remote description. If the MI D
skipping to change at line 3632 skipping to change at line 3639
<xref target="sec.voiceactivitydetection1" format="default"/>. <xref target="sec.voiceactivitydetection1" format="default"/>.
If these If these
conditions are not met, silence suppression <bcp14>MUST NOT</bcp14 > 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 appropriate numbe r of <li>If simulcast has been negotiated, send the appropriate numbe r of
Source RTP Streams as specified in Source RTP Streams as specified in
<xref target="RFC8853" sectionFormat="comma" section="5.3.3"/>.</l i> <xref target="RFC8853" sectionFormat="comma" section="5.3.3"/>.</l i>
<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 unique 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 clock rate, corresponding "red" media format of the same clock rate,
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="RFC8854" sectionFormat="comma" section="3.2"/>. Note <xref target="RFC8854" 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
 End of changes. 13 change blocks. 
23 lines changed or deleted 42 lines changed or added

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