Hello,
I was working with peer to peer technology before and in the production mode i needed to configure the iceServers: [ ] that contain a Stun and Turn servers to ensure best connectivity between peers.
do i need to use this iceServers in the Mediasoup use case ?
if yes, please, where could i integrate my servers? (stun/turn iceServers: [ ])
As far as I know you don’t need any.
Stun servers are used to find the ip of the two parties to try to have a direct connection. With mediasoup you already know the IP of your server so the browser knows exactly where to connect to.
Turn servers are used as a relay if direct connection isn’t possible. With mediasoup you already have a direct connection to the server from the browser.
@Dirvann I Got you now and the answer was on my question, I was using a peer to peer tech.
Thank you so much.
good job in the Github.
no more available ports transport:udp, ip:’0.0.0.0’, numAttempt:101 what does it mean ? i notice that frequence error many times when i tested the library? is that mean the server reacht he max consumer and producer number ?
It means that:
Transports once their clients disconnect, orThis is a bug in your app logic/code.
hello, how can I know the total number of producers and consumers on my server or on my mediasoup extention ?
You create them so you must know.
Also please don’t use an existing thread for unrelated questions.
If a client has blocked UDP ports, TURN server comes to the rescue, so data would be sent through TCP, with a bigger delay ofc, but it covers more clients.
I found this thread and comments from @ibc very helpful regarding STUN/TURN:
https://groups.google.com/g/mediasoup/c/CwsxtmCcrh4/m/puOJlEDLBwAJ
In many of the historical posts from @ibc he pointed out that MediaSoup uses ICE-LITE, “meaning that it does not require ICE candidates from clients but, instead, will wait for RTP in its open ports to know the client’s remote IP, port and transport protocol (UDP or TCP).”
Another thing I have read that may be useful here: configuration using port 443 is a way to get around restrictive corporate firewalls, if necessary. From @ibc in this post:
For worst network cases you should have your TURN server listening into TLS port 443 with a proper TLS certificate. Since some networks (WiFi in hotels and so on) block traffic other than 80 and 443, you’d rather have TURN listening in TLS 443 of public IP_A and your HTTP/WS signaling server in TLS 443 of public IP_B.
One thing I am also investigating, rather than eliminate stun/turn entirely, is if there is any benefit to installing Coturn alongside MediaSoup, even on the same server, and using it for normalizing client connections and managing them and then MediaSoup for the SFU functions. This and port 443 is mentioned in a post at medium (google: WebRTC pro-tips @ Medium – I am limited in links in my post as a new member)
If you’re using an SFU or MCU, consider running TURN along-side your software, and forcing everyone to relay through TURN. It’s sixes this way and can actually simplify a few things.
HI, just wondering if have managed to implement a TURN server between your mediasoup client and mediasoup server?
We currently use Jitsi as a video conferencing platform but wanted to evaluate/compare with mediasoup. We have coturn running on the same 443 port on the server as the web client itself (but with a different domain name and cert).
I can’t seem to find any direct experiences on using a TURN server with mediasoup yet, or how it would be implemented without further WebRTC knowledge from other sources. We have clients behind corporate firewalls that mean we have to use a TURN server on a TCP:443 port.
I presume we’d need a coturn server listening on port 443 and we’d provide that to the mediasoup client using transport.updateIceServers([])
mediasoup (server) does not need any knowledge/configuration related to TURN. You must setup your TURN server so it has proper direct networking to the mediasoup server. That’s all.
In client side you pass STUN/TURN servers when creating a send/recv transport:
Thanks @ibc, I will try it. Can I also confirm that the client will only use the TURN server other (e.g. UDP) communication isn’t availble? As a failover. I’m not sure if that would be based on logic in the mediasoup client or underlying libraries.
And we can have some clients using the TURN server, and others not using it, in the same conference? Presumably, like you say, the clients/server would not know or care.
Each client will choose whether to use TURN or not depending on previous ICE process and on what it feels works better.
And this is PeerConnection behavior, mediasoup-client does decide here.