Change:
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

Discussion:
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).