Hay un centro de llamadas. Hay Asterisk / FreePBX con colas configuradas. Hay agentes que deben atender las llamadas. Pero hay tantos clientes potenciales, y hay tan pocos agentes que el primero no puede pasar al segundo de ninguna manera: cuelgue en la cola por un minuto e incluso apague.¡Pero por alguna razón llamaron! ¿Quizás quieren traer dinero a la empresa? Intentemos devolver tanto a los clientes como a su dinero utilizando el ejemplo de FreePBX.En la configuración de la cola, puede especificar el Destino de conmutación por error: dónde enviar la llamada cuando la cola está llena, el tiempo de espera ha transcurrido, etc. Pero a menudo sucede que la persona que llama se desconecta antes de que pueda ser redirigido a Fail Over Destination; nunca se sabe, la conexión se desconecta. No existe una solución preparada para tales casos. Por lo tanto, vamos por debajo del corte y escribimos el suyo, con el envío de una alerta a Telegram / Slack / E-mail / en otro lugar.Y lo primero que debemos entender es cómo FreePBX escribe registros de colas. En el caso más simple, este es el archivo de texto / var / log / asterisk / queue_log.Por lo tanto, se escribe una llamada regular en el registro desde el suscriptor 8964467XXXXX, quien llamó a 302221XXXX, quien está en la línea 603 a la primera posición, a lo que Agent Girl respondió 8 segundos después. Hablaron 133 segundos y el suscriptor fue el primero en colgar: ¡todos tendrían gerentes tan educados!1584318765|1584318747.89449|603|NONE|DID|302221
1584318765|1584318747.89449|603|NONE|ENTERQUEUE||8964467|1
1584318774|1584318747.89449|603|Agent Girl|CONNECT|9|1584318765.89450|8
1584318907|1584318747.89449|603|Agent Girl|COMPLETECALLER|9|133|1
Y aquí hay una historia ligeramente diferente cuando un suscriptor 8996453XXXXX llamó por teléfono a 302257XXXXX, colgó 10 segundos en la línea No. 210 en la primera posición y se desconectó. ¡Ni siquiera escuché el menú de voz!1581728710|1581728690.59367|210|NONE|DID|302257
1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
Eso es sobre él, escribiremos en el mensajero.Para hacer esto, necesitamos detectar la ocurrencia del evento ABANDON en el archivo de registro. Durante mucho tiempo me pregunté cómo se puede hacer esto, pero por casualidad me encontré con una herramienta maravillosa: MONIT . En nuestro caso, supervisará el registro de la cola y, tan pronto como aparezca la línea "ABANDON", llamará al script para procesar este evento.Para hacer esto, después de instalar el paquete:yum install monit
Configúrelo: cree el archivo /etc/monit.d/queue_log y escriba literalmente tres líneas en él:check file queue_log with path /var/log/asterisk/queue_log
if content = "ABANDON" then
exec "/var/lib/asterisk/agi-bin/qlogevent.sh $EVENT"
Por lo tanto, cuando aparece la palabra "ABANDON" en el registro de la cola, que nos dice que desconectemos prematuramente al suscriptor, se llamará al script /var/lib/asterisk/agi-bin/qlogevent.sh con el parámetro $ EVENT, que no es más que completamente la línea en la que apareció esta palabra.Es simple.Y ahora no es el ajedrez lo que comienza, debes pensarlo.La línea pasada al script no contiene información sobre el número de la persona que llama:1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
Solo tiene marca de tiempo (1581728720), un ID de llamada único (1581728690.59367), un número de cola (210), el evento en sí y algunos otros parámetros no esenciales. Aquellos. Tendremos que buscar el número de suscriptor nosotros mismos. ¿Y de qué manera? ¡Y es muy simple, porque tenemos un UID de una llamada!Volvamos nuevamente al registro de esta llamada, específicamente, a la línea en la que el suscriptor cae en la cola:1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
Cuando se produce el evento "ENTERQUEUE", uno de los parámetros es el número de suscriptor que necesitamos. Solo podemos encontrar esta línea en el archivo queue_log. Esto es exactamente lo que está haciendo el script bash, que MONIT nos llamó cuidadosamente:#!/bin/bash
timedate=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2 | gawk '{print strftime("%d.%m.%Y %H:%M:%S",$0);}')
call_id=$(echo $MONIT_DESCRIPTION | cut -d\| -f2)
qnum=$(echo $MONIT_DESCRIPTION | cut -d\| -f3)
case $qnum in
210)
qname=" 1"
;;
220)
qname=" 2"
;;
esac
str=$(grep "|$call_id|$qnum|.*|ENTERQUEUE" /var/log/asterisk/queue_log)
caller_id=$(echo $str | cut -d\| -f7)
time_enter=$(echo $str | cut -d\| -f1)
time_abandon=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2)
data=" $caller_id $timedate $qname, $(($time_abandon-$time_enter)) ."
/usr/bin/curl -X POST -H 'Content-type: application/json' --data '{"text":"'"$data"'"}' "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
En realidad, eso es todo!Es cierto, hay un incidente: MONIT, diseñado para monitorear todo y todo; en sí mismo necesita monitoreo, porque cae periódicamente