1173760 - Rooms frequently failing to connect on Google Chrome (subscribe doesn't callback - no remote video stream shown)

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, defect, P1)

Description

[Mark Banner (:standard8)]

I've been testing rooms today on my localhost - a Firefox connecting to a Google Chrome instance locally on my Mac.

Using our current production servers, about 1 in 5 attempts are resulting in no remote video being shown. Using the latest in-tree working code I'm seeing virtually all attempts fail.

I did try this with someone else over the internet about 10 times, and there were no issues, which makes me wonder if its timing related.

STR:

1) General a conversation url in Firefox & leave the conversation open
2) Visit the url in Google Chrome
3) Join the conversation

Expected Results

-> Both Local and Remote Video works fine.

Actual Results

-> Local video is fine (and transmits fine), Remote video is not always received, though sound can be heard for localhost attempts.


More info:

The latest localhost is using the virtual DOM element when subscribing to the remote stream - which is probably why the audio is working, as we're using the virtual element for that currently.

With debugging, I'm seeing that the callback from this.session.subscribe isn't always happening for some reason. It is obviously doing most of the subscribe but not calling the callback.

Comment 1

[Mark Banner (:standard8)]

Is there anything known in TokBox's current issues relating to this? Or do you have hints on what could be looked at?

If you need session ids, I can supply those separately.

Comment 2

[msander]

Which browser channel are you using? Also, please send the session ids.

Comment 3

[Mark Banner (:standard8)]

(In reply to msander from comment #2)
> Which browser channel are you using? Also, please send the session ids.

Firefox Nightly as the link generator, Chrome version 43 as the link clicker.

Comment 4

[Mark Banner (:standard8)]

Attachment: Firefox Stun/ICE log

I've been reproducing the issue consistently on my machine when testing locally.

Here's the ice logs from FF and Chrome.

The issue is with in the Firefox -> Chrome direction, the media is not received by Chrome.

There's no ICE failures raised, nothing comes through.

Comment 5

[Mark Banner (:standard8)]

Attachment: Chrome ice/stun log

Hopefully this is the right log for Chrome.

Comment 6

[Mark Banner (:standard8)]

Can someone from the team take a look at the logs here and see if there's something obvious going on?

I'm concerned this is causing some of the occasional instances of one-way audio that we sometimes hear about.

Comment 7

[Byron Campen [:bwc]]

So ICE is succeeding just fine. From what I can tell we have only one ICE stream, which means we're using bundle too, meaning that we use exactly the same transport for both audio and video. If only audio is failing to work, it is almost certainly not an ICE or transport problem (although I could see it being an SRTP problem or even a bundle demux problem). Let me look into it.

Comment 8

[Byron Campen [:bwc]]

I've tried reproducing this with no luck. Not sure what it was you saw here.

Comment 9

[Mark Banner (:standard8)]

Ok, I can't really reproduce this at the moment either. I'm going to set this as WFM for now. We're adding more instrumentation for this kind of situation, so hopefully we can pick up if there's a real problem somewhere or not.