 Telecom APIs: Bringing Voice Services to the Cloud
Dirk Hermans, VP Research and Development at Voxbone, identifies major opportunities for application programming interfaces (APIs) in the telecom world
 |
| Dirk Hermans, VP Research and Development, Voxbone |
Dirk has over 17 years of IT and telecom experience. He joined Voxbone as head of development in 2012. Prior to joining, he held IT architect, project and program manager positions on consulting assignments in fixed and mobile telecommunications and finance sectors.
As a consultant, Dirk worked for AT&T, Belgacom, BT, Libertel and Telenet. He also performed research at IBM Almaden in San Jose, California. He holds a master’s degree in electronics engineering from the University of Leuven.
A fundamental aspect of voice over IP (VoIP) was to separate physical connectivity from telephony services. That change created a fantastic opportunity to treat a telephony service as any other Internet service and bring it to the cloud. Why bring it to the cloud? Doing so allows dot-com businesses to sell online, creating a strong competition market climate with service innovation. It also enables services that spur sales through convenience, such as click-to-call so customers can get an answer right away instead of searching the website for a phone number. Finally, the cloud enables capacity management to truly be dynamic, such as instantly and cost-effectively scaling up a contact center’s inbound call capacity to support product launches or the holiday shopping season.
In today's truly global market, more service providers are choosing to use multiple sales and distribution channels to target the entire market. They are allowing their customers and resellers to add value by aggregating additional services with the ones they're providing. APIs allow them to implement this model by exposing business support system (BSS) and operational support system (OSS) functionality through the API, with the ultimate goal of enabling communications. Sprint, for example, publishes more than 300 APIs.
This model is especially valuable in a wholesale market, where the ability to provision capacity and configure telecom services is consumed by application providers such as cloud PBX players and conferencing providers that build their own distinct services on top of service providers’ advanced telecommunications capabilities. More and more operators understand the technical and commercial value of APIs, but there are still many incumbents that do not expose an automated ordering mechanism to the outside world catered to the wholesale market.
 |
A good API platform drives a community and allows the community to drive the platform in return. The community will provide valuable input about the functionality and syntax for the next iteration of the platform. The key to success is to ask for this input and embrace it. For example, service providers should publicize new APIs and successful client deployments, and devise developer incentive models such as competitions or revenue sharing on orders generated via the API. Service providers also should provide clear code examples, generate client libraries in different languages and – most importantly – document everything.
How easily service providers can offer an API depends on the architecture of their IT systems. When properly architected, adding an API simply means adding another channel into the existing infrastructure, a skin around the apple. This skin should do as little as possible, such as security and DOS attack protection, and some protocol translations between API protocols and the internal systems.
WebRTC is a JavaScript API for initiating communications and is a fantastic example of how an API can bring communications to so many developers by simply lowering the knowledge prerequisites. Three lines of code are all it takes to add telecom features to a Web page, enabling services such as click-to-call functions for contact centers, conferencing platforms or video chats in the browser.
What does this evolution mean for the spectrum of telecom APIs? For one, it will bring added value to the retail players by offering yet another and much easier way of initiating communications. At first sight, this feature plays no role in the wholesale side of telecom APIs because it directly targets the end-user. It will, however, affect the services offered in the wholesale market because unified communications becomes both easier to achieve and richer in features.
In general, there is increased attention towards standardisation in the retail telecom API market, with developments such as the GSMA's oneAPI. It makes a lot of sense to support these standards in a retail market because the services offered are simple (e.g., sending an SMS) and can be consumed by many app developers and offered by many operators. In the wholesale market, the situation is different: Services are more complex (e.g., provisioning which codecs to use and how to handle DTMF), which makes it harder to define a common standard without paying a lot of attention to feature discovery or stopping at the 'lowest common denominator' and defining only the simplest of services. By nature, there are fewer consumers of these wholesale services and fewer providers, as well. Both of these factors explain why we have seen little successful developments in standardizing wholesale telecom APIs.
Recent big data developments hold great potential for telecom service providers. Online CDR analysis and aggregation offer huge internal potential for NOC teams, contact centers, fraud detection departments and other departments. But what's the value of online CDR statistics to a wholesale telecom customer, and how do operators deliver this information to these customers? Big data is just starting to evolve, with the initial deployments inside companies rather than shared with outsiders such as business partners. It's a paradigm shift in many ways and a true example of how technology changes can enable functionality previously impossible to expose, such as near real-time access to massive CDR-based information and statistics.
As businesses continue to explore the potential of big data, they’ll need to explore the role that APIs play in unlocking that potential. Will they offer the results of big data analysis to their customers via a Web portal, or will they offer the data processing as such through an API, thereby enabling the customers to perform their own analysis based on the data? The impact of big data in the cloud will be a fascinating field to be involved with. Finally, if we can drive the immediate feedback of big data back into capacity management via an API, we can implement truly elastic communications in the cloud.
For more information visit:
www.voxbone.com |
