Agent Greeting is available to agents and supervisors who use IP Phones with Built-In Bridge (BIB). These agents are typically located within a contact center. Phones used with Agent Greeting must meet these requirements:

• The phones must have the BIB feature.

  Note	If you disable BIB, the system attempts to use a conference bridge for agent greeting call flow and raises a warning event.

• Ensure that the phone's firmware is up to date. (Usually, phone firmware upgrades automatically when you upgrade your Unified CM installation.)

• For a list of supported phones for contact center enterprise solutions, see the Compatibility Matrix for your solution at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.html.

1. The incoming call arrives from CUBE or a TDM gateway at CVP.

2. CVP sends the incoming call to Unified CCE.

3. Unified CCE instructs CVP to queue the call.

4. CVP sends the call to the Voice Browser for VRU treatment.

5. When an agent is available, Unified CCE sends the agent number to CVP.

6. CVP sends the call to Unified CM.

7. Unified CM establishes the connection to the agent phone.

8. The caller connects to the agent phone and stops hearing the ringback.

9. Unified CCE determines which CVP to invoke, and instructs Unified CM to tell the phone BIB to open a stream to CVP.

10. Unified CCE and CVP shake hands to set the trigger for CVP to let it know which greeting to play.

11. CVP instructs the Voice Browser to have the Media Server play the greeting.

12. The phone's BIB mixes the greeting. After the greeting plays, CVP disconnects and the agent speaks with the caller.

Following are the concepts that are to be handled in a VAV application. For more information on these concepts, see Google's Dialogflow documentation at https://cloud.google.com/dialogflow/docs/.

Note	The VAV feature is supported only on VVB. It is not supported with the VXML Gateway.

Follow these requirements when implementing Cisco Outbound Option:

• Configure abandon to VRU in agent-based campaigns. Telemarketing laws often require this behavior.

• Schedule large imports of the contact list and Do-Not-Call list during off-hours because the Campaign Manager runs on the same system as the Logger.

• Do not use Cisco IP Communicator softphone for agents configured for Cisco Outbound Option. IP Communicator can introduce an extra delay in transferring customer calls to the agent.

• An IPv6 client cannot import to Outbound Option.

• Finesse IP Phone Agent (IPPA) does not support Cisco Outbound Option.

• If you use the redundant Campaign Manager, Outbound Option Importer, and Database, your databases are larger:

  • Do Not Call records require more space. For comparison, 60 million DNC records require about 1 GB of extra disk space.

In many Outbound Option deployments, all components are centralized; therefore, there is no WAN network traffic to consider.

For some deployments, if the outbound call center is in one country (for example, India) and the customers are in another country (for example, US), then consider the WAN network structure under the following conditions:

• In a distributed Outbound Option deployment, when the Voice Gateways are separated from the Outbound Option Dialer servers by a WAN.

• When using Unified CVP deployments for transfer to a VRU campaign, and the Unified CVP servers are separated from the Outbound Option Dialer servers by a WAN. Provide Unified CVP with its own Cisco Unified SIP Proxy Server in the local cluster to reduce the WAN traffic.

• When deploying a SIP Dialer solution for transfer to a VRU campaign, and the Cisco Unified SIP Proxy Servers for the SIP Dialers are separated from the Outbound Option Dialer servers by a WAN.

• When the third-party Recording Server is separated from the Outbound Option Dialer servers by a WAN, configure the recording server local to the Voice Gateways.

Adequate bandwidth provisioning is an important component in the success of the Outbound Option deployments.

In your callback script, you can establish criteria for offering a caller courtesy callback. These are examples of callback criteria that you can establish:

• Expected wait for a customer in queue exceeds some maximum number of minutes, based on your average call handling time per customer.

  Note	The included sample scripts use this method for determining callback eligibility.

• Assigned status of a customer. You can offer gold customers the opportunity to be called back, instead of remaining on the line.

• The particular service that a customer requests. You can establish sales calls or system upgrades as callback criteria.

If the caller opts for a callback, they leave their name and phone number. Their request remains in the system. The system places a callback to the caller when the Estimated Wait Time (EWT) reaches the correct value. The caller answers the call and confirms that they are the original caller, and the system connects the caller to the agent after a short wait.

Note	Courtesy Callback is also supported for IP-originated calls.

A typical call flow for this feature follows this pattern:

1. The call arrives at Unified CVP and the call is treated in the VRU environment.

2. The Call Studio and Unified CCE Courtesy Callback scripts determine if the caller is eligible for a callback based on your rules.

3. If the caller is eligible, the system announces the EWT and offers the caller a callback when an agent is available.

4. The caller chooses what to do:

   1. If the caller chooses not to use the callback feature, queuing continues.

   2. If the caller chooses to receive a callback, the system prompts the caller to record their name and to key in their phone number.

5. The system writes a database record to log the callback information.

   Note	If the database is not accessible, the system does not offer a callback to the caller.

6. The caller disconnects from the TDM side of the call. However, the IP side of the call in Unified CVP and Unified CCE is still active. This keeps the call in the same queue position. No queue music plays, so Voice Browser resources used during this time are less than for a caller actually in the queue.

7. When an appropriate agent is close to being available (as determined by your callback scripts), then the system calls the person back. The system announces the recorded name when the callback is made to ensure that correct person accepts the call.

8. A VRU session asks the caller to confirm that they are the correct person and that they are ready for the callback.

   If the system cannot reach the callback number (for example, busy lines, RNA, or network problems), then the call is not sent to an agent. The call also does not go to the agent if the caller does not confirm that they are the correct person. The agent is guaranteed that someone is waiting when they take the call. The system assumes that the caller is already on the line by the time the agent gets the call.

   This feature is called preemptive callback because the system assumes that the caller waits a minimal time for the agent and the caller is on the line when the agent answers.

9. The system presents the call context on the agent screen-pop.

If the system cannot reach the caller after a configurable number and frequency of retries, the callback cancels and the database status updates appropriately. You can run reports to determine if any manual callbacks are necessary based on your business rules.

See the Configuration Guide for Cisco Unified Customer Voice Portal at https://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html for a call flow description of the scripts providing the Courtesy Callback feature.

Consider the following design impacts for Courtesy Callback feature:

• The callback uses the same Ingress Gateway through which the call arrived. The outbound calls cannot be made on any other Egress Gateway.

• Queue calls that allow callback on a Unified CVP VXML Server.

• Courtesy Callback requires the Unified CVP Reporting Server.

• Answering machine detection is not available for this feature. During the callback, the caller is prompted with a brief VRU session message and acknowledge with DTMF that they are ready to take the call.

• Calls that are transferred to agents using DTMF *8, TBCT, or hookflash cannot use Courtesy Callback.

• Courtesy Callback doesn't support Agent call transfers to the CCB Queue, over a computer telephony integration (CTI) route point.

• Callbacks are a best-effort function. After a limited number of attempts to reach a caller during a callback, the callback is terminated and marked as failed.

• Configure the allowed or blocked numbers that Courtesy Callback uses to place calls through the Unified CVP Operations Console .

• The media inactivity detection feature on the Voice Browser can affect waiting callback calls. For more information, see the Configuration Guide for Cisco Unified Customer Voice Portal.

• Courtesy Callback call flow routed via CUCM is not supported, even though they originate at CUBE.

• Courtesy Callback requires an accurate EWT calculation for its optimal behavior.

  Do the following to optimize the EWT, when using Precision Queues for Courtesy Callback:

  • Queue the calls to a single Precision Queue

  • Do not include a Consider If expression when you configure a step.

  • Do not include a wait time between steps or use only one step in the Precision Queue.

    Note	Use simple Precision Queue definitions (for example, with one step and one-to-one agent mapping). The complexity of Precision Queues makes calculating accurate EWT difficult.

• Courtesy Callback supports 900 calls with 10 CPS. One reporting server can be configured to support 900 CCB calls simultaneously with standard reporting enabled.

Note	CCB does not support the use of SRTP.

Expanded Call Context (ECC) variables enable you to set business relevant data for transfer to the agent desktop. Unlike the call variables, you can configure the size, format, and the name of each ECC variable. You use an ECC payload to pass defined sets of ECC variables, the members of that ECC payload. An ECC payload holds 2,000 bytes. The Router can store approximately 6,000 bytes of ECC variables for each call. If you exceed the system-wide limit on ECC variable contents, the solution generates events to warn you.

The solution includes an ECC payload named "Default" for backward compatibility. If your solution does not require more ECC variable space, you only need the Default payload. If your solution only has the Default payload, the solution automatically adds any new ECC variables to the Default payload until it reaches the 2000-byte limit.

Note	You cannot delete the Default payload. But, you can change its members. CVP, Outbound Option, Multi-Channel, and the ECC variables consume some of the space in the Default payload.

Create your ECC payloads to carry the ECC variables for a particular interface:

Note	For ECC payloads to a CTI client, the size limit is 2,000 bytes plus an extra 500 bytes for the ECC variable names. Unlike other interfaces, the CTI message includes ECC variable names.

Only one ECC payload can have scope at any time during a call. You set which ECC payload has scope in the scripting environment. The solution uses the Default payload unless you override it.

For conferences and transfers, in general, use the same ECC payload through the call flow. The variable merging behavior is more complex when merging two calls with different ECC payloads. For more information, see the Scripting and Media Routing Guide for Cisco Unified ICM/Contact Center Enterprise.

You can set UUI by Unified CCE scripts and extract it by Unified CVP for resending in SIP messages.

UUI processing scenarios:

• You can have GTD (generic type descriptor) data in the inbound call leg of the SIP INVITE message in the mime body format for GTD. In this case, Unified CVP saves the GTD data as inbound GTD and passes the UUI portion (if present) to Unified CCE.

  Cisco IOS gateways support this GTD format on outbound VoIP dial peers with SIP transport.

  If Unified CCE modifies the data, it sends the modified UUI back to Unified CVP. Unified CVP converts the UUI data from Unified CCE into hex, modifies the UUS (if present), and overwrites the inbound GTD value. Unified CVP only modifies the UUS portion, using the format:

  UUS,3,<converted Hex value of data from Unified CCE>

  Unified CVP preserves the rest of the GTD parameter values, saving the values as they arrived from the caller GTD.

• If the inbound call leg has no GTD, Unified CVP prints a message on the trace stating "No GTD Body present in Caller Body." The call then continues as a regular call.

Note	Unified CCE passes the modified UUI in the user.microapp.uui ECC variable or the Call.UsertoUserInfo variable. If you use both variables, the Call.UsertoUserInfo variable takes precedence.

Modified GTD is set in the outbound INVITE mime body from CVP SIP B2BUA, which includes IP originated callers and TDM callers. If a DTMF label for outpulse transfer is received on a connected call, then the BYE message is sent with the GTD only if Unified CCE passes UUI. The BYE message comes immediately after the SIP INFO with DTMF.

Note	You cannot use the UUI data transfer feature with Hookflash or Two B Channel Transfer (TBCT).

UUI in Unified CCE Scripts

To extract the UUI in your Unified CCE Script, look at the user.microapp.uui Call ECC variable and the Call.UserToUserInfo variable. By using the SET node on either one of these variables, you can set the variable on the outbound direction of the call.

Setting Call.UserToUserInfo variable takes precedence over using the ECC variable.

Note	Unified CVP sends a BYE message on the DTMF label only if Unified CCE passes UUI.

If a BYE message is received, then the GTD from the received BYE is used to send it on the other leg.

Configure the Ingress Gateway with signaling forward unconditional, so that GTD with UUI and UUS are forwarded on the VoIP side. For example:

voice service voip
        signaling forward unconditional

VER,1.00
PRN,t1113,*,att**,1993
FAC,
UUS,0,(hex encoded UUI string here)

Use mixed codecs to avoid transcoders and DSP resources. Define a dual codec at the ingress and egress gateways and Unified CM. The VRU automatically negotiates the call as G.711. The system then renegotiates the call as G.729 or G.711 for the caller-agent conversation.

Design impacts for mixed codec are:

• A SIP trunk that only supports G.729 forces the use of transcoders.

• Certain features, such as Whisper Announcement, require universal transcoders for G.729 to G.729 interworking.

• If transcoders are required due to single G.729 codec, use Unified CM controlled transcoding resources. They trigger automatically for any codec mismatch.

• Sizing of appropriate transcoding and universal transcoding resources are required based on call flows, supplementary services, and certain integrated features.

Unified Mobile Agents can sign in to Unified CCE with any PSTN phone that gets routed to a Cisco Voice Gateway. Mobile agents also require an agent desktop.

You can use any Voice Gateway that Unified CCE supports for mobile agents. You can register the Voice Gateway with the same Unified CM cluster as the Agent PG or with another cluster. The caller (ingress) and mobile agent (egress) Voice Gateways can use either MGCP or SIP.

Note	If you enable Silent Monitoring, use different Voice Gateways for ingress and egress.

Unified Mobile Agents can use a Cisco IP Phone that is configured for SIP. Calls to mobile agents can also originate from SIP IP Phones.

For improved Unified CM performance, use Extension Mobility, instead of Unified Mobile Agent, for mobile agents with IP Phones on the same cluster as the Agent PG. Because the IP Phone device is associated with the JTAPI user, there is a small performance hit on Unified CM for making that association.

Consider the following factors when designing a Unified Mobile Agent solution:

• If you use SIP trunks, configure Media Termination Points (MTPs). This requirement also applies if you use TDM trunks to interface with service providers. For detailed information, see Cisco Unified Contact Center Enterprise Features Guide at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.html.

• Enabling the use of an MTP on a trunk affects all calls that traverse that trunk, even non-contact center calls. Ensure that the number of available MTPs can support the number of calls traversing the trunk.

Multi-Line Agent Control (MLAC) is a Cisco CCE agent peripheral setting which enables reporting and call control for calls on the secondary extensions. Use of MLAC imposes some restrictions, such as:

• No call waiting

• A limit to four extensions for each agent phone

• No shared lines between agents

• Applies to all phones on a given peripheral when enabled

The solution does not track call activity on an unmonitored secondary extension. A secondary extension can have PBX functions that are not generally associated with contact center actions, like the use of shared lines.

Unified CCE supports E.164 dial plans and provides partial support for the ‘+’ prefix as follows:

• Agent extensions cannot include the ‘+’ character.

• Agent secondary lines cannot include the ‘+’ character if the agent peripheral has “All Lines” Agent Control enabled.

• The VRU cannot include the '+' prefix unless you route DNs through a CTI Route Point.

• Dialer-imported contact numbers and campaign prefixes cannot include the ‘+’ prefix.

• Agents can dial the ‘+’ prefix with an E.164 number through their Cisco Finesse desktop.

• Agents can dial the ‘+’ prefix with an E.164 number through their phones.

For contact centers that advertise the agent extension outside of the contact center, these considerations apply:

• Use transformation patterns to add the ‘+’ prefix to the calling number on outgoing calls. You can use Calling Party Transformation CSS for phone configuration.

• To route incoming calls addressed to an E.164 number with the ‘+’ prefix, use called party transformations on the translation patterns to strip the ‘+’ prefix from the called number.

• The Attendant Console does not have visibility into the phone status.

The caller is typically asked if they want to participate in a survey after the call. Your solution can determine based on dialed numbers to invoke the post call survey at the end of a call. When the customer completes the conversation with an agent, the customer is automatically redirected to a survey. When the agent ends the call, it initiates the Post Call Survey.

A customer can use the keypad on a touch tone phone and voice with ASR/TTS to respond to questions asked during the survey. For the solution, the post call survey call is just like another regular call. The Post Call Survey retrieves the call context information from the original customer call.

Observe the following conditions when designing a Post Call Survey:

• A Post Call Survey initiates when the last agent ends the call. The call routing script launches a survey script.

• The mapping of a dialed number pattern to a Post Call Survey number enables the Post Call Survey feature for the call.

• The value of the expanded call variable user.microapp.isPostCallSurvey controls whether the call transfers to the Post Call Survey number.

  • If user.microapp.isPostCallSurvey is set to y (the implied default), the call transfers to the mapped post call survey number.

  • If user.microapp.isPostCallSurvey is set to n, the call ends.

  • To route all calls in the dialed number pattern to the survey, your script does not have to set the user.microapp.isPostCallSurvey variable. The variable is set to y by default.

• You cannot have a REFER call flow with Post Call Survey. REFER call flows remove Unified CVP from the call. But, Post Call Survey needs Unified CVP because the agent has already disconnected.

• For Unified CCE reporting purposes, the Post Call Survey call inherits the call context for the initial call. When a survey starts, the call context of the customer call that was transferred to the agent replicates into the call context of the Post Call Survey call.

• The expanded call variable isPostCallSurvey will be cached only when the UCCE router generates a label for CVP.

Unlike skill groups, a precision queue breaks down attribute definitions to form a collection of agents at an attribute level. The agents who match the attribute level of the precision queue become associated with that precision queue.

With precision queues, an English Sales queue involves defining the attributes English and Sales, and associating agents with those traits to those attributes. The precision queue English Sales dynamically maps all agents who have those traits to the precision queue. You can also define more complex proficiency attributes to associate with those agents. This enables you to build, in a single precision queue, multiple proficiency searches like English Language Proficiency = 10 and Sales Proficiency = 5.

To match the English Sales queue with skill groups, you set up two separate skill groups, one for each of the attributes. With precision queues, you can refine agents by attributes. With skill groups, you define a skill group and then assign agents to it.

At a high level, consider a 5-step precision queue which first checks if the caller is Premium Member:

1. Attribute: Skill > 8 - Consider If: Caller is Premium Member

2. Attribute: Skill > 6

3. Attribute: Skill > 4

4. Attribute: Skill > 3

5. Attribute: Skill >= 1

John, who is not a premium customer, calls 1-800-repairs. The system sends John's call to this precision queue. The precision queue works like this:

1. Since John is not a premium customer, he is immediately routed out of Step 1 (because of the Consider If on Step 1).

2. The call moves into Step 2 where he waits for an agent with a Skill greater than 6 to answer his call.

3. After the Step 2 wait time expires, John's call moves to Step 3 to wait for an agent with a Skill greater than 4.

4. After the Step 3 wait time has expired, John's call moves to Step 4 to wait for an agent with a Skill greater than 3.

5. When it arrives at Step 5, John's call waits indefinitely for an available agent. This step applies to any call because there is no routing logic past this step.

The call goes through each successive step to expand the pool of available agents. Eventually, when you reach the last step, the call waits for the largest pool of potential agents. With each extra step, the chances increase that there is an available agent to handle the call. This also puts the most valuable and skilled agents in the earlier precision queue steps. Calls come to them first before moving on to the less appropriate agents in later steps.

The following contact center solution components support SSO:

• Unified CCE—Agent and Supervisor interfaces

• Cisco Finesse—Agent and Supervisor interfaces

• Cisco Unified Intelligence Center—Agent and Supervisor interfaces

• Customer Collaboration Platform—Task Routing interface

• Enterprise Chat and Email—Agent and Supervisor interfaces through the ECE gadget for Cisco Finesse

• Unified Contact Center Management Portal (Unified CCMP)

SSO uses Security Assertion Markup Language (SAML) to exchange authentication and authorization details between the enterprise identity provider (IdP) and the Cisco IdS.

When a user browses to a web page for an SSO-enabled service, the authentication request is redirected to the Cisco IdS. Cisco IdS generates a SAML authentication request and directs it to the Identity Provider. The IdP presents a sign-in page to the user at the browser to collect the user's credentials. After the IdP authenticates the user, the IdP issues a SAML assertion to the Cisco IdS. The assertion contains trusted statements about the user.

When the SAML assertion is received, the Cisco IdS uses the Open Authorization (OAuth) protocol to complete authorization with the requested service. The service may present an approval page to the user to enable specific resources.

Together SAML and OAuth make it possible for a user to authenticate while only exposing user credentials to the authentication provider. The username and password are only presented to the IdP. The contact center solution applications and services do not see the user information. Only the SAML assertion and the OAuth token are exchanged.

The standard call flow with Whisper Announcement is as follows:

1. Incoming call arrives at CVP from the carrier.

2. CVP sends the call to Unified CCE.

3. Unified CCE instructs CVP to queue the call.

4. CVP sends the call to the Voice Browser.

5. Unified CCE sends the agent label with the whisper announcement prompt.

6. CVP sends the call to Unified CM.

7. Unified CM sends the call to the agent phone.

8. The caller continues to hear ringback. The agent hears the whisper announcement.

9. When the whisper announcement ends, the caller connects to the agent.

Whisper Announcement has these limitations:

• Announcements do not play for outbound calls made by an agent. The announcement plays for inbound calls only.

• For Whisper Announcement to work with agent-to-agent calls, use the SendToVRU node before you transfer the call to the agent. Transfer the call to Unified CVP before you transfer the call to another agent. Then, Unified CVP can control the call and play the announcement, regardless of which node transfers the call to Unified CVP.

• Announcements do not play when the router selects the agent through a label node.

• CVP Refer Transfers do not support Whisper Announcement.

• Whisper Announcement supports Silent Monitoring. However, for Unified Communications Manager-based Silent Monitoring, supervisors cannot hear the announcements themselves. The supervisor desktop dims the Silent Monitor button while an announcement plays.

• Only one announcement can play for each call. While an announcement plays, you cannot put the call on hold, transfer, or conference; release the call; or request supervisor assistance. These features become available again after the announcement completes.

• The codec settings for Whisper Announcement recording and the agent's phone must match. For example, if Whisper Announcement is recorded in G.711 ALAW, the phone must also be at G.711 ALAW. If Whisper Announcement is recorded in G.729, the phone must support or connect using G.729.

• In an IPv6-enabled environment, Whisper Announcement might require extra Media Termination Points (MTPs).