Disconnect on poor connection takes 30 seconds to deliver the disconnected event

[paco-spr]

Description

Calling disconnect while on a slow internet connection takes about 30 seconds to disconnect. This causes a problem for our app because we try to derive the UI state from the current connection state. We could fix this ourselves by doing what the Quickstart App is doing and change the UI immediately after calling activeCall.disconnect but we would like to maintain our existing pattern if possible — we are trying to avoid hiding the UI until we have confirmation that the call has been disconnected and audio is no longer being sent.

If it can't be changed it would be helpful to at least have insight into why the Voice SDK behaves this way.

Steps to Reproduce

1. Launch the quick start app on an emulator
2. Set the emulator Network Type to GSM and Signal Strength to Poor
3. Place a call
4. Immediately hit the disconnect button
5. Notice it takes almost 30 seconds before the "disconnect" event is delivered

Code

Reproduces on the Quickstart app as is.

Expected Behavior

The app immediately receives a disconnected event

Actual Behavior

It takes almost 30 seconds to disconnect.

Reproduces How Often

Every time

Twilio Call SID(s)

CAd41bbacb746c97efd82114d1489f2cf6

Logs

N/A

Versions

Current android quickstart

Voice Android SDK

Current android quickstart voice sdk version

OS Version

31

Device Model

Pixel 6 emulator

[afalls-twilio]

@paco-spr This is not surprising... This is expected because of poor network conditions

When you 'disconnect' we send a message to our backed that then sends an acknowledgment response back to you that it was successful. If you simulate poor network conditions with the emulator, it is dropping packets and causing it to retry that communication until it is successful, hence the long delay.

While I did not see a 30 sec delay for the callsid posted, I did see a 14 sec delay between the time it took to send the disconnect message from your client to the time it received the acknowledgement of that disconnect message from the server.

To be specific, your client sent the disconnect message and did not finish receiving the corresponding acknowledgment response message from the server until 14 seconds later.

NOTE: I did see that there was a 4 second delay when the disconnect message was sent from Twilio's servers to a phone carriers backend and the phone carrier sent back an acknowledgment that it disconnected the PSTN call, what happens if you make a call to another Twilio client and not PSTN line ruling out any delays at the phone carriers network?

There was also a minor incident last night that may have added to the delay.

[paco-spr]

@afalls-twilio Unfortunately our backend will reject any client to client communication at the moment.

Regardless though, whats the reason that a network request needs to be sent to disconnect the call? I imagine one does not get sent when the user loses internet entirely, but the call will still drop. Does audio continue to get sent until the disconnect is acknowledged?

When disconnecting would it be possible for the SDK to:

1. Immediately close the open connection and stop sending audio
2. Deliver a disconnected event to the client consumer of the SDK
3. Send disconnect event to the server and wait for the acknowledge

[afalls-twilio]

@paco-spr There are multiple connections to Twilio in an active call, the signaling layer, and the RTP streams used for the VOIP data etc.. Upon receiving a disconnect message, the backend notifies all other services that the call has ended. Furthermore, when its a client->PSTN connection, the disconnect must be forwarded to the phones carrier. Audio is not sent after the disconnect message is sent, it doesn't wait for the acknowledgment.

When a call is dropped due to poor network conditions, the backend keeps it open until a timeout occurs. For obvious reasons we, nor the phone carriers want want to have millions of 'open' connections waiting on timeouts due to VOIP conversations ending.

To answer your question, the general answer is not really. The Twilio backend sits in-between all clients, its not a P2P network, so in order for the other participants to know that a client disconnected, the disconnect message would have to first go the the server then potentially to the other clients, making step 2 impossible.

[paco-spr]

@afalls-twilio Ty for taking the time to provide the insight. I always appreciate how informative and responsive you are. We will make the necessary adjustments on our side then.