Document voice recieving

[Bottersnike]

Connecting to voice is documented, as is heart-beating and sending voice data, however receiving voice data is not. Is this something that should be added to the documentation?

[msciotti]

I suppose an argument could be made for including it explicitly. I assumed it would be assumed that receiving would be, in essence, sending in reverse. However, I can see the argument. Will add this to TODO

[MinnDevelopment]

Could the documentation for this be added together with v4?

[msciotti]

Yeah, seems reasonable.

[Orphis]

Any update on this? It would be interesting to see how to receive voice data through WebRTC in a browser, especially documenting how to get the ICE server information and munge the SDP appropriately!

[msciotti]

I or @b1naryth1ef can do this when the new voice protocol stuff is deployed and documented.

[b1naryth1ef]

I don't fully understand what your trying to ask @Orphis, but the implementation that will be documented here is for native bot implementations, not web browsers.

[Orphis]

@b1naryth1ef Why wouldn't a bot be able to use the WebRTC protocol too or run in a browser context? There are certainly some valid use cases! Also, WebRTC is a native library, not just a browser API.

[b1naryth1ef]

@Orphis Effectively the API we expose for bots is opus via RTP + Websocket control layer, with encryption via libsodium/nacl. While this doesn't exclude you from using WebRTC as a client (read; native) library, you would have to do the packet / networking layer translation (I'm not familiar if WebRTC as a library lets you do this trivially). This is actually mostly documented on this page, however this ticket exists because it doesn't represent the latest version of our control-layer and encryption schemes.

While we do have an implementation of the standard in-browser WebRTC / ICE / DTLS connections, this is only intended to be used by our browser clients as a compatibility layer. We have no plans to open this up for external bot/API use, and we won't be documenting that implementation.

[MicahZoltu]

This ticket seems to imply that the voice documentation is out of date, along with the original issue of voice receiving being missing. If I am looking to start a project that integrates with Discord's voice API, should I wait for the updated documentation or is this documentation "good enough"?

Also, on the topic of voice receiving, will the client receive UDP packets that look exactly like the UPD packets sent by other clients? Does the intermediate server not transform the messages in any way and instead just routes/forwards them blindly?

[MicahZoltu]

On the same topic of receiving voice, how does one differentiate between the different voice streams? In a channel with 2+ people talking at the same time, the client will receive two streams of voice packets at the same time from the same source with (it appears) no way to differentiate those streams. Each stream does have a sequence, but it will appear as a single stream with broken sequence I believe. Obviously the system works, but this is an example of how things are confusing without having documentation on receiving.

[cookkkie]

@MicahZoltu In an RTP packet header you should find the SSRC corresponding to that packet. The SSRC is basically just a number that identifies the stream the packet belongs to. Additionally, thanks to the websocket connection, you can build a map of user_id->ssrc: Discord sends you that information through the websocket connection.

To respond to:

If I am looking to start a project that integrates with Discord's voice API, should I wait for the updated documentation or is this documentation "good enough"?

Basically, the UDP connection sends you standard RTP packets. So, just learn about RTP, implement it, and it should be fine 👌 .

https://tools.ietf.org/html/rfc3550

[elenakrittik]

dead.

[flipbit03]

Is there anything we should do to help push this forward? This is a huge missed opportunity.