Протокол RTP.

Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.

Итак, с чем мы будем разбираться под катом:

1. Базовые понятия телефонии: типы аппаратов, схемы подключения
2. Связка SIP/SDP/RTP-протоколов: как это работает
3. Как передается информации о нажатых кнопках
4. Как происходит передача голоса и факсов
5. Цифровая обработка сигналов и обеспечение качества звука в IP-телефонии

1. Базовые понятия телефонии

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

На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.

По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто - на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.

Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента - с помощью модуля DAA (Direct Access Arrangement).

Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.

Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) - телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия - POTS (Plain Old Telephone Service) - простая старая телефонная система.

С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг - дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.

Skype - самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго - не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.

К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками - это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.

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

2. Описание связки SIP/SDP/RTP-протоколов

SIP (Session Initiation Protocol) - протокол установления сессии (не только телефонной) - это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.

SDP (Session Description Protocol) - протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов - скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.

RTP (Real-time Transport Protocol) - протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.

Общая структура SIP-пакетов:

• Start-Line: поле, указывающее SIP-метод (команду) при запросе или результат выполнения SIP-метода при ответе.
• Headers: дополнительная информация к Start-Line, оформленная в виде строк, содержащих пары АТТРИБУТ: ЗНАЧЕНИЕ.
• Body: бинарные или текстовые данные. Обычно используется для передачи SDP-параметров или сообщений.

Вот пример двух SIP-пакетов для одной частой процедуры - установления вызова:

Слева изображено содержимое пакета SIP INVITE, справа - ответ на него - SIP 200 OK.

Основные поля выделены рамками:

• Method/Request-URI содержит SIP-метод и URI. В примере происходит установление сессии - метод INVITE, вызов абонента [email protected].
• Status-Code - код ответа на предыдущую SIP-команду. В данном примере команда выполнилась успешно - код 200, т.е. абонент 555 поднял трубку.
• Via - адрес, на котором абонент 777 ждет ответа. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• From/To - отображаемые имя и адрес отправителя и получателя сообщения. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Cseq содержит порядковый номер команды и название метода, к которому относится данное сообщение. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Content-Type - тип данных, которые передаются в блоке Body, в данном случае - SDP-данные.
• Connection Information - IP-адрес, на который второму абоненту необходимо отправлять пакеты RTP (или UDPTL пакеты в случае передачи факса по T.38).
• Media Description - порт, на который второй абонент должен передавать указанные данные. В данном случае это звук (audio RTP/AVP) и список поддерживаемых типов данных - PCMU, PCMA, GSM-кодеки и DTMF-сигналы.

SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:

• o - Origin, имя организатора сессии и идентификатор сессии.
• с - Connection Information, поле описано ранее.
• m - Media Description, поле описано ранее.
• a - медиа-атрибуты, уточняют формат передаваемых данных. Например, указывают направление звука - прием или передача (sendrecv), для кодеков указывают частоту дискретизации и номер привязки (rtpmap).

RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https :// wikipedia org wiki RTP audio video profile .

Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).

Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):

Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.

При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).

Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.

Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток - если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT"ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.

После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.

3. Передача информации о нажатых кнопках

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

Так, в обычной телефонной линии есть два способа набора номера:

• Импульсный - исторически первый, использовался в основном в телефонах с дисковым номеронабирателем. Набор происходит за счет последовательного замыкания и размыкания телефонной линии согласно набираемой цифре.
• Тоновый - набор номера DTMF-кодами (Dual-Tone Multi-Frequency) - каждой кнопке телефона соответствует своя комбинация двух синусоидальных сигналов (тонов). Выполняя алгоритм Гёрцеля можно довольно просто определить нажатую кнопку.

Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс - разрыв линии, 40 мс - замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.

В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:

1. DTMF Inband - генерация звукового тона и передача его внутри аудиоданных (текущего RTP-канала) - это обычный тоновый набор.
2. RFC2833 - генерируется специальный RTP-пакет telephone-event, в котором содержится информация о нажатой клавише, громкость и длительность. Номер RTP-формата, в котором будут передаваться пакеты DTMF RFC2833, указывается в теле SDP-сообщения. Например: a=rtpmap:98 telephone-event/8000.
3. SIP INFO - формируется пакет SIP INFO c информацией о нажатой клавише, громкости и длительности.

Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков - это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).

Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.

4. Передача голоса и факсов

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

Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.

Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.

Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.

Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.

Основные достоинства T.38 - снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.

Процедура передачи факса в режиме T.38 выглядит следующим образом:

1. Устанавливается обычное голосовое соединение по любому кодеку.
2. Когда бумага загружена в отправляющий факс, он периодически шлет T.30-сигнал CNG (Calling Tone), что означает готовность к передаче факса.
3. На принимающей стороне генерируется T.30-сигнал CED (Called Terminal Identification) - это готовность принять факс. Данный сигнал отправляется либо после нажатия кнопки «Получить факс» либо факс делает это автоматически.
4. На отправляющей стороне обнаруживается CED-сигнал и происходит процедура SIP REINVITE, а в SDP-сообщении указывается T.38 тип: m=image 39164 udptl t38.

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

Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы - David Hanes и Gonzalo Salgueiro.

5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования

С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос - качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС - цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.

Основные процедуры, улучшающие качество звука:

VAD (Voice activity detector) - процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).

Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.

Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).

Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.

CNG (сomfort noise generation) - процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.

PLC (packet loss concealment) - процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.

Простейший способ эмуляции потери пакетов (в Linux) - воспользоваться утилитой tc из пакета iproute с модулем netem . Она выполняет шейпинг только исходящего трафика.

Пример запуска эмуляции сети с потерей 50% пакетов:

Tc qdisc change dev eth1 root netem loss 50%

Отключение эмуляции:

Tc qdisc del dev eth1 root

Jitter buffer - процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.

Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):

tc qdisc add dev eth1 root netem delay 500ms reorder 99%

LEC (Line Echo Canceller) - процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.

Эхо может возникать по нескольким причинам:

• акустическое эхо из-за некачественного аудиотракта (звук из динамика попадает в микрофон);
• электрическое эхо из-за несогласованности импедансов между телефонным аппаратом и SLIC-модулем. В большинстве случаев это происходит в цепях преобразования 4-проводной телефонной линии в 2-проводную.

Выяснить причину (акустическое или электрическое эхо) несложно: абоненту, на чьей стороне создается эхо, необходимо отключить микрофон. Если эхо все равно возникает - значит оно электрическое.

Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books .

На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.

[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad .

Теги:

• для начинающих
• для новичков

Добавить метки

Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов 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).

Протокол RTP

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).

Рис. 1.5.

На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP -- это транспортный протокол, реализованный на прикладном уровне.

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).

Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок.

Рис. 1.6.

Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.

RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

Одной из важнейших тенденций в эволюции современных телекоммуникаций является развитие средств 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

Протоколы RTP и RSVP,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Современные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два протокола (RTP и PSVP) позволяют гарантировать своевременность доставки с обеспечением качества услуг.

Непрекращающийся рост Интернета и частных сетей предъявляет новые требования к пропускной способности. Клиент-серверные приложения далеко превосходят Telnet по объемам передаваемых данных. World Wide Web привел к гигантскому увеличению графика графической информации. Сегодня к тому же голосовые и видеоприложения выдвигают свои специфические требования к и без того перегруженным сетям.

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

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

АТМ - единственная сетевая технология, которая изначально разрабатывалась для поддержки обычного трафика TCP и UDP наряду с трафиком реального времени. Однако ориентация на АТМ означает либо создание новой сетевой инфраструктуры для трафика реального времени, либо замену имеющейся конфигурации на базе IP, причем оба варианта обойдутся весьма недешево.

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

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

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

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

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

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

ограничений (соединение «точка-точка» и передача потерянных сегментов), но и он не предоставляет критической информации о синхронизации. Таким образом, UDP сам по себе не имеет каких-либо инструментов общего назначения для приложений реального времени.

Несмотря на то что каждое приложение реального времени может обладать своими собственными механизмами для поддержки передачи в реальном времени, они имеют много общих черт, что делает определение единого протокола весьма желательным. Стандартный протокол такого рода - RTP, определенный в RFC 1889.

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

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

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

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

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

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

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

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

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

• поле версии (2 бита): текущая версия - вторая;
• поле заполнения (1 бит): это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. (Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.) В этом случае последний октет указывает число заполняющих октетов;
• поле расширения заголовка (1 бит): когда это поле задано, то за основным заголовком следует еще один, дополнительный, используемый в экспериментальных расширениях RTP;
• поле числа отправителей (4 бита): это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком;
• поле маркера (1 бит): смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания;
• поле типа полезной нагрузки (7 бит): это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol);
• поле порядкового номера (16 бит): каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент (например, пакеты, принадлежащие одному и тому же видеокадру);
• поле отметки о времени (32 бита): здесь записывается момент времени, когда был создан первый октет данных полезной нагрузки. Единицы, в которых в этом поле указывается время, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя;
• поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса.

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

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Отдельный протокол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) работает с несколькими адресатами для обеспечения обратной связи с отправителями данных RTP и другими участниками сеанса.

RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участникам сеанса. RFC 1889 описывает три функции, выполняемые RTCP.

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

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

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

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

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

При небольшом числе участников один пакет RTCP посылается максимум каждые пять секунд. RFC 1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

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

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

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

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

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

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

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

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

Резервирование ресурсов позволяет маршрутизаторам заранее определить, в состоянии ли они осуществить доставку многоадресного трафика всем получателям.

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

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

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

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

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

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

RSVP не определяет содержания спецификации потока, он просто передает запрос. Спецификация потока обычно включает класс услуг, Rspec (R означает резерв) и Tspec (T означает трафик). Два других параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP.

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

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

Основная сложность RSVP связана с многоадресной рассылкой. Пример многоадресной конфигурации приведен на рис. 6 . Эта конфигурация состоит из четырех маршрутизаторов. Канал между двумя любыми маршрутизаторами, изображаемый линией, может представлять собой как прямой канал, так и подсеть. Три хоста - Gl, G2 и G3 - входят в одну группу и получают дейтаграммы с соответствующим групповым адресом. Данные по этому адресу передаются двумя хостами - S1 и S2. Красная линия соответствует дереву маршрутизации для S1 и данной группы, а синяя линия - для S2 и данной группы. Линии со стрелками указывают направление передачи пакетов от S1 (красная) и от S2 (синяя).

Рисунок показывает, что все четыре маршрутизатора должны знать о резервировании ресурсов каждым получателем. Таким образом, запросы на выделение ресурсов распространяются в обратном направлении по дереву маршрутизации.

RSVP использует два основных типа сообщений: Resv и Path. Сообщения Resv генерируются получателями и распространяются вверх по дереву, причем каждый узел по пути объединяет и компонует пакеты от разных получателей, когда это возможно. Эти сообщения приводят к переходу маршрутизатора в состояние резервирования ресурсов для данного сеанса (группового адреса). В конце концов все объединенные сообщения Resv достигают хостов-отправителей. Основываясь на полученной информации, они задают надлежащие параметры управления графиком для первого транзитного узла.

Рис. 7 показывает поток сообщений Resv. Обратите внимание: сообщения объединяются; следовательно, только одно сообщение передается вверх по любой ветви комбинированного дерева доставки. Однако эти сообщения должны периодически рассылаться вновь для продления срока резервирования ресурсов.

Сообщение Path используется для распространения информации об обратном маршруте. Всеми современными протоколами многоадресной маршрутизации поддерживается только прямой маршрут в виде дерева распространения (вниз от отправителя). Но сообщения Resv должны передаваться в обратном направлении через все промежуточные маршрутизаторы всем хостам-отправителям.

Поскольку протокол маршрутизации не предоставляет информации об обратном маршруте, она передается RSVP в сообщениях Path. Любой хост, желающий стать отправителем, посылает сообщение Path всем членам группы. По пути каждый маршрутизатор и каждый хост-адресат переходит в состояние path, указывающее, что пакеты для этого отправителя должны пересылаться на транзитный узел, с которого данный пакет получен. Рис. 5 показывает, что пакеты Path передаются по тем же самым путям, что и пакеты данных.

Рассмотрим работу протокола RSVP. С точки зрения хоста работа протокола состоит из следующих этапов (первые два этапа в этой последовательности имеют иногда обратную очередность).

1. Получатель вступает в группу многоадресной рассылки посредством отправки сообщения по протоколу IGMP соседнему маршрутизатору.
2. Потенциальный отправитель отправляет сообщение по адресу группы.
3. Получатель принимает сообщение Path, идентифицирующее отправителя.
4. Теперь, когда получатель имеет информацию об обратном пути, он может отправлять сообщения Resv с дескрипторами потока.
5. Сообщения Resv передаются по сети отправителю.
6. Отправитель начинает передачу данных.
7. Получатель начинает прием пакетов данных.

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

В качестве примера реального применения этих протоколов можно привести модель VoIP (Voice over IP) – передачи голоса по IP-сетям, которая описана в стандарте H.232 и предусматривает передачу аудио-, видеоинформации и данных через IP-сеть. В этом случае протокол реального времени RTP используется для установления соединения, а протокол RSVP – для резервирования ресурсов сети.