[tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Apr 24 19:35:59 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]
>
> anadahz worked on an [https://github.com/n0emis/ansible-role-
> bigbluebutton ansible role to install BBB].
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
* also, training sessions for people *outside* of 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 setup BBB using a [https://github.com/n0emis/ansible-role-
bigbluebutton ansible role to install BBB].
--
Comment (by anarcat):
i'm looking at a budget for hosting a BBB instance and it seems
bigbluebutton.org references 5 commercial service providers:
* http://blindsidenetworks.com/ - original authors, contacted by email
* http://international.imdt.com.br/ - consultants, contacted by email
* https://distancelearning.cloud/ - AKA HostBBB on the BBB website,
40USD/mth for 25 concurrent users, 150USD/100, 30-day trial
* https://mconf.com/en/ - have their own BBB derivatived (mconf),
contacted by email
* https://riadvice.tn/ - long-standing BBB contributors, hosting and
consulting, contacted by email
Hopefully that will give us an idea of the commercial side of things.
Also, correction: anadahz setup BBB *using* the Ansible role, they didn't
write it from scratch but provided patches to customize it.
There is no recent Puppet module for BBB:
https://forge.puppet.com/modules?q=big%20blue%20button I found an old
Puppet manifest for BBB 0.8 here: https://github.com/flyapen/puppet-
bigbluebutton
The numbers I have right now in terms of labour and hardware requirements
are:
* 2 vCPU and 4GB ram
* "1 day of work"
That does not include VoIP/dialin configuration and long term support. For
example, before next year, Ubuntu 16.04 will be EOL and the entire
platform will be upgraded, which could be a significant challenge in terms
of work and reliability.
We're having a meeting on monday to clarify the requirements on this
project.
What I want to see in the meeting:
1. discuss process
2. finalize requirements (e.g. self-hosted? number of participants?
scope)
3. establish timeline
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33700#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list