Почему новые установки Asterisk делают на PJSIP

Для новой установки Asterisk выбирайте PJSIP: проект не рекомендует chan_sip, а в Asterisk 21 старый драйвер удалён. Если система уже работает, это не повод срочно всё ломать: проверьте версию, конфигурацию и поддержку у поставщика, затем готовьте тестовую миграцию. Здесь — факты, ограничения и план проверки.

Статус chan_sip: устарел, но не «умер» везде

У Asterisk есть конкретная граница, а не мистическая дата смерти. В официальной таблице модулей chan_sip помечен deprecated начиная с Asterisk 17 и удалён в Asterisk 21. Документация проекта не рекомендует выбирать его для новых установок; там же сказано, что дальнейшие исправления и развитие маловероятны, а поддержка через список рассылки, IRC и баг-трекер ограничена. Это практическая причина планировать переход. Утверждать, что любой работающий chan_sip завтра перестанет звонить, неверно: старые ветки и сборки различаются, важны версия, комплект модулей и сопровождение. (Устарел — не значит выключится в полночь.)

Сначала выясните, что запущено: версию Asterisk, способ установки, список загруженных модулей и происхождение пакетов. В Asterisk 21 chan_sip отсутствует, а в более ранних версиях его статус и доступность зависят от ветки и сборки. Это важнее календарного года. Если телефония работает на старой версии, не обновляйте её наугад и не удаляйте конфигурацию: проверьте совместимость приложений, модулей, диалплана и транков. Причина миграции — ограниченная перспектива поддержки, а не доказанная уязвимость в каждой установке.

PJSIP — стандартный SIP-драйвер Asterisk. Его конфигурация строится вокруг связанных объектов: endpoint хранит параметры SIP-устройства или узла, AOR описывает адреса контактов, transport задаёт транспортный уровень, а при необходимости добавляются auth, identify и registration. Документация указывает, что endpoint без связанного AOR нельзя использовать для связи с удалённым устройством. Это конкретное отличие модели настройки; оно не доказывает, что любой PJSIP-сервер быстрее или стабильнее любого chan_sip. Архитектуру выбирают по функциям и проверяют на своей нагрузке.

Не стоит продавать переход страхом. Сам факт использования chan_sip не означает, что звонки прослушиваются, а PJSIP не обеспечивает безопасность «из коробки». В руководстве Asterisk показаны TLS для сигнализации и SRTP для медиапотока, причём примеры есть для обоих драйверов. Защиту определяют настройки, управление доступом, обновления системы и сетевые ограничения. Если нужна криптография, проверьте поддержку на клиентах и у оператора, настройте её с обеих сторон и отдельно проверьте медиапоток.

Переход: разберите действующую схему

До переноса составьте список того, что обслуживает телефония: внутренние номера и типы регистрации, входящие и исходящие транки, маршруты, очереди, голосовую почту, конференции, переадресации и интеграции. Отдельно зафиксируйте адреса и порты, способы аутентификации, кодеки и требования оператора. Не переписывайте конфиг строка за строкой, пока не понимаете назначение каждой настройки. Часть поведения задаёт диалплан или внешняя АТС, а не SIP-драйвер; перенос одного файла не переносит систему целиком.

Сделайте резервную копию конфигурации и базы данных, сохраните версии пакетов и способ возврата. Подготовьте стенд или окно работ, где можно проверить ключевые направления вызовов. До переключения убедитесь, что есть доступ к консоли и команда умеет вернуть исходную конфигурацию. Нельзя обещать отсутствие простоя без знания топологии и сценария переключения. Практичная цель — ограничить окно работ, определить проверки и иметь проверенный откат. (План отката портит только самоуверенность.)

Сравните текущие параметры с фактическим поведением. Зарегистрированный аппарат может принимать вызовы, но исходящий маршрут зависеть от отдельного контекста; транк может принимать только заданный формат номера; очередь — использовать специфичное приложение. Запишите ожидаемый результат каждого важного сценария, а не только название настройки. Эти заметки станут приёмочным списком после переноса. Если есть неизвестные настройки, выясните их назначение по документации именно вашей версии и журналам до изменения.

Проверьте зависимости от дистрибутива или панели управления. Если конфигурацию генерирует FreePBX или собственные шаблоны, ручная правка файлов может быть перезаписана при следующем применении настроек. Выясните, как поставщик собирает Asterisk и какие модули доступны. Не всякий переход требует сборки из исходников: совет «соберите сами» не заменяет обновлений и сопровождения. Выберите поддерживаемый способ развёртывания, который команда сможет повторить и восстановить.

Чем отличается настройка PJSIP

В PJSIP используется pjsip.conf и набор секций с типами объектов. Типичный endpoint связывают с AOR, а аутентификацию и транспорт описывают соответствующими объектами. Это разделяет функции, но конфигурация не становится автоматически простой: у объектов много параметров, и связи имеют значение. В официальной документации описаны типы, отношения и команды CLI для диагностики. Начните с минимальной схемы для одного тестового аппарата, затем добавляйте особенности телефонии.

Не копируйте механически названия полей из sip.conf. Найдите аналог нужного поведения в документации своей ветки res_pjsip. Параметр aors у endpoint указывает связанные AOR, а AOR сообщает, куда Asterisk может обратиться. Для входящей регистрации имя AOR сопоставляется с пользовательской частью SIP URI в заголовке To, если не применяется иной способ идентификации. Ошибка выглядит как «аппарат зарегистрирован, но вызов не находится», хотя причиной бывает несвязанный объект или правило сопоставления.

Диагностируйте по этапам: загружен ли объект, связан ли endpoint с нужным AOR, появился ли контакт после регистрации, совпал ли входящий запрос с endpoint и попал ли вызов в ожидаемый context. В CLI можно посмотреть endpoint и AOR; официальный troubleshooting guide разбирает случаи, когда AOR отсутствует или не загрузился. Сетевые проблемы проверяйте отдельно: адреса, NAT и RTP. ICE и STUN нужны в некоторых топологиях, но не являются универсальным лекарством от проблем со связью.

Производительность нельзя выводить из фразы «модульный значит быстрее». Результат зависит от версии Asterisk, числа регистраций и вызовов, приложений, кодеков, журналирования и оборудования. Я не обещаю линейное масштабирование или выигрыш CPU без измерений. Если нагрузка критична, снимите показатели на рабочем профиле, повторите тест на целевой конфигурации и сравните одинаковые сценарии. Один лабораторный звонок ничего не доказывает о промышленной нагрузке.

Как проверить совместимость до переключения

В некоторых установках два SIP-драйвера можно загрузить одновременно, но это не гарантия бесконфликтной работы. Если оба слушают один адрес и порт, возникнет конфликт привязки; если настроены разные порты, проверьте маршрутизацию, firewall и направление регистраций и вызовов. Asterisk отдельно предупреждает о проблемах с портами при одновременной работе драйверов. Проверьте конкретную версию на стенде. Не отключайте chan_sip в modules.conf, пока не подтвердили, что новая схема обслуживает нужные каналы.

Для теста выберите контрольные номера и сценарии: регистрация аппарата, внутренний вызов, транк в обе стороны, перевод, удержание, DTMF, голосовая почта и запись, если она нужна. Согласуйте тест с оператором и исключите попадание вызовов на реальных абонентов. Проверяйте не только установление соединения, но и двусторонний звук, Caller ID, завершение вызова и запись событий. Фиксируйте ожидание, результат и журналы; иначе «вроде заработало» будет единственным критерием приёмки.

Проверяйте NAT и медиатрафик отдельно от SIP-регистрации. Успешный REGISTER подтверждает обмен сигнализацией, но не гарантирует, что RTP проходит в обе стороны. Сверьте внешние адреса, правила firewall, адреса SDP и поведение при звонках из разных сетей. Подробную SIP-диагностику включайте на ограниченное время, затем выключайте, чтобы не раздувать журналы и не собирать лишние данные. Если сбой возникает только с конкретным оператором или клиентом, сохраняйте обезличенные примеры и проверяйте параметры именно этой стороны.

Проверьте обратный сценарий. До работ сохраните конфигурацию и задайте критерий отката: например, критичная группа вызовов не проходит или односторонний звук не исправляется за согласованное время. Убедитесь, что возврат не оставит одновременно активными несовместимые правила. После переключения наблюдайте за отказами вызовов, регистрациями, RTP и нагрузкой в период, соответствующий режиму звонков организации. Длительность задаёт риск и график работы, а не универсальное число из статьи.

Поддержка, безопасность и решение о сроках

Технический долг измеряется стоимостью сопровождения, а не лозунгом. Если команда не может обновить старую ветку, найти специалиста или проверить совместимость нового оборудования, переход нужно включить в план. Если старый контур стабилен и поддерживается поставщиком, решение можно принять планово, оценив срок поддержки и стоимость риска. Ни один из вариантов не означает «всё срочно выключить». Зафиксируйте ответственного, дату повторной оценки и вопросы, которые надо закрыть перед миграцией.

Юридические последствия нельзя выводить из одного слова deprecated. Не следует обещать штраф, нарушение ФЗ-152 или провал аудита только из-за старого SIP-драйвера: для вывода нужны применимые требования, факты и юридическая оценка. Разумная практика — вести учёт версий и обновлений, ограничивать доступ, сохранять конфигурацию и проверять защиту. Если телефония обрабатывает персональные данные, оценивайте систему и процессы вместе с профильным специалистом, а не приписывайте правовой статус отдельному модулю.

Миграция оправдана, когда целевая версия поддерживается, нужные функции проверены, а команда понимает откат. План включает инвентаризацию, тестовую конфигурацию PJSIP, проверку сценариев, согласованное переключение, наблюдение и удаление старых настроек после стабилизации. Не удаляйте старые файлы после первого успешного звонка. Они нужны для сравнения и возврата, пока приёмка не завершена и резервная копия не проверена.

После перехода обновите документацию: какой endpoint связан с каким AOR, где заданы транспорт и аутентификация, какие маршруты проходят через транк и как проверить регистрацию. Это уменьшает зависимость от человека, который помнит детали по памяти. Добавьте мониторинг доступности транков и регистрации, но не подменяйте им проверку вызовов: SIP может быть доступен, а аудио или отдельный маршрут — нет. (Зелёная лампочка иногда очень уверена в себе.)

Частые вопросы