Bug 1562341 Comment 38 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Well, let me come back into this.

FF 69 does not allow creating DataChannels with id > 31. Well, it allows it since I do it with `negotiated: true` and FF doe snot complain. But then, when calling `dc.send(DATA)` it fails with:

```
OperationError: The operation failed for an operation-specific reason
```

So, in summary, it seems that FF 69 initially negotiates 16 outbound SCTP streams:

```
mediasoup:worker RTC::SctpAssociation::OnUsrSctpReceiveSctpNotification() | SCTP association connected, streams [in:16, out:2048]
```

(note: those are the logs in the server so "in" means FF outgoing streams and "out" means FF incoming streams).

Then FF renegotiates the association by incrementing the number of SCTP outgoing streams to 32;

```
mediasoup:worker RTC::SctpAssociation::OnUsrSctpReceiveSctpNotification() | SCTP stream changed, streams [in:32, out:2048, flags:0]
```

So that's all. Somehow FF 69 allows 0-31 outgoing SCTP streams and 0-2047 incoming SCTP streams. Since DataChannels are bidirectional SCTP streams, this means that FF 69 limits itself to 32 DataChannels (with id in 0..31). Period.

So no, FF does not try to "add streams" once those 32 outgoing SCTP streams are used, not at all.

This is very sad. Chrome limits the SCTP message size and so on, but at least it allows the application create up to 1023 DataChannels. Currently in FF 69 just 32 DataChannels can be simultaneously opened. Not enough at all for a SFU scenario.
Well, let me come back into this.

FF 69 does not allow creating DataChannels with id > 31. Well, it allows it since I do it with `negotiated: true` and FF does not complain (although it should not allow it). But then, when calling `dc.send(DATA)` it fails with:

```
OperationError: The operation failed for an operation-specific reason
```

So, in summary, it seems that FF 69 initially negotiates 16 outbound SCTP streams:

```
mediasoup:worker RTC::SctpAssociation::OnUsrSctpReceiveSctpNotification() | SCTP association connected, streams [in:16, out:2048]
```

(note: those are the logs in the server so "in" means FF outgoing streams and "out" means FF incoming streams).

Then FF renegotiates the association by incrementing the number of SCTP outgoing streams to 32;

```
mediasoup:worker RTC::SctpAssociation::OnUsrSctpReceiveSctpNotification() | SCTP stream changed, streams [in:32, out:2048, flags:0]
```

So that's all. Somehow FF 69 allows 0-31 outgoing SCTP streams and 0-2047 incoming SCTP streams. Since DataChannels are bidirectional SCTP streams, this means that FF 69 limits itself to 32 DataChannels (with id in 0..31). Period.

So no, FF does not try to "add streams" once those 32 outgoing SCTP streams are used, not at all.

This is very sad. Chrome limits the SCTP message size and so on, but at least it allows the application create up to 1024 DataChannels (from id 0 to 1023). Currently in FF 69 just 32 DataChannels can be simultaneously opened. Not enough at all for a SFU scenario.

Back to Bug 1562341 Comment 38