Get best of the week

Asterisk dan pengiriman tidak terjawab di Telegram / Slack / E-mail

Ada pusat panggilan. Ada Asterisk / FreePBX dengan antrian yang dikonfigurasi. Ada agen yang harus melayani panggilan. Tetapi ada begitu banyak pelanggan potensial, dan ada begitu sedikit agen yang pertama tidak dapat melewati yang kedua dengan cara apa pun - hang-hang dalam antrean selama satu menit, dan bahkan mematikan.

Tetapi karena alasan tertentu mereka memanggil! Mungkin mereka ingin membawa uang ke perusahaan? Mari kita coba untuk mengembalikan pelanggan dan uang mereka menggunakan contoh FreePBX.

Dalam pengaturan antrian, Anda dapat menentukan Tujuan Gagal - tempat mengirim panggilan saat antrian penuh, periode waktu habis telah berlalu, dll. Tetapi sering terjadi bahwa penelepon terputus sebelum ia dapat dialihkan ke Fail Over Destination - Anda tidak pernah tahu, koneksi terputus. Tidak ada solusi siap pakai untuk kasus-kasus seperti itu. Oleh karena itu, kami melakukan pemotongan dan menulis sendiri - dengan mengirimkan peringatan ke Telegram / Slack / E-mail / di tempat lain.

Dan hal pertama yang perlu kita pahami adalah bagaimana FreePBX menulis log antrian. Dalam kasus yang paling sederhana, ini adalah file teks / var / log / asterisk / queue_log.

Jadi, panggilan reguler ditulis ke log dari pelanggan 8964467XXXXX, yang memanggil 302221XXXX, yang berada di jalur No. 603 ke posisi pertama, yang dijawab Agent Girl 8 detik kemudian. Mereka berbicara 133 detik dan pelanggan adalah yang pertama menutup telepon - semua orang akan memiliki manajer yang sopan!

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

Dan di sini adalah cerita yang sedikit berbeda ketika pelanggan 8996453XXXXX menelepon 302257XXXXX, digantung 10 detik di jalur No. 210 di posisi pertama dan terputus. Saya bahkan tidak mendengarkan menu suara!

1581728710|1581728690.59367|210|NONE|DID|302257
1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10

Itu tentang dia, kami akan menulis di utusan.

Untuk melakukan ini, kita perlu menangkap kejadian peristiwa ABANDON di file log. Saya sudah lama bingung bagaimana hal ini bisa dilakukan, tetapi kemudian secara kebetulan saya menemukan alat yang luar biasa - MONIT . Dalam kasus kami, ini akan memonitor log antrian, dan segera setelah baris "ABANDON" muncul di dalamnya, ia akan memanggil skrip untuk memproses acara ini.

Untuk melakukan ini, setelah menginstal paket:

yum install monit

Atur - buat file /etc/monit.d/queue_log dan tulis hanya tiga baris di dalamnya:

check file queue_log with path /var/log/asterisk/queue_log
    if content = "ABANDON" then
        exec "/var/lib/asterisk/agi-bin/qlogevent.sh $EVENT"

Jadi, ketika kata "ABANDON" muncul di log antrian, yang memberitahu kita untuk memutuskan sambungan pelanggan secara prematur, skrip /var/lib/asterisk/agi-bin/qlogevent.sh dengan parameter $ EVENT akan dipanggil, yang tidak lain adalah sepenuhnya garis di mana kata ini muncul.
Itu mudah.

Dan sekarang bukan catur yang dimulai - Anda harus berpikir.

Baris yang diteruskan ke skrip tidak berisi informasi tentang nomor penelepon:

1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10

Ini hanya memiliki Timestamp (1581728720), ID panggilan unik (1581728690.59367), nomor antrian (210), acara itu sendiri dan beberapa parameter tidak penting lainnya. Itu Kami harus mencari sendiri nomor pelanggan. Dan dengan cara apa? Dan itu sangat sederhana, karena kami memiliki UID panggilan!

Mari kita kembali ke log panggilan ini, khususnya, ke baris di mana pelanggan jatuh ke dalam antrian:

1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1

Ketika acara "ENTERQUEUE" terjadi, salah satu parameter adalah nomor pelanggan yang kita butuhkan. Kami hanya dapat menemukan baris ini di file queue_log. Inilah yang dilakukan skrip bash, yang oleh MONIT memanggil kami dengan cermat:

#!/bin/bash
#MONIT_DESCRITION - ,      .
# timestamp    - ( №1).
timedate=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2 | gawk '{print strftime("%d.%m.%Y %H:%M:%S",$0);}')
# UID ( №2)
call_id=$(echo $MONIT_DESCRIPTION | cut -d\| -f2)
#   ( №3)
qnum=$(echo $MONIT_DESCRIPTION | cut -d\| -f3)

#      
case $qnum in
    210)
        qname=" 1"
        ;;
    220)
        qname=" 2"
        ;;
esac

#      UID,     ENTERQUEUE
str=$(grep "|$call_id|$qnum|.*|ENTERQUEUE" /var/log/asterisk/queue_log)
#      ( №7)
caller_id=$(echo $str | cut -d\| -f7)
#     ( №1)
time_enter=$(echo $str | cut -d\| -f1)
#     ( №1   ABANDON)
time_abandon=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2)
# 
data=" $caller_id $timedate   $qname,       $(($time_abandon-$time_enter)) ."
#    /.     Slack.
/usr/bin/curl -X POST -H 'Content-type: application/json' --data '{"text":"'"$data"'"}' "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Sebenarnya itu saja!

Benar, ada satu kejadian - MONIT, yang dirancang untuk memantau segalanya dan segalanya, itu sendiri perlu pemantauan, karena jatuh secara berkala.

More articles:


All Articles