This is what IPsec TFS is for [https://datatracker.ietf.org/doc/rfc9347/]
> the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel
(If they block a constant rate stream, that'll hit a whole ton of audio/video streaming setups)
So they'll just block any constant rate stream that isn't containing AV data or a whilelisted streaming service.
I don’t think that’s possible. AV data is behind the TLS layer, all the DPI can see is a CBR stream that matches HTTPS signature. Unless it can do a MitM (Kyrgyzstan-style) they can’t really tell anything about the payload content save from what the TLS handshake may expose. Past it, observability stops at packet sizes and timings.
As I understand it, modern DPIs try to fingerprint TLS traffic through feeding data that passed some pattern matching to ML models that try to predict how likely it’s between a genuine commonplace browser and a “normal” webserver (or a video streaming server or game server - whatever they trained it on). And in turn modern obfuscation software tries to match the behavior and be seen exactly as it’s your Chrome user watching some cat videos or something equally innocuous.
Aren't many/most audio/video streaming services variable bitrate now?