Are You Ready to Mumble..?

Last week, on Inworld Review, we talked Murmur with two guests. Cyberglo Cyberstar, famous for his scripting prowess and many wonderful free items on his grid Cyberdatastorm, runs a Mumble server on his grid, and he told us a bit about it. Opensim veteran Snowbody Cortes shared some general information about how Mumble could revolutionize opensim, and here are the slides he showed us during the program.

Inworld Review Studio

Snowbody Cortes:  I first got interested in Mumble in 2009 but at the time I didn't really think about it in terms of an overall service for virtual worlds. Back then, Mumble was less evolved than it is today. I did some standalone experiments, and I created a Murmur server that I shared with some SL friends, just to be able to have a communication channel that didn't use the usual things like Skype or WhatsApp.

For a long time, it seemed like the voice element in opensim was covered by Vivox, so I didn't really dedicate any time to thinking about Mumble. I was aware that there were various projects that were aimed at integrating Mumble into opensim use, and of course over recent years, it is becoming clear that the vivox solution for opensim voice is not a long term and reliable thing, it could go away any time; and of course we are grateful to them that they have provided this service to us for free for so many years.

Snowbody Cortes: When I heard there was going to be an edition of Inworld Review talking about Mumble for Opensim, I began thinking about strategies for bringing Mumble into Opensim in a way that would be low tech and easy for users to figure out, maybe just as an independent tool to be used in parallel with the virtual world, which was the way I had used it all those years ago. The best solution would be if Mumble was integrated into the Viewer, of course, so that the user doesn't have to do anything. That seemed a big ask... 

Snowbody Cortes: So, going from what would be the most simple way right up to the most sophisticated way to bring Mumble into opensim, I came up with 4 possibilities. That is what these slides illustrate, just to demonstrate the possibilities and to invite people to think about ways it might be made to work.
I'm not saying these are the only solutions, but more like a set of ideas that can be useful. Opensim is not a monolith. the people have lots of different needs and their own ideas about how they want to run their grids. and for sure, people with more detailed knowledge of opensimulator code may have a lot to contribute in terms of coming up with a module... but let me explain the basics first.

SLIDE 1

Mumble and Murmur are the 2 parts of the Mumble app. It's an open source, free, highly portable app with high quality audio without taking up a lot of bandwidth, particularly Murmur (the server part) doesn't need a lot of memory and cpu. so anyone can have one in their house, if they want, even on a Raspberry Pi.
Another big advantage is that it has written chat as well as voice, and both are encrypted.
On the downside, it uses its own communication protocols, so you cannot just simply swap Vivox and Mumble, and have it work. Please notice at the bottom of this slide, where it says 'tree of audio channels" - that is going to be important later on.

SLIDE 2

This slide shows how Vivox works, just to get us started.

In my opinion, there are 4 ways to use Mumble in Opensim.
As I said before, Opensim is not monolithic. People should be able to see all the choices they have and be aware that each solution, there is a certain amount of benefit, but also a corresponding amount of effort needed. 

SLIDE 3

On Slide 4, here below, you can see my 4 solutions of Mumble in a graphic similar to the Vivox layout, on Slide 2, so you can make a direct comparison. 
The best approach for the use of Mumble, in my view, is where grid owners run and control Murmur servers for their own grids. Smaller grids might want to share a murmur server. A murmur server can handle over 100 users all online at the same time, the main thing that could limit the capacity of the server is internet bandwidth.

SLIDE 4

In the next picture, Slide 5, you can see the first and most basic solution. The blue part of the picture  (the Viewer and Opensim) is not connected to the green part (the Mumble/Murmur part). 

SLIDE 5

Used like this, Mumble is an independent tool, in many ways like Discord or Skype or any other voip, except that you or someone you trust is in control of the server.
It's not connected to your Viewer, but even at this simplest level, you can use the characteristics of Mumble to make a tree of audio channels, a bit like you have on Discord, and you can have up to 10 levels of audio channels.
Users can be registered - even self-registered! -  that way they don't have to retype their pw and username every time they log in. Each audio channel in the tree is independent and can have its own rules and allowed people and sub channels. We'll come back to this 'tree' of channels later.

SLIDE 6

In Slide 6 you see solution 2, the opensim module or "Murmur meets Opensimulator code". I have hypothesized a possible way to add Mumble to opensim with an integration in Opensimulator code - Opensim server side - the idea here is to have communication between Opensimulator and the Murmur server using a module - (there are already many modules, like for example the physics module, or the one that makes gloebits work). This way, we would avoid the integration of Mumble into the Viewer, but you could make the information (av position, cam positions, what sim you are on) can be transmitted to the Murmur server and so you would get that immersive, 3d sensation. And joining to a specific audio channel would be automatic. in this case, like case 1, you still need to download the Mumble app and have it open alongside your Viewer.

It's possible to communicate with the Murmur server using an ICE channel, and the Murmur server can be controlled with an ICE channel with an RPC code based on PHP and a web server like Apache. This could be the way that the opensim module could interface with the murmur server.
It might be necessary to adapt the interface on the Murmur side. This channel between Murmur and Opensimulator is not protected by password and not encrypted, so that's something to think about. 

I suspect that the communication channel between Murmur and the opensim module could be the most grid-jumper friendly solution. 

You're not limited to using SQLite when you configure your Murmur database, you have options. And you can configure Murmur to allow only registered users to log in, and you can personalize things like the Welcome message, and the choice of which channel people will automatically be logged into when they first arrive. 

SLIDE 7

Slide 7 shows the third solution. This brings us a little bit closer to what Vivox currently does. I'll call it 'Mumble meets the Viewer' because it's based on an interface with the Viewer. There is a lot more that can be said about that, but basically this is the way online gamers currently use Mumble. It means you have to create a plugin for Mumble that can gather from the Viewer's memory all the info: position, cam, etc. 

This is the solution used in a lot of online games, like World of Warcraft, Call of Duty, and Final Fantasy, to name just three. You still need to have Mumble client, and you have to keep it open on your computer while you're using the opensim viewer. 

The disadvantages of this solution? Every viewer would need its own plugin, and every time they change the code with a new version of the viewer, there is always the risk that the Mumble plugin will need to be updated. 
A more sophisticated solution consists in modifying the viewer to create a standard interface and have a Mumble plugin able to dialog with that standard interface. This would be one interface for all opensim friendly viewers and all versions of them. With this solution, the Mumble plugin would be stable and have a longer life.

SLIDE 8

Slide 8 shows the 'Rolls Royce' solution, where the functionalities of the Mumble client are completely integrated into the Viewer. You don't have to have the Mumble client open. 

This would require a lot of effort and and support from Viewer devs, who would have to be convinced that it is worth their time. 

For the user, it would make the experience just like it is today with Vivox - only one interface, just the Viewer. It would do exactly what Vivox does now... but with a big difference, the servers controlling the exchange of information would be in the hands of grid owners, not Vivox. And, the communication is encrypted, both voice and chat.

Will it ever happen? Let's be optimistic but proactive in the meantime.

SLIDE 9

Slide 9 shows you how Mumble and Murmur can do most of the things Vivox already does, even with just that first, simplest solution. It makes sense to structure the audio channel into 4 main branches. A Service channel for the grid, one for Groups, one for private messages and one for general chat on a sim or a parcel. 

SLIDE 10

As far as I know, there are no pre-existing functions that automatically put the user into a particular audio channel. it's possible to imagine, for example, for the voice in a region or a parcel that there could be a scripted object on the land that invites people to click on a link that will take them to join the Mumble server specific for that place.

SLIDE 11

This is how you can manage people on the grid using different channels, so everyone is not talking over everyone else. You can be speaking in groups, or one on one. 

SLIDE 12

You can use the definition of the specific ACLs (access control lists) and Access Tokens to set rules about who can enter a group chat and who is controlling it.
 In conclusion, after going through this information, there's a lot of possibilities out there, and they are not that difficult to put into action. And every grid can choose the solution that they feel most comfortable with. 

As long as the Opensim user has downloaded Mumble onto their computer, they can communicate with others, whichever solution the grid owner prefers and more than that, they can continue to chat with friends even when they are out hypergridding - the chat link will not be lost. 

I'm not holding myself up as an expert, I have not dedicated more than a few days to thinking about this problem and so I'm sure there are many other thoughtful and active people out there who can build on these ideas and come up with other ideas, strategies and comments.