__group__ ticket summary component type owner reporter status created _changetime _description _reporter 1 очередь 854 RT-01, обновление web-интерфейса платы. sw задача alx ledol new 2026-06-10T11:28:28+05:00 2026-06-10T11:29:55+05:00 "В тикете MC-04\#1486 поставлена задача по добавлению настроек платы RT-01. Для реализации предлагается: 1. В программной версии 2 и выше (исполнение платы 2) и в программной версии 8 и выше (исполнение платы 1), в переменной 5 MIB платы изменены значения бит 4, 5, 6 байта 3 ранее имевшие значение reserved. Общее описание переменной: переменная 5 (конфигурация портов передачи данных) Тип строка, длина строки 13 байт,чтение\запись,формат - Байт Название Параметры Значение по умолчанию 0 Признак обновления переменной 0-всегда 1 бит 0 блокировка 1-канал блокирован 1 бит 1 шлейф канала РМ 1-шлейф включен 0 бит 2 шлейф канала РКС 1-шлейф включен 0 бит 3 питание приемника 1-питание включено 1 бит 5..4питание передатчика 00-выкл 01-вкл 10-вкл по PTT 10 бит 6 маска аварии 1-авария замаскирована 0 бит 7 reserved 2 бит 0 вкл перед по PTT пост. 1-настройка вкл 0 бит 1 вкл перед по PTT по CD 1-настройка вкл 0 бит 2 вкл перед по PTT по А 1-настройка вкл 0 бит 3 вкл перед по PTT по Png 1-настройка вкл 0 бит 4 вкл перед по PTT по Vad 1-настройка вкл 0 бит 5 вкл перед по PTT по CAS 1-настройка вкл 0 бит 6 исп. альтернативный CD 1-настройка вкл 0 бит 7 прд. А при PTT ON 1-настройка вкл 0 3 бит 0 выкл перед по D 1-настройка вкл 0 бит 1 выкл перед по таймеру 1-настройка вкл 0 бит 2 выкл перед по Vad 1-настройка вкл 0 бит 3 отправка выкл.(D) 1-настройка вкл 0 бит 4 Направления VAD 0 => ""Radio+TDM"" 1 => ""TDM"" 0 (ticket #1486 п.1) бит 5 Сброс PTT при аварии ретр. 1-настройка вкл 0 (ticket #1486 п.2.1) бит 6 Сброс питания при аварии ретр. 1-настройка вкл 0 (ticket #1486 п.2.2) бит 7 reserved 4 бит 0 Акт. ур. CD 1/0 бит 1 Акт. ур. PTT 1/0 бит 2 Акт. ур. CAS 1/0 бит 4..3 CAS_tx 00-CAS=0 01-CAS=1 10-CAS=cd бит 5 Акт. ур. CAS_tx_B 1/0 бит 7..6 reserved 5 Адрес групп. выз. 0-45 6 Адрес инд. выз. 0-45 7 таймер мл. байт 0-255 8 таймер ст. байт 0-255 9 ур. канала ТЧ прм -13-+4дБ (аналог EM)* 10 ур. канала ТЧ прд -13-+4дБ (аналог EM)* 11 ур. DTMF прм -13-+4дБ (аналог EM)** 12 ур. DTMF прд -13-+4дБ (аналог EM)** 2. В web-интерфейсе платы добавить селектор ""Направления VAD"" с вариантами ""Radio+TDM"" и ""TDM"". 3. В web-интерфейсе платы добавить чек-бокс ""Сброс PTT при аварии ретр."". 4. В web-интерфейсе платы добавить чек-бокс ""Сброс питания при аварии ретр."". Отладку настроек можно провести в блоке 192.168.0.252." ledol 1 очередь 188 Требуется измеритель уровня сигнала в TDM маппере ПЛИС (sw) улучшение alx san assigned 2016-08-04T14:38:34+05:00 2025-10-15T18:00:07+05:00 "~~Отдельная ячейка коммутационного поля TDM маппера, скомутировав в неё нужный канал мы должны увидеть уровень сигнала в этом канале.~~ На вкладке ""Данные TDM"", кроме hex и bin добавить ещё переключатель ""уровень dBm"", при переключении на этот вариант в ячейках должен отображаться уровень сигнала принятого коммутатором от платы." san 1 очередь 304 "Резервирование потоков: изменить алгоритм варианта ""без возврата на основной""" ПЛИС (sw) улучшение alx san assigned 2017-11-03T13:33:39+05:00 2025-10-18T14:19:19+05:00 "Сценарий: Пользователь настроил резервирование ""без возврата на основной"". 1. ОСН-норма, РЕЗ-норма. Данные идут по потоку ОСН 2. ОСН-авария, РЕЗ-норма. Данные переключаются на поток РЕЗ 3. ОСН-норма, РЕЗ-норма. Данные по прежнему идут по потоку РЕЗ 4. ОСН-норма, РЕЗ-авария. Данные переключаются на поток ОСН 5. ОСН-норма, РЕЗ-норма. Данные переключаются на поток РЕЗ Поведение в пункте 5 кажется пользователям не логичным, и мне в том числе. Раз уж вынуждено было произведено переключение на '''основной''' поток, и он в норме, то какой смысл в возврате на резервный ? Предлагаю: в режиме ""без возврата"" производить переключение на другой поток только при аварии на текущем потоке. " san 1 очередь 537 "Резервирование потоков: добавить опцию ""передавать/не передавать данные в резервном потоке""" ПЛИС (sw) улучшение alx san assigned 2021-09-08T11:59:20+05:00 2025-10-15T18:00:07+05:00 "Сейчас при переходе на резерв одной стороны, эта сторона передаёт на дальнюю сторону извещение, через биты RAI в ЦСС. Сделано это для того, чтобы в резервном потоке можно было передавать другие данные и переключение на обоих сторонах было одновременным(чтобы не получилось так что одна переключилась на резерв, а другая нет и передает ложные данные пользователю). В передаче и анализе RAI есть минус - в случае если ЦСС формируется не в нашем блоке, то в нём может присутствовать RAI, что может привести, как минимум, к ложному переключению на резерв или гипотетически к ""кольцу RAI"" Алексей(ledol) предлагает добавить еще один вариант алгоритма резервирования: Не передавать RAI и в резервном потоке всегда передавать данные из основного, тогда каждая сторона независимо от другой может переключаться на резерв." san 2 очередь 272 "Кнопка ""Применить"" на вкладке Ethernet->VLAN, Ethernet->RSTP" web-интерфейс (sw) улучшение alx san new 2017-09-18T15:22:59+05:00 2023-09-11T17:58:56+05:00 "Предлагается вместо немедленной записи каждого изменения настроек в коммутатор, записывать все изменения только после нажатия кнопки ""Применить"". За время работы аппаратуры разные пользователи жалуются на неудобство ""мгновенного"" применения настроек на вкладке Ethernet->VLAN. Случайно ткнув мышкой парой пикселов правее-левее можно сломать связь с блоком. Кроме этого, ""пошаговая"" настройка немного сложнее, т.к. нужно соблюдать определённую последовательность действий, чтобы не потерять связь с блоком.(например при переносе порта CPU в другой VLAN нужно обязательно сначала создать новый vlan, а потом уже удалять старый) А недавно я сам столкнулся с неудобством такого подхода настраивая VLAN на блоках в кольце RSTP(""промежуточные"" состояния настройки сложно проанализировать, кроме того шаги вызывают кольца и перестроения дерева, и гораздо проще было бы настроить за ""одно применение"" чем пошагово. p.s. Ваня сравнивает настройку VLAN на нашей аппаратуре с игрой [https://ru.wikipedia.org/wiki/Сапёр_(игра) ""Сапёр""]." san 2 очередь 303 Резервирование потоков: добавить настройку таймаута детектирования аварии ПЛИС (sw) улучшение alx san assigned 2017-11-03T13:03:19+05:00 2025-10-15T18:00:07+05:00 Сейчас при возникновении кратковременной аварии поток переключается на резервсразу. В некоторых случаях, например при грозе или э/м помехах пользователи предпочитают чтобы поток не переключался на резерв при кратковременных авариях, поэтому предлагается ввести настройку таймаута. san 2 очередь 314 Добавить поле комментария в настройки групповых каналов web-интерфейс (sw) улучшение alx san new 2017-12-06T18:03:27+05:00 2017-12-06T18:06:08+05:00 "Добавить поле комментария к каждому групповому каналу, в настройки групповых каналов В старый интерфейс и новый. " san 2 очередь 358 Новая функция: дистанционный анализ трафика ethernet sw улучшение alx alx new 2018-10-10T16:22:10+05:00 2018-10-10T18:10:10+05:00 "Иногда при исследовании прохождения (или непрохождения) трафика по сети требуется узнать, что за пакеты ходят через наш коммутатор. Когда блок находится в физической доступности, можно подключить анализатор (компьютер) к свободному порту и миррорить туда интересующий трафик. Но если блок находится далеко и доступен только по сети, это сделать затруднительно. Отчасти задача решается направлением (миррорингом) кадров в порт CPU и наблюдением за трафиком TCPDUMP'ом, но здесь есть ряд недостатков. Во-первых, tcpdump не покажет, каким образом тегированы кадры, так как сразу после приема кадра его тэг отбрасывается. Во-вторых, трафик может быть довольно большой, и CPU в нем может ""захлебнуться"". В-третьих, возможна нежелательная ""интерференция"", например, из-за случайного пересечения адресов (скажем, CPU отвечает на запрос, посчитав, что запрос адресован ему, хотя это был запрос из независимой изолированной сети)... Насколько я помню, в коммутаторе есть такая функция - проба трафика. Суть ее в том, что из потока кадров выбираются отдельные с некоторой вероятностью (например 1 из 100) и отправляются в CPU. Предлагается задействовать ее для наблюдения за трафиком. Кадры, направленные в CPU этой функцией, могут быть опознаны по соответствующему коду (код указывается в тэге). Предлагается такие пакеты направлять в специальный VLAN (снабжать их тэгом с ID, например, 2222). Это исключит ""интерференцию"" с настоящим пользовательским трафиком (мониторинг/управление). В SW-01 для наблюдения за кадрами создать новый интерфейс с VLAN ID 2222. Наблюдать трафик можно будет как tcpdump'ом, так и самим демоном swd, который мог бы принятые кадры отображать (с минимальным анализом) в веб-интерфейсе. Прошу высказывать мнения, пожелания, критику и т.п." alx 2 очередь 66 При несконфигурированной ПЛИС выдавать аварию swd баг alx alx new 2014-07-31T16:28:14+06:00 2014-07-31T16:28:14+06:00 "При постоянной ошибке конфигурации ПЛИС (например испорчен файл прошивки) горит зеленая лампочка ""OK"", и о неисправности платы ничего не гвоорит. Надо формировать аварию при незаконфигурированной ПЛИС." alx 2 очередь 310 Мониторинг регенераторов SM-xx web-интерфейс (sw) задача alx san new 2017-11-22T15:33:18+05:00 2018-10-09T10:11:50+05:00 "Пользователи часто жалуются на сложность мониторинга регенераторов подключенных к плате SM-xx. Тема эта уже давно назрела, попытался всё описать, если что-то забыл или наврал поправляйте. Что нужно от регенераторов: I. Собственно мониторинг. Периодическое обновление информации о состоянии участков линейного тракта, накопление статистики и т.д.. II. Детализация аварии на линейном тракте. Допустим тракт состоит из N участков (N-1 регенераторов) и в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария. Сложности текущего варианта: 1. Для мониторинга нужно периодически посылать команду опроса, т.е. программе мониторинга кроме чтения придётся делать ещё и запись в определённую переменную, либо посылать команду другими средствами. В любом случае это дополнительная сложность. 2. При новом опросе таблица очищается и до окончания опроса в таблице не корректные данные (не понятно регенератор пропал(не отвечает) или опрос ещё не завершен) а точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать и я думаю что перекладывать задачу определения критериев конца опроса на пользователя не правильно. 3. Проблема с отказом EOC канала на платах SM-01, суть: EOC канал может перейти в нерабочее состояние при некоторых условиях(одновременное попадание ЕОС пакетов с разных сторон в регенератор). Подробности у Влада. 4. Конфликты с совместным доступом, это следствие из п. 1-3, если два пользователя независимо друг от друга будут проводить опрос и считывать таблицу, они могут мешать друг-другу. - Очищение таблицы вызванное опросами одного мешает прочитать таблицу другому. - При повторном опросе до завершения предыдущего, возможно проявление проблемы с EOC на SM-01. Так-же это возможно при мониторинге с двух сторон Предлагается: a. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе. b. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии. с. Пользователь, при необходимости, может через веб-морду нажать кнопку опрос не дожидаясь автоматического обновления таблицы. Вопросы: - Критерии конца опроса (таймаут, кол-во регенераторов,...) - Опрос по разным парам. Для простоты ограничиться опросом по паре А? - Что делать с опросом с двух концов? " san 2 очередь 31 Сделать коммутацию обратного потока Е1 web-интерфейс (sw) улучшение alx alx new 2014-03-21T14:07:03+06:00 2014-06-16T18:13:53+06:00 Сделать коммутацию обратного потока Е1. alx 2 очередь 277 Окно платы SM-xx: опрос при входе web-интерфейс (sw) улучшение alx san new 2017-09-27T17:04:47+05:00 2017-09-28T10:02:00+05:00 "Предлагается при каждом открытии окна платы SM-xx автоматически запускать ""опрос"" чтобы не вводить пользователя в заблуждение устаревшими данными в таблице. p.s. это решение временное, в идеале в таблице должно отображаться актуальное состояние регенераторов, без нажатия кнопок." san 2 очередь 306 Прятать лишние вкладки web-интерфейс (sw) улучшение alx san new 2017-11-16T20:01:51+05:00 2020-04-15T12:03:38+05:00 "Предлагаю дать пользователю возможность скрыть ненужные ему вкладки из окна веб-морды. Например вкладка CDR может быть ненужной, если в блоке нет платы VE, а вкладка Сервис используется обычно только при неполадках и т.д. .. Предлагаю где-нибудь, например на вкладке Разное, разместить набор чекбоксов для выбора нужных/ненужных вкладок. Предлагаю хранить набор выбранных вкладок в ПЗУ блока." san Как-нибудь потом 273 Функция автоматического контроля канала sw задача alx alx assigned 2017-09-18T18:46:23+05:00 2025-10-15T18:00:07+05:00 "viktam натолкнул меня на идею (см. mc-04:#12). Предположим, в сети организован некий канал, который никак не используется в ""нормальных"" ситуациях, а предусмотрен на случай проведения каких-либо ""аварийных"" работ. Канал, который не находится в работе, легко непреднамеренно ""сломать"" в процессе различных изменений конфигурации, и не заметить этого. Будет очень печально, если на момент наступления таких работ окажется, что аварийный канал не работает. Поэтому требуется регулярная проверка исправности такого канала. Возникла идея - возложить такую проверку на саму аппаратуру. Мне видится несколько возможных вариантов проверки исправности канала (в зависимости от его типа и характера): передача в канал некоего сигнала (гармонического для речевых каналов, цифрового для цифровых) и прием этого сигнала на выходе канала. Периодичность посылки должна настраиваться - раз в час, раз в сутки и т.п. Период должен быть достаточно большим чтобы не мешать нормальному использованию канала. Если приемник не ""увидел"" сигнал в течение двух интервалов (тоже, наверное, можно настраивать), формируется предупреждающее сообщение (придумать как и какое). Сигнал не должен быть очень простым, чтобы не было ложных положительных срабатываний, но и не должен быть слишком сложным, чтобы легко был реализуем средствами ПЛИС. Как вариант, последовательность тональных посылок нескольких определенных частот определенной длительности... Предлагаю обсудить детали возможной реализации и степень полезности этой функции." alx Как-нибудь потом 97 Предложение: хранить в плате sw-01 запасные конфигурации swd задача alx san new 2015-03-17T17:27:17+05:00 2017-11-17T13:29:18+05:00 "При выгрузке конфигурации, кроме носителей подключеных к ПК предусмотреть ещё выгрузку во внутреннюю память sw. Название конфигурации должен задать пользователь(например, это может быть имя файла, или как угодно) ну и соответственно при загрузке конфигурации в блок, дать возможность выбрать и из конфигураций во внутренней памяти" san