It is a matter of perspective
You probably heard the terms PSTN Sunset and IP Transformation before. In the last few years, decisions in the US and in Europe (probably in other countries as well) have been made to move to all IP and gracefully shutdown the PSTN network.
SIP is around for 20 years now (originally designed in 1996). Like many exiting new technologies, at first it seemed to many it will take the communications world by a storm.
It started in a rather simple concept (the S in SIP doesn’t stand for Simple but for Session J) which got more complex as it got acquainted with the real world of communications.
Fast forward 20 years:
- PSTN is still around although in process of being replaced in many countries
- Most businesses are still using TDM and not VoIP
- TDM still accounts for a large chunk of mobile phone calls
Even now, as PSTN sunset initiatives are driven by governments, regulators and tier 1 operators, the process is taking time. Since not all businesses are ready to retire their old PBXs, operators are offering VoIP up to the premise and a GW to connect to the old rusty PBX so the truth of the matter is that many businesses are still not VoIP in their private communications network.
WebRTC adoption
With all this in mind let’s look at WebRTC adoption. I hear from people that WebRTC has “stalled” in adoption during 2016. I had a chat about this with Andrew Prokop who mentioned this in his post Top 5 Picks in a Year of Communications Richness in which he also mentions SwitchRTC as an exciting use of the WebRTC technology (we take a different approach to the SFU media engine and use a modified build of the WebRTC Google code as the media engine).
I think differently. I actually see WebRTC continue in adoption and also see significant moves that will make this adoption even faster. The thing is that WebRTC doesn’t come to replace our house phone, mobile dialer or business IP Phone. The fact is that being an open source technology developers can change and embed it in anything they want, WebRTC usage is hard to quantify.
WebRTC changes the user experience. It moves some of the communications sessions we have previously done using Phones/apps to a different medium.
This is different from the transition from PSTN to SIP where SIP calls replaced PSTN calls in a very clear way. You got a new IP Phone or mobile app that allowed you to, well, make calls.
When I go to a business in my country and see an IP Phone from AudioCodes or SNOM (these are the phones used by the dominant local operator here), the person by the desk doesn’t even know it is VoIP. For them it is just a phone.
Other transitions to SIP are completely transparent to the end user. Adoption of SIP trunks or operator core transition to IP/IMS.
WebRTC usage scenario is different
Since WebRTC adoption results in the creation of new communication opportunities or a shift of what we used to do over the phone to an in-context session within another application, not everyone is aware of the fact that it is all about WebRTC adoption. It doesn’t fall into the normal traditional analysts’ (the Gartners and Infonetics of the world) reports of PSTN vs. VoIP metrics. It is hard to count the actual usage of WebRTC and sessions in which it or a modified version of it was used.
But, WebRTC is widely used and growing. Just a few examples from a very long list:
WebRTC is used in context of team work and business discussions.
Slack has embedded WebRTC as part of their application. When I chat with my SwitchRTC team we can easily move into a call from the context of that messaging session by simply clicking the phone icon.
When I consider a subcontractor through Upwork I don’t need to give a Skype ID or send a link for having a call. We can upgrade our messaging chat to a live call in a click of a button.
Facebook Messenger
SnapChat
…
That’s billions of users and sessions achieved in just 5 years. Compared to the adoption of “traditional” VoIP that’s lightning fast!
These types of WebRTC deployments are not promoted as a technology feature but rather as a new capability WebRTC happens to power behind the scene.
Another market indication that will impact future growth of WebRTC is projects initiated by tier 1 operators for adding WebRTC services to their networks. These include pure new services as well as adding a WebRTC interface to an existing service with a massive user base.
Conclusion
Compared to SIP, WebRTC adoption is lightning fast. It is not about replacing VoIP or PSTN. WebRTC is VoIP that extends communications to new dimensions.
Traditional analysts have a hard time quantifying the real usage of WebRTC because is it used in such a wide range of verticals and applications deployed by an undefined list of vendors, service providers and startups. You can’t just survey a short list of vendors to get their latest sales numbers of IP Phones, IP-PBXs or SBCs.
But who really cares if the adoption is accurately quantified of not. Reality is the best proof of WebRTC deployment.
WebRTC faster than SIP? Tell that to the carriers who have millions of calls running over SIP trunks. Tell that to the countless number of enterprises I work with that have rolled out SIP applications, hard SIP endpoints, mobile SIP endpoints, and are connecting up to those SIP-enabled carriers.
I cannot go a day without SIP touching my life and the lives of just about everyone else I know. The same is not true for WebRTC.
Thanks Andrew.
What you are writing is correct except for the “?” at the beginning :).
I agree that from telephony perspective SIP calls are much more common that WebRTC based calls but that’s not what I’m referring to inthe post. WebRTC adoption is far beyond telephony use cases.
2 things to point out:
First, think of the SIP deployment back in 2001, 5 years after it started in 1996 and compare.
Second and much more important, WebRTC is not deployed by the same people who deploy SIP. The examples I give in the post, Facebook, Slack, SnapChat and many others are not dealing with telephony but communications as a feature in their application. So I assume you don’t meet them in your day to day customer discussions but just know about them because you have a good understanding of the market.
Another point is that technically speaking we shouldn’t compare SIP with WebRTC because they are different things (signaling vs. media). Some even use SIP over WebSockets for their WebRTC signaling. But that’s a side point.
Amir
I always translate SIP vs. WebRTC to mean trapezoidal vs. triangular connection model. Even though, SIP also talks about triangular connection model, due to different variations of SIP, client interoperability requires trapezoidal connection model assuming there will be network elements to handle signaling interoperability. Dynamic download of signaling procedure and UI drivers via JS allows for triangular connection model for WebRTC.
There are a couple of inherent benefits of triangular connection model: 1. A WebRTC app can unilaterally introduce new features or UI components without worrying about corresponding functionality in the clients; 2. The app can enjoy the benefits of full network effect (more or less) on day 1.
For more … http://www.slideshare.net/aswath/trapezoidal-voip-is-evil
Aswath,
SIP vs. WebRTC is not an apples to apples comparison. They are 2 different things that sometimes compliment each other (SIP over WebSocket as an options for WebRTC signaling).
Moreover, both SIP and WebRTC use ICE and all the magic behind it to connect media which may result in the media architectures you mention.
To my view, the capabilities you mention at the end of your comment are not related to how media flows. If a feature (say recording) requires taking all media through a recording server this can be done regardless of how ICE procedure eventually connects media. The TURN server is anyway not involved in these features but just does TURN.
The recording (as an example feature) requires things TURN is not, like terminating media encryption.
Amir
Amir, probably you read my comment in a hurry because you are characterizing it to be related to media architecture. Not at all. I am talking only about signaling path and SIP RFC itself talks about it. My point is that as a practical matter, SIP is compelled to use trapezoidal connection model which necessarily encounters interoperability issues.
Hi Aswath,
Right. I was referring to media.
Still, Why compare SIP with WebRTC. You can use SIP in WebRTC as well.
The usage of WebRTC is typically in a specific island. Once you try to exit that Island you are in the need for some mediation as well. Same as if you try to connect between 2 SIP clients of different vendors and run into interop problems there.
In context of signaling, when talking about WebRTC, I see the lack of mandatory signaling as the important advantage.
Amir