des

@Efimov Line MGTS: msk.ims.mgts.ru registration failed: response 403 Forbidden. это сообщентие от сервера. Вероятно, ему не нравится логин, пароль, или еще что-то. Если нужно более подробно увидеть, что туда отсылается - можно включить режим отладки - там будут выидны сообщения между Кинетиком и сервером.

У DECT, кажется, 1.8 или 1.9 GHz.

@Rezdbic Может, питания не хватает. Похоже на проблему в железе.

@Joe D Отключили поддержку Service-Route начиная с 3.04. Там получилось, что в pjsip эта поддержка, скорее, "для галочки", а как пытаешься сделать нормально - то одного не хватает, то другого. Если кому-то будет сильно нужно - сделаем как положено, а пока - помучались пару дней, и в результате - просто отключили. После обновления на следующую (3.04.A.15) роутер больше не должен пытаться ходить на странный адрес mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org

@BelkuntK+DECT очень мало покупали. Вероятно, как раз радиотелефоны не выдерживают конкуренции с мобильными. К FXS можно по проводу подключить как DECT систему (база и трубка одного производителя, с полной родной функциональностью), так и обычный телефон. Также надеемся сделать поддержку нескольких донглов одновременно. Тогда одного роутера хватит на маленький офис. Вообще - теория проверяется практикой. Посмотрим, как будут покупать FXS, если его доделаем.

@Belkunt Сейчас нет. Начали делать хранение телефонной книги и истории звонков на сервере (чтобы не заводиться с флешкой), но потом всех направили заниматься FXS донглом. Думаю, в ближайший год до телефонной книги не доберемся.

@Efimov Если телефония идет по отдельному VLAN, нужно выяснить в поддержке МГТС: VLAN ID для интернета и телефонии Как заставить их роутер пропускать на Кинетик не интернет-трафик со снятым VLAN тегом, а оба видя трафика (интернет и телефонию) с проставленными VLAN тегами (как они идут по кабелю от провайдера). Какой режим получения IP адреса на интерфейсе для телефонии: динамический или статический. Если статический - тогда еще сам IP адрес.

@EfimovВзаимно! Если Вам МГТС даст данные учетки для телефонии (сервер, логин/пароль, какие-то дополнительные настройки) - можете попробовать. Вы уже пробовали подключить телефонию? Вероятно, нужно будет прокинуть оба VLAN (телефония и интернет) на Гигу; возможно - настроить маршрут к серверу телефонии.

@Joe DВам спасибо, что нашли!

@Joe D@KorDen Разобрали проблему. Итак, в pjsip есть массив даных по учеткам. В каждой учетке есть указатель на структуру pjsip_regc в которой хранятся даные для регистрации. https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_reg.c При успешной регистрации pjsip получает от сервера Service-Route и заменяет все роуты (прокси) в учетке на то, что пришло от сервера. При этом в pjsip_regc не заменяет - там лежат данные, рассчитанные при старте программы. Следующая регистрация также делается при помощи старой pjsip_regc, и так до тех пор, пока регистрация успешна. Когда регистрация не удалась (например, нет связи с сервером) - структура pjsip_regc удаляется. При следующей попытке регистрации она создается заново исходя из данных учетки, а в учетке уже поменяли роуты, и роут не ресолвится, и регистрация не работает. Итого: У нас неправильный алгоритм обработки Service-Route Каждая проблема с регистрацией вызвана недоступностью сервера телефонии Билайн Что дальше: Пишу о проблеме в поддержку pjsip, чтобы они починили для будущих поколений Делаю настройку, которая позволит игнорировать Service-Route или добавлять новые роуты в конец, а не заменять старые Пока будет готова новая команда CLI, попробуйте использовать прописанный руками маршрут ip host mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org 212.119.246.230 - это может помочь

@Joe D Начальник воспроизвел у себя на компьютере при подключении к билайну. Если выдернуть сетевой шнурок, и в этот момент пройдет запрос на регистрацию, регистрация не восстанавливается, пока не перезапустить телефонию. Разбираемся.

@KorDen@Joe D По RFC и кто кому Рабинович: 8.1.2 Sending the Request The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request. Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI. https://tools.ietf.org/html/rfc3261#section-8.1.2 Базовый стандарт SIP требует, чтобы запросы клиента отсылались по адресу первого роута в сообщении, отресолвленному при помощи DNS. Что у нас происходит: В начале список роутов пустой - в настройках учетки они не сконфигурированы, если я правильно понимаю. После регистрации сервер присылает Service-Route с адресом mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org, и этот адрес добавляется в список роутов в соответствии с RFC3608. После этого, в соответствии с RFC3261, клиент ОБЯЗАН отсылать следующие запросы на первый известный роут, который оказывается mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org. ОС или DNS не может найти его IP адрес, поэтому клиент не может отослать никакой запрос на сервер (иначе клиент нарушит RFC 3261 section 8.1.2). Если перезагрузить телефонию, или задать команду register, клиент перезагружается и не помнит, что было раньше. В результате список роутов обнулился, и клиент опять может отсылать запросы на червер, пока ситуация не повторится.

@Joe D 1) Скорее всего, понадобится несколько попыток. 2) Когда мы несколько лет назад делали в домашних условиях, Билайн заблокировал нашу тестовую учетку и потом не отвечал на просьбы разблокировать.

@Joe DНас Билайн блокировал за доступ из другого региона. И надо не дамп, а словить это все под отладчиком на компьютере. Если оно отваливается раз в сутки случайным образом - тоже вариант так себе. Разве что - на выходные ставить.

@KorDen Если бы это воспроизводилось у меня на компьютере - я бы отдебажил и посмотрел, что там происходит. Сейчас нужно решить реальную проблему реального человека, а не разбираться, кто кому что в RFC.

@Joe D Начальник предлагает прописать руками адрес для mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org, тогда не должно быть проблем с обнаружением сервера или прокси, который под ним прячется: (config)> ip host mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org 212.119.246.230 Предлагаемый адрес 212.119.246.230 - это адрес ip.beeline.ru. Есть надежда, что пакеты через него пойдут нормально. Если нет - нужно посмотреть, какой адрес с Вашего роутера ресолвится на странице "Проверка сетевого соединения" (ping) для mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org и прописать его. Если поможет - напишите, пожалуйста, результат. Спасибо

@Joe D Отдал все логи и дампы начальнику. Он смотрит сейчас.

@Joe D Почему он ищет Viva-Solos (хостнейм) - тоже не знаю. SIP вообще сложная штука - там одних стандартов и дополнений овердофига, и самому такое написать "с нуля" просто нереально. Мы взяли pjsip, он легко запустился и стабильно работает, но вникнуть в детали происходящего - это надо садить кого-то на год разбираться. Когда есть какая-то конкретная проблема - можно пробовать понять, что он там у себя делает, но тоже времени много уходит, и иногда в результате ничем не заканчивается, если какой-то кусок сильно завязан на остальные.

@Joe D realm="ims.mnc099.mcc250.3gppnetwork.org" это не оно - реалмом, насколько я понимаю, может быть любая строка - это типа как называется провайдер. Оно нужно чтобы звонки для одного провайдера не путались со звонками для другого провайдера, когда одинаковый номер абонента. У нас проблема ресолва адреса сервера, и строка в проблемном запросе тоже длиннее: getaddrinfo(mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org) returned -2 (Name or service not known). PS Authorization в случае SIP - это сервер просит клиента прислать пароль, чтобы убедиться, что это правильный пользователь. Для безопасной смены роута сервером нужно наоборот - чтобы склиент убедился, что сообщение отправлено тем сервером, которому он доверяет. Там как-то по-другому, вроде механизмов https. Зашифрованный протокол называется SIPS, в детали я тоже не влазил.

@KorDen Ждем понедельника. Я в SIP плохо разбираюсь, что сейчас мог - то сделал. Там подтянется начальник, у которого много лет практического опыта с IP телефонией, посмотрит дампы, и что-то решит. Вполне может быть проблема в pjsip когда не ресолвится один из роутов.

@Joe D Кстати, самого запроса к DNS серверу я тоже не вижу. Но я в этом не разбираюсь.

@Joe D Наша проблема в том, что сервер либо оборудование на пути к серверу перенаправляет SIP трафик через адрес, который либо сразу, либо в какой-то более поздний момент не ресолвится DNS сервером.

@Joe D Вот в самом стандарте написано, что это небезопасно без шифрования 7. Security Considerations It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of Service-Route returned by the registrar, or to insert a Service-Route even when one was not returned by the registrar. The consequence of such an attack is that future requests made by the UA using the service route might be diverted to or through a node other than would normally be visited. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks. The "sips:" URI as defined in [3] defines a mechanism by which a UA may request transport-level message integrity and mutual authentication. Since there is no requirement for proxies to modify messages, S/MIME signed bodies may be used to provide end-to-end protection for the returned value. Systems using Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI. Registrars returning a Service-Route MUST implement end-to-end protection using S/MIME and SHOULD use S/MIME to protect all such responses. UAs receiving Service-Route SHOULD authenticate attached S/MIME bodies if present. https://tools.ietf.org/html/rfc3608#section-7

@Joe D Может и сервер. Вот расширения стандарта, которое позволяет перенаправить трафик https://tools.ietf.org/html/rfc3608

@Joe D В последнем дампе то же поле появляется в 92,806402: Service-Route: <sip:mavodi-2-4a-112b-6-ffffffff-1bae2-x10pff-@mskimcs01.msk.ims.mnc099.mcc250.3gppnetwork.org:5061;lr;mpcftk=1-115-ddd-f-400e3a89>