Функциональность Keenetic DECT

[krass]

35 минут назад, Joe D сказал:

Что то я чуть не поседел пока ВАТС Билайна настраивал и местами не понятно - глючит роутер или сам билайн..

Но одно знаю точно, в логе видно:
Фев 28 16:49:08 ndm
Service: "Nvox": unexpectedly stopped.

Так здесь наверное тоже нужно создать тему с этой проблемой и приложить лог/селфтест (скрытым постом)...

[Joe]

 

7 часов назад, krass сказал:

Так здесь наверное тоже нужно создать тему с этой проблемой и приложить лог/селфтест (скрытым постом)...

надеюсь у разработчиков все таки есть доступ к тикетам) там селфтест приложен.

если коротко вопроса 4:

1. Прерывается исходящий звонок с сипа через атс Билайн, спустя 30 сек разговора. ТП Билайна сказали что кинетик заваливает их PRACKами, и получает бан.. предложили отключить. Возможно это?

2. Часть исходящих вызовов тупо не получается совершить, в логе 480 Temporally unavailable. - это похоже косяк на стороне ВАТС. Тут же проблема перевода - звонок исходящий а в журнале кинетика пишется как входящий.

3. При включении режима отладки перезапускается весь дект и соединения на роутере. Так должно быть?

4. После ряда включений режима отладки и перерегистраци начинает падать сервис nvox.

Это все на новой виве с модулем, пока ощущения стабильной работы не вижу.

[des]

2 hours ago, Joe D said:

3. При включении режима отладки перезапускается весь дект и соединения на роутере. Так должно быть?

Да.

[des]

@Joe D Сделайте, пожалуйста, дамп трафика UDP на внешнем интерфейсе роутера во время проблем со звонками.
Статья о том, как захватывать трафик: https://help.keenetic.com/hc/ru/articles/360000401420

[des]

2 hours ago, Joe D said:

4. После ряда включений режима отладки и перерегистраци начинает падать сервис nvox.

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

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

[Joe]

Опять проблемы с DECT..

Кинетик потерял регистрацию и не может сам ее вернуть, практически сутки - пока я не заиметил.

В вебе пишет Ошибка BAD SIP PROXY DOMAIN NAME.

в логах каждую минуту

Mar  3 17:52:33 nvox: 17:52:33.807    pjsua_acc.c  .Unable to create/send REGISTER: gethostbyname() has returned error (PJ_ERESOLVE) [status=70018] 

Сип прокси и сервер везде ip.beeline.ru - я не верю что с публичным доменом провайдера какие то проблемы.

Руками сделал вкл\выкл регистрации из веб интерфейса - все мгновенно заработало.

Почему кинетик не может сам восстановить регистрацию?

Уже пожалел что положился на решение Keenetic DECT, стабильной работы просто нет.

Изменено 4 марта, 2020 пользователем Joe D

[des]

@Joe D Проблема с DNS, либо запорчены данные в памяти. Мы такого за 5 лет разработки ни разу не видели.

Захватите, пожалуйста, дамп трафика при отваливающемся исходящем вызове.

Сейчас готовим команду CLI для отключения 100rel - это может помочь с Билайн. Но чтобы нормально проанализировать проблему - нужен дамп.

[Joe]

capture-GigabitEthernet1-Mar 4 15-55-49.pcapng Дамп

[Joe]

Это дамп обычного обмена, когда проблем нет. Пока проблема не воспроизводится
Лог звонков в роутере.



 

[des]

@Joe D Дамп нужен в ситуации, когда есть проблема, чтобы разобраться, кто в чем виноват (кто ведет себя не в соответствии со стандартом).

Если провайдер у себя перенастроил оборудование, и проблема пропала - хорошо.

[Joe]

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

[des]

@Joe DСпасибо! Во вторник будем разгребать.

[Joe]

Поддержка билайна ответила:

Произвели проверку на нашей стороне, по информации от эксплуатации:

 После проключения вызова 200 OK -> ACK от Вас  приходят несколько сообщений PRACK. Но соединение уже состоялось. Зачем идут PRACK-и?

BYE приходит со стороны Вашего оборудования. Видимо по какому то таймауту.

Изменено 9 марта, 2020 пользователем Joe D

[des]

@Joe D А они не сказали, зачем несколько раз подряд присылают 183, и зачем после 183 присылают 180? PRACK - это ответы на 180 и 183, которыми нас засыпает сервер. Детальнее будем разбираться в рабочий день.

[Joe]

Только что, des сказал:

@Joe D А они не сказали, зачем несколько раз подряд присылают 183, и зачем после 183 присылают 180? PRACK - это ответы на 180 и 183, которыми нас засыпает сервер. Детальнее будем разбираться в рабочий день.

Нет не сказали, но вы эти вопросы не обозначивали, я бы их задал без проблем)
Может быть это связано с работой UDP, типа пакет не долетел ловите еще один?

Моделировал поведение на софтовой звонилке Phonerlite - она также как и кинетик генерирует много PRACK после соединения, но BYE не отправляет, т.е. звонок не рвется.

Обмен phonerlite

Скрытый текст

 

Разработчик программы на вопрос про множественные PRACK ответил: That are retransmissions

[des]

@Joe D Я не обозначал вопросы так как:

1. Не было дампа, а с учетом количества 180 и 183 от сервера в отладочном логе сущий адъ без поллитра неразгребаемый.

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

[KorDen]

1 час назад, des сказал:

зачем несколько раз подряд присылают 183, и зачем после 183 присылают 180?

Предполагаю, у них SBC проксирует PBX, PBX проксирует софтсвич, софтсвич проксирует провайдерский транк, и так далее... Каждый вначале дает свое SDP а затем заменяет на то что прилетело дальше по цепочке, или что-то в этом роде. Там и 180 вон с SDP летит.

Может воспроизводиться при звонках на определенные нумерации.

Еще вспомнилось - 183+180 бывают при переходах SIP-ОКС7 на некоторых железках.

Изменено 9 марта, 2020 пользователем KorDen

[des]

@Joe D Судя по дампу:

1. Множественные 180 и 183, вероятно, приходят от нескольких прокси, через которые идет звонок между роутером и сервером. Каждый прокси присылает свой 180 и 183. И на каждый мы должны ответить PRACK в соответствии со стандартом (как написал выше @KorDen).

2. В конце мы отсылаем несколько PRACK потому, что сервер не подтвеждает получение последнего PRACK сообщением 200 ОК.

3. Вероятно, звонок сбрасывается по таймауту так как сервер не отвечает 200 ОК на PRACK, и роутер считает, что сервер недоступен. Попробуйте поставить последнюю прошивку 3.4 Alpha 6 и ввести команду CLI dect sip-common 100rel disable. Эта команда (если нормально сработает) должна отключить на нашей стороне поддержку стандарта 100rel, который заведует отсылкой PRACK. Возможно, после этого проблемы исчезнут.

4. Я сейчас почитаю собственно стандарт 100rel и попробую аргументировать поведение нашего приложения (если еще будете общаться с поддержкой Билайн).

[des]

@Joe D Итак, вот стандарт, определяющий использование PRACK https://tools.ietf.org/html/rfc3262

   The UAS MAY send a final response to the initial request before
   having received PRACKs for all unacknowledged reliable provisional
   responses, unless the final response is 2xx and any of the
   unacknowledged reliable provisional responses contained a session
   description.  In that case, it MUST NOT send a final response until
   those provisional responses are acknowledged.  If the UAS does send a
   final response when reliable responses are still unacknowledged, it
   SHOULD NOT continue to retransmit the unacknowledged reliable
   provisional responses, but it MUST be prepared to process PRACK
   requests for those outstanding responses.  A UAS MUST NOT send new
   reliable provisional responses (as opposed to retransmissions of
   unacknowledged ones) after sending a final response to a request.

Тут написано, что после того, как сервер ответил 200 ОК на INVITE (сервер принял звонок), он должен отвечать на те PRACK, которые клиент посылает в ответ на более ранние сообщения от сервера.

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

Здесь пишут, что клиент ДОЛЖЕН отвечать PRACK на каждое сообщение 180 или 183 от сервера.

   If a PRACK request is received by the UA core that does not match any
   unacknowledged reliable provisional response, the UAS MUST respond to
   the PRACK with a 481 response.  If the PRACK does match an
   unacknowledged reliable provisional response, it MUST be responded to
   with a 2xx response.  The UAS can be certain at this point that the
   provisional response has been received in order.  It SHOULD cease
   retransmissions of the reliable provisional response, and MUST remove
   it from the list of unacknowledged provisional responses.

Тут - что сервер ДОЛЖЕН отвечать на все PRACK - либо 200 если он знает, что это за PRACK, либо 481, если не знает.

 

Что видно в дампе:

В 14.036275 пришел 180 Ringing. В ответ на него отправили PRACK (CSeq: 2048) в 14,373892. Ответа на этот PRACK от сервера нет. Поэтому мы перепосылаем его еще несколько раз с тем же CSeq: 2048. Через 32 секунды (64*T1, The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions.) не получив ответа мы завершаем сессии в соответствии со стандартом SIP https://tools.ietf.org/html/rfc3261#section-17

   The "Trying" state is entered when the TU initiates a new client
   transaction with a request.  When entering this state, the client
   transaction SHOULD set timer F to fire in 64*T1 seconds.  The request
   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2).  This
   process continues so that retransmissions occur with an exponentially
   increasing interval that caps at T2.  The default value of T2 is 4s,
   and it represents the amount of time a non-INVITE server transaction
   will take to respond to a request, if it does not respond
   immediately.  For the default values of T1 and T2, this results in
   intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.

   If Timer F fires while the client transaction is still in the
   "Trying" state, the client transaction SHOULD inform the TU about the
   timeout, and then it SHOULD enter the "Terminated" state.  If a
   provisional response is received while in the "Trying" state, the
   response MUST be passed to the TU, and then the client transaction
   SHOULD move to the "Proceeding" state.  If a final response (status
   codes 200-699) is received while in the "Trying" state, the response
   MUST be passed to the TU, and the client transaction MUST transition
   to the "Completed" state.

 

Итого: оборудование провайдера нарушает RFC 3262 (100rel / PRACK SIP standard extension). Чтобы как-то с этим бороться, попробуйте ввести в CLI роутера новую команду dect sip-common 100rel disable . Мы ее добавили в последней прошивке для отключения этого стандарта. Что получится - непонятно, так как стандарт очень старый, всеми используется, и уже давно прибит гвоздями к базовому SIP стеку. Поэтому пришлось обрабатывать напильником. Если напильник был правильный, и если у провайдера оборудование сможет работать, когда мы скажем, что не поддерживаем 100rel / PRACK - тогда все будет чики-пики. Если нет - давайте еще дампы после этой команды, будем посмотреть, что там еще допилить и куда дальше напильник совать.

 

[Joe]

@des

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

1. Отвалилось само по себе соединение с SIP. Роутер не может сам восстановить регистрацию.
2..Дамп трафика я снял небольшой. Прикладываю.
3. В дампе почему то неправильное время. Это происходило в 10 часов с чем то, а в дампе 8
4. В дампе роутер почему то шлет сигналы модему (168.8.1), хотя установлено соединение с проводным провайдером и аптайм 3 дня http://prntscr.com/rhnhof

5.. Но как только я РУКАМИ щелкнул тумблер телефонной линии в веб интерфейсе -выключить, затем включить - соединение мгновенно установилось. Это отражено в дампе. Селфтест приложил, если есть толк от него.

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

[des]

@Joe D В управляющей системе роутера есть логика, которая должна рестартовать SIP стек при смене интерфейса подключения к интернету. Скорее всего, там что-то поломалось.

В следующий раз, когда регистрация отвалится, введите, пожалуйста, команду CLI:

dect rpc register

Это должно перезагрузить pjsip (на котором основывается телефония), и он найдет маршрут к серверу. Если проблема в этом. Если поможет (или не поможет) - скажите, пожалуйста.

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

[des]

@Joe D Начальство рекомендует зайти в вебку модема (192.168.8.1) и отключить SIP ALG (siproxd). Если нет такой настройки - обновить прошивку модема. Раньше уже были проблемы с Huawei E3372. Сейчас похоже, что модем подменил своим адресом адрес SIP сервера Билайн.

[Joe]

1. Модем настроен как резервный. Я писал что аптайм провайдера уже 3 дня, без разрывов и переключений на модем. Проблема возникла на 3 день при работе чисто-на-проводном подключении.

2. В вебморде модема нет SIP ALG, возможно действительно прошивку надо будет обновить. Но это не отменяет п.1..

И еще не подскажете, скачал свежий мануал cli для viva - там нет ни одной команды для dect, включая ту что вы выше написали. Они где то в другом месте лежат?

Изменено 17 марта, 2020 пользователем Joe D

[des]

@Joe D Команд для dect нет в мануале - большинство из них либо нужно для общения веб интерфейса и телефонии, либо вообще для тестирования

[des]

@Joe D пока непонятно по пунктам 1 и 2. Начальство предполагает, что могло быть кратковременное отключение основного соединения, которое привело к попытке соединения с сервером через модем, но не было записано в статистике как проблема со связью.

Если хотите проверить - предлагают провести следующий эксперимент:

1. подключить LTE- модем и проводное подключение к Интернету. Убедиться, что проводное подключение основное и оба подключения работают нормально. Выключить DECT-станцию в веб-интерфейсе.
2. настроить и активировать захват трафика UDP одновременно на проводном интерфейсе и LTE-модеме.
3. включить DECT-станцию в веб-интерфейсе, убедиться, что SIP-линии зарегистрировались.
4. отключить проводное подключение от роутера на 2 минуты.
5. восстановить проводное подключение, подождать 2 минуты.
6. выключить захват трафика на обоих интерфейсах, прислать дампы нам.

Спасибо.

Я занимаюсь собственно телефонией (DECT), а здесь проблема где-то между настройками роутера, сети и модема, поэтому сам не могу вразумительно отвечать.

 

[krass]

2 часа назад, des сказал:

@Joe D Команд для dect нет в мануале - большинство из них либо нужно для общения веб интерфейса и телефонии, либо вообще для тестирования

А нельзя ли опубликовать хотя бы небольшой список команд для cli ?  

[des]

@krass а что Вы хотите с ними делать? Вручную трубки регистрировать без веб интерфейса?

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

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

[krass]

6 минут назад, des сказал:

Да, там есть пару десятков "тонких настроек", но из них большая часть даже в команды CLI не выведена

Да, как раз тонкая настройка и имелась в виду. 

Вот например вроде таких команд:

В 10.03.2020 в 15:05, des сказал:

Попробуйте поставить последнюю прошивку 3.4 Alpha 6 и ввести команду CLI dect sip-common 100rel disable. Эта команда (если нормально сработает) должна отключить на нашей стороне поддержку стандарта 100rel, который заведует отсылкой PRACK. Возможно, после этого проблемы исчезнут.

Ведь наверняка не одна команда еще есть. А так отдельный пост на форуме с небольшим списком команд и проблем, которые они решают  -- многое бы упростил и ускорил...

Изменено 18 марта, 2020 пользователем krass

[des]

@krass Эту команду мы делали всей командой)

Сначала - я руками отковыривал поддержку 100rel от pjsip, где она уже годами пришита. Начальник проверял трафик и говорил, что еще надо отключить. Потом - сосед добавлял в CLI роутера новую команду, которая выставляет мою новую настройку в конфиге телефонии. Потом - его код проверял тех директор, чтобы новая команда не свалила роутер.

В результате - ушла неделя (параллельно с другой работой) на проблему @Joe D и появилась новая команда, которую поддержка сможет посоветовать, если у кого-то еще провайдер поставит такое же забавное оборудование. А на ровном месте мы новые команды обычно не добавляем, и вообще - сейчас FXS донглом занимаемся.

Цель - телефония должна работать "из коробки", а не требовать ручного ввода 100500 команд - такое нафиг не надо. Не все от нас зависит, и не все в этой жизни мы видели, но хочется стараться.

[krass]

3 минуты назад, des сказал:

Эту команду мы делали всей командой)

Что ж спасибо, не знал))

5 минут назад, des сказал:

Цель - телефония должна работать "из коробки", а не требовать ручного ввода 100500 команд - такое нафиг не надо.

Это да, было б хорошо) но вы видите как провайдер "соблюдает" rfc ))