 Hi everybody. I'm Joachim and I'm going to talk about the speed services that we will that we are providing for an extra talk to Support more users and larger installations Yeah, you all have heard about next law talk enough, so I don't have to repeat everything again So I'm talking about a quick overview about how web RTC works and what it is So web RTC basically is a peer-to-peer connection between two clients And over that peer connection there can be different streams that can be audio video data and Also screen sharing and in order to establish that peer-to-peer connection the clients have to communicate using the signaling messages To actually set up the connection So parts of that Signaling messages are Negotiation of the codex that are being used that the streams in the peer connection and also the endpoints Over which the clients can be reached so it's IP address and port and their special handling required to support clients behind the net or a firewall So that setup requires multiple messages There's often answer first being sent containing all the codex And then there are multiple candidates containing the IP addresses and the ports and these have to go through a central server because Before the actual setup the clients don't know each other yet So with the next cloud talk if you just install the regular app everything goes to next cloud the messages are stored in the database and The clients are using long polling get and post requests to actually send that messages to their to next cloud and To retrieve them from there and our next load a PHP Request is being handled and is polling the database for new messages This of course has a rather high latency The streams are all peer-to-peer so if there are multiple people communicating with each other Everybody has to establish a peer-to-peer connection with all the other peers and has to encode and decode all the streams for each participant So that requires a rather high CPU and upstream bandwidth With the speed services we want to improve All of these things. So first is the Stand-alone signaling server. It's using web sockets for communication. So there's no get and post involved can messages can be sent directly and There's no additional latency involved besides the actual network latency Also events from next cloud are distributed to that signaling server to the clients For example, if a user is invited to a new room He gets an event to have to refresh the room list and that signaling service implemented in go The other service is the web RTC gateway or the MCU it can distribute the streams between different users and It's using a pop-up pattern So a user publishes his stream to the web RTC gateway and other clients can subscribe this stream from the gateway Using the open source project Janus for that have integrated it in the signaling server and Janus is implemented in C We provide packages for Ubuntu. So it's current or the last three LTS releases And customers can install all these components on their own server So it's still self-hosted even if the data is no longer really peer-to-peer, but it's going through that central server We have already first setups including some regional government customers The third service you us already mentioned it briefly is the zip telephone integration That can be used to dial into web RTC calls. So you can join the next cloud talk call by telephone We have scriptable Workflows can customize all the voice prompts and everything So how this does that look like we have the clients communicate to next cloud and to the different services which are all interconnected I have to speed up a little bit and Yeah, so the signalling is directly no more long-polling involved And also the streaming goes through the web RTC gateway So every client only has to publish the stream once no matter how many Subscribers are there because everything goes through that gateway On the road map currently all that setup is not supported with the mobile apps So this is something that needs to be worked on We will also work on providing high availability support and redundancy So you can have multiple of these signaling servers and gateways We will package for other distributions besides a boom to depend on depending on customer demand and Further optimize everything also we want to support Simulcast streams meaning that a client is publishing his stream in different resolutions and with different Bandwidths and the gateway then selects for the clients the best stream that they should receive also, we're working on H2 65 screen chain to further reduce the bandwidth and We are working on a desktop app for next cloud talk That is being built with Qt or native code That's it if you have questions be free to ask me. Thanks