Your choice to make.

I stop using webrtc adapter now.
I found that it add new bug to Safari 13.

Want to fix found problem in adapter and found that it’s very difficult !
It’s not enough send problem explanation.
I have sign some agreement with Google, provide complete test, etc.
;-(

For STUN not much really. For TURN main factor would be the “distance” from the user. You can learn more about the servers in WebRTC here: https://bloggeek.me/webrtcs-server-side-enroll/

You don’t need media server for quality of 1:1 video calls.

2/ Is it necessary to use media server in 1:1 video call to ensure the quality of the call? (I’m afraid it’s something low quality without media server).

Minh,

A few comments:
* There’s no ICE server. There’s an ICE protocol
* STUN is usually “packaged” with a TURN server (although not always)

For 1:1 you don’t need a media server. You’ll need STUN, TURN and a signaling server
For 1:many you will also need media servers

As I discovered, I know some servers may include in WebRTC app:

– Signaling server for mutual understanding between peers.
– STUN server for exchange IP address between peers when NAT appears.
– TURN server is like a relay server that makes transitions of streams to peer in central server.
– ICE server helps peer find the way (using signaling or STUN, or TURN) to get information of other peers.

Media server for processing media stream (encode, decode, multiplexing, or image processing) in server and output the processed stream to peers.
So to have a good livestream (low latency, reasonable price for infrastructure) system using WebRTC. What things do I need in system:

– Just signaling, turn, stun and ice servers.

– Or Both of them and media server (like Kurento).

– Or just media server only.

What’s the best choice for 1:1 (like Facetime) and 1:many (like Youtube livestreaming)?

And do I understand it right?

Thank you!

Nir,

Thanks for that.

I truly think WebRTC democratizes communication and takes it out of the hands of VoIP engineers. Many of the most interesting use cases I’ve seen were built because no VoIP engineer was involved in them.

Knowing the technology and how to use it is different than what background is needed.

I hope that clears what I tried to convey with “democratize” (which probably means accessible, so I guess we’re in agreement here).

The main thing that people tend to forget here is that WebRTC is a whole lot of different things and technologies – and getting them to work the way you want isn’t a trivial task.

One thing I don’t agree with your writing is the following: “It “democratizes” this whole domain, taking it from the hands of experts into the hands of the masses of developers out there. Slapping a bit of code and seeing real time video is magical.” – I find that statement a little misleading.

If you would like to define “democratize” as: making it accessible – I agree. It doesn’t mean that it is as simple as writing a few lines of JavaScript. Adding voice and video to applications at ease is magical, indeed. But there is a whole lot of hard work behind it. If you go to our website (https://cloudonix.io), you will see at the bottom left side a “handset” icon. Click-it and following a short entry form, you will be connected directly to one of us. That “widget” seems incredibly simple, but, behind it – there is much “hard work”. Developer’s can use platforms like Cloudonix, Twilio, Nexmo and others to create various WebRTC based solutions – but they will be different. While WebRTC democratized the access to voice and video capabilities, it created new opportunities for vendors and service providers.

In general, I agree – WebRTC is not a place for script kiddies or ‘fly by night coders’, it’s a serious piece of technology that requires much care.