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.

Related Articles:

What Activates a Survivable Avaya Communication Manager Server?

I’ve been teaching Avaya Aura Communication Manager (CM) for about 8 years now. When the topic of CM’s survivability strategy comes up, I like to ask students, “What causes a CM-Survivable Core or a CM-Survivable Remote server to become active?” Typically, students respond with, “the CM-Survivable Server takes control when it loses communication with CM-Main.”

I’m always surprised by how many experienced engineers give that wrong answer.

We all agree that CM-Survivable Core (CM-SC) and CM-Survivable Remote (CM-SR) are doing essentially nothing during a “sunny day,” when CM-Main is in full control of the environment. More specifically, no call processing is occurring within them.

To know what is healthy, Avaya depends upon “heartbeats” between various devices. Those “heartbeats” are called many things, such as keep-alives, or sanity checkslots. For the purpose of this discussion, heartbeats are exchanged between CM-Main and survivable CMs, H.248 Media Gateways (MG), IPSI (Internet Protocol Server Interface) circuit packs within Port Networks, H.323 phones, and starting in CM version 7.0, Avaya Aura Media Servers (AAMS). Further, for some devices, CM is responsible for generating the heartbeats, and for other devices, the device itself generates the heartbeats.

First, all of these devices must have registered with CM-Main. This “gatekeeper” function requires that the device present some credentials to ensure its legitimacy, and then CM needs to be told, or to learn, the IP address of that device.

In older CM versions, those devices (except for IPSIs) could register with any of up to 106 CLAN (control local area network) circuit packs. Acting as a front-end processor, the CLAN would collect the registration requests and forward them to CM. Recently, Avaya deprecated the use of CLANs, and wants all devices to register directly to CM at the Processor Ethernet (also known as PROCR) IP address.

So now imagine that CM-Main can no longer communicate with some, or all of these other devices. Perhaps a power outage took CM-Main completely offline, or maybe some network issue separated CM-Main from one or more of these devices. In this “rainy day” scenario, the heartbeats are not being exchanged.

In a well-designed system, each of these devices has a list of alternate CM “gatekeeper” addresses that it could register to. Further, there are several administrable fields that determine how frequently heartbeats are sent, how many heartbeats need to go missing before the device recognizes it has lost communication with CM-Main, and how long the device should wait before registering to another CM.

Most of those settings should be provided to all CM-survivable servers every night when CM-Main automatically performs a ‘save translations.’

With all that as background, here is the answer to my question: It is the Media Gateway, IPSI or AAMS that decides to register to a CM-Survivable. The survivable CMs are passive. Upon registration by one of these three devices, CM-Survivable becomes active. In other words, the survivable CM did not “take control.”

So from this perspective, what is the difference between CM-Survivable Core (SC), (formerly known as an Enterprise Survivable Server) and CM-Survivable Remote (SR) (formerly known as Local Survivable Processor)? A CM-SC is activated by the registration by a MG, an IPSI, or an AAMS. However, a CM-SR can only be activated by the registration of a MG. IPSIs and AAMS’ cannot register to a CM-SR.

“But no wait, John” some students have said. “Registration by an H.323 phone can also cause a CM survivable to become active.” Unfortunately, no. CM will not let an H.323 phone register if CM cannot provide it with a VoIP resource. And those VoIP resources reside within the MGs, Port Networks, and AAMS’. So, only after one of those devices registers to a CM could that CM allow an H.323 phone to register.

To focus on the point that registration by an IPSI, MG or AAMS is what activates a CM-survivable server, I kept this article vague. In future articles, I’ll provide details about how the IPSI, MG and AAMS know when and where to register. I’ll also discuss handling split registration.