Звонки используют мало полосы пропускания по современным меркам. Даже 64 кбит/c для звонков — это хорошее качество, с низким можно уложиться в 8-16 кбит/c + заголовки пакетов UDP/IP. Просмотр видео занимает в десятки раз больше. Хотя VoIP для сокращения задержки передаёт данные мелкими пакетами, поэтому при одинаковой полосе нагрузка на сеть будет больше, но при современных объёмах трафика это малозначительно.
Операторы предлагают разные тарифы, где-то меньше звонков и больше интернета, подключайтесь на такой тариф, если вам нужна только "труба для данных".
На медленном интернете можно использовать голосовые сообщения в мессенджерах. Похоже на обычный звонок, но с большей задержкой из-за медленной связи (когда нет возможности передавать голос в реальном времени).
Хотя нет возможности передать голосовое сообщение в виде звонка на обычный телефон (а возможен ли в принципе такой сервис? скорее всего это было бы неудобно — отвечающему с обычного телефона абоненту пришлось бы слишком долго ждать ответа, но с плохой связью можно было бы хоть как-то общаться голосом).
Либо просто текстовые сообщения, но в этой теме речь идёт всё-таки про голосовые звонки.
Два актуальных сценария применения (относится и к операторским приложениям вроде МТС Коннект):
1) роуминг — из-за границы звонить по обычной мобильной сети дорого. А с возможностью звонить из мессенджера на обычные телефоны можно избежать этого (можно даже использовать интернет с симки местного оператора и оставаться на связи по российскому номеру без роуминга). Если приложение от самого оператора — ещё и без изменения этого номера принимать входящие звонки.
2) связь в помещениях — часто в помещениях качество мобильного сигнала не очень хорошее, зато есть Wi-Fi или даже проводное подключение к сети. А с такой возможностью можно звонить без мобильной сети.
Зато операторы получают увеличение использования мобильного интернета, это компенсирует им потерю выручки из-за голосовых звонков. Те люди, которые раньше только звонили, подключают ради мессенджеров небольшой пакет трафика интернета, где 1 Гб стоит относительно дорого, и оператору это выгодно.
Операторы даже завлекают таких людей тарифами с безлимитными мессенджерами. Если бы они были заинтересованы повышать количество звонков через мобильную сеть, они не поддерживали бы использование мессенджеров таким способом. Также операторы (например МТС) завлекают людей на свои мессенджеры, вроде МТС Коннект — ради этого сделали даже бесплатную внутрисеть на МТС на всех тарифах при звонках через МТС Коннект (даже если у вызываемого абонента нет приложения МТС Коннект). Всё это тоже ради стимулирования использования мобильного интернета.
Не очень понятно, идёт ли речь о звонках на номера ТфОП и мобильных сетей, или о звонках внутри сети самих мессенджеров. Доступ к звонкам внутри мессенджеров им вряд ли дадут (это уже слишком вызывающе), а на ТфОП и мобильных сетях звонки и так контролируются.
А как же «Ревизор», блокировки, СОРМы, Яровая?
У нас эти государственные хотелки стали бы очень значительной частью расходов. Как в Америке с этим обстоят дела? Как говорил Сноуден, АНБ у них тоже всех подряд слушать хочет, значит, аналоги Яровой тоже должны быть.
Благодаря высокой скорости есть ещё один вариант использования Wireguard — распределённые сети.
На разных этажах здания стоят разные Wi-Fi точки и розетки проводной сети, подключённые к сети без доступа в интернет и важным корпоративным ресурсам. В этой сети открыт только доступ к портам VPN сервера на Wireguard, через который уже можно получить доступ куда надо. И не важно, через что сидит пользователь, через Wi-Fi, провод, или VPN извне, сидит ли он в офисе, в какой-то общей зоне или дома — он будет доступен по постоянному адресу. Пришёл сотрудник на работу — выдали ему ключ. Ушёл — заблокировали. По постоянным IP хорошо вести логи и настраивать права, корпоративная система может узнавать пользователей по их внутренним IP (хотя пароли пусть все равно остаются на случай, если незаблокированное устройство попадёт в руки другого пользователя).
Система работает в том случае, если в здании размещается несколько компаний, и есть общее рабочее пространство, тогда из общей сети здания открывается доступ к нескольким VPN серверам, принадлежащим каждой компании, и сотрудники каждой компании имеют доступ к своим ресурсам.
Кто попало не подключится к сети, даже узнав пароль Wi-Fi или воткнувшись в сетевую розетку.
Недостаток такого решения — большой трафик через VPN сервер (интересно, можно ли его кластеризовать, чтобы масштабировать добавлением нового узла в кластер).
Я написал явно "там в конфиге задаётся адрес внутри VPN", и он задаётся статически в конфиге, поменялся IP — должен меняться конфиг и на сервере, и на клиенте. Это часто бывает неудобно.
Но в следующих версиях клиента WireGuard планируется добавить поддержку динамических адресов внутри VPN. https://git.zx2c4.com/wg-dynamic/about/docs/idea.md
Ещё один тест: в параметрах разработчика включена опция "Не отключать мобильный интернет для быстрого переключения между сетями".
С мобильной сети на Wi-Fi практически мгновенно, без пропусков с -i 0.1, обратно задержка около 1 секунды.
Значит дело точно не в типе VPN-соединения, а в реализации переключения сетей на самом устройстве.
Я на мобиле проверял именно.
Так выглядит переключение с мобильной сети на Wi-Fi:
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=26.3 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=24.6 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=31.7 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=7.99 ms (Wi-Fi)
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=6.70 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=339 ms
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=3.19 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=6.20 ms
64 bytes from 192.168.29.226: icmp_seq=18 ttl=64 time=3.43 ms
64 bytes from 192.168.29.226: icmp_seq=19 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=20 ttl=64 time=6.73 ms
64 bytes from 192.168.29.226: icmp_seq=23 ttl=64 time=110 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=24 ttl=64 time=36.7 ms
64 bytes from 192.168.29.226: icmp_seq=25 ttl=64 time=44.0 ms
задержка побольше, но все равно в пределах нескольких секунд.
Интересно, я проверял переключение специально, и всё нормально:
$ ping 192.168.29.226 (это телефон, подключённый по VPN WireGuard)
PING 192.168.29.226 (192.168.29.226) 56(84) bytes of data.
64 bytes from 192.168.29.226: icmp_seq=1 ttl=64 time=1.70 ms (подключение по проводу)
64 bytes from 192.168.29.226: icmp_seq=2 ttl=64 time=1.35 ms
64 bytes from 192.168.29.226: icmp_seq=3 ttl=64 time=1.87 ms
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=2.88 ms (переключение на WiFi)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=258 ms
64 bytes from 192.168.29.226: icmp_seq=9 ttl=64 time=4.39 ms
64 bytes from 192.168.29.226: icmp_seq=10 ttl=64 time=100 ms
64 bytes from 192.168.29.226: icmp_seq=11 ttl=64 time=19.9 ms
64 bytes from 192.168.29.226: icmp_seq=12 ttl=64 time=246 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=168 ms
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=3.03 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=1.97 ms (переключение обратно на провод)
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=1.93 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=1.35 ms
Переключение с проводного подключения на WiFi занимает около 2-3 секунд, а обратно происходит практически мгновенно (поэтому я думаю, что сам по себе WireGuard отрабатывает переключение очень быстро). При этом IP-адреса у самих подключений по проводу и по Wi-Fi разные.
Тест с ping -i 0.01, для более точного определения времени переключения:
с провода на Wi-Fi пропущено 190 пакетов
с Wi-Fi на провод пропущено 0 пакетов (при этом задержка также не росла)
Это антицензурный VPN. А как насчёт применения VPN на предприятиях для удалённого доступа? админ же замучается каждому выдавать ключи, адреса и следить за всем этим.
Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.
Тогда зачем переживать за диапазон 6 ГГц? Для многоквартирных домов лучше подойдёт стандарт типа WiGig с маломощной точкой в каждой комнате, для загородных домов, где другие точки не мешают, будет хватать и 5 ГГц (может и 2,4 ГГц тоже, если дальность важнее, чем скорость). Для уличных точек из-за бóльшей дальности будет лучше подходить 2,4 ГГц.
Не хочется тянуть кабели в квартире? миритесь с неизбежными физическими ограничениями — если точка доступа пробивает стены, ей будут мешать соседские точки.
Не думаю — скорее всего развитие беспроводных технологий просто упёрлось в нехватку частот. Чем больше скорость передачи, тем больше нужно частотной полосы. Причём увеличивать частоты бесконечно тоже не получается — падает проникающая способность.
Мобильная связь на высокочастотном 5G была бы очень неудобной из-за неустойчивого сигнала. Даже на 4G (1.8 ГГц) это сильно заметно, на даче есть место, где на возвышенности очень хороший сигнал, а в 200 метрах в кустах связь пропадает. На 5G добиться устойчивого покрытия везде было бы гораздо сложнее.
Даже если бы можно было отвести под связь вообще все существующие частоты без ограничений, все равно бы упёрлись, но чуть позже.
WiFi в многоквартирных домах будет работать плохо всегда, если точка доступа будет в каждой квартире, и на 5 ГГц, и на 6. Возможно как-то могло бы помочь взаимодействие между точками доступа в одном доме. Или увеличение частоты до такой степени, чтобы сигнал не проходил сквозь стены, с установкой маломощной точки доступа или излучающего кабеля в каждой комнате.
Это похоже на переносимость телефонных номеров. Без переносимости получается похожая зависимость от окружения: человек хотел бы сменить оператора, но ему приходится пользоваться старым номером, чтобы оставаться в контакте со своим окружением.
Операторам переносимость тоже невыгодна и они не стали бы добавлять её по своей воле. До этого дошло с политической волей государства и общим запросом пользователей на такую функцию.
Почему в случае с мессенджерами должно пойти по-другому, и зависимость от поставщика для поддержания общения должна сохраняться? только потому, что мобильные операторы стоят под государствами, а мессенджеры нет, а пользователям проще поставить ещё одно приложение, чем подключить тариф другого оператора — они же не платят за это деньги, а расходуют только немного трафика и заряда батарейки телефона? Или есть ещё какое-то принципиальное отличие между телефонной сетью, email и мессенджерами с соцсетями, из-за которого первые два способа общения интероперабельны, а последний нет?
Звонки используют мало полосы пропускания по современным меркам. Даже 64 кбит/c для звонков — это хорошее качество, с низким можно уложиться в 8-16 кбит/c + заголовки пакетов UDP/IP. Просмотр видео занимает в десятки раз больше. Хотя VoIP для сокращения задержки передаёт данные мелкими пакетами, поэтому при одинаковой полосе нагрузка на сеть будет больше, но при современных объёмах трафика это малозначительно.
Операторы предлагают разные тарифы, где-то меньше звонков и больше интернета, подключайтесь на такой тариф, если вам нужна только "труба для данных".
На медленном интернете можно использовать голосовые сообщения в мессенджерах. Похоже на обычный звонок, но с большей задержкой из-за медленной связи (когда нет возможности передавать голос в реальном времени).
Хотя нет возможности передать голосовое сообщение в виде звонка на обычный телефон (а возможен ли в принципе такой сервис? скорее всего это было бы неудобно — отвечающему с обычного телефона абоненту пришлось бы слишком долго ждать ответа, но с плохой связью можно было бы хоть как-то общаться голосом).
Либо просто текстовые сообщения, но в этой теме речь идёт всё-таки про голосовые звонки.
Два актуальных сценария применения (относится и к операторским приложениям вроде МТС Коннект):
1) роуминг — из-за границы звонить по обычной мобильной сети дорого. А с возможностью звонить из мессенджера на обычные телефоны можно избежать этого (можно даже использовать интернет с симки местного оператора и оставаться на связи по российскому номеру без роуминга). Если приложение от самого оператора — ещё и без изменения этого номера принимать входящие звонки.
2) связь в помещениях — часто в помещениях качество мобильного сигнала не очень хорошее, зато есть Wi-Fi или даже проводное подключение к сети. А с такой возможностью можно звонить без мобильной сети.
Зато операторы получают увеличение использования мобильного интернета, это компенсирует им потерю выручки из-за голосовых звонков. Те люди, которые раньше только звонили, подключают ради мессенджеров небольшой пакет трафика интернета, где 1 Гб стоит относительно дорого, и оператору это выгодно.
Операторы даже завлекают таких людей тарифами с безлимитными мессенджерами. Если бы они были заинтересованы повышать количество звонков через мобильную сеть, они не поддерживали бы использование мессенджеров таким способом. Также операторы (например МТС) завлекают людей на свои мессенджеры, вроде МТС Коннект — ради этого сделали даже бесплатную внутрисеть на МТС на всех тарифах при звонках через МТС Коннект (даже если у вызываемого абонента нет приложения МТС Коннект). Всё это тоже ради стимулирования использования мобильного интернета.
Не очень понятно, идёт ли речь о звонках на номера ТфОП и мобильных сетей, или о звонках внутри сети самих мессенджеров. Доступ к звонкам внутри мессенджеров им вряд ли дадут (это уже слишком вызывающе), а на ТфОП и мобильных сетях звонки и так контролируются.
У нас эти государственные хотелки стали бы очень значительной частью расходов. Как в Америке с этим обстоят дела? Как говорил Сноуден, АНБ у них тоже всех подряд слушать хочет, значит, аналоги Яровой тоже должны быть.
OpenVPN даже без шифрования медленнее WireGuard.
Благодаря высокой скорости есть ещё один вариант использования Wireguard — распределённые сети.
На разных этажах здания стоят разные Wi-Fi точки и розетки проводной сети, подключённые к сети без доступа в интернет и важным корпоративным ресурсам. В этой сети открыт только доступ к портам VPN сервера на Wireguard, через который уже можно получить доступ куда надо. И не важно, через что сидит пользователь, через Wi-Fi, провод, или VPN извне, сидит ли он в офисе, в какой-то общей зоне или дома — он будет доступен по постоянному адресу. Пришёл сотрудник на работу — выдали ему ключ. Ушёл — заблокировали. По постоянным IP хорошо вести логи и настраивать права, корпоративная система может узнавать пользователей по их внутренним IP (хотя пароли пусть все равно остаются на случай, если незаблокированное устройство попадёт в руки другого пользователя).
Система работает в том случае, если в здании размещается несколько компаний, и есть общее рабочее пространство, тогда из общей сети здания открывается доступ к нескольким VPN серверам, принадлежащим каждой компании, и сотрудники каждой компании имеют доступ к своим ресурсам.
Кто попало не подключится к сети, даже узнав пароль Wi-Fi или воткнувшись в сетевую розетку.
Недостаток такого решения — большой трафик через VPN сервер (интересно, можно ли его кластеризовать, чтобы масштабировать добавлением нового узла в кластер).
Определяется уменьшенный MTU 1280.
Я написал явно "там в конфиге задаётся адрес внутри VPN", и он задаётся статически в конфиге, поменялся IP — должен меняться конфиг и на сервере, и на клиенте. Это часто бывает неудобно.
Но в следующих версиях клиента WireGuard планируется добавить поддержку динамических адресов внутри VPN.
https://git.zx2c4.com/wg-dynamic/about/docs/idea.md
Версия ядра: 3.18.140
Версия Android: 10
Вряд ли. Специальный модуль для wireguard если и есть на android, то только в кастомных прошивках.
Ещё один тест: в параметрах разработчика включена опция "Не отключать мобильный интернет для быстрого переключения между сетями".
С мобильной сети на Wi-Fi практически мгновенно, без пропусков с -i 0.1, обратно задержка около 1 секунды.
Значит дело точно не в типе VPN-соединения, а в реализации переключения сетей на самом устройстве.
Я на мобиле проверял именно.
Так выглядит переключение с мобильной сети на Wi-Fi:
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=26.3 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=24.6 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=31.7 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=7.99 ms (Wi-Fi)
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=6.70 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=339 ms
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=3.19 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=6.20 ms
64 bytes from 192.168.29.226: icmp_seq=18 ttl=64 time=3.43 ms
64 bytes from 192.168.29.226: icmp_seq=19 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=20 ttl=64 time=6.73 ms
64 bytes from 192.168.29.226: icmp_seq=23 ttl=64 time=110 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=24 ttl=64 time=36.7 ms
64 bytes from 192.168.29.226: icmp_seq=25 ttl=64 time=44.0 ms
задержка побольше, но все равно в пределах нескольких секунд.
Интересно, я проверял переключение специально, и всё нормально:
$ ping 192.168.29.226 (это телефон, подключённый по VPN WireGuard)
PING 192.168.29.226 (192.168.29.226) 56(84) bytes of data.
64 bytes from 192.168.29.226: icmp_seq=1 ttl=64 time=1.70 ms (подключение по проводу)
64 bytes from 192.168.29.226: icmp_seq=2 ttl=64 time=1.35 ms
64 bytes from 192.168.29.226: icmp_seq=3 ttl=64 time=1.87 ms
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=2.88 ms (переключение на WiFi)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=258 ms
64 bytes from 192.168.29.226: icmp_seq=9 ttl=64 time=4.39 ms
64 bytes from 192.168.29.226: icmp_seq=10 ttl=64 time=100 ms
64 bytes from 192.168.29.226: icmp_seq=11 ttl=64 time=19.9 ms
64 bytes from 192.168.29.226: icmp_seq=12 ttl=64 time=246 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=168 ms
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=3.03 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=1.97 ms (переключение обратно на провод)
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=1.93 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=1.35 ms
Переключение с проводного подключения на WiFi занимает около 2-3 секунд, а обратно происходит практически мгновенно (поэтому я думаю, что сам по себе WireGuard отрабатывает переключение очень быстро). При этом IP-адреса у самих подключений по проводу и по Wi-Fi разные.
Тест с ping -i 0.01, для более точного определения времени переключения:
с провода на Wi-Fi пропущено 190 пакетов
с Wi-Fi на провод пропущено 0 пакетов (при этом задержка также не росла)
network-manager имеет gui для настройки Wireguard.
Это антицензурный VPN. А как насчёт применения VPN на предприятиях для удалённого доступа? админ же замучается каждому выдавать ключи, адреса и следить за всем этим.
Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.
Тогда зачем переживать за диапазон 6 ГГц? Для многоквартирных домов лучше подойдёт стандарт типа WiGig с маломощной точкой в каждой комнате, для загородных домов, где другие точки не мешают, будет хватать и 5 ГГц (может и 2,4 ГГц тоже, если дальность важнее, чем скорость). Для уличных точек из-за бóльшей дальности будет лучше подходить 2,4 ГГц.
Не хочется тянуть кабели в квартире? миритесь с неизбежными физическими ограничениями — если точка доступа пробивает стены, ей будут мешать соседские точки.
Не думаю — скорее всего развитие беспроводных технологий просто упёрлось в нехватку частот. Чем больше скорость передачи, тем больше нужно частотной полосы. Причём увеличивать частоты бесконечно тоже не получается — падает проникающая способность.
Мобильная связь на высокочастотном 5G была бы очень неудобной из-за неустойчивого сигнала. Даже на 4G (1.8 ГГц) это сильно заметно, на даче есть место, где на возвышенности очень хороший сигнал, а в 200 метрах в кустах связь пропадает. На 5G добиться устойчивого покрытия везде было бы гораздо сложнее.
Даже если бы можно было отвести под связь вообще все существующие частоты без ограничений, все равно бы упёрлись, но чуть позже.
WiFi в многоквартирных домах будет работать плохо всегда, если точка доступа будет в каждой квартире, и на 5 ГГц, и на 6. Возможно как-то могло бы помочь взаимодействие между точками доступа в одном доме. Или увеличение частоты до такой степени, чтобы сигнал не проходил сквозь стены, с установкой маломощной точки доступа или излучающего кабеля в каждой комнате.
Это похоже на переносимость телефонных номеров. Без переносимости получается похожая зависимость от окружения: человек хотел бы сменить оператора, но ему приходится пользоваться старым номером, чтобы оставаться в контакте со своим окружением.
Операторам переносимость тоже невыгодна и они не стали бы добавлять её по своей воле. До этого дошло с политической волей государства и общим запросом пользователей на такую функцию.
Почему в случае с мессенджерами должно пойти по-другому, и зависимость от поставщика для поддержания общения должна сохраняться? только потому, что мобильные операторы стоят под государствами, а мессенджеры нет, а пользователям проще поставить ещё одно приложение, чем подключить тариф другого оператора — они же не платят за это деньги, а расходуют только немного трафика и заряда батарейки телефона? Или есть ещё какое-то принципиальное отличие между телефонной сетью, email и мессенджерами с соцсетями, из-за которого первые два способа общения интероперабельны, а последний нет?