Отладка SIP-сигнализации начинается не с “почему не звонит”, а с чтения транзакций по слоям

Отладка SIP-сигнализации начинается не с “почему не звонит”, а с чтения транзакций по слоям

Сначала разделяйте SIP и медиа. В логах Asterisk и Kamailio ищите не “ошибку”, а цепочку: INVITE → 100 Trying → 180/183 → 200 OK → ACK. Если вызов рвётся, проверьте, на каком узле цепочка обрывается, и сопоставьте Call-ID, From-tag, To-tag, CSeq.

В Asterisk включайте точечную диагностику, а не шум:
- pjsip set logger on — для SIP-сообщений
- core set verbose 5 и core set debug 5 — только на время разборов
- смотрите, что реально ушло в SDP: адреса, порты, codecs, direction
Если в дампе есть 401/407, это не авария, а часть challenge-response. Если после 200 OK нет ACK, ищите NAT, неверный Contact или потерю маршрута.

В Kamailio ключевой фильтр — не весь syslog, а связка callid, from_tag, branch. Полезно сразу проверять:
- не переписал ли topology_hiding заголовки критично для маршрутизации
- совпадает ли Record-Route с реальным путём возврата
- не ломает ли nathelper контакт и Via
Разбираем дамп трафика в Wireshark, и вот что мы там видим: таймеры, retransmits, malformed SDP и асимметрию маршрута.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если логов мало, включайте захват на границе: tcpdump -s0 -w sip.pcap port 5060, а потом сопоставляйте pcap с логами приложений. Так вы увидите, где именно теряется сигнализация, а не будете гадать по симптомам.