This is another one of those posts about WebRTC. The ones you might be interested in?
When I published my post on what WebRTC will do to Video Conferencing, a colleague of mine asked what will it to the larger VoIP industry.
I think that this question renders a similar but a bit different answer in such a case. The focus here changes a bit – we’re not interested in video – only in the voice capabilities of WebRTC. And voice has become a commodity already.
I’d like to highlight 3 ways in which the VoIP industry is being changed by WebRTC:
Shift in the power structure of voice engine offerings in the market
From the moment Google has acquired GIPS (the company that was later open sourced as WebRTC), their user base has scrambled to search for alternatives. GIPS was one of the most known and successful voice engine companies – almost every company developing a VoIP product used them.
It was somewhat expected that Google would open source them, but that has left the issue of an SLA wide open – there was no real way you as a customer can get an SLA from Google for maintaining and improving the GIPS voice engine any longer. And it is an issue, as a lot of GIPS customers used customized voice engine packages – ones that fit specific hardware and embedded processors.
With a limited number of alternatives around, companies had to find other solutions and at times invent and invest in their own home grown solutions. No fun there.
This shift of power can be beneficial to some:
- Companies who were lacking a good voice engine solution but were willing to invest engineering resources on it now have a great starting point – they can take WebRTC and embed it into their own products – web based or not.
- Small software vendors can now offer engineering services around WebRTC or rather GIPS’ earlier solutions, providing an SLA for those searching for it.
Addition of new voice transcoders
If your product deals with voice codecs, it should probably now add those supported by WebRTC inherently. These codecs are different than the ones used in most SIP deployments. While there is a common denominator – G.711 – that’s a poor man’s solution.
This means that VoIP products now need to add iSAC and maybe iLBC to their arsenal. Not hard, but still a pain.
“Translators“ from SIP to… web-something
As WebRTC has no real signaling attached to it, it is half the solution. The rest of the VoIP world is still mostly SIP (I am ignoring Skype and Gtalk on purpose here), so to offer something here, companies will need a kind of a gateway from SIP to the open ended JavaScript signaling of WebRTC.
Why is that important? Once solutions that use only WebRTC start surfacing, there will be a need to connect them to the “other” world. That of SIP and PSTN. And this requires gateways.
–
It is going to be interesting to see how this evolves moving forward.
Don’t assume that WebRTC will have to connect to the other world of SIP/PSTN. Anyone with a computing device, phone, tablet, computer & new TVs will enjoy better, cheaper, more efficient voice, video and messaging without any SIP or PSTN. VoIP has provided a transitional phase but it no longer makes any sense to emulate, connect to, or support the PSTN.
Trent,
I agree with you on the first part – future communications will not be limited or hindered by such concepts – assuming WebRTC gets the same robustness as other HTML features.
And even once that happens, there will be a transition period, where some of the WebRTC services will need to connect to SIP and/or PSTN.
One thing is good for WebRTC developer is that you can add your favorite signaling. I would say that H.323 and 3G-324M over ip are more suitable for the mass deployment.
Hong-Quan,
You are correct – developers can use whatever they want.
My first selection would be either XMPP or SIP – or a proprietary thing.
H.323 would go next.
3G-324M won’t work at all as it is a circuit switching technology that isn’t really suitable for IP.
how can you ignore skype?
today it is the biggest enterprise video conferencing system in the world!!
Skype “users made 95 billion minutes of voice and video calls” during the first half of 2010, with a full 40 percent of those minutes being video.
37 percent of users surveyed say they use Skype for business purposes
so roughly we have 95B*40%*37%=14B enterprise skype video minutes during 6 months!!!!!
I am ignoring Skype because I don’t see them connecting to anything else anytime soon – besides maybe Lync, but that is yet to be seen.
And if we are talking about Skype, then they were the first to adopt VP8 a few months ago so they are ahead of the rest in the potential to use WebRTC. If I were Skype – that’s what I’d use.
Gateways are already there and you can make a call to SIP or PSTN using WebRTC right now http://blog.zingaya.com/2012/03/29/webrtc-version-of-zingaya/
Alexey,
That is exactly what I am talking about – companies such as your own connecting the “old” world of SIP/PSTN (or others) to the new one of WebRTC.
There are going to be many ways of doing that moving forward.
In addition to the codecs already in WebRTC, you should also make note of Opus, which is just being moved towards RFC status, and which can handle all the way from G.729 bandwidth levels to 44KHz multi-channel audio at hundreds of Kbps, and do so while equaling or beating existing codecs (including iLBC and iSAC) at the same bitrates – and it’s free. We at Mozilla are pushing hard to get the IETF to adopt Opus as a mandatory-to-implement codec in addition to G.711.
Randell,
Thanks for the tip – I’ve seen that progress around Opus but haven’t given it much thought yet. I’ll definitely be looking to it more closely now.
Hi Tsahi,
First of all a very informative post.
Though what I would like to know is if I say download the webRtc code, will it have any ‘default’ signaling stack(say SIP) as part of its architecture?
I am not a web developer but plan to use webRtc as part of an embedded end point(a Voip phone for instance) and the signalling part of webRtc is currently a bit of a grope in the dark.
Thanks & regards,
John
John,
There is no default signaling for WebRTC, and I think this is what makes this standard/package so great. You can use whatever you feel like: XMPP, SIP (both have JavaScript packages these days) or you can use your own proprietary mechanism on top of JavaScript.
If you are looking to connect to a third party PBX or an existing ecosystem, then I suggest you try and look for a SIP implementation (http://sipml5.org) and even checkout what Asterisk are doing to support WebRTC on the server side.