Channel Viewer Protocol

From Mumble Wiki
Revision as of 09:55, 11 May 2010 by Svedrin (Talk | contribs)

Jump to: navigation, search

People often wish to have a view on their Mumble servers without needing to actually run the client. This is mostly accomplished using a web based channel viewer which retrieves channel and user data from a web server, which in turn queries it from Murmur, and then using techniques like JavaScript to render that data into a nice tree structure.

As multiple channel viewers start to arise, developers found the consensus that using a standardized format for data retrieval yields multiple advantages, the most important of which is interoperability: The need for using a specific server and viewer does not arise when all servers and viewers use a shared data format, thus allowing for both parts to be exchanged easily and independent from one another.

General notes

The data format should generally be aimed towards delivering information retrieved from Murmur unaltered. That means that any field that exists in Murmur should be exposed by the server (unless there is a really good reason not to do so, like for passwords and the like), and it should not alter any fields that exist in Murmur to prevent confusion.

If the implementer of the protocol chooses to add extra information that does not originate from Murmur itself, these fields should be prefixed with "x-" in order to prevent name clashes (so for example, a custom field named "coolstuff" should be named "x-coolstuff" instead).

If a client encounters a field which it does not understand, it must ignore that field.

Example Channel tree

All examples are based on the following channel structure:

  • test server
    • newtesting
    • testing
      • htmlsubtesting - This channel has HTML elements in its description
        • subsubtesting
      • plainsubtesting - This channel has HTML elements in its description which are escaped and should NOT be evaluated
        • subsubtesting


JSON

To expose the full channel tree using JSON, start with the root channel and recursively add the users and data to it.

In order to make cross-site requests easier, the server must implement JSONP.

Server format

Channel format

A Channel entry must at least contain the following fields:

'description': ,
'id': 0,
'links': [],         // A list of IDs that name linked channels
'name': 'Root',
'parent': -1,
'users': [],         // A list of users in this channel
'position': 0,
'channels': [],      // A list of subchannels
'temporary': False

And may optionally contain:

'x-connecturl': 'mumble://somewhere/somechannel'

User format

A User entry must at least contain the following fields:

'channel': 40,
'deaf': False,
'mute': False,
'name': 'Yps0',
'selfDeaf': False,
'selfMute': False,
'session': 143,
'suppress': False,
'userid': 4,

And may optionally contain:

'address': (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 255, 192, 168, 0, 10),
'x-addrstring': '192.168.0.10',           // A nicely formatted version of the IP address (hostname, dotted quad, IPv6 notation)
'bytespersec': 6580,
'comment': ,
'context': ,
'identity': ,
'idlesecs': 0,
'onlinesecs': 161,
'os': 'Win',
'osversion': '5.1.2600.1',
'prioritySpeaker': False,
'release': '02071e',
'tcponly': False,
'x-texture': '/mumble/1/4/texture.png',   // A URL to retrieve the texture/avatar from
'version': 66051

Which fields to expose may depend on the user of the channel viewer, e.g. the IP adress may be shown to certain logged-in users only.