EX Engage Connector Conversation Provider Service (EXCP)

EXCP is a component responsible for the conversation injection into the GC EX Org (See Conversation Injection section of the Genesys Cloud EX Integration Guide for more information.

EXCP General Operating Principles

EXCP connects to the default port of an Engage SIP Server and subscribes for a subset of TLib and call monitoring events. Those events are used to obtain information about interactions in the Engage Contact Center. EXCP translates Engage interaction events into the GC events and injects those events into the EX Org using EX REST API. EXCP uses the REST API of the EXCS to obtain the mapping information to translate the Engage object IDs into the GC equivalents.

Two instances of the EXCP should connect to an HA pair of the Engage SIP Servers to support high availability. Both instances connected to the same SIP Server HA pair are subscribed for the same set of events. If one EXCP instance is temporarily unavailable, then the other one continues to listen to the events generated by a SIP Server. Redis is used to deduplicate the events storing only one unique event instance for further processing.

EXCP processes three types of Engage events to build a call representation compatible with the GC call model:

1. Virtual Queue (VQ) DN Events:
   • VQ DNs represent reporting and routing queues in the Engage solution.
   • T-Library events consumed from the VQ DNs: EventQueued and EventDiverted
2. Extension DN Events
   • Extensions DNs is where agents log in to receive or make calls
   • T-Library events consumed from the Extension DNs: EventUserEvent - This event contains the current list of call participants
3. Call Monitoring Events:
   • Those events are not related to any DN and are generated by a SIP Server to provide call progress notifications.
   • Consumed Events: EventCallCreated, EventCallDataChanged, EventCallDeleted, EventCallPartyAdded, EventCallPartyState, and EventCallPartyDeleted

EXCP creates a dedicated SIP Server client to consume each type of events. Those clients can be pointed to one or multiple SIP Servers. Refer to the description of the environment variables VOICE_SERVER_VQ, VOICE_SERVER_AGENT, and VOICE_SERVER_CALL for configuration details.

EXCP Deployment Topologies

SIP Server Roles in Engage Contact Center

SIP Servers can be used in different roles in the Engage Contact Centers. The SIP Server role defines the types of DNs, which are configured in a Switch used by this SIP Server. The SIP Server roles to DN types associated with this role are:

1. Generic:
   • Description: Usually, SIP Server is configured in smaller contact centers where one SIP Server HA pair can handle the load of the whole contact center.
   • DN Types: Any
2. IVR:
   • Description: IVR applications are hosted on RP DNs. SIP Servers are used in this role in larger environments to implement a 2-layer IVR-agent architecture where IVR processing is handled by the IVR SIP Server. After completing the self-service stage, the call is either terminated or routed to an agent located on a different SIP Server.
   • DN Types: Routing Point (RP)
3. Agent:
   • Description: Agent SIP Server is used to host agents and contains the DNs of type Extension. Usually, it is not responsible for any routing logic.
   • DN Types: Extension
4. VQ:
   • Description: VQ SIP Servers is a centralized place for VQ DNs that are used for reporting and routing for all calls on all sites of a contact center.
   • DN Types: Virtual Queue (VQ)

Single-Site Deployment

In smaller environments, one SIP Server HA pair is used to handle the load of the whole contact center. To support this configuration one pair of the EXCP instances is deployed. Both instances are configured to collect all required Engage interaction events from the only SIP Server available in the environment.

Single-Site Deployment with a Dedicated VQ SIP Server

Engage deployment is considered a single-site environment even if two SIP Servers are present but one of them is a VQ SIP Server, which contains only VQ DNs configured on its switch. VQ SIP Server never handles a physical call and is used only for distributing events on behalf of the VQ DNs. In this configuration a single pair of EXCP instances is connected to both SIP Server HA pairs. Call monitoring events and events on agent extensions are received from a generic SIP Server. VQ events are consumed from the VQ SIP Server.

Multi-Site Deployment

For deploying EXCP in a multi-site environment, Genesys recommends using one EXCP pair per SIP Server HA pair Each EXCP in this pair connects to both primary and backup SIP Server instances in an HA pair.

All EXCP instances use the same centralized Redis cache.

Engage Call Model Transformation for the EX Conversation Injection

Engage Call Model Transformation Principles

GC EX conversation model supports a limited number of scenarios listed in the Sample Conversation Injection Scenarios section of the Genesys Cloud EX Integration Guide. Calls are allowed to be injected into the EX Org only if they match one of the supported scenarios.

Basic Engage contact center scenarios such as inbound calls to agents can be mapped to one of the EX supported scenarios with simple translation of the Engage call events to the GC conversation events. More complex scenarios such as transfers can also be mapped but they require some changes to be made to the call event flow. There is also a group of more complex Engage call flows such as conferences, which do not have any matching scenario patterns on the EX side. To avoid injecting unsupported scenarios to the EX Org EXCP monitors compatibility of an Engage call with the EX requirements while the call progresses. As soon as the Engage call goes out of compliance with the supported EX conversation scenarios, EXCP stops injecting interaction events for this call to the EX Org by transitioning this call to a Monitoring Suspension Mode, which is described later in this chapter. Such Engage calls are not fully represented in the EX Org.

Multi-Site Call Conversion to an EX Conversation

A simple multi-site call is depicted:

1. Inbound call arrives on SIP Server SIPS1 where it goes through the IVR application loaded on a Routing Point DN RP1.
2. The call is reported to URS for routing. URS places the call on Virtual Queue DN VQ1 while looking for an available agent.
3. Agent1 selected for the call is located on a different switch. Call is routed to Agent1.
4. Agent1 answers the call and talks to the caller.

The left side of the following diagram represents TLib topology of the Engage call. EXCP reduces a complex Engage multi-site call to one GC EX conversation. The right side shows a mockup of the GC EX Conversation timeline, which users can see in the GC UI. The bar on the right side of the party name in the GC EX conversation timeline represents the time interval when the corresponding party was active in this conversation.

Call Scenarios Not Supported by the GC EX Org

GC EX integration doesn't support the following scenarios, which can be encountered in the Engage contact centers:

1. Conferences
2. Call Supervision
3. Outbound campaign calls of fully automated (agent-less) campaigns and ASM dialing mode with merging two independent calls made to agent and to customer.
4. Calls to the Extension DNs without logged-in agents.
   • Such calls can be encountered in two scenarios:
     1. Engage contact centers can use remote agents/consultants who never log in to an agent desktop
     2. If an Engage agent is not selected for the EX-integration (through folder filtering) and is not mapped to GC, then an Engage call to such agent cannot be injected into the GC EX Org.
5. Multiple independent calls on an agent DN
   • GC EX agent is allowed to have only one main and one consult call at a time. EXCP ignores all other concurrent calls on agent DN.
6. Nested consult calls
   • GC EX call model allows only one consult call made out of the main call. Consult calls made out of other consult calls are not allowed.

Monitoring Suspension Mode

EXCP moves a GC EX conversation into the monitoring suspension mode if one of the GC EX conversation model rules is violated. In this mode EXCP generates only the communicationEnded events for the suspended GC EX conversation to indicate that the corresponding party has left the conversation. EXCP indicates a party removal from the GC EX conversation when corresponding party leaves the Engage call.

A sample activation of the Monitoring Suspension Mode for an Engage conference call process:

1. Inbound call lands on the RP DN and goes through the IVR treatments.
   • EXCP reports to GC that a new conversation is created and caller talks to the IVR application .
2. URS places a call on a VQ DN and starts searching an agent to route the call to:
   • EXCP reports to GC that the IVR party left the call and now call is placed on the ACD queue.
3. URS routes the call to an agent and agent answers the call
   • EXCP reports to GC that a successful user transfer took place and now the caller talks to an agent.
4. Agent initiates a single step conference inviting second agent to the call.
   • EXCP detects an EX call model violation as Conference scenarios are not supported and activates Monitoring Suspension Mode on this call.
   • EXCP doesn't report to GC that the second agent joined the call.
5. First agent leaves the call while caller continues talking to the second agent.
   • EXCP reports to GC that the first agent left the call.
   • GC conversation has only one party, a caller, left at this point because the second agent is not reported to the GC. So, to avoid leaving a call with a single party in GC EXCP reports that the remaining party, a caller, leaves the call.

This example demonstrates how EXCP handles Engage call flows, which do not match any of EX supported scenarios. In this scenario, GC received the information about the call being transferred from ACD queue to the first agent. This information is important for the WFM and Gamification services. However, the information about the presence of the second agent in the call is missing. Also, the duration of the GC conversation is shorter than the one of the corresponding Engage call.

Handling of Unsupported call flows in EXCP

GC EX supports 17 types of call flows. In Engage, when a call is received which does not match any of the supported scenarios, the calls are matched to the nearest possible scenario. If the call could not be matched, then it's marked as ignored.

For these ignored calls,

1. No new parties are added.
2. The call terminates when there is only one active party in GC.

For example, in SSC in Engage, when a third party is added, this is not supported by GC. EXCP ignores adding additional parties and only the first two parties are shown in GC. When either of the first two parties terminates the call, the call is terminated in GC EX.