rfc9429.original   rfc9429.txt 
Network Working Group J. Uberti Internet Engineering Task Force (IETF) J. Uberti
Internet-Draft Request for Comments: 9429
Obsoletes: 8829 (if approved) C. Jennings Obsoletes: 8829 C. Jennings
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: 24 March 2024 E. Rescorla, Ed. ISSN: 2070-1721 E. Rescorla, Ed.
Mozilla Mozilla
21 September 2023 February 2024
JavaScript Session Establishment Protocol (JSEP) JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-05
Abstract Abstract
This document describes the mechanisms for allowing a JavaScript This document describes the mechanisms for allowing a JavaScript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API and via the interface specified in the W3C RTCPeerConnection API and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
This specification obsoletes RFC 8829. This specification obsoletes RFC 8829.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 March 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9429.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP
1.2. Other Approaches Considered . . . . . . . . . . . . . . . 6 1.2. Other Approaches Considered
1.3. Changes from RFC 8829 . . . . . . . . . . . . . . . . . . 7 1.3. Changes from RFC 8829
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology
3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 7 3. Semantics and Syntax
3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 7 3.1. Signaling Model
3.2. Session Descriptions and State Machine . . . . . . . . . 8 3.2. Session Descriptions and State Machine
3.3. Session Description Format . . . . . . . . . . . . . . . 11 3.3. Session Description Format
3.4. Session Description Control . . . . . . . . . . . . . . . 11 3.4. Session Description Control
3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 3.4.1. RtpTransceivers
3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. RtpSenders
3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers
3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE
3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview
3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2. ICE Candidate Trickling
3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 14 3.5.2.1. ICE Candidate Format
3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 15 3.5.3. ICE Candidate Policy
3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.4. ICE Candidate Pool
3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16 3.5.5. ICE Versions
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 17 3.6.1. Creating an imageattr Attribute
3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 18 3.6.2. Interpreting imageattr Attributes
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7. Simulcast
3.8. Interactions with Forking . . . . . . . . . . . . . . . . 20 3.8. Interactions with Forking
3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 21 3.8.1. Sequential Forking
3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 3.8.2. Parallel Forking
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Interface
4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 4.1. PeerConnection
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Constructor
4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 25 4.1.2. addTrack
4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 25 4.1.3. removeTrack
4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25 4.1.4. addTransceiver
4.1.5. onaddtrack Event . . . . . . . . . . . . . . . . . . 26 4.1.5. onaddtrack Event
4.1.6. createDataChannel . . . . . . . . . . . . . . . . . . 26 4.1.6. createDataChannel
4.1.7. ondatachannel Event . . . . . . . . . . . . . . . . . 26 4.1.7. ondatachannel Event
4.1.8. createOffer . . . . . . . . . . . . . . . . . . . . . 26 4.1.8. createOffer
4.1.9. createAnswer . . . . . . . . . . . . . . . . . . . . 27 4.1.9. createAnswer
4.1.10. SessionDescriptionType . . . . . . . . . . . . . . . 28 4.1.10. SessionDescriptionType
4.1.10.1. Use of Provisional Answers . . . . . . . . . . . 29 4.1.10.1. Use of Provisional Answers
4.1.10.2. Rollback . . . . . . . . . . . . . . . . . . . . 30 4.1.10.2. Rollback
4.1.11. setLocalDescription . . . . . . . . . . . . . . . . . 30 4.1.11. setLocalDescription
4.1.12. setRemoteDescription . . . . . . . . . . . . . . . . 31 4.1.12. setRemoteDescription
4.1.13. currentLocalDescription . . . . . . . . . . . . . . . 31 4.1.13. currentLocalDescription
4.1.14. pendingLocalDescription . . . . . . . . . . . . . . . 31 4.1.14. pendingLocalDescription
4.1.15. currentRemoteDescription . . . . . . . . . . . . . . 32 4.1.15. currentRemoteDescription
4.1.16. pendingRemoteDescription . . . . . . . . . . . . . . 32 4.1.16. pendingRemoteDescription
4.1.17. canTrickleIceCandidates . . . . . . . . . . . . . . . 32 4.1.17. canTrickleIceCandidates
4.1.18. setConfiguration . . . . . . . . . . . . . . . . . . 33 4.1.18. setConfiguration
4.1.19. addIceCandidate . . . . . . . . . . . . . . . . . . . 34 4.1.19. addIceCandidate
4.1.20. onicecandidate Event . . . . . . . . . . . . . . . . 34 4.1.20. onicecandidate Event
4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 35 4.2. RtpTransceiver
4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.1. stop
4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.2. stopped
4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 35 4.2.3. setDirection
4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 36 4.2.4. direction
4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 36 4.2.5. currentDirection
4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 36 4.2.6. setCodecPreferences
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 37 5. SDP Interaction Procedures
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 37 5.1. Requirements Overview
5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 37 5.1.1. Usage Requirements
5.1.2. Profile Names and Interoperability . . . . . . . . . 37 5.1.2. Profile Names and Interoperability
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 39 5.2. Constructing an Offer
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 39 5.2.1. Initial Offers
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 45 5.2.2. Subsequent Offers
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 49 5.2.3. Options Handling
5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 49 5.2.3.1. IceRestart
5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 49 5.2.3.2. VoiceActivityDetection
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 50 5.3. Generating an Answer
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 50 5.3.1. Initial Answers
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 56 5.3.2. Subsequent Answers
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 58 5.3.3. Options Handling
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 58 5.3.3.1. VoiceActivityDetection
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 58 5.4. Modifying an Offer or Answer
5.5. Processing a Local Description . . . . . . . . . . . . . 59 5.5. Processing a Local Description
5.6. Processing a Remote Description . . . . . . . . . . . . . 60 5.6. Processing a Remote Description
5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 60 5.7. Processing a Rollback
5.8. Parsing a Session Description . . . . . . . . . . . . . . 61 5.8. Parsing a Session Description
5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 62 5.8.1. Session-Level Parsing
5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 63 5.8.2. Media Section Parsing
5.8.3. Semantics Verification . . . . . . . . . . . . . . . 66 5.8.3. Semantics Verification
5.9. Applying a Local Description . . . . . . . . . . . . . . 67 5.9. Applying a Local Description
5.10. Applying a Remote Description . . . . . . . . . . . . . . 68 5.10. Applying a Remote Description
5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 72 5.11. Applying an Answer
6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 75 6. Processing RTP/RTCP
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7. Examples
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 76 7.1. Simple Example
7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 80 7.2. Detailed Example
7.3. Early Transport Warmup Example . . . . . . . . . . . . . 90 7.3. Early Transport Warmup Example
8. Security Considerations . . . . . . . . . . . . . . . . . . . 97 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 9. IANA Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 97 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 102 10.2. Informative References
Appendix A. SDP ABNF Syntax . . . . . . . . . . . . . . . . . . 104 Appendix A. SDP ABNF Syntax
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 Authors' Addresses
1. Introduction 1. Introduction
This document describes how the W3C Web Real-Time Communication This document describes how the W3C Web Real-Time Communication
(WebRTC) RTCPeerConnection interface [W3C.webrtc] is used to control (WebRTC) RTCPeerConnection interface [W3C.webrtc] is used to control
the setup, management, and teardown of a multimedia session. the setup, management, and teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
WebRTC call setup has been designed to focus on controlling the media WebRTC call setup has been designed to focus on controlling the media
skipping to change at page 7, line 9 skipping to change at line 284
and especially how to generate the correct answer from an arbitrary and especially how to generate the correct answer from an arbitrary
offer and the supported capabilities. While this could certainly be offer and 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 example. basically forces the use of said library even for a simple example.
Providing createOffer/createAnswer avoids this problem. Providing createOffer/createAnswer avoids this problem.
1.3. Changes from RFC 8829 1.3. Changes from RFC 8829
When [RFC8829] was published, inconsistencies regarding BUNDLE When [RFC8829] was published, inconsistencies regarding BUNDLE
[RFC8843] operation were identified with regard to both the [RFC8843] operation were identified with regard to both the
specification text as well as implementation behavior. The former specification text and implementation behavior. The former concern
concern was addressed via an update to BUNDLE (see [RFC9143]). For was addressed via an update to BUNDLE (see [RFC9143]). For the
the latter concern, it was observed that some implementations latter concern, it was observed that some implementations implemented
implemented the "max-bundle" bundle policy defined in [RFC8829] by the "max-bundle" bundle policy defined in [RFC8829] by assuming that
assuming that bundling had already been negotiated, rather than bundling had already been negotiated, rather than marking "m="
marking "m=" sections as bundle-only as indicated by the BUNDLE sections as bundle-only as indicated by the BUNDLE specification. In
specification. In order to prevent unexpected changes to order to prevent unexpected changes to applications relying on the
applications relying on the pre-standard behavior, the decision was pre-standard behavior, the decision was made to deprecate "max-
made to deprecate "max-bundle" and instead introduce an identically bundle" and instead introduce an identically defined "must-bundle"
defined "must-bundle" policy that, when selected, provides the policy that, when selected, provides the behavior originally
behavior originally specified by [RFC8829]. specified by [RFC8829].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Semantics and Syntax 3. Semantics and Syntax
skipping to change at page 8, line 35 skipping to change at line 351
that must be handled in the JSEP APIs. that must be handled in the JSEP APIs.
Whether a session description applies to the local side or the remote Whether a session description applies to the local side or the remote
side affects the meaning of that description. For example, the list side affects the meaning of that description. For example, the list
of codecs sent to a remote party indicates what the local side is of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs willing to receive, which, when intersected with the set of codecs
the remote side supports, specifies what the remote side should send. the remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; some parameters are However, not all parameters follow this rule; some parameters are
declarative, and the remote side must either accept them or reject declarative, and the remote side must either accept them or reject
them altogether. An example of such a parameter is the TLS them altogether. An example of such a parameter is the TLS
fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; fingerprints [RFC8122] as used in the context of DTLS [RFC6347]
these fingerprints are calculated based on the local certificate(s) [RFC9147]; these fingerprints are calculated based on the local
offered and are not subject to negotiation. certificate(s) offered and are not subject to negotiation.
In addition, various RFCs put different conditions on the format of In addition, various RFCs put different conditions on the format of
offers versus answers. For example, an offer may propose an offers versus answers. For example, an offer may propose an
arbitrary number of "m=" sections (i.e., media descriptions as arbitrary number of "m=" sections (i.e., media descriptions as
described in [RFC4566], Section 5.14), but an answer must contain the described in [RFC4566], Section 5.14), but an answer must contain the
exact same number as the offer. exact same number as the offer.
Lastly, while the exact media parameters are known only after an Lastly, while the exact media parameters are known only after an
offer and an answer have been exchanged, the offerer may receive ICE offer and an answer have been exchanged, the offerer may receive ICE
checks, and possibly media (e.g., in the case of a re-offer after a checks, and possibly media (e.g., in the case of a re-offer after a
skipping to change at page 12, line 5 skipping to change at line 513
associated with one "m=" section. Each RtpTransceiver has an associated with one "m=" section. Each RtpTransceiver has an
RtpSender and an RtpReceiver, which an application can use to control RtpSender and an RtpReceiver, which an application can use to control
the sending and receiving of RTP media. The application may also the sending and receiving of RTP media. The application may also
modify the RtpTransceiver directly, for instance, by stopping it. modify the RtpTransceiver directly, for instance, by stopping it.
RtpTransceivers generally have a 1:1 mapping with "m=" sections, RtpTransceivers generally have a 1:1 mapping with "m=" sections,
although there may be more RtpTransceivers than "m=" sections when although there may be more RtpTransceivers than "m=" sections when
RtpTransceivers are created but not yet associated with an "m=" RtpTransceivers are created but not yet associated with an "m="
section, or if RtpTransceivers have been stopped and disassociated section, or if RtpTransceivers have been stopped and disassociated
from "m=" sections. An RtpTransceiver is said to be associated with from "m=" sections. An RtpTransceiver is said to be associated with
an "m=" section if its media identification (mid) property is non- an "m=" section if its mid property is non-null, i.e., set to a valid
null; otherwise, it is said to be disassociated. The associated "m=" Media Identification (MID) value; otherwise, it is said to be
section is determined using a mapping between transceivers and "m=" disassociated. The associated "m=" section is determined using a
section indices, formed when creating an offer or applying a remote mapping between transceivers and "m=" section indices, formed when
offer. creating an offer or applying a remote offer.
An RtpTransceiver is never associated with more than one "m=" An RtpTransceiver is never associated with more than one "m="
section, and once a session description is applied, an "m=" section section, and once a session description is applied, an "m=" section
is always associated with exactly one RtpTransceiver. However, in is always associated with exactly one RtpTransceiver. However, in
certain cases where an "m=" section has been rejected, as discussed certain cases where an "m=" section has been rejected, as discussed
in Section 5.2.2 below, that "m=" section will be "recycled" and in Section 5.2.2 below, that "m=" section will be "recycled" and
associated with a new RtpTransceiver with a new MID value. associated with a new RtpTransceiver with a new MID value.
RtpTransceivers can be created explicitly by the application or RtpTransceivers can be created explicitly by the application or
implicitly by calling setRemoteDescription with an offer that adds implicitly by calling setRemoteDescription with an offer that adds
skipping to change at page 17, line 22 skipping to change at line 758
3.6.1. Creating an imageattr Attribute 3.6.1. Creating an imageattr Attribute
The receiver will first combine any known local limits (e.g., The receiver will first combine any known local limits (e.g.,
hardware decoder capabilities or local policy) to determine the hardware decoder capabilities or local policy) to determine the
absolute minimum and maximum sizes it can receive. If there are no absolute minimum and maximum sizes it can receive. If there are no
known local limits, the "a=imageattr" attribute SHOULD be omitted. known local limits, the "a=imageattr" attribute SHOULD be omitted.
If these local limits preclude receiving any video, i.e., the If these local limits preclude receiving any video, i.e., the
degenerate case of no permitted resolutions, the "a=imageattr" degenerate case of no permitted resolutions, the "a=imageattr"
attribute MUST be omitted, and the "m=" section MUST be marked as attribute MUST be omitted, and the "m=" section MUST be marked as
sendonly/inactive, as appropriate. "sendonly"/"inactive", as appropriate.
Otherwise, an "a=imageattr" attribute is created with a "recv" Otherwise, an "a=imageattr" attribute is created with a "recv"
direction, and the resulting resolution space formed from the direction, and the resulting resolution space formed from the
aforementioned intersection is used to specify its minimum and aforementioned intersection is used to specify its minimum and
maximum "x=" and "y=" values. maximum "x=" and "y=" values.
The rules here express a single set of preferences, and therefore, The rules here express a single set of preferences, and therefore,
the "a=imageattr" "q=" value is not important. It SHOULD be set to the "a=imageattr" "q=" value is not important. It SHOULD be set to
"1.0". "1.0".
skipping to change at page 20, line 47 skipping to change at line 924
description that lists each desired encoding, and no "recv" simulcast description that lists each desired encoding, and no "recv" simulcast
stream description. The "m=" section will also include an "a=rid" stream description. The "m=" section will also include an "a=rid"
attribute for each encoding, as specified in [RFC8851], Section 4; attribute for each encoding, as specified in [RFC8851], Section 4;
the use of Restriction Identifiers (RIDs, also called rid-ids or the use of Restriction Identifiers (RIDs, also called rid-ids or
RtpStreamIds) allows the individual encodings to be disambiguated RtpStreamIds) allows the individual encodings to be disambiguated
even though they are all part of the same "m=" section. even though they are all part of the same "m=" section.
3.8. Interactions with Forking 3.8. Interactions with Forking
Some call signaling systems allow various types of forking where an Some call signaling systems allow various types of forking where an
SDP Offer may be provided to more than one device. For example, SIP SDP offer may be provided to more than one device. For example, SIP
[RFC3261] defines both a "parallel search" and "sequential search". [RFC3261] defines both a "parallel search" and "sequential search".
Although these are primarily signaling-level issues that are outside Although these are primarily signaling-level issues that are outside
the scope of JSEP, they do have some impact on the configuration of the scope of JSEP, they do have some impact on the configuration of
the media plane that is relevant. When forking happens at the the media plane that is relevant. When forking happens at the
signaling layer, the JavaScript application responsible for the signaling layer, the JavaScript application responsible for the
signaling needs to make the decisions about what media should be sent signaling needs to make the decisions about what media should be sent
or received at any point in time, as well as which remote endpoint it or received at any point in time, as well as which remote endpoint it
should communicate with; JSEP is used to make sure the media engine should communicate with; JSEP is used to make sure the media engine
can make the RTP and media perform as required by the application. can make the RTP and media perform as required by the application.
The basic operations that the applications can have the media engine The basic operations that the applications can have the media engine
skipping to change at page 24, line 4 skipping to change at line 1071
The set of available policies is as follows: The set of available policies is as follows:
balanced: The first "m=" section of each type (audio, video, or balanced: The first "m=" section of each type (audio, video, or
application) will contain transport parameters, which will allow application) will contain transport parameters, which will allow
an answerer to unbundle that section. The second and any an answerer to unbundle that section. The second and any
subsequent "m=" sections of each type will be marked as bundle- subsequent "m=" sections of each type will be marked as bundle-
only. The result is that if there are N distinct media types, only. The result is that if there are N distinct media types,
then candidates will be gathered for N media streams. This policy then candidates will be gathered for N media streams. This policy
balances the desire to multiplex with the need to ensure that balances the desire to multiplex with the need to ensure that
basic audio and video can still be negotiated in legacy cases. basic audio and video can still be negotiated in legacy cases.
When acting as answerer, if there is no bundle group in the offer, When acting as answerer, if there is no bundle group in the offer,
the implementation will reject all but the first "m=" section of the implementation will reject all but the first "m=" section of
each type. each type.
max-compat: All "m=" sections will contain transport parameters; max-compat: All "m=" sections will contain transport parameters;
none will be marked as bundle-only. This policy makes no none will be marked as bundle-only. This policy makes no
assumptions about the remote endpoint and as such will allow all assumptions about the remote endpoint and as such will allow all
streams to be received by non-bundle-aware endpoints, but as a streams to be received by non-bundle-aware endpoints, but as a
result requires separate candidates to be gathered for each media result requires separate candidates to be gathered for each media
stream. stream.
must-bundle: Only the first "m=" section will contain transport must-bundle: Only the first "m=" section will contain transport
parameters; all streams other than the first will be marked as parameters; all streams other than the first will be marked as
bundle-only. This policy presumes the remote endpoint supports bundle-only. This policy presumes that the remote endpoint
multiplexing and accordingly aims to minimize candidate gathering, supports multiplexing and accordingly aims to minimize candidate
at the cost of less compatibility with legacy endpoints. When gathering, at the cost of less compatibility with legacy
acting as answerer, the implementation will reject any "m=" endpoints. When acting as answerer, the implementation will
sections other than the first "m=" section, unless they are in the reject any "m=" sections other than the first "m=" section, unless
same bundle group as that "m=" section. they are in the same bundle group as that "m=" section.
As it provides the best trade-off between performance and As it provides the best trade-off between performance and
compatibility with legacy endpoints, the default bundle policy MUST compatibility with legacy endpoints, the default bundle policy MUST
be set to "balanced". be set to "balanced".
[RFC8829] defined a policy known as "max-bundle", which, while [RFC8829] defined a policy known as "max-bundle", which, while
defined identically to the "must-bundle" policy described above, was defined identically to the "must-bundle" policy described above, was
implemented by some implementations according to an earlier, pre- implemented by some implementations according to an earlier, pre-
standard definition (in which, for example, no "m=" sections were standard definition (in which, for example, no "m=" sections were
marked as bundle-only). As a result, "max-bundle" is considered marked as bundle-only). As a result, "max-bundle" is considered
deprecated, and implementations compliant with this specification deprecated, and implementations compliant with this specification
SHOULD ignore attempts by the application to select this bundle SHOULD ignore attempts by the application to select this bundle
policy (although some phase-out period may be necessary to avoid policy (although some phase-out period may be necessary to avoid
application breakage). application breakage).
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding the use of
RTP/RTCP multiplexing [RFC5761] using one of the following policies: RTP/RTCP multiplexing [RFC5761] using one of the following policies:
negotiate: The JSEP implementation will gather both RTP and RTCP negotiate: The JSEP implementation will gather both RTP and RTCP
candidates but also will offer "a=rtcp-mux", thus allowing for candidates but also will offer "a=rtcp-mux", thus allowing for
compatibility with either multiplexing or non-multiplexing compatibility with either multiplexing or non-multiplexing
endpoints. endpoints.
require: The JSEP implementation will only gather RTP candidates and require: The JSEP implementation will only gather RTP candidates and
will insert an "a=rtcp-mux-only" indication into any new "m=" will insert an "a=rtcp-mux-only" indication into any new "m="
sections in offers it generates. This halves the number of sections in offers it generates. This halves the number of
skipping to change at page 25, line 30 skipping to change at line 1145
compatible transceiver that was created by the most recent call to compatible transceiver that was created by the most recent call to
setRemoteDescription and does not have a local track. Otherwise, a setRemoteDescription and does not have a local track. Otherwise, a
new transceiver will be created, as described in Section 4.1.4. new transceiver will be created, as described in Section 4.1.4.
4.1.3. removeTrack 4.1.3. removeTrack
The removeTrack method removes a MediaStreamTrack from the The removeTrack method removes a MediaStreamTrack from the
PeerConnection, using the RtpSender argument to indicate which sender PeerConnection, using the RtpSender argument to indicate which sender
should have its track removed. The sender's track is cleared, and should have its track removed. The sender's track is cleared, and
the sender stops sending. Future calls to createOffer will mark the the sender stops sending. Future calls to createOffer will mark the
"m=" section associated with the sender as recvonly (if "m=" section associated with the sender as "recvonly" (if
transceiver.direction is sendrecv) or as inactive (if transceiver.direction is "sendrecv") or as "inactive" (if
transceiver.direction is sendonly). transceiver.direction is "sendonly").
4.1.4. addTransceiver 4.1.4. addTransceiver
The addTransceiver method adds a new RtpTransceiver to the The addTransceiver method adds a new RtpTransceiver to the
PeerConnection. If a MediaStreamTrack argument is provided, then the PeerConnection. If a MediaStreamTrack argument is provided, then the
transceiver will be configured with that media type and the track transceiver will be configured with that media type and the track
will be attached to the transceiver. Otherwise, the application MUST will be attached to the transceiver. Otherwise, the application MUST
explicitly specify the type; this mode is useful for creating explicitly specify the type; this mode is useful for creating
recvonly transceivers as well as for creating transceivers to which a "recvonly" transceivers as well as for creating transceivers to which
track can be attached at some later point. a track can be attached at some later point.
At the time of creation, the application can also specify a At the time of creation, the application can also specify a
transceiver direction attribute, a set of MediaStreams that the transceiver direction attribute, a set of MediaStreams that the
transceiver is associated with (allowing "LS" group assignments), and transceiver is associated with (allowing "LS" group assignments), and
a set of encodings for the media (used for simulcast as described in a set of encodings for the media (used for simulcast as described in
Section 3.7). Section 3.7).
4.1.5. onaddtrack Event 4.1.5. onaddtrack Event
The onaddtrack event is dispatched to the application when a new The onaddtrack event is dispatched to the application when a new
skipping to change at page 27, line 10 skipping to change at line 1218
generation of the SDP will follow the process defined for generating generation of the SDP will follow the process defined for generating
an initial offer from the specification that defines the given SDP an initial offer from the specification that defines the given SDP
line. The exact handling of initial offer generation is detailed in line. The exact handling of initial offer generation is detailed in
Section 5.2.1 below. Section 5.2.1 below.
In the event createOffer is called after the session is established, In the event createOffer is called after the session is established,
createOffer will generate an offer to modify the current session createOffer will generate an offer to modify the current session
based on any changes that have been made to the session, e.g., adding based on any changes that have been made to the session, e.g., adding
or stopping RtpTransceivers, or requesting an ICE restart. For each or stopping RtpTransceivers, or requesting an ICE restart. For each
existing stream, the generation of each SDP line MUST follow the existing stream, the generation of each SDP line MUST follow the
process defined for generating an updated offer from the RFC that process defined for generating an updated offer from the
specifies the given SDP line. For each new stream, the generation of specification that defines the given SDP line. For each new stream,
the SDP MUST follow the process of generating an initial offer, as the generation of the SDP MUST follow the process of generating an
mentioned above. The exact handling of subsequent offer generation initial offer, as mentioned above. The exact handling of subsequent
is detailed in Section 5.2.2 below. offer generation is detailed in Section 5.2.2 below.
Session descriptions generated by createOffer MUST be immediately Session descriptions generated by createOffer MUST be immediately
usable by setLocalDescription; if a system has limited resources usable by setLocalDescription; if a system has limited resources
(e.g., a finite number of decoders), createOffer SHOULD return an (e.g., a finite number of decoders), createOffer SHOULD return an
offer that reflects the current state of the system, so that offer that reflects the current state of the system, so that
setLocalDescription will succeed when it attempts to acquire those setLocalDescription will succeed when it attempts to acquire those
resources. resources.
Calling this method may do things such as generating new ICE Calling this method may do things such as generating new ICE
credentials, but it does not change the PeerConnection state, trigger credentials, but it does not change the PeerConnection state, trigger
skipping to change at page 27, line 36 skipping to change at line 1244
Specifically, the offer is not applied, and does not become the Specifically, the offer is not applied, and does not become the
pending local description, until setLocalDescription is called. pending local description, until setLocalDescription is called.
4.1.9. createAnswer 4.1.9. createAnswer
The createAnswer method generates a blob of SDP that contains an SDP The createAnswer method generates a blob of SDP that contains an SDP
answer per [RFC3264] with the supported configuration for the session answer per [RFC3264] with the supported configuration for the session
that is compatible with the parameters supplied in the most recent that is compatible with the parameters supplied in the most recent
call to setRemoteDescription; setRemoteDescription MUST have been call to setRemoteDescription; setRemoteDescription MUST have been
called prior to calling createAnswer. Like createOffer, the returned called prior to calling createAnswer. Like createOffer, the returned
blob contains descriptions of the media added to this PeerConnection, blob contains descriptions of the media added to this PeerConnection;
the codec, RTP, and RTCP options supported by the application, and the codec, RTP, and RTCP options supported by the application; and
any candidates that have been gathered by the ICE agent. An options any candidates that have been gathered by the ICE agent. An options
parameter may be supplied to provide additional control over the parameter may be supplied to provide additional control over the
generated answer. generated answer.
As an answer, the generated SDP will contain a specific configuration As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each that specifies how the media plane should be established; for each
SDP line, the generation of the SDP MUST follow the process defined SDP line, the generation of the SDP MUST follow the process defined
for generating an answer from the specification that defines the for generating an answer from the specification that defines the
given SDP line. The exact handling of answer generation is detailed given SDP line. The exact handling of answer generation is detailed
in Section 5.3 below. in Section 5.3 below.
skipping to change at page 28, line 27 skipping to change at line 1283
"offer" indicates that a description MUST be parsed as an offer; said "offer" indicates that a description MUST be parsed as an offer; said
description may include many possible media configurations. A description may include many possible media configurations. A
description used as an "offer" may be applied any time the description used as an "offer" may be applied any time the
PeerConnection is in a "stable" state or applied as an update to a PeerConnection is in a "stable" state or applied as an update to a
previously supplied but unanswered "offer". previously supplied but unanswered "offer".
"pranswer" indicates that a description MUST be parsed as an answer, "pranswer" indicates that a description MUST be parsed as an answer,
but not a final answer, and so MUST NOT result in the freeing of but not a final answer, and so MUST NOT result in the freeing of
allocated resources. It may result in the start of media allocated resources. It may result in the start of media
transmission, if the answer does not specify an inactive media transmission, if the answer does not specify an "inactive" media
direction. A description used as a "pranswer" may be applied as a direction. A description used as a "pranswer" may be applied as a
response to an "offer" or as an update to a previously sent response to an "offer" or as an update to a previously sent
"pranswer". "pranswer".
"answer" indicates that a description MUST be parsed as an answer, "answer" indicates that a description MUST be parsed as an answer,
the offer/answer exchange MUST be considered complete, and any the offer/answer exchange MUST be considered complete, and any
resources (decoders, candidates) that are no longer needed SHOULD be resources (decoders, candidates) that are no longer needed SHOULD be
released. A description used as an "answer" may be applied as a released. A description used as an "answer" may be applied as a
response to an "offer" or as an update to a previously sent response to an "offer" or as an update to a previously sent
"pranswer". "pranswer".
skipping to change at page 29, line 30 skipping to change at line 1332
MediaStreamTrack and create a new "sendrecv" offer to update the MediaStreamTrack and create a new "sendrecv" offer to update the
previous offer/answer pair and start bidirectional media flow. While previous offer/answer pair and start bidirectional media flow. While
this could also be done with a "sendonly" pranswer followed by a this could also be done with a "sendonly" pranswer followed by a
"sendrecv" answer, the initial pranswer leaves the offer/answer "sendrecv" answer, the initial pranswer leaves the offer/answer
exchange open, which means that the caller cannot send an updated exchange open, which means that the caller cannot send an updated
offer during this time. offer during this time.
As an example, consider a typical JSEP application that wants to set As an example, consider a typical JSEP application that wants to set
up audio and video as quickly as possible. When the callee receives up audio and video as quickly as possible. When the callee receives
an offer with audio and video MediaStreamTracks, it will send an an offer with audio and video MediaStreamTracks, it will send an
immediate answer accepting these tracks as sendonly (meaning that the immediate answer accepting these tracks as "sendonly" (meaning that
caller will not send the callee any media yet, and because the callee the caller will not send the callee any media yet, and because the
has not yet added its own MediaStreamTracks, the callee will not send callee has not yet added its own MediaStreamTracks, the callee will
any media either). It will then ask the user to accept the call and not send any media either). It will then ask the user to accept the
acquire the needed local tracks. Upon acceptance by the user, the call and acquire the needed local tracks. Upon acceptance by the
application will plug in the tracks it has acquired, which, because user, the application will plug in the tracks it has acquired, which,
ICE handshaking and DTLS handshaking have likely completed by this because ICE handshaking and DTLS handshaking have likely completed by
point, can start transmitting immediately. The application will also this point, can start transmitting immediately. The application will
send a new offer to the remote side indicating call acceptance and also send a new offer to the remote side indicating call acceptance
moving the audio and video to be two-way media. A detailed example and moving the audio and video to be two-way media. A detailed
flow along these lines is shown in Section 7.3. example flow along these lines is shown in Section 7.3.
Of course, some applications may not be able to perform this double Of course, some applications may not be able to perform this double
offer/answer exchange, particularly ones that are attempting to offer/answer exchange, particularly ones that are attempting to
gateway to legacy signaling protocols. In these cases, pranswer can gateway to legacy signaling protocols. In these cases, pranswer can
still provide the application with a mechanism to warm up the still provide the application with a mechanism to warm up the
transport. transport.
4.1.10.2. Rollback 4.1.10.2. Rollback
In certain situations, it may be desirable to "undo" a change made to In certain situations, it may be desirable to "undo" a change made to
skipping to change at page 33, line 13 skipping to change at line 1484
cannot support trickle. cannot support trickle.
As described in Section 3.5.2, JSEP implementations always provide As described in Section 3.5.2, JSEP implementations always provide
candidates to the application individually, consistent with what is candidates to the application individually, consistent with what is
needed for Trickle ICE. However, applications can use the needed for Trickle ICE. However, applications can use the
canTrickleIceCandidates property to determine whether their peer can canTrickleIceCandidates property to determine whether their peer can
actually do Trickle ICE, i.e., whether it is safe to send an initial actually do Trickle ICE, i.e., whether it is safe to send an initial
offer or answer followed later by candidates as they are gathered. offer or answer followed later by candidates as they are gathered.
As "true" is the only value that definitively indicates remote As "true" is the only value that definitively indicates remote
Trickle ICE support, an application that compares Trickle ICE support, an application that compares
canTrickleIceCandidates against "true" will by default attempt Half canTrickleIceCandidates against "true" will by default attempt half
Trickle on initial offers and Full Trickle on subsequent interactions trickle on initial offers and full trickle on subsequent interactions
with a Trickle ICE-compatible agent. with a Trickle ICE-compatible agent.
4.1.18. setConfiguration 4.1.18. setConfiguration
The setConfiguration method allows the global configuration of the The setConfiguration method allows the global configuration of the
PeerConnection, which was initially set by constructor parameters, to PeerConnection, which was initially set by constructor parameters, to
be changed during the session. The effects of calling this method be changed during the session. The effects of calling this method
depend on when it is invoked, and they will differ, depending on depend on when it is invoked, and they will differ, depending on
which specific parameters are changed: which specific parameters are changed:
skipping to change at page 34, line 34 skipping to change at line 1553
"m=" sections in the specified ICE candidate generation. However, if "m=" sections in the specified ICE candidate generation. However, if
both fields are null for a new remote candidate, this MUST be treated both fields are null for a new remote candidate, this MUST be treated
as an invalid condition, as specified below. as an invalid condition, as specified below.
If any IceCandidate fields contain invalid values or an error occurs If any IceCandidate fields contain invalid values or an error occurs
during the processing of the IceCandidate object, the supplied during the processing of the IceCandidate object, the supplied
IceCandidate MUST be ignored and an error MUST be returned. IceCandidate MUST be ignored and an error MUST be returned.
Otherwise, the new remote candidate or end-of-candidates indication Otherwise, the new remote candidate or end-of-candidates indication
is supplied to the ICE agent. In the case of a new remote candidate, is supplied to the ICE agent. In the case of a new remote candidate,
connectivity checks will be sent to the new candidate, assuming connectivity checks will be sent to the new candidate, assuming that
setLocalDescription has already been called to initialize the ICE setLocalDescription has already been called to initialize the ICE
gathering process. gathering process.
4.1.20. onicecandidate Event 4.1.20. onicecandidate Event
The onicecandidate event is dispatched to the application in two 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 Section 3.5.1 and ICE candidate during ICE gathering, as outlined in Section 3.5.1 and
subject to the restrictions discussed in Section 3.5.3, or (2) when subject to the restrictions discussed in Section 3.5.3, or (2) when
an ICE gathering phase completes. The event contains a single an ICE gathering phase completes. The event contains a single
skipping to change at page 35, line 12 skipping to change at line 1578
candidate will also be added to the current and/or pending local candidate will also be added to the current and/or pending local
description according to the rules defined for Trickle ICE. description according to the rules defined for Trickle ICE.
In the second case, the event's IceCandidate object MUST have its In the second case, the event's IceCandidate object MUST have its
candidate field set to null to indicate that the current gathering candidate field set to null to indicate that the current gathering
phase is complete, i.e., there will be no further onicecandidate phase is complete, i.e., there will be no further onicecandidate
events in this phase. However, the IceCandidate's ufrag field MUST events in this phase. However, the IceCandidate's ufrag field MUST
be specified to indicate which ICE candidate generation is ending. be specified to indicate which ICE candidate generation is ending.
The IceCandidate's "m=" section index and MID fields MAY be specified The IceCandidate's "m=" section index and MID fields MAY be specified
to indicate that the event applies to a specific "m=" section, or set to indicate that the event applies to a specific "m=" section, or set
to null to indicate it applies to all "m=" sections in the current to null to indicate that it applies to all "m=" sections in the
ICE candidate generation. This event can be used by the application current ICE candidate generation. This event can be used by the
to generate an end-of-candidates indication, as defined in [RFC8838], application to generate an end-of-candidates indication, as defined
Section 13. in [RFC8838], Section 13.
4.2. RtpTransceiver 4.2. RtpTransceiver
4.2.1. stop 4.2.1. stop
The stop method stops an RtpTransceiver. This will cause future The stop method stops an RtpTransceiver. This will cause future
calls to createOffer to generate a zero port for the associated "m=" calls to createOffer to generate a zero port for the associated "m="
section. See below for more details. section. See below for more details.
4.2.2. stopped 4.2.2. stopped
skipping to change at page 36, line 5 skipping to change at line 1615
future calls to createOffer and createAnswer. The permitted values future calls to createOffer and createAnswer. The permitted values
for direction are "recvonly", "sendrecv", "sendonly", and "inactive", for direction are "recvonly", "sendrecv", "sendonly", and "inactive",
mirroring the identically named direction attributes defined in mirroring the identically named direction attributes defined in
[RFC4566], Section 6. [RFC4566], Section 6.
When creating offers, the transceiver direction is directly reflected When creating offers, the transceiver direction is directly reflected
in the output, even for re-offers. When creating answers, the in the output, even for re-offers. When creating answers, the
transceiver direction is intersected with the offered direction, as transceiver direction is intersected with the offered direction, as
explained in Section 5.3 below. explained in Section 5.3 below.
Note that while setDirection sets the direction property of the Note that while setDirection sets the direction property
transceiver immediately (Section 4.2.4), this property does not (Section 4.2.4) of the transceiver immediately, this property does
immediately affect whether the transceiver's RtpSender will send or not immediately affect whether the transceiver's RtpSender will send
its RtpReceiver will receive. The direction in effect is represented or its RtpReceiver will receive. The direction in effect is
by the currentDirection property, which is only updated when an represented by the currentDirection property, which is only updated
answer is applied. when an answer is applied.
4.2.4. direction 4.2.4. direction
The direction property indicates the last value passed into The direction property indicates the last value passed into
setDirection. If setDirection has never been called, it is set to setDirection. If setDirection has never been called, it is set to
the direction the transceiver was initialized with. the direction the transceiver was initialized with.
4.2.5. currentDirection 4.2.5. currentDirection
The currentDirection property indicates the last negotiated direction The currentDirection property indicates the last negotiated direction
for the transceiver's associated "m=" section. More specifically, it for the transceiver's associated "m=" section. More specifically, it
indicates the direction attribute [RFC3264] of the associated "m=" indicates the direction attribute [RFC3264] of the associated "m="
section in the last applied answer (including provisional answers), section in the last applied answer (including provisional answers),
with "send" and "recv" directions reversed if it was a remote answer. with the direction reversed if it was a remote answer. For example,
For example, if the direction attribute for the associated "m=" if the direction attribute for the associated "m=" section in a
section in a remote answer is "recvonly", currentDirection is set to remote answer is "recvonly", currentDirection is set to "sendonly".
"sendonly".
If an answer that references this transceiver has not yet been If an answer that references this transceiver has not yet been
applied or if the transceiver is stopped, currentDirection is set to applied or if the transceiver is stopped, currentDirection is set to
"null". null.
4.2.6. setCodecPreferences 4.2.6. setCodecPreferences
The setCodecPreferences method sets the codec preferences of a The setCodecPreferences method sets the codec preferences of a
transceiver, which in turn affect the presence and order of codecs of transceiver, which in turn affect the presence and order of codecs of
the associated "m=" section on future calls to createOffer and the associated "m=" section on future calls to createOffer and
createAnswer. Note that setCodecPreferences does not directly affect createAnswer. Note that setCodecPreferences does not directly affect
which codec the implementation decides to send. It only affects which codec the implementation decides to send. It only affects
which codecs the implementation indicates that it prefers to receive, which codecs the implementation indicates that it prefers to receive,
via the offer or answer. Even when a codec is excluded by via the offer or answer. Even when a codec is excluded by
skipping to change at page 37, line 34 skipping to change at line 1689
If any of these are absent, this omission MUST be treated as an If any of these are absent, this omission MUST be treated as an
error. error.
* ICE, as specified in [RFC8445], MUST be used. Note that the * ICE, as specified in [RFC8445], MUST be used. Note that the
remote endpoint may use a lite implementation; implementations remote endpoint may use a lite implementation; implementations
MUST properly handle remote endpoints that use ICE-lite. The MUST properly handle remote endpoints that use ICE-lite. The
remote endpoint may also use an older version of ICE; remote endpoint may also use an older version of ICE;
implementations MUST properly handle remote endpoints that use ICE implementations MUST properly handle remote endpoints that use ICE
as specified in [RFC5245]. as specified in [RFC5245].
* DTLS [RFC6347] or DTLS-SRTP [RFC5763] MUST be used, as appropriate * DTLS [RFC6347] [RFC9147] or DTLS-SRTP [RFC5763] MUST be used, as
for the media type, as specified in [RFC8827]. appropriate for the media type, as specified in [RFC8827]. Note:
RFC 8827 requires implementations to support DTLS 1.2 [RFC6347]
and permits the use of DTLS 1.3 [RFC9147].
The SDP security descriptions mechanism for SRTP keying [RFC4568] The SDP security descriptions mechanism for Secure Real-time
MUST NOT be used, as discussed in [RFC8827]. Transport Protocol (SRTP) keying [RFC4568] MUST NOT be used, as
discussed in [RFC8827].
5.1.2. Profile Names and Interoperability 5.1.2. Profile Names and Interoperability
For media "m=" sections, JSEP implementations MUST support the For media "m=" sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the
"TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850] and MUST indicate "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850] and MUST indicate
one of these profiles for each media "m=" line they produce in an one of these profiles for each media "m=" line they produce in an
offer. For data "m=" sections, implementations MUST support the offer. For data "m=" sections, implementations MUST 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 MUST indicate one of these profiles for each data "m=" line they
skipping to change at page 41, line 8 skipping to change at line 1852
all have the same fingerprint value or values [RFC8122], or these all have the same fingerprint value or values [RFC8122], or these
values MUST be session-level attributes. values MUST be session-level attributes.
Each "m=" section MUST be generated as specified in [RFC4566], Each "m=" section MUST be generated as specified in [RFC4566],
Section 5.14. For the "m=" line itself, the following rules MUST be Section 5.14. For the "m=" line itself, the following rules MUST be
followed: followed:
* If the "m=" section is marked as bundle-only, then the <port> * If the "m=" section is marked as bundle-only, then the <port>
value MUST be set to zero. Otherwise, the <port> value is set to value MUST be set to zero. Otherwise, the <port> value is set to
the port of the default ICE candidate for this "m=" section, but the port of the default ICE candidate for this "m=" section, but
given that no candidates are available yet, the default port value given that no candidates are available yet, the default <port>
of 9 (Discard) MUST be used, as indicated in [RFC8840], value of 9 (Discard) MUST be used, as indicated in [RFC8840],
Section 4.1.1. Section 4.1.1.
* To properly indicate use of DTLS, the <proto> field MUST be set to * To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8.
* If codec preferences have been set for the associated transceiver, * If codec preferences have been set for the associated transceiver,
media formats MUST be generated in the corresponding order and media formats MUST be generated in the corresponding order and
MUST exclude any codecs not present in the codec preferences. MUST exclude any codecs not present in the codec preferences.
* Unless excluded by the above restrictions, the media formats MUST * Unless excluded by the above restrictions, the media formats MUST
skipping to change at page 42, line 15 skipping to change at line 1908
* For each primary codec where RTP retransmission should be used, a * For each primary codec where RTP retransmission should be used, a
corresponding "a=rtpmap" line indicating "rtx" with the clock rate corresponding "a=rtpmap" line indicating "rtx" with the clock rate
of the primary codec and an "a=fmtp" line that references the of the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in [RFC4588], payload type of the primary codec, as specified in [RFC4588],
Section 8.1. Section 8.1.
* For each Forward Error Correction (FEC) mechanism supported by the * For each Forward Error Correction (FEC) mechanism supported by the
application, "a=rtpmap" and "a=fmtp" lines, as specified in application, "a=rtpmap" and "a=fmtp" lines, as specified in
[RFC4566], Section 6. The FEC mechanisms that MUST be supported [RFC4566], Section 6. The FEC mechanisms that MUST be supported
are specified in [RFC8854], Section 7, and specific usage for each are specified in [RFC8854], Section 7, and specific usage for each
media type is outlined in Sections 4 and 5. media type is outlined in Sections 4 and 5 of [RFC8854].
* If this "m=" section is for media with configurable durations of * If this "m=" section is for media with configurable durations of
media per packet, e.g., audio, an "a=maxptime" line, indicating media per packet, e.g., audio, an "a=maxptime" line, indicating
the maximum amount of media, specified in milliseconds, that can the maximum amount of media, specified in milliseconds, that can
be encapsulated in each packet, as specified in [RFC4566], be encapsulated in each packet, as specified in [RFC4566],
Section 6. This value is set to the smallest of the maximum Section 6. This value is set to the smallest of the maximum
duration values across all the codecs included in the "m=" duration values across all the codecs included in the "m="
section. section.
* If this "m=" section is for video media and there are known * If this "m=" section is for video media and there are known
skipping to change at page 42, line 40 skipping to change at line 1933
"a=extmap" line, as specified in [RFC5285], Section 5. The list "a=extmap" line, as specified in [RFC5285], Section 5. The list
of header extensions that SHOULD/MUST be supported is specified in of header extensions that SHOULD/MUST be supported is specified in
[RFC8834], Section 5.2. Any header extensions that require [RFC8834], Section 5.2. Any header extensions that require
encryption MUST be specified as indicated in [RFC6904], Section 4. encryption MUST be specified as indicated in [RFC6904], Section 4.
* For each RTCP feedback mechanism supported by the application, an * For each RTCP feedback mechanism supported by the application, an
"a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The "a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The
list of RTCP feedback mechanisms that SHOULD/MUST be supported is list of RTCP feedback mechanisms that SHOULD/MUST be supported is
specified in [RFC8834], Section 5.1. specified in [RFC8834], Section 5.1.
* If the RtpTransceiver has a sendrecv or sendonly direction: * If the RtpTransceiver has a "sendrecv" or "sendonly" direction:
- For each MediaStream that was associated with the transceiver - For each MediaStream that was associated with the transceiver
when it was created via addTrack or addTransceiver, an "a=msid" when it was created via addTrack or addTransceiver, an "a=msid"
line, as specified in [RFC8830], Section 2, but omitting the line, as specified in [RFC8830], Section 2, but omitting the
"appdata" field. "appdata" field.
* If the RtpTransceiver has a sendrecv or sendonly direction, and * If the RtpTransceiver has a "sendrecv" or "sendonly" direction,
the application has specified a rid-id for an encoding, or has and the application has specified a rid-id for an encoding, or has
specified more than one encoding in the RtpSenders's parameters, specified more than one encoding in the RtpSenders's parameters,
an "a=rid" line for each encoding specified. The "a=rid" line is an "a=rid" line for each encoding specified. The "a=rid" line is
specified in [RFC8851], and its direction MUST be "send". If the specified in [RFC8851], and its direction MUST be "send". If the
application has chosen a rid-id, it MUST be used; otherwise, a application has chosen a rid-id, it MUST be used; otherwise, a
rid-id MUST be generated by the implementation. rid-ids MUST be rid-id MUST be generated by the implementation. rid-ids MUST be
generated in a fashion that does not leak user information, e.g., generated in a fashion that does not leak user information, e.g.,
randomly or using a per-PeerConnection counter (see guidance at randomly or using a per-PeerConnection counter (see guidance at
the end of [RFC8852], Section 3.3), and SHOULD be 3 bytes or less, the end of [RFC8852], Section 3.3), and SHOULD be 3 bytes or less,
to allow them to efficiently fit into the RTP header extensions to allow them to efficiently fit into the RTP header extensions
defined in [RFC8852], Section 3.3. If no encodings have been defined in [RFC8852], Section 3.3. If no encodings have been
specified, or only one encoding is specified but without a rid-id, specified, or only one encoding is specified but without a rid-id,
then no "a=rid" lines are generated. then no "a=rid" lines are generated.
* If the RtpTransceiver has a sendrecv or sendonly direction and * If the RtpTransceiver has a "sendrecv" or "sendonly" direction and
more than one "a=rid" line has been generated, an "a=simulcast" more than one "a=rid" line has been generated, an "a=simulcast"
line, with direction "send", as defined in [RFC8853], Section 5.1. line, with direction "send", as defined in [RFC8853], Section 5.1.
The associated set of rid-ids MUST include all of the rid-ids used The associated set of rid-ids MUST include all of the rid-ids used
in the "a=rid" lines for this "m=" section. in the "a=rid" lines for this "m=" section.
* If (1) the bundle policy for this PeerConnection is set to "must- * If (1) the bundle policy for this PeerConnection is set to "must-
bundle" and this is not the first "m=" section or (2) the bundle bundle" and this is not the first "m=" section or (2) the bundle
policy is set to "balanced" and this is not the first "m=" section policy is set to "balanced" and this is not the first "m=" section
for this media type, an "a=bundle-only" line. for this media type, an "a=bundle-only" line.
skipping to change at page 44, line 11 skipping to change at line 2000
* If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- * If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux-
only" line, as specified in [RFC8858], Section 4. only" line, as specified in [RFC8858], Section 4.
* An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. * An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
Lastly, if a data channel has been created, an "m=" section MUST be Lastly, if a data channel has been created, an "m=" section MUST be
generated for data. The <media> field MUST be set to "application", generated for data. The <media> field MUST be set to "application",
and the <proto> field MUST be set to "UDP/DTLS/SCTP" [RFC8841]. The and the <proto> field MUST be set to "UDP/DTLS/SCTP" [RFC8841]. The
<fmt> value MUST be set to "webrtc-datachannel" as specified in <fmt> value MUST be set to "webrtc-datachannel" as specified in
[RFC8841], Section 4.2.2. [RFC8841], Section 4.4.2.
Within the data "m=" section, an "a=mid" line MUST be generated and Within the data "m=" section, an "a=mid" line MUST be generated and
included as described above, along with an "a=sctp-port" line included as described above, along with an "a=sctp-port" line
referencing the SCTP port number, as defined in [RFC8841], referencing the SCTP port number, as defined in [RFC8841],
Section 5.1; and, if appropriate, an "a=max-message-size" line, as Section 5.1; and, if appropriate, an "a=max-message-size" line, as
defined in [RFC8841], Section 6.1. defined in [RFC8841], Section 6.1.
As discussed above, the following attributes of category IDENTICAL or As discussed above, the following attributes of category IDENTICAL or
TRANSPORT are included only if the data "m=" section either has a TRANSPORT are included only if the data "m=" section either has a
unique address or is associated with the BUNDLE-tag (e.g., if it is unique address or is associated with the BUNDLE-tag (e.g., if it is
skipping to change at page 44, line 36 skipping to change at line 2025
* "a=ice-pwd" * "a=ice-pwd"
* "a=fingerprint" * "a=fingerprint"
* "a=setup" * "a=setup"
* "a=tls-id" * "a=tls-id"
Once all "m=" sections have been generated, a session-level "a=group" Once all "m=" sections have been generated, a session-level "a=group"
attribute MUST be added as specified in [RFC5888]. This attribute attribute MUST be added as specified in [RFC5888]. This attribute
MUST have semantics "BUNDLE" and MUST include the mid identifiers of MUST have semantics "BUNDLE" and MUST include the MID identifiers of
each "m=" section. The effect of this is that the JSEP each "m=" section. The effect of this is that the JSEP
implementation offers all "m=" sections as one bundle group. implementation offers all "m=" sections as one bundle group.
However, whether the "m=" sections are bundle-only or not depends on However, whether the "m=" sections are bundle-only or not depends on
the bundle policy. the bundle policy.
The next step is to generate session-level lip sync groups as defined The next step is to generate session-level lip sync groups as defined
in [RFC5888], Section 7. For each MediaStream referenced by more in [RFC5888], Section 7. For each MediaStream referenced by more
than one RtpTransceiver (by passing those MediaStreams as arguments than one RtpTransceiver (by passing those MediaStreams as arguments
to the addTrack and addTransceiver methods), a group of type "LS" to the addTrack and addTransceiver methods), a group of type "LS"
MUST be added that contains the MID values for each RtpTransceiver. MUST be added that contains the MID values for each RtpTransceiver.
skipping to change at page 49, line 6 skipping to change at line 2235
section. section.
The "a=group:BUNDLE" attribute MUST include the MID identifiers The "a=group:BUNDLE" attribute MUST include the MID identifiers
specified in the bundle group in the most recent answer, minus any specified in the bundle group in the most recent answer, minus any
"m=" sections that have been marked as rejected, plus any newly added "m=" sections that have been marked as rejected, plus any newly added
or re-enabled "m=" sections. In other words, the bundle attribute or re-enabled "m=" sections. In other words, the bundle attribute
MUST contain all "m=" sections that were previously bundled, as long MUST contain all "m=" sections that were previously bundled, as long
as they are still alive, as well as any new "m=" sections. as they are still alive, as well as any new "m=" sections.
Note that if bundling has been negotiated, unbundling is no longer Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only. This possible, and media sections will not be marked as bundle-only.
is by design, but could cause issues in the rare case of sending a Although this is by design, it could cause issues in the rare case of
subsequent offer as an initial offer to a non-bundle-aware endpoint sending a subsequent offer as an initial offer to a non-bundle-aware
via Third Party Call Control (3PCC), as discussed in [RFC9143], endpoint via Third Party Call Control (3PCC), as discussed in
Section 7.6. [RFC9143], Section 7.6.
"a=group:LS" attributes are generated in the same way as for initial "a=group:LS" attributes are generated in the same way as for initial
offers, with the additional stipulation that any lip sync groups that offers, with the additional stipulation that any lip sync groups that
were present in the most recent answer MUST continue to exist and were present in the most recent answer MUST continue to exist and
MUST contain any previously existing MID identifiers, as long as the MUST contain any previously existing MID identifiers, as long as the
identified "m=" sections still exist and are not rejected, and the identified "m=" sections still exist and are not rejected, and the
group still contains at least two MID identifiers. This ensures that group still contains at least two MID identifiers. This ensures that
any synchronized "recvonly" "m=" sections continue to be synchronized any synchronized "recvonly" "m=" sections continue to be synchronized
in the new offer. in the new offer.
5.2.3. Options Handling 5.2.3. Options Handling
The createOffer method takes as a parameter an RTCOfferOptions The createOffer method takes as a parameter an RTCOfferOptions
object. Special processing is performed when generating an SDP object. Special processing is performed when generating an SDP
description if the following options are present. description if the following options are present.
5.2.3.1. IceRestart 5.2.3.1. IceRestart
If the IceRestart option is specified, with a value of "true", the If the IceRestart option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in [RFC8839], Section 4.4.3.1.1. If pwd attributes, as specified in [RFC8839], Section 4.4.1.1.1. If
this option is specified on an initial offer, it has no effect (since this option is specified on an initial offer, it has no effect (since
a new ICE ufrag and pwd are already generated). Similarly, if the a new ICE ufrag and pwd are already generated). Similarly, if the
ICE configuration has changed, this option has no effect, since new ICE configuration has changed, this option has no effect, since new
ufrag and pwd attributes will be generated automatically. This ufrag and pwd attributes will be generated automatically. This
option is primarily useful for reestablishing connectivity in cases option is primarily useful for reestablishing connectivity in cases
where failures are detected by the application. where failures are detected by the application.
5.2.3.2. VoiceActivityDetection 5.2.3.2. VoiceActivityDetection
Silence suppression, also known as discontinuous transmission Silence suppression, also known as discontinuous transmission
("DTX"), can reduce the bandwidth used for audio by switching to a ("DTX"), can reduce the bandwidth used for audio by switching to a
special encoding when voice activity is not detected, at the cost of special encoding when voice activity is not detected, at the cost of
some fidelity. some fidelity.
If the "VoiceActivityDetection" option is specified, with a value of If the VoiceActivityDetection option is specified, with a value of
"true", the offer MUST indicate support for silence suppression in "true", the offer MUST indicate support for silence suppression in
the audio it receives by including comfort noise ("CN") codecs for the audio it receives by including comfort noise ("CN") codecs for
each offered audio codec, as specified in [RFC3389], Section 5.1, each offered audio codec, as specified in [RFC3389], Section 5.1,
except for codecs that have their own internal silence suppression except for codecs that have their own internal silence suppression
support. For codecs that have their own internal silence suppression support. For codecs that have their own internal silence suppression
support, the appropriate fmtp parameters for that codec MUST be support, the appropriate fmtp parameters for each such codec MUST be
specified to indicate that silence suppression for received audio is specified to indicate that silence suppression for received audio is
desired. For example, when using the Opus codec [RFC6716], the desired. For example, when using the Opus codec [RFC6716], the
"usedtx=1" parameter, specified in [RFC7587], would be used in the "usedtx=1" parameter, specified in [RFC7587], would be used in the
offer. offer.
If the "VoiceActivityDetection" option is specified, with a value of If the VoiceActivityDetection option is specified, with a value of
"false", the JSEP implementation MUST NOT emit "CN" codecs. For "false", the JSEP implementation MUST NOT emit "CN" codecs. For
codecs that have their own internal silence suppression support, the codecs that have their own internal silence suppression support, the
appropriate fmtp parameters for that codec MUST be specified to appropriate fmtp parameters for each such codec MUST be specified to
indicate that silence suppression for received audio is not desired. indicate that silence suppression for received audio is not desired.
For example, when using the Opus codec, the "usedtx=0" parameter For example, when using the Opus codec, the "usedtx=0" parameter
would be specified in the offer. In addition, the implementation would be specified in the offer. In addition, the implementation
MUST NOT use silence suppression for media it generates, regardless MUST NOT use silence suppression for media it generates, regardless
of whether the "CN" codecs or related fmtp parameters appear in the of whether the "CN" codecs or related fmtp parameters appear in the
peer's description. The impact of these rules is that silence peer's description. The impact of these rules is that silence
suppression in JSEP depends on mutual agreement of both sides, which suppression in JSEP depends on mutual agreement of both sides, which
ensures consistent handling regardless of which codec is used. ensures consistent handling regardless of which codec is used.
The "VoiceActivityDetection" option does not have any impact on the The VoiceActivityDetection option does not have any impact on the
setting of the "vad" value in the signaling of the client-to-mixer setting of the "vad" value in the signaling of the client-to-mixer
audio level header extension described in [RFC6464], Section 4. audio level header extension described in [RFC6464], Section 4.
5.3. Generating an Answer 5.3. Generating an Answer
When createAnswer is called, a new SDP description MUST be created When createAnswer is called, a new SDP description MUST be created
that is compatible with the supplied remote description as well as that is compatible with the supplied remote description as well as
the requirements specified in [RFC8834]. The exact details of this the requirements specified in [RFC8834]. The exact details of this
process are explained below. process are explained below.
skipping to change at page 52, line 28 skipping to change at line 2400
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
The example in Section 7.2 shows a more involved case of "LS" group The example in Section 7.2 shows a more involved case of "LS" group
generation. generation.
The next step is to generate a "m=" section for each "m=" section The next step is to generate an "m=" section for each "m=" section
that is present in the remote offer, as specified in [RFC3264], that is present in the remote offer, as specified in [RFC3264],
Section 6. For the purposes of this discussion, any session-level Section 6. For the purposes of this discussion, any session-level
attributes in the offer that are also valid as media-level attributes attributes in the offer that are also valid as media-level attributes
are considered to be present in each "m=" section. Each offered "m=" are considered to be present in each "m=" section. Each offered "m="
section will have an associated RtpTransceiver, as described in section will have an associated RtpTransceiver, as described in
Section 5.10. If there are more RtpTransceivers than there are "m=" Section 5.10. If there are more RtpTransceivers than there are "m="
sections, the unmatched RtpTransceivers will need to be associated in sections, the unmatched RtpTransceivers will need to be associated in
a subsequent offer. a subsequent offer.
For each offered "m=" section, if any of the following conditions are For each offered "m=" section, if any of the following conditions are
skipping to change at page 54, line 30 skipping to change at line 2498
* If "rtx" is present in the offer, for each primary codec where RTP * If "rtx" is present in the offer, for each primary codec where RTP
retransmission should be used, a corresponding "a=rtpmap" line retransmission should be used, a corresponding "a=rtpmap" line
indicating "rtx" with the clock rate of the primary codec and an indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type of the primary "a=fmtp" line that references the payload type of the primary
codec, as specified in [RFC4588], Section 8.1. codec, as specified in [RFC4588], Section 8.1.
* For each FEC mechanism supported by the application, "a=rtpmap" * For each FEC mechanism supported by the application, "a=rtpmap"
and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC
mechanisms that MUST be supported are specified in [RFC8854], mechanisms that MUST be supported are specified in [RFC8854],
Section 7, and specific usage for each media type is outlined in Section 7, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5 of [RFC8854].
* If this "m=" section is for media with configurable durations of * If this "m=" section is for media with configurable durations of
media per packet, e.g., audio, an "a=maxptime" line, as described media per packet, e.g., audio, an "a=maxptime" line, as described
in Section 5.2. in Section 5.2.
* If this "m=" section is for video media and there are known * If this "m=" section is for video media and there are known
limitations on the size of images that can be decoded, an limitations on the size of images that can be decoded, an
"a=imageattr" line, as specified in Section 3.6. "a=imageattr" line, as specified in Section 3.6.
* For each RTP header extension supported by the application and * For each RTP header extension supported by the application and
skipping to change at page 54, line 52 skipping to change at line 2520
[RFC5285], Section 5. The list of header extensions that SHOULD/ [RFC5285], Section 5. The list of header extensions that SHOULD/
MUST be supported is specified in [RFC8834], Section 5.2. Any MUST be supported is specified in [RFC8834], Section 5.2. Any
header extensions that require encryption MUST be specified as header extensions that require encryption MUST be specified as
indicated in [RFC6904], Section 4. indicated in [RFC6904], Section 4.
* For each RTCP feedback mechanism supported by the application and * For each RTCP feedback mechanism supported by the application and
present in the offer, an "a=rtcp-fb" line, as specified in present in the offer, an "a=rtcp-fb" line, as specified in
[RFC4585], Section 4.2. The list of RTCP feedback mechanisms that [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that
SHOULD/MUST be supported is specified in [RFC8834], Section 5.1. SHOULD/MUST be supported is specified in [RFC8834], Section 5.1.
* If the RtpTransceiver has a sendrecv or sendonly direction: * If the RtpTransceiver has a "sendrecv" or "sendonly" direction:
- For each MediaStream that was associated with the transceiver - For each MediaStream that was associated with the transceiver
when it was created via addTrack or addTransceiver, an "a=msid" when it was created via addTrack or addTransceiver, an "a=msid"
line, as specified in [RFC8830], Section 2, but omitting the line, as specified in [RFC8830], Section 2, but omitting the
"appdata" field. "appdata" field.
Each "m=" section that is not bundled into another "m=" section MUST Each "m=" section that is not bundled into another "m=" section MUST
contain the following attributes (which are of category IDENTICAL or contain the following attributes (which are of category IDENTICAL or
TRANSPORT): TRANSPORT):
skipping to change at page 56, line 24 skipping to change at line 2587
* "a=setup" * "a=setup"
* "a=tls-id" * "a=tls-id"
Note that if media "m=" sections are bundled into a data "m=" Note that if media "m=" sections are bundled into a data "m="
section, then certain TRANSPORT and IDENTICAL attributes may also section, then certain TRANSPORT and IDENTICAL attributes may also
appear in the data "m=" section even if they would otherwise only be appear in the data "m=" section even if they would otherwise only be
appropriate for a media "m=" section (e.g., "a=rtcp-mux"). appropriate for a media "m=" section (e.g., "a=rtcp-mux").
If "a=group" attributes with semantics of "BUNDLE" are offered, If "a=group" attributes with semantics "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as corresponding session-level "a=group" attributes MUST be added as
specified in [RFC5888]. These attributes MUST have semantics specified in [RFC5888]. These attributes MUST have semantics
"BUNDLE" and MUST include all mid identifiers from the offered bundle "BUNDLE" and MUST include all MID identifiers from the offered bundle
groups that have not been rejected. Note that regardless of the groups that have not been rejected. Note that regardless of the
presence of "a=bundle-only" in the offer, all "m=" sections in the presence of "a=bundle-only" in the offer, all "m=" sections in the
answer MUST NOT have an "a=bundle-only" line. answer MUST NOT have an "a=bundle-only" line.
Attributes that are common between all "m=" sections MAY be moved to Attributes that are common between all "m=" sections MAY be moved to
the session level if explicitly defined to be valid at the session the session level if explicitly defined to be valid at the session
level. level.
The attributes prohibited in the creation of offers are also The attributes prohibited in the creation of offers are also
prohibited in the creation of answers. prohibited in the creation of answers.
skipping to change at page 58, line 28 skipping to change at line 2677
same rules as for an initial answer. same rules as for an initial answer.
5.3.3. Options Handling 5.3.3. Options Handling
The createAnswer method takes as a parameter an RTCAnswerOptions The createAnswer method takes as a parameter an RTCAnswerOptions
object. The set of parameters for RTCAnswerOptions is different than object. The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the IceRestart option is those supported in RTCOfferOptions; the IceRestart option is
unnecessary, as ICE credentials will automatically be changed for all unnecessary, as ICE credentials will automatically be changed for all
"m=" sections where the offerer chose to perform ICE restart. "m=" sections where the offerer chose to perform ICE restart.
The following options are supported in RTCAnswerOptions. The following option is supported in RTCAnswerOptions.
5.3.3.1. VoiceActivityDetection 5.3.3.1. VoiceActivityDetection
Silence suppression in the answer is handled as described in Silence suppression in the answer is handled as described in
Section 5.2.3.2, with one exception: if support for silence Section 5.2.3.2, with one exception: if support for silence
suppression was not indicated in the offer, the suppression was not indicated in the offer, the
VoiceActivityDetection parameter has no effect, and the answer MUST VoiceActivityDetection parameter has no effect, and the answer MUST
be generated as if VoiceActivityDetection was set to "false". This be generated as if VoiceActivityDetection was set to "false". This
is done on a per-codec basis (e.g., if the offerer somehow offered is done on a per-codec basis (e.g., if the offerer somehow offered
support for CN but set "usedtx=0" for Opus, setting support for CN but set "usedtx=0" for Opus, setting
VoiceActivityDetection to "true" would result in an answer with CN VoiceActivityDetection to "true" would result in an answer with "CN"
codecs and "usedtx=0"). The impact of this rule is that an answerer codecs and "usedtx=0"). The impact of this rule is that an answerer
will not try to use silence suppression with any endpoint that does will not try to use silence suppression with any endpoint that does
not offer it, making silence suppression support bilateral even with not offer it, making silence suppression support bilateral even with
non-JSEP endpoints. non-JSEP endpoints.
5.4. Modifying an Offer or Answer 5.4. Modifying an Offer or Answer
The SDP returned from createOffer or createAnswer MUST NOT be changed The SDP returned from createOffer or createAnswer MUST NOT be changed
before passing it to setLocalDescription. If precise control over before passing it to setLocalDescription. If precise control over
the SDP is needed, the aforementioned createOffer/createAnswer the SDP is needed, the aforementioned createOffer/createAnswer
skipping to change at page 61, line 8 skipping to change at line 2796
MUST be returned. Note that this implies that once the answerer has MUST be returned. Note that this implies that once the answerer has
performed setLocalDescription with its answer, this cannot be rolled performed setLocalDescription with its answer, this cannot be rolled
back. back.
The effect of rollback MUST be the same regardless of whether The effect of rollback MUST be the same regardless of whether
setLocalDescription or setRemoteDescription is called. setLocalDescription or setRemoteDescription is called.
In order to process rollback, a JSEP implementation abandons the In order to process rollback, a JSEP implementation abandons the
current offer/answer transaction, sets the signaling state to current offer/answer transaction, sets the signaling state to
"stable", and sets the pending local and/or remote description (see "stable", and sets the pending local and/or remote description (see
Sections 4.1.14 and 4.1.16) to "null". Any resources or candidates Sections 4.1.14 and 4.1.16) to null. Any resources or candidates
that were allocated by the abandoned local description are discarded; that were allocated by the abandoned local description are discarded;
any media that is received is processed according to the previous any media that is received is processed according to the previous
local and remote descriptions. local and remote descriptions.
A rollback disassociates any RtpTransceivers that were associated A rollback disassociates any RtpTransceivers that were associated
with "m=" sections by the application of the rolled-back session with "m=" sections by the application of the rolled-back session
description (see Sections 5.10 and 5.9). This means that some description (see Sections 5.10 and 5.9). This means that some
RtpTransceivers that were previously associated will no longer be RtpTransceivers that were previously associated will no longer be
associated with any "m=" section; in such cases, the value of the associated with any "m=" section; in such cases, the value of the
RtpTransceiver's mid property MUST be set to "null", and the mapping RtpTransceiver's mid property MUST be set to null, and the mapping
between the transceiver and its "m=" section index MUST be discarded. between the transceiver and its "m=" section index MUST be discarded.
RtpTransceivers that were created by applying a remote offer that was RtpTransceivers that were created by applying a remote offer that was
subsequently rolled back MUST be stopped and removed from the subsequently rolled back MUST be stopped and removed from the
PeerConnection. However, an RtpTransceiver MUST NOT be removed if a PeerConnection. However, an RtpTransceiver MUST NOT be removed if a
track was attached to the RtpTransceiver via the addTrack method. track was attached to the RtpTransceiver via the addTrack method.
This is so that an application may call addTrack, then call This is so that an application may call addTrack, then call
setRemoteDescription with an offer, then roll back that offer, then setRemoteDescription with an offer, then roll back that offer, then
call createOffer and have an "m=" section for the added track appear call createOffer and have an "m=" section for the added track appear
in the generated offer. in the generated offer.
skipping to change at page 62, line 40 skipping to change at line 2870
Section 5.2. Section 5.2.
* The "b=" line, if present, MUST be parsed as specified in * The "b=" line, if present, MUST be parsed as specified in
[RFC4566], Section 5.8, and the bwtype and bandwidth values [RFC4566], Section 5.8, and the bwtype and bandwidth values
stored. stored.
Finally, the attribute lines are processed. Specific processing MUST Finally, the attribute lines are processed. Specific processing MUST
be applied for the following session-level attribute ("a=") lines: be applied for the following session-level attribute ("a=") lines:
* Any "a=group" lines are parsed as specified in [RFC5888], * Any "a=group" lines are parsed as specified in [RFC5888],
Section 5, and the group's semantics and mids are stored. Section 5, and the group's semantics and MID values are stored.
* If present, a single "a=ice-lite" line is parsed as specified in * If present, a single "a=ice-lite" line is parsed as specified in
[RFC8839], Section 5.3, and a value indicating the presence of [RFC8839], Section 5.3, and a value indicating the presence of an
ice-lite is stored. "a=ice-lite" line is stored.
* If present, a single "a=ice-ufrag" line is parsed as specified in * If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC8839], Section 5.4, and the ufrag value is stored. [RFC8839], Section 5.4, and the ufrag value is stored.
* If present, a single "a=ice-pwd" line is parsed as specified in * If present, a single "a=ice-pwd" line is parsed as specified in
[RFC8839], Section 5.4, and the password value is stored. [RFC8839], Section 5.4, and the password value is stored.
* If present, a single "a=ice-options" line is parsed as specified * If present, a single "a=ice-options" line is parsed as specified
in [RFC8839], Section 5.6, and the set of specified options is in [RFC8839], Section 5.6, and the set of specified options is
stored. stored.
skipping to change at page 70, line 20 skipping to change at line 3229
candidates, as described in [RFC8445], Section 6.1.2, and start candidates, as described in [RFC8445], Section 6.1.2, and start
connectivity checks with the appropriate credentials. connectivity checks with the appropriate credentials.
* If an "a=end-of-candidates" attribute is present, process the end- * If an "a=end-of-candidates" attribute is present, process the end-
of-candidates indication as described in [RFC8838], Section 14. of-candidates indication as described in [RFC8838], Section 14.
* If the "m=" section <proto> value indicates use of RTP: * If the "m=" section <proto> value indicates use of RTP:
- If the "m=" section is being recycled (see Section 5.2.2), - If the "m=" section is being recycled (see Section 5.2.2),
disassociate the currently associated RtpTransceiver by setting disassociate the currently associated RtpTransceiver by setting
its mid property to "null", and discard the mapping between the its mid property to null, and discard the mapping between the
transceiver and its "m=" section index. transceiver and its "m=" section index.
- If the "m=" section is not associated with any RtpTransceiver - If the "m=" section is not associated with any RtpTransceiver
(possibly because it was disassociated in the previous step), (possibly because it was disassociated in the previous step),
either find an RtpTransceiver or create one according to the either find an RtpTransceiver or create one according to the
following steps: following steps:
o If the "m=" section is sendrecv or recvonly, and there are o If the "m=" section is "sendrecv" or "recvonly", and there
RtpTransceivers of the same type that were added to the are RtpTransceivers of the same type that were added to the
PeerConnection by addTrack and are not associated with any PeerConnection by addTrack and are not associated with any
"m=" section and are not stopped, find the first (according "m=" section and are not stopped, find the first (according
to the canonical order described in Section 5.2.1) such to the canonical order described in Section 5.2.1) such
RtpTransceiver. RtpTransceiver.
o If no RtpTransceiver was found in the previous step, create o If no RtpTransceiver was found in the previous step, create
one with a recvonly direction. one with a "recvonly" direction.
o Associate the found or created RtpTransceiver with the "m=" o Associate the found or created RtpTransceiver with the "m="
section by setting the value of the RtpTransceiver's mid section by setting the value of the RtpTransceiver's mid
property to the MID of the "m=" section, and establish a property to the MID of the "m=" section, and establish a
mapping between the transceiver and the index of the "m=" mapping between the transceiver and the index of the "m="
section. If the "m=" section does not include a MID (i.e., section. If the "m=" section does not include a MID (i.e.,
the remote endpoint does not support the MID extension), the remote endpoint does not support the MID extension),
generate a value for the RtpTransceiver mid property, generate a value for the RtpTransceiver mid property,
following the guidance for "a=mid" mentioned in following the guidance for "a=mid" mentioned in
Section 5.2.1. Section 5.2.1.
skipping to change at page 71, line 19 skipping to change at line 3277
- For each specified "rtx" media format, establish a mapping - For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload between the RTX payload type and its associated primary payload
type, as described in [RFC4588], Section 4. If any referenced type, as described in [RFC4588], Section 4. If any referenced
primary payload types are not present, this MUST result in an primary payload types are not present, this MUST result in an
error. Note that RTX payload types may refer to primary error. Note that RTX payload types may refer to primary
payload types that are not supported by the local media payload types that are not supported by the local media
implementation, in which case the RTX payload type MUST also be implementation, in which case the RTX payload type MUST also be
ignored. ignored.
- For each specified fmtp parameter that is supported by the - For each specified fmtp parameter that is supported by the
local implementation, enable them on the associated media local application, enable them on the associated media formats.
formats.
- For each specified Synchronization Source (SSRC) that is - For each specified Synchronization Source (SSRC) that is
signaled in the "m=" section, prepare to demux RTP streams signaled in the "m=" section, prepare to demux RTP streams
intended for this "m=" section using that SSRC, as described in intended for this "m=" section using that SSRC, as described in
[RFC9143], Section 9.2. [RFC9143], Section 9.2.
- For each specified RTP header extension that is also supported - For each specified RTP header extension that is also supported
by the local application, establish a mapping between the by the local application, establish a mapping between the
extension ID and URI, as described in [RFC5285], Section 5. extension ID and URI, as described in [RFC5285], Section 5.
Specifically, this means that the implementation records the Specifically, this means that the implementation records the
extension ID to be used in outgoing RTP packets when sending extension ID to be used in outgoing RTP packets when sending
each specified header extension. If any indicated RTP header each specified header extension. If any indicated RTP header
extension is not supported by the local application, it MUST be extension is not supported by the local application, it MUST be
ignored. ignored.
- For each specified RTCP feedback mechanism that is also - For each specified RTCP feedback mechanism that is also
supported by the local application, enable them on the supported by the local application, enable them on the
associated media formats. associated media formats.
- For any specified "TIAS" ("Transport Independent Application - For any specified "TIAS" ("Transport Independent Application
Specific Maximum") bandwidth value, set this value as a Specific (maximum)") bandwidth value, set this value as a
constraint on the maximum RTP bitrate to be used when sending constraint on the maximum RTP bitrate to be used when sending
media, as specified in [RFC3890]. If a "TIAS" value is not media, as specified in [RFC3890]. If a "TIAS" value is not
present but an "AS" value is specified, generate a "TIAS" value present but an "AS" value is specified, generate a "TIAS" value
using this formula: using this formula:
TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)
The 1000 changes the unit from kbps to bps (as required by The 1000 changes the unit from kbps to bps (as required by
TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of
header overhead is then subtracted out, in which the 50 is header overhead is then subtracted out, in which the 50 is
skipping to change at page 73, line 9 skipping to change at line 3359
In addition to the steps mentioned above for processing a local or In addition to the steps mentioned above for processing a local or
remote description, the following steps are performed when processing remote description, the following steps are performed when processing
a description of type "pranswer" or "answer". a description of type "pranswer" or "answer".
For each "m=" section, the following steps MUST be performed: For each "m=" section, the following steps MUST be performed:
* If the "m=" section has been rejected (i.e., the <port> value is * If the "m=" section has been rejected (i.e., the <port> value is
set to zero in the answer), stop any reception or transmission of set to zero in the answer), stop any reception or transmission of
media for this section, and, unless a non-rejected "m=" section is media for this section, and, unless a non-rejected "m=" section is
bundled with this "m=" section, discard any associated ICE bundled with this "m=" section, discard any associated ICE
components, as described in [RFC8839], Section 4.4.3.1. components, as described in the second bullet item in [RFC8839],
Section 4.4.3.1.
* If the remote DTLS fingerprint has been changed or the value of * If the remote DTLS fingerprint has been changed or the value of
the "a=tls-id" attribute has changed, tear down the DTLS the "a=tls-id" attribute has changed, tear down the DTLS
connection. This includes the case when the PeerConnection state connection. This includes the case when the PeerConnection state
is "have-remote-pranswer". If a DTLS connection needs to be torn is "have-remote-pranswer". If a DTLS connection needs to be torn
down but the answer does not indicate an ICE restart or, in the down but the answer does not indicate an ICE restart or, in the
case of "have-remote-pranswer", new ICE credentials, an error MUST case of "have-remote-pranswer", new ICE credentials, an error MUST
be generated. If an ICE restart is performed without a change in be generated. If an ICE restart is performed without a change in
the tls-id value or fingerprint, then the same DTLS connection is the tls-id value or fingerprint, then the same DTLS connection is
continued over the new ICE channel. Note that although JSEP continued over the new ICE channel. Note that although JSEP
skipping to change at page 76, line 11 skipping to change at line 3501
section is defined in [RFC9143], Section 9.2. When not bundling, the section is defined in [RFC9143], Section 9.2. When not bundling, the
proper "m=" section is clear from the ICE component over which the proper "m=" section is clear from the ICE component over which the
RTP/RTCP is received. RTP/RTCP is received.
Once the proper "m=" section or sections are known, RTP/RTCP is Once the proper "m=" section or sections are known, RTP/RTCP is
delivered to the RtpTransceiver(s) associated with the "m=" delivered to the RtpTransceiver(s) associated with the "m="
section(s) and further processing of the RTP/RTCP is done at the section(s) and further processing of the RTP/RTCP is done at the
RtpTransceiver level. This includes using the RID mechanism RtpTransceiver level. This includes using the RID mechanism
[RFC8851] and its associated RtpStreamId and RepairedRtpStreamId [RFC8851] and its associated RtpStreamId and RepairedRtpStreamId
identifiers to distinguish between multiple encoded streams and identifiers to distinguish between multiple encoded streams and
determine which Source RTP stream should be repaired by a given determine which Source RTP Stream should be repaired by a given
redundancy RTP stream. redundancy RTP stream.
7. Examples 7. Examples
Note that this example section shows several SDP fragments. To Note that this example section shows several SDP fragments. To
accommodate RFC line-length restrictions, some of the SDP lines have accommodate RFC line-length restrictions, some of the SDP lines have
been split into multiple lines, where leading whitespace indicates been split into multiple lines, where leading whitespace indicates
that a line is a continuation of the previous line. In addition, that a line is a continuation of the previous line. In addition,
some blank lines have been added to improve readability but are not some blank lines have been added to improve readability but are not
valid in SDP. valid in SDP.
skipping to change at page 80, line 41 skipping to change at line 3713
7.2. Detailed Example 7.2. Detailed Example
This section shows a more involved example of a session between two This section shows a more involved example of a session between two
JSEP endpoints. Trickle ICE is used in full trickle mode, with a JSEP endpoints. Trickle ICE is used in full trickle mode, with a
bundle policy of "must-bundle", an RTCP mux policy of "require", and bundle policy of "must-bundle", an RTCP mux policy of "require", and
a single TURN server. Initially, both Alice and Bob establish an a single TURN server. Initially, both Alice and Bob establish an
audio channel and a data channel. Later, Bob adds two video flows -- audio channel and a data channel. Later, Bob adds two video flows --
one for his video feed and one for screen sharing, both supporting one for his video feed and one for screen sharing, both supporting
FEC -- with the video feed configured for simulcast. Alice accepts FEC -- with the video feed configured for simulcast. Alice accepts
these video flows but does not add video flows of her own, so they these video flows but does not add video flows of her own, so they
are handled as recvonly. Alice also specifies a maximum video are handled as "recvonly". Alice also specifies a maximum video
decoder resolution. decoder resolution.
// 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
skipping to change at page 86, line 24 skipping to change at line 3944
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
The SDP for |offer-B2| is shown below. In addition to the new "m=" The SDP for |offer-B2| is shown below. In addition to the new "m="
sections for video, both of which are offering FEC and one of which sections for video, both of which are offering FEC and one of which
is offering simulcast, note the increment of the version number in is offering simulcast, note the increment of the version number in
the "o=" line; changes to the "c=" line, indicating the local the "o=" line; changes to the "c=" line, indicating the local
candidate that was selected; and the inclusion of gathered candidates candidate that was selected; and the inclusion of gathered candidates
as a=candidate lines. as "a=candidate" lines.
v=0 v=0
o=- 7729291447651054566 2 IN IP4 0.0.0.0 o=- 7729291447651054566 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1 a=group:LS a1 v1
m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
skipping to change at page 88, line 18 skipping to change at line 4035
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
The SDP for |answer-B2| is shown below. In addition to the 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 the received resolution, note the use of "a=setup:passive" to maintain
existing DTLS roles. the existing DTLS roles.
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
skipping to change at page 90, line 15 skipping to change at line 4128
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
7.3. Early Transport Warmup Example 7.3. Early Transport Warmup Example
This example demonstrates the early-warmup technique described in This example demonstrates the early-warmup technique described in
Section 4.1.10.1. Here, Alice's endpoint sends an offer to Bob's Section 4.1.10.1. Here, Alice's endpoint sends an offer to Bob's
endpoint to start an audio/video call. Bob immediately responds with endpoint to start an audio/video call. Bob immediately responds with
an answer that accepts the audio/video "m=" sections but marks them an answer that accepts the audio/video "m=" sections but marks them
as sendonly (from his perspective), meaning that Alice will not yet as "sendonly" (from his perspective), meaning that Alice will not yet
send media. This allows the JSEP implementation to start negotiating send media. This allows the JSEP implementation to start negotiating
ICE and DTLS immediately. Bob's endpoint then prompts him to answer ICE and DTLS immediately. Bob's endpoint then prompts him to answer
the call, and when he does, his endpoint sends a second offer, which the call, and when he does, his endpoint sends a second offer, which
enables the audio and video "m=" sections, and thereby bidirectional enables the audio and video "m=" sections, and thereby bidirectional
media transmission. The advantage of such a flow is that as soon as media transmission. The advantage of such a flow is that as soon as
the first answer is received, the implementation can proceed with ICE the first answer is received, the implementation can proceed with ICE
and DTLS negotiation and establish the session transport. If the and DTLS negotiation and establish the session transport. If the
transport setup completes before the second offer is sent, then media transport setup completes before the second offer is sent, then media
can be transmitted by the callee immediately upon answering the call, can be transmitted by the callee immediately upon answering the call,
minimizing perceived post-dial delay. The second offer/answer minimizing perceived post-dial delay. The second offer/answer
skipping to change at page 97, line 37 skipping to change at line 4484
JSEP implementation MUST be prepared for the JavaScript to pass in JSEP implementation MUST be prepared for the JavaScript to pass in
bogus data instead. bogus data instead.
Conversely, the application programmer needs to be aware that the Conversely, the application programmer needs to be aware that the
JavaScript does not have complete control of endpoint behavior. One JavaScript does not have complete control of endpoint behavior. One
case that bears particular mention is that editing ICE candidates out case that bears particular mention is that editing ICE candidates out
of the SDP or suppressing trickled candidates does not have the of the SDP or suppressing trickled candidates does not have the
expected behavior: implementations will still perform checks from expected behavior: implementations will still perform checks from
those candidates even if they are not sent to the other side. Thus, those candidates even if they are not sent to the other side. Thus,
for instance, it is not possible to prevent the remote peer from for instance, it is not possible to prevent the remote peer from
learning your public IP address by removing server-reflexive learning an application's public IP address by removing server-
candidates. Applications that wish to conceal their public IP reflexive candidates. Applications that wish to conceal their public
address MUST instead configure the ICE agent to use only relay IP address MUST instead configure the ICE agent to use only relay
candidates. candidates.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 102, line 40 skipping to change at line 4718
Protocol (SDP) Attributes When Multiplexing", RFC 8859, Protocol (SDP) Attributes When Multiplexing", RFC 8859,
DOI 10.17487/RFC8859, January 2021, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>. <https://www.rfc-editor.org/info/rfc8859>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143, Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022, DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>. <https://www.rfc-editor.org/info/rfc9143>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
10.2. Informative References 10.2. Informative References
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
September 2002, <https://www.rfc-editor.org/info/rfc3389>. September 2002, <https://www.rfc-editor.org/info/rfc3389>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, DOI 10.17487/RFC3556, July 2003, RFC 3556, DOI 10.17487/RFC3556, July 2003,
<https://www.rfc-editor.org/info/rfc3556>. <https://www.rfc-editor.org/info/rfc3556>.
skipping to change at page 104, line 35 skipping to change at line 4812
[SDP4WebRTC] [SDP4WebRTC]
Nandakumar, S. and C. F. Jennings, "Annotated Example SDP Nandakumar, S. and C. F. Jennings, "Annotated Example SDP
for WebRTC", Work in Progress, Internet-Draft, draft-ietf- for WebRTC", Work in Progress, Internet-Draft, draft-ietf-
rtcweb-sdp-14, 17 December 2020, rtcweb-sdp-14, 17 December 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb- <https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-
sdp-14>. sdp-14>.
[TS26.114] 3GPP, "3rd Generation Partnership Project; Technical [TS26.114] 3GPP, "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 16)", 3GPP TS 26.114 handling and interaction (Release 18)", 3GPP TS 26.114
V16.3.0, September 2019, V18.4.0, September 2023,
<https://www.3gpp.org/DynaReport/26114.htm>. <https://www.3gpp.org/DynaReport/26114.htm>.
[W3C.webrtc] [W3C.webrtc]
Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed., Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed.,
"WebRTC 1.0: Real-time Communication Between Browsers", and J-I. Bruaroey, Ed., "WebRTC: Real-time Communication
World Wide Web Consortium Recommendation, January 2021, Between Browsers", W3C Recommendation, March 2023,
<https://www.w3.org/TR/2021/REC-webrtc-20210126/>. <https://www.w3.org/TR/2023/REC-webrtc-20230306/>.
Appendix A. SDP ABNF Syntax Appendix A. SDP ABNF Syntax
For the syntax validation performed in Section 5.8, the following For the syntax validation performed in Section 5.8, the following
list of ABNF definitions is used: list of ABNF definitions is used:
+=========================+==========================+ +=========================+===============================+
| Attribute | Reference | | Attribute | Reference |
+=========================+==========================+ +=========================+===============================+
| ptime | Section 6 of [RFC4566] | | ptime | Section 6 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| maxptime | Section 6 of [RFC4566] | | maxptime | Section 6 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| rtpmap | Section 6 of [RFC4566] | | rtpmap | Section 6 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| recvonly | Section 9 of [RFC4566] | | recvonly | Sections 6 and 9 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| sendrecv | Section 9 of [RFC4566] | | sendrecv | Sections 6 and 9 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| sendonly | Section 9 of [RFC4566] | | sendonly | Sections 6 and 9 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| inactive | Section 9 of [RFC4566] | | inactive | Sections 6 and 9 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| fmtp | Section 9 of [RFC4566] | | fmtp | Sections 6 and 9 of [RFC4566] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| rtcp | Section 2.1 of [RFC3605] | | rtcp | Section 2.1 of [RFC3605] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| setup | Section 4 of [RFC4145] | | setup | Section 4 of [RFC4145] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| fingerprint | Section 5 of [RFC8122] | | fingerprint | Section 5 of [RFC8122] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| rtcp-fb | Section 4.2 of [RFC4585] | | rtcp-fb | Section 4.2 of [RFC4585] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| extmap | Section 7 of [RFC5285] | | extmap | Section 7 of [RFC5285] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| mid | Section 4 of [RFC5888] | | mid | Section 4 of [RFC5888] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| group | Section 5 of [RFC5888] | | group | Section 5 of [RFC5888] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| imageattr | Section 3.1 of [RFC6236] | | imageattr | Section 3.1 of [RFC6236] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| extmap (encrypt option) | Section 4 of [RFC6904] | | extmap (encrypt option) | Section 4 of [RFC6904] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| candidate | Section 5.1 of [RFC8839] | | candidate | Section 5.1 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| remote-candidates | Section 5.2 of [RFC8839] | | remote-candidates | Section 5.2 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| ice-lite | Section 5.3 of [RFC8839] | | ice-lite | Section 5.3 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| ice-ufrag | Section 5.4 of [RFC8839] | | ice-ufrag | Section 5.4 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| ice-pwd | Section 5.4 of [RFC8839] | | ice-pwd | Section 5.4 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| ice-options | Section 5.6 of [RFC8839] | | ice-options | Section 5.6 of [RFC8839] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| msid | Section 3 of [RFC8830] | | msid | Section 3 of [RFC8830] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| rid | Section 10 of [RFC8851] | | rid | Section 10 of [RFC8851] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| simulcast | Section 5.1 of [RFC8853] | | simulcast | Section 5.1 of [RFC8853] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
| tls-id | Section 4 of [RFC8842] | | tls-id | Section 4 of [RFC8842] |
+-------------------------+--------------------------+ +-------------------------+-------------------------------+
Table 1: SDP ABNF References Table 1: SDP ABNF References
Acknowledgements Acknowledgements
Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter
Thatcher provided significant text for this document. Bernard Aboba, Thatcher provided significant text for RFC 8829 (and thereby this
Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa document). Bernard Aboba, Adam Bergkvist, Jan-Ivar Bruaroey, Dan
Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer Burnett, Ben Campbell, Alissa Cooper, Richard Ejzak, Stefan
Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Håkansson, Ted Hardie, Christer Holmberg, Andrew Hutton, Randell
Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Jesup, Matthew Kaufman, Anant Narayanan, Adam Roach, Robert Sparks,
Sean Turner, and Magnus Westerlund all provided valuable feedback on Neil Stratford, Martin Thomson, Sean Turner, and Magnus Westerlund
this document. all provided valuable feedback on RFC 8829 (and thereby this
document).
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Email: justin@uberti.name Email: justin@uberti.name
Cullen Jennings Cullen Jennings
Cisco Cisco
400 3rd Avenue SW 400 3rd Avenue SW
Calgary AB T2P 4H2 Calgary AB T2P 4H2
 End of changes. 75 change blocks. 
322 lines changed or deleted 326 lines changed or added

This html diff was produced by rfcdiff 1.48.