This might be a completely isolated incident, but it's nonetheless an interesting one with some wider lessons. (NB - see EDIT footnote, certainly doesn't seem to be a blanket policy on audio streams)
I'm currently working in a cafe, streaming music through headphones while I work. Normally it's fine, but today, via my MiFi+Vodafone SIM, I'm getting lots of glitches and drop-outs on the stream. Tried switching "channel" on the same site, but still unlistenable. (96kbit/s streamed MP3 via www.di.fm)
It's on 5-bars coverage, and the pattern is so consistent that it's got to be either an ongoing network problem or deliberate fiddling-about. And given that the audio is buffered anyway, my money is on something funny going on. The glitching is just too regular to blame on congestion.
Listening to the exact same stream via my 3UK USB dongle is perfect even on 1-bar coverage - so it's not the server to blame.
Haven't had a chance to do this "scientifically", ie repeated tests, switching to other streaming sites, or other codecs, or moving to other cells... but it's definitely something to keep an eye (and ear) on.
And this post is another example of why "covert" policy management will be swiftly uncovered. I bet that a few people are probably working on "policy testing" tools for just this sort of scenario, to monitor and reverse-engineer any monkeying-about in DPI boxes. If anyone can point me to a trustworthy app, I'll give it a go.
I wonder which OS vendor will be the first to be brave enough to include a network monitor-and-testing capability, designed for consumer protection and to keep broadband providers honest? That could be an interesting differentiator for Chrome OS, eh Google?
EDIT - I've experimented a bit more now. Some streams work fine on the Voda connection (eg from sky.fm), but others don't (consistently). So... there's seems to be no port/protocol-level policy being applied, but it's possible that some are delivered from different servers, or via different CDNs, or different peering points.