- Introduction:
- Things about the series
- Tools I use
- Things to understand
- Before looking at the logs
- Good things to review
- Things I will discuss in this series:
-------------
Please rate helpful content (i.e. videos, documents, comments) so quality content shows at the top of people's search results. Also, please select the correct answer(s) if any comment(s) answers your question otherwise the question remains on the support forums as unanswered.
-------------
Introduction:
Everyone has some overlap in the way they read traces; however, there are tips and tricks that each person can bring to the table. With that being said, this series displays my way of reading the traces.
Things about the series
This is not meant to be all inclusive. This is meant to show some of the things I do when reading CallManager service traces. The goal of this is to help people be more comfortable with looking at traces. Then they can practice on their own, or try to find things on their own when they have an issue.
I will not cover much with SCCP phones.
This will be geared more towards the interleaved SDI/SDL traces (version 9 and higher... if you are on version 8, there will be a lot that still applies; however, you should think about upgrading)
Tools I use
This 2.5 minute video discusses how I setup extract now.
translator X (only when the occasional need arises, and this should be used once you are a little more familiar with traces)
Call signaling diagrams
Version 10 SRND for media resources
Things to understand
Every call has a few things in common:
1: The call is extended to CUCM
2: CUCM will do digit analysis
3: If a pattern or DN is matched, CUCM will try to select a device (trunk, gateway, route point, phone (via Directory Number and partition combination), etc...)
4: If CUCM successfully selects a device, the call will be extended to the device
You also want to understand a little about the processes.
The process listed on the right is talking to the process listed on the left. Here we see the SIPStationCdfc process talking to the SIPCdpc process.
|SIPCdpc(3,100,83,3) |SIPStationCdfc(3,100,75,2)
There are two major types of processes in the SDL device layer:
1: Edge Processes (Talk with the outside world from the perspective of CUCM)
2: Control Processes (Internal processes that control the devices)
These are 5 of the major edge processes.
- SipHandler
- SIP phones and SIP Trunks will communicate with the CUCM using the SipHandler internal process
- SipHandler creates an intermediate process named SipStationInit (there is only one per CUCM),
- SipStationInit creates SipStationD instances for each SIP Phones.
- For every SIP Trunk SipHandler will create an instance of SipD
- StationInit
- Communicates with all the Skinny devices: Phones, Voicemail ports, Media Resources (CFBs, XCDRs, Annunciators, MOD, etc...)
- StationInit creates one StationD per Skinny device.
- H225Handler
- Will Communicate with all the H323 Gateways and Trunks that point to the CUCM
- StationHandler creates an instance of H225D per H323 device
- MgcpHandler
- Will talk to all of the MGCP gateways regardless of protocol (T1 CAS/CCS, PRI, FXS, FXO, etc...)
- For each T1 CAS, FXS, or FXO MgcpHandler will create an instance of MgcpTrunkD to manage the port
- MgcpBhHandler
- Will only talk to the MGCP Pri interfaces because MgcpBhHandler processes the ISDN backhauled messages from the gateway as these messages are terminated at the CUCM. When the ISDN messages hit the GW, the GW convirts the Time Division Multiplexing (TDM) messages to IP Packets (i.e. the legacy voice setup message will be put into a TCP packet which will be put into an IP packet), the gateway will open a TCP socket with CUCM, the IP packet will be sent to CUCM, CUCM will read the message off the socket when it terminates at the CUCM, CUCM will then reply with an MGCPPri call proceeding message by putting the message inside a TCP packet which is put into an IP packet, the IP packet will be sent to the gateway using the TCP socket, the GW will then translate the message into TDM and send it to the PSTN
- The regular MGCP messages like CRCX, MDCX, etc. go to the MgcpHandler
- For each Pri interface MgcpBhHandler will create an instance of MgcpPn9D
There are a few things you will want to find to help you better follow the call:
1: The CIs (these are identifiers that are unique to a call, but more specifically they are unique to a call leg within the call)
2: The CDCCs (Call Dependent Call Control process)
3: Call dependent processes (processes created specifically for the call you are analyzing). These are not as important as knowing the CIs and CDCCs; however, they can be very useful at times.
Here are some of the call dependent processes:
Cdcc
LineCdpc
SIPStationCdfc
SIPCdpc
SIPInterface
Forwarding
PickupMonitoring
MatrixControl
MediaExchange
MediaManager
Transferring
Recording
RouteListCdrc
HuntListCdrc
QueueControlCdrc
CallPark
H225Cdpc
MGCPpn9cuser
MediaResourceCdpc
H245Interface
AgenaInterface
MGCPInterface
When the processes are created it looks similar to this (I modified it for ease of viewing).
Before looking at the logs
There are a few things you want to know before reviewing the traces. These will help find the right call and better understand what the sequence of events are:
The time stamp of the call
The calling Number
The called number
The call flow
What happened on the call (transfer, pauses, sounds, no audio, etc...)
It is not exactly necessary; however, it is very helpful if you know the mac addresses and IP addresses of the phones and the IP addresses of servers and routers that may be in the call flow. The output of "show network cluster" gets the IP addresses and host names of the CUCM servers in the cluster (along with other helpful information that doesn't directly relate to call routing). This information is what helps create a more detailed call flow which is something I talk about here: How To Identify A Call Flow In CUCM
Good things to review
Troubleshooting IP Telephony book
The links on the support forums that deal with reading traces
How to gather traces from the CLI
If there is a router in the call flow: How to debug the gateway
CUCM Troubleshooting Methods, SIP Concepts and Troubleshooting Tools
Things I will discuss in this series:
How to gather traces from CUCM:
Make sure they are detailed, select all nodes, relative range if you can reproduce the issue, relative range if you don't know how to reproduce the issue but you are getting an RTMT alert about an issue, no issue reported by users
Getting the most out of this (2.5 minute video)
Phone to phone same node (SCCP - the only one I will go out of my way to make with Skinny phones)
Phone to phone same node (SIP - most the rest will be made using SIP phones)
Phone to phone, call transfer to another phone
Inbound call from H.323 gateway to phone
Inbound call From MGCP gateway to phone
The list below are place holders for future videos:
Call Recording
Call Pickup
Hunt Pilot
MWI SCCP
MWI SIP
Mobile Connect (SNR)
-------------
Please rate helpful content (i.e. videos, documents, comments) so quality content shows at the top of people's search results. Also, please select the correct answer(s) if any comment(s) answers your question otherwise the question remains on the support forums as unanswered.
-------------
