- From: jesup via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Apr 2018 15:00:41 +0000
- To: public-webrtc-logs@w3.org
The point of this spec decision was that you can exclude the complexity of reconfig (which isn't required in SCTP IIRC, and adds complexity to to the DataChannels impl) if you set the max number of channels to the maximum possible. So, the spec really was supposed to mandate 0-65534 (we reserved 0xFFFF) streams. Given external negotiation (another contentious point), a user of webrtc can use any id in that space, and is supposed to assume it will work (though can can fail the open, of course, even if it should work). IMHO (though not relevant) it would have been simpler to require imply support for reconfig than the require SCTP impls to implement and test dynamic allocation internally -- and I think this has been borne out in practice. (Implementing reconfig wasn't *that* hard in DataChannels.cpp when I first did it.) So: the decision in the IETF was to require 0-65534 be supported without reconfig. Unless we want to reopen that, we need to do the same here. -- GitHub Notification of comment by jesup Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1829#issuecomment-380133122 using your GitHub account
Received on Tuesday, 10 April 2018 15:00:52 UTC