Voice

The ASAPP Voice Agent Desk includes web-based agent-assist services, which provide telephone agents with a machine learning and natural-language processing powered desktop. Voice Agent Desk augments the agent’s ability to respond to inbound telephone calls from end customers.

Voice Agent Desk augments the agents by allowing quick access to relevant customer information and provides actionable suggestions that ASAPP infers from the analysis of the ongoing conversation. The content, actions, and responses ASAPP provides to agents is meant to augment the agent’s ability to respond quickly and more effectively to end customers.

Voice Agent Desk interfaces with relevant customer applications to enable desired features.

The ASAPP Voice Agent Desk is not in the call-path but is more of an active listener, and uses two different integrations to provide the real-time augmentation:

• SIPREC - you enable SIP RECording on the customer Session Border Controllers (SBC) and route a copy of the media stream, call information, and metadata per session to ASAPP.
• CTI Events - ASAPP subscribes to telephony events of the voice agents via the CTI server (login, logout, on-hook, off-hook, etc.)

You associate and aggregate the media sessions and CTI events within the ASAPP solution and use them to power the agent augmentation features presented in Voice Agent Desk to the agents.

The ASAPP Voice Agent Desk solution provides agents with the real-time features that automate many of their repeatable tasks. Agents can use Voice Agent Desk for:

• The real-time transcript
• Conversation Summary - where agents add notes and structured data tags that ASAPP suggests as well as disposition the call during the interaction and once it is complete.
• Agents login to Voice Agent Desk via the customer’s SSO.
• Customer information (optional)
• Knowledge Base integration (optional)

​

Customer Current State Solution

ASAPP works with you to understand your current telephony infrastructure and ecosystem, including the type of voice work assignment platform/s and other capabilities available, such as SIPREC.

​

Solution Architecture

After the discovery of the customer’s current state is complete, ASAPP completes the architecture definition, including integration points into the existing infrastructure. You can deploy the ASAPP media gateways and media gateway proxies within your existing AWS instance or within ASAPP’s, providing additional flexibility and control.

​

Network Connectivity

ASAPP will determine the network connectivity between your infrastructure and the ASAPP AWS Virtual Private Cloud (VPC) based on the architecture, however, there will be secure connections deployed between your data centers and the ASAPP VPC.

​

Port Details

You can see ports and protocols in use for the Voice implementation depicted in the following diagram. These definitions provide visibility to your security teams for the provisioning of firewalls and ACL’s.

• SIP/SIPREC - TCP (5060, 5070-5072)
  • SBC to Media Gateway Proxies
  • SBC to Media Gateway/s
• Audio Streams - UDP <RTP/RTCP port range>
• CTI Event Feed - TCP <vendor specific>
• API Endpoints - TCP 443 In customer firewalls, you must disable the SIP Application Layer Gateway (ALG) and any ‘Threat Detection’ features, as they typically interfere with the SIP dialogs and the re-INVITE process.

​

Data Flow

The Voice Agent Desk Data Flow diagram illustrates the PCI Zone within the ASAPP solution. The customer SBC originates the SIPREC sessions and the media streams and sends them to ASAPP media gateways, which repackage the streams into secure WebSockets and sends them to the Voice Streamer within the PCI zone. ASAPP encrypts the data in transit and at rest.

The SBC does not typically encrypt the SIPREC sessions and associated media streams from the SBC to the ASAPP media gateways, but usually encapsulates them within a secure connection. You are responsible for the compliance/security of the network path between the SBC and the media gateways, in accordance with applicable customer policies.

​

SIPREC and CTI Correlation and Association

In order to be able to associate the correct audio stream and the correct agent and agent desktop, ASAPP must associate the audio session and the CTI events of the particular agent.

ASAPP assigns voice agents a unique Agent ID and adds it to the SSO profile as a custom attribute. ASAPP will then map this to the Agent ID within ASAPP.

You configure the SBCs to set a unique call identifier, such as UCID (Avaya) or GUID/GUCID (Cisco), etc. on inbound calls, which provides ASAPP the means to correlate the individual SIPREC stream with the CTI events of the correct agent.

The SBCs will initiate a SIPREC session INVITE for each new call. With SIPREC, the customer SBC and the ASAPP media gateway negotiate the media attributes via the SDP offer/answer exchange during the establishment of the session. The codec/s in use today are:

1. G.711
2. G.729

Traffic and load considerations:

• Total number of voice agents using ASAPP -<total agent count>
• Maximum concurrently logged in agents <max concurrent agent count>
• Maximum concurrent calls at each SBC pair -<max number of current offered calls to SBC/s>
• Maximum calls per second at each SBC pair -<max calls per second offered to the SBC>

​

Load Balancing for ASAPP Media Gateway Proxies

In order to distribute traffic across all of the media gateway proxies, the SBCs load balance the SIPREC dialogs to the ASAPP MG Proxies. To facilitate this, you configure the SBCs with a proxy list that provides business continuity and enables the fail-over to the next available proxy if one of the proxies becomes unavailable.

Session Recording Group Example:

The customer data center SBCs use different orders for the media gateway proxy list.

Data Center 1:

1. MG Proxy #1
2. MG Proxy #2
3. MG Proxy #3

Data Center 2:

1. MG Proxy #3
2. MG Proxy #2
3. MG Proxy #1

​

Media Failover and Survivability

​

Session Border Controller (SBC) to Media Gateways (MG) and Proxies

• Typically unencrypted signaling and audio through a secure connection/private tunnel
  • You can encrypt the traffic in theory, but the SBC has costs and scale limitations associated with encrypting traffic, as well as cost increases to MGs as you will need more instances.
• ASAPP accepts SIPREC dialogs, but initially sets SDP media to “inactive,” which pauses the audio while in the IVR and in queue.
  • The ASAPP media gateway will re-invite the session and re-negotiate the media parameters to resume the audio stream when the agent answers the call.

• SIP RFC handles some level of packet loss and re-transmissions but if the SIP signal is lost, the SIPREC dialog will be torn down and the media will no longer be sent.
• Media is sent via UDP.
  • No retransmissions so packet loss or disconnects result in permanent loss of the audio.
• Proxies are transactionally stateless.
• No audio is ever sent to/through proxies, all audio goes directly to media gateways.
  • Proxies are no longer in the signal path after the first transaction.
• If a proxy fails or is disconnected, SBCs can “hunt” or failover to the next proxy in it’s configuration.
  • No existing calls are impacted.
• If media gateways fail or are disconnected, the next SIP transaction will fail and the existing media stream (if resumed) will be sent via UDP to nothing (media is lost).
• Media gateways use regular SIP OPTIONS sent to static proxies that indicate if they are available and their current number of calls.
• Proxies use this active call load to evenly load balance to the least used media gateway.
  • As well as dynamically pick up when a media gateway is no longer available or new ones come online.
• Any inbound calls coming in over ISDN-PRI/TDM trunk facilities will not have associated SIPREC sessions, as these calls do not traverse the SBC.

​

Media Gateways to ASAPP Voice Streamers

• Secure websocket initiated per stream (2 per call) to the ASAPP Voice Streamer
• Media gateways do not store media, all processing is done in memory.
• Packet loss can be tolerated a little with TCP retransmissions.
• Buffer overrun audio data in the media gateway is purged instantly (per stream).
• If a secure websocket connection is lost, the media gateway will attempt a limited number of reconnections and then fail.
• If a voice streamer fails, a media gateway will reconnect to a new streamer.
• If a media gateway fails, the SIPREC stream is lost and the SBC can no longer send audio for that group of calls.

​

Integration

​

API Integration

Integration to existing customer systems enable ASAPP to call for information from those systems to present to the agent, such as:

• customer profile information
• billing history/statements
• customer product purchases
• Knowledge Base

Integration also enables ASAPP to push information to those systems, such as disposition notes and account changes/updates.

ASAPP will work with you to determine use cases for each integration that will add value to the agent and customer experience.

​

Custom Call Data from CTI Information

In many instances, CTI will carry end customer specific information about the end customer and the call. This may be in the form of User-to-User Information (UUI), Call Variables, Custom NamedVariables, or Custom KVList UserData. ASAPP uses this data to provide more information to agents and admins. It may contain information that provides customer identity information, route codes, queue information, customer authentication status, IVR interactions/ outputs, or simply unique identifiers for further data lookup from APIs. ASAPP extracts the custom fields and leverages the data in real-time to provide agents as much information as possible as part of the initial part of the interaction.

Each environment is uniquely different and ASAPP needs to understand what data is available from the CTI events to maximize relevant data to the agent and for voice intelligence processing.

Examples:

Avaya

UserToUserInfo: “10000002321489708161;verify=T;english;2012134581”

Cisco

CallVariable1:10000002321489708161
CallVariable7:en-us
user.AuthDetect:87

Genesys

userAccount:10000002321489708161
userLanguage:en
userFirstName:John

Twilio

<Parameter name=”FirstName” value=”John”/>
<Parameter name=”AccountNum” value=”10000002321489708161”/>
<Parameter name=”Language” value=”English”/>
<Parameter name=”VerficationStatus” value=”True”/>

​

SSO Integration

Single Sign-On (SSO) allows users to sign in to ASAPP using their existing corporate credentials. ASAPP supports Security Assertion Markup Language (SAML) 2.0 Identity Provider (IdP) based authentication. ASAPP requires SSO integration to support implementation.

To enable the SSO integration, the customer must populate and pass the Agent Login ID as a custom attribute in the SAML payload. Then, when a user logs in to ASAPP and authenticates via the existing SSO mechanism, the Agent Login ID value is then passed to ASAPP via SAML assertion for subsequent CTI event correlation.

The ASAPP Voice Agent Desk supports role-based access. You can define a specific role for each user that will determine their permissions within the ASAPP platform. For example, you can define the “app-asappagentprod” role in the Active Directory to send to ASAPP via SAML for those specific users that should have access to ASAPP Voice Agent Desk only. You can define multiple roles for an agent, such as access to Voice Agent Desk, Digital Agent Desk, and Admin Desk. You must define roles for voice agents and supervisors and include them in the SAML payload as a custom attribute.

The table below provides examples of SAML user attributes.

​

Call Flows

Once an inbound Automatic Call Distribution (ACD) call is connected to an agent, the agent may need to transfer or conference the customer in with another agent/skill group. It is important to identify and document these types of call flows, when the transcript and customer data needs to be provided to another agent due to a change in call state. Then ASAPP will test these call scenarios as part of the QA and UAT testing process.

These scenarios include:

• Cold Transfers
  • The agent transfers the call to a queue (or similar) but does not stay on the call.
• Warm Transfers
  • The agent talks to the receiving agent prior to completing the transfer, in order to prepare the agent with the context of the call/customer issue.
• Conferences
  • The agent conferences in another agent or supervisor and remains on the call.
• Other
  • Customer call back applications or other unique call flows.

​

Speech Files for Model Training

To prepare for a production launch, ASAPP will train the speech models on the customer language and vocabulary, which will provide better transcription accuracy. ASAPP will use a set of customer call recordings from previous interactions.

You will need to provide ASAPP with a minimum of 1,000 hours of agent/customer dual-channel/speech separated media files in .wav format with a sample rate of 8000 and signed 16-bit Pulse-Code Modulation (PCM) in order for ASAPP to train the speech recognition models.

• ASAPP will set up an SFTP site in our PCI zone to receive voice media files from you. You will provide an SSH public key and ASAPP will configure the SFTP location within S3.
  • ASAPP prefers that you redact the PCI data from the provided voice recordings. Regardless, ASAPP will use its media redaction technology to remove sensitive customer data (Credit Card Numbers and Social Security Numbers) from the recordings to the extent possible. In addition to the default redaction noted above, ASAPP can customize redaction criteria per your requirements and feature considerations.
• The unredacted voice media files will remain within the PCI Zone.
• ASAPP will use a combination of automated and manual transcription to refine our speech models. Data that ASAPP shares with vendors goes through the redaction process described above and is transferred via secured mechanisms such as SFTP.

​

Non-Production Lower Environments

As part of our implementation strategy, ASAPP will implement two lower environments for testing (UAT and QA) by both ASAPP and customer resources. It is important that the lower environments do not use production data, including the audio data, as it may contain PCI information or other customer information that you should not expose to the lower environments.

You can implement lower environments using a lab environment, or a production environment.

When using the production infrastructure to support the lower environments, ASAPP separates production traffic from the lower environment traffic. The lower environments will have dedicated inbound numbers and routing that will allow them to be isolated and provide the ability for ASAPP and the customer teams to fully test using non-production traffic.

As part of the environment’s buildout, ASAPP will need a way to initiate and terminate test calls. The ASAPP team will use the same soft-client and tools used by agents to login as a voice agent, answer inbound test calls, and simulate the various call flows used within the customer contact center.

ASAPP proposes customers allocate two Direct Inward Dialing (DID)/ Toll Free Number (TFN) numbers, one for each of the two different test environments.

• Demo Environment - A lower environment used by both ASAPP and customers.
• Preprod Environment - A lower environment used by ASAPP QA for testing.

At the SBC level, you should configure the Demo and Preprod DID numbers with their own Session Recording Server (SRS), unique from the production SRS configuration. This will allow the test environments to always have SIPREC turned on, but not send excess/production traffic to ASAPP. This also allows the test environments to operate independently of production. With Oracle/Acme, you can accomplish this with session agents. For Avaya SBCE, you can accomplish this with End Point Flows.

ASAPP will have a separate set of media gateways and media gateway proxies for each environment to ensure traffic and data separation.

The lower environments (not PCI compliant) are for testing only and will not receive actual customer audio. The production environment is where ASAPP transcribes and redacts the audio in a PCI zone.

​

Appendix A - Avaya Configuration Details

This section provides specific configuration details for the solution that leverages Avaya telephony infrastructure.

Avaya Communication Manager

• Set Avaya Internet Protocol - Private Branch Exchange (IP-PBX) SIP trunks to ‘shared’ to ensure the UCID is not reset by the PBX.
  • Change trunk-group x -> page 3 -> UUI Treatment:shared
• Set SendtoASAI parameter to ‘yes.‘
  • Change system-parameters features -> page 13 -> Send UCID to ASAI? Y
  • Add ASAPP voice agents to a new skill, one that is not used for queuing or routing.
  • Configure AES to monitor the new skill.
    • ASAPP will use the cstaMonitorDevice service to monitor the ACD skill.
    • ASAPP may also call cstaMonitorCallsViaDevice if more call data is needed.

Avaya AES TSAPI configuration

• Networking -> Ports -> TSAPI Ports
  • Enabled
  • TSAPI Service Port (450)
    • Firewalls will also need to allow these ports.

• AES link to ASAPP connection provisioning
  • Provisioning of new ASAPP Voice skill for monitoring.

​

Appendix B - Cisco Configuration Details

This section provides specific configuration details for the solution that leverages Cisco telephony infrastructure.

Cisco CTI Server configuration

• ASAPP will connect with the CTI_SERVICE_ALL_EVENTS
  • You will need the Preferred ClientID (identifier for ASAPP) and ClientPassword (if not null) to send the OPEN_REQ message.
• Ports 42027 (side A) and 43027 (side B)
  • Instance number if not 0 will increase these ports
  • Firewalls will also need to allow these ports
• CallVariable1-10 Definitions/usages
• Custom NamedVariables and NamedArrays Definitions/usages
• Events currently used by ASAPP:
  • OPEN_REQ
  • OPEN_CONF
  • SYSTEM
  • AGENT_STATE
  • AGENT_PRE_CALL
  • BEGIN_CALL
  • CALL_DATA_UPDATE
  • CALL_CLEARED
  • END_CALL

​

Appendix C - Oracle (Acme) Session Border Controller

In order to provide the correlation between the SIPREC session and specific CTI events, ASAPP will use the following approach:

• Session Border Controller
  • Configure the SBC to create an Avaya UCID (universal call identifier) in the SIP header.
    • UCID generation is a native feature for Oracle/Acme Packet session border controller platforms.
      • Oracle SBC UCID Admin
• In the Oracle (Acme Packet) SBCs, load balancing across the ASAPP Media Gateway Proxies requires the use of static IP addresses versus the use of dynamic hostnames.
  • SBC Settings for Media Gateway Proxies - Production and Lower Environments:
    • Transport = TCP
    • SIP OPTIONS = disabled
    • Load Balancing strategy = “hunt”
    • Session-recording-required = disabled
    • Port = 5070

​

Glossary