Широкое распространение системы компьютерной телефонии получили только после появления аппаратных и программных стандартов.

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

В области КТ стандартные API-интерфейсы появились немногим позже, чем стандартный набор аппаратных средств - в 1993 году. Microsoft совместно с Intel предложила TAPI (Telephony Applications Programming Interface) - стандартный интерфейс прикладного программирования под Windows. Почти одновременно Novell и AT&T представили TSAP1 (Telephone Server Applications Programming Interface) - интерфейс для системы NetWare. Оба эти интерфейса выполняют основную задачу API - обеспечивают программирование приложений КТ без разработки специальных драйверов устройств.

TAPI может работать под Windows 3.1 и 3.11 и входить в качестве составной части в Windows 95. TAPI устанавливается на PC, поэтому вся характерная для КТ-систем обработка входящих и исходящих звонков сосредотачивается именно там. Это означает, что стандарт TAPI предполагает установку на PC всей необходимой аппаратуры КТ. При этом часто отпадает необходимость в использовании традиционных ТА. При работе с TAPI не требуется никаких дополнительных аппаратных или программных средств; каждая PC может иметь свою собственную конфигурацию в соответствии с нуждами своего пользователя. Стандарт TAPI удобен для небольших организаций, где нет сложной информационной и телефонной инфраструктуры.

Большие организации, где имеется разветвленная ЛВС на базе NetWare и используется современная У АТС (цифровая), должны использовать систему, построенную в соответствии со стандартом TSAPI. Этот стандарт предполагает сосредоточение всего компьютерно-телефонного интеллекта на сервере, взаимодействующем с УАТС при помощи виртуальной линии связи. В стандарте используется как бы двойная архитектура клиент-сервер, в которой PC являются клиентами сервера, а телефонные аппараты - клиентами УАТС. Доступ с PC к функциям КТ осуществляется через интеллектуальный сервер, который, в свою очередь, выдает соответствующие команды на АТС.

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

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

Вопрос о том, какой API следует установить в ИС компании, весьма важен, поскольку от выбора API в значительной степени зависит, каким ПО можно будет пользоваться. С другой стороны, выбор интерфейса, как уже говорилось выше, во многом зависит от размера организации. Важную роль при выборе базового стандарта для построения системы играет также предполагаемое назначение системы. Например, если речь идет об организации системы обмена сообщениями для сотрудников, то здесь подойдет TAPI. Если же необходимо построить центр обслуживания телефонных вызовов (например, для заказа товаров по телефону), то в этом случае предпочтительнее использование TSAPI.

Существование нескольких стандартов в одной отрасли не может не сказываться на особенностях применения систем КТИ на ВС, делая несовместимыми отдельные разработанные системы и приложения.

В последнее время сделана попытка объединения данных стандартов.

Появились приложения, способные работать с обоими интерфейсами. В качестве примера такого приложения можно привести программу CallXpress3 Desktop for Windows, разработанную компанией Applied Voice Technologies. Эта программа реализует единую среду обмена сообщениями. При работе в такой среде пользователю предоставляется возможность просмотра сообщений разных типов (факсимильных сообщений, электронных писем и голосовой почты) из одного меню. Ознакомившись с содержанием сообщения, пользователь может немедленно принять решение о форме ответа на это сообщение и тут же отправить ответ (написать письмо или наговорить голосовое сообщение), выбрав телефонный номер или электронный адрес из списка на экране. CallXpress3 предоставляет все эти функции, выполняет работу автосекретаря и осуществляет маршрутизацию входящих звонков в соответствии с набранным номером. Другое приложение, и тоже из области unified messaging (унифицированные системы сообщений), работающее с обоими интерфейсами, - это продукт TeLANophy, предлагаемый компанией Active Voice.

Фирма Microsoft представила версию TAPI для Windows NT. Тем самым, стандарт TAPI избавлен от ориентации на PC и приобретет дополнительную степень гибкости. Фирма Northern Telecom разработала приложение Ттар, которое отображает функции TAPI на набор функций TSAPI. Поэтому приложения, рассчитанные на работу с PC, получили возможность доступа к компьютерно-телефонным ресурсам сервера. Ттар следует устанавливать на всех PC, откуда желательно получить доступ к функциям TSAPI. Надо отметить, что отображение Ттар не является полным - часть функций TAPI не могут быть реализованы в TSAPI. Использование Ттар не отменяет возможности работать под TAPI - приложение может обращаться как к локальным компью-терно-телефонным ресурсам, так и к серверу, где установлен интерфейс TSAPI.

Windows 2000 реализует компании Microsoft последнюю версию TAPI 3.0 с расширенной функциональностью.

Фирма Dialogic разработала продукт CT-Connect. CT-Connect использует в качестве системного ПО Windows NT и обеспечивает обмен информацией между телефонным сервером и приложениями, написанными под TAPI. Имеется TSAPI-версия CT-Connect. Таким образом, оказывается возможным использование TSAPI-приложения в среде Windows NT. Поэтому приложения, разработанные в стандартах TAPI и TSAPI, смогут сосуществовать на одном сервере.

Дальнейшее объединение и выработка единого стандарта, несомненно, помогут решить проблему совместимости телефонных систем, интеллектуальных серверов и программных приложений. Кроме этого, системы альтернативных IP-УАТС должны поддерживать также протокол Н.323, решающий важные вопросы сигнализации при обслуживании вызовов в сети Internet-телефонии.

Рекомендация Н.323, в которой определен набор средств и механизмов для мультимедиакоммуникаций (передача аудио, видео и данных) в пакетных сетях, является на сегодня основным стандартом для IP-телефонии. Она была принята МСЭ-Т в 1996 г. И, хотя группа Интернет IETF разрабатывает несколько альтернативных стандартов, рынок пока ориентируется на Н.323.

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

В целом Н.323 - это целая серия стандартов для поддержки мультимедийных коммуникаций по сетям без обеспечения качества услуг. Он охватывает множество вещей, в том числе спецификации для аудио- и видеокодеков, протоколы установления и управления соединениями, меры обеспечения передачи в РВ, интерфейсы с другими сетями и т.д. Н.323 не привязан к какому-либо конкретному типу сети и протоколу транспортного уровня. Нижележащая сеть может представлять собой Ethernet, Fast Ethernet, Token Ring и др., а транспортным протоколом может быть не обязательно TCP/IP, а, например, IPX. Однако Н.323 нашел применение преимущественно именно в сетях на базе IP. Далее будут иметься в виду именно последние.

Н.323 был первоначально разработан для ЛВС, имеющих стабильную и фиксированную ширину полосы частот, в то время, как Internet имеет переменную ширину полосы частот и значительные времена задержки при передаче информации, что ограничивает возможность использования некоторых элементов Н.323. Одновременно с тем, что Н.323 включает сам множество стандартов, он входит в еще более крупную серию коммуникационных стандартов на видеоконференции для сетей разных типов. Известная как Н.32х (см. табл. 4.4), эта серия включает также уже упомянутый стандарт Н.320 для видеоконференций по сетям ISDN, и аналогичные стандарты Н.321и Н.310 для В-ISDN и ATM, Н.322 для ЛВС, не имеющих качества обеспечения услуг, и Н.324 для ТфОП.

Таблица 4.4. Семейство стандартов Н.32х

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

Вспомогательная серия стандартов Т.120 охватывает конференции данных (совместное использование документов или приложений), а также аудио- и видеоконференции (серия стандартов Н.32х относится только к видеоконференциям, но не к конференциям данных). Большинство видеоконференций предусматривают поддержку разделяемой «грифельной доски» или совместного использования приложений. Поддерживающие стандарты Т. 120 системы конференций, как правило, совместимы друг с другом. Стандарт Т.120 относительно новый, поэтому взаимодействие между продуктами разных производителей не гарантируется, но их совместимость довольно высокая.

Качество видео определяет единый промежуточный формат (Common Intermediate Form, CIF) ITU. Спецификации CIF предусматривают видеоразрешение 288 на 352 пикселов, a QCIF (Quarter CIF) - 144 на 176 пикселов. Большинство доступных систем видеоконференций поддерживают разрешение CIF и/или QCIF.

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

На рис. 4.6 приведен пример взаимоувязанной сети, построенной с учетом использования серии Н.32х. Межсетевое взаимодействие различных Н.32х-сетей определяет рекомендация Н.246 (рис. 4.7).

Рис. 4.6. Пример взаимоувязанной сети: SoHo - Small-office/Home-office; RAS - Remote Access Service; CCS No.7 - Common Channel Signaling System No.7; QSIG - D-Channel signaling protocol at Q reference point for PBX networking

Протокол Н.323 в действительности представляет объединение различных спецификаций, поэтому в него вошли уже известные стандарты: 5 спецификаций, определяющих работу аудиокодеков, 2 стандарта на видеокодеки, 1 стандарт мультиплексирования данных, 3 стандарта сигнализации, а также версия протокола передачи в режиме РВ речевых и видеопакетов. В нем описаны компоненты сети и даны комментарии к применению множества дополнительных рекомендаций, которые все вместе часто называют семейством Н.323. Это семейство представлено на рис. 4.8.

Рис. 4.7. Н.323 и другие сети Н.32х

В семейство стандартов Н.323 входят следующие компоненты.

Н.323. Системы пакетной передачи мультимедийного трафика.

Н.225. Определяет механизмы синхронизации данных и объединения их в пакеты в СКП.

Н.245. Определяет протоколы управления и процедуры передачи сигналов управления ау-дио-видеопотоками.

Н.261. Алгоритм видеокодека, предназначенный для обеспечения обратной совместимости со стандартом Н.320.

Н.263. Новый видеокодек для POTS и СКП.

G.711. Аудио-кодек для голосовой связи в полосе до 3,1 кГц, рассчитан на скорости 43,56 и 64 кбит/с (ИКМ).

G.722. Высококачественный аудиокодек для голосовой связи в полосе до 7 кГц, рассчитан на скорости 43,56 и 64 кбит/с.

G.723, G.723.1. Узкополосный аудиокодек для голосовой связи в полосе до 3,1 кГц, рассчитан на пропускные способности 5,3 и 6,3 кбит/с.

G.728. Аудиокодек для голосовой связи в полосе до 3,1 кГц, рассчитан на пропускную способность 16 кбит/с.

G.729, G.729A. Аудиокодек для голосовой связи в полосе до 3,1 кГц, рассчитан на пропускную способность 8 кбит/с.

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

Н.261, Н.263, МРЕв4. Спецификации для видеокодеков. Н.263 определяет экранные видеоформаты.

Рис. 4.8. Структура семейства Н.323

Н.321. Адаптация видеотелефонных систем Н.320 для широкополосных сред.

Н.322. Видеотелефонные системы в среде ЛВС.

Н.324. Терминал для узкополосной передачи мультимедийного трафика.

Н.310. Терминал для широкополосных систем.

Н.246. Взаимодействие мультимедиа-терминалов серии Н с терминалами традиционной ТфОП.

Н.235. Защита и шифрование для мультимедиа-терминалов серии Н.

Различные спецификации Интернет (RTP, RTCP, IPSec и т.д.).

Н.450. Определяет набор дополнительных видов услуг в сетях Н.323.

Ниже приведено описание основных протоколов стандарта Н.323.

RAS - Registration, Admission Control and Status. Протокол сигнализации (регистрации, подтверждения и состояния) применяется для передачи служебных сообщений между терминалами и привратником. RAS-сообщения служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой полосы пропускания, информирования о состоянии сеанса и его прекращении. RAS не задействуется при отсутствии в зоне привратника.

Q.931. Протокол сигнализации используется для установления и разрыва соединений между двумя терминалами Н.323, а также между терминалом и шлюзом. Служебные сообщения этого протокола передаются поверх TCP.

RTP (RFC 1889). Протокол обеспечивает в IP-сетях доставку адресатам аудио- и видеопотоков в МРВ.

SGCP (Simple Gateway Control Protocol. Протокол, основанный на UDP и рассчитанный на администрирование конечными терминалами и связью между ними.

UDP (User Datagram Protocol). Потокол обеспечивает механизм многоадресной рассылки (IP Multicast) для негарантированной доставки звука и видео определенному числу пользователей. Поверх IP Multicast работает RTP, который создает необходимые условия для нормального воспроизведения полученных потоков на пользовательских терминалах.

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

SDP (Session Description Protocol). Протокол описания конференций для SAP, SIP и RTSP

RTCP (Real -Time Streaming Protocol ) (RFC 1889). Транспортный протокол управления передачей в режиме РВ контролирует реализацию функций RTP, отслеживает качество обслуживания и снабжает соответствующей информацией компоненты, участвующие в конференции.

Спецификации Н.323 основаны на алгоритмах инкапсуляции аудиотрафика, предусмотренных протоколами JP/UDP/RTP, Протокол реального времени RTP (Real-Time Protocalj вяибынает общий механизм поддержки интеграции голоса, видео и данных. В заголовках RTP-пакетов содержатся порядковые, номера и отметки времени, необходимые для восстановления потока сигналов в РМВ. Стандарт Н.323 не обеспечивает гарантированных уровней качества сервиса (QoS), но он определяет, что для передачи управляющей информации используется надежный транспортный протокол TCP.

Из всего многообразия в области алгоритмов кодирования/декодирования наиболее популярен стандарт G.723.1, регламентирующий передачу сжатого цифрового аудиосигнала по телефонным линиям. Он позволяет сжимать 64-кбит/с сигнал до 6,4 или 5,3 кбит/с в зависимости от конфигурации. Однако при этом он дает и самые большие задержки в передаче информации. Спецификация G.729 определяет меньшее сжатие, но за счет усложнения схем кодирования достигается заметное сокращение задержки. Такие же показатели и у кодека G.729A, но при почти вдвое более низком уровне сложности. Малые размеры кадров в алгоритмах G.729 и

G.729A благоприятны с точки зрения уменьшения задержки, но оборачиваются значительными накладными расходами в том случае, когда в пакет помещается только один кадр.¹При этом не следует забывать, что алгоритмы G.729A требуют более широкой полосы пропускания и дополнительной обработки пакетов в связи с повышенным отношением длины заголовка к размеру содержательной части пакета. Таким образом, индивидуальным пользователям, работающим в условиях низкой пропускной способности канала, часть которого занимает передача данных, рекомендуется предпочесть кодек по стандарту G.723A. Корпоративным же пользователям, имеющим прямой доступ к среде Ethernet или линиям El (Т1), предпочтительнее использовать продукты категории G.729A. В табл. 4.5 приведены технические характеристики вышеуказанных кодеков.

Стандарт Н.323 определяет четыре типа элементов сети: 1) терминалы; 2) шлюзы (Gateway); посредник или привратник (Gatekeeper)²; устройства управления конференциями с несколькими участниками (Multipoint Control Unit, MCU).

Типовая структура сети Н.323 приведена на рис. 4.9.

Терминалы Н.323 - (рис. 4.10) это конечные точки сети, с помощью которых пользователи могут взаимодействовать друг с другом в РМВ. Типичные терминалы - пользовательские ПК с ПО аудио- или видеоконференций типа Microsoft NetMeeting; в последнее время их число пополнили

¹Размер- кадра - это длительность сжатого речевого сигнала, помещенного в пакет. Задержка обработки определяется временем выполнения алгоритма кодирования для одного кадра. Превентивная задержка - это та часть размера следующего кадра, которая используется при кодировании текущего кадра в соответствии с условиями корреляции. Фактически односторонняя задержка кодирования складывается из размера кадра, превентивной задержки и задержки обработки. Длина кадра равняется количеству байт в кодированном кадре (не считая заголовков).

²Имеет в технической литературе названия - контроллер зоны, посредник, привратник.

так называемые Internet-телефоны. В обязательном порядке все терминалы должны поддерживать сжатие голосового сигнала по алгоритму G.711, Н.245 - для согласования параметров соединения, Q.931 - для установления и контроля соединения, канал RAS - для взаимодействия с посредником, а также RTP/RTCP - для оптимизации доставки потоков аудио (видео) сигналов. Кроме этого, терминалы могут поддерживать и другие аудиокодеки помимо G.711, а также видеокодеки и конференции документов по протоколу Т. 120.

Таблица 4.5. Характеристики кодеков

Источник: Nortel Networks

Рис. 4.9. Типовая структура сети Н.323

Рис. 4.10. ПК-терминал Н.323

Шлюз является другим элементом архитектуры сети Н.323. Его основная функция (рис. 4.11) состоит в преобразовании форматов и протоколов передачи. Шлюз позволяет связать терминалы

Н.323 с другими, не поддерживающими данный стандарт конечными устройствами, в частности с обычными телефонами классической ТфОП, а также терминальными устройствами КОИ. Он преобразует транспортные протоколы (например, ТБМ в ЮТ). Терминалы передают шлюзам необходимую информацию с помощью протоколов Н.245 и С?.931. Как правило, шлюз состоит из нескольких частей: 1) интерфейс с СКП в виде платы линии Т-1/Е-1 или РШ; 2) сетевая плата, например, ЕШеше! для взаимодействия с другими устройствами Н.323 по ЛС; 3) процессоры ЦОС для сжатия речевого сигнала и подавления пауз; 4) управляющий процессор для координации действий всех остальных компонентов шлюза. Помимо этих аппаратных элементов, шлюзу необходимо иметь соответствующее ПО для выполнения всех своих функций.

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

Рис. 4.11. Структура шлюза сети Н.323

Устройство управления конференцией с несколькими участниками (МС11) необходимо для организации конференций между тремя и более участниками. Этот третий элемент архитектуры Н.323 состоит, в свою очередь, из обязательного контроллера (Multipoint Controller, MC) и одного или более необязательных процессоров (Multipoint Processor, МР). Контроллер обслуживает переговоры между терминалами по выяснению и согласованию возможностей и параметров обработки аудио- и видеосигналов. Он не имеет непосредственного отношения к каким-либо аудио -или видеопотокам. С ними работает процессор. Он микширует, коммутирует и обрабатывает аудио, видео и данные.

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

Четвертый, и наиболее важный элемент любой сети Н.323 - посредник (gatekeeper) (рис. 4.12). Посредник - это приложения, чья функция состоит в преобразовании IP-адресов, контроле доступа и управлении пропускной способностью для других компонентов Н.323, включая шлюзы и конечные точки. Посредник выступает в качестве центра обработки вызовов внутри своей зоны и выполняет важнейшие функции по управлению ими. (Зона определяется как совокупность всех терминалов, шлюзов и MCU под управлением данного устройства). Прежде всего, в его функции входит преобразование псевдонимов (имен) терминалов и шлюзов в IP-адреса (или IPX-адреса в сетях Novell). Следующей функцией является контроль пропускной способности. При задании администратором сети максимально допустимого числа одновременно проводимых конференций в ЛС устройство управления доступом может отказать в открытии дополнительных соединений при достижении заданного значения пропускной способности. Это позволяет ограничить занимаемую конференциями долю пропускной способности сети определенным значением и предоставить, таким образом, оставшуюся ее часть другим приложениям.

Рис. 4.12. Посредник (привратник) сети Н.323

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

Например, привратник может выступать в качестве посредника для всех сигнальных сообщений о вызовах Q.931 между двумя конечными точками. Эта функция была введена в интересах провайдеров услуг для упрощения биллинга. Кроме этого, он может осуществлять авторизацию вызовов, то есть разрешение или блокирование вызова в зависимости от таких критериев, как день недели или время суток, запрошенная услуга, отсутствие пропускной способности и т.п. Это может быть интеллектуальное управление вызовами для контроля за тем, какие терминалы свободны/заняты в данный конкретный момент времени. И, наконец, это управление (но не контроль) пропускной способностью. Привратник может попросить участников конференции снизить потребляемую пропускную способность, если ее не хватает другим конференциям или приложениям.

Таблица 4.6. Функции GATEKEEPER

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

Процедура установления сеанса связи (рис. 4.13) между конечными точками (пользователями) делится на три этапа: 1) регистрация конечного пользователя и прохождение процедур контроля доступа (выполняется привратником); 2) маршрутизация вызова в сети и установление соединения между двумя конечными пользователями или большим их числом; 3) согласование требуемых параметров для передачи информации между двумя конечными пользователями.

Все фазы реализуются при помощи специальных каналов сигнализации, называемых каналами RAS, Q.931 и Н.245. Управление каждым из них осуществляется независимо. Следует отметить, что в отличие от системы сигнализации ОКС №7, используемой на телефонных СКК, в Н.323 сигнализация полностью отделена от каналов передачи пользовательской информации. Это обеспечивает высокую гибкость при обработке вызова и предоставлении различных услуг.

Рис. 4.13. Алгоритм работы привратника при обслуживании вызова в соответствии с Н.323:

1. GRQ - Gatekeeper Discovery, 2. GCF/GRJ - Gatekeeper Confirm/Gatekeeper Reject, 3. RRQ- Registration Request, 4. RCF/RRJ - Registration Confirm/Registration Reject,

5. ARQ- Admission Request, 6. ACF/ARJ, 7. ARQ, 8. ACF/ARJ, 9. BRQ - Bandwidth Request, 10. BCF/BRJ - Bandwidth Confirm/Bandwidth Reject, 11. DRQ - Disengage Request, 12. DCF/DRJ, 13. URQ, 14. UCF/DRJ - Unregister Confirm/Unregister Reject.

После установления соединения и согласования параметров передача и управление потоком мультимедийной информации осуществляются по протоколу ЯТР. Для каждого типа мультимедийного трафика (аудио или видео) используется отдельный логический канал ЯТР. Однако даже для потоков однотипной информации рекомендуется использовать разные логические каналы, в том случае, когда они предъявляют разные требования к качеству обслуживания (например, к полосе пропускания).

Ниже рассмотрен пример установления соединения между терминалами Н.323. Терминалы Т1 и Т2 являются мультимедийными Н.323 - терминалами, соединенными с привратником. (Это условие не исключает возможность установления прямых вызовов).

А. Прохождение заявки на установление соединения (рис. 4.14).

Рис. 4.14. Алгоритм прохождения заявки на установление соединения 1) Т1 посылает устройству управления доступом сообщение ARQ по RAS-каналу и запрашивает разрешение на использование прямого канала сигнализации с Т2.

2) Устройство управления доступом отвечает Т1 сообщением ACF, удовлетворяя заявку.

3) Т1 посылает терминалу Т2 Q-931-сообщение “setup”.

4) Т2 отвечает, посылая Q-931-сообщение “call proceeding”.

5) Т2 регистрируется у устройства управления доступом зоны, отправив ему сообщение ARQ по RASканалу.

6) Устройство управления зоны подтверждает регистрацию Т2 RAS-сообщением ACF.

7) Т2 сообщает Т1 о своей регистрации и таким образом получении разрешения на установление соединения. Передается Q.931-сообщение “alterting”.

8) После окончания установления соединения Т2 сообщает Т1 о завершении процедуры Q.931-сообщением “connect”.

В. Установление соединения по протоколу Н.245 (рис. 4.15).

Рис. 4.15. Алгоритм установления соединения по протоколу Н.245

1) Терминал Т1 посылает терминалу Т2 сообщение “Terminal Capability Set”.

2) Терминал Т2 подтверждает начало сеанса согласования возможностей сообщением “Terminal Capability Set Ack”.

3) Терминал T2 сообщает терминалу Т1 о своих параметрах сообщением “Terminal Capability Set”.

4) Завершается процесс согласования возможностей сообщением T1 “Terminal Capability Set Ack”.

5) T1 сообщением “Open Logical Channel” открывает канал передачи мультимедиа-информации в направлении Т2 (в него входит транспортный адрес RTCP- канала).

6) Сообщением “Open Logical Channel Ask” T2 подтверждает открытие однонаправленного логического канала от Т1 ( сообщение включает также RTP-адрес терминала Т2 и RTCP-адрес, полученный отТ1).

7) Сообщением “Open Logical Channel” Т2 информирует Т1 об открытии мультимедиа-канала в его направлении (В составе сообщения - RTCP-адрес).

8) Сообщением “Open Logical Channel Ask” T1 подтверждает установление однонаправленного логического канала от Т2 (сообщение включает. RTP-адрес терминала Т1 и RTCP-адрес, полученный от Т2). На этом завершается процесс установления двухстороннего соединения.

С. Завершение сеанса связи (рис. 4.16).

Рис. 4.16. Алгоритм завершения сеанса связи 1) Посылая Н.245-сообщение “End Session Command” терминал Т2 является инициирует разъединение.

2) Т1 завершает обмен данными и сообщением “End Session Command” подтверждает разъединение.

3) После отправки Q.931 -сообщения “release complete” Т2 разрывает установленное ранее соединение.

4) Терминалы Т1 и Т2 инициируют свое отключение от привратника зоны RAS-сообщениями DRQ.

5) Оповестив терминалы Т1 и Т2 сообщениями DCF, привратник зоны их отключает.

Специально разработанный для сетей, не гарантирующих QoS, Н.323 предоставляет специальную поддержку, необходимую приложениям РВ. Одним из таких протоколов является протокол передачи в РМВ (RTP) для доставки потокового аудио и видео по Internet.

Известно, что TCP является общепринятым в Internet транспортным уровнем. Однако, несмотря на свою ориентированность на установление соединения, обеспечивающую контроль потоков и упорядоченную доставку, он не имеет средств контроля за задержками. Таким образом, хотя пакеты видеоконференции и не окажутся перемешаны как попало при передаче, принимающая сторона немедленно почувствует любую задержку более нескольких миллисекунд.

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

RTP может быть дополнен протоколом управления трафиком РВ (RTCP) для мониторинга уровня QoS и передачи сеансовой информации между участниками сеанса.

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

При всей полезности RTP - далеко не панацея. Один из способов расширения возможностей RTP состоит в использовании его совместно с протоколом RSVP. Не входя официально в комплект протоколов Н.323, RSVP поддерживается многими приложениями РВ.

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

Блок контроля ресурсов RSVP на каждом узле определяет наличие ресурсов, необходимых для обеспечения запрошенного уровня QoS, а блок контроля доступа проверяет наличие у пользователя права произвести запрошенное резервирование ресурсов. Если какая-либо из этих проверок даст отрицательный результат, то приложение получит сообщение об ошибке. Если обе проверки закончатся положительно, тогда всякому пакету потока будет гарантирован согласованный уровень QoS.

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

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

Необходимо отметить, что протокол RSVP «принят к исполнению» лишь немногими производителями. Кроме того, данный протокол обеспечивает только два уровня приоритета (высокий и низкий), тогда как, скажем, в режиме ATM полосу пропускания можно резервировать на нескольких уровнях. И наконец, протокол RSVP выполняет только резервирование полосы и не гарантирует нужного пути следования пакетов, попавших в сеть. В этом отношении более предпочтительны шлюзовые карты, вставляемые в маршрутизаторы. Они обеспечивают прямой доступ к очереди маршрутизатора и способны помещать исходящие голосовые пакеты в ее начало.

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

Вторая версия Н.323 включила в себя усовершенствование старых и введение новых функций. Эта версия распространена на СПК в целом, в том числе на территориально распределенные. По этой причине были внесены изменения, позволяющие минимизировать время установления сеанса связи при помощи процедуры быстрого соединения. Она обеспечивает передачу параметров Н.245 в запросе на установление соединения и не предусматривает дальнейшее их согласование.

Наиболее значительными из новых функций стали: поддержка качества услуг с помощью RSVP, возможность дублирования привратника на случай его отказа, оповещение шлюзом привратника об имеющихся у него ресурсах, обеспечение защиты, конфиденциальности и целостности информации, быстрое установление соединения. Так, стандарт Н.325 решает вопросы защиты: идентификация сторон, целостность и конфиденциальность информации, а также фиксация факта участия. Процедура Fast Call Setup значительно сокращает начальную задержку передачи информации до того, как участники смогут действительно услышать друг друга.

Вторая версия Н.323 предполагает использование ряда дополнительных видов обслуживания (ДВО) согласно рекомендациям серии Н.450. Так, Н.450.1 описывает протокол сигнализации между двумя компонентами сети, позволяющий предоставлять дополнительные услуги, а Н.450.2 -механизмы услуги трансформации вызова, благодаря чему соединение между двумя терминалами 1 и 2 можно преобразовать в соединение между терминалами 2 и 3. Рекомендация Н.450.3 определяет дополнительную услугу Call Diversion, которая дает возможность переадресовывать вызов в тех случаях, когда вызываемый абонент занят, не отвечает или когда переадресация вызова на другой терминал предварительно запрограммирована.

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

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

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

В третьей версии рекомендаций Н.323 появилось приложение G к Н.225. В нем описан метод взаимодействия административных доменов с помощью объекта, называемого «пограничным элементом» (Border Element). Этот функциональный элемент поддерживает открытый доступ к административному домену с целью доведения вызова до входящего в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи с его узлами.

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

Переменная ширина полосы частот и время задержки, характерные для ЛС, уменьшают полезность некоторых элементов Н.323. По умолчанию звуковым кодеком Н.323, например, является G.711. Однако, ширина полосы частот в 64 кбит/с, требуемая в G.711, чаще всего неприемлема при использовании в Internet, ибо большинство пользователей Internet имеют канал заведомо меньшей ширины. Но, даже в этом случае, многое из стандарта полезно. Тем более, что сам стандарт понимается более широко.

Кроме G.711, Н.323 определяет звуковые кодеки G.722, G.723, G.723.1, MPEG1, G.728,

G.729. Кодеры с низкой шириной полосы частот - G.729 в 8 кбит/с и G.723 в 5,3/6,3 кбит/с - вполне подходят для использования в Internet. В частности, G.723 является одним из нескольких «стандартных» кодеров для Internet-телефонии, особенно после того, как Intel, Microsoft и Netscape объявили о поддержке этого кодера. Основной недостаток G.723 состоит в том, что он весьма сложен. И его применение, как отмечают специалисты фирмы Intel, требует 100 МГц Pentium-процессор в качестве минимального для использования в Internet-телефонии.

В большинстве телефонных сетей мира используется адаптивная разностная импульснокодовая модуляция (ADPCM) с пропускной способностью канала в 32 кбит/с (определяется стандартом G.724). Алгоритм компрессии ADPCM основан на кодировке различия между уровнями сигнала, а также динамической подстройке в зависимости от уровня входного сигнала.

Новый алгоритм компрессии позволяет достичь при передаче голоса со скоростью 8 кбит/с того же уровня качества, что и при передаче с использованием FDPCM со скоростью 32 кбит/с. В основу нового стандарта был положен алгоритм CS-ACELP (Conjugate Structured-Algebraic Code Excited Linear Predictive). CS-ACELP формирует голосовые пакеты по 10 бит каждые 10 мс, основываясь на 80 шаблонах стандартной ИКМ-1 (64 кбит/с). Алгоритм обеспечивает высокое качество передачи голоса при минимальных задержках на процессорах DSP.

Одним из примеров реализации G.729 на практике служит технология Clear Voice компании Micom. Clear Voice упаковывает голосовые фреймы G.729 так, что они вместе со служебной информацией занимают примерно 9 кбит/с арендованной выделенной линии или 10,6 кбит/с подключения Frame Relay. Экономия пропускной способности канала достигается также за счет использования метода подавления пауз: в разговоре по одному каналу паузы заполняются оцифрованным голосовым сигналом или данными из других каналов. Как подтверждают исследования, голосовой трафик на 50-70% состоит из пауз, таким образом требования к средней пропускной способности канала снижаются до 4 кбит/с, поэтому метод подавления пауз весьма эффективен.

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

МСЭ рассматривает предложения о внесении дополнений в стандарт мультимедиасвязи на базе пакетных сетей Н.323. В частности, речь идет о функциях, распространенных в современной телефонии: уведомление о поступлении второго вызова или режим справки. Некоторые компании добиваются включения в Н.323 поддержки мультимедиа-возможностей, основанных на предложенном IETF протоколе Session Initiation Protocol.

Активное участие в составлении спецификаций Н.323 и их внедрении принимало исследовательское подразделение Architecture Labs корпорации Intel. На стандарте Н.323 базируется, например, видеофон Intel Video Phone. И наконец, третья ревизия этого стандарта имеет главную цель - упростить и повысить эффективность Н.323-совместимых продуктов, так как, невзирая на все усилия производителей, внедрение Н.323 шло до сих пор медленным темпом, по мнению основных его разработчиков, отчасти из-за страха перед его сложностью.

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

Реализация средств видеоконференций в КС означает немалые дополнительные технические сложности, решение которых, если конференция организуется по СКК или по выделенным линиям, лежит на операторе связи. Именно спецификация Н.323 Gatekeeper позволяет администраторам ИС регулировать доступ пользователей и управлять пропускной способностью, выделяемой для каждого видеопотока. Данная схема распределения пропускной способности очень важна для любого администратора, в особенности если аудио- и видеопотоки передаются одновременно с другим трафиком. Для сетевого администратора очень важно иметь возможность контроля за загруженностью сети.

Спецификация Н.323 Gateway позволяет устройствам Н.323 взаимодействовать с оборудованием, совместимым с Н.320, и с другими видеоспецификациями ITU. Такая возможность важна для объединения настольных систем с уже инсталлированным в компаниях оборудованием видеоконференций. Шлюз Н.323 становится центральным пунктом взаимодействия сетей различных типов, обеспечивая их прозрачное соединение.

Спецификация Н.323 (MCU) описывает, как можно объединить нескольких пользователей Н.323 в конференцию с более чем двумя конечными пунктами.

Будучи самодостаточной, технология Н.323 больше подходит для КС (интранет) и поставщиков услуг IP-телефонии, для которых Интернет-услуги не являются доминирующими. Реализация Н.323 выгодна корпоративным пользователям, так как позволяет объединить разные сетевые инфраструктуры. Компании получают при этом интегрированные сети для передачи речи и данных, с которыми намного проще работать и эксплуатация которых обойдется им значительно дешевле. Пример подобной интегрированной сети приведен на рис. 4.17.

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

В деловой среде в последнее время большую популярность получают основанные на стандарте Н.323 междугородная и международная телефонная связь. Благодаря эффективной экономической политике (такая междугородная и международная связь обходится дешевле «классической»), и даже несмотря на существенное снижение качества связи, данная услуга постепенно завоевывает рынок, создавая конкуренцию классическим телефонным системам.

Рис. 4.17. Пример интегрированной сети Следует отметить, что реальную экономическую выгоду на деле могут, как правило, получить лишь фирмы и компании, имеющие избыточную пропускную способность собственной корпоративной сети 1Р.

Занимает свою нишу и ЛВС-телефония. Подобно классической АТС, ЛС предоставляет услуги передачи речи, которые активизируются интеллектуальными серверами (ип-РВХ, РС РВХ) или, встроенными в учрежденческие АТС, РС-драйверами, реализованными на базе Windows N1. Обслуживание вызовов в пределах ЛВС обеспечивает ИнС (ип-РВХ). Он создает соединения между пользовательскими ПК и 1Р-телефонами, управляет установлением соединения и разъединяет его в пределах пакетной сети. Соединения с пользователями, находящимися за пределами ЛВС, осуществляются с помощью шлюза Н.323.

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

Следует остановиться и еще на одном протоколе, предложенном IETF для замены некоторых составляющих Н.323. Речь идет о протоколе SIP¹(Session Initialization Protocol - протоколе установления, модификации и окончания мультимедийных сеансов связи), предоставляющем больше возможностей. SIP можно рассматривать в качестве одного из семейства протоколов Н.323, работающих совместно для осуществления вызовов. SIP является протоколом управления и сигнализации уровня приложений. Он служит для организации, модификации и завершения сеансов связи с одним или несколькими абонентами. Это могут быть мультимедийные конференции через Internet, сеансы дистанционного обучения, вызовы пакетной телефонии и распределение мультимедийных сигналов. SIP позволяет устанавливать соединения абонентам и автоматическим устройствам, например, серверам архивации. Протокол может быть использован для инициирования сеансов связи, подключения дополнительных участников к сеансам связи, установленным другими способами, или для осуществления многосторонней связи с помощью MCU.

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

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

В совершенном мире, где все работает как надо, запрос будет доставлен в точку назначения. Вызываемая сторона, принимая вызов, возвращает SIP-отклик с кодом 200. Как и другие ответные коды TCP/IP, код, начинающийся с цифры 2, означает, что все в порядке. Затем инициатор вызова в свою очередь посылает ответное подтверждение вызываемой стороне.

Протокол SIP позволяет устанавливать соединения, используя групповую и индивидуальную адресацию и комбинацию этих видов адресации. Объекты, адресуемые SIP, представлены клиентами на сервере и идентифицируются с помощью SIP URL. Этот указатель состоит из двух частей. Имя узла описывается именем пользователя или телефонным номером. Другая часть является именем домена или 1Р-адресом.

Протокол SIP использует ряд серверов различного назначения. Это сервер, содержащий данные о клиентских агентах SIP (UAS - user agent server), прокси-сервер, серверы перенаправления и регистрации. Это также некий сервер локации, который предоставляет услуги по определению местоположения пользователей и может быть совмещен с SIP сервером.

SIP-сессия состоит из SIP-запроса и соответствующего ответа. Для установления соответствия между запросом и ответом на него существует несколько полей, содержащих идентичные значения при запросе и ответе. Эти поля включают: поле идентификатора вызова, последовательный номер команды, поля адреса получателя и адреса отправителя и поле метки (если это требуется). Заметим, что поля адресов получателя и отправителя идентичны в обоих направлениях. В этом нет ничего необычного, такой метод используется в HDLC (High-Level Data Link Control). Данный подход помогает, используется анализатор протокола для устранения сетевых проблем. Запрос приглашает вызываемую сторону присоединиться к имеющейся конференции или установить двухстороннюю связь. Приглашение включает описание сеанса связи, где перечисляются доступные варианты среды передачи и используемые форматы сигналов. Если вызываемая сторо

¹В соответствии с RFC 2543, протокол SIP разработан в рамках создания архитектуры для передачи мультимедийной информации. В нее входят RSVP (RFC 2205), RTP (RFC 1889), RTSP (RFC 2326), SAP и SDP (RFC 2327). Однако функционирование SIP не зависит ни от одного из этих протоколов.

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

⇐Аппаратное и программное обеспечение коммутационных систем на базе пк | Корпоративные сети связи | Аппаратные и программные решения систем кти⇒