An Avaya Aura Session Manager Cookbook

A long time ago, I learned that I don’t fully understand something until I can explain it to someone else. Not only does that require me to translate the gobbledygook in my head into words, but it forces me to completely learn the subject I profess to know. Trust me when I say that neither one is a simple task. All too often I find that I can talk the talk, but need work on the walk.

With that in mind, allow me to present my bare bones cookbook for configuring an Avaya Session Manager. While mastering Session Manager is not trivial task, it can be made simpler by following a step-by-step flow of tasks.

Seasoned experts will probably have their own flows or variations of mine and that’s fine. As long as it gets the job done, there are many ways to skin this cat.

Note: This article only scratches the surface of what a Session Manager can do. To make this article manageable, I am going to keep things pretty simple. It’s my intention to dig deeper into several of these sections in future articles.

---

I’ve written a number of articles that you may find helpful in understanding this one.

A Necessary Guide to the Avaya traceSM Utility

A traceSM view of Avaya Aura IMS Processing

Avaya Aura IMS Processing Once Again

A Necessary Guide to the Avaya traceSBC Utility

---

Session Manager 101

Session Manager is a lot of things, but most importantly, it is a SIP routing engine. It moves SIP messages from one place to another place by implementing a set of configured rules. Along the way, it can enforce call admission control, time based routing, and apply SIP adaptations. It was designed to be fast, flexible, and resilient.

To allow routing to take place, you need to administer a number of different items. While there are perfectly fine variations to my approach, here is an example of a basic workflow for a brand new installation.

To keep things simple, I am only going to concern myself with one Session Manager, one Communication Manager, and one Session Border Controller. I will call these ASM1, CM1, and SBC1. Production systems will probably have an ESS, multiple core SMs, local survivable SMs, and duplicated SBCs. I am not going to worry about any of those things right now.

Also, I am assuming that both System Manager and Session Manager have been installed and trust management and database replication between the two has occurred.  All configuration in this cookbook occurs within System Manager, but I will point out a few things that need to take place on Communication Manager.  I will not be presenting the steps to create Communication Manager SIP signaling groups.  That’s a blog article for another day.

Building Boxes

To begin, you need to identify the SIP components that will be part of the network. Avaya does not treat all components the same, so it’s important to create the right configuration items in the right places and in the right order. While there may be other ways to do this, here is a fairly straightforward path.

Note: You must press Commit after each action to save and apply your changes.

Create a SIP Entity for Session Manager

This is accomplished under Home–>Routing–>SIP Entities.

Press New to create a new SIP Entity. Assign a name, set the FQDN, and choose a time zone for the Session Manager. Make sure you choose “Session Manager” as the type. You can ignore the other settings for now.

Create Session Manager Instance

This is accomplished under Home–>Session Manager–>Session Manager Administration. You can accept nearly all the defaults within the global configuration section at the top of the page.

Scroll down and press New. Use ASM1 for the name and set the appropriate values under General and Security Module. Note that Session Managers require two IP addresses. General is concerned with the management IP and Security Module deals with the SM100 interface. The SM100 interface handles all the SIP traffic to and from the Session Manager.

For simplification, I am going to ignore the rest of the sections as they are not required for a basic, working Session Manager.

Create SIP Entities for Communication Manager and the SBC

Return to Home–>Routing–>SIP Entities to create SIP entities for CM1 and SBC1. The type value for CM1 will be “Communication Manager” and the type value for SBC1 will be “Other.” Note that different configuration values will be presented for the different types.

Create Communication Manager Managed Element

Go to Home–>Services–>Inventory–>Manage Elements to create a managed element for CM1. Select “Communication Manager” as the type. After the new screen appears, click New and name the element. Next, assign an IP address, login user, and password. The user assigned here must have full administrative privileges – i.e. created using Profile 18 under Communication Manager’s web interface.

Make sure that Enable Notifications is set. This is necessary to synchronize administration changes made on Communication Manager (6.2 and later) and System Manager. Additionally, Communication Manager must have a trusted certificate from System Manager and rsyslog must be set up.

You can watch the synchronization status at Home–>Services–>Inventory–>Synchronization–>Communication System.

Building Routes

At this point, the component framework for this simple configuration is complete. We now need to create links between the different entities and build routing patterns that manage the flow of SIP traffic. For this, return to Home–>Routing and for the most part, walk down the list of configuration items.

Create SIP Domain

Go to Home–>Routing–>Domains and click New. Name the new domain. Notice how “SIP” is the only available type. For this example, let’s call the domain SIPAdventures.com.

Create Location

Go to Home–>Routing–>Locations and click New. Name the location and assign any necessary bandwidth values. These values can be used later for call admission control. Locations are also used for location-based routing.

Complete SIP Entities

We created data structures for all the hardware components in the first part of my cookbook. Now that we’ve created a logical location, edit CM1 and SBC1 to assign them to that location. Go to Home–>Routing–>SIP Entities and edit CM1 and SBC1. Choose the newly created location from the dropdown list. Session Managers can be also assigned to a location, but since Session Managers don’t process media, it’s not necessary to do so.

Create Entity Links

Entity Links define how SIP traffic flows from one SIP Entity to another. In this simple example, packets will travel between ASM1 and CM1 as well as ASM1 and SBC1. Traffic will never flow directly between CM1 and SBC1.

Go to Home–>Routing–>Entity Links and click New. Give the link a name. The link will consist of SIP Entity 1 speaking a protocol to a port on SIP Entity 2. For example, CM1 to ASM1, TLS, with both sides using port 5061. Create links for every protocol and port combination you need to support. Supported protocols are TLS, UDP, and TCP.

In this example, links are created for ASM1 to CM1 and ASM1 to SBC1. You do not need to create links in the opposite direction (e.g. CM1 to ASM1). All links are considered bidirectional.

Verify Entity Links

Go back to Home–>Routing–>SIP Entities and view the various SIP Entities to see that the new created Entity Links have been magically added. You do not need to add them yourself.

Create Routing Policies

Up until this point, we have been pretty much defining the plumbing of our system. We now get to create routing policies to define message flows and the conditions that trigger them.

Go to Home–>Routing–>Routing Policies and click New. Give the policy a name and select a destination. You can ignore the rest of the settings. They will get magically filled in for you after the next steps are completed.

In my example, we need routing policies between ASM1 and CM1 as well as ASM1 and SBC1. These policies define the conditions SIP traffic will be sent on the Entity Links to the SIP Entities.

Create Dial Patterns

This may be the most involved part of Session Manager programming. Dial patterns define the dialed digits and how they are manipulated during SIP routing. For fun, I looked at the defined dial patterns of my company, Arrow Systems Integration, and there are 18 pages of them. At 15 entries per page, that’s 270 different dial patterns!

However, for this exercise, let’s keep it simple and adhere to the following rules:

All digit manipulation within Session Manager will be done with E.164 numbers. Session Manager must be prepared to receive non E.164 numbers, but those numbers will be converted into an E.164 format.

SIP messages sent to Communication Manager will be E.164 without the plus sign.

SIP messages sent to the Session Border Controller will be E.164 with the plus sign.

For my example, I would create the following dial patterns. Note that I am designating all stations within Communication Manager begin with 952456. This, of course, is completely arbitrary. However, the E.164 rules are standard and can be applied to any Session Manager installation.

International E.164

North American PSTN

Local Communication Manager Dialing Plan

As Dial Patterns are created, apply them to Routing Policies. For this example, apply the Local CM Dialing Pattern to the route from ASM1 to CM1 and apply the North American PSTN pattern to the route from ASM1 to SBC1.

Create Adaptations

Session Manager Adaptations are applied to entities to normalize SIP messages and format dialed digits.  Adaptations are divided into three main categories – Digit, Domain, and Dialect. Digit adaptations manipulate digits, domain adaptations manipulate domains, and dialect adaptations massage SIP messages. For example, Cisco speaks SIP differently than Avaya and the messages between the two must be adapted.

These different types are not mutually exclusive. A dialect adaptation can also perform digit manipulation.

Here is a screen shot of the adaptation types that Session Manager supports. If you were going to build an adaptation for a CS1000, you would select CS1000Adaptor. The previously mentioned Cisco connection would require CiscoAdaptor. For better or worse, Avaya executes all the dialect adaptation within those modules and you cannot change or alter their processing logic.

For this example, we need to create an adaptor for SIP sessions that flow between Communication Manager and Session Manager. Click New, call it Make CM Happy, and select DigitConversionAdapator.

Notice how an adaptation has sections for calls to and calls from Session Manager. Calls from Communication Manager to Session Manager will convert numbers to E.164 and calls from Session Manager to Communication Manager will strip off the E.164 plus sign.

Apply Adaptations

Adaptations are then applied to SIP Entities in Home–>Routing–>SIP Entities. In my simple example, we only need to apply our digit conversion adaptation to CM1. Select CM1, click Edit, and select Make CM Happy from the dropdown list.

Whew

At this point, we have created a fully-meshed system that is capable of passing calls from the SBC all the way to Communication Manager and vice-versa. Note that I have not concerned myself with SIP users or SBC programming, but I didn’t want this article to go on forever.

It’s important to recognize that I didn’t take you into quite a few of the menu items. For instance, Session Manager can do time of day routing, but I ignored that. I also ignored priority and alternate routing. Those subjects deserve individual attention and will be dealt with in their own articles.

Tags: Avaya, Session Management, traceSBC, traceSM, Unified Communications