This document discusses strategies for turning live events into virtual events using Janus. It begins by introducing Janus and its uses for streaming live events over WebRTC. It then discusses new challenges that arise for virtual events compared to live events, such as ensuring active participation from remote attendees. The document considers options for scheduling virtual events, whether to use pre-recorded or live presentations, and how to leverage Janus and other tools to broadcast events at scale over WebRTC or HLS. It proposes that SFUs and MCUs can be used together to optimize streaming based on factors like bandwidth and device capabilities.
OpenShift Commons Paris - Choose Your Own Observability Adventure
Turning live events to virtual with Janus
1. Turning live events to virtual with Janus
Lorenzo Miniero
@elminiero
CommCon 2020
July, from my couch at home
2. Who am I?
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://soundcloud.com/lminiero
10. What about the impact on business?
• Co-founded in 2009 as an academic spin-off
• University research efforts brought to the market
• Completely independent from the University
• Focus on real-time multimedia applications
• Strong perspective on standardization and open source
• Several activities
• Consulting services
• Commercial support and Janus licenses
• Streaming of live events (IETF, ACM, etc.)
11. What about the impact on business?
• Co-founded in 2009 as an academic spin-off
• University research efforts brought to the market
• Completely independent from the University
• Focus on real-time multimedia applications
• Strong perspective on standardization and open source
• Several activities
• Consulting services
• Commercial support and Janus licenses
• Streaming of live events (IETF, ACM, etc.)
12. What about the impact on business?
• Co-founded in 2009 as an academic spin-off
• University research efforts brought to the market
• Completely independent from the University
• Focus on real-time multimedia applications
• Strong perspective on standardization and open source
• Several activities
• Consulting services
• Commercial support and Janus licenses
• Streaming of live events (IETF, ACM, etc.)
13. Streaming live events via WebRTC
• Service we provided for several different events
• Mainly IETF (official remote participation tool) and some ACM conferences
• A few other events too (a growing business)
• Typically involved some specific activities
• Fly a couple people + equipment there, of course
• Setup cameras, split/capture projector signals, hook to room mixer
• Embed some event-specific channel (e.g., Twitter feed, or Sli.do channel)
• ... and then stream everything via WebRTC (sometimes allowing remote speakers)
Until the world changed...
No more live events in person for a while!
14. Streaming live events via WebRTC
• Service we provided for several different events
• Mainly IETF (official remote participation tool) and some ACM conferences
• A few other events too (a growing business)
• Typically involved some specific activities
• Fly a couple people + equipment there, of course
• Setup cameras, split/capture projector signals, hook to room mixer
• Embed some event-specific channel (e.g., Twitter feed, or Sli.do channel)
• ... and then stream everything via WebRTC (sometimes allowing remote speakers)
Until the world changed...
No more live events in person for a while!
15. Streaming live events via WebRTC
• Service we provided for several different events
• Mainly IETF (official remote participation tool) and some ACM conferences
• A few other events too (a growing business)
• Typically involved some specific activities
• Fly a couple people + equipment there, of course
• Setup cameras, split/capture projector signals, hook to room mixer
• Embed some event-specific channel (e.g., Twitter feed, or Sli.do channel)
• ... and then stream everything via WebRTC (sometimes allowing remote speakers)
Until the world changed...
No more live events in person for a while!
34. Moving to Virtual Events: new challenges
• Remote participants are not 2nd class citizens anymore...
• ... they’re the only ones there!
• You can’t assume remote participants will just lurk anymore
• Most than often, virtual event != webinar “on steroids”
• Active participation much more important than before
• A “broken” remote speaker will break the whole presentation
• Interaction with remote speakers can take different forms
• Sometimes important for them to have little delay
• Even if you won’t let them speak, they’ll need ways to interact
• And don’t you miss hallway conversations or social dinners?
35. Moving to Virtual Events: new challenges
• Remote participants are not 2nd class citizens anymore...
• ... they’re the only ones there!
• You can’t assume remote participants will just lurk anymore
• Most than often, virtual event != webinar “on steroids”
• Active participation much more important than before
• A “broken” remote speaker will break the whole presentation
• Interaction with remote speakers can take different forms
• Sometimes important for them to have little delay
• Even if you won’t let them speak, they’ll need ways to interact
• And don’t you miss hallway conversations or social dinners?
36. Moving to Virtual Events: new challenges
• Remote participants are not 2nd class citizens anymore...
• ... they’re the only ones there!
• You can’t assume remote participants will just lurk anymore
• Most than often, virtual event != webinar “on steroids”
• Active participation much more important than before
• A “broken” remote speaker will break the whole presentation
• Interaction with remote speakers can take different forms
• Sometimes important for them to have little delay
• Even if you won’t let them speak, they’ll need ways to interact
• And don’t you miss hallway conversations or social dinners?
37. Moving to Virtual Events: new challenges
• Remote participants are not 2nd class citizens anymore...
• ... they’re the only ones there!
• You can’t assume remote participants will just lurk anymore
• Most than often, virtual event != webinar “on steroids”
• Active participation much more important than before
• A “broken” remote speaker will break the whole presentation
• Interaction with remote speakers can take different forms
• Sometimes important for them to have little delay
• Even if you won’t let them speak, they’ll need ways to interact
• And don’t you miss hallway conversations or social dinners?
38. Moving to Virtual Events: new challenges
• Remote participants are not 2nd class citizens anymore...
• ... they’re the only ones there!
• You can’t assume remote participants will just lurk anymore
• Most than often, virtual event != webinar “on steroids”
• Active participation much more important than before
• A “broken” remote speaker will break the whole presentation
• Interaction with remote speakers can take different forms
• Sometimes important for them to have little delay
• Even if you won’t let them speak, they’ll need ways to interact
• And don’t you miss hallway conversations or social dinners?
39. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
40. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
41. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
42. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
43. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
44. How to schedule a Virtual event?
• With a live event, that’s easy
• People on site meet for a few days and present
• Schedule tied to whatever the location timezone is (for remotes too)
• With Virtual events there’s no “site”, though
• If everyone’s remote, timezone clashes can happen more easily
• Session slots may conflict with work-related commitments
• Different schools of thought on how to solve this
1 Just move the same on-site schedule online?
2 Maybe fewer talks per day, and a longer event?
3 Dynamic sessions that fit the timezones of most attendees?
45. Pre-recorded or live?
• There’s not a one-size-fits-all answer here
• Different solutions to different problems
• A truly live event seems the obvious answer
• Can feel closer to a “traditional” event schedule
• Live interaction with audience not always needed, but nice to have
• Pre-recording allows for more control on the end result, though
• Speakers can record on their own time, and fix mistakes
• Post-processing allows for higher quality output (yay CommCon!)
• Live interaction still possible after the talk (e.g., live Q&A)
• In both cases, though, WebRTC will most likely be used
46. Pre-recorded or live?
• There’s not a one-size-fits-all answer here
• Different solutions to different problems
• A truly live event seems the obvious answer
• Can feel closer to a “traditional” event schedule
• Live interaction with audience not always needed, but nice to have
• Pre-recording allows for more control on the end result, though
• Speakers can record on their own time, and fix mistakes
• Post-processing allows for higher quality output (yay CommCon!)
• Live interaction still possible after the talk (e.g., live Q&A)
• In both cases, though, WebRTC will most likely be used
47. Pre-recorded or live?
• There’s not a one-size-fits-all answer here
• Different solutions to different problems
• A truly live event seems the obvious answer
• Can feel closer to a “traditional” event schedule
• Live interaction with audience not always needed, but nice to have
• Pre-recording allows for more control on the end result, though
• Speakers can record on their own time, and fix mistakes
• Post-processing allows for higher quality output (yay CommCon!)
• Live interaction still possible after the talk (e.g., live Q&A)
• In both cases, though, WebRTC will most likely be used
48. Pre-recorded or live?
• There’s not a one-size-fits-all answer here
• Different solutions to different problems
• A truly live event seems the obvious answer
• Can feel closer to a “traditional” event schedule
• Live interaction with audience not always needed, but nice to have
• Pre-recording allows for more control on the end result, though
• Speakers can record on their own time, and fix mistakes
• Post-processing allows for higher quality output (yay CommCon!)
• Live interaction still possible after the talk (e.g., live Q&A)
• In both cases, though, WebRTC will most likely be used
49. Leveraging Janus for the purpose
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
51. Broadcasting: WebRTC or HLS?
• Again, there’s not a simple answer
• If low latency and/or live interaction are important, then obviously WebRTC!
• Otherwise, you may want to let a CDN worry about scalability
• With WebRTC, most of the times you can just relay media
• Much less impact on the server-side CPU resources (no/few mixing/transcoding)
• Scaling the WebRTC part is up to you, though
• With a CDN, you need a single audio/video stream to distribute
• Will require some mixing/transcoding, so dedicated resources
• Once you create the stream, though, scaling is up to the CDN (not-my-problemTM
!)
52. Broadcasting: WebRTC or HLS?
• Again, there’s not a simple answer
• If low latency and/or live interaction are important, then obviously WebRTC!
• Otherwise, you may want to let a CDN worry about scalability
• With WebRTC, most of the times you can just relay media
• Much less impact on the server-side CPU resources (no/few mixing/transcoding)
• Scaling the WebRTC part is up to you, though
• With a CDN, you need a single audio/video stream to distribute
• Will require some mixing/transcoding, so dedicated resources
• Once you create the stream, though, scaling is up to the CDN (not-my-problemTM
!)
53. Broadcasting: WebRTC or HLS?
• Again, there’s not a simple answer
• If low latency and/or live interaction are important, then obviously WebRTC!
• Otherwise, you may want to let a CDN worry about scalability
• With WebRTC, most of the times you can just relay media
• Much less impact on the server-side CPU resources (no/few mixing/transcoding)
• Scaling the WebRTC part is up to you, though
• With a CDN, you need a single audio/video stream to distribute
• Will require some mixing/transcoding, so dedicated resources
• Once you create the stream, though, scaling is up to the CDN (not-my-problemTM
!)
54. Can SFUs and MCUs be friends?
• SFUs ideal to just relay media
• No mixing/transcoding to worry about −→ less CPU on server, less delay
• More streams to distribute −→ more bandwidth needed
• Different streams −→ more control on UI
• MCUs ideal to just mix media
• Mixing/transcoding taking place −→ more CPU on server, more delay
• Just one stream to distribute −→ bandwidth constant
• Single output stream −→ UI rendering constrained
• Sometimes it makes sense to use them both!
• Use SFU where applicable (e.g., video, plenty of bandwidth)
• Use MCU to complement (e.g., audio, lower power devices)
• Besides, an MCU can mix SFU streams to broadcast to a CDN!
55. Can SFUs and MCUs be friends?
• SFUs ideal to just relay media
• No mixing/transcoding to worry about −→ less CPU on server, less delay
• More streams to distribute −→ more bandwidth needed
• Different streams −→ more control on UI
• MCUs ideal to just mix media
• Mixing/transcoding taking place −→ more CPU on server, more delay
• Just one stream to distribute −→ bandwidth constant
• Single output stream −→ UI rendering constrained
• Sometimes it makes sense to use them both!
• Use SFU where applicable (e.g., video, plenty of bandwidth)
• Use MCU to complement (e.g., audio, lower power devices)
• Besides, an MCU can mix SFU streams to broadcast to a CDN!
56. Can SFUs and MCUs be friends?
• SFUs ideal to just relay media
• No mixing/transcoding to worry about −→ less CPU on server, less delay
• More streams to distribute −→ more bandwidth needed
• Different streams −→ more control on UI
• MCUs ideal to just mix media
• Mixing/transcoding taking place −→ more CPU on server, more delay
• Just one stream to distribute −→ bandwidth constant
• Single output stream −→ UI rendering constrained
• Sometimes it makes sense to use them both!
• Use SFU where applicable (e.g., video, plenty of bandwidth)
• Use MCU to complement (e.g., audio, lower power devices)
• Besides, an MCU can mix SFU streams to broadcast to a CDN!
57. A simple use case to start with: podcasts
• Not strictly speaking a Virtual event, but close enough
• One or more people talking, and a (wide?) audience
• During Covid, many podcasts done remotely (e.g., "Conan needs a friend")
• WebRTC a good fit for the conversation part
• Easy to have a chat just using your browser
• Broadcasting could be done with WebRTC too!
• May make sense to have the conversation mixed, though
• If broadcasting with WebRTC, the more the speakers, the more the bandwidth
• If NOT broadcasting with WebRTC, you need a mix to transcode anyway
• More control on additional media (e.g., themes, clips, ads, etc.)
• How to optimize mixing with the ability to bring people in in a scalable way?
58. A simple use case to start with: podcasts
• Not strictly speaking a Virtual event, but close enough
• One or more people talking, and a (wide?) audience
• During Covid, many podcasts done remotely (e.g., "Conan needs a friend")
• WebRTC a good fit for the conversation part
• Easy to have a chat just using your browser
• Broadcasting could be done with WebRTC too!
• May make sense to have the conversation mixed, though
• If broadcasting with WebRTC, the more the speakers, the more the bandwidth
• If NOT broadcasting with WebRTC, you need a mix to transcode anyway
• More control on additional media (e.g., themes, clips, ads, etc.)
• How to optimize mixing with the ability to bring people in in a scalable way?
59. A simple use case to start with: podcasts
• Not strictly speaking a Virtual event, but close enough
• One or more people talking, and a (wide?) audience
• During Covid, many podcasts done remotely (e.g., "Conan needs a friend")
• WebRTC a good fit for the conversation part
• Easy to have a chat just using your browser
• Broadcasting could be done with WebRTC too!
• May make sense to have the conversation mixed, though
• If broadcasting with WebRTC, the more the speakers, the more the bandwidth
• If NOT broadcasting with WebRTC, you need a mix to transcode anyway
• More control on additional media (e.g., themes, clips, ads, etc.)
• How to optimize mixing with the ability to bring people in in a scalable way?
60. A simple use case to start with: podcasts
• Not strictly speaking a Virtual event, but close enough
• One or more people talking, and a (wide?) audience
• During Covid, many podcasts done remotely (e.g., "Conan needs a friend")
• WebRTC a good fit for the conversation part
• Easy to have a chat just using your browser
• Broadcasting could be done with WebRTC too!
• May make sense to have the conversation mixed, though
• If broadcasting with WebRTC, the more the speakers, the more the bandwidth
• If NOT broadcasting with WebRTC, you need a mix to transcode anyway
• More control on additional media (e.g., themes, clips, ads, etc.)
• How to optimize mixing with the ability to bring people in in a scalable way?
67. Adding video: the “webinar” scenario
• Mostly a one-to-many scenario
• A single presenter (maybe more than one video, e.g., screensharing)
• Multiple passive viewers
• Can sometimes be “conversational” like a podcast, though
• e.g., Q&A session, interview, or panel discussion
• As before, WebRTC definitely a good fit for publishing
• Browsers support screensharing natively
• Broadcasting could be done with WebRTC too! (but more streams, now)
• Video(s) may or may not be mixed
• In both cases, still needs to be distributed to all participants
68. Adding video: the “webinar” scenario
• Mostly a one-to-many scenario
• A single presenter (maybe more than one video, e.g., screensharing)
• Multiple passive viewers
• Can sometimes be “conversational” like a podcast, though
• e.g., Q&A session, interview, or panel discussion
• As before, WebRTC definitely a good fit for publishing
• Browsers support screensharing natively
• Broadcasting could be done with WebRTC too! (but more streams, now)
• Video(s) may or may not be mixed
• In both cases, still needs to be distributed to all participants
69. Adding video: the “webinar” scenario
• Mostly a one-to-many scenario
• A single presenter (maybe more than one video, e.g., screensharing)
• Multiple passive viewers
• Can sometimes be “conversational” like a podcast, though
• e.g., Q&A session, interview, or panel discussion
• As before, WebRTC definitely a good fit for publishing
• Browsers support screensharing natively
• Broadcasting could be done with WebRTC too! (but more streams, now)
• Video(s) may or may not be mixed
• In both cases, still needs to be distributed to all participants
70. Adding video: the “webinar” scenario
• Mostly a one-to-many scenario
• A single presenter (maybe more than one video, e.g., screensharing)
• Multiple passive viewers
• Can sometimes be “conversational” like a podcast, though
• e.g., Q&A session, interview, or panel discussion
• As before, WebRTC definitely a good fit for publishing
• Browsers support screensharing natively
• Broadcasting could be done with WebRTC too! (but more streams, now)
• Video(s) may or may not be mixed
• In both cases, still needs to be distributed to all participants
76. Bringing it all together for Virtual Events
• Virtual Events platform designed to “borrow” some concepts from before
• Mixing for audio streams, SFU mode for video streams
• Unlike before, AudioBridge used as the audio MCU now
• “Podcast” scenario applied to Virtual event
• Scalable thanks to RTP forwarding and Streaming plugin
• VideoRoom still used as the video SFU, instead
• “Webinar” scenario applied to Virtual event
• RTP forwarding and Streaming plugin used here too to make it scalable
All orchestration and RTP “magic” transparent users
• Participants talk to orchestrator, not Janus instances
• Docker, Docker, everywhere!
77. Bringing it all together for Virtual Events
• Virtual Events platform designed to “borrow” some concepts from before
• Mixing for audio streams, SFU mode for video streams
• Unlike before, AudioBridge used as the audio MCU now
• “Podcast” scenario applied to Virtual event
• Scalable thanks to RTP forwarding and Streaming plugin
• VideoRoom still used as the video SFU, instead
• “Webinar” scenario applied to Virtual event
• RTP forwarding and Streaming plugin used here too to make it scalable
All orchestration and RTP “magic” transparent users
• Participants talk to orchestrator, not Janus instances
• Docker, Docker, everywhere!
78. Bringing it all together for Virtual Events
• Virtual Events platform designed to “borrow” some concepts from before
• Mixing for audio streams, SFU mode for video streams
• Unlike before, AudioBridge used as the audio MCU now
• “Podcast” scenario applied to Virtual event
• Scalable thanks to RTP forwarding and Streaming plugin
• VideoRoom still used as the video SFU, instead
• “Webinar” scenario applied to Virtual event
• RTP forwarding and Streaming plugin used here too to make it scalable
All orchestration and RTP “magic” transparent users
• Participants talk to orchestrator, not Janus instances
• Docker, Docker, everywhere!
79. Bringing it all together for Virtual Events
• Virtual Events platform designed to “borrow” some concepts from before
• Mixing for audio streams, SFU mode for video streams
• Unlike before, AudioBridge used as the audio MCU now
• “Podcast” scenario applied to Virtual event
• Scalable thanks to RTP forwarding and Streaming plugin
• VideoRoom still used as the video SFU, instead
• “Webinar” scenario applied to Virtual event
• RTP forwarding and Streaming plugin used here too to make it scalable
All orchestration and RTP “magic” transparent users
• Participants talk to orchestrator, not Janus instances
• Docker, Docker, everywhere!
89. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
90. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
91. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
92. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
93. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
94. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)
95. What about hallway conversations?
• Definitely one of the things I personally miss the most...
• Hallway conversations, social gatherings, dinners can be fun
• It’s not just work: great people make great events!
• Harder to translate to the “virtual” world
• No scheduling, much more dynamic, lacks human feel and “contact”
• Number of interactions can have huge impact on scalability
• A few different ways to handle this, though
1 Several small-ish P2P conversations?
2 Possibly involve an SFU for larger ones?
3 An “explorable” space with avatars to trigger conversations?
4 Why not, maybe even VR! (e.g., via Hubs or vrlandio)