"Open" phone call routing with OpenVBX

Silicon Valley startup Twilio released an open source phone-routing application framework named OpenVBX last month, branded as "the web-based, open source phone system for business." As is often the case with web services, though, using open in the product name does not necessarily mean customers have access to all of the code.

Twilio itself runs a commercial phone routing service, currently supporting inbound and outbound U.S. phone calls and SMS messages and outbound-only international calls. Unlike consumer-oriented offerings such as Google Voice (which offers a turn-key application that routes incoming calls and text messages, among other things), Twilio's service has always targeted developers. The company's service offers an API, to which developers would write their own PHP-and-MySQL applications to dictate call routing, call logging, voicemail transcription, or other functionality.

Up until the launch of OpenVBX, Twilio users were building their own applications from scratch, with some reusable code-sharing among the community, and using Twilio's own collection of prefabricated application components called "Twimlets." Some developers, such as OtherNum, even wrote their own full-fledged "virtual branch exchange" applications on top of the Twilio service.

OpenVBX is essentially one of those virtual branch exchange applications (hence the VBX) written by Twilio itself, and released under the Mozilla Public License. Users install OpenVBX on their own server, define call routing plans (called "flows" in Twilio's documentation), configure user accounts, write custom scripts and plugins, and even set outbound phone numbers. All of the actual call routing, however, is done on Twilio's cloud service, which charges per-minute and per-message rates and leases local and toll-free U.S. phone numbers.

Calling all servers

For those simply wanting to set up a voice-response system or basic business switchboard, OpenVBX is impressive both for its straightforward setup and its ease of management. The OpenVBX server requires nothing but a basic LAMP stack and a Twilio account to install and configure. Interested users can download the source code, or install it as a one-click-installer option if using the Dreamhost hosting service. For those not ready to pony up for a Twilio-provided phone number, the company offers a free "sandbox" number complete with $30 in calling credit. Apart from the sandbox, however, there is no way to test or deploy OpenVBX other than paying to lease a phone number from the company.

Once installed, administrators can use the OpenVBX dashboard to add user accounts and phones (both mobile and land line). Each user account has an associated inbox, which stores SMS messages and voicemails (in audio and transcribed form), and can initiate calls and send text messages through the web interface.

This level of service makes OpenVBX akin to a multi-user, in-house alternative to Google Voice. The real power comes from the ability to do more complex call response. Administrators can lease multiple Twilio-provided numbers and configure the behavior of each one individually, by connecting it to a particular "call flow" and/or "SMS flow."

Flows are assembled in the browser with a drag-and-drop visual editor. The flow editor walks the administrator through the process, starting with the question "When a call begins, what should we do?" — which can be answered by dragging one of the available applets onto the empty outline box beneath the question. Playing a message, recording a voicemail, routing the call to one of the outbound numbers, and offering an interactive menu are among the basic applets. Each applet has its own simple configuration, allowing voice prompts to the caller via computer-synthesized voice, pre-recorded message, or digital audio file, and more.

The built-in applets offer enough functionality to route incoming calls based on caller responses like a traditional phone tree, plus a few modern niceties such as initiating conference calls, or sending an SMS to notify users of a new call.

But the really interesting possibilities come through third-party OpenVBX plugins, which can not only enable new routing functionality (such as routing based on keyword matching against incoming SMS messages), but can tie the OpenVBX system into any other web application. Plugins already exist to check whether the caller is in the Highrise customer relationship management (CRM) system, to check for the caller's location via Foursquare, and to open a ticket in the Zendesk customer service system, among others. Installing a plugin is as simple as unzipping the downloaded file to the OpenVBX /plugins/ directory and configuring it through the web administration panel. Third-party plugins are linked to, but not hosted by, Twilio, and may have their own licensing terms.

Performance-wise, OpenVBX delivers as advertised. In my own test, it introduces no noticeable lag to calls, processes scripts quickly, and provides good voice quality. The synthesized text-to-speech voice leaves something to be desired, but what it lacks in personality it makes up for in clarity.

Twilio provides detailed documentation for writing OpenVBX plugins, including message handling, the user interface toolkit, and the APIs for data, users, and groups. For more detailed help with the Twilio API that connects an OpenVBX instance to the Twilio service, there is additional documentation at twilio.com.

Nice enough, but open enough?

Considering how easy to use OpenVBX is, it is unfortunate that it builds on a proprietary API and a closed flow description language (TwiML). Strictly speaking, it would be inaccurate to call OpenVBX an "open core" product, since the open layer is on the outside. Nor really would it be accurate to call it the opposite (open veneer?), because the Twilio service itself is a load-balanced farm of virtual servers running the open source Asterisk switching software on Amazon's EC2 cloud.

Clearly a cloud-based Asterisk or FreeSWITCH instance is something that a lot of customers want; Twilio has no shortage of competitors offering a similar service that frees the buyer from hardware requirements and allows per-minute billing. In addition, the layer that Twilio places in between Asterisk and OpenVBX simplifies configuration — but there is no reason for it to be proprietary. TwiML, for example, duplicates the functionality of the W3C's open VoiceXML standard.

Moreover, Twilio seems to discourage would-be platform developers from porting OpenVBX to a different backend. The FAQ page says in response to the question "Can I replace Twilio with X as the backend for OpenVBX?":

Elsewhere on the page, the company says it may accept patches into OpenVBX's trunk after evaluation by the project. A more open attitude would probably attract more developers to the project, because a friendly front-end is something that all Asterisk users, not just Twilio, would benefit from.

The race is on

In fact, maintaining its middleware stack as a proprietary layer does not guarantee Twilio any chance of success. Already, cloud-phone-service competitor Teleku announced that it would support the full Twilio API and TwiML alongside its other services, hoping to attract OpenVBX users — something that it could not do before OpenVBX's release due to incomplete public documentation. Twilio provides extensive API documentation, bundled with a more liberal LICENSE document than is applied to the OpenVBX code (requiring only copyright notice reproduction), making such interoperability trivial to implement. There are also several independent Twilio API-using developers who were put out of business by the release of OpenVBX itself who are now looking for something else ot occupy their time — including the creator of OtherNum, mentioned above.

In addition, other Asterisk front-ends are available that can tie in to cloud-based call-routing services, such as OpenVoice, which is designed to work with the Tropo cloud service. Since the OpenVBX source is available, too, perhaps Twilio should expect ports to other backends or complete forks just because interest in phone routing is on the rise. Despite what Twilio does offer through its cloud service, there are several big gaps: no live voice recognition, no integration with instant messaging services, and — most notably — no SIP support. Considering these areas without feature coverage, acting like a fork will not happen is a formula for being left behind.

All things considered, OpenVBX is a pleasure to set up and run. Installation and administration are simple, the feature set is powerful enough to deploy in the field, and the quality is good. The only down side is the proprietary middle-layer between an excellent open source telephony server and an excellent telephony front-end. Hopefully Twilio will see the strategic value of opening the entire stack in light the highly competitive — and growing — voice application space.