Чтение SIP-логов без структуры превращает отладку Asterisk и Kamailio в гадание

Чтение SIP-логов без структуры превращает отладку Asterisk и Kamailio в гадание

В SIP сначала фиксируем три вещи: Call-ID, From/To и направление транзакции. Без этого INVITE, 100 Trying, 180 Ringing, 200 OK и ACK легко собрать в ложную цепочку. В Asterisk смотрим notransfer, cdr, pjsip set logger on; в Kamailio — tcpdump + siptrace или xlog с маршрутом и reply code.

Дальше проверяем тайминг и сопоставление диалогов. Если BYE пришёл без согласованного CSeq или ACK не дошёл до 200 OK, проблема часто не в приложении, а в NAT, retransmit или неверном Contact. Разбираем дамп трафика в Wireshark, и вот что мы там видим: один и тот же диалог может идти через несколько сокетов, а в логах это выглядит как «потерянный вызов».

Полезный порядок чтения: сначала заголовки, потом SDP, затем ответы. В SDP сверяем IP/port для RTP, codec list, direction sendrecv/sendonly. Если в SIP всё чисто, а звука нет — ищем asymmetric routing, неправильный rtpengine/rtpproxy или firewall, который режет UDP-сессии. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.

Не пытайтесь лечить сигнализацию по одному логу. Сопоставляйте SIP-диалог, RTP-дамп и состояние транка на уровне маршрутизации: тогда причина обычно находится за один проход, а не за пять кругов по конфигам.