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

RESOLVED WORKSFORME

Status

P1
normal
Rank:
10
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: standard8, Unassigned)

Tracking

unspecified
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bug])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
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.
Flags: needinfo?(mozilla-support)

Updated

4 years ago
Rank: 10
Flags: firefox-backlog+
Priority: -- → P1
Whiteboard: [bug]

Comment 2

4 years ago
Which browser channel are you using? Also, please send the session ids.
Flags: needinfo?(standard8)
(Reporter)

Comment 3

4 years ago
(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.
Flags: needinfo?(standard8)
(Reporter)

Comment 4

3 years ago
Created attachment 8626286 [details]
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.
Flags: needinfo?(mozilla-support)
(Reporter)

Comment 5

3 years ago
Created attachment 8626288 [details]
Chrome ice/stun log

Hopefully this is the right log for Chrome.
(Reporter)

Comment 6

3 years ago
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.
Flags: needinfo?(rjesup)
Flags: needinfo?(docfaraday)

Comment 7

3 years ago
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

3 years ago
I've tried reproducing this with no luck. Not sure what it was you saw here.
Flags: needinfo?(docfaraday)
(Reporter)

Comment 9

3 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(rjesup)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.