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.
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.
I don’t forsee death for anyone involved in the short-mid term – just a lot of innovation and creativity.
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.
I don’t forsee death for anyone involved in the short-mid term – just a lot of innovation and creativity.
Agree, but we may consider that “telephony API carriers” are also trying to sell the infrastructure to telcos. I guess next trend will be delivering more compelling and innovative services by combining different Telco APIs. We just published a demo of this concept combining voice and RCS joyn APIs to create a combined service.
http://blog.solaiemes.com/2012/12/combining-voice-joyn-apis-to-create-new.html
That trend is already happening – simply by providing these APIs, companies are meshing them up any way they like – with our without RCS.
Too shyly 🙂
Telcos need to engage “enterprise business units” in pioneering the API plasitiline to create the new services their customer are asking for.
Agree, but we may consider that “telephony API carriers” are also trying to sell the infrastructure to telcos. I guess next trend will be delivering more compelling and innovative services by combining different Telco APIs. We just published a demo of this concept combining voice and RCS joyn APIs to create a combined service.
http://blog.solaiemes.com/2012/12/combining-voice-joyn-apis-to-create-new.html
That trend is already happening – simply by providing these APIs, companies are meshing them up any way they like – with our without RCS.
Your post is spot on! By popular demand, we just exposed @Twelephone’s API last week and released a WebRTC CallMe button/widget for people to add to their sites. Check out http://twelephone.com/#/api for more details.
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.
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.
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.
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.
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.
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.