Система видеонаблюдения своими руками - 2

РЕКЛАМА НА ФОРУМХАУС

Ваш SIP сервер, при этом, зарегистрирован на внешнем сервере, не так ли? А что произойдет, когда вы клиентом SIP со своего телефона, с интернетом через SIM карту попытаетесь зарегистрироваться на домашнем сервере?

 

Сервер (без проброса портов) не может быть "на домашнем сервере", потому что сервер - посредник в установлении соединения между клиентами и должен быть доступен

подумайте о ситуации звонка между двумя клиентам с помощью общедоступного сервера, с передачей медиа-трафика между клиентами напрямую, если у одного из них full cone nat (после создания динамического правила пропускает на UDP порт трафик с любого источника), тип NAT у второго - не важен

 

Я к этому и веду, человек хочет смотреть камеры извне.

 

Да. Но сервер - это облако, а зритель и камера - клиенты. Вот подумайте об этой ситуации. Про передачу меда-трафяика напрямую. Сигналинг - через сервер

Можете даже упростить задачу. Подумать чем передача видео в ситуации, когда одна сторона за full cone NAT, а вторая - за любым, отличается от ситуации, когда первая сторона вообще за статическим пробросом портов. Единственный нюанс - ей надо выяснить свой внешний IP и порт, и сообщить его через посредника (сервер) другой стороне.

 

Какая занимательная дискуссия. Очень все понятно и информативно
Кстати, а почему рассматривается вариант только с одним NATом с каждой стороны? Ведь, зачастую, видеосервер (регистратор) будет за двойным, а то и за тройным NATом. И откуда такая уверенность, что NAT у всех реализован одинаково? Интересно как медиа трафик потечет напрямую через тройной NAT безо всяких манипуляций со стороны провайдера и юзера?

 

Что вам конкретно непонятно в дискуссии? Она для тех, кто эти слова понимает. Не для скучающих зрителей

Где вы увидели эту уверенность?

Нет такой уверенности Вы невнимательные. Есть уверенность, что при наличии на одной стороне full cone или restricted cone абсолютно не важно, что на другой. Достаточно одной стороны, любой. Да, может и убеих сторон оказаться symmetric, гарантии в интернете никто не дает. В таком случае не будет peer-to-perr, трафик скорее всего пойдет через китайский сервер и будет тормозить

Да, технологии без гарантии, а кому сейчас легко?

А чем так тройной NAT хуже двойного?

 

Погуглил по теме, вот первое попашееся - человек пишет про свой опыт реализации p2p. Как и весь хабр, текст хаотический, но суть в общем понятна

https://habr.com/ru/companies/tensor/articles/347534/

 

В общем как обычно. Сами не знаете как оно работает, но повыкрикивать наугад загугленные термины это святое.
Где хоть одно доказательство, что трафик с регика ходит напрямую в телефон, самостоятельно делая дырки в NATe? Даже в приведенной статье используется дополнительное ПО и всякие прочие манипуляции.
Кстати чё там Ваш эксперимент с кинетиком и вайршарком? Не удался? Я волнуюсь.

 

Все как всегда. Влезаете в тему, в который вы не компетентны полностью, и кричите "нагуглил", произнося при этом абсолютно бессмысленные фразы. Ничего нового. Как это работает - я написал еще до вашего появления в обсуждении.

У меня в следующем году 30 лет юбилей моей первой разработки для VoIP, а так я в этой сфере работаю до сих пор (но не только VoIP). Ну и как бы тема про nat traversal, абсолютно обычная для этой сферы, поднимается с интервалом раз в несколько лет. И хотя я так ни разу, ни в одном проекте не стал ее делать в варианте p2p, но изучать общеизвестные методики пришлось. И можете называть это "нагуглил", для вас вообще любое знание - это "нагуглил", такой универсальный ответ. Да, NAT я тоже писал, под винду, 1999-2000 год, в релиз не пошло - появился ICS неожиданно

Нагуглил я для вас текстик от людей, кто реализовал. Чтобы вы почитали. Ибо писать тут далее это зафлудить ветку до конца, там и так несколько постов уже с объяснениями. Поэтому читайте, если вам это действительно интересно. Чтобы нагуглить - надо было знать, что там должно быть написано.

Вы всилу полней некомпетентности так и не поняли, что оно ходит напрямую именно благодаря тому самому "дополнительному ПО", которое помогает двум сторонам обменяться информацией друг о друге и определить параметры NAT. Слова STUN и "сигналинг сервер" присутствуют в моем посте на предыдущей странице ветки. Я не знаю, что там у вас фантазии про "самостоятельно делая дырки", какой-то бессмысленный поток слов. Любая отправка TCP SYN или UDP пакета их локалки наружу "делает дырку" в NAT - создает динамическое правило, которое далее пропускает относящийся к соединению трафик в 2 стороны. Самостоятельно. Без помощи внешнего ПО. Но вот обмен информацией, необходимой для начала передачи напрямую, между двумя участниками за NAT - требует таки доп. сервера. Про это написано выше, до вашего появления в дискуссии.

Я же написал, вы прочитали раз спрашиваете. Потом снес ибо стало лень доводить до конца.

Попытка записать трафик кинетиком провалилась полностью, даже намека не было на примерно мегабайт трафика, пролетевший в направлении одного хоста. Какие-то мелкие огрызки. Тащить NVR в кабинет, где его можно воткнуть для записи вайршарком, настраивая для этого все - стало лень. Увы. Тем более что одиночный эксперимент все равно ничего не скажет, ни положительный, ни отрицательный, а человеку, который понимает - достаточно объяснения как это работает, почему я и кинул статейку на хабре. Хотите - читайте.

 

Crucial, объяснение написано выше. Перечитайте мои посты. Про Full Cone NAT, STUN и динамические правила с их особенностями. Подробнее расписано в тексте по ссылки. Вам это просто непонятно, потому что вы только общие слова знаете.
На все ваши вопросы я ответил, правда кое где встречным вопросом, который вы проигнорировали. Про "трафик напрямую" было только про тройной NAT, я что-то пропустил?

В 2 предложения, для UDP:
1. обе стороны открывают UDP порт для передачи медиа, отправляют запросы на STUN-сервер (хотя этот функционал может быть и в облаке на своем протоколе), выясняют свой внешний IP/порт и ограничения NAT
2. При обнаружении Full Cone NAT на одной стороне, вторая сторона просто отправляет пакет первой стороне, получив ее IP/порт через облако, а первая получив его - отправляет ответ взад (при этом неважно, кто в этой схеме потом будет посылать основной поток данных)

все.

для restricted чуть сложнее

 

Аппаратный NAT отключали?

 

нет, а надо?

он пишет трафик, но там слишком мало данных, видеопотока должно было пройти больше мегабайта, а там самые активных хосты в дампе были - на сотню Kb

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

 

Ага, сейчас позвоню в мегафон, что бы они на своем bgw открыли UDP, лично для меня, пробросили его на станцию и ко мне на телефон...
А с утра поеду на работу, попрошу повторить их это, только с другой станцией и другим IP на телефоне. Здорово, что...

 

Для вас правда сюрприз, что у вас работает UDP через NAT с мегафона?

 

Он так не работает) Если вы читали статью на Хабре внимательно, то там как раз телефон инициатор соединения должен быть, соответственно, мегафону не надо ничего делать.
А если бы вы внимательно посмотрели на скриншот, то поняли бы, что там нет никакого NAT - только маршрутизация.