Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

SIP_482_LOOP_DETECTED IP-Телефония и СКУД

SIP Error 482 Loop Detected: устранение петель маршрутизации и Max-Forwards

Обновлено: 24.08.2026
  • Мгновенный сброс звонка с ответом SIP/2.0 482 Loop Detected или 483 Too Many Hops.
  • В дампе трафика видно многократное прохождение одного и того же INVITE через одни и те же SIP-серверы.
  • Счетчик Max-Forwards уменьшается до 0.
  • Зацикливание между двумя АТС или между локальным сервером и пограничным SBC.

1. Механизм обнаружения петель маршрутизации по RFC 3261

Сервер фиксирует петлю (Loop Detected) в двух случаях:

  • Запрос INVITE приходит на сервер, и в списке заголовков Via уже присутствует собственный адрес сервера с тем же параметром branch.
  • Хеш-сумма транзакции (To, From, Call-ID, CSeq, Request-URI) совпадает с уже обрабатываемой текущей транзакцией в памяти софтсвитча.
INVITE sip:100@pbx1.company.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK-abc1
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK-xyz2
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK-abc1 ; ПОВТОРНЫЙ VIA (ПЕТЛЯ!)
Max-Forwards: 68

2. Анализ и устранение циклических переадресаций в FreePBX / Asterisk

Типичная проблема — взаимная переадресация номеров (Номер A переадресован на Номер B, а Номер B переадресован на Номер A):

# Проверка базы данных переадресаций FreePBX (CF / CFU / CFB):
asterisk -rx "database show CF"
asterisk -rx "database show CFU"

# Очистить ошибочную переадресацию для экстеншена 101:
asterisk -rx "database del CF 101"

3. Предотвращение зацикливания транков (Inbound / Outbound Routing Loop)

Если входящий вызов из транка оператора попадает в диалплане обратно в тот же транк:

# extensions.conf
[from-trunk-carrier]
exten => _+79991234567,1,NoOp(Inbound Call)
 ; ОШИБКА: отправка обратно в тот же транк без смены номера!
 ; same => n,Dial(PJSIP/+79991234567@trunk-carrier)
 ; ПРАВИЛЬНО: отправка на локальный внутренний номер:
 same => n,Dial(PJSIP/100,30)

4. Защита от петель в скрипте Kamailio

Используйте стандартную проверку модуля maxfwd и sanity в блоке route[REQINIT]:

if (!mf_process_maxfwd_header("10")) {
    sl_send_reply("483","Too Many Hops");
    exit;
}

if (check_route_param("nat=yes")) {
    # Обработка Record-Route параметров
}
💡 Практика специалистов: При настройке переадресаций (Call Forwarding) всегда ограничивайте максимальное количество переходов в диалплане переменной счетчика (например, не более 3 переходов), чтобы защитить станцию от шторма вызовов при круговом форвардинге.

Частые вопросы (FAQ)

В чем разница между ошибками SIP 482 и SIP 483?

SIP 482 (Loop Detected) возвращается, когда узел обнаруживает в заголовке Via собственный адрес/branch и понимает, что запрос ходит по кругу. SIP 483 (Too Many Hops) возвращается, когда счетчик заголовка Max-Forwards уменьшился до нуля.

Как параметр branch в заголовке Via помогает обнаружить петлю?

Параметр branch всегда начинается с магического префикса 'z9hG4bK' и представляет собой уникальный криптографический хеш параметров транзакции. Если узел видит свой собственный branch второй раз, это 100% признак петли.

Может ли неправильная настройка DNS SRV записей вызвать петлю 482?

Да. Если SRV-запись для домена указывает на несколько SBC, которые проксируют неразрешенный запрос друг на друга по кругу, это приведет к ошибке 482.

Какое начальное значение заголовка Max-Forwards считается стандартным?

Стандарт RFC 3261 рекомендует устанавливать начальное значение Max-Forwards равным 70. Каждый промежуточный SIP-прокси обязан уменьшать это значение на 1 перед пересылкой.

Полезные материалы
Рекомендуем