Как читать SIP-логи Asterisk и Kamailio, чтобы быстро найти поломку в сигнализации

Как читать SIP-логи Asterisk и Kamailio, чтобы быстро найти поломку в сигнализации

Первое правило: не ищите ошибку только в одном слое. SIP-диалог надо сопоставлять с транзитом через proxy, B2BUA и RTP-потоком. Разбираем дамп трафика в Wireshark, и вот что мы там видим: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK — если цепочка рвётся, проблема уже локализуется по отсутствующему сообщению.

В Asterisk смотрите не «весь лог», а связку pjsip set logger on + core set verbose + rtp set debug on. Важны Call-ID, CSeq, branch, tag и contact-адреса. Если в логе есть 488/480/486, проверьте SDP: кодеки, fmtp, направление media, наличие m=audio и корректный c= адрес. Частая ошибка — ответ 200 OK приходит, а ACK не доходит из-за NAT или неверного Route set.

В Kamailio анализируйте не только xlog, но и транзакцию: какой request_route сработал, где изменились Record-Route/Contact, не переписался ли домен, не отрезал ли nathelper заголовки, нужные downstream. Если INVITE ушёл, а 408 вернулся без попытки на апстриме, ищите policy-ветку, таймауты и неверный match по source IP.

Полезный порядок отладки: 1) найти Call-ID в обоих узлах; 2) сверить временную шкалу; 3) проверить, кто последний отправил корректный ответ; 4) сравнить SDP по обе стороны; 5) проверить NAT, symmetric RTP и transport. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если лог не объясняет поведение, значит вы смотрите не туда: SIP чинят не «по ощущению», а по последовательности сообщений, заголовкам и расхождению между сигнализацией и медиапланом.