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:mee...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
