Лекции_Мультимедийные ИС
.docxРасширение stack протоколов TCP/IP поддержки распределённых мультимедийных приложений:
Поддержка мультикаста. Самое простое – рассылка пакетов по заданным адресам, т.е., host, который готов послать сообщение в режиме мультикаста, информирует их посредством протокола IGMP и производит доставку. Если есть транзитный маршрутизатор (т.е., есть выход за пределы сегмента), то необходимо воспользоваться алгоритмами, такими как: flooding, spanning tree и reverse path broadcasting, reverse path multicasting. Эти алгоритмы используются в таких протоколах, как: DVMRP, MOSPR, PEM. На основе этих протоколов маршрутизатор мультикаста решает, куда отправить пакет. Также, возможно организовать мультикаст с помощью технологии MBONE. MBONE – это виртуальная сеть, создаваемая над фрагментами Internet. В ней острова мультикаста связаны друг с другом виртуальными ссылками (туннелями). По этим туннелям передаётся сообщение мультикаста и для передачи эти туннели инкапсулируются по методу «IP-over-IP».
Управление сессиями. Для управления сессиями стандартизированы следующие протоколы:
Протокол описания сессии (SDP). SDP кодирует описание сессии в текстовом формате. SDP состоит из серии строк (поля). Имя поля – одна буква. Поля заданы в строгом порядке, поэтому буквы совпадают. Поля заполняются по шаблону: имя поля = значение, v = 0, где v – номер версии.
Протокол оповещения о сессии (SAP). Данный протокол используется для оповещения о предстоящей сессии мультикаста. SAP периодически рассылает пакеты оповещения всем зарегистрированным участникам по их адресам и портам (обычно, порт 9875). Одну сессию могут анонсировать несколько оповещателей. При этом, гарантируется надёжность доставки. Период времени между оповещениями выбирается так, чтобы суммарный поток сообщений в сети, используемый всеми оповещателями из одной группы SAP, находился бы ниже предварительно настроенного предела. Каждый оповещатель получает другие оповещения, чтобы определить общее число сессий в конкретной группе, и SAP объявляет о предстоящих сессиях и начинает работу задолго до её старта.
Протокол идентификации сессий. В сети каждый поток идентифицируется кортежем (адрес источника назначения, порт источника назначения, адрес сети получателя, порт сети получателя, протокол). На рис.7 представлен кортеж с обозначениями.
Рис.7 – Кортеж для идентификации потока в сети
Т.е., для каждой сессии устанавливается индивидуальный сокет. Сокет – это объект, являющийся конечным элементом соединения и обеспечивающий взаимодействие между процессами транспортного уровня. Если необходимо объединить несколько сессий вместе, то доступный механизм отсутствует. Таким образом, необходимо мультиплексирование различных потоков в одном сокете. Данная функция аналогична тому, что происходит на сеансовом уровне, а идентификацию сессий можно сделать с помощью протокола RTP.
RTP запускается в верхней части UDP. Т.е., фрагмент данных инкапсулируется в пакет RTP, который, в свою очередь, инкапсулируется в UDP. RTP обеспечивает:
Упорядочивание - пакет RTP включается в поле номера пакета, что помогает предотвратить его потерю.
Идентификация передаваемой информации – используется для динамического изменения схем кодирования данных и при необходимости изменения пропускной способности. Данный идентификатор включается в каждый пакет RTP для обеспечения функциональности.
Индикация фреймов (фрейм – логическая единица для пересылки звука и видео). Для индикации фрейма используется маркет-фрейм.
Идентификация источников – для идентификации автора фрейма в условиях мультикаста используется идентификатор SSRC.
Синхронизация фрагментов мультимедиа – в рамках одного потока RTP используются метки времени, необходимые для организации работы буфера проигрывания.
Чтобы описать тип мультимедиа и схемы сжатия, в пакет может быть вставлены два поля: заголовок профиля и расширение.
RTCP (Real Time Control Protocol) – это протокол управления, который работает совместно с RTP, обеспечивает участников сессии статистикой (количество переданных и потерянных пакетов, показатели нестабильности работы сети, время полной передачи). Также, в пакет RTCP можно включать адреса почты, имена, телефоны для идентификации.
RTSP (Real Time Streaming Protocol) – это внешний управляющий протокол, который позволяет конечному пользователю останавливать и перематывать видео-контент.
Работа RTP над UDP обеспечивает дополнительную функциональность, требуемую для перестановки UDP пакетов и использовании в них меток времени. Но ограничение протокола UDP не преодолеваются, т.к. нет гарантии доставки переданных пакетов получателю, а использование TCP (гарантия отсутствия ошибок) создаёт серьёзные задержки во времени (трудно использовать в реальном времени).
Безопасность. Для безопасной передачи данных используется протокол IpSec (IP Security), который отделяет политику от применения. Политика — это какой поток надо кодировать и каким образом. Она обеспечивается системным администратором, а применение проводится с использованием набора протоколов.
Политики помещаются в виде правил в SPD (Secure Policy Database). SPD используется каждым пакетом, а IpSec определяет каждый раз, что с этим делать: либо к нему необходимо применить механизм IpSec, либо он должен быть отброшен, либо пакет пересылается дальше без изменения.
Если администратор конфигурирует SPD для отдельных потоков, то IpSec сначала обрабатывает параметры безопасности потока от предыдущего узла, в рез-те образуется соглашение по безопасности SA (Security Association).
SA содержит тип механизма, который может быть применён AH или ESP. Основная функция AH (Authenticated Header) – установление аутентичности отправителя для получателя. AH не шифрует поток данных. Данный механизм может применяться в новостных сайтах.
Преимущества AH:
Создаёт меньшую добавку к основному трафику, чем ESP. ESP (Encapsulating Security Payload) – это протокол из набора IPSec, который обеспечивает как аутентификацию участников, так и шифрование данных в пакетах IP. Так как кодируется каждый пакет, то происходит повышенная нагрузка. IpSec работает как в транспортном, так и в туннельном режиме.
В транспортном защищаемом пакете сохраняется IP-заголовок, а модифицируется только часть верхнего уровня, куда добавляется заголовок IPSec и требуемый тип защиты между верхними уровнями и оригинальным заголовком пакета IP.
В туннельном режиме IpSec рассматривает весь пакет как блок данных, добавляя новый заголовок пакета и защищая данных путём кодирования. В IpSec легко интегрируется ОС. Для поддержки мобильности используется протокол MobileIP, целью которого является обеспечение соединения вне зависимости от места расположения.
Сайт, который позволяет пользователю перемещаться, должен создать HA (Home Agent), а каждый сайт, который хочет, чтобы его посещали, должен создать FA (Foreign Agent).
Когда мобильный хост заходит на сайт, поддерживающий роуминг, он контактирует с FA этого сайта. FA в свою очередь контактирует с HA мобильного хоста, поэтому все пакеты, которые предназначаются для мобильного хоста, в конечном итоге достигнут HA, который инкапсулирует пакеты внутри другого пакета IP и передаёт его FA. FA их декапсулирует и передаёт пакет мобильному хосту.
Стандарт H.323 обеспечивает преобразование формата данных, расшифровку управляющих сигналов, преобразование аудио- и видеокодеков, вызов или прекращение функциональности.
Стандарт H.323 определяет 4 компонента:
Терминалы (конечные точки)
Шлюз (необходим в случае конференции с разными клиентами на базе H.32x)
Gate Keeper (обеспечивает контроль доступа и управление пропускной способностью.). Терминалы должны получить доступ от Gate Keeper для передачи своих сообщений.
MCU (Multipoint Control Unit) – опциональная компонента, которая обеспечивает проведение конференций типа «point – multipoint» для сети по стандарту H.323. MCU состоит из обязательного Multipoint Controller (MC) и опционального Multipoint Processor (MP). MC определяет общие возможности терминалов, используя стандарт H.245, но он не позволяет мультиплексировать звук, видео и данные. Мультиплексирование потоков управляется MP под контролем MC. Мультиплексация потоков управляется MP под контролем MC.
Рис.7 – Сеть H.323 с различными компонентами
В сеть под управлением H.323 могут входить:
Протокол H.225 (RAS, Registration Admition Status). Используется терминалами и шлюзами для обнаружения Gate Keeper, проведения у него регистрации, запрашивание прав на сообщение, выделение пропускной способности. Gate Keeper может использовать данный протокол для запросов на соседние шлюзы.
Протокол Q.931. Используется для установки соединения и разъединения двух конечных элементов.
Протокол H.245, использующийся для рассмотрения возможности передачи мультимедиа, которые будут использовать для каждого типа носителя и определения отношений подчинённости.
Рекомендация T.120. Используется при проведении конференции в реальном времени для разделения и использования приложений, передачи файлов и текущих сообщений.
Настройка конференции H.323 с Gate Keeper делается по схеме, представленной на рис.8.
Рис.8 – Схема настройки конференции H.323 с Gate Keeper
В H.323 поддерживаются два типа соединения: прямое и через Gate Keeper.
Для прямого все сигнальные сообщения Q.931 и H.245 пересылаются напрямую между двумя конечными элементами H.323 как потоки RTP. До тех пор, пока вызывающий конечный элемент знает транспортный адрес вызываемого элемента, он может поддерживать режим прямого соединения. Если крупная конференция – такая модель не подходит, так как не известно, кто является организатором конференции.
Если с Gate Keeper, то все сигнальные сообщения проходят через него и тогда необходимо использовать H.225 RAS.
Следующий протокол – это протокол SIP (сигнальный протокол уровня приложений), предназначенный для создания, модификации и завершения сессии мультимедиа с одним или несколькими участниками.
SIP не определяет содержание сессии, зависит и не зависит от передаваемого контента. Установка соединения делится на 4 этапа:
Инициализация сессии. Начало сессии – самая сложная часть, поскольку необходимо определить кол-во участников и адрес участника (электронная почта).
Доставка описания сессии. Для этого используется протокол SDP (Session Description Protocol).
Управление сессией. После отправки описания SIP передаёт запрос на запуск сеанса соответствующему узлу. Если ответ принять, то сессия активна. Для транспортировки данных в реальном времени используются протоколы RTP и RTCP.
Завершение сессии. SIP – это только сигнальный протокол, который используется совместно с протоколами SDP, RTP и RTCP.
Сигнальная система SIP состоит из след. элементов:
Пользовательские агенты (User Agent, UA) – это элементы системы, действующие от имени конечного пользователя. Выделяют UAC (пользовательские агенты-клиенты, которые инициируют запросы SIP) и UAS (пользовательские агенты-серверы, которые получают запросы и возвращают ответы).
Сетевые серверы (Network Servers, NS). Выделяют три типа серверов: сервер регистрации (отслеживает местоположение пользователя), прокси-сервер (маршрутизатор уровня приложений, который получает запрос SIP и пересылает дальше) и перенаправляющий сервер (получает запросы, возвращает местоположение другого пользовательского агента и сервера). Чаще всего, эти три компонента реализуются единой программой.
SIP основан на модели «запрос-ответ» типа HTTP. Все запросы и ответы используют текстовое представление. Для этого, используются основные команды Invite (приглашение пользователя), ACK (обмен приглашениями), BYE (завершение сеанса между двумя точками), Cancel (завершение поиска пользователей), Options (получение информации о параметрах вызова) и Register (получение информации о местоположении пользователя для сервера регистрации).
Тело сообщения отделено от заголовка пустой строкой.
Поле Via содержит хост и порт, от которого ожидается ответ. Когда сообщение SIP проходит через множество прокси-серверов, каждый добавляет свой адрес и порт в это сообщение, тем самым, получатель посылает ответ по тому же самому пути.
Поля From и To – это адреса электронной почты (от, кому)
Поле Call-Id – глобальный уникальный идентификатор вызова.
Поля Content-length и Content-type поясняют содержимое тела сообщения.
Если вызывающий клиент хочет пригласить участника на сессию, то:
Клиент SIP создаёт приглашение Invite для какой-то электронной почты, которая посылается на прокси-сервер.
Прокси-сервер пытается получить IP-адреса сервера SIP, который управляет запросами в данном домене.
Прокси-сервер консультируется с Location сервер для определения следующего сервера.
Location сервер не является сервером SIP, запоминает информацию о следующих серверах и возвращает IP-адрес найденного участника.
Получив этот IP-адрес, прокси-сервер пересылает приглашение Invite машине хосту.
При достижении UAS передаётся ответ «ОК» на прокси-сервер.
Если ответ принят, то прокси-сервер посылает «ОК» клиенту.
Клиент подтверждает получение ответа, посылая сообщение ASQ.
Между клиентами устанавливается сессия мультимедиа.
В конце сессии принимающий клиент посылает сообщение BYE.
Посылающий клиент завершает сессию отправкой сообщения BYE.
RTP позволяет передавать информацию и надёжно доставлять информацию по ненадёжным сетям. Это достигается на основе двух принципов:
Фрагментирование информации на уровне приложений
Принцип конечных точек
Фрагментирование на уровне приложений позволяет учесть специфику, следовательно, уменьшить число ошибок. Только приложение оценивает существенность ошибки и принимает решение, устранять её или не устранять.
Принцип конечных точек предполагает ответственность за надёжность передачи и возлагается на отправителя и получателю, а не на промежуточные узлы.
Стандарт RFC 1889 состоит из двух частей:
Протокол передачи данных, который отвечает за доставку данных реального времени между конечными пунктами маршрута
Протокол управления RTCP, который обеспечивает получение информации о качестве принимаемых данных, идентификаторе получателя и синхронизирует потоки.
RTP вводит следующие ограничения:
Не определяет алгоритмы проигрывания аудио и видео
Не определяет восстановление временных характеристик
Не определяет синхронизацию между мультимедиа и потоками
Обнаружение и устранение ошибок
Контроль перегрузок сети
За всё это отвечает разработчик приложения.
Некоторые характеристики передачи открыты и отражают специфику формата передаваемых данных. Ссылка на этот формат данных находится в профиле RTP.
В целом, данная организация позволяет работать с различными кодеками. В формат данных можно включать схемы коррекции, а также опционально следующие элементы:
Сжатие заголовка
Мультиплексирование
При старте сессии определяют, интерактивная сессия или нет. Если интерактивная, то используются протоколы H.323 и SIP, если нет – то RTSP.
Если используется упрощенная модель конференции (одностороннее вещание), то в чистом виде используется протокол RTP с мультивещанием по IP. Для анонсирования сессии используется протокол SAP.Для настройки сессии используется протокол SDP.
В формат сессии обязательно включаются следующие элементы:
Транспортные адреса потоков
Формат и профиль данных
Время активности
Цель сессии
SDP всё это объединяет в файле текстового формата.
Допускается:
Непосредственно передавать этот файл в приложении
Резервирование сетевых ресурсов. Если интегрируемые сервисы используют протоколы RSVP, тогда хост перед началом сеанса передаёт маршрутизатору всю необходимую информацию, а если дифференцирующие сервисы, то информация о требуемом сервисе сама добавляется в пакет.
Сессия – это группа участников, которая обменивается данными по протоколу RTP. Участник сессии может присутствовать в нескольких RTP-сессиях одновременно.
Сессия идентифицируется сетевым адресом и парой портов отправления и получения информации. Эти пары могут быть одинаковыми. В паре два смежных порта (следуют один за другим). Если чётный номер – то порт для данных RTP, а если нечётный (на 1 больше), то RTCP. По умолчанию это порты 5004 и 5005, как для UDP с IP. Приложения могут переопределять данные пары. Сессия может быть либо односторонней либо широковещательной.
Пакет RTP состоит из 4 частей:
RTP-заголовок (обязательный элемент)
Опциональное расширение заголовка
Опциональный заголовок данных
Данные
В заголовок RTP входят:
Номер версии
Дополнения
Расширения
Количество источников
Маркер
Тип проигрываемых данных
Номер последовательности
Идентификатор источника синхронизации (SSRC)
Идентификатор внешних источников, если используется миксер (CSRC)
Так как для RTP сессии используют динамические порты, то необходимо определить, является ли полученный пакет действительным пакетом RTP. Данная задача кажется невыполнимой, так как в пакете отсутствуют обозначения протоколов. Но, применяя анализ последовательности полей заголовка в нескольких пакетах, быстро определяется условия принадлежности пакета к RTP-потоку.
Существует два типа тестов:
Потоковая проверка
Пакетная проверка
Потоковая проверка основана на знании структуры полей заголовка. Если структура похожая, значит, она относится к данному протоколу. Это быстрый вид проверки, поэтому она проводится первой.
Для оставшихся пакетов проводится пакетная проверка, которая основана на знании полей заголовка. Это более медленный вид проверки.
Также, возможно проводить проверку с помощью контрольных RTCP-пакетов, но данная проверка вызывает большие задержки, что может быть недопустимо. Помимо конечных систем, в RTP включаются промежуточные обработчики, которые работают с потоком в процессе его передачи.
Выделяют 2 типа обработчиков:
Транслятор – это промежуточная система, работающая с RTP-данными во время создания источника синхронизации и временной схемой потока данных. Они осуществляют перекодировку между форматами без их смешивания, невидимы для конечных RTP-систем, если отсутствует предварительная информация о кодировке данных.
Типы трансляторов:
Мост (не меняет кодировки, в большинстве случаев не изменяет передаваемый поток). Пример: межсетевые интерфейсы
Транскодеры (основная функция – преобразование кодировки в соответствии со спецификой используемой сети)
Эксплодеры (из одного пакета делают несколько пакетов)
Мерджеры (из нескольких пакетов делают один пакет)
Миксер – это промежуточная система, собирающая RTP-пакеты из нескольких источников и генерирующая на их основе общий пакет, в котором допускается изменение кодировки данных. Так как временные характеристики входящих потоков не синхронизированы, то основная задача синхронизации – ложиться на миксер. Миксеры могут использовать буферы проигрывания для временного хранения потока данных. Миксер использует собственный SSRC, который вставляет формируемый пакет данных. Идентификаторы SSRC из входящих пакетов копируются в SSRC-список выходного пакета.
Протокол RTCP обеспечивает периодическую отчётность о качестве принятых данных, идентификацию получателей, извещение об изменении состава участников сессии, получение информации, необходимой для синхронизации потоков.
RTCP включает в себя три части:
Формат пакетов
Базу данных участников
Временные правила
RTCP предполагает 5 стандартных форматов пакетов и правил управления частотой их пересылки. Каждое изменение отображается в базе данных участников сессии на основе информации, получаемой из пакетов RTCP.
База используется для составления периодических отчётов о качестве принятой информации, синхронизации звука и изображения. Порт RTP имеет чётный номер и если данные передаются по протоколу на порт 5004, то контрольный канал будет работать по порту 5005.
Все участники сессии посылают свои пакеты RTCP и соответственно получают пакеты RTCP от других участников. Информация обратной связи посылается всем участникам либо индивидуально с использованием транслятора либо всем сразу в режиме мультивещания. Таким образом, каждый участник сессии имеет полную информацию о других участниках. В обязательном порядке должно быть присутствие и качество приёма, как опционально имя участника, адрес электронной почты, местоположение и телефон.
Формат пакета RTCP:
Номер версии (v) – 2 байта
Дополнения (p) – 1 бит. Данный бит является индикатором, сделанный операцией дополнения. Если равен единице, то к концу пакета добавляется один или несколько дополнительных байтов, в последнем из которых записано их количество.
Количество элементов (IC). В каждый пакет может быть включено до 31 элемента. Если количество элементов больше, то они делятся на несколько пакетов. Если какому-то типу пакетов не нужна данная информация, то данное поле используется по своему усмотрению.
Тип пакета (PT). Тут указывается один из пяти стандартных типов
Длина пакета (length), следующего за заголовком. Определяется в 32-битных единицах.
Пакеты RTCP никогда не передаются по одиночке. Перед передачей они всегда группируются, тем самым образуя составной пакет. Каждый составной пакет включает в себя один пакет нижнего уровня (UDP с IP) для транспортировки.
Структура составного пакета RTCP представлена на рис.9.
Рис.9 – Структура составного пакета RTCP
Формат пакета RTCP:
Заголовок: версия и дополнение, количество источников и тип проигранных данных длина.
Информация
Дополнение
Форматы:
Отчет получателя
Отчет отправителя
3. пакет SDEC
4.Пакет BY (управление участниками)
5. Пакет APP (приложения)
Номер сессии – 2 бит, 1 бит – дополнение,
Количество элементов – каждый пакет может быть включено до 31 элементов, если больше
Тип пакета – 32 бит единица
Пакеты SDES – могут рассылаться персональные данные (адрес, имя). Если участник сессии, чтоб его присутствие было видно остальным, то мы можем пересылать пакеты избранному кругу. Чтобы достичь конфиденциальность потока – используют шифрование. Нужно различать RTP and RTSP пакеты. Успешность проверки. На корректность влияет проверка пакетов но и самого потока.
Нужно выделять особенности:
все пакеты – составные, поле версии пакетов – одно значение версии, тип поля составного пакета должен быть со значением sr(отчет отправитель/получатель) или ss. Дополняется только последний пакет, сумма значений полей длины отдельных пакетов = длина составного пакета.
Каждое приложение в rtp сессии, создает БД, а
Размер покате, время последней отсылки rtsp пакета, участники сессии
Буфер накопления перед мульмед инф перед проигрыванием, инфа для кодирования канала и обнаружение ошибок.
Если пакет rtcp получен и проверки, то участник добавляется в БД
При добавлении нового участника увеличивается их на уровень сессии, что может служить повторным просмтром trcp пакетом
Участник удаляется из базы, если получен пакет bye. Но нет гарантий, что пакеты поступают последовательно от одного участника. Пакет bye может быть получен до того, как получен ласт пакет в отчетный интервал.
Правило передачи: интервал между пакетами определяется случ образом в границах от 0.5-1.5 от вычисленного отчетного интервала, исходя из размеров сессии. Для первого пакета берется половина отчетного интервала для обеспечения быстрой и обратной связи с пользователем.
g.711 – алгоритм сжатия кодек
устройства захвата мультимедиа – микрофон/видеокамера
sample – выходной уровень звука в данный момент
Среднее время ожидания очередного пакета RTCP участником называется отчетным интервалом.
На его значение влияют следующие факторы:
пропускная способность канала, выделенная под RTCP. Обычное значение – 5 % от скорости передачи данных в сессии. Последняя устанавливается до сессии и служит параметром ее конфигурирования;
средний размер передаваемых и получаемых RTCP пакетов.
В этот размер входят не только передаваемые данные, но и UDP и IP заголовки;