С ISDN PRI на SIP-транк: как мы урезали счета за исходящие и два дня боролись с кодеками

Клиент - торговая компания, 60 с лишним сотрудников, московский офис. Телефония держалась на Panasonic KX-TDA200 с двумя ISDN PRI-потоками: 60 B-каналов, вполне достаточно для нагрузки. Всё работало, никто не жаловался. Жаловались только на ежемесячный счёт от оператора.

PRI-линии - это аренда физических потоков плюс тариф за минуту. Стоимость исходящих в мобильные сети ощутимая, а у клиента продажи, менеджеры звонят много. Финансовый директор спросил прямо: можно что-то сделать?

Можно. Операторы вроде Билайн Бизнес и МТТ давно предлагают SIP-транки, которые дают тот же выход в телефонную сеть без физической аренды потоков и с другой тарифной сеткой на мобильные. Мы посчитали по биллингу за три месяца - переход должен дать примерно 30-40% экономии на исходящих. Решили пробовать.

Архитектура: Asterisk как медиатор

Panasonic трогать не хотелось - пользователи привыкли, всё настроено, номерная ёмкость устраивает. Схема получилась такая: между PBX и SIP-транком ставим Asterisk 1.6 на выделенной машине с Debian. Asterisk со стороны Panasonic говорит по SIP (АТС умеет SIP-транки), а со стороны оператора регистрируется как SIP-клиент на их шлюзе. Получается мост: Panasonic - Asterisk - оператор.

PRI-линии при этом оставляем как резерв на первое время - пока не убедимся, что SIP справляется с нагрузкой.

Где потеряли два дня

Подключить Asterisk к оператору по бумаге - дело часа. Реально получилось иначе.

Кодеки. Оператор заявил поддержку G.711 alaw и G.729. Мы настроили Asterisk с предпочтением G.711 - он не требует лицензии и не жрёт CPU на перекодировку. Первые тестовые звонки прошли, но при одновременных вызовах начался односторонний звук. Оказалось, что оператор в реальности отдавал приоритет G.729 несмотря на наши предпочтения, а у нас G.729 был прописан как fallback с настройками по умолчанию. Пришлось явно запретить всё кроме G.711 alaw на стороне транка в sip.conf:

[operator-trunk]
type=peer
disallow=all
allow=alaw

После этого оператор или договаривался на alaw, или звонок не проходил вовсе - что лучше, чем разговор с кашей в одну сторону.

NAT. Asterisk стоял за корпоративным шлюзом с NAT. Классическая проблема: SIP-сигнализация проходит, а RTP с голосом идёт не туда, потому что Asterisk в SDP-теле сообщает оператору внутренний адрес вида 10.x.x.x, который снаружи недостижим. Параметры externip и localnet в sip.conf решают это в лоб - сервер подставляет белый адрес в SDP. Но оператор дополнительно требовал, чтобы RTP-порты были пробиты на шлюзе явно, а не через стандартный диапазон. Выясняли это через их техподдержку примерно полтора дня - у них своя реализация с нестандартным поведением по симметричному RTP.

В итоге пробросили диапазон UDP 10000-20000 на машину с Asterisk и добавили nat=force_rport,comedia на секцию транка. Звук пошёл чисто в обе стороны.

Маршрутизация на Panasonic. Это уже не SIP-история, а конфигурация АТС. Нужно было так настроить таблицы маршрутизации на Panasonic, чтобы исходящие на мобильные уходили через Asterisk, а городские - могли идти и так, и так. Плюс аварийный маршрут: если Asterisk недоступен - звонок должен уйти через PRI, а не просто упасть. Это настраивается через LCR (Least Cost Routing) на KX-TDA, но чтобы разобраться в интерфейсе Panasonic, нужен их фирменный инструмент - KX-TDA Maintenance Console. Без него вслепую не залезешь.

Что получилось

Запустили в полную нагрузку через три недели после начала работ - сначала только часть исходящих, потом всё. PRI оставили в горячем резерве.

Счёт за первый полный месяц показал снижение стоимости исходящих примерно на 35% по сравнению со средним за предыдущий квартал. Это совпало с нашей предварительной оценкой. Качество звонков - пользователи не заметили разницы, что и было целью.

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

Несколько наблюдений

Согласование с оператором занимает больше времени, чем настройка Asterisk. Техподдержка SIP-операторов умеет работать с FreeSWITCH и иногда с Cisco, а вот конкретные параметры для Asterisk приходится выяснять вопрос за вопросом. Важно сразу попросить технический лист с параметрами транка - не маркетинговый буклет, а именно технику: адреса SIP-прокси, поддерживаемые кодеки, требования к NAT, ожидаемые FROM-заголовки.

G.729 - отдельная тема. Он экономит полосу, но требует лицензий на Asterisk, и это не символические деньги. При хорошем канале G.711 предпочтительнее - проще отлаживать, нет лицензионных вопросов, перекодировки нет.

Резервный PRI оставили. Не из-за недоверия к SIP, а потому что у клиента есть несколько линий, которые используются для входящих факсов и аварийной связи. Переводить это на SIP - отдельная история, пока не трогали. Как факс ведёт себя через IP-каналы, мы знаем - ненадёжно, особенно если оператор не гарантирует задержки.

Мониторинг транка. Добавили в Zabbix проверку регистрации на операторском шлюзе - asterisk -rx "sip show registry" через внешний скрипт. Если транк отвалился - уведомление за 2 минуты. Без этого первый признак проблемы - звонок, который не прошёл, а это уже неприятно.

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