How WebRTC could replace softclients
Jun 29th, 2013 by Aswath
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”.
Interesting, as always. Agree, there could be a paradigm shift.
Do think we need to assume very heterogeneous (but not necessarily integrated) workflows and architectures. C to C, B to C and B to B could all be very different for example.
In your example, where does the user get his URI…other than those of us that will run our own web servers ; )? If from an ASP of some sort (e.g. the operator of the app server), would it often come *bundled* with a client from that ASP (abstracted from user)?
Thanks for your comment.
I don’t think it matters whether it is C2C, B2C or B2B. I think the paradigm works. Same for URI. Even if the ASP wants to supply a native client, it could be built on top of a “WebRTC browser” base; also they could use WebRTC when the user uses a BYOD for which they do not have a native client.
Aswath,
If single authentication of multiple accounts is so easy, then build it. Most of the folks I talk to feel under the current approaches its not that simple.
Also, if the apps today are nothing more than customized browsers, then WebRTC is the next generation of those. I don’t see why this is not valid.
Andy,
I am a bit surprised at your comment. So let me understand your requirement. You have a single ID that you would like to use with multiple WebRTC apps. If that is your requirement, I am suggesting that this can be done using 3rd party authentication methods like OpenID/OAuth/SAML etc. As I say, the std calls for this scheme for the end users to authenticate themselves over the Peer Connection. Also, yes I have done this. Not now, back in 2008 and yu have seen the demo as well.
Secondly, if your requirement is that you want to use a single sign on, but project diff id at different apps, then that is also possible if your ID provider offers such a capability. For example Yahoo’s OpenID provides for this capability.
Thirdly, if your requirement is that you want to derive your id from the app provider themselves, then I am suggesting in the post that you should sign into those apps with browser maintaining the credentials and presenting them as and when required. Browsers have this capability and so nothing new to build.
So will you please clarify what is your requirement. I am just missing to see the difficulty that others are seeing.
I am lost on your second point.
Thanks
Aswath