1/ TSERVER
Le Tserver capture et analyse les événements concernant les agents, les appels; il génère des
statistiques sur les agents et les appels. C’est un service qui effectue les process suivants:
Il lit les paramètres de connexion dans le dossier Config (users, mots de passe, dB,
paramètres de connexion asterisk, paramètres de connexion dB……)
Il se connecte aux différents serveurs (asterisk, dB, et via scp……)
Il capture les événements en permanence. Noter qu’on on ne récupère que les
événements AgentCalled, AgentConnect, AgentComplete, Cdr,
QueuememberPaused, Hangup, Hold et Newstate. Donc le Tserver fait un filtrage
des événements.
Il associe à chaque événement une fonction qui s’exécute dès que l’événement se
produit.
Rôle de ces fonctions :
Chaque fonction récupère toutes les variables de l’événement sous forme de tableau associatif (clé/ valeur).
Ces variables sont ensuite, soit insérées dans la base Tserver, soit utilisées pour mettre à jour les tables
agentvent et astrequest de la base stat_realtime. Tserver écrit dans 2 bases comme indiqué ci-dessous :
Bases Tables
Agentcalled, AgentConnect, AgentComplete, Cdr, Cdr_autre, Dispo, Acw, Wait
Tserver
et Attente
Stat_realtime Astrequest, Agentvent
La différence entre les tables astrequest et agentvent est que le script lit dans la table astrequest le
statut concernant l’agent et d’autres infos dont le script a besoin ( a savoir l’ID de la fiche, le numéro
appelant……). Le portail lit dans la table agentvent.
Le tableau suivant indique, pour chaque fonction/ événement, les tables dans lesquelles elle insère les
variables récupérées et les déclencheur de l’événement,
Evénement insère dans quelle table? Tables mis à jour Déclencheur
Astrequest L’agent est appelé
AgentCalled AgentCalled
par une queue
Astrequest L’agent a décroché
AgentConnect AgentConnect
Agentvent
Astrequest L’agent a fini sa
AgentComplete AgentComplete
Agentvent com et a raccroché
Cdr
Cdr Cdr_autre Appel terminé
Astrequest
QueuememberPaused Dispo
Agentvent
Acw
Astrequest L’agent ou le client
Hangup Wait
Agentvent a raccroché
Astrequest
Hold attente
Agentvent Hold ou Unhold
Astrequest
Newstate
Agentvent
AgentCalled :
Récupère toutes les variables de l’événement AgentCalled,
Met à jour le champ ‘CurrentState’ en ‘Ringing’ dans la table Astrequest et
Insère les données de variables récupérées dans la table agentcalled.
AgentConnect :
Récupère toutes les variables de l’événement AgentConnect,
Met à jour le champ ‘CurrentState’ en ‘COM’ dans la table Astrequest,
Met à jour la table Agentvent et
Insère les données de variables récupérées dans la table AgentConnect.
AgentComplete :
Récupère toutes les variables de l’événement AgentComplete,
Insère les données des variables dans la table AgentComplete ; il permet d’avoir la durée de com.
Cdr :
Récupère toutes les variables de l’événement Cdr,
Stocke dans la table Cdr de la base Tserver les cdr sur les queues et stocke les autres cdr dans la
table cdr_autre. Ceci pour alléger les deux tables.
QueueMemberPaused :
Cette fonction intervient quand l’événement QueueMemberPaused se produit. Deux états peuvent
alors être produites : (dispo ou indispo). Dans chacun de ces deux cas, il exécute une série d’actions
Cas Indispo : vérifie si le log était en dispo, si c’est le cas, il ferme ce cas dispo et insère dans la table
Dispo (DateDebIndispo..).
Cas Dispo : vérifie si le log était en indispo, si c’est le cas, il ferme ce cas d’indispo et met à jour la
table Dispo (DateFinIndispo).
Dans les 2 cas, les tables astrequest et agentvent sont mises à jour.
Hangup :
Cette fonction vérifie qui est à l’origine du raccrochage.
Si c’est le cc qui a cliqué sur LogOff ou Fin implique que c’est le cc qui a déclenché le
raccrochage et qu’il n’y a pas d’ACW. Le cc est alors mis en dispo. 1 ligne est insérée dans la table
wait (DateDebWait….) en attendant de recevoir un autre appel pour mettre à jour la table wait et
indiquer la DateFinWait. Les tables astrequest et agentvent sont mis à jour.
Sinon si c’est le client qui a raccroché, donc le cc effectuera un ACW. Dans ce cas, le cc est
mis en indispo. Une ligne est insérée dans la table acw (en indiquant DateDebAcw). Les tables
astrequest et agentvent sont mis à jour (champ ’CurrentState’ en ‘acw’). Dès que le cc finit de codifier
et clique sur Fin, il est remis en dispo et DateFinWait est indiquée dans la table acw.
Hold :
Noter que seul le cc peut déclencher ‘Hold’. Cette fonction récupère l’état (si c’est à Hold ou Unhold).
Si c’est à Hold, il met à jour la table astrequest et agentvent et insère dans la table attente
(‘DateDébAttente’ ,’StatutAttente’…….).
Dès que c’est à Unhold, les tables astrequest, attente et agentvent sont mises à jour.
Newstate :
L’événement Newstate se produit quand l’état d’un canal change. Il récupère des variables telles que
l’état d’un canal actuel qui est soit (Down, Reserve, Dialing, Ring, Ringing, Up, Busy, Pre-ring,
unknown). Cette fonction est utilisée dans le cas de l’émission d’appel mode préview (cas ou l’appel
ne passe pas par la queue). Quand un agent poste un appel sortant, elle récupère le channel utilisé
par son extension pour poster l’appel sortant, son log et met à jour la table agentvent et astrequest
(champ currentstate en ‘DIAL’). Dès que le client décroche, le statut de l’agent est mis ‘EN COM’.
2/ AGENTACTION
AGENTACTION traite les demandes postées par les ccx vers Asterisk.
Les demandes ou actions que peuvent poster les ccx sont : Demande de Logon, Demande de Logoff,
Disponible, Indisponible, Raccrochage, Transfer, Rappel.
En effet les ccx sont créés et paramétrés dans la base suivante :
Base Tables
Stat_realtime Astrequest, Agentvent
AgentAction n’écrit que dans la base Stat_realtime : il met à jour les tables astrequest et agentvent.
En effet, le script client ne communique pas directement avec Asterisk. Le script poste les actions
effectuées par le cc dans la table astrequest : il met à jour les champs ‘Statedem’ et ‘Libdem’ dans
Astrequest.
Statedem, état de la demande : 0 Demande pas encore traitée
1 Demande en cours de traitement
2 Demande traitée
Libdem, le nom de la demande: AgentCallBackLogin Demande de Logon
AgentLogoff Demande de Logoff
QueuePause Disponible
QueueUnPause Indisponible
Hangup Demande de raccrochage
FinEtLogoff Fin et Logoff
Transfer Demande de Transfer
OutBand Demande de rappel
AgentAction est un service qui effectue les process suivants:
Il lit les paramètres de connexion dans le dossier Config (users, mots de passe, dB,
paramètres de connexion asterisk, paramètres de connexion dB……)
Il se connecte aux différents serveurs (asterisk, dB, et via scp……)
Il tourne en permanence et récupère toutes les demandes qui ne sont pas encore traitées.
Pour éxécuter cette tache, Il récupère toutes les lignes dans Astrequest dont Statedem=’0‘ et
‘Libdem’ correspond à un des items suivants :
AgentCallBackLogin','AgentLogoff','QueuePause','QueueUnPause','Hangup','FinEtLogoff','Tra
nsfer','OutBand'.
Il prend en charge ces demandes et met à jour le champ ‘Statedem’ à 1. Et récupère pour
chaque demande, le log, l’extension, la queue, le channelCalling, le numéro à appeler, le
channel, le nom.
Il exécute la fonction correspondante à chaque type de demande.
Différentes fonctions sont créées. Chaque type d’action ciblé pour traitement est associé à une
fonction.
Chaque fonction, récupère les paramètres de la demande et le convertit en événement d’AMI
qu’elle envoie à Asterisk.
Le résultat de la requête est analysé par la fonction ; si c’est en « success », il met à jour la
table astrequest. Le champ Statedem est mis à 2.
3/ STATQUEUE
STATQUEUE est un service qui effectue les process suivants:
Il lit les paramètres de connexion dans le dossier Config (users, mots de passe, dB,
paramètres de connexion asterisk, paramètres de connexion dB……)
Il se connecte aux différents serveurs (asterisk via AMI, dB, et via scp……)
Il lance en continu pour chaque queue la commande qstatus : nom_queue.
Il récupère le résultat dans des variables.
Il insère les variables récupérées dans la table ‘queuestatus’ si la table est vide sinon il met à
jour les données de la table pour chaque queue.
4/ DIALER
Mode Préview : C’est le cc qui émet l’appel. Il peut le faire soit en composant sur son téléphone, soit
en lançant une demande d’appel.
Mode Progressif : Il vérifie d’abord le nombre d’agents dispo, ensuit il émet les appels en suivant la
règle : nombre d’appels émis égal nombre d’agents disponibles.
Mode Prédictif :
Il vérifie d’abord le nombre d’agents dispo.
Pour le premier lancement, il émet le même nombre d’appels que le nombre d’agents dispo.
Pour le cas suivant, il se base sur un algorithme pour connaitre le nombre d’appels à émettre.
Après le lancement t, suivant le nombre d’appels décroché, il calcule le nombre d’appels qu’il fallait
émettre pour qu’un cc ait une communication. Il multiplie ce résultat par le nombre de Ccx pour
déterminer le nombre d’appels à émettre au lancement t+1.
En exemple, supposons qu’on a 10 agents disponibles en émission d’appel prédictif. 10 appels sont
lancés en premier temps et seulement 8 ont décrochés. Pour le lancement suivant, il calcule :
10 ag ------------- 10 app ------------------ 8 com
1 ag --------------- ?app ------------------ 1 com
Pour qu’un agent ait un appel décroché, il fallait émette 10/8 appels
Pour 10 agents, il faut émettre (10/8)*10 appels
Outbound System est une plateforme d’émission d’appels qui comporte plusieurs queues; elle est
composée de plusieurs modules :
Le module de paramétrage des trunks : est une table qui comporte l’ensemble des gateways
disponibles
Le module de paramétrage des campagnes : c’est à ce niveau qu’on déclare la campagne, la
queue, le nombre de trunks.
Le module de paramétrage des CL : c’est à ce niveau qu’on effectue l’affectation des CL aux
campagnes.
Le module Dialer est un programme perl qui tourne en permanence et qui se base sur les
configs pour émettre des appels. C’est un programme multithread, ainsi pour chaque
campagne il génère un thread qui se chargera d’émettre des appels pour cette campagne.
Fonctionnement du Dialer :
Il se connecte sur asterisk et sur la base IPVoX Outbound
Il combine les tables cfg_campaign, cfg_gateway et cfg_CL afin de récupérer les infos
nécessaires pour une campagne d’émission: le nom de la campagne, la queue
concernée, la liste des CL, le trunk et le nombre de ports.
Il se connecte sur la base stat_realtime agentvent pour récupérer le nombre d’agents
/statut (nombre d’agents dispo, en com indispo).
Il prend le nombre d’agents en wait combiné à un algorithme pour trouver le nombre
d’appels à émettre au prochain saut. L’algorithme tourne chaque 15min; il récupère le
nombre d’appels nécessaire pour qu’un cc décroche qu’il multiplie par le nombre de Ccx
dispo. Ce nombre additionné à l’OverDial est comparé au nombre de trunks.
Si > au nombre de trunks, il est limité au nombre de trunks, sinon ce même nombre d’appel
est émis.