WebRTC private-to-private: chatStream is randomly 'remotely' closed with no obvious reason (probably Firefox bug)

1. The example starts normally, and usually it is possible to send and receive few messages.
2. But then one peer observes remote close write event and overall 'close' on the chatStream.
3. The other peer have no idea about that and is still able to write some data to the channel (but such data will be lost somewhere).

The connection interruption seems to be independent of time between consequent messages (probably not a consequence of some timeout) and of size of the messages (probably not overflow).

I turned tracing and debug logs on and observed no FIN / FIN_ACK exchanges related to such interruptions from either side. Replacing yamux with mplex also does not prevent that behavior.

When I removed ping service from clients, the interruption seemed to occur later, so the stream stays for longer. It may be just a coincidence (that way I tried to reduce number of connection reuse requests).

Also there are rare sessions when the interruption does not occur.

The issue occurs in firefox (ver 145), but not in chromium ( 143.0.7499.169 )

I also found that https://bugzilla.mozilla.org/show_bug.cgi?id=1603887 and tried to use applicable fix (setting dummy 'datachannel' event listener on every connection), but it didn't work

package-lock.json

Start with the WebRTC private-to-private example and the chatStream close handling described in the issue. Reproduce the behavior in Firefox 145 with tracing and debug logs enabled, then compare it with Chromium and with yamux versus mplex; done means identifying the cause of the remote close and documenting or fixing the interruption so both peers observe consistent stream state.