Здравствуйте, novitk, Вы писали:
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
Ну, например, могут вносить сумятицу, если времянка потока данных через этот канал будет напоминать видео или аудиопоток.
Достаточно зажать пропускную способность и/или добавить большой jitter, и звонки рассыпятся, а чат — нет.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, например, могут вносить сумятицу, если времянка потока данных через этот канал будет напоминать видео или аудиопоток.
Pzz>Достаточно зажать пропускную способность и/или добавить большой jitter, и звонки рассыпятся, а чат — нет.
они не полностью блокированны
потом постоянно прерываеться и разноваривать не возможно
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, например, могут вносить сумятицу, если времянка потока данных через этот канал будет напоминать видео или аудиопоток. Pzz>Достаточно зажать пропускную способность и/или добавить большой jitter, и звонки рассыпятся, а чат — нет.
То есть это не блокировка, а замедление как с ютьбом? Те же видео из телеги будут неудобоваримы и прочее.
Здравствуйте, sergey2b, Вы писали:
Pzz>>Достаточно зажать пропускную способность и/или добавить большой jitter, и звонки рассыпятся, а чат — нет.
S>они не полностью блокированны S>потом постоянно прерываеться и разноваривать не возможно
Это подтверждает мою гипотезу о добавлении jitter-а в то, что напоминает телеграмский звонок.
Здравствуйте, novitk, Вы писали:
Pzz>>Ну, например, могут вносить сумятицу, если времянка потока данных через этот канал будет напоминать видео или аудиопоток. Pzz>>Достаточно зажать пропускную способность и/или добавить большой jitter, и звонки рассыпятся, а чат — нет.
N>Тогда это не блокировка звонков, а замедление как с ютьбом. Те же видео из телеги будут неудобоваримы и прочее.
Видео он, помоему, подкачивает, как файл, с той скоростью, с которой может, а проигрывает соответственно заявленному в видео битрейту. Поэтому видео будет играться нормально, если средней скорости загрузки оказывается достаточно.
А вот звонок вперёд не подкачаешь. Поэтому периодическое включение большого jitter-а будет портить звонки, а все остальное сохранит работоспособность.
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
Нет, обычно это разные каналы и совсем разные сервера.
Т.е. отдельно сигнальный траффик и отдельно аудио/видео потоки.
Для VoIP оператора выгоднее чтобы аудио/видео по возможности шло напрямую.
Если это невозможно (клиенты за NAT), то используется операторский relay (TURN сервер).
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
Нет, это две совершенно разные, никак не связанные между собой системы. Кроме разве что начальной аутентификации. Более того, realtime трафик (почти) всегда ходит по UDP, тогда как все остальное — TCP.
Здравствуйте, novitk, Вы писали:
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
По таймингам.
Я как-то собеседовался в одну контору, где меня спросили, а почему RTP (данные аудиопотока) в SIP ходит исключительно по UDP? Я ответил "потому что идиоты", и меня разумеется не взяли. Я всё понимаю про не-гарантированную доставку, но при ХОРОШЕМ канале TCP не будет провисать, вдобавок ничто не мешает открывать несколько TCP-соединений и слать по ним пакеты по round-robin, ну сдохнет один пакет в общем потоке, так не страшно.
Вот выше несомненно технически грамотный SkyDance отвечает про UDP, технически он прав — как тот программист из анекдота про воздушный шар. А политически было бы более правильным делать как раз неправильно. Но до 9 уровня OSI (8 — финансовый, 9 — политический) не всякий может добраться.
N>>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
SD>Нет, это две совершенно разные, никак не связанные между собой системы. Кроме разве что начальной аутентификации. Более того, realtime трафик (почти) всегда ходит по UDP, тогда как все остальное — TCP.
С>Я как-то собеседовался в одну контору, где меня спросили, а почему RTP (данные аудиопотока) в SIP ходит исключительно по UDP? Я ответил "потому что идиоты", и меня разумеется не взяли
Правильно сделали, ведь работать-то им нужно не с выскочкой-всезнайкой, а с приятным в общении человеком. Который скажет ровно то же, но — вежливо!
С> Я всё понимаю про не-гарантированную доставку, но при ХОРОШЕМ канале TCP не будет провисать, вдобавок ничто не мешает открывать несколько TCP-соединений и слать по ним пакеты по round-robin, ну сдохнет один пакет в общем потоке, так не страшно.
Это все классно, но решается банальной задержкой (latency). Сообщение, доставленное на 2-3 секунды позже, ничем не хуже доставленного немедленно. А вот общаться с такой задержкой становится некомфортно. Это одна из причин, по которым realtime трафик не шлют по TCP. Вторая — head of the line blocking, если ты в канал уже заслал 100500 байт, получатель должен их все подтвердить, причем в определенном порядке.
PS: еще в начале 2000х, работая на одну с aik контору, мы пилили firewall, тогда еще под разные версии windows, начиная с 95. Есть столько очень простых и действенных способов сломать весь этот ваш интернет...
M>Кстати, есть же ещё такой протокол IAX2, где весь трафик ходит по одному UDP порту.
Да многих таких. Вон, Гугл продавил свой QUIC, который, конечно, чутка менее кривой чем полувековой давности TCP, но от совершенства все еще очень далек. Оно и понятно, разрабатывался ведь для решения коммерческих задач, а не общественно-научных.
Здравствуйте, SkyDance, Вы писали:
SD>Это все классно, но решается банальной задержкой (latency). Сообщение, доставленное на 2-3 секунды позже, ничем не хуже доставленного немедленно. А вот общаться с такой задержкой становится некомфортно. Это одна из причин, по которым realtime трафик не шлют по TCP. Вторая — head of the line blocking, если ты в канал уже заслал 100500 байт, получатель должен их все подтвердить, причем в определенном порядке.
Всё это понятно, а теперь открываем Amnezia или что-то иное, работающее как UDP-over-TCP, и видим, что оно всё же работает. И звонок в MS Teams работает. Вам там из ваших United States следует иногда выбираться и смотреть, как мир живёт в ненормальных условиях. К слову, повсеместный NAT — это ненормально.
Поэтому всё-таки идиоты. Телефонисты, как и отцы-основатели. Уродцы вроде SDP появились только из желания быть совместимыми с некими ранее существовавшими кривыми железками.
Здравствуйте, SkyDance, Вы писали:
С>>Всё это понятно, а теперь открываем Amnezia или что-то иное, работающее как UDP-over-TCP, и видим, что оно всё же работает.
SD>Так этот "неуловимый Джо" работает ровно потому, что его никто не пытается сломать. Сломать TCP сильно проще, чем UDP.
Ну разумеется пытаются, вы поинтересуйтесь вопросом. Моя мысль в том, что несмотря на все ограничения в абстракциях, современный интернет настолько хорош, что потери пакетов встречаются редко, даже без TCP и повторной передачи.
Здравствуйте, Слава, Вы писали:
С>По таймингам. С>Я как-то собеседовался в одну контору, где меня спросили, а почему RTP (данные аудиопотока) в SIP ходит исключительно по UDP? Я ответил "потому что идиоты", и меня разумеется не взяли. Я всё понимаю про не-гарантированную доставку, но при ХОРОШЕМ канале TCP не будет провисать, вдобавок ничто не мешает открывать несколько TCP-соединений и слать по ним пакеты по round-robin, ну сдохнет один пакет в общем потоке, так не страшно.
При хорошем канале и upd будет ходить, а он легче в плане потребления ресурсов и т.п.
Здравствуйте, novitk, Вы писали:
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
Попутный вопрос.
Блокирован только W/A и tg? Всякие матриксы, джаберры на домашних серверах работают?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Слава, Вы писали:
С>>По таймингам. С>>Я как-то собеседовался в одну контору, где меня спросили, а почему RTP (данные аудиопотока) в SIP ходит исключительно по UDP? Я ответил "потому что идиоты", и меня разумеется не взяли. Я всё понимаю про не-гарантированную доставку, но при ХОРОШЕМ канале TCP не будет провисать, вдобавок ничто не мешает открывать несколько TCP-соединений и слать по ним пакеты по round-robin, ну сдохнет один пакет в общем потоке, так не страшно.
S>При хорошем канале и upd будет ходить, а он легче в плане потребления ресурсов и т.п.
S>ЗЫ: Понимаю, что капитанство, но все же.
Мысли о том, что хорошо бы разрешить пускать голосовые данные по TCP, добавить такой стандарт, возникли у меня, когда я запускал такси и поднимал с нуля телефонию на Asterisk. Начать можно с того, что под диапазон RTP UDP обычно отдаются порты UDP с 20000 по 40000, и зачастую всякие админы, когда их просишь открыть этот диапазон, сделать перенаправление портов для машины с Asterisk из-за NAT наружу, админы как-то нервно себя ведут. Для TCP прозрачно работает NAT, для работы в связке с RTP over UDP через NAT требуются специфические настройки Asterisk. Для общения двух абонентов на одном SIP-сервере вообще можно сделать так, чтобы голос ходил напрямую между ними... теоретически, если бы они все поголовно не сидели за NAT. Я понимаю, что для всего этого имеются разные STUN/TURN сервисы, что клиент SIP у абонента тоже можно настроить, но в целом:
От SIP возникает впечатление, что он был создан в первую очередь для общения между драконами, а не людьми. Вот стоит корпорация Поперёк-Себя-Широкая-Inc, а вот имеется корпорация В-Ширину-Больше-Чем-В-Высоту-Inc, у них имеются белые адреса, да не один, а несколько, есть многочисленные админы, и вот они всё могут у себя там настроить, чтобы какие-нибудь SIP-телефоны на столах у сотрудников работали без проблем, после месяца настройки и согласований. А когда речь о домашних пользователях, которые подрабатывают операторами в такси и белого адреса в принципе не имеют, начинаются проблемы.
Можно же было создать вот отдельную настроечку, отдельный небольшой стандарт для голоса поверх TCP? Да, можно. Но вот имеется комитет по всему этому, там сидят люди, у которых в подчинении 100 серверных стоек и 10 SRE, а на всё, что помельче, они плевать хотели. Что там у вас, малый бизнес, вот мы тут пук-жряк-хряп, у нас выплаченный дом в Калифорнии и две теслы, у нас есть оборудование времён Билла Клинтона, стоит 100 миллионов долларов и нам надо, чтобы оно было совместимо с протоколами (а чтобы вы пользовались оборудованием и нам за него платили, мы вам звонки в Whatsapp и Телеграм запретим). Вот у нас тут Whatsapp и бэкенд на Эрланге, их обслуживают самые умные люди мира из физтеха, мехмата и межнара по математике, а вы, малый бизнес, вы говно на палочке, и никаких стандартов вам не положено.
Всё это высокомерное попукивание с вершин привело к тому, что в годы ковида самой популярной звонилкой стал китайский Zoom, до того никому не известный и не нужный. Были бы открытые и реализованные в уже имеющихся программах стандарты для работы не между корпорациями с корпоратами, а между кем поменьше — китайцы бы не получили такой подъём своего бизнеса. Я уверен, что ВСЕ звонки в Zoom пишутся, распознаются, транскрибируются и складываются в хранилище, в интересах КПК и лично товарища Си. Но господам вроде Skydance на это плевать, они уже пришли к успеху, и на их век успешного успеха в США хватит.
Здравствуйте, novitk, Вы писали:
N>Не понимаю, как технически сделано отделенние для блокировки именно звонков от текстовых сообщений. Там разве не единный крипто-канал?
Такое ощущение что душат канал по пропускной способности. Картинки в HD тоже плохо ходят.
С>Мысли о том, что хорошо бы разрешить пускать голосовые данные по TCP
В смысле, "разрешить"? Оно сейчас вполне разрешено, пускай сколько хочешь. Просто фигня получается, притом полная. В локалке-то оно работает, благодаря надежной доставке без всяких там retransmit'ов и прочих потерь пакетов. Но когда нужно сделать что-то реально работающее на разных по качеству сетях и платформах, как TCP попросту не годится. Опыт, увы, накоплен — именно по причине полной негодности TCP для realtime communications до сих пор нет нормальных браузерных игр. Хотя казалось бы, WASM наше все, быстр, крут, почти как нативное исполнение. Ан нет, не все так просто. Либо городить огород с WebRTC (кто писал, тот поймет), либо рисковать и ставить на WebTransport (который пока только в Хроме более-менее работает).
С> админы как-то нервно себя ведут. Для TCP прозрачно работает NAT, для работы в связке с RTP over UDP через NAT требуются специфические настройки Asterisk. Для общения двух абонентов на одном SIP-сервере вообще можно сделать так, чтобы голос ходил напрямую между ними...
"Смешались в кучу кони, люди, и залпы тысячи орудий" (С)
Отличная аргументация. "У меня нервные админы, поэтому все вокруг идиоты, раз голос/видео хотят передавать через unreliable каналы".
С>Всё это высокомерное попукивание с вершин привело к тому, что в годы ковида самой популярной звонилкой стал китайский Zoom, до того никому не известный и не нужный.
Ага, точно, именно поэтому Zoom работает через UDP.
PS: называть Сан-Хосе ("родину" Zoom'а, и его место регистрации, а также офис) как-то... странновато. Мексиканский, пожалуй, и то ближе по духу. Или это был намек на оригинал (Webex)? Так это тоже не совсем верно. Да, Zoom творечески переработанный" webex. Но — даже у webex китаец был американским.
