Searching and Addressing
See the following sections:
•Directory Handler Searches
•Using Traces to Determine Which Search Space Is in Use During a Call
Directory Handler Searches
Use the troubleshooting information in this section if callers report that they are unable to locate one or more users in a directory handler. See the following possible causes:
•The users are not configured to be listed in the directory. Verify the List in Directory setting on the Edit User Basics page for each user in Cisco Unity Connection Administration, or use the Bulk Edit Utility to configure the setting for multiple users at the same time.
•The search scope of the directory handler does not include the users. See the "Users Are Not Found in the Search Scope of the Directory Handler" section.
•For voice-enabled directory handlers, the voice-recognition engine does not recognize the names. See the "Voice Commands Are Recognized, But Names Are Not" section on page 20-2.
Users Are Not Found in the Search Scope of the Directory Handler
If callers are unable to find specific users in a directory handler, check the search scope of the directory handler on the Edit Directory Handler Basics page in Cisco Unity Connection Administration. The search scope of a phone directory handler can be set to the entire server; to a specific class of service, system distribution list or search space; or to the search space of the call at the point that the caller reaches the directory handler. The search scope of a voice-enabled directory handler can be set to the entire server, to a specific search space, or to the search space of the call at the point that the caller reaches the directory handler.
If the search scope is set to the entire server, the user or users must be homed on the server on which the directory handler resides in order to be reachable from the directory handler.
If the search scope is set to a specific class of service, system distribution list, or search space, you can use Connection Administration to determine whether the target users belong to the class of service or distribution list or to a partition that is a member of the search space.
If the search scope is set to inherit the search space from the call, determine which search scope is in use when callers have difficulty reaching users in the directory handler. Note that depending on how the call comes in to the system and is routed, the search scope can differ from one call to another and can change during the course of the call. See the "Using Traces to Determine Which Search Space Is in Use During a Call" section for instructions on using traces to determine the inherited search scope.
Message addressing involves the ability to select a desired recipient or recipients when creating a new message. Use the troubleshooting information in this section if users report that they are experiencing difficulties with message addressing. See the following:
•Users Cannot Address to Desired Recipients
•Users Cannot Address to a System Distribution List
•Unexpected Results Are Returned When a User Addresses by Extension
Note For additional information about troubleshooting message addressing when it involves remote recipients at VPIM locations or at other digitally networked Cisco Unity Connection locations, see the "Networking" chapter.
Users Cannot Address to Desired Recipients
If a user is unable to find one or more desired recipients when attempting to address a message, start by verifying that the recipient user or contact account exists and that the name spelling or extension that the user is entering is correct.
If the user is attempting to blind address a message to a VPIM location by entering a number that is made up of the VPIM location DTMF Access ID and the mailbox number of the recipient, or by saying the digits of the mailbox number and the display name of the VPIM location (for example, "five five at Seattle office"), confirm that blind addressing is enabled for the VPIM location by checking the Allow Blind Addressing check box on the VPIM Location page in Cisco Unity Connection Administration.
If you have verified that the recipient account exists and matches the user search criteria or that blind addressing is enabled, and the user still cannot address to the desired recipient, the most likely cause is that the user search space does not include the partition of the target user, VPIM contact, or VPIM location. If the VPIM contact partition does not match the partition of the VPIM location to which the contact belongs, the search results depend on the method used to address the message as well as the partition and search space configuration. When users address messages to a VPIM mailbox by entering a VPIM location DTMF Access 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 by 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.
Users Cannot Address to a System Distribution List
When a user cannot address messages to a system distribution list, consider the following possible causes:
•The user must be given the correct class of service rights on the Class of Service > Edit Class of Service page in Cisco Unity Connection Administration. The class of service that the user is assigned to must have the Allow Users to Send Messages to System Distribution Lists check box checked.
•The user must know how to address to the list. If the user is using the phone keypad conversation, the user can enter the display name or extension of the list. If the user is using the voice-recognition conversation, the user can say the display name or one of the alternate names defined for the list in Connection Administration.
•As with other types of addressing, in order for a user to address messages to a system distribution list, the list must belong to a partition that is a member of the search space that is defined as the user search scope. Note that the distribution list members receive the message regardless of whether they are individually addressable in the search scope of the sending user.
Unexpected Results Are Returned When a User Addresses by Extension
If a user addresses a message by extension and hears an unexpected match, the most likely cause is the search space configuration. To make a match by extension, Cisco Unity Connection checks the search space of the user who is addressing the message. Connection searches the partitions in this search space in the order that they appear in the Assigned Partitions list in Cisco Unity Connection Administration, and returns the first result found. If your dial plan includes overlapping extensions, it is possible for the user to enter an extension that matches multiple users or other Connection objects and hear a match result that is different from what the user expects.
To resolve the issue, you may need to review the order of partitions in the search space that is assigned to the user, either in Connection Administration or by using the Dial Plan Report and Dial Search Scope Report in Cisco Unity Connection Serviceability. If the search space is set up correctly according to your dial plan, you can recommend that the user address messages by spelling or saying the name of the recipient; in this case, if there are multiple matches on the name, Connection returns each match.
Using Traces to Determine Which Search Space Is in Use During a Call
The search scope of a call is initially set to a particular search space by the call routing rule that first processes the call, although the scope may change during the course of the call.
To determine which search space is being used at each point in a call, enable the CDE micro trace (level 4 Search Space). For detailed instructions on enabling the traces and viewing the trace logs, see the "Diagnostic Traces" chapter.