 |
|
 |
| Главное меню | ||
· Главная · Права на контект · Скачать NOD32 |
||
| Сетевые технологии | ||
· Учебные пособия и обзоры · Беспроводные технологии · Локальные сети · Сетевое оборудование · Сети хранения данных · TCP/IP · xDSL · ATM · Netware |
||
| Счетчики | ||
|
|
||
| Друзья | ||
 |
 |
|
Управляющий протокол RTCP (RTP control protocol; см. RFC-1889 \"RTP: A Transport Protocol for Real-Time Applications\" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и используется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции:
1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании, но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети. 2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы. 3. Первые две функции требуют, чтобы все участники посылали RTCP-пакеты, следовательно скорость передачи должна контролироваться для того, чтобы RTP мог работать с большим числом участников. При посылке каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это число используется при вычислении частоты посылки пакетов. 4. Четвертая опционная функция служит для передачи минимальной управляющей информации, например идентификаторов участников, для графического интерфейса пользователя. Это полезно для \"слабо управляемых\" сессий, когда участники входят и выходят без должного контроля и без согласования параметров. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения. Функции 1-3 являются обязательными, когда RTP используется в среде с IP мультикастингом, и рекомендательными для всех остальных сред. Разработчикам приложений RTP рекомендуется избегать механизмов, которые могут работать только в уникастном режиме. Формат пакетов RTCP Стандарт определяет несколько типов RTCP пакетов, которые предназначены для переноса управляющей информации: sr: Отчет отправителя. Для статистики приема и передачи участников, которые являются активными отправителями rr: Отчет получателя. Для получения статистики от участников, которые не являются активными отправителями sdes: Элементы описания источника, включая cname bye: Отмечает прекращение участия в группе app: Специфические функции приложения Каждый RTCP-пакет начинается с фиксированной части, сходной с той, которая используется RTP-пакетами, за ней следуют структурные элементы, которые могут иметь переменную длину в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета. Каждый индивидуальный RTCP пакет в составном пакете может обрабатываться независимо без каких-либо требований к порядку или комбинации пакетов. Однако, для того чтобы выполнить функции протокола накладываются следующие ограничения: Статистика приема (в SR или RR) должна посылаться так часто, как это позволяют ограничения пропускной способности, так что каждый периодически посылаемый составной пакет включает в себя пакет отчета. Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname. Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено. Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат: Префикс шифрования. Если составной пакет должен быть зашифрован, он снабжается 32-битным случайным числом-префиксом, которое копируется для каждого передаваемого составного пакета. SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye. Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах. SDES. SDES-пакет, содержащий Cname, должен быть включен в каждый составной RTCP-пакет. Другие элементы описания источника могут быть опционно добавлены, если этого требует характер приложения и позволяет пропускная способность используемого канала. Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться. |