These are the slides for the presentation I shared at the virtual edition of IIT-RTC 2022. I talked about how cascading/scalability worked with Janus 0.x, and what steps we've taken to do the same for 1.x (multistream) as well. In particular, the focus is on the new integrated cascading support in the VideoRoom plugin.
Boost Fertility New Invention Ups Success Rates.pdf
Janus SFU cascading @ IIT-RTC 2022
1. SFU Cascading with Janus
Lorenzo Miniero
@elminiero
IIT Real-Time Communication 2022 – WebRTC Track
October 11th 2022, Chicago, IL, USA
2. A few words about me
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Main author of Janus®
Contacts and info
• lorenzo@meetecho.com
• https://twitter.com/elminiero
• https://www.slideshare.net/LorenzoMiniero
• https://lminiero.bandcamp.com
3. A quick reminder on what Janus is!
Janus
General purpose, open source WebRTC server
• https://github.com/meetecho/janus-gateway
• Demos and documentation: https://janus.conf.meetecho.com
• Community: https://groups.google.com/forum/#!forum/meetecho-janus
16. We use it A LOT in our Virtual Events Platform!
https://commcon.xyz/session/turning-live-events-to-virtual-with-janus
17. This works great with Janus 0.x, but what about multistream?
• The first version of Janus (now called 0.x) had a key “limitation”
• Each PeerConnection could contain 1 audio and 1 video stream at max
• Multiple PCs needed to serve content from different SFU participants
• Very simple and easy to manage, as far as cascading is concerned
• 1 VideoRoom publisher = 1 Streaming mountpoint
• Relatively easy to orchestrate and negotiate in web apps
• New version of Janus (1.x, a.k.a. multistream) removes this constraint
• VideoRoom can be told to only use 2 PCs per participant
• One PC to send everything, one to receive everything
• Much more flexibility in how subscriptions are handled
18. This works great with Janus 0.x, but what about multistream?
• The first version of Janus (now called 0.x) had a key “limitation”
• Each PeerConnection could contain 1 audio and 1 video stream at max
• Multiple PCs needed to serve content from different SFU participants
• Very simple and easy to manage, as far as cascading is concerned
• 1 VideoRoom publisher = 1 Streaming mountpoint
• Relatively easy to orchestrate and negotiate in web apps
• New version of Janus (1.x, a.k.a. multistream) removes this constraint
• VideoRoom can be told to only use 2 PCs per participant
• One PC to send everything, one to receive everything
• Much more flexibility in how subscriptions are handled
19. This works great with Janus 0.x, but what about multistream?
• The first version of Janus (now called 0.x) had a key “limitation”
• Each PeerConnection could contain 1 audio and 1 video stream at max
• Multiple PCs needed to serve content from different SFU participants
• Very simple and easy to manage, as far as cascading is concerned
• 1 VideoRoom publisher = 1 Streaming mountpoint
• Relatively easy to orchestrate and negotiate in web apps
• New version of Janus (1.x, a.k.a. multistream) removes this constraint
• VideoRoom can be told to only use 2 PCs per participant
• One PC to send everything, one to receive everything
• Much more flexibility in how subscriptions are handled
20. VideoRoom usage in “multistream” Janus
https://www.slideshare.net/LorenzoMiniero/multistream-in-janus-commcon-2019
21. VideoRoom usage in “multistream” Janus
https://www.slideshare.net/LorenzoMiniero/multistream-in-janus-commcon-2019
22. Multistream PeerConnections not as easy to cascade
• A single Streaming mountpoint per participant wouldn’t help
• It would force subscribers to create multiple PCs for receiving media
• Wouldn’t really take advantage of multistream functionality
• A multistream Streaming mountpoint wouldn’t help either
• A mountpoint is a pretty static component, and SFU participants are dynamic
• Different subscribers will want to subscribe to different resources
The solution: cascading the VideoRoom itself!
https://www.meetecho.com/blog/sfu-cascading/
23. Multistream PeerConnections not as easy to cascade
• A single Streaming mountpoint per participant wouldn’t help
• It would force subscribers to create multiple PCs for receiving media
• Wouldn’t really take advantage of multistream functionality
• A multistream Streaming mountpoint wouldn’t help either
• A mountpoint is a pretty static component, and SFU participants are dynamic
• Different subscribers will want to subscribe to different resources
The solution: cascading the VideoRoom itself!
https://www.meetecho.com/blog/sfu-cascading/
24. Multistream PeerConnections not as easy to cascade
• A single Streaming mountpoint per participant wouldn’t help
• It would force subscribers to create multiple PCs for receiving media
• Wouldn’t really take advantage of multistream functionality
• A multistream Streaming mountpoint wouldn’t help either
• A mountpoint is a pretty static component, and SFU participants are dynamic
• Different subscribers will want to subscribe to different resources
The solution: cascading the VideoRoom itself!
https://www.meetecho.com/blog/sfu-cascading/
25. Implementing the concept of “remote publishers”
• VideoRoom in Janus 1.x now supports so-called “remote publishers”
• Handled and advertised (via signalling) as local publishers, but actually remote
• Media coming from another VideoRoom (or server)
• RTP forwarders still used internally for the purpose
• Remote publishers can be part of a VideoRoom multistream subscription
• Subscribers can combine local and remote publishers in the same PeerConnection
• Remote publishers can be updated dynamically as well
• Tracks added/removed at remote source are notified to local subscribers via API
• Renegotiations and updates work transparently as well, as far as users are concerned
26. Implementing the concept of “remote publishers”
• VideoRoom in Janus 1.x now supports so-called “remote publishers”
• Handled and advertised (via signalling) as local publishers, but actually remote
• Media coming from another VideoRoom (or server)
• RTP forwarders still used internally for the purpose
• Remote publishers can be part of a VideoRoom multistream subscription
• Subscribers can combine local and remote publishers in the same PeerConnection
• Remote publishers can be updated dynamically as well
• Tracks added/removed at remote source are notified to local subscribers via API
• Renegotiations and updates work transparently as well, as far as users are concerned
27. Implementing the concept of “remote publishers”
• VideoRoom in Janus 1.x now supports so-called “remote publishers”
• Handled and advertised (via signalling) as local publishers, but actually remote
• Media coming from another VideoRoom (or server)
• RTP forwarders still used internally for the purpose
• Remote publishers can be part of a VideoRoom multistream subscription
• Subscribers can combine local and remote publishers in the same PeerConnection
• Remote publishers can be updated dynamically as well
• Tracks added/removed at remote source are notified to local subscribers via API
• Renegotiations and updates work transparently as well, as far as users are concerned
30. A caveat: remote publishers not really automated, for now
• Manual API requests needed on both sides to create a remote publisher
1 Create a remote publisher Y on Janus B (returns connectivity info)
2 Tell VideoRoom on Janus A to forward publisher X to VideoRoom on Janus B
3 Y (Janus B) is now an avatar of X (Janus A)
• Manual API requests also needed on recipient side for updates
• Janus B needs to know when a track is added/removed (to notify subscribers)
• RTP management already automated, instead
• A single port per publisher used, no matter how many streams they send
• SSRC multiplexing used for sending RTP packets to the remote side
• Simple math to calculate SSRC on both sides (and demultiplex incoming streams)
31. A caveat: remote publishers not really automated, for now
• Manual API requests needed on both sides to create a remote publisher
1 Create a remote publisher Y on Janus B (returns connectivity info)
2 Tell VideoRoom on Janus A to forward publisher X to VideoRoom on Janus B
3 Y (Janus B) is now an avatar of X (Janus A)
• Manual API requests also needed on recipient side for updates
• Janus B needs to know when a track is added/removed (to notify subscribers)
• RTP management already automated, instead
• A single port per publisher used, no matter how many streams they send
• SSRC multiplexing used for sending RTP packets to the remote side
• Simple math to calculate SSRC on both sides (and demultiplex incoming streams)
32. A caveat: remote publishers not really automated, for now
• Manual API requests needed on both sides to create a remote publisher
1 Create a remote publisher Y on Janus B (returns connectivity info)
2 Tell VideoRoom on Janus A to forward publisher X to VideoRoom on Janus B
3 Y (Janus B) is now an avatar of X (Janus A)
• Manual API requests also needed on recipient side for updates
• Janus B needs to know when a track is added/removed (to notify subscribers)
• RTP management already automated, instead
• A single port per publisher used, no matter how many streams they send
• SSRC multiplexing used for sending RTP packets to the remote side
• Simple math to calculate SSRC on both sides (and demultiplex incoming streams)
33. Improving the performance of the VideoRoom
• Cascading as done in Janus 0.x leverages Streaming plugin
• Streaming plugin optimized for broadcasting (via “helper threads”)
• Easy to serve the same mountpoint to many subscribers on the same instance
• Very helpful in webinar scenarios (or for our virtual event platform)
• Janus 1.x has remote publishers, but VideoRoom not suited for large audiences
• Does the job for small/medium conferences
• Relay logic may have some bottlenecks in critical paths
WIP: support for helper threads in VideoRoom as well
• https://github.com/meetecho/janus-gateway/pull/3067
• Automatically supported for both local and remote publishers
34. Improving the performance of the VideoRoom
• Cascading as done in Janus 0.x leverages Streaming plugin
• Streaming plugin optimized for broadcasting (via “helper threads”)
• Easy to serve the same mountpoint to many subscribers on the same instance
• Very helpful in webinar scenarios (or for our virtual event platform)
• Janus 1.x has remote publishers, but VideoRoom not suited for large audiences
• Does the job for small/medium conferences
• Relay logic may have some bottlenecks in critical paths
WIP: support for helper threads in VideoRoom as well
• https://github.com/meetecho/janus-gateway/pull/3067
• Automatically supported for both local and remote publishers
35. Improving the performance of the VideoRoom
• Cascading as done in Janus 0.x leverages Streaming plugin
• Streaming plugin optimized for broadcasting (via “helper threads”)
• Easy to serve the same mountpoint to many subscribers on the same instance
• Very helpful in webinar scenarios (or for our virtual event platform)
• Janus 1.x has remote publishers, but VideoRoom not suited for large audiences
• Does the job for small/medium conferences
• Relay logic may have some bottlenecks in critical paths
WIP: support for helper threads in VideoRoom as well
• https://github.com/meetecho/janus-gateway/pull/3067
• Automatically supported for both local and remote publishers
36. Thanks! Questions? Comments?
Get in touch!
• https://twitter.com/elminiero
• https://twitter.com/meetecho
• https://www.meetecho.com
