Как перенести телефонию на Asterisk и сохранить контроль

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

Зачем уходить из облака и когда этого делать не стоит

Облачная АТС удобна до тех пор, пока ваши сценарии укладываются в её конструктор. Как только нужно своё меню по времени суток, умная маршрутизация по клиенту из CRM или хранение записей у себя, начинаются доплаты за модули и обходные пути. Asterisk в этой серии мы рассматриваем как обычную офисную IP-АТС: сервер, на котором живут внутренние номера, очереди, записи и маршруты. Если вы решили забрать телефонию под свой контроль, это типовая задача внедрения open-source решений, а не подвиг.

Но сначала — когда переезжать не надо. Если у вас десять сотрудников, два номера и нет ни одного нестандартного сценария, облако дешевле и спокойнее: за сервер, его обновления и бэкапы кто-то должен отвечать. Если внутри компании нет человека и нет подрядчика, который будет держать Asterisk, вы просто поменяете зависимость от облачного оператора на зависимость от случайного фрилансера. Это плохой обмен. Переезд оправдан, когда сценарии стали частью бизнеса: диспетчерская, колл-центр, продажи с плотной интеграцией в CRM. Тогда собственная АТС — это не экономия на абонентке, а контроль над тем, как именно звонит ваш клиент и куда попадает его вызов. Именно такой случай я и разберу дальше.

Этап 1. Инвентаризация: номера, маршруты, люди

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

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

Третья часть описи — люди и устройства. Какие у сотрудников телефоны, софтфоны, мобильные приложения, кто работает из дома, у кого гарнитура подключена к компьютеру. Модели IP-телефонов важны: от них зависит, сможете ли вы раздать конфиг автоматически или придётся настраивать каждый аппарат руками. Совместимость старых телефонов проверьте на вашей версии Asterisk и у оператора: список кодеков, транспорт SIP и поддержка шифрования зависят от конкретных моделей и настроек. Не назначайте TLS обязательным условием каждому аппарату — сначала подтвердите, что обе стороны его поддерживают. Удалённые сотрудники — отдельная строка: их домашние роутеры вы не контролируете.

• Внешние номера и владелец каждого номера
• Маршруты по времени, меню, очереди, переадресации
• Внутренние номера, группы, мобильные переадресации
• Модели телефонов и софтфонов, удалённые сотрудники
• Интеграции: CRM, запись, статистика

Этап 2. Параллельный контур: PJSIP, NAT и RTP

Новый Asterisk поднимается рядом со старой АТС и до самого конца ничего у неё не отбирает. Регистрируем на нём тестовый транк к провайдеру — если провайдер позволяет второй транк или тестовый номер, это идеально. Внутренние номера описываем в PJSIP: endpoint, auth, aor на каждого сотрудника. Ошибки в pjsip.conf, о которых мы говорили в серии, здесь вылезают все сразу, поэтому лучше поймать их на тестовом номере, чем на живых клиентах. Здесь же ограничьте доступ к SIP по адресам и настройте уникальную аутентификацию. Не выставляйте интерфейсы управления в интернет. Правила фильтрации и защита от перебора зависят от схемы подключения и должны проверяться снаружи.

NAT — одна из частых причин одностороннего звука, но не единственная: проверяйте также firewall, адреса в SDP, RTP-маршрут и согласование кодеков. Если Asterisk стоит за роутером, в транспорте PJSIP задаются local_net для внутренних сетей и external_media_address с external_signaling_address для внешнего адреса. Диапазон RTP задаётся параметрами rtpstart и rtpend в rtp.conf; откройте для него нужный UDP-трафик в firewall и на NAT-устройстве. Не копируйте чужие границы диапазона: сверьте конфигурацию вашей сборки и сетевую схему. В образце Asterisk приведены значения по умолчанию 5000 и 31000, а диапазон 10000–20000 показан как пример настройки. Регистрация транка подтверждает только регистрацию, а не прохождение входящего вызова или RTP. Проверьте входящий и исходящий звонки, двусторонний звук, удержание и перевод; длительность теста выбирайте по сценарию и не считайте одну минуту гарантией качества. Отдельно проверьте удалённых сотрудников из-за их роутеров: у них NAT двойной, и симптомы будут другие.

Полезные команды консоли на этом этапе — они реально существуют и спасают часы:

asterisk -rx "pjsip show registrations"
asterisk -rx "pjsip show endpoints"
asterisk -rx "core show channels"
asterisk -rx "pjsip set logger on"

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

Этап 3. Записи, CRM и сценарии

Записи разговоров — то, что пользователи заметят первым, если оно сломается. Решите заранее, где они будут лежать, сколько хранятся и кто имеет к ним доступ. В диалплане запись можно запускать приложением MixMonitor. Если имя файла относительное, Asterisk сохраняет запись в настроенный каталог мониторинга; расположение каталогов задаётся в asterisk.conf и может отличаться от типовой установки. Проверьте место на диске с запасом: диспетчерская, где все звонки пишутся, за год накапливает очень заметный объём. И отдельно решите судьбу старых записей в облаке — выгрузите их до отключения, потом может быть поздно. Права на каталог записей ограничьте сразу.

Интеграция с CRM — второе место, где переезд ломается. Облачная АТС часто имела готовый виджет, а с Asterisk связь строится через AMI или ARI и коннектор на стороне CRM. Проверьте три вещи: карточка клиента открывается при входящем, исходящий из CRM уходит через нужный транк, ссылка на запись попадает в сделку. Если хотя бы одно не работает, менеджеры начнут вести учёт в блокноте, и вы потеряете смысл всей затеи. Тестируйте сразу на рабочей CRM, но на тестовом менеджере, иначе сюрпризы всплывут на живых сделках.

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

Этап 4. Перенос пользователей волнами

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

Внешние номера переводятся отдельно от людей и по одному. Сначала наименее критичный номер, затем основной. В момент переключения основной линии у вас должен быть человек на связи с провайдером и человек, который сразу звонит на номер с мобильного. Переключение лучше делать в начале рабочего дня, а не в пятницу вечером: если что-то пойдёт не так, все нужные люди на месте. Проверьте у оператора, как именно меняется маршрут номера. Снижение TTL имеет смысл только если переключение действительно зависит от DNS; у SIP-провайдера маршрут может изменяться в панели или по заявке и DNS тут ни при чём.

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

План возврата и восстановление

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

Восстановление самого Asterisk — отдельная тема. Начните с конфигурации Asterisk, внутренней базы, используемых внешних баз и данных приложений. В типовой структуре конфигурация находится в /etc/asterisk, spool-данные — в /var/spool/asterisk, а внутренняя база и ключи — в /var/lib/asterisk; реальные пути могут быть переопределены в asterisk.conf. Отдельно проверьте, где лежат записи и голосовая почта в вашей конфигурации. Если используете базу для CDR, её тоже. Проверьте, что из бэкапа сервер реально поднимается на чистой машине, — а не что архив существует. Принцип тот же, что в статье серии «Обновить Asterisk с планом отката»: откат есть, только если вы его один раз прогнали. Сделайте это до переключения первой волны.

И последнее: мониторинг. Asterisk должен проверяться извне — регистрация транка, отклик сервера, место на диске под записи. Тихо упавший транк в облаке был бы проблемой оператора, а теперь это ваша проблема, и узнать о ней вы должны раньше клиентов. Это та же логика, что и с мониторингом сети: настроить один раз и обязательно проверить, что уведомление доходит до человека, а не в пустой ящик. Проверьте это тестовым отключением транка в нерабочее время. Мониторинг ставится до переезда, а не после.

Разбор: диспетчерская «Ровный маршрут», 26 мест

Возьмём условный сценарий «Ровного маршрута» из 26 рабочих мест: два внешних номера, 18 диспетчеров в двух сменах и связка с CRM. Облачная АТС не умеет направлять вызов курьера диспетчеру, который ведёт заказ, а подходящий модуль оплачивается отдельно. Если номера обслуживает отдельный SIP-провайдер, может оказаться достаточно изменить маршрут вызова — но это подтверждают у оператора до проекта. Ручной поиск заказа отнимает время, однако заявлять о точной экономии на каждом звонке без замеров нельзя.

В таком сценарии план работ выглядит так: развернуть Asterisk на подготовленной площадке, настроить endpoint в PJSIP, проверить NAT и RTP, связать CRM с маршрутом и испытать очередь диспетчеров. Сначала контур работает параллельно на тестовом номере, затем пользователи переходят несколькими группами. Срок каждой стадии зависит от доступности провайдера и готовности интеграции; само изменение маршрута может занять от нескольких минут до срока обработки заявки оператором. До завершения сверки нельзя утверждать, что входящие не терялись.

В тестовом сценарии отдельно проверьте удалённых сотрудников: домашняя сеть, NAT и SIP ALG могут влиять на сигнализацию и звук, но универсального лечения вроде «отключить ALG и включить TLS» нет. TLS шифрует SIP-сигнализацию, а для шифрования медиапотока нужна отдельная настройка SRTP; ни то ни другое само по себе не чинит маршрутизацию RTP. Облачную АТС отключают после успешной приёмки, переноса нужных записей и согласования возврата. Отчёт по пропущенным вызовам тоже оценивают по доступным данным и трудоёмкости, а не обещают как задачу на час.

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