Opened 2 days ago
Closed 24 hours ago
#455 closed баг (fixed)
Баг с состоянием КО SL
| Reported by: | roman_zhur | Owned by: | alx |
|---|---|---|---|
| Priority: | высокий | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description (last modified by )
После звонка канальное окончание SL не выходит из состояния "Blocked", хотя ожидался переход в состояние "Idle".
В одном блоке 3U одна плата VE-01, одна плата VE-02, одна плата FS-08, к которой подключены два аналоговых телефона.
На плате VE-01 создано КО FXS с URI 11@IP_VE-01 и КО SL с URI ve01@IP_VE-01. На SL вариант сигнализации 2100 Гц.
На плате VE-02 создано КО FXS с URI 22@IP_VE-02 и КО SL с URI ve02@IP_VE-02. На SL вариант сигнализации 2100 Гц.
КО SL скоммутированы через TDM.
Эксперимент:
- звоним с первого телефона (11) на второй (22), сигнализация и КПВ есть;
- телефон 22 звонит, поднимаем трубку;
- голос передается в обе стороны;
- кладем трубку первого телефона (с которого звонили);
- кладем трубку второго телефона.
После этого КО SL на VE-01 (с которого звонили) не переходит из состояния "Blocked".
версия ПО:
VE-01 - 91
VE-02 - 55
Attachments (10)
Change History (23)
by , 2 days ago
| Attachment: | messages_VE-01 added |
|---|
by , 2 days ago
| Attachment: | messages_VE-02 added |
|---|
by , 2 days ago
| Attachment: | config-export-VE-01.xml added |
|---|
by , 2 days ago
| Attachment: | config-export-VE-02.xml added |
|---|
comment:1 by , 2 days ago
| Description: | modified (diff) |
|---|
comment:3 by , 29 hours ago
У меня не получается воспроизвести баг. Выполняю следующий сценарий:
- Вызов канального окончания SL.
- Удаленное окончание SL формирует вызов в сеть IP.
- Вызываемый дает ответ.
- Пауза 5 секунд.
- Вызывающий передает BYE канальному окончанию SL.
- Пауза 2 секунды.
Описанный выше сценарий повторил 3000 раз, канальное окончание в состоянии Blocked так и не зависло.
follow-up: 5 comment:4 by , 29 hours ago
В виду отсутствия малейших предположений о причине неприхода индикации от MSP не вижу иного выхода кроме как применить "костыль", борющийся не с причиной, а со следствием. Перед передачей в канал TDM сигнала "отбой" канальное окончание запускает таймер на 5 секунд. Если в течение этого времени индикация "Tone Completed" из MSP не приходит, то канальное окончание повторно передает сигнал "отбой". Предполагаю, что повторная передача сигнала завершится приходом сообщения "Tone Completed". Потому что если эта индикация вообще перестанет приходить, то канальное окончание будет вообще неработоспособно, и тогда хорошо и правильно, что оно останется в состоянии Blocked. Также перед отправкой сигнала "отбой" выполняется безусловное пересоздание канала в MSP.
Модифицированный sip_ua для VE-01 лежит в http://repo.adc-line.ru/misc/sip_ua. Прошу записать его в плату VE-01, воспроизвести проблему и подтвердить, что через 5 секунд после повторной передачи "отбой" канальное окончание действиетльно перейдет в исходное.
comment:5 by , 29 hours ago
Replying to alx:
Прошу записать его в плату VE-01, воспроизвести проблему и подтвердить, что через 5 секунд после повторной передачи "отбой" канальное окончание действиетльно перейдет в исходное.
И желательно лог этого события из VE-01 приложить к тикету - я бы посмотрел...
follow-up: 7 comment:6 by , 28 hours ago
Сейчас воспроизвел баг у себя программно: посылаем вызов и отвечаем через СУВы. Звонок 22@ --> 11@.
Баг воспроизводится. В логах попытался воспроизвести баг таким образом.
Записал модифицированный sip_ua на VE-01, на VE-02 sip_ua не трогал.
С новым sip_ua баг не воспроизводится.
Логи с "_old" со старым sip_ua на VE-01, логи с "_new" после замены sip_ua.
by , 28 hours ago
| Attachment: | messages_ve01_old added |
|---|
by , 28 hours ago
| Attachment: | messages_ve02_old added |
|---|
by , 28 hours ago
| Attachment: | messages_ve01_new added |
|---|
by , 28 hours ago
| Attachment: | messages_ve02_new added |
|---|
follow-up: 8 comment:7 by , 28 hours ago
Replying to roman_zhur:
Сейчас воспроизвел баг у себя программно
С новым sip_ua баг не воспроизводится.
Вижу здесь явное противоречие... Если ты воспроизвел баг, значит он воспроизводится. А если не воспроизводится, значит ты его не воспроизвел... По-моему так. (с) Винни Пух :)
follow-up: 9 comment:8 by , 28 hours ago
поправил комментарий.
я воспроизвел баг новым способом, потом заменил sip_ua, после замены баг не воспроизводится.
comment:9 by , 27 hours ago
Replying to roman_zhur:
потом заменил sip_ua, после замены баг не воспроизводится.
Как странно... Это неожиданный для меня результат...
Единственное предположение - на воспроизведение могло повлиять безусловное пересоздание канала перед посылкой "отбой". Убрал безусловное пересоздание соединения, но оставил таймер. Обновил файл. Попробуй воспроизвести в таком варианте...
by , 27 hours ago
| Attachment: | messages_ve01 added |
|---|
by , 27 hours ago
| Attachment: | messages_ve02 added |
|---|
comment:11 by , 25 hours ago
Replying to roman_zhur:
С новым sip_ua баг так же не воспроизводится.
В таком случае, я думаю, что что-то "сломалось" в твоем методе. Запуск таймера перед посылкой сигнала "отбой" никак не мог повлиять на работу MSP и, соответственно, воспроизводимость бага...
comment:12 by , 24 hours ago
Replying to roman_zhur:
С новым sip_ua баг так же не воспроизводится.
Уточни, пожалуйста, как именно ты определяешь, воспроизвелся баг или нет?
Я смотрю приложенный файл messages_ve01 и вижу там следующее:
May 14 08:05:39 sip_ua[391]: sl.cpp:208: ---> ts=2, state=Connected: Call disconnected, ts=2, flags=0000, data=1 ... May 14 08:06:15 sip_ua[391]: sl.cpp:208: ---> ts=2, state=Blocked: Tone completed, ts=2, flags=0000, data=5
Обрати внимание на state=...... Здесь видно, что в 08:05:39 канальное окончание получило отбой. Как мы знаем из его описания, при этом оно переходит в состояние Blocked и передает сигнал "отбой". По окончании передачи канальное окончание должно получить сообщение "Tone completed" и перейти в исходное. Из этого лога видно, что сообщение "Tone completed" было получено в 08:06:15, то есть через 6 (шесть!) секунд после получения отбоя от вызывающей стороны. И на этот момент канальное окончание все еще находится в состоянии Blocked. А мы знаем, что передача сигнала "отбой" длится 800 мс.
Почему же ты говоришь, что баг не воспроизводится? Разве вот это вот описанное выше не похоже на наш баг? Ты разве не заметил, что после отбоя вызывающего канальное окончание "залипло" в состоянии Blocked на 6 секунд (то есть до срабатывания таймаута - напоминаю, что я установил таймер на 5 секунд, и еще одна секунда - это повторная передача сигнала "отбой")?
Сравни это с логом messages_ve01_new, когда баг действительно не воспроизвелся:
May 14 07:22:35 sip_ua[421]: sl.cpp:206: ---> ts=2, state=Connected: Call disconnected, ts=2, flags=0000, data=9 May 14 07:22:36 sip_ua[421]: sl.cpp:206: ---> ts=2, state=Blocked: Tone completed, ts=2, flags=0000, data=0
А вот что видела удаленная сторона:
May 14 08:05:39 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=28 ... May 14 08:05:40 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=255 ... May 14 08:05:44 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Idle: Tone detected, ts=2, flags=0000, data=28 ... May 14 08:05:45 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Idle: Tone detected, ts=2, flags=0000, data=255
Здесь "data=28" означает, что детектирован сигнал частотой 2100 Гц, а "data=255" означает, что сигнал прекратился. Две посылки с интервалом 5 секунд. При этом сообщение "Tone completed" на вызывающей стороне только одно. По-моему вполне ясно, что произошло - после первой посылки "отбой" сообщение "Tone completed" не пришло. Через 5 секунд работал таймаут, по которому "отбой" был послан второй раз, и на этот раз сообщение "Tone completed" пришло (на что я изначально и рассчитывал).
По-моему можно считать, что ситуация была успешно воспроизведена. Оснований для этого вполне достаточно. "Костыль", который был применен, работает. Ну и пересоздание канала я верну обратно, раз уж по счастливому стечению обстоятельств было обнаружено, что оно само по себе уже помогает.
Очень странная ситуация...
Как должно быть:
Когда канальное окончание SL получает BYE со стороны IP, оно переходит в состояние
Blockedи посылает в канал TDM тональный сигнал. Тональный сигнал в канал генерирует MSP. Для этого CSP посылает в MSP команду примерно такого содержания: "генерируй в канал тональный сигнал частотой 2100 Гц и уровнем -10 dBm в течение 800 мс". MSP выполняет команду (генерирует сигнал), и после окончания генерации (через 800 мс) передает в CSP сообщение "Tone Completed". Получив сообщение "Tone Completed", канальное окончание SL переходит в исходное (Idle) состояние.Что мы видим в данном случае:
Канальное окончание SL получило BYE со стороны IP, передало команду генерировать "отбой" в канал (мы это видим по логу с противоположного конца канала) и перешло в состояние
Blocked. Но вот сообщения "Tone Completed" из MSP, судя по приложенному логу, почему-то не пришло... В результате канальное окончание так и осталось в состоянииBlocked.По-моему это очевидный баг MSP. Я такое вижу впервые, и что с этим можно сделать, я пока не представляю...