Bug#682698: alternatives to mumble
On 30/08/12 23:56, Chris Knadle wrote:
> On Thursday, August 30, 2012 14:51:06, Daniel Pocock wrote (to #682010):
>> This is not a comment in support of or against Mumble, rather, it is
>> looking beyond Mumble
>>
>> A few weeks ago I put up a wiki page about alternatives to mumble:
>>
>> http://wiki.debian.org/AlternativesToMumble
>>
>> and I've put up an ITP (sponsor needed) for SylkServer (supports SIP,
>> Jabber and IRC conferencing)
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698
>>
>> Ultimately, the widespread deployment of standards-based solutions (such
>> as SylkServer and others mentioned in the wiki) should eliminate any
>> need for anyone to run Mumble and then celt can be put to rest.
>
> What originally drew me to Mumble was:
>
> a) it was built on Qt and has clients for Linux/Windows/Mac
> (i.e. is cross-platform)
SIP and Jabber servers don't come with their own clients: rather, it is
choose-your-own-client (e.g. Jitsi, Empathy, Ekiga, Google Talk,
Lumicall, SipDroid, Polycom phone, etc,...)
> b) is free-as-in-freedom software
SIP and Jabber products vary in `free'-ness. Some are GPL, some are BSD
licensed. Some codecs are patented (but the code is available for you
to experiment with, e.g. G.729, SILK). Asterisk is dual-licensed, some
people don't like contributing back to such a code base.
It is possible to build 100% Free solutions though.
> c) is encrypted for both voice and text communication (simple and
> automatic in the user sense)
This varies. Most Jabber servers (e.g. ejabberd) support TLS. Leading
SIP proxies (e.g. reSIProcate/repro and Kamailio) support TLS. The
leading softphones and hardphones support SRTP and ZRTP. They all
inter-operate.
However, there are some weaker implementations, like Asterisk, which
doesn't do client-side cert verification and has been a bit troublesome
from time to time (see the open bugs)
> d) it has a 3D overlay for popular videogames to allow seeing
> who is talking
This is unique to Mumble. Some conferencing servers aim to provide
equivalent dashboards, some even allow the moderator to see things like
the wifi signal strength and latency for each participant. I'm not sure
if any of the free ones have all of that.
> e) it was easy to set up
That is what I've aimed to replicate with packaging repro, it is a hell
of a lot easier than deploying Asterisk. It needs to be paired with
something like SylkServer for conferencing though - hopefully the
SylkServer packages will also be easy enough for people to get them
running in 5-10 minutes.
> f) has ACL rules for specifying user privileges
Most SIP and Jabber products have some kind of ACL system, but they
vary. Asterisk can do quite a lot (e.g. blocking some users from
dialing abroad), but it takes a lot more effort to learn and configure.
> I initially needed a VoIP solution for a group of gamers who were running
> multiple platforms. Mumble fits that need well in that there are different
> "channels" one can join, similar to chatrooms, which can be done quickly with
> just a couple of mouse clicks. Mumble has no provision for making phone
> calls, which has its pros and cons. To connnect to a Mumble server from the
> client, one generally only needs a single DNS name or an IP address (although
> it's possible to change the default port and/or to require a password for
> entry to the server).
>
>
> I caught your DebConf12 talk "Free (as in freedom) communications, VoIP and
> messaging":
>
> http://penta.debconf.org/dc12_schedule/events/933.en.html
>
> from this it seemed like making connections required knowing particular email
> addresses to make connections, and I didn't see any discussion concerning
> chatroom communications. It's thus not immediately clear to me what the user
This varies slightly between SIP and Jabber
Jabber has multi-user-chat (MUC), a dedicated IRC like feature. Chat
room addresses look like email addresses. Empathy and psi support this
using the ejabberd server (they all exist in Debian).
With both SIP and Jabber, from any client, you dial a peer that looks
like an email address. That peer may be another real user, or it may be
an application. A conference is such an application. Therefore, you
could set up a conference at sip:meetme@pocock.com.au and people would
`dial' that address from any SIP device and they would be part of the
conference. If it was served by Asterisk, it could ask for a PIN, etc.
Other servers provide their own auth mechanisms. FreeSWITCH can even
bridge text-to-speech from IRC into a conference.
> impact would be concerning switching from Mumble to one of the alternatives.
> If you could give a brief description of the (general) connection and chatroom
> choosing process of the alternatives, that would at least give me a 'gut feel'
> for whether they might be fitting. The alternatives are obviously more
> versitile, but that comes with some complication on both the client and server
> side, which raises the 'barrier-to-entry' a bit.
>
I agree that some of the VoIP products are a pain to learn and setup
However, I'm addressing that with some of the things I'm packaging:
http://www.opentelecoms.org/federated-voip-quick-start-howto
Thanks for your feedback on these issues. I'm familiar with the mentors
site and have brought some of my other packages through there already.
I'll let you know when SylkServer is ready to try, waiting on some
upstream tweaks before finishing off the packaging.
Reply to: