Opened 6 weeks ago
Last modified 3 weeks ago
#449 reopened баг
Канальное окончание R1.5 блокируется канал
| Reported by: | mixyil1.1 | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 2 очередь |
| Component: | VE-01 | Keywords: | R1.5 |
| Cc: |
Description
Не уверен что это баг именно платы VE-01.
Дано
плата VE-01 15 канальных окончаний №1-15 типа R1.5 направление
исходящие(IP->TDM) способ набора номера (декадно-импульсный).
Проблемма
В какой-то момент времени через одно из канальных окончаний невозможно
установить соединение для нескольких входящих вызовов подряд.
Aug 19 08:35:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: RTP monitor, ts=2, flags=0000, data=0 Aug 19 08:36:56 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0001, data=4034 Aug 19 08:37:41 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0001, data=4036 Aug 19 08:39:05 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0001, data=4040 Aug 19 08:39:05 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Seizure: CAS event, ts=2, flags=0000, data=13 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: RTP parameters, ts=2, flags=0000, data=4040 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: CAS event, ts=2, flags=0000, data=1 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4040 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4040 Aug 19 08:39:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: CAS event, ts=2, flags=0000, data=5 Aug 19 08:39:38 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0001, data=4042 Aug 19 08:39:38 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0002, data=4042 Aug 19 08:39:38 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Seizure: CAS event, ts=2, flags=0000, data=13 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: RTP parameters, ts=2, flags=0000, data=4042 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: CAS event, ts=2, flags=0000, data=1 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4042 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4042 Aug 19 08:39:42 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: CAS event, ts=2, flags=0000, data=5 Aug 19 08:40:04 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Idle: Incoming call, ts=-1, flags=0001, data=4044 Aug 19 08:40:04 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Seizure: CAS event, ts=2, flags=0000, data=13 Aug 19 08:40:08 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: RTP parameters, ts=2, flags=0000, data=4044 Aug 19 08:40:08 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:40:08 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: Statistics received, ts=2, flags=0000, data=0 Aug 19 08:40:08 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: RTP monitor, ts=2, flags=0000, data=1 Aug 19 08:40:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Dialed: CAS event, ts=2, flags=0000, data=9 Aug 19 08:40:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Answered: Tone detected, ts=2, flags=0000, data=47 Aug 19 08:40:10 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Answered: CAS event, ts=2, flags=0000, data=9 Aug 19 08:40:11 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Answered: CAS event, ts=2, flags=0000, data=1 Aug 19 08:40:11 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4044 Aug 19 08:40:11 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Call disconnected, ts=2, flags=0000, data=4044 Aug 19 08:40:11 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Tone completed, ts=2, flags=0000, data=0 Aug 19 08:40:11 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: CAS event, ts=2, flags=0000, data=1 Aug 19 08:41:55 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4046 Aug 19 08:42:17 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4048 Aug 19 08:42:17 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0002, data=4048 Aug 19 08:42:40 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4050 Aug 19 08:43:23 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4052 Aug 19 08:43:23 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4054 -----//----- Aug 19 10:27:22 sip_ua[390]: r1.5.cpp:643: ---> ts=2, state=Blocked: Incoming call, ts=-1, flags=0001, data=4336
Сразу после этого канальное окончание переходит в состояние Blocked и остается в таком
состоянии продолжительное время (до суток).
Такое поведение проявляется случайным образом (примерно раз в неделю) и не
связано с каким-то определенным канальным окончанием.
Как сейчас поступают
Когда канальное окончание после вызова остается в состоянии Blocked его удаляют
через web интерфейс блока и создают заново. "Новое" канальное окончание в
состоянии Idle и успешно устанавливает соединение для входящих вызовов.
Цитата оригинального сообщения
Допустим изначально все работает. В какой то момент времени допустим по второму
каналу входящие вызова начинают сразу же сбрасываться в занятость. Т.е. на
канале состояние Idle, абонент которому идёт попытка дозвона свободен, однако
при поступлении звонка на канал плата VE моментально вызов сбрасывается в
занятость. Следовательно любой звонящий попадающий в этот канал никуда не
дозванивается. Пока одновременно не произойдёт два и более вызовов чтобы
сработал другой канал. Через некоторое неустановленное время канал переходит в
состояние Blocked. В таком случае на него вызова не попадают а попадают на
следующий канал и все опять работает. Через примерно сутки по наблюдениям
Blocked самостоятельно сбрасывается на Idle и канал работает нормально
Attachments (5)
Change History (18)
by , 6 weeks ago
| Attachment: | config.xml added |
|---|
by , 6 weeks ago
| Attachment: | log.tar.gz added |
|---|
follow-up: 2 comment:1 by , 6 weeks ago
follow-up: 3 comment:2 by , 6 weeks ago
Replying to alx:
Сообщи потом здесь, пожалуйста, о результате.
Я имел в виду, сообщи, действительно ли от R1.5 в канал идет "контроль исходного", а из канала в R1.5 - нет (чтобы я знал, закрыть ли уже тикет или разбираться дальше). Что ответят специалисты, эксплуатирующие другую станцию, сообщать не обязательно. :)
comment:3 by , 6 weeks ago
Если все действительно так, то все вопросы следует адресовать тем, кто обслуживает удаленную станцию.
К сожалению нет специалистов, которым можно задать вопрос.
Сообщи потом здесь, пожалуйста, о результате.
Хорошо. Это займет некоторое время.
comment:4 by , 6 weeks ago
От удаленной стороны получен "контроль исходного". Канальное окончание переходит в состояние Idle. Обработка вызова завершена. Не вижу здесь ничего криминального - нормальное поведение при вызове занятого абонента.
По словам инженера вызываемый абонент в это время точно не занят. Но это, опять же, вопрос скорее к удаленной станции.
by , 6 weeks ago
by , 6 weeks ago
comment:5 by , 6 weeks ago
5 поток СЛ
6 поток VE
Если я правильно понимаю, то канальное окончание передает Занятие, СЛ - Занято/Отбой
comment:6 by , 6 weeks ago
Мне удалось воспроизвести проблему "синтетическим" тестом.
Суть проблемы состоит в том, что когда канальное окончание передает в канал кодограмму АОН, оно пере создает канал с другим типом (ComplexTone вместо VoIP). Я почти уверен (уверен на 90%), что раньше этот тип канала не работал с СУВ'ами - не передавал (в этом я уверен на 99%) и не сообщал об их изменении на приеме. Поэтому в ПЛИС я сделал специальную функцию - "заморозка СУВ" - которая включается на время передачи кодограммы (чтобы передаваемые СУВ не сбрасывались в дефолтную комбинацию - это такой костыль).
В реальности, судя по приведенному логу, линейный сигнал "занято" от удаленной стороны приходит и индицируется во время передачи кодограммы АОН! Канальное окончание такого не ожидало - оно сначала переходит в состояние Blocked и передает "контроль исходного (который не передается в канал, потому что СУВ'ы заморожены), и после окончания передачи окончание снова включает передачу "занятие" (так как оно не ожидало, что в процессе передачи АОН его состояние могло измениться) и размораживает СУВ'ы. Предполагаю, что в результате смены firmware MSP поведение изменилось - MSP начал индицировать изменение принимаемых СУВ каналами типа ComplexTone, что и привело к данной проблеме.
by , 3 weeks ago
| Attachment: | 13_03.suv.jpg added |
|---|
follow-up: 11 comment:9 by , 3 weeks ago
Ревизия прошивки платы VE-01 91, новая с исправлением 2476/sip_ua.
Поведение такое же. На картинке заблокирован 3 канал 5 поток СЛ
6 поток VE.
follow-up: 12 comment:10 by , 3 weeks ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
follow-up: 13 comment:11 by , 3 weeks ago
Replying to mixyil1.1:
Ревизия прошивки платы VE-01 91, новая с исправлением 2476/sip_ua.
Поведение такое же. На картинке заблокирован 3 канал 5 поток СЛ
6 поток VE.
Не понял смысл комментария... У тебя по этому поводу есть какой-то вопрос?
comment:12 by , 3 weeks ago
Replying to mixyil1.1:
Это я тоже не понял... Объясни, пожалуйста, почему ты переоткрыл тикет (лучше это делать сразу в том комментарии, в котором переоткрываешь тикет).
comment:13 by , 3 weeks ago
Replying to alx:
Не понял смысл комментария... У тебя по этому поводу есть какой-то вопрос?
Проблема осталась. Канал переходит в состояние Blocked. На картинке в коментарии 9 состояние СУВ в ситуации когда канал 3 в состоянии Blocked продолжительное время.
Сейчас на пате VE-01 включили логирование. Когда в следующий раз случится ситуация с блокировкой канала добавлю логи.
Replying to mixyil1.1:
Давай разберем, что здесь произошло...
Вызов 1
Пришло сообщение INVITE. В соединительную линию (СЛ) передается линейный сигнал "занятие".
Из СЛ от удаленной станции получен линейный сигнал "подтверждение занятия". Далее в СЛ передается номер вызываемого абонента.
Номер передан, активирован медиапоток.
Получен линейный сигнал "занято/отбой Б". В СЛ передается линейный сигнал "контроль исходного", вызывающему передается ответ "486 Busy here", канальное окончание переходит в состояние
Blockedи ожидает "контроль исходного" от удаленной станции.От удаленной стороны получен "контроль исходного". Канальное окончание переходит в состояние
Idle. Обработка вызова завершена. Не вижу здесь ничего криминального - нормальное поведение при вызове занятого абонента.Вызов 2
Здесь я вижу полное повторение предыдущего сценария.
Вызов 3
Пришло сообщение INVITE. В соединительную линию (СЛ) передается линейный сигнал "занятие".
Из СЛ от удаленной станции получен линейный сигнал "подтверждение занятия". Далее в СЛ передается номер вызываемого абонента.
Номер передан, активирован медиапоток.
Получен линейный сигнал "ответ".
Принят тональный сигнал 500 Гц. То есть принятый линейный сигнал "ответ" - это на самом деле запрос АОН. Далее в СЛ передается кодограмма АОН и ожидается линейный сигнал "снятие ответа".
Вместо ожидаемого сигнала "снятие твета" получен сигнал "занято/отбой Б". Канальное окончание передает линейный сигнал "контроль исходного", переходит в состояние
Blockedи ожидает "контроли исходного" от удаленной станции. Однако "контроль исходного" так и не поступает - удаленная станция продолжает передавать "занято", поэтому канальное окончание R1.5 так и остается в состоянииBlocked. Почему от удаленной станции не приходит "контроль исходного", непонятно...Все правильно - пока удаленная станция не в исходном, канальное окончание должно оставаться в состоянии
Blockedчтобы новые вызовы не принимались, пока удаленная сторона не готова к работе.Я предлагаю, когда в следующий раз возникнет подобная ситуация, посмотреть в веб-интерейсе блока, какие комбинации СУВ идут из канального окончания и из СЛ - действительно ли канальное окончание передает "контроль исходного", и идет ли "занято" из соединительной линии. Если все действительно так, то все вопросы следует адресовать тем, кто обслуживает удаленную станцию. Сообщи потом здесь, пожалуйста, о результате.
Вероятно, на удаленной станции срабатывает какой-то таймаут, и она освобождает СЛ (передает наконец линейный сигнал "контроль исходного").