Professional Geekism

So in the last few days I’ve been playing around with a new Cisco 2811 and CallManager Express 4.0. One thing that’s bugged me hurrendously, ever since I began working with CME, is the generation of config files. When I first started my job, the phones were running from an Asterisk PBX which also hosted the TFTP server (naturally), and when we first began experimenting with CME 3.3 the TFTP server was kept in place upon Asterisk for simplicity and testing speed. However, we’re hoping to move all the phones to CME now, so the TFTP server had to be there too.

The problem is, according to any documentation that you read about creating individual configuration files for SCCP (or SIP) phones on CME, all you’ll be told is:

RouterX#(telephony-service) create cnf-files

And that’s it. But if you dig a little deeper, you’ll find that storing the cnf-files in the system: directory is the default (unbelivably stupid, as I’d imagine it just rapes your router’s RAM). So to remedy this:


RouterX#(telephony-service) cnf-files location [ flash: | tftp: | etc. ]
RouterX#(telephony-service) cnf-files perphone
RouterX#(telephony-service) create cnf-files


And then you should have something that works. But does it? Well, upon running create cnf-files, if you’ve changed it, the localised tone file for your network locale should have been generated and placed into flash, but there won’t be configuration files for each registered phone until you enter another command:


RouterX#(ephone) type [ 7960 | 7970 | etc. ]


And that must be applied for each and every ephone (note: CME allows you can use an ephone-template to achieve the same effect across multiple ephones) before an individual configuration file is generated. It makes sense now that I write this, as phones would inevitably require different configurations, but you try finding any relevence to this in Cisco’s documentation. I wonder how many voice engineers blindly set this value as good practice, not realising that it’s required for perphone configuration?

Meh, it keeps me occupied!

All said and done however, I have to say there is a lot more SIP functionality in this newer release, compared to the older 3.3 release I was originally using. Notably the support for SIP MWI is there (though I’m not sure if that might’ve not worked in 3.3, we might’ve just been doing something wrong) and it works a treat. Come to think of it, there’s been a huge improvement in SIP support across the board. This is more than likely because Cisco is moving to phones which support SIP natively (the SIP firmware for 7960‘s is very lacklustre if you wish to have any advanced features from your phones) and that is the challenge for the next few days.

Again, however, Cisco felt it necessary to keep SCCP and SIP phone configuration completely seperate in the IOS. Whilst those familiar with SCCP will feel quite at home in the ‘telephony-service’ sub-mode, you’ll notice when configuring CME to register SIP phones, all the commands are spread across a multitude of sub-menus that all begin with ‘voice’. No telephony-service in sight!

..Wouldn’t it have been easier to create a ‘sip-telephony-service’ sub-mode, Cisco? :/

On top of all this, I’m starting to think we might just need CME 4.1. 12.4 XJ releases are the only IOS I’ve heard of which carry this version, and it doesn’t appear to be on the feature selector – so finding this mythical beast might be a bit harder. Cisco do list a lot of SIP commands as being only supported in CME 4.1 though, so I guess we’ll have to wait and see where the limits are!