Closed Bug 1623863 Opened 4 years ago Closed 3 years ago

join.me meetings do not share video across conference

Categories

(Web Compatibility :: Site Reports, defect, P3)

Tracking

(firefox-esr68 wontfix, firefox74 wontfix, firefox75 wontfix, firefox76 wontfix, firefox77 wontfix, firefox78 wontfix)

RESOLVED INVALID
Tracking Status
firefox-esr68 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix

People

(Reporter: cfogel, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

Affected versions

  • 74.0, 75.0b5(devEd), 76.0a1 (2020.03.19)

Affected platforms

  • Windows 10, macOS 10.15

Steps to reproduce

  1. Access https://www.join.me/
  2. Create a chat room and share it accross;
  3. Have someone else join the room;
  4. Share your webcam+mic;

Expected result

  • mic + camera is shared, other person can see and hear;

Actual result

  • only audio is shared;
  • video can only bee seen from own camera, stream from the other person is not receieved;

Regression range

  • will check and provide one asap;

Additional notes

  • joining from other browsers(Chrome) does not have this issue;
  • screen share works fine.

Hi Cristian, what was the last version of Firefox for which the camera was working as expected? I'm suspicious that this is a web compatibility problem and not a Firefox bug because screen sharing is working.

Flags: needinfo?(cristian.fogel)
Priority: -- → P3
Has Regression Range: --- → no
Has STR: --- → yes

So join.me is passing {sdpSemantics: "plan-b"}, and using a separate PeerConnection for audio and video. It is possible for something like this to work, but this already looks really bad from a web-compat standpoint.

ICE seems to have worked, and a send track seems to be getting set, but there's no data in that track for some reason.

DTLS has failed. Maybe this is bug 1623511?

So, DTLS fails on the PC that join.me uses for video, but not on the PC that join.me uses for audio. There's a different endpoint for video than there is for audio.

Ok, so it seems that this is probably just bug 1623511, but the changeset on that bug does not re-enable DTLS 1.0 on nightly. I am trying to test this on beta, but join.me seems down at the moment...

Testing this with beta works a little better; video is actually transmitted and received. It is never rendered, however, likely due to some other web-compat bug.

@Dan, last time I used this web-app was about 5 years ago.

In an attempt to find the regression range for this:

  • last good build_date: 2019-04-29
  • first bad build_date: 2019-04-30
  • pushog URL
  • mozregression points to 1546408 from bisected this pushlog
Has Regression Range: no → yes
Flags: needinfo?(cristian.fogel)

Yeah, I don't see how that changeset could be the problem. I'll check later today.

This is almost certainly bug 1531803; one of the things that bug did was stop emitting track ids (in SDP a=msid) based on the id of the send track, because the latest specs have made the track id in a=msid meaningless (and in fact, the latest spec does not use track ids in a=msid at all).

This is a webcompat thing.

join.me needs to do the following:

  1. Support DTLS 1.2 on all of its endpoints
  2. Stop using track ids in a=msid attributes for any purpose. Stream ids in a=msid are still fine, and so is transceiver mid.
  3. Migrate to unified-plan instead of plan-b SDP semantics
Component: WebRTC → Desktop
Product: Core → Web Compatibility

Thanks everyone, I will reach out to them.

The website still shows that Firefox is supported:
https://help.join.me/joinmehelp/s/article/joinme-c-joinme-systemrequirements?language=en_US

Just an update that this bug has reached the right team working on join.me. It is in their backlog to investigate in their next sprint.

Hello this issue is still reproducible on Fx 78.0a1 on Ubuntu 18.04 LTS and on Fx 77.0b2 on Windows 10. I will update the flags accordingly.

Thanks for the info. I've asked if Join.me for an update on this.

So join.me says they have fixed the issue and Firefox video is working again.

Cristian, would you be able to re-test please?

Flags: needinfo?(cristian.fogel)

While crosschecking across builds it appears that with nightly 78.0a1 (2020-05-10) the issue still manifests.

However as far as beta(77.0b3) the issue no longer persists and image is shared between callers.

Flags: needinfo?(cristian.fogel)

(In reply to Cristian Fogel, QA [:cfogel] from comment #19)

While crosschecking across builds it appears that with nightly 78.0a1 (2020-05-10) the issue still manifests.

However as far as beta(77.0b3) the issue no longer persists and image is shared between callers.

This would be consistent with join.me continuing to use an old version of DTLS, since only nightly rejects it right now.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3

Should we call this fixed, or wait until the site update their DTLS version?

Flags: needinfo?(astevenson)

The issue still occurs on Windows and Mac in Nightly 78. The user allows the camera permission-door hanger (2-3 times, for some reason), he (the host) notices that the camera is being shared, but the other participants will not see his camera feed.

This issue above is probably also present on Linux, but it cannot be reproduced because the camera is NOT DETECTED AT ALL for this site, even in Chrome. Reproduced with the latest versions of Nightly v78.0a1 (26-05-2020) and Chrome. Should I log an issue for this?

Initially, I have ONLY succeeded in seeing each other's camera feed on Windows Chrome - MacOS Chrome.
Did not see the other one's camera feed in neither of the following combinations: Windows Nightly - MacOS Chrome, Windows Chrome - MacOS Nightly, Windows Nightly - MacOS Nightly.

Then, I have also tested the Beta77 to confirm comment 20, so Beta works correctly in all combinations, while Nightly78 does not work in either of the combinations.

Cristi, do you know if there's a logged bug for the issue on the Linux platform of not detecting the camera at all? Do you think I should log it considering that it also reproduces on Chrome?

Flags: needinfo?(cristian.fogel)

Logged: 1641210.

Flags: needinfo?(cristian.fogel)
See Also: → 1641210

Join.me meeting can no longer be made from the browser. GoToMeeting app needs to be installed in order to join a meeting.
https://prnt.sc/10p727e

Tested with:
Browser / Version: Firefox Nightly 88.0a1 (2021-03-18)
Operating System: Windows 10 Pro

Cristi can you still reproduce the issue on your side?

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(cristian.fogel)
Resolution: --- → INVALID

Can confirm that the site changed to app requirement.
My old account is no longer on the trial period; trying to create a new one, pushes the user onto the GoToMeeting page and app-download.

Thanks @Oana for the checks!

Flags: needinfo?(cristian.fogel)
Flags: needinfo?(a.stevenson82)
You need to log in before you can comment on or make changes to this bug.