Is it possible to use stunner with Nextcloud - talk?

[jattind]

Specially in Nextcloud talk the turn server settings need to point to a URL and a secret. How do you configure stunner to use a secret instead of usrname/password?

[rg0now]

Hi @jattind, thanks for the question. Short answer: we don't know, we haven't looked into NextCloud Talk yet, but now that you're bringing this up we will put this to the TODO list.

That being said, we'd happy to walk you through integrating STUNner with NextCloud Talk. This usually shouldn't be a massive problem but there may be the occasional bumps along the road.

So far, my quick investigation has led me to believe that either (1) we're lucky and everything should work smoothly or (2) we're not that lucky and we'd a trivial patch in STUNner's TURN authentication handlers to support NextCloud Talk. The problem is that NextCloud Talks seems to default to coturn's use-auth-secret authentication mode that STUNner only partially supports at this moment with the longterm authentication mode.

Here is how to test this out:

• Install NextCloud Talk to Kubernetes. The default Kubernetes manifests should work, but don't forget to remove the hostNetwork: true hack from your media server container template to install your media servers into regular pods and make sure to wrap the pods that act as a media server in your NextCloud Talk distro with a Kubernetes service, call it nextcloud-talk-media-svc for simplicity.
• Install STUNner and set the authentication mode in the GatewayConfig to longterm:

  kubectl apply -f - <<EOF
  apiVersion: stunner.l7mp.io/v1alpha1
  kind: GatewayConfig
  metadata:
    name: stunner-gatewayconfig
    namespace: stunner
  spec:
    authType: longterm
    sharedSecret: <YOUR-SECRET>
  EOF
  

• Open a STUNner Gateway at an arbitrary port and attach a UDPRoute to it that points to the nextcloud-talk-media-svc service as a backend,
• Configure NextCloud Talk to use the above TURN secret for authenticating with STUNner:
  • set the relay transport mode to "TURN only"
  • set the TURN URI to turn:<STUNNER_PUBLIC_ADDRESS>:<STUNNER_PUBLIC_PORT>, the concrete values can be parsed out from stunnerctl output
  • set the TURN secret to <YOUR-SECRET>

This should be enough to direct your Talk clients to talk to the media server via STUNner. Problem is, they may not be able to authenticate. In particular, the client may or may not send a user-id alongside the timestamp in the username option depending on the way NextCloud Talk generates TURN authentication credentials for clients, while STUNner assumes that the username part of the TURN credentials contains only a timestamp but no user id. It is a one-line patch to let STUNner ignore the user id but first we'd need a good indication that this is indeed necessary.

Now start a NextCloud Talk session and look for the authentication success/failure entries in the stunnerd pod's logs. If you see authentication failures with the log message invalid time-windowed username then NextCloud Talk instructs clients to send the user id and we need the STUNner fix, otherwise you should see authentication success log messages and things should work smoothly.

May I ask you to report back on whatever you find? Even better, join the Discord, communication is usually faster there. Still better write a short README on how you made NextCloud Talk work with STUNner, we'd be happy to add it to the tutorials!

[jattind]

Thanks for the quick response. This is very helpful and I will give it a try sometime next week. Will let you know how it goes. Regards,Jattin On Sunday, September 25, 2022 at 10:23:49 AM PDT, Gabor Retvari @.***> wrote:

Hi @jattind, thanks for the question. Short answer: we don't know, we haven't looked into NextCloud Talk yet, but now that you're bringing this up we will put this to the TODO list.

That being said, we'd happy to walk you through integrating STUNner with NextCloud Talk. This usually shouldn't be a massive problem but there may be the occasional bumps along the road.

So far, my quick investigation has led me to believe that either (1) we're lucky and everything should work smoothly or (2) we're not that lucky and we'd a trivial patch in STUNner's TURN authentication handlers to support NextCloud Talk. The problem is that NextCloud Talks seems to default to coturn's use-auth-secret authentication mode that STUNner only partially supports at this moment with the longterm authentication mode.

Here is how to test this out:

• Install NextCloud Talk to Kubernetes. The default Kubernetes manifests should work, but don't forget to remove the hostNetwork: true hack from your media server container template to install your media servers into regular pods and make sure to wrap the pods that act as a media server in your NextCloud Talk distro with a Kubernetes service, call it nextcloud-talk-media-svc for simplicity.

• Install STUNner and set the authentication mode in the GatewayConfig to longterm: kubectl apply -f - <<EOF apiVersion: stunner.l7mp.io/v1alpha1 kind: GatewayConfig metadata: name: stunner-gatewayconfig namespace: stunner spec: authType: longterm sharedSecret: <YOUR-SECRET> EOF

• Open a STUNner Gateway at an arbitrary port and attach a UDPRoute to it that points to the nextcloud-talk-media-svc service as a backend,

• Configure NextCloud Talk to use the above TURN secret for authenticating with STUNner:

  • set the relay transport mode to "TURN only"
  • set the TURN URI to turn:<STUNNER_PUBLIC_ADDRESS>:<STUNNER_PUBLIC_PORT>, the concrete values can be parsed out from stunnerctl output
  • set the TURN secret to <YOUR-SECRET>

This should be enough to direct your Talk clients to talk to the media server via STUNner. Problem is, they may not be able to authenticate. In particular, the client may or may not send a user-id alongside the timestamp in the username option depending on the way NextCloud Talk generates TURN authentication credentials for clients, while STUNner assumes that the username part of the TURN credentials contains only a timestamp but no user id. It is a one-line patch to let STUNner ignore the user id but first we'd need a good indication that this is indeed necessary.

Now start a NextCloud Talk session and look for the authentication success/failure entries in the stunnerd pod's logs. If you see authentication failures with the log message invalid time-windowed username then NextCloud Talk instructs clients to send the user id and we need the STUNner fix, otherwise you should see authentication success log messages and things should work smoothly.

May I ask you to report back on whatever you find? Even better, join the Discord, communication is usually faster there. Still better write a short README on how you made NextCloud Talk work with STUNner, we'd be happy to add it to the tutorials!

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[rg0now]

This issue has been stale for about 2 years now, closing it for now. If there is still interest in making NextCloud Talk work in Kubernetes, please reopen.