rfc8829.txt   draft-uberti-rtcweb-rfc8829bis-00.txt >
Internet Engineering Task Force (IETF) J. Uberti Network Working Group J. Uberti
Request for Comments: 8829 Google Internet-Draft Clubhouse
Category: Standards Track C. Jennings Obsoletes: 8829 (if approved) C. Jennings
ISSN: 2070-1721 Cisco Intended status: Standards Track Cisco
E. Rescorla, Ed. Expires: 11 January 2022 E. Rescorla, Ed.
Mozilla Mozilla
January 2021 10 July 2021
JavaScript Session Establishment Protocol (JSEP) JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-00
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.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
https://www.rfc-editor.org/info/rfc8829. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Design of JSEP 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4
1.2. Other Approaches Considered 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 6
1.3. Contradiction regarding bundle-only "m=" sections 1.3. Changes from RFC 8829 . . . . . . . . . . . . . . . . . . 7
2. Terminology 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Semantics and Syntax 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 7
3.1. Signaling Model 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 7
3.2. Session Descriptions and State Machine 3.2. Session Descriptions and State Machine . . . . . . . . . 8
3.3. Session Description Format 3.3. Session Description Format . . . . . . . . . . . . . . . 11
3.4. Session Description Control 3.4. Session Description Control . . . . . . . . . . . . . . . 11
3.4.1. RtpTransceivers 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11
3.4.2. RtpSenders 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12
3.4.3. RtpReceivers 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12
3.5. ICE 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1. ICE Gathering Overview 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12
3.5.2. ICE Candidate Trickling 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13
3.5.2.1. ICE Candidate Format 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 14
3.5.3. ICE Candidate Policy 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14
3.5.4. ICE Candidate Pool 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15
3.5.5. ICE Versions 3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16
3.6. Video Size Negotiation 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16
3.6.1. Creating an imageattr Attribute 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 17
3.6.2. Interpreting imageattr Attributes 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17
3.7. Simulcast 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8. Interactions with Forking 3.8. Interactions with Forking . . . . . . . . . . . . . . . . 21
3.8.1. Sequential Forking 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 21
3.8.2. Parallel Forking 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 22
4. Interface 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. PeerConnection 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Constructor 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. addTrack 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3. removeTrack 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 25
4.1.4. addTransceiver 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25
4.1.5. onaddtrack Event 4.1.5. onaddtrack Event . . . . . . . . . . . . . . . . . . 26
4.1.6. createDataChannel 4.1.6. createDataChannel . . . . . . . . . . . . . . . . . . 26
4.1.7. ondatachannel Event 4.1.7. ondatachannel Event . . . . . . . . . . . . . . . . . 26
4.1.8. createOffer 4.1.8. createOffer . . . . . . . . . . . . . . . . . . . . . 26
4.1.9. createAnswer 4.1.9. createAnswer . . . . . . . . . . . . . . . . . . . . 27
4.1.10. SessionDescriptionType 4.1.10. SessionDescriptionType . . . . . . . . . . . . . . . 28
4.1.10.1. Use of Provisional Answers 4.1.10.1. Use of Provisional Answers . . . . . . . . . . . 29
4.1.10.2. Rollback 4.1.10.2. Rollback . . . . . . . . . . . . . . . . . . . . 30
4.1.11. setLocalDescription 4.1.11. setLocalDescription . . . . . . . . . . . . . . . . . 30
4.1.12. setRemoteDescription 4.1.12. setRemoteDescription . . . . . . . . . . . . . . . . 31
4.1.13. currentLocalDescription 4.1.13. currentLocalDescription . . . . . . . . . . . . . . . 31
4.1.14. pendingLocalDescription 4.1.14. pendingLocalDescription . . . . . . . . . . . . . . . 31
4.1.15. currentRemoteDescription 4.1.15. currentRemoteDescription . . . . . . . . . . . . . . 32
4.1.16. pendingRemoteDescription 4.1.16. pendingRemoteDescription . . . . . . . . . . . . . . 32
4.1.17. canTrickleIceCandidates 4.1.17. canTrickleIceCandidates . . . . . . . . . . . . . . . 32
4.1.18. setConfiguration 4.1.18. setConfiguration . . . . . . . . . . . . . . . . . . 33
4.1.19. addIceCandidate 4.1.19. addIceCandidate . . . . . . . . . . . . . . . . . . . 34
4.1.20. onicecandidate Event 4.1.20. onicecandidate Event . . . . . . . . . . . . . . . . 34
4.2. RtpTransceiver 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 35
4.2.1. stop 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2. stopped 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3. setDirection 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 35
4.2.4. direction 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 36
4.2.5. currentDirection 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 36
4.2.6. setCodecPreferences 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 36
5. SDP Interaction Procedures 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 37
5.1. Requirements Overview 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 37
5.1.1. Usage Requirements 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 37
5.1.2. Profile Names and Interoperability 5.1.2. Profile Names and Interoperability . . . . . . . . . 37
5.2. Constructing an Offer 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 39
5.2.1. Initial Offers 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 39
5.2.2. Subsequent Offers 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 45
5.2.3. Options Handling 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 49
5.2.3.1. IceRestart 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 49
5.2.3.2. VoiceActivityDetection 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 49
5.3. Generating an Answer 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 50
5.3.1. Initial Answers 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 50
5.3.2. Subsequent Answers 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 56
5.3.3. Options Handling 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 58
5.3.3.1. VoiceActivityDetection 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 58
5.4. Modifying an Offer or Answer 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 58
5.5. Processing a Local Description 5.5. Processing a Local Description . . . . . . . . . . . . . 59
5.6. Processing a Remote Description 5.6. Processing a Remote Description . . . . . . . . . . . . . 60
5.7. Processing a Rollback 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 60
5.8. Parsing a Session Description 5.8. Parsing a Session Description . . . . . . . . . . . . . . 61
5.8.1. Session-Level Parsing 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 62
5.8.2. Media Section Parsing 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 63
5.8.3. Semantics Verification 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 66
5.9. Applying a Local Description 5.9. Applying a Local Description . . . . . . . . . . . . . . 67
5.10. Applying a Remote Description 5.10. Applying a Remote Description . . . . . . . . . . . . . . 68
5.11. Applying an Answer 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 72
6. Processing RTP/RTCP 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 75
7. Examples 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1. Simple Example 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 76
7.2. Detailed Example 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 80
7.3. Early Transport Warmup Example 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 90
8. Security Considerations 8. Security Considerations . . . . . . . . . . . . . . . . . . . 97
9. IANA Considerations 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
10. References 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.1. Normative References 10.1. Normative References . . . . . . . . . . . . . . . . . . 97
10.2. Informative References 10.2. Informative References . . . . . . . . . . . . . . . . . 102
Appendix A. SDP ABNF Syntax Appendix A. SDP ABNF Syntax . . . . . . . . . . . . . . . . . . 104
Acknowledgements Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
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 line 278 skipping to change at page 7, line 5
API, which would provide the application with the information it API, which would provide the application with the information it
needed in order to generate its own session descriptions. This needed in order to generate its own session descriptions. This
increases the amount of work that the application needs to do; it increases the amount of work that the application needs to do; it
needs to know how to generate session descriptions from capabilities, needs to know how to generate session descriptions from capabilities,
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. Contradiction regarding bundle-only "m=" sections 1.3. Changes from RFC 8829
Since the approval of the WebRTC specification documents, the IETF
has become aware of an inconsistency between the document specifying
JSEP and the document specifying BUNDLE (this RFC and [RFC8843],
respectively). Rather than delaying publication further to come to a
resolution, the documents are being published as they were originally
approved. The IETF intends to restart work on these technologies,
and revised versions of these documents will be published as soon as
a resolution becomes available.
The specific issue involves the handling of "m=" sections that are
designated as bundle-only, as discussed in Section 4.1.1 of this RFC.
Currently, there is divergence between JSEP and BUNDLE, as well as
between these specifications and existing browser implementations:
* JSEP prescribes that said "m=" sections should use port zero and
add an "a=bundle-only" attribute in initial offers, but not in
answers or subsequent offers.
* BUNDLE prescribes that these "m=" sections should be marked as
described in the previous point, but in all offers and answers.
* Most current browsers do not mark any "m=" sections with port zero When [RFC8829] was published, an inconsistency regarding BUNDLE
and instead use the same port for all bundled "m=" sections; some [RFC8843] operation was identified concerning both the specification
others follow the JSEP behavior. text as well as implementation behavior. The former concern was
addressed via an update to [RFC8843]. For the latter concern, it was
observed that some implementations implemented the "max-bundle"
bundle policy by assuming that bundling had already been negotiated,
rather than marking "m=" sections as bundle-only as indicated by
[RFC8829]. In order to prevent unexpected changes to applications
relying on the pre-standard behavior, the decision was made to
deprecate the use of "max-bundle" and instead introduce a new "must-
bundle" policy that, when selected, provides the correct behavior.
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 line 787 skipping to change at page 17, line 36
codecs supported have the same capabilities, use of a single codecs supported have the same capabilities, use of a single
attribute, with the wildcard payload type (*), is RECOMMENDED. attribute, with the wildcard payload type (*), is RECOMMENDED.
However, when the supported video codecs have different limitations, However, when the supported video codecs have different limitations,
specific "a=imageattr" attributes MUST be inserted for each payload specific "a=imageattr" attributes MUST be inserted for each payload
type. type.
As an example, consider a system with a multiformat video decoder, As an example, consider a system with a multiformat video decoder,
which is capable of decoding any resolution from 48x48 to 720p. In which is capable of decoding any resolution from 48x48 to 720p. In
this case, the implementation would generate this attribute: this case, the implementation would generate this attribute:
a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]
This declaration indicates that the receiver is capable of decoding This declaration indicates that the receiver is capable of decoding
any image resolution from 48x48 up to 1280x720 pixels. any image resolution from 48x48 up to 1280x720 pixels.
3.6.2. Interpreting imageattr Attributes 3.6.2. Interpreting imageattr Attributes
[RFC6236] defines "a=imageattr" to be an advisory field. This means [RFC6236] defines "a=imageattr" to be an advisory field. This means
that it does not absolutely constrain the video formats that the that it does not absolutely constrain the video formats that the
sender can use but gives an indication of the preferred values. sender can use but gives an indication of the preferred values.
skipping to change at line 1056 skipping to change at page 23, line 38
generally the desired policy and also typically reduces the use of generally the desired policy and also typically reduces the use of
application TURN server resources significantly. application TURN server resources significantly.
If a size is specified for the ICE candidate pool, this indicates the If a size is specified for the ICE candidate pool, this indicates the
number of ICE components to pre-gather candidates for. Because number of ICE components to pre-gather candidates for. Because
pre-gathering results in utilizing STUN/TURN server resources for pre-gathering results in utilizing STUN/TURN server resources for
potentially long periods of time, this MUST only occur upon potentially long periods of time, this MUST only occur upon
application request, and therefore the default candidate pool size application request, and therefore the default candidate pool size
MUST be zero. MUST be zero.
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding the use of
bundle, the multiplexing mechanism defined in [RFC8843]. Regardless BUNDLE, the multiplexing mechanism defined in [RFC8843]. Regardless
of policy, the application will always try to negotiate bundle onto a of policy, the application will always try to negotiate bundle onto a
single transport and will offer a single bundle group across all "m=" single transport and will offer a single bundle group across all "m="
sections; use of this single transport is contingent upon the sections; use of this single transport is contingent upon the
answerer accepting bundle. However, by specifying a policy from the answerer accepting bundle. However, by specifying a policy from the
list below, the application can control exactly how aggressively it list below, the application can control exactly how aggressively it
will try to bundle media streams together, which affects how it will will try to bundle media streams together, which affects how it will
interoperate with a non-bundle-aware endpoint. When negotiating with interoperate with a non-bundle-aware endpoint. When negotiating with
a non-bundle-aware endpoint, only the streams not marked as bundle- a non-bundle-aware endpoint, only the streams not marked as bundle-
only streams will be established. only streams will be established.
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 bundle-only. subsequent "m=" sections of each type will be marked as bundle-
The result is that if there are N distinct media types, then only. The result is that if there are N distinct media types,
candidates will be gathered for N media streams. This policy then candidates will be gathered for N media streams. This policy
balances desire to multiplex with the need to ensure that basic balances the desire to multiplex with the need to ensure that
audio and video can still be negotiated in legacy cases. When basic audio and video can still be negotiated in legacy cases.
acting as answerer, if there is no bundle group in the offer, the When acting as answerer, if there is no bundle group in the offer,
implementation will reject all but the first "m=" section of each the implementation will reject all but the first "m=" section of
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 will allow all none will be marked as bundle-only. This policy makes no
streams to be received by non-bundle-aware endpoints but will assumptions about the remote endpoint and as such will allow all
require separate candidates to be gathered for each media stream. streams to be received by non-bundle-aware endpoints, but as a
result requires separate candidates to be gathered for each media
stream.
max-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 aims to minimize candidate gathering and bundle-only. This policy presumes the remote endpoint supports
maximize multiplexing, at the cost of less compatibility with multiplexing and accordingly aims to minimize candidate gathering,
legacy endpoints. When acting as answerer, the implementation at the cost of less compatibility with legacy endpoints. When
will reject any "m=" sections other than the first "m=" section, acting as answerer, the implementation will reject any "m="
unless they are in the same bundle group as that "m=" section. sections other than the first "m=" section, unless 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
defined identically to the "must-bundle" policy described above, was
implemented by some implementations according to an earlier, pre-
standard definition (in which, for example, no "m=" sections were
marked as bundle-only). As a result, "max-bundle" is considered
deprecated, and new applications should use the "must-bundle" policy
instead.
The application can specify its preferred policy regarding use of The application can specify its preferred policy regarding 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="
skipping to change at line 1780 skipping to change at page 39, line 33
The first step in generating an initial offer is to generate session- The first step in generating an initial offer is to generate session-
level attributes, as specified in [RFC4566], Section 5. level attributes, as specified in [RFC4566], Section 5.
Specifically: Specifically:
* The first SDP line MUST be "v=0" as defined in [RFC4566], * The first SDP line MUST be "v=0" as defined in [RFC4566],
Section 5.1. Section 5.1.
* The second SDP line MUST be an "o=" line as defined in [RFC4566], * The second SDP line MUST be an "o=" line as defined in [RFC4566],
Section 5.2. The value of the <username> field SHOULD be "-". Section 5.2. The value of the <username> field SHOULD be "-".
The <sess-id> MUST be representable by a 64-bit signed integer, The <sess-id> MUST be representable by a 64-bit signed integer,
and the value MUST be less than 2^(63)-1. It is RECOMMENDED that and the value MUST be less than 2^63-1. It is RECOMMENDED that
the <sess-id> be constructed by generating a 64-bit quantity with the <sess-id> be constructed by generating a 64-bit quantity with
the highest bit set to zero and the remaining 63 bits being the highest bit set to zero and the remaining 63 bits being
cryptographically random. The value of the <nettype> <addrtype> cryptographically random. The value of the <nettype> <addrtype>
<unicast-address> tuple SHOULD be set to a non-meaningful address, <unicast-address> tuple SHOULD be set to a non-meaningful address,
such as IN IP4 0.0.0.0, to prevent leaking a local IP address in such as IN IP4 0.0.0.0, to prevent leaking a local IP address in
this field; this problem is discussed in [RFC8828]. As mentioned this field; this problem is discussed in [RFC8828]. As mentioned
in [RFC4566], the entire "o=" line needs to be unique, but in [RFC4566], the entire "o=" line needs to be unique, but
selecting a random number for <sess-id> is sufficient to selecting a random number for <sess-id> is sufficient to
accomplish this. accomplish this.
skipping to change at line 1954 skipping to change at page 43, line 19
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 "max- * 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.
The following attributes, which are of category IDENTICAL or The following attributes, which are of category IDENTICAL or
TRANSPORT, MUST appear only in "m=" sections that either have a TRANSPORT, MUST appear only in "m=" sections that either have a
unique address or are associated with the BUNDLE-tag. (In initial unique address or are associated with the BUNDLE-tag. (In initial
offers, this means those "m=" sections that do not contain an offers, this means those "m=" sections that do not contain an
"a=bundle-only" attribute.) "a=bundle-only" attribute.)
skipping to change at line 2388 skipping to change at page 52, line 28
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 an "m=" section for each "m=" section The next step is to generate a "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
true, the corresponding "m=" section in the answer MUST be marked as true, the corresponding "m=" section in the answer MUST be marked as
rejected by setting the <port> in the "m=" line to zero, as indicated rejected by setting the <port> in the "m=" line to zero, as indicated
in [RFC3264], Section 6, and further processing for this "m=" section in [RFC3264], Section 6, and further processing for this "m=" section
can be skipped: can be skipped:
* The associated RtpTransceiver has been stopped. * The associated RtpTransceiver has been stopped.
* There is no offered media format that is both supported and, if * There is no offered media format that is both supported and, if
applicable, allowed by codec preferences. applicable, allowed by codec preferences.
* The bundle policy is "max-bundle", and this is not the first "m=" * The bundle policy is "must-bundle", and this is not the first "m="
section or in the same bundle group as the first "m=" section. section or in the same bundle group as the first "m=" section.
* The bundle policy is "balanced", and this is not the first "m=" * The bundle policy is "balanced", and this is not the first "m="
section for this media type or in the same bundle group as the section for this media type or in the same bundle group as the
first "m=" section for this media type. first "m=" section for this media type.
* This "m=" section is in a bundle group, and the group's offerer * This "m=" section is in a bundle group, and the group's offerer
tagged "m=" section is being rejected due to one of the above tagged "m=" section is being rejected due to one of the above
reasons. This requires all "m=" sections in the bundle group to reasons. This requires all "m=" sections in the bundle group to
be rejected, as specified in [RFC8843], Section 7.3.3. be rejected, as specified in [RFC8843], Section 7.3.3.
skipping to change at line 3097 skipping to change at page 67, line 43
restored to the state it was in before performing these steps. restored to the state it was in before performing these steps.
First, "m=" sections are processed. For each "m=" section, the First, "m=" sections are processed. For each "m=" section, the
following steps MUST be performed; if any parameters are out of following steps MUST be performed; if any parameters are out of
bounds or cannot be applied, processing MUST stop and an error MUST bounds or cannot be applied, processing MUST stop and an error MUST
be returned. be returned.
* If this "m=" section is new, begin gathering candidates for it, as * If this "m=" section is new, begin gathering candidates for it, as
defined in [RFC8445], Section 5.1.1, unless it is definitively defined in [RFC8445], Section 5.1.1, unless it is definitively
being bundled (either (1) this is an offer and the "m=" section is being bundled (either (1) this is an offer and the "m=" section is
marked bundle-only or (2) it is an answer and the "m=" section is marked as bundle-only or (2) it is an answer and the "m=" section
bundled into another "m=" section). is bundled into another "m=" section).
* Or, if the ICE ufrag and password values have changed, trigger the * Or, if the ICE ufrag and password values have changed, trigger the
ICE agent to start an ICE restart as described in [RFC8445], ICE agent to start an ICE restart as described in [RFC8445],
Section 9, and begin gathering new candidates for the "m=" Section 9, and begin gathering new candidates for the "m="
section. If this description is an answer, also start checks on section. If this description is an answer, also start checks on
that media section. that media section.
* If the "m=" section <proto> value indicates use of RTP: * If the "m=" section <proto> value indicates use of RTP:
- If there is no RtpTransceiver associated with this "m=" - If there is no RtpTransceiver associated with this "m="
skipping to change at line 3695 skipping to change at page 80, line 35
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
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 "max-bundle", an RTCP mux policy of "require", and a bundle policy of "must-bundle", an RTCP mux policy of "require", and
single TURN server. Initially, both Alice and Bob establish an audio a single TURN server. Initially, both Alice and Bob establish an
channel and a data channel. Later, Bob adds two video flows -- one audio channel and a data channel. Later, Bob adds two video flows --
for his video feed and one for screen sharing, both supporting FEC -- one for his video feed and one for screen sharing, both supporting
with the video feed configured for simulcast. Alice accepts these FEC -- with the video feed configured for simulcast. Alice accepts
video flows but does not add video flows of her own, so they are these video flows but does not add video flows of her own, so they
handled as recvonly. Alice also specifies a maximum video decoder are handled as recvonly. Alice also specifies a maximum video
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
AliceJS->WebServer: signaling with |offer-B1| AliceJS->WebServer: signaling with |offer-B1|
skipping to change at line 4625 skipping to change at page 101, line 5
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", [RFC8826] Rescorla, E., "Security Considerations for WebRTC",
RFC 8826, DOI 10.17487/RFC8826, January 2021, RFC 8826, DOI 10.17487/RFC8826, January 2021,
<https://www.rfc-editor.org/info/rfc8826>. <https://www.rfc-editor.org/info/rfc8826>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, January 2021, DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/info/rfc8827>. <https://www.rfc-editor.org/info/rfc8827>.
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)",
RFC 8829, DOI 10.17487/RFC8829, January 2021,
<https://www.rfc-editor.org/info/rfc8829>.
[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the [RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", RFC 8830, Session Description Protocol", RFC 8830,
DOI 10.17487/RFC8830, January 2021, DOI 10.17487/RFC8830, January 2021,
<https://www.rfc-editor.org/info/rfc8830>. <https://www.rfc-editor.org/info/rfc8830>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/info/rfc8834>. January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
skipping to change at line 4778 skipping to change at page 104, line 23
<https://www.rfc-editor.org/info/rfc6464>. <https://www.rfc-editor.org/info/rfc6464>.
[RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling [RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling
Requirements", RFC 8828, DOI 10.17487/RFC8828, January Requirements", RFC 8828, DOI 10.17487/RFC8828, January
2021, <https://www.rfc-editor.org/info/rfc8828>. 2021, <https://www.rfc-editor.org/info/rfc8828>.
[SDP4WebRTC] [SDP4WebRTC]
Nandakumar, S. and C. Jennings, "Annotated Example SDP for Nandakumar, S. and C. Jennings, "Annotated Example SDP for
WebRTC", Work in Progress, Internet-Draft, draft-ietf- WebRTC", Work in Progress, Internet-Draft, draft-ietf-
rtcweb-sdp-14, 17 December 2020, rtcweb-sdp-14, 17 December 2020,
<https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-14>. <https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-
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 16)", 3GPP TS 26.114
V16.3.0, September 2019, V16.3.0, September 2019,
<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., Boström, H., Ed., and J. Bruaroey, Ed.,
skipping to change at line 4872 skipping to change at page 106, line 20
Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa
Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer
Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant
Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson,
Sean Turner, and Magnus Westerlund all provided valuable feedback on Sean Turner, and Magnus Westerlund all provided valuable feedback on
this document. this document.
Authors' Addresses Authors' Addresses
Justin Uberti Justin Uberti
Google Clubhouse
747 6th Street South
Kirkland, WA 98033
United States of America
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
Canada Canada
Email: fluffy@iii.ca Email: fluffy@iii.ca
 End of changes. 27 change blocks. 
184 lines changed or deleted 190 lines changed or added

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