Cisco UCM 7.1 - how to use RTMT to create and view a trace

I would like to use Call Trace to help trouble shoot some intermittent one-way voice issues.  Can someone tell me how to use the Real Time Monitoring Tool to help analyze this kind of problem for say just one particular extension?
amigan_99Network EngineerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Most of the time one-way voice issues are routing problems between the endpoints.
Basically, the RTMT lets you download the log files/trace files from the call manager.
amigan_99Network EngineerAuthor Commented:
Well it seems RTMT is the only way to view call traces.  You choose what should be in the Servicability module for UCM.  But what's not clear to me is what of the several items that you CAN trace you should trace to try and figure out a problem like this.  If you choose everything or the wrong thing you can take down your UCM server.  So...I am asking what would be the minimal amount of traces that would be useful in analysing a problem such as one-way audio.  For example - what would show me just the details of the SCCP concersations?  Is there anything that would summarize the RTP? yada yada yada
José MéndezCommented:

I have never seen a CM node crash because of trace writing. In my experience this is very safe debugging to run, it is not like enabling a debug rtp packets on a voice gateway for example.

If what you have is a one way audio issue, what you can do is tell us more about the call flow, and we can determine together from which device you can take sniffer captures in order to determine where the network problem is.

In a trace file, you won't see any packet related information. You will see all signal and application analysis of whats happening, so may suddenly find a TCP Broken message or something like that, but I am 99% sure you won't see any errors because the devices are most likely sending RTP traffic to each other and their logical channels are open, it is just that somewhere else those packets are dropped. At this level, Callmanager is pretty much out of the picture. Unless you have 1 way audio from your software conference bridge.

Any ways, here is a link on how to configure traces:

Disable all PRI, H225, MGCP, SIP options if this only involves SCCP to SCCP calling. From then on enable the other protocols if gateways running a particular protocol are involved, but again, just for the sake of simplicity, it is most likely your head crashes when you see the trace file and try to find the call and the problem, than the Callmanager when it writes to file the debugging. Those are endless files of pure text, hex and binary codes,

You may also try the Device Based option and gather trace lines from just the devices involved, this way you dont see debugs from ALL devices.

Hope it helps.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
amigan_99Network EngineerAuthor Commented:
Excellent.  Thank you!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IP Telephony

From novice to tech pro — start learning today.