[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations
#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
>
> === 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
>
> 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).
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
=== 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
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).
--
Comment (by anarcat):
added details on mumble - there's a web interface!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33700#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs