Opened 10 months ago
Last modified 5 hours ago
#408 new задача
Новое окончание, заменяющее PPS для применения в дисппетчерской связи
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | высокий | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description
Окончание PPS на практике нашло нестандартное применение - с помощью него можно организовать систему телефонной диспетчерской связи работающую через групповой канал TDM. Однако при таком применении, использование окончания PPS приводит к ограничениям:
- ограничение количества участников: символов DTMF не много, учитывая команды группового вызова и отбоя остаётся Диспетчер + 12 операторов. Хотя по условиям заказчика количество операторов может быть до 50.
- необходимость для вызова отдельного оператора создавать отдельное окончание и подключать его в групповой канал (а сумматор групповых каналов у нас тоже очень ограничен)
Требуется разработать новое окончание(назовём его например DST2), позволяющее избежать этих ограничений при организации диспетчерской связи. Окончание должно выполнять такие функции:
- подключение оператора к групповому каналу с одновременным вызовом Диспетчера(если он ещё не подключен)
- вызов Диспетчером оператора в групповой канал
- вызов Диспетчером группы операторов в групповой канал. Группа операторов должна быть задана заранее с помощью указания префикса или перечисления операторов или другим способом.
- передача номера, подключившегося к групповому каналу оператора, на телефон диспетчера
- опциональная возможность отключения всех операторов от группового канала при отключении диспетчера
p.s. В устном разговоре обсуждалось использование для этой цели сигнализации на основе сигналов Caller ID в отдельном от разговорного групповом канале. В таком случае разумно предусмотреть возможность использование одного группового канала сигнализации для нескольких независимых друг от друга голосовых каналов.
Attachments (3)
Change History (45)
comment:1 by , 10 months ago
follow-up: 5 comment:2 by , 10 months ago
Replying to san:
Окончание должно выполнять такие функции:
- подключение оператора к групповому каналу с одновременным вызовом Диспетчера(если он ещё не подключен)
??? Это я не понял... Почему это должно выполнять канальное окончание? Это же функция диспетчерского пульта (или конференции если используется конференция VE-01)...
comment:3 by , 10 months ago
Replying to san:
- передача номера, подключившегося к групповому каналу оператора, на телефон диспетчера
??? Это тоже никак не зависит от абонентского канального окончания, это функция конференции.
comment:4 by , 10 months ago
Еще одно соображение. Когда-то в устной беседе говорилось, что протокол управления радиоретрансляторами тоже надо менять, так как ППС-Р3 мы реально не используем, а его протокол не устраивает отсутствием адресной информации (в смысле, что диспетчерской конференции не передается информация о том, какая радиостанция подключилась к каналу).
Чтобы дважды не разрабатывать протокол, предлагаю дождаться постановки задачи по управлению радиоретрансляторами и/или пригласить его разработчиков поучаствовать в разработке протокола.
comment:5 by , 10 months ago
Replying to alx:
- подключение оператора к групповому каналу с одновременным вызовом Диспетчера(если он ещё не подключен)
Это же функция диспетчерского пульта (или конференции если используется конференция VE-01)...
Уточню: под "это" я имел в виду подключение диспетчера. Оператора подключать должно, конечно, канальное окончание, по нему вопросов нет.
follow-ups: 8 11 comment:6 by , 10 months ago
Поскольку применение окончания PPS, которое требуется "переизобрести", нестандартное, для начала опиши, пожалуйста, это применение (а еще лучше обрисуй в картинках).
Конференция между диспетчером и операторами организуется с помощью группового канала.
- Когда Оператор вызывает своё окончание PPS оно, подключает Оператора к групповому каналу и передаёт в канал DTMFB, получив этот сигнал, окончание "PPS групповое" на стороне Диспетчера вызывает Диспетчера в групповой канал.
- Когда Диспетчер вызывает окончание "PPS групповое" в канал передаётся DTMFA, что приводит к вызову всех операторов в канал
- Когда диспетчер вызывает окончание PPS1, в канал передаётся DTMF1 в результате на сигнал реагирует только окончание Оператора1 и вызывает Оператора1 в канал.
подключение оператора к групповому каналу с одновременным вызовом Диспетчера(если он ещё не подключен)
Это я не понял... Почему это должно выполнять канальное окончание? Это же функция диспетчерского пульта (или конференции если используется конференция VE-01)
При такой схеме подключения конференция не нужна. Голоса участников смешиваются при помощи сумматоров в групповом канале. При подключении оператора к каналу, окончание на стороне диспетчера должно вызвать заданное uri, в данном случае это телефон диспетчера.
Если пользователь работает с настоящими конференциями. то он может просто использовать окончание DS, для подключения операторов. А это новое окончание задумывается именно для случая когда у пользователя нет возможности использовать конференции.
передача номера, подключившегося к групповому каналу оператора, на телефон диспетчера
Это тоже никак не зависит от абонентского канального окончания, это функция конференции.
Т.к. конференции нет, то было бы удобно если окончание на стороне диспетчера могло передать номер вызывающего оператора при вызове Диспетчера в канал и может быть даже передать номер последнего подключившегося оператора если диспетчер уже подключен к окончанию.
Вот схема применения нового окончания:
by , 10 months ago
by , 10 months ago
comment:7 by , 10 months ago
Чтобы дважды не разрабатывать протокол, предлагаю дождаться постановки задачи по управлению радиоретрансляторами и/или пригласить его разработчиков поучаствовать в разработке протокола.
Вадим(разработчик ретрансляторов и RT-01) говорит что ему хватает возможностей PPS, Алексей(разработчик RT-01), говорит, что при необходимости просто реализует поддержку нашего протокола на RT-01, производительности у платы достаточно и особых пожеланий у него нет.
comment:8 by , 10 months ago
Replying to san:
Почему это должно выполнять канальное окончание? Это же функция диспетчерского пульта (или конференции если используется конференция VE-01)
При такой схеме подключения конференция не нужна. Голоса участников смешиваются при помощи сумматоров в групповом канале. При подключении оператора к каналу, окончание на стороне диспетчера должно вызвать заданное uri, в данном случае это телефон диспетчера.
А, я понял. Ты так делал, потому что у нас не было функции статических конференций. Поэтому при отсутствии MC04-SoftSwitch окончание PPS ("групповое") вызывало не конференцию, а непосредственно диспетчера...
А это новое окончание задумывается именно для случая когда у пользователя нет возможности использовать конференции.
Да, я понял. Спасибо за описание и картинки.
Вот что я думаю по этому поводу. Так как теперь (с появлением статических конференций в плате VE-01) возможность использовать конференции есть у всех (и у "богатых", и у "бедных"), а разработчика радиоретранслятора и так все устраивает, то, получается, что в этом новом окончании нет необходимости. Можно просто использовать конференцию (либо в MC04-SoftSwitch, либо в плате VE-01).
Из функций, перечисленных в описании тикета, на данный момент не выполняется только пункт 3 (вызов группы абонентов). Причем при использовании MC04-Dispatcher и MC04-SoftSwitch проблем нет, так как пульт диспетчера при вызове группы сразу внутри себя преобразует это в несколько вызовов - к каждому члену группы. Проблема будет только при организации конференции средствами VE-01, так как с ней MC04-Dispatcher не может использоваться.
Мне кажется, будет гораздо лучше, если вместо разработки нового канального окончания с самодельным нестандартным протоколом сигнализации мы добавим функцию вызова группы абонентов в конференцию. Тем более что у нас уже есть "группы вызова" - только сейчас они работают по-другому.
Как вариант можно сделать так, что при вызове конференцией существующей группы вызова, она (конференция) вместо вызова группы будет сразу вызывать ее участников (делать отдельный вызов каждому абоненту группы).
Другой вариант - сделать отдельный вид групп, специально для конференций. Но это мне нравится меньше - не хочется множить сущности без особой необходимости...
follow-up: 10 comment:9 by , 10 months ago
возможность использовать конференции есть у всех (и у "богатых", и у "бедных")
Не совсем так.
Диспетчеру с телефоном Yelink(например T21 или T27G) крайне неудобно пользоваться нашей статической конференцией, т.к., такие телефоны не умеют посылать refer вне диалога и вместо простого вызова оператора одной кнопкой(как привык Диспетчер) ему нужно нажимать много кнопок. К сожалению большинство наших пользователей используют такие телефоны, им они нравятся по критерию цена/надёжность, да и Артём для поставок с нашим оборудованием тоже выбрал эти Е-линки.
По этой причине пользователь не может использовать статические конференции для организации "диспетчерской без сервера" и я ищу другие решения, которые будут адекватно работать c "любым" телефоном. На данный момент, самое удобное - это схема с PPS, которую я описал, но её ограничения создают неудобства.
follow-up: 12 comment:10 by , 10 months ago
Replying to san:
По этой причине пользователь не может использовать статические конференции для организации "диспетчерской без сервера"
Хм... Зачем же мы тогда их делали? Получается, что была проделана ненужная работа...
comment:11 by , 10 months ago
Replying to san:
передача номера, подключившегося к групповому каналу оператора, на телефон диспетчера
Т.к. конференции нет, то было бы удобно если окончание на стороне диспетчера могло передать номер вызывающего оператора при вызове Диспетчера в канал
В канал-то оно его передать сможет, но телефон диспетчера этого не услышит, так как на время передачи абоненты отключаются от канала.
и может быть даже передать номер последнего подключившегося оператора если диспетчер уже подключен к окончанию.
Как?
follow-ups: 13 14 18 comment:12 by , 10 months ago
Replying to alx:
Replying to san:
По этой причине пользователь не может использовать статические конференции для организации "диспетчерской без сервера"
Хм... Зачем же мы тогда их делали? Получается, что была проделана ненужная работа...
Предполагалось, что мы будем использовать статические конференции для диспетчерской, но нюанс с тем что не все телефоны умеют в refer, не позволяет. Я надеялся что мы что-нибудь придумаем чтобы обойти эту неприятность...
В канал-то оно его передать сможет, но телефон диспетчера этого не услышит, так как на время передачи абоненты отключаются от канала.
Почему отключаются? у нас ведь вроде планировалось два отдельных канала один для голоса другой для сигнализации, не понял почему абонентам нужно отключаться в момент передачи сигнализации.
Я имел в виду передачу номера вызывающего в инвайте от Диспетчерского окончания к диспетчерскому телефону.
Как?
Тут я тоже имел в виду передачу через Sip. Конкретно как я не знаю, может быть среди сообщений sip есть что-то подходящее.
Суть глазами диспетчера:
У диспетчера sip телефон, Оператор Вася подключается к групповому каналу, на телефон диспетчера приходит вызов, в качестве вызывающего написано что-то вроде "Диспетчерская_Вася", Диспетчер поднимает трубку и подключается к каналу, разговаривает с Васей, на телефоне по прежнему отображается в качестве имени собеседника "Диспетчерская_Вася", затем в групповой канал подключается Петя, и было бы хорошо чтобы в этот момент телефон диспетчера стал отображать "Диспетчерская_Петя".
follow-ups: 15 19 comment:13 by , 10 months ago
Хм... Зачем же мы тогда их делали? Получается, что была проделана ненужная работа...
Я надеялся что мы что-нибудь придумаем чтобы обойти эту неприятность...
Ну вот у меня есть одна идея:
- Требуется вызов оператора в конференцию "одной кнопкой"
- Некоторые телефоны не умеют отправлять рефер одной кнопкой, но все(по крайней мере которые я видел) умеют инвайт одной кнопкой.
Идея в том, что телефон отправит инвайт на какойнибудь определённый номер, "некоторая сущность" примет инвайт и "преобразует его в рефер". Т.е. например получив инвайт на номер xxx123 некоторая сущность вызовет оператора 123 в конференцию ну и заодно добавит туда Диспетчера(того кто отправил инвайт).
comment:14 by , 10 months ago
Replying to san:
В канал-то оно его передать сможет, но телефон диспетчера этого не услышит, так как на время передачи абоненты отключаются от канала.
Почему отключаются?
Потому что так написано в программе. Отключается чтобы не мешать передаче данных, и самим абонентам ее не слушать.
у нас ведь вроде планировалось два отдельных канала один для голоса другой для сигнализации,
Во-первых, это у нас так планировалось. А разработчиками эта функция планировалась для передачи Caller ID телефонному аппарату в процессе разговора.
Во-вторых, у нас планировалось оба варианта - как два отдельных, так и один совмещенный.
не понял почему абонентам нужно отключаться в момент передачи сигнализации.
Я думаю, что если абонент будет говорить, то его речь может помешать телефонному аппарату правильно принять Caller-ID. Да и не очень приятно слышать шипение в процессе разговора...
Я имел в виду передачу номера вызывающего в инвайте от Диспетчерского окончания к диспетчерскому телефону.
А, я понял теперь. :) Я сначала понял как "передать номер в канал", а имелось в виду, оказывается, "вызов диспетчера в канал"...
Тут я тоже имел в виду передачу через Sip. Конкретно как я не знаю, может быть среди сообщений sip есть что-то подходящее.
Ну, тогда тоже INVITE пусть будет.
Суть глазами диспетчера:
У диспетчера sip телефон, Оператор Вася подключается к групповому каналу, на телефон диспетчера приходит вызов, в качестве вызывающего написано что-то вроде "Диспетчерская_Вася", Диспетчер поднимает трубку и подключается к каналу, разговаривает с Васей, на телефоне по прежнему отображается в качестве имени собеседника "Диспетчерская_Вася", затем в групповой канал подключается Петя, и было бы хорошо чтобы в этот момент телефон диспетчера стал отображать "Диспетчерская_Петя".
Непонятно, почему "Диспетчер Петя", если диспетчер по-прежнему продолжает говорить с диспетчером Васей, ведь Вася никуда из канала не делся...
Вообще-то ровно для таких применений индустрией давно уже придуманы конференции, и все между собой более-менее договорились, как это все должно работать. А мы теперь "переизобретаем" то же самое, только через задницу... :( Стыдно становился, как представлю, как люди будут читать описание всей этой фигни в РЭ... Снова прихожу к мысли, что надо разработать и производить собственный телефонный аппарат - в беседе с нашими зарубежными коллегами прошлой зимой эта мысль уже звучала...
comment:15 by , 10 months ago
Replying to san:
Идея в том, что телефон отправит инвайт на какойнибудь определённый номер, "некоторая сущность" примет инвайт и "преобразует его в рефер". Т.е. например получив инвайт на номер xxx123 некоторая сущность вызовет оператора 123 в конференцию ну и заодно добавит туда Диспетчера(того кто отправил инвайт).
Это как-то очень общо... Нужны подробности. Например, я не понял, откуда сущность возьмет URI конференции... Давай подробности.
follow-up: 17 comment:16 by , 10 months ago
Это как-то очень общо... Нужны подробности. Например, я не понял, откуда сущность возьмет URI конференции... Давай подробности.
Ну это же только идея, подробностей я не придумывал. Сущность эта, например, может быть "частью"(функцией) статической конференции
Вообще-то ровно для таких применений индустрией давно уже придуманы конференции, и все между собой более-менее договорились, как это все должно работать. А мы теперь "переизобретаем" то же самое, только через задницу.
Я согласен, я в устном разговоре уже говорил, что мне хотелось бы использовать конференции, тем более именно для этого мы специально сделали статические конференции, нужно только решить проблему с телефонами, которые не умеют в refer.
Снова прихожу к мысли, что надо разработать и производить собственный телефонный аппарат
Я не думаю что в этом есть смысл. Пользователю значительно удобнее купить любой Sip телефон в магазине, чем строго определённую модель определённого производителя, тем более sip-телефоны у пользователей часто уже имеются. Одним из пунктов критики старых систем диспетческой у пользователей является заточенность их под свои аппараты, которые долго/сложно/дорого купить и ремонтировать, т.к. производитель один и альтернативы нет. На мой взгляд перспективнее будет если наши продукты (система диспетчерской) будут работать с "любым" Sip-телефоном (ну пока это так и есть, наша диспетчерская работает с любыми сип телефонами, пользователям это нравится).
comment:17 by , 10 months ago
Replying to san:
Я не думаю что в этом есть смысл. Пользователю значительно удобнее купить любой Sip телефон в магазине, чем строго определённую модель определённого производителя, тем более sip-телефоны у пользователей часто уже имеются.
Кстати, я вспомнил, что в устной беседе ты говорил, что пользователи пользовались другой системой "диспетчерской связи для бедных". Очень интересно, как они там посылали REFER конференции одним нажатием кнопки. Или там тоже это все работало через какие-то костыли, подобные предложенной сущности? Ты не знаешь?
Хотя это уже выходит за рамки темы этого тикета...
comment:18 by , 10 months ago
Replying to san:
У диспетчера sip телефон, Оператор Вася подключается к групповому каналу,
....
...и было бы хорошо чтобы в этот момент телефон диспетчера стал отображать "Диспетчерская_Петя".
Мне подобное поведение не кажется хорошим и правильным (и даже вообще удобным). Смотри:
- Вася вызывает диспетчера, и они начинают говорить. У диспетчера на дисплее "Вася".
- Петя на пару секунд подключается к диспетчерскому каналу (услышал, что там идет разговор, и отключился).
- Диспетчер продолжает разговор с Васей (может быть еще час или дольше), и все это время у него на дисплее написано "Петя"!
По-моему фигня какая-то получается...
follow-up: 20 comment:19 by , 10 months ago
Replying to san:
- Некоторые телефоны не умеют отправлять рефер одной кнопкой, но все(по крайней мере которые я видел) умеют инвайт одной кнопкой.
Ты уверен? Я сейчас подумал, что в большинстве телефонов, которые я видел, это, как минимум, не совсем так. Да, скорее всего, телефон можно настроить так, чтобы при нажатии кнопки вызывался какой-то абонент. Но это только если телефон не занят. А ведь диспетчер, скорее всего, как раз постоянно включен в свой канал! В этом случае, для вызова нового абонента он должен сначала послать BYE в текущий диалог, и только потом посылать новый INVITE! Ты уверен, что Yealink T27G делает это одним нажатием? У меня почему-то есть сомнения... Возможно, нажатий потребуется не одно, а, как минимум, два...
comment:20 by , 10 months ago
Возможно, нажатий потребуется не одно, а, как минимум, два...
Ну я поэтому "одной кнопкой" и написал в кавычках первый раз, имеется ввиду простыми и понятными действиями. Вызов и отбой - это просто и понятно. Нет, в идеале конечно было бы здорово если было совсем одной кнопкой...
Мне подобное поведение не кажется хорошим и правильным (и даже вообще удобным). Смотри:
Вася вызывает диспетчера, и они начинают говорить. У диспетчера на дисплее "Вася".
Петя на пару секунд подключается к диспетчерскому каналу (услышал, что там идет разговор, и отключился).
Диспетчер продолжает разговор с Васей (может быть еще час или дольше), и все это время у него на дисплее написано "Петя"!
По-моему фигня какая-то получается...
Ну если возможность передавать другое имя вызывающего найдётся, то я бы "очищал" имя звонящего через какое-то разумное время.
- Вася вызывает диспетчера, и они начинают говорить. У диспетчера на дисплее "Вася".
- через 5-10 секунд вместо надписи Вася появляется надпись Диспетчерская
- Петя на пару секунд подключается к диспетчерскому каналу (услышал, что там идет разговор, и отключился).
- У диспетчера на дисплее на 5-10 секунд появляется "Петя". Затем меняется обратно на Диспетчерская.
comment:21 by , 10 months ago
Кажется, я реализовал все оговоренные выше функции (пока для простоты только "совмещенный" вариант - сигнализация передается в том же канале, что и речь). Это можно считать prove of concept.
Прежде чем двигаться дальше хотелось бы как-то убедиться, что это вообще будет пригодно для практического использования и не получится как со статическими конференциями. Но я не думаю, что смогу сделать такую практическую проверку...
follow-up: 23 comment:22 by , 10 months ago
Если оно уже пригодно для экспериментов, то залей в мой блок .20.160 и я попробую потестировать сценарии диспетчера
comment:23 by , 10 months ago
Replying to san:
Если оно уже пригодно для экспериментов, то залей в мой блок .20.160 и я попробую потестировать сценарии диспетчера
Залил в плату в слоте 5.
Тогда краткая информация о том, как использовать. Канальное окончание называется B2. В конфигурационный параметр "URI оператора" надо записать URI оператора. Группы, в которые входит оператор, задаются регулярным выражением параметра "Группы оператора" (если вызванный номер совпадает с рег. выражением, значит оператор выходит в эту группу и будет вызван). Если параметр "Отбой при отключении" не пустой, то при отключении оператора в канал будет передан отбой заданного параметром оператора или группы. Остальные параметры работают как во всех других окончаниях.
follow-up: 25 comment:24 by , 8 months ago
Пока я дошёл до этой проверки, стенд .20.160 уже случайно был "испорчен" другими экспериментами.
В VE-01, кажется, всё ещё экспериментальная прошивка, а вот в SW-01 уже не та.
Алексей, почини пожалуйста стенд.
comment:25 by , 8 months ago
follow-up: 29 comment:26 by , 7 months ago
При тестировании окончания B2 в блоке .20.160 я обнаружил странность:
- Oct 11 10:59:52 абонент 200 вызывает диспетчера 111 через окончания B2 (оба окончания находятся на одной плате, и соединенны друг с другом через TDM)
- Диспетчер принимает вызов - идёт разговор, слышимость в обе стороны
- абонент 200 кладёт трубку, диспетчер по прежнему подключен к B2
- Oct 11 11:00:14 абонент 200 снова вызывает диспетчера 111 через окончания B2.
- Диспетчер слышит "бип" (кажется немного обрезанный по длительности), затем он не слышит абонента 200, хотя абонент 200 слышит диспетчера
by , 7 months ago
comment:28 by , 7 months ago
при копировании из консоли putty почему-то появляются лишние пробелы, не знаю как скопировать по другому ...
comment:29 by , 7 months ago
Replying to san:
- Oct 11 10:59:52 абонент 200 вызывает диспетчера 111
- Диспетчер принимает вызов - идёт разговор, слышимость в обе стороны
- абонент 200 кладёт трубку, диспетчер по прежнему подключен к B2
- Oct 11 11:00:14 абонент 200 снова вызывает диспетчера 111 через окончания B2.
- Диспетчер слышит "бип" (кажется немного обрезанный по длительности), затем он не слышит абонента 200, хотя абонент 200 слышит диспетчера
Посмотрел приложенный лог. Насколько я вижу, повторное соединение между окончанием FXS с номером 200 и его окончанием B2 выполняется точно так же, как и в первый раз. Канальные окончания видят поток RTP друг от друга. Следовательно, слышимость между абонентом и групповым каналом должна быть.
В то же время в логе нет никаких сообщений, говорящих о том, что что-то произошло с соединением между абонентом 111 и его окончанием B2 после пункта 2. То есть слышимость между ними как была, так и должна продолжать оставаться. Канальное окончание B2 получило сообщение о подключении к групповому каналу абонента 200 и передало абоненту 111 сообщение UPDATE (записи об этом в логе нет, но есть запись о получении ответа 200 OK). Через 5 секунд окончание B2 передало абоненту 111 новое сообщение UPDATE и снова получило ответ 200 OK. Никаких манипуляций с медиапотоком это окончание не выполняло (по крайней мере в логе никаких следов этого нет).
Хотелось бы выяснить, на каком именно из участков не проходит сигнал. Слышит ли абонент 111 сигнал, если в TDM-маппере установить каналу его окончания B2 режим "генератор 1 кГц"?
comment:30 by , 7 months ago
Проделал у себя описанную последовательность действий несколько раз. Каждый раз слышимость в обе стороны.
comment:32 by , 7 months ago
По устной просьбе san дополняю: после выполнения описанных действий диспетчер перестает слышать не только вызвавшего его оператора 200, но и других операторов, которые подключены к тому же каналу (то есть вообще всех).
comment:33 by , 7 months ago
Давай на всякий случай сравним наши эксперименты. У меня в MSP версия ARM: v11_26_03_08_SS_04.
Еще в моей конфигурации только два окончания B2, соединенные друг с другом "точка-точка" (то есть нет групповых каналов с суммированием). Вряд ли это может как-то влиять, но воспроизводится ли у тебя проблема, если просто соединить два B2 между собой?
follow-up: 37 comment:34 by , 7 months ago
Добавил еще 4 окончания B2 и подключил их всех к тому же каналу, что и "рабочий". После первого же звонка плата зависла и перезагрузилась.
Предварительный вывод: MSP "глючит" при одновременном приеме CID по нескольким каналам.
Очень жаль, но, скорее всего, мы с этим ничего не сможем сделать, и реализация идеи в таком виде невозможна... :(
comment:35 by , 7 months ago
Я, вероятно, поторопился с выводами...
Сделал схему, вроде бы полностью аналогичную описанной в comment:26. Повторил вчерашний эксперимент несколько раз (не менее пяти), и все было нормально, проблема не воспроизвелась.
comment:36 by , 7 months ago
Если в момент воспроизведения бага в sip телефоне диспетчера поставить соединение на Hold, то после возврата к соединению - канал работает, слышимость появляется.
follow-up: 38 comment:37 by , 32 hours ago
Replying to alx:
MSP "глючит" при одновременном приеме CID по нескольким каналам.
Очень жаль, но, скорее всего, мы с этим ничего не сможем сделать, и реализация идеи в таком виде невозможна... :(
Насколько я помню, на этом выводе мы и закончили прошлые эксперименты.
Какие идеи что делать дальше?
comment:38 by , 32 hours ago
Replying to san:
Какие идеи что делать дальше?
Я долго думал, что можно еще попробовать сделать в B2, но интуиция подсказывает, что это пустая трата времени. Я решил попробовать отказаться от идеи использовать внутриканальную сигнализацию, и сделал новое канальное окончание, в котором сообщения передаются по UDP. В остальном оно работает так же как B2, набор сообщений тот же.
comment:39 by , 6 hours ago
Я постепенно прихожу к выводу о том, что все варианты с какими-то новыми канальными окончаниями - это не что иное чем костыли. Как результат, построенную на костылях систему будет неудобно и сложно настраивать и поддерживать в работе из-за всяких лишних настроек.
Мне кажется более правильным вариантом придумать какие-то расширения к уже реализованным полупостоянным конференциям. Например добавить фокусу конференции некий "список групп", при вызове имени которой фокус вызывает всех членов группы. Это бы реализовало функции 2 и 3... Функции 4 и 5 реализовать несложно...
follow-up: 41 comment:40 by , 5 hours ago
Вариант с расширением возможностей полупостоянных конференций мне нравится, такой вариант был бы более гибким решением - в качестве участника может быть любой sip пользователь.
Только надо учитывать, что функции диспетчерской должны работать как с "обычными" sip-пользователями так и с окончаниями DS.
comment:41 by , 5 hours ago
Replying to san:
Вариант с расширением возможностей полупостоянных конференций мне нравится, такой вариант был бы более гибким решением - в качестве участника может быть любой sip пользователь.
Не понял твою мысль... Разве с окончанием PPS не любой SIP пользователь может работать?
Только надо учитывать, что функции диспетчерской должны работать как с "обычными" sip-пользователями так и с окончаниями DS.
Не понял и эту твою мысль. Как именно это надо учитывать? В чем необычность окончания DS?
comment:42 by , 5 hours ago
Не понял твою мысль... Разве с окончанием PPS не любой SIP пользователь может работать?
Я имел ввиду что не нужен будет посредник в виде шлюза(окончания pps) для подключения пользователя к конференции.
В чем необычность окончания DS
В том что кроме самих пользователей ещё и групповой голосовой канал ещё подключается к конференции, вроде бы это никак не должно повлиять, но вдруг.
Поскольку применение окончания PPS, которое требуется "переизобрести", нестандартное, для начала опиши, пожалуйста, это применение (а еще лучше обрисуй в картинках).