Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Tracking H.323 Calls in CUCM SDI Traces
Disclaimer: This document is written with CUCM 7.X in mind, but will be applicable to all CUCM versions with small amounts of tweaking.
Follow this excellent document for turning on CUCM traces. Pay particular attention to the H.225 and H.245 check boxes.
Recreate Issue / Place Test Calls
Get the calling party number, called party number, and time of the call.
Download Relevant Traces
Follow these instructions to download CallManager traces from all nodes in the cluster during the time of the call.
Download Advanced Analytical Application
I prefer Notepad++, but any text editor with highlighting or searching will work. If you want to run unix2dos on the trace files beforehand you could even use the standard Windows Notepad. Downloading a tool like TripleComboTool or TranslatorX is basically cheating, but can be useful.
This is where all of the fun comes in. We now have folders full of trace files. You can download the traces I used for this example in the attached file H323Trace.zip. Somewhere in the potentially Gigabytes of files we collected is our call. Here's how to find it then track it.
Locate the problem call
I like to use a tool like WinGrep, or even Linux grep to just get an idea of which trace files to look at.
My example call has the following details:
Calling Party - 7021004
Called Party - 8011000
Calling Time (Taken from Placed Calls phone menu) - 11:45
The seach queries would be things like
These two strings will find the Digit Analysis line in CUCM. cn stands for Calling Number. dd stands for Dialed Digits. Let's take a look at using grep to find the trace file we're interested in.
-E extended regular expressions (in case we want to get fancy with regex)
-i case insensitive search (in case we want to get lazy)
--include to search through only files that had names like ccm*.txt
If we only knew the calling number we could change our search string accordingly. If we received no resutls we could remove the cn or dd portion and just search for the number. If searching for the 7 digit number didn't work we could search for just the last 4 digits until we found our call.
Based on the search we see that our file is located in
The TCP Handle of that particular IP Phone is 0000003. That indicates this phone was the 3rd one to register since starting the CCM process on this node. We could do a grep for that particular TCP handle to get all SCCP messages sent to and from the phone.
StationInit - The phone sent this message to CUCM
StationD - The CUCM sent this message to the phone
Let's use Notepad++ to highlight this in the trace. Highlight the handle, right click, select "Using 1st Style". Now this will be light blue anywhere in the trace file.
Find the Process ID for this call and Process ID for the called party
Each call leg has a CallID. This is a unique identifier for that leg of the call. It's commonly referred to as a CI.
Each call also has a cdcc process. This is primary call control process for the call.
Each called party has a process associated with it. This is where CUCM is going to send the call.
We can learn all of these in the few lines after the Digit Analysis Block
06/24/2010 11:45:32.095 CCM|Digit analysis: insert daResEntry to daResCache.
Here we learn the Ci for the call 42514739, as well as the cdcc(2,174,4). It's helpful to highlight these in the trace as well.
Through the dmpidreq and dmpidres (Request and Response) we can get the Process ID (pid) of the party we're going to extend the call to:
We see that the Route Pattern I matched was 801XXXX, and that this pattern points to RouteListControl. The Process ID for this is (1,100,61,2).
Track the called process to the correct node
The Route List Control process exists on Node 1 (the publisher) and we're currently on the subscriber. It exists inside the CUCM process (100). This means the subscriber will now have to send a message to Route List Control on the publisher.
I typically match Node IDs to server names by looking at the SDL trace files. For example, here we can see that cucm7-sub1 is Node 2 (SDL002_*.txt)
Since we know the signal was sent to Node 1, and Node 2 is the subscriber, we can search the SDL trace folders for Node 1. Node 1 is always the publisher server (but your publisher might not always be Node1 based on your CCM version and whether or not you've activated and deactivated servces).
Let's open the CCM trace on the publisher at the time in question, 11:45:32.096
The most important part of this message for tracking the rest of the call is the guid '807B41849C7D31C2030003010E302CCF'H. This is an identifier unique to the call. We can use grep or wingrep now to search on this guid. We can find out how many traces this guid appears in and then open all of these traces in our editor of choice.
Along with the exploded H.225 message body there is also a compact printout of the H.225 message:
This gives us an extremely succinct way to track all of the messages in a call. We can see the first message is an Outbound Setup and it contains the ASCII values of the called and calling numbers.
Calling 37 30 32 31 30 30 34
Called 38 30 31 31 30 30 30
Since these are in ASCII and they're digits all you need to do to get he numbers is just remove the leading 3 from each group of numbers. This is very handy for double checking which number gets sent to the far end H.323 device.
The second message is a Inbound Proceeding message.
We tie these messages together based on the ISDN identifier, which starts at the third octet.
The identifier portion is 0 03. The first character indicates direction. 0 stands for the outbound direction in this case (Outbound SETUP was 00 03). The inbound direction will be outbound + 8 (hex), or 8 in this case (Inbound CallProceeding was 80 03).
Find the Negotiated H.245 Port
Messages like Setup, Proceeding, Alerting, Connect, and Release Complete will be exchanged over the H.225 protocol. These messages are for call control. There is a completely different protocol called H.245 that is used to negotiate the IP addresses, UDP Port numbers, and codec that will be used for the media streams of the call.
In either the Alerting, or Connect message the called endpoint will put in a section called H.245 address. This port triggers the calling party to setup a new TCP session to the called party for the purposes of exchanging H.245 messages.
I used Notepad++ to search for the guid in all trace files, then browsed through all of the H.225 messages until I find the one with the port:
Here you can see that the H.245 port is 58820 and it comes in the Connect message at 11:45:34 (when the called party answered). I've highlighted this port as it is crucial to our next step.
Locate the H.245 TTPid based on H.245 Port
Now that we have the H.245 Port we can look for the process identifier that will allow us to find all H.245 messages for this call.
This procedure below only applies to "Slow Start" calls. I will document "Fast Start" at another point in time.
If the H.245 port comes on an Inbound H.225 message, search down in the traces for the port number. We have to do post processing to create the H.245 process.
If the H.245 port is sent on an Outbound H.225 message, search up in the traces for the port number. We have already done the processing to make the H.245 process and THEN we send out the message with the port number.
This is an Inbound H.225 message in our example, so we will search down for the H.245 port number until we see a line that looks like this:
ip = (184.108.40.206), port = 58820, TA provided by Callee
In this instance we see that the H.245 interface created has a process ID of 3 H245Interface(3). All H.245 message for this call will be exchanged on that process. Search down until you see a message like the following to get the full process ID:
This is an Outbound TCS. The identifier that we'll use as our future search string is TtPid=(1,100,16,3). Go ahead and make this some other interesting color.
Use Notepad++ "Find in all Open Documents" (or similar search in your text editor) to get the full H.245 session output from the start of the call to the end:
Find the Capabilities in the Terminal Capability Set
Each side will advertise the supported capabilities in the Terminal Capability Set (TCS) message. One side will initially advertise all capabilities supported. The responding side will respond with the matching supported capabilities.
If we go back to the node where the H.245 session is ongoing, we see the following outgoing OpenLogicalChannelAck. Notice that the UDP RTP port number we send out on the H.323 leg is the exact port that the phone responded with in the SCCP ORCAck, 24418.