1623863 - join.me meetings do not share video across conference

Status: RESOLVED INVALID

(Web Compatibility :: Desktop, defect, P3)

Description

[Cristian Fogel, QA [:cfogel]]

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.

Comment 1

[Dan Minor [:dminor]]

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.

Comment 2

[Byron Campen [:bwc]]

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.

Comment 3

[Byron Campen [:bwc]]

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.

Comment 4

[Byron Campen [:bwc]]

DTLS has failed. Maybe this is bug 1623511?

Comment 5

[Byron Campen [:bwc]]

Attachment: dtls_failure_filtered.pcapng

Comment 6

[Byron Campen [:bwc]]

Attachment: dtls_success_filtered.pcapng

Comment 7

[Byron Campen [:bwc]]

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.

Comment 8

[Byron Campen [:bwc]]

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...

Comment 9

[Byron Campen [:bwc]]

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.

Comment 10

[Cristian Fogel, QA [:cfogel]]

@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

Comment 11

[Byron Campen [:bwc]]

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

Comment 12

[Byron Campen [:bwc]]

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).

Comment 13

[Byron Campen [:bwc]]

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

Comment 14

[Adam Stevenson [:adamopenweb]]

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

Comment 15

[Adam Stevenson [:adamopenweb]]

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.

Comment 16

[Negritas Sergiu]

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.

Comment 17

[Adam Stevenson [:adamopenweb]]

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

Comment 18

[Adam Stevenson [:adamopenweb]]

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

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

Comment 19

[Cristian Fogel, QA [:cfogel]]

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.

Comment 20

[Byron Campen [:bwc]]

(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.

Comment 21

[Firefox Bug Husbandry Bot]

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.)

Comment 22

[Julien Cristau [:jcristau]]

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

Comment 23

[Bodea Daniel [:danibodea]]

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?

Comment 24

[Bodea Daniel [:danibodea]]

Logged: 1641210.

Comment 25

[Oana Arbuzov [:oanaarbuzov]]

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?

Comment 26

[Cristian Fogel, QA [:cfogel]]

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!