Janus-gateway: Data channels failing in FF Nightly (69.0a1)

[mqp]

You can see that the text room demo fails to load. The proximate reason it fails to load is that although Janus emits a webrtcup event, the data channel's readyState is connecting forever, never transitioning to open. My custom plugin, working with my own Javascript client library, also fails, indicating that it's either an issue in Nightly or an issue in Janus, but I'm not sure which yet.

I will update this issue with more information as I learn more.

[mqp]

I narrowed down when the regression happened and created this bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1562341

[lminiero]

Thanks for the link, I'll track the issue on their bugzilla to see if it's something we're doing wrong ourselves.

[ibc]

HEY!!!! do this!

https://bugzilla.mozilla.org/show_bug.cgi?id=1562341#c28

   // Set SCTP_ENABLE_STREAM_RESET.
   struct sctp_assoc_value av;

-  av.assoc_value = SCTP_ENABLE_RESET_STREAM_REQ;
+  av.assoc_value = SCTP_ENABLE_RESET_STREAM_REQ | SCTP_ENABLE_RESET_ASSOC_REQ | SCTP_ENABLE_CHANGE_ASSOC_REQ;

   ret = usrsctp_setsockopt(this->socket, IPPROTO_SCTP, SCTP_ENABLE_STREAM_RESET, &av, sizeof(av));

So basically SCTP_ENABLE_CHANGE_ASSOC_REQ is required as per https://tools.ietf.org/html/rfc6525#section-6.3:

SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing
Streams Requests if this flag is set; deny them if not.

However, in sctp.c Janus is just setting av.assoc_value = 1; (here)

In usrsctp:

netinet/sctp.h
186:#define SCTP_ENABLE_RESET_STREAM_REQ    0x00000001
188:#define SCTP_ENABLE_CHANGE_ASSOC_REQ    0x00000004

So Janus is just enabling SCTP_ENABLE_RESET_STREAM_REQ, but it's not enabling SCTP_ENABLE_CHANGE_ASSOC_REQ which is required for allowing the remote to dynamically add more outbound channels (as Firefox 69 does).

😀😀😀😀😀😀😀

[lminiero]

@ibc thanks! I'm out of office today, so mentioning @atoppi to take care of this later.

[ibc]

Cool. Once you do it, may you also please try to have more than 32 open DataChannels in FF 69? As I've reported in the Bugzilla issue I don't think it's possible.

[atoppi]

Actually just changing

- av.assoc_value = 1;
+ av.assoc_value = SCTP_ENABLE_RESET_STREAM_REQ | SCTP_ENABLE_CHANGE_ASSOC_REQ;

is enough to make Firefox 69 happy.

This is because FF69 is requesting 16 more outbound streams in a RE_CONFIG chunk after the INIT and COOKIE chunks. As @ibc suggested, in order to permit the outbound streams increasing operation on the server, SCTP_ENABLE_CHANGE_ASSOC_REQ must be added to the socket options. Conversely, I have observed that Janus denies the RE_CONFIG request and Firefox 69 nevers sends a datachannel open request.

I can't fully understand why FF69 is issuing that RE_CONFIG, it might also be a bug, so before taking into account a patch on Janus I'd wait for the resolution of the related issue on Bugzilla.

[lminiero]

I think we should do that anyway, since as @ibc pointed out in the bugzilla issue SCTP_ENABLE_CHANGE_ASSOC_REQ is mandatory apparently.

[ibc]

I can't fully understand why FF69 is issuing that RE_CONFIG, it might also be a bug, so before taking into account a patch on Janus I'd wait for the resolution of the related issue on Bugzilla.

AFAIU by reading the rationale given in the Bugzilla issue, they do not want to allocate all SCTP streams until DTLS is connected or something like that.

BTW: Guys, can we please move the discussion to the Bugzilla issue? I'm now in the hateful scenario in which "I should provide a fucxxxxx jsfiddle to reproduce the problem" just because I do know that FF 69 fails to create more than 32 DataChannels...

[ibc]

False alarm, everything is fine. FF 69 can create up to 2048 DataChannels if properly negotiated with the server as per comment above.

[lminiero]

This commit should fix all the above:

1. Firefox 69 failure
2. the crash @atoppi mentioned
3. max number of datachannels bumped to 128 (256 streams)

Thanks to all for the help and discussion!

[mqp]

For anyone who comes across this in the future -- the issue in the associated Bugzilla causing Firefox to renegotiate the stream count unnecessarily was resolved, so Firefox should be working again even without this patch.