Firstly - @dmonad, thank you and the community for creating this amazing library! It is an incredible piece of work.
I am experiencing an issue where when using WebRTC, sometimes peers don’t seem to find each other and I am not sure why. It is too sporadic for me to recreate consistently, but I got “lucky” today and ended up in a state where an InCognito window of chrome did not properly connect to the room I had open in my regular window. Didn’t see any errors; had the signaling server hardcoded (to one of the defaults). I logged the provider and the room/password seemed consistent across the non-connected peers.
What’s interesting is that new tabs in that InCognito window would successfully connect to their own “instance” of the room but would not connect to the peers in the regular window. New tabs in the regular window in turn connected to each other but not to the InCognito peers… Here’s the kicker - when I connected to the room from my phone (in cognito on there too), all peers suddenly connected to each other. Now I could see all edits across any of the 3 “users”. When I left the room on my phone, the peers would disconnect from each other once again creating the isolated silos (InCog tab users together, regular tab users together).
I am not sure what to make of this. It seems like something is blocking the peers from discovering each other, but I am not sure why accessing it from another device enables that discovery. I tried using peerOpts to specify a different set of iceServers (Free WebRTC TURN Server - Open Relay Project | Open Relay Project - Free WebRTC TURN Server) but that didn’t make a difference either. It also seems like there is something about the browser instance/profile that could be influencing the connection path (since tabs across the instance connected to each other).
How might I go about troubleshooting this further? Crossing my fingers the problem persists so I can get to the bottom of it
This has been resolved! Info for others that might encounter similar issues:
In reviewing other conversations relating to this topic and doing more research, I learned that WebRTC peers cannot always connect directly (via STUN) and can sometimes require TURN to facilitate the connectivity. It looks like I was on the right track with the iceServers, but I actually made a mistake in how I configured the peerOpts. I accidentally made my object look like peerOpts: { iceServers: [] } instead of peerOpts: { config: { iceServers: [] }}. Once I correct the data structure, the free TURN server I posted above facilitated the traffic properly and made the connection work!
One additional note though, I found this article insightful: https://bloggeek.me/google-free-turn-server/ - and based off of commentary there, I signed up for Xirsys to ensure stability for my project (there are other alternatives available too). Hope this might help someone else out
Oh cool, I didn’t know about Xirsys. Yes, something like this is certainly necessary to provide a reliable service.
There are many pitfalls when using WebRTC. I also found that there is a maximum number of WebRTC connections that a single Browser instance can create. At some point, it was 20 connections in chrome which is easily used up if you have a larger network and multiple tabs open.
Hi @IvanVolons thanks for sharing your findings! I’m running into similar problems as you. I have some questions about your solution.
When using peerOpts.iceServers, does this completely replace the signaling value in the yjs WebrtcProvider?
What is the difference between Xirsys and the open relay turn servers you mentioned in your original message? It seems like they provide similar services.
Adding the option and using the open relay service doesn’t seem to change the behavior based on what I see in my network dev tools (I’m not seeing any network requests to the TURN server)
