Предложения по модернизации системы диспетчерской связи

[mixyil1.1]

Предложения по модернизации программы Dispatcher

У меня есть предложения по внесению изменений в программу Dispatcher и систему диспетчерской связи в целом:

1. Переход с Qt5 на Qt6
   • Dispatcher написан с использованием Qt5, актуальной версией является Qt6.
   • Между Qt5 и Qt6 есть изменения в API, поэтому необходимо адаптировать программу для работы с Qt6.
   • Тестирование перехода на Qt6 уже проводилось в Linux (патч прилагается).

2. Изменение архитектуры диспетчерской связи Текущая схема работы (рис. 1).

Предлагаю новую схему (рис. 2)

включающая следующие изменения:

• Подключение к ESL FreeSWITCH через Proxy
  • Это позволит Dispatcher работать с несколькими серверами FreeSWITCH одновременно.
  • Также появится возможность подключения к другим VoIP-серверам (например, Asterisk).
• Устранение зависимостей
  • Убрать зависимость от MySQL: пароль для подключения к Proxy ESL должен храниться в конфигурационном файле Dispatcher.
  • Убрать зависимость от SSH: настройка должна выполняться через веб-интерфейс.
• Перенос функционала в веб-интерфейс
  • Прослушивание записанных конференций.
  • Управлением абонентами.
  • Управлением планом набора.

Что должно получится:

• Dispatcher останется только в качестве пользовательского интерфейса для управления конференциями.
• Proxy обеспечит гибкость подключения в том числе и к нескольким серверам.
• Веб-интерфейс сократит необходимость ручного консольного конфигурирования FreeSWITCH.

Для реализации предлагаю:

• Создать в репозитории новую ветку qt6 для продолжения разработки.
• Если нет возражений, я готов взять разработку на себя. В таком случае, предоставьте пользователю mixyil1.1 права на запись в ветку qt6.

[san]

Заберу пока тикет себе

[alx]

Replying to mixyil1.1:

• Тестирование перехода на Qt6 уже проводилось в Linux (патч прилагается).

Спасибо за патч. Попробую собрать с QT6 и проверить в работе.

Предлагаю новую схему (рис. 2)

Тут требуются дополнительные пояснения...

На приведенной схеме я вижу рабочее место оператора, на котором почему-то присутствуют пульт диспетчера и веб-браузер... Почему так? Не ошибся ли ты? Вообще-то пульт диспетчера (MC04Dispatcher) предназначен для использования диспетчером, а не оператором. Оператор использует SIP-телефон. ИМХО ни одна из функций пульта диспетчера оператору для работы по-моему не требуется...

включающая следующие изменения:

• Подключение к ESL FreeSWITCH через Proxy

Предлагается использовать какой-то уже существующий прокси (если да, то какой) или предлагается этот прокси создать самим?

• Это позволит Dispatcher работать с несколькими серверами FreeSWITCH одновременно.

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

Во-вторых, непонятно, почему пульт диспетчера не может работать с несколькими FreeSWITCH напрямую, без прокси. Что ему не позволит это сделать?

• Также появится возможность подключения к другим VoIP-серверам (например, Asterisk).

Опять непонятно, в чем суть предлагаемого улучшения. Чем именно Asterisk лучше FreeSWITCH как сервер диспетчерской связи?

• Устранение зависимостей
  • Убрать зависимость от MySQL: пароль для подключения к Proxy ESL должен храниться в конфигурационном файле Dispatcher.

Это не уберет зависимость от Mysql, так как mysql используется не только и не столько для хранения пароля. Mysql используется также для хранения метаданных записей переговоров. Но я согласен, что текущая схема аутентификации "кривая". Она была реализована вынужденно, так как ESL не имеет логинов, а имеет лишь один единственный пароль на всех. По уму на сервере должен быть свой пароль на каждого диспетчера (и каждого техника).

Хранить пароль в конфиг-файле мне не кажется хорошей идеей. Если диспетчер не хочет или не может держать пароль в своей голове, есть множество менеджеров паролей, специально для этого предназначенных. Мы, конечно, не можем запретить диспетчеру записать свой пароль в файл, но поощрять такую практику я не считаю хорошей идеей.

• Убрать зависимость от SSH: настройка должна выполняться через веб-интерфейс.

Во-первых, непонятно, чем плох протокол SSH (и, соответственно, зависимость от libssh, которую ты предлагаешь устранить). Поясни, пожалуйста. Насколько я понял, ты предлагаешь вместо SSH использовать HTTP(S). Я в этом не вижу никаких преимуществ, зато вижу недостатки:

• сервер SSH устанавливается и работает "из коробки", а веб-серверу требуется еще некий backend, который будет обрабатывать запросы, то есть требуется выполнение дополнительной работы;
• протокол HTTP небезопасен;
• протокол HTTPS требует установки и регулярного обновления сертификатов, это дополнительная забота и работа для администратора сервера (да, я знаю, что обновление можно автоматизировать, но в любом случае это дополнительная забота для администратора).

Во-вторых, мне не нравится идея, что настройка сервера выполняется с клиентского приложения. По-моему настраивать сервер - это не функция диспетчера. Сервер должен настраивать администратор сервера - зайдя на сервер интерактивно по тому же SSH (обычным нормальным ssh клиентом, а не пультом диспетчера!). Но к моменту, когда я был назначен разработчиком, такой функционал у пульта уже был, и мое предложение его убрать, к сожалению, не встретило поддержки и понимания.

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

• Перенос функционала в веб-интерфейс

Опять не понятно, в чем же зесь улучшение. Мне не нравится идея, что диспетчеру для работы требуется уже не одна, а две разных программы - пульт и веб-браузер. По-моему это не улучшение, а, необорот, ухудшение. Если на рабочем месте диспетчера уже есть нативное приложение, у которого уже есть пользовательский интерфейс, которым диспетчер пользуется, IMHO было бы логично все функции выполнять через интерфейс этого приложения, чтобы не требовалось запускать еще и браузер.

• Прослушивание записанных конференций.

Не согласен. Не вижу в этом улучшения. По-моему если для прослушивания записи будет требоваться переключаться на другое приложение (браузер), это будет менее удобно чем то, как сделано сейчас, когда все в одном приложении.

• Управлением абонентами.

Что ты подразумеваешь под "управлением абонентами"? Если вызов абонента в конференцию, включение/отключение его микрофона, перемещение из одной конференции в другую, отбой абонента от конференции и т.п. (то есть именно функции диспетчера) - то изначально у нас как раз и была идея сделать пульт диспетчера веб-приложением - я даже сам на скорую руку набросал веб-страницу, которая показывала список конференций, список их участников, позволяла вызывать кого-то... Но потом в процессе работы столкнулись с какими-то проблемами, которые средствами веб-приложения решить не представлялось возможным (деталей не помню, разработкой занимался не я). Поэтому мы были вынуждены отказаться от веб-приложения и делать приложение на Java (от которого потом тоже пришлось отказаться в пользу с++ и QT). Теперь, когда нативное приложение уже реализовано, заново разрабатывать то же самое как веб-приложение я смысла не вижу...

Если же имеется в виду администрирование сервера (создание абонентов, удаление, изменение их настроек) - то, как я уже писал выше, это вообще не функция диспетчера, и я всеми руками и ногами за полное устранение этого функционала с рабочего места диспетчера. Это должен делать администратор сервера, и ни пульт, ни веб-браузер ему для этого не нужны.

• Управлением планом набора.

А у пульта диспетчера есть такая функция? Кошмар!!! :)

Это вообще не функция диспетчера, это функция администратора сервера. Поэтому я считаю, что подобный функционал должен быть просто выпилен из пульта. Администратору FreeSWITCH для настройки плана ни пульт диспетчера, ни веб-браузер не нужны. Ему нужен текстовый редактор, который на сервере и так уже есть.

Что должно получится:

• Dispatcher останется только в качестве пользовательского интерфейса для управления конференциями.

Полностью поддерживаю.

• Proxy обеспечит гибкость подключения в том числе и к нескольким серверам.

Эта мысль пока не понятна, жду пояснений, о которых уже попросил выше.

• Веб-интерфейс сократит необходимость ручного консольного конфигурирования FreeSWITCH.

Конфигурирование FreeSWITCH не является функцией диспетчера, поэтому такой необходимости у диспетчера просто нет, и поэтому веб-интерфейс для сокращения этой необходимости ему не нужен.

Для реализации предлагаю:

• Создать в репозитории новую ветку qt6 для продолжения разработки.

Зачем создавать ветку? QT5 в этом году наступает EOL. Нет ни смысла, ни возможности на ней оставаться. Ты дал готовый патч, и пишешь, что он даже уже проверен - я считаю, что надо просто переходить с QT5 на QT6 в транке. Если все будет хорошо - я просто закоммичу твой патч.

• Если нет возражений, я готов взять разработку на себя. В таком случае, предоставьте пользователю mixyil1.1 права на запись в ветку qt6.

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

[mixyil1.1]

Replying to alx:

На приведенной схеме я вижу рабочее место оператора, на котором почему-то
присутствуют пульт диспетчера и веб-браузер... Почему так? Не ошибся ли ты?
Вообще-то пульт диспетчера (MC04Dispatcher) предназначен для использования
диспетчером, а не оператором. Оператор использует SIP-телефон. ИМХО ни одна из
функций пульта диспетчера оператору для работы по-моему не требуется...

Да, ошибся. Тут произошло смешивание понятий, оператор в схеме выше это рабочее
место техника (имелось ввиду оператор/администратор сервера).

Предлагается использовать какой-то уже существующий прокси (если да, то какой)
или предлагается этот прокси создать самим?

Написать самим.

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

Например, если устанавливать диспетчерскую связь на плату МС-03, то мы
имеем ограничение на количество одновременных вызовов ~50-80. Это позволит, в
случае необходимости, распределить нагрузку между 2-мя и более платами. (Управлять разными конференциями на 2-х платах)

Во-вторых, непонятно, почему пульт диспетчера не может работать с несколькими
FreeSWITCH напрямую, без прокси. Что ему не позволит это сделать?

Пульт диспетчера подключается к event socket 1-го сервера и получает события
конференций только с 1 сервера. Если нужно следить/управлять за конференциями на 2
серверах, то это сейчас сделать невозможно. Или я ошибаюсь?

Опять непонятно, в чем суть предлагаемого улучшения. Чем именно Asterisk лучше
FreeSWITCH как сервер диспетчерской связи?

Asterisk не рассматривается как замена Freeswitch в системе диспетчерской
связи. Тут речь скорее про универсальность. Используя прокси пульту диспетчера
по большому счету без разницы куда он, proxy, подключен. И если в proxy
реализовать протокол взаимодействия с Asterisk то в качестве сервера конференций
для пульта диспетчера можно будет использовать в том числе и Asterisk. Это
бывает востребованно, когда уже есть внутренняя АТС, например на Asterisk, и есть
необходимость видеть/управлять конференциями с пульта диспетчера и на
внутренней АТС. Обычно таким управлением занимается не диспетчер а техник и в
этом случае пульт диспетчера рассматривается не как пульт диспетчера, а как
пульт управления конференциями.

Это не уберет зависимость от Mysql, так как mysql используется не только и не
столько для хранения пароля. Mysql используется также для хранения метаданных
записей переговоров.

Да, я понимаю про метаданные записей.

Метаданные для записей я тоже предлагаю запрашивать через
подключение к proxy. Например команда вида "api conference media uid" запрос
данных конкретной сессии и "api conference media date_start date_stop" запрос
списка записей за временной промежуток. Реализовать это можно или в самом proxy
(он делает запросы в базу) или добавить api команды в модуль Freeswicth
mod_conference_cdr_mysql.

Но я согласен, что текущая схема аутентификации
"кривая". Она была реализована вынужденно, так как ESL не имеет логинов, а имеет
лишь один единственный пароль на всех. По уму на сервере должен быть свой пароль
на каждого диспетчера (и каждого техника).

Текущая схема мне не нравиться еще и потому, что нельзя запустить пульт
диспетчера если нет подключения к базе данных. Мне кажется правильным сохранить
работоспособность пульта диспетчера с случае проблем с базой данных. Пусть
потеряется информация о сессиях (метаданные записей), но можно будет создавать
конференции.

Назначить каждому пользователю свой пароль, в этом proxy как раз и может помочь.

Хранить пароль в конфиг-файле мне не кажется хорошей идеей. Если диспетчер не
хочет или не может держать пароль в своей голове, есть множество менеджеров
паролей, специально для этого предназначенных. Мы, конечно, не можем запретить
диспетчеру записать свой пароль в файл, но поощрять такую практику я не считаю
хорошей идеей.

Тут я полностью согласен. Но это как самый простой вариант, к тому же я
предлагаю хранить пароль только от подключения к сокету proxy.

Во-первых, непонятно, чем плох протокол SSH (и, соответственно, зависимость от
libssh, которую ты предлагаешь устранить). Поясни, пожалуйста. Насколько я
понял, ты предлагаешь вместо SSH использовать HTTP(S). Я в этом не вижу никаких
преимуществ, зато вижу недостатки:

сервер SSH устанавливается и работает "из коробки", а веб-серверу требуется еще
некий backend, который будет обрабатывать запросы, то есть требуется выполнение
дополнительной работы;
протокол HTTP небезопасен;
протокол HTTPS требует установки и регулярного обновления сертификатов, это
дополнительная забота и работа для администратора сервера (да, я знаю, что
обновление можно автоматизировать, но в любом случае это дополнительная забота
для администратора).

Во-вторых, мне не нравится идея, что настройка сервера выполняется с клиентского
приложения. По-моему настраивать сервер - это не функция диспетчера. Сервер
должен настраивать администратор сервера - зайдя на сервер интерактивно по тому
же SSH (обычным нормальным ssh клиентом, а не пультом диспетчера!). Но к
моменту, когда я был назначен разработчиком, такой функционал у пульта уже был,
и мое предложение его убрать, к сожалению, не встретило поддержки и понимания.

SSH отличная вещь. И да диспетчеру не к чему заниматься настройкой
сервера, в том или ином виде эта функция техника (администратора
сервера). Именно поэтому я предлагаю перенести настроку в web, убрать с
пульта эти функции. К сожалению путь - подключиться к серверу по ssh и
отредактировать файлы конфигурации Freeswitch порой вызывает трудности.

Для этого да, придется выполнить дополнительную работу по реализации backend.

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

Да. Скачивать записи я предлагаю тоже чрез web интерфейс.

Зачем скачивать записи - чтобы передать кому-то для разрешения каких-то спорных
ситуаций. Диспетчеру этот функционал тоже не особо нужен. Ему может быть необходимо
оперативно прослушать какую-то запись для принятия решения.

Опять не понятно, в чем же зесь улучшение. Мне не нравится идея, что диспетчеру
для работы требуется уже не одна, а две разных программы - пульт и
веб-браузер. По-моему это не улучшение, а, необорот, ухудшение. Если на рабочем
месте диспетчера уже есть нативное приложение, у которого уже есть
пользовательский интерфейс, которым диспетчер пользуется, IMHO было бы логично
все функции выполнять через интерфейс этого приложения, чтобы не требовалось
запускать еще и браузер.

Я предлагаю перенести в web интерфейс не весь функционал пульта диспетчера а
только часть функций:

• Управлением абонентами;
• Управлением планом набора;
• Прослушивание записанных конференций;

которые диспетчеру в пульте как-раз не очень то и нужны, ну за исключением
прослушивания записей.

Не согласен. Не вижу в этом улучшения. По-моему если для прослушивания записи
будет требоваться переключаться на другое приложение (браузер), это будет менее
удобно чем то, как сделано сейчас, когда все в одном приложении.

Соглашусь. Однако иметь возможность прослушать записи и через web интерфейс я тоже
считаю полезной т.к. это позволит просмотривать данные сохраненной сесии и
прослушать запись без использования пульта диспетчера. Этот функционал
необходим, например для контроля переговоров диспетчерской связи ответственными лицами.

Если же имеется в виду администрирование сервера (создание абонентов, удаление,
изменение их настроек) - то, как я уже писал выше, это вообще не функция
диспетчера, и я всеми руками и ногами за полное устранение этого функционала с
рабочего места диспетчера. Это должен делать администратор сервера, и ни пульт,
ни веб-браузер ему для этого не нужны.

Да. Ровно это. Эти функции нужны техническому персоналу, который обслуживает
сервер диспетчерской связи. И очень часто работа в консоле сервера вызывает
трудности. В связи с этим я предлагаю эти функции (создание абонентов, удаление,
изменение их настроек) вынести в web интерфейс.

А у пульта диспетчера есть такая функция? Кошмар!!! :)

Нету

Это вообще не функция диспетчера, это функция администратора сервера. Поэтому я
считаю, что подобный функционал должен быть просто выпилен из
пульта. Администратору FreeSWITCH для настройки плана ни пульт диспетчера, ни
веб-браузер не нужны. Ему нужен текстовый редактор, который на сервере и так уже
есть.

Согласен на все 100%. Однако, как говорил выше, это таки вызывает определенные
трудности.

Proxy обеспечит гибкость подключения в том числе и к нескольким серверам.

Эта мысль пока не понятна, жду пояснений, о которых уже попросил выше.

Дополню примерами.

1. Сервер диспетчерской связи, кроме основной своей функции, часто выполняет еще и роль небольшой АТС. На него переносят часть телефонов внутренней АТС. (Хорошо это или плохо вопрос другой, но кто запретит.) Неудобство в том, что когда программа запрашивает список абонентов "list_users", то получает список всех абоненнтов и тех что относятся к диспетчерской и тех что не относятся. Это загромаждает список в пульте диспетчера. Абонентов, которые не относятся к диспетчерскоой связи обычно объединяют в отдельную группу, но все равно это лишняя информация. На proxy можно фильтровать этот список и выдавать в программу только абонентов диспетчерской связи. (Это можно делать и на самом пульте).

2. Если для Freeswitch делать не статическую конфигурацию а динамическую, например через mod_xml_curl, то ответ на запрос "list_users" придет пустой.

3. Если рассматривать пульт диспетчера как программу управления конференциями, то proxy позволит фильтровать события конференций для разных пультов. Например - техник будет видеть все конференции, которые создаются на сервере, а диспетчер только с номерами 0 - 10.

Зачем создавать ветку?

Для перехода на qt6 наверное и не обязательно. Но для внесения других
предлагаемых изменений, в случае положительного решения на доработку, все-же
наверное нужно.

[mixyil1.1]

Исправил схемы