JSEP restriction on session ID is 2^62, should be 2^63 or 2^64

[alvestrand]

JSEP -24 currently says:

  The sess-id MUST be representable by a 64-bit signed
  integer, and 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.

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
(2**62)-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?

[nils-ohlmeier]

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.

[juberti]

Would changing to 2^63 (and removing the citation for 3264) be sufficient?
cc @ekr

[nils-ohlmeier]

Would changing to 2^63 (and removing the citation for 3264) be sufficient?

I think so yes. Firefox already does generate 2^63 session IDs.

[fluffy]

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.

[nils-ohlmeier]

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.

[fluffy]

@nils-ohlmeier is correct. I need coffee.

[juberti]

PTAL at #858

[nils-ohlmeier]

Looks like @juberti was faster then me in creating a PR. Thank you.

[juberti]

yeah, next time I will read the etherpad notes first :)