P2P4121
If you are wondering, we use this for: “Peer-to-peer for 1 to 1″. It does what it says: every time there are only two participants in a call, instead of using Jitsi Videobridge, Jitsi Meet will now connect them directly. It’s as simple as that.
There are two major wins with this feature. First and foremost, given how one-to-one calls often represent the majority of the conferences on most RTC services, taking them off of your infrastructure (NAT permitting) means that you don’t have to provide any resources for them. If you are running a Jitsi installation for a single company or group, this means that you now need even less hardware or even smaller VMs to service it. If, on the other hand, you are a large scale provider with thousands or tens of thousands of daily calls, this should significantly reduce your bill.
There is also a second advantage. While in a conference, the browser, Jitsi Videobridge and Jitsi Meet rely on things like simulcast and temporal scalability to adapt the amount of traffic they emit to the available network bandwidth. We have already explained adaptivity in more detail, but the gist of it is that with simulcast all endpoints send three versions of their video so that Jitsi Videobridge can choose and forward only one of them to every other participant. While this generally works quite well, it is also less precise than what endpoints are able to do when they talk directly to each other. Being in control of the encoder, and having to adjust it to only one receiver allows for a much wider variety of encoding options so you may notice that with this new feature your video quality adapts better to changing network conditions.
So how does this work exactly?
Let’s back up for a second. In the past, you might have heard us say that our Jitsi infrastructure supports multi-party calls natively. What we really mean by that is that all calls, including 1:1, are really just conferences for us. They were all hosted at Jitsi Videobridge, which routed all their media.
While this works really well, it also means that in cases with two participants, we unnecessarily burden the infrastructure in 1:1 scenarios where media could be flowing directly between users. That is actually quite significant since 1:1 calls, as already mentioned, often represent more than half of the calls on video conferencing services.
To solve this, we have implemented a new mode of operation that we activate automatically for conferences with two participants. With that mode we keep our bridge connections alive but also attempt a direct connection. If it doesn’t succeed, we keep all media through going through Jitsi Videobridge. If it does succeed however, we seamlessly switch to it.
Note how we always keep the bridge connection alive though. This is SUPER important for what comes next:
Should a third person join the call, we seamlessly switch all media back to our bridge so that communication can continue uninterrupted. If then one of these people leave, we are back to an attempted direct connection. Because the connection with the bridge is always live, these switches are barely if at all noticeable. You can see how it works here:
You can always track the status of your connection by hovering over your local GSM bars, clicking on “Show more” and looking for the (p2p) label there.
As usual, you are welcome to go and try this on https://meet.jit.si
UPDATE
Our own George Politis also put together a presentation discussions some of the engineering that went into this at: https://jitsi.org/news/iit-rtc-2018/
Love,
The Jitsi Team