-
Notifications
You must be signed in to change notification settings - Fork 397
MSC4002: Walkie talkie #4002
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
MSC4002: Walkie talkie #4002
Conversation
@@ -0,0 +1,64 @@ | |||
# MSC4002: Walkie-Talkie |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if I am missing the proposal here but this sounds more like a client feature request than a necessary specification change of the protocol. I think current VoIP signaling can do this already
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if that is the case.
Can current VoIP support locking incoming transmissions when one person is speaking?
And if it can how to implement VoIP on demand where message is automatically accepted by the client.
Without permission management, server will try to send it to all users in one specific room which is not ideal.
As I mentioned earlier, 50% or more of the implementation needs to be done on the client side. However, I suspect that some protocol changes will also be required.
Thank you for your contribution. This MSC is lacking details that we would need to review it. Does this feature need new events that clients need to exchange? Does it need new endpoints? How are device-based permissions implemented? I've marked this as a draft for now. |
Element Call already has walkie talkie mode based on MSC3401 style group calling, which does the necessary stuff like take a lock out on the line etc. It implements it entirely clientside though, using mute state to detect who's taken out a lock on the line though, iirc: https://github.com/vector-im/element-call/pulls?q=is%3Apr+ptt+is%3Aclosed. I guess this MSC could be extended to spell out that behaviour, even though it doesn't involve API changes? (although PTT is pretty beta on EC, which in turn is also beta, so it could well be that the implementation approach changes as it matures). I think this is really asking for a feature in the spec rather than proposing a solution though, so might have been better as an issue rather than a PR. (That said, now it's here, we can use it as a placeholder that can grow into an actual MSC for PTT :) |
Thank you, @ara4n and @uhoreg, for listening to me. I will try my best to help change the feature request into a solution for this pull. However, my knowledge of the matrix protocol is lacking, so after my training arc I will try to refine this MSC to ensure it won't be a hindrance for other contributors. |
@tajo48 No problem. If you have any questions or need any guidance, feel free to ask. |
Rendered
Walkie-talkies are ideal for communication in a work environment as they allow for quick and efficient two-way communication among team members.
To use a walkie-talkie functionality, simply hold down the "talk" button while speaking, and release it to listen for a response.