Разработка структуры сети с пакетной коммутацией на примере оао "московская государственная телефонная сеть". Курс лекций по сетевым технологиям

В данном разделе рассмотрены некоторые аспекты переноса пакетов RTP сетевыми и транспортными протоколами. Если не установлено иначе спецификациями других протоколов, то при передаче пакетов применяются следующие основные правила.

RTP полагается на протоколы нижележащих уровней при обеспечении разделения потоков данных RTP и управляющей информации RTCP. Для протокола UDP и подобных ему протоколов протокол RTP использует четный номер порта, а соответствующий поток RTCP использует порт с номером, на единицу большим.

Информационные пакеты RTP не содержат никакого поля длины, следовательно, RTP полагается на нижележащий протокол и для обеспечения индикации длины. Максимальная длина пакетов RTP ограничивается только протоколами нижележащих уровней.

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

9. Перечень констант протокола

Этот раздел содержит перечень констант, определенных в спецификации протокола RTP.

Константы типа трафика RTP (PT - payload type) определяются в профилях. Однако, октет заголовка RTP, который содержит бит(ы) маркера и поле типа трафика, не должен содержать зарезервированные величины 200 и 201 (десятичный вид), чтобы пакеты RTP отличались от пакетов RTCP SR и RR. Для стандартного формата с одним битом маркера и семибитовым полем типа трафика, это ограничение означает, что типы трафика 72 и 73 использоваться не должны.

Значения типов пакетов RTCP (см. табл.1) выбраны в диапазоне от 200 до 204 для лучшего контроля корректности заголовка пакетов RTCP при сравнении с пакетами RTP. Когда поле типа пакета RTCP сравнивается с соответствующим октетом заголовка RTP, этот диапазон соответствует биту маркера, равному единице (чего обычно не бывает в информационных пакетах) и старшему разряду поля стандартного типа трафика, равному единице (в то время как статически заданные типы трафика обычно имеют значения PT с нулем в старшем разряде). Этот диапазон был также выбран для большего дистанцирования от значений 0 и 255, так как поля, целиком состоящие из нулей или единиц, в основном характерны для данных.

Другие типы пакетов RTCP определяются Сообществом IANA. Разработчики имеют возможность регистрировать значения, которые им требуются для проведения экспериментальных исследований, а затем аннулировать регистрацию по мере исчезновения потребности в этих значениях.

Допустимые типы пунктов пакета SDES представлены в табл. 2 . Другие типы пунктов SDES назначаются Сообществом IANA. Разработчики имеют возможность регистрировать значения, которые им нужны при выполнении экспериментальных исследований, а затем аннулировать регистрацию, когда необходимость в этих значениях исчезнет.

10. Описание профиля и формата трафика

Как отмечалось выше (см. раздел 2), для полного описания протокола RTP для конкретного приложения требуются дополнительные документы двух типов: описание профиля и формата трафика.

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

Дополнительный документ второго типа - спецификация формата трафика - определяет, как конкретный вид трафика (например, видеосигнал, кодированный согласно H.261) должен передаваться в соответствии с RTP. Один и тот же формат трафика может использоваться для множества профилей и может, следовательно, быть определен независимо от профиля. Документы профиля отвечают лишь за соответствие этого формата и значения PT.

В описании профиля могут определяться следующие пункты, но этот список не является исчерпывающим.

Заголовок пакета данных RTP. Октет в заголовке пакета данных RTP, который содержит бит маркера и поле типа трафика, может быть переопределен в соответствии с профилем для удовлетворения различным требованиям, например, для обеспечения большего или меньшего количества битов маркера (раздел 3.3).

Типы трафика. Профиль обычно определяет множество форматов трафика (например, алгоритмов кодирования мультимедийных данных) и заданное по умолчанию статическое соответствие этих форматов и значений РТ. Некоторые из форматов трафика могут быть определены ссылкой на отдельные описания формата трафика. Для каждого определенного типа трафика профиль должен задать необходимую для использования тактовую частоту временной метки RTP (раздел 3.1).

Дополнения заголовка пакета данных RTP. Если требуются некоторые дополнительные функциональные возможности в рамках класса приложений профиля, не зависящих от типа трафика, то к фиксированному заголовку пакета данных RTP могут быть присоединены дополнительные поля.

Расширения заголовка пакета данных RTP. Должно быть определено содержимое первых 16 битов структуры расширения заголовка пакета данных RTP, если использование этого механизма позволено профилем.

Типы пакетов RTCP. Могут быть определены (и зарегистрированы IANA) новые, зависящие от класса приложения типы пакетов RTCP.

Интервал отчетности RTCP. Профиль должен определить величины, используемые при вычислении интервала отчетности RTCP: часть полосы пропускания сеанса RTCP, минимальный интервал отчетности и разделение полосы пропускания между отправителями и получателями.

Расширение пакета SR/RR. Если имеется дополнительная информация об отправителе или получателе, которая должна регулярно передаваться, то для пакетов SR и RR протокола RTCP может быть определен раздел расширения.

Использование SDES. Профиль может определять относительные приоритеты для пунктов SDES протокола RTCP, которые будут переданы или исключены (см. раздел 4.2.2); альтернативный синтаксис или семантику для пункта CNAME (раздел 4.4.1); формат пункта LOC (раздел 4.4.5); семантику и использование пункта NOTE (раздел 4.4.7) и новые пункты SDES, которые должны регистрироваться в IANA.

Безопасность. Профиль может определять, какие услуги по обеспечению безопасности и алгоритмы нужно использовать приложениям, и может обеспечивать управление их использованием (раздел 7).

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

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

Транспортное соответствие. Может быть определено иное, чем указанное в разделе 8 стандартное соответствие RTP и RTCP адресам транспортного уровня, например, портам UDP.

Инкапсуляция. Формирование пакетов RTP может быть определено так, чтобы позволить передавать множество информационных пакетов RTP в одном блоке данных протокола нижележащего уровня (раздел 8).

Для каждого разрабатываемого приложения не должен требоваться новый профиль. Целесообразнее в рамках одного класса приложений расширять существующий профиль, а не создавать новый. Это облегчит взаимодействие приложений, так как каждое обычно выполняется под управлением только одного профиля. Простые расширения, такие как определения дополнительных значений РТ или типов пакетов RTCP, могут быть выполнены путем регистрации их в IANA и публикации их описаний в спецификации профиля или в спецификации формата трафика.

11. Профиль RTP для аудио- и видеоконференций с минимальным управлением

В RFC 1890 приведено описание профиля для использования транспортного протокола реального времени RTP версии 2 и связанного с ним протокола управления RTCP в рамках групповой аудио- или видеоконференции, так называемого профиля RTP для аудио- и видеоконференций с минимальным управлением (RTP Profile for Audio and Video Conferences with Minimal Control). Этот профиль определяет аспекты RTP, не заданные в спецификации протокола RTP версии 2 (RFC 1889). Минимум управления означает, что не требуется никакая поддержка согласования параметров или управления принадлежностью (например, при использовании статических соответствий типов трафика и индикаций принадлежности, обеспечиваемых RTCP). Рассмотрим основные положения данного профиля.

11.1. Форматы пакетов RTP и RTCP и параметры протокола

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

Заголовок информационного пакета RTP. Используется стандартный формат фиксированного заголовка информационных пакетов RTP (один бит маркера).

Типы трафика. Статические значения типов трафика определены в разделах 11.3 и 11.4.

Дополнения заголовков информационных пакетов RTP. К заголовкам информационных пакетов RTP не присоединяются никакие дополнительные фиксированные поля.

Расширения заголовков информационных пакетов RTP. Никакие расширения заголовка информационных пакетов RTP не определены, но приложения, использующие этот профиль, могут использовать такие расширения. То есть, в приложениях не должно быть принято, что бит X заголовка RTP всегда имеет нулевое значение. Приложения должны быть готовы игнорировать расширение заголовка. Если расширение заголовка определится в будущем, то должно быть задано содержимое первых 16 битов таким образом, чтобы можно было идентифицировать множество различных расширений.

Типы пакетов RTCP. Никаких дополнительных типов пакетов RTCP в этой спецификации профиля не определено.

Интервал отчетности RTCP. При вычислении интервала отчетности RTCP должны использоваться константы, предложенные в RFC 1889.

Расширения пакетов SR/RR. Расширения для пакетов SR и RR протокола RTCP не определены.

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

Безопасность. Заданные по умолчанию службы безопасности RTP также определяются по умолчанию этим профилем.

Соответствие пароль-ключ. Вводимый пользователем пароль преобразуется с использованием алгоритма MD5 в 16-октетный дайджест. N-битовый ключ получается из дайджеста, путем использования его первых N битов. Предполагается, что пароль может включать только буквы в коде ASCII, цифры, дефисы и пробелы, чтобы уменьшить вероятность искажений при передаче паролей по телефону, факсу, телексу или электронной почте. Паролю может предшествовать спецификация алгоритма шифрования. Любые символы вплоть до первой наклонной черты вправо (код ASCII 0x2f) воспринимаются, как название алгоритма шифрования. Если наклонная черта вправо отсутствует, то по умолчанию считается, что используется алгоритм шифрования DES-CBC.

Перед применением алгоритма закрытия пароль, вводимый пользователем, преобразуется в каноническую форму. Для этого пароль преобразуется в набор символов ISO 10646 с использованием кодирования UTF-8, как определено в Приложении P к ISO/IEC 10646-1:1993 (символы ASCII не требует никакого преобразования); удаляются пробелы в начале и конце пароля; два или более пробелов заменяются на один пробел (ASCII или UTF-8 0x20); все буквы преобразуются в буквы нижнего регистра

Нижележащий протокол. Профиль определяет использование RTP над протоколом UDP в двухстороннем и групповом режиме.

Транспортное соответствие. Используется стандартное соответствие RTP и RTCP адресам транспортного уровня.

Инкапсуляция. Инкапсуляция пакетов RTP не определена.

11.2. Регистрация типов трафика

Данный профиль определяет стандартные типы кодирования, используемые с RTP. Другие типы кодирования перед использованием должны быть зарегистрированы IANA. При регистрации нового типа кодирования должна быть обеспечена следующая информация:

• условное наименование типа кодирования и тактовая частота временной метки RTP (условные наименования должны иметь длину в три или четыре символа для обеспечения компактного представления, если это необходимо);
• указание того, кто имеет право изменять тип кодирования (например, ISO, CCITT/ITU, другие международные организации по стандартизации, консорциум, конкретная компания или группа компаний);
• любые рабочие параметры;
• ссылки на доступные описания алгоритма кодирования, например (в порядке предпочтения) RFC, изданная статья, регистрация патента, технический отчет, исходный текст кодека или справочник;
• для частных типов кодирований, контактная информация (почтовый адрес и адрес электронной почты);
• величина для обозначения типа трафика этого профиля, в случае необходимости (см. ниже).
• Заметим, что не все типы кодирования, которые нужно использовать с RTP, должны быть назначены статически. Для установления динамического соответствия между значением типа трафика (PT) в диапазоне от 96 до 127 и типом кодирования могут использоваться «не-RTP средства», не рассматриваемые в этой статье.
• Доступное пространство значений типов трафика достаточно мало. Новые типы трафика назначаются статически (постоянно) только, если выполнены следующие условия:
• кодирование в большой степени интересует сообщество сети Internet;
• оно предлагает выгоды, сравнимые с существующими кодированиями и/или требуется для взаимодействия с существующими, широко используемыми системами конференцсвязи или мультимедийными системами;
• описание достаточно для создания декодера.

11.3. Кодирование звукового сигнала

Для приложений, которые не посылают пакеты во время пауз, первый пакет активного участка речи (первый пакет после паузы) отличается установленным в единицу битом маркера в заголовке информационного пакета RTP. Приложения без подавления пауз устанавливают этот бит в нуль.

Тактовая частота RTP, используемая при генерации временной метки RTP, не зависит от числа каналов и типа кодирования; она равна числу периодов дискретизации в секунду. Для N-канального кодирования (стерео, квадро и т.п.) каждый период дискретизации (скажем, 1/8000 секунды) генерирует N отсчетов. Общее число отсчетов, сгенерированных за секунду, равно произведению частоты дискретизации на число каналов.

При использовании нескольких звуковых каналов они нумеруются «слева направо», начиная с первого. В звуковых пакетах RTP данные из каналов с меньшими номерами предшествуют данным из каналов с большими номерами. Для более чем двух каналов используется следующая систем обозначений:

• l - левый;
• r - правый;
• c - центральный;
• S - периферийный;
• F - фронтальный;
• R - тыльный.

Число каналов	Название системы	Номера каналов
		1	2	3	4	5	6
2	стерео	l	r
3		l	r	c
4	квадро	Fl	Fr	Rl	Rr
4		l	c	r	S
5		Fl	Fr	Fc	Sl	Sr
6		l	lc	c	r	rc	S

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

Частота дискретизации должна быть выбрана из множества: 8000, 11025, 16000, 22050, 24000, 32000, 44100 и 48000 Гц (компьютеры Macintosh Apple имеют собственные значения частоты дискретизации 22254,54 и 11127,27, которые могут быть преобразованы в 22050 и 11025 с допустимым качеством путем пропуска четырех или двух отсчетов в 20-миллисекундном кадре). Однако, большинство алгоритмов кодирования звука определено для более ограниченного множества частот дискретизации. Получатели должны быть готовы принимать многоканальный звук, но могут выбирать и монофонический режим.

Для пакетизации звукового сигнала, заданный по умолчанию интервал пакетизации должен иметь продолжительность 20 ms, если при описании кодирования не указано иное значение. Интервал пакетизации определяет минимальную задержку «из конца в конец». В более длинных пакетах под заголовок отводится относительно меньшая часть байтов, но они вызывают большую задержку и делают потери пакетов более значимыми. Для не интерактивных приложений, таких как лекции, или каналов со значительными ограничениями полосы пропускания может быть допустима более высокая задержка пакетизации. Получатель должен принимать пакеты со звуковым сигналом с задержкой от 0 до 200 ms. Это ограничение обеспечивает приемлемый размер буфера для получателя.

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

Для типов кодированиях, основанных на отсчетах и производящих для каждого отсчета один или более октетов, отсчеты из различных каналов, дискретизированные одновременно, упаковываются в соседние октеты. Например, для кодирования стереозвука последовательность октетов такова: левый канал, первый отсчет; правый канал, первый отсчет; левый канал, второй отсчет; правый канал, второй отсчет и т.д. При многооктетном кодировании первым передается старший октет. Упаковка основанных на отсчетах кодирований, производящих менее одного октета для каждого отсчета - определяется алгоритмом кодирования.

Алгоритм основанного на кадре кодирования преобразует блок звукового сигнала фиксированной длины в другой блок сжатых данных, обычно также фиксированной длины. Для основанных на кадрах кодирований отправитель может объединять несколько таких кадров в одно сообщение.

Для основанных на кадрах кодеков, порядок следования каналов определен для целого блока. То есть, для стереозвука отсчеты для левого и правого каналов кодируются независимо; при этом кадр кодирования для левого канала предшествует кадру для правого канала.

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

В табл. 3 представлены значения типов трафика (PT), определенных данным профилем для звуковых сигналов, их условные обозначения и основные технические характеристики алгоритмов кодирования.

11.4. Кодирование видеосигнала

В табл. 4 представлены значения типов кодирования (РТ), условные обозначения алгоритмов кодирования и технические характеристики алгоритмов кодирования видеосигнала, определяемых данным профилем, а также не назначенные, зарезервированные и динамически задаваемые значения РТ.

Значения типа трафика в диапазоне от 96 до 127 могут быть определены динамически через протокол управления конференции, который не рассматривается в данной статье. Например, каталог сеанса может определять, что для данного сеанса связи, тип трафика 96 обозначает кодирование PCMU, двухканальное с частотой дискретизации 8000 Гц. Диапазон значений типа трафика, отмеченный, как «зарезервировано», не используется, чтобы пакеты протоколов RTCP и RTP могли надежно различаться.

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

Звуковые приложения, использующие данный профиль, должны, как минимум, быть способны посылать и получать трафик типа 0 (PCMU) и 5 (DVI4). Это позволяет взаимодействовать без согласования формата.

11.5. Назначение портов

Как определено в описании протокола RTP, данные RTP должны передаваться через порт UDP с четным номером, а соответствующие пакеты RTCP должны передаваться через порт с номером, на единицу большим (нечетным номером).

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

Однако по умолчанию могут быть заданы номера портов 5004 и 5005. Приложения, которые используют множество профилей, могут выбирать эту пару портов, как индикатор данного профиля. Но приложения могут также требовать, чтобы пара портов была задана в явном виде.

12. Список используемых терминов и сокращений

• ASCII (American Standart Code for Information Interchange) - американский стандартный код для обмена информацией. Семиразрядный код для представления текстовой информации, используемый с отдельными модификациями в большинстве вычислительных систем
• CBC (cipher block chaining) - цепочка шифруемых блоков, режим стандарта шифрования данных DES
• CELP (code-excited linear prediction) - тип кодирования звуковых сигналов, использующий линейное предсказание с кодовым возбуждением
• CNAME (canonical name) - каноническое имя
• CSRC (сontributing source) - включаемый источник. Источник потока пакетов RTP, который внес свой вклад в комбинированный поток, произведенный микшером RTP. Микшер вставляет в заголовок пакета протокола RTP список идентификаторов SSRC тех источников, которые участвовали в формировании этого пакета. Этот список называется списком CSRC. Пример: микшер передает идентификаторы говорящих в данный момент участников телеконференции, звуки голосов которых были смикшированы и использованы при создании исходящего пакета, указывая получателю на текущий источник сообщений, даже если все звуковые пакеты содержат один и тот же идентификатор SSRC (такой, как у микшера)
• DES (Data Encryption Standard) - стандарт шифрования данных
• IANA (Internet Assigned Numbers Authority) - Сообщество назначения номеров Internet
• IMA (Interactive Multimedia Association) - Ассоциация интерактивного мультимедиа
• IP (Internet Protocol) - межсетевой протокол, протокол сетевого уровня, дейтаграммный протокол. Позволяет пакетам пересекать на пути к пункту назначения множество сетей
• IPM (IP Multicast) – групповая передача с использованием протокола IP
• LD-CELP (low-delay code excited linear prediction) - алгоритм кодирования речи с использованием линейного предсказания с кодовым возбуждением и низкой задержкой
• LPC (linear predictive encoding) - кодирование с линейным предсказанием
• NTP (Network Time Protocol) - сетевой протокол времени, является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых случаях используется более компактное представление, в котором взяты из полного формата только средние 32 бита: младшие 16 битов целой части и старшие 16 битов дробной части
• RPE/LTP (residual pulse excitation/long term prediction) - алгоритм кодирования речевого сигнала с разностным импульсным возбуждением и долговременным предсказанием
• RTCP (Real-Time Control Protocol) - протокол управления передачей данных в реальном масштабе времени
• RTP (Real-Time Transport Protocol) - транспортный протокол реального времени
• SSRC (synchronization source) - источник синхронизации. Источник потока пакетов RTP, идентифицированный 32-разрядным числовым идентификатором SSRC, который передается в заголовке RTP, независимо от сетевого адреса. Все пакеты с одним источником синхронизации используют единый интервал таймирования и единое пространство порядковых номеров, так что получатель группирует пакеты для воспроизведения с помощью источника синхронизации. Пример источника синхронизации: отправитель потока пакетов, полученных из источника сигнала типа микрофона, видеокамеры или микшера RTP. Источник синхронизации может через какое-то время изменять формат данных, например, звуковое кодирование. Идентификатор SSRC - случайно выбранная величина, которая считается глобально уникальной в пределах конкретного сеанса RTP. Участнику телеконференции не требуется использовать один и тот же идентификатор SSRC для всех сеансов RTP в мультимедийном сеансе связи; объединение идентификаторов SSRC обеспечивается посредством протокола RTCP. Если участник генерирует множество потоков в одном сеансе RTP, например, от множества видеокамер, то каждый поток должен идентифицироваться отдельным SSRC
• TCP (Transmission Control Protocol) - протокол транспортного уровня, используемый совместно с протоколом IP
• UDP (User Datagram Protocol) - протокол транспортного уровня без установления логического соединения. UDP обеспечивает только посылку пакета одной или нескольким станциям сети. Проверка правильности и обеспечение целостности (гарантированной доставки) передачи данных осуществляется на более высоком уровне
• АДИКМ - адаптивная дифференциальная импульсно-кодовая модуляция
• джиттер (jitter) - дрожание, отклонения фазы или частоты сигнала; применительно к IP-телефонии - неравномерности задержки дейтаграмм в сети
• ЗПД - звено передачи данных (второй уровень Эталонной модели взаимодействия открытых систем)
• ИВС - информационно-вычислительные сети
• микшер (mixer) - промежуточная система, которая получает пакеты RTP от одного или более источников, возможно, изменяет формат данных, объединяет пакеты в новый пакет RTP и затем передает его. Так как множество источников сигналов в общем случае не синхронизировано, микшер корректирует таймирование составляющих потоков и генерирует собственную синхронизацию для объединенного потока. Таким образом, все информационные пакеты, сформированные микшером, идентифицируются, как имеющие микшер в качестве их источника синхронизации
• монитор (monitor) - приложение, которое получает пакеты RTCP, посланные участниками сеанса RTP, в частности, отчеты приема, и оценивает текущее качество обслуживания для контроля распределения, обнаружения ошибок и долговременной статистики. Обычно функции монитора лежат на приложениях, используемых в сеансе связи, но монитор может быть и отдельным приложением, которое иным образом не используется, не посылает или не получает информационные пакеты RTP. Такие приложения называются мониторами третьей стороны
• МСЭ-Т - Сектор стандартизации электросвязи Международного союза электросвязи
• оконечная система (еnd system) - приложение, которое генерирует содержимое, передаваемое в пакетах RTP, и/или которое потребляет содержимое полученных пакетов RTP. Оконечная система может действовать как один или более (но обычно только один) источников синхронизации в каждом сеансе RTP
• пакет RTCP - управляющий пакет, состоящий из фиксированной части заголовка, подобной заголовкам информационных пакетов протокола RTP, за которой следуют структурные элементы, изменяемые в зависимости от типа пакета RTCP. Обычно, множество пакетов RTCP передается вместе, как составной пакет RTCP в одном пакете нижележащего протокола; это обеспечивается полем длины в фиксированном заголовке каждого пакета RTCP
• пакет RTP - протокольный блок данных, состоящий из фиксированного заголовка RTP, возможно, пустого списка включаемых источников, расширения и трафика. Обычно в одном пакете протокола нижележащего уровня содержится один пакет RTP, но может быть и несколько
• порт - абстракция, используемая протоколами транспортного уровня для различения множества адресатов в пределах одного хост-компьютера. Порт определяется своим номером. Таким образом, номер порта - это число, определяющее конкретное приложение, которому предназначены пересылаемые данные. Этот номер, вместе с информацией о том, какой протокол (например, TCP или UDP) используется на вышележащем уровне, содержится среди прочей служебной информации в пересылаемых через Internet дейтаграммах. Транспортные селекторы (TSEL - transport selector), используемые транспортным уровнем OSI, эквивалентны портам
• профиль (profile) - набор параметров протоколов RTP и RTCP для класса приложений, определяющий особенности их функционирования. В профиле определяются использование полей бита маркера и типа трафика в заголовке пакета данных RTP, типы трафика, дополнения к заголовку пакета данных RTP, первые 16 битов расширения заголовка пакета данных RTP, типы пакетов RTCP, интервал отчетности RTCP, расширение пакетов SR/RR, использование пакетов SDES, услуги и алгоритмы обеспечения безопасности связи и особенности использования протокола нижележащего уровня
• сеанс связи RTP (RTP session) - связь множества участников, взаимодействующих посредством протокола RTP. Для каждого участника, сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пара транспортных адресов назначения может быть общей для всех участников (как в случае IPМ) или может быть отличной для каждого (индивидуальный сетевой адрес и общая пара портов, как при двусторонней связи). В мультимедийном сеансе трафик каждого типа передается в отдельном сеансе RTP со своими собственными пакетами RTCP. Групповые сеансы RTP различаются различными номерами пар портов и/или различными групповыми адресами
• средства не RTP (non-RTP means) - протоколы и механизмы, которые могут быть необходимы в дополнение к RTP, чтобы обеспечить приемлемое обслуживание. В частности, для мультимедийных конференций, приложение управления конференцией может распределять групповые адреса и ключи шифрования, согласовывать алгоритм шифрования, который нужно использовать, и определять динамические соответствия между величинами типа трафика RTP и форматами трафика, которые они представляют (форматами, которые не имеют предопределенной величины типа трафика). Для простых приложений также могут использоваться электронная почта или базы данных конференций
• транслятор (translator) - промежуточная система, которая направляет пакеты RTP, не изменяя идентификатор источника синхронизации. Примеры трансляторов: приборы, которые выполняют перекодировку без микширования, многосторонние или двунаправленные репликаторы, приложения прикладного уровня в брандмауэрах
• транспортный адрес (transport address) - комбинация сетевого адреса и номера порта, которая идентифицирует оконечную точку транспортного уровня, например, IP-адрес и номер порта UDP. Пакеты передаются от транспортного адреса источника до транспортного адреса назначения
• трафик RTP - мультимедийные данные, передаваемые в пакете протокола RTP, например, звуковые отсчеты или сжатые видеоданные
• ТСОП - телефонные сети общего пользования

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

• Устранение эффекта потери пакетов
• Восстановление порядка и контроль поступления пакетов
• Сглаживание эффекта задержки (джиттера)

Именно для этих целей был разработан RTP (Real-time Transport Protocol) - протокол передачи в реальном времени, о котором пойдет речь в сегодняшней статье. Протокол разрабатывался в IETF группой Audio-Video Transport Working Group и описывается в рекомендации RFC 3550.

Как правило, RTP работает поверх протокола UDP (User Datagram Protocol), так как при передаче мультимедийных данных очень важно обеспечить их своевременную доставку.

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

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

Ещё одна функция RTP связана с возможными потерями пакетов при прохождении по IP сети, что выражается в появлении кратковременных пауз в разговоре. Внезапная тишина в телефонной трубке, как правило, очень негативно действует на слушателя, поэтому возможностями протокола RTP такие периоды тишины заполняются, так называемым,“комфортным шумом”

RTP работает в связке с еще одним протоколом IETF, а именно RTCP (Real - time Transport Control Protocol), который описывается в RFC 3550. RTCP предназначен для сбора статистической информации, определения качества обслуживания QoS (Quality of Service), а также для синхронизации между медиа потоками RTP-сессии.

Основная функция RTCP – установление обратной связи с приложением для отчета о качестве получаемой информации. Участники RTCP сессии обмениваются сведениями о числе полученных и утраченных пакетов, значении джиттера, задержке и т.д. На основе анализа этой информации принимается решение об изменении параметров передачи, например, для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи.

Для выполнения этих функций RTCP передает специальные сообщения определенных типов:

• SR - Sender Report - отчёт источника со статистической информацией о RTP сессии
• RR - Receiver Report - отчёт получателя со статистической информацией о RTP сессии
• SDES - содержит описание параметров источника, включая cname (имя пользователя)
• BYE – Инициирует завершение участия в группе
• APP - Описание функций приложения

RTP является протоколом однонаправленного действия, поэтому для организации двусторонней связи необходимо две RTP сессии, по одной с каждой стороны.

RTP-сессия определяется IP адресами участников, а также парой незарезервированных UDP портов из диапазона 16384 - 32767. Кроме того, для организации обратной связи с приложением необходимо также установить двустороннюю RTCP сессию. Для RTCP сессии занимаются порты с номером на единицу большим чем RTP. Так например, если для RTP выбран 19554 порт, то RTCP сессия займет 19555 порт. Наглядно формирование RTP/RTCP сессии представлено на рисунке ниже.

Одной из важнейших тенденций в эволюции современных телекоммуникаций является развитие средств IP-телефонии - множества новых технологий, обеспечивающих передачу мультимедийных сообщений (речи, данных, видео) через информационно-вычислительные сети (ИВС), построенные на базе протокола IP (Internet Protocol), в том числе локальные, корпоративные, глобальные вычислительные сети и сеть Internet. Понятие IP-телефонии включает в себя Internet-телефонию, позволяющую организовать телефонную связь между абонентами сети Internet, между абонентами телефонных сетей общего пользование (ТСОП) через Internet, а также телефонную связь абонентов ТСОП и Internet друг с другом.

IP-телефония обладает рядом несомненных достоинств, обеспечивающих ее быстрое развитие и расширение рынка компьютерной телефонии. Она выгодна конечным пользователям, которые обеспечиваются телефонной связью при довольно низкой поминутной оплате. Компаниям, имеющим удаленные филиалы, IP-технология позволяет организовать речевую связь при помощи уже существующих корпоративных IP-сетей. Вместо нескольких сетей связи при этом используется одна. Безусловным преимуществом IP-телефонии перед обычным телефоном является также возможность предоставления дополнительных услуг за счет использования мультимедийного компьютера и различных Internet-приложений. Таким образом, благодаря IP-телефонии предприятия и частные лица могут расширить возможности организации связи путем включения в них современной видеоконференцсвязи, совместного использования приложений, средств типа электронной чертежной доски (whiteboard) и т.п.

Какие международные стандарты и протоколы регламентируют основные параметры и алгоритмы функционирования аппаратных и программных средств связи, используемых в IP-телефонии? Очевидно, как следует из названия, данная технология построена на базе протокола IP, который, впрочем, используется не только для телефонии: первоначально он был разработан для передачи цифровых данных в ИВС с коммутацией пакетов.

В сетях, не обеспечивающих гарантированное качество обслуживания (к ним относятся сети, построенные на основе протокола IP), пакеты могут теряться, может изменяться порядок их поступления, данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных и восстанавливает исходный порядок следования пакетов. Если в пакете обнаружена ошибка, или пакет теряется, процедуры TCP посылают запрос на повторную передачу.

Для приложений аудио- и видеоконференцсвязи задержки пакетов гораздо в большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двухстороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу мультимедийных данных в пакетах через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.

Во многих публикациях, посвященных IP-телефонии, отмечается, что большая часть сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) Н.323 (в том числе, TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 - это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например, стандарты аудио- и видеокодеков, имеют широкое применение не только в IP-телефонии. Что касается протоколов RTP/RTCP, то они составляют основу стандарта H.323, ориентированы на обеспечение именно IP-технологии, лежат в основе организации IP-телефонии. Рассмотрению данных протоколов и посвящена эта статья.

2. Основные понятия

Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.

Действие протокола RTP сводится к присваиванию каждому исходящему пакету временных меток. На приемной стороне временные метки пакетов указывают на то, в какой последовательности и с какими задержками их необходимо воспроизводить. Поддержка RTP и RTCP позволяет принимающему узлу располагать принимаемые пакеты в надлежащем порядке, снижать влияние неравномерности времени задержки пакетов в сети на качество сигнала и восстанавливать синхронизацию между аудио и видео, чтобы поступающая информация могла правильно прослушиваться и просматриваться пользователями.

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

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

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

Протокольные блоки данных RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, требуемой для надежной работы телеконференции, называют пакетами управления или служебными пакетами (control packets). Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину.

Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно не определенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) - это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д (в качестве примере в разделе 11 рассмотрен предложенный в RFC 1890 профиль RTP для аудио- и видеоконференций с минимальным управлением). Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.

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

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

2.1. Групповая аудиоконференцсвязь

Для организации групповой аудиоконференцсвязи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, как определено в разделе 7.1, в этом случае также должен быть сгенерирован и распределен ключ шифрования.

Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.

Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент, и как хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя, может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.

2.2. Видеоконференцсвязь

Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP (см. список используемых сокращений и терминов). Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов так, чтобы сеансы могли быть связаны.

Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.

2.3. Понятие о микшерах и трансляторах

Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того, чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.

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

Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих только протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала пакет за пакетом из индивидуальных источников без пересинхронизации или микширования. Детали работы микшеров и трансляторов рассмотрены в разделе 5.

2.4. Порядок байтов, выравнивание и формат меток времени

Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.

Абсолютное время (время Wallclock) в RTP представлено с использованием формата временной метки сетевого протокола времени NTP (Network Time Protocol), который является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых полях с более компактным представлением используются только средние 32 бита - младшие 16 битов целой части и старшие 16 битов дробной части.

В следующих двух разделах данной статьи (3 и 4) рассматриваются форматы пакетов и особенности функционирования протоколов RTP и RTCP соответственно.

3. Протокол передачи данных RTP

3.1. Поля фиксированного заголовка RTP

Как было отмечено выше, пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка с переменной длиной и поле данных. Фиксированный заголовок пакетов протокола RTP имеет следующий формат: .

Первые двенадцать октетов присутствуют в каждом пакете RTP, в то время как поле идентификаторов включаемых источников CSRC (сontributing source) присутствует только тогда, когда оно вставлено микшером. Поля имеют следующие назначения.

Версия (V): 2 бита. Это поле идентифицирует версию RTP. В данной статье рассматривается версия 2 протокола RTP (величина 1 использовалась в первой черновой версии RTP).

Дополнение (P): 1 бит. Если бит дополнения установлен в единицу, то пакет в конце содержит один или более октетов дополнения, которые не являются частью трафика. Последний октет дополнения содержит указание на число таких октетов, которые должны впоследствии игнорироваться. Дополнение может требоваться некоторым алгоритмам шифрования с фиксированными размерами блока или для переноса нескольких пакетов RTP в одном блоке данных протокола нижележащего уровня.

Расширение (X): 1 бит. Если бит расширения установлен, то за фиксированным заголовком следует расширение заголовка с форматом, определенным в .

Счетчик CSRC (CC): 4 бита. Счетчик CSRC содержит число идентификаторов включаемых источников CSRC (см. список используемых сокращений и терминов), которые следуют за фиксированным заголовком.

Маркер (M): 1 бит. Интерпретация маркера определяется профилем. Он предназначен для того, чтобы позволить маркировать в потоке пакетов значительные события (например, границы видеокадра). Профиль может вводить дополнительные биты маркера или определять, что никакого бита маркера не имеется, изменяя число битов в поле типа трафика (см. ).

Тип трафика (PT): 7 бит. Это поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Профиль определяет заданное по умолчанию статическое соответствие значений РТ и форматов трафика. Дополнительные коды типа трафика могут быть определены динамически через не-RTP средства. Отправитель пакета RTP в любой момент времени выдает единственное значение типа трафика RTP; это поле не предназначено для мультиплексирования отдельных мультимедийных потоков (см. ).

Порядковый номер: 16 бит. Значение порядкового номера увеличивается на единицу с каждым посланным информационным пакетом RTP и может использоваться получателем для обнаружения потерь пакетов и восстановления их исходной последовательности. Начальная величина порядкового номера выбирается случайным образом, чтобы усложнить попытки взлома ключа с опорой на известные значения данного поля (даже если шифрование не используется источником, так как пакеты могут проходить через транслятор, который применяет шифрование). Временная метка: 32 бита. Временная метка отражает момент дискретизации для первого октета в информационном пакете RTP. Момент дискретизации должен быть получен от таймера, который увеличивает свои значения монотонно и линейно во времени, для обеспечения синхронизации и определения джиттера (см. раздел 4.3.1). Разрешение таймера должно быть достаточным для желательной точности синхронизации и измерения джиттера поступления пакетов (одного отчета таймера на видеокадр обычно бывает недостаточно). Частота таймирования зависит от формата передаваемого трафика и задается статически в профиле или спецификации формата трафика или может задаваться динамически для форматов трафика, определенных через «не-RTP средства». Если пакеты RTP генерируются периодически, то должны использоваться номинальные моменты дискретизации, определяемые таймером дискретизации, а не значения системного таймера. Например, для звукового сигнала с фиксированной скоростью желательно, чтобы датчик временной метки увеличивался на единицу для каждого периода дискретизации. Если звуковое приложение из устройства ввода читает блоки, содержащие 160 отсчетов, то временная метка при этом должна увеличиваться на 160 для каждого такого блока, независимо от того, передан ли блок в пакете или сброшен, как пауза. Начальное значение временной метки, так же, как и начальное значение порядкового номера, является случайной величиной. Несколько последовательных пакетов RTP могут иметь равные временные метки, если они логически генерируются одновременно, например, принадлежат одному и тому же видеокадру. Последовательные пакеты RTP могут содержать немонотонные временные метки, если данные не передаются в порядке дискретизации, как в случае интерполируемых видеокадров MPEG (однако порядковые номера пакетов при передаче все же будут монотонными).

SSRC: 32 бита. Поле SSRC (synchronization source) идентифицирует источник синхронизации (см. список используемых сокращений и терминов). Этот идентификатор выбирается случайным образом так, чтобы никакие два источника синхронизации в рамках одного и того же сеанса связи RTP не имели одинаковых идентификаторов SSRC. Хотя вероятность того, что несколько источников выберут один и тот же идентификатор, низка, все же все реализации RTP должны быть готовы обнаруживать и разрешать подобные коллизии. В разделе 6 рассмотрена вероятность коллизий вместе с механизмом для их разрешения и обнаружения зацикливаний уровня RTP, основанным на уникальности идентификатора SSRC. Если источник изменяет свой исходный транспортный адрес, то он должен также выбрать новый идентификатор SSRC, чтобы его не интерпретировали как зацикленный источник.

Список CSRC: от 0 до 15 пунктов, 32 бита каждый. Список CSRC (сontributing source) идентифицирует включаемые источники трафика, содержащегося в пакете. Число идентификаторов задается полем CC. Если имеется более пятнадцати включаемых источников, то только 15 из них могут быть идентифицированы. Идентификаторы CSRC вставляются микшерами при использовании идентификаторов SSRC для включаемых источников. Например, для звуковых пакетов идентификаторы SSRC всех источников, которые были смешаны при создании пакета, перечисляются в списке CSRC, обеспечивая корректную индикацию источников сообщений для получателя.

3.2. Сеансы связи RTP

Как было упомянуто выше, в соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Например, в телеконференции, составленной из звукового и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения. Не предполагается, что звуковой и видеосигнал будут передаваться в одном сеансе RTP и разделяться на основе типа трафика или полей SSRC. Перемежение пакетов, имеющих различные типы трафика, но использующих один и тот же SSRC, вызвало бы некоторые проблемы:

1. Если в течение сеанса один из типов трафика изменится, то не будет никаких общих средств, чтобы определить, какая из старых величин была заменена новой.
2. SSRC идентифицирует единственное значение интервала таймирования и пространство порядкового номера. Перемежение множества типов трафика потребовало бы различных интервалов синхронизации, если тактовые частоты разных потоков различаются, и различных пространств порядковых номеров для индикации типа трафика, к которому относится потеря пакета.
3. Сообщения отправителя и получателя протокола RTCP (см. раздел 4.3) описывают только одно значение интервала таймирования и пространство порядковых номеров для SSRC и не передают поле типа трафика.
4. Микшер RTP не способен объединять перемеженные потоки различных типов трафика в один поток.
5. Передаче множества типов трафика в одном сеансе RTP препятствуют следующие факторы: использование различных сетевых путей или распределение сетевых ресурсов; прием подмножества мультимедийных данных, когда это требуется, например, только звука, если видеосигнал превысил доступную полосу пропускания; реализации приемника, которые используют отдельные процессы для различных типов трафика, в то время как использование отдельных сеансов RTP допускает реализации как с одним, так и со множеством процессов.

При использовании для каждого типа трафика различных SSRC, но при передаче их в одном и том же сеансе RTP, можно избежать первых трех проблем, но двух последних избежать не удастся. Поэтому спецификация протокола RTP предписывает для каждого типа трафика использовать свой сеанс RTP.

3.3. Определяемые профилем изменения заголовка RTP

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

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

Дополнительная информация, которая требуется для конкретного формата трафика (например, тип кодирования видеосигнала), должна передаваться в поле данных пакета. Она может размещаться на определенном месте в начале или внутри массива данных.

Если конкретный класс приложений нуждается в дополнительных функциональных возможностях, не зависящих от формата трафика, то профиль, с которым функционируют эти приложения, должен определить дополнительные фиксированные поля, располагаемые сразу после поля SSRC существующего фиксированного заголовка. Эти приложения будут способны быстро напрямую обращаться к дополнительным полям, в то время как профиль-независимые мониторы или регистраторы все еще будут способны обрабатывать пакеты RTP, интерпретируя только первые двенадцать октетов.

Если считается, что дополнительные функциональные возможности необходимы в общем для всех профилей, то должна быть определена новая версия RTP, чтобы сделать постоянное изменение фиксированного заголовка.

3.4. Расширение заголовка RTP

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

Если бит X в заголовке RTP установлен в единицу, то к фиксированному заголовку RTP (вслед за списком CSRC, если он есть) присоединяется расширение заголовка с переменной длиной. Заметим, что это расширение заголовка предназначено только для ограниченного использования. Расширение заголовка пакета RTP имеет следующий формат:

Расширение содержит 16-разрядное поле длины, которое показывает количество 32-разрядных слов в нем, исключая четырехоктетный заголовок расширения (следовательно, длина может иметь нулевое значение). Только одно расширение может быть добавлено к фиксированному заголовку информационного пакета RTP. Чтобы позволить каждому из множества взаимодействующих реализаций экспериментировать независимо с различными расширениями заголовка или позволять конкретной реализации экспериментировать более чем с одним типом расширения заголовка, использование первых 16 битов расширения не определено, оставлено для различающих идентификаторов или параметров. Формат из этих 16 битов должен быть определен спецификацией профиля, с которым работают приложения.

1999

2000

Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов TCP/IP сейчас весьма акту­ально. Эту задачу призван решить транспортный протокол реального времени (Real-Time Transport Protocol, RTP), который является стандартом IETF для передачи таких данных, как голос или видео, в реальном времени по сети, не гарантирующей качества обслуживания.

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

Хотя протокол TCP гарантирует доставку передаваемых данных в нужной последовательности, трафик при этом неравномерен, то есть при доставке дей­таграмм происходят непредсказуемые задержки. Так как протокол RTP учи­тывает содержимое дейтаграмм и обладает механизмами обнаружения потери данных, он позволяет снизить задержки до приемлемого уровня.

Адресная схема протокола IP

Межсетевая схема адресации, применяемая в протоколе IP, описана в докумен­тах RFC 990 и RFC 997. В ее основе лежит разделение адресации сетей от адре­сации устройств в этих сетях. Такая схема облегчает маршрутизацию. При этом адреса должны назначаться упорядоченно (последовательно), для того чтобы сделать маршрутизацию более эффективной.

При использовании в сети стека протоколов TCP/IP конечные устройства получают уникальные адреса. Такими устройствами могут быть персональные компьютеры, коммуникационные сервера, маршрутизаторы и т. д. При этом не­которые устройства, которые имеют несколько физических портов, например маршрутизаторы, должны иметь уникальный адрес на каждом из портов. Исходя из схемы адресации и того, что некоторые устройства в сети могут иметь не­сколько адресов, можно сделать вывод, что данная схема адресации описывает не само устройство в сети, а определенное соединение этого устройства с сетью. Данная схема приводит к ряду неудобств. Одним из них является необходи­мость замены адреса устройства при перемещении его в другую сеть. Другой недостаток в том, что для работы с устройством, имеющим несколько подключе­ний в распределенной сети, необходимо знать все его адреса, идентифицирую­щие эти подключения.

Итак, для каждого устройства в сетях IP можно говорить об адресах трех уровней:

q Физический адрес устройства (точнее - определенного интерфейса). Для устройств в сетях Ethernet - это МАК - адрес сетевой карты или порта маршрутизатора. Эти адреса назначаются производителями оборудования. Физический адрес имеет шесть байтов: старшие три байта - идентифика­тор фирмы-производителя, младшие три байта назначаются самим произ­водителем;

q IP-адрес, состоящий из четырех байт. Этот адрес используется на сетевом уровне эталонной модели OSI;

q Символьный идентификатор - имя. Этот идентификатор может назна­чаться администратором произвольно.

Когда протокол IP был стандартизован в сентябре 1981 года, его специфика­ция требовала, чтобы каждое устройство, подключенное к сети, имело уникаль­ный 32-битный адрес. Этот адрес разбивается на две части. Первая часть адреса идентифицирует сеть, в которой располагается устройство. Вторая часть одноз­начно идентифицирует само устройство в рамках сети. Такая схема приводит к двухуровневой адресной иерархии (рис. 6.23).

Сейчас поле номера сети в адресе называется сетевым префиксом, так как оно идентифицирует сеть. Все рабочие станции в сети имеют один и тот же сетевой префикс. При этом они должны иметь уникальные номера устройств. Две рабо­чие станции, расположенные в разных сетях, должны иметь различные сетевые префиксы, но при этом они могут иметь одинаковые номера устройств.

Для обеспечения гибкости в присвоении адресов компьютерным сетям разра­ботчики протокола определили, что адресное пространство IP должно быть раз­делено на три различных класса - А, В и С. Зная класс, вы знаете, где в 32-битном адресе проходит граница между сетевым префиксом и номером устройства. На рис. 6.24 показаны форматы адресов этих основных классов.

Одно из основных достоинств использования классов заключается в том, что по классу адреса можно определить, где проходит граница между сетевым пре­фиксом и номером устройства. Например, если старшие два бита адреса равны 10, то точка раздела находится между 15 и 16 битом.

Недостатком такого метода является необходимость изменения сетевого ад­реса при подключении дополнительных устройств. Например, если общее число устройств в сети класса С будет превышать 255, то потребуется заменить ее адреса на адреса класса В. Изменение сетевых адресов потребует от админист­ратора дополнительных усилий по отладке сети. Администраторы сетей не могут осуществить плавный переход к новому классу адресов, так как классы четко разделены. Приходится запрещать использовать целую группу сетевых адресов, производить одновременное изменение всех адресов устройств в этой группе, и только затем вновь разрешать их использование в сети. Кроме того, введение классов адресов значительно уменьшает теоретически возможное число индивидуальных адресов. В текущей версии протокола IP (версия 4) общее число адресов могло составлять 2 32 (4 294 967 296), так как протокол преду­сматривает использование 32 бит для задания адреса. Естественно, использование части бит в служебных целях уменьшает доступное количество индивидуальных адресов.

Класс А предназначен для больших сетей. Каждый адрес класса А имеет 8-битовый префикс сети, в котором старший бит установлен в 1, а следующие семь бит используются для номера сети. Для номера устройства задействуются оставшиеся 24 бита. В настоящий момент все адреса класса А уже выделены. Сети класса А также обозначаются как «/8», поскольку адреса этого класса имеют 8-битовый сетевой префикс.

Максимальное число сетей класса А составляет 126 (2 7 -2 - вычитаются два адреса, состоящие из одних нулей и единиц). Каждая сеть этого класса поддер­живает до 16 777 214 (2 24 -2) устройств. Так как адресный блок класса А может содержать максимум до 2 31 (2 147483648) индивидуальных адресов, а в прото­коле IP версии 4 может поддерживаться максимум до 2 32 (4 294 967 296) адре­сов, то класс А занимает 50 % общего адресного пространства протокола IP.

Класс В предназначен для сетей среднего размера. Каждый адрес класса В имеет 16-битовый сетевой префикс, в котором два старших бита равны 10, а следующие 14 бит используются для номера сети. Для номера устройства выде­лены 16 бит. Сети класса В также обозначаются как «/16», поскольку адреса этого класса имеют 16-битный сетевой префикс.

Максимальное число сетей класса В равно 16 382 (2 14 -2). Каждая сеть этого класса поддерживает до 65 534 (2 16 -2) устройств. Так как весь адресный блок класса В может содержать максимум до 2 30 (1 073 741 824) индивидуальных ад­ресов, он занимает 25 % общего адресного пространства протокола IP.

Адреса класса С используются в сетях с небольшим числом устройств. Каж­дая сеть класса С имеет 24-битный сетевой префикс, в котором три старших бита равны 110, а следующие 21 бит используются для номера сети. Под номера устройства выделены оставшиеся 8 бит. Сети класса С также обозначаются как «/24», поскольку адреса этого класса имеют 24-битный сетевой префикс.

Максимальное число сетей класса С составляет 2 097 152 (2 21). Каждая сеть этого класса поддерживает до 254 (2 8 -2) устройств. Класс С занимает 12.5 % общего адресного пространства протокола IP.

В табл. 6.9 подводится итог нашему анализу классов сетей.

Таблица 6.9. Классы сетей

В дополнение к этим трем классам адресов выделяют еще два класса. В клас­се D старшие четыре бита равны 1110. Этот класс используется для групповой передачи данных. В классе Е старшие четыре бита - 1111. Он зарезервирован для проведения экспериментов.

Для удобства чтения адресов в технической литературе, прикладных про­граммах и т. д. IP-адреса представляются в виде четырех десятичных чисел, раз­деленных точками. Каждое из этих чисел соответствует одному октету (8 битам) IP-адреса. Этот формат называют точечно-десятичным (Decimal-Point Notation) или точечно-десятичной нотацией (рис. 6.25).

В табл. 6.10 перечислены диапазоны десятичных значений трех классов адре­сов. В табл. 6.10 запись XXX означает произвольное поле.

Таблица 6.10. Диапазоны значений адресов

Некоторые IP-адреса не могут присваиваться устройствам в сети (табл. 6.11).

Как показано в этой таблице, в зарезервированных IP-адресах все биты, установленные в ноль, соответствуют либо данному устройству, либо данной сети, а IP-адреса, все биты которых установлены в 1, используются при ши­роковещательной передаче информации. Для ссылки на всю IP-сеть в целом используется адрес с номером устройства, у которого все биты установлены в «0». Сетевой адрес класса А - 127.0.0.0 зарезервирован для обратной связи и введен для проверки взаимодействия между процессами на одной машине. Ког­да приложение использует адрес обратной связи (loopback), стек протоколов TCP/IP возвращает эти данные приложению, ничего не посылая в сеть. Кроме того, данный адрес можно использовать для взаимодействия отдельных процес­сов в пределах одной машины. Поэтому в сетях IP запрещается присваивать устройствам IP-адреса, начинающиеся со 127.

Помимо направленной передачи данных определенной рабочей станции, активно используется широковещательная передача, при которой информацию получают все станции в текущей или указанной сети. В протоколе IP разделяют два типа широковещания: направленное и ограниченное.

Направленное широковещание позволяет устройству из удаленной сети по­слать дейтаграмму всем устройствам в текущей сети. Дейтаграмма с направлен­ным широковещательным адресом может проходить через маршрутизаторы, но доставлена она будет только всем устройствам в указанной сети, а не вообще всем устройствам. При направленном широковещании адрес получателя состоит из номера конкретной сети и номера устройства, все биты которого равны 0 или 1. Например, адреса 185.100.255.255 и 185.100.0.0 будут рассматриваться как адреса направленного широковещания для сети 185.100.xxx.xxx класса В. С точки зрения адресации, главным недостатком направленного широковеща­ния является то, что требуется знание номера целевой сети.

Вторая форма широковещания, называемая ограниченным широковещанием, обеспечивает широковещательную передачу в рамках текущей сети (сети, где находится устройство-отправитель). Дейтаграмма с ограниченным широкове­щательным адресом никогда не будет пропущена через маршрутизатор. При ограниченном широковещании биты номера сети и номера устройства состоят из всех нулей или единиц. Таким образом дейтаграмма с адресом получате­ля 255.255.255.255 или 0.0.0.0 будет доставлена всем устройствам в сети. На рис. 6.26 показаны сети, связанные маршрутизаторами. В табл. 6.12 перечис­лены получатели широковещательных дейтаграмм, отправляемых рабочей стан­цией А.

Протокол IP поддерживает три способа адресации: единичную (unicast), ши­роковещательную (broadcast) и групповую (multicast).

Таблица 6.12. Получатели широковещательных дейтаграмм

При единичной адресации дейтаграммы посылаются конкретному единично­му устройству. Реализация этого подхода не представляет затруднений, однако если рабочая группа содержит много станций, пропускной способности может оказаться недостаточно, так как одна и та же дейтаграмма будет передаваться многократно.

При широковещательной адресации приложения посылают одну дейтаграм­му, причем она доставляется всем устройствам в сети. Такой подход еще более прост для реализации, но если в этом случае широковещательный трафик не ограничен пределами локальной сети (а, например, с помощью маршрутизаторов пересылается другую сеть), то тогда глобальная сеть должна иметь значитель­ную пропускную способность. Если информация предназначается только не­большой группе устройств, то такой подход представляется нерациональным.

При групповой адресации дейтаграммы доставляются определенной группе устройств. При этом (что очень важно при работе в распределенных сетях) не генерируется избыточный трафик. Дейтаграммы с групповым и единичным ад­ресом различаются адресом. В заголовке IP-дейтаграммы с групповой адреса­цией вместо IP-адресов классов А, В, С содержится адрес класса D, то есть групповой адрес.

Групповой адрес присваивается некоторым устройствам-получателям или, иными словами, группе. Отправитель записывает данный групповой адрес в за­головок IP-дейтаграммы. Дейтаграмма будет доставлена всем членам группы. Первые четыре бита адреса класса D равны 1110. Остальную часть адреса (28 бит) занимает идентификатор группы (рис. 6.27).

В точечно-десятичном формате групповые адреса лежат в диапазоне от 224.0.0.0 до 239.255.255.255. В табл. 6.13 показана схема распределения адресов класса D.

Таблица 6.13. Распределение адресов класса D

Как видно из табл. 6.13, первые 256 адресов зарезервированы. В частности, этот диапазон отведен протоколам маршрутизации и другим низкоуровневым протоколам. В табл. 6.14 содержатся некоторые зарезервированные IP-адреса класса D.

Выше этого диапазона находится большая группа адресов, выделенных для приложений, работающих в сети Internet. Самый верхний диапазон адресов (примерно 16 миллионов адресов) предназначен для административных целей в локальных сетях. Централизованным управлением и регистрацией групповых адресов класса D занимается специальная организация IANA.

Групповая адресация может быть реализована на двух уровнях модели OSI - канальном (Data-Link Layer) и сетевом (Network Layer). Протоколы пе­редачи канального уровня, например, Ethernet и FDDI, могут поддерживать еди­ничную, широковещательную и групповую адресацию. Групповая адресация на канальном уровне особенно эффективна, если она поддерживается сетевой пла­той аппаратно.

Для поддержки групповой адресации IANA выделен блок групповых Ether­net-адресов, начиная с 01-00-5Е (в шестнадцатеричном представлении). Груп­повой IP-адрес может транслироваться в адрес из этого блока. Принцип трансляции достаточно прост: младшие 23 бита идентификатора IP-группы ко­пируются в младшие 23 бита Ethernet-адреса. При этом необходимо учитывать, что данная схема ассоциирует до 32 различных IP-групп с одним и тем же Ethernet-ад­ресом, так как следующие 5 бит идентификатора IP-группы игнорируются.

Таблица 6.14. Зарезервированные адреса класса D

Адрес	Назначение
224.0.0.1	Все устройства подсети
224.0.0.2	Все маршрутизаторы подсети
224.0.0.4	Все DVMRP-маршрутизаторы
224.0.0.5	Все MOSPF-маршрутизаторы
224.0.0.9	RIP IP версии II
224.0.1.7	Аудионовости
224.0.1.11	IEFT аудио
224.0.1.12	IEFT видео

Если отправитель и получатель принадлежат одной физической сети, про­цесс передачи и приема групповых кадров на канальном уровне достаточно прост. Отправитель указывает IP-адрес группы получателей, а сетевая плата вы­полняет трансляцию этого адреса в соответствующий групповой Ethernet-адрес и посылает кадр.

Если отправитель и получатель находятся в разных подсетях, связанных мар­шрутизаторами, доставка дейтаграмм затруднена. В этом случае маршрутизато­ры должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM - см. ниже). Согласно этим протоколам маршрутиза­тор построит дерево доставки и правильно передаст групповой трафик. Кроме того, каждый маршрутизатор должен поддерживать протокол управления груп­пами (IGMP) для определения наличия членов группы в непосредственно под­ключенных подсетях (рис. 6.28).

RTSP (Real Time Streaming Protocol, или, по-русски, потоковый протокол реального времени) – это прикладной протокол, в котором описаны команды для управления видеопотоком. С помощью этих команд мы можем «приказать» камере или серверу, например, начать трансляцию видеопотока. Пример запроса на начало воспроизведения выглядит так: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

То есть RTSP – это просто набор команд для управления видеопотоком. Проведем эксперимент. Для этого нам понадобится IP-камера с поддержкой RTSP протокола и ее RTSP адрес. Этот адрес выглядит примерно так rtsp:///mpeg. Его можно узнать из руководства по эксплуатации камеры либо из описания API. Для удобства мы приведем RTSP адреса для ряда популярных камер в таблице. После того, как мы узнали RTSP-адрес камеры, открываем стандартный проигрыватель, поддерживающий RTSP. Это может быть одна из следующих программ: Windows Media Player, QuickTime, Media Player Classic, VLC media player, RealPlayer, MPlayer. Мы выбрали QuickTime. Открываем меню «Файл > Открыть URL» и вводим наш RTSP адрес. После чего QuickTime подключится к камере и воспроизведет «живое видео». Устройства записи, работающие в системах IP-видеонаблюдения, получают видео от камер либо с помощью протокола HTTP – то есть также, как мы скачиваем JPEG-картинки с сайтов, либо в виде потока через RTSP – то есть также как мы получили его с помощью стандартного проигрывателя в последнем примере. В настройках IP-камер потоковый вариант передачи данных может обозначаться как RTSP over , RTSP over либо просто . Итак, RTSP – это набор команд для управления потоком. Но что означают остальные аббревиатуры: TCP, RTP? TCP, и RTP — это транспортные механизмы (протоколы), которые собственно и передают видео.

Протокол TCP

Допустим, мы выбрали метод RSTP over TCP и хотим начать передачу видеопотока. Что будет происходить на уровне транспортных механизмов? Предварительно с помощью нескольких команд будет установлено соединение между отправителем и получателем. После этого начнется передача видеоданных. При этом механизмы TCP
будут следить за тем, чтобы все данные дошли до адресата без изменений и в нужной последовательности. Также TCP будет регулировать скорость передачи, чтобы передатчик не посылал данные интенсивнее, чем их может обработать приемник.

UDP – это альтернатива транспортному протоколу TCP. В отличие от TCP, UDP не устанавливает предварительного соединения, а вместо этого просто начинает передавать данные. UDP не следит за тем, чтобы данные были получены и не дублирует их, если отдельные части пропали или пришли с ошибками. UDP менее надежен, чем TCP. Но с другой стороны, он обеспечивает более быструю передачу потоков благодаря отсутствию механизма повторения передачи потерянных пакетов.

Можно увидеть различие в протоколах, поставив следующий эксперимент: попробуйте перевести камеру в режим RTSP over TCP и помашите рукой перед объективом — на экране монитора вы увидите задержку. А теперь проведите этот же тест в режиме RTSP over UDP. Задержка будет меньше. На время задержки влияют несколько факторов: формат сжатия, мощность компьютера, протокол передачи и особенности программного обеспечения, участвующего в декодировании видео.

RTP (Real-time Transport Protocol), или по-русски транспортный протокол реального времени. Этот протокол специально создан для передачи реалтайм трафика. Он позволяет следить за синхронизацией передаваемых данных, корректировать последовательность доставки пакетов и потому более других подходит для передачи видео- и аудиоданных. В общем случае для передачи видеопотока предпочтительнее использовать либо RTP либо UDP. Работа через TCP оправдана лишь если нам приходится работать с проблемными сетями, так как протокол TCP сможет корректировать ошибки и сбои, возникающие при передаче данных.