- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Apr 2019 09:22:39 +0000
- To: public-webrtc-logs@w3.org
[rtcweb-data-channel-13, sec 6.2](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.2) says that implementations should allow for 65535 channels (with ids 0 to 65534):
The number of streams negotiated during SCTP association setup SHOULD
be 65535, which is the maximum number of streams that can be
negotiated during the association setup.
IIRC from what @tuexen told me, the rationale was that renegotiation of the amount of streams would be unnecessarily complex (which I would agree with) and memory for those streams can be allocated on demand.
AFAIK current browser implementations only restrict the amount of data channels due to a limitation of usrsctp which allocates memory for each stream beforehand, see https://github.com/sctplab/usrsctp/issues/121. And, at least on mobile browsers, having a couple of MiB (or so) per page that creates an `RTCPeerConnection` is not desirable.
That's the background
---
My thoughts: I think browsers should always support 65535 channels. Only other endpoints may use less than that (but they aren't targeted by the W3C API). I'm not strongly opposed to changing the spec slightly and say "[...] if the implementation allows less, throw X [...]" but I do see value in keeping it the way it is to nudge implementations to actually support 65535 channels and declare anything else proprietary.
--
GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2158#issuecomment-478915393 using your GitHub account
Received on Tuesday, 2 April 2019 09:22:44 UTC