Transport Encryption/UDP connection not accurate #7335
Unanswered
Carmen-Shannon
asked this question in
API Feature Requests & Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The documents are a bit ambiguous when it comes to encryption modes and how to generate nonces for these modes: https://discord.com/developers/docs/topics/voice-connections#transport-encryption-and-sending-voice
I have an issue where I am using the gateway and voice gateway, and opening a UDP connection and streaming an audio file that is Opus encoded with a 48khz sample rate on 2 channels. I have confirmed that encryption/decryption works using the format as specified by the docs for AES 256 GCM:
using a 32-bit incremental value as the nonce, padding the other 8 bits of the nonce with null bytes
using the 32 byte secret key obtained from the session description/details (I forget what it's called)
using the RTP Header (standardized format, including IV's for sequence and timestamp, SSRC set to be the bot I have created to play the audio which was fetched from the voice gateway ready response
appending the un-padded 32-bit incremental nonce value to the end of the encrypted value
appending the encrypted payload + nonce to the standardized format RTP header
sending the voice packet over the UDP connection
I have confirmed that my encryption works, as I am able to decrypt following the same procedure:
extract the nonce value from the last 4 bytes of the payload
extract the RTP header (unencrypted) using the SRTP method:
use the 32 byte secret key, the extracted nonce value, and the extracted RTP header to decrypt the audio frame
playback the audio frame
I am able to receive packets over the UDP connection, and decrypt those packets without issue, but when I send encrypted packets using apparently the same encryption method, my bot does not playback audio.
I think this is a result of out-dated UDP connection instructions, or maybe DAVE is being silently enforced even though I have omitted my
max_dave_protocol_version
in my identify request.The encryption descriptions and specifically the nonce generation instructions are a little ambiguous, and the only description for nonce generation is for the deprecated xsalsa20-poly1305 generation:
This bit of information is inaccurate. As an extra note of context, I am not using a current library for any of the voice connection or gateway connection logic, everything is built in my own custom library. I should also note that while sending packets, the connection shows now sign of degradation or failure and the gateway connections remain in-tact as well, the UDP connection just seems to show no indication that my packets or audio frames are mal-formed.
Beta Was this translation helpful? Give feedback.
All reactions