The Commoditization of Telephony and Rise of the Telephony API Carriers

December 20, 2012

Telephony is getting commoditized. It is happening not only by OTT player, but more by telephony API carriers.

Everywhere you go these days you see an API. It is the way of the world. While this is a trend, there’s a niche there somewhere – one of providing telephony APIs: instead of offering a closed solution, you offer an API for developers to do whatever they want with it.

The known ones, and probably pioneers in this space are Twilio and Voxeo. But there are others, each with his own unique twist to telephony.

The latest entrant? Bandwidth.com, who just launched their own beta APIs for voice and SMS.

Where are we with WebRTC in this regard? There are about 10 such companies who focus only on telephony APIs and do WebRTC.

  • Some have taken it to the all-encompassing area, of voice, video, PSTN connectivity – the works
  • Others are pure WebRTC players
  • There are those who do mostly video, and have both WebRTC and Flash support
  • In some cases, the offer extends to mobile by way of specialized SDKs

What do I make of it?

  • Telephony is being commoditized. The telephony API vendors are making it into a feature and enabling others to embed it into their own service
  • It makes it easier to develop and deploy voice and video services. Got an idea that requires real time communications? You can focus on that by using a third party API vendor – that’s what Wello has done
  • If you are into telephony APIs, you should find a really good story to differentiate yourself from the pack

As we are close to year end, I’ll be taking a break from the WebRTC interviews I am doing here; taking the time to collect a few more interesting interviews. The next one up will be from one of the API vendors that use WebRTC. It might give a glimpse at the inner workings and thought processes going on within such companies.


You may also like

Nocode/Lowcode in CPaaS

Nocode/Lowcode in CPaaS
Comment

Your email address will not be published. Required fields are marked

  1. Nice post. I would also add that the OTT players are likely to be disrupted by the companies using the APIs (like Wello.co, Hall.com). As live video and voice becomes more and more accessible, and is embedded across applications as a seamless feature, there will be less need to launch Skype for a call. This will lead to a ‘death by a thousand cuts’ scenario.

  2. Nice post. I would also add that the OTT players are likely to be disrupted by the companies using the APIs (like Wello.co, Hall.com). As live video and voice becomes more and more accessible, and is embedded across applications as a seamless feature, there will be less need to launch Skype for a call. This will lead to a ‘death by a thousand cuts’ scenario.

    1. That trend is already happening – simply by providing these APIs, companies are meshing them up any way they like – with our without RCS.

      1. Too shyly 🙂
        Telcos need to engage “enterprise business units” in pioneering the API plasitiline to create the new services their customer are asking for.

    1. That trend is already happening – simply by providing these APIs, companies are meshing them up any way they like – with our without RCS.

    1. Saw that one as well. I categorize it under the fact that every service these days has an API.
      The telephony API guys provide only that – “barebone” access to telephony. The Twelephone APIs enable meshups with the service you created, which makes a lot of sense to add, but it is still somewhat different in my view.

  3. Saw that one as well. I categorize it under the fact that every service these days has an API.
    The telephony API guys provide only that – “barebone” access to telephony. The Twelephone APIs enable meshups with the service you created, which makes a lot of sense to add, but it is still somewhat different in my view.

  4. I really like Wello, as it illustrates a huge problem in the telephony API world. The chase for the developer in the Telephony API world is counter-intuitive to me. Even the very successful Twilio’s and Voxeo’s fall victim to marketing to developers, and out of sheer volume stumble across entrepreneurial developers that make a successful product. This is the total opposite of what they should be doing.

    IMHO, I think the bulk of the marketing should be in going after business themselves, rarely do developers make the decision on adding telephony to the mix, they are given a project and they complete the project. The API’s are so incredibly easy and powerful to integrate the learning curve is minutes for a good developer – the killer idea and use case on how to deploy them will usually come from the entrepreneur that started the business in the first place. That person is rarely an engineer or has the ability to decipher an API document and they certainly don’t attend VoIP or WebRTC conferences, hackathons or mashups.

    So where the API has become a commodity and is dead simple, more often than not the API providers fail in relating what they can do for the average business person, they consistently look for customers in the wrong places.

    I’ve been a strategist in VoIP and Web for quite a while and I am consistently amazed at the simplistic creativity that entrepreneurs (once educated on how to add RTC to a business) come up with. The cost is so inconsequential to a web project, they always agree to start with something – once they have a basic understanding on that first project they will add it to all projects moving forward.

  5. I really like Wello, as it illustrates a huge problem in the telephony API world. The chase for the developer in the Telephony API world is counter-intuitive to me. Even the very successful Twilio’s and Voxeo’s fall victim to marketing to developers, and out of sheer volume stumble across entrepreneurial developers that make a successful product. This is the total opposite of what they should be doing.

    IMHO, I think the bulk of the marketing should be in going after business themselves, rarely do developers make the decision on adding telephony to the mix, they are given a project and they complete the project. The API’s are so incredibly easy and powerful to integrate the learning curve is minutes for a good developer – the killer idea and use case on how to deploy them will usually come from the entrepreneur that started the business in the first place. That person is rarely an engineer or has the ability to decipher an API document and they certainly don’t attend VoIP or WebRTC conferences, hackathons or mashups.

    So where the API has become a commodity and is dead simple, more often than not the API providers fail in relating what they can do for the average business person, they consistently look for customers in the wrong places.

    I’ve been a strategist in VoIP and Web for quite a while and I am consistently amazed at the simplistic creativity that entrepreneurs (once educated on how to add RTC to a business) come up with. The cost is so inconsequential to a web project, they always agree to start with something – once they have a basic understanding on that first project they will add it to all projects moving forward.

  6. One of the issues I see with Telephony APIs is that they bring with them most of the limitations of telephony as the “raw ingredient”.

    Most obviously, they bring assumptions about business models – “calls” measured in “minutes”, telecoms interconnect & termination regimes/costs, particular types of user interaction (eg interruptions) and so forth.

    In some markets this works better than others – for example, the US, where termination calls to mobile are the same as to fixed. But in most places, this introduces both cost and variability for the developer, and ultimately drives an impetus for VoIP or WebRTC.

    That said, there are enough use-cases where this *is* justifiable for some enthusiasm in the near term.

  7. One of the issues I see with Telephony APIs is that they bring with them most of the limitations of telephony as the “raw ingredient”.

    Most obviously, they bring assumptions about business models – “calls” measured in “minutes”, telecoms interconnect & termination regimes/costs, particular types of user interaction (eg interruptions) and so forth.

    In some markets this works better than others – for example, the US, where termination calls to mobile are the same as to fixed. But in most places, this introduces both cost and variability for the developer, and ultimately drives an impetus for VoIP or WebRTC.

    That said, there are enough use-cases where this *is* justifiable for some enthusiasm in the near term.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}