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 Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Very Strange Problem

Status
Not open for further replies.

jneiberger

Technical User
Jan 21, 2005
1,791
US
I've got three IP phones and a QSIG trunk up and running with CCM 4.1(3)SR3a. Earlier today, I was able to call any IP phone from my IP phone and I was also able to call TDM phones over the QSIG trunk. Then I went to a meeting for a while...

I come back and now the IP phones can't even call each other. I get a fast busy after the first two digits. Our dial plan is very small--we only have three patterns at the moment!

The IP phones are 1001, 1010, and 1093. I have route patterns for 1XXX, 8XXX, and 9.@ that point to a route list/group that points to the QSIG trunk. All of these devices are in the "Phones" partition and they all use the "Unrestricted" CSS which includes the Phones partition. All IP phones are registered to the same CCM.

I have no explanation. I've reset the phones, route lists, gateways...you name it. This is extremely weird.

What else can I check? Any ideas what might be wrong?
 
I've discovered that both of my subscribers are hosed somehow. If I re-register our IP phones to the publisher, all is well, but the dial plan is broken if I used either subscriber.

Interestingly, Dialed Number Analyzer reports the correct results because it runs on the publisher, but CCM traces show the calls failing because the subscribers don't seem to have valid copies of the dial plan. It's really weird. I'm opening up a TAC case right now.
 
Normally a subscriber will get its configuration directly from the Publisher. But if that link breaks, it should then default to the local SQL replication it has. I've had the SQL replication break several times before. You have to rebuilt it (there's a utility called DBHelper.exe on the Publisher that can do this for you). Also, restarting the CallManager service on the subscriber should reinitialize the link to the publisher, therefore no longer requiring it to look at the local SQL database.

Unless you check on it regularly, the SQL replication issues aren't noticed until the link to the Publisher breaks. Then you get all kinds of strange issues!
 
This isn't doing much to boost my confidence in this system. We've also been running into some weird MGCP issues.

I don't know if the links to the publisher are completely broken because I can make changes to our phones, which are registered to the subscribers, and they receive the updates. It only seems to be the dial plan that is broken.

I've checked the databases using DBLHelper and it reports that everything is fine, which I don't believe. I think they really are out of sync. I'm still waiting on a call back from a TAC engineer before I do anything because I want to leave them in the current state for troubleshooting purposes.
 
You can always run a Reinitialize to rebuild the subscriber databases just to be safe. There is a Cisco class you can take that covers troubleshooting the CallManager. I used to support Avaya PBXs and I never had to take a week long class on how to troubleshoot and fix it before, but with CallManager it's very useful! One of the class labs covers this very issue, which shows how often it can occur.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top