Having seen numerous problems pop-up on lists many times, I think I’m going to write a mini-guide on CallManager route patterns and route filters.
I’ve used filters since CM 3.0, and am quite familiar with them and their quirks.
Look for a guide to be posted here in the near future.
Well, now that I’ve written a basic app, I feel it’s time to get serious about this.
I’m seeking comments on what folks would like from an app that could forward phones (possibly extend to ringers).
Post a comment and let me know what you’d like to see.
Well, sorry to my 2 readers about having been gone so long. Some interesting things have happened.
I quit my job. (I won’t go into why)
I started my own business. I’ll say I enjoy being on my own. I can now truly serve customers they way I believe they need to be served. Anyone need help with IP telephony or networking? 
I wrote my first AXL/SOAP application. It allows you to forward or unforward any line on any CallManager based phone from the phone. Why is this unique? Well, since currently you can only forward or unforward the primary line on a phone, I thought it’d be nice to be able to do it from any line (I’ve seen zillions of customer requests on this one). I’ve zipped the app and the source code (and documentation) up and it can be found here (or check files and downloads):
Here are two of the most requested features I’ve seen for CallManager:
1. Hold ringback timer – this feature would make a call re-ring a phone if it’s been on hold X seconds – been requested since CM 3.0 came out.
2. Flash-hook – CME has this already – it would allow someone using an FXO line to get a call-waiting call – been requested for at least three years now.
Well, if there’s one thing I’ve learned, it’s that Cisco responds to customers pretty well. If you’re considering CallManager, or already have it, contact your local account team and tell them it’s urgent you have these features, or you’ll switch to Avaya which already has them
Looks like TAC has a DDTS, assigned (CSCsb47643), and is testing a fix right now.
I guess the good thing is that you can run with SSL off with no ill effects.
Who wants to be the first guinea pig for this ES?
Well, apparently Cisco has found a bug with DC Directory and SSL on 4.1.3 and 4.1.3SR1.
Disabling SSL on DC Directory is the short term workaround (see my prior note about CallManager and DC Directory).
You’ll know you’re hitting this bug if you see several thousand DC Directory or CTI access errors in the event logs. You also won’t be able to bring up a global directory listing in the CCMAdmin web page. This problem usually evidences itself about 20-40 minutes after a CallManager reboot.
A fix is supposed to be coming soon. Hoorah for engineering specials.
This has got to be the biggest joke of an application I’ve ever seen.
1. The server it goes on can’t have anything other than a physical C: drive.
2. If you install MS SQL in anything other than the default location, their app won’t install.
3. Their app process seems to go down without notice, frequently.
4. Their database replication seems to break frequently, along with their Tomcat install.
I don’t know how they got Cisco certified, but I find it irritating to say the least.
Their product does have good features, assuming you can keep it operational.
8/10/2005 Update –
One more bad thing – their product only waits by default 100ms for a response from the phone. Hardly ideal in a WAN environment. They patched it to wait 500ms and that seems to work better 
Well, just got done with one of the more arcane problems I’ve ever seen. Apparently with CM 4.1 and the addition of HTTPS for the web pages, DC Directory also went HTTPS. The problem I ran into was that for some reason, DC Directory stopped liking to deliver HTTPS requests. After 16 hours on the phone with Cisco TAC on a P1 case, someone suggested we turn HTTPS on DC Directory off. That fixed the problem of the directories not synching, and CTI stuff finally started working again.
I recently had numerous discussions with various technical folks about the use of the @ symbol in dial plans. Talk about your controvertial subjects.
The sides came down to one of two opinions.
(my side)
1. @ + a filter should be used wherever possible. The @ + filters process faster in the dialplan, and in my eyes, makes for easier reading. For instance, a typical dial plan will have 5 entries to cover 800 numbers for a given location. Using @ + a filter, I can make that one entry. Now when CM 3.0 first came out, the dialplan had a few issues with @, but that is no longer the case. Also, @ + filters properly categorize outbound calls to the PSTN (national, international etc.). This make life easier when dealing with a 4ess AT&T switch among other things.
(the other side)
2. Use discrete patterns because they are easier to understand. While this is true, discrete patterns when multiplied over multiple sites makes looking at route patterns quite tedious. You also don’t get the benefits of proper call marking so you need to do things like setting gateways to unknown/unknown etc.
Bottom line for me, I will continue to use @ + filters unless something better comes along.
Bad Behavior has blocked 127 access attempts in the last 7 days.