I have a specific issue where I'm using WebRTC (voice and video).
I want to keep a connection/voice/video streams alive between webpages on a website. I thought I could use shared web workers to run in the background?
Any guidance would be great. I've looked at other posts but they're quite old and wondered if anyone had any, more, up-to-date information or ways I could tackle this issue?
UPDATE: Shared Web Workers are the incorrect way of tackling this problem. Service Workers are the way forward for maintaining after the web page is terminated.
Keeping the webRTC connection alive between page loads seems like a rare use case. Normally, you start a call and remain on a single page. I guess it could make sense if you wanted to embed a customer support like webRTC widget on a site and have that widget follow a user through page navigations under a single domain.
I don't think saving/reusing the blob URL will allow you to reconnect on a page reload for security issues/hijacking potential.
There is the IceRestart constraint which might help. Apparently you can save the SDP info to local storage, reuse the negotiated SDP, then call an IceRestart to quickly reconnect.
As described in section 3, the nominated ICE candidate pair is exchanged during an SDP offer/answer procedure, which is maintained by the JavaScript. The JavaScript can save the SDP information on the application server or in browser local storage. When a page reload has happened, a new JavaScript will be reloaded, which will create a new PeerConnection and retrieve the saved SDP information including the previous nominated candidate pair. Then the JavaScript can request the previous resource by sending a setLocalDescription(), which includes the saved SDP information. Instead of restart an ICE procedure without additional action hints, the new JavaScript SHALL send an updateIce() which indicates that it has happended because of a page reload. If the ICE agent then can allocate the previous resource for the new JavaScript, it will use the previous nominated candidate pair for the first connectivity check, and if it succeeds the ICE agent will keep it marked as selected. The ICE agent can now send media using this candidate pair, even if it is running in Regular Nomination mode.
https://bugs.chromium.org/p/webrtc/issues/detail?id=979
https://datatracker.ietf.org/doc/html/draft-li-rtcweb-ice-page-reload-02