Как читать SIP-логи Asterisk и Kamailio без ложных выводов и лишнего шума

Как читать SIP-логи Asterisk и Kamailio без ложных выводов и лишнего шума

Первое правило — не искать проблему в одном сообщении. SIP-транзакция читается цепочкой: INVITE → 100 Trying → 180 Ringing/183 Session Progress → 200 OK → ACK. Если в логе виден только обрывок, сначала сопоставьте Call-ID, From-tag, To-tag и branch, иначе вы склеите разные диалоги в одну ошибку.

В Asterisk смотрите не только sip.conf/pjsip.conf, но и полный стек: include SDP, направление RTP, retransmit и итоговый код ответа. Типовая ловушка — 200 OK есть, а ACK не доходит: в логах это выглядит как повторные INVITE/окончание по таймауту, а в дампе часто видно, что NAT переписал адрес только на одном плече.

В Kamailio полезно читать не “сообщение”, а маршрут: какой branch создан, куда ушел request, какой reply matched. Если INVITE уходит в upstream, а ответ возвращается по другому пути, ищите Record-Route, loose_route(), topology hiding и несоответствие advertised address. Разбираем дамп трафика в Wireshark, и вот что мы там видим: сигнализация жива, но ответ теряется на асимметрии маршрута.

Практика простая: сравнивайте лог, дамп и таблицу NAT в одном временном окне; отдельно проверяйте Via, Contact, SDP c= и m= строки, отдельно — таймеры retransmission. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если трассировка не объясняет, где потерялся пакет, значит, вы пока смотрите не на тот уровень стека.