861722 - Before a peer connection handshake occurs with data channels, the stream value for both data channels is 65535 (odd number?)

Status: RESOLVED INVALID

(Core :: WebRTC, defect, P4)

Description

[Jason Smith [:jsmith]]

Attachment: Test Case

STR:

1. Load the attached test case
2. Go into the web console and type localDC.stream

Expected:

Don't know the exact behavior expected here.

Actual:

I wouldn't expect to get the maximum possible value for an unsigned short - 65535. That number feels...strange to use? After establishing the handshake, I see 0 and 1 being used. Can we come up with a better numbering scheme here that makes sense?

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

The proposal for the API here says that channel.stream is not valid until onopen fires.  (Internally, 65535 is used as an invalid value to flag that the stream isn't assigned yet.)

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

We could return something non-numeric if the state isn't 'open'... if so we should add that to the spec proposal.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #2)
> We could return something non-numeric if the state isn't 'open'... if so we
> should add that to the spec proposal.

Hmm..okay. 65535 felt odd to use to indicate "invalid" from my sense. Why not use -1?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Because internally it's a unsigned short, as we're just exposing it via .stream (and it's an unsigned short in the IDL, so we can't return -1 or undefined even if we want to)

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.

Comment 6

[Lennart Grahl [:lgrahl]]

Sorry for digging this up. :)

Expected value is 'null' before assignment.