Логи SIP в Asterisk и Kamailio: как читать не шум, а причину сбоя

Логи SIP в Asterisk и Kamailio: как читать не шум, а причину сбоя

Первый шаг — не искать «ошибку» в одном сообщении, а собрать цепочку: INVITE → 100 Trying → 180 Ringing → 200 OK → ACK. Если звонок рвётся, смотрите, на каком переходе цепь обрывается. В Asterisk полезны sip set debug on, pjsip set logger on, core set verbose и целевой capture на проблемном транке; в Kamailio — log_level, xlog() и трассировка маршрута по веткам script.

Дальше сверяйте не текст, а поля: Via, Route, Contact, Record-Route, CSeq, Call-ID, branch, tag, SDP. Ошибки NAT обычно видно сразу: в SDP уезжает private IP, а в логах — разный source/received. Если INVITE уходит, а 200 OK не возвращается, проверьте обратный путь, Topology hiding, rport и корректность Contact/Record-Route. Разбираем дамп трафика в Wireshark, и вот что мы там видим...

Для Asterisk критичны диалплан и транк-логика: если есть 403/404/486, смотрите не только код, но и откуда он пришёл — endpoint, auth, маршрут, dialplan match. Для Kamailio полезно сравнивать, где запрос изменился: до nathelper, после loose_route(), после rewritehostport(). Частая ошибка — искать RTP, когда SIP ещё не сошёлся: сначала чинится сигнализация, потом медиа.

Практика простая: один Call-ID, один полный дамп, один маршрут. Фильтруйте по SIP-диалогу, а не по всему потоку, и фиксируйте, какой узел изменил заголовок или SDP. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.