Cisco Unity Connection provides the following elements for managing incoming and outgoing calls:
Answer calls and can take messages; provide menus of options (for example, “For customer service press 1, for sales press 2...”); route calls to users and to other call handlers; and play audiotext (prerecorded information).
Provide directory assistance by playing an audio list that users and outside callers use to reach users and to leave messages.
Collect information from callers by playing a series of questions and then recording the answers.
Call Routing Tables
Allow you to define how calls are initially routed, based on criteria such as the phone number of the caller and the schedule. When you have set up call handlers, interview handlers, and directory handlers, as well as extensions for users, you can route calls to the applicable person or handler by modifying the call routing tables.
Control outgoing calls by allowing you to specify the numbers that Connection can dial for transferring calls, for notifying users of messages, and for delivering faxes.
Schedules and Holidays
Define business/nonbusiness and holiday hours for the organization, for the purpose of controlling which set of call routing rules, greetings, or transfer options is currently active.
All of these elements can be used as building blocks; you can use or customize the default objects in Connection, or add new objects and combine them to create the caller experience.
Revised May 2009
Call handlers answer calls, greet callers with recorded prompts, provide callers with information and options, route calls, and take messages. They are a basic component of Cisco Unity Connection. Your plan for call handlers can be simple, using only the predefined call handlers, or you can create up to 2,500 new call handlers. You may want to use call handlers in the following ways:
As an automated attendant—A call handler can be used in place of a human operator to answer and direct calls by playing greetings and responding to key presses. The automated attendant can provide a menu of options (for example, “For Sales, press 1; for Service, press 2; for our business hours, press 3.”).
To offer prerecorded audiotext—A call handler can be used to provide information that customers request frequently (for example, “Our normal business hours are Monday through Friday, 8 a.m. to 5 p.m.”), or to play a prerecorded message that all callers hear before they can interact with the system.
As a message recipient—A call handler can be used to take messages for the organization (for example, “All of our customer service representatives are busy. Please state your name, phone number, and account number, and we will return your call as soon as possible.”).
To transfer calls—A call handler can be used to route callers to a user (for example, after hours, you could transfer calls that come to a technical support call handler directly to the cell phone of the person who is on call), or to another call handler.
Directory handlers provide directory assistance that callers can use to reach Cisco Unity Connection users who have mailboxes and who are listed in the directory. When a caller searches for a user name or part of a name, a directory handler looks up the extension and routes the call to the appropriate user. Callers can also enter an extension to place a call from a directory handler; the extension is checked against the applicable outcalling restriction table if the caller is a user, or against the Default Outdial restriction table if the caller is an outside caller.
There are two types of directory handlers:
Callers enter search information or extensions by using the phone keypad. For this type of directory handler, you can specify how it searches for names, what it does when it finds one or more matches, and what it does when it detects no caller input.
(For Cisco Unity Connection systems with the voice-recognition option only).
For this type of directory handler, callers say the first name and last name of the Connection user that they want to reach, or enter an extension by saying the individual digits in the extension. In addition to searching by first and last name, the voice directory handler includes alternate names in searches. Callers can narrow down the search by saying the name and city or department of the user (or both) if these fields are defined on the Edit User Basics page in the user profile.
Connection users who are listed in the directory are available to outside callers as names that can be reached. System contacts are only available to Connection users who are logged on to Connection, and personal contacts are only available to the Connection users who defined them.
Note that for this type of directory handler, users cannot be accessed by using directory handlers unless they have a display name specified and the List in Directory check box is checked for them on the User Basics page.
Interview handlers collect information from callers by playing a series of questions that you have recorded, and then recording the answers offered by callers. For example, you might use an interview handler to take sales orders or to gather information for a product support line.
When a call is routed to an interview handler, the interview handler plays the first recorded question, then plays a beep, then records the answer. Cisco Unity Connection stops recording either when the response reaches the maximum recording time that you have specified, or when the caller stops speaking. Connection then plays the second question, and so on. When all the answers have been recorded, they are forwarded as a single voice message, with beeps separating the answers, to the recipient that you designate.
Call routing tables are used to route incoming calls to the operator or to specific users, call handlers, directory handlers, or interview handlers. In addition, call routing tables are used to route users to the user logon conversation.
Cisco Unity Connection has two call routing tables—one for direct calls and one for forwarded calls—that handle calls from users and from outside callers. Each table contains predefined routing rules, and you can create additional rules to route calls as needed. Set up your directory handlers, call handlers, and interview handlers first, and then modify or create call routing rules for each table as needed to route incoming calls correctly.
Direct rules handle calls from users and outside callers that are dialed directly to Connection. The predefined direct routing rules are:
Attempt Sign-In—Calls from users are routed to the user logon conversation.
Opening Greeting—Calls from outside callers are routed to the Opening Greeting.
Forwarded rules handle calls that are forwarded to Connection from either a user extension or from an extension that is not associated with a user account (such as a conference room). The predefined forwarded routing rules are:
Attempt Forward—All calls forwarded from a user extension are routed to the user greeting.
Opening Greeting—Calls forwarded from an extension that is not associated with a user account are routed to the Opening Greeting.
You can add new rules and change the order of the rules in the respective routing tables. You can change the order of the Attempt Sign-In and Attempt Forward rules relative to additional rules that you add in the respective routing tables, but the Opening Greeting rule is always the last entry for both tables. You cannot delete the predefined rules.
Call routing tables consist of a series of rules that let you route incoming calls based on the information that Cisco Unity Connection may have about a call, such as the calling phone number (ANI or caller ID), the trunk or port on which the call comes in, the dialed phone number (DNIS), the forwarding station, and the schedule.
When Connection receives a call, it first determines if it is a direct or forwarded call based on the call information that is sent by the phone system, and then applies the applicable call routing table. If the call information matches all of the conditions for the first rule, the call is routed as specified in the rule. If any of the conditions specified in the first rule are not met, the call information is then compared to the conditions of the second rule, and so on, until a rule is found that matches all the characteristics of the call.
The integration between the phone system and Connection determines the information that is provided about a call (for example, call type, port, trunk, calling number, and dialed number). The schedule is determined by the date and time that the call is received.
The following examples show how call routing tables are used in Connection to route calls.
In Table 4-1, calls that meet the criteria specified in the Operator rule settings—any direct external call received while the Weekdays schedule is active—are transferred to the operator. Calls that do not meet this criteria are routed as specified by one of the other call routing rules in the table. In this case, any direct external calls received on the weekends are routed to the Opening Greeting, according to the Opening Greeting call routing rule.
Table 4-1 Direct Calls Call Routing Table
Send Call To
Attempt transfer for operator
Attempt transfer for Opening Greeting
In Table 4-2, calls forwarded from specific extensions—1234 and 5678—are routed according to the Product Info and Customer Service rules, respectively. Calls that do not match the extension (or forwarding station) in either of the first two rules are routed according to the two remaining rules.
Using Routing Rules with the Route from Next Call Routing Rule Action
In a user profile or call handler, you can configure the After Greeting action, the After Message action, or the action of a caller input key to apply the Route from Next Call Routing Rule action to calls. This action causes Cisco Unity Connection to continue processing the call according to the applicable call routing table (direct or forwarded, depending on how the call was received from the phone system) starting at the rule immediately after the rule that Connection previously applied to the call. If the call was already processed according to the final rule in the table, the final rule is applied again.
For example, you might want to have Connection always play a standard greeting or legal disclaimer to all callers, whether they call Connection directly or are forwarded by an extension. The greeting plays before callers can take any other action—for example, leaving a message or signing in. To do so, you do the following tasks:
1. Create a new call handler and record the message as the alternate greeting.
2. Enable the alternate greeting, configure it to ignore caller input during the greeting, and then configure the After Greeting action with the Route from Next Call Routing Rule call action.
3. Add a new direct call routing rule to send all direct calls to the new call handler (with Go Directly to Greetings selected) and verify that the rule appears at the top of the direct call routing table.
4. Add a new forwarded call routing rule to send all forwarded calls to the same new call handler (again with Go Directly to Greetings selected) and verify that the rule appears at the top of the forwarded call routing table.
Once the system is configured in this way, all calls—no matter where they come from or how they get to the system—hear this greeting in its entirety and then proceed directly to their original destination.
Restriction tables allow you to control which phone numbers users and administrators can use for:
Transferring calls—including both the numbers users can enter for transferring their calls, and the numbers that outside callers can enter when using Caller system transfers. (For more information on Caller system transfers, see the “System Transfer Overview” section.)
Recording and playback by phone from Cisco Unity Connection applications, when the phone is the designated recording and playback device in the Media Master.
Delivering faxes to a fax machine.
Sending message notifications.
For example, you can specify that users have calls transferred only to internal extensions or that faxes are delivered only to local phone numbers. Restriction tables are applied regardless of how a user or administrator accesses Cisco Unity Connection. They do not affect the phone numbers that users can dial when they are not logged on to Connection.
Each class of service specifies for its members a restriction table for call transfers, one for message notification, and one for fax deliveries. The restriction table can be the same for all three, or different for each. Because users without mailboxes (typically, administrators) are not assigned to a class of service, Connection applies the default restriction tables (default transfer, default outdial, or default fax) to actions taken by these types of users, including actions taken on behalf of other users.
When a user uses the Cisco Unity Assistant or the Cisco Unity Connection conversation to attempt to change a phone number that is used for call transfer, message notification, or fax delivery, or when users use Caller system transfers to transfer to a number that they specify, Connection applies the applicable restriction table to verify that the phone number entered is allowed. The same thing happens when an administrator uses Cisco Unity Connection Administration to attempt to change a phone number that is used for message notification or call transfer. In each case, the restriction table used is the one associated with the user or administrator who is changing the number.
For example, if a user uses the Cisco Unity Assistant to enter a phone number to set up a message notification device, Connection applies the restriction table that is associated with the class of service of that user, and displays an error message if the phone number is not allowed. But when an administrator changes a message notification number for a user by using Cisco Unity Connection Administration, Connection applies the default restriction table—in this example, the default outdial table—not the restriction table that is associated with the class of service of the user. Therefore, an administrator can, when necessary, override the limitations of the class of service of a particular user.
Each row of a restriction table is made up of a dial string. Each dial string consists of a call pattern and a setting that specifies whether numbers that match the call pattern are permitted for use. The restriction table is applied when a user or an administrator attempts to change a number that is controlled by a restriction table, not when Connection tries to complete a transfer or delivery. To protect Connection from toll fraud and unauthorized use when users use Caller system transfers, users must log on to Connection, enter the number that they want to transfer to, and Connection performs the transfer only when the Default System Transfer restriction table permits it.
When a restriction table is applied to a number (such as a pager number for a message notification), Connection compares the number with the call pattern of the first dial string in the restriction table. If the number does not match the call pattern, Connection then compares the number with the call pattern in the second dial string, and so on, until it finds a match. When Connection finds a match, it either permits or restricts the use of the number as specified in the dial string.
Restriction tables are commonly used to permit or restrict the use of the following:
Specific numbers, such as an extension.
Numbers that are greater than or less than a specific length.
Numbers that contain a specific digit or pattern of digits, such as an external access code followed by a long-distance access code.
For example, the restriction table in Table 4-3 restricts most long distance phone numbers, but permits extensions starting with “91.” In this case, if a user enters “9123” as a transfer number, Connection first compares the number to the call pattern in Dial String 0, which restricts all numbers that begin with “91” and are followed by at least seven digits. Because the number entered does not match the call pattern, Connection then compares the number to Dial String 1, which restricts all numbers that begin with “9011” and are followed by at least seven digits. Finally, Connection compares the number to the last dial string, which contains the wildcard character that matches all numbers of any length. Because the Allow This String field is set to Yes for this dial string, Connection permits this number to be used.
Table 4-3 Example 1
Allow This String
The restriction table in Table 4-4 restricts long distance phone numbers and numbers with fewer than four digits. In this example, “9” is the external access code for the phone system, and “1” is the long-distance access code. Dial String 0 restricts any number beginning with “91,” while numbers fewer than four digits in length are restricted by Dial String 2. Thus, the only numbers permitted by this restriction table have at least four digits, and are not long distance phone numbers.
Table 4-4 Example 2
Allow This String
Schedules and Holidays
Schedules (and associated sets of holidays) are one of the variables that Cisco Unity Connection uses to manage calls: call handler transfer rules can be varied based on a schedule and schedules can be applied to routing rules to change call routing patterns for different time periods. Schedules also affect when some user and call handler greetings play.
Connection offers two predefined schedules: All Hours, and Weekdays, both of which can be modified. (By default, the Weekdays schedule is configured to observe standard hours from 8 a.m. through 5 p.m. Monday through Friday, and to observe the predefined Holidays schedule, which does not contain any dates or times.)
For each schedule that you create or modify, you can identify multiple ranges of hours and days that make up the standard and closed hours, and associate a holiday schedule that defines specific holiday dates and times:
The hours and days that make up the normal business hours, when the organization is open. Standard hours can include multiple time ranges and different time ranges on different days. (For example, standard hours for an organization might be Monday through Friday from 8 a.m. to 12 p.m. and 1 p.m. to 5 p.m., to accommodate a lunch break, and Saturday from 9 a.m. to 1 p.m.)
Standard transfer rules are in effect during the days and time ranges you add to the standard schedule; standard user and call handler greetings play during standard hours.
The hours and days not identified as standard hours are considered nonbusiness hours, when the organization is closed.
Closed user and call handler transfer rules operate at all times not specified by the standard schedule—including holidays; closed user and call handler greetings play according to the closed schedule.
When a Holiday setting is in effect, Connection plays holiday greetings (if enabled) and observes closed hours transfer rules. You can set up several years of holidays at a time. Because many holidays occur on different dates each year, confirm that the holiday schedule remains accurate annually.
Closed user and call handler transfer rules operate at all times not specified by the standard schedule—including holidays; holiday greetings for users and call handlers also play during this time period.
The following example uses the default Cisco Unity Connection automated attendant configuration to illustrate a call flow through various call management elements. It illustrates some of the default behavior you can expect if you have not changed the call management configuration after installing Connection.
An Outside Caller Calls Cisco Unity Connection During Business Hours
A caller who does not have a Connection mailbox dials the main Connection phone number at 9:00 a.m. on a Monday morning.
1. Information from the phone system indicates that the call is a direct call from an outside caller. Connection checks the call routing rules for a rule that matches the call. The Direct routing rules table contains two entries: Attempt Sign In and Opening Greeting. For the Attempt Sign-In rule, Connection attempts to match the caller phone number with the extension or alternate extension of a Connection user. When this fails, Connection tries the next routing rule, the Opening Greeting rule.
2. The Opening Greeting call routing rule matches any incoming call at any time of day. It is configured to attempt to route the call to the Opening Greeting call handler.
3. Connection checks the transfer option settings for the Opening Greeting call handler. Because the call came in during the Weekdays active schedule, the standard transfer options apply. These specify to send the call to the greeting for this call handler. (Note that if the Opening Greeting call routing rule had been configured to send the call to the greeting for the Opening Greeting call handler rather than attempting to transfer to it, this step would be skipped).
4. Because the call came in during the Weekdays active schedule from a phone number that did not match an internal Connection user, Connection plays the standard greeting for the call handler: “Hello: Cisco Unity Connection Messaging System. From a touchtone phone you may dial an extension at any time. For a directory of extensions, press 4. Otherwise, please hold for an operator.”
5. While the greeting plays, as the greeting indicates, the caller can enter digits to reach a user extension. The caller input settings on the Opening Greeting call handler also define several one-key dialing actions that can be taken—for example, when the caller presses key 4, Connection is configured to send the call to the System Directory Handler if no other keys are pressed within the time configured to wait for additional digits.
6. If no digits are entered, Connection proceeds with the after greeting action for the Standard greeting on this call handler, which is configured to attempt to transfer the call to the Operator call handler.
7. The Operator call handler is also configured for the Weekdays active schedule, and once again, Connection checks the standard transfer options for the call handler, which specify to transfer to the call handler greeting. The greeting plays: “Sorry, the operator is not available.”
8. The after greeting action for this greeting directs Connection to take a message. The message settings for this call handler specify that the Operator user receives the message, and that after the caller leaves the message, Connection should hang up.