Can you hear me now? Tales from a Cisco voice instructor

October 31, 2009  2:27 AM

Removing Unused Directory Numbers in Cisco Communications Manager

Dave Bateman Dave Bateman Profile: Dave Bateman

I am not sure what it is like where you live but where I am the leaves are falling and the trees are becoming bare. It’s a nice time of the year with the color in the trees and the leaf covered yards. But, as the trees becoming bearer, I am able to see more clearly into my woods, and I see all of the clean up that is needed. It was nice during the summer when all the foliage covered it up but the work ahead of me is becoming a little too easy to see. I guess that is nature’s way of making sure things don’t go unnoticed for too long. This started me thinking about the things that tend to go unnoticed in Cisco Unified Communications Manager environments. Things that we really should clean up but tend to forget about because we don’t see them.

The one thing that quickly comes to mind is unused Directory Numbers (DNs). In the past it wasn’t so much a problem. When you deleted a phone, the directory number was removed as well. Things have changed. In the current releases of CM, when you delete a phone, the directory number is not removed from the database. This may not cause a problem but it is best to keep the database as clean as possible.

You are thinking to yourself, “no problem, I have never deleted a phone so I don’t have unused directory numbers.” Think again… have you ever place an exiting number into a partition? If you have, then you most likely have unused directory numbers. In the current versions of CM when you assign a partition to a directory number a new directory number is created within the selected partition. The result is that you have two directory numbers with the same number but in different partitions. Over the course of time you can end up with a number of unused directory numbers.

Now that you understand how unused directory numbers came to live in your system, it is time to remove them. The following steps show you how to find and delete these directory numbers. But first, a disclaimer… as with all CM administration, only qualified personnel should attempt this procedure. Remember that all changes are final so make certain that you really want to delete the DNs. In other words… proceed at your own risk.

Step 1) From within CM administrator select Call Routing>Route Plan Report (Figure 1)

CM Call Routing Menu

Figure 1

Step 2) Select Unassigned DN from the drop down list of the Find field (Fig 2) and click Find.

Route Plan Report Drop Down List

Figure 2

Step 3) You may check the box next to each DN that you want to remove and click Delete Selected or you may click Delete All Found Items to remove all the unassigned DNs (Figure 3).

Unassigned DN report

Figure 3

There you have it. Your system should now be free of unused DNs.

October 29, 2009  8:32 AM

Understanding the Various Cisco Unified Communications Manager Products

Dave Bateman Dave Bateman Profile: Dave Bateman

I got a call the other day from someone wanting to know the difference between Cisco Unified Communication Manger and Cisco Unified Communications Manger Business Edition. He believed he already knew but just want to make sure the Communications Manger Business Edition was the one that ran on a router (spoiler alert… it isn’t). Thus began a long and sometimes confusing conversation. During the conversation I recalled how I had just posted a blog to help clear up the confusion of various Unity platforms and thought perhaps there was a need for the same for the Cisco Unified Communication Manger platforms.

Cisco offers three call control products which contain “Communications Manager” in the name. In addition to the two mentioned above there is Communications Manager Express But before we talk about these products lets try to clear up the Cisco Call Manager vs. Cisco Communication Manger confusion. People often ask what the difference is… to paraphrase an old time TV show “the names have been change to confuse the masses.” Cisco changed the name of Call Manger to Communications Manager. Many people still refer to it as Call Manager. Most of the consultants I know that have been working with Communication Manager for a number of years are still calling it Call Manager. I think it has something to do with teaching an old dog new tricks.

Now that we have that cleared up lets take a look at Communications Manager and Communications Manager Business Edition . They are basically the same software. The main difference is that Communications Manager Business Edition does not support redundant servers which means that if the Communications Manager fails the devices have no backup Communications Manager to failover to. This does not mean that the system will be down. A Survivable Remote Site Telephony (SRST) device can be deployed which can service the devices until the Communications Manager is back up. Communications Manager Business Edition also has a limit of 500 user where Communications Manager can handle 7500 phones per server. At this point it seems like Communications Manager Business Edition doesn’t have much to offer. First you have to remember that Communications Manager Business Edition is a lower priced option for small and mid-size businesses and secondly it has something Communications Manager doesn’t. It includes an on box Unity Connections service. This means that one box handles call processing and voicemail services. Aside for these features Communications Manager and Communications Manager Business Edition are essentially the same. This means that the most of the feature offered are the same as well as administration interface.

Communications Manager Express is the third product that carries the Communications Manager name. It is very different from Communications Manager. The first thing you will notice when looking a Communications Manager Express device is that it is a router. Communications Manager Express runs on a router. It is very similar to an SRST device and is often used in place of SRST. It can support up to 350 phones but this number is dependent on the platform which it is running on. It runs on a number of routers such as the 2800, 3800, 2900 and 3900 series routers. It is possible to have this same router provide voicemail by installing a Unity Express module in it. Communications Manger Express is a good solution for small/branch offices.

So there you have it, the demystification of the Cisco communication Manager product in 600 words or less. I hope you find this helpful.

October 23, 2009  8:00 AM

First look at Google Wave

Dave Bateman Dave Bateman Profile: Dave Bateman

The Wave has begun, Google’s Wave, that is. As you may have heard, Google has launched the beta for a product that some are saying will replace email. Currently Google WaveIt is a closed beta and many are very anxious to see exactly what this thing is and how it will change the way they communicate. Well, I happen to be one of the fortunate to have received an invite to Google Wave. With much anticipation, I signed in and started to use the product. Remember, this is a communication platform and one thing about communication is that it normally involves more than one person. Since I did not know anyone else that was using Wave, there wasn’t a whole lot of communicating going on. As a matter of fact, it was pretty boring. I think it was about the same as it was for the first person in the city to get a telephone. It is very cool to say you have it but… that was about it.

I headed out to the web to see if I could find some other Wavers and see what they were saying. I found a way to view public waves. This caused my screen to fill with a number of conversations. Now I felt like that guy that just got a phone and picked up the receiver to hear a hundred conversations but not really a part of any of them. However, this did offer me a chance to see some of the features in action. So… what is my opinion of Wave? Deferred. Until I am able to use this application with a group of people that I live, work and play with, I don’t feel a fair conclusion can be made.

While this evaluation maybe a disappointment for some, it should also comfort those of you that have not received your invitation yet. While Wave has a lot of potential and it very well may change the way we communicate it, having it before anyone else you know doesn’t offer much more then bragging rights.

October 21, 2009  9:41 PM

Working from the Road

Dave Bateman Dave Bateman Profile: Dave Bateman

So here I sit 30,000 miles in the air again realizing just how much I dislike traveling. When I first started teaching, traveling was new and exciting. Nowadays it is about as exciting as sitting in traffic. Beyond the normal annoyances of travel, being away from the office just makes work harder. When you are in the office you have all the tools you need to do your job. Also, people that need to get a hold of you know how to. Don’t get me wrong – today’s advancements have made all of this a lot easier – but there is still nothing as efficient as doing work from the office.

One of the things that make working on the road easier is a single point for all communications. In an earlier post we discussed how Cisco’s Unity solution can offer this, but what about people that don’t have the fortune of using such a system? Don’t worry, there are alternatives for individuals.

I use is my Google Voice account. Let’s start with the bad news: it is still in closed beta so if you don’t have an account, you may have to wait awhile. There are other products that are similar such as 3jam. But these services are paid services whereas Google voice is free (at least for now). So what is Google voice? Its core feature is what I call single number reach. You are assigned a phone number. When someone dials that number, all of the phones you have configured ring. For instance, when someone dials my number, my office, cell and home phone all ring. The call is then routed to the phone that I answer. I can also setup rules that route calls based on who is calling. For instance, I may set it up so that if my family calls, it sends the call to my cell and home but not the office number. I can also create personalized greetings based on who is calling. Other features of the system allow me to transfers active calls to another phone; for example, I can transfer an active call from my cell phone to my office phone. If I am unable to take the call, all voicemails go to a single point. Gone are the days of checking my cell phone voicemail and then the home answering machine and then dial into the office to see if there are messages. I receive an email and an SMS message when I get a voicemail. The service includes the ability to transcribe the messages and include the text in the email and SMS messages. The transcription is still a bit sketchy at times, but often I can get the idea of what the message was about. There are other features, but these are the ones I use the most.

Another problem with working from the road is that there always seem to be that one file you left at home. This is where remote access comes in. Most of us have heard of GoToMyPC, and it is a good product. I, however, use Logmein. This service is very similar to GoToMyPC, but the base level service is free. I like free. They have paid plans that allow you to do things like remote printing and file transfer. I have little need for remote printing, and I just use my FTP server for the file transfers. It is a little bit more of a headache and if you think you will find yourself needing to transfer files, I would recommend going with one of the paid plans to make your life a little easier.

Life on the road isn’t always as exciting as some would think. As a matter of fact, it can be a real pain. It adds many new challenges to the job. Hopefully, this post will give you some ideas on how to make your life on the road a bit easier. Even if you never travel, I think some of these technologies can help make the day a little smoother.

October 17, 2009  9:15 PM

Exploring Cisco’s Unified Messaging Products (Part 2)

Dave Bateman Dave Bateman Profile: Dave Bateman

In the last post we started a discussion about Cisco’s Unity messaging product. The last post included a brief overview of the three messaging products with more detailed exploration of Unity. This post will focus on Unity Connections and Unity Express.

Unity Connections is sometimes thought to be a smaller version of Unity, but it is really a completely different product. For instance, it does not run on Windows but rather Linux and it has its own built-in message store so it does not require Exchange. While it has some features that are similar to Unity, it does not include all of Unity’s features. While many might expect that, they are often surprised to hear that it also contains features not found in Unity.

Unity Connections does not offer true unified messaging, but it does support integrated messaging. Unity Connections stores messages on-box in its built-in message store. Since it does not use an external message store, all types of messages (voice e-mail and faxes) are not stored in a single inbox; therefore, true unified messaging is not possible. But, by implementing integrated messaging you can have the next best thing. Integrated messaging allows Unity Connections to access to the email server and the email client to have access to the voicemail messages that it is storing. This allows users to access voice mail messages from their email client and allows users to access email messages from their phone.

Another feature of Unity connection that is not found within Unity is personal rules. A user can setup call screen rules. A typical rule might be something like, “if a call comes in after 5:00 and the caller is any of (fill in the blank) people, then send the call to my cell phone.” If configured, Unity Connection can also access you calendar and route calls based on your schedule. I am sure you are already thinking of other cool ways you could use this kind of feature.

Let’s take a look at Unity Express. Again, this is a completely separate product. Unlike the other two solutions, it is not installed on a server. This product runs on a router. Actually, it runs on a module within a router. For all intents and purposes, the module is a PC. It has all the makings of a PC, a CPU, storage device, memory, etc. As a matter of fact, it is also based on a Linux OS.

For the most part, Unity Express is the messaging solution selected for environments that are using Cisco Communications Manager Express. This is a popular solution for small or branch offices. While it was primarily built as a Voicemail system, features are continually being added that are turning this into a very feature-rich product. In addition to offering all of the features you would expect from a voicemail system, it also has a very solid auto attendant feature. The auto attendant function is really an Interactive Voice Response (IVR) system similar to that found in Cisco’s contact center solutions. This actually allows Unity express to provide functions that neither Unity nor Unity Express do.

So, which one is for you?… that depends. On what? A lot! The size of your deployment, the features you desire, the size of your budget and so on. I can’t tell you which is the best because that all depends on your needs. Hopefully this, at the least, helps you understand some of the basic differences in the products.

Below is a brief comparison table of the features found in each:


Unity Connections

Unity Express

Number of Users

15000 per server

7500 (10,000 VM only)



Windows based Server

Server (Linux)

Router module

Max active calls

200 per server

144 (244 in certain configurations)



Small/branch office

SMB – Enterprise





Voicemail via IMAP

Massage Store




For a more detailed comparison table check out Cisco Messaging Products: Feature Comparison.

October 15, 2009  8:07 PM

Exploring Cisco’s Unified Messaging Products (Part 1)

Dave Bateman Dave Bateman Profile: Dave Bateman

I often receive calls from individuals that have questions about their Unity system. The fist thing I ask them is “What Unity do you have?” This question is often met with moments of silence followed by “Cisco Unity?” At this point I know it’s going to be a while before we can get to the actual question. The reason for this confusion is that Cisco has three different voice messaging systems and each contains Unity in the name. To make things a bit more complicated, even though each is a different product, there are aspects in which they are very similar.

I thought I would use this and the next post to try to help you understand the three voice messaging products that Cisco offers. I will offer a brief description of each followed by a comparison table.

Let’s start with Unity. That’s the whole name… just Unity. While it can be used as a voicemail only solution, it is really a unified messaging solution. It runs on a Windows server and requires Exchange (or Dominos) as a message store. No messages are stored on the Unity server but rather in the message store. If you are using this for a voicemail only solution, Exchange may be loaded on the same server as Unity. This often leads people to believe that Unity stores the messages, but they are actually stored in Exchange.

So what do they mean when they say it’s a “unified messaging solution?” They idea is that it can offer the user a single inbox for various forms of messages. All of the user’s e-mail, voicemail and faxes can be stored in their Exchange inbox. This allows the user to retrieve their voice from their Outlook client as well as dialing in. A Text to Speech (TTS) feature is also available which allows a user to not only hear their voice mail when they dial in, but also listen to their emails. Using TTS, Unity “reads” the email to them. The quality of this feature is good; however, the practicality of having all of your email read to you is questionable. The faxing feature is a bit more limited. It requires that you have a compatible fax server installed and it only notifies you of faxes and allows you to forward them to another fax machine. It does not read the faxes to you over the phone.

In addition to Unity offering Unified messaging, it has the ability to function as a very feature-rich Auto-Attendant. This feature allows an administrator to configure Unity to route calls to the proper destination based on touch tone input from the caller.

One final feature that I would like to touch on is its queuing capabilities. This is a feature that is not discussed too much. Unity has the capability to allow callers to choose to be placed on hold instead on going to voicemail. The caller is then placed in a queue and is told how many callers are ahead of them. At pre-set time intervals, the caller is given the opportunity to be released from the queue and leave a message. Sounds like a pretty cool feature doesn’t it? Well it is, however, for every call that is in the queue, a voicemail port is being used. In short, what this means is if this feature is used on a system that is running close to capacity, it is possible that it could cause all ports to be consumed and cause Unity stop accepting incoming calls until ports are freed up.

In the next post I will discuss Unity Connection and Unity Express as well as offer a concise comparison table.

October 9, 2009  7:28 PM

Cisco Phone Registration Process

Dave Bateman Dave Bateman Profile: Dave Bateman

I made a phone call today. I know it doesn’t really sound like a big deal does it? Well, when you stop to think about it, everything that happens to make that call successful is really amazing. It’,s funny how people never stop to think about things like this and in all honesty, most people don’t need to worry about these things; that is our job.

A large part of making sure something works reliably or fixing it when it doesn’t work, is to understand what happens when it is working properly. I started this post planning on discussing call flow but before you can even setup a call you need a working phone. So the focus of today’s post will be the registration of a Cisco IP phone. We will discuss call flow in another article.

For the purposes of this article, we will assume the phone that is going to register is a Skinny Client Control Protocol (SCCP) device. The first thing that phone will need is power. There are two ways the phone will receive its power. The first is wall power. A power supply is plugged into the wall and attached to the phone. The second and, more common, is referred to as inline power or Power over Ethernet (PoE). There are two types of PoE that Cisco Phones use: Cisco pre-standard and 802.3af. The details on how each work will be the topic of a future article but for now understand the the phone negotiates with the switch to determine power requirements. Once the switch determines that the attached device is a PoE device, power is provided.

The following are the steps that a phone goes through once it has power:

1. The phone boots using its firmware.

2. The VLAN is determined. If a voice VLAN has been configured, the phone will learn that VLAN otherwise it will use the access VLAN.

3. If the phone is using DHCP, a DCHP request is sent. When the phone recieves the DHCP information, it will also receive the IP address of the TFTP server.

4. Once the phone learns the TFTP server address, it requests a configuration file. Since every phone has a unique configuration, the MAC address is used as part of the configuration file name.

5. If the phone has previously been configured within Communications Manager, a configuration file will exist in the TFTP server and will be sent to the phone.

Note: If the phone has not been configured in the Communication Manager, the phone will attempt to begin the auto-registration process. This will only be successful if auto-registration has been configured.

6. Once the phone has loaded its configuration file, it will complete the registration with Communications Manager.

You know the phone has registered when the correct extension number appears on it and you can receive dial tone.

When troubleshooting phone failure, a few common issues you may run into are:

  • Switch not configured to supply power.
  • Incorrect DHCP configuration.
  • Non-functioning  TFTP Server.
  • Phone not configured in that Communications Manager.
  • Improper setup of auto-registration.

Now that you know how the registration process should work, troubleshooting registration failures should be easier.

October 7, 2009  3:18 PM

Proper Planning for Calling Search Spaces and Partitions

Dave Bateman Dave Bateman Profile: Dave Bateman

We have all heard the saying, “There’s never time to do it right but there is always time to do it over.” This is as true for Unified Communication deployment as it is anything else. Today I was talking to a gentleman that had recently started a new job managing a Cisco Unified Communications system. He mentioned to me that one of his largest headaches is how the calling search spaces and partitions are organized. OK, maybe the word organized is being a bit generous. This made me start to think… how many times have I heard this?

Calling search spaces and partitions are arguably one of the most important concepts to master in a Cisco Unified Communications environment. While they can seem complicated at first, they are fairly simple when you get down to the core of what they are and how they work.

As you may know, calling search spaces and partitions are used to create class of services within CUCM. For those that aren’t familiar these concepts think of it this way: a partition is assigned to a number. In order for a device to reach that number, they must have the number’s partition listed in their calling search spaces. A simple analogy is that of locks and keys. The partition is the lock; the calling search space is the key chain. If you have the key to the lock, you can reach the destination. I am not going to go any further into the explanation at this point as this is not the focus of this post. The focus is that of proper planning and organization of calling search spaces and partitions.

Let’s start with planning. Since calling search spaces and partitions determine which numbers various devices can reach, you first need to determine what types of numbers your dial plan will consist of. A typical dial pan consists of at least five types of destination numbers. These are:

  1. Local Numbers
  2. Long Distance Numbers
  3. Toll Free Numbers
  4. Intra-Company Numbers
  5. Emergency Numbers

Your environment most likely will include other destinations so the first thing you need to do is take a long hard look at all of the types of numbers your dial plan will consist of.

Next you need to think about the type of users you have within your company and the type of calls they will need to make as part of their everyday job. It often helps to look at the different job roles within your company and group those roles together based on the type of calls each needs to make. Often many different roles will need to make the same types of calls. By grouping the roles together you can reduce the number of calling search spaces you need. For example, if you have sales, warranty and billing departments and they all make the same type of calls you can create one calling search spaces for all of them instead of one for each department.

Now, of course, you are documenting all of this while you are planning. I know the dreaded D word… I don’t know why but it seems like very few techies like to document anything. Trust me, when you get to the point of actually configuring this stuff, it will go much smoother if you have it down on paper.

Once you have a clear picture of the types of destination numbers your dial plan will require and the types of callers you have, you can start creating the partitions and calling search spaces. Create a partition for each type of destination and a calling search spaces for each type of caller. Remember to keep it as simple as you can while ensuring you have deployed the most effective and secure class of service possible.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: