Comments (5)
Hey,
At first glance it does not seem impossible. Although I was wondering what could be the benefit for you to cascade two TURN servers in the same cluster? Since STUNner at the edge of the cluster already relays traffic into the cluster, what would be the practical benefit of coTURN in the second step? But anyway, I am not here to ask but to help you out, so getting back to your question STUNner does not care what is on the peer side, it can be another TURN server. As long as the TURN allocation points to your coTURN instance (either running behind a podIP, clusterIP, NodePort service) it simply opens a UDP or TCP route and relays traffic into Kubernetes and lets Kubernetes networking to do the rest. On the other hand, making a TURN allocation from behind another TURN server is something where tweaking on the client side could be needed, I guess. Does this help?
from stunner.
Hi @nmate ,
Thanks for your reply.
The first idea is that I am not intend to cascade TURN servers in a cluster.
What I mean is if the cluster is serving some user devices (e.g. 3 user devices), it will have 3 services (accessible via a unique URI subpath, configured by K8s Ingress). Based on this, what I want is adding a TURN server per service, such that each service has its own TURN server. And I could simply tear down the services when user devices finished its life cycle without affecting others.
BTW, do you mean that I could use STUNner as an edge relay and connected by user devices and PC Chrome browser, to route corresponding p2p connection requests to the TURN servers behind STUNner ?
As STUNner only listen to single port, if user device no.1 wants to connect its own TURN server, how could I config STUNner to route p2p requests to its own TURN server no.1 ?
I wonder how could this actually be done in K8s. Could you mind give me some examples in YAML ?
from stunner.
What I mean is if the cluster is serving some user devices (e.g. 3 user devices), it will have 3 services (accessible via a unique URI subpath, configured by K8s Ingress). Based on this, what I want is adding a TURN server per service, such that each service has its own TURN server. And I could simply tear down the services when user devices finished its life cycle without affecting others.
While this is clearly doable, it is definitely not the recommended way to do that. Instead, just deploy a single STUNner gateway service (you can scale it to arbitrary many pods) and use it to ingest and route the traffic of all users to the corresponding per-user backend service. When a user wants to join, the corresponding backend will generate an ICE candidate with its own pod IP and send it back to the user, that's how the user's browser will know which backend to connect to via STUNner, and the nice thing is that this is all automatic with WebRTC!
BTW, do you mean that I could use STUNner as an edge relay and connected by user devices and PC Chrome browser, to route corresponding p2p connection requests to the TURN servers behind STUNner ?
That's the purpose, but routing is not "to the TURN servers behind STUNner" (you don't need a TURN server behind STUNner, STUNner is a TURN server) but directly to your per-user backend services. Please make sure to read all the docs here, here and here.
Let's stay at your example: you have 3 users, served by 3 per-user backend deployments/services in Kubernetes, say, service-user1
, service-user2
, service-user3
. Then, deploy a STUNner gateway hierarchy, add a single Gateway to expose STUNner on the protocol/port you want (let's call it my-gateway
), and then add 3 separate UDPRoutes, one Route per user, e.g., something like this for user1
:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
name: route-user1
spec:
parentRefs:
- name: my-gateway
rules:
- backendRefs:
- name: service-user1
You can also have a single UDPRoute for all users but it will be a bit more difficult to update it as users come and go:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
rules:
- backendRefs:
- name: service-user1
- name: service-user2
- name: service-user3
I wonder how could this actually be done in K8s. Could you mind give me some examples in YAML ?
We try to give you as much help as we can and you can count on our assistance in the future too, but please keep in mind that we have very limited time for unpaid support (we are in the consultancy business though).
from stunner.
Hi @rg0now ,
Thanks for your reply.
Perhaps my english is bad or the situation is too complicated to explain by words. All I need is 1 COTURN server run as a simple container inside 1 Pod (with 1 associated Service + Ingress). And we do not need COTURN help us to route traffics to some arbitrary media services. We only need the p2p connection function + data channel for image sending (which mean we need a very simple video call feature, between user's PC browser and his device).
As our cluster only has 1 entrance, which is cluster_master_ip
, in order to access different user-services, we use Ingress. In our current setting, we could access containers in Pod from external via K8s ingress only.
- User1:
https://<cluster_master_ip>/user1/....
- User2:
https://<cluster_master_ip>/user2/....
For the most early idea, I just think COTURN could be accessed behind Ingress such that users could connect to COTURN via a URI like turn:cluster_master_ip>/user1/coturn
or turn:cluster_master_ip>/user2/coturn
but I found this URI violates TURN's definition.
So at this moment, due to my lack of knowledge about WebRTC and COTURN stuff, I could only deploy 1 very simple COTURN server into my K8s cluster, and just expose it to public in terms of turn:cluster_master_ip>:<PORT>
.
Thanks for your time.
from stunner.
All I need is 1 COTURN server run as a simple container inside 1 Pod (with 1 associated Service + Ingress).
This is exactly what we propose not to do, because it will be a PITA to route your media to the required service. Deploy a single STUNner and use proper media routing via the Gateway API (i.e., UDPRoutes) to describe your intent.
Now I understand that in your situation maybe an unmanaged coturn sidecar container is the proper choice. We expect you back once you realize you need something that you can actually manage...:-)
from stunner.
Related Issues (20)
- Meetecho Janus integration HOT 7
- turn ERROR: Failed to handle datagram: failed to create stun message from packet: unexpected EOF: not enough bytes to read header HOT 1
- Mixed protocol available for AWS? If not how to setup health check if not supported? HOT 3
- Does it work with MediaMTX (Whip) and can I choose the destination server with an API? HOT 8
- Gatteway API v1.0 incompatibility on GKE HOT 6
- UDP Gateway Error HOT 11
- srflx ICE candidate wrong ip? HOT 3
- SRS integration? HOT 5
- Extra question about horizontally scaled Stunner HOT 3
- Example app udp-greeter.yaml not working - help needed HOT 10
- v0.16.0 - Websocket error HOT 3
- v0.16.0 - Stunnerd pods get into state where they won't respond to TURN requests HOT 1
- Allow Gateways to request a specific NodePort in the automatically created Service HOT 7
- TURN connection breaks when the backend pod enters graceful shutdown HOT 13
- `stunnerctl config` does not fall back to the default namespace
- Help testing on AKS (Azure) HOT 1
- Media plane: Asymmetric ICE connection issues: no allocation found HOT 6
- Deployment in headless mode does not resolve public ip address of client HOT 4
- Turncat example not working on EKS HOT 11
- error install on container : kubernate and helm HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stunner.