Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Discord Call RTC connecting #611

Closed
1 task done
MartinRJDagleish opened this issue Sep 11, 2022 · 14 comments
Closed
1 task done

Bug: Discord Call RTC connecting #611

MartinRJDagleish opened this issue Sep 11, 2022 · 14 comments
Labels
bug 🪲 Something isn't working

Comments

@MartinRJDagleish
Copy link

Avoid duplicates

  • I have searched the issues tracker for a bug report similar to mine, in vain

Ferdium Version

6.1.1-nightly.10

What Operating System are you using?

Ubuntu

Operating System Version

Ubuntu 22.04 LTS

What arch are you using?

x64

Last Known Working Ferdium version

No response

Expected Behavior

I wanted to use Ferdium for a Discord call, but although my sound seems to work the call never connects.

Actual Behavior

I am stuck at RTC connecting and I cannot hear the other person.

Steps to reproduce

  1. Go to Discord
  2. Call a friend / join a server voice chat
  3. RTC connecting

Debug link

https://debug.ferdium.org/af669fe2-2706-4c80-af9a-67dad22af547

Screenshots

Screenshot from 2022-09-11 22-12-21

Additional information

No response

@MartinRJDagleish MartinRJDagleish added the bug 🪲 Something isn't working label Sep 11, 2022
@Axel29
Copy link

Axel29 commented Sep 12, 2022

Same issue here, I've had this bug for a week now.

@Yuki2DX
Copy link

Yuki2DX commented Sep 14, 2022

Same bug here. Discord App works fine, but the Ferdium recipe isn't working now :\

@SpecialAro
Copy link
Member

SpecialAro commented Sep 16, 2022

Hello 😁 thank you for logging this issue.

Are you by any chance using the latest nightly and not the stable version?

If so (using the nightly), then it is probably due to the new feature for WebRTC IP handling. This was introduced in a nightly version, with the default option to hide the public and private IP and interfaces for WebRTC.

This behavior can be changed in the Privacy section of the Settings menu. Please, if you can, try all options and see what works. Notice that if you change the option you need to perform a full restart of Ferdium (close Ferdium, make sure it is not running and open again).

Disclaimer: be aware that changing that setting can expose your public/private IPs and interfaces to the WebRTC... So make sure you know what you are doing (you can read more about that if you search WebRTC IP leaks).

Let me know the results please 😁

Edit: I can see that you're using the nightly.10 so it is probably due to the new feature. Please try the above steps.

Also, are you building nightly.10 locally? Because it is not published on our repo.

@MartinRJDagleish
Copy link
Author

Hey @SpecialAro,

Thank you. Yes I was using the nightly.10 and your proposed fix did work :) Thank you.

I have switched distros to Manjaro now and I am using the "normal" versions, so this should not be a problem any longer.

@SpecialAro
Copy link
Member

Btw @MartinRJDagleish, which option work out for you?

@vraravam should we change the default value of the WebRTC IP handle to the "default" option (leaking both private and public IP and interfaces)?

When I implemented this, I focused on getting a setting where the user is protected by default (i.e. disabling IP leaks regardless) - but this can also introduce some issues on recipes that depend on WebRTC as seen here.

Maybe we should implement this recipe wise instead (tho I'm not sure it is possible) and change the defaults for some recipes.

@nathanaelhoun nathanaelhoun pinned this issue Sep 22, 2022
@DeN-AlB
Copy link

DeN-AlB commented Sep 23, 2022

Btw @MartinRJDagleish, which option work out for you?

For me, all other 3 settings in v6.2.0 work to be able to join a voice chat in Discord. Only the default setting (Do not expose public or local IPs) is not working. So I choose the 3rd setting (Expose user public or local IPs - only use default route used by http).

@PhlegmaTREEc
Copy link

I just found this and made my discord work again. What is the least bad option to choose? The one that @DeN-AlB did or the second one?

@DeN-AlB
Copy link

DeN-AlB commented Sep 28, 2022

What is the least bad option to choose?

I'm interested in that, too.

@fgurdradee
Copy link

Btw @MartinRJDagleish, which option work out for you?

For me, all other 3 settings in v6.2.0 work to be able to join a voice chat in Discord. Only the default setting (Do not expose public or local IPs) is not working. So I choose the 3rd setting (Expose user public or local IPs - only use default route used by http).

I can confirm that the first 3 options all work. Tested on Linux Mint with deb file and flatpak installation, and Windows. Running 6.2 stable.

2022-09-30_16-23-56

@wennbley
Copy link

I am now getting this issue on 2 of my Macs. I have the latest public build Version: 6.2.0

Changing to any of the WebRTC IP Handling Policy does not work for me!

@fnagel
Copy link

fnagel commented Mar 25, 2023

Tried all three options (on Windows 10) but I was not able to make Discord work. Using Ferdium 6.2.6 nightly 8.

@trendespresso
Copy link

Btw @MartinRJDagleish, which option work out for you?

For me, all other 3 settings in v6.2.0 work to be able to join a voice chat in Discord. Only the default setting (Do not expose public or local IPs) is not working. So I choose the 3rd setting (Expose user public or local IPs - only use default route used by http).

Same! Perhaps if a user adds the Discord app then Ferdium can notify the user about the issue and suggest changing the setting to one less strict?

@dargmuesli
Copy link

@SpecialAro do you have a recommendation for the question

What is the least bad option to choose?

🙏 thank you. If it's not easy to explain, a link to some specification to read ourselves would surely help as well ❤️

@SpecialAro
Copy link
Member

Hi @dargmuesli

I think you have to try and error from the best case (not exposing anything) to the worst case (exposing everything).

Take a look at this issue (the one that triggered the implementation of the WebRTC) #598

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🪲 Something isn't working
Projects
None yet
Development

No branches or pull requests