Understanding Avaya Aura and IMS

If you’ve heard Avaya tout the benefits of an Aura architecture you’ve undoubtedly heard that what differentiates Aura from the competitors is its support of IMS principles.  I certainly know that I’ve personally stressed that as a very important factor in why Aura stands head and shoulders above the traditional IP PBX.  However, I realize that most people do not understand IMS, or IP Multimedia Subsystem, and why it’s such a major leap forward from the PBX architecture of the past.   Over the next couple of minutes I hope to make IMS and its benefits a little more real for you.

IMS as a concept was first proposed back in 1999 as a way to create a standard framework for communications systems and was quickly adopted by mobile phone carriers as a platform for distributed applications and call processing functionality.  Although it began as an architecture for GSM and GPRS networks, support for SIP-based multimedia was added early on.  In fact, IMS evolved to use standard Internet protocols whenever possible — thus, the “IP” in “IP Multimedia Subsystem.”

Although the architecture of a carrier IMS system is quite complicated, there are only a few core concepts that need to be understood.  First, IMS has clear definitions and specifications for the different functions that make up an IMS communications system.  For instance, IMS defines several roles for the different SIP Call Session Control Function (CSCF) components such as the Service CSCF (S-CSCF), the Interrogating CSCF (I-CSCF), and the Proxy-CSCF (P-CSCF).  It is not important for you to understand the specifics of these components, but it is important that you realize that each has a clearly documented interface that allows different vendors to supply components into an IMS configuration.  In other words, IMS is an open architecture that fosters a mix-and-match approach to building a system.

Second, like SIP itself, IMS separates signaling from media.  That does not mean that IMS is unconcerned with media.  It simply means that the components that process SIP signaling messages are not in the media path.  For example, IMS defines the Media Resource Function Processor (MRFP) for mixing and processing media streams, but it is under the control of the signaling component and not a signaling component itself.  This separation of signaling and media allows IMS to scale to millions of users.

When Avaya began designing Aura they looked hard at IMS and realized that although it was an extremely flexible specification for building a distributed, SIP-based communications platform, it was far more involved than what was needed by an enterprise.  So, instead of taking IMS lock-stock-and-barrel, Avaya took the main concepts of IMS (distributed SIP services, well-defined interfaces, scalability, and media/signaling separation) and created “Enterprise IMS.”

At the core of “Enterprise IMS” is the Avaya Aura Session Manager (SM).  Fundamentally, SM is two things.  First, it is a SIP routing engine.  It can take SIP messages from anywhere and route them to their appropriate destination(s).

Next, you can think of SM as the conductor of a SIP symphony.   What this means is that SM enforces policies, dialing rules, and routes for all PBXs, endpoints, applications, and SIP entities that connect to SM.  It’s in this role as SIP maestro that SM truly follows the IMS model.  To ensure that SM can communicate effectively and accurately with all those elements it does two things.  It requires that every element speaks the same language.  That language, of course, is SIP.

Next, it defines a clear interface that every entity must follow if it wants to be part of the orchestra.  That interface is known as IMS Service Control or SIP ISC.   SIP ISC allows an application to receive, process, and return SIP messages to SM as part of a call flow.  In Aura parlance, these entities are Sequenced Applications and they are one of the main reasons why Aura is more open and flexible than any other vendor’s communications system.

As mentioned above, a significant strength of IMS is that it can be used to build a system comprised of components from different vendors.  This is exactly the case with Aura.  Do you want voice messaging from Modular Messaging?  Go for it.  Would you rather use the new Avaya Aura Messaging?  You can use that, too.  Are you a fan of Microsoft’s Unified Messaging?  With Aura and its ability to interface with any SIP application, interfacing to Microsoft is as easy as S-I-P.

However, the real strength is in those sequenced applications.  Do you want every call flow to reach into the called party’s Microsoft Outlook calendar to check his or her availability before ringing the phone?  Do you want to create a unique caller-ID based upon a lookup into your customer accounts database?  Do you want to route calls based upon criteria that can only be found in your backend Human Resources application?  Sequenced Applications, and more importantly Aura’s support for IMS makes all of that, and more, possible.

As the world moves more and more into an open, dynamic, off-the-shelf, virtual world for all things software, it is important that your communications systems does the same.  You need something that is open, vendor agnostic, and flexible.  Aura and its support for IMS principals is all that and more.

Advertisement

Tags: Avaya, SIP, Unified Communications, VoIP