Voxeo Labs Ameche – The Telco Platform Approach Evolves…

Posted by on October 30, 2012 in Blog | Comments Off on Voxeo Labs Ameche – The Telco Platform Approach Evolves…

Voxeo Labs Ameche – The Telco Platform Approach Evolves…

Voxeo Labs just released their communications PaaS (cPaaS), which they’ve named Ameche in a tip of hat to Don Ameche in his portrayal of telephony pioneer Alexander Bell.

Ameche enables applications to run “in a call” hence the Ameche moniker: “Apps in your Calls” (a Voxeo trademark). It’s a great addition to the existing Voxeo Labs programmable voice products (e.g. Tropo), but this time aimed at operators to allow them to offer programmable-voice capabilities on existing subscriber number ranges.

I’ll say that bit again – on existing numbers!

I just hope that it comes to an operator near me sometime soon…

I built my first telephony app back in the late 90s when I founded one of Europe’s first mobile apps companies. We hacked a Dialogic telephony card in the back of a Windows server in an attempt to build our own PBX solution connected to an instant messaging app that we built atop of MS Exchange. We also built a crude CRM (ASP app) for logging sales calls. It seemed like “programmable voice” was just around the corner.

For serial inventors, deja vu is a common experience. In Ground-Hog-Day fashion, we often feel like we’ve had the same conversation over and over. When IMS was invented, some of us got excited about “programmable voice” in the network. The IMS standard included an Application Server concept. It has various configurations, including the ability to allow an application to sit “in the middle” of a SIP call.

I wrote a conference paper (sponsored by Wiley) solely about this concept, which later became a chapter in the 2nd edition of my Next Generation Wireless Applications book (2004/6).

My favourite app idea at the time was a taxi-hailing application. The concept allowed a caller to dial a generic “TAXI” number and automatically be routed to the nearest available taxi. Or, as it was supposed to be an IMS app (with it’s associated IM apparatus) the cab could he hailed using an IM client. Again, the message popped up on the nearest cab’s device.

As Motorola’s Chief Apps Architect, I ended up building the taxi app atop of an Asterisk server whilst running the “Mashing Room” lab for their nascent apps vertical. It was part of a variety of use cases that we used for IMS presales, mostly unsuccessfully for all the usual (carrier-myopia) reasons.

Roll on a few years…

I tried again with Telefonica/O2 when I proposed and led a “platform initiative” that included exposing the subscriber’s text message stream in the same “in the middle” fashion, via an experimental service and API called #Blue, about to be closed (as the capabilities are going to become mainstream inside of a more production-ready platform).

I then extended this to a wider platform vision called connFu, aimed at exposing the call stack, messaging stack and associated real-time streams (e.g. Twitter) via a single API set (initially exposed via a Ruby DSL). My understanding (I no longer consult for Telefonica) is that the concept has been re-imagined as part of the Tu Me platform, although not exposed to external developers.

Voxeo Labs has succeeded where Twilio hasn’t in bringing a solution to the gargantuan market of existing mobile subscribers by offering a well thought-out carrier solution. This is to be expected because Voxeo Labs combines the carrier-grade product experience of the parent company (via its high performance Prism SIP product) with the developer-friendly experience of its Tropo platform, which already powers a ton of apps.

Besides the four use cases mentioned on Ameche’s landing site, the possibilities for programmable voice really are endless. The so-called “death of voice” (not profitability)  has been greatly exaggerated. Whilst it is interesting to note that, as an evolutionary adaptation, we have become much better under various circumstances in communicating via our finger tips and thumbs (tapping on keyboards) than we have with our mouths and ears, voice remains a central human experience.

The problem has been that innovation in voice communications has not been possible. Even Apple’s attempts (via Visual Voice) were largely unsuccessful. However, with the right ingredients, innovation is possible. The question remains as to what are the right ingredients.

Clearly, programmability is only one element. Ameche ticks that box.

Next, we need low-friction adoption, which mostly comes from allowing users to use their existing numbers. Ameche ticks that box too.

So, what else?

Well, we still need the right circumstances and environment to attract developers. This is a complex topic. As we’ve learnt over the years, the developer “market” is just as segmented, if not more, as any other market. Ironically, it was a carrier that brought this to the attention of other carriers when Telefonica’s BlueVia project sponsored VisionMobile to produce the “Developer Economics” survey/report.

Different segments behave differently, but across the board, they all reportedly seek the same thing from any platform, which is market reach. Within a carrier configuration, developers usually baulk at the idea of a solution that only works with one carrier (where adoption is asymmetric). So, we must hope that Ameche is adopted by multiple carriers and/or that the API is open and adopted – de facto – by other carriers atop of their own solutions (e.g. Telefonica’s Tu platform, if it ever makes its way into the BlueVia family of APIs).

Again, somewhat ironically, Telefonica has shown initiative in their ability to partner with Telenor to form a single developer-facing co-operative under the BlueVia banner. What we need is a combination of this pragmatic approach (versus the WAC-y way) and wide scale adoption of Ameche or Ameche-like APIs. We might just see a runway effect. Let’s hope so.

Regarding the asymmetric adoption issue, I think there is a difference in this case, although subject to how well carriers promote and execute Ameche as a carrier service. The difference is that developers have never before been given the chance to play with the voice stack that powers their phones. It might just stimulate enough curiosity to provoke the sort of “playful” innovation that often drives early adoption of key platforms. Carrier readers would do well to read my recent book (“Connected Services“) that explores the platform paradigm in some detail, and from a carrier perspective.

In terms of economics, I think that the sweet spot will fall in the SME/Enterprise category where developers ought to be thinking in terms of monthly subscription models. This is where the billing/payment models need to be well thought through by the carriers. We can only hope that they avoid their historical tendencies to think in terms of short-term revenue targets that are out of line with seeding a long-term successful platform play.

I look forward to Ameche being available in my carrier’s network soon.

Subscribe to Paul Golding's posts and other provocative content by email