Document chapter 01

* the routing structure
* the building blocks inside Element-Call

src/ch01-01-routing-structures.md

@@ -0,0 +1,55 @@
+## 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