Table Of Contents
Cisco Unified Expert Advisor Option
Last revised on: August 18, 2009
Note Cisco recommends that you read the entire chapter if you intend to deploy Cisco Unified Expert Advisor in your system. Unless otherwise noted, all information in this chapter refers to Cisco Unified Expert Advisor Release 7.6(1).
Cisco Unified Expert Advisor is an optional component in a Unified ICM deployment, first introduced with Cisco Unified ICM Release 7.2(3). It allows calls to be routed to expert advisors in addition to traditional contact center agents. An expert advisor differs from a traditional agent most notably in the fact that it is not the expert's main job to answer the phone. The expert advisor is a part of the enterprise but usually not a part of the call center. However, the expert advisor has an expertise that may be tapped by traditional agents or tapped directly by callers into the contact center. Thus, the company may develop a business model that allows the call center to reach into the enterprise in order to involve specifically designated expert advisors.
Two general use cases are addressed, leading to somewhat different call flows. In the first case, advisors are never targeted for direct interaction with inbound callers. They are involved only by those traditional agents who have already received calls and who wish to consult an advisor. The agent may consult and, if the company's business practices permit it, conference or transfer to the advisor. In this way, experts within the enterprise are brought into the contact center interaction. Such involvement might be useful in order to increase the percentage of first-call resolutions.
The second use case bypasses the traditional contact center completely and allows outside callers to reach members of the enterprise directly. As with traditional contact centers, Unified Expert Advisor uses various mechanisms to select the most appropriate advisor for a given inbound call, and the caller may be queued until an advisor answers.
This chapter provides guidelines on deploying Unified Expert Advisor in the context of Cisco Unified ICM technology and other solution components.
For more details about Unified Expert Advisor, refer to the Cisco Unified Expert Advisor product documentation available at http://www.cisco.com.
Unified Expert Advisor consists of the following components:
•One primary Runtime Server
•One optional backup Runtime Server
•One optional Reporting Server
The Runtime Servers handle all call activity, and the primary Runtime Server also hosts the Operations, Administration, Maintenance, and Provisioning (OAMP) service, which provides the web-based management and configuration interface. The Reporting Server houses an Informix database system which captures and records relevant events from the Runtime Servers and makes them available for queries via Crystal Reports or Cisco Unified Intelligence Center (Unified IC), either of which must be purchased separately.
All Unified Expert Advisor servers run in an appliance model, on top of the Unified Communications Operating System. This operating system is a version of Linux that has been customized by Cisco for use with this and other Unified Communications products such as Cisco Unified Communications Manager (Unified CM).
Unified Expert Advisor is part of a set of solution components, as shown in Figure 7-1.
Figure 7-1 Unified Expert Advisor Solution Component Environment
The following sections describe each solution component.
Unified ICM Components
The Unified ICM components are the typical Unified ICM component set (router, logger, HDS, and so forth), which have their usual job of collecting and tracking agent state data, processing incoming calls via routing scripts, and queuing and connecting callers with appropriate agents. Three peripheral gateways (PGs) are involved in an Expert Advisor solution:
•Unified CM PG — Connects to Unified CM via JTAPI. Only one Unified CM PG is shown in Figure 7-1, but normal duplexing and sizing rules and recommendations apply. Note that, although Unified CM is a required part of the deployment, a Unified CM PG is not and may be omitted if the deployment does not include traditional Unified CCE agents.
•VRU PG — Connects to Unified CVP (or some other service control VRU) via GED-125. Again, only one VRU PG is shown in the diagram, but normal duplexing and sizing rules and recommendations apply.
•Expert Advisor PG — This is a new component in Unified ICM and is designed specifically to support Unified Expert Advisor. It is the same executable as the Unified CCE Gateway PG, but it functions in a way to support the fact that a termination event is the only call event received when using Unified Expert Advisor. The configuration in Figure 7-1 assumes duplexed PG and Unified Expert Advisor Runtime Servers, but a simplexed configuration is also supported.
Unified Expert Advisor is not supported as part of a Unified System CCE deployment.
Unified Customer Voice Portal (CVP)
Unified CVP is an optional component in a Unified Expert Advisor solution, but it is highly recommended. With Unified Expert Advisor as well as any Unified ICM solution, Unified CVP provides a queuing platform for calls that are in queue for any skill group, including those groups consisting of expert advisors. Just as importantly, it provides sophisticated IP call control capability for Unified ICM.
A Unified Expert Advisor deployment that does not include Unified CVP has the following limitations:
•Another Service Control VRU (such as IP-IVR or a third-party product) must be provided as a queuing platform; or if no queuing is desired, then only Select nodes or similar non-queuing skill group selection nodes may be used in the routing script.
•Call delivery failures due to the selected advisor's phone being busy, unreachable, or not answered, will not necessarily result in an event that could be handled within the Unified ICM routing script.
•Certain call disposition reporting fields in Unified ICM might not be accurate because Unified CVP explicitly translates certain SIP errors to appropriate Unified ICM Termination Call Detail disposition codes.
•Unified CVP automatically plays simulated ring tone audio to the caller during the period of time when a caller is waiting for an expert advisor but is no longer queued in Unified ICM. Unified CVP 7.0 offers a destination-specific ring tone capability, which allows ring tone to be replaced with music on hold for that time period. Without Unified CVP, however, callers will hear only silence during this period.
Although Unified CVP Release 4.1 is supported, Unified CVP 7.0(2) or a later maintenance release is recommended. The following limitations exist when using Unified CVP 4.1 with Unified Expert Advisor:
•Calls passing through Unified CVP 4.1 will not support video.
•If the expert's phone is busy when the call is sent to it, a re-query is invoked in Unified ICM, thus allowing the routing script to take an appropriate action. With Unified CVP 4.1 however, the Requery Status does not distinguish between busy and other types of connection failures.
•Destination-specific ring tone is not available with Unified CVP 4.1. It is therefore not possible to substitute music for ring tone while the caller is waiting for an expert advisor.
Note Because all Unified Expert Advisor deployments use SIP for call signaling, Unified CVP must also be deployed for SIP and not H.323. On the other hand, in deployments where Unified CVP does not establish a direct SIP connection to Unified Expert Advisor, such as when calls are translation-routed to Unified Expert Advisor through the PSTN or other means, there is no restriction on the signaling type in which Unified CVP is deployed.
Call Control and Presence Infrastructure Components
The gateway (see Figure 7-1) serves two purposes. First, for calls arriving from the PSTN, the gateway provides TDM-to-IP conversion. Later, if Unified ICM needs to queue the call, Unified CVP uses the gateway to provide VXML voice browser services to play music and other prompts. Deployments that do not include Unified CVP will need some other way of providing TDM-to-IP conversion and some other queuing platform.
Cisco Unified Communications Manager (Unified CM)
Unified CM is required in all Unified Expert Advisor deployments. At a minimum, Unified CM proxies the addresses where calls are delivered to expert advisors. Stated another way, when Unified Expert Advisor delivers a call to an expert advisor, it asks Unified CM to connect the call. Any address that can be configured in Unified CM is a valid address to which Unified Expert Advisor can send the call to an advisor. This includes both local and remote destinations, hunt and pickup groups, outbound calls via the PSTN to cell phones or hard phones, voicemail-forwarded numbers, Mobile Connect remote destination numbers, and so forth.
Unified CM may also be used to source calls. Often such calls are initiated by Unified CCE agents in the form of a consult operation, but they might also be from any member of the enterprise who has an IP phone connected to Unified CM.
Cisco Unified Presence
Cisco Unified Presence provides the interface to the supported instant messaging (IM) clients, and it is required in all Unified Expert Advisor deployments. Ultimately the intent is for Unified Expert Advisor to support any IM client that Cisco Unified Presence supports; but as of this release, only Cisco Unified Personal Communicator, IP Phone Messenger (IPPM), and Microsoft Office Communicator are supported. Via a SIP SIMPLE protocol, Cisco Unified Presence provides regular presence updates to Unified Expert Advisor as its users login and go active and inactive, which is how Unified Expert Advisor knows which expert advisors are present. IM messages between Unified Expert Advisor and the individual expert advisors are also proxied by Cisco Unified Presence. In Microsoft Office Communicator deployments, the Cisco Unified Presence server connects to the Microsoft Office Communications Server (OCS) via inter-domain federation, and the OCS then connects to the individual Microsoft Office Communicator IM clients. In addition, the list of Cisco Unified Presence users is shared with Unified Expert Advisor via the AXL protocol, so that customers do not need to configure users redundantly on both systems.
Note Only Cisco Unified Personal Communicator and IPPM users can be imported in this way; Microsoft Office Communicator users must be configured manually in Unified Expert Advisor or imported from a file through Unified Expert Advisor's bulk import tool.
Finally, the Cisco Unified Presence server also includes a built-in SIP proxy server (not shown in Figure 7-1). Of primary interest is the proxy server's static route table, where the entire SIP numbering plan can be maintained in one place. The static route table also plays a role in the Unified Expert Advisor high availability strategy, causing SIP messages to retry automatically to the backup Runtime Server if the primary Runtime Server is unable to accept them. The table is used by Unified CVP as well, as part of its load-balancing strategy.
Therefore, Unified Expert Advisor communicates with Cisco Unified Presence in three ways: first as a simulated ordinary presence user (actually, one for each runtime server), second as an AXL application user, and third as a SIP user agent for call control purposes.
Cisco Unified Personal Communicator
Cisco Unified Personal Communicator is Cisco's instant messaging and presence client, and it normally runs on an individual user's desktop. In a Unified Expert Advisor deployment, this component acts as the expert advisor's primary interface into the Unified Expert Advisor system. It sends presence information to Cisco Unified Presence and allows the expert advisor to interact with Unified Expert Advisor using instant messaging. It also supports voice and video, and Unified Expert Advisor can deliver incoming calls directly to Cisco Unified Personal Communicator if no hard phone is available. Unified Expert Advisor can support either Cisco Unified Personal Communicator clients or Microsoft Office Communicator clients, but not both in the same installation.
IP Phone Messenger (IPPM)
IPPM (not shown in Figure 7-1) is an IM and presence client that runs on certain Cisco IP phones. It is supported with Unified Expert Advisor as an alternative to Cisco Unified Personal Communicator.
Microsoft Office Communicator
Microsoft Office Communicator is an instant messaging (IM) and presence client. It can be used with Unified Expert Advisor as an IM client but not as a softphone. Unified Expert Advisor can support either Cisco Unified Personal Communicator clients or Microsoft Office Communicator clients, but not both in the same installation.
This section outlines the various features and concepts that describe the Unified Expert Advisor product.
Definition of an Expert Advisor
An expert advisor differs from a traditional contact center agent in two specific ways:
•Answering phones is not the advisor's primary job.
•The advisor is often mobile and can be reachable at different numbers at different times.
Because answering phones is not the expert's primary job, that person may not always be available or willing to accept calls. Unified Expert Advisor accommodates the advisor's availability to accept a call by first offering a task to the advisor using a pop-up IM message, and then allowing the advisor to reject it or not respond at all. Unified Expert Advisor accommodates for possible unavailability by making use of presence technology. Essentially, if the presence/IM client indicates that the advisor is available, then Unified Expert Advisor may offer tasks to that advisor.
Being mobile means that the advisor might not always be reachable at a fixed number. Unified Expert Advisor accommodates this possibility by allowing the administrator to configure multiple addresses, a preferred address, and even an optional preference to use the Cisco Unified Personal Communicator client directly for voice and video, thus bypassing the phone completely. The advisor also has the ability to use an IM response to specify a different phone number than any which have been previously configured, such as a cell phone number.
The Unified Expert Advisor administrator may assign skills, competency levels in those skills, and arbitrary attributes to each expert advisor. These factors can then be used to qualify advisors for membership in various assignment queues. (See Assignment Queues and Unified ICM Skill Groups.)
Synchronization of Cisco Unified Presence User List
All expert advisors must first be defined in Cisco Unified Presence as users, but not all Cisco Unified Presence users need to be expert advisors. Unified Expert Advisor supports a process that imports basic information about all configured users from Cisco Unified Presence, consisting of their names, login IDs, phone numbers, and phone number preferences. Once this information is imported, Unified Expert Advisor screens must be used to indicate which users are to be considered expert advisors and to add configurations specific to Unified Expert Advisor, such as skill and attribute information for those users. Unified Expert Advisor does not provide a way to enter the basic information manually; it must be imported from Cisco Unified Presence.
This "synchronization" process runs automatically upon initial setup, and thereafter every night at midnight by default, but the time and frequency are configurable. In addition, the Unified Expert Advisor administrator can request a synchronization on demand. Note, however, that the import process can take up to five minutes to complete, depending on the number of Cisco Unified Presence users configured. (Also see Scheduling of the Cisco Unified Presence Synchronization Task.)
Assignment Queues and Unified ICM Skill Groups
Expert advisors are configured as members of various assignment queues (AQs); however, inclusion in a given AQ can be configured quite flexibly. The administrator can either explicitly list AQ members or configure the set of skills, competency levels, and attribute values that are to define membership in a given AQ. The administrator would then configure each expert advisor's skills, competencies, and attribute values. Although AQ membership is static (it can be changed only by configuration), availability in a given AQ is dynamic and depends on the expert advisor's login state, presence state, and current activity on a call.
Each assignment queue corresponds directly to exactly one skill group in Unified ICM. The administrator should always configure AQs on Unified Expert Advisor first, after which an autoconfiguration process will automatically configure corresponding skill groups in Unified ICM. Any additional objects must be configured using Unified ICM's configuration manager tools. For details, refer to the Administration and Configuration Guide for Cisco Unified Expert Advisor, available at http://www.cisco.com.
A Unified Expert Advisor skill group may contain only expert advisors; you cannot mix other Unified ICM agents with expert advisors in the same skill group. Nevertheless, from Unified ICM's perspective, a skill group containing expert advisors is no different than one containing traditional agents. A single Queue to Skill Group node may include both traditional and expert advisor skill groups if so desired.
Expert Advisor Availability States
The expert advisor's availability state is determined by the state of his presence client. If the advisor's presence client is not logged in to Cisco Unified Presence, then he is not logged in to any assignment queue and therefore not logged in to any Unified ICM skill group. If the advisor's presence client is logged in and available, then the expert is available on all assignment queues (and therefore Unified ICM skill groups) of which he is a member. If advisor's presence client is logged in but "away," then the expert is not available in any assignment queues or Unified ICM skill groups.
The Cisco Unified Personal Communicator client, like other IM clients, allows the user to modify the list of the presence states that appear in his drop-down list. Similarly, Unified Expert Advisor allows administrators to manually define how those presence states map to assignment queue and Unified ICM skill group availability status.
Unified Expert Advisor Uses Unified ICM Enterprise Routing Semantics
From the perspective of Unified ICM, Unified Expert Advisor is just another Enterprise Routing Service (ERS) peripheral. Just as with Unified CCE Child and any traditional third-party ACD, the Unified ICM router selects a hypothetical agent from a skill group but then routes the call to the peripheral, not to the agent. It is then up to the peripheral to indicate to Unified ICM which agent actually received the call.
Also as with Unified CCE Child and third-party ACDs, it can take some time for the agent to receive the call, during which time the peripheral is responsible for any local queuing that might be required. On the other hand, Unified ICM should be scripted so that it does not to send the call until it is reasonably sure there is an agent available to accept it. In the case of Unified Expert Advisor, the local queue time could be considerable because it includes not only the time in which expert advisors are being offered the task, but also the possibility that no advisor accepts it. In that case the call continues under the control of Unified Expert Advisor until more expert advisors in the assignment queue become available.
The next section on Strategies for Managing Extended Ring Time, explains ways to mitigate the effects of this queue time.
Strategies for Managing Extended Ring Time
As mentioned above, due to Unified Expert Advisor's process for offering tasks to advisors, a call could remain under the control of Unified Expert Advisor without being answered for quite some time after it has finished queuing. During that time, the caller is listening to ring tone. You can use any of the following methods to mitigate the impact on the caller experience:
•If Unified CVP 7.0 or later is used as the routing service and queuing platform, then Unified CVP can be configured to provide a special ring tone for calls while they are at Unified Expert Advisor. The ring tone can be any .wav file, such as a music file, and it can be applied on the basis of a particular outbound dialed number, which in this case would be the translation route address pattern that is used to transfer calls to Unified Expert Advisor from Unified CVP. For more information, refer to the custom ringtone patterns feature in the Unified CVP documentation.
•The administrator can also limit the amount of time a call remains unanswered with Unified Expert Advisor before being returned to Unified ICM. Unified CVP's ring-no-answer (RNA) time-out feature on outbound SIP calls can be set so that any call to Unified Expert Advisor must be answered within a certain number of seconds; any call not answered within the specified time is withdrawn by Unified CVP and causes a re-query into the Unified ICM routing script, with a re-query code indicating ring-no-answer. Note that, in Unified CVP 4.1, this time-out can be set only on a global basis; it cannot be set differently for Unified Expert Advisor destinations than for other destinations.
•Various features allow the administrator to increase the likelihood that an expert will accept the call. For example, the broadcast number in an assignment queue definition could be increased, so that more experts will be offered the task at one time, thus increasing the likelihood that one will accept during the first round of offers. Also, expert advisors may be configured on an individual basis to not be allowed to reject tasks. Such advisors do not receive the offer message at all; they only receive the call. As a business practice, it might be appropriate for certain users to be configured in this way as a last resort, so that somebody's phone always rings.
•Although the following technique actually takes effect before the call reaches Unified Expert Advisor, it is relevant to this discussion. Unified Expert Advisor offers a feature whereby even expert advisors whose IM clients are set to Not Available can be offered tasks. In other words, such expert advisors are not allowed to make themselves unavailable for tasks. This setting can be configured on a per-AQ basis. As a result, the administrator could create two parallel AQs with identical membership rules but different settings for this flag. Then, the administrator could configure escalating queues in the Unified ICM script editor so that, if the normal queue contains no available agents, after a certain amount of time the special queue gets added to the list. This method effectively allows expert advisors to be considered for the call if they are logged in to their IM clients but not "present."
Attributes are user-configurable variables that can be associated with incoming calls as well as with individual expert advisors. When associated with incoming calls, their values can be populated from Unified ICM call variables or Extended Call Context (ECC) variables, or from arbitrary SIP header variables that might have been provided by a SIP endpoint that represents the caller. Additional standard call contact information such as ANI, DNIS, GUID, and so forth, is also stored by default in their respective system-defined attributes, and the entire set of call-related attributes makes up the ContactDetail. ContactDetail is the basis for the call detail record that is stored in both the reporting server and the Unified ICM historical database for each call.
When associated with expert advisors, attributes can be used to help qualify or disqualify individual advisors from various assignment queues. For example, an expert advisor attribute called YearsInJob with a value of 2 might disqualify the advisor from an assignment queue whose configuration calls for advisors with at least 5 years of experience.
When it comes time to select the best expert advisors to handle a particular contact, attributes come into play for assignment queues whose selection strategy is spatial. Unified Expert Advisor has the ability to compare like (numeric) attributes that are associated with the expert advisor and with the incoming call, and to place advisors in priority order according to closest match among many values. This is sometimes known as N-Dimensional Routing.
Attributes are also displayed in an expert advisor's presence client window as tasks are offered or assigned. This allows the presence client to act as a sort of lightweight CTI desktop, as described in the section on The Presence Client as Lightweight CTI Desktop.
Individual attributes may be configured as either visible, masked, or hidden with respect to the expert advisor's IM client, to the reporting server, and also to the system's debug logs. In this way Unified Expert Advisor administrators may individually control which attributes are used for which purpose, which persist in the historical database, and which are too sensitive to be written out in the logs.
Changes to attribute definitions, mappings, characteristics, and relationship to expert advisors and to assignment queues may all be changed by the administrator at run time, and the changes take effect immediately.
IM Message Sets
Unified Expert Advisor communicates with expert advisors via the presence client in the form of IM messaging. These IM messages are aggregated into message sets, which are localized to many locales as well as being completely customizable in terms of their form and content, and new message sets can even be created. In addition, each expert advisor can be assigned not only to a particular locale but also to a particular message set.
Three messages of particular interest are the Contact Offer Request Notice, the Contact Offer Notice, and the Contact Offer Cancelled Notice. By default, the pre-populated US English versions of these messages are:
•Contact Offer Request Notice: "Are you available to handle this contact?"
•Contact Offer Notice: "Please standby for incoming call."
•Contact Offer Cancelled Notice: "The system has cancelled the task."
The Contact Offer Request Notice informs an expert advisor about an incoming call and invites him to accept or reject it. Multiple advisors can potentially accept the call, but only one will actually receive it. Those who were a little late in responding receive the Contact Offer Cancelled Notice, but the individual who was quickest receives the Contact Offer Notice, indicating that the call is on its way.
As described previously, an advisor may or may not be permitted to reject contacts. Advisors who are not permitted to reject contacts receive only a Contact Offer Notice announcing that the call is coming, and there is no Contact Offer Request Notice in that case.
The Unified Expert Advisor message sets also contain inbound messages, which are regular-expression descriptions of the formats that advisors will use to respond to queries. These are also customizable. Administrators can take advantage of this customization capability to eliminate certain possibilities from certain expert advisors. For example, if the corporate policy is not to allow advisors to accept calls on their cell phones unless previously configured by the administrator, then the administrator can remove the regular expression that describes the format that the advisor would use to specify his cell phone number.
The Presence Client as Lightweight CTI Desktop
Many of the messages in a message set incorporate system variables, such as the advisor's name or the date and time of a call. They can also incorporate data from ContactDetail attributes, which can in turn come from Unified ICM call or ECC variables or from custom SIP header fields. In this way, the Unified ICM routing script is able to provide call context information to the expert advisor, and the presence client becomes something of a lightweight CTI desktop. When the presence client is used in this way, the following guidelines and conditions apply:
Generally, attributes in Unified Expert Advisor can be configured as viewable or not viewable by agents. Those that are agent-viewable are automatically displayed along with the Contact Offer Request Notice message and the Contact Offer Notice to the expert advisor. In the case of Cisco Unified Personal Communicator, the message is displayed in HTML form, and the attributes appear in a standard HTML table below the text of the message. For presence clients that do not support HTML, the attributes appear in list form.
•Improving the formatting
As mentioned previously, you can embed any or all of the attributes directly in the content of the Contact Offer Request Notice or the Contact Offer Notice, adjusting the text as appropriate.
•Removing attributes from the table
Embedding attributes directly in the message text does not remove them from the HTML table or list. The only way to remove them is to mark them as not viewable in Expert Advisor Client in the attribute definition itself. Doing so does not prevent them from appearing in message text content in which they are explicitly embedded.
•Preventing duplicate appearances
Note that the attributes table appears in both the Contact Offer Request Notice and the Contact Offer Notice, so for expert advisors who are permitted to reject contacts, the attributes table will appear twice. If this is confusing or unwanted, then all the attributes should be declared not viewable in Expert Advisor Client, and only those that are desired in each message should be embedded in those messages exclusively.
•Displaying a clickable URL
When a Cisco Unified Personal Communicator client displays information in the default HTML form, any text that matches the format of a URL is automatically shown in the form of a clickable link. Clicking on that link causes the user's web browser to open and display the specified page. Using this capability, it is quite easy for a Unified ICM routing script to construct a URL based on information obtained from a back-end database or application gateway source and to provide it to the expert advisor who is receiving the call. This feature offers a very simple and straightforward way to deliver a caller-specific web page directly to the expert advisor as he receives the call.
For example, suppose the customer wishes to push a custom web page from a Customer Relationship Management (CRM) application such as Siebel or Salesforce.com to the expert advisor who accepts a call. In both these cases as in many others, the web page that identifies a particular case or database record can be addressed through a URL, as in the following (hypothetical) example:
To accomplish this, the Unified ICM routing script would build the above string by concatenating its components together with the help of Unified ICM's formula editor, using information it has already determined about the caller. It would place this information into an ECC variable that is mapped in Unified Expert Advisor to an attribute embedded in the Contact Offer Notice as described above. When the expert then accepts the call, he receives the URL in his Cisco Unified Personal Communicator client and clicks on it in order to be presented with the appropriate page from Salesforce.com.
Unified Expert Advisor's job is to connect callers to expert advisors. In most cases this means that an audio connection will be established, but other media, particularly video, are also supported. It is entirely up to the endpoints (the expert advisor's phone and the caller's phone) to determine which media they wish to negotiate. The negotiation process, an integral part of the SIP protocol, is proxied through Unified Expert Advisor, but Unified Expert Advisor takes no action other than to observe its progress. The media itself, whether voice, video, or something else, is established directly from endpoint to endpoint and does not pass through Unified Expert Advisor.
From a reporting perspective, Unified Expert Advisor keeps track of which media are used during a call, when, and for how long, and the data is written to the reporting server. Note that Unified CVP 4.1 does not support media other than voice.
Unified Expert Advisor offers a number of security features, including:
•Operations, Administration, Maintenance, and Provisioning (OAMP) Security
All administrative web pages are served using Secure Socket Layer (SSL) (HTTPS protocol).
•Unified Communications Operating System Root Access
The Unified Communications Operating System is based on the Linux operating system, which generally offers a root account that is privileged to perform any function on the system. Root access is disallowed in Unified Expert Advisor, but there are provisions to open such access in rare cases where Cisco Technical Assistance Center (TAC) may require it. The procedure for doing so is fairly involved and requires both the customer and the TAC to grant permission.
•Users and user management
Two levels of administrative users are available: superuser and administrator. The superuser has access to system-level OAMP functions, which includes the ability to create and manage both administrators and additional superusers. One default superuser is also created during installation. All but the default superuser are authenticated through Active Directory. Superusers may also create and manage an additional set of reporting users (users who can run reports). Finally, one Informix user is created during installation, which is used internally to allow the various instances of Informix to communicate with each other across the network. Neither the reporting users nor the Informix user is authenticated through Active Directory.
Unified Expert Advisor supports an SSL connection to Active Directory (AD).
Certificates are exchanged automatically among the three servers in a Unified Expert Advisor cluster, so that they can communicate securely with each other via the ActiveMQ message bus as well as for database replication purposes. Note that, as each server is added to the cluster, all the previously added servers must be up and operational in order to exchange these certificates, or else installation will fail.
•Sensitive call data
Unified Expert Advisor has a concept of attributes, which hold any call-specific data. If certain attributes contain sensitive information such as PIN codes or passwords, they can easily be configured so that they are never written to any log file, never stored in the historical reporting database, and/or never shown to expert advisors.
Unified Expert Advisor installs Cisco Security Agent 5.2 automatically with the product.
Note Unified Expert Advisor does not yet support SIP over TLS, which includes call control activities as well as instant messaging and presence interactions.
Reporting with Unified Expert Advisor is accomplished by combining information collected by Unified ICM with information collected by the Unified Expert Advisor Reporting Server. In general, Unified ICM reporting is used to report on anything it would report on for a traditional ACD, whereas the Unified Expert Advisor Reporting Server handles information that is specific to expert advisor operations.
The Unified Expert Advisor Reporting Server contains an Informix IDS database that collects historical information about assignment queues, expert advisors, and contacts. Sample reporting templates are provided in order to produce historical reports that cover assignment queue activity, expert advisor activity (including contact rejection rate), expert advisor presence statistics, contact detail information for the period of time in which calls were under the control of Unified Expert Advisor, and media reports indicating when voice and/or video were used. Two sets of templates are provided: one for Crystal Reports and one for Cisco Unified Intelligence Center (Unified IC) Release 7.5(2) or later. Both sets offer the same functionality. (Note that Cisco Unified Intelligence Suite does not offer specific support for Unified Expert Advisor tables.)
In Unified ICM, skill group reports, service reports, agent reports, and agent skill group reports are all available in both historical and real-time form. As mentioned previously, the Reporting Server is an optional component of Unified Expert Advisor. If it is omitted, then only those reports offered by Unified ICM will be available.
The Unified Expert Advisor Reporting Server can retain about 8 days worth of data, assuming a full load of 3000 logged in expert advisors, with each being a member of 10 assignment queues, and a sustained rate of 2 calls per expert per hour. (See the chapter on Sizing Unified CCE Components and Servers, page 10-1, for detailed capacity information.) There is an automatic purge mechanism that operates twice daily to delete any data that is older than the (configured) retention period. Data is always purged in full-day increments.
Customers who usually have fewer experts logged in, fewer assignment queues per expert, or a slower call rate, can probably set correspondingly longer retention periods, but some experimentation is needed to determine the desired settings. The purge mechanism also operates automatically if the database approaches its capacity, so there is no harm in starting with a longer retention period and gradually reducing it. But for the sake of safety and predictability, it is best in the long run to choose a fixed period rather than to rely on the capacity thresholds.
ServiceabilityThe serviceability functions of Unified Expert Advisor, similar to those of Cisco Unified CM, are conducted primarily using the Real-Time Monitoring Tool (RTMT), which is a Windows or Linux application, downloadable from the Operations, Administration, Maintenance, and Provisioning (OAMP) serviceability page. It functions on any desktop or laptop computer that is running Windows 98, Windows XP, Windows 2000, Windows Vista, or Linux with KDE and/or Gnome client, and that has a screen resolution 800x600 or above. To install RTMT on Windows Vista, you must be logged in as Administrator.
Other serviceability functions are inherited from the Unified Communications Operating System Serviceability application, available via the Navigation drop-down menu on the Unified Expert Advisor OAMP login screen. Both Simple Network Management Protocol (SNMP) versions 1 to 3 and SYSLOG are supported as well.
Some functions are also available via the Unified Communications Operating System command line interface (CLI). These functions are accessible by any Platform Administrator.
Unified Expert Advisor also introduces a new concept known as System Conditions, which piggybacks on the SNMP trap mechanism. System Conditions are defined within the product with either warning or critical severity, and once raised, they persist until they are cleared. Although each raise or clear action also causes an SNMP trap, the condition's current state can be examined using RTMT even if the trap events were missed. (The current version of RTMT does not display System Conditions in an easily readable format, however.) The list of Unified Expert Advisor System Conditions can be found in the Real Time Monitoring Tool Administration Guide for Cisco Unified Expert Advisor, available at http://www.cisco.com.
Root access to the Unified Communications Operating System is available, but as with Unified CM root access, it requires a detailed procedure involving Cisco TAC as well as customer approval. Passwords obtained in this way are valid for only a limited time. On the other hand, root access is not required in order to perform any normal customer or partner activity.
This section describes deployment options for Unified Expert Advisor.
Unified Expert Advisor Components
Unified Expert Advisor may be deployed with either simplexed or duplexed Runtime Servers, and in either case a single Reporting Server may be added. The resulting four options are illustrated in Figure 7-2.
Figure 7-2 Server Deployment Options for Unified Expert Advisor Components
For information on the effects of omitting a reporting server, see Reporting. Also, for information on the trade-offs involved in deploying simplexed versus duplexed Runtime Servers, see High Availability for Runtime Servers
Deploying Multiple Unified Expert Advisor Clusters for Scalability
The current version of Unified Expert Advisor supports a maximum of 3000 expert advisors. A Cisco Unified Presence 6.x cluster, however, can support as many as 10,000 users, and you might want to configure more than 3000 of them as expert advisors. In order to accommodate more expert advisors than are currently supported by a single Unified Expert Advisor, it is possible to deploy multiple independent Unified Expert Advisor clusters as separate peripherals on the same Unified ICM. Each cluster may be simplexed or duplexed, and each may contain a Reporting Server. The Reporting Servers cannot be shared, however.
Different Unified Expert Advisor clusters may be configured to communicate with the same Cisco Unified Presence cluster, as illustrated in Figure 7-3. The assignment queues from those Unified Expert Advisor clusters will simply map to separate skill groups in Unified ICM, but separate skill groups can always be treated as a homogeneous pair by listing them both in the same Queue to Skill Group node.
Figure 7-3 Multiple Unified Expert Advisor Clusters with a Single Cisco Unified Presence Cluster
Note that, if two Unified Expert Advisor clusters share the same Cisco Unified Presence cluster, both will import the same set of Cisco Unified Presence users. Functionally it would be safe to configure them all as expert advisors on both Unified Expert Advisor clusters, but doing so causes reporting and statistical irregularities because each advisor will be counted as two agents in Unified ICM. Therefore, it is important to partition the Cisco Unified Presence user list manually within Unified Expert Advisor so that one set of users is configured as expert advisors in one Unified Expert Advisor cluster and the other set of users is configured as expert advisors in the other Unified Expert Advisor cluster.
Deploying Unified Expert Advisor with Various Cisco Unified Presence Deployments
The Cisco Unified Presence 6.x may be deployed in a number of different ways with respect to both Cisco Unified Presence and Cisco Unified CM clustering. This section describes the degree to which Unified Expert Advisor supports each scenario.
Cisco Unified Presence High Availability
Cisco Unified Presence 6.x and 7.x generally support a cluster configuration that consists of a publisher server and a subscriber server. Clients may be logged in to either server, and messaging flows between them as required. During an outage, it is possible for either the publisher or the subscriber to fail, leaving the other server to handle the full load. With Cisco Unified Presence 6.x, Cisco Unified Personal Communicator clients that are logged into the failed server do not automatically fail-over to the surviving server; and the user must explicitly log out and log in again. With Cisco Unified Presence 7.x, the Cisco Unified Personal Communicator clients are able to do this automatically.
Unified Expert Advisor, however, does not automatically fail-over to the surviving Cisco Unified Presence server. It allows the address of only one Cisco Unified Presence server to be configured; and if that server fails, then Unified Expert Advisor takes itself out of service until the failed server is restored.
Similarly for call control purposes, Unified Expert Advisor can be configured to connect to only one Cisco Unified Presence server's SIP Proxy server. There is currently no capability to automatically retry SIP requests to a second SIP Proxy server.
On the other hand, for the purpose of importing Cisco Unified Personal Communicator and IP Phone Messenger (IPPM) user lists into Unified Expert Advisor, both the publisher and the subscriber can be configured. Unified Expert Advisor will automatically try one and then the other if necessary.
For SIP, instant messaging, and presence purposes, both Unified Expert Advisor runtime servers should be configured to connect to the Cisco Unified Presence publisher only; and for Microsoft Office Communicator deployments, this should usually be the same server that is federated with the Microsoft Office Communications Server (OCS) as a best practice.
Intradomain, Intercluster Deployment
Unified Expert Advisor does not currently support intradomain, intercluster deployments. In this scenario, two (or more) Cisco Unified Presence clusters are configured to work with their own separate Cisco Unified CM clusters. Each Cisco Unified Presence cluster has its own configured user base, but they share with each other a certain amount of information about each user. Thus, a user on one Cisco Unified Presence cluster is able to observe presence of, and send IM messages to, a user on another Cisco Unified Presence cluster.
Unified Expert Advisor, however, does not support this deployment. One Unified Expert Advisor cluster must be connected to exactly one Cisco Unified Presence cluster and can import the user list only for users who reside on that one cluster.
If expert advisors reside on different Cisco Unified Presence clusters, then different Unified Expert Advisor clusters must be deployed as well.
Unified Expert Advisor does not currently support Cisco Unified Presence clusters that are deployed in separate domains. All experts must be located in the same domain.
Deployments in which expert advisors use Microsoft Office Communicator actually work by defining an interdomain federation link between Cisco Unified Presence and Microsoft Office Communicator Server. However, a single Unified Expert Advisor deployment cannot support situations in which some experts are using Cisco Unified Personal Communicator and other experts are using Microsoft Office Communicator as their IM clients. If any use Microsoft Office Communicator, then all must use Microsoft Office Communicator, and their domain name will all be the Microsoft Office Communications Server (OCS) domain name. Therefore even in this case, all experts are located in the same domain, although that domain will be different than that of the Cisco Unified Presence server itself.
Clustering Over the WAN
Cisco Unified Presence 7.0 servers may be deployed as a single cluster split across a WAN link. This type of deployment is known as clustering over the WAN. However, the WAN latency requirements are very strict and difficult to achieve on WAN connections, making such deployments unlikely. As a result, Unified Expert Advisor has not been tested, and currently is not supported, with this configuration.
For more information on clustering over the WAN, refer to the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
Deploying with the Cisco Unified Presence Proxy Server
Cisco Unified Presence contains not only a presence server, but also a SIP proxy server, and both are required for Unified Expert Advisor deployments. The proxy server has two purposes in a Unified Expert Advisor deployment: first, as a way to define the entire SIP dial plan in one place, and second, as an integral element in the Unified Expert Advisor failover strategy.
Although the Cisco Unified Presence 6.x server does not offer failover support, the proxy server does. In addition, Unified Expert Advisor can currently be configured to point to only one such proxy server; failover among SIP proxy servers is not supported.
If Unified CVP is part of the deployment, you might prefer for Unified CVP to use the Cisco Unified Presence publisher as one of its SIP proxy servers, so that you have to configure the dial plan only once. However, this benefit should be weighed against the performance impact that is incurred by making one Cisco Unified Presence server responsible for IM and presence services, SIP proxy services, and (in Microsoft Office Communicator deployments) federation overhead to Microsoft Office Communications Server (OCS), on top of its existing publisher responsibilities.
Relationship Between Unified Expert Advisor Runtime Servers and Unified ICM PGs
Runtime servers may be either simplexed or duplexed. In a simplexed configuration, both simplexed and duplexed Unified ICM PGs are supported, but duplexed Runtime servers require duplexed Unified ICM PGs as well.
The following considerations apply to these types of configurations:
•Any component that is simplexed becomes a single point of failure in the deployment.
•If the expert advisor PIM is co-resident with another PIM (such as a Cisco Unified Communications Manager PIM) that is duplexed, then the Expert Advisor PIM must also be duplexed even if the Runtime Server itself is simplexed. However, there is no machine count penalty for following this requirement because no new machines are being introduced to carry the expert advisor PIMs in this scenario.
Small Deployments with Unified ICM
In order to reduce server count for small deployments, it is possible for PIMs to share Unified ICM PGs and for multiple PGs to be hosted on the same physical machine, as long as all Unified ICM sizing guidelines, co-residency rules, and physical proximity rules are observed. Most Unified Expert Advisor installations include a VRU peripheral (for Unified CVP), a Cisco Unified CM peripheral, and an Expert Advisor peripheral. Cisco Unified CM and Expert Advisor PGs are best located physically near their respective peripherals, but VRU PGs need not be.
The co-residency rules are as follows:
•One machine can host no more than two PGs.
•One PG can host no more than two types of peripherals (types of PIMs).
•In order for one PG to host two types of peripherals:
–It must be configured as a Generic PG; and
–One of the types must be a VRU PG.
In most cases, Setup and the PG Explorer will allow you to configure machines that do not meet these restrictions. However, when you start up the PGs, only two will actually start.
Unified Expert Advisor implements an active/standby high availability model for its runtime servers and a buffering high availability model for its reporting servers.
High Availability for Runtime Servers
Unified Expert Advisor runtime servers operate in an active/standby fashion. Typically the primary server will be active and the backup server (also called the high availability server) will be in standby mode. Under normal conditions, all calls are handled by the active server. The only thing the standby server does is keep track of expert advisor login and presence states, but it does that only in order to avoid having to gather the data all at once if a failover occurs.
The rules for setting up duplexed PGs and Unified Expert Advisor runtime machines, as depicted in Figure 7-4, are as follows:
•PG A should connect to the primary runtime server.
•PG B should connect to the backup runtime server.
•There may be no cross-connections between PG A and the backup runtime server, or vice versa.
This is because the primary and backup servers are envisioned to be located at physically different sites, across a WAN from each other. The WAN link between PG sides is guaranteed (via Unified ICM design guidelines) to be high bandwidth, low latency in nature, but there is no such guarantee for the connection between a PG and its peripheral. Also, transmitting data across a WAN link could lead to security concerns that are not a problem with LAN links.
Figure 7-4 High Availability Deployments with Unified ICM
Runtime server failover relies heavily on the Unified ICM PG's guarantee that it will connect to only one peripheral at a time. Therefore, each runtime server knows it is active if and only if it has an active connection from the Unified ICM PG. There are, in fact, no heartbeats or other direct communications between the two runtime servers, nor are there any heartbeats or other direct communications between the idle side PG and the inactive runtime server.
Each PG and its corresponding runtime server, therefore, fail-over in tandem. If the active runtime server fails or is manually taken out of service, then it disconnects itself from its PG, and Unified ICM causes the standby runtime server's PG to become active. That PG then establishes a connection to the standby runtime server, which causes the standby runtime server to become active.
Similarly, if one PG fails over to its standby counterpart, the corresponding runtime servers fail-over as well.
Call and Expert Advisor Handling During Failover
The disposition of calls upon failover depends on the cause of failover. On the one hand, it could be a software failover, either because the active node is being shut down manually or because of a software failure of some kind. On the other hand, it could be a hardware failover due to either a hardware or network outage. An operating system level restart also acts like a hardware failover. The following table shows the distinction between these two failover modes.
"In-flight" calls are those that have been received by the Unified Expert Advisor runtime server but have not yet been connected to an expert advisor.
Expert advisors log their presence clients into Cisco Unified Presence, not to Unified Expert Advisor, so the presence clients are not affected by a failover. They will, however, receive a Message Set message indicating that there was a technical problem and warning them about conducting call control operations. The standby runtime server automatically takes over the job of managing each advisor's agent state with respect to Unified ICM; however, it does not know which advisors are already talking to callers. Therefore it is possible that some advisors are assumed to be ready and available, and could receive pop-up task offers when they are already on a call, just as they might when talking on the phone for any reason unrelated to Expert Advisor activity. Advisors are of course free to ignore or decline such offers.
High Availability for the Reporting Server
The reporting server is always simplexed and always listening to reporting events from both runtime servers. There is little likelihood that conflicting events will be received because, at any given time, one call is under the control of one runtime server. If conflicting events ever do occur, database triggers automatically prevent them from entering the database.
If the reporting server fails or goes out of service for any reason, reporting events are automatically buffered within the runtime server. The size of this buffer space is configurable, and currently the default of 2 Gbytes is the recommended size. This is enough to support several days of normal operation. If it runs out, however, calls continue to be processed normally but newly arriving reporting events will be lost.
Handling of Reporting Events During Failover
Expert advisor state change events with respect to various assignment queues are continually received by the reporting server. These events are not affected by a runtime server failover; the reporting server will simply continue receiving them from the backup runtime server.
Call events and task events are received by the Reporting Server only at call or task termination time, but they are received by the Expert Advisor PG at both translation routing time and call termination time. This leads to the following conditions (refer to failure type definitions under Call and Expert Advisor Handling During Failover):
The Reporting Server will contain no information about any calls or tasks that were active (had started but not yet terminated) at the time of failover. In Unified ICM, however, there will be one Termination Call Detail (TCD) record for the Expert Advisor peripheral, which will reflect data about the call up to the point at which the failover occurred, and which will contain a status code of 27 (FAILED_SOFTWARE).
The Reporting Server will contain a complete record of any calls and tasks that were active at the time of failover. In Unified ICM, however, there will be one TCD record for the Expert Advisor peripheral, which will reflect data about the call up to the point at which the failover occurred, and which will contain a status code of 27 (FAILED_SOFTWARE).
High Availability for the Configuration Database
The OAMP configuration is stored in an Informix database on the primary runtime server and is copied via Informix's built-in replication mechanism to the backup runtime server. In this way each runtime server can operate on its own, without the other. However, the OAMP web server runs only on the primary runtime server. Therefore, the OAMP administration screens can be accessed only if the primary server is running (but not necessarily active from the perspective of expert advisors and calls).
In addition, a subset of the OAMP configuration is copied to the reporting server. The reporting server uses this information in order to match object identifiers to customer-facing names. It also keeps a history of configuration data so that events which took place prior to a configuration change can be reported with the configuration that was in effect at the time the event was captured.
Although configuration data is copied to multiple places, it is not possible to use that data as a source for rebuilding a damaged primary server. The system administrator must perform regular backups using the Data Recovery Framework (DRF), and restore the configuration from those backups if necessary.
High Availability for Microsoft Office Communicator Server
The federation link between Cisco Unified Presence and Microsoft Office Communications Server (OCS) is not a redundant link. Only one Cisco Unified Presence server in a cluster may link to the OCS. If that Cisco Unified Presence server fails or loses its connection, there is no backup path.
Recommendations for Deploying Unified Expert Advisor
Follow the guidelines and best practices in this section when deploying Unified Expert Advisor.
Using Router Requery
In deployments that include Unified CVP, it is possible for failed calls to reach expert advisors for various reasons to invoke a requery to Unified CCE, which then allows the Unified CCE routing script to control how the call is handled when such a failure occurs. In order to take advantage of this capability, check the Enable Requery check box in the script's Queue to Skill Group node. Doing so causes an "X" branch connector to appear on the node. Calls that successfully reach their destinations normally terminate in the Queue node, but calls that are requeried proceed through that "X" branch to a subsequent node.
The script can determine, by examining a script editor variable, whether the call was requeried due to no-answer, busy, or other connection failure. It may be appropriate at that point to requeue the call by connecting the branch to another Queue node.
If your deployment employs this requery capability, then consider the following notes:
•In general, the second queue node should be different than the first, such as by including more or different skill groups. Otherwise, the call is likely to encounter the exact same result as with the first queue node.
•For the same reason, be careful about looping the script back to the first queue node. It is important to change something, so that the result will be different.
•For sizing purposes, remember that each time a queue node sends the call to Expert Advisor, it appears as a new call to the system. Therefore, the total number of calls reaching Expert Advisor per unit of time, is the number of actual incoming calls plus the number of calls returned to Expert Advisor through requery.
•Expert Advisor itself is not aware of which calls are requeried instances of previous calls. However, it is possible to find such calls in the logs and the historical database because they appear with different ContactIds but the same GUID and the same Unified CCE Router Call Key.
Recovery Following a Failover
If Runtime Server A loses power or otherwise fails over to Runtime Server B, then all new calls are handled by Runtime Server B. If at some point Runtime Server A comes back up, it will remain in Partial Service and Runtime Server B will continue to be the active system. Runtime Server A becomes active again only if you manually shut down Runtime Server B or if it encounters some sort of fault of its own that causes it to fail.
After Runtime Server A has failed over to Runtime Server B, the administrator should make every effort to bring Runtime Server A up again as soon as possible. Once Runtime Server A is running properly, the administrator should manually shut down Runtime Server B, which will cause Runtime Server A to become active again.
It is generally better to have the primary runtime server be the active runtime server because new calls always try to go to Runtime Server A before they try Runtime Server B (per the static route configuration in the SIP proxy server), and a delay is possible. If Runtime Server A is running, even if it is not active, then the delay is very slight and probably not noticeable. But if Runtime Server A is down, then the delay involves a time-out and could amount to a few seconds and be noticeable by callers. (The time-out is configurable in the Cisco Unified Presence proxy server service parameters.)
In cases where Runtime Server A is expected to be down or disconnected for an extended period of time, it would be best to reverse the priorities in the SIP proxy server's static route table so that the backup runtime server rather than the primary runtime server receives the first invite. It is important to remember to restore the original priorities once the primary server is back online.
Another important reason to get the primary runtime server up and running as soon as possible is that OAMP is accessible as long as the primary runtime server is running, even if it is in Partial Service. There is currently no way to promote the backup runtime server to primary.
Route Pattern or Route Point
When you configure the method in which calls are delivered from Cisco Unified CM to Unified CCE, you have two decisions to make. First, do you configure the dialed number to go through a route pattern via a SIP trunk to Unified CVP, or do you configure it to go through a route point to Unified ICM? Second, once the call reaches Unified ICM and begins a routing script, do you force it to transfer to Unified CVP even if no queuing is required?
This section discusses the trade-offs involved.
•If the call is routed through a route point, if the routing script does not contain any SendToVRU node or RunExternalScript node prior to the Queue node, and if expert advisors are available in the referenced skill groups (meaning no queueing is necessary), then the SIP Invite will flow from Cisco Unified CM directly to Unified Expert Advisor and will bypass Unified CVP. This means that Unified CVP ports will not be tied up unnecessarily, but the extra functionality that Unified CVP provides (such as simulated ring tone, re-query in case of failure, and re-query in case of time-out) will not be available.
•If any of the above conditions is not true, then a SIP dialog will be established between Cisco Unified CM and Unified CVP, and another SIP dialog will be established between Unified CVP and Unified Expert Advisor. All the Unified CVP functionality is available in this case, but be aware that one Unified CVP port and license remain tied up through the life of the call (until both the caller and the expert advisor disconnect).
In addition, the call should always be routed through a route point if it is coming from a Unified CCE agent in the form of a consult, conference, or transfer. This allows Unified CCE to track this call as a part of the original call that is being handled by the Unified CCE agent.
Given these trade-offs, the best practice in most cases is for the call to be routed through a route point first, but for the routing script to include at least a SendToVRU node prior to the Queue node. This provides the best reporting and the best call handling functionality, but at the expense of the possibly unnecessary use of a Unified CVP port license for the life of the call.
Also, in deployments that include Cisco Unified CM as a communications manager that does not host Unified CCE agents, there might be no Unified CM PG at all. In that case, all calls from Cisco Unified CM to Unified CCE must go through a route pattern to a SIP trunk to Unified CVP. There is no other option.
Getting Expert Advisors to Answer Calls
Expert advisors are not contact center agents, and as mentioned previously, answering calls is not their primary job function. Various techniques are suggested under Strategies for Managing Extended Ring Time, for ensuring that callers do not wait for advisors for a very long time. Ultimately however, unless advisors are willing to pick up the phone, the enterprise's business model will not succeed.
It is important, therefore, to find non-mechanical ways to encourage advisors to accept calls. Some methods might involve financial incentives, competitions among advisors, consideration during annual reviews, explicitly scheduling experts to take escalation calls, and so forth. This is an issue your enterprise should consider as part of its overall deployment success strategy.
The following series of specific notes describe how best to configure various SIP parameters in a Unified Expert Advisor deployment:
•Cisco Unified Presence SIP Proxy Server — Record Route Header
The default setting of the Add Record Route Header service parameter for the Cisco Unified Presence Proxy Service has varied from one release of Cisco Unified Presence to another. It should be set to OFF.
•Cisco Unified Presence SIP Proxy Server — Maximum INVITE Retransmissions
The default setting of the Maximum INVITE Retransmissions service parameter for the Cisco Unified Presence Proxy Service is 6. However, in a redundant Unified Expert Advisor environment, failover works best when this parameter is set to 2.
User Datagram Protocol (UDP) is preferred over TCP because it detects and reacts to failover situations much more readily. It is usually best to select one protocol and use it on all SIP connections in the deployment. SIP over TLS is not available in the current release.
•Media Termination Points (MTP)
Due to a limitation in the Cisco IOS SIP implementation in some older Cisco IOS releases, an MTP was required in Cisco Unified CM on the SIP trunk that connects to Unified CVP or its SIP proxy server, in order for expert advisors to be able to use Unified CM features to consult, transfer, or conference a call to another destination. If these capabilities were not important in a particular deployment, then the MTP was not required. Refer to the Expert Advisor 7.5(1) Release Notes for more details. In later Cisco IOS releases, this limitation no longer exists and thus the MTP is no longer required.
Unified CVP Time-Outs
Unified CVP 7.0 and later should be configured to limit the amount of time it will allow Unified Expert Advisor to have control of a call without it being answered by an expert advisor. This configuration can be done in Unified CVP under Call Server Configuration > SIP > Patterns for RNA timeout on outbound SIP calls. There should be an entry for the dialed number pattern that corresponds to the set of Translation Route DNISs that are used to transfer the call to Unified Expert Advisor. For those calls, the time-out should be configured to an appropriate number of seconds (typically between 30 and 120) to allow before the Unified ICM routing script is re-queried.
For Unified CVP releases prior to 7.0, there is no way to control this time-out on a per-destination basis. It can be configured, but the setting will apply to all calls being delivered by Unified CVP to any destination.
Scheduling of the Cisco Unified Presence Synchronization Task
The synchronization task that imports the Cisco Unified Presence user list into Unified Expert Advisor is configured to run every day at midnight. This is the default schedule, but it can be changed so that it runs at another time and another interval, even as often as some number of minutes if necessary. However, it should not be run with unnecessary frequency, and it might be appropriate to confine it to run only during the normal system maintenance window. The system administrator should consider how often users are added, updated, or removed from Cisco Unified Presence, and how quickly such changes need to be reflected in Unified Expert Advisor. Keep in mind that a synchronization can always be invoked manually if necessary.
Call Flow Descriptions
This section describes the call flows for various types of calls processed by Unified Expert Advisor.
Inbound Call from PSTN
Figure 7-5 shows the sequence of events that take place as a typical inbound PSTN call is processed.
Figure 7-5 Inbound Call Flow
A typical inbound call arrives from the PSTN via an ingress gateway to Unified CVP. Unified CVP then announces it to Unified ICM through the VRU PIM, and Unified ICM starts a routing script. The routing script can instruct Unified CVP to perform self service, prompt-and-collect, or menu actions, and then it uses a Queue to Skill Group node to queue the call to one or more expert advisor skill groups. While no expert advisors are available in those skill groups, it queues the call via Unified CVP using the VXML gateway.
When at least one expert advisor in one of the relevant skill groups becomes available, Unified ICM asks Unified CVP to deliver the call to the Unified Expert Advisor Runtime Server via translation routing. Unified CVP sends a SIP Invite to the Runtime Server (optionally via the Cisco Unified Presence SIP Proxy Server) and simultaneously begins playing ring tone to the caller. This marks the end of Unified ICM queuing support and the beginning of Unified Expert Advisor control.
Unified Expert Advisor closes the translation route with Unified ICM by sending a Route Request via the Expert Advisor PG. Unified ICM returns the label for the targeted skill group. At this point it is up to Unified Expert Advisor to find an expert advisor in that skill group, called an Assignment Queue (AQ) within Unified Expert Advisor, who is willing to accept the call.
Unified Expert Advisor then orders the list of available experts as specified in the AQ configuration and begins offering the task to one or more of them at a time. If all advisors reject or do not respond at all during the configurable offer-task time-out period, then the next set of advisors in the selected AQ receive the offer. If the entire list is exhausted without any advisor accepting the call, then the call remains in queue in Unified Expert Advisor, with the caller listening to ring tone until either a new advisor becomes available (Unified Expert Advisor will offer the task to him) or Unified CVP withdraws the call and invokes a Unified ICM re-query.
Assuming an expert advisor accepts the call, Unified Expert Advisor immediately delivers the call to that advisor. If the advisor can be reached at several different addresses, Unified Expert Advisor rings only one specific number: either his preferred destination address, one of his non-preferred destination addresses, or any other address that he specifies in his response. The selected address could be a hardware phone, a software phone, a third-party phone, a home phone, a cell phone, or any other device that can be addressed through Cisco Unified CM.
When the expert advisor answers, he and the caller conduct a conversation. If the expert advisor then wishes to hand off the call to another destination or back into the contact center, he may do so using the normal consult, conference, and transfer functions of his phone (assuming he has contracted for such functions from his service provider). That can result in the call returning to Unified Expert Advisor, but it does so as a new call. Unified Expert Advisor is not aware of the relationship between the two calls.
Consult Call from Unified Contact Center Enterprise Agent
This call flow is actually no different from that of an inbound call from the PSTN, as far as Unified Expert Advisor is concerned. The call can come from Cisco Unified CM to Unified CCE either on a route point through its JTAPI interface to Unified CCE or on a route pattern through a SIP trunk to Unified CVP. In either case the same routing script would be executed, and the call flow continues through self-service, queuing, and Unified Expert Advisor as described above. However, the actual SIP-level routing depends on whether the call ends up passing through Unified CVP. For more information, see Route Pattern or Route Point.
Post-Expert Advisor Transfers
After an expert advisor has completed his time with the caller, he might want to consult, transfer, or conference another party. These activities are handled by using only those methods provided by the expert advisor's own switching system. For example, if the advisor is using a Cisco Unified CM hard phone, he can make use of the soft keys on his phone to place the caller on hold and dial another person or route point. This action could end up queuing the advisor or the caller for a traditional contact center agent, or even for another expert advisor. These cases, however, are considered to be new calls into Unified ICM and/or Unified Expert Advisor; call context information is not carried over from the original call into the new call.
While this activity is fully supported in Unified Expert Advisor deployments, Unified Expert Advisor itself plays no role in carrying it out. However, Unified Expert Advisor does pay attention to the information about such actions that are available at the SIP signaling level. If Unified Expert Advisor detects that the expert has transferred the call, or conferenced the call and then dropped out of the conference, it automatically declares that expert to be available again for additional calls. Note, however, that the SIP signaling for the original call continues to flow through Unified Expert Advisor's back-to-back user agent even though there is no longer an expert connected to it, and Unified Expert Advisor continues to track the call's duration and media changes until the caller eventually hangs up.
Finally, this functionality depends on the signaling that Cisco Unified CM provides to Unified Expert Advisor during conference and transfer scenarios. It is not guaranteed to work if a further downstream call control device such as the PSTN or a cellular phone MSC performs the switching. In those cases, the most likely result will be that the expert appears to remain active on the call until the caller disconnects.
Expert Advisor Login
The preceding call flows deal with the process by which calls arrive in the system and reach an expert advisor. This section considers the process by which an expert advisor becomes available to take such calls. Figure 7-6 shows the event sequence by which an expert advisor logs in to Unified Expert Advisor.
Figure 7-6 Expert Advisor Login Sequence
When Unified Expert Advisor first starts up, it logs into Cisco Unified Presence as a two simulated Cisco Unified Personal Communicator users, one from the primary runtime server and one from the backup runtime server. Both simulated users subscribe to presence notifications for all Cisco Unified Presence users who are designated as expert advisors, but only the one on the active runtime server actually conducts IM message exchanges.
When an expert advisor interacts with Cisco Unified Presence by logging in or by setting his presence state to available, a corresponding presence document is forwarded to Unified Expert Advisor. (Presence documents are in the form of XML content attached to a SIP/SIMPLE message.) If the document indicates that the advisor is available, Unified Expert Advisor notifies Unified ICM that the advisor is ready to take calls in all Unified ICM skill groups for which he is qualified. If the document indicates that the advisor is not available, then Unified Expert Advisor notifies Unified ICM that he is no longer ready to take calls on any Unified ICM skill groups.
Note In the current release of Unified Expert Advisor, the idle state is not considered to be unavailable. Idle is the state to which the presence client transitions when there has been no activity on the computer for a configurable period of time.
Sizing and Licensing
The following guidelines apply when sizing various components in a Unified Expert Advisor deployment:
•Unified Expert Advisor
Unified Expert Advisor is licensed according to the number of Cisco Unified Presence users that may be configured as expert advisors and the number of servers in the cluster. There is no separate limit to the number of expert advisors who may be logged in or actively connected to callers. Licenses are strictly enforced, but all license checking is performed at configuration time.
Currently each Unified Expert Advisor cluster supports up to 3000 expert advisors and up to 6000 busy hour call attempts (BHCA) on Cisco MCS-7845 servers. See the chapter on Sizing Unified CCE Components and Servers, page 10-1, for complete details about supported Unified Expert Advisor capacities under various conditions.
Outside of normal SIP and telephony network guidelines, the only significant bandwidth occupied by Unified Expert Advisor is in the link between each runtime server and the reporting server. Reporting event traffic for the number of calls and expert advisors indicated above is about 1.6 megabits per second. No special QoS or latency minimums are required.
•Cisco Unified Communications Manager (Unified CM)
With some older Cisco IOS releases on the gateway, when you size Unified CM for Unified Expert Advisor deployments, it is important to take into account that an MTP resource is required for all calls on the SIP trunk that connects to Unified CVP or its SIP proxy server. (See SIP Configuration.)
•Cisco Unified Presence
Each Unified Expert Advisor runtime server logs one presence user (who must be fully licensed) into Cisco Unified Presence. During startup of either runtime server or of the presence server itself, and every 30 to 60 minutes thereafter, the system goes through the process of subscribing for presence notifications from each configured expert. This process can take several minutes to complete, during which time the presence server experiences a heavy load. However, the presence server works together with Unified Expert Advisor to inject delays as necessary so that the presence server does not become overloaded. Once the systems reach steady state, the presence server load is equal to the number of configured experts issuing typical presence updates to each of the two runtime server presence users.
•Cisco Unified Presence SIP Proxy Server
The load is relatively light, equivalent to about 3 SIP dialogs and 8 to 20 IM messages per call, depending on the number of AQ broadcasts.
See the chapter on Sizing Unified CCE Components and Servers, page 10-1, for detailed information about sizing Unified ICM for Unified Expert Advisor deployments.