## WebRTC bases routing structures

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

![voip routing structures][voip_routing_structure]

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][matrix_structure]

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][matrix_sfu_structure]

[matrix_structure]: ./img/matrix_structure.webp
[matrix_sfu_structure]: ./img/matrix_sfu_structure.png
[voip_routing_structure]: ./img/voip_routing_structures.png