Протокол обмена сообщениями в реальном времени - Real-Time Messaging Protocol

Протокол обмена сообщениями в реальном времени (RTMP) изначально был проприетарный протокол разработан Macromedia за потоковая передача аудио, видео и данные через Интернет, между Вспышка игрок и сервер. Macromedia теперь принадлежит Adobe, которая выпустила неполную версию спецификации протокола для публичного использования.

Протокол RTMP имеет несколько разновидностей:

Собственно RTMP, "простой" протокол, который работает поверх Протокол управления передачей (TCP) и по умолчанию использует номер порта 1935.
RTMPS, то есть RTMP через Безопасность транспортного уровня (TLS / SSL) соединение.
RTMPE, который зашифрован RTMP с использованием собственного механизма безопасности Adobe. Хотя детали реализации являются проприетарными, механизм использует стандартные криптографические примитивы.^[1]
RTMPT, который инкапсулированный в HTTP запросы на прохождение межсетевых экранов. RTMPT часто используется с использованием запросов открытого текста по TCP. порты 80 и 443, чтобы обойти большую часть фильтрации корпоративного трафика. Инкапсулированный сеанс может нести в себе простые пакеты RTMP, RTMPS или RTMPE.
RTMFP, то есть RTMP поверх Протокол пользовательских датаграмм (UDP) вместо TCP, заменяя поток фрагментов RTMP. Безопасность Протокол потока мультимедиа в реальном времени Этот пакет был разработан Adobe Systems и позволяет конечным пользователям подключаться и общаться напрямую друг с другом (P2P).

Хотя основной мотивацией для RTMP был протокол для воспроизведения Flash-видео, он также используется в некоторых других приложениях, таких как Adobe LiveCycle Data Services ES.

Основная операция

RTMP - это протокол на основе TCP, который поддерживает постоянные соединения и обеспечивает связь с малой задержкой. Чтобы обеспечить бесперебойную доставку потоков и передачу как можно большего количества информации, он разбивает потоки на фрагменты, и их размер динамически согласовывается между клиентом и сервером. Иногда его оставляют без изменений; размеры фрагментов по умолчанию составляют 64 байта для аудиоданных и 128 байтов для видеоданных и большинства других типов данных. Затем фрагменты из разных потоков могут чередоваться, и мультиплексированный через одно соединение. Таким образом, с более длинными фрагментами данных протокол переносит только однобайтовый заголовок на фрагмент, поэтому влечет за собой очень мало накладные расходы. Однако на практике отдельные фрагменты обычно не чередуются. Вместо этого чередование и мультиплексирование выполняются на уровне пакетов, при этом пакеты RTMP по нескольким различным активным каналам перемежаются таким образом, чтобы гарантировать, что каждый канал соответствует своей полосе пропускания, задержке и другим требованиям к качеству обслуживания. Пакеты, перемежаемые таким образом, рассматриваются как неделимые и не перемежаются на уровне фрагментов.

RTMP определяет несколько виртуальных каналов, по которым могут отправляться и приниматься пакеты и которые работают независимо друг от друга. Например, есть канал для обработки запросов и ответов RPC, канал для данных видеопотока, канал для данных аудиопотока, канал для сообщений внеполосного управления (согласование размера фрагмента и т. Д.) И т. Д. . Во время обычного сеанса RTMP несколько каналов могут быть активными одновременно в любой момент времени. Когда данные RTMP кодируются, генерируется заголовок пакета. Заголовок пакета определяет, среди прочего, идентификатор канала, по которому он должен быть отправлен, метку времени, когда он был сгенерирован (при необходимости), и размер полезной нагрузки пакета. Затем за этим заголовком следует фактическое содержимое полезной нагрузки пакета, которое перед отправкой по соединению фрагментируется в соответствии с согласованным в настоящее время размером фрагмента. Сам заголовок пакета никогда не фрагментируется, и его размер не учитывается в данных в первом фрагменте пакета. Другими словами, фрагментации подвержена только фактическая полезная нагрузка пакета (мультимедийные данные).

На более высоком уровне RTMP инкапсулирует MP3 или же AAC аудио и FLV1 видео мультимедийные потоки, и может сделать вызовы удаленных процедур (RPC) с помощью Формат сообщения действия. Любые требуемые службы RPC выполняются асинхронно с использованием единой модели запрос / ответ клиент / сервер, так что связь в реальном времени не требуется.^{[требуется разъяснение ]}^[2]^[3]

Шифрование

Сессии RTMP могут быть зашифрованы одним из двух методов:

Используя отраслевой стандарт TLS / SSL механизмы. Базовый сеанс RTMP просто заключен в обычный сеанс TLS / SSL.
Использование RTMPE, которое заключает сеанс RTMP в более легкий уровень шифрования.

HTTP-туннелирование

В RTMP Tunneled (RTMPT) данные RTMP инкапсулированный и обменялся через HTTP, а сообщения от клиента (в данном случае медиаплеера) адресуются на порт 80 (по умолчанию для HTTP) на сервере.

Хотя сообщения в RTMPT больше, чем эквивалентные сообщения RTMP без туннелирования из-за заголовков HTTP, RTMPT может облегчить использование RTMP в сценариях, где использование RTMP без туннелирования в противном случае было бы невозможно, например, когда клиент находится позади а брандмауэр который блокирует исходящий трафик, отличный от HTTP и HTTPS.

Протокол работает, отправляя команды через URL-адрес POST и сообщения AMF через тело POST. Примером является

POST / open / 1 HTTP / 1.1

для открытия соединения.

Спецификация и патентная лицензия

Adobe выпустила спецификацию протокола версии 1.0 от 21 декабря 2012 года.^[4] На целевой веб-странице, ведущей к этой спецификации, отмечается, что «В интересах клиентов, которые хотят защитить свой контент, открытая спецификация RTMP не включает уникальные меры безопасности RTMP Adobe».^[5]

Документ, сопровождающий спецификацию Adobe, предоставляет «неисключительный, бесплатный, непередаваемый, не подлежащий сублицензированию, персональный, международный» патентная лицензия ко всем реализациям протокола с двумя ограничениями: одно запрещает использование для перехвата потоковых данных («любая технология, которая перехватывает потоковое видео, аудио и / или содержимое данных для хранения на любом устройстве или носителе»), а другое запрещает обход «технологических меры по защите аудио, видео и / или данных, включая любые меры безопасности RTMP Adobe ».^[6]

Патенты и связанные с ними судебные разбирательства

Стефан Рихтер, автор нескольких книг по Flash, в 2008 году отметил, что, хотя Adobe нечетко указывает, какие патенты применяются к RTMP, Патент США 7 246 356 кажется одним из них.^[2]

В 2011 году Adobe подала в суд на Wowza Media Systems, заявив, среди прочего, о нарушении их патентов на RTMP.^[7]^[8]^[9] В 2015 году Adobe и Wowza объявили, что иски были урегулированы и отклонены с предубеждением.^[10]

Структура пакета

Диаграмма пакетов RTMP

Пакеты отправляются через TCP-соединение, которое сначала устанавливается между клиентом и сервером. Они содержат заголовок и тело, которое в случае команд подключения и управления кодируется с помощью Формат сообщения действия (AMF). Заголовок разделен на Основной заголовок (показаны на схеме отдельно от остальных) и Заголовок сообщения фрагмента. Основной заголовок - единственная постоянная часть пакета, обычно состоящая из одного составной byte, где два наиболее значимых бита - это тип блока (fmt в спецификации), а остальное - это идентификатор потока. В зависимости от значения первого, некоторые поля заголовка сообщения могут быть опущены, а их значение получено из предыдущих пакетов, в то время как в зависимости от значения последнего базовый заголовок может быть расширен одним или двумя дополнительными байтами (как в случае диаграммы, содержащей всего три байта (c)). Если значение оставшихся шести битов Основной заголовок (BH) (наименее значимое) равно 0, тогда BH составляет два байта и представляет от идентификатора потока 64 до 319 (64 + 255); если значение равно 1, то BH составляет три байта (последние два байта закодированы как 16-битный Little Endian) и представляет от идентификатора потока 64 до 65599 (64 + 65535); если значение равно 2, то BH составляет один байт и зарезервирован для сообщений и команд управления протоколом низкого уровня. Заголовок сообщения Chunk содержит информацию о метаданных, такую как размер сообщения (измеряется в байтах), Дельта отметки времени и Тип сообщения. Это последнее значение представляет собой один байт и определяет, является ли пакет звуковым, видео, командным или «низкоуровневым» пакетом RTMP, таким как RTMP Ping.

Ниже показан пример, когда флэш-клиент выполняет следующий код:

вар транслировать:NetStream = новый NetStream(connectionObject);

это сгенерирует следующий чанк:

Шестнадцатеричный код	ASCII
`03 00 0B 68 00 00 19 14 00 00 00 00 02 00 0C 63 72 65 61 74 65 53 74 72 65 61 6Д 00 40 00 00 00 00 00 00 00 05`	`␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂ ␀ ␌ c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅`

Пакет начинается с Основной заголовок одного байта (0x03), где два старших бита (b00000011) определяют тип заголовка блока 0, а остальные (b00000011) определяют идентификатор потока фрагментов, равный 3. Четыре возможных значения типа заголовка и их значимость:

b00 = 12-байтовый заголовок (полный заголовок).
b01 = 8 байт - как тип b00. не включая идентификатор сообщения (4 последних байта).
b10 = 4 байта - включены основной заголовок и метка времени (3 байта).
b11 = 1 байт - включен только базовый заголовок.

Последний тип (b11) всегда используется в случае агрегированных сообщений, где в приведенном выше примере второе сообщение будет начинаться с идентификатора 0xC3 (b11000011) и будет означать, что все поля заголовка сообщения должны быть получены из сообщения с идентификатор потока 3 (это будет сообщение прямо над ним). Шесть младших значащих битов, образующих идентификатор потока, могут принимать значения от 3 до 63. Некоторые значения имеют особое значение, например 1, обозначающее расширенный формат идентификатора, и в этом случае за ним идут два байта. Значение два предназначено для сообщений низкого уровня, таких как Ping и Set Client Bandwidth.

Следующие байты заголовка RTMP (включая значения в приведенном выше примере пакета) декодируются следующим образом:

байт # 1 (0x03) = Тип заголовка блока.
байт # 2-4 (0x000b68) = дельта отметки времени.
byte # 5-7 (0x000019) = Длина пакета - в данном случае это 0x000019 = 25 байт.
байт # 8 (0x14) = идентификатор типа сообщения - 0x14 (20) определяет закодированный AMF0 команда сообщение.
byte # 9-12 (0x00000000) = идентификатор потока сообщений. Это в порядке от младшего к старшему

Байт идентификатора типа сообщения определяет, содержит ли пакет аудио / видеоданные, удаленный объект или команду. Вот некоторые возможные значения:

0x01 = Установить размер пакета сообщения.
0x02 = Прервать.
0x03 = Подтверждение.
0x04 = Контрольное сообщение.
0x05 = пропускная способность сервера
0x06 = Пропускная способность клиента.
0x07 = Виртуальный контроль.
0x08 = Аудиопакет.
0x09 = пакет видео.
0x0F = данные расширены.
0x10 = контейнер расширен.
0x11 = Команда расширена (команда типа AMF3).
0x12 = Данные (Invoke (информация onMetaData отправляется как таковая)).
0x13 = контейнер.
0x14 = Команда (команда типа AMF0).
0x15 = UDP
0x16 = агрегировать
0x17 = Присутствует

После заголовка 0x02 обозначает строку размером 0x000C и значениями 0x63 0x72 ... 0x6D (команда createStream). После этого у нас есть 0x00 (число), которое является идентификатором транзакции со значением 2.0. Последний байт - 0x05 (ноль), что означает отсутствие аргументов.

Вызов структуры сообщения (0x14, 0x11)

Некоторые из типов сообщений, показанных выше, такие как Ping и Set Client / Server Bandwidth, считаются сообщениями протокола RTMP низкого уровня, которые не используют формат кодирования AMF. С другой стороны, командные сообщения, будь то AMF0 (тип сообщения 0x14) или AMF3 (0x11), используют формат и имеют общую форму, показанную ниже:

(Строка) <Имя команды> (Число) <Идентификатор транзакции> (Смешанный) <Аргумент> напр. Null, String, Object: {key1: value1, key2: value2 ...}

Идентификатор транзакции используется для команд, которые могут иметь ответ. Значение может быть либо строкой, как в приведенном выше примере, либо одним или несколькими объектами, каждый из которых состоит из набора пар ключ / значение, где ключи всегда кодируются как строки, а значения могут быть любого типа данных AMF, включая сложные типы, такие как массивы.

Структура управляющего сообщения (0x04)

Управляющие сообщения не кодируются AMF. Они начинаются с идентификатора потока 0x02, что подразумевает полный заголовок (тип 0) и имеет тип сообщения 0x04. За заголовком следуют шесть байтов, которые интерпретируются как таковые:

# 0-1 - Тип управления.
# 2-3 - Второй параметр (имеет значение в определенных типах управления)
# 4-5 - Третий параметр (то же)

Первые два байта тела сообщения определяют тип Ping, который, очевидно, может^[11] возьмите шесть возможных значений.

Тип 0 - Clear Stream: отправляется, когда соединение установлено и не несет дополнительных данных
Тип 1 - Очистить буфер.
Тип 2 - Stream Dry.
Тип 3 - буферное время клиента. Третий параметр содержит значение в миллисекундах.
Тип 4 - Сбросить поток.
Тип 6 - Пинг клиента с сервера. Второй параметр - текущее время.
Тип 7 - Pong ответ от клиента. Второй параметр - это время, когда клиент получает пинг.
Тип 8 - UDP-запрос.
Тип 9 - ответ UDP.
Тип 10 - Предел пропускной способности.
Тип 11 - Пропускная способность.
Тип 12 - Дроссельная заслонка.
Тип 13 - поток создан.
Тип 14 - поток удален.
Тип 15 - Установить доступ для чтения.
Тип 16 - Установить доступ для записи.
Тип 17 - Мета-запрос потока.
Тип 18 - Мета-ответ потока.
Тип 19 - Получить границу сегмента.
Тип 20 - Установить границу сегмента.
Тип 21 - при отключении.
Тип 22 - Установить критическую ссылку.
Тип 23 - Отключить.
Тип 24 - Обновление хэша.
Тип 25 - Тайм-аут хеширования.
Тип 26 - запрос хеширования.
Тип 27 - Хеш-ответ.
Тип 28 - проверьте пропускную способность.
Тип 29 - Установить доступ к аудио образцу.
Тип 30 - Установить доступ к образцу видео.
Тип 31 - Дроссельная заслонка.
Тип 32 - Дроссельная заслонка.
Тип 33 - уведомление DRM.
Тип 34 - RTMFP Sync.
Тип 35 - Запрос IHello.
Тип 36 - Нападающий Привет.
Тип 37 - перенаправить IHello.
Тип 38 - уведомить EOF.
Тип 39 - Продолжить прокси.
Тип 40 - Удаление прокси-сервера в восходящем направлении.
Тип 41 - RTMFP Set Keepalive.
Тип 46 - сегмент не найден.

Понг - это имя ответа на Ping со значениями, указанными выше.

Структура сообщения ServerBw / ClientBw (0x05, 0x06)

Это относится к сообщениям, которые связаны с битрейтом восходящего потока клиента и нисходящего потока сервера. Тело состоит из четырех байтов, показывающих значение полосы пропускания с возможным расширением на один байт, который устанавливает тип ограничения. Он может иметь одно из трех возможных значений: жесткий, мягкий или динамический (мягкий или жесткий).

Установить размер блока (0x01)

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

Протокол

Диаграмма установления связи RTMP

Рукопожатие

После установления TCP-соединения сначала устанавливается RTMP-соединение, выполняя рукопожатие путем обмена тремя пакетами с каждой стороны (также называемых Chunks в официальной документации). В официальной спецификации они упоминаются как C0-2 для пакетов, отправленных клиентом, и S0-2 для стороны сервера соответственно, и их не следует путать с пакетами RTMP, которыми можно обмениваться только после завершения рукопожатия. Эти пакеты имеют собственную структуру, а C1 содержит поле, устанавливающее временную метку «эпохи», но, поскольку это может быть установлено в ноль, как это сделано в реализациях сторонних производителей, пакет можно упростить. Клиент инициализирует соединение, отправляя пакет C0 с постоянным значением 0x03, представляющим текущую версию протокола. Он следует прямо с C1, не дожидаясь получения S0 первым, который содержит 1536 байтов, причем первые четыре представляют временную метку эпохи, вторые четыре все равны 0, а остальные являются случайными (и которые могут быть установлены на 0 в третьей стороне реализации). C2 и S2 являются отражением S1 и C1 соответственно, за исключением того, что вторые четыре байта являются временем получения соответствующего сообщения (вместо 0). После получения C2 и S2 рукопожатие считается завершенным.

Соединять

На этом этапе клиент и сервер могут согласовывать соединение, обмениваясь AMF закодировано Сообщения. К ним относятся пары ключ-значение, которые относятся к переменным, которые необходимы для установления соединения. Пример сообщения от клиента:

(Вызвать) "соединять"(Сделка Я БЫ) 1.0(Объект1) { приложение: "образец", flashVer: «MAC 10,2,153,2», swfUrl: ноль,              tcUrl: "rtmpt: //127.0.0.1/sample", fpad: ложный,              возможности: 9947.75 , audioCodecs: 3191, videoCodecs: 252,              видеоФункция: 1 , pageUrl: ноль, objectEncoding: 3.0 }

Flash Media Server и другие реализации используют концепцию «приложения» для концептуального определения контейнера для аудио / видео и другого контента, реализованного в виде папки в корне сервера, которая содержит медиа-файлы для потоковой передачи. Первая переменная содержит имя этого приложения как «образец», которое является именем, предоставленным сервером Wowza для их тестирования. В flashVer строка такая же, как возвращаемая Action-скриптом getversion () функция. В audioCodec и видео кодек закодированы как удваивается и их значение можно найти в оригинальной спецификации. То же верно и для видеоФункция переменная, которая в данном случае является самоочевидной константой SUPPORT_VID_CLIENT_SEEK. Особый интерес представляет objectEncoding который определит, будет ли остальная часть сообщения использовать расширенный AMF3 формат или нет. Поскольку версия 3 является текущей версией по умолчанию, флэш-клиент должен явно указать в коде сценария действия использовать AMF0, если это требуется. Затем сервер отвечает последовательностью сообщений ServerBW, ClientBW и SetPacketSize, за которыми, наконец, следует Invoke с примером сообщения.

(Вызвать) "_результат"(сделка Я БЫ) 1.0(Объект1) { fmsVer: «ФМС / 3,5,5,2004», возможности: 31.0, Режим: 1.0 }(Объект2) { уровень: "положение дел", код: "NetConnection.Connect.Success",                   описание: «Соединение успешно»,                   данные: (множество) { версия: "3,5,5,2004" },                   ID клиента: 1728724019, objectEncoding: 3.0 }

Некоторые из приведенных выше значений сериализованы в свойства универсального объекта Action-script, который затем передается прослушивателю событий NetConnection. В ID клиента установит номер для сеанса, который будет запущен соединением. Кодировка объекта должна соответствовать ранее установленному значению.

Проиграть видео

Чтобы запустить видеопоток, клиент отправляет вызов createStream, за которым следует сообщение ping, за которым следует вызов play с именем файла в качестве аргумента. Затем сервер ответит серией команд onStatus, за которыми следуют видеоданные, инкапсулированные в сообщениях RTMP.

После того, как соединение установлено, медиа отправляется путем инкапсуляции содержимого Теги FLV в сообщения RTMP типа 8 и 9 для аудио и видео соответственно.

HTTP-туннелирование (RTMPT)

Это относится к версии протокола с туннелированием HTTP. Он обменивается данными через порт 80 и передает AMF данные внутри запроса и ответов HTTP POST. Последовательность подключения следующая:

ПОЧТОВЫЙ / fcs / identity2 HTTP/1.1Тип содержимого: приложение / x-fcs  r  nHTTP / 1.0 404 не найдено

ПОЧТОВЫЙ / open / 1 HTTP/1.1Тип содержимого: приложение / x-fcs  r  nHTTP / 1.1 200 OK Тип содержимого: application / x-fcs  r  n 1728724019

Первый запрос имеет / fcs / identity2 путь и правильный ответ - ошибка 404 Not Found. Затем клиент отправляет запрос / open / 1, где сервер должен ответить сообщением 200 ok, добавив случайное число, которое будет использоваться в качестве идентификатора сеанса для упомянутого сообщения. В этом примере в теле ответа возвращается 1728724019.

ПОЧТОВЫЙ / простаивает / 1728724019/0 HTTP/1.1HTTP / 1.1 200 ОК   0x01

Отныне / idle / <идентификатор сеанса> / <номер последовательности> - это запрос на опрос, в котором идентификатор сеанса был сгенерирован и возвращен сервером, а последовательность - это просто число, которое увеличивается на единицу для каждого запроса. Соответствующий ответ - 200 OK с целым числом, возвращенным в теле, обозначающим интервал времени. AMF данные отправляются через / send / <идентификатор сеанса> / <номер последовательности>

Программные реализации

RTMP реализуется на трех этапах:

Кодировщик живого видео
Сервер потоковой передачи мультимедиа в реальном времени и по запросу
Живой клиент и клиент по запросу

rtmpdump

Клиентский инструмент командной строки RTMP с открытым исходным кодом rtmpdump предназначен для воспроизведения или сохранения на диск полного потока RTMP, включая RTMPE протокол, который Adobe использует для шифрования. RTMPdump работает на Linux, Android, Solaris, Mac OS X, и большинство других операционных систем Unix, а также Microsoft Windows. Первоначально поддерживая все версии 32-битной Windows, включая Windows 98, начиная с версии 2.2 программное обеспечение будет работать только в Windows XP и выше (хотя более ранние версии остаются полностью функциональными).

Пакеты rtmpdump набор программного обеспечения доступен в основных репозиториях с открытым исходным кодом (дистрибутивы GNU / Linux). К ним относятся интерфейсные приложения «rtmpdump», «rtmpsrv» и «rtmpsuck».

Разработка RTMPdump была возобновлена в октябре 2009 г. за пределами США, в MPlayer сайт.^[12] В текущей версии значительно улучшена функциональность, и она была переписана, чтобы воспользоваться преимуществами Язык программирования C. В частности, основная функциональность была встроена в библиотеку (librtmp), которую могут легко использовать другие приложения. Разработчики RTMPdump также написали поддержку librtmp для MPlayer, FFmpeg, XBMC, cURL, VLC и ряд других программных проектов с открытым исходным кодом. Использование librtmp обеспечивает этим проектам полную поддержку RTMP во всех его вариантах без каких-либо дополнительных усилий по разработке.

FLVstreamer

FLVstreamer - это форк RTMPdump, без кода, который, как утверждает Adobe, нарушает DMCA в США. Это было разработано как ответ на попытку Adobe в 2008 году подавить RTMPdump. FLVstreamer - это клиент RTMP, который сохранит поток аудио- или видеоконтента с любого сервера RTMP на диск, если шифрование (RTMPE) не включено для потока.

Смотрите также

Защищенная потоковая передача Информация о RTMPS и RTMPE
Видео по запросу (VoD)

внешняя ссылка

Страница разработчика Adobe - RTMP - официальная спецификация

[RTMPE_overview-1] «RTMPE». Справка по Adobe Flash Lite 4. Adobe. Получено 29 декабря 2013.

[:0-2] а ^б "TheRealTimeWeb.com: Adobe Patents RTMP". www.therealtimeweb.com.

[3] «Использование сервисов RPC в Flex Data Services 2». Архивировано из оригинал 3 апреля 2007 г.. Получено 16 апреля 2007. Цитировать журнал требует | журнал = (помощь)

[4] Х. Пармар, М. Торнбург (ред.) Протокол обмена сообщениями Adobe в реальном времени, Adobe, 21 декабря 2012 г.

[5] «Спецификация протокола обмена сообщениями в реальном времени (RTMP)». Получено 8 мая 2014.

[6] Лицензия на спецификацию RTMP Опубликовано в апреле 2009 г.

[7] Шумахер-Расмуссен, Эрик (27 мая 2011 г.). «Wowza отрицает утверждения Adobe о нарушении патентных прав». streamingmedia.com.

[8] Лоулер, Райан (31 мая 2011 г.). "Wowza стреляет в Adobe в патентном иске Flash". gigaom.com.

[9] "ADOBE SYSTEMS INCORPORATE - № C 11-2243 CW. - 20120907565 - Leagle.com". leagle.com.

[10] Wowza Media Systems и Adobe Systems урегулировали патентные дела http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases

[11] Проект Red5 (2009) Пинг. Доступна с: http://trac.red5.org/wiki/Documentation/Tutorials/Ping. Доступ: 25 декабря 2011 г.

[12] «Обновления: 01.11.2009». Получено 1 ноября 2009.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]