RTP LOS при настройках VAD и G.729

[san]

У пользователя VE-02 RTP-потоки с VAD и G.729. В такой конфигурации авария LOS не должна возникать никогда, однако в очень редких случаях такое случается(три месяца между случаями).
В момент проишествия поток с обоих сторон перешел в состояние LOS и оставался в таком состоянии. Для решения проблемы пользователь создал новые RTP-потоки в обоих платах и они работают нормально, связность есть
На скриншотах блоки Васюган и Томск которые соединены RTP потоком, проблема проявилась примерно 7 сентября 2022.


Проблема наблюдалась на прошивке платы VE-02 ревизии 39 и ранее на ревизии 36

В комментах приложу конфигурационные файлы и логи.

[alx]

Во-первых, насколько я вижу, приложенные к тикету логи - это не логи плат VE-02, а логи плат SW-01. Поэтому приложенные логи мало что могут дать для анализа проблемы платы VE-02. Тем не менее, попробую проанализировать то, что есть.

Tomsk

Плата SW-01 в блоке Tomsk была загружена и обнаружила плату VE-02 в 05:11:41. В результате обнаружения плате VE-02 была передана конфигурация, записанная в конфиг-файле блока. С этого момента следующие 4 минуты плата VE-02 работала без аварий.

В 05:15:40 в плату VE-02 блока Tomsk оператором была загружена новая конфигурация. Спустя секунду, в 05:15:41, одновременно появились аварии LOS каналов 2 и 4. Мне кажется маловероятным, что данные факты случились независимо друг от друга. Есть подозрение, что авария LOS появилась в результате записи в плату новой конфигурации.

Полторы минуты спустя, в 05:17:17, была снова произведена запись конфигурации в плату VE-02. В следующую секунду (05:17:18) авария LOS канала 4 завершилась.

Далее в 05:17:38 снова была записана новая конфигурация в плату VE-02. В ту же секунду авария LOS появилась вновь. Судя по отметке времени, это та самая авария, которая показана на скриншоте в описании тикета.

Далее в 05:19:15 в плату VE-02 была снова записана новая конфигурация. В следующую секунду (05:19:16) авария LOS завершилась.

Далее было еще две записи конфигурации в плату VE-02 - в 05:19:16 и 05:21:02. В следующую секунду после последней записи (в 05:21:03) авария LOS вновь возникла.

Думаю, что нет смысла продолжать анализ данного лога. Мне кажется очевидным, что возникновение и завершение аварии LOS коррелирует с записями операторами (обрати внимание, что конфигурации записывались с разных адресов IP) настроек в плату VE-02. Уверен, что между этими событиями есть прямая причинно-следственная связь.

Последняя авария LOS завершалась в 08:04:00. После прекращения последней аварии LOS было сделано еще три различных записи конфигурации в плату VE-02 - в 08:04:1, в 08:04:12 и в 08:25:07 (то есть спустя 20 минут после прекращения последней аварии LOS). Затем в 08:25:29 конфигурация блока была сохранена в файл. Причем последняя запись конфигурации и ее сохранение выполнены с другого IP адреса. До этого с момента загрузки платы SW-01 сохранение конфигурации блока в файл не производилось.

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

s.vasugan

Первая авария LOS платы VE-02 в слоте 10 7 сентября зафиксирована в 04:58:22 (канал 3). Секундой ранее (в 04:58:21) оператор произвел запись новой конфигурации в эту плату VE-02. До этой записи плата VE-02 на протяжение долгого времени (месяцы) работала без аварий.

Далее в 04:59:02 оператор снова записал новую конфигурацию в плату VE-02. В следующую секунду (04:59:03) начала фиксироваться авария LOS канала 6.

Далее много раз производилось изменение конфигурации блока...

Последняя зафиксированная команда LOS завершилась в 07:43:36. Секундой ранее, в 07:43:35, в плату VE-02 оператором была записана новая конфигурация.

Как и в случае блока Tomsk, мне кажется очевидным, что возникновение и завершение аварии LOS коррелирует с записями операторами (обратите внимание, что конфигурации записывались с разных адресов IP) настроек в плату VE-02. Уверен, что между этими событиями есть прямая причинно-следственная связь.

Согласно приложенному конфиг-файлу, в конфигурации каналов 3 и 6, которые и фиксировали аварию LOS, функция VAD отключена (отсутствует атрибут noVAD=false). В такой конфигурации авария LOS должна фиксироваться платой VE-02. Следовательно, наличие аварии LOS при таких настройках не является багом. Однако, в силу активного вмешательства операторов, изменявших настройки платы, невозможно с уверенностью судить о том, действительно ли функция VAD каналов 3 и 6 была отключена в период инцидента или нет.

Общие выводы и рекомендации

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

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

• В конфигурации канальных окончаний платы VE-02 снять отметку чекбоксов "Запрет VAD".
• Записать конфигурацию в плату VE-02.
• Сохранить конфигурацию блока в конфиг-файл платы SW-01.
• Ждать возникновения ложной аварии LOS.

При новом возникновении аварии LOS:

• не меняя настроек платы VE-02, загрузить из нее лог-файлы и прикрепить к этому тикету.
• По-прежнему не меняя конфигурации скачать лог-файлы из платы SW-01 и тоже прикрепить к тикету.
• По-прежнему не меняя конфигурации, сохранить конфигурацию блока в файл. Файл конфигурации скачать и тоже прикрепить к тикету.
• После этого можно менять конфигурацию (например пересоздать канальное окончание для устранения ложной аварии).

Я повторно проанализировал исходный код (первый раз анализ проводился по устному сообщению), но снова не нашел возможности возникновения ложной аварии. Далее идут комментарии скорее для меня самого.

В массиве codec_list для кодека G729 поле enable_los установлено в значение false. При наличии атрибута noVAD=false переменная enable_vad принимает значение true (строка 330). При применении полученных настроек, если установлен кодек G729, переменная no_los_detection получает значение, обратное enable_los, то есть true (строки 331 и 363).

Далее, при старте потока RTP функция RTPMonitorEna() вызывается с первым аргументом, обратным значению no_los_detection, то есть false, что означает отключение мониторинга потока RTP. Кроме того, при no_los_detection равном true не запускается таймер, по которому при отсутствии индикации наличия потока от MSP активируется авария LOS. Напротив, генерируется "синтетическая" индикация наличия потока для снятия возможной аварии LOS.

Таким образом, никаких ошибок и "дыр", которые могли бы привести к ложной аварии LOS, в своем коде я не вижу. Могу гипотетически допустить баг в MSP, в результате которого MSP присылает индикацию отсутствия потока RTP несмотря на то, что ему запретили мониторить наличие потока... Но подобных жалоб от пользователей никогда ранее не поступало, поэтому считаю такое крайне маловероятным.

[san]

Да, действительно теперь сложно что-то понять.
Пользователь утверждал, что "ничего" не предшествовало возникновению аварии LOS, а все действия происходили позже. Но подтвердить это не возможно.
Я передам пользователю инструкцию, тикет вероятно можно пока закрыть, т.к. даже если это баг воспроизводится он по словам пользователя очень редко, если воспроизведётся, тогда и реоепнем.

[san]

Поскольку на обеих станциях в период возникновения инцидента имело место активное вмешательство в работу аппаратуры операторов

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

За последние два месяца ничего похожего не воспроизводилось.