Cisco Unified Survivable Remote Site Voicemail -- Auto Attendant Design
Survivable Remote Site Auto Attendant
The SRSV (Survivable Remote Site Voicemail) solution includes a survivable AA (auto attendant) feature. For the most part the survivable AA configuration is automated and mirrors the configuration on the central CUC (Cisco Unity Connection). This guide will describe how to best construct the central site AA so that its features can be automatically published to remote sites for AA service during a WAN outage.
|Note:||The SRSV solution supports auto-provisioning Cisco Unity Connection 8.x AAs ONLY.|
Auto Attendant Components
A CUC AA is configured using four basic building blocks: Call Routing Rules, Call Handlers, Directory Handlers, and Interview Handlers. The survivable AA solution has varying levels of support for each of these CUC AA features as described in the following pages.
- Cisco Unified Survivable Remote Site Voicemail -- Call Routing Rule Support
- Cisco Unified Survivable Remote Site Voicemail -- Call Handler Support
- Cisco Unified Survivable Remote Site Voicemail -- Directory Handler Support
- Cisco Unified Survivable Remote Site Voicemail -- Interview Handler Support
Default Auto Attendant
CUC ships with a default AA pre-configured. This AA will be invoked for outside callers to CUC as specified by the default call routing rules. The default call routing rule is always the last call routing rule (for both direct and forward routing rules) and is pre-configured to invoke the “Opening Greeting” call handler. The pre-configured opening greeting call handler has a flow as described below.
- The opening greeting call handler prompt is played to welcome the user. The default prompt is something like “Hello, Unity Connection Messaging System. From a touch tone telephone you may dial an extension at any time. For a directory of extensions press 4. Otherwise please hold for an operator.”.
- The caller may choose one of the following options. If the caller takes no action then the caller will be redirected to an operator.
- If the caller sends DTMF *, then they will be prompted to enter the extension and pin in order to log into a subscriber voice mailbox.
- If the caller sends DTMF # or 0, they will be directed to the operator.
- If the caller sends DTMF 4, they will be sent to the system directory handler and may dial a user by name to be transferred to a subscriber on the system.
All of the basic features described above are also available on the survivable AA. In addition to the default behavior, the survivable AA on SRSV-CUE’s will be updated with the applicable changes by SRSV-UMG on every provisioning interval with any changes made to the CUC AA. The remainder of this document will further describe the features of the CUC AA and which of those features can be transferred to the remote sites managed by SRSV-UMG.
Survivable AA Limitations to Consider for a Common Central and Survivable AA
Based on the support for the various AA features as described above, there are a few pitfalls that should be avoided when constructing an central AA call flow so that the Survivable AA will not confuse callers.
Consider the prompts for every call handler based on the functionality supported on the Survivable AA and whether they make sense in a failover situation. If some features will not work when the survivable AA is active, try to construct the prompt for the call handler to prepare the caller with the appropriate expectation.
Transfer to Subscribers
Avoid transferring callers directly to subscribers based on simple menu selections, such as "press 6 to speak to bob". Transferring directly to subscribers will work on at most one survivable remote site and on all other sites this will be considered an invalid option since the subscriber does not exist on the site.
Interview handlers are not supported by Survivable AA try not to include these in your AA. If it is possible, try to place the functionality in another AA flow and use distinct call rules to trigger the script outside of the 'opening greeting' call flow.
Custom Call Routing
Avoid using a lot of custom call routing for common call flows. Only the "Opening Greeting" call flow will be provisioned on the survivable remote site and all other call handlers will not be available. Do use call routing to segregate essential core AA behavior from supplementary behavior. Design the core AA to use only features available on the SRSV-CUE so this flow will operate as expected in failover. The supplementary AA flows can then use the enhanced CUC AA features not available to SRSV and not impact the SRSV flow since they will be omitted from being provisioned to the SRSV-CUE.
Transfer to Operator
Transfer to an operator will only work when an operator has been assigned to the remote site in SRSV-UMG configuration. Be careful in assigning the site operator number so that if the operator is likely to change over time, each new operator for the site will have the same phone number to avoid a lot of configuration on the SRSV-UMG. If any sites don't get an operator number defined the operator option programmed into your AA script will be considered invalid by the SRSV-CUE.
Splitting Central AA from Survivable AA
There may be situations where the central AA needs to have a fuller feature set than what is provided in survivable mode and there is a desire to avoid caller confusion with missing AA features in failover. The call flows used during failover can be separated from the standard day-to-day AA by following the procedure described below.
Build the central AA call flow using only custom call, directory, and interview handlers. Don't rely on any of the built-in CUC call handlers: 'Opening Greeting', 'Operator', 'Goodbye', or 'System Directory Handler'. Try using a naming scheme to distinguish the central handlers from the survivable handlers. For example you could name all the central CUC handlers with a prefix of 'Central '. Once the flow is defined, bind in the top level call handler in the default call routing rule 'Opening Greeting'. Since the SRSV solution only recognizes the 'Opening Greeting' call handler, pointing the call router to a different call handler will cause the CUC to bypass using the built in call flow in favor of the new customized call flow.
Next design the survivable call flow into the built-in 'Opening Greeting' call handler. The other default handlers may also be used but it is they are not required so long as all the survivable handlers that are defined are bound into the 'Opening Greeting' call handler directly or indirectly. When laying out the survivable AA be sure to limit the flow to features supported by SRSV-CUE. Even if the customized 'Opening Greeting' call handler is not used by the CUC, the UMG will still pull the configuration for the call handler and push it to the SRSV-CUE. If the 'Opening Greeting' call handler is not referenced at all by a CUC call routing rule, then the survivable AA flow will be maintained and managed on CUC while also being distributed to the remote sites without ever being executed by the CUC for incoming calls.
This layout of call and directory handlers is illustrated in the figure below.