В период работы с астериском рано или поздно задумываешься о том, почему не получается прозвониться и обычное чтение лога не помогает. На помощь приходит снятый дамп. В этой статье рассмотрим разные дампы SIP сообщений и постараемся разобрать на примерах причины неисправностей, а также найти виновника найденной неполадки.

Структура SIP

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

Категории запросов:

1. Одинарные методы — методы на которые требуется единичный ответ, без дополнительных запросов.
2. Диалоговые методы — методы, которые сопровождаются многочисленными ответными сообщениями и поддерживают диалоговые соединения.

В одинарные запросы входят пакеты со следующими методами:

• OPTIONS – метод позволяющий определить доступность того или иного VOIP устройства подключенного в АТС. Запрос о функциональных возможностях АТС.
• SUBSCRIBE – метод позволяющий получать информацию о статусах в пределах всего сеанса подключения
• PUBLISH — публикация события на сервере.
• INFO – передача какой либо информации, которая не меняет состояние сессии
• NOTIFY – уведомление о событии для пользователя, отправившего PUBLISH
• ACK – подтверждение ответа на запрос INVITE

К диалоговым методам можно отнести:

• INVITE – приглашение пользователя на сеанс связи
• REGISTER – передает серверу информацию для регистрации пользователя

Детально рассмотреть можно здесь .

Пакет INVITE

Структура сообщений в SIP одинакова. Стартовая строка → Заголовки → Пустая строка → Тело сообщения. Для примера рассмотрим Пакет INVITE:

Далее следует основное тело пакета с полями заголовков. В основной своей части используются заголовки:

• Via
• Max-Forwards
• From
• To
• Contact
• Call-ID
• Cseq

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

Поле Max-Forwards указывает максимальное количество полей Via может быть в пакете.

Заголовок From предназначен для обозначения инициатора запроса с указанием адреса uri и  отображаемого имени.

В заголовок To подставляется информация о получателе сообщения. Зачастую формируется из значения Ruri. Т.к. в дальнейшем на клиентской стороне может быть изменена.

Заголовок Call—ID – это уникальный идентификатор, сохраняющийся на протяжении всего диалога.

В Cseq записывается порядковый номер запроса и имя метода, которое передается,

В поле Contact записывается URI адрес того устройства, на которое должен прийти ответ. Т.е. в приведенном выше примере, ответ прийдет из всех зарегистрированных устройств пользователя 102 на устройство <sip:[email protected]:5060;ob>

Т.е. сравните поля From и Contact в нашем примере:

В поле From указан адрес сервера астериска, а в поле Contact указан адрес устройства.

Причины отбоя INVITE

• В дампе вы видите только один или несколько инвайтов.

Причиной данной неполадки может быть:

1. Не правильно настроенный iptables
2. Попали в бан. (Проверять fail2ban)

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

• Вызов от неавторизованного пользователя.

Схема вызова в данном случае читается следующим образом:

1. Отправляется инициирующий INVITE
2. Получаем ответ от астериска 401 Unauthorized, что говорит нам о том, что пользователь не зарегистрированный
3. Клиент подтверждает что не авторизован пакетом ACK
4. Снова отправляется INVITE с авторизационными данными. Смотрим заголовок Authorization

• Получаем ответ от сервера 403 Forbidden, что указывает на то, что пользователя с такими авторизационными данными не существует на АТС
• Клиент подтверждает полученный ответ пакетом ACK

Примеры вызовов

Рассмотрим корректный вызов:

1. Отправляется инициирующий INVITE
2. Получаем ответ от астериска 401 Unauthorized, что говорит нам о том, что пользователь не зарегистрированный
3. Клиент подтверждает что не авторизован пакетом ACK
4. Снова отправляется INVITE с авторизационными данными.
5. АТС видит что пользователь авторизован и посылает ответ 100 Trying
6. Следом посылаются к инициатору пакеты 180 Ringing с различным интервалом. Пока не поднимут трубку.
7. Пакет 200 OK (SDP) от вызываемой стороны означает что трубка была снята, сейчас будут ходить RTP пакеты.
8. Инициатор вызова отправляет пакет ACK с подтверждением. Что увидел сигнал о снятии трубки
9. По завершению вызова будет отправлен пакет BYE со стороны инициатора разрыва линии.
10. Вторая сторона разговора отправляет пакет 200 OK без SDP для подтверждения завершения вызова

Вызов на не зарегистрированного пользователя.

1. Отправляется инициирующий INVITE
2. Получаем ответ от астериска 401 Unauthorized, что говорит нам о том, что пользователь не зарегистрированный
3. Клиент подтверждает что не авторизован пакетом ACK
4. Снова отправляется INVITE с авторизационными данными.
5. АТС видит что пользователь авторизован и посылает ответ 100 Trying
6. От сервера видим пакет 503 Service Unavailable

В пакете мы видим причину разъединения в полях X-Asterisk-HangupCause и X-Asterisk-HangupCauseCode (в данном примере это пользователь не найден).

7. Инициатор, подтверждает завершение вызова.

Пакет REGISTER

Рассмотрим пример пакета REGISTER и опишем его работу

Заголовки пакета и их назначение

Основные заголовки пакета:

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

Max-Forwards – указывается максимальное колличество хопов (прыжков/переадресаций) которые может пройти пакет до пункта назначения

Заголовок From предназначен для обозначения инициатора запроса с указанием адреса uri и  отображаемого имени.

В заголовок To подставляется информация о получателе сообщения. Зачастую формируется из значения Ruri.

Заголовок Call—ID – это уникальный идентификатор, сохраняющийся на протяжении всего диалога.

В Cseq записывается порядковый номер запроса и имя метода, которое передается.

Заголовок Expires содержит информацию о времени , через которое истекает регистрация. Значение указывается целочисленно в секундах от 0 до (2 ** 32) -1.

Возможные причины отбоя регистрации

В этом блоке будем рассматривать самые распространенные причины сбоев в регистрации

• Вы не видите ответа на пакет REGISTER

Причинами этой ситуации может быть:

• Firewall не пропускает, нужно проверить правила.

• IP инициатора запроса попал в бан

• Сетевое оборудование не пропускает. В данном случае, вы вообще не увидите запросов на АТС.
• Ответ на REGISTER есть, но регистрация не проходит.

• Не верный логин или пароль от extension (см. рис6)

Решение

Смотреть лог или консоль астериска

• Не верный permit (см. рис6)

Решение

Смотреть лог или консоль астериска.

• Указан не верный транспорт (UDP, TCP, TLS) (см. рис6)

Решение

Смотреть лог или консоль астериска.

Примеры регистрации

Рассмотрим корректную регистрацию:

• Digium посылает регистрацию на астериск.
• REGISTER с заголовком Authorization

• Получаем ответ отастериска пакет 200 OK

Рассмотрим не верную авторизацию:

• Телефон Digium посылает регистрацию на астериск.
• АТС отвечает сообщением 401 Unauthorized. Это означает что АТС не увидела авторизационные данные.
• Телефон заново посылает пакет REGISTER с заголовком Authorization
• В ответ PBX отвечает 403 Forbidden. Что означает что какие то данные не верны. Нужно смотреть консоль астериска.