DY
Не обязательно же sipp, можно для начала взять тот же pjsua из pjproject, пусть регистрируется на вашем или соседнем астере схожей конфигурации.
Size: a a a
2018 November 01
DS
Не обязательно же sipp, можно для начала взять тот же pjsua из pjproject, пусть регистрируется на вашем или соседнем астере схожей конфигурации.
Есть второй "офисный" сервер, где немного эндпоинтов. Там это не проявляется. По крайней мере, в наблюдаемом периоде.
Видимо, зависит от числа подключений.
Я не против проводить разумные эксперименты: добавлять отладочный код, передавать логи... Но, ничего такого не предлагается.
Видимо, зависит от числа подключений.
Я не против проводить разумные эксперименты: добавлять отладочный код, передавать логи... Но, ничего такого не предлагается.
DY
взаимоотношения разработчиков и пользователей тема всегда мутная.
С pjsua/sipp могу попробовать помочь, пните завтра в лс
С pjsua/sipp могу попробовать помочь, пните завтра в лс
DS
взаимоотношения разработчиков и пользователей тема всегда мутная.
С pjsua/sipp могу попробовать помочь, пните завтра в лс
С pjsua/sipp могу попробовать помочь, пните завтра в лс
Огромное спасибо за предложение помощи. Но я пока не виже сценария, который можно автоматизировать.
Ведь речь идёт не о входящих пакетах.. а исходящих. Это при исходящих пакетах сервер в какой-то момент решает изменить src порт. Какими sipp можно это... промоделировать?
Ведь речь идёт не о входящих пакетах.. а исходящих. Это при исходящих пакетах сервер в какой-то момент решает изменить src порт. Какими sipp можно это... промоделировать?
DY
Можно пока в джире у них спросить какой сценарий для sipp им подойдёт. Простой REG-re-REG или что-то иное
DS
с REG никаких проблем нет. Соединение не пропадает.. регистрация идёт на ура..
DS
проблема с исходящими пакетами OPTIONS/INVITE от сервера к клиенту. Сервер вдруг плюёт на соединение от contact.. и вместо src port 5061 начинает динамически выделять порты.
Я бы просто изучил код.. от чего зависит src порт при запланированном OPTIONS к клиенту
Я бы просто изучил код.. от чего зависит src порт при запланированном OPTIONS к клиенту
DS
ещё включен rewrite. Но.. он же относится к портам клиента, никак не сервера.
У меня есть клиентские соединения с IP сервера (worker для sip2tg).. грешил на них. Но.. там не используется тот порт, который выделяется динамически и rewrite тут как бы не виновен
У меня есть клиентские соединения с IP сервера (worker для sip2tg).. грешил на них. Но.. там не используется тот порт, который выделяется динамически и rewrite тут как бы не виновен
DS
если два лога от pjproject с "правильным" OPTIONS и "неправильным"... сегодня постараюсь сравнить для начала
DY
Вопрос к ним по поводу сценария сипп все равно в силе, чтоб отправная точка примерно одна была
DS
сравнение логов выявило "добавочный код", который выполняется в случае "ошибки". Явно видно лог установления соединения с новым src портом...
DS
imho..
filter_on_tx_message вызыват pjsip_tpmgr_find_local_addr2, в котором прописана логика выбора или создания нового транспорта...
метод filter_on_tx_message на поверхностный взгляд выглядит как костыль на костыле :(
вызывает метод получения локального адреса и порта.. а после на основании своих эвристик игнорирует и переписывает полученный результат
filter_on_tx_message вызыват pjsip_tpmgr_find_local_addr2, в котором прописана логика выбора или создания нового транспорта...
метод filter_on_tx_message на поверхностный взгляд выглядит как костыль на костыле :(
вызывает метод получения локального адреса и порта.. а после на основании своих эвристик игнорирует и переписывает полученный результат
IP
Единственное изменение в этом методе между 15.1.4 и 15.2.0 - https://github.com/asterisk/asterisk/commit/65c718ab50803df6b73831ebe6846e53f94c053b
DS
local_if переключает ветку выполнения.. из поиска интерфейса к простому дублированию.
как минимум.. можно уже подумать и вставить отладочные логи.
но пока нет уверенности что дело в этом коде... я не вижу всё же чтобы создавалось новое соединение. Если только транспорт TLS вдруг стал PJSIP_TRANSPORT_DATAGRAM, что... маловероятно
как минимум.. можно уже подумать и вставить отладочные логи.
но пока нет уверенности что дело в этом коде... я не вижу всё же чтобы создавалось новое соединение. Если только транспорт TLS вдруг стал PJSIP_TRANSPORT_DATAGRAM, что... маловероятно
IP
Можно поменять эту одну строчку, пересобрать и проверить.
DS
кстати!!! Вот и разница... у меня прибиндено не на нули..
DS
тогда это должно помочь.. спасибо. Пробую
DS
не поможет... это влияет только на выбор адреса.. строка присвоения порта одинакова для обеих случаев. Не там копал
DS
[2018-10-29 21:28:31] DEBUG[14790] res_pjsip/pjsip_message_filter.c
14790 - это идентификатор потока или что-то иное?
14790 - это идентификатор потока или что-то иное?