Работа IP-телефонии, передача голоса, аудио-, видео-, конференц-связь имеет свою существенную специфику, особенно в условиях уже созданных компьютерных сетей. Поэтому необходимо хорошо понимать требования, хорошо знать условия работы и уметь прогнозировать результаты воздействия комплекса применяемых правил и протоколов.
2.1. Адресация в IP-сетях
Каждый терминал в сети TCP/IP имеет адреса трех уровней.
Физический (МАС-адрес) - локальный адрес узла, определяемый технологией, с помощью которой построена отдельная сеть, куда входит данный узел.
Сетевой (IP-адрес), состоящий из 4 байтов, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно или назначен по рекомендации специального подразделения Интернета (Network Information Center, NIC), если сеть должна работать как составная часть Интернета. Обычно провайдеры услуг Интернета получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами.Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла - гибкое, и граница между этими полями может устанавливаться весьма условно. Узел может входить в несколько IP-сетей. В этом случае узел должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом, IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.
Символьный (DNS-имя) - идентификатор-имя. Этот адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена.
Интернет - это совокупность тысяч компьютеров, объединенных в сети, которые, в свою очередь, соединены между собой посредством маршрутизаторов.
Сеть Интернет имеет иерархическую структуру. Этот подход является эффективным, потому что позволяет идентифицировать компоненты Интернета посредством адресов, также имеющих иерархическую структуру. Старшие биты адреса идентифицируют сеть, в которой находится рабочая станция, а младшие - расположение рабочей станции в этой сети.
Подавляющее большинство сетей сейчас использует протокол IPv4 (интернет-протокол версии 4), хотя уже разработана шестая версия протокола IP. Схема адресации протокола IPv4 предусматривает размер адресного поля 32 бита, что дает 232 (или 4 294 967 296) потенциальных адресов.
IP-адрес любой рабочей станции состоит из адреса сети и адреса компьютера в этой сети. В архитектуре адресации предусмотрено пять форматов адреса, каждый из которых начинается с одного, двух, трех или четырех битов, идентифицирующих класс сети (класс А, В, С, D или Е ). Область сетевого идентификатора (Network ID) определяет конкретную сеть в классе, а область Host ID идентифицирует конкретный компьютер в сети, а именно:
адреса класса А идентифицируются начальным битом 0. Следующие семь битов определяют конкретную сеть (число возможных значений - 128, или 27). Остальные 24 бита определяют конкретный компьютер в сети, при возможном количестве компьютеров 16 777 216 (224). Адреса класса А предназначены для очень крупных сетей с большим количеством рабочих станций;
адреса класса В идентифицируются начальной двухбитовой двоичной последовательностью 10. Следующие 14 битов определяют сеть, при возможном количестве сетей 16 384 (214). Остальные 16 битов определяют конкретный компьютер, с возможным количеством компьютеров 65 536 (216);
адреса класса С идентифицируются начальной трехбитовой последовательностью 110. Следующие 21 бит определяют сеть, с возможным количеством сетей 2 097 152. Остальные 8 битов определяют конкретный компьютер в сети, с возможным количеством компьютеров 256 (28). Большинство организаций имеют адреса класса С ;
адреса класса D идентифицируются начальной четырехбитовой последовательностью 1110. Адреса этого класса предназначены для групповой передачи, и оставшиеся 28 битов определяют групповой адрес;
адреса класса Е идентифицируются начальной четырехбитовой двоичной последовательностью 1111. Адреса этого класса зарезервированы для будущего использования.
(рис 2.1) Структура IP-адресаСпособ, при помощи которого записываются все IP-адреса, называется пунктирной десятичной системой обозначений. Каждое 32-битовое адресное поле разделено на четыре поля в виде ххх.ххх.ххх.ххх, и каждому полю дается десятичное числовое значение от 0 до 255, выраженное в виде одного октета (28 = 256, или 0-255). Адреса класса А начинаются с 1 до 127, адреса класса В - с 128 до 191, и адреса класса С - с 192 до 223.
| Класс |
Наименьший адрес |
Наибольший адрес |
|---|
| А |
1.0.0.0 |
126.0.0.0 |
| В |
128.0.0.0 |
191.255.0.0 |
| С |
192.0.0.0 |
223.255.255.0 |
| D |
224.0.0.0 |
239.255.255.255 |
| Е |
240.0.0.0 |
247.255.255.255 |
Строго говоря, адрес идентифицирует только сетевой интерфейс рабочей станции, т. е. точку подключения к сети.
IP-адреса распределяются Корпорацией Интернет по присвоению имен и номеров (ICANN). Класс IP-адреса и, следовательно, количество возможных адресов компьютеров зависит от размеров организации. Организация, которой присвоены номера, может затем переназначить их на основе либо статической, либо динамической адресации. Статическая адресация означает жесткую привязку IP-адреса к конкретному компьютеру. При динамической адресации компьютеру присваивается доступный IP-адрес всякий раз при установлении соединения. Динамическое присвоение IP-адресов обычно осуществляется через маршрутизатор, работающий по протоколу DHCP (протокол динамической конфигурации рабочей станции). Наоборот, если доступ к поставщику осуществляется по xDSL, поставщик услуг Интернет обычно присваивает пользователю один или более статических IP-адресов.
Как уже отмечалось, протокол IP версии 4 предусматривает размер адресного поля 32 бита, что дает 232 (или 4 294 967 296) потенциальных адресов. Однако возрастающая популярность технологии TCP/IP привела к истощению плана нумерации протокола. Дополнительной проблемой является тот факт, что очень большое количество адресов класса А и класса В было выделено крупным организациям, которые в них на самом деле не нуждались, и поскольку фактически использовался только небольшой процент адресов, огромное количество доступных адресов было потеряно.
Протокол IPv6 решает этот вопрос путем расширения адресного поля до 128 битов, обеспечивая тем самым 2128 потенциальных адресов, что составляет величину 340.282.366.920.938.463.463.374.607.431.768.211.456.
Протокол IPv6 обладает также дополнительными функциональными возможностями, хотя для их реализации потребуется модернизация существующего сетевого программного обеспечения.
Но вернемся к протоколу IPv4. Компьютер, подключенный к сети Интернет, кроме IP-адреса может идентифицироваться доменным именем. Сеть Интернет разделена на логические области (домены). Адреса в системе имен доменов (DNS), администрирование которых лежит на ICANN, имеют стандартный вид: последовательность имен, разделенных точками. Домены TLD, которые идентифицируются как суффикс доменного имени, бывают двух типов: обобщенные домены верхнего уровня ( net, com, org ) и коды стран ( ru, fi, ua ).
Имена доменов гораздо легче запомнить и ввести, но необходимо преобразование для перевода имен доменов в IP-адреса - для того, чтобы разные маршрутизаторы и коммутаторы могли направить информацию в нужный пункт назначения.
2.2. Модель OSI
Функционирование сети Интернет основано на сложном комплексе протоколов, обеспечивающих выполнение различных функций - от непосредственно передачи данных до управления конфигурацией оборудования сети.
Для того, чтобы классифицировать различные протоколы и понять их место в общей структуре технологии межсетевого взаимодействия, удобно воспользоваться так называемым "многоуровневым представлением сетевых протоколов". В рамках такого представления подразумевается, что протоколы более высокого уровня используют функции протоколов более низкого уровня. Классической моделью такого рода является семиуровневая модель взаимодействия открытых систем (Open Systems Interconnection - OSI), разработанная ITU-T.
Первый уровень модели - уровень сетевого интерфейса - поддерживает физический процесс переноса информации между устройствами в сети, т. е. объединяет функции двух уровней OSI - физического и звена данных. Второй уровень сетевого интерфейса обеспечивает физическое соединение со средой передачи, обеспечивает разрешение конфликтов, возникающих в процессе организации доступа к среде (например, используя технологию CSMA/CD в сети Ethernet), упаковывает данные в пакеты. Пакет - это протокольная единица, которая содержит информацию верхних уровней и служебные поля (аппаратные адреса, порядковые номера, подтверждения и т. д.), необходимые для функционирования протоколов этого уровня.
(рис 2.2) Уровни модели OSIСетевой уровень отвечает за передачу информации, упакованной в дейтаграммы (datagram), от одного компьютера к другому. Дейтаграмма - это протокольная единица, которой оперируют протоколы семейства TCP/IP. Она содержит адресную информацию, необходимую для переноса дейтаграммы через сеть, а не только в рамках одного звена данных. Понятие дейтаграммы никак не связано с физическими характеристиками сетей и каналов связи, что подчеркивает независимость протоколов TCP/IP от аппаратуры. Основным протоколом, реализующим функции сетевого уровня, является протокол IP. Этот протокол отвечает за маршрутизацию, фрагментацию и сборку дейтаграмм в рабочей станции.
Обмен между сетевыми узлами информацией о состоянии сети, необходимой для формирования оптимальных маршрутов следования дейтаграмм, обеспечивают протоколы маршрутизации - RIP, EGP, BGP, OSPF и др.
Протокол преобразования адресов (Address Resolution Protocol - ARP) преобразует IP-адреса в адреса, использующиеся в локальных сетях (например, Ethernet). На некоторых рисунках, изображающих архитектуру и взаимосвязь протоколов, ARP размещают ниже IP, чтобы показать его тесную взаимосвязь с уровнем сетевого интерфейса.
Протокол контрольных сообщений - (Internet Control Message Protocol - ICMP) предоставляет возможность программному обеспечению рабочей станции или маршрутизатора обмениваться информацией о проблемах маршрутизации пакетов с другими устройствами в сети. Протокол ICMP - необходимая часть реализации стека протоколов TCP/IP.
Когда дейтаграмма проходит по сети, она может быть потеряна или искажена. Транспортный уровень решает эту проблему и обеспечивает надежную передачу информации от источника к приемнику. Кроме того, реализации протоколов этого уровня образуют универсальный интерфейс для приложений, дающий доступ к услугам сетевого уровня. Наиболее важными протоколами транспортного уровня являются TCP и UDP.
Конечные пользователи взаимодействуют с компьютером на уровне пользовательских приложений. Разработано множество протоколов, применяемых соответствующими приложениями. Например, приложения передачи файлов используют протокол FTP, веб-приложения - протокол HTTP. Оба протокола, FTP и HTTP, базируются на протоколе TCP. Приложение Telnet обеспечивает подключение удаленных терминалов. Протокол эксплуатационного управления сетью SNMP позволяет управлять конфигурацией оборудования в сети и собирать информацию о его функционировании, в том числе и об аварийных ситуациях. Приложения, созданные для организации речевой связи и видеосвязи, используют протокол RTP для передачи информации, чувствительной к задержкам. Х Window - популярный протокол для подключения к интеллектуальному графическому терминалу. Этот список можно еще продолжить рядом протоколов.
Таким образом, IP-сети используют для передачи информации разнообразные протоколы, причем функции протоколов не зависят от того, какие данные передаются. Иными словами, IP, ARP, ICMP, TCP, UDP и другие элементы стека протоколов TCP/IP предоставляют универсальные средства передачи информации, какой бы природы она ни была (файл по FTP, веб-страница или аудиоданные).
2.3. Основные протоколы IP-телефонии
2.3.1. Протокол IP версии 4
В качестве основного протокола сетевого уровня в стеке протоколов TCP/IP применяется протокол IP, который изначально проектировался как протокол передачи пакетов в сетях, состоящих из большого количества локальных сетей. Поэтому он хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP организует пакетную передачу информации от узла к узлу IP-сети, не используя процедур установления соединения между источником и приемником информации. Кроме того, Internet Protocol является дейтаграммным протоколом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.
Протокол IP не обеспечивает надежность доставки информации, так как он не имеет механизмов повторной передачи. Он не имеет также и механизмов управления потоком данных (flow-control). Дейтаграммы могут быть потеряны, размножены или получены не в том порядке, в каком были переданы.
Протокол IP базируется на протоколе уровня звена данных, который обеспечивает передачу данных по физической среде. Программный модуль, реализующий протокол IP, определяет маршрут переноса данных по сети до точки назначения или до промежуточного маршрутизатора, где дейтаграмма извлекается из кадра локальной сети и направляется в канал, который соответствует выбранному маршруту. Дейтаграммы могут разбиваться на более мелкие фрагменты, или, наоборот, несколько дейтаграмм могут объединяться в одну на стыке разных сетей, если эти сети поддерживают передачу дейтаграмм разной длины.
В каждой рабочей станции, подключенной к IP-сети, обработка IP-дейтаграмм производится по одним и тем же правилам адресации, фрагментации и маршрутизации. Рабочие станции рассматривают каждую дейтаграмму как независимую протокольную единицу.
На рис 2.3 показана структура протокольной единицы протокола IP-дейтаграммы.
Поле версия (version) идентифицирует используемую версию протокола IP, в рассматриваемом случае указывается версия 4. Необходимость этого поля объясняется тем, что в переходный период в сети могут применяться протоколы разных версий.
Поле длина заголовка (header length), состоящее из 4 битов, определяет длину заголовка, причем длина указывается как количество блоков размером 32 бита. В типичном случае значение этого поля равно 5.
(рис 2.3) IP-дейтаграммаПоле Тип обслуживания (Type of Service) содержит информацию, которая бывает нужна при поддержке сетью разных классов обслуживания. Использование этого поля в Интернете будет возрастать по мере роста в IP-сетях возможностей передачи мультимедийного трафика с задаваемыми параметрами качества обслуживания.
Поле Общая длина (Total Length) определяет общую длину дейтаграммы в октетах (байтах), включая заголовок и полезную нагрузку. Максимальная длина дейтаграммы составляет 65535 октетов, однако на практике все рабочие станции и маршрутизаторы работают с длинами, не превышающими 576 байтов. Это объясняется тем, что при превышении указанной длины снижается эффективность работы сети.
Протокол IP использует 3 поля заголовка для управления фрагментацией/сборкой дейтаграмм. Как уже упоминалось, фрагментация необходима, потому что разные сети, по которым передаются дейтаграммы, имеют разные максимальные размеры кадра.
Идентификатор фрагмента (Identifier) обозначает все фрагменты одной дейтаграммы, что необходимо для ее успешной сборки на приемной стороне.
Поле Флагов (Flags) обеспечивает возможность фрагментации дейтаграмм и, при использовании фрагментации, позволяет идентифицировать последний фрагмент дейтаграммы.
Поле Смещение фрагмента (Fragment Offset) определяет положение фрагмента относительно исходной дейтаграммы в единицах, равных 8 октетам.
Поле Время жизни (TTL - Time To Live) используется для ограничения времени, в течение которого дейтаграмма находится в сети. Каждый маршрутизатор сети должен уменьшать значение этого поля на единицу и отбрасывать дейтаграмму, если поле TTL приняло нулевое значение. Наличие поля TTL ограничивает возможность бесконечной циркуляции дейтаграммы по сети.
Поле Протокол (Protocol) идентифицирует протокол верхнего уровня (TCP, UDP и т. д.).
Поле Контрольная сумма заголовка (Header Checksum) обеспечивает возможность контроля ошибок в заголовке. Алгоритм подсчета контрольной суммы весьма прост, поскольку обычно протоколы нижнего уровня имеют более развитые средства контроля ошибок.
IP-дейтаграммы содержат в заголовке два адреса - отправителя ( Source ) и получателя ( Destination ), которые не меняются на протяжении всей жизни дейтаграммы.
2.3.2. Протокол IP версии 6
Самой насущной проблемой все чаще становится нехватка адресного пространства, что требует изменения формата адреса.
Другой проблемой является недостаточная масштабируемость процедуры маршрутизации - основы IP-сетей. Быстрый рост сети вызывает перегрузку маршрутизаторов, которые уже сегодня вынуждены поддерживать таблицы маршрутизации с десятками и сотнями тысяч записей, а также решать проблемы фрагментации пакетов. Облегчить работу маршрутизаторов можно, в частности, путем модернизации протокола IP.
Наряду с вводом новых функций непосредственно в протокол IP, целесообразно обеспечить более тесное взаимодействие его с новыми протоколами путем введения в заголовок пакета новых полей.
В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:
создание новой расширенной схемы адресации;
улучшение масштабируемости сетей за счет сокращения функций магистральных маршрутизаторов;
обеспечение защиты данных.
Расширение адресного пространства. Протокол IP решает потенциальную проблему нехватки адресов за счет расширения разрядности адреса до 128. Однако такое существенное увеличение длины адреса было сделано в значительной степени не с целью снять проблему дефицита адресов, а для повышения эффективности работы сетей на основе этого протокола. Главной целью было структурное изменение системы адресации, расширение ее функциональных возможностей.
Вместо существующих двух уровней иерархии адреса (номер сети и номер узла) в протоколе IPv6 предлагается использовать четыре уровня, что предполагает трехуровневую идентификацию сетей и один уровень для идентификации узлов.
Теперь адрес записывается в шестнадцатеричном виде, причем каждые четыре цифры отделяются друг от друга двоеточием, например:
FEDC:0A96:0:0:0:0:7733:567A.
Для сетей, поддерживающих обе версии протокола IPv4 и IPv6, имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатеричную:
0:0:0:0:FFFF 194.135.75.104.
В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, то есть для сетей, не входящих в Интернет. Существует две разновидности локальных адресов: для "плоских" сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), которые различаются значением префикса.
Изменение формата заголовков пакетов. Реализовать это позволяет новая схема организации "вложенных заголовков", обеспечивающая разделение заголовка на основной, который содержит необходимый минимум информации, и дополнительные, которые могут отсутствовать. Такой подход открывает богатые возможности для расширения протокола путем определения новых опциональных заголовков, делая протокол открытым.
Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат (рис 2.4).
(рис 2.4) Формат основного заголовка дейтаграммы IPv6Поле Класс трафика (Traffic Class) эквивалентно по назначению полю Тип обслуживания (Type Of Service), а поле Лимит переходов (Hop Limit) - полю Время жизни (Time To Live) протокола IPv4.
Поле Метка потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.
Поле Следующий заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header.
2.3.3. Протокол TCP
Протокол управления передачей информации (Transmission Control Protocol - TCP) был разработан для поддержки интерактивной связи между компьютерами. Протокол TCP обеспечивает надежность и достоверность обмена данными между процессами на компьютерах, входящих в общую сеть.
К сожалению, протокол TCP не приспособлен для передачи мультимедийной информации. Основная причина - наличие контроля за доставкой. Контроль отнимает слишком много времени для передачи более чувствительной к задержкам информации. Кроме того, TCP предусматривает механизмы управления скоростью передачи с целью избежать перегрузок сети. Аудио- и видеоданные требуют, однако, строго определенных скоростей передачи, которые нельзя изменять произвольным образом.
С одной стороны протокол TCP взаимодействует с прикладным протоколом пользовательского приложения, а с другой - с протоколом, обеспечивающим "низкоуровневые" функции маршрутизации и адресации пакетов, которые, как правило, выполняет IP.
Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Интернет, изображена на рис 2.5.
Прямоугольники обозначают модули, обрабатывающие данные, а линии, соединяющие прямоугольники, - пути передачи данных. Горизонтальная линия внизу рисунка обозначает сеть Ethernet, которая используется в качестве примера физической среды.
(рис 2.5) Структура сетевого программного обеспечения стека протоколов TCP/IPЧтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только интернет-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Интернет однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.
Протокол TCP умеет работать с поврежденными, потерянными, дублированными или поступившими с нарушением порядка следования пакетами. Это достигается благодаря механизму присвоения каждому передаваемому пакету порядкового номера и механизму проверки получения пакетов.
Когда протокол TCP передает сегмент данных, копия этих данных помещается в очередь повтора передачи и запускается таймер ожидания подтверждения.
2.3.4. Протокол UDP
Протокол передачи пользовательских дейтаграмм (User Datagram Protocol - UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.
Протокол UDP базируется на протоколе IP и предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает негарантированную доставку данных, т. е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации, т. е. между модулями UDP.
2.3.5. Протоколы RTP и RTCP
Основные понятия
Транспортный протокол реального времени 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 для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются: использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т. д. Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т. п. не предусмотрено.
Таким образом, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться в RTP.
Групповая аудио-конференц-связь
Для организации групповой аудио-конференц-связи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, в этом случае также должен быть сгенерирован и распределен ключ шифрования.
Приложение аудио-конференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) применялся при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Интернет, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент и насколько хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.
Видео-конференц-связь
Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов, чтобы сеансы могли быть связаны.
Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
Понятие о микшерах и трансляторах
Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках
можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.
Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференц-связи с использованием протокола IP (IPM - IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.
Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену.
Протокол управления RTCP
Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.
Протокол управления RTСP (RTCP - Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.
Главная функция - обеспечение обратной связи для оценки качества распределения данных. Это неотъемлемая функция RTСP как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, можно также получать информацию обратной связи и действовать при диагностике проблем сети как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP.
RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый "каноническим именем" ( CNAME - canonical name). Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP, например, при синхронизации звукового и видеосигнала.
Первые две функции требуют, чтобы все участники посылали пакеты RTCP, следовательно, для предоставления возможности масштабирования числа участников протоколом RTP должна регулироваться частота передачи таких пакетов. При посылке каждым участником телеконференции управляющих пакетов всем остальным участникам, каждый может независимо оценивать общее число участников.
Четвертая, дополнительная, функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в "свободно управляемых" сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.
Функции с первой по третью являются обязательными, когда RTP используется в IP-мультивещании, и рекомендуемыми во всех остальных случаях. Разработчикам приложений RTP предлагается избегать механизмов, работающих только в двустороннем режиме и не масштабируемых для увеличения числа пользователей.
Интенсивность передачи пакетов RTCP
Протокол RTP позволяет приложению автоматически масштабировать представительность сеанса связи в пределах от нескольких участников до нескольких тысяч. Например, в аудиоконференции трафик данных, по существу, является самоограничивающим, потому что только один или два человека могут говорить одновременно, и при групповом распределении скорость передачи данных на любой линии связи остается относительно постоянной, не зависящей от числа участников. Однако трафик управления самоограничивающим не является. Если отчеты приема от каждого участника посылаются с постоянной интенсивностью, то трафик управления с ростом числа участников будет расти линейно. Следовательно, должен быть предусмотрен специальный механизм понижения частоты передачи управляющих пакетов.
Для каждого сеанса предполагается, что трафик данных соответствует агрегированному пределу, называемому полосой пропускания сеанса связи, которая совместно используется всеми участниками. Эта полоса пропускания может быть зарезервирована, и ее предел установлен сетью. Полоса пропускания сеанса не зависит от типа кодирования мультимедийных данных, но выбор типа кодирования может быть ограничен полосой пропускания сеанса связи. Параметр полосы пропускания сеанса, как ожидается, будет обеспечен приложением управления сеанса, когда оно вызовет мультимедийное приложение, но мультимедийные приложения могут также устанавливать значение по умолчанию, основанное на полосе пропускания данных с единственным отправителем для типа кодирования, выбранного для данного сеанса.
Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.
Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5 %. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так, чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.
Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики:
отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов;
требуется, чтобы расчетный интервал между пакетами RTCP, как минимум, превышал 5 секунд, чтобы избежать пачек пакетов RTCP, превышающих дозволенную полосу пропускания, когда число участников мало и трафик не сглаживается согласно закону больших чисел;
интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание непреднамеренной синхронизации всех участников. Первый пакет RTCP, посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи;
для автоматической адаптации к изменениям в объеме передаваемой информации управления вычисляется динамическая оценка среднего размера составного пакета RTCP с использованием всех полученных и посланных пакетов;
этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае параметр полосы пропускания сеанса - это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5 % от этой величины.
Взаимодействие RTP с протоколами сетевого и транспортного уровней
Если не установлено иначе спецификациями других протоколов, то при передаче "голосовых" пакетов применяются следующие основные правила.
RTP полагается на протоколы нижележащих уровней при обеспечении разделения потоков данных RTP и управляющей информации RTCP. Для протокола UDP и подобных ему протокол RTP использует четный номер порта, а соответствующий поток RTCP - порт с номером на единицу большим.
Информационные пакеты RTP не содержат никакого поля длины, следовательно, RTP полагается на нижележащий протокол и для обеспечения индикации длины. Максимальная длина пакетов RTP ограничивается только протоколами нижележащих уровней.
В одном блоке данных протокола нижележащего уровня, например, в пакете UDP, могут передаваться несколько пакетов протокола RTP. Это позволяет уменьшить избыточность заголовков и упростить синхронизацию между различными потоками.
Работа IP-телефонии, передача голоса, аудио-, видео-, конференц-связь имеет свою существенную специфику, особенно в условиях уже созданных компьютерных сетей. Поэтому необходимо хорошо понимать требования, хорошо знать условия работы и уметь прогнозировать результаты воздействия комплекса применяемых правил и протоколов.
2.1. Адресация в IP-сетях
Каждый терминал в сети TCP/IP имеет адреса трех уровней.
Физический (МАС-адрес) - локальный адрес узла, определяемый технологией, с помощью которой построена отдельная сеть, куда входит данный узел.
Сетевой (IP-адрес), состоящий из 4 байтов, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно или назначен по рекомендации специального подразделения Интернета (Network Information Center, NIC), если сеть должна работать как составная часть Интернета. Обычно провайдеры услуг Интернета получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами.Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла - гибкое, и граница между этими полями может устанавливаться весьма условно. Узел может входить в несколько IP-сетей. В этом случае узел должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом, IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.
Символьный (DNS-имя) - идентификатор-имя. Этот адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена.
Интернет - это совокупность тысяч компьютеров, объединенных в сети, которые, в свою очередь, соединены между собой посредством маршрутизаторов.
Сеть Интернет имеет иерархическую структуру. Этот подход является эффективным, потому что позволяет идентифицировать компоненты Интернета посредством адресов, также имеющих иерархическую структуру. Старшие биты адреса идентифицируют сеть, в которой находится рабочая станция, а младшие - расположение рабочей станции в этой сети.
Подавляющее большинство сетей сейчас использует протокол IPv4 (интернет-протокол версии 4), хотя уже разработана шестая версия протокола IP. Схема адресации протокола IPv4 предусматривает размер адресного поля 32 бита, что дает 232 (или 4 294 967 296) потенциальных адресов.
IP-адрес любой рабочей станции состоит из адреса сети и адреса компьютера в этой сети. В архитектуре адресации предусмотрено пять форматов адреса, каждый из которых начинается с одного, двух, трех или четырех битов, идентифицирующих класс сети (класс А, В, С, D или Е ). Область сетевого идентификатора (Network ID) определяет конкретную сеть в классе, а область Host ID идентифицирует конкретный компьютер в сети, а именно:
адреса класса А идентифицируются начальным битом 0. Следующие семь битов определяют конкретную сеть (число возможных значений - 128, или 27). Остальные 24 бита определяют конкретный компьютер в сети, при возможном количестве компьютеров 16 777 216 (224). Адреса класса А предназначены для очень крупных сетей с большим количеством рабочих станций;
адреса класса В идентифицируются начальной двухбитовой двоичной последовательностью 10. Следующие 14 битов определяют сеть, при возможном количестве сетей 16 384 (214). Остальные 16 битов определяют конкретный компьютер, с возможным количеством компьютеров 65 536 (216);
адреса класса С идентифицируются начальной трехбитовой последовательностью 110. Следующие 21 бит определяют сеть, с возможным количеством сетей 2 097 152. Остальные 8 битов определяют конкретный компьютер в сети, с возможным количеством компьютеров 256 (28). Большинство организаций имеют адреса класса С ;
адреса класса D идентифицируются начальной четырехбитовой последовательностью 1110. Адреса этого класса предназначены для групповой передачи, и оставшиеся 28 битов определяют групповой адрес;
адреса класса Е идентифицируются начальной четырехбитовой двоичной последовательностью 1111. Адреса этого класса зарезервированы для будущего использования.
(рис 2.1) Структура IP-адресаСпособ, при помощи которого записываются все IP-адреса, называется пунктирной десятичной системой обозначений. Каждое 32-битовое адресное поле разделено на четыре поля в виде ххх.ххх.ххх.ххх, и каждому полю дается десятичное числовое значение от 0 до 255, выраженное в виде одного октета (28 = 256, или 0-255). Адреса класса А начинаются с 1 до 127, адреса класса В - с 128 до 191, и адреса класса С - с 192 до 223.
| Класс |
Наименьший адрес |
Наибольший адрес |
|---|
| А |
1.0.0.0 |
126.0.0.0 |
| В |
128.0.0.0 |
191.255.0.0 |
| С |
192.0.0.0 |
223.255.255.0 |
| D |
224.0.0.0 |
239.255.255.255 |
| Е |
240.0.0.0 |
247.255.255.255 |
Строго говоря, адрес идентифицирует только сетевой интерфейс рабочей станции, т. е. точку подключения к сети.
IP-адреса распределяются Корпорацией Интернет по присвоению имен и номеров (ICANN). Класс IP-адреса и, следовательно, количество возможных адресов компьютеров зависит от размеров организации. Организация, которой присвоены номера, может затем переназначить их на основе либо статической, либо динамической адресации. Статическая адресация означает жесткую привязку IP-адреса к конкретному компьютеру. При динамической адресации компьютеру присваивается доступный IP-адрес всякий раз при установлении соединения. Динамическое присвоение IP-адресов обычно осуществляется через маршрутизатор, работающий по протоколу DHCP (протокол динамической конфигурации рабочей станции). Наоборот, если доступ к поставщику осуществляется по xDSL, поставщик услуг Интернет обычно присваивает пользователю один или более статических IP-адресов.
Как уже отмечалось, протокол IP версии 4 предусматривает размер адресного поля 32 бита, что дает 232 (или 4 294 967 296) потенциальных адресов. Однако возрастающая популярность технологии TCP/IP привела к истощению плана нумерации протокола. Дополнительной проблемой является тот факт, что очень большое количество адресов класса А и класса В было выделено крупным организациям, которые в них на самом деле не нуждались, и поскольку фактически использовался только небольшой процент адресов, огромное количество доступных адресов было потеряно.
Протокол IPv6 решает этот вопрос путем расширения адресного поля до 128 битов, обеспечивая тем самым 2128 потенциальных адресов, что составляет величину 340.282.366.920.938.463.463.374.607.431.768.211.456.
Протокол IPv6 обладает также дополнительными функциональными возможностями, хотя для их реализации потребуется модернизация существующего сетевого программного обеспечения.
Но вернемся к протоколу IPv4. Компьютер, подключенный к сети Интернет, кроме IP-адреса может идентифицироваться доменным именем. Сеть Интернет разделена на логические области (домены). Адреса в системе имен доменов (DNS), администрирование которых лежит на ICANN, имеют стандартный вид: последовательность имен, разделенных точками. Домены TLD, которые идентифицируются как суффикс доменного имени, бывают двух типов: обобщенные домены верхнего уровня ( net, com, org ) и коды стран ( ru, fi, ua ).
Имена доменов гораздо легче запомнить и ввести, но необходимо преобразование для перевода имен доменов в IP-адреса - для того, чтобы разные маршрутизаторы и коммутаторы могли направить информацию в нужный пункт назначения.
2.2. Модель OSI
Функционирование сети Интернет основано на сложном комплексе протоколов, обеспечивающих выполнение различных функций - от непосредственно передачи данных до управления конфигурацией оборудования сети.
Для того, чтобы классифицировать различные протоколы и понять их место в общей структуре технологии межсетевого взаимодействия, удобно воспользоваться так называемым "многоуровневым представлением сетевых протоколов". В рамках такого представления подразумевается, что протоколы более высокого уровня используют функции протоколов более низкого уровня. Классической моделью такого рода является семиуровневая модель взаимодействия открытых систем (Open Systems Interconnection - OSI), разработанная ITU-T.
Первый уровень модели - уровень сетевого интерфейса - поддерживает физический процесс переноса информации между устройствами в сети, т. е. объединяет функции двух уровней OSI - физического и звена данных. Второй уровень сетевого интерфейса обеспечивает физическое соединение со средой передачи, обеспечивает разрешение конфликтов, возникающих в процессе организации доступа к среде (например, используя технологию CSMA/CD в сети Ethernet), упаковывает данные в пакеты. Пакет - это протокольная единица, которая содержит информацию верхних уровней и служебные поля (аппаратные адреса, порядковые номера, подтверждения и т. д.), необходимые для функционирования протоколов этого уровня.
(рис 2.2) Уровни модели OSIСетевой уровень отвечает за передачу информации, упакованной в дейтаграммы (datagram), от одного компьютера к другому. Дейтаграмма - это протокольная единица, которой оперируют протоколы семейства TCP/IP. Она содержит адресную информацию, необходимую для переноса дейтаграммы через сеть, а не только в рамках одного звена данных. Понятие дейтаграммы никак не связано с физическими характеристиками сетей и каналов связи, что подчеркивает независимость протоколов TCP/IP от аппаратуры. Основным протоколом, реализующим функции сетевого уровня, является протокол IP. Этот протокол отвечает за маршрутизацию, фрагментацию и сборку дейтаграмм в рабочей станции.
Обмен между сетевыми узлами информацией о состоянии сети, необходимой для формирования оптимальных маршрутов следования дейтаграмм, обеспечивают протоколы маршрутизации - RIP, EGP, BGP, OSPF и др.
Протокол преобразования адресов (Address Resolution Protocol - ARP) преобразует IP-адреса в адреса, использующиеся в локальных сетях (например, Ethernet). На некоторых рисунках, изображающих архитектуру и взаимосвязь протоколов, ARP размещают ниже IP, чтобы показать его тесную взаимосвязь с уровнем сетевого интерфейса.
Протокол контрольных сообщений - (Internet Control Message Protocol - ICMP) предоставляет возможность программному обеспечению рабочей станции или маршрутизатора обмениваться информацией о проблемах маршрутизации пакетов с другими устройствами в сети. Протокол ICMP - необходимая часть реализации стека протоколов TCP/IP.
Когда дейтаграмма проходит по сети, она может быть потеряна или искажена. Транспортный уровень решает эту проблему и обеспечивает надежную передачу информации от источника к приемнику. Кроме того, реализации протоколов этого уровня образуют универсальный интерфейс для приложений, дающий доступ к услугам сетевого уровня. Наиболее важными протоколами транспортного уровня являются TCP и UDP.
Конечные пользователи взаимодействуют с компьютером на уровне пользовательских приложений. Разработано множество протоколов, применяемых соответствующими приложениями. Например, приложения передачи файлов используют протокол FTP, веб-приложения - протокол HTTP. Оба протокола, FTP и HTTP, базируются на протоколе TCP. Приложение Telnet обеспечивает подключение удаленных терминалов. Протокол эксплуатационного управления сетью SNMP позволяет управлять конфигурацией оборудования в сети и собирать информацию о его функционировании, в том числе и об аварийных ситуациях. Приложения, созданные для организации речевой связи и видеосвязи, используют протокол RTP для передачи информации, чувствительной к задержкам. Х Window - популярный протокол для подключения к интеллектуальному графическому терминалу. Этот список можно еще продолжить рядом протоколов.
Таким образом, IP-сети используют для передачи информации разнообразные протоколы, причем функции протоколов не зависят от того, какие данные передаются. Иными словами, IP, ARP, ICMP, TCP, UDP и другие элементы стека протоколов TCP/IP предоставляют универсальные средства передачи информации, какой бы природы она ни была (файл по FTP, веб-страница или аудиоданные).
2.3. Основные протоколы IP-телефонии
2.3.1. Протокол IP версии 4
В качестве основного протокола сетевого уровня в стеке протоколов TCP/IP применяется протокол IP, который изначально проектировался как протокол передачи пакетов в сетях, состоящих из большого количества локальных сетей. Поэтому он хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Протокол IP организует пакетную передачу информации от узла к узлу IP-сети, не используя процедур установления соединения между источником и приемником информации. Кроме того, Internet Protocol является дейтаграммным протоколом: при передаче информации по протоколу IP каждый пакет передается от узла к узлу и обрабатывается в узлах независимо от других пакетов.
Протокол IP не обеспечивает надежность доставки информации, так как он не имеет механизмов повторной передачи. Он не имеет также и механизмов управления потоком данных (flow-control). Дейтаграммы могут быть потеряны, размножены или получены не в том порядке, в каком были переданы.
Протокол IP базируется на протоколе уровня звена данных, который обеспечивает передачу данных по физической среде. Программный модуль, реализующий протокол IP, определяет маршрут переноса данных по сети до точки назначения или до промежуточного маршрутизатора, где дейтаграмма извлекается из кадра локальной сети и направляется в канал, который соответствует выбранному маршруту. Дейтаграммы могут разбиваться на более мелкие фрагменты, или, наоборот, несколько дейтаграмм могут объединяться в одну на стыке разных сетей, если эти сети поддерживают передачу дейтаграмм разной длины.
В каждой рабочей станции, подключенной к IP-сети, обработка IP-дейтаграмм производится по одним и тем же правилам адресации, фрагментации и маршрутизации. Рабочие станции рассматривают каждую дейтаграмму как независимую протокольную единицу.
На рис 2.3 показана структура протокольной единицы протокола IP-дейтаграммы.
Поле версия (version) идентифицирует используемую версию протокола IP, в рассматриваемом случае указывается версия 4. Необходимость этого поля объясняется тем, что в переходный период в сети могут применяться протоколы разных версий.
Поле длина заголовка (header length), состоящее из 4 битов, определяет длину заголовка, причем длина указывается как количество блоков размером 32 бита. В типичном случае значение этого поля равно 5.
(рис 2.3) IP-дейтаграммаПоле Тип обслуживания (Type of Service) содержит информацию, которая бывает нужна при поддержке сетью разных классов обслуживания. Использование этого поля в Интернете будет возрастать по мере роста в IP-сетях возможностей передачи мультимедийного трафика с задаваемыми параметрами качества обслуживания.
Поле Общая длина (Total Length) определяет общую длину дейтаграммы в октетах (байтах), включая заголовок и полезную нагрузку. Максимальная длина дейтаграммы составляет 65535 октетов, однако на практике все рабочие станции и маршрутизаторы работают с длинами, не превышающими 576 байтов. Это объясняется тем, что при превышении указанной длины снижается эффективность работы сети.
Протокол IP использует 3 поля заголовка для управления фрагментацией/сборкой дейтаграмм. Как уже упоминалось, фрагментация необходима, потому что разные сети, по которым передаются дейтаграммы, имеют разные максимальные размеры кадра.
Идентификатор фрагмента (Identifier) обозначает все фрагменты одной дейтаграммы, что необходимо для ее успешной сборки на приемной стороне.
Поле Флагов (Flags) обеспечивает возможность фрагментации дейтаграмм и, при использовании фрагментации, позволяет идентифицировать последний фрагмент дейтаграммы.
Поле Смещение фрагмента (Fragment Offset) определяет положение фрагмента относительно исходной дейтаграммы в единицах, равных 8 октетам.
Поле Время жизни (TTL - Time To Live) используется для ограничения времени, в течение которого дейтаграмма находится в сети. Каждый маршрутизатор сети должен уменьшать значение этого поля на единицу и отбрасывать дейтаграмму, если поле TTL приняло нулевое значение. Наличие поля TTL ограничивает возможность бесконечной циркуляции дейтаграммы по сети.
Поле Протокол (Protocol) идентифицирует протокол верхнего уровня (TCP, UDP и т. д.).
Поле Контрольная сумма заголовка (Header Checksum) обеспечивает возможность контроля ошибок в заголовке. Алгоритм подсчета контрольной суммы весьма прост, поскольку обычно протоколы нижнего уровня имеют более развитые средства контроля ошибок.
IP-дейтаграммы содержат в заголовке два адреса - отправителя ( Source ) и получателя ( Destination ), которые не меняются на протяжении всей жизни дейтаграммы.
2.3.2. Протокол IP версии 6
Самой насущной проблемой все чаще становится нехватка адресного пространства, что требует изменения формата адреса.
Другой проблемой является недостаточная масштабируемость процедуры маршрутизации - основы IP-сетей. Быстрый рост сети вызывает перегрузку маршрутизаторов, которые уже сегодня вынуждены поддерживать таблицы маршрутизации с десятками и сотнями тысяч записей, а также решать проблемы фрагментации пакетов. Облегчить работу маршрутизаторов можно, в частности, путем модернизации протокола IP.
Наряду с вводом новых функций непосредственно в протокол IP, целесообразно обеспечить более тесное взаимодействие его с новыми протоколами путем введения в заголовок пакета новых полей.
В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:
создание новой расширенной схемы адресации;
улучшение масштабируемости сетей за счет сокращения функций магистральных маршрутизаторов;
обеспечение защиты данных.
Расширение адресного пространства. Протокол IP решает потенциальную проблему нехватки адресов за счет расширения разрядности адреса до 128. Однако такое существенное увеличение длины адреса было сделано в значительной степени не с целью снять проблему дефицита адресов, а для повышения эффективности работы сетей на основе этого протокола. Главной целью было структурное изменение системы адресации, расширение ее функциональных возможностей.
Вместо существующих двух уровней иерархии адреса (номер сети и номер узла) в протоколе IPv6 предлагается использовать четыре уровня, что предполагает трехуровневую идентификацию сетей и один уровень для идентификации узлов.
Теперь адрес записывается в шестнадцатеричном виде, причем каждые четыре цифры отделяются друг от друга двоеточием, например:
FEDC:0A96:0:0:0:0:7733:567A.
Для сетей, поддерживающих обе версии протокола IPv4 и IPv6, имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатеричную:
0:0:0:0:FFFF 194.135.75.104.
В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, то есть для сетей, не входящих в Интернет. Существует две разновидности локальных адресов: для "плоских" сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), которые различаются значением префикса.
Изменение формата заголовков пакетов. Реализовать это позволяет новая схема организации "вложенных заголовков", обеспечивающая разделение заголовка на основной, который содержит необходимый минимум информации, и дополнительные, которые могут отсутствовать. Такой подход открывает богатые возможности для расширения протокола путем определения новых опциональных заголовков, делая протокол открытым.
Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат (рис 2.4).
(рис 2.4) Формат основного заголовка дейтаграммы IPv6Поле Класс трафика (Traffic Class) эквивалентно по назначению полю Тип обслуживания (Type Of Service), а поле Лимит переходов (Hop Limit) - полю Время жизни (Time To Live) протокола IPv4.
Поле Метка потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.
Поле Следующий заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header.
2.3.3. Протокол TCP
Протокол управления передачей информации (Transmission Control Protocol - TCP) был разработан для поддержки интерактивной связи между компьютерами. Протокол TCP обеспечивает надежность и достоверность обмена данными между процессами на компьютерах, входящих в общую сеть.
К сожалению, протокол TCP не приспособлен для передачи мультимедийной информации. Основная причина - наличие контроля за доставкой. Контроль отнимает слишком много времени для передачи более чувствительной к задержкам информации. Кроме того, TCP предусматривает механизмы управления скоростью передачи с целью избежать перегрузок сети. Аудио- и видеоданные требуют, однако, строго определенных скоростей передачи, которые нельзя изменять произвольным образом.
С одной стороны протокол TCP взаимодействует с прикладным протоколом пользовательского приложения, а с другой - с протоколом, обеспечивающим "низкоуровневые" функции маршрутизации и адресации пакетов, которые, как правило, выполняет IP.
Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Интернет, изображена на рис 2.5.
Прямоугольники обозначают модули, обрабатывающие данные, а линии, соединяющие прямоугольники, - пути передачи данных. Горизонтальная линия внизу рисунка обозначает сеть Ethernet, которая используется в качестве примера физической среды.
(рис 2.5) Структура сетевого программного обеспечения стека протоколов TCP/IPЧтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только интернет-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Интернет однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.
Протокол TCP умеет работать с поврежденными, потерянными, дублированными или поступившими с нарушением порядка следования пакетами. Это достигается благодаря механизму присвоения каждому передаваемому пакету порядкового номера и механизму проверки получения пакетов.
Когда протокол TCP передает сегмент данных, копия этих данных помещается в очередь повтора передачи и запускается таймер ожидания подтверждения.
2.3.4. Протокол UDP
Протокол передачи пользовательских дейтаграмм (User Datagram Protocol - UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.
Протокол UDP базируется на протоколе IP и предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает негарантированную доставку данных, т. е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации, т. е. между модулями UDP.
2.3.5. Протоколы RTP и RTCP
Основные понятия
Транспортный протокол реального времени 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 для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются: использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т. д. Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т. п. не предусмотрено.
Таким образом, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться в RTP.
Групповая аудио-конференц-связь
Для организации групповой аудио-конференц-связи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, в этом случае также должен быть сгенерирован и распределен ключ шифрования.
Приложение аудио-конференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) применялся при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Интернет, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент и насколько хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.
Видео-конференц-связь
Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов, чтобы сеансы могли быть связаны.
Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
Понятие о микшерах и трансляторах
Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках
можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.
Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференц-связи с использованием протокола IP (IPM - IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.
Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену.
Протокол управления RTCP
Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.
Протокол управления RTСP (RTCP - Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP. Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.
Главная функция - обеспечение обратной связи для оценки качества распределения данных. Это неотъемлемая функция RTСP как транспортного протокола, она связана с функциями управления потоком и перегрузками других транспортных протоколов. Обратная связь может быть непосредственно полезна для управления адаптивным кодированием, но эксперименты с IP-мультивещанием показали, что обратную связь с получателями также важно иметь для диагностики дефектов при распространении информации. Посылка отчетов обратной связи о приеме данных всем участникам позволяет при наблюдении проблем оценивать, являются они локальными или глобальными. С механизмом распределения IPM для таких объектов, как поставщики услуг сети, можно также получать информацию обратной связи и действовать при диагностике проблем сети как монитор третьей стороны. Эта функция обратной связи обеспечивается отчетами отправителя и приемника RTCP.
RTCP поддерживает устойчивый идентификатор источника данных RTP на транспортном уровне, называемый "каноническим именем" ( CNAME - canonical name). Так как идентификатор SSRC может изменяться, если обнаружен конфликт или перезапущена программа, то получателям для отслеживания каждого участника требуется каноническое имя CNAME. Получатели также требуют CNAME для отображения множества потоков информации от данного участника на множество связанных сеансов RTP, например, при синхронизации звукового и видеосигнала.
Первые две функции требуют, чтобы все участники посылали пакеты RTCP, следовательно, для предоставления возможности масштабирования числа участников протоколом RTP должна регулироваться частота передачи таких пакетов. При посылке каждым участником телеконференции управляющих пакетов всем остальным участникам, каждый может независимо оценивать общее число участников.
Четвертая, дополнительная, функция RTCP должна обеспечивать информацию управления сеансом (например, идентификацию участника), которая будет отражена в интерфейсе пользователя. Наиболее вероятно, что это будет полезным в "свободно управляемых" сеансах, где участники вступают в группу и выходят из нее без контроля принадлежности или согласования параметров.
Функции с первой по третью являются обязательными, когда RTP используется в IP-мультивещании, и рекомендуемыми во всех остальных случаях. Разработчикам приложений RTP предлагается избегать механизмов, работающих только в двустороннем режиме и не масштабируемых для увеличения числа пользователей.
Интенсивность передачи пакетов RTCP
Протокол RTP позволяет приложению автоматически масштабировать представительность сеанса связи в пределах от нескольких участников до нескольких тысяч. Например, в аудиоконференции трафик данных, по существу, является самоограничивающим, потому что только один или два человека могут говорить одновременно, и при групповом распределении скорость передачи данных на любой линии связи остается относительно постоянной, не зависящей от числа участников. Однако трафик управления самоограничивающим не является. Если отчеты приема от каждого участника посылаются с постоянной интенсивностью, то трафик управления с ростом числа участников будет расти линейно. Следовательно, должен быть предусмотрен специальный механизм понижения частоты передачи управляющих пакетов.
Для каждого сеанса предполагается, что трафик данных соответствует агрегированному пределу, называемому полосой пропускания сеанса связи, которая совместно используется всеми участниками. Эта полоса пропускания может быть зарезервирована, и ее предел установлен сетью. Полоса пропускания сеанса не зависит от типа кодирования мультимедийных данных, но выбор типа кодирования может быть ограничен полосой пропускания сеанса связи. Параметр полосы пропускания сеанса, как ожидается, будет обеспечен приложением управления сеанса, когда оно вызовет мультимедийное приложение, но мультимедийные приложения могут также устанавливать значение по умолчанию, основанное на полосе пропускания данных с единственным отправителем для типа кодирования, выбранного для данного сеанса.
Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.
Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов, и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP, должна быть установлена равной 5 %. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP, так, чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.
Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики:
отправители коллективно используют по крайней мере 1/4 полосы пропускания трафика управления так, как в сеансах с большим количеством получателей, но с малым числом отправителей; едва установив соединение, участники в течение короткого интервала времени получают CNAME передающих сайтов;
требуется, чтобы расчетный интервал между пакетами RTCP, как минимум, превышал 5 секунд, чтобы избежать пачек пакетов RTCP, превышающих дозволенную полосу пропускания, когда число участников мало и трафик не сглаживается согласно закону больших чисел;
интервал между пакетами RTCP изменяется случайно в пределах от половины до полутора расчетных интервалов во избежание непреднамеренной синхронизации всех участников. Первый пакет RTCP, посланный после вступления в сеанс связи, также задерживается случайным образом (до половины минимума интервала RTCP) в случае, если приложение начато во множестве сайтов одновременно, например, при объявлении о начале сеанса связи;
для автоматической адаптации к изменениям в объеме передаваемой информации управления вычисляется динамическая оценка среднего размера составного пакета RTCP с использованием всех полученных и посланных пакетов;
этот алгоритм может использоваться для сеансов, в которых передача пакетов допустима для всех участников. В этом случае параметр полосы пропускания сеанса - это произведение полосы пропускания индивидуального отправителя на число участников, и полоса пропускания RTCP составляет 5 % от этой величины.
Взаимодействие RTP с протоколами сетевого и транспортного уровней
Если не установлено иначе спецификациями других протоколов, то при передаче "голосовых" пакетов применяются следующие основные правила.
RTP полагается на протоколы нижележащих уровней при обеспечении разделения потоков данных RTP и управляющей информации RTCP. Для протокола UDP и подобных ему протокол RTP использует четный номер порта, а соответствующий поток RTCP - порт с номером на единицу большим.
Информационные пакеты RTP не содержат никакого поля длины, следовательно, RTP полагается на нижележащий протокол и для обеспечения индикации длины. Максимальная длина пакетов RTP ограничивается только протоколами нижележащих уровней.
В одном блоке данных протокола нижележащего уровня, например, в пакете UDP, могут передаваться несколько пакетов протокола RTP. Это позволяет уменьшить избыточность заголовков и упростить синхронизацию между различными потоками.
