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:
Also add ip-handling reference
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Also think this is uncontroversial, planning to land this next week if there are no objections.
JSEP -24 currently says: The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (262)-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. There are two problems here: RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field.Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1 Quote from RFC 3264: The offer (and answer) MUST be a valid SDP message, as defined by RFC 2327 [1], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP message. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (262)-1, to avoid rollovers. Although the SDP specification allows for multiple session descriptions to be concatenated together into a large SDP message, an SDP message used in the offer/answer model MUST contain exactly one session description. So what's easiest to change, deployed code or JSEP?
Firefox also creates session IDs > 2^62. The restriction in JSEP looks to me like someone accidentally put the requirements from 3264 version field onto the session ID. I think this should be fixed in JSEP.
Would changing to 2^63 (and removing the citation for 3264) be sufficient? cc NAME
I think so yes. Firefox already does generate 2^63 session IDs.
I think saying 2^63 is probably wrong.

Lets say that we changed it to 2^63 an something randomly choose a number very close to 2^63 then when that number got incremented a few times, it could be larger than 2^63. And do the ABNF silliness we don't have a way to represent this. We could do something like 2^63 - 1,000,000 or something if people had some sort of real concern about this extra bit.
We are talking about the session ID, which is not suppose to be incremented if I'm not mistaken. So the roll over concerns should only apply to the version.
NAME is correct. I need coffee.
PTAL at
Looks like NAME was faster then me in creating a PR. Thank you.
yeah, next time I will read the etherpad notes first :)
LGTMLGTM