Opened 3 weeks ago
Closed 10 days ago
#456 closed баг (не будем делать)
Двусторонний отбой канального окончания SL
Reported by: | alx | Owned by: | alx |
---|---|---|---|
Priority: | средний | Milestone: | 1 очередь |
Component: | any | Keywords: | |
Cc: | roman_zhur, san |
Description
В процессе анализа логов по другому тикету (см. #455) я заметил, что в некоторых случаях при работе двух канальных окончаний SL, включенных друг на друга, удаленная сторона не переходит в исходное при получении сигнала "отбой" из канала TDM.
В логе видно, что в 6:58:27 канальное окончание начало передавать в канал сигнал "отбой". Однако в логе другой стороны видно, что вместо длинного сигнала (~800 мс) принимающая сторона зафиксировала короткий сигнал (150 мс) и проигнорировала его, оставшись в состоянии Connected
. Отбой этой стороны произошел только в 06:58:29, когда второй участник соединения положил трубку.
@roman_zhur, подтверди, пожалуйста, что в экспериментах тикета #455 отбой одной стороны соединения действительно не приводил к переходу другой стороны в исходное.
Могу добавить, что в моих собственных экспериментах (было выполнено около 3000 вызовов) такого не происходило - удаленная сторона всегда определяла "отбой" как длинный сигнал (790 мс) и переходила в исходное.
Attachments (18)
Change History (31)
follow-up: 2 comment:1 by , 3 weeks ago
by , 3 weeks ago
Attachment: | messages_ve01_1 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_1 added |
---|
by , 3 weeks ago
Attachment: | messages_ve01_2 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_2 added |
---|
comment:2 by , 3 weeks ago
Replying to roman_zhur:
Да, это действительно так. Одна сторона будет в состоянии
Connected
до тех пор, пока сама не положит трубку.
Спасибо за подтверждение.
Я заметил, что обнаружению "укороченного" сигнала (150 мс вместо 800 мс) всегда предшествует переход канального окончания в режим PassThru:
Apr 27 09:16:04 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: PassThru mode autoswitch, ts=2, flags=0000, data=1 Apr 27 09:16:04 sip_ua[454]: comcerto.cpp:6132: ts 2: PassThru mode autoswitch to 1 Apr 27 09:16:04 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=255 Apr 27 09:16:04 sip_ua[454]: sl.cpp:348: SL[2]: duration 150 ms
Дело в том, что частота 2100 Гц, которая используется для передачи сигнальных сообщений, совпадает с частотой несущей модема в протоколах V.8/V.25. Закралось подозрение, что обнаружение модема и переход в режим PassThru как-то связаны с данной проблемой - например переход в PassThru каким-либо образом сбрасывает состояние фильтров, и MSP передает ложное сообщение об окончании сигнала, в то время как сигнал продолжает идти (это все просто догадки)...
Прошу провести еще ряд аналогичных экспериментов:
- в настройках канальных окнчаний SL установить вариант сигнализации 2600 Гц;
- в настройках канальных окнчаний SL установить вариант сигнализации 600+750 Гц;
- снова установить вариант сигнализации 2100 Гц и установить запрет VBD;
- если баг проявлялся в вариантах 2600 и/или 600+750, повторить эти варианты с запретом VBD.
Во всех случаях интересует, будет ли проявляться баг или нет.
Во втором случае есть еще одна странность: после того, как я положил трубку 11@, SL ve02@ перешел из состояния
Idle
вNumRecv
и вернулся обратно вIdle
.
Насколько можно видеть в логе, длительность сигнала "отбой", передаваемого удаленной стороной, была определена как 170 мс (и опять сообщению об окончании сигнала предшествовал переход в режим PassThru!). Канальное окончание интерпретировало этот сигнал как "занятие" и перешло в состояние NumRecv
.
follow-up: 4 comment:3 by , 3 weeks ago
Звонок 22@ --> 11@
.
- Делаю вызов;
- жду
Ringing
вызываемого FXS; - отвечаю на звонок;
- жду несколько секунд;
- кладу трубку 11@;
- жду несколько секунд;
- кладу трубку 22@.
1.0 вариант сигнализации 2600 Гц
Логи messages_ve01_2600 и messages_ve02_2600.
Баг с Blocked
не воспроизводится. Когда одна сторона кладет трубку, вторая сторона так же получает отбой.
2.0 вариант сигнализации 600+750 Гц
Логи messages_ve01_600-750 и messages_ve02_600-750.
Аналогично 2600 Гц баг с Blocked
не воспроизводится. Когда одна сторона кладет трубку, вторая сторона так же получает отбой.
3.0 вариант сигнализации 2100 Гц и запрет VBD
3.1 В первом случае, как и в предыдущих, сначала я кладу трубку вызываемого абонента (11@), жду несколько секунд, затем кладу трубку вызывающего (22@). В этом случае баг с Blocked
не воспроизводится, но 22@ продолжает оставаться в состоянии Connected
после отбоя 11@, пока я не положу трубку 22@.
Логи первого случая messages_ve01_VBD_1 и messages_ve02_VBD_1.
3.2 Во втором случае сначала я кладу трубку вызываемого абонента (11@) и почти сразу же кладу трубку вызывающего абонента (22@). В этом случае баг с Blocked
воспроизводится: состояние Blocked
у SL на VE-02.
Логи второго случая messages_ve01_VBD_2 и messages_ve02_VBD_2.
3.3 В третьем случае звонок 22@ --> 11@, но сначала я кладу трубку вызывающего абонента (22@), затем вызываемого (11@). В этом случае баг с Blocked
воспроизвелся два раза из десяти, состояние Blocked
у SL на VE-02. Вызываемый (11@) сразу получил отбой после того, как я положил трубку вызывающего (22@).
Логи третьего случая messages_ve01_VBD_3 и messages_ve02_VBD_3.
by , 3 weeks ago
Attachment: | messages_ve01_2600 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_2600 added |
---|
by , 3 weeks ago
Attachment: | messages_ve01_600-750 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_600-750 added |
---|
by , 3 weeks ago
Attachment: | messages_ve01_VBD_1 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_VBD_1 added |
---|
by , 3 weeks ago
Attachment: | messages_ve01_VBD_2 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_VBD_2 added |
---|
by , 3 weeks ago
Attachment: | messages_ve01_VBD_3 added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_VBD_3 added |
---|
follow-up: 5 comment:4 by , 3 weeks ago
Replying to roman_zhur:
1.0 вариант сигнализации 2600 Гц
Баг сBlocked
не воспроизводится.
Ты по-моему перепутал тикеты. :) Баг с "залипанием" канального окончания в состоянии Blocked
рассматривался в тикете #455. Насколько я понимаю, с тем багом мы разобрались, возможные меры приняты, тикет #455 закрыт. Темой данного тикета (#456) является совсем другой баг - двусторонний отбой (перечитай, пожалуйста, описание тикета). Именно воспроизведение этого бага, а не описанного в тикете #455, меня и интересовало, когда я в comment:2 просил провести новую серию экспериментов!
То есть требуется заполнить такую таблицу:
вариант 2100 Гц | вариант 2600 Гц | вариант 600+750 Гц | |
---|---|---|---|
нет запрета VBD | двусторонний отбой случается | ??? | ??? |
запрет VBD | ??? | ???* | ???* |
* только если без запрета VBD двусторонний отбой возникает
Когда одна сторона кладет трубку, вторая сторона так же получает отбой.
Могу ли я понимать это так, что баг двустороннего отбоя в этом варианте не воспроизводится?
2.0 вариант сигнализации 600+750 Гц
Аналогично 2600 Гц баг сBlocked
не воспроизводится.
Это не тема данного тикета. Про баг с Blocked
- тикет #455.
Когда одна сторона кладет трубку, вторая сторона так же получает отбой.
Могу ли я понимать это так, что баг двустороннего отбоя в этом варианте не воспроизводится?
3.0 вариант сигнализации 2100 Гц и запрет VBD
3.1 В этом случае баг сBlocked
не воспроизводится,
Это не тема данного тикета. Про баг с Blocked
- тикет #455.
но 22@ продолжает оставаться в состоянии
Connected
после отбоя 11@, пока я не положу трубку 22@.
Понятно. То есть баг все равно воспроизвелся.
Логи первого случая messages_ve01_VBD_1 и messages_ve02_VBD_1.
Хм... Очень интересно... В приложенном логе я вижу вот это:
Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=18 Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: PassThru mode autoswitch, ts=2, flags=0000, data=1 Apr 27 10:29:00 sip_ua[454]: comcerto.cpp:6132: ts 2: PassThru mode autoswitch to 1
Это выглядит как работа функции VBD - при обнаружении сигнала модема канальное окончание переходит в режим PassThru. Насколько я понимаю, при запрещенном VBD такого происходить не должно...
3.2 В этом случае баг с
Blocked
воспроизводится: состояниеBlocked
у SL на VE-02.
Это не тема данного тикета. Про баг с Blocked
- тикет #455.
3.3 В этом случае баг с
Blocked
воспроизвелся два раза из десяти, состояниеBlocked
у SL на VE-02.
Это не тема данного тикета. Про баг с Blocked
- тикет #455.
follow-up: 7 comment:5 by , 3 weeks ago
Replying to alx:
Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=18 Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: PassThru mode autoswitch, ts=2, flags=0000, data=1 Apr 27 10:29:00 sip_ua[454]: comcerto.cpp:6132: ts 2: PassThru mode autoswitch to 1Это выглядит как работа функции VBD - при обнаружении сигнала модема канальное окончание переходит в режим PassThru. Насколько я понимаю, при запрещенном VBD такого происходить не должно...
Я перепроверил исходный код - при запрете VBD никаких "PassThru mode autoswitch" быть не должно...
Ты совершенно уверен, что при проведении эксперимента, в ходе которого был получен лог messages_ve02_VBD_1, в настройках канального окончания SL был установлен запрет VBD? Перепроверь, пожалуйста. Если при установленной отметке чекбокса "Запрет VBD" в логе все равно появляются строки с "PassThru mode autoswitch", то это, наверое, еще один баг...
comment:6 by , 3 weeks ago
Ты по-моему перепутал тикеты
Ты прав.
Вот таблица
2100 Гц | 2600 Гц | 600+750 Гц | |
---|---|---|---|
нет запрета VBD | воспроизводится | не воспроизводится | не воспроизводится |
запрет VBD | воспроизводится | не воспроизводится | не воспроизводится |
follow-up: 8 comment:7 by , 3 weeks ago
Ты совершенно уверен, что при проведении эксперимента, в ходе которого был получен лог messages_ve02_VBD_1, в настройках канального окончания SL был установлен запрет VBD? Перепроверь, пожалуйста.
Воспроизвел еще раз. В этот раз я точно уверен, что чек-бокс "запрет VBD" был установлен на обоих SL. Вот новые логи messages_ve01_2100_VBD, messages_ve02_2100_VBD.
by , 3 weeks ago
Attachment: | messages_ve01_2100_VBD added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_2100_VBD added |
---|
comment:8 by , 3 weeks ago
Replying to roman_zhur:
Воспроизвел еще раз. В этот раз я точно уверен, что чек-бокс "запрет VBD" был установлен. Вот новые логи messages_ve01_2100_VBD, messages_ve02_2100_VBD.
Печально. Значит придется разбираться еще с одним багом... Создал тикет #457.
comment:9 by , 3 weeks ago
Тикет #457 закрыт. Возвращаюсь к данной проблеме.
Файл sip_ua для платы VE-02 с исправленным багом #457 положил в http://repo.adc-line.ru/misc/sip_ua
Прошу записать этот файл в плату VE-02 и повторить эксперимент с вариантом сигнализации 2100 Гц и запретом VBD. Как и раньше, интересует, воспроизведется ли баг, описанный в описании тикета.
follow-up: 11 comment:10 by , 3 weeks ago
Проверка, как в комментарии 3.
С модицифицированным sip_ua на VE-02 баг не воспроизводится ни с одной, ни с другой стороны.
Логи messages_ve01_mod и messages_ve02_mod.
by , 3 weeks ago
Attachment: | messages_ve01_mod added |
---|
by , 3 weeks ago
Attachment: | messages_ve02_mod added |
---|
follow-up: 12 comment:11 by , 3 weeks ago
Cc: | added |
---|
Replying to roman_zhur:
С модицифицированным sip_ua на VE-02 баг не воспроизводится ни с одной, ни с другой стороны.
Спасибо. В таком случае, я считаю, что можно считать подтвержденным влияние VBD на данную проблему.
@san, вынужден подключить тебя, так как у меня самого, кроме идеи добавить в РЭ рекомендацию запрещать VBD при использовании варианта "2100 Гц", других идей нет. Похоже, что это особенность MSP - в момент PassThru autoswitch давать ложное сообщение о том, что прием частоты прекратился, и мы с этим ничего поделать не можем... Есть ли альтернативные идеи у тебя?
follow-up: 13 comment:12 by , 10 days ago
Replying to alx:
@san, вынужден подключить тебя, так как у меня самого, кроме идеи добавить в РЭ рекомендацию запрещать VBD при использовании варианта "2100 Гц", других идей нет. Похоже, что это особенность MSP - в момент PassThru autoswitch давать ложное сообщение о том, что прием частоты прекратился, и мы с этим ничего поделать не можем... Есть ли альтернативные идеи у тебя?
А можно, кроме добавления в РЭ, сделать ещё так, чтобы в окне настройки платы, при выборе варианта "2100 Гц" автоматически запрещался VBD (выбирался вариант запретить и настройка дизейблилась). На мой взгляд, так меньше вероятность что пользователь увидит этот баг, а чем меньше багов, тем приятнее пользователю работать с нашей аппаратурой.
comment:13 by , 10 days ago
Resolution: | → не будем делать |
---|---|
Status: | new → closed |
Replying to san:
А можно, кроме добавления в РЭ, сделать ещё так, чтобы в окне настройки платы, при выборе варианта "2100 Гц" автоматически запрещался VBD (выбирался вариант запретить и настройка дизейблилась).
Конечно, можно.
На мой взгляд, так меньше вероятность что пользователь увидит этот баг, а чем меньше багов, тем приятнее пользователю работать с нашей аппаратурой.
На мой взгляд, это очень деструктивное решение (прямо скажем, диверсия). Оно чревато тем, что у пользователя просто перестанет работать связь (вдруг ему как раз необходимо обеспечить работу модемов через эту соединительную линию)! Получится, что ради устранения не очень серьезной проблемы (ну произойдет освобождение канала на несколько секунд позже, не когда первый абонент положит трубку, а когда второй - кто это вообще заметит?) мы создадим пользователям намного более серьезную проблему (вдвойне неприятную, так как все уже же работало, но в результате наших действий перестанет) - это IMHO совсем не способствует приятности работы с нашей аппаратурой. :) Поэтому такой вариант я отверг сразу.
Так как никаких других идей, несколько я понял, у тебя нет, создал тикет для внесения рекомендации в РЭ.
Да, это действительно так. Одна сторона будет в состоянии
Connected
до тех пор, пока сама не положит трубку.Дополнительные логи.
22@ --> 11@
(messages_ve01_1 и messages_ve02_1)Положил трубку 11@, подождал ~30 секунд, положил 22@.
22@ --> 11@
(messages_ve01_2 и messages_ve02_2)Положил трубку 22@, подождал ~90 секунд, положил 11@.
Во втором случае есть еще одна странность: после того, как я положил трубку 11@, SL ve02@ перешел из состояния
Idle
вNumRecv
и вернулся обратно вIdle
. После этого SL ve01 перешел из состоянияIdle
вNumRecv
и вернулся обратно вIdle
.