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

It was not possible to establish direct connection with the other peer #87

Open
zhouchaoyuan opened this issue Jun 3, 2020 · 11 comments

Comments

@zhouchaoyuan
Copy link

image

@valoricDe
Copy link
Contributor

Which steps did you take to get the other pc shown?

@heyakyra
Copy link

Same here, just created a room, shared the link.

@valoricDe
Copy link
Contributor

valoricDe commented Aug 11, 2020

I could reproduce when my Android is connected with mobile data.
Most mobile operators have their connected phones behind a NAT which could be the reason that a direct connection is not possible. If you connect your phone to a Café /any WLAN it should work

@heyakyra
Copy link

Doesn't that mean the app does not work as described? I didn't see anything noting that on the website, it only says you can create a room to share with users on other networks

@valoricDe
Copy link
Contributor

valoricDe commented Aug 12, 2020

I was curious (I'm no maintainer by the way) and read a bit more about and it could be that the mobile provider does not support websocket connections but then the app should fall back to long lived http requests. Don't know if the app does that.
I could also be that a so called TURN server is needed to get around this problem. shrug

@szimek
Copy link
Owner

szimek commented Aug 12, 2020

The way WebRTC works is that in some cases (e.g. if both peers are behind a NAT) it might be not possible to create peer-to-peer connection. WebRTC has a way around it, but it requires using a relay server called TURN (Traversal Using Relay NAT) and, if available, all traffic (still encrypted) goes through this external relay server.

The problem is that TURN servers cost money and this app doesn't bring any. Right now it's really cheap to run it, as the only cost is basically the domain and occasionally a few $ for Firebase.

Maybe I'll add a link in this error message that provides more info.

@valoricDe
Copy link
Contributor

Maybe we can add an open turn server? https://gist.github.com/sagivo/3a4b2f2c7ac6e1b5267c2f1f59ac6c6b

@szimek
Copy link
Owner

szimek commented Aug 12, 2020

I really would prefer not to use someone else's "open" TURN servers - first of all there's no way for me to check if they are actually ok with it, I have no certainty that these servers don't do something fishy with the relayed data and they could turn them off at any time.

@valoricDe
Copy link
Contributor

I would guess that the owner is probably aware that his relay is used by others but yes that's an argument.
The server can not do something fishy as the data is encrypted, or? And if they turn it off it will not work as it does right now too. So nothing lost.
On the other hand who want's to send a big amount of data over mobile data anyway. Wifi should be prefered

@tejasvi
Copy link

tejasvi commented Feb 18, 2021

Alas.

@sebbes333
Copy link

The way WebRTC works is that in some cases (e.g. if both peers are behind a NAT) it might be not possible to create peer-to-peer connection. WebRTC has a way around it, but it requires using a relay server called TURN (Traversal Using Relay NAT) and, if available, all traffic (still encrypted) goes through this external relay server.

About the NAT problem.
There are a technique called "NAT Punchthrough" or "Nat Hole Punching", I don't know the exact details, I have just read about it some day ago, but I found this:
Tool: https://github.com/samyk/pwnat
Wiki article: https://en.wikipedia.org/wiki/Hole_punching_(networking)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants