The RTMT Session Trace is a tool that processes a Call Log file CUCM uses to capture and log all SIP message activities. This log stores all incoming and outgoing calls or sessions that are handled by a CUCM call processing node in the cluster. Session Trace provides an easy to use tool for reviewing call flows for SIP calls. It even provides a nice ladder diagram for your viewing pleasure.
Call Trace Log
To leverage the power of the Session Trace tool, you need to ensure that the Call Trace log is enabled. If you aren't sure where you would modify this parameter then you are in luck because the Call Trace log is enabled by default.
You can modify the Call Trace log parameters by going to System>Enterprise Parameters of the CCMAdmin web portal. Scroll all the way down to the bottom of the page and you will find the following parameters:
You can modify the Call Trace log parameters by going to System>Enterprise Parameters of the CCMAdmin web portal. Scroll all the way down to the bottom of the page and you will find the following parameters:
- Enable Call Trace Log: Enabled by default
- Max. Number of Call Trace Log Files: 2000 by default (Min: 5 Max: 4000)
- Call Trace Log File Size (MB): 2 by default (Min: 1 Max: 10)
Just like any other trace file, the Call Trace log is cyclical and when the max number of files is reached, CUCM will begin overwriting records in the oldest file. The Call Trace logs are stored in /var/log/active/cm/trace/ccm/calllogs/.
Session Trace Example
Let's take a look at an example. We'll show the steps to access the tool and then give a quick tour of the interface and capabilities.
Accessing the Tool
Assume we have loaded RTMT and we want to get to the Session Trace tool. You can access it in two ways. Option 1, you can go to CallManager>Call Process>Session Trace. See the following figure.
Option 2, you can select CallManager from the tool bar on the side of the RTMT window and then select Session Trace. See the following figure.
The Interface
Once you access Session Trace, RTMT will automatically collect call information based on the current time. So, if the call you want to look at just happened then you will see it listed. You can also specify a different time slice using the search function. The following figure dissects the interface.
The areas highlighted in the above figure:
- Calling and Called party search criteria. Use '*' for either field to see all called or calling parties (as appropriate). You can't leave this field blank. If asterisk is a digit in the party field then use the backslash ("\") to escape the wildcard (e.g. using \*011* would get *011, *011123, *0111234, and so on).
- Use these fields to specify the relative time range. You can choose the timezone, starting time, and a duration of up to 60 minutes. So, if you specify 12:00:00 AM on 3/27/2012 with a duration of 45 minutes the Session Trace tool will query all calls that took place between 12:00:00AM and 12:45:00AM on 3/27/2012.
- Once you specify your search criteria click on Run to collect the log files.
- If calls are found they will be displayed in the results pane. If there are no calls found, Session Trace will provide an appropriate error message.
- If you select one of the calls, you will be able click on Trace Call to dive into the SIP messages exchanged during the call setup.
An interesting feature of the call flow diagram provided by Session Trace is that you can hover your mouse over any message and see a floating message box with some summary information. You can then explore that specific message in more detail (we'll get there soon enough). In this call flow diagram the IP phone SEP3037A61747C7 is sending an Invite message to 10.3.8.20, which is the CUCM call processing node. The CUCM digit analysis and call routing subroutine is then generating an Invite to 10.3.9.20, which is a Cisco Video Communications Server (VCS). The call flow also provides information on call tear down, as well.
When you hover over a message you the choice to "See message in log file" or "See SIP Message". The former display the message in context with other messages in the call log file while the latter displays pertinent information from the SIP header. The relevant information is displayed in the appropriate tabs of the call flow diagram window.
Conclusion
The Session Trace tool is definitely pretty handy and has prompted me to start re-discovering the RTMT interface to see what other goodies I have neglected in the past few revisions.
Thanks for reading. If you have time, post a comment!
William,
ReplyDeleteI had a go at this and I observed that it doesnt trace calls originating from any of my sccp devices. The only calls I can see are calls that are inbound via my CUBE to the CUCM. So I am beginning to think that unless my IP phone is a SIP endpoint, I may not be able to trace the relevant calls. For calls from CUBE that I see the trace, I dont see the call extensded to the IP phone. Again I can only imagine this is because my phones are sccp endpoints, hence there are no sip messages exhcanged and nothing for RTMT session trace to report
You are correct that RTMT session trace won't dissect SCCP call legs.
Delete-Bill (@ucguerrilla)
Hi Will
ReplyDeleteNice post but when i login to RTMT V 8.1 the session trace option is not avaible at all.
Does it have to a specific version.looking at the post is around 2012 v8.1 is not too old ?.
Kind Regards
Pramo
Pramo,
DeleteUnfortunately, RTMT versions don't line up with UCM versions. So, I don't know what versions of UCM that RTMT 8.1 maps to. What is the version on the UCM where you downloaded the plugin?
-Bill
THanks
ReplyDelete