Hello,
Could you help me understand the new reconnecting behaviour that is released in v1.9.0? I've got the following questions in mind:
1) How long does twilio-video wait before emitting _disconnected_ event after it enters into the _reconnecting_ state? Is it determined by iceServersTimeout setting?
2) Do all the subscriptions and publications resume working if reconnection attempt succeeds? Do I need do any kind of health checks programmatically?
3) >twilio-video.js does not yet support reconnecting the signaling connection; however, when we do, we will use this same event.
What does that mean in practice? What is the impact of not reconnecting the signaling connection?
Thanks
- How long does twilio-video wait before emitting _disconnected_ event after it enters into the _reconnecting_ state? Is it determined by
iceServersTimeoutsetting?
twilio-video only transitions to _disconnected_ if the signaling connection to the Room is broken, times out, etc. In cases where the signaling connection is fine, but the media connection needs to be reestablished, twilio-video enters the _reconnecting_ state. twilio-video could be in the _reconnecting_ state for an indefinite amount of time.
The _reconnecting_ state is independent of iceServersTimeout. iceServersTimeout only determines how long twilio-video is willing to wait to fetch ICE servers from Twilio's configuration service before connecting to a Room. Furthermore, abortOnIceServersTimeout controls whether or not twilio-video should even continue connecting to the Room if fetching ICE servers timed out, since on some networks, it just will not work without TURN over TLS on port 443.
- Do all the subscriptions and publications resume working if reconnection attempt succeeds? Do I need do any kind of health checks programmatically?
If twilio-video emits _reconnected_ (i.e., it transitions from _reconnecting_ back to _connected_), then this means all publications and subscriptions should be working again, at least in a Group Room. In a P2P Room, since it is a mesh topology, _reconnected_ is emitted once at least on of the RTCPeerConnections in the mesh is repaired.
- > twilio-video.js does not yet support reconnecting the signaling connection; however, when we do, we will use this same event.
What does that mean in practice? What is the impact of not reconnecting the signaling connection?
If you look at Twilio's iOS and Android Video SDKs, they support full network handoff. For example, you could start using the iOS or Android Video SDK on WiFi. In this case, your signaling connection and media connection are established over WiFi. Then, you could disable (or lose) WiFi and fallback to LTE. In this case, new signaling and media connections would be established over LTE.
For twilio-video.js, we can't handoff the signaling connection yet. This means, in practice, there are fewer scenarios where we can recover from a partial loss of internet connectivity鈥攖he only scenarios we can currently recover are ones where the media connection has broken but the signaling connection remains in tact.
Thanks @markandrus, I did some reading on signalling and media connections and it all makes sense now 馃憤
Most helpful comment
twilio-video only transitions to _disconnected_ if the signaling connection to the Room is broken, times out, etc. In cases where the signaling connection is fine, but the media connection needs to be reestablished, twilio-video enters the _reconnecting_ state. twilio-video could be in the _reconnecting_ state for an indefinite amount of time.
The _reconnecting_ state is independent of
iceServersTimeout.iceServersTimeoutonly determines how long twilio-video is willing to wait to fetch ICE servers from Twilio's configuration service before connecting to a Room. Furthermore,abortOnIceServersTimeoutcontrols whether or not twilio-video should even continue connecting to the Room if fetching ICE servers timed out, since on some networks, it just will not work without TURN over TLS on port 443.If twilio-video emits _reconnected_ (i.e., it transitions from _reconnecting_ back to _connected_), then this means all publications and subscriptions should be working again, at least in a Group Room. In a P2P Room, since it is a mesh topology, _reconnected_ is emitted once at least on of the RTCPeerConnections in the mesh is repaired.
If you look at Twilio's iOS and Android Video SDKs, they support full network handoff. For example, you could start using the iOS or Android Video SDK on WiFi. In this case, your signaling connection and media connection are established over WiFi. Then, you could disable (or lose) WiFi and fallback to LTE. In this case, new signaling and media connections would be established over LTE.
For twilio-video.js, we can't handoff the signaling connection yet. This means, in practice, there are fewer scenarios where we can recover from a partial loss of internet connectivity鈥攖he only scenarios we can currently recover are ones where the media connection has broken but the signaling connection remains in tact.