Логи SIP в Asterisk и Kamailio: как читать INVITE, 4xx и retransmit без гадания

Логи SIP в Asterisk и Kamailio: как читать INVITE, 4xx и retransmit без гадания

Первое правило отладки — не смотреть на один лог в вакууме. Сопоставляйте SIP-диалог по Call-ID, branch, From-tag и To-tag: только так видно, где именно ломается цепочка транзакций. В Asterisk полезны full/debug и включение SIP/ PJSIP trace, в Kamailio — xlog и siptrace, но без корреляции по идентификаторам это просто шум.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: INVITE ушёл, 100 Trying пришёл, а дальше тишина — значит, проблема уже не в сигнализации клиента, а в маршрутизации, NAT или downstream-сервере. Если видите 401/407, проверяйте auth header и повторный INVITE; если 480/486 — смотрите логи B2BUA/бэкенда, а не только прокси.

Для Kamailio важны топология и состояние транзакции: branch-флаги, Record-Route, Via и контактный адрес после NAT-манипуляций. Для Asterisk ищите, совпадает ли конечный Contact с реальным reachable IP, нет ли раннего переписывания SDP и не отрезается ли 200 OK на обратном пути. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практика простая: сначала подтверждаем доставку SIP-пакетов, потом состояние транзакции, и только затем лезем в RTP. Если сигнализация «живая», а медиа молчит — проблема уже в SDP, NAT или firewall, а не в диалплане. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.