1091316 - Call takes several seconds to initiate

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, defect)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

I have tried a number of calls with different people. All take several seconds to initiate - before audio and video are ready. The delay is noticeable and my expectation is that the call should initiate more more quicly.

All calls have been setup by sharing a URL. I think all have been with someone who has not previously used Loop, although subsequent attempts with the same person have been slow as well.

Comment 1

[Mark Banner (:standard8)]

Given your description, I think a lot of this is probably to do with the fact that we're not prompting link-clickers to accept media before initiating the actual call.

Currently they only get prompted when the call has been accepted.

This could cause a longer setup time than expected.

Bug 1073410 is working on solving this by moving the prompt to before the call is initiated.

Comment 2

[Adam Roach [:abr]]

It's hard to tell what the problem might be without Lawrence specifically highlighting which phase of the call he's finding to take longer than he expects. If it's literally the delay between him clicking "accept" and the other person's face showing up (which is what it sounds like), then it's some combination of the delay imposed by the TokBox SDK and infrastructure and the delay of ICE setup. It's likely (although I'd want to gather numbers to verify) that the ICE step is the overwhelming majority of this time. Some of this inherent in ICE itself as defined, and can't be worked around. Some of it could be improved by having STUN and TURN servers closer to users (e.g., by deploying more instances of TokBox's servers).

My proposed path forward here is (a) to have Lawrence clarify very, very clearly which two events he thinks are too far apart in time; (b) generating telemetry that details how long the various steps between these two events take individually; and then (c) improving those steps that appear to comprise the bulk of this delay, within the constraints of the protocols and infrastructure being used.

Lawrence: can you describe the two events that you think are too far apart, time wise?

Comment 3

[Lawrence Mandel [:lmandel] (use needinfo)]

Attachment: loopcall.mov

(In reply to Adam Roach [:abr] from comment #2)
> It's hard to tell what the problem might be without Lawrence specifically
> highlighting which phase of the call he's finding to take longer than he
> expects. 

Sorry for the crappy report. I had told Maire that I'd get more info together today. Here it is...

> If it's literally the delay between him clicking "accept" and the
> other person's face showing up (which is what it sounds like), then it's
> some combination of the delay imposed by the TokBox SDK and infrastructure
> and the delay of ICE setup. It's likely (although I'd want to gather numbers
> to verify) that the ICE step is the overwhelming majority of this time. Some
> of this inherent in ICE itself as defined, and can't be worked around. Some
> of it could be improved by having STUN and TURN servers closer to users
> (e.g., by deploying more instances of TokBox's servers).

It is the delay between clicking accept and other other person's face (video + audio) showing up. (A ~7 second delay to start the call seems like a long time compared to a system like Vidyo.) I tested this today and have attached a video of the delay. I confirmed with Andrew (the face in the video) that most of the delay results from waiting for him to click "share" to allow his camera and mic to be used. In this case I like the suggestion of doing this configuration up front (comment 1). We can also work around this by in the UI with more information about what's happening ("waiting for the other caller to connect") or using a room based approach where new participants join the room when they're ready.

Comment 4

[Adam Roach [:abr]]

Ah, okay. Based on this description, I agree with Mark that the problem will almost certainly go away entirely when the fix for Bug 1073410 lands.

Comment 5

[:shell escalante]

we are still working on gUM work on stand-alone side this sprint.  will reach out to lawrence to validate after land.

Comment 6

[Mark Banner (:standard8)]

Lawrence, can you retry this now?

The fixes for the gUM prompts were deployed end of November/early December, so you shouldn't be notified about any calls/room joins until they have been accepted.

Comment 7

[Lawrence Mandel [:lmandel] (use needinfo)]

UI seems much more responsive now. I think that that problem that I reported as been resolved.

Comment 8

[Mark Banner (:standard8)]

This was fixed by several bugs so marking as WFM.