System Administration Guide for Cisco Unity Connection Release 10.x

Single Site Automated Attendant Search Space Example

CompanyA has a single Unity Connection server that is set up as an automated attendant to handle calls to the customer service department as well as handling user to user voice messages. All employees at CompanyA have a primary extension in the Employee partition. Employees who work in the customer service department also have alternate extensions in the Customer Service partition.

The Unity Connection server is configured with the following search spaces and associated partition membership:

In addition, the routing rules that outside callers reach are configured to use the Customer-Service-SS search space as their search scope. The system call handlers and directory handlers that outside callers interact with are configured to inherit their search scope from the call. All users use the Employees-SS as their search scope, and the routing rules that users reach when they call Unity Connection are configured to use the Employees-SS as their search space.

In this example, when users call and sign in to Unity Connection, they can address messages or place calls to any other user at the company. However, when outside callers call Unity Connection and reach the automated attendant, they can reach only those employees who have alternate extensions in the Customer Service partition.

To extend the example, CompanyA might have two operators who share the same extension: an internal operator with extension 411 in the Employee partition, and an external operator with extension 411 in the Customer Service partition. When outside callers attempt to reach extension 411, Unity Connection routes them to the external operator, because that is the only operator who appears in a partition in the Customer-Service-SS search space. When employees call and sign in to Unity Connection and attempt to reach extension 411, Unity Connection routes them to the internal operator, because the Employee partition in which this operator extension appears is listed earlier in the partition membership of the Employees-SS search space than the Customer Service partition in which the external operator extension appears.

Multiple Site Search Space Example

CompanyB has three digitally networked Unity Connection locations serving three sites: Headquarters, Regional-East, and Regional-West.

The configuration is as follows:

• Unity Connection is configured with the following search spaces and associated partitions:

• The following user accounts are set up:

• There is a VPIM server that is configured as a VPIM location on the Headquarters server: VPIM-South. This VPIM location has a Dial ID of 8468 and is configured to allow blind addressing, to belong to the Primary partition, and to use the Headquarters-SS search space.
• The Attempt Sign In direct routing rule and the Attempt Forward forwarded routing rule on each server are configured to use the same search space as the users on that server. (For example, the rules on the Headquarters server use the Headquarters-SS search space.)

In this example, Unity Connection users can address other Unity Connection users at their own site using 4-digit extensions; users can address anyone at the company using 8 plus a 7-digit extension. Users can blind address messages to a VPIM mailbox by entering 8468 plus the mailbox number on the remote system. Messages sent by users at the VPIM-South VPIM location can be delivered to any CompanyB user in the HQ, Primary, RE, or RW partitions.

For example, if Alex Abade addresses a message by entering extension 3002 on the phone keypad, Unity Connection returns Chris Brown as the match. If Alex addresses a message by spelling SMITHR on the phone keypad (764847), Unity Connection returns both Pat Smith and Robin Smith, because both names match the 764847 spelling. If Alex addresses a message by saying “Robin Smith,” Unity Connection returns Robin Smith.

The phone system can be set up to identify internal callers either by their 4-digit extension or the 8 plus 7-digit extension. Each caller must call their home server to sign in to Unity Connection. For more information about setting up cross-server sign-in and transfers, see the “Cross-Server Sign-In, Transfers, and Live Reply in Cisco Unity Connection 10.x” chapter of the Networking Guide for Cisco Unity Connection Release 10.x , at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/networking/guide/10xcucnetx/10xcucnet050.html .

Search Spaces and Users

When a user has signed in to Unity Connection, the search scope of the user defines the objects that the user can reach when:

• Addressing a message by extension
• Addressing a message by name
• Adding members to a private distribution list
• Adding names to an addressing priority list
• Placing a call to another user by saying the name
• Addressing a message to a VPIM contact
• Blind addressing a message to a VPIM location

Users can reach only those objects that are in a partition that is part of the search space that is defined as the search scope for the user. This search space need not include any partitions that contain the primary or alternate extensions of the user. Unity Connection applies the search scope of the user whether the user is interacting with Unity Connection by phone (using phone keypad keys), using voice commands, or using a visual client such as the Cisco Personal Communications Assistant (PCA).

If a user addresses a message by extension, and there are overlapping extensions in different partitions in the search space, Unity Connection searches the partitions in the search space in the order that they appear in the Assigned Partitions list in Cisco Unity Connection Administration, and returns the first result found.

Note that if a user receives a message from a sender whose partition is not in the search space of the receiving user, the recipient cannot reply to the sender. If the message is sent to multiple recipients, and the user replies-all, the user receives non-delivery receipts for any recipients who are not in partitions in the search space of the user (if Unity Connection is configured to send receipts)

Search Spaces and Call Routing Rules

When a call comes in to Cisco Unity Connection, it is first checked against the applicable routing rules table, depending on whether the caller dialed directly into Unity Connection or was forwarded from an extension. When Unity Connection matches the call to a routing rule in the applicable table based on the parameters of the call, the configuration of the routing rule determines the initial search scope of the call. Other objects, such as system call handlers, may later change the search scope of the call when the call is routed to them, but the initial scope is set by the call routing rules.

To facilitate setting the correct search scope on a call routing rule, you can set up routing rule conditions to select a rule based on the port of the incoming call, the phone system, the dialed number, or other criteria. If you are setting up multiple partitions and multiple search spaces, you must carefully consider the impact of the search scope that is configured for each call routing rule. Note the following considerations related to setting the search scope with call routing rules:

• Unity Connection uses the search space defined as the initial scope of the call to identify whether the call is from a user, and if so, which user. If a user calls from an extension that is in a partition that is not a member of the search space set as the initial search scope for the call, the call is not identified as coming from the user. If the extension of the user overlaps with an extension in another partition that also appears in this search space, the call is identified as coming from the first object that Unity Connection finds when searching the partitions in the order that they appear in the search space.
• Users who call to sign in to Unity Connection do not have their search scope set to the search space defined for their user profile until they have successfully completed the sign-in process.

If users are segmented into different partitions, and extensions overlap between partitions, you must consider how Unity Connection recognizes users by extension when they call Unity Connection and attempt to sign in. For example, if Kelly Bader in Kansas City and Chris Jones in Chicago both use extension 3001, you must set up your call management plan such that when Kelly calls Unity Connection from extension 3001, Unity Connection recognizes the extension as belonging to Kelly and checks the password against the appropriate user profile; likewise when Chris calls from extension 3001. There are multiple ways to set up the routing rules to handle this. For example, you can set up a direct routing rule based on a call coming from a particular phone system, so that calls from the phone system in Kansas City match one routing rule, setting the scope of the call to a search space in which the partition that Kelly is in appears before the one that Chris is in (or the partition that Chris is in does not appear at all), and then set a similar direct routing rule for calls from Chicago. You can also set up different pilot numbers for Kansas City and Chicago, and use the Dialed Number routing rule condition to distinguish between two different routing rules that are set to use the two different search spaces.

Search Spaces and System Distribution Lists

Because each system distribution list belongs to a partition, you can use search spaces to limit user access to send messages to lists. By placing a distribution list in a partition that is not part of the search scope of a particular group of users, these users are not able to find the distribution list to address messages to it. For example, you can create a new partition called “Distribution Lists Partition” and configure the allvoicemailusers, allvoicemailenabledcontacts, and undeliverablemessages to use this partition. To grant certain users access to send to these lists, you can create a new search space that includes both the default partition and the “Distribution Lists Partition,” and assign this search space as the search scope for those users.

Search Spaces and System Call Handlers

Cisco Unity Connection uses the call handler search scope to match extensions that are dialed from the call handler to users, administrator-defined contacts, and remote contacts at VPIM locations. You can choose to set the scope of the handler to either inherit the search scope that is already set on the call (from a previous handler or from a call routing rule), or to use the particular search scope that you specify.

You can use call handlers to change the search scope of a call based on caller input. For example, you can set up a multiple-site automated attendant using an introductory call handler that offers callers a menu of site choices (“Press 1 for Chicago; Press 2 for New York”). One-key dialing rules configured for this call handler send callers to either of two call handlers, which set the search scope of the call to the appropriate search space for the site (Chicago or New York) and send the call directly to the shared opening greeting call handler. After the caller makes a selection, if the caller reaches any call handlers or directory handlers that are configured to inherit the search scope of the call, these handlers are scoped correctly to reach only the users and other objects at the appropriate site.

Search Spaces and Directory Handlers

You can configure the scope of a directory handler to define the objects that callers who reach the directory handler can find or hear. For phone directory handlers, you can set the scope to the entire server, to a particular class of service, to a system distribution list, or to a search space (either inherited from the call or specified for the directory handler). For voice-enabled directory handlers, you can set the scope to the entire server or to a search space (either inherited from the call or specified for the directory handler).

When callers search a directory handler for a particular name, if the scope of the directory handler is set to a search space, Cisco Unity Connection searches each partition in the search space and returns a list of all of the objects that match the name.

Search Spaces and Interview Handlers

Each interview handler is associated with a partition, so that it can be included in a search space and callers can reach it from other parts of the conversation. Because interview handlers do not involve dialing or addressing to users or other objects, they do not have a search scope defined.

Search Spaces and Networking

When you network a Unity Connection server with other Unity Connection locations, the partitions and search spaces that are configured on the server replicate to all other Unity Connection locations on the network. A Unity Connection network supports up to 10K partitions and 10K search spaces shared among all of the locations in the network.

If you plan to connect multiple Unity Connection servers in a network, it is important to note that when you initially set up the network between the servers, users on one server are not able to address messages to users on other servers, because the users on each server are in separate partitions and use search spaces that do not contain partitions with users on the other server. At a minimum, to allow users to address to users on other servers, you must add the partition of the remote Unity Connection server to the search space that local users are using.

Search Spaces and VPIM Locations

Each VPIM location belongs to a single partition. If a VPIM location allows blind addressing, and the partition to which the location belongs is in the search space for a user, the user can blind address to a user on the remote VPIM system. To blind address, the user addresses the message to the Dial ID of the VPIM location followed by the remote user mailbox number. For example, to reach mailbox 1000 at VPIM location 555, the user would address the message to 5551000.

The partition of the VPIM location is used as the partition of automatically-created VPIM contacts if the VPIM location is configured for automatic contact creation. However, you can change the partition of VPIM contacts independent of the associated VPIM location in Cisco Unity Connection Administration. A Unity Connection user can address a message to a VPIM contact by spelling or saying the contact name or by saying “<Name> at <Location>” provided that the contact belongs to a partition that is in the search space of the Unity Connection user.

Each VPIM location also has a search scope. When Unity Connection receives a message from a sender at a VPIM location, Unity Connection searches the search space that is defined as the search scope for the location to determine the message recipient by matching the extension in the To: address field with a Unity Connection user.

Note that when users address messages to a VPIM mailbox by entering a VPIM location Dial ID plus a remote user mailbox number, or when voice-recognition users say a name and location (for example, “John Smith in Seattle”), the action is allowed or denied based on the partition of the VPIM location. However, when users address to a VPIM contact using spell-by-name or by entering the local extension of the contact, or when voice-recognition users say the name of a contact without the location (for example, “John Smith”), the action is allowed or denied based on the partition of the VPIM contact, regardless of whether the partition of the VPIM location is out of scope for the user.

Search Spaces and Administrator-Defined Contacts

Each administrator-defined contact belongs to a partition. When a contact is configured with phone numbers that callers can use to call the contact using voice commands, voice-recognition users whose search space includes the partition of the contact are able to call the contact; users whose search space does not include this partition are not able to call the contact. In addition, the contact is reachable by callers who reach any voice-enabled directory handler whose search scope uses or inherits a search space that includes this partition (or if the directory handler search scope is set to the entire server).

Finding Objects Based on Partition in Cisco Unity Connection Administration

In Cisco Unity Connection Administration, you can use the Search Limits fields on the search pages for the objects that have partition membership to locate the objects of that type that belong to a particular partition.

Use the following procedure to limit a search by partition.

To Limit a Search by Partition

Step 1 In Cisco Unity Connection Administration, go to the applicable Search page.

Step 2 In the Limit Search To list, select Partition .

Step 3 In the Where Name Is list, select the name of the partition in which to find objects.

Note When searching for users, you can also select whether to display only the primary extension in the partition, or both the primary extension and any alternate extensions that appear in the partition. If you select to display both the primary extension and any alternate extensions, multiple records may display for a single user in the search results.

Step 4 Optionally, to further limit the search, in the search fields, indicate the search parameters, and enter the applicable characters to search for. Select Find .

Finding Users Based on Partition in Cisco Unity Connection Serviceability

You can use the Dial Search Scope report in Cisco Unity Connection Serviceability to get a list of all users who are members of each search space in the Cisco Unity Connection directory. For each search space, the report lists each partition in the search space, and for each partition, the report lists each user and the corresponding user extension (primary or alternate) that is in the partition.

For more information on generating and viewing reports, see the Administration Guide for Cisco Unity Connection Serviceability Release 10.x , at http://www.cisco.com/en/US/docs/voice_ip_comm/connection/10x/serv_administration/guide/10xcucservagx.html .