Skip to main content

Does Agora have reconnection mechanisms?

The Agora SDK has reconnection mechanisms when a user drops offline or a process gets killed.This page shows the connection state mechanism of the Agora SDK under these circumstances.

This article does not apply to the Agora RTC Web SDK.

User drops offline

The Agora SDK adds the onConnectionStateChanged or connectionStateChangedToState callback in v2.3.2. This callback reports the current network connection state and reasons to any state change.

Before v2.3.2

The following diagram shows the callbacks received by the apps of UID 1 and UID 2 during which UID 1 joins the channel, experiences a network exception, loses connection, and rejoins the channel.

Where:

  • T0 = 0 s: The SDK receives the joinChannel or joinChannelByToken request from the app of UID 1.
  • T1 ≈ T0 + 200 ms: 200 ms after calling the joinChannel or joinChannelByToken method, the app of UID 1 joins the channel and receives the onJoinChannelSuccess or didJoinChannel callback.
  • T2 ≈ T1 + 100 ms: Due to network latency, the app of UID 2 detects UID 1 100 ms after the latter joins the channel. UID 2 receives the onUserJoined or didJoinedOfUid callback.
  • T3: The uplink network condition of UID 1 deteriorates. The SDK automatically tries rejoining the channel.
  • T4 = T3 + 4 s: If the app of UID 1 fails to receive any data from the server in 4 seconds, it receives the onConnectionInterrupted or rtcEngineConnectionDidInterrupted callback; meanwhile the SDK continues to try rejoining the channel.
  • T5 = T3 + 10 s: If the app of UID 1 fails to receive any data from the server in 10 seconds, it receives the onConnectionLost or rtcEngineConnectionDidLost callback; meanwhile the SDK continue to try rejoining the channel.
  • T6 = T3 + 20 s: If the app of UID 2 fails to receive any data from UID 1 in 20 seconds, the SDK decides that UID 1 is offline. The app of UID 2 receives the onUserOffline or didOfflineOfUid callback.
  • T7: If the app of UID 1 successfully rejoins the channel, it receives the onRejoinChannelSuccess or didRejoinChannel callback.
  • T8 ≈ T7 + 100ms: 100 ms after the app of UID 1 successfully rejoins the channel, the app of UID 2 receives the onUserJoined or didJoinOfUid callback, which means that UID 1 is online again.

v2.3.2 and Later

The following diagram shows the callbacks received by the apps of UID 1 and UID 2 during which UID 1 joins the channel, experiences a network exception, loses connection, and eventually fails to rejoin the channel.

Where:

  • T0 = 0 s: The SDK receives the joinChannel or joinChannelByToken request from the app of UID 1.
  • T1 ≈ T0 + 200 ms: 200 ms after calling the joinChannel or joinChannelByToken method, the app of UID 1 joins the channel. During the process, the app of UID 1 also receives the onConnectionStateChanged(CONNECTION_STATE_CONNECTING, CONNECTION_CHANGED_CONNECTING) or connectionChangedToState(AgoraConnectionStateConnecting, AgoraConnectionChangedConnecting) callback. When successfully joining the channel, app of UID 1 receives the onConnectionStateChanged(CONNECTION_STATE_CONNECTED, CONNECTION_CHANGED_JOIN_SUCCESS) or connectionChangedToState(AgoraConnectionStateConnected, AgoraConnectionChangedJoinSuccess) and onJoinChannelSuccess or didJoinChannel callbacks.
  • T2 ≈ T1 + 100 ms: Due to network latency, the app of UID 2 detects UID 1 100 ms after the latter joins the channel. UID 2 receives the onUserJoined or didJoinedOfUid callback.
  • T3: The uplink network condition of UID 1 deteriorates. The SDK automatically tries rejoining the channel.
  • T4 = T3 + 4 s: If the app of UID 1 fails to receive any data from the server in 4 seconds, it receives the onConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED) or connectionChangedToState(AgoraConnectionStateReconnecting, AgoraConnectionChangedInterrupted) callback; meanwhile the SDK continues to try rejoining the channel.
  • T5 = T4 + 10 s: If the app of UID 1 fails to receive any data from the server in 10 seconds after receiving onConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED) or connectionChangedToState(AgoraConnectionStateReconnecting, AgoraConnectionChangedInterrupted), it receives the onConnectionLost or rtcEngineConnectionDidLost callback; meanwhile the SDK continue to try rejoining the channel.
  • T6 = T3 + 20 s: If the app of UID 2 fails to receive any data from UID 1 in 20 seconds, the SDK decides that UID 1 is offline. The app of UID 2 receives the onUserOffline or didOfflineOfUid callback.
  • T7 = T4 + 20 min : If the app of UID 1 fails to rejoin the channel in 20 minutes after receiving onConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED) or connectionChangedToState(AgoraConnectionStateReconnecting, AgoraConnectionChangedInterrupted), the SDK stops trying. The app of UID 1 receives the onConnectionStateChanged(CONNECTION_STATE_FAILED, CONNECTION_CHANGED_JOIN_FAILED) or connectionChangedToState(AgoraConnectionStateFailed, AgoraConnectionChangedJoinFailed) callback. UID 1 needs to leave the channel and call the joinChannel or joinChannelByToken method to join the channel.
  • If UID 2 is a Web client, the behaviors of the Web app are as follows:
    • When UID 1 joins and rejoins the channel, UID 2 receives the client.on("stream-added") callback.
    • If UID 2 does not receive any data from UID 1 in 10 seconds, UID 2 receives the client.on("stream-removed") callback.
    • If the server does not receive any data from UID 1 in 3 minutes, UID 2 receives the client.on("peer-leave") callback.
  • Users can call leaveChannel to stop the retires at any time during the SDK reconnection process.

Process Gets Killed

This scenario involves the following situations:

  • Enables or disables VoIP mode.
  • The process gets killed.
  • Closes a web page.

Suppose UID 1 and UID 2 are in the same channel. When the process of user A gets killed:

  • If UID 1 is in iOS or macOS: UID 1 calls the leaveChannel method and UID 2 receives a callback:

    • Android, Windows, or Linux: UID 2 receives the onUserOffline callback.
    • iOS or macOS: UID 2 receives the didOfflineOfUid callback.
    • The Web: UID 2 receives the client.on("peer-leave") callback.
  • If UID 1 is in Android, Windows, or Linux and user B uses the Native SDK:

    • If UID 1 does not restart the app and rejoin the original channel within 20 seconds, UID 2 receives a callback:

    • Android, Windows, or Linux: UID 2 receives the onUserOffline callback.

    • iOS or macOS: UID 2 receives the didOfflineOfUid callback.

    • If UID 1 restarts the app and rejoins the original channel within 20 seconds, UID 2 does not receive any callback function.

  • If UID 1 is in Android, Windows, or Linux and UID 2 uses the Web SDK:

    • If UID 1 does not restart the app and rejoin the original channel within 10 seconds, UID 2 receives the client.on("stream-removed") callback.
    • If UID 1 restarts the app and rejoins the original channel, UID 2 does not receive any callback.
  • For the Web SDK, killing a process is equivalent to a user dropping offline.

  • If UID 1 is the last user in the channel, the server destroys the channel in 10 seconds.

Page Content