A brief dialogue explaining why WebRTC separates signaling (control) and media paths: signaling can tolerate higher latency (hundreds of ms) while media requires low latency so media services are placed close to users and central signaling can be located elsewhere. The split is partly legacy/practice and partly design-driven by latency differences.
Why does WebRTC split between media and signaling over the network?
WebRTC has a split where you say you have a signaling server that you talk to to exchange the information you need to set up the media session. And the reason for this split is that the latency properties of both are very different. For signaling it's okay to have 4, 500 milliseconds of latency. It's not great but for media that would be a killer thing. So you design your system in a way that you put the media service very close to the user while your central signaling back end might be in a different place.
Okay so it's not like there is this reason behind of this is how we did things so we're going to do it again.
I think largely this has been the way we've always done this stuff and we keep on doing it.
Yes. So it's part legacy or this is how we do things over here and part actual reasoning behind that.
Yes.
Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin
