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

> 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 <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
>>