Александр Грицук, директор по развитию бизнеса Haivision в России и СНГ, выступил с докладом на Online круглом столе «Broadcasting 2021 Belarus. Технологический комплекс «Белтелерадиокомпании» 23 марта.
Александр Грицук, директор по развитию бизнеса Haivision в России и СНГ, выступил с докладом на Александр Грицук: Спасибо большое за такое представление. Мы были очень рады с вами протестироваться. Я хотел сегодня рассказать про новую функцию, которая поднимает SRT на следующий уровень надежности в использовании и сделаю это на примере нашего популярного продукта SRT Gateway.
Немножко напомню про SRT, если кто-то про него не слышал. Это протокол, который выполняет восстановление потерь при передаче через публичный интернет, старается сделать это с минимальной задержкой. Он не привязан к какому-то контенту (имеются в виду кодеки, количество пар аудио и т.д.) Плюс, поскольку мы подозреваем передачу через публичный интернет, конечно, очень важно обеспечить его защиту. Есть закрытие встроенных протоколов AES 128 и 256 бит.
https://tkt1957.com/ru/path_redundancy_haivision/
Переходим непосредственно к продукту SRT Gateway. Основные его возможности заключаются в том, что в ответ на запрос рынка, как перейти в SRT, если у вас уже есть какие-то IP-потоки, это смена протокола в одну и другую сторону. Это маршрутизация, поскольку это сетевое устройство, вы можете из точки А, где вы его используете, маршрутизировать потоки по разным абонентам, переходить из внутренней сети во внешнюю. Еще один момент – репликация потоков, вы можете сделать из одного n и облегчить возможность прохождения файрвола. На следующем слайде поясню, что я имею в виду. Если у вас есть задача передачи одного потока, и вам нужно сделать множество из одного потока, или, например, вы хотите соединить два устройства, которые находятся за файрволами, вам как раз пригодится то свойство SRT-протокола, когда инициация сессии может проходить в любом направлении, даже в противоположном от передачи видео, что совершенно нехарактерно для привычного UDP. Где с кодирующего устройства нужно знать IP-адрес и порт, он должен быть доступен для того, чтобы осуществить передачу этого потока. В SRT вы можете делать в том числе и наоборот – как вам удобнее. Внешне это будет практически зависеть от того, где вам удобнее открывать порты IP-адресам. В задаче, когда у вас оба устройства: и передающее, и приемное – находятся где-то за файрволами, наличие третьей точки, это может быть как раз наш Gateway, позволит вам осуществить передачу данных.
Здесь нарисованными стрелками показан процесс инициации подсоединения: кодер стучится на Gateway, чтобы отдать поток, а декодер стучится на Gateway, чтобы забрать поток в обратном направлении. Таким образом, устройства, находящиеся в эксплуатации, которые меняют свое положение, прекрасно смогут передать трафик по SRT-протоколу через Gateway. Это такая его суперсила, которую многие наши клиенты любят использовать. Еще одна суперсила заключается в том, что Gateway как некое серверное решение имеет минимум два, а обычно четыре и более Ethernet-интерфейса, и он сможет вам помочь обеспечить передачу видео снаружи, внутрь и обратно безопасным способом, а именно забрав потоки от ваших устройств, находящихся в локальной сети и перебросив их с внутреннего интерфейса на внешний или на несколько, если у вас их несколько. И,с другой стороны, сделать то же самое, забрав из публичного интернета потоки и отдав их на ваше локальное устройство, при этом сохранив систему безопасности вашей студии в дата-центре.
Очень важный момент: Gateway умеет в реальном времени реинкапсулировать потоки. Вы можете принять RTMP, UDP, SRT, RTR и RTSP и из этих протоколов сделать на выбор HLS, SRT,RTP и UDP. Вспоминая прошлый слайд, вы можете из студии, имея готовый поток в UDP-формате, зайти на Gateway по внутреннему интерфейсу локальной сети и выйти в наружный интерфейс, в публичный интернет и отдать этот поток в SRT абоненту, находящемуся где угодно в мире. Тоже самое можно сделать и обратно, забрав у вашей репортажной бригады в SRT-протоколе поток на Gateway, зайти с этой стороны – снаружи, и внутри выйти в UDP или RTP –что вам удобнее. Следующий момент: из одного можно сделать n, но нюанс в том, что вы не просто можете из входящего UDP сделать энное количество UDP кодов, нет, вы можете одновременно, воспользовавшись предыдущими суперсилами, сконвертировать UDP в HLSи SRT или другие доступные протоколы, сделав в каждом протоколе нужное количество потоков. Внутри будет один и тот же контент, но каждый выходящий поток будет иметь свои индивидуальные настройки, свойственные данному протоколу. Это и буферизация, и режимы, и IP-настройки. Каждый абонент, сидящий в своей локации, сможет с легкостью получить поток, имея свои собственные параметры.
Вот пример такой простейшей схемы, когда вы забираете поток не из студии, а со спортивной площадки – один или несколько SRT потоков через публичный интернет, вы заходите с внешнего интерфейса Gateway, дальше разворачиваете поток в другой протокол и на другой интерфейс. Например, локально в RTP или UDP идет производство для SRT и других задач. Вы можете обратно на какой-то внешний интерфейс отправить HLS или SRT для подсмотра вашей творческой команды, генерального директора или продюсера. Это можно организовать с помощью Gateway в считанные минуты. Вот его интерфейс, он представляет из себя набор маршрутов. Маршрут состоит из источника, который может быть захвачен по любому из перечисленных уже протоколов, и списка назначений, они также у каждого могут быть со своим протоколом, со своими настройками. Плюс вы видите статус этих соединений. Можно работать с закрытием AES, если это нужно, можно конвертировать протоколы в каждом маршруте.
Главное отличие нашего продукта Gateway и кодеров/декодеров, с которыми мои коллеги уже знакомы – особенность профессиональных решений, наличие статистики в реальном времени. Когда вы передает трафик через публичный интернет, всякое может произойти, и вы хотите понимать, что в вашем канале происходит. Такая статистика не только в цифровом, в буквенном виде доступна на Gateway, но и в виде графиков в реальном времени. Глядя на такие графики, часто легко понять, что не так и что нужно изменить в настройках для того, чтобы передача осуществлялась с минимальной задержкой, с одной стороны, а с другой стороны, абсолютно стабильно. Небольшая новинка в Gateway, которая появилась – это возможность разделять потоки, отправляемые одному порту, например, SDN по Stream1.
Перехожу к ключевому моменту, ради которого я рассказал про Gateway: это новая функция, отвечающая на частый вопрос наших клиентов, которые попробовали SRT и видят, что он максимально стабильно работает. Спрашивают: «Что делать, если вдруг оператор связи, через которого вы передаете поток, имеет проблемы: начинаются потери или снижается полоса передачи?» Ответ такой: с прошлого года, со второй половины, в самом протоколе (я упоминал уже, он публичный и доступен у многих компаний) появилась возможность нативно резервировать, передавать потоки по нескольким маршрутам синхронно. Как это работает практически на наших изделиях? Это может быть Gateway кодеры-декодеры. Вы используете энное количество физических раздельных Ethernet-интерфейсов на этих устройствах и при настройке маршрута указываете два или более независимых интерфейса, два или более IP-адресов, то же самое с портами. Дальше автоматизировано протокол осуществляет передачу пакетов по энному количеству маршрутов. На приеме устройства выбираете пакеты, которые пришли первыми. Таким образом, если у одного из операторов начинаются какие-то проблемы при передаче, вы совершенно этого не увидите на приеме, все работает бесшовно, без остановки. Единственное, что вы сможете увидеть в уже упомянутой мной статистике – можете посмотреть, как происходит потеря по одному из маршрутов. При таком подходе вы, используя два или более операторов связи, существенно поднимаете надежность передачи через ваш канал, и эта функция доступна в наших Gateway.
Наши клиенты на прошлой неделе уже обновились. Также на кодерах и декодерах сейчас это появится. Если будет желание посмотреть, как это практически реализовано, я всегда буду рад показать демо либо через Zoom, либо реально, предоставив оборудование или лицензии. Последний момент: доступно это в виде серверов как готовое изделие либо в виде виртуальной машины, если вам есть где установить на своих мощностях виртуальные машины. Также это может быть развернуто в облачных решениях и, если надо, в том числе в частных. Мы лицензируем только максимальную пропускную способность: 100, 200, 500 и есть безлимитные версии для VM. Все остальное буду готов отдельно рассказать и показать всем желающим. Готов ответить на вопросы сейчас или со мной несложно связаться по e-mail для дальнейших вопросов. У меня все, спасибо.
Алексей Вашурин: Александр, большое спасибо за презентацию. Коллеги, есть какие-то вопросы?
Тимур Кулгарин: Александр, есть вопрос, связанный с внутренней безопасностью SRT Gateway. Возможность какие-то интерфейсы опубликовать наружу, а какие-то оставить внутри сети, то есть использовать его фактически как некое устройство безопасности при передаче видео, она интересна, но всегда возникает вопрос: «А какая защита внутри?». Внутри это, наверное, какой-нибудь Linux, наверное, там какой-то файрвол настроен, какие-то сервисы работают? Вы не пробовали проходить какое-нибудь тестирование? Существуют лаборатории, которые тестируют устройства на сетевую безопасность, чтобы как-то подтвердить, что это можно делать?
Александр Грицук: Вопрос хороший. Сразу скажу, мы не проходили тестирование в России или в СНГ. Я могу спросить коллег, делалось ли что-то подобное в других странах, но так или иначе этот вопрос решается путем выбора типа инсталляции. Либо вы размещаете это в виде сервера и, может быть, можете использовать внешние файрволы, дополнительные устройства, которые, конечно, будут стоить денег, но тем не менее. Либо вы можете решить на уровне виртуальной машины или дополнительным софтом. Операционная система, на которой работает Gateway, не раскрою большой секрет, это CentOS, и какие-то средства есть в том числе на базе операционной системы. Я прошу прощения, но этот вопрос мне лучше будет переадресовать нашим сетевым специалистам, они более детально смогут предложить какие-то варианты решений.
Тимур Кулгарин: Спасибо вам. Мы просто сами как раз размышляем над тем, как правильно разместить это устройство в сети – для начала для тестов, а дальше, может быть, чтобы использовать, поэтому вопрос такой актуальный. Спасибо.
Александр Грицук: Спасибо, хороший вопрос.
Алексей Вашурин: Спасибо большое, Тимур, Александр!
