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

[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]

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

[mixyil1.1]

Еще однин пример применения proxy - работа с "необычными" абонентами.

Задача
На плате VE02 есть канальные окончания RTP. В пульт диспетчера добавить возможность подключать эти канальные окончания к конференции.

Вариант решения с использованием proxy

---

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

[alx]

Replying to mixyil1.1:

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

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

Спасибо за пояснение. Я не согласен с таким предложением. По-моему это неправильное, негодное решение. Задача балансировки нагрузки сервера должна решаться средствами сервера. Пульт диспетчера - это всего лишь такой специфический юзер-агент. Примерно как телефон у оператора. И это не его функция - балансировать нагрузку сервера, как это не функция SIP-телефона. Диспетчера может вообще не быть в сети - представь себе, что он задержался с выходом на работу, :) а в это время 100 операторов подключились к конференции и, как результат, сервер не справился с такой нагрузкой...

По-моему балансировщик должен работать на стороне сервера (в твоем примере - на той же плате MC-03) независимо от присутствия диспетчеров.

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

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

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

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

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

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

Спасибо, теперь суть улучшения понятна. Однако по-прежнему непонятно, зачем здесь прокси. Ты выше уже уточнил, что прокси-сервер предлагается создавать самим, то есть самим реализовывать поддержку взаимодействия с Asterisk по каким-то поддерживаемым им протоколам. Но если так, то почему мы не можем реализовать это сразу в пульте? По-моему прокси-сервер здесь не нужен.

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

Обычно таким управлением занимается не диспетчер а техник и в
этом случае пульт диспетчера рассматривается не как пульт диспетчера, а как
пульт управления конференциями.

Хм... Тикет озаглавлен "Предложения по модернизации системы диспетчерской связи", именно из этого я и исходил. Если (в данной части предложения) речь не о системе диспетчерской связи, то может быть имеет смысл создать отдельный продукт для управления конференциями Asterisk (на основе пульта) вместо того чтобы нагружать пульт лишним (для диспетчерской связи) функционалом? Мне сложно представить, что кто-то использует Asterisk и FreeSWITCH одновременно... :)

Метаданные для записей я тоже предлагаю запрашивать через
подключение к proxy.

Спасибо за пояснение, суть предлагаемого теперь понятна. Но по-прежнему непонятно, в чем же состоит улучшение - почему ты считаешь, что запрос БД через прокси (или модуль FS, который тоже в таком случае будет выполнять роль прокси) будет лучше, чем прямое обращение к СУБД. Я вообще не вижу в этом проекте никаких проблем с зависимостями. Сейчас специально посмотрел зависимости пульта. Если не считать QT и стандартные библиотеки компилятора, их меньше десятка. Это мизер! Искренне не понимаю, что тут улучшать. IMHO пропадания из зависимостей libmysqlclient21 вообще никто не заметит - ни диспетчер/техник, которые будут работать с пультом, ни администратор, который будет софт обновлять, ни разработчик (я), который будет собирать пакет пульта...

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

О, вот это - другое дело. Это - вполне понятное мне улучшение. Странно, что в описании тикета ты об этом не написал...

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

Как я уже писал, против "выпиливания" этой функции из пульта лично я не возражаю. Однако предполагаю, что кто-от будет (заказчики?), так как смутно помню, что такая дискуссия у нас уже была...

К сожалению путь - подключиться к серверу по ssh и
отредактировать файлы конфигурации Freeswitch порой вызывает трудности.

Это слышать для меня удивительно. :)

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

Много лет назад, кажется в фидошной конференции RU.UNIX.BSD (или в RU.LINUX?) регулярно появлялись запросы новичков какой-либо программы/фичи. Им отвечали примерно так: программы/фичи, о которой ты спрашиваешь, нет и, скорее всего, никогда не будет, потому что те, кто о ней спрашивают, не имеют достаточной квалификации для ее создания, а те, кто имеет достаточную квалификацию, не имеют в подобной программе потребности. По-моему это очень верно и правильно. IMHO если у администратора сервера, как ты говоришь, вызывает трудности вход на сервер по SSH и редактирование конфиг-файла, этому администратору стоит заняться повышением своей квалификации. А когда и если он ее повысит, потребность в веб-интерфейсе для редактирования конфиг-файла у него отпадет сама собой...

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

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

Не вижу в этом улучшения (для диспетчера). Сейчас он все делает в интерфейсе одной программы: нашел запись, прослушал ее и, если посчитал интересной, нажатием одной кнопки сохранил ее себе локально (не помню точно, как это сделано в интерфейсе, но вроде бы это делается в один клик). Ты предлагаешь вместо сохранения одним кликом:

• запустить веб-браузер;
• открыть в браузере какой-то URL;
• аутентифицироваться;
• найти в веб-интерфейсе ту же запись;
• кликнуть "сохранить".

Мне не кажется это улучшением (для пользователя), скорее ухудшение...

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

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

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

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

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

Хорошо. Допустим, в пульте есть функция, которая диспетчерам, как ты выразился, не очень-то нужна (например управление планом нумерации). Но эти функции в пульте уже есть. Никто ведь не заставляет пользователя пользоваться функциями, которые ему не нужны, только потому, что они в пульте есть! :) Что улучшится от того, что функцию, которой не пользуются, мы перенесем из пульта в веб-интерфейс?

У предыдущего разработчика пульта была любимая фраза, которая у нас стала мемом: "Предлагаю оставить как есть". :)

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

Но ты же на схеме нарисовал веб-браузер на рабочем месте диспетчера, а не какого-то другого ответственного лица! :)

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

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

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

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

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

Это загромаждает список в пульте диспетчера.

Такого ИМХО не должно происходить! Диспетчер должен видеть только пользователей своего домена - так, по крайней мере, если я правильно помню, было задумано. Сейчас я специально проверил. Запустил пульт и подключился к серверу. На сервере есть пользователи с разными доменами (я вижу их по выводу list_users). Но в пульте отображаются только пользователи того домена, в который вошел диспетчер. Специально проверил каждого в списке - пользователи чужих доменов не отображаются. Если у тебя (или у кого-то еще) не так - это баг, рекомендую в таком случае создать тикет.

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

Абонентов, которые не относятся к диспетчерскоой связи обычно

объединяют в отдельную группу,

Вообще-то для этого существуют домены.

но все равно это лишняя информация.

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

На proxy

можно фильтровать этот список и выдавать в программу только абонентов
диспетчерской связи. (Это можно делать и на самом пульте).

Точно так же его можно фильтровать и без прокси, и, главное, это и так уже делается! Ты "ломишься в открытую дверь"! :)

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

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

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

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

Давай я подведу предварительную черту и попробую кратко резюмировать.

---

1. Предложение перейти с QT5 на QT6 я поддерживаю и постараюсь реализовать.

2. По прокси серверу. Из всех твоих аргументов разумным и понятным мне кажется только один - возложить на него аутентификацию пользователей чтобы для этого не требовался запрос к БД (и, соответственно, можно было начать работу даже при отказавшей mysql). Однако учитывая, что и mysql позволяет без особого труда настроить резервирование сервера, важность этого улучшения мне кажется не настолько высокой, чтобы только ради него стоило разрабатывать новую дополнительную сущность - прокси-сервер ESL (тем самым как раз понижая общую надежность системы).

3. Если ты считаешь нужным создать веб-интерфейс для администратора сервера, где работает FS, то я не возражаю, но тебе и не требуется на это мое согласие, так как прямого отношения к пульту диспетчера это не имеет.

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

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

[alx]

Replying to mixyil1.1:

Задача
На плате VE02 есть канальные окончания RTP. В пульт диспетчера добавить возможность подключать эти канальные окончания к конференции.

Прости, но я с такой постановкой задачи категорически не согласен, поэтому даже рассматривать (пока) вариант решения не буду. Это как это - пришел утром диспетчер на работу и подумал: "Ох, как же хочется мне поговорить с канальным окончанием RTP платы VE-01! Как жаль, что мой пульт не может подключить его в конференцию"... Так? :) :) :)

Нет, так не бывает! У диспетчера ИМХО нет и не может быть такой цели/задачи. Он вообще не знает (и не должен знать) ни про какие канальные окончания никакой VE-01, он не оперирует такими понятиями. Он знает оператора Петрова с ГРС "Васильки", оператора Сидорова с ГРС "Лютики" и т.п... :)

Подключить к конференции канальное окончание RTP - это не самоцель, и не задача диспетчера. Это - средство решения какой-то другой, настоящей задачи. И, скорее всего, не единственное, а всего лишь одно из возможных. А настоящая задача диспетчера - подключить к конференции какого-то оператора ГРС чтобы поговорить с ним, либо подключить нескольких операторов чтобы дать им возможность поговорить друг с другом. Вот из этих целей и задач диспетчера и следует исходить. И я не вижу необходимости для решения этих задач использовать канальные окончания RTP платы VE-01, так как для переговоров с диспетчером у операторов ГРС есть SIP-телефон. По-моему ты здесь подгоняешь задачу под желаемый ответ. :)

[mixyil1.1]

Replying to alx:

Прости, но я с такой постановкой задачи категорически не согласен, поэтому даже
рассматривать (пока) вариант решения не буду. Это как это - пришел утром
диспетчер на работу и подумал: "Ох, как же хочется мне поговорить с канальным
окончанием RTP платы VE-01! Как жаль, что мой пульт не может подключить его в
конференцию"... Так? :) :) :)

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

Подключить к конференции канальное окончание RTP - это не самоцель, и не задача
диспетчера.

Я и не говорил что это цель диспетчера. Задача иметь возможность подключить
канальное окончание RTP к пульту диспетчера.

Это - средство решения какой-то другой, настоящей задачи.

Подключить устройство громкой связи к конференции.

И, скорее всего, не единственное, а всего лишь одно из возможных.

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

И я не вижу необходимости для решения этих задач использовать канальные
окончания RTP платы VE-01, так как для переговоров с диспетчером у операторов
ГРС есть SIP-телефон. По-моему ты здесь подгоняешь задачу под желаемый
ответ. :)

Для связи с оператором конечно нет. Для связи с другими абенентами возможно
понадобятся и не только канальные окончания RTP платы VE-01. "Диспетчерская
связь" не только 1 фиксированный сценарий работы.

[mixyil1.1]

Replying to alx:

По-моему это неправильное, негодное решение. Задача балансировки
нагрузки сервера должна решаться средствами сервера. Пульт
диспетчера - это всего лишь такой специфический юзер-агент. Примерно
как телефон у оператора. И это не его функция - балансировать нагрузку
сервера, как это не функция SIP-телефона. Диспетчера может вообще не
быть в сети - представь себе, что он задержался с выходом на работу,
:) а в это время 100 операторов подключились к конференции и, как
результат, сервер не справился с такой нагрузкой..

Тут я согласен. Ошибся это конечно-же не задача прокси.

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

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

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

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

Однако по-прежнему непонятно, зачем
здесь прокси. Ты выше уже уточнил, что прокси-сервер предлагается создавать
самим, то есть самим реализовывать поддержку взаимодействия с Asterisk по
каким-то поддерживаемым им протоколам. Но если так, то почему мы не можем
реализовать это сразу в пульте? По-моему прокси-сервер здесь не нужен.

Можно конечно и в пульте. Я про то, чтобы пульт и знать не знал про такие
подробности, пусть он "думает" и дальше что общается с сервером
Freeswitch через ESL.

И отдельный вопрос (не связанный с прокси) - поддерживает ли Asterisk
функционал, требуемый для организации системы диспетчерской связи.

Да, там есть свои интерфейсы управления - AMI, ARI. Но Asterisk я привел больше
для примера, на его месте может быть что-то другое.

Спасибо за пояснение, суть предлагаемого теперь понятна. Но по-прежнему
непонятно, в чем же состоит улучшение - почему ты считаешь, что запрос БД через
прокси (или модуль FS, который тоже в таком случае будет выполнять роль прокси)
будет лучше, чем прямое обращение к СУБД.

В том чтобы пульт не "знал" что он обращается к БД. Обращение к базе будет
конечно, но пульт пусть об это не знает. Это, конечно, не избавляет от реализации это
функционала в другом месте.

Я вообще не вижу в этом проекте никаких проблем с зависимостями. Сейчас
специально посмотрел зависимости пульта. Если не считать QT и стандартные
библиотеки компилятора, их меньше десятка. Это мизер! Искренне не понимаю, что
тут улучшать. IMHO пропадания из зависимостей libmysqlclient21 вообще никто не
заметит - ни диспетчер/техник, которые будут работать с пультом, ни
администратор, который будет софт обновлять, ни разработчик (я), который будет
собирать пакет пульта...

Избавиться от зависимостей не самоцель, нет. Цель предложенных изменений убрать
из пульта не нужный функционал и детали реализации системы.

MHO если у администратора сервера, как ты говоришь, вызывает трудности вход на
сервер по SSH и редактирование конфиг-файла, этому администратору стоит заняться
повышением своей квалификации. А когда и если он ее повысит, потребность в
веб-интерфейсе для редактирования конфиг-файла у него отпадет сама собой...

Короткий комментарий - конечно стоит, но ......

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

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

Сейчас он все делает в интерфейсе одной программы: нашел запись, прослушал ее и,
если посчитал интересной, нажатием одной кнопки сохранил ее себе локально

Что значит посчитал интересной. Запись не может быть интересной и диспетчер не
оперирирует такими понятиями. Скачать запись из системы можно в некоторых
определенных случаях, сделать это просто так и оставить у себя на компьютере
нельзя. Почти везде сейчас есть правила/нормативы для хранения записей
разговоров диспетчерской связи, или переговоров диспетчера если точнее.

Если диспетчеру
она не нужна, он ей просто не будет пользоваться и все

Я не говорю что эту функцию нужно удалить. Я говорю давайте метаданные
конференций получать другим, отличным от запроса к БД, способом.

Хорошо. Допустим, в пульте есть функция, которая диспетчерам, как ты выразился,
не очень-то нужна (например управление планом нумерации). Но эти функции в
пульте уже есть.

Нет этой функции в пульте диспетчера.

Но ты же на схеме нарисовал веб-браузер на рабочем месте диспетчера,
а не какого-то другого ответственного лица

На новых схемах браузер нарисован на рабочем месте техника/администратора.

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

Все ровно так и есть. На сервере обычно 1 IP и 1 домен и все абоненты в
куче.

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

У всех статическая конфигурация, вот и не жаловались.

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

Ну например конференции, которые создает техник для решения своих
задач, не появляются в пульте диспетчера и не отвлекают его.

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

Еще раз, я не призываю отказать от Mysql. Я предлагаю сделать так,
чтобы пульт не знал что он пользуется Mysql. Новая сущность несет
риски, но дает возможность развития системы без глубокой модернизации
пульта диспетчера.

3. Если ты считаешь нужным создать веб-интерфейс для администратора

сервера, где работает FS, то я не возражаю, но тебе и не требуется на
это мое согласие, так как прямого отношения к пульту диспетчера это
не имеет.

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

[alx]

Replying to mixyil1.1:

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

Это ровно то, о чем я написал в прошлом комментарии. Рад, что наши мнения совпали.

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

Вот! Кажется, начинает проступать истинная задача! :)

Подключить к конференции канальное окончание RTP - это не самоцель, и не задача
диспетчера.

Я и не говорил что это цель диспетчера.

Как не говорил? У тебя в comment:5 написано и выделено жирным шрифтом слово "Задача", и под ним написаны слова про подключение канального окончания RTP платы VE-02 к конференции диспетчера. Про прослушивание переговоров конференции с помощью устройства громкой связи там не написано ни слова...

Задача иметь возможность подключить
канальное окончание RTP к пульту диспетчера.

Нет, это не задача. Ты же сам выше вроде бы согласился со мной в том, что диспетчер не знает и знать не должен "про плату VE-02 и прочее"... :)

Это - средство решения какой-то другой, настоящей задачи.

Подключить устройство громкой связи к конференции.

Вот! Отлично! Теперь мы знаем истинную задачу, которую требуется решить. Вот тебе прямое решение поставленной задачи ("в лоб"). В качестве устройства громкой связи устанавливается SIP-телефон, который вызывается из FS в режиме интерком (то есть при получении INVITE он сразу отвечает "200 OK" и включает громкую связь). Для пульта этот телефон ничем не отличается от телефона любого другого оператора.

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

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

[alx]

Replying to san:

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

Правильно ли я понял, что любезно предоставленный mixyil1.1 патч (переход с QT5 на QT6) ты протестируешь и закоммитишь сам?

[mixyil1.1]

Как не говорил? У тебя в comment:5 написано и выделено жирным шрифтом
слово "Задача", и под ним написаны слова про подключение канального
окончания RTP платы VE-02 к конференции диспетчера. Про прослушивание
переговоров конференции с помощью устройства громкой связи там не
написано ни слова...

Написано "В пульт диспетчера добавить возможность подключать эти
канальные окончания к конференции." Тут ничего не написано про
диспетчера, написано про возможность пульта диспетчера подключить
канальное окончание в конференцию. Это техническая задача - как сделать
так, чтобы абонент с списке пульта диспетчера был связан не с IP
телефоном, а с канальным окончанием RTP платы VE. Про диспетчера и его
желание оперировать канальными окончаниями RTP тут ни слова нет.

Вот тебе прямое решение поставленной задачи ("в лоб"). В качестве
устройства громкой связи устанавливается SIP-телефон, который
вызывается из FS в режиме интерком (то есть при получении INVITE он
сразу отвечает "200 OK" и включает громкую связь). Для пульта этот
телефон ничем не отличается от телефона любого другого оператора.

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

[alx]

Replying to mixyil1.1:

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

А, кажется понял. Ты предлагаешь сделать прозрачный прокси, который снаружи (по протоколу работы) ничем не отличается от ESL Freeswitch.

Тут я вынужден сделать некоторое отступление. Посмотри, пожалуйста, на ситуацию моими глазами. Ты создал для меня тикет, в котором (в числе прочего) предлагаешь добавить в систему новый компонент - прокси-сервер. По идее, получив и прочитав это предложение в описании тикета, я должен сесть и написать этот прокси-сервер (если, конечно, я согласен, что это действительно улучшит нашу систему). Но перечитай сам описание тикета - там нет никакой конкретики о том, как этот прокси должен работать, какие функции этот прокси должен выполнять. Я сейчас отвечаю уже на 9-й комментарий тикета, но все еще получаю детали твоего предложения (в части прокси-сервера) буквально по каким-то крупицам... Вот первый пункт предложения тикета (переход с Qt5 на Qt6) ты написал просто идеально - понятно что предлагается сделать, есть понятная мотивация, и даже приложен готовый патч, за что тебе еще раз спасибо! По-моему это первый случай в моей практике, когда приложен готовый патч, реализующий предложение тикета. Фактически ты выполнил большую часть работы за меня. Но вот со второй частью предложения - просто какая-то беда... Так к чему это я? У меня большая просьба: распиши, пожалуйста, насколько можешь подробно и конкретно, что и как должен делать прокси-сервер, который ты предлагаешь создать. Постарайся изложить это так, чтобы, прочитав, можно было сесть и написать этот прокси-сервер! :) После этого мы продолжим обсуждение твоего предложения. Обсуждение того, о чем я до сих пор имею крайне смутное и отрывочное представление, я нахожу неконструктивным... Прости за это длинное "лирическое отступление". :)

Теперь возвращаюсь к нашему диалогу. По-моему уточнение, которое ты только что сделал (что прокси-сервер будет прозрачным, то есть иметь тот же протокол ESL, что и сам Freeswitch, чтобы с ним мог работать существующий пульт без доработки) противоречит твоим же словам, написанным ранее в comment:3.

В comment:3 ты писал: "Метаданные для записей я тоже предлагаю запрашивать через
подключение к proxy". Но ведь сейчас через ESL, подключаясь напрямую к Freeswitch, метаданные записей переговоров запросить нельзя, нет сейчас такой функции! То есть предлагается, во-первых, все-таки дополнить протокол новыми функциями, то есть изменить его, а во-вторых, предлагается изменить и пульт тоже - чтобы он запрашивал метаданные записей не из БД, а из прокси!

Далее в том же comment:3 ты пишешь: "Назначить каждому пользователю свой пароль, в этом proxy как раз и может помочь". Но ведь чтобы прокси-сервер аутентифицировал каждого пользователя индивидуально, насколько я понимаю, ему для этого надо будет получить пару значений - "логин" и "пароль". Но существующий протокол ESL такого не предусматривает - там передается один только пароль без всякого логина! Как же возможно не изменяя этого протокола производить аутентификацию разных пользователей прокси-сервером? По-моему это невозможно... Впрочем, может быть, когда ты подробно и конкретно распишешь предлагаемый функционал прокси-сервера, о чем я попросил выше, мне это станет понятно...

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

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

Сейчас он все делает в интерфейсе одной программы: нашел запись, прослушал ее и,
если посчитал интересной, нажатием одной кнопки сохранил ее себе локально

Что значит посчитал интересной.

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

Я не говорю что эту функцию нужно удалить.

В описании тикета ты предложил убрать зависимость пульта от libssh, а в comment:3 ты написал: "Скачивать записи я предлагаю тоже чрез web интерфейс". Я понимаю это так, что в веб-интерфейс эту функцию предлагается добавить, а из пульта - убрать. Потому что если не убирать из пульта функцию скачивания файла по SSH, то каким тогда образом устранить зависимость пульта от libssh?

Я говорю давайте метаданные
конференций получать другим, отличным от запроса к БД, способом.

При чем тут метаданные конференций? Метаданные конференций через SSH не запрашиваются и никогда не запрашивались. Через SSH работают две функции: правка конфиг-файлов FS и копирование файлов записей переговоров с сервера на локальный компьютер пользователя (поправь меня, если я ошибаюсь).

Все ровно так и есть. На сервере обычно 1 IP и 1 домен и все абоненты в
куче.

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

Ну например конференции, которые создает техник для решения своих
задач, не появляются в пульте диспетчера и не отвлекают его.

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

Еще раз, я не призываю отказать от Mysql.

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

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

Если такая проблема возникнет, создай на эту тему тикет, и мы попробуем в нем найти решение проблемы.

[mixyil1.1]

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

Я создал тикет с типом улучшение, предполагая, что тикеты этого типа созданы для
обсуждения добавления/изменения функционала пульта диспетчера. Тикет так и
называется "предложения по ...". Основная задача тикета, как я её вижу, обсудить
нужно/не нужно и, в том числе путем диалога, прийти к общей терминологии в
вопросах прокси, ESL и прочего. А в конце диалога выйти на общий знаминатель вот
это хорошо - делаем, вот это не трогаем, вот это не нужно а вот это без разницы.

Ты предлагаешь сделать прозрачный прокси, который снаружи (по протоколу работы)
ничем не отличается от ESL Freeswitch.

Прокси, прозрачный проски, прямой прокси, прослойка, коннектор, midleware - давай
остановимся на прозрачном прокси. Да, именно это я и предлагаю.

То есть предлагается, во-первых, все-таки дополнить протокол новыми функциями,
то есть изменить его, а во-вторых, предлагается изменить и пульт тоже - чтобы он
запрашивал метаданные записей не из БД, а из прокси!

В этой части, работа с записями, да, конечно. Стандартная практика во
Freeswitch, каждый модуль может дополнить набор функций своим api. Давайте это
сделаем не в модуле Freeswitch а дополним протокол только между прокси и пультом.

Но существующий протокол ESL такого не предусматривает - там передается один
только пароль без всякого логина! Как же возможно не изменяя этого протокола
производить аутентификацию разных пользователей прокси-сервером? По-моему это
невозможно...

Запрос аутентификации в ESL выглядит так:

auth password

Вопрос интерпритации параметра. Давайте передавать на прокси такой запрос

auth login@password

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

Кому ты предлагаешь создать этот веб-интерфейс администратора? Ты создал тикет
мне и, стало быть, предлагаешь это сделать мне? Если да, то мой ответ - нет, так
как по-моему эта задача выходит за рамки задач системы диспетчерской связи. Если
кому-то другому (включая тебя), то, кака я уже писал, на это не требуется
спрашивать моего разрешения. :)

В описании тикета я указал, что готов сделать, если придем к какому-то
решению. Вопрос не в разрешении, а в том что можно "поломать" пульт диспетчера (я
писал про mod_xml_curl и api list_users выше). Вопрос про обсудить возможные
нюансы и как их избежать, тикет по проблеме всегда можно создать, но можно
обговорить потенциальные проблемы сразу.

Я не говорю что эту функцию нужно удалить.

Потому что если не убирать из пульта функцию скачивания файла по SSH, то каким
тогда образом устранить зависимость пульта от libssh?

Я предлагал убрать зависимость от libssh, но раз она нужна для функции, которой
кто-то иногда пользуется, то тогда конечно не нужно. Это мой ответ на этот комментарий

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

---

У меня большая просьба: распиши, пожалуйста, насколько можешь подробно и
конкретно, что и как должен делать прокси-сервер

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

[alx]

Replying to mixyil1.1:

Я создал тикет с типом улучшение, предполагая, что тикеты этого типа созданы для
обсуждения добавления/изменения функционала пульта диспетчера. Тикет так и
называется "предложения по ...". Основная задача тикета, как я её вижу, обсудить
нужно/не нужно и, в том числе путем диалога, прийти к общей терминологии в
вопросах прокси, ESL и прочего.

А, в таком случае, прошу прощения - я не понял, что ты предлагаешь обсудить. Тикет называется "Предложения по модернизации системы диспетчерской связи", а не "Проедложение обсуждения...". И в первой строке описания тикета написано: "У меня есть предложения по внесению изменений в программу Dispatcher и систему диспетчерской связи в целом", а не "У меня есть предложение обсудить возможные изменения...". Поэтому я думал, что ты предлагаешь мне внести в код MC04Dispatched некие конкретные изменения, а не обсуждение. :) Спасибо за уточнение.

Думаю, что свое мнение по теме обсуждения я уже высказал.

Вопрос интерпритации параметра. Давайте передавать на прокси такой запрос

auth login@password

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

В comment:9 ты писал: "Специально уметь работать с прокси пульту и не нужно, пульт шлет сообщения как и прямом подключении к Freeswitch, ничего на стороне пульта менять не надо". Сейчас пульт не передает параметр команды auth в формате login@password, он передает его в формате password, то есть без логина. Таким образом, чтобы начать работать с прокси и передавать команду auth с параметром в форме login@password, изменения на стороне пульта потребуются.

В описании тикета я указал, что готов сделать, если придем к какому-то
решению. Вопрос не в разрешении, а в том что можно "поломать" пульт диспетчера (я
писал про mod_xml_curl и api list_users выше). Вопрос про обсудить возможные
нюансы и как их избежать, тикет по проблеме всегда можно создать, но можно
обговорить потенциальные проблемы сразу.

По list_users я уже ответил - проблемы, описанной тобой в примере 1 comment:3, нет. Вропрос по mod_xml_curl можно обсудить. Только мне не нравится обсуждать в одном тикете кучу разных вопросов сразу. Когда в таком тикете становится больше сотни комментариев, находить в нем то, что написано по одной конкретной теме становится крайне трудно. Поэтому я и писал выше - если у тебя есть необходимость обсудить работу пульта с динамическим конфигом FS, создай, пожалуйста, отдельный тикет, в котром будет обсуждаться эта и только эта тема.

И еще один "процедурный" вопрос: ты ведь не являешься сотрудников АДС? Я могу обращаться к тебе по имени?

[mixyil1.1]

Replying to alx:

Сейчас пульт не передает параметр команды auth в формате login@password, он передает его в > формате password, то есть без логина. Таким образом, чтобы начать работать с прокси и передавать > команду auth с параметром в форме login@password, изменения на стороне пульта потребуются.

Нет. Не потребуются

mysql> update options set value = '1@adc' where name = 'event-socket-pwd';

0 изменений на стороне пульта.

И еще один "процедурный" вопрос: ты ведь не являешься сотрудников АДС? Я могу обращаться к тебе по имени?

Нет, не являюсь. Я не возражаю.

[alx]

Replying to mixyil1.1:

mysql> update options set value = '1@adc' where name = 'event-socket-pwd';

0 изменений на стороне пульта.

Подожди... Так это же и есть та самая "кривая" схема, от которой хотелось избавиться! Чем в предлагаемом тобой варианте 1@adc лучше чем просто adc?

[mixyil1.1]

Replying to alx:

Подожди... Так это же и есть та самая "кривая" схема, от которой хотелось избавиться! Чем в предлагаемом тобой варианте 1@adc лучше чем просто adc?

Я отвечал на твое конкретное замечание "чтобы начать работать с прокси и передавать команду auth с параметром в форме login@password, изменения на стороне пульта потребуются". Чтобы начать работать с прокси не меняя текущую схему аутентификации изменения в пульте не требуются.

Да, я предлагаю изменить схему аутентификации. Изменение схемы естественно потребует изменения в пульте, но не только и не столько в компоненте ESL.

Еще раз - чтобы начать работать с прокси изменений на строне пульта не требуется.

[alx]

У меня возник вопрос, касающийся приложенного патча (qt6.patch).

Для места, в котором производится валидация имени конференции как имени пользователя SIP URI, предложен такой код:

    QRegularExpression re("^[A-Za-z0-9\\-_.!~*'()]+$");
    auto match = re.match(conference);
    QString username = match.hasMatch() && match.capturedStart() == 0
        ? match.captured() 
        : "conference";

Я не понял, для чего потребовалось условие match.capturedStart() == 0. Насколько я вижу, регулярное выражение начинается с якоря начала строки (^) и, следовательно, совпадение, начинающееся не с начала строки произойти не может. Таким образом, условие match.capturedStart() == 0 (в случае совпадения регулярного выражения) выполняется всегда. Михаил, не мог бы ты пояснить?

[alx]

В процессе чтения приложенного патча (qt6.patch) я обнаружил в нем изменения к проекту pjsip (а именно, к файлу pjproject-2.10/aconfigure). Насколько я знаю, pjsip не использует QT. Поясни, пожалуйста, почему переход с QT5 на QT6 потребовал внесения изменений в код pjsip? Или эти изменения попали в патч по ошибке?

[mixyil1.1]

Replying to alx:

В процессе чтения приложенного патча (qt6.patch) я обнаружил в нем изменения к проекту pjsip (а именно, к файлу pjproject-2.10/aconfigure). Насколько я знаю, pjsip не использует QT. Поясни, пожалуйста, почему переход с QT5 на QT6 потребовал внесения изменений в код pjsip? Или эти изменения попали в патч по ошибке?

Изменения в pjproject-2.10/aconfigure не должны были попать в патч. Я не заметил этого перед отправкой. Хотя странно почему svn diff включил их в патч.

[mixyil1.1]

Replying to alx:

Я не понял, для чего потребовалось условие match.capturedStart() == 0. Насколько я вижу, регулярное выражение начинается с якоря начала строки (^) и, следовательно, совпадение, начинающееся не с начала строки произойти не может. Таким образом, условие match.capturedStart() == 0 (в случае совпадения регулярного выражения) выполняется всегда. Михаил, не мог бы ты пояснить?

При подготовке патча я стрался не вносить никаких изменений, кроме исправления API qt. Вероятно match.capturedStart() == 0 я добавил машинально, когда "проговаривал про себя" выражение
"^[A-Za-z0-9\\-_.!~*'()]+$" строка начинается с ...

[alx]

In 1068/dispatcher:

Перешли на использование Qt6.
See #593.

[alx]

Так как san в отпуске, а другого разработчика никто не назначал (по крайней мере, мне об этом ничего не известно), я сам изучил и протестировал приложенный к тикету патч. Патч принят с некоторыми изменениями:

• При чтении телефонной книги используется кодировка локали, а не UTF-8.
• Удалена избыточная часть условия при валидации имени конференции как имени пользователя SIP URI.
• В функции ErrorPanel::setAudioDevice() аудио-устройству устанавливается найденный и поддерживаемый устройством формат, а не фиксированный формат 44100 Гц/16 бит/2 канала.
• Файл pjproject-2.10/aconfigure оставлен без изменений.
• Мелкие несущественные (в-основном стилистические) изменения.

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

[alx]

Replying to mixyil1.1:

Хотя странно почему svn diff включил их в патч.

Вероятно, autoconf перегенерил этот файт в процессе сборки пульта.

[mixyil1.1]

Replying to alx:

Вероятно, autoconf перегенерил этот файт в процессе сборки пульта.

-generated by GNU Autoconf 2.69
+generated by GNU Autoconf 2.72

Autoconf перегенерировал этот файл, как минимум версии Autoconf отличаются. Меня удивило зачем aconfigure добавлен под контроль версий, он генерируется автоматически в процессе сборки/конфигурации.

[alx]

Replying to mixyil1.1:

Меня удивило зачем aconfigure добавлен под контроль версий, он генерируется автоматически в процессе сборки/конфигурации.

Этот файл добавлен под контроль версий, так как он присутствует в дистрибутиве pjsip. В дистрибутиве 2650 различных файлов и каталогов. Я не посчитал необходимым анализировать каждый из них на предмет действительно ли он является исходным или генерируется в процессе сборки/конфигурации. :) Я просто сделал svn add pjproject-2.10, доверившись его разработчикам.

[mixyil1.1]

Попробую еще раз объяснить суть своего предложения.

Добавить компонент Прокси.

Цель:
Расширение возможностей пульта без модификации (с минимальныйми изменениями) Qt-приложения.

Назначение:
Прокси-сервер выступает промежуточным звеном между пультом (Qt-приложение) и FreeSWITCH, обеспечивая взаимодействие через ESL-протокол.

Основные функции:

1. Принимает запросы от пульта (api, bgapi, event, ...) и транслирует их в FreeSWITCH без изменений.
2. Может дополнять или заменять ESL-команды обращениями к API, БД или другим системам.
3. Пересылает ответы от FreeSWITCH на пульт в исходном виде или модифицирует их.
4. Передает события с FreeSWITCH на пульт.

Дополнительные функции:

1. Аутентификация, ограничение доступа, фильтрация команд, SSL/TLS.
2. Взаимодействие с внешними сервисами/устройствами.
3. Кеширование ответов от FS.
4. Управление состоянием (хранит собственный state).
5. Расширение протокола между пультом и прокси.

Место размещения:
Сервер.

Добавить компонент интерфейс управления (web интерфейс).

Цель:
Предоставить техническому персоналу систему управления динамическими параметрами
FreeSWITCH (конференции, пользователи, ACL, правила набора) без необходимости
редактирования XML-файлов вручную.

Назначение:
Замена ручного редактирования XML на веб-интерфейс. Изменение конфигурации
Freeswitch в реальном времени.

Основные функции:

1. Добавление/удаление/редактирование SIP-пользователей.
2. Добавление/удаление/редактирование профилей конференц комнат.
3. Добавление/удаление/редактирование правил набора.
4. Добавление/удаление/редактирование SIP-профилей.
5. Добавление/удаление/редактирование шлюзов.
6. Управление ACL.
7. Динамическая конфигурация Freeswitch. Взаимодействие через mod_xml_curl.

Дополнительные функции:

1. Контроль доступа - роли (админ, техник).
2. Доступ к записям конференций.

Место размещения:
Сервер.

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

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