Код в мешке

Viktor Oreshkin:
Все бы ничего, но вот только mtproto прокси не используются для звонков

Anna 🐱:
голосовые данные передаются вне mtproto
поэтому mtproto-прокси и не может их пропускать через себя
там отдельные relay-сервера, они могут по TCP и UDP работать
и могут только через socks5 идти
ну так это прямое соединение с relay-серверами
не через прокси

Savely Krasovsky:
То есть в России работать не будет?

Anna 🐱:
если relay-сервера забанены, не будет
а с SOCKS5 будет, так как в SOCKS5 можно завернуть что угодно

Savely Krasovsky:
Я это понимаю

Viktor Oreshkin:
Было бы круто, если бы peer-to-peer устанавливался и при заблокированном релее

Anna 🐱:
не круто, когда человек жмет "отключить p2p", а p2p все равно устанавливается
и человек сливает свой IP, не ожидая того

Viktor Oreshkin:
Когда включён p2p, но забанены релеи, звонок не пройдёт
Потому что перед установкой p2p соединения несколько пакетов идут через релей

Anna 🐱:
не через релей, а через мтпрото-сервер основной
да, это обычные мтпрото-пакеты, в них вся мета
а потом сразу п2п либо релей для голоса уже
гляньте доки:3

Savely Krasovsky:
Я просто что-то тупанул, тестил звонки со включенным VPN. Уже забыл про него

Anna 🐱:
ссылочку постараюсь найти. заодно перепроверю себя

Viktor Oreshkin:
Не следил за обновлениями, но раньше точно было так
Гришка ещё вроде расписывал, что это нужно в том числе для штук вроде hole punching и для более надёжного определения адреса внешнего

Savely Krasovsky:
А в таких вещах юзаются стандартные вещи типа STUN и TURN?
Я так понимаю обращение к релею это как раз аналог STUN

Anna 🐱:
а чем mtproto-сервера не хватает для решения этой задачи?

Viktor Oreshkin:
Не могу найти уже, а сам не настолько хорош в сетях, так что не отвечу

Anna 🐱:
https://core.telegram.org/api/end-to-end/voice-calls

Savely Krasovsky:
Судя по TDLib там можно установить этот P2P канал, но нужна tgvoip
И там использовались именно методы MTProto

Viktor Oreshkin:
Это *or* должно быть and, имхо

Anna 🐱:
у меня совсем нет сил
пожалуста можно конкретнее

Viktor Oreshkin:
Ну, так как это было приведено как аргумент к тому, что релеи при p2p неё нужны, вот единственное место, где это упоминается:
Besides that, the parties have to negotiate the protocols to be used, learn the IP addresses of each other or of the Telegram relay servers to be used (so-called reflectors),

Savely Krasovsky:
P2P же вообще не всегда технически возможен
Это я так, к слову

Anna 🐱:
если невозможен, то фоллбек до relay

Viktor Oreshkin:
Беглый просмотр исходников libtgvoip показывает, что:
- endpoint’ы от mtproto сервера скармливаются libtgvoip вместе с allowP2p
- Если allowP2p == true, то вызывается SendPublicEndpointsRequest, который в итоге отправляет на UDP релеи пакет с 0xFF x 16 (и peer tag). Если udp relay не доступен или его вообще нет, то все умирает на этом этапе.
После отправки пакета waitingForRelayPeerInfo устанавливается в true
- со временем приходит очередной пакет от relay сервера с tlid TLID_UDP_REFLECTOR_PEER_INFO. Если waitingForRelayPeerInfo установлен в true, то пакет обрабатывается: из него извлекаются ip/port текущего клиента и собеседника. ip/port собеседника добавляются в список доступных endpoint’ов как p2p. Если адреса клиента и собеседника одинаковые, то происходит попытка установить соединение по локалке
- (по локалке) В очередь ставится пакет с типом PKT_LAN_ENDPOINT с локальным адресом и портом
- (по локалке) когда такой пакет приходит, данные из него добавляются в endpoint’ы
Каждый раз, когда они добавляются, новый ставится как приоритетный и происходит их перепроверка и пересортировка

Вообще, как я это понимаю: Отправляется udp пакет на релеи, все nat’ы на пути выбирают свободные порты и создаётся цепочка пересылки. Приложение на конце никак не может узнать какие там в итоге получились адрес и порт, его может узнать только релей и отправить обратно.

core.telegram.org

End-to-End Encrypted Voice Calls

Deprecated description of encryption in voice calls as implemented in Telegram apps older than version 7.0.

4 viewsedited 23:18