End User Creation
When a new end user is created, we've already talked about the fact that we can use a template to allow that new end user to inherit several pre-configured parameters, but there are some things that need to be unique to that user. For example, they need to have their own first and last name, they need a unique user id, we need to define an extension for that user and if we have more than one Cisco Unity Connection server, we need to specify where is the mailbox store going to reside. And although this isn't a requirement, we could set up an alternate extension for that user. We might set up a mobile phone for the user, a home phone for the user and keep in mind, if we don't associate an extension with the user, and that user from their extension calls in to Cisco Unity Connection, or somebody calls that user's phone and the phone forwards the calls to Cisco Unity Connection, if that extension is not associated with the user, then the calling party is going to hear the standard opening greeting instead of the customized end-user greeting.
Extensions and Call Forward Options
Here we have a couple of different examples of call flows coming in to a Cisco Unity Connection server. In the first example, we have a user calling in from the PSTN, and the default for all PSTN callers is to play the standard opening greeting.
However, if this phone on the PSTN has been predefined as an alternate extension for one of our end users, that could be recognized by Cisco Unity Connection, and this external caller, even though they are calling in from the PSTN, because they're calling from this predefined, maybe cell phone number or their home phone number, they could still be directed to their mailbox.
In the second example somebody is calling in to an internal extension but the internal extension is set to call-forward maybe because of a busy condition, maybe because of a no-answer condition but that internal phone is forwarding to the Cisco Unity Connection server.
And the Cisco Unity Connection server can look at that directory number of the phone that redirected the call, in other words the internal extension number, and direct the call to that mailbox. So the caller out of the PSTN is going to be prompted to leave a message for the appropriate user.
Voice Messaging with SRST and AAR
If we have IP phones at our branch office connecting over the IP WAN back to a centralized Cisco Communications Manager cluster and a centralized Cisco Unity Connection server, the calls are going to flow over the WAN if the WAN is available. But perhaps the WAN is down or it's not available. By not available I mean that a Call Admission Control mechanism such as locations has stepped in and said no more calls can be placed across the WAN because there's not sufficient bandwidth. In that case calls going from the branch office back to the headquarters might be routed over the PSTN.
Let's say that that phone at the branch office has an internal extension number of 2001 but now the call coming into the headquarters is coming in from the PSTN. It might come in with a caller ID of 14085552001. Is that going to match an end user in Cisco Unity Connection? Well it might if we have configured an alternate extension for that user. And this makes the point that we might want to create alternate extensions – in other words fully qualified PSTN numbers – for internal directory numbers at remote sites in case those remote site phones ever call into Cisco Unity Connection via the PSTN instead of the IP WAN.
When a user is been created, the administrator can decide whether or not to enable the self-enrollment feature for the voice mailbox of a new user. This initialization of a mailbox, which needs to be done before the mailbox can be used, that can be done either by the administrator or it can be done by the end-user when they first log on. They can be prompted to perhaps record their name, reset their Personal Identification Number and record a greeting. We could also allow the user to decide if they want their name listed in the Cisco Unity Connection directory, so they can be looked up if somebody is trying to find them in the corporate directory. And I mentioned that they could be prompted to record their name, but if they don't record their name based on the display name, the Cisco Unity Connection can automatically generate a name to play out. And if the user decides not to record a customized greeting, there is a default greeting that will be used by Cisco Unity Connection.
Private Distribution Lists
Earlier we talked about the concept of a distribution list. A system distribution list – that's usable by everybody in Cisco Unity Connection but we can also have users create private distribution lists. For example, let's say that we have a sales manager and this sales manager is responsible for three different teams – voice, security and network. If this manager needs to distribute news to each team, they have created three private distribution lists that could be used. One for voice, one for security and one for network. But if this manager needs to send a message to everyone at the same time, there is another private distribution list that's been created and it's called "All Lists". And this distribution list contains the three private distribution lists – voice, security, network. So now the sales manager could distribute a message to members of all groups just by using the "All Lists" distribution list.
When a message is left for a user, we might think of the notification to the user being in the form of a Message Waiting Indicator light on that phone. However, we can select additional notification devices, and these other notification devices include phones, pagers, e-mail addresses. We can have as many as three phone devices defined per user. And when a voicemail message is left, Cisco Unity Connection could for example call the mobile number that was defined for this user. And when that user gets this call to their mobile number, they're told about the new voice message and they are prompted to enter a PIN so they can listen to the message. We could configure Cisco Unity Connection to send an e-mail with that message to a specified e-mail address, and these notification devices, while they can be enabled in a user template, the user or the administrator needs to configure the specific addresses, the specific cell phone number, for example, to call when a message is left, or the specific e-mail address. So while these notification devices can be enabled within a user template, the user or the administrator, they need to specify the exact address.
User Creation Options
Let's consider how we can add end users into Cisco Unity Connection. We could add users manually, and this can be done fairly efficiently if we just have a few users to add, because we can leverage user templates, where we don't have to populate all the fields of an end user. Instead we can assign a user template to that end user and they suddenly inherit all of those parameters. We could add users in bulk by creating a comma-separated value file and use that to do a bulk import. We could import users from Microsoft Active Directory, as another example. And if we had users existing in a Cisco Unity System, not Cisco Unity Connection but a Cisco Unity, if we wanted to migrate those users to Cisco Unity Connection, we could use Cisco's Consolidated Object Backup and Restore Application Suite or COBRAS for short. This tool allows the migration from Cisco Unity to Cisco Unity Connection.
Mailbox Stores and Membership
When we create a voicemail box for an end user, that voice mailbox needs a message store – where are the messages going to be stored? And we need to specify for a user mailbox the message store that we're going to be using, and if we have more than one Unity Connection server, this message store database can be shared between both of these Cisco Unity Connection servers.
Message Aging Policy and Mailbox Quotas
As Cisco Unity Connection users accumulate voicemails overtime, their storage space could start to fill up. Users are limited to a certain quota, and if we want to prevent that user's mailbox from filling up, we could define aging rules. We could say that after so many days, messages that have been listened to can be moved to the deleted items folder. This feature is disabled by default, so it needs to be enabled if you want to use it. And then messages that are in that deleted items folder, they can be permanently deleted after a certain number of days, and here the default is 15 days. We can warn a user that their mailbox is reaching capacity, and by default, when a user's mailbox reaches 12mb, the mailbox quota warns the user that the mailbox is reaching capacity and it can prevent the user from sending anymore voicemail messages after the voice mailbox reaches a size of 13mb, and it can prevent the user from sending or receiving any more voice messages when the mailbox reaches 14mb. But again the default warning quota is 12mb and that's about 200 minutes of Cisco Call Recording with the G.729 codec, or if the G.711 is being used, that's about 25 minutes of recordings.