Using Avaya Call Intercept Services to Build 'Call Forwarding on Steroids'

A few weeks ago I wrote about Avaya’s new Collaboration Environment (CE). Since then I have had time to download the SDK (Software Development Kit) and spend some time reading through the documentation. So far, I like what I see. The Java classes are straightforward and comprehensive in their scope. I have yet to write my first application, but I have looked through some sample code snippets and haven’t run into anything that doesn’t make sense.

There are lots of things that excite me about CE, but on the top of the list are the Call Intercept Services. These are very similar to Avaya’s Sequenced Applications, but Call Intercept Services extend the concept of in-call applications to better support non-SIP endpoints and trunks.

So, what are Call Intercept Services? Essentially, they are applications, or more precisely applets, that sit in the middle of a call flow. They are extensions to Avaya Communication Manager to provide functionality not provided through Avaya telephony features. For example, can Communication Manager consult a user’s Outlook Calendar to make routing decisions? No. Can Communication Manager make web services calls to a web-based do-not-call database? Another no.

Call Intercept Services allow a programmer to write the code that performs those services and place it anywhere within an inbound or outbound call flow. Back to our previous example, it is possible to write a Call Intercept Service that makes that Outlook query before ringing a user’s telephone.

If the calendar says that he or she is out of the office on vacation an inbound call can be then routed directly to voice mail or to another appropriate destination. Or instead of dipping into a user’s Outlook calendar, how about using his or her Lync presence status for call routing decisions. In this way setting do-not-disturb in Microsoft Lync would prevent your Avaya telephone from ringing. We are all familiar with call forward. This is call forward on steroids.

Call Intercept Services aren’t limited to routing calls. They aren’t also limited to the called party. A Call Intercept Service could be written to perform some sort of user authentication on the caller – say a few words, send those words to a speech analysis service, verify that the speech patterns stored for Andrew Prokop match the words just spoken.

A Call Intercept Service could also record calls based on a variety of criteria established outside of Communication Manager. A Call Intercept Service could be used to perform specialized billing for either the caller or called parties. Once you are able sneak bits of code into the middle of a call flow, the sky is the limit as to what sorts of features you can create.

So, how does this work? First, Call Intercept Services are developed using Collaboration Environment and each service runs on a CE server. The service can make calls to components outside of CE. For instance, the Outlook calendar will certainly run outside of CE, but can be invoked by a Call Intercept Service running on CE.

Second, Call Intercept Services are invoked by Session Manager as part of its processing of implicit users. Implicit users are essentially phone numbers and you can create a Session Manager rule that invokes a Call Intercept Service for phone numbers in a particular range. For example, you can tell Session Manager to invoke the Outlook calendar Call Intercept Service for called numbers between 952-456-3000 and 952-456-3399.

You aren’t limited to a single Call Intercept Service within a call flow. If desired, you can have a user authentication service and a call blocker service running for the calling party. At the same time, you can have Outlook calendar, Microsoft Lync, and accounting services running for the called party.

There are a few important things to know about Call Intercept Services. First, they only work on calls to and from the PSTN. One leg of the call has to be a trunk. It doesn’t matter if it’s a SIP trunk or an ISDN trunk. However, it cannot be one station on the PBX calling another station on the PBX. It has to be a call to or from the outside world.

Second, unlike Sequenced Applications, Call Intercept Services do not run on behalf of explicit users. In Session Manager speak, an explicit user is a SIP station configured in System Manager. That doesn’t mean that you can’t use SIP stations. It simply means that you need to identify those users as telephone numbers within a range of numbers.

Third, Call Intercept Services can run alongside Sequenced Applications. You may have a need to develop a Sequenced Application that is invoked when SIP telephones call each other within the same PBX. You might also want to develop an application that is invoked when a call to a SIP phone arrives on an ISDN trunk. In this second case you will want a Call Intercept Service. The key message is that Sequenced Applications and Call Intercept Services aren’t dependent or exclusive of one another.

There are a few other minor details, but the above is more than enough to make you dangerous when it comes to Collaboration Environment and Call Intercept Services. Think about your business. Think about the external applications and backend services that you already employ. Now, think about how those applications or business processes make sense in terms of communications. I expect that you will be able to find a use for Call Intercept Applications and come up with easy ways to justify implementing one or more on your PBX.

* * *

This article originally appeared on Andrew Prokop’s unified communications blog, and is reprinted with permission.