Midsession Reoffer

[gbfarah]

Hi,
I'm tackling an issue that I would appreciate feedback on...
Issue is pretty simple. When using pion to communicate to a browser I need to address maintaining a webrtc connection being resilient to a page refresh.

Conceptually I've tried two solution and both have failed . Solution 1 is most ideal but I understand if their is a WebRTC limitation I'm missing.

Solution 1

1- Server create a WebRTC offer.... The SDP for this offer is cached by signalling app
2-Browser answers the offer and remote SDP is communicated back to server .. WebRTC connection successfully established
3- Browser refreshes. The original offer in 1 is given again to the browser and answered. Remote SDP passed back to the server
4. No connection established

In the above conceptually I can't see why using an old server offer to a new browser doesn't work . From a crypto perspective all required info is known by each of the browsers

Solution 2
1- Server create a WebRTC offer.... The SDP for this offer is cached by signalling app
2-Browser answers the offer and remote SDP is communicated back to server .. WebRTC connection successfully established
3- Browser refreshes. Server is asked to reoffer
4- New Browser presents the answer
5. No connection established

I'm a little confused by neither of these solutions works and prefer not to destroy and recreate peer connections

Many thanks in advance

[Sean-Der]

Hey @gbfarah

Re-establishing a WebRTC connection across pages refreshes isn't supported by WebRTC. It will take some effort to make work. I would suggest moving your state into a generalized container.

I will explain below why it is difficult. I am going to use terms explained in WebRTC for the Curious

Moving through the subsystems in WebRTC

• Signaling - Not a problem
• ICE - Not a problem. You can do a ICE Restart
• DTLS - Technically possible, not supported in Pion. You can do a DTLS Restart this will re-establish the crypto session.
• SCTP - Not technically possible today. WebRTC doesn't have a concept of a 'SCTP Restart'. One PeerConnection will have a established SCTP session and the other will be attempting to handshake. This could possibly be added to the spec.

---

If you are really interested in making this work it is technically possible. It is a decent amount of effort though. My recommendation would be to implement a layer of redirection in your application to support users refreshing. If you are really interested in making this work I am happy to support you implementing this in Pion!

[gbfarah]

Many thanks for the followup. I think this feature would be super useful to the community...

From my simple understanding this is how I see it (please correct me if I'm wrong)

Consider example where Pion Server sends an offer SDP which the browser answers..... In a refresh we communicate the same SDP that Pion Server previously generated. The refreshed browser is none the wiser that this is an old WebRTC SDP offer and answers it all the same

From server perspective, I was thinking rather than restarting / re-establishing things what we are actually trying to do is a PeerConnection rewind all the way back to cryptographic/signalling state as at when the offer was originally generated.....This requires two distinct operations

1. Immediately after a peer connection offer , pion takes a copy of the state of each of DTLS , ICE, SCTP internally.
2. On a browser refresh (or even moving client devices) , the signalling app simply communicates the existing offer SDP (which it had cached) and calls a peerConnection.RewindToOffer() on the Pion side. The Rewind function simply reverts the saved state in 1
3. Answer from new browser is thus handled in the same manner as for the original answer

The other major advantage of this revert concept is that enables the pion server to simply multiplex between clients without trashing and recreating the peer connection. This is similar to a reinvite handling in traditional telephony

Let me know if the above makes sense and your thoughts