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 cloud et des applications affaires NiCE CXone tout en continuant à utiliser votre système téléphonique existant. Votre système de téléphonie peut résider dans le cloud ou sur site.

Étape 1 : préparez votre site. Revoir les déploiements pris en charge et mettre en œuvre 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éfinir une licence d'enregistrement avancé 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 Recording, activez l'Autorisation Configuration de la Téléphonie de Troisième Partie.

É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 :

  • Public Internet (sécurisé)

  • SD-WAN

  • AWS Public Direct Connect

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

Pour l’enregistrement des appels de téléphonie tiers, vos systèmes de téléphonie doivent être configurés de manière à autoriser :

  • Réception des événements CTI via les interfaces CTI pertinentes

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

      • Dans le cas où le client dispose d'un seul placer, AZ1 et AZ2 doivent tous deux être connectés à ce site

      • Si le client possède 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 de manière active selon un modèle Actif/En attente à chaud.

  • Réception du trafic SIP (SIPS) et des médias vocaux (SRTP) via le SBC client sur l'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 les éléments suivants :

  • Recording des interactions vocales et à l'écran. Il existe plusieurs 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.

  • Enrichissement des appels enregistrés à l’aide de métadonnées et de champs de données commerciales.

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

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

  • Importation et gestion des informations de périphériques (pour les extensions).

  • Utilisation des applications NiCE CXone pour les interactions provenant de 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’interfaces suivants :

Pour configurer les interfaces dans un système de téléphonie Avaya, procédez de l’une des façons suivantes :

  • TSAPI avec DMCC uniquement

  • TSAPI avec SIPREC uniquement

  • TSAPI avec SIPREC et DMCC

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

(En option, pour le basculement et la haute disponibilité) Si vous disposez de 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 numéroteur sortant avec le système de téléphonie Avaya. Dans ce cas, créez un système de téléphonie supplémentaire pour chaque interface de numéroteur, notamment Avaya POM ou Alvaria (Aspect).

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

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

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

  • Network-based Recording (NBR) nécessite à la fois Cisco CUBE/vCUBE et l'un des SBC supplémentaires suivants : CUBE/vCUBE, AudioCodes SBC, Oracle (Acme Packet), ou Ribbon (Sonus)

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

  • Interface CTI : cisco jtapi (obligatoire)

  • Interface CTI (continuité des activités de TI) : Serveur Cisco CTI (en option ; plusieurs interfaces peuvent être incluses)

  • Interface CTI : Cisco UCCX CTI (en option ; Multiple interfaces peuvent être incluses)

  • Interface de Médias Cisco CUBE : il n'est pas nécessaire de définir cette interface

  • Le composeur sortant UCCE/UCCX peut être utilisé avec le système Cisco sans configuration supplémentaire, car il est prêt à l'emploi.

Il est possible de configurer les interfaces dans un système de téléphonie Cisco de l’une des façons suivantes :

  • JTAPI

  • JTAPI et un ou plusieurs serveurs Cisco CTI

  • JTAPI et un ou plusieurs serveurs CTI Cisco UCCX

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’interfaces 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 (NiCE BOT d'Enregistrement)

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 MONO ou Stéréo est pris en charge, selon la licence.

Avis de déploiement :

Après la création du système téléphonique et de l'interface Microsoft Teams, il est nécessaire de déployer le Microsoft Teams NiCE Recording BOT dans le compte NiCE Azure. Ce déploiement est géré 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) :

  • Téléphonie tierce, 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é

If vous n'utilisez pas le NiCE CXone ACD, il est possible que vous obteniez une erreur en essayant d'afficher certaines parties de ces applis prises en charge. Par exemple, l'onglet Paramètres du contact d'une équipe ne s'affichera pas, car cet onglet contient des Paramètres liés à ACD.

Applications applications prises en charge

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

  • Interactions

    Les compétences et les dispositions ne s’affichent pas dans les résultats de la recherche. Lorsqu'un contact inclut 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 Engagement Hub (Multi-ACD/Open) utilisateurs. Vous pouvez créer un Plan Qualité en fonction d'un champ de données commerciales si la compétence est renseignée dans ce champ.

  • Interaction Analytics (CXone)

    Seule une langue par locataire est prise en charge.

  • Performance Management (Integrated) (Standalone)

    Aucune donnée ne s’affiche dans les widgets liés à ACD.

  • Reporting et Legacy Dashboard pour les données liées à la Gestion de la qualité et à l’enregistrement.

Autorités de certification prises en charge pour SIPREC

La liste suivante inclut les autorités de certification (CA) prises en charge auprès desquelles les clients peuvent obtenir le certificat TLS requis pour l'intégration SIPREC (Session Recording) avec Real-Time Third Party Telephony Recording (Multi-ACD). Les certificats émis par ces CA 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

  • Autorité de Certification 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 and Research Institutions

  • HiPKI

  • Hongkong Poste

  • IdenTrust

  • ISRG (Let's Encrypt)

  • Izenpe

  • Microsoft

  • NAVER

  • NetLock

  • OISTE / WISeKey

  • QuoVadis

  • RootCA (Générique/Inconnu)

  • Secure Global

  • SecureSign

  • SecureTrust

  • SECOM (Communication de Sécurité)

  • 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 garantir la compatibilité avec CXone Recording sur l'ensemble des intégrations, configurez tout environnement de téléphonie ou composant responsable du transcodage pour utiliser un temps 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) en combinaison avec NiCE CXone ACD

Lorsque vous déployez Real-Time Third Party Telephony Recording (Multi-ACD) avec NiCE CXone ACD (Side-by-Side), 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) peuvent utiliser uniquement les applications prises en charge pour Real-Time Third Party Telephony Recording (Multi-ACD), notamment Recording Management (CXone), Quality Management (CXone), Interaction Analytics (CXone) et Performance Management (Integrated) (Standalone). Si des rôles assignés aux utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD) incluent des applications qui ne sont pas prises en charge par Real-Time Third Party Telephony Recording (Multi-ACD), ils peuvent accéder à l'application, mais aucune donnée n'est disponible.

Afin de garantir une expérience utilisateur optimale pour les utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD), il est recommandé que les administrateurs configurent des rôles spécifiques pour les utilisateurs Real-Time Third Party Telephony Recording (Multi-ACD). Ces rôles doivent inclure uniquement 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. Uniquement 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 disposer d'un identificateur externe défini dans l'application NiCE CXone Admin.

FAQ

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

Oui. Pour utiliser des données commerciales provenant du système téléphonique Tiers d'un client, définir 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 Cisco prend en charge l'Active Recording SIP via Cisco NBR. Les méthodes de passerelle privilégiée avec CUBE/vCUBE et de téléphone privilégié Built-in-Bridge (BiB) sont toutes deux prises en charge.

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

Oui. NBR gateway Recording requires CUBE/vCUBE. De plus, pour la passerelle NBR comme pour le téléphone préféré, un CUBE ou un autre SBC pris en charge est nécessaire en tant que SBC client pour gérer le 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.

Uniquement SSC est pris en charge.

Les méthodes de connexion sécurisée incluent VPN/IPsec pour les interfaces CTI, Avaya TLS 1.2 pour CTI, ainsi que SIPS/SRTP pour le média à l'aide d'un SBC client. Le VPN pour le tronçon média (SIP/RTP) n'est pas pris en charge.

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

Chaque instance CUCM JTAPI CTI dans chaque centre de données (qu'il s'agisse d'un abonné ou d'un éditeur) nécessite une Adresse IP publique. Les nombres 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 UCCE Call Generator (CG) CTI, une Adresse IP publique est requise par instance avec la Traduction d'adresse de port (PAT), ou deux sans celle-ci. Les numéros de port CG sont configurables. Le client UCCE CG peut utiliser deux Adresses IP : une pour le CG actif et une pour le CG en attente. Plusieurs interfaces CG peuvent être configurées pour diverses instances UCCE.

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

Oui, Real-Time Third Party Telephony Recording (Multi-ACD) pour avaya requiert plusieurs licences :

  • TSAPI License : Une par appareil surveillé.

  • **Licence DMCC** : Une par appareil d'enregistrement, basée sur le nombre maximum d'agents simultanés.

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

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

  • Elle n’est pas prise en charge pour les enregistrements DMCC Avaya.

  • QM Advanced et Interaction Analytics (CXone) ne sont pas pris en charge lors de l’utilisation de DMCC pour les appels externes.

Oui. Real-Time Third Party Telephony Recording (Multi-ACD) est entièrement redondant et offre une haute disponibilité transparente sur tous les composants de la solution. Le Soutien de 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 en utilisant l'application CXone Supervisor Workspace (Supervisor). Elle est prise en charge pour les agents du 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 (également appelé Total Recording) était nécessaire pour garantir qu'aucun enregistrement ne soit perdu en raison de pannes CTI. Aujourd'hui, grâce à la résilience nettement améliorée des systèmes de téléphonie modernes et à la robustesse accrue des composants CTI de Engagement Hub (Multi-ACD/Open), la continuité des affaires 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 dont au moins deux ont un enregistrement d’écran :

    • La lecture du segment commence avec l'enregistrement d'écran de l'Agent qui a effectué le travail après Appel.

    • S'il n'y a pas d'ACW, la lecture démarre avec le Recording d'écran dont l'estampille temporelle de premier début est la plus ancienne. Cela peut entraîner la lecture du Recording d'écran d'un Agent aléatoire.

  • Pour la lecture d’un contact :

    • La lecture commence avec l'enregistrement qui comprend le travail après Appel ou avec l'estampille temporelle de début d'enregistrement la plus ancienne.

    • Pour les segments suivants, la lecture utilise le recording d'un agent qui était présent dans le segment précédent. S'il n'existe aucun recording de ce type, la lecture utilise le recording d'écran ayant l'estampille temporelle de premier début la plus ancienne. Cela peut entraîner la lecture d'un recording d'écran aléatoire d'un agent.

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