MetaSwitch "Innovators" and BroadSoft's "Marketplace"

Last week, MetaSwitch (part of Data Connection Limited, DCL) launched the "Innovators" site. It's similar in spirit to BroadSoft Inc's "Marketplace". They're both intended to spur "Client Development".

Both are major VoIP software companies. MetaSwitch also handles hardware. Both keep their ordinary documentation locked in customer-only web sites. But both have released just a tiny bit of their documentation through these sites -- documents about "client" application development.

What's a "Client" for BroadSoft and MetaSwitch? What's it good for?

Both MetaSwitch and BroadSoft make call control systems. They're "VoIP Softswitches". They replace "traditional" telephone switches, like the Lucent 5ESS or Nortel DMS. A telephone company would buy BroadSoft's BroadWorks, or buy a MetaSwitch system, then connect customers to it. As a customer, you'd pick up your phone and make a phone call, and BroadWorks or the MetaSwitch does all the work necessary to connect your call to the person you called. They also handle things like Voicemail, and fancy features like find-me-follow-me routing.

They both have software interfaces to write "Client" applications. Carbon-12 was a company that wrote a BroadWorks client "toolbar"; it let you dial calls, answer calls, transfer calls, etc. from a toolbar installed in MS Internet Explorer. BroadSoft bought them and now it's called the "BroadSoft Assistant". MetaSwitch has also developed a similar client for their system.

Both BroadSoft Inc and MetaSwitch/DCL apparently believe that there's a market for other clients. And to help make their case, my company did develop a Mac client for BroadWorks, called Attache.. We did it mostly because we had plenty of time in the slowdown of 2008, and we're a desktop-Mac OS X shop. We wanted a client for ourselves. Attache is a lot like the BroadSoft Assistant (toolbar), but it runs on Apple Mac OS X.

BroadSoft's Marketplace / Developer Sites

Marketplace has been going strong for a while. It has several applications posted on it, including Attache. There's a sister site, developer.broadsoft.com that has documentation. They have some of BroadSoft's documentation -- but not all:

  • OCI-P -- The Provisioning Interface
  • OCI-C aka CAP -- The Call-Control Interface (used by BroadSoft Assistant, ADP, Attache, etc.)
  • Xtended Interfaces, aka XSI -- The new HTTP-based "REST-ful" interfaces for call control. Unfortunately, the XSI requires a new server that most BroadWorks service providers don't have (yet), but should.

In addition to the Developer and Marketplace sites, BroadSoft runs its customer portal, Xchange. That site has the actual documentation and software patches used by Customers. All three of those sites (Developer, Marketplace, and Xchange) have discussion forums and question-and-answer capabilities, but BroadSoft customers know that the fourth site, ExtraView, is where you actually ask real support questions to get official answers from BroadSoft Inc.

BroadSoft is eager to see new applications built against its platform. They've announced a contest with cash prizes to encourage developers to build applications.

MetaSwitch Innovators

The new MetaSwitch Innovators site started just last week. It also has limited documentation:

  • CommPortal Customization Information
  • Call Control API Information

Like BroadSoft, MetaSwitch has a separate site, the MetaSwitch customer portal, where the real documentation lives.

VoIP System Agnosticism

In addition to BroadSoft and MetaSwitch, Asterisk is the elephant in the room. Sure, it's not "carrier grade", but carriers are using it -- the same way Carriers and Enterprises were using Linux in 1995 before it was "enterprise ready".

Many open-source database-driven applications are built to run on different databases. For example, Request Tracker, RT, from BestPractical runs on MySQL and Oracle. By similar logic, any software developer with Computer-Scientific dignity will shriek with joy to build new layer of abstraction over a clever new service. By building their tools to span VoIP platforms, a developer can market his tool to a wider market. MetaSwitch, BroadSoft, and Asterisk all have some external call-control logic. So if there's a good tool that someone can develop for one platform, they should be able to port it to others.

Where's all this going?

Only So Many Click-to-Dial Systems Needed

Most of the client applications are effectively click-to-dial tools. For example, there's a nifty way to use Salesforce.com and a BroadSoft BroadWorks account to place calls to people in your contact list there. But you can also do neat things with incoming calls: For example, ADP Inc, the Payroll Services and Car-Dealer Services company, has integrated both BroadWorks and Cisco Call Manager into their Dealer Management System. When a car-buying prospect calls a car dealer using that software and the right phone service, the salesman receiving the call can automatically jump to the information about that person calling.

The world only needs so many desktop phone control tools like Attache or BroadSoft Assistant. The real question is: what other interesting things can people do, in addition to desktop clients?

Already Other Ways To Control Calls

VoIP lets you connect your computer to the PSTN; to make and receive telephone calls. We already have SIP for doing this. For "serious applications", like Call Centers or Call Recording, you typically see external application servers that function as SIP Back To Back User Agents (B2BUAs).

What do the Client APIs add on top of SIP?

The clients add Third Party Call Control (3PCC); i.e., in addition to the two ends of the conversation, the client can manipulate the call -- placing the call initially, putting it on hold, transferring, etc.

And the 3PCC is without the use of SIP. I.e., I don't have to implement a full SIP stack, and function as a B2BUA, to control the calls. The Call Control APIs try to reduce the accidental complexity of controlling calls.

Fundamental Human Limitations on Client Applications

In what circumstances is it appropriate for a system to manipulate the call? Both sides of the conversation have to be OK with the call manipulation; either by being unaware of it (as happens when a call is dialed), or by causing it (e.g., by clicking the "Transfer to Bob" button), or by understanding that it will happen automatically (such as happens with a call center).