JavaScript Session Establishment Protocol (JSEP)
draft-ietf-rtcweb-jsep-26
Approval announcement
Draft of message to be sent after approval:
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: draft-ietf-rtcweb-jsep@ietf.org, The IESG <iesg@ietf.org>, ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie <ted.ietf@gmail.com>, rtcweb@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'JavaScript Session Establishment Protocol' to Proposed Standard (draft-ietf-rtcweb-jsep-24.txt)
The IESG has approved the following document:
- 'JavaScript Session Establishment Protocol'
(draft-ietf-rtcweb-jsep-24.txt) as Proposed Standard
This document is the product of the Real-Time Communication in WEB-browsers
Working Group.
The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
Technical Summary
This document describes the mechanisms for allowing a JavaScript
application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API and
relates this signaling to the media streams and data channels which
are created and managed by the application. It is effectively the
core signaling protocol for WebRTC endpoints.
Working Group Summary
The working group process leading up to this document was quite long and
required unusual levels of coordination with the W3C group producing the
API and the IETF working groups responsible for the underlying mechanisms
(especially those responsible for SDP, ICE, and RTP). During the process,
there were some decisions which moved between groups in ways that made
consensus difficult to judge because the groups were not completely
congruent. The shepherd's evaluation is that the contents of this document
do have consensus of the interested parties, and the responsible area
director concurs.
Document Quality
The protocol has various levels of implementation in release versions of at
least five major web browsers (Chrome, Safari, Firefox, Edge, and Opera) and
in hundreds of applications. Those who contributed significant text and
reviews are mentioned in the acknowledgements section. The GEN-ART
review was specifically (and by request) conducted by a communications
and SDP expert.
Personnel
Ted Hardie is the document shepherd.
Adam Roach is the responsible area director.
RFC Editor Note
Several changes to references are necessary to accommodate SDP-related
mechanisms moving from draft-ietf-ice-trickle to
draft-ietf-mmusic-trickle-ice-sip. These changes are detailed below. Note that
the final change is only a change in section rather than a change in document
and section.
§5.2.1
OLD:
o An "a=ice-options" line with the "trickle" option MUST be added,
as specified in [I-D.ietf-ice-trickle], Section 4.
NEW:
o An "a=ice-options" line with the "trickle" option MUST be added,
as specified in [I-D.ietf-mmusic-trickle-ice-sip], Section 4.1.1.
OLD:
o If the m= section is marked as bundle-only, then the port value
MUST be set to 0. Otherwise, the port value is set to the port of
the default ICE candidate for this m= section, but given that no
candidates are available yet, the "dummy" port value of 9
(Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle],
Section 5.1.
NEW:
o If the m= section is marked as bundle-only, then the port value
MUST be set to 0. Otherwise, the port value is set to the port of
the default ICE candidate for this m= section, but given that no
candidates are available yet, the "dummy" port value of 9
(Discard) MUST be used, as indicated in
[I-D.ietf-mmusic-trickle-ice-sip], Section 4.1.1.
OLD:
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-ice-trickle], Section 5.1.
NEW:
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-mmusic-trickle-ice-sip], Section 4.1.1.
§5.2.2
OLD:
o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted.
NEW:
o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in
[I-D.ietf-mmusic-trickle-ice-sip], Section 8.2. If the m= section is
bundled into another m= section, both "a=candidate" and
"a=end-of-candidates" MUST be omitted.
§5.3.1
OLD:
The first step in generating an initial answer is to generate
session-level attributes. The process here is identical to that
indicated in the initial offers section above, except that the
"a=ice-options" line, with the "trickle" option as specified in
[I-D.ietf-ice-trickle], Section 4, is only included if such an option
was present in the offer.
NEW:
The first step in generating an initial answer is to generate
session-level attributes. The process here is identical to that
indicated in the initial offers section above, except that the
"a=ice-options" line, with the "trickle" option as specified in
[I-D.ietf-mmusic-trickle-ice-sip], Section 4.1.3, is only included
if such an option was present in the offer.
OLD:
o The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates
are available yet, the "dummy" port value of 9 (Discard) MUST be
used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
NEW:
o The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates
are available yet, the "dummy" port value of 9 (Discard) MUST be
used, as indicated in [I-D.ietf-mmusic-trickle-ice-sip],
Section 4.1.1.
OLD:
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-ice-trickle], Section 5.1.
NEW:
The m= line MUST be followed immediately by a "c=" line, as specified
in [RFC4566], Section 5.7. Again, as no candidates are available
yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
as defined in [I-D.ietf-mmusic-trickle-ice-sip], Section 4.1.3.
§5.3.2
OLD:
o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted.
NEW:
o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in
[I-D.ietf-mmusic-trickle-ice-sip], Section 8.2. If the m= section is
bundled into another m= section, both "a=candidate" and
"a=end-of-candidates" MUST be omitted.
§5.8.2
OLD:
o If present, a single "a=end-of-candidates" attribute MUST be
parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
its presence or absence flagged and stored.
NEW:
o If present, a single "a=end-of-candidates" attribute MUST be
parsed as specified in [I-D.ietf-mmusic-trickle-ice-sip], Section 8.1,
and its presence or absence flagged and stored.
§5.10
OLD:
o If an "a=end-of-candidates" attribute is present, process the end-
of-candidates indication as described in [I-D.ietf-ice-trickle],
Section 11.
NEW:
o If an "a=end-of-candidates" attribute is present, process the end-
of-candidates indication as described in [I-D.ietf-ice-trickle],
Section 14.
§11.1 and 11.2:
Please move [draft-ietf-mmusic-trickle-ice-sip] from the informative references section to the normative references section.