Handling Reconnects

Starting with version 2.6.0, Infobip RTC SDK is able to automatically reconnect any kind of established call in case of connection loss.

If successful, calls are reconnected and restored to the same state as prior to the disconnect.

Once reconnected, the call state is synchronised to ensure valid state transitions. This means that our SDK will emit a sequence of events that will correctly transition from the previous SDK state to the current state on our platform.

Prerequisites

To enable auto reconnect, you only need to set the corresponding autoReconnect flag when creating the call options.

Migrating from prior versions

Application Calls

Previously, we supported reconnecting for application calls, by recreating the application call. This essentially meant that a new call leg was created and would then replace the old one. This also required you to provide your own implementation of reconnectHandler to orchestrate this transition using your backend application.

This is no longer required, as the same call leg is being reused, and only media renegotiation takes place. Due to this, we removed the reconnect handler and all related types and fields.

Instead, there is only a single flag in the call options you need to set.

This also means that you will no longer be able to perform any modifications to the call options when attempting to reconnect.

Room Calls

In case you were using reconnect for room calls, please be aware that there are two main changes.

• The events ROOM_REJOINING and ROOM_REJOINED are replaced by the universal RECONNECTING and RECONNECTED events.

• Additionally, RECONNECTED (previously ROOM_REJOINED) will no longer contain any data. Instead, any changes in state will be communicated through call events (explained in the next section). You also won't need any new audio stream, as the previous one will be reused.

Handling reconnects

Once a connection loss is detected, assuming you have reconnect enabled, you will immediately receive the RECONNECTING event. This allows you to update your UI accordingly, so that the user knows that they are currently disconnected.

While reconnecting, certain actions, which rely on being connected to our platform (e.g. media modifications) are rejected and will result in a media error being thrown.

Once you are reconnected, you will receive the corresponding RECONNECTED event notifying you about this. The event itself don't contain any particularly useful information and is only meant for you to manage your app state transitions.

Recovering from a reconnect

While your call was disconnected, certain transitions could've occurred that need to be addressed. For instance, a conference you were part of now has different participants, or the remaining participants have media changes that you missed.

To mitigate this, we will emit a sequence of events that should transition your app from the pre-disconnected state, to the post-reconnect state. Pay close attention to this as this might be a cause of bugs on asynchronously handled events, as we emit events synchronously and expect you to process events in the order they were emitted.

For example, if you reconnected to a room call where two participants left since you were reconnecting, and another one joined, you will receive two PARTICIPANT_LEFT and one PARTICIPANT_JOINED event after being reconnected.

Being notified about peer reconnections

Aside from the reconnecting call being notified about the reconnect process, we now also offer similar events to all call participants.

• For WebRTC calls, we added REMOTE_DISCONNECTED and REMOTE_RECONNECTED
• For room and application calls, we added PARTICIPANT_DISCONNECTED and PARTICIPANT_RECONNECTED
  • We also added the disconnected field to the Participant class, allowing you to easily populate your UI