Сброс текущего соединения более приоритетным вызовом

[alx]

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

Возник вопрос: а не будет ли полезно реализовать такую функцию и для других типов канальных окончаний - например FXO? Скажем, если линия FXO занята разговором, и в это время поступает более приоритетный вызов, текущее соединение разрывается, и линия FXO занимается новым вызовом...

Технически реализовать это можно так (черновой набросок алгоритма):

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

Хочется услышать мнения по следующим моментам:

• будет ли такая функция хоть сколько-нибудь востребована;
• по каким критериям можно определять приоритетность вызова (у окончания АДАСЭ уже есть параметр "Горячая линия 1600 Гц", в которой пишется URI диспетчера, вызовы от которого и будут приоритетными, в других канальных окончаниях такого параметра нет), как вариант - использовать параметр URI cpc (Calling Party Category), который у нас уже используется;
• Замечания/предложения по поводу предложенного алгоритма.

[andrei]

Случилось у меня происшествие о котором нужно незамедлительно сообщить куда-либо (например пожар, и я звоню в 112). дозвониться удалось только спустя 10 напряженных минут. И во время объяснения адреса звонит мне "приоритетный диспетчер" чтобы "позвать пить чай". И важный вызов обрывается.
Правильно я понял ситуацию?
Вообще я немножко против независимо от типа окончания.
Единственное что я нахожу приемлемым - оповестить пользователя о поступившем втором вызове, например попищать ему в трубку, как в сотовом при ещё одном вызове во время разговора.

[alx]

Replying to andrei:

Правильно я понял ситуацию?

Абсолютно.

[san]

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

...А если приоритет настраивать гибче, тогда может быть и пригодится(например приоритет = номер вызываемого "112") с другой стороны есть ещё куча "приоритетных" номеров, и разных ситуаций и если все их не прописать, то например звонок в 101 будет прерван звонком в 112 ....

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

[alx]

Replying to san:

можно добавить такую команду ДВО.

Поясни эту мысль, пожалуйста...

[san]

Поясни

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

[alx]

Replying to san:

Поясни

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

Как-то ты сегодня очень скуп на пояснения... :)

То, что ты предлагаешь сделать новую функцию ДВО, я уже понял. Расскажи, что и как эта функция должна делать. Только подробно, не "Набираешь 777 и все перехватывается"... :)

[san]

Да я и не предлагал особенно, упомянул скорее, поэтому тапками не кидайтесь, если что.
ну например:
У окончания например FxO настройка типа "группа перехвата". Если участник(Вася) указанной группы набирает 777, текущее соединение разрывается, вместо него устанавливается соединение с Васей.

Суть та же, что и в тикете, но исключает случайное использование приоритета (позвать пить чай).

[san]

ну ещё в настройки того же FxO можно добавить "код перехвата".
Не обдумывал это в деталях, суть

исключает случайное использование приоритета

тем что нужно набрать некий код для умышленного перехвата

[andrei]

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

[san]

Разорвать может, но только намеренно.
Скажем инструкция, при пожаре использовать код 777. В остальных случаях, чтоб попить чай никто использовать не будет, ты же не звонишь в 112 для развлечения :)

[alx]

Replying to san:

У окончания например FxO настройка типа "группа перехвата". Если участник(Вася) указанной группы набирает 777, текущее соединение разрывается, вместо него устанавливается соединение с Васей.

Что-то я все равно не понял... Устанавливается соединение кого с Васей?

[alx]

Replying to andrei:

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

Сомневаюсь, что это может работать... Так как подавляющее большинство вызовов все-таки по сути неприоритетны, получается, что практически при любом телефонном звонке любой пользователь должен рассуждать примерно так: "О, пять часов, надо позвонить Маше, предложить попить чаю. Какой у нее телефон... а, вот он... Постой, это же у меня будет неприоритетный звонок, надо обязательно перед номером добавить префикс '*#' иначе диспетчер, в случае острой необходимости и нехватке свободных линий не сможет мой разговор прервать!"... :) Будет кто-то так делать? Да никто! :) Все будут просто набирать телефонные номера без всяких префиксов, и в результате все вызовы будут непрерываемыми.

Если уж делать что-то подобное, то логика должна быть обратной: для того чтобы соединение было "защищенным" от прерывания, требуется добавлять какой-то префикс. Иными словами, добавлять префикс лучше не к 99% неважных звонков, а к 1% важных...

[andrei]

Replying to alx:

Будет кто-то так делать? Да никто! :) Все будут просто набирать телефонные номера без всяких префиксов, и в результате все вызовы будут непрерываемыми.

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

[alx]

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

[andrei]

Что в итоге? Не ломать то, что работает?

[alx]

Replying to andrei:

Что в итоге?

Так вроде бы итоги я подвел в comment:14...

Не ломать то, что работает?

??? Не понял вопрос.

[andrei]

Я невнимательно прочел, вопрос снимается.

[san]

Вспомнил что при внедрении IP-Диспетчерской пользователи тоже просили подобную функцию.
Достаточно долго обдумав :), я не против реализации этой функции.
Главное критерий приоритетного вызова сформировать правильно, и сам алгоритм разъединения, что бы не было случайных приоритетных вызовов, и всем участникам было понятно что произошло.

Сценарии использования функции я вижу примерно так:
Есть приоритетные пользователи, группа например, куда входит Диспетчер.
И есть пользователь Вася (например FxS c номером 101.)
Вася сейчас разговаривает с Петей (неприоритетное соединение)

• сценарий 1.

Диспетчеру срочно нужно вызвать Васю.
Диспетчер набирает 101. Диспетчеру вместо гудков проигрывается "Пользователь разговаривает. Для разрыва соединения нажмите 1."
Диспетчер нажимает 1.
Пете проигрывается: "Соединение было разорвано приоритетным вызовом". После чего Петя слышит короткие гудки.
А Васе проигрывается что-то типа: "Внимание! Приоритетный вызов" И Вася соединяется с Диспетчером, в момент соединения Диспетчер получает звуковой сигнал и начинает разговор.

• сценарий 2.

Диспетчер нужно вызвать срочно несколько необходимых пользователей для чего отправляет сразу приоритетные вызовы всем из программы.
Программа вызывает Васин номер с каким нибудь постфиксом, например 101#1.
(вместо постфикса можно использовать, наверное, какой-нибудь параметр в вызове)
Плата VE определяет этот вызов как приоритетный на номер 101.
Пете проигрывается: "Соединение было разорвано приоритетным вызовом" ...

• сценарий 3.

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

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

• позвать пить чай - обычный вызов.
• пожар/годзила - приоритетный вызов.

Андрей, интересно твоё мнение, т.к. ты был против.

[andrei]

Так ничего же нового ты не придумал. Мой сценарий так и остался с негативными последствиями приоритезации.
В помещении пожар. У Васи 2 минуты чтобы вызвать пожарных, потом огонь перекинется на телефон. Вася звонит в пожарную часть, а не Пете. И вот он с трудом дожидается ответа пожарных, кричит "ПОЖАР ПО АДРЕСУ..." и в этот момент диспетчер решает что его вызов самый важный и обрывает разговор. Кадр с угольками. Занавес.
И не важно какие кнопки нужно нажать для этого диспетчеру, всё равно он будет руководствоваться какими-то своими критериями важности, которые не учитывают всех обстоятельств.
Если уж плата VE просит диспетчера чего-то понажимать, ввести пароль, а потом тыкнуть кнопку ДА на вопрос "уверены ли Вы?", то было бы разумным и Васю спросить желает ли он завершить текущее соединение чтобы поговорить с важным диспетчером. И тогда, если Вася звонил не в экстренную службу, а действительно Пете, он позволит разорвать соединение.
Не знаю только как опрашивать абонента не имеющего аппарата с тональным набором.

[andrei]

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

[san]

Вася звонит в пожарную часть

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

не имеющего аппарата с тональным набором

думаю этот случай мы не рассматриваем

[andrei]

Сколько должно быть приоритетов?
Вызов может быть разорван только более высоким приоритетом?

[alx]

Replying to san:

Сценарии использования функции я вижу примерно так:
Есть приоритетные пользователи, группа например, куда входит Диспетчер.
И есть пользователь Вася (например FxS c номером 101.)
Вася сейчас разговаривает с Петей (неприоритетное соединение)
Диспетчеру срочно нужно вызвать Васю.

Вообще-то в описанном сценарии нет никакой проблемы - есть услуга "Ожидание вызова", позволяющая Васе узнать, что его кто-то вызывает, переключиться на новый вызов, спросить "Чо надо?" и затем вернуться к Пете. Не с таким, конечно, искусственным интеллектом, как ты описал в сценарии 1, но поставленная задача решается.

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

[alx]

Replying to san:

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

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

[alx]

Replying to andrei:

Сколько должно быть приоритетов?
Вызов может быть разорван только более высоким приоритетом?

На данный момент вызовы делятся на "Приоритетные" и "Все остальные". При получении приоритетного вызова окончание АДАСЭ, уже занятое вызовом, разрывает текущий вызов. При получении любого другого (не приоритетного) - не разрывает.

[andrei]

А если текущий приоритетный вызов получает новый приоритетный вызов?

[san]

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

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

А если текущий приоритетный вызов получает новый приоритетный вызов

как В АДАСЭ сделано не знаю, но логично, что если приоритет вызова и текущего соединения одинаковый, то разрыва соединения не должно быть.

услуга "Ожидание вызова"

Да, и наша услуга "перехват соединения приоритетным вызовом" предлагается вместо неё, как более действенная и грубая :)

не абонентские окончания, а соединительные линии

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

[alx]

Replying to andrei:

А если текущий приоритетный вызов получает новый приоритетный вызов?

Если это вопрос мне, то я его не понял.

Replying to san:

Но приоритетность соединения на мой взгляд может зависеть и от вызываемой стороны.

Я не знаком с понятием "приоритетность соединения". Плата VE-01 на данный момент таким понятием не оперирует.

как В АДАСЭ сделано не знаю

Как сделано в АДАСЭ я написал в comment:25. Или ты мне не веришь? :) :) :)

наша услуга "перехват соединения приоритетным вызовом" предлагается вместо неё

Становится интересно. :) Не мог бы ты изложить суть этой предлагаемой услуги? Или дать ссылку, если ее описание уже где-то есть...

Но суть ведь та-же, в описаных сценариях, вместо подключения к Васе, после разрыва соединения, Диспетчер перехватит линию FxO. А Петя и Вася будут слушать извинения от искусственного интеллекта)

Принципиальная разница в том, что ожидание вызова для окончания FXS уже реализовано, а "перебивка" соединения для FXO - нет. :) Я думаю, тратить время на еще одну альтернативную реализацию решения задачи, которая уже имеет одно решение, в то время как есть другие задачи, которые никак не решены - нерационально...

[alx]

Скорректировал описание тикета - уточнил, как определяется "приоритетный вызов".

[san]

Как сделано в АДАСЭ

не веришь

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

наша услуга "перехват сброс соединения приоритетным вызовом"

ну та самая гипотетическая функция, которую ты анонсировал в этом тикете, по аналогии с функцией реализованной для АДАСЭ.

уточнил, как определяется "приоритетный вызов"

я так не играю :)
с такой узкой формулировкой у меня нет интереса к этой функции

Я предлагаю ввести понятие "приоритетное соединение" и расширить критерии приоритетного вызова.

Я не знаком с понятием "приоритетность соединения"

Приоритетное соединение - соединение созданное приоритетным вызовом.

[alx]

Replying to san:

услуга "Ожидание вызова"

Да, и наша услуга "перехват сброс соединения приоритетным вызовом" предлагается вместо неё, как более действенная и грубая :)

С этим я совершенно не согласен. Почему "вместо"? Функция предлагалась (по крайней мере, мной) вовсе не "вместо", а "дополнительно к". Мне кажется, это две совсем разные функции, одна не заменяет другую.

Replying to san:

я так не играю :) с такой узкой формулировкой у меня нет интереса к этой функции

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

Я предлагаю ввести понятие "приоритетное соединение" и расширить критерии приоритетного вызова.

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

[san]

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

Предлагаю оставить как есть