A Close Look at Avaya Aura IMS Call Processing

It goes without saying that SIP is a protocol. After all, it stands for Session Initiation Protocol. It’s a series of request methods, responses, headers, and documented call flows. You send an INVITE and expect to receive a 100 Trying, 180 Ringing and eventually a 200 OK. That’s the way I was taught SIP, and that’s what most people assume they will see when they trace SIP calls.

However, SIP as a solution can be quite different. Yes, you will see an INVITE to make a call (most of the time), but you may also see one, two, three or even more subsequent INVITE requests for that one call.

Case in point is Avaya Aura and how SIP messages are processed by Session Manager and Communication Manager. It’s not that Avaya is doing anything wrong. There is no huge diversion from SIP as a protocol. It’s just that SIP as a solution requires network elements to take an active role in how call processing occurs.  The value that Avaya adds to SIP calls leads to something more complicated than INVITE – 100 Trying – 180 Ringing – 200 OK – ACK.

IMS Processing

Avaya built its SIP solution around something called IP Multimedia System (IMS). IMS began in the carrier world and is defined by a number of service roles and well-defined interfaces. Now, it would be incorrect to claim that Aura is an IMS implementation. It’s not. Instead, Avaya took several important concepts of IMS and created what I call “Enterprise IMS.”

Today, I want to write about the interface that exists between Session Manager and Communication Manager since this is the most visible place you will see IMS in action. Once you understand this interaction, you will have an easier time tracing calls using Avaya’s traceSM tool.

You will find this article useful for understanding the following call flows: A Necessary Guide to the Avaya traceSM Utility.

When you configure a SIP user in System Manager, you need to do a few things that you don’t do for non-SIP endpoints.

First, you’ll need to assign the user to up to three session managers – prime, backup and survivable remote (think LSP). A Session Manager plays a number of different roles in an Aura system, but one of the most important is its role as SIP Registrar. An Avaya telephone can simultaneously register to all three providing a level of survivability not available in traditional IP (H.323) telephony.

You’ll also need to configure two application sequences – origination and termination. Sequences are a list of applications or services you want the phone to invoke during the origination and termination phases of call processing. For those of you with a carrier background, this is known as half-call processing and is at the core of delivering a powerful and flexible platform for feature development and invocation.

As Session Manager processes a call, it will send that call through the origination and termination sequences. It does this by sending the SIP messages for that call to the elements defined within the sequences.

Bare-bones origination and termination sequences will always contain references to a Communication Manager (CM). This informs Session Manager (SM) to send a SIP call to CM during each half of the half-call processing.

If both the caller and called party are SIP endpoints, the call flow looks like this:

  1. INVITE to SM (from the calling SIP endpoint)
  2. SM sends INVITE to CM
  3. CM sends INVITE back to SM
  4. SM sends INVITE to CM
  5. CM sends INVITE back to SM
  6. SM sends INVITE to next hop (to the called SIP endpoint)

Steps 2 and 3 are the origination phase (run on behalf of the calling party) and steps 4 and 5 are the termination phase (run on behalf of the called party).

How do CM and SM know what is happening when receiving what is essentially the same INVITE over and over again? By modifying the SIP headers, of course. Specifically, within a ROUTE header, SM and CM will insert a parameter that indicates which phase of IMS processing is in effect.

The four phases are:


The original call to a SIP telephone and the ultimate INVITE to the called party will not contain any phase indication.  Phases only occur between Session Manager and Communication Manager.

Show Me

In order to make this a bit clearer, I started up traceSM on Session Manager and made two calls. The first call was from my SIP telephone to an outside number and the second was from an outside number to my SIP phone. The first call allowed me to capture SIP messages for the origination phase and the second showed me the SIP messages of the termination phase.  If I had two SIP telephones to work with, I could have captured both phases in a single call flow. Unfortunately, I did not.

Let’s start with the first call and its origination phase. When CM receives this INVITE, it executes features that are applicable to the caller. For instance, all calling restrictions for that user would be applied here.

Here we see the INVITE sent from SM to CM.


Take a look at the top ROUTE header to see the following:

phase=imsorig. This tells CM to perform origination sequencing.

seq=explicit. Explicit sequencing indicates that this sequence was assigned to a SIP user and not a telephone number (implicit sequencing).

Here is the INVITE that CM returns to SM. At this point, the origination phase has been completed.


Note that the phase is origdone.

At the completion of the origination phase, SM begins the termination phase. Since CM is part of the termination sequence, the INVITE goes back to CM for processing.

The termination phase will perform all features that are applicable to the called party. An example would be any Forward settings for that user.

Here we see the INVITE sent from SM to CM.


Note that the phase is imsterm.

Finally, CM sends the INVITE back to SM.


Note that the phase is termdone.

If there were other applications in the termination sequence, they would now be invoked.  If not (the most common case), the INVITE is sent to the next hop.  In my example, the next hop is my telephone.

That’s All Folks

I could spend a lot more time on this, but I don’t want to overwhelm you with too much detail too quickly. In a subsequent article, I will dig even deeper to how Communication Manager adds services within call flows.

Again, SIP the protocol can be very different from SIP the solution. If you understand the unique Avaya approach, you will have a much easier time debugging problems.

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.