Undocumented requirement for voice receive

[MinnDevelopment]

It appears that using voice receive has an unintuitive if not errornous requirement. Before being able to receive anything through the established UDP connection the client is expected to send an Opcode 5 Speaking update. The documentation does not reflect this in the slightest and this was unknown to me for weeks until someone mentioned this from the docs:

You must send at least one Opcode 5 Speaking payload before sending voice data, or you will be disconnected with an invalid SSRC error.

This got me curious and I decided to send a speaking update after finishing the session setup, where all i send is the ssrc and speaking set to 0 (none). All of a sudden no more issues were present and voice receive worked as "expected" once again. I'm not sure if this is at all intended behavior but this certainly should be documented together with voice receive (see #365).

Commit that fixed voice receive in JDA

[MinnDevelopment]

Once again voice receive received a breaking change. Now you cannot receive anything unless you first send several packages through the UDP connection.

This is the third time in one year for voice receive randomly breaking without any announcements or updates coming from the API developers. I am very frustrated with the amount of issues that have yet to be acknowledged by the developers.

Additionally there are still no documentations almost 2 years after a formal request has been made. The voice gateway version 4 has not been documented and I have been told it will never be documented as a 5th version is already in the works. The quality of the voice connection documentation is very poor to say the least and I feel neglected by the maintainers. I opened this issue 2 weeks ago and nobody has even put a label on it.

So is this new breaking change a bug? Is it intended behavior that was previously broken?
Why do you need to send a speaking update when you want to receive audio? Why do you need to send silence bytes if you already told the server about your UDP connection?

At this point I feel like it is not even intended for bots to use the voice API in the first place.

I apologize if I come across as entitled or rude but I am very frustrated with this situation.

[jhgg]

At this point I feel like it is not even intended for bots to use the voice API in the first place.

Unless it's documented, it's not our intent that it is to be used by bots. Our approach to this has been, you are welcome to attempt to use it if you can get it working - but we are currently not offering support for it. Additionally, the native client does a bunch of things to set up stuff for voice receiving, so as we change things, if your bot breaks, it's probably by side-effect (the implementation was incorrect in the first place), and not because of a backwards incompatible change (we still have to support the many millions of clients out there that are on old versions...)

This issue doesn't make much sense, as the entirety of voice receive is not documented. I'm going to close this in-favor of #365 - which is the open issue/feature request for documenting

[LikeLakers2]

I'll be honest, reading that response confuses me more than seeing that Minn was frustrated. After all, the very same issue you linked, #365, contains Mason and b1naryth1ef both seeming to imply (at least to me, by agreeing voice receiving should be documented) that voice receiving for bots is intended to be supported, and thus to be used by bots.

I hope it isn't too much to ask, but can you clarify your response? i.e. Has the stance of the devs in regards to voice receiving for bots changed since those comments in #365 were made? Perhaps this is some simple miscommunication? Or what?

[jhgg]

Until it is documented, it is not supported.

[aveao]

That's a terrible approach as bots using voice are pretty widespread and it's a feature users expect from bots. Bot and library devs were told that voice documentation will happen, but it hasn't.

Many discord communities rely heavily on bots for verification, for moderation, for personalization, for music, for fun. It's clear that discord would be a lesser platform without bot and library devs doing the hard work that they do. Discord not supporting and actively going against their hard work is a sign that discord is forgetting what makes discord discord.

TL;DR: Saying "it's not supported until it is documented" just points at a bigger problem: lack of promised documentation. Please make this happen.

[jhgg]

Voice transmission is documented and supported.

This specifically is about the bot being able to receive voice (RTP) traffic - which is currently not documented nor supported. Receiving RTP traffic is a process that is undergoing a lot of change - and as such we are deliberately not documenting or supporting it at this time until the feature-set and protocol stabilizes.

[MinnDevelopment]

First of all, thank you for responding to my issue.

I'm not exactly happy about the outcome because it means the situation is unchanged.
When you say

it's probably by side-effect (the implementation was incorrect in the first place), and not because of a backwards incompatible change

that does sound reasonable, but that doesn't explain why the voice gateway works the way it does now. I do not comprehend the reasoning why you should only receive audio when you first send a speaking update and silence bytes through the UDP connection. This has worked in the past without any of those requirements and I do not understand why they were added to the gateway.

we still have to support the many millions of clients out there that are on old versions

Yes you do, that is why I thought you had versions in the gateway. What exactly is the point of having a versioned gateway if it breaks anyway?

Voice transmission is documented and supported.

But the documentation for this has not been updated for almost a year and still does not mention anything from version 4 or the newer encryption modes that were added (and work fine).

If you officially here claim that voice receive is not meant to be used by bots I don't plan on trying to keep up with this nonsense in the future and will leave this section of JDA unmaintained. This is an unfortunate outcome and very disappointing.