The advent of WebRTC is opening an interesting door: the ability to use a URL as a way for anyone to contact you. WebRTC is the technology that allows your browser or a mobile device to operate as a phone. Because of this, all that’s needed is a “click-to-call” link or button on a Web page for initiating a connection with the URL that represents the recipient’s end-point of the call. These buttons have existed for a while already, but what changes with WebRTC is that browsers no longer need plug-ins, and that the end-point is addressed using a standard URL.
A simple implementation would be a URL that connects to a SIP end-point, such as a SIP phone. Anyone clicking on the URL in a WebRTC-capable browser (currently Chrome, Firefox, and Opera) would instantly set up a call from the browser (on a device equipped with a microphone and speakers) to the corresponding SIP phone. By assigning a defined URL to each employee in a company, all of your staff could also have a personal “URL to call,” in addition to a traditional phone number. Contact management systems like Microsoft Office offer the ability to add a Web site (or URL) in a contact info list. As such, it would be easy for your customers, friends and family to store a URL they can click-to-call you from their smartphone, tablet or laptop.
The “click-to-call” concept would play out something like this: let’s say I ask someone something in an email, but their response needs to be explained verbally. That person can just click the “click-to-call” image at the bottom of my email. This action would open my personal contact page. That person can enter their name and hit the phone button, which makes my desk phone ring while also displaying the name of the caller.
This type of scenario may be just the first step in how WebRTC and the Web will change communications. In the above example, WebRTC allows for a Web click to be a simple phone call to an individual, but it can be much more.
For example, when someone clicks your personal URL, they could be directed to a personal Web page capable of pre-screening people who want to interact with you. This page could ask why the caller wants to interact with you. It could require entering known identifiers such as an email address, a Facebook name, a LinkedIn page, or a phone number to confirm the identity of the caller. Alternatively (or in addition), the personal contact Web page can take a picture of the caller (after having received the caller’s consent for this action through the browser). All of these criteria can be used to confirm the caller’s identity, which can then be transmitted to you, along with the communications request. Then you can decide if you want interact, and on which media, video, voice, or text, or to request the caller to leave a voice or video message. This kind of interaction would, of course, require a different type of end-point on the other end, as a regular SIP phone would not be able to deal with this enriched information. But a softphone application on a smartphone or PC could. Especially since browser vendors will soon be incorporating enhanced capabilities into the newest browsers in order for the browser to fully function as a softphone (such as better handling of notifications).
The capabilities of click-to-call URLs extend even further. By using cookies or device information, the next time that device tries to interact, the personal Web page can take into account information gathered from the previous call. This information can be used to make the interaction more efficient or more user-friendly, by automating some steps in the process. For example, when click-to-calling the customer service of a company, a cookie could store information on whether or not you are a customer or a prospect and change the call flow accordingly. A click-to-call page could look at the language configuration of the caller’s PC, and put them in touch directly with an agent speaking their language.
Integrating communications into the Web is a powerful concept. In 5 to 10 years, most professionals will likely have “click-to-call-me” buttons on LinkedIn, companies will have click-to-call-me buttons on the customer section of their Web portal, and employees will click-to-join online meeting rooms around the world. But before we get to this point, solutions must be thought of to address some potential issues that could limit adoption:
1. How can consistent quality of calling – after all, the call travels over the public Internet – be offered? We accept variable quality for a free Skype call, but companies are not likely to accept this quality when a valuable customer calls.
2. Browsers’ limitations:
- To place calls: at least for the next couple of years, a non-negligible percentage of the installed-base of browsers will not support WebRTC. This leads to a variable user experience, which is likely to discourage enterprises from adopting the technology.
- To receive calls: receiving calls in a WebRTC-capable browser is not even close to the experience of receiving a call a native phone client. Receiving a call via a browser requires you to keep a Web page open constantly. Furthermore, today’s browsers do not have the capability to “take control” over a device to answer phone calls the way a standard smartphone client does, which will surely result in many missed calls. For mobile devices, HTML5 based smartphone communications integrating WebRTC capabilities will be the way forward, but this is still 1-2 years away. This should not necessarily be a problem, at least for enterprise applications, calls will be received not in a browser, but on a contact center agent’s phone. For this purpose, WebRTC calls will be converted to a SIP call to easily integrate with existing phone infrastructure (SIP being the most widely accepted VoIP protocol). In other words, in most implementations, the caller will place the call using WebRTC, while the called party will receive the phone call on his regular phone or UC client.
3. Identity and security are potential challenges. In order to assure that the person on the other end of the session is who they claim to be, some form of identity assertion and authentication must be included. Today, this can be done using email addresses, logins to sites like Facebook and LinkedIn, or phone numbers. These, however, require the person initiating the communications to go through an authentication process, which would be more cumbersome than just picking up the phone. There are works ongoing to improve identity management, but these are not yet widely accepted and implemented.
5. One final challenge is that WebRTC offers strong end-to-end encryption as a standard. So if someone starts up a WebRTC communication from within a company with an external user or server, there is no way to see or record the traffic. The conversation is encrypted from the user’s device all the way to the other end. For enterprises that have regulatory or other requirements to monitor and/or record conversations by employees, this may cause them to block all WebRTC traffic, much as they do now with Skype. The same remark is valid for governments, who rely on lawful interception of calls to prevent terrorism and combat crime. In a world of WebRTC communications, this will no longer be possible.