Last week during WebRTC Expo we saw enormous activity regarding WebRTC. Even though people list many use cases, most of the demos and announcements were related to Unified Communications (UC). They were all good, but in a way disappointing because they didn’t take full advantage of rearchitecture afforded by WebRTC. Most widely held mindset seems to be to continue with the current architecture with browser-based clients making peripheral change in the clients. I would like to take comments made by Andy Abramson and Vincent Perrin as a springboard to expound my view that we have to reorient our thinking.
In a blog post Andy observes that WebRTC has the potential to “kill off” softphone business, if WebRTC apps/services fix a couple of things. He makes the following observation:
… for the most part softphones are not easy to work with, set up or manage unless you’re an IT guy. … More importantly, the services all need to do a better job with identity and management of multiple accounts. … like GrandCentral [WebRTC apps] need to give you one single sign on and manage many different identities, all in one place. That way, a customer with multiple accounts can manage their online communications life in one place. … [No one is doing] Single sign on, multiple accounts. Right now, it’s all one username, one account, one browser window. Sorry, but I for one don’t want multiple windows with multiple accounts on the same service to be running.
While commenting on an unrelated blog post, Vincent observes that
you won’t be able to be called except if you are in the right page at the right moment.
Both of the comments to a certain extent reveals a widely, if wrongly held view regarding the roles of clients and apps. In this post I would like to describe how I view the architecture and why these issues are not there under this architecture.
- I do not consider a web page served by an WebRTC app replaces softclient. Instead, I consider the full browser (not a single app) taken as a whole replaces softclient.
- The browser supports Notification API and WebRTC apps will use it to notify the user to notify events like an incoming session initiation request.
- WebRTC apps will use third party authentication mechanism to authenticate users. After all the standard requires this mechanism when the end users want to authenticate each other over the Peer Connection.
- A user’s address book is nothing more than a bookmark folder in the browser containing names of the contacts and their corresponding WebRTC URIs.
- The workflow for initiating a session is for the originating user to visit the the other user’s “WebRTC URI”, which will point to the app server among other things. At that time, the app server will authenticate the originator before proceeding further.
Given these, it is straightforward to see that none of the concerns expressed by Andy and Vincent are valid.
Since the apps are using Notification API to indicate incoming session request, there is no need for the user to be in the “right page at the right moment”. It is enough that the apps are properly registered so they can notify the user’s browser. Given that the browser can be concurrently “logged into” multiple id providers with the user selecting the relevant id as needed and that the apps use 3rd party authentication mechanism, we can easily meet Andy’s requirement that there be a “single sign on, multiple accounts”.