3 ms·

Seems to me, they really missed out on naming the project "Turner" as it's really more about the TURN part than the rest. Essentially, they are making creative

by xg15 4y ago

Seems to me, they really missed out on naming the project "Turner" as it's really more about the TURN part than the rest. Essentially, they are making creative use of TURN servers as reverse proxies. My understanding of the whole thing is as follows: WebRTC was originally designed for direct P2P connections between browsers - and ICE was a grab-bag of strategies to get around NATs and firewalls. One "strategy" was TURN, which was essentially "give up and relay the peers through a 3rd party server". At some point, people started to (ab)use WebRTC for traditional client/server media streaming. Browsers don't care if the other peer sits in a data center. You can ignore most of ICE in that scenario, as you have full control over one peer (the media server) and therefore can ensure it is reachable - in particular, you don't need STUN or TURN servers to make it work. However, much of the design is still assuming P2P, so it doesn't play well with Kubernetes which is all designed for client/server. The trick is now that they expose a special TURN server which can act as a unified point of entry into the Kubernetes cluster and make the whole infrastructure much more usable in a Kubernetes context.

rg0now 4y ago
<Spoiler alert: I'm one of the authors behind STUNner> Wow, this is a perfect summary, thanks! In fact, must better than what we could ever come up with, nice! Indeed, the idea is to reuse the STUN/TURN protocol suite (note that under the hood the TURN protocol is just an extension to STUN, hence the name STUNner) in order to ingest WebRTC traffic into Kubernetes in a browser-compliant way. ICE is not (necessarily) a concern for STUNner: ICE is just a negotiation protocol for WebRTC clients and servers to arrive to a common understanding of the addresses and ports used to exchange media, and STUNner is the dataplane that makes that communication happen. And that's maybe the main point here: STUNner is just the dataplane and we still lack a nice control plane. STUNner is already quite usable on its own (but you may need a bit of a reading and manual configuration to make it work), just like how you can use a manually configured Envoy to implement a simpler ingress gateway but of course using it via Istio or Gloo is so much more convenient! So the next step will be to expose STUNner to the Kubernetes control plane wrapped in the Kubernetes Gateway API. We plan this for the next STUNner release, so bear with us! Or better yet, come and join us, we wan use all help!

by xg15 4y ago

rg0now 4y ago

<Spoiler alert: I'm one of the authors behind STUNner> Wow, this is a perfect summary, thanks! In fact, must better than what we could ever come up with, nice! Indeed, the idea is to reuse the STUN/TURN protocol suite (note that under the hood the TURN protocol is just an extension to STUN, hence the name STUNner) in order to ingest WebRTC traffic into Kubernetes in a browser-compliant way. ICE is not (necessarily) a concern for STUNner: ICE is just a negotiation protocol for WebRTC clients and servers to arrive to a common understanding of the addresses and ports used to exchange media, and STUNner is the dataplane that makes that communication happen. And that's maybe the main point here: STUNner is just the dataplane and we still lack a nice control plane. STUNner is already quite usable on its own (but you may need a bit of a reading and manual configuration to make it work), just like how you can use a manually configured Envoy to implement a simpler ingress gateway but of course using it via Istio or Gloo is so much more convenient! So the next step will be to expose STUNner to the Kubernetes control plane wrapped in the Kubernetes Gateway API. We plan this for the next STUNner release, so bear with us! Or better yet, come and join us, we wan use all help!