Одно из разрабатываемых нами решений — анализатор прогресса вызова iqAntibot. Развивая данное решения мы сталкиваемся с различными запросами и требованиями к интеграции с call-центрами. При тестировании у одного из клиентов потребовалось минимизировать получение вызовов операторами колл-сцентра, а также в случае если вызов отбит антиботом — не передавать ответ вызова на сервер колл-центра, инициализированвшего вызов и отклонить вызов с конкретным SIP ответом, который будет зафиксирован в статистике КЦ. При этом расширить логику и обработать заголовок Reason в BYE на стороне КЦ нельзя.
Читать далее«Реализация задержки ответа на вызов в Asterisk»Какие бывают статусы вызова?
В нашей работе мы часто сталкиваемся с вопросом клиентов, которые хотят получить достоверную статистику по статусам исходящих вызовов. Хотелось бы в небольшой статье пояснить что из себя представляют статусы в телефонии Asterisk и почему они слабо подходят для маркетинговых вызовов отдельно от других данных.
Какие бывают статусы?
Q.931 и SIP
Технические статусы, отображают причину отклонения вызова. Для Q.931 — цифровой, для SIP — код и текстовое описание. Ответы от разных операторов в одних и тех же ситуациях могут быть разными. К тому же если произошёл ответ на вызов, кода уже не будет, хотя ответ мог быть и не реальным.
Обе системы кодов имеют стандарт на преобразование между друг другом. Особеенностью является, что последовательные преобразования из SIP в q.931 и обратно могут привести к изменению кода завершения вызова. Для справки:
- Коды q.931: https://ru.wikipedia.org/wiki/Q.931
- Коды SIP: https://zen.yandex.ru/media/id/5b29cf6adf7d5600a8c5dc40/chto-takoe-sip-kody-kody-sip-oshibok-5b2be375b2fb7000a9f04a42
- Соответствие кодов: https://www.dialogic.com/webhelp/BorderNet2020/2.2.0/WebHelp/causecodemap.htm
${DIALSTATUS}
Asterisk внутренне фактически использует коды q.931 для обработки кодов завершения вызова, но чаще всего в статистике вы увидете значение переменной DIALSTATUS, которая обобщает эти коды по общему смыслу, основные это (мы пеерчислим ситуации в которых код появится, чтобы показать как это помешает в анализе):
- ANSWER — вызов был технически отвечен. Это ничего не говорит о доступности номера для вызова. Вызываемый номер может быть недоступен, занят. Оператор может произвести ответ при переводе вызова на голосовую почту (при этом как после тонового сигнала, так и перед приглашением оставить сообщение)
- NOANSWER — вызов не был отвечен. Означает только то что ваш Asterisk прервал вызов до того как он был отвечен или отклонён вызываемой стророной. При этом во время вызова могли звучать различные сообщения, проходить КПВ или вообще не быть никакой сигнализации о прогрессе вызова.
- BUSY — номер занят. Относительно понятно, но нужно учитывать что не во всех ситуациях когда номер занят вы получите этот код. Часть вызовов на занятые номера попадают на автоответчик и вторую линию и будут видны со статусом NOANSWER, часть — попадут на автоответчик и будут видны со статусом ANSWER
- CONGESTION — какой-либо другой код отклонения вызова, ез подробного понимания что произошло (номер отключён, недоступен, не существует и т.п.). Также этот статус подвержен тем же проблемам для понимания доступности номера как и статус BUSY.
- CHANUNAVAIL — ситуации когда вызываемый канал недоступен (в основном это проблемы с настройкой или недоступность обрудования оператора)
Слышимость ARI snoop в режиме whisper
В Asterisk интерфейсы ARI предоставляют набор примитивов, позволяющих реализовывать собственные приложения, задавая собственную гибкую логику.
Например мы можем сделать сложные «конференции», в которых выборочно ограничивать слышимость между участниками или добавляя индивидуальные оповещения её участникам. Сделать это можно используя ARI endpoint /snoop.
Читать далее«Слышимость ARI snoop в режиме whisper»Запись разговоров на RAM-диск во FreePBX
В интернете есть много статей, говорящих о том как сделать перекодирование записей разговоров в MP3, но не менее актуальным вопросом в нагруженной системе является экономия ресурсов при записи изначального wav файла.
Разумным выходом является запись файла на RAM диск и последующее перекодирование и сохранение записи на примонтированный внешний ресурс. Однако FreePBX используя штатные опции пишет и читает записи из одного и того же места.
Для того чтобы начать писать записи в отдельную папку, при том что читать FreePBX в CDR reports продолжит из той же папки /var/spool/asterisk/monitor достаточно поместить такое дополнение в extensions_custom.conf:
[globals](+)
MIXMON_DIR=/var/spool/asterisk/monitorRAM/
PS. Если перекодировать файлы записей, то лучше кодировать их в mp4, а не mp3. Так как mp4 штатно поддерживается в CDR Reports, а mp3 — нет.
PPS. Еще одной полезной опцией будет cache_record_files в asterisk.conf. Она позволяет писать файл во временную папку, а перемещать в постоянное только после завершения записи.
Задание нескольких proxy в chan_pjsip
В процессе разработки относительно сложных конфигураций нам потребовалось добавить свой промежуточный SIP proxy в систему, где транки с операторами уже используют Outbound Proxy.
Основная страница где говорится о работе с proxy из chan_pjsip не говорит нам ничего о такой конфигурации и показывает как задать один Proxy. Но на самом деле можно задать всю цепочку используемых Proxy прямо из конфигурации chan_pjsip.
Переменные sip протокола при переходе на pjsip
Продолжаю тему обновлений, которые требуются при переходе на канал chan_pjsip, отмечу еще два момента, возможно недостаточно отраженные в документации. По крайней мере нам при обновлении диалпланов наших систем пришлось немного поискать информацию.
- Что: переменная SIPCALLID
- Замена: вызов функции CHANNEL(pjsip,callid)
Положительным моментом является то, что данный вызов является более логичным и документация по нему доступна при просмотре помощи по функции CHANNEL. callid совершаемого вызова доступен до отправки INVITE в pre-dial процедуре, вызываемой приложением Dial()
- Что: приложение SipAddHeader()
- Замена: функция PJSIP_HEADER()
Предложенная для замены функция является более функциональной заменой, позволяет также читать, удалять и модифицировать заголовки. О применении и ограничениях — подробнее во встроенной справке Asterisk
Также хотелось отметить, что все такие заметки мы начинаем собирать о обобщать в нашей базе знаний — https://kb.iqtek.ru, надеемся она сможет стать полезным ресурсом наравне с другими зарекомендовавшими себя сайтами по теме Asterisk и VoIP.
Настройка транка с регистрацией в chan_pjsip и FreePBX
Наша компания уже в течении последнего года использует в настройке всех новых систем на Asterisk канал chan_pjsip для работы с SIP протоколом. Часто появляются вопросы, в которых пользователи спрашивают о том, как настроить ту или иную конфигурацию по аналогии с chan_sip.
Читать далее«Настройка транка с регистрацией в chan_pjsip и FreePBX»SQL из диалплана
По следам прошедшей конференции AsterConf’2017 мы решили опубликовать несколько простых советов, которые оказались полезными участникам конференции.
Первый относится к использованию SQL запросов в системах, которые построены при помощи написания диалплана без применения графических оболочек вроде FreePBX. Для работы c SQL из диалплана чаще всего используют возможности модуля func_odbc. Однако часто оказывается неудобным то, что для каждого запрос а требуется редактирование отдельного файла. Ниже описание того, как этого избежать и задавать все запросы в диалплане.
Что нового в Asterisk 15
Совсем скоро должна появиться релизная версия Asterisk 15. В новой версии Asterisk Digium провели массивное изменение ядра системы, что вызвало отхождение от принципов нумерации и выпуска LTS релизов. Таким образом:
- Asterisk 15 становится не-LTS релизом со сроком поддержки 2 года
- Поддержка Asterisk 13 продляется до 2021 года
Основными нововведениями при этом являются:
- Поддержка мульти-поточности в работе с RTP (в основном для WebRTC в chan_pjsip)
- Внедрение API для абстракции при работе с SDP
- Реализация спецификации BUDLE для передачи нескольких RTP потоков единым транспортом
Более подробный список изменений под катом.
Обновление openssl для webrtc
Браузеры идут вперед семимильными шагами, при этом складывается ситуация, когда обновление браузеров у клиента иногда требует обновления и инфраструктуры.
Мы с толкнулись с тем, что в нашей инфраструктуре не работают новые версии Chrome. Поиск по изменениям показал, что в в 52 версии Chrome перешли на использование только на использование ECDSA алгоритма при согласовании подключения DTLS. Но в версии openssl до 1.0.2 эти алгоритмы не поддерживаются. «Правильный» openssl на Ubuntu можно установить таким способом:
|
1 2 3 |
sudo add-apt-repository ppa:louisinternet/openssl sudo apt-get update apt install openssl |
Проверить версию после установки:
|
1 2 |
root@freeswitch3-in:/home/superadmin# openssl version OpenSSL 1.0.2g-fips 1 Mar 2016 |
После этого достаточно перезапустить freeswitch для работы с правильными версиями библиотеки openssl.