It is in multi-vendor environment that the capabilities of Session Manager are required to disable boundaries between disparate systems.

When Avaya first introduced its Aura Session Manager at last year's industry analyst conference it mentioned the term "Applications Sequencing," but did not go into any meaningful depth. The term popped up again earlier this year when Session Manager was officially launched at VoiceCon Orlando. Though Avaya did a fair job discussing the centralized SIP network routing functionality of the new product offering, they failed to adequately expound on Applications Sequencing.The first Avaya Aura Session Manager brochure, dated 6/09, did not even include the term among the many product feature/function capabilities. Applications Sequencing is a term of Avaya s own invention, so don't bother Googling it, because it would be a futile exercise. Finally, after several months of prodding by industry analysts such as me, Avaya finally held a conference call to explain their Applications Sequencing concept.

I won't bother you with the technical mumbo jumbo behind Applications Sequencing, because many of you would care little about it, but I will try to briefly describe what Aura Session Manager brings to the table as regards features and functions. Let me preface my remarks by stating that I am still confused how Avaya enables Applications Sequencing in a multi-vendor environment (more about that later), but I believe I understand what Avaya intends to bring to the table via Aura Session Manager Applications Sequencing capabilities.

If one looks closely at a simplified Avaya Aura architecture diagram (see below) you notice that Session Manager is the foundation on which three other subsystem elements rest: Communications Manager, Applications Enablement, and Presence. Communications Manager is the name Avaya has given to the generic software package for its flagship family of S8X00 IP telephony system models. Applications Enablement Services, according to Avaya, is a software platform that leverages the capabilities of Avaya Communication Manager, providing an enhanced set of Application Programming Interfaces (APIs), protocols, and web services that expose the functionality of Avaya Communication solutions to corporate application developers, third-party independent software vendors, and system integrators. Presence Services, for an outsider the most easily understood of the three elements, is the collection and distribution of rich presence information between Avaya and third party sources that leverages a set of collectors which link the core presence capabilities with these other presence sources. Session Manager and Presence each require a dedicated server.

Evolving Avaya Core Architecture

Following the recent Avaya System Platform Technology announcement, Communications Manager and Applications Enablement run on a common virtualized server.

Avaya plans to have a Session Manager Server function as the brain and nervous system of its enterprise communications system, replacing the current role of a S8X00 server running Communications Manager. The Communications Manager server becomes, in its new role, a feature server to be shared across Avaya and third party IP telephony systems. It will provide telephony features and media control to communications devices; Session Manager will provide device support and routing control. All server-to-server signaling will be SIP-based. Session Manager, with a centralized directory profile database, will directly support SIP communications devices; non-SIP device support will require an intermediary SIP proxy server. Additional applications server solutions, such as Avaya Modular Messaging, Voice Portal, and Meeting Exchange, will also work behind Session Manager and support user needs in a multi-vendor IP telephony system environment, as will third party applications (see diagram below).

In effect, Communications Manager running in feature server mode will support Avaya and non-Avaya system subscribers much like a CTI applications server was designed to do years ago. Avaya's approach could ease migration from a third party system to one of its own platform. Third party hardware (telephones, gateways, port interface common equipment) can remain in place while telephony services are provided by a combination of Session Manager and Communications Manager; new Avaya telephones can be added to the mix or replace currently installed third party instruments. How Avaya or a customer actually enables this process was not discussed during the call; the only examples discussed were an all-Avaya environment. In fact, Avaya never completely explained how its Session Manager routing function avoids conflict with a third party system s routing operations. I was able to find an online Avaya testing lab document detailing the operation of a mixed Avaya/Cisco SIP network solution, but the explicit system programming instructions were difficult to follow.

In summary, Applications Sequencing is the provisioning of communications features and functions from a variety of applications servers working behind Avaya Aura Session Manager Server to a user community distributed across a network of multi-vendor IP telephony systems. There does not appear to be much need for Session Manager in an all-Avaya network, because all systems would be compatible for networking purposes, features would be common across systems, and centralized applications could be shared. It is in multi-vendor environment that the capabilities of Session Manager are required to disable boundaries between disparate systems.

I have current plans to meet with Avaya, once again, to delve further into the inner workings of Session Manager, especially how routing and feature conflicts are avoided in multi-vendor networks. The implementation of Session Manager is far greater in scope and complexity than simple feature/application layering in which an add-on system works with, not replaces, another system. I promise to report back on my visit to better illuminate the workings of Session Manager.It is in multi-vendor environment that the capabilities of Session Manager are required to disable boundaries between disparate systems.