Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

There was little or nothing in WebRTC to match what we'd spend 5 years creating. So they were back to 1-5 people in a conference, with 1-3 second connect times, and no resilience to network changes.

The excuse they gave was "We can't rely on 6 people in Iowa for our core IP". So they switched to some open source mix node that was the pet project of 2 guys in Italy. Two academics, who gave it hardly any attention. And it had zero IP; just a collection of APIs stitched together to give you the impression of having a mix node.

We said all that at the time. But such was the power of the magic words "Open Source" that it all bounced off their mental shields.

View on HN

Maybe I'm kinda leaning beyond the practical/relevance limits of "old code still interesting", but could you open-source the implementation you came up with given the passage of time? Lots of people are stuck on low-bandwidth links so a codebase optimized for slower connections would absolutely fly (and consistently so, for everyone, under lots of conditions), and everyone always wants to use less bandwidth anyway.

From an implementational perspective it's also always good to have explicitly bespoke designs out there to contrast against the bog-standardness of WebRTC with its standard "can't be helped" set of limitations and flaws.

I also find it very fascinating to hear that OSS was the cause of (headdesk-inducing) myopia and blindsiding. My (naive, distant, apparently out of date) impression was that open-source was incorrectly perceived as the inferior option in the stereotypical case. I guess the entropy pool really can go in all the directions...

> Lots of people are stuck on low-bandwidth links so a codebase optimized for slower connections would absolutely fly (and consistently so, for everyone, under lots of conditions), and everyone always wants to use less bandwidth anyway.

You would think so but why have solutions like Mumble[0], which allows for extremely low-latency and high-quality voice calls and has existed at least since the mid 2000s, not become more popular during the pandemic? Or why didn't people at Zoom and MS Teams at least learn from Mumble?

[0]: https://www.mumble.info/

Long enough mumble sessions will desync and the developers don't want to do anything about it. Mobile clients all suck. Mumble is great, but it has flaws too :)

How long are we talking? I remember being in Mumble sessions for hours quite often back in ~2007, 2008 and I never noticed anything like that.

Usually happens when there's bad connectivity.

> You would think so but why have solutions like Mumble[0], which allows for extremely low-latency and high-quality voice calls and has existed at least since the mid 2000s, not become more popular during the pandemic?

Because there is no official Mumble server.

People know how to download an application, click "install", and register an account. But ask them to open a port on their router's firewall/NAT, or set up DNS, and you instantly lose 99.9% of your user base.

It could have been different, but lay people never had the chance to install their own server. They couldn't do it with Dial Up, they didn't have the upload bandwidth with ADSL, they didn't have fixed IP addresses, there's the NAT hurdle, outgoing SMTP is blocked everywhere… that ship has sailed. Even I host my websites on a remote virtual machine I rent.

Mumble has a bunch of issues, the main one being their confusing UI, especially on mobile clients. I'm regularly in mumble conferences and for example accidentally switching the room instead of pushing the push-to-talk button happens quite often.

There's also a bunch of more technical problems. For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection. Results in missing audio. Not just that sound doesn't arrive (in both directions) but it also doesn't tell you something's wrong.

Mumble has problems with changing audio setups which require a restart of the client.

Also no video, no simply calling people - you need to go to a server and they need to go there, too. Basically stopped innovating some time ago and everone else moved further.

>For example as mumble uses a udp protocol it handles dropped frames badly, like on a spotty wireless connection.

WebRTC also uses UDP—as well as virtually every other real-time conferencing platform since the internet existed. TCP is too constraining to use for voice because every single packet retransmission only increases delay further. Dropping packets when they don’t arrive on time is necessary in order to minimize delay, which is one of the principal goals of Mumble.

The real solution to dropped packets is not TCP—it’s a quality jitter buffer, and if you don’t like mumble’s performance in that respect then you need to look at the JB. A good JB will buffer and reorder packets within some statistical measure of network jitter, but the behavior is very explicitly not to retransmit.

https://www.cs.columbia.edu/~hgs/rtp/faq.html#reliable

Google cheated with their implementation of WebRTC by purchasing Global IP Solutions, which gave them the most advanced jitter buffer in the world at the time: NetEQ.

http://www.gipscorp.alcatrazconsulting.com/files/english/dat...

https://chromium.googlesource.com/external/webrtc/+/master/m...

When arrogant MBAs make technology decisions they don't understand and aren't concerned with the details because "their way is best".

Sorry to burst their bubble, but most of the tech world operates on a "6 people in Iowa" for niche technologies.

It seems often in history that better technologies are lost as the wheel is reinvented for no apparent reason, either due to NIH syndrome, political/business concerns, or out of sheer ignorance. Hubris to the overconfident and a loss for humanity are often the results.

> The excuse they gave was "We can't rely on 6 people in Iowa for our core IP"

But, didn't all this code belong to the company? They could have open sourced it themselves, and it would become an open source solution...

What happened to this code??

Some of the Engineers involved may have some of the components. Tom I know has the desktop client. Chris may have a mix node machine in a closet somewhere :) The backend I'm not so sure. Guy who wrote most of that, is a middle manager at Microsoft. My son wrote some, but he didn't keep any of it.

Sounds like they just wanted to stop paying for developers.

Reply on news.ycombinator.com