With the appropriate equipment, Avaya Aura CM sites can “survive” an outage. An outage, in this context, means that the site lost IP (or TDM shudder) connectivity to both its primary controller and its enterprise survivable server (if there is one). The necessary equipment includes (generally) a media gateway with a local survivable processor, and some form of trunking (if you want calls to be able to leave the gateway).

In most cases, the default behavior – continuing to operate with the same programming as usual – is correct. That is to say, if your branch office lost connectivity to its primary and secondary datacenters, you’d more than likely still want to have calls delivered to and from stations and trunks associated with that site. But consider, for a moment, a site that provides significant trunking access to other sites – a case that is not uncommon when an organization spans multiple area codes (or, more accurately, local calling areas). One of our sites exists in a local calling area where we have a very significant quantity of customers, despite our offices being located in a different area. That site accepts incoming calls from the PSTN, and the calls are connected to their final destination via means other than the PSTN (such as IP or private circuits). The default survivability behavior isn’t necessarily the best solution for that case.

The solution that I most recently used involved sending some callers on to their ultimate destination by way of the PSTN (potentially incurring long-distance toll expense), and playing a message to other callers informing them that their call was unable to be completed due to a technical failure, and that they could either re-try their call to an alternate telephone number, or try their call again later.

There are a lot of programming changes required to implement that, but none of them are terribly complex:

  • Determine which callers (by incoming digit string) should receive an announcement. For each of those, create an announcement, and create the corresponding rules in inc-call-handling-trmt for that trunk-group.
  • Determine which callers (by incoming digit string) should be carried on to their destination party via the PSTN (keeping in mind that this will keep two of your trunks busy for the duration of their call). Create a vector, if you don’t have one already, that silently forwards callers to another number based on VDN variable. Then, for each of the digit strings to be forwarded on, create a VDN with the appropriate variables, and then create the corresponding rules in inc-call-handling-trmt for that trunk-group.
  • Remove the remaining rules in inc-call-handling-trmt for that trunk-group.

What I’ve done is undoubtedly not the best solution for all needs… or even many needs. It’s fairly purpose-driven. But perhaps someone else will find it useful. :)

Related posts that may be of use: