56 lines
2.4 KiB
Markdown
56 lines
2.4 KiB
Markdown
## 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
|