FS Calling, хотя трубка телефона положена.

[san]

В результате эксперимента #267
Одно из окончаний FS осталось в состоянии Calling, хотя трубка телефона подключенного к этому каналу была положена.
В таком состоянии окончание пребывало достаточно долго, более минуты, после поднятия трубки на телефоне и опускания обратно - окончание приняло статус Iddle.
Удалось воспроизвести два раза
эксперимент 1


эксперимент 2

[san]

приложил логи выше

[alx]

Лог первого эксперимента описанную ситуацию не подтверждает. В логе присутствует шесть случаев, когда канальное окончание FXS ts=29 получает сообщение о размыкании шлейфа, и после каждого из них вызов снимается, и канальное окончание переходит в состояние Idle. В конце лога есть еще один (седьмой?) вызов, который начинается с замыкания шлейфа, инициируется вызов, затем вызов отклоняет удаленная сторона, и канальное окончание FXS переходит из состояния Calling в Busy, что правильно. На этом лог кончается, сообщения о размыкании шлейфа канальному окончанию не приходит.

Прошу уточнить, какой именно из семи имеющихся в логе вызовов является "проблемным", в процессе которого плата, предположительно, работала неправильно.

[alx]

В конце лога второго эксперимента вижу примерно то же самое, что и с конце лога первого (см. comment:2). Просто снятий/опусканий трубки там огромное количество, я не стал изучать их все...

Резюме: логи обоих экспериментов не подтверждают описание экспериментов. Либо логи неполные (не записаны до конца или имеют место пропуски строк в логах), либо описание проблемы неточное...

[san]

Думаю что имеет смысл изучать последний вызов в логе, т.к. файл лога был получен после "скриншотов" без проведения новых вызовов

[alx]

Replying to san:

В таком состоянии окончание пребывало достаточно долго, более минуты,

Судя по этому уточнению, в обоих экспериментах "проблемным" являлся именно последний вызов, так как только он длился более минуты (3 минуты в каждом эксперименте). Но ни в одном из логов не зафиксировано последующее снятие вызова поднятием и опусканием трубки. Оба вызова были сняты сообщением DISCONNECT от удаленной стороны (стороны вызываемого абонента). Думаю, что DISCONNECT был отправлен по таймауту. После получения DISCONNECT окончание FXS перешло из состояния Calling в состояние Busy.

Саша, уточни, поэалуйста, на основании каких внешних признаков ты сделал вывод о том, что "окончание приняло статус Idle". Также уточни, пожалуйста, произошло ли это уже после того как вызов завершился, и окончание перешло из Calling в Busy, или раньше.

[alx]

Replying to alx:

Саша, уточни, пожалуйста, на основании каких внешних признаков ты сделал вывод о том, что "окончание приняло статус Idle". Также уточни, пожалуйста, произошло ли это уже после того как вызов завершился, и окончание перешло из Calling в Busy, или раньше.

Со слов Саши уточняю: поднятие и опускание трубки, после которого окончание FXS переходило в Idle, выполнялось уже после завершения снятия лога.

Предположительно причина бага в том, что при опускании трубки (размыкании шлейфа) не приходит событие CAS. Возможные причины:

• неисправность телефона (не сработал рычаг размыкателя, после повторного опускания трубки сработал);
• неисправность/баг FS-08 (не изменила состояние СУВ при размыкании шлейфа);
• баг MSP платы VE-01 (не передал сообщение об изменении СУВ);
• баг CSP (теряется сообщение уже после его получения из MSP).

[alx]

Тот факт, что описанный эффект возникает только у абонента 129 (см. также #267, #270), говорит в пользу версии о неисправности телефонного аппарата.

[alx]

Как показал новый эксперимент, во время активности вызова СУВ А равен единице (согласно показаниям в таблице коммутации веб-интерфейса). Таким образом, неисправность телефонного аппарата можно исключить. И неисправность FS-08 тоже.

[alx]

Для подтверждения/исключения бага MSP предлагается следующий эксперимент:

На плату VE-01 необходимо установить tcpdump, после чего запустить его следующим образом:

tcpdump -i eth1 -pnves0 ether[24:2]=0xb780

и воспроизвести баг. Для надежности вывод tcpdump лечше записать в файл. Вывод tcpdump должен показать все сообщения об изменении СУВ канальных окончаний.

[alx]

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

[alx]

Replying to alx:

tcpdump -i eth1 -pnves0 ether[24:2]=0xb780

Наверное даже лучше так:

tcpdump -i eth1 -pnves0 ether[24:2]=0xb780 and ether[28:2]=0x1d00

тогда будет выводиться только индикация изменения СУВ канала 30.

[san]

Возникла ещё теория, что воспроизведение бага связано с перегревом платы, проверяем...

[alx]

Эксперимент с tcpdump'ом проведен. Как показал tcpdump, сообщение о размыкании шлейфа из MSP не пришло. Следовательно, виноват либо сам MSP, "забывший" известить CSP об изменении СУВ, либо какие-то проблемы в драйвере ved (например переполнилась очередь пакетов)...

[alx]

См. также #270.

[alx]

Как показала статистика CSME_STATS, запрошенная у MSP после воспроизведения бага, счетчик пакетов, не отправленных из-за переполнения очереди, равен нулю. Думаю, переполнения очереди не возникало, и придется сделать вывод, что имеет место чистый баг MSP.

Предлагается реализовать workaround: периодически перезапрашивать состояние СУВ.

[alx]

Replying to alx:

Предлагается реализовать workaround: периодически перезапрашивать состояние СУВ.

Как показали эксперименты, функция GET_INGRESS_SIGNALING, предназначенная для запроса состояния принимаемых СУВ, не реализована в MSP (возвращает ответ 0xffad: "API is not supported"). Следовательно, реализовать предложенный workaround не представляется возможным.

Так как неполучение индикации изменения СУВ не приводит к катастрофическим отказам (например нахождение в состоянии Calling ограничено таймаутом, а в состоянии Connected соединение может быть завершено удаленным абонентом, или если местный абонент сделает дополнительное размыкание шлейфа), а также учитывая, что подобная ситуация возникает крайне редко, предлагаю оставить все как есть ©.

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