Session Manager Tracing
From Jaymzworld
Contents |
SIP Tracer
SIP Tracer allows advanced tracing of SIP messages exchanged between the Session Manager server and remote SIP entities. SIP Tracer consists of two components:
- Tracer Configuration - defines the characteristics of messages to be traced for the capturing engine in the Security Module
- Trace Viewer displays the captured SIP messages You can use SIP message tracing to troubleshoot or monitor a selected Session Manager instance. SIP tracing enables the logging of incoming and outgoing SIP messages in the SM100 framework. SIP messages that are dropped by any of the SM100 components such as SIP firewall are also logged by the SIP tracer. You can trace all the messages belonging to a user for a call or for a selected Session Manager instance.
Tracer Configuration
The Tracer Configuration page allows you to configure tracing properties for each administered Session Manager. The output of the SIP Trace is viewable on the System Manager.
To configure SIP tracing, select Session Manager > Tracer Configuration in the left navigation pane of the System Manager Common Console.
There are three Call Filters and three User Filters which can be configured separately for each Session Manager in the cluster. Each time a new Tracer configuration is sent to a Session Manager, the existing Tracer configuration is overwritten.
The Tracer Configuration page has four sections:
- Basic configuration: This section has six check boxes that control the basic functionality of SIP Message tracer
- User Filter: To filter SIP messages based on the users, click New under User Filter.
- You can define a maximum of three separate user filters.
- An empty value in the From and To fields means that every message matches.
- The format for a valid sender/receiver is sip:1234@xyz.com, where 1234 is the user and xyz.com is the domain.
- To delete an existing user filter, check the box next to the filter and click Delete.
- Call Filter: To filter all SIP messages that start a new call, click New under Call Filter.
- You can define a maximum of three separate call filters.
- All the messages in a call are identified by their unique call ID, To tag, and From tag from the header values.
- A valid sender/receiver string, for example, is: sip:1234@xyz.com, where 1234 is the user and xyz.com is the domain.
- An empty value in the From and To fields means that every message matches.
- To delete an existing call filter, select the filter and click Delete.
- Session Manager Network: Select one or more of the administered Session Manager instances from the list under Session Manager Network on which to apply the filters.
Click the Commit button to apply the filters to the selected Session Managers. Any previous filter configurations are overwritten.
Trace Viewer
Trace Viewer allows you to view SIP message trace logs based on the filters that you have configured. You can view these trace logs for a range of hours or days and for selected Session Manager instances.
If you select a message and click Show in the Details column, it will provide you a detailed view of the message headers.
Finally, capture output, both summary and detailed, can be exported to file by using the More Actions button.
Call Routing Test
Call routing tests are used to test routing of a SIP INVITE based on the current Session Manager administration. You can use it to verify that Session Manager has been administered correctly before placing it into service, or to get feedback on why a certain type of call is not being routed as expected. The testing of call routing using Session Manager does not send any real SIP messages.
This test displays the routing decision process as it uses the SIP routing algorithms. It uses administration from the following forms:
- Network Routing Policy > Adaptations, Dial Patterns, Entity Links, Locations, Routing Policies, SIP Domains, SIP Entities, Time Ranges
- Session Manager > Session Manager Administration
Call Routing Test page field descriptions
| Name | Description |
|---|---|
| Calling Party URI | The SIP URI of the calling party. You must specify a handle and a domain, for example, 5552000@domain.com. You can also specify a full URI such as sip:5555555@domain.com:5060;sometag=3;othertag=4. You can also copy a URI recorded in a SIP trace and use it. |
| Calling Party Address | The IP address or host name from which the INVITE is received. For routing, this is the IP address of a SIP Entity. You can enter any IP address that you require, but make sure that it is recognized by Session Manager. If it is not, Session Manager considers it to have come from a non-trusted host and rejects it. |
| Called Party URI | The SIP URI of the called party. You must specify a handle and a domain, for example, sip:5551000@companydomain.com. You can also specify a full URI such as sip:5555555@domain.com:5060;sometag=3;othertag=4. You can also copy a URI recorded in a SIP trace and use it. |
| Session Manager Listen Port | The port on which the called Session Manager Instance receives the INVITE. |
| Day of Week | Day of the week. This is used for testing time of the day routing. |
| Time (UTC) | Time. This is used for testing time of the day based routing. |
| Transport Protocol | Protocol used for transportation of the call. This is used in testing the routing based on NRP entity links. |
| Called Session Manager Instance | The Session Manager instance that receives the INVITE sent for testing routing. This is used in testing the routing based on NRP entity links. |
| Button | Description |
|---|---|
| Execute Test | Carries out the routing test based on the parameters that you provide.
The Routing Decisions box displays the result of the routing test. This result displays one line per destination choice. For a destination that has alternate routing choices available, the result displays one line per alternate routing choice and the lines are in the same order that the test attempted the destinations. Each line displays not only where the INVITE would be routed, but also what the adapted digits and domain would be. The Routing Decision Process box contains details about how Session Manager made the routing decisions. This gives you a tool to check your routing algorithms. |
TraceASM
traceASM is located at /opt/Avaya/contrib/bin. In is run from the command line, and provides the following features:
- Filter calls that contain <URI|NUMBER> in the From or To field.
- Filter SIP messages from/to a particular IP address.
- Filter based on the SIP Call-ID header field.
- Filter SIP header field <HEA> for value <VALUE>.
- Use a logical OR operator instead of the implicit AND when using multiple filter options.
- Filter out REGISTER messages.
- Filter out SUBSCRIBE/NOTIFY messages.
- Filter out OPTIONS messages.
- Filter out ASM related messages.
- Enable Asset point of view. This option is useful when the Asset hardware/software is used. The Asset acts as a proxy, so ASM only transfer packets to/from the Asset and the diagram will usually (default option) show only the Asset IP column. Enabling this option will display the IPs of the far end SIP Entities from the Asset perspective. You can also enable/disable this using the a key.
- Start with a clear screen, instead of decoding the current traceASM.log file.
- Open the traceASM.log file(s) previously captured with traceASM. More than one file can be specified. If no file is specified, then you can start/stop the capture using the s key.
The Filter options can take a regular expression. Filters are also available by pressing f in the application.
- WARNING
- traceASM may use high CPU and memory in a busy ServiceHost. The capture will stop automatically if captured 10000 packets
- In SM 5.2 and below, traceASM redirects normal log output to /opt/Avaya/SIPAS/current/ServiceHost0/var/traceASM.log.
- In SM 6.0 and higher, output is kept in /var/log/Avaya/sm/ServiceHost.
Below is an example trace which includes the proxy work by the ASSET card.
-----------------------------------------------------------------------------------------------------------------------
10.0.19.11 Texas
Asset
-----------------------------------------------------------------------------------------------------------------------
13:48:38,410 | |<----BYE---| | (8) sip:3022@10.0.19.11
13:48:38,414 |<----BYE---| | | (8) sip:3022@10.0.19.11
13:48:38,451 |--200 OK-->| | | (8) 200 OK
13:48:38,456 | |--200 OK-->| | (8) 200 OK
13:53:57,885 |--INVITE-->| | | (9) T:70501 F:3022 U:70501
13:53:57,889 |<--Trying--| | | (9) 100 Trying
13:53:57,897 | Request originating SIP Entity | for: 10.0.19.11 5061 TLS
13:53:57,897 | Originating SIP Entity found | SIPEntity: Maine
13:53:57,899 | Request ingress Adaptation | for: 70501
13:53:57,899 | Adaptation result | result: 70501
13:53:57,899 | Originating Location found | Location: IPT Lab
13:53:57,899 | Request Dial Pattern route | for: sip:70501@asmlab.com Location: IPT Lab
13:53:57,899 | Dial Pattern route parameters | URI Domain: asmlab.com Location: IPT Lab
13:53:57,899 | Trying Dial Pattern route | Domain: asmlab.com Location: IPT Lab
13:53:57,899 | Dial Pattern route parameters | URI Domain: null Location: IPT Lab
13:53:57,899 | Trying Dial Pattern route | Domain: null Location: IPT Lab
13:53:57,900 | Dial Pattern route parameters | URI Domain: asmlab.com Location: null
13:53:57,900 | Trying Dial Pattern route | Domain: asmlab.com Location: null
13:53:57,900 | Dial Pattern route parameters | URI Domain: null Location: null
13:53:57,900 | Trying Dial Pattern route | Domain: null Location: null
13:53:57,900 | Dial Pattern found | for: < 70501> and domain < null > Pattern: 705
13:53:57,900 | Route found | for: sip:70501@asmlab.com SIPEntity: Texas
13:53:57,900 | Entity Link found | SIPEntity: Texas EntityLink: TLS:5061
13:53:57,901 | Request egress Adaptation | for: 70501
13:53:57,901 | Adaptation result | result: 70501
13:53:57,905 | No hostname resolution required | Routing to: sip:10.0.24.20:5061;transport=tls;lr;phase=terminating
13:53:57,906 | Originating Location found | Location: ASM Lab
13:53:57,909 | |--INVITE-->| | (9) T:70501 F:3022 U:70501
13:53:57,914 | |<--Trying--| | (9) 100 Trying
13:53:57,928 | |<--Ringing-| | (9) 180 Ringing
13:53:57,934 |<--Ringing-| | | (9) 180 Ringing
13:53:57,976 |---PRACK-->| | | (9) sip:70501@10.0.24.20
13:53:57,980 | |---PRACK-->| | (9) sip:70501@10.0.24.20
13:53:57,985 | |<--200 OK--| | (9) 200 OK
13:53:57,988 |<--200 OK--| | | (9) 200 OK
13:53:59,685 | |<--200 OK--| | (9) 200 OK
13:53:59,693 |<--200 OK--| | | (9) 200 OK
13:53:59,755 |----ACK--->| | | (9) sip:70501@10.0.24.20
13:53:59,758 | |----ACK--->| | (9) sip:70501@10.0.24.20
13:53:59,795 | |<--reINVIT-| | (9) sip:3022@10.0.19.11 F:70501 U:3022
13:53:59,797 | |--Trying-->| | (9) 100 Trying
13:53:59,800 |<--reINVIT-| | | (9) sip:3022@10.0.19.11 F:70501 U:3022
13:53:59,849 |--Trying-->| | | (9) 100 Trying
13:53:59,864 |--200 OK-->| | | (9) 200 OK
13:53:59,868 | |--200 OK-->| | (9) 200 OK
13:53:59,877 | |<----ACK---| | (9) sip:3022@10.0.19.11
13:53:59,880 |<----ACK---| | | (9) sip:3022@10.0.19.11
13:53:59,991 |--reINVIT->| | | (9) T:70501 F:3022 U:70501
13:53:59,993 |<--Trying--| | | (9) 100 Trying
13:53:59,996 | |--reINVIT->| | (9) T:70501 F:3022 U:70501
13:54:00,001 | |<--Trying--| | (9) 100 Trying
13:54:00,003 | |<--200 OK--| | (9) 200 OK
13:54:00,007 |<--200 OK--| | | (9) 200 OK
13:54:00,231 |----ACK--->| | | (9) sip:70501@10.0.24.20
13:54:00,235 | |----ACK--->| | (9) sip:70501@10.0.24.20
13:54:01,165 | |<----BYE---| | (9) sip:3022@10.0.19.11
13:54:01,170 |<----BYE---| | | (9) sip:3022@10.0.19.11
13:54:01,234 |--200 OK-->| | | (9) 200 OK
13:54:01,239 | |--200 OK-->| | (9) 200 OK
Stopped | s=Start q=Quit ENTER=Details f=Filters w=Write a=Asset c=Clear
Usage examples
- Usage
Usage: traceSM [-h] [-u <URI|NUMBER>] [-i <IP>] [-c <CALL-ID>] [-g <HEA>=<VALUE>] [-or] [-nr] [-ns] [-no] [-na] [-nd] [-uni] [-a] [-x] [-r] [-m] [<SM_LOG_FILE>...]
Where:
-u <URI|NUMBER> Filter calls that contain <URI|NUMBER> in the 'From' or
'To' field.
-i <IP> Filter SIP messages from/to <IP> address.
-c <CALL-ID> Filter based on the SIP 'Call-ID' header field.
-g <HEA>=<VALUE> Filter SIP header field <HEA> for value <VALUE>.
-or Use a logical OR operator instead of the implicit
AND when using multiple filter options.
-nr Do not display REGISTER messages.
-ns Do not display SUBSCRIBE/NOTIFY messages.
-no Do not display OPTIONS messages.
-na Do not display SM related messages.
-nd Do not lookup the Postgres DB to resolve names (Locations,
SIP Entities, Route Patterns, etc.)
-uni Use Unicode/UTF-8 characters. Display the arrows and other
lines in 'graphic' mode. Your terminal client has to
support Unicode to display this correctly. For example,
PuTTY using unicode fonts (like 'Lucida Console').
-a Disable SM100 point of view.
-x Start with a clear screen. Do not decode the current
traceSM.log file.
-r Display the RTP simulation. This is not based on the actual
RTP packets but using just the SDP content.
-m Allows to run multiple instances of traceSM. Do not use
this option in a production system as it may cause
performace issues.
<SM_LOG_FILE> File name of the traceSM.log file(s) previously captured
with traceSM. More than one file can be specified. If no
file is specified, then you can start/stop the capture
using the 's' key.
The Filter options can take a regular expression. Filters are also available
by pressing 'f' in the application.
WARNING: traceSM may use high CPU and memory in a busy ServiceHost. The
capture will stop automatically if captured 10000 packets
NOTE: traceSM captures SIP messages at the SIPAS application. For this reason
it makes the best estimates of where the messages are being sent/received
, but may not represent exactly what goes 'on the wire'.
To have a view of what goes to the wire the trace needs to be done at the
SM100 level, and you can use the traceSM100 tool for it.
- To start a new capture, run 'traceASM' without arguments and then press 's'
# traceSM
- To filter SIP messages from/to 1.1.1.1 and 2.2.2.2
# traceSM -i "1.1.1.1|2.2.2.2"
- To analyze a previously captured traceASM.log file named my_asm.log
# traceSM my_asm.log
- To filter SIP messages containing 'Avaya' in the User-Agent header field
# traceSM -g "User-Agent=Avaya"
- Bypass decoding the current log at startup
# traceSM -x
traceSM
- In later loads (5.2 and higher) traceASM became traceSM and was shipped as part of the SM solution.
- The log file location was changed to /var/log/Avaya/sm/ServiceHost/traceSM.log.
traceSM100
Traces on the SM100 itself.
clcalls
clcalls (also known as clc) is a call trace tool to interrogate SIP messages in the calls.log files. It is dependent on SIP logging being active.
References
- Avaya "Maintaining and Troubleshooting Avaya Aura Session Manager". Avaya, June 19, 2009
