Products / Plugins:Video Call / Voice Call / ZEGO Live
Platform / Framework:iOS / Android / macOS / Windows
Last updated:2022-03-12 10:43
The ZEGO SDK does support this feature.
A fast reconnection for temporary disconnection refers to a mechanism to ensure the users can be quickly reconnected to a room or recover a stream publishing/playing operation after a temporary disconnection occurred due to some exceptions.
This document introduces the handling logic of the SDK when reconnecting to a room, recovering a stream publishing/playing operation, and the methods to handle unexpected disconnections.
After logging in to a room, the SDK automatically tries to reconnect when you are disconnected from the room due to network errors.
To receive the updates on the current user's room connection status in real time and handle the event callbacks related to room status, you can listen for the onRoomStateUpdate
callback.
For other users in the room, to receive updates on the status of specified users in the room, call the onRoomUserUpdate
method. (Remember to set the isUserNotify
property of the room configuration parameter config
to true
when you log in to a room in advance.)
Status | Enumerated value | Implication |
---|---|---|
ZegoRoomStateDisconnected |
0 |
Disconnected state, which appears before you log in to a room or after you log out from a room. This state also appears if a steady-state exception occurs during the login operation, for example, the AppID and Token are incorrect, or the local end user is kicked out when the same username is used to log in to another rooms. |
ZegoRoomStateConnecting |
1 |
Connecting state, which appears when you perform the room login operation successfully. (Generally, the user can set a corresponding UI to indicate the current state.) This state also appears when the SDK automatically tries to reconnect when users disconnected from a room due to network errors. |
ZegoRoomStateConnected |
2 |
Connected state, which appears when you log in to a room successfully. In this state, users can receive the event notifications related to room users and streams. |
The following diagram illustrates the callback for updates on the room connection status:
Among the diagram:
loginRoom
calling request.loginRoom
method is called, the client can join in to a room. And in the process of joining the room, the ClientA receives the onRoomStateUpdate(roomID, ZegoRoomStateConnecting, 0, extendedData)
and the onRoomStateUpdate(roomID, ZegoRoomStateConnected, 0, extendedData)
callbacks, which notifies that it is connecting to the room and room is connected successfully respectively.onRoomUserUpdate(roomID, ZegoUpdateTypeAdd, userList)
callback about 100ms later and is notified that the ClientA has joined the room.onRoomStateUpdate(roomID, ZegoRoomStateConnecting, 0, extendedData)
callback and is notified that the reconnection attempt is ongoing.onRoomUserUpdate(roomID, ZegoUpdateTypeDelete, userList)
callback and is notified that the ClientA is disconnected/offline.onRoomStateUpdate(roomID, ZegoRoomStateConnected, 0, extendedData)
and is notified that the reconnection attempt is successful.onRoomUserUpdate(roomID, ZegoUpdateTypeAdd, userList)
callback about 100ms later and is notified that the ClientA has reconnected successfully.onRoomStateUpdate(roomID, ZegoRoomStateDisconnected, 0, extendedData)
callback and is notified the it is disconnected.During a stream publishing process, the SDK automatically tries to recover the operation when the streaming publishing failed due to network errors.
If all nodes have been tried, but the stream publishing still failed, the SDK sends out notification through the callback onPublisherStateUpdate
.
In this callback, when the state
is ZegoPublisherStateNoPublish
and the errorCode
is not 0
, indicates the SDK's recovery attempt has failed. The error can be determined based on the value of the errorCode
, for details, see Error codes.
At this point, we recommend waiting a few seconds (3-5 seconds) to start publishing the stream again, rather than getting stuck in an infinite loop by trying again and again.
Status | Enumerated value | Implication |
---|---|---|
ZegoPublisherStateNoPublish |
0 |
This state indicates no streams published, which appears before a stream publishing. This state also appears if a steady-state exception occurs during the stream publishing operation, for example, the AppID and Token are incorrect, or the stream with the same ID is already publishied by another user. |
ZegoPublisherStatePublishRequesting |
1 |
This state indicates a stream publishing is being requested, which appears when you perform the stream publishing operation successfully. (Generally, the user can set a corresponding UI to indicate the current state.) This state also appears when the SDK automatically tries to recover the operation when stream publishing failed due to network errors. |
ZegoPublisherStatePublishing |
2 |
This state indicates a stream is being published, which appears when a stream is published successfully. In this state, users can communicate normally. |
During a stream playing process, the SDK automatically tries to recover the operation when the streaming playing failed due to network errors.
If all nodes have been tried, but the stream playing still failed, the SDK sends out notification through the callback onPlayerStateUpdate
.
In this callback, when the state
is ZegoPlayerStateNoPlay
and the errorCode
is not 0
, indicates the SDK's recovery attempt has failed. The error can be determined based on the value of the errorCode
, for details, see Error codes.
At this point, we recommend waiting a few seconds (3-5 seconds) to start playing the stream again, rather than getting stuck in an infinite loop by trying again and again.
Status | Enumerated value | Implication |
---|---|---|
ZegoPlayerStateNoPlay |
0 |
This state indicates no streams played, which appears before a stream playing. This state also appears if a steady-state exception occurs during the stream playing operation, for example, the AppID and Token are incorrect. |
ZegoPlayerStatePlayRequesting |
1 |
This state indicates a stream playing is being requested, which appears when you perform the stream playing operation successfully. (Generally, the user can set a corresponding UI to indicate the current state.) This state also appears when the SDK automatically tries to recover the operation when stream playing failed due to network errors. |
ZegoPlayerStatePlaying |
2 |
This state indicates a stream is being played, which appears when a stream is played successfully. In this state, users can communicate normally. |
setEngineConfig
method and set the parameter "room_retry_time=xxxx"
(unit: second).setEngineConfig
method and set the parameter "av_retry_time=xxxx"
(unit: second).When a user in a room disconnects, other users in the room receive a notification through callback 90 seconds later by default. To change the default value, contact the ZEGO technical support.
The SDK detects the network status of the host in real time. When the host is disconnected, it automatically stops the stream publishing. If the network recovers within 300 seconds, the SDK automatically publishes streams again.
When the host is disconnected:
onRoomStreamUpdate
, and audience in the room can call the stopPlayingStream
method to stop playing the streams.onRoomStreamUpdate
, and audience in the room can call the startPlayingStream
to start playing the streams again.After the host is disconnected, the audience will fail to play the streams in the room, meanwhile, the SDK will automatically try to recover the stream playing.
If the SDK fails to recover the operation, audience will be notified through the callback onPlayerStateUpdate
(when the errorCode
is not 0, we recommend audience to try playing the stream after a while, for example, 3 seconds).
During the SDK recovery attempt, the audience can do the following accordingly:
onRoomStreamUpdate
, and audience in the room can call the stopPlayingStream
method to stop playing the streams.onRoomStreamUpdate
, and audience in the room can call the startPlayingStream
to start playing the streams again.To avoid invalid stream playing, the audience needs to stop stream playing once they are notified that existing streams in the room stop.
When the host end gets crash, and does not restart the live streaming for a while, the audience will be notified that existing streams in the room stop through the callback onRoomStreamUpdate
.
For this circumstance, the audience can do the following accordingly:
onRoomStreamUpdate
, and audience need to call the stopPlayingStream
method to stop playing the streams.onRoomStreamUpdate
, and audience need to call the startPlayingStream
to start playing the streams again.onRoomStreamUpdate
, and audience need to call the stopPlayingStream
method to stop playing the streams.If the host end gets recovered and published streams successfully: The audience will be notified that new streams are published to the room through the callback onRoomStreamUpdate
, and audience can call the startPlayingStream
to start playing the streams again.