asterisk.ru

Из того что я понял лично, астериск в мире виртуальных атсок - бульдозер, если есть варик пересадить всех на велосипеды полегче было бы круто)

Астериск - это куча деталей и куча инструментов. а собрать из них бульдозер или велосипед - решает автор продукта на основе астера

для начала определить/посчитать/спрогнозировать кол-во активных пользователей - от этого зависит какую архитектуру делать и куда пользователей запихивать - в астерис или камаилио.
ну и on-prem, cloud или box.

полностью облако, никаких коробок

с ним прям много проблем?

это телефония, детка (с)
тут скучно не бывает )))

Астериск - это куча деталей и куча инструментов. а собрать из них бульдозер или велосипед - решает автор продукта на основе астера

вот это уже интересно)

полностью облако, никаких коробок

ну тада вопрос с кол-вом пользователей следующий

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

1. Возможна ли динамическая регистрация юзеров (тобишь не через конфиг файлик а через условное API)
2. Возможна ли динамическая генерация диалпланов, в зависимости от бизнес-процессов уже нашего клиента
3. Возможно ли разделение одного сервака с астериском на разные ???"каналы"??? чтобы на один продукт нашего клиента приходилось условно изолированная среда (отдельный продукт, отдельные юзеры, отдельные конфиги, все такое), или про это можно забыть и ручками оркестрировать докер контейнеры

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

вы сделайте апи, а телефонисты к вам сами подтянутся

ну тада вопрос с кол-вом пользователей следующий

не сильно крупный, от 1к ежедневного онлайна по всем тенантам так скажем

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

1. Возможна ли динамическая регистрация юзеров (тобишь не через конфиг файлик а через условное API)
2. Возможна ли динамическая генерация диалпланов, в зависимости от бизнес-процессов уже нашего клиента
3. Возможно ли разделение одного сервака с астериском на разные ???"каналы"??? чтобы на один продукт нашего клиента приходилось условно изолированная среда (отдельный продукт, отдельные юзеры, отдельные конфиги, все такое), или про это можно забыть и ручками оркестрировать докер контейнеры

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

п 1., п.2. да, есть механизм realtime, когда в БД хранится инфа о sip учетках, и плане набора, что-то мне подсказывает, что под ваши нагрузки подойдет. п.3. нууу, теоретически, можно на уровне контекстов "разбросать" клиентов.

не сильно крупный, от 1к ежедневного онлайна по всем тенантам так скажем

что есть тенант?

что есть тенант?

мультитенант жеж.
тенант - одна компания. читай - домен