Draft: draft-ietf-rtcweb-jsep

Commentary: I fixed this . 
 Section 5.2.1 CreateOffer " given that no candidates have yet been gathered " - when people remember the pre - gathered candidate pool , this can be confusing . Suggest adding a note at the top of this section saying that CreateOffer does n't cause candidate gathering and does not take candidates from the pre - gathered pool , and thus , no candidates are available at the initial call to  . All subsequent references to " no candidates have yet been gathered " in this section should be replaced with " no candidates are available " . This also affects section 5.3.1 CreateAnswer . 
 lgtm
Paragraph (version A):
When using JSEP to transmit multiple encodings from a RTPSender, the
techniques from I-D.ietf-mmusic-sdp-simulcast and I-D.ietf-mmusic-rid
are used.  Specifically, when multiple encodings have been configured
for a RTPSender, the m= section for the RTPSender will include an
"a=simulcast" attribute, as defined in I-D.ietf-mmusic-sdp-simulcast,
Section 6.2, with a "send" simulcast stream description that lists
each desired encoding, and no "recv" simulcast stream description.
The m= section will also include an "a=rid" attribute for each
encoding, as specfied in I-D.ietf-mmusic-rid, Section 4; the use of
RID identifiers allows the individual encodings to be disambiguated
even though they are all part of the same m= section.
Paragraph (version B):
When using JSEP to transmit multiple encodings from a RTPSender, the
techniques from I-D.ietf-mmusic-sdp-simulcast and I-D.ietf-mmusic-rid
are used.  Specifically, when multiple encodings have been configured
for a RTPSender, the m= section for the RTPSender will include an
"a=simulcast" attribute, as defined in I-D.ietf-mmusic-sdp-simulcast,
Section 6.2, with a "send" simulcast stream description that lists
each desired encoding, and no "recv" simulcast stream description.
The m= section will also include an "a=rid" attribute for each
encoding, as specified in I-D.ietf-mmusic-rid, Section 4; the use of
RID identifiers allows the individual encodings to be disambiguated
even though they are all part of the same m= section.
Paragraph (version A):
The setCodecPreferences method sets the codec preferences of a
transceiver, which in turn affect the presence and order of codecs of
the associated m= section on future calls to createOffer and
createAnswer.  Note that setCodecPreferences does not directly affect
which codec the implemtation decides to send.  It only affects which
codecs the implementation indicates that it prefers to receive, via
the offer or answer.  Even when a codec is excluded by
setCodecPreferences, it still may be used to send until the next
offer/answer exchange discards it.
Paragraph (version B):
The setCodecPreferences method sets the codec preferences of a
transceiver, which in turn affect the presence and order of codecs of
the associated m= section on future calls to createOffer and
createAnswer.  Note that setCodecPreferences does not directly affect
which codec the implementation decides to send.  It only affects
which codecs the implementation indicates that it prefers to receive,
via the offer or answer.  Even when a codec is excluded by
setCodecPreferences, it still may be used to send until the next
offer/answer exchange discards it.
Paragraph (version A):
The port value is set to the port of the default ICE candidate for
this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in I-D.ietf-ice-trickle, Section 5.1.
Paragraph (version B):
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.
Paragraph (version A):
The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates
have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in I-D.ietf-ice-trickle, Section 5.1.
Paragraph (version B):
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.
Paragraph (version A):
The SDP returned from createOffer or createAnswer MUST NOT be changed
before passing it to setLocalDescription.  If precise control over
the SDP is needed, the aformentioned createOffer/createAnswer options
or RTPSender APIs MUST be used.
Paragraph (version B):
The SDP returned from createOffer or createAnswer MUST NOT be changed
before passing it to setLocalDescription.  If precise control over
the SDP is needed, the aforementioned createOffer/createAnswer
options or RTPSender APIs MUST be used.