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

*Hi Youenn, hi Tim,*

Thank you both for taking the time to review my questions and for providing
such clear and constructive insights.
Your answers were extremely helpful, and I appreciate the openness
regarding the current implementation constraints and the potential areas
where contributions or guidance could improve interoperability.
------------------------------
*🔹 1. Multipoint (mesh) usage*

It is very helpful to know that the current WebRTC API surface is intended
to support small-scale multipoint mesh scenarios, and that most of the
issues I’m seeing are likely tied to implementation limitations or network
constraints rather than to the specification itself.

I will also look more closely at the ICE candidate restrictions that can
appear when camera/microphone permissions are not granted, as this could
explain some of the failures observed on mobile networks.
------------------------------
*🔹 2. Large-file DataChannel transfers (>4GB)*

Thanks for confirming that these failures — especially on Chromium-based
browsers — are likely caused by implementation restrictions rather than by
any limit defined in the spec.

I will prepare reproducible test cases showing the stall/freeze cases when
sending large, long-lived streams through DataChannels, and I will share
them both with browser implementers and here if useful.

Tim, thank you for pointing out Iñaki’s article. I will reach out or
attempt to provide updated findings since the topic still seems very
relevant.

If, after investigating, it turns out that applications would benefit from
additional flow-control or pacing signals at the API level, I would be glad
to draft a proposal for discussion. I appreciate your openness to such
contributions.
------------------------------
*🔹 3. Safari / iOS DataChannel issues*

As mentioned, I can consistently reproduce DataChannel failures even for
small files (a few MB) on iOS/Safari.
Following your advice, I will file the corresponding bugs on
https://bugs.webkit.org and I’ll include detailed logs and reproducible
conditions.

Here is a simple way to reproduce the issue using an iPhone 14+ (Safari):

   1.

   Open Safari and go to *https://beta.sendfast.io/
   <https://beta.sendfast.io/>*
   2.

   Fill the form and validate your email
   3.

   Copy the generated transfer links and send them to a recipient
   4.

   Keep the original browser window open (sender side)
   5.

   The recipient clicks *Download* on Safari
   6.

   The DataChannel begins transferring but the download never progresses
   due to browser-side limitations (no crash, but the stream stalls)

These tests are reproducible, and I can also provide the client-side source
code if needed for deeper analysis.
The failure does not appear on desktop browsers under the same network
conditions.
------------------------------
*🔹 Conclusion & Next steps*

I’ll start working on structured reproducible tests for all the cases
mentioned:

   -

   multipoint mesh edge cases
   -

   large DataChannel transfers (>4GB)
   -

   iOS/Safari DataChannel stalls

Once I have precise repro steps, logs, and traces, I will submit them both
to the relevant browser bug trackers and share them here if they can help
the WG’s interoperability discussions.

Thank you again for your time, guidance, and openness.
I’m very happy to contribute wherever it can be useful, and I remain
available for further discussion, collaboration, or test case preparation.


*Best regards, Yvan Ngoudjou*

Le jeu. 27 nov. 2025 à 11:06, Tim Panton <tim@pi.pe> a écrit :

>
>
> On 27 Nov 2025, at 09:22, Youenn Fablet <youenn@apple.com> wrote:
>
> Hi Yvan,
>
> Some thoughts below.
>
> On 23 Nov 2025, at 19:00, Yvan Wamba <yvangoudjou04@gmail.com> wrote:
>
> 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?*
>
>
> The current API should work for the usecase. TURN servers may be needed to
> ensure connection between peers.
>
>
> I think it is accepted that the majority use case is SFU (or MCU) based
> and new additions to the API tend to support that use case. But the API
> works for Peer to Peer and is seeing some traction in 1 to many fanout
> usage supported by spec changes.
>
> *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?*
>
> I am not aware of issues, except maybe the case of ICE candidate
> restrictions in case camera/microphone is not granted.
>
>
> The spec could give guidance about how many peer-connections are ’too
> many’ and how many simultaneous new peer connections can be created. This
> might be useful, since in our experience a new joiner to a mesh tends to
> create a _lot_ of ice failing traffic unless it paces the new connections.
>
>
> *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.
>
> I am not aware of documents like this owned by the WG.
>
>
> The WG has quite deliberately stayed out of the signalling - but as I said
> above it might be useful to know when a new peer connection would be likely
> to overload a user agent.
>
>
>
> ------------------------------
> *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?
>
>
> This looks like implementation restrictions, filing bugs is probably the
> way to go go.
>
>
> Agreed, bugs and test cases are the way to go here.
> There is an old paper
> https://lgrahl.de/articles/demystifying-webrtc-dc-size-limit.html#demystifying-webrtc-dc-size-limit discussing
> this - it might be useful to work with the author on an update?
>
>
> *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.
>
>
> Working with implementors first seems the right approach to diagnose the
> issue you are facing.
>
>
> If it emerges that there are signals the API needs to provide to the
> application to improve this, then please make an API proposal - I’d
> certainly be interested.
>
>
> ------------------------------
> *3. iOS / Safari DataChannel interop issues*
>
> During testing with Safari/iOS, even small file transfers (few MB)
> frequently fail.
>
> This looks like an implementation restriction or a bug.
>
> 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.
>
> It would be great if you could provide reproducible test cases. Filing
> bugs at https://bugs.webkit.org for iOS WebKit is one way to provide such
> feedback.
>
> ------------------------------
> *Closing*
>
> I’d be happy to contribute additional implementation feedback, tests, or
> clarifications based on my experience with:
>
> In summary  think your best contributions to this group would be :
>
>
>    -
>
>    multipoint mesh call setups,
>
> Advise on spec wording changes that might help alleviate the problem,
> either by guidance or by a new API point.
>
>
>    -
>
>    chunked high-volume DataChannel transfers,
>
>
> Create a platform test that demonstrates spec violation ;-) Or at any rate
> a test case failure matrix that we could bring to the group as a basis for
> discussion.
>
>
>    -
>
>    Safari/iOS interoperability issues.
>
>
> Test case.
>
>
> Thank you for maintaining this specification and for your guidance.
>
> As an aside I’d love to swap notes with you on your non-SFU usage - I
> suspect we have some common interests!
>
> Yours.
>
> Tim Panton
>
> Best regards,
> *Yvan Ngoudjou*
>
>
>