Omit STUN?

[miloxeon]

Hello!

Unfortunately, the original project seems to be broken (infinite recursion every time), I opened the issue but still have no answer.

Your project is awesome and it works well! I just have one question: how to omit STUN server? Is it really necessary on local connection?

[xem]

Hello! Thanks for the kind words! I also noticed the original project is broken, but I had seen it working earlier. So I just found the old version that used to work, forked it and simplified as much as I could. I've tried to get rid of the STUN server, locally or not, but never found any solution or a good enough documentation on how I could maybe simulate it through something to copy-paste. I may be wrong but I have the feeling that the STUN server's main feature is to tell you what's your IP, which I think JS can't do alone. Local webrtc would also need a (local) IP to exchange data with another device, so the problem is probably quite the same.

[miloxeon]

Does the original thing use STUN? I feel like at this point I need some deeper research of how WebRTC works. But, abstractly speaking, if two devices are on the same local network with no internet access, may we just broadcast to the whole local network and listen to whoever answers us?

Generally, this wouldn't work for large networks, but for local networks oriented solutions like serverless data exchange between your phone and your computer it may be one of the ways of making a connection.

[miloxeon]

For example, there's Gun.js, which broadcasts the whole data model to everyone connected to the network (of course, it's not serverless). Each peer can listen to any key and receive the value associated with that key. Symmetrical key may be used: peers can subscribe to any key and actually receive the data, but the one couldn't decrypt the data if it doesn't have the specific password.

[xem]

Oh, local broadcating sounds interesting indeed. If you find more information about the possibility to do it with WebRTC or JS, I'd be happy to try to demo it

AFAIK the original has always used a STUN server, as you can see in these articles: http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ http://blog.printf.net/articles/2014/07/01/serverless-webrtc-continued/

[miloxeon]

Hey, I've found something!

Consider this: https://stackoverflow.com/a/41711747 I can't understand this magic now, but the following code

window.RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection;  
var pc = new RTCPeerConnection({iceServers:[]}), 
noop = function(){}; 
pc.createDataChannel("");  
pc.createOffer(pc.setLocalDescription.bind(pc), noop);   
pc.onicecandidate = function(ice) { 
    if(!ice || !ice.candidate || !ice.candidate.candidate)  return;
    var myIP = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
}

is working: I copied and pasted from the StackOverflow to the local file, and got this: 192.168.0.141, it's my actual local IP!

I think this is not completely safe, it seems hacky and may be removed in the future, but for now it works

[xem]

That's crazy! In the comments of the pages I linked above, they say that the STUN server also provides the port on which you listen to webrtc data (if I understand correctly that's mandatory too, unless WebRTC allows an arbitrary hardcoded port like 12345)

[miloxeon]

Explicitly set ports are not necessary because there may exist an algorithm which may set the port in smarter way than hardcode does. For example, there may exist a conventional algorithm which sets the port as the last three digits of IP plus zero, thus, for 192.168.0.141 port will be 1410. That's just an idea, the algorithm like this could set the 'next' port if the desired port isn't avaiable, for example, it could just go from 0001 to 9999 and stop when it'll become possible to create a connection

[xem]

Sure, hardcoded or computed shouldn't be a problem. I'm just wondering if we can make a WebRTC link by setting a custom port like that, instead of reading it from the STUN server...?

[miloxeon]

As I understand it, STUN is needed when WebRTC connection happens via internet, through NATs, servers, proxys and other things, just for figuring out the final and exact IP addresses. But for LAN it seems like the STUN isn't necessary, because peer's IP will be the same for everyone in specified local network

[miloxeon]

I'm sure it'll work, if only I had more time to play with it... the Stack Overflow code is a mess, it may be way more simple.