For example, suppose players of Mission1's 'Team1' want to put together a secret plan, unknown to 'Team2'. As a Mumble server attracts more and more users for more and more advanced use, it can sometimes become desirable to restrict this merging of a Link Community's conversations. Referring to the diagram immediately above, it would be easy for a Mumble Administrator to create one Link Community for Mission1 with its Children, and a second Link Community for Mission2 with its Children, so that players participating in those missions can communicate within their own mission, regardless of the team they have joined, without interfering with the other mission.Ĭhannel Links of this type are, however, unsophisticated they merge ALL conversations within the Link Community. Within one of these Link Communities, all conversations are heard by everybody in any of the Linked Channels. Two or more Linked Channels of this type are known as 'Link Communities'. By joining a Mumble Channel and then right-clicking on the name of one of its Children or Descendants, a Mumble Administrator is presented with a menu option that can be used to 'Link' them. Mumble allows this through a tool that it calls 'Channel Links'.

In this larger situation supporting two different Missions, it might be desirable for everybody participating in Mission1 to communicate with one another in one large group, without interfering with conversations associated with Mission2, and vice versa. For example, suppose that the simple Channel Hierarchy shown in the prior example grows into a larger Channel Hierarchy like this: Even though all three of these Mumble Channels have an obvious Hierarchical relationship, conversations within one of them are still isolated from the others unless additional Mumble tools are put into place.Ĭhannel Links: After a Mumble server grows enough to support several channels, it is sometimes desirable for two or more channels to be 'Linked' so that their conversations can be shared. Following the same pattern, the Channel named 'Team2' has one Parent ('Mission1') and one Sibling ('Team1'). The Channel named 'Team1' has one Parent ('Mission1') and one Sibling ('Team2'). In that example, the Channel named 'Mission1' has two Children, named 'Team1' and 'Team2'. Here is a picture of a very simple Channel Hierarchy: In large Mumble Channel hierarchies, we might refer to a channel's 'Ancestors' and 'Descendants', and we might refer to the common ancestry between two related Channels according to the number of 'Generations' back to a common Ancestor. The depth of this Parents/Children hierarchy can continue to grow. This can go on for several 'Generations', so that one Channel can be the Child of its Parent and it can also be the Parent of its own Children. Channels can have 'Children', 'Parents', and 'Siblings'. In these simple situations, conversations within one Channel are not heard in any of the other Channels.Ĭhannel Hierarchies: Related Mumble Channels can be organized Hierarchically, like members of a family.

As simple Mumble servers attract more users, it is commonplace for them to be expanded with several distinct Channels, allowing different groups of people to isolate their conversations within those distinct Channels. In its most basic configuration, Mumble servers create just one Channel, and all users communicate with one another simultaneously by entering and speaking within that channel. In order to understand those tools, it's essential to understand certain fundamental terms as follows:Ĭhannel: The most basic tool for separating Mumble conversations is the 'Channel'. Mumble has a rich and powerful set of tools for controlling access. 5.1 Channel Group - Speak to children but not siblings.3.2 Channel Passwords and Access Tokens.

Mumble access token