ГЛАВА 4

Форум компьютерной телефонии ECTF

4.1. Проблемы стандартизации компьютерной телефонии

История компьютерной телефонии насчитывает 30 лет: первое известное применение СТ реализовано фирмой IBM в 1969 г. В 1970 г. установлен первый центр телефонного обслуживания, так называемый Call-center, в 1973 г. первый автоматизированный распределитель вызовов ACD (Automatic Call Distributor). Сегодня на рынке сотни фирм предлагают телефонные платы, серверы, генераторы приложений. К сожалению, эти изделия, как правило, взаимно не стыкуются.

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

К телефонному серверу подключается множество устройств:

•  интерактивный автоответчик (IVR, Interactive Voice Response),

•  устройства голосовой почты (Voice Mail),

•  конверторы (шлюзы) текста в речь (Email Voice Gateway),

•  факс-серверы,

• распределители вызовов (ACD, Automatic Call Distributor),        

•  генераторы вызовов по расписанию (Predictive Dialers),

через   локальную   сеть   LAN   телефонный   сервер   и   устройства   СТ общаются в вычислительными средствами):

•  хост-системами (головными вычислительными системами),

•  базами данных,

•  персональными компьютерами.

Отсутствие единых интерфейсов (протоколов) обусловлено в значительной мере тем, что производители РВХ действуют вне поля зрения международных организаций по стандартизации, что отсутствует единый признанный лидер среди фирм - производителей оборудования СТ. До 1995 г. на рынке компьютерной телефонии царил хаос.

Переломный момент в развитии СТ связан с именем Тома Зенисека - менеджера канадской фирмы Nortel Networks. Зенисек -бывший кадровый офицер американской армии в области радиотехнической разведки, затем известный профессор в Канаде, перешел на работу в научный центр Bell Nothern Reserch, где и осознал необходимость стандартизации изделий компьютерной телефонии. В 1995 г. он выступил с инициативой создания ECTF (Enterprise Computei Telephony Forum). Его поддержали коллеги из четырех фирм: Dialogic. Digital, Hewlett Packard, Ericsson. И так они - пять человек - в апреле 1995 г. учредили международную организацию, которая сегодн; объединяет около 100 ведущих фирм мира. Главной задачей форумг ECTF является разработка Соглашений о взаимодействии (Interoperability Agreement).

Цель ECTF состоит в том, чтобы унифицировать аппаратные v программные интерфейсы, последовательно следуя концепции клиент-сервер, достичь того, чтобы продукты различных производителей мопи быть, использованы в любом месте схемы, представленной на рис. 4.2.

Телефонный сервер ECTF через локальную сеть (LAN) имеет доступ к серверу приложений. На рис. 4.2 указаны интерфейсы ECTF:

•    контроля сервисов S.100,

•    фирменные интерфейсы контроля вызова TSAPI и TAPI.

Сервер приложений реализует функции многочисленны  устройств компьютерной телефонии: интерактивного автоответчик; (IVR), голосовой почты, шлюза электронной почты, факс-сервера и др.

Рис. 4.2. Телефонный сервер ECTF, включенный в телефонную сеть общего пользования

В настоящее время в ECTF разработаны следующие Соглашения о взаимодействии:

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

•   Интерфейс контроля вызова (модель вызова) - С. 100.

•   Интерфейс мультимедиа-S. 100.                                                        

•   Интерфейс протокола сервер/клиент- S.200.                 

•   Интерфейс поставщика услуг-S.300.                                      

•   Взаимодействие приложений-А. 100.                       

•   Административные услуги - МЛ 00.

1995 г. стал началом второго поколения компьютерной телефонии: начался этап международной стандартизации продуктов компьютерной телефонии.

4.2. ECTF: год рождения 1995

«Microsoft присоединился к ECTF» - так 27 апреля 1999 г. сообщал web-сайт «www.ectf.org». Это событие является ярким свидетельством зрелости международного форума компьютерной телефонии ECTF (Enterprise Computer Telephony Forum). История ECTF насчитывает менее пяти лет: первое организационное совещание ECTF состоялось в марте 1995 г. В том же году число членов ECTF достигло 35, а сейчас их насчитывается около 100. Членами ECTF среди прочих являются ведущие компании мира: Apple, AT&T, Dialogic, Digital, Ericsson, Fujitsu, Hewlett Packard, Motorola, Nortel Networks, Novell, Siemens и др.

С создания ECTF начинается второе поколение изделий компьютерной телефонии. Путем внедрения единых интерфейсов, называемых Соглашениями о взаимодействии, начинается новый этап межнународной стандартизации в области компьютерной телефонии. Начинается упорядочение бурно растущего рынка аппаратных и программных средств компьютерной телефонии. Заглянем на страницу FAQ (Frequently Asked Questions) web-сайта ECTF с наиболее интересными вопросами о деятельности форума.

Вопрос 1. Кто имеет выгоды от следования соглашениям ECTF о взаимодействии в части аппаратных и программных решений?

Прежде всего это:

•   Поставщики     (провайдеры)     услуг     на     общедоступных     сетях международных телефонных компаний.

•   Крупные     компании,      которые     производят     оборудование     и эксплуатируют такие специализированные службы,  как инфоцентр (Call-center) или унипочту (Unified messaging).

•   Малые    предприятия,    поставляющие,    например,    интерактивные автоответчики и устройства голосовой почты.

Вопрос 2. Назовите наиболее типичные решения, основанные на соглашениях ECTF.

Это новое поколение изделий компьютерной телефонии, которые имеют согласованные интерфейсы в аппаратной и программной части, в том числе:

•   Инфоцентры и автоматические распределители вызовов ACD.

•   Сетевые инфоцентры.

•   Речевая почта,унипочта.                                        

•   Конференцсвязь.                                                      

•   Медиа-шлюз (Media gateway).

•   Факсимильные услуги: серверы, факс-почта, IP-факс.

•   Шлюз 1Р-телефонии.

•   Услуги по упрощенной нумерации (Freephone, Personal Number).

•   Телекоммуникационные расчетные карты.

•   Аудиотекст.

•   Справочные и ремонтные службы телефонных компаний.     

•   Удаленный сервер приложений.

•   Интеллектуальная периферия.

•   Услуги с распознаванием речи.

•   Интерактивные информационные службы.

•   Корпоративные платформы с расширением функций РВХ.

Вопрос 3. Провайдеры телефонных услуг спрашивают: «У меня успешный бизнес на местной телефонной сети. Почему я должен следить за тем, соблюдает ли соглашение ECTF мой поставщик оборудования». Тот же вопрос задает менеджер инфоцентра крупного торгового дома.

Ответ. Поставщик, соблюдающий соглашения ECTF, дает вам:

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

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

•   Масштабируемость. Платы, построенные по стандарту ECTF H.I00, дают  не  блокирующий   коммутатор   на  2048  дуплексных   портов. Следуя и далее архитектуре ECTF для коммутационных систем, вы сможете расширить свою систему до 30 000 портов. При выходе из строя какой-то платы вы её замените без выключения питания всей системы. А при наличии резерва по схеме N+1 вы замените плату без ухудшения пропускной способности системы.

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

Вопрос 4. На кого рассчитана информация на web-сайте www.ectf.org?

Следите за нашим web-сайтом, и вы узнаете имена победителей наших конкурсов на лучшие СТ-продукты и услуги.

Полезные сведения получат:

•   Системные интеграторы.

•   Поставщики оборудования.

•   Поставщики систем «под ключ».

•   Разработчики новых приложений (прикладных программ).

•   Разработчики вспомогательных средств программирования (software toolkit).

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

4.3. Задачи ECTF

Основная цель ECTF. Форум ECTF - это негосударственная бесприбыльная организация по разработке нормативной документации в области компьютерной телефонии (Computer Telephony, CT). Членами ECTF являются организации различного профиля:

•   Поставщики средств компьютерной телефонии.

•   Разработчики.

•   Системные интеграторы.

•   Пользователи.

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

1) контроль телефонного вызова и

2) управление телефонными медиа-ресурсами.

На настоящей начальной фазе работы ECTF имеются в виду следующие медиа-ресурсы:

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

•   Распознавание   и   генерация   многочастотных   сигналов   (сигналов тонального набора/DTMF или двухчастотной сигнализации R2).

•   Автоматическое распознавание речи.

•   Прием и передача факсимильных сообщений (по стандарту ITU T.30).

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

Заметим, что СТ-применения - это прикладные программы, которые обеспечивают обмен информацией, пользуясь телефонными технологиями, т.е. коммутационными средствами и медиа-ресурсами. СТ-применения предоставляют интеллектуальные услуги путем обмена информацией:

•   между индивидуальным пользователем и компьютером или

•   между двумя индивидуальными пользователями (непосредственно или путем перезаписи).

Приведем базовую схему включения телефонного сервера ECTF, которая соответствуют архитектурной концепции ECTF (рис. 4.3): телефонный сервер включен в корпоративную сеть, т.е. УАТС (РВХ,

Public Branch eXchange). Телефонный сервер общается с РВХ по известным интерфейсам компьютерной телефонии: CSTA, TSAP1 и TAPI. В качестве интерфейсов между серверами тоже указаны стандарты, рекомендованные форумом ECTF: S.I00, TSAPI, TAPI.

Будущие задачи ECTF. Разработка общих интерфейсов (соглашений о взаимодействии) для схемы включения телефонного сервера (на рис. 3.1) и является задачей ECTF. При этом имеются в виду не только существующие приложения СТ. На очереди стоят многие новые экономически выгодные применения компьютерной телефонии. Укажем некоторые из них:                                                                          

1)  услуги баз данных для мобильных абонентов:

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

• регистры местоположения мобильных абонентов HLR (Home

Location Register) и VLR (Visitor Location Register),

2)   взаимодействие СТ-приложений:

• медиа-конверсия между СТ-применениями (например, для услуг унипочты),

• взаимодействие между СТ-применениями и другими услугами (не-СТ), например услугами интеллектуальной сети или web-технологиями,

3)  обеспечение безопасности (security):

•   безопасность данных, доступных многим приложениям,

•   предупреждение  злонамеренных действий  в  части  контроля вызова для доступа к СТ-применениям,

•   предупреждение злонамеренного захвата телефонных ресурсов со стороны СТ-применений.

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

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

Рис. 4.3. Телефонный сервер ECTF, включенный В РВХ

4.4. Концепция клиент-сервер

В основу архитектуры ECTF положена современная компьютерная концепция клиент-сервер. Суть построения сети клиент-сервер очень простая: компьютер-сервер обрабатывает информацию и поставляет её компьютеру-клиенту, который размещается на столе пользователя. Последовательно следуя концепции клиент-сервер, создаются прекрасные возможности на рынке компьютерной телефонии. Проиллюстрируем это.

В качестве клиентов выступают настольные системы, которые обращаются к сетевым системным ресурсам: файлам, услугам печати, электронной почты и т.д. Клиентские системы обычно не предоставляют услуги другим клиентам (пользователям). Число клиентов на сети достигает сотни и тысячи.

Сервером называют любую систему, которая через сеть поставляет услуги другим пользователям сети. Обычно на сети имеется более одного сервера.

Невыделенный сервер - система, которая имеет доступ к другим системам и сама доступна другим клиентам и серверам. Другими словами, она выступает как в роли сервера, так и клиента.

Выделенные сервера - те, которые настроены на выполнение специфических функций или приложений. Вот их примеры:

•   Сервер файлов.

•   Сервер принтеров.

•   Сервер базы данных.

•   Сервер электронной почты.                            

•   Интернет-сервер (или web-сервер).

•   Интранет-сервер.

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

1) приложения (прикладные программы) размещаются на телефонном сервере,

2) приложения    размещаются    на    отдельном    сервере    приложений (отдельно от телефонного сервера).

Кроме того, каждый из двух серверов может представлять собой:

1) единый физический и логический узел,

2) многие физические устройства, объединенные в единое логическое устройство с точки зрения приложений,

3) многие физические устройства, представленные в виде нескольких логических устройств с точки зрения приложений.

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

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

Рис. 4.4. Телефонные серверы ECTF, размещенные на отдельных узлах.

Конфигурация 2. Более сложный пример показан на рис. 4.5:

1) применение 2 знает о наличии двух соседних серверов,

2) о вызове, запустившим эти прикладную программу, знают соседние сервера.

Для выполнения программы следует явно установить соединение между этими тремя серверами. Что касается самих соединений, то они могут иметь различную физическую природу: аналоговые линии, цифровые линии ISDN, линии РВХ, межузловые коммутационные шины (например,SCbus).

Конфигурация 3. На рис. 4.6 дан пример логического сервера, размещенного на нескольких физических узлах. Для объединения ресурсов различных физических серверов используется междузловой коммутатор на базе стандартных сетевых технологий, например ТфОП, Интернет, широкополосная сеть WAN. Этим коммутатором управляет некий контроллер коммутации.

4.5. ECTF: соглашения о взаимодействии, архитектурные модули и интерфейсы

Основная схема организации ECTF. Главным органом Форума является годичное собрание членов ECTF (рис. 4.7). На нем выбирается совет директоров ECTF (в составе 9 человек сроком на два года). Совет директоров заседает раз в две недели по конференцсвязи и раз в квартал на очных встречах.

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

Технический комитет ECTF. Обсуждение функций Технического комитете ECTF начнем с ссылки на примечательный документ -рамочное соглашение по архитектуре (Architecture Framework). Этот документ является основным результатом деятельности Архитектурной рабочей группы, которая по своей сути призвана координировать работу остальных пяти рабочих групп ECTF. Ниже мы рассмотрим этот документ подробнее. Заметим только, что в число заданий Архитектурной рабочей группы входит также определение отношений с другими организациями, которые заняты стандартизацией интеллектуальных услуг, предоставляемых на базе телефонного вызова. Прежде всего это:

1)  Форум  интеллектуальных  сетей INF (Intelligent Network Forum), который   активно   ищет   связи   с   ECTF   с   целью   установления соответствий  между  рекомендациями  ITU Q.121x  и  документами ECTF.

2) Интернет-форум IETF (Internet Engineering Task Force) - организация, разрабатывающая документы по сети Интернет, в частности по IP-телефонии.

3) Европейский институт  стандартов в области телекоммуникаций ETSI, в том числе проекты:

•   TIPHON - объединение обычной телефонии и IP- телефонии и

•   CAMEL   -   объединение   интеллектуальных   сетей   IN CS1   и мобильных сетей GSM.

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

Рабочие группы ECTF. Рабочая группа по аппаратным средствам (Hardware, отсюда Н.ххх - сокращение для обозначения документов) разрабатывает аппаратные интерфейсы, определяет размеры плат и т.д. В настоящее время разработаны важнейшие для упорядочения рынка оборудования СТ спецификации Н.100, в которых дается описание шин между оборудованием компьютерной телефонии в форматах ИКМ-передачи и с учетом возможности «горячей» замены плат.

Рабочая группа по контролю вызова (Call Control - отсюда обозначение стандартов С.ххх) разрабатывает унифицированную модель вызова, на основе которой строятся различные услуги (сервисы). Базовыми моделями контроля вызова ECTF выбраны две модели:

•   CSTA (фаза 3, что изложено в документе С.001) и

•   JTAPI (документ С. 100).

Рабочая группа по сервисам (Service, или документы S.xxx), точнее, по интерфейсным функциям серверов описывает стыки между телефонным сервером и приложениями. Отметим важнейший документ S.I00 - спецификацию программного интерфейса для разработчиков приложений СТ в рамках архитектуры клиент-сервер.

Рабочая группа по взаимодействию применений (Application, отсюда сокращение документов А.ххх) прежде всего занимается согласованием различных приложений с учетом протокола S.100.

Рабочая группа по управлению серверами компьютерной телефонии (Management, или документы М.ххх) занимается интерфейсами управления. Рассматриваются пять областей: конфигурация сетей, устранение повреждений, пропускная способность, учет стоимости, безопасность (Security).

Структура телефонного сервера ECTF. Рисунок 4.8 иллюстрирует взаимоотношение между структурой телефонного сервера ECTF и четырьмя группами Соглашений о взаимодействии А, С, Н и S.

В последнее время выделены также административные сервисы (менеджмент, группа соглашений, обозначенных буквой М, интерфейс S.900 переведен в группу М).

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

На рис. 4.8 выделены три типа приложений (см. справа налево):

1) Call Flow Application — приложения, основанные на потоке вызовов,

2) Admin Application - административные приложения,

3)  S.100 application — приложения с использованием интерфейса S.100.

Каждое из трех типов приложений проходит свой путь:

Первый путь (Call Flow Application). Вызов поступает от абонента, включенного через линейный комплект LC (Line Control) непосредственно в модуль контроля вызова (Call Control Module), или от какого-либо абонента сети (Network). После сравнительно сложного взаимодействия «абонент - модуль контроля вызова» некоторая информация появляется в прикладной программе (Call Flow Application). При этом она проходит через два интерфейса: интерфейс провайдера услуг контроля вызова (Call Control SPI)*h API контроля вызова.

Между ними находится некоторое вспомогательное программное обеспечение (Call Control Middleware), функции которого на сегодня еще не определены. Виной тому является неопределенность с упомянутыми двумя интерфейсами:

1.  в качестве нижнего интерфейса на рис. 4.8 указаны интерфейсы CSTA и TSPI,

2.  в качестве верхнего интерфейса указаны TAPI, TSAPI, JTAPI (о них речь пойдет в гл. 5 ниже).

Если поступивший вызов требует медиа-ресурсов, то информация об этом через два упомянутых интерфейса передается в маршрутизатор системных вызовов (System Call Router).

Второй путь (Admin Application) - административные приложения (менеджмент). Этот раздел пока еще не стандартизирован. На рис. 4.8 указан интерфейс S.900 - известный в компьютерных сетях протокол SNMP (Simple Network Management Protocol).

Третий путь (S.100 application). Входящий вызов требует медиа-ресурсов, т.е. вызов является системным. Информация об этом из модуля контроля вызова через маршрутизатор системных вызовов поступает в модуль медиа-ресурсов (System Services Module). Проследим цепочку прохождения вызова медиа-услуг:

•   S.100 Application Programming Interface (S.I00 API).

•   Application Interface Adapter   -   модуль   адаптеров   интерфейса приложений.

•   Транспортный протокол с интерфейсом транспортного протокола S.200.

•   Модули медиа-сервисов (названы четыре сервиса: сеанс (Session), группа (Group), контейнер (Container) и соединение (Connection).

•   Интерфейс провайдеров медиа-услуг S.300.

•   Три медиа-услуги:

•   Play - запись и проигрывание голосового сообщения,

•   ASR - автоматическое распознавание речи,                    

•   Fax - факс-услуги.

•   Контроллер коммутатора SFC (Switch Fabric Controller).

•   Комплект канала для обслуживания вызова (Call Channel).

Сами перечисленные медиа-услуги предоставляются с участием программ-драйверов (Private Drivers) и ресурсов медиа-услуг, точнее: с участием ресурсов сигнальных процессоров DSP (Digital Signal Processor), которые размещены на телефонных платах (обозначены на рисунке как Firmware&Hardware). Коммутацию медиа-ресурсов, каналов и линейных комплектов обеспечивает коммутатор (Switch Fabric Implementation). Это осуществляется через шины, соединяющие телефонные карты.

Упрощенная схема архитектуры ECTF. Чтобы облегчить восприятие общей схемы интерфейсов ECTF на рис. 4.8, напомним, что речь на этом рисунке идет о шести типах модулей архитектуры ECTF:

1.  модули приложений (прикладные программы),

2.  модули адаптеров интерфейса приложений, которые инициируют предоставление медиа-услуг,

3.  модули   медиа-сервисов   -   это   вспомогательное   программное обеспечение, облегчающее предоставление медиа-услуг,

4.  модули драйверов (для доступа к медиа-услугам),

5.  модули телефонных ресурсов (ресурсов медиа-услуг),

6.  модули контроля вызова (услуги РВХ), которые реализованы либо в РВХ, либо в телефонном сервере, если он включает функции РВХ.

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

Рис. 4.9. Упрощенная схема архитектуры ECTF: модули и интерфейсы

4.6. Телефонный сервер ECTF

Задачи телефонного сервера. Телефонный сервер ECTF предоставляет мощные вспомогательные средства (middleware) для единого подхода к программированию разных медиа-услуг, таких, например, как факс-системы или голосовая почта. Это достигается дополнением традиционных средств API системными функциями, реализующими архитектуру клиент-сервер. При наличии системных функций (сервисов предоставления медиа-услуг) конкретное приложение может не заниматься вопросами выбора системного ресурса, необходимого для выполнения задания, или установкой соединения и маршрутизацией телефонного вызова. В телефонном сервере определен также протокол обмена информацией между приложениями и ресурсами телефонной системы, что обеспечивает аппаратную независимость прикладной программы от конкретного оборудования. Конечно, это выполнимо лишь при строгом следовании требованиям интерфейса S.100 на входе в сервер со стороны применений и интерфейса S.300 при выходе к медиа-ресурсам.

Разработка ECTF-сервера преследует две цели: 1) Экономия труда программистов, которые создают новые приложения (прикладные программы),   работая   в   разных   коллективах   програм-мистов.    Это обеспечивает интерфейс S.I00, 2) Обеспечение унифицированного доступа к аппаратным медиа-ресурсам, созданным разными производителями, чему служит интерфейс провайдеров медиа-услуг S.300.

Базовая   конфигурация.   Рисунок   4.10   показывает   базовую   конфигурацию     телефонного     сервера     ECTF.     Он     обеспечивает предоставление всех медиа-услуг, которые необходимы для применений, пользующихся интерфейсов S.100.

Рис. 4.10. Базовая конфигурация телефонного сервера ECTF

Сервер обеспечивает:

•   управление группой/вызовом для предоставления медиа-услуг,

•   сами медиа-услуги, такие, например, как запись или воспроизведение речи,

•   соединение между группой медиа-ресурсов и выходом в сеть.

Интерфейсы контроля канала (TAPI, TSAPI, JTAPI) не входят в состав базового телефонного сервера ЕСТ; эти интерфейсы относятся к функциям РВХ, которые не отражены на рис. 4.10.

Интегральный телефонный сервер. Возможны различные переходные варианты от сравнительно простой схемы (на рис. 4.10) до телефонного сервера, полностью интегрированного с модулем контроля услуг, т.е. с функциями РВХ (рис. 4.11).

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

правильно.

Рис. 4.11. Телефонный сервер ECTF с интеграцией контроля вызова (услуг РВХ)

Маршрутизатор медиа-вызовов обрабатывает вызовы, требующие S.100-применений, и делает это с учетом состояний вызова и плана выбора путей в модуле контроля вызова. Работа S.100-сервера более подробно описана ниже в гл. 6.  

ГЛАВА 5

Интерфейсы контроля вызова

5.1. Введение об интерфейсах ECTF

Официальные документы форума ECTF, разработанные Архитектурной рабочей группой (ECTF Architecture Framework, rev. 1.0,1997), рекомендуют несколько интерфейсов контроля вызова (см. рис.3.1):

1.  на   выходе   из   модуля   контроля   вызова  (или   РВХ)  допускаются интерфейсы TAPI, TSAPI и CSTA,

2.  на входе в сервер приложений допускаются интерфейсы TAPI, TSAPI hS.IOO.

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

С учетом сказанного будем придерживаться следующего плана изложения:

•   кратко рассмотрим интерфейсы TAPI и TSAPI,

•   подробно   обсудим   интерфейс   CSTA,   который   лежит   в   основе документа С.001,

•   дадим представление об этом новом интерфейсе С.001.

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

Вне поля зрения останется интерфейс JTAPI (на базе языка JAVA). Применение JTAPI официально допускается документами ECTF с 1999 г., что зафиксировано:

•   в соглашении С. 100 об использовании JTAPI 1.3 в контроле вызова и

•  в соглашении S.410 об использовании пакета JTAPI 1.3 Media Package

в управлении медиа-ресурсами.

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

Применение языка JAVA, системы JINI и других средств фирмы SUN Microsystems, которые ориентированы на расширение компьютерного мира вплоть до бытовых приборов и самых простых вещей в повседневной жизни, естественно, породит новые услуги, которые будут использовать средства телефонной связи. Деятельность фирмы SUN Microsystems, возможно, откроет принципиально новые горизонты компьютерной телефонии, что составит суть её третьего поколения, но более подробно мы это не рассмотрим.

5.2. О противоборстве интерфейсов TSAPI и TAPI

Уроки неудач TSAPI. В конце 1992 г. произошло историческое событие в области компьютерной телефонии: фирмы Novell и AT&T (сейчас Lucent Technologies) заключили стратегическое соглашение об унификации изделий компьютерной телефонии. Договорись об использовании единого интерфейса TSAPI (Telephony Service API): Novell стал поставлять компьютерные сети с интерфейсом TSAPI, a AT&T (Lucent) начал снабжать тем же интерфейсом свою РВХ Definity. Это открыло широкое поле деятельности для поставщиков услуг: любой разработчик прикладной программы обязан только дописать свой интерфейс API, чтобы сделать её доступной для РВХ, использующей общий интерфейс TSAPI.

Интерфейс TSAPI первоначально был задуман как средство подключения компьютера к телефонной станции в качестве третьего лица, то что сегодня рассматривается как схема инфоцентра: входящий вызов поступает из АТС к телефонному аппарату агента инфоцентра, а из сервера приложений необходимая информация поступает на дисплей его настольного компьютера.

В 1993 г. фирма Novell достигла соглашение с восемью фирмами-производителями РВХ о поддержке интерфейса TSAPI:

Alcatel                   Comdial        GPT                          Mitel

AT&T                   Fujitsu                  Interconnect               SDX.

К сожалению, многие крупные производители РВХ остались в стороне от этого начинания.

В 1994 г. была создана ассоциация Novell Open Telephony Association.  В  то  время  фирма Novell  имела 66%  мирового  рынка программного обеспечения для компьютерных сетей, и можно было надеятся на всеобщее признание интерфейса TSAPI. Но этого не произошло.

Как часто бывает при переходе на новый продукт, с самого начала не было обращено должное внимание на эффективное распространение нововведения в мире. Через год фирма Novell осознала просчет и организовала Центр по внедрению телефонных решений Novell. Задачей Центра было оказание консультаций, обучение и поддержка партнеров Novell. Всплыл и крупный методический просчет: представленная в 1992 г. версия TSAPI базировалась на протоколе, который был ранее разработан в ЕСМА (European Computer Manufacturer Association) и обладал существенным недостатком, а именно: не имел четко определенной модели вызова. Это мешало унификации РВХ: оказалось, что приложения, написанные для одной модели РВХ, скажем для Lucent Definity, не могли быть перенесены на РВХ других производителей, например Nortel Meridian. В начальной версии TSAPI отсутствовали также команды обработки медиа-ресурсов, что пришлось устранять в следующих версиях протокола.

В 1996 г. протокол TSAPI был расширен функциями выхода из сети Novell LAN в сеть TCP/IP, но опять с некоторым запаздыванием по сравнению с деятельностью конкурирующей фирмы Microsoft. Много сил также было потрачено на расширение функций обработки речи и поставку интерактивных автоответчиков IVR (вместе с фирмой Voysys), что отвлекало от генерального направления - массового внедрения TSAPI как стандартного интерфейса «компьютер - телефонная сеть».

В 1996 г. начинание Novell поддерживали 22 фирмы -производители РВХ. Сюда вошла и фирма Nortel, сторонник конкурирующего стандарта TAPI, предложенного фирмой Microsoft в 1993 г. Nortel объявила о своей поддержке TSAPI и разработала конвертор Ттар, который позволяет выполнять программы, написанные для TAPI, в окружении TSAPI.

К сожалению, по мере роста популярности фирмы Microsoft и её сетевого продукта Windows NT уменьшается интерес к TSAPI. Сегодня покупатели склонны приобретать СТ-продукты от тех фирм, которые поставляют серверы с операционными системами Microsoft. Поэтому столь значительным событием для дальнейшей судьбы форума ECTF следует считать упомянутое выше вступление Microsoft в члены ECTF в 1999 г.

Как развивался протокол TAPI. После появления TSAPI в конце 1992 г. Билл Гейтс развернул бурную деятельность, свойственную его хватке  менеджера.  Он  стал  партнером  фирмы  Intel,  которая  к тому времени завершала разработку оригинального протокола для подключения PC к РВХ по абонентской линии. Летом 1993 г. Microsoft и Intel объявили о распространении нового стандарта Microsoft под названием TAPI (Telephony Application Programming Interface) и о его поддержке 40 другими компаниями.

Основная мысль начальной версии протокола TAPI является весьма простой. На рис. 5.1 дана схема размещения PC относительно АТС и телефонного аппарата (PC выступает в роли первого лица, так же как и телефонный аппарат), и протокол TAPI служит основой общения между PC и АТС.

Рис. 5.1. Схема интерфейса TAPI

Рисунок 5.2 показывает, как использовать TAPI: по интерфейсу TAPI можно предложить множество приложений абонентам, которые располагают персональным компьютером. В более поздних версиях интерфейса TAPI его функции расширены: к нему добавлены функции для работы в качества третьего лица (как TSAPI).                                                    

Следует признать, что интерфейс TAPI поначалу не был поддержан в мире. Внедрение началось только после включения TAPI в состав Windows 95, а тем более после включения следующей версии TAPI2 в состав сетевой операционной системы Windows NT в 1996 г. В этой версии реализованы оба варианта подключения PC и РВХ — как по абонентской линии, так и по соединительной линии.

Противоборство интерфейсов TSAPI и TAPI - это всего лишь частный пример, иллюстрирующий сложности, которые стоят перед форумом ECTF в деле стандартизации интерфейсов контроля вызова. Любое решение ECTF неизбежно дает преимущество какой-то частной фирме или группе фирм на рынке телефонного оборудования РВХ.

5.3. Европейский протокол CSTA

Историческая справка. В настоящее время протокол CSTA (Computer Supported Telecommunications Applications) является важнейшим независимым стандартом в концепции ECTF. Этот стандарт разработан при активном участии Европейской ассоциации компьютерной индустрии ЕСМА (European Computer Manufacturer Association). Название "Европейский протокол CSTA" является весьма условным, так как сегодня этот протокол претерпел существенные изменения и стал международным в полном смысле слова.

Работа над протоколом CSTA началась в 1988 г., и его первая версия была завершена в 1992 г. Протокол CSTA внедрили в своих РВХ фирмы Ericsson, Philips и Alcatel. Кое-что из CSTA фирма Novell заимствовала и использовала в протоколе TSAPI. Правда, как позже оказалось, это стало одним из слабых мест TSAPI, так как в качестве основного протокола CSTA выбрана недостаточно продуманная модель телефонного вызова. Причиной этого недостатка послужило противоборство производителей РВХ, которые не желают жесткой стандартизации функций РВХ, в том числе жесткой стандартизации модели вызова. Однако отсутствие жесткой стандартизации модели вызова сильно ограничило возможности предоставления дополнительных (компьютерных) услуг.

В 1995 г. была издана вторая версия протокола CSTA (фаза 2, документы ЕСМА под номерами 217 и 218). В настоящее время эта версия обнародована как текущая рекомендация форума ECTF. Эта же версия CSTA нашла внедрение в работе консорциума CTI Encyclopedia, что в итоге привело к разработке соглашения ECTF по контролю вызова С.001(см. ниже пункт 4.4). Во второй версии CSTA учтены требования работы с медииа-ресурсами:

•   введены функции (сервисы) по привязке данных к вызову,

•   расширена группа функций по обработке речи,

•   введена новая группа функций по обмену данными.

В 1998 г. ассоциация ЕМСА объявила о завершении следующей, третьей версии протокола CSTA (фаза 3), которая пока не включена в документы ECTF.

Примеры применений. Разработчики протокола CSTA имели четкую ориентацию на практические применения. В базовый список были включены следующие применения:

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

•   Телемаркетинг, что рассматривается как одно   из наиболее значимых применений СТ.  Предусмотрено  предоставление развитых средств слежения за состоянием рынка.

•   Исходящие вызовы. Помощь в наборе  номера,  в дозванивании и других действиях абонента.

•   Обработка входящих вызовов. Это применение является наиболее массовым, так как   управление потоков входящих вызовов является основой   многих   применений.   Отдельно   вынесены   требования   к «единому столу сообщений» (Integrated Message Desk). Абонентам предоставлены   широкие   возможности   перенаправления   входящих вызовов, как в случае краткосрочного отсутствия (с расписанием по часам),  так  и   при  длительном  отсутствии   на  работе.   Обработка исходящих    и    входящих    вызовов    предусматривает    интеграцию компьютера и речевой почты с телефонной станцией.

•   Обеспечение вызова спецслужб.                                                          

•   Сбор и распределение данных (через голосовой терминал).

•   Гостиничные применения.

•   Применения в области коммутации сообщений.

Архитектура протокола CSTA. Разработчики протокола CSTA придерживались по возможности существующих стандартов, в частности материалов ISO и ITU, и не создавали новую архитектуру. Протокол CSTA должен быть полностью независим от низлежащих транспортных уровней. Следовательно, запрос и сообщения о состоянии объектов могут пересылаться по любым физическим средам: по проводам, коаксиальному или стекловолоконному кабелю, пользуясь любым протоколом нижнего уровня, будь то Х.25 или IP.

В итоге выбрана следующая архитектура протокола CSTA (табл. 5.1.):

•   основой    функционального    уровня    выбран    принцип    открытой распределенной обработки, • взаимосвязи между одноименными уровнями происходя! по протоколу OSI ROSE (Remote Operation Service Element), - в качестве модели доступа к сети выбраны стандарты ISDN.

Таблица 5.1. Архитектура протокола CSTA

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

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

Нам предстоит выбрать описание двух областей модели телефонного вызова - компьютерную и телефонную.

Таблица 5.2. Компьютерная область модели: объекты и атрибуты

Компьютерная   модель.    Что    «видит»    телефонная    станция? Компьютер со стороны АТС  представлен теми объектами, которыми

АТС может распоряжается. Это привычные всем нам объекты и их атрибуты (табл. 5.2).

Протокол общения между АТС и компьютером основан на обмене информацией в форме запрос/ответ. Компьютер посылает запрос, который, например, содержит команду "make a call" (инициировать вызов). Компьютер прежде всего проверяет обоснованность (допустимость) команды. Используются два типа проверки: семантическая и операционная. Семантическая проверка включает следующее: допустим ли код команды, входят ли её параметры в заданный диапазон параметров, заданы ли все обязательные параметры и многое другое. После успешной семантической проверки коммутатор посылает компьютеру подтверждение в получении команды и приступает к выполнению команды. При успешном исходе АТС отсылает результаты выполнения, при отрицательном — отсылает код ошибки.

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

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

Коммутационная модель вызова (табл. 5.3) содержит три составные части:

•   объекты,

•   состояния, которые могут принимать эти объекты,                      

•   правила изменения состояний объектов.

Таблица 5.3. Коммутационная часть модели вызова: объекты и атрибуты

Заметим, что соединение представляет собой взаимоотношение между вызовом и устройством. Соединение проходит ряд состояний в соответствии с моделью вызова, а вызов представляется суммой этих состояний соединения. К модели вызова мы еще вернемся.

Прежде следует определить допустимые типы устройств. В стандарте CSTA названы следующие шесть типов устройств:

•   распределители вызовов (ACD) и их группы,                             

•   клавиши пультов и группы клавиш,

•   линии и группы линий,

•   агенты (инфоцентров) и их группы,

•   телефонные аппараты и их группы,

•   каналы и группы каналов.

Каждое устройство принадлежит по крайней мере к одному из заданного набора классов устройств:

•   голос,

•   данные,

•   изображение,

•   другое.                                                                                       

Каждое устройство имеет свой идентификатор, CSTA определяет два типа идентификаторов:

•   статический (как номер в списке абонентов),

•   динамический (присваивается на время вызова).

Модель вызова CSTA. Как вызов, так и соединение характеризуются двумя атрибутами: идентификатором и состоянием. На рис. 5.3 приведена упрощенная последовательность состояний вызова. Рисунок иллюстрирует изменения состояний исходящего и входящего терминала (А и В-абонента) под влиянием событий. Заметим, что работа над протоколом CSTA велась под влиянием документов МСЭ в части ISDN, поэтому модель вызова ISDN повлияла на выбор модели вызова CSTA, хотя между ними и нет полного соответствия.

Рисунок 5.4 дает более четкое представление модели соединения CSTA: каждое соединение может иметь семь различных состояний с переходами между ними, обусловленными моделью прохождения вызова. В случае связи между двумя терминалами возможны 49 состояний, а между тремя терминала 343 состояния. Правда, не все состояния возможны, и в терминах телефонии описание диаграммы состояний легко представить, например, из 49 состояний двух терминалов в итоге рассматриваются только 14 состояний, которые называются простыми состояниями вызова (табл. 5.4).

Рис. 5.3. Упрощенная последовательность состояний соединения и вызова по стандарту CSTA

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

Стандартные сервисы CSTA. Речь пойдет о тех услугах, которые могут взаимно оказывать компьютер (сервер) и коммутатор (АТС). В документах ЕСМА эти услуги названы сервисами (services), хотя синонимами при переводе могли бы выступать и другие слова: команда, функция, услуга. В основном запрос на услугу исходит из компьютера, и только в некоторых случаях инициатором услуги является коммутатор.

Таблица 5.5 содержит перечень стандартных сервисов CSTA. Приводим эту таблицу в английском варианте, так как при отсутствии устоявшейся терминологии ее перевод только осложнит понимание. Сервисы CSTA делятся на шесть категорий:

1) Коммутационные функции, другими словами, услуги по обработке вызова в собственном смысле слова. Легко заметить, что эти 20 функций заимствованы из описания работы агента на пульте инфоцентра, и они могут быть выполнены как агентом, так и компьютером.

2)  Определение состояния.   Чтобы  управлять  вызовом,  следует четко фиксировать текущее состояние вызова (snapshot call) или устройства (snapshot device),    начать    слежения    за    объектом    (monitor start), подготовить сообщение о каком-то событии (event report) и т.д. Описание важнейших  сервисов  "monitor start"   и   "monitor stop",   что   в   итоге приводит к сервису "event report" с посылкой "event report message", является   весьма   сложным,   так   как   должно   включать   в   себя   все многообразие услуг    компьютерной телефонии, например управление автоматическим    распределением    вызовов    ACD    или    функциями инфоцентра.   По   замыслу   создателей   протокола   CSTA    механизм мониторов берет на себя функцию триггеров интеллектуальных сетей.

3) Вычислительные   функции.   Протокол   CSTA   построен   на   основе концепции клиент-сервер. Компьютер (сервер приложений) выступает, как правило, в роли клиента,  а коммутационная система (РВХ или телефонный сервер) в роли сервера. Но имеются некоторые отклонения от этого подхода.  Это  касается выбора путей обслуживания  вызова (routing).

4)  Сервисы обработки голосовых сообщений: запись, воспроизведение, синтез и др.

5) Сервисы ввода/вывода. Они предусматривают особенности работы с медиа-ресурсами.

6) Двусторонние сервисы (определение состояния системы и выход из программы "escape").

Завершая описание протокола CSTA, заметим, что он разработан с учетом специфики корпоративных сетей. В нем очень богаты возможности управления вызовом. Но по мере роста рынка компьютерной телефонии, по мере укрепления позиций форума ECTF растут амбиции его членов, появляются желания выхода на рынок сетей общего   пользования   (а   не   только   корпоративных   сетей,   как   было объявлено при создании форума ECTF и что нашло отражение в название форума "Enterprise" - учреждение). Выход на рынок ТфОП может потребовать введения ограничений на допустимые сервисы протокола CSTA в части обработки вызова, так как команды по управлению вызовом могут вызвать сбои на сети (особенно при злонамеренных действиях). Для такой модификации протокола CSTA полезно обратиться к опыту разработки протокола INAP для интеллектуальных сетей, а тем более к опыту создания системы сигнализации SS7.

Пример реализации протокола CSTA. PBX Coral фирмы Tadiran построена с учетом требований протокола CSTA. Система CoraLINK -это комплекс программно-аппаратных средств, который обеспечивает непосредственное соединение между Coral и LAN Ethernet. Услуги, которые могут запрашиваться через систему CoraLINK, и события, сообщения о которых может выдавать Coral, полностью соответствуют требованиям стандарта CSTA.

Примеры функций CSTA, поддерживаемые системой CoraLINK, приведены в табл. 5.6. Аппаратно система выполнена в виде дочерней платы ЦП, содержащей процессор применений и схему сопряжения с Ethernet.

Таблица 5.6. Примеры функции CoraLINK

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

•   для определения текущего состояния любого порта станции,

•   для установления и разъединения соединений,

•   организации конференц-связи трех абонентов,

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

Так, посылая запрос на обслуживание, прикладная программа может попытаться установить соединение между двумя портами, например, от абонентского ТА к соединительной линии, а затем (если попытка оказалась успешной) выдать в Coral команду набрать номер телефона.

5.4. Модель контроля вызова ECTF C.001

Предыстория. В 1997 г. форум ECTF обнародовал спецификации С.001, которые предлагают в качестве стандарта ECTF принять модель контроля вызова из документов консорциума CTI Encyclopedia. Этот консорциум был создан фирмами Apple, IBM, Lucent Technologies, Siemens в 1996 г. В свою очередь модель контроля вызова CTI Encyclopedia имеет три источника:

•   стандарт CSTA,

•   интерфейс TSAPI и                                                           

•   один протокол IBM (Call Path Normalization).

Кроме того, на разработку документа С.001 оказали влияние два обстоятельства: во-первых, необходимость работы с медиа-ресурсами в соответствии с концепцией S.100-сервера (см. ниже гл. 5), во-вторых, появление форума интеллектуальных сетей INF.

Уже в 1995 г. началась острая дискуссия между сторонниками интеллектуальных сетей и компьютерной телефонии, был организован форум INF, в 1998 г. издан основополагающий документ INF "IN-CT Interworking Opportunities" о взаимодействии с форумом ECTF. Несомненно, документы МСЭ по интеллектуальным сетям, разработанные на рубеже 1980 - 1990 гг. (серия рекомендаций Q.120x), имеют достоинства, заслуживающие заимствования. Это и произошло в данном случае: в модели вызова С.001 введено, в частности, понятие триггер, что упрощает предоставление дополнительных услуг, например переадресацию вызова, повторный вызов, обратный вызов и т.п.

Общие требования. Модель контроля вызова ECTF должна решить следующие вопросы:

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

2.  Определение     объектов     коммутационной     области     (например, устройство, агент, вызов), включая их параметры и атрибуты.

3.  Определение вызова, состояний вызова и введение терминологии для точного описания семантики услуг контроля вызова.

4.  Описание сервисов контроля вызова.

5.  Описание потоков сообщений, связанных с сервисами.

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

7.  Поддержка голосовых вызовов и вызовов по передаче данных.

8.  Описание требований соответствия для обеспечения взаимодействия разных реализаций модели контроля вызова.

Любая система компьютерной телефонии содержит две области: коммутационную и компьютерную. Коммутационная область включает в себя коммутатор в собственном смысле слова, а также телефонные ресурсы, включая медиа-ресурсы. Компьютерная область содержит вычислительные ресурсы. Интерфейс служит общению между этими двумя областями.

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

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

•   посылают запросы о сервисе,

•   получают ответы в соответствии с запросом,

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

Каждая из двух областей соответствует какой-то версии модели вызова (как правило, средства компьютерной телефонии построены по нескольким версиям). Для согласования двух областей с их версиями в любом частном случае используется вспомогательное программное обеспечение (middleware). В моделях контроля вызова С.001 нас интересует деятельность коммутационной области. Новизной модели является введение понятия «состояние области». В качестве возможных состояний области названы:

1.  Инициализация.      Это      состояние      указывает,      что      область реинициализируется или производится ее рестарт и она временно неспособна ответить на запросы. После завершения инициализации посылается сообщение о состоянии работоспособности.

2.  Нормальное.

3.  Сообщение потеряно. Это состояние указывает, что запрос сервиса ответ или сообщение о событии могут быть потеряны.

4.  Состояние предперегрузки.

5.  Перегрузка достигнута.

6.  Перегрузка устранена и возможна нормальная работа.

Коммутационные устройства. Коммутационные устройства (или просто устройства) - это разные типы точек внешнего доступа, через которые абонент может получить телефонные услуги. Устройством может быть телефонный аппарат, многолинейный аппарат офиса или такой сложный объект, как автоматический распределитель вызовов ACD.

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

Физический элемент характеризуется набором свойств, которые доступны пользователю в качестве интерфейса. Это, например, тастатурная кнопка на аппарате или воображаемая кнопка в прикладной программе. В качестве компонентов физического элемента в С.001 названы шесть объектов: аудио-аппараты (с атрибутами: тип, идентификатор, микрофон, громкоговоритель и др.), переключатель, тастатурная кнопка, звонок, дисплей. Подробно расписаны атрибуты физических элементов (имена, параметры), их всего 17.

Логические элементы. Это набор интерфейсов устройств, которые используются для слежения за вызовом, для контроля путей передачи медиа-потоков и связаны с обработкой сигналов, которые относятся к вызову. Список атрибутов логических элементов содержит 32 названия, введены еще 6 типов связей между ними, что важно при описании медиа-услуг (английское название «appearance» нами здесь переведено как «связь», может быть лучше — «проявление»).

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

1) телефонный аппарат,

2) точка доступа сети (основа систем коммутации),

3) автоматический распределитель вызовов ACD. С устройством ACD ассоциируется понятие «агент» (оператор, работающий с ACD),

4) группа ACD,

5) группа искания (hunt group) - частный случай группы ACD,

6) группа   перехвата  (pick group)  —  относится   к   коммутации   точек доступа,

7) устройство парковки (ожидания).

Медиа-доступ. Медиа-поток - это объект, который передает данные между устройствами, связанными с вызовом. Медиа-поток контролирует так называемые устройства медиа-доступа (Media Access Device). Введены 16 типов медиа-услуг, в том числе:

•   Задержанный живой звук - аналоговый, что означает - живой звук получен   по   каналу   медиа-потока   и   доставлен   по   аналоговому звуковому каналу.

•   Модем   данных   -   подключение   модема   к   передаче/получению асинхронных данных.

•   Медиа-услуги    по    стандарту    S.100    -    это    пять    типов    услуг (запись/передача      звука,      распознавание      речи,      факс-услуги, обнаружение/генерация сигналов).   

Соединение. Рисунок 5.5 иллюстрирует четыре вновь вводимых понятия:

•   вызов,

•   соединение,

•   устройство медиа-доступа и

•   подключение медиа.

Рис. 5.5. Взаимоотношения объектов в модели контроля вызова

Соединение — это отношение между устройством и вызовом. Его идентификатор обычно состоит из пары идентификаторов: устройства и вызова. Совокупность состояний соединения и переходов между ними образует модель соединения, она является графом с семью состояниями (рис. 5.6). Переходы между состояниями происходят по мере выполнения операций (над устройством и вызовом) в соответствии с моделью контроля вызова.

Поясним телефонную суть состояний:

•   вызывной   звонок.    Различают   четыре   типа    вызывного    звонка: входящий (состояние до звонка) или звонящий, звонок в устройстве распределения     вызовов     ACD     (вызывной     звонок    отражается соответствующим событием);

•   соединение;

•   сбой (включая «вызываемое устройство занято»);

•   удержание. Логическое участие в соединении, физическое участие приостановлено;

•   инициализация.  Соединение покидает это состояние после набора номера, срыва набора или сбоя;

•   нулевое - отсутствует отношение между вызовом и соединением;

•   в ожидании - вызов приостановлен, например вызов запаркован в устройстве, вызов ожидает освобождение агента в ACD.

Коммутационная область может иметь более «богатую» модель вызова. Тогда рассматриваемая модель (рис. 5.6) является ее подграфом.

Рис. 5.6. Модель состояний соединения по спецификации С.001

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

Сервисы С.001. Их намного больше, чем в первоисточнике -стандарте CSTA, который был рассмотрен выше. Сервис - это взаимодействие типа «запрос - ответ» между компьютерной и коммутационной областями с целью контроля процесса обслуживания вызова. Вызов может быть инициирован любой из двух областей, хотя в большинстве случаев инициатором выступает компьютерная область (прикладная программа).

Определение сервиса должно содержать следующую информацию:

•   Инициатор сервиса.

•   Состояние  объектов до  и  после  предоставления  всех  участников сервиса (устройства, элементы, соединения, вызовы, агенты).

•   Параметры (обязательные и по выбору).

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

•   Последовательность событий слежения за вызовом.

•   Критерий завершения сервиса.

•   Ответ, т.е. спецификации возвращаемой информации.

•   Потоки    информации:    спецификации     наблюдаемых    последовательностей запросов, ответов, событий и изменений состояний.

Описание сервисов, событий и потоков является слишком объемным, чтобы могли быть воспроизведены в настоящем документе. Перечислим отдельные категории (группы) сервисов:

•   рапорты о состоянии системы. Их всего 12;

•   сервисы контроля вызова - 25, включая: принять вызов, ответить, очистить, удерживать и т.д.;

•   сервисы дополнительных свойств вызова — 9: генерировать цифры, генерировать тоны, собрать цифры частотного набора и т.д.;

•   сервисы выбора пути;

•   сервисы физических свойств (изменение их состояний и параметров, таких, как - нажать кнопку, включить лампочку и т.д.);

•  сервисы логических свойств.

Сервисы сопровождаются событиями, т.е. сообщениями об изменении состояний. Запросы сервисов, ответы на запросы и рапорты о событиях образуют потоки сообщений.

Мониторы. Это важное понятие, веденное для построения дополнительных услуг (в интеллектуальных сетях роль мониторов в какой-то мере выполняет механизм триггеров). Монитор - это объект, который получает подтверждение об изменениях  в коммутационной области и посылает рапорт о событии в компьютерную область. Монитор устанавливается над устройством или вызовом по команде (по сервису) Monitor Start.   Фильтр   монитора   отбирает   рапортуемые   сообщения.

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

5.5. Протокол TAPI фирмы Microsoft

Область применения. Еще раз возвратимся к протоколу TAPI и обсудим его спецификации. Протокол TAPI (Telephone Applications Programming Interface) работает в операционной среде Windows фирмы Microsoft. По замыслу его разработчиков протокол TAPI должен охватывать следующие применения:

•   Унифицированная обработка сообщений - единая система для приема, архивирования  и  ответа  на  голосовые,  текстовые,  графические  и видеосообщения.

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

•   Продвинутый менеджер вызовов — управление вызовами посредством Windows.

•   Передача данных под управлением пиктограмм - копирование через LAN, WAN, ISDN-линии, выбор средств для e-mail или fax.

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

•   Информационные услуги - доступ в реальном масштабе времени к файлам новостей, биржевой информации и т.д.

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

Объекты TAPI. В TAPI рассматриваются два типа периферийных устройств:

1) Линейные устройства - это факс-карта, модем, ISDN-карта или карта обработки  голоса,  которые физически  подключены  к телефонной линии и могут входить в состав компьютера. TAPI предполагает выполнение всех требований к базовому телефонному вызову. Перед тем как некоторое приложение воспользуется линейным устройством, его  следует  открыть  (наподобие  тому,   как  открывается  файл)  и определить атрибуты линейного устройства.

2)  Телефонные устройства - микрофоны и громкоговорители. Их можно рассматривать как частный случай линейных устройств.

3) Третьим объектом TAPI является вызов. Вызовы - это динамические объекты, которые создаются на время выполнения приложений и разрушаются после. Вызов имеет множество атрибутов: тип транспортного канала, например голос или факс; полоса пропускания, например 9600 или 2400 бод в случае факса; источник вызова; идентификатор вызывающего абонента; идентификатор вызываемого абонента; идентификатор соединения (не обязательно совпадает с идентификатором вызываемого абонента).

Для     типичного     вызова     следует     выполнить     следующую

последовательность шагов:

1.  Определить среду передачи, например голос или данные.

2.  Инициализировать TAPI посредством функции linelnitialize.           

3.  Открыть линию посредством функции ПпеОреп.                

4.  Произвести вызов посредством функции lineMakeCall.       

5.  Послать данные (или голос).                                             

6.  Конец вызова.

Уже первая версия протокола TAPI (1993 г.) обладала широким набором функций, в том числе имела 26 функций для телефонного аппарата и 60 функций для линии. В 1996 г. фирма Microsoft вышла на рынок с новой версией TAPI, которая:

•    поддерживает  16-битовые  и  32-битовые  применения,  а главное -работает в конфигурации клиент-сервер;

•   включает новые типы устройств, в том числе дозвон по заданному списку, управление очередью;

•   обеспечивает фильтрацию вызовов;

•   централизованное управление тайм-аутами и многое другое.

Годом позже, в 1997 г. вышла версия TAPI3, которая в настоящее время документами ECTF рекомендуется в качестве международного протокола контроля вызова. Версия TAPI3 имеет следующие улучшения:

•   Использован объектно-ориентированный подход, что позволяет любой прикладной программе пользоваться услугами TAPI3 независимо от того, на каком языке она написана.

•   Включены функции 1Р-телефонии.

•   Расширены функции работы с медиа-ресурсами.

Продолжая агрессивную политику освоения рынка компьютерной телефонии, фирма Microsoft предложила два новых продукта:

•   MAPI(Messaging API) - протокол для систем электронной почты и

•   SAPI (Speech API) - протокол для распознавания и синтеза речи.

5.6. Пример реализации CSTA: Dialogic CT Connect

СТ Connect - это система программ, которая облегчает доступ к сервисам контроля вызова в телефонной системе. В качестве телефонной системы могут быть:

•   Традиционные РВХ.                                                

•   Автоматические распределители вызовов ACD.         

•   РС-РВХ (т.е. РВХ на базе PC).

•   Коммутаторы ТфОП.

•   Коммутаторы IP-телефонии.              

•   Интегрированные СТ-серверы.            

Система СТ Connect построена в 'Соответствии с требованиями протокола CSTA и работает на базе сетевых операционных систем Windows NT или SUN Solaris (рис. 5.7.)    

Рис. 5.7. Схема включения СТ Connect

Стандартная версия СТ Connect V3.0 поддерживает, в частности, две популярные телефонные системы, в которых реализована модель вызова CSTA:

1) Meridian  1   фирмы Nortel, укомплектованную протоколом Meridian Link,

2) Definity G3 фирмы Lucent Technologies с протоколом CallVisor.

Dialogic поставляет также специальные версии СТ Connect. В итоге СТ Connect может работать с большинством известных РВХ.

Рисунок 5.8 показывает одну из возможных конфигураций включения СТ Connect. Каждый пользователь имеет настольный компьютер или сетевой терминал, в котором установлен клиентский модуль системы СТ Connect. Применение отслеживается по телефону пользователя. При поступлении вызова компьютер запрашивает данные об абоненте из базы данных и высвечивает их на дисплее. Новые применения легко построить на основе общедоступных средств Visual Basic фирмы Microsoft или Power Builder фирмы Sybase.

Рис. 5.8. СТ Connect в конфигурации инфоцентра

Пакет "CSTA Switch Simulator" помогает разрабатывать и тестировать новые применения, так как содержит коммутационные функции в соответствии с протоколом CSTA (фаза 2), в том числе:

•    стандартные телефонные соединения,

•    очереди в ACD,

•    действия агентов,

•    цифровые и аналоговые каналы,                   

•    функции маршрутизации каналов.

Приобретая компоненты системы СТ Connect, разработчик прикладных программ легко добавит новые телефонные свойства, новые услуги к имеющейся платформе компьютерной телефонии. Заказчику не потребуется покупать новую дорогую систему «под ключ», а только новую версию программного обеспечения уже существующей системы.

ГЛАВА 6

Предоставление медиа-услуг

6.1. Общая схема СТ-сервера

Начнем с упрощенной схемы сервера компьютерной телефонии или, сокращенно, СТ-сервера (рис. 6.1). Суть его состоит в решении двух основных задач компьютерной телефонии:

1)   контроля вызова и

2)  управления медиа-услугами.    

Рис.6.1. Общая схема СТ-сервера, включающая коммутационные и медиа-ресурсы

В конструкции СТ-сервера обе эти задачи объединены в одном сервере. Будет ли в будущем задача контроля вызова (что мы рассматривали выше в гл. 5) выделена в отдельный сервер, зависит, в частности, от успехов деятельности форума ECTF.

СТ-сервер объединяет все СТ-решения в единый общий сервер и служит основой для построения инфраструктуры связи современного предприятия (по замыслу форума ECTF). Приложения (прикладные программы) запрашивают нужные медиа-ресурсы и ресурсы контроля вызова для обслуживания поступившего вызова. На рис. 6.1 явно выделяются три функциональных уровня общей архитектурной схемы компьютерной телефонии:

1)   приложения (прикладные программы), что соответствует клиентскому уровню,

2)   программное обеспечение СТ-сервера, которое реализует системные сервисы обслуживания вызова и управление телефонными ресурсами,

3)  телефонные ресурсы медиа-обработки и коммутации. В качестве сети можно представлять как традиционную ИКМ-сеть, так и Интернет или что-либо другое.

В настоящее время эта общая схема (рис. 6.1) еще полностью не реализована. Наиболее близким прототипом является сервер Dialogic CT Media, который ниже обсудим более детально. На рынке существует и, видимо, еще долго будет существовать множество РВХ со своими оригинальными протоколами контроля вызова. Как правило, в учреждении установлена своя РВХ, вложены немалые средства для построения инфраструктуры учреждения, поэтому более реально обсуждать несколько видоизмененную схему СТ-сервера (рис. 6.2), где явно выделена телефонная станция РВХ со своим протоколом контроля вызова. В этом случае СТ-сервер включает достаточно большой набор протоколов контроля вызова (TAPI, CSTA, C.001), чтобы без существенных изменений подключаться к существующим РВХ.

6.2. S.100-сервер: основные понятия

Базовая архитектура ECTF. Документ ECTF S.100 представляет собой соглашение о взаимодействии между разработчиками приложений и производителями серверов. Нам предстоит разобраться в сложной схеме предоставления медиа-услуг, которая приведена на рис. 6.3. Точнее, предстоит разобраться в работе S.lOO-сервера, являющего собой промежуточное программное обеспечение (middleware) между медиа-приложениями (прикладными программами), что наверху рисунка, и аппаратными средствами медиа-ресурсов (внизу рисунка), которые через коммутатор сервера (самый нижний блок рисунка) имеют доступ к телефонной сети.

Следует признать, что это довольно сложная схема. Напоминаем, что система компьютерной телефонии состоит из двух частей:

1) контроля вызова и

2) медиа-обработки.

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

По существу нам следует разобраться в работе трех блоков, выделенных (затемненных) на рис. 6.3:

Первый блок состоит из двух частей: интерфейса «S.100 API» (интерфейс между медиа-приложениями) и адаптера этого интерфейса AIA (Application Interface Adapter). По существу это два неразрывно связанных объекта, как станет ясно ниже при анализе выполнения медиа-приложений.

Рис.  6.3.  Базовая  архитейурй'' ЁСТР:  выделены  блоки,  участвующие в работе S.lOO-сервера   

Второй блок представляет собой основное нововведение «S.lOO-cepeep», это сложный программный комплекс, который обеспечивает четыре системных сервиса для работы с медиа-ресурсами:

1) сеанс,

2) группа,

3)  контейнер и                                                         :           :

4) соединение.

Третий блок - «маршрутизатор медиа-вызовов SCR» (System Call Router). Он стоит поотдаль от схемы медиа-сервера. SCR - это связующее звено между двумя частями системы компьютерной телефонии -контролем вызова и медиа-обработкой. SCR вступает в работу, когда поступивший вызов требует предоставления медиа-ресурсов.

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

•   Записывающей и воспроизводящей речевой аппаратуры.

•   Детекторов и генераторов многочастотных сигналов DTMF.

•   Автоматического распознавания речи и конверторов текст-речь.        

•   Факс-аппаратуры по стандартам Т.ЗО и Т.611,                                     

•   Телефонной сети.

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

Клиент взаимодействует с сервером посредством S.lOO-команд, записанных в виде функций языка С. Адаптер AIA конвертирует команды в сообщения и посылает их к серверу, который предпринимает соответствующие действия и возвращает сообщения о событиях (или, короче, события). Адаптер AIA хранит это сообщение в буфере событий до подтверждения ее получения клиентской прикладной программой.

Сервер в свою очередь в соответствии с командой клиента (проходя через интерфейс провайдера услуг S.300) запрашивает нужные медиа-устройства, соединяет их и подключается к телефонной сети. Для выхода на линию телефонной сети используется блок «контроль линии» и соответствующий интерфейс контроля линии, а само общение с телефонной сетью проходит под управлением системного сервиса «маршрутизатор медиа-вызовов».

Пример. При первом чтении изложенная схема предоставления медиа-услуг (рис. 6.1) выглядит отпугивающей. В ней слишком много новых понятий. Для облегчения ее восприятия воспользуемся простым частным примером - схемой шлюза IP-телефонии, предложенной в 1996 г. фирмой VocalTec (рис. 6.4). Шлюз состоит из четырех плат, в том числе двух компьютерных плат:

1) материнской платы персонального компьютера и

2) сетевой    платы    персонального    компьютера    выхода    на    IP-сеть и двух СТ-плат от фирмы Dialogic:

3) телефонной   платы,   которая   преобразовывает  аналоговые   речевые

сигналы и служебные сигналы в цифровую последовательность 64 Кбит/с по стандарту ИКМ-системы,

4) платы  аудио  ресурсов  на  сигнальных   процессорах  DSP,   которая

производит сжатие  цифровой  последовательности до  потока   144 Кбит/с и организует пакеты сети Интернет. Платы объединяются вместе двумя системами шин:

•   системной шиной компьютера и

•   шиной СТ-ресурсов, в данном случае шиной SCbus, которая выступает

в роли коммутатора.

Рис. 6.4. Шлюз (gateway) IP-телефонии фирмы VocalTec (1996)

Сравним оба рисунка: рис. 6.3 и 6.4. Прикладные программы в обоих случаях находятся в компьютере. В обоих случаях имеются две системы шин. Имеются телефонные ресурсы общения с телефонной сетью и DSP-ресурсы обработки медиа-потоков. Главное отличие обеих схем состоит в том, что между прикладными программами и их аппаратным исполнением лежат мощные программные ресурсы (middleware) и многие интерфейсы, что обеспечивает независимость двух групп разработчиков:

1) разработчиков приложений (прикладных программ) для медиа-услуг и

2) разработчиков  аппаратуры  для   стыковки   медиа-ресурсов  с  сетью

связи.

В обеих группах разработчиков основные затраты ложатся на оплату труда программистов. Приложения компьютерной телефонии (прикладные программы для медиа-услуг) пишутся на языке высокого уровня независимо от программ обработки медиа-протоколов в аппаратных платах, где также суть работы состоит в программировании сигнальных процессов DSP. Обеспечение независимости работы этих двух групп программистов порождает необходимость промежуточного слоя программ, что в данном случае и называется S.lOO-сервером.

6.3. Взаимодействие медиа-приложений с сервером

Нам предстоит разобраться в организации сеанса между клиентом (медиа-приложением) и сервером, что представлено на рис. 6.5. Начнем с важнейшего сервиса S.100- сервера, а именно с сеанса.

Сеанс (session) - это временное объединение между клиентом (точнее, некоторым клиентским приложением) и сервером, на стороне клиента условия этого временного объединения фиксируются в адаптере прикладного интерфейса AIA (Application Interface Adapter), и через адаптер AIA осуществляются все взаимодействия клиента с сервером.

Сеанс создается клиентом перед началом взаимодействия с сервером, и создание сеанса начинается с того, что адаптер AIA вручает клиенту название сеанса (session handle), которое потом используется при обращении к серверу. После установления сеанса клиент посылает серверу команду, на что может получить ответ, так называемое событие завершения. Эта пара «команда/событие завершения» называется транзакцией. Сервер может посылать также сообщения о событиях без связи с конкретной транзакцией, например, это может быть вызвано каким-либо объектом, которым управляет сервер, или другим клиентом.

Когда клиент посылает команду к серверу, то задействуется некоторая функция S. 100-сервера, точнее, функция на языке С. Команда имеет вид CTxxx_Create ( ). Эта команда превращается в поток сообщений и поступает к серверу. Сервер предпринимает соответствующие Действия и возвращает ответ в виде сообщения о событиях. В AIA формируется очередь событий, которая разгружается по мере передачи этих сообщений клиентам (приложениям).

На рис. 6.5 указан также поток информации от сервера вниз к ресурсам. Этот поток назван «оплаченной нагрузкой», так как суть Деятельности ресурсов составляют действия, фиксируемые в счете к оплате. На основе взаимодействия клиент-сервер реализуются две модели клиентских применений: синхронные и асинхронные.

Рис. 6.5. Схема организации сеанса между клиентом и сервером

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

Кроме того, клиент может:

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

событий  в AIA  и  срабатывает,  как только  выполнены  заданные критерии оценки событий,

•   установить несколько таких диспетчеров,

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

Завершая описание сеанса, перечислим функции адаптера AIA относительно сеанса:

•   Управление   контекстной   информацией   о   клиенте,   чтобы   многие

клиенты могли использовать сервер независимо.

•   Выбор параметров сеанса (с учетом параметров группы, ресурса или

другого объекта сервера).

•   Управление очередью событий, поступающих от сервера или других

клиентов к данному клиенту.

•   Управление    списком    диспетчеров    событий    и    критериями    их

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

6.4. Пример. Сервер Dialogic CT Media: телефонные медиа-ресурсы

Сервер CT Media фирмы Dialogic в наиболее полной мере соответствует текущим материалам форума ECTF. Это открытый программный комплекс, который управляет функциями контроля каналов и медиа-ресурсов, т.е. в режиме клиент-сервер управляет предоставлением медиа-ресурсов для различных клиентских приложений.

На примере сервера CT Media рассмотрим третий - нижний уровень архитектуры СТ-сервера, что на рис. 6.1 обозначено в общем виде как медиа-ресурсы. На рис. 6.3 медиа-ресурсы расписаны более подробно, выделены их основные части:

•   интерфейс провайдера услуг S.300,

•   драйверы различных ресурсов,

•   физические ресурсы,

•   интерфейс с коммутатором S.3xx (еще не специфированный),

•   сам коммутатор.

Физическую обработку медиа-сигналов производят сигнальные процессоры DSP (Digital Signal Processor) и другое аппаратное обеспечение, что в прикладных программах обозначается словом «ресурсы». В программах, именуемых «ресурсами», реализация физических устройств спрятана от двух верхних уровней (сервера и приложений). Эти программы выступают лишь абстрактным интерфейсом для физических клиентов, которые предусмотрены соглашением S.100 (табл. 6.1).

Программа под названием «Ресурсы» принимает запросы от провайдеров услуг и через драйверы передает их физическому ресурсу. И наоборот, «Ресурсы» принимают сообщения о событиях и данные от физических устройств и генерируют ответы и сообщения к провайдерам Услуг.

В качестве примера использования DSP сошлемся на платы -Dialogic. Например, плата Dialogic D/41ESC содержит четыре компонента физических ресурсов, каждый из которых включает пять Ресурсов:

•   один проигрыватель;

•   один проигрыватель;

•    одно записывающее устройство;      

•    один детектор сигналов;                               

•    один генератор сигналов;    

•    один канал вызова.            

Таблица 6.1. Сервер СТ Media: ресурсы, поддерживаемые адаптерами AIA и интерфейсами провайдера услуг

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

6.5. Обслуживание медиа-вызова: общая схема

Рисунок 6.7. содержит схему обслуживания медиа-вызова. Основным элементом этой схемы является подключение медиа-ресурсов и передача медиа-потока через устройство медиа-доступа, включенного в соединение. Устройство медиа-доступа - это сетевой интерфейс в коммутационной области, через который осуществляется выход на каналы вызова.

Рис. 6.7. Базовая модель медиа-вызова    

Обслуживание медиа-вызова является основой целью построения

S.lOO-сервера и состоит из четырех процессов:

1) управление сеансом

2) управление ресурсами;                           

3) управление группой (ресурсов);

4) управление соединением.                                       

Управление сеансом. Все начинается с создания сеанса и запроса ресурсов для обработки медиа-информации. Сеанс создается между медиа-приложением и сервером по каждому медиа-вызову (рис. 6.8). По Данным из библиотеки клиентов определяется профиль применения, что, в свою очередь, определяет набор свойств, которые необходимы для обработки вызова, а также детальный выбор параметров тех системных ресурсов, которые необходимы для обслуживания данного вызова. Информацию о профиле применения сервер использует для выбора конфигурации группы ресурсов, инициализации параметров и установки правил построения и выполнения сеанса (рис. 6.9).

Управление ресурсами. Это один из наиболее трудных вопросов, так как необходимо управлять дефицитными физическими ресурсами,

например ресурсами распознавания голоса или обработки факс-сообщения. Программа управления ресурсами (рис. 6.10) особенно важна для обслуживания тех вызовов, которые требуют более одного ресурса. Эту задачу выполняет сервис распределения ресурсов, который:

1)  интерпретирует профиль применений данного клиента и определяет

ресурсы, требующиеся для создаваемой группы;  

2)  выбирает ресурсы;                                                            

3) закрепляет выбранные ресурсы за группой.

Рис. 6.10. Схема управления ресурсами

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

Рис. 6.11. Иллюстрация группы ресурсов

В примере, который показан на рис. 6.11, входящий телефонный вызов требует ресурс канала вызова CCR (Call Channel Resource) и три вторичных ресурса: детектора тонов сигнализации (SIGD), распознавания голоса (ASR) и передачу записанного сообщения (Play).

Управление соединением. В чем отличие между группой и соединением? Группа по сути являет собой соединение между ресурсами, но оно, это соединение, остается скрытым (неявным) с точки зрения приложений. Интерфейс управления соединением - это средство для открытого управления, которое позволяет приложениям резервировать соединения между двумя ресурсами через систему коммутации и устанавливать это соединение, а затем и разрушать. Соединение устанавливается через виртуальный ресурс, называемый точкой коммутации (Switch Port). Точка коммутации - это абстракция соединения группы в коммутаторе сервера (рис. 6.12).

Рис. 6.12. Иллюстрация соединения медиа-вызова

6.6. Группа и контейнер - основные средства

организации медиа-потоков

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

Первичные и вторичные ресурсы. Первичный ресурс используется для перемещения потоков данных между внешним миром (т.е. вне данной группы) и вторичными ресурсами группы. В качестве первичного ресурса в S. 100 названы три класса ресурсов: 1) порт коммутатора (например, временной слот в шине, виртуальный канал в АТМ-системе);

2) порт конференц-связи;

3) ресурс канала поступившего вызова, например аналоговый канал или

В-канал по стандарту ISDN.

Рис. 6.13. Первичный ресурс

Вторичные ресурсы производят обработку медиа-потоков (например, распознавание сигналов или речи, прием и передачу факсимильного сообщения). Они получают набор данных от первичного ресурса или передают их к первичному ресурсу. Структура группы ресурсов представлена на рис. 6.14.

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

Конфигурация группы (groupconfig) — это спецификация ресурсов (и их атрибутов), образующих группу.

Профиль применения (application profile) — совокупность информации, которой пользуется клиент и сервер для предоставления требуемого применения, включает конфигурацию группы и идентификационный номер сервиса.

Рис. 6.14. Структура группы ресурсов

Жизненный цикл группы состоит из шести фаз:

1) Создание группы. Группа создается сервером по запросу клиента. Клиент определяет конфигурацию группы. Он становится владельцем группы, и его имя фиксируется в стеке владельцев группы.

2) Присвоение.   Чтобы   группа   была   готова   выполнять   требуемое приложение,   ей   следует   присвоить   определенные   аппаратные   и программные средства.

3) Действие. В течение своего жизненного цикла данная группа может сделать множество действий.

4) Реконфигурация. Владелец группы может потребовать изменения её конфигурации.

5) Смена владельца. Группа может перейти к новому владельцу (клиенту) или вернуться к прежнему клиенту. Это отражается в стеке владельцев группы.

6) Разрушение группы.

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

Соединения между группами. Суть соединений между группами заключается в передаче медиа-потоков. Описаны три типа соединений: 1) Мостовое соединение - первичные ресурсы двух групп соединяются посредством соединения вторичных ресурсов двух групп, как показано на рис.  6.15.  Это типичная  схема для  соединения  между двумя вызовами.

Рис. 6.15. Мостовое соединение                                      

2) Присоединение группы (второй группы к первой) - первичный ресурс второй группы становится вторичным ресурсом первой группы, как на рис. 6.16. Такое присоединение происходит при конференц-связи.

3) Соединение   типа   обратной   петли   (рис.   6.17).   Это   соединение применяется при тестировании (по схеме обратной петли).

Рис. 6.16. Схема присоединения группы 2 к группе 1

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

Контейнер может содержать объекты разных типов:

•  файловые объекты;

•   аудио- и видео объекты, требующие временной синхронизации;

•   объекты двумерных изображений;

•   другие контейнеры (точнее, ссылки на другие контейнеры). Клиент может:

•   открыть контейнер,

•   использовать имя контейнера в командах для получения данных или передачи на хранение,

•   осуществить импорт и экспорт данных между клиентской файловой системой и контейнером.

Рис. 6.17. Соединение типа обратной петли

Объекты в виде данных характеризуются типом медиа-данных, а именно:

•   форматом данных в файле,

•   алгоритмом кодирования/декодирования и

•   временной информацией относительно данных.

Спецификация S.100-сервера допускает три типа медиа-данных:

1) медиа-данные, требующие временной синхронизации (аудио- и видео данные).      Они      требуют      выбора      алгоритма      кодирования. Специфицированы 18 типов кодирования, в том числе задано 9 типов кодирования телефонной передачи. Фиксированы 34 языка, в том числе 4 варианта английского языка. Подробно расписаны правила преобразования текста в речь;

2) медиа-данные   в   виде   двумерных   изображений,   включая   режим

передачи книг, изображений в них;

3) файлы.

Менеджер контейнеров управляет доступом к данным, например страницами факс-сообщения, миллисекундами речи и т.п.

6.7. Маршрутизатор медиа-вызовов

И наконец, следует рассмотреть последний системный сервис S.100-сервера -маршрутизатор медиа-вызовов SCR (System Call Router). Тем самым будет завершено рассмотрение всех блоков базовой архитектуры S.1 ОО-сервера (см. рис. 6.3). Связи блока SCR изображены на рис. 6.18.

SCR участвует в обслуживании медиа-вызовов. Он осуществляет соединения медиа-вызова с сетью через канальный ресурс SCR (Call Channel Resource) в коммутаторе сервера. Разработаны планы маршрутизации для выполнения трех функций блока SCR:

1) маршрутизация входящего вызова, что является главной функцией

SCR;

2) маршрутизация исходящего вызова;                

3) переадресация вызова.                                                                 

Блок SCR обрабатывает вызовы на основе следующей информации:

•   номер вызывающего абонента,

•   номер вызываемого абонента,                               

•   время суток,

•   требования к качеству обслуживания и другие критерии.

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

6.8. Пример. Сервер СТ Медиа (продолжение)

Продолжим рассмотрение сервера Dialogic CT Media (см. раздел 6.4). Начнем с общей архитектурной схемы компьютерной телефонии и места сервера СТ Media в ней (рис. 6.19).

СТ Media предоставляет не только рассмотренные выше системные сервисы: сеанс, группа, контейнер, соединение и маршрутизация медиа-вызовов, но и обепечивает стык с контролем вызова по протоколу TAPI. Включение контроля данных в состав телефонного сервера СТ Media отличает предложенную конфигурацию от той, что рекомендует архитектурная группа ECTF. Нижнюю часть рис. 6.19 занимают телефонные ресурсы. В данном случае это платы фирмы Dialogic.

Заключая изложение материалов форума ECTF на примере сервера СТ Media, еще раз подчеркнем, что львиную долю всех усилий по созданию СТ-систем составляет программирование. Не говоря уже о том, что сам СТ-сервер - это сложный программный комплекс (middleware) между прикладными программами (на языке высокого уровня) и программами для DSP в телефонных ресурсах.

Сервер СТ Media фирмы Dialogic иллюстрирует современный подход к оснащению готовых фирменных средств вспомогательными средствами разработки (Software Development Kit, SDK).

Рисунок 6.20 поясняет возможности программирования сервера СТ Media, призванные облегчать его использование другими фирмами. Выделены три блока средств программирования:

•   ресурсы сигнальных процессоров DSP,                             

•   стек сетевого интерфейса NIS SDK,                               

•   интеллектуальное расширение коммутатора ISE SDK.

В 1998 г. шли дебаты о взаимных преимуществах двух протоколов: спецификаций ECTF S.I00 и протокола Микрософт TAPI 3.0. Эта дискуссия прекратилась в марте 1999 г. объявлением о двух встречных шагах:

•   об объединении обоих интерфейсов в сервере Dialogic CT Media и

•   о включении этого комплекса программ фирмы Dialogic в состав

Windows NT.

Таким образом, СТ Media становится ядром для построения СТ-серверов, которые могут поддерживать разные приложения, разработанные разными фирмами, a Windows NT5 может стать общепризнанной сетевой операционной системой для ECTF. Эту возможность тем более усиливает членство компании Microsoft в форуме ECTF с лета 1999 г.