RFC 9443 defines how to demultiplex QUIC from a whole range of other protocols. Packets in the range 128..191 (i.e. all packets starting with 0b10xxxxxx) are supposed to be forwarded to RTP/RTCP.
This mostly works, since QUIC v1 packets (both short and long header) define the "QUIC bit", the second bit (0x40) to be set to 1. On the other hand, Version Negotiating packets are defined as 0b1xxxxxxx, where the last 7 bits are an arbitrary value. RFC 8999 defines these bits as unused, and it's up to the server to decide how to set these bits. Specifically, it's a valid strategy to set them to a fixed value. If that value starts with a 0, Version Negotiation packets would be consistently mis-classified as RTP packets. Section 17.2.1 of RFC 9000 says that servers SHOULD set the first of the unused bits to 1 "where QUIC might be multiplexed with other protocols". This advice is fine for some deployments, but in the general case, the server has no way of knowing what other things the client is demultiplexing on the same UDP socket. I see two ways out here: 1. Change the recommendation in RFC 9000 to always set 0x40 to 1 (e.g. by removing the "where QUIC might be multiplexed with other protocols" subclause). It might also make sense to add this recommendation to RFC 8999, too. 2. Change the classification logic in RFC 9443, such that 128..191 are only routed to RTP/RTCP if the next 4 bytes are not equal to 0. I'm not sure about the implications for RTP/RTCP though.
