3 ms·
Tested this a couple of years ago and Chrome prevented WebRTC connections from ever establishing if you're not connected to internet proper (it was doing some l
by capableweb 6y ago
Tested this a couple of years ago and Chrome prevented WebRTC connections from ever establishing if you're not connected to internet proper (it was doing some lookup to a Google domain before trying to actually create the WebRTC connection, even if I had nothing to do with Google, and stopped the attempt if it couldn't connect). Might have changed by now.
- dnautics 6y agoIf memory serves me right it's a security issue, webrtc only allows connections when proper ssl certs exist on the initial brokered handshake, so you would only be able to do this if your lan has some sort of self signed ssl root cert and the cert placed in each machines authoritative cert stash.
- lxgr 6y agoWebRTC doesn't use any public CA certificates to my knowledge. DTLS-SRTP uses self-signed certificates on both sides, with the certificate hashes or key fingerprints being included in the SDP signalling messages. Maybe you're thinking of the "secure origin" requirement? (The page hosting the JS needs to be a "trusted context", i.e. no file:// and no http:// http://)
- dnautics 6y agoI'm referring to the secure origin requirement. Sorry I wasn't clear. Thank you for putting the correct label on it.
- kingosticks 6y agoIf you did need a certificate within your LAN, could you alternatively use Let's Encrypt with a DNS Challenge (if your provider has support)?
- Sean-Der 6y agoThat might have been Google's STUN server? If this was required at one time this is now fixed! getUserMedia requires a secure domain (HTTPS or localhost) so LAN only video calls are kind of a PITA. You can easily do DataChannel only. For dev work I have a signaling server on a Class C address. Just for testing interop on Safari with my Linux box running signaling and WebRTC agent.