Restart connection when app goes to background

1

Hi all!

First of all, thank for all the awesome work on react-native-webrtc!

I have a question - how can I properly restart the connection if the app goes to background? I’ve re-running the offer/answer sequence by creating a new offer, but it doesn’t seem to work properly. E.g., remote stream is not fetched properly, and iceconnectionstate hangs a bit on “checking”, and then goes to “failed”.

And can I actually re-use the same RTCPeerConnection object, or should re-create everything from scratch, on both sides of the communication?

Thanks in advance.

2

You don’t really need to do that when the app goes to the background. On both iOS and Android you’ll be allowed to run on the background, as long as you have defined your background permissions right (iOS).

On Android >= 8 you app may still get killed, so make sure you use a foreground service while in a call: https://github.com/voximplant/react-native-foreground-service

Note that in the background JS timers don’t work, you can monkey patch setTimeout and friends to use: https://github.com/ocetnik/react-native-background-timer

Cheers!

3

Thank you for response @saghul! You’re right - on Android, it’s not necessary to restart WebRTC if AppState goes to background and then to active again, but it is necessary on iOS. iOS drops both WebRTC and websocket connection that I use for signalling.

Sorry to bug you again, but what kind of iOS permissions would I need to set in order to allow connections to remain active while app is in background?

4

Make sure you set the “audio” and “voip” background modes.

5

Thanks again @saghul. You’ve saved me countless hours. This works, now on iOS if app goes to background i get a red bar on top, so the system right fully assumes i’m in a call.

Still - sorry again to be a nuisance - but what should i do in case when either WebRTC live connection or WebSocket signalling connection get closed due to bad connectivity or whatever. How to properly attempt restart in that case?

6

Glad I could help!

If you are doing something like a calling app, you should probably trigger the same behavior as you did when you first made the call and shiow the user some error dialog.

7

@saghul (old thread, but same problem). We’ve noticed something interesting on iOS:
When there is at least one voice track FROM a peer (even if the peer has muted), the iOS app stays awake in the background. When there is no voice track from a peer, and the iOS app is not currently transmitting a voice track, the app will sleep in the background after about 40 seconds. By “not currently transmitting a voice track” I mean: they may have never unmuted, or they may have unmuted and then muted again. (in our code we replace the track with null when they mute, to save bandwidth)

We have both audio and voip as UIBackgroundModes.

Thanks for all your work on this great library.