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.