Comment by moron4hire | Hacker News Reader

Comment by moron4hire | Hacker News Reader

It'd be one thing if WebRTC actually worked, then we could maybe talk about trade offs and whether or not the functionality is worth the negative impact. But WebRTC is a real shit-show right now. It's a 5 year old spec that doesn't have a single complete implementation, and no two implementations are even close to being reasonably compatible. I challenge any one person to write a WebRTC-utilizing app, from just the spec, that works in two OSes and two browsers.

Add on to that the fact that none of the popular examples are running on anything resembling the latest version of the spec. It's complete garbage. I've stooped to having to use a third party framework in my project, and that still fails 20% of the time when it's not 100% of the time on iOS.

I lost at least month to WebRTC. They lure you in with the promise of working over your LAN and then completely destroy your dreams. I've had connections report they were successful and still have no audio come through! "Get a TURN server" they say. Did that, didn't help, still have problems because the STUN connections are reporting success so the TURN server is never attempted. No errors, no indication something is wrong. How are you supposed to recover from something like that?

I fully agree with the above. Maintaining a live streaming website which still uses Flash unfortunately, I was really excited over this about a year ago until I saw that I can barely use our beta with my remote co-workers, different network setups are a pain. I stopped and sworn I ll never touch it until I see one of our bigger competitors adopting it. Seems not much has changed since.

Regarding the spec, it's not finished yet, so it's hard to write a "complete" implementation. In the browser, adapter.js https://github.com/webrtc/adapter should help a lot though.

Five years is too long, and adapter.js is not very good.

I've had a WebRTC app tested working under multiple OS's (Windows, Linux, Android) and browsers (Chrome, Firefox, IE, Chrome for Android).

It did take more than a month to get to that point though.

Repo or it didn't happen.

https://github.com/blakelapierre/instantfile

https://github.com/blakelapierre/instantchat

Can't say whether the HEADs work or not. They currently aren't hosted live at the moment, either.

So other than hosting your own TURN server, you're not doing anything that my own home grown code was doing, leading me to believe that this will not work very reliably. My problem wasn't making confections, it was making them reliably.

You must follow the 52ish-step handshake protocol pretty much exactly to have any hope of reliably creating connections across OS/browser platforms.

I don't think I had seen any handshake failures in the final versions of the code in those projects.

Also, you need a TURN to work reliably over every possible NAT topology (though, a few years ago I think only about 5% of connections in the wild required TURN).

I had a TURN server, I just meant I didn't host it myself. But the metering showed it was never active! I kept getting a connection that succeeded through STUN, but no audio would actually come through in about 50% of WAN cases. It would always work on the LAN. Is it possible to just have a janky STUN server that negotiated a bad connection for you? Seems like a really weird failure mode. I was using Xirsys at the time as they have a mostly bare-bones setup.

If you were going across browser versions/platforms, it's possible that an appropriate audio codec couldn't be negotiated...perhaps some browsers use different codecs for different network conditions? It seems unlikely, but possible.

So, you had video, but no audio?

No, I wasn't using video. This is for a WebVR app, so the people are rendered as avatars.

So, you were still getting a data connection, just no audio?

Send a sinewave outside the human hearing range and check for it on both ends.

That's an interesting idea. I wonder if the audio compression codec wouldn't obliterate it, though. Typically, they are supposed to be designed for human speech-level audio.

Regardless, there is nothing within the WebRTC spec for dealing with failed connections. I suppose you could close the WebRTCPeerConnection object, drop it on the floor for the GC to find, and make a new one. But the entire point of providing a list of STUN servers is that it's supposed to find the one that works for you.

I also just found out that, even though Tokbox (the 3rd party framework I'm using for WebRTC now that I've admitted I have more important things to do than screw around with this) is communicating a P2P video or audio connection, it cannot also let you negotiate a P2P data channel.

You should be ok as long as you keep it bellow the nyquist freq.

Reply on news.ycombinator.com