Decouple signaling server connection from p2p connection

[saba-abi]

Component your feature request relates to

• Signalling server
• Frontend library
• Frontend UI library
• Matchmaker
• SFU
• This repo

Problem your feature solves? Please describe.
I noticed that when the signaling was successful and the webrtc stream is playing, then when the ws connection to the signaling webserver is disrupted the p2p webrtc connection is also teared down. I think this is unnecessary and e.g. makes deployments complicated.

Describe the solution you'd like
Don't tear down webrtc connection when signaling connection is disrupted.

Additional context
I am using the pixelstreaming libraries:
"@epicgames-ps/lib-pixelstreamingsignalling-ue5.7": "^0.2.1",
"@epicgames-ps/lib-pixelstreamingfrontend-ue5.7": "^0.2.2",

[mcottontensor]

Thanks for the suggestion, it's a reasonable thing to want. You're right that once a WebRTC connection is fully established the media flows peer to peer (or via TURN) and doesn't strictly need the signalling channel anymore. Signalling is really only needed for the initial setup and for later renegotiation.

The reason the stream still goes down today is a bit more involved than the frontend closing the connection. When your player's websocket to the signalling server drops, the server sees that close and treats it as the player having left. In PlayerConnection.ts the transport close handler calls unsubscribe(), which sends a playerDisconnected message to the streamer. The UE Pixel Streaming plugin then tears down its side of the WebRTC connection. So by the time the browser might try to hold onto its peer connection, the streamer has already dropped its half and the media stops regardless.

On the frontend the websocket close handler doesn't close the peer connection directly, but if auto-reconnect is enabled it rebuilds the whole session from a fresh config, which also means a brand new peer connection rather than reusing the existing one.

The parts of this that live in this repo, the signalling server and the frontend library, are the tractable ones. A grace period or session-resume concept on the server (so a brief websocket drop doesn't immediately unsubscribe the player and notify the streamer, and a reconnecting player can re-attach to its existing session) plus frontend changes to reconnect signalling without rebuilding the peer connection would both be straightforward to PR and release here.

The harder piece is the UE plugin. It's the side that acts on playerDisconnected and closes its half of the connection, and any change there is tied to UE engine releases rather than this repo's release cadence. We also don't take external PRs for the plugin, so that part isn't something you could contribute directly. That's the main thing that makes a full end-to-end fix slower than it looks, even if the server and frontend changes are easy.

One note on versions: Pixel Streaming 1 is no longer being actively developed, so any engine-side change here would come through in Pixel Streaming 2.

So it's a fair request and we can log it. The repo-side changes are very doable and we'd happily talk through an approach and review a PR for those. The engine-side behaviour is the gating factor, so I'd set expectations around timing accordingly. Worth noting too that anything needing signalling during the outage (renegotiation, ICE restart, and input over the data channel if that path is affected) still wouldn't work until the connection is back.

[saba-abi]

Ok I understand. Thanks! Would be awesome when this would be implemented in the plugin!

Until then maybe the following workaround is implementable in the library?

• when player disconnected from signaling port don't send playerDisconnected yet to the plugin
• only when there is no ping received for a configurable amount of time send playerDisconnected
• reconnecting of the player just reattaches the session

What do you think?

[mcottontensor]

That sounds like a reasonable approach on the surface. It does carry some behaviour changes and edge cases though, so for now it's something you'd want to carry on a fork rather than something we can take into the official release. Happy to answer questions if you go down that road.