Двусторонний отбой канального окончания SL

[alx]

В процессе анализа логов по другому тикету (см. #455) я заметил, что в некоторых случаях при работе двух канальных окончаний SL, включенных друг на друга, удаленная сторона не переходит в исходное при получении сигнала "отбой" из канала TDM.

В логе​ видно, что в 6:58:27 канальное окончание начало передавать в канал сигнал "отбой". Однако в логе другой стороны​ видно, что вместо длинного сигнала (~800 мс) принимающая сторона зафиксировала короткий сигнал (150 мс) и проигнорировала его, оставшись в состоянии Connected. Отбой этой стороны произошел только в 06:58:29, когда второй участник соединения положил трубку.

@roman_zhur, подтверди, пожалуйста, что в экспериментах тикета #455 отбой одной стороны соединения действительно не приводил к переходу другой стороны в исходное.

Могу добавить, что в моих собственных экспериментах (было выполнено около 3000 вызовов) такого не происходило - удаленная сторона всегда определяла "отбой" как длинный сигнал (790 мс) и переходила в исходное.

[roman_zhur]

Да, это действительно так. Одна сторона будет в состоянии Connected до тех пор, пока сама не положит трубку.

Дополнительные логи.

1. Звонок 22@ --> 11@ (messages_ve01_1 и messages_ve02_1)
   Положил трубку 11@, подождал ~30 секунд, положил 22@.

2. Звонок 22@ --> 11@ (messages_ve01_2 и messages_ve02_2)
   Положил трубку 22@, подождал ~90 секунд, положил 11@.

Во втором случае есть еще одна странность: после того, как я положил трубку 11@, SL ve02@ перешел из состояния Idle в NumRecv и вернулся обратно в Idle. После этого SL ve01 перешел из состояния Idle в NumRecv и вернулся обратно в Idle.

[alx]

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.

[roman_zhur]

Звонок 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​.

[alx]

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.

[alx]

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", то это, наверое, еще один баг...

[roman_zhur]

Ты по-моему перепутал тикеты

Ты прав.

Вот таблица

	2100 Гц	2600 Гц	600+750 Гц
нет запрета VBD	воспроизводится	не воспроизводится	не воспроизводится
запрет VBD	воспроизводится	не воспроизводится	не воспроизводится

[roman_zhur]

Ты совершенно уверен, что при проведении эксперимента, в ходе которого был получен лог messages_ve02_VBD_1​, в настройках канального окончания SL был установлен запрет VBD? Перепроверь, пожалуйста.

Воспроизвел еще раз. В этот раз я точно уверен, что чек-бокс "запрет VBD" был установлен на обоих SL. Вот новые логи messages_ve01_2100_VBD​, messages_ve02_2100_VBD​.

[alx]

Replying to roman_zhur:

Воспроизвел еще раз. В этот раз я точно уверен, что чек-бокс "запрет VBD" был установлен. Вот новые логи messages_ve01_2100_VBD​, messages_ve02_2100_VBD​.

Печально. Значит придется разбираться еще с одним багом... Создал тикет #457.

[alx]

Тикет #457 закрыт. Возвращаюсь к данной проблеме.

Файл sip_ua для платы VE-02 с исправленным багом #457 положил в ​http://repo.adc-line.ru/misc/sip_ua
Прошу записать этот файл в плату VE-02 и повторить эксперимент с вариантом сигнализации 2100 Гц и запретом VBD. Как и раньше, интересует, воспроизведется ли баг, описанный в описании тикета.

[roman_zhur]

Проверка, как в комментарии 3.
С модицифицированным sip_ua на VE-02 баг не воспроизводится ни с одной, ни с другой стороны.
Логи messages_ve01_mod​ и messages_ve02_mod​.

[alx]

Replying to roman_zhur:

С модицифицированным sip_ua на VE-02 баг не воспроизводится ни с одной, ни с другой стороны.

Спасибо. В таком случае, я считаю, что можно считать подтвержденным влияние VBD на данную проблему.

@san, вынужден подключить тебя, так как у меня самого, кроме идеи добавить в РЭ рекомендацию запрещать VBD при использовании варианта "2100 Гц", других идей нет. Похоже, что это особенность MSP - в момент PassThru autoswitch давать ложное сообщение о том, что прием частоты прекратился, и мы с этим ничего поделать не можем... Есть ли альтернативные идеи у тебя?

[san]

Replying to alx:

@san, вынужден подключить тебя, так как у меня самого, кроме идеи добавить в РЭ рекомендацию запрещать VBD при использовании варианта "2100 Гц", других идей нет. Похоже, что это особенность MSP - в момент PassThru autoswitch давать ложное сообщение о том, что прием частоты прекратился, и мы с этим ничего поделать не можем... Есть ли альтернативные идеи у тебя?

А можно, кроме добавления в РЭ, сделать ещё так, чтобы в окне настройки платы, при выборе варианта "2100 Гц" автоматически запрещался VBD (выбирался вариант запретить и настройка дизейблилась). На мой взгляд, так меньше вероятность что пользователь увидит этот баг, а чем меньше багов, тем приятнее пользователю работать с нашей аппаратурой.

[alx]

Replying to san:

А можно, кроме добавления в РЭ, сделать ещё так, чтобы в окне настройки платы, при выборе варианта "2100 Гц" автоматически запрещался VBD (выбирался вариант запретить и настройка дизейблилась).

Конечно, можно.

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

На мой взгляд, это очень деструктивное решение (прямо скажем, диверсия). Оно чревато тем, что у пользователя просто перестанет работать связь (вдруг ему как раз необходимо обеспечить работу модемов через эту соединительную линию)! Получится, что ради устранения не очень серьезной проблемы (ну произойдет освобождение канала на несколько секунд позже, не когда первый абонент положит трубку, а когда второй - кто это вообще заметит?) мы создадим пользователям намного более серьезную проблему (вдвойне неприятную, так как все уже же работало, но в результате наших действий перестанет) - это IMHO совсем не способствует приятности работы с нашей аппаратурой. :) Поэтому такой вариант я отверг сразу.

Так как никаких других идей, несколько я понял, у тебя нет, создал ​тикет для внесения рекомендации в РЭ.