Отладка SIP-сигнализации: как читать логи Asterisk и Kamailio без гадания

Отладка SIP-сигнализации: как читать логи Asterisk и Kamailio без гадания

Первое правило — не смотреть только на один узел. Asterisk показывает симптом на уровне диалплана, Kamailio — маршрут и транзит SIP, а реальная причина часто сидит в несостыковке Via, Contact, SDP или в NAT.

Собирайте цепочку целиком:
— sip set debug on / pjsip set logger on в Asterisk для SIP-транзакций
— journalctl, rtp debug и логи диалплана для понимания, где вызов меняет состояние
— Kamailio: xlog(), syslog, tm/acc, плюс полный заголовок INVITE/183/200/ACK
— в дампе ищите не «ошибку», а разрыв последовательности: retransmit, 4xx/5xx, отсутствующий ACK, неверный branch, неправильный CSeq

Разбираем дамп трафика в Wireshark, и вот что мы там видим: если INVITE дошёл, 200 OK ушёл, а ACK не вернулся — это почти всегда маршрут, NAT или Contact. Если есть 183/180 без RTP, проверяйте SDP и media-path: адреса, порты, symmetric RTP, rport, rewrite_contact.

Для Kamailio важен порядок: сначала понять, где пакет был принят, потом — какой скриптовый блок его изменил, и только затем смотреть на downstream. Для Asterisk — сверять состояние канала, диалплан и SIP-логи в одной временной шкале. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практика простая: сначала фиксируйте полный SIP-dialog, затем проверяйте таймлайны, и только после этого меняйте конфиг. Иначе вы лечите шум, а не причину.