VoIP or SIP application developers can be categorised by the clothes they wear, the bicycles they ride or the approach they take to programming. This post is about the latter. Which grouping do you belong to when it comes to writing VoIP, IP telephony or SIP-based applications?
Regardless of the purpose of your application, whether it be a straightforward, IVR/auto-attendant ‘front-end’ or a complex, unified communications application for a sophisticated contact centre environment, you can approach its development from a number of different angles. There are many competing methods for developing software. Here are five you can try:
1. The traditional method
Developers taking this approach are becoming increasingly rare and as a consequence, their skills can be much in demand. They could be described as the ‘shorts and sandals’ brigade. Thankfully, they are far from extinct and their expertise makes them consistently sought after. Their value stems from having gained a fundamental knowledge of the intricacies of telephony and protocols, and an ability to use low-level programming languages, such as C, to best advantage.
The products they use are likely to be those from the traditional ‘voice board’ manufacturers, who provide professionally documented application programming interfaces (APIs) in C or C++. They appreciate the level of control that can be exerted over the behaviour of an application via a low-level API. Vendors typically provide a portfolio of DSP boards or host media processing (HMP) software with proprietary APIs.
2. Application generators
The conventional user of the ‘App Gen’ has been the enterprise IT Services Manager. These are individuals with loosened ties and a permanently worried expression. Their broad skill sets make them invaluable to any organisation, however, they may occasionally suffer from the ‘jack-of-all-trades’ syndrome. What they often need is the ability to cobble together rapidly an IVR application for that new call centre.
Typically, the kinds of tools they can deploy are entrenched in the development environment of
Microsoft .NET technologies. These are extremely useful and easy to adopt as they do not need an extensive learning curve. That is because the telephony functions – mainly restricted to basic IVR capabilities – are represented by a library of components. The ‘developer’ simply drags ‘n’ drops icons (or modules) into a GUI workspace to create the desired application. Integration with a third party DSP voice board or, increasingly, HMP software is needed.
3. VXML/CCXML approach
This is the realm of sophisticated users of service delivery platforms, which can be hosted on behalf of an enterprise or installed in its contact centre. VoiceXML and CCXML scripts are served up from a Web server and the great benefit is that new call flows and IVR interactions can be produced by any sharply dressed end user. That can be done very cost-effectively and in real time, without needing to engage an expensive, third party developer.
Of course, VoiceXML brings with it the great promise of open standards. However, whilst scripts written to conform to the specification should run on any VoiceXML interpreter or ‘browser’, a telephony engine or media server is needed. That underlying hardware or software must have been integrated with the vendor’s interpreter. Usefully, integrations are available across the spectrum of open source and commercial board and HMP software providers.
4. Telephony by Web page
There is a new breed of telephony application developer who is a kind of cross-over between geek and entrepreneur. These folks are looking to shake up the landscape and demand that making a voice call be as simple as HTML. This kind of independent developer treats the application as a Web page and looks to leverage their existing skill set in languages such as PHP and Java.
In the majority of cases, they depend upon a hosted or cloud-based telephony platform that is accessible to the user’s Web application, which is registered through its URL with the service provider. A great attraction of this type of service is that it is often free to try online via a ‘sandbox’, when all the developer needs is to register for an account. Fees are charged for real, deployed applications and increase when other functions, such as SMS and speech recognition, are added. The entrepreneurial developer pays the provider a monthly $ fee and/or a ¢ per minute rate, and rakes in the marked-up fees when the application (hopefully) becomes popular with the masses.
5. New era developer tools
This approach is for those developers, whether sandaled or suited, who are crafting real-world applications and need to add telephony functionality to their platforms. They could be from the Microsoft .NET / Visual Studio / C# or the open source, Linux and Python community. A common theme is that they will be using such familiar, general purpose programming languages for coding. They will be seeking development tool kits with APIs written in those very same, high-level languages so they can ‘dive straight in’ and immediately begin writing the application in their preferred language.
The availability of abstracted, high-level APIs means that an ‘old hand’ or someone new to telephony, can get on with the job of crafting an application and focus on the end result rather than issues such as SIP negotiation and RTP usage. Significantly, time to market for the development of a given solution can be considerably reduced, because applications are probably two orders of magnitude quicker to write than the traditional alternative. Vendors will typically offer their own (ideally) or a third party’s HMP software to provide the underlying telephony or media server functionality.
So, which group are you in?
Each of these five methods or approaches has its own merits, which you will recognise. One way or another, each has its price. You pay through a per channel licence fee or on a fixed fee and/or usage basis. The cost-effectiveness of what you get and the time to market result is a matter for you. Choose well, my friends!
People of a certain age, including myself, grew up watching sci-fi shows such as Star Trek and even earlier, Flash Gordon (remember that?) – and the idea that a portable ‘communicator’ could be carried or worn to enable communications back to base was certainly a space-age idea. The communication would be not just voice, but often video also from the distant crew member. Here we are a few decades later, and this type of communication is now possible – amazing! However, whilst we have all seized the opportunity to have a personal voice communicator with us at all times, how many have tried out the facilities now becoming more widespread of video communication?
