Files
element-call-book/src/ch01-01-routing-structures.md
Ralf Zerres 36bb3d6b8a Document chapter 01
* the routing structure
* the building blocks inside Element-Call
2024-10-17 18:01:07 +02:00

2.4 KiB

WebRTC bases routing structures

The following image visualize the concepts of actively used routing structures inside a RTC applications.

voip routing structures

Historically Elememnt-Call did implement an infrastructure, where all participants were fully meshed. That means all participants had a direct peer to each other in a Mesh. This structure does work quite well with a low number of call partners (e.g 1:1 sessions). Clearly this structure is totally inefficient and collapsing, as soon as the number of participants rises: The needed number of streams that have to be synchronized are increasing exponentioally.

Most commercial solutions overcome this bottleneck utilizing a Multipoint Connection Unit (MCU): Each participant of the call is directly connected to the controlling MCU. The MCU will consolidate all streams and has only one stream to each participant. It is able to linearly scale.

MCU routing has disadvantages and shortcommings too.

  • You can't assign different egress parameters from the MCU to individual participant streams
  • A single MCU can't handle distributed structure

Therefore Element-Call has choosen to implement the service on top of a Selective Forward Unit (SFU) capable backend:

Matrix structures

Each participant will only send in one stream to the choosen SFU. The number of egress streams can scale linearly, comparable to the concept used with an MCU. But in contrast to MCU based communication clients insede the MatrixRTC are able to dynamicaly advertise to their SFU what ingress streams they are interested in. Here are some commen szenarios:

  • I'm only interested to get participant A, B, C, E, G but not D and F
  • Please only send high resolutions for the speaker and reduce the bitrate for all other participants
  • Change my own egress bitrate to a given value

On top of this, the nature of a Matrix based communication makes use of a distributed infrastructure. Within MatrixRTC that allows communications

  • between different involved SFU's
  • Require and handle E2EE meetings for all participants
  • Authenticate matrix accounts as well as guest accounts inside a call

Matrix SFU structures