Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Optimizing the infrastructure costs and call quality of web rtc based group calls

373 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Optimizing the infrastructure costs and call quality of web rtc based group calls

  1. 1. Optimizing the infrastructure costs and call quality of WebRTC-based group calls George Politis | linkedin.com/in/gpolitis | @jitsinews
  2. 2. Jitsi Meet Overview • Jitsi Meet (Open Source) Stack • meet.jit.si cloud • meet.jit.si metrics !2
  3. 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. 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. 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. 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. 7. meet.jit.si Metrics • 91,408 conferences • Average conference duration 38 min • Average participant count 3.37 • 3.47M conferencing minutes !7
  8. 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. 9. Choosing the right architecture • Multipoint Control Units (MCU) transcode media streams • Selective Forwarding Units (SFU) route packets
  10. 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. 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. 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. 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. 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. 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. 16. Demo time! https://drive.google.com/file/d/ 1BuG8YzcIkEFs588HDTxtA80XwWT4JAQH/view?usp=sharing
  17. 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. 18. Demo time! https://drive.google.com/file/d/ 1SVKLEEl_NbmCrmzrrbL7NxzoQVRk7zQB/view?usp=sharing
  19. 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. 20. Off-stage sender stream suspension
  21. 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. 22. Questions and answers George Politis | linkedin.com/in/gpolitis | @jitsinews !22

×