Что согласовать с оператором перед запуском АТС на Asterisk

Перед подключением SIP-транка получите от оператора письменно: адреса и транспорт, способ аутентификации, список DID и формат номера на входе, лимит одновременных вызовов, разрешённые направления и формат CallerID на выходе. Затем проверьте оба направления по тестовым сценариям. Ниже — чек-лист и как он ложится на объекты PJSIP.

Почему приёмка транка превращается в переписку

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

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

В прошлой статье серии мы разобрали план внутренних номеров без тупиков; здесь собираем входные данные, без которых этот план не соединить с внешней сетью. Я сначала фиксирую техусловия, затем настраиваю АТС. Ответ оператора сохраняю рядом с конфигурацией: при смене тарифа или подрядчика это экономит время и помогает отличить изменение на стороне провайдера от ошибки в собственном dialplan.

Какие параметры SIP-транка запросить у оператора

Первый блок — сеть. Запросите имя или адрес SIP-сервера, порт и транспорт: UDP, TCP или TLS. Попросите перечислить адреса, с которых провайдер отправляет SIP-сигнализацию, и отдельно — как устроен путь RTP с голосом. Эти потоки могут идти по разным адресам; открывать в межсетевом экране следует только необходимые направления и диапазоны, которые подтвердил оператор. Если адреса меняются, выясните порядок и канал уведомления. Иначе изменение на стороне провайдера выглядит как внезапно сломавшиеся входящие.

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

Третий блок — голос. Запросите поддерживаемые кодеки и порядок предпочтения: универсального обязательного кодека для всех операторов нет. Согласуйте передачу DTMF: RFC 4733 (в настройках PJSIP — rfc4733), SIP INFO или in-band, если это поддерживают обе стороны. Иначе звонящий может слышать меню, но его нажатия не дойдут до IVR. Уточните поддержку T.38 только если факс действительно нужен. Если не нужен — зафиксируйте это и не тратьте время на ненужную настройку.

• Адрес SIP-сервера, порт, транспорт (UDP/TCP/TLS)
• IP-адреса оператора для сигнализации и голоса
• Способ аутентификации: регистрация или доверие по IP
• Логин, домен, формат заголовка From
• Кодеки и порядок предпочтения
• Способ передачи DTMF
• Список DID и формат номера на входе
• Лимит одновременных вызовов и поведение при превышении
• Открытые направления и формат CallerID на выходе

Как ответы оператора ложатся на объекты PJSIP

В PJSIP соединение описывается несколькими объектами. Endpoint задаёт профиль вызова, в том числе контекст и кодеки; Auth хранит параметры аутентификации; AOR описывает адреса контактов для вызова; Registration задаёт исходящую регистрацию; Identify связывает входящий SIP-запрос с endpoint по выбранному способу идентификации. Эти объекты связаны, но не взаимозаменяемы. В частности, Registration описывает исходящие REGISTER-запросы и сама по себе не настраивает обработку входящих вызовов. Ниже — учебный фрагмент, значения адресов и учётных данных замените данными оператора. `

[provider-auth]
type=auth
auth_type=userpass
username=login_from_operator
password=из_хранилища_секретов

[provider-aor]
type=aor
contact=sip:sip.example.com

[provider-reg]
type=registration
outbound_auth=provider-auth
server_uri=sip:sip.example.com
client_uri=sip:login_from_operator@sip.example.com

[provider]
type=endpoint
context=from-provider
disallow=all
allow=alaw
dtmf_mode=rfc4733
outbound_auth=provider-auth
aors=provider-aor

[provider-identify]
type=identify
endpoint=provider
match=192.0.2.10

Identify по IP полезен, когда для входящего вызова оператор отправляет запросы с известных адресов. Это не единственный возможный способ сопоставления: Asterisk может определять endpoint и по другим признакам, в зависимости от загруженных модулей и конфигурации. Поэтому не ставьте identify механически. Сначала выясните, откуда приходят запросы и как настроена идентификация; затем проверьте результат командой pjsip show endpoint provider. В выводе должна быть ожидаемая привязка Identify, если вы выбрали именно сопоставление по IP.

Для входящих задайте endpoint отдельный dialplan-контекст с нужными DID и маршрутами, а исходящие разрешайте только отдельными правилами. Это уменьшает последствия ошибочной маршрутизации и упрощает аудит. Проверить состояние исходящей регистрации можно командой pjsip show registrations, но она показывает именно регистрации и не подтверждает, что входящий вызов попадёт в нужный контекст. Для диагностики входящего вызова включите SIP-логирование в CLI командой pjsip set logger on, воспроизведите один сценарий и выключите его командой pjsip set logger off: подробный протокол может содержать идентификаторы и другие чувствительные данные.

DID, лимит каналов и формат номеров

Список DID стоит получить в том виде, в каком оператор передаёт номер во входящем вызове: с семёркой, с восьмёркой, десятью цифрами или в формате E.164 с плюсом. От этого зависит, совпадут ли шаблоны в контексте входящих. Я видел транк, где оператор отдавал номер в одном формате на основной DID и в другом — на дополнительный, купленный позже. Правило в dialplan ловило один и молча пропускало второй. Лекарство — спросить заранее и в контексте входящих принимать оба варианта или явно нормализовать.

Лимит одновременных вызовов нужно получить у оператора вместе с описанием реакции на превышение: отказ, занято или очередь на его стороне. Сверьте число каналов с реальной пиковой нагрузкой офиса. Если в тарифе два канала, а одновременно разговаривают четверо, настройка Asterisk не создаст дополнительные каналы. Зато заранее согласованный сценарий отказа позволит понять, что именно произошло, и не искать проблему в dialplan.

Формат CallerID на выходе — то, что увидит получатель. Уточните, разрешены ли разные DID для разных отделов, в каком формате их передавать и как оператор обрабатывает номер, который не закреплён за клиентом: отклоняет вызов или заменяет номер. Это лучше выяснить до запуска, иначе обратный звонок может уйти не туда. Запишите согласованный формат и проверьте его на тестовом вызове с телефона, который не подключён к вашей АТС.

Правила входящих и исходящих: что открыть и что закрыть

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

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

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

Тестовые сценарии приёмки: проверяем оба направления

Приёмка — не «позвонил на мобильный, услышал гудок». Я записываю ожидаемый результат и проверяю каждый DID на входе, каждое нужное направление на выходе, CallerID, DTMF и поведение при достижении лимита каналов. Сценарии повторяю с мобильного и городского номера, а при необходимости — в рабочее и нерабочее время. Для ограничения каналов достаточно проверить согласованный оператором порог в контролируемое окно; заранее сообщите ему о тесте, чтобы не принять штатное ограничение за неисправность. | Сценарий | Что проверить | Ожидаемо | |---|---|---| | Входящий на каждый DID | Маршрут и формат номера | Нужный контекст и маршрут | | Исходящий на нужные направления | Дозвон и CallerID | Согласованные значения | | Набор в тестовом IVR | DTMF | Выбран нужный пункт | | Достижение лимита | Ответ на следующий вызов | Сценарий из ответа оператора | | Запрещённое направление | Ограничение | Вызов не проходит |

Если вызов не проходит, включите в CLI pjsip set logger on, воспроизведите один сбой и найдите SIP-ответ и адрес второй стороны. После диагностики отключите трассировку командой pjsip set logger off; не отправляйте оператору необработанные логи, если в них остались номера или учётные данные. Если вызов устанавливается, но звука нет или слышна только одна сторона, проверяйте уже RTP-маршрут, межсетевой экран и NAT — SIP-журнал сам по себе не доказывает, что медиапоток дошёл. Ровный обрыв по таймеру может быть подсказкой, но диагноз ставят по трассировке конкретного вызова, а не по одной секунде на часах.

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

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