search

Hubs-Foundation / hubs

Duck-themed multi-user virtual spaces in WebVR. Built with A-Frame.
https://hubsfoundation.org
Mozilla Public License 2.0
2.13k stars 1.42k forks source link

No Audio in both senses. #3096

Open markfoodyburton opened 3 years ago

markfoodyburton commented 3 years ago

Nobody is able to hear my colleague, any my colleague is unable to hear anybody else in a hubs room. (All other participants can hear each other)

He IS on a company network (and behind a firewall) - we believe this is critical. (It is the enterprise vpn mechanism offered by Microsoft, I dont have any more details than that - his machine is sufficiently locked down that he can not disable it).

He is using Chrome Version 85.0.4183.121 (Official Build) (64-bit) on Windows 64bit 10 Enterprise 1803 In incognito mode In the preferences we tried

1/ With mic/speaker volume set to 100 and all options in their default position

2/ Mic and Speaker volume set to max All options set to "disable"

In all cases, the client neither sends, nor receives any sound.

In all cases, on entering the room, the browser asks for permission to use the microphone, and then the audio test shows sound on the microphone, and clicking the test button plays a sound.

When he enters the room, he hears the greeting chimes

If he chooses an avatar that has mouth animation, we see the animation

For him, his speaker icon in the roster shows audio noise when he's talking. However, no audio is transmitted, and we hear nothing. For other participants, his speaker never moves in the roster, it shows as being unmuted, but no noise.

Likewise, he hears nothing, and the speakers for others never moves.

┆Issue is synchronized with this Jira Task

keianhzo commented 3 years ago

Related to https://github.com/mozilla/hubs/pull/3305 and https://github.com/mozilla/hubs/issues/2643

keianhzo commented 3 years ago

@markfoodyburton For your description it looks like the firewall is probably blocking ports or UDP traffic towards the STUN/TURN servers.

To confirm, you can open the RTC debugging panel (Preferences -> Misc -> RTC panel) and see what's the status of the send/receive transports candidates. If there are no candidates most probably the ICE negotiation failed and even all the setup process of the mic worked there can't be SRTP communication if you can't solve candidates and you won't be able to send/receive any audio/video.

If there are no candidate it probably is related to:

In case the UDP traffic is blocked, you can try switching to TCP as the relay protocol adding the force_tcp=true parameter at the end of the URL.

If the ports are blocked, you can try asking your net admin for allowed port and configure you Hubs instance Dialog ports to use those in case you are using your own instance.

Hope that helped to diagnose the issue.

markfoodyburton commented 3 years ago

We did try the force_tcp=true trick - this seemed to make no difference.

I no longer have the instance to test, but it seemed like hubs on Mozilla didn't suffer a problem, while hubs 'self hosted' on AWS did.

markfoodyburton commented 3 years ago

We can now reproduce this on Hubs

I have a colleague who is behind a company firewall - (rather a large company) - They are also using proxies etc.

He is able to join the room, and visually see things, but no audio is passed in either direction.

Is there anything we can do about this?

Andy-Roger-Kats commented 3 years ago

My team is also using Hubs Cloud through our company VPN and experiencing the same issue as above. We have been testing with a wide variety of user devices and experiencing the issue with no noticeable pattern of device type. All tests have been run in Chrome incognito mode. Below is an image taken from PR: https://github.com/mozilla/hubs/pull/3604 that was merged into the (current) latest hubs-cloud branch, the branch we are testing on. Users, while on VPN see the same sequence of enableChromeAEC messages (seen in the image below). We have seen this occur and the audio recover after a short delay ~10 seconds. With other users we have seen the messages just as below but the audio does not recover. As noted in PR https://github.com/mozilla/hubs/pull/3604 "When the network change from wired to Wi-Fi, the RTCPeerConnection loopback stays disconnected, recreate it after 10s if it didn't get back to connected." Is running through a VPN similar to changing from wired to WiFi during an RTCPeerConnection? I can imagine that a large number of Hubs Cloud users are connecting to rooms through a VPN since it is a great virtual events platform, but still experiencing issues with audio. This issue is blocking us from doing virtual events since we are worried that some users, especially users new to Hubs, will be confused about the experience if the the audio issue happens. -Thanks!

Andy-Roger-Kats commented 3 years ago

If the ports are blocked, you can try asking your net admin for allowed port and configure you Hubs instance Dialog ports to use those in case you are using your own instance.

Hi @keianhzo by "own instance" does that also include Hubs Cloud (that is what I am running)? If so, can you explain how I can configure our Hubs instance Dialog ports to use the ones allowed by a firewall?