If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Assigned to

Status

()

Core
WebRTC
P4
normal
Rank:
35
5 years ago
11 days 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

5 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

5 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

5 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

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

Comment 3

5 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

5 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

2 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
You need to log in before you can comment on or make changes to this bug.