Comprendre l'architecture JTAPI et le flux d'appels dans UCCX

Introduction

Ce document décrit les fonctionnalités de base de JTAPI, son architecture et le flux d'appels en ce qui concerne UCCX.

Conditions préalables

Exigences

Cisco recommande de connaître ces outils et fonctionnalités :

• JTAPI - API de téléphonie Java
• API - Interface de programmation d'applications
• UCCX - Unified Contact Center Express
• CUCM - Cisco Unified Communications Manager
• CTI - Intégration de la téléphonie informatique

Cisco recommande de connaître les sujets suivants :

• Configuration de Cisco Unified Communications Manager (CUCM)
• Configuration de Unified Contact Center Express (UCCX)

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

• UCCX version 12.5.1.11002-481
• CUCM version 12.5.1.11900-146

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document décrit l'architecture JTAPI, le flux d'appels, l'activation des débogages et la collecte des journaux.

Présentation de JTAPI

Cisco Unified JTAPI est une norme d'interface de programmation développée par Sun Microsystems pour une utilisation avec des applications de téléphonie et d'informatique Java. Cisco JTAPI met en oeuvre la spécification Sun JTAPI 1.2 avec des extensions Cisco supplémentaires. Vous devez utiliser Cisco JTAPI pour développer des applications qui :

• Contrôlez et observez les téléphones Cisco Unified Communications Manager.

• Routage des appels à l'aide des ports CTI (Computer-Telephony Integration) et des points de routage (périphériques virtuels).

JTAPI et UCCX

Cisco Unified JTAPI est utilisé dans un centre de contact pour surveiller l'état des périphériques et émettre des instructions de routage pour envoyer des appels au bon endroit au bon moment. En outre, JTAPI est utilisé pour démarrer et arrêter l'enregistrement des instructions tout en récupérant des statistiques d'appel à des fins d'analyse et pour filtrer les appels dans les applications CRM, les scripts automatisés et le contrôle d'appel à distance.

Architecture JTAPI

Cisco Unified JTAPI, utilisé dans un environnement d'entreprise, combine la disponibilité, l'emplacement et les préférences des utilisateurs pour un environnement personnalisé unique pour le routage basé sur la présence.

Voici les applications de JTAPI :

• JTAPI peut surveiller deux combinaisons de téléphones et de lignes ou être averti de l'existence de ces combinaisons.
• Les applications de centre de contact utilisent le modèle d'appel complet pour JTAPI.
• JTAPI offre les fonctionnalités suivantes :
  • Contrôle des appels
  • Contrôle des supports
  • Négociation des médias

Modèle d'observateur JTAPI

Le schéma suivant explique le modèle Provider-Observer sur lequel JTAPI fonctionne.

Observateurs

Interfaces d'observateur

La JTAPI est basée sur l'idée d'observateur. Par observateur, il fait référence à l'idée de celui qui observe les événements. Vous pouvez placer plusieurs observateurs sur différents éléments du système. JTAPI utilise des observateurs pour connaître les changements d'état des objets.

Par exemple, vous pouvez placer des observateurs sur les lignes, les téléphones, le terminal, les adresses, etc., et vous renseigner sur leurs changements d'état.

Modèle de fournisseur JTAPI

Le schéma suivant explique le modèle de fournisseur sur lequel JTAPI fonctionne :

Modèle de fournisseur JTAPIModèle du fournisseur

Le fournisseur JTAPI est une connexion de l'application à Call Manager ou CTI Manager. Les fournisseurs sont utilisés pour attacher des observateurs aux objets. Vous pouvez également associer un observateur à un fournisseur. Les fournisseurs sont utilisés pour être avertis des actions entreprises sur les objets. (Vous pouvez également prendre le contrôle des périphériques sur lesquels l'observateur est connecté (à partir du fournisseur qui a connecté cet observateur).

Utilisateur JTAPI

Les captures d'écran suivantes sont tirées de CUCM (à gauche) et UCCX (à droite) qui expliquent l'utilisateur de l'application JTAPI.

• Lorsque vous démarrez une application et que vous souhaitez établir une connexion avec le gestionnaire CTI, vous ouvrez un fournisseur.
• L'ouverture d'un fournisseur a pour but de vous permettre de surveiller les actions effectuées sur les périphériques, les terminaux , etc.
• Sa mise en oeuvre dans CUCM s'effectue par le biais d'un utilisateur Application.
• Vous créez cet utilisateur et lui attribuez des informations d'identification afin qu'il puisse d'abord s'authentifier sur CTI auprès du CUCM.
• Ainsi, l'utilisateur de l'application JTAPI qui est créé dans CUCM est le fournisseur.
• Outre la simple surveillance, vous devez vous assurer que ces périphériques sont sous Périphériques associés pour vous assurer que vous pouvez contrôler les périphériques.

Handles P1 et P2

P1 et P2 sont les handles du fournisseur. Elles deviennent importantes lorsque vous allez ouvrir plusieurs fournisseurs à partir de la même application. À partir d'UCCX, vous créez 2 fournisseurs, l'un contrôlant les ports CTI et les points de routage, l'autre contrôlant les téléphones agents appelés fournisseurs RM-JTAPI. En tant qu'UCCX, vous créez le fournisseur qui contrôle les ports CTI et les points de routage en premier, qui est le fournisseur JTAPI P1. L'autre fournisseur que vous créez après le P1 est le fournisseur P2 ou le fournisseur RmCm qui gère les périphériques agents.

Si vous voyez un nouvel événement d'appel P1, vous savez qu'il s'agit d'un événement d'appel provenant d'un port CTI ou d'un point de routage CTI. Si vous voyez un nouvel événement d'appel P2, vous savez qu'il s'agit d'un événement d'appel du téléphone réel. Vous créez un utilisateur RM-JTAPI et un utilisateur JTAPI du côté CCX, mais du côté CUCM, vous voyez 2 utilisateurs JTAPI créés. En effet, chaque noeud CCX obtient son propre utilisateur JTAPI, mais il partage le même utilisateur RM-JTAPI. Lorsque vous créez un déclencheur sur UCCX, il est ajouté aux deux utilisateurs JTAPI. Les deux noeuds ouvrent un fournisseur séparément. Ainsi, toute action entreprise sur le point de routage est notifiée sur les deux noeuds CCX.

En dehors de cela, le noeud secondaire reste là et continue d'informer qu'il est toujours le noeud secondaire. Chaque noeud possède un groupe distinct de ports CTI. Les ports CTI du noeud 1 sont contrôlés par jtapi_1. Les ports CTI du noeud 2 sont contrôlés par jtapi_2.

Lorsque l'appel arrive au point de routage CTI, les deux noeuds CCX sont avertis du nouvel événement d'appel, mais le noeud CCX actif répond au gestionnaire d'appels avec une demande de redirection pour l'un de ses ports CTI qu'il contrôle.

Si vous voyez une adresse IP par rapport à un point de routage CTI dans CUCM, il s'agit de l'une des adresses IP du CCX, mais cela ne signifie pas que le noeud spécifique achemine l'appel.

L'une de vos opérations courantes consiste à dissocier le périphérique de l'utilisateur JTAPI et à le rajouter. La raison derrière elle est quand vous dissociez, le fournisseur est averti et supprime toutes les connexions à elle, puis quand il est ajouté de nouveau, l'observateur est ajouté à nouveau et le fournisseur commence à le surveiller à nouveau à l'aide de la demande de fournisseur ouvert. Vous pouvez voir qu'en dehors du périphérique ajouté à la liste des périphériques contrôlés, il y a une autre chose appelée Autoriser le contrôle du périphérique à partir de CTI case à cocher sur le périphérique individuel aussi bien. Cela permet d'obtenir un niveau de granularité supplémentaire. Ainsi, si le point de routage est ajouté à la liste contrôlée mais que la case CTI n'est pas cochée, vous pouvez toujours être averti des événements sur ce point de routage, mais aucune action sur le contrôle d'appel n'est possible.

Flux d’appels

Voici les séquences des événements impliqués dans le flux d'appels UCCX :

1. Lorsque l'appel arrive au point de routage CTI, il est redirigé vers un port CTI.
2. Le port CTI ouvre le canal média avec le pilote ipvms sur le boîtier uccx.
3. Une fois que vous avez décidé que l'agent doit prendre l'appel, un transfert de consultation est effectué du port à l'agent.
4. Un nouvel événement d'appel est envoyé au point de routage CTI.
5. La requête de redirection est envoyée au port CTI.
6. État de l'ID d'appel devient inactif.
7. Un autre nouvel événement d'appel arrive pour l'appel vers le port CTI.
8. Si la réponse de redirection est 0, elle est bonne, si elle n'est pas nulle, elle signifie qu'elle a échoué.
9. Ensuite, vous envoyez une demande d'acceptation d'appel (sans réponse, simplement acceptée sur le port).
10. Ensuite, acceptez les occurrences d'étape sur le script, c'est à ce moment que la demande de réponse d'appel arrive en Jtapi.

11. Vous obtenez ensuite une réponse du port.

12. L'état de l'appel passe à connecté.

13. Une fois la réponse obtenue du port, la négociation de support a lieu.

14. Le port envoie une requête open_logical_channel dans laquelle il partage son port et l’adresse IP sur laquelle il souhaite que la partie distante envoie le RTP.

15. Avant d’ouvrir le canal logique, il crée une connexion avec le pilote IPVMS sur le boîtier UCCX et ouvre un flux RTP.

16. L’événement suivant est l’événement start_reception qui nous indique les informations de fin lointaine (c’est-à-dire l’adresse IP et le port du périphérique appelant).

17. Ensuite, vous obtenez l'événement start_transmission comme n'importe quel autre signal multimédia.

18. Vous écoutez maintenant l'IVR et les invites.

19. À présent, lorsque l'appel atteint une étape du script qui permet de transférer l'appel à l'agent, vous voyez une demande CallSetupTransferRequest.

20. Contrairement au premier message, il s’agit d’un transfert avec consultation et non d’une redirection.

21. Si un agent est PRÊT mais pas à son siège, et que nous redirigeons l'appel, il reste simplement sans réponse, mais si nous effectuons un transfert de consultation, si l'agent n'est pas là, l'appel est à nouveau placé dans la file d'attente.

22. Comme pour tout autre transfert avec consultation, il s’agit du port CTI qui appuie sur le bouton de transfert pour la première fois sur le téléphone.

23. Lors d'un transfert de consultation régulier, il existe un chemin de média entre A et C, mais dans ce cas, vous indiquez à CUCM de ne pas le faire car il n'y a aucun sens que vous établissiez un média entre UCCX et l'agent.

24. Vous allez donc effectuer un transfert de consultation sans effectuer de coupure de support entre l'agent et le port CTI.

25. À ce stade, le port CTI met l’appelant en attente et nous voyons un événement change d’état d’appel = ATTENTE.

26. Vous voyez maintenant un événement de nouvel appel du port CTI vers le périphérique de l'agent.(En utilisant l'ID d'appel d'origine, mais un sous-ensemble de celui-ci et un événement P2.)

27. Si vous recherchez l'ID d'appel de l'événement P2, le message suivant s'affiche sous la forme CallAnswer request, ce qui signifie que l'agent a pris l'appel.

28. Une fois que vous savez que l’agent a pris l’appel (à l’aide de P2) et que l’appel est également à l’état connecté du côté du port CTI (à l’aide de P1), le point de routage voit unCallDirectTransferRequest, ce qui signifie que le bouton de transfert a été enfoncé pour la deuxième fois.

29. Maintenant que le port CTI sait que l'agent a pris l'appel, il n'y a pas de raison d'attendre, il envoie immédiatement un messageCallDirectTransferRequest qui est le port CTI appuyant sur le bouton de transfert une deuxième fois comme expliqué ci-dessus.

30. Maintenant, la branche d'appel d'origine (celle qui était en attente) est celle qui a survécu.

31. L'autre branche d'appel est détruite (entre le port et l'agent).

32. À ce stade, CUCM et UCCX sortent de l'image et le protocole RTP s'établit entre l'appelant et l'agent via la passerelle.

Le schéma suivant explique le flux d'appels mentionné précédemment de manière résumée.

Récapitulatif du flux d'appels JTAPI

Dépannage

Activer et collecter les journaux JTAPI

Activer les débogages JTAPI

Vérifiez ces étapes pour activer les niveaux de débogage JTAPI.

1. Ouvrez une session UCCX.
2. Accédez à CCX Serviceability.
3. Accédez à Trace.
4. Accédez à Configuration.
5. Dans la liste déroulante Sélectionner un service, sélectionnez Client de téléphonie Cisco Unified CM.
6. Cochez la case Débogage.
7. Cochez toutes les cases sauf MISC_DEBUGGING.

Collecter les débogages JTAPI

Vérifiez ces étapes pour activer les niveaux de débogage JTAPI à partir de RTMT ou CLI.

De RTMT

1. Connectez-vous à l'outil CCX Real Time Monitoring.
2. Cliquez sur Trace & Log Central.
3. Cliquez sur Collecter les fichiers.
4. Sélectionnez Client JTAPI pour tous les serveurs.
5. Cliquez sur Next (Suivant).
6. Sélectionnez les horodatages et l'emplacement dans lesquels vous souhaitez enregistrer les fichiers journaux.

À partir de CLI

Emplacement du journal JTAPI

activelog /uccx/log/JTAPI

Commande de collecte des journaux JTAPI :

fichier get activelog /uccx/log/JTAPI/* récurrent compress

Syntaxe:

file get {activelog|inactivelog|install} file-spec [options]

file-spec fichier obligatoire à transférer

options facultatives reltime mois|semaines|jours|heures|minutes valeur temporelle

                                 abstime hh:mm:MM/JJ/AAAA hh:mm:MM/JJ/AAAA

                                 match regex

                                 récidive

                                 comprimer

5 façons de télécharger les journaux en fonction de l'horodatage

reltime : période relative, spécifiée en minutes | heures | jours | semaines | valeur en mois

abstime : période de temps absolue, spécifiée sous la forme hh:mm:MM/JJ/AA hh:mm:MM/JJ/AA

match : fait correspondre une chaîne particulière dans le nom de fichier, spécifié comme valeur de chaîne

recurs : récupère tous les fichiers, y compris les sous-répertoires

compress vous permet de télécharger les fichiers dans un format zippé.

Liens de référence

• Guide du développeur JTAPI
• Niveaux de suivi UCCX