Feedback and questions regarding DataChannel large-file transfers and multipoint usage

Hello WebRTC WG,

My name is *Yvan Ngoudjou*, and over the last few years I’ve been working
on two WebRTC-based projects that exposed some behaviors or limitations
where I believe feedback from the Working Group might be valuable.

While implementing these projects, I encountered recurrent patterns related
to *multipoint architectures* and *large DataChannel transfers*, and I
would appreciate guidance or confirmation regarding the expected behavior
from the current specification.
------------------------------
*1. Multipoint (mesh) usage at small scale — API considerations*

In one of my projects, I implemented a small-scale multipoint architecture
(3–6 participants) using pure mesh with RTCPeerConnection.
From a spec perspective, I’m trying to understand:
*a) Is the current API surface intended to fully support small multipoint
scenarios via mesh, or are users implicitly expected to move toward SFU
architectures for stability?* *b) Are there known areas in the spec where
multipoint mesh creates edge cases (e.g., SDP negotiation sequencing, glare
handling, ICE restarts across multiple peers) that the WG considers
out-of-scope for further improvements?* *c) Would the WG be open to
documented guidance or non-normative notes addressing best practices for
small multipoint topologies built purely on top of the standardized API?*

Mesh clearly works today, but in practice developers tend to rebuild custom
logic around negotiation and connection orchestration.
Clarifying the WG’s position would help tool authors (including myself)
understand the intended use boundary.
------------------------------
*2. Large-file peer-to-peer transfer over DataChannels (>4 GB)*

My second project involves peer-to-peer transfer of large files using
a *reliable
DataChannel with chunking*.
During testing, several limitations surfaced:
*a) Transfers above ~4 GB fail or stall*

Across Chromium-based browsers, transfers of very large files tend to hang
or terminate prematurely.
Is the specification expecting any implicit limitation (buffering, internal
SCTP behavior, memory pressure, congestion control) that implementers must
follow?
*b) Is there a recommended approach (from a WebRTC API standpoint) when
handling long-lived DataChannels transporting high-volume data?*

For example:

   -

   aggressive backpressure management?
   -

   limiting RTCDataChannel bufferedAmount?
   -

   recommended pacing strategies?

The current spec gives implementers freedom, but guidance or non-normative
notes might be beneficial for interoperability.
------------------------------
*3. iOS / Safari DataChannel interop issues*

During testing with Safari/iOS, even small file transfers (few MB)
frequently fail.
I understand that WebKit’s WebRTC implementation is still evolving, but I’d
like clarification on:
*a) Are there known interop limitations for DataChannel reliability on iOS
that the WG officially tracks?* *b) Would contributions documenting these
failures (logs, reproducible tests, etc.) be useful to the WG or should
they be directed exclusively to WebKit’s bug tracker?*

I am willing to provide reproducible test cases if they can help move
discussions forward.
------------------------------
*Closing*

I’d be happy to contribute additional implementation feedback, tests, or
clarifications based on my experience with:

   -

   multipoint mesh call setups,
   -

   chunked high-volume DataChannel transfers,
   -

   Safari/iOS interoperability issues.

Thank you for maintaining this specification and for your guidance.

Best regards,
*Yvan Ngoudjou*