SMGR & SM – Basic Components

SMGR (System Manager)  & SM (Session Manager) – Analogy of their processes, and elements.

By the end of this post ‘SMGR and SM – Basic Components’ you will understand some of the core components of both Session Manager (SM) and System Manager (SMGR). These Avaya Aura Servers are crucial whenever running a VoIP Topology with different kinds of solutions, or PBXs. They both help to facilitate the management, and integration of systems from one console. They also help with software deployment, licensing, alarm monitoring, and many other features.

As a Service Engineer, you might find yourself helping customers deploying, adding, upgrading, or troubleshooting SMGR(s) or SM(s). As a good practice, take time to review the implementation worksheets with IP Addresses, FQDNs, DNS, NTP, and other network information, that form part of the customer’s VoIP infrastructure. You will gain an advantage by getting familiar with the customer’s configuration. Making it easier to understand where failure occurs, and it helps you to communicate better your ideas.

For those performing maintenance

Have a thorough conversation with the site contact to help identify the existing issues. And finally try to duplicate the problem. Remember to jot down every step, and failures. as these can be caused by user-error, or a 3rd party entity malfunctioning.

I broke-down the key elements for these two servers SM and SMGR. Let’s start with with SM

Key components of Session Manager

• 1.- Basic Overview
• 2.- Entity in a nutshell
• 3.- Network and Centralized Routing
• 4.- Media Types
• 5.- Registration Process
• 6.- Adaptation Modules
• 7.- CAC
• 8.- SM100
• *. Question

1.- Basic Overview of SM

By now you should know that SM is a server that helps integrate SIP Entities and SIP End-Points. If your customer has a multisite topology, it is recommended to have multiple SMs through multiple geographical sites as redundant servers.

The Session Manager server acts as a Registration, Redirect, Proxy, and Location Server; all in one. Storing SIP User Agent (UA) information, including location, login credentials, etc. This application server has 3 servers running on its core. The Service Director, Service Host and Management Servers.

Service Director – It performs load-balancing between servers, and it also analyzes the incoming SIP traffic.

Service Host – Its responsible of hosting the SIP Servlets, and its where the call processing resides. It also decides CAC and redundancy.

SM Management Server – is a JBoss Server hosting the SIP A/S Management Console which provides performance monitoring, and statistics.

Session Manager – Its call processing primarily servers two purposes= SRE (Sip Routing Element) and URE (User Routing Element).

2.- Entity in a nutshell

Each entity are trusted by the SM Server, and these can be SIP enabled PBXs, Gateways, etc.

3.- Network and Centralized Routing Policies

Network Routing Policies are used for H.323 endpoints using Dial Pattern Matching and Routing Policies, allowing communication between non-sip endpoints. Centralized Routing – its a trust relationship between UAs or SIP Endpoints using the same policies already mentioned.

4.- Media Types

SM utilizes G729 for voice, and H.264 for video as the prefer media types.

5.- Registration Process

For the initial authentication, Session Manager will reject the first request from the UA, forcing it to resend another request with username and password. A SIP Communication Profile has to be created in SM, before the UA is authenticated.

6.- Adaptation Modules

These Modules serve as translators whenever a call is made between different vendors.

7.- CAC

Call Admission Control, adjusts the bandwidth used between sites. Each location will have a total bandwidth assigned to help the over-utilizing of the pipe connecting both locations.

8.- SM100

this module acts as a firewall, handling DoS, SIP Authentication, etc. For secured deployments. It uses TLS and PKI Certificates, and for non-secure connections it utilizes TCP/UDP.

Question

What are some of the benefits of the Failover feature of Session Manager?

What Certificate issues, have you experienced before?

System Manager (SMGR)

SMRG runs on System Platform (SP) in a dedicated server offering the enduser the facility of a central management solution.

Key components of SMGR

• 1.- Console Management
• 2.- User Management
• 3.- SSO
• 4.- Data Replication
• 5.- Fault Management
• 6.- Maintenance Commands
• 7.- Console Management
• *.- Maintenance Procedures

1.- Console Management

The SMGR sits in the center of the VoIP Topology providing system administrators the facility of managing, implement, and maintain different network elements through one operating console. Its database resides in a Core Server, then it gets pushed out in a time interval to different Entities.

2.- User Management

SMGR uses two groups or classes of users, Administrators and Communication Users. The Admin User Class is responsible of controlling any provision needed to any of the existing network entities. The Communication User Class are the ones utilizing the existing services created by the Administrator User Class.

3.- SSO

The Single Signed On is another cool features of the SMGR, which allows users to manage different elements in the Avaya VoIP Topology with one account and password.

4.- Data Replication

The Data Replication updates the Session Manager(s).

SIP Domain, Location, SM Entities, and instances are some of the modules created in SMGR then pushed to SM(s).

5.- Fault Management

This feature of SMGR uses a SAL Agent to help status Alarms, Traps and notification of any existing entity having issues or generated alarms. Aside from monitoring the existing events, SMGR Fault Mgmt. allows the system admin to acknowledged, retiring, and clearing the exiting alarms, as well as exporting these to a file if needed.

*.- Maintenance Procedures

There are an array of commands available, I will list some of the health commands normally used. But first I will go over some other components that are worth mentioning.

Time Server – For first initialization SM and SMGR use the same NTP server. If for some reason the time is off, this might cause an issue when syncing both servers.

FQDN (Fully Qualify Domain Name) – is used in the authentication process.

Data Replication Service – (DRS). It replicates the data residing on SMGR out to the SMs. To do this manually, run the command= initDRS from the SMGR’s shell terminal console.

InitTM (Trust Management) – This service or app is use to manually establish trust relationships between SMGR and SM.

Commands

swversion – Displays the Software version of Session Manager and its components.

statapp – Check the status of the applications.

statapp -u – Displays the expected running apps

smconfig – Shows the IPs and FQDNs associated with he server, plus service state of the SM(s).

restart sm-mgmtn – this command restarts SM if partially up or completed down.

xm reboot smgr – restarts SMGR (run this command from the CDOM). 

cat hosts – It will pull up the DNS records associated to the SMGR or SM.

createCA – It generates a Certificate for SMGR. (Keep in mind that whenever Certs are created)

For a list of common SMGR Q&As visit this link below

SMGR Troubleshooting Guide