W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2019

Re: [webrtc-pc] DataChannel max value for "id" before connecting? (#2158)

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Tue, 02 Apr 2019 09:22:39 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-478915393-1554196957-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:56 UTC