Keep connection/session/call allive on page/tab refresh

[Srlence]

Hi,

I am using SIP.js in combination with Asterisk and it works just fine. However I have an issue. when the user is in a call and let's say refreshes the browser window/tab the connection drops (call is lost or whatever you wanna call it). I would like this connection to stay alive so the user could be able to continue with the call after page has been refreshed.

I can confirm Verto in combination with freeswitch https://webrtc.freeswitch.org/verto/index.html is able to do that (tested it). During call you can refresh the page and still return to the call and hear audio/video. I know that in this scenario there seems to be some server side modules for freeswitch which in return might be keeping the session alive. Not sure cause i didn't dive into it and I want to use sipjs not verto :)

First I wanted to see if anyone in the group has encountered this real life problem. Users will be users and I am sure it happens a lot they refresh the page and consequently loose the call. If the user can easily return to the call this would be a much better user experience.

Can someone point me in the right direction how to handle this issue? ANY pointers really appreciated.

[Will Mitchell]

Hi,

I can definitely confirm that we've experienced this.  At OnSIP, we tend to build our apps around it, focusing on "Phone" apps that users leave open.  We've also added code to SIP.js to try to clean up the call appropriately when you do leave the page.  That said, I've been thinking about this a little, and it should be possible to "rehydrate" the session on a new page.  This is all theoretical at this point...I haven't tried it.  If you prevent SIP.js from sending a BYE on page unload, any server should believe the session is still there for at least a few moments.  On page reload, you can quickly reconnect and send an INVITE w/Replaces to negotiate a new session with the same FreeSwitch box.  There will be a short loss of audio as the page unloads, loads, connects, and renegotiates ICE and DTLS, but it should continue in the end.  The trickiest part is likely going to be persisting the session information from page to page, so that you can do the replaces.  That could be accomplished with localStorage, and then manually added as an extraHeader to the invite request.

All theory...haven't tried it...but that's what I would do.

-Will

[Srlence]

First of all Will thank you very much for such a speedy gonzales reply :)

I will definitely follow your suggestions. In our case the phone app is residing within a crm and it happens a lot that users are switching between tabs/windows so I am unable to prevent users from doing that. I could just simpl JS to prevent going to a different page.. but somehow i would like to liberate the user to do whatever he wants:)

I will post my findings.

[Srlence]

The first issue I encountered is storing objects in the local storage which apparently is able to store strings .. maybe i will convert the object to string .. will post a follow up on this.

[Minh Truong]

Does it work @Srlence? I am getting the same issue