szimek
It was not possible to establish direct connection with the other peer
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
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
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
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.
Maybe we can add an open turn server? https://gist.github.com/sagivo/3a4b2f2c7ac6e1b5267c2f1f59ac6c6b
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.
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
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)
