Murmur "Opcode" for TCP Mode Only

[Omicron]

I am currently running a Murmur server and I am wanting to restrict it down a bit. Luckily, it looks like I can modify the server source to restrict the connection to a single version only (aka, only one version, not higher or lower.)

However, I am also wanting to force all clients to only use the TCP port without them having to either set the property manually, or waiting until their client makes the decision and forces them into TCP mode.

Is there a command/opcode that I can send via Murmur's TCP connection to tell the clients to go ahead and only use TCP only upon connection? There is no setting or flag I can see to set this, and this would also require something already implemented on the client to understand such a code.

Thanks!

P.S., this is already looking way better than Flagship's overcontrolled product. We can't host pro Vent servers ourself? Gimme a break.

[fwaggle]

Dropping all UDP packets should cause the clients to fall back to UDP automatically (but it'll be noisy, with a warning each connection, and it may take a second or two to take effect).

I don't really know why you'd want to though - TCP is really a regression for voice communication using any advanced codec. We run with low latency and the codec simply works around lost packets, continuing on with varying degrees of noise depending on the number of lost packets - with TCP mode and the default jitter buffer, you'll end up with pauses and then delayed audio and you're effectively wasting one of the best parts of CELT/OPUS. So I'm curious as to why you'd want this?

Also note the nomenclature of the suggestVersion and friends - it's not really possible to "force" these things, and the settings are so-named to avoid implying it's possible. Mumble's open source software, any user could simply modify a client to send what the server is expecting and there went all your ability to enforce such things (except the no-UDP thing, obviously, because you can enforce that at the firewall). For example restricting the version, that's probably trivially worked around with a hex editor if you don't feel like setting up a build environment.

[Omicron]

For the version thing, that is definitely a complete consideration. The main reason is for simplicity on behalf of the "standard" user, not to restrict someone with more complex knowledge from exploiting around the restriction.

If the user understands the protocol enough to modify their client to send the version I want, then more power to him/her. Absolutely no issues there, this is just to restrict the average user to an approved version of the client.

For the TCP part, this definitely impacts the advantages that UDP has for Mumble (completely understood.) However, I am in an environment where average communication is restricted to TCP only. Mumble/Murmur automatically understand to switch over in the way I have it configured, but as mentioned, it is very messy/noisy.

It would be nice to have an elegant solution to just have Murmur send the client a "hey, we're TCP only here, go ahead and switch over" message.

Murmur has no configuration/switch for this, but if Mumble's protocol has something hidden away that I can use, I might just modify Murmur's code to send a message and benefit from this.

On an unrelated note, when in TCP mode, are the voice packets encrypted in their standard method and then reencrypted again in the TCP stream?

Thanks.

[fwaggle]

It would be nice to have an elegant solution to just have Murmur send the client a "hey, we're TCP only here, go ahead and switch over" message.

Murmur has no configuration/switch for this, but if Mumble's protocol has something hidden away that I can use, I might just modify Murmur's code to send a message and benefit from this.

 

I don't think it does, it's my understanding all the TCP/UDP switching code is completely client-side and based entirely off pings being received back from the server. If I'm wrong, someone should chime in at some point.

 

On an unrelated note, when in TCP mode, are the voice packets encrypted in their standard method and then reencrypted again in the TCP stream?

 

I believe they're only encrypted once, whichever way they go. I'm not 100% certain on that either though.

Sorry I can't be of more help.

[Omicron]

To be honest, your replies are extremely helpful and I appreciate your assistance beyond what I can convey through text.

I can't get a single straight answer out of the people on the Ventrilo forums, it's absolutely pathetic. It's like they could care less about their archaic product and opening up a little... I mean, you can't even let free servers private chat? What an absolute joke.

This software lets me have the option for a TCP mode for voice "assurance," and even lets me choose the encryption method via OpenSSL. If the software does not have a switchover or anything similar, we'll probably just modify the code (imagine that, a VOIP software you can actually edit to your needs.) It is just sometimes simpler to say "go download version blah.blah," instead of providing the client yourself (but not a big deal.)

The effort put into this project is immensely appreciated.

[mkrautz]

In TCP mode, the voice packets are only encrypted once, via the TLS transport.

[Omicron]

In TCP mode, the voice packets are only encrypted once, via the TLS transport.

 

Thank you, that's actually what I was hoping.