Переход на PJSIP без мифа о волшебном ускорении

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

Что именно устарело в chan_sip

Я разделяю два утверждения: chan_sip устарел как модуль, а конкретная АТС медленная из-за chan_sip. Первое подтверждает сам проект Asterisk: модуль объявлен устаревшим в ветке 17 и удалён в версии 21. Второе без измерений не доказать. Потери звука, задержки и обрывы могут быть связаны с сетью, NAT, кодеками, RTP, маршрутом вызова, ресурсами машины или настройкой телефонов. Смена SIP-драйвера не исправляет автоматически ни один из этих пунктов. Поэтому я начинаю не с покупки сервера, а с симптома, времени его появления и логов.

В документации Asterisk прямо сказано не выбирать chan_sip для новых установок. Это достаточная причина не строить на нём новую телефонию и заранее готовить переход со старой. Но это не команда срочно выключить работающую АТС посреди рабочего дня. Пока установленная версия поддерживает модуль, сначала фиксирую текущую схему: внутренние абоненты, транки, входящие маршруты, исходящие правила, переадресации и критичные сценарии. Старое решение может быть неудобным в сопровождении, не будучи причиной каждого сбоя. Удивительно, но у плохого звука иногда виноват плохой звук, а не любимый объект миграционного проекта.

• chan_sip устарел начиная с Asterisk 17
• Модуль удалён в Asterisk 21
• PJSIP — рекомендуемый драйвер для новых установок
• Причину деградации нужно измерять отдельно

Как устроен PJSIP и что меняется в конфигурации

В PJSIP конфигурация описывает несколько связанных объектов. Endpoint хранит параметры SIP-профиля телефона или удалённой стороны; к нему привязывают AoR с адресом или контактами, при необходимости объект auth, а также транспорт. Поэтому привычный peer из sip.conf нельзя механически переименовать в endpoint и считать работу законченной. У объектов разные роли, а связи между ними задаются явно. Именно это даёт более гибкую модель: например, один endpoint может ссылаться на связанные AoR и auth, а transport задаёт, как модуль работает на сетевом уровне.

Я проверяю для каждого устройства и транка не только имя секции, но и направление соединения, способ регистрации, авторизацию, контекст dialplan, кодеки и адреса. В простом примере телефона обычно нужны endpoint, auth и AoR; для транка будут свои параметры регистрации и авторизации. Точный набор зависит от сценария и версии Asterisk. Конфигурация транспорта поддерживает UDP, TCP, WebSocket и TLS, но наличие протокола в списке не означает, что его следует включить везде. Сначала определяют требования к сигнализации и сеть, затем заводят только нужные транспорты. Порт, сертификат или шифрование не появляются от смены имени секции.

Модель PJSIP не гарантирует нулевых блокировок, бесконечного числа вызовов или меньшего расхода CPU на любом оборудовании. Я не сравниваю драйверы фразой «новый значит быстрее»: для такого вывода нужны одинаковый сценарий, оборудование, версия, кодеки, маршрутизация и нагрузка. Измеряйте частоту одновременных вызовов, загрузку CPU, потери RTP и задержку на своих условиях. Если проблема в переполнении канала связи или неверном NAT, сравнение драйверов лишь аккуратно измерит одну и ту же проблему дважды.

Как подготовить миграцию, не копируя конфиг вслепую

Перед изменениями я сохраняю конфигурацию Asterisk и выгружаю фактические состояния пиров, регистраций и маршрутов. Затем составляю таблицу соответствий: старый peer, новый endpoint, AoR, объект auth, контекст, кодеки, транспорт и сценарий тестового звонка. Для первичного преобразования Asterisk поставляется скрипт sip_to_pjsip.py в каталоге contrib/scripts. Вендор называет его базовым конвертером, а не кнопкой «перенести АТС». Его результат нужно читать и сверять: скрипт не знает, какие правила dialplan важны бизнесу и какие особенности провайдера появились за годы.

Подготовьте стенд или отдельную тестовую группу телефонов. На ней проверьте входящую регистрацию, исходящий вызов, входящий вызов по каждому транку, перевод, удержание, DTMF, голос в обе стороны и поведение после потери связи. Если используется факс, запись, конференция или нестандартный кодек, включите этот сценарий в список отдельно. Я фиксирую ожидаемый результат до переключения, иначе после теста трудно отличить регрессию от старого дефекта. Конфигурацию chan_sip и pjsip.conf не следует считать взаимозаменяемыми: это разные модели, и часть параметров придётся осмысленно перенести вручную.

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

• Сохранить конфигурацию и текущую схему звонков
• Сопоставить peer с объектами PJSIP
• Проверить результат sip_to_pjsip.py вручную
• Испытать сценарии на стенде или группе

ICE, TLS и SRTP: сначала проверьте условия

Утверждение, что chan_sip вообще не поддерживает ICE, неверно. В документации Asterisk сказано, что поддержка ICE включена глобально в системе, но для chan_sip по умолчанию отключена; параметр icesupport можно включить в sip.conf глобально или для отдельного peer. Для работы ICE также требуется подходящая настройка STUN и/или TURN, если этого требует сетевая схема. У PJSIP эти возможности тоже зависят от конфигурации и условий соединения. Если звонки идут через NAT, проверьте адреса, SDP и фактические RTP-пакеты; название драйвера само по себе не устраняет ошибку маршрутизации.

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

Для внешних соединений не выбирайте TLS просто по правилу «снаружи всегда TLS». Сначала выясните, что поддерживает оператор и какие требования к сертификатам, шифрам, портам и медиапотоку применяются в вашей конфигурации. Для локального сегмента важны его границы и модель угроз. Отдельно настройте сетевые правила для SIP и RTP и проверьте их пакетами или диагностикой Asterisk. Не публикуйте без необходимости панель управления и не открывайте произвольные диапазоны «на всякий случай». Безопасность состоит из согласованной схемы, а не из букв TLS в названии транспорта.

Как сравнить работу до и после перехода

Нагрузочное сравнение имеет смысл только при повторяемом сценарии. SIPp подходит для генерации SIP-сигнализации и вызовов, но сам факт запуска SIPp не измеряет качество аудио. Я записываю версию Asterisk, число одновременных диалогов, кодеки, длительность, сценарий набора, параметры генератора и метрики сервера. Для медиа отдельно смотрю RTP-потери, задержку и джиттер там, где есть подходящий измерительный метод. Сначала снимите базовые значения на прежнем драйвере, затем повторите тот же тест после изменения. Если менялись другие параметры, честного сравнения уже нет.

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

В Asterisk состояние объектов и журналы PJSIP помогают диагностировать регистрацию и SIP-обмен. Но «более подробные логи» не равны автоматически «проблема решена»: нужно включать диагностический уровень на время поиска, сопоставлять сообщения с конкретным вызовом и затем возвращать обычный уровень журналирования. В тесте фиксируйте, где именно появился сбой: регистрация, согласование кодеков, установление медиасессии или сам RTP. Так мы понимаем, что менять дальше, а не объявляем любой симптом доказательством превосходства одного драйвера.

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

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

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

В сети «Омега Групп» этот подход означает сначала описать действующие сценарии телефонии, затем перевести и проверить их на PJSIP; я не приписываю этому кейсу неподтверждённые проценты ускорения или экономии. Отчёт по итогам должен отвечать на конкретные вопросы: какие устройства перешли, какие вызовы проверены, что осталось на старой схеме и какие риски требуют отдельного окна. Миграция считается законченной не тогда, когда pjsip.conf перестал ругаться, а когда пользователи звонят по привычным маршрутам и администратор знает, как эту конфигурацию сопровождать.

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