Professional Documents
Culture Documents
Enable Traces
Follow this excellent document for turning on CUCM traces. Pay particular attention to the
H.225 and H.245 check boxes.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
1
Dissect Traces
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.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
2
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.
jasburns@jasburns-gentoo ~/trace/H323Trace $ grep -REi --include "ccm*.txt" "dd=\"8011000" *
cucm7-sub1/2010-06-24_11-47-16/cm/trace/ccm/sdi/ccm00000002.txt:06/24/2010 11:45:32.095
CCM|Digit analysis: match(pi="2", fqcn="7021004", cn="7021004",plv="5", pss="",
TodFilteredPss="", dd="8011000",dac="0")
-R recursive
-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.
We also see some interesting things about the digit analysis line:
pss="" and TodFilteredPss="" means that the calling phone has a Calling Search Space set
to <None>. This value is usually the ordered list of partition inside the calling party's CSS.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
3
Let's open the trace file ccm*02.txt in our text editor and look at this line above.
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.
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.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
4
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.
KeyCi=42514739 ,PID:Cdcc(2,174,4)
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:
06/24/2010 11:45:32.096 CCM|Digit analysis: wait_DmPidRes- Partition=[] Pattern=[801XXXX]
Where=[], cmDeviceType=[AccessDevice], OutsideDialtone =[1], DeviceOverride=[0],
PID=RouteListControl(1,100,61,2)
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).
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)
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
5
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
cucm7-pub\2010-06-24_11-47-15\cm\trace\ccm\sdi\ccm00000002.txt
06/24/2010 11:45:32.100 CCM|RouteListControl::idle_CcSetupReq - RouteList(ICT_RL)
Here is the inbound request from the sub to the pub. We can see the call is going to a Route
List named "ICT_RL".
The Route List parses through the Route Groups, and you can see we pick a member of the
RG in the following trace
06/24/2010 11:45:32.101 CCM|SMDMSharedData::findLocalDevice - Name=ICTto801
Key=005cee5b-ef72-4919-4855-5983ba8b23f2 isActvie=1 Pid=(1,153,7) found
Lucky for us the PID of this device inside the Route Group is also on node 1. If we scroll
down a bit in the traces we should see the outbound H.323 call over this InterClusterTrunk.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
6
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
7
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.
We tie these messages together based on the ISDN identifier, which starts at the third octet.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
8
The identifier portion is 0 03. The first character indicates direction. 0 stands for the
outbound direction in this case. The outbound direction will be inbound + 8 (hex), or 8 in this
case.
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:
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
9
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.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
10
Note
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:
06/24/2010 11:45:34.167 CCM|H245Interface(3)::start_Transition, (H245Client session)
ip = (14.48.44.80), 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:
06/24/2010 11:45:34.181 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= request : terminalCapabilitySet
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:
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
11
{
capabilityTableEntryNumber 3,
capability receiveAudioCapability : g711Ulaw64k : 40
},
{
capabilityTableEntryNumber 4,
capability receiveAudioCapability : g711Alaw64k : 40
},
{
capabilityTableEntryNumber 5,
capability receiveAudioCapability : g729wAnnexB : 6
},
{
capabilityTableEntryNumber 6,
capability receiveAudioCapability : g729AnnexAwAnnexB : 6
},
{
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
12
capabilityTableEntryNumber 7,
capability receiveAudioCapability : g729 : 6
},
{
capabilityTableEntryNumber 8,
capability receiveAudioCapability : g729AnnexA : 6
},
{
capabilityTableEntryNumber 9,
capability receiveAndTransmitUserInputCapability : dtmf : NULL
G.711U/A @ up to 40 msec packetization (4 data samples per frame with each sample
taking 10msec)
G.729/A/B @ 6 data samples per frame (60 msec packetization, since each sample takes
10msec)
Note:
G.711 uses the msec packetization interval between RTP packets in the TCS
G.729 uses the number of 10msec data samples per RTP packet inside the TCS
If you understand that each sample is 10msec in length then the conversion between the
two is pretty simple.
The most common packetization is 20msec, or 2 voice samples per RTP packet.
If we look at the capabilities Inbound we see that all of the same capabilities are supported.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
13
On the publisher we tell the far end H.323 node we're using G.711 @ 20 msec
06/24/2010 11:45:34.246 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= request : openLogicalChannel :
{
forwardLogicalChannelNumber 1,
forwardLogicalChannelParameters
{
dataType audioData : g711Ulaw64k : 20,
On the subscriber we can go back to our TCP Handle and see that the SCCP calling phone
is told to Open a G.711 audio channel. The phone responds (StationInit) saying it will listen
on UDP port 24418.
06/24/2010 11:45:34.255 CCM|StationInit: (0000003) OpenReceiveChannelAck Status=0,
IpAddr=IpAddr.type:0 ipAddr:0x0e302ccf000000000000000000000000(14.48.44.207),
Port=24418, PartyID=33554435
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.
06/24/2010 11:45:34.257 CCM|H245ASN - TtPid=(1,100,16,3) -Outgoing -value
MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 1,
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
sessionID 1,
mediaChannel unicastAddress : iPAddress :
{
network '0E302CCF'H,
tsapIdentifier 24418
},
The incoming OpenLogicalChannelAck says the called party will be listening on 23362
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
14
Going back to the publisher server where the Calling SCCP phone is registered we see
CUCM instructing to send RTP to this new IP and port using the previously established
codec.
06/24/2010 11:45:34.260 CCM|StationD: (0000003) startMediaTransmission
conferenceID=42514739 passThruPartyID=33554435 remoteIpAddress=IpAddr.type:0
ipAddr:0x0e302ccc000000000000000000000000(14.48.44.204) remotePortNumber=23362
milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k)
Further on in the call the Called party presses Hold, Resume, and End Call. You can use all
of the previously discussed techniques to track through the behavior of these steps in detail.
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
is not warrantied by Cisco.
15