For AI agents: see the complete documentation index at /llms.txt.
Connection status management
Updated
Test network quality and adjust audio and video settings to optimize channel quality
Supported platforms: Web, Android, iOS, macOS, Windows, Unreal Engine, Electron, Flutter, React Native, Unity, and Unreal Blueprint.
In real-time audio and video implementations, the connection state between the app and Agora SDRTN® changes as the client joins or leaves the channel. The connection may also be interrupted due to network or authentication issues.
This page describes the various channel connection states, reasons for state changes, and how to handle these changes to better manage your users and troubleshoot network faults.
Understand the tech
The following figure shows the various connection states and how the connection state changes between a user joining and leaving a channel:
Disconnection and reconnection
During the communication process, if the user is disconnected due to network problems, the SDK automatically enables the disconnection and reconnection mechanism. The following figure shows the callbacks received by the local user UID1 and the remote user UID2 when:
- A local user joins the channel
- A network exception occurs
- The connection is interrupted
- The user rejoins the channel
The following platform-specific timelines explain the reconnection sequence in detail.
In the diagram:
-
T0: The Video SDK receives a
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(CONNECTING, CONNECTING)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(CONNECTED, JOIN_SUCCESS)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(RECONNECTING, INTERRUPTED)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(RECONNECTING, INTERRUPTED),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(RECONNECTING, INTERRUPTED), the SDK stops retrying.UID1receives theonConnectionStateChanged(FAILED, JOIN_FAILED)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying.UID1receives theonConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying.UID1receives theonConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
joinChannelByTokenrequest fromUID1. -
T1: After 200 ms of calling
joinChannelByToken,UID1joins the channel. At the same time,UID1receivesconnectionChangedToState(Connecting, Connecting)callback. After successfully joining the channel,UID1receivesconnectionChangedToState(Connected, JoinSuccess)anddidJoinChannelcallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives adidJoinedOfUidcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theconnectionChangedToState(Reconnecting, Interrupted)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingconnectionChangedToState(Reconnecting, Interrupted),UID1receives thertcEngineConnectionDidLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives thedidOfflineOfUidcallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingconnectionChangedToState(Reconnecting, Interrupted), the SDK stops retrying.UID1receives theconnectionChangedToState(Failed, JoinFailed)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
joinChannelByTokenrequest fromUID1. -
T1: After 200 ms of calling
joinChannelByToken,UID1joins the channel. At the same time,UID1receivesconnectionChangedToState(Connecting, Connecting)callback. After successfully joining the channel,UID1receivesconnectionChangedToState(Connected, JoinSuccess)anddidJoinChannelcallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives adidJoinedOfUidcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theconnectionChangedToState(Reconnecting, Interrupted)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingconnectionChangedToState(Reconnecting, Interrupted),UID1receives thertcEngineConnectionDidLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives thedidOfflineOfUidcallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingconnectionChangedToState(Reconnecting, Interrupted), the SDK stops retrying.UID1receives theconnectionChangedToState(Failed, JoinFailed)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(connectionStateConnecting, connectionChangedConnecting)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(connectionStateConnected, connectionChangedJoinSuccess)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(connectionStateReconnecting, connectionChangedInterrupted), the SDK stops retrying.UID1receives theonConnectionStateChanged(connectionStateFailed, connectionChangedJoinFailed)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
JoinChannelrequest fromUID1. -
T1: After 200 ms of calling
JoinChannel,UID1joins the channel. At the same time,UID1receivesOnConnectionStateChanged(CONNECTION_STATE_CONNECTING, CONNECTION_CHANGED_CONNECTING)callback. After successfully joining the channel,UID1receivesOnConnectionStateChanged(CONNECTION_STATE_CONNECTING, CONNECTION_CHANGED_JOIN_SUCCESS)andOnJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aOnUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theOnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingOnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED),UID1receives theOnConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingOnConnectionStateChanged(CONNECTION_STATE_RECONNECTING, CONNECTION_CHANGED_INTERRUPTED), the SDK stops retrying.UID1receives theOnConnectionStateChanged(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
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(CONNECTING, CONNECTING)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(CONNECTED, JOIN_SUCCESS)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(RECONNCTING, INTERRUPTED)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(RECONNCTING, INTERRUPTED),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying.UID1receives theonConnectionStateChanged(FAILED, JOIN_FAILED)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
Client.joinrequest fromUID1. -
T1:
UID1successfully joins the channel.UID1receivesAgoraRTCClient.on("connection-state-change")callback reporting "CONNECTING" during joining channel and "CONNECTED" after joining. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aAgoraRTCClient.on("user-joined")callback. -
T3: At some point
UID 1callsAgoraRTCClient.publishto publish the local track. -
T4:
UID 2receives theAgoraRTCClient.on("user-published")callback indicating thatUID 1has published the track.UID 2can subscribe toUID 1's track by callingAgoraRTCClient.subscribemethod. -
T5: If the
UID 1network 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 1for 10 consecutive seconds, the server determines thatUID 1no longer publishes audio/video, andUID 2will receiveAgoraRTCClient.on("user-unpublished")callback. -
T8: If the Agora server does not receive a heartbeat packet from
UID 1for 20 consecutive seconds, the server determines thatUID 1is offline, andUID 2will receive theAgoraRTCClient.on("user-left")callback. -
T9: After successfully re-establishing the connection,
UID 1receives theAgoraRTCClient.on("connection-state-change")callback reporting as "CONNECTED". -
T10:
UID 2receives theAgoraRTCClient.on("user-joined")callback again.
In the diagram:
-
T0: The Video SDK receives a
joinChannelrequest fromUID1. -
T1: After 200 ms of calling
joinChannel,UID1joins the channel. At the same time,UID1receivesonConnectionStateChanged(CONNECTING, CONNECTING)callback. After successfully joining the channel,UID1receivesonConnectionStateChanged(CONNECTED, JOIN_SUCCESS)andonJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aonUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theonConnectionStateChanged(RECONNCTING, INTERRUPTED)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingonConnectionStateChanged(RECONNCTING, INTERRUPTED),UID1receives theonConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theonUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingonConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying.UID1receives theonConnectionStateChanged(FAILED, JOIN_FAILED)callback and the user must exit and then rejoin the channel.
In the diagram:
-
T0: The Video SDK receives a
JoinChannelrequest fromUID1. -
T1: After 200 ms of calling
JoinChannel,UID1joins the channel. At the same time,UID1receivesFOnConnectionStateChanged(CONNECTING, CONNECTING)callback. After successfully joining the channel,UID1receivesFOnConnectionStateChanged(CONNECTED, JOIN_SUCCESS)andFOnJoinChannelSuccesscallbacks. -
T2: Due to the transmission delay between networks,
UID2observes a delay of about 100 milliseconds forUID1to join the channel, and at this pointUID2receives aFOnUserJoinedcallback. -
T3: When
UID1client's connection deteriorates due to a network issue or some other reason, the Video SDK automatically tries to rejoin the channel. -
T4: If
UID1does not receive any data from the server for 4 consecutive seconds,UID1receives theFOnConnectionStateChanged(RECONNCTING, INTERRUPTED)callback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T5: If
UID1does not receive any data from the server for 10 consecutive seconds after receivingFOnConnectionStateChanged(RECONNCTING, INTERRUPTED),UID1receives theFOnConnectionLostcallback. Meanwhile, the Video SDK continues to try to rejoin the channel. -
T6: If
UID2does not receive any data fromUID1for 20 consecutive seconds, the Video SDK determines thatUID1is offline. SoUID2receives theFOnUserOfflinecallback. -
T7: If
UID1fails to rejoin the channel for 20 consecutive minutes after receivingFOnConnectionStateChanged(RECONNCTING, INTERRUPTED), the SDK stops retrying.UID1receives theFOnConnectionStateChanged(FAILED, JOIN_FAILED)callback and the user must exit and then rejoin the channel.
Prerequisites
Ensure that you have implemented the SDK quickstart project.
Implement connection status management
Reference
This section contains content that completes the information on this page, or points you to documentation that explains other aspects to this product.
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | CONNECTING (0): The app is trying to join the Agora channel. |
| Connected | JOIN_SUCCESS (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | Connecting (0): The app is trying to join the Agora channel. |
| Connected | JoinSuccess (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | Connecting (0): The app is trying to join the Agora channel. |
| Connected | JoinSuccess (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannelByToken. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the didJoinChannel callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannelByToken to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | Connecting (0): The app is trying to join the Agora channel. |
| Connected | JoinSuccess (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannelByToken. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the didJoinChannel callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannelByToken to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | Connecting (0): The app is trying to join the Agora channel. |
| Connected | JoinSuccess (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | Connecting (0): The app is trying to join the Agora channel. |
| Connected | JoinSuccess (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling JoinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the OnJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call LeaveChannel to leave the current channel, and then call JoinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | CONNECTING (0): The app is trying to join the Agora channel. |
| Connected | JOIN_SUCCESS (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | CONNECTING (0): The app is trying to join the Agora channel. |
| Connected | JOIN_SUCCESS (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| DISCONNECTED | Connection disconnected. The SDK will not automatically reconnect while in this state. This state indicates that the user is in one of the following stages:
|
| CONNECTING | Joining. The instantaneous state after calling join. |
| CONNECTED | Occurs after the app has successfully joined the channel. At this point the user can publish or subscribe to the audio and video in the channel. |
| RECONNECTING | Occurs when the connection is interrupted due to a network disconnection or switch. The SDK automatically tries to reconnect after an interruption. |
| DISCONNECTING | Disconnecting. This is the state when leave is called. |
API reference
Connection states
The app may have the following connection states before joining, during a session, and after leaving a channel:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling joinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the onJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call leaveChannel to leave the current channel, and then call joinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | CONNECTING (0): The app is trying to join the Agora channel. |
| Connected | JOIN_SUCCESS (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|
API reference
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:
| Connection state | Description |
|---|---|
| Disconnected | Initial connection state. Usually occurs:
|
| Connecting | The transient state after calling JoinChannel. |
| Connected | Occurs after the app successfully joins a channel. The SDK also triggers the FOnJoinChannelSuccess callback to report that the local client has joined the channel. At this point, the user can publish or subscribe to the audio and video in the channel. |
| Reconnecting | Occurs when the connection is interrupted. The SDK automatically tries to reconnect after an interruption.
|
| Failed | Connection failed. Occurs when the SDK is unable to join a channel for 20 minutes and stops attempting to reconnect to the channel. In this case, call LeaveChannel to leave the current channel, and then call JoinChannel to join the channel again. |
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:
| Connection state | Description and troubleshooting guide |
|---|---|
| Disconnected |
|
| Connecting | CONNECTING (0): The app is trying to join the Agora channel. |
| Connected | JOIN_SUCCESS (1): The app has successfully joined the channel. |
| Reconnecting |
|
| Failed |
|