A Developer’s Intro to Avaya Engagement Call Control (ECC)

I need to start by telling you that I am a Java programmer. Having experienced quite a few computer languages over the years, I started writing in Java fairly exclusively in the late 1990s. I love the elegance, power and flexibility of Java. It ran circles around other object oriented languages such as C++ and made my life as a software designer much easier.

However, I recognize that Java isn’t for everyone or for every circumstance. While it’s not necessarily a difficult language to learn, it requires a particular way of thinking. You can’t write Java code the way you may have written software in other languages – object-oriented or not – and I understand why some people get frustrated with Java and turn to other languages for their development projects.

Even more importantly, I realize that in certain areas, pure Java can feel like a square peg in a round hole. To avoid developer/application mismatch, it’s important to keep an open mind and be willing to adapt to the situation at hand.

The new Avaya Engagement Call Control (ECC) Snap-in is the perfect example of something different being the right choice. Built on top of the Avaya Engagement Development Platform (EDP), ECC exposes a wide array of RESTful Web services that allows developers to quickly and easily add a myriad of call control features into their applications.

While much of the ECC functionality is supported natively by EDP, EDP interfaces require Java and, by their very nature, are a bit more difficult to use than Web services.

On the other hand, ECC features can be used by any language or scripting tool that supports Web services. This includes Python, Ruby, Node.js, .NET, PHP and, yes, even Java. So, while hardcore programmers might prefer a more traditional language, powerful ECC applications can be quickly built with easy-to-use and highly portable Ruby. In fact, there may be times when an application is prototyped with Python and productized with .NET. Developers have choices and are not locked into a single platform or a specific way of programming.

Read additional articles from Andrew Prokop at SIP Adventures.

A powerful difference between ECC Web services and EDP Java interfaces is the ability for ECC to monitor and control calls of all types. While EDP applications are limited to calls to and from trunks, ECC can act upon trunk calls as well as station-to-station calls. That alone makes ECC worth the price of admission.

This difference comes from the fact that the ECC Snap-in uses the Avaya Application Enablement Server (AES) to provide telephony features, while EDP Java applications run as sequenced applications on Session Manager. By using AES, ECC Web services extend AES’s close relationship with Communication Manager (CM). In other words, any call that CM can see, ECC can also see.

The following list is a more comprehensive look at the differences between the ECC and Java APIs:


A Look at the ECC Interfaces

ECC Web services support the following call control interfaces:

  • Make Call
  • Get Call
  • Drop Call
  • Drop Connection
  • Answer Call
  • Hold Call
  • Retrieve Call
  • Get Call Forward
  • Set Call Forward
  • Cancel Call Forward
  • Get Connections By Address
  • Get Call Connections
  • Get Connections Details
  • Redirect Call
  • Single Step Transfer
  • Consult Initiate
  • Complete Transfer
  • Complete Conference

As a software developer, I can immediately envision a myriad of applications made possible by these 18 function calls. For instance, it would be painless to add click-to-call capability to a corporate Web page or an employee services portal. The same holds true for CRM or workflow management packages. Although Avaya Communicator makes it unnecessary, it wouldn’t be that difficult to write your own soft client. The possibilities are endless.

In addition to operations that create and manage voice calls, ECC supports a number of Web services that act upon Avaya Aura Messaging. These are:

  • Get Messagebox by ID
  • Get Message by ID
  • Get All Messages
  • Get Message Flags
  • Set Message Flags:
  • Get Message Parts
  • Get Message Part by ID
  • Get Message Part Content
  • Purge All Messages in Trash

Again, there are quite a few applications that could be built from these interfaces with Visual Voice Mail being the most obvious. It would be very simple to create a Web page that displayed and played a user’s voice mails. I don’t know about you, but I am all for anything that keeps me from entering DTMF commands from my telephone. I have been a Modular Messaging user for years and still refer to the cheat sheet of commands pinned on my bulletin board.

Digging Deeper

As a developer, I want more than function names. Thankfully, Avaya has done a great job of documenting every Web service and its associated data structures. Before I did anything with ECC, I downloaded the documentation and poked around the function calls.

For instance, the Make Call operation consists of an invocation and subsequent response. The Make Call invocation looks like this:


“id” :”#MakeCall”,
“type” : “object”,
“properties” : {
“from” : { “type” : “string”},
“to” : { “type” : “string”}
},”additionalProperties”: false

And a successful response (200 OK) looks like this:


“id” : “#Call”,
“type” : “object”,
“properties” : {
“callID” : { “type” : “string”},
“statusUrl” : { “type” : “string”}
},”additionalProperties”: false

In English, Make Call requires To and From destinations. For example, the To could be my telephone number (“+19524563516”) and the From might be my coworker, Debbie (“+19524563888”). Note that To and From are expressed as E.164 numbers.

A successful response contains a  callID that uniquely identifies the call. This  callID will be used in subsequent commands to manage the newly created call.

The remaining function calls follow a similar model of command and response.

ECC Events

Of course, it’s not enough to simply tell ECC to do something. You need to know when something has occurred. For that, ECC delivers the following events:

  • HELD

Applications will register an event handler that will subsequently be invoked for all new events. For example, an ECC application is made aware of a ringing call with an ALERTING event:

event {

callEvent: ALERTING


originalCallingParticipant: A

originalCalledParticipant: B

alertingParticipants: B

participants:A, B

callID: <call_id>

callHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID

address: A


An application could act upon that event by issuing an Answer Call command.

After the call has been answered, an ACTIVE event would be delivered to the application’s event handler.

event {

callEvent: ACTIVE

originalCallingParticipant: A

originalCalledParticipant: B

participants:A, B


callID: <call_id>

callHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID

connectionId: <connection_id>

connectionHref: https://<CLUSTER-IP>/services/EngagementCallControl/connections/connectionId

address: A

operations: [

endCallHref: https://<CLUSTER-IP>/services/EngagementCallControl/calls/callID holdCallHref:


consultCallHref: https://<CLUSTER-IP>/services/EngagementCallControl/connections/connectionId?action=consult]


Make note of connectionId. Like callID, this reference is used in commands that act upon calls and their various connections. For example, an application can use connectionId to drop a single participant from a conference call while not releasing the call itself.

Mischief Managed

My goal for this blog article was to provide an introduction to ECC, and I hope I accomplished that. In future articles, I may dig in a bit deeper to the commands, events and call models that ECC supports.

In the meantime, I highly recommend that you go to the Avaya DevConnect page, download the SDK and supporting documentation, take a look at the sample applications, and have a go at it. I think you’ll find it as easy to understand as I did!

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.

Views All Time
Views All Time
Views Today
Views Today