|Visual Tour of Cisco CallManager 3.2, Part 1|
|Wednesday, 05 February 2003 11:26|
IntroductionIt has struck me recently that I've seen a lot of talk about Voice over IP (VoIP), and certainly read a lot of press about Cisco CallManager. But as far as actually taking a look at the product, well, that might take effort. You need to obtain an eval kit, or RTFM (Read The Fine Manual). Now, reading the manual isn't a terrible thing, Cisco did a nice job on the voice documentation. But it does sound like work, doesn't it? Because of this, I thought it might be of interest to make available some pictures of CallManager. These were taken with 3.2 since 3.3 wasn't quite out at the time. I imagine 3.3 will be quite popular, since it will scale to larger sizes (30,000 per large cluster)!
Chesapeake Netcraftsmen has been involved in some VoIP projects in the last year. Several of us have been taking the certification tests to get us IP Telephony Specialization certification, to make our voice skills more visible. We hope to have that status soon, by when this article appears if not sooner. My follow-on articles may talk about some other aspects of VoIP, since I've been immersed in it for a little while.
Implementing VoIP with CallManager is not just a matter of buy the phones and software, plug 'em in, and it works. Much as we all wish it were that simple. There's various forms of homework you want to do first. Among other things, you'll want to make sure you're buying the right equipment. And communicating capabilities clearly, not making any promises you won't be able to keep. Nothing scary here, but you do need to know what you're doing. And it's better to get details like bandwidth and QoS out of the way up front -- you fix it now, or you fix it while you're in the middle of deployment.
I've come at this from the Network Design and QoS side of things. I'm a big believer in a systems approach. There, the AUX VLAN capability of Cisco switches and phones seems like a big win -- simpler DHCP service, simpler QoS classification of VoIP traffic. Right now, that is more of a challenge with gear from other vendors. If you're deploying a lot of phones, you do not want to have to individually address them, or assign them to a VLAN, etc. -- unless you have a lot of time on your hands. Other vendors' IP phones can use separate switch ports to make this easier -- but then you've doubled the cost and FastEthernet port count. All those can affect the cost of a non-Cisco IP phone deployment.
For QoS, I personally really don't want to have to know or care which ports have phones plugged into them. I've seen too many sites where the cables tend to wander around (get plugged back into other ports). Tracking PC versus phone ports might be reasonable to do at the blade level. Having some server ports, some uplinks, and the rest PC/phone ports intermingled, that could be administratively time consuming. So when doing a QoS design, you've got to think about how VoIP might be implemented. And vice versa.
That's not to scare anybody off. It's just that there's a bunch of things to think about and plan, and having someone help with taking things in the right sequence can make a rollout go more smoothly, with fewer Maalox moments.
In summary, you don't just install CallManager and start configuring it, there's a very large amount of planning and work that precedes that. Having said that, we're going to jump in and look at CallManager, just as if you'd recently installed it.
Basic OrientationI always like to get my bearings in a new program by checking out the major menu headings. Cisco CallManager is web-based, but still does menus. The following series of images shows the menus superimposed on the initial splash screen. I thought about cropping the pictures to just show the menus, but I think it's useful to see the menus in relation to the background, it certainly helps me keep track of what's where.
The System menu provides access to the basic settings. More about this in a moment.
Route Plan is all about making calls, call routing. This is where you set up what digits call where. And Partitions, which allow control of who can call whom. For example, perhaps some employees are not allowed to make long distance calls. Or the CallManager is in a building with multiple tenants, who should not be able to directly call each others' extensions.
The Service menu allows configuration of some of the services provided by CallManager. For example, TFTP is used to download software and configurations to Cisco IP phones. WebAttendant lets you set up Pilot Points (virtual numbers that are never busy) and Hunt Groups (destination phones that calls are directed to). Media Resources include Conference bridges, Media Termination Points, Transcoder and groups of such resources. Also Music on Hold.
The Feature menu provides configuration for Call Park numbers, extra numbers a call can temporarily be transferred to, allowing someone else to pick up on a call on hold. Call Pickup is the other half of that. Cisco IP Phone Services allows access to web-based services from phones. Meet-Me is for setting up numbers for groups to dial to join a conference call (as compared to Ad Hoc conference calls, where you conference somebody else in). Voice Mail is configuration for the connection from CallManager to your voice mail system: numbers dialed for voice mail, etc.
The Device menu is how you add new devices. The list below the first entry (CTI Route Point, Gatekeeper, Gateway, Phone) gives an idea of what can be added. Voice Mail port is the other new device type that can be added. The idea here is that you configure a Cisco H.323 Gatekeeper or Gateway with IP address and basic connectivity, and then tell CallManager about it. CallManager can then centrally control dial plans and so on, which is certainly more attractive than maintaining a dial plan distributed across a large number of devices.
We're going to save some space at this point, by omitting screen captures of the User, Application, and Help menus. The User menu lets you work with CallManager users. Phones work without this, but some of the other features require a user directory. The Application menu lets you add Plug-Ins, and also access the Serviceability screens, for troubleshooting. Help is context sensitive and pretty useful, but also rather self-explanatory.
Configuring CallManagerNow that you have had your (very) basic orientation, let's take a quick look at what one might do when configuring CallManager for the first time.
There's a handy checklist at the URL
It suggests the following approach. See the above URL for more details and links to documentation. There are gentle chapters on each of the following topics.
In the rest of this article, we're going to look at some of the very basic setup tasks in the above list.
Establishing Some System-Level SettingsThe first thing you'll want to do is tell the system what name to go by, and what directory numbers (extensions) it manages for auto-registration. Note you will need to enable auto-registration if you want to use it (a security measure against "rogue phones").
The following is the form you fill in to create a group of CallManagers for use by phones. In the event the first choice isn't available, the phones will try the next. Up to 3 choices allowed.
Setting the Date/Time (think time zone) for a group of phones is about what you'd expect it to be. Regions are just named listings of what codecs to use for phones in the region or to other regions. Once you've got these, you can move on to the more exciting Device Pool configuration. See the following screen capture.
The Device Pool is just a group of phones with a name. They share Date/Time, Region, and the other items in the picture.
Adding DevicesOnce you've got that, you're got the basics ready to go. You can then specify device defaults, where you tell CallManager what Device Pool to use for each phone device type.
CallManager can then auto-register phones: assigning each new phone the next number in the range of numbers you've set up in the earlier CallManager system configuration (above). After auto-registration, you can change the device pools or phone settings as desired. Device -> Phone allows you to search for phones. See the following picture.
Clicking on an entry then allows you to configure it, as shown in the next picture.
You can use this form to add new phones manually, but that's not nearly as much fun!
Adding other types of devices is also fairly simple. For example, pre-configure and install an H.323 gateway, and you can then tell CallManager about it with the following screen.
The gateway type can be one of:
Some LinksThe Reference Design Guide listed below is a great way to get started finding out about Cisco CallManager. Highly recommended! Good stuff! Bravo Cisco! (I think you get the idea!)
No, I didn't see one posted for CallManager 3.3 yet. By the way, I haven't tested the non-Cisco Calculator site listed below, so no promises as to accuracy. The Cisco calculator does give some nice output, especially if you're evaluating your options.
ConclusionThat's our quick visual tour of Cisco CallManager, with a few comments on getting started. I hope it provided you with the feel of the product. The product has a pretty good set of menus and User Interface. The complexity comes in because of phone terminology (if you're not familiar with it). And in figuring out which of the many configuration items you need to fill in, and what some of the more cryptic ones mean. I hope you've come out of the above with a feeling of "I can find my way around", and perhaps "Yes, those screens pretty much made sense to me". Don't forget, when you do get stuck in CallManager, you can use the context-sensitive help. The explanations are pretty good for phone newbies.
I have a full set of screen captures, showing almost every screen in 3.2. I may post it on our web site if time permits, for those wishing a full tour of CallManager. I'm trying to get some annotation and basic amenities into it, but am squeezed on time, as usual. Some of them may well show up in next month's article. Stay tuned!