Draft: draft-ietf-rtcweb-jsep

Commentary: Do you need to say anything about privacy implications of this or how the local addresses are filtered ? 
 I considered providing a reference but noticed that we do n't currently do this for other methods , e.g. , setRemoteDescription , mentioned in the introduction . Open to ideas here but would want to be consistent . I could add some text similar to ' ... subject to the restrictions noted in & lt ; xref target="ice - candidate - policy " & gt ; ' 
 I consider the request for the xref an enhancement request , not a bug . I 'm okay with leaving it as - is . 
 Added text about the ICE candidate filtering and some minor editorial tweaks .  if this LGTY , for final approval . 
 I took another pass over this to address feedback , and also resolve an inconsistency in the document where we had previously said that all IceCandidate fields MUST be filled in . 
 PTAL 
 all comments addressed . Will plan to merge once  passes unless I hear otherwise . 
 11 ) [ rfced ] Sections 4 and 7 : For ease of the reader , please let us know if we may cite [ ] as a reminder regarding " addTrack , " " removeTrack , " etc . ( Section 4 ) as well as " onicecandidate , " " addIceCandidate , " and " ontrack " ( Section 7 ) , as follows . Original : The actual API exposed in the W3C API may have somewhat different syntax , but should map easily to these concepts . ... More examples of SDP for WebRTC call flows , including examples with IPv6 addresses , can be found in [ I - D.ietf - rtcweb - sdp ] . Suggested : The actual API exposed in the W3C API [ ] may have somewhat different syntax but should map easily to these concepts . ... More examples of SDP for WebRTC call flows , including examples with IPv6 addresses , can be found in [ SDP4WebRTC ] . See [ ] for information regarding " onicecandidate , " " addIceCandidate , " and " ontrack " . 
 hmm , we never refer to ontrack or onicecandidate in this document , I wonder if we should mention them in Section 4 . 
 The ideal solution here would be to have a subsection of section 4 to refer to ontrack ( adjacent to the existing addTrack section ) and one to refer to onicecandidate ( adjacent to the existing addIceCandidate section ) . The onicecandidate section should be fairly trivial and could simply refer to the ICE gathering process already defined in JSEP , but ontrack would need to be referenced by setRemoteDescription , so this would not be entirely editorial . from a process perspective , what would you suggest here ? 
 for his thoughts 
 It does make sense to add something . We are not making a normative change to how anything works , just clarifying the mapping to the W3C spec . I suspect that the AD could approve that . 
 I 'm not too fussed either way . I think folks who read both this and the W3C spec will get their implementation right , so it 's not required for interop ; while at the same time , it 's probably a slight improvement to add specific text . I would defer to the current ADs on the correct choice between the two ( I think implicitly picked the C238 work up with the rest of my former realtime groups ) . I do agree with Cullen that the path that adds new text for definitely requires AD approval , while leaving it as - is does not . 
 I 'd prefer that the document be internally consistent , so I 'd advocate adding the new paragraph if is OK with it . I 'll make a PR and send to the list for a decision . 
 PTAL at 
 made one comment over on PR 
 PR is approved as it is right now . 
 I only found one typo , which I 've highlighted . LGTMGenerally LGTM
Paragraph (version A):
When a new gathering phase starts, the ICE agent will notify the
application that gathering is occurring through an event.  Then, when
each new ICE candidate becomes available, the ICE agent will supply
it to the application via an additional event; these candidates will
also automatically be added to the current and/or pending local
session description.  Finally, when all candidates have been
gathered, an event will be dispatched to signal that the gathering
process is complete.
Paragraph (version B):
When a new gathering phase starts, the ICE agent will notify the
application that gathering is occurring through a state change event.
Then, when each new ICE candidate becomes available, the ICE agent
will supply it to the application via an onicecandidate event; these
candidates will also automatically be added to the current and/or
pending local session description.  Finally, when all candidates have
been gathered, a final onicecandidate event will be dispatched to
signal that the gathering process is complete.
Paragraph (version A):
When creating an IceCandidate object, JSEP implementations MUST
populate each of the candidate, ufrag, "m=" section index, and MID
fields.  Implementations MUST also be prepared to receive objects
with some fields missing, as mentioned above.
Paragraph (version B):
The onaddtrack event is dispatched to the application when a new
remote track has been signaled as a result of a setRemoteDescription
call.  The new track is supplied as a MediaStreamTrack object in the
event, along with the MediaStream(s) the track is part of.
Paragraph (version B):
The ondatachannel event is dispatched to the application when a new
data channel has been negotiated by the remote side, which can occur
at any time after the underlying SCTP/DTLS association has been
established.  The new data channel object is supplied in the event.
Paragraph (version A):
The addIceCandidate method provides an update to the ICE agent via an
IceCandidate object (sec.ice-candidate-format).  If the
IceCandidate's candidate field is filled in, the IceCandidate is
treated as a new remote ICE candidate, which will be added to the
current and/or pending remote description according to the rules
defined for Trickle ICE.  Otherwise, the IceCandidate is treated as
an end-of-candidates indication, as defined in RFC8838.
Paragraph (version B):
The addIceCandidate method provides an update to the ICE agent via an
IceCandidate object (sec.ice-candidate-format).  If the
IceCandidate's candidate field is non-null, the IceCandidate is
treated as a new remote ICE candidate, which will be added to the
current and/or pending remote description according to the rules
defined for Trickle ICE.  Otherwise, the IceCandidate is treated as
an end-of-candidates indication, as defined in RFC8838.
Paragraph (version A):
In either case, the "m=" section index, MID, and ufrag fields from
the supplied IceCandidate are used to determine which "m=" section
and ICE candidate generation the IceCandidate belongs to, as
described in sec.ice-candidate-format above.  In the case of an end-
of-candidates indication, the absence of both the "m=" section index
and MID fields is interpreted to mean that the indication applies to
all "m=" sections in the specified ICE candidate generation.
However, if both fields are absent for a new remote candidate, this
MUST be treated as an invalid condition, as specified below.
Paragraph (version B):
In either case, the "m=" section index, MID, and ufrag fields from
the supplied IceCandidate are used to determine which "m=" section
and ICE candidate generation the IceCandidate belongs to, as
described in sec.ice-candidate-format above.  In the case of an end-
of-candidates indication, null values for the "m=" section index and
MID fields are interpreted to mean that the indication applies to all
"m=" sections in the specified ICE candidate generation.  However, if
both fields are null for a new remote candidate, this MUST be treated
as an invalid condition, as specified below.
Paragraph (version B):
The onicecandidate event is dispatched to the application in two
situations: (1) when the ICE agent has discovered a new allowed local
ICE candidate during ICE gathering, as outlined in sec.ice-gather-
overview and subject to the restrictions discussed in sec.ice-
candidate-policy, or (2) when an ICE gathering phase completes.  The
event contains a single IceCandidate object, as defined in sec.ice-
candidate-format.
Paragraph (version B):
In the first case, the newly discovered candidate is reflected in the
IceCandidate object, and all of its fields MUST be non-null.  This
candidate will also be added to the current and/or pending local
description according to the rules defined for Trickle ICE.
Paragraph (version B):
In the second case, the event's IceCandidate object MUST have its
candidate field set to null to indicate that the current gathering
phase is complete, i.e., there will be no further onicecandidate
events in this phase.  However, the IceCandidate's ufrag field MUST
be specified to indicate which ICE candidate generation is ending.
The IceCandidate's "m=" section index and MID fields MAY be specified
to indicate that the event applies to a specific "m=" section, or set
to null to indicate it applies to all "m=" sections in the current
ICE candidate generation.  This event can be used by the application
to generate an end-of-candidates indication, as defined in RFC8838.