Ericsson open-sources OpenWebRTC, rival to Google’s WebRTC implementation(gigaom.com)
gigaom.com
Ericsson open-sources OpenWebRTC, rival to Google’s WebRTC implementation
https://gigaom.com/2014/10/02/ericsson-open-sources-openwebrtc-to-provide-alternative-to-googles-webrtc-implementation/
50 comments
Our (Ericsson Research) view:
1. Agreed. That headline was not written by us. 2. The reason for having another impl. is not the lack of native app support in Google's implementation. Rather, you should read it as one of the motivations for developing OpenWebRTC in the first place.
1. Agreed. That headline was not written by us. 2. The reason for having another impl. is not the lack of native app support in Google's implementation. Rather, you should read it as one of the motivations for developing OpenWebRTC in the first place.
A few months ago, I tried building the Google WebRTC implementation, but got an error about missing Java libraries. I'm not sure why Java is needed to build a C++ API, even then, requiring Oracle Java 6 and not working with OpenJDK.
Ericsson's implementation, on the other hand, has a much simpler build process. Just run the shell script and it works.
Ericsson's implementation, on the other hand, has a much simpler build process. Just run the shell script and it works.
I am pretty sure Java is only needed to build the Java wrapper. There may be a build target or a flag you can use to avoid this.
I'll agree Ericsson's implementation is simpler, but maybe not as robust.
I'll agree Ericsson's implementation is simpler, but maybe not as robust.
Oh, also... I forgot I created an ansible playbook on ansible-galaxy a couple weeks ago that builds Google's webrtc implementation:
https://github.com/jgrowl/ansible-galaxy-webrtc
It will build the JAR target but that will build the .so file as part of the process.
https://github.com/jgrowl/ansible-galaxy-webrtc
It will build the JAR target but that will build the .so file as part of the process.
I am curious. How did you come to work on the WebRTC stack for Chrome?
I applied to Google. They hired me. I worked on Google Talk and Hangouts for many years. WebRTC was related and interesting, so I worked on various parts (such as the data channels) in my 20% time. After a while, I liked it so much I chose to make it my 100% time.
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.
Major Kudos.
Major Kudos.
There is a lot of hubaloo over WebRTC in the telecom space, because there's nothing else happening there. Traditional V/VoIP has been stagnant since people started doing video chat using large TVs a decade ago, calling it telepresence.
WebRTC is another feature to check off, and the opportunity to develop and sell another SIP gateway product. WebRTC is in no way a replacement for SIP, much less an existential threat to the telecom industry; it is simply another transport layer.
Personally, while some OTT innovation is welcome, I hope the status quo isn't completely shattered. Going all-out on WebRTC implies a siloed architecture, which is antithetical to the purpose of an interoperable standard like SIP.
WebRTC is another feature to check off, and the opportunity to develop and sell another SIP gateway product. WebRTC is in no way a replacement for SIP, much less an existential threat to the telecom industry; it is simply another transport layer.
Personally, while some OTT innovation is welcome, I hope the status quo isn't completely shattered. Going all-out on WebRTC implies a siloed architecture, which is antithetical to the purpose of an interoperable standard like SIP.
Technology has historically confined us to communications = telecom, but really telecom is just a branch of comms, and a branch that is best for a very specific set of use cases.
WebRTC enables communications as a feature - a very different set of use cases. Use cases that are directly embedded in other applications and workflows.
Also, by publishing the APIs, and baking much of the technology into the browsers (regardless if it is WebRTC, ORTC, etc.), WebRTC helps democratize communications service development by lowering the barrier to entry and the cost of development. This will help lead to comms apps we haven't even thought of yet, or don't yet have a reason to exist.
WebRTC enables communications as a feature - a very different set of use cases. Use cases that are directly embedded in other applications and workflows.
Also, by publishing the APIs, and baking much of the technology into the browsers (regardless if it is WebRTC, ORTC, etc.), WebRTC helps democratize communications service development by lowering the barrier to entry and the cost of development. This will help lead to comms apps we haven't even thought of yet, or don't yet have a reason to exist.
Not disagreeing with you. Learning a new JavaScript API is much more accessible than waddling through the morass of VoIP standards. But ultimately, that's all WebRTC is -- an API specification with MTIs for media handling that are going to look antiquated in a decade.
There is absolutely nothing wrong with that -- tooling makes all the difference in the world, and the reason WebRTC is catching is because the right substrate for RTC is finally available in the browser. What's missing in the dialogue is that WebRTC only solves a small subset of the problems that V/VoIP addresses. They are complementary technologies, but not substitutes -- we'll be seeing a lot of reinventing the wheel and rediscovering the same mistakes in the years to come.
There is absolutely nothing wrong with that -- tooling makes all the difference in the world, and the reason WebRTC is catching is because the right substrate for RTC is finally available in the browser. What's missing in the dialogue is that WebRTC only solves a small subset of the problems that V/VoIP addresses. They are complementary technologies, but not substitutes -- we'll be seeing a lot of reinventing the wheel and rediscovering the same mistakes in the years to come.
Google fiber could kill traditional telco and traditional sip, if the speed and stability rivals that of a sip network, then google could become a utility I'd imagine, as I believe the ability to reliably deliver "tone" and provide access to emergency services are the only things lacking in voip today. The telcos shouldn't just be scared of the application layer, they should be scared of what the application layer has begun to do in the physical.
Traditional telco will die within the next 6 years if they don't innovate, I'd bet my bottom dollar on it. I believe this move from Ericsson is the beginings of them pulling the telco industry forward - knowing fine well how reliant they are on it. If this isn't part of a bigger picture play, then teclo as we know it and their vendors (all of you) are done.
Traditional telco will die within the next 6 years if they don't innovate, I'd bet my bottom dollar on it. I believe this move from Ericsson is the beginings of them pulling the telco industry forward - knowing fine well how reliant they are on it. If this isn't part of a bigger picture play, then teclo as we know it and their vendors (all of you) are done.
What exactly would you replace SIP with? Hangouts? Skype? Another proprietary OTT solution? Please, no.
Are you confusing SIP with the public switched telephone network? They are two very different things; SIP can be used to signal PSTN traffic, among many, many more things. "Killing" a completely open, functioning communications standard just because it doesn't share the same acronym as the hotness of the moment is extremely shortsighted.
I do agree on two things: carriers should not be in the business of providing services on top of last-mile delivery, and any said services really need to be modernized. Eg, provision public URIs alongside phone numbers, let my phone register with my own SIP proxy rather than the carrier's IMS gateway, QoS guarantees for video calls and other media, etc.
Are you confusing SIP with the public switched telephone network? They are two very different things; SIP can be used to signal PSTN traffic, among many, many more things. "Killing" a completely open, functioning communications standard just because it doesn't share the same acronym as the hotness of the moment is extremely shortsighted.
I do agree on two things: carriers should not be in the business of providing services on top of last-mile delivery, and any said services really need to be modernized. Eg, provision public URIs alongside phone numbers, let my phone register with my own SIP proxy rather than the carrier's IMS gateway, QoS guarantees for video calls and other media, etc.
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.
Signalling is already removed from the WebRTC API. ORTC doesn't change that. All would change is not needing to use SDP as the API surface. But that's API surface, not signalling.
signaling/api surface, easy enough for me to not be precise in my terminology, that said, there is still no agreement to produce an rfc/draft with agreed to sdp for an independent implementation.
I'm pretty sure this RFC draft qualifies as defining the SDP for an independent implementation:
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-07#section...
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-07#section...
Dang, here I was hoping this would be (or at least contain) an implementation of WebRTC Data Channel support for Erlang.
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".
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.
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.
I'm the Ericsson Research person responsible for the release.
This release is not about throwing code over the fence. We have developed OpenWebRTC over last few years and are using it to build various applications. This will continue, with the difference that we will maintain the OpenWebRTC framework in the open.
That being said, we are a relatively small team. For OpenWebRTC to remain competitive as the WebRTC standard continues to evolve and people find new uses for the technology, we hope to get as many external developers involved as possible. OpenWebRTC builds on GStreamer which is a well-maintained project with a active community. Improvements in GStreamer will therefore almost automatically be reflected in OpenWebRTC.
To be completely transparent Bowser is not our top priority, OpenWebRTC is. Bowser primarily serves as a demo application for OpenWebRTC and is a good way for people to try out the technology before committing to it. Some people will find Bowser very useful, especially while WebRTC support is missing on other iOS browsers, and we are happy for any value it creates.
This release is not about throwing code over the fence. We have developed OpenWebRTC over last few years and are using it to build various applications. This will continue, with the difference that we will maintain the OpenWebRTC framework in the open.
That being said, we are a relatively small team. For OpenWebRTC to remain competitive as the WebRTC standard continues to evolve and people find new uses for the technology, we hope to get as many external developers involved as possible. OpenWebRTC builds on GStreamer which is a well-maintained project with a active community. Improvements in GStreamer will therefore almost automatically be reflected in OpenWebRTC.
To be completely transparent Bowser is not our top priority, OpenWebRTC is. Bowser primarily serves as a demo application for OpenWebRTC and is a good way for people to try out the technology before committing to it. Some people will find Bowser very useful, especially while WebRTC support is missing on other iOS browsers, and we are happy for any value it creates.
Does WebRTC strike anyone as too many things in one package?
It's P2P, video, audio, codecs, and a whole slew of other things all bundled up together into the same "standard."
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 + ...
It's P2P, video, audio, codecs, and a whole slew of other things all bundled up together into the same "standard."
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 + ...
You can't have video chat with audio, video, codecs, p2p, the whole thing. The only piece you can remove from the whole and still have video chat work is the data channel.
If all you want is the data channel, then you can ignore the audio/video part, and just use the data channel separately. It doesn't do you any harm.
If all you want is the data channel, then you can ignore the audio/video part, and just use the data channel separately. It doesn't do you any harm.
> Does WebRTC strike anyone as too many things in one package?
It does too many things. I want to use WebRTC data channels for a multiplayer game, but the current implementation libraries tie-in all the media components. It would be nice if there was a WebRTC implementation that provided data channels without having the media functionality.
It does too many things. I want to use WebRTC data channels for a multiplayer game, but the current implementation libraries tie-in all the media components. It would be nice if there was a WebRTC implementation that provided data channels without having the media functionality.
While we don't provide a build target for compiling the data channel without the audio and video parts, it's not that hard to remove from the build. It's just some build file hacking (basically remove webrtcvideoengine.cc and webrtcvoiceengine.cc).
Would you mind filing an issue at https://code.google.com/p/webrtc/issues/list to ask us to make a nicer build target? It won't be top priority, but we get around to it. Or better yet, if you get it working, send a patch. We'd probably include such a build target.
Would you mind filing an issue at https://code.google.com/p/webrtc/issues/list to ask us to make a nicer build target? It won't be top priority, but we get around to it. Or better yet, if you get it working, send a patch. We'd probably include such a build target.
I've filed the issue here: https://code.google.com/p/webrtc/issues/detail?id=3892
Ericsson's code base looks like pure C? Should make it a lot easier to interop with other languages like GO.
It's on my TODO list to try and make Go bindings for WebRTC :).
Am I reading this correctly? Firefox uses Google’s WebRTC implementation?
They cooperate on the same stack (webrtc.org) which deals with audio/video processing. Networking, JavaScript bindings, etc (the part exposed to the outside world where standardization matters) are separate. This ironically means that interoperability isn't a given, took a while to achieve, and was worthy of a press release.
The relevant code was originally from GIPS: http://www.gipscorp.com/ which Google bought.
The relevant code was originally from GIPS: http://www.gipscorp.com/ which Google bought.
Note the Google implementation is full of code from Cisco. FWIW.
That would be news to me. They aren't listed in the AUTHORS file:
https://code.google.com/p/webrtc/source/browse/trunk/AUTHORS
https://code.google.com/p/webrtc/source/browse/trunk/AUTHORS
Don't confuse a WebRTC implementation with the Cisco supplied H.264 codec binary and MPEG LA coverage. You get H.264 support in Mozilla & Chrome via this mechanism.
Thought of the same thing. Anyone know?
There are a few different layers to the WebRTC stack. I believe they use the lower layer which does the video and audio processing. But they don't use the higher layers from which do ICE, SCTP, and SDP.
Great to see Ericsson open sourcing awesome stuff.
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.
I think there's a significant amount of value in having multiple independent implementations, especially when they are open-sourced and can borrow from as well as compete against each other. See, for example, OpenSSL/LibreSSL/GNUtls.
The README states the focus isn't on browsers
> OpenWebRTC is built on the belief that the WebRTC standard would transcend the pure browser environment and that native apps, implementing the same protocols and API's, would become an important part of the WebRTC ecosystem
and it has out of the box platform support for iOS and Android
> OpenWebRTC is built on the belief that the WebRTC standard would transcend the pure browser environment and that native apps, implementing the same protocols and API's, would become an important part of the WebRTC ecosystem
and it has out of the box platform support for iOS and Android
Here is a link on how to build a native Android WebRTC sample app: https://code.google.com/p/webrtc/source/browse/trunk/talk/ex...
For those interested in Google's implementation:
https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%...
or browse the code:
or browse the code:
svn checkout http://webrtc.googlecode.com/svn/trunk/ webrtc-read-only
code.google.com - ugh why can't google admit defeat and start using github?
They already did. New projects are on Github, and they seem to be migrating old ones: https://github.com/google.
We put some WebRTC things on github, like AppRTC:
https://github.com/GoogleChrome/webrtc/tree/master/samples/w...
https://github.com/GoogleChrome/webrtc/tree/master/samples/w...
I don't think they should, what they should do is copy the UI, switch to git as their version control, offer lower prices and better search. Embrace and extinguish.
Great Thanks !
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.
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) already supports mobile and native apps. In fact, the documentation is linked to right from the front page:
http://www.webrtc.org/reference/native-apis
And there are lots of native/mobile apps that already use it.