Not only do I write for No Jitter, but I am also an avid reader of all its articles. While I enjoy nearly every topic my fellow writers explore, I am especially intrigued by those that address programming and APIs (Application Programming Interfaces). That's not surprising, though, since most of my professional life was spent writing software for the company formerly known as Nortel. I began with Intel 8085 Assembler Language and spent the last several years writing object oriented Java applications.
So, it's natural that I was thrilled to see Beth Schultz's recent article on Cisco's approach to APIs (Adopting an API Attitude at Cisco) and their shift from product team centric to developer centric. I have struggled with poorly designed APIs, and was happy to learn that Cisco has put a new focus on how their APIs are designed, documented, delivered, and ultimately supported. I know firsthand how that kind of attention to detail can simplify even the most complex software development projects.
Avaya understands this, too, and its Engagement Development Platform (EDP) is opening up access to Avaya servers and services in ways that were not possible a few short years ago. Sitting in the middle of just about everything, EDP applications have insight into communications workflows that isn't possible with traditional APIs such as TSAPI and JTAPI.
For the first year or so, developers were limited to writing their EDP applications in Java and creating what Avaya calls Snap-ins (think Java Servlet). As an old Java programmer myself, I was perfectly happy with that approach. However, as powerful and as flexible as I might find Java, for others it can be a square peg in a round hole, and if they can't use their preferred language, they have no interest in EDP. Consequently, this limits the pool of great developers and applications.
The new Avaya Engagement Call Control (ECC) Snap-in changes all that. Instead of requiring programmers to use Java for application development, ECC exposes a vast array of call control and voice mail functions through a series of RESTful Web services. This makes ECC language agnostic and allows developers a choice of programming languages and scripting tools including Python, Ruby, Node.js, .Net, PHP, and yes, even Java.
To begin with, ECC provides an extensive list of functions that can be invoked on calls of all types -- digital, H.323, SIP, analog, station-to-station, and trunk:
As a longtime software developer, I can immediately envision a dozen applications that I could write with those function calls including click-to-call from a corporate webpage or CRM (Customer Relationship Management) application. Given that so many of today's applications and workflow management solutions support Web services extensions, integration with Avaya call control becomes downright trivial.
In addition to call control, Avaya exposes an extensive number of additional Web services calls that can control voice mail operations on Avaya Aura Messaging:
By using these function calls along with the previously mentioned call control APIs, it becomes an easy task to combine visual voice mail with click-to-call to create a powerful soft phone that can run as a standalone application or be embedded into an employee Web portal. The beauty of Web services is that they don't restrict the developer, the platform, or the solution. Add scalability, portability, and security to the mix and you've got yourself a winning API strategy.
This is about the time when I would really like to get down and dirty and take you into the weeds of JSON formatted messages and responses, but I will spare you. However, I will tell you that ECC provides two essential modes of operation. First, it gives developers the ability to tell an Avaya system to do something. That something might be as simple as making a station-to-station voice call or as complicated as dropping a specific participant from a conference call.
Second, developers need to know when something has happened. This might be an alerting call, an answered call, a dropped call, or an acknowledgement that someone left a conference call. These events consist of the following:
Of course, on a busy telephone system, there will be thousands of these events happening all day long. To keep applications from becoming swamped with too much information, ECC applications register against the stations they wish to monitor. They see all the events that matter to them and are spared from having to process anything that isn't of interest.
The process for obtaining the documentation (which is quite good) and SDK (Software Development Kit) for ECC is easy. Simply go to the Avaya DevConnect page and everything you need for ECC is there for the downloading. Developers familiar with Web services and client/server programming should have no trouble understanding the function calls and their associated events.
Beside providing an extensive set of open interfaces, ECC wants to make writing communications software easy for non-communications programmers. Since I have been so immersed in this technology for 30+ years, I am not the best judge of how well they succeeded with this initiative. However, from what I can tell, anyone who has ever picked up a telephone shouldn't have any difficulty writing fairly sophisticated applications. Knowing more will certainly help, but it's not a requirement.
In closing, I hope you see that like Cisco, Avaya has adopted its own API Attitude. It began with Engagement Development Platform and a powerful set of Java APIs, and has matured nicely with a strong set of Web services APIs that make programing as simple as navigating to a webpage.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
