Transport Encryption/UDP connection not accurate

[Carmen-Shannon]

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:

The RTP size variants determine the unencrypted size of the RTP header in [the same way as SRTP](https://tools.ietf.org/html/rfc3711#section-3.1), which considers CSRCs and (optionally) the extension preamble to be part of the unencrypted header. The deprecated variants use a fixed size unencrypted header for RTP.

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:

Voice data sent to discord should be encoded with [Opus](https://www.opus-codec.org/), using two channels (stereo) and a sample rate of 48kHz. Voice Data is sent using a [RTP Header](https://www.rfcreader.com/#rfc3550_line548), followed by encrypted Opus audio data. Voice encryption uses the key passed in [Opcode 4 Session Description](https://discord.com/developers/docs/topics/opcodes-and-status-codes#voice) and the nonce formed with the 12 byte header appended with 12 null bytes to achieve the 24 required by xsalsa20_poly1305. Discord encrypts with the [libsodium](https://download.libsodium.org/doc/) encryption library.

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.