Real-Time Third Party Telephony Recording (Multi-ACD)

NiCE CXone Real-Time Third Party Telephony Recording (Multi-ACD) vous permet de tirer parti de l’enregistrement dans le nuage NiCE CXone et des applications d’affaires tout en continuant à utiliser votre système téléphonique existant. Votre système téléphonique peut être dans le nuage ou sur site.

Étape 1 : Préparez votre site. Examinez les déploiements pris en charge et implémentez les directives pour l’environnement de votre site.

Étape 2 : Conditions préalables pour travailler avec Real-Time Third Party Telephony Recording (Multi-ACD) :

  • Définissez une licence d’enregistrement avancée pour Real-Time Third Party Telephony Recording (Multi-ACD).

    • Dans Tenant Management, sous Options d’enregistrement, sélectionnez Recording Advanced.

    • Cochez la case à cocher pour Third Party Telephony.

    • Cochez la case à cocher pour une ou plusieurs intégrations pertinentes.

  • Sous Autorisations d’enregistrement, activez l’Autorisation Third Party Telephony Configuration.

Étape 3 : Dans NiCE CXone, configurez la connectivité à votre système téléphonique tiers.

Il existe trois méthodes de connectivité réseau prises en charge :

  • Internet Public (sécurisé)

  • SD-WAN

  • AWS Public Direct Connect

Pour plus d’informations, consultez Méthodes de connectivité réseau prises en charge.

Pour enregistrer les appels de la téléphonie tierce, vos systèmes téléphoniques doivent être configurés pour permettre :

  • La réception des événements CTIClosed Continuité des activités de TI : toute technologie qui permet d’intégrer les interactions sur les ordinateurs et les téléphones. par les interfaces CTI pertinentes

    • La connectivité est requise de chacune des deux NiCE AWS zones de disponibilité (AZ1, AZ2) vers chacun des sites et des Adresses ip des clients

      • Si le client a un site, AZ1 et AZ2 doivent tous deux être connectés à ce site

      • Si le client a deux sites, AZ1 et AZ2 doivent tous deux être connectés au site A et au site B (maillage complet)

    • Les deux AZ doivent être connectées activement en mode actif/En attente à chaud

  • Réception du trafic SIP (SIPS) et des médias voix (SRTP) par l’intermédiaire du SBC du client, sur Internet public, vers le SBC NiCE

Après le déploiement, toutes les options NiCE CXone Recording Management (CXone) sont disponibles.

Real-Time Third Party Telephony Recording (Multi-ACD) prend en charge ce qui suit :

  • Enregistrement des interactions voix et écran. Il existe diverses façons d’enregistrer les interactions.

    Pour l’enregistrement d’écran, le paramètre de configuration ScreenAgent RESOLVE_USER doit être configuré avec la valeur oslogin.

  • Enrichir les appels enregistrés avec des métadonnées et des champs de données commerciales

  • Stockage et gestion des médias enregistrés.

  • Importation et gestion des informations pour les employés et les identificateurs externes (comptes d’enregistrement).

  • Importation et gestion des informations relatives aux appareils (pour les extensions).

  • Utilisation d’applications NiCE CXone pour les interactions avec des systèmes de téléphonie tiers.

Options d’Intégration prises en charge

Un système téléphonique Avaya peut inclure les types d’interface suivants :

Les interfaces peuvent être configurées dans un système téléphonique Avaya de l’une des manières suivantes :

  • TSAPI avec DMCC uniquement

  • TSAPI avec SIPREC uniquement

  • TSAPI avec SIPREC et DMCC

Cette solution ne prend en charge que la méthode SSCClosed Conférence en une Étape DMCC, tandis que les méthodes MRClosed Enregistrement multiple et SOClosed Observateur de service ne sont pas prises en charge.

(Facultatif pour le basculement et la haute disponibilité) Si vous avez 2 systèmes téléphoniques Avaya, vous pouvez configurer une interface TSAPI et une interface DMCC pour chaque système téléphonique.

Vous pouvez utiliser un composeur sortant avec le système téléphonique Avaya. Dans ce cas, créez un système téléphonique supplémentaire pour chaque interface de composeur - Avaya POM ou Alvaria (Aspect).

CXone Recording Management (CXone) est officiellement reconnu comme conforme à Avaya Communication Manager 10.1 et 10.2.

Un système téléphonique Cisco prend en charge deux configurations :

  • Recording basé sur le Téléphone IP (BiB) nécessite l'un de ces SBC : Cisco CUBE/vCUBE, AudioCodes SBC, Oracle (Acme Packet), ou Ribbon (Sonus)

  • Recording basé sur le réseau (NBR) nécessite à la fois Cisco CUBE/vCUBE et l'un des SBC supplémentaires : CUBE/vCUBE, AudioCodes SBC, Oracle (Acme Packet), ou Ribbon (Sonus)

Le système téléphonique Cisco peut inclure les types d’interface suivants :

  • Interface CTI : Cisco JTAPI (obligatoire)

  • Interface CTI : Serveur CTI de Cisco (facultatif; plusieurs interfaces peuvent être incluses)

  • Interface CTI : Cisco UCCX CTI (facultatif; plusieurs interfaces peuvent être incluses)

  • Interface média Cisco CUBE : La définition de cette interface n’est pas nécessaire

  • Le composeur sortant UCCE/UCCX peut être utilisé avec le système Cisco sans configuration supplémentaire, car il est pris en charge d'emblée.

Les interfaces peuvent être configurées dans un système téléphonique Cisco de l’une des manières suivantes :

  • JTAPI

  • JTAPI et un ou plusieurs serveurs Cisco CTI

  • JTAPI et un ou plusieurs serveurs Cisco UCCX CTI

Real-Time Third Party Telephony Recording (Multi-ACD) est officiellement certifié et reconnu par Cisco comme étant conforme à CUCM 14 et 15.

Un système téléphonique Genesys peut inclure les types d’interface suivants :

Le système téléphonique Genesys inclut les types d’interface Genesys SIP Server et SIPREC qui peuvent être configurés avec AudioCodes SBC.

Un système téléphonique Microsoft Teams peut inclure le type d’interface suivant :

  • Microsoft Teams (BOT d’enregistrement NiCE)

L’interface Microsoft Teams gère à la fois les événements d’appel CTIClosed Continuité des activités de TI : toute technologie qui permet d’intégrer les interactions sur les ordinateurs et les téléphones. et les médias d’appel.

Format d’enregistrement :

L’enregistrement en MONO ou en Stéréo est pris en charge, selon la licence.

Avis de déploiement :

Après avoir créé le système téléphonique et l’interface Microsoft Teams, il est nécessaire de déployer le BOT d’enregistrement Microsoft Teams NiCE dans le compte NiCE Azure. Ce déploiement est pris en charge par l’équipe de déploiement NiCE.

Applications Admin prises en charge

Les applications NiCE CXone Admin suivantes sont prises en charge dans Real-Time Third Party Telephony Recording (Multi-ACD) :

  • Recording Management (CXone) : Téléphonie de Troisième partie, Politiques d’enregistrement et Données commerciales

  • Admin : Employés, Équipes et Groupes

  • Réglages de sécurité

  • Cloud Storage

  • Portail de téléversement groupé

Si vous n'utilisez pas les NiCE CXone ACD, vous pourriez obtenir une erreur en essayant d'afficher certaines parties de ces applications prises en charge. Par exemple, l'onglet Paramètres du contact d'une équipe ne s'affichera pas, puisque cet onglet contient des paramètres liés à ACD.

Applications commerciales prises en charge

Les applications NiCE CXone suivantes sont prises en charge dans Real-Time Third Party Telephony Recording (Multi-ACD) :

  • Interactions

    Les compétences et les dispositions ne sont pas affichées dans les résultats de recherche. Lorsqu’un contact comprend des enregistrements stéréo et des enregistrements mono, la lecture de l’ensemble du contact sera mono.

  • Quality Management (CXone) pour My Zone et Quality Planner

    Un plan qualité par compétence ou disposition ne peut pas être généré pour les utilisateurs de Engagement Hub (Multi-ACD/Open). Vous pouvez créer un plan qualité en fonction d'un champ de données commerciales si la compétence est remplie dans ce champ.

  • Interaction Analytics (CXone)

    Une seule langue est prise en charge par locataire.

  • Performance Management (Integrated) (Standalone)

    Aucune donnée n’est affichée dans les gadgets logiciels liés à l’ACD.

  • Reporting et Legacy Dashboard pour Quality Management et les données relatives à l'enregistrement.

Autorités de certification prises en charge pour SIPREC

La liste suivante comprend les autorités de certification (AC) prises en charge auprès desquelles les clients peuvent obtenir le certificat TLSClosed Sécurité de la couche transport. protocole qui fournit une sécurité de bout en bout pour les données envoyées entre les applications. requis pour l'intégration SIPREC (Session Recording) avec Real-Time Third Party Telephony Recording (Multi-ACD). Les certificats émis par ces AC de confiance garantissent une communication sécurisée et conforme entre l'infrastructure d'enregistrement du client et la plateforme CXone.

  • DigiCert

  • AAA

  • FNMT-RCM

  • ACCV

  • Actalis

  • AffirmTrust

  • Amazon

  • ANF Autoridad de Certificación

  • Atos

  • Autoridad de Certificación Firmaprofesional

  • BJCA

  • Buypass

  • Disig

  • Certainement

  • Certigna

  • Certum

  • CFCA

  • CommScope

  • COMODO / Sectigo

  • D-TRUST

  • Microsec (e-Szigno)

  • emSign

  • Entrust

  • Entrust.net

  • GDCA

  • GlobalSign

  • GLOBALTRUST

  • GoDaddy / Starfield

  • Google Services de Confiance (GTS)

  • HARICA

  • Hellenic Academic et Research Institutions

  • HiPKI

  • Hongkong Publication

  • IdenTrust

  • ISRG (Let's Chiffrer)

  • Izenpe

  • Microsoft

  • NAVER

  • NetLock

  • OISTE / WISeKey

  • QuoVadis

  • RootCA (Generic/Inconnue)

  • Secure Global

  • SecureSign

  • SecureTrust

  • SECOM (Sécurité Communication)

  • SSL.com

  • SwissSign

  • SZAFIR

  • T-Systems (T-TeleSec)

  • Telia

  • TeliaSonera

  • TrustAsia

  • Trustwave

  • TÜBİTAK

  • TunTrust

  • TWCA

  • UCA

  • USERTrust / Sectigo

  • vTrus

  • XRamp

Durée de paquétisation prise en charge

Pour assurer la compatibilité avec CXone Recording dans toutes les intégrations, configurez tout environnement téléphonique ou toute composante responsable du transcodage afin d'utiliser une durée de paquétisation (ptime) de 20 millisecondes pour les appels enregistrés. Il s'agit de la seule valeur de ptime actuellement prise en charge par l'enregistreur.

Utilisation de Real-Time Third Party Telephony Recording (Multi-ACD) avec NiCE CXone ACD

Lorsque vous déployez Real-Time Third Party Telephony Recording (Multi-ACD) avec NiCE CXone ACD (côte à côte), toutes les applications sont activées pour le locataire en fonction des licences achetées.

Toutefois, les utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD) ne peuvent utiliser que les applications prises en charge pour Real-Time Third Party Telephony Recording (Multi-ACD), y compris Recording Management (CXone), Quality Management (CXone), Interaction Analytics (CXone) et Performance Management (Integrated) (Standalone). Si des rôles incluant des applications non prises en charge par Real-Time Third Party Telephony Recording (Multi-ACD) sont attribués aux utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD), ceux-ci peuvent accéder à l'application, mais aucune donnée n'est disponible.

Afin de garantir une expérience optimale aux utilisateurs de Real-Time Third Party Telephony Recording (Multi-ACD), il est recommandé aux administrateurs de définir des rôles spécifiques pour les utilisateurs de Real-Time Third Party Telephony Recording (Multi-ACD). Ces rôles ne doivent inclure que les applications prises en charge par Real-Time Third Party Telephony Recording (Multi-ACD). Il est recommandé que les noms de ces rôles incluent Open afin de les distinguer des rôles NiCE CXone généraux. Seuls ces rôles doivent être attribués aux utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD). Les utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD) doivent avoir un identifiant externe défini dans l'application NiCE CXone Admin.

FAQ

Oui, la connexion à NiCE CXone et à Real-Time Third Party Telephony Recording (Multi-ACD) est prise en charge.

Oui. Pour utiliser les données commerciales provenant du système téléphonique tiers d'un client, définissez les données commerciales pour Real-Time Third Party Telephony Recording (Multi-ACD).

Pour Avaya : Avaya TSAPI avec SIPREC ou Avaya TSAPI avec SIPREC et DMCC pour les appels Internes; Avaya TSAPI avec DMCC.

Pour Cisco : CUCM (JTAPI) uniquement; CUCM (JTAPI) avec CUCCE (serveur CTI); CUCM (JTAPI) avec CUCCX (serveur CTI).

Pour Genesys : T-Lib avec SIPREC

Avaya prend en charge les méthodes d'enregistrement SIPREC et DMCC (Single Step Conference) avec Real-Time Third Party Telephony Recording (Multi-ACD).

L'intégration Real-Time Third Party Telephony Recording (Multi-ACD) Cisco prend en charge l'enregistrement actif SIP par l'intermédiaire de Cisco NBR. Les deux méthodes sont prises en charge : la méthode privilégiée par passerelle avec un CUBE/vCUBE et la méthode privilégiée par téléphone Built-in-Bridge (BiB).

Real-Time Third Party Telephony Recording (Multi-ACD) est pris en charge pour l'enregistrement avec Genesys SIPREC.

Oui. CUBE/vCUBE est requis pour l'enregistrement par passerelle NBR. De plus, tant pour la passerelle NBR que pour la méthode privilégiée par téléphone, un CUBE, ou un autre SBC pris en charge, est nécessaire comme SBC client pour gérer SIP sur TLS et le chiffrement SRTP sur l'Internet public.

Non, Cisco Webex calling et Cisco Webex-CC ne sont pas pris en charge. Toutefois, Cisco Webex-CCE et Cisco Webex Calling DI (instance dédiée) sont pris en charge.

Seul SSC est pris en charge.

Les méthodes de connexion sécurisées comprennent VPN/IPsec pour les interfaces CTI, Avaya TLS 1.2 pour CTI, et SIPS/SRTP pour les médias au moyen d'un SBC client. Le VPN pour le segment média (SIP/RTP) n'est pas pris en charge.

Actuellement, l'Internet public, SD-WAN et AWS Public Direct Connect sont pris en charge. AWS ne prend pas en charge MPLS.

Chaque instance CTI JTAPI CUCM dans chaque centre de données (qu'il s'agisse d'un abonné ou d'un éditeur) nécessite une Adresse ip publique. Les numéros de port JTAPI sont fixes. Le client CUCM JTAPI peut prendre en charge jusqu'à 6 Adresses ip : une pour l'éditeur CUCM et jusqu'à cinq pour les abonnés CUCM.

Pour les instances CTI Call Generator (CG) UCCE, une Adresse ip publique est requise par instance avec la traduction d'adresse de port (PAT), ou deux sans elle. Les numéros de port CG sont configurables. Le client CG UCCE peut utiliser deux adresses ip : une pour le CG actif et une pour le CG en attente. Multiple interfaces CG peuvent être configurées pour diverses instances UCCE.

Oui. Vous pouvez utiliser les composeurs Avaya POM, Alvaria (Aspect) avec Avaya DMCC, ainsi que Cisco UCCE/UCCX. Si vous utilisez POM ou Alvaria, créez un système téléphonique de composeur séparé avec une seule interface de composeur.

Oui, Real-Time Third Party Telephony Recording (Multi-ACD) pour Avaya nécessite plusieurs licences :

  • Licence TSAPI : une pour chaque appareil surveillé.

  • Licence DMCC : une pour chaque appareil d'enregistrement, selon le nombre maximal d'agents simultanés.

  • Virtual Extensions : pour le nombre maximal d'appels simultanés, plus 20 % supplémentaires pour gérer la capacité additionnelle.

  • Analytics est prise en charge uniquement pour les enregistrements stéréo. Elle est prise en charge pour Avaya SIPREC et Cisco.

  • Elle n’est pas prise en charge pour l’enregistrement Avaya DMCC.

  • QM Advanced et Interaction Analytics (CXone) ne sont pas pris en charge lorsque DMCC est utilisé pour les appels externes.

Oui. Real-Time Third Party Telephony Recording (Multi-ACD) est entièrement redondant, avec une haute disponibilité transparente pour tous les composants de la solution. Le Soutien pour la redondance est transparent. Real-Time Third Party Telephony Recording (Multi-ACD) prend en charge Multi-AZ avec deux zones de disponibilité AWS.

CXone Real-Time Third Party Telephony Recording (Multi-ACD) prend en charge la surveillance en temps réel de la voix et de l'écran à l'aide de l'application CXone Supervisor Workspace (Supervisor). Cette fonctionnalité est prise en charge pour les agents de centre de contact avec les intégrations Avaya, Cisco ou Genesys.

Real-Time Third Party Telephony Recording (Multi-ACD) utilise l’enregistrement basé sur les interactions. L’enregistrement total n’est pas pris en charge.

Autrefois, lorsque la connectivité CTI était moins fiable, l'enregistrement indépendant du CTI (aussi appelé Total Recording) était nécessaire pour garantir qu'aucun enregistrement ne soit perdu en cas de défaillance du CTI. Aujourd'hui, grâce à la résilience considérablement améliorée des systèmes téléphoniques modernes et à la robustesse accrue des composantes CTI de Engagement Hub (Multi-ACD/Open), la continuité des activités est intrinsèquement maintenue. Par conséquent, les méthodes d'enregistrement indépendantes du CTI ne sont plus nécessaires ni recommandées.

  • Pour les appels internes entre plusieurs agents et dont au moins deux disposent d’une vidéocapture d’écran :

    • La lecture du segment commence par la vidéocapture de l’écran de l’agent qui a effectué le travail après appel.

    • S’il n’y a pas d’ACW, la lecture commence par la vidéocapture d’écran dont l’estampille temporelle de premier début d’enregistrement est la plus ancienne. Cela peut entraîner la lecture d’une vidéocapture aléatoire de l’écran de l’agent.

  • Pour la lecture d’un contact :

    • La lecture commence par l’enregistrement qui inclut le traitement post-appel ou par l’heure de début d’enregistrement la plus ancienne.

    • Pour les segments suivants, la lecture utilise l’enregistrement d’un agent présent dans le segment précédent. S’il n’y a pas d’enregistrement de ce type, la lecture prend la vidéocapture d’écran dont l’heure de début d’enregistrement est la plus ancienne. Cela peut entraîner la lecture d’une vidéocapture aléatoire de l’écran de l’agent.

Oui. Vous pouvez utiliser les API de masquage et de démasquage pour Real-Time Third Party Telephony Recording (Multi-ACD).