Force push-to-talk on server

[dennis]

Hi

I need to force PTT on my server. How can I do that.

The suggest function is not enough.

[fwaggle]

You can't.

It's called a suggest function because that is all the assurance we can make, you can't ever force someone to use PTT. Anyone with a hex editor or the ability to build the software themselves could ignore it.

Decent moderators is about the only thing you can do - simply kick users who aren't using PTT until they get the message.

[dennis]

You just can't make it easy, can you!?

Maybe I can't force someone to use PTT but You could force them to be muted if they don't.

[fwaggle]

You just can't make it easy, can you!?

Maybe I can't force someone to use PTT but You could force them to be muted if they don't.

 

You really can't, unless you control the machine the user is on. Like I said, decent moderators and/or users who respect the rules is the only actual solution to this. A way to enforce PTT or any other client setting is writing checks we can't cash - it's akin to enforcing a user wear pants while they use the PC.

[dennis]

The audio stream goes to the server before it gets transferred to the other clients.

It can't be hard to mute audio from a user that doesn't have PTT enabled.

It should be the admin of the server who decides what the clients can do or not.

[Lindee]

Except, all the server knows is that there is audio being transmitted. It has no way of knowing what method the audio is being inputting in to mumble. As far as the server is concerned there is no difference between continuous, PTT, and voice activated.

That said, if properly setup, listeners should not be able to tell the difference between VA and PTT.

[dennis]

The client can be changed so it transfers that information to the server and the server need to be changed so it can handle that information.

This is the only thing that is bad with Mumble. It would be sweet if it got changed.

"...if properly setup, listeners should not be able to tell the difference between VA and PTT"

All the people on the server does not live alone. Children are noisy. TV and music and what not.

[Lindee]

As soon as you start transfering more information then Mumble is no longer Low-Latency and becomes as high latency as all the others.

[dennis]

Sending a few bits telling the server about PTT can't raise the latency notably.

Why not send the information while not talking!?

[Lindee]

Except it wouldn't be only a few bites. Its "a few bites" (if that few) per person per server instance. and it would have to poll a lot in order to stay up to date. The best would be if it polled every time the mic actives but that would create latency too as the server would have to turn around and allow the mic to pass audio.

I bet if it is something you are really interested in, you could run some sort of script in python and mumo to do this, but I'm guessing the appetite is not there from the devs to do this as it would probably be a huge resource and bandwith hog.

[fwaggle]

The audio stream goes to the server before it gets transferred to the other clients.

It can't be hard to mute audio from a user that doesn't have PTT enabled.

 

Except we can't assure that it will never happen that the client will lie and say it's using PTT when it's not. So us advertising functionality that "enforces PTT" is effectively a lie, we're promising things we can't deliver.

That's the entire reason behind the suggest* configuration knobs, because we can only suggest these things, and have no way of enforcing them. I could be overridden by one of the primary devs of course, but I can't see this ever changing. That is to say that from where I'm sitting, it will not ever happen that we will include so it's a waste of time arguing about it.

If your users' voice activation is being triggered by their kids or their TV, put them in a time out (admin mute, separate channel, whatever) until they fix their mic or switch to PTT. You can enforce this yourself with decent admins! If your users don't care enough about the people they talk with to not have kids shrieking in the background or the TV going, that's not really a software problem.

[dennis]

Except it wouldn't be only a few bites. Its "a few bites" (if that few) per person per server instance. and it would have to poll a lot in order to stay up to date. The best would be if it polled every time the mic actives but that would create latency too as the server would have to turn around and allow the mic to pass audio.

I bet if it is something you are really interested in, you could run some sort of script in python and mumo to do this, but I'm guessing the appetite is not there from the devs to do this as it would probably be a huge resource and bandwith hog.

 

You have no clue what you're talking about. At all.

I thought I was talking to someone who knows programming and networking.

[dennis]

The audio stream goes to the server before it gets transferred to the other clients.

It can't be hard to mute audio from a user that doesn't have PTT enabled.

 

Except we can't assure that it will never happen that the client will lie and say it's using PTT when it's not. So us advertising functionality that "enforces PTT" is effectively a lie, we're promising things we can't deliver.

That's the entire reason behind the suggest* configuration knobs, because we can only suggest these things, and have no way of enforcing them. I could be overridden by one of the primary devs of course, but I can't see this ever changing. That is to say that from where I'm sitting, it will not ever happen that we will include so it's a waste of time arguing about it.

If your users' voice activation is being triggered by their kids or their TV, put them in a time out (admin mute, separate channel, whatever) until they fix their mic or switch to PTT. You can enforce this yourself with decent admins! If your users don't care enough about the people they talk with to not have kids shrieking in the background or the TV going, that's not really a software problem.

 

All of these things worked like like a charm when I was using Teamspeak. They solved it. I stopped using Teamspeak because of licensing issues. Teamspeak is closed source, I know. But doing this is much better than not doing anything at all.

Mumble is sending mute and deafen information to the server. Sending PTT information should not be any problem to implement.

Actually.. The server is already sending PTT suggestion. Why just not make it enforcing.

All it has to do when the client gets this message is to mute the client on the serverside and show the message every time there is a noise.

The serverside then unmutes the client when a PTT enabled message is retrieved.

Edited November 17, 2015 by dennis

[fwaggle]

TS is making promises they can't keep then.

It's simply not possible to enforce it in any way client side - the client can always lie. Unless you disagree with this and can prove it with code, we're at an impasse.

[dennis]

TS is making promises they can't keep then.

It's simply not possible to enforce it in any way client side - the client can always lie. Unless you disagree with this and can prove it with code, we're at an impasse.

 

Do you really think that's a problem? That people fake this.

If one out of a thousand fakes this I guess it would be easy to ban this person.

If a hundred new people have to be informed and learned about how to configure this it's a problem.

[Geraner]

I would instead of forcing the whole server to use PTT, like to have this setting on the Channel Level instead. (ACL)

In this case the admin can select per channel whether PTT is forced or not.

If PTT is forced, users who not have PTT enabled can not access the channel.

The question is, what should happen if a user inside a PTT force channel is changing it's settings to not use PTT?

Maybe "User moved to pre-defined channel", or something similar.

This are just some thoughts I got regarding this discussed function. :) Feel free to comment.

[dennis]

I would instead of forcing the whole server to use PTT, like to have this setting on the Channel Level instead. (ACL)

In this case the admin can select per channel whether PTT is forced or not.

 

Yes, this would be even better.

 

If PTT is forced, users who not have PTT enabled can not access the channel.

The question is, what should happen if a user inside a PTT force channel is changing it's settings to not use PTT?

Maybe "User moved to pre-defined channel", or something similar.

This are just some thoughts I got regarding this discussed function. :) Feel free to comment.

 

Yes, an option for moving people to a predefined channel would be nice. Or, just mute the client serverside and present a message to the client that it needs to enable PTT.

[Geraner]

Or, just mute the client serverside and present a message to the client that it needs to enable PTT.

I agree, that would also be an alternative.

[Natenom]

What about a configuration option in the client like "obey ptt suggestion". Either per server (in the server edit dialog) or for all servers in the settings. Default is on and will set ptt and ask for a ptt button if not yet set, but one can always disable it.

[dennis]

What about a configuration option in the client like "obey ptt suggestion". Either per server (in the server edit dialog) or for all servers in the settings. Default is on and will set ptt and ask for a ptt button if not yet set, but one can always disable it.

You mean the client should be able to decide if it will obey the server settings or not?

What will happen is that people won't be able to talk on the server and when they find this option they will disable it and never touch it again.