Comment by Sean-Der | Hacker News Reader

Comment by Sean-Der | Hacker News Reader

Parent Full thread

I am so glad you like them! Working on Pion and the KVS WebRTC stuff has been super rewarding because people want it. I have built so many things that flopped, so this is a welcome change of pace. Thank you so much for being part of the community, talking to people on the Pion slack about WebRTC is the highpoint of my week :)

> Having implemented the entire WebRTC spec a couple times now, what wisdoms have you learned that can be shared with us mortals?

The biggest thing I learned during all this was community/collaboration. With all the RFCs I could grind it out and learn them/write unit tests, but working with people took a lot more. With Pion I wanted to build a community/get people excited. I don't always get it right, but I love when I can figure out where mine and other peoples interests lie.

The next big one is convincing people that WebRTC/P2P is important. It has been really hard to convince the Go community that this stuff is important, I have gotten LOTS of talk rejections. I feel so strongly that WebRTC/P2P is the future I want to see. I just want to see an internet that is resilient to monoliths going down and encourages direct collaboration between people.

> If you could write a protocol for the same use-case right now that instantly became as popular and standard as WebRTC, what would be different about it?

I think WebRTC as a protocol is really wonderful. I love that it took established/working technologies and wrapped them up into a nice package. This has let me bridge WebRTC with lots of other interesting projects/hacks. I think that is why WebRTC will eventually eat the RTC/VoIP world, since it is a standard and uses existing technologies it works everywhere.

I would like to see lots of changes to WebRTC as an API though. The W3C/Javascript protocol doesn't allow you access to enough things, I think the more things developers can tweak the more interesting things we will see built. This was a slide I did for the W3C https://i.imgur.com/vHTnlFY.png it hasn't gotten much reception yet, but I am going to keep trying :)

> Media via Datachannels is being chosen more and more (can be HW accelerated)

That piqued my curiosity. Could you please expand on this? What kind of hw accel can be applied to video when it is sent through DataChannels instead of the standard video channel?

The encryption for DataChannels is HW accelerated while video is not. I was able to convince people to change this one! So a developer can opt-in to the accelerated profile.

https://bugs.chromium.org/p/chromium/issues/detail?id=713701...

Nice speedup! However it seems that AES-GCM comes at a cost of considerable increases in packet sizes, from what I could read in the link. Have you observed an increase of packet loss and latencies in real-world networks? (esp. with third world connections)

The improvements in CPU usage are clear for the server, but the choice doesn't seem so obvious to me

EDIT: I meant that, for the quality of end-user experience (who doesn't care about server load), it doesn't seem like an immediately obvious better choice to just use GCM, until some empiric testing shows if the potential increase of packet loss causes noticeable problems, or on the contrary, doesn't. It would be very cool reading any observations in this regard.

Sorry I haven't done any measurements myself. Agree, it is a trade-off for sure, if you are doing video and packets are already ~1300 bytes it probably makes sense. For Opus only you are really blowing up your payload.

You might see CPU improvements on the client side as well though! If you have a fixed set of clients it might be something worth evaluating.

I personally don't have any real-word deploys I can measure. The AES-GCM work came around because a Pion user mentioned it me, so then I added it/tried to push the issue in the IETF/W3C.

Dude, thank you for this. My team has been trying to figure this out - we know we will eventually need a way to utilize in a low-level context, but couldn't dig up any cases of such an implementation. In addition, we were constantly frustrated by the lack of HW acceleration that created a performance bottleneck. Great work!

There's a proposal that would let video encoding be accelerated without going through the entire WebRTC pipeline: https://github.com/WICG/web-codecs/blob/master/explainer.md

Somewhat tangentially related, for cases when P2P connectivity is not needed, there's also a proposal that lets you send data unreliably, but in a client-server setting: https://github.com/WICG/web-transport/blob/master/explainer....

Both are currently being actively prototyped in Chromium (full disclosure: I've been working on the latter).

I agree it needs more low level controls. The api is very high level at this moment. Luckily that seems to be a focus of webrtc NG being discussed.

I also think SDP wasn't such a great choice. ORTC that was pushed early on by microsoft was better in this regard, but luckily a lot of ideas from ORTC are also making their way in webRTC.

"I feel so strongly that WebRTC/P2P is the future I want to see."

This sounds like it'd bring back the good ol' DDoS days where cable modem users could just knock dial-up users offline with a simple packet flood, or ACK flood, or SYN attack, because the IP address was known. Especially since WebRTC has a nasty habit of leaking IPs when (easily) misconfigured, so much so that VPN services have dedicated WebRTC services to check if you're leaking out your IP due to such easy chance of misconfiguration.

I am fine with NATs! I think is a good compromise between security and connectivity. If two users want to connect they have to explicitly do NAT traversal.

'IP Leaking' was fixed with mDNS candidates [0]

[0] https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candi...

Wasn't mDNS designed for small networks like intranets, not the whole internet?

I'm reading a discussion on Google where in the comments it is mentioned that you can still obtain IP addresses even with mDNS enabled if you're allowing video and audio with a specific flag set (again with the configuration implementation.)

https://groups.google.com/forum/#!topic/discuss-webrtc/6stQX...

yes. WebRTC doesn't allow changing the video buffering behavior. it is suitable for conference meetings, but not so ideal for remote control.

Reply on news.ycombinator.com