VoIP и ОПСОСы

[dr.Evil]

Настраивал ли кто нибудь IP телефонию на андроиде?

Поставил Zoiper (не бета) по вай ваю пашет более менее исправно. На мобильном интернете дозванивается, но оба абонента друг друга не слышат. В одном из приложений написано что ОПСОСы может блокировать VoIP. Хотел поговорить сегодня с тех. поддержкой МТСа но после пятого переключения в трубке тишина, больше звонить пока что нет желания

[SVI]

Эх, Витюньчик !

Ладно, слушай сюды.

Классический VoIP требует, чтобы между абонентами было установлено прямое соединение.

Даже если оба они на сером ip за nat, такое всё равно возможно, для этого существует stun и т.д, читай википедию.

Но! Если хоть один из натов меняет номер порта источника исходящего соединения на случайный,

то технология не сработает никак. Назовём это условно "плохой нат".

Любой реально работающий сервис, например Skype, всегда учитывает эту проблему, и если

между абонентами невозможно прямое соединение, то трафик релеится через сервера данного сервиса.

Классический SIP-VOIP - нет.

 

Так что тут есть только одно решение:

все абоненты, желающие работать по твоей технологии должны со своих смартфонов поднять VPN

и даже не в одну и ту же точку, и даже не ради получения белого ip, а только ради

нормального nat'a , который будет на vpn сервере. Ну просто обычный линукс там и обычный линукс нат

ну типа просто я не знаю:  iptables -A -t nat -o eth0 -j MASQUERADE

И тогда работать БУДЕТ.

 

Или есть другое решение - отказаться от классического VoIP в пользу сервиса с расширенными

возможностями : SIP/VoIP + проприетарный релей.

Рекомендую любой из betamax, а конкретно intervoip.com у меня работает отлично.

 

И да, "плохой нат" был замечен только у мобильных операторов.

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

И роутеры домашние тоже не творят, и комбинация провайдера с серым ip и роутера тоже не творит.

[dr.Evil]

@SVI,

Познавательно, спасибо

[SVI]

Строго говоря, это не борьба с VoIP. Это борьба с любым P2P.

И торренты тоже с мобильного инета можно качать только с тех пиров, которые сами имеют белый IP,

ну это пока не проблема, потому что большинство сидеров не мобильные.

А вот если все сидеры некоего торрента будут мобильные и все желающие скачать

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

или если все они поднимут VPN. У торрентов роль stun выполняет DHT, он видит с какого (внешнего) адреса-порта

пришёл (на DHT) чел и регистрирует его, что вот есть такой пир адрес-порт, а к другим пирам этот чел

стучится с этого же адреса-порта (нат не меняет) порт и они к нему со своих же неизменённых, происходит P2P.

А клиентский софт должен использовать один единственный порт для общения и с DHT, и с другими пирами,

и вышестоящие наты не должны менять этот порт на выходе - в этом вся суть P2P.

 

Единый входящий-исходящий порт в uTorrent:

[ГМО]

Глубоко копаешь Свин.
Voip (например астер) сам понимает что клиент за натом.
И если клиент удачно зарегался, то и сам астер и сама железка поддерживает (keep alive) канал, чтоб запись не заэкспарилась в NAT таблице маршрутизатора (посылая keep alive пакеты, причем это надо делать в обе стороны). 

Но, если астер "знает", что его абонент "тусуется" за натом, то он может "попросить" клиента самому начать RTP сессию и тем самым создать маппинг в NAT таблице. НО! Для этого, клиент должен понимать "симетричный" RTP (принимать и передавать данные, используя один номер порта) и понимать указание сервера, которое требует от клиента инициировать RTP сессию. Если клиент не то или ни се не понимает - тогда ему дорога к сексу со stun (что так же предусмотрено). Хотя все больше новых железок прекрасно понимают указания сервера и поддерживают "симетричный RTP". И естественно в софтварных версиях это так же реализовано на уровне протокола.

Настройка адресов RTP в астере и подключение STUN/TURN.

 

RTP/RTCP очень легко блокируется по отличным от tcp/ip заголовкам. Поэтому таки да.

https://geektimes.ru/post/273470/

Скорее всего просто дропается самими ОПСОСами. Поможет VPN.

[SVI]

Давай рассмотрим абстрактно механику установки P2P.

Представим, что есть два хоста с серыми адресами a и b, которые находятся

за белыми адресами A и B. И есть некий хелпер-сервер H, который помогает им установить P2P,

но только помогает организационно, а не релеит через себя их трафик.

 

a - A - B - b   и где-то ещё H

 

пакеты мы будем записывать так адрес:порт->адрес:порт

 

Итак, на a запустилось приложение, оно типо как на картинке у меня прибиндило свой сокет на порт 3000.

Оно связывается с хелпером:

a:3000->H:x    (x-некий порт сервиса хелпера)

на выходе с A пакет имеет вид:

A:3000->H:x

Видите, хороший нат не меняет номер порта источника.

Хелпер видит, что к нему обращаются с A:3000 и записывает в свой список

активных пиров этого пира просто как A:3000

 

Также и на b запускается приложение, которое использует, допустим другой порт 4000

b:4000->H:x

на выходе

B:4000->H:x

Добавляется в список пир B:4000

 

Хелпер знает о пирах только что они A:3000 и B:4000.

 

Теперь пиры хотят установить P2P, они связываются через хелпера и заявляют о своём

намерении. Хелпер отвечает им - ты "A:3000" кидай пакеты на B:4000, а ты "B:4000", кидай пакеты на A:3000

Они оба начинают кидать пакеты

a:3000->B:4000 , на выходе A:3000->B:4000

b:4000->A:3000 , на выходе B:4000->A:3000

 

То что в итоге шлют друг другу A и B соответствует в обе стороны портами и адресами,

то есть для A входящие от B пакеты принимаются как ответные по устанавливаемому исходящему соединению,

и для B входящие от A пакеты принимаются как ответные по устанавливаемому исходящему соединению.

Оба ната думают, что установили исходящее соединение и получили соответственный ответ. Всё, P2P установился.

 

Теперь представим, что в A у нас плохой нат, который для каждой пары назначения адрес:порт придумывает новый случайный порт источника.

 

Когда a будет соединяться с H, он пошлёт

 

a:3000->H:x   

но на выходе с A пакет будет иметь некий вид:

A:47821->H:x

 

Эта подмена не будет мешать общаться с хелпером, то что хелпер будет отвечать H:x->A:47821, будет натом A обратно транслироваться на a:3000

// но с других адресов-портов снаружи слать пакеты на A:47821 бесполезно, пропущены будут только с H:x

// согласно установленного исходящего соединения

(эта подмена вообще не мешает исходящим соединениям на белые адреса и ответам на них)

Но пир будет зарегистрирован в списке как A:47821

и когда ему придёт команда - "С тобой хотят связаться, ты кидай пакеты на B:4000", он кинет

a:3000->B:4000 , но на выходе это будет опять другой порт A:21771->B:4000

 

Но B согласно информации от хелпера ждёт пакетов от A:47821

// потому что он сам начал кидать пакеты b:4000->A:47821   вышло   B:4000->A:47821   // да, тут хороший нат, плохой только на A

 

Но получает от A:21771, пройдут ли они - нет, адрес тот же, но порт другой. Они не засчитаются как ответные по исходящему соединению.

 

Видите, если хоть один нат меняет порт источника, то P2P уже не состоится.

[ГМО]

Возможно Свин. Но тогда не будет работать ни один p2p протокол. Например майл агент, скайп, вайбер,.. етц.. а они через мобильных операторов работают.

Я остаюсь при мнении что RTP пакеты просто уходят в дроп по заголовкам на ближайшем роутере ОПСОСа. Проверить сейчас не могу, так как вся айпителефония у меня работает внутри впнов.

Если ее пустить в мир, то ее начинают ломать со скоростью 600.000 соединений в секунду с 1000000 уникальных хостов.  Но как нибудь может попробую.

[SVI]

Ты кому тут паришь, я сисадмин со стажем, я изучал под лупой все TCP едрить её и UDP,

все виды NAT и PAT.

 

И скажу тебе так - всё что реально работает на мобильных сетях,

всё оно имеет архитектуру Клиенты-Сервер, но не P2P.

 

И если ты видишь нечто вроде P2P, значит тот второй 2P имеет у себя белый IP.

[ГМО]

И если ты видишь нечто вроде P2P, значит тот второй 2P имеет у себя белый IP.

У меня из под йоты, МТС, Билайна работает.

Не знаю что ты изучал, но ты не прав.

 

Кстати есть интересный форк одного известного проекта, немного доработанный и полностью бесплатный.

http://software.schmorp.de/pkg/gvpe.html

Не хочешь затестить?

Декларируют устойчивую сеть p2p при наличии в виртуальной сети хотя бы с одной ноды имеющей белый айпи. (если две то еще лучше).

У меня время особо на это нет. Но если устойчиво работает буду пользовать.

[SVI]

Я те внатуре говорю !

Возьми два разных компа, шоб каждый работал от своего 3-4Г модема, неважно - разные операторы или одинаковые.

Поставь на них Маил.РУ Агент, установи голосовую связь.

Возьми любое средство анализа трафика, любое каким умеешь пользоваться.

И ты увидишь, что они оба установили соединение на московские белые IP из пула, принадлежащего Маил.РУ.

И так будет с любым приложением.

Лично мне не нужен gvpe, у меня есть московский vds.

[ГМО]

И ты увидишь, что они оба установили соединение на московские белые IP из пула, принадлежащего Маил.РУ.

И так будет с любым приложением.

Естественно любой p2p сети нужен сервер который даст параметры соединения каждой ноде за натом. Но этот сервер вообще не обязан быть частью сети и гонять через себя трафик.

Причем тут vds? 

[SVI]

Ты чо тут дуарчка строишь ?

Я те говорю о том, что то самое соединение, через которое идёт голос, оно будет на московский IP.

Отличить его от остального просто, это скорее всего будет UDP и трафик будет бежать стабильно и вверх, и вниз

со скоростью типичного речевого кодека.

 

А тут vds притом, что если мне лично нужен пиринг,

то я просто поднимаю со всех желающих точек до него vpn и всё.

Пинг больше всё равно не будет, у нас тут нет пиринга особенно-то в городе,

всё через Москву ходит между МТС - Билайн - РеалТ+

И через vds оно больше не становится.

[ГМО]

Ты чо тут дуарчка строишь ?

Я те говорю о том, что то самое соединение, через которое идёт голос, оно будет на московский IP.

Отличить его от остального просто, это скорее всего будет UDP и трафик будет бежать стабильно и вверх, и вниз

со скоростью типичного речевого кодека.

Чушь. Не будет оно в Мск бежать.

У мня внутри астраханского ростелекома (например) через нат, пинги внутри p2p сети 5-10 мс. А до вдски которая всем этим рулит 100 мс. Тоже самое и с voip трафиком, потому что он у меня внутри впна бегает. Через опсосов сложнее но сути не меняет.

Я тебя убеждать больше не буду, смысла нет.

[SVI]

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

 

Ну поставь своё gvpe на двух мобильноинтернетных компах,

он те скажет - ну не шмогла я, не шмогла !

[ГМО]

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

 

Ну поставь своё gvpe на двух мобильноинтернетных компах,

он те скажет - ну не шмогла я, не шмогла !

Чушь. Все работает. Вообще без разницы какой интернет.

[SVI]

То, что у тебя работает внутри ростелекома с пингом 5-10мс

для мобильноинтернетных клиентов не будет работать НИКАК.

 

Если только твой организующий vds на этот случай

не релеит трафик через себя.

[ГМО]

см выше

[dr.Evil]

Во вторник всё решится скорее всего одной галкой

[SVI]

Неужели я стал старый и глупый ?

[dr.Evil]

Ответ на этот вопрос мы получим во вторник

[jnc]

@SVI, нет, просто ГМО никогда не признаёт свою неправоту

[ГМО]

@SVI, нет, просто ГМО никогда не признаёт свою неправоту

У ГМО все работает. И проблем нет.

[SVI]

Вторник настал !!!!

[dr.Evil]

zoiper работать стал

R port uncheck.

А вы тут воды налили 2 ведра

[SVI]

Че за хрень, не

может быть прямого соединения между серыми ip от мобильных

операторов.

Они поди общаются через ваш voip сервер.

Сегодня делал эксперимент на двух смартфонах,

один был через рутер с возможностью подсмотреть трафик.

Viber - голос идёт через ip, принадлежащий немецкому link11.de

Whatsapp - голос идёт через ip, принадлежащий amazon.