<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!

<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!