Support for Auth Secret authentication instead of username/password about stunner

[rg0now]

Migration from coturn to STUNner is absolutely possible, but keep in mind that the operational model of coturn is completely different from that of STUNner: coturn provides NAT-traversal for clients and media servers located anywhere on the Internet, while STUNner is used to ingest clients' media traffic into a Kubernetes cluster and route it to the media servers that are deployed into the very same cluster as STUNner, see more on this here.

That being said, STUNner is a perfect substitute for coturn as long as you understand the operational implications of this (for a starter, you will have to deploy it into the host-namespace just like coturn, a model that we absolutely do not recommend). Maybe itis time to revisit your operational model, instead of just going with a blind coturn->STUNner migration? Consider these questions: do you have media servers? how do you host them? why not hosting them behind STUNner, in the same cluster and benefit from the Kubernetes goodies for both the gateway and the media servers?

As per authentication, STUNner fully supports the coturn's use-auth-secret mode, see here.

[francoisminaud]

Thank you for your fast reply.

That leaves me with even more questions as I do not understand all the implications.

We are running a SaaS in Kubernetes. Not sure about the media server to be honest.
That software is a whiteboard where people can add images, notes, text etc... More than one person can browse the same whiteboard. Thanks to WebRTC it can allow users to follow the other persons mouse movement, this is what we use WebRTC/Coturn fore, nothing more.

We have a separate VM that is running Coturn and exposing some Public IP needed for the client connection.

As I'm not the developer of said part and just helping with the infrastructure I cannot provide much more details. All I know is that hosting it on Kubernetes instead of some separate VM would ease the maintainance and observability greatly.

[rg0now]

This seems like a perfect use case for STUNner: if I understand correctly you want to route WebRTC media traffic between clients and the whiteboard-servers (which play the same role as the media servers in the "conventional" WebRTC videoconferencing setup) in a Kubernetes compliant way, and meanwhile provide NAT-traversal to the clients. You can deploy STUNner in the media-plane deployment model using asymmetric ICE mode to support this. We actually have a desktop streaming tutorial with neko that provides something similar to your use case, maybe it's a good idea to take a look.

[francoisminaud]

This indeed looks very similar to the use case you described.
I'll have a look at the documentation and the tutorial video.
I'm wondering if from a client point of view, switching from Coturn to STUNner is transparent as all we provide is "Host", and the "Token". From a Service perspective it seems like we need to expose publicly port 3478 on both UDP and TCP so that is something we can do. For air-gapped networks this should also work as long as the advertised IP address is reachable from the client I believe.

Thanks for your help, will try to provide feedback and we're going to tryout STUNner!

[rg0now]

There shouldn't be any difference from the client's perspective: as long as the client-stack is a standard WebRTC implementation (any major browser, libwebrtc, pion/webrtc, etc) you should be OK. We don't use anything nonstandard or custom: for the client STUNner looks just like any ordinary TURN server.

Closing this for now, feel free to reopen if anything comes up. Or drop by at the Discord, happy to answer your questions there in more detail.