JavaScript Session Establishment Protocol
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.