Mumble and the Bandwidth – Anonymous CB radio with Mumble and Tor

mumble and the bandwidth

The journey towards anonymous and secure voice communication is a long one. There’s lots of roadblocks to get your voice from point A to point B over the Internet if you need to prevent eavesdropping or censorship. There is the limited bandwidth of mobile data connections. There is the high latency of the TCP protocol. To achieve anonymity via Tor, there’s even more latency added to each packet.

Mumble is a non-standard protocol that was originally designed for realtime voice chat for video games. If you’ve ever played Halo or World of Warcraft, this should sound familiar. If not, think of it as a conference call you don’t have to ring. You simply connect to a Mumble server over the Internet and your voice will transmit to everyone else.

Mumble clients are available for Android and iOS, as well as a cross-platform desktop client. The server software is also cross-platform. Guardian Project is focusing on the Android client named Plumble and the official server backported to Debian stable.

A cool feature of Mumble is a Push To Talk (PTT) method to speak to the channel. Your voice is only transmitted when you press the PTT button in the user interface. Another lower level feature that’s important for our anonymity goal is TCP support. For any application to run over Tor, it must use the TCP protocol. This rules out most VoIP clients, since they use UDP. Here is a case where Mumble’s non-standard protocol works to our advantage.

When Tor is running and your Mumble client is configured to use TCP, connecting to your local SOCKS5 proxy offered by Tor allows you to join a Mumble server anonymously. The big problem is as suspected, latency. The traffic passing through the Tor network must make an indeterminate number of proxy hops to be anonymized successfully. Each hop adds more and more latency. This makes a typical syncronous voice call impossible since there’s no way to determine when one person has stopped talking and when the other can respond without interrupting.

Latency in human speech transmision has deep psychological impact on a conversation. A Japanese research project called SpeechJammer exploited this part of our senses by inventing a “shut up gun.” When pointed at a person it makes them immediately stop talking. Everyone who has used a cell phone knows the frustration of “echo” where you hear your own voice, slightly delayed. The delay is caused by the network latency of the cellular carrier.

Another similar example is a VoIP call on a congested network. The side effect of the latency is that one person accidently interrupts the other person because he thinks the other person has finished talking, when in reality the other person’s voice hasn’t yet arrived at the other end. Interruption ensues, no one is happy nor do they know anything new since the transmission was not understood. High latency makes full-duplex communication ineffective.

The contemporary telephone you are acustomed to allows both sides to talk and listen simultaneously. This is called full-duplex. Early radio telephones like walkie talkies, CB radio or aviation radio are half-duplex systems, meaning that for any given transmission, only one side can talk while the other side listens. Running Mumble over Tor takes a full-duplex technology and effectively reduces it to half-duplex. Even though the protocol is full-duplex, when run through a high latency network like Tor, the transmit and receive channels are so far out of sync there is no point in allowng both sides to talk at once. Again, interruption ensues.

Then it hit me. Radio telephones have been around since the turn of the 20th century, when people figured out a reasonable way to do voice chat without the technology causing accidental interruptions in the conversation. In particular, the use of procedure words, or prowords, are essential for one speaker to acknowledge the transmission of the other (Roger), to signify that one party is finished speaking (Over), or indicate when one party has left the conversation (Out).

Here in the USA, some prowords evolved into a coloquial language, complete with slang thanks to the Citizen Band radio boom of the 1960s and the truck driving culture that used it to communicate while on the road. The 1977 film Smokey and the Bandit is more than just a touching love story with world class actors, it is an amazing dramatization of an information culture that resembled pre-Internet BBS systems and current day Internet Relay Chat (IRC) networks around the globe. The truck drivers portrayed in that movie have a mobile, decentralized information sharing network that is anonymous. The users have pseudonyms and a language of their own. Many of them have never met their CB radio friends IRL. They are invisible companions on the lonely road of the US of A.


Old ideas are worth bringing back if they have strong roots. CB and general purpose radio telephones have a long history, unlike the standard the standard of tody, VoIP. Perhaps these features are thought of as obsolete or not cutting-edge enough to model into a digital system. Regardless of the reason, if you are looking for a mobile and open source PTT solution to use on the Internet with anonymity and security, Mumble over Tor is currently the state of the art. All you have to do is throw in some prowords to keep the conversation flowing.

The Guardian Project is operating a private Mumble server during a testing phase, and we have plans to open this to the public as part of the OSTN research effort. When that happens, I will post application-specific tutorials to install and configure the Plumble client. I will also publish a cookbook to build a Mumble server.

Finally, an example transmission log with some prowords:

Internet: Guardian Project. I have a ping response from your server, over.
GP: Roger Internet. Ping was sent, over.
Internet: Guardian Project. Build anonymous PTT system with open source software, over.
GP: Internet, build anonymous PTT system with open source software, wilco. Out.

11 comments for “Mumble and the Bandwidth – Anonymous CB radio with Mumble and Tor

  1. KLP
    2013/01/31 at 7:34 am

    Will Plumble allow for audio encryption to prevent eavesdropping at the server?

    • hans
      2013/02/01 at 10:16 am

      As far as I know, mumble relies on transport security, i.e. TLS with TCP sockets, so the server sees all the unencrypted audio. Also, since mumble is a multi-party protocol, it would need something like multi-party OTR, which, as far as we know, does not exist yet in any complete and usable form.

      • n8fr8
        2013/02/01 at 1:09 pm

        You are right, Hans, and in fact it would be multi-party ZRTP, which definitely does not exist.

      • Anonymous
        2013/02/01 at 1:10 pm

        Although it doesn’t use Tor, Redphone for Android by Moxie Marlinspike does encrypted phone calls over IP. They go via a server, but they’re still encrypted client to client so that the server is unable to access the audio. So it’s certainly possible.

        • Lee
          2013/02/02 at 1:17 pm

          Guardian Project also sponsors a VoIP project with similar goals to RedPhone called If you are looking for full-duplex voice with P2P authentication that is the best way to go. Mumble over Tor is a different model with different goals. Neither RedPhone nor are anonymous.

  2. 2013/02/01 at 1:20 am

    What is you opinion about more minimalistic IHU-project alternative

    • Abel Luck
      2013/02/02 at 1:35 pm

      IHU hasn’t had a commit in almost two years and seems to be abandonware, moreover it appears to use a homegrown crypto scheme of questionable security.

      Not sure how it negotiates the peer to peer stuff, looks cool, but completely non-standard.

  3. 2013/02/02 at 10:31 am

    I see the way multi-party voice chat using PGP (GPG).
    The server should only forward packets from one user to another. Each package should have a field of the source and the destination (or broadcast to forward it to all subscribers).
    Each user creates his session key to encrypt voice and can change it at any time.
    If a user receives a packet from the other and hasn’t the key to decrypt (or the current key does not valid), it asks for the key to sender, indicating the fingerprint of own pgp key. Server forwards the request. After receiving such a request, the sender of the package authenticates the user by fingerprint (eg, using the Internet service keys in manual mode) and optionally adds it to the trusted and sends the fingerprint of its PGP-key authentication and a key session by encrypting them with his public key. Server forwards the response to the user. User decrypts the packet with its private PGP key and can then listen to the subscriber’s voice mailbox, decoding them to his session key.

  4. 2013/02/04 at 6:55 am

    I did some tests now and have comments to the PTT mode.
    I used TCP socket with disabled Nagle algorithm to send packets, the data is sent in portions of 140 bytes every 80 mS for recipient’s hidden service.
    Absolute delivery delay of the first packet was less than the average delay for continuous transmission, but subsequent packets jitter was considerably greater.
    I noticed that at least 10-20 seconds of continuous delivery is kind of tunnel adaptation and reduced jitter. Still, the beginning of the sentence was interrupted, some packages rejected by codec due to significant jitter. In addition, after transmission some of the data remains in the channel during tens of seconds and and delivered immediately only after the start of the new transmission.
    In TORFone 0.2 I have provided the possibility of transferring some dummy packages after each voice packet to “push” it and saturate channel. Most likely, the dummy packages are also needed in voice chat, but it will significantly increase the load on the server.

  5. Pete
    2013/03/01 at 7:14 pm

    Please see this thread on the OTR-dev list where I discuss using code2, David Rowe’s very low bitrate digital radio codec (1200bps is pretty good!)

  6. OldEnoughToHaveACBHandle
    2013/04/04 at 1:02 pm

    CB’ers didn’t use prowords. They listened for the squelch or looked at the signal strength meter on the radio to know when the other guy released his mic button and it was okay to start talking. And NASA radio comms with astronauts don’t use them either because the radios add an automatic “over” beep at the end of each transmission.

    Now that PTT is supported the app could provide the same kind of automatic “transmitting” indication to the receivers so users don’t need to manually add the slow (and really hokey sounding) prowords.

Leave a Reply

Your email address will not be published. Required fields are marked *