SIP-логи без шума: как читать Asterisk и Kamailio так, чтобы находить причину, а не симптомы

SIP-логи без шума: как читать Asterisk и Kamailio так, чтобы находить причину, а не симптомы

Сначала отделяем сигнализацию от медиа. В логах ищите цепочку INVITE → 100 Trying → 180 Ringing/183 → 200 OK → ACK. Если цепочка рвётся, проблема не в RTP, а в маршрутизации, заголовках или транзите через SBC. Разбираем дамп трафика в Wireshark, и вот что мы там видим: по Call-ID и CSeq можно быстро связать SIP-сообщения в одну сессию.

В Asterisk включайте verbose и sip/pjsip debug точечно, на один номер или один peer. Иначе тонете в потоке и пропускаете момент, где меняется Contact, Via или SDP. Смотрите:
• From/To и tag — правильная ли корреляция диалога
• Request-URI — туда ли уходит вызов
• SDP — совпадают ли IP/port с тем, что ждёт RTP-поток
• Response code — 403, 404, 407, 486 дают разную причину отказа

В Kamailio полезнее всего логи с маршрутными ветками и состоянием транзакции: куда ушёл вызов, кто вернул ответ, где сработал failure_route. Если есть NAT, проверяйте received/rport, rewrite_contact и корректность Record-Route; именно здесь чаще всего ломается обратный путь.

Не смешивайте SIP и RTP в одной диагностике. Если сигнализация проходит, а аудио нет — ищите SDP, firewall, symmetric RTP и расхождение адресов в offer/answer. Если же INVITE не доходит до 200 OK, отладка начинается с заголовков, транзита и логики маршрутизации. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.