PeerConnection goes to failed due to DataChannel

[Butcher-vj]

I'm trying to create a desktop sharing and file transfer in a single project with a web-app and an agent.
I have two data channels in my peer connection, primary and file transfer data channel.
In my primary data channel, I am continuously sending the mouse movement from the web to the agent and also my file transfer data channel is sharing file.
My file transfer logic is Stop-and-Wait ARQ. I will send every single packet after getting acknowledgement from the receiver so in this file transfer data channel there won't be any buffer overflow issue, right?
Whenever I use both data channels, my peer connection suddenly goes to failed state without any error message. It directly goes to failed state rather than going to disconnected and then to closed, what is the reason?

[Senthil455]

This usually points to the underlying WebRTC transport failing rather than the DataChannels themselves.

Even though you created two DataChannels (one for mouse movement and one for file transfer), both of them actually share the same SCTP/DTLS connection. So if that single transport gets overloaded or unstable, the entire PeerConnection can jump straight to the "failed" state.

A few things could be causing it in your case:

Continuous mouse movement events can generate a very high message rate, even if each message is small
Your file transfer uses Stop-and-Wait ARQ, which is good for control, but it doesn’t prevent congestion from the other channel
If the combined traffic exceeds what the transport can handle, buffers can fill up and the connection may fail

The fact that it goes directly to "failed" (without "disconnected") often indicates ICE or connectivity issues rather than a clean shutdown.

Some things you can try:

Throttle mouse movement updates (for example, send every 30–50 ms instead of continuously)
Monitor RTCDataChannel.bufferedAmount to see if data is backing up
Log iceConnectionState and connectionState to understand when it fails
Try running with only one DataChannel at a time to isolate the issue
Make sure STUN/TURN servers are configured properly, especially if NAT is involved

Also worth noting that Stop-and-Wait ARQ helps control the file transfer side, but since both channels share the same transport, it doesn’t protect against overload caused by the mouse stream.

If you can share logs (ICE states or buffer growth), it would help narrow it down further.