Draft: draft-ietf-rtcweb-jsep

Commentary: Thanks for writing this up . Can you fix the build errors ? 
 OK , I think I fixed everything 
 that makes sense . That probably needs to be new text in Section 5.11 , I think that could be separate from this PR ( which does n't talk about which ICE version is used at all ) . 
 I do n't care if it is one PR to two and the rest of this PR looks good to me . 
 I a note about RFC 5245 ( based on  's email ) and I text like what Cullen was asking for around accepting offers and answers without " ice2 " . I excluded the part of  's not about previous versions of trickle ICE because it did n't seem relevant to this PR and it had a missing ref and I did n't know what the ref should be ( so I remove it ) . TL;DR : I think this is closer to what we want eventually . I 'd suggest we land something and then tweak if further in a followup PR . But I 'm willing to delete or modify the note if that would get the PR landed . 
 Agree , the references in Sections 5.2.2 and 5.3.2 should be updated accordingly . 
 If this changes the dependency graph to stuff we do n't need , I might suggest the definition of the attributes gets moved . 
 can you take a shot at this ? 
 Not positive this was closed , needs review 
 I 'm looking into this one 
 Have a look at - I think it fixes this - I could not find other instances that looked wrong 
 I think fixed this . 
 I think this looks good with new stuff  . I 'm happy with it .
Paragraph (version B):
The IceCandidate object contains a field to indicate which ICE ufrag
it is associated with, as defined in I-D.ietf-mmusic-ice-sip-sdp,
Section 4.4.  This value is used to determine which session
description (and thereby which gathering phase) this IceCandidate
belongs to, which helps resolve ambiguities during ICE restarts.  If
this field is absent in a received IceCandidate (perhaps when
communicating with a non-JSEP endpoint), the most recently received
session description is assumed.
Paragraph (version B):
While this specification formally relies on RFC8445, at the time of
its publication, the majority of WebRTC implementations support the
version of ICE described in RFC5245.  The use of the "ice2" attribute
defined in RFC8445 can be used to detect the version in use by a
remote endpoint and to provide a smooth transition from the older
specification to the newer one.  Implementations MUST be able to
accept remote descriptions that do not have the "ice2" attribute.
Paragraph (version A):
ICE, as specified in RFC5245, MUST be used.  Note that the remote
endpoint may use a Lite implementation; implementations MUST
properly handle remote endpoints which do ICE-Lite.
Paragraph (version B):
ICE, as specified in RFC8445, MUST be used.  Note that the remote
endpoint may use a Lite implementation; implementations MUST
properly handle remote endpoints which do ICE-Lite.
Paragraph (version A):
For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate
this profile for each media m= line they produce in an offer.  For
data m= sections, implementations MUST support the "UDP/DTLS/SCTP"
profile and MUST indicate this profile for each data m= line they
produce in an offer.  Although these profiles are formally associated
with UDP, ICE can select either UDP RFC5245 or TCP RFC6544 transport
depending on network conditions, even when advertising a UDP profile.
Paragraph (version B):
For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate
this profile for each media m= line they produce in an offer.  For
data m= sections, implementations MUST support the "UDP/DTLS/SCTP"
profile and MUST indicate this profile for each data m= line they
produce in an offer.  Although these profiles are formally associated
with UDP, ICE can select either UDP RFC8445 or TCP RFC6544 transport
depending on network conditions, even when advertising a UDP profile.
Paragraph (version B):
An "a=ice-options" line with the "trickle" and "ice2" options MUST
be added, as specified in I-D.ietf-ice-trickle, Section 3 and
RFC8445, Section 10.
Paragraph (version B):
Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as
described in I-D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2.  If ICE
checking has already completed for one or more candidate pairs and
a candidate pair is in active use, then that pair MUST be used,
even if ICE has not yet completed.  Note that this differs from
the guidance in I-D.ietf-mmusic-ice-sip-sdp, Section 3.3.4, which
only refers to offers created when ICE has completed.  In each
case, if no RTP candidates have yet been gathered, dummy values
MUST be used, as described above.
Paragraph (version A):
If the "IceRestart" option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this
option is specified on an initial offer, it has no effect (since a
new ICE ufrag and pwd are already generated).  Similarly, if the ICE
configuration has changed, this option has no effect, since new ufrag
and pwd attributes will be generated automatically.  This option is
primarily useful for reestablishing connectivity in cases where
failures are detected by the application.
Paragraph (version B):
If the "IceRestart" option is specified, with a value of "true", the
offer MUST indicate an ICE restart by generating new ICE ufrag and
pwd attributes, as specified in I-D.ietf-mmusic-ice-sip-sdp,
Section 3.4.1.1.1.  If this option is specified on an initial offer,
it has no effect (since a new ICE ufrag and pwd are already
generated).  Similarly, if the ICE configuration has changed, this
option has no effect, since new ufrag and pwd attributes will be
generated automatically.  This option is primarily useful for
reestablishing connectivity in cases where failures are detected by
the application.
Paragraph (version A):
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.
Paragraph (version B):
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 3, and the "ice2" option as specified in
RFC8445, Section 10, is only included if such an option was present
in the offer.
Paragraph (version B):
Each "m=" and c=" line MUST be filled in with the port and address
of the default candidate for the m= section, as described in I-
D.ietf-mmusic-ice-sip-sdp, Section 3.2.1.2.  Note, however, that
the m= line protocol need not match the default candidate, because
this protocol value must instead match what was supplied in the
offer, as described above.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the m= section is restarting, in which case new ICE credentials
must be created as specified in I-D.ietf-mmusic-ice-sip-sdp,
Section 3.4.1.1.1.  If the m= section is bundled into another m=
section, it still MUST NOT contain any ICE credentials.
Paragraph (version A):
The "c=" line MUST be checked for syntax but its value is only
used for ICE mismatch detection, as defined in RFC5245,
Section 6.1.  Note that JSEP implementations should never
encounter this condition because ICE is required for WebRTC.
Paragraph (version B):
The "c=" line MUST be checked for syntax but its value is only
used for ICE mismatch detection, as defined in RFC8445,
Section 5.4.  Note that JSEP implementations should never
encounter this condition because ICE is required for WebRTC.
Paragraph (version B):
If present, a single "a=ice-lite" line is parsed as specified in
I-D.ietf-mmusic-ice-sip-sdp, Section 4.3, and a value indicating
the presence of ice-lite is stored.
Paragraph (version B):
Any "a=candidate" attributes MUST be parsed as specified in I-
D.ietf-mmusic-ice-sip-sdp, Section 4.1, and their values stored.
Paragraph (version B):
Any "a=remote-candidates" attributes MUST be parsed as specified
in I-D.ietf-mmusic-ice-sip-sdp, Section 4.2, but their values are
ignored.
Paragraph (version B):
ICE ufrag and password values, which MUST comply with the size
limits specified in I-D.ietf-mmusic-ice-sip-sdp, Section 4.4.
Paragraph (version A):
Or, if the ICE ufrag and password values have changed, trigger the
ICE agent to start an ICE restart, and begin gathering new
candidates for the m= section as described in RFC5245,
Section 9.1.1.1.  If this description is an answer, also start
checks on that media section as defined in RFC5245,
Section 9.3.1.1.
Paragraph (version B):
Or, if the ICE ufrag and password values have changed, trigger the
ICE agent to start an ICE restart as described in RFC8445,
Section 9, and begin gathering new candidates for the m= section.
If this description is an answer, also start checks on that media
section.
Paragraph (version A):
If the ICE ufrag or password changed from the previous remote
description: RFC5245.
Paragraph (version A):
If the description is of type "offer", the implementation MUST
note that an ICE restart is needed, as described in RFC5245,
Section 9.1.1.1.
Paragraph (version A):
If the description is of type "answer" or "pranswer", then
check to see if the current local description is an ICE
restart, and if not, generate an error.  If the PeerConnection
state is "have-remote-pranswer", and the ICE ufrag or password
changed from the previous provisional answer, then signal the
ICE agent to discard any previous ICE check list state for the
m= section.  Finally, signal the ICE agent to begin checks as
described in RFC5245, Section 9.3.1.1.
Paragraph (version A):
If the current local description indicates an ICE restart, and
either the ICE ufrag or password has not changed from the previous
remote description, as prescribed by RFC5245, Section 9.2.1.1,
generate an error.
Paragraph (version A):
Pair any supplied ICE candidates with any gathered local
candidates, as described in RFC5245, Section 5.7, and start
connectivity checks with the appropriate credentials.
Paragraph (version B):
If the description is of type "answer" or "pranswer", then
check to see if the current local description is an ICE
restart, and if not, generate an error.  If the PeerConnection
state is "have-remote-pranswer", and the ICE ufrag or password
changed from the previous provisional answer, then signal the
ICE agent to discard any previous ICE check list state for the
m= section.  Finally, signal the ICE agent to begin checks.
Paragraph (version B):
If the current local description indicates an ICE restart, and
either the ICE ufrag or password has not changed from the previous
remote description, as prescribed by RFC8445, Section 9, generate
an error.
Paragraph (version B):
Pair any supplied ICE candidates with any gathered local
candidates, as described in RFC8445, Section 6.1.2, and start
connectivity checks with the appropriate credentials.
Paragraph (version A):
If the m= section has been rejected (i.e. port is set to zero in
the answer), stop any reception or transmission of media for this
section, and, unless a non-rejected m= section is bundled with
this m= section, discard any associated ICE components, as
described in RFC5245, Section 9.2.1.3.
Paragraph (version B):
If the m= section has been rejected (i.e. port is set to zero in
the answer), stop any reception or transmission of media for this
section, and, unless a non-rejected m= section is bundled with
this m= section, discard any associated ICE components, as
described in I-D.ietf-mmusic-ice-sip-sdp, Section 3.4.3.1.