Draft: draft-ietf-rtcweb-jsep

Commentary: The main difference between this patch and is that this one says TCP should be set as the protocol any time the selected pair is TCP , whereas only sets TCP when there are only TCP candidates ( a condition that currently can not happen , IIRC ) . 
 cc 
 What happens in the following situation ? client is placed behind the firewall which only allows TCP connections TURN servers are configured establishes connection to a server which supports ICE TCP nomination completes browser app calls createOffer with no options ( ICE restart option is not present ) In this case ICE nomination is complete and the TCP candidate is nominated . No other candidates should be present in the offer . 
 I believe the other candidates can still be present in the updated offer , as noted in the JSEP examples section . 
 What example specifically are you talking about ? Also , please take a look at RFC 5245 section 9.1.2.2 ( ): The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream , and MUST NOT include any other candidates . And in mmusic - ice - sip - sdp Section 3.4.1.2.2 ( ): In addition , the offerer only includes SDP candidates representing the local candidates of the nominated candidate pair . The offerer MUST NOT include any other SDP candidate attributes in the subsequent offer . Does  overwrites this somewhere ? 
 example : JSEP seems to say that a = candidate lines MUST always be : 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 , as defined in [ I - D.ietf - mmusic - ice - sip - sdp ] , Section 4.1 . If candidate gathering for the section has completed , an " a = end - of- candidates " attribute MUST be , 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 . 
 I guess it was not immediately obvious to me if this section referrers to offers sent while ICE nomination process or when it is completed . RFC5245 and ice - sip - sdp both make a distinction between the two . The ICE nomination status in the example is also not clear . In any case , if overwriting a MUST from a referenced RFC was intentional , it should be explicit . I think I am not the only person who is confused by this right now . Also , what is the reason to keep old candidates once ICE nomination is completed ? When does the browser release the unused candidates ? 
 It was n't intentional ; it sort of assumed that renomination could occur at any time ( which was my view on ICE at the time this was written ) , which meant you would want the additional candidates 
 Since this was not intentional , non - obvious , and somewhat contradicts RFC5245 / RFC8445 / ice - sip - sdp specifications , what do you want to do here ? One way to solve this is to make this compliant with RFC8445 / ice - sip - sdp , and to specify that once ICE nomination completes , only nominated candidates are kept and implementation can release other candidates . Subsequent offer after the end of ICE nomination includes only nominated candidates . If TCP candidate is a default in this case , proto should be TCP based . Another way to deal with this is to specify how JSEP nomination process is different from normal ICE . For instance ICE nomination from the browser is never considered complete , so that candidates are never released and all candidates are always included in the offer . In this case , m= and c= line can be assigned to one of the UDP candidates even if TCP candidate is the default . This way proto is always UDP based and browser based client will never generate TCP based proto . Current specification is kind of between these two points which makes it ambiguous . 
 My guess is that the consensus view for JSEP would be that it match 8445 , and not include extra candidates . Chrome supports renomination , and would include the extra candidates accordingly , but that 's not something that JSEP needs to adhere to ( especially because there is no active standards - track renomination spec ) . 
 Just for my own interest , does  send keep - alives and consensus checks for all candidates that it includes in subsequent offers ? If not , how does  check that a pair still works if it wants to renominate ? 
 Updated this PR to incorporate the feedback regarding what candidate should be put into the m=/c= during ICE negotiation ( now  says to simply follow sip - sdp ) .
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 RFC8445 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 as well as the
"TCP/DTLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate
one of these profiles for each media m= line they produce in an
offer.  For data m= sections, implementations MUST support the
"UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and
MUST indicate one of these profiles for each data m= line they
produce in an offer.  The exact profile to use is determined by the
protocol associated with the current default or selected ICE
candidate, as described in I-D.ietf-mmusic-ice-sip-sdp,
Section 3.2.1.2.
Paragraph (version B):
The second SDP line MUST be an "o=" line, as specified in RFC4566,
Section 5.2.  The value of the <username> field SHOULD be "-".
The sess-id MUST be representable by a 64-bit signed integer, and
the value MUST be less than (2**63)-1.  It is RECOMMENDED that the
sess-id be constructed by generating a 64-bit quantity with the
highest bit set to zero and the remaining 63 bits being
cryptographically random.  The value of the <nettype> <addrtype>
<unicast-address> tuple SHOULD be set to a non-meaningful address,
such as IN IP4 0.0.0.0, to prevent leaking a local IP address in
this field; this problem is discussed in I-D.ietf-rtcweb-ip-
handling.  As mentioned in RFC4566, the entire o= line needs to be
unique, but selecting a random number for <sess-id> is sufficient
to accomplish this.
Paragraph (version A):
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 B):
Each "m=" and c=" line MUST be filled in with the port, relevant
RTP profile, 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, and clarified in sec.profile-names.  If no RTP
candidates have yet been gathered, dummy values MUST still be
used, as described above.
Paragraph (version A):
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 "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 that in certain
cases, the m= line protocol may not match that of the default
candidate, because the m= line protocol value MUST match what was
supplied in the offer, as described above.
Paragraph (version B):
If present, "a=msid" attributes MUST be parsed as specified in I-
D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring
any "appdata" field.  If no "a=msid" attributes are present, a
random msid-id value is generated for a "default" MediaStream for
the session, if not already present, and this value is stored.