[rtcweb] JSEP nit: Size of <sess-id> in the o= line

[Harald Alvestrand <[e-mail]>]

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 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/rfc2327>
   2327 <https://tools.ietf.org/html/rfc2327> [1 <https://tools.ietf.org/html/rfc3264#ref-1>], with one exception.  RFC 2327 <https://tools.ietf.org/html/rfc2327> 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?

This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855

-- 
Surveillance is pervasive. Go Dark.