|Visual Tour of Cisco CallManager 3.2, Part 2|
|Wednesday, 05 March 2003 11:26|
IntroductionThis month we continue our visual tour of Cisco Call Manager, version 3.2. Yes, I know 3.3 is now available, but this is what was available to me when I took the screen shots. For consistency, we'll stick with Call Manager 3.2.
The previous article can be found at Visual Tour of Cisco CallManager 3.2, Part 1. I created PDF files of the full sets of screen captures that I had collected. Links to them can be found at Call Manager 3.2 Screen Captures Part 1 (2.37MB), Call Manager 3.2 Screen Captures Part 2 (1.45 MB), Call Manager 3.2 Screen Captures Part 3 (1.20 MB), and Call Manager 3.2 Screen Captures Part 4 (1.39 MB).
Remember, the overall objective here is a quick tour of Cisco Call Manager 3.2. I'll try to present clustered screen captures with enough explanation so you can sort of see how to drive Call Manager, and how it addresses things of interest. Any more complete explanations will be left for follow-on articles. This article is going to address some leftover items from the last article, and continue with showing how to adg and configure Call Manager to work with various kinds of devices.
About IP TelephonyHave you noticed all the Cisco ads on TV lately? They're trying to boost sales, of course. The message about the IP phones is cost savings. That's because there's a lot of "we're not taking on new networking projects" going on right now.
We have some consulting customers who very definitely agree that IP Telephony can reduce costs, or who like the strategic aspects, the flexibility of tying the phones into web applications. They're moving ahead with projects right now.
What are some of the other reasons sites are going to IP Telephony? For some, it's about replacement of aging PBX or getting out from under annual application licensing or support costs. For some, not having to deal with toning out voice lines for extension Moves/Adds/Changes is a big deal: reducing support costs and increasing flexibility. So is central admin of small remote sites, and not having to buy small PBX or key systems and maintain them remotely. And being able to have call agents working from home can be very attractive financially to companies. It can also tap into skilled but constrained parts of the labor pool, e.g. parents who want to be home when their children are out of school, or the disabled.
Once we've said all that, there also seems to be some inertia to deploying IP Telephony. One form of this is that staying with Nortel (or whatever the vendor) is much more comfortable for the telephony folks. I can't totally poke holes in this: IP telephony does involve new skills, new management tools, and change. If an organization isn't ready for that, then that's a factor to be dealt with. Furthermore, if one wants to add incrementally, for example on-network inter-site trunks, then adding cards to an existing PBX may seem less risky and less work than cutting over to full IP telephony. The reverse side is something I've also seen: cost-cutting in a smaller organization means you've lost the one telephony person. Or your external contractor can only come in once every two weeks to work on extensions and phone system issues. IT applications/server folks find Call Manager a whole lot more familiar than traditional PBX interfaces. Voice is just another service from that perspective.
What's your take on this? What do you feel about IP Telephony? Where do you think it's going? My email box welcomes your opinions!
And In Our Previous EpisodeThe previous article briefly discussed the main menus in Call Manager. We then went through my version of Cisco's list of things to do when setting up a new Call Manager installation. This lead us to some of the items in the System menu, where you set up the basic configuration of the Call Manager. Our emphasis there was on the Auto-Registration feature. We also saw that we could create different Device Pools, groups of phones with shared behaviors. We briefly looked at Device Defaults.
More About Auto RegistrationAfter re-reading last month's article, I realized maybe a little more should be said about Auto Registration.
The point to Auto Registration is that a new Cisco phone on a network needs to be assigned a phone number by Call Manager.
Upon bootup, Cisco phones obtain an IP address from a DHCP server. They also pick up their default gateway and TFTP server address that way. They then download their configuration from the TFTP server. After that, the phone registers with the Call Manager server.
Auto Registration means that the first time a phone comes up, it is assigned a phone number from the pool you specify. Call Manager can then track the phone number, the MAC address of the IP phone, and the phone's presently-assigned IP address. The real identifier for the phone is the MAC address, the IP address is temporary, coming from DHCP. So Call Manager is just tracking which phone number goes with which physical phone via MAC address, and the IP address comes in as temporary means of communication.
When registering a phone, the Call Manager Device Default specifies the Device Pool for each type of IP phone. The Device Pool then controls the Call Manager group or list the phone will use, the date/time for Call Detail Records, and the region or codec to use. The Device Defaults screen also assigns the Load Information (what firmware to run), and the Phone Template (what phone button template to use). For pictures of these screens, see last month's article. The next image shows what the Phone Template configuration screen looks like. It just matches features and labels to the buttons on the phone.
One approach you can use is to have phones Auto-Register. Have each user plug their phone in, then email or leave voice mail with their current phone number. You can then change the directory number to the assigned extension. This is simpler than trying in advance to record each phone MAC address, place it in the right cube, etc. The Bulk Administration tools in Call Manager provide another way to do bulk editing, e.g. in a spreadsheet. That's a lot faster than doing things one at a time via the Web interface.
The previous article showed the screen capture for adding a phone, so you can see the sort of information Call Manager tracks for each phone. It's a lot simpler to use default or template values!
Adding Other DevicesThere is one main screen, Device -> Add a New Device, from which you can select which type of device to add. The screen capture of this follows.
You can also add directly from the Device menu.
GatewaysThe previous article ended with a picture of the Add a New Gateway screen. Gateways come in two main flavors, H.323 or MGCP. Inter-Cluster Trunks (other Call Manager clusters via H.323) and Skinny or SGCP are the other flavors. This is specified as gateway type and "Device Protocol" in adding the gateway. For normal H.323 gateways, Device Protocol is H.225, the default. For other Call Managers, specify Inter-Cluster Trunk as protocol. You can't quite see Device Protocol in the following figure, since the gateway type pop-up menu partly covers the field.
Some devices can be used either way. MGCP means the gateway is fully controlled by Call Manager, with centralized dial plan, and call survivability during a Call Manager switchover. H.323 means the gateway is more capable on its own. H.323 may be required to support certain features, until Cisco adds MGCP support for some hardware.
With any gateway, the basic issue is configuring enough into the gateway so it can talk to Call Manager, or vice versa. There are non-IOS MGCP gateways, e.g. the WS-X6608-x1 card in a Cat 6000. Call Manager needs to be told their MAC addresses. For the Cisco IOS-based gateways, they need to have an IP address, they need to have MGCP enabled, and they need to know the IP address of the primary controlling Call Manager. H.323 gateways need to have an IP address assigned so Call Manager can communicate with them. In general, you'll want to be careful the Domain Name entered into Call Manager matches the hostname on the IOS device. If no DNS domain name is configured in the gateway, enter the hostname without a domain into Call Manager.
Once you've picked the type of voice gateway from this screen, you then get a protocol-specific configuration screen. The following is what the MGCP configuration screen looks like.
For an example of configuring an H.323 Gateway, see below .
You can similarly configure the other types of devices, shown in the Device menu or in the above screen capture (for Add a New Device). For example, the next image shows configuring an H.323 Gatekeeper. Since the Gatekeeper is stand-alone, independent of Call Manager, there isn't very much to configure!
Device ProfilesDevice -> Device Profile allows you to specify per-phone or per-group of phone behavior. The following images are the main and configuration screens for Device Profiles.
I then clicked on the link to Add a New User Device Profile. The next figure shows what came up.
FindAbove, we saw the Find screen for Device Profiles. Many of the menu choices in Call Manager allow you to search for all phones, gateways, gatekeepers, etc. that match some search criterion. This may take a little getting used to at first, since you pick a menu item expecting a list of gateways or whatevers, and instead you get a rather empty Find dialog box. Just remember: an empty search criterion brings up all entries.
By way of example, the next image shows the screen listing all gateways known to this copy of Call Manager. The initial Find screen didn't show the two entries after "Matching Records".
From this screen, you can click on any gateway entry to view or alter its configuration. I clicked on 10.2.1.1 and the next image shows what came up.
Where Are We?At this point, we've seen how to do basic Call Manager setup and configuration (the first article). We've also seen more details of how you tell Call Manager about the various devices it controls (this article). Remaining major topics we have yet to tour:
ConclusionFor good links to read about Call Manager, I'm going to refer you to the links in the previous article .
Relevant Cisco training links:
The CVOICE course gets you telephony basics, also some idea of the router capabilities and configurations. That's a good place to start.I have mixed feelings about the EVODD course. It does cover design basics nicely. On the other hand, reading the documentation, Call Manager reference design manual, and online material might be a quite reasonable and cost-effective alternative.
For really learning to drive Call Manager, there's nothing like the hands-on experience in the CIPT course, listed above. Recommended! Any later articles I write will only scratch the surface of what you can do with this product.
I've left out the Cisco Unity courses, since our focus here is basic IP Telephony. Unity is pretty nifty, but is an add-on application from this point of view.
By the way, we, Chesapeake Netcraftsmen, do offer our customers a Network Health Check service. The idea is to quickly evaluate your network, surface any major problems, and identify the next steps in moving the network along the path to the appropriate levels of reliability and service. That can include strategic advice, as in "you might want to think about doing this next". That can be particularly helpful when you know your network isn't as stable as you like, but don't know where to begin. The intent is to help move your network to the next level of performance or service, allowing your company to obtain more value for the money already invested in the network. We can also help with planning for QoS deployment, or evaluating IP Telephony readiness and options. We can certainly also do full design, implementation, or evaulation projects, but we've found that the shorter-term Health Checks provide solid value and low risk to our customers.