История #

При изучении WebRTC разработчики часто чувствуют разочарование из-за сложности. Они видят функции WebRTC, не относящиеся к их текущему проекту, и хотят, чтобы WebRTC был проще. Проблема заключается в том, что у каждого свой набор вариантов использования. Коммуникации в реальном времени имеют богатую историю с множеством людей, создающих различные вещи.

Эта глава содержит интервью с авторами протоколов, составляющих WebRTC. Она дает представление о проектных решениях при создании каждого протокола и заканчивается интервью о самом WebRTC. Если вы понимаете намерения и проектные решения программного обеспечения, вы можете создавать более эффективные системы.

RTP #

RTP и RTCP - это протокол, который обрабатывает весь медиа-транспорт для WebRTC. Он был определен в RFC 1889 в январе 1996 года. Нам очень повезло, что один из авторов Рон Фредерик рассказывает о нем сам. Рон недавно загрузил Network Video tool на GitHub, проект, который повлиял на RTP.

Своими словами #

В октябре 1992 года я начал экспериментировать с платой захвата кадров Sun VideoPix, с идеей написать сетевой инструмент видеоконференцсвязи на основе IP-многоадресной рассылки. Он был смоделирован по образцу “vat” - инструмента аудиоконференцсвязи, разработанного в LBL, в котором использовался аналогичный легковесный протокол сеанса для пользователей, присоединяющихся к конференциям, где вы просто отправляете данные в определенную многоадресную группу и следите за трафиком от других членов группы.

В программе для того, чтобы она была действительно успешной, ей нужно было сжимать видеоданные перед отправкой в сеть. Моя цель состояла в том, чтобы создать приемлемый по виду поток данных, который мог бы поместиться в 128 кбит/с, или доступную полосу пропускания стандартной домашней линии ISDN. Я также надеялся создать что-то, что все еще можно было бы смотреть, которое помещалось бы в половину этой полосы пропускания. Это означало, что мне нужно было приблизительно в 20 раз сжимать видео для конкретного размера изображения и частоты кадров, с которыми я работал. Я смог достичь этого сжатия и подал заявку на патент на методы, которые я использовал, позже выданный патент US5485212A: Software video compression for teleconferencing.

В начале ноября 1992 года я выпустил инструмент видеоконференцсвязи “nv” (в бинарном формате) в интернет-сообщество. После некоторых начальных тестов он использовался для видеоконференцсвязи частей ноябрьского Интернет-Инженерного Задания по задачам (IETF) по всему миру. Примерно 200 подсетей в 15 странах были способны принимать эту трансляцию, и примерно 50-100 человек получали видео, используя “nv” в течение недели.

В течение следующих нескольких месяцев три других встречи и некоторые меньшие встречи использовали “nv” для трансляции в интернет на большой шкале, включая Австралийскую Сеть-Встречу, Рабочую встречу по аудио- и видеоконференцсвязи CU-SeeMe и встречу MultiG о распределенных виртуальных реальностях в Швеции.

Выпуск исходного кода “nv” последовал в феврале 1993 года, и в марте я выпустил версию инструмента, в которой я ввел новую схему сжатия на основе вейвлетов. В мае 1993 года я добавил поддержку цветного видео.

Сетевой протокол, используемый для “nv” и других интернет-инструментов конференцсвязи, стал основой Реалтайм-Транспортного Протокола (RTP), стандартизированного через Интернет-Инженерный Задание по задачам (IETF), первоначально опубликованного в RFCs 1889-1890 и затем пересмотренного в RFCs 3550-3551 вместе с различными другими RFCs, которые охватывали профили для переноса конкретных форматов аудио и видео.

В течение следующих нескольких лет работа продолжалась над “nv”, портируя инструмент на множество дополнительных аппаратных платформ и устройства захвата видео. Он продолжал использоваться как один из основных инструментов для трансляции конференций в интернет в то время, включая был выбран NASA для трансляции онлайн-покрытия миссий шаттла.

В 1994 году я добавил поддержку в “nv” для поддержки алгоритмов сжатия видео, разработанных другими, включая некоторые схемы аппаратного сжатия, такие как формат CellB, поддерживаемый картой захвата видео SunVideo. Это также позволило “nv” отправлять видео в формате CUSeeMe, отправлять видео пользователям, запустившим CUSeeMe на Mac и PC.

Последняя публично выпущенная версия “nv” была версией 3.3beta, выпущенной в июле 1994 года. Я работал над выпуском “4.0alpha”, который был предназначен для миграции “nv” на версию 2 RTP-протокола, но эта работа никогда не была завершена из-за моего перехода к другим проектам. Копия 4.0 альфа-кода включена в архив Network Video tool для полноты, но он не завершен и имеет известные проблемы, особенно в неполной поддержке RTPv2.

Фреймворк, предоставленный в “nv”, позже стал основой для видеоконференцсвязи в проекте “Jupiter multi-media MOO” в Xerox PARC, который, в конечном итоге, стал основой для компании-разработчика “PlaceWare”, позже приобретенной Microsoft. Он также использовался как основа для нескольких проектов аппаратного видеоконференцсвязи, которые позволяли отправлять полное качество NTSC видео по высокоскоростным Ethernet и сетям ATM. Я также позже использовал некоторый из этого кода как основу для “Mediastore”, который был сетевым сервисом записи и воспроизведения видео.

Помните ли вы мотивации/идеи других участников черновика? #

Мы все были исследователями, работающими над IP-многоадресной рассылкой и помогающими создавать магистраль интернет-многоадресной рассылки (aka MBONE). MBONE был создан Стивом Дирингом (который первым разработал IP-многоадресную рассылку), Ваном Джекобсоном и Стивом Касснером. У Стива Дирринга и меня был один научный руководитель в Стэнфорде, и Стив закончил работать в Xerox PARC, когда покинул Стэнфорд, я провел лето в Xerox PARC стажером, работая над проектами, связанными с IP-многоадресной рассылкой, и продолжал работать на них неполный день, будучи в Стэнфорде, а позже - полный день. Ван Джекобсон и Стив Касснер были двумя из четырех авторов первоначальных RTP RFCs, вместе с Хеннингом Шульцринном и мной. У нас всех были инструменты MBONE, над которыми мы работали и которые позволяли различные формы онлайн-сотрудничества, и попытка создать общий базовый протокол, который могли бы использовать все эти инструменты, и привела к RTP.

Многоадресная рассылка очень интересна. WebRTC полностью использует одноадресную рассылку, не могли бы вы рассказать об этом подробнее? #

Перед тем, как попасть в Стэнфорд и узнать о IP-многоадресной рассылке, у меня была длинная история работы над способами использования компьютеров для общения людей друг с другом. Для меня это началось в начале 80-х, когда я запустил систему доски объявлений с набором номеров, где люди могли войти и оставлять друг другу сообщения, как частные (что-то вроде электронной почты), так и публичные (группы обсуждений). Примерно в то же время я узнал об онлайн-провайдере CompuServe. Одной из крутых функций на CompuServe был так называемый “CB Simulator”, где люди могли общаться друг с другом в реальном времени. Это было полностью текстовое, но с понятием “каналов”, как в настоящей радиосвязи CB, и несколько человек могли видеть, что печатают другие, если они находились в одном канале. Я построил свою собственную версию CB, которая работала на системе разделения времени, к которой у меня был доступ и которая позволяла пользователям этой системы отправлять друг другу сообщения в реальном времени, и в течение следующих нескольких лет я работал с друзьями над разработкой более сложных инструментов реального времени на нескольких различных компьютерных системах и сетях. На самом деле, одна из этих систем до сих пор работает, и я использую ее, чтобы каждый день общаться с людьми, с которыми учился в колледже 30+ лет назад!

Все эти инструменты были текстовыми, так как компьютеры того времени в основном не имели никаких аудио/видео возможностей, но когда я попал в Стэнфорд и узнал о IP-многоадресной рассылке, я был заинтригован идеей использования многоадресной рассылки, чтобы получить что-то вроде настоящего “радио”, где вы могли бы отправить сигнал в сеть, не направляя его никому конкретно, но все, кто настроился на этот “канал”, могли бы его получить. Как оказалось, компьютер, на который я портировал код IP-многоадресной рассылки, был первым поколением SPARC-станции от Sun, и у него действительно было встроенное аппаратное обеспечение телефонного качества! Вы могли оцифровать звук с микрофона и воспроизводить его через встроенные динамики (или через выход для наушников). Поэтому моей первой мыслью было понять, как отправить этот аудио в сеть в реальном времени, используя IP-многоадресную рассылку, и посмотреть, смогу ли я построить эквивалент “CB-радио” с реальным аудио вместо текста.

Были некоторые сложные вещи, которые нужно было решить, например, тот факт, что компьютер мог воспроизводить только один аудиопоток за раз, поэтому, если несколько человек говорили, вам нужно было математически “смешивать” несколько аудиопотоков в один перед тем, как его можно было воспроизвести, но это все можно было сделать в программном обеспечении, как только вы поняли, как работает аудиосемплирование. Этот аудиоприложение привел меня к работе над MBONE и, в конечном итоге, к переходу от аудио к видео с “nv”.

Что было упущено в протоколе, что вы хотели бы добавить? Есть ли что-то в протоколе, о чем вы жалеете? #

Я не сказал бы, что жалею, но одной из больших жалоб, которые у людей в конце концов появились на RTP, была сложность реализации RTCP, контрольного протокола, который работал параллельно с основным трафиком данных RTP. Я думаю, что эта сложность была большой частью того, почему RTP не был более широко принят, особенно в случае одноадресной рассылки, где не было такой большой необходимости в некоторых функциях RTCP. По мере того, как пропускная способность сети становилась менее дефицитной, а перегрузка не была такой большой проблемой, многие люди просто стали передавать аудио и видео по обычному TCP (и позже HTTP), и в целом это работало “достаточно хорошо”, чтобы не заниматься RTP.

Что вы себе представляли, создавая RTP? Есть ли какие-то интересные проекты/идеи с RTP, которые были утеряны во времени? #

Одной из забавных вещей, которые я создал, была версия классической игры “Spacewar”, которая использовала IP-многоадресную рассылку. Без какого-либо центрального сервера несколько клиентов могли запустить двоичный файл spacewar и начать трансляцию расположения своего корабля, его скорости, направления, в котором он был обращен, и подобной информации о любых “пулях”, которые он выпустил, и все другие экземпляры могли бы перехватить эту информацию и отобразить ее локально, позволяя пользователям видеть корабли и пули друг друга, с “взрывающимися” кораблями при столкновении или попадании в них пуль. Я даже сделал “обломки” от взрыва живым объектом, который мог уничтожать другие корабли, иногда приводя к забавным цепным реакциям!

В духе оригинальной игры я визуализировал ее с использованием симулированной векторной графики, так что можно было делать такие вещи, как масштабирование вида, и все будет масштабироваться вверх/вниз. Сами корабли представляли собой набор линейных сегментов в векторной форме, которые помогли мне разработать некоторые из моих коллег в PARC, так что у каждого корабля был свой уникальный вид.

В основном, любая технология, которая могла бы извлечь пользу из потока данных в реальном времени, не требующего идеальной последовательной доставки, могла бы извлечь пользу из RTP. Так что, помимо аудио и видео, мы могли бы создавать такие вещи, как общая электронная доска. Даже передача файлов могла бы извлечь пользу из RTP, особенно в сочетании с IP-многоадресной рассылкой.

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

Почему вам пришлось самостоятельно заниматься сжатием видео? Не было ли чего-либо доступного в то время? #

К тому времени существовали основные концепции сжатия видео, с появлением стандарта MPEG-1 примерно в то же время, когда появился “nv”, но реального времени кодирования с MPEG-1 определенно не было. Изменения, которые я внес, были связаны с тем, чтобы взять эти базовые концепции и аппроксимировать их более дешевыми алгоритмами, где я избегал таких вещей, как косинусные преобразования и операции с плавающей точкой, и даже избегал целочисленных умножений, так как они были очень медленными на SPARC-станциях. Я старался делать все, что мог, только с помощью сложения/вычитания и побитового маскирования и сдвига, и это давало достаточно скорости, чтобы все еще ощущать что-то, похожее на видео.

В течение года или двух после выпуска “nv” появилось много различных аудио- и видеоинструментов, не только на MBONE, но и в других местах, таких как инструмент CU-SeeMe, созданный на Mac. Было очевидно, что это идея, время которой пришло. Я действительно закончил тем, что сделал “nv” совместимым с многими из этих инструментов, и в нескольких случаях другие инструменты перенимали мои кодеки “nv”, чтобы они могли взаимодействовать при использовании моей схемы сжатия.

WebRTC #

WebRTC потребовал усилий по стандартизации, которые превосходят все остальные усилия, описанные в этой главе. Он потребовал сотрудничества между двумя различными организациями по стандартизации (IETF и W3C) и сотен отдельных лиц из многих компаний и стран. Чтобы дать нам взглянуть на мотивации и колоссальные усилия, потребовавшиеся для создания WebRTC, у нас есть Серж Лашапель.

Серж - продукт-менеджер в Google, в настоящее время работающий продукт-менеджером для Google Workspace. Это мое резюме интервью.

Что привело вас к работе над WebRTC? #

Я был увлечен созданием коммуникационного программного обеспечения с тех пор, как учился в колледже. В 90-х годах начала появляться технология, подобная nv, но ее было сложно использовать. Я создал проект, который позволял присоединиться к видеозвонку прямо из браузера. Я также портировал его на Windows.

Я взял этот опыт в Marratech, компанию, которую я сооснователь. Мы создали программное обеспечение для групповых видеоконференций. Технологический ландшафт был совершенно иным. Передовым в видео был многоадресный режим сети. Пользователь мог полагаться на сеть для доставки видеопакета всем участникам звонка. Это означало, что у нас были очень простые серверы. Однако это имело большой недостаток - сети должны были быть разработаны для его поддержки. Индустрия отошла от многоадресной рассылки к пакетным коммутаторам, более известным как SFU.

Первый проект Google #

Первый проект, над которым работала будущая команда WebRTC, был голосовой и видеочат Gmail. Внедрение аудио и видео в браузер было непростой задачей. Это требовало специальных компонентов, которые нужно было лицензировать у разных компаний. Аудио был лицензирован у GIPs, видео - у Vidyo, а сетевая часть - у libjingle. Магия заключалась в том, чтобы заставить все это работать вместе.

Каждая подсистема имеет совершенно разные API и предполагает решение разных проблем. Чтобы заставить все это работать вместе, нужны глубокие знания сетей, криптографии, медиа и многого другого. Джастин Убертти был тем, кто взял на себя эту работу. Он объединил эти компоненты, чтобы создать пригодный к использованию продукт.

Отрисовка в реальном времени в браузере также была очень сложной. Нам пришлось использовать NPAPI (Netscape Plugin API) и делать много хитрых вещей, чтобы это работало. Уроки, которые мы извлекли из этого проекта, очень повлияли на WebRTC.

Chrome #

В то же время внутри Google начался проект Chrome. Было много волнения, и у этого проекта были огромные цели. Велись разговоры о WebGL, автономной работе, возможностях базы данных, низкой задержке ввода для игр - и это только некоторые из них.

Отказ от NPAPI стал большим приоритетом. Это мощный API, но он несет большие последствия для безопасности. Chrome использует дизайн песочницы, чтобы защитить пользователей. Операции, которые могут быть потенциально небезопасными, выполняются в разных процессах. Даже если что-то пойдет не так, злоумышленник все еще не получит доступ к пользовательским данным.

WebRTC рождается #

Для меня WebRTC родился с несколькими мотивациями. В совокупности они дали жизнь этому усилию.

Не должно быть так сложно создавать RTC-опыт. Слишком много усилий тратится впустую на повторную реализацию одного и того же разными разработчиками. Мы должны решить эти раздражающие проблемы интеграции один раз и сосредоточиться на других вещах.

Человеческое общение не должно быть ограничено и должно быть открытым. Как может быть нормально, что текст и HTML открыты, но мой голос и мое изображение в реальном времени - нет?

Безопасность - приоритет. Использование NPAPI не было лучшим для пользователей. Это также был шанс создать протокол, безопасный по умолчанию.

Чтобы сделать WebRTC реальностью, Google приобрел и открыл исходный код компонентов, которые использовались ранее. On2 был приобретен за его видеотехнологию, а Global IP Solutions за его RTC-технологию. Я отвечал за усилия по приобретению GIPS. Мы приступили к работе по объединению этих технологий и их упрощению для использования внутри и вне браузера.

Стандартизация #

Стандартизация WebRTC была чем-то, что мы действительно хотели сделать, но чего я раньше не делал, как и кто-либо из нашей непосредственной команды. Для этого нам очень повезло иметь Харальда Альвестранда в Google. Он уже проделал обширную работу в IETF и начал процесс стандартизации WebRTC.

Летом 2010 года в Маастрихте был запланирован неформальный обед. Разработчики из многих компаний собрались вместе, чтобы обсудить, каким должен быть WebRTC. На обеде присутствовали инженеры из Google, Cisco, Ericsson, Skype, Mozilla, Linden Labs и других. Полный список участников и презентационные слайды можно найти на rtc-web.alvestrand.com.

Skype также предоставил отличное руководство благодаря работе, которую они проделали с Opus в IETF.

Опираясь на плечи гигантов #

При работе в IETF вы развиваете работу, которая была до вас. С WebRTC нам повезло, что существовало так много вещей. Нам не пришлось решать каждую проблему, потому что они уже были решены. Если вам не нравится предсуществующая технология, это может быть frustrating. Должна быть очень веская причина, чтобы пренебречь существующей работой, поэтому создание собственной версии не является вариантом.

Мы также сознательно не пытались повторно стандартизировать такие вещи, как сигнализация. Это уже было решено с помощью SIP и других усилий, не связанных с IETF, и казалось, что это может стать очень политизированным. В конце концов, просто не казалось, что здесь есть много ценного, что можно добавить.

Я не остался таким же вовлеченным в стандартизацию, как Джастин и Харальд, но мне понравилось время, проведенное там. Я был более взволнован возвращением к созданию вещей для пользователей.

Будущее #

WebRTC сегодня находится в отличном состоянии. Происходят различные итеративные изменения, но ничего конкретного, над чем бы я работал.

Я больше всего взволнован тем, что облачные вычисления могут сделать для коммуникаций. Используя передовые алгоритмы, мы можем удалять фоновый шум во время звонка и делать коммуникацию возможной там, где ее раньше не было. Мы также видим, что WebRTC распространяется далеко за пределы коммуникаций… Кто бы мог подумать, что через 9 лет он будет обеспечивать облачные игры? Все это было бы невозможно без фундамента WebRTC.