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
- При создании новой конференции, она должна отображаться на панели конференций у Диспетчеров/Техников уже в момент вызова абонентов. Получается что конф. ещё не создана на сервере, но диспетчер/техник уже должны её видеть в списке и видеть какие пользователи туда вызваются.
- И наоборот когда все абоненты вышли из конференции и конференция закрылась Диспетчер/Техник должны видеть эту конференцию в списке и абонентов в ней с красными кнопками.
Попробую на примере показать как всё должно выглядеть.
Диспетчер вызывает абонентов a1, a2, a3 в конф1:
- Диспетчер создал заготовку из 3 абонентов и нажал вызов.
- Три абонента вызываются в конф1
- Диспетчер и техник видят в списке конференций конф1 и в ней 3 вызываемых абонента.
- Абонент а1 подключился в конф1.,(на сервере была создана конф1) диспетчер и техник видят в списке абонентов конф1, что кнопка абонента а1 изменилась к виду "подключен", кнопки а2 и а3 в состоянии "вызывается".
- Абонент а1 покинул конф1.,
- В реальности конф1 была закрыта, но диспетчер и техник продолжают видеть её в списке конференций кнопка абонента а1 в списке абонентов конференции стала красной, кнопки абонентов a2,a3 в состоянии "вызывается".
- а2 и а3 отклонили вызов
- Диспетчер/Техник видят в конф1: а1,а2 и а3 с красными кнопками.
- Техник нажимает в конф1 общую кнопку "вызвать" - повторный вызов абонентов с красными кнопками.
- а1,а2 и а3 снова вызываются в конф1., диспетчер/техник видят кнопки абонентов в состоянии "вызывается".
- а1,а2 и а3 подключились к конф1 диспетчер/техник видят кнопки абонентов в состоянии "подключен".
Attachments (1)
Change History (55)
comment:1 by , 8 years ago
follow-up: 3 comment:2 by , 8 years ago
По "1", "2" и "3": мне кажется, логика отображения конференций/абонентов не должна зависеть от того, как и почему они появляются/исчезают (сам ли пользователь ушел или его отключил диспетчер, сама ли конференция закрылась или ее уничтожили насильно). Мне кажется, у пользователя пульта должна быть настройка: отображать ли пропавших участников бесконечно (пока "плашка" не будет удалена вручную), либо какое-то время (настраиваемое количество секунд). Так, например, делает jabber-клиент gajim - когда контакт отключается, он несколько секунд индицирует его другим цветом (красным), а затем убирает его из списка.
Мне более интересен другой момент из "1" - каким образом пульт техника будет узнавать, что диспетчер вызвал кого-то в конференцию до того как эта конференция будет реально создана? Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...
По "4" - я не вижу проблемы в том, что техник (или кто-либо еще) создаст конференцию с именем, которое когда-то уже использовалось. Соответственно, я не вижу смысла давать конференциям уникальные имена.
comment:3 by , 8 years ago
Replying to alx:
Мне более интересен другой момент из "1" - каким образом пульт техника будет узнавать, что диспетчер вызвал кого-то в конференцию до того как эта конференция будет реально создана? Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...
Дима мне говорил, что уже умеет получать эту информацию из какого-то существующего события ESL.
follow-up: 5 comment:4 by , 8 years ago
| Keywords: | algorithm added |
|---|
Сообщение PRESENCE_IN, поле status - по не можно узнать что кто-то звонит.
Сообщение CHANNEL_CALLSTATE, поле Answer-State - по не можно также узнать что кто-то звонит.
comment:5 by , 8 years ago
Replying to dimag:
...можно узнать что кто-то звонит.
И? "Кто-то звонит" и "пользователя вызывают в конференцию" - не одно и то же...
by , 8 years ago
| Attachment: | presence_in.png added |
|---|
follow-up: 7 comment:6 by , 8 years ago
Дима мне показал содержание сообщения PRESENCE_IN
В параметрах выделенных красным присутствует uri вызывающего, uri вызываемого и имя конференции.
Разве этого не достаточно?
comment:7 by , 8 years ago
Replying to san:
В параметрах выделенных красным присутствует uri вызывающего, uri вызываемого и имя конференции.
??? Я вижу в выделенном на картинке номер вызываемого, номер вызывающего и имя вызывающего. Имени конференции не вижу...
Разве этого не достаточно?
Я пока доверяю своим глазам. :) Имени конференции среди выделенных параметров нет. Следовательно, недостаточно - нет возможности установить сам факт предполагаемого включения абонента в конференцию.
comment:8 by , 8 years ago
Вызвал абонентом Техник4(4@..) абонента ГРС_201 (201@..) в Конференцию_1.
Вижу в поле Caller-Caller-ID-Name значение "Конференция_1", откуда оно там взялось и какой логике подчиняется я не знаю.
comment:9 by , 8 years ago
Это пульт вызывающего диспетчера в качестве имени вызывающего абонента подставляет имя конференции, которую предполагается создать. По-моему это вполне логично - вызываемый может понять, куда его вызывают. Проблема в том, что о том, что, к примеру, "Диспетчерская" - это имя конференции, а не человека Лидии Ивановны Диспетчерской, :) знает только пульт, который инициировал вызов...
follow-up: 11 comment:10 by , 8 years ago
В нашей ситеме Диспетчерской связи подразумевается что только пульты Диспетчера/Техника имеют право вызывать пользователя в конференцию.
Можем мы договориться о том что имя конферении будем всегда подставлять вкачестве имени вызывающего и использовать эту фичу для реализации задачи тикета? Как ты считаешь, Алексей, насколько это "правильно"?
follow-up: 12 comment:11 by , 8 years ago
Replying to san:
В нашей ситеме Диспетчерской связи подразумевается что только пульты Диспетчера/Техника имеют право вызывать пользователя в конференцию.
А согласится ли с таким постулатом Заказчик? Насколько я помню, ко мне (через тебя) дважды обращались с просьбой настроить в dialplan'е возможность прямого вызова операторов ("прямого" в смысле не в конференцию)...
Можем мы договориться о том что имя конферении будем всегда подставлять вкачестве имени вызывающего и использовать эту фичу для реализации задачи тикета? Как ты считаешь, Алексей, насколько это "правильно"?
Мне это не кажется хорошей идеей.
Вышеприведенный постулат (что только диспетчер может вызвать абонента в конференцию, и никакие другие входящие вызовы невозможны) сильно ограничивает гибкость системы связи и, следовательно, ее применимость. И все это ради чего? Ради того чтобы два экземпляра программы могли синхронизировать свое состояние (чтобы одна программа могла сделать вывод о намерении другой программы создать конференцию на основании уже имеющихся сообщений)? Но того же самого можно добиться и другими средствами, не выдвигая таких ограничений - можно придумать массу способов, как передать информацию от одного экземпляра программы другим, учитывая, что они все имеют соединение с сетью и даже знают о существовании друг друга (включая адреса). Один из возможных вариантов (через события ESL) я описывал ранее.
И, как заключение, я вообще сторонник того чтобы пульт, по возможности, отображал реальное состояние дел: те конференции и их участников, которые существуют в действительности. Я понимаю, что иногда имеет смысл "отступать" от этого правила. Например, когда диспетчер вызвал кого-то в конференцию, имеет смысл отобразить в списке этого предполагаемого нового участника, хотя реально его еще нет в конференции, просто чтобы пользователь видел реакцию (feedback) на свои действия. Но я не понимаю, зачем такого "воображаемого" участника видеть пользователям других пультов, которые его не вызывали. По-моему будет логично, если они увидят нового участника, когда он реально появится в конференции (то есть после ответа на вызов)...
follow-up: 13 comment:12 by , 8 years ago
Replying to alx:
Например, когда диспетчер вызвал кого-то в конференцию, имеет смысл отобразить в списке этого предполагаемого нового участника, хотя реально его еще нет в конференции, просто чтобы пользователь видел реакцию (feedback) на свои действия. Но я не понимаю, зачем такого "воображаемого" участника видеть пользователям других пультов, которые его не вызывали. По-моему будет логично, если они увидят нового участника, когда он реально появится в конференции (то есть после ответа на вызов)...
Техник связи "контролирует" работу Диспетчерской, и хочет видеть все действия и их последствия:
допустим Диспетчер вызывает на "режим" 10 операторов ГРС, А оператор "ГРС Простоквашино" не ответил на вызов. Если техник сразу это увидит, он может принять меры раньше, не дожидаясь звонка от Диспетчера.
Возможно будет достаточно реализовать данный функционал только для конференции "Диспетчерская", она и так у нас особая.По крайней мере логично будет с этого начать
Если штатных способов гарантировано получить нужную информацию нет, согласен что лучше добавить что-то новое, чем делать "костыли" на существующее.
Алексей, я так понимаю ты предлагаешь такой вариант для синхронизации ?
Я не знаю, может ли пульт техника как-то сгенерировать через ESL некое custom'ное событие в FS, на которое могли бы подписаться другие пульты, которые получили бы его от FS...
follow-up: 16 comment:13 by , 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, а не что-то другое...
comment:14 by , 8 years ago
| Priority: | critical → major |
|---|
comment:15 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
r318
Программа при запуске определяет соединения с конференцией "Диспетчерская" в процессе вызова и выводит их.
Это достаточно или есть ещё какие-то замечания?
comment:16 by , 8 years ago
Replying to alx:
В описанном варианте есть единственный вопрос - как сгенерировать нужное событие командой API.
Нет вопроса. Произвольное событие можно передать непосредственно в event-socket с помощью sendevent - см. https://freeswitch.org/confluence/display/FREESWITCH/mod_event_socket
follow-up: 18 comment:17 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
не вижу причин закрывать тикет
comment:18 by , 8 years ago
Replying to san:
не вижу причин закрывать тикет
В comment:15 Дима пишет, что описанное в тикете улучшение реализовано в r318. Это по-моему и есть причина. :)
Там же он спрашивает, есть ли какие-то замечания. Если есть замечания, то, наверное, надо их здесь изложить, чтобы Дима мог их исправить. Если же замечаний нет, то зачем переоткрывать тикет?
comment:20 by , 8 years ago
В r318 сделано всё описанное в тикете?
(пока тут всё было на стадии обсуждения, поэтому я был удивлён внезапным закрытием тикета)
comment:25 by , 8 years ago
Я бы хотел выполнение пунктов 1. и 2. описанных в тикете, как минимум, для "Основной конференции".
Дима, каким образом мы будем передавать информацию о своих действиях(вызовах) другим пользователям?
comment:26 by , 8 years ago
Дмитрий не ответил на мой вопрос. Задам ещё один.
В r471 заметил что в конференциях отображаются абоненты на стадии вызова
Дима, каким способом ты передаёшь информацию о вызовах абонентов?
follow-up: 28 comment:27 by , 8 years ago
Как я определяю наличие внешней конференции.
Обрабатываю сообщение Event-Name с именем PRESENCE_IN.
Если статус в сообщение CS_ROUTING, состояние ответа("Answer-State") равно "ringing", то получаем имя конференции из поля "Caller-Caller-ID-Name", если значение в этом поле отсутствует в списке известных конференций, то добавляем новую внешнюю конференцию, если есть, то добавляем нового пользователя конференции.
comment:28 by , 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). Таким образом, описанный Вами алгоритм не соответствует реальному поведению программы.
follow-up: 30 comment:29 by , 8 years ago
Забыл упомянуть - Имя внешней конференции должно содержать строку "Конференция", если этой строки нет, то сообщение игнорируется.
comment:30 by , 8 years ago
Replying to dimag:
Имя внешней конференции должно содержать строку "Конференция",
Довольно странное ограничение, особенно учитывая, что даже основная конференция, в которой диспетчер работает большую часть своего времени, имеет имя "0", в котором никакой строки "Конференция" нет...
follow-up: 32 comment:31 by , 8 years ago
Распознать что пришло сообщение именно для конференции, а не для прямых сообщений между абонентами можно по параметру "Caller-Callee-ID-Name" или по параметру "Caller-Caller-ID-Name" для конференций значение одного из этих параметров будут равны "Outbound%20Call", другое параметр будет содержать имя конференции.
В остальных случаях параметры указанные выше будут иметь другие значения.
comment:32 by , 8 years ago
Replying to dimag:
для конференций значение одного из этих параметров будут равны "Outbound%20Call",
- Обоснуйте, пожалуйста, это утверждение. На основании чего Вы сделали такой вывод?
- Даже если это так, для распознавания вызова в конференцию недостаточно доказать, что при вызове в конференцию одно из этих полей будет иметь значение "Outbound%20Call". Надо еще доказать, что при любом другом вызове (не в конференцию) эти поля не могут принмать значение "Outbound%20Call". Иначе есть возможность ошибочного (ложного) вывода о том, что имеет место вызов в конференцию...
comment:34 by , 8 years ago
Replying to dimag:
На основание наблюдений.
Я только что провел простой эксперимент: в консоли FS дал команду:
originate user/test13 &echo()
и в результате ее выполнения получил событие PRESENCE_IN с Caller-Callee-ID-Name: Outbound%20Call. Таким образом, этот признак для определения вызова в конференцию не годится.
comment:35 by , 8 years ago
| Summary: | Отображение конференций в программе, дополнение → Отображение конференций в программе |
|---|
На данный момент(r487) вижу такие проблемы в текущей реализации этой задачи:
- В качестве признака вызовов пользователя в конференцию используется не достоверная информация
- баг:
В некую конф1 пользователь Техник вызывает абонентов
Диспетчер видит (ещё не созданную конф1) но добавить туда абонентов не может
comment:36 by , 8 years ago
| Milestone: | Текущее → 1 очередь |
|---|---|
| Priority: | major → critical |
Переношу в "1-ю очередь" т.к. функция реализована, но криво, и теперь влияет на работоспособность программы
comment:37 by , 8 years ago
r488
Пользователь может добавлять и удалять пользователей из всех конференций находящихся в процессе создания.
comment:38 by , 8 years ago
Дима, разъясните, пожалуйста, назначение макроса USER_STATE_IN_CALL. И макроса USER_STATE_CALL_SUCCESS тоже.
follow-up: 42 comment:39 by , 8 years ago
USER_STATE_IN_CALL - абонент в процессе вызова
USER_STATE_CALL_SUCCESS - вызов абонента прошёл успешно абонент в конференции или есть состояние прямой связи между двумя абонентами.
follow-up: 43 comment:40 by , 8 years ago
Предлагаю для определения вызова в конференцию посылать после выполнения команды originate сообщение следующего формата:
MC04Conference_Proposed('[имя конференции'], имя пользователя, UUID устанавлимоего соединения)
UUID - если абонент не в сети, то пустая строка.
follow-up: 44 comment:41 by , 8 years ago
Алексей, ваше мнение о предложение выше, будет ли посылка сообщения при добавление в конференцию/создание конференции, как описано выше, достоверным признаком?
comment:42 by , 8 years ago
Replying to dimag:
USER_STATE_IN_CALL - абонент в процессе вызова
Вижу что некая переменная проверяется на равенство этому макросу, но присваивания этого макроса не вижу. Я правильно понимаю, что эти проверки всегда дают false?
USER_STATE_CALL_SUCCESS - вызов абонента прошёл успешно абонент в конференции или есть состояние прямой связи между двумя абонентами.
Для чего введен этот макрос, если он нигде не используется?
comment:43 by , 8 years ago
Replying to dimag:
Предлагаю для определения вызова в конференцию посылать после выполнения команды originate сообщение следующего формата:
Что Вы подразумеваете под форматом? Формат событий (plain, json, xml) определяется при подписке на них.
MC04Conference_Proposed('[имя конференции'], имя пользователя, UUID устанавлимоего соединения)
А для чего сообщать UUID устанавливаемого соединения? И еще здесь не хватает домена пользователя...
UUID - если абонент не в сети, то пустая строка.
А для чего пульту может потребоваться вызывать абонента, который не в сети? В чем смысл такого вызова?
comment:44 by , 8 years ago
Replying to dimag:
Алексей, ваше мнение о предложение выше, будет ли посылка сообщения при добавление в конференцию/создание конференции, как описано выше, достоверным признаком?
Достоверным признаком чего?
follow-up: 46 comment:45 by , 8 years ago
USER_STATE_CALL_SUCCESS - используется для прямых соединений абонентов между собой
Формат сообщений plain.
UUID нужен для случая если пользователь захочет отменить соединение.
В предполагаемую конференцию можно добавлять абонента который не в сети, при вызове он автоматически станет абонентом вызов которого произошёл неудачно, другие пользователи наверно тоже захотят увидеть что была попытка такого абонента.
Достоверным признаком чего? - попытки создания новой конференции, который невозможно перепутать ни с чем.
comment:46 by , 8 years ago
Replying to dimag:
USER_STATE_CALL_SUCCESS - используется для прямых соединений абонентов между собой
Можете назвать имя файла и номер строки в нем, где используется макрос USER_STATE_CALL_SUCCESS?
В предполагаемую конференцию можно добавлять абонента который не в сети, при вызове он автоматически станет абонентом вызов которого произошёл неудачно, другие пользователи наверно тоже захотят увидеть что была попытка такого абонента.
Сама по себе попытка вызова пользователя, не зарегистрированного на сервере, мне уже кажется странной и нелогичной (результат такой попытки заведомо известен). А уж желание других пользователей знать о такой попытке - тем более... :)
Достоверным признаком чего? - попытки создания новой конференции, который невозможно перепутать ни с чем.
Если, например, это событие будет иметь уникальный Event-Subclass (то есть такой Event-Subclass, который используется для оповещения о намерении создать новую конференцию и только о намерении создания новой конференции) - то да, получение такого события будет достоверным признаком попытки создания новой конференции, который невозможно перепутать ни с чем. Формат же сообщения в этом случае никакого значения не имеет.
follow-up: 48 comment:47 by , 8 years ago
То есть вы согласны с использованием сообщения MC04Conference_Proposed для индикации попытки создания новой конференции? Если да, то переделаю программц новое сообщение.
comment:48 by , 8 years ago
Replying to dimag:
То есть вы согласны с использованием сообщения MC04Conference_Proposed для индикации попытки создания новой конференции? Если да, то переделаю программц новое сообщение.
Я не могу с этим ни согласиться, ни не согласиться, так как я не знаю, что это за сообщение такое - MC04Conference_Proposed.
comment:49 by , 8 years ago
MC04Conference_Proposed - это сообщение которое я хочу посылать при создание новой конференции, это будет моё пользовательское сообщение.
follow-up: 53 comment:52 by , 8 years ago
Вы согласны с использованием описанного выше сообщения и его параметров? Не будет ли, по ваше мнению, каких-либо проблем со FreeSwitch.
Если вы согласно, то я переделаю программу на заданное сообщение.
comment:53 by , 8 years ago
Replying to dimag:
Вы согласны с использованием описанного выше сообщения и его параметров?
Ходим по кругу. Этот вопрос Вы уже задавали в комментарии 47. И в комментарии 48 я на него ответил. Еще раз: я не могу с этим ни согласиться, ни не согласиться, так как я не знаю, что это за сообщение Вы будете посылать. Да, Вы уточнили, при каких обстоятельствах (при создании новой конференции) Вы будете посылать это сообщение. Но о самом сообщении (кроме того что в нем будет содержаться имя пользователя, имя конференции и UUID соединения) я так ничего и не знаю.
Не будет ли, по ваше мнению, каких-либо проблем со FreeSwitch.
Вы спрашиваете о проблемах вообще или о каких-то конкретных? Если о проблемах вообще, то я не знаю. Никогда нельзя исключить вероятность возникновения какой-то проблемы. Могу лишь сказать что, по моему опыту, FS - довольно качественная и надежная программа. Если о конкретных, то уточните, пожалуйста, о каких.
Если вы согласно, то я переделаю программу на заданное сообщение.
Задание в этом тикете Вам давал Александр, руководит работой Александр, не понимаю, почему Вы спрашиваете моего согласия на переделку программы. Свое мнение я достаточно полно изложил в комментариях к этому тикету. Прочитайте их, наконец!
comment:54 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Реализовано в ветке source:branches/user-list-model@642.
Позднее будет добавлено в транк.
К этому алгоритму у меня возникают некоторые вопросы и, мне кажется остались неопределённости.
Вот например некоторые вопросы:
Думаю логично убрать конференцию из списка
Получается что нужно отобразить а1 и и а2 с красными кнопками
Получается что у Техника этот абонент останется с красной кнопкой
Надеюсь я понятно изложил суть :) Если возникают вопросы или вы видите проблемы с описаным поведением программы, давайте обсудим в комментариях.