6 ms·
WebRTC seems easy when you're creating a proof of concept with-in your own network, once you get into complex situations behind firewalls across the internet it
by figers 6y ago
WebRTC seems easy when you're creating a proof of concept with-in your own network, once you get into complex situations behind firewalls across the internet it's a whole different story.
The article mentioned "This section we will just touch and go about when do you need a TURN server. It is not needed in all situations but a component needed if you have to deal with slightly less straightway use cases." a TURN server is a must in the real world...
- chrisco255 6y agoTrue but there are some open source TURN servers you can use for that.
- mothepro 6y agoNot necessarily, TURN servers should only be required for strict NAT. It seems that 92%* for connections are not behind strict NATs. *https://developers.google.com/talk/libjingle/important_concepts?csw=1#portssocketsconnections https://developers.google.com/talk/libjingle/important_conce...
- FR10 6y agoIn my tests with 10 people 5 needed TURN, ISPs in my country are really something special.
- bkanber 6y agoSTUN fails under symmetric NAT, not strict NAT. That google document makes no citations of that 92% figure, but I assume that's for desktop traffic only. Pretty much all mobile/cellular connections would require TURN too.
- cma 6y agoI haven't found Verizon or AT&T to need TURN, but maybe clients on them would if connecting to each other.
- hardwaresofton 6y agoTrue, but the problem you're mentioning is solved, for the most part. STUN/TURN servers serve this purpose, there are open source ones[0][1] and you can can even use public STUN servers[2] (as you might expect free TURN servers aren't really a thing). Solutions like Jitsi Meet[3], whereby (formerly appear.in)[4] use WebRTC to great success and are fantastic for quick meetings. WebRTC these days is pretty mature and ready for primetime -- TURN servers are a last resort, but they're a small price to pay for something that might be free (to you the service provider) most of the time, if signaling succeeds. [0]: https://github.com/jselbie/stunserver https://github.com/jselbie/stunserver [1]: https://github.com/enobufs/stun https://github.com/enobufs/stun [2]: https://gist.github.com/mondain/b0ec1cf5f60ae726202e https://gist.github.com/mondain/b0ec1cf5f60ae726202e [3]: https://meet.jit.si https://meet.jit.si [4]: https://whereby.com https://whereby.com
- EGreg 6y agoAccording to Tsahi Levent-Levi, some of your biggest customers (corporation wise) are behind firewalls and need TURN. This “last resort” is about 10% he says
- mbzi 6y agoI do a significant amount of work with Hospitals and secure environments (Military, etc). TURN is needed 100% of the time. P2P traffic is not allowed. All IP addresses need to be known and kept static upfront for firewall whitelisting. This means products which help alleviate WebRTC infrastructure such as AWS Kinesis are not allowed (due to how they allocate turn servers with unknown IP addresses) and a company needs to manage their own infrastructure / TURN servers (which allows you to cherry pick where server locations are (HIPAA, country legal for what is streamed)) or accept Twillio's, or their competitors etc, large IP ranges (and don't have server location flexibility / increased commercial and market growth restrictions). Whichever route you go down it is quite an undertaking! P.s. Tsahi Levent-Levi is truly exceptional in this area. I highly recommend reading his blog and training courses: https://bloggeek.me/ https://bloggeek.me/, https://webrtccourse.com/ https://webrtccourse.com/, AND he runs an amazing testing product https://www.testrtc.com https://www.testrtc.com. if you build your own infrastructure testRTC is a must.
- Sean-Der 6y agoI think the most frustrating part is that people don't know what NAT they are behind. I wish WebRTC easily told people the attributes of their NAT. Not sure if it would help production deploys, but would make learning a lot easier. Someone contributed a really cool tool to Pion stun-nat-behavior[0] that I use a lot. It prints out NAT details. It uses the modern/correct details. I see a lot of docs that still use symmetric NAT etc.. RFC 4787 [1] suggests against all that. [0] https://github.com/pion/stun/tree/master/cmd/stun-nat-behaviour https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi... [1] https://tools.ietf.org/html/rfc4787#section-3 https://tools.ietf.org/html/rfc4787#section-3
- j1elo 6y agoThere is also pystun in pip, a comparatively old tool so it is probably much less sophisticated than newer options, but still nice to know about: https://pypi.org/project/pystun/ https://pypi.org/project/pystun/
- cool-RR 6y agoAnd a wrong usage of "touch and go" to boot.
- snemvalts 6y agofor proof of concepts, twilio video was really nice, everything webrtc is abstracted away. built a demo with it in 2 weeks for a potential pivot.
- telesilla 6y agoXirsys and Twilio offer affordable plug-and-play TURN/STUN options, I can recommend them both.
- kodablah 6y agoAfter hand-rolling my own setups and working with a few libraries, I have found https://mediasoup.org/ https://mediasoup.org/ v3 to be the easiest library to use that still gives me the freedom to work with the architecture I want. This of course you're not using WebRTC for its p2p capabilities and are willing to scale via SFUs which is a common approach these days.
- dougwbrunton 6y agomediasoup has a remarkably well considered API and architecture.