Видеоконференции в сети INTERNET
ость и контроль
соединения, то UDP может отправлять пакеты от одного процесса к другому
без какого либо дополнительного сервиса, за исключением, разве что,
проверки контрольной суммы переданных данных.
Прикладной уровень идентифицирует и устанавливает наличие предполагаемых
партнеров для связи , синхронизирует совместно работающие прикладные
программы , устанавливает соглашения по процедурам устранения ошибок и
управления целостности информации. Кроме того протоколы прикладного уровня
определяют , имеется ли в наличии достаточно ресурсов для предполагаемой
связи. Прикладной уровень также отвечает за то, чтобы информация,
посылаемая из прикладного уровня одной системы была читаемой на прикладном
уровне другой системы. При необходимости он осуществят трансляцию между
множеством форматов представлений путем использования общего формата и
структур данных, а также согласует синтаксис передачи данных для
прикладного уровня. Прикладной уровень устанавливает и завершает сеансы
связи взаимодействия между прикладными задачами , управляет этими
сеансами, синхронизирует диалог между объектами и управляет обменом
информации между ними. Кроме того прикладной уровень предоставляет средства
для отправки информации и уведомления об исключительных ситуациях передачи
данных.
Комплект протоколов Internet включает в себя большое число протоколов
высших уровней, имеющих самые разнообразные применения, в том числе
управление сети, передача файлов, распределенные услуги пользования
файлами, эмуляция терминалов и электронная почта.
Стремительный рост Internet предъявляет новые требования к скорости и
объемам передачи данных. И для того , чтобы удовлетворить все эти запросы,
одного уведомления емкости сети недостаточно , необходимы разумные и
эффективные методы управления трафиком и контролем загруженности линий
передач.
Наиболее широко используемый протокол транспортного уровня - это, как было
описано выше, ТСР. Несмотря на то, что ТСР позволяет поддерживать
множество разнообразных распределенных приложений, он не подходит для
приложения реального времени. Использование ТСР в качестве транспортного
протокола ТСР для этих приложений невозможно по нескольким причинам:
1. Этот протокол позволяет установить соединение только между двумя
конечными точками, следовательно, он не подходит для многоадресной
передачи.
2. ТСР предусматривает повторную передачу потерянных сегментов,
прибывающих, когда приложение реального времени уже их не ждет.
3. ТСР не имеет удобного механизма привязки информации о синхронизации к
сегментам = дополнительное требование приложений реального времени.
Другой широко используемый протокол транспортного уровня - UDP не имеет
части ограничений ТСР, но и он не представляет критической информации о
синхронизации.
Эту задачу и призван решить новый транспортный протокол реального времени -
RTP ( Real-Time Transport Protocol), который гарантирует доставку данных
одному или более адресатам с задержкой в заданных пределах, т.е. данные
могут быть воспроизведены в реальном времени.
Пакеты RTP содержат следующие поля: идентификатор отправителя, указывающий,
кто из участников генерирует данные, отметки о времени генерирования
пакета, чтобы данные могли быть воспроизведены принимающей стороной с
правильными интервалами, информация о порядке передачи, а также информация
о характере содержимого пакета, например, о типе кодировки видеоданных
(MPEG, Indeo и др.). Наличие такой информации позволяет оценить величину
начальной задержки и объема буфера передачи.
Протокол RTP используется только для передачи пользовательских данных -
обычно многоадресной - всем участникам сеанса. Совместно с RTP работает
протокол RTCP (Real-Time Transport Control Protocol). , основная задача
которого состоит в обеспечении управления передачей RTP, RTCP использует
тот же самый базовый транспортный протокол, что и RTP ( обычно UDP), но
другой номер порта.
RTCP выполняет несколько функций:
1. Обеспечение и контроль качества услуг и обратная связь в случае
перегрузки. Так как RTCP-пакеты являются много адресными, все участники
сеанса могут оценить, насколько хороша работа и прием других участников.
Сообщения отправителя позволяют получателям оценить скорость данных и
качества передачи. Сообщения получателей содержат информацию о проблемах,
с которыми они сталкиваются, включая утерю пакетов и избыточную
неравномерность передачи.
Обратная связь с получателями важна также для диагностирования ошибок при
распространении. Анализируя сообщения всех участников сеанса, администратор
сети может определить, касается данная проблема одного участника или носит
общий характер. Если приложение - отправитель приходит к выводу, что
проблема характерна для системы в целом, например, по причине отказа одного
из каналов связи, то оно может увеличить степень сжатия данных за счет
снижения качества или вообще отказаться от передачи видео - это позволяет
передавать данные по соединению низкой емкости.
2. Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое
описание отправителя. Они проставляют больше информации об отправителе
пакетов данных, чем случайным образом выбранный идентификатор источник
синхронизации. Кроме того, они помогают пользователю идентифицировать
потоки, относящиеся к различным сеансам.
3. Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг
и обратной связи с целью управления загруженностью, а также с целью
идентификации отправителю все участники периодически посылают пакеты RTCP.
Частота передачи этих пакетов снижается с ростом числа участников. При
небольшом числе участников один пакет RTCP посылается максимум каждые 5
секунд.
ЛОГИЧЕСКАЯ СТРУКТУРА СЕТЕВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
(ПРОТОКОЛ ОБМЕНА ДАННЫХ)
приложения
Формат UDP-
пакета
Заголовок TCP – пакета ИНТЕРНЕТ
Рис. 3
Таким образом с протоколом сетевого уровня IP (Internet Prortocol)
взаимодействуют два протокола транспортного уровня: TCP и UDP. TCP
(transmission control protocol) обеспечивает надежную связь за счет мощных
средств контроля ошибок при отправке пакетов и повторной отправки пакета в
случае ошибки. UDP (user datagram protocol) такими средствами контроля над
ошибками и повторной отправки пакета не обладает. Настольные системы
видеоконференций, работающие по сетям Internet, используют протокол UDP для
передачи аудио- и видеосигнала. Протокол TCP используется для передачи
данных, таких, например, как данные с "настенной доски" или из разделяемых
прикладных программ. При организации конференций по сетям Internet
возникает одна проблема. Суть конференции в том, чтобы передавать
изображение/голос/данные в общем случае в режиме широкого вещания. Однако
протокол IP подразумевает связь "точка-точка". Чтобы преодолеть это
препятствие, в 1989 г. было предложено расширение IP для поддержки
широковещательных пакетов в Internet — RFC (Request for Comments).
Благодаря RFC появилась возможность проводить конференции в Internet в
режиме "широковещательной магистрали" Multicast Backbone (MBone), что
означает возможность для одного участника конференции в Internet
связываться одновременно с несколькими участниками. В режиме MBone группы
хостов, поддерживающих широковещательный IP, связаны друг с другом по
каналам чистого IP со связью "точка-точка". Данные к хостам группы
передаются через широковещательный маршрутизатор. Это, как правило, рабочая
станция, работающая в системе Unix. Для выбора оптимального пути от
отправителя к получателю широковещательный маршрутизатор использует один из
протоколов: DVMRP (Distance Vector Multicast Routing Protocol), MOSPF
(Multicast Open Shortest Path First), PIM (Protocol Independent Multicast).
Необходимость передачи аудио- и видеоинформации по Internet привела к
созданию нового транспортного протокола RTP (Real-time Transport Protocol).
Его рабочая спецификация была предложена группой AVT (Audio/Video Transport
working group) разработчиков средств передачи аудио/видеоинформации,
входящей в организацию IETF (Internet Engineering Task Force). Протокол RTP
отвечает за очередность, тайминг и качество аудио/видеоинформации,
передаваемой в режиме "точка-точка" или "точка-многоточка". Большинство
разработчиков систем MBone используют в своих системах RTP. Среди них такие
как Communique! (InSoft), InPerson (Silicon Graphics), ShowMe (Sun
Microsystems).
На сегодняшний день системы настольных видеоконференций, разработанные
разными производителями, практически несовместимы друг с другом. Поэтому
возникла острая необходимость создания общепринятых стандартов на эти
системы.
Организация ITU, о которой речь уже шла ранее, является агентством ООН. В
рамках этой организации государственные и частные компании координируют
работы по созданию сетей телекоммуникаций и телекоммуникационных услуг.
Сектор ITU-T занимается разработкой стандартов для систем видеоконференций,
работающих по каналам ISDN. Рекомендация стандарта для систем конференц-
связи H.320, предложенная ITU-T, носит название "Narrow-Ba
| |  скачать работу |
Видеоконференции в сети INTERNET |
