Do telco network voice/messaging capabilities need to be "exposed" via 3rd party APIs?

For several years now, we've watched telecom operators try to court application developers, offering APIs for a variety of network and database functions. These have ranged from billing-on-behalf, through to SMS and phone call initiation, location lookups, authentication and so forth. Some of these have been offered by operators acting "solo" (most larger operators have developer programmes), while we have also seen standardisation efforts through organisations like OMA and GSMA's OneAPI programme.

All of this is seen as a way for telcos to:
a) Build revenues by charging directly for the APIs
b) Gain mindshare & relevance among Internet & IT developers, building an "ecosystem"
c) Potentially move up the value chain beyond "minutes and messages" into CEBP (communications-enabled business processes) or application rev-share models

Usually, the network APIs have been just a part of a wider developer-facing effort, which has also provided developer tools, testing facilities, and even funding through associated incubators and VC arms. While some seem to have gained quite a lot of critical acclaim (eg Telefonica's BlueVia), the actual results - especially in monetary terms - have been lacklustre. Most operators have now moved away from operating their own appstores, for example.

I see a few problems that have contributed to this state of affairs:

• While developers understand the role of device-side APIs (for creating smartphone apps, eg on iOS & Android) and web APIs (for creating mashups, eg with Google Maps), they have much less awareness or understanding of the role (and possibilities) of in-network telco APIs
• Various telco API initiatives have been quite poor - the actual functionality, or the way it has been packaged, has not fit well with the way developers design their applications or services, or has been poorly documents, or have required clunky sign-up or registration processes.
• Telcos are seen as slow and uncool (important for developers)
• If you're not a telco person, it's difficult to get your head around how the networks actually work and for whom. If a user calls into a company's call-centre, does the operator API work via the user's network, or the company's provider? Apps are always user-centric (and must be downloaded), but applications are server-side

The last point is really critical. It's the difference between apps and applications, and goes right to the heart of whether operators have a chance to resuscitate their falling SMS and telephony revenues (and usage).

I've long talked about the limitations of telephony, and it's also something that Martin Geddes and I cover in depth at our Future of Voice workshops. Phone calls are old, clunky and really not a great experience - they're often interruptive, there's no upfront indication why someone is calling, there's no context info beyond caller ID, they're charged per-minute (which may be an inappropriate metric), and they come with a whole set of social and etiquette rules that may diminish the value of an interaction.

The question is whether the best way around this is to avoid using "calls" at all, and just shift to other forms of communication: "non-telephony voice apps", or completely abandon voice and shift to messaging or other ways to interact. If I want a taxi nowadays, I use a London cab company's app, which is faster and better because I enter the address, get a price quote, time of arrival, vehicle registration and so on. Much better than trying to speak to a dispatcher, from a noisy pub or restaurant.

But the other option is to try and reinvent  the phone call - and the phone network - to be more useful, and work around some of the deficiencies of the format. We've long seen "call me" buttons on company websites, but how much more valuable would be "call me, with your agent having been sent the web-form I've filled in 80% and then got stuck, so they can help me complete it". That's clearly not interruptive (I've requested it), it's got context (the partially-filled form), maybe it's recorded by me or them, and I'm not paying for it - and maybe they're paying by a metric other than a minute.

The problem has been that that's not just a telco API. It's both a telco AND web API, working together. It's also (probably) not inside a smartphone app, but just uses the regular phone dialler as the UI. Which makes it very hard for a company to specify, a developer to produce, or for a telco to enable. Add in that the company might want to give its customers the option to connect via both traditional phone calls or VoIP ("Skype me"), plus various styles of messaging, and it becomes harder still. They might also want to have all this integrated into a smartphone app that  their regular customers download (eg bank, airline etc). Add WebRTC into that for in-browser comms in future, too.

(There are many other use cases beyond call-centres, but this is a good illustration).

Looked at that way, it becomes clear that the telco network call-initiation API is only an ingredient of a much broader "meta-API" (probably) provided by somebody else.

This is why we're seeing other companies start to sit between telcos and developers - Voxeo and Twilio probably being the best-known examples. They are able to help developers put together those sorts of useful functions that don't need have to have a downloadable app, but run using "legacy telephony" updated with rich context and programmability. They can still exploit ubiquity where appropriate (ie everyone can call/be called), but work around some of the human psychological and behavioural downsides of a 100-year old service.

We've seen various partnerships already - Voxeo & DT, Twilio & AT&T, for example - and I think we will see quite a lot more. Apart from anything else, those companies are "web telephony" players, and don't have the same anti-coolness stigma attached to telco APIs. They may also be in a place to create more sensible business models that don't boil down to minutes.

I see parallels here with other areas of telecoms. Jasper Wireless does much the same intermediary role for M2M - it provides a platform for telcos that turns their network capabilities into something that device manufacturers can actually use to develop new service models. Most telcos wouldn't know how to deal directly with a company that makes washing machines or digital cameras, so having an intermediary layer makes sense. We may also see the same for authentication/ID services, and of course we've long had SMS aggregators or external advertising networks that also essentially help telcos monetise their network resources or customer data assets.

This range of API intermediaries might even be able to salvage something from the wreckage of RCS (certainly, various of them are hoping for it). They could also be the ones who manage to put some lipstick on the IMS pig for developers, although I suspect that will be very market-dependent and won't work on a generalised global basis.

Where I think this approach will struggle is with consumer-to-consumer services, which are increasingly going to be be app-based on smartphones or tablets. There will probably be reasons to bridge between phone calls, SMS and websites on occasions, but I think that Viber, Skype, Facebook and others will still develop the majority of their comms functionality on a direct-to-user basis, without the need for "embedded" telco functionality in the form of telephony. I'm unconvinced that some of the niche-specific uses of voice comms (eg karaoke, baby monitors, voiceprint biometrics etc) will use telco "raw ingredients" rather than app-style OTT VoIP or (in future) WebRTC.

But for companies and brands, this new layer of meta-APIs, which incorporate some telco APIs "under the hood" has some interesting potential. Less clear is what proportion of the value flows to the operators, versus the new tier of Twilio, Voxeo et al in the middle.