Reconnect during a call in case of network change

Skip to first unread message

Максим Куличенко

Sep 30, 2021, 2:55:01 AMSep 30
to JsSIP

Hi! I'm currently trying to implement reconnect after network change without losing a current call and noticed the following behavior:

  • if network changes JsSIP continues to send packets over established websocket connection but receives no answer to those packets
  • once INVITE for session prolongation is sent through that ws connection, it doesn't go through and that is being considered as critical transport error causing session termination.

I've tried to listen to `iceconnectionstatechange` which is triggered with disconnected if I change my network. And even though I'm able to renegotiate for ICE candidate successfully it doesn't matter cause ws connection is closes along with the session.

If it's not possible to add reconnection ability directly into JsSIP than how can I do it for my project only?

I would really like to receive some tips on how to proceed with adding such a feature 🙏. Thanks!

Olle E. Johansson

Sep 30, 2021, 3:49:27 AMSep 30
to 'xymo' via JsSIP
You have to look at this from a higher level too. If the IP of one SIP endpoint changes - how do you preserve the call? You’ve set up the call using a websocket that connects from your IP to the IP on one server and suddenly wants to move it all. RTP media flows in one flow and you want to redirect it elsewhere? If all of that happened automatically it would be a very good attack vector.

You have to assume that the websocket died if the old IP disappeared. You may still be able to send RTP packets and depending on the other side you may receive to the new address. That assumes that the other side notices that you send from a new IP. It may just ignore the incoming RTP.

Sorry, I haven’t got the details on JSsip handling here, but just wanted to give you a wider outlook on the problem. It’s a problem we’ve been discussing in the SIP world for a long time. There’s no easy hack on one side to handle it. 

Having said that there are call transfer tricks that can be done to reconnect to the call. Other developers may chime in on how they solved the problem, as it is not unknown in the mobile world (going from mobile data to Wifi is just one example).


Максим Куличенко

Sep 30, 2021, 6:32:29 AMSep 30
to JsSIP
Thanks for your insights, I now understand problem space a little bit better! I'm quite new to all of this (SIP, SDP, RTP, etc) and only started to dig into it about two weeks ago. So it's quite hard for me to implement such a feature but I know it's possible - we've tried to use linphone for our calls and it is able to reconnect on network change.

Also hoping that other developers can join and share how they implemented such feature with JsSIP or give some advice on how to proceed

четверг, 30 сентября 2021 г. в 10:49:27 UTC+3, Olle E Johansson:

Максим Куличенко

Sep 30, 2021, 9:05:48 AMSep 30
Currently I'm thinking that I should recreate WebSocket once I notice network change. After that I probably should renegotiate for ice candidate and send reINVITE to a new websocket. Depending on our server (SBC) configuration it may or may not work and I'm not yet sure how to do each of these things with JsSIP except for ice candidate renegotiation. I'll keep trying and post here if I'm able to proceed somehow

чт, 30 сент. 2021 г. в 13:32, Максим Куличенко <>:
You received this message because you are subscribed to a topic in the Google Groups "JsSIP" group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit

Максим Куличенко

Oct 1, 2021, 10:08:06 AMOct 1
to JsSIP
Small update: I have been able to provide my own WebSocketInterface implementation and reconnect WebSocket once network has changed. I have also been able to do ice renegotiation after that. But for some reason when I send INVITE into a new WebSocket connection I receive 408 Request Timeout as an answer to it. So far I have no idea what is it but will keep trying

четверг, 30 сентября 2021 г. в 16:05:48 UTC+3, Максим Куличенко:
Reply all
Reply to author
0 new messages