KorDen

... Где в RFC говорится о том что UA должен ходить сам на указанный в Service-Route хост?!

Ну так вон в прошлых self-test'ах маршрутизацию видно 😕

С чего бы? Через подсеть алиаса маршрута на "сервер" нет, только через основной IP, и он же сам его по логам добавляет правильно. См. self-test ранее с alpha 8-10. С текущей версии пришлю вечером

@Joe D, описанное вами - это стандартная Challenge-Response аутентификации чтобы не передавать пароль в открытом виде. Там может быть что угодно, значения полей из раздела WWW-Authenticate в других местах не используются. Если хочется поискать различия, надо смотреть финальное сообщение 200 OK в ответ на REGISTER и строчку Service-Route в нём. Наверняка там дается в одних случаях какой-нибудь обычный айпишник или домен, а в других это самое 3gppnetwork. Ога, SIP и IPsec - два монстра... Сидишь себе с парой SIP-прокси и несколькими транками, всё вроде понятно, и даже домофон созванивается с видеотелефоном как-то сам по себе, только кодек одинаковый выбрать и разрешить. А как окунешься в "serious business" с outbound proxy, раздельными регистрантами-прокси, раздельными логинами-номерами-etc и кучей расширений-заголовков, так уже перестаешь понимать, что вообще происходит. Вишенка на торте - согласование этой тысячи расширений с SS7-фиксой, экстра-бонус контент - с опсосами

Стоп. Нет. "6.1. Procedures at the UA": "it uses the content of the Service-Route header field as a preloaded Route header field in outgoing initial requests". И всё. Service-Route - это не outbound-прокси, и тем более не редирект регистрации. Пример описан в разделе 6.4. Клиенту UA1 возвращают в качестве Service-Route P2 и HSP, но он продолжает обращаться к P1, просто у себя в Route он МОЖЕТ подставлять присланные P2 и HSP.

Но его значение при успешных регах не блаблабла-3gpp, а вполне нормальный IP или домен же?

Видимо билайн решил не тратить лишние ресурсы и SIP-телефония стыкуется с остальное сетью через уже имеющийся IMS. Но не регистрироваться же на него Хм. В тех дампах, что сходу гуглятся, это безобразие присутствует в полях Contact для INVITE, а так же в realm и domain для ответов на REGISTER. По этим полям кинетик по идее не должен лезть на такой домен

Не прокатило, всё так же лезет с алиаса.

Пожалуй лучше так: нужна возможность задавать вес STP для всех интерфейсов

@Le ecureuil, похоже в моем случае ip alias всё-таки мешает, вон он в connecting лезет с алиасного IP вместо основного, видно что в ipsec statusall, что в conntrack Security Associations (0 up, 1 connecting): IPIP0[3]: CONNECTING, 10.x.x.x[%any]...37.x.x.x[%any]

3.4 Alpha 10, у меня похоже так и сломано..

без Ipsec это stateless туннель, в логах ничего и не должно быть (он просто постоянно UP будет), это у вас микрот чего-то чудит

Не, там у меня что-то наоборот было, но так и не понял закономерность - при наличии ip alias на интерфейсе ISP на 3.4 Alpha 6 в некоторых случаях не удавалось подключиться на основной IP. А на Alpha 8 у меня не поднимался исходящий IPIP с "IKE retransmit message ...."

// Оу, теперь и я словил на Alpha 8 жесткие глюки IPIP с бесконечным пересогласованием всех туннелей, да так, что отдалось "эхом" по цепочке всем... Откатился на Alpha 6, там прошло. self-test пришлю немного позже, как перешьюсь на 8 обратно

На Alpha 6 замечал неработающие входящие ipsec (IPIP и Virtual IP), но пока стабильно воспроизвести не получается. @dexter, а у вас ip alias есть? Или может IP динамический? @Le ecureuil, подозрения на netfilter по 500 (а точнее правила для _NDM_IP_PUBLIC в _NDM_INPUT), они то ли некорректно обновляются, то ли что-то в этом роде.