The document discusses Janus, an open-source WebRTC server, highlighting its features and functionality, particularly regarding the videoroom plugin and SFU cascading. It details the transition from Janus 0.x to 1.x, which introduces multistream capabilities, enabling more flexible handling of media streams and remote publishers. The challenges related to cascading multistream connections and the need for manual API interactions are also addressed, along with planned improvements for performance optimization.

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

4. SFU functionality provided by the VideoRoom plugin
https://janus.conf.meetecho.com/docs/videoroom

5. Historically, different ways to scale Janus (and VideoRoom)
https://www.slideshare.net/LorenzoMiniero/scaling-webrtc-applications-with-janus

6. RTP forwarders played a key role
https://archive.fosdem.org/2020/schedule/event/janus/

7. RTP forwarders played a key role
https://archive.fosdem.org/2020/schedule/event/janus/

8. ... especially when coupled with the Streaming plugin
https://janus.conf.meetecho.com/docs/streaming

9. ... especially when coupled with the Streaming plugin
https://janus.conf.meetecho.com/docs/streaming

10. ... especially when coupled with the Streaming plugin
https://janus.conf.meetecho.com/docs/streaming

11. ... why not, maybe using multicast too!
https://www.slideshare.net/LorenzoMiniero/scaling-webrtc-deployments-with-multicast-ietf-110-mboned

12. Useful for large-scale broadcasting (e.g., via WHIP)
https://www.slideshare.net/LorenzoMiniero/whip-and-janus-iitrtc-2021

13. Useful for large-scale broadcasting (e.g., via WHIP)
https://www.slideshare.net/LorenzoMiniero/whip-and-janus-iitrtc-2021

14. ... but also plain SFU cascading

15. ... but also plain SFU cascading

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

28. Implementing the concept of “remote publishers”

29. Implementing the concept of “remote publishers”

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