I forgot to set the title of the issue. It should be "WebRTC: Negotiated DataChannels don't seem to work". Could someone with the necessary permissions change it for me?

I found the problem. Apparently the id 1023 is reserved, so it cannot be used. When changing the id to something else (e.g. 0) it works.

The fact that no error was raised is a bug though, right?

I don't see 1023 getting set in your gist. Please elaborate?

Did you look at the right Gist?

It's being set here: https://gist.github.com/dbrgn/2b6c08094dae0fc49c95173bba80903d#file-dctest-negotiated-html-L42-L50

Thank you for providing more feedback. Adding requester "phoglund@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Oh, that's a different gist than in the original CL. Sure, I see it now.

Just curious, is the problem that 1023 is magically reserved by something or that you choose the same id for both the local and remote channel?

hta, perkj, guidou, should bad ID's for data channels throw errors? I think that sounds reasonable, but not sure what our error policy is.

There are two Gist links in the description, one with negotiated and one with non-negotiated channels :)

Yes, I chose 1023 on both sides (I simply wanted to use the highest number in a 2**10 space as the control channel). It was quite arbitrary. The problem was that I didn't notice the problems because there was no error message.

The spec says:

If id attribute is uninitialized (not set via the dictionary), initialize it to a value generated by the user agent, according to the WebRTC DataChannel Protocol specification, and skip to the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel , throw a ResourceInUse exception and abort these steps.

So it's a bug that an exception isn't thrown.

hta: sounds like you confirmed this is a bug in #12 so I'll assign this to you for further triage within your team.

Taylor, can you comment on whether we can either stop reserving 1023 or throw an exception if others try to use it?

It's not that the ID is taken, but rather that we create exactly 1023 streams and never add any. Why exactly 1023 (and not, say, 1024)? I don't know. May just be an off-by-one error.

hta@: If an application requests a stream ID outside the currently allocated range, should we try to add streams? The spec currently says an exception should only be thrown if the ID is taken by another data channel. That would lead me to believe we *should* try to add streams.

The original contributor says it works when he uses 0 (or apparently any other number).

People should be able to create datachannels, and if we support external negotiation at all, they should be able to pick their own numbers. If they pick a number that's in use (or cannot be used), they should get an error; if they don't, it should work.

Can you look at the code pointed to in #7 and say what he should have done?

(I don't understand the "we create 1023 datachannels" - who is "we" in this case?)

It's not that 1023 data channels are created, but 1023 SCTP streams. So, only stream IDs 0-1022 can be used without adding additional streams.

When the SCTP association is created, the WebRTC endpoints negotiate an initial number of outgoing and incoming streams. The data channel spec states an implementation SHOULD negotiate the maximum number of streams, which is 65535 (https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2). But we negotiate 1023 instead; perhaps this was to save memory, since usrsctp allocates memory for each stream negotiated.

So the question is: If a WebRTC implementation (such as ours) does *not* negotiate the maximum number of streams, and an application runs out of IDs or tries to allocate an ID outside the allocated range, should we use the stream reconfiguration extension to add additional streams? https://tools.ietf.org/html/rfc6525#section-4.5

If so, this may be something the rtcweb data channel spec should call out.

I think the quick fix is to reject attempts to use stream IDs outside the range we have negotiated. Since there's nothing in the API to prevent the user from attempting to set the stream ID to 1000000, we have to check the range anyway, and return the right error.

We should file a (for now, low priority) bug for increasing the number of SCTP streams we negotiate (this would probably result in an ask to the SCTP folks to decrease the footprint of non-used SCTP streams). No particular opinion on renegotiation, but it seems like a larger project than just checking the value.

(I was wrong - the API data object is an "unsigned short", so WebIDL should reject an attempt to use 1M as an ID.)

WebIDL would reject 1M, but it would *not* reject 65535... and since 65535 is the maximum number of streams, and IDs are 0-based, an ID of 65535 will never be possible.

Anyway; how should we reject attempts to use IDs outside the negotiated range? Also, consider that it's possible to create a data channel before the SCTP INIT/INIT-ACK handshake completes (in other words, before we know the negotiated ID range). So in that case, we couldn't throw an exception in createDataChannel since it returns immediately.

@deadbeef can you raise a bug against the spec on this point?
Seems to me we have a problem that has to be solved at spec level.

I agree; thanks for your input. Here's an issue: https://github.com/w3c/webrtc-pc/issues/746

In the meantime, this CL should at least ensure that ID 1023 doesn't have unique behavior: https://codereview.webrtc.org/2254003002/

The spec issue is resolved. @deadbeef, can you triage the issue again?

Well, the spec issue was resolved by saying "it's closed with an error", but we're still working out how DataChannel error events work in the standard. So we should wait for that to settle first.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot