RTP и RTCP: протоколы для IP-телефонии

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

В данном разделе рассмотрены некоторые аспекты переноса пакетов 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 — тыльный.

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

Частота дискретизации должна быть выбрана из множества: 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, например, звуковые отсчеты или сжатые видеоданные
• ТСОП — телефонные сети общего пользования

КомпьютерПресс 10'1999