МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

_______________________________________________________________________________________

Е.С. Чердынцев

МУЛЬТИМЕДИЙНЫЕ СЕТИ

Допущено Учебно-методическим объединением

по профессионально-педагогическому образованию в качестве учебного пособия для магистров направления 230100

«Информатика и вычислительная техника»

Издательство Томского политехнического университета

2011

2

УДК 681.327.1 (0.75.8)

ББК 32.973.202 Я73

Ч 459

Чердынцев Е.С. Ч 459 Мультимедийные сети: Учебное пособие. – Томск: Изд-во

Томского политехнического университета, 2011. – 97 с.

В пособии рассмотрены вопросы, связанные с передачей мультимедийной инфор-

мации по глобальным сетям, включая основы мультимедиа, требования по передаче

потоков мультимедиа, стандарты и протоколы, удовлетворяющие требованиям пе-

редачи таких потоков. Подробно рассмотрен протокол RTP для передачи и контроля

мультимедийных данных, проигрывания, управления временем, синхронизации

звука и изображения, контроля ошибок и перегрузок сети. Предназначено для маги-

стров направления 230100 «Информатика и вычислительная техника».

УДК 681.327.1 (0.75.8)

ББК 32.973.202 Я73

Рецензенты

Доктор технических наук, профессор НИ ИрГТУ

Л.В. Массель

Доктор технических наук, профессор ТПУ

О.Г. Берестнева

Кандидат технических наук, начальник отдела ИТ

ОАО "ТомскНИПИнефть"

А.А. Напрюшкин

© Томский политехнический университет, 2011

© Чердынцев Е.С., 2011

© Оформление. Издательство ТПУ, 2011

3

ОГЛАВЛЕНИЕ

Глава 1. Введение в мультимедиа ................................................................. 6

1.1. Классификация мультимедиа .............................................................. 6 1.2. Текст ...................................................................................................... 7 1.3. Звук ........................................................................................................ 8 1.4. Графика и анимация ............................................................................. 9 1.5. Видео.................................................................................................... 11 1.6. Требования к передаче мультимедиа по сетям ............................... 11

1.6.1. Характеристики реального времени (ограничения на задержки

и нестабильность) .................................................................................. 12 1.6.2. Требование высокой пропускной способности ........................ 12 1.6.3. Требования к ошибкам ................................................................ 13 1.6.4. Поддержка мультикаста .............................................................. 14 1.6.5. Управление сессиями .................................................................. 14 1.6.6. Безопасность ................................................................................. 15 1.6.7. Поддержка мобильности ............................................................. 15

Глава 2. Поддержка распределенного мультимедиа трафика в Интернете

......................................................................................................................... 16 2.1. Поддержка трафика реального времени в Интернете .................... 16

2.1.1. Задержки при обработке пакетов ............................................... 16 2.1.2. Задержки при передаче пакетов ................................................. 16 2.1.3. Задержка передачи ....................................................................... 17 2.1.4. Задержки маршрутизации и обработки очередей .................... 17

2.2. Требование высокой пропускной способности............................... 18 2.3. Отклонения характеристик сети ....................................................... 19 2.4. Предлагаемые модели сервисов Интернет ...................................... 19

2.4.1. Уточнение требований к сервисам и описанию трафика ........ 19 2.4.2. Управление доступом .................................................................. 21 2.4.3. Управление трафиком ................................................................. 22 2.4.4. Классификация пакетов............................................................... 22 2.4.5. Планирование пакетов ................................................................. 23 2.4.6. Потеря пакетов ............................................................................. 23 2.4.7. Маршрутизация на основе QoS .................................................. 23

2.5. Интегрированные сервисы ................................................................ 24 2.5.1. Классы гарантированного обслуживания ................................. 26 2.5.2. Сервис управления загрузкой ..................................................... 27 2.5.3. Сервис негарантированной доставки ......................................... 27 2.5.4. Недостатки модели Intserv для Интернета ................................ 27

4

2.6. Дифферецированный сервис ............................................................. 28 2.6.1. Per Hop Behavior (PHB) ............................................................... 29

2.7. Мультипротокольная коммутация по меткам ................................. 30 Глава 3. Расширение стека протоколов TCP/IP для поддержки

функциональных требований распределенных мультимедийных

приложений ................................................................................................... 32 3.1. Поддержка мультикаста .................................................................... 32 3.2. Управление сессиями ......................................................................... 33 3.3. Безопасность ....................................................................................... 36 3.4. Мобильность ....................................................................................... 37 3.5. H.323 .................................................................................................... 37 3.6. Session Initiation Protocol (SIP) .......................................................... 41

Глава 4. Введение в RTP .............................................................................. 45 4.1. Базовые принципы RTP ..................................................................... 45 4.2. Стандартные элементы RTP .............................................................. 45 4.3. Связанные с RTP стандарты .............................................................. 46 4.4. Сессии RTP ......................................................................................... 48 4.5. Структура пакета RTP ........................................................................ 48 4.6. Проверка качества пакета .................................................................. 49 4.7. Трансляторы и миксеры ..................................................................... 49

Глава 5. Описание протокола RTCP ........................................................... 51 5.1. Компоненты RTCP ............................................................................. 51 5.2. Передача пакетов RTCP ..................................................................... 51 5.3. Формат пакетов RTCP ....................................................................... 51 5.4. Безопасность и конфиденциальность ............................................... 53 5.5. Проверка корректности данных ........................................................ 54 5.6. База данных участников сессии ........................................................ 56 5.7. Управление характеристиками времени .......................................... 58

5.7.1. Отчетные интервалы .................................................................... 59 5.7.2. Базовые правила передачи .......................................................... 59 5.7.3. Процедура пересмотра вперед .................................................... 59 5.7.4. Процедура пересмотра назад ...................................................... 60 5.7.5. Пересмотр пакетов BYE .............................................................. 60 5.7.6. Общие проблемы реализации ..................................................... 61

Глава 6. Захват мультимедиа, проигрывание и управление

характеристиками времени .......................................................................... 62 6.1. Поведение отправителя ..................................................................... 62 6.2. Захват мультимедиа и сжатие ........................................................... 62

6.2.1. Захват и сжатие звука .................................................................. 63 6.2.2. Захват и сжатие изображения ..................................................... 64 6.2.3. Использование предварительно записанной информации ...... 65

5

6.3. Генерация пакетов RTP ..................................................................... 65 6.3.1. Метки времени и модель времени RTP ..................................... 66 6.3.2. Фрагментация ............................................................................... 67 6.3.3. Заголовки, зависящие от формата данных ................................ 67

6.4. Поведение получателя ....................................................................... 68 6.5. Получение пакетов ............................................................................. 68

6.5.1. Получение пакетов данных ......................................................... 69 6.5.2. Получение управляющих пакетов .............................................. 71

6.6. Буфер проигрывания .......................................................................... 73 6.7. Декодирование, смешивание и проигрывание ................................ 73

6.7.1. Декодирование ............................................................................. 73 6.7.2. Смешивание звука ....................................................................... 74

Глава 7. Синхронизация звука и изображения .......................................... 75 7.1. Поведение отправителя ..................................................................... 75 7.2. Поведение получателя ....................................................................... 77 7.3. Точность синхронизации ................................................................... 79

Глава 8. Компенсация ошибок..................................................................... 80 8.1. Компенсация потерь звука ................................................................ 80

8.1.1. Измерение качества звука ........................................................... 80 8.1.2. Замещение периодами тишины .................................................. 81 8.1.3. Замещение шума .......................................................................... 81 8.1.4. Повторение ................................................................................... 82

8.2. Компенсация потерь изображения ................................................... 83 8.2.1. Компенсация передвижения ....................................................... 84

8.3. Чередование (Interleaving) ................................................................. 84 Глава 9. Исправление ошибок и контроль перегрузок ............................. 86

9.1. Прямое исправление ошибок ............................................................ 86 9.1.1. Контроль четности ....................................................................... 86 9.1.2. Неравномерная защита от ошибок ............................................. 88 9.1.3. Коды Рида-Соломона................................................................... 89 9.1.4. Избыточное кодирование звука.................................................. 89

9.2. Кодирование канала ........................................................................... 89 9.3. Повторная передача ........................................................................... 90 9.4. Контроль перегрузок .......................................................................... 90

9.4.1. Необходимость контроля перегрузок ........................................ 90 СПИСОК ЛИТЕРАТУРЫ ............................................................................ 93

6

Глава 1. Введение в мультимедиа

Термин ‘мультимедиа’ применяется к различным классам пред-

ставления информации. Составляющие мультимедиа могут быть разби-

ты на три основные группы: текстовая, визуальная и звуковая информа-

ция. Текстовая информация – это не только текст в чистом виде, но

также и форматированный текст с различными управляющими симво-

лами, математическими выражениями, фонетическими транскрипциями

произношения, нотными знаками и гипертекстом. Визуальная инфор-

мация может включать рисованные линии, карты, изображения или фо-

тографии, анимацию, объекты виртуальной реальности, видео- и теле-

конференции. Звуковая информация может быть представлена голо-

совой информацией телефонного или широковещательного качества,

музыкальными фрагментами или записями биометрических звуковых

сигналов. Текстовая составляющая мультимедиа обычно уже представ-

лена в цифровой форме, тогда как визуальная и звуковая информация

часто требует преобразования из аналоговой формы с использованием

соответствующих технологий.

1.1. Классификация мультимедиа

С точки зрения передачи мультимедиа она может быть классифи-

цирована на передаваемую в реальном времени (Real-Time – RT) или

не в реальном времени (Non Real-Time – NRT). Мультимедиа первого

типа (RT) требует ограничений на задержку пакетов, в то время как

мультимедиа второго типа (например, текст и изображение) таких огра-

ничений не требует, но может иметь жесткие ограничения на наличие

ошибок при передаче. Существует два основных подхода к контролю

ошибок при передаче мультимедийной информации [1]. Первый осно-

ван на автоматическом повторе передачи потерянных или поврежден-

ных пакетов (Automatic Retransmission reQuest – ARQ). Этот подход

используется в протоколе транспортного уровня TCP (Transport Con-

trol Protocol) в стеке протоколов TCP/IP. Приложения, требующие без-

ошибочной передачи NRT информации, обычно используют именно

этот протокол. При втором подходе (Forward Error Correction – FEC)

– передается избыточная информация, позволяющая обнаруживать и

исправлять ошибки без повторной передачи пакетов. Такой подход ис-

пользуется в другом протоколе транспортного уровня UDP (User Data-

gram Protocol) в том же стеке протоколов TCP/IP. Приложения, обме-

нивающиеся мультимедийной информацией, допускающей ошибки (как

7

RT, так и NRT) обычно используют UDP для исключения потерь време-

ни на повторную передачу пакетов. В [2] приводится ряд результатов

экспериментов по использованию FEC в UDP на глобальной широко-

полосной сети STARTAP.

RT мультимедиа разделяется на дискретную (Discrete media – DM)

и непрерывную (Continuous media – CM), в зависимости от того, пере-

даются ли данные дискретными порциями или непрерывным потоком.

В свою очередь СМ может разделяться на допускающую ошибки

и не допускающую их. Примером RT первого типа могут служить зву-

ковые и видео потоки, используемые при проведении звуковых и видео

конференций, а примером второго – приложения, запускаемые на уда-

ленном компьютере. Потоковое вещание, используемое для вещания

через Интернет, допускает некоторый уровень ошибок при передаче

информации. Далее мы рассмотрим некоторые общие типы мультиме-

диа и их характеристики в терминах пропускной способности, допусти-

мых ошибок и специфики режима реального времени.

1.2. Текст

Текст наиболее популярен среди остальных типов мультимедиа. Он

представлен в сети Интернет различными формами, включая файлы или

сообщения, использующие различные протоколы передачи, такие как

FTP (File Transfer Protocol: для передачи двоичных и ASCII файлов),

HTTP (Hyper Text Transfer Protocol: для передачи HTML страниц)

или SMTP (Simple Mail Transfer Protocol: для обмена почтовыми со-

общениями). В двоичном виде текст представляется в 7-битной US-

ASCII, 8-битной ISO-8859, 16-битной Unicode или 32-битной ISO 10646

кодировочных таблицах, в зависимости от используемого языка и стра-

ны. Требования к пропускной способности для текстовой информации в

основном зависят от ее размера, который может быть существенно

уменьшен при использовании различных схем сжатия информации [3]

как показано в таблице 1.1.

Требования к допустимому уровню ошибок при передаче текста

зависят в основном от используемых приложений. Приложения, пере-

дающие текстовые файлы, требуют полного отсутствия ошибок переда-

чи, используя протокол TCP. Другие приложения могут допускать неко-

торый процент ошибочной информации и используют для передачи

протокол UDP.

Приложения, работающие преимущественно с текстом, не имеют

ограничений, связанных с передачей в реальном времени. В тоже время

8

приложения, передающие непрерывный поток сообщений, накладывают

существенные ограничения на величину задержки в их передаче.

Таблица 1.1

Схемы сжатия текста

Схема сжатия Комментарии

Кодирование

Шеннона-Фано

Символы с высокой вероятностью появления заменяются на

более короткие кодовые слова.

Кодирование Ха-

уфмана

Аналогично кодированию Шеннона-Фано.

LZW Замена строки символов единственным кодом. Анализа тек-

ста не проводится. Вместо этого каждая новая строка симво-

лов добавляется в таблицу строк.

Unix сжатие Использует LZW с растущим словарем. Вначале словарь со-

держит 512 элементов и по мере необходимости удваивает-

ся.

1.3. Звук

Звуковая информация представляет собой звуки, преобразованные

в цифровой вид с использованием выборок (sampling) и квантизации

(quantization). Оцифрованный звук передается по сети как поток дис-

кретных пакетов. Требования к пропускной способности сети зависят от

характеристик звука. Например, голос по телефону сжимается с потерей

информации с 12 бит до 8 бит. Это уменьшает скорость передачи с 96

kbps до 64 kbps. Некоторые схемы сжатия [4], как показано в таблице

1.2, часто используются для звуковых файлов.

Звуковая информация не накладывает жестких ограничений на

наличие ошибок в процессе ее передачи. Потеря 1-2 % пакетов практи-

чески не отражается на ее качестве. Сегодня большинство мультиме-

дийных приложений, использующих звук, имеют встроенный механизм

интерполяции потерянных пакетов.

Требования реального времени для звука жестко связаны с ожида-

емым уровнем интерактивности участвующих сторон. Некоторые при-

ложения, такие как Интернет-телефония, подразумевающие двусторон-

нее взаимодействие, имеют высокий уровень интерактивности и требу-

ют коротких времен отклика. В этом случае накладываются жесткие

ограничения на задержку пакетов для обеспечения приемлемого каче-

ства звука. Приложения, использующие такой тип мультимедиа, назы-

вают зависимыми от режима реального времени (Real-Time Intolerant –

RTI). В большинстве RTI приложений допускается задержка не более

200 мс. В других приложениях, таких как Интернет-вещание (webcast),

9

использующих одностороннюю передачу звука, уровень интерактивно-

сти близок к нулю. Интерактивность в этом случае ограничивается ко-

мандами пользователя к смене каналов.

Таблица 1.2

Схемы сжатия звука

Звуковой кодек Использование Скорость

(Kbps)

Кодово-импульсная мо-

дуляция (G.711) Узкополосная речь (300 – 3300 Hz) 64

GSM Узкополосная речь (300 – 3300 Hz) 13

CS-ACELP (G.729) Узкополосная речь (300 – 3300 Hz) 8

G.723.3 Узкополосная речь (300 – 3300 Hz) 6.4 и 5.3

Адаптивная дифферен-

циальная импульсно-

кодовая модуляция

(G.726)

Узкополосная речь (300 – 3300 Hz) 32

SBC (G.722) Широкополосная речь (50 – 7000 Hz) 48/56/64

MPEG layer III (MP3) Широкополосный звук качества CD (10 –

22Khz)

128 – 112

Kbps

1.4. Графика и анимация

В эту группу входят как статичные цифровые изображения, так и

динамические изображения, такие как flash-презентации. Несжатое

цифровое изображение состоит из массива пикселей, где каждый пик-

сель со своими параметрами хранится в определенном количестве битов

памяти. По сравнению с текстом, цифровые изображения требуют

намного больше памяти. Например, изображение размером 4 на 6 дюй-

мов при разрешении экрана 480 на 640 пикселей и 24-битном цвете тре-

бует около одного мегабайта памяти. Передача такого изображения по

сети со скоростью 56.6 Kbps занимает около двух минут. Если изобра-

жение сжато в 10 раз, требуется уже около 100 Кбайт памяти и передача

занимает около 14 секунд. Некоторые популярные схемы сжатия [5]

приведены в таблице 1.3. Большинство современных схем сжатия име-

ют прогрессивный характер, что очень важно при передаче изображе-

ний по коммуникационным сетям [3]. Когда такое изображение получа-

ется, пользователь вначале видит вариант низкого качества, который за-

тем постепенно улучшается. Обычно достаточно принять 5-10% изоб-

ражения, чтобы получить общее представление о нем. Прогрессивное

сжатие достигается:

прогрессивным кодированием часто встречающихся фраг-

ментов изображения;

10

использованием векторной квантизации, начинающей с от-

тенков серого цвета с последовательным добавлением цве-

тов;

использованием пирамидального кодирования, разбиваю-

щего изображение на слои в порядке увеличения разрешения

при росте номера слоя.

Таблица 1.3

Схемы сжатия изображения

Схема сжа-

тия Комментарии

Graphics In-

terchange

Format (GIF)

Поддерживает до 256 цветов. Использует LZW (Lempel-Ziv-

Welch) сжатие без потерь информации с поддержкой анимации.

Portable Net-

work

Graphics

(PNG)

Поддерживает любое количество цветов. Использует схему сжа-

тия zlib, с адаптивным фильтром сжимаемых блоков. Схема с по-

терей информации и без поддержки анимации.

Joint Photo-

graphic Ex-

perts Group

(JPEG)

Наилучшим образом подходит для сжатия цветных и черно-

белых фотографий с большим количеством цветовых оттенков

(или оттенков серого). Этот стандарт сжатия базируется на ис-

пользовании кодирования по Хауфману и кодов длин серий в

процессе дискретного косинусного преобразования коэффициен-

тов блоков изображения. Сжатие происходит с потерей информа-

ции. Стандартный JPEG не разрешает чересстрочную развертку,

но ее поддерживает прогрессивный формат (Progressive JPEG).

Progressive JPEG начинает с укрупненных блоков изображения с

последующей их детализацией.

JPEG2000

Подходит для широкого спектра изображений, поэтому исполь-

зуется в портативных цифровых камерах. Использует внедрен-

ную технику, основанную на вейвлетах (wavelet), хранящих ин-

формацию в потоке данных, а не в блоках. Эта схема также при-

водит к масштабируемой потере информации.

JPEG-LS

Подходит для однотонных изображений. Схема основана на ал-

горитме LOCO-I (Low COmplexity LOssless COmpression for Im-

ages), разработанного HP. Это схема без потери или практически

без потери информации.

Joint Bi-level

Image Experts

Group (JBIG)

Подходит для черно-белых изображений. Использует схему мно-

жественного арифметического кодирования без потери информа-

ции.

Изображения толерантны к некоторому уровню ошибок передачи,

позволяя восстановить потерянную информацию. Кроме того, они не

накладывают ограничений на передачу в реальном времени.

11

1.5. Видео

Видео является последовательностью кадров, показываемых с

определенной скоростью, обычно 24 или 30 кадров в секунду. Цифровое

видео, как и оцифрованный звук, передается по сети потоком дискрет-

ных пакетов. Требования к пропускной способности зависят от уровня

избыточности информации, как в каждом кадре, так и в их последова-

тельности. Оба этих вида избыточности информации могут быть ис-

пользованы для алгоритмов сжатия видео. Таблица 1.4 иллюстрирует

некоторые распространенные [6] схемы сжатия видео.

Таблица 1.4

Схемы сжатия видео

Схема сжа-

тия Комментарии

MPEG-I

Используется для сжатия в формате VCR NTSC (352 x 240) для

записи на CD-ROM (CD-I и CD-Video формат) и скорости пере-

дачи 1.2 Mbps.

MPEG-II

Более общий стандарт для кодирования аудио и видео. Поддер-

живает защиту от ошибок в режиме вещания. Поддерживает сжа-

тие качества вещания (DVB) и High Definition Television (HDTV).

MPEG-2 поддерживает 4 варианта разрешения: низкое (low) (352

x 240), основное (main) (720 x 480), высокое-1440 (high-1440)

(1440 x 1152), и высокое (high) (1920 x 1080). Скорость передачи

данных находится в интервале 3-100 Mbps.

MPEG-IV

Поддерживает сжатие для сетей с малой пропускной способно-

стью (64 Kbps). Это формат, одинаково хорошо сжимающий все

компоненты мультимедиа.

H.261

Поддерживает передачу видео по ISDN на скоростях, кратных 64

Kbps. Схема основана на сжатии как внутри фреймов, так и меж-

ду ними.

H.263 Схема предназначена для передачи видео по беспроводным сетям

с очень низкой пропускной способностью (18-64 Kbps).

Ограничения на наличие ошибок передачи и передачу в реальном

времени аналогичны ограничениям для звука.

1.6. Требования к передаче мультимедиа по сетям

В этом разделе мы рассмотрим требования, накладываемые рас-

пределенными мультимедийными приложениями на передающую сеть.

Они могут быть разбиты на две категории [7] – требования к трафику и

функциональные требования. Первые включают требования реального

времени (задержки и нестабильность, пропускная способность и досто-

12

верность), а вторые включают поддержку сервисов мультимедиа (муль-

тикастинг, безопасность, мобильность и управление сессиями). Требо-

вания к трафику могут быть удовлетворены только расширением базо-

вой архитектуры Интернет, в то время как функциональные требования

можно выполнить введением новых протоколов в стеке протоколов

TCP/IP. Функциональные требования не являются абсолютно необхо-

димыми, в том смысле, что распределенные мультимедийные приложе-

ния могут работать с высокой производительностью путем внедрения

необходимых функций в само приложение.

1.6.1. Характеристики реального времени (ограничения на задержки и неста-бильность)

Как рассматривалось в разделах 1.1- 1.5, такие компоненты муль-

тимедиа, как звук и видео, накладывают требования по передаче в ре-

жиме реального времени. Например, они должны проигрываться с той

же скоростью, с которой они оцифровывались. При любой задержке в

передаче это сразу будет обнаружено. В Интернет-телефонии человек

может спокойно относиться к задержкам не более 200 мс. Таким обра-

зом, передача мультимедиа в реальном времени накладывает жесткие

ограничения на задержку пакетов и нестабильность интервалов их по-

ступления.

1.6.2. Требование высокой пропускной способности

Очевидно, что мультимедийные приложения требуют существенно

более высокой пропускной способности сетей, чем обычные текстовые

приложения, широко распространенные в прошлом. Более того, муль-

тимедийные потоки передаются с использованием протокола UDP, ко-

торый не имеет механизма контроля перегрузок сети. Таблица 1.5 пока-

зывает требования к пропускной способности для наиболее распростра-

ненных типов мультимедиа.

Существует два типа сжатия: с потерей информации и без потери.

В первом случае при сжатии происходит удаление избыточной инфор-

мации из данных, что часто приводит к их искажению или появлению

шумов. Во втором случае информация не теряется и получаемые дан-

ные идентичны отправляемым данным. Обычно сжатие с потерей ин-

формации дает степень сжатия больше, чем сжатие без потери инфор-

мации. Однако в некоторых приложениях потеря информации недопу-

стима (например, при передаче медицинской телеметрии).

13

Таблица 1.5

Требования к пропускной способности для различных элементов муль-

тимедиа

Звук Скорость выборки Битов в вы-

борке

Скорость

в битах

Голос по телефону (до 3.4

КГц) 8000 выборок/сек 12 96 Kbps

Широкополосная речь (до 7

КГц) 1600 выборок/сек 14 224 Kbps

Двусторонняя широкополос-

ная речь (до 20 КГц) 44.1 Kвыборок/сек 16 на канал

1.412

Mbps на

оба кана-

ла

Изображение Пиксели бит/пиксель Битовая

скорость

Цветное изображение 512 x 512 24 6.3 Mbps

CCIR TV 720 x 576 x 30 24 300 Mbps

HDTV 1280 x 720 x 60 24 1.327

Gbps

1.6.3. Требования к ошибкам

Как отмечалось ранее, разные типы мультимедиа имеют разные

требования к наличию ошибок при их передаче по сетям. Ошибки воз-

никают при повреждении или потере пакетов. Большинство приложе-

ний, допускающих ошибки при передаче, используют технику маскиро-

вания ошибок (error concealment techniques – FEC), которая позволяет

восстановить потерянную информацию на основе информации из дру-

гих пакетов.

При использовании FEC в поток пакетов добавляется дополнитель-

ная информация для устранения возможных ошибок. Однако, если в

процессе передачи пакетов появятся ошибки за пределами уровня FEC,

они могут остаться не обнаруженными. Следовательно, для приложения

мультимедиа важно знать тип ошибок в используемых коммуникацион-

ных сетях, чтобы использовать необходимый уровень FEC для обеспе-

чения безошибочной передачи. Например, беспроводные сети требуют

более высокий уровень защиты от ошибок, чем проводные сети, так как

вероятность потери пакетов в них существенно выше. Минимизация по-

вторной посылки пакетов, достигаемая использованием FEC, может

быть слишком дорогой в проводных сетях, так как вероятность потери

пакетов в них достаточно низка. Дополнительные затраты требуются и

на повышение пропускной способности сети для передачи дополни-

тельной информации FEC.

14

1.6.4. Поддержка мультикаста

При мультикасте один источник используется одновременно не-

сколькими получателями мультимедийной информации. Его использу-

ют наиболее популярные распределенные мультимедийные приложе-

ния. Например, видеоконференция с несколькими участниками является

одним из самых широко используемых сервисов в Интернет-телефонии.

Если мультикаст не поддерживается самой сетью, его поддержку долж-

но взять на себя используемое приложение.

Мультикаст легче обеспечить при односторонней передаче инфор-

мации, чем при двусторонней. Например, в случае использования Ин-

тернет-радио мультикаст обеспечивается созданием дерева связи с вер-

шиной у отправителя информации, ветвями – у ее получателей и соот-

ветствующим дублированием пакетов в узлах дерева. Однако в случае

двусторонней коммуникации как, например, в Интернет-телефонии для

нескольких участников, необходимо иметь некоторый функционал для

корректного смешивания голосовых потоков от разных участников. В

противном случае придется поддерживать множество двусторонних ка-

налов связи каждого участника с остальными, что может дать слишком

высокую нагрузку на передающую сеть.

1.6.5. Управление сессиями

Управление сессиями включает:

Описание типа мультимедиа. Эта информация необходима

распределенным мультимедийным приложениям для указания таких

параметров сессии, как тип мультимедиа (звук, видео или данные), схе-

мы кодирования, время начала и окончания сессии, IP адреса использу-

емых хостов и т.д. Часто очень важно описать сессию до ее начала, так

как участники сессии могут иметь разные возможности по приему

мультимедиа.

Оповещение о сессии. Позволяет оповещать участников о бу-

дущей сессии. Например, существуют сотни радиостанций в Интернет,

вещающих по разным каналам. Оповещение о сессии позволяет таким

радиостанциям распространить информацию о расписании вещания для

потенциальных слушателей.

Идентификация сессии. Мультимедийная сессия часто со-

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

кретные (текст, изображения). Например, отправитель может посылать

звук и видео как два разных потока по одному каналу, которые при по-

лучении должны быть синхронизированы. Или наоборот, отправитель

может посылать звук и изображение вместе, но разделять воспроизве-

15

дение на несколько уровней по качеству в соответствии с возможностя-

ми получателей.

Управление сессией. Информация, содержащаяся в разных

потоках, может иметь внутренние связи и это должно быть учтено при

ее передаче. Это называется синхронизацией мультимедиа и может

быть достигнуто расстановкой меток времени (timestamps) в передава-

емых пакетах. Более того, получатели потокового мультимедиа могут

захотеть иметь возможность управления воспроизведением [8], как это

делается в обычных видеомагнитофонах.

1.6.6. Безопасность

При обсуждении процесса передачи мультимедиа часто забывают

про вопросы безопасности. Однако с ростом использования сервисов

реального времени вопросы безопасности становятся достаточно важ-

ными. Безопасность для данных мультимедиа выражается в трех аспек-

тах: целостность, аутентичность, шифрованность. Например, публичное

вещание требует целостности и аутентичности данных, а частное – их

шифрования. Для этого можно использовать различные криптографиче-

ские схемы [9].

Еще одна проблема – в сохранении авторских прав на компоненты

мультимедиа. Например, рассмотрим доставку фильмов по предвари-

тельной оплате. Существует возможность использования полученных

фильмов в коммерческих целях. Современные цифровые технологии

[11], добавляющие дополнительные данные в мультимедиа, могут по-

мочь в предотвращении таких нарушений.

1.6.7. Поддержка мобильности

Все более широкое использование беспроводных и сотовых сетей

подталкивает приложения мультимедиа к мобильности. Сотовые сети

покрывают огромную площадь и поддерживают высокий уровень мо-

бильности. Беспроводные сети, таки е как IEEE 802.11x [12], покрывают

относительно небольшие участки и имеют ограниченный уровень мо-

бильности. Однако такие сети обладают большей скоростью передачи и

более удобны для подключения пользователей.

Аспект мобильности приводит к изменению мультимедийных се-

тей. Он поднимает проблемы маршрутизации мобильных терминалов,

взаимодействия проводных и беспроводных сетей и многое другое.

16

Глава 2. Поддержка распределенного мультимедиа трафика в Интернете

В этой главе анализируется текущее состояние сети Интернет в

плане поддержки распределенного мультимедиа трафика, в том числе и

в режиме реального времени.

2.1. Поддержка трафика реального времени в Интернете

Трафик реального времени имеет жесткие требования на задержку

пакетов и неустойчивость их передачи, а сегодняшнее состояние сети

Интернет часто им не соответствует. Требуются дополнительные стадии

передачи пакетов и новая технология уменьшения потерь в процессе

этой передачи. Рассмотрим эти изменения более детально [12].

2.1.1. Задержки при обработке пакетов

Это постоянные задержки, которые может присутствовать как на

стороне отправителя пакетов, так и на стороне их получателя. Причиной

задержек может быть необходимость преобразования данных из анало-

говой формы в цифровую и их пакетизации на протоколах разного

уровня до непосредственной передачи по каналу связи. На этапе полу-

чения данных может потребоваться обратная процедура. Обычно эти

задержки определяются используемой операционной системой и муль-

тимедийным приложением. Для уменьшения таких задержек даже мо-

жет использоваться специализированная мультимедийная операционная

система [13].

2.1.2. Задержки при передаче пакетов

Это время, затрачиваемое на физическом уровне для передачи па-

кетов. Оно зависит от нескольких факторов, например:

Число активных сессий. На физическом уровне пакеты пере-

даются по схеме FIFO, поэтому при наличии нескольких активных сес-

сий задержка становится значительной, особенно при отсутствии в опе-

рационной системе специализированных алгоритмов управления муль-

тимедийным трафиком.

Пропускная способность канала. Увеличение пропускной

способности канала уменьшает задержки передачи пакетов. Так при пе-

реходе от 10 Mbps Ethernet к 100 Mbps fast Ethernet задержки передачи

должны уменьшиться в 10 раз.

17

Medium Access Control (MAC) задержка. Если канал переда-

чи делится несколькими приложениями, то может использоваться соот-

ветствующий уровень сетевого доступа и обнаружения ошибок (MAC

протокол) [14]. Выбор MAC протокола существенно влияет на величину

задержки. Например, если пропускная способность C bps, а длина паке-

та L бит, время передачи для выделенной линии равно L/C. Но если

MAC протокол использует TDMA (Time Division Multiple Access), ска-

жем, при m слотах, задержка будет равна mL/C. Большие сети Ethernet

не могут дать никаких гарантий на величину этой задержки из-за не-

определенности прогноза коллизий между различными потоками дан-

ных в канале [16]. Fast Ethernet работает по той же схеме, как и 10 Mbps

Ethernet и также не дает таких гарантий. Изохронный Ethernet и Ethernet

с запросами приоритетов могут обеспечить качество передачи, но их

распространение пока под вопросом.

Переключатель контекста в ОС. Отсылка и получение паке-

тов подразумевает некоторое время на работу контекстных переключа-

телей. Следовательно, существует некоторый максимум для скорости

передачи пакетов компьютером. Для 10 Mbps LAN эта задержка может

быть несущественной, но для гигабитных сетей ее уже надо учитывать.

Для уменьшения этой задержки требуется улучшение драйверов

устройств и повышение частоты работы компьютера.

2.1.3. Задержка передачи

Верхним порогом скорости передачи сигнала является скорость

света. В случае передачи в одном здании на расстояние 200 метров за-

держка составит около одной микросекунды. Если же передача проис-

ходит между странами на расстояние 20,000 км, задержка составит

0.1секунды. Эти значения являются физическими ограничениями и не

могут быть уменьшены. Если интерактивная сессия мультимедиа требу-

ет задержек не более 200 миллисекунд, то на таком расстоянии заданное

качество передачи не может быть обеспечено.

2.1.4. Задержки маршрутизации и обработки очередей

Это единственный тип задержки, которая может быть уменьшена

путем введения улучшенных моделей архитектуры Интернет. В Интер-

нете каждый пакет обрабатывается одинаково, вне зависимости от его

характера (реального или нереального времени). Промежуточные

маршрутизаторы принимают независимые решения для каждого пакета.

Когда пакеты встраиваются в очередь, они ожидают случайное время до

их обработки, зависящее от текущей загрузки маршрутизатора. Это

18

время добавляется к задержке в очереди. Такой тип задержки случаен и

является основной причиной несинхронности в передаче данных. Если

задержка времени в очереди становится слишком большой, пакет может

быть послан повторно. Это может вызвать лавинный эффект и привести

к перегрузке и еще большему увеличению задержки в очереди. В со-

временных сервисах Интернета используется специальная технология

для предотвращения подобных эффектов. Например, в простейшем слу-

чае образуется виртуальный выделенный канал (с выделением ресурсов

в форме буферов или частот пропускания) и эта задержка исчезает. По

такому принципу работают модели Integrated Services (Intserv) и Multi-

Protocol Label Switching (MPLS). Другим вариантом является комбина-

ция упорядочивания трафика, контроль входов и модификации техноло-

гии обработки очередей с учетом приоритетов пакетов. Этот подход ис-

пользует модель Differentiated Services (Diffserv).

2.2. Требование высокой пропускной способности

Передача потока мультимедиа требует высокой пропускной спо-

собности каналов (см. таблицу 5). Модель негарантированной доставки

(best effort Internet model) не обеспечивает никаких механизмов для

приложений по резервированию сетевых ресурсов при передаче боль-

ших объемов информации. Неконтролируемая передача на высокой

скорости может привести к перегрузке канала и полной остановке пере-

дачи. В данной модели нет механизма предотвращения подобных ситу-

аций, кроме простого отключения источников информации. Приложе-

ния сами должны динамически адаптироваться к перегрузкам каналов.

Гибкие приложения, использующие TCP, применяют механизм обрат-

ной связи (closed-loop feedback mechanism), встроенный в TCP для

предотвращения перегрузок. Этот метод называется реактивным кон-

тролем перегрузок. Однако многие приложения используют при пере-

даче протокол UDP, в котором нет механизмов контроля перегрузок и

есть тенденция к полной остановке передачи от перегрузок канала.

Для решения этих проблем, используется управление доступом

(admission control), резервирование пропускной способности (band-

width reservation) и механизмы управления трафиком (traffic policing

mechanisms). Приложение должно сначала получить полномочия пере-

давать трафик с заданной скоростью и с некоторыми заданными харак-

теристиками трафика. Если такие полномочия даются, оно создает запас

необходимых ресурсов (пропускной способности и буферов) для пере-

дачи данных на заданной скорости. Механизмы контроля трафика обес-

печивают соблюдение заданных скоростей.

19

2.3. Отклонения характеристик сети

Мультимедийные потоки требуют некоторых гарантий по отклоне-

нию характеристик сети передачи от заданных значений, а модель нега-

рантированной доставки не может предоставить такие гарантии, потому

что путь пакета от источника к месту назначения не является фиксиро-

ванным и, следовательно, сеть не имеет информации об отклонении ха-

рактеристик каждого отдельного сегмента. Таким образом, приложение-

отправитель не знает об отклонениях характеристик сети, что может

привести к использованию неоптимальных механизмов обнаружения и

коррекции ошибок.

Для новых моделей сервисов Интернет приложение-отправитель

должно пройти контроль доступа. В этом случае отправитель может

указать максимальную ошибку, которую он может терпеть. Если сеть

использует алгоритм маршрутизации на основе QoS и не может найти

путь, удовлетворяющий этому требованию, она будет просто отвергать

соединение или сделать встречное предложение о повышении уровня

допустимых ошибок. Другими словами, отправитель предупреждается

об отклонениях характеристик сети.

2.4. Предлагаемые модели сервисов Интернет

Мы рассмотрим несколько новых моделей архитектуры Интернет –

Integrated Services (Intserv), Differentiated Services (Diffserv) и Multi-

protocol Label Switching (MPLS) – которые предлагаются для удовле-

творения требований распределенных приложений мультимедиа при

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

обсуждение этих моделей, сформулируем некоторые принципы, кото-

рые являются для них общими.

2.4.1. Уточнение требований к сервисам и описанию трафика

Для добавления к Интернету поддержки гарантированного обслу-

живания необходимо определить ее в математических терминах. QoS

определяет уровень сервиса, который распределенное мультимедийное

приложение ожидает от сети связи. Три параметра QoS представляют

первостепенный интерес: пропускная способность, задержки и надеж-

ность.

Пропускная способность определяет, сколько данных (макси-

мально и в среднем) могут быть переданы в сети [15]. Одной битовой

скорости здесь недостаточно, так как схемы QoS должны быть приме-

нимы к сетям разного типа. Например, при обработке протокола пере-

дачи важную роль играют такие вопросы, как управление буфером,

20

таймерами и запросы управляющей информации. Затраты на эти опера-

ции связаны с числом обрабатываемых пакетов, что определяет важ-

ность пакето-ориентированных спецификаций пропускной способности.

Информация о пакетах может задаваться указанием максимального и

среднего размера пакетов, а также скоростью их передачи.

Задержка, в качестве второго параметра, определяет максималь-

ную задержку передачи данных от отправителя до получателя [11]. Зна-

чение задержки при передаче мультимедийной информации может ва-

рьироваться от одного элемента к другому. Источником этих изменений

задержки может быть нестабильность процесса передачи (jitter) и его

сдвиг (skew). Нестабильность означает, что в потоке объектов их фак-

тическое время появления отличается от заданного момента (рис. 2.1).

Рис. 2.1. Эффект несинхронности потока объектов:

(a)–исходный поток с регулярными интервалами; (b)–эффект нестабильно-

сти; (c)–эффект сдвига.

На рис. 2.1 (a) каждая стрелка представляет позицию объекта через

равные промежутки времени. На рис. 2.1 (b) пунктирные стрелки пока-

зывают ожидаемые моменты появления объектов, а сплошные – реаль-

ное появление. Видно, что существует случайное отклонение от ожида-

емого момента появления объекта. Этот эффект называется нестабиль-

ностью потока объектов по времени. При передаче видео это выражает-

ся в дрожании получаемой картинки.

Сдвиг выражается в постоянно увеличивающейся разнице между

заданным и фактическим моментом появления мультимедийных объек-

тов потока. Этот эффект показан на рис. 2,1 (с). При передаче видео это

проявится замедлением движущегося изображения. Нестабильность

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

21

Надежность связана с потерями и повреждениями данных. Может

быть указана вероятность потерь и метод борьбы с ошибочными дан-

ными.

Также необходимо для каждого источника математически описать

характеристики трафика. Например, каждый источник может описать

характеристики своего транспортного потока с использованием де-

скриптора трафика, который содержит пиковую скорость, среднюю

скорость и максимальный объем передаваемой информации [8].

2.4.2. Управление доступом

Это преактивная форма управления перегрузками (в отличие от

реактивного управления перегрузкой, используемой в таких протоко-

лах, как TCP), которая гарантирует, что спрос на сетевые ресурсы не

превысит предложение. Предотвращение возникновения заторов

уменьшает задержки пакетов и их потери, что повышает производи-

тельность передачи в режиме реального времени.

Модуль контроля доступа (см. рис. 2.2) принимает в качестве

входных данных дескриптор трафика и требования QoS, а на его выходе

формируется решение о принятии потока (в соответствии с требования-

ми QoS) или его отклонении, если требования QoS не выполняются [17].

Для этого он обращается к модулю критериев приема, содержащему

правила, по которым схема управления доступом принимает или откло-

няет поток.

Рис. 2.2. Компоненты управления доступом

Поскольку сетевые ресурсы являются общими для всех принятых

потоков, решение принять новый поток может повлиять на выполнение

22

требований QoS для предыдущих потоков. Таким образом, решение

контроля доступа, как правило, принимается на основе оценки влияния

нового потока на другие потоки и выполнение цели сети.

Другим полезным компонентом управления доступом является мо-

дуль измерения процесса (measurement process module). Если источник

информации строго соответствует заданным значениям дескриптора по-

тока, модуль управления доступом может просто использовать эти зна-

чения. Однако при передаче в реальном времени строго задать эти па-

раметры не удается. Когда реальный трафик становится пульсирующим

(bursty traffic), использования сети может быть очень низким, если

управление доступом производится исключительно на основе парамет-

ров, заданных в начале сеанса.

2.4.3. Управление трафиком

После того, как поток принимается с заданными требованиями QoS

и дескриптором трафика, источник обязан придерживаться этого про-

филя. Если источник нарушает обязательства и отправляет больше ин-

формации, чем было запланировано, то это приведет к сбою в модели

обслуживания. Для предотвращения таких ситуаций используется си-

стема управления трафиком.

Для управления трафиком почти всегда используется алгоритм

дырявого ведра (Token Bucket алгоритм) [18]. Задача алгоритма –

принять решение: передать пакет или отбросить. Параметрами алгорит-

ма являются скорость поступления пакетов в «ведро» (бит/c) и объём

«ведра». Когда ведро переполняется, дополнительные пакеты будут по-

теряны. Этот алгоритм используется для систем управления трафиком, в

которых избыточный трафик отбрасывается.

2.4.4. Классификация пакетов

Каждый пакет, как реального, так и нереального времени, в Интер-

нете обрабатывается одинаково на всех маршрутизаторах. Но в режиме

мультимедийного трафика реального времени требуется дифференци-

рованный подход. Таким образом, новым моделям сервисов придется

использовать какой-то механизм, чтобы различать пакеты в режиме ре-

ального времени. На практике это обычно делается путем маркировки

пакетов. Для этой цели может быть использовано поле типа сервиса

(ToS) в заголовке протокола IP.

23

2.4.5. Планирование пакетов

Если в сети используется дифференцированный подход, то плани-

рование FIFO, традиционно используемое в маршрутизаторах, должно

быть заменено сложными процедурами управления очередями, напри-

мер, приоритетами очередей и т.п. Приоритеты очередей формируют

различные очереди для разных типов трафика. Каждая очередь имеет

приоритет, с которым она обслуживается. Очереди с более низким при-

оритетом обрабатываются только тогда, когда нет очередей с более вы-

соким приоритетом. Один из главных недостатков этого подхода состо-

ит в том, что он может привести к существенной задержке потоков с

низким приоритетом.

2.4.6. Потеря пакетов

При перегрузке сети некоторые пакеты должны быть удалены

маршрутизаторами. Раньше это делалось случайно, что приводило к не-

эффективной производительности при передаче мультимедийного тра-

фика. Например, кодированный MPEG поток пакет содержит I, P и B

кадры. Кадры I сжимаются без использования временной избыточности

между кадрами, а Р и В кадры формируются с использованием векторов

движения от кадра I (или Р). Таким образом, пакеты, содержащие кадры

I, являются более важными, чем те, которые содержат кадры P или B.

Когда дело доходит до потерь пакетов в сети, приоритетное внимание

должно уделяться кадрам I. Обзор различных схем потерь пакетов мож-

но найти в [19].

2.4.7. Маршрутизация на основе QoS

Интернет с негарантированной доставкой использует протоколы

маршрутизации Open Shortest Path First (OSPF), Routing Information

Protocol (RIP) и Border Gateway Protocol (BGP) [20]. Эти протоколы

называются протоколами негарантированной маршрутизации и обычно

используют одноцелевые алгоритмы оптимизации, которые рассматри-

вают только один показатель (число транзитных участков или стои-

мость линии) и сводят его к минимуму, чтобы найти кратчайший путь

от источника к месту назначения. Таким образом, весь трафик направ-

ляется по кратчайшему пути, что приводит к перегрузке в некоторых

узлах и недогрузке в других. Кроме того, если перегрузка используется

для определения стоимости линии, то сильно перегруженные узлы

имеют более высокую стоимость, и такие алгоритмы могут вызывать

колебания в сети, где трафик непрерывно переключается от сильно пе-

24

регруженных узлов к недогруженным узлам, что приведет к увеличе-

нию задержки и нестабильности для конечных пользователей.

При маршрутизации на основе QoS пути для разных потоков опре-

деляются с учетом некоторой информации о доступности ресурсов сети.

Например, на рис. 2.3 предполагается, что поток от хоста X до хоста Y

требует пропускной способности 4Mbps. Следовательно, хотя путь A-B-

C короче (всего два транзитных участка), он не будет выбран, так как не

имеет достаточной пропускной способности. Вместо него будет выбран

путь A-E-D-C.

Рис. 2.3. Маршрутизация на основе QoS

Кроме маршрутизации на основе QoS, есть еще маршрутизации на

основе политик и маршрутизация на основе ограничений. Маршрутиза-

ции на основе политик [21] обычно означает, что решения о маршрути-

зации основана не на знании топологии сети и ее метрик, а на некото-

рых политиках администрирования. Например, политика может запре-

тить транспортный поток по конкретному пути из соображений без-

опасности, даже если путь удовлетворяет всем ограничениям QoS.

Маршрутизация на основе ограничений [22] – еще одна новая концеп-

ция, которая происходит от маршрутизации на основе QoS, но имеет

более широкий смысл. В ней маршруты вычисляются на основе не-

скольких ограничений, в том числе и ограничений QoS и политик. Оба

этих способа маршрутизации можно рассматривать как частные случаи

маршрутизации на основе ограничений.

2.5. Интегрированные сервисы

Для поддержки мультимедийного трафика через Интернет рабочая

группа Integrated Services в Internet Engineering Task Force (IETF) разра-

25

ботала усовершенствованную модель Интернет под названием интегри-

рованный сервис (IntServ) [23]. Эта модель характеризуется резервиро-

ванием ресурсов. Она требует от приложений знания их требований к

трафику и требований QoS, а также передачи промежуточным маршру-

тизаторам информации для резервирования ресурсов, таких как про-

пускная способность и размер буферов. Соответственно, если маршру-

тизаторы зарезервировали их и отправили обратно положительное под-

тверждение, можно начать передачу данных. Если, с другой стороны,

достаточные ресурсы не доступны в любом маршрутизаторе пути, по-

пытка повторяется через некоторое время. Эта модель также требует

использования пакета классификаторов для определения потоков, кото-

рые должны получить определенный уровень сервиса, а также пакет

планировщиков для обработки пересылки различных пакетов в порядке,

обеспечивающем выполнения требований QoS.

Сущность Intserv почти исключительно связана с контролем ком-

понент задержки очередей пакетов. Таким образом, задержка пакета –

центральный момент, на основе которого принимаются решения.

Intserv вводит три класса обслуживания для поддержки RTI, RTT и

гибких мультимедийных приложений. К ним относятся: гарантиро-

ванный сервис (Guaranteed service), сервис контроля нагрузки (Con-

trolled Load service) и сервис негарантированной доставки (best-

effort service). Для описания передачи и требований QoS используется

поток дескрипторов [1]. Поток дескриптора состоит из двух частей:

спецификации фильтра (filterspec) и спецификации потока

(flowspec). Filterspec предоставляет информацию, необходимую класси-

фикатору пакетов для определения пакетов, которые принадлежат к

этому потоку. Flowspec состоит из спецификации трафика (Tspec) и

спецификации запроса на обслуживание (RSpec). Tspec описывает

поведение трафика в потоке через маркер параметров ведра (b,r), в то

время как RSpec содержит требования QoS с точки зрения пропускной

способности, задержки, нестабильности передачи и потери пакетов.

Поскольку все узлы сети на пути от источника к месту назначения

должны быть проинформированы о запрашиваемых ресурсах, протоко-

лов сигнализации не требуется. Для этой цели используется протокол

резервирования ресурсов (RSVP) [24]. Процесс сигнализации показан на

рис. 2.4. Отправитель посылает сообщение PATH для приемника с ука-

занием характеристик трафика. Каждый промежуточный маршрутиза-

тор на пути сообщения PATH для следующего шага определяется про-

токолом маршрутизации. Приемник, получив сообщение PATH, реаги-

рует сообщением RESV запроса ресурсов для потока. Каждый проме-

жуточный маршрутизатор на пути может отклонить или удовлетворить

26

запрос сообщения RESV. Если запрос отклоняется, маршрутизатор по-

сылает сообщение об ошибке на приемник и процесс сигнализации за-

вершается. Если запрос будет принят, для потока выделяются буфер пе-

редачи и пропускная способность, а в маршрутизаторе будет установле-

но соответствующее состояние.

Рис. 2.4. Сигнализация RSVP

RSVP может быть использован для различных сервисов управления

QoS. Спецификация RSVP не определяет внутренний формат полей или

объектов протокола RSVP и рассматривает их как непрозрачные, имея

дело только с установкой механизма. RSVP был разработан для под-

держки как одноадресных, так и многоадресных приложений. RSVP

поддерживает гетерогенные QoS, что означает: для различных прием-

ников в одной группе многоадресной рассылки можно запросить раз-

личные QoS. Такое разнообразие позволяет некоторым приемникам

иметь резерв на то время, когда другие получают тот же трафик, ис-

пользуя сервис негарантированной доставки. Перейдем теперь к обсуж-

дению классов сервисов, предлагаемых IntServ.

2.5.1. Классы гарантированного обслуживания

Гарантированный уровень обслуживания обеспечивает твердые га-

рантии величины задержки доставки пакетов. Гарантированное обслу-

живание не контролирует минимальную или среднюю задержку паке-

тов, а только максимальную задержку в очередях. Данная услуга гаран-

тирует, что пакеты будут приходить получателю в течение требуемого

времени и не будут отменены из-за переполнения очереди, при условии,

что трафик потока остается в пределах установленных лимитов, кото-

рые контролируется с помощью политик. Данная услуга предназначена

для приложений, которые нуждаются в твердой гарантии, что пакет бу-

дет доставлен не позднее указанного времени.

Используя спецификацию трафика (TSpec), сеть может вычислить

различные параметры, описывающие, как она будет обрабатывать по-

ток, и путем комбинирования параметров может вычислить максималь-

27

ную длину очередей и задержки маршрутизации пакета. При использо-

вании модели потока жидкости, задержка в очереди выражается функ-

цией двух параметров: 'b' – маркер размера ведра, и "r" – скорость пере-

дачи данных, запрашиваемая приложением.

2.5.2. Сервис управления загрузкой

Сервис управления загрузкой повышает качество обслуживания

RTT приложений, требующих более высокой производительности, чем

предусмотрено в сети негарантированной доставки. В данном случае

предполагается, что в условиях незагруженной сети очень высокий про-

цент переданных пакетов будет успешно доставлен, а задержки переда-

чи пакетов не будут сильно отличаться от минимальной задержки.

Сеть, обеспечивающая адекватную пропускную способность и ре-

сурсы для обработки пакетов, доступна для обработки с требуемым

уровнем трафика. Сервис управления загрузкой не использует конкрет-

ные целевые значения для задержки или потерь. Прием запроса управ-

ления загрузкой является просто обязательством обеспечить поток

условиями, равными условиям неконтролируемого трафика при невы-

сокой загрузке. В процессе контроля загрузки средние задержки пакетов

в очереди могут незначительно вырасти или совсем не измениться, а по-

тери из-за перегрузки сети могут вообще исчезнуть.

Сервис управления загрузкой описывается только с помощью

TSpec. Так как сеть не дает каких-либо количественных гарантий, RSpec

не требуется. Контролируемая загрузка потоков в условиях отсутствия

перегрузки будет иметь заданное качество обслуживания, а сетевые

элементы будут освобождены от избыточное трафика. Превышение

трафика будет направлено по схеме негарантированной доставки.

2.5.3. Сервис негарантированной доставки

Сервис негарантированной доставки не имеет полей TSpec или

RSpec, поэтому доставка действительно не гарантируется. Никакого

контроля доступа в этом случае не производится.

2.5.4. Недостатки модели Intserv для Интернета

Intserv использует RSVP, чтобы резервировать на маршрутизаторах

сетевой путь для каждого потока. Хотя это позволяет сети предостав-

лять гарантии сервиса на уровне потока, возникает проблемы масштаба.

Маршрутизаторы должны поддерживать заданное состояние потока для

каждого потока, проходящего через маршрутизатор, что может приве-

сти к перегрузке сети. Более того, RSVP является программным прото-

28

колом и его состояние обновляется через регулярные промежутки вре-

мени. Это также увеличивает расход трафика.

2.6. Дифферецированный сервис

Дифферецированный сервис (Differentiated Services – Diffserv)

был предложен рабочей группой Diffserv из IETF как модель сервиса

Интернет, устраняющую некоторые проблемы архитектуры Intserv [25].

DiffServ делит сеть на отдельные регионы, называемые DS доменами,

где каждый домен управляется как отдельный объект. Одним из важных

результатов является обеспечение гарантированного сервиса в рамках

одного DS домена. Но если даже один транзитный участок находится за

пределами домена, то гарантии уже не даются. Архитектура DiffServ

может быть распространена на несколько доменов с использованием со-

глашений по уровню сервиса (Service Level Agreement's – SLA) между

ними. SLA определяет правила разметки трафика, действия по обработ-

ке лишнего трафика и т.д.

Каждая вершина в домене DS может быть:

Граничной вершиной. Граничные вершины являются воро-

тами домена DS. Граничная вершина является первой (или последней)

вершиной, через которую проходит пакет при входе (или выходе) в (из)

домен(а) DS. В ней выполняются специфичные граничные действия, та-

кие как контроль доступа, классификация пакетов и обеспечение усло-

вий прохождения трафика. Алгоритм контроля доступа ограничивает

число потоков внутри домена DS. Например, в простейшем случае, ал-

горитм контроля доступа может создать центральную структуру дан-

ных, содержащую текущий статус всех связей в домене DS. Когда поток

проверяется на доступ, соответствующая граничная вершина должна

просто проверить структуру данных на удовлетворение путей потока

требованиям QoS. Каждый пакет, принадлежащий принятому потоку,

по прибытии в домен DS классифицируется и маркируется как принад-

лежащий одному из классов сервиса, называемых “Behavior

Aggregates” в терминах Diffserv. Каждому такому классу соответствует

8-битовое кодовое слово, называемое точкой кода (DS code-point).

Маркировка пакетов проводится добавлением в поле TOS IP-заголовка

пакета значения точки кода. Граничные вершины также обеспечивают

соглашения по трафику (Traffic Conditioning Agreements – TCA)

между собственным доменом DS и другими доменами, если это необхо-

димо.

Внутренней вершиной. Внутренняя вершина расположена

полностью внутри домена DS и соединяется с другими внутренними

29

вершинами или граничными вершинами этого же домена DS. Внутрен-

ние вершины занимаются только пересылкой пакетов. Когда пакет со

своей точкой входа поступает в такую вершину, он пересылается на

один транзитный участок дальше в соответствии с некоторыми заранее

определенными правилами для этого класса пакетов. Такие правила

называют Per-Hop Behaviors (PHB) и более детально будут рассмотрены

ниже.

Таким образом, в противоположность Intserv, только граничные

вершины могут определять состояние потока, что делает Diffserv более

масштабируемой.

2.6.1. Per Hop Behavior (PHB)

PHB является набором заранее определенных правил, определяю-

щих, каким образом буферы маршрутизатора и пропускная способность

сети будет разделяться между конкурирующими потоками. PHB могут

быть определены или в терминах ресурсов маршрутизатора (буферы и

пропускная способность), или в терминах приоритетов относительно

других PHB, или в терминах свойств трафика (задержки и потери). Не-

сколько PHB могут быть объединены в группу. Группа может действо-

вать на несколько путей, так как она определена в терминах характери-

стик поведения и не зависит от специфики приложений. PHB могут рас-

сматриваться как базовые блоки при создании сервисов. Для пакета

PHB выбирается в первой вершине на основе точки кода. Соответствие

между точкой кода и PHB может быть 1 к 1 или N к 1. Примером пара-

метров поведения при пересылке может быть определение для потока

выделенной пропускной способности (Weighted Fair Queuing – WFQ) и

приоритеты при потере (Random Early Detect – RED). IETF определены

два общих PHB:

Assured Forwarding (AF) PHB. Делит входящий трафик на 4

класса с разным уровнем гарантий минимальной пропускной способно-

сти и размера буферов. Внутри каждого класса пакетам назначается

один из трех приоритетов потери пакета. Путем варьирования количе-

ства ресурсов в классе может быть достигнут разный уровень произво-

дительности.

Expedited Forwarding (EF) PHB. EF PHB определяет, что

скорость отправки трафика из любого маршрутизатора должна быть

больше или равна предусмотренной в конфигурации. Так для класса

трафика, принадлежащего к EF PHB, в любой интервал времени гаран-

тируется скорость отправки из любого маршрутизатора большая или

равная его суммарной скорости получения пакетов. Это гарантирует

30

минимальную задержку пакетов в очередях, ограниченную только про-

пускной способностью сети. EF PHB используется для обеспечения

сервиса класса «премиум» (Premium Service) без задержек и нестабиль-

ности передачи. Однако EF PHB требует очень жесткого механизма

контроля доступа. Он должен обеспечивать скорость прибытия трафика

меньше скорости его отправки, заданной в конфигурации EF PHB. Пра-

вильное функционирование EF PHB требует еще и жестких политик.

Если пакеты нарушают установленные правила, они могут быть либо

отброшены, либо переведены в более низкий класс трафика.

2.7. Мультипротокольная коммутация по меткам

Когда пакет IP прибывает на маршрутизатор, следующий транзит-

ный участок (hop) для этого пакета определяется алгоритмом маршру-

тизации с использованием метода «совпадения длиннейшего префикса»

(“longest prefix match”), т.е. совпадения самого длинного префикса в IP-

адресе пункта назначения со входами в таблице маршрутизации при

выборе подходящего выходного маршрута [26]. Этот процесс добавляет

некоторую задержку, так как таблицы маршрутизации достаточно вели-

ки и их просмотр требует времени. Также этот процесс приходится по-

вторять независимо для каждого входящего пакета, даже если все паке-

ты принадлежат одному потоку и следуют в одном направлении. Этот

недостаток может быть устранен использованием IP-коммутаторов, в

которых небольшая метка прикрепляется к пакету и обновляется после

каждого транзитного участка. Когда такой модифицированный пакет

поступает на коммутатор (маршрутизатор в предыдущих терминах), эта

метка используется для индексирования в короткой коммутационной

таблице для определения дальнейшего маршрута и обновления метки.

Все это легко реализуемо на уровне оборудования, поэтому выполняет-

ся с высокой скоростью. Этот подход раньше использовался в ATM для

сотовых коммутаторов, которые работали с полем VPI/VCI пакета как с

меткой. MPLS использует этот подход в сетях IP. Он называется муль-

типротокольным, так как эта технология также может быть использова-

на на любом уровне сети, а не только на уровне IP.

Коммутация по меткам обеспечивает использование недорогих ап-

паратных средств, масштабируемость до очень высоких скоростей, а

также гибкость в управлении потоками трафика.

Подобно Diffserv, сеть MPLS также делится на домены с гранич-

ными вершинами, называемыми ‘Label Edge Routers’ (LER), и внутрен-

ними вершинами, называемыми ‘Label Switching Routers’ (LSR). Паке-

там, входящие в домен MPLS, назначаются метки, по которым и проис-

31

ходит коммутация пакета внутри домена. Метки определяют качество

обслуживания потоков, проходящих через сеть. Последовательность

LSR на пути внутри домена MPLS называется ‘Label Switched Path’

(LSP). И снова, подобно Diffserv, гарантируется определенный уровень

обслуживания как внутри домена, так и между доменами при наличии

соответствующего соглашения.

MPLS использует концепцию ‘Forward Equivalence Class’ (FEC)

для обеспечения дифференцированной обработки разных типов муль-

тимедиа. Группа пакетов пересылается одинаково, если они принадле-

жат одному классу FEC. Ограничений на количество и сложность

структуры FEC не накладывается. Следовательно, возможно опреде-

лить отдельный FEC для каждого потока или для каждого типа мульти-

медиа. Здесь следует отметить один важный момент. Данные метки

имеют локальное значение в пределах заключенных соглашений. Необ-

ходимо назначать метки на каждом транзитном участке LSP до того, как

этот поток начнет использовать LSP. Назначение меток может быть вы-

полнено одним из следующих трех способов:

Topology-driven label assignment. LSP (для каждого возмож-

ного FEC) автоматически устанавливается для каждой пары LSR. Эта

схема накладывает жесткие требования на использование меток в каж-

дом LSR. Однако основное преимущество такого подхода заключается в

отсутствии задержек на установку LSP до использования его потоком

трафика.

Request driven label assignment. LSP устанавливается на базе

определенных запросов. Для формирования запросов может быть ис-

пользован RSVP. Преимуществом данного подхода в том, что LSP фор-

мируется только по запросу. Но с другой стороны, появляется новый

источник задержек.

Traffic driven label assignment. Это комбинация преимуществ

двух предыдущих подходов. LSP устанавливаются только в тот момент,

когда LSR идентифицирует шаблоны трафика. Если идентификация не

нужна, используются обычные методы маршрутизации.

MPLS также поддерживает стек меток, который может быть поле-

зен при выполнении туннельных операций. В стеке метки обслужива-

ются по схеме FILO. В любом отдельном домене только верхняя метка в

стеке используется для принятия решения о маршрутизации пакета. Эта

функциональность может быть очень полезна для обеспечения мобиль-

ности, где домашний агент может назначить другую метку входящему

пакету и переслать пакет внешнему агенту, который пересылает пакет

на мобильный пункт назначения.

32

Глава 3. Расширение стека протоколов TCP/IP для поддержки функциональных требований распределенных мультимедийных

приложений

В этой главе будут кратко рассмотрены протоколы, работающие на

базе протокола TCP/IP и удовлетворяющие функциональные требования

мультимедийных потоков. Затем будут представлены две архитектуры

протоколов (H.323 и SIP), которые стандартизуют поддержку этих

функциональных требований.

3.1. Поддержка мультикаста

Самым простым способом организации мультикаста в Интернете

является простая посылка пакетов по заданным адресам [27]. Хост, го-

товый посылать сообщения в режиме мультикаста определенным груп-

пам мультикаста, информирует их ближайшие маршрутизаторы с ис-

пользованием протокола IGMP (Internet Group Management Protocol).

Мультикаст тривиален на одном сегменте Ethernet, где пакеты могут от-

сылаться на заданные MAC-адреса. Однако при доставке пакетов муль-

тикаста через другие сети маршрутизатор мультикаста нуждается в об-

мене информацией с соседними маршрутизаторами. Существует много

различных алгоритмов, таких как "flooding", "spanning tree", "reverse

path broadcasting" и "reverse path multicasting" для обмена информацией

между маршрутизаторами. Некоторые из этих алгоритмов были исполь-

зованы в динамических протоколах многоадресной маршрутизации, та-

ких как Distance Vector Multicast Routing Protocol (DVMRP), Multicast

extension to Open Shortest Path First (MOSPF), и Protocol Independent

Multicast (PIM) [28]. На основе информации о маршрутизации, получен-

ной с помощью одного из этих протоколов, маршрутизаторы мультика-

ста будут решать, следует ли направить этот пакет по своей сети или

нет.

Другой подход называется MBone или Multicast Backbone. Mbone

– по существу виртуальная сеть, создаваемая над фрагментами Интер-

нет. В MBone «острова» мультикаста связаны друг с другом виртуаль-

ными ссылками, называемые «туннелями». Именно через эти туннели

сообщения мультикаста передаются через обычные части Интернет. Для

пересылки пакетов мультикаста через эти туннели они инкапсулируют-

ся как пакеты IP-over-IP (с уровнем протокола до 4) и выглядят как

обычные пакеты.

33

ITU-T H.323 и IETF Session Initiation Protocol (SIP), как будет

рассмотрено позже, поддерживают мультикаст посредством использо-

вания Multi-point control unit, что обеспечивает функциональные воз-

можности, необходимые для аудио/видео конференций. В [29] дается

обзор вопросов QoS при мультикасте.

3.2. Управление сессиями

Мы обсудим протоколы, которые были стандартизированы для

удовлетворения различных аспектов управления сессиями.

Описание сессии (Session Description Protocol – SDP) [30] [31],

разработанный IETF, может быть использован для обеспечения функ-

циональности описания сессии (описание типа мультимедиа, способа

его кодирования в данной сессии). SDP кодирует описание мультимедиа

в простом текстовом формате. Сообщение SDP состоит из серии строк,

называемых полями, имена которых сокращены до одной буквы в ниж-

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

процесса анализа. Поля заполняются по шаблону attribute_type = зна-

чение. Пример сообщения SDP показан на рис. 3.1. Значение всех атри-

бутов записано в левой колонке, а само сообщение – в правой.

Рис. 3.1: Пример сообщения SDP

Оповещение о сессии (Session Announcement). Протокол опове-

щения о сессиях (Session Announcement Protocol – SAP) [32][33] ис-

пользуется для оповещения о предстоящих сессиях мультикаста. Опо-

вещатель SAP периодически рассылает пакеты оповещения зарегистри-

рованным участникам мультикаста по их адресам и портам (обычно

порт 9875). Одну сессию могут анонсировать несколько оповещателей,

гарантируя надежность доставки данной информации в условиях воз-

можной потери пакетов и выхода из строя отдельных оповещателей.

34

Период времени между повторениями объявления выбирается так, что-

бы суммарный поток сообщений в сети, используемой всеми оповеща-

телями из одной группы SAP, оставался ниже предварительно настро-

енного предела. Каждый оповещатель получает и другие оповещения,

чтобы определить общее число сессий в конкретной группе. SAP объяв-

ляет о предстоящих многопользовательских сессиях мультикаста и

начинает свою работу задолго до ее старта. SAP также содержит меха-

низмы обеспечения целостности сессии оповещений, проверки их под-

линности и шифрования.

Идентификация сессий (Session Identification). В обычном Ин-

тернете каждый поток (или сессия) могут быть идентифицированы кор-

тежом <Src Ip, Src Port, Dst IP, Dst Port, Protocol>. Таким образом, для

каждой сессии может быть установлен индивидуальный сокет транс-

портного уровня. Но если возникает необходимость объединить не-

сколько сессий вместе (для сокращения расходов), то для этого нет до-

ступного механизма. Следовательно, существует явная необходимость в

мультиплексировании различных потоков одном сокете транспортного

уровня. Эта функция аналогична " Session Layer " в 7-уровневой модели

OSI, которая отсутствует в стеке протоколов TCP/IP. Идентификацию

сессии можно сделать с помощью RTP, что описывается более подробно

в следующих главах.

Управление сессиями (Session Control). Вся функциональность

управления сессиями может быть обеспечена использованием комбина-

ции RTP, RTCP и RTSP.

Real-time Protocol (RTP) [35] обычно запускается в верхней части

UDP. В частности, фрагмент аудио/видео данных, сгенерированный на

стороне мультимедийного приложения, инкапсулируется в пакет RTP,

который в свою очередь инкапсулируется в UDP. Функциональность

RTP должна быть интегрирована в приложение. Функции, обеспечивае-

мые RTP, включают:

Упорядочивание (Sequencing). В пакет RTP включается по-

ле номера пакета, помогающее предотвратить потерю паке-

тов.

Идентификация передаваемой информации (Payload Iden-

tification). Используется для динамического изменения схем

кодирования данных при необходимости изменения про-

пускной способности. Для обеспечения данной функцио-

нальности этот идентификатор включается в каждый пакет

RTP.

Индикация фреймов (Frame Indication). Звук и видео пере-

сылаются в логических единицах, называемых фреймами.

35

Для индикации начала и конца фрейма используется маркер

фрейма (frame marker).

Идентификация источника (Source Identification). В сесси-

ях мультикаста принимают участие много пользователей.

Требуется идентифицировать автора фрейма. Для этого ис-

пользуется идентификатор SSRC (Synchronization Source).

Синхронизация фрагментов мультимедиа (Intramedia

Synchronization). Для компенсации нестабильности передачи

разных фрагментов мультимедиа в рамках одного потока

RTP использует метки времени, необходимые для организа-

ции работы буферов проигрывания.

Дополнительная информация, описывающая тип мультимедиа и

схемы сжатия, может быть также вставлена в пакеты RTP, используя за-

головки профиля (profile headers) и расширения (extensions).

RTCP [20] является протоколом управления, работающим сов-

местно с RTP и обеспечивающим участников сессии мультикаста стати-

стикой о количестве переданных пакетов, числе потерянных пакетов,

показателях нестабильности работы сети и времени полной передачи.

Эта информация может быть использована источником для регулирова-

ния скорости передачи данных. Информация об адресах электронной

почты, именах и номерах телефонов, включаемая в пакеты RTCP, поз-

воляет пользователям идентифицировать других участников сессии.

Real-Time Streaming Protocol (RTSP) [35] является внешним

управляющим протоколом, дающим конечному получателю такую

функциональность, как пауза, перемотка и т.п.

Работа протокола RTP над протоколом UDP обеспечивает допол-

нительную функциональность, требуемую для перестановки UDP паке-

тов и использования в них меток времени. Однако ограничения прото-

кола UDP не преодолеваются полностью при использовании протокола

RTP. Так остается ненадежность UDP и по прежнему нет гарантии до-

ставки переданных пакетов получателю. С другой стороны, гарантии

отсутствия ошибок в протоколе TCP создают серьезные задержки вре-

мени, которые делают его бесполезным для приложений реального вре-

мени.

Мулабегович [36] предлагает альтернативу протоколу RTP –

Lightweight Streaming Protocol (LSP). Этот протокол так же размеща-

ется в верхней части транспортного уровня и основан на протоколе

UDP. LSP, также как и RTP, обеспечивает нумерацию пакетов и добав-

ление в них меток времени для упорядочивания пакетов и управления

буфером получателя. Однако, в противоположность UDP и RTP, прото-

кол LSP разрешает ограничение использования повторной пересылки

36

для минимизации перегрузок передающей сети. Это достигается ис-

пользованием негативной информации о потере пакетов и удовлетворе-

нием требования максимальной задержки, устанавливаемого при пере-

даче информации в реальном времени.

3.3. Безопасность

IpSec [37] [38] обеспечивает набор протоколов, необходимых для

безопасной передачи данных, добавляя элементы безопасности пакетам

IP. Такой подход позволяет приложениям безопасно передавать инфор-

мацию без изменения самих приложений. Например, до внедрения Ip-

Sec приложения часто для этих целей использовали SSH или SSL, но это

требовало модификации некоторых API в исходном тексте приложения

и его последующей перекомпиляции. IpSec четко отделяет политику от

применения. Политика (какой поток надо кодировать и каким образом)

обеспечивается системным администратором, тогда как ее применение

проводится применением набора протоколов. Политики помещаются в

виде правил в Secure Policy Database (SPD), используемой каждым па-

кетом и IpSec определяет, что делать с каждым пакетом: либо механизм

IpSec требуется применить к пакету, либо пакет должен быть отброшен,

либо пакет должен пересылаться дальше без применения механизма

безопасности. Если администратор сконфигурирует SPD для использо-

вания системы безопасности для отдельных потоков, то IpSec сначала

обрабатывает параметры безопасности потока от предыдущего узла. В

результате появляется соглашение по безопасности (Security Associa-

tion – SA) между ними. SA содержит тип механизма IpSec, применяе-

мый к потоку (AH или ESP), используемые алгоритмы кодирования,

секретные ключи и т.д. SA заключается на основе протокола Internet key

Exchange (IKE).

Как уже упоминалось ранее, IpSec использует два протокола для

обеспечения безопасности потока:

Authenticated Header (AH). Основная функция AH – уста-

новление аутентичности отправителя для получателя. Это

означает, что AH не шифрует поток данных. Может пока-

заться, что этот вариант не подходит для обеспечения без-

опасности на производстве. Однако существует большое

число приложений, где этот способ оказывает неоценимую

помощь. Например, при обзоре новостей, где данные могут

не шифроваться, аутентификация отправителя очень важна.

AH создает существенно меньшую добавку к основному тра-

фику, чем ESP.

37

Encapsulated Security Payload (ESP). ESP обеспечивает как

аутентификацию участников, так и шифрование данных в па-

кетах IP. В связи с кодированием каждого пакета ESP повы-

шает нагрузку на процессор.

IpSec может работать как в транспортном, так и в туннельном ре-

жимах. В транспортном режиме IpSec в защищаемом пакете сохраняет

заголовок IP и модифицирует только часть верхнего уровня, добавляя

заголовки IpSec и требуемый тип защиты между верхними уровнями и

оригинальным заголовком пакета IP. В туннельном режиме IpSec рас-

сматривает весь пакет как блок данных, добавляя новый заголовок паке-

та и защищая данные путем кодирования.

IpSec может быть легко интегрирован в операционную систему ли-

бо изменением протокола IP, либо вставкой дополнительного уровня

ниже уровня IP в стеке протоколов TCP/IP, либо использованием неко-

торых внешних устройств.

3.4. Мобильность

Mobile IP [39] является протоколом Интернет, используемым для

поддержки мобильности. Его целью является обеспечение поддержки

соединения вне зависимости от места расположения. Каждый сайт, ко-

торый позволяет своим пользователям перемещаться, должен создать

объект Home Agent (HA), а каждый сайт, который хочет, чтобы его по-

сещали, должен создать объект Foreign Agent (FA). Когда мобильный

хост (Mobile Host – MH) заходит на сайт, поддерживающий роуминг,

он контактирует с FA этого сайта. FA, в свою очередь, контактирует с

HA мобильного хоста. Все пакеты, предназначенные для MH, в конеч-

ном итоге достигнут HA, который инкапсулирует пакеты внутри друго-

го пакета IP и передает его FA. FA затем декапсулирует их и, в конеч-

ном счете, передает пакет MH. HA может также сообщать источник но-

вых IP-адресов, куда пакеты должны быть непосредственно перена-

правлены.

3.5. H.323

Рекомендации ITU-T Н.323 [40] [41] [33] определяют компоненты,

протоколы и процедуры, используемые для проведения голосовых и ви-

део конференций по пакетной сети, такой как Интернет или локальные

сети на основе IPX. H.323 являются очень гибкими рекомендациями,

которые могут применяться в самых разных вариантах – только аудио

(IP-телефония), аудио и видео (видео-телефония), различные виды

мультимедийных конференций. Они не нужны для двух разных клиен-

38

тов, поддерживающих одинаковые механизмы общения, такие, как воз-

можность обмена информацией в начале каждой сессии. Также веща-

тельные конференции могут поддерживаться без наличия какого-либо

специального оборудования и программного обеспечения.

H.323 является частью семейства рекомендаций ITU-T, приведен-

ных в табл. 3.1, называемых H.32x, так как они обеспечивают услуги

мультимедийных коммуникаций в широком спектре сетей. Операции

между этими различными стандартами осуществляется при наличии

шлюза, который обеспечивает преобразование формата данных, рас-

шифровку управляющих сигналов, преобразование аудио и видео коде-

ков, а также вызова или прекращение функциональности.

Таблица 3.1

Рекомендации ITU-T для аудио и видео конференций

Рекомендации ITU-T Тип сети, обеспечивающей конференцию

H.320 ISDN

H.321 и H.310 ATM

H.322 LAN, гарантирующие QoS

H.323 LAN и Интернет

H.324 PSTN/Wireless

Стандарт H.323 определяет четыре компоненты, которые обеспе-

чивают следующие сервисы мультимедийных коммуникаций типа

point-to-point и point-to-multipoint:

Терминалы (Terminals). Это конечные точки конференции

по стандарту H.323.

Шлюз (Gateway). Как указывалось ранее, шлюз необходим

только в случае конференции с разными клиентами на базе

H.32X.

Гейткипер (Gatekeeper). Обеспечивает множество функций,

включая контроль доступа и управление пропускной способ-

ностью. Терминалы должны получить доступ от гейткипера

для передачи своих сообщений.

Multi-point Control Unit (MCU). Это опциональная компо-

нента, обеспечивающая проведение конференций типа point-

to-multipoint на сети по стандарту H.323. MCU состоит из

обязательного Multipoint Controller (MC) и опциональных

Multipoint Processors (MP). MC определяет общие возможно-

сти терминалов использовать стандарт H.245, но не дает воз-

можности мультиплексирования звука, видео и данных.

39

Мультиплексирование потоков мультимедиа управляется MP

под контролем MC.

Рис. 3.2 иллюстрирует эти ситуации для всех четырех компонент.

Рис. 3.2. Сеть по стандарту H.323 с различными компонентами

H.225 RAS (Registration, Admission and Status) используется в ос-

новном конечными элементами H.323 (терминалами и шлюзами) для

обнаружения гейткипера, проведение у него регистрации, запрашивания

прав на сообщения и выделение пропускной способности. Гейткипер

может также использовать этот протокол для запросов на соседние

шлюзы.

Сигнальный протокол Q.931 используется для установки соеди-

нения и разъединения между двумя конечными элементами H.323 и яв-

ляется облегченной версией протокола Q.931 определенного для PSTN /

ISDN.

Мультимедийный управляющий протокол H.245 используется

для рассмотрения возможности передачи мультимедиа, например, аудио

/ видео кодеков, которые будут использоваться для каждого типа носи-

теля, а также определения отношений подчиненности.

40

Проведение конференций в реальном времени требует разделения

использования приложений, передачу файлов и текущих сообщений.

Рекомендации T.120 обеспечивают такие возможности для H.323.

T.120 является протоколом передачи данных в реальном времени, раз-

работанным специально для проведения конференций. Как и H.323, ре-

комендации T.120 служат надстройкой над множеством стандартов, что

делает возможным разделение работы определенных приложений в ре-

альном времени между несколькими участниками при использовании

неоднородных сетей.

Рис. 3.3. Стек протоколов H.323

Таблица 3.2 иллюстрирует этапы настройки конференции H.323

типа point-to-point, где гейткипер представлен в сети H.323. Первые три

этапа соответствуют установке соединения, в то время как последние

три – его завершению. Если гейткипер не используется, этапы 1 и 7 от-

брасываются.

Соответственно, в H.323 поддерживаются две модели соединения:

прямое соединение и соединение через гейткипера. В модели прямого

вызова все сигнальные сообщенияl Q.931 и H.245 пересылаются напря-

мую между двумя конечными элементами H.323 как потоки RTP. Пока

вызывающий конечный элемент знает транспортный адрес вызываемого

элемента, он может поддерживать режим прямого соединения. Эта мо-

дель непривлекательна для крупных проектов, поскольку непонятно,

кто является организатором конференции, а это может помешать предо-

ставить достаточные ресурсы для ее старта и проведения. В модели

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

рез него. В этом случае, использование RAS необходимо. Эта модель

41

дает конечным точкам доступ к услугам, предоставляемым гейткипе-

ром, таким как расшифровка адресов и маршрутизация вызовов. Она

также позволяет гейткиперам обеспечить контроль доступа и распреде-

ление пропускной способности в своих зонах. Эта модель больше под-

ходит для поставщиков услуг IP-телефонии, так как они могут контро-

лировать сеть и осуществлять функции учета и формирования счетов.

Таблица 3.2

Этапы вызова в H.323

Этап Прото-

кол Функции

1. Разрешение

вызова RAS

Запрос доступа от гейткипера на вызов или прием.

По завершении этапа вызывающие конечные точки

получают транспортный адрес Q.931 вызываемой

конечной точки.

2. Установка

вызова Q.931

Установка соединения между двумя конечными

точками. По завершении этапа вызывающие конеч-

ные точки получают транспортный адрес H.245 вы-

зываемой конечной точки.

3. Параметры

конечной точки H.245

Переговоры между конечными точками. Определе-

ние отношений подчиненности. Открытие логиче-

ского канала между двумя точками. По завершении

этапа каждая конечная точка знает адрес RTP/RTCP

другой точки.

4. Обмен ин-

формацией RTP Участники обмениваются сообщениями

5. Закрытие ка-

нала H.245 Закрытие логического канала

6. Завершение

вызова Q.931 Завершение вызова

7. Освобожде-

ние ресурсов RAS Освобождение ресурсов.

3.6. Session Initiation Protocol (SIP)

SIP является сигнальным протоколом уровня приложений, предна-

значенным для создания, модификации и завершения сессий мультиме-

диа (звуковых, видео или передающих данные) с одним или нескольки-

ми участниками [31][25][33]. SIP не определяет содержания сессии, оно

зависит от передаваемого контента, недоступного для сообщений SIP.

Для установки соединения в мультимедийной сессии SIP выполняет

следующие этапы:

Инициализация сессии (Session Initiation). Начало сессии,

возможно, самая сложная ее часть, так как обычно она требует опреде-

42

ления, где пользователь находится на текущий момент: дома или на ра-

боте. SIP позволяет пользователю находиться в любом месте, но требует

указания его глобального адреса (как правило, адреса электронной по-

чты), который не зависит от его местонахождения.

Доставка описания сессии (Delivering session description).

Второй функцией SIP является описание сессии, предлагаемой пользо-

вателю. Наиболее распространенным протоколом, используемым для

этой цели, является Session Description Protocol (SDP).

Управление активной сессией (Active Session management).

После отправки описания сессии SIP передает запрос на запуск сеанса

соответствующему узлу сети. Если получен ответ "Принять", сессия

становится активной. Если сессия включает в себя мультимедийные

компоненты, потоки мультимедиа могут передаваться между двумя

пользователями. Для транспортировки данных в реальном времени ис-

пользуются протоколы RTP и RTCP. SIP может быть использован также

для изменения параметров активного сеанса (удаление некоторых пото-

ков видео, снижения качества потока аудио и т.д.).

Завершение сессии (Session Termination). При окончании се-

анса SIP используется для завершения текущей сессии.

Таким образом, SIP является только сигнальным протоколом и

должен использоваться совместно с протоколами типа SDP, RTP, RTCP

и т.п. для обеспечения полной архитектуры мультимедийного сервиса в

соответствии с H.323. Отметим, что функциональность и действия SIP

не зависят от других протоколов.

Сигнальная система SIP состоит из следующих элементов:

Пользовательские агенты (User Agents): элемент системы,

действующий от имени конечного пользователя. User-Agent Client

(UAC) инициирует запросы SIP, в то время как User-Agent Server

(UAS) получает такие запросы и возвращать ответы.

Сетевые серверы (Network Servers): существует три типа се-

тевых серверов:

o Сервер регистрации: отслеживает местоположение

пользователей.

o Прокси-сервер: маршрутизатор уровня приложений,

получающий запрос SIP и пересылающий его на сле-

дующий сервер.

o Перенаправляющий сервер: получает запросы и воз-

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

агента SIP или сервера, на котором пользователь может

быть найден.

43

Часто все три типа серверов реализуются в единой программе.

SIP основан на модели передачи запрос-ответ типа HTTP. Каждая

транзакция состоит из запроса, который вызывает конкретный метод

или функцию на сервере и получает по крайней мере один ответ. Как и

для HTTP, все запросы и ответы используют текстовое представление.

Некоторые команды и ответы SIP, а также их использование, отражены

в таблице 3.3.

Table 3.3

Команды и ответы SIP

Метод Использование

INVITE Приглашение пользователя

ACK Обмен приглашениями

BYE Завершение сеанса между двумя точками

CANCEL Завершение поиска пользователя

OPTIONS Получение информации о параметрах вызова

REGISTER Получение информации о местоположении пользователя для сер-

вера регистрации SIP.

Формат сообщения для SIP показан на рис. 3.3. Тело сообщения

отделено от заголовка пустой строкой. Поле ‘Via’ содержит хост и порт,

от которого ожидается ответ. Когда сообщение SIP проходит через

множество прокси-серверов, каждый прокси-сервер добавляет свой ад-

рес и порт в это сообщение. Это дает возможность получателю отпра-

вить ответ через те же прокси-серверы. Поля ‘From’ и ‘To’ специфици-

руют SIP URI отправителя и получателя приглашения, обычно в виде

адреса электронной почты. Поле ‘call-Id’ содержит глобальный уни-

кальный идентификатор этого вызова. Поля ‘Content-Length’ и ‘Content-

Type’ поясняют содержимое тела сообщения SIP.

44

Рис. 3.3: Типичная сессия SIP

На рис. 3.3 приведен простой пример, в котором отражается суть

операций SIP. Вызывающий клиент приглашает участников на сессию.

Клиент SIP создает приглашение INVITE для callee@uic.edu, которое

посылается на прокси-сервер (Шаг 1). Этот прокси-сервер пытается по-

лучить IP-адрес сервера SIP, который управляет запросами в данном

домене. Прокси-сервер консультируется с Location Server для определе-

ния следующего сервера (Шаг 2). Location server не является сервером

SIP и запоминает информацию о следующих серверах для разных поль-

зователей, возвращая адрес IP найденного участника (Шаг 3). Получив

этот адрес, прокси-сервер пересылает приглашение INVITE (Шаг 5)

машине-хосту. При достижении UAS (User Agent Server), передается от-

вет OK на прокси-сервер (Шаг 8), предполагая, что запрос принят.

Прокси-сервер посылает OK клиенту (Шаг 9). Клиент подтверждает по-

лучение ответа, посылая сообщение ACK (Шаг 10). После этого между

двумя клиентами устанавливается сессия мультимедиа. В конце этой

сессии принимающий клиент посылает сообщение BYE посылающему

клиенту(Шаг 11), который завершает сессию другим сообщением BYE

(Шаг 12).

45

Глава 4. Введение в RTP

В этой главе рассматривается протокол RTP, начиная с положен-

ных в его основу базовых принципов и используемых стандартов. В

конце главы рассматриваются возможные пути развития RTP и соответ-

ствующих ему стандартов.

4.1. Базовые принципы RTP

Перед создателями протокола RTP стояла задача разработки меха-

низма надежной доставки мультимедийной информации по ненадеж-

ным сетям. Они достигли этой цели на основе двух принципов: фраг-

ментирования информации на уровне приложений и принципа ко-

нечных точек.

Фрагментирование информации на уровне приложений позволяет

учитывать специфику передаваемой информации и, как следствие,

уменьшать число ошибок передачи. Только приложение может оценить

существенность возникшей ошибки и принять решение о необходимо-

сти повторной пересылки фрагмента или другого способа устранения

обнаруженной ошибки.

Что касается принципа конечных точек, то он означает, что ответ-

ственность за надежность передачи информации возлагается на ее от-

правителя и получателя, а не на промежуточные пункты маршрута пе-

редачи. Такой подход позволяет значительно упростить механизм пере-

дачи данных для промежуточных пунктов, исключая операции обнару-

жения и исправления ошибок передачи.

4.2. Стандартные элементы RTP

Стандарт RTP был опубликован в январе 1996 года (RFC 1889).

Протокол состоит из двух частей – протокола передачи данных и свя-

занного с ним протокола управления. Первый отвечает за доставку

данных реального времени между конечными пунктами маршрута. Он

включает порядковый номер пакета для предотвращения потерь паке-

тов, метку времени для восстановления временных характеристик,

SSRC- и CSRS-идентификаторы, маркер существенных событий в пере-

даваемом потоке. В деталях протокол будет рассмотрен позже.

Протокол управления RTP (RTP control protocol – RTCP) обес-

печивает получение информации о качестве принимаемых данных и

46

идентификаторе получателя, а также синхронизацию потоков. Более де-

тально протокол RTCP также будет обсуждаться в дальнейших главах.

Отметим ограничения, вводимые протоколом RTP. Во-первых,

стандарт не определяет алгоритмов проигрывания аудио или видео дан-

ных, восстановления временных характеристик, синхронизации между

мультимедиа потоками, обнаружения и устранения ошибок, контроля

перегрузок сети. Все это остается в сфере деятельности разработчика

приложения, а так как разные приложения предъявляют разные требо-

вания в этой области, то стандартизировать их было бы ошибкой.

Во-вторых, некоторые характеристики передачи остаются откры-

тыми и могут отражать специфику формата передаваемых данных (еди-

ница временной шкалы, отметки различных событий в рамках передава-

емого потока и т.д.).

Протокол RTP также определяет формат передаваемых данных

(payload format), ссылка на который есть в профиле RTP (RTP profile).

Профиль может задавать некоторые общие свойства используемых

форматов данных. В целом данная структура позволяет работать с раз-

личными кодеками, используемыми для сжатия передаваемой инфор-

мации.

Кроме всего перечисленного, существуют форматы передаваемых

данных, содержащие схемы коррекции данных. Эта тема также будет

детально рассмотрена в следующих главах учебного пособия.

В заключение отметим, что элементами формата RTP могут быть

два опциональных элемента: сжатие заголовка (header compression) и

мультиплексирование (multiplexing).

4.3. Связанные с RTP стандарты

Протокол RTP связан еще с рядом стандартов. Полный стек прото-

колов показан на рис. 4.1.

Рис. 4.1. Полный стек протоколов, связанных с RTP

47

При старте сессии RTP в зависимости от сценария приложения мо-

гут быть использованы дополнительные протоколы.

При старте интерактивной сессии (голосовом телефонном вызове

или телеконференции) используются два протокола. Основными явля-

ются рекомендации ITU H.323, а в последнее время к ним добавляют

протокол SIP (Session Initiation Protocol).

При старте не интерактивной сессии (просмотре видео по сети)

используется протокол RTSP (Real-Time Streaming Protocol).

При старте упрощенной модели конференции (одностороннее ве-

щание) используется в чистом виде протокол RTP с мультивещанием

по протоколу IP. Для анонсирования конференции добавляется прото-

кол SAP (Session Announcement Protocol).

Для настройки сессии часто используется протокол SDP (Session

Description Protocol). Независимо от формата описания сессии, есть ряд

параметров, которые обязательно должны быть в него включены. Необ-

ходимо передавать транспортные адреса потоков, формат и профиль

данных, время активности и цель сессии.

SDP объединяет все эти параметры в файле текстового формата,

сформированном в простой и понятной для анализа форме. В некоторых

случаях этот файл направляется непосредственно в приложение RTP,

давая достаточную информацию для прямого подключения к сессии. В

других случаях протокол служит базой для переговоров о включении в

проходящую сессию с более жестким контролем участников. Более де-

тально протокол SDP будет рассмотрен в дальнейших главах пособия.

Хотя протокол RTP предназначен для работы с высокоэффектив-

ными сервисами, обеспечиваемыми протоколом IP, иногда бывает по-

лезным резервирование сетевых ресурсов для обеспечения повышенно-

го качества сервисов для потоков RTP. Для этих целей в настоящее вре-

мя применяются две основные структуры ─ интегрирующие и диффе-

ренцирующие сервисы.

Интегрирующие сервисы используют протокол RSVP (Resource

ReSerVation Protocol). Перед началом сеанса хост передает маршрутиза-

тору информацию, необходимую для резервирования, что повышает ка-

чество передачи информации.

Дифференцирующие сервисы добавляют в сами пакеты информа-

цию о требуемом сервисе. Это позволяет маршрутизатору расставить

приоритеты для сервисов, что тоже снижает вероятность потери переда-

ваемой информации.

48

4.4. Сессии RTP

Сессия состоит из группы участников, обменивающимися данными

по протоколу RTP. Каждый участник может присутствовать в несколь-

ких RTP сессиях одновременно. Сессия идентифицируется сетевым ад-

ресом и парами портов отправления и получения информации, причем

эти пары могут быть одинаковыми.

Каждая пара состоит из двух смежных портов: порта с четным но-

мером для пакетов данных RTP и порта с нечетным номером (на едини-

цу больше) для управляющих пакетов RTCP. По умолчанию пара пор-

тов 5004 и 5005 определена для UDP/IP, но многие приложения в про-

цессе настройки сессии переопределяют эти стандартные номера. Сес-

сия RTP разработана для передачи только одного типа мультимедийной

информации, поэтому для каждого такого типа организуется своя сес-

сия.

Сессия может быть односторонней (либо напрямую между двумя

участниками, либо в виде центрального сервера, транслирующего ин-

формацию) или широковещательной (группа участников).

4.5. Структура пакета RTP

Формат пакета RTP показан на рис. 4.2. Он состоит из четырех ос-

новных частей: обязательного RTP заголовка; опционального расшире-

ния заголовка; опционального заголовка данных (зависящего от форма-

та данных); самих данных.

Рис. 4.2. Формат пакета RTP

49

4.6. Проверка качества пакета

Так как RTP сессии обычно используют динамические пары пор-

тов, то очень важно определять, что полученный пакет действительно

является пакетом RTP. На первый взгляд, эта задача не тривиальна, так

как пакет не содержит обозначения протокола. Однако наблюдая после-

довательность полей заголовка в нескольких пакетах, можно быстро

определить условие принадлежности пакета к RTP потоку.

Существует два типа таких тестов:

пакетная проверка, основанная на знании полей заголовка;

потоковая проверка, основанная на знании структуры полей

заголовка.

Первый тип проверки больше подходит для проверки дефектных

пакетов, но подразумевает дополнительную нагрузку на получателя

данных. Выгоднее всего сначала провести проверку второго типа, и

только потом для оставшихся пакетов проводить проверку первого ти-

па.

Также возможно проводить проверку качества пакетов с помощью

контрольных пакетов RTCP, но такая проверка влечет за собой задерж-

ки в передаче потока, что часто недопустимо.

4.7. Трансляторы и миксеры

В дополнение к нормальным конечным системам протокол RTP

включает промежуточные обработчики, которые работают с потоком в

процессе его передачи. Определены два класса таких обработчиков –

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

Транслятором называется промежуточная система, работающая с

RTP данными во время создания источника синхронизации и временной

схемы потока данных. Примером являются системы, осуществляющие

перекодировку между форматами без их смешивания, являясь мостом

между разными транспортными протоколами или фильтрами этого по-

тока. Трансляторы невидимы для конечных RTP систем, если у них нет

предварительной информации о кодировке данных. Известные типы

трансляторов:

Мосты (Bridges). Этот тип трансляторов не меняет кодировки

данных, поэтому чаще всего не изменяет передаваемого потока.

Примером являются различные межсетевые интерфейсы (gate-

ways).

Транскодеры (Transcoders). Основная функция транскодеров –

преобразование кодировки данных в соответствии со спецификой

используемой сети.

50

Эксплодеры (Exploders). Эксплодеры (множители) из одного па-

кета делают несколько.

Мерджеры (Mergers). Из нескольких пакетов делают один.

Миксером называется промежуточная система, собирающая RTP

пакеты из нескольких источников и генерирующая на их основе общий

пакет, возможно с изменением кодировки данных. Так как временные

характеристики входящих потоков обычно не синхронизированы, зада-

ча синхронизации ложится на миксер. Миксеры могут использовать бу-

феры проигрывания для временного хранения данных потоков. Миксер

имеет свой собственный SSRC, который он вставляет в формируемый

пакет данных. Идентификаторы SSRC из входящих пакетов копируются

в CSRC список выходного пакета. Пример системы с миксером приве-

ден на рис. 4.3.

Рис. 4.3. Система с миксером (М) и пятью участниками сессии (A,B,X,Y,Z)

51

Глава 5. Описание протокола RTCP

Протокол RTP состоит из двух частей: протокола передачи данных,

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

щего протокола, который и рассматривается ниже. Управляющий про-

токол RTCP обеспечивает периодическую отчетность о качестве приня-

тых данных, идентификацию получателей, извещение об изменении со-

става участников сессии, а также получение информации, необходимой

для синхронизации потоков.

5.1. Компоненты RTCP

Реализация RTCP включает три части: форматы пакетов, временные

правила и базу данных участников.

Пять стандартных форматов пакетов и правила управления частотой

их пересылки будут описаны позже.

Каждое изменение отображается в базе данных участников сессии

на основе информации, получаемой из пакетов RTCP. Эта база исполь-

зуется для составления периодических отчетов о качестве принятой ин-

формации и для синхронизации звука и изображения. Более детально

эта тема будет описана в дальнейших разделах учебного пособия.

5.2. Передача пакетов RTCP

Каждая сессия RTP идентифицируется сетевым адресом и парой

портов (для передачи пакетов RTP и RTCP). Порт RTP имеет четный

номер, а номер порта RTCP на единицу больше. Например, если данные

передаются по протоколу на порт 5004, контрольный канал будет рабо-

тать по порту 5005.

Все участники сессии посылают свои пакета RTCP и получают их

от других участников. Отметим, что информация обратной связи посы-

лается всем участникам сессии, либо индивидуально с использованием

транслятора, либо сразу всем в режиме мультивещания. В результате

каждый участник сессии имеет полную информацию о других участни-

ках: их присутствии, качестве приема и опционально – персональные

данные, такие как имя, адрес электронной почты, местоположение и те-

лефон.

5.3. Формат пакетов RTCP

Спецификацией RTCP определены пять стандартных форматов:

отчет получателя RR (Receiver Report);

52

отчет отправителя SR (Sender Report);

описание источника SDES (Source DEScription);

управление участниками BYE;

определяемый приложением APP.

Все эти форматы имеют общую структуру, показанную на рис. 5.1,

хотя заносимая в поля информация отличается для каждого типа форма-

та.

Рис. 5.1. Структура стандартного формата пакета RTCP

Заголовок пакета длиной 4 байта содержит 5 полей:

номер версии V (Version number), обычно равен 2;

дополнение P (Padding). Этот бит служит индикатором сде-

ланной операции дополнения. Если он равен 1, то к концу па-

кета добавлен один или несколько дополнительных байтов, в

последнем из которых записано их количество;

количество элементов IC (Item count). В каждый пакет может

быть включено до 31 элемента. Если число элементов больше,

они делятся на несколько пакетов. Те типы пакетов, которым

не нужна данная информация, могут использовать это поле для

других целей;

тип пакета PT (Packet type). Один из пяти стандартных типов;

длина пакета (Length), следующего за заголовком (в 32-битных

единицах).

Пакеты RTCP никогда не передаются поодиночке, они всегда груп-

пируются перед передачей, формируя составные пакеты. Каждый со-

ставной пакет включает один пакет нижнего уровня (чаще всего

UDP/IP) для транспортировки. Если составной пакет должен быть за-

шифрован, группа RTCP пакетов предваряется случайным 32-битным

целым. Структура составного пакета изображена на рис. 5.2. Правила

формирования групп пакетов RTCP будут изложены в соответствую-

щем разделе.

53

Рис. 5.2. Структура составного пакета RTCP

5.4. Безопасность и конфиденциальность

При работе по протоколу RTCP есть несколько моментов, влияю-

щих на сохранения конфиденциальности информации, например, ис-

пользование пакетов описания источника (source description packets).

Хотя эти пакеты опциональны, их использование может раскрыть важ-

ные персональные данные, поэтому приложения не пересылают пакеты

SDES без предварительного информирования пользователя о возмож-

ных последствиях.

Использование же пакетов SDES CNAME является исключением,

так как они обязательно должны присутствовать. Включение в CNAME

IP адреса может при этом иметь некоторые последствия, но эта инфор-

мация уже присутствует в заголовке самого IP пакета.

Доступ к имени пользователя может иметь более существенные по-

следствия, но в этом случае приложение может либо не включать имя

пользователя в пакеты, либо заменить его на другое.

Некоторые участники сессии могут не желать, чтобы их присут-

ствие было видно остальным участникам сессии. Для этого случая

54

необходима возможность пересылки пакетов RTCP избранному кругу

участников сессии.

Для достижения конфиденциальности потока информации может

быть использовано ее шифрование. Шифрованные составные пакеты

содержат случайную 32-битную добавку, как показано на рис. 5.3.

Более детально вопросы безопасности и конфиденциальности бу-

дут рассмотрены далее в соответствующей главе.

Рис. 5.3. Пример шифрованного пакета RTCP, показывающий правильное ис-

пользование заполнителей

5.5. Проверка корректности данных

В первую очередь следует распознавать RTP и RTCP пакеты. Пра-

вила составления пакетов, рассмотренные ранее, позволяют проводить

их строгую проверку. Успешность этой проверки дает существенную

гарантию корректности соответствующего RTP потока, хотя это не ис-

ключает и проверку самого потока.

55

В приводимом ниже примере показан фрагмент псевдокода, прове-

ряющий корректность пакетов.

validate_rtcp(rtcp_t *packet, int length)

rtcp_t *end = (rtcp_t *) (((char *) packet) +

length);

rtcp_t *r = packet;

int l = 0;

int p = 0;

// All RTCP packets must be compound packets

if ((packet->length+ 1) * 4) == length) {

... error: not a compound packet

}

// Check the RTCP version, packet type, and padding of

the first

// in the compound RTCP packet...

if (packet->version != 2) {

...error: version number != 2 in the first subpacket

}

if (packet-> p != 0) {

...error: padding bit is set on first packet in com-

pound

}

if ((packet->pt != RTCP_SR) && (packet->pt != RTCP_RR))

{

...error: compound packet does not start with SR or

RR

}

// Check all following parts of the compound RTCP pack-

et. The RTP

// version number must be 2, and the padding bit must be

zero on

// all except the last packet.

do {

if (p == 1) {

...error: padding before last packet in compound

}

if (r-> p) {

p = 1;

}

if (r-> version != 2) {

...error: version number != 2 in subpacket

}

l += (r->length + 1) * 4;

r = (rtcp_t *) (((uint32_t *) r) + r->length + 1);

} while (r < end);

56

// Check that the length of the packets matches the

length of the

// UDP packet in which they were received...

if ((l != length) || (r != end)) {

...error: length does not match UDP packet length

}

...packet is valid

}

В этом примере необходимо отметить несколько ключевых момен-

тов.

Все пакеты должны быть составными пакетами RTCP.

Поле версии всех пакетов имеет значение 2.

Тип поля в первом RTCP пакете составного пакета должно

быть со значением SR или RR.

Если заполнение необходимо, то дополняется только послед-

ний пакет в составном пакете. Значение бита поля заполнения

для остальных пакетов должно быть равно нулю.

Сумма значений полей длины отдельных пакетов должна соответ-

ствовать длине составного пакета.

5.6. База данных участников сессии

Каждое приложение в RTP сессии создает базу данных о самой

сессии и ее участниках. Информация о сессии, на основе которой про-

исходит настройка характеристик сессии по времени, может хранится в

виде набора переменных.

Пропускная способность (RTP bandwidth), рассчитываемая

при старте сессии.

Фрагмент пропускной способности (RTCP bandwidth frac-

tion), задаваемый как процент от общей пропускной способно-

сти для использования при пересылке отчетов RTCP. Обычно

это значение равно 5 %, но профиль может его изменять,

вплоть до значения 0, означающего отказ от использования па-

кетов RTCP.

Средний размер RTCP пакетов, получаемых и передаваемых

участником.

Количество участников сессии, количество участников, ко-

торым был послан последний пакет RTCP, и части участников,

пересылавших эти пакеты в предыдущем отчетном интервале.

Время последней отсылки пакетов RTCP и время следую-

щей передачи.

57

Флаг, указывающий на пересылку RTCP пакетов всем участ-

никам.

Кроме того, необходимо создавать переменные для формирования

пакетов RTCP SR.

Количество переданных RTCP пакетов и байтов данных.

Последний номер пакета.

Соответствие между временем RTP пакетов и меткой времени

формата NTP.

Структура данных сессии, содержащая эти переменные, является

хорошим местом для хранения используемых SSRC, SDES приложения

и дескрипторов RTP и RTCP каналов.

Для правильного формирования RTCP пакетов каждому участнику

сессии необходимо отслеживать состояние остальных участников. Хо-

рошим путем решения этой задачи является хранение такой информа-

ции в базе данных. Она может включать следующие данные:

идентификатор SSRC;

описание источника (CNAME и другая информация);

информация, полученная из отчетов отправителя для обеспе-

чения синхронизации изображения и звука;

последнее время получения информации от неактивных участ-

ников;

флаг, показывающий, пересылались ли участником данные в

текущий отчетный интервал;

буфер накопления мультимедийной информации перед проиг-

рыванием;

любая информация, необходимая при кодировании канала и

обнаружения ошибок.

В RTP сессии участники идентифицируются своими идентифика-

торами SSRC. Так как участников может быть много и они могут обра-

щаться к базе данных в любом порядке, то наиболее приемлемым видом

базы данных участников является хэш-таблица, индексированная по

идентификатору SSRC. Для приложений, работающих с единственным

форматом медиа, этого вполне достаточно. Однако для синхронизации

звука и изображения требуется доступ по параметру CNAME, поэтому

хэш-таблица должна быть проиндексирована и по этому параметру.

Участники должны добавляться в базу данных при получении от

них проверенного пакета. Этап проверки здесь весьма важен, так как

приложение не должно заносить в базу информацию о непроверенных

участниках. На эту тему можно сформулировать два совета:

58

если пакет RTCP получен и проверен, соответствующий участ-

ник обязательно должен быть добавлен в базу. Проверка паке-

та RTCP достаточно строга, поэтому вероятность прохождения

через нее неправильного пакета незначительна;

заполнение базы должно происходить не только на основе RTP

пакетов, за исключением случаем прибытия пакетов строго в

порядке их номеров. Проверка пакета RTP недостаточно стро-

га, поэтому вероятность прохождения через нее неправильного

пакета высока.

Эти советы предполагают создание дополнительной упрощенной

базы «подозрительных» участников сессии, в которую включаются

участники, отправляющие только пакеты RTP. Для предотвращения ис-

пользования некорректными пакетами слишком большого объема памя-

ти в этой таблице должно быть жесткое ограничение по времени и мак-

симальному размеру.

Каждый идентификатор CSRC, имеющийся в проверенном пакете,

тоже должен был добавлен в базу.

Когда новый участник добавляется в базу, необходимо увеличивать

количество участников на уровне сессии. Такое добавление может быть

причиной повторного просмотра RTCP пакетов.

Участники удаляются из базы при получении пакета BYE или в ре-

зультате превышения установленного периода неактивности. Это зву-

чит просто, но скрывает некоторые проблемы. Нет гарантии, что пакеты

будут получены в той же последовательности, как они были отправле-

ны, поэтому пакет BYE может быть получен раньше последнего пакета

с данными от этого отправителя. Обычно приложения после получения

пакета BYE делают задержку в 2 секунды для получения запоздавших

пакетов с данными и лишь потом удаляют этого участника сессии.

Источники могут быть удалены, если они не присылают отчетов в

течение пяти отчетных периодов. Если отчетные интервалы менее 5 се-

кунд, то используется минимальное значение 5 секунд.

Процедура повторного просмотра RTCP пакетов будет рассмотрена

более подробно в соответствующем разделе пособия.

5.7. Управление характеристиками времени

Частота, с которой участники сессии посылают RTCP пакеты, не

фиксирована и изменяется в зависимости от количества участников и

формата передаваемых в потоке данных. Целью является ограничить

объем передачи пакетов RTCP выделенной для этих целей частью про-

пускной способности канала (обычно эта доля составляет 5 %). Эта цель

59

достигается снижением частоты отправления пакетов RTCP при увели-

чении числа участников сессии. При телефонном разговоре двух участ-

ников с использованием протокола RTP отчеты RTCP посылаются с ин-

тервалом в несколько секунд, а при вещании для тысяч участников – с

интервалом в несколько минут.

Каждый участник сам решает, когда посылать пакеты RTCP на ос-

нове набора правил, которые будут описаны далее. Очень важно строго

выполнять эти правила, особенно в случае участия в больших сессиях. В

противном случае может произойти перегрузка сети.

5.7.1. Отчетные интервалы

Составные пакеты RTCP пересылаются периодически, в соответ-

ствии со случайным таймером. Среднее время ожидания очередного па-

кета RTCP участником называется отчетным интервалом. На его

значение влияют следующие факторы:

пропускная способность канала, выделенная под RTCP.

Обычное значение – 5 % от скорости передачи данных в сессии. По-

следняя устанавливается до сессии и служит параметром ее конфигури-

рования;

средний размер передаваемых и получаемых RTCP паке-

тов. В этот размер входят не только передаваемые данные, но и UDP и

IP заголовки;

общее количество участников и процент отправителей

среди них. Эти данные необходимы для создания базы данных участни-

ков.

5.7.2. Базовые правила передачи

Когда приложение стартует, первый RTCP пакет отправляется на

основе вычисленного отчетного интервала. Реальный интервал между

пакетами определяется случайным образом от половинного значения

отчетного интервала до полуторного, для предотвращения одновремен-

ного прибытия всех отчетов. Для первого пакета берется половина от-

четного интервала, для обеспечения быстрой обратной связи с новым

пользователем.

5.7.3. Процедура пересмотра вперед

Как уже упоминалось ранее, проходит несколько отчетных интер-

валов, прежде чем новый участник узнает общий размер сессии. На

протяжении этого периода изучения новый участник посылает пакеты

RTCP чаще, чем это установлено, так как ему не хватает информации.

60

Этот факт становится существенным, когда много новых участников

одновременно присоединяются к сессии. Такая ситуация типична для

начала сессии.

В этом случае при использовании только базовых правил передачи

данных каждый участник будет исходить из отсутствия на данный мо-

мент других участников сессии и соответствующим образом структури-

ровать первый пакет RTCP. Он перешлет этот пакет в среднем через по-

ловину минимального отчетного интервала и будет строить следующий

пакет на основе количества присоединившихся на данный момент

участников, которых может быть несколько сотен или даже тысяч. Из-за

низкого начального вычисленного количества участников сессии будет

наблюдаться резкий рост нагрузки на сеть, что часто приводит к ее пе-

регрузке.

5.7.4. Процедура пересмотра назад

Как и при одновременном подключении пользователей, проблемы

возникают и при одновременном их отключении (этап завершения сес-

сии). Проблема возникает не с перегрузкой сети, а со слишком больши-

ми задержками в отчетах оставшихся участников сессии. Эти задержки

могут восприниматься как длительное молчание и пользователи в этом

случае отмечаются как неактивные.

Проблема решается путем, аналогичным способу, примененному в

предыдущем разделе. При получении каждого пакета BYE пересчиты-

вается число участников сессии и время отсылки следующего пакета.

Разница с процедурой пересмотра вперед заключается в направлении

изменения времени отсылки пакетов, которое в этом случае уменьшает-

ся, а не увеличивается.

Процедура пересмотра назад применяется при числе пользователей

в несколько сотен, когда есть вероятность быстрого уменьшения числа

участников сессии.

5.7.5. Пересмотр пакетов BYE

Участники сессии, решившие ее покинуть, посылают пакет BYE и

затем выходят из сессии. Если это происходит для многих участников

одновременно, может произойти перегрузка сети.

Для предотвращения этой нежелательной ситуации текущая версия

RTP разрешает посылать пакет BYE немедленно только в том случае,

если число участников сессии менее 50. При числе участников более 50

пакет BYE отсылается с задержкой, если в это время получен такой же

61

пакет от другого участника. Этот процесс называется пересмотром па-

кетов BYE (BYE reconsideration).

Этот процесс аналогичен процессу просмотра вперед, но базирует-

ся на числе полученных пакетов BYE, а не на числе участников сессии.

Перед отправкой пакета BYE учитывается число принятых пакетов это-

го типа от других участников и пересчитывается время отправления

этого пакета. Эта процедура повторяется до тех пор, пока пакет не будет

отослан.

Данная операция полезна только в случае многочисленных сессий,

в которых возможен одновременный выход большого числа участников.

5.7.6. Общие проблемы реализации

Наиболее общими проблемами реализации являются:

Некорректное масштабирование при увеличении числа участ-

ников сессии. Наблюдается при использовании фиксированно-

го отчетного интервала.

Отсутствие рандомизации отчетного интервала. Приводит к

перегрузкам в сети.

Не включение заголовков протоколов нижнего уровня при раз-

личных вычислениях размеров пакетов.

Некорректное использование заполнителей. Если заполнение

необходимо, оно проводится только для последнего пакета

RTCP в составном пакете.

При тестировании поведения приложений, работающих с RTP сес-

сиями, необходимо использовать не один сценарий, а их спектр, меняя в

них характеристики сессий (число участников, доля отправителей и

т.д.).

62

Глава 6. Захват мультимедиа, проигрывание и управление характеристиками времени

В этой главе мы отойдем от обсуждения протоколов и рассмотрим

создание систем, работающих по протоколу RTP. Реализация RTP имеет

много аспектов, часть из которых касается всех систем, а другая – ис-

пользуется опционально при необходимости.

6.1. Поведение отправителя

Как отмечалось ранее, отправитель отвечает за захват мультимедиа

(«живого» потока или файла), сжатие данных для их передачи, генера-

цию RTP пакетов. Он может также участвовать в коррекции ошибок и

контроле перегрузок сети путем адаптации передаваемого потока в от-

вет на отчеты его получателей.

Работа отправителя начинается с чтения несжатых данных мульти-

медиа (аудио потока или видео фрагментов) в буфер, из которого потом

создаются сжатые фреймы. Фреймы могут быть сжаты несколькими

способами, в зависимости от выбранного алгоритма сжатия, а сами

фреймы могут зависеть от предыдущих или последующих данных.

Сжатым фреймам назначается метка времени и номер в последова-

тельности, после чело они загружаются в RTP пакеты и готовы к пере-

даче. Если фрейм не помещается в один пакет, он может быть фрагмен-

тирован на несколько пакетов. Если фреймы достаточно малы, в один

пакет могут быть помещено несколько фреймов. В зависимости от ис-

пользуемой схемы коррекции ошибок кодировщик канала может ис-

пользоваться для генерации пакетов коррекции ошибок или перестанов-

ки пакетов. Затем отправитель периодически отсылает отчеты в виде

RTCP пакетов для генерируемых потоков и получает отчеты о качестве

полученной информации от других участников сессии, имея возмож-

ность на их основе адаптировать параметры потока. Все эти моменты

будут рассмотрены далее.

6.2. Захват мультимедиа и сжатие

Процесс захвата мультимедиа практически одинаков как для звука,

так и для изображения. Несжатый фрейм захватывается, при необходи-

мости преобразуется в подходящий для сжатия формат, а затем с помо-

щью кодировщика создается сжатый фрейм. Полученный фрейм про-

63

пускается через программу пакетизации, в результате чего получается

один или несколько пакетов RTP.

6.2.1. Захват и сжатие звука

Рис. 6.1 иллюстрирует процесс захвата звука рабочей станцией с

его оцифровкой и сохранением во входном звуковом буфере.

Рис. 6.1. Захват звука

Входной звуковой буфер обычно делают доступным для приложе-

ния, когда в нем накопится фиксированное количество сэмплов (сэмпл –

амплитудная выборка, т.е. выходной уровень звука в данный момент).

Большинство приложений для захвата звука забирают данные из вход-

ного звукового буфера фреймами фиксированной продолжительности,

каждый раз ожидая, пока в буфере накопится полный фрейм. Это при-

водит к появлению задержки в получении очередной порции звука. Для

уменьшения влияния этой задержки размер фрейма устанавливается в

соответствии с размером буфера используемого кодека (обычно 20 или

30 миллисекунд).

Несжатый фрейм, полученный от устройства захвата звука, может

содержать не один, а несколько типов сэмплов. Обычно эти устройства

возвращают 8-, 16- или 24-битные сэмплы со скоростью от 8000 до

96000 сэмплов в секунду (моно или стерео).

64

Многие звуковые кодеки обнаруживают паузы в передаче звука,

выбрасывая фреймы без звука или содержащие только фоновый шум.

Это дает более эффективное использование канала передачи информа-

ции.

6.2.2. Захват и сжатие изображения

Устройства захвата изображения чаще работают с полными фрей-

мами, чем с полосами сканирования или областями изображения. Мно-

гие предлагают работу с пониженным разрешением и разным размером

фреймов, их форматом и глубиной цвета.

В зависимости от используемого кодека, бывает необходимо пре-

образовать фрейм из формата устройства захвата изображения в другой

формат. Алгоритмы такого преобразования находятся за пределами во-

просов, рассматриваемых в данном учебном пособии. Наиболее часто

встречаемое преобразование состоит в переходе между цветовой схемы

RGB и YUV. Такое преобразование ускоряет обработку фреймов на ос-

нове использования специальных команд процессора. На рис 6.2 пока-

зан процесс захвата изображения (NTSC сигнал со схемой YUV) и пре-

образование его в формат RGB.

Рис. 6.2. Захват изображения

Захваченные фреймы перед их сжатием кодировщиком помещают-

ся в буфер. Размер буфера зависит от используемой схемы сжатия.

Устройства захвата и звука, и изображения могут сразу осуществ-

лять их сжатие. Эта функция реализована в специализированных

устройствах, хотя встречается и в продвинутых рабочих станциях. Та-

65

кие фреймы можно напрямую передавать в поток RTP, хотя могут быть

наложены некоторые ограничения на его характеристики.

Вне зависимости от типа мультимедиа и использованного способа

сжатия результатом данного этапа является последовательность сжатых

фреймов с указанным временем захвата. Эти фреймы поступают в мо-

дуль RTP для пакетизации и передачи.

6.2.3. Использование предварительно записанной информации

Подготовленные фреймы обычно поступают на этап пакетизации в

том же порядке, в каком они были захвачены. Протокол RTP не делает

различий между предварительно записанной информацией и «живым»

потоком.

В частности, в начале предварительно записанной информации от-

правитель должен сгенерировать новый идентификатор SSRC и выбрать

случайные значения для метки времени и порядкового номера. В про-

цессе передачи он должен управлять SSRC коллизиями, получать и от-

правлять пакеты RTCP.

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

файла и помещать его содержимое тоже в файлы. Вместо этого он ис-

пользует процесс запоминания и пакетизации «на лету» (рис.6.3).

Рис. 6.3. Использование предварительно записанной информации

6.3. Генерация пакетов RTP

Сгенерированные сжатые фреймы передаются процедуре пакетиза-

ции. Каждому фрейму соответствует метка времени, из которой получа-

ется метка времени RTP. Если формат данных поддерживает фрагмен-

тацию, большие фреймы разделяются на максимально допустимые для

передачи фрагменты (обычно это необходимо только для видео). Нако-

66

нец, один или несколько RTP пакетов, содержащих заголовок и соб-

ственно данные, генерируются для каждого фрейма. Формат пакета и

его заголовка определяется используемым кодеком. Критической ча-

стью процесса генерации пакетов является назначение фреймам меток

времени, фрагментирование больших фреймов и генерация заголовков

данных. Эти моменты мы и обсудим более подробно.

6.3.1. Метки времени и модель времени RTP

Метка времени представляет момент получения первого байта дан-

ных. Значение начинается со случайно сгенерированного числа и воз-

растает со скоростью, определяемой передаваемыми данными.

В процессе захвата «живого» потока мультимедиа метка времени

обозначает момент получения первых сэмплов с устройства захвата. Ес-

ли речь идет о синхронизированных звуковых и видео потоках, то надо

быть уверенным, что время обработки потоков разного типа учтено при

вычислении метки времени. Для большинства звуковых форматов метка

времени RTP для каждого очередного пакета возрастает пропорцио-

нально числу входящих в него сэмплов, а не байтов данных его длины.

Исключением является форматы звука MPEG, включая формат MP3,

который использует частоту 90 КГц в данных для совместимости с дру-

гими форматами MPEG. Большинство форматов видео также использу-

ют часы 90 КГц, что дает им возможность увеличивать значение метки

времени целыми значениями шага. Например, при использовании стан-

дартной для NTSC скорости 29.97 фреймов в секунду и использовании в

данных частоты 90 КГц метка времени RTP будет увеличиваться на

3.003 на каждый пакет.

Для потока, предварительно записанного в файле, метка времени

дает время фрейма в последовательности фреймов плюс постоянное

случайное смещение. Метки времени назначаются для фреймов, поэто-

му, если большой фрейм фрагментируется, каждый фрагмент будет

иметь одинаковую метку времени.

Спецификация RTP не гарантирует детальность, точность и ста-

бильность часов данных. Каждое приложение само решает эту задачу.

Метка времени в RTP данных и отсылаемых отправителем RTCP

пакетах отражает параметры времени у отправителя. Отметим, что мо-

дель времени RTP ничего не говорит о времени проигрывания переда-

ваемых данных. Метки времени данных дают относительные параметры

времени и RTCP отчеты отправителя помогают синхронизировать раз-

ные потоки. Но RTP ничего не говорит о количестве буферов, использу-

емых для проигрывания данных или о времени их раскодирования.

67

Хотя модель времени детально описана в спецификации RTP, в ней

нет упоминания об алгоритмах, используемых при реконструкции па-

раметров времени на стороне получателей пакетов. Это сделано пред-

намеренно, так как такие алгоритмы зависят от требований самого при-

ложения.

6.3.2. Фрагментация

Процесс фрагментации большого фрейма проиллюстрирован на

рис. 6.4. Каждый фрагмент имеет метку времени всего фрейма и допол-

нительный заголовок данных, описывающий этот фрагмент.

Рис. 6.4. Фрагментация большого фрейма

Процесс фрагментации критичен к потере пакетов. Желательна

возможность декодирования отдельных фрагментов, в противном слу-

чае потеря одного фрагмента приводит к потере всего фрейма.

После фрагментации отправитель должен решить, будет ли он по-

сылать все фрагменты одновременно, или последовательно через опре-

деленный интервал. Первый вариант может привести к перегрузке сети,

поэтому рекомендуется выбирать второй.

6.3.3. Заголовки, зависящие от формата данных

В дополнение к заголовку RTP и самим передаваемым данным

мультимедиа пакеты часто содержат заголовки, зависящие от формата

данных. Этот заголовок определяет спецификацию используемого фор-

мата данных и обеспечивает переход от RTP к выходу кодека.

Типичное использование дополнительного заголовка происходит

при адаптации форматов данных, не предназначенных для передачи в

сетях с потерями. Правильно разработанные заголовки данных суще-

68

ственно расширяют сферу применения таких форматов. Более детально

эта тема будет рассмотрена позднее.

6.4. Поведение получателя

Как уже отмечалось ранее, получатель отвечает за прием пакетов

из сети, восстановление и корректировку потерянных и поврежденных

пакетов, восстановление характеристик времени, декодирование данных

и представление результата пользователю. Кроме того, от получателя

ожидают присылку пакетов RTCP для обеспечения адаптации процесса

передачи данных к характеристикам используемых сетей. Получатель

также обычно создает базу данных об участниках сессии.

Первым шагом в процессе получения данных сессии является соб-

ственно сбор пакетов из сети, проверка их корректности и выстраивание

в последовательности, заданной отправителем. Это достаточно простые

операции, не зависящие от формата данных. Далее этот процесс будет

описан подробнее.

Остальные операции выполняются в стиле отправителя и зачастую

зависят от формата принимаемых данных. Пакеты из входной очереди

передаются программе кодирования и проверяются на потери. Коди-

ровщик помещает пакеты в очереди по типу данных мультимедиа, где

они ожидают получения полного фрейма и достижения времени проиг-

рывания. Процедура вычисления размера задержек будет рассмотрена

далее в соответствующем разделе.

Иногда до достижения времени проигрывания пакеты группируют-

ся в полные фреймы с восстановлением потерянных или поврежденных

фреймов, после чего они декодируются. В завершение полученные дан-

ные подготавливаются для пользователя. В зависимости от формата

данных и используемого проигрывающего устройства каждый поток

может проигрываться отдельно (например, два потока видео в разных

окнах). В других случаях бывает необходимо смешать данные из разных

потоков в один. Каждая из этих операций также будет рассмотрена да-

лее.

Операции, выполняемые получателем, сложнее операций, выпол-

няемых отправителем. Многие из этих осложнений связаны с необхо-

димостью восстановления потерянной при передаче информации.

6.5. Получение пакетов

RTP сессия включает в себя как потоки данных, так и потоки

управления, работающие с назначенными портами (обычно четным для

потока данных и нечетным для потока управления). Это означает, что

69

принимающее потоки приложение должно открывать два сокета (сокет

– объект, являющийся конечным элементом соединения, обеспечиваю-

щего взаимодействие между процессами транспортного уровня сети),

один – для данных, второй – для управления. Так как RTP работает в

стеке протоколов UDP/IP, он использует стандартные сокеты

SOCK_DGRAM.

После создания сокетов приложение подготавливается к получе-

нию пакетов по сети и хранению их для последующей обработки. Мно-

гие приложения реализуют это в виде цикла, повторяющегося при по-

лучении очередных пакетов.

Пакеты данных и управления проверяются на корректность, как

описывалось в предыдущих разделах. Интервал повторения цикла по-

лучения пакетов выбирается по интервалу между фреймами.

Для организации процесса получения пакетов может использовать-

ся и событийный подход: пакеты в этом случае обрабатываются по мере

их поступления. Обычно такой подход применяется при условии работы

в реальном времени.

6.5.1. Получение пакетов данных

Первой стадией проигрывания данных мультимедиа по сети явля-

ется получение пакетов и их буферизация для дальнейшей обработки.

Так как сеть часто изменяет интервал времени между пакетами, как по-

казано на рис. 6.5, то несколько пакетов могут появиться в короткий ин-

тервал времени или могут возникнуть большие паузы между поступле-

нием пакетов. Получатель не знает заранее, когда прибудут очередные

пакеты, поэтому он должен быть готов к получению нескольких пакетов

сразу, причем в любом порядке.

После получения пакетов они проверяются на корректность и до-

бавляются в очередь для дальнейшей обработки в порядке возрастания

их меток времени. Эти шаги разрывают связь между временем прибы-

тия пакетов и временем их обработки и проигрывания для пользователя.

На рис. 6.6 показано разделение между получением пакетов и програм-

мами проигрывания, которые имеют доступ только к входным очере-

дям.

70

Рис. 6.5. Нарушение интервала времени между пакетами при их транспор-

тировке по сети

Рис. 6.6. Отделение процесса получения пакетов от их проигрывания

71

Важно запоминать точное время прибытия пакетов M, чтобы иметь

возможность рассчитать соответствующие статистические характери-

стики. Неточное измерение может привести к появлению задержек в пе-

редаче пакетов. Время прибытия измеряется по реальному времени по-

лучателя T и преобразуется в потоковое время R:

M=T×R+смещение

Здесь смещение используется для перехода от относительного

времени к потоковому времени, корректируя разницу между ними.

Как отмечалось ранее, процесс приемки пакетов в приложении мо-

жет чередоваться с их обработкой, или эти действия могут быть разде-

лены по разным ветвям логики работы приложения. В первом случае

одна ветвь осуществляет и прием пакетов, и их обработку перед проиг-

рыванием. За один цикл работы все пришедшие пакеты считываются из

сокета и вставляются в правильном порядке в очередь проигрывания.

Во втором случае одна ветвь приложения занимается приемкой пакетов

и формированием из них очереди. Другие ветви занимаются декодиро-

ванием данных и подготовкой их к проигрыванию.

Независимо от выбранного варианта приложение не может прини-

мать и обрабатывать пакеты непрерывно. Входные очереди сглаживают

флуктуации для процесса проигрывания в приложении, но что делать с

задержками в поступлении пакетов? К счастью, большинство операци-

онных систем общего назначения управляют приемкой пакетов UDP/IP

на основе управления прерываниями и могут буферизовать пакеты на

уровне сокета, даже если в это время принимающее приложение занято.

Принятый по умолчанию буфер сокета подходит для большинства при-

ложений, но приложения, работающие с высокоскоростными сетями,

могут увеличить размер буфера до необходимого. Правда, это может

привести к увеличению задержек в получении пакетов, но в приложе-

нии можно соответственно увеличить значение задержки проигрывания,

что компенсирует данный отрицательный эффект.

6.5.2. Получение управляющих пакетов

Параллельно процессу приемки пакетов данных приложение долж-

но быть готово к получению, проверке, обработке и отсылке пакетов

RTCP. Информация пакетов RTCP используется при создании базы

данных об участниках сессии, как было описано в предыдущей главе, а

также для проверки и идентификации участников, адаптации парамет-

ров сети и синхронизации звука и изображения.

72

Одноканальные приложения обычно обрабатывают и пакеты дан-

ных, и пакеты RTCP в одном цикле. Многоканальные приложения вы-

деляют одну ветвь для приема и обработки управляющих пакетов. Так

как частота появления пакетов RTCP намного меньше, чем для пакетов

данных, загрузка их обработчика невелика и не критична по времени.

Однако следует запоминать точное время прибытия пакетов SR с отче-

тами отправителя, так как это время используется при генерации пакета

RR получателя и участвует в вычислении времени передачи по сети.

После получения пакета RTCP с отчетом отправителя или получа-

теля содержащаяся в нем информация сохраняется. Синтаксический

разбор блоков отчетов в пакетах SR и RR достаточно несложен. Поле

count в заголовке пакета RTCP показывает количество блоков отчета,

причем значение 0 допустимо и показывает, что отправитель пакета

RTCP не получал пакетов данных RTP.

Главным назначением пакетов RTCP является отслеживание каче-

ства приемки отправленных пакетов с данными. Если отчеты показы-

вают плохое качество приема, то можно либо добавить коды предупре-

ждения ошибок, либо уменьшить скорость отправки пакетов. В сессии с

несколькими отправителями можно отслеживать качество других от-

правителей. Приложения обычно сохраняют информацию из отчетов

для последующего ее использования при подстройке процесса передачи

данных.

Отчеты отправителей содержат также информацию о соответствии

часов данных RTP и относительных часов отправителя, используемую

для синхронизации звука и изображения.

Когда приходит пакет SR, его информация сохраняется и может

быть показана пользователю. Каноническое имя CNAME в пакете

SDES обеспечивает связь между потоками звука и изображения. Другое

направление его использования – группировка потоков, идущих от од-

ного отправителя (например, при передаче изображения с нескольких

камер).

После проверки качества пакетов RTCP их информация добавляет-

ся в базу данных об участниках сессии. Так как проверка качества паке-

тов RTCP достаточно строга, то наличие участника в базе указывает,

что он действительно существует. Это полезный параметр проверки па-

кетов RTP.

Когда приходит пакет RTCP BYE, соответствующий вход в базу

данных помечается для последующего удаления. Как отмечалось в

предыдущей главе, удаление не выполняется немедленно, давая воз-

можность получить задержанные пакеты данного отправителя. Еще од-

73

на операция, выполняемая на основе этой информации – удаление неак-

тивных пользователей.

6.6. Буфер проигрывания

Пакеты данных извлекаются из входной очереди и вставляются в

определенный источником буфер проигрывания в соответствии с их

метками времени. Фреймы задерживаются в очереди проигрывания,

чтобы сгладить неравномерность поступления данных по сети. Эта за-

держка позволяет также получить и собрать вместе фрагменты больших

фреймов. В завершении процесса фреймы подвергаются декомпрессии,

а полученная мультимедийная информация подготавливается для поль-

зователя. Рис. 6.7 иллюстрирует этот процесс.

Рис. 6.7. Буфер проигрывания

Один и тот же буфер может быть использован и для компенсации

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

Но возможно и разделение этих функций, однако это не является жест-

ким требованием для RTP.

6.7. Декодирование, смешивание и проигрывание

Завершающей стадией процесса проигрывания является декодиро-

вание сжатых данных, смешивание отдельных потоков и собственно

проигрывание данных для пользователя.

6.7.1. Декодирование

Для каждого активного источника приложение должно использо-

вать декодер. Декодер может быть реальным физическим устройством

или программным средством. Он преобразует сжатый фрейм в несжа-

тые данные, как показано на рис. 6.8.

74

Рис. 6.8. Декомпрессия фреймов декодером

Если часть фреймов потеряна, декодер может выдать некорректный

результат. В этом случае в процессе проигрывания может возникнуть

пауза.

6.7.2. Смешивание звука

Смешивание является процессом объединения нескольких потоков

в один. Этот случай более всего характерен для звуковых приложений,

которые получают звук из нескольких источников, а проигрывают его

на одном комплекте воспроизведения, например, при проведении теле-

конференции. Процесс смешивания показан на рис. 7.9.

Рис. 7.9. Смешивание звука

75

Глава 7. Синхронизация звука и изображения

Сессия мультимедиа состоит из нескольких потоков, каждый из ко-

торых передается в отдельной сессии RTP. Так как задержки, связанные

с форматами кодирования, существенно различаются, то в разных пото-

ках будет разное время проигрывания, как показано на рис. 7.1.

Рис. 7.1. Синхронизация потоков мультимедиа

Обычно синхронизация применяется для выравнивания потоков

звука и изображения, но данная технология может применяться для лю-

бых типов потоков.

Часто разделение звука и изображения на отдельные потоки дик-

туют предпочтения участников сессии. Некоторые в видеоконференци-

ях предпочитают получать только звук. Это особенно важно для конфе-

ренций с большим количеством участников.

7.1. Поведение отправителя

Отправитель помогает в процессе синхронизации потоков мульти-

медиа путем запуска общих часов и периодического уведомления через

пакеты RTCP о рассогласовании общего и потокового времени. Общие

часы идут с постоянной скоростью, а получателю дается информация,

помогающая выравнивать скорости в потоках, как показано на рис. 8.2.

76

Рис. 8.2. Выравнивание времени по общим часам

Соответствие между общим временем и потоковым определяется в

момент формирования пакета RTCP. Общее время Treference отражается в

метке времени пакета RTP:

TRTP = Treference × Raudio + Oaudio

Отсюда получаем смещение часов:

Oaudio = Taudio – (Tavailable – Daudio_capture) × Raudio

Здесь Tavailable определяется задержками операционной системы, а

Daudio_capture – длительностью процесса захвата данных.

На рис. 7.3 демонстрируется необходимость синхронизации часов,

когда потоки мультимедиа получаются из разных источников.

Еще одна проблема синхронизации – идентификация потоков, к ко-

торым она должна быть применена. RTP решает ее путем выдачи свя-

занным источникам общих имен (CNAME), поэтому получатель разли-

чает зависимые и независимые потоки.

77

Рис. 7.3. Синхронизация потоков от разных источников

7.2. Поведение получателя

Получатель должен выделить синхронизируемые потоки и выров-

нять их перед проигрыванием. Первое достигается достаточно просто

использованием одинаковых имен CNAME в разных потоках. Сложнее

сама процедура синхронизации (рис. 7.4 и 7.5).

Рис. 7.4. Синхронизация звука и изображения на стороне пользователя

78

Рис. 7.5. Установление соответствия времен на стороне пользователя

Получатель вначале определяет соответствие между общим време-

нем, установленным отправителем, и временем синхронизируемых по-

токов путем сравнивания данных RTP и RTCP пакетов. При получении

пакета данных RTP с меткой времени M может быть вычислено время

захвата:

R

MMTT srSsr

s

)(

Здесь Msr – метка времени RTP в последнем полученном пакете

RTCP, TSsr – общее время в секундах, R – номинальная скорость часов

данных в герцах. Получатель также вычисляет время вывода синхрони-

зированных данных TR согласно локальным часам. Оно равно метке

времени пакета, согласованной с общим временем отправителя, плюс

задержка в буфере проигрывания для декодирования, смешивания и об-

работки.

Когда время захвата и проигрывания известны, получатель может

вычислить относительную задержку между захватом данных и их про-

игрыванием для каждого потока. Если данные захвачены во время TS

по общему времени отправителя и выводятся в момент времени TR по

часам получателя, то разница между ними D = TR – TS даст величину за-

держки между захватом изображения и его выводом. Из-за того, что ча-

сы отправителя и получателя не синхронизированы, это значение вклю-

79

чает в себя неизвестное смещение между ними, но его можно игнориро-

вать, так как оно одинаково для всех синхронизируемых потоков, а нас

интересует только относительное смещение между потоками.

После вычисления этой задержки как для потока звука, так и для

потока изображения можно вычислить собственно задержку синхрони-

зации потоков D = Daudio – Dvideo. Если это значение получится равным

нулю, то потоки синхронизированы. В противном случае оно дает сме-

щение между потоками в секундах.

Для опережающего потока данных задержка синхронизации умно-

жается на номинальную скорость потока данных для преобразования

значения в формат метки времени данных и затем используется как зна-

чение постоянного смещения во всех вычислениях времени.

Пользователь в соответствии со своими приоритетами может вы-

бирать, по какому потоку проводить синхронизацию. Для большинства

кодеков кодирование и декодирование видео является доминирующим

фактором, но звук более чувствителен к происходящим изменениям.

Задержку синхронизации необходимо пересчитывать при измене-

нии задержки проигрывания любого из потоков. Это также необходимо

при изменении соотношения между общим временем и временем пото-

ка.

7.3. Точность синхронизации

Может возникнуть вопрос, каким значением задержки между пото-

ками можно пренебречь? Ответ на этот вопрос зависит от ряда факто-

ров, в том числе от того, что синхронизируется и с какой целью.

Например, синхронизация звука и изображения может быть достаточно

нестрогой и изменяться в зависимости от качества видео и скорости

фреймов, в то время как синхронизация звуковых потоков должна быть

очень точной.

При синхронизации звука и изображения считается достаточной

точность синхронизации в рамках нескольких десятком миллисекунд.

Эксперименты с проведением видеоконференций дают граничное зна-

чение порядка 80-100 миллисекунд, превышение которого не следует

допускать. При повышении качества передаваемого изображения этот

порог уменьшается.

80

Глава 8. Компенсация ошибок

Предыдущие главы рассматривали прохождение потока RTP по

протоколам UDP/IP в ненадежных сетях и соответствующее поведение

приложений. Возникающие в процессе передачи данных ошибки можно

либо компенсировать, либо корректировать. Рассмотрим оба этих вари-

анта.

8.1. Компенсация потерь звука

Когда пакет RTP, содержащий звук, независимо от того, речь это

или музыка, потерян, то получатель должен генерировать его замени-

тель, чтобы обеспечить непрерывность воспроизведения. Это можно

сделать разными способами в зависимости от степени чувствительности

системы к ошибкам.

8.1.1. Измерение качества звука

Восприятие звука человеком – комплексный процесс, зависящий от

многих факторов. Это делает достаточно трудным оценку качества зву-

ка. Недостаточно просто сравнить отправленный и принятый звук, по-

тому, что восприятие различий не соответствует этой разнице напря-

мую. Простые измерители, такие как отношение уровня сигнала к уров-

ню шума, здесь не подходят. Более сложные схемы дают результат, но

не со 100 % надежности.

Из-за отсутствия объективных мер измерения приходится приме-

нять субъективные тесты. Такие тесты включают проигрывание разных

типов музыки, набора слов, фраз и предложений с оценкой качества ре-

альным слушателем по заданной шкале.

Шкала выбирается в зависимости от типа оцениваемых данных.

Если это речь, то можно применять шкалу MOS (Mean Opinion Score).

Это пятибалльная шкала (excellent = 5, good = 4, fair = 3, poor = 2, bad =

1). Для обеспечения статистической значимости оценки ее надо прово-

дить на большом количестве тестов и разных примерах. Типичное зна-

чение качества передачи звука для обычных телефонных переговоров

имеет оценку около 4.2, а для мобильной сети – от 3.5 до 4.

Шкала MOS дает достаточно стабильные результаты, но не разли-

чает специфику передаваемых данных. Даже при высокой оценке нельзя

гарантировать понятность принятой речи. Поэтому данная оценка

81

обычно дополняется серией синтаксических тестов, на основе которых

подсчитывается статистическая оценка качества передачи данных.

8.1.2. Замещение периодами тишины

Простейшая техника замещения потерянных пакетов периодами

тишины показана на рис. 9.1.

Рис. 8.1. Замещение потерянных пакетов периодами тишины

Данная техника применима только к очень коротким пакетам (ме-

нее 16 миллисекунд) при низкой доле потерянных пакетов (менее 2

процентов), иначе она приводит к существенному падению качества пе-

редачи данных.

8.1.3. Замещение шума

Процесс замещения шума показан на рис. 9.2.

82

Рис. 8.2. Замещение шума

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

цесс.

void

substitute_noise(sample previous_frame[samples_per_frame],

sample missing_frame[samples_per_frame)

{

double energy;

// Calculate energy (amplitude) of the previous frame

energy = 0.0;

for(j = 0; j < samples_per_frame; j++) {

energy += previous_frame[j] * previous_frame[j];

}

energy = sqrt(energy);

// Fill in the noise

for(j = 0; j < samples_per_frame; j++) {

missing_frame[j] = energy * random(-1,1);

}

}

8.1.4. Повторение

На рис. 8.3 показан типичный речевой сигнал.

83

Рис. 8.3. Типичный речевой сигнал

На рис. 8.4 показано восстановление речевого сигнала путем по-

вторения.

Рис. 8.4. Восстановление речевого сигнала

8.2. Компенсация потерь изображения

Многие кодеки видео используют межфреймовую компрессию, посы-

лаю не следующий фрейм, а его отличия от предыдущего, как показано

на рис. 8.5.

Потеря пакета с промежуточной информацией приведет в этом

случае к незначительному искажению части передаваемого кадра. С

другой стороны, потеря основного кадра может влиять на ряд следую-

щих пакетов.

84

Рис. 8.5. Межфреймовая компрессия

8.2.1. Компенсация передвижения

Часто при потере пакета вместо него используют содержимое

предыдущего пакета. Но это напрямую допустимо только при отсут-

ствии существенного передвижения в кадре. В противном случае при-

ходится восстанавливать вектор движения, анализируя сохранившиеся

кадры. На рис. 8.6 показано восстановление положения единственного

потерянного блока.

Рис. 8.6. Восстановление потерянного блока

8.3. Чередование (Interleaving)

При применении технологии чередования меняется порядок дан-

ных перед их передачей, в результате чего соседние данные передаются

на достаточно большом расстоянии между ними. На рис. 8.7 потеря че-

85

тырех пакетов в потоке с чередованием приводит потере четырех изо-

лированных пакетов после восстановления исходного порядка данных.

Рис. 8.7. Передача с чередованием

Чередование может применяться на уровне пакетов RTP, но чаще

всего происходит чередование фреймов в передаваемых пакетах. В по-

следнем случае в пакетах нарушается последовательность меток време-

ни. Примером применения такой схемы является известный формат для

передачи звука MP3.

86

Глава 9. Исправление ошибок и контроль перегрузок

Хотя сглаживание ошибок достаточно важно, лучше их избегать

или исправлять. Рассмотрим две базовые категории технологий исправ-

ления ошибок.

9.1. Прямое исправление ошибок

Алгоритмы системы прямого исправления ошибок FEC (Forward

error correction) преобразуют битовый поток, делая его устойчивым к

передаче. Дополнительная информация, содержащаяся в преобразован-

ном битовом потоке, позволяет получателю точно реконструировать ис-

ходный битовый поток при наличии ошибок передачи.

Если отправитель пакетов RTP использует FEC, он должен на ос-

нове анализа ошибок сети определить долю дополнительной информа-

ции корректировки ошибок, помещаемой в каждый пакет. Одним из

способов решения данной задачи является наблюдение за пакетами

RTCP, приходящими от получателей.

Теоретически путем выбора схемы FEC можно гарантировать от-

сутствие ошибок при приеме данных. Практически же приходится учи-

тывать, что дополнительная информация, передаваемая в потоке, еще

больше нагружает сеть и увеличивает количество ее ошибок. Поэтому

речь идет о корректировке ошибок с определенным уровнем вероятно-

сти.

Ключевое преимущество схемы FEC заключается в возможности ее

применения к большим сессиям, в которых некоторые получатели во-

обще не отсылают пакетов RTCP, а главный недостаток – в прямой за-

висимости объемов дополнительной информации от уровня ошибок в

сети.

9.1.1. Контроль четности

Контроль четности является простейшим способом обнаружения и

корректировки ошибок. Передаваемые данные преобразуются с помо-

щью логической операции XOR:

0 XOR 0 = 0

1 XOR 0 = 1

0 XOR 1 = 1

1 XOR 1 = 0

На рис. 9.1 показан процесс восстановления данных.

87

Рис. 9.1. Контроль четности

Пакеты FEC могут передаваться и как отдельные потоки (рис. 9.2).

Рис. 9.2. Пакеты FEC в отдельном потоке

Формат пакетов FEC определен в соответствующих стандар-

тах. Некоторые распространенные схемы проверки на четность пред-

ставлены на рис. 9.3.

88

Рис. 9.3. Возможные схемы проверки на четность

9.1.2. Неравномерная защита от ошибок

Если данные содержат очень важную часть, то ее можно защитить

с помощью неравномерной защиты от ошибок ULP (Unequal Layered

Protection). Формат пакета RTP с такой защитой показан на рис. 9.4.

Рис. 9.4. Защита по схеме ULP

89

9.1.3. Коды Рида-Соломона

Коды Рида-Соломона преобразуют каждый блок данных с помо-

щью коэффициентов полиномиального уравнения. Они меньше загру-

жают каналы передачи, но требуют более сложной обработки.

9.1.4. Избыточное кодирование звука

Схема данного кодирования приведена на рис. 9.5.

Рис. 9.5. Избыточное кодирование звука

9.2. Кодирование канала

В этом случае для контроля качества передачи используется либо

контрольная сумма пакетов UDP, либо частичная контрольная сумма.

На рис. 9.6 приведен пример использования частичной контрольной

суммы для пакетов данных в формате AMR.

Рис. 9.6. Пакет с частичной контрольной суммой

90

9.3. Повторная передача

Повторная передача является естественным вариантом корректи-

ровки ошибок передачи. Повторную передачу можно проводить с ис-

пользованием канала RTCP, так как именно по нему приходит инфор-

мация об ошибках передачи.

Стандартное описание RTCP имеет строгие правила управлением

характеристиками времени. Профиль повторной передачи модифициру-

ет эти правила, что приводит к кратковременным превышениям лимита

передачи, хотя в целом скорость передачи остается прежней.

На рис. 9.7 представлены режимы повторной передачи.

Рис. 9.7. Режимы повторной передачи

Следует отметить, что использование различных схем коррекции

ошибок приводит к повышению сложности алгоритмов работы как при-

ложений-отправителей, так и приложений-получателей.

9.4. Контроль перегрузок

До сих пор мы предполагали, что можно направить мультимедий-

ный поток с его естественной скоростью, и что случаи потери пакетов

должны быть учтены. В реальной ситуации, однако, мультимедийный

поток, скорее всего, делит сети с другими потоками и мы должны рас-

смотреть эту ситуацию.

9.4.1. Необходимость контроля перегрузок

Результаты перегрузки сети наглядно показаны на рис. 9.8.

91

Рис. 9.8. Перегрузка сети

Как видим, в результате перегрузки сети пересылка пакетов может

упасть до нуля. Широкое вещание еще более усложняет проблему кон-

троля перегрузки сети, так как отправителям приходится адаптировать

передачу данных для большого количества пользователей, требования

которых могут быть противоречивы.

Решение проблемы лежит в уровневом кодировании, когда отпра-

витель разделяет передачу данных на несколько групп (уровней) широ-

кого вещания, а получатели подсоединяются только к части доступных

групп. Естественно, что такой подход требует и кодеков, которые могут

работать с разными уровнями сети передачи. Пример такого кодирова-

ния приведен на рис. 9.9.

92

Рис. 9.9. Уровневое кодирование

93

СПИСОК ЛИТЕРАТУРЫ

1. A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamen-

tal Concepts and Key Architectures, McGraw-Hill, 2000.

2. J. Leigh, O. Yu, D. Schonfeld, R. Ansari, et. al., “Adaptive networking

for tele-immersion”, Proc. Immersive Projection Technolo-

gy/Eurographics Virtual Environments Workshop (IPT/EGVE),

Stuttgart, Germany, 2001.

3. D. Salomon, Data Compression: The Complete Reference, Springer,

1998.

4. V.K. Garg, IS-95 CDMA and cdma2000, Prentice Hall, 1999.

5. W. Kinsner, "Compression and its metrics for multimedia", Proceed-

ings of First IEEE International Conference on Cognitive Informatics,

2002, pp: 107-121.

6. J. Watkinson, The MPEG Handbook: MPEG-I, MPEG-II, MPEGIV,

Focal Press, 2001.

7. L.C. Wolf, C. Griwodz and R. Steinmetz, "Multimedia Communica-

tion", Proceedings of the IEEE, vol: 85(12), December 1997.

8. J. Kurose and K. Ross, Computer Networking: A top-down approach

featuring the Internet, Addision Wesley, 2001.

9. G. Kessler, “An overview of cryptography”, online version available at

http://www.garykessler.net/library/crypto.html

10. J. Su, F. Hartung, and B. Girod, "Digital Watermarking of Text, Image,

and Video Documents", Computers & Graphics, vol: 22 (6), pp: 687 -

695, February 1999.

11. B. P. Crow, I. Widjaja, J.G. Kim, P.T. Sakai, "IEEE 802.11: Wireless

Local Area Networks", IEEE Communications Magazine, September

1997.

12. D. Bertsekas and R. Gallager, Data Networks, Prentice Hall, 1987.

13. R. Steinmetz, "Analyzing the multimedia operating system", IEEE

Multimedia, vol: 2(1), Spring 1995, pp: 68-84

14. Yu, O. and Khanvilkar, S., “Dynamic Adaptive Guaranteed QoS

Provisioning over GPRS Wireless Mobile Links”, ICC2002, vol: 2, pp:

1100-1104.

15. L.C. Wolf, C. Griwodz and R. Steinmetz, "Multimedia Communica-

tion", Proceedings of the IEEE, vol: 85(12), December 1997.

16. B. Furht, “Real-time issues in distributed multimedia systems”, Pro-

ceedings of the Second Workshop on Parallel and Distributed Real-

Time Systems, April 1994, pp: 88-97.

94

17. N. Tang, S. Tsui and L. Wang, "A Survey of Admission Control Algo-

rithms", on-line report available at http://www.cs.ucla.edu/~tang/

18. A. Tanenbaum, Computer Networks, 3e, Prentice Hall, 1996.

19. M. Labrador and S. Banerjee, “Packet Dropping policies for ATM and

IP networks”, IEEE communication surveys, 3rd

Quarter 1999, vol:

2(3).

20. W. Sun and R. Jain, “QoS/policy/constraint based routing”, Class re-

port avail. on-line at ftp://ftp.netlab.ohio-

state.edu/pub/jain/courses/cis788-99/qos_routing/index.html.

21. Z. Avramovic, “Policy based routing in the Defense Information Sys-

tem Network”, IEEE Military Communications Conference, vol: 3, pp:

1210-1214.

22. F. Kuipers, P.V. Mieghem, T. Korkmaz and M. Krunz, "An Overview

of Constraint-Based Path Selection Algorithms for QoS Routing",

IEEE Communications Magazine, December 2002.

23. P. P. White, “RSVP and integrated services in the Internet: a tutorial”,

IEEE Communications Magazine, vol: 35(5), May 1997, pp: 100-106.

24. R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, "Resource

ReSerVation Protocol (RSVP): Version 1 Functional Specification",

RFC2205, September 1997.

25. D. Schonfeld, “Image and Video Communication Networks”, (Invited

Chapter). Handbook of Image and Video Processing. A. Bovik (ed.),

Academic Press: San Diego, California, Chapter 9.3, pp. 717-732,

2000.

26. E. Rosen, A. Viswanathan, R. Callon, “Multiprotocol Label Switching

Architecture”, RFC3031, January 2001.

27. M. Banikazemi, R. Jain, "IP Multicasting: Concepts, Algorithms, and

Protocols", Class report avail. on-line at http://ftp.netlab.ohio-

state.edu/pub/jain/courses/cis788-97/ip_multicast/index.htm

28. ] L.H. Sahasrabuddhe and B.M. Mukherjee, "Multicast Routing

Algorithms and Protocols: A Tutorial", IEEE Network, Janu-

ary/February 2000.

29. A. Striegel and G. Manimaran, "A Survey of QoS Multicasting Issues",

IEEE Communications Magazine, June 2002.

30. M. Handley and V. Jacobson, “SDP: Session Description Protocol”,

RFC2327, April 1998.

31. A.B. Johnston, Understanding the Session Initiation Protocol, Artech

House, 2000.

32. M. Handley, C. Perkins and E. Whelan, “Session Announcement Pro-

tocol”, RFC2974, October 2000.

95

33. R. Arora, R. Jain, "Voice over IP : Protocols and Standards", Class re-

port avail. on-line at ftp://ftp.netlab.ohio-

state.edu/pub/jain/courses/cis788-99/voip_protocols/index.html

34. B. Cavusoglu, D. Schonfeld, and R. Ansari, “Real-time adaptive for-

ward error correction for MPEG-2 video communications over RTP

networks”, Proceedings of the IEEE International Conference on Mul-

timedia and Expo, Baltimore, Maryland, 2003, to appear.

35. H. Schulzrinne, A. Rao and R. Lanphier, "Real Time Streaming Proto-

col (RTSP)", RFC2326, April 1998.

36. E. Mulabegovic, D. Schonfeld, and R. Ansari, “Lightweight Streaming

Protocol (LSP)”, ACM Multimedia Conference, Juan Les Pins, France,

2002.

37. S. Kent and R. Atkinson, "Security Architecture for the Internet Proto-

col", RFC2401, November 1998.

38. R. Oppliger, “Security at the Internet Layer”, Computer, vol: 31(9),

September 1998.

39. C.E. Perkins, “Mobile networking through Mobile IP”, IEEE In-

ternet Computing, vol: 2(1) Jan/Feb 1998, pp: 58-69.

40. G.A. Thom, "H.323: the multimedia communications standard for lo-

cal area networks", IEEE Communications Magazine , vol: 34(12),

December 1996, pp: 52-56.

41. H. Liu and P. Mouchtaris, "Voice over IP Signaling: H.323 and Be-

yond", IEEE Communications Magazine, October 2000.

42. D. D. Clark and D. L. Tennenhouse. "Architectural Considerations for

a New Generation of Protocols," Proceedings of the SIGCOMM Sym-

posium on Communications Architectures and Protocols, Computer

Communications Review, Volume 20, Number 4, September 1990.

43. J. H. Saltzer, D. P. Reed, and D. D. Clark. "End-to-End Arguments in

System Design," ACM Transactions on Computer Systems, Volume 2,

Number 4, November 1984.

44. M. Handley, J. Crowcroft, C. Bormann, and J. Ott. "Very Large Con-

ferences on the Internet: The Internet Multimedia Conferencing Archi-

tecture," Journal of Computer Networks and ISDN Systems, Volume

31, Number 3, February 1999.

45. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP: A

Transport Protocol for Real-Time Applications," Internet Engineering

Task Force, RFC 1889, January 1996.

46. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. "RTP: A

Transport Protocol for Real-Time Applications," Internet Engineering

Task Force, Work in Progress (Update to RFC 1889), March 2003.

96

47. M. Handley and V. Jacobson. "SDP: Session Description Protocol," In-

ternet Engineering Task Force, RFC 2327, April 1998.

48. H. Schulzrinne. "RTP Profile for Audio and Video Conferences with

Minimal Control," Internet Engineering Task Force, RFC 1890, Janu-

ary 1996.

49. H. Schulzrinne and S. Casner. "RTP Profile for Audio and Video Con-

ferences with Minimal Control," Internet Engineering Task Force,

Work in Progress (Update to RFC 1890), March 2003.

50. M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund,

and K. Norrman. "The Secure Real Time Transport Protocol," Internet

Engineering Task Force, Work in Progress, June 2002.

51. J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey. "Extended RTP

Profile for RTCP-Based Feedback (RTP/AVPF)," Internet Engineering

Task Force, Work in Progress, February 2003.

52. P. Luthi. "RTP Payload Format for ITU-T Recommendation G.722.1,"

Internet Engineering Task Force, RFC 3047, January 2001.

53. K. McKay. "RTP Payload Format for PureVoice Audio," Internet En-

gineering Task Force, RFC 2658, August 1999.

54. H. Schulzrinne and S. Petrack. "RTP Payload for DTMF Digits, Te-

lephony Tones and Telephony Signals," Internet Engineering Task

Force, RFC 2833, May 2000.

55. R. Finlayson. "A More Loss-Tolerant RTP Payload Format for MP3

Audio," Internet Engineering Task Force, RFC 3119, June 2001.

56. T. Turletti and C. Huitama. "RTP Payload Format for H.261 Video

Streams," Internet Engineering Task Force, RFC 2032, October 1996.

57. D. Hoffman, G. Fernando, V. Goyal, and M. Civanlar. "RTP Payload

Format for MPEG1/MPEG2 Video," Internet Engineering Task Force,

RFC 2250, January 1998.

58. C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell,

J. Ott, G. Sullivan, S. Wenger, and C. Zhu. "RTP Payload Format for

the 1998 Version of ITU-T Rec. H.263 Video (H.263+)," Internet En-

gineering Task Force, RFC 2429, October 1998.

59. C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. C.

Bolot, A. Vega-Garcia, and S. Fosse-Parisis. "RTP Payload for Redun-

dant Audio Data," Internet Engineering Task Force, RFC 2198, Sep-

tember 1997.

60. J. Rosenberg and H. Schulzrinne. "An RTP Payload Format for Gener-

ic Forward Error Correction," Internet Engineering Task Force, RFC

2733, December 1999.

97

Чердынцев Евгений Сергеевич

МУЛЬТИМЕДИЙНЫЕ СЕТИ

Учебное пособие

Научный редактор

доктор технических наук,

профессор В.А. Силич

Редактор

Верстка

Дизайн обложки

Подписано к печати . Формат 60х84/16. Бумага «Классика».

Печать RISO. Усл.печ.л. . Уч.-изд.л. .

Заказ . Тираж 100 экз.

Томский политехнический университет

Система менеджмента качества

Томского политехнического университета сертифицирована

NATIONAL QUALITY ASSURANCE по стандарту ISO 9001:2000

. 634050, г. Томск, пр. Ленина, 30.