There’s been an increasing number of service providers that offer WebRTC-based group calls in recent years. Without any special handling, the server egress bitrate grows quadratically and the participant bitrate grows linearly with the number of participants in a call, which has a direct impact in the total infrastructure costs and in the end-user experience. In addition, conferencing systems that are designed for group calls are used, at least some of the time, for one-on-one calls. Changes from one-on-one to a group call (and back) happen dynamically as participants join or leave a conference. For a system to be optimal in terms of resource use and QoS, it has to treat these two cases differently and dynamically switch between different operating modes with specific features for each case. In this presentation we describe what features need to be enabled for each mode and quantify the benefit from the users and the service provider perspective.

1. Optimizing the infrastructure
costs and call quality of
WebRTC-based group calls
George Politis | linkedin.com/in/gpolitis | @jitsinews

2. Jitsi Meet Overview
• Jitsi Meet (Open Source) Stack
• meet.jit.si cloud
• meet.jit.si metrics
!2

3. Jitsi Meet Stack
!3
Jitsi Meet for the Web
(WebRTC JS APIs)
Jitsi Meet for Mobile
(React Native WebRTC)
JiCoFo
(Signaling Server)
Jitsi Videobridge
(Media Server/SFU)
Client Side
Server Side
XMPP (Prosody) UDP/DTLS/SRTP

4. Jitsi Meet
• Multiple Layouts
• Video Quality slider
• Speaker stats
• Desktop sharing
• Integrated Chat
• callstats.io integration
• Transcriptions
• Recording to Dropbox
• Telephony support
!4
(web & mobile app)

5. Jitsi Videobridge
• Implements Google
Congestion Control
• Adaptive Simulcast/SVC
• Adaptive Last-N
• XMPP API
• REST API
• callstats.io integration
!5
media server/SFU

6. meet.jit.si Cloud
• Horizontal scaling through
Sharding
• Geo-distributed HA Proxy
cluster routes participants
to shards
• AWS Regions: North
Virginia, Oregon, Ireland,
Australia
• Beefy dedicated C4.xlarge
for SFU & TURN servers
!6
Signaling
components
SFU 1 SFU 2
SFU N
HA Proxy
Cluster
…
…
Shard N
AWS Region Z
AWS Region X
AWS Region Y
Shard 1
TURN

7. meet.jit.si Metrics
• 91,408 conferences
• Average conference duration 38 min
• Average participant count 3.37
• 3.47M conferencing minutes
!7

8. Minimize costs and
maximize call quality?
• Make the backend less CPU/memory/bandwidth hungry
• Deliver the best quality within the limits set by the client
network and CPU

9. Choosing the right
architecture
• Multipoint Control Units (MCU) transcode media streams
• Selective Forwarding Units (SFU) route packets

10. Google Congestion Control
• Network congestion directly
impacts Quality of Service (QoS)
• Google Congestion Control
cues:
• Packet delay variation
• Packet loss
• Standard RTCP & REMB or
Transport Wide Congestion
Control Header and RTCP
feedback
!10
Media
Target bitrate
2.5Mbps
Packet arrival times
Packet loss
Sender
Receiver

11. SFU + simulcast
receiver A
sender B
sender C
sender A
SFU
viewport feedback
720p@30fps
360p@30fps
180p@30fps
720p@30fps
360p@30fps
180p@30fps
720p@30fps
360p@30fps
180p@30fps
720p@30fps
180p@7.5fps
180p@7.5fps

12. SFU + simulcastEndpointingressbitrate(Mbps)
0
3
6
9
12
15
18
21
24
27
30
# participants
2 3 4 5 6 7 8 9 10
With Simulcast Without simulcast

13. SFU + simulcastSFUegressbitrate(Mbps)
0
30
60
90
120
150
180
210
240
270
300
#participants
2 3 4 5 6 7 8 9 10
With simulcast Without simulcast

14. SFU + Last-N
receiver A
sender B
sender C
sender A
SFU
720p@30fps
(+ audio level information)
720p@30fps
(+ audio level information)
720p@30fps
(+ audio level information)
720p@30fps
720p@30fps
Last-N = 2
i.e. forward last 2
active speakers

15. SFU + Bandwidth Adaptivity
Bandwidth
Estimator (GCC)
Bitrate Controller
receiver A
sender B
sender C
sender A
Packet Filter
transport feedback
viewport feedback
bandwidth estimation
720p@30fps
360p@30fps
180p@30fps
(+ audio level information)
720p@30fps
360p@30fps
180p@30fps
(+ audio level information)
720p@30fps
360p@30fps
180p@30fps
(+ audio level information)
720p@30fps
180p@7.5fps

16. Demo time!
https://drive.google.com/file/d/
1BuG8YzcIkEFs588HDTxtA80XwWT4JAQH/view?usp=sharing

17. SFU
Participant A Participant B
Group mode
connection
Group mode
connection
One-to-one mode
connection
P2P4121
(aka peer-to-peer for one-to-one)
• 52% reduced bandwidth
• 35%-40% infrastructure
pressure (memory/CPU/
load)
• 20%-30% shorter RTT
(depending on the region)

18. Demo time!
https://drive.google.com/file/d/
1SVKLEEl_NbmCrmzrrbL7NxzoQVRk7zQB/view?usp=sharing

19. Off-stage sender stream
suspension
Bandwidth
Estimator (GCC)
Bitrate Controller
receiver A
sender B
sender C
sender A
Packet Filter
transport feedback
viewport feedback
bandwidth estimation
720p@30fps
360p@30fps
180p@30fps
(+ audio level information)
180p@7.5fps
(+ audio level information)
paused
720p@30fps
180p@7.5fps

20. Off-stage sender stream
suspension

21. Future
• Experiment with hardware accelerated H264 simulcast
instead of (software) VP8 simulcast
• Experiment with VP9 SVC to prevent wasting bits for
encoding/sending multiple streams
• Optimizing bandwidth usage with cascading bridges
• Congestion control improvements: More aggressive
bandwidth probing, faster ramp-up, BBR

22. Questions and
answers
George Politis | linkedin.com/in/gpolitis | @jitsinews
!22