Some tidbits from the WebRTC Conference I just attended.
I just came back from Paris where I took part in the WebRTC Conference hosted by Upperside.
There was a lot going on during the conference – I won’t be trying to sum it up neatly here – I don’t think I am up to it. I will leave the long and arduous insights for some future posts – more than one.
What I will do, is put here a few bullet points of things that resonated with me during these sessions:
- SIP is now considered as “legacy”. WebRTC is the innovator, disruptor, new kid in the block
- SIP failed to deliver on its promise – it is too slow to change: almost every new service idea requires standards rewriting, code changes, redeployments, etc.
- OTTs have more to lose than Telcos from WebRTC because they rely on money made from interconnect (think Skype Out)
- Trust and identity are missing from WebRTC by design – we lose something due to it. There will be those who will come to fill in the gaps – carriers can do that
- WebRTC will make setting up a telephony service as easy as setting up a blog
- You either build a pure web service with WebRTC or you try to map it into the current carrier world of PSTN and IMS. I think there is more opportunity somewhere in-between these extremes than in these obvious two options
- Web and SIP standards don’t match – not in signaling and not in media. This is a problem of sorts
- WebRTC is both revolutionary and yet another access protocol
- Gateways were all the rage during the conference. I must say that is frustrating. I think there’s a lot more interesting infrastructure to WebRTC services than gateways
- Emergency and regulation are the best excuses not to use WebRTC
- The dial tone is missing in WebRTC. The W3C is working to remedy that with push additions to HTML5
- Universities have all the fun. I’d like to be a student again
- There are some real, important enterprises looking to use WebRTC and deploy it (hint: banks)
- WebRTC needs the smartphone and the smartphone needs WebRTC
- Lots of challenges for WebRTC on mobile
The above are mostly “keywords” at best. Feel free to contact me and tell me what focus do you want me to take of these issues moving forward – I promise to write on these topics more.
Hi Tsahi,
Are there any working implementations yet? Is any one actually using WebRTC commercially or is it still too early that?
Cheers,
Andrew.
There are several working implementations already.
I have done an interview with frisB – one such implementation – and have 4 additional ones lined up.
Most are in alpha or beta phases but some are readying themselves for commercial deployments – I guess this will happen once Google Chrome and Mozilla Firefox come out with their own stable versions of WebRTC implementations in the browser.
Hi Tsahi,
Reading pointers posted by you..It is interesting to know “SIP is now considered as “legacy”. WebRTC is the innovator, disruptor, new kid in the block”
1. Can you throw some light on SIP part of it and its specific limitations.
2. What about the organizations who have already invested heavily on SIP products for Voice, Video and UC .. what can be the points which can decide the transition from legacy “SIP” to WebRTC in practical scenarios.
Thanks,
SIP is here to stay. It has a lot of years ahead of it, so vendors and the ecosystem has nothing to fear about. WebRTC will be adopted and disrupt things, so vendors need to make sure they stay ahead of the game here.
In terms of innovation and creativity, I think we’ve moved on from SIP to WebRTC.
I am planning a post about this one in the near future – it will be based on Wolfgang Beck’s presentation during the conference.
Thanks Tsahi. Looking forward to your new post on the subject.
Cheers,
Anant
We’re using WebRTC right now as well… it’s also been one of the ways we provided to allow users to attend IETF meeting sessions in Vancouver remotely, and will do the same in October in Atlanta.
Hi Tsahi, it was a pleasure to meet you there in person.
We’ve just launched a brand new version of Bistri, have you tested it ?
Take care,
Arnaud
http://bistri.me/arnaud
Arnaud,
Gone for the weekend. I’ll be sure to check up your service next week!
I have been enjoying your blogs. I have a couple of questions.
If SIP is considered legacy as far as WebRTC is concerned, what is the “preferred” signaling stack for WebRTC applications?
I am involved in the development of a video server application–we have not done much on the signaling modules yet. What signaling stacks would you advise that we should support in order to be ready for a WebRTC future?
Thanks,
-Andres
Andres,
I don’t think there is a preferred signaling protocol for WebRTC. It really depends on the use case you have in mind.
The 3 main options that exist are probably:
Make your pick based on your architecture, experience in the company and integration points with other equipment.
Tsahi,
Thank you for your response and advice.
Another question if I may…
I vaguely remember hearing something recently that Google has decided to support h.264 in WebRTC. Is that true?
Actually, I do not understand why all the fuss regarding video codecs. Why can’t WebRTC support *both* V8 and h.264? Why is it an either/or issue and not simply both? It seems that since there is currently so much hardware support for h.264 in smartphones that it is a no-brainer that WebRTC should support h.264. If WebRTC supported h.264, WebRTC would be useful in the mobile space *now* and then when hardware vendors finally get around to adding support for V8 in their chipsets, both sides would be happy. Since Google now owns Motorola, it would appear that whatever codec Google decides to support, there would eventually be Motorola-based smartphones with hardware support for that codec. So, I would think there will eventually be hardware support for V8 but it will be several years before we see it.
-Andres
Andres,
H.264 requires royalties.
This causes problems to two types of developers:
So mandating H.264 means royalty costs placed on WebRTC.
H.264 has it advantages, mainly the ecosystem and current video deployments – no easy answers.
I recognize that H.264 requires royalties–that makes it less than ideal, but as a developer I should still have the *choice* to use it if I am willing to pay. Correct me if I am wrong here, because my understanding is that if I use WebRTC today, I *have* to use V8 for video because it currently does not have support for any other video codec, much less the very popular and ubiquitous H.264 video codec.
Why does the standard have to mandate a *single* video codec? As I recall, the H.323 standard says that *if* an endpoint chooses to support video, it has to at least support H.261, and then other video codecs are optional. So having a standard mandate a particular video codec certainly insures some minimum degree of interoperability for video applications. So, if two separate video apps claim to support H.323 then the probability is high that they can interoperability at least with H.261. I can see that is one good reason for having the standard in the first place.
But I want the option to use H.264.
Personally, I wish WebRTC would specify that *only* G.711 was *mandatory* for voice and that *any* other speech codec was optional (G.723, G.729, G.722, etc). For video, that *any* video codec was optional (V8, H.261, H.263+, H.264, H.265, SVC, etc). That way the standard would specify a bare minimum for royalty-free voice interoperability but also gives developers the option to use *any* video codec so we can use higher quality video codecs to allow us to differentiate our product from the others. If there *has* to be a mandatory video codec, then that could be V8–but the more important issue for me is the option to use other higher quality codecs if I am willing to pay the consequent royalties.
-Andres
Andres,
The spec states which codecs are mandatory. You can use whatever optional codec you wish.
The problem with having no mandatory codec is being unable to communicate at all, and the problem of not adding a mandatory wideband codec is that you are back to the crap of a voice experience PSTN offers today. There are so many voice codecs that not choosing one effectively means choosing none.
Remember that there are only 4 real browsers out there: Chrome, Firefox, IE and Safari – as a developer of a service you are not in control of the codecs the browser vendors will choose to implement.
Andres,
the IETF has agreed that at least a shared common codec needs to be specified, and the “mandatory” here means “mandatory to implement”, not “mandatory to use”. So yes, even if VP8 were to be chosen as the MTI codec, H.264 could still be used by browser that chose to support it, and viceversa. The reason why H.264 is not available in current WebRTC implementation has been well explained before: it’s not royalty free, and not easily distributable without a license, especially in open source projects like Chromium or Firefox which are the most up-to-date implementations of the specification. I for sure wouldn’t be able to get it on my Fedora Linux, for instance.
Lorenzo
Thank you Tsahi and Lorenzo for your replies.
That is a relief to see that I do have the option to use H.264 if I want to pay the powers that be. I just found more links to WebRTC and related RFCs and so I will study them more this week.
I guess I am just too much of an optimist because I keep assuming that H.264 royalty issues will get better not worse. Since HTML5 supports H.264, and all of the browsers are supporting HTML5, I am assuming that eventually all of the browsers will eventually have H.264 support.
Please correct me if I am wrong here, but my understanding is that it is royalty free to use a H.264 decoder, but that MPEG-LA still requires royalties to use the encoder. Is that true?
When I see open-source apps like VLC support H.264 it appears that MPEG-LA royalties are not *that* prohibited.
-Andres