Commercial Hosting

Mumble (and murmur) are open source, and therefore completely free of charge. However, to fully experience the quality of Mumble, a quality server with good network connection is needed. Home-based DSL or Cable servers are far from optimal, and do not scale to much more than 5-6 users.

We are therefore interrested in facilitating commercial hosting of murmur, to enable users who lack either the server hardware and network connection or the skill to compile and maintain murmur to use Mumble.

This page is specifically targeted at commercial hosting providers. This is where we'll present a short summary of murmur's expected resource requirements, and where you can edit it to provide us with information on what you need to make your job easier.

Murmur technical requirements

Murmur runs on any operating system where Qt can compile. At the moment, that is "most" UNIXes, Windows and MacOSX. Our internal testserver runs on Linux, and a binary version for Windows is included in the mumble installer.

Based on data from out testserver, murmur will use about 40 MB of virtual memory, of which about 4 MB are resident in physical memory.

As no processing is done serverside, we were not able to push even 1% of actual CPU usage with 4 users on a Xeon 3.4Ghz. We do see quite a few context switches though, so high quality network cards is likely a requirement.

Mumble uses VBR speex, and using the highest quality and lowest latency, the peak bandwidth is 65kbit/s per speaker per listener (with IP and UDP overhead). In other words, a server with 10 users and 1 user speaking will need to replicate the datastream 9 times, for a total of 65*9=585kbit/s outgoing bandwidth. If all 10 users speak at once, each stream has to be replicated 9 times, for a total of 65kbit/s*9*10=5.8 Mbit/s. Note that these are absolute worst-case scenarios, and the average bandwidth use is around 20-30 kbit/s during speech, multiplied by the number of listeners.

Licensing

Murmur and Mumble is GPL, which means that much like the Linux kernel, you are free to use it in commercial hosting without royalties. You are selling a service, not a program.

Requirements for Murmur for adoption by commercial providers

I'll note down what I can imagine commercial hosting providers would like to see implemented in murmur before they start offering it as a service. If you are a commercial provider, please comment on the below in the discussion (even if you agree, it helps to know we're on the right track), or add new sections.

Ability to limit number of users

As bandwidth scales mostly linearly with the number of users (as long as only one user talks at a time), it makes sense to have a price structure reflecting the ammount of concurrent users. I think the easiest way to facilitate this is to add a field for [code]MaxConcurrentUsers=X[/code] in murmur.ini, and then reject connections with an error message at that point. We'll reserve a slot for SuperUser so the "owner" can clean up if desired.

Ability to limit audio quality

Bandwidth scales with audio quality. While Mumble's worst-case (top quality, 20ms latency) peak is 65kbit/s with IP and UDP overhead, the best case (minimum quality, 80ms latency, no 3D info) is 11 kbit/s. A sensible middle ground is 40ms latency with medium quality audio, which is 25.8kbit/s peak. It would probably be very helpfull if the quality and latency could be controlled serverside, as a 8-user top-quality server uses as much bandwidth as a 16-user medium-quality server, especially since we can't really hear much of a difference between "high" and "medium".

Perhaps the easiest solution for this is to simply add [code]MaxVBRQuality=X[/code] and [code]MinimumFramesPerPacket[/code] to murmur.ini and have murmur communicate those limits to the clients. If the clients still send with higher quality or more packets-per-second, we'll silently discard them.

Update: Murmur 0.9.2 contains support for limiting the per-user incoming bandwidth, and it's up to each to each user how to divide that bandwidth between latency (more packets-per-second), audio quality (larger framesize) and 3D position information. New connections will be rejected with proper error messages if their current settings are too high. Bandwidth usage is measured, and if it exceeds the allowed value, clients are kicked. This avoids people recompiling the client without the limits, or just changing the quality settings after they connect.

No frills ACLs and Groups

The multi-channel ACL and Groups system in Mumble enables easy setup of linked channels that can match most any scenario. On the downside, it's also easy to mess up, especially if you're an inexperienced user. While this might ultimately be up to the hosting providers, we should probably provide a small example of how to use a webpage to "configure" a very basic access system, and give no users the actual "Write" bit, even the admin. This would allow those users who feel they are competent enough to log in with superuser and foul things up as much as they want, and will also allow for simple management for less sophisticated users.

SQL-Server

It would be nice to use Postgres as SQL-Storage for murmur. Please add another table ("servers") containing a list of all servers (id, name) and a column to each table indicating to which server the row belogs. All configuration parameters (from the ini file) should be moved into the SQL by creating a new table.

After starting the murmur process, it should read the "servers" table and spawn the subprocesses automatically. I've seen a "command"-table, so I guess it is possible to send murmur commands by inserting them into that table. It would be nice, if it's possible to add/modify/delete servers just by inserting some commands into a table.

This would make administration of murmur much more easier cause there is no need to create and maintain an extra process for all customers. A small webinterface or so for editing servers would be helpfull, too.

Hope this is an useful idea ...

Query Protocol

External querying of servers (ie, via UDP or TCP) to retrieve server information (name, number of people in the server, channel list, who's in what channel etc) would be a requirement so that people may monitor player statistics as well as allow customers to place the figures on their website (like Ventrilo / TeamSpeak 2).