Opened 11 years ago

Closed 11 years ago

#25 closed баг (готово)

Не пропадала авария отсутствия потока

Reported by: alx Owned by: alx
Priority: средний Milestone:
Component: any Keywords:
Cc:

Description

Ситуация: Две кассеты с платами VE-01 соединены между собой. Сконфигурирован RTP поток между платами. В первой кассете уже работает SW-01, в нее вставляем плату VE-01. В другой кассете включаем питание. В первой кассете VE-01 загрузилась раньше и начала сигнализировать аварию. Затем загрузилась VE-01 во второй кассете. В первой кассете авария пропала, во второй - появилась. Авария во второй кассете не пропала после включения передачи RTP потока в первой кассете.

Change History (7)

comment:1 by alx, 11 years ago

Status: newaccepted

comment:2 by alx, 11 years ago

Наверное надо периодически перезапрашивать состояние потока на случай "рассинхронизации" нашего понимания о его состоянии.

comment:3 by alx, 11 years ago

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

comment:4 by alx, 11 years ago

Выяснилось, что вместо ожидаемого RTPMonitorEvent со значением 1 приходит RTPMonitorEvent со значением 0. СУВы в таком состоянии тоже не проходят.

comment:5 by alx, 11 years ago

Причина определилась. Включать мониторинг необходимо только после включения RTP потока. То есть не в setRTPparams(), а в startRTP(). В таком случае сначала приходит RTPMonitorEvent со значением 0, а затем, когда появляется входной поток - со значением 1.

comment:6 by alx, 11 years ago

СУВы не работали по той же причине. Их, оказывается, надо переводить в соединенное (connected) состояние только после включения RTP потока.

comment:7 by alx, 11 years ago

Resolution: fixed
Status: acceptedclosed

In 343/sip_ua:

Методы startRTP() и stopRTP() сделаны виртуальными.
Включение/выключение мониторинга RTP и передачи СУВ перенесено
из setRTPparams() в startRTP() и stopRTP(). fixes #25.

Note: See TracTickets for help on using tickets.