Оперативная диагностика SIP в консоли Asterisk каналы PJSIP и CHAN_SIP

Как вы можете видеть выше, мы успешно перезагрузили asterisk и подключились к нему.

Диагностика SIP и оборудования связанного с ним:

Отладка SIP протокола в Asterisk:

И так, asterisk работает нормально. Однако предположим, что у нас наблюдаются какие-то неполадки на внутреннем номере 120, и мы хотим посмотреть, какие sip сообщения приходят от этого внутреннего номера и какие sip-сообщения он получает от нас в ответ. Для этого нужно выполнить следующие шаги:

1. Проверить, что IP адрес устройства не заблокирован fail2ban. Это можно сделать средствами iptables следующей командой: # iptables -L –n



Как видим выше, fail2ban пустой, переходим ко второму шагу.



2. Включить отладку sip для внутреннего номера 120 следующей командой: CLI> sip set debug peer 120
Эту же команду (и многие другие) можно выполнять, не входя в asterisks, и в нашем случае команда примет следующий вид: # asterisk –rx "sip set debug peer 120"



3. После чего, скорее всего, вы увидите примерно следующие сообщения:

Для того, чтоб снять дамп таким образом необходимо, чтоб asterisk был известен ip адрес конечного устройства пользователя т.е или пользователь должен быть зарегистрирован, либо ip адрес пользователя должен быть сконфигурирован в настройках пользователя.

Зная, какой ip адрес у пользователя, можно выполнить отладку немного иначе, а именно указать ip адрес пользователя: # sip set debug ip 192.168.1.1

Если требуется включить отладку всех sip сообщений, а не с какого-то определенного ip/peer, то команда выглядит следующим образом:

Однако учтите, что если через АТС в этот момент совершается много звонков, то и количество сообщений будет огромным.

Результаты можно проверить или в консоли asterisk или же в лог-файле.

Консоль удобна тем, что можно быстро посмотреть какие приходят и уходят сообщения, их расшифровку, но если в данный момент совершается много звонков (даже если в отладке учувствует только один ip), то выцепить нужную информацию будет сложно. В таком случае лучше смотреть в лог-файлах.

Лог-файл располагается по следующему маршруту«/var/log/asterisk/full». Здесь можно выполнить поиск по ip-адресу устройства, или, к примеру, по типу сообщения. Давайте проверим файл по ключевому слову «REGISTER»

Переходим в раздел хранящий логи

Для проверки лога набираем следующую команду: grep ‘REGISTER’ full

Если вы все сделали правильно, то вы получите нечто схожее тому, что вы можете видеть выше (если такие сообщения были). Однако лучше читать лог немного другим образом, с помощью дополнительной команды less. Чтоб отобразить весь лог на одной отдельной странице можно выполнить следующую команду # grep ‘REGISTER’ full | less

Вы могли заметить, что лог был немного «обрезан» в прошлых примерах. Использовать less рекомендуется хотя бы потому, что позволяет удобно просмотреть весь лог. Давайте нажмем стрелочку вправо.

Для того, чтоб выйти достаточно нажать на q. Этим функции не ограничиваются, к примеру, присутствует возможность поиска по тексту, для этого существуют следующие команды. Для поиска определенного текста вперед нужно набрать: /текст/ (к примеру , REGISTER )

а для того, чтоб искать по заданному тексту назад ?текст? (к примеру Request)

Сейчас эти команды не так полезны т.к размер лога не большой, но если логов много они могут сократить время поиска нужной строчки. Когда вы закончите экспериментировать, то чтоб вывести на экран справку по командам нужно набрать h.

А теперь, после всей работы не забывайте выключать отладку т.к высока вероятность того, что на жестком диске попросту закончится место.

# asterisk -rx "sip set debug off"

Мы рассмотрели здесь базовую отладку средствами самого asterisk. Возможно, вам будет интересно почитать об утилите sngrep, которая благодаря своему удобному интерфейсу и богатому функционалу может стать отличным инструментом для отладки и снятия дампа. Так же стоит ознакомиться с SIP-ответами и их значением которые будут приведены в конце статьи.

Отладка PJSIP протокола в Asterisk

Канальный драйвер chan_sip протокола SIP был создан давно, в 2002 году, это уже почти 16 лет назад. Тогда еще никто и не предполагал, что протокол SIP на рынке получить одну из лидирующих ролей, а так же получить множество расширений. Однако сейчас с каждым годом этому модулю сложнее идти в ногу с новыми технологиями и обновлениями.

Таким образом, был создан новый канальный драйвер для Asterisk – PJSIP.

PJSIP — мультимедийная коммуникационная библиотека, написанная на Си. Поддерживает такие протоколы как SIP, SDP, RTP, STUN, TURN, и ICE. Эта библиотека работает на различных платформах, начиная с хэндсетов и мобильных устройств и заканчивая высоконагруженными АТС. Начиная с asterisk 12, эта библиотека поддерживается частично и только с asterisk 13 появилась полноценная поддержка. Для осуществления звонков программной АТС Asterisk

Главное отличие этого нового канального драйвера в том, что он хорошо работает с различными брандмауэрами и NAT, как в составе Asterisk-сервера, так и на клиентских устройствах.

Тем не менее, несмотря на ряд преимуществ перед Chan_SIP, PJSIP все еще не получил широкого применения из-за отличия конфигурации. Новый стек использует подход разделения конфигурации на логические разделы, поэтому создаются разные разделы для различных целей.

В данной статье мы рассмотрим основные способы отладки PJSIP. В Asterisk версии 13.8.0 был добавлен новый модуль - res_pjsip_history, который обеспечивает сбор, фильтрацию и отображение SIP-сообщений в командной строке.

Для проверки, какая у вас версия asterisk достаточно выполнить команду #asterisk –rv и обратить внимание на выделенную область на скриншоте.

Как видим выше у нас версия старше, и это значит, что модуль включен по умолчанию.

Захват SIP-сообщений:

Для того чтоб начать захват нужно выполнить следующую команду:

CLI> pjsip set history on

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

CLI> pjsip set history off

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

CLI> pjsip set history clear

Просмотр:

И так, вы включили запись, прошло какое-то время, пользователи совершали звонки, подключали аппараты и.т.д и по итогам всего действия мы собрали какие-то данные, но как нам теперь их просмотреть?

Чтоб показать всю историю собранных сообщений нужно выполнить следующую команду: CLI> pjsip show history

Эта команда предоставит краткое изложение истории sip-сообщений.

Просмотреть подробнее какое-то конкретное SIP-сообщение, нужно указать в команде его номер. Команда примет следующий вид:

CLI> pjsip show history entry 6 ,где цифра обозначает номер строки

Пожалуйста, обратите внимание, что номера всех записей отображаются в левом столбце. Номера сообщений идут по порядку, и их номер увеличивается с каждым полученным или отправленным SIP-сообщением.

Манипуляции с результатами:

Выше мы получили подробную информацию о sip-сообщении. Тем не менее, в таком виде редко когда удобно просматривать сообщения, в особенности когда на станции зарегистрированы не два пользователя, а 10 и даже больше и все они в этот момент совершают звонки. Модуль res_pjsip_history поддерживает простую фильтрацию запросов по заданным условиям, подобную тому, который есть в SQL.

Для теста давайте отфильтруем запрос по SIP Call-ID, используя следующую команду:

CLI>pjsip show history where sip.msg.call-id = “ваш caller-id“

Результат выполнения команды вы можете видеть выше. Если вы знакомы или даже работали с программой «sngrep», то можете заметить сходства в отображении информации о входящих и исходящих пакетов.

На момент написания статьи модульres_pjsip_history поддерживает следующие команды:

• number : номер записи в истории
• timestamp : время отправка сообщения SIP
• addr : Адрес источника/Получателя SIP-сообщения
• sip.msg.request.method : Метод запроса SIP
• sip.msg.call—id : Значение заголовка

Так же Res_pjsip_history поддерживает все логические операторы, а так же операторы регулярных выражений.

Дебаг pjsip без использования Res_pjsip_history:

Сбор информации для дебага:

Как было упомянуто раньше – модульres_pjsip_history был включен в asterisk, только начиная с версии Asterisk 13.8.0, и в младших версиях он отсутствует. Как в таком случае проводить дебаг? Этому посвящен этот раздел.

И так, предположим, что наш asterisk младше указанных версий дебаг pjsip придется выполнять иначе. Какие нужно сделать шаги для отлавливания ошибок?

Для начала нужно включить запись логов следующей командой: > pjsip set logger on

Как можете видеть выше, эта команда похожа на аналогичную команду для sip, > sip set debug on/off. Как и в случае с дебагом для sip не забывайте после траблшутинга выключать логирование следящей командой: > pjsip set logger off

Обычно для отладки этого достаточно, но иногда (и в этой статье мы будем использовать в некоторых примерах, и такие строки помечаются как DEBUG) следует так же включить debug. Обычно этим пользуются разработчики во время тестирования программ и утилит, но и нам это может помочь в поисках проблем. Включить дебаг можно следующей командой: CLI> core set debug 4

И соответственно выключается следующей командой CLI> core set debug off

Как вы могли заметить выше мы можем задавать уровень логивания. Можно задать от 0 до 10 и чем выше, тем больше будет выводиться информации. Сообщения debug по умолчанию выводятся в файл /var/log/asterisk/messages.

Траблшутинг pjsip:

И так, логирование включено. Теперь можно приступать к траблшутингу. Т.К тут много схоже с отладкой chan_sip (те же sip ответы, о которых вы можете почитать в следующей главе) мы разберем некоторые другие ошибки, с которыми вы можете столкнуться.

Неизвестная конечная точка:

Если Asterisk не может определить куда отправить входящий звонок, то входящий вызов будет отклонен. Если вы видите в консоли следующее сообщение:

Или же

[2018-11-11 16:12:17.349] DEBUG[20937]: res_pjsip_endpoint_identifier_user.c:167username_identify: Could not identify endpoint by username 'ivanivanov'

Это признак того, что запрос отклоняется по причине того, что Asterisk не может определить, с какой конечной точки поступает входящий запрос.

И так, как asterisk вообще определяет, с какой конечной точки поступает запрос? Asterisk использует т.н. «endpoint identifiers» (идентификатор конечных точек). Существует три идентификатора:

User — предоставляется модулем res_pjsip_endpoint_identifier_user.so. Способ его использования заключается в использовании заголовка From из входящего sip. R К примеру:

Для исправления ошибки связанной с этим для начала введи команду > pjsip show endpoints.  

• Если конечная точка не отображается, то, вероятно возникла проблема с загрузкой при запуске.
• Так же следует проверить настройки. Возможно, вы допустили ошибку в конфигурации.

Ip — Asterisk также может распознавать конечные точки на основе исходного IP-адреса SIP-запроса. Ниже приведены некоторые шаги по исправлению возможных неполадок.

• Для начала убедитесь, что res_pjsip_endpoint_identifier_ip.so загружен и работает. Из CLI модель отображается как res_pjsip_endpoint_identifier_ip.so и команда примет следующий вид: CLI> module show like res_pjsip_endpoint_identifier_ip.so Результат должен выглядеть следующим образом:

• Для проверки идентификатора наберите следующую команду > pjsip show endpoint . Обратите внимание навыделенную область. В данном примере настройки иные, но если было все настроено, то строчка приняла бы вид Identify:192.168.1.5/32

• Так же убедитесь, что в вашей конфигурации нет конфликтов ip-адресов.

Anonymous – Использует специальную конечную точку «anonymous», если другие идентификаторы конечных точек не могут определить, с какой именно  конечной точки отправляется запрос. Ниже приведены некоторые шаги по исправлению возможных неполадок:

• Убедитесь, что res_pjsip_endpoint_identifier_anonymous.so загружен и работает. Из командной строки Asterisk модуль запуска отображается как res_pjsip_endpoint_identifier_anonymous.so и команда примет следующий вид: CLI> module show like res_pjsip_endpoint_identifier_anonymous. Результат должен выглядеть следующим образом:

• Проверьте, что «анонимная» конечная точка была правильно загружена. Для проверки наберите следующую команду > pjsip show endpoint и обратите внимание на строчку Users.

Ошибка регистрации:

Если вы видите следующие ошибки:

и

Или же

Значит, пароль не соответствует заданным настройкам на номере. Так же если пароль верен, но все равно в консоли вы видите ошибку типа «authentication is failing» и в дебаге сообщения типа:

То следует пройтись по ниже перечисленным шагам для исправления возможных неполадок:

• Убедитесь, что имя пользователя и пароль в разделе type=auth написаны правильно.
• Если вы используете опцию md5_cred в разделе auth, убедитесь, что:
  • Проверьте, что вы установили auth_type = md5.
  • Убедитесь, что рассчитанная сумма MD5 состоит из имени пользователя: realm: password
  • Убедитесь, что рассчитанная сумма MD5 не содержит посторонних пробелов.
  • Убедитесь, что не было ошибки во время копировани. Сумма MD5 составляет ровно 32 шестнадцатеричных символа. Если параметр в вашем файле конфигурации содержит меньше или превышает 32 символа, или если какой-либо из символов не является шестнадцатеричным символом, тогда сумма MD5 недействительна.
• Убедитесь, что конечная точка, которая взаимодействует с Asterisk, использует метод аутентификации «Digest» и алгоритм «md5». Если они используют что-то другое, Asterisk не поймет и не отклонит попытку аутентификации.

Asterisk не может найти указанное расширение:

Если вы видите в CLI сообщение, подобное приведенному ниже

то это означает, что Asterisk не смог направить входящий вызов на соответствующее расширение в диалплане. В приведенном выше случае я набрал «456789» на телефоне, который соответствует конечной точке131. Конечная точка 131 настроена с контекстом «from-internal», а этот контекст в моем диалплане не имеет расширения «49944».

• Убедитесь, что конечная точка настроена на ожидаемый контекст.
• Убедитесь, что набираемый номер существует в диалплане. Из CLI Asterisk запустите dialplan show <имя контекста>, чтобы увидеть расширения для определенного контекста. Если номер, который вы набираете, не указан, то Asterisk не знает о расширении и не сможет соединить с номером.
• Если если вы недавно вносили изменения в extensions.conf то убедитесь, что вы сохранили изменения и перезагрузили dialplan из CLI Asterisk.
• Убедитесь, что набираемый номер имеет 1 приоритет.
• Убедитесь, что набираемый номер находится в ожидаемом диалплан-контексте.

Полезные инструменты:

В данной статье мы рассмотрели дебаг с помощью встроенных функций asterisk. Как вы можете видеть, Asterisk даже без сторонних утилит способен помочь обнаружить и устранить неполадки. Тем не менее, все же рекомендуем при возможности использовать дополнительные утилиты, которые не только облегчат дебаг, но и помогут сократить время нужное для отлавливания проблемы благодаря богатому функционалу и удобному оформлению. Советуем ознакомиться со следующими инструментами для отладки телефонии и по возможности использовать их во время дебага

Установка и настройка Sngrep

Sngrep

Wireshark. Сохраняем дамп нужного разговора.

Перехват и прослушивание разговора в кодеках G722 и G729. Использование Wireshark