Chrome WebRTC developer here. Two quick thoughts:<p>1. A better headline would be "Ericsson open-sources another WebRTC implementation". WebRTC is a set of standards, and they are implementing them, which is one of the purposes of having standards: to have multiple implementations.<p>2. One of the purposes listed by Ericsson for having another implementation is to "transcend the pure browser environment and that native apps ... would become an important part of the WebRTC ecosystem". What I would like to point out is that the implementation of WebRTC found at webrtc.org (ie Chrome's implementation) <i>already</i> supports mobile and native apps. In fact, the documentation is linked to right from the front page:<p><a href="http://www.webrtc.org/reference/native-apis" rel="nofollow">http://www.webrtc.org/reference/native-apis</a><p>And there are lots of native/mobile apps that already use it.
For those interested in Google's implementation:
<a href="https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fwebrtc" rel="nofollow">https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%...</a><p>or browse the code:<p><pre><code> svn checkout http://webrtc.googlecode.com/svn/trunk/ webrtc-read-only
</code></pre>
Also Ericsson's code is on github (I couldn't find a direct link from the parent article): <a href="https://github.com/EricssonResearch/openwebrtc/" rel="nofollow">https://github.com/EricssonResearch/openwebrtc/</a>
Given that they're both open source, built to the same open standard, and (at least nominally) completely interoperable, I'd say "complement" would be a better word than "rival."
I've spent quite a lot of time looking at how OTT providers have impacted traditional SIP stack technologies. Ericsson are one of the few major tech I know companies that have understood that the future is heavily reflected in software definition. I strongly believe companies like Ericsson will surely make some game changing technologies over the next 2-5 years, their bread and butter has traditionally been reliant on production for telco and the like. I bet on Ericsson because they seem to have understood the giant pivot a head of them and look to be rapidly evolving to allow it.<p>Major Kudos.
One of the biggest issues in the whole WebRTC process has been getting companies to commit to documenting the minimum SDP for interop. I'm curious how well these two implementations will interop. One of the reasons for ORTC is to remove signaling from the specification.
Does Ericsson plan to maintain and update this implementation (my understanding is that WebRTC is still an evolving standard) or is this the kind of "we're abandoning the project and dropping the maintenance burden on the open source community" kind of thing that this kind of announcement usually means? Closed source projects opening their code don't generally end up very successful if they're "dead drops".<p>As an aside, I notice that the first issue in the github is "implement H265". That seems like a weird priority if you saw what needed to happen to get Mozilla and Google to even consider supporting H264. I think Firefox still doesn't support it and uses VP8.
Does WebRTC strike anyone as too many things in one package?<p>It's P2P, video, audio, codecs, and a whole slew of other things all bundled up together into the same "standard."<p>The P2P part is really really useful, but I could see some vendors wanting to break that off for various reasons. You can do that of course but... well... it's sort of like if "WiFi" referred to 802.11 + a bunch of video codecs + a routing standard + transport protocols + ...
They open it after all the other browser vendors are already done with this task. Why haven't they released it from the very beginning, saving a few days work-time for others?
I think that now it has almost zero value.