Opened 8 years ago

Closed 8 years ago

#246 closed улучшение (fixed)

Отображение конференций в программе

Reported by: san Owned by: dimag
Priority: critical Milestone: 1 очередь
Component: ПО MC04-Dispatcher. Пульт диспетчера/техника Keywords: algorithm
Cc: alx

Description

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

Попробую на примере показать как всё должно выглядеть.
Диспетчер вызывает абонентов a1, a2, a3 в конф1:

  1. Диспетчер создал заготовку из 3 абонентов и нажал вызов.
  2. Три абонента вызываются в конф1
  3. Диспетчер и техник видят в списке конференций конф1 и в ней 3 вызываемых абонента.
  4. Абонент а1 подключился в конф1.,(на сервере была создана конф1) диспетчер и техник видят в списке абонентов конф1, что кнопка абонента а1 изменилась к виду "подключен", кнопки а2 и а3 в состоянии "вызывается".
  5. Абонент а1 покинул конф1.,
  6. В реальности конф1 была закрыта, но диспетчер и техник продолжают видеть её в списке конференций кнопка абонента а1 в списке абонентов конференции стала красной, кнопки абонентов a2,a3 в состоянии "вызывается".
  7. а2 и а3 отклонили вызов
  8. Диспетчер/Техник видят в конф1: а1,а2 и а3 с красными кнопками.
  9. Техник нажимает в конф1 общую кнопку "вызвать" - повторный вызов абонентов с красными кнопками.
  10. а1,а2 и а3 снова вызываются в конф1., диспетчер/техник видят кнопки абонентов в состоянии "вызывается".
  11. а1,а2 и а3 подключились к конф1 диспетчер/техник видят кнопки абонентов в состоянии "подключен".

Attachments (1)

presence_in.png (18.8 KB ) - added by san 8 years ago.

Download all attachments as: .zip

Change History (55)

comment:1 by san, 8 years ago

К этому алгоритму у меня возникают некоторые вопросы и, мне кажется остались неопределённости.
Вот например некоторые вопросы:

  1. Что отображать у Техника когда конференция была закрыта Диспетчером?

Думаю логично убрать конференцию из списка


  1. Что отображать когда конференция закрылась автоматически (остался один участник)?

Например:

  • Диспетчер вызывает а1 и а2 в конф1
  • оба пользователя добавились в конф1
  • а1 покинул конф1 - его кнопка стала красной
  • а2 остался один в конф1 - конф1 автоматически закрывается

Получается что нужно отобразить а1 и и а2 с красными кнопками


  1. Что отображать у Техника, когда Диспетчер нажал красный крестик на абоненте.

Получается что у Техника этот абонент останется с красной кнопкой


  1. Что делать с именем конференции? Например была создана конф1, затем на сервере она была завершена, а у Диспетчера она ещё отображается как конф1. Если в этот момент авторизуется Техник, он не будет знать о конф1. И может создать конференцию с таким же именем.
  • либо оставить так - абоненты вызваные Техником в конф1 отобразятся в конф1 Диспетчера вместе с его "красными" абонентами
  • либо давать конференциям уникальные имена



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

comment:2 by alx, 8 years ago

По "1", "2" и "3": мне кажется, логика отображения конференций/абонентов не должна зависеть от того, как и почему они появляются/исчезают (сам ли пользователь ушел или его отключил диспетчер, сама ли конференция закрылась или ее уничтожили насильно). Мне кажется, у пользователя пульта должна быть настройка: отображать ли пропавших участников бесконечно (пока "плашка" не будет удалена вручную), либо какое-то время (настраиваемое количество секунд). Так, например, делает jabber-клиент gajim - когда контакт отключается, он несколько секунд индицирует его другим цветом (красным), а затем убирает его из списка.

Мне более интересен другой момент из "1" - каким образом пульт техника будет узнавать, что диспетчер вызвал кого-то в конференцию до того как эта конференция будет реально создана? Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...

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

in reply to:  2 comment:3 by san, 8 years ago

Replying to alx:

Мне более интересен другой момент из "1" - каким образом пульт техника будет узнавать, что диспетчер вызвал кого-то в конференцию до того как эта конференция будет реально создана? Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...

Дима мне говорил, что уже умеет получать эту информацию из какого-то существующего события ESL.

comment:4 by dimag, 8 years ago

Keywords: algorithm added

Сообщение PRESENCE_IN, поле status - по не можно узнать что кто-то звонит.
Сообщение CHANNEL_CALLSTATE, поле Answer-State - по не можно также узнать что кто-то звонит.

in reply to:  4 comment:5 by alx, 8 years ago

Replying to dimag:

...можно узнать что кто-то звонит.

И? "Кто-то звонит" и "пользователя вызывают в конференцию" - не одно и то же...

by san, 8 years ago

Attachment: presence_in.png added

comment:6 by san, 8 years ago

Дима мне показал содержание сообщения PRESENCE_IN


В параметрах выделенных красным присутствует uri вызывающего, uri вызываемого и имя конференции.
Разве этого не достаточно?

in reply to:  6 comment:7 by alx, 8 years ago

Replying to san:

В параметрах выделенных красным присутствует uri вызывающего, uri вызываемого и имя конференции.

??? Я вижу в выделенном на картинке номер вызываемого, номер вызывающего и имя вызывающего. Имени конференции не вижу...

Разве этого не достаточно?

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

comment:8 by san, 8 years ago

Вызвал абонентом Техник4(4@..) абонента ГРС_201 (201@..) в Конференцию_1.
Вижу в поле Caller-Caller-ID-Name значение "Конференция_1", откуда оно там взялось и какой логике подчиняется я не знаю.

comment:9 by alx, 8 years ago

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

comment:10 by san, 8 years ago

В нашей ситеме Диспетчерской связи подразумевается что только пульты Диспетчера/Техника имеют право вызывать пользователя в конференцию.
Можем мы договориться о том что имя конферении будем всегда подставлять вкачестве имени вызывающего и использовать эту фичу для реализации задачи тикета? Как ты считаешь, Алексей, насколько это "правильно"?

in reply to:  10 ; comment:11 by alx, 8 years ago

Replying to san:

В нашей ситеме Диспетчерской связи подразумевается что только пульты Диспетчера/Техника имеют право вызывать пользователя в конференцию.

А согласится ли с таким постулатом Заказчик? Насколько я помню, ко мне (через тебя) дважды обращались с просьбой настроить в dialplan'е возможность прямого вызова операторов ("прямого" в смысле не в конференцию)...

Можем мы договориться о том что имя конферении будем всегда подставлять вкачестве имени вызывающего и использовать эту фичу для реализации задачи тикета? Как ты считаешь, Алексей, насколько это "правильно"?

Мне это не кажется хорошей идеей.

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

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

in reply to:  11 ; comment:12 by san, 8 years ago

Replying to alx:

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

Техник связи "контролирует" работу Диспетчерской, и хочет видеть все действия и их последствия:
допустим Диспетчер вызывает на "режим" 10 операторов ГРС, А оператор "ГРС Простоквашино" не ответил на вызов. Если техник сразу это увидит, он может принять меры раньше, не дожидаясь звонка от Диспетчера.

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

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

Алексей, я так понимаю ты предлагаешь такой вариант для синхронизации ?

Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...

in reply to:  12 ; comment:13 by alx, 8 years ago

Replying to san:

Алексей, я так понимаю ты предлагаешь такой вариант для синхронизации ?

Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...

Да, это мне кажется наиболее логичным, так как подключение к FS по ESL и так уже есть. Это проще чем самостоятельно отслеживать наличие других пультов и слать им сообщения напрямую (не надо плодить сущности без необходимости).

В описанном варианте есть единственный вопрос - как сгенерировать нужное событие командой API. Если в каком-то модуле такая команда уже есть, можно использовать ее. Если нет - можно добавить такую команду в mod_conference_cdr_mysql, раз уж он все равно у нас есть.

Есть еще другой вариант. Насколько я помню, где-то в конфигурации FS можно сказать волшебное слово, в результате чего в сообщениях, касающихся соединений, будут перечислены все channel variables. Тогда, инициируя вызов, пульт мог бы устанавливать какую-нибудь специальную переменную (например x-mc04-invite-to-conf=conference-name), а другие пульты, увидев в сообении CHANNEL_CALLSTATE (или каком-то другом) переменную x-mc04-invite-to-conf, поняли бы, что это именно вызов в конференцию conference-name, а не что-то другое...

Last edited 8 years ago by alx (previous) (diff)

comment:14 by san, 8 years ago

Priority: criticalmajor

comment:15 by dimag, 8 years ago

Resolution: fixed
Status: newclosed

r318
Программа при запуске определяет соединения с конференцией "Диспетчерская" в процессе вызова и выводит их.
Это достаточно или есть ещё какие-то замечания?

in reply to:  13 comment:16 by alx, 8 years ago

Replying to alx:

В описанном варианте есть единственный вопрос - как сгенерировать нужное событие командой API.

Нет вопроса. Произвольное событие можно передать непосредственно в event-socket с помощью sendevent - см. https://freeswitch.org/confluence/display/FREESWITCH/mod_event_socket

comment:17 by san, 8 years ago

Resolution: fixed
Status: closedreopened

не вижу причин закрывать тикет

in reply to:  17 comment:18 by alx, 8 years ago

Replying to san:

не вижу причин закрывать тикет

В comment:15 Дима пишет, что описанное в тикете улучшение реализовано в r318. Это по-моему и есть причина. :)

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

comment:19 by dimag, 8 years ago

Закрывать или нет?

comment:20 by san, 8 years ago

В r318 сделано всё описанное в тикете?
(пока тут всё было на стадии обсуждения, поэтому я был удивлён внезапным закрытием тикета)

comment:21 by dimag, 8 years ago

Сообщи что ещё надо сделать.

comment:22 by san, 8 years ago

продолжить обсуждение

comment:23 by dimag, 8 years ago

Что надо обсудить?

comment:24 by san, 8 years ago

Вопросы поднятые в тикете и в коментариях

comment:25 by san, 8 years ago

Я бы хотел выполнение пунктов 1. и 2. описанных в тикете, как минимум, для "Основной конференции".

Дима, каким образом мы будем передавать информацию о своих действиях(вызовах) другим пользователям?

comment:26 by san, 8 years ago

Дмитрий не ответил на мой вопрос. Задам ещё один.
В r471 заметил что в конференциях отображаются абоненты на стадии вызова
Дима, каким способом ты передаёшь информацию о вызовах абонентов?

comment:27 by dimag, 8 years ago

Как я определяю наличие внешней конференции.
Обрабатываю сообщение Event-Name с именем PRESENCE_IN.
Если статус в сообщение CS_ROUTING, состояние ответа("Answer-State") равно "ringing", то получаем имя конференции из поля "Caller-Caller-ID-Name", если значение в этом поле отсутствует в списке известных конференций, то добавляем новую внешнюю конференцию, если есть, то добавляем нового пользователя конференции.

in reply to:  27 comment:28 by alx, 8 years ago

Replying to dimag:

Обрабатываю сообщение Event-Name с именем PRESENCE_IN.
Если статус в сообщение CS_ROUTING, состояние ответа("Answer-State") равно "ringing", то получаем имя конференции из поля "Caller-Caller-ID-Name",

Дима, Вы принципиально не читаете комментарии к тикетам? Изложенный Вами алгоритм не годится, и в comment:9 написано почему.

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

Event-Name: PRESENCE_IN
Core-UUID: 67a7e494-5922-4c35-a8bd-cbc673a655b2
FreeSWITCH-Hostname: voip.kolez.com
FreeSWITCH-Switchname: voip.kolez.com
FreeSWITCH-IPv4: 192.168.0.63
FreeSWITCH-IPv6: 2a01%3A540%3A2f02%3Af200%3A922b%3A34ff%3Afe33%3A882b
Event-Date-Local: 2016-10-05%2010%3A40%3A26
Event-Date-GMT: Wed,%2005%20Oct%202016%2007%3A40%3A26%20GMT
Event-Date-Timestamp: 1475653226915703
Event-Calling-File: switch_channel.c
Event-Calling-Function: switch_channel_perform_presence
Event-Calling-Line-Number: 785
Event-Sequence: 6255570
Channel-State: CS_ROUTING
Channel-Call-State: RINGING
Channel-State-Number: 4
Channel-Name: sofia/internal/test13%40192.168.0.63
Unique-ID: e1d88bdf-79e3-4ef2-be3c-ab924d865377
Call-Direction: inbound
Presence-Call-Direction: inbound
Channel-HIT-Dialplan: true
Channel-Presence-ID: test13%40192.168.0.63
Channel-Call-UUID: e1d88bdf-79e3-4ef2-be3c-ab924d865377
Answer-State: ringing
Caller-Direction: inbound
Caller-Logical-Direction: inbound
Caller-Username: test13
Caller-Dialplan: XML
Caller-Caller-ID-Name: Alex%20Mogilnikov
[... далее поскипано ...]

Таким образом, в соответствии с изложенным Вами алгоритмом программа должна была отобразить конференцию с именем "Alex Mogilnikov", что, очевидно, неправильно, так как конференцию с таким именем никто создавать не пытался.

Более того, в пульте диспетчера в списке конференций конференция "Alex Mogilnikov" не появилась (проверялось в r482). Таким образом, описанный Вами алгоритм не соответствует реальному поведению программы.

Last edited 8 years ago by alx (previous) (diff)

comment:29 by dimag, 8 years ago

Забыл упомянуть - Имя внешней конференции должно содержать строку "Конференция", если этой строки нет, то сообщение игнорируется.

in reply to:  29 comment:30 by alx, 8 years ago

Replying to dimag:

Имя внешней конференции должно содержать строку "Конференция",

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

comment:31 by dimag, 8 years ago

Распознать что пришло сообщение именно для конференции, а не для прямых сообщений между абонентами можно по параметру "Caller-Callee-ID-Name" или по параметру "Caller-Caller-ID-Name" для конференций значение одного из этих параметров будут равны "Outbound%20Call", другое параметр будет содержать имя конференции.
В остальных случаях параметры указанные выше будут иметь другие значения.

in reply to:  31 comment:32 by alx, 8 years ago

Replying to dimag:

для конференций значение одного из этих параметров будут равны "Outbound%20Call",

  1. Обоснуйте, пожалуйста, это утверждение. На основании чего Вы сделали такой вывод?
  2. Даже если это так, для распознавания вызова в конференцию недостаточно доказать, что при вызове в конференцию одно из этих полей будет иметь значение "Outbound%20Call". Надо еще доказать, что при любом другом вызове (не в конференцию) эти поля не могут принмать значение "Outbound%20Call". Иначе есть возможность ошибочного (ложного) вывода о том, что имеет место вызов в конференцию...

comment:33 by dimag, 8 years ago

На основание наблюдений.

in reply to:  33 comment:34 by alx, 8 years ago

Replying to dimag:

На основание наблюдений.

Я только что провел простой эксперимент: в консоли FS дал команду:

originate user/test13 &echo()

и в результате ее выполнения получил событие PRESENCE_IN с Caller-Callee-ID-Name: Outbound%20Call. Таким образом, этот признак для определения вызова в конференцию не годится.

comment:35 by san, 8 years ago

Summary: Отображение конференций в программе, дополнениеОтображение конференций в программе

На данный момент(r487) вижу такие проблемы в текущей реализации этой задачи:

  1. В качестве признака вызовов пользователя в конференцию используется не достоверная информация
  1. баг:

В некую конф1 пользователь Техник вызывает абонентов
Диспетчер видит (ещё не созданную конф1) но добавить туда абонентов не может

  1. Для более логичного восприятия требуется реализация #321 #240

comment:36 by san, 8 years ago

Milestone: Текущее1 очередь
Priority: majorcritical

Переношу в "1-ю очередь" т.к. функция реализована, но криво, и теперь влияет на работоспособность программы

comment:37 by dimag, 8 years ago

r488
Пользователь может добавлять и удалять пользователей из всех конференций находящихся в процессе создания.

comment:38 by alx, 8 years ago

Дима, разъясните, пожалуйста, назначение макроса USER_STATE_IN_CALL. И макроса USER_STATE_CALL_SUCCESS тоже.

Last edited 8 years ago by alx (previous) (diff)

comment:39 by dimag, 8 years ago

USER_STATE_IN_CALL - абонент в процессе вызова
USER_STATE_CALL_SUCCESS - вызов абонента прошёл успешно абонент в конференции или есть состояние прямой связи между двумя абонентами.

comment:40 by dimag, 8 years ago

Предлагаю для определения вызова в конференцию посылать после выполнения команды originate сообщение следующего формата:
MC04Conference_Proposed('[имя конференции'], имя пользователя, UUID устанавлимоего соединения)
UUID - если абонент не в сети, то пустая строка.

comment:41 by dimag, 8 years ago

Алексей, ваше мнение о предложение выше, будет ли посылка сообщения при добавление в конференцию/создание конференции, как описано выше, достоверным признаком?

in reply to:  39 comment:42 by alx, 8 years ago

Replying to dimag:

USER_STATE_IN_CALL - абонент в процессе вызова

Вижу что некая переменная проверяется на равенство этому макросу, но присваивания этого макроса не вижу. Я правильно понимаю, что эти проверки всегда дают false?

USER_STATE_CALL_SUCCESS - вызов абонента прошёл успешно абонент в конференции или есть состояние прямой связи между двумя абонентами.

Для чего введен этот макрос, если он нигде не используется?

in reply to:  40 comment:43 by alx, 8 years ago

Replying to dimag:

Предлагаю для определения вызова в конференцию посылать после выполнения команды originate сообщение следующего формата:

Что Вы подразумеваете под форматом? Формат событий (plain, json, xml) определяется при подписке на них.

MC04Conference_Proposed('[имя конференции'], имя пользователя, UUID устанавлимоего соединения)

А для чего сообщать UUID устанавливаемого соединения? И еще здесь не хватает домена пользователя...

UUID - если абонент не в сети, то пустая строка.

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

in reply to:  41 comment:44 by alx, 8 years ago

Replying to dimag:

Алексей, ваше мнение о предложение выше, будет ли посылка сообщения при добавление в конференцию/создание конференции, как описано выше, достоверным признаком?

Достоверным признаком чего?

comment:45 by dimag, 8 years ago

USER_STATE_CALL_SUCCESS - используется для прямых соединений абонентов между собой
Формат сообщений plain.
UUID нужен для случая если пользователь захочет отменить соединение.
В предполагаемую конференцию можно добавлять абонента который не в сети, при вызове он автоматически станет абонентом вызов которого произошёл неудачно, другие пользователи наверно тоже захотят увидеть что была попытка такого абонента.
Достоверным признаком чего? - попытки создания новой конференции, который невозможно перепутать ни с чем.

in reply to:  45 comment:46 by alx, 8 years ago

Replying to dimag:

USER_STATE_CALL_SUCCESS - используется для прямых соединений абонентов между собой

Можете назвать имя файла и номер строки в нем, где используется макрос USER_STATE_CALL_SUCCESS?

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

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

Достоверным признаком чего? - попытки создания новой конференции, который невозможно перепутать ни с чем.

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

Last edited 8 years ago by alx (previous) (diff)

comment:47 by dimag, 8 years ago

То есть вы согласны с использованием сообщения MC04Conference_Proposed для индикации попытки создания новой конференции? Если да, то переделаю программц новое сообщение.

in reply to:  47 comment:48 by alx, 8 years ago

Replying to dimag:

То есть вы согласны с использованием сообщения MC04Conference_Proposed для индикации попытки создания новой конференции? Если да, то переделаю программц новое сообщение.

Я не могу с этим ни согласиться, ни не согласиться, так как я не знаю, что это за сообщение такое - MC04Conference_Proposed.

comment:49 by dimag, 8 years ago

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

comment:50 by dimag, 8 years ago

Алексей?

in reply to:  50 comment:51 by alx, 8 years ago

Replying to dimag:

Алексей?

Дмитрий?

В чем смысл вашего комментария?

comment:52 by dimag, 8 years ago

Вы согласны с использованием описанного выше сообщения и его параметров? Не будет ли, по ваше мнению, каких-либо проблем со FreeSwitch.
Если вы согласно, то я переделаю программу на заданное сообщение.

in reply to:  52 comment:53 by alx, 8 years ago

Replying to dimag:

Вы согласны с использованием описанного выше сообщения и его параметров?

Ходим по кругу. Этот вопрос Вы уже задавали в комментарии 47. И в комментарии 48 я на него ответил. Еще раз: я не могу с этим ни согласиться, ни не согласиться, так как я не знаю, что это за сообщение Вы будете посылать. Да, Вы уточнили, при каких обстоятельствах (при создании новой конференции) Вы будете посылать это сообщение. Но о самом сообщении (кроме того что в нем будет содержаться имя пользователя, имя конференции и UUID соединения) я так ничего и не знаю.

Не будет ли, по ваше мнению, каких-либо проблем со FreeSwitch.

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

Если вы согласно, то я переделаю программу на заданное сообщение.

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

comment:54 by alx, 8 years ago

Resolution: fixed
Status: reopenedclosed

Реализовано в ветке source:branches/user-list-model@642.
Позднее будет добавлено в транк.

Note: See TracTickets for help on using tickets.