[tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

Fri Apr 24 16:58:47 UTC 2020

#33700: audio- and video-conferencing considerations
-------------------------------------------------+-------------------------
 Reporter:  anarcat                              |          Owner:  (none)
     Type:  project                              |         Status:
                                                 |  needs_revision
 Priority:  High                                 |      Milestone:
Component:  Internal Services/Services Admin     |        Version:
  Team                                           |
 Severity:  Major                                |     Resolution:
 Keywords:                                       |  Actual Points:
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Old description:

> With the rise of the coronavirus, even Tor, which generally works
> remotely, is affected because we were still having physical meetings from
> time to time, and we'll have to find other ways to deal with this.
>
> This ticket aims at establishing the problem space ("what we're trying to
> solve") and evaluate possible solutions ("what could fix it"). we could
> follow the sysadmin documentation template:
>
> https://help.torproject.org/tsa/howto/template/#Discussion
>
> which establishes the following criterion:
>
> = Goals
> == Must have
>
>  * video/audio communication for a group of people of approx 2-10 people
>  * specifically, work session for teams internal to TPI
>  * chat fallback
>  * have a mobile app
>  * allow people to call in by regular phone
>  * a way for one person to mute themselves
>  * long term maintenance costs covered
>
> == Nice to have
>
>  * Reliable video support. Video chat is nice, but most video chat
> systems usually require all participants to have video off otherwise the
> communication is sensibly lagged.
>  * usable to host a Tor meeting, which means more load (because possibly
> > 20 people) and more tools (like slide sharing or whiteboarding)
>  * respecting our privacy, peer to peer encryption or at least encrypted
> with keys we control
>  * free and open source software
>  * tor support
>
> == Non-goals
>

> = Approvals required
>
> = Proposed solution
>
> = Cost
>
> = Alternatives considered
>
> == mumble
>
> === features
>
>  * audio-only
>  * moderation
>  * multiple rooms
>  * native client for Linux, Windows, Mac, iOS, Android
>  * web interface https://github.com/Johni0702/mumble-web
>  * chat
>  * dial-in, unmaintained, might be broken:
> https://github.com/slomkowski/mumsi
>
> === installation
>
> there are two different puppet modules to setup mumble:
>
>     https://github.com/voxpupuli/puppet-mumble
>     https://0xacab.org/riseup-puppet-recipes/mumble
>
> still need to be evaluated, but i'd be tempted to use the voxpupuli
> module because they tend to be better tested and it's more recent
>
> == jitsi
>
> === installation
>
> ansible roles: https://code.immerda.ch/o/ansible-jitsi-meet/
> https://github.com/UdelaRInterior/ansible-role-jitsi-meet
>
> puppet module: https://gitlab.com/shared-puppet-modules-group/jitsimeet
>
> there's also a docker container and (messy) debian packages
>
> prometheus exporter: https://github.com/systemli/prometheus-jitsi-meet-
> exporter
>
> == Nextcloud
>
> systemli is using this ansible role to install coturn:
> https://github.com/systemli/ansible-role-coturn
>
> == BBB
>
> features:
>
>  * audio, video conferencing support
>  * [http://docs.bigbluebutton.org/support/faq.html#accessibility
> accesssible] with live closed captionning and support for screen readers
>  * whiteboarding and "slideshow" mode (to show PDF presentations)
>  * moderation tools
>  * chat box
>  * embedded etherpad
>  * dial-in support with Freeswitch
>  * should scale better than jitsi and NC, at least
> [http://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-
> users-can-bigbluebutton-support according to their FAQ]: "As a rule of
> thumb, if your BigBlueButton server meets the minimum requirements, the
> server should be able to support 150 simultaneous users, such as 3
> simultaneous sessions of 50 users, 6 x 25, etc. We recommend no single
> sessions exceed one hundred (100) users."
>
> i tested an instance setup by a fellow sysadmin and we had trouble after
> a while, even with two people, doing a screenshare. it's unclear what the
> cause of the problem was: maybe the server was overloaded. more testing
> required.
>
> === installation
>
> [https://docs.bigbluebutton.org/2.2/install.html based on unofficial
> Debian packages], requires Freeswitch for dialin, which doesn't behave
> well under virtualization (so would need a bare metal server). Requires
> Ubuntu 16.04, [https://github.com/bigbluebutton/bigbluebutton/issues/8978
> packages are closed source] (!),
> [https://github.com/bigbluebutton/bigbluebutton/issues/8861 doesn't
> support Debian] or
> [https://github.com/bigbluebutton/bigbluebutton/issues/8876 other]
> [https://github.com/bigbluebutton/bigbluebutton/issues/8956 distros]

New description:

 With the rise of the coronavirus, even Tor, which generally works
 remotely, is affected because we were still having physical meetings from
 time to time, and we'll have to find other ways to deal with this.

 This ticket aims at establishing the problem space ("what we're trying to
 solve") and evaluate possible solutions ("what could fix it"). we could
 follow the sysadmin documentation template:

 https://help.torproject.org/tsa/howto/template/#Discussion

 which establishes the following criterion:

 = Goals
 == Must have

  * video/audio communication for a group of people of approx 2-10 people
  * specifically, work session for teams internal to TPI
  * chat fallback
  * have a mobile app
  * allow people to call in by regular phone
  * a way for one person to mute themselves
  * long term maintenance costs covered

 == Nice to have

  * Reliable video support. Video chat is nice, but most video chat systems
 usually require all participants to have video off otherwise the
 communication is sensibly lagged.
  * usable to host a Tor meeting, which means more load (because possibly >
 20 people) and more tools (like slide sharing or whiteboarding)
  * respecting our privacy, peer to peer encryption or at least encrypted
 with keys we control
  * free and open source software
  * tor support

 == Non-goals

 = Approvals required

 = Proposed solution

 = Cost

 = Alternatives considered

 == mumble

 === features

  * audio-only
  * moderation
  * multiple rooms
  * native client for Linux, Windows, Mac, iOS, Android
  * web interface https://github.com/Johni0702/mumble-web
  * chat
  * dial-in, unmaintained, might be broken:
 https://github.com/slomkowski/mumsi

 === installation

 there are two different puppet modules to setup mumble:

     https://github.com/voxpupuli/puppet-mumble
     https://0xacab.org/riseup-puppet-recipes/mumble

 still need to be evaluated, but i'd be tempted to use the voxpupuli module
 because they tend to be better tested and it's more recent

 == jitsi

 === installation

 ansible roles: https://code.immerda.ch/o/ansible-jitsi-meet/
 https://github.com/UdelaRInterior/ansible-role-jitsi-meet

 puppet module: https://gitlab.com/shared-puppet-modules-group/jitsimeet

 there's also a docker container and (messy) debian packages

 prometheus exporter: https://github.com/systemli/prometheus-jitsi-meet-
 exporter

 == Nextcloud

 systemli is using this ansible role to install coturn:
 https://github.com/systemli/ansible-role-coturn

 == BBB

 features:

  * audio, video conferencing support
  * [http://docs.bigbluebutton.org/support/faq.html#accessibility
 accesssible] with live closed captionning and support for screen readers
  * whiteboarding and "slideshow" mode (to show PDF presentations)
  * moderation tools
  * chat box
  * embedded etherpad
  * dial-in support with Freeswitch
  * should scale better than jitsi and NC, at least
 [http://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-
 users-can-bigbluebutton-support according to their FAQ]: "As a rule of
 thumb, if your BigBlueButton server meets the minimum requirements, the
 server should be able to support 150 simultaneous users, such as 3
 simultaneous sessions of 50 users, 6 x 25, etc. We recommend no single
 sessions exceed one hundred (100) users."

 i tested an instance setup by a fellow sysadmin and we had trouble after a
 while, even with two people, doing a screenshare. it's unclear what the
 cause of the problem was: maybe the server was overloaded. more testing
 required.

 === installation

 [https://docs.bigbluebutton.org/2.2/install.html based on unofficial
 Debian packages], requires Freeswitch for dialin, which doesn't behave
 well under virtualization (so would need a bare metal server). Requires
 Ubuntu 16.04, [https://github.com/bigbluebutton/bigbluebutton/issues/8978
 packages are closed source] (!),
 [https://github.com/bigbluebutton/bigbluebutton/issues/8861 doesn't
 support Debian] or
 [https://github.com/bigbluebutton/bigbluebutton/issues/8876 other]
 [https://github.com/bigbluebutton/bigbluebutton/issues/8956 distros]

 anadahz worked on an [https://github.com/n0emis/ansible-role-bigbluebutton
 ansible role to install BBB].

--

Comment (by anarcat):

 anadahz has an ansible role for BBB!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33700#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online