Respect++ for what you said about Peerjs. I used those servers myself for testing when I wrote my own TURN client and always felt a little bad about it. But it saved me tons of time before setting up my own. Now I have my own server (though not as well setup as yours -- your guide is good.)
This is a valuable contribution. IMO, the Internet needs more STUN, TURN, and MQTT servers. It's even more valuable if they support as many protocols as possible and have IPv4 / IPv6. For STUN -- running it with two IPs means it can support bind requests which is necessary for testing NAT types.
Oh, thanks that's very kind of you to say. PeerJS is great - it takes a lot of the complexity out of WebRTC and replaces it with a nice, clean API. I think it was an OK decision for them to use Google for their TURN server - really, the best use case for their cloud server is exactly as you described - get your PoC working, and then if you're serious, implement your own
Comments
Respect++ for what you said about Peerjs. I used those servers myself for testing when I wrote my own TURN client and always felt a little bad about it. But it saved me tons of time before setting up my own. Now I have my own server (though not as well setup as yours -- your guide is good.)
This is a valuable contribution. IMO, the Internet needs more STUN, TURN, and MQTT servers. It's even more valuable if they support as many protocols as possible and have IPv4 / IPv6. For STUN -- running it with two IPs means it can support bind requests which is necessary for testing NAT types.
Oh, thanks that's very kind of you to say. PeerJS is great - it takes a lot of the complexity out of WebRTC and replaces it with a nice, clean API. I think it was an OK decision for them to use Google for their TURN server - really, the best use case for their cloud server is exactly as you described - get your PoC working, and then if you're serious, implement your own