The fact is that you can't easily do the last part without a central server.

There might be some public or semi-public servers for this kind of thing available somewhere, or the alternative that I played with a few years ago was to compress and base64 encode the connection information into a string, and allow users to share the link with friends via whatever method they want, and that can then be expanded client side and used to establish the connection. (Or something like qr codes I've also seen used)

Sadly I never finished that project, so I don't really have any code to show you, but in theory it should work okay.

> base64 encode the connection information into a string

Doesn't work anymore.

Firefox times out the answer offer after very few seconds, which makes sharing the answer offer asynchronously impractical, which effectively killed serverless WebRTC and in turn killed any interest I had on it (for my side projects I mostly do serverless web apps, as in real serverless, not lambda functions).

Ouch! That really sucks...

Is there a ticket number or blog post or something I can research to learn a bit more about the reasoning behind this change with them?

No ticket that I know of. It's mentioned in https://blog.mozilla.org/webrtc/ice-disconnected-not/

> So every 5 seconds Firefox (version >= 49) sends another binding request no matter if the ICE transport is in use or not, and it expects the other side to reply with a binding response. If it hasn’t received a binding response for 6 consecutive binding requests, in other words no reply within the last 30 seconds, it will give up and mark the transport as failed. This results in switching the ICE connection state to ‘failed‘ and stop sending any packets over that transport.

Zero-config peer to peer is basically impossible without central servers or some large populated list of long-term seed nodes which are basically central servers.

The central servers don't have to do much, but they need to exist so new nodes on random IPs can find each other. The Internet has no native service discovery bus.

Could I avoid requiring a central server, and still use webrtc, if the two peers I want to connect are in the same lan?

Yes: https://github.com/LucasVanDongen/WebRTC-Local-Loop-iOS

Based on: https://webrtc.github.io/samples/src/content/peerconnection/...

You will need to know where the other peer lives. Which is why they expect you to have a discovery service. But typing in local IP's should work for internal networks. The hardest part is getting through NAT and firewalls and that's not a problem on your own LAN.

I think this is possible, but I'm not sure about the details. I think their IPs need to be obtained somehow though. I don't think you can use things like mDNS from web pages without a plugin.

would ip guessing work? 192.168.. … ?

It would flood the network with probes and take quite a while.

Maybe embedding nmap with the electron app to search for active bodes, then probeing. Requires some C or C++ knowledge though.

can't electron js do local pings?

You still ultimately need some channel to set up that initial P2P connection. This allows the peers to share the IP addresses at which they’re accessible, as well as the formats and codecs they each support.

There’s nothing to stop you doing this through broadcast messages on a local network, though I’m not aware of any way that could be done from within a browser. You could extract the SDP and ICE messages from the browser environment and handle that in Node though, if you were using Electron or something.

Thanks everyone, what I essentially want to do is link a phone (my app) with a laptop (running a decent browser) by showing a QR code on the latter, and establish a data channel (not voice or video).

I mean if everyone already has a way to contact their friends (discord) and say "hey let's play this game together", sharing that link does away with the need for a coordination server. But there's still the need for at least a server, even if it's just one of the clients that knows how to take charge (like Minecraft).

The link could just be encoded information that gives the hosts details for everyone else to connect to.

Yeah, I skipped over a lot of the details, but you would need someone to choose to be a "host" (at least in terms of a "host" for the connection signaling stuff), but you can also implicitly make it the person who created the link safely.

If everybody is behind NATs (without uPnP privileges), nobody can be the "host" for connection-signalling purposes.

There are public ICE/STUN servers that can facilitate NAT-punching, google even hosts one. But that's not the aspect that I thought the root comment was talking about, but more the aspect of "A is hosting a room called 'stuff', and B and C want to browse the list of rooms and connect to it".

>The fact is that you can't easily do the last part without a central server.

Looks up DHT use.

DHT is a fantastic system, but it's not easy by any means, and it still needs some "important" nodes to help bootstrap the system.

WebRTC requires some sort of external communication channel to exchange information about how to set up the connection. (Often referred to as signaling messages).

Disclaimer: Google employee, work on the WebRTC team.

Grandparent:

After getting frustrated with all the other WebRTC libraries over the last 4 years, I finally wrote our own ( https://github.com/amark/gun/blob/master/lib/webrtc.js ) which is capable of using a set of decentralized DHT relay-peers in GUN for signaling - and once peers are already on WebRTC, they can signal (daisy-chain "DAM" as we call it) to other WebRTC peers via WebRTC!

Meaning, you don't/won't have to run any servers!!! Ping us on our chatroom if you want the list of DHT peers.

Parent:

Chuck! Sounds like you'd be a very useful person to know. Me, Feross, etc., plenty others have been requesting additional API/protocol access over the last 4 years (some of which FireFox is adding in libdweb extension!). Any chance we could connect and chat? Ping me at [email protected] ?

Would it be a problem to keep a list of DHT peers in the git repo?

Good idea. I need to get approval they are OK with their peers being publicly listed (easy DDoS potential, we don't have code yet to [but working on it] mitigate it).

I'll start one with just mine, and then others can PR to opt-in. You want to join?

Awesome, thanks.

I'm not actually using WebRTC (or GUN) yet, but I hope to for a project relatively soon and the possibility of not requiring a STUN/ICE server is very enticing to me.

If you need to request more APIs, you should try to talk about your usecase to the WebRTC working group using the users mailing list ( https://groups.google.com/forum/#!forum/discuss-webrtc ). Depending on the question, you may also ask on the spec Github project ( https://github.com/w3c/webrtc-pc ).

Source: Google employee, in the WebRTC WG.

You will need some sort of signal transport for sending ICE negotiation data in JSON. Because the two peers need to know how to coordinate how to connect to each other before actually connecting. It can be a websocket server, REST API, email, QR codes, carrier pigeon, etc.

Also in general, I highly recommend webrtc-adapter.

You need a STUN/TURN server, that's just how the cookie crumbles unfortunately. Blame NAT :)

I used this dockerized coturn server successfully:

https://github.com/strukturag/docker-webrtc-turnserver

There are probably some problems with this idea, but why not just use a popular social network or similar as the lobby? For example, if there is a twitter feed "@MyWebRTCLobby" that everyone follows, clients could just @ a tweet at it with current contact details.

If random Twitter users send @mentions to "@mywebrtclobby" then no other users will likely see these tweets unless they already follow each of the various Twitter users sending the @mentions.

However if you connected @mywebRTClobby with https://GroupTweet.com you could configure things so that any @mentions (from authorized users or anyone) would be converted into actual tweets from the @mywebRTClobby account so that all followers would actually see those tweets/contact details.

Haha I don't use Twitter so I'm not surprised I got something wrong... thanks for fixing that bug.

It used to be the case you could see all @mentions someone received, but alas not anymore.

Iirc there are some free servers you can use provided by Google and/or twilio.

Edit: STUN is free, Turn is not. Been a while since I worked with those.

For my game, I wrote a simple UDP to WebRTC datachannel proxy in NodeJS, suing node-electron, webrtc-electron and SimplePeer. My proxy only works downstream, with the upstream signalling using websockets. I'm going to move over to an all WebRTC architecture, however.

https://www.emergencevector.com

Interesting, i am working on a realtime action game and currently implemented multiplayer via websockets including authorative server, client side predicition and server reconciliation which works failry well but based on the nature of TCP, i still sometimes get some visible stutter in the movement. I guess with WebRTC you can handle things more like traditional UDP? What are your experiences vs Websockets? Did you write how you did it somewhere? Would be very interesting

I got really big stutter with head of line blocking on TCP. You can make things better by conspiring to send only 1 packet messages of about 512 bytes or less, and not too often.

You can register for an account on my server. WebRTC downstream seems to be working at the moment. Be sure to read the instructions, however.

https://www.emergencevector.com

I am thinking of turning my game server into a serverless PaaS offering. I'm open to collaborating on this.

i emailed you regarding this ;)

There's a number of decentralized networks that could send the connection info without a single central server, e.g. torrents or Dat. OTOH the time required to connect to them and pass the info would be quite noticeable.

A single connection-initiation server could be the easiest solution. It won't need to withstand a heavy load.