Дмитрий Рашевский
20.02.2019
1174

Анализ SIP пакета, на примерах рабочего вызова и со сбоем

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

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

Работы проводились на CentOS release 6.9 (Final) Asterisk 13.21.0

Структура SIP

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

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

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

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

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

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

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

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

Далее все дампы сохранялись командой tcpdump -nnvy any -s0 port 5060 – w /tmp/sipdump.pcap

Пакет INVITE

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

Анализ дампа можно проводить в программе sngrep. Для того, чтобы открыть снятый вами дамп ткройте его командой sngrep -I /<путь>/<к>/<дампу>.pcap
Стартовая строка INVITE sip:84959898533@192.168.170.220 SIP/2.0
Заголовки Via: SIP/2.0/UDP 192.168.170.105:5060;rport;branch=z9hG4bKPjR1lZ8c09xesG.6AE497.qhlZlf2nwJxa Max-Forwards: 70 From: “102” <sip:102@192.168.170.220>;tag=5EH8QhIiuvpzL62cHe9uhXXbQbsSg8-s To: <sip:84959898533@192.168.170.220> Contact: “102” <sip:102@192.168.170.105:5060;ob> Call-ID: ks2EUm46cCnW9jlRCYfkIuXT0AdEaZzt CSeq: 31529 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: Digium D40 1_3_0_1_53901 Content-Type: application/sdp Content-Length:   442
Пустая строка  
SDP данные v=0 o=- 240683915 240683915 IN IP4 192.168.170.105 s=digphn c=IN IP4 192.168.170.105 t=0 0 a=X-nat:0 m=audio 4062 RTP/AVP 9 8 0 18 58 118 58 111 96 a=rtcp:4063 IN IP4 192.168.170.105 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:58 L16/16000 a=rtpmap:118 L16/8000 a=rtpmap:58 L16-256/16000 a=rtpmap:111 G726-32/8000 a=sendrecv a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
Для определения действия и направления пакета в SIP используется первая строка:
INVITE sip:84959898533@192.168.170.220 SIP/2.0
Метод SIP Ruri (request-uri) Версия протокола

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

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

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

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

Стандартно — в Max-Forwards указано число 70.

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

Параметр tag формирует отправляющая сторона<br>

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

Изменения также можно проводить для поля From

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

При инициализации нового диалога снова генерируется Call-ID.
В рамках одного вызова может быть инициализированных несколько диалогов.

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

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

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

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

From: “102” <sip:102@192.168.170.220>;tag=5EH8QhIiuvpzL62cHe9uhXXbQbsSg8-s Contact: “102” <sip:102@192.168.170.105:5060;ob>

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

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

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

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

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

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

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

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

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

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

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

Right_Call
  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 для подтверждения завершения вызова

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

Not register
  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 и опишем его работу

Первая строка REGISTER sip:192.168.170.220:5060 SIP/2.0
Заголовки Via: SIP/2.0/UDP 192.168.170.105:5060;rport;branch=z9hG4bKPj.J5KVeS0GGU4BV3DE1Wk0YLCSGSGQzjq Max-Forwards: 70 From: “102” <sip:102@192.168.170.220>;tag=J6Kk9pzb8UEm9uUgGMIZrwzdkuxw48f- To: “102” <sip:102@192.168.170.220> Call-ID: ARjJonSDAVAJADPRCdFlWj6Ww5jw3JU1 CSeq: 48583 REGISTER User-Agent: Digium D40 1_3_0_1_53901 Contact: “102” <sip:102@192.168.170.105:5060;ob> Expires: 0 Content-Length:  0
Для определения действия и направления пакета в SIP используется первая строка:
REGISTER sip:102@192.168.170.220 SIP/2.0
Метод SIP Ruri (request-uri) Версия протокола
REGISTER

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

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

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

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

Стандартно — в Max-Forwards указано число 70.

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

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

В дальнейшем на клиентской стороне поле To может быть изменено.

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

В рамках диалога REGISTER заголовок Call-ID не меняется

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

В ответных сообщениях в это поле вписывается метод на который производится ответ.
AnswerPacket

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

Измеряется с момента получения запроса.

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

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

Будем рассматривать регистрации только относительно астериска.
  • Вы не видите ответа на пакет REGISTER
NO_ANSWER_REGISTER

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

  • Firewall не пропускает, нужно проверить правила.
Iptables
  • IP инициатора запроса попал в бан
Ipset
  • Сетевое оборудование не пропускает. В данном случае, вы вообще не увидите запросов на АТС.
  • Ответ на REGISTER есть, но регистрация не проходит.
REGISTER_ANSWER
  • Не верный логин или пароль от extension (см. рис6)

Решение

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

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

Решение

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

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

Решение

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

Invalid transport

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

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

Right_Auth
  • Digium посылает регистрацию на астериск.
  • REGISTER с заголовком Authorization
Authorization: Digest username=”102″, realm=”pbx574″, nonce=”50117049″, uri=”sip:192.168.170.220:5060″, response=”026616e569998328028072d869333f72″, algorithm=MD5
  • Получаем ответ отастериска пакет 200 OK

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

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

Остались вопросы?

Я - Кондрашин Игорь, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

Why Choose HUGE?

Unlimited pre-designed elements

Each and every design element is designed for retina ready display on all kind of devices

User friendly interface and design

Each and every design element is designed for retina ready display on all kind of devices

100% editable layered PSD files

Each and every design element is designed for retina ready display on all kind of devices

Created using shape layers

Each and every design element is designed for retina ready display on all kind of devices