This is the slide deck I presented at the first CommCon event in the UK: it goes through some of the possible strategies for scaling WebRTC applications, mostly if you're using Janus but not only.

1. Scaling server-side WebRTC applications:
the Janus challenge
Lorenzo Miniero
@elminiero
CommCon 2018
June 27th 2018, Wotton House, Surrey (UK)

2. Sorry Dan, pineapples on pizza = BIG NO

3. A picture of me as a kid for no reason
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Open source believer
Contacts and info
• lorenzo@meetecho.com
• https://twitter.com/elminiero
• https://www.slideshare.net/LorenzoMiniero

4. 1. No, I don’t know what happened...

5. 2. Yes, Police is still looking for who stole my cheeks

6. Ok, let’s stop clowning around...
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Open source believer
Contacts and info
• lorenzo@meetecho.com
• https://twitter.com/elminiero
• https://www.slideshare.net/LorenzoMiniero

7. What is Janus?
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

8. Modular architecture
• The core only implements the WebRTC stack
• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, ...
• Plugins expose Janus API over different “transports”
• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too
• Users attach to plugins via the Janus core
• The core handles the WebRTC stuff
• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”
• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.

9. Modular architecture
• The core only implements the WebRTC stack
• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, ...
• Plugins expose Janus API over different “transports”
• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too
• Users attach to plugins via the Janus core
• The core handles the WebRTC stuff
• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”
• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.

10. Modular architecture
• The core only implements the WebRTC stack
• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, ...
• Plugins expose Janus API over different “transports”
• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too
• Users attach to plugins via the Janus core
• The core handles the WebRTC stuff
• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”
• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.

11. Modular architecture
• The core only implements the WebRTC stack
• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, ...
• Plugins expose Janus API over different “transports”
• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too
• Users attach to plugins via the Janus core
• The core handles the WebRTC stuff
• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”
• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.

12. Extensible Architecture and API

13. Extensible Architecture and API

14. A quick look at plugins: SIP gateway

15. A quick look at plugins: RTP rebroadcaster

16. A quick look at plugins: Audio MCU

17. A quick look at plugins: Video SFU

18. The first step towards scaling: benchmarking
• Measuring Janus performance is not trivial...
• Different plugins have different behaviours
• Different technologies have different impact
• Need to focus on individual features
• SIP Gateway (SIP plugin)
• Multimedia streaming (Streaming plugin)
• Audio mixing (AudioBridge plugin)
• Video routing (VideoRoom plugin)
• ...
What about the results?1
• When just relaying, bandwidth is typically the real bottleneck
• Linear vs. exponential resource increase depends on plugin and topologies
1
https://janus.conf.meetecho.com/citeus

19. The first step towards scaling: benchmarking
• Measuring Janus performance is not trivial...
• Different plugins have different behaviours
• Different technologies have different impact
• Need to focus on individual features
• SIP Gateway (SIP plugin)
• Multimedia streaming (Streaming plugin)
• Audio mixing (AudioBridge plugin)
• Video routing (VideoRoom plugin)
• ...
What about the results?1
• When just relaying, bandwidth is typically the real bottleneck
• Linear vs. exponential resource increase depends on plugin and topologies
1
https://janus.conf.meetecho.com/citeus

20. The first step towards scaling: benchmarking
• Measuring Janus performance is not trivial...
• Different plugins have different behaviours
• Different technologies have different impact
• Need to focus on individual features
• SIP Gateway (SIP plugin)
• Multimedia streaming (Streaming plugin)
• Audio mixing (AudioBridge plugin)
• Video routing (VideoRoom plugin)
• ...
What about the results?1
• When just relaying, bandwidth is typically the real bottleneck
• Linear vs. exponential resource increase depends on plugin and topologies
1
https://janus.conf.meetecho.com/citeus

21. Beyond a single Janus instance: different strategies
• Once performance is evaluated, other aspects come into play
• Does a user stream need to stay within the plugin?
• Can it be sent to/received from somewhere else?
• Will this affect other connections?
• How much is the context important?
• What level of orchestration is needed?
• All those questions can lead to different answers/solutions, e.g.
1 Plain load balancing
2 Media resource brokering (MRB)
3 Sharing the “burden”
4 Cascaded delivery
5 ...

22. Beyond a single Janus instance: different strategies
• Once performance is evaluated, other aspects come into play
• Does a user stream need to stay within the plugin?
• Can it be sent to/received from somewhere else?
• Will this affect other connections?
• How much is the context important?
• What level of orchestration is needed?
• All those questions can lead to different answers/solutions, e.g.
1 Plain load balancing
2 Media resource brokering (MRB)
3 Sharing the “burden”
4 Cascaded delivery
5 ...

23. Plain load balancing
• The simplest strategy of them all
• You have N Janus instances available
• You allocate users on one according to some logic
• No orchestration needed, just knowledge of Janus addresses
• User has list vs. HAProxy vs. nginx vs. ...
• Logic can differ depending on the application
• Pick a random server?
• Use round robin?
• Pick the one closest to the user?
• Pick the least loaded?
• Something else and/or any combination of the above?

24. Plain load balancing
• The simplest strategy of them all
• You have N Janus instances available
• You allocate users on one according to some logic
• No orchestration needed, just knowledge of Janus addresses
• User has list vs. HAProxy vs. nginx vs. ...
• Logic can differ depending on the application
• Pick a random server?
• Use round robin?
• Pick the one closest to the user?
• Pick the least loaded?
• Something else and/or any combination of the above?

25. Plain load balancing
• The simplest strategy of them all
• You have N Janus instances available
• You allocate users on one according to some logic
• No orchestration needed, just knowledge of Janus addresses
• User has list vs. HAProxy vs. nginx vs. ...
• Logic can differ depending on the application
• Pick a random server?
• Use round robin?
• Pick the one closest to the user?
• Pick the least loaded?
• Something else and/or any combination of the above?

26. Plain load balancing examples

27. Plain load balancing examples

28. Plain load balancing examples

29. Plain load balancing limitations
• The only safe option is the SIP plugin
• All streams are independent of each other
• Even those that are related, are related via the SIP infrastructure
• It might work with the Streaming plugin...
• ... as long as you make sure the same mountpoints exist on all servers...
• ... and they’re all fed with the same data!
• With other plugins (e.g., AudioBridge or VideoRoom), it’s not as simple
• Users meant for the same room may end up on different servers
• ... unless the balancing component is aware of the context (“room”)
• What about hosting the same room on different servers?
• May work, but is also messy
• Different contexts, multiple signalling channels, events overhead

30. Plain load balancing limitations
• The only safe option is the SIP plugin
• All streams are independent of each other
• Even those that are related, are related via the SIP infrastructure
• It might work with the Streaming plugin...
• ... as long as you make sure the same mountpoints exist on all servers...
• ... and they’re all fed with the same data!
• With other plugins (e.g., AudioBridge or VideoRoom), it’s not as simple
• Users meant for the same room may end up on different servers
• ... unless the balancing component is aware of the context (“room”)
• What about hosting the same room on different servers?
• May work, but is also messy
• Different contexts, multiple signalling channels, events overhead

31. Plain load balancing limitations
• The only safe option is the SIP plugin
• All streams are independent of each other
• Even those that are related, are related via the SIP infrastructure
• It might work with the Streaming plugin...
• ... as long as you make sure the same mountpoints exist on all servers...
• ... and they’re all fed with the same data!
• With other plugins (e.g., AudioBridge or VideoRoom), it’s not as simple
• Users meant for the same room may end up on different servers
• ... unless the balancing component is aware of the context (“room”)
• What about hosting the same room on different servers?
• May work, but is also messy
• Different contexts, multiple signalling channels, events overhead

32. Plain load balancing limitations
• The only safe option is the SIP plugin
• All streams are independent of each other
• Even those that are related, are related via the SIP infrastructure
• It might work with the Streaming plugin...
• ... as long as you make sure the same mountpoints exist on all servers...
• ... and they’re all fed with the same data!
• With other plugins (e.g., AudioBridge or VideoRoom), it’s not as simple
• Users meant for the same room may end up on different servers
• ... unless the balancing component is aware of the context (“room”)
• What about hosting the same room on different servers?
• May work, but is also messy
• Different contexts, multiple signalling channels, events overhead

33. Plain load balancing limitations
• The only safe option is the SIP plugin
• All streams are independent of each other
• Even those that are related, are related via the SIP infrastructure
• It might work with the Streaming plugin...
• ... as long as you make sure the same mountpoints exist on all servers...
• ... and they’re all fed with the same data!
• With other plugins (e.g., AudioBridge or VideoRoom), it’s not as simple
• Users meant for the same room may end up on different servers
• ... unless the balancing component is aware of the context (“room”)
• What about hosting the same room on different servers?
• May work, but is also messy
• Different contexts, multiple signalling channels, events overhead

34. Media resource brokering
• A step above Plain load balancing
• You have N Janus instances available
• You allocate users based on logic AND context
• Orchestration needed, here
• You need to know which Janus instances are available...
• ... and which one is doing what
• Logic will differ depending on the context
• Before allocating users, you allocate the context itself (e.g., a conference room)
• Users are then sent wherever their context belongs to
• Unlike Plain load balancing, can be used for everything
• You just need to implement context awareness somehow, and track resources

35. Media resource brokering
• A step above Plain load balancing
• You have N Janus instances available
• You allocate users based on logic AND context
• Orchestration needed, here
• You need to know which Janus instances are available...
• ... and which one is doing what
• Logic will differ depending on the context
• Before allocating users, you allocate the context itself (e.g., a conference room)
• Users are then sent wherever their context belongs to
• Unlike Plain load balancing, can be used for everything
• You just need to implement context awareness somehow, and track resources

36. Media resource brokering
• A step above Plain load balancing
• You have N Janus instances available
• You allocate users based on logic AND context
• Orchestration needed, here
• You need to know which Janus instances are available...
• ... and which one is doing what
• Logic will differ depending on the context
• Before allocating users, you allocate the context itself (e.g., a conference room)
• Users are then sent wherever their context belongs to
• Unlike Plain load balancing, can be used for everything
• You just need to implement context awareness somehow, and track resources

37. Media resource brokering
• A step above Plain load balancing
• You have N Janus instances available
• You allocate users based on logic AND context
• Orchestration needed, here
• You need to know which Janus instances are available...
• ... and which one is doing what
• Logic will differ depending on the context
• Before allocating users, you allocate the context itself (e.g., a conference room)
• Users are then sent wherever their context belongs to
• Unlike Plain load balancing, can be used for everything
• You just need to implement context awareness somehow, and track resources

38. Media resource brokering use case
• Will work nicely with all plugins, if you manage the context
• Context may give more info to SIP balancing logic
• Conference rooms and Streaming mountpoints can be associated to instances
• Broadcasting with Streaming plugin...
• ... if MRB knows Janus X hosts mountpoint Y, it can send users there
• Conference rooms with AudioBridge and/or VideoRoom...
• New rooms can be “deployed” on a specific instance
• Attempts to join room Y can be sent to Janus instance responsible for it
• Won’t help much when the same resource needs to be scaled, though
• e.g., many small rooms vs. one very large room
• For that, some different approach is needed

39. Media resource brokering use case
• Will work nicely with all plugins, if you manage the context
• Context may give more info to SIP balancing logic
• Conference rooms and Streaming mountpoints can be associated to instances
• Broadcasting with Streaming plugin...
• ... if MRB knows Janus X hosts mountpoint Y, it can send users there
• Conference rooms with AudioBridge and/or VideoRoom...
• New rooms can be “deployed” on a specific instance
• Attempts to join room Y can be sent to Janus instance responsible for it
• Won’t help much when the same resource needs to be scaled, though
• e.g., many small rooms vs. one very large room
• For that, some different approach is needed

40. Media resource brokering use case
• Will work nicely with all plugins, if you manage the context
• Context may give more info to SIP balancing logic
• Conference rooms and Streaming mountpoints can be associated to instances
• Broadcasting with Streaming plugin...
• ... if MRB knows Janus X hosts mountpoint Y, it can send users there
• Conference rooms with AudioBridge and/or VideoRoom...
• New rooms can be “deployed” on a specific instance
• Attempts to join room Y can be sent to Janus instance responsible for it
• Won’t help much when the same resource needs to be scaled, though
• e.g., many small rooms vs. one very large room
• For that, some different approach is needed

41. Media resource brokering use case
• Will work nicely with all plugins, if you manage the context
• Context may give more info to SIP balancing logic
• Conference rooms and Streaming mountpoints can be associated to instances
• Broadcasting with Streaming plugin...
• ... if MRB knows Janus X hosts mountpoint Y, it can send users there
• Conference rooms with AudioBridge and/or VideoRoom...
• New rooms can be “deployed” on a specific instance
• Attempts to join room Y can be sent to Janus instance responsible for it
• Won’t help much when the same resource needs to be scaled, though
• e.g., many small rooms vs. one very large room
• For that, some different approach is needed

42. Media resource brokering examples

43. Media resource brokering examples

44. Media resource brokering examples

45. Media resource brokering examples

46. Sharing the “burden”
• A bit different from Brokering described before
• You have N Janus instances available
• You use one or more of them to serve the same context
• Again, orchestration needed here too
• You need to know which Janus instances are available...
• ... and which one is serving which “subset” of the resource
• Logic will differ depending on the resource
• You identify how you can “split” the resource (unrelated parts)
• Users are then sent where the resource “subset” is allocated
• Less flexible than Balancing and Brokering, and more specific
• Can greatly help optimize delivery scenarios, though, depending on the context

47. Sharing the “burden”
• A bit different from Brokering described before
• You have N Janus instances available
• You use one or more of them to serve the same context
• Again, orchestration needed here too
• You need to know which Janus instances are available...
• ... and which one is serving which “subset” of the resource
• Logic will differ depending on the resource
• You identify how you can “split” the resource (unrelated parts)
• Users are then sent where the resource “subset” is allocated
• Less flexible than Balancing and Brokering, and more specific
• Can greatly help optimize delivery scenarios, though, depending on the context

48. Sharing the “burden”
• A bit different from Brokering described before
• You have N Janus instances available
• You use one or more of them to serve the same context
• Again, orchestration needed here too
• You need to know which Janus instances are available...
• ... and which one is serving which “subset” of the resource
• Logic will differ depending on the resource
• You identify how you can “split” the resource (unrelated parts)
• Users are then sent where the resource “subset” is allocated
• Less flexible than Balancing and Brokering, and more specific
• Can greatly help optimize delivery scenarios, though, depending on the context

49. Sharing the “burden”
• A bit different from Brokering described before
• You have N Janus instances available
• You use one or more of them to serve the same context
• Again, orchestration needed here too
• You need to know which Janus instances are available...
• ... and which one is serving which “subset” of the resource
• Logic will differ depending on the resource
• You identify how you can “split” the resource (unrelated parts)
• Users are then sent where the resource “subset” is allocated
• Less flexible than Balancing and Brokering, and more specific
• Can greatly help optimize delivery scenarios, though, depending on the context

50. Sharing the “burden” use case
• A typical use case is larger conferences
• Many active participants, with many viewers
• The first step is identifying the resources, and how they’re related
• Publishers will send media: they don’t “depend” on each other
• Subscribers only receive media: they depend on a specific publisher
• Publishers can be the “subset”, here
• A large conference room becomes N 1-to-many smaller broadcasts
• Each publisher→subscribers distribution is allocated separately
• Controlling application makes sure that viewer picks streams from the right place
• Bob from Janus1, Alice from Janus2, Tom from Janus3, Jim from Janus2, ...

51. Sharing the “burden” use case
• A typical use case is larger conferences
• Many active participants, with many viewers
• The first step is identifying the resources, and how they’re related
• Publishers will send media: they don’t “depend” on each other
• Subscribers only receive media: they depend on a specific publisher
• Publishers can be the “subset”, here
• A large conference room becomes N 1-to-many smaller broadcasts
• Each publisher→subscribers distribution is allocated separately
• Controlling application makes sure that viewer picks streams from the right place
• Bob from Janus1, Alice from Janus2, Tom from Janus3, Jim from Janus2, ...

52. Sharing the “burden” use case
• A typical use case is larger conferences
• Many active participants, with many viewers
• The first step is identifying the resources, and how they’re related
• Publishers will send media: they don’t “depend” on each other
• Subscribers only receive media: they depend on a specific publisher
• Publishers can be the “subset”, here
• A large conference room becomes N 1-to-many smaller broadcasts
• Each publisher→subscribers distribution is allocated separately
• Controlling application makes sure that viewer picks streams from the right place
• Bob from Janus1, Alice from Janus2, Tom from Janus3, Jim from Janus2, ...

53. Sharing the “burden” use case
• A typical use case is larger conferences
• Many active participants, with many viewers
• The first step is identifying the resources, and how they’re related
• Publishers will send media: they don’t “depend” on each other
• Subscribers only receive media: they depend on a specific publisher
• Publishers can be the “subset”, here
• A large conference room becomes N 1-to-many smaller broadcasts
• Each publisher→subscribers distribution is allocated separately
• Controlling application makes sure that viewer picks streams from the right place
• Bob from Janus1, Alice from Janus2, Tom from Janus3, Jim from Janus2, ...

54. Sharing the “burden” example

55. Sharing the “burden” example

56. Sharing the “burden” example

57. Sharing the “burden” example

58. Sharing the “burden” example

59. RTP forwarding
• All strategies so far assume related streams stay together
• In smaller rooms, publishers and subscribers are all on the same server
• In larger rooms, only the publisher and its subscribers are on the same server
• No scenario where this relationship is broken
• Apart from SIP and Streaming, but those are different (legacy interop)
• How can streams from different servers interact?
• Janus plugins don’t talk to each other...
• ... and neither do different Janus instances!
RTP forwarding
A way to relay RTP behind the curtains, without WebRTC
• e.g., relay VideoRoom publisher’s media to a Streaming mountpoint

60. RTP forwarding
• All strategies so far assume related streams stay together
• In smaller rooms, publishers and subscribers are all on the same server
• In larger rooms, only the publisher and its subscribers are on the same server
• No scenario where this relationship is broken
• Apart from SIP and Streaming, but those are different (legacy interop)
• How can streams from different servers interact?
• Janus plugins don’t talk to each other...
• ... and neither do different Janus instances!
RTP forwarding
A way to relay RTP behind the curtains, without WebRTC
• e.g., relay VideoRoom publisher’s media to a Streaming mountpoint

61. RTP forwarding
• All strategies so far assume related streams stay together
• In smaller rooms, publishers and subscribers are all on the same server
• In larger rooms, only the publisher and its subscribers are on the same server
• No scenario where this relationship is broken
• Apart from SIP and Streaming, but those are different (legacy interop)
• How can streams from different servers interact?
• Janus plugins don’t talk to each other...
• ... and neither do different Janus instances!
RTP forwarding
A way to relay RTP behind the curtains, without WebRTC
• e.g., relay VideoRoom publisher’s media to a Streaming mountpoint

62. RTP forwarding
• All strategies so far assume related streams stay together
• In smaller rooms, publishers and subscribers are all on the same server
• In larger rooms, only the publisher and its subscribers are on the same server
• No scenario where this relationship is broken
• Apart from SIP and Streaming, but those are different (legacy interop)
• How can streams from different servers interact?
• Janus plugins don’t talk to each other...
• ... and neither do different Janus instances!
RTP forwarding
A way to relay RTP behind the curtains, without WebRTC
• e.g., relay VideoRoom publisher’s media to a Streaming mountpoint

63. RTP forwarding example

64. RTP forwarding example

65. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

66. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

67. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

68. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

69. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

70. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

71. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

72. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

73. While “plain” RTP, and not WebRTC?
• Why not use WebRTC to “move” media around?
• WebRTC uses RTP too, after all, and has a lot of useful stuff
• Orchestrated properly, you can have one Janus see another Janus as a WebRTC user
• Many reasons why we went for “plain” RTP, actually
1 Recipient may not be WebRTC compliant (e.g., FFmpeg script)
2 A lot of existing tools support RTP (and other things) natively
3 You may not need an encrypted stream (although RTP forwarders can do SRTP)
4 You may need to “feed” many recipients at the same time
5 Plain RTP is simpler to distribute in different topologies
6 You can take advantage of multicast networks easily
7 More in general, WebRTC has too much overhead for that

74. A specific scenario: broadcasting
• Tree topology with several levels
• Broadcaster is at the root
• Intermediate levels are relayers (RTP trunks)
• Attendees attached at edge nodes (WebRTC)
• Waterfalls and Valves
• Only one flow between related nodes
• Different encodings can be different flows
• Number of relay levels can vary
• No levels → Broadcaster feeding edge nodes directly
• 1-N levels → distribution network (unicast/simulcast)
SOLEIL
Streaming Of Large Scale Events over Internet cLouds

75. A specific scenario: broadcasting
• Tree topology with several levels
• Broadcaster is at the root
• Intermediate levels are relayers (RTP trunks)
• Attendees attached at edge nodes (WebRTC)
• Waterfalls and Valves
• Only one flow between related nodes
• Different encodings can be different flows
• Number of relay levels can vary
• No levels → Broadcaster feeding edge nodes directly
• 1-N levels → distribution network (unicast/simulcast)
SOLEIL
Streaming Of Large Scale Events over Internet cLouds

76. A specific scenario: broadcasting
• Tree topology with several levels
• Broadcaster is at the root
• Intermediate levels are relayers (RTP trunks)
• Attendees attached at edge nodes (WebRTC)
• Waterfalls and Valves
• Only one flow between related nodes
• Different encodings can be different flows
• Number of relay levels can vary
• No levels → Broadcaster feeding edge nodes directly
• 1-N levels → distribution network (unicast/simulcast)
SOLEIL
Streaming Of Large Scale Events over Internet cLouds

77. A specific scenario: broadcasting
• Tree topology with several levels
• Broadcaster is at the root
• Intermediate levels are relayers (RTP trunks)
• Attendees attached at edge nodes (WebRTC)
• Waterfalls and Valves
• Only one flow between related nodes
• Different encodings can be different flows
• Number of relay levels can vary
• No levels → Broadcaster feeding edge nodes directly
• 1-N levels → distribution network (unicast/simulcast)
SOLEIL
Streaming Of Large Scale Events over Internet cLouds

78. SOLEIL architecture: a simple overview

79. SOLEIL architecture: a simple overview

80. Another scenario: cascaded conferencing
• Multiple VideoRoom instances “feeding” each other
• Publisher on Janus X → relayed on other Janus instances too
• Users can subscribe even when not on Janus X
• Can be used for scaling purposes
• Potential audience of publisher goes beyond capabilities of single Janus instance
• Broadcasting seen before applied to conferencing, basically
• Very interesting for geographic access to rooms too, though
• Users always contact Janus closest to them
• Behind the scenes, the Janus instances exchange media for all publishers
• Typically, intra- and inter-datacenter network speed > Users network speed

81. Another scenario: cascaded conferencing
• Multiple VideoRoom instances “feeding” each other
• Publisher on Janus X → relayed on other Janus instances too
• Users can subscribe even when not on Janus X
• Can be used for scaling purposes
• Potential audience of publisher goes beyond capabilities of single Janus instance
• Broadcasting seen before applied to conferencing, basically
• Very interesting for geographic access to rooms too, though
• Users always contact Janus closest to them
• Behind the scenes, the Janus instances exchange media for all publishers
• Typically, intra- and inter-datacenter network speed > Users network speed

82. Another scenario: cascaded conferencing
• Multiple VideoRoom instances “feeding” each other
• Publisher on Janus X → relayed on other Janus instances too
• Users can subscribe even when not on Janus X
• Can be used for scaling purposes
• Potential audience of publisher goes beyond capabilities of single Janus instance
• Broadcasting seen before applied to conferencing, basically
• Very interesting for geographic access to rooms too, though
• Users always contact Janus closest to them
• Behind the scenes, the Janus instances exchange media for all publishers
• Typically, intra- and inter-datacenter network speed > Users network speed

83. Another scenario: cascaded conferencing

84. Another scenario: cascaded conferencing

85. A few words on nuts and bolts
• We use Docker A LOT in our deployments
• Even though Janus can deal with NATs, we do prefer it to have a public IP
• Host networking makes it tricky to place more instances on the same machine
• Pipework: assign a dedicated IP address to a container
https://github.com/jpetazzo/pipework
• Docker native macvlan network driver also allows you to assign custom IPs to
containers. We’ll move to it sooner or later...
• Several people (including us) using Janus in clustered environments (Docker
Swarm, Kubernetes, ...)
• Auto-scaling by spawning new replicas as needed
• Live monitoring of machines’ resources (e.g., CPU, # connections, bandwidth) drives
the deployment process

86. A few words on nuts and bolts
• We use Docker A LOT in our deployments
• Even though Janus can deal with NATs, we do prefer it to have a public IP
• Host networking makes it tricky to place more instances on the same machine
• Pipework: assign a dedicated IP address to a container
https://github.com/jpetazzo/pipework
• Docker native macvlan network driver also allows you to assign custom IPs to
containers. We’ll move to it sooner or later...
• Several people (including us) using Janus in clustered environments (Docker
Swarm, Kubernetes, ...)
• Auto-scaling by spawning new replicas as needed
• Live monitoring of machines’ resources (e.g., CPU, # connections, bandwidth) drives
the deployment process

87. A few words on nuts and bolts
• We use Docker A LOT in our deployments
• Even though Janus can deal with NATs, we do prefer it to have a public IP
• Host networking makes it tricky to place more instances on the same machine
• Pipework: assign a dedicated IP address to a container
https://github.com/jpetazzo/pipework
• Docker native macvlan network driver also allows you to assign custom IPs to
containers. We’ll move to it sooner or later...
• Several people (including us) using Janus in clustered environments (Docker
Swarm, Kubernetes, ...)
• Auto-scaling by spawning new replicas as needed
• Live monitoring of machines’ resources (e.g., CPU, # connections, bandwidth) drives
the deployment process

88. A real-world example

89. A real-world example

90. Thanks! Questions? Comments?
Contacts
• https://twitter.com/elminiero
• https://twitter.com/meetecho
• http://www.meetecho.com