Отваливаются трубки Gigaset A420, A220

[Nonen]

Добрый день.
Есть K Extra II 3.4.12 подключенным K Dect Plus и две подключенные трубки (и пара выключены в резерве).
Трубки периодически отваливаются: обе включены, но звонить с них не удается. После набора номера вызов не идет, никак не отображается, трубка переходит в режим ожидания (т.е. готовности для набора).
В разделе "Базовая станция DECT" видны одна или обе (без закономерности).

Донгл K Plus DECT подключен в активный хаб, месте с Sandisk-флешкой для журнала звонков и резервной линией интернет через usb-модем.

В прикрепленном логе три попытки совершить звонок через А420 гигасет, все провальные (но он видится в в разделе "Базовая станция DECT").
Совершены примерно в Sep 14 16:30 -16:33.

Настораживает еще то, что видны переодические сообщения в логе о переинициализации донгла и перерегистрации телефонной линии (с данными от провайдера Smart Telecom).

Перезагрузка роутера решает все проблемы.

Что нужно исправить и поменять?

 

Edited September 14, 2020 by des
Удалил селф тест - там может быть персональная информация

[des]

@Nonen Изменения настроек телефонии через веб интерфейс приводят к перезагрузке сервиса телефонии. После перезагрузки сервис пытается зарегистрировать учетные записи у провайдера, и провайдер какое-то время может не отвечать. Если в такой период сделать звонок - звонок не пройдет.

В логе вижу неуспешные исходящие вызовы:

Sep 12 16:10:36 nvox: Outgoing call from HS Gigaset_A220 to *** was rejected. Lines were unavailable because of SIP registration failure.

Sep 12 17:49:20 nvox: Line SmartTelecom: outgoing call from HS Gigaset_A420 to *** was incomplete, response 503 Service Unavailable

Sep 12 17:50:54 nvox: Line SmartTelecom: outgoing call from HS Gigaset_A420 to *** was rejected by callee.

Судя по логу, проблемы на сервере, если это - те самые звонки, о которых Вы писали.

Получается следющее:

1. Если Вы изменяли настройки телефонии и сразу пытались звонить - звонок мог не пройти потому что телефония в этот момент перезагружалась, потому трубка искала донгл, линии регистрировались... Восстановление работоспособности может занять до минуты.
2. Если проблема связи с сервером, или сервер отбил звонок - это будет видно в логе.

В 16:32 как раз перезагружалась телефония - соответственно, трубка не видела донгл и никуда не могла позвонить. Причина перезагрузка - включение отладочного лога:

Sep 14 16:31:59 ndm: Core::Debug: system debug enabled.

 

Нужна следующая информация:

• Наблюдается ли проблема, если не трогать веб интерфейс роутера
• Со всех ли трубками не удается звонить, или это только для какой-то одной модели
• Видно ли модель трубки в веб интерфейсе, или вместо нее показан десятизначный номер (IPUI)

[Nonen]

3 hours ago, des said:

@Nonen

В 16:32 как раз перезагружалась телефония - соответственно, трубка не видела донгл и никуда не могла позвонить. Причина перезагрузка - включение отладочного лога:

Sep 14 16:31:59 ndm: Core::Debug: system debug enabled.

  Нужна следующая информация:

• Наблюдается ли проблема, если не трогать веб интерфейс роутера
• Со всех ли трубками не удается звонить, или это только для какой-то одной модели
• Видно ли модель трубки в веб интерфейсе, или вместо нее показан десятизначный номер (IPUI)

Спасибо за оперативный ответ.

"Судя по логу, проблемы на сервере, если это - те самые звонки, о которых Вы писали."
Нет, это я на выходных заново настроил телефонию, т.к. при обновлении на последнюю версию прошивки (перед тем как создать тикет) слетели все настройки телефонии.

Получается, включение отладочного лога перезапускает сервисы телефонии в роутере?

• "Наблюдается ли проблема, если не трогать веб интерфейс роутера"
  Да, периодически звонить нельзя, но на трубках нет индикации потери базы.
  
  Еще грешу на уставшие аккумы, новые оттренирую и поставлю на днях. После этого еще раз всё протестирую.
   
• Со всех ли трубками не удается звонить, или это только для какой-то одной модели
  Обе трубки гигасет, одна модели А220, вторая А420. (Панасоники после настройки не задействованы).
   
• Видно ли модель трубки в веб интерфейсе, или вместо нее показан десятизначный номер (IPUI)
  Нет, ни одну не видно по названию (я их вручную прописал, чтоб различать). Обе отображаются по IPUI.
  (Думал, что не отображается из-за старой версии, после обновления до последней 3.4.12 - тоже).

[des]

12 hours ago, Nonen said:

при обновлении на последнюю версию прошивки слетели все настройки телефонии

Спасибо, скажу руководителю проекта. Так не должно быть.

12 hours ago, Nonen said:

Получается, включение отладочного лога перезапускает сервисы телефонии в роутере?

Включение отладки перезапускает почти все сервисы роутера.

12 hours ago, Nonen said:

Еще грешу на уставшие аккумы, новые оттренирую и поставлю на днях.

Вряд ли это оно.

12 hours ago, Nonen said:

Да, периодически звонить нельзя, но на трубках нет индикации потери базы.

Попробуйте сразу же позвонить второй раз с той же трубки.

Какое-то время назад ввели опрос трубок, чтобы показывать в вебе, какая трубка подключена. Для этого используется невидимый сервисный звонок, и он может конфликтовать с нормальными звонками. Если это оно - то второй звонок пройдет нормально, и проблема будет проявляться абсолютно случайным образом. Чуть позже сегодня узнаю, как его отключить через веб интерыейс или CLI и отпишу.

12 hours ago, Nonen said:

Нет, ни одну не видно по названию (я их вручную прописал, чтоб различать). Обе отображаются по IPUI.

Напишите, пожалуйста, здесь IPUI и модели (у какой  модели какой IPUI).

Там примерно такая ситуация. Есть комитет DECT, который раздает производителям IPUI номера пачками. Производители покупают пачку номеров и выпускают какую-то модель трубок с этими номерами (иногда - пару моделей из одной пачки). Открытых данных, какие номера соответствуют какой модели, нет. С другой стороны - трубки тестируются с родными базами, и ведут себя по-разному. У нас с десяток хаков (изменений нашего поведения) для того, чтобы разные трубки с нами не глючили. И некоторым не помогло. Но знать, какая модель трубки зарегистрирована и какие хаки к ней применять, мы можем только если кто-то уже раньше нам прислал IPUI из этой пачки номеров и сказал, что это за трубка.

В принципе, с Гигасетами в плане совместимости все хорошо, но если скажете IPUI - в следующей версии они будут показывать имя звонящего вместе с номером (смогли такое сделать для Гигасетов, но чтобы применить - надо знать, что это - Гигасет).

[Nonen]

Добрый день.
Пока лишь поделюсь  IPUI для Гигасетов:
026D458CE6 Gigaset A420
0227A6BFAB Gigaset A220

При обновлении с версии 2.11 до 3.4.12 отключились все сервисы телефонии, поэтому их потребовалось заново настроить. Впрочем, планировал перед отправкой тикета проделать это сам.

Проверю на неделе обе трубки заново, уже на новых батарейках.

[des]

@Nonen Трубки добавил, спасибо. В следующей версии модели должны распознаться.

По поводу опроса состояния трубки сервисным звонком - это не оно, так как опрос делается только для известных моделей, а Ваши трубки не определялись.

[Nonen]

2 hours ago, des said:

@Nonen Трубки добавил, спасибо. В следующей версии модели должны распознаться.

По поводу опроса состояния трубки сервисным звонком - это не оно, так как опрос делается только для известных моделей, а Ваши трубки не определялись.

Спасибо.
Нужно скачать какой-то новый тестовый билд, чтоб залить его себе с этими новыми IPUI?

[des]

@NonenНет, они будут в следующей сборке прошивки роутера (3.4 и 3,5).

Но проблема со звонками не в этом.

[Nonen]

Добрый день.
Аккумуляторы заменил на новые, пока остались подозрения на нарушение регистрации только у 420 гигасета.
У 220 модели всё нормально.

Теперь нужно решить основную проблему со связью: при входящих звонках они обрываются через 20-30 секунд. И часто бывает, что нас не слышно вызывающей стороне. Тогда никто 20-30 секунд не ждет, конечно.
Предполагаю, что второе связано с несогласованностью кодеков.

Подскажите, пожалуйста, что нужно сделать (и какие настройки проверить) для
1) "30 секундной длительности" и
2) "нас не слышно при входящем".

[des]

@Nonen Надо дамп (UDP) траффика такого звонка

https://help.keenetic.com/hc/ru/articles/360000401420-Захват-сетевых-пакетов

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

Публикуйте их на форуме скрытым сообщением, если не хотите, чтобы файлы были общедоступны.

 

[Nonen]

3 minutes ago, des said:

@Nonen Надо дамп (UDP) траффика такого звонка

 

Будет достаточно только UDP указать? А сигнальные данные попадут или не нужны?

Отладочный лог - это тот, что после включение отладки формируется, верно?

[des]

@NonenОбычно используется UDP. Но это зависит от настроек учетки.

10 minutes ago, Nonen said:

Отладочный лог - это тот, что после включение отладки формируется, верно?

Да.

[des]

@NonenСпасибо. Оба селф-теста начинаются в 16:12, то есть, в них нет проблемных звонков.

Звонки в 16:13 с кодами ошибки 503 и 603 - это были какие-то проблемы на сервере провайдера (сервер отвечает "603 Declined" и "503 Service Unavailable").

Дампы передал начальнику, он посмотрит в понедельник.

 

[des]

@Nonen"серые" трубки - это телефония перезагрузилась и еще не знает, какие трубки включены. Если с трубки позвонить - она должна позеленеть.

[Nonen]

5 hours ago, des said:

@NonenСпасибо. Оба селф-теста начинаются в 16:12, то есть, в них нет проблемных звонков.

Странно это, как раз остановил Режим отладки примерно в 16.12 (после последнего проблемного звонка в 16.11), начатый в 12 часов. И сохранил self-test из раздела Общих настроек. Всё по инструкции: сначала Режим вкл, затем вкл Захват UDP, после звонка в обратном порядке. Верно?

Звонки в 16:13 с кодами ошибки 503 и 603 - это были какие-то проблемы на сервере провайдера (сервер отвечает "603 Declined" и "503 Service Unavailable").
Этот момент учту и предъявлю провайдеру для прояснения, спасибо.

"серые" трубки - это телефония перезагрузилась и еще не знает, какие трубки включены. Если с трубки позвонить - она должна позеленеть.
Ок, значит это нормально.

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

Upd.: добавил аттачем проверочные селф-тесты от 13.02 - они столько же "весят", что и последние (от 16.12). Не понимаю.

 

Edited September 25, 2020 by Nonen

[des]

@Nonen В дампах как раз входящий звук хороший, исходящий - с перерывами. Значит, проблема на стороне роутера. Есть следующие предположения:

1. Посмотрите загрузку процессора. Если высокая - какие-то системные сервисы могут забирать весь процессор, и телефония не успевает передать звук.
2. Хаб, в который включен донгл, может глючить. Если он собирает пакеты в пачку, а затем передает их в месте - часть голосовых пакетов может не влезть в буфер донгла, и они будут потеряны. Маловероятно, но попробуйте перезагрузить хаб.
3. В операционной системе могут быть блокировки, останавливающие USB шину на длительное время. Это не сильно проявится в загрузке процессора, но голос будет с перерывами. Здесь, например, может быть зависимость от того, открыта ли основная страница веб интерфейса или запущена ли какая-то служба роутера.

В логе некоторые команды обрабатываются по 6 секунд - очень похоже на блокировки.

Итого:

а) посмотрите загрузку процессора с отключенной телефонией, со включенной телефонией и во время звонка

б) закройте веб интерфейс на всех компьютерах и все подключенные мобильные приложения, и проверьте качество звука в звонках

ПС селф тесты могут весить одинаково если в роутере выделен фиксированный объем памяти под запись лога. Это было бы логично. У Вас в логе очень много сообщений от nimproxy и ndnproxy, поэтому в него помещается короткий интервал времени.

[Nonen]

24 minutes ago, des said:

@Nonen В дампах как раз входящий звук хороший, исходящий - с перерывами. Значит, проблема на стороне роутера. Есть следующие предположения:

1. Посмотрите загрузку процессора. Если высокая - какие-то системные сервисы могут забирать весь процессор, и телефония не успевает передать звук.
2. Хаб, в который включен донгл, может глючить. Если он собирает пакеты в пачку, а затем передает их в месте - часть голосовых пакетов может не влезть в буфер донгла, и они будут потеряны. Маловероятно, но попробуйте перезагрузить хаб.
3. В операционной системе могут быть блокировки, останавливающие USB шину на длительное время. Это не сильно проявится в загрузке процессора, но голос будет с перерывами. Здесь, например, может быть зависимость от того, открыта ли основная страница веб интерфейса или запущена ли какая-то служба роутера.

В логе некоторые команды обрабатываются по 6 секунд - очень похоже на блокировки.

Итого:

а) посмотрите загрузку процессора с отключенной телефонией, со включенной телефонией и во время звонка

Уже проверил в простое и при звонках ,т.е. с телефонией (без неё офис не оставить и именно поэтому стоит Кинетик). Процессор 3-7% загруженности, память 50-60-70%. При звонках процессор загружен чуть больше, но в рамках погрешности наблюдений.

б) закройте веб интерфейс на всех компьютерах и все подключенные мобильные приложения, и проверьте качество звука в звонках

Ок, попробую. При тестах интерфейс был открыт на одной странице, где Запустить/Остановить захват пакетов.

ПС селф тесты могут весить одинаково если в роутере выделен фиксированный объем памяти под запись лога. Это было бы логично. У Вас в логе очень много сообщений от nimproxy и ndnproxy, поэтому в него помещается короткий интервал времени.

Есть ли какой-либо проверенный юсб-хаб, проверенный в работе и без замечаний?
Кстати, а подключенный 4G-модем может на это влиять? На какой-то предыд.прошивке было такое: там служба проверки соединения периодически его опрашивала и в логах было похоже на переинициализацию всего хаба (отвал и определение всего подключенного оборудования).

 

[des]

@Nonen чтобы убедиться, что не хаб, подключите донгл в роутер напрямую. Переживет какое-то время без истории звонков.

Если это поможет - значит, дело в хабе либо программах, обслуживающих другие устройства в хабе.

[des]

@ndmпохоже на блокировки в ядре

[Nonen]

1 hour ago, des said:

@Nonen чтобы убедиться, что не хаб, подключите донгл в роутер напрямую. Переживет какое-то время без истории звонков.

Если это поможет - значит, дело в хабе либо программах, обслуживающих другие устройства в хабе.

Хорошо, протестирую без хаба и отпишусь.

[des]

@NonenВообще - исключительно странно, что есть зависимость от того, с каким провайдером звонок. Так как, судя по дампам, проблема у нас в операционной системе, и не должна зависеть от сервера телефонии.

[Nonen]

2 minutes ago, des said:

@NonenВообще - исключительно странно, что есть зависимость от того, с каким провайдером звонок. Так как, судя по дампам, проблема у нас в операционной системе, и не должна зависеть от сервера телефонии.

Это пока рабочая гипотеза, т.к. нет четкого разграничения на "плохие" и "хорошие" звонки. Звонишь с мобильного - вроде норм, на мобильные - тоже. На некоторые городские  тоже норм  (они же не все "медью" приземляются). Нашел несколько таксофонов и тестировали на них. Тоже не 100% гарантия, что они медные, но у них слышен импульсный набор номера при вызове.

[Nonen]

Дополню последними наблюдениями. Прошло три дня работы с напрямую воткнутым донглом: пока все нормально.
Нужно еще неделю+ потестировать, т.к. сотрудники из-за нестабильности звонков почти перестали пользоваться офисной телефонией.
Если будет всё в порядке, значит потребуется подобрать новый хаб.
Есть какие-либо рекомендации по ним?
Или просто единичные примеры успешной работы конкретных моделей хабов?

[des]

@Nonen Вот с этим хабом http://orico-russia.ru/hub/orico-m3h4-sv работает очень стабильно. Вообще, хабы пока серийно не тестировали - вероятно, когда будем выпускать версию с поддержкой нескольких донглов, станет актуальным сделать список рекомендуемых хабов.

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

[Nonen]

3 hours ago, des said:

@Nonen Вот с этим хабом http://orico-russia.ru/hub/orico-m3h4-sv работает очень стабильно. Вообще, хабы пока серийно не тестировали - вероятно, когда будем выпускать версию с поддержкой нескольких донглов, станет актуальным сделать список рекомендуемых хабов.

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

Добрый день.
Как вижу, этот Орико без доп.питания и для 4G-модема не подойдет?
Покупал SmartBuy SBHA-6000-K Black  с блоком питания в комплекте (он юсб3.0, т.к. других активных и не ноунейм не было.). Флешка самая типичная SANDISK Cruzer Fit 16ГБ, USB2.0

[des]

@Nonen зависит от потребления модема.

K+DECT с четырьмя трубками в разговорном режиме потребляет до 170 мА. Флешка USB 2.0 при записи может потребляеть около 150 мА. Потребление USB-хаба около 70 мА. Максимальный ток нагрузки при котором напряжение на USB-порте падает не ниже 5 В составляет 1 A.
При подключении K+DECT и флешки через хаб останется примерно 600 мА для питания модема.

[Nonen]

Добрый день.
После месяца тестов с разным оборудованием имеем:
- донгл K+DECT напрямую в К работает без нареканий,
- K+DECT через изначальный хаб usb3.0  SmartBuy SBHA-6000-K нормально не работает, даже оставленный единственным устройством в хабе,
- K+DECT через хаб ORI-H7013-U2-10-BK также нормально не работает, даже оставленный единственным устройством в хабе.

Во втором и третьем случае пропадание собеседников, прерывания и неожиданные прекращения разговора.
Пока остались на первом варианте, без резервного интернет-канала. Он был через 4G-LTE модем Huawei E3372 с безлимитным МТСом.

Вопросы:
а) на своем хабе Орико orico-m3h4-sv вы тестировали K+DECT и какой-либо 3G\4G-модем одновременно в течение 3-5 дней?
 

On 10/6/2020 at 5:15 PM, des said:

@Nonen зависит от потребления модема.

При подключении K+DECT и флешки через хаб останется примерно 600 мА для питания модема.

б) как понимаю в роутере K Extra II порт юсб выдает 1А вместо 500мА по стандарту usb2.0?
в) как заполучить работоспособное решение с одновременным K+DECT и 4G-модемом?