Finally, it’s the blog you’ve all been waiting for! Yes, that’s right folks; the time has come to discuss the benefits of Real-Time Monitoring Tool (RTMT) in CUCM and CUC. All right, I know it’s not the most exciting subject to discuss all the topics on the CCIE Collaboration lab blueprint, but it can help you perform troubleshooting tasks in a very efficient manner. The goal for this blog is to point out a couple useful features of RTMT to give you a nice boost when tackling different lab topics.
For those that are not familiar with RTMT, it can be used to pull traces (log files) for troubleshooting in all Cisco UC servers, monitor real-time platform statistics, check syslog messages, and display a host of “Performance” parameters that can assist the engineer in gathering system information. While those are all great features worthy of our attention, I’d like to focus specifically on a new RTMT feature available in CUCM 9.x called “Session Trace Log View.” This feature is an excellent troubleshooting tool, especially when used with SIP. Essentially what this does for us is organize the traces in such a way as to provide a cohesive view of the messaging associated with a particular call flow.
As an example, let’s have a look at a simple call flow between two CUCM-registered phones. The HQ and SB CUCM clusters have a SIP ICT configured to allow calls between devices registered to each cluster. In this example, HQ Phone 1 will place a call to SB Phone 1 over the SIP ICT.
Before placing the call, log into RTMT for the HQ CUCM cluster (Publisher) and navigate to CallManager Call Manager Summary.
Next, on the left-hand pane, select the “Real Time Data” option under the “Session Trace Log View” heading. This will allow access to debug the call flow between HQ Phone 1 and SB Phone 1.
When the tool loads, the first thing that needs to happen is to set the starting date and time that should be used to search for call records. We should also set the duration to the maximum value (60 minutes) in order to provide greater searchability. In other words, we are creating a one-hour date/time range by which to search for calls. Yes, the method is a little bit strange, but we need to roll with it—we have no choice! Don’t forget to set the time according to the server time, not the time of the local PC. Also, make sure to select the proper time zone.
Once the date/time parameters are locked in, we are ready to make the test call. Place the call between HQ Phone 1 and SB Phone 1. When it completes successfully, go ahead and hang up. Now click the Run button within RTMT. This will reveal useful statistics about the call, such as “Calling DN”, “Orig Called DN”, “Called Device Name”, and “Termination Cause Code.” In this case, since the call was ended “normally” by hanging up the phone, the cause code is “(16) Normal Call Clearing.”
Now for the real magic! Double click the call record in order to launch an RTMT-created diagram of the call flow from the perspective of the HQ CUCM cluster.
As you can see in the screenshot, this provides an incredibly useful diagram of the call flow between devices. We have an overview of the SIP messaging that takes place between endpoints with each message being “clickable”.
Let’s click on the original INVITE message that is sent from the phone to the HQ CUCM Subscriber server (10.10.13.12) to reveal the details of the message.
As you can see in the above, the actual message is displayed, which is essential to understanding what is happening within the SIP call. If you click the “Call Flow Diagram” tab, you can return to the diagram to click another message in another part of the call flow if you so desire.
As mentioned above, RTMT is not only useful for CUCM servers, but also every other UC server on the CCIE Collaboration blueprint. In this next example, let’s focus on the Unity Connection server to explore the “Port Monitor” feature. This feature will provide access to view the real-time status of the ports along with statistics about each call that traverses them. Log in to RTMT for CUC and navigate to Unity Connection Port Monitor.
Next, select the server of interest from the dropdown box.
After the node has been selected, set the “Polling Rate” to the lowest value possible (1) and click the Set Polling Rate button. Then click the Start Polling Button to begin gathering data about the available Unity Connection ports.
At this point, all ports are now visible from the tool.
Now make a test call into Unity Connection by pressing the “Messages” key on SB Phone 1 and observe the behavior.
As you can see in the above, the call is displayed as a “Direct” call and has used the second available voicemail port in the system. In the case of a “Forwarded” call, it will be displayed differently in the tool. We can test this by attempting to leave a message for a user configured on the system.
In this case, the third available port was used in order to handle the forwarded call.
Once again, this can be a very useful tool when troubleshooting voicemail issues. Simply understanding if the call has been interpreted correctly on the Unity Connection server (either “Direct” or “Forwarded”) can make a world of difference in your troubleshooting approach.
So there you have it; a little bit more information about RTMT to help you prepare for and pass this lab! I hope you found this post useful and that it provides you with some much-needed ammunition to slay the beast that is the CCIE Collaboration lab! As always, if you need an extra push to get ready for the lab, are hitting roadblocks in your preparation, or just need some direction on how tackle the CCIE Collaboration Lab, give us a call and speak with an iPexpert Training Advisor about attending one of my bootcamps.
Thanks again for reading and good luck in your preparation!
Check out My Video on Demand Courses that feature in-depth information on Cisco Unified Communications Manager!
Learn CUCM Features from My Written Exam Prep VoD
iPexpert’s Cisco CCIE Collaboration Technology Workbook (Vol. 1) – Features 7 CUCM and CUCME Labs
