Viewer does not resend SDP offer if master receives SDP offer but fails to send answer

[fblundun]

In my code, the "viewer" side of the WebRTC call uses the KVSWebRTC.SignalingClient.sendSdpOffer function to send an SDP offer, and the "master" side of the call listens for "sdpOffer" events and reacts to them by calling KVSWebRTC.SignalingClient.sendSdpAnswer.

This usually all works fine. But I've found that the following sequence of events can happen:

• The viewer user opens the webpage, then sends an SDP offer
• The master user opens the webpage, and receives the SDP offer
• Before the master side can send an SDP answer, the master user refreshes the page
• The master user tries to rejoin the call, but no longer receives any SDP offer event - it's as if the offer has been swallowed by the original aborted session. The connection can only be made if the viewer side makes a new SDP offer.

Am I correct in thinking that the SDP offer is "consumed" when the master side signalling client first fires the "sdpOffer" event?

What's the appropriate way to handle this? Is the viewer side supposed to speculatively make fresh SDP offers every few seconds, in case the above sequence of events has occurred? Is there any way for the viewer side to know that their SDP offer has been lost?

(I also asked this on StackOverflow: https://stackoverflow.com/questions/72690321/how-do-i-rescue-my-webrtc-connection-when-my-sdp-offer-is-swallowed)

[disa6302]

@fblundun ,

You are correct. The master connection needs to be opened first so that the offer sent by the viewer can be consumed. If you refresh the master page, the viewer needs to resend the offer. This kind of handshake mechanism will have to be incorporated outside of the realm of WebRTC. You can have some kind of=handshake message between master and viewer to allow this.