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

NEW
Assigned to

Status

()

P4
normal
Rank:
35
6 years ago
11 months ago

People

(Reporter: jsmith, Assigned: jesup)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [spec-issue][webrtc-uplift])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 737339 [details]
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?
(Assignee)

Comment 1

6 years ago
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.)
(Assignee)

Comment 2

6 years ago
We could return something non-numeric if the state isn't 'open'... if so we should add that to the spec proposal.
(Assignee)

Updated

6 years ago
Assignee: nobody → rjesup
Priority: -- → P3
Whiteboard: [webrtc][blocking-webrtc-][spec-issue][webrtc-uplift]
(Reporter)

Comment 3

6 years ago
(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?
(Assignee)

Comment 4

6 years ago
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)

Updated

4 years ago
backlog: --- → webRTC+
Rank: 35
Whiteboard: [webrtc][blocking-webrtc-][spec-issue][webrtc-uplift] → [spec-issue][webrtc-uplift]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4

Comment 6

11 months ago
Sorry for digging this up. :)

Expected value is 'null' before assignment.
You need to log in before you can comment on or make changes to this bug.