MAATRIX / Блог / Своя АТС на Asterisk перестаёт окупаться на определённом числе линий

Своя АТС на Asterisk перестаёт окупаться на определённом числе линий

MAATRIX

Разворачивать свою АТС на Asterisk ради экономии на трёх линиях так же нелепо, как продолжать платить за облачную телефонию «за место», когда у вас уже полсотни внутренних номеров и штатный админ, который скучает без дела. Между этими крайностями лежит зона, где решение неочевидно, и правильный ответ зависит не от общих лозунгов «своё дешевле» или «облако надёжнее», а от конкретной арифметики: сколько у вас линий, сколько стоит час человека, который будет это администрировать, и насколько вы готовы разбираться в SIP руками, а не через кнопки веб-интерфейса. Разберём эту арифметику по шагам.

Что мы сравниваем: голый Asterisk, а не FreePBX

Важная оговорка сразу, потому что путаница в терминах здесь обычная. Asterisk — это open-source ядро АТС: демон, который умеет принимать и маршрутизировать звонки, вести очереди, проигрывать IVR-меню, писать разговоры. Сам по себе он не имеет графического интерфейса — вся конфигурация делается через текстовые файлы в /etc/asterisk/ и перезагружается командами в консоли. FreePBX — это отдельный продукт, веб-панель поверх того же ядра Asterisk, которая генерирует те же самые конфиги за вас через формы и кнопки, обычно в составе готового дистрибутива.

Это разные вопросы с разными ответами. Если вы уже решили ставить FreePBX и хотите знать, какие эксплуатационные проблемы вылезают у него через несколько месяцев эксплуатации — это отдельная тема про конкретный дистрибутив, его модули и обновления. Здесь же речь про более общий и более фундаментальный вопрос: окупается ли вообще идея держать телефонию на своей инфраструктуре (голый Asterisk, максимально гибкий и максимально ручной вариант) — в сравнении с облачной АТС как сервисом, где вы вообще не думаете ни про Asterisk, ни про FreePBX, а просто платите за рабочие места и получаете готовый личный кабинет. Если ответ «да, своя инфраструктура окупается» — то это отдельный последующий выбор, ставить ли поверх голого Asterisk панель управления или администрировать его напрямую через конфиги. Ниже — только первый вопрос: своя инфраструктура или аренда сервиса.

Из чего складывается счёт за облачную телефонию

Модель тарификации у подавляющего большинства облачных АТС и виртуальных операторов связи одна и та же: абонентская плата за рабочее место в месяц (называют по-разному — «оператор», «внутренний номер», «расширение», «пользователь»), часто со ступенчатыми тарифами по числу мест и с доплатой за опции сверх базового набора.

Типичные статьи, которые складываются в итоговый счёт:

  • Плата за место. Растёт линейно с числом сотрудников, принимающих звонки, — причём часто нелинейно на границах тарифных планов («до 10 мест», «до 25 мест», «до 50 мест»), где переход через порог обходится дороже, чем кажется на первый взгляд.
  • Запись разговоров. У части провайдеров входит в тариф, у части — отдельная опция или доплата за объём хранения записей сверх лимита.
  • IVR, очереди, сценарии маршрутизации. В базовом тарифе обычно есть простое переключение, а многоуровневые сценарии («для отдела продаж — 1, для поддержки — 2, для бухгалтерии — 3») нередко идут в более дорогом плане.
  • Интеграция с CRM. Popup-карточка клиента при входящем звонке, автоматическая фиксация звонка в сделке — тоже часто отдельная опция или требование более высокого тарифа.
  • SIP-транк и минуты. Даже при облачной АТС звонки на городские и мобильные номера тарифицируются отдельно от абонентской платы за место — это статья расходов, которая никуда не девается ни в одной из моделей.

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Что значит «поднять голый Asterisk» на практике

Здесь стоит быть честным: это не «установил пакет и работает», а работа с текстовыми конфигами и пониманием, как устроен SIP, а не набор кнопок в панели.

Базовый набор действий на Debian/Ubuntu:

apt update && apt install asterisk
systemctl enable --now asterisk
asterisk -rvvv    # консоль управления запущенным демоном

Дальше вся логика — в трёх основных файлах:

  • /etc/asterisk/pjsip.conf — регистрация внутренних номеров (endpoint, aor, auth) и настройка SIP-транка к оператору связи. Современный Asterisk работает через модуль PJSIP — старый chan_sip официально выведен из поддержки, и разворачивать на нём новую АТС в 2026 году уже нет смысла.
  • /etc/asterisk/extensions.conf — дialplan: логика маршрутизации звонков, IVR-меню, очереди, переадресация. Пример простейшего маршрута внутреннего звонка:
[internal]
exten => 100,1,Dial(PJSIP/100,20)
 same => n,VoiceMail(100@default)
 same => n,Hangup()

exten => _2XX,1,Dial(PJSIP/${EXTEN},20)
 same => n,Hangup()
  • /etc/asterisk/queues.conf — если нужна очередь звонков (например, для колл-центра или ресепшна на несколько человек) с распределением по операторам и статистикой ожидания.

Отдельный практический узел — NAT. Если сервер и SIP-телефоны сотрудников находятся за разными NAT (обычная ситуация для удалённых сотрудников или офиса за роутером), в секции transport pjsip.conf придётся явно прописать external_media_address, external_signaling_address и local_net — без этого звонок может устанавливаться, но пропадать голос в одну сторону. Это одна из самых частых причин, по которым «вроде настроил, а не работает», и разбирается через чтение pjsip set logger on в консоли и, при необходимости, tcpdump/sngrep для просмотра реального SIP-трафика.

Запись разговоров делается модулем MixMonitor, который добавляется прямо в dialplan строкой вида MixMonitor(${UNIQUEID}.wav) перед Dial() — файлы пишутся на диск сервера, и дальше вы сами решаете политику хранения и доступа.

Отдельно стоит помнить про кодеки: G.711 (стандартный, без лицензионных ограничений) достаточен почти всегда при нормальном канале, а G.729 (более компактный по трафику) в Asterisk требует платного кодек-модуля от вендора — если видите рекомендацию «просто включите G.729» без оговорки про лицензию, это неточность.

Скрытая себестоимость: время администратора без графического интерфейса

Главное отличие голого Asterisk не в деньгах на аренду сервера — сервер под голосовую нагрузку на разумное число линий стоит недорого, и это самая маленькая статья расходов в этой схеме. Главное отличие — в требованиях к квалификации и во времени человека, который это обслуживает.

Что регулярно требует ручной работы, в отличие и от облачной АТС, и от FreePBX с её формами:

  • Каждый новый внутренний номер — это правка pjsip.conf и extensions.conf вручную, а не форма «добавить пользователя». На пять номеров это несколько минут, на пятьдесят — это уже отдельная дисциплина именования и проверки, чтобы не сломать существующий dialplan опечаткой.
  • Изменение маршрутизации — новый IVR-пункт, новая очередь, переадресация на время отпуска сотрудника — правится в dialplan текстом, с последующим dialplan reload и проверкой, что синтаксис не сломан.
  • Диагностика проблем со звонком — «слышно одностороннее», «звонок обрывается через 30 секунд», «эхо» — типовые SIP/RTP-проблемы (NAT, таймауты, кодеки, MTU), которые требуют понимания протокола, а не просто «перезагрузить сервис». В облаке этим занимается служба поддержки провайдера, у вас — вы сами или подрядчик.
  • Обновления безопасности. Asterisk, как любой демон, принимающий трафик из интернета (SIP-порт 5060/5061), — регулярная цель для брутфорса международных номеров за ваш счёт (fraud, subscription toll fraud). Требуется fail2ban или аналог, ограничение по IP для транка, актуальные версии — самостоятельная забота, а не автоматика провайдера.
  • Резервное копирование конфигурации и записей — снятие бэкапа /etc/asterisk/ и каталога с записями по расписанию, с реальной проверкой восстановления, а не «оно вроде бэкапится».

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

Важный нюанс именно для телефонии: трудозатраты на голом Asterisk растут не столько от числа внутренних номеров (сама по себе регистрация endpoint — рутинная и быстрая операция), сколько от сложности логики — числа очередей, ветвлений IVR, интеграций с CRM через AMI/ARI, требований к отказоустойчивости. Компания на 40 человек с одной прямой линией на каждого администрируется проще, чем компания на 15 человек с тремя очередями, сложным IVR-деревом и интеграцией всплывающей карточки клиента.

Формула точки перелома

Считаем два потока расходов в месяц.

Облачная АТС:
P — цена за рабочее место в месяц (по актуальному тарифу провайдера)
N — число сотрудников, принимающих звонки
A — доплаты сверх базового тарифа (запись, IVR, интеграция с CRM)

Счёт за облако = P × N + A
Своя АТС на голом Asterisk:
C — аренда сервера в месяц
H — часы администрирования в месяц (зависит больше от сложности
    логики, чем от N — см. нюанс выше)
R — стоимость часа администратора (своего или подрядчика)

Счёт за self-hosted = C + H × R

Точка перелома по числу рабочих мест N* — это число сотрудников, при котором облачный счёт сравнивается с затратами на self-hosted:

N* = (C + H × R) / P

Если ваше реальное число сотрудников на телефоне больше N*, self-hosted теоретически выгоднее по прямым деньгам. Если меньше — дешевле платить за облако, даже с учётом того, что подписка растёт со штатом.

Подставим условный пример только для демонстрации методики, не как готовый тариф:

Условно: P = 800 ₽/место/мес, N = 20
Облако ≈ 16 000 ₽/мес (без учёта доплат за запись и IVR)

Условно: C = 1500 ₽/мес, H = 5 часов/мес, R = 2000 ₽/час
Self-hosted ≈ 1500 + 5 × 2000 = 11 500 ₽/мес

N* = 11 500 / 800 ≈ 14 сотрудников

В этом иллюстративном расчёте точка перелома оказывается заметно ниже 20 — то есть при таких вводных своя АТС выгоднее уже для штата от 14 человек. Но результат крайне чувствителен к H: если та же логика маршрутизации требует не 5, а 15 часов в месяц (сложное IVR-дерево, частые правки очередей, разбор инцидентов с fraud-атаками на SIP-порт), N* сдвигается почти вдвое вверх — и облако снова оказывается дешевле при том же штате. Отдельно стоит закладывать разовые трудозатраты на первичную настройку (обычно один-два полных рабочих дня квалифицированного администратора на голом Asterisk, без FreePBX это чаще ближе к верхней границе) — они не входят в месячную формулу, но реально влияют на срок окупаемости перехода.

Три сценария: сколько сотрудников — какое решение

Штат на телефонеЧто обычно выгоднееПочему
3-8 человек, простая маршрутизацияОблачная АТСАбонентская плата за места невелика, а H (часы админа) на голом Asterisk почти не масштабируется вниз — минимальный порог трудозатрат на настройку и поддержку есть даже для трёх номеров
10-30 человек, есть очереди/IVR, но без сложных интеграцийЗона неопределённости — считайте N* по своим цифрамИменно здесь решает не штат сам по себе, а сложность логики (H) и реальная стоимость часа администратора (R) — см. формулу выше
40+ человек или несколько точек с общей телефониейЧаще выгоднее своя инфраструктураАбонентская плата за места растёт линейно и без потолка, а трудозатраты на голом Asterisk растут медленнее штата — но при условии, что логика маршрутизации не разрастается пропорционально числу отделов

Наглядный пример из смежной темы — как меняется экономика для конкретной вертикали с высокими требованиями к записи разговоров, разобран в статье про свою АТС и записи разговоров в медцентре: там штат в 20 человек уже даёт заметную экономию именно из-за модели «плата за место» у облачных провайдеров и дополнительной чувствительности к тому, где физически лежат записи разговоров с пациентами.

Отдельно стоит учитывать не только деньги, но и риск. Голый Asterisk без графического интерфейса — это полная свобода настройки, но и полная ответственность: если единственный человек, который понимает вашу конфигурацию, уйдёт в отпуск или уволится, а вы не документировали dialplan, восстановление логики маршрутизации по памяти — не быстрая задача. Ведите README рядом с конфигами: какой номер за что отвечает, какая очередь на кого падает, что менялось и зачем. Это не блажь, а страховка от единой точки отказа в виде одного человека.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

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

Можно ли начать с облака, а потом перейти на свой Asterisk при росте штата?

Да, это обычный и разумный путь — облако снимает риск на старте, когда неизвестно, приживётся ли компания вообще, а миграция на свою АТС делается позже, когда штат и нагрузка предсказуемы. Перенос номеров через процедуру переноса у оператора связи занимает обычно одну-две недели, планируйте её заранее.

Нужен ли отдельный человек для администрирования, или справится любой сисадмин?

Формально — не обязательно выделенная штатная единица, но нужен человек, который реально понимает SIP, dialplan и NAT, а не «разберётся по ходу». Голый Asterisk без GUI прощает ошибки хуже, чем FreePBX: опечатка в конфиге dialplan может уронить маршрутизацию для всех номеров сразу, а не только для одного пользователя в форме.

Что с отказоустойчивостью — если сервер с Asterisk упадёт, компания останется без связи?

Риск тот же, что и для любой критичной инфраструктуры на одном сервере: нужен план на случай сбоя — резервный сервер с готовым образом конфигурации, либо временная переадресация номеров на мобильные оператора связи на время восстановления. Пропишите это в регламенте заранее, а не изобретайте в момент простоя.

G.729 обязателен, чтобы экономить трафик на слабом канале?

Нет, в большинстве случаев на современных каналах связи G.711 работает без проблем и не требует платной лицензии. G.729 имеет смысл только при реально узком и дорогом канале (спутниковая связь, сильно ограниченный аплинк) — и тогда стоимость лицензии на кодек нужно закладывать отдельной строкой.

Что выгоднее по деньгам — голый Asterisk или Asterisk с FreePBX поверх?

Сама лицензия и ядро одинаковые — FreePBX не добавляет прямых затрат на софт, но требует немного больше ресурсов сервера под веб-панель. Разница не в стоимости, а в квалификации: FreePBX снижает порог входа за счёт форм и модулей, голый Asterisk даёт больше контроля, но требует более глубокого понимания SIP от того, кто его настраивает и поддерживает.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →