This is definitely a generic WebRTC question but I am not really aware of a better community in which to ask it, and I am finding it hard to test/verify this behavior locally. The crux of my question is, if a client receives out-of-order UDP packets of voice data from the server and discards the “late” packets, is this counted as dropped packets in the RTC transport statistics?
edit: Want to mention I am aware of the jitter buffer and that to some extent it should allow for out-of-order packets and mitigate potential issues. But this is also what brought the question to mind… does discarding from the jitter buffer count as actually “dropping” a packet as if it was never received?
If you are wondering why I am asking this… read on 
I have a theory that our AWS instances using Enhanced Networking could be causing voice data packets to sometimes be sent out of order. Each vCPU has it’s own Rx/Tx network queue. We currently do not pin mediasoup workers to any specific vCPU. If a worker is sending some packets and is currently running on vCPU #1, which has a Tx queue length of 100 packets, then the process is preempted, sleeps, etc. and is moved to vCPU #2, which has an empty queue, I am thinking the packets sent from vCPU #2 could theoretically be sent out and arrive at the client first. Maybe this is crazy? Additionally my thought on why this is hard to detect and debug is because no packets are actually lost. The received packet count will match the servers sent packet count. However since the packets get discarded we still get gaps in audio, and when Opus FEC kicks in we get “robotic” sounding voice with no correlation in bandwidth, CPU or packet loss issues.