Call Handlers
Call handlers are the essential building blocks for constructing audio-text applications within Unity and are the primary mechanism for both routing calls within Unity and sending callers to internal and external phones. The call handler plays custom-recorded greetings to callers, responds to input from users, and rings phones. In short, it is the most fundamentally important object in the system.
Each subscriber is associated with a call handler, which is referred to as the primary call handler for that user. If you look on the Unity SA and compare the call handler's administration pages with the subscribers pages, you will notice that a subscriber is an almost perfect superset of a call handler. The information that you see on the subscriber pages includes almost all the information on the call handlers pages, plus additional subscriber-specific items. The only important limitation that a primary call handler has that a standalone call handler does not is that the subscriber administration interface allows only one transfer rule to be enabled (the alternate). A standalone call handler has three transfer rules (alternate, standard, and off-hours). This limitation was imposed early on, to simplify the subscriber administration phone conversation. Subscribers can simply enable or disable transfers to their phones because dealing with lists of devices that can each be enabled or disabled through a phone interface can be somewhat daunting.
In Figure 3-1, the call handlers that have a prefix of ch_ are primary call handlers that are associated with a subscriber. The alias of the primary call handler contains the alias of the subscriber that it is associated with. For example, ch_jsmith is the primary call handler for the mail user with the alias jsmith. The cht_test template call handler seen in Figure 3-1 is a primary call handler for a subscriber template. Oddly, the two built-in subscriber templates are associated with primary call handlers ch_DefaltTemplate and ch_DefaultAdminTemplate. New templates that you create will be prefaced with cht_, however. The call handlers that have no prefix are standalone call handlers, and they appear in the Unity administration interface under the call handlers page. The other call handlers listed in the collection do not appear on their own in the SA; their properties are exposed on the subscriber and the subscriber templates pages instead.
All call handlers also have three subcollections of objects: contact rules, menu entries, and messaging rules. If you click on any of these properties in DPT, a pop-up window appears on top of the main DPT interface to show the objects in the collection. Figure 3-2 shows the AVP_CONTACT_RULES collection.
Figure 3-2. The Contact (Transfer) Rules Collection Opened for the Example Administrator in DOHPropTest
[View full size image]
AVP_CONTACT_RULES
Contact rules is the internal term for what the Unity SA calls transfer rules. Three transfer rules are present on each call handler, although, as noted earlier, primary call handlers associated with subscribers use only one: the alternate. The values for most of these properties are exposed on the Call Transfer page for call handlers, subscribers, and subscriber template pages in the SA.
In short, a contact rule is designed to optionally allow you to ring a phone when a call is passed to that call handler. By default, the first thing a call handler does when a call is passed into it is to process its contact rules and act on them. We cover this in more detail in Chapter 18, "Audio-Text Applications."
The three rules in the collection are alternate, standard, and off-hours. Which rule is evaluated depends on which is enabled and what time of day it is. If the alternate rule is active, it is always the one evaluated; it overrides the other two in all cases. If the off-hours rule is enabled in the SA and the schedule that the call handler/subscriber is associated with indicates that it is after hours, this rule is evaluated. If neither the alternate nor the off-hours rules trigger, the standard rule is evaluated. The standard rule never can be disabled in the SA; if it is disabled programmatically or by fiddling directly with SQL or DTP, callers can end up being sent to the failsafe phone conversation and will hear, "I am sorry, I cannot talk to you now. . . " The standard rule always is supposed to be enabled so that it can act as a backstop and prevent calls from falling through all three rules like that.
AVP_MENU_ENTRIES
The menu entries collection corresponds to the data visible on the Caller Input pages on the call handler and the subscriber pages in the Unity SA. A total of 12 objects in this collection represent the programmable actions for the 0–9, *, and # keys.
Each key can be set up to perform an action when pressed during the greeting for a call handler or subscriber. You can opt to hang up the call, take a message, send the caller to a different handler, route the call to the subscriber sign-in conversation, and so on.
The same set of menu entries is active and takes action for any of the five greetings that can play for a handler. This means that you cannot have different key actions active during the day than during after-hours; this can present difficulties in some audio-text applications. We cover ways to work around this in Chapter 18.
AVP_MESSAGING_RULES
The messaging rules correspond to the greetings on the call handler and subscriber pages in the SA. You will see six messaging rules in this collection, but the astute observer will note that only five greetings are visible in the SA. By default, the Error greeting is hidden in the SA, but it can be exposed by making a Registry edit available in the Advanced Settings tool. You also can edit the Error greeting using the Bulk Edit utility. The Error greeting is a special greeting that dictates what happens when a user attempts to dial an extension that does not exist in the system during a greeting. This is hidden on the SA by default: We got so many calls and questions about how it worked in early versions, and the need to customize it is reasonably rare in the field.
When a call is handed off to a call handler (either standalone or a primary call handler associated with a subscriber), the transfer rules are processed first by default. Then the call proceeds to the messaging rules if the transfer rules allow for it (in other words, if we did not do a successful transfer to a phone and release the call). You can change this to skip the transfer rules entirely by sending the caller to the greetings entry point in the call handler directly, which is discussed in detail in Chapter 18. The schedule that the handler is associated with and the source of the call and how it was routed to Unity determine which greeting gets played. The greetings are processed in the following order:
Alternate. If the alternate greeting is enabled, it always plays. It overrides all other greetings when active.
Internal. If the internal greeting is enabled and the calling extension corresponds to a subscriber in the database, the internal greeting plays.
Busy. If the busy greeting is enabled and the forwarding reason is busy, this greeting plays.
After Hours. If the after-hours greeting is active and the schedule associated with the call handler indicates that it is after hours, this greeting plays.
Standard. If none of the other greetings kicks in, the standard greeting always plays. It cannot be disabled in the SA and is always active.
Error. The Error greeting is always active and enabled by default, and is the one that gets played only when a caller enters an extension that cannot be found in the database while another greeting for the call handler or subscriber plays. By default, it tells the user, "I am sorry, I did not hear that entry. . ." and routes the caller back to the opening greeting call handler created by setup. This can cause headaches for folks trying to do a simple tenant services type of application because there could be multiple opening greeting handlers for multiple incoming numbers. Ways for dealing with basic tenant services types of scenarios are covered in Chapter 18.
Aside from the subcollections noted, a call handler has several important properties that link it to other objects in the system:
AVP_ADMINISTRATOR_OBJECT_ID
AVP_RECIPIENT_OBJECT_ID
AVP_LOCATION_OBJECT_ID
AVP_AFTER_MESSAGE_ACTION, AVP_AFTERMESSAGE_CONVERSATION, and AVP_AFTER_MESSAGE_OBJECT_ID
AVP_SCHEDULE_OBJECT_NAME
AVP_ADMINISTRATOR_OBJECT_ID
The Administrator object ID corresponds to the owner property on the profile page of a call handler or an interview handler. Anything that has the object ID tag on it indicates a unique identifier for an object in a collection. In most cases, when you click on any AVP_xxx property that ends in OBJECT_ID in the DPT application, you get a pop-up dialog box similar to Figure 3-3.
Figure 3-3. An ObjectID Jump Dialog Box in DOHPropTest
[View full size image]
If you click on the Find button, DPT automatically takes you to the appropriate object collection and shows you that object. This is handy for jumping around to follow various links off an object because the object ID values themselves are not human-readable in Unity 3.x. In versions of Unity 2.4.x and earlier, the object ID values were LDAP-distinguished names that referenced the container and alias of the object; this made it reasonably easy to figure out which one it was pointing at. In 3.x and later, they are GUID strings, which would require tedious manual filtering to run down on your own. The fine folks in the DOH group added this functionality to make our lives a bit easier.
The Administrator object ID can point to either a mail user or a distribution list. It is found on call handlers, public distribution lists, interview handlers, and name lookup handlers. Although the Administrator object ID value has been in the schema since day one, it has not been used for anything of significance until the release of Unity 4.0. This value originally was intended to allow owners of objects to administer them over the phone or through the SA interface. For instance, the capability to record the greeting on a call handler over the phone would be limited to the owner(s) of that handler. This was another one of those things that originally was slated to go in early on, but the resources and time just never allowed us to get to it. However, starting in Unity 4.0, if you are the mail user or a member of the public distribution list noted as the administrator (or owner in the SA) for a call handler, you are allowed to record the greetings for that handler over the phone. This will make some folks happy in the field because the only other way to change the greeting over the phone is to use a dummy subscriber—of course, this requires a subscriber license. Currently, that is the only use for this property; it is not yet possible to change properties on any other objects in the directory over the phone. It should be noted that this value has no impact for user access to objects via the web-based SA interface.
AVP_RECIPIENT_OBJECT_ID
The Recipient object ID points to a mail user or a public distribution list object that gets messages left for a call handler or interview handler. This is exposed on the SA on the Messages page for call handlers. For subscribers, however, the message recipient is, of course, hard-coded to be the subscribers themselves and does not show up as a separate field in the SA.
In the case of a primary call handler associated with a subscriber, both the recipient and the administrator object IDs should point to the mail user. This is one of the checks the dbWalker application makes while crawling the Unity database. If a primary call handler does not have both these properties pointing to a mail user, and if the mail user does not have the primary call handler object ID pointing back at the same handler, there is a problem. When a user-creation action fails, such a cross-linked primary call handler can result. The one exception to this is primary call handlers associated with subscriber templates. Templates are special because the owner and recipients are assigned when the subscriber is created using the templates.
The first thing Unity does when a call is sent to a call handler is to fetch handles to both the recipient and the administrator objects. Even though the call handler might not be set up to take messages, both of these objects must be valid and found, or the caller will go to the failsafe conversation. This is where Unity sends calls that it does not know what to do with. The caller hears, "I am sorry, I cannot talk to you now. Please try your call again later." Then Unity logs one or more errors in the application event log to help in diagnosing the situation. We decided to do this instead of risk the possibility of taking a message that we could not deliver.
For instance, if you have a customer feedback call handler set up to leave a message for Bill, and you delete Bill as a subscriber (or delete Bill's mail account entirely), that call handler has a broken link and will not work properly. The dbWalker utility is designed to quickly run down and help administrators fix such broken links. It is important to understand that Unity currently does not dynamically fix up these types of links when objects are removed, however, because it is very difficult to do this on-the-fly. For instance, deciding what to do with broken owner and recipient links requires some sort of user feedback from the administrator. In Chapter 21, we cover an example of how to do a clean removal of a user from the system without breaking any links programmatically.
AVP_LOCATION_OBJECT_ID
The location object ID points to the location that this call handler is associated with. All objects in the Unity database are associated with a location object, but only special types of subscribers can be associated with anything other than the default location object created by the Unity setup. Eventually, this design might allow for full tenant applications in Unity by allowing entire groups of objects (call handlers, interview handlers, subscribers, directory handlers, COS objects, and so on) to be associated with different locations on the same Unity server. Currently, however, only one primary location object exists per Unity box.
Administrators can create additional location objects for various networking schemes using AMIS, SMTP, the Cisco Unity Bridge, and VPIM transport mechanisms to other Unity servers or other foreign voice-mail systems. This is covered in detail in Chapter 12, "Unity Networking."
The location object also serves an important role for identifying other Unity servers on the network and finding out which Unity server a subscriber in the directory is associated with. When you install a Unity server onto your network, the setup creates a uniquely named primary location object, and a corresponding object is created in the directory. All Unity servers in the directory, then, can identify one another through information in these location objects and their subscribers, which are also in the directory. The details of how this works are covered in Chapter 12. Chapter 21 also includes an example that shows how to find and attach to a remote Unity server's database to update the properties on a subscriber found in the directory.
AVP_AFTER_MESSAGE_ACTION, AVP_AFTERMESSAGE_CONVERSATION, and AVP_AFTER_MESSAGE_OBJECT_ID
These three properties work together to define where a caller is sent after leaving a message for a call handler or subscriber. The values for these are exposed on the Messages page for call handlers and subscribers under the After Message Action section in the SA.
You will see a very similar trilogy of properties for action, conversation, and destination object IDs in the Messaging Rules collection objects as well. They all work in much the same way. The action determines whether a call is to be hung up or sent to another object. The conversation indicates which type of object this is and how it is to be used if the action is set to send the caller to another object. The destination object ID indicates which object will get the call.
For instance, if an administrator sets the after-message action in the SA to go to the greeting for the Operator Call handler, the AVP_AFTER_MESSAGE_ACTION would be 2, the AVP_AFTER_MESSAGE_CONVERSATION would be phGreeting, and the AFTER_MESSAGE_OBJECT_ID would be the object ID for the Operator Call Handler object in the call handlers collection. The 2 there is a generic "goto" value that is the most common setting for action properties. Do not worry—in Chapter 21, we cover how to check what the values for the action and conversations fields mean and what legal values you have to choose from.
TIP
The conversation phGreeting actually stands for Phone Handler Greeting. Early in the development of Unity, we called things phone handlers until it dawned on us that we were not handling phones—we were handling calls. In the user interface, things were renamed to call handlers, but the underlying conversation code was already in place with the ph prefix; it remains there today.
AVP_SCHEDULE_OBJECT_NAME
Schedules do not appear in the DOH Property Tester tool, but call handlers have an AVP_SCHEDULE_OBJECT_NAME reference. This schedule defines what times of the day are considered standard and what times are considered off-hours, in 30 minute increments for each of the 7 days of the week. The phone conversations use this to determine which greeting and transfer rules are triggered for the call handler when processing calls. In Unity 3.1(3) and later, schedule definitions appear in the Schedule table in the UnityDB database in SQL. For earlier versions of Unity, they appear as separate keys in the Registry under HKLM\Software\Active Voice\Schedule.
The unique identifier for schedules in all versions is simply their name (for example, Day Shift). You define different schedules in the SA on the Schedules page. There is no limit to the number of schedules that you can create.
TIP
Although the SA exposed only 30-minute increments in its interface for constructing schedules, the schedules are actually stored in 15-minute segments in the database. If you need more granularity in your schedules, you can use the Schedules option in the Audio Text Manager (ATM) application to expose schedules in 15-minute increments. You will find the ATM application in your Tools Depot on the Unity desktop or at
www.ciscounitytools.com.
AVP_ALTERNATE_DTMF_IDS
This is a collection of extensions that administrators can assign to subscribers. Athough this appears on all call handlers, of course, it applies only to primary call handlers that are associated with subscribers. Up to nine alternate extensions can be associated with each subscriber, and they are listed here
المشاركة الأصلية كتبت بواسطة forMyIslam
اخي ياسر
ضوابط المشاركة
المفضلات