Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Better tool than built-in Cisco CDR?

Status
Not open for further replies.

dudecrush

IS-IT--Management
Apr 2, 2007
468
US
I'm a Cisco newbie, running Call Manager V 9.1 I've been asked to trace a dropped conference call and find out why it dropped. I used the Cisco CDR tool (CDR > Search). I've done it by device and by call termination. Device shows me that the calls where made, but not much more. The Call termination had me all excited because it had the "Conference Drop" call termination cause. Unforunately, it returns an error code of: 10021 - There are no matching records. (B.S. there are no matching records...)

Am I not using this tool correctly, or is it the POS I think it is? If it's not good, what 3rd party tools do you know of out there do a better job? I've heard that in Cisco 10.x releases, the CDR tool is much better.

Any opinions would be great.

Thanks!
 
CDR, call detailed records, is not a call tracing/troubleshooting tool. It is a call recording tool, what was called SMDR in the legacy PBX world.
If you want to trace a call and find out when and possibly why it disconnected, you need to run SDI/SDL traces for the range of time the call took place and look through them. Since you are on version 9 you will use the RTMT tool to collect traces.
What type of conference was it? Internal to cisco initiated via the conference key or a third party that you call in and join?
 
whykap - Thanks for the info. After I posted the message, I ran across the RTMT install after I posted this message. I'm new here, so I need to get permission to install the RTMT.

The call itself was internal to Cisco - no conferencing bridges were used. Internal extension 1803 called internal extension 8202, then 1803 attempted to conference a cell phone. The call to 8202 dropped, but the call to the cell phone worked just fine. I tried to duplicate the problem by calling another extension from my desk phone, then conferencing in my cell. It worked just fine.

Just trying to get to the bottom of this; Sounds like the best way is to use the RTMT.

If I install the RTMT, can it search the current database for that call drop information, or does it start from nothing and build it's own database?
 
User error? Just saying......
Especially if you can't duplicate it from the same phone calling the same numbers.
 
Probably a user error, but this is a high-maintenance user (VIP)

What do you know about installing RTMT?
1) Service affecting? (probably not)
2) Require a license?
3) Once installed, does it use it's own database or add data to the current database?
4) Install time?
5) Other "gotcha's" / caveats?
 
Youll have no issues installing RTMT. It just connects to CUCM/CUC/etc.

Certifications:
A+
Network+
CCENT
CCNA Voice
 
OK - More information. As a test, the user called me today and then attempted a conference to a cell phone. The conference didn't complete. Is there a setting on the phone or on the number itself that would keep the call from conferencing? If this helps, the user was calling from a bridged appearance at a different location. When I opened up this ticket, he was calling from HQ. That makes me think it's a phone or DN setting.
 
What happened when he tried to conference the person in?

Certifications:
A+
Network+
CCENT
CCNA Voice
 
As a test you could change the devilce pool, calling search space on the phone and set the partition on the DN to match the partition you're using. Complete another test conference with the user. What happens when the conference fails? Does it fail when dialing the cell number or when he hits conference again to bring the calls together?

~Han

The great use of life is to spend it for something that outlasts it. ~William James
 
Well - I finally have a answer as to why conference calls were dropping. About a month prior to my employment here, this issue came up. To fix, one of the network admins upgraded the iOS on voice-gateway #2, and moved all the cables from voice-gateway #1 to #2. Unfortunately, the 2nd Gateway wasn't added in Call Manager in the Media Resource Group. Everything kept trying to use GW #1 and was failing. Once I added GW#2 to the MRG and removed #1, everything worked slick.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top