Draft: draft-ietf-rtcweb-jsep

Commentary: S 5.2.1 says : Attributes that are common between all m= sections MAY be moved to session - level , if explicitly defined to be valid at session - level . This seems like it would be better as a should 
 Discussed in DC : Some concerns that things that appear at the session level have , in the past , missed by bad implementations . 
 Dc - decdie to change to SHOULD NOT and for things that are big , like idientiy , will put MUST
Paragraph (version A):
JSEP gathers ICE candidates as needed by the application.  Collection
of ICE candidates is referred to as a gathering phase, and this is
triggered either by the addition of a new or recycled m= line to the
local session description, or new ICE credentials in the description,
indicating an ICE restart.  Use of new ICE credentials can be
triggered explicitly by the application, or implicitly by the browser
in response to changes in the ICE configuration.
Paragraph (version B):
JSEP gathers ICE candidates as needed by the application.  Collection
of ICE candidates is referred to as a gathering phase, and this is
triggered either by the addition of a new or recycled m= section to
the local session description, or new ICE credentials in the
description, indicating an ICE restart.  Use of new ICE credentials
can be triggered explicitly by the application, or implicitly by the
browser in response to changes in the ICE configuration.
Paragraph (version A):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use
their existing candidates.  Also, when bundling is active, candidates
are only gathered (and exchanged) for the m= lines referenced in
BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation.
Paragraph (version B):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= sections; other m= sections continue to
use their existing candidates.  Also, when bundling is active,
candidates are only gathered (and exchanged) for the m= sections
referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-
bundle-negotiation.
Paragraph (version A):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m= line can be identified in
one of two ways; either by a m= line index, or a MID.  The m= line
index is a zero-based index, with index N referring to the N+1th m=
line in the SDP sent by the entity which sent the IceCandidate.  The
MID uses the "media stream identification" attribute, as defined in
RFC5888, Section 4, to identify the m= line.  JSEP implementations
creating an ICE Candidate object MUST populate both of these fields,
using the MID of the associated RtpTransceiver object (which may be
locally generated by the answerer when interacting with a non-JSEP
remote endpoint that does not support the MID attribute, as discussed
in sec.applying-a-remote-desc below).  Implementations receiving an
ICE Candidate object MUST use the MID if present, or the m= line
index, if not (the non-JSEP remote endpoint case).
Paragraph (version B):
The IceCandidate object also contains fields to indicate which m=
section it should be associated with.  The m= section can be
identified in one of two ways; either by a m= section index, or a
MID.  The m= section index is a zero-based index, with index N
referring to the N+1th m= section in the SDP sent by the entity which
sent the IceCandidate.  The MID uses the "media stream
identification" attribute, as defined in RFC5888, Section 4, to
identify the m= section.  JSEP implementations creating an ICE
Candidate object MUST populate both of these fields, using the MID of
the associated RtpTransceiver object (which may be locally generated
by the answerer when interacting with a non-JSEP remote endpoint that
does not support the MID attribute, as discussed in sec.applying-a-
remote-desc below).  Implementations receiving an ICE Candidate
object MUST use the MID if present, or the m= section index, if not
(the non-JSEP remote endpoint case).
Paragraph (version A):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  The pair of MID and ufrag is used to determine the m=
section and ICE candidate generation to which the candidate belongs.
If the MID is not present, the m= line index is used to look up the
locally generated MID (see sec.applying-a-remote-desc), which is used
in place of a supplied MID.  If these values or the candidate string
are invalid, an error is generated.
Paragraph (version B):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  The pair of MID and ufrag is used to determine the m=
section and ICE candidate generation to which the candidate belongs.
If the MID is not present, the m= section index is used to look up
the locally generated MID (see sec.applying-a-remote-desc), which is
used in place of a supplied MID.  If these values or the candidate
string are invalid, an error is generated.
Paragraph (version A):
The createAnswer method takes as a parameter an RTCAnswerOptions
object.  The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the IceRestart option is
unnecessary, as ICE credentials will automatically be changed for all
m= lines where the offerer chose to perform ICE restart.
Paragraph (version B):
The createAnswer method takes as a parameter an RTCAnswerOptions
object.  The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the IceRestart option is
unnecessary, as ICE credentials will automatically be changed for all
m= sections where the offerer chose to perform ICE restart.