Unified Communications Expert

Управление iptables при помощи CGI-скриптов

Игнат Кудрявцев — Wed, 29 May 2019 15:50:44 +0000

Использование функционала CGI, скриптов bash(равно как и на другом языке программирования), веб-сервера и авторизации по ключам ssh позволяет легко реализовать полезные в администрировании веб-приложения. Ниже представлен практический пример: удалённое управление сетевым фильтром iptables через веб-интерфейс.

Задача: при помощи веб-форм размещённых на веб-сервере, добавлять удалять и просматривать правила сетевого фильтра iptables на удалённых серверах, также запускать ping и traceroute, получать результат вывода в веб-интерфейс. Такой функциона полезен для упрощения процесса конфигурирования сетевого экрана, позволяет исключить использование консоли при конфигурировании, и соответственно не давать доступ пользователям в shell, если есть дублирующие сервера, управлять правилами сетевых фильтров на всех одновременно.
Ниже представлена общая схема работы. Данный материал не приследует цель дать полную инструкцию по реализации такой схемы, а лишь даёт идею для реализации с некоторыми техническим подробностями.

Пользователь, при помощи веб-браузера, авторизуется(при помощи встроенного в веб-сервера Apache механизма) на странице, которая сорержит CGI-скрипт, когда пользователь добавляет удаляет или просматриваем правила в iptables через веб-форму, скрипт по ssh «дёргает» другие скрипты находящиеся на удалённом сервере и возвращает в веб-браузер клиента результат выполнения скрипта с удалённого сервера.

Процесс настройки выглядит следующим образом:
1) Настройка веб-сервера Apache и его работу с CGI
2) Защита логином и паролем директорию веб-сервера где находятся скрипты
3) Создание пользователя на удалённом хосте, где будут выполняться команды от CGI скриптов
при помощи ssh
4) Добавление прав пользователю на выполнения команд требующих повышения прав при помощи sudo
5) Загрузка bash скриптов обработчиков команд по ssh от веб-сервера на удалённом хосте
6) Разрешаем авторизацию по ключам для sshd
7) Настройка авторизации по ключам ssh
8) Загрузка bash скриптов в директорию CGI назначение им прав
9) Тестирование работы

Шаг 1. Настройка веб-сервера Apache и cgi

В Linux Centos открываем /etc/httpd/conf/ httpd.conf, находим строки:

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#

    #AllowOverride None
    AllowOverride All
    Options None
    Order allow,deny
    Allow from all

Здесь нас интересует параметр AllowOverride, который по умолчанию установлен как None, меняем её на AllowOverride All.

Далее рестартуем Apache:

/etc/init.d/httpd restart

Тоже самое, но для Debian, здесь будет отличаться настройка Apache.

Переходим в /etc/apache2/sites-available
создаём файл firewall-web
# > firewall-web
Порт 80 на котором будет находиться виртуальный хост:

Listen *:80

ServerAdmin ignat@spb.ru

DocumentRoot /usr/lib/cgi-bin

Options FollowSymLinks
AllowOverride None

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride All
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all


ErrorLog ${APACHE_LOG_DIR}/error-firewall-web.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access-firewall-wb.log combined

Сохраняем.

Далее переходим в директорию /etc/apache2/sites-enabled
И создаём символическую ссылку на /etc/apache2/sites-available/firewall-web

Теперь делаем reload конфигурации Apache:

#/etc/init.d/apache2 reload

Также нужно проверить что в /etc/apache2/mods-enabled есть ссылка на файл /etc/apache2/mods-available/cgi.load
Если нет, то создать, и перечитать конфигурацию веб-сервера:
#/etc/init.d/apache2 reload
Отлично, теперь надо защитить наши скрипты от неавторизованного доступа, один из простейших вариантов добавить http аутентификацию и авторизацию.

Шаг 2. Защита логином и паролем директорию веб-сервера где находятся скрипты

Настройка простой аутентификации и авторизации в Apache

Настраивается аутентификация либо в файле httpd.conf, либо в файле .htaccess. При настройке посредством .htaccess, необходимо сначала убедиться, что директива AllowOverride в файле httpd.conf разрешает получение настроек из файла .htaccess. Директива AllowOverride может принимать следующие значения:

— AllowOverride None — файлы .htaccess игнорируются веб-сервером. Данное значение оказывает положительное влияние на быстродействие веб-сервера.

— AllowOverride All — обрабатываются все без исключения директивы из файлов .htaccess.

— AllowOverride AuthConfig — разрешены директивы аутентификации-авторизации, такие как AuthName, AuthType, AuthUserFile, AuthGroupFile, Require и т.д.

Чтобы авторизация заработала, нам надо сделать следующее:

— Разрешить аутентификацию в конфигурационном файле Apache (файл httpd.conf)

— Прописать защищаемый ресурс в конфигурацию Apache (в файле .htaccess).

— Создать файл с паролями .htpasswd.

Далее, предполгаем что наши скрипты лежат в директории /var/www/cgi-bin/.
Мы защищаем директорию с нашими скриптами /var/www/cgi-bin/ поэтому создаём в ней файл .htaccess с правами apache:

#> .htaccess
#chown apache:apache .htaccess
В файл .htaccess добавим:
AuthName "Authentication"
AuthType Basic
AuthUserFile /var/www/cgi-bin/.htpasswd
require valid-user

Что обозначает каждая из директив:

AuthName – текст содержащийся в данной директиве, выводится в окне ввода пароля. Он должен быть написан в одну строку и заключен в двойные кавычки.
AuthType — типы аутентификации: Basic или Digest. Рекомендуется использовать первый, т.к. второй поддерживается не всеми браузерами.
AuthUserFile — полный путь к файлу с логинами и паролями, для аутентификации пользователей. Пароли содержаться в шифрованном виде. Рекомендуется хранить данный файл в папке, к которой нет доступа для пользователей, это необходимо, чтобы предотвратить кражу паролей.
require valid-user – директива предписывает, что к URL получают доступ только, пользователи, успешно прошедшие аутентификацию.

Сохраняем. Теперь нужно создать файл .htpasswd
Это делается при помощи утилиты htpasswd
Ключи:
-cm — ключи утилиты:
-с – указывает, что необходимо создать новый файл
-m –шифрует пароли по алгоритму MD5
.htpasswd – имя файла с паролями
firewall – логин
Создаём пользователя с новом файле:

#htpasswd -cm .htpasswd firewall

Дважды вводим пароль для пользователя firewall.
Листинг содержимого получившегося файла:

# cat .htpasswd
firewall:$apr1$xMW8mAaG$259lBs0uXj.M/t1Yu7T2u1

Добавить ещё одного пользователя в существующий файл:
#htpasswd -m .htpasswd ignat

Теперь при открытии адреса http://192.168.1.252/cgi-bin/ будет появляться окно авторизации:

После успешной перезагрузки переходим в директорию /usr/lib/cgi-bin и размещаем здесь файлы CGI-скриптов.

Шаг 3. Создание пользователя на удалённом хосте, где будут выполняться команды от CGI-скриптов при помощи ssh

Добавляем авторизацию по ключам ssh. Мы поставили веб-сервер Apache на одной машине 192.168.1.252, залить туда скрипты и при помощи команд SSH удалённо выполнять команды на хосте 192.168.1.16 и анализировать из результат, например:

ssh firewall-edit @192.168.1.16 'uptime'
13:32:59 up 584 days,  1:26,  4 users,  load average: 0.41, 0.34, 0.27

Для этого нужно настроить авторизацию по ключам на ssh-клиенте(192.168.1.252) и на удалённом ssh-сервере (192.168.1.16).

Создадим пользователя на удалённом сервере, дадим ему права на выполнение без пароля команд iptables и iptables-save:

#useradd firewall-edit  --create-home --comment 'Remote firewall editor' --shell /bin/bash
#passwd firewall-edit

Шаг. 4 Добавление прав пользователю на выполнения команд требующих повышения прав при помощи sudo

Отлично, теперь нужно добавить возможно выполнять команды iptables и iptables-save без прав root.
Пропишем в /etc/sudoers, из под root отредактируем данный файл:

#aptitiude install sudo
#sudoedit /etc/sudoers

Добавим следующие строки:

firewall-edit  ALL=(ALL) NOPASSWD:/sbin/iptables
firewall-edit  ALL=(ALL) NOPASSWD:/sbin/iptables-save

Сохраняем.

Шаг. 5 Загрузка bash скриптов обработчиков команд по ssh от веб-сервера на удалённом хосте

Конечно, можно посылать по ssh просто команды, затем обрабатывать их вывод на веб-сервере(192.168.1.252), но зачем «гонять» лишние данные? Поэтому загрузим скрипты которым будут передаваться нужные параметры, они буду их обрабатывать и выдавать результат, который мы передадим назад веб-серверу и покажем пользователю на веб-странице.

Ниже пример:

ucexpert.ru:/home/firewall-edit# cat firewall-find-ip.sh
#!/bin/bash 
sudo iptables -L CLIENTS -n -v --line-number| sed '1,1d'| grep $1 |  awk '{print "" $1 "" $9 ""}'

Обращаю внимание что в вывод сразу же добавлена html разметка для отображении в веб-браузере клиента.
На стороне веб-сервера(192.168.1.252) этот скрипт будет вызываться так:

sudo ssh firewall-edit@192.168.1.16 "./firewall-find-ip.sh $IP"

Первый скрипт получает IP адрес, ищет его в таблице и отправляет результат.

ucexpert.ru:/home/firewall-edit# cat firewall-get-ip.sh
#!/bin/bash 
sudo /sbin/iptables -L CLIENTS -n -v --line-number| sed '1,1d' |  awk '{print "" $1 "" $9 ""}'

На стороне веб-сервера(192.168.1.252) этот скрипт будет передаваться как:

sudo ssh firewall-edit@192.168.1.16 './firewall-get-ip.sh'

Второй скрипт возвращает назад все правила с номерами(--line-number) в цепочке CLIENTS, в виде html таблицы.

Команды ping и traceroute будем запускать без скриптов.

sudo ssh firewall-edit@192.168.1.16 "ping $IP -I $RTU -c 5" 
sudo ssh firewall-edit@192.168.1.16 "traceroute $IP"

Создаём окружение для скриптов на 192.168.1.16

Создаём файл iptables в нашей домашней директории, сюда мы будем сохранять правила iptables.

/home/firewall-edit# > iptables

Копируем скрипты:

firewall-find-ip.sh
firewall-get-ip.sh
firewall.sh

Далее, назначаем необходимые права нашему пользователю, который будет удалённо выполнят команды:

#/home/firewall-edit# chown firewall-edit:firewall-edit firewall.sh
#/home/firewall-edit# chown firewall-edit:firewall-edit iptables

Скрипте на сервере запускаем при помощи sudo

#sudo /sbin/iptables -L -n -v | grep 84.84.84.84
#sudo ./firewall.sh add 84.84.84.84
#sudo ./firewall.sh del  84.84.84.84

Устанавливаем права на скрипты, пример:

#/home/firewall-edit# chown www-data:www-data firewall.sh
#/home/firewall-edit# chmod +x firewall.sh

Для отладки команд, которые передаются на удалённый сервер по SSH можно также использовать ttyrec или поставить утилиту snoopy:

ucexpert.ru:/home/firewall-edit# #aptitude install snoopy

Данная утилита логирует пользовательские команды, интерактивно смотреть их при помощи команды:

ucexpert.ru:/home/firewall-edit# #tail -f /var/log/auth
Apr 13 11:25:43 rtu4-1 sshd[3273]: Accepted publickey for firewall-edit from 192.168.1.252 port 53822 ssh2
Apr 13 11:25:43 rtu4-1 sshd[3273]: pam_unix(sshd:session): session opened for user firewall-edit by (uid=0)
Apr 13 11:25:43 rtu4-1 sudo: firewall-edit : TTY=unknown ; PWD=/home/firewall-edit ; USER=root ; COMMAND=/sbin/iptables -L CLIENTS -n -v --line-number
Apr 13 11:25:43 rtu4-1 sshd[3296]: Received disconnect from 192.168.1.252: 11: disconnected by user

Шаг 6. Разрешаем авторизацию по ключам для sshd на удалённом хосте
Открываем /etc/ssh/sshd_config
Проверяем, что следующие строки присутствуют и не закомментированы:

RSAAuthentication yes
PubkeyAuthentication yes

После чего перезапускаем sshd.

Шаг 7. Настройка авторизации по ключам ssh

На клиенте(192.168.1.16) локальной машине нужно сгенерировать пару ключей:

приватный id_rsa – хранится у клиента в файле /home/$user/.ssh/id_rsa
публичный id_rsa.pub – хранится в файле /home/$user/.ssh/id_rsa.pub

Где $user пользователь который генерирует ключ. Для root этот путь будет /root/.ssh

Мы генерируем файл из под root, соответственно чтобы подключаться по ssh веб-сервере и пользователь www-data должны запускать ssh с правами root или sudo ssh.

Сгенерируем пару ключей на клиенте (192.168.1.252) при помощи утилиты ssh-keygen (если ключ уже создан для нового хоста его генерировать не требуется)

# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GXgitSSV+S66HjiNW9A9pcehP3WECulLpi5tuPrt2bs root@CDR-serv
The key's randomart image is:
+---[RSA 2048]----+
|    ..+o         |
|     +o+   .     |
|    . *.= . .    |
|   . + O.= .     |
|  . . O.S . .    |
|   = +.=.. .     |
|  +o=...o        |
|  o*++   .       |
|.o+*B.Eo         |
+----[SHA256]-----+

Чтобы авторизоваться на 192.168.1.16, предварительно открытый или публичный ключ должен быть загружен на сервер, для этого загрузим ключ на сервер 192.168.1.16 при помощи утилиты ssh-copy-id:

# ssh-copy-id firewall-edit@192.168.1.16
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host '192.168.1.16 (192.168.1.16)' can't be established.
RSA key fingerprint is SHA256:Ma5zmprv9jGPkwdSwEgwFK2L4jyzCqc1xxoXYW5I7e0.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
firewall-edit@192.168.1.16's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'firewall-edit@192.168.1.16'"
and check to make sure that only the key(s) you wanted were added.

Таким образом ключ успешно инсталлирован.

Проверим работу авторизации по ключу:

# ssh firewall-edit@192.168.1.16 'uptime'
 18:13:03 up 582 days,  6:06,  2 users,  load average: 0.14, 0.21, 0.19

Теперь проверяем: из под пользователя firewall-edit заходим на удалённый хост по ключу и запускаем команду iptables.

# ssh firewall-edit@192.168.1.16 ' sudo /sbin/iptables -L -n -v '

Если будет возвращён вывод запущенной конфигурации iptables, то всё настроено правильно.
На этом настройка авторизации по ssh ключам завершена.

Шаг 8. Загрузка bash скриптов в директорию CGI веб-сервера 192.168.1.252 назначение им прав

Создаём окружение для скриптов на клиенте.

Здесь есть один важный момент: скрипты запускаются из под пользователя www-data
Чтобы запускать ssh с авторизацией по ключам надо повысить уровень прав, нам поможет sudo.
Пропишем в /etc/sudoers, из под root отредактируем данный файл:

#sudoedit /etc/sudoers

Добавим следующие строки:

www-data  ALL=(ALL) NOPASSWD: /usr/bin/ssh

Сохраняем.

Теперь создаём cgi скрипт который будет выполняться при открытии и успешной авторизации в веб-браузере ссылки http://192.168.1.252/cgi-bin

Листинг скрпита index.cgi с комментариями:

root@CDR-serv:/var/www/html/cgi-bin# cat index.cgi #!/bin/bash echo "Content-type: text/html" echo "" echo '' echo '' echo '' #Загружаем favicon echo '' echo '' #Заголовок страницы echo 'FIREWALL EDITOR for RTU4 ' echo '' echo '' #Заголовок 3 уровня на странице echo '

' RTU 4 FIREWALL EDITOR echo '

' echo '

'Проветить есть IP-адрес в списке разрешённых $можно ввести часть, например: 84.52.$ без маски или префикса сети: echo '

' #Начало формы поиска разрешённых IP-адресов в списке echo "' echo '

'Добавить IP-адрес и префикс сети $опционально, например 29$: echo '

' echo "' #Конец формы поиска IP-адрес в списке разрешённых, при нажатии кнопки "Проверить" выполнится скрипт find-ip-addr.cgi причём он примет единственный аргумент IP и в браузер вернётся результат выполнения скрипта echo '

'Удалить IP-адрес $без маски или префикса сети$: echo '

' #Начало формы добавления IP-адреса или подсети в список разрешённых, тут кроме аргумента IP - адреса и MASK - маску IP которую следует удалить, может опционально передаваться комментарий echo '

'Добавить IP-адрес и префикс сети $опционально, например 29$: echo '

' echo "' #Конец формы добавления IP-адреса в списке разрешённых, при нажатии кнопки "Добавить" выполнится скрипт firewall-add.cgi, с входными аргументами - IP-адрес и маску, опционально комментарий и в браузер вернётся результат выполнения скрипта #Аналогично, начало формы удаления IP-адреса из iptables. echo '

'Удалить IP-адрес $без маски или префикса сети$: echo '

' echo "' #Конец формы. При нажатии на кнопку "Удалить" выполнится скрипт firewall-del.cgi #Форма отображения полного списка разрешённых IP-адресов echo '

' Показать полный список разрешенныйх IP-адресов для транков РТУ 4 echo '

' echo "" #Конец формы отображения полного списка разрешённых IP-адресов. echo '' echo '' exit

При обращении к веб-серверу по адресу http://192.168.1.252/cgi-bin/ выполняется скрипт написанный на языке bash, а результат его выполения отдаётся веб-сервером в веб-браузер клиенту который запросил страницу, логично что это должен быть код HTML(хотя и не обязательно)
А а вот как будет выгядеть html-код страницы когда скрипт index.cgi будет выполнен и результат его работы будет возращён в веб-браузер клиента.






FIREWALL EDITOR for RTU4 and NET DIAGNOSTIC



 RTU 4 FIREWALL EDITOR


Листинг скрпита find-ip-addr.cgi который запускается из скрпита index.cgi при использовании веб-формы поиска IP-адреса:


Проветить есть IP-адрес в списке разрешённых (можно ввести часть, например: 84.52.) без маски или префикса сети:






                  

IP-адрес
 

                                      


                                      
                                       



Добавить IP-адрес и префикс сети (опционально, например 29):






                  

IP-адрес



                            

Префикс сети



				

Комментарий: 
 

                                      


                                      
                                       



Удалить IP-адрес (без маски или префикса сети):






                  

IP-адрес



		 

Комментарий: 
 

                                      


                                      
                                       



 Показать полный список разрешенныйх IP-адресов для транков РТУ 4

Здесь скриптом генеририуются html формы, затем этими веб-формами может воспользоваться клиент, к каждой веб-форме привязан скрипт(например, find-ip-addr.cgi), который также выполниться при запуске веб-формы и вернет результат обработки. Этот скрипт «лезет» на удалённый сервер, запускает другой скрипт, например firewall.sh и возвращает результат назад, затем результат в виде веб-страницы возвращается пользователю.

Теперь рассмотрим файл find-ip-addr.cgi

#!/bin/bash

echo "Content-type: text/html"
echo ""
echo ''

echo ''

echo '
 '



echo ''
echo ''
echo ''

echo 'Firewall'

echo ''

echo ''

echo ''Результат поиска:
echo ''
DATE=`date +%Y-%m-%d-%H:%M:%S`

if [ "$REQUEST_METHOD" = "POST" ]; then
    QUERY_STRING=`cat -`
    fi
    #echo `cat -` #Дебаг
    #echo "QUERY_STRING ==><> $QUERY_STRING 
" #Дебаг
    IP=`echo $QUERY_STRING | sed -n 's/^.*IP=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"` #Дебаг
    COMMENT=`echo $QUERY_STRING | sed -n 's/^.*COMMENT=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"` #Дебаг
    REMOTE_USER=`echo $REMOTE_USER`
    REMOTE_ADDR=`echo $REMOTE_ADDR`
    HTTP_USER_AGENT=`echo $HTTP_USER_AGENT`
    #echo "IP ==> $IP 
" #Дебаг
    echo "Результат поиска для введённого IP-адреса: $IP 

"
echo "Найдены правила в таблице брандмауэра РТУ 4:

"
echo ''
echo ''
sudo ssh firewall-edit@192.168.1.16 "./firewall-find-ip.sh $IP"
export LANG="ru_RU.UTF-8" # Это очень важный момент, без неё скрипту insert-log.py не передаётся аргумент закодированный кириллицей
echo '№ Правила IP-адрес или подсеть'
echo ''
./insert-log.py "$DATE" "ПОИСК" "$IP" "N/A" "$REMOTE_ADDR" "$REMOTE_USER" "$HTTP_USER_AGENT" "N/A" "$COMMENT"
echo ''
./get-ip-history.py "$IP"
echo "

Дата запроса: $DATE 
"
echo "Пользователь: $REMOTE_USER 
"
echo "Ваш адрес: $REMOTE_ADDR 
"
echo ''
echo ''

Ниже пример листинга скрипта firewall-find-ip.sh который выполняется на 192.168.1.16 который ищет запрошенные пользователем правила iptables.

#!/bin/bash 
sudo iptables -L CLIENTS -n -v --line-number| sed '1,1d'| grep $1 |  awk '{print "" $1 "" $9 ""}

Шаг 9. Тестирование работы

Вот как выглядет веб-странциа сгенерированная index.cgi:

Мы запускаем поиск первых трёх актетов IP адреса, например 84.52.72

и нажимаем кнопку «Проверить». Ниже результат:

Найдено несколько правил и они выведены в виде таблицы. Что произошло: пользователь загрузил страницу index.cgi с несколькими формами, передал переменную 84.52.72 в форму поиска IP-адреса, которая в свою очередь передала управление CGI-скрипту find-ip-addr.cgi данный скрипт выполняет комманду

sudo ssh firewall-edit@192.168.1.16 "./firewall-find-ip.sh $IP"

То есть, подключается к удалённому серверу выполняет на нём скрипт firewall-find-ip.sh и возвращает результат в веб-бразуер клиенту.

Автор: Игнат Кудрявцев

Получение кодов отбоя SIP и стороны завершившей вызов в Asterisk

Игнат Кудрявцев — Thu, 14 Mar 2019 05:49:18 +0000

В последних релизах Asterisk есть возможность получить коды отбоя Asterisk или SIP-код отбоя при помощи функции HANGUPCAUSE. В заметке приводится практический пример того как это сделать,а затем записать результаты в БД MySQL. Также приведен пример того, как в Asterisk узнать какая из сторон была инициатором завершения вызова.

В консоли Asterisk посмотрим описание функции HANGUPCAUSE.

CLI> core show function HANGUPCAUSE

  -= Info about function 'HANGUPCAUSE' =-

[Synopsis]
Gets per-channel hangupcause information from the channel.

[Description]
Gets technology-specific or translated Asterisk cause code information from the
channel for the specified channel that resulted from a dial.

[Syntax]
HANGUPCAUSE(channel,type)

[Arguments]
channel
    The name of the channel for which to retrieve cause information.
type
    Parameter describing which type of information is requested. Types are:
    tech - Technology-specific cause information
    ast - Translated Asterisk cause code

[See Also]
HANGUPCAUSE_KEYS, HangupCauseClear()

Всё достаточно просто. Но есть нюанс, что каналы, которые участвовали в соединении, могут не иметь коды отбоев.
Поэтому в Asterisk есть специальная функция HANGUPCAUSE_KEYS, которая содержим имена каналов, содержащие коды отбоя:

 
*CLI> core show function HANGUPCAUSE_KEYS

  -= Info about function 'HANGUPCAUSE_KEYS' =-

[Synopsis]
Gets the list of channels for which hangup causes are available.

[Description]
Returns a comma-separated list of channel names to be used with the HANGUPCAUSE
function.

[Syntax]
HANGUPCAUSE_KEYS()

[Arguments]
Not available

[See Also]
HANGUPCAUSE, HangupCauseClear()

Всё вместе это выглядит так:

 

h => {

if ($[${LEN(${HANGUPCAUSE_STRING})} = 0])
 goto stop;

NoOp(SIP cause:  ${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},tech)});
NoOp(Ast cause:  ${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},ast)});
NoOp(Hangupcause keys: ${HANGUPCAUSE_KEYS()});
Set(CDR(userfield)=${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},tech)} | ${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},ast)} |  ${HANGUPCAUSE_KEYS()});

stop:
 NoOp(HANGUPCAUSE is empty);
};

В дайлплане удачный звонок на номер 5500:

 
    -- Channel SIP/CCM61-WC-00006071 left 'simple_bridge' basic-bridge <5e218c7f-08e4-402b-a201-9fe95e43645c>
    -- Channel SIP/AST-CC-ERT-2-00006070 left 'simple_bridge' basic-bridge <5e218c7f-08e4-402b-a201-9fe95e43645c>
  == Spawn extension (ERT-IN, 5500, 6) exited non-zero on 'SIP/AST-CC-ERT-2-00006070'
    -- Executing [h@ERT-IN:1] NoOp("SIP/AST-CC-ERT-2-00006070", "SIP cause:  SIP 200 OK") in new stack
    -- Executing [h@ERT-IN:2] NoOp("SIP/AST-CC-ERT-2-00006070", "Ast cause:  Normal Clearing") in new stack
    -- Executing [h@ERT-IN:3] NoOp("SIP/AST-CC-ERT-2-00006070", "Hangupcause keys: SIP/CCM61-WC-00006071") in new stack
    -- Executing [h@ERT-IN:4] Set("SIP/AST-CC-ERT-2-00006070", "CDR(userfield)=SIP 200 OK | Normal Clearing | SIP/CCM61-WC-00006071") in new stack

То есть в бридже у нас были каналы SIP/CCM61-WC-00006071 и SIP/AST-CC-ERT-2-00006070, первым брижд покинул Channel SIP/CCM61-WC-00006071, то есть он является инициатором отбоя, но в переменной HANGUPCAUSE_KEYS() содержится только код отбоя второго канала SIP/AST-CC-ERT-2-00006070.

Теперь, посмотрим что содержит сама переменная:

Translated Asterisk cause code: Normal Clearing
Translated Asterisk cause code: SIP 200 OK

Если вызов состоялся, а переменная пустая, то значит ни один канал не содержал кода отбоя.

Возьмём звонок на сервис, то есть по сути с одним плечом SIP, в таком случае переменная HANGUPCAUSE_KEYS() будет пустая:

[Jan 22 18:17:15] WARNING[13817][C-0000306d]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel
    -- Executing [h@WC-IN:1] NoOp("SIP/CCM61-WC-0000608c", "SIP cause:  ") in new stack
[Jan 22 18:17:15] WARNING[13817][C-0000306d]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel
    -- Executing [h@WC-IN:2] NoOp("SIP/CCM61-WC-0000608c", "Ast cause:  ") in new stack
    -- Executing [h@WC-IN:3] NoOp("SIP/CCM61-WC-0000608c", "Hangup keys: ") in new stack
[Jan 22 18:17:15] WARNING[13817][C-0000306d]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel
[Jan 22 18:17:15] WARNING[13817][C-0000306d]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel
    -- Executing [h@WC-IN:4] Set("SIP/CCM61-WC-0000608c", "CDR(userfield)= |  |  ") in new stack

Вызов который завершился неудачей:

  -- Got SIP response 503 "Service Unavailable" back from 10.101.1.7:5060
    -- SIP/ASTERISK-ERT-1-00006090 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing [22000@WC-IN:7] NoOp("SIP/CCM61-WC-0000608f", "CONGESTION") in new stack
    -- Executing [22000@WC-IN:8] Goto("SIP/CCM61-WC-0000608f", "sw_378_CONGESTION,10") in new stack
    -- Goto (WC-IN,sw_378_CONGESTION,10)
    -- Executing [sw_378_CONGESTION@WC-IN:10] Hangup("SIP/CCM61-WC-0000608f", "") in new stack
  == Spawn extension (WC-IN, sw_378_CONGESTION, 10) exited non-zero on 'SIP/CCM61-WC-0000608f'
    -- Executing [h@WC-IN:1] NoOp("SIP/CCM61-WC-0000608f", "SIP cause:  SIP 503 Service Unavailable") in new stack
    -- Executing [h@WC-IN:2] NoOp("SIP/CCM61-WC-0000608f", "Ast cause:  Circuit/channel congestion") in new stack
    -- Executing [h@WC-IN:3] NoOp("SIP/CCM61-WC-0000608f", "Hangup keys: SIP/ASTERISK-ERT-1-00006090") in new stack
    -- Executing [h@WC-IN:4] Set("SIP/CCM61-WC-0000608f", "CDR(userfield)=SIP 503 Service Unavailable | Circuit/channel congestion | SIP/ASTERISK-ERT-1-00006090 ") in new stack

Посмотрим что содержит сама переменная:

Hangup keys: SIP/ASTERISK-ERT-1-00006090
Translated Asterisk cause code: Circuit/channel congestion
Translated Asterisk cause code: SIP 503 Service Unavailable

Я заметил, что если lastapp в CDR != Hangup, а Dial, то поля в CDR которые я пытаюсь обновить CDR(userfield|dialstatus) не обновляются, вот пример с одним uniqueid и две записи:

mysql> select * from  cdr where uniqueid=1548253072.2783;
+-----+---------------------+----------------------------+--------+-------------+----------+-----------------------+-----------------------------+---------+------------------------------+----------+---------+-------------+----------+-------------+-----------------+------------+--------------------------------------------------------------+
| id  | calldate            | clid                       | src    | dst         | dcontext | channel               | dstchannel                  | lastapp | lastdata                     | duration | billsec | disposition | amaflags | accountcode | uniqueid        | dialstatus | userfield                                                    |
+-----+---------------------+----------------------------+--------+-------------+----------+-----------------------+-----------------------------+---------+------------------------------+----------+---------+-------------+----------+-------------+-----------------+------------+--------------------------------------------------------------+
| 986 | 2019-01-23 17:17:52 | "Kudr Ignat" <015166> | 015166 | 12345       | WC-IN    | SIP/CCM61-WC-00000706 | SIP/ASTERISK-ERT-1-00000707 | Dial    | SIP/ASTERISK-ERT-1/12345,,tT |        4 |       0 | BUSY        |        3 |             | 1548253072.2783 |            |                                                              |
| 987 | 2019-01-23 17:17:56 | "Kudr Ignat" <015166> | 015166 | sw_525_BUSY | WC-IN    | SIP/CCM61-WC-00000706 |                             | Hangup  |                              |        0 |       0 | BUSY        |        3 |             | 1548253072.2783 |            | SIP 486 Busy Here | User busy |  SIP/ASTERISK-ERT-1-00000707 |
+-----+---------------------+----------------------------+--------+-------------+----------+-----------------------+-----------------------------+---------+------------------------------+----------+---------+-------------+----------+-------------+-----------------+------------+--------------------------------------------------------------+
2 rows in set (0.01 sec)

Это связано с тем, что вызов хоть и попал на h, но CDR не записался на диск.
Who Hung Up? Asterisk Wiki

По ссылке описывается более сложный пример, в нём мы разбираем пременную HANGUPCAUSE_KEYS(), ведь он в теории может содержать больше имени одного канала, и тогда в моём примере попросту будет ошибка. Но у меня было максимум 1 переменная.

Приведу пример ниже:

[foo]
exten => s,1,Dial(SIP/bar)
 
exten => h,1,noop()
exten => h,n,set(HANGUPCAUSE_STRING=${HANGUPCAUSE_KEYS()})
; start loop
exten => h,n(hu_begin),noop()
 
; check exit condition (no more array to check)
exten => h,n,gotoif($[${LEN(${HANGUPCAUSE_STRING})} = 0]?hu_exit)
 
; pull the next item
exten => h,n,set(ARRAY(item)=${HANGUPCAUSE_STRING})
exten => h,n,set(HANGUPCAUSE_STRING=${HANGUPCAUSE_STRING:${LEN(${item})}})
 
; display the channel ID and cause code
exten => h,n,noop(got channel ID ${item} with pvt cause ${HANGUPCAUSE(${item},tech)})
 
; check exit condition (no more array to check)
exten => h,n,gotoif($[${LEN(${HANGUPCAUSE_STRING})} = 0]?hu_exit)
 
; we still have entries to process, so strip the leading comma
exten => h,n,set(HANGUPCAUSE_STRING=${HANGUPCAUSE_STRING:1})
; go back to the beginning of the loop
exten => h,n,goto(hu_begin)
exten => h,n(hu_exit),noop(All HANGUPCAUSE entries processed)

Можно создать свою таблицу CDR или содержащую иную информацию по вкусу и записывать в БД.
В примере ниже, по результатам вызова, в таблицу Mysql c именем cdr_custom записываются нужные переменные CDR плюс коды отбоя, ниже приводится подробный пример.

Предпологается? что мы будем использовать ранее созданное MySQL ODBC соединение.
Все поля, кроме dialstatus и REL будем брать из функции CDR().

Переменная REL формируется из функции HANGUPCAUSE:

Set(REL=${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},tech)} | ${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},ast)} |  ${HANGUPCAUSE_KEYS()});

Переменная ${DIALSTATUS} также стандартная переменная.

${DIALSTATUS}: This is the status of the call
    CHANUNAVAIL
    CONGESTION
    NOANSWER
    BUSY
    ANSWER
    CANCEL
    DONTCALL: For the Privacy and Screening Modes. Will be set if the called
    party chooses to send the calling party to the 'Go Away' script.
    TORTURE: For the Privacy and Screening Modes. Will be set if the called
    party chooses to send the calling party to the 'torture' script.
    INVALIDARGS

Ниже строка дайлплана Asterisk:

NoOp(${CDR(uniqueid)},${CDR(start)},${CDR(clid)},${CDR(src)},${CDR(dst)},${CDR(dcontext)},${CDR(channel)},${CDR(dstchannel)},${CDR(duration)},${CDR(billsec)},${CDR(disposition)},${DIALSTATUS},${REL})

В консоли Asterisk строка выше с подставленными переменными будет выглядеть так:

1548251202.2649,2019-01-23 16:46:42,"79210001122" <79210001122>,79210001122,600,WC-IN,SIP/CCM61-WC-000006aa,SIP/AST-CC-ERT-1-000006ab,409,409,ANSWERED,ANSWER,SIP 200 OK | Normal Clearing

Теперь все эти переменные нужно записать подготовленную для этих целей таблицу MySQL при помощи функции ODBC которая будет вызаться из дайлплана на экстеншене h.

Создадим новую таблицу cdr_custom в БД MySQL

 
mysql> use ertx_ast_cdr;
mysql> CREATE TABLE cdr_custom ( 
        id int(11) unsigned NOT NULL auto_increment PRIMARY KEY,
        uniqueid varchar(32) NOT NULL default '', 
        calldate datetime NOT NULL default '0000-00-00 00:00:00', 
        clid varchar(80) NOT NULL default '', 
        src varchar(80) NOT NULL default '', 
        dst varchar(80) NOT NULL default '', 
        dcontext varchar(80) NOT NULL default '', 
        channel varchar(80) NOT NULL default '', 
        dstchannel varchar(80) NOT NULL default '', 
        duration int(11) NOT NULL default '0', 
        billsec int(11) NOT NULL default '0', 
        disposition varchar(45) NOT NULL default '', 
        dialstatus varchar(17) NOT NULL default '' ,cause varchar(120) NOT NULL default '' );

mysql> desc cdr_custom;
+-------------+------------------+------+-----+---------------------+----------------+
| Field       | Type             | Null | Key | Default             | Extra          |
+-------------+------------------+------+-----+---------------------+----------------+
| id          | int(11) unsigned | NO   | PRI | NULL                | auto_increment |
| uniqueid    | varchar(32)      | NO   |     |                     |                |
| calldate    | datetime         | NO   |     | 0000-00-00 00:00:00 |                |
| clid        | varchar(80)      | NO   |     |                     |                |
| src         | varchar(80)      | NO   |     |                     |                |
| dst         | varchar(80)      | NO   |     |                     |                |
| dcontext    | varchar(80)      | NO   |     |                     |                |
| channel     | varchar(80)      | NO   |     |                     |                |
| dstchannel  | varchar(80)      | NO   |     |                     |                |
| duration    | int(11)          | NO   |     | 0                   |                |
| billsec     | int(11)          | NO   |     | 0                   |                |
| disposition | varchar(45)      | NO   |     |                     |                |
| dialstatus  | varchar(17)      | NO   |     |                     |                |
| cause       | varchar(120)     | NO   |     |                     |                |
+-------------+------------------+------+-----+---------------------+----------------+
14 rows in set (0.00 sec)

Теперь создадим функцию в /etc/asterisk/func_odbc.conf

[INSERT_CUSTOM_CDR]
dsn=asterisk
writesql=INSERT INTO cdr_custom (uniqueid,calldate,clid,src,dst,dcontext,channel,dstchannel,duration,billsec,disposition,dialstatus,cause) VALUES ('${ARG1}','${ARG2}','${ARG3}','${ARG4}','${ARG5}','${ARG6}','${ARG7}','${ARG8}','${ARG9}','${ARG10}','${ARG11}','${ARG12}','${ARG13}')

Настала очередь dialplan.

Ловим вызова на специальном экстеншене h куда попадает вызов после заверешния:

>h => {
Set(REL=${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},tech)} | ${HANGUPCAUSE(${HANGUPCAUSE_KEYS()},ast)} |  ${HANGUPCAUSE_KEYS()});
Set(ODBC_INSERT_CUSTOM_CDR(${CDR(uniqueid)},${CDR(start)},${CDR(clid)},${CDR(src)},${CDR(dst)},${CDR(dcontext)},${CDR(channel)},${CDR(dstchannel)},${CDR(duration)},${CDR(billsec)},${CDR(disposition)},${DIALSTATUS},${REL})=);

{

Причём обращаю внимание, что для записи значений из dialplan в ODBC нужно использовать SET!!!

Если в дайлплане используется case

Тогда в CDR в столбце dst может быть вместо Б-номера может быть значение sw_564_CHANUNAVAIL или что-то похожее вместо Б-номера:

mysql> select * from ertx_ast_cdr.cdr_custom where src in ('49000','015136') and calldate >= '2019-03-06 09:00:00';
+-------+------------------+---------------------+---------------------------+--------+--------------------+----------+-----------------------+-----------------------------+----------+---------+-------------+------------+------------------------------------------------------------------+
| id    | uniqueid         | calldate            | clid                      | src    | dst                | dcontext | channel               | dstchannel                  | duration | billsec | disposition | dialstatus | cause                                                            |
+-------+------------------+---------------------+---------------------------+--------+--------------------+----------+-----------------------+-----------------------------+----------+---------+-------------+------------+------------------------------------------------------------------+
| 27633 | 1551942737.86893 | 2019-03-07 10:12:17 | Kudryavcev Ignat <015136> | 015136 | 450000              | WC-IN    | SIP/CCM61-WC-0000de97 | SIP/ASTERISK-ERT-1-0000de98 |        2 |       0 | NO ANSWER   | CANCEL     | SIP 180 Ringing | Normal Clearing |  SIP/ASTERISK-ERT-1-0000de98 |
| 27634 | 1551942783.86900 | 2019-03-07 10:13:03 | Kudryavcev Ignat <015136> | 015136 | sw_564_CHANUNAVAIL | WC-IN    | SIP/CCM61-WC-0000de9d |                             |        0 |       0 | CONGESTION  | CONGESTION |  |  |  SIP/ASTERISK-ERT-2-0000de9f                               |
| 27635 | 1551942795.86906 | 2019-03-07 10:13:15 | Kudryavcev Ignat <015136> | 015136 | 450000              | WC-IN    | SIP/CCM61-WC-0000dea0 | SIP/ASTERISK-ERT-1-0000dea1 |        2 |       0 | NO ANSWER   | CANCEL     | SIP 180 Ringing | Normal Clearing |  SIP/ASTERISK-ERT-1-0000dea1 |
| 27636 | 1551942821.86912 | 2019-03-07 10:13:41 | Kudryavcev Ignat <015136> | 015136 | sw_577_BUSY        | WC-IN    | SIP/CCM61-WC-0000dea5 |                             |        0 |       0 | BUSY        | BUSY       | SIP 486 Busy here | User busy |  SIP/ASTERISK-ERT-1-0000dea6     |

Ниже пример Dialplan в котором может возникнуть такая ситуация:

 
_[56]XX => {
            NoOp(Call from Westcall);
            //Set(CALLERID(num)=01${CALLERID(num)});
            Set(CALLERID(num)=${IF($[${LEN(${CALLERID(num)})} = 4]?01${CALLERID(num)}:${CALLERID(num)})});
            Verbose(!!! DEBUG Call from Westcall to ERTEL from ${CALLERID(num)} ${CALLERID(name)} --called-number-> ${EXTEN} !!!);
            Verbose(!!! ${CALLERID(all)} !!!);
            Set(_REAL_DST=${EXTEN});
            Dial(SIP/${EXTEN}@AST-CC-ERT-1,,tT);
            //Dial(SIP/5136@10.10.10.10);
            NoOp(${DIALSTATUS});
            switch(${DIALSTATUS}) {
        case BUSY:
                  Hangup;
        case ANSWER:
                  Hangup;
        case NOANSWER:
                  Hangup;
        case CONGESTION:
                  Hangup;
        default:
                  Dial(SIP/${EXTEN}@AST-CC-ERT-2,,tT);
                  Hangup;

В данном примере, мы пытаемся перемаршрутизировать вызов на резервный сервер в зависимости от ответа основного.
Поэтому сохраним набранный номер в переменную Set(_REAL_DST=${EXTEN});

Затем при сохранении CDR заменим сохранение dst как ${CDR(dst)} на ${REAL_DST}

На Asterisk перезагрузить func_odbc.so и dailplan(dialplan reload/ael reload)

 
voip-gate-aster*CLI> module reload func_odbc.so
Module 'func_odbc.so' reloaded successfully.
    -- Reloading module 'func_odbc.so' (ODBC lookups)
  == Parsing '/etc/asterisk/func_odbc.conf': Found
  == Unregistered custom function ODBC_PRESENCE
  == Unregistered custom function ODBC_ANTIGF
  == Unregistered custom function ODBC_SQL
  == Registered custom function 'ODBC_SQL'
  == Registered custom function 'ODBC_ANTIGF'
  == Registered custom function 'ODBC_PRESENCE'
  == Registered custom function 'ODBC_INSERT_CUSTOM_CDR'
  
  voip-gate-aster*CLI> odbc write ODBC_
ODBC_ANTIGF      ODBC_PRESENCE    ODBC_INSERT_CUSTOM_CDR  ODBC_SQL

Запустим в dialplan:

 -- Executing [h@WC-IN:1] Set("SIP/CCM61-WC-000006fa", "REL=SIP 200 OK | Normal Clearing |  SIP/ASTERISK-ERT-1-000006fb") in new stack
    -- Executing [h@WC-IN:2] Set("SIP/CCM61-WC-000006fa", "ODBC_INSERT_CUSTOM_CDR(1548252647.2763,2019-01-23 17:10:47,"" <015139>,015139,450000,WC-IN,SIP/CCM61-WC-000006fa,SIP/ASTERISK-ERT-1-000006fb,1,1,ANSWERED,ANSWER,SIP 200 OK | Normal Clearing |  SIP/ASTERISK-ERT-1-000006fb)=") in new stack

В таблице CDR:

mysql> select * from  cdr_custom  order by id desc limit 2;
+-----+-----------------+---------------------+---------------------------+-------------+-------+----------+---------------------------+-----------------------------+----------+---------+-------------+------------+-------------------------------------------------------------+
| id  | uniqueid        | calldate            | clid                      | src         | dst   | dcontext | channel                   | dstchannel                  | duration | billsec | disposition | dialstatus | cause                                                       |
+-----+-----------------+---------------------+---------------------------+-------------+-------+----------+---------------------------+-----------------------------+----------+---------+-------------+------------+-------------------------------------------------------------+
| 230 | 1548253896.2820 | 2019-01-23 17:31:36 | Kudr Ignat <015040>   | 015040      | 450000 | WC-IN    | SIP/CCM61-WC-0000071c     | SIP/ASTERISK-ERT-1-0000071d |       56 |      36 | ANSWERED    | ANSWER     | SIP 200 OK | Normal Clearing |  SIP/ASTERISK-ERT-1-0000071d |
| 229 | 1548253402.2799 | 2019-01-23 17:23:22 | 79053332211 <79053332211> | 79053332211 | 5500  | ERT-IN   | SIP/AST-CC-ERT-2-0000070e | SIP/CCM61-WC-0000070f       |      348 |     348 | ANSWERED    | ANSWER     | SIP 200 OK | Normal Clearing |  SIP/CCM61-WC-0000070f       |
+-----+-----------------+---------------------+---------------------------+-------------+-------+----------+---------------------------+-----------------------------+----------+---------+-------------+------------+-------------------------------------------------------------+
2 rows in set (0.00 sec)


Как в Asterisk узнать какая из сторон была инициатором отбоя?

Пример дайлплана:


exten => _1XX,1,Set(HANGUPSIDE=originator)
exten => _1XX,2,Dial(SIP/${EXTEN},,g)
exten => _1XX,3,Set(HANGUPSIDE=terminator)
exten => _1XX,4,NoOp(${HANGUPSIDE})
exten => h,1,NoOp(${HANGUPSIDE})

В первом шаге, мы устанавливам что по умолчания в переменной HANGUPSIDE оригинатор завершит вызов.
На втором шаге мы отправляем вызов терминатору, но указываем, в приложении Dial опцию g.
Что такое опция g описано в Help Asterisk:

    g: Proceed with dialplan execution at the next priority in the current
    extension if the destination channel hangs up.

Без опций, приложение Dial, после отбоя любой из сторон передаёт вызов сразу же на экстеншен h текущего контекста, выполнение следующего шага дайлплана не происходит.
Если поставить опцию g, то следующий шаг дайлплана после Dial будет выполняться если терминирующий канал первым завершил вызов, в данном случае установка переменной HANGUPSIDE равной terminator.
Таким образом легко установить какая из причин является инициатором завершение, что иногда может очень сильно помочь в диагностике проблем.

Автор: Игнат Кудрявцев

Сравниваем конфигурации Freeswitch и Asterisk для одной задачи

Игнат Кудрявцев — Wed, 27 Feb 2019 06:45:56 +0000

Для чемпионата мира в России, который прошёл в 2018 году, нужно было решить задачу авторизации пользователей для услуги Wi-Fi при помощи звонка на телефонный номер как один из способов авторизации. Для решения использованы аналогичные конфигурации Freeswtich и Asterisk.

Смысл в том, что пользователь вводит номер телефона своего смартфона\планшета\компьютера через веб-форму авторизации в Wi-Fi сети, далее, пользователь выбирает каким способом он подтвердит, что это действительно его мобильный номер: при помощи отправки SMS-сообщения или звонком на номер телефона, где ему должна проиграться голосовая подсказка о успешности\неуспешности авторизации, в зависимости от языка интерфейса(русский, английский, французский, немецкий или испанский). Голосовая платформа Asterisk\Freeswith передаёт номер позвонившего серверу авторизации, сервер сверяет телефонный номер полученный через веб-форму с номером, который передала голосовая платформа, в ответ возвращается успешный или неуспешный код. Сообщение должно проигрываться в предответном состоянии до начала тарификации, чтобы абонент не платил деньги за звонок. Так как Asterisk и Freeswitch в этой схеме выполняют функции медиасерверов, будем называть далее их именно так.
Терминация из телефонных сетей на медасерверы работала через два транковых шлюза Eltex SMG1016M, голосовых платформ тоже две: первая Asterisk 15.3.0 установленный на ОС Linux Debian 9.4, вторая FreeSWITCH Version 1.6.20 установленная на ОС Linux Debian 8.10. В июне 2018 FreeSWITCH ещё не поддерживал ОС Linux Debian 9 для «продакшен» режима.
Asterisk и Freeswitch запущены на виртуальных машинах, основные пики нагрузки приходились, когда начинались футбольные матчи.
Главный минус схемы с такой авторизацией – иногда из телефонной сети общего пользования может приходить искажённый номер вызывающего абонента(А-номер), в таком случае пользователь не будет авторизован, хотя правильно указал свои данные. Данная ситуация была замечена у одного сотового оператора для парных номеров: федеральный номер плюс местный городской номер в которых равны последние 7 цифр номера.

Техническая реализация

Создан пул телефонных номеров равный количеству языков – 5, звонки на любой из 5 телефонных номеров по очереди попадает на шлюзы SMG1016: 192.168.25.8 и 192.168.25.9, на каждом из шлюзов созданы транковые направления терминации состоящие из двух транковых групп, по одной на медиасервер (Asterisk и Freeswitch), алгоритм работы направлений для терминации: последовательно вперёд.

Транковое направление SMG

Заметку по маршрутизации на шлюзах Элекс SMG можно найти по данной ссылке.
Оба шлюза подключены к городской АТС, где также создана группа терминации с алгоритмом работы по очереди. Такая схема даёт равномерное распределение нагрузки по шлюзам и медиасерверам.
Когда медиасервер получает вызов, он делает запрос по http на сервер авторизации куда в фомате JSON передаёт номер телефонный позвонившего и телефонный номер для авторизации куда позвонил пользователь:

data={'user_phone': user_phone,'gw_phone': gw_phone}

В ответ сервер передаёт код ответа и результат в формате:

resultCode=1&resultMessage=accepted

Если,

resultCode = 1 – проиграть подсказку об успешно авторизации
Любой другой код – проиграть сообщение об ошибке

В статье я не буду касаться вопросов инсталляции Asterisk и Freeswtich, рассмотрю только необходимую конфигурации внешнего канала SIP и дайлплана, также скриптов которые делают запрос по http и возвращают результат.

Медиасервер Astersik

IP-адрес=192.168.25.32

Здесь из дайлплана при помощи AGI вызываем внешний скрипт, который сделает запрос на сервер и вернёт результат.

Настройка внешних каналов SIP для приёма трафика от шлюзов, файл /etc/asterisk/sip.conf

[FIFA-1]
type=peer
context=FIFA-IN
host=192.168.25.8 ;Шлюз 1 SMG1016M
insecure=port,invite
disallow=all
allow=ulaw
nat=no
canreinvite=no
use_q850_reason = yes


[FIFA-2]
type=peer
context=FIFA-IN
host=192.168.25.9 ;Шлюз 2 SMG1016M
insecure=port,invite
disallow=all
allow=ulaw
nat=no
canreinvite=no
use_q850_reason = yes

Здесь вызовы с любого из двух шлюзов отправляются в контекст FIFA-IN.
Дайплан Asterisk, файл /etc/asterisk/extensions.ael
Приведу только первые два номера, напомню, что всего языков подсказок 5 и номеров столько же, соответственно.

context FIFA-IN
{
78120002915 => {
        AGI(get-res.py,${CALLERID(num)},${EXTEN:1});
Set(CDR(userfield)=${ANSWER});
NoOp(RES => ${RES});
        switch (${RES}) {
                    case 1:
                    Progress();
                    Playback(/var/lib/asterisk/sounds/fifa/success_readyRUS1,noanswer);
                    Busy(10);
                    Hangup(16);
                  default:
                    Progress();
                    Playback(/var/lib/asterisk/sounds/fifa/Fail_RUS1,noanswer);
                    //Playback(/var/lib/asterisk/sounds/ru/agent-alreadyon,noanswer);
                    Busy(10);
                    Hangup(16);

                };
        };

78120002916 => {                                                                //English
        AGI(get-res.py,${CALLERID(num)},${EXTEN:1});
Set(CDR(userfield)=${ANSWER});
NoOp(RES => ${RES});
        switch (${RES}) {
                    case 1:
                    Progress();
                    Playback(/var/lib/asterisk/sounds/fifa/Success_readyEN1,noanswer);
                    Busy(10);
                    Hangup(16);
                  default:
                    Progress();
                    Playback(/var/lib/asterisk/sounds/fifa/Fail_EN1,noanswer);
                    //Playback(/var/lib/asterisk/sounds/ru/agent-alreadyon,noanswer);
                    Busy(10);
                    Hangup(16);

                };
        };


};

Любой вызов, пришедший со шлюзов 192.168.25.8 и 192.168.25.9 попадает в контекст FIFA-IN дайлплана Asterisk, здесь, в зависимости от одного из пяти набранных номеров, вызов попадает на нужный экстеншен, например, 78120002916, при помощи приложения AGI вызывается внешний скрипт из директории по умолчанию /var/lib/asterisk/agi-bin. Результат работы скрипта передаётся оператору выбора case, далее, приложение Progress() указывает Asterisk что не нужно посылать SIP 200OK, что равно соединению и началу тарификации, а проиграть голосовое сообщение в режиме предответа(early media) с помощью приложения Playback, затем послать сигнал занято — Busy(10) и повесить трубку Hangup. Аудиофайлы, которые нужно проиграть загружаются в /var/lib/asterisk/sounds/ru/.
Для контроля содержимого ответа в CDR Asterisk добавим содержимое переменой ANSWER при помощи приложения Set,
Set(CDR(userfield)=${ANSWER});
Далее, в примере CDR содержимое полученного значения переменной будет продемонстрировано.
Ниже два примера скрипта написанные на bash и Python3, скрипты передают номера и возвращают в дайлплан результат.
#cat /var/lib/asterisk/agi-bin/get-res.sh

#!/bin/bash

res=`curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d"user_phone=$1&amp;gw_phone=$2" http://wfff-loginpage:8008/ivr_auth| sed -n 's/^.*resultCode=\([^&amp;]*\).*$/\1/p' | sed "s/%20/ /g"`

echo $res
echo -e "SET VARIABLE RES $res";
sleep 0
exit 0

Здесь я использовал консольную утилиту curl для http запроса на сервер авторизации. Кстати, последняя строчка exit 0, иначе в консоли Asterisk будут появляться ошибки результаты работы AGI-скрипта.
Ниже аналогичный скрипт на языке Python3, который я использовал в «боевой» конфигурации.


#!/usr/bin/env python3

import requests
from sys import argv
user_phone,gw_phone = argv[1:]
answer = requests.post('http://wfff-loginpage:8008/ivr_auth',headers={'Content-Type': 'application/x-www-form-urlencoded'},data={'user_phone': user_phone,'gw_phone': gw_phone})
#res='resultCode=0&resultMessage=rejected'
answer=str(answer.content)
print("SET VARIABLE RES %s" % answer[13] +"\n"+"SET VARIABLE ANSWER %s" % answer)

Здесь я использовал отличный модуль для http запросов requests. На этом настройка Asterisk закончена.

В CDR вызовы будут выглядеть так:

"","+00000637658","sw_5_0","FIFA-IN",""""" <+00000637658>","SIP/FIFA-1-000034c0","","Busy","10","2018-07-15 18:54:34",,"2018-07-15 18:54:41",7,0,"BUSY","DOCUMENTATION","1531670074.27007","b'resultCode=0&amp;resultMessage=rejected'"

"","79060003159","sw_4_1","FIFA-IN",""""" <79060003159>","SIP/FIFA-2-000034c1","","Busy","10","2018-07-15 18:55:22",,"2018-07-15 18:55:31",8,0,"BUSY","DOCUMENTATION","1531670122.27010","b'resultCode=1&amp;resultMessage=accepted'"

По мониторингу Asterisk использую следующие основные параметры, ниже пример конфигурации для Zabbix файл /etc/zabbix/zabbix_agentd.conf в UserParameter:

### Option: UserParameter
#Текущие вызовы
UserParameter=asterisk.core.show.calls,/usr/bin/sudo /usr/sbin/asterisk -rx 'core show calls' | grep active| awk '{print $1}'
#Текущие каналы SIP
UserParameter=asterisk.sip.show.channels,/usr/bin/sudo /usr/sbin/asterisk -rx 'sip show channels' | grep "active SIP dialog" | awk '{print $1}'
#Обработанные звонки, накопительный счётчик
UserParameter=asterisk.sip.show.calls.processed,/usr/bin/sudo /usr/sbin/asterisk -rx 'core show calls' | grep processed | awk '{print $1}'

Медиасервер Freeswitch

IP-адрес=192.168.25.32
У Freeswitch есть встроенный модуль curl.
Нам надо добавить модуль mod_curl поэтому, при компиляции снимаем комментарий с требуемых модулей в
/usr/src/freeswitch/modules.conf

languages/mod_python
applications/mod_curl

Сохраняем. Запускаем конфигурацию сбоку и инсталляцию ещё раз:

./configure
make
make install

Теперь в конфигурационных файлах Freeswtich /usr/local/freeswitch/conf/autoload_configs/modules.conf.xml, удаляем комментарии:

Проверим что модуль есть:

#fs_cli
$fs_cli
freeswitch@FS1.6> module_exists mod_python
true
freeswitch@FS1.6> module_exists mod_curl
true

В файле можно /freeswitch/conf/autoload_configs/switch.conf.xml можно увеличить данные параметры:

Внешние каналы SIP, добавим новый профиль:

#touch /freeswitch/conf/sip_profiles/fifa.xml

Добавим в файл следующие строки:

Значение $${external_sip_port} это глобальный параметр, его значение указано в /freeswitch/conf/vars.xml, и выглядит так: external_sip_port=5080.

Запустим наш новый профиль:

freeswitch@wfff-media2> sofia profile fifa start
Reload XML [Success]
fifa started successfully

В консоли Linux, проверим, что IP и порт прослушивает Freeswitch:

root@wfff-media2:/freeswitch/conf/sip_profiles# netstat -anp | grep 5080
tcp        0      0 192.168.25.32:5080      0.0.0.0:*               LISTEN      5499/freeswitch
udp        0      0 192.168.25.32:5080      0.0.0.0:*                           5499/freeswitch

Теперь переходим к настройке дайлплана, файл /freeswitch/conf/dialplan/fifa.xml:

Затем перезагружаем дайлплан:

freeswitch@wfff-media2> reloadxml
+OK [Success]

2019-02-22 13:32:23.277861 [INFO] mod_enum.c:879 ENUM Reloaded
2019-02-22 13:32:23.277861 [INFO] switch_time.c:1423 Timezone reloaded 1750 definitions

Всё, на этом настройка закончена.

Что происходит в дайлплан?

В модуль SIP медиасервера Freeswitch (использует Sofia) приходит вызов, в соответствии с созданным sip профилем FIFA вызов направляется в контекст fifa для обработки.
Контекст fifa содержит единственный эктеншен с именем FIFA_NUM_POOL. В первое условие(condition) содержит правило

Поэтому туда попадает любой позвонивший пользователь. Начинается первая фаза ROUTING – формирования найденного по совпавшим в условиям списка действий(actions) TODO. Значение break в первом условии (condition) отсутствует, это равно break=”on-false”, то есть
не проверять следующее условие condition, если это условие ложно, но оно всегда в нашем случае истинно. Далее, проверяются остальные условия conditions которые содержат 5 номеров, соответствующих языку, на котором воспроизводятся голосовые подсказки, в примере я показываю только два номера 78120002915 и 78120002916. Когда условие по номеру позвонившего или destination_number совпадает с набранным пользователем номером, срабатывает директива break=»on-true», что значит прервать просмотр условий (condition)и запустить те условия, которые совпали. То есть первое и второе, одно из пяти. Причём условия как бы стекируются и связаны межу собой оператором И(AND).
Список на выполнение или TODO список действии(action) составлен, начинается фаза выполнения State EXECUTE.
Запускается первое приложение curl:

Мы отправляем сообщение POST в формате JSON номер звонящего и номер телефона на который позвонили, при этому удаляем первую цифру номера.
В ответ получаем ответ, наподобие

resultCode=1&amp;resultMessage=accepted

Приложение curl возвращает результа в стандартную переменную curl_response_data
Так как интересующее нас значение находится в 11 символе, извлечём её при помощи конструкции

и присвоим переменной result.
Здесь запускается приложение curl, которое проверяет телефонный номер и возвращает результат в переменную ${result}. Далее, выполняются действия из второго найденного условия, во-первых

означает что мы будем проигрывать сообщение в предответном состоянии, без начала тарификации.
Следующее действие:

Тут мы воспроизводим файл success_readyRUS1.wav, если значение переменной ${result}=1 или файл Fail_RUS1.wav в противном случае.
Сследующие действия:

Ждём 3000 миллисекунд и запускаем приложение «отбой» с кодом USER_BUSY или SIP 486.
Результат в CDR Freeswitch представлен ниже.
Если абонент авторизован:

"70002783772","70002783772","78120002915","fifa","2018-07-17 13:40:58","","2018-07-17 13:41:05","7","0","ORIGINATOR_CANCEL","c6337123-7a94-4ba2-96ee-17d00d2e460b","","","PCMA","PCMA","resultCode=1&amp;resultMessage=accepted"

Если абоненту отказано в авторизации:

"70002254963","70002254963","78120002918","fifa","2018-07-17 17:13:23","","2018-07-17 17:13:34","11","0","USER_BUSY","854529fc-62c6-479a-8c10-4c639fa624d9","","","PCMA","PCMA","resultCode=0&amp;resultMessage=rejected"

Как видно, в cdr отображается содержимое переменной ${curl_response_data}

Чтобы добавить её в CDR, нужно сделать следующее:

Открыть на редактирование файл /usr/local/freeswitch/conf/autoload_configs/cdr_csv.conf.xml, далее, смотрим какой используется темплейт для CDR:

Затем, в

Название диода(LED)	Off	Зелёный	Мигает жёлтым	Желтый
Standby/Active	Устройство выключено	RPS 2300 в активном режиме может резервировать электропитание от коммутатора	RPS 2300 в режиме выбора. Выбранный порт в режиме ожидания и не готов резервировать электропитание коммутатора	Модули электропитания не совместимы друг с другом, или RPS перегрелся или еще с ним что-то.

Цвет диода	Статус линии DC Output LED
Off	RPS не включен или ничего не подключено к DC Output коннектору(линии)
Зелёный	К RPS подключена к коммутатору и она готова к резервированию питания
Мигает зелёным	На на RPS переключился коммутатор и он получает с неё электропитание.
Мигает жёлтым	RPS в режиме Standby или в режиме ожидания.(есть питание на RPS но она не включена)
Жёлтый	RPS недоступна
Мигает жёлтым и зелёным	Когда вы нажимаете кнопку Select, диод DC output LEDs показывает статус каждого порта электропитания, когда вы выбираете нужный порт LED этого порта мигает зелёным и жёлтым.

Unified Communications Expert

Управление iptables при помощи CGI-скриптов

' RTU 4 FIREWALL EDITOR echo '

RTU 4 FIREWALL EDITOR

'Результат поиска: echo '

Получение кодов отбоя SIP и стороны завершившей вызов в Asterisk

Сравниваем конфигурации Freeswitch и Asterisk для одной задачи

Обзор Homer 5

Cisco RPS 2300 и замена БП Catalyst 3750

Обзор удачной реализации интерфейса виртуальной АТС (ВАТС)

Настройка IP-телефонов Cisco 79 серии для работы за NAT и отладка

Разграничение видов связи на Eltex SMG2016 и SMG1016M

Настройка уведомления о записи разговора для исходящих и входящих вызовов в Asterisk

Обзор Siemens C530A IP