A traceSM view of Avaya Aura IMS Processing

It goes without saying that SIP is a protocol. After all, it is 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 teach SIP and that is 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 an Avaya Aura system 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 their 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 may find these two articles useful for understanding the following call flows:

Understanding Avaya Aura and IMS

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.

You 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 also need to configure two application sequences – origination and termination. Sequences are a list of applications/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 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 it receives 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:

• IMSORIG
• ORIGDONE
• IMSTERM
• TERMDONE

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 is sent 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 address the differences that arise from Evolution vs. Feature Server processing. However, that’s not important to understand these call flows.

Again, SIP the protocol can be very different from SIP the solution. If you understand each vendor’s unique approach, you will have a much easier time debugging problems. I hope this article helped in understanding a little more about how Avaya’s solution works.

Tags: Avaya, Session Management, SIP