Participant disconnect event is fired too late

[matdennoigi]

Hi guys,

We developed a video call app with Twilio. In a call, assume has 2 participants A & B. When device of A be crashed or lost network, after 1 minutes and 13 seconds later, Twilio (on A device) threw "B disconnect" event. How can I make it faster, because our service charge over call duration?

[idelgado]

@matdennoigi We have an issue in our backend infrastructure at the moment, where a timer, that can last up to 120 seconds retains the instance of the participant. We are working through possible solutions to detect and reap participants on abrupt disconnections(crashes, lost network).

I'll update this ticket with the proposal we land on and with an ETA for a fix.

[matdennoigi]

Thank so much! Hope it soon

[moksamedia]

Any update on this?

[aaalaniz]

Hey @moksamedia

Unfortunately, we have no update on the underlying issue caused by the 120 second timer. However, we did release a new Participant REST API that allows developers to disconnect participants. If you have a way to detect a participant abruptly dropping (crash, etc) then you could boot that participant from the room using this new API in your backend service. This is not ideal, but it's somewhat of a workaround until we can resolve the timer issue on our backend.

Thanks!

[Puneet2412]

Any update on this?

[aaalaniz]

Hey @Puneet2412

Unfortunately, there is no update on this issue.

[jitendra-kr]

is there any update

[MattBlack01]

any update on this?

[zackm0571]

Hey @MattBlack01 @jimmylogic No update. With TCMP this issue will improved but we don’t have a timeline for that yet

[taher-mosbah]

Any ETA on a fix or a workaround please ?

[zackm0571]

It's on our roadmap and we're actively working on this. I'll provide an update once it's available.

[aaalaniz]

Hey everyone,

After some runtime with the Video Android 5.x betas, we have now released Video Android 5.0.0. This release contains the following features that relate directly to this issue:

• Global Low Latency (GLL) signaling Servers.
• Faster detection and recovery from connection failures.

In 5.0.0, the client and server use heartbeats to detect broken signaling connections within 15 seconds or less. If a failure is detected, the Participant then has up to 30 seconds to reconnect to the Room before being permanently disconnected. Additionally, the SDK's media monitoring logic has also been modified to disconnect in scenarios where recovery is unlikely. Looking out beyond GA, we would like to introduce a reconnecting state for the RemoteParticipant, and provide events regarding media interruptions for Tracks.

I am closing this issue for now, but we are happy to address any follow up questions and comments.

[RapidoBots]

Has this issue resolved in the latest 2.0.0 version?