mumble-voip
Force PTT (Push to talk) in server settings
I tried to find this (admittedly, not very hard) and did not find it. We have a couple members that refuse to stop using open mic and it is rather bothersome to some member when these people are burping, crunching chips, using pc speakers, or any other number of things that will play back thru the mic. Would this be a possible option that could be added? or is this not possible due to the communication privileges from server to client or vice versa?
now, i am sure that the knee jerk reaction will be that we should mute them and try to get them to be responsible. but, remember that these are not tech savvy people we are dealing with. we are talking about people who expect a program to "just work" and not just work the way you want it they want it to "just work" they way they think it should. asking them to set any thing will be tantamount to telling them to uninstall it and go to some other voice software. and aside from that muting them will be the same as kicking them as they will not join the voice chat at all after that. not having people in voice gets difficult after you have grown accustomed to being able to give directions and information verbally.
p.s. sorry i don't know where the tag system is
The closest option is suggestPushToTalk=true which merely outputs a single line to the Mumble log.
I agree though, it would be very nice to have this kind of option.
Necroing this issue, but it would be nice to be able to set this in ACL as mentioned in #2718, probably the best way to do it.
Hi. I'm an undergrad student looking to contribute to my first open source project. I have C++ experience but have never used Qt. Would I be able to implement this?
Yes, the implementation should be easy enough. However, I think that it'd be best to revise the current draft of how this feature ought to work first. I don't really like the server-config option nor the ACL suggestions. The former seems too coarse-grained to me and the latter just feels wrong as forcing a particular transmission mode has nothing to do with "access control lists".
My suggestion would therefore be to introduce a new concept of a ChannelProperty that for the time being contains only a flag indicating whether or not PTT is forced in that channel.
The easiest would be to have this strictly on a per-channel basis, but I suspect users would like this property to apply to a tree of channels.Though, this could also be a future extension once the per-channel setting is implemented.
Thoughts?
That seems reasonable. It also does seem very similar to how the ACL system is structured, but also I understand that it is distinct (it doesn't take user permissions under account). That could be useful though, if you wanted to have some users who are required to use PTT while other users aren't.
Some more questions:
- What happens when a user switches transmission modes when in one of these channels? I have a keyboard hotkey bound to cycle transmission modes, and it seems like the client should at least log that the cycle was blocked by channel permission settings.
- Would the settings GUI lock down the setting when in one of these channels?
- Would the client auto switch to PTT when joining one of these channels?
- What happens if this property is applied to the default channel? Can the user even join the server?
Excellent points. In the end I think I still don't feel exactly comfortable letting the server force client-side settings to a particular value. Your questions are (I would say) more or less manifestations of the server getting involved with things that are ultimately purely client-side stuff.
In my opinion, if you have users that are unable/unwilling to open the settings to change their transmission mode, then you would also have a problem with those users if the client forced PTT on them as then they'd have to open the settings and figure out the default keybind for PTT (which atm we don't even have, so they'd have to configure a custom keybind).
Could someone provide an argument in favor of this feature that details how it gains more than it costs (in term of initial implementation and ongoing maintenance)?
Maybe the least disruptive way is to just have non-PTT users force-muted by server in PTT channel, perhaps with a client side error message or notification if it detects attempted voice transmission then? Maybe the notification goes in the chat box, with a minor sound, and a quick link or button that will set it to PTT mode, too.
That would avoid most of the issues, I think --- the user still has to be the one to choose PTT; cycling transmit modes is fine, you just can't talk unless it's on PTT; joining a PTT-only server just means you can't talk until you switch to PTT.
Also has the advantage that if you're on a server with lotsa people just listening, they can stay on their usual settings if they don't want to talk anyways.
Personally I'd prefer the client sending its transmission mode to the server when talking, and let the server decide whether the incoming voice should be blocked, or the user should be muted and notified, rather than attempting to disable certain client feature by server flags.
But that may require another UDP packet scheme change, so meh.
Additionally the current Suggest thing is sorta useless, because it only outputs one line to the terminal, and usually people will not notice that. It'll be far better if the transmission mode is automatically set to PTT when logging into the server on the first time, or pop a messagebox for it.
Personally I'd prefer the client sending its transmission mode to the server when talking, and let the server decide whether the incoming voice should be blocked, or the user should be muted and notified, rather than attempting to disable certain client feature by server flags.
But that may require another UDP packet scheme change, so meh.
In addition to requiring a change to the UDP scheme (which nowadays wouldn't be such a big deal as we have switched to using protobuf for that as well) this would cause a bunch of unnecessary server traffic.
Additionally the current Suggest thing is sorta useless, because it only outputs one line to the terminal, and usually people will not notice that. It'll be far better if the transmission mode is automatically set to PTT when logging into the server on the first time, or pop a messagebox for it.
I agree that it should create a messagebox - that is orthogonal to this specific feature request though. I created https://github.com/mumble-voip/mumble/issues/5979 to track that.
Maybe the least disruptive way is to just have non-PTT users force-muted by server in PTT channel, perhaps with a client side error message or notification if it detects attempted voice transmission then?
This :point_up: I like this suggestion a lot! :+1:
For this we'd need to implement a new TCP message type that the client sends to the server to inform it about its current transmission mode (and changes thereof) and then the server can use standard methods to force-mute the client if appropriate and also send a message to the client.
@AntonioNarra are you still interested to work on this?
Personally I'd prefer the client sending its transmission mode to the server when talking, and let the server decide whether the incoming voice should be blocked, or the user should be muted and notified, rather than attempting to disable certain client feature by server flags.
But that may require another UDP packet scheme change, so meh.
In addition to requiring a change to the UDP scheme (which nowadays wouldn't be such a big deal as we have switched to using protobuf for that as well) this would cause a bunch of unnecessary server traffic.
Additionally the current Suggest thing is sorta useless, because it only outputs one line to the terminal, and usually people will not notice that. It'll be far better if the transmission mode is automatically set to PTT when logging into the server on the first time, or pop a messagebox for it.
I agree that it should create a messagebox - that is orthogonal to this specific feature request though. I created #5979 to track that.
Maybe the least disruptive way is to just have non-PTT users force-muted by server in PTT channel, perhaps with a client side error message or notification if it detects attempted voice transmission then?
This ☝️ I like this suggestion a lot! 👍
For this we'd need to implement a new TCP message type that the client sends to the server to inform it about its current transmission mode (and changes thereof) and then the server can use standard methods to force-mute the client if appropriate and also send a message to the client.
@AntonioNarra are you still interested to work on this?
I'm no longer looking into this issue.
