Opened 22 hours ago

Closed 20 hours ago

#485 closed баг (fixed)

Не появляется авария "LOS" в окончании RTP

Reported by: san Owned by: alx
Priority: средний Milestone: 1 очередь
Component: VE-02 Keywords:
Cc:

Description

В блоке VIP установлен субмодуль 4W04 и имеются 4 окончания RTP для этого субмодуля.

  1. Окончание 253 я соединил RTP-потоком с окончанием 255, состояние обоих окончаний ОК, данные передаются, светодиод соответствующий окончанию горит.
  2. На вкладке канальных окончаний нажимаю кнопку "Блокировка потока" сначала для окончания 253, затем для 255.
  3. Статус обоих окончаний Blocked, светодиоды потушены.
  4. Нажимаю кнопку "Блокировка потока" для окончания 253 (того которое было заблокировано первым).
  5. Ожидаю, что окончание разблокируется и перейдёт в состояние LOS, т.к. противоположная сторона заблокирована и не передаёт данные. Но в статусе окончания 253 отображается состояние Ок (при этом светодиод погашен, данные канала ТЧ не проходят).

r2705 (на самом деле не уверен, у меня в вебморде отображается ревизия 0, тестовую прошивку залил alx)

Change History (10)

in reply to:  description comment:1 by alx, 22 hours ago

Resolution: invalid
Status: newclosed

Replying to san:

  1. Ожидаю, что окончание разблокируется и перейдёт в состояние LOS, т.к. противоположная сторона заблокирована и не передаёт данные. Но в статусе окончания 253 отображается состояние Ок (при этом светодиод погашен, данные канала ТЧ не проходят).

Это нормальное поведение канального окончания. Дело в том, что у MSP отсутствует возможность запросить текущее состояние медиапотока (принимается он в настойщий момент или нет). MSP может индицировать только изменение состояния медиапотока: то есть после того как канал в MSP создан, и получен первый пакет RTP из сети, MSP индицирует появление потока. Если потом поток приниматься перестал, MSP индицирует пропадание медиапотока. И т.д.

Учитывая описанную выше логику работы MSP, следовало бы изначально (сразу после создания канала) считать, что медиапоток отсутствует. Однако это давало бы множество ложных аварий канала, так как канал в MSP создается не только при создании канального окончания пользователем, но и, например, при изменении целого ряда настроек (некоторые настройки могут быть изменены только путем пересоздания канала в MSP).

Чтобы не давать пользователю "лишних" аварий, канальное окончание RTP использует немного более хитрую логику: при создании канала оно "априори" считает, что медиапоток на входе есть (и поэтому индицирует "OK", а не "LOS"). Но при этом запускается специальный таймер. В норме (когда медиапоток действительно принимается), при получении первого пакета RTP MSP сигнализирует появление медиапотока до истечения таймера. По этому событию таймер останавливается. Но если индикации появлении медиапотока от MSP не пришло (например потому что медиапоток отсутствует), запущенный таймер истечет, и тогда плата начнет индицировать "LOS".

Предполагаю, что тебе следовало просто немного подождать, и индикация "OK" в веб-интерфейсе изменилась бы на "LOS". Я в процесе разработки это проверял (с той лишь разницей, что в моих экспериментах удаленной стороной был компьютер, но он не передавал никакого медиапотока, я лишь контролировал на компьютере прием медиапотока от платы VE-02), и отображаемое состояние канального окончания сначала менялось на "OK", а уже чуть позже - на "LOS". Так и должно быть.

Last edited 22 hours ago by alx (previous) (diff)

comment:2 by san, 22 hours ago

Хм.. А сколько примерно надо подождать?

comment:3 by san, 21 hours ago

Жду с момента написания прошлого коммента, подозреваю, что это дольше чем задумано.
Обрати внимание, что индикация светодиодом корректная(погашен), а ОК присутствует.

Last edited 21 hours ago by san (previous) (diff)

in reply to:  2 comment:4 by alx, 21 hours ago

Replying to san:

Хм.. А сколько примерно надо подождать?

Хм... Не помню, сейчас посмотрю в коде...

Если включено VAD, то 3 секунды, если не включено - то 0.8 с.

in reply to:  3 comment:5 by alx, 21 hours ago

Replying to san:

Обрати внимание, что индикация светодиодом корректная(погашен), а ОК присутствует.

Индикация светодиодом не подчиняется описанной выше логике. Светодиод зажигается только при получении индикации появления медиапотока от MSP.

Last edited 21 hours ago by alx (previous) (diff)

in reply to:  3 ; comment:6 by alx, 21 hours ago

Replying to san:

Жду с момента написания прошлого коммента, подозреваю, что это дольше чем задумано.

Верно ли я понял, что в течение пяти минут после разблокирования канального окончания его состояние так и не изменилось на "LOS"?

in reply to:  6 ; comment:7 by san, 21 hours ago

Replying to alx:

Replying to san:

Жду с момента написания прошлого коммента, подозреваю, что это дольше чем задумано.

Верно ли я понял, что в течение пяти минут после разблокирования канального окончания его состояние так и не изменилось на "LOS"?

Да. Загляни в сой блок VIP, я его так и оставил после эксперимента

Version 0, edited 21 hours ago by san (next)

in reply to:  7 comment:8 by alx, 21 hours ago

Resolution: invalid
Status: closedreopened
Summary: Ложное отображение состояния RTP-потокаНе появляется авария "LOS" в окончании RTP

Replying to san:

Да. Загляни в мой блок VIP, я его так и оставил после эксперимента

Тогда это, конечно, какой-то баг. Переоткрыл тикет и скорректировал заголовок (т.к. твое первоначальное ожидание было ошибочным).

comment:9 by alx, 21 hours ago

Priority: полный атассредний

comment:10 by alx, 20 hours ago

Resolution: fixed
Status: reopenedclosed

In 2707/sip_ua:

Исправлена ошибка: в канальном окончании RTP
при остановке медиапотока через stopRTP()
не сбрасывался флаг seenRTPevent. В результате,
если перед остановкой потока принималась индикация
состояния потока от MSP, механизм отложенной аварии
LOS по таймеру не действовал. Closes #485.

Note: See TracTickets for help on using tickets.