не-не, зачем вообще ёжику turn?  Клиент и сервер могут не видеть друг друга?

чтобы rtp трафик гонять по udp между двумя клиентами которые решили созвониться по встроенной в клиент звонилке.

Ну т.е еджаберд тут чисто функцию сервера сигнального выполняет. Но видимо авторы решили из каких-то своих соображений о удобстве эксплуатации включить в комплект и свою реализацию stun/turn сервера. Хотя лично я не вижу никакой проблемы в том, чтобы поставить сторонний выделенный. Но видимо был какой-то бизнес ризон.

аа, там по сути есть внутри webrtc встроенный?

Нет, в самом джабере емнип не было. Да им и не нужен, они же в основном на случай пир ту пир взаимодействия заточены. Ну т.е есть у тебя два офиса каждый за своим натом, и сотрудники в них общаются через какой-нибудь клиент месаджингом по XMPP. + в клиентах есть заодно и звонилка встроенная (собранная с использованием webrtc или чего-нибудь более олдскульного). В качестве сигналки используется jingle (жаббер емнип в этом случае используется практически как транспорт для передачи сообщений от одного клиента к другому и registrar), а rtp предполагается что бегает от клиента до клиента напрямую. Но так как офисы за натом, то надо как-то сделать так чтобы при звонке из одного офиса в другой трафик ходил. Для этого нужно нат пробить. Вот типа в ежа и добавили встроенный компонент.

Вообще задача пробития ната в общем случае довольно таки всратая за счёт частных случаев связанных с особенностями конфигурации (нередко криворукой) конкртеных клиентов и их сетевой инфраструктуры. В связи с этим, я бы с интересом узнал, как планируется это адрессить при массовом внедрении QUIC/HTTP3 . Хотя, возможно, там план такой что у Гугла и остальных здоровячков работать будет, а остальным оно не нужно.

примерно понял, спасибо

Так vk внедрили ж, вроде, quic. Работают. Видимо, с фоллбэками. Это ж не sctp, в конце концов

@askbnd кстати, если есть выбор то я бы jingle не использовал. Хз какой у него стейт сейчас, но когда я этот вопрос изучал, там всё было довольно печально. Его развисите забросили практически вместе с тем, как гугл похоронил XMPP. Из болей емнип ice trickle там из коробки непонятно как делать/клиенты не умеют. Из за этого как раз могут быть проблемы со скоростью установки соединения и его стабильностью, что как раз таки на мобилках и вайфаях может проявляться.

Ну вопрос в деталях во первых, во вторых я тут не про контакт речь виду конечно, а про условного админа петю который сделал апт гет инстал и хочет, чтобы всё полетело.

да, проблема как раз таки когда разные операторы. если в одной сети находятся клиенты все хорошо работает

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

В вебртц можно указывать turn сервер

+ например в своем гипотетическом http3 клиенте такую логику да ещё и с фолбэком реализовывать конечно сущее мучение.

Макс, мы тут уже про http3

И там нужен турн?

там овер udp всё

stun точно нужен, турн дискасабл

Хотя я сам протокол не знаю, может быть там вопрос решён на уровне протокола как-то.

Не решен, но учитывая что сервера обычно не за NAT-ом, обычно stun/turn не нужен