This week, Daniel Pocock showed that WebRTC is not just for the phone by bringing it to one of the largest web content delivery platforms. The community that supports Drupal is full of fresh ideas in open source code that make developers lives easier and their sites more robust. Now, Daniel Pocock, building on his previous work to put convenient WebRTC solutions into the hands of the free software community, has created the DruCall WebRTC module for Drupal.
DruCall makes it easier than ever to put click-to-call functionality into virtually any Drupal powered web site, whether you run a personal blog or the United States Government (the White House really does use Drupal). Anyone wishing to deploy DruCall will need a WebRTC (SIP over WebSockets) capable SIP server. Both the major SIP proxies have this capability now in their development versions.
Given Daniel’s enthusiasm, I sent him a quick note with some questions and it’s clear he has a good grasp on what is possible with WebRTC. See that discussion in full below.
First of all, do you expect that companies that use Drupal sights will connect them to whatever voice network they use?
DP: Absolutely. Most modern phone systems already support Session Initiation Protocol (SIP) with some kind of interface module. More progressive companies already have SIP as the core of their phone system, using a full-featured platform like Asterisk or FreeSWITCH. I recently spoke with one international bank, headquartered in Switzerland, that is using Asterisk and SIP over their VPN as their global communications platform. Although SIP is not a mandatory feature of WebRTC, it is the variation of WebRTC used by DruCall. For those companies that have invested for the future and have a SIP capability or a full SIP architecture, they are already in the right place; DruCall may work for them now without any substantial change. At worst, they may need to upgrade their Asterisk or FreeSWITCH server to the latest version.
Do you expect that a community of users will be gathering on these sites so a DruCall network gets associated with the site itself?
DP: WebRTC is not just a new alternative to low-cost calling cards, but a whole new paradigm in communications. DruCall goes right to the heart of the community concept, as it can be integrated so tightly with existing Drupal user bases. Instead of associating with a brand like Skype, people will be building their identity through communities like football clubs, industry associations and political blogs. DruCall (and WebRTC in general) brings their RTC experience under the umbrella of that preferred identity.
What needs to be emphasized here is that SIP (and also its sexy twin, XMPP), are both federated protocols. This means that users of these technologies are not stuck in a 'facebookesque' walled garden, rather, they can conveniently (at a click) make a call to a user from another community who left a passing comment on their blog.
Does that mean companies are going to have to have attendants using their browser to stay connected to the site (or at least their jabber client?)
DP: It is interesting the way you ask "have to have attendants using their browser" as it almost gives the impression that this will be a painful thing for companies.
In fact, one intention of WebRTC is to make the browser the dominant paradigm in the user-interface domain. It can be predicted that companies will ask if they "have to have phones on their desk with exorbitant recurring maintenance fees" when they can just do everything from the browser.
In practice, there will be a period of parallel running when call center staff has both a browser and a legacy phone. Audio from WebRTC can be delivered in the browser, and if the legacy phone system supports SIP, then the calls can be brought in through a regular handset without the
user needing to keep the browser open at all. For those companies that want to support video calls, using the browser will be very compelling.
Another possibility that needs to be emphasized is the ability to create call centers that are almost infinitely scalable in a minimum amount of time. Can you imagine Chile's 2010 earthquake or Fukushima replicated on the West Coast of the U.S., and the Red Cross is able to E-Mail volunteers on the East Coast and ask them to click a link and participate in a call center? All of a sudden, tens of thousands of people, even public servants sitting at their desks in Washington can be roped in to handling requests for assistance, locating missing children, processing donations of food and clothing, etc? Only WebRTC can scale in this manner, due to the way it leverages ubiquitous browser technology.
Given that you have connected this up through Jabber do you expect that Jabber and Drupal are going to be early adopters?
DP: Actually, it is based on SIP, although it could be done with Jabber.
There are currently two low-level SIP implementations that run over WebRTC, SIPml5 and JsSIP. DruCall is based on SIPml5. There are already plenty of Jabber/XMPP solutions that run in a browser (like the popular Candy web chat client) and it is inevitable that these solutions
will offer WebRTC capability sooner rather than later.
Drupal is one of the most widely used CMS platforms and offers a convenient modular architecture. That means that non-programmers can easily drop in the DruCall module and get almost immediate benefit.
This enables a solution like DruCall to gain widespread deployment with very little effort from the developer (myself) and this is why I have offered it in this form first. As Drupal is based on free software and a spirit of "collaboration over competition" I'm also hopeful that people are already extending the module to do things that I hadn't even thought of myself.
The SIPml5 SIP client for WebRTC can also be installed as a Debian or Ubuntu package, but then the system administrator or web site owner needs to customize the JavaScript and HTML to integrate with their web site. With DruCall, that customization work is not necessary.
Do you have any plans to support Wordpress? Or Google Sites, etc...
DP: Replicating this project for other CMS platforms is not particularly difficult, it just requires some time for a developer to familiarize themself with each API. Given the way that free software evolves, it's quite possible that users of those other platforms who know the APIs will dig into the DruCall source code and adapt it faster than I could do myself. However, if a commercial driver appears then I might be able to prioritize some of these other platforms and support them formally. I suspect the DruCall name would not be adaptable though, maybe the Wordpress variation will be branded RTCpress?
Edited by
Stefania Viscusi
