Настройка Asterisk для офиса: SIP, маршрутизация и проверка звонков

SIP и RTP: два потока одного звонка

• SIP: регистрация, установление и завершение вызова, согласование параметров через SDP.
• RTP/RTCP: медиапоток и служебная информация о нём; порты могут отличаться от SIP.
• Dialplan: решает, что делать с набранным номером и откуда вызов имеет право прийти.
• Транк: связь с оператором или другой АТС. Он не равен пользовательскому внутреннему номеру.

Звонок может успешно установиться без звука. Это не повод открывать весь UDP: нужно проверить адреса SDP, диапазоны media и оба направления. И наоборот, доступность порта 5060 не доказывает наличие права платного исходящего вызова.

План офиса: адреса, номера и договорённости с оператором

example.net и внешние IP здесь документационные, а не действующий оператор. Перед подключением получите точные параметры: REGISTER или IP-auth, формат исходящего номера, разрешённый CallerID, входящий DID/Request-URI, кодеки, DTMF, число каналов, резервные узлы и лимиты расходов. У SIP и RTP оператора могут быть разные сети.

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

Шаг 1. Проверьте установленную Asterisk и модули

Для новой АТС выбирайте поддерживаемую ветку и сопровождаемый способ установки. Здесь используется 22 LTS; это выбранная основа, а не утверждение о последней версии. Актуальные сроки поддержки — в таблице Asterisk. Пакет с именем asterisk в вашей ОС не обязательно относится к 22-й ветке.

cat /etc/os-release
timedatectl status
systemctl status asterisk --no-pager
sudo asterisk -rx 'core show version'
sudo asterisk -rx 'core show settings'
sudo asterisk -rx 'module show like res_pjsip'
sudo asterisk -rx 'core show application Dial'
sudo ss -luntp

Если бинарника или нужных модулей нет, сначала завершите установку по выбранному дистрибутиву. Не добавляйте случайный install-скрипт из поисковой выдачи. Официальная документация объясняет выбор поставки; компиляция из исходников требует собственного сопровождения зависимостей и обновлений.

Проверьте реальную версию, пользователя службы, каталог конфигураций и конфликт порта. В новой схеме используем PJSIP, а не переносим настройки sip.conf/chan_sip по старому руководству. Версия GUI-панели и версия ядра Asterisk — разные вещи.

Шаг 2. Сохраните конфигурацию и ограничьте управление

stamp=$(date +%Y%m%d-%H%M%S)
sudo install -d -m 0700 "/root/asterisk-before-$stamp"
sudo cp -a /etc/asterisk "/root/asterisk-before-$stamp/"
sudo systemctl cat asterisk

В конфигурациях могут быть пароли транков и телефонов. Резервную копию хранят с ограниченным доступом, вне веб-каталога. Отдельно учитывают голосовую почту, записи, CDR/CEL, БД и данные панели, если они есть. Копия /etc не резервирует всё это автоматически.

• SSH — только через согласованный административный маршрут.
• AMI, ARI и HTTP-интерфейсы не публикуются ради базовых звонков; включаются по реальной задаче интеграции.
• Файлы конфигурации должен читать пользователь службы. Права 640 root:asterisk подходят только если такая группа действительно используется; проверьте unit.
• Не исправляйте доступ к конфигурации командой chmod777 и не выводите её целиком в общую заявку.

Endpoint, auth, AOR и transport: зачем столько объектов

• transport: где и каким протоколом АТС принимает SIP.
• endpoint: параметры участника: контекст, кодеки, DTMF, NAT и ссылки на другие объекты.
• auth: данные для проверки телефона либо аутентификации АТС у оператора.
• AOR/contact: где находится участник; contact может появляться после регистрации или задаваться статически.
• identify: как сопоставить входящий запрос с endpoint, например по сетям оператора.
• registration: исходящий REGISTER к оператору; сам по себе не заменяет остальные объекты.

Подробные связи — в руководстве PJSIP. Перепутанный auth, AOR или context может дать совершенно разные симптомы: от отказа регистрации до неверного маршрута вызова.

Идентификация, аутентификация и права: три отдельные проверки

В телефонии недостаточно одного слова «авторизация». Последовательно проверяются разные вещи:

1. Идентификация: к какому endpoint относится запрос? Для аппарата — по согласованной SIP-схеме, для транка — например, по точному identify оператора.
2. Аутентификация: подтвердил ли аппарат свои учётные данные? Для REGISTER это обычно SIP Digest с auth-объектом; для операторского IP-auth действуют другие условия.
3. Авторизация: что разрешено этому endpoint? Это context, доступные маршруты, перевод, подхват, запись, интеграции и внешние лимиты.

SIP Digest не равен шифрованию всей сигнализации и разговора. Для защиты транспортов выбирают TLS/SRTP или согласованный VPN, а алгоритмы и проверку сертификатов сверяют с возможностями конкретных аппаратов и сборки Asterisk.

CallerID, имя на дисплее и принадлежность к офисному IP не являются универсальной аутентификацией пользователя. Для подрядчиков и интеграций создают отдельные записи, секреты, сетевые ограничения и процедуру отзыва.

PJSIP подробно: как запрос получает endpoint, auth и context

PJSIP — современная SIP-подсистема Asterisk, в которой параметры разделены на связанные объекты. Она не является одним «новым sip.conf». Для рабочего проекта важно понимать направление операции, а не только копировать имена секций.

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

Endpoint и AOR: имена иногда совпадают намеренно, но типы объектов разные. Для динамического REGISTER AOR должен соответствовать user-части To URI; статический provider-aor с contact работает по другой схеме и может называться иначе. При нескольких контактах одного AOR продумайте звонок на несколько аппаратов, смену устройства, срок регистрации и отзыв доступа.

Идентификация: на сопоставление влияют загруженные identifiers и настройки их порядка. Не меняйте глобальный порядок только ради ошибки одного транка: это может изменить обработку остальных участников. У оператора используйте подтверждённые источники/согласованную схему; у телефона недостаточно доверять произвольному From. Anonymous endpoint с привилегированным контекстом недопустим.

PJSIP ACL, transport и NAT: не смешиваем механизмы

Сетевой firewall ограничивает доступ до приложения. Дополнительный endpoint ACL может ограничить источник уже в PJSIP. Например, для шаблона офисных телефонов из VLAN40 можно добавить в его endpoint-параметры:

deny=0.0.0.0/0.0.0.0
permit=10.10.40.0/255.255.255.0

Это дополнение к office-phone, не глобальное ограничение всех запросов оператора. Для телефона через VPN нужна соответствующая точная сеть/адрес в его профиле. Нельзя разрешать весь интернет в ACL из-за одного удалённого аппарата. Source ACL и ограничения адресов в заголовке Contact — разные проверки; NAT может делать Contact непохожим на наблюдаемый источник.

• bind: реальный адрес/порт слушателя. В нашем примере адрес 10.10.50.30 уже должен быть назначен ОС.
• transport: endpoint и registration ссылаются на ожидаемый UDP/TCP/TLS, а не случайный первый transport.
• force_rport: влияет на обратную доставку сигнализации; не проверяет личность и не шифрует её.
• rewrite_contact: помогает маршрутизировать запросы через наблюдаемый адрес контакта при NAT; не заменяет настройку media.
• rtp_symmetric: связано с направлением media; не является SRTP или аутентификацией звонящего.
• direct_media: определяет возможность прямого media-пути. Меняет нагрузку, запись и точки диагностики; значение no не гарантирует правильный NAT.
• TLS/SRTP: отдельная настройка transport/сертификатов и media_encryption. Поддержку и алгоритмы проверяют по версии платформы и телефонов.

Не оставляйте проверку TLS-сертификата выключенной ради успешного подключения. Защита сигнала и голоса проверяется раздельно; UDP5060 из учебного локального примера сам по себе не обеспечивает ни того, ни другого.

Чек-лист PJSIP после изменения конфигурации

sudo asterisk -rx 'module show like res_pjsip'
sudo asterisk -rx 'pjsip show identifiers'
sudo asterisk -rx 'pjsip show transports'
sudo asterisk -rx 'pjsip show endpoint 201'
sudo asterisk -rx 'pjsip show aor 201'
sudo asterisk -rx 'pjsip show contacts'
sudo asterisk -rx 'pjsip show registrations'
sudo asterisk -rx 'config show help res_pjsip endpoint named_pickup_group'

1. Endpoint загружен и ссылается на правильные auth/AOR/transport.
2. В AOR правильное число контактов, адрес/порт и ожидаемая регистрация, а не старый контакт другого аппарата.
3. Источник проходит ACL, а чужой адрес не получает право регистрации.
4. Context соответствует классу вызовов, включая подхват, перевод и IVR.
5. Transport действительно применён. Если нужна перезагрузка процесса, согласовано окно и учтены активные звонки.
6. Повторены внутренний/внешний вызов, оба направления звука, DTMF, простой и отказ запрещённому маршруту.

Не выводите секреты auth-объектов в общий журнал. Help и показ объектов подтверждают параметры, но не заменяют реальную регистрацию и разговор. Полный справочник опций используйте именно для ветки 22 и своего maintenance-релиза.

Шаг 3. Настройте два внутренних номера в pjsip.conf

На согласованной новой системе откройте sudoedit /etc/asterisk/pjsip.conf. Ниже минимальный фрагмент для двух телефонов. Предварительно сгенерируйте разные пароли в менеджере паролей, сохраните их и замените оба обозначения в угловых скобках. Это не готовые пароли для использования.

[transport-udp-office]
type=transport
protocol=udp
bind=10.10.50.30:5060
local_net=10.10.40.0/24
local_net=10.10.50.0/24

[office-phone](!)
type=endpoint
transport=transport-udp-office
context=office-internal
disallow=all
allow=alaw,ulaw
direct_media=no
dtmf_mode=rfc4733
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

[201](office-phone)
auth=auth201
aors=201

[auth201]
type=auth
auth_type=userpass
username=201
password=<GENERATED_UNIQUE_PASSWORD_201>

[201]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=60

[202](office-phone)
auth=auth202
aors=202

[auth202]
type=auth
auth_type=userpass
username=202
password=<GENERATED_UNIQUE_PASSWORD_202>

[202]
type=aor
max_contacts=1
remove_existing=yes
qualify_frequency=60

Секция office-phone с (!) — шаблон, а 201/202 наследуют общие параметры. Повтор имени [201] с разными type здесь намеренный: endpoint и AOR — разные объекты. Для входящей регистрации имя AOR должно совпадать с user-частью To URI, обычно с SIP user телефона; произвольное имя AOR без соответствующей настройки регистрации не подойдёт. На телефоне 201 задайте SIP server10.10.50.30, порт 5060, UDP, SIP user/auth user201 и его пароль; на втором —202 и другой пароль. Имена пунктов отличаются у Yealink, Grandstream, Fanvil, Snom и других производителей. Старые заводские пароли веб-интерфейсов телефонов также заменяют.

max_contacts=1 и remove_existing=yes выбраны для одного аппарата на номер: новая регистрация может заменить старый контакт. Для нескольких устройств нужен другой проект, а не общая копия одного пароля. direct_media=no оставляет АТС в медиапути для понятной диагностики; это не шифрование и не гарантия качества.

UDP-вариант подходит закрытому пилоту. Для удалённых устройств используйте согласованный VPN либо корректно спроектированные TLS/SRTP/SBC. Открывать регистрацию всех телефонов всему интернету эта инструкция не предлагает.

Шаг 4. Задайте media-диапазон и согласуйте firewall

В /etc/asterisk/rtp.conf для примера:

[general]
rtpstart=10000
rtpend=10199

Это выбранный диапазон для пилота, а не обязательное значение Asterisk. Его нужно согласовать с firewall и NAT. Диапазон портов сам по себе не обещает число одновременных разговоров: влияют топология, каналы, RTCP, кодеки и ресурсы. Пример файла есть в официальном репозитории.

• Телефоны → АТС: SIP на выбранном transport и media в диапазон АТС.
• АТС → телефоны: ответы и возможные инициируемые АТС media-потоки к фактическим портам телефонов.
• АТС ↔ оператор: только согласованные SIP/media-сети и порты.
• DNS/NTP и provisioning телефонов: отдельные разрешения по назначению.

Не копируйте RTP-диапазон АТС в destination range телефонов автоматически. Для общей сетевой схемы используйте руководство по firewall MikroTik. SIP helper/ALG на шлюзе может влиять на обмен: проверяйте поведение с вашей АТС, сохраняя возможность возврата, а не отключайте всё наугад.

Шаг 5. Создайте закрытый внутренний dialplan

В /etc/asterisk/extensions.conf добавьте отдельный контекст. Он разрешает только два точных внутренних номера:

[office-internal]
exten => 201,1,Dial(PJSIP/201,20)
 same => n,Hangup()

exten => 202,1,Dial(PJSIP/202,20)
 same => n,Hangup()

При вызове 201→202 Asterisk ищет 202 в контексте office-internal endpoint201. Dial звонит на PJSIP/202 до 20 секунд, затем управление продолжается и канал завершается. Никакой транк здесь не вызывается. Контекст не должен включать чужие широкие outbound-контексты.

Ошибка «extension not found in context» требует проверить номер и контекст, а не добавить универсальный шаблон _X. с выходом к оператору. Contexts, extensions и priorities — основа контроля прав в dialplan.

Шаг 6. Примените изменения и проверьте регистрацию

Сначала убедитесь, что изменяется стенд и нет активных рабочих разговоров. Transport-настройки PJSIP могут требовать полного перезапуска; reload не является универсальным способом применить всё.

sudo asterisk -rx 'core show channels count'
sudo asterisk -rx 'dialplan reload'
sudo asterisk -rx 'pjsip reload'
sudo asterisk -rx 'pjsip show transports'
sudo asterisk -rx 'pjsip show endpoints'
sudo asterisk -rx 'pjsip show aors'
sudo asterisk -rx 'pjsip show contacts'
sudo asterisk -rx 'dialplan show office-internal'
sudo journalctl -u asterisk --since '-10 min' --no-pager

Если менялся transport и ваша версия требует restart, выполните его только в согласованное окно после проверки сеансов: sudo systemctl restart asterisk. Затем повторите проверки. Для иной схемы установки проверьте фактическую службу и каталог.

Ожидается загрузка объектов без ошибок, корректные transport/AOR и contact телефона после его регистрации. Наличие endpoint ещё не означает, что аппарат зарегистрировался; contact сам по себе не доказывает звук. Не выводите auth-объекты с секретами в общий лог ради отчёта.

Шаг 7. Проверьте внутренний разговор в обе стороны

1. С201 наберите 202, дождитесь ответа, проверьте речь в обе стороны.
2. Повторите 202→201 и завершите вызов по очереди с каждой стороны.
3. Проверьте занятость, отсутствие ответа и отключённый аппарат.
4. Проверьте повторный разговор после простоя: NAT/keepalive могут менять поведение.
5. Зафиксируйте время и канал; это облегчит сопоставление с журналом.

До успешной внутренней проверки подключать платный транк для диагностики не требуется. Команды контроля:

sudo asterisk -rx 'core show channels concise'
sudo asterisk -rx 'pjsip show endpoint 201'
sudo asterisk -rx 'pjsip show endpoint 202'
sudo asterisk -rx 'pjsip show contacts'

Не используйте автоматически originate как замену осмысленному тесту с двумя участниками. Автоматический ответ/отбой может подтвердить только часть маршрута, но не качество речи.

Шаг 8. Подготовьте транк оператора: объекты PJSIP

Следующий фрагмент адаптируют по договору оператора. Он не работает с example.net и не является универсальной настройкой любого SIP-провайдера. Пароль транка — выданный или согласованно заменённый секрет оператора; произвольная локальная генерация не изменит пароль на его стороне.

Пример использует REGISTER, исходящую аутентификацию и identify по подтверждённому IP оператора. Для IP-auth без регистрации набор другой.

[provider]
type=endpoint
transport=transport-udp-office
context=from-provider
disallow=all
allow=alaw
outbound_auth=provider-auth
aors=provider-aor
direct_media=no
dtmf_mode=rfc4733
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

[provider-auth]
type=auth
auth_type=userpass
username=<PROVIDER_LOGIN>
password=<PROVIDER_SECRET>

[provider-aor]
type=aor
contact=sip:sip.example.net:5060
qualify_frequency=60

[provider-identify]
type=identify
endpoint=provider
match=198.51.100.10/32

[provider-registration]
type=registration
transport=transport-udp-office
outbound_auth=provider-auth
server_uri=sip:sip.example.net
client_uri=sip:<PROVIDER_LOGIN>@sip.example.net
contact_user=inbound
retry_interval=60
forbidden_retry_interval=600
expiration=3600

Registrar, proxy, auth username, from_user/from_domain и CallerID могут различаться. Если оператор требует их, добавьте именно согласованные значения. Все реальные резервные SIP-адреса должны корректно сопоставляться с endpoint и проходить firewall. Сеть media не добавляют в identify просто потому, что из неё приходит RTP.

registration и endpoint не связываются автоматически только похожими именами. Здесь входящий запрос идентифицируется отдельным provider-identify. Проверяйте реальный сценарий; для DNS/SRV, нескольких прокси и другой аутентификации нужна адаптация. Параметры — в документации res_pjsip22 и outbound registration22.

Шаг 9. Маршрутизируйте входящий вызов в ограниченный контекст

В примере оператор направляет вызов на contact_user=inbound. Проверьте фактический Request-URI: некоторые операторы присылают DID вместо этого имени. Тогда создайте маршрут для точного согласованного DID, а не разрешайте всё подряд.

[from-provider]
exten => inbound,1,NoOp(Inbound provider call)
 same => n,Dial(PJSIP/201&PJSIP/202,25)
 same => n,Hangup()

Оба аппарата звонят одновременно до 25 секунд; после ответа одного работа второго вызова определяется Dial. Этот контекст не включает исходящий контекст и не предлагает вызывающему набрать произвольный платный номер. CallerID входящего звонка нельзя считать доказательством личности.

Если нужен IVR, очередь, рабочее время, голосовая почта или резервный номер, добавляйте их отдельными сценариями с явными правами и проверкой отказов. Переадресация на внешний номер тоже расходует операторские ресурсы и требует контроля.

Шаг 10. Выдайте право исходящего вызова отдельно

Телефоны 201 и 202 пока находятся в office-internal и не имеют этого права. Ниже отдельный контекст для согласованного класса пользователей. Внешний префикс 9 удаляется, далее отправляется номер вида 7+10 цифр:

[office-with-outbound]
include => office-internal

exten => _97XXXXXXXXXX,1,NoOp(Authorized office outbound)
 same => n,Dial(PJSIP/${EXTEN:1}@provider,60)
 same => n,Hangup()

Для разрешённого endpoint изменяют context на office-with-outbound после согласования. Входящий provider остаётся в from-provider. Этот шаблон задаёт формат номера, а не доказательство безопасного тарифа: внутри диапазона могут быть нежелательные направления.

• Задайте разрешённые направления/классы, запрет платных и международных сценариев по задаче.
• Согласуйте CallerID и нормализацию номера с оператором.
• На стороне оператора включите лимиты расходов/каналов и уведомления, если доступны.
• Проверьте переадресацию, перевод и доступ интеграций: они не должны обходить класс вызова.
• Не выдавайте произвольному входящему SIP-запросу outbound-контекст.

Финальный набор маршрутов, включая экстренные и короткие номера, согласуется отдельно. Не подключайте сотрудников к учебному ограниченному шаблону вместо действующего телефонного плана.

Группа вызова, группа подхвата и очередь: что выбрать

• Группа вызова (ring group): один номер вызывает несколько аппаратов одновременно либо по очереди. Для небольшого отдела часто достаточно Dial.
• Группа подхвата (pickup group): определяет, кто может забрать уже звонящий чужой вызов. Она сама не организует обзвон отдела.
• Очередь: удерживает вызывающих, распределяет обращения между участниками и предоставляет состояние ожидания/агентов.
• IVR: проигрывает меню, принимает DTMF и выбирает разрешённый маршрут. Это не аутентификация по одному факту нажатия цифры.

Дополнения ниже — модули для адаптации. Существующие context/endpoint не дублируют вслепую: сначала выберите окончательную схему, затем замените нужный блок. Базовые номера 201/202 и параметры транка сохраняются. Новые функции принимают отдельно до включения рабочего DID.

Группа вызова: одновременный и последовательный обзвон

Добавьте отдельный контекст. Номер 600 сначала звонит 201, затем 202 при отсутствии успешного разговора;601 звонит обоим сразу:

[office-rings]
exten => 600,1,Dial(PJSIP/201,15)
 same => n,GotoIf($["${DIALSTATUS}"="ANSWER"]?done)
 same => n,Dial(PJSIP/202,20)
 same => n(done),Hangup()

exten => 601,1,Dial(PJSIP/201&PJSIP/202,25)
 same => n,Hangup()

Для набора 600/601 с телефонов добавьте include => office-rings в существующий office-internal, если это разрешено их роли. Входящий IVR может переходить в эти точные номера через Goto, не включая весь внутренний контекст.

В последовательном примере разные неуспешные исходы переходят на второй аппарат. Для рабочего маршрута отдельно решите, что делать при BUSY, NOANSWER, CHANUNAVAIL и отказе сотрудника. Не обещайте одинаковую обработку Busy всем телефонам без проверки их ответа.

• Убедитесь, что после ответа одного аппарат другого перестаёт звонить.
• Проверьте отключённый аппарат, DND, занятого сотрудника и отбой вызывающего во время дозвона.
• Назначьте конечное действие при неответе: резервный отдел, голосовая почта либо корректное завершение.
• Не превращайте отсутствие ответа в бесконечную петлю между группами.

Группа подхвата: кто имеет право ответить за коллегу

В PJSIP есть named_call_group и named_pickup_group. Первая задаёт группу звонящего канала, вторая — группы, звонки которых участник может подхватывать. Это не список участников ring group.

Замените только endpoint-блоки 201/202 на следующие, сохранив отдельные auth и AOR из базовой схемы:

[201](office-phone)
auth=auth201
aors=201
named_call_group=sales
named_pickup_group=sales

[202](office-phone)
auth=auth202
aors=202
named_call_group=sales
named_pickup_group=sales

В существующий office-internal добавьте код группового подхвата:

exten => *8,1,Pickup()
 same => n,Hangup()

С аппарата 202 наберите *8, пока звонит 201, и затем проверьте обратный сценарий. Подхватывается подходящий звонящий канал; это не подключение к уже начатому разговору. При нескольких одновременных звонках проверьте фактический выбор и удобство процесса.

Вызов Pickup(201@...) с прямым указанием цели — другой механизм: нельзя считать, что любые directed-pickup маршруты автоматически соблюдают ту же политику групп. Не публикуйте универсальный подхват любого номера; границы отделов проверяют отрицательным тестом. Подробная семантика — в Pickup, параметры endpoint — в руководстве PJSIP22.

Очередь отдела: ожидание, стратегия и отсутствие сотрудников

Для потока входящих обращений вместо цепочки Dial можно использовать очередь sales. Фрагмент /etc/asterisk/queues.conf для двух статических участников:

[sales]
strategy=rrmemory
timeout=15
retry=3
wrapuptime=5
maxlen=10
joinempty=no
leavewhenempty=yes
ringinuse=no
member => PJSIP/201
member => PJSIP/202

rrmemory распределяет попытки с учётом предыдущего положения; это не гарантия равной нагрузки во всех обстоятельствах. Параметры empty/unavailable зависят от состояний участников и выбранных условий — проверьте их на своей сборке. Для входа и пауз агентов понадобится отдельная политика, а не общая команда с полными AMI-правами.

Добавьте контекст точки входа:

[office-queue]
exten => 650,1,Answer()
 same => n,Queue(sales,,,,90)
 same => n,NoOp(Queue result ${QUEUESTATUS})
 same => n,Goto(ivr-failed,s,1)

90 — предел ожидания в этом примере, а не время разговора после ответа. При возврате из Queue обработайте TIMEOUT, FULL, JOINEMPTY/LEAVEEMPTY и другие фактические статусы. Контекст ivr-failed задан ниже; для production он должен вести в согласованный конечный сценарий. Прямой доступ к 650 телефонам выдавайте только при необходимости.

Проверьте модуль app_queue, загрузку очереди, доступность музыки ожидания и состояние участников. Контроль: queue show sales. Динамические агенты, приоритеты, SLA и статистика требуют отдельной настройки. Описание Queue и образец queues.conf22 помогают сверить параметры.

IVR: меню, DTMF, неверный ввод и тайм-аут

Подготовьте собственную запись office-main в поддерживаемом формате в каталоге sounds/custom, доступном службе. Текст должен соответствовать маршрутам:0 — секретарь,1 — группа сотрудников,2 — очередь. Файл указывается без расширения. Следующий IVR ограничивает число попыток тремя:

[office-ivr]
exten => s,1,Answer()
 same => n,Set(IVR_TRIES=0)
 same => n(menu),Set(IVR_TRIES=$[${IVR_TRIES}+1])
 same => n,GotoIf($[${IVR_TRIES}>3]?ivr-failed,s,1)
 same => n,Background(custom/office-main)
 same => n,WaitExten(5)
 same => n,Goto(ivr-failed,s,1)

exten => 0,1,Goto(office-rings,600,1)
exten => 1,1,Goto(office-rings,601,1)
exten => 2,1,Goto(office-queue,650,1)

exten => i,1,Playback(pbx-invalid)
 same => n,Goto(s,menu)
exten => t,1,Goto(s,menu)

[ivr-failed]
exten => s,1,Hangup()

Background принимает цифры во время проигрывания, Playback используется здесь только для сообщения об ошибке, WaitExten даёт время после меню. i обрабатывает неподходящий ввод, t — отсутствие ввода. Повтор ведёт к метке menu, поэтому счётчик не обнуляется. Пример не содержит include исходящего контекста и не разрешает произвольный внутренний набор.

Проверьте реальное DTMF от оператора и аппаратов: rfc4733, SIP INFO и in-band — разные методы. Не считайте нажатие цифры в логах достаточным, если меню фактически не переключается. Порядок Background/WaitExten описан в официальном руководстве IVR.

ivr-failed намеренно завершает учебный вызов. Для компании выберите человеческий сценарий: дежурный, сообщение о нерабочем времени, voicemail или иной резерв. Не оставляйте внезапный Hangup как случайное поведение рабочего номера.

Запись разговоров через MixMonitor: включение и файлы

Сначала согласуйте назначение записи, уведомление участников, доступ, срок хранения и удаление по применимым требованиям и правилам компании. Техническое включение записи не определяет эти условия автоматически.

Создайте каталог для фактического пользователя службы; пример ниже подходит только если это asterisk:

sudo install -d -o asterisk -g asterisk -m 0750 /var/spool/asterisk/monitor/office
sudo asterisk -rx 'core show application MixMonitor'
sudo asterisk -rx 'core show application StopMixMonitor'

Для повторного использования добавьте подпрограмму:

[record-call]
exten => s,1,MixMonitor(/var/spool/asterisk/monitor/office/${UNIQUEID}.wav,b)
 same => n,Return()

Имя строится из внутреннего UNIQUEID, а не из произвольного CallerID или строки CRM. Не передавайте непроверенные данные в пути, параметры post-processing, System/SHELL или команды конвертации. Опция b записывает аудио, когда канал находится в мосту; меню/ожидание при такой схеме может не попасть в запись.

MixMonitor сам не отвечает на вызов. В собранном входящем маршруте ниже сначала выполняется Answer, затем Gosub(record-call,s,1). Если файл нужен для обработки до завершения dialplan, используйте StopMixMonitor перед чтением/отправкой файла. После перевода, подхвата и перехода между каналами отдельно проверяйте полноту и отсутствие дублей: запись одного канала не гарантирует автоматически запись всей сложной цепочки.

Подробности — в MixMonitor22. Контроль записи — фактическое прослушивание разрешённого тестового разговора с двух сторон, а не один нулевой WAV на диске.

Хранение записей: место, права и связь с карточкой клиента

• Объём: считать по фактическому формату, длительности и числу каналов, а не только по числу сотрудников.
• Доступ: отдельные роли просмотра и выгрузки, журнал скачиваний, отсутствие прямой публичной ссылки на каталог monitor.
• Срок: автоматическая ротация с исключениями по согласованному процессу; резервная копия тоже входит в жизненный цикл данных.
• CRM: привязка по внутреннему идентификатору/событиям вызова; номер CallerID не является уникальным ключом.
• Передача: защищённый сервис выдачи, а не SMB-доступ ко всему диску АТС или бессрочный общий URL.
• Наблюдение: место, ошибки записи, очередь выгрузки, права и восстановление.

Пример расчёта: PCM16bit,8 кГц,моно — около 16КБ/с, или 57,6МБ/час без существенных накладных расходов контейнера.100 часов — примерно 5,76ГБ в десятичных единицах, до резервирования и копий. Стерео, другая частота и компрессия меняют результат; проверьте реальные файлы вашей системы.

Собираем входящий маршрут: запись → IVR → отдел

После проверки модулей замените прежний from-provider только выбранным вариантом. Не оставляйте две конкурирующие версии одного inbound-маршрута:

[from-provider]
exten => inbound,1,Answer()
 same => n,Gosub(record-call,s,1)
 same => n,Goto(office-ivr,s,1)

Если запись пока не согласована, уберите Gosub и не создавайте её под видом обязательного шага. Если оператор передаёт DID вместо inbound, используйте точный согласованный DID. Контексты office-ivr,office-rings,office-queue,ivr-failed и подпрограмма record-call должны существовать в принятой версии проекта.

Answer перед меню означает ответ вызывающему на уровне сигнализации; тарификация может начаться до соединения с сотрудником. Если нужен early media без ответа, проектируйте Progress/183 и поддержку оператора отдельно. Не меняйте Answer на Ringing только ради обещания «бесплатного ожидания».

Шаг 11. Настройте NAT и внешние media-адреса по реальной топологии

Если АТС находится за NAT, к transport могут понадобиться параметры внешнего адреса. Ниже дополнение к уже существующему transport, а не второй transport с тем же именем:

local_net=10.10.40.0/24
local_net=10.10.50.0/24
external_signaling_address=203.0.113.10
external_media_address=203.0.113.10

Адрес замените своим. Укажите все фактически локальные подсети, иначе АТС может подставлять внешний адрес в локальном разговоре или внутренний — в разговоре с оператором. При динамическом адресе, двойном NAT, CGNAT или SBC схему проектируют отдельно; статический пример её не исправляет.

• Пробрасывайте только требуемый SIP-транспорт и media-диапазон к АТС, ограничивая источники оператора где возможно.
• Учитывайте разные сети SIP/RTP, резервные узлы и инициируемые media-потоки.
• Проверьте symmetric RTP, rport и rewrite_contact вместе с фактическим NAT, а не как магический набор опций.
• Согласуйте VPN для удалённых телефонов; не расширяйте внешний SIP до всего интернета ради одного сотрудника.

Руководство PJSIP NAT объясняет отдельную роль local_net и внешних адресов. После изменения transport повторите согласованный порядок применения и проверки.

Шаг 12. Проверьте транк, входящий и исходящий звонок

sudo asterisk -rx 'pjsip show registrations'
sudo asterisk -rx 'pjsip show endpoint provider'
sudo asterisk -rx 'pjsip show aor provider-aor'
sudo asterisk -rx 'dialplan show from-provider'
sudo asterisk -rx 'dialplan show office-with-outbound'
sudo asterisk -rx 'core show channels count'

Registered подтверждает регистрацию там, где она предусмотрена, но не весь вызов. Для IP-auth отсутствие registration-объекта может быть нормой. Выполните согласованный короткий тест на разрешённое направление и проверьте:

1. Правильный номер назначения и исходящий CallerID.
2. Ответ и речь в обе стороны.
3. Отбой с каждой стороны, повторный вызов и разговор после простоя.
4. Входящий вызов на точный DID, занятость и отсутствие ответа.
5. DTMF в согласованном IVR, удержание и перевод.
6. Отказ внутреннему номеру без исходящего права и недопустимому направлению.

Отдельно сверьте учёт вызова у оператора и локальный журнал. Тест может тарифицироваться по договору; наличие локального CDR не гарантирует правильность счёта оператора.

Если не работает: диагностика от регистрации до media

Для короткой диагностики на согласованном стенде можно включить SIP logger на время одного сценария и обязательно выключить:

sudo asterisk -rx 'pjsip set logger on'
# Один согласованный тест, затем:
sudo asterisk -rx 'pjsip set logger off'
sudo asterisk -rx 'core show help rtp set debug'
sudo asterisk -rx 'rtp set debug off'

SIP-трасса содержит номера, адреса, идентификаторы и данные аутентификации, а media-захват может содержать разговор. Храните материалы ограниченно, удаляйте секреты перед передачей. Не оставляйте подробный debug включённым на длительный срок. sngrep/Wireshark полезны для анализа разрешённого захвата, но зашифрованный SIP/TLS не становится открытым текстом только из-за запуска анализатора.

Разбор ошибок — в PJSIP Troubleshooting Guide. Используйте точное время, Call-ID и путь одного тестового вызова, а не огромную несвязанную выгрузку журналов.

Пути обхода ограничений: что проверять при защите

Проверяем не только прямой набор с телефона. Лишний исходящий доступ может появиться через соседние функции даже при аккуратном основном контексте:

1. Входящий контекст: нет include внешних маршрутов, произвольного Goto по данным клиента или общего catch-all с транком.
2. IVR: доступны только объявленные пункты; неверный ввод и тайм-аут не выводят в привилегированный контекст.
3. Перевод/переадресация: SIP REFER, attended transfer и пользовательские follow-me проверяются по тем же классам доступа.
4. Подхват: сотрудник не забирает звонки другого отдела через универсальный directed Pickup.
5. CRM/AMI/ARI: событие «кликнуть позвонить» не должно разрешать интеграции произвольный номер, endpoint, context или переменные.
6. AGI и shell: не используются внешние номера и имена как команды ОС; внешнему сервису не выдаются полномочия пользователя root.
7. Call files: право записи в spool/outgoing ограничено, иначе оно становится правом инициировать вызовы.
8. Учётные данные: скомпрометированный телефон не делит секрет с транком, а секрет CRM не открывает управление всей АТС.

Результат защиты подтверждают отрицательные тесты на согласованном стенде: запрещённый маршрут остаётся запрещённым при переводе и запросе интеграции. Это не инструкция по эксплуатации уязвимостей и не утверждение о проверенном production-инциденте.

Перевод, парковка, голосовая почта и конференции

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

• Blind/attended transfer: перевод без консультации и с предварительным разговором. Проверяются кнопки аппарата, SIP REFER и политика endpoint; allow_transfer относится к REFER, а DTMF-функции Dial — другой путь.
• Парковка: отдельные слоты, права забрать вызов, тайм-аут возврата и защита от утечки разговора соседнему отделу.
• Voicemail: собственные PIN, ограничение прослушивания, доставка уведомлений, ёмкость и политика хранения.
• Конференции: организатор/участник, доступ извне, PIN/модерация, запись и отсутствие нежелательного подключения.
• BLF/присутствие: кто видит состояние коллег, как это связано с hints/subscriptions и клавишами телефона.

Не включайте все Dial options t/T и функции записи всем участникам «на всякий случай». Если endpoint не должен инициировать SIP REFER, соответствующее allow_transfer ограничивают и затем проверяют нужные законные сценарии. Базовая инструкция не развёртывает полноценную конференц-платформу или voicemail: это отдельные модули проекта.

AGI, AMI, ARI и CTI: разные способы связать АТС с бизнесом

Практический сценарий CRM: пришло событие звонка → сервис сопоставил нормализованный номер с клиентом → показал карточку → после завершения связал CDR/CEL и разрешённую запись. Дубликаты событий и переводы требуют корректной корреляции; одного CallerID для этого недостаточно.

Для 1С нужен конкретный модуль/расширение или промежуточный сервис, права на методы и согласование версии конфигурации. Наличие Asterisk не означает встроенную готовую интеграцию любой 1С с любой CRM. Секрет АТС нельзя хранить в коде пользовательской формы или отдавать браузеру.

Описание интерфейсов: AGI, AMI, ARI. Подбирайте библиотеку по поддерживаемой версии, а не по возрасту найденного примера.

AMI и привилегии интеграции: сначала только нужные события

Если локальному CRM-адаптеру нужны лишь события вызовов, не выдавайте ему read/write=all. Пример отдельного manager.conf включает AMI только на loopback; секрет заменяется своим генерируемым значением. Не применяйте поверх существующей панели без инвентаризации её пользователей.

[general]
enabled=yes
bindaddr=127.0.0.1
port=5038

[crm-events]
secret=<GENERATED_UNIQUE_AMI_SECRET>
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255
read=call
write=

Пустое write здесь намеренно не выдаёт управляющие классы. Даже события call содержат закрытую информацию, поэтому доступ ограничен назначением адаптера. Сверьте эффективные права и события с образцом manager.conf22. Для click-to-call создаётся другой ограниченный контракт и проверка направлений; просто добавить все права этому же аккаунту неправильно.

• Удалённый адаптер подключают через защищённый доверенный маршрут, с точным сетевым ACL и отдельной аутентификацией.
• Входящие параметры интеграции валидируются: вызывающий сотрудник, его endpoint, номер назначения и разрешённый класс.
• Не разрешайте произвольные context, channel variable и команды ОС из внешнего запроса.
• Сохраняйте безопасное поведение при потере связи, повторных запросах и недоступности CRM.

Для AGI/FastAGI задайте время ожидания и fallback в обычную очередь, не оставляйте клиента в тишине при зависшем API. Для ARI требуются аутентификация REST/WebSocket и обработка событий после Stasis; включение HTTP-сервера не создаёт готового приложения.

Настройку live_dangerously не включают ради устаревшего коннектора. Официальное описание привилегированных dialplan-функций объясняет, почему чтение/запись переменных через внешний интерфейс может иметь последствия шире ожидаемого.

Старые интеграции: что проверять перед переносом

• chan_sip: старые sip.conf/команды sip show peers не переносятся механически в PJSIP22. Сопоставляют endpoint/auth/AOR/identify, NAT и контексты.
• Старый Asterisk GUI: интерфейс управления и ядро АТС — разные продукты; сгенерированные файлы редактируются только поддерживаемым способом.
• AGI/PHP/Python-коннектор: поддержка интерпретатора, права запуска, обработка ввода, тайм-ауты и поддерживаемые команды AGI.
• AMI-коннектор: используемые actions/events, изменения форматов, принцип минимальных прав, повторное подключение и отсутствие дублирующих исходящих.
• TAPI/CTI-драйвер: обычно отдельный адаптер; нужна проверка совместимости ОС, клиента, лицензирования и схемы авторизации. Это не универсальная встроенная возможность ядра.
• Call files / spool: очередь заданий на вызов может дублировать платные операции при неправильном повторе; контролируйте создание, права и идемпотентность интеграции.
• SQL-отчёты: прямое изменение служебной БД в обход API не становится безопасным лишь потому, что старый скрипт так работал.

Перед заменой сохраните перечень реальных зависимостей: CRM,1С,операторские API,отчётность,записи,очереди,подхват и настройки телефонов. Затем повторите те же сценарии на новой схеме; успешная регистрация не является приёмкой переноса.

Проверки новых функций: положительные и отрицательные

1. Ring group: одновременный/последовательный вызов, занятость, неответ, отбой и резерв.
2. Pickup: разрешённый коллега забирает звонящий вызов; чужой отдел не получает такой доступ.
3. Queue: агент свободен/занят/на паузе/недоступен, очередь полна, все вышли, лимит ожидания и конечный маршрут.
4. IVR: каждая цифра, ввод во время приветствия, неверная цифра, молчание, три попытки, отсутствие аудиофайла и DTMF от оператора.
5. Запись: обе стороны, длительность, перевод и подхват, отсутствие дублей, права чтения, выдача через CRM и истечение срока.
6. Права: внешний вызывающий не получает исходящий маршрут через IVR, REFER или интеграцию.
7. CRM: входящий/исходящий, повторное событие, перевод, недоступность API, повторное соединение и отзыв секрета.

sudo asterisk -rx 'core show application Pickup'
sudo asterisk -rx 'core show application MixMonitor'
sudo asterisk -rx 'core show application Queue'
sudo asterisk -rx 'queue show sales'
sudo asterisk -rx 'dialplan show office-ivr'
sudo asterisk -rx 'dialplan show from-provider'
sudo asterisk -rx 'manager show users'

Наличие команды или объекта не доказывает выполнение сценария. В этой статье описана процедура; реальные подхваты, записи, звонки через IVR и запросы CRM при подготовке не выполнялись.

Защита от телефонного мошенничества и лишнего доступа

• Уникальный генерируемый пароль на номер; транк хранится отдельно и не используется на телефонах.
• Ограничение SIP-источников на firewall и точная идентификация оператора; отсутствие анонимного outbound-доступа.
• Разные dialplan-контексты для внутренних пользователей, привилегированных исходящих и оператора.
• Ограничение расходов/направлений, контроль необычного числа вызовов и ночной активности.
• VPN либо спроектированные TLS/SRTP для удалённых аппаратов; TLS защищает сигнализацию, SRTP — media.
• Ограниченные AMI/ARI/CRM-аккаунты. Интеграция может инициировать вызовы, поэтому её права требуют отдельной проверки.
• Обновления АТС и прошивок телефонов, закрытые provisioning-файлы, управляемый доступ подрядчиков.
• Fail2ban и автоматические списки — дополнение. Они не заменяют правильные контексты и лимиты оператора, могут ошибочно заблокировать NAT-адрес офиса.

Записи разговоров, их доступ, хранение и удаление определяют по принятой политике и применимым требованиям. Исходный минимальный пример запись не включает; ниже добавлен отдельный модуль MixMonitor с правилами доступа к файлам. Не размещайте записи и конфигурации в публичном веб-каталоге.

Кодеки, каналы, QoS и ресурсы: как считать без обещаний

Число внутренних номеров не равно числу одновременных разговоров. Сначала оцените пиковые входящие/исходящие, очереди, конференции, запись и транскодирование. Лицензии/каналы оператора и ресурсы вашей ВМ — отдельные ограничения.

• G.711 имеет 64 кбит/с звуковой нагрузки на направление, но IP/UDP/RTP, Ethernet и VPN добавляют накладные расходы. Канал считают с запасом в обе стороны.
• Транскодирование повышает CPU-нагрузку; согласование одного кодека уменьшает лишние преобразования.
• Запись и хранение разговоров требуют диска, ротации и отдельного расчёта срока хранения.
• DSCP и очереди помогают при конкуренции за канал, если метки и доверие согласованы на всём пути. Они не исправляют плохое радио или перегруженного провайдера.
• Для ВМ проверьте CPU ready/steal, задержки хранения и сетевые потери. Не оценивайте голос только по среднему CPU.

sudo asterisk -rx 'core show channels count'
sudo asterisk -rx 'core show codecs audio'
sudo asterisk -rx 'core show translation'
df -h

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

Журналы, мониторинг, копии и возврат

Наблюдайте не только процесс asterisk, но и регистрации, доступность оператора, ошибки вызовов, число каналов, качество media и место под данными. Сигнал «служба запущена» не доказывает, что клиент дозвонится.

• CDR: сведения о вызовах; конкретные поля и полнота зависят от конфигурации/backend.
• CEL: более подробные события каналов для восстановления сложного пути, переводов и мостов.
• Журнал/Call-ID: диагностика SIP и сопоставление одного сценария.
• Резервная копия: конфигурация, секреты, данные, БД и голосовые файлы по фактической установке.

Материалы по CDR и CEL описывают разные уровни учёта. Ни один журнал не следует выдавать за доказательство качества речи без соответствующих измерений.

Перед обновлением сохраняйте версии, конфигурации и данные, проверяйте совместимость модулей. Возврат старого каталога /etc не откатывает изменения пакетов и БД панели. Восстановление репетируют в изолированной среде, не подключая копию к рабочему транку: две АТС с одними регистрационными данными могут мешать друг другу.

Паспорт АТС и протокол проверки звонков

Внедрение телефонии и сопровождение офисной сети

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