Session Manager Troubleshooting Techniques
The 2 steps to find and assess SIP Trunks, Call Handling, and SIP-UAs
As you read through this post, “ Session Manager Troubleshooting Techniques,” you learn how to identify two of the most common techniques to find and fix SIP connections, how users experience call-handling difficulties, and help identify those misconfigured elements that allow SIP User Agents establish communication with the Avaya Session Manager solution, the Communications Manager or the third party voice system.
Lately, I have been given the opportunity to help our remote customers; especially those having problems with SMGR, SM, and CM. I decided to write some of those lessons learned here, to help those to avoid some of the mistake I’ve made along the way, and at the same time learn from them.
The 2 steps to troubleshoot Session Manager:
- 1.- Start with the basics
- 2.- What to analyze
1.- Start with the basics:
It is very easy to start troubleshooting the more complex elements bypassing the simple ones. Many times I have found myself spending most of my time gathering system configuration and piecing all of the elements together, in order to understand how of the VoIP solution is designed. These are some of the tips that you can follow=
Work Orders and Customer’s History – Before you start working or helping the customer, see if they have experience the same issue(s) in the past by looking through the customer’s history.
VoIP Components – When working with large customer you find multiple servers responsible for handling the SIP calls from cradle to grave. Some of these are= Session Border Controllers, SMs, SMGRs, CM, Audio-Codes-SIP Gateways, among others.
2.- What to analyze
When you first start working on verifying the customers’ problem always start by going through the Communication’s manager configuration and routing, then move on to the Session Manager elements related to the specific issue. These are some of the most common ones=
Down Trunk Group – For this type of errors, you need to start by checking the Communications Manager first then move to the Entity links under Session Manager (SM). From the CLI you can run the following command to gather a quick overview=
Communication Manager (CM)
- List trunk type sip – This command helps you find the SIP trunks used to interconnect Session Manager.
- List trace tac xxx – Run this command while having the person who’s having the problem on the phone, making a test call.
The trace should look something like this=
From a SIP Extension – When calls are originated as a SIP-UA, calls will be sent from SM to CM via a particular SIP Trunk. Run the “List trace tac xxx” on the SIP Trunk. then If the SIP-UA is trying to call out from CM’s ISDN or a SIP Trunk connected to a SBC, run another trace .
This is what a SIP Message will look like when tracing it through CM=
10:49:15 SIP>INVITE sip:555121@mydomain.com SIP/2.0
Message Definition
10:49:15= Time of the SIP Invite
SIP> = Direction of the SIP Message. –> = coming to CM, and <– Leaving CM.
INVITE= SIP Message Type
sip:555121@mydomain.com = SIP User Agent sending the INVITE Request
SIP/2.0 = Session Initiation Protocol Version 2
This INVITE SIP Message header has the Call-ID: 8084ae6bef5ie71a11558c7de00 (encrypted for security purposes) included in the SIP Header. Once received by CM, it will then respond with 100 TRYING SIP Message, and so on. Until the session gets stablished.
Testing the SIP Trunk from Session Manager – There are two quick commands that allows you to see when the trunk went down, or last came up in service. These two commands are ran from the Root login with SM-6.3=
- Entity Link Status Command (copy and paste the entire script)
sm console GET AllMonitoredEntities|sed s/.*name=/”/|awk -F, ‘{print $1″ “$2}’
- Entity Link Event History Command (copy and paste the entire script)
sm console GET AllMonitoredEntities |sed s/.*name=/”/|sed s/”, 201″/” 201″/g|awk -F, ‘BEGIN{sp=” “;sp2=” “}{print $1;for (i=1;i<NF;i++) {if(i>2) printf(“%s”,sp2) ; print sp””$i }}’|egrep -i “status=|MonitoredAddress|up at|down at|^\””|sed s/”.*MonitoredAddress\[“/” “/g|sed s/“transitions=\[“/””/
These two commands provide you with the Entity Links created under Session Manager, with the status and when the interface (Entity Link) came UP or Down with the SIP Message related to the event.
SIP Endpoint Call Handling Issues – These are related to missing system configuration or misconfigured SIP User Agent. Very similar to the trunk troubleshooting method, you should start by working on the Telecommunication system first, then move on to the SMGR.
From the Avaya communication run the following commands=
- Status station – When running this command look for the registered location of the SIP-Endpoint, as well as the Network Region. If possible find a working SIP User and compare the settings.
- Application verification – Microsoft-Lync and One-X Communicator are the most popular Light User Agents configured to work as a Soft-phone. Help the customer go through each of these applications, and verify that all of the settings are configured correctly.
- CM Features and SIP Integration – When troubleshooting inbound call rejection problems, check with the customer that they don’t have Send All Calls, DND or other redirect options activated, and if they do, then test the Coverage Paths.
- off-pbx-telephone station-mapping – This table allows Communications Manager send the call through the AAR tables to the SIP Server. I have found duplicated entries here.
From SM (Session Manager) run the following utility=
TraceSM – This tools helps you identify 4xx, 5xx, and 6xx SIP Error Messages. As you run it through SM’s cust’s home directory, you can filter some of the events by following the option given to you while running the tool. You can save it to the local directory and exported to PCAP for later analysis.
One thing to consider is the “Call Processing” Option. It provides a more detailed trace than the regular SIP Trace. Just keep in mind to stop the trace right after the call has been terminated.
Other Considerations – Networks are the main conductor of the data delivery for these systems. It is important to confirm that the network components are configured correctly from End to End. VLANs, Routing, Firewalls, and ACLs, are some of the elements responsible to allow these services to work.
3rd Party Telecommunication Systems – I have found that some customer forget to configure their stations in their system causing a 404 Not Found message. So in other words, do not take anything for grated, and assume that some of the components are programmed.
Question – Which filters do you use with TraceSM?
Resources
Please note: I reserve the right to delete comments that are offensive or off-topic.