WebRTC transport support

[Menduist]

WebRTC Stack Implementation for libp2p in Nim

This issue covers the current status of our WebRTC stack implementation in Nim for our libp2p project. Below is an overview of the protocols involved, progress so far, and details about what’s left to complete. This issue will serve as a reference for the team to continue the implementation and maintenance.

Overview

The WebRTC stack we’re building consists of five main protocols:

• UDP for transport
• STUN for NAT traversal https://datatracker.ietf.org/doc/html/rfc5389
• DTLS for encryption https://datatracker.ietf.org/doc/html/rfc6347
• SCTP for reliable, ordered data transmission over WebRTC https://datatracker.ietf.org/doc/html/rfc4960
• DataChannel for application data https://datatracker.ietf.org/doc/html/rfc8831

You can currently find all these protocols merged in this PR: https://github.com/vacp2p/nim-webrtc/pull/24

While some are fully implemented, others require additional work, especially around cross-platform stability and testing. Here’s a detailed look at the status of each protocol, what’s working, what isn’t, and areas needing follow-up.

---

Protocol Breakdown

1. UDP

• Status: Fully implemented
• Library: nim-chronos
• Notes: No additional implementation required. We are leveraging nim-chronos, a reliable library we already use widely, so no issues are anticipated here.

2. STUN (NAT Traversal)

• Status: Implemented by us
• Details: STUN is implemented with the mandatory attributes required for our application. Some optional attributes, like realm or nonce, are not included since they are unnecessary for our use case as far as I know.
• To Do: None, unless additional STUN attributes are required in the future.

3. DTLS (Encryption)

• Status: Wrapped from Mbed-TLS
• Library: nim wrapper nim-mbedtls / C library Mbed-TLS
• Details: By wrapping Mbed-TLS, we avoided a full DTLS implementation. However, wrapping with c2nim introduces several pain points:
  • Wrapping Limitations: The wrapper tool we used (c2nim if I remember correctly) is not always able to handle some C specificity, requiring portions of the code to be wrapped manually.
  • Maintenance Overhead: To keep the wrapper updated with the latest Mbed-TLS fixes and improvements, we often need to reapply these manual adjustments, adding to maintenance time and complexity.
  • Cross-OS Compilation: Variability in OS environments complicates compilation, especially for cross-compiling between systems as a lot of these things are done using C macros which are not really well detected by the wrappers.
• To Do: Long-term, explore options to improve cross-platform compatibility. Also, set up regular checks for upstream Mbed-TLS updates to stay secure and maintain compatibility.

4. SCTP (Reliable Data Transmission)

• Status: Wrapped from Usrsctp
• Library: nim wrapper nim-usrsctp / C library usrsctp
• Details: Similar to DTLS, wrapping Usrsctp provides SCTP functionality without a full implementation. The trade-offs are:
• To Do: Same as DTLS; monitor Usrsctp for updates and be mindful of cross-platform compilation needs.

5. DataChannel

• Status: Implemented by us. Initial implementation is complete, but several important remain untested or incomplete.
• Details: Our DataChannel implementation should support reliable, ordered messaging across peers.
• To Do:
  • [ ] Extensive Testing: Run a broad suite of tests to ensure stability and identify any missing or incorrect functionality.
  • [ ] Stream Management: Ensure we can request additional streams if necessary, depending on usage patterns.
  • [ ] Data Handling: Implement handling for both string and binary data, including differentiation based on incoming data type.
  • [ ] Client/Server Mode Differences: Account for different behaviors when the DataChannel operates as a client vs. as a server.
  • [ ] Graceful Stream Closure: Close DataChannel streams in line with the other protocols to ensure consistency and clean disconnection.

---

Summary

The WebRTC stack implementation is well underway, with STUN fully implemented and stable UDP handling through nim-chronos. Wrapping for DTLS (via Mbed-TLS) and SCTP (via Usrsctp) provides essential protocol support, but comes with challenges in maintenance and cross-platform compatibility. DataChannel is in place but needs further testing.

[mxinden]

(aka libp2p-webrtc-direct)

Note that webrtc direct will likely not be promoted to the general libp2p WebRTC protocol, given that it requires a previous WebSocket connection to exchange the SDP.

The goal of the upcoming design (https://github.com/libp2p/specs/issues/220) is to not require a previous exchange.

Happy to expand on this in case you are planning on working on this any time soon.

[lchenut]

We dig a bit on the SCTP part with @Menduist lately, here what we found:

• There's no native implementation for the SCTP in nim that we could use, https://github.com/metacontainer/sctp.nim is the only one we found, it's not maintained and use reactor instead of chronos as an asynchronous library. However, it imports a C library that looks promising.
• The C implementation used by sctp.nim is https://github.com/sctplab/usrsctp, it's well maintained, it's importable, it looks usable for our purpose. Not much more to say. I'll check if it's easily feasible soon.
• The other option is to implement our own version of SCTP, looking at the pion implementation in Go (~5500 LoC), it shouldn't be too long to code.

As for the full webrtc stack, only two were satisfying, the google one in C++ and the pion one in Go. I'm not sure if we can use those directly though.

[lchenut]

A quick overview of what was done since last update.

• The SCTP is more or less done. I wrappped the https://github.com/sctplab/usrsctp library. It needs a more testing and tweaking but beside that, the wrapping is done. You can take a look at it here.
• As for DTLS part, BearSSL still doesn't implement it. It might be a good idea to take a look at other implementations.
• The DataChannel is the next thing I'll look at, assuming it doesn't need DTLS features to work

Some DataChannel relevant links:

• the pion implementation https://github.com/pion/datachannel/blob/master/datachannel.go
• An usrsctp example, I'm not 100% sure that it's a datachannel implementation but it might be interesting to take a look at it https://github.com/sctplab/usrsctp/blob/master/programs/rtcweb.c
• And the RFC, obviously https://www.rfc-editor.org/rfc/rfc8831