• После отправки INVITE сервер получает 100 Trying, но дальнейшие ответы (180 Ringing, 200 OK) не поступают.
• Вызов зависает на 32 секунды и завершается по таймауту 408 Request Timeout или 504 Server Timeout.
• Абонент слышит абсолютную тишину в трубке после набора номера.
• Бесконечный цикл маршрутизации (SIP routing loop) между прокси-серверами.

1. Назначение предварительного ответа 100 Trying (RFC 3261 §21.1.1)

Статус 100 Trying — это предварительный hop-by-hop ответ. Его единственная цель — остановить повторную отправку запросов INVITE клиентом (отключить Timer A и перезапустить Timer B) и подтвердить, что следующий узел принял транзакцию в обработку.

2. Анализ зависших транзакций в Asterisk / Kamailio

# Просмотр активных SIP транзакций в Asterisk
asterisk -rx "pjsip show channelstats"
asterisk -rx "core show channels"

Если вызов завис на этапе 100 Trying, снимите дамп на пограничном шлюзе:

sngrep host 192.168.1.50

3. Типовые причины отсутствия ответов после 100 Trying:

• Зависание AGI/AMI скрипта в Asterisk: диалплан выполняет внешний запрос к медленной CRM или неработающей БД до вызова функции Dial().
• Сбои DNS SRV / NAPTR: прокси пытается разрешить следующий хост и блокирует стек по тайм-ауту сокета.
• Односторонняя сетевая блокировка: ответ 180/200 от удаленного узла блокируется межсетевым экраном из-за изменения порта или отсутствия NAT keep-alive.

4. Оптимизация диалплана для предотвращения зависаний

Никогда не выполняйте длительные блокирующие запросы до ответа вызывающему абоненту:

[fast-route]
exten => _XXXX,1,NoOp(Быстрый вызов без блокировок)
 ; Немедленная отправка 180 Ringing вызывающей стороне
 same => n,Ringing()
 ; Асинхронный запуск логики в CRM без блокировки диалплана
 same => n,System(/usr/local/bin/notify_crm.sh ${CALLERID(num)} &)
 same => n,Dial(PJSIP/${EXTEN},25)
 same => n,Hangup()