ИМХО — ajenti прекрасный продукт.
Используем его где-то в 50 инсталяциях. Очень удобно сделанно управление в Ajenti V.
Надеюсь вы его не закинете :)
Основное преимущество его, в том что Ajenti мы используем как шорткат к правке конфигов, а не решение с кучей галочек конструктором конфига. Такой подход позволяет использовать его в самых разных системах.
Если есть возможность написать статьи о настройке\эксплуатации — буду премного благодарен.
Архитектура же Kazoo меня при первом столкновении с ней привела в восторг, и я часто привожу ее как пример грамотно и качественно построенного решения.
Еще до выхода monster-ui пробовали поднять Kazoo на CloudZZ, как дополнительный сервис для клиентов, с приватной виртуальной АТС каждому подписчику на их собственном домене. До сих пор считаю что для всевозможных интернет магазинов это супер-функция (multi-tenant pbx). Но увы заставить все это работать не удалось — основным препятствием была таки заточка под USA (П.4 конспекта к примеру)
На тот момент родился вот такой конспект, по вещам не описанным в их инструкции по установке (о них забыли упомянуть):
Конспект установки
1. Kazoo Config
Поменять пути в
/var/www/html/kazoo-ui/config/config.js
на ip сервера с api или его url. Для субаккаунтов эти настроки меняются в меню whitelabel, и они не зависят от этой настройки. Без этого первый логин не возможно сделать.
2. Включить https для ui
/etc/https/conf/httpd.conf
/etc/https/conf.d/ssl.conf
https включается только для интерфейса, сам api как работал по чистому http так и будет работать без шифрования. Увы.
4. Подключение к sip gate. Kazoo не умеет аутентифицироваться по логину и паролю. Только аутентификация по IP. Используем костыль в виде freeswitch конфига для поддержки соединения. Концептуальный минус — после любой правки нужно рестартовать freeswitch, отключая всех от kazoo.
По поводу заказчиков крупных пулов — как раз обычно они и делают качественные сравнения. Запрашивают пул ресурсов в нескольких облаках и сравнивают те показатели о которых нет в маркетинговой брошюре. Пара таких обзоров была и на хабре. 1 и 2
Хотел сказать что нужно более вдумчиво относится к тому что за ширмой и изучать результаты вроде этих. Из того что мне встречалось, там наиболее аргументированное\грамотное сравнение, причем не только дисковой подсистемы но и других аспектов.
По поводу хостинга на микротике
Это плохая идея. Встроенный в него webserver подходит только для статики, и используется для создания hotspotoв в основном (но кстати очень успешно) и заточен на работу с ip\mac абонента, а не с логикой. Хотя вэб-приложение на Angular с parse.com в роди бэка заработает хорошо.
По поводу применения MetaRouter. Это технология виртуализации в микротиках, причем очень крутая… Нужна она за тем чтобы виртуализтровать микротики внутри микротика. Грубо говоря я каждому абоненту включенному в сеть могу дать персональный микротик для управления его сеткой, qos etc. Это очень круто, и на самом деле на мой взгляд микротик феерически ошибается, с тем, что не поддерживает HyperV нормально, в котором с сеткой проблемы, т.к на нем сделать управление сеткой для клиентов в ДЦ (виртуальном) к примеру супер. В Том году Микротики выпустили стоечные CCR, CRS — роутеры и свичи для ДЦ, которые вообщем то на это и рассчитаны, но в железном варианте.
Окончим лирику, и по сути выясняем что архитектура процессоров микротиков железных MipsBE, Tile, и только иногда x86. Это значит что версия того что запускается в метароутере должно быть собранно под туже архитектуру (собери asterix под 36 ядерный tile), стандартный php или ngnix под эту архитектуру найти — та еще задачка.
Сам микротик выпустил DD_WRT собранный для ARM с поддержкой metarouter, то есть только для небольшой линейки микротиков. И любители пересобрали на него часть пакетов типа asterix. Но во первых это не самые новые пакеты, во вторых нет саппорта на такие костыли. А теперь к проблеме. Crash metarouter = ребут микротика. Даже читсый DD_WRT с всего лишь WINS сервером на борту крашился у меня дважды в день… Что как бы говорит о ненадежности. Поэтому запуск чего-то отличного от микротика в метароутере очень чревато.
Используем его где-то в 50 инсталяциях. Очень удобно сделанно управление в Ajenti V.
Надеюсь вы его не закинете :)
Основное преимущество его, в том что Ajenti мы используем как шорткат к правке конфигов, а не решение с кучей галочек конструктором конфига. Такой подход позволяет использовать его в самых разных системах.
Архитектура же Kazoo меня при первом столкновении с ней привела в восторг, и я часто привожу ее как пример грамотно и качественно построенного решения.
P.S. возможно хаб voip был бы уместнее.
На тот момент родился вот такой конспект, по вещам не описанным в их инструкции по установке (о них забыли упомянуть):
Поменять пути в
/var/www/html/kazoo-ui/config/config.js
на ip сервера с api или его url. Для субаккаунтов эти настроки меняются в меню whitelabel, и они не зависят от этой настройки. Без этого первый логин не возможно сделать.
2. Включить https для ui
/etc/https/conf/httpd.conf
/etc/https/conf.d/ssl.conf
https включается только для интерфейса, сам api как работал по чистому http так и будет работать без шифрования. Увы.
3. number_manager
pbx.tehpostach.com:5984/_utils/document.html?system_config/number_manager
Необходимо задать reconcile_regex — выражние согласно которому будет происходить добавление DID номера. Я использовал отсюда регулярное выражение: github.com/yumminova/kazoo/blob/master/applications/crossbar/doc/internationalization/EU%20reconsile%20regex%20and%20e164%20converter.txt
Помимо этого тут можно задать регулярки для определения разных направлений — «classifiers»:
Они красиво мигрируют в web-ui.
4. Подключение к sip gate. Kazoo не умеет аутентифицироваться по логину и паролю. Только аутентификация по IP. Используем костыль в виде freeswitch конфига для поддержки соединения. Концептуальный минус — после любой правки нужно рестартовать freeswitch, отключая всех от kazoo.
/etc/freeswitch/gateways/*.xml
File: intertelecom.xml
5. Настройка прав доступа ecallmgr
pbx.tehpostach.com:5984/_utils/document.html?system_config/ecallmgr
Для того чтобы принимать звонки нужно внести ip шлюзов в лист trusted
6. UI
В Number Manager добавляем номер
+3809466xxxxxx
В VoIP Services — Callflow
создаем новый callflow для этого номера.
Это плохая идея. Встроенный в него webserver подходит только для статики, и используется для создания hotspotoв в основном (но кстати очень успешно) и заточен на работу с ip\mac абонента, а не с логикой. Хотя вэб-приложение на Angular с parse.com в роди бэка заработает хорошо.
По поводу применения MetaRouter. Это технология виртуализации в микротиках, причем очень крутая… Нужна она за тем чтобы виртуализтровать микротики внутри микротика. Грубо говоря я каждому абоненту включенному в сеть могу дать персональный микротик для управления его сеткой, qos etc. Это очень круто, и на самом деле на мой взгляд микротик феерически ошибается, с тем, что не поддерживает HyperV нормально, в котором с сеткой проблемы, т.к на нем сделать управление сеткой для клиентов в ДЦ (виртуальном) к примеру супер. В Том году Микротики выпустили стоечные CCR, CRS — роутеры и свичи для ДЦ, которые вообщем то на это и рассчитаны, но в железном варианте.
Окончим лирику, и по сути выясняем что архитектура процессоров микротиков железных MipsBE, Tile, и только иногда x86. Это значит что версия того что запускается в метароутере должно быть собранно под туже архитектуру (собери asterix под 36 ядерный tile), стандартный php или ngnix под эту архитектуру найти — та еще задачка.
Сам микротик выпустил DD_WRT собранный для ARM с поддержкой metarouter, то есть только для небольшой линейки микротиков. И любители пересобрали на него часть пакетов типа asterix. Но во первых это не самые новые пакеты, во вторых нет саппорта на такие костыли. А теперь к проблеме. Crash metarouter = ребут микротика. Даже читсый DD_WRT с всего лишь WINS сервером на борту крашился у меня дважды в день… Что как бы говорит о ненадежности. Поэтому запуск чего-то отличного от микротика в метароутере очень чревато.