Своих героев надо знать в лицо

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

я знаю только деда )

не оверквотишь ли ты?

Динамический диалплан - ну например есть у вас пользователи сервиса, которые могут через какой нибудь интерфейс создать дерево IVR, а вам нужно чтобы это дерево у вас в диалплан преобразовывалось на лету
Статический соответственно - например когда вы для колл-центра настроили один раз дерево и оно у вас так работает пол года, пока им не понадобится что то поменять там
Звонки генерировать очень по разному, сказал что через ами, потому что сам делал авто-отправку звонков и получение информацию о событиях через AMI, а диалпланы у меня в AGI обрабатывались. Тут на самом деле куча разных применений
Ну про примитивы - имеется в виду та особенность ARI, что встроенные приложения которые есть в астере, в ARI нужно реализовывать самому, по этой теме есть куча статей и докладов, которые можно поглядеть и почитать

Спасибо. Полезная информация.

Добрый. Это встроенная утилита в операционку (Deepin Screen Recording) Но вам не обязательно ставить Deepin только из-за этой программы. Есть очень хорошая прога (flameshot), которая по функционалу даже больше, чем DSR.
https://www.youtube.com/watch?v=ryEZjzHO7qw

Про ARI я слышал что свои приложения делать, но вот кучи информации по этому поводу не находил((

ARI - интерфейс для разработчиков в Asterisk

Предлагаем ознакомиться с видео, которое затрагивает возможности создания более гибких приложений телефонии, привлекая к их созданию разработчиков.

Будут затронуты:
- история и преимущества ARI
- области применения
- функционал и ограничения методов
- антипатерны применения ARI
- вопросы масштабирования

Для сравнения разберем различные интерфейсы (AGI/AMI) и платформы

Будет наглядно продемонстрирована работа простых приложений, получающих лучшую эффективность от использования ARI. Вам будут доступны ссылки, примера интересных проектов, использующих ARI.

Все это и многие другие важных аспекты использования ARI вы найдете по ссылке: https://youtu.be/gSI8vYpVVg4

Открыл видео. Вижу уже смотрел и видимо на 53 минуте уснул)

Вопрос реально трудозатрат: на реализацию и на поддержку потом. Если делать на голом диалплане как умею это долго и потом поддерживать сложно.
Я бы хотел упор сделать все равно на разделении всего и взаимодействии по сети, что-то типа микросервисной модели. Типа есть какой-то дефолтный контейнер с астером, он запускается с примонтированными конфигами, в которых минимум настроек и коннектится по сети через FastAGI на адрес, на котором работает контейнер с тупым TCP-балансировщиком (например, HAproxy и тоже элементарный конфиг и дефолтный контейнер), этот балансировщик с помощью service-discovery находит работающий и "здоровый" контейнер(ы) с моим приложением и пересылает сетевые запросы в него. Если приложение перестаёт работать, то service-discovery или те же health-check в Haproxy моментально узнают об этом и HAproxy переключается на другой живой контейнер с моим приложением.
Соответственно сервисы с базой, хранилищем для файлов и т.п. тоже реплицированы.
Звонки тоже можно кстати балансировать через haproxy на несколько контейнеров с астером.

Но опять же я не углублялся в AMI или ARI, возможно с ними будет проще это реализовать

У вас сколько пользователей, чтобы городить все это?

Если совсем грубо говоря, там call центр на 500 агентов. Но работает в разных странах мира находящихся на большом удалении. Поэтому и нужна распределенная система

А есть данные по существующей нагрузке?

Точных данных нет. Может доходить до 2000 в пики

основная нагрузка это пока европа. Но там система растет и в других направлениях планы по расширению. Поэтому и думаем с заделом на будущее.

Эх где бы найти в сутках дополнительно ещё 6 часов  для изучения всего нужного (

Перефразирую. К примеру мой сервер:
CPU: Intel(R) Xeon(R) E-2124 CPU @ 3.30GHz (4 core)
MEM: MemTotal:       32658300 kB
LAN: 1Gbps
На нагрузочном тесте показал 3790 параллельных вызовов при 70% загрузки ЦПУ. У вас же один агент способен в один конкретный промежуток времени вести диалог с одним клиентом. Это 500 вызовов. Ну, допустим, еще по 1 клиенту у каждого агента в ожидании. Итого 1000. Один сервер легко потянет все ваши хотелки. Исключение, конечно, может быть  в том случае, если агенты до вашей АТС имеют завышенное время отклика. (Ну скажем Куба с их спутниковым инетом) Тогда, конечно, есть смысл ставить отдельную АТС на их территории для обслуживания местного населения.

И так. Полагаю, вам будет достаточно двух серверов в режиме мастер-слейв.

Если же хотите экзотики, то смотрите в сторону Kamailio, как балансировцик, маршрутизатор и сервер регистрации, с подлюченными к нему астерисками в требуемом количестве. Где-то видел на опеннет сию схему. Сейчас поищу.