1. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Purpose  The purpose of the cross box handoff feature is to make the user experience in a networked environment similar to what it would be in a single server environment.  Without the cross box handoff feature, users would have to logon to their mailbox from their home server, and only their home server. Transfers to users homed on different servers would be limited to a simple release transfer with no greetings, call screening, or holding options.

2. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 2 Logon  Cross box logon allows users who are homed on different UC servers to have a single phone number that they can call to log on to UC. No matter which UC server is their home server, they call the same number and are transferred to their home UC server to log on. Without this feature, users need to call the UC server on which their accounts were created to log on and access their messages.  The search for a user happens at the attempt sign-in level. It is the administrator’s responsibility to have the search scopes set up on their routing rules correctly, so that when a user calls in they can be found in the call’s search scope.

3. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 3 Transfers  The current networking design limits the data that is stored in the global directory. For this particular problem we are concerned with the fact that this limited amount of data only provides for release to switch call transfers from the automated attendant or directory handler to users on different UC servers in the search scope. It doesn’t matter what the user on the other UC server has configured for call transfers, even if they are set up for supervised transfers, we just do a release transfer. This hampers the user experience (no greetings, call screening, call holding).  Cross box transfer enables calls from the automated attendant or from a directory handler of on UC server to be transferred to a user on another UC server. The full user experience can then be achieved as the call now has access to the user’s full greetings and transfer settings.  For UC, live replies will not be distinguished as a separate case from transfers. If you have cross box transfers enabled and configured, then you get live replies too. There is no need for a separate live reply setting like exists in Unity.

4. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 4 Overview of Handoff  The basic hand off procedure goes something like: –The UC server on which the logon or transfer originates puts the caller on hold and calls the home UC server. –When the home UC server answers, the originating UC server sends the DTMF tone [B], that identifies the call as a hand off request. –The home UC server responds with the DTMF tone [D], and the originating UC server hands of the call to the home UC server for processing along with a DTMF packet that contains the caller and the called ID. –At this point the functionality is the same as if the call had originated on the home UC server.

5. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 5 Timeouts and Delays  There are several timeouts and delays that happen during the hand off. All of these settings are exposed in the SA. During the hand off request we use the following: –Max Rings. The number of rings to wait for an answer when the originating UC server first calls the home UC server. Configurable on the Connection location. –Send Delay. A delay before the originating UC server sends the DTMF tones to identify the call as a hand off request. Configurable on the Connection location. –Response Interdigit Delay. The inter digit timeout settings we use when listening for the hand off response. Configurable in advanced conversation settings. –Response Timeout. The amount of time (first digit timeout) to wait for the home UC server to respond to the hand off request. Configurable on the Connection location. –Data Packet Listen Interdigit Timeout. The inter digit timeout settings we use when listening for the packet. Configurable in advanced conversation settings. –Data Packet Listen First Digit Timeout. The amount of time (first digit timeout) the home UC server waits to receive the DTMF packet from the originating UC server, after the home UC server has already responded to the hand off request. Configurable in advanced conversation settings.

6. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 6 Packet Reading  The conversation will create and parse a packet of DTMF tones, in order to control the hand off, that holds the following information: –A single digit that represents the type of hand off, logon (0), logon over a known device (1), transfer (2) or transfer directly to greeting (3). –For a logon hand off, the ID of the user signing in. –For a transfer hand off, the caller id of the call and the ID of the user being transferred to, with a [*] DTMF denoting the end of the caller id and th4e beginning of the user ID. –The [#] DTMF to signal the end of the packet.  An example of a login packet for a user with a DTMF Access ID of 1010 would look like 01010#  An example of a transfer packet for a caller calling in on phone 1010 who matched a user on a directory handler with a DTMF Access ID of 1013 would look like 21010*1013#.

7. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 7 Issues  Different search scopes between where the hand off is requested and the hand off is accepted are going to cause problems. A match could be made on a search scope on the originating server that can not be made on a different search scope on the home server. So check the search scopes. Call routing rules can be used to direct calls to the appropriate search scopes if need be.  Multi-switch integrations where one switch has to dial a different number then the other switch to reach another UC server pose problems. There is only one number that can be configured to dial another UC server. If this number doesn’t work for every switch configured, then hand offs will fail if they are initiated from the incorrect switch. The only real ways to workaround this are to either have the number work for all switches configured for the UC server, or have the auto-attendant application on the originating server setup in such a way that cross box handoffs are only done on the correct switch.

8. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 8 Generic Conversation Flow  When a caller enters an extension of an object the following flow generally happens that trips a hand off: – Search the search scope that the call is set to for the extension. – If an object is found, then determine what that object is. – If that object is a user, then determine if that user is local or not. – If the user is not local, then check to see if the user’s location is configured for cross box handoffs. – If the user’s location is configured for cross box handoffs, then do the hand off. – Otherwise, if the user has a cross-server transfer extension set (on the User Basics page of the SA), then do a release transfer to that number. – Otherwise, take a message for the user.

9. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 9 Hand Off Request Errors  “The dial string for the VMS location [location name] was empty.” Should never happen, but if it does, this is easily remedied by adding a dial string to the Connection Location in the SA on the server making the hand off request.  The supervised transfer that is made to the home server can fail in several ways. – “Hand off connected with [location name].” The transfer was successful. – “Hand off could not connect with [location name], it is busy.” The transfer received a busy signal. Check why the home server is busy. Is it taking too many calls? Is the switch integration configured correctly (like are the ports forwarding correctly)? – “Hand off could not connect with [location name], it timed out while accepting the call.” The transfer timed out. Check why the home server is timing out when accepting calls from the originating server. – “Hand off could not connect with [location name], it ring no answer (RNA).” The transfer rung the dial string for the max number of rings under the Connection Location in the SA. Check why the home server is RNA. May need to increase the number of rings on the originating server. – “Hand off could not connect with [location name], hr=[error code].” This is the catch-all for when the transfer fails but is not one of the three conditions above. Turn on MIU diagnostics to further troubleshoot the issue.  “Hand off response not received, waiting for [hand off request tone], digits gathered = [dtmf], max wait time in seconds = [time].” This error occurs after the transfer has already succeeded, but the hand off response tone never came back. Check the diags on the home server as to why it is not sending the response tone.

10. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 10 Hand Off Response Errors  “Packet was not received, max wait time in seconds = [time].” The hand off packet that the originating server was supposed to send after the hand off response was received, was never sent. Check the diags on the originating server to figure out why the packet was never sent. Verify that the originating server saw the hand off response tone.

11. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 11 Errors Processing Packets  These errors on the home server generally mean the packet is deformed in some manner. Likely due to DTMF issues on the line, such as DTMF echos or missing DTMF tones. Most are self-explanatory.  “Hand off action is unknown, digit = [hand off action digit found in packet].” The hand off action digit found in the packet received was not the DTMF 0, 1, 2, or 3. These are the only action digits UC understands. The hand off action digit (the first digit of the packet) is logged.  “The hand off packet was empty.”  “Failed to find a # digit (termination digit) in packet.”  “Failed to find a user id in packet.” This packet was for a logon but there was no user id found in the packet.  “Failed to find a * digit (delimiter digit) in packet.” This packet was for a transfer, but their was no * in the packet to mark where the caller id ends and the called id begins.  “Failed to find a caller id in packet.” This packet was for a transfer but no caller id was found.  “Failed to find a called id in packet.” This packet was for a transfer but no called was found.

12. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 12 The Big Cheese  Any time, any hand off fails, whether it be a request or a response, an entry is always placed in the diags, much like a failsafe. The trace logged dumps all the hand off specific named props that have been discussed in these slides and the annotated logs. This diag is meant to alert you to the fact that a hand off failed, with the named props showing the circumstances around the failure for reproduction. It is not enough to solve the problem…for that you should turn on the ConvSub micro traces and walk through a failed hand off.

13. © 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 13