Cisco Unity Express Design Guide

Chapter 5: Voice Mail Design Considerations

This chapter focuses on Cisco Unity Express voice mail design considerations, including space allocation to mailboxes, setting up (and using) different types of mailboxes, and setting up a message waiting indictor (MWI). Some AA features are also described that can help you design your voice mail system. For an in-depth discussion specific to the Cisco Unity Express AA features, see "Chapter 4: Auto-Attendant Design Considerations."

The Cisco Unity Express voice mail design considerations addressed in this chapter are presented in the following sections:

•Voice Mail Pilot Number Operation

•Calling into Voice Mail to Retrieve Messages

•Mailbox Operation

•MWI Operation

•Leaving a Message After Business Hours Only

•Distribution Lists

•Broadcast Messaging

•Comparison of "Everyone" Distribution List and Broadcast Message

•Voice Mail Number Handling

•Voice Mail Operator

•AVT Operation for Voice Mail

•Voice Mail Deployment Models

•Best Practices

Voice Mail Pilot Number Operation

The Cisco Unity Express voice mail application has a single entry point number (pilot number) for all types of calls. A caller can presented with a mailbox login prompt or with a greeting to leave a message, depending on how the call is directed to the voice mail pilot number. Specifically, it depends on the content of the "redirected number" field in the call setup message that enters Cisco Unity Express.

If the "last redirected number" field is present (which means the call terminated to an extension first and was subsequently redirected to the voice mail pilot via a call forward feature), the following rules are applied:

•If the extension in the "last redirected number" field has a mailbox, Cisco Unity Express assumes that it is a call-forward from the subscriber's phone and the mailbox's greeting is played to the caller.

•If the extension in the "last redirected number" field has no mailbox, then the call is transferred to the "Voice Mail Operator" extension after an announcement. The default setting for the "Voice Mail Operator" is the AA pilot number, but you can change this to any extension (use the Voice Mail > Call Handling GUI window).

If the "last redirected number" field is not present (which means the caller dialed the voice mail pilot number directly), then Cisco Unity Express assumes that the subscriber is calling into voice mail to retrieve messages and the subscriber login prompt is played and the following rules are applied:

•If the caller (the "calling number" field) has a mailbox on the system, then the caller is prompted to enter a PIN.

•If the caller (the "calling number" field) does not have a mailbox on the system, then the caller is prompted for an ID (extension) and a PIN.

Cisco Unity Express cannot be configured to enter a mailbox based on the "first redirected number" because this is not currently (up to and including Cisco Unity Express 2.1) a field provided to Cisco Unity Express by the associated call agent (Cisco CME or Cisco CallManager). If a call is redirected to Cisco Unity Express, the mailbox associated with the "last redirected number" field is entered.

Calling into Voice Mail to Retrieve Messages

Subscribers can call the voice mail pilot number to check messages from their desks by pressing the Messages button on their IP phones. How this button is programmed (mapped) with the voice mail pilot number depends on which call agent you are using.

•Cisco CallManager—The number dialed by pressing the Messages button is controlled by a system administrator programming the phone so that a Voice Mail Profile is attached to the Directory Number (extension) configuration for the phone. The Voice Mail Profile contains the pilot number called when the Messages button is pressed on the IP phone. This pilot number must be associated with a route point registered with Cisco CallManager by Cisco Unity Express.

•Cisco CME—The following example shows the voice-mail CLI setting within the telephony-services command configuration that controls the number automatically dialed (3105 in this example) when a subscriber presses the Messages button on an IP phone controlled by Cisco CME.

The following configuration example illustrates the voice mail pilot number setting for Cisco CME:

telephony-service

 load 7960-7940 P00305000300

 max-ephones 100

 max-dn 300

.

.

.

voicemail 3105

 max-conferences 8

•Cisco SRST—Cisco SRST uses similar CLI commands as that shown for Cisco CME in the preceding example, except that the voicemail command is a setting within the call-manager-fallback configuration.

If a subscriber calls to the voice mail pilot number from an assigned IP phone, the calling number field in the call setup matches the subscriber's assigned mailbox and Cisco Unity Express prompts only for a PIN to log in. If a subscriber calls from someone else's IP phone, Cisco Unity Express assumes the subscriber wants to log in to the mailbox that matches that phone's extension (provided a mailbox exists for the extension) and also presents just the PIN prompt. The subscriber can now press # on the phone keypad to force Cisco Unity Express to present the User ID prompt to permit logging in to a specific mailbox from any phone.

You should also consider how your employees call into voice mail from PSTN locations to retrieve messages. You can have either a separate (dedicated) PSTN number for this specific purpose (which is routed to the voice mail pilot number), or these calls can use your main business number (and therefore terminate on the AA). If you choose to terminate calls at the AA, you must redirect calls to voice mail via the AA menu by dialing the voice mail pilot number as an extension.

If a subscriber wants to call in to check voice mail from any off-net location (such as home or a cell phone) and to be presented only with the PIN login menu (and not the User ID followed by PIN login menu), then Cisco Unity Express must recognize the caller ID delivered with the PSTN call and be able to map that to a mailbox on the system. This call flow requires the following:

•The PSTN must deliver caller ID to your location.

•You must associate a secondary number (the PSTN phone number) with the mailbox in addition to the extension.

You can associate a secondary number with a Cisco Unity Express mailbox by setting the Primary E.164 Number field in the user's profile to this number as shown in Figure 21.

Figure 21 Associating a Secondary Number with a Mailbox

Note The arrangement illustrated in Figure 21 is not the typical use of the Primary E.164 Number field in the user profile. Typically this field is used to map the subscriber's DID number to a mailbox so that PSTN calls to the extension correctly forward to voice mail. In the example configuration in Figure 21, User1 U1's extension is 1005; User1's DID number is x44y551005; and User1 U1's cell phone number is x33y551212. You can use the Primary E.164 Number to either route DID calls (x44y551005) to User1 U1's mailbox, or to allow User1 U1 to call in to retrieve voice mail and bypass the mailbox User ID prompt by setting this field to his cell phone number (x33y551212). You cannot do both. If it is more important to have the DID number mapped, then calling in from User1 U1's cell phone will require stepping through both the User ID and the PIN prompts. If it is more important to bypass the User ID prompt, then the DID number must be changed to the extension (converting x44y551005 into 1005) by the PSTN voice gateway, Cisco CME, or Cisco CallManager digit manipulation features before the call enters Cisco Unity Express and is matched to a mailbox.

Mailbox Operation

This section addresses various aspects of voice mailbox operation and configuration that allow you to customize Cisco Unity Express's features to the best advantage for your business, and to integrate Cisco Unity Express mailboxes with the rest of your network. Cisco Unity Express offers all the basic expected features of a voice mail system, and these are not described individually. Please refer to Cisco Unity Express feature documentation for descriptions of supported features and their operation.

The following mailbox operational considerations are presented in this section:

•Associating Multiple Extensions with a Mailbox

•Phone Types Supporting Mailbox Implementation

•Users and Subscribers

•Personal Mailboxes

•General Delivery Mailboxes

•Number of GDMs and Personal Mailboxes

•Mailbox License Control

•Voice Mail Customization

•Voice Mail Language Customization

•Fax Calls

•Caller ID in Message Header

•Dial-by-Name in Message Send

•Digit Manipulation

•"Announcement Only" Mailbox

•Disabled Mailboxes

•Orphaned Mailboxes

•Mailbox Space Allocation

•Spoken Names

•Spoken Name Confirmation

•Spoken Name Delivery

•Outcall Notification

•Directories

Associating Multiple Extensions with a Mailbox

Up to two numbers can be associated with a mailbox:

•Primary extension—For a Cisco CME system, this is an extension configured on the system and exists as an ephone-dn command statement in the Cisco CME configuration. For a Cisco CallManager system, this is a free-form field and no cross-checking is done between Cisco Unity Express and Cisco CallManager to ensure that it matches a valid extension on Cisco CallManager (although this is the intended use of the field).

• Primary E.164 number—This is any secondary number that you intend to associate with the mailbox. Its primary use is to map the subscriber's DID number to the mailbox so that calls arriving from the PSTN can enter the mailbox unaltered. As described in the "Calling into Voice Mail to Retrieve Messages" section, it can also be used for voice mail retrieval functionality; DID numbers can go through digit manipulation to match the extension before entering the Cisco Unity Express mailbox.

When a call arrives at Cisco Unity Express, the "called" (for leaving a message) or "calling" (for retrieving voice mail) number is compared with these two fields. If either one of them matches, then the mailbox is recognized at the destination for this call.

If you intend to map more than two numbers to a mailbox, you must use the digit manipulation features on the router, Cisco CME, or Cisco CallManager to adjust the number to one of the Primary Extension and Primary E.164 Number fields before the call reaches Cisco Unity Express.

Phone Types Supporting Mailbox Implementation

Cisco Unity Express 2.1 provides mailboxes for SCCP-controlled IP phones managed by either Cisco CME or Cisco CallManager.

Voice mail for analog phones is not supported when the analog phone is connected behind H.323, Media Gateway Control Protocol (MGCP), or SIP-controlled voice-gateway foreign exchange station (FXS) ports. With these three gateway configurations, there is no direct way to complete the following tasks:

•Forward (busy or no-answer) a ringing call on an FXS port to voice mail without the help of a call agent or some other call routing intelligence—such as a Tool Command Language (TCL) script.

•Enable MWI for the analog phone.

Voice mail for analog phones connected behind SCCP-controlled voice gateway FXS ports is supported in Cisco Unity Express 2.1, because these ports appear as IP phones to the system. Such ports use stutter dial tone for MWI (created by the FXS voice gateway, not directly by Cisco Unity Express).

Voice mail for general-purpose SIP phones is not supported in Cisco Unity Express 2.1, due to the lack of RFC 2833 DTMF relay support in Cisco Unity Express. Calls to SIP phones can be deflected to a Cisco Unity Express system, and direct SIP calls can be made to a Cisco Unity Express AA or voice mail pilot number. The caller cannot interact with Cisco Unity Express via DTMF, so there is no way for the subscriber to retrieve the message or a caller to interact with the AA menus.

Users and Subscribers

A mailbox belongs to a user (or subscriber). A mailbox cannot be defined without first defining a user profile. The user profile contains the extension number, the secondary phone number (Primary E.164 Number field), and the PIN used for mailbox login. A mailbox is associated with the user profile, which in turn is associated with an extension. There is no direct linkage between the mailbox and the extension. Therefore, the mailbox profile, shown in Figure 22, shows no extension number or PIN fields (these are contained in the associated user profile).

Figure 22 Personal Mailbox Profile

Note If a user profile is deleted from the system via the GUI, the associated mailbox is automatically also deleted. If the user profile is deleted from the CLI, the mailbox is not automatically deleted and must be deleted manually.

Although a mailbox cannot exist without a user profile, a user profile can exist without a mailbox. The Cisco Unity Express license installed on your system directly controls the number of mailboxes you can define. It indirectly also controls the number of users you can define. The number of users allowed is always larger than the number of mailboxes. In releases up to and including Cisco Unity Express 2.1 the number of users allowed is twice the number of mailboxes defined by the license installed on the system.

You might choose to define users that do not have mailboxes for the following reasons:

•To define system administrator accounts that do not need a mailbox or may not belong to the same organization. For example, the administrator might be an outsourced company that is not part of the end-user community served by the voice mail system.

•To define administrators (that do not require voice mail themselves) to manage group membership and distribution lists.

•To define usernames that show up in the AA dial-by-name feature but do not require voice mail.

Personal Mailboxes

A personal mailbox is typically used by one person and belongs to an individual subscriber. This person is typically the only one who knows the PIN of the mailbox and logs in to the mailbox to retrieve messages. As explained in the "Users and Subscribers" section, the user profile associated with the mailbox determines the extension, user ID, and PIN used for access to a personal mailbox. A personal mailbox can be associated only with a single User ID.

Multiple people can log in to a personal mailbox only if the same User ID and PIN combination is known to both of them, which is normally considered a security violation.

General Delivery Mailboxes

A general delivery mailbox (GDM) is typically used by multiple people (a shared mailbox) who work in the same functional group, such as the help desk or customer service. All members of the group can log in to the GDM (only one person can be logged in at any one time) and retrieve messages.

GDM Access and Login

A GDM is associated with a group profile in the Cisco Unity Express configuration and does not have a login user ID or a PIN associated. Members of the group gain access to the GDM by logging into their personal mailboxes first (where individual User ID and PIN authentication checks are done) and then following a voice menu choice that allows them to access specific group mailboxes—for groups to which they belong. Employees who are not members of the group cannot access the GDM.

An Example of GDM Use

An example of a typical use of a GDM is for a group of people who work in customer service. Callers do not generally know the individual's names, nor do they require this information. Although each member of the customer service group has a personal mailbox, the GDM is a collective mailbox for customer service queries where all staff members check for nonpersonal messages and any member can respond, depending on who is available or on shift.

Figure 23, Figure 24, and Figure 25 show such a configuration. The members and owners of the customer service group are defined in Figure 23. The GDM profile is shown in Figure 24. The group profile for the GDM is show in Figure 25.

Figure 23 Group Members and Owners

Figure 24 GDM Profile

Figure 25 Group Profile

The extension (1050) associated with customer service—and with the group definition (customer-service)—is shown in the Group Profile in Figure 25. This is an extension different from the individual extensions of the members of the group and would normally appear as a secondary button appearance on their phones.

MWI for GDMs

Any phone with a button appearance of the extension associated with the group receives MWI for message content in the GDM. This configuration is shown in Figure 26. The customer-service GDM extension (1050) appears on button 2 of group member User2 U2's phone (extension 1001).

Figure 26 GDM Extension Appearance for MWI

Further information on MWI for GDMs is given in the "MWI Operation" section.

Number of GDMs and Personal Mailboxes

GDMs have no direct login, therefore a GDM can not generally be leveraged to increase the number of personal mailboxes on the system. All GDM members also require a personal mailbox definition because the login authentication happens via the personal mailbox (User ID and PIN). However, with Cisco Unity Express 2.1—where the number of personal mailboxes and GDMs becomes flexible (as long as the total number of mailboxes for the license is not exceeded)—different types of applications become possible.

One example illustrating the tradeoffs between GDMs and personal mailboxes is to define all mailboxes as personal mailboxes and define no GDMs. In this configuration, you have effectively leveraged your GDM allocation as personal mailboxes instead. If you have no need for GDMs, then you can define a number of mailboxes higher than the number allowed by the license (see Table 10) on your system.

In contrast to defining zero GDMS, you might define all (or almost all) mailboxes as GDMs. If you have a need only for GDMs (perhaps you are designing a temporary system to support a conference facility and various groups of staff members need to communicate via shared mailboxes, but no one requires any personally targeted voice mail), you could define all but one of the mailboxes on Cisco Unity Express as GDMs and a single personal mailbox. Provide the User ID and PIN of the single personal mailbox to all users for login access to the GDMs. Although it is possible to do this in the configuration, the side effect is that only a single person can be logged in to a mailbox at any one time, and because users all enter the system through a single personal mailbox, this configuration effectively reduces Cisco Unity Express to a single session access (no simultaneous access). If this is problematic for your application, you can define a few more personal mailboxes to allow some simultaneous access. The point remains that you can have far more GDMs than you require personal mailboxes (although the personal mailbox count can never be zero) if your situation is such that users can share knowledge of the PIN of a personal mailbox without creating security or privacy issues. If the number of personal mailboxes defined is less than the number of ports available on the system, then the lesser of the two numbers is the limit on the number of simultaneous voice mail logins you can achieve on the system. A personal mailbox must be defined with at least 10 seconds of storage space; it cannot be empty.

Note A GDM cannot be changed to a personal mailbox or vice versa. In other words, mailbox cannot be changed from being associated with a group profile to being associated with an individual user profile (or vice versa). To achieve this configuration change, the GDM must be a deleted and a new mailbox must be defined for the individual user (or vice versa). The contents of the deleted mailbox cannot be preserved, or transferred.

GDMs Only, but No Need for a Personal Mailbox

A user cannot have access to a GDM without also having a personal mailbox on the system. A user cannot have a personal mailbox without having a personal extension assigned. If the business environment is such that the user should have access only to a shared extension and its associated GDM, and is not to receive personal calls or personal voice mails, then the dial plan must be constructed to limit this access.

For example, the person works in the bakery of a small grocery chain and answers only calls to the bakery department, all outgoing calls are made from a payphone in the employee breakroom or a personal mobile phone. The bakery department's extension 2005 appears on the phone in the bakery department and the bakery GDM is associated with extension 2005. The three employees who work shifts in the bakery have personal extensions 3001, 3002, and 3003, and each has a personal mailbox set to the minimum size of 10 seconds (this effectively prohibits anyone from leaving voice mail in this mailbox). Further, extensions 300x are not forwarded on busy or no-answer, and they do not appear as button appearances on any phones, thereby effectively prohibiting users from receiving and making calls from these extensions.

Members and Owners

A group profile contains both owners and members, as shown earlier in Figure 23. Members of the group have access to log into the GDM and retrieve messages. Owners have administrative access to change the membership of the group they own. Group owners cannot log into a GDM unless they are also defined as a member of the group, as is User U3 in the example shown in Figure 23.

Mailbox License Control

The license purchased with the Cisco Unity Express system generally indicates the number of personal mailboxes allowed on the system, as shown in the "Personal Mailboxes" column in Table 10. A number of GDMs are allowed by the license in addition to the number of personal mailboxes that appears in the license.

Until Cisco Unity Express 2.0, the number of personal mailboxes or GDMs allowed by the license was strictly controlled as given in the "Personal Mailboxes" and "GDMs" columns in Table 10. In Cisco Unity Express 2.1, only the "Total mailboxes" column is strictly controlled by the license and the system allows you to define any combination of personal mailboxes and GDMs as long as the aggregate number does not exceed the "Total mailboxes" column.

The number of mailboxes allowed by the license can be displayed in the Cisco Unity Express GUI and CLI, but cannot be changed through these interfaces. Changing a license requires the purchase of a new license and an installation of a new license package file onto the Cisco Unity Express system.

Voice Mail Customization

The items that a voice mail subscriber can customize on a Cisco Unity Express mailbox are as follows:

•Spoken name—This is blank on a newly installed system and can be recorded or rerecorded by the subscriber. Once recorded, it can never be deleted; it only can be changed. To delete the spoken name, delete the entire mailbox from the system.

•Greetings—Cisco Unity Express allows two greetings to be recorded per mailbox, a standard greeting and an alternate greeting. The subscriber chooses—via the telephone user interface (TUI) or the GUI—which of the two greetings is the current greeting for the mailbox. The current greeting is played to all callers regardless of whether they are internal or external callers, or whether the call arrived at voice mail by virtue of CFNA or CFB. Cisco Unity Express ships with a basic system greeting that is played to callers if the subscriber has not recorded any customized greetings. Once recorded, the customized greetings cannot be deleted, or reset to the system greeting. To achieve this result, the mailbox must be deleted and reinserted into the system. Greetings can be rerecorded at any time.

When an external caller accesses a mailbox to leave a message, the caller can bypass the outgoing greeting by pressing # on the phone keypad.

The elements or order of the header playout (when a subscriber retrieves a message) is fixed and cannot be changed or customized in Cisco Unity Express.

The Cisco Unity Express voice mail TUI conversation (the menus, options, and directions presented to the user when logged in to a mailbox) cannot be changed, resequenced, translated, suppressed, or customized.

Cisco Unity Express does not support a feature comparable to the "call handler" approach offered by Cisco Unity.

Cisco Unity Express offers a tutorial mode for newly defined mailboxes (see the "Play Tutorial" field in the mailbox profile shown in Figure 22). This tutorial walks the subscriber through setting up the mailbox (spoken name, greetings, and change PIN) with the first login. After the subscriber has worked through the tutorial, it is automatically deactivated. As the administrator of the system, you can suppress the tutorial for newly defined mailboxes if you do not want this functionality, or you can turn the tutorial back on for a mailbox that has already been set up.

Voice Mail Language Customization

The voice mail system prompts can use a custom language if the desired language package is installed on Cisco Unity Express. Only a single language at a time is supported; activation of multiple simultaneous languages is not available.

Fax Calls

Cisco Unity Express cannot terminate fax calls into a voice mailbox. Cisco Unity Express 2.1 provides a voice mail functionality only—not unified messaging.

Caller ID in Message Header

Until Cisco Unity Express 2.0, only internal extensions were played out during the message header when a user retrieved a voice message. Messages from all other call origins played out as being from an "unknown caller," even if the digits were known at the time the call arrived.

As of Cisco Unit Express 2.1, the Caller ID for "unknown" calls (calls from anywhere else except another recognized subscriber defined in a user profile on the Cisco Unity Express system) can be played out reading the digits received with the call. This applies to VoIP calls or PSTN calls arriving at the mailbox.

Reading out Caller ID is not the default operation of the system; it requires an administrator to set the "Play caller ID for external callers" field on the Defaults > Voice Mail window shown in Figure 27.

Figure 27 Caller ID in Message Playout

Dial-by-Name in Message Send

The names accessible via the Cisco Unity Express AA dial-by-name and voice mail send dial-by-name functions are based on the user profile configuration. The First Name and Last Name fields, as shown in Figure 28, are used to populate the names database used by the dial-by-name feature.

Figure 28 Name Fields in Local User Profile

The Cisco Unity Express AA dial-by-name feature has the following characteristics:

•Names of users are defined on the local Cisco Unity Express system.

•Groups cannot be accessed via the AA dial-by-name feature.

The voice mail send dial-by-name function has the following characteristics:

•Names of users are defined on the local Cisco Unity Express system.

•Names of users are defined in remote user profiles on the local system. An example of a remote user profile is shown in Figure 29.

•Names of groups are associated with GDMs.

•Names of distribution lists.

Figure 29 Name Fields in Remote User Profile

Cisco Unity Express has no centralized or external directory access and cannot access name or user definitions defined anywhere else in the network.

Digit Manipulation

The use of Cisco CallManager or the routers (or any other piece of equipment in the call path) to perform digit translation on phone numbers could affect your call flows into Cisco Unity Express voice mail. When calls are not working correctly, you will experience overflow tone or dropped calls when attempting to enter voice mail. There are two aspects to consider regarding digit manipulation, including changes to:

•The voice mail pilot number

•The extension of the mailbox that must be entered

Voice Mail Pilot Number

The Cisco Unity Express voice mail pilot number is typically defined as an extension on the system, such as 3105. Very often there is also a PSTN number associated with the voice mail pilot to allow easy access for your employees to call in to retrieve their voice mail. This could be a number completely unrelated to the voice mail pilot number (such as x33.y55.1266) that is changed (via digit manipulation) to extension 3105 to route the calls. This could also be a DID number, for example, x33.y55.3105, that directly terminates without digit manipulation into voice mail.

You can configure the routing of calls to multiple variations of the voice mail pilot number (in this case 3105 from internal IP phones, and x33.y55.3105 from the PSTN) to Cisco Unity Express in one of two ways:

•Perform digit manipulation on the DID number (x33.y55.3105) and reduce it to the extension (3105) before delivering the call to Cisco Unity Express. In a Cisco CME environment, you can use translation rules on the router to accomplish this manipulation. In a Cisco CallManager environment, you can use route pattern tools to accomplish this manipulation.

•Define two voice mail pilot numbers in Cisco Unity Express to recognize both variations of the number as a valid pilot number. You can do this via the CLI in any release of Cisco Unity Express, but via the GUI only as of Cisco Unity Express 2.1.

The following configuration example shows a Cisco CME router configuration using translation rules to change the DID number (x33.y55.3105) to extension 3105 before the call enters Cisco Unity Express. For this scenario, Cisco Unity Express has a single voice mail pilot number (3105) defined, as shown in Figure 30.

voice translation-rule 10

 rule 1 /x33y553100/ /3100/

 rule 2 /x33y553105/ /3105/

 rule 3 /x33y553106/ /3106/

!

voice translation-profile to_cue

!

 translate called 10 dial-peer voice 3100 voip

 description VM-AA

 destination-pattern 31..

 session protocol sipv2

 session target ipv4:a.3.229.128

 dtmf-relay sip-notify

 codec g711ulaw

 no vad

!

dial-peer voice 3101 voip

 description VM-AA-PSTN

 translation-profile outgoing to_cue

 destination-pattern x33y5531..

 session protocol sipv2

 session target ipv4:a.3.229.128

 dtmf-relay sip-notify

 codec g711ulaw

 no vad

Figure 30 Cisco Unity Express Single Voice Mail Pilot Number Configuration

As an alternative to digit manipulation, you can define two pilot numbers on Cisco Unity Express to accept incoming calls to the two numbers. For this configuration you should ensure that your call agent can route calls intended for both pilot numbers to Cisco Unity Express. The following configuration example shows SIP dial peers for Cisco CME or Cisco SRST deployments:

dial-peer voice 3100 voip

 description VM-AA

 destination-pattern 31..

 session protocol sipv2

 session target ipv4:a.3.229.128

 dtmf-relay sip-notify

 codec g711ulaw

 no vad

!

dial-peer voice 3101 voip

 description VM-AA

 destination-pattern x33y5531..

 session protocol sipv2

 session target ipv4:a.3.229.128

 dtmf-relay sip-notify

 codec g711ulaw

 no vad

On Cisco CallManager, you can define multiple route points to be associated with the Cisco Unity Express JTAPI user. The following configuration example shows the Cisco Unity Express CLI for the definition of both pilot numbers, and Figure 31 shows the Cisco Unity Express 2.1 GUI window for the same configuration:

ccn trigger sip phonenumber 3105

 application "voicemail"

 enabled

 maxsessions 8

 end trigger

ccn trigger sip phonenumber x33y553105

 application "voicemail"

 enabled

 maxsessions 8

 end trigger

Figure 31 Cisco Unity Express Multiple Voice Mail Pilot Number Configuration

Extension of the Mailbox

As described in the "Voice Mail Pilot Number Operation" section, Cisco Unity Express uses the "last redirected number" field delivered by the call agent to decide which mailbox to enter. The digits in this field must map to an extension assigned to a mailbox, or the call will fail with a Cisco Unity Express system message announcing "Sorry, there is no mailbox associated with this extension...".

To ensure that calls enter the desired mailbox in Cisco Unity Express, remember the following digit manipulation considerations:

•Cisco Unity Express can associate up to two numbers with a mailbox (the Primary Extension and the Primary E.164 Number fields in the Cisco Unity Express user profile). A call containing either of these two numbers will correctly enter the mailbox for this subscriber. If you have more than two numbers that must be mapped to a single mailbox, those numbers must be translated on the call agent to match the Primary Extension or the Primary E.164 Number fields before the call reaches Cisco Unity Express.

•If you are leveraging the Primary E.164 Number field for a purpose other than the DID number for the subscriber (as described in the "Calling into Voice Mail to Retrieve Messages" section), then the DID number must be translated to the extension by the call agent before the call enters Cisco Unity Express.

•If you are using Cisco CME as the call agent, and implement dialplan-pattern commands to "normalize" numbers, be aware that these commands translate (or expand) the dialed number of internal calls to the digit string specified in the dialplan-pattern command statement. This might be a number that Cisco Unity Express does not recognize because it no longer equals the extension associated with the mailbox. Set the Primary E.164 Number field to the expanded number created by the dialplan-pattern command.

If Cisco CME has primary and secondary numbers defined on an ephone, the number that was dialed by the originator is the number delivered to Cisco Unity Express. For an ephone-dn configuration of "number 3001 secondary x33y553001," either of the two numbers associated with that phone may be delivered to Cisco Unity Express, depending on which number the caller dialed. Unless the Primary E.164 Number is configured to match the secondary number, calls to both numbers cannot get forwarded to voice mail.

"Announcement Only" Mailbox

You can use either the Cisco Unity Express AA or a voice mailbox in order to play an announcement to callers that changes frequently (perhaps daily or hourly). Cisco Unity Express does not have a direct feature or mailbox type called an "announcement-only" mailbox, but you can use various other Cisco Unity Express features in combination to achieve this operation.

AA Application

The Cisco Unity Express AA is the most flexible way of implementing an "announcement-only" mailbox implementation. Write an AA script that plays an announcement (prompt) to callers. The simple example file (Announcement-mbox.aef) is shown in Figure 32. Associate this script with a pilot number (in the same way you would build a Cisco Unity Express AA application). Callers to the pilot number will hear the announcement and the call will be automatically disconnected by the Terminate step.

Figure 32 Announcement Script Example

To change the announcement played by the script, follow these steps:

Step 1 Log in to the Administration via Telephony (AVT) interface of Cisco Unity Express.

Step 2 Record the new prompt.

Step 3 Change the system-assigned filename via the GUI to the filename you want (Voice Mail > Prompts window).

Step 4 Associate the new prompt file with the script via the Script Parameters GUI window as shown in Figure 33 (Voice Mail > Auto Attendant, click on the application name, and click Next).

The new prompt will take effect with the next new incoming call. Existing calls already active in the application are not affected by this change.

Figure 33 Updating the Announcement

Building the "announcement mailbox" application using the Cisco Unity Express AA features has the following characteristics and tradeoffs:

•The person making changes to the prompt recordings and assignments requires AVT access (to gain this access, define a group with the privilege to access the AVT and then add the users that must have this access as members of the group). This provides automatic PIN authentication so that only designated administrators can make changes to the announcements.

•The person making changes to the prompt recordings and assignments requires browser access to the Cisco Unity Express GUI to change the prompt filenames and assignments to the script. Although these changes can also be made via the CLI, this interface is likely not well suited to the person who would be maintaining these prompts.

•The simple script example shown in Figure 32 disconnects the call immediately after the announcement, but you have full flexibility in the script instead to request and process input (DTMF) from the caller, or provide other information or choices (such as being transferred to an operator) subsequent to the announcement.

•You have full control over the exact content of the phrases spoken to the caller and you can disconnect the call at a time of your choice. You need not rely on the caller to hang up or take any action.

•You can have the same announcement available in multiple different languages. You can either direct the caller to a language of choice by presenting a menu step before the announcement is played, or you can derive the language preference from the called number (provided you have different PSTN numbers for the different language preferences, and therefore also multiple pilot numbers associated with the application script).

•You can easily prerecord announcements, and have them automatically activated at a later time by using the time-of-day, day-of-week, or business-hours steps in the script. The example script in Figure 34 shows four different announcements given during the day in two-hour blocks, and a fifth announcement is given after hours. These announcements can all be recorded at the start of the day (or the end of the previous day) and each will take effect based on the actual time of day as specified in the script. By designing your own custom script, you have full control over the schedule and timing of the announcements that the application plays.

Figure 34 Time-of-Day Announcement Script Example

Voice Mailbox Application

A Cisco Unity Express GDM can also be used to implement an "announcement mailbox" application. Define a GDM, associate it with an extension (which becomes the equivalent of your pilot number for this application), and log in to the GDM and record the announcement you want played as the outgoing greeting of the mailbox. You can record an alternate greeting as well and therefore, by changing the greeting of the mailbox between standard and alternate, you could alternate between two different prerecorded announcements.

Building the "announcement mailbox" application by using the Cisco Unity Express GDM voice mail features has the following characteristics and tradeoffs:

•The person making changes to the GDM greetings (rerecording the announcement) requires access to the GDM. This person must therefore have a personal mailbox defined, and be a member of the group associated with the GDM. The person's personal mailbox provides PIN authentication so that only designated administrators can make changes to the announcement.

•The person making changes to the GDM greetings requires only telephone (TUI) access to the Cisco Unity Express system; no browser or IP access is necessary.

•You do not have full control over the exact content of the phrases spoken to the caller. The recorded greeting for the GDM is played out to the caller (which you can fully control), but that is followed by the system prompt "You may record your message at the tone. When you are finished you can hang up, or press pound for more options," which cannot be bypassed, suppressed, or provided in a language other than the system language installed on Cisco Unity Express.

•You cannot disconnect the call from the Cisco Unity Express system—the caller must disconnect.

•If the active greeting of the GDM is rerecorded, it becomes live immediately. If the alternate greeting is rerecorded it can be made live by manually changing the active greeting of the mailbox—this action cannot be scheduled to happen automatically at a future time.

•To provide an announcement in different languages you can define multiple different GDMs, each containing the announcement in an individual language. This call flow requires separate PSTN call-in numbers to differentiate which language the caller wants. The caller cannot be prompted for a language choice.

•The smallest size mailbox that can be defined on Cisco Unity Express is 10 seconds. It cannot be zero. If the caller does not hang up after the announcement is completed, the caller is presented the normal mailbox dialog and is offered an opportunity to leave a very short message.

Disabled Mailboxes

A mailbox can be disabled by the Cisco Unity Express system administrator. The administrator does this by unchecking the Enabled field in the mailbox profile (see Figure 22). A subscriber cannot log in to a disabled mailbox, and callers cannot leave messages in a disabled mailbox. Disabling a mailbox is equivalent to deleting it, from a functional point of view; however, this preserves the content of the mailbox if that should be of value to your organization. If a mailbox is deleted, the messages are deleted too. A disabled mailbox can be reenabled by the administrator at a later date to restore full operation of the mailbox.

Orphaned Mailboxes

If a user or group profile is deleted using the Cisco Unity Express GUI, the associated mailbox is also deleted. However, if a user or group profile is deleted using the CLI, the mailbox is left intact, causing it to become orphaned (disassociated from a specific active subscriber profile). See Figure 35.

Figure 35 Orphaned Mailbox

The Cisco Unity Express maintains an orphaned mailbox for seven days; during this time, the user or group profile can be rebuilt and the mailbox reassociated with its owner. After seven days, orphaned mailboxes are automatically deleted by the system. Orphaned mailboxes cannot be associated with a different User ID; an orphaned mailbox must be reassociated with same User ID for which it was defined originally.

Mailbox Space Allocation

Messages are stored in G.711 u-law format—An encoding scheme designed to be transmitted at a data rate of 64 Kbps. Each minute of audio uses bandwidth according to the following calculation:

60 seconds * 64 Kbps = 3840 Kb/minute = 480 KB/minute

The audio of a voice message is physically stored only once regardless of how many mailboxes in which the message may appear—either by being sent by the originator to multiple subscribers, or being forwarded to other subscribers by recipients of the message. However, the time for the message is counted against each individual mailbox where the message appears.

Space used by an individual mailbox includes:

•Standard greeting size

•Alternate greeting size

•Size of all voice messages in the mailbox

Spoken name recordings are not counted as part of the space allocation of a mailbox.

When a new mailbox is created, it is set to the default system mailbox size, unless it is explicitly set to a particular size by the administrator. Changing the system default mailbox size does not affect existing mailboxes; it governs only the size allocated to mailboxes created after the default is changed.

Note Upgrading the license on Cisco Unity Express to a higher number of mailboxes does not affect the storage allocation on the system. For example, if a 12-mailbox license is installed on a Cisco Unity Express AIM module with 16 hours of storage, and an hour is allocated to each of the mailboxes, then 12 of the 16 hours total storage is allocated on this system. When this system is upgraded to a 25-mailbox license, there is only 4 hours left to be allocated to the 13 new mailboxes. If this is insufficient, each of the original 12 mailboxes must be resized to make more space available to the new subscribers. A mailbox's size can be lowered by the administrator, but requires a value at least big enough to contain the current message content in the mailbox.

Spoken Names

The limit on spoken names recorded by using the TUI for local subscribers, network locations, and remote subscribers is 10 seconds.

Spoken Name Confirmation

When a subscriber addresses a message to another subscriber, spoken name confirmation is given to the sender of the message whenever possible. If spoken name confirmation is not available, the destination extension is read out. The spoken name of the recipient might not be available due to one of the following issues:

•Local recipient—The recipient subscriber has not recorded a spoken name for the assigned mailbox.

•Remote recipient—The spoken name for the subscriber does not exist in either the static directory (remote user configuration) or the dynamic cache of entries accumulated via receiving networked messages from other sites.

Spoken Name Delivery

When a subscriber receives a message, a spoken name is delivered as part of the message header readout whenever possible. If spoke name delivery is not available, the originating (sending) extension is read out. The spoken name of the sender might not be available due to:

•Local or remote sender—The sending subscriber has not recorded a spoken name for their mailbox.

•Remote sender—The sending system's intersite networking is set up not to include the spoken name with the message when transmitting it to the recipient. Cisco Unity Express sends the spoken name by default with networked locations. Figure 36 shows the Send Spoken Name field for a networked location that can be used to control this operation (use the Administration > Networking Locations window, then click on the desired location, or Add for a new location, to bring up this window). Cisco Unity does not send this field by default, but it can be enable by toggling the Sender's recorded name field on the Delivery Locations window for the particular location in question.

Figure 36 Send Spoken Name for Networked Locations

Outcall Notification

Cisco Unity Express 2.1 does not support any means of outcall notification.

Directories

Cisco Unity Express uses an internal directory to store user and PIN information, and to do user mailbox, AVT, or browser administration login authentication. This directory information cannot be accessed externally from another system, nor can Cisco Unity Express access an external directory for its authentication purposes.

Cisco Unity Express keeps and uses several types of directory information:

•Local user and PIN information—This information is derived from the user profiles (Configure > Users) entered into the Cisco Unity Express configuration.

•Remote user information—This information is derived from the remote user profiles (Configure > Remote Users) entered into the Cisco Unity Express configuration.

•Dynamic Cache—This information is derived from Voice Profile for Internet Mail (VPIM) messages received by Cisco Unity Express. The sender user information, and the spoken name (if present), are kept in a short least recent user (LRU) cache for use (for example, to provide Spoken Name Confirmation) if messages are sent back (reply or a new message) to this same user. This cache is automatically enabled, but can be disabled by the Enable remote user information cache field on the Defaults > Voice Mail window if needed.

MWI Operation

Cisco Unity Express enables an MWI when a new voice message is left and disables MWI when the last new voice message is saved or deleted. Cisco Unity Express has no direct visibility into enabling or disabling MWI on a phone. Cisco Unity Express knows the extension associated with the change in MWI, and notifies the call agent of the extension and the desired MWI state. Upon receiving this message, the call agent is responsible for determining on which phones the extension appears, and to send an appropriate message to each affected phone to change its MWI state.

The following MWI considerations are presented in this section:

•Methods of Invoking MWI

•MWI Lamps and Icons

•Refresh

•Broadcast

•GDMs

Methods of Invoking MWI

The method of MWI notification used by Cisco Unity Express depends on the associated call agent:

•Cisco CME—Outdial directory numbers (DNs) are used between Cisco Unity Express and Cisco CME. Cisco Unity Express initiates an outbound SIP call to a predefined Cisco CME MWI extension and when Cisco CME receives this call attempt, it collects the extension for which MWI must be changed from the call setup attempt, and in turn lets the phone know to change its indicator to the requested state. Two separate MWI extensions are defined on Cisco CME, one for "MWI on" and one for "MWI off". Only one set of these MWI on/off extensions can be defined, which in turn implies that all Cisco CME extensions associated with mailboxes must be of a fixed length or MWI will not operate correctly.

•Cisco CallManager—JTAPI is used as the signaling protocol between Cisco Unity Express and Cisco CallManager. To notify Cisco CallManager of an MWI change, Cisco Unity Express sends a JTAPI message containing the extension and the requested MWI state. Cisco CallManager sends a message to the affected phones.

•Cisco SRST—There are no MWI changes for phones during SRST failover mode, regardless of message activity in the mailbox. If MWI state is on before SRST failover, it remains on until Cisco CallManager comes back into contact. Similarly, if the MWI state is off before failover, it remains off until contact is reestablished. MWI state on all phones is refreshed automatically when Cisco CallManager comes back into contact; no manual intervention is required.

MWI Lamps and Icons

The nature of the MWI indication depends on the capabilities of the phone, the configuration of the system, and the call agent used. Characteristics are as follows:

•Lamp—Cisco IP phones have a red lamp in the handset that can be lit for MWI. When you implement Cisco Unity Express with Cisco CME, this type of MWI is provided only for messages associated with the extension on button 1 of the phone. When a lamp is used as a MWI with Cisco CallManager, the configuration determines which buttons on the phone will trigger MWI via the red lamp of the phone set.

•Flashing Icon—Cisco IP phones with displays can provide a flashing envelope icon next to a button appearance. When Cisco Unity Express is implemented with Cisco CME, this type of MWI is provided for messages associated with the extensions on button 2 or higher of the phone. When a flashing icon is used with Cisco CallManager, the configuration determines which buttons on the phone will trigger MWI via a flashing icon.

•Stutter Dial Tone—Analog phones connected to an SCCP-controlled FXS port (for example, on a VG224 gateway) are provided with stutter dial tone MWI.

Note Cisco CME can activate MWI for the primary or secondary extension associated with an ephone-dn. MWI can be activated only for the first DN on an overlay. The subsequent DNs associated with an overlay do not trigger MWI on the phone.

Refresh

MWI state on all phones is refreshed when the Cisco Unity Express system reboots or starts up. It is not done as a periodic scheduled activity while the system is running. If MWI state should become unsynchronized with mailbox state, MWI must either be reset manually or Cisco Unity Express must be rebooted.

The administrator can reset MWI state manually, either for a particular phone, or for the entire system. If the entire system is selected, MWI state changes will be staggered over a short period of time; not all phones will be done at once.

Broadcast

Cisco Unity Express provides MWI for individual message activity in personal mailboxes and GDMs by default. This feature cannot be turned off.

MWI can optionally be provided for broadcast messages (the default is disabled). To disable MWI for broadcast messaging, set the "Use MWI for broadcast messages" field to Yes (on the Defaults > Voice Mail window).

The configuration of MWI for broadcast messaging is of local significance to the Cisco Unity Express system. Therefore, if you send a broadcast message to five different sites, MWI might be activated for that message on some of the recipient sites and not on others, depending on how each individual recipient system is configured for this parameter.

The configuration of MWI for broadcast messaging is a Cisco Unity Express system-wide setting. MWI operation for broadcast messaging cannot be controlled per individual mailbox, or individually per message. MWI state (on or off) is not an attribute of the broadcast message itself; it is an attribute of the system on which the message is delivered. If MWI for broadcast messaging is configured to be on, the MWI light is lit for all mailboxes on the system when a broadcast message becomes active. MWI is refreshed when a broadcast message expires so that any mailboxes that have not listened to the message will never receive it and the MWI state is turned off (unless there are other new messages in the mailbox).

GDMs

MWI for GDMs is done in the same manner as MWI for personal mailboxes. If the extension associated with a GDM appears on a phone, then that phone receives MWI for message activity in the GDM. MWI for GDMs is not done to the phones associated with the extensions of the group's members; it is done only to the extension directly associated with the group mailbox. For example, MWI is done to phones with an appearance of extension 1050 in the configuration shown in Figure 25.

GDMs can be associated with extension types that cannot be placed as button appearances on a phone, such as Cisco CME automatic call distributor (ACD) or hunt-group pilot numbers. If the GDM is associated with such a type of extension, there is no MWI for messages in that GDM on any of the phones that belong to the ACD or hunt group. You can work around this by configuring the ACD or hunt group to forward calls to an intermediate extension (which is set permanently to CFA calls to the voice mail pilot number), rather than forwarding directly to voice mail. The intermediate extension can now be placed on a phone as a button appearance and MWI for GDMs can be implemented even for GDMs functionally assigned to ACD or hunt groups. Figure 37 shows such a configuration.

Figure 37 MWI for GDMs Associated with ACD and Hunt Groups

In the example shown in Figure 37, the ACD pilot number is 2040. If you associate the GDM with extension 2040, then there is no MWI for any messages in the GDM. Instead, associate the GDM with intermediate extension 2070, which is permanently forwarded (via CFA) to the voice mail pilot number 2105. The ACD voice-mail number is now set to 2070 instead of directly to 2105. Extension 2070 may now appear on a button on the ACD agent phones and gets MWI for message activity in the GDM. The following configuration example illustrates the Cisco CME and Cisco Unity Express configurations for this setup.

The following Cisco CME configuration example illustrates configuring GDM MWI for an ACD group:

!

! Cisco CME ACD AA Configuration for pilot number 2040.

!

call application voice cme-aa flash:app-b-acd-aa-2.1.0.0.tcl

call application voice cme-aa second-greeting-time 30

call application voice cme-aa max-time-call-retry 60

call application voice cme-aa max-time-vm-retry 1

call application voice cme-aa call-retry-timer 20

call application voice cme-aa aa-pilot 2040

call application voice cme-aa number-of-hunt-grps 3

call application voice cme-aa service-name acd

call application voice cme-aa voice-mail 2070

call application voice cme-aa language 0 en

call application voice cme-aa set-location en 0 flash:

!

! Extension 2070 associated with the GDM. It is CFA to 2105, 

! the Cisco Unit Express pilot number.

!

ephone-dn  11

 number 2070

 description GDM

 name Cust Svc GDM

 call-forward all 2105

!

! Ephone-dn 11 (2070) is defined as button 2 on the ACD Agent phone

! so that the agent can get MWI for the GDM.

!

ephone  1 

 username "Agent1"

 mac-address 1111.2222.3333

 type 7960

 button  1:1 2:11

The following Cisco Unity Express configuration example illustrates configuring GDM MWI for an ACD group:

!

! The custservice ACD group (and GDM) is associated with extension 2070.

!

groupname custservice phonenumber "2070"

!

! Voice mail pilot number is 2105.

!

ccn trigger sip phonenumber 2105

 application "voicemail"

!

! Define the GDM associated with 2070, associated with the custservice group.

!

voicemail mailbox owner "custservice" size 5520

 description "custservice mailbox"

Leaving a Message After Business Hours Only

If calls must ring on phones indefinitely during business hours, and only forward to voice mail after hours, a time-of-day routing feature is required on the call agent—or the employees must manually call forward their phones to the voice mail pilot number when they leave the office at the end of the day. Cisco Unity Express itself does not provide this feature; the call agent makes a decision to forward the call (or not) to the voice mail system before it reaches the voice mail system.

Distribution Lists

Cisco Unity Express 2.1 introduces support for distribution lists. A distribution list allows a subscriber to send a message to a list of predefined recipients. Distribution lists can be addressed either by number or tag (the descriptive name associated with the distribution list). A spoken name can be recorded via the TUI (it cannot be uploaded as a .wav file) for a distribution list to assist in confirmation that the message is being sent to the correct recipient list (during addressing of a message).

The following distribution list considerations are presented in this section:

•List Types

•Membership and Ownership

•Privileges to Access and View Distribution Lists

•Remote Users and Remote Distribution Lists

•Everyone List

List Types

Cisco Unity Express supports public and private distribution lists as follows:

•Public—These are defined by an administrator (or suitably privileged system user), and are visible to all subscribers on the system and can have messages addressed to them by all subscribers.

•Private—These are defined by an individual subscriber and are visible (in general) only to the subscriber that defines the list.

If a subscriber is deleted from the system, all the private distributions lists belonging to that subscriber are also deleted from the system. Public lists, however, are deleted only when the administrator explicitly deletes them.

The following characteristics apply to the support of public distribution lists:

•A maximum of 15 public lists per system

•A total of 1000 members in all public lists collectively on a Network Module (NM) and a total of 500 members on an Advanced Integration Module (AIM)

•A maximum of 50 owners collectively across all public lists

Note The "everyone" list (described in the "Everyone List" section) and its members do not count toward these numbers.

The following characteristics apply to the support of private distribution lists:

•A subscriber can define up to five private lists.

•A total of 50 private list members are supported per subscriber (collectively over all lists belonging to this subscriber).

Membership and Ownership

Distribution lists have members and owners. Members are the recipients who receive a voice message when a sender sends a message to the distribution list. Owners are the subscriber User IDs who have the privileges to change the membership and other parameters of the distribution lists.

The members of a distribution list can be any combination of the following entities:

•Local

–Subscribers

–Groups

–GDMs

–Other (nested) public distribution lists

•Remote

–Blind addresses (a numeric string representing a location code that is configured on the local system and the extension of a subscriber at another network location)

–Remote subscribers (user IDs defined in the Configure > Remote Users GUI window)

The owners of a public distribution list can be one of the following entities:

•Local subscribers

•Groups

Public lists can be nested and can include other public lists as members, but public lists cannot include private lists. Private lists can include public lists as members.

Both a group and a GDM can be members of a distribution list. If a group is a member, any message sent to the distribution list is placed in the personal mailbox of each member of the group (but not the group mailbox or GDM). If a GDM is a member, any message sent to the distribution list is placed in the GDM (but not any personal mailboxes of group members). Both the group and the GDM can be explicit members of a distribution list if you want the message to be delivered to both destinations.

Privileges to Access and View Distribution Lists

Private distribution lists are administered and owned by the subscriber who defined them. They are, in general, not visible to anyone other than that subscriber. The exception to this rule is if another user (likely an administrator) is given the explicit "Private List Viewer" privilege. In this case, the subscriber with this privilege can view (although not change) the members of the private lists held by other subscribers on the system (through the GUI).

"Private List viewer" is one of the system access privileges that can be awarded to a group. All members of that group inherit that privilege. Assigning this privilege for a new group is shown in Figure 38.

Figure 38 Assigning the Privilege to View Private Distribution Lists

Note Public lists are printed in the text configuration output of the Cisco Unity Express system (with the show running-config command), but private lists are not. If you make a "backup" of a system configuration by copying and pasting the output of the show running-config command, you cannot preserve the definition of private lists to the new system. Private lists can be explicitly listed in the CLI by using the show lists owner user-id command, where user-id is the User ID of the owner of the list.

Defining public distribution lists is controlled by the "Public List Manager" privilege (see Figure 38). All members of a group that has this privilege can define and manage public list membership on the system. To modify a public distribution list, the user must be a member of a group that has the "Public List Manager" privilege, or be an owner of the public list. By default, only users that belong to the Administrators system group have these privileges.

Table 11 summarizes the distribution list parameters that can be administered via the TUI, GUI, and CLI.

Remote Users and Remote Distribution Lists

Distribution lists are local to the system on which they are defined and can be addressed only by local subscribers when they send messages. A distribution list that was defined at a remote site cannot be used as the destination address of a message sent on your local system. You can send a message to a local distribution list that includes remote users (as members) and blind addresses (location code and extension) that result in remote recipients receiving the message.

Everyone List

Cisco Unity Express defines a system public list named the "everyone" list. This list cannot be deleted and the membership cannot be changed. It is automatically maintained by the system and always contains a definitive list of every subscriber defined on the system. Groups and GDMs are not members of the "everyone" list—only local subscribers (user profile definitions).

The default list number for the "everyone" list is 9999. This number can be changed if it conflicts with your dial plan or you desire a different numbering scheme. The "everyone" list comes with a default spoken name that can be rerecorded by an administrator.

The "everyone" list and its members do not count against the list and member number limits for the system.

Broadcast Messaging

Broadcast messaging is the ability for an authorized subscriber to send a prioritized voice mail message that everyone receives and to which everyone must listen. A broadcast message is sent to all local subscribers and all subscribers at all (or specified subset of) remote systems in the network deployment. Broadcast messages can be sent from, or to, Cisco Unity Express and Cisco Unity sites.

On Cisco Unity Express a broadcast message is sent from the administrator's AVT interface. GDMs cannot receive broadcast message; only the personal mailboxes of individual subscribers can receive broadcast messages. A broadcast message is treated like any other normal voice message, except for:

•Broadcast messages are played immediately after the subscriber logs in as the highest priority in the message playout list.

•Subscribers must listen to the entire broadcast message—a broadcast message cannot be skipped or fast forwarded.

•Broadcast messages cannot be forwarded or replied to (they can be saved).

•The recipient does not know who sent the broadcast message.

•A new (unread) broadcast message does not count against the recipient mailbox's storage capacity, but once it is saved it does.

•You cannot send a broadcast message to a distribution list.

The following broadcast messaging considerations are presented in this section:

•MWI for Broadcast Messaging

•Sending and Addressing a Broadcast Message

•Lifetime of a Broadcast Message

•Broadcast Message Properties

•Broadcast Messaging and VPIM

•Broadcast Message Delivery to a Network Location

•Nondelivery Receipt

MWI for Broadcast Messaging

MWI for broadcast messaging is described in the "MWI Operation" section.

Sending and Addressing a Broadcast Message

Broadcast messages are sent from the administrative AVT interface by users with the appropriate privileges. The "Voice Mail Broadcaster" privilege, shown in Figure 38, is an attribute of a group profile. This privilege is required for an AVT user to log in and hear the menu selections pertaining to broadcast messaging. Members of the system-defined "Broadcasters" group have this privilege enabled by default, but you can also add it to any other group definition of your choice.

The following broadcast message creation and addressing options are available in the AVT:

•Local Broadcast message:

–Option 3-1-1 from the AVT main menu.

–The message is sent to all personal mailboxes on the local system.

•Global Broadcast message:

–Option 3-1-2-1 from the AVT main menu.

–The message is sent to the local system and all systems defined as remote networking locations on the local system.

•Broadcast message to a specific remote systems:

–Option 3-1-2-2 from the AVT main menu.

–The location codes of the individual systems (local or remote) where the message must be sent are entered—a distribution list cannot be used to contain this list of location codes.

Lifetime of a Broadcast Message

A broadcast message can be prerecorded and scheduled to be delivered, or become active, at a future date and time. Similarly, a broadcast message can be set to expire at a certain date and time such that if the relevance of a message is only for a few days or a week, then the message can be removed upon expiring from any mailboxes that have not yet listened to the message.

The time between when a broadcast message becomes active and when it expires is called the lifetime of the message. The lifetime is specified by the start and end time associated with the message:

•Start time—By default, this is immediately when the message is recorded. The start time could be set to be in the future so that a message becomes active on a specified date and time.

•End time—This is calculated as the start time plus the broadcast message lifetime, which is a configurable system parameter with a default of 30 days and a limit of not being more than a year into the future. When the end time occurs, the broadcast message expires and messages that have not yet been listened to by subscribers are removed from the subscribers' mailboxes and MWI (if configured) is turned off.

Start and end times can be changed only via the CLI, once a broadcast message has been recorded, and start and end times have been assigned. For a message that is already active, only the end time can be changed. For a broadcast message sent to multiple networked locations, the parameters must be changed on each individual location, the source system no longer has any control over the destination system's handling of the message.

A broadcast message is sent to recipient network locations with Coordinated Universal Time (UTC) time parameters such that it will be delivered simultaneously on all receiving systems in their respective time zones. It is the responsibility of the recipient system to convert the UTC time stamp to the local time zone and activate the message at the appropriate given time. This means that if a broadcast message is composed with a start time of 08:00 Pacific Daylight Time, and sent to recipient systems in New York and London, then that message will activate and be delivered at 11:00 Eastern Daylight Time for mailboxes on the system in New York and 16:00 British Summer Time for mailboxes on the system in London.

Broadcast Message Properties

The following behavior differences exist between normal voice messages and broadcast messages. In all other respects, broadcast messages behave just like other voice messages.

•Mailbox full condition—This condition cannot occur for a broadcast message. A new (not yet listened to) broadcast message is not counted against the recipient mailbox's storage allocation, so even if the destination mailbox is full, a new broadcast message can still be received and listened to. A broadcast message cannot be saved by the subscriber if the mailbox is full, but it can be listened to. Once a broadcast message is saved by a subscriber, the message is counted toward the storage allocation of the mailbox.

•Active time—Broadcast messages are active only between the start time and the end time specified for the message. Mailboxes will not receive a broadcast message until the start time passes. A broadcast message will be deleted from all mailboxes from which it has not yet been retrieved when the end time passes. MWI is updated according to when a broadcast message is active in the system.

•Message envelope—No sender envelope information (for example, sender name or number, or the date and time the message arrived) is played for a broadcast message. A recipient does not know who sent a broadcast message, only that it is a broadcast message.

•Message controls—Subscribers cannot ignore, fast-forward, reply to, or forward a broadcast message. The message can be repeated, deleted, or saved after the subscriber has listened to it.

•Message Send—A subscriber cannot send a broadcast message from a mailbox. To send a broadcast message, you must log in to the AVT interface. Only users with access privileges to the AVT, and the "Voicemail Broadcaster" privilege in their profiles, can access the broadcast message menu items in the AVT.

Broadcast Messaging and VPIM

A broadcast message can be addressed to all sites in a network, or a subset of locations in the network. A single broadcast message is sent across the network from the local system to each remote system to which it was addressed—the remote recipient system replicates the message to all personal mailboxes on that system.

The VPIMv2 voice mail networking standard does not support a method for broadcast messaging between sites, so Cisco Unity Express and Cisco Unity have implemented this functionality via extensions to VPIMv2. These extensions require the following minimum releases:

•Cisco Unity Express 2.1 or a later release

•Cisco Unity Release 4.0(5) or a later release

Previous releases of both Cisco Unity Express and Cisco Unity support standard VPIM networking, but not the broadcast extensions.

Broadcast Message Delivery to a Network Location

For a normal voice message, the recipient mailbox address is used by the destination voice mail system to decide whether an incoming VPIM message from a remote source system is a valid message, and thus whether to accept it. Cisco Unity Express rejects incoming VPIM messages addressed to invalid mailboxes.

Unlike a normal voice message, a broadcast message is not addressed to an individual extension (mailbox) on the destination system. To address a broadcast message, a "virtual broadcast message mailbox" tag must be used to allow the destination system to recognize the message as valid, to accept it, and subsequently to replicate it to individual mailboxes on the system. The "VPIM Broadcast ID" field in the configuration of a networking location is used for this purpose. See Figure 39.

Figure 39 VPIM Broadcast ID

The default value for the "VPIM Broadcast ID" field is "vpim-broadcast" for all Cisco Unity Express networking locations. Considerations about the use of this field are as follows:

•Broadcast networking on Cisco Unity Express is enabled by default. You can disable the ability for Cisco Unity Express to send and receive broadcast messages to or from other locations by entering an empty string (removing the current field value) in the "VPIM Broadcast ID" field of the destination location's configuration.

•The "VPIM Broadcast ID" field value is configured per networking location, including the local location. The value can be the same for each location provided the locations are all in different domains (that is, the domain name makes the full xxx@domain.name address unique).

•To enable network broadcast messaging between Cisco Unity Express and Cisco Unity sites in a network, the broadcast "VPIM Broadcast ID" field must be set to a numeric-only value (this is a Windows Exchange requirement that underlies the Cisco Unity messaging infrastructure), and must match Cisco Unity's broadcast mailbox ID. The general guideline is that you can use the Cisco Unity Express default "VPIM Broadcast ID" field value (alphanumeric) if your network contains only Cisco Unity Express sites. However, if you have a network of Cisco Unity Expresss and one or more Cisco Unity sites, then set all site values to a numeric value to ensure full intersite interoperability.

Nondelivery Receipt

Broadcast messages are sent to a large number of subscribers. No nondelivery receipt (NDR) is generated for a broadcast message that cannot be delivered to an individual subscriber at any of the destination locations (an NDR is generated for nonbroadcast voice mail messages to individual subscribers). If the destination location is the local Cisco Unity Express site, then an NDR will never be generated for a broadcast message. If the destination site is a remote location, an NDR for a broadcast message is provided for situations affecting the entire site, such as the following:

•Connectivity problems to the remote location

•Remote location not responding

•Mismatch in the "VPIM Broadcast ID" field

•Message content errors reported by the destination location

A separate NDR is generated for each location that cannot accept the broadcast message. Broadcast messages are sent from the AVT interface, but NDRs are placed into the sender's mailbox.

Comparison of "Everyone" Distribution List and Broadcast Message

There are two general methods to distribute a voice message to every subscriber on your system:

•The "everyone" system-provided public distribution list

•A broadcast message to the local system

There are various differences in how these two methods operate that may cause you to choose one method over the other for the distribution of a particular message. The following operational characteristics apply:

•Playout priority—A broadcast message is played out as the top priority in a recipient's mailbox. A message received via a distribution list is played out amid the normal list of new messages (based on its arrival time) and is not given any special priority.

•MWI control—A message received via a distribution list always gets MWI. A broadcast may or may not trigger MWI depending on the system's configuration (default is no MWI).

•Message options—A message received via a distribution list can be saved, deleted, ignored, and forwarded just like any other voice message; no special considerations apply. A broadcast message cannot be ignored, forwarded, fast-forwarded, or replied to, and must be listened to in its entirety by the recipient before other new messages can be reviewed. A broadcast message can only be saved or deleted.

•Future delivery—A message sent via a distribution list is delivered immediately to recipient mailboxes. A broadcast message can be recorded, but scheduled for a future delivery date and time.

•Identity of the sender—The sender's name and number are delivered to the recipient via the message header playout for a message received via a distribution list. The identity of the sender of a broadcast message is not known to the recipients, and the message cannot be replied to.

•Message expiry—A message received via a distribution list remains in a recipient mailbox as a new message until the recieving subscriber logs in and reviews the message, or the mailbox is deleted. A broadcast message can be set to expire on a certain future date and time so that recipients, who have not yet retrieved the message, will not hear the broadcast at all if they only log in to their mailboxes after the message has already expired. Broadcast messaging can therefore control the period of time for which a message's content is valid, but this cannot be done when a message is sent via a distribution list.

•Sender privileges—Any subscriber on the system can send a message to a public distribution list. Only users with administrative access to the AVT can send broadcast messages.

Voice Mail Number Handling

Various features within Cisco Unity Express are identified with numbers, as follows:

•Extension numbers associated with mailboxes

•Location codes identifying remote locations for voice mail networking

•Distribution lists

These numbers do not have to be mutually exclusive; for example you can define an extension 101, location code 101, and distribution list 101 on the same system. This is not a recommended configuration because it is confusing to the subscribers, but it is possible to do if needed by dial-plan considerations. When a voice message is addressed and the subscriber dials a number, Cisco Unity Express matches the number against all features identified by numbers. If there are multiple matches, the TUI prompts the subscriber to choose one of the elements to be entered into the message address.

Voice Mail Operator

Cisco Unity Express defines a system voice mail operator where calls are redirected if a caller does not respond to voice mail menus, or does not hang up after leaving a voice mail for a subscriber. The voice mail "operator" is triggered when the following voice mail prompt is reached: "If you have a mailbox on the system please press # or you will be transferred to the operator."

By default the voice mail operator is set to the AA pilot number. Alternately, you can set this to the extension of any employee in your office. To change this attribute, use the Voice Mail > Call Handling GUI window and change the "Voice Mail Operator Number" field.

AVT Operation for Voice Mail

The AVT interface offers administrative features for both the Cisco Unity Express AA and voice mail. Employees in your organization who are responsible for the following activities must have user profiles with access to the AVT defined on Cisco Unity Express (see Figure 25), regardless of whether they are also voice mail users:

•Send broadcast messages

•Manage (create or maintain membership) public distribution lists

•View private distribution lists of other subscribers

•Record spoken names on behalf of remote users entered into the local system

Voice Mail Deployment Models

Voice mail in your network can be designed as either a centralized, distributed, or hybrid deployment model. Which model is chosen depends in part on the voice mail availability you require during network outages.

The following sections summarize considerations to assess when selecting a voice-mail deployment model for your environment:

•Centralized

•Distributed

•Hybrid

•Voice Mail Failover

•Call Agent Failover

Centralized

A centralized deployment model provides for a the voice mail server that is located in a single site (central) and that is local to the employees located in that office, but remote for all employees at smaller outlying offices. Deploy Cisco Unity in a centralized model.

Cisco Unity Express 2.1 is not supported in a centralized deployment model and cannot to provide voice mail to employees that are not collocated with it in the same office. Cisco Unity Express can be used as the voice mail solution for a single site deployment (a standalone office), or in a distributed model (described in the "Distributed" section).

When Cisco Unity Express implemented with Cisco CME as the call agent, there is a 1:1 relationship between the Cisco Unity Express system and the Cisco CME system it serves (these two systems do not need to be collocated on the same router, but the relationship must be maintained and they should be collocated at the same site). You cannot configure a single Cisco Unity Express to provide voice mail to multiple Cisco CME sites, nor is it possible to configure two Cisco Unity Express servers to provide voice mail to the same Cisco CME system.

When Cisco Unity Express is implemented with Cisco CallManager as the call agent, there is a looser coupling between the physical location of the phone and the site where Cisco Unity Express is present as Cisco CallManager manages this relationship. It is technically possible therefore to have a single Cisco Unity Express provide voice mail to phones at multiple locations when under control of Cisco CallManager. However, this is not an officially supported or tested configuration and might have residual implications for the Cisco CallManager configuration components including the following:

•Codec choice used between sites

•Locations and regions configurations

•Route points

•Transcoder choices for calls

Note A network deployment featuring a single Cisco Unity Express to provide voice mail to phones at multiple locations under the control of Cisco CallManager is discouraged and is not supported by Cisco TAC.

Distributed

Although a centralized voice mail network design is often attractive from an administrative perspective, it is sometimes required to have local voice mail access, typically to increase availability during network failures. In a distributed design, the voice mail server is collocated at the same site as the employee for whom voice mail is provided. Either Cisco Unity (for large sites) or Cisco Unity Express (for small sites) can be deployed in a distributed design.

Hybrid

Many networks follow a hybrid deployment model with centralized Cisco Unity for the larger sites, and perhaps some Cisco Unity Express systems distributed at a selection of the smaller sites.

Voice Mail Failover

If Cisco Unity Express is deployed as the voice mailbox for an employee, then it is the permanent voice mailbox for that subscriber. Cisco Unity Express configuration does not allow for a deployment model in which Cisco Unity Express acts as a temporary "backup" for a permanent mailbox resident on a Cisco Unity (or other Cisco Unity Express) system elsewhere in the network. If voice mail must remain accessible during network outages, then a distributed voice mail network design should be deployed.

Call Agent Failover

When used with Cisco CallManager as the call agent, Cisco Unity Express works automatically with Cisco SRST to provide continuous access to voice mail regardless of the connectivity status between Cisco Unity Express or the IP phones and Cisco CallManager. Like the phones, Cisco SRST acts as the call agent of last resort when connectivity with Cisco CallManager is lost (primary, secondary, and tertiary Cisco CallManagers can be configured for Cisco Unity Express, just as they can for the phones). Call control automatically switches back from Cisco SRST to Cisco CallManager when contact is restored.

Note During Cisco SRST mode there are no changes in MWI state. All other Cisco Unity Express AA and voice mail functions continue to operate unchanged.

Cisco Unity Express is not consciously aware of "CallManager" versus "Cisco SRST" mode, and no configuration is required on Cisco Unity Express to enable this feature; however, the Cisco SRST router requires some configuration to determine voice mail call forward destinations for the phones and a SIP dial peer to route calls to Cisco Unity Express. Cisco Unity Express supports two means in which calls may arrive at the system—calls arriving via both mechanisms are handled at all times:

•SIP—Used for both Cisco SRST and Cisco CME as the call agent

•JTAPI—Used for Cisco CallManager as the call agent

When used with Cisco CME, Cisco Unity Express is collocated with the call agent and no failover scenarios apply.

Best Practices

The following summarizes the best practices in Cisco Unity Express voice mail design and configuration:

•On a new system, plan the license level to purchase carefully.

Cisco Unity Express licenses are not cumulative, so it is best to purchase the correct license for the number of mailboxes you expect to deploy in the office in the foreseeable future. If you purchase a 12-mailbox license to start with and then expand beyond that, you have to buy and install the 25 (or 50 or 100)-mailbox license. You cannot buy another 12-mailbox license and end up with a cumulative total of 24 mailboxes.

•On a new system, plan the appropriate default mailbox size carefully before you start entering the mailboxes into the configuration.

The total system storage depends only on the hardware platform used (AIM-CUE or NM-CUE); it does not depend on the mailbox license installed. For example, if you start with the 25-mailbox license on an NM-CUE system, the default space allotted per mailbox is about 100 hours/25 = 240 minutes. If you enter 25 mailboxes, all the storage is allocated. If you subsequently upgrade to a 50-mailbox license, there is no space left to allocate to mailboxes 26 to 50. You must change the mailbox size of each of the existing mailboxes first, then add the new mailboxes. If you plan to grow or upgrade to more mailboxes, set the mailbox default parameters (default mailbox size) appropriately to allocate the actual time you require per mailbox, as opposed to using the system default calculation, which is total storage/mailbox license number.

•There are aspects of Cisco Unity Express operation that vary depending on which call agent is deployed with Cisco Unity Express.

Most Cisco Unity Express AA and voice mail features are generic and operate the same way regardless of the deployment model used. There are some minor differences,though, between Cisco CME and Cisco CallManager operation, including the following:

–AA control of calls after a transfer—With Cisco CME, a SIP blind transfer is done and once the call is transferred, the AA script has no further control of the call. So any error branches in the AA script to handle busy, not available, or nonexistent extension conditions will never execute. Instead, Cisco CME treatments (busy tone, overflow tone, or announcements) are heard by the caller. With Cisco CallManager, a consultative transfer is done via JTAPI and the AA script retains control of the call for error condition execution.

–Rendering MWI on a phone—On Cisco CME, red light MWI can only be done for extension appearances on button 1, and a flashing icon is shown for other button appearances. This is not configurable. On Cisco CallManager, red light or flashing icon MWI can be configured for any button on the phone.

–Direct transfer to voice mail—Although Cisco Unity Express 2.1 does not explicitly support this feature, there are Cisco Unity Express 2.1 configurations that can result in direct transfer to voice mail. These methods differ for Cisco CME and Cisco CallManager. More information on this is available in the Tech Tip entitled "Transfer a Caller Directly into a Unity Express Mailbox" at the following URL: http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_tech_note09186a00802ab979.shtml

–Collocation of phones and Cisco Unity Express mailboxes—For Cisco CME there is a 1:1 relationship between the phones under control of Cisco CME router and the Cisco Unity Express system providing voice mail services to these phones. Multiple Cisco CME systems cannot be served by a single Cisco Unity Express, nor can multiple Cisco Unity Express systems serve a single Cisco CME. With Cisco CallManager, this relationship is looser. Although Cisco recommends that the phones for which the Cisco Unity Express system provides voice mail be collocated at the same Cisco Unity Express site, there is nothing in the configuration that enforces this relationship.

–Extension length—For Cisco CME, all the phone extensions associated with mailboxes must be of a fixed length. The absolute length does not matter, but they cannot vary in extension length. If they do, MWI does not operate correctly. For Cisco CallManager, this restriction does not apply and extensions can be of any length.

•Cisco Unity Express is an integrated AA and voice mail system. Although the license level explicitly references only the number of mailboxes, the AA is always available as well. However, it is your choice of which features to use. You can deploy Cisco Unity Express as an AA system only or as a voice mail system only.

•For broadcast messaging, the Cisco Unity Express default value for the "VPIM Broadcast ID" field is" vpim-broadcast." If voice mail networking with Cisco Unity systems is required, this field must be set to a numeric-only value.

•MWI for GDMs require the extension associated with the GDM to be a button appearance on the phone where MWI is needed.

•Set location IDs for voice mail networking locations to be at least three digits if you require Cisco Unity Express to interwork with a Cisco Unity system now or in the future.

•Encourage new subscribers to work through the new mailbox enrollment tutorial. This ensures that each subscriber records a greeting, records a spoken name, and changes the default PIN. The spoken name is used in many other Cisco Unity Express features (such as address confirmation and sending the spoken name with the message for header playout to the recipient at a remote system). It enhances the overall user experience of the voice mail system.

•If a subscriber must administer (and log in to) a GDM, ensure that the subscriber is assigned to be both an owner and a member of the group with which the GDM is associated.

•All subscribers who must be able to send broadcast messages must be granted access privileges to the AVT.

•Various features within Cisco Unity Express are identified with numbers, such as extension numbers, network location codes, and distribution lists. To optimize the end user experience of addressing messages, it is best to configure numbers for these items that do not overlap.

•For user IDs to appear in the dial-by-name feature, a user profile definition must exist on Cisco Unity Express. A mailbox need not necessarily be assigned to a user with a profile defined for the purposes of dial-by-name functionality; however, if spoken name confirmation is required for such a user, a mailbox is requried.

•They do not need to have a mailbox assigned, although if spoken name confirmation for these users is required, that can only be done via a mailbox.

•Configure the Cisco Unity Express system to do regular backups so that you can recover voice mail configuration and message content after upgrades or destruction media failures.

•Cisco Unity Express subscriber PINs do not expire by default. For added security, it is recommended that you configure a suitable expiration time frame in the Cisco Unity Express system policy (use the Defaults > User GUI window).

•When making configuration changes to the system, be sure to make the configuration permanent by doing either a "write" statement from the Cisco Unity Express CLI, or choosing the Save Unity Express Configuration button on the Administration > Control Panel GUI window. If Cisco Unity Express reboots or loses power with unsaved changes, the last saved configuration will be loaded. Cisco Unity Express follows the Cisco IOS router model of a startup configuration and a running configuration.

•Although the Cisco Unity Express GUI allows you to look at the status of an individual mailbox, it does not have a single window overview with a consolidated listing of all the mailboxes on the system. If this view is necessary for tracking or monitoring purposes the show voicemail mailboxes command can be used to obtain needed information:

cue# show voicemail mailboxes 

OWNER         MSGS NEW SAVE DEL BCST MSGTIME  MBXSIZE   USED

"User1"        3    2   1    0   1    77       5520      1 %

"User2"        0    0   0    0   0    5        5520      1 %

"User3"        1    0   1    0   1    21       5520      1 %

"User4"        2    1   1    0   0    47       5520      1 %

"User5"        0    0   0    0   1    0        5520      0 %

"User6"        1    1   0    0   1    21       5520      1 %