Connection status management

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(CONNECTING, CONNECTING) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(CONNECTED, JOIN_SUCCESS) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(RECONNECTING, INTERRUPTED) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(RECONNECTING, INTERRUPTED), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(RECONNECTING, INTERRUPTED), the SDK stops retrying. UID1 receives the onConnectionStateChanged(FAILED, JOIN_FAILED) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying. UID1 receives the onConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying. UID1 receives the onConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannelByToken request from UID1.

• T1: After 200 ms of calling joinChannelByToken, UID1 joins the channel. At the same time, UID1 receives connectionChangedToState(Connecting, Connecting) callback. After successfully joining the channel, UID1 receives connectionChangedToState(Connected, JoinSuccess) and didJoinChannel callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a didJoinedOfUid callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the connectionChangedToState(Reconnecting, Interrupted) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving connectionChangedToState(Reconnecting, Interrupted), UID1 receives the rtcEngineConnectionDidLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the didOfflineOfUid callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving connectionChangedToState(Reconnecting, Interrupted), the SDK stops retrying. UID1 receives the connectionChangedToState(Failed, JoinFailed) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannelByToken request from UID1.

• T1: After 200 ms of calling joinChannelByToken, UID1 joins the channel. At the same time, UID1 receives connectionChangedToState(Connecting, Connecting) callback. After successfully joining the channel, UID1 receives connectionChangedToState(Connected, JoinSuccess) and didJoinChannel callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a didJoinedOfUid callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the connectionChangedToState(Reconnecting, Interrupted) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving connectionChangedToState(Reconnecting, Interrupted), UID1 receives the rtcEngineConnectionDidLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the didOfflineOfUid callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving connectionChangedToState(Reconnecting, Interrupted), the SDK stops retrying. UID1 receives the connectionChangedToState(Failed, JoinFailed) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying. UID1 receives the onConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a JoinChannel request from UID1.

• T1: After 200 ms of calling JoinChannel, UID1 joins the channel. At the same time, UID1 receives OnConnectionStateChanged(CONNECTION_STATE_CONNECTING, CONNECTION_CHANGED_CONNECTING) callback. After successfully joining the channel, UID1 receives OnConnectionStateChanged(CONNECTION_STATE_CONNECTING, CONNECTION_CHANGED_JOIN_SUCCESS) and OnJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a OnUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the OnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving OnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED), UID1 receives the OnConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving OnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED), the SDK stops retrying. UID1 receives the OnConnectionStateChanged(CONNECTION_STATE_FAILED, CONNECTION_CHANGED_JOIN_FAILED) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(CONNECTING, CONNECTING) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(CONNECTED, JOIN_SUCCESS) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(RECONNCTING, INTERRUPTED) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(RECONNCTING, INTERRUPTED), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying. UID1 receives the onConnectionStateChanged(FAILED, JOIN_FAILED) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a Client.join request from UID1.

• T1: UID1 successfully joins the channel. UID1 receives AgoraRTCClient.on("connection-state-change") callback reporting "CONNECTING" during joining channel and "CONNECTED" after joining.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a AgoraRTCClient.on("user-joined") callback.

• T3: At some point UID 1 calls AgoraRTCClient.publish to publish the local track.

• T4: UID 2 receives the AgoraRTCClient.on("user-published") callback indicating that UID 1 has published the track. UID 2 can subscribe to UID 1's track by calling AgoraRTCClient.subscribe method.

• T5: If the UID 1 network is interrupted during the communication process, the SDK automatically opens the disconnection and reconnection mechanism.

• T6: The SDK triggers AgoraRTCClient.on("connection-state-change") callback to report "RECONNECTING" during automatic reconnection.

• T7: If the Agora server does not receive the audio/video packet from UID 1 for 10 consecutive seconds, the server determines that UID 1 no longer publishes audio/video, and UID 2 will receive AgoraRTCClient.on("user-unpublished") callback.

• T8: If the Agora server does not receive a heartbeat packet from UID 1 for 20 consecutive seconds, the server determines that UID 1 is offline, and UID 2 will receive the AgoraRTCClient.on("user-left") callback.

• T9: After successfully re-establishing the connection, UID 1 receives the AgoraRTCClient.on("connection-state-change") callback reporting as "CONNECTED".

• T10: UID 2 receives the AgoraRTCClient.on("user-joined") callback again.

In the diagram:

• T0: The Video SDK receives a joinChannel request from UID1.

• T1: After 200 ms of calling joinChannel, UID1 joins the channel. At the same time, UID1 receives onConnectionStateChanged(CONNECTING, CONNECTING) callback. After successfully joining the channel, UID1 receives onConnectionStateChanged(CONNECTED, JOIN_SUCCESS) and onJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a onUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the onConnectionStateChanged(RECONNCTING, INTERRUPTED) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving onConnectionStateChanged(RECONNCTING, INTERRUPTED), UID1 receives the onConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the onUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving onConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying. UID1 receives the onConnectionStateChanged(FAILED, JOIN_FAILED) callback and the user must exit and then rejoin the channel.

In the diagram:

• T0: The Video SDK receives a JoinChannel request from UID1.

• T1: After 200 ms of calling JoinChannel, UID1 joins the channel. At the same time, UID1 receives FOnConnectionStateChanged(CONNECTING, CONNECTING) callback. After successfully joining the channel, UID1 receives FOnConnectionStateChanged(CONNECTED, JOIN_SUCCESS) and FOnJoinChannelSuccess callbacks.

• T2: Due to the transmission delay between networks, UID2 observes a delay of about 100 milliseconds for UID1 to join the channel, and at this point UID2 receives a FOnUserJoined callback.

• T3: When UID1 client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel.

• T4: If UID1 does not receive any data from the server for 4 consecutive seconds, UID1 receives the FOnConnectionStateChanged(RECONNCTING, INTERRUPTED) callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T5: If UID1 does not receive any data from the server for 10 consecutive seconds after receiving FOnConnectionStateChanged(RECONNCTING, INTERRUPTED), UID1 receives the FOnConnectionLost callback. Meanwhile, the Video SDK continues to try to rejoin the channel.

• T6: If UID2 does not receive any data from UID1 for 20 consecutive seconds, the Video SDK determines that UID1 is offline. So UID2 receives the FOnUserOffline callback.

• T7: If UID1 fails to rejoin the channel for 20 consecutive minutes after receiving FOnConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying. UID1 receives the FOnConnectionStateChanged(FAILED, JOIN_FAILED) callback and the user must exit and then rejoin the channel.

When the connection state changes, Video SDK sends an onConnectionStateChanged callback. This section shows you how to use the onConnectionStateChanged callback to monitor changes in the connection state.

Use the following code in your IRtcEngineEventHandler to log the connection state changes and the reason for the state change.

public void onConnectionStateChanged(int state, int reason) {
    super.onConnectionStateChanged(state, reason);
    Log.i(TAG, "onConnectionStateChanged->" + ", state->" + state
        + ", reason->" + reason);
}

override fun onConnectionStateChanged(state: Int, reason: Int) {
    super.onConnectionStateChanged(state, reason)
    Log.i(TAG, "onConnectionStateChanged->, state->$state, reason->$reason")
}

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK triggers the onConnectionStateChanged callback. This section describes how to use the onConnectionStateChanged callback to monitor changes in a channel's connection state.

In your project, open the file with the Agora Engine event handler, and add the onConnectionStateChanged callback to the IRtcEngineEventHandler instance initialization.

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK triggers the onConnectionStateChanged callback. This section describes how to use the onConnectionStateChanged callback to monitor changes in a channel's connection state.

In your project, open the file with the Agora Engine event handler, and add the onConnectionStateChanged callback to the RtcEngineEventHandler instance initialization.

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK sends a connectionChangedToState callback. This section describes how to use the connectionChangedToState callback to monitor changes in a channel's connection state.

In your project, open the file with AgoraRtcEngineDelegate and copy the following code into the AgoraRtcEngineDelegate initialization process:

func rtcEngine(_ engine: AgoraRtcEngineKit, connectionChangedTo state: AgoraConnectionState, reason: AgoraConnectionChangedReason) {
    LogUtils.log(message: "Connection state changed: \(state) \(reason)", level: .info)
}

The code logs the connection state changes and the reason for the state change. The reason parameter in connectionChangedToState explains why the connection state changed and helps you troubleshoot your network.

When the connection status changes, Video SDK sends a connectionChangedToState callback. This section describes how to use the connectionChangedToState callback to monitor changes in a channel's connection state.

In your project, open the file with AgoraRtcEngineDelegate and copy the following code into the AgoraRtcEngineDelegate initialization process:

func rtcEngine(_ engine: AgoraRtcEngineKit, connectionChangedTo state: AgoraConnectionState, reason: AgoraConnectionChangedReason) {
    LogUtils.log(message: "Connection state changed: \(state) \(reason)", level: .info)
}

The code logs the connection state changes and the reason for the state change. The reason parameter in connectionChangedToState explains why the connection state changed and helps you troubleshoot your network.

When the connection status changes, Video SDK triggers the onConnectionStateChanged callback. This section describes how to use the onConnectionStateChanged callback to monitor changes in a channel's connection state.

In your project, open the file with the Agora Engine event handler, and add the onConnectionStateChanged callback to the IRtcEngineEventHandler instance initialization.

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK triggers the OnConnectionStateChanged callback. This section describes how to use the OnConnectionStateChanged callback to monitor changes in a channel's connection state.

Use the following code in your IRtcEngineEventHandler to log the connection state changes and the reason for the state change.

internal class UserEventHandler : IRtcEngineEventHandler
{
    ...
    // Callback for channel connection status change
    public override void OnConnectionStateChanged(RtcConnection connection, CONNECTION_STATE_TYPE state,
        CONNECTION_CHANGED_REASON_TYPE reason)
    {
        _helloVideoTokenAgora._state = state;
    }
}

The state parameter in OnConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK triggers the onConnectionStateChanged callback. This section describes how to use the onConnectionStateChanged callback to monitor changes in a channel's connection state.

In your project, open the file with the Agora Engine event handler, and add the onConnectionStateChanged callback to the IRtcEngineEventHandler instance initialization.

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK triggers the onConnectionStateChanged callback. This section describes how to use the onConnectionStateChanged callback to monitor changes in a channel's connection state.

In your project, open the file with the Agora Engine event handler, and add the onConnectionStateChanged callback to the IRtcEngineEventHandler instance initialization.

The state parameter in onConnectionStateChanged reports the current connection state. The reason parameter indicates why the connection state changed to help you troubleshoot your network. See State description and troubleshooting.

When the connection status changes, Video SDK sends a FOnConnectionStateChanged callback. This section describes how to use the FOnConnectionStateChanged callback to monitor changes in a channel's connection state.

1. Create the OnConnectionStateChanged callback function and configure the following parameters:

   Connection state	Description	Parameter description
   state	Enum	The current network connection status.
   reason	Enum	The reason why the network connection state changed. See State description and troubleshooting.

2. Add a listener for the OnConnectionStateChanged callback as shown below:

   

3. When the channel connection state changes and the OnConnectionStateChanged callback is triggered, it prints information about the state of the monitored network connection. You can read the current connection state and the reason for the state change from the log which helps you troubleshoot the network.

   

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in connectionChangedToState describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• rtcEngine(_:connectionChangedTo:reason:)
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in connectionChangedToState describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• rtcEngine(_:connectionChangedTo:reason:)
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in OnConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• OnConnectionStateChanged
• GetConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged
• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

API reference

• AgoraRTCClient.on("connection-state-change")

• AgoraRTCClient.on("user-joined")

• AgoraRTCClient.on("user-left")

• AgoraRTCClient.on("user-published")

• AgoraRTCClient.on("user-unpublished")

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in onConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• onConnectionStateChanged

• getConnectionState

Connection states

The app may have the following connection states before joining, during a session, and after leaving a channel:

The app may have the following connection states before joining, during a session, and after leaving a channel:

State description and troubleshooting

The reason parameter in FOnConnectionStateChanged describes the reason for the connection state change.

The following table maps the relationships between different connection states and the causes of state change, as well as how to handle the situation when network outages occur:

API reference

• FOnConnectionStateChanged
• GetConnectionState