Change:
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 cannot happen, IIRC).
cc NAME
NAME What happens in the following situation? Browser client is placed behind the firewall which only allows TCP connections No TURN servers are configured Client establishes connection to a server which supports ICE TCP ICE nomination completes Client 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.
NAME What example specifically are you talking about? Also, please take a look at RFC 5245 section 9.1.2.2 (URL): 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 (URL): 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 JSEP overwrites this somewhere?
example: URL JSEP seems to say that a=candidate lines MUST always be added: 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 added, 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 added, 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 wasn'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 Chrome send keep-alives and consensus checks for all candidates that it includes in subsequent offers? If not, how does Chrome 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 JSEP says to simply follow sip-sdp).

Discussion:
5.1.2. For media m= sections, JSEP implementations MUST support the <del> "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. </del> <ins> "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. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del> <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer:

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 <del> the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 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 the local address in this field.  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. </del> <ins> 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. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used

line(s) MUST be generated according to the same rules as for an initial offer. <del> 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. </del> <ins> 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. </ins> Each "a=mid" line MUST stay the same.

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- <del> 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. </del> <ins> 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. </ins> 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

If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> 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. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.