Draft: draft-ietf-rtcweb-jsep

Commentary: Also add ip - handling reference 
 ping 
 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 . 
  -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 does n'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 i d 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  ? 
 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 
 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 do n'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 . 
 is correct . I need coffee . 
 PTAL at 
 Looks like was faster then me in creating a PR . Thank you . 
 yeah , next time I will read the etherpad notes first :) 
 LGTMLGTM
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.