
Ericsson open-sources OpenWebRTC, rival to Google’s WebRTC implementation - openmaze
https://gigaom.com/2014/10/02/ericsson-open-sources-openwebrtc-to-provide-alternative-to-googles-webrtc-implementation/
======
pthatcherg
Chrome WebRTC developer here. Two quick thoughts:

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](http://www.webrtc.org/reference/native-apis)

And there are lots of native/mobile apps that already use it.

~~~
jephir
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.

~~~
jgrowl
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.

------
mgraczyk
For those interested in Google's implementation:
[https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%...](https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fwebrtc)

or browse the code:

    
    
        svn checkout http://webrtc.googlecode.com/svn/trunk/ webrtc-read-only
    

Also Ericsson's code is on github (I couldn't find a direct link from the
parent article):
[https://github.com/EricssonResearch/openwebrtc/](https://github.com/EricssonResearch/openwebrtc/)

~~~
feider
code.google.com - ugh why can't google admit defeat and start using github?

~~~
lobster_johnson
They already did. New projects are on Github, and they seem to be migrating
old ones: [https://github.com/google](https://github.com/google).

~~~
pthatcherg
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/web/content/apprtc)

------
kcorbitt
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."

~~~
jmspring
It is generally considered a positive thing when proposed standards have
multiple independent implementations.

~~~
kcorbitt
Yes, I think you're agreeing with me?

~~~
paulgb
It's a second implementation of your opinion.

------
neom
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.

~~~
jallmann
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.

~~~
gz5
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.

~~~
neom
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.

~~~
jallmann
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.

------
jmspring
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.

~~~
pthatcherg
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.

~~~
jmspring
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.

~~~
pthatcherg
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-5.2)

------
derefr
Dang, here I was hoping this would be (or at least contain) an implementation
of WebRTC Data Channel support for Erlang.

------
rockdoe
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.

~~~
stalund
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.

------
api
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 + ...

~~~
jephir
> 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.

~~~
pthatcherg
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](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.

~~~
jephir
I've filed the issue here:
[https://code.google.com/p/webrtc/issues/detail?id=3892](https://code.google.com/p/webrtc/issues/detail?id=3892)

------
jgrowl
Ericsson's code base looks like pure C? Should make it a lot easier to interop
with other languages like GO.

~~~
pthatcherg
It's on my TODO list to try and make Go bindings for WebRTC :).

------
SimeVidas
Am I reading this correctly? Firefox uses Google’s WebRTC implementation?

~~~
glandium
Note the Google implementation is full of code from Cisco. FWIW.

~~~
pthatcherg
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)

------
antocv
Great to see Ericsson open sourcing awesome stuff.

------
fenesiistvan
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.

~~~
kalleboo
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

~~~
pigubrco
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...](https://code.google.com/p/webrtc/source/browse/trunk/talk/examples/android/README)

