Jump to content

des

Moderators
  • Posts

    660
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by des

  1. @Joe D@r13@KorDen В дампе от 27 марта 13-36-01 в 83,175746 ответ сервера 200 OK на регистрацию 30885 REGISTER содержит поле: Service-Route: <sip:mavodi-3-4a-14aa-16-ffffffff-1b359-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-8e3-2-400dd589> Вот это поле говорит, что теперь к серверу нужно стучаться по новому адресу. Кто это поле вставил в сообщение - сам сервер, какое-то устройство по дороге, или операционная система роутера - мы не знаем.
  2. @Joe D Нужно засечь момент, когда этот адрес подсовывается по SIP протоколу. Вероятно, за несколько минут (нужно смотреть период регистрации) до того, как регистрация перестает работать. Если я правильно помню, адрес может быть подменен и при перерегистрации, и во время звонка. Возможно, есть еще какие-то механизмы. Чтобы увидеть, что происходит, нужно словить момент подмены адреса в дампе трафика или в отладочном логе.
  3. @r13 А зачем оператору? Снять дополнительную плату за трафик по мобильному?
  4. Нет, переключение регистрации перезагружает pjsip, который занимается IP телефонией. Он заново ищет путь к серверу и находит правильный. И нормально работает, пока ему опять кто-то не скажет, что к серверу нужно стучаться через mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org. А потом - честно стучится, как ему сказали, пока не умрет смертью храбрых.
  5. @Joe D Роутер сам такой адрес придумать не может. Кто-то из провайдеров им подменил настоящий адрес сервера. Если не модем - значит, провайдер интернета. Либо кто-то уже сломал роутер и залез в память. Только зачем ему перенаправлять трафик на недоступный сайт?
  6. @Joe D Спасибо. Вот получается кто-то сказал роутеру, что SIP сервер находится по адресу mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org 3gppnetwork.org зарегистрирован на GSM Association. https://lookup.icann.org/lookup Такой же адрес упоминается для VoLTE https://itechinfo.ru/content/технология-volte Похоже, в какой-то момент трафик начинает идти через модем, и модем подменяет адрес сервера этой длинной строкой. Попробуйте обновить прошику модема может, там появится отключение SIP ALG.
  7. @Joe D Какая там версия? Дополнительный лог добавили в 3,04,А,11. По REST команде не знаю - я только по телефонии. И надеюсь, мы с этой проблемой разберемся. Спасибо за дамп и селф-тест - передам начальнику, он в них хорошо разбирается.
  8. @Joe D Были проблемы с серверами, пока новую телефонию в сборку не подтянули
  9. @Joe D Добавили логирование ошибок host name resolution от операционной системы. Наверное, завтра будет в draft (3.04). Возможно, идет resolution сервера регистрации, а не прокси.
  10. @Joe D Сейчас попробуем добавить логирование ошибок в тех местах, где она происходит (вызовы в операционную систему). Если повезет - увидим, что именно pjsip пытается ресолвить, и что отвечает ОС.
  11. Если бы. Эта модель железки уже не производится, нужно делать поддержку другого устройства от другого производителя. Естественно, абсолютно несовместимого с прошлым DECT донглом)
  12. Пока заморозили, чтобы сделать FXS - рук на все не хватает.
  13. @Joe D K+DECT плохо покупают. Возможно - пересекается ниша с мобильными телефонами. Есть надежда, что FXS пойдет лучше. С Билайном у нас тоже отдельная история. В начале производства K+DECT тестировали телефонию с разными провайдерами, а Билайн заблокировал нам учетки из-за того, что работали с одной учеткой из разных регионов. И потом поддержка игнорировала просьбу разблокировать. Поэтому с ними не смогли протестировать. После Вашей жалобы связались с Билайном еще раз, они активировали учетку, и там нашлась совершенно другая проблема - при подключении звонка сервер присылает a=recvonly SDP, и наша телефония падала, потому что никогда раньше такого не видели и не тестировали. Так что, зависит еще и от конкретной железки на стороне Билайна. Вам спасибо за сотрудничество - чем больше мы сейчас исправим проблем совместимости с K+DECT, тем более гладко запустим FXS донгл - приложение телефонии одно и то же.
  14. @krass Вот пытаемся смотреть, что происходит, и если проблема повторяется - что-то с ней делать (включать настройку автоматически, выносить в веб). Но сначала надо проверить, что эта настройка помогает, и для такого добавляется "голая" команда или настройка в конфиге.
  15. @krass Эту команду мы делали всей командой) Сначала - я руками отковыривал поддержку 100rel от pjsip, где она уже годами пришита. Начальник проверял трафик и говорил, что еще надо отключить. Потом - сосед добавлял в CLI роутера новую команду, которая выставляет мою новую настройку в конфиге телефонии. Потом - его код проверял тех директор, чтобы новая команда не свалила роутер. В результате - ушла неделя (параллельно с другой работой) на проблему @Joe D и появилась новая команда, которую поддержка сможет посоветовать, если у кого-то еще провайдер поставит такое же забавное оборудование. А на ровном месте мы новые команды обычно не добавляем, и вообще - сейчас FXS донглом занимаемся. Цель - телефония должна работать "из коробки", а не требовать ручного ввода 100500 команд - такое нафиг не надо. Не все от нас зависит, и не все в этой жизни мы видели, но хочется стараться.
  16. @krass а что Вы хотите с ними делать? Вручную трубки регистрировать без веб интерфейса? Да, там есть пару десятков "тонких настроек", но из них большая часть даже в команды CLI не выведена, а живет на уровне конфиг файла. В остальном - мы пытаемся разобрать каждый конкретный случай, чтобы понять, как проще с ним обойтись - может, нужно добавить правило в профиль модели трубки или провайдера, и у других пользователей проблема исправится автоматом при обновлении.
  17. @Joe D пока непонятно по пунктам 1 и 2. Начальство предполагает, что могло быть кратковременное отключение основного соединения, которое привело к попытке соединения с сервером через модем, но не было записано в статистике как проблема со связью. Если хотите проверить - предлагают провести следующий эксперимент: подключить LTE- модем и проводное подключение к Интернету. Убедиться, что проводное подключение основное и оба подключения работают нормально. Выключить DECT-станцию в веб-интерфейсе. настроить и активировать захват трафика UDP одновременно на проводном интерфейсе и LTE-модеме. включить DECT-станцию в веб-интерфейсе, убедиться, что SIP-линии зарегистрировались. отключить проводное подключение от роутера на 2 минуты. восстановить проводное подключение, подождать 2 минуты. выключить захват трафика на обоих интерфейсах, прислать дампы нам. Спасибо. Я занимаюсь собственно телефонией (DECT), а здесь проблема где-то между настройками роутера, сети и модема, поэтому сам не могу вразумительно отвечать.
  18. @Joe D Команд для dect нет в мануале - большинство из них либо нужно для общения веб интерфейса и телефонии, либо вообще для тестирования
  19. @Joe D Начальство рекомендует зайти в вебку модема (192.168.8.1) и отключить SIP ALG (siproxd). Если нет такой настройки - обновить прошивку модема. Раньше уже были проблемы с Huawei E3372. Сейчас похоже, что модем подменил своим адресом адрес SIP сервера Билайн.
  20. @Joe D В управляющей системе роутера есть логика, которая должна рестартовать SIP стек при смене интерфейса подключения к интернету. Скорее всего, там что-то поломалось. В следующий раз, когда регистрация отвалится, введите, пожалуйста, команду CLI: dect rpc register Это должно перезагрузить pjsip (на котором основывается телефония), и он найдет маршрут к серверу. Если проблема в этом. Если поможет (или не поможет) - скажите, пожалуйста. Ваш дамп пока не смотрели - сейчас немного аврал в связи с подготовкой к работе из дому, если понадобится. Надеюсь, к вечеру посмотрим.
  21. @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 - тогда все будет чики-пики. Если нет - давайте еще дампы после этой команды, будем посмотреть, что там еще допилить и куда дальше напильник совать.
  22. @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 и попробую аргументировать поведение нашего приложения (если еще будете общаться с поддержкой Билайн).
  23. @Joe D Я не обозначал вопросы так как: 1. Не было дампа, а с учетом количества 180 и 183 от сервера в отладочном логе сущий адъ без поллитра неразгребаемый. 2. Не знал, что Вы общаетесь с поддержкой после того, как они что-то исправили (проблема почему-то перестала воспроизводиться, а мы ничего потрогать не успели).
  24. @Joe D А они не сказали, зачем несколько раз подряд присылают 183, и зачем после 183 присылают 180? PRACK - это ответы на 180 и 183, которыми нас засыпает сервер. Детальнее будем разбираться в рабочий день.
×
×
  • Create New...