May replace usrsctp with dcSCTP

[ibc]

Google's announcement: https://groups.google.com/g/discuss-webrtc/c/hY3VkIw2-20/m/Gd2O0Q4aCQAJ

[fippo]

mind you that this requires pulling all of libwebrtc as a dependency. Build-wise generating a standalone lib is easy but the includes of the base lib... ;-)

[ibc]

mind you that this requires pulling all of libwebrtc as a dependency.

I hope we could avoid that by using mediasoup built-in utils.

[jmillan]

Not enthusiastic about this.

We already know the libwebrtc code extraction inferno (BWE currently), and are working to get rid of it.

Let's see how it evolves.

[ibc]

Good news is that this new dsSCTP code has its own Timer implementation so I expect the dependency on libwebrtc to be less huge than expected.

[boivie]

Glad you found it,

dcSCTP will mostly depend on fairly simple utilities in /api and /rtc_base and unit tests depend on /test.

This is generally:

• Replacements from what's available in abseil that can't be used in WebRTC (like absl::Span -> rtc::ArrayView, absl::StrCat etc -> rtc::StringBuilder)
• Logging

Even if you would build dcSCTP as a standalone library from within the webrtc code, it wouldn't soak in that much.

An exception would be the timer (TaskQueueTimeout) implementation, that depends on the rtc::TaskQueue, which I guess is more complicated, but there is no hard dependency on that implementation (the client decides what it returns as DcSctpSocketCallbacks::CreateTimeout).

There have been ideas about making it a completely standalone library, but never more than ideas. This library has to mature first, which it does more easily inside WebRTC. I have no opinion here. I can't promise API stability, but we have more users than "dcsctp_transport.h" (also outside the WebRTC tree), where dcSCTP is used as a standalone library.

[ibc]

Thanks, @boivie. Very valuable input. We do not plan yet to integrate it so there is time for considering how to go here and also for the library to get more mature.