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

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

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

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

SIP 494 Security Agreement Required: настройка RFC 3329, IPsec и TLS

Обновлено: 24.08.2026 · Официальная документация ↗

Отказ в обслуживании при попытке регистрации или установления вызова в IMS / VoLTE и защищенных сетях операторов:

  • Сервер или SBC возвращает ответ SIP/2.0 494 Security Agreement Required.
  • В теле ответа сервера присутствует заголовок Security-Server с перечнем обязательных механизмов шифрования (например, ipsec-3gpp, tls, sdes-srtp).
  • Клиентский запрос REGISTER или INVITE не содержал заголовка Security-Client или предлагал неподдерживаемые протоколы.
  • Вызовы блокируются на пограничном контроллере сессий (SBC).

1. Механизм согласования безопасности (RFC 3329)

Спецификация RFC 3329 определяет порядок согласования механизмов защиты между клиентом и сервером до начала передачи конфиденциальных данных:

UAC (Клиент)                                  UAS (Сервер/IMS)
     |                                               |
     |--- REGISTER (Security-Client: tls) ---------->|
     |<-- 494 Security Agreement Required -----------| (Security-Server: ipsec-3gpp, tls)
     |                                               |
     |--- REGISTER (Security-Verify / Client) ------>| (Согласовано)
     |<-- 200 OK ------------------------------------|

2. Анализ заголовков Security-Server в Wireshark / sngrep

Проверьте параметры, которые требует сервер в ответе 494:

SIP/2.0 494 Security Agreement Required
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK4321
Security-Server: msrp-tls;prot=auth;mod=rsa,
                 tls;prot=auth;mod=rsa,
                 ipsec-3gpp;alg=hmac-sha-1-96;ealg=aes-cbc;spi-c=1000;spi-s=2000;port-c=5060;port-s=5060

3. Конфигурация клиента / шлюза для поддержки RFC 3329

Если используется терминал с поддержкой VoLTE/IMS (например, шлюз с SIM-картами):

  • Включите опцию Enable RFC 3329 Security Agreement в настройках SIP стека.
  • Выберите обязательный механизм: IPsec 3GPP или TLS в зависимости от требований оператора связи.
  • Убедитесь, что настроены корректные пары портов для защищенных SA (Security Associations).

4. Отключение требования Security Agreement на собственном SBC

Если вы администрируете собственный Kamailio / OpenSIPS и ошибочно включили модуль secfilter:

# В конфигурации Kamailio отключите принудительную проверку:
# if (!sec_agree_check()) {
#     sec_agree_send_reply();
#     exit;
# }
💡 Практика специалистов: Если при подключении к IMS-ядру сотового оператора вы получаете 494, проверьте правильность настройки IPsec-туннелей (IKEv2 / ESP) на внешнем маршрутизаторе: сигнализация не должна идти в открытом виде через UDP/5060.

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

Для чего используется ошибка SIP 494?

Статус 494 генерируется сервером, если клиент пытается выполнить запрос без использования согласованного механизма безопасности (IPsec, TLS и др.), который является строго обязательным на данном узле согласно RFC 3329.

В каких сетях чаще всего встречается код 494?

Этот код является базовым для архитектуры 3GPP IMS (IP Multimedia Subsystem), сетей VoLTE/VoWiFi и межоператорских пиринговых стыков, использующих аппаратные криптошлюзы.

Может ли обычный Asterisk обработать заголовок Security-Client?

Базовый Asterisk не имеет встроенного полноценного стека RFC 3329 для динамического поднятия IPsec SA. В таких схемах перед Asterisk устанавливается специализированный SBC (Kamailio / OpenSIPS / Acme Packet).

Как клиенту подтвердить согласованные параметры?

Клиент отправляет повторный запрос с заголовком Security-Verify, который в точности повторяет параметры заголовка Security-Server, полученного в ответе 494.

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