Never really tried to debate. Just claimed to be an expert in AV over IP solutions in a UDP environment. To be clear, I don't work in VOIP -- I'm a broadcasting engineer. My thesis (I do not have a masters degree but my undergrad. required us to do a thesis) was a live jazz concert. The drummer was in Berkeley, the bass player was in Tromso Norway, the trumpet player was in Seoul, South Korea, and I played Piano in a poorly attended theater in the village. I had to build 8 linux machines, but was able to achieve audio @ 48 K, 24 Bit and H.264 video with less than 7 ms of latency, such that we could all play and improvise in real time...think of it as skype with HD audio and video and nominal delay...This was the only system I've ever designed by myself but I have an intimate knowledge of the siriusXM airchain, our webstreaming app, and the shitty audio quality that we provide to north america...
..so far as your comment on compression algorithms optimized for adaptive bit-rate streaming, i'm not so sure I follow. The heavy lifting is done in the server's encoder, relying on feedback from the client to inform it's decisions...i simply teach the encoder how to cut corners when it has to...
If you wanna tell multiplexer stories I've got a good one for you. I once spent 17 hours straight re-programming a statmux card. I was replacing a bad PS in the Space Multiplexer (a unit that takes all 160+ SiriusXM channels and sums them into one bit stream before sending them down 12 DS3s to our various uplink sites) and it caught fire, leaving us with no redundancy. It was easy to repopulate the frame with the necessary components but getting the statmux to play ball was a bitch...
...I'm sure your networking chops are far superior to mine, but until this thing is actually implemented and, more importantly, OVERSEEN -- i'm not drinking the cool-aid.