-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSEP restriction on session ID is 2^62, should be 2^63 or 2^64 #855
Comments
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? |
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. |
@nils-ohlmeier is correct. I need coffee. |
Fixes #855 Also add ip-handling reference
PTAL at #858 |
Looks like @juberti was faster then me in creating a PR. Thank you. |
yeah, next time I will read the etherpad notes first :) |
JSEP -24 currently says:
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?
The text was updated successfully, but these errors were encountered: