Какая лучшая архитектура для интеграции CDR в приложение на основе Asterisk

Question

Iam разрабатывает платформу VOIP, которая позволит пользователям одновременно выполнять 100 вызовов одновременно с моей службой.

Asterisk хранит все записи подробных записей вызовов в таблице CDR. Я хотел бы знать, где лучше всего хранить эту таблицу для наилучшей архитектуры моей системы.

Должен ли я хранить его на Asterisk Box и запускать cron, чтобы синхронизировать его с сервером базы данных. Или я должен напрямую вызывать сервер БД с помощью Asterisk Box и регистрировать все данные непосредственно в базе данных удаленно, хотя Asterisk.

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

Answer 1

Лучшей архитектурой будет использование распределенных узлов (сервер), то есть УАТС, веб-сервер & Сервер БД в разных узлах. PBX будет заполнять вашу таблицу CDR (это должно быть на сервере БД) после каждого вызова, вы можете получить эти записи с вашего веб-сервера для своей отчетности & целью выставления счетов.

Использование Cron для синхронизации БД таблица не рекомендуется, так как это будет съедать ресурсы системы & Bandwidth тоже (как это хроны будут работать каждый раз съедаю системный ресурс & синхронизации с Db приведет использование полосы пропускания) Таким образом, используя выше что вы можете сохранить системные ресурсы, которые будут использоваться при запуске cron

Во-вторых, если вы поместите CDR в том же узле, что и PBX, он сохранит системный ресурс из-за cron, но для сообщения & фактурирования вы должны получить данные с этого узла, поэтому вы не можете сохранить пропускную способность, эта схема имеет большой недостаток, так как в настоящее время вы говорите о 100 вызовах одновременно, о том, если у вас было 1000 или более?

В этом случае вы должны определенно использовать кластеры PBX, в этом случае вам понадобится централизованный сервер БД, который будет синхронизироваться вашими кластерами УАТС.

Таким образом, во всех аспектах моя предлагаемая архитектура идеально подходит для вашей потребности. Как указано в вопросе, что вам нужно только 100s одновременных вызовов вы можете использовать один узел для DB & Web-сервера, а PBx в другом узле

Answer 2

Я думаю, что если вы можете подключиться непосредственно из Asterisk к базе данных, чем вы должен использовать его. Я видел это на некоторых установках Asterisk (включая один довольно большой call-центр), и он работал хорошо.

Другой вариант, который я использую там, где нет прямого соединения из Asterisk в базу данных, но есть HTTPS-соединение с другой службой или структура таблицы биллинга несовместима с таблицами Asterisk, чтобы использовать CSV-файлы CDR. Такой файл отправляется каждые несколько минут в систему CRM. Я использую cron и маленький скрипт Python. Таким образом, я могу легко адаптироваться к CSV-формату, используемому биллинговой системой CRM.

Answer 3

Использование отдельного сервера базы данных для хранения ваших CDR является правильным вариантом для всего, кроме реализации Asterisk хобби. Asterisk упрощает выбор целевой базы данных для ваших CDR и содержит множество различных параметров базы данных: MySQL, Postgresql. MSSQL и т. Д. Реализация Asterisk CDR использует только одну таблицу, поэтому на самом деле это очень простая интеграция между ним и вашим сервером базы данных.

ОЧЕНЬ известно, что если ваш сервер базы данных или соединение между ним и вашим сервером Asterisk имеют проблемы, это будет влиять на обработку вызовов.Если есть проблема, то Asterisk будет блокироваться, пока он пытается подключиться к базе данных для записи CDR. Хотя он делает это, он не будет обрабатывать другие вызовы. Возможно, это желаемое поведение, поскольку CDR имеют решающее значение для выставления счетов и не могут регистрировать их, означает, что любые вызовы потенциально могут стать бесплатными. В качестве резервной копии вы также можете настроить регистрацию CDR в CSV-файл на сервере Asterisk в качестве подхода к поясу и подтяжкам.