[Matthias247]

I'm not related to the Safari or any other browser team in any way. But I totally believe that it's a giant amount of work. I personally researched the effort which would just be required to implement webrtc data channels in a server application and have been rapidly been put off after seeing that I would need to have support STUN, TURN, ICE, DTLS and DTCP. With each of them having giant specs. The media formats and all the JS APIs would add on top of that.

I guess it's also not an easy decision to "just include libwebrtc" into ones own application, since that's a giant dependency which pulls in lots of chromium code.

[om2]

We did end up using libwebrtc but we had to strip a lot of the dependencies and also update it use system services instead where appropriate.

[Matthias247]

Thanks for the info. One more question on that: Do you think it makes sense to rerelease that independently or upstream the changes so that others could also include a more lightweight webrtc library? Or are your changes too far tied to Safari? I guess an optimal solution would need to have some kind of platform abstraction layer which then gets implemented by integrators like Chrome or Safari. Probably a big effort.

[microcolonel]

There's OpenWebRTC, which is optimized for standalone applications like media servers and proxies. The version in Chromium is also pretty easy to build and run in C/C++ applications on Linux, but requires extra work for an application like Safari.

[dbrgn]

That means you're aiming for WebRTC 1.0, not for ORTC, right?

[om2]

For now, yes. Our main goal in the short term is interop, since we are a little late to this party.