Official Mumble VoIP Forums

Mumble Protocol Question

It crashed, it is bugged, ...
Hi ,

I have a very simple question.
The mumble TCP part of the protocol states that every package
has a header that includes a 2 byte type number and 4 byte load packet length.
Every protobuffer message has a unique 2 byte number.
However, i looked into the mumble sources.. but i can't seem to find where these numbers are defined.
I'm looking for the match between every protobuffer message name type and its unique number type.
Never mind. Found the ennumeration:

typedef enum {
Version, =0
UDPTunnel, =1
Authenticate, =2
Ping, =3
Reject, =4
ServerSync, =5
ChannelRemove, =6
ChannelState, =7
UserRemove, =8
UserState, =9
BanList, /* 10 */
TextMessage, =11
PermissionDenied, =12
ACL, =13
QueryUsers, =14
CryptSetup, =15
ContextActionAdd, =16
ContextAction, =17
UserList, =18
VoiceTarget, =19
PermissionQuery, /* 20 */
CodecVersion, =21
I'm using pdf file that describes the mumble protocol:
Mumble protocol 1.2.X reference (WIP)
Stefan Hacker, Mikko Rantanen
November 8, 2010

Busy on the client part.
Following that.. the ssl handshake has completed.. with the server.
I have send the version and authenticate. But then.. nothing happens.. i get nothing back from the server.
Connections are open. I have received the certificate.. is there something changed in the protocol sequence?

My program is now talking to the server and server has decided to talk back... i'm a happy man.
Next problem..

Is the UDP Voice Packet
I'm reading it from the tcp stream thus far.. as supported.

1 byte: Header byte : type/target Bit 1-3: Type, Bit 4-8: Target
varint : session The session number of the source user
varint : sequence

The above 3 i read succesfull. The varint has a variable length.
I noticed that the sequence is increased with steps of 2.. is that correct? (0 , 2 , 4, 6 etc)

Then the tricky part the audio part.
I first should get a terminator bit followed by 7 bits indicating the length of the audio part.
However, the length i get exceeds my total remaining message length.
Hence, i must be doing something wrong.. is the above still up-to-date?

The positional audio part.. i don't care about.
Ok.. solved that one too.

The protocol document is wrong..
Its first 7 bits are the length .. and the last one is the terminator.

Header = header & 0x7f
Would you be so kind to update the documentations when you are finished with your implementation. So future devs will not encounter the same problems.

Github is used when one wants to have commits added to the git repo.
Sure.. i see your using Tex... nice!

I updated the documentation..its pushed back.
Thank you.

If you have changes ready to be merged back feel free to create a pull request. There is a button/link at the top nav of your repo.
I did so this time.

Pull requests make it easier to see the pull requests, code changes (potentially) ready to be merged back.
Also, those not checking these forums can see the changes at a prominent location and pull back with a single button click on the github website.

Also, as I just see your commit does not have author information (unknown), you may want to set your author information in git if you will contribute more in the future.
See point 1 of the github help setup ... hub-token/
I didn't have time to look at the whole documentation but it seems like the bit order is assumed to be

Code: Select all

MSB 1|2|3|4|5|6|7|8 LSB
The header packet above is described the same way. A bit counter intuitive and definitely worth mentioning. I don't have time right now but, unless I forget, will take a closer look this weekend.