mediasoup | Cutting Edge WebRTC Video Conferencing | Runtime Evironment library

What's up with this?

You are correct that this is a pain in the xxx neck when doing casual demos and bug-reproductions.

I do one of two things when I need to do this.

1. put the app on https://glitch.com . They give you a durable https://yourprojectname.glitch.me URL to work with. Good for one-offs. I have had bug reports against both Chromium and Firefox accepted with glitch.com examples.

2. deploy the app to Heroku. They give you a durable https://example-whatever-12345.herokuapp.com URL to use. Good for bigger stuff.

Others use https://netlify.com for purely static stuff. I haven't used it myself.

If you have your own domain and server you can also use https://letsencrypt.org/ to obtain certs. But it takes a mess of server rigging, and might not be best for casual stuff.

Just realized the app.module.tns.ts doesn't have the Dashboard component declared which resolves the issue.

Here is the project with mediasoup recording implemented mediasoup3-record-demo

Because how ICE works is that initially the browser looks at what IP based network interfaces it can find on your machine.

Then it takes the number of network interfaces and combines it with ever single STUN server and every single TURN server the service provides. Next it needs to send request to every single of the these combinations and keep track of the responses. In case of STUN it's just a single response, in case of TURN it is usually multiple round trips. So the more STUN and TURN servers you have the longer it takes to get answers from all of them.

Now if STUN server #1 reports your external IP address as A, with port 1, most likely STUN server #2 is also going to tell you it sees A as your external IP address, with the only difference it reports port 2. In almost all cases all the STUN servers are going to report back the exact same external IP A. But reporting the same external IP address over and over again to the ICE agent on the other end does not increase the chances of establishing the connection at all since its request are all going to hit the same router/NAT/firewall.

With TURN servers one can argue that more TURN servers could help more, as each TURN server should give the browser a different IP address for relaying. But it would be highly unusual if a given browser is able to reach one TURN server and not the another.

In the end all of these servers result in the browser emitting more ICE candidates. And so more ICE candidates need to get send to the other browser or ICE agent. As a result the ICE checking table which tries all possible permutations of local and remote ICE candidates grows bigger and bigger with each ICE candidate. And so it produces a lot more network traffic, while not much increasing the chances of establishing a connection.

WebRTC tries everything it can do to make a p2p connection, but there are times that it will fail. The turn server acts as a last resort so that the peers can both connect through the turn server. Obviously this is not a p2p connection, so there will be extra latency, and you will have to make sure that your turn server has enough bandwidth to cover all of the connections you expect.

TL;DR, If you need 100% connection rates, you should have a turn server.

I believe AWS has a ready made instance you can spin up, or if you could use this open source coturn server https://github.com/coturn/coturn

On a debugging note... Check your ice candidates type. You should see host and srflx if you only have a STUN server, but if you have a TURN server you will also see relay. You can replicate this issue by discarding the ice candidates that have host and srflx types.

the mediasoup forum is here: https://mediasoup.discourse.group

BTW, as Philipp says, mediasoup "is not listening in port 8443 or 443". That's the WebSocket server of the mediasoup-demo project. mediasoup does not listen by itself for HTTP or WebSocket at all.

If you don't provide your TLS certificate to mediasoup.createWorker() then mediasoup will create its own random certificates for DTLS. And it's in DTLS where you see that error.

BTW I've tested in latest Firefox stable (68.0.2) and Nightly (70.0a1 (2019-08-14)) in OSX and I don't get any SSL error in DTLS, so honestly no idea.

PS: If you can provide more info (for example which mediasoup version you are using), please open an issue in mediasoup Discourse Group in the "mediasoup-demo" category.

If you need to listen bellow than 1024 port then you need to run as administrator on windows and as a root(sudo) user on Linux/MAC that is sudo node server.js

and as documentation of https://github.com/versatica/mediasoup-demo, you must update port on config.js