2.3.1.2. Видеотелефонная связь

Видеотелефонная связь имеет требования по задержке схожие с речевым обслуживанием. Вследствие применения сжатия видеоинформации требования к BERздесь более строгие, чем для передачи речи. ВUMTSопределено, что для видеотелефонной связи по соединительным линиям с коммутацией каналов должны использоваться РекомендацииITURec.H324M[4]. В настоящее время имеется два подходящих варианта для систем видеотелефонной связи с коммутацией каналов:ITUIRec.H.323 иIETFSIP.

Рекомендация ITU-T Rec. H.324

Первоначально Рекомендации Rec.H.324 предназначались для мультиме дийной связи по стандартной телефонной сети, т.е.PSTN. Указывается, что для соединенийPSTNиспользуется синхронный модемV.34. Позднее, с развитием

Рис. 2.3. Область применения Rec. H.324

беспроводных сетей, в спецификацию введены добавления, касающиеся подвижной связи, с тем, чтобы сделать систему более устойчивой к ошибкам при передаче. Общий вид системы H.324 показан на рис.2.3.

H.324 состоит из следующих обязательных элементов:H.223 для мультиплексирования иH.245 для управления. Элементами необязательными, но обычно используемыми, являются видеокодекG.723.1 иV.8bis. Позднее в систему в качестве необязательных элементов были добавленыMPEG-4 видео иAMR. Рекомендация определяет семь этапов вызова: установление соединения, только речь, обучение модема, инициализация, сообщение (собственно передача), окончание и очистка (разъединение). Уровень 0 мультиплексированияH.223 точно такой же, как уровень мультиплексирования H.324, тем самым обеспечивается совместимость со старыми терминаламиH.324. При стандартизированной процедуре согласования терминал может приспосабливаться к преобладающим условиям радиолинии путем выбора определенного уровня устойчивости к ошибкам.

V.8bisсодержит процедуры для идентификации и выбора общих режимов работы для оконечного оборудования канала передачи данных (DCE) и оконечного оборудования для передачи данных (DTE) по обычной коммутируемой телефонной сети и арендованным телефонным линиям (каналам) между двумя пунктами. Основные возможности элементаV.8bis:

•  Он позволяет выбирать необходимый режим связи либо вызывающей, либо отвечающей стацией.

•  Он позволяет терминалам автоматически определять общие рабочие режимы (приложения).

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

•  Он обеспечивает удобное для пользователя переключение с обычной речевой телефонной связи на режим связи с использованием модема.

Особенность V.8bis, связанная с обменом возможностями, позволяет производить обмен между терминалами сведениями о режимах связи, а также прикладными программами. Поэтому каждый терминал может устанавливать режимы работы, с помощью которых он будет осуществлять связь с удаленной станцией. Таким образом, обмен возможностями, производимый между станциями, обеспечивает,apriori, что выбранный режим для связи возможен. Таким образом, удается избежать попыток установления несовместимых режимов работы, что ускоряет осуществление соединения на прикладном уровне.

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

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

Чтобы гарантировать бесшовную передачу данных между UMTSиPSTN, механизм управления вызовом системыUMTSдолжен брать в расчет сообщенияV.8bis. СообщенияV.8bisдолжны интерпретироваться и преобразовываться в сообщенияUMTSи наоборот.

Одним из последних усовершенствований H.324 является рабочий режим, который позволяет использовать терминалH.324 на линияхISDN. Этот режим работы определяется в ДополненииDк РекомендацииH.324 и называетсяH.324/1. ТерминалыH.324/1 используют интерфейс пользователь-сетьISDNсерии 1.400 вместо модемаV.34. Выходной сигнал мультиплексораH.223 непосредственно сопрягается с каждым битом цифрового канала в соответствии с порядком, определеннымH.223. Режимы работы определяются скоростями передачи, начиная от 56 Кбит/с и кончая 1920 Кбит/с, так чтоH.324/1 позволяет использовать несколько каналов со скоростью передачи 56 или 64 Кбит/с одновременно.

H.324/1 обеспечивает прямую совместимость с терминаламиH.320, терминаламиH.324 вGSTN(при использовании модемовGSTN), терминаламиH.324, работающими вISDN, при замене пользователями интерфейсовISDNсерии 1.400 на модемыV.34 и с речевыми телефонами (какGSTN, так иISDN). ТерминалыH.324/1 поддерживаютH.324/ДополнениеF(=V.140), которые служат для установления связи между двумя мультипротокольными аудиовизуальными терминалами при передаче цифровых каналов со скоростями, кратными 64 или 56 Кбит/с [5].

Рекомендация ITU-T Rec. 323

В H.323 (см. рис. 2.4) логические каналы мультиплексируются на транспортном уровне по адресам порта назначения. Транспортный адрес представляет собой соединение адреса сети и порта, которое и определяет пункт назначения транспортного уровня, например,IP-адрес и портUDR(протокол пользовательских дейтаграмм), пакеты передаются на транспортном уровне от адреса источника по адресу назначения. Например, каждый логический канал передачи данных, аудио, видеоинформации дляH.245,T.120 иRTCP(протокол поточной передачи в реальном времени) посылается по разным транспортным адресам назначения. Соответственно и пакеты с различными типами информационного наполнения посылаются по различным транспортным адресам, исключая необходимость в отдельном уровне мультиплексирования/демультиплек-сирования вH.225.0. Если получатель соглашается на то, что протокол управленияH.245 будет открывать логический аудио и/или видеоканал, то приемный терминал посылает по каналу управления указание о порте, где бы он хотел получать соответствующий битовый поток. Поток данных будет передаваться в этот порт, как и дейтаграммыUDP[6].

Следует отметить, что существующая в настоящее время спецификация GPRSне поддерживает более одного контекстаPDRна одинIP-адрес. Чтобы в полной мере воспользоваться возможностямиUMTS, должен поддерживаться контекст на уровне порта. Это необходимо для того, чтобы определитьQoSпорта, т.е. пригоден ли выделенный канал доступа для передачи аудио и видеоинформации.

H.225.0 используетRTP/RTCP(транспортный протокол реального времени/управляющий протокол реального времени) для пакетирования мультимедийного потока и синхронизации всех обслуживаемыхLANs. ИспользованиеRTP/RTCPсвязано с использованиемUDP/TCP/IP.

Предполагается, что ошибки в битах определяются на нижних уровнях, и пакеты, содержащие ошибки, не посылаются в H.225.0. ТерминалыH.225 должны позволять осуществление передачи и приема аудио и видеоинформации на отдельные транспортные адреса при использовании отдельных пакетовRTP, чтобы давать номера последовательности фреймов в соответствии со спецификой мультимедиа и разделять трактовкуQoSдля каждой среды передачи.

Рис. 2.4. Область применения Рекомендаций ITU Rec. H.323

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

Установление конференц-связи между двумя пунктами с помощью H.323 требует наличия двух соединенийTCPмежду двумя терминалами: одно для установления вызова, а другое – для управления конференц-связью и обмена возможностями. Первоначальное соединение производится от вызывающего с заранее известным портом на стороне вызываемого. Это соединение переносит сообщения по установлению вызова, определенные вH.225.0, и обычно называется каналомQ.931. Приняв входящий вызов, вызываемый контролирует соединениеTCPна динамическом порте; вызываемый сообщает этому порту о приеме сообщения. Затем вызываемый устанавливает второе соединениеTCPс этим портом. Второе соединение переносит сообщения по управлению конференц-связью, определенные вH.245. Как только устанавливается каналH.245, первое соединение становится ненужным (в среде простой конференц-связи), и может быть разъединено с любого конечного пункта.

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

Мультимедийная архитектура IETE

(Комитета по инженерным проблемам Интернет)

Просматривающиеся в настоящее время перспективы развития видеотелефонной связи IPосновываются главным образом на стандартеITU-TH.323. Однако, он необязательно будет служить лучшим решением для использования в Интернет и в частности в беспроводных линиях из-за его весьма сложной управляющей сигнализации. ВH.323 используется управляющая сигнализацияH.245 и двоичное кодированиеASN.1/PER. Вместо этого,IETE, основной орган по определению стандартов для Интернет, использует текстовые протоколы сигнализации. В настоящее время эти простые стандартыIETEпо конференц-связи и проведенные экспериментыdefactoпривели к выработке представления, которое называется Мультимедийной архитектуройIETE(см. рис. 2.5), охватывающей несколько областей:

•  SIP(протокол инициализации сеансов): протокол сигнализации, подлежащий использованию вместоH.323/H.245

•  SAP(протокол извещения о сеансах): Многоадресный протокол извещений (извещает о аудио/видео сеансах Интернет, например, о поп-концертах, лекциях и т.д.) На нем основан действующий в настоящее время протоколMbone(Многоадресной магистрали)

•  SDP(протокол описания сеансов): Текстовый синтаксис для описания сеансов (вместоASN.1/BERвH.323)

•  RTSP(потоковый протокол реального времени): Протокол для управления удаленными серверами (например, серверамиVOD(предоставления видео по требованию) для воспроизведения элементов файла).

Рис. 2.5. Мультимедийная архитектура IETF

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

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

•  Направленный вызов, переключение телефонного вызова при отсутствии ответа абонента

•  Переключение телефонного вызова в случае занятости линии абонента

•  Безусловный направленный вызов (переключение телефонного вызова)

•  Другие услуги, связанные с трансляцией адреса (переадресацией)

•  Передача номера вызываемого и вызывающего, где номером может служить любая (желательно уникальная) схема наименования (присвоения имен)

•  Персональная мобильность, т.е. возможность вызова абонента по одному, независимому от местоположения адресу, даже в том случае, если пользователь меняет терминалы

•  Согласование и выбор типа терминала.

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

•  Согласование возможностей терминалов

•  Аутентификация вызывающего и вызываемого абонентов

•  Слепая и контролируемая передача вызова

•  Приглашение к многопунктовой конференц-связи (для территориально рассредоточенных пользователей).

Имеются расширения SIP, позволяющие осуществлять независимую сигнализацию, например, для услуг с переключением на связь по телефонным линиям, конференц-связь между узлами и обеспечение соединений с устройствами управления многопунктовой связью (MCUs), а также иметь смешанные режимы работы и возможности перехода с одного на другой.SIPявляется адресно-нейтральным протоколом, где адреса выражаются какURLs(унифицированные указатели ресурсов) различных типов, например, в видеSIP,H.323 или телефонной связи (E.164).SIPне зависит от уровня пакетов и требует только дейтаграммного обслуживания с невысокой надежностью, поскольку он имеет собственный механизм обеспечения надежности [7].

На рис. 2.6 показан один из вариантов видеотелефонов.

Рис. 2.6. Вариант видеотелефона третьего поколения

2.3.2. Класс потокового взаимодействия

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

Чтобы заработал потоковый метод, сторона клиента, принимающего данные, должна обладать способностью собирать данные и посылать их в виде устойчивого потока по прикладной программе, которая производит обработку данных и их преобразование в звук или изображение. Эти потоковые приложения являются весьма асимметричными и поэтому способны выдерживать более длительную задержку, чем симметричные диалоговые системы. Это означает также, что они допускают более высокий джиттер (переменную задержку) при передаче. Джиттер легко сглаживается с помощью буферизации. Видеопродукция Интернет и участвующая в их создании мультимедийная индустрия, взятые вместе, четко подразделяются на две разные по своим задачам области: (1) Передача Webи (2) Обеспечение видеопотока по требованию. Провайдеры передачиWebобычно имеют дело с очень широкой аудиторией, подключающейся к мультимедийному серверу при выборе из большого числа серверов через действующую сеть Интернет, которая в настоящее время является очень медленнодействующей. Услугами по требованию чаще пользуются большие корпорации, которые хотят записать видеоклипы или лекции в память сервера, подключенного к местной Интрасети (внутрикорпоративной сети) с более широкой полосой – эти записи по требованию редко когда используются одновременно более, чем несколькими сотнями людей.

Оба эти применения используют в основе своей схожую технологию сжатия видеоданных, но ширина полосы частот для кодирования, уровень настройки при использовании сетевого протокола, робастность технологии серверов, необходимая серверам широковещательной передачи, отличается от технологии, используемой по требованию в меньших по своим масштабам системах. Это приводит к ситуации, когда несколько крупных компаний, разрабатывающих и реализующих продукцию потокового видео, приспособили свою продукцию для удовлетворения потребностей конечного пользователя в этих двух близких областях. По сути дела, они оптимизировали свою базовую продукцию различным образом: одна из них нацелена на рынок «28,8 КГц» – потока по Интернет, с большой зависимостью от изменений ширины полосы, а другая – на рынок Интрасети (внутрикорпоративной) со скоростями передачи 100-7300 Кбит/с.

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

В заключении можно отметить, что реализация системы воспроизведения у клиента подвижной системы, как представляется, приводит к построению модуля прикладного уровня, который позволяет обрабатывать потоки видео независимо (при независимом соединении и приведении в действие систем воспроизведения) или параллельно с применением браузера, когда услуга активизируется от браузера. Модуль может сопрягаться непосредственно с узловым интерфейсом протоколов сети с коммутацией пакетов для прикладных уровней, наиболее вероятными здесь будут протоколы UDP/IPилиTCP/IP[8].

2.3.3. Класс интерактивного взаимодействия

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

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