[davidmnoll]

I recently learned you can do the candidate server exchange without those servers. There was an implementation which used [this](https://github.com/cjb/serverless-webrtc) as a backend and a QR code to do the transfer. I can't seem to find it now. However they were having issues with the QR code reaching its size limit, leading to the question of whether you could break the message into a series of qr codes.

Pretty interesting stuff, I was considering taking a crack at it as part of a project I'm working on.

Edit: [here](https://franklinta.com/2014/10/19/serverless-webrtc-using-qr... the blog post about it

[thdc]

You would still need a STUN server, though there are many public ones out there.

The main idea in removing the signaling server is to somehow transfer the session description between clients e.g. one client scans a qr code that encodes the session description of another or sending session description through some existing chat application and allowing a user to enter it manually instead of having your own server do the transfer over some mechanism.

Also it may be possible to avoid the multiple qr code thing this blog is talking about (qr code per ice candidate) if you just wait for the ice gathering state to be complete then send the session description, though they are correct that the session description in its entirety will most likely exceed the qr code capacity (coincidentally they use LZ compression in an attempt to lower the length, similar to what I tried long ago though I ended up deciding it wasn't worth it).