В нашей работе мы часто сталкиваемся с вопросом клиентов, которые хотят получить достоверную статистику по статусам исходящих вызовов. Хотелось бы в небольшой статье пояснить что из себя представляют статусы в теелфонии Asterisk и почему они слабо подходят для маркетинговых вывводов отдельно от других данных.
Какие бывают статусы?
Q.931 и SIP
Технические статусы, отображают причину отклонения вызова. Для Q.931 — цифровой, для SIP — код и текстовое описание. Ответы от разных операторов в одних и тех же ситуациях могут быть разными. К тому же если произошёл ответ на вызов, кода уже не будет, хотя ответ мог быть и не реальным.
Обе системы кодов имеют стандарт на преобразование между друг другом. Особеенностью является, что последовательные преобразования из SIP в q.931 и обратно могут привести к изменению кода завершения вызова. Для справки:
Asterisk внутренне фактически использует коды q.931 для обработки кодов завершения вызова, но чаще всего в статистике вы увидете значение переменной DIALSTATUS, которая обобщает эти коды по общему смыслу, основные это (мы пеерчислим ситуации в которых код появится, чтобы показать как это помешает в анализе):
ANSWER — вызов был технически отвечен. Это ничего не говорит о доступности номера для вызова. Вызываемый номер может быть недоступен, занят. Оператор может произвести ответ при переводе вызова на голосовую почту (при этом как после тонового сигнала, так и перед приглашением оставить сообщение)
NOANSWER — вызов не был отвечен. Означает только то что ваш Asterisk прервал вызов до того как он был отвечен или отклонён вызываемой стророной. При этом во время вызова могли звучать различные сообщения, проходить КПВ или вообще не быть никакой сигнализации о прогрессе вызова.
BUSY — номер занят. Относительно понятно, но нужно учитывать что не во всех ситуациях когда номер занят вы получите этот код. Часть вызовов на занятые номера попадают на автоответчик и вторую линию и будут видны со статусом NOANSWER, часть — попадут на автоответчик и будут видны со статусом ANSWER
CONGESTION — какой-либо другой код отклонения вызова, ез подробного понимания что произошло (номер отключён, недоступен, не существует и т.п.). Также этот статус подвержен тем же проблемам для понимания доступности номера как и статус BUSY.
CHANUNAVAIL — ситуации когда вызываемый канал недоступен (в основном это проблемы с настройкой или недоступность обрудования оператора)
В Asterisk интерфейсы ARI предоставляют набор примитивов, позволяющих реализовывать собственные приложения, задавая собственную гибкую логику.
Например мы можем сделать сложные «конференции», в которых выборочно ограничивать слышимость между участниками или добавляя индивидуальные оповещения её участникам. Сделать это можно используя ARI endpoint /snoop.
В интернете есть много статей, говорящих о том как сделать перекодирование записей разговоров в MP3, но не менее актуальным вопросом в нагруженной системе является экономия ресурсов при записи изначального wav файла.
Разумным выходом является запись файла на RAM диск и последующее перекодирование и сохранение записи на примонтированный внешний ресурс. Однако FreePBX используя штатные опции пишет и читает записи из одного и того же места.
Для того чтобы начать писать записи в отдельную папку, при том что читать FreePBX в CDR reports продолжит из той же папки /var/spool/asterisk/monitor достаточно поместить такое дополнение в extensions_custom.conf:
В процессе разработки относительно сложных конфигураций нам потребовалось добавить свой промежуточный SIP proxy в систему, где транки с операторами уже используют Outbound Proxy.
Основная страница где говорится о работе с proxy из chan_pjsip не говорит нам ничего о такой конфигурации и показывает как задать один Proxy. Но на самом деле можно задать всю цепочку используемых Proxy прямо из конфигурации chan_pjsip.
Продолжаю тему обновлений, которые требуются при переходе на канал chan_pjsip, отмечу еще два момента, возможно недостаточно отраженные в документации. По крайней мере нем при обновлении диалпланов наших систем пришлось немного поискать информацию.
Что: переменная SIPCALLID
Замена: вызов функции CHANNEL (pjsip,callid)
Положительным моментом является то, что данный вызов является более логичным и документация по нему доступна при просмотре помощи по функции CHANNEL. callid совершаемого вызова доступен до отправки INVITE в pre-dial процедуре, вызываемой приложением Dial ()
Что: приложение SipAddHeader ()
Замена: функция PJSIP_HEADER ()
Предложенная для замены функция является более функциональной заменой, позволяет также читать, удалять и модифицировать заголовки. О применении и ограничениях — подробнее во встроенной справке Asterisk
Также хотелось отметить, что все такие заметки мы начинаем собирать о обобщать в нашей базе знаний — https://kb.iqtek.ru, надеемся она сможет стать полезным ресурсом наравне с другими зарекомендовавшими себя сайтами по теме Asterisk и VoIP.
Наша компания уже в течении последнего года использует в настройке всех новых систем на Asterisk канал chan_pjsip для работы с SIP протоколом. Часто появляются вопросы, в которых пользователи спрашивают о том, как настроить ту или иную конфигурацию по аналогии с chan_sip.
В этом году мне удалось принять участие в community-конференции Astricon компании Digium (ныне часть Sangoma), посвященную развитию проекта Asterisk. Данная конференция собирает представляет community со всего мира и позволяет познакомиться с актуальными вопросами, с которыми сталкиваются разработчики VoIP систем.
Хотелось бы рассказать о полученном опыте в плане получения визы, дороги, выбора маршрутов, стоимости и просто присутствия на конференции. Возможно кому-то эта информация будет полезна в будущем для поездки на Astricon или какую-либо другую конференцию в США.
Для начала хочу выразить благодарность семье, которая мужественно вынесла мое отсутствие в течении почти двух недель. Также хочу заметить, что в ссылках на сервисы далее по тексту могут быть использованы промо-ссылки. Если используете и это будет реально полезно — буду только рад. В комментариях задавайте вопросы, буду рад что-то подсказать. Далее »
По следам прошедшей конференции AsterConf’2017 мы решили опубликовать несколько простых советов, которые оказались полезными участникам конференции.
Первый относится к использованию SQL запросов в системах, которые построены при помощи написания диалплана без применения графических оболочек вроде FreePBX. Для работы c SQL из диалплана чаще всего используют возможности модуля func_odbc. Однако часто оказывается неудобным то, что для каждого запрос а требуется редактирование отдельного файла. Ниже описание того, как этого избежать и задавать все запросы в диалплане.
Совсем скоро должна появиться релизная версия Asterisk 15. В новой версии Asterisk Digium провели массивное изменение ядра системы, что вызвало отхождение от принципов нумерации и выпуска LTS релизов. Таким образом:
Asterisk 15 становится не-LTS релизом со сроком поддержки 2 года
Поддержка Asterisk 13 продляется до 2021 года
Основными нововведениями при этом являются:
Поддержка мульти-поточности в работе с RTP (в основном для WebRTC в chan_pjsip)
Внедрение API для абстракции при работе с SDP
Реализация спецификации BUDLE для передачи нескольких RTP потоков единым транспортом
В этом году мне удалось принять участие в community-конференции 