When a user dials the pilot number of a Unity Connection location that is not the home server of the user, the answering location processes the call according to its call management plan. A search space is assigned to the call by the first call routing rule that the call matches. At each subsequent processing step, the search scope of the call may change. Unity Connection uses the search space that is assigned to the call at the point that the call reaches the Attempt Sign-In conversation to identify which user is trying to sign in. If a user calls from an extension that is in a partition that is not a member of this search space, 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 in which they appear in the search space. Check the direct routing rules on each Unity Connection location that handles incoming sign-in calls from remote users to determine the search space that is set by the rule or other call management object that sends calls to the Attempt Sign-In conversation. If the partitions that contain remote users are not a part of this search space, cross-server sign-in does not work, even if it is enabled.

Also note that for cross-server calls from one Unity Connection location to another Unity Connection location, a mismatch between the search space that is applied to the call on the originating location and the search space that is applied on the receiving location can cause problems for cross-server sign-ins and cross-server transfers. A match could be made on the search scope on the originating location that cannot be made on a different search scope on the receiving location. For this reason, we recommend that you verify that the same search scope is configured on both originating and receiving locations. For example, call routing rules can be used to direct cross-server calls on the receiving location to the appropriate search space based on the cross-server dial string that is used to reach that location.

For cross-server live reply, as with any live reply attempt, a Unity Connection user can only call the sender if the sender is in a partition that is a member of the search space configured for the user.

When you are configuring an HTTPS network, use the following task list to enable cross-server sign-in. The cross references take you to detailed procedures.

1. Determine which locations are the originating locations and which are the receiving locations for cross-server sign-in. Often a single location is designated as the originating location that all users call into from outside the organization, and all other location are designated as receiving locations; however, this does not have to be the case. A single location also may be both an originating location and a receiving location.

2. For each originating location, make a list of the phone numbers that the location must dial to reach the receiving location servers.

   Note	You can enter only one dial string for each receiving location. If the originating location is configured for multiple phone system integrations, you need a dial string that all phone system integrations can use to reach the receiving location.

3. Configure each receiving location so that it can handle incoming cross-server handoff requests.

   • If the receiving location is a Unity Connection server, see the “Configuring a Unity Connection Receiving Location to Accept Cross-Server Handoff Requests” section.

4. For each originating location, enable the cross-server sign-in feature and enter the pilot numbers of the receiving locations from the list that you created in Task 2

   • If the location is a Unity Connection server, see the .

5. Test the cross-server sign-in functionality. See the “Testing Cross-Server Sign-In” section.

See the following sections:

When you are configuring an HTTPS network, use the following task list to enable cross-server transfers. The cross references take you to detailed procedures.

1. Determine whether each location is an originating location, a receiving location, or both.

2. For each originating location, make a list of the phone numbers the location must dial to reach the receiving location servers.

   Note	You can enter only one dial string for each receiving location. If the originating location is configured for multiple phone system integrations, you need a dial string that all phone system integrations can use to reach the receiving location.

3. Configure each receiving location so that it can handle incoming cross-server handoff requests.

   • If the receiving location is a Cisco Unity Connection server, see the “Configuring a Unity Connection Receiving Location to Accept Cross-Server Handoff Requests” section on page 5-7.

4. For each originating location, enable the cross-server transfer feature and enter the pilot numbers of the receiving locations from the list that you created in Task 2

   • If the location is a Cisco Unity Connection server, see the Configuring a Unity Connection Originating Location to Perform Cross-Server Transfer Requests .

5. Test the cross-server transfer functionality. See the “Testing Cross-Server Transfer” section on page 5-9.

See the following sections:

Note

In Unity Connection, cross-server live reply is automatically supported (for users whose class of service allows it) when cross-server transfer is enabled. If you have previously configured a Unity Connection location as an originating or receiving location for cross-server transfers, the location also originate or receive cross-server live reply requests.

Use the following task list to enable cross-server transfers and live reply between Unity Connection locations in an HTTPS network. The cross references take you to detailed procedures.

1. Determine whether each location is an originating location, a receiving location, or both.

2. For each originating location, make a list of the phone numbers the location must dial to reach the receiving location servers.

   Note	You can enter only one dial string for each receiving location. If the originating location is configured for multiple phone system integrations, you need a dial string that all phone system integrations can use to reach the receiving location.

3. Configure each receiving location so that it can handle incoming cross-server handoff requests.

   • If the receiving location is a Cisco Unity Connection server, see the “Configuring a Unity Connection Receiving Location to Accept Cross-Server Handoff Requests” section on page 5-4.

4. For each originating location, enable the applicable cross-server features and enter the pilot numbers of the receiving locations from the list that you created in Task 2

   • If the location is a Cisco Unity Connection server, see the “Testing Cross-Server Sign-In” section on page 5-5.

5. Test the cross-server live reply functionality. See the “Testing Cross-Server Sign-In” section on page 5-5.

Users must access their home server (or cluster) when using client applications such as the Cisco Personal Communications Assistant (Cisco PCA) and IMAP clients. The phone interface is the only client that provides cross-server sign-in capability.

The following factors can contribute significantly to delays in cross-server call handoff:

• Longer user extensions. A four-digit extension does not take as long to dial during the handoff as a ten-digit extension.

• Longer dialing strings to reach the receiving location. A four-digit dialing string does not take as long to dial as a ten-digit dialing string.

• Multiple elements (such as PIMG/TIMG units, voice gateways, TDM trunks, and PSTN interfaces) in the call path between the originating location and the receiving location. More elements in the call path require more processing time for handing off cross-server calls.

In your environment, these factors can create delays that may cause the cross-server features to be unusable or unfeasible for callers. You must test your cross-server configuration on a representative call path in your environment to determine whether the delays that callers experience are acceptable.

The cross-server features require the use of ports on both the originating and receiving locations. Depending on how busy your servers are, you may need to add more ports or an additional server before enabling these features. You may also need to adjust how ports are configured. For example, you may need to enable more ports to accept incoming calls.

After enabling the cross-server features, we recommend that you monitor activity on the servers closely until you are confident that the servers can handle the increased load. For Cisco Unity Connection servers, you can use the Port Activity report in Cisco Unity Connection Serviceability to monitor port usage.

When a caller enters an extension in the automated attendant followed by the digits “#2,” the caller is routed directly to the greeting for the extension entered without a transfer being attempted. This is known as the transfer override digit sequence. Cisco Unity Connection 14 automatically supports the transfer override sequence between networked locations.

Do the following tasks so that cross-server handoffs complete properly between locations when this service parameter is set in Cisco Unified CM. In the task list, you create a special directory number for each receiving location that is used only during cross-server handoffs, so that the receiving location recognizes the call as a handoff.