I can still reproduce this with [my testing tool](https://rawgit.com/rawrtc/rawrtc/master/htdocs/webrtc/index.html). Just check *Offering*, click on *Start* and look at the browser log. > [Child 9446: Socket Thread]: D/DataChannel Deleting DataChannelConnection 0x7f22e126a400 [Child 9446: Main Thread]: D/DataChannel Constructor DataChannelConnection=0x7f22dd4ccc00, listener=0x7f22dd4cb408 [Child 9446: Main Thread]: D/DataChannel Maximum message size (outgoing data): 2147483637 (set=no, enforced=yes) [Child 9446: Main Thread]: D/DataChannel Setting number of SCTP streams to 256, was 10/2048 [Child 9446: Main Thread]: D/DataChannel Registered 0x7f22dd4ccc00 within the SCTP stack. [Child 9446: Main Thread]: D/DataChannel DC Open: label cat-noises/, type 0, inorder 1, prValue 0, listener (nil), context (nil), external: true, stream 0 [Child 9446: Main Thread]: D/DataChannel Inserting channel 0 : 0x7f22e12ba670 [Child 9446: Main Thread]: D/DataChannel Setting number of SCTP streams to 16, was 256/2048 [Child 9446: Main Thread]: D/DataChannel Queuing channel 0x7f22e12ba670 (0) to finish open [Child 9446: Main Thread]: D/DataChannel Init: origin = null This is before ICE even kicked in. For whatever reason, the amount of SCTP streams to be negotiated is overriden by `16`. IIRC this happens in the `DataChannelConnection::OpenFinish` function. May I add another note that [rtcweb-data-channel-13](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13) says that the maximum amount of streams SHOULD be announced. The only reason we don't is [early memory allocation](https://github.com/sctplab/usrsctp/issues/121). Thus, don't expect stream renegotiation support. I would say the majority of implementations don't have implemented support for it and there's actually no reason to do it once memory is allocated lazily. In addition: Please, if you have the resources, support the usrsctp team with a contribution by for example resolving this issue.
Bug 1562341 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I can still reproduce this with [my testing tool](https://rawgit.com/rawrtc/rawrtc/master/htdocs/webrtc/index.html). Just check *Offering*, click on *Start* and look at the browser log. > [Child 9446: Socket Thread]: D/DataChannel Deleting DataChannelConnection 0x7f22e126a400 [Child 9446: Main Thread]: D/DataChannel Constructor DataChannelConnection=0x7f22dd4ccc00, listener=0x7f22dd4cb408 [Child 9446: Main Thread]: D/DataChannel Maximum message size (outgoing data): 2147483637 (set=no, enforced=yes) [Child 9446: Main Thread]: D/DataChannel Setting number of SCTP streams to 256, was 10/2048 [Child 9446: Main Thread]: D/DataChannel Registered 0x7f22dd4ccc00 within the SCTP stack. [Child 9446: Main Thread]: D/DataChannel DC Open: label cat-noises/, type 0, inorder 1, prValue 0, listener (nil), context (nil), external: true, stream 0 [Child 9446: Main Thread]: D/DataChannel Inserting channel 0 : 0x7f22e12ba670 [Child 9446: Main Thread]: D/DataChannel Setting number of SCTP streams to 16, was 256/2048 [Child 9446: Main Thread]: D/DataChannel Queuing channel 0x7f22e12ba670 (0) to finish open [Child 9446: Main Thread]: D/DataChannel Init: origin = null This is before ICE even kicked in. For whatever reason, the amount of SCTP streams to be negotiated is overriden by `16`. IIRC this happens in the `DataChannelConnection::OpenFinish` function. It might be that this is related to an out-of-band negotiated data channel being created early. In that case, I would recommend adding a test case since oob negotiated channels have been a source of bugs in this implementation pretty often. May I add another note that [rtcweb-data-channel-13](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13) says that the maximum amount of streams SHOULD be announced. The only reason we don't is [early memory allocation](https://github.com/sctplab/usrsctp/issues/121). Thus, don't expect stream renegotiation support. I would say the majority of implementations don't have implemented support for it and there's actually no reason to do it once memory is allocated lazily. In addition: Please, if you have the resources, support the usrsctp team with a contribution by for example resolving this issue.