Книга
Книга
Глава 1
Основы компьютерной телефонии
Машины должны работать. Люди должны думать.
Девиз компании IBM
Что такое компьютерная телефония?
Собственно говоря, ответу на этот вопрос и посвящена значительная часть книги. Здесь же мы попытаемся определить лишь некоторые основные понятия в этой области и обозначающие их термины.
Связисты старшего поколения помнят горячие споры о терминологии, дискуссионные статьи, связанные с разработкой терминологических ГОСТов, борьбу с употреблением терминов «телетрафик» вместо «телефонная нагрузка», «бит» - вместо «двоичный разряд», «компьютер» - вместо «электронная вычислительная машина» и т.п. Сегодня подобные споры просто бессмысленны, в первую очередь, из-за резкого сокращения продолжительности жизни не столько са- михтерминов, сколько соответствующих этим терминам технических концепций, решений и оборудования. А потому авторы в этой книге, начиная с ее названия, сознательно используют сложившийся в отечественных публикациях по компьютерной телефонии сленг как наиболее эффективное (а иногда - просто единственное) средство быть понятыми читателями.
Как метко определил много печатавшийся в СССР американский поэт левых взглядов Карл Сэнберг, «сленг 一 это язык, снявший пиджак, поплевавший на руки и принявшийся за работу». И именно это
соображение оправдывает появление на страницах книги таких слов как Call-центр, IP-телефония, предоплатные телефонные карточки и т.п.. Только исключительный успех отдельных телекоммуникационных технологий позволяет соответствующим терминам на некоторое время закрепиться, а иногда даже перейти из узко профессионального лексикона в повседневный обиход, как это получилось, например, с аббревиатурами АТС или GSM. Уже сейчас ясно, что аббревиатуру CTI - Computer-Telephony Integration (компьютерно-телефонная интеграция) или СТ - Computer Telephony (компьютерная телефония) вряд ли ожидает счастливая участь аббревиатуры GSM. Более того, авторам представляется, что появляющаяся в настоящее время в результате конвергенции компьютерных и телекоммуникационных технологий новая индустрия инфокоммуникаций «покроет как бык овцу» компьютерную телефонию. Или, заменяя метафору Михаила Жванецкого несколько менее образным высказыванием бизнес-аналитика Боба Эммерсона, - «компьютерная телефония принадлежит индустриальной нише стоимостью в 8 миллиардов долларов, которая оказалась катапультированной в 200 миллиардный рынок и была им поглощена». Тем не менее, 8 миллиардов долларов 一 тоже хороший рынок, поэтому обратимся к компьютерной телефонии как таковой и начнем с определений.
Человек, который в 1992 году придумал термин компьютерная телефония, - это Гарри Ньютон, известный специалист в области телекоммуникаций и издатель нескольких журналов и книг по электросвязи, в том числе, журнала «Компьютерная телефония». У нас более известен его «Ньютоновский словарь по телекоммуникациям», в котором дается следующее определение:
Компьютерная телефония /СТ, Computer Telephony) - дисциплина использования развитых логико-информационных возможностей компьютера для создания и приёма телефонных вызовов, сообщений факсимильной связи и других сложных сообщений и транзакций с участием сетей общего пользования, частных сетей и сети Интернет. Этот термин охватывает множество технологий, в том числе, интеграцию компьютер-телефон через локальную сеть, интерактивную обработку речи, речевую почту, операторские Call-центры, распознавание речи, преобразование текст-речь, факсимильную связь, одновременную передачу речи и данных, обработку речевых сигналов, видеоконференции, автоматический набор номера, аудиотекст, речевое воспроизведениеданных, справочные службы и мно- гиедругие технологии, дополняющие и расширяющие функциональные возможности традиционной телефонной коммутации.
Приведенное определение включает в сферу компьютерной телефонии операторские Call-центры, что, по мнениюавторов, отнюдь не общеизвестно, а потому и само название книги, и компоновка материала в ее главах призваны это продемонстрировать. Кроме того,
определение не затрагивает обратную ситуацию, когда телефонная система управляет некоторыми функциями компьютерной системы. Хотя уже в конце 1960-х годов область компьютерной телефонии, ещё не имевшая своего названия, была представлена комплексом из нескольких мэйнфреймов IBM 360, соединённых с УАТС IBM 2750, который обеспечивал приём заказов от книжных магазинов через сеть общего пользования Германии. А в 1970-х годах это были автоматическое распределение вызовов к агентам крупных операторских центров с помощью оборудования компании Rockwell и система Delta 1 компании Delphi Corporation, которая использовалась службами ответа на телефонные вызовы в Сан-Франциско. В 1980-х годах это были система речевой почты VMX, система интерактивного речевого ответа Periphonics и устройства упреждающего набора. Обо всем этом будет подробнее рассказано в следующей главе.
Там же будет сказано, что уже с самого начала 1990-х годов компьютерная телефония использовала не только большие ЭВМ, но и персональные компьютеры (PC), которые внесли в телекоммуникационную индустрию новые возможности. Стандартизация отрасли связи и наличие дешёвых СТ-каналов породили новое поколение СТ-приложений, которые связали с телефонными линиями серверы локальных вычислительных сетей (LAN), телефонные станции сетей общего пользования, УДГС частных сетей и настольные PC.
В те дни двумя лидерами компьютерной индустрии были Novell и Microsoft, причем считалось, что Novell владеет компьютерными сетями, a Microsoft - настольными PC. Именно эти две компании были первыми, кто начал разрабатывать стандартную модель API компьютерной телефонии. В 1992 году AT&T и Novell разработали интерфейс программирования приложений услуг телефонии (Telephony Services Applications Programming Interface, TSAPI), который работал только в среде NetWare, что было относительно дорого, однако обеспечивал применение в приложениях компьютерной телефонии архитектуры клиент/сервер с возможностью управления функциями third-party call control. В этих приложениях сервер является интеллектуальным и может устанавливать соединения и маршрутизировать вызовы независимо от пользователя, а также управлять, например, удалённой УАТС.
Компании Intel и Microsoft разработали интерфейс программирования приложений телефонной связи (Telephony Application Programming Interface, TAPI), открытое программное обеспечение, работающее noflWindows и выполняющее телефонные приложения в PC (first party call control), но не позволявшее (по крайней мере, вплоть до появления версии 3.0) в полной мере поддерживать third-party call control на базе архитектуры клиент/сервер. К подходам 7Api и TSAPI мы еще вернемся в связанной со стандартизацией главе 3, в главе 9, описывающей алгоритмическое обеспечение Call-центров и компь-
ютерной телефонии, а также в плаве 10, посвященной программному обеспечению компьютерной телефонии.
Кстати, именно в главах 9 и 10 изложены основные причины, по которым в конце 1990-х годов потребовалось ещё раз переопределить понятие «компьютерная телефония». Это было обусловлено, в частности, объединением традиционных телефонных систем коммутации каналов с пакетными технологиями и с IP-сетями, такими как Интернет, при котором в компьютерной телефонии становятся существенными не столько сами компьютеры, сколько абстрактная модель управления обслуживанием вызова и обмена сообщениями. В эпоху, когда концепция платформы сместилась из операционной системы к браузерам, интерфейс TAPI, едва выйдя победителем из войны cTSAPI, в 1998 году столкнулся с конкурентом абсолютно нового типа - с интерфейсом Java Telephony API (JTAPI). Некоторые функции JTAPI и TAPI перекрываются. Одной из этих функций является функция управления обслуживанием вызова J7API, которая также используется в JAIN, куда, в конечном итоге, перейдет значительная часть функциональных возможностей J7API. Эта более широкая спецификация JAIN, как и другая, не менее перспективная технология PARLAyAPI, рассматриваются далее в этой книге.
А сейчас вернемся к терминам и определениям. Приведем еще несколько определений, подобранных в редакционной колонке первого выпуска журнала «Компьютерная телефония» за 2000 год.
Карлтон Карден, автор книги «Understanding Computer Telephony» предлагает следующее определение. Компьютерная телефония - это общий термин, охватывающий широкий спектр технологий и приложений, использующих компьютерный потенциал (чаще всего - сервер или локальную сеть), чтобы придать телефонии интеллектуальные функции и обеспечить сопряжение этих функций с обработ- койданных.
Эд Маргулис из Miller Freeman Voice Data Group: Компьютерная телефония - отрасль, специализирующаяся на приложении компь- ютерного интеллекта к созданию и приему телефонных вызовов, а также к другим сложным взаимодействиям.
Наиболее развернутое определение предложено ведущей в этой области компанией Dialogic: Компьютерная телефония - это технология, которая позволяет скоординироватьдействия телефонной и компьютерной систем для выполнения следующих функций.
Прием телефонного вызова, когда система обнаруживает входящий вызов, воспроизводит(без участия оператора) ответную речевую фразу и меню опций, а также дает абоненту возможность оставить свое сообщение.
Управление набором номера, когда абонент, набрав телефонный номер системы компьютерной телефонии, получает предложение
ввести с клавиатуры телефонного аппарата свой идентификационный номер, а после верификации этого номера получает второй сигнал ответа станции и указания о дальнейшем наборе, например, междугородного или международного номера.
Автоматическое разъединение системами компьютерной телефонии, отвечающими на вызовы путем воспроизведения записанной информации f например, прогноза погоды), по окончании ее воспроизведения.
Маршрутизация телефонного вызова к нужному приложению вызываемой стороны (при этом с аппарата, непосредственно принявшего вызов, ответна вызов не производится). В варианте программированной переадресации входящий телефонный вызов направляется к другому телефонному номеру f например, система речевых сообщений позволяет пользователям заранее указать телефонный номер, к которому при их отсутствии на рабочем местедолжны переадресовываться входящие вызовы). Другой вариант автоматической переадресации позволяет ответить на входящий вызов и направить его к другому расширению в случае, если от вызывающего абонента не поступает никаких указаний. Например, приняв входящий вызов, система компьютерной телефонии инструктирует вызвавшего абонента: «набрать 1 в случае, если вызов производится с кнопочного телефона, или подождать соединения». Если абонент не набирает требуемый номер в течение 5 секунд, вызов автоматически переводится к секретарю. Вариант переадресации в зависимости от информации, поступившей от абонента: система отвечает на входящий вызов и предлагает вызывающему абоненту набрать, в зависимости от цели звонка, ту или иную комбинацию цифр. Например, система компьютерной телефонии предлагает набрать 1 для соединения с отделом продажи, 2-с отделом обслуживания и т.п., или подождать ответа секретаря. Весьма интересен еще один вариант - маршрутизация к службам телефонных аудиоконференций, дающим абонентам возможность присоединять ся к беседе двух или более сторон, набирая определенную комбинацию цифр в режиме много часто тного набора.
Уведомление абонента, участвующего в сеансе связи, о новом входящем вызове посредством специального звукового сигнала. Большинство телефонных систем располагают этой функцией, часто 一 в сочетании с функцией ре чевой почты. Если извещаемая о новом вызове сторона не желает отвечать на него, вызывающий абонент слышит записанную речевую фразу и имеет возможность оставить свое сообщение.
Организация ожидания: вызов находится в очереди до тех пор, пока вызываемое лицо не сможет на него ответить, или пока не освободится исходящая линия, по которой может быть произве-
дена его дальнейшая маршрутизация. Если количество входящих вызовов превышает количество людей, их обслуживающих, может быть организовано ожидание ответа. Ожидающие абоненты обычно слышат звуковой сигнал или речевое сообщение, информирующее их о перспективах дальнейшего ожидания, а например, приложение «телефон доверия», позволяет абонентам получать в это время бесплатную информацию, консультацию или помощь.
Предоставление информации в соответствии с меню опций, воспроизводимым при поступлении в систему входящего вызова. Вызывающий абонент выбирает нужную опцию, нажимая на определенную кнопку телефонной клавиатуры или просто называя избранную опцию (если система оборудована функцией распознавания речи). Например, служба «банковские сделки по телефону» отвечает на вызов и воспроизводит меню предлагаемых услуг приблизительно по такой модели: «Если вас интересует сальдо счета, наберите 1, если процентная ставка, наберите 2 и т.п.» Информация может воспроизводиться автоматически или в зависимости от выбранной абонентом опции меню. Пользователь может регулировать скорость и громкость воспроизведения, набирая соответствующие комбинации цифр в DTMF-режиме. Упреждающее введение информации с клавиатуры в DTMF-режиме позволяет пользователям «вторгаться» в воспроизводимое сообщение, вводя в систему необходимую информацию. Например, пользователь, знакомый с приложением для проверки балансов, может ввести номер своего счета, не дослушав до конца предлагаемые ему инструкции. Возможно озвучивание информации, хранящейся в текстовом файле: синтезатор речи может за читать вызывающему абоненту текст, хранящийся в компьютерном файле (например, сообщение электронной почты). Система преобразования текста в речь может создавать и новые, не записанные заранее речевые сообщения. Например, может быть озвучена хранящаяся в телефонном справочнике информация о телефонных номерах, именах, адресах и т.п. Система уведомления может сообщить абоненту о том, что ему оставлено сообщение. Например, система речевой почты отвечает на вызовы, поступающие к занятым телефонным номерам, и предлагает вызывающим абонентам оставить сообщение. Вызываемая сторона извещается о наличии сообщения световым сигналом или текстом на дисплее телефонного аппарата. Возможна отправка факса - информации, хранящейся в компьютерном файле. Например, система факсимильного ответа предлагает позвонившему абоненту ввести в систему телефонный номер, по которому можно отправить факс. Более сложные системы позволяют вызывающему абоненту предварительно выбрать из предлагаемого меню необходимую ему информацию.
Получение информации, т.е. запись и хранение в компьютерном файле для последующей обработки информации, получаемой от абонентов. Например, система массового опроса респондентов, работающая по следующей схеме: люди звонятпо определенному номеру, и им предлагается записать свои соображения в связи с обсуждаемой темой. Другой вариант - определение телефонного номера вызывающего абонента с помощьюАОН. Например, приложение телемаркетинга может направить вызов к торговому агенту и в процессе его разговора с абонентом поместить в базу данных телефонный номер этого абонента и информацию о текущем запросе. Еще один вариант - фиксация набранной абонентом цифровой комбинации: регистрируются и сортируются цифровые коды, набранные вызывающими абонентами. Например, автоматизированная система проведения опросов предлагает людям позвонить по определенному номеру и проголосовать, выбрав тотили иной ответпутем набора на телефонном аппарате заданного цифрового кода. Система регистрации определяет и записывает информацию о входящих и исходящих телефонных вызовах, включая данные о продолжительности разговора, о дате и времени суток, набранный телефонный номер или телефонный номер вызывающего абонента и т.п. Это позволяет, например, оценить производительность труда операторов телемаркетинго- вой компании, определить среднее время, затрачиваемое ими на работу с одним телефонным вызовом.
Распознавание речи позволяет абонентам взаимодействовать с системами компьютерной телефонии, произнося определенные слова или фразы. Эти технологии особенно полезны в условиях, когда применение многочастотного режима набора номера весьма ограничено. Система распознавания устных команд, произносимых определенным человеком, предусматриваетин~ дивидуальную настройку системы компьютерной телефонии на конкретного пользователя путем: (1) формирования списка употребляемых слов; f2) многократной аудиозаписи этих слов, позволяющей системе запомнить характеристики речи говоряще- го/говорящей; (3) повторения записи в разных условиях(скажем, при шумовых помехах на телефонной линии). Система распознавания устных команд независимо от индивидуальных речевых особенностей говорящего обычно предусматривает весьма ограниченный запас слов (цифры от О до 9), слова «да» и «не丁》 и т.п. Например, при обращении к службе «банковские сделки по телефону» абонентов, имеющих телефон с дисковым набором, звонящие слышат меню и произносят название (или код) выбранной ими опции. Система идентификации вызывающего абонента делает это путем сравнения заранее сохраненного образца его голоса с голосом звонящего по телефону. Тот же
пример - служба «банковские сделки по телефону» предлагает звонящему назвать номер своего счета, а затем использует уже имеющийся в ее распоряжении образец голоса владельца этого счета для идентификации последнего на предмет предоставления ему доступа к счету. Распознавание речевой информации, вводимой во время автоматического воспроизведения текста, позволяет постоянному клиенту, уже знакомому с системой, озвучить выбранную им опцию меню, не дожидаясь окончания автоматически воспроизводимого сообщения. Например, смете- ма воспроизводит фразу ответа на вызов и перечень отделов, в которые он может быть переадресован. Абонент может озвучить избранную им опцию, не дожидаясь окончания перечисления. Идентификация ключевых слов позволяет распознать определенные слова независимо от того, произносятся ли они отдельно или в каком-то контексте. Например, при заказе платной услуги в ответ на предложение назвать нужный ему отдел абонент может просто ответить: «Кредит» или произнести фразу: «Я бы хотел поговорить с отделом кредитов^ - в любом случае система распознает ключевое слово «кредит» и соответствующим образом направит вызов.
Сетевые функции, к которым относятся генерация и детектирование зуммерных сигналов ТфОП, что позволяет приложению произвести вызов и вести затем мониторинг процесса его обслуживания. Наряду с генерацией стандартных зуммерных сигналов ТфОП при наборе телефонного номера абонентами, возможны генерация и детектирование нестандартных акустических одночастотных и двухчастотных сигналов с амплитудой и длительностью, не используемыми в обычной практике ТфОП. Возможно распознавание сигнала о разъединении, передаваемого районной АТС, например, для приложений телемаркетинга при воспроизведении заранее записанных сообщений. Если вызванный абонент повесил трубку, система определяет факт разъединения, прекращает воспроизведение и набира етдругой номер. Возможно и распознавание системой человеческого голоса с целью определить, когда на звонок отвечает человек, а не автоответчик или подобное устройство, и только в этом случае начать воспроизведение заранее записанных сообщений.
Напротив, одно из самых коротких определений компьютерной телефонии предложено в книге Джефри Шапиро [29], согласно которому компьютерная телефония f СТ!) - это процесс интеграции внешних автономных или находящихся в составе сети компьютерных систем с телефонной сетью и узлами коммутации.
Еще одно, краткое, но весьма емкое определение компьютерной телефонии принадлежит Луису Б. Левику из Digital Equipment Company: Компьютерная телефония 一 технологическая платформа,
обеспечивающая слияние на функциональном уровне услуг, связанных с передачей речи, и услуг, связанных с переда чей данных, в результате чего коммерческие приложения приобретают ощутимые выгоды.
Компания Mitel определяет компьютерно-телефонную интеграцию СТ! как технологию пре дос тавле ния услуг на базе объединения коммуникационных возможностей телефонных систем сигнализации и вычислительных возможностей и ресурсов баз данных компьютерных систем.
К основным понятиям CTI относятся и два подхода к организации услуг компьютерной телефонии: непосредственный ( first party СТ) и сторонний (third party СТ). С точки зрения физической, первый подход можно уподобить интеграции компьютера и обычной телефонной линии; при втором подходе компьютер подключается непосредственно к коммутационному узлу. В сетевом плане эти подходы могут относиться к обычному пользователю телефоном и к оператору, соответственно. В случае third party СТ оператор устанавливает соединение для абонента, устраняясь от участия в нем и предоставляя системе компьютерной телефонии накапливать данные об организации сеанса связи, конфигурационные подробности о вызываемом и вызывающем абонентах и т.д. Именно в этом смысле оператор рассматривается как посредник (третье лицо).
Здесьуместно определить термины оператор, те. человек-телефонист, принимающий вызовы определенной телефонной службы, отвечающий на эти вызовы и/или обеспечивающий их маршрутизацию, и автоматический или компьютерный оператор, те. услуга или система компьютерной телефонии, которая заменяет человека-телефониста. В обязанности телефониста могут входить бизнес-администрирование, обработка слов и данных, учет вызовов, эксплуатационное управление, обучение пользователей, взаимодействие с прессой, связь с общественностью, подготовка текста для компьютерной телефонии, запись речи и архивирование информации, помощь администрации и многое другое.
Определим еще несколько терминов.
Автоматическое распознавание речи (ASR) представляет собой технологию, обеспечивающую надежное распознавание некоторых элементов человеческой речи, таких как отдельные цифры и короткие команды или непрерывные строки цифр вроде произнесенного номера кредитной карты. Независимая от говорящего система ASR может распознавать ограниченное количество слов (обычно - цифры и короткие команды), произносимых любым человеком. Зависимая от говорящего система ASR может распознавать большое количество слов и команд, произносимых определенным человеком.
Архитектура SCSA - комплексная открытая архитектура системы обработки сигналов (SCSA) для поддержки многопользовательских услуг компьютерной телефонии вереде клиент-сервер. Сервер SCSA обеспечивает возможность инициировать вызовы, отвечать на вызовы, маршрутизировать вызовы, устанавливать конференц-связь и манипулировать информацией (влиять на содержимое сеансов связи). Серверы SCSA также дают возможность обрабатывать информацию разных видов (например, речь, телефакс, текст и электронную почту) и преобразовывать информацию любого из этих видов с тем, чтобы представить ее в наиболее удобной форме. Система прикладных объектов телефонии (ТАО) в составе SCSA определяет стандартный набор программных интерфейсов, протоколов и услуг; которые составляют модель программного обеспечения. Эти интерфейсы являются открытыми, объектно-ориентированными и аппаратно-независимыми.
Интерфейсы ТфОП позволяют системам компьютерной телефонии устанавливать связь с телефонными сетями по разным линиям, от аналоговых абонентских линий с импульсным набором до цифро- выхлиний Е1 с первичным доступом PRA ISDN.
Конференции - возможность объединить в одном сеансе телефонной связи трех или нескольких участников. Для участников конференцсвязи могут устанавливаться разные права, например, некоторым абонентам может быть разрешено только слушать разговор, но не говорить самим.
Медиа - серверы представляют собой специализированные серверы обработки речи, которые обеспечивают генерацию системных сообщений, возможность обмена сообщениями (включая преобразование типов сообщений), конференцсвязь, распознавание и синтез речи, детектирование многочастотных сигналов DTMF. Кроме того, медиа-серверы используются программными коммутаторами для генерации автоинформационных сообщений и акустических сигналов, а также для поддержки функций конференцсвязи в процессе предоставления базовых услуг.
Медиа-шлюзы - обеспечивают интерфейс между традиционной сетью с коммутацией каналов (и, соответственно, абонентами данной сети), и сетью с пакетной коммутацией (и ее абонентами). Основной функцией медиа-шлюза является преобразование формата пользовательской информации (медиа-потоков). Медиа-шлюзы могут также обеспечивать преобразование форматов при связи двух разных сетей пакетной коммутации. Кроме того, медиа-шлюзы поддерживают возможность генерации простых акустических сигналов (например, зуммер ЗАНЯТО) и системных сообщений (например, «Набранный номер недоступен»);
Программные коммутаторы (Softswitches) поддерживают базовые функции маршрутизации вызовов и управления коммутацией медиа-потоков, связанных с маршрутизируемыми вызовами, и учет использования ресурсов и услуг; аналогично возможностям, поддерживаемым традиционными АТС. Они также могут поддерживать функции авторизации и идентификации абонентов и функции учета использования ресурсов в сети пакетной коммутации. С точки зрения телефонной сети общего пользования Softswitch представляет собой устройство, совмещающее функции транзитного пункта сигнализации STP и транзитного коммутатора, поддерживающего системы сигнализации E-DSS1, ВСК, ОКС7, а с точки зрения пакетных сетей Softswitch является устройством управления медиа-шлюзами (Media Gateway Controller) и, одновременно, контроллером сигнализации (Signaling Controller).
Автоматическая входящая связь DID представляет собой возможность набирать номер внутреннего абонента учреждения без помощи компьютерного оператора или человека-телефониста.
Серверы приложений являются платформой для реализации приложений типа Unified Messaging, связанных с обработкой и преобразованием медиа-данных. В принципе, их можно рассматривать как разновидность серверов услуг или, наоборот, серверы услуг можно считать частным случаем серверов приложений (с точки зрения авторов это разделение весьма искусственно, но в литературе оно присутствует).
Серверы услуг обеспечивают реализацию интеллектуальных услуг, связанных с изменением (на основе определенных критериев) алгоритма обслуживания и маршрутизации вызовов, и, как правило, предусматривающих дополнительно процедуры аутентификации, авторизации и начисления платы (аналогично SCP классической Интеллектуальной сети).
Хотелось бы, чтобы из этого множества определений читатель понял, что компьютерная телефония - это нечто гораздо большее, чем только связь компьютера и телефона. И если раньше, на заре компьютерной телефонии, основным инструментом компьютерной телефонии была некая вычислительная мощность, подключенная к телефонной системе, то современная компьютерная телефония 一 это не какое-то устройство, а технологическая среда, которая вносит интеллект в процесс обслуживания вызовов и дает возможность разнопланового выбора вариантов этого процесса. Она предоставляет не столько какую-либо определенную услугу, сколько возможность построить на её основе подходящее приложение, используя богатый набор концепций, алгоритмов и формализованных инструментов. А некоторые из новых инструментальных средств, имеющихся у разработчиков компьютерной телефонии, такие как генераторы
приложений и настраиваемые под заказчика готовые к использованию системы, позволяют даже неспециалистам легко приспосабливать коммуникационную среду к собственным потребностям. Современные услуги компьютерной телефонии обладают выдающимися возможностями и функциональными характеристиками.
Вместе с тем, на пути развития и внедрения компьютерной телефонии, как и любой другой новой технологии инфокоммуникаций, имеется целый ряд проблем, которые будут обсуждаться далее на страницах этой книги. Речь идет о технических проблемах, что же касается психологических или социальных аспектов, то они остаются за пределами книги в силу некомпетентности авторов в этих вопросах. Тем не менее, не упомянуть о самом факте их наличия было бы неверно. Например, для японцев очень важно, как обращаться друг к другу (так сложилось в течение столетий); поэтому японцу нужно время, чтобы почувствовать себя комфортно в диалоге «человек- компьютер», например, в IVR или в речевой почте. Дай не только для японцев. Существует определенное сопротивление новой технологии со стороны людей старшего поколения. Пользователи самых разных категорий могут воспринимать компьютер, который звонит им и разговаривает с ними, как нечто пугающее и сбивающее с толку. Без учета всех аспектов влияния технологии в таких областях, как общественная культура, человеческие обычаи и этика общения, любой самый технологически совершенный проект компьютерной телефонии может с треском провалиться.
Не менее важен еще один социальный фактор 一 наличие во Взаимоувязанной сети связи России миллионов телефонных аппаратов, не поддерживающих многочастотный набор номера. И не только в России: около 80% всех абонентов Земного шара 一 обладатели телефонов с импульсным набором номера. Даже в США около 25% абонентов продолжают использовать телефонные аппараты с дисковыми номеронабирателями. В связи с этим наиболее часто востребованным сообщением компьютерной телефонии м ожет о казаться следующее: «Чтобы соединиться с нужной вам службой, нажмите цифру 1, а если у вас аппарат с дисковым номеронабирателем, то издайте, пожалуйста, звук, похожий на сигнал DTMF; соответствующий цифре 1, а если не сумеете, то положите трубку на рычаг и идите покупать себе новый телефонный аппарат с многочастотным набором».
CTI или СТ?
Вернемся к упомянутым в предыдущем параграфе понятиям СТ и CTI. Буква *Г в аббревиатуре CTI обозначает интеграцию и объединяет две до последнего времени весьма далекие друг от друга среды -учрежденческие АТС сети с коммутацией каналов и серверы сети
с коммутацией пакетов. Первое поколение таких решений отнюдь не отличалось элегантностью и привело к чересчур разнообразным меню интерактивных систем IVR, к избытку ответных речевых сообщений и музыкальных мелодий, предоставляемых абоненту вместо ответа для удержания соединений. Тем не менее, именно эти разработки положили начало CTI как применению компьютера для управления телефонной системой, с одной стороны, и как оборудованию, которое позволяет людям взаимодействовать с компьютером при помощи своих телефонов, с другой. Используемый в этой книге термин компьютерная телефония (СТ) относится к следующему поколению и подразумевает более высокий уровень интеграции - компактные технические решения, такие как связные серверы, которые под- держиваюттелефонию клиент/сервер, а также приложения типа единой системы обмена сообщениями.
Такое противопоставление CTI и СТ несколько условно. Аббревиатура CTI была введена Джимом Бартоном, когда он работал в IBM, причем мотивы были отнюдь не технические. Дело в том, что в 1985 году Карл Штратмайер из компании DEC (в настоящее время - подразделение компьютерной телефонии Intel/Dialogic) разработал первый канал связи между компьютером и телефонным аппаратом и ввел термин «Computer Integrated telephony, CIT» (интегрированная с компьютером телефония), однако IBM не захотела использовать термин, придуманный их главным конкурентом. Джим Бартон путём перестановки букв в акрониме получил CTI. Позже Бартон по этому поводу часто говорил, что ему всегда больше нравился термин, придуманный Штратмайером, чем его собственный.
Как бы то ни было, в обиход вошёл термин CTI, и он применялся при описании рассматриваемой технологии и индустрии до тех пор, пока Гарри Ньютон и Джерри Фризен не начали использовать термин Computer telephony (компьютерная телефония) в первом выпуске нового журнала под тем же названием, который вышел осенью 1993 года.
К этому времени те, кто был воспитан на термине CTI, осознали, что выражение «Computer Telephone Integration» является, в некотором роде, ограничительным, поскольку подразумевает технологию, которая относится исключительно к физическому стыку компьютер- телефон. Была предпринята попытка сохранить акроним CTI путём введения и популяризации более адекватного термина «Computer Telephony Integration». При такой трактовке оба термина 一 «СТ!» и «СТ» - можно считать взаимозаменяемыми, что и сделано, в частности, в данной книге. Еще одним примером является тот факт, что в течение нескольких лет в США единственным конкурентом журнала «ComputerTelephony» был журнал «СТ1», который издавали Наджи и РичардТехрани.
В мартовском номере журнала «Computer Telephony» за 1997 год Гарри Ньютон опубликовал статью под заголовком «Why CTI is not Computer Telephony», в которой он объяснил, почему CTI является лишь малой частью всей отрасли компьютерной телефонии. Аргументы были убедительны, и авторы этой книги ему поверили. Да и не только они, даже журнал «СТ1» в 2000 году был переименован в «Communications Solutions». В трактовке Ньютона СТ намного более изящная технология, которая предусматривает не только физическую, но и функциональную интеграцию, и для которой ключевым является то, что она обеспечивает создание полезных инфокоммуникационных приложений. В этом смысле компьютернуютелефонию уместно сравнить с операционной системой, которая обеспечивает условия для создания приложений и открывает доступ к функциям компьютерной системы. Хотелось бы обратить на это особое внимание читателя, поскольку приложения - именно то, что нужно оператору, а все остальное - лишь технологические средства.
Таким образом, к приведенным в предыдущем параграфе определениям можно добавить еще одно: компьютерная телефония 一 это технология, которая обеспечивает множество разнообразных, полезных и интересных функций, позволяющих создавать принципиально новые приложения для поставщиков инфокоммуникационных услуг.
Эти функции могут быть разделены на две большие группы 一 функции управления обслуживанием вызова и функции обработки медиапотоков, о чем будет сказано более подробно в главе 9. В конечном итоге, названные функции позволяют произвести исходящий вызов, обнаружить входящий вызов и ответить на него, озвучить для абонента текст, хранящийся в файле формата ASCII в компьютере, используя синтезированную речь (преобразование «текст-речь»), воспроизвести абоненту оцифрованную речь по телефону, накопить статистическую информацию о входящих и исходящих вызовах, и т.п.
В связи с этим следует упомянуть уже цитировавшегося ранее Боба Эммерсона, который считает, что настало время заменить акронимы СТ| (компьютерно-телефонная интеграция) и СТ (компьютерная телефония) новой аббревиатурой ICT (информационно-коммуникационная технология). К этому хотелось бы добавить еще одну, появившуюся совсем недавно в нескольких публикациях аббревиатуру CTII (Computer Telephony Internet Integration), которая напоминает об известной спиральной модели развития. Этот термин подчеркивает сближение компьютерной телефонии с IP-телефонией и с Web-технологиями в целом. Впрочем, квитку спирали, связанному с интеграцией компьютерной телефонии и Интернет, мы еще вернемся в главе 8, да и не только в ней.
Еще одним подтверждением упомянутых тенденций является тот факт, что в борьбу за телекоммуникационный рынок, за то, чтобы
стать активными строителями телекоммуникационных сетей следующего поколения (Next Generation Networks - NGN), в последние годы включились такие традиционно компьютерные компании, как HP и Intel. Так, Intel энергично скупал и продолжает скупать компании, имеющие отношение к Call-центрам, компьютерной телефонии и к телефонии вообще. Среди купленных им компаний крупнейший производитель плат и библиотек ПО для компьютерной телефонии компания Dialogic и один из ведущих производителей зарубежных конвертеров сигнализации и ПО для поддержки телекоммуникационных протоколов Datakinetics.
Связисты, в свою очередь, активно сражаются за усиление своего влияния в смежных областях, таких, например, как электронная коммерция, имея очень существенные наработки в области системы расчетов с абонентами или организации справочно-информационных служб.
Упомянем и про язык XML, которому прочат большое будущее в качестве универсального языка структурирования документов и данных, и про язык SIP [5], имеющий массу аналогий с языком написания Web-страниц HTML, но успешно используемый сегодня для управления обслуживанием вызовов в сетях IP-телефонии и рассматриваемый как перспективный язык управления услугами в телекоммуникационных сетях следующего поколения.
Рядом телекоммуникационных компаний активно продвигается в жизнь и поддерживается концепция IT-аутсорсинга, т.е. перепору- чения внешней специализированной компании обслуживания информационной инфраструктуры заказчика, что выражается для связистов в сдаче в аренду сторонним организациям ресурсов Call-центров и контакт-центров, рассматриваемых в главах 6, 7 и 8.
CTI и Интеллектуальная сеть
С самого начала своего развития вычислительная техника в целом, азатем и компьютерная телефония, ориентировались, главным образом, на обслуживание трех основных инфраструктур современной цивилизации: банков, телекоммуникаций и транспорта. Именно на этих инфрастуктурах были сосредоточены и первые услуги компьютерной телефонии.
Параллельно с этим процессом и в сфере телекоммуникаций создавались собственные службы (служба 800 в Северной Америке, «свободный телефон» в Европе, 008 в Австралии, «свободный набор» в Японии), которые способствовали развитию разных видов коммерческой деятельности и разных информационных услуг для населения. Они же обусловили появление концепции Интеллектуальной сети (IN), которая позволила революционно усовершенствовать этот про-
цесс и обеспечить организацию услуг в масштабе национальной телекоммуникационной сети, или даже в мировом масштабе, а также предоставить абонентам принципиально новые возможности, которых прежде в телекоммуникациях не существовало.
Основой идеологии Интеллектуальных сетей является отделение функций организации услуг от функций транспортировки и построение универсальной среды, обеспечивающей наибольшую эффективность конструирования и предоставления новых телефонных услуг. Концепция Интеллектуальной сети стала средством глобального нагнетания вычислительной мощности в телефонную сеть общего пользования. Стандартизацию этой концепции Международный союз электросвязи (ITU-T) выполнил, в основном, в период с 1985 до 1990 гг.
Возникновение парадигмы Интеллектуальной сети явилось следствием двух основных событий: создания электронных АТС с управлением по записанной программе и перехода от внутриполосной сигнализации (сигнализации по выделенным сигнальным каналам) к общеканальной сигнализации ОКС7.
В связи с наличием в программно управляемых АТС компьютеров, полностью выполняющих управление коммутацией, функции коммутации могут быть путем программирования преобразованы, расширены и видоизменены как для поддержки существующих, так и для создания новых услуг. Такая возможность, в сочетании с ОКС7, привела к появлению услуг, называемых интеллектуальными. Этот термин не совсем корректен (говорить следует об услугах Интеллектуальной сети), но он уже устоялся и широко применяется, причем часто им обозначают и такие, например, услуги, как блокировка входящих вызовов или идентификация номера вызывающего абонента, т.е. услуги, реализуемые программным обеспечением самой АТС. Фактически только услуга 800 являлась первой услугой, где были использованы функциональные возможности протокола ТСАР из стека протоколов ОКС7.
Для маршрутизации вызова, требующего услугу 800, исходящая АТС (с функциями SSP) направляет запрос к централизованной базе данных, где для каждого пользователя услуги 800 хранится фактический номер, к которому должен быть направлен вызов, идентификационный код оператора, номер, на который будет начисляться плата за услугу, а также другие контекстно-зависимые условия для работы механизма маршрутизации (время суток, местоположение исходящей АТС и т.п.). Эта информация передается обратно на исходящую АТС (SSP) для того, чтобы она могла направить вызов к конечному пункту назначения.
Пример архитектуры современной Интеллектуальной сети представлен на рис. 1.1. Узлы коммутации услуг (SSP - Service Switching
Рис. 1.1 Архитектура Интеллектуальной сети
Points) распознают вызовы, требующие услуг Интеллектуальной сети, и обслуживают эти вызовы, взаимодействуя с централизованным узлом управления услугами (SCP - Service Control Point). Не менее важен и другой элемент архитектуры Интеллектуальной сети, хотя он не работает в реальном времени, - среда создания услуг (Service Creation Enviroment- SCE), в которой конструируются и проверяются новые услуги. SCE содержит базовые инструментальные средства (в частности, графический пользовательский интерфейс), позволяющие разрабатывать и тестировать интеллектуальные услуги с помощью набора программных модулей (конструкционных блоков, не зависящих от услуг, - service-independent building blocks, SIB), комбинируя которые, можно «построить» ту или иную услугу.
Очень неудачно был назван еще один важный элемент архитектуры IN - интеллектуальная периферия IP (Intellectual Periphery): подавляющее большинство читателей воспринимает это сокращение как обозначение протокола Интернет (IP - Internet Protocol). Таким же образом оно используется и в этой книге, за исключением этого абзаца и рис. 1.1, на котором IP обозначает и то, и другое. Кстати сказать, более удачный, по мнению авторов, термин для обозначения данного элемента IN предложен в [27] - узел специальных ресурсов SRP (Special Resource Point). Так или иначе, этот элемент обеспечивает поддержку интеллектуальных услуг речевыми сообщениями (например, чтобы информировать инициаторов вызовов об изменении номера, о запрещении вызовов), а также обнаруживает и передает акустические сигналы, принимает сигналы набора DTMF и т.п.
Начиная с 1992 года, крупные национальные телефонные операторы приступили к развертыванию инфраструктуры Интеллектуальной сети, а приносящими реальную прибыль услугами, кроме уже упоминавшейся службы 800, были: вызов с оплатой по кредитной карте, выявление злонамеренных вызовов, избирательная переадресация вызовов при занятости или при отсутствии ответа абонента, сокращенный набор номера, вызов по паролю, автоматическая альтернативная оплата разговора и др.
Несмотря на достигнутые успехи, при развертывании Интеллектуальных сетей возникло немало трудностей, вызванных:
необходимостью существенных начальных инвестиций для создания Интеллектуальной сети и общей высокой стоимостью ее инфраструктуры,
относительной сложностью протоколов INAP и TCAR
неполным соблюдением стандартов IN производителями оборудования,
сложностью процесса создания услуг,
невостребованностью целого ряда услуг из списка CS-1 (Follow me, например),
централизацией биллинга и управления услугами с вытекающим отсюда ограничением возможности выполнения этих функций конечными пользователями.
К тому же, развитие компьютерных технологий сделало хорошо видимой громоздкость технологии распределенных вычислений ROSE, на которой базировалась традиционная Интеллектуальная сеть. Разнообразие услуг IN и вариантов их реализации существенно больше, чем разнообразие базовых телекоммуникационных услуг, и оказалось, что почти каждый поставщик хочет максимально адаптировать ту или иную услугу к своим потребностям, а сделать это в «классической» Интеллектуальной сети далеко не так просто, как декларировалось. Развитие информационных технологий привело к появлению компаний, специализирующихся на предоставлении только информационных услуг, однако выяснилось, что добиться взаимодействия с оборудованием сторонних производителей при создании новых услуг и использовании внешних информационных ресурсов в «классической» IN практически невозможно.
И еще одной немаловажной проблемой оказалось как раз развитие рассматриваемых в данной книге технологий, а именно, появление продуктов на базе PC, предлагающих многие функциональные возможности IN. Эти продукты используют стандартные интерфейсы, открытые аппаратные платформы и независимое ПО, и стоят на несколько порядков дешевле, чем традиционная инфраструктура Интеллектуальной сети. Более того, их платформы в большей степени соответствуют новой среде, в которой границы между услугами передачи речи, данных и видеоинформации продолжают непрерывно размываться.
Тем не менее, операторы связи, уже развернувшие у себя инфраструктуру Интеллектуальной сети (причем многие - совсем недавно), будут с неохотой изымать из обращения оборудование IN, которое находится только на ранней стадии износа. Эту ситуацию в полной мере осознают компании-производители, администрации связи, органы стандартизации, и они активно работают над концепциями, архитектурами и протоколами взаимодействия, которые позволят, в частности, SCP Интеллектуальной сети сохранить ключевую роль в конвергентной сети.
Немало этому способствуют и технологии мобильной связи. Наличие на рис. 1.1 элементов мобильной ИС подразумевает взаимодействие протоколов INAP и ТСАР с другими протоколами ОКС7 - MAP (Mobile Applications Part), IS41 и CAMEL (Customized Applications for Mobile Network Enhanced Logic), - а значит и дальнейшую эволюцию Интеллектуальной сети.
У читателя, который не у до влетво рится этим более чем поверхностным анализом Интеллектуальной сети, есть возможность обратиться к монографии [3]. Там подробно рассмотрены основные концепции Интеллектуальной сети, ее важные преимущества в свете проблематики данной книги, например, гарантированное сквозное (end-to- end) качество обслуживания (QoS), экономичное введение новых услуг через INAK архитектура узлов услуг SN (Service Node) и др.
Читателям, заинтересованным в глубоком изучении вопросов конвергенции сетей и услуг связи и проблем создания современных инфокоммуникационных услуг, было бы чрезвычайно полезно ознакомиться с книгой [3], включая последние ее главы, посвященные конвергенции IN и IP, IN для мобильных сетей связи, широкополосных сетей, IN и CORBA и др. Из этих материалов станет ясно, почему именно концепция Интеллектуальной сети, по всей вероятности, окажется тем мостом, который поз вол ит традиционны м телефонным сетям (как стационарным, так и мобильным) взаимодействовать с IP-сетями.
И все это - в диалектическом взаимодействии с тем, что многие услуги IN-типа уже предоставляются (и будут еще больше предоставляться) IP-серверами или региональными узлами услуг (SN), что разрабатываемые сегодня интеллектуальные коммутационные платформы поддержки IP-услуг и компьютерной телефонии третьего поколения сами являются интегрированными коммутаторами и процессорами поддержки услуг с начислением платы за них, и что все это объективно вызывает перемещение «интеллектуальности» из традиционных узлов IN к краям сети. Впрочем, это не первый в истории техники случай диалектического взаимодействия центростремител ь- ных и центробежных сил.
Для отечественных операторов разумным, с практической точки зрения, компромиссом является близкий к идеологии компьютерной телефонии 3-го поколения подход, сформулированный в концепции Интеллектуальной сети и предусматривающий применение выделенных узлов услуг SN (Service Nodes), уже упоминавшихся в данном параграфе. Этот подход позволяет создавать системы, по функциональным возможностям не уступающие платформам распределенной Интеллектуальной сети, апо ценовым характеристикам - во много раз более эффективные. К тому же, ряд услуг, задуманных в рамках CS-1 IN и за несколько лет приобретших у потребителей большую популярность, оказался великолепно реализуемым с использованием технологий CTI.
Еще одним аргументом в пользу подхода с применением SN является социально-психологический фактор. Как оказалось, «попереч-
ное тяготение» между разными регионами России в силу многих причин (в т.ч., и размеров территории страны) невелико. Средний житель, предположим, Пензы весьма слабо интересуется юридическими консультациям и Перми или, например, ценами в м агази н ах Хаба - ровска. С ледовател ьн о, задача глобализации услуг, столь актуальная в «компактных» европейских странах, в нашей стране распространяется на существенно меньшее количество услуг
Недостатки же, связанные с изначально централизованной архитектурой SN (перекострафика в сети и др.), в последнее время начали отступать благодаря развитию IP-технологий, позволивших перейти на качественно новый уровень и создавать т.н. распределенные центры, обмен информацией между модулями которых происходит с использованием компьютерных, а не телекоммуникационных протоколов. Концептуально каждый из элементов такой системы может находиться в произвольной точке глобальной телекоммуникационной сети, взаимодействуя с другими элементами по протоколу TCP/IP с использованием, при н еобходи м ости, любой из существующих технологий распределенных вычислений (CORBA, JAVA), или, например, с использованием протоколов из стека Н.323 или SIR
Перспективная архитектура такого SN представлена рис.1.2.
Серверы баз данных
Рис. 1.2 Структура узла услуг SN для конвергентной сети связи - интеграция технологий IN, CTI и ПР
Конвергенция телекоммуникационных услуг
и 1Р-услуг
Упомянутая в предыдущем параграфа альтернатива IN, согласно которой будущее принадлежит неинтеллектуальным IP-сетям с интеллектуал ьными средствами, устанавливаемыми на краях сети (вплоть до персональных компьютеров оконечных пользователей), таит в себе опасности, выходящие за пределы ТфОП с IN.
В первую очередь, это проблемы глобальной децентрализации, послужившие поводом к шутливой расшифровке аббрев натуры WWW как Wild Wild West и усугубляющиеся невиданной ранее быстротой и легкостью, с которой создаются новые приложения компьютерной телефонии 3-го поколения, интерактивных игр, электронной коммерции, чатов и пр. Главная проблема в том, что практически все элементы архитектуры IP-сетей - шлюзы, маршрутизаторы, привратники, программные коммутаторы, терминалы (PC, WAP), клиентские приложения (браузеры, FTF* e-mail, чат), сетевые серверы (RADIUS, LDAP, DNS) и серверы приложений (HTTP, FTP, Java, SIP, POP3)-управляются совершенно разными сетевыми структурами, а весьма многие из этих элементов вообще н икак не управляются.
С другой стороны, практически все поставщики телекоммуникационного оборудования, и традиционные, и новые, предусматривают интерфейсы 0КС7 в Web-контакт-центрах и IP-серверах, так что эти центры и серверы могут на основе IP-протокола организовывать связь с узлам и управлен ия услугами SCP и/или с базами данных компьютерной телефонии, а также устанавливать соединения между пользователями. Разумеется, при этом есть опасность возникновения перегрузки в сетях 0КС7. Операторы, которые устанавливают Web-контакт-центры и другое оборудование компьютерной телефонии, иногда рассчитывают на то, что они будут единственными пользователями сети 0КС7. Однако при наличии многих операторов все они одновременно могут создать любую нагрузку сети 0КС7, которая, возможно, захлестнет и узлы услуг Это может стать стихийным бедствием не только для пользователей инфокоммуникационными услугами, но и для всех абонентов сетей общего пользования, поскольку сеть 0КС7 обслуживает все вызовы. Причиной такой ситуации могут, например, стать заявки на пересчет номера в случаях, когда соответствующая услуга не активизирована, и информация о номере по сети не передается. В результате создастся бесполезная нагрузка, т.к. коммутационные узлы будут пытаться определить, куда следует маршрутизировать вызовы. Рост IP-телефонии придаст подобной тенденции отнюдь не безопасное ускорение.
К этому нужно добавить весьма слабо удовлетворяемую потребность в удобном биллинге и в гарантированном сквозном качестве обслуживания (QoS). Кроме того, новые IP-сети, будь то Интернет,
Интранет, Экстранет, корпоративная или частная сеть передачи данных, распространят эти проблемы и на такие инфокоммуникацион- ные услуги, как маршрутизация и ремаршрутизация, управление шириной полосы пропускания и секретностью, административное управление сетью, а также на услуги, ориентированные на определенного заказчика.
Простым и красноречивым примером новой инфокоммуникаци- онной услуги как результата конвергенции является услуга Internet Call Waiting (ICW), аналогичная широко применяемой (не в нашей ТфОП, к сожалению) телефонной услуге установки вызова на ожидание. Услуга ICW обеспечивает вызов по телефону пользователя, занятого сеансом связи с Интернет. Получив извещение отелефонном вызове, пользователь может приостановить сеанс с Интернет и либо ответить на этот вызов, либо переадресовать его на другую линию или к почтовому ящику и т.п.
Еще одним примером того же класса является услуга Click-to-Dial (CTD), дающая пользователю возможность исходящего телефонного вызова во время сеанса с Интернет путем активизации пиктограммы на экране компьютера. Особое удобство этой услуги связано с тем, что пользователь может вызвать телефонного оператора интересующей его компании, просто нажав на указатель на Web-странице этой компании. Подробнее об этом будет сказано в главе 8.
Другой услугой в направлении от IP к ТфОП является услуга Internet Customer Profile Management(ICPM), позволяющая пользователю управлять назначенным для него профилем обслуживания непосредственно со своего персонального компьютера, например, с помощью меню на Web-странице. Реализованные сейчас услуги предусматривают возможность управления профилем обслуживания при помощи сигналов DTMF от телефонного аппарата. Тот, кто попробовал оба варианта, безусловно, почувствовал разницу.
Во встречном направлении компьютерная телефония может немало сделать для IP. Сегодня роль оператора местной телефонной сети сводится, в большинстве случаев, к организации коммутируемой связи между пользователем и Интернет-поставщиком (ISP). Рассматриваемые в этой книге услуги помогут оператору местной телефонной сети оптимизировать доступ к Интернет-поставщику, организовать для соединений с ним альтернативный биллинг, предоставить универсальный номер для всех ISP Point of Presence (IPOP), создавать службы бесплатных вызовов (Freephone)] предоплаченных вызовов (Prepaid calling) и т.п. В полном соответствии с правилом «помогая другим, поможешь и себе» телефонная сеть общего пользования может не только повысить свои доходы, предоставляя услуги доступа пользователей к Интернет, но и уменьшить расходы путем наискорейшего отвода IP-трафика из своей сети к Интернет-поставщику.
Уже сегодня становится все менее и менее принципиальным различие между услугами компьютерной телефонии, заказываемыми и управляемыми пользователями с помощью телефонного аппарата и сигнализации DTMF- и услугами IP-сетей, доставляющих пользователю с помощью его персонального компьютера и протоколов TCP/IP информацию в формате HTML или Java-апплеты от соответствующих Web-серверов. И, независимо от того, где расположены интеллектуальные средства - в центре сети или на ее краях, - объединенные в процессе конвергенции функциональные возможности сетей ТфОП и IP-сетей позволят наиболее эффективно организовать управление как услугами, уже внедренными или разработанными и готовыми к внедрению, так и совсем новыми услугами, которые еще только будут придуманы в результате объединения усилий специалистов новой индустрии инфокоммуникаций.
Call-центры и речевые порталы
Говоря о новых услугах связи, предоставляемых телекоммуникационными операторами и/или поставщиками услуг; можно назвать три способа их пре достав лен и я - автоматизированный, с помощью операторских центров и с использованием речевых порталов. Конечно, такое разделение условно, так как автоматизация присутствует и во втором, и в третьем случае, а с другой стороны, при всех трех способах необходимы определенные действия того человека, который хочет воспользоваться услугой.
Начнем с первого, автоматизированного способа. Этим способом предоставляется большинство услуп привычных и известных читателю: предоплаченные услуги связи (вызов по сервисной телефонной карте), многокритериальная маршрутизация вызовов и преобразование номера, автоматическая (активная или пассивная) передача абонентам информации, в частности, с использованием технологии audiotext и технологии синтеза речи. Некоторые такого рода услуги пришли из Интеллектуальной сети, другие - из простейших офисных применений, причем и те, и другие адаптировались к современным требованиям крупных телекоммуникационных сетей. Таковы, например, услуги речевой почты или Unified Messaging.
Второй способ - так называемые «одушевленные» услуги - это услуги, предоставляемые абонентам с помощью операторов Call- центра. Операторские службы, или центры распределения (обработки) вызовов существовали задолго до появления концепции Интеллектуальной сети и продолжают существовать, изменяясь в соответ^ ствии с развитием телекоммуникационных и компьютерных технологий. Их функции - прием заявок на обслуживание, предоставление абонентам разного рода справочной информации, организация экстренных служб и др. Этой проблематике посвящена значительная часть книги (главы 6, 7, 8, и не только они).
Традиционные приложения операторского Call-центра и справочного стола (help desk) позволяют более эффективно использовать персонал благодаря предварительной обработке информации с помощью автосекретаря, который может давать ответы на общие вопросы, пока вызывающий абонент ждёт, когда ему ответит оператор, или ступени распределения вызовов (СРВ), которая либо направляет вызов к незанятому оператору, высвечивая на его экране сведения о вызывающем абоненте, либо маршрутизирует вызов, основываясь на ответах этого абонента на подсказки, управляет очередями, передает ожидающим в очереди музыку или информацию и т.д.
Для иллюстрации возможностей более современного Web-кон- такт-центра, предоставляющего услуги на базе сочетания функций телефонной сети и сети Интернет, можно привести пример коммерческой деятельности, где такое сочетание используется весьма эффективно, -изготовление одежды по индивидуальным заказам при ценах, конкурирующих с ценами аналогичной продукции массового спроса. Клиент «посещает» демонстрационный зал магазина, выбирает модель, которая его устраивает, и оформляет заказ. Информация отправляется по сети Интернет за сотни и тысячи мильтуда, где отмеряется нужная ткань, которую далее отвозят в то место, где производится пошив. Готовое изделие отправляют в магазин, где был оформлен заказ, и доставляют клиенту, причем все это делается в течение одного-двух рабочих дней. Таким образом, Web-контакт-цен- тры позволяют персонализировать отношения с посетителями Web- сайтов, обеспечивая доступ к агенту службы заказчика в критический момент, когда у посетителя имеется важный вопрос, от ответа на который зависит, совершит он покупку или нет.
И, наконец, третье направление - так называемые порталы.
Под речевым порталом понимается некий серийный телефонный номер, позволяющий получить нужную информацию в виде речевого сообщения, т.е., по сути, - автоинформационная система, которая обладает определенным интеллектом, способностью поиска ин - формации и преобразования ее в вид, пригодный для восприятия на слух. Мощный сервер, на котором построен портал, преобразует речь вызывающего абонента в формализованный запрос, производит поиск в базе данных или в сети Интернет, после чего зачитывает абоненту найденную информацию.
В принципе, это может быть не только информация о погоде или о точном времени. У речевого портала можно запросить содержимое Web-сайта, скажем, с использованием уже упоминавшейся технологии XML. Речевые порталы могут предоставлять ряд услуг; полезных абонентам мобильных сетей. Например, можно из автомобиля устно известить речевой портал о своем местоположении и в ответ, опять же, в речевом режиме, получить информацию о ближайших дорогах, погоде, оптимальном маршруте и т.п.
Главная проблема создания речевых порталов сегодня - несовершенство технологии распознавания речи, что особенно актуально для отечественного рынка, потому что разработки систем распознавания речи на русском языке существенно отстают от аналогичн ых ан г- лоязычных разработок, о чем будет подробнее сказано в главе 11.
Преимущества речевых порталов перед рассматриваемыми в главе 4 более традиционными решениями компьютерной телефонии очевидны. В частности, длинный путь по системе сложных меню заменяется в речевом портале интуитивно очевидной системой навигации.
Кроме речевых порталов известиы также мобильные порталы. Обычно под мобильным порталом понимается сайт, из которого можно отправить сообщение в разные сети, а также получить доступ к различной информации, используя мобильные устройства связи. Технологии доступа к информации, используемые в мобильных терминалах, общеизвестны. Это WAP, SMS, GPRS, представляющие собой услуги мобильных сетей 2 и 3 поколения.
Порталы, обеспечивающие доступ к своим услугам со стороны абонентов разных сетей связи, имеют общее название телекоммуникационных порталов. Технологически телекоммуникационный портал -это специализированный Интернет-сервер, интегрированный с телефонным сервером. Основные услуги телекоммуникационных порталов сводятся к получению и отправке сообщений электронной почты, речевых, факсимильных, видеосообщений и текстовых сообщений, используемых в сетях мобильной связи (SMS), с преобразованием их формата в зависимости от типа терминалов вызывающего и вызываемого абонентов.
Именно к этой категории можно отнести системы Unified Messaging, которые позволяют передавать и принимать сообщения потенциально любого типа, используя самые разные терминалы доступа. Системы Unified Messaging подробно рассматриваются в главе 4.
Из всего изложенного в данной главе можно сделать некоторые выводы.
Компьютерная телефония, начавшаяся на уровне электрической шины, платы и чипа, благодаря увеличению вычислительной мощности и пропускной способности шин, развитию ПО и систем распознавания речи, получила в последние годы не просто больше функциональных возможностей и большее число портов на каждой плате CTI, а вышла на качественно новый уровень. Всего лишь одно из направлений развития программного и аппаратного обеспечения переросло в концепцию, серьезно влияющую на эволюцию телекоммуникационного мира.
Глава 2 Исторические предпосылки
«Если бы вы могли изобрести что-нибудь полезное в области телеграфии, 丁。обеспечили бы себе надежный годовой доход и потом, отписав его своей жене, могли бы заниматься обучением визуализованной речи и ставить эксперименты в телеграфии с чистой и спокойной совестью».
Гардинер Хаббард, из письма Александру Беллу от 13 марта 1876 г.
Я полагаю, что на мировом рынке можно будет продать штук пять компьютеров
Томас Уотсон, директор IBM, 1943 г.
История телефона
Одним из величайших изобретений XIX века является телефон - прибор, преобразующий звуковые колебания в электрические. С его появлением стала реальностью передача речи на расстояние. Да и само слово «телефон», будучи образовано из греческих слов «теле» - «далеко» и «фоно» - «звук», буквально означает «звук издалека».
Это изобретение связано с именем знаменитого американца Александра Грэхема Белла, получившего в США в 1876 году патент на первый пригодный для практического применения телефон (рис.2.1). По образованию Белл не был ни инженером-электриком, ни физиком. Он работал с людьми, страдавшими дефектами речи или потерявшими слух. Стремление помочь этим людям и любовь к девуш ке, оглохшей после болезни, побудили его конструировать приборы, с помощью которыхон демонстрировал глухим артикуляцию звуков речи. Белл глубоко изучил акустику и физические основы человече-
ской речи и стал вместе со своим помощником Томасом Уотсоном ставить опыты, связанные с использованием мембраны для передачи звуковых колебаний, что привело его к созданию электромагнитных приборов, явившихся прототипом современного телефона.
Вскоре Белл, совместно с Уотсоном и Гардинером Хаббардом (отцом той самой девушки, оглохшей после перенесенной ею скарлатины), организовал фирму Bell Telephone Company, которая впоследствии приобрела всемирную известность под именем Bell Systems. Однако сам Белл покинул Bell Telephone еще в 1879 году из-за разногласий в ее правлении.
No 201,488No 201,488Fig, 1Fig, 1Fig. 2Fig. 2ЕЕЕЕNN| Earth || Earth |F©.4F©.4SSEEEEI Earth II Earth IAlexander Graham Bell's PatentAlexander Graham Bell's PatentA.G. BELLSpeaking TelephoneA.G. BELLSpeaking TelephonePatented March 19,1878Patented March 19,1878NNвFig, 5вFig, 5Рис. 2.1 Патент А.Г. БеллаРис. 2.1 Патент А.Г. БеллаFig.3Fig.3N N NN N N
No 201,488
No 201,488
Fig, 1
Fig, 1
Fig. 2
Fig. 2
Е
Е
Е
Е
N
N
| Earth |
| Earth |
F©.4
F©.4
S
S
E
E
E
E
I Earth I
I Earth I
Alexander Graham Bell's Patent
Alexander Graham Bell's Patent
A.G. BELL
Speaking Telephone
A.G. BELL
Speaking Telephone
Patented March 19,1878
Patented March 19,1878
N
N
в
Fig, 5
в
Fig, 5
Рис. 2.1 Патент А.Г. Белла
Рис. 2.1 Патент А.Г. Белла
Fig.3
Fig.3
N N N
N N N
В 1922 Александр Грэхем Белл умер от диабета. Он отнюдь не был богат, хотя жил вполне комфортной жизнью высших кругов среднего класса. Пожалуй, самым большим его богатством было сознание того, что он совершил важнейшее открытие в области телефонии. Его ассистент, Уотсон, ушел из Bell Telephone вскоре после смерти Белла и избрал для себя карьеру актера; умер он в 1934 году.
Любопытно, что жизнь другого изобретателя телефона тоже была связана с театром. Итальянец Антонио Меучи родился во Флоренции в 1808 году, работал механиком в местном театре, а позднее - в Миланском и Римском. Деньги Антонио тратил, в основном, на изобретательство и на изучение малоизвестных явлений, связанных с электричеством. В 1838 году, в поисках заработка, он приехал в Га-
вану, где, по одной из версий, для создания сценических эффектов в театре «Такой» был применен первый телефон. Работами Меучи в области электричества заинтересовался генерал Леопольдо О'Доннел, которого тревожило то, что оружие, и даже металлические пуговицы на солдатской униформе, из-за влажного климата быстро ржавели. Антонио предложил прибегнуть к гальваностегии, что и было успешно осуществлено. Полученные средства дали ему возможность обратиться к экспериментам в области связи. В 1844 году Антонио отправился в Италию, где сражался под знаменами Джузеппе Гарибальди. Через пять лет, в чине офицера, он возвратился в Гавану и занялся применением электричества в медицине.
В 1850 году Меучи отплыл в Нью-Йорк. В его багаже, среди приборов, чертежей и рукописей, лежало и описание изобретения, названного «говорящий телеграф». С помощью этого устройства ему удалось наладить дома устную связь из своего кабинета, расположенного на первом этаже, с третьим этажом, где находилась его парализованная жена.
В Нью-Йорке Антонио запатентовал способ производства бумаги из тростника и дал заявку на ткацкие станки нового типа. Бумага никого не заинтересовала, а вот производство полотна пошло неплохо, так что он смог взяться за доводку «говорящего телеграфа». Несколько раз патентное ведомство возвращало ему чертежи и схемы, однако Меучи не унывал и продолжал работу. В борьбе с этим ведомством прошло два десятка лет, и вдруг; в 1871 году, последовал сокрушительный удар - его официально уведомили о том, что «все документы исчезли, и найти их не представляется возможным».
Начались затяжные судебные процессы. Лишь в 1886 году Верховный суд США решил дело в пользу Антонио Меучи. Его, наконец- то, признали изобретателем телефона, но приоритет был уже потерян: с 1876 года патентом на телефон владел Александр Белл, который, кстати, появился в США именно в том, катастрофическом для Меучи, 1871 году.
Как это случается почти с каждым великим изобретением, вокруг создания телефона существует целый ряд подобных историй. О ситуации с опоздавшим на два часа Э.Греем широко известно и уже писалось, в частности, в [4].
Менее известно, что принцип действия телефона разработал в своей диссертации французский телеграфист Ш.Бурсель. Описание его изобретения было представлено в 1854 году в Академию, где оно тоже попросту затерялось за 20 лет до появления электрического телефонного аппарата Белла.
Еще одним предшествен н и ком А. Белла считается Филипп Рейс, молодой школьный учитель из Фридрихсдорфа. Изготовленный им телефон представлен на рис.2.2. Передатчиком служил деревянный
ящике двумя отверстиями: одно-для рупора, а другое было затянуто мембраной с иглой посередине, которая под влиянием колебаний мембраны периодически прикасалась к металлической пластине, замыкая и размыкая электрическую цепь. Еще более любопытным был приемник, который представлял собой железную вязальную спицу, обмотанную изолированной проволокой и помещенную в корпус старой скрипки с проделанными в нем отверстиями.
Рис. 2.2 Телефон Ф. Рейса
Ап парат действовал, правда, звуки нужно было произносить очень протяжно, чтобы их можно было разобрать на приемной стороне. Именнотакой аппаратбыл продемонстрирован за 15 лет до изобретения А. Белла, 26 октября 1861 года, перед членами Физического общества города Франкфурта. Оценка высоко ученых членов этого общества была благосклонна: «хорошая игрушка для детей». В качестве игрушек, талантливым механиком по имени Альберт было изготовлено несколько аппаратов Рейса, один из которых попал в шотландский университет в Эдинбурге, где с ним познакомился А. Белл. Не к таким ли ситуациям относится известный тезис о неисповеди- мости путей? Первой реакцией Белла на этот телефон была идея создать аналогичный аппарат, превращающий звуки в световые сигналы, чтобы с его помощью научить говорить глухих детей. Каким образом мысли Белла вернулись в область электрического телефона, оставив оптическую передачу речи другим изобретателям другого века, история умалчивает. О том же, как малопригодный для промышленного применения принцип Рейса с его мембранами и иглами превратился в телефон Белла, написано много. Впрочем, сам Рейс ничего об этом не узнал. Он умер в январе 1874 года в возрасте 40 лет, а признание пришло в 1885 году, когда в городе Гнельгаузен ему установили памятник, и министр почт США прислал по этому случаю следующую телеграмму: «В чести, которую мир не оказал Филиппу
Рейсу при его жизни, он не откажет ему теперь, когда его уже нет среди нас, ибо его великий дух жив и движет мир».
Предметом изобретения Белла был только приемник, преобразующий электрические колебания в звуковые; возможности его использования в качестве передатчика были крайне ограничены. Дальнейшее совершенствование телефона связано с угольным микрофоном, который изобрел Давид Эдуард Юз в 1878 г. Железную мембрану Белла в передатчике заменила коробочка с угольным порошком. От колебаний воздуха сопротивление угольного порошка то увеличивалось, то уменьшалось, изменяя соответственно силу проходящего через порошок электрического тока. Усовершенствования, устранявшие посторонние шумы и позволявшие хорошо слышать собеседника на любом расстоянии, внес в телефон Эдисон, включая, разумеется, применение индуктивной катушки. Благодаря всем этим изобретениям телефонная связь по проводам с каждым годом стала находить все большее и большее применение.
В связи с возникновением компьютерной телефонии следует сказать несколько слов о телефаксе. Идею нынешнего телефакса (от греческого «теле» - «далеко» и латинского «facsimale» - «делай подобное») предложил англичанин Александр Байн в 1843 году, то есть за 33 года до появления телефона.
Первые результативные попытки передачи рисунка на расстояние относятся к концуXIX века. Основой для этого послужили работы российских ученых Б.С. ЯкобииП.Л. Шиллинга по телеграфии. 5 мая 1908 года О.А. Адамян получил патент на систему передачи по проводам двухцветного изображения, а 30 июня 1930 года осуществил по своей схеме передачу/прием первой фотодиаграммы между Москвой и Ленинградом.
Многое сделал в этой области Б.Л. Розинг. Благодаря его изобретению, а также работам других ученых и инженеров, появились фототелеграф и факсимильная связь. Но по-настоящему массовое использование телефаксов началось в 70-е годы XX века. Свою роль в этом сыграло несколько факторов - бурная автоматизация офисов, появление недорогих микросхем и согласование первых стандартов, благодаря чему стало возможным совместное использование аппаратов, произведенных разными фирмами.
История компьютера
BV веке до н.э. в Египте, Финикии, древней Греции был известен абак (от греческого abax 一 доска) 一 счетный инструмент, представлявший собой дощечку, покрытую слоем песка. На ней острой палочкой проводили линии и в получившихся колонках передвигали (как на счётах) камешки и кости для арифметических вычислений. В Древ-
нем Риме абак назывался calculi или abaculi. От этого слова произошло в дальнейшем латинское calculatore (вычислять) и calculus (исчисление), а затем и русское - калькуляция.
С конца XV столетия в Западной Европе получил распространение абак, известный как «счет на линиях». На разлинованную таблицу выкладывались специальные жетоны; горизонтальные линии таблицы соответствовали единицам, десяткам и т.д., вертикальные линии образовывали столбцы для отдельных слагаемых или множителей. «Счет на линиях» вспоминали герои Шекспира, а Мольер заставлял своего «мнимого больного» проверять счета аптекаря, раскладывая на столе жетоны.
Изобретение шотландским математиком Джоном Неппером (1550-1617) логарифмов послужило основой для замечательного вычислительного инструмента, почти 400 лет использовавшегося инженерами всего мира, - логарифмической линейки, и явилось важным вкладом в развитие передачи данных и компьютерной индустрии.
Суммирующую машину для выполнения операций сложения и вычитания впервые изобрел и сконструировал в 1623 году в Германии профессор математики и астрономии Тюбингенского университета В. Шиккард (1592-1636). Машина Шиккарда, изготовленная в одном экземпляре, сгорела во время пожара в начале 1624 года. Остались лишь ее эскизы, сделанные самим изобретателем. Машина не оказала влияния на развитие счетной техники, и поэтому биография механических счетных машин ведется обычно от суммирующей машины французского математика и философа Блеза Паскаля. Машина Паскаля представлена на рис. 2.3. Она состояла из ряда шестеренок, дисков и механического «экрана». При повороте дисков, расположенных в разных местах, поворачивались соответствующие шестеренки, в результате чего на «экране» отображался результат. Кстати говоря, этот же самый метод и по сей день используется во многих других машинах.
Рис. 2.3 Суммирующая машина Паскаля (1642 г.)
История создания суммирующей машины связана с тем, что в 1640 году Этьен Паскаль, отец знаменитого ученого, был назначен в Руан на должность интенданта. Семнадцатилетний Блез помогал отцу в подсчетах налоговых сборов, и, видя, как утомляют отца громоздкие вычисления, решил создать арифметическую машину- механического помощника в этой трудоемкой работе, что и сделал в 1642 году. Вот что сказал тогда Блез Паскаль: «Я представляю на суд публики изобретенную мною машинку, с помощью которой вы сможете, без каких-либо усилий, выполнять все арифметические действия и избавитесь от работы, которая нередко вас угнетает». Принцип этой машины до последнего времени применялся во всех арифмометрах. Изобретатель организовал свое предприятие и несколько лет занимался продажей счетных машин. Всего, по мнению историков, на его предприятии было создано немногим более пятидесяти моделей. Одна из них в настоящее время находится в музее крупнейшей американской электронной корпорации IBM, другая - в музее города Дрездена. Пять машин находятся у частных коллекционеров.
Следующим поколением компьютеров явились счетные машины, предназначенные для выполнения всех четырех арифметических действий (арифмометры). Первая такая машина была предложена в 1670 году великим немецким математиком, философом, физиком и языковедом Лейбницем. Готфрид Вильгельм Лейбниц родился в 1646 г. в Лейпциге, в семье, известной своими учеными и политическими деятелями. В возрасте 15 лет он уже поступил в Лейпцигский университет, а в 20 лет Лейбницу предложили должность профессора в Нюрнбергском университете. Он отклонил это предложение, предпочтя жизни ученого дипломатическую карьеру. Однако пока он разъезжал в карете из одной европейской столицы в другую, его беспокойный ум терзали всевозможные вопросы из самых разных областей науки и философии - от этики до гидравлики и астрономии. В 1672 г, находясь в Париже, Лейбниц познакомился с голландским математиком и астрономом Христианом Гюйгенсом. Именно огромные объемы вычислений в астрономии побудили Лейбница изобрести механический калькулятор для людей этой профессии, «поскольку, -как писал сам Лейбниц, - недостойно таких замечательных людей, подобно рабам, терять время на вычислительную работу, которую можно было бы доверить кому угодно при использовании машины». В 1673 г. появился механический калькулятор, представленный на рис.2.4. Лейбниц включил в конструкцию движущуюся часть (прообраз подвижной каретки будущих настольных калькуляторов) и ручку, с помощью которой можно было крутить зубчатые колеса, расположенные внутри аппарата. Этот механизм с движущимся элементом позволял ускорить повторяющиеся операции сложения, необходимые для умножения и деления чисел. Лейбниц продемонстрировал свою машину во Французской академии наук и в Лондонском королевском
обществе. Один экземпляр машины Лейбница попал к Петру I, который подарил ее китайскому императору, желая поразить того европейскими техническими достижениями.
Рис. 2.4 Калькулятор Лейбница (1673 г)
Итальянскому математику и физику Д. Полени (1683-1761) принадлежит идея применения зубчатого колеса с переменным числом зубцов. Она получила воплощение в арифмометре петербургского механика В.Т Однера. Прямые потомки арифмометров Однера - арифмометры «Феликс», которые совсем не так давно работали во многих учреждениях.
Другая суммирующая машина в России была, как гласит надпись на ней, «изобретена и изготовлена около 1770 года в Беларуси Ев- ной Якобсоном, часовым мастером и механиком в городе Несвиже».
Весьма удачная конструкция клавишной суммирующей машины была предложена в 1885 году 24-летним американским механиком Д. Фельтом. Изобретатель назвал ее комптометром.
В 1885 году механик из Сан-Луиса У. Бэрроуз закончил работу над бухгалтерской машиной, которая печатала вводимые числа, суммировала их, а затем выдавала результат.
Автоматизировать вычисления одним из первых попытался английский ученый и инженер Чарльз Бэббидж. Родившийся в 1791 г. в графстве Девоншир в богатой семье, Бэббидж прославился как остротой ума, так и своими чудачествами. Одним из таких чудачеств была порожденная стремлением к безукоризненной математической точности тотальная война Бэббиджа против ошибок в таблицах логарифмов, которыми широко пользовались при вычислениях астрономы, математики и штурманы дальнего плавания. В 1820 году Бэббидж предложил специализированную машину, предназначенную для табулирования функций по методу разностей. В 1822 г. он построил пробную модель своей разностной машины, состоявшую из шестеренок и валиков, вращаемых вручную при помощи специального рычага (рис.2.5). Затем, по ходатайству Королевского общества, Британское правительство предоставило Бэббиджу субсидию в 1500 фунтов стерлингов для создания полномасштабной работающей машины. Как писал Бэббидж президенту Королевского общества, «эта машина возьмет на себя невыносимо утомительную работу», неиз-
бежную при многократно повторяющихся математических расчетах, которые «представляют собой самое низкое занятие, не достойное человеческого интеллекта».
Рис. 2.5 Разностная машина Чарльза Бэббиджа (1822 г.)
Бэббиджу удалось построить лишь часть разностной машины, но основываясь на его идеях, подобные машины построили: в Швеции - отец и сын Георг и Эдвард Шютцы (1854), в США - Д. Грант (1876), в Германии - X. Гаманн (1909). Примечательно, что шведский издатель, изобретатель и переводчик Георг Шютц при строительстве слегка видоизмененного варианта разностной машины пользовался ценными советами Бэббиджа. Построенная Шютцами машина успешно прошла испытания в 1854 匚 в Лондоне, а годом позже разностная машина была удостоена золотой медали на Всемирной выставке в Париже.
В 1834 году Бэббидж предложил универсальную вычислительную машину с программным управлением, которую назвал аналитической. Аналитическая машина Чарльза Бэббиджа к моменту смерти ее создателя в 1871 году осталась незавершенной. Архитектура этой машины была весьма примечательна и совпадала, по существу, со структурой современных ЭВМ первых двух поколений. В ее проекте предусматривались операции с точностью до 40 десятичных разрядов, использовался перфокарточный ввод программ и данных, была заложена возможность создавать программные циклы и условные переходы, результаты выводились на принтер. Все это очень напоминает современные ЭВМ, но разработка Бэббиджа была полностью механической. Однако работа над машиной не была закончена, и имя Бэббиджа оказалось на долгие годы забытым. Объяснением этому может служить то обстоятельство, что хотя машины Бэббиджа исто-
рически были важным достижением, все же они не являлись предшественниками современного компьютера. Сделать его машину практически полезным устройством могла бы вакуумная лампа, которая была изобретена только в 1906 году. Более известный след в истории компьютеров оставил другой связанный с аналитической машиной факт: ассистентка Чарльза Бэббиджа графиня Ада Лавлэйс -дочь поэта лорда Байрона и первый в истории человечества программист - отдала все свои незаурядные математические и литературные способности осуществлению проекта Бэббиджа и составила программу для его аналитической машины. А язык программирования «Ада», созданный спустя полтора века в 1979 году, был назван так в ее честь.
Вычислительными машинами занимался и известный русский математик Пафнутий Львович Чебышев (1821-1894), Среди многочисленных изобретенных им механизмов имеется арифмометр, сконструированный в 1876 году. Это была одна из самых оригинальных вычислительных машин того времени.
Возвращаясь к уже упоминавшимся выше в этом параграфе достижениям Готфрида Вильгельма Лейбница, следует отметить, что гораздо больше, чем механический калькулятор, его прославили математические труды. В 1666 г, заканчивая учебу в университете - еще задолго до изобретения механического калькулятора, - двадцатилетний Лейбниц написал работу «Искусство составления комбинаций» (De Arte Combinatoria), которую скромно охарактеризовал как «сочинение школьника». В этой работе были заложены основы общего метода, позволяющего свести человеческую мысль - любого вида и на любую тему - к совершенно точным формальным высказываниям. Однако, при всей своей гениальности, Лейбниц так и не смог найти полезного применения полученным результатам. Изобретенный им механический калькулятор предназначался для работы с десятичными числами, и Лейбницне стал переделывать его под двоичные числа, возможно, устрашившись очень длинных цепочек двоичных разрядов, необходимыхдля представления чисел.
Более чем через сто лет после смерти Лейбница (он умер в 1716 году) английский математик Джордж Буль энергично принялся за поиски такого универсального формального языка. В 1847 匚 Буль написал важную статью на тему «Математический анализ логики», а в 1854 匚 развил свои идеи в работе под названием «Исследование законов мышления», Буль изобрел своеобразную алгебру - систему обозначений и правил, применимую ко всевозможным объектам, от чисел и букв до предложений. Пользуясь этой системой, Буль мог кодировать высказывания (утверждения, истинность или ложность которых требовалось доказать) с помощью символов своего языка, азатем манипулировать ими подобно тому, как в математике манипулируют обычными числами.
Три основные операции булевой алгебры - И, ИЛИ и НЕ, а другие операции, согласно системе Буля, получаются из этих трех логическими действиями. Трех основных операций вполне достаточно для того, чтобы производить сложение, вычитание, умножение и деление или выполнять такие операции, как сравнение символов и чисел. Логические действия двоичны по своей сути: они оперируют лишь парами понятий - «истина» или «ложь», «да» или «нет», «О» или «1». Алгебра Буля стала фундаментом применения в вычислительных машинах двоичной системы счисления и современных логических схем. Многое из того, что сегодня изучает цифровая электроника, является результатом вклада, внесенного булевой алгеброй. Эти результаты, в совокупности с диаграммами Джона Венна, привели, в частности, к первым компьютерным алгоритмам, которые были опубликованы в 1886 в книге «Игра логики» R Доджсоном, гораздо более известным под псевдонимом Люис Кэррол благодаря другой своей книге «Приключения Алисы в Стране Чудес».
Рис. 2.6 Табулятор Холлерита для обработки перфокарт (1890 г)Рис. 2.6 Табулятор Холлерита для обработки перфокарт (1890 г)Е .!:£ JU、, г А'"', ,н^广 ":三二二♦二е!,Е .!:£ JU、, г А'"', ,н^广 ":三二二♦二е!,
Рис. 2.6 Табулятор Холлерита для обработки перфокарт (1890 г)
Рис. 2.6 Табулятор Холлерита для обработки перфокарт (1890 г)
Е .!:£ JU、, г А'"', ,н^广 ":三二二♦二е!,
Е .!:£ JU、, г А'"', ,н^广 ":三二二♦二е!,
Важный шаг на пути автоматизации вычислений был сделан американским инженером Германом Холлеритом. Холлерит родился в Буффало (штат Нью-Йорк) в семье немецких эмигрантов. По окончании Горной школы при Колумбийском университете он был принят статистическим управлением Министерства внутренних дел США на работу в контору по переписи населения в Вашингтоне. Это случилось как раз в то время, когда сотни служащих приступили к исключительно трудоемкой (занявшей семь с половиной лет) ручной обработке данных, собранных при переписи населения в 1880 匚
Здесь он встретился с доктором Джоном Шоу Биллингсом, возглавлявшим работы по составлению сводных данных. Биллингс навел Холлерита на мысль о возможности создать машины для выполнения чисто механической работы, сопутствующей статистической обработке данных. Именно Биллингс, в будущем тесть Холлерита, высказал мысль, что табуляцию можно производить при помощи перфокарт, и Холлерит провел значительную часть последовавшего за этим десятилетия в попытках разработать такую систему. Свою первую машину, табулятор, он создал для облегчен ия подсчетов при переписи населения, которая проводилась в США каждые 10 лет. В 1884 году Г. Холлерит обратился за патентом на свою «машину для переписи населения». В последовавшие затем годы ему было выдано более 30 патентов за работы в этой области. В результате итоги переписи 1890 г. были подведены всего за 6 недель. Данные о каждом жителе хранились на особой перфокарте.
Карты табулятора Холлерита были размером в долларовую бумажку. На карте имелось 12 рядов, в каждом из которых можно было пробить 20 отверстий, соответствующих таким данным как возраст, пол, месторождения, количество детей, семейное положение и прочим сведениям, включенным в вопросник переписи американского населения. Агенты, проводившие перепись, записывали ответы опрашиваемых в специальные формуляры. Заполненные формуляры отсылались в Вашингтон, где содержавшуюся в них информацию переносили на карты путем перфорирования. Затем перфокарты загружались в специальные устройства, соединенные стабуляционной машиной, где они нанизывались на ряды тонких игл (по одной игле на каждую из 240 перфорируемых позиций на карте).
В систему Холлерита входили сортировальная машина, табулятор и перфоратор. Клавишный перфоратор позволял оператору перфорировать около 100 отверстий в минуту, причем повторяющаяся информация (например, штат, округ) перфорировалась одновременно на нескольких картах. Сортировальная машина представляла собой несколько ящиков, каждый со своей крышкой. Карты продвигались между набором штырей, насаженных на пружины, и резервуаром, наполненным ртутью. Как только штырь попадал в отверстие, он касался ртути и замыкал электрическую цепь. При этом приподнималась крышка на соответствующем ящике, куда и попадала карта. Табулятор работал аналогично сортировальной машине стой лишь разницей, что когда штырь попадал в отверстие перфокарты, замыкалась цепь тока, и счетчик передвигался на одно деление.
Холлерит был удостоен нескольких премий, получил немало похвал и звание профессора в Колумбийском университете. «Этот аппарат, -восхищенно писал журнал Electrical Engineer, - работает так же безошибочно, как машины бессмертных богов, но намного превосходит их по быстродействию». Холлерит с гордостью называл
себя «первым инженером-статистиком», впрочем, так оно и было на самом деле. Он организовал фирму по производству табуляцион- ных машин «Тэбьюлейтинг машин ком пани» (Tabulating Machine Company) и продавал их железнодорожным управлениям и правительственным учреждениям. Машины Холлерита закупила и Россия, решив провести перепись населения на современном уровне.
Между прочим, сама идея разработки перфокарты появилась у Холлерита в поезде, когда он обратил внимание на кондуктора, который с помощью ручного компостера заносил в какой-то бланк данные о пассажирах. А дальнейшая судьба этого изобретения представлена на рис.2.7. На изображенной там перфокарте IBM размещено 80 колонок, пронумерованных слева направо от 1 до 80, и 12 строк, которым присвоены номера сверху вниз. Прямоугольные отверстия могут быть отперфорированы в любой из 80 х 12 = 960 позиций на карте. Пробивки в каждой колонке карты представляют один из множества символов (цифр, букв и специальных символов). На рис.2.7 показаны комбинации пробивок (коды) для тех 64 символов, включая пробел, которые обычно используются при работе с перфокартами. Однако существуют коды для представления 256 различных символов.
/0123456789 ABCDEFGHIJKLMMDPGRSTUVUXYZ &~,С. <《+1 !$羅:> ;г ,N_>? : #审・="\
/IIIIHIIII llllll
ПИШИI llllll
IOOO|f 0010( IfOOeOOIOHHODfOfOlfIlf l|||g||||OOOOD DfgOOI 1 0 0 0 0 0 1 1 0||||||l 01 I I I I 000
I 1 ) < 1 I I I I li 11 >1 11 II IS 11 I) H H N II n О M Л 111! Л Л M II u n и n м » u Л N II ц a u ц H «1 11 и м и м » м M я » н н м w u u м « u i> u и я >1 >1 t) 11 ь ч tj n )1 и intt|timttiitii|itiMtit|itiimiiiiimiiMiiii|ittiiiiiiiiiiii!ttiiiiiittii и2222|222222222222122222222|2222222|222222222222222|2П22|Ш22|22222|22П32222 ]ЗИПЗ|]33]ИПШ]|ПП]]]]|ЗПИ2]|]ПИП]]]]3]3]|]ЗЗИ|Ш]11]]ЗП|ЗиЗ]И] U444444|444444444444|44444444|4444I44|4444444H444444|44444|44444S44444|4444444 555555555|555555555555|5555П55|5555555|555555555555555|55555|55$55|55555|555555 6 “ 6M66“・“““““・“16$“力6 “6“ 6“6Г“,666
77)7222)117|7177!7177?73|/2777177|7171))1|717)2771)711777|77777|77717|17777|7771
I OOOOOOOOIIIO|lOOOOOtIOIOO|OOIOIItI|lItOOII|tIIII 0 0 0 lllllllllllllllllllllllllI о I о 1
IIftt0fllfIfl|l)0IDDflII))|)))))))l|)))I)I)|)III9III)IIIIIIII)ll)JJIIII)IIIJIlll
I 1 1 < 5 S I I ) 11 II 11 >] .4 1> 11 It X >1 N 11 :1 Л » n 1M> Я П ■ II !: 11 U U X и Х И «Ml l> II U <N «> u H Nil 11 >1 M 1> U » U 59 II |1 l> U W I! H P Ы II ;l)1 1] 1) И П Ц И II )1 It ^ N.C. CO. 90«lVHlhTEO <N U S. *. J
Рис. 2.7 Перфокарта IBM
Столь подробное описание обусловлено отнюдь не только пристальным вниманием к рассмотренной технологии, порожденным спорами о достоверности пересчета перфокарт с голосами избирателей штата Флорида, которые были поданы за одного из двух кандидатов в президенты США на выборах 2000 года (эти споры шли как раз тогда, когда писалась данная глава). Оно связано и с дальнейшей судьбой самого Германа Холлерита на рубеже двух предыдущих веков. Созданная в 1896 году компания Холлерита с годами претерпела ряд изменений - слияний и переименований. В 1911 году она была продана другой фирме, которая вскоре, слившись с другими, образовала Computing-Tabulating Recording Со. Последнее измене-
ние произошло в 1924匚,за 5 лет до смерти Холлерита, когда он создал корпорацию IBM (International Business Machines Corporation), крупнейшую в мире промышленную фирму, которая смогла воплотить в жизнь мечту Чарльза Бэббиджа о «машине самого универсального характера». Авторам не удалось разыскать изображение перфоратора машины Холлерита, но на рис.2.8 представлен перфоратор системы IBM-360, не имеющий принципиальных отличий от изобретения начала XX века. Основные элементы этого перфоратора: 1 - клавиатура; 2 - переключатели управления; 3 - пункт перфорации; 4 - ключ возврата на шаг; 5 - пункт чтения; 6 - карточный приемный карман; 7 - блокировка переполнения приемного кармана; 8 -программное устройство; 9 - рычаг подъема прижимного ролика; 10 - карточный магазин; 11 - печатающий механизм; 12-рычаг прижима карты.
10
Рис. 2.8 Клавишный перфоратор IBM-029
Значительный вклад в историю современной вычислительной техники внес Клод Шэннон, который работал в Bell Telephone Laboratories с 1941 года после получения им степени доктора в Массачусетском технологическом институте (Massachusetts Institute of Technology). Заметим сразу же, что сам по себе этот факт, в числе многих других, свидетельствует о том, что компьютеры и телефония никогда не были далеки друг от друга. Снискавший большую известность своими работами по теории информации и, в частности, основополагающей «Математической теорией связи», Шэннон сумел, кроме этого, показать, как можно использовать электрические схемы для сложения, вычитания, умножения и т.д. Он также привлек внимание специалистов к тому факту, что схемы очень упрощаются при использовании двоичной системы. Именно объединение электроники и двоичной системы счисления знаменует начало разви-
тия современного цифрового компьютера. Приблизительно в то же время, когда Шэннон опубликовал свою знаменитую работу, другой сотрудник Bell Labs разработал первый двоичный сумматор - существенный элемент любого цифрового компьютера. Имя этого человека - Джордж Штибиц. В 1940 году он продемонстрировал простейший компьютер, работающий через линию связи (еще один предвестник компьютерной телефонии). В Dartmouth College Дж. Штиблиц объяснял и демонстрировал использование калькулятора, впервые разработанного Bell Telephone Laboratories. Калькулятор находился в Нью-Йорк Сити, а связь с ним осуществлялась по стандартным телефонным линиям.
В это же время и в Германии началась работа над машинами, в которых все логические и арифметические операции выполнялись с помощью реле. Немецкий инженер Конрад Цузе в 1941 году закончил первую в мире универсальную автоматическую цифровую вычислительную машину (ЦВМ) с программным управлением, которую он назвал Z3 (по-немецки его фамилия пишется Zuse). Результаты вычислений высвечивались на панели с множеством маленьких лампочек, а для ввода данных, наряду с клавиатурой ( Цузе придумал весьма остроумное и дешевое устройство, в котором инструкции для машины кодировались с помощью отверстий, пробиваемых в использованной 35-миллиметровой фотопленке. В 1942 匚 Цузе и австрийский инженер-электрик Хельмут Шрайер предложили создать компьютер принципиально нового типа. Они задумали перевести машину Z3 с электромеханических реле на вакуумные электронные лампы. Машина, задуманная Цузе и Шрайером, должна была работать в тысячу раз быстрее, чем любая из машин, имевшихся в то время в Германии. Но шла война, Гитлер, уверенный в быстрой победе, наложил запрет на все долговременные научные разработки, и этим планам не суждено было осуществиться. Тем не менее, стараниями Цузе и его коллег - пионеров вычислительной техники по обе стороны Атлантического океана - не только перфоленты, но и само предложенное Лейбницем двоичное представление информации, в конце концов, были положены в основу вычислительных машин.
Этому способствовало принципиально отличное от ситуации в Берлине отношение английского правительства к проекту «Ультра», целью которого был поиск способов расшифровки секретных немецких кодов. Идея проекта «Ультра» зародилась после весьма успешной операции, проведенной польской разведкой. Еще до оккупации Польши Германией в 1939 匚,поляки умудрились создать точную копию немецкого шифровального аппарата «Загадка» и переправить его в Англию вместе с описанием принципа работы. Без ключа схемы коммутации (их немцы меняли три раза в день) даже использование в качестве приемника копии устройства типа «Загадка» было бесполезно. В надежде раскрыть секрет «Загадки», британская развед-
ка собрала и поселила в Блетчли-Парке, обширном имении викторианской эпохи, расположенном неподалеку от Лондона, группу блестящих ученых, изолировав их от остального мира. В эту группу входил и математик из Кембриджского университета Алан Тьюринг О чудачествах Тьюринга ходили легенды. Говорили, что в бытность свою в Кембридже он никогда не ставил часы по сигналам точного времени и ни у кого не спрашивал, который час, а отмечая положение определенной звезды, вычислял время в уме. В 1936 г., в возрасте 24 лет, он написал работу, которой суждено было сыграть исключительно важную роль в развитии вычислительной математики и информатики. Работа касалась очень трудной проблемы математической логики 一 описания задач, которые не удалось решить даже теоретически. Пытаясь найти такое описание, Тьюринг использовал в качестве вспомогательного средства мощное, хотя и существовавшее лишь в его воображении, вычислительное устройство, в котором он предвосхитил ключевые свойства современного компьютера. Тьюринг назвал свое абстрактное механическое устройство «универсальной машиной», поскольку оно должно было справляться с любой допустимой, то есть теоретически разрешимой, задачей 一 математической или логической. Данные должны были вводиться в машину с бумажной ленты, поделенной на клетки-ячейки. Каждая такая ячей- калибо содержала символ, либо была пустой. Машина могла не только обрабатывать записанные на ленте символы, но и изменять их, стирая старые и записывая новые в соответствии с инструкциями, хранимыми в ее внутренней памяти. Некоторые идеи Тьюринга были, в конечном счете, воплощены в реальных машинах, построенных в Блетчли-Парке.
Строго говоря, электромеханические машины для вычислений с помощью перфокарт или перфолент назывались тогда счетно-аналитическими машинами. Механические и электромеханические элементы счетно-аналитических машин были использованы американским физиком Хауэр дом Эйкеном при создании вычислительной машины с автоматическим управлением последовательностью операций (АСКК), больше известной под названием «Марк-1». Проект финансировался IBM и впервые демонстрировался в 1943 году.
Этот проект стал поворотным моментом в революционном изменении фирмы IBM, которая первоначально была ориентирована на производство таких изделий, как пишущие машинки, настольные калькуляторы итабуляционные машины, подобные машине Германа Холлерита. Директор IBM Уотсон начинал карьеру, торгуя кассовыми аппаратами для магазинов, и постепенно превратил свою компанию в концерн с многомиллионным оборотом. О талантах этого, безусловно, выдающегося человека, в котором сочетались интуиция, позволявшая улавливать наиболее перспективные направления технического развития, и талант предпринимателя, написано немало.
Наиболее известным, вероятно, является придуманный им лозунг «Think!». Таблички с этим призывом долго украшали кабинеты, причем не только в IBM. Почти так же широко известны его требования предельной аккуратности от сотрудников, включая обязательное ношение тщательно выглаженных белых сорочек.
Разработка машины «Марк-1» к началу 1943 匚 была доведена до первых успешных испытаний, после чего она была передана в Гарвардский университет. «Марк-1», достигавший в длину почти 17 м, а в высоту 一 более 2,5м, содержал примерно 750 тыс. деталей, соединенных проводами, общая протяженность которых составляла около 800 км. Машина использовалась для выполнения сложных баллистических расчетов, руководил которыми сам ее изобретатель Эйкен. «Марк-1» мог обрабатывать числа длиной до 23 разрядов. На сложение и вычитание тратилось 0,3 с, а на умножение - 3 с, что позволяло выполнить за день вычисления, на которые раньше уходило полгода. Такое быстродействие было беспрецедентным для того времени, и «Марк-1» активно работал в Гарвардском университете еще 16 лет.
Вместе с тем, еще в процессе разработки «Марк-1» стало ясно, что заложенные в него принципы начали устаревать, что более перспективным стало применение электронных вакуумныхламп вместо электромеханических реле. В конце 1943 г: в Блетчли-Парке сумели построить машину, содержавшую 2000 электровакуумных ламп. Англичане назвали новую машину «Колосс». Возможно, это был самый первый полностью электронный компьютер. Его проектировала команда, в состав которой входил один из наиболее известных в мире вычислительной техники людей - Алан Тюринп Создание «Колосса» имело определенную цель: взломать секретные германские коды, использовавшиеся во время второй мировой войны. Сконструированный в обстановке секретности в British Post Office research station, он оказался очень удачным. Основанный на электронных лампах и использующий высокоскоростное устройство ввода с перфокарт, он работал в тысячу раз быстрее, чем электромеханический «Марк-1». Да и разработка эта отличалась от разработки «Марк-1» узкой специализацией машины: применение «Колосса», как уже было сказано, ограничивалось исключительно расшифровкой секретных кодов. Использование вакуумных ламп ознаменовало крупный шаг вперед в развитии вычислительной техники. Размеры этой ЭВМ первого поколения получились весьма внушительными: 40 панелей, содержащих 18000 электронных ламп и 1500 реле. И хотя срок службы каждой лампы составлял 2000 ч, ЭВМ работала с постоянными сбоями: в среднем, каждые 6 минут одна из ламп выходила из строя. К тому же, аппаратура занимала площадь огромного цеха и потребляла столько электроэнергии, сколько потребляет небольшой завод. На операцию сложения ЭВМ тратила 0.0002 с, на умножение - 0.0028 с.
Рис. 2.9 Английская машина "Колосс" (1943) для расшифровки немецких кодов
Те же потребности военного времени стимулировали разработку в Филадельфии, США, другой машины, которая по принципу работы и применению была уже ближе к теоретической универсальной ма- шинеТьюринга. Машина «Эниак» (ENIAC, аббревиатура от Electronic Numerical Integrator and Computer 一 электронный цифровой интегратор и вычислитель), подобно «Марку-1» Говарда Эйкена, предназна- чаласьдля решения задач баллистики. Но в итоге она оказалась способной решать задачи из самых разных областей. Авторами проекта были двое сотрудников вычислительного центра Высшего технического училища Пенсильванского университета Джон У. Мочли и Дж. Преспер Экерт.
Рис. 2.10 Первая ЭВМ '*Эниак"Дж.Экерта и Дж.Мочли (1946)
Джон Мочли, физик и метеоролог; занимался созданием машины, которая позволила бы применить статистические методы для прогнозирования погоды. Еще перед Второй мировой войной он смастерил несколько простых цифровых счетных устройств на электрон- ныхлампах. Возможно, интерес к электронным вычислительным машинам возник у него под влиянием идей американского физика болгарского происхождения Джона Атанасоффа, работавшего в штате Айова. В январе 1938 с, после двух лет раздумий об оптимальной конструкции компьютера, Атанасофф решил создавать машину на основе двоичной, а не десятичной системы счисления. Атанасофф сконструировал машину для решения систем алгебраических уравнений. К концу 1941 года почти все ее блоки были изготовлены, однако дальнейшую работу над ней приостановили.
В июне 1941 г Мочли в течение пяти дней гостил у Атанасоффа, наблюдая, как тот, вместе со своим помощником Клиффордом Берри, трудился над прототипом компьютера, содержавшим около 300 электронных ламп. Вопрос о том, насколько значительным было влияние Атанасоффа, позже перерос в судебное разбирательство, но, так или иначе, сам этот факт имел место.
Дж. П. Экерт еще в возрасте восьми лет построил миниатюрный приемник и не растратил с годами инженерный талант. Именно он убедил Мочли, что его мечты о компьютере можно осуществить на практике. В августе 1942 匚 Мочли написал заявку на пяти страничках, где вкратце изложил их совместное с Экертом предложение о создании быстродействующего компьютера на электронных лампах, но эта заявка затерялась в инстанциях, как это не раз встречалось и в истории отечественной компьютерной техники.
Однако Мочли и Экерту повезло больше, чем их заокеанским коллегам: спустя несколько месяцев прикомандированный к училищу военный представитель лейтенант Герман Голдстейн случайно услышал об этой идее. В то время армия крайне нуждалась в новых баллистических таблицах. Артиллеристы сообщали из Северной Африки, что из-за очень мягкого грунта орудия далеко откатываются при отдаче и снаряды не достигают цели.
Голдстейн, до войны преподававший математику в Мичиганском университете, сразу же оценил значение предлагаемого проекта компьютера и начал хлопотать от имени военного командования, чтобы проект приняли к разработке. Наконец, 9 апреля 1943 г. - в день, когда Экерту исполнилось 24 года, ~ армия заключила с училищем контракт на 400 тыс. долларов, предусматривавший создание компьютера ЭНИАК. Конструкция машины казалась фантастически сложной -предполагалось, что она будет содержать 17468 ламп.
В конце 1945 г. ЭНИАК был собран и подвергнут первому официальному испытанию, которое он успешно выдержал, обработав око-
ло миллиона перфокарт фирмы IBM. По своим размерам (около 6 м в высоту и 26 м в длину) этот компьютер более чем вдвое превосходил «Марк-1» Говарда Эйкена, однако двойное увеличение размера сопровождалось тысячекратным увеличением быстродействия. Война, нуждам которой был призван служить ЭНИАК, к этому времени закончилась, но уже надвигались годы «холодной войны». Поэтому задача, выбранная для проверки машины, - расчеты, которые должны были ответить на вопрос о принципиальной возможности создания водородной бомбы, - указывала на то, что роль компьютеров в послевоенные годы скорее возрастает, чем снижается. Сама же машина ЭНИАК оказалась самой знаменитой из компьютеров и многократно описывалась в научной фантастике.
Следующая модель ~ машина ЭДВАК (EDVAC, от Electronic Discrete Variable Automatic Computer 一 электронный дискретный переменный компьютер) 一 была еще более гибкой. Ее более вместительная внутренняя память содержала не только данные, но и программу. Алгоритмы вычислений теперь не «зашивались» в схемы аппаратуры, а записывались электронным способом в специальные устройства памяти. ЭДВАК кодировал данные не в десятичной системе, а в двоичной, что позволило значительно сократить количество электронных ламп.
Когда Мочли и Экерт трудились над машиной ЭДВАК, способной хранить программы в памяти, в их группу был назначен блестящий и уже известный математик Джон фон Нейман, оказавший затем огромное влияние на развитие вычислительной техники в послевоенные годы. Родом из Венгрии, сын преуспевающего будапештского банкира, фон Нейман был продуктом той интеллектуальной среды, из которой вышли такие выдающиеся физики, как Эдвард Теллер, Лео Сциллард и Деннис Габор. В восемь лет он освоил основы высшей математики, а в возрасте 20-30 лет, занимаясь преподавательской работой в Германии, внес значительный вклад в развитие квантовой механики и разработал теорию игр, которая нашла широчайшее применение - от экономики до военной стратегии.
Меньше чем через год после того, как фон Нейман присоединился к группе Мочли и Экерта, он подготовил отчет на 101 странице, в котором обобщил планы работы над машиной ЭДВАК. Этот отчет, озаглавленный «Предварительный доклад о машине ЭДВАК» представлял собой прекрасное описание не только самой машины, но и ее логических свойств. На Германа Голдстейна, военного представителя, предложившего фон Нейману принять участие в проекте, доклад произвел очень сильное впечатление. Прежде всего, это было связано с тем, что фон Нейман, отвлекшись от радиоламп и электрических схем, сумел строго описать формальную, логическую организацию компьютера. Размножив доклад, Голдстейн разослал его ученым США и Великобритании.
Благодаря этому «Предварительный доклад» фон Неймана стал первой работой по цифровым электронным компьютерам, с которой познакомились широкие круги научной общественности. Доклад передавали из рук в руки, из лаборатории в лабораторию, из университета в университет, из одной страны в другую. Эта работа обратила на себя особое внимание, поскольку фон Нейман пользовался широкой известностью в ученом мире. С того момента компьютер был признан объектом, представляющим научный интерес. Ученые и по сей день иногда называют компьютер «машиной фон Неймана». Читатели «Предварительного доклада» были склонны полагать, что все содержавшиеся в нем идеи, в частности, принципиально важное решение хранить программы в памяти компьютера, исходили от самого фон Неймана. Мало кто знал, что Мочли и Экерт говорили о программах, записанных в памяти, по меньшей мере, за пол года до появления фон Неймана в их рабочей группе; большинству неведомо было и то, что Алан Тьюринг, описывая свою гипотетическую универсальную машину еще в 1936 匚,наделил ее внутренней памятью. В действительности, фон Нейман читал классическую работу Тьюринга и лично познакомился с ее автором, когда тот незадолго до войны посетил Принстон.
Джон Мочли и Преспер Экерт организовали в Филадельфии собственную компанию, разместившись в помещении бывшего танцевального клуба. Они задалисыделью создать универсальный компьютер для широкого коммерческого применения. Машина ЮНИВАК (UNIVAC, от Universal Automatic Computer - универсальный автоматический компьютер) представляла собой электронное устройство с хранимыми в памяти программами, которые вводились туда уже не с перфокарт, а с магнитной ленты; это обеспечивало высокую скорость чтения и записи информации. В 1950 г., примерно за год до того, как первый ЮНИВАК вступил в эксплуатацию в Бюро переписи населения США, партнеры оказались в тяжелом финансовом положении и вынуждены были продать свою компанию фирме по производству электробритв и табуляторов на перфокартах «Ремингтон Рэнд», получив при этом примерно по 300тыс. долларов, включая и выручку от продажи патентов на компьютер ЭНИАК.
Неоднократно упоминающиеся на страни цах этой книги знаменитые Bell Telephone Laboratories энергично занимались полупроводниками, способными заменить радиолампы и электромеханические реле, которые использовались как усилители и как переключатели в телефонных станциях, рассматривавшихся в предыдущем параграфе. Ключевыми фигурами в группе физиков твердого тела, перед которой стояла задача изучить свойства полупроводников, были Уолтер Браттейн, экспериментатор, и Джон Бардин, молодой талантливый теоретик, а также руководитель группы 35-летний Уильям Шокли. Сын горного инженера, Шокли родился в Лондоне, но вырос
в Пабло-Альто (Калифорния). В результатах их труда 一 полупровод- никовыхтриодах (а также их потомках-интегральных схемах)-крайне нуждались компьютеры для обеспечения надежной и экономичной вычислительной мощности. И в 1947 году Уильям Шокли, Уолтер Браттейн и Джон Бардин из Bell Telephone Laboratories создали небольшое устройство, которое они назвали транзистором и за которое были удостоены в 1956 匚 Нобелевской премии по физике. На смену ламповым (первое поколение) в конце 50-х пришли ЭВМ с полупроводниковыми и магнитными элементами, что принципиальным образом сказалось на габаритах и надежности. ЭВМ второго поколения стали работать без остановки 6 дней, хотя срок службы транзистора -миллионы часов. Теперь невысокая надежность ЭВМ объяснялась непрочностью пайки.
В апреле 1964 г представители IBM в 15 странах мира одновременно провели 77 пресс-конференций, объявив о создании целого семейства машин IBM-360 с официальным названием «Система 360», в которое входило шесть моделей, различавшихся мощностью и стоимостью. С позиций сегодняшнего дня решение о разработке «Системы-360» представляется естественным и почти неизбежным, однако в то время оно означало решительный отход от сложившихся в вычислительной технике стандартов, было весьма рискованным, встретило упорное сопротивление части сотрудников фирмы и поставило на карту весь капитал и само существование фирмы.
Почему же, все-таки, это произошло именно в компании IBM, известной своей дисциплиной и обязательными белоснежными рубашками сотрудников? Ответ, по мнению авторов, заключается в следующем тезисе управляющего IBM: «Каждая компания нуждается в истинных диссидентах. К счастью, в IBM никогда не переводились люди, отказывающиеся ходить строем». Но не только. По оценкам специалистов, на исследования, разработку и внедрение в производство одновременно шести машин IBM-360 компания затратила около 5 млрд, долларов, что вдвое превышало расходы США во время второй мировой войны на Манхэттенский проект, целью которого было создание атомной бомбы. Перенос этой разработки в Советский Союз для программы ЕС ЭВМ (речь, разумеется, идет о IBM-360, а неоМан- хэттенском проекте) потребовал, вероятно, гораздо меньших материальных затрат, но отнюдь не меньшего времени, что в период быстрой смены компьютерных технологий имело решающее значение.
В СССР тогда уже имелись существенные достижения в вычислительной технике. В 1950 году в Институте электротехники (Киев) под руководством академика Лебедева была построена первая ЭВМ - малая электронная счетная машина (МЭСМ), а в октябре 1951 года ее ввели в эксплуатацию. В МЭСМ использовалось 6000 электронных ламп, скорость ее работы составляла, в среднем, пятьдесят операций в секунду. Осенью 1952 года вступила в строй машина БЭСМ,
созданная в Институте точной механики и вычислительной техники. Она была в то время одной из самых быстродействующих машин в мире - выполняла, в среднем, 8 тыс. операций в секунду.
Первой машиной, запущенной в серию в 1953 г, стала «Стрела» (2 тыс. операций в секунду). Продолжалось также развитие малой электроники. В 60-е годы в СССР было разработано около 30 моделей полупроводниковых ЭВМ. Первая серийная машина на транзисторах вышла в 1961 году. В следующем году был начат выпуск «Проминя», а в 1963 году - машин серии «Минск». Быстродействие наиболее мощной из них, «Минск-32», - 65 тыс. операций в секунду. С 1964 года выпускались полупроводниковые «Уралы», БЭСМ-4 и М220. В 1966 году в Институте точной механики и вычислительной техники была построена машина БЭСМ-6, выполнявшая уже миллион операций в секунду. Машина была оборудована четырьмя независимыми пультами управления.
Однако феноменальный успех машин IBM 360 во всем мире, а также соблазн воспользоваться появившейся не вполне ясным путем (и с не вполне осознававшимся тогда опозданием) технологией, не могли не повлиять на советских конструкторов вычислительных машин. В результате этого IBM 360 появилась у нас в качестве системы третьего поколения под именем ЕС ЭВМ. Минимальная стандартная конфигурация наиболее распространенной машины ЕС-1020 содержала: процессор с оперативным ЗУ емкостью 64 Кбайта; блок питания процессора; устройство управления НМЛ; сами НМЛ; устройство управления НМД; сменные НМД; устройство ввода информации с перфолент; устройство ввода информации с перфокарт; устройство вывода информации на перфоленты; устройство вывода информации на перфокарты; алфавитно-цифровое печатающее устройство; печатающее устройство на базе пишущей машинки «Консул-260» с блоком стандартного сопряжения с каналами передачи данных; устройство подготовки данных на перфоленте; устройство подготовки данных на перфокартах (рис.2.11).
Рис. 2.11 Общий вид ЭВМ ЕС-1020Рис. 2.11 Общий вид ЭВМ ЕС-1020
Рис. 2.11 Общий вид ЭВМ ЕС-1020
Рис. 2.11 Общий вид ЭВМ ЕС-1020
В 1975 г идея персонального компьютера 一 машины, находящейся в распоряжении одного человека, а не целого предприятия, — была лишь мечтой отдельных, наиболее ярых энтузиастов электроники.
Одна из первых персональных машин, получившая название Альтаир-8800, была построена на основе микропроцессора INTEL-8080. С самого начала машина имела огромный успех и принесла многомиллионные прибыли. Альтаир не был уроженцем Кремниевой долины-области западной Калифорнии, протянувшейся от Сан-Франциско до Сан-Хосе, которая стала почти синонимом полупроводниковой промышленности США. Его построил в Альбукерке (штат Нью- Мексико) молодой офицер ВВС США Робертс с дипломом инженера-электронщика, а описал 一 ведущий технический раздел журнала Popular Electronics Лесли Соломон в январском выпуске этого журнала за 1975 год. Именно Соломон поведал впоследствии о том, как возникло название машины, гораздо более привлекательное, чем название РЕ-8, которое Робертс хотел дать своему творению в честь упомянутогожурнала. Увидев, как его 12-летняя дочь увлеченно смотрит научно-фантастический телефильм «Звездный поход», Соломон решил назвать новую машину так же, как именовался ком пьютер «Энтерпрайза», межзвездного корабля из фильма. На это дочь возразила, что тот компьютер не имел названия, но предложила свое - «Альтаир», в честь звезды, к которой в фильме направлялся корабль.
Пол Аллен, молодой программист из Бостона, в содружестве со студентом Гарвардского университета Биллом Гейтсом, написал программу, реализующую для Альтаира популярный язык BASIC (Beginners All-Purpose Symbolic Instruction Code) 一 символический универсальный язык программирования для начинающих. Таким образом, владельцы компьютера получили очень удобный язык, значительно облегчивший составление программ. Когда Аллен приехал в Альбукерке, чтобы показать Робертсу свое творение, тот предложил ему создать и возглавить отдел программного обеспечения в своей фирме МИТС. Впоследствии Гейтс и Аллен основали собственную фирму Microsoft.
Затем еще две фирмы, Tandy Radio Shack (TRS) и Commodore International, выбились в лидеры по продаже микрокомпьютеров. Первая из них, TRS, владела в Техасе сетью магазинов, торговавших электронными деталями и комплектами для разнообразных устройств, от любительских радиоприемников до стереофонических проигрывателей, и имела возможность привлечь к своей продукции любителей электроники, мечтавших о собственном компьютере. В июле 1976 匚 компания заключила контракт со Стивеном Лейнинджером, инженером, работавшим до этого на предприятии National Semiconductor в Кремниевой долине. В течение следующих 6 месяцев Лей- нинджер с небольшой группой сотрудников в штаб-квартире фирмы TRS в Форт-Ворсе создали машину, способную конкурировать с Аль-
таиром. Лейнинджер, практически в одиночку, разработал не только архитектуру нового компьютера, но и его встроенное программное обеспечение. Первая модель TRS-80 была построена на основе но- вей山е「о микропроцессора Z-80 производства компании Zilog, весьма похожего на INTEL-8080, но с лучшими рабочими характеристиками. Для удобства ввода и вывода данных Лейнинджер соединил компьютер с телевизионным видеомонитором и клавишным устройством типа пишущей машинки, добавив также кассетный магнитофон, на котором были записаны программы и данные. Сколько раз, вслед за Лейнинджером, повторяли эти манипуляции многиетысячи российских энтузиастов - создателей своих собственных «Зайлогов».
Еще одна молодая компания со странным названием Apple Computers удивила финансовый мир, стремительно вторгшись в список крупнейших 500 американских фирм (Fortune 500), причем сделала это быстрее, чем какая-либо из компаний за всю историю существования списка. В течение пяти лет компания Apple Computer выросла из малого предприятия, почти не имевшего средств и состоявшего из двух студентов, которые бросили колледж и стали собирать компьютеры в одном из калифорнийских гаражей, в корпорацию с многомиллиардным капиталом, а основатели фирмы Стив (Стефен) Возняк и Стив (Стивен) Джобс стали легендой компьютерной индустрии, ле「ендой под названием «два Стива».
Оба Стива увлекались электроникой, жили в Лос-Анджелесе, ходили в одну школу и были друзьями. Возняк был четырьмя годами старше Джобса, которому в 1983 г., когда фирма Apple Computers вошла в список 500 крупнейших американских компаний, исполнилось лишь 27 лет. Оба они вначале работали в известных фирмах Кремниевой долины: Джобс программировал видеоигры для компании Atari, а Возняк был инженером в Hewlett Packard. В 1975 г., когда Возняк и Джобс решили создать собственный персональный компьютер, они, в лучших традициях российских радиолюбителей, вынесли нужные им детали со своих предприятий, что отмечалось их многочисленными биографами как неблаговидный поступок двух будущих миллионеров. Машина, продемонстрированная Возняком на одном из собраний клуба «Хоумбрю» осенью 1975 г., использовала новый микропроцессор 6502, который был значительно дешевле популярного процессора INTEL-8080, применявшегося в компьютерах Альтаир, - стоил он всего 20 долларов. Вскоре Возняк усовершенствовал конструкцию компьютера - это был шаг к знаменитой модели «Эпл-2», которую ожидал феноменальный успех.
Но уже в следующем году корпорация IBM изготовила свой персональный компьютер, IBM PC, с появлением которого началась новая эпоха в истории человечества, а также закончился период неформального любительского стиля работы, создававшего эту инду-
стрию на первых этапах. За удивительно короткое время, с середины 70-х до начала 80-х「одов, новая индустрия перекочевала из「а・ ражей хакеров в залы, где проходят совещания директоров корпораций. Закономерность зтопэ процесса подтверждают анало「ии из истории телефонии, рассмотренной в предыдущем пара「рафе.
Но нельзя не сказать еще о нескольких изобретателях, без которых не было бы IBM PC. Дуглас Инглбарт потратил 10 лет на разработку устройства, которое мно「ие из нас используют до сих пор. Ин「- лбарт осознавал необходимость соэаамия поибооя. паюищго пени- зователю возможность управлять компьютером без применения клавиатуры. «Мышь» появилась еще в 1968「оду, а впервые была использована как стандартный интерфейс компьютера Apple Computer's Macintosh в 1989「оду.
В 1971「оду от Алана Шу「арта к IBM пришел первый дисковод. Позднее 111у「арт ор「анизовал собственную компанию - Shugart Disk Drives. Это был первый накопитель на съемных дисках для персональных компьтеров, на начальной стадии он был 8-дюймовым и вмещал 300 Кбайтов данных.
В 1973「оду винчестер стал первым «жестким диском», применяемым для компьютеров. Объем е「о памяти был небольшим, но се「о- дня на 3,5-дюймовом жестком диске помещаются мно「ие десятки гигабайтов данных.
В 1978「оду Radio Shack и Shugart Industries разработали 5,25дюймовый 「ибкий диск; впоследствии разработки совершенствовались, и через 10 лет「ибкий диск уже вмещал скромное количество информации.
Влапэдаря Инглбарту и Шугарту, а также мно「им дру「им, не названным в этом кратком обзоре, за короткий период, прошедший с дебюта Альтаира до появления персонал ь>но「о компьютера IBM PC, к вычислительной технике приобщилось больше людей, чем за все предшествовавшие「одн - от момента возникновения первых, еще не вполне ясных, мыслей Чарльза Бэббиджа об Аналитической машине до момента изобретения инте「ральныхзлектроннь4хсхем. Персональные компьютеры, разумеется, претерпели существенные изменения за время своепэ победного шествия по планете, но они изменили и сам мир, создав, к тому же, многочисленные новые отрасли человеческой деятельности, включая и компьютерную телефонию, составляющую предмет данной кни「и.
История компьютерной телефонии
Первым устройством компьютерной телефонии, по всей вероятности, можно считать телефонный автоответчик, появившийся в США
в 1886 году. Это был и «говорящие часы»: снявтрубкутелефона, можно было раз в минуту услышать серию слабых щелчков, не мешавших разговору. Число щелчков означало час и минуту. '
Будапештское телефонное общество «Телефон-Хиромондо» в 1893 году ввело услугу передачи новостей по телефону, а по вечерам -даже целых концертных программ. Эти же услуги вскоре стали получать абоненты еще двух телефонных сетей - Лондонской «Элек- трофоун Компани» и Петербургской телефонной сети. Впрочем, еще в 1882 году телефон ная линия между Петербургом и Гатчиной использовалась как для переговоров высочайш их особ, так и для слушания опер из Мариинского театра.
Почти такая же долгая история и у прогнозов погоды по телефону. В 1902 году в ГТС города Льежа была введена услуга побудки по телефону, мало чем отличающаяся от сегодняшней.
Во Франции «говорящие часы» (уже - голосом) появились в 1936「о- ду. Затем, в 40-50-х годах, в Париже появилась телефонная служба последних известий и прогноза погоды. Далее в пеструю историю компьютерной телефонии включились аудиотекс и видеотекс. Обе технологии обеспечили доступ к информации баз данных, использовались в системах распространения билетов, приема заказов ит. п. Начался настоящий бум телефонных информационно-справочныхсистем. Существовали и существуют сегодня сотни таких систем с самыми разнообразными программами. Набирая определенные номера, по телефону можно прослушать детскую сказку или обзор печати, про「ноз погоды или церковную проповедь, юмореску или данные о загрязнении воздуха в городе, программы телевидения и кинотеатров, кулинарные рецепты, советы огородникам, краткие рецензии новых фильмов, гороскоп, песенку, результаты бегов, анекдоты,「орсщские слухи, расписание самолетов ит.д., и т.п.
В 1960-х и 1970-х годах насущными проблемами были вопросы внедрения в сферубизнеса компьютеров (мини-ЭВМ и больших ЭВМ) совместно со средствами телекоммуникаций. Первые реализации компьютерной телефонии в эти годы обеспечивал ведущий компьютерный производитель - корпорация IBM. Но и для IBM телефония была новым направлением деятельности. Разработки, ориентированные на телефонию, первоначально преследовали цель обойти ре「- ламентные препятствия на пути продвижения продуктов IBM, которые поставил Deutsche Bundespost. Речь шла об установке двух основных продуктов: рассмотренной в предыдущем параграфе универсальной ЭВМ «Система 360» и УАГС 2750 (360 mainframe и 2750 РАВХ). Связью между УАГС 2750 и IBM-360 служил канал телеобработки TPLH. Сообщения передавались по линии двоичной синхронной передачи (BSC) с использованием слегка модифицированного протокола удаленного ввода заданий 2780/3780,
Пример системы для крупнейшего книжного магазина Германии показан на рис.2.12. Канал TPLH использовался для управления УАТС из IBM-360. В определенное время, ночью, IBM-360 выбирала телефонный номер книжного магазина, затем давала команду УАТС 2750 установить соединение с этим номером для связи с приемником терминала в магазине. Приемник выполнял функцию модема. Он отвечал на вызов от УДГС и затем передавал введенные в терминал днем данные о наличии книг на полках и о требуемом их пополнении. Эти данные передавались многочастотным способом через УАТС в IBM-360 для обработки. Затем компьютер IBM-360 выбирал номер следующего магазина и извлекал оттуда книжные заказы. Таким образом, начиная работу на следующий день, компьютер IBM-360 распечатывал полный перечень заказов от всех книжных магазинов (вместе с адресами доставки), что позволяло заполнять полки книгами, которые были заказаны только накануне. Книжный магазин не был единственным приложением удаленного автоматического ввода заказа. Аналогичная система применяласьдля фармацевтических магазинов, и снова в Германии.
КомпьютерIBM-360КомпьютерIBM-360Рис. 2.12 Сбор информации о книжных заказах с помощью IBMРис. 2.12 Сбор информации о книжных заказах с помощью IBM
Компьютер
IBM-360
Компьютер
IBM-360
Рис. 2.12 Сбор информации о книжных заказах с помощью IBM
Рис. 2.12 Сбор информации о книжных заказах с помощью IBM
Оборудование 2750 совместно IBM-360 было установлено шведской компанией SKF в октябре 1970 года на ее германском предприятии в Бад Канштаате. Этот проект был начат в 1969 году с целью ускорить сбор данныхдля того, чтобы производство могло более эффективно управляться с помощью оперативной информации. Было известно, что отделы предприятий используют более 300 официаль-
ных форм с отчетными данными 100 разныхтипов. Данные эти собирали 79 хронометражистов, специалистов планирования производства, конторских служащих и операторов перфораторов в три смены. Тем не менее, производственные отчеты выпускались слишком поздно, и потому теряли свою ценность, объем отчетов возрастал настолько, что прочесть их было проблемой, а стоимость ручного сбора данных становилась чрезмерно высокой. Согласно проекту, УАТС 2750 была связана с системой 360 таким образом, что производственные данные вводились через кнопочные телефоны, отчеты об исключительных ситуациях могли печататься сразу же при их идентификации, экономия людских ресурсов, нужных для сбора данных, оказалась существенной.
Телекоммуникационный рынок Германии, где уста на в л и вал ись системы, представленные на рис.2.12, был тогда в высшей степени регламентированным; на нем, по словам одного из свидетелей тех событий, «кроме обязательнопэ и запрещенного ниче「о не существовало». Deutsche Bundespost вовсе не имел желания поддерживать IBM как поставщика коммутаиионно「о оборудования и ограничил продажу коммутаторов IBM обязательным условием - наличием соответствующих приложений для обработки данных. Эта ситуация дала возможность IBM продемонстрировать свою изобретательность и де-факто послужила поводом к разработкам в направлении компьютерной телефонии, хотя вначале усилия разработчиков, как уже отмечалось, были направлены не на удовлетворение потребностей рынка, а на борьбу с о「раничивающими регламентациями.
Более быстрое развитие сдерживал, к сожалению, и стоимостной фактор. Когда в Великобритании были введены системы 2750/3750, они стоили почти в шесть раз дороже, чем конкурирующие продукты -производившиеся в то время координатные УАТС. Кроме то「о, ранние реализации не отличались должной надежностью, вынуждая IBM-360 распечатывать отчеты об исключительных ситуациях для анализа их операторами. Хотя продукты IBM, несомненно, олицетворяли большой скачок в смысле функциональных возможностей, их приобретение требовало от заказчика материальной обеспеченности и способности рисковать.
Возникло и движение во встречном направлении. Например, инженеры компании Plessey спроектировали интерфейс, позволяющий подключать компьютер к координатной УАТС. Использовался компьютер Interdata 7/16, миникомпьютер той эпохи, который работал в двухпроцессорном режиме для обеспечения надежности. Компьютер анализировал цифры, которые были набраны, затем пересчитывал их в соответствии со своей про「раммой маршрутизации, а координатная y/VTC выполняла коммутацию в соответствии с цифрами, принимаемыми от компьютера. Полученный в результате продукт был назван System 2150. Один экземпляр этой системы был ус-
тановлен в середине 1970-х в офисе British Petroleum в Лондоне, а другой - на предприятии British Steel в Корби. Система 2150, возможно, представляет собой решение, ближе всего примыкающее к ранним примерам внедрения компьютерной телефонии (CTI). Это решение обладало массой возможностей, которые в обычных электромеханических УДГС были просто немыслимы. На 1,5-МБ дисках (диаметром приблизительно 18 дюймов) компьютера хранился полный телефонный справочник (каталог) для УПДГС.
Тем не менее, решавшиеся в те дни вопросы имели мало общего с современными концепциями взаимодействия телефонов и компьютеров.
В США начало CTI принято отсчитывать от 1973 года, когда была внедрена ступень распределения вызовов (ACD) Galaxy производства компании Rockwell International. Именно благодаря этому комплексу и начавшемуся тогда же использованию компьютеров для управления телефонными станциями развились идеи Call-центров. В первое время эти системы были очень дороги, и их стоимость могла быть оправдана только тогда, когда работало несколько сот операторов, а потому применение Call-центров было ограничено справочно-информационными службами сети общего пользования или состояте льн ыми организациями, такими как авиакомпании и банки. По мере того как стоимость оборудования снижалась, эти системы распространялись из США в Европу и становились все более популярными.
Первое отечественное оборудование компьютерной телефонии на базе специализированной ЭВМ «Нева», вполне сопоставимое по функционал ьным возможностям с описанными выше проектами IBM, как раз развивало идеи Call-центра и было установлено в качестве справочно-информационного центра для службы 09 и других служб телефонной сети общего пользования в Минской ГТС. Параметры этой отличной ЭВМ «Нева», придуманной и названной в ЛОНИИС, а разработанной под руководством В.И.Шляпоберского (ЦНИИС, Москва) и А.ГКухарчука (Институт кибернетики, Киев), не уступали появившейся в те же годы специализированной ЭВМ типа ITT-3200 и прекрасно подходили к тогдашним задачам компьютерной телефонии. Кстати, «Нева» ктому времени уже управляла междугородными АТС «Кварц», успешно справляясь при этом с задачами биллинга, эксплуатационного управления и др. Высочайшему научно-техническому уровню проекта этого справочно-информационного центра в полной мере соответствовали и заложенные С.С.Бернштейном основы алгоритмического обеспечения, и блестяще разработанное ГЯ.Машбиц и В.А.Яффе системное программное обеспечение, и созданное Г И. Голуб и М.В.Персияновой прикладное ПО.
Один из авторов данной книги, принимавший участие в этом и других предшествовавших ему проектах на базе ЭВМ «Нева», и сейчас,
спустя 20 лет, все еще пытается понять, почему столь талантливые разработки, ни в чем не уступавшие зарубежным аналогам, а зачастую и превосходившие их, заканчивались ничем. И почему то же самое происходило со сменившими «Неву» распределенными микропроцессорными системами, о которых речь пойдет чуть ниже. Впрочем, на этом этапе о превосходстве над зарубежными аналогами говорить уже не приходилось 一 сказывались задержки в «срисовывании» микропроцессорных комплектов Intel.
Ответ на этот вопрос, пусть не полный, но, как показалось авторам, вполне точный и справедливый, попался им вовремя написания данной главы в работе современного отечественного философа, автора многотомного «Философского наследия» П. Таранова. Заранее принося извинения за весьмадлинную цитату, авторы считают уместным привести здесь, с некоторыми сокращениями, фрагмент личных воспоминаний философа [12],
«Мне пришлось в 80-е годы работать на крупном заводе в отрасли, кодифицируемой тогда как промышленность средств связи. Без всякого отличия от других предприятий, здесь тоже быломногоинициативных, умных, просто талантливых людей, могущих легко что-то дельное предложить и с энтузиазмом все это же исполнить,
Я был социологом и всегда удивлялся общей, с каждым годом усугубляющейся невостребованности именно инициативного контингента.
Одновременно я понимал, а может быть, тогда еще только чувствовал, более или менее осознавая последовательные масштабы вроде бы явной проблемы, что без предпочтения в вознаграждении с этими людьми общий язык не найти.
Творчество - это износовый труд, и без его восстанавливающей компенсации личность быстро выгорает. Человек думающий, заводной, активный непроизвольно стремится к повышению уровня жизни -ему нужно и больше читать, и общительнее поведенчествовать, и как-то демпфировать семейные к нему претензии ввиду общего уменьшения внимания к дому. Кроме того, обширная познавательная неуемность влечет рост здоровой самооценки, человек ощущает свое право быть выделенным среди других, рассчитывает на признание окружающих. И - что важно подчеркнуть - заслуженное...
Но руководство рассуждало иначе и поддерживалось установок, базирующихся на прямо противоположном подходе. Здесь была своя «Марья Алексеевна», которая считала всякую прибавку жалованья таким - излишней роскошью. Мол, и без них «саду советскому цвесть», да и то「о, что им уже дадено - речь в таких случаях всегда шла о пресловутых 120 рублях (что-то около двух средней ценности парфюмерных наборов), - «этим» изобретателям, кандидатам, выскочкам вполне «прилично» и вполне «достаточно».
Ну и что? Тэгда она жалела десятку-две. А теперь? Тэ, за что она держалась, рассыпалось в прах: плоды ее усилий оказались противоположными ожиданиям.
Это не наказание. Просто сорванный лист желтеет, а надломленная ветка сохнет. И по-другому не бывает».
Но вернемся к технике. Для решения этих (технических, а не социальных) задач создавались первые ступени распределения вызовов (СРВ) у нас и за рубежом. В отличие от вышеописанной системы на базе машины «Нева» с рабочими местами операторов, оснащенными видеотерминалами, первые СРВ базировались на печатной информации. Операторы служб 09, например, имели карты, содержащие подробные данные об абонентах. Несмотря на постоянное совершенствование механических картотек, операторы работали медленно, т.к. любому из них требовалось определенное время, чтобы найти нужную карту.
Кстати, четыре сотрудника Bell Telephone Laboratories, занимавшиеся этой проблематикой, для поиска информации придумали компьютерную технологию и основали Delphi Corporation. Первая система Delphi называлась Delta 1 и поддерживала предоставление услуг СРВ в Сан-Франциско. После того как оператор отвечал на вызов абонента, он обращался за справкой к базе данных, и экран рабочего места оператора заполнялся текстом соответствующего ответа. Система оказалась значительно дешевле в эксплуатации, а работа операторов - почти на 30% более эффективной. Но технология, использованная в Delta 1, быстро устаревала. Приблизительно в 1979 匚 началось проектирование Delta 2, финансируемое нефтяной компанией Exxon. Однако общий уровень телефонии и компьютерной техники, надежность тогдашних мини-ЭВМ и, вероятно, ряд субъективных причин, тормозили проект. К концу 1981 года результат еще не был получен; при отсутствии продукта, и, следовательно, заказчиков, компания Exxon вышла из проекта. Хотя рынок существовал, но технология, которая была бы готова к производству, отсутствовала.
В самом начале 80-х годов British Telecom в Великобритании стала думать об организации бюро телемаркетинга с обслуживанием входящих вызовов. Несколько операторов должны были отвечать на вызовы, предоставлять информацию, принимать заказы и т.д. Сценарий, который указывал, что именно оператор должен сказать, находился в компьютере DEC VAX, телефонными вызовами занималась УАТС Mitel Regent. Проектировщики столкнулись с классической проблемой компьютерной телефонии: информация, в которой нуждался компьютер, имелась в АТС. В объеме, минимально необходимом для эффективной работы оператйра, эту информацию содержали несколько последних цифр, набранных вызывающим абонентом. Некоторые из разработчиков отбыли в США, чтобы посе-
тить Delphi Corporation и увидеть систему Delta. Подход, использованный в Delta, имел много общего с системой, в которой нуждалась British Telecom.
Разработка была успешно завершена в 1983 году. Она была названа Telecom Tan. АТС соединялась с компьютером DEC VAX через компьютер Macintosh, который выполнял функции преобразования протоколов, а также буферизировал запросы приложения телемаркетинга, поступавшие к VAX в реальном времени. Сама АТС специального интерфейса для приложений не имела. Система Telecom TAN использовала выводлинейного дисплея пульта оператора Regent для получения информации о статусе каждой линии; эта информация обрабатывалась Macintosh для доставки необходимых данных к VAX.
В 1982 году в компании Aircall возникла потребность обеспечить персональные ответы абонентам пейджинговой связи. Aircall обратилась к компании Special Telephone System (STS), которая была первым производителем СРВ в Великобритании. Требования Aircalls предусматривали передачу из АТС в компьютер полученных ею цифр номера и передачу на экран оператора одновременно информации о телефонном вызове и данных из компьютерной базы. Первое требование обеспечивало оператора немедленной информацией о вызываемом лице, второе - давало возможность в сложных случаях перепоручать обслуживание вызовов - более опытному оператору. STS сумела создать такую систему, что в начале 80-х было, несомненно, выдающимся достижением. Приблизительно двенадцать экземпляров системы было продано телефонной компании Хельсинки, шведской РТ^ в Швейцарию и Австралию. Это, веооятно, самый ранний пример реализации двух важнейших функций компьютерной телефонии: анализа данных о вызове и одновременной передачи речи и данных.
Следующая после СРВ глава книги посвящена Call-центрам, которые ориентированы на обслуживание как входящей, так и исходящей на「рузки. Пример обработки исходящих вызовов уже упоминался в рассметренной выше системе оформления книжных заказов - компьютер сам направлял вызовы к книжным магазинам. Однако более широкое применение так назвваемопэ «вызова по поручению» (power dialing) связано с торговлей по телефону. Примерный сценарий выглядит следующим образом. Оператор Call-центра вызывает очередного абонента из заранее составленного списка и говорит: «Пожалуйста, не кладите трубку, у меня для вас сообщение от такой- то компании». После этого включается магнитофон, и абоненту транслируется сообщение о продукте или услу「е, который (которую) названная компания пытается продать. Как только оператор организовал одно такое соединение, он может тут же его оставить и произвести анало「ичнь>В вызов по друпэй линии. Это было весьма эффективным способом продажи и применялось разными компаниями. При
реализации подобного сценария необходимо распознавать отбой вы- званно「о абонента, который не хочет или не может в данный момент слушать записанный на пленку монолог. Эта задача не представляет особой сложности для АТС любого типа, но ее решение, вполне естественно, натолкнуло разработчиков на мысль анало「ичным образом распознавать также и ответ вызванного абонента и, тем самым, автоматизировать весь процесс, исключив из не「о оператора. Такой подход позволил компани и Telephone Broadcasting Systems (TBS) построить в 1983 году систему, которая способствовала пополнению фондов рели「иозннх проповедников, выступающих по радио. Вызовы распределялись автоматически, а когда ответ обнаруживался, вызванному абоненту передавалась запись обращения проповедника с просьбой сделать пожертвование на какое-нибудь неотложное дело, после че「о система переключала абонента к живому оператору, который завершал разговор.
Дальнейшим развитием этой техноло「ии явилась разработка в 1984「оду оборудования автоматического набора номера, установ- ленно「о в Кентоне, Охайо, для General Electric Credit Corporation. Эта компания собирала платежи за холодильники, печи и другое бытовое оборудование, для чего с плательщиками связывались по телефону 200 операторов. После установки оборудования Call-центра с автоматическим набором номера количество операторов сократилась до 30. TBS продолжает поставлять системы автоматическо- 「о набора номера средствами компьютерной телефонии до сих пор.
Практически в то же время аналогичные работы проводила крупнейшая телекоммуникационная компания Northern Telecom, причем разработанные ею продукты были тесно связаны с рядом ее собственных АТС. Две системы заслуживают упоминания в этом кратком обзоре. Первая система первоначально была названа Packet Transport Equipment, а позднее ей был присвоен номер в пределах ряда продуктов Meridian. Интересен этот продукт наличием специализированного (только для SL! Northern Telecom) протокола сигнализации между процессором и коммутатором. Другой продукт Nothern Telecom производился, прошел полевые испытания, но не имел коммерческого успеха. Речь идет о DVI, который использовал тот же терминал М4000, что и Packet Transport Equipment, тоже базировался на UNIX, но не нуждался в подключении к УАГС, т.к. фактически сам выполнял ее функции.
Дру「ие компании - AT&T и Plessy, например, - разработали свои мультиплексированные интерфейсы, обеспечивающие подключение множества терминалов к компьютеру через У АТС. Интерфейс AT&T назывался DMI (цифровой мультиплексированный интерфейс), Northern Telecom использовал CPI (интерфейс УАТС-компьютер), a Plessy применила для сопряжения стандарт ЕСМА. Все эти интерфейсы не представляли собой элементы компьютерной телефонии, т.к. они не
являлись функциональными линиями связи, а просто обеспечивали средства подключения канала данных к другому каналу данных.
Другие поставщики телекоммуникационного оборудования в 80-е годы также претендовали нато, чтобы ихУАТС могли не только передавать данные, но и запускать разнообразные приложения. Компания Mitel предлагала метод встраивания компьютерных конфигураций непосредственно в коммутатор, хотя ее внимание, со временем, стало концентрироваться на внешних (third party), а не на встроенных приложениях. Следует заметить, что быстро развивающаяся канадская компания Mitel, впервые вышедшая на рынок с аналоговой УПАТС малой производительности, привлекла внимание IBM на раннем этапе исследования ею возможностей использования перспективного цифрового коммутатора SX2000. Инженеры IBM сосредоточенно изучали документацию SX2000 и средства, разработанные Mitel, но коммерческого результата этот проект не имел. Немного позднее IBM объявила о своем партнерстве с компанией Rolm. Mitel и Rolm находятся среди немногих сохранившихся из тех компаний, которые предлагали обработку встроенных приложений непосредственно в своих УАТС.
Вернемся к истории отечественной компьютерной телефонии, начатой выше с описания специализированной ЭВМ «Нева». За более чем 20-летний период было немало других творческих достижений и великолепных разработок. Ряд работ, под общим названием «Речевые интеллектуальные технологии», проводился, начиная с 1980 года, в существовавшем тогда Московском отделении НИИ связи (МОНИИС) под руководством Б.А. Лопусова [11].
По сути своей, эти работы предполагали дистанционное управление компьютерной системой, для чего служил телефонный аппарате импульсным или многочастотным набором; предусматривались дополнительные речевые команды (включая речевой или тональный ответ компьютерной системы), обработка данных и формирование управляющих воздействий на другие системы. Проще говоря, абонент соединяется по телефону с некоторой компьютерной системой и по речевой подсказке компьютера набирает нужную комбинацию цифр. В ответ компьютер передает в речевой форме запрашиваемую информацию или выдает инструкции о дальнейших действиях, вплоть до завершения обслуживания абонента.
В 1985 匚 этот коллектив создал систему «Диалог», которая автоматически принимала заказы международных и междугородных переговоров в городе Сочи. Система была построена на базе отечественной микро-ЭВМ «Электроника-60» с дополнительными аппаратными модулями, разработанными под руководством Ю.М. Мазнике- ра, и с оригинальным программным обеспечением, созданным А.А. Бирманом. На этих же принципах и на этой же «Электронике-60»
в 1986 году была реализована система «Телефонная почта», которая выполняла практически все функции современной речевой почты, а ее единственным отличием от современных систем был небольшой объем хранимых речевых сообщений, поскольку емкость жесткого диска не превышала 30 Мбайт.
В те же годы, и на базе все той же микро-ЭВМ «Электроника-60», уже в Ленинградском отделении НИИ связи (ЛОНИИС), под руководством И.Е.Соловейчика велась разработка уникальной широкополосной (с доступом на скорости 384 Кбит/с) системы компьютерной телефонии, которую, следуя современной терминологии, можно назвать мультисервисным контакт-центром. Уникальное программное обеспечение для нее было написано Н.А.Апостоловой и Н.Ю.Виноградовой, а первой областью ее применения был советский космический Центр управления полетами. Переход же на микропроцессорное управление на базе изделий Intel был осуществлен в другом разработанном вЛОНИИС изделии компьютерной телефонии - ЦСК, а затем СРВ-30/24, являющемся уже не столько историей, сколько современностью, и потому рассматриваемом в главе 6, посвященной СРВ.
Историю развития технологии компьютерной телефонии в сегодняшней трактовке начали разработки израильской компании VocalTec, а ее хронология выглядит следующим образом:
1995 匚 Разработан VocalTec Internet Phone. Платы Dialogic, в том числе, и их распространение в России через Comlek. В состав операционной системы Windows 95 компания Microsoft включила поддержку 7API. В том же году организован Enterprise Computer Telephone Forum (ECTF).
1996 г. Dialogic/Vocallec Telephony Gateway. Компания VocalTec выпускает VocalTec Telephony Gateway - первый коммерчески доступный шлюз между IP-сетям и и ТфОП. В октябре 1996 года первый такой шлюз был продан в Россию. Компания Mitel продемонстрировала первый USB-телефон (universal serial bus). Появилась первая реализация JavaTAPI.
1997 匚 Маршрутизаторы Cisco. В России появляются первые сети IP-телефонии: Тарио Трейдинг, AMT-Линк, ИнкомТел ТГ. Установлено несколько десятков шлюзов VocalTec. Тоща же появилось коммерческое оборудование для передачи речи поверхАТМ. Microsoft включил 7API2 в состав Windows NT и анонсировал TAPI3.
1998 匚 Начали появляться цифровые шлюзы. Компания Dialogic выпустила специализированную карту DM3 IP Link, которая стала первым открытым решением IP-телефонии. Выход на рынок Интеллектуальной платформы ПРОТЕЙ, которая примирила концепции компьютерной телефонии и Интеллектуальных сетей, использовав подход Service Node.
1999 г Рынок компьютерной телефонии в России испытывает устойчивый рост примерно на 20-30% в год, даже во время кризиса 1998 匚 Закат «эры VocalTec». На рынке появилось оборудование, позволяющее организовать любые решения IP-телефонии, в частности, Ethernet-телефоны. Легализация 1Р-телефонии: выдано несколько десятковлицензий.
2000 п Объем рынка компьютерной телефонии в России составил $2.2-3 млн. (около 12 тыс. портов). Одновременное развитие 1Р-те- лефонии в России: количество IP-телефонных портов в России - примерно 5-Ютыс. шг Сохранение лидирующих позиций Cisco, VocalTec, Avaya и Ericsson. Установка целого ряда систем предоплаченных телефонных карт на базе систем СВЕТЕЦ, ПРОТЕЙ, БЕРКУТ и др.
2001 г: Активное внедрение Call-центров операторами мобильной и стационарной связи. Выход на рынок российских разработчиков IP-телефонии: установлены первые отечественные шлюзы между IP- сетями и ТфОП на базе Интеллектуальной платформы ПРОТЕЙ. Разработки Web-контакт-центров.
В значительной степени именно благодаря этим разработкам возникли индустрия компьютерной телефонии и соответствующие стандарты, рассматриваемые в следующей главе, а также курсы подготовки специалистов, отраслевые организации и объединения пользователей компьютерной телефонии. Среди последних - AC7AS (Альянс производителей приложений компьютерной телефонии) в США, ACTIUS (Ассоциация пользователей и производителей систем компьютерно-телефонной интеграции) в Великобритании и др.
В следующей же главе будут рассмотрены и весьма непривлекательные страницы истории компьютерной телефонии, описывающие баталию двух разных компаний, которая на много лет задержала развитие стандартов отрасли. Еще в 1993 году компании Novell и AT&T выступили с идеей TSAPI (API телефонных услуг), который был разработан для связи учрежденческих АТС с сервером NetWare. Компания Microsoft установила другой стандарт - 7API, предусмотрев этот интерфейс как часть операционной системы Windows и увязав с операционной системой факсимильную связь на базе компьютера и унифицированную передачу сообщений.
По общему признанию, TAPI имел гораздо меньше функциональных возможностей, чем TSAPI, и, хотя он был дешевым и удобным для пользователя, подвергался серьезной критике телефонных компаний, операторов и поставщиков оборудования. Главным объектом критики 7API была относительная слабость в нем функций управления сеансами связи, что могло приводить к ошибкам при разработке программного обеспечения без детальных знаний телефонной специфики. Впрочем, почти традиционно, версии 1.0 большинства продуктов Microsoft для вычислительной техники имеют структурные не-
достатки, но зато Microsoft невероятно быстро обучается. Ко времени, когда была выпущена версия 2.0, стандартTSAPI компании Novell был оттеснен. TAPI позволял открытому серверу NT заменить закрытый продукт NetWare, что, в свою очередь, предоставило поставщикам плат компьютерной телефонии возможность использовать свои платформы не только для обработки вызовов, но и для коммутации. В результате, компьютерные серверы могуттеперь вводиться в связные серверы и заменять УАТС.
Итак, чего же ждать от будущего компьютерной телефонии? Мнение авторов по этому вопросу узнает лишь тоттерпеливый читатель, который доберется до последней плавы книги. Здесь же мы ограничимся самыми общими соображениям и.
В сфере учрежденческой телефонной связи 1Р-УАТС вытеснят с телекоммуникационного рынка обычные станции в ближайшие восемь- десять лет. Учрежденческие абоненты будут использовать внутри офиса преимущественно мобильные телефоны, а в качестве терминалов проводной связи будут использоваться Ethernet-телефоны. Программы просмотра контекстно-зависимых меню станут основными интерфейсами связи. И многое, многое другое.
У операторов сетей связи общего пользования перспективы не менее заманчивы. Операторы будут продолжать продавать миллиарды минут на линияхсвязи, но их сети сосквозным управлением по IP-протоколу обеспечат виртуально свободную полосу пропускания. Узлы предоставления услуг (Service Nodes) будут ведущими в сети, создаваемые на их базе приложения компьютерной телефонии будут продаваться различным поставщикам и, в конце концов, - потребителям телекоммуникационных услуг Некоторые сегодняшние инженерные решения компьютерной телефонии, описанные в этой книге, будут медленно отмирать, однако рассмотренные в ней же приложения компьютерной телефонии будут применяться все шире и шире.
Глава 3 Стандартизация
Смысл всякой деятельности лежит за ее пределами Принцип Таллинской школы менеджеров В.К.Тарасова
Стандартизация компьютерной телефонии
В истории компьютерной телефонии известно немало конфликтов, возникавших при создании стандартов, чему имелись вполне объективные причины. Прежде всего, можно вспомнить о тех конфликтах между производителями компьютеров и п ро из водител ям и систем коммутации, которые были связаны с разработкой протокола ЕС МА CSTA. Компьютерщики хотели стандартизовать весь набор функций АТС и иметь формализованную модель работы узла коммутации. Специалисты в области коммутации подчеркивали сложность и функциональное многообразие коммутационных систем и настаивали на том, что необходимо дать каждой АТС возможность работать по-своему, и на том, что достаточно иметь возможность описывать телефонные операции, но вовсе не обязательно накладывать ограничения на порядок выполнения этих операций. Восторжествовала точка зрения разработчиков систем коммутации. Аналогичная дискуссия велась и разработчиками SCAI из ANSI, но здесь победил уклон в сторону компьютерного подхода.
Как следует из материалов предыдущей главы, и Call-центры, и остальные системы компьютерной телефонии были одной из тех областей инфокоммуникаций, которые меньше других подвергались стандартизации. Однако сегодня все большую популярность приобретает (и стимулируется многими операторскими компаниями) подход, основанный на применении поставщиками не закрытых систем с использованием внутрифирменных технологий, а открытыхсистем, базирующихся на устоявшихся, общепринятых стандартах.
Существуют международные комитеты, форумы, институты, комиссии, консорциумы, создающие стандарты общего пользования,
которые в процессе их разработки должны быть (и иногда бывают) открыты для анализа и обсуждения. Такие стандарты называютстан- дартами де-юре. Наиболее известной из подобных организаций, много сделавшей, среди прочего, и в той области, которая рассматривается в данной книге, является Сектор стандартизации электросвязи Международного союза электросвязи (1TU-T).
Существуют и другие международные стандарты 一 де-факто,- которые формально не являются стандартами общего пользования. В их число входят протоколы и процедуры, определенные для своих продуктов такими всемирно признанными авторитетами, как, например, Microsoft или IBM. Благодаря высокому проффесионализму разработчиков, а также благодаря своей доступности и корректности, описания и спецификации соответствующих интерфейсов стали настолько широко использоваться, что, по существу, превратились в стандарты. Именно такого рода стандартами являются, например, протокол TCP/IP и операционная система Windows. Правда, всеща существует вероятность борьбы стандартов. Наглядными примерами такой борьбы могут служить война Бета со стандартом VHS или война IBM PC с Apple Macintosh.
Весьма актуальный в контексте данной книги пример - это два стандарта для открытых интерфейсов API, применяемых в системах компьютерной телефонии, - TSAPI (прикладной программный интерфейс телефонных услуг), разработанный Novell Inc., и TAPI (телефонный прикладной программный интерфейс), разработанны访 Microsoft.
Пользователям нужны такие продукты компьютерной и традиционной телефонии, которые можно интегрировать с существующими информационными системами, а оба упомянутых интерфейса удовлетворяют этому требованию. С момента их внедрения в 1993 году интерфейсы API стали играть в индустрии компьютерной телефонии связующую роль. И хотя этот вопрос уже был затронут в главе 1, в данной главе они рассматриваются для того, чтобы показать, насколько непроста ситуация со стандартами в области компьютерной телефонии.
Стандартизация в компьютерной телефонии охватывает, прежде всего, модели обработки вызова, т.е. алгоритмы обработки сигнальной информации, объекты этих моделей и протоколы взаимодействия коммутационной и вычислительной областей. Обработкой вызова занимается программное обеспечение коммутатора, включающее в себя операционную среду, управляющую ресурсами системы, и драйверы устройств, создающие интерфейс между аппаратной и программной частями коммутационной подсистемы. Существует множество вариантов реализации программной части. Так, существуют коммутационные системы, которые до сих пор достаточно ус-
пешно работают с программным обеспечением обработки вызова, написанным на ассемблере, тогда как в других оно реализовано на специальных языках и с использованием специальных алгоритмов обработки вызова. Интеграция двух независимо развивающихся областей 一 весьма непростая задача, тем более что компьютерная часть должна реализовывать все функции управления коммутатором и быть способной интерпретировать получаемые от него сообщения. Для выполнения этих и других задач компьютерный домен систем CTI должен работать с соответствующей абстрактной моделью коммутационного оборудования и алгоритмов обслуживания вызова. Этой теме посвящена глава 9.
Несмотря на очевидные преимущества и актуальность рассматриваемой в книге технологии, развитие и стандартизация систем компьютерной телефонии протекали довольно сложно. Основной причиной этого были разногласия между производителями компьютерной и коммутационной техники. Архитектура third-party CTI требует специального стандартного протокола связи между станцией и компьютером. А к началу 1990-х годов ситуация характеризовалась тем, что компьютерное оборудование для взаимодействия «с внешним миром» уже поддерживало ряд разных протоколов, и поставщики компьютеров не стремились добавлять к этому ряду ещё несколько, тогда как производители систем коммутации либо вообще не имели нужного протокола, либо имели свои собственные внутриотраслевые протоколы. Каждый поставщик компьютерных систем или API поддерживал те протоколы, которые он считал стратегически важными (в силу сложившихся партнерских взаимоотношений или других, большей частью, субъективных причин). Тем не менее, программисты-конструкторы приложений Call-центров и компьютерной телефонии нуждались в общей платформе, на которой могло бы базироваться их программное обеспечение. В сфере компьютерных систем двумя примерами таких общих платформ являются IBM-совместимые персональные компьютеры и стандартизация операционной системы UNIX, но этого явно не хватало, чтобы стимулировать производство совместимого ПО компьютерной телефонии.
В начале 90-х годов стандарты стали появляться, но их количество и разноплановость прекрасно иллюстрировали известное высказывание: «единственное преимущество стандартов состоит в том, что их всегда очень много, а потому - есть, из чего выбирать». Очевидно, что когда ситуация со стандартами - запутанная, производители не стремятся вкладывать значительные средства в их внедрение. Более того, когда выбор слишком велик, производитель, вероятнее всего, сохранит своё собственное внутрифирменное решение, особенно, если оно предоставляетбольше возможностей и услуг; чем любой из существующих стандартов. К тому же, на разработку стандартов большее влияние оказывают не требования пользователей,
а технические аспекты. Этим объясняется и то, что главным объектом внимания в сфере стандартизации Call-центров и CTI были и остаются вопросы протоколов, а не разработка стандартного API, по крайней мере, в части архитектуры внешних серверов компьютерной телефонии (third-party CTI).
Сегодня, правда, протоколы first-party специфицируются путём определения линейной сигнализации между терминальными устройствами и коммутационным оборудованием. Здесь наиболее распространенной базой для стандартизации является специфицированная ITU-Tсигнализация ISDN (рекомендация Q.931). Именно предусмотренная в Q.931 модель процесса обслуживания вызова и состояния этого процесса легли в основу модели процесса, применяемой в тех интерфейсах API, через которые обеспечивается программный доступ к управлению соединениями, устанавливаемыми и разрушаемыми с использованием этого протокола.
Этапы стандартизации
В начале 1980-х годов был предпринят ряд усилий, направленных на стандартизацию каналов связи между АТС и компьютерами. На переднем крае этой деятельности, как и в других телекоммуникационных областях, выступила компания AT&T, которая разработала в 1984 году протокол DMI (цифровой мультиплексный протокол), первоначально обеспечивавший связь Н Р-АТ&Т Несмотря на то, что этот стандарт был реализован некоторыми производителями УАТС (интерфейс поддерживала, например, УАТС iSDX производства Plessey) и что с ним начали экспериментировать некоторые производители компьютеров (например, компания DEC реализовала его в опытном оборудовании Annecy во Франции), рынок фактически игнорировал эту концепцию- вместе с большинством попыток обеспечить транспортировку данных через УПАТС. Компания Nortel предложила сходное решение - интерфейс Computer PBXIinterface (CPI), которое тоже не нашло широкого распространения.
Тем не менее, DMI и подобные протоколы, в некотором смысле, проложили дорогу полноценным протоколам, включающим в себя обширный набор команд и состояний взаимодействующих объектов. AT&T спонсировала форум производителей ISDN/DMI User's Group, собравший 170 производителей систем коммутации и компьютеров и организовавший в 1987 году группу для изучения технических вопросов реализации прикладного интерфейса АТС-компьютер. В результате этой работы был определен протокол ASAI. Хотя протокол был открытым (в том смысле, что спецификацию ASAI можно было приобрести у AT&T за минимальную сумму), он был слишком связан с AT&T, чтобы стать универсальным стандартом.
Тем временем, в Великобритании British Telecom организовал ряд рабочих встреч, направленных на создание национального стандарта CTI, подобно аналогичным действиям, приведшим к успешной реализации DPNSS 一 системы сигнализации для частных сетей, рассмотренной в [4]. Основное внимание на этих встречах было уделено использованию протокола HCI компании Mitel в качестве отправной точки для определения национального стандарта.
В процессе дальнейшей работы на смену Mitel пришла Европейская ассоциация производителей вычислительной техники ЕСМА с задачей создать Европейский стандарт для телефонных приложений с использованием вычислительной техники (Computer-Supported Telephony Applications - CSTA), в котором впоследствии, для расширения сферы охвата, заменила слово «телефонные» на «телекоммуникационные».
Аналогичная работа тогда же (в 1990 году) была организована в Американском национальном институте стандартов (ANSI) под названием Switch Computer Application Interfaces (SCAI).
Как CS7A, так и SCAI являются протоколами обмена сообщениями между коммутаторами и компьютерами 一 ни ЕСМА, ни ANSI не определяют интерфейс API. Эти два протокола создавались довольномедленно (на протяжении трёх или четырёх лет), но явились первыми действительно открытыми стандартами приложений компьютерной телефонии для протоколов уровня звена данных. Спецификации CSTA были усовершенствованы и стандартизованы ITU-T с включением в них элементов прикладного интерфейса SCAI. К CSTA близко примыкает и дополнительный прикладной интерфейс компьютер-коммутатор ASAI (Adjunct Switch/System Application Interface), а также совместимая c IBM архитектура CSA - CallPath Services Architecture IBM.
Еще один стандарт 一 MVIP - был разработан тогда же (в 1990 году) компанией Natural MicroSystems и до сих пор поддерживается многими производителями, использующими аппаратные средства этой компании. MVIP допускает установку нескольких телефонных плат в одном PC, обеспечивает обработку до 256 одновременных вызовов через 8 шин по 2.048 Мбит/с и предусматривает взаимосвязь ресурсов до 20 компьютеров, улучшая тем самым масштабируемость системы. Более 50 производителей, включая Mitel, поддерживают MVIP через международную организацию GO-MVIR
Разработанная Dialogic архитектура вычислительных систем обработки сигналов SCSA основана на архитектуре клиент/сервер и представляет собой совокупность независимых аппаратных средств (клиентская часть, хост-компьютер, среда передачи) со стандартизованными интерфейсами между ними.
Далее в этой главе рассматриваются основные направления стандартизации Call-центров и компьютерной телефонии.
Рекомендации ITU-T
Первой в истории международной организацией по стандартизации электросвязи является Сектор стандартизации электросвязи Международного союза электросвязи - ITU-T (русская аббревиатура ССЭ-МСЭ). Этот орган выпускает документы, формально носящие рекомендательный характер, но фактически обязательные для исполнения. Создание рекомендаций и их утверждение в структуре ITU-T поручено исследовательским комиссиям (ИК), целый ряд которых выпускает рекомендации по тематике данной книги.
ИК-2 (Operational aspects of service provision, networks, and performance) отвечает за исследования общих аспектов предоставления услуг ТфОП, ISDN, мобильной и универсальной персональной связи, включая принципы сопряжения услуг и аспекты качества обслуживания пользователей; вопросов эксплуатации сетей, включая маршрутизацию, нумерацию, эксплуатационное управление сетью; вопросов качества работы сетей (расчет нагрузки, рабочие характеристики и их измерения); человеческих факторов; аспектов предотвращения обманных действий. Является ведущей комиссией в вопросах определения услуг; нумерации, маршрутизации и глобальной мобильности.
ИК-3 (Tariff and accounting principles including related telecommunications economic and policy issues) определяет тарифные принципы и принципы учета, включая относящиеся к этому экономические вопросы и вопросы принятия решений.
ИК-4 (Telecommunication management, including TMN) отвечает за исследования, относящиеся к сети эксплуатационного управления системами электросвязи (TMN), к тех обслужи ван ию сетей и их составных частей, к определению механизмов техобслуживания и к применению такого рода механизмов, предложенных другими комиссиями. Является ведущей комиссией в вопросахTMN.
ИК-7 (Data networks and open system communications) отвечает за исследования, относящиеся к сетям данных, к развитию модели взаимодействия открытых систем и к их применению, включая использование в сетях, обработку сообщений, защищенность информации и открытую распределенную обработку. Является ведущей комиссией в вопросах открытой распределенной обработки (ODP), ретрансляции кадров (FR) и защиты систем связи.
ИК-10 (Languages and general software aspects for telecommunication systems) отвечает за алгоритмические языки, методы их приме-
нения и другие вопросы, имеющие отношение к аспектам программного обеспечения телекоммуникационных систем. Является ведущей комиссией в вопросах языков и средств описания. Именно этой комиссией разработан язык спецификаций и описаний SDL, используемый в следующих главах книги для представления алгоритмов.
ИК-11 (Signaling requirementsand protocols) отвечает за исследования, касающиеся требований к сигнализации и протоколов для телефонии, ISDN, а также универсальной персональной, мобильной и мультимедийной связи. Является ведущей комиссией в вопросах Интеллектуальной сети; именно ею разработаны не только все упоминаемые в книге системы сигнализации, но и сама концепция Service Node (SN), которая стала бы названием данной книги, если бы нашелся удачный термин на русском языке.
ИК-13 (Multi-protocol and IP-based networks and their interworking) отвечает за исследования перспективных общесетевых аспектов и влияния новых системных концепций и новых технологий на телекоммуникационные сети в плане ожидаемых последствий, включая исследования широкополосных и IP-сетей и глобальной информационной и н ф р аст руктур ы.
ИК-16 (Multimedia services, systems and terminals) отвечает за исследования, касающиеся определения мультимедийныхуслуг и систем, включая терминалы, модемы, протоколы и обработку сигналов. Является ведущей комиссией в вопросах мультимедийных услуг и систем. Именно в ней созданы основные рекомендации, которые касаются Контакт-центров, рассмотренных в главе 8, и ряда других затрагиваемых в книге вопросов. К этим вопросам относятся и разрабатываемые перечисленными И селедо вательски м и комиссиями рекомендации следующих серий (таблица3.1.).
Таблица 3.1 Рекомендации ITU-T
G
Системы передачи и передающая среда. Цифровые системы и сети
Н
Системы аудиовизуальной и мультимедийной связи
1
Сети ISDN
J
Передача мультимедийных сигналов
Р
Качество телефонной передачи, телефонные установки и абонентские линии
Q
Коммутация и сигнализация
Т
Телематические терминалы
V
Передача данных по телефонным сетям
X
Сети данных и взаимодействие открытых систем
Y
Глобальная информационная инфраструктура
Z
Языки программирования.
С затрагиваемыми в книге вопросами тесно связаны и рекомендации серии Q.500 (требования к цифровым системам коммутации), серии Q.700 (спецификации системы сигнализации №7), серии Q.600 (взаимодействие разных систем сигнализации), серии Q.900 (цифровой доступ), а также рекомендации серии Q.2000, определяющие требования к широкополосным сетям. Все эти рекомендации, кроме последней серии, рассмотрены с той или иной степенью детал и - зациив [4]. Там же излагаются основы языка спецификаций и описаний SDL согласно рекомендациям Z.100, на котором написаны приводимые в данной книге SDL-диаграммы, например, рис.5.1, аспекты ISDN согласно рекомендациям серии I и др.
В контексте основной тематики книги весьма интересны также стандарты серии Q.1200, посвященные сначала революционной, а затем весьма быстро ставшей классической концепции создания телекоммуникационных услуг; называемой Интеллектуальной сетью.
Об этой концепции уже говорилось в главе 1, а здесь упомянем основные аспекты стандартизации ее физических и функциональных элементов. Для поддержки услуг из списков CS-1 и CS-2 рекомендациями ITU-T серии Q. 12хх определены следующие физические элементы: узел коммутации услуг (Service Switching Point - SSP), узел доступа к сети (Network Access Point-NAP), узел управления услугами (Service Control Point - SCP), вспомогательный узел управления услугами (Adjunct - AD), интеллектуальные периферийные устройства (Intelligent Peripheral - IP), узел услуг (Service Node - SN), совмещенный узел управления и коммутации услуг (Service Switching and Control Point-SSCP), узел предоставленияданныхдля услуг (Service Data Point - SDP), узел доступа (Enhanced ISDN Customer Premises Equipment - Enhanced ISDN CPE), узел приема и обработки информации, не относящейся к связи пользователя (Call-Unrelated Service Point-CUSP). Перечисленные физические элементы содержат функциональные объекты: поддержки доступа (CCAF), управления связью пользователя (CCF), коммутации услуг (SSF), управления услугами (SCF), предоставления данных для услуг (SDF), специализированных ресурсов (SRF), доступа к сети (IAF), приема и обработки информации, не относящейся к связи пользователя (CUSF), передачи информации управления услугой от пользователя (SCUAF), эксплуатационного управления услугами (SMF).
Более подробно все эти элементы и сама концепция изложены в [3]. Там же представлена структура Интеллектуальной сети, определены в соответствии с рекомендацией Q.1225 и другими рекомендациями ITU-T этой серии функционал ьные и физические элементы сети и интерфейсы между ними. Определение физического элемента сети ограничивается описанием его функций, интерфейсов с другими элементами сети и набором функциональных элементов, кото-
рые он может содержать. Так, для узла услуг определяются интерфейсы подключения к коммутационному узлу (PRI/BRI) и функциональные элементы SSR CUSE ССЕ SCR §DE SRE При этом функции SSF/CCF тесно связаны с функцией SCF и недоступны для других узлов, выполняющих функции управления услугами. Сегодня такие узлы услуг строится, как правило, на базе технологии компьютерной телефонии третьего поколения.
Заниматься проблемами компьютерной телефонии ITU-T начал довольно давно. Еще в те времена, когда он назывался Международным консультативным комитетом по телеграфии и телефонии (МККТТ), одним из направлений работы его Исследовательской комиссии 11 было «Телекоммуникационные приложения для коммутаторов и компьютеров» (IASC), Работа началась в сентябре 1992 года в подкомиссии, которая специализировалась на Интеллектуальных сетях. На первом заседании был согласован план создания международных рекомендаций и определён ряд интересных положений. Наиболее важные положения, разработанные на этом первом заседании, касались того, что должен представлять собой протокол TASC, каковы должны быть сфера его применения и его отношение к Интеллектуальным сетям.
Фактически, IASC представлял собой технологию доступа к сети, а технологию сетевого взаимодействия определяла концепция Интеллектуальной сети. Приложения TASC должны были дополнять и поддерживать услуги Интеллектуальной сети. С этой целью, а также чтобы избежать конфликтов взаимодействия, для TASC и Интеллектуальной сети строилась единая модель процесса обслуживания вызова. При разработке рекомендаций серии Q.1300, посвященных протоколу TASC, ITU-T использовал опыт разработки интерфейсов взаимодействия компьютер-АТС, накопленный ЕС МА и SCAI.
Следующим значительным шагом ITU-Т который может существенно повлиять на развитие технологий компьютерной телефонии в целом, стали рекомендации серии Q.1900, посвященные протоколу управления обслуживанием вызова в сетях с коммутацией пакетов, не зависящему от средств доставки информации (BICC). Этот протокол ориентирован на использование для связи между элементами сети следующего поколения NGN, под которой понимается результат конвергенции телефонной сети общего пользования, сетей кабельной телевидения (с возможностью передачи другой информации), сетей подвижной связи и Интернет. Одним из основных преимуществ протокола BICC является то, что он является наследником стека протоколов ОКС 7, а именно - протокола ISUR что значительно упрощает алгоритмы взаимодействия элементов сети нового поколения с элементами традиционных сетей. Из этой серии стандартов на данный момент вышли в свет следующие спецификации (часть 一 еще в предварительном варианте):
Таблица 3.2 Спецификации серии Q.1900
Спецификация
Описание
Q.1901
Протокол управления обслуживанием вызова вне зависимости от средств доставки информации (BICC)
Q.1902.1
Функциональное описание протокола BICC (CS2)
Q.1902.2
Основные функции сообщений и параметров протоколов BICC и ISUP (ОКС7)
Q.1902.3
Форматы и коды протоколов BICC и ОКС7
Q.1902.4
Протокол BICC: основные процедуры обслуживания вызова
Q.1902.5
Изъятия из прикладного механизма транспортировки в контексте BICC
QJ902.6
Общие процедуры сигнализации и поддержка протоколом BICC дополнительных услуг ISUP
QJ912.1
Сопряжение сигнализации ISUP (ОКС7) и BICC
Q.1912.2
Сопряжение некоторых систем сигнализации (доступ к ТфОП, DSS1, С5, R1, R2, TUP) и BICC
Q.1912.3
Сопряжение сигнализации протоколов Н.323 и BICC
Q.1912.4
Сопряжение сигнализации DSS2 и BICC
Q.1922.2
Взаимодействие между INAP CS2 и BICC
Q.1950
Протокол управления обслуживанием вызова вне зависимости от средств доставки информации (BICC)
Q.1970
BICC - Протокол управления доставкой информации по IP (IPBCP)
Q.1990
BICC - Протокол туннелирования информации управления доставкой
Стандарты ISO
Международная организация стандартов (ISO) также предприняла некоторые усилия в рассматриваемом направлении и даже придумала новый термин в области CTI - методы интеграции АТС и компьютеров (MISC - Methods for Integrating Switches and Computers). Первое заседание рабочей группы состоялось еще в 1993 году, и уже тогда на нём было решено, что эту работу под названием TASC возглавит ITU-Т о чем говорилось в предыдущем параграфе.
Стандарты ETSI
Европейский институт стандартизации в области электросвязи (European Telecommunications Standards Institute) был создан в 1988 году. Основной офис ETSI расположен на юге Франции в Sophia Antipolis, а сама организация насчитывает сотни членов из десятков стран, которые представляют адм и нистраторов, сетевых операторов, и сел ед о вател ьск и е организации и конечных пользователей, а также кандидатов в участники и наблюдателей.
ETSI играет значительную роль в разработке международных стандартов и другой технической документации в ключевых областях инфокоммуникаций и, в частности, в рассматриваемых в данной книге направлениях. На рис.3.1 представлена структура ETSI, которую составляют общее собрание, управление, технические комитеты, специальные комитеты, а также основные проекты.
Общее собрание
Технические комитетыТехнические комитетыПроекты ETSIПроекты ETSI
Технические комитеты
Технические комитеты
Проекты ETSI
Проекты ETSI
ТС АТ ТК сетей доступа и терминального оборудованияJTC Broadcast Объединений ТК EBU/CENELEC/ETSIТК32ЕСМАСвязь, сети и системы взаимодействияТС ЕЕ ТК моделирования условий эксплуатацииТС АТ ТК сетей доступа и терминального оборудованияJTC Broadcast Объединений ТК EBU/CENELEC/ETSIТК32ЕСМАСвязь, сети и системы взаимодействияТС ЕЕ ТК моделирования условий эксплуатацииTCERMТК электромагнитной совместимости и вопросов частотного спектраTCHF ТК человеческих факторовTCMSG ТК стандартов подвижной связиТС MTSТК методов тестирования и спецификацииТС Safety ТК безопастности телекоммуникационного оборудованияТС SEC ТК безопастностиТС SESТК спугниковых станций и системТС SPANТК услуг и протоколов современных сетейТС STQ ТК качества и передачи сжатой речиТС тм ТК передачи данных и мультиплексированияTCERMТК электромагнитной совместимости и вопросов частотного спектраTCHF ТК человеческих факторовTCMSG ТК стандартов подвижной связиТС MTSТК методов тестирования и спецификацииТС Safety ТК безопастности телекоммуникационного оборудованияТС SEC ТК безопастностиТС SESТК спугниковых станций и системТС SPANТК услуг и протоколов современных сетейТС STQ ТК качества и передачи сжатой речиТС тм ТК передачи данных и мультиплексированияЕР BRAN Сети широкополосного радиодоступаЦифровая расширенная беспроводная связь1СОМММобильная коммерцияЕР SCP Интеллектуальная карточная плаатформаEPPLT Связь через сеть электропитанияEPRTЖелезнодорожная связьЕР IETRAЕР TIPHONЕР BRAN Сети широкополосного радиодоступаЦифровая расширенная беспроводная связь1СОМММобильная коммерцияЕР SCP Интеллектуальная карточная плаатформаEPPLT Связь через сеть электропитанияEPRTЖелезнодорожная связьЕР IETRAЕР TIPHON'Участие ETSI в других проектах'Участие ETSI в других проектахТС TMNТК сети эксплуатационногоуправления системамиэлектросвязиТС TMNТК сети эксплуатационногоуправления системамиэлектросвязиСпециальные комитетыOCGГруппа координации работETSAGГруппа ослеживания европейских телекоммуникационных стандартовSAGE「pynna специалистов по проверке безопасности алгоритмовФинансовый комитетJEEC Объединений комитет ETSI/ECMAГруппа пользователейNGNСеть следующего поколенияСпециальные комитетыOCGГруппа координации работETSAGГруппа ослеживания европейских телекоммуникационных стандартовSAGE「pynna специалистов по проверке безопасности алгоритмовФинансовый комитетJEEC Объединений комитет ETSI/ECMAГруппа пользователейNGNСеть следующего поколенияЁРРЗОРР :'■ :■ ■Проект сетей третьего поколенияTSG-CNОпорная сетьTSG-GERAN Сеть радиодоступа GSM/EDG 匚TSG-RANСети радиодоступаTSG-SAАспекты услуг и системTSG-TТерминалыePPMESA::Прое.ю- безопасностиMESA-CNОпорная сетьMESA-RAРадиодоступMESA-SAУслуги и приложенияMESA-T Терминальное оборудованиеЁРРЗОРР :'■ :■ ■Проект сетей третьего поколенияTSG-CNОпорная сетьTSG-GERAN Сеть радиодоступа GSM/EDG 匚TSG-RANСети радиодоступаTSG-SAАспекты услуг и системTSG-TТерминалыePPMESA::Прое.ю- безопасностиMESA-CNОпорная сетьMESA-RAРадиодоступMESA-SAУслуги и приложенияMESA-T Терминальное оборудование
ТС АТ ТК сетей доступа и терминального оборудования
JTC Broadcast Объединений ТК EBU/CENELEC/ETSI
ТК32ЕСМА
Связь, сети и системы взаимодействия
ТС ЕЕ ТК моделирования условий эксплуатации
ТС АТ ТК сетей доступа и терминального оборудования
JTC Broadcast Объединений ТК EBU/CENELEC/ETSI
ТК32ЕСМА
Связь, сети и системы взаимодействия
ТС ЕЕ ТК моделирования условий эксплуатации
TCERM
ТК электромагнитной совместимости и вопросов частотного спектра
TCHF ТК человеческих факторов
TCMSG ТК стандартов подвижной связи
ТС MTS
ТК методов тестирования и спецификации
ТС Safety ТК безопастности телекоммуникационного оборудования
ТС SEC ТК безопастности
ТС SES
ТК спугниковых станций и систем
ТС SPAN
ТК услуг и протоколов современных сетей
ТС STQ ТК качества и передачи сжатой речи
ТС тм ТК передачи данных и мультиплексирования
TCERM
ТК электромагнитной совместимости и вопросов частотного спектра
TCHF ТК человеческих факторов
TCMSG ТК стандартов подвижной связи
ТС MTS
ТК методов тестирования и спецификации
ТС Safety ТК безопастности телекоммуникационного оборудования
ТС SEC ТК безопастности
ТС SES
ТК спугниковых станций и систем
ТС SPAN
ТК услуг и протоколов современных сетей
ТС STQ ТК качества и передачи сжатой речи
ТС тм ТК передачи данных и мультиплексирования
ЕР BRAN Сети широкополосного радиодоступа
Цифровая расширенная беспроводная связь
1
СОММ
Мобильная коммерция
ЕР SCP Интеллектуальная карточная плаатформа
EPPLT Связь через сеть электропитания
EPRT
Железнодорожная связь
ЕР IETRA
ЕР TIPHON
ЕР BRAN Сети широкополосного радиодоступа
Цифровая расширенная беспроводная связь
1
СОММ
Мобильная коммерция
ЕР SCP Интеллектуальная карточная плаатформа
EPPLT Связь через сеть электропитания
EPRT
Железнодорожная связь
ЕР IETRA
ЕР TIPHON
'Участие ETSI в других проектах
'Участие ETSI в других проектах
ТС TMN
ТК сети эксплуатационногоуправления системамиэлектросвязи
ТС TMN
ТК сети эксплуатационногоуправления системамиэлектросвязи
Специальные комитеты
OCG
Группа координации работ
ETSAG
Группа ослеживания европейских телекоммуникационных стандартов
SAGE
「pynna специалистов по проверке безопасности алгоритмов
Финансовый комитет
JEEC Объединений комитет ETSI/ECMA
Группа пользователей
NGN
Сеть следующего поколения
Специальные комитеты
OCG
Группа координации работ
ETSAG
Группа ослеживания европейских телекоммуникационных стандартов
SAGE
「pynna специалистов по проверке безопасности алгоритмов
Финансовый комитет
JEEC Объединений комитет ETSI/ECMA
Группа пользователей
NGN
Сеть следующего поколения
ЁРРЗОРР :'■ :■ ■
Проект сетей третьего поколения
TSG-CN
Опорная сеть
TSG-GERAN Сеть радиодоступа GSM/EDG 匚
TSG-RAN
Сети радиодоступа
TSG-SA
Аспекты услуг и систем
TSG-T
Терминалы
ePPMESA
::Прое.ю- безопасности
MESA-CN
Опорная сеть
MESA-RA
Радиодоступ
MESA-SA
Услуги и приложения
MESA-T Терминальное оборудование
ЁРРЗОРР :'■ :■ ■
Проект сетей третьего поколения
TSG-CN
Опорная сеть
TSG-GERAN Сеть радиодоступа GSM/EDG 匚
TSG-RAN
Сети радиодоступа
TSG-SA
Аспекты услуг и систем
TSG-T
Терминалы
ePPMESA
::Прое.ю- безопасности
MESA-CN
Опорная сеть
MESA-RA
Радиодоступ
MESA-SA
Услуги и приложения
MESA-T Терминальное оборудование
Рис. 3.1 Общая организационная структура ETSI
Общее собрание (technical assembly) является высшим органом ETSI, принимающим последнее решение об утверждении готовых стандартов. Разработкой самих стандартов занимаются технические комитеты. К 2002 году в состав ETSI было включено 15 технических и 7 специальных комитетов.
Структура ЕСМА
Европейская ассоциация ЕСМА была основана в 1961 году для стандартизации систем связи и информации. В ассоциации менее 20 активныхчленов, но ее состав хорошо сбалансирован. В нее всегда входили представители трёх основных направлений 一 производители компьютеров, производители систем коммутации и телекоммуникационные компании.
О результатах работы этой ассоциации можно судить по тому количеству стандартов ЕСМА, которые стали общеевропейскими и международными. ЕСМА также принимает активное участие в других организациях и форумах или имеет с ними соглашения о взаимодействии. Взаимодействие ЕСМА с другими стандартизующими организациями иллюстрирует рис,3.2.
Наиболее известной и важной разработкой ЕСМА является интерфейс взаимодействия коммутационного и вычислительных доменов
CSTA, уже упоминавшийся в начале главы. Во время разработки комитет возглавляли производители компьютеров — сначала DEC, а затем IBM. При дальнейшем развитии стандарта возник ряд разногласий. Некоторые из них появились в процессе доработки технического отчёта ЕСМА при определении модели обслуживания вызова для описания функций области коммутации (вопрос с моделью компьютерной области был менее насущным и менее спорным). Определение состояний и событий для интерфейсов CTI фактически было включено в технический отчёт, но только для сведения. Но даже этим разработчики АТС были весьма обеспокоены, т.к. стандартизация процесса обработки вызовов в их системах, скорее всего, противоречила бы текущему поведению производимых ими АТС. Другой вопрос, вызвавший существенные разногласия, касался количества услуг которые должен был реализовать в своём продукте производитель коммутационных станций, чтобы обеспечить их соответствие стандарту. Некоторые производители АТС настаивали на том, что достаточно оговорить в стандарте только поддержку процедур установления базового соединения. Но производители ПО компьютерных систем считали, что минимальный набор услуг реализуемых в ЗС, должен быть расширен. В результате стандартый набор услуг так и не был определён, что впоследствии ограничило возможности предоставления услуг под управлением серверов CTI.
Положительным моментом в деятельности ЕСМА было намерение в первую очередь стараться использовать существующие стандарты. Группа, работавшая с CSTA, не стремилась создать для протокола новую архитектуру, а решила организовать её на базе существующей архитектуры и на результатах работ других международных групп, занимающихся стандартизацией, главным образом, ISO и ITU-T. Цель подобных действий - достичь полной независимости протокола от нижележащих транспортных уровней. Передаются ли сообщения о запросах и состояниях по проводам, коаксиальному кабелю или оптическому волокну, используются ли при этом такие транспортные протоколы нижних уровней какХ.25 или протокол 1Р 一 все это не представляет интереса для протокола CSTA: лишь бы для передачи сообщений имелся какой-нибудь тракт. Именно по этой причине на функциональном уровне был применен принцип открытой распределенной обработки, а для взаимодействия между соответствующими уровнями протокола - OSI ROSE, в результате чего была создана архитектура, представленная в таблице 3.3. Несмотря на то, что ЕСМА является европейской организацией, её стандарты получают все большее международное распространение, а в группу, которая занималась спецификацией протокола, с самого начала вошли AT&T, Nortel, Mitel, Siemens - со стороны производителей систем коммутации - и IBM, Nixdorf и DEC-co стороны производителей вычислительной техники.
Таблица 3.3 Архитектура протокола CSTA
Уровень
Средства
Функциональный
Открытая распределенная обработка
Взаимодействие
OSI ROSE
Модель сети доступа
ISDN
Американский институт стандартов ANSI
Уже упоминавшийся выше интерфейс SCAI стандартизован комитетом T1S1 Американского национального института стандартов ANSI. Группа SCAI является частью комитета T1S1.1, который занимается также вопросами Интеллектуальных сетей. В группу SCAI входит около 40 активных участников, включая Bellcore и семь региональных операторских компаний Bell, AT&T, Nortel, Rolm, IBM, Harris, Hewlett-Packard и Mitel.
Работа началась несколько позже, чем работа ЕСМА, и шла параллельным курсом. Эти две группы взаимодействовали между собой, но убедить их в необходимости слияния не удалось. Преобладание в составе SCAI традиционных операторов ТфОП привело к фундаментальным различиям в подходе. В группе SCAI большее внимание уделено согласованию со стандартами для Интеллектуальных сетей и взаимодействию с сетями общего пользования.
Консорциум мультимедиа и телеконференций IMTC
Международный консорциум по мультимедиа и телеконференциям IMTC, объединяющий более 150 компаний-участников, занимается приложениями мультимедийной телеконференцсвязи, их функциональной совместимостью и открытыми стандартами. Основные направления работы консорциума IMTC сконцентрированы на стандартизации стеков протоколов Н.320 и Т120 для видеотелефонной конференцсвязи и конференцсвязи с передачей данных, соответственно, что подробно рассмотрено в [5].
Там же достаточно подробно описаны и стандарты 1ЕТ£ на которых строятся Web-контакт-центры (им посвящена глава 8 данной книги), а потому работа IETF в книге не рассматривается.
Конференции OpenSig and OpenArch и рабочая группа IEEE Р1520
Требования иметь в сетевом оборудовании открытые интерфейсы были сформулированы сетевыми операторами еще в начале эры компьютерной телефонии. Разработчики сетевых приложений, как
и разработчики рассматриваемых в следующей главе пользовательских приложений, искали новые пути использования сети. В 1996 году Колумбийский университет провел первый семинар OpenSig, нацеленный на продвижение исследований вопросов открытого сетевого управления. В 1998 году телекоммуникационное объединение IEEE спонсировало расширенный семинар OpenSig как часть конференции OpenArch IEEE. Затем IEEE создает группу стандартизации Р1520, задача которой - сделать сеть такой же программируемой, как персональный компьютер. Работа этой группы ориентирована на сети IP и АГМ и базируется на модели, содержащей следующие интерфейсы (рис.3.3):
V - API интерфейсы, обеспечивающие доступ пользовательских приложений к уровню дополнительных услуг
U - API интерфейсы, обеспечивающие доступ к основным сетевым услугам.
L - API интерфейсы, обеспечивающие доступ к виртуальным сетевым устройствам, позволяя манипулировать состояниями сетевых ресурсов.
ССМ - интерфейс управления соединениями, т.е. набор открытых протоколов доступа к физическим элементам сети.
Пользовательские приложения
УровеньдополнительныхуслугУровеньдополнительныхуслугV интерфейс
Уровеньдополнительныхуслуг
Уровеньдополнительныхуслуг
Алгоритмы предоставления дополнительных услуг,содаваемых сетевыми операторами, пользователямии другими сторонами
U интерфейс
интерфейсинтерфейс!~~ Алгоритмы маршрутизации и управления соединениями,получения доступа к сети!~~ Алгоритмы маршрутизации и управления соединениями,получения доступа к сетиУровеньосновныхсетевых услугУровеньосновныхсетевых услуг
интерфейс
интерфейс
!~~ Алгоритмы маршрутизации и управления соединениями,получения доступа к сети
!~~ Алгоритмы маршрутизации и управления соединениями,получения доступа к сети
Уровеньосновныхсетевых услуг
Уровеньосновныхсетевых услуг
|—! УровеньВиртуальное сетевое устройствовиртуальныхIсетевых устройств|—! УровеньВиртуальное сетевое устройствовиртуальныхIсетевых устройствФизические элементы ( аппаратное обеспечение)Физические элементы ( аппаратное обеспечение)Рис. 3.3 Структура модели Р1520Рис. 3.3 Структура модели Р1520ФизическийуровеньФизическийуровень
|—! Уровень
Виртуальное сетевое устройствовиртуальных
Iсетевых устройств
|—! Уровень
Виртуальное сетевое устройствовиртуальных
Iсетевых устройств
Физические элементы ( аппаратное обеспечение)
Физические элементы ( аппаратное обеспечение)
Рис. 3.3 Структура модели Р1520
Рис. 3.3 Структура модели Р1520
Физическийуровень
Физическийуровень
ССМ интерфейс
Группа Р1520 представила свои идеи реализации этой модели в 1999 на выставке Те^сот^Э, где авторам и удалось с ними познакомиться. Основные усилия группы сегодня направлены на стандартизацию L-интерфейса для IP-маршрутизаторов и ДГМ-коммутато- ров, а также ССМ-интерфейса для АГМ коммутаторов.
Международный консорциум Softswitch
Консорциум ISC (The International Softswitch Consortium) был создан в мае 1999 года и на данный момент включает в себя примерно 150 членов, среди которых Alcatel, Cisco Systems, Clarent Corporation, Samsung Electronics Co. Ltd., Lucent Technologies, Nokia Telecommunications, Siemens Carrier Networks LLC, Radcom Ltd., VocalTec Communications, Ltd., Marconi Communications, Level 3 Communications, Motorola Inc. Имеется шесть рабочих групп - группа приложений (Applications WG), группа управления устройствами (Device Control WG), группа маркетинга (Marketing WG), группа SIP (SIP WG), административная группа (Session Management WG) и юридическая группа (Legal Intercept WG).
Своей основной задачей консорциум считает развитие и поддержку открытых архитектур, протоколов и API-интерфейсов, что предполагает значительное упрощение развертывания услуг, как для производителей систем, так и для операторов услуг Консорциум фокусирует своевнимание на вопросах взаимодействия и сертификации услуг реального времени.
Архитектура консорциума Softswitch различает 5 плоскостей - плоскость данных, плоскость приложений, плоскость управления связью, плоскость транспорта и плоскость эксплуатационного управления. Столько же стандартов уже принято ISC. Протоколы для интерфейсов одноуровневых компонентов включают в себя Н.323, SIP, RTP и RTSF^ а также протоколы MGSP и MEG АСО, предусматривающие декомпозицию компонентов на управляющие и управляемые [5].
Форум MSF
Форум MSF (Multiservice Switching Forum) был основан компаниями Cisco, Bellcore и MCI WorldCom в ноябре 1998, а сейчас насчитывает 57 участников. Он получил широкую поддержку сетевых операторов (участниками форума являются В[ SBC, US West, Telia, Telecom Italia, France Telecom и NTT), производителей телекоммуникационного оборудования и оборудования передачи данных, а также производителей различных компонентов аппаратных и программных средств. Цель MSF заключается в том, чтобы ускорить внедрение открытых коммуникационных систем с гибкой поддержкой широкого спектра сетевых услуг на базе различных технологий.
Общая структура форума MSF представлена на рис. 3.6. Совет директоров определяет общие задачи, общую политику и структуру организации. Состав совета открыто выбирается из кандидатов, выдвинутых членами организации. Как и большинство стандартизующих организаций, форум MSF включает в себя несколько комитетов;
в их числе - технический комитет, комитет маркетинга и обучения, комитет взаимодействия с другими промышленными группами.
В своей работе MSF опирается на протоколы и стандарты, разработанные другими организациями. На рис. 3.4 обозначены проблемные области мультисервисной сети и указаны организации, занимающиеся стандартизацией в этих областях.
Рис. 3.4 Проблемные области MSF и разработчики стандартов
Одно из фундаментальных положений, формирующих основу MSF, - использовать сходство в архитектуре IP-маршрутизаторов, коммутаторов Frame Relay и ДГМ-коммутаторов. Разрабатываемое оборудование должно стать общей платформой для систем с коммутацией пакетов данных любых форматов. Такое решение позволяет поддерживать на этой платформе широкий спектр услуг.
Консорциум Parlay Group
Консорциум Parlay Group был сформирован в марте 1998 г. для создания спецификаций API-интерфейса, обеспечивающего доступ
к сетевой информации и управление сетевыми ресурсами. Изначально соглашение заключили фирмы ВТ Ulticom, Microsoft, Nortel Networks и Siemens. В мае 1998 года оно было обнародовано, а уже в ноябре 1998 было объявлено о завершении 1 стадии работы над техническими спецификациям, и в декабре были изданы первые версии технических требований и проведена демонстрация гипотетического приложения Guaranteed Call Delivery. Это приложение обеспечивало возможность, работая вне области сетевого оператора, предлагать услуги конечным пользователям, используя некоторые из ключевых возможностей версии 1 Parlay API. В начале 1999 года к соглашению присоединились 6 новых членов: AT&T Cegetel, Cisco, Ericsson, IBM и Lucent, и были начаты работы над стадией 2, посвященной, прежде всего, управлению обслуживанием вызова, обменом сообщениями и защитой. Работы стадии 2 сосредоточены также на расширении функциональных возможностей API, особенно в областях беспроводных услуг и IP-услуг, включая конвергенцию беспроводных сетей, ТфОП и сетей IR Хронология выпуска спецификаций Parlay API представлена в таблице 3.4.
Таблица 3.4 Хронология спецификаций Parlay API
Версия
Дата
Причина изменений
1.0
4 декабря 1998
Первое издание для промышленной оценки
1.1
7 мая 1999
Второй выпуск
1.2
10 сентября 1999
Третий выпуск с расширенным механизмом уведомления о событиях
2.0
24 января 2000
Фаза 2: Первый выпуск для оценки промышленностью
2.1
26 июня 2000
Незначительные редакционные изменения
2.1.1
20 ноября 2000
Незначительные изменения диаграмм и связанных с ними описаний
Деятельность консорциума Parlay API направлена на создание универсального интерфейса программирования для управления сетевыми ресурсами. Исторически возможности такого управления контролировались и эксплуатировались исключительно сетевыми операторами, что частично было обусловлено несовместимостью стандартов, но также и задачей обеспечить защиту и целостность сети. Однако чтобы обеспечить гибкость ввода новых услуг; приложения должны создаваться, тестироваться и эксплуатироваться операторами услуг вне сетевой области. Необходимо обеспечить доступ к сетевой информации извне и иметь возможность контролировать извне сетевые ресурсы, что может быть достигнуто благодаря использованию прикладного программного интерфейса API между прикладным уровнем и уровнем компонентов услуг; как это показано на рис.3.5.
APIAPIN SMHaxousduN SMHaxousdu""MHexouMdu""MHexouMduОбласть приложенийОбласть приложений
API
API
N SMHaxousdu
N SMHaxousdu
""MHexouMdu
""MHexouMdu
Область приложений
Область приложений
Компоненты услуг
Физические сети
Область сетевого оператора
固 41
Рис. 3.5 Использование прикладногопрограммного интерфейса Parlay API
Управление сетевыми возможностями посредством интерфейса API не означает, что сеть общего пользования станет более открытой. Скорее, сетевые возможности станут «видимыми», сохраняя при этом эффективность и защиту. Обеспечить целостность и защиту сети - одно из главных требований к разработке API-интерфейса и его дополнений. Используя API-интерфейс, можно добиться быстрого создания и ввода в коммерческую эксплуатацию новых услуг, отвечающих потребностям конкретного потребителя. Архитектура Parlay API содержит интерфейсы нескольких категорий. Первая версия Parlay API охватывает интерфейсы между клиентскими приложениями и услугами Parlay, а также базовый API интерфейс, который обеспечивает возможности, необходимые для организации интерфейсов услуг Во второй версии добавились интерфейсы для поддержки административных функций внутри предприятия и для поддержки услуг Parlay сторонними производителями. Алгоритмические аспекты Parlay API будут рассмотрены в главе 9.
Еще раз о TAPI, TSAPI и JTAPI
Об этих интерфейсах внешнего управления алгоритмом обработки вызова в АТС уже говорилось ранее, но важность и драматические аспекты их стандартизации говорят о необходимости отразить эти аспекты и здесь, что, впрочем, было также обещано в конце предыдущей главы.
Итак, об API. Внешние управляющие системы (а это, как правило, мощные серверы), реализованные на базе технологий компьютерной телефонии, являются чем-то вроде локальных SCP Интеллектуальной сети и обеспечивают возможность модифицировать алгоритмы управления обслуживанием вызовов силами технического персонала. Иными словами, этот персонал может доработать и модифицировать стандартное программное обеспечение, что позволяет оператору или администратору самостоятельно разрабатывать правила управления обработкой вызовов от разных абонентов. Но это еще не все. Помимо собственно управления /^ГС, такой сервер может взаимодействовать и с другими устройствами, а также с корпоративной базой данных.
Как уже отмечалось, сегодня существуют две основные схемы реализации интерфейсов АР! - Telephony Services API (TSAPI), предложенная Novell и AT&T, и Telephony API (TAPI), разработанная Microsoft. И тот, и другой стандарт предусматривает, что API принимает запросы CTI-приложений и направляет их к телефонным системам, которые и выполняют команды. Различие между стандартами заключается в том, как обрабатываются запросы, TSAPI предусматривает их обработку на файловом сервере, a TAPI - на рабочей станции.
Спецификация TSAPI выпущена в марте 1994 года, ориентирована на платформы PC и является протокольным стеком, не требующим, чтобы изготовитель полностью открывал интерфейс коммутатора. Возможности первой версии TSAPI оказались не столь широкими, хотя эта версия являлась транслятором CSTA для весьма популярных в России учрежденческих АТС семейства Definity. Версия 2 (1995) интерфейса TSAPI распространила API на другие УАТС и компьютерные системы, включая OS/2, Macintosh, UnixWare и Windows NT Более новые версии TSAPI отличаются лучшей согласованностью с CSTA и поддерживают клиент-серверные технологии Windows NT и сетевые аспекты TCP/IR
Microsoft и Intel совместно разработали спецификацию TAPI - прикладного интерфейса телефонной связи для тех же задач, что и TSAPI. Как неотъемлемая часть разработанной Microsoft открытой архитектуры служебных функций для среды Windows (WOSA), TAPI функционирует в среде сетевого терминала Windows и также основан на архитектуре клиент-сервер. Ориентированный с самого начала на максимальную независимость от телефонного оборудования, 7Api содержит набор функций, позволяющих управлять с персонального компьютера под Windows разнообразными телефонными устройствами, отвечать на вызовы, набирать нужный номер или переключать связь с одного номера на другой. Программисты разрабатывают компьютерно-телефонные приложения, используя эти функции TAPI, а те, в свою очередь, дают приложениям
возможность обращаться к TAPI-совместимым устройствам. Производители аппаратных телефонных средств поставляют свои устройства (например, телефоны, факсы, модемы) вместе с программными модулями или драйверами, поддерживающими интерфейс TAPI. В качестве одного из простейших примеров, иллюстрирующих подход TAPI, можно привести задачу написать приложение, в котором требуется, чтобы устройство (к примеру, телефон) инициировало телефонный вызов. Для этого программист определяет в TAPI функцию GetDialTone, необходимую для того, чтобы до набора номера обнаружить сигнал «Ответ станции». В свою очередь, TAPI обращается к драйверу, поставляемому вместе с телефоном, и исполняет фрагмент программы, дающий указание телефону включиться и набрать номер, если сигнал распознан. Реальные программы управления разными устройствами отличны одна от другой, но это не должно беспокоить программиста - его задача состоит лишь в том, чтобы написать код, отвечающий за выполнение задания, которое было передано через интерфейс TAPI.
TSAPI тоже используется для управления обслуживанием вызовов, однако в нем применяется иной подход. Как и в случае с TAPI, программные приложения запускаются на рабочих станциях, но запросы телефонного обслуживания передаются через сетевой адаптер на файловый сервер. Сервер распознает запрос и передает соответствующий пакет данных на TSAPI-совместимую УАТС для исполнения. Пакет содержит телефонный номер пользователя и собственно запрос. Если, например, пришел запрос снять трубку, УАТС включит громкоговоритель телефона, и пользователь услышит гудок. Если у пользователя нет встроенной акустической системы, УАТС просто передаст к его телефону вызывной сигнал. Аналогично, если в запросе приложения указан номер телефона, УАТС передаст этот номер.
Кроме того, пользователи Windows NT 4.0 могут с помощью TAPI имитировать для Windows NT Server действия, аналогичные действиям TSAPI компании Novell. Администраторам самим можно решать, какая конфигурация для них удобнее.
Преимущество архитектуры TSAPI состоите том, что телефонные переговоры практически не загружают локальную сеть. Несколько пакетов управления, передаваемых по локальной сети, оказывают на ее загрузку ничтожное (по сравнению с потоком данных при двустороннем разговоре) влияние. TSAPI обеспечивает передачу информации только о начале и о завершении разговора, а прочие функции управления, например, функции управления переключением связи, работают в обычном режиме, тогда как TAPI в процессе обслуживания вызова передает по сети информацию о значительно большем числе событий.
Выбор между TAPI-приложениями и TSAPI-приложениями определяется несколькими факторами. Во-первых, TSAPI - это модуль, который загружается и контролируется средствами NetWare, без них его запустить нельзя. Во-вторых, некоторые приложения поддерживают только один интерфейс, так что выбор зависит от того, с каким приложением захочет работать пользователь.
Таким образом, если пользователь подключен к NetWare, и выбранное им приложение поддерживают и TAPI, и TSAPI, то решение зависит от загрузки сети. Для организации, устанавливающей новое оборудование, лучшим будет использование решения на базе TAPI и установка высокоскоростной локально访 сети, такой, например, как Fast Ethernet или FDDI. Скоростная локальная сеть поддерживает передачу и речи, и данных. Телефоны можно подключать прямо к персональному компьютеру, так что телефонные вызовы не будут перегружать сетевой сервер. Эта конфигурация дает и другие выгоды. Одна из них - экономия на телефонной проводке; другая - возможность покупать менее дорогие телефоны, поскольку всякие дополнительные функции, в частности, повторный набор, кратковременный обрыв шлейфа (flash), режим удержания (hold), телефонные конференции, счетчик времени, определитель номера и т.п. могут быть встроены в приложение, запускаемое с компьютера.
Итак, hTSAPI, и 7API создавались, в первую очередь, с учетом задач своих создателей и их сторонников. Наибольшее достижение, в контексте данной главы, состоит в том, что пользователи получили надежные и поддерживаемые стандарты, созданные мощными компаниями-разработчиками программного обеспечения. В конечном итоге, пользователи в 3丁。访 сложной ситуации выиграли, поскольку они имеют возможность доступа из программного обеспечения своих систем к любому устройству, поддерживаемому тем и другим стандартом, лишь бы программное обеспечение их систем также соответствовало этим API. Следует отметить, что это оказалось возможным только благодаря поддержке со стороны создателей крупных операционных систем и производителей оборудования, иначе интерфейсы TSAPI и TAPI имели бы мало шансов на широкое признание, а компьютерно-телефонная интеграция могла бы остаться ограниченной достижениями первого поколения систем CTI, которые рассматривались в главе 2.
И, наконец, прикладной интерфейс программирования телефонных задач J7API представляет собой решение на основе Java, разработанное совместно Sun Microsystems, Lucent Technologies, IBM, и Nortel. Это - кросс-платформенное неоднородное решение, использующее высокоэффективные Java-приложения для компьютерной телефонии. JTAPI содержит дополнительные функции компьютерной телефонии для Интернет, что дает возможность создавать приложения на основе Web, в которых интегрированы браузер-приложения и функции Call-центра, рассматриваемые далее в этой книге.
ECTF
Основанный в 1995 году, форум ECTF представляет собой объединение поставщиков, разработчиков и потребителей оборудования CTI. Среди участников форума такие компании как Nortel, Ericsson, HR Microsoft, Lucent, Motorola, Dialogic, Natural MicroSystems и ряд других. Работа форума направлена на обсуждение, разработку и тестирование вариантов многоуровневого взаимодействия компонентов CTI внутри ТфОП, IP-сетей, а также внутри ведомственных и корпоративных сетей. Основная цель форума - разработка соглашений о взаимодействии аппаратных и программных решений компьютерной телефонии в части управления обслуживанием вызова и управления медиа- ресурсам и. Использование стандартов ECTF разработчиками систем CTI позволяет предоставить покупателям оборудования большую свободу выбора (т.е. возможность строить готовое решение из оптимального набора компонентов разных производителей) ,ускорить процесс внедрения новых услуг за счет наличия открытых интерфейсов, обеспечить масштабируемость систем и т.п. Не углубляясь в организационную структуру форума, остановимся лишь на технических аспектах, т.е. на деятельности технического комитета ЕСТЕ Можно выделить следующие основные направления деятельности этого комитета:
Вопросы конвергенции компьютерного и телефонного оборудования;
Обеспечение согласованности открытых интерфейсов оборудования CTI;
Разработка стандартизирующих документов, обеспечивающих возможность создания открытых, расширяемых, объединяемых в сеть платформ и приложений компьютерной телефонии, а также стандартов, обеспечивающих взаимодействие оборудования СТ выпускаемого разными производителями.
Технический комитет имеет несколько рабочих и исследовательских групп, деятельность которых охватывает области взаимодействия приложений и устройств, структуры, администрирования, обработки вызова, и платформ компьютерной телефонии.
Стандарты ECTF разделены наследующие группы:
серия М.ХХХ- административные услуги;
серия S.XXX - программные интерфейсы;
серия Н.ХХХ- аппаратное обеспечение и интерфейсы;
серия С.ХХХ - управление обслуживанием вызова;
серия R.XXX- модель учета статистической информации;
серия А.ХХХ - интерфейсы приложений.
Остановимся кратко на основных стандартах этих групп, а более подробное рассмотрение некоторых из нихотложим до глав 9,10 и 11.
Спецификация С.001 определяет модель управления обслуживанием вызова и включает в себя описания услуг управления и их интерфейсы. Основой спецификации послужили предшествовавшие работы в этой сфере - стандарты форума ЕСМА и консорциума CTI Encyclopedia.
Н.100/Н.110 - спецификации шин компьютерной телефонии для систем PCI/compact PCI. Шина Н.110 представляет собой дополнительную шину в compact PCI конструктиве и позволяет одновременно коммутировать до 4096 каналов на скорости 64 Кбит/сек каждый.
S.100 - спецификация прикладного программного интерфейса для разработчиков приложений компьютерной телефонии, определяющая архитектуру клиент-сервер, в которой клиентское приложение использует набор услуг для работы с ресурсами оборудования. В рамках модели базового процесса обслуживания вызова описан прикладной программный интерфейс API, позволяющий разработчикам различных приложений (факс-серверов, IVR, Call-центров и др.) упростить написание прикладных пакетов программ. В качестве главной цели реализации программного интерфейса в стандарте S.100 декларируется независимость созданных прикладных средств от аппаратуры и от драйверного программного слоя разных производителей.
S.200 - транспортный протокол передачи команд SJ 00 к серверу и ответов сервера - к клиентскому приложению.
S.300 - спецификация взаимодействия платформ услуг S.100 с ресурсами компьютерной телефонии, обеспечивающая независимость программного обеспечения от производителей аппаратуры.
S.900 - спецификация адм и н истрати в н ых аспектов построения систем компьютерной телефонии. Специфицированы процедуры расп редел ен н о го управления, разрешения доступа ксистемам. Стандарт описывает механизмы построения программныхсистем, управление которыми сильно упрощается за счет использования специфицированных процедур доступа к данным.
М.100 ~ спецификация административных услуг, которые позволяют создавать административные приложения, управляющие запуском и отключением серверов компьютерной телефонии, их конфигурацией и услугами. Основными функциями протокола М.100 являются функции контроля устойчивости работы системы (контроля инициирования ресурсов и других элементов сервера). В случаях возникновения неисправностей протокол М.100 обеспечивает остановку сервера без потери данных.
R.100 - спецификация моделей и алгоритмов учета статистической информации о работе операторских центров, включающая в се-
бя модель обслуживания вызова, минимальный набор данных, структуру записей в базе данных.
Рис. 3.6 Структура стандартов ECTF
Несмотря на неоднозначные оценки будущего форума ECTF, сегодня эта организация 一 все еще ведущий авторитет в области стандартов компьютерной телефонии. Причины же неоднозначности оценок связаны с тем, что исходные материалы для стандартизации, как правило, предоставляются компанией, которая к моменту начала стандартизации больше других преуспела в определенном направлении разработок, так что в ряде случаев подготовленные стандарты несут на себе ярко выраженный корпоративный отпечаток. Кроме того, хотя ECTF работает быстрее упоминавшихся выше традиционных стандартизирующих организаций, времени на разработку и согласование стандартов уходит довольно много, и в ряде случаев уже согласованные стандарты опираются на не самые новые и перспективные подходы и технологии (с точки зрения разработки аппаратных и программных средств).
Впрочем, по поводу последнего замечания об отставании стандартов от развития технологии, уже было кем-то замечено, что стандарты не могут не отставать от времени, ибо именно это отставание и делает их стандартами.
Глава 4 Услуги компьютерной телефонии
Телефонный разговор находится на полпути между искусством и жизнью. Это разговор не с человеком, а с образом, который складывается у тебя, когда ты его слушаешь.
Андре Моруа
IVR и аудиотекс
4-1-1 Основы IVR
Системы, о которых пойдет речь в этом разделе, представляют собой, пожалуй, самое разнородное и разнообразное семейство систем компьютерной телефонии. Говоря о системах интерактивного речевого ответа (IVR - Interactive Voice Response), авторы включили в эту категорию не только традиционные системы предварительного диалога системы с абонентом, применяемые в офисах, которые, собственно, и называются IVR, но и другие автоматизированные системы, функционирующие по аналогичным принципам. Это, например, автоматизированные справочно-информационные системы Аудиотекс, системы речевой почты, системы телеголосования, реализованные на базе оборудования компьютерной телефонии, и др. Особое место занимают в этом разделе системы универсального обмена сообщениями (Unified Messaging), т.к. эта технология, возможно, является одной из самых перспективных в плане совершенствования офисной работы. Мы постарались коснуться и безусловно перспективных, но объективно еще не готовых к широкому коммерческому
применению технологий «текст-речь» (text-to-speech) и распознавания речи. Но, впрочем, обо всем по порядку.
Своим появлением системы IVR обязаны, прежде всего, резкому росту количества входящих вызовов, которые приходилось обрабатывать сотрудникам в компаниях и офисах. При этом значительная часть времени сотрудников тратилась на рутинные операции, связанные с получением от клиента первичной информации, если речь идет об операторском центре, или на организацию связи клиента с нужным отделом или рабочим местом. «Ивана Ивановича? Сейчас соединю...»
Впрочем, последняя проблема обусловлена, главным образом, применением наиболее популярного и дешевого способа включения офисных УАТС в городскую АТС - по двухпроводным аналоговым АЛ, - что исключает возможность прямо набрать «из города» номер нужного абонента УАТС. Тем не менее, эту проблему тоже нельзя сбрасывать со счетов, т.к. на рутинные операции тратится дорогостоящее рабочее время сотрудников компании.
Что касается Call-центров, о которых речь пойдет в следующих главах, то время, затрачиваемое на получение первичной информации, часто бывает сопоставимо со временем обслуживания абонента. А ведь во многих случаях можно не только обработать запрос абонента автоматически, но так же автоматически сформировать ответ на этот запрос.
А сколько времени тратится на многократные попытки отправить факс, всякий раз терпя неудачу из-за занятости вызываемого номера или из-за плохого качества соединения!
Одним словом, поле деятельности для разработчиков открывалось огромное. И в середине 80-х годов на рынке появились первые системы, способствовавшие автоматизации офисной деятельности.
На тот момент единственным способом получить от абонента дополнительную информацию после установления соединения был (да, в общем-то, и остается до сей поры) многочастотный DTMF-дона- бор. Отсутствие у значительной части абонентов российской ТфОП возможности многочастотного набора (и, как следствие, наличие у них телефонов без возможности переключения в режим DTMF) 一 вот основной фактор, до недавнего времени сдерживавший внедрение таких систем в России. Сейчас, правда, эта проблема, ко всеобщему удовлетворению, постепенно уходит в прошлое. Конечно, были (и продолжаются, главным образом, в странах бывшего СССР) попытки создать детекторы для приема импульсного донабора, однако низкая достоверность распознавания дополнительных цифр номера в таких системах не оставляла им шансов на широкое коммерческое применение.
Впрочем, в странах, где появились и широко используются сегодня системы IVR, механические АТС уже практически не применяются, и проблемы поддержки DTMF в телефонных аппаратах не существует. Поэтому основная масса систем IVR и по сей день работает по одним и тем же принципам - многоуровневое меню с навигацией при помощи DTMF-донабора. В современные системы IVR также могутбыть интегрированы функции синтеза речи и функции поддержки факсимильных сервисов, которые подробнее рассмотрены в следующих разделах данной главы, а типовая структура комплекса IVR приведена на рис. 4.1.
Рис. 4.1 Типовая архитектура систем IVR и Аудиотекс
Функции, реализуемые системами IVR, как правило, определяются областью применения той или иной системы. В Call-центрах, как уже упоминалось, на системы IVR возлагаются функции получения от абонента первичной информации. Поясним, о чем идет речь. Чтобы обеспечить оператора Call-центра максимально полной информацией об обратившемся к нему клиенте до начала его обслуживания, сведений, получаемых с помощью телефонной сигнализации (которые ограничиваются данными о номере и категории вызвавшего абонента), недостаточно. Без применения систем IVR все необходимые данные оператору приходится получать путем диалога с клиентом в ручном режиме, это отнимает значительное время и повторяется при каждом новом вызове. Система IVR берет на себя всю рутинную работу. Следуя инструкциям речевого меню, абонент вводит недостающую информацию в то время, пока его вызов находится в очереди. Это может быть код запроса (причина обращения), по которому вызов будет направлен к определенной группе операторов, номер счета и секретный код (если речь идет о системах телебанкинга) и т.д.
Таким образом, к моменту начала обслуживания вызова собственно оператором в базу данных компании с помощью системы IVR уже бывает внесена значительная часть информации, которая сразу становится доступной персоналу центра, ответственному за обслуживание вызовов.
Побуждающим мотивом к следующему шагу в развитии такого рода систем явилось стремление компаний, применяющих оборудование IVR, не только автоматически получать информацию от абонента, но и, по возможности, автоматически сообщать ему необходимые сведения. Самой простой и, в то же время, самой распространенной была и остается ситуация, когда абоненту необходимо получить информацию, которая может быть представлена в виде стандартных фраз с изменяющимися сегментами (как правило, числительными). Таковой является, например, информация о состоянии счета при обращении в банк, информация о времени прибытия/от- правления поездов или самолетов при обращении в транспортные справочные службы и т.п. В этом случае абонент вводит в режиме DTMF-донабора номер своего счета или, скажем, номер интересующего его рейса. Система передает запрос к базе данных, откуда извлекается и передается обратно в систему компьютерной телефонии необходимая цифровая информация, которая вставляется в стандартную фразу, а затем готовая фраза «произносится» абоненту.
Здесь приведен самый простой пример, т.к. в реальности меню могут содержать в себе блоки определения прав абонента, различные системы ветвления и т.д. Но принципы остаются теми же: для ответа на вопрос абонента система компьютерной телефонии на основании данных, введенных абонентом, автоматически формирует и передает запрос к базе данных, получает на него ответ и озвучивает его для передачи абоненту.
Что касается упоминавшихся выше Call-центров, то статистика свидетельствует, что при дооснащении их развитыми системами IVR, большая часть вызовов, цель которых заключается в получении какой-либо типовой информации, обслуживается вообще без подключения оператора к разговору.
Аудиотекс
Именно с использованием рассмотренных выше алгоритмов работают весьма популярные в мире системы Аудиотекса - автоматизированные справочно-информационные комплексы, предоставляющие абонентам широкий спектр информации: прогноз погоды, курс акций или валюты, транспортные расписания и многое, многое другое.
Одной из функциональных возможностей, крайне важных для успешного применения подобных систем, является возможность адаптации комплекса к нуждам конкретного пользователя. На практике
такая адаптация сводится к тому, чтобы произвольно формировать структуру меню, гибко ее изменять и так же гибко формировать структуру передаваемых пользователю ответных фраз. Сегодня практически каждая система имеет встроенный табличный или графический конструктор услуг позволяющий путем несложных манипуляций, во- первых, создать именно ту структуру меню, которая нужна пользователю, а во-вторых, необходимым образом сформировать структуру ответных фраз. Принципы работы этих конструкторов примерно одинаковы.
Меню
Основная идея «конструктора меню» заключается в том, что адресация к услуге - пункту меню - производится по сочетанию номера доступа и кода многочастотного донабора, однозначно соответствующему этому пункту. Сам пункт меню, в свою очередь, может представлять собой собственно информационный ресурс и, возможно, ссылку на следующий пункт меню.
С точки зрения администратора системы, создание пункта меню в дереве справочных услуг выглядит следующим образом:
Создается пустой информационный ресурс, примерно соответствующий по функциям речевому почтовому ящику;
Производится включение его в группу таких же ресурсов;
Создается пункт речевого меню, идентифицируемый последовательностью комбинаций DTMF и п редставл я ющи й собой ссылку на меню более низкого уровня;
Пункты речевого меню вводятся в речевое меню более высокого уровня, называемое «родительским». Внутри одного «родительского» меню последовательности DTMF-комбинаций, которыми идентифицируются отдельные его пункты, должны быть уникальны;
Для каждого речевого меню создается привязка «группа информационных ресурсов - речевое меню»;
Для меню самого верхнего уровня дополнительно создается привязка «номер доступа - речевое меню»;
Производится заполнение информационного ресурса.
Примерархитектуры такого конструктора услуг приведен на рис. 4.2.
Несмотря на широкий спектр услу「доступных с помощью систем IVR, основное их ограничение - необходимость пользоваться фиксированными схемами формирования ответных фраз и (если это предусмотрено алгоритмом предоставления услуги) вести диалог с помощью DTMF-донабора. Сводку новостей, например, с помощью подобной технологии по телефону уже не зачитаешь, а между тем
(если взять, например, услуги, предоставляемые операторами мобильной связи с использованием технологий SMSmWAP), это мог бы быть один из самых востребованных видов услуг
Рис. 4.2 Реализация конструктора услуг в Интеллектуальной платформе ПРОТЕЙ
Стремление создать абонентам максимальные удобства пользования такими системами определило основное направление их эволюции -совершенствование способов ведения диалога «абонент- система». Речь здесь идет о технологии синтеза речи (text-to-speech) и о технологии распознавания речи (speech recognition). Обе технологии в том или ином виде уже применяются в компьютерных системах, однако проблемы и возможные перспективы применения их в системах IVR заслуживают того, чтобы остановиться на этих технологиях подробнее.
Начнем с более очевидной технологии синтеза речи. Сегодня она уже практически готова для коммерческого применения, разработано множество библиотек, которыми могут пользоваться сторонние разработчики систем CTI. Основная проблема заключается в адаптации систем синтеза речи к конкретному языку (в частности, это касается и русского языка: главными недостатками русифицированных систем сегодня являются отсутствие «человеческих» интонаций и проблемы с логическими ударениями в сконструированных фразах).
Стратегическим направлением развития технологии синтеза речи является обеспечение возможности зачитывать пользовате-
лю по телефону информацию, содержащуюся на Web-страницах Всемирной паутины. С этой целью недавно разработан язык программирования VoiceXML, предназначенный для управления Web- контентом с помощью речевых команд или команд DTMF. И именно в этом направлении сейчас ведутся основные работы. Создаваемые устройства должны будут сопоставлять телефонный номер, или DTMF-комбинацию, набранную абонентом, с определенными адресами URL и затем зачитывать информацию с выбранного сайта с использованием технологии синтеза речи. В качестве примера можно привести систему, анонсированную компанией Lucent Technologies как Speech Server.
Значительно менее очевидна технология распознавания речи. Главная перспективная цель приложений, распознающих речь, - позволить абонентам получать информацию или выполнять необходимые транзакции в режиме беседы. Распознавание обычной человеческой речи до сих пор ещё не стало реальностью, хотя ухе было изрядно разрекламировано. Дело в том, что поуровню сложности системы распознавания речи можно разделить натри большие группы. Покажем это на примерах возможного диалога между системой и пользователем.
Замена многочастотого набора
Подсказка системы: «Для получения информации о состоянии счета, наберите или скажите: «Один»».
Ответ абонента: «Один».
Режим диалога по шаблону
Вопрос системы: «Вы хотите проверить состояние счета или получить информацию о расценках?»
Ответ абонента: «Проверить» (вариант - «проверить счет») или «расценки».
Живой язык
Вопрос системы: «Какой вид транзакций Вы хотите выполнить?»
Ответ абонента: «Проверить состояние счета».
Первый способ наиболее прост в реализации и является сегодня самым распространенным и отлаженным. Однако его возможности существенно ограничены. Фактически, словарь содержит только числительные (как правило, из первой сотни) и ключевые слова «Да» и «Нет». Этот способ может служить неплохой альтернативой многочастотному набору, для чего он, главным образом, и предназначен.
Второй способ значительно более гибок, позволяет использовать довольно широкий набор команд и избавляет абонента от необходимости вводить длинные комбинации цифр. Однако непростой задачей является подбор ключевых слов и фраз.
Конечно, идеальным вариантом было бы распознавание живой речи в потоковом режиме. Задача машинного распознавания такой речи без использования сложных обучающихся систем или без настройки систем на конкретных пользователей привлекает внимание специалистов уже долгое время. Тем не менее, продвинуться в этом направлении пока удалось относительно недалеко, и постоянно возникают разного рода проблемы, осложняющие широкое внедрение этой технологии. Речь идет, главным образом, о необходимости корректно воспринимать совершенно разные голоса, диалекты, дикцию (по оценкам экспертов технологию распознавания речи можно считать доведенной до необходимого уровня, если с ее помощью надежно и точно распознается не менее 90% ответов). Решению именно этих проблем и посвящены основные работы, проводимые в направлении развития техники распознавания речи. Нельзя упускать из виду и экономический аспект - ведь применение той или иной технологии должно быть экономически целесообразным, а ценовые рамки систем CTI довольно жестки.
Сравнить вышеупомянутые технологии по их возможностям, стоимости и времени, затрачиваемом на разработку, позволяет рис.4.3.
Распознавание "живой" речиРаспознавание "живой" речиСложность и время разработки
Распознавание "живой" речи
Распознавание "живой" речи
■ Диалог "по шаблону'
. Замена многочастотного набора
(распознавание ограниченного набора слов) 1111
Удобство и гибкость
Рис. 4.3 Варианты применения технологии распознавания речи
Тем не менее, несмотря на некоторый скептицизм, проскальзывавший выше, решить все эти проблемы - означало бы существенно продвинуться по пути к реализации естественного интерфейса пользователя.
Услуги, предоставляемые на базе систем компьютерной телефонии с использованием механизмов автоматизированного диалога IVR и компьютерной обработки полученных от пользователя данных, могут быть крайне разнообразными и не ограничиваются описанными выше. В заключение этого параграфа целесообразно сказать несколько слов об услугах, которые успешно реализуются на базе систем CTI и весьма популярны, но имеют лишь косвенное отношение к системам IVR. Речь идет о системах оповещения и системах записи телефонных переговоров.
Системы оповещения
Системы оповещения - это технологические системы, которые обычно используют либо для оперативного оповещения большого количества сотрудников (например, перед селекторными совещаниями, при чрезвычайных ситуациях и т.д.), либо для оповещения о задолженности (что часто делают телекоммуникационные операторы). Сейчас коммерческие структуры пытаются найти для подобных систем новые ниши. Дело в том, что при проведении разного рода маркетинговых акций коммерсантам хотелось бы иметь возможность извещать о своих новостях максимально широкий круг потенциальных клиентов. Давно существует, широко используется в Call-центрах за рубежом и пользуется популярностью компьютерная приставка под названием «Predictive Dialer».
Однако уже сегодня в ряде случаев можно обойтись без помощи оператора. Грамотно построив диалог с абонентом (например, используя для его ответов DTMF), можно с минимальными затратами провести маркетинговое исследование или рекламную акцию в автоматическом режиме. Еще более широкие возможности появятся при широком внедрении технологии синтеза речи. Правда, до сих пор остается открытым вопрос: а захочет ли абонент «разговаривать» с автоинформатором? Но этот вопрос адресуется не к разработчикам оборудования компьютерной телефонии, а, скорее, - к психологам. Еще одна интересная возможность, которую можно реализовать на базе систем оповещения, - организация индивидуальных информационных каналов (по аналогии с SMS-каналами операторов мобильной связи).
Запись переговоров
Нельзя не упомянуть и о многоканальных системах записи телефонных переговоров, которые предлагают сейчас на рынке многие компании, ведущие разработки в области CTL Функции и назначение этих систем очевидны - фиксация и соответствующее структурирование информации обо всех входящих и исходящих соединениях на контролируемом участке сети, а также запись состоявшихся разговоров. Для чего это нужно? Прежде всего, для повышения производственной дисциплины. По утверждениям руководителей компаний, установивших у себя такие системы, после ввода их в работу сотрудники стали лучше контролировать свои разговоры по телефону (реже стали случаи утечки информации), уменьшились потери рабочего времени на частные беседы. Кроме того, накапливается неплохая база данных для разбора ситуаций с клиентами и партнерами по бизнесу. Такие системы особенно популярны среди банковских и других структур, где очень высока ценность коммерческой информации. Мы намеренно не касаемся нравственного аспекта применения таких систем, предполагая, что везде, сце они применяются, сотрудники компаний
знают об их существовании и выразили добровольное (и притом - письменное) согласие на прослушивание всех своих разговоров.
4.2 Речевая почта
4_2_1 Офисные системы
В предыдущем параграфе мы рассказали о системах IVR, определили функции, ими реализуемые, а также раскрыли преимущества этих систем и упомянули о некоторых аспектах внедрения их на российском рынке.
Здесь же имеет смысл коснуться вопросов функционирования других систем компьютерной телефонии, тоже использующих режим диалога с абонентом и тоже очень популярных. Речь идет о почтовых системах. При всем разнообразии таких систем в сегодняшнем компьютерном и телекоммуникационном мире, их объединяет один ключевой момент. Все они предусматривают возможность отложенной обработки поступающей к ним в том или ином виде информации.
В этом параграфе рассматриваются системы речевой почты, которые, хоть и являются «старожилами» в ряду почтовых услуг компьютерной телефонии, но до сих пор популярны и широко распространены.
По сути, речевая почта - это коллективный централизованный автоответчик. Своим появлением системы речевой почты обязаны возникшей к концу восьмидесятых годов в США тенденции к максимальной интенсификации офисной работы. Именно тогда была сформулирована цель не пропустить ни одного телефонного звонка, т.к. это может привести к упущенной выгоде. Человек, в силу производственных обязанностей, да просто и физически, не может постоянно находиться на своем рабочем месте. И нередко потенциальный клиент, позвонив в компанию тому специалисту, с которым ему требовалось переговорить, слышал в трубке только долгие сигналы контроля посылки вызова. Хотя возникавшие вопросы далеко не всегда требовали срочной реакции (например, нужно было заново отправить плохо прошедший факс или уточнить какой-то технический вопрос), но 一 несколько подобных безуспешных звонков - и впечатление о компании могло испортиться. В лучшем случае, вызов переадресовывался к другому специалисту, который вежливо сообщал (исполняя, по существу, роль автоответчика), что нужной информацией владеет лишь единственный специалист, а его в данный момент нет на месте. Ставить автоответчики на каждое рабочее место, естественно, было нецелесообразно. Примерно тогда и были разработаны компактные системы коллективного пользования (пригодные для применения в офисах), позволявшие принимать (записывать) и хра-
нить достаточно большой объем речевой информации, обеспечивая простой телефонный доступ к ней.
Именно такие системы назывались речевой почтой. Сегодня встроенный или внешний сервер речевой почты является неотъемлемой составной частью практически любой серьезной офисной системы связи. На технологии записи мы остановимся подробнее в главах 10 и 11, посвященных аппаратному и программному обеспечению систем компьютерной телефонии, а сейчас рассмотрим принципы и алгоритмы функционирования речевой почты. Как правило, вызов направляется к такой системе с помощью предварительно запрограммированных в коммутаторе функций переадресации в том случае, если вызываемый абонент занят или не отвечает в течение определенного времени. Почтовый ящик, к которому переадресует- ся вызов, определяется номером вызываемого абонента. Следует упомянуть, что возможен и другой алгоритм, когда для доступа к системе речевой почты выделяется единый номер, а нужный почтовый ящик выбирается с помощью мно гочастотно го донабора. Такой способ чаще применяется операторами, которые предоставляют речевую почту как самостоятельную услугу, но об этом позже.
В некоторых случаях возможность оставить сообщение в речевом почтовом ящике адресата предоставляет система IVR, интегрированная в офисную УАТС.
4.2.2 Алгоритмы речевой почты
Функциональные возможности систем речевой почты определяются требованиями двух сторон, пользующихся их услугами: абонента, оставляющего сообщение в почтовом ящике, и владельца этого ящика. Как правило, абоненту, хе刀 акицему оставить сообщение в почтовом ящике, п редоста вл я ются следующие основные возможности:
прослушивание стандартного ответа системы или личного приветствия владельца почтового ящика;
запись сообщения в почтовый ящик (с вводом, при необходимости, пароля, допускающего к записи).
Пожалуй, здесь больше ничего и не требуется. Указанных двух возможностей, в совокупности с функциями офисной УАТС, в нужной ситуации переключающей вызов к системе речевой почты, вполне достаточно, чтобы абонент, для которого такой способ связи оказался приемлемым, смог им воспользоваться.
Значительно шире спектр возможностей, которые необходимо предоставить владельцу почтового ящика с тем, чтобы речевая почта превратилась из уже привычной дополнительной услуги офисной УАТС в инструмент, позволяющий более эффективно организовать деятельность сотрудников фирмы.
Начнем с алгоритма доступа к почтовому ящику. Здесь возможны несколько вариантов, определяемых сегментом применения той или иной системы. В подавляющем большинстве случаев для доступа владельцев ящиков к серверу речевой почты служит единый номер доступа, а для организации взаимодействия пользователя с сервером применяется традиционная для систем IVR схема. Владелец почтового ящика взаимодействует с сервером, пользуясь многоступенчатой системой меню, навигация по которой производится с помощью многочастотного донабора. SDL-диаграмма приведена на рис. 4.4.
Ожидание кодаоперации менюпервого уровняОжидание кодаоперации менюпервого уровня
Ожидание кодаоперации менюпервого уровня
Ожидание кодаоперации менюпервого уровня
Ожидание кода ' операции для работы с новыми
У сообщениями 丿
Ввод цифры 1 (Повторить сообщение)
Ввод цифры 2 (Сохранить сообщение и перейти к следующему)
Ввод цифры 3 (Удалить сообщение и перейти к следующему)
Ввод цифры 2 (Прослушать сохраненные сообщения)
Ввод цифры 1 (Продлить срок действия п/я)
Сохранение сообщения
Удаление сообщения
Меню работы с новыми сообщениями
Да
У вас нет новых сообщений
Меню первого уровня
следующего сообщения
Меню работы с новыми сообщениями
Меню работы с параметрами
Ввод цифры 3 (Изменить параметры п/я)
Ожидание кодаоперации менюпервого уровняОжидание кодаоперации менюпервого уровня
Ожидание кодаоперации менюпервого уровня
Ожидание кодаоперации менюпервого уровня
Ожидание кода ' операции для работы с новыми 、сообщениями ,
Ожидание кодаоперации для работыс новыми. сообщениями
^ Ожидание кода '
операции для работы
с сохраненными
сообщениями
Ожидание PIN-кодадля продления л/яI 丿
Ожидание кода дляработыс параметрами п/я
Рис. 4.4 SDL-диаграмма процесса обслуживания владельца почтового ящика в системе речевой почты (2 из 4)
Рис* 4、4 SDL-диаграмма процесса обслуживания владельца почтового ящика в системе речевой почты (3 из 4)
Ожидание кода дляработыс параметрами п/я
Текст меню рабо<ь| с фразой приветсвия
Ввод цифры 1 (Измении. фразу принетсгвия)
Ожидание кода для работы с фразой приветсвия
Виод цифры О (Вернуться в меню первого уровня)
Ожидание копа операции меню nepBOi о уровня
Ожидание кода дляработы с фразойприве[свия
Ввод м 巾 рн 1 (Прослушать фразу приветствия)
Фраза приветствия
Текст меню работы с фразой приветствия
Ввод 1Ц1фры 2 (Записать новое приветствие)
Ввод ЦИфр|5| 3 (Восстановить авюматическое пр”ве1Сгвме)
Ввод цифры О (Вернуться в меню работы с параметрами п/я)
Приглашение к записи фразы приветствия
Запись новогоприветствия
Восстановлениеавтоматическогоприветствия
Автоматическое приветствие восстановлено
Ожидание кода дляработы с фразойпривете IвияОжидание кода дляработы с фразойпривете Iвия
Ожидание кода дляработы с фразойпривете Iвия
Ожидание кода дляработы с фразойпривете Iвия
Текст меню работы с фразой приве1СтвияТекст меню работы с фразой приве1Ствия
Текст меню работы с фразой приве1Ствия
Текст меню работы с фразой приве1Ствия
Ожидание кода дляработы с фразойприветствия
Текст меню рабо!ы с фразой приветствияТекст меню рабо!ы с фразой приветствия
Текст меню рабо!ы с фразой приветствия
Текст меню рабо!ы с фразой приветствия
/'\
Ожидание кода дляработы с фразойпривете!вия
/>
Ожидание кода дпнработы спараметрами п/я< _ V
С этой точки зрения исключение составляют системы речевой почты, применяемые операторами мобильной связи. Так как мобильный телефон однозначно идентифицируется информацией АОН, и всегда считается, что им пользуется его владелец, номер почтового ящика при доступе к нему владельца автоматически определяется в этих системах номером вызывающего абонента.
Перейдем теперь к функциональным возможностям, которые системы речевой почты должны предоставлять владельцам почтовых ящиков, чтобы те могли эффективно пользоваться этой услугой. Владелец речевого почтового ящика должен иметь возможность:
гибкой организации работы с полученными сообщениями;
защиты своего почтового ящика от несанкционированного доступа;
управления фразой индивидуального приветствия;
получения уведомлений о наличии сообщений с помощью других почтовых систем (например, электронной почты) или по телефону.
Рассмотрим эти функции подробнее.
Организация работы с полученными сообщениями должна обеспечивать возможность неоднократного прослушивания вновь поступивших сообщений и сохранения или удаления любого из них. Должна обеспечиваться возможность настройки очередности прослушивания поступивших сообщений (в порядке их получения, или в обратном порядке), неоднократного прослушивания или удаления любого из сохраненных сообщений. Безусловно, должна обеспечиваться возможность получения информации о дате и времени поступления в почтовый ящик каждого сообщения. Во многих системах, исходя из необходимости контроля и экономии системных ресурсов, занимаемых для хранения речевых сообщений, вводятся пороги длительности хранения (как правило, разные для прослушанных и не прослушанных сообщений), по достижении которых «устаревшие» сообщения принудительно удаляются.
Небесполезной является и возможность включения и отключения опции прослушивания заголовков сообщений, что может повысить скорость навигации по списку сохраненных сообщений.
Отдельно остановимся на вопросе защиты информации, находящейся в почтовых ящиках, от несанкционированного доступа. Для этого, как правило, используется система паролей и предупредительных блокировок ресурсов. Поясним, о чем идет речь. Каждый речевой почтовый ящик защищается паролем, который назначается владельцем этого ящика и служит гарантией того, что только человек, знающий пароль, получитдоступ к находящейся в ящике корреспонденции или сможет изменить настройки ящика.
Пароль задается с помощью обычного м но го частотн о го набора, для чего в меню владельца почтового ящика предусматривается специальный раздел. Однако, как показывает практика, одного только «пароля владельца» может оказаться недостаточно. В ряде случаев полезной является дополнительная защита почтового ящика «паролем на запись», что позволяет ограничить круг лиц, имеющих возможность оставлять сообщения в этом ящике.
В некоторых системах предусматривается защита от попыток подобрать пароль, для чего после приема несколько раз подряд неверного пароля владельца почтовый ящик блокируется на задаваемое адм и н и страто ро м время.
Чтобы обеспечить надежное взаимодействие абонента с системой при такой ответственной операции, как управление паролями, при замене пароля у владельца почтового ящика обычно запрашивается подтверждение измененного пароля (и пароль заменяется только при совпадении введенных значений).
Индивидуальная фраза приветствия дает возможность владельцу почтового ящика сообщать желающим оставить сообщения какие- либо сведения о себе. Если абонент не записал персонального приветствия, то в ответ на все входящие вызовы, как правило, передается стандартная фраза автоинформатора, например, »Вы позвонили в компанию.... К сожалению, нужного Вам специалиста сейчас нет на месте. Оставьте, пожалуйста, свое сообщение после звукового сигнала».
Еще одна важная функциональная возможность систем речевой почты -поддержка функций уведомления о поступлении сообщений. Реализована эта функция может быть самыми разными способами, но в общем случае они сводятся к двум вариантам:
оповещение владельца ящика о наличии нового сообщения с помощью стандартной фразы, передаваемой либо в виде электронного письма (или SMS - у операторов мобильной связи) на заранее определенный адрес, либо в виде речевой фразы автоинформатора 一 по телефону;
пересылка поступившего сообщения на тот же заранее определенный адрес электронной почты.
Впрочем, последний вариант, гораздо более удобный, уже ближе к системам универсального обмена сообщениями (Unified Messaging) -перспективному направлению эволюции почтовых систем. Но на таких системах мы остановимся подробнее несколько позже. А пока 一 вернемся к системам речевой почты.
Речевая почта в ТфОП
Как уже было упомянуто выше, речевая почта может применяться не только в офисной сфере или операторами мобильной связи. У нее
существует также своя ниша на рынке услуг, предоставляемых телекоммуникационными операторами. На российском рынке 一 это совсем новая услуга, и продвинуться здесь пока удалось относительно недалеко из-за разного рода проблем, осложняющих повсеместное внедрение данной технологии. Тем не менее, примеры предоставления этой услуги существуют, и было бы несправедливо обойти их стороной.
Существует значительная прослойка потенциальных пользователей, для которых услуги пейджинговой или сотовой связи дороги, стационарный телефон у них, по тем или иным причинам, отсутствует, а необходимость в периодическом оперативном получении и передаче информации существует. Это, например, студенты общежитий, уличные торговцы и некоторые другие. Таким пользователям было бы весьма удобно, если бы они могли передать сообщение или прослушать адресованную им информацию, воспользовавшись любым доступным телефоном.
Следует отметить, что применяя системы речевой почты, операторы должны учитывать ряд специфических моментов. Это, главным образом, механизм начисления платы за услуги и способ адресации к почтовым ящикам. По поводу нумерации отметим лишь, что эта задача, как правило, индивидуально решается оператором, внедряющим услугу. Если оператор имеет в своем плане нумерации большой резерв номеров, то речевым почтовым ящикам можно присваивать индивидуальные номера для доступа к ним тех абонентов, которым нужно оставить сообщение. Для владельцев же почтовых ящиков выделяется единый номер доступа, а выбор своего ящика и управление его параметрами производится посредством многочастотного донабора. Такой способ удобен тем, что полностью снимается проблема отсутствия средств многочастотного набора у абонентов сети, однако при его применении очень неэффективно используется имеющаяся номерная емкость. Второй способ более традиционен - и для абонентов, и для владельцев ящиков выделяются групповые номера, а остальная информация вводится путем многочастотного донабора.
Что касается начисления платы, то здесь можно выделить два основных способа, приемлемых для операторов ТфОП: предоплата и выставление счетов за пользование услугой. Очевидно, что предоплата -более эффективный способ (подробнее об этом - в главе 5). Как показывает практика, в этом случае в качестве средства оплаты услуг речевой почты с успехом используются сервисные телефонные карты с PIN-кодом. Для ящиков, активизируемых по сервисной карте, обычно предусматривается ограничение срока действия ящика с соответствующим уведомлением владельца ящика за некоторое время до истечения этого срока, а также продление срока действия почтового ящика адм и н истратором или владельцем с использованием новой сервисной карты.
Психологический аспект
Мы видим, что применение речевой почты дает много полезного. Однако не всё так просто. Как и при использовании любой автоматизированной системы, важную роль здесь играют психологические факторы. Именно ими, на взгляд авторов, определяется весьма невысокая (по сравнению с западными странами) популярность систем речевой почты в России. И дело не только в проблемах с DTMF- набором, о которых шла речь выше (пользуются же те, кому это необходимо, персональными автоответч и кам и с дистанционным прослушиванием поступивших сообщений). Для того чтобы понять, какая информация накопилась в речевом почтовом ящике за время вашего отсутствия, ее, как минимум, необходимо прослушать. Почти анекдотами стали истории о том, какое отвращение вызывает у сотрудников, вернувшихся с длинного заседания, или с обеда, или из отпуска, процесс знакомства с содержимым речевой почты. Придя на рабочее место, сотрудник узнает об энном количестве поступивших на его имя сообщений. Значительная их часть оказывается разнообразными коммерческими предложениями, не представляющими большого интереса, или сообщениями, уже утратившими свою актуальность. Здесь же - ответы от людей, к которым он когда-то обращался, одинокое сообщение от приятеля, когда-то неожиданно раздумавшего зайти в гости, и два звуковых сигнала факса и модема, которые, по неизвестным причинам, оказались вречевом почтовом ящике. В итоге 一 только два сообщения оказываются важными и/или требующими ответа.
При этом нельзя забывать и о том, что вернувшийся на рабочее место после некоторого отсутствия сотрудник, помимо почтового ящика в системе речевой почты, должен просмотреть поступившие на его имя факсы и прочитать электронную почту.
Факс-серверы
Говоря о почтовых системах, нельзя не упомянуть о такой их разновидности, как факсимильные серверы. Хотя концептуально эти системы не представляют большого интереса, но, во-первых, факсимильная связь, несмотря на все новейшие средства телекоммуникации, сдавать позиции не собирается, а во-вторых, перед тем как говорить об эволюции в сторону универсальных почтовых систем, сказать несколько слов об одной из наиболее популярных специализированных почтовых систем просто необходимо.
Итак, если основной предпосылкой к созданию систем речевой почты явилосьжелание не упустить важную информацию, то основным назначением факсимильных серверов является экономия рабочего времени. Действительно, на отправку факсов во всех компани-
ях тратится значительная часть рабочего времени сотрудников. При этом основные затраты времени крайне непроизводительны - либо линия занята, либо вызываемый факс не включен, либо связь обрывается по нескольку раз...
Появление факсимильных серверов стало возможным с развитием технологий цифровой обработки сигналов (DSP - digital signal processing), что позволило автоматически принимать и сохранять факсимильные сообщения, а далее - и передавать их. Вначале факсимильные сообщения представлялись в виде графических файлов, затем, с совершенствованием техники оптического распознавания символов (OCR), появилась возможность хранить факсы в виде документов стандартного формата. Основной принцип работы факс- серверов тот же, что и других почтовых систем, - отложенная обработка поступающей информации.
При использовании факс-сервера отправка факса выглядит следующим образом: вызывается этот сервер, при необходимости определяется правомочность такого вызова, далее вводится телефонный номер адресата (как правило, в режиме DTMF-донабора) и передается собственно факс. Факсимильный сервер принимает этот факс и, следуя определенным правилам (расписание, число попыток, интервалы между попытками), пытается его отправить.
Обязательные требования к функциональным возможностям оборудования предусматривают (помимо поддержки настраиваемой системы расписаний отправки исходящих сообщений) возможность принимать и накапливать сообщения и далее, по запросам, передавать их пользователям. Таким образом обеспечивается возможность работы со входящим (с точки зрения компании - владельца сервера) потоком факсимильных сообщений.
В связи с разработкой стандартов «Факс-через-IP» (рекоменда- цияТ38) полезной функцией факс-сервера является поддержка этого протокола и, соответственно, возможность отправлять факсимильные сообщения через сети с коммутацией пакетов IP
Унифицированный обмен сообщениями
Как показывает практика (и мы уже отмечали этот факт чуть выше), приходя на свое рабочее место, сотрудник организации или офиса весьма значительную часть времени тратит на обработку поступившей к нему разнородной корреспонденции. Неудивительно, что сегодня, при большом количестве носителей информации, остро встает проблема быстрого и, по возможности, унифицированного доступа ко всем поступающим сообщениям. Так определилась основная тенденция эволюции почтовых систем - создание единых механизмов обработки поступающих сообщений и обеспечение универсального
доступа к ним, т.е. технологии, получившей на Западе название Unified Messaging.
Концепция Unified Messaging (унифицированного обмена сообщениями или единой среды обмена сообщениями), возникшая на стыке двух информационных сред 一 компьютерной и телефонной, в настоящее время является одной из главных движущих сил на рынке приложений компьютерной телефонии.
Предпосылки
Согласно результатам обследования 10ОО крупнейших американских компаний (по рейтингу журнала «Fortune»), проведенного без малого три года назад, рядовой сотрудник этих компаний располагает, в среднем, шестью средствами связи. Традиционный их набор выглядит так: электронная почта, офисный телефон, факс, сотовый телефон, пейджер (которым крупная фирма часто снабжает своих работников на всякий случай) и дополнительное коммуникационное устройство (вроде Nokia Communicator 9000 или Palm). Часто к этому списку добавляется домашний адрес электронной почты и домашний телефон. На первый взгляд, столь высокий уровень коммуникационной оснащенности должен гарантировать, что связь с сотрудником можно установить в любое время дня и ночи. В действительности дело обстоит не совсем так.
Если работники одного отдела, как правило, знают, где находится их коллега и как с ним оперативно связаться, то руководство и сотрудники других подразделений фирмы, особенно крупной, обычно такой информацией не располагают. Нередко секретарь даже небольшой компании не знает, присутствует тот или иной человек в данный момент на работе или нет. В этой ситуации на помощь приходят переадресация вызова, системы речевой почты и некоторые другие функции компьютерной телефонии. Электронная почта отчасти снимает эти проблемы благодаря тому, что имеется принципиальная возможность просматривать входящую корреспонденцию не только со своего рабочего места, но и практически из любой точки сети. Тем не менее, все эти технические достижения решают задачу лишь частично. С ростом арсенала средств связи, оказавшихся в распоряжении одного человека, его коллеги и клиенты получают возможность передавать ему информацию по нескольким разным каналам. Асам обладатель этого арсенала, чтобы оперативно получать нужную ему информацию, вынужден крайне неэффективно расходовать свое время, просматривая электронную почту, факсы, сообщения, пришедшие на пейджер, прослушивая речевую почту и просто отвечая на телефонные звонки.
Нерациональностьтакого способа обработки входящих информационных потоков стала в 90-х годах настолько очевидной, что сразу
несколько фирм вплотную занялись разработкой технологии, призванной значительно упростить общение пользователя с внешним миром. Эта технология и основанные на ней продукты в 1994 г оформились в концепцию унифицированной (или объединенной) обработки сообщений, которая в течение последних двух-трех лет стала пользоваться завидной популярностью (рис.4.5.).
UM серверРис. 4.5 Применение сервера Unified MessagingUM серверРис. 4.5 Применение сервера Unified Messaging□□ФаксФаксПользователиПользователи
UM сервер
Рис. 4.5 Применение сервера Unified Messaging
UM сервер
Рис. 4.5 Применение сервера Unified Messaging
□
□
Факс
Факс
Пользователи
Пользователи
Функциональные возможности
Важнейшим критерием, позволяющим отнести продукт того или иного производителя к категории Unified Messaging, является способ доступа к сообщениям. Унифицированная система обработки сообщений обычно определяется как система, которая дает пользователю возможность выполнять разные операции (извлечение, просмотр, редактирование, сохранение, пересылку) с сообщениями всевозможных типов, прежде всего, с речевыми, факсимильными и электронной почты. При этом обработка сообщений производится с применением разных средств (и, соответственно, разных интерфейсов). Использоваться могут как персональные компьютеры с инсталлированными на них Web-браузерами или специальным клиентским ПО, так и стационарные и мобильные телефоны, факсы. Очевидно, впрочем, что возможности перечисленных вариантов неравнозначны.
Например, прослушивание речевых сообщений с использование ем средств электронной почты выглядит примерно следующим образом. Пользовательустанавливает всвой компьютер соответствующую звуковую карту и обычную почтовую программу типа Microsoft Outlook. В окне программы речевые сообщения будут помечаться специальными символами. Штатными средствами почтового клиента можно открыть соответствующее сообщение и прослушать приложенный к нему речевой файл. Это не означает что прослушать речевые сообщения можно будет только с помощью компьютерных приложений, но, используя эту функцию, пользователю для получения сообщений разных видов не нужно обращаться то к компьютеру, то к телефонному аппарату.
Более строгий подход к оценке систем Unified Messaging предполагает также наличие в них средств управления сообщениями, а также гибкость и расширяемость систем. Так, полнофункциональное решение должно обладать способностью переадресации отдельных сообщений по критериям и на устройства, которые задает пользователь (при необходимости - с преобразованием формата сообщений).
Однако суть не в едином почтовом ящике. По определению, данному Дэвидом Циммером из Unified Messaging Consortium, главный принцип архитектуры любой универсальной системы заключается в единственности не почтового ящика как такового, а его представления для пользователя. Пользователю безразлично, как организованы хранение и обработка сообщений разных типов (на одном или на нескольких серверах); главное, что доступ к ним осуществляется единообразно и возможен с разных устройств. При этом заметно упрощается и задача отправителя сообщений: он не должен заботиться о том, в каком формате и каким путем информация достигнет адресата. Таким образом, как отмечалось выше, важнейшим принципом, который должен лежать в основе действительно универсальной системы обработки сообщений, является не объединение нескольких почтовых систем (как считают многие), а универсальность доступ па, которая распространяется и на просмотр поступившей корреспонденции, и на отправку ответной. Конечно, этот подход несколько идеализирован, тк. возможности просмотра апектронно访 почты, скажем, у мобильного телефона и у персонального компьютера, явно неодинаковы. Тем не менее, возможность, например, получать на мобильный терминал с использованием SMS заголовки приходящих сообщений электронной почты может быть весьма полезна пользователю, часто бывающему в разъездах.
Поскольку в статьях производителей и поставщиков оборудования UM для обозначения одних и тех же понятий подчас используются разные термины и определения, что вводит читателей в заблуждение, приведем несколько определений, введенных консорциумом по разработке и продвижению систем Unified Messaging.
Унм4жш1рованнаа почта (unified mail) - это система, предусматривающая хранение сообщений всех типов (речь, факс, электронная почта, видео, пейджинп и т.д.) в одном почтовом ящике или в нескольких ящиках, но с унифицированным доступом. Доступ к содержимому ящика возможен с компьютера или с телефона. Обеспечиваются определенные возможности преобразования типов (способа представления) сообщений. Такие системы сегодня существуют и довольно широко представлены на рынке.
Система унмсЬмимрованнсто обмена сообшенмамм (unified messaging) -это система, которая обеспечивает возможность создавать (и отвечать на) сообщения различныхтипов с использованием телефона или компьютера (в том числе, через платформы разных производителей) с управляемым преобразованием типа сообщения, причем поддерживаются все варианты преобразования. Обеспечивается и совместимость с почтовыми системами предыдущих поколений. Такие системы, по оценкам экспертов, появятся на рынке в самое ближайшее время.
Система универсальных сообщена访(universal messaging) 一 это система, которая обеспечивает возможность создавать сообщения любого типа и посылать их любому адресату, не предъявляя какие-либо требования к почтовому ящику получателя. Пока подобные системы находятся в стадии разработки.
Могут использоваться и другие термины, например, «интегрированная почта». Это - вариант применения унифицированной почты, обеспечивающий возможность хранения сообщений нескольких разных типов и представления их конечному пользователю в едином виде.
В обеспечении универсального доступа ключевую роль играют преобразования форматов сообщений: текстового - в речевой и факсимильный, факсимильного - в текстовый или речевой, наконец, речевого -в текстовый и факсимильный.
Актуальность подобных преобразований связана не только с необходимостью унифицировать обработку сообщений разных типов, но и с тем, что сами сообщения все чаще оказываются мультимедийными. Если раньше удавалось однозначно определить сообщение как речевое, текстовое или факсимильное, то сегодня к первому может быть присоединен фрагмент факса, а ко второму - звуковой, факсимильный и графический файл.
Технологии преобразования форматов находятся на разных стадиях своего развития, поскольку зависят от достижений в создании новых и совершенствовании имеющихся алгоритмов цифровой обработки сигналов (DSP) 一 синтеза естественной человеческой речи, оптического распознавания символов и графических изображений, распознавания потоковой речи и т.д.
Простейшим, пожалуй, является преобразование факсимильного сообщения в текстовое и обратно, поскольку и компьютер, и факсимильный аппарат воспринимают эти сообщения как сжатые двоичные файлы. Правда, когда факсимильное сообщение отправляют с аппарата группы III, невозможно обойтись без специального факс- сервера, который преобразует такое сообщение в текст, используя технологии оптического распознавания символов (OCR) или меток (OMR). Тот же сервер требуется для пересылки поступившего факсимильного сообщения удаленному адресату.
Но, все же, в современных продуктах Unified Messaging чаще встречаются два других варианта преобразований - перевод текста в факсимильную и в речевую формы. В первом случае открывается возможность отправки сообщения электронной почты непосредственно на факсимильный аппарат, во втором - прослушивания поступившего сообщения по телефону. Интеграция речевой почты в системы Unified Messaging сегодня реализуется в различных формах - от речевых комментариев к электронным сообщениям до так называемой «речевой электронной почты» (когда WAV-файл отравляют в виде приложения к письму по электронному адресу). Очевидно, что универсальная система должна допускать прослушивание подобной корреспонденции через обычный телефон.
При наличии средств автоматического распознавания речи, о которых достаточно подробно было сказано выше, речевые сообщения можно было бы диктовать «своему» серверу UM, не обращаясь к речевому почтовому ящику адресата. Они передавались бы в виде речевой или обычной электронной почты (при условии предварительного перевода речи в текст). Обратное преобразование текста в речь необходимо для прослушивания по телефону (скажем, из дома или из другого города) поступившей корреспонденции (не только речевых, но и факсимильных сообщений и сообщений электронной почты).
Еще одной интересной возможностью, поддерживаемой системами Unified Messaging, является возможность присваивать поступающим сообщениям разные приоритеты. Пользователь, по своему усмотрению, задает алгоритм. Расстановка приоритетности поступающих сообщений осуществляется на основании анализа заголовков сообщений или имен отправителей. Такая функция необходима в случае большого объема входящих сообщений, не все из которых могут быть одинаково важными. Например, наряду с сообщениями, приходящими от потенциальных клиентов или от партнеров по бизнесу, в почтовый ящик приходит определенный объем сообщений рекламного или развлекательного характера. Естественно, что в этой ситуации приоритет будет отдаваться деловым письмам, тогда как сообщения с рекламой могутбыть либо автоматически удалены, либо отправлены в конец очереди с самым низким приоритетом.
Важнейшей функцией систем унифицированного обмена сообщениями является поддержка гибких режимов уведомления о поступлении сообщений в почтовый ящик. Действительно, неудачная схема уведомления способна свести на нет все те преимущества, которые сулит пользователям возможность извлекать из одного почтового ящика сообщения, имеющие разный формат.
В зависимости от используемых средств существующие системы уведомления можно условно разбить на три класса: настольные, мобильные и экранные (с использованием PC).
Типичным примером настольной системы может служить световой индикатор на системном телефонном аппарате УАТС, указывающий на наличие в ящике речевой почты не прослушанного сообщения. Этот простейший метод был изобретен почти 20 лет назад, но с успехом используется и по сей день. Однако от него мало проку, если сотрудник часто отлучается со своего рабочего места или много времени проводит в командировках.
В мобильной системе используется сотовый телефон или пейджер, но ее работоспособность напрямую зависит от того, не покинул ли абонент зону обслуживания, заряжен ли аккумулятор на мобильном устройстве и включено ли оно. Находясь на рабочем месте, сотрудники иногда выключают мобильные терминалы, и тогда передача уведомлений на них теряет смысл.
Уведомления от экранных систем можно видеть на мониторе персонального компьютера, причем в этом случае пользователю предоставляется дополнительная информация, на основании которой он может оценить, какова важность поступившего вызова или сообщения, и выбрать способ реакции на него. Однако, как и в первом случае, предполагается, что сотрудник присутствует на своем рабочем месте.
Ограниченность систем, относящихся к каждому из трех названных классов, позволяет выявить те свойства, которыми должна обладать система уведомления, чтобы ее действительно можно было назвать универсальной. Прежде всего, в идеальном случае пользователь должен быть извещен о поступившем сообщении немедленно, вне зависимости оттого, где он находится, и от типа сообщения.
Система должна уметь адаптировать генерируемые ею уведомления к тем устройствам, к которым эти уведомления должны передаваться в соответствии с расписанием, заранее определенным пользователем.
Немаловажно наличие гибких средств управления. Нужно, чтобы пол ьзовател ь и мел возможность задавать методы и расписания уведомлений, меняя содержимое записей в каталоге почтовой системы или используя специальную Web-страницу сети Интранет.
Наверное, ни один пользователь не отказался бы от системы уведомления, способной анализировать поступающую корреспонденцию по идентификатору отправителя, теме сообщения и другим атрибутам и принимать решение о необходимости передачи уведомления, руководствуясь заранее установленными настройками.
От степени интеллектуальности подсистемы генерации уведомлений зависит и их информационное наполнение. Просто поставить пользователя в известность, что для него получено новое или даже важное сообщение, бывает явно недостаточно. Скорее всего, пользователю захочется узнать, от кого, когда, откуда и по какому каналу поступило это сообщение, какова его основная тема и содержит ли оно присоединенные файлы. Такие сведения представляют ценность и для системы (поскольку они могут использоваться ею, чтобы автоматически принять решение о способе обработки сообщения), и для самого потребителя (ибо позволяютему определить необходимость оперативной реакции).
Должна быть предусмотрена возможность подтверждения принимающим устройством получения уведомления, чтобы система не генерировала его повторно (подобно тому, как в системах электронной почты мы нередко активизируем функцию, подтверждающую доставку отправленного письма).
Архитектура
Пока мы говорили только о функциональных возможностях систем Unified Messaging. Понимание этой стороны вопроса, в целом, одинаково у большинства разработчиков. Что же касается архитектуры программно-аппаратных комплексов и идеологии их построения, то сегодня их нельзя определить однозначно. Дело в том, что при реализации систем разработчики придерживаются двух принципиально разных подходов. Речь идет об интегрированной и об универсальной архитектуре. Рассмотрим эти два варианта архитектуры подробнее.
В системах с интегрированной архитектурой предусматривается несколько самостоятельных хранилищ, в которые помещаются сообщения разныхтипов. Для организации связи между хранилищами и синхронизации их содержимого иногда применяется специальное связующее программное обеспечение (middleware).
Существует несколько разновидностей интегрированной архитектуры.
Частично интегрированная система. Речевые сообщения и сообщения электронной почты помещаются в разные хранилища, более того, доступ к ним не интегрирован даже на уровне клиентского ПО. В то же время, для факсимильных и речевых сообщений обычно используется общее хранилище, и доступ к ним возможен с персонального компьютера.
Интегрированный клиент. В этом случае сообщения разных типов также оказываются в разных хранилищах, непосредственное взаимодействие (а значит, и синхронизация) между которыми отсутствует, однако имеется интеграция хранилищ науровне клиентского ПО. Перед доступом к корреспонденции станция-клиент регистрируется на всех имеющихся почтовых серверах, а содержимое последних предоставляется пользователю через единый интерфейс. В системах такого типа сервер речевой/факсимильной почты обычно подсоединяется клокальной сети и физически отделен от сервера электронной почты. Благодаря клиентскому ПО пользователь работает с почтовыми серверами так, как если бы в его распоряжении имелся единственный почтовый ящик. Очевидно, что для этого клиентское приложение электронной почты обязано поддерживать операции с сообщениями разных типов. В качестве таких приложений чаще других используются программы Microsoft Outlook или Lotus Notes (клиентская часть). •
Интегрированный сервер. Как можно заключить из названия этого варианта архитектуры, хранилища для речевых/факсимильных сообщений и для электронной почты формируются на одном сервере, но логически они остаются независимыми. Интегрирующее программное обеспечение, устанавливаемое на сервере, выполняет маршрутизацию потоков сообщений между хранилищами и управление ими. Для доступа к любым сообщениям можно использовать персональный компьютер или телефон; в последнем случае необходимы средства распознавания символов (обработка факсимильных сообщений) и преобразования текста в речь.
Системы с синхронизацией. Основная особенность данного класса -наличие мощных средств синхронизации хранилищ сообщений разных типов, которые могут располагаться как на одном, так и на разных серверах. Средства управления каждым хранилищем имеют точную информацию о содержимом остальных хранилищ благодаря использованию системы указателей и технологии индексирования. К системам данного типа примыкают решения с тиражированием сообщений. В их клиентском варианте копии речевых и факсимильных сообщений могут передаваться, например, на сервер электронной почты.
В системах с универсальной архитектурой сообщения разныхти- пов, а также их комбинированные варианты (например, текст с присоединенным речевым файлом или речевое сообщение с дополняющим его факсимильным) хранятся в одной базе данных или в одном хранилище. Как правило, такая база данных (или хранилище) располагается на одном физическом сервере, хотя в больших организациях при значительном объеме факсимильной и речевой корреспонденции может возникнуть потребность в применении серверных кластеров. Перед тем как факсимильные и речевые сообщения поме-
щаются в единое хранилище, они подвергаются предварительному преобразованию на специальных почтовых серверах.
Каждый из вариантов архитектуры имеет свои достоинства и недостатки. К сильным сторонам интегрированного подхода можно отнести большую степень отказоустойчивости и избыточности: при сбое одного из серверов в распоряжении пользователей остаются другие почтовые средства. В этом отношении слабость универсальной архитектуры очевидна: отказ почтового сервера, неполадки в сети или какие-либо проблемы с базой данных означают, что доступ к корреспонденции будет полностью закрыт. Однако за повышенную надежность надо платить, и сопровождение интегрированных систем представляет для администратора непростую работу.
Неоднозначность решений в пользу того или иного подхода лучше всего иллюстрируется практикой ведущих производителей такого оборудования: в то время как в системе INTUITYMessage Manager, основанной на продукте Octel Unified Messenger, корпорация AWYA использует универсальную архитектуру, создатели Symposium Messenger из компании Nortel Networks проповедуют распределенный подход. ”
Стандартизация
Предусматриваемая системами Unified Messaging интеграция обработки электронных, речевых и факсимильных сообщений нашла отражение и в области стандартов.
В приложениях речевой почты в течение многих лет использовался стандарт Audio Messaging Interchange Specification (AMIS), призванный гарантировать взаимодействие продуктов разных поставщиков в сетевой среде. Но возможности, которые гарантировал этот стандарт, были ограничены, и часто, чтобы достичь совместимости различных решений, пользователям приходилось отказываться от множества полезных функций. Это привело к тому, что разные производители начали выпускать системы речевой почты, базировавшиеся либо на расширенных вариантах AMIS, либо на закрытых технологиях.
В связи с этим в 1994 г. консорциум Universal Messaging Interoperability Group (UMIG) рассмотрел вопрос о применении в системах речевой почты стандарта MIME. Кроме того, в том же году в составе Ассоциации по электронным сообщениям (Electronic Messaging Association) появилась рабочая группа Voice Profile for Internet Mail (VPIM), перед которой была поставлена задача создать стандарт для универсальных систем обработки сообщений, регламентирующий операции с речевыми и факсимильными сообщениями в IP-сетях. Осенью 1998 г. форумом IETF была принята в качестве рабочей спецификации версия VPIM2, основанная на протоколах SMTP и MIME;
Б.С. Гольдштейн
она получила порядковый номер RFC 2421. Последняя версия этого протокола существует в виде предварительной редакции (draft), выпущенной 15 ноября 2000 года. Названная спецификация описывает процедуры обмена речевыми и факсимильными сообщениями между почтовыми системами разных поставщиков как в корпоративной IP-сети, так и в сети Интернет. По сути, VPIM2 представ- ляетсобой расширение протоколов SMTP и MIME в части передачи речевых сообщений.
В спецификации нормируются правила кодировки адресных полей (вт.ч., для тех отправителей, которым нельзя ответить, используя стандартные почтовые процедуры, предусмотренные SMTP), форматы полей для переноса речевой части сообщений и другие тонкости. Не углубляясь в детали этой спецификации (она доступна в сети Интернет), отметим лишь некоторые интересные моменты, а именно - адресацию и передачу речевого содержимого. Адресация для речевых сообщений используется стандартная, т.е. адрес формируется по принципу user@domain.
Согласно стандарту, поле имени домена, если оно не вводится абонентом (например, при отправке сообщения с телефонного аппарата), должно заполняться системой автоматически на основании введенного пользователем адреса (при необходимости - с обращением к соответствующим каталогам).
Вводится ряд требований и рекомендаций в отношении заполнения поля имени пользователя. В обычных почтовых системах (имеется в виду привычная всем электронная почта) имя пользователя, как правило, является буквенно-цифровым и может состоять из нескольких частей. В то же время, большинство речевых почтовых ящиков «исторически» имеет цифровую нумерацию, что вызвано необходимостью иметь доступ кним с использованием клавиатуры телефонных аппаратов. В принципе, набор буквенно-цифровых имен с клавиатуры телефона, конечно, возможен, но требует весьма неудобных манипуляций (тот, кому приходится регулярно отравлять SMS с сотовых телефонов, поймет, о чем речь). Отсюда - возможные проблемы при обработке серверами речевой почты писем, содержащих вложенные речевые сообщения и имеющих имя пользователя в буквенно-цифровом формате.
Чтобы избежать этой проблемы, стандартом VPIM2 предусматривается несколько основных (рекомендованных) схем нумерации речевых почтовых ящиков:
обычный номер почтового ящика - может употребляться при использовании внутреннего плана нумерации корпоративной сети и иметь произвольную длину. Пример: «2722@loniis.ru»;
групповой номер почтового ящика + индивидуальный номер консоли -может использоваться в корпоративной сети, если для дос-
тупа к нужному абоненту этой сети необходим донабор. Может иметь произвольную длину; в качестве разделителя группового номера и номера консоли используется символ «+». Пример: «2722+111@loniis.ru»;
международный номер - рекомендуется использовать для номеров, входящих в план нумерации сети общего пользования и соответствующих рекомендации ITU-T Е.164. Максимальная длина номера ограничивается 15 цифрами. Идентификация того, что пользовательская часть почтового адреса является номером в сети ТфОП, осуществляется по символу «+», предшествующему собственно номеру. Этот символ не набирается с клавиатуры, а подставляется системой автоматически. Пример: «+16137637582@protei.ru»;
групповой международный номер + индивидуальный номер консоли -используется аналогично п.2, но при доступе из сети общего пользования. Максимальная длина каждой из частей ограничивается 15 цифрами. Символ «+» используется и как указатель того, что номер является номером сети общего пользования, и как разделитель между групповой частью и и нди в иду ал ьн ы м номером консоли. Пример: «+17035245550+230@ета.огд».
В стандарте отмечено, что вся «смысловая» информация в подобном адресе определяется цифрами и единственным символом «+». Наличие в адресе других разделителей (например, символа «-») допускается, однако их толкование не нормируется. Принимающая сторона может либо игнорировать такие разделители, либо использовать их, например, чтобы вычленить осмысленные фрагменты номера для последующего анализа (например, коды страны, города и т.п.).
Кроме того, стандарт определяет два специальных имени пользователя, которые не применяются непосредственно для адресации сообщений, а используются в служебных целях: postmaster и nonmail-user. Назначение первого - прием разного рода служебной и диагностической информации от других систем. Смысл второго служебного имени - идентифицировать отправителя, которому нельзя ответить с помощью стандартного почтового механизма «Reply». Допускается также использование произвольного текстового имени взамен стандартного, однако системы, соответствующие VPIM2, должны уметь определять такие имена в приходящих сообщениях и не допускать попыток ответа.
Оговаривается, что в будущем, когда степень конвергенции телефонных услуг и услуг Интернет возрастет, схемы адресации могут быть расширены и дополнены.
Перейдем теперь к передаче собственно речевого и факсимильного содержимого. Для этого стандарт VPIM2 регламентирует ис-
пользование заложенных в протокол MIME возможностей передачи в электронных письмах вложений произвольного формата.
Прежде всего, необходимо обозначить факт наличия в почтовом сообщении речевого вложения. Для этого все сообщения, соответствующие стандарту VPIM2, содержат в стандартном поле ContentType значение «Multipart/Voice-Message». Вводить в такое сообщение другое сообщение (например, при пересылке) и вообще любое вложение, кроме речи, не допускается. При обнаружении в принимаемых сообщениях недопустимых вложений система должна игнорировать их, обрабатывая только вложения разрешенного типа.
Для описания содержимого каждого вложения служат следующие поля:
Content-Description - необязательное текстовое поле произвольного формата.
Content-Disposition 一 обязательное поле, необходимое для того, чтобы принимающая сторона могла разделять речевые вложения, если их в письме несколько.
Предусматриваются следующие типы речевых вложений:
Voice-Message - основное речевое сообщение;
一 Voice-Message-Notification 一 речевое уведомление (как правило -о доставке);
Originator-Spoken-Name - имя отправителя, представленное в речевой форме;
Recipient-Spoken-Name - имя получателя, представленное в речевой форме (не указывается, если письмо отправляется более чем одному адресату);
Spoken-Subject - тема письма, пред ста в лен на я в речевой форме.
Content-Duration - необязательное поле; указывает длительность речевого вложения.
Content-Language - необязательное поле; указывает язык речевого вложения (для использования в перспективе системами распознавания речи).
Content-Type - обязательное поле, указывающее тип вложения. Как уже отмечалось, в сообщениях, соответствующих VPIM2, число типов вложений ограничено:
- Audio - указывает на передачу речевых сообщений. Для кодировки речевых сообщений стандартом VPIM2 принят способ АДИКМ. (32 Кбит/с). В этом случае поле Content-Type содержит значение Audio/32KADPCM.
-Image - указывает на передачу оцифрованных факсимильных сообщений. В качестве варианта кодирования принята модификация стандарта TIFR адаптированная для факсимильной
связи - TIFF-Е В этом случае поле Content-Type содержит значение Image/TIFE
- Message - указывает на передачу переадресованных писем, полностью соответствует «традиционным» спецификациям MIME и в контексте данной книги интереса не представляет.
Стандарт предполагает, что оборудование, поддерживающее VPIM2, может использовать и нестандартные алгоритмы кодирования. В этом случае производителю не нужно изобретать новые поля, он должен лишь определить дополнительные допустимые значения подполей вышеуказанного поля Content-Type
Что касается самой информации, содержащейся во вложениях, то она должна передаваться в двоичном виде; это отображается в стандартном поле Content-Transfer-Encoding, имеющем в данном случае значение Base64 (как и при передаче практически любых вложений).
Для иллюстрации сказанного приведем пример кодировки речевого сообщения, адресованного двум адресатам и содержащего в виде речевых вложений имя отправителя, тему и собственно тело сообщения.
То: +19725551212@vml.mycompany.com
То: +16135551234@vml.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary=” MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@vm2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/3 2KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: partl@vm2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (отображение закодированного имени отправителя) fgdhgddlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/3 2KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@vm2-4321
glslfdslsertifIkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (отображение закодированной темы сообщения) fgdhgddlkgpokpeowrit09==
--MessageBoundary
Content-type: Audiо/3 2KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msgl.72 6 Content-Duration: 2 5
HiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(отображение закодированного тела речевого сообщения) zb8tFdLTQtlPXj
u7wjOyRhws+krdns7RjuOt4tLF7cEOKOMxOTOnRW/Pn30c8uHi9==
Не углубляясь в подробности, отметим, что некоторые изменения и расширения были внесены и в базовый протокол передачи почтовых сообщений SMTR Они коснулись, главным образом, расширения функций механизмов уведомления о доставке сообщений (генерация разных уведомлений в зависимости от условий, включение в них дополнительной информации и т.д.), механизмов согласования допустимых размеров сообщений, расширения перечня служебных кодов, механизмов передачи не кодированной двоичной информации.
Несомненным шагом вперед, по сравнению со стандартом AMIS, ориентированным на аналоговую передачу, стало включение в регламентируемую областьфаксимильной корреспонденции (в AMIS механизмы маршрутизации факсимильных сообщений отсутствовали).
Важным доводом в пользу применения компаниями-разработчиками почтовых систем этого стандарта является и то, что поддержка VPIM почтовыми системами, используемыми в организациях, позволяет этим компаниям довольно существенно снизить затраты на дальнюю связь: ведь речевые и факсимильные послания можно передавать в виде цифровых сообщений средствами протокола SMTP
Впрочем, разработка стандарта VPIМ решила задачу сокращения расходов на международные соединения л ишь частично. Его применение позволяет изменить способ передачи сообщений с одного почтового сервера на другой, однако никак не затрагивает вещательную передачу (когда один и тот же факс надо разослать множеству получателей). Посколькузначительнаячастьфаксимильныхаппаратов по-прежнему остается включенной в телефонную сеть общего пользования, передача факсимильных сообщений иногородним адресатам без использования услуг дальней связи невозможна.
Один из способов, позволяющих обойти эту трудность, уже реализован в некоторых почтовых системах, поддерживающих операции с факсимильными сообщениями. Каждая такая система формирует отдельный узел в сети POP и перед отправкой факса осуществляет поиск POP-узла, ближайшего (в смысле стоимости соединения) кфакс-машине адресата. К POP-узлу, удовлетворяющему требованию минимизации затрат, факсимильное сообщение транспортируется по IP-сети, а дальше этот узел передает сообщение адресату стантартным способом.
Стандарт VPIM сегодня поддерживает большинство зарубежных разработчиков универсальных почтовых систем. К ним относятся как крупнейшие поставщики телефонных станций (Lucent, Nortel, Siemens и др.), так и фирмы, которые специализируются на коммуникационном программном обеспечении (Active Voice, Applied Voice Technology, Interactive Intelligence, Novavox, Pulse Point Communications).
Если говорить о традиционной электронной корреспонденции, то интерес представляет протокол IMAP4 (Internet Message Access Protocol), пришедший на смену хорошо известному протоколу POR Преимущество IMAP4 перед его п редшестве н н и ко м состоит в том, что он поддерживает папки сообщений, функции поиска и индексирования на почтовом сервере, а также операции извлечения только нужной части хранящегося сообщения. Компании Microsoft, Netscape, Qualcomm, CommTouch и ряд других заявили о поддержке этого стандарта пару лет назад. Для пользователей такая поддержка означает возможность обмена сообщениями между серверами разных производителей.
Еще один круг задач, возникающих при развертывании различных почтовых систем, в том числе универсальных, связан с интеграцией разнородных каталогов. Наиболее распространенный путь интеграции -использование протокола LDAP. Он обеспечивает тиражирование информации каталогов с одного сервера LDAP на остальные. Система Unified Messaging, поддерживающая указанный стандарт, позволяет администратору электронной почты контролировать ее функционирование с одной консоли.
Основной вывод из этого краткого рассмотрения стандартов в области универсальных почтовых систем таков. Работая с продуктом того или иного производителя, сегодня еще можно догадаться, какая технология - речевой почты или электронной почты - лежала в его основе. Однако конвергенция технологий приводит к тому, что различать унаследованные черты становится все труднее. Мы можем наблюдать, как постепенно стираются грани между компьютерными (GUI) и телефонными (TUI) интерфейсами, а также то, как активно проникают в сферу Unified Messaging стандарты из смежных областей.
Тем не менее, пока еще рано говорить о том, что спрос на стандарты в этом сегменте рынка удовлетворен. Перечисленные выше протоколы и спецификации касаются лишь отдельных аспектов задачи обеспечить совместимость решений разныхфирм и задачи интеграции новых продуктов с унаследованными системами. Ккк отмечают эксперты, пока еще не выработаны стандарты, регламентирующие функционирование систем Unified Messaging в целом, а это сильно сдерживает их дальней шее развитие.
4.4.5 Проблемы и перспективы
Концепция Unified Messaging появилась в 1994 匚,и уже через пару лет эксперты стали наперебой давать прогнозы взрывного роста нового рыночного сегмента. Однако ожидания не оправдались: несмотря на очевидные, казалось бы, преимущества нового подхода к «перемалыванию» многоликой корреспонденции, мировая продажа универсальных почтовых систем пока не достигла тех объемов, которые предсказывались.
Причины того, что новой технологии вот уже несколько лет не удается «расправить плечи», можно разделить на четыре группы: технические, психологические, организационные и экономические.
При развертывании универсальных систем обработки сообщений компании, прежде энергично использовавшие речевую почту, могут столкнуться с нехваткой емкости установленных запоминающих устройств. Как известно, несжатое речевое сообщение продолжительностью в 1 мин после преобразования в файл требует для своего хранения примерно 500 Кбайт дискового пространства. Конечно, емкость жестких дисков растет год от года, а их стоимость падает, кроме того, постоянно совершенствуются алгоритмы сжатия речи. Однако если пользователи не утруждают себя «чисткой» почтовыхящи- ков, придется либо постоянно покупать все новые и новыедиски, либо вводить для таких сотрудн и ков специальные ограничения на размер доступного дискового пространства, что потребует от администратора дополнительных усилий.
Для установки систем Unified Messaging необходимы мощные серверы, способные сжимать и хранить огромные массивы информации, а также оперативно передавать ее в локальную сеть по запросам пользователей.
Всегда остается сомнение в надежности приобретаемых решений. Хотя укладка всей корреспонденции в одну «корзину» заметно упрощает администрирование, от работоспособности этой «корзины» начинает, без преувеличения, зависеть жизнь использующей ее компании. В случае сбоя почтового сервера или локальной сети такая компания может остаться без основных коммуникационных средств.
Существует и проблема производительности универсальной почтовой системы. Просматривая корреспонденцию на экране монитора, вы сумеете за несколько секунд выявить сообщен ия, требующие немедленных действий; использование для этой цели телефона способно отнять у вас десятки минут. Решить данную проблему можно, лишь повысив интеллектуальность систем Unified Messaging с тем, чтобы реализовать в нихфункции анализа и сортировки содержимого почтовых ящиков.
К проблемам технического рода примыкают трудности, связанные с уже используемыми системами речевой и электронной почты, а также с УАТС. Их обновление и интеграция в универсальную среду требуют определенных затрат, а их замена эквивалентна потере прежних инвестиций. Дополнительные сложности возникают из-за нехватки стандартов, регламентирующих взаимоде访ствие новых продуктов с существующими системами. Кроме того, обновление почтовой системы вряд ли удастся оправдать, есл и ун иверсальная почтовая среда будет иметь мало общего (в части пол ьзо в ател ьс ко го интерфейса) с продуктами, уже применяемыми в организации. В таком случае значительных средств потребует обучение сотрудников, а внедрение все равно не пройдет гладко. В этой связи поставщики решений класса Unified Messaging стараются предусмотреть возможность выбора интерфейса клиентом по своему усмотрению (включая телефонный интерфейс).
Все сказанное означает, что внедрен ие систем Unified Messaging должно производиться постепенно (при сохранении на какое-то время существующих систем) и на основе индивидуального подхода. Например, доступ к новым функциям можно предоставлять только тем сотрудникам, которые в них остро нуждаются.
Существует также ряд экономических проблем, сдерживающих внедрение подобных систем. Так, проблему их высокой стоимости (системы с приемлемым функциональным наполнением стоят не менее 20 тысяч долларов США) усугубляет отсутствие четких моделей их окупаемости. Однако, как уже отмечалось, одним из важнейших результатов перехода на системы Unified Messaging является оптимизация внутренних коммуникационных процессов в организации и повышение оперативности принятия решений, так что вопрос о целесообразности внедрения таких систем стоит рассматривать с позиций общего улучшения показателей бизнеса компании и ее конкурентоспособности.
4.5 Телеголосование
Говоря о системах IVR, нельзя не упомянуть о несложных с точки зрения алгоритма обслуживания вызовов, но весьма популярных системах телеголосования. Сточки зрения алгоритма 一 это простейшие системы интерактивного ответа, основное назначение которых - фиксировать вызовы абонентами телефонной сети тех номеров, которые выделены для опроса, и обеспечивать заказчикам опросов доступ к накапливаемой информации в реальном времени.
Для проведения голосования (опроса общественного мнения) выделяется группа номеров, каждому из которых ставится в соответствие один из предлагаемых вариантов ответа на вопрос, постав-
ленный через средства массовой информации. Участвующий в голосовании набирает тот номер, который соответствует выбранному им ответу. При необходимости система автоматически определяет номер вызвавшего абонента (для начисления платы и чтобы исключить из результатов голосования многократные звонки с одного и того же телефона), ведет подсчет количества вызовов, сделанных к каждому из заданных номеров. При этом, по желанию заказчика опроса, вызвавшему абоненту может передаваться фраза автоинформатора, соответствующая выбранному им варианту ответа.
Каждому заказчику опроса оператор выделяет требующееся количество номеров. Моменты начала и окончания сбора статистиче- скихданных могут устанавливаться для каждого заказчика в соответствии с заранее заданным графиком либо командами администратора услуги, либо, удаленно, - самим заказчиком опроса. Критерием, определяющим момент окончания опроса, может служить либо время, либо количество полученных ответов.
Доступ заказчика опроса к оперативной информации о ходе голосования, как правило, осуществляется с использованием динамически обновляемых Web-страниц, что обеспечивает произвольную форму отображения информации и гибкие механизмы управления дизайном. Информация о ходе опросов может отображаться в табличном или графическом формате.
Достоинства услуги, при всей ее простоте, очевидны - заказчик опроса получает возможность оперативно узнать мнение аудитории по интересующим его вопросам, будь то формирование хит-парадов на музыкальной радиостанции или выяснение политических пристрастий зрителей телеканала. При этом заказчикопроса имеетвоз- можность оперативно (а в случае телеопросов -ив реальном времени) информировать своих зрителей/слушателей о ходе опроса, представляя на всеобщее обозрение получаемую статистическую информацию. Разного рода телевикторины, хит-парады, выбор фильмов с помощью голосования - все эти «приманки», безусловно, значительно повышают популярность тех средств массовой информации, которые их используют.
Услуга телеголосования внедрена рядом российских операторов связи. Правда, пока она востребована, в основном, центральными телеканалами, а ее поставщиками являются московские операторы, такие как МТУ-информ, Аудиотеле. Отметим, что основной трафик к этой услуге созда ют стол и чные жители. Региональные операторы, за редким исключением, не предоставляютуслуги телеголосования, а только обеспечивают выход на столичных поставщиков этой услуги, получая довольно скромные отчисления за пропускаемый трафик.
В качестве одного из таких исключений можно привести ГП «СА- ХАТЕЛЕКОМ», самостоятельно и успешно п редоста в л яющее услуги
телеголосования на базе платформь( ПРОТЕЙ. Данный опыт и другие предварительные оценки показывают, что потенциал этой услуги может быть значительно выше, если ее внедрять на региональном уровне, например для проведения опросов общественного мнения региональными властями.
Есть, правда, несколько «но», о которых следует упомянуть в контексте систем телегол осован и я. Прежде всего, это проблема перегрузок в телефонныхсетях. Дело в том, что п одоб н ые с и стем ы, в случае их реализации средствами компьютерной телефонии с исключительно централизованной архитектурой, при обработке потока вызовов большой интенсивности, возникающего при проведении некоторых опросов, могут создавать значительные перегрузки в той сети, куда они включены. Отсюда - необходимость очень продуманно подходить к включению в сети подобных систем, и если прогнозируется, что пользование услугами телеголосования породит значительный трафик, заранее предусматривать для этого трафика маршруты с достаточной пропускной способностью, использовать распределенную архитектуру узлов услуг (SN - Service Nodes), соединенных между собой каналами передачи данныхс протоколами INAR или TCP/IF* или любыми другими.
Столь детальные предостережения обусловлены известной ситуацией, когда во время одного из первых телефонных опросов, проводившихся в начале 90-х годов в Москве, шквал вызовов, направленных к одному коммутационному узлу, вызвал серьезные перегрузки пучков межстанционных линий, которые не были рассчитаны на такого рода пиковые нагрузки. Сегодня ситуация проще - совершенствуется оборудование, растут мощности пучков линий (системы SDH уровня STM-16 с пропускной способностью 2 Пбит/с уже являются обычным оборудованием в современных сетях), да и народ, попри- выкнув к новой услуге, уже отнюдь не так массово участвует в голосованиях. Хотя и не настолько, чтобы распространять на процедуру тел егол осован и я полностью выполняющееся у нас правило Чичестера «Если погода плохая, то количество избирателей, пришедших голосовать, уменьшается, а если погода хорошая, то количество избирателей, пришедших голосовать, уменьшается».
Глава 5 Предоплаченные услуги связи
Деньги вперед, 一 заявил монтер, - утром - деньги, вечером - стулья или вечером - деньги, а на другой день утром - стулья.
И.Ильф, Е.Петров. Двенадцать стульев
Принципы начисления платы за услуги связи
Как следует из эпиграфа, рассматриваемый в данной главе метод предварительной оплаты услуг был известен задолго до возникновения компьютерной телефонии. Тем не менее, на протяжении практически всей истории телекоммуникаций преимущественно использовался другой метод - предоставление услуг связи в кредит с последующей оплатой счетов. Рекомендации ITU-T выделяют три операции, связанные с оплатой услуг связи:
измерение количественной характеристики услуги, проще говоря, -длительности пользования услугой (metering),
собственно начисление платы (charging),
выписка и рассылка счетов (billing).
Последний из упомянутых терминов - «биллинг» - используется в последнее время в несколько более широком смысле. Вопрос «русификации» терминов бурно развивающейся информационной индустрии в связи с биллингом рассматривался в [8]. Там было отмечено, что под биллингом подразумевается два в определенном смысле противоположных понятия - собственно биллинг и аудит. Собственно биллингом занимаются телефонные компании, выставляя счета абонентам, а аудитом, наоборот, - абоненты, проверяя правильность счетов (биллинга), выставленных операторами. Вместе с тем, согласно сложившейся сегодня практике, биллингом называется всё, что связано с оплатой телефонных услуг; хотя довольно часто пер-
вые две из трех названных выше операций обозначают другим термином -тарификация. С последним трудно согласиться, поскольку в русском языке слово «тарификация» означает «определение тарифа», то есть цены единицы продукта, отражая, таким образом, лишь часть функций начисления платы. Так или иначе, традиционная схема расчетов за услуги телефонной связи выглядит следующим образом: обслуженные вызовы учитываются соответствующими средствами станции (как правило, АМТС). Далее учетная информация попадает в биллинговую систему и там обрабатывается, в результате чего начисляется плата за предоставленные услуги и производится выписка счета каждому отдельному абоненту.
В этой схеме можно отметить два ключевых момента. Во-первых, услуга предоставляется в кредит. Во-вторых, абонент (потребитель услуги) идентифицируется на основании номера телефонной линии, для которой устанавливалось соединение (как правило, определяемого на основании информации АОН). Этот телефонный номер зафиксирован в договоре, который был заключен между оператором и абонентом. Плата за все вызовы, совершенные с данной абонентской линии, относится на счет абонента, за которым эта линия закреплена.
Современное развитие рынка телекоммуникационных услуг показало ограниченность такого способа расчетов оператора с абонентом. Повышение мобильности людей, постоянная их потребность в услугах связи, независимо от того, где они находятся, поставили вопрос о п редоставлен и и доступа к услугам связи без необходимости вступать в договорные отношения с местным поставщиком услуг В сложных биллинговых системах в ряде случаев отсутствуют достаточные возможности оперативно управлять тарифами. Проблемы неплатежей актуальны не только в России. И, наконец, в странах, ще телекоммуникационный рынок демонополизирован, масла в огонь, безусловно, подливает конкуренция между операторами. Все вышеупомянутые факторы привели к появлению альтернативного способа расчетов за услуги связи - предоплаты.
Сегодня предоплаченные услуги связ弘(PrepaidServices) - всеми признанная, очень удобная и одна из самых популярных форма предоставления платных услуг телекоммуникационными операторами.
Замена кредитной формы оплаты услуг авансовой, которая исключает возможность появления задолженности и позволяет обходиться без выставления счетов абонентам, - основное преимущество предоплаченных услуг
Наиболее удобным механизмом предоставлени я п редоплаченн ых услуг связи является использование систем обработки сервисных телефонных карт. В англоязычных источниках эти карты называют по- разному -calling cards, prepaid calling cards (PCC), account calling cards (ACC). Что касается русскоязычных источников, то (не без участия
первых российских разработчиков таких систем, отдадим им должное) для этой формы оплаты услуг связи в качестве стандартного де- факто утвердилось название «Сервисные телефонные карты» (сокращенно -СТК).
В системах обработки СТК ключевым является принцип предоставления услуги по коду, обозначенному на телефонной карте. Допуск абонента к пользованию услугой и управление ее предоставлением производятся централизованно, а общение абонента с системой происходит с использованием речевых подсказок, передаваемых абоненту, и цифр, вводимых абонентом (владельцем карты) с телефонного аппарата в режиме многочастотного донабора. По сути, PIN-код^ это просто очень удобный способ идентификации абонента, позволяющий убедится в том, что абонент уже заплатил определенную сумму за те услуги связи, которые ему требуются.
Порядок действий абонента, использующего сервисную телефонную карту (СТК), несложен. Чтобы воспользоваться услугой, в общем случае, необходимо:
набрать номер доступа к услуге определенного оператора;
при необходимости перейти в режим многочастотного набора (если обычно номер набирается импульсным способом);
набрать свой PIN-код;
набрать номер телефона вызываемого абонента или код дополнительной услуги (запрос информации о балансе карты, справочной информации и т.п.).
После этого системой будет установлено исходящее соединение (или, в более общем случае, - обеспечен доступ к запрашиваемой услуге), и включатся механизмы учета стоимости. При окончании средств на карте доступ к услуге будет прекращен системой автоматически.
Предоплаченные услуги связи
Первые предоплаченные услуги связи появились в США довольно давно и быстро завоевали популярность. Десятки операторов и их дилеров предлагают на рынке множество телефонных карт с самыми разнообразными тарифными планами и условиями обслуживания.
Предоплаченные телефонные карты на рынке США занимают две основные ниши. Первая - обеспечение доступа абонентов местных сетей к услугам дальней связи по выгодным тарифам. Возможность снижения тарифов обеспечивают несколько факторов. Прежде всего, оно достигается благодаря предоплате, т.к. оператор получает деньги заранее, по сути, беря кредит у владельца карты. Немалый доход дает и размещение на картах рекламы (впрочем, об этом чуть
позже). И, наконец, операторы, предоставляющие услуги связи по СТК, во многих случаях бывают избавлены от необходимости содержать весьма дорогую и трудоемкую в обслуживании сеть абонентского доступа. Их расходы ограничиваются арендой междугородних каналов у магистральных операторов и эксплуатацией собственной коммутационной платформы (узла услуг).
Вторая ниша - обеспечение интересов людей путешествующих. Служба «Call Direct» крупнейшего оператора США AT&T действует во многих странах мира и пользуется довольно большой популярностью среди туристов и бизнесменов, т.к. телефонная карта с предоплатой, приобретенная в своей стране, позволяет пользоваться международной связью по существенно более выгодным тарифам.
В Европейских странах всплеск популярности предоплаченных услуг произошел позже и совпал по времени с начавшимся там в 1998 году процессом демонополизации рынка связи. Коммерческим операторам, построившим свои магистральные трансевро- пейские и трансатлантические сети, было необходимо быстро привлечь клиентов. В то же время, создавать постоянную клиентскую базу по принципу «традиционных» операторов было экономически нецелесообразно и технически сложно (это потребовало бы построения альтернативной сети доступа, а окупаемость такого шага при высокой плотности телефонизации в Европе абсолютно нереальна). Единственным способом предоставления своих услуг максимальному количеству клиентов в такой ситуации оказался вариант предоплаченных услуг.
Демонополизация рынка в совокупности с возможностями, открывающимися при предоставлении предоплаченных услуг; привели к тому, что появились телекоммуникационные операторы определенной категории, для которых даже был придуман специальный термин «Long Distance Resellers» (перепродавцы услуг дальней связи). Основной их бизнес состоит в том, что они, подключаясь своим коммутатором к нескольким крупным операторам, используют выбор оптимального маршрута (Least Cost Routing), т. е. предоставляют свои услуги через того оператора, у которого связь в данном направлении и в данное время стоит наиболее дешево. Сейчас такие операторские компании появились и в России.
Внедрение предоплаченных услуг связи на базе систем обработки сервисных телефонных карт в России началось с крупных городов. Первоначально услуги по своему содержанию были полностью аналогичны западным. Они заключались в п редоста влен и и междугородней и международной связи приезжим, или тем, кто по каким- либо причинам не хотел или не имел возможности пользоваться связью со своих стационарных или мобильных телефонов.
Специфическая структура тарифов на пользование дальней связью в России (когуда стоимость услуг для коммерческих организаций и частных лиц может различаться в несколько раз) привела к тому, что появилась новая (и довольно значительная) прослойка пользователей СТК.
Весьма интересным вариантом применения СТК, во многом специфическим для России, оказалась модернизация таксофонной сети телефонного оператора с помощью систем обработки СТК. О ней хотелось бы сказать несколько слов.
Итак, есть цель 一 превратить все таксофоны в универсальные, предоставляющие услуги местной и междугородней/международной телефонной связи. Существуют два основных пути ее достижения.
Первый путь традиционен и предполагает использование магнитных (чиповых) карт и специализированных таксофонов. Преимущества применения подобных систем заключаются в возможности подключения к АТС любого типа, в наличии средств защиты карт от подделки и «взлома» и в возможности автоматического контроля работоспособности таксофонов.
Однако российский опыт показывает, что магнитные (да и некоторые чиповые) карты полностью от «взлома» не защищены, а стоимость таксофонов для карт таких типов, да и самих карт, слишком высока. Чтобы переоснастить, например, весь таксофонный парк среднего областного центра, в соответствии с существующими нормативами емкость парка должна составлять 1 - 1.5% общей абонентской емкости. Таким образом, при 20%-й телефонизации полумиллионного областного центра суммарные затраты на установку специализированных таксофонов могут составлять величину порядка 1 млн. долларов США. Очевидно, что такие объемы инвестиций в сегодняшних российских условиях - чрезмерная ноша для оператора. Нельзя также не учитывать возможность актов вандализма в отношении специализированных таксофонов, что приведет к дополнительным денежным расходам при эксплуатации таксофонной сети.
Второй путь модернизации предполагает использование систем, где ключевым является принцип предоставлен и я услуги по коду (PIN- коду), обозначенному на телефонной карте, с использованием оборудования интеллектуальной платформы.
Такое решение, во-первых, обеспечивает широкие возможности, связанные с централизованным управлением как начислением платы, так и маршрутизацией для всей обслуживаемой таксофонной сети, а во-вторых, стоимость уже переоборудованных таким образом таксофонов относительно низка, что существенно снижает потери из-за вандализма.
Стоит также отметить, что изготовление карт с PIN-кодом обходится намного (примерно в 3 - 4 раза) дешевле, чем изготовление чиповых карт, так что при тиражах, необходимых региональным операторам (сотни тысяч карт), экономия только на самом процессе изготовления карт составляет весьма внушительные суммы. Кроме того, в продажной цене СТК существенно снижается доля «пустой» карты, что, приводя к общему снижению стоимости карты, повышает привлекательность услуги СТК.
Один из первых опытов модернизации таксофонной сети с помощью систем обработки СТК интеллектуальной платформы Про- тей-ТК (в 匚 Пенза) показал, что при выборе такого пути модернизации таксофонной сети требуется учитывать ряд специфических моментов.
Это, прежде всего, необходимость иметь возможность блокировать доступ к услуге при попытках подбора PIN-кода, передавать инфо рмациюАОН к спецслужбам, обеспечивать доступ к самим спецслужбам без набора PIN-кода. Кроме того, когда через систему работает большая часть таксофонов города, существенно возрастают требования к ее надежности и производител ьности.
При модернизации сети таксофонов с использованием таких систем для доступа к ним обычно используется сокращенный номер. Во многих случаях для таксофонов, включенных в электронные АТС, может оказаться удобной активизация услуги «горячей линии», чтобы абонент, сняв трубку таксофона, сразу услышал приглашение системы к вводу PIN-кода.
Популярность СТК оказалась настолько высока, что системы обработки СТК в ряде городов России успешно сосуществуют с модернизированной таксофонной сетью того же Оператора (Москва, Санкт- Петербург Тула, Нижний Новгород и ряд других).
Говоря о вариантах применения СТК, нельзя не сказать и о перспективнейшем направлении 一 п редоста влени и предоплаченных услуг операторами мобильной связи.
Предоплаченные услуги на рынке мобильной связи
Европейские операторы мобильной связи переживают в настоящее время период феноменального роста доли услуг Prepaid. Рост числа абонентов Prepaid начался в 1997 году и составил тогда 40%. В течение 1998 года этот показатель превысил 55%, практически теми же темпами рост продолжился и в следующие годы. Сегодня больше всего абонентов Prepaid насчитывается в Италии - 7 ми/!лио- нов. Рекорд численности абонентов Prepaid по отношению к общему числу абонентов принадлежит Португалии: здесь этой услугой пользуется около 65-70% общего числа пользователей мобильной свя-
зью. Не менее распространена эта форма оплаты услуг связи ив Восточной Европе (таблица 5.1). Со второй половины 1997 года практически все операторы сетей GSM в Чехии, Польше, Словакии, Румынии и Венгрии ввели Prepaid.
Таблица 5.1 Рост количества абонентов Prepaid в разных регионах
Регион
12/97
12/98
12/99
12/00
Прогноз 12/01
Прогноз 12/02
Азия
193,900
1,431,230
7,200,000
38,600,000
98,000,000
178,100,000
Восточная
Европа
29,400
725,147
2,200,000
6,300,000
12,400,000
22,300,000
Западная Европа
8,421,134
29,612,335
53,700,000
77,900,000
106,000,000
136,300,000
США/ Канада
17,540
1,504,940
8,900,000
16,100,000
25,500,000
37,300,000
Операторы сотовой связи США также проявляют интерес к внедрению этой новой формы. Например, компания Omnipoint (оператор сети GSM-1900) начала в конце 1998 года с обслуживания по схеме Prepaid примерно 165 тыс. абонентов, что составляло около половины общего числа ее пользователей, а к концу 2000 года число абонентов, обслуживаемых ею по этой схеме, достигло 1 млн. человек.
Внедрение предоплаченных услуг российскими операторами мобильной связи началось сравнительно недавно. Самым крупным из российских операторов, предоставляющих услуги с использованием предоплаченных карт, является «ВымпелКом». Внешне весьма похожая на обычную услугу связи по сервисным телефонным картам, услуга Prepaid в ее «мобильном варианте» имеет ряд существенных особенностей.
Прежде всего, если в «обычной» услуге номер вызывающего абонента передается в систему средствами межстанциоиной сигнализации, а дальнейшее общение абонента с системой происходит с использованием прямого DTMF-донабора, то в мобильном варианте услуги Prepaid средствами межстанционной сигнализации к платформе передается вся адресная информация.
В «обычной» услуге идентификация абонента производится на основании PIN-кода, вводимого, как правило, в режиме DTMF-донабо- ра, тогда как в «мобильном» варианте Prepaid используется вариант услуги с привязкой оплаченной карты к номеру вызывающего абонента. Эта операция производится обычно при активизации карты.
Еще одной особенностью, характерной, главным образом, для «мобильного» варианта Prepaid, является возможность начисления платы за вызовы, входящие к владельцу карты (счета), в зависимости оттого, откуда был сделан вызов. Кроме того, добавляются обязательные подфункции активизации своей карты (своего счета) по телефону и ее пополнения.
Привлекательность предоплаченных услуг связи
Причины столь значительного успеха предоплаченных услуг связи на мировом телекоммуникационном рынке объясняются, на взгляд авторов, несколькими основными факторами.
Для абонентов привлекательна, в первую очередь, очевидная простота услуг. Владельцу карточки не важно, откуда он звонит (из дома, от знакомых, с работы и др) - вызов всегда будет оплачен за его счет. Предоплаченные услуги предусматривают возможность использовать для междугородных и международных переговоров любые телефоны, включая уличные таксофоны, телефоны в гостиницах и т.п.
Тарифы, по которым предоставляются предоплаченные услуги связи, как правило, более привлекательны для пользователей, т.к. последние в этом случае обычно не платят ни абонентской платы, ни страховых взносов, а рассчитываются только за продолжительность пользования услугой. Все расчеты стоимости разговоров довольно прозрачны, процесс их оплаты упрощен до предела. Важно и то, что абонент может постоянно контролировать продолжительность пользования телефоном, следя за тем, сколько оплаченного времени осталось в его распоряжении.
Тем пользователям, деятельность которых связана с частыми разъездами и проживанием в гостиницах, не приходится платить администрации этих гостиниц за телефонные переговоры существеннодороже, чем это предусмотрено тарифами операторов. Именно использование СТК при вызовах из гостиниц породило непонятную зарубежному специалисту проблему: адм и нистраторы гостиниц своей властью закрывают выход к поставщикам услуг СТК с гостиничных АТС, лишая клиентов возможности выбора и навязывая им услуги связи по тем тарифам, которые устраивают гостиницу.
Услугами СТК часто пользуются абоненты, которые оплачивают телефонную связь, например, своих детей, обучающихся в университетах далеко от дома. По схожей причине услуга привлекает деловых абонентов: руководители компаний могут таким образом контролировать, сколько тратят на услуги связи их подчиненные.
Ряд преимуществ обнаруживается и для операторов, предоставляющих предоплаченные услуги. Прежде всего, невозможна задолженность за услуги связи. Предоставление предоплаченных услуг не требует организации собственной сети доступа. С помощью предоплаченных услуг значительно проще привлекать новых клиентов, не прибегая к сложным механизмам договоров и контрактов. Высокая гибкость управления тарифами на услуги позволяет операторам постоянно изобретать разного рода «приманки» для пользователей и проводить сколь угодно гибкую тарифную политику. Разные тариф-
ные планы могут быть ориентированы на разные категории пользователей услугами: часто или редко звонящих, делающих звонки по всему миру или в какие-то определенные страны, ведущих много коротких разговоров или мало, но продолжительных, и т.п.
Иногда операторы идут на различные уловки, чтобы завлечь потенциальных потребителей и при этом не остаться в накладе. Например, объявляются сверхнизкие тарифы для вызовов по картам, но при этом добавляется, что для обеспечения возможности разговора по этим тарифам вводится незначительная абонентская плата, т.е. с каждой карточки, независимо от количества вызовов, ежемесячно будетсниматься определенная сумма. Или, скажем, вводится плата за активизацию карты в системе. Карты могут иметь или не иметь ограничение по сроку действия. Наличие такого ограничения, по наблюдению маркетологов, стимулирует клиентов говорить больше, чтобы остаток на карте не пропал, но при этом отпугивает тех пользователей, которым услуга нужна нерегулярно.
Желание операторов максимально удовлетворить возможные потребности клиента привело к тому, что за время существования этой услуги СТК разделились на несколько разных типов: дебетные не возобновляемые, пополняемые, кредитные и корпоративные.
Дебетные не возобновляемые карты можно использовать, пока они имеют ненулевой остаток.
Баланс пополняемых карт можно модифицировать средствами администратора систем ы. Уцобство пополняемых карт состоит в том, что оператор уменьшает таким способом расходы на изготовление новых карт, а абонент может «раз и навсегуда» запомнить свой PIN- код, что повысит для него удобство пользования картой. Кроме того, можно, например, вводить различные бонусы за единовременное пополнение карты на сумму, превышающую определенный порог
Кредитные счета предназначаются, главным образом, для корпоративных клиентов. Основная их особенность - для запрета предоставления услуг владельцу счета устанавливается не нулевой порог, а максимально допустимый размер кредита. Расчет же клиента с оператором, как правило, происходит ежемесячно по счетам, выставляемым на фактически истраченную сумму.
Желание компаний лучше контролировать свои расходы на телефонную связь породило еще один вид карт - с автоматически восстанавливаемым балансом. Они могут применяться тогда, когда сотруднику выделяется на определенный период времени лимит средств, которые он может потратить на телефонные переговоры. По окончании средств на карте она блокируется, а по истечении установленного периода времени восстанавливается первоначальный баланс. За счет предоплаты появляется возможность несколько сни-
зить тарифы на услуги связи, повысив тем самым их привлекательность для потребителя.
Поскольку СТК дают пользователям возможность контролировать время, потраченное на переговоры, и, оплачивая его небольшими долями (покупая карточки небольшого номинала), ощутимо уменьшить расходы на услуги связи, предоставление предоплаченных услуг позволяет операторам существенно расширить круг своих пользователей за счет небогатых слоев населения.
Существенную экономию приносит оператору и то, что он избавляется от сложного механизма выписки и доставки счетов. И, наконец, дополнительные (и немалые) доходы приносит реклама, размещаемая на телефонных карточках. По информации крупнейшего американского оператора АТ&[ около 60% опрошенных респондентов признались, что реклама на телефонных картах в большей или меньшей степени повлияла на выбор ими тех или иных товаров. Некоторые Российские операторы, активно размещая рекламу на своих телефонных картах, добились полной компенсации стоимости изготовления карт доходами, получаемыми от рекламодателей.
Необходимо упомянуть о том, что СТК, помимо поддержки доступа к основным услугам телефонной связи, могут использоваться и при предоставлении оператором широкого спектра дополнительных платных услуг как универсальное средство для разрешения доступа к ним. Впрочем, подробнее об этом 一 в конце данной главы.
Резюмируя материалы, приведенные в этом параграфе, можно сказать, что СТК предоставляют их владельцам массу возможностей простого доступа к услугам связи, а операторам дают эффективный и хорошо управляемый источник дохода.
Функциональные возможности системы обработки СТК
Обслуживание вызова
Базовый алгоритм обслуживания вызова, связанного с использованием СТК, включает в себя следующие основные этапы:
установление соединения вызывающего абонента с системой,
диалог между абонентом и системой (аутентификация абонента, прием номера внзь旧аемопэ абонента или кода заказа услуги),
установление (при необходимости) исходящего соединения с последующим начислением платы за связь в режиме on-line.
Рассмотрим более подробно основные фазы базового алгоритма, SDL-диаграмма которого представлена на рис.5.1.
Рис. 5.1 SDL-диаграмма базового алгоритма обслуживания вызова по СТК
После обнаружения входящего вызова вызывающему абоненту передается речевое приглашение к набору PIN-кода, а в некоторых случаях - к набору номера карты и PIN-кода. При отсутствии набора в течение контрольного периода времени, например, из-за отсутствия в телефонном аппарате вызывающего абонента средств многочастотного набора, может предусматриваться возможность автоматической маршрутизации вызова к оператору системы, или к заранее заданному внешнему телефонному номеру.
Далее верифицируется PIN-код. Если код верен, вызывающему абоненту передается приглашение к набору номера вызываемого абонента или кода услуги. Перед этим может предусматриваться передача абоненту данных о состоянии его счета, т.е. об остатке оплаченных единиц на его карте. Кроме того, система должна проверить, не использует ли в настоящий момент введенный PIN-код кто- то еще. Как правило, системы СТК не допускают (по очевидным причинам, связанным с необходимостью начисления платы в реальном времени) возможности одновременного использования карты несколькими абонентами. Исключение составляют корпоративные кредитные карты. В последнем случае сумма, затраченная на каждый сеанс связи, записывается на карточный корпоративный счет по завершении этого сеанса, а пользователю карты ежемесячно выставляется счет на оплату всех предоставленных за месяц услуг.
После набора PIN-кода производится набор кода и/или номера вызываемого абонента. В связи с тем, что как междугородные, так и международные номера могут иметь разную длину, для них обычно предусматривается возможность анализа полноты номера либо по таймеру, ограничивающему время ожидания очередной цифры, либо по символу окончания набора номера «#». После приема всего номера анализируются полномочия набранного PIN-кода (и, возможно, 一 категории карты): разрешен ли данному абоненту вызов в данном направлении и сколько времени может продолжаться разговор. Если запрошенная услуга абоненту доступна, то перед установлением соединения, в качестве опции, может предусматриваться передача ему информации о предельно допустимой длительности разговора (либо во всех случаях, либо если продолжительность разговора при связи в данном направлении не должна превышать заданное пороговое значение). После этого устанавливается исходящее соединение. Если продолжительность разговора превысила допустимую, соединение разрушается, а в базу данных записывается предельная величина, соответствующая аннулированию предоплаченной карты. Как правило, за несколько секунд до окончания оплаченного или разрешенного времени абоненту передается предупреждение о предстоящем разъединении. При разъединении по инициативе одного из абонентов выполняется та же операция, но в базу данных в этом случае записывается фактическая длительность состоявшегося разговора.
Рассмотрим основные функциональные возможности, которыми должна обладать система, реализующая услугу обработки СТК.
Эти возможности можно разделить на следующие основные группы:
подготовка карт (счетов);
управление маршрутизацией и начислением платы;
назначение прав доступа к услугам (категории карт);
настройка параметров обслуживания вызова;
управление доступом к системе и поддержка безопасности;
обеспечение доступа к статистическим данным об обслуживании вызовов и к информации о функционировании системы.
5.5.2 Функциональный блок подготовки счетов
Этот блок включает в себя функции создания, удаления и модификации счетов, подготовки данных для изготовления серий карт.
Практика операторов СТК по понятным причинам предполагает не создание новых карт (счетов) индивидуально, а выпуск серий карт с одинаковыми категориями и начальными емкостями. Для каждой такой серии, как правило, задаются два основных параметра: емкость карты (в тарифных единицах) и категория карты (определяющая права доступа и тарифный план, который будет связан с картами данной серии). Может также задаваться контрольная дата, после которой карта будет аннулирована. Генерация PIN-кодов при создании серии карт обычно осуществляется автоматически, с использованием встроенного генератора случайных чисел, однако в качестве альтернативного источника PIN-кодов может быть предусмотрено и использование внешнего файла.
Как уже упоминалось выше, различают несколько основных типов карт (счетов): дебетные не возобновляемые, пополняемые, кредитные и корпоративные. Для каждого из этих типов существуют свои правила пользования и алгоритмы обработки системой вызовов по этим картам.
Блок маршрутизации и начисления платы
Это, пожалуй, один из самых важных блоков системы обработки СТК, реализующий ее основные функции - взимание платы за предоставляемые услуги связи. Он должен обладать достаточной гибкостью, чтобы предоставить оператору максимальные возможности формирования тарифных планов и ограничения прав доступа.
Все логические направления, к которым может иметь доступ владелец карты некоторой категории, разделяются на тарифные зоны. Каждая из зон характеризуется определенным набором зонных па-
раметров. Административное управление логическими направлениями сводится к определению префикса, по которому выбирается то или иное направление, и (как опция) длины номера, а также к управлению административным состоянием направления (заблокировано или разблокировано).
Полезной возможностью во многих случаях является поддержка «вложенных» логических направлений, обеспечивающая возможность назначения зонных параметров даже для индивидуального телефонного номера, что оказывается весьма эффективным при организации доступа с использованием СТК к платным службам сети, для каждой из которых может оказаться необходимым определить свой набор параметров.
Анализ существующих разработок показал, что в общем случае формулы определения предельной длительности разговора (а) и его стоимости (б) можно представить следующим образом:
Т max=mod[(x-ka)/(k * b * р/60)] * р+n,(а)
cJO,ecnnt<m,⑹,
[integer[(t-n)/p] * (р * k * b/60)+ka, если t>m,
где Tmax - максимально допустимая продолжительность разговора;
С - стоимость завершившегося разговора в тарифных единицах;
t - продолжительность разговора в секундах;
р - тарифный интервал, т.е. неделимый промежуток времени, заданный в секундах и являющийся минимальной величиной, с точностью до которой определяется оплачиваемое время;
а - стоимость установления соединения (стоимость в тарифных единицах, которая списывается с карты с поправкой на корректирующий коэффициент в случае установления соединения);
b - стоимость (в тарифных единицах) одной минуты разговора с поправкой на корректирующий коэффициент;
к - набор корректирующих коэффициентов для модификации действующего тарифа и стоимости установления соединения в зависимости от даты и времени. Каждому заданному коэффициенту должны быть поставлены в соответствие период его действия и тип дня (рабочий/выходной);
т-длина интервала времени (в секундах), до истечения которого соединение считается несостоявшимся;
п 一 количество секунд до начала начисления платы.
Присвоение прав доступа и назначение категорий карт
Как правило, тарифные планы и права доступа определяются категориями карт.
Права доступа задают перечень логических направлений, к которым имеют доступ владельцы карт данной категории, а тарифный план - совокупность параметров, используемых при начислении платы. Помимо этого, имеются дополнительные параметры, которые могут использоваться при выборе тарифной зоны для данной карты. Основным параметром, очевидно, является введенный владельцем карты PIN-код. Однако в ряде случаев появляется необходимость учитывать при начислении платы дополнительные параметры. Такие ситуации возможны при создании распределенных систем с централизованной базой данных, или при необходимости использовать особые зонные параметры для вызовов от определенных абонентских линий (например, из гостиниц). В этом случае при выборе тарифной зоны, помимо PIN-кода, должен анализироваться номер доступа к системе или номер вызывающего абонента.
Кроме того, могут изменяться условия применения некоторых из вышеупомянутых параметров. Так, стоимость установления соединения в ряде случаев может списываться с карты независимо от результата установления соединения (такая практика существует у некоторых операторов в США).
Настройка параметров обслуживания вызовов
В эту группу входят функции, обеспечивающие возможность корректировки и подстройки алгоритма обслуживания вызова с учетом требований конкретного оператора. В общем случае, к настраиваемым параметрам относятся контрольные интервалы, используемые при обработке вызовов (ожидание первой или очередной цифры номера, порог для уведомления абонента о предельной длительности разговора и т.п.), а также условия, формирующие алгоритм обслуживания вызова (выбирающие одну из возможных веток алгоритма).
Таким образом, в частности, можно настраивать режим обслуживания входящих вызовов.
Настраивается и диалог абонента с системой, который может происходить в разговорном или в предответном состоянии. В первом случае ответ на входящий вызов передается сразу после обнаружения этого вызова, тогда как во втором - только после получения линейного сигнала «ответ вызываемого абонента».
Настраиваться может также содержание информации о номере вызывающего абонента: к опорной АТС может передаваться либо номер самого абонента, либо групповой номер системы.
Кроме того, возможны модификации сценария (логики) обслуживания вызова. В самом простом случае при неуспешном исходящем вызове или при разъединении со стороны вызываемого абонента можно сразу же отключать вызывающего абонента от системы. Однако это приведет к тому, что при следующем вызове абоненту по-
требуется заново вводить PIN-код, а системе придется снова определять его права связи. Более приемлемым представляется вариант, предусматривающий возврат в меню набора номера по окончании обслуживания вызова. Еще одной модификацией алгоритма является возможность запроса вызывающим абонентом разъединения путем набора специального DTMF-кода. Наличие такой возможности повышает удобство пользования услугой, но при этом возрастают и требования к аппаратным ресурсам комплекса оборудования, поскольку DTMF-приемники должны быть подключены к разговорному тракту в течение всего времени разговора, а не только на этапе установления соединения, как это обычно делается.
Еще одна возможность скорректировать алгоритм обслуживания вызова для некоторых абонентов - «привязка» карты к определенному абонентскому номеру. Операция выполняется администратором системы по заявке владельца карты. Эта дополнительная услуга может оказаться полезной тому, чья работа постоянно сопровождается исходящими от него вызовами, а единственным механизмом их создания является применение СТК. Для такого человека будет весьма удобно, если, набрав номер доступа к услуге, он сразу услышит приглашение к набору номера.
Во многих системах предусматривается поддержка многоязычной системы подсказок. Выбор языка может определяться либо номером доступа к системе, либо через меню после первого универсального двуязычного приглашения.
Доступ к статистической информации
Для эффективной эксплуатации новых телекоммуникационных услуг оператор должен располагать достаточной статистической и оперативной информацией о работе каждой услуги и системы в целом. Кроме того, оператору необходима подробная информация о предоставленных услугах для обработки возможных претензий клиентов, а также некая обобщенная статистическая информация, характеризующая эффективность использования системы. В общем случае, фиксируемая в таких системах информация образует следующие группы:
- журнал аварий (разного рода информация о перезагрузках модулей системы, пропаданиях связи и т.п.);
一 журнал событий (операции, связанные с изменениями параметров конфигурации и т.п.);
журнал учета вызовов;
статистическая информация;
текущая информация о загрузке системы.
Как правило, на основе информации, представленной в журнале учета вызовов, предусматривается возможность генерировать отче-
ты об использовании определенных карт, а также отчеты об исходящей связи (сколько, когда и в каких направлениях делается вызовов) и о доступе к услуге со стороны тех или иных абонентских линий.
800
Исходящая нагрузка "Протей-ТК" за 31.01.2000Исходящая нагрузка "Протей-ТК" за 31.01.2000700700600600500500400400300 ■300 ■200200100100■□OutAII, ед. [ЭОиЮК, ед. [■Raz, ед.■□OutAII, ед. [ЭОиЮК, ед. [■Raz, ед.OutAII - всего исходящих вызовов, OutOK - исходящих успешных вызовов, Raz - разъединение из-за исчерпания емкости карт.OutAII - всего исходящих вызовов, OutOK - исходящих успешных вызовов, Raz - разъединение из-за исчерпания емкости карт.Рис. 5.2 Графики статистических отчетов (на примере Протей-ТК)Рис. 5.2 Графики статистических отчетов (на примере Протей-ТК)10 ! 119 I 20 : 21 ! 22
Исходящая нагрузка "Протей-ТК" за 31.01.2000
Исходящая нагрузка "Протей-ТК" за 31.01.2000
700
700
600
600
500
500
400
400
300 ■
300 ■
200
200
100
100
■□OutAII, ед. [ЭОиЮК, ед. [■Raz, ед.
■□OutAII, ед. [ЭОиЮК, ед. [■Raz, ед.
OutAII - всего исходящих вызовов, OutOK - исходящих успешных вызовов, Raz - разъединение из-за исчерпания емкости карт.
OutAII - всего исходящих вызовов, OutOK - исходящих успешных вызовов, Raz - разъединение из-за исчерпания емкости карт.
Рис. 5.2 Графики статистических отчетов (на примере Протей-ТК)
Рис. 5.2 Графики статистических отчетов (на примере Протей-ТК)
423 54 и bJMDj I,4yti j э( 1 I 30門 оу I [ ы^[ 650 66^ 732 j 687 I 452 1173) 198 期| 362'2931 25o| 335〕而13381 347 丨 3451 422.354 ^ 3772341 而'j
Примеры статистических отчетов представлены на рис.5.2. К статистической информации для определенной услуги, в общем случае, относится набор следующих величин:
число входящих занятий;
число успешных вводов PIN-кода;
число неправильных вводов PIN-кода;
число исходящих занятий;
число исходящих успешных занятий;
число случаев разъединения из-за истечения емкости карт.
5.6 Применение СТК в ТфОП. Процессинговые центры
Рост популярности предоплаченных услуг связи на базе СТК в России и большое количество систем СТК, установленных в сетях крупных операторов ТфОП, сделали актуальными аспекты функционирования таких систем именно в больших сетях. Хотелось бы остановиться на двух из них:
надежность и производительность;
взаимодействие между системами и роуминг карт.
Аспект надежности систем уже упоминался выше при обсуждении варианта применения СТК для модернизации таксофонной сети. Напомним, что если речь идет об эксплуатации системы крупным телекоммуникационным оператором, существенно повышаются требования к надежности и производительности системы. Так, в полумиллионном областном центре России система, предоставляющая услуги связи по СТК, в сутки обрабатывает около 30 тыс. успешно обслуженных вызовов. Очевидно, что при такой нагрузке и таком объеме обрабатываемой информации системы компьютерной телефонии должны обладать функциональными возможностями, которые ранее были присущи лишь специализированному телекоммуникационному оборудованию. Они должны предусматривать резервирование отдельных модулей, возможность работы модулей в режиме разделения нагрузки, высокую надежность аппаратного обеспечения, операционной системы и прикладного ПО. Именно такими свойствами обладают комплексы СТК ведущих российских и зарубежных разработчиков, имея необходимую архитектуру аппаратно-программных средств. Непростые вопросы реализации систем компьютерной телефонии будут более подробно рассмотрены в заключительных главах книги.
Еще одним интересным моментом является возможность организации взаимодействия между системами обработки СТК, установленными у разных операторов. Речь идет о поддержке систем с территориально-распределенной архитектурой и о роуминге карт.
Территориально распределенный принцип реализует возможность использовать в рамках единой системы одну и ту же карту в разных географически удаленных друг от друга центрах. Построенная по этому принципу система СТК содержит программно-аппаратные комплексы двух типов: процессинговый центр и связанные с ним через сеть передачи данных региональные узлы или самостоятельные региональные системы СТК.
Региональные системы СТК обычно располагаются в телефонных узлах и предоставляют услуги населению города, района или области, т.е. пользователям сети регионального оператора.
Процессинговый центр (ПЦ), как правило, представляет собой программно-аппаратный комплекс на базе мощного компьютера, совмещенного с сервером баз данных. ПЦ имеет кластерную структуру с возможностями распределенной обработки данных и резервного копирования и включается в сеть взаимодействующих с ним региональных узлов. Каждый региональный узел должен иметь уникальный идентификатор и уникальный пароль доступа к ПЦ.
Соединения между процессинговым центром и региональными узлами организуются с использованием любой транспортной сети (SDH,
модемы, спутниковые каналы), обеспечивающей приемлемое время реакции ПЦ на запросы в реальном времени со стороны региональных узлов. В качестве транспортного протокола целесообразно использовать TCP/IP с применением одного из кодирующих алгоритмов.
Подчеркнем, что описываемые ниже функции процессингового центра и распределение функций между процессинговым центром и региональными узлами представляют лишь один из вариантов реализации подобного решения. Однако поскольку авторы книги имеют опыт разработки оборудования, функционирующего в реальных сетях, в этом варианте учтены практические возможности и многие пожелания операторов стран СНГ, эксплуатирующих платформы Протей.
Итак, на процессинговый центр возлагаются следующие функции:
поддержка единого поля PIN-кодов, т.е. генерация серий карт (серия представляет собой заданное количество карт, каждая из которых имеет серийный номер и PIN-код, уникальные для данного процессингового центра). PIN-код генерируется случайным образом, а серийный номер может формироваться по принятым операторами правилам (например, номер серии + номер карты в серии);
передача серий карт на региональные узлы (для каждой карты передается пара «PIN-код, серийный номер») с фиксацией в базе данных процессингового центра (БДПЦ) кода «домашнего» узла каждой карты;
отслеживание текущего м естопо ложен и я и баланса каждой карты;
ведение журнала использования карт региональными узлами;
一 ведение журнала операций (вызовов) по картам.
Определяя схему хранения информации и организацию информационных потоков между элементами территориально-распределенной системы, следует исходить из нескольких основных предпосылок. Прежде всего, чтобы упростить требования к транспортной сети, повысить надежность комплекса в целом и обеспечить максимальный спектр возможностей регионального узла в режиме автономной работы, нужно минимизировать объем информации, передаваемой по транспортной сети. Могут использоваться разнообразные схемы, позволяющие сократить объем информации, которой обмениваются ПЦ и региональные узлы. Целесообразно также использовать результаты работ стандартизирующих организаций (ITU-工 ETSI) по вопросам Интеллектуальных сетей [3] в части организации расчетов с абонентами (процедуры charging протокола INAP) и расчетов между операторами.
С учетом сказанного, можно описать следующую приблизительную схему работы процессингового центра.
Информация о балансе карты в базе данных ПЦ обновляется периодически (например, ежесуточно) и/или при перерегистрации карты в другом регионе.
Информация о региональном узле, где зарегистрирована карта, обновляется в тот момент, когда через него производится первый вызов с использованием этой карты.
Информация о вызовах с помощью карты хранится на том региональном узле, через который эти вызовы произведены, и периодически передается каждым таким узлом в базу данных ПЦ. Эта же информация может быть получена и по запросу администратором БДПЦ или а дм и ни стратором любого регионального узла.
Для дополнительного контроля использования карт на каждом региональном узле организуется журнал, в который заносится сумма, снятая с карты данным узлом, когда исчерпана емкость карты, или при переходе карты в зону другого узла.
Когда к ПЦот какого-либо регионального узла поступает запрос использовать новую для него карту, процессинговый центр передает запрос отмены регистрации к тому региональному узлу, где данная карта была зарегистрирована прежде. При положительном ответе этого регионального узла на запрашивающий региональный узел передается подтверждение перерегистрации и информация о регистрируемой карте (PIN-код, номер, код «домашней» сети, баланс, административное состояние), а также обновляется информация в БДПЦ. В дальнейшем на ПЦ могут быть возложены функции координации финансовых расчетных потоков между региональными узлами.
В соответствии с описанными функциями процессингового центра, определим функции регионального узла:
получение из БДПЦ серий карт (наборов «PIN-код, серийный номер карты»);
ведение баз тарифов, тарифных зон, логических направлений, категорий карт (при поддержке этой опции) и т.п.;
一 запрос у БДПЦ регистрации карты, приписанной к другому региональному узлу, при приеме вызова по такой карте;
включение (при положительном ответе от БДПЦ) этой «карты-визитера» в таблицу карт, зарегистрированных на данном узле;
контроль текущего баланса каждой карты в течение всего времени, пока она зарегистрирована на этом региональном узле;
учет вызовов по карте, зарегистрированной на этом региональном узле;
исключение карты-визитера из таблицы активных карт по запросу от БДПЦ, если эта карта в данный момент не используется;
一 периодическая передача в БДПЦ информации о вызовах по карте и о текущем балансе карты;
一 передача в БДПЦ по ее запросу информации о вызовах по карте и о текущем балансе карты.
Рассмотрим алгоритм обслуживания вызовов по карте-визитеру.
При вводе PIN-кода региональный узел проверяет корректность этого кода и регистрацию соответствующей карты в своей локальной базе данных. Если карта не найдена (или — всегда, без поиска в локальной базе), происходит обращение к БДПЦ, получение информации о карте, и занесение ее в локальную базу с установкой в ПЦ признака использования карты и кода регионального узла, где она зарегистрирована.
При повреждении регионального узла карта закрепляется за этим узлом либо до его восстановления, либо до выполнения принудительных действий адм и н истратором БДПЦ. Чтобы обеспечить сосуществование «региональных» и «межрегиональных» карт, для них целесообразно выделить два разных номера доступа к системе СТК.
5.7 Дополнительные услуги с помощью СТК
Хотя именно обычная телефонная связь составляет львиную долю услуг; предоставляемых по СТК, не следует ограничивать только ею сферу таких услуг, поскольку СТК - это, прежде всего, практически универсальный алгоритм определения прав связи абонента и способ идентификации его счета.
Использование принципа предоплаты прекрасно сочетается с двумя основными механизмами взимания платы за услуги связи: поразговорным (или повременным), когда плата берется за количество успешных обращений к услуге (или за продолжительность пользования ею), и арендным, когда пользователь периодически вносит определенную абонентскую плату. Ниже оба механизма рассматриваются применительно к предоплаченным услугам.
При применении механизма повременной оплаты, помимо доступа к услугам телефонной связи между абонентами, с помощью СТК может обеспечиваться доступ к специализированным справочноинформационным службам оператора. Эта услуга хорошо известна в Интеллектуальных сетях под названием «информационная услуга за дополнительную плату (Premium Rate)» и рассмотрена в главе 4.1 книги [3].
Вариант, иллюстрирующий второй механизм, - абонирование услуги на определенное время или на определенное количество сеансов пользования ею. Одним из примеров такого применения системы СТК является организация доступа к услуге речевой почты подобно тому, как это сделано компанией «Санкт-Петербургские так-
6. Б.С. Гольдштейн
софоны» с использованием платформы Протей-ТК. Доступ к услуге речевой почты, предоставляемой оператором, осуществляется с использованием карт, которые служат для обычной таксофонной связи. На те карты, с помощью которых на сервере можно открыть почтовый ящик, подзащитную полосу дополнительно наносится PIN-код. Набрав номер доступа к услуге и этот код, т.е. активизировав карту в системе, владелец карты абонирует на сервере почтовый ящик. Время существования почтового ящика на сервере ограничено стоимостью карты. Этот срок можно продлить (с сохранением прежнего номера и других настроек), купив и активизировав в системе новую сервисную карту.
Еще одним видом услуг; которые могут предоставляться с использованием СТК, является стремительно набирающая популярность IP- телефония (см., например, [5], где рассмотрены, отчасти, и вопросы, связанные с СТК). Если с технической точки зрения ключевым элементом предоставления услуг I P-тел ефон и и является шлюз (Gateway), то с организационной точки зрения важнейшим элементом является система обработки СТК, т.к. именно в ней, как правило, реализуются все средства разрешения доступа к услугам и начисления платы за пользование ими. Возможны два варианта взаимодействия шлюза и системы обработки СТК.
В первом варианте шлюз поддерживает предоставление дополнительной (по отношению к «традиционной» телефонной связи) услуги IP-телефонии, доступ к которой обеспечивается с помощью СТК. В соответствующем пункте меню системы пользователю предлагается выбрать услугу: «традиционная» или IP-телефония. Сам же шлюз можетлибо быть интегрирован в состав речевого сервера, либо представлять собой один из модулей программно-аппаратного комплекса обработки СТК или отдельное устройство. В последнем случае функции системы СТК ограничиваются только начислением платы, а маршрутизация вызовов к той или к другой сети возлагается на коммутационный узел, в который все это оборудование включается.
Если поставщик услуги обеспечивает еще и доступ в Интернет, та же карта может служить Интернет-картой для путешествий по Всемирной сети. В этом случае понадобится обеспечить возможность доступа внешнего оборудования к базе данных системы СТК, например, по протоколу RADIUS.
Хотелось бы упомянуть еще об одной интересной услуге, не получившей пока распространения у нас, но очень популярной во мно「их развитых странах, - об услуге «предоплаченный обратный вызов (Call- Back)». Ею часто пользуются в тех случаях, когда тарифы на связь между двумя пунктами асимметричны (т.е. позвонить из страны Б в страну А ощутимо дороже, чем из страны А в страну Б). Обратный вызов основан на определении номера вызывающего абонента при международной связи, что сегодня плохо поддерживается россий-
скими системами сигнализации [4]. Абонент, желающий воспользоваться услугой CallBack, набирает номер доступа к системе и, услышав сигнал контроля посылки вызова, кладет трубку. Система, в свою очередь, определив номер абонента, устанавливает к нему исходящее соединение, а затем (точно так, как это делается при обычной услуге связи по СТК) передает приглашение к вводу PIN-кода и номера вызываемого абонента. Услу「а эта, из-за ощутимого различия тарифов, используется, главным образом, европейцами, которым нужно связаться с США.
Эффективен принцип предоплаты и при пользовании услу「。访 универсального персонального номера (UPN), о которой речь пойдет ниже. Услуга UPN устраняет многочисленные повторные попытки получить связь с тем, кто ею пользуется, поскольку владелец (арендатор) универсального персонального номера получает в свое распоряжение возможность назначать критерии маршрутизации направленных к нему вызовов в зависимости от местоположения вызывающего абонента и от времени суток.
Рассмотрим кратко ал「оритм обработки вызова, вход只山е「о к пользователю услугой UPN, а также роль и место принципа предоплаты при ее предоставлении. Все входящие вызовы поступают на сервер службы универсальных персональных номеров. После процедуры АОН происходит обращение к базе данных для просмотра расписания маршрутизации вызовов к тому или иному из реальных телефонных номеров. Это означает, что в зависимости от номера вызывающего абонента произойдёт обращение к той или иной маршрутной матрице. Владелец услуги UPN определяет, когда и какой из его реальных номеров должен использоваться, а также список тех вызывающих номеров, для которых предусматривается индивидуальное расписание. Если номер вызывающего абонента не найден в этом списке, то вызов должен обслуживаться в соответствии с общим расписанием. При занятости или неответе одно「о реальной? номера вызов ремаршрутизируется к другому номеру, по которому в настоящее время абонент доступен. Приоритетность реальных номеров задаётся владельцем услуги UPN.
^хПриоритет
Период4^ суток
1
2
3
4
8.30-17.45 (будни)
N1
N3
N2
N4
17.45-23.30
(будни)
N3
N2
N4
23.30-8.30 (будни)
N2
N3
N4
0.00-23.59
(выходные)
N4
Телефонный номер, группа номеров или отсутствие номера в списке
N1- рабочий номер
N2- домашний номер
N3- мобильный номер
N4- речевая почта
Рис. 5.3 Пример маршрутной матрицы для услуги UPN
Рассмотрим подробнее процесс взаимодействия владельца (арендатора) данной услуги со службой UPN. Активизация номера может производиться с использованием сервисной телефонной карты подобно тому, как это происходит при пользовании услугой речевой почты, о чем уже было достаточно подробно написано выше. Срок аренды номера может ограничиваться номиналом активизированной карты и, при необходимости, продлеваться активизацией в системе других карт на этот же номер. Для доступа к меню управления услу「ой абонент набирает номер доступа к услуге (специфический код услуги), например UPN1, после чего ему передается речевое приглашение набрать свой UPN, а затем - свой персональный идентификационный номер (PIN). После ввода вернсто PIN-кода происходит переход в конфигурационное меню или переключение к оператору службы UPN.
Сегодня при предоставлении таких услу「все сложные действия, связанные с администрированием услу「и (например, составление матрицы маршрутизации), как правило, производятся администратором системы по заявке арендатора услу「и. Кроме того, все большую популярность в Европе приобретает способ адм и н и стри ро ва - ния сложных услу「самим арендатором услуги с использованием сети Интернет. В этом случае каждый абонент, используя специальную Web-страницу, может самостоятельно, без помощи оператора, составлять расписание для маршрутизации входящих вызовов. Санкционирование доступа на соответствующей Web-странице при этом алгоритме также осуществляется с использованием PIN-кода. Простота, быстрота и удобство тако「о способа очевидны.
И, наконец, нельзя не вспомнить о такой перспективнейшей сфере применения СТК, как платежи за различные услу「и (не только услу「и связи). Се「одня в России эта услуга, как представляется авторам, находится на самой ранней стадии своего развития, однако ее потенциал заслуживает того, чтобы остановиться на ней подробнее. Как уже неоднократно「оворилось выше, человек, купивший предоплаченную сервисную карту, по сути, перечисляет сум му денежных средств, равную стоимости карты, на некий персональный целевой счет, с которого впоследствии производится оплата телекоммуникационных услу「 по мере их предоставления. Применить эту схему «в своих целях» первыми решили операторы мобильной связи. Они предложили своим пользователям интересную альтернативу. Вместо то「о чтобы ходить в специальные пункты приема платежей и там оплачивать услу「и связи, пользователь может купить специальную карту и, позвонив по определенному ном еру и активизировав эту карту в системе (набрав P1N- код), перечислить на свой (уже существующий) счет сумму, соответствующую номиналу этой карты. Услуга прижилась. Сегодня она, получив в России два альтернативных названия - «Карты авансовых платежей» и «Карты экспресс-оплаты», - широко применяется ведущими операторам и связи. Очевидно, что применение СТК для оплаты услуг не должно ограничиваться услу「ами мобильной связи. Аналогичным образом мо「утог1лачиваться любые услу「и связи, да и услуги вообще.
Следует, правда, отметить, что для зто「о потребуется хорошо организованный обмен данными на участке «оператор-банк« (при оплате услу「сторонних фирм), и, возможно, частичный пересмотр ал「орит- мов внесения платежей за услуги традиционных операторов ТфОП. Речь идет о том, например, чтобы дать владельцу карты возможность вносить плату фиксированными частями определенного номинала по аналстии стам, как это сегодня можно делать абонентам операторов мобильной связи. Следующим ша「ом будет возможность вносить плату за услуги в произвольном размере, задаваемом владельцем карты в пределах доступного остатка на карте, те. доступ с помощью СТК к услу「ам тапб6анкин「а и электронной коммерции.
Таким образом, набор дополнительных услуг, предоставляемых абонентам с использованием СТК, может быть весьма и весьма широк. Он может включать в себя кактрадиционнь1бус_пу「и Интеллектуальной сети [3] (связь с оплатой вызываемым абонентом Freephone, услу「и с дополнительной платой Premium Rate, вызовы по телефонной карте Account Card Calling и др.), так и услу「и, характерные для систем компьютерной телефонии (справочно-информационные услу- 「и, ус_пу「и IP-телефонии и др.). В недалеком будущем рост популярности предоплаченных сервисных телефонных карт будет стимулироваться еще одной областью их применения - рынком электронной коммерции. Одним словом, уже сейчас предоплаченные карты являются одной из популярнейших услуг, предоставляемых с использованием систем CTI, а потенциал их еще более впечатляет. Перспективы рынка предоплаченных карт схематически иллюстрирует рис.5.4.
Рис. 5.4 Перспективы использования разных методов оплаты телекоммуникационных услуг
Глава 6 Ступени распределения вызовов
Впечатление о фирме создается у клиента по первому телефонному звонку в нее.
Принцип японского менеджмента
Основные понятия
Одной из ключевых прикладных областей компьютерной телефонии являются Call-центры, называемые также операторскими центрами или инфоцентрами, т.е. центрами п редоставлени я по телефону информационных услуг. Отметим, что под информационной услу- 「ой понимается любая услу「а, предусматривающая прием информации от клиента, обработку и, если требуется, дальнейшее продвижение этой информации, передачу клиенту ответной информации, а также распределение заранее гюд「отовлбнной в центре информации по списку, то есть передачу ее всем клиентам, занесенным в этот список. Информационными услу「амм являются, в частности, прием всевозможных заказов (информация о заказе, полученная от клиента, после соответствующей обработки пересылается исполнителю заказа), выдача разнообразных справок (например, о номере телефона) или сведений (например, о про「нозе попэдн), передача группе клиентов свежих рекламных объявлений по интересующим их вопросам и др. В предоставлении информационных услуг, как правило, участвуют операторы центра (называемые также агентами).
Этой области применения компьютерной телефонии посвящены 「лавы 6, 7 и 8, составляющие вместе значительную по объему
и очень важную по содержанию часть этой книги. В настоящей главе рассматривается исторически первая версия Call-центра (можно сказать, его прародителя), наиболее распространенная в России, -автоматические ступени распределения вызовов (СРВ), используемые в операторских центрах и именуемые в англоязычной литературе Automatic Call Distributing (ACD). Употребляются также названия: Automated Call Distribution (автоматизированное распределение вызовов), Automated Call Distributor (автоматизированный распределитель вызовов), Automatic Call Dispatcher (автоматический диспетчер вызовов) и другие. Связь СРВ с ТфОП и с операторами центра иллюстрирует рис. 6.1.
Группа 1Группа 1Группа 2Группа 2Группа 3Группа 3Рис. 6.1 Конфигурация СРВРис. 6.1 Конфигурация СРВ
Группа 1
Группа 1
Группа 2
Группа 2
Группа 3
Группа 3
Рис. 6.1 Конфигурация СРВ
Рис. 6.1 Конфигурация СРВ
Операторские центры, как правило, работают в круглосуточном режиме, а интенсивность потока поступающих к ним вызовов может достигать нескольких сотен вызовов в минуту. В Call-центрах используются информационные ресурсы, хранящиеся в соответствующих базахданных, обрабатывается и запоминается поступающая информация, автоматически п ротокол и руется вся деятельность операторов, связанная с обслуживанием вызовов, а также выполняется целый ряд других функций, о которых речь пойдет ниже.
Но главной задачей, которую решаютоператорские центры, было и остается обеспечение ответов на возможно большее количество входящих вызовов и/или создание и завершение возможно большего количества исходящих вызовов, ибо каждый вызов, требующий обработки в Call-центре, либо является потенциальным источником дохода, либо несёт в себе важную информацию. Потеря вызова крайне нежелательна, а иногда и просто недопустима.
Помимо этого, необходимо предусмотреть как можно более рациональное распределение входящих вызовов между операторами (агентами центра) в соответствии с их функциональными задачами и квалификацией, а также обеспечить контроль работы операторов управляющим персоналом центра. Разработаны специальные технологии, при использовании которых запросы разной сложности могут обрабатывать операторы, имеющие разную квалификацию. В состав программного обеспечения Call-центров часто включается приложение, которое выполняет функции интеллектуального распределения входящих вызовов согласно разным сценариям их обработки. В такие сценарии, которые либо программируются непосредственно адм и н истратором системы, либо выбираются им из некоторого набора возможных вариантов, заложены алгоритмы работы с запросом, правила оптимального выбора оператора (или группы операторов), методы и возможные результаты обслуживания того или иного клиента.
Рост популярности операторских центров пришелся на середину 70-х годов. Это было обусловлено стремительным ростом потока входящих вызовов к крупным компаниям, что было связано, во- первых, с ростом популярности торговли по телефону, а во-вторых, 一 с потребностями клиентов компаний в послепродажном обслуживании и в выполнении гарантийных обязательств. Клиенты больше не хотели неделями ждать ответа на свои письма в отдел обслуживания; они предпочитали снять трубку и набрать номер соответствующей службы.
Практически в это же время стали распространяться СРВ в городских телефонных сетях СССР, правда, по совершенно иным причинам. Отсутствие телефонных справочников не только в таксофонных будках, но и в продаже, неразвитость средств и сетей передачи данных, отсутствие служб типа телетекст и т.п. - все это вызывало потребность в обращении к справочно-информационным службам ГТС, наиболее популярной из которых была служба информации о номерах телефонов 09. Обо всем этом речь пойдет далее.
История СРВ начиналась с системы, созданной в американской компании Rockwell. Первая полностью цифровая система автоматического распределения вызовов для операторского центра, управляемая компьютером, была разработана Говардом Уолратом (Howard Walrath), который возглавил группу разработчиков компании Rockwell в начале 1970-х годов. Послеслияния в 1973 году компании Rockwell и Collins Radio Company, разработчики стали использовать технологию Collins, первоначально предназначавшуюся для средств резервирования IBM, в связи с чем система автоматического распределения вызовов была названа Collins Galaxy СРВ.
К1976 году системы Collins Galaxy СРВ использовались 10-ю крупнейшими авиакомпаниями, а также многими компаниями по аренде автомобилей, отелями и центрами авторизации кредитных карт. Мгновенный успех концепции СРВ привёл к созданию подразделения Rockwell Switching Systems Division, которое было впоследствии преобразовано в Rockwell Electronic Commerce. В 1985 году Уолрат уволился из Rockwell. Производство Galaxy СРВ было прекращено в декабре 1997 года, хотя существующие контракты на обслуживание этой системы продолжают действовать до ноября 2007 года.
Ступени распределения вызовов образца 1970 - 1980-х годов представляли собой относительно простые специализированные коммутаторы, устанавливающие соединения с первым незанятым оператором в группе операторов. По современным критериям такие СРВ относятся, скорее, к менее интеллектуальным технологическим системам равномерного распределения вызовов UCD (Uniform Call Distributor), которые распределяют входящие вызовы между операторами группы в соответствии с заранее определённой логикой. Возможными алгоритмами распределения вызовов являются нисходящий метод (top-down) или более популярный циклический метод (round-robin). Такие простые СРВ не пре дуематривал и мониторинг или анализ трафика в реальном времени, не определяли, какой оператор наиболее загружен или дольше всех не был занят обслуживанием вызовов. Они не различали запросы клиентов; вне зависимости от вида запроса клиент слышал стандартное записанное сообщение: «Спасибо за звонок. Пожалуйста, не кладите трубку. В данный момент все наши операторы заняты. Через некоторое время вам ответят...». Такое же оборудование, к сожалению, и сегодня работает у большинства российских операторов связи. Интеллект систем СРВ ограничивался выдачей статистических отчётов об общей производительности операторского центра (например, число вызовов на одного оператора в час). Не предпринимались попытки классифицировать вызовы по типам, объединить операторов и телефонную систему в локальную сеть, автоматически анализировать содержание запросов и т.п.
В настоящее время для оснащения операторских центров могут использоваться системы трех основных категорий:
специально разработанные для этих целей системы типа СРВ 30/24;
一 УАТС с функциями СРВ типа Meridian, Hicom, Definity, Coral, Millenium и др.;
платформы компьютерной телефонии (CTI), в том числе, их новейшие модификации, интегрированные с Интернет, и решения, предусматривающие комбинацию СРВ/УАТС и внешнего сервера CTI, о чем подробнее будет сказано в следующей главе.
В этой главе будет рассмотрена, главным образом, первая из названных категорий, хотя на функциональном уровне всё, излагаемое ниже, будет справедливо и для двух остальных.
Основная функция любого операторского центра - приём вызовов, поступивших к центру, и передача их (по заранее запрограммированному алгоритму) на обслуживание к свободному оператору. Пример структуры операторского центра представлен на рис.6.2. На нем не показаны средства аудиотекса, интеллектуальной обработки и маршрутизации поступающих и ожидающих вызовов, системы интерактивного речевого ответа (IVR), средства маршрутизации на основе указаний вызывающего абонента (Caller-Directed Routing) и другие средства автоматизации обработки вызовов, которыми уже давно оснащаются современные операторские центры, но которые обычно являются принадлежностью именно Call-центров, а не традиционных систем СРВ, и поэтому рассматриваются в следующей главе. К этому доба вл я ются специфические функции, связанные непосредственно с процессом предоставления услуг справочно-информационными и диспетчерскими службами, службами бронирования билетов на все виды транспорта или мест в гостинице, вызова такси, экстренными службами (скорая помощь, милиция, газовая аварийная служба), операторами сотовой и пейджинговой связи, предприятиями торговли по каталогам, справочными аптек и т.д. В России спектр такого рода служб всегда был несколько уже - СРВ применялись, главным образом, для оснащения экстренных спецслужб, а также справочно-информационных и заказных служб ГТС.
Рис. 6.2 Типичная конфигурация УАТС/СРВ для операторского центра
Опыт ВСС России
Практика, которая сложилась в российских телефонных сетях, оснащенных, преимущественно, коммутационным оборудованием электромеханического (декадно-шагового и координатного) типа,
предусматривала два основных способа включения справочно-информационных и заказных служб в ГТС:
службы с сокращенными двузначными или трехзначными номерами, начинающимися с нуля (так называемые спецслужбы), включались в ГТС через один узел, называемый узлом спецслужб (УСС);
службы с полными (абонентскими) номерами включались в разные районные АТС по абонентским линиям с серийным исканием. Функции узла спецслужб состоят в следующем:
идентификация вызывающего абонента, те. определение категории и номера абонентской линии, от которой поступил вызов службы;
определение по категории вызывающей абонентской линии права выхода на данную службу (администрация ГТС имеет право запретить выход на некоторые службы для линий определенных категорий; например, может быть запрещен выход на платные службы с местных таксофонов или с телефонов гостиниц);
подключение автоинформатора; например, если выход на вызываемую службу пользователю не разрешен, то УСС с помощью автоинформатора сообщаетемуобэтом, аесли выход разрешен, но служба платная, то автоинформатор может сообщить пользователю стоимость услуги и предупредить его, что он может отказаться от этой услуги, положив трубку;
фиксация данных, необходимых для формирования счета абоненту при вызове им платных служб (номер телефона, с которого сделан вызов, код службы, дата);
передача к службе (при необходимости) сведений о категории и номере вызывающего ее абонента;
прием вызова, исходящего от оператора службы и направленного к абоненту ГТС, что позволяет оператору службы по просьбе пользователя соединить его через оборудование СРВ с этим абонентом.
Пример включения в УСС службы, обрабатывающей как местные, так и междугородные вызовы и предоставляющей операторам возможность вызова абонентов ГТС, представлен на рис.6.3. СРВ службы связан с УСС тремя пучками цифровых соединительных линий ИКМ:
входящим (к службе) пучком для местных вызовов;
входящим пучком для междугородных вызовов;
исходящим пучком для вызовов операторами службы абонентов ГТС.
Раздельные пучки соединительных линий для местных и междугородных вызовов предусматриваются для того, чтобы обеспечить приоритетное обслуживание междугородных вызовов. На соединительных линиях между УСС и СРВ могут использоваться системы сигнализации следующих типов:
сигнализация по 2ВСК;
сигнализация DSS1 (30B+D);
сигнализация ОКС7.
При использовании УСС включенные в него платные службы не должны идентифицировать вызывающих абонентов и фиксировать исходные данные для начисления платы за оказанные услуги - это делает централизованно УСС. Однако если службе требуются сведения о категории и номере вызывающего абонента, УСС можегпередать ей эту информацию.
Пример децентрализованного способа включения служб по двухпроводным соединительным линиям с абонентской сигнализацией, предусматривающего использование услуги переадресации в цифровых АТС, представлен на рис.6.4.
к ГТС
Районная АТС
Службе присваивается абонентский номер, при приеме которого АТС переадресует вызов на пучок соединительных линий к СРВ. При этом не теряется номерная емкость АТС, в которую включена служба. Вызовы, поступающие от иногородних пользователей, районная АТС направляет к СРВ по отдельному пучку соединительных линий.
С 1977 года в таких случаях использовалась разработанная ЛОНИИС совместно со Свердловским филиалом ЦКБ Минсвязи аппаратура справочной службы АСПС, которая представляла собой ме- ханоэлектронную ступень распределения вызовов на координатных соединителях с электронным управлением по зам оптированной программе, и соответствующие рабочие места. В АСПС впервые был введен режим обслуживания с ожиданием, что избавляло абонентов от необходимости делать повторные вызовы при занятости всех операторов службы. Операторы АСПС разделялись на секторы (в службе 09 это были учрежденческий и квартирный секторы) с возможностью перевода вызова из сектора в сектор. При возникновении конфликтной ситуации вызов абонента мог быть передан на рабочее место бригадира. Для контроля обслуживания абонентов операторами предусматривалась возможность незаметного подключения к тракту «абонент-оператор» контролера, который мог записать разговор оператора с абонентом на магнитофон. Оборудование обеспечивало равномерную загрузку операторов.
К 1993 году в качестве замены АСПС была разработана и начала выпускаться цифровая СРВ 30x24 с программным управлением, внешний вид которой представлен на рис.6.5. С городской телефонной сетью СРВ 30x24соединяется трактами ИКМ, афункция запроса информации АОН обеспечивает идентификацию абонента, обращающегося к службе, что дает возможность выставлять счет за платные справки.
Таким образом, выбор способа включения СРВ в ГТС связан с принятой в России классификацией справочно-информационных, заказных и специальных служб и с их нумерацией.
В ТфОП предусмотрена следующая классификация служб.
Первая группа-это специальные службы, предоставляющие услуги общенационального значения и имеющие единые для территории всей страны сокращенные номера (двузначные и трехзначные, начинающиеся как с нуля, так и с единицы в переходный период; только трехзначные, начинающиеся с единицы при использовании перспективной нумерации после завершения переходного периода). Сюда входят экстренные спецслужбы: пожарной охраны, милиции, скорой медицинской помощи, аварийной службы газовой сети, а также служба «Спасение» и некоторые другие службы.
Ступень распределениявызовов СРВ 30X24
Рабочее место оператора
Рабочее место оператора
OQQOQQO
Информа-ционнаябаза данных
2-х или 4-х проводные АЛ
Рабочее место контролера РМО № 22
RS 232
] Блок
EthernetEthernet
Ethernet
Ethernet
УправляющийкомпьютерСРС
Рис. 6.5 Цифровая ступень распределения вызовов СРВ 30/24
Для вызова служб первой группы предусматриваются сокращенные номера, приведенные в таблице 6.1.
Таблица 6.1
Наименование спецслужбы
Нумераци
Действующая
Перспективная
Пожарная охрана
01
101
Милиция
02
102
Скорая медицинская помощь
03
103
Аварийная служба газовой сети
04
104
Служба спасения
051
112
Справка о номерах телефонов по полным данным
09
118
Справка о номерах телефонов по неполным данным
009
109
Междугородная информационно-справочная служба
07/070
170
Международная информационно-справочная служба
07/078
178
Служба приема заказов на междугородные переговоры
07/007
107
Служба приема заказов на международные переговоры
07/057
117
Справочная служба по претензиям за услуги связи
050
150
Служба точного времени
060/100
100
Федеральная служба ОП FLEX
081
181
Федеральная служба ERMEC
082
182
Служба информации ГИБДД
002
122
Прием телеграмм по телефону
066
166
Служба СПАС
000
110
На тот случай, когда необходимо организовать дополнительные спецслужбы, предусмотрены резервные номера: 003, 008, 052, 059, 068. Назначение номеров для таких спецслужб производится Министерством связи России в соответствии с «Руководством о порядке распределения и возвращения ресурсов нумерации телефонных сетей связи России», утвержденным приказом Гостелекома России от 03.07.1999, №10.
Ко второй группе относятся службы, организуемые местными органами власти. Это могут быть, например, спецслужбы, ориентированные на выдачу справочной информации и на оказание услуг в соответствии с потребностями данного населенного пункта: справочно-информационные службы городской администрации, милиции, здравоохранения, аптекоуправления, службы справок о пропавших людях, пропавших животных, гуманитарно访 помощи, справок по вопросам ведения хозяйства, обучения, юридической помощи, работы органов местного управления, банковской деятельности, курса валют, о новостяхторговли, культурной жизни, спорта, о ритуальных услугах, номерах телефонов абонентов и учреждений, по вопросам трудоустройства, недвижимости, службы приема заявок на оказание услуг медицинскими учреждениями, управлением Горгаза, службы приема заказов на доставку товаров, на передачу рекламных объявлений, на обеспечение перевозок, на оказание услуг бытового харак-
тера, юридической помощи, аварийно-диспетчерские службы городского хозяйства, транспорта и т.п. Номера для таких служб выделяет институт Гипросвязь, закрепленный за данной зоной нумерации, в соответствии с порядком и требованиями, изложенными в уже упоминавшемся «Руководстве о порядке распределения и возвращения ресурсов нумерации телефонных сетей связи России» от 03.07.1999. При увеличении количества служб для их вызова могут использоваться резервные номера: 071,072, 073, 074, 075, а также серийные номера местной телефонной сети, назначаемые операторами связи.
К третьей группе относятся службы справок по вопросам предоставления услуг связи, а также любые другие информационно-справочные и заказные службы, создаваемые операторами ОАО «Электросвязь», ОАО «Связьинформ» и др. К этой группе могут быть отнесены, например, службы справок по вопросам предоставления услуг почтой, телеграфом, операторами связи, сетями подвижной связи, Интернет, о задолженности за услуги, предоставленные этими сетями и др., службы приема заявок на ремонт аппаратуры связи, замену номеров, перестановку и переключение телефонных аппаратов, установку параллельных телефонных аппаратов и дополнительных розеток, службы справок о телематических услугах и услугах передачи данных, передачи рекламы и др. При создании новых спецслужб этой группы для их вызова могут использоваться резервные сокращенные номера: 053, 067, 076, 077, 079, а также серийные номера местной телефонной сети, назначаемые операторами связи.
В четвертую группу входят прочие службы, к которым относятся службы справок об услугах фирм, предприятий торговли, рекламы товаров и услуг и т.п. К таким службам могут быть отнесены, например, информационно-справочные и заказные службы телебанка, службы справок по вопросам деятельности разных страховых компаний, отдельных фирм, справок об их местоположении, режимах работы и т.д,, службы справок по вопросам торговли, оказания посреднических услуг, психологической помощи, знакомств, местных, междугородных и международных перевозок, наличия продовольственных и промышленных товаров и приема заказов на их доставку на дом, ветеринарной помощи, оказания услуг связанных с обменом собственности, туризма, службы справок о выигрышах госзаймов, лотерей, лото, о результатах спортивных соревнований в нашей стране и за рубежом и т.п. Для этих служб должны использоваться серийные номера местной телефонной сети, выделяемые операторами связи. При наличии технической возможности, по усмотрению операторов ОАО «Электросвязь», ОАО «Связьинформ» и др., таким службам могут присваиваться трехзначные номера из резерва, закрепленного за специальными службами этих операторов.
Варианты включения СРВ в УСС разных типов согласно принципу, показанному на рис.6.3, представлены на рис. 6.6.
РАТС АТ-ДШ .^221
РАТС
б)УСС-АТСК
Рис. 6.6 Структурная схема организации связи абонентов со спецслужбами, включенными в УСС электромеханических систем
Функциональные возможности СРВ
В этой главе уже упоминалось, что ступени распределения вызовов работают как системы обслуживания с ожиданием. Пока количество входящих вызовов, требующих обслуживания, меньше, чем количество доступных терминалов операторов, каждый новый вызов будет немедленно направлен оператору в соответствии с используемым алгоритмом и логикой, содержащейся в специальной базе данных о правилах маршрутизации. Если же все операторы заняты, вызовы ставятся на ожидание.
СРВ должна вести мониторинг состояния операторов и направлять вызовы к свободным операторам в максимально возможном темпе. Операторы 一 это самые дорогие компоненты операторского центра, а потому необходимо стремиться к повышению производительности их труда, применяя надлежащие алгоритмы функционирования СРВ (т.е. разумно организуя механизмы распределения вызовов и системы очередей).
Недавно начатые у нас серьёзные исследования рынка привели к внедрению технологий, давно известных в странах с рыночной экономикой. Так называемый маркетинг пользовательских связей 一 технология, базирующаяся на изучении интересов пользователей и анализе их потребностей, - позволяет корректировать поведение организации по отношению к каждому отдельному клиенту (клиентским группам) на основании статистической информации, накапливаемой в оборудовании, которым оснащен операторский центр. Подобные наблюдения позволяют выяснить, насколько важна информация, предоставляемая центром, насколько «средний» абонент терпелив и насколько он заинтересован в том, чтобы получить необходимую информацию вовремя. Это хорошо видно на примере такого параметра, как среднее время ожидания обслуживания. Если информация, которую хочет получить абонент, для него чрезвычайно важна, то, как показывают наблюдения, он готов потратить на ожидание столько времени, сколько потребуется. Если же он не слишком заинтересован в получении этой информации, или может получить ее в каком- либо другом месте, то такое его поведение маловероятно.
Известно, что нагрузка Call-центра может зависеть от дней недели, времени суток, сезона (очевидно, что летом, в период отпусков, операторские центры, занимающиеся бронированием билетов, загружены больше, чем, например, поздней осенью, а справочно-информационные службы обслуживают больше запросов в дневное время, чем в ночное). В связи с этим возникает необходимость оптимизировать характеристики ожидания клиентами обслуживания, для чего требуется постоянно вести статистику загруженности операторов, и, на основе накопленной информации, увеличивать или уменьшать их количество в часы (дни) пиковой нагрузки.
Важной функцией СРВ, необходимой для Call-центров, которые предоставляют платные услуги, является поддержка т.н. «черных списков» и «белых списков». Это означает, что при приеме каждого входящего вызова анализируется информация о номере вызывающего абонента на тот предмет, в каком списке этот номер (или категория АОН) присутствует. Если номер обнаруживается в «черном списке», то вызов получает отказ в обслуживании. Как правило, эта функция применяется службами, предоставляющими информацию в кредит. В «черные списки» могут вноситься номера неплательщиков, или номера (маски номеров, список категорий), которым платные услуги в принципе не могут предоставляться в кредит (таксофоны, номера гостиниц ит.п.).
Попытаемся систематизировать и разбить на смысловые группы основные возможности, которыми должна обладать современная СРВ. Эти возможности можно разделить на несколько больших групп:
функциональные возможности маршрутизации и обработки вызовов, имеющиеся в самой СРВ;
функциональные возможности операторов СРВ;
функциональные возможности административного управления ресурсами СРВ.
Маршрутизация и обработка вызовов
В эту группу функций входят функции приема и обработки входящих вызовов, установления исходящих соединений, организации очередей и управления ими.
Возможности маршрутизации, которыми должна обладать СРВ, определяются задачами, которые выполняет операторский центр. Если Call-центр обслуживает только входящие вызовы (что чаще всего и бывает связано с термином СРВ), то функции маршрутизации сводятся к приему вызова и к определению того, в какую службу его надо направить. Это означает, что следует найти линию к свободному оператору нужной службы, а если таковых нет, то поместить вызов в соответствующую очередь. Под службой понимается часть операторов, обслуживающих вызовы определенного типа и из определенной очереди. Существенно, что не каждая группа операторов должна иметь прямой номер в плане нумерации телефонной сети. Часто внутри одной службы организуется несколько групп операторов, одна из которых выполняет диспетчерские функции. Операторы этой группы принимают вызовы от абонентов ТфОП и переадресуют их к той или иной из остальных групп в соответствии со специализацией ее операторов. Так работают, например, службы скорой помощи и некоторые справочные службы широкого профиля.
С точки зрения маршрутизации входящих вызовов к современным СРВ предъявляются следующие специфические требования:
возможность обслуживания входящих вызовов в ответном или предответном режиме;
идентификация вызывающей стороны по информации АОН;
поддержка в одной системе нескольких групп операторов и очередей.
Функции переадресации вызовов по заранее заданным критериям могут иметь разнообразные варианты реализации, которые, в общем случае, сводятся к двум:
переадресация вызовов к другой группе операторов в той же СРВ;
переадресация вызовов к другой СРВ.
Критериями, по которым производится переадресация, как правило, являются время суток, размер очереди к определенной группе операторов или к СРВ в целом, информация о вызывающем абоненте и т. п.
Дисциплины очередей и алгоритмы обслуживания вызовов
За каждым системным ресурсом, который может обслуживать вызовы с ожиданием, закрепляется некая очередь. Это означает, что вызов, который поступил в систему при отсутствии ресурса, способного его обслужить, не теряется, а устанавливается на ожидание.
Пока вызов находится в очереди, абоненту, его создавшему, как правило, либо передается музыка или рекламная информация, либо предоставляется связь с системой IVR, о которой уже говорилось выше. Здесь же мы остановимся подробнее на дисциплине выбора вызовов из очереди и распределения их по рабочим местам операторов.
В ранних версияхСРВ эта дисциплина предусматривала маршрутизацию вызова, стоящего в очереди первым, ктому незанятому оператору, который был обнаружен первым при циклическом поиске (так называемая дисциплина NAA- Next Available Agent). Дисциплина NAA работает хорошо, если поступающий трафик равномерен, а все операторы имеют одинаковую квалификацию; в противном случае применение этой дисциплины ведёт к перегрузке наиболее квалифицированного персонала. Для такого случая лучше подходит дисциплина с маршрутизацией вызова, стоящего в очереди первым, ктерми- налу того оператора, который простаивал дольше других; подобная стратегия позволяет распределить нагрузку между операторами более справедливо.
Традиционно вызовы, установленные в очередь, обрабатывались по принципу FIFO - «первым поступил - первым обслужен». Однако
разнообразие задач, стоящих перед СРВ в центре обслуживания вызовов, приводит к разнообразным модификациям дисциплины организации очередей с возможностью производить выбор вызовов из очереди не только в порядке их поступления, но и по сложной многокритериальной системе (например, в первую очередь обслуживать вызовы OTVIP-номеров и т.п.). Такими модификациями, наряду с FIFO и равномерным распределением вызовов по операторам, являются приоритетное обслуживание вызовов определенного типа или обслуживание вызова, в зависимости отего параметров, оператором соответствующей квалификации.
Помимо дисциплины выбора вызовов из очереди и выбора операторов для их обслуживания, и сами очереди, в зависимости от структуры системы, могут быть организованы разными способами:
индивидуальные очереди к каждому оператору;
очередь к службе (группе операторов);
единая очередь ко всем службам, доступным через данную СРВ.
По мере укрупнения и усложнения систем возникла необходимость создавать группы операторов общих интересов или одинаковой квалификации и устанавливать к каждой такой группе очереди вызовов от автооператора (Automated Attendant), от IVR, согласно схеме маршрутизации на основе информации АОН о вызывающем абоненте и т.п. При этом, однако, стали возможны случаи длительного ожидания в одних очередях при наличии незанятых операторов, обслуживающих другие очереди. В более сложных вариантах организации очередей эта проблема решалась путём использования нескольких уровней возвратной маршрутизации (Fallback Routing). Вызов устанавливался в очередь к определенной группе операторов лишь на некоторое время, по истечении которого он маршрутизировался заново, имея при этом доступ к более крупной группе операторов. Есл и дл ител ьность ожидания и в этом случае достигала пороговой величины, вызов получал право доступа к еще более крупной группе операторов, маршрутизация производилась еще раз и т.д.
Существуют более сложные модификации дисциплины организации очередей. Одной такой модификацией является распределение поступающих вызовов с учетом интегрального показателя обслуживания вызовов и индивидуального коэффициента оператора. Вызов должен направляться к тому свободному оператору, для которого частное от деления интегрального показателя на его индивидуальный коэффициент является наименьшим.
Существуют модификации, связанные также и с анализом характера поступившего вызова с тем, чтобы направить его к оператору, который имеет квалификацию, наиболее подходящую для обслужи-
вания именно этого вызова. Такая дисциплина называется SBR - маршрутизацией на основе квалификации (Skills-Based Routing). Этот способ маршрутизации становится жизненно необходимым для крупных комплексных СРВ и для их «прямых потомков» - Call-центров, предоставляющих широкий спектр услуг; или для международиых центров, которые должны обслуживать поступающие от клиентов вызовы на разных языках.
Операторы в системе
Итак, наконец-то очередь до шла до рассмотрения ключевого объекта операторского центра обслуживания вызовов 一 оператора. Согласно определению уже рассматривавшегося в главе 3 стандарта R.100, оператор (агент) 一 это человек или устройство, основной функцией которого является обработка вызова. Операторы идентифицируются в системе уникальным номером (именем) и имеют каждый свой пароль, который используется при регистрации оператора на рабочем месте (на конкретной консоли).
Понятно, что физически вызовы распределяются по консолям. Логически же распределение происходит по операторам, которые на этих консолях в данный момент зарегистрированы. Поэтому для СРВ, в которых поддерживается несколько служб, необходимо решить вопрос о распределении консолей по операторским группам. Распределение может быть различным, следовательно, будут различаться и способы регистрации. Обычно это определяется организационной структурой операторского центра. Если известно, что консоли одной службы не могут использоваться операторами другой службы, то каждая консоль жестко закрепляется за какой-то группой; в этом случае оператор при регистрации вводит только свое имя и пароль. Если же консоли могут использоваться операторами, работающими в любой из групп (служб), как, например, это происходит сегодня во многих ГТС при организации платной и бесплатной справочных служб 09 и 009, то консоли ни за одной группой жестко не закрепляются, и в этом случае оператор, регистрируясь, дополнительно вводит номер группы (службы), в которой он собирается работать.
Консоль может быть реализована разными способами, в зависимости от аппаратно-программных решений, примененных в оборудовании в целом. Вообще говоря, в любой современной системе распределения вызовов консоль состоит из телефонной и компьютерной составляющих.
В традиционной архитектуре телефонная часть консоли обеспечивает прием телефонных вызовов и представляет собой устройство поддержки речевого диалога «абонент-оператор». В самом простом случае - это аналоговый телефонный аппарат с гарнитурой,
подключаемый к системе по двухпроводной аналоговой абонентской линии. В некоторых системах - это стандартный телефонный аппарат ISDN или специализированный аппарат, снабженный жидкокристаллическим дисплеем, светодиодами для индикации вызова и функциональными клавишами, посредством которых производятся вс^ основные операции, связанные сего обслуживанием (прием, переадресация, отбой ит.п.).
Компьютерная составляющая поддерживает интерфейс оператора со специализированной базой данных службы. В большинстве сегодняшних систем эти две составляющие используют для обмена информацией принципиально разные сети и синхронизируются через управляющий сервер СРВ. В наиболее удачных СРВ наблюдается тенденция к интеграции обеих составляющих в единое целое, что сделано, например, в СРВ 30x24, о которой речь шла во втором параграфе этой главы. Обычно в таких СРВ аппаратные средства поддержки телефонного интерфейса встраиваются в персональный компьютер в виде специализированной платы. Подобное решение существенно повышает эффективность работы оператора, поскольку пользовательский интерфейс единого устройства более удобен, однако стратегически является промежуточным, т.к. две сети внутри центра обработки вызовов по-прежнему функционируют раздельно.
Возможность сделать революционный шаг вперед дало появление IP-телефонии. Благодаря развитию средств передачи речи через сеть IP стало возможным интегрировать не только физические устройства, но и сети, а также, «между делом», решить вопрос с автоматической реализацией таких услуг; как удержание соединения и наведение дополнительной справки, поскольку поддержка протоколами IP-телефонии нескольких речевых сессий не представляет собой технической проблемы. Консоль оператора на базе технологии IP-телефонии - это терминальное устройство принципиально нового уровня, обладающее высоким интеллектом и дающее операторам центров обработки вызовов качественно новые возможности. Именно такие решения применены в Call-центре нового поколения ПРО- ТЕЙ-РВ, реализованном на базе и нтел л ектуа л ьн о й платформы ПРОТЕЙ и подробно рассматриваемом в главе 8.
Во всех этих вариантах реализации оператор в системе обычно характеризуется следующими атрибутами:
фамилия, имя, отчество;
личный идентификационный номер;
личное регистрационное имя (номер) и пароль;
дополнительные данные, определяющие права и квалификацию оператора (категория, индивидуальный коэффициент и т.п.).
Управление этими атрибутами возлагается на администратора системы.
Возможности, предоставляемые оператору, определяются его правами и задачами, решаемыми данным Call-центром. В общем случае они описываются следующим набором функций:
регистрация в определенной операторской группе;
прекращение регистрации;
кратковременная блокировка консоли;
прием входящих вызовов из очереди (персональной, очереди группы, очереди центра);
переадресация вызова (к другому оператору, к старшему оператору, к другой группе операторов, к автоинформатору);
принудительное разъединение;
удержание соединения с одновременным служебным вызовом старшего оператора (для консультации);
запись разговора с абонентом;
прием от системы исходящего соединения, установленного ею по списку оповещения.
Старший оператор (контролер) имеет право не только заниматься обслуживанием вызовов, поступающих от абонентов, но и контролировать работу операторов в группе (подключаясь в режиме скрытого прослушивания и анализируя статистическую и оперативную информацию).
Оповещение о входящем вызове может быть передано на рабочее место оператора двумя способами:
посредством визуальной индикации;
тональным сигналом, посылаемым в гарнитуру оператора.
Служебная исходящая связь позволяет любому оператору получить, при необходимости, дополнительную справочную информацию или информацию, связанную с его работой в системе. Оператор может производить со своего рабочего места вызовы к другой группе операторов, к конкретному оператору в своей группе (если это разрешено), к старшему оператору своей группы, а также вызовы к автоинформатору и (при необходимости) к абонентам городской телефонной сети.
В зависимости от алгоритма работы службы, рабочие места операторов могут возвращаться в число доступных автоматически (по окончании разговора) или по команде оператора (если, например, оператор после разговора должен заносить в базу данных какую-либо информацию).
Статистика и учет вызовов
Как уже было упомянуто выше, важнейшей функцией СРВ является учет вызовов и накопление статистической информации. Накопление и анализ статистической информации о работе операторов и в целом служб, организованных на базе СРВ, являются основным средством оценки эффективности функционирования центров и настолько важны, что некоторые телекоммуникационные форумы даже разработали набор нормативных документов, стандартизирующих эти функции. Одним из наиболее хорошо проработанных стандартов этого направления является, например, стандарт R.100 форума ЕСТЕ
Прежде всего, следует разделить накапливаемую и контролируемую информацию на три основные категории: статистическая, оперативная, учета вызовов.
Оперативная информация позволяет обслуживающему персоналу Call-центра контролировать функционирование оборудования, оценивать текущую загрузку центра и т.п.
К оперативной информации, в общем случае, можно отнести:
информацию о текущей загрузке разговорных каналов;
информацию о текущей длине очередей;
информацию о текущем состоянии операторских консолей;
информацию о текущем состоянии определенного оператора.
Информация учета вызовов включает в себя параметры каждого вызова, принятого/обслуженного/потерянного системой СРВ.
В качестве примера статистики СРВ на рис 6.7 представлена экранная форма для оборудования СРВ 30/24.
国D fit! СРВ30х24 Версия №060901 -0102w2.1 Программа CpclP.exe
Команды Окна Справка
и ®в н &
Состояние
поступившие вызовы: 产|
СРВ
Сеть
СОМ
переключенные вызовы:卜]
обслуженные вызовы: Р
каоичив песта
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Каналы
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1G
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Рис. 6.7 Экранная форма статистического отчета
-5 Системы отчетности и управления операторским центром
Ниже перечислены основные параметры, статистические данные о которых, как правило, накапливаются и анализируются в Call-центре:
тип вызова (входящий, исходящий или внутренний);
количество вызовов за определённый промежуток времени (по данным работы зарубежных операторских центров эта величина составляет порядка 100 вызовов на одного оператора в сутки и от 5 до 18 вызовов на одного оператора в час);
средняя длина очереди (величина, нужная для оптимизации числа операторов);
средняя длительность разговора (на основании данных о работе американских операторских центров эта величина приблизительно равна 3,5 минуты);
доход, полученный за день;
расходы на организацию исходящих соединений;
средняя стоимость обслуживания вызова службой данного типа;
соотношение числа клиентов, обслуженных с помощью системы IVR и с помощью операторов;
время, в течение которого все линии были заняты;
среднее время занятости оператора (в процентах продолжительности рабочего дня; в центрах западных стран это приблизительно 65-75%);
среднее число операторов, находящихся в системе за определённый промежуток времени;
среднее время удержания соединения;
средняя длительность интервала между окончанием обслуживания вызова и началом обслуживания следующего вызова (от 20 до 30 секунд минимум);
максимальная длительность ожидания;
не обслуженные вызовы (т.е. когда абонент не дождался ответа оператора или не дозвонился по причине занятости всех операторов и мест в очереди);
среднее число повторных вызовов;
идентификационный номер оператора, обслужившего вызов;
номер группы операторов;
процент обслуженных вызовов.
Архитектура и перспективы эволюции СРВ
С концептуальной точки зрения, пик развития специализированных ступеней распределения вызовов теперь уже в прошлом, хотя, в силу экономических причин, они до сих пор успешно производятся и продаются, особенно в России. Основные их потребители - справочно-информационные и диспетчерские службы, службы бронирования билетов на транспорт всех видов или мест в гостинице, службы вызова такси, экстренные службы (скорая помощь, милиция, пожарная команда, служба спасения), службы поддержки абонентов сотовой и пейджинговой связи, клиентов организаций торговли по каталогам, медицинские регистратуры и т.д. Кроме того, существует огромное количество других предприятий, фирм и организаций, производственная или торговая деятельность которых связана с необходимостью принимать и обрабатывать очень много телефонных вызовов.
При организации подобных служб прежде всего оцениваются объем трафика, который необходимо обрабатывать, тип трафика, требуемые группы операторов и количество операторов в группах, режим работы (дневной или круглосуточный) и т.п. Нельзя не учитывать также необходимость интеграции СРВ в инфраструктуру телекоммуникационной сети оператора ТфОП или частной компании. Именно из-за многообразия возможных задач разработчики СРВ быстро поняли, что удовлетворить потребности всех потенциальных пользователей таких систем средствами обычной УАТС невозможно в принципе. Чтобы дать заказчикам возможность наиболее полно адаптировать функциональные возможности системы к своим потребностям, было принято решение, которое отразилось на всем телекоммуникационном рынке, - в УАГС стали реализовывать функции СРВ, а затем и интерфейс для внешнего управления алгоритмом обработки вызова API - Application Programming Interface.
Главное преимущество, которое было достигнуто при внедрении API, - функциональная расширяемость продуктов. Внешние управляющие системы, реализованные на базе технологии компьютерной телефонии, являются чем-то вроде локальных SCR которые обеспечивают возможность модифицировать алгоритм ы управления обслуживанием вызовов силами персонала СРВ. Это позволяет оператору или администратору СРВ самостоятельно разрабатывать правила управления обработкой отдельных вызовов.
Но и это еще не все. Самостоятельно извлекая и анализируя информацию, связанную с вызовом (как правило, эта информация включает в себя номер вызывающего абонента и те данные, которые клиент сообщил системе при диалоге с IVR), и оперативно взаимодействуя с базами данных, системы компьютерной телефонии, подключаемые через API, к моменту приема собственно телефонного
вызова уже обеспечивают оператора СРВ необходимой справочной информацией, относящейся к этому вызову. Таким образом, вся информация, сопровождающая запрос клиента (номер телефона, имя, регион проживания, интересующий вопрос, номер счёта и т.п.), считывается из базы данных центра и появляется на экране рабочего места оператора (автоматически или по его команде).
Помимо того, что эта функция экономит рабочее время оператора, она повышает психологический комфорт для абонента, т.к. ему не приходится начинать общение с оператором «с нуля», сообщая о себе нужные данные.
Еще одной полезной функцией, связанной с развитием компьютерных технологий, является автоматическая генерация речевого ответа на вызов, определяемого тем, оператор какой службы (или группы) зарегистрирован на данной консоли. Эта функция избавляет оператора от необходимости многократно произносить один и тот же текст и, как следствие, повышает эффективность его работы.
С ростом вычислительных мощностей компьютеров стало возможным возложить на системы компьютерной телефонии весь процесс обработки телефонных вызовов, включая обработку сигнализации, коммутацию и т.д. Так появились системы, полностью реализованные с использованием технологий CTI. Эти системы могут сильно различаться между собой как по производительности, так и по функциональным возможностям; наиболее мощные из них сравнимы в этом смысле с центрами обработки вызовов, реализованными по «классической» схеме СРВ.
Существенной особенностью такого подхода представляется и то, что сегодня на него наиболее сильно влияют тенденции конвергенции телефонных и IP сетей. При создании корпоративной сети «с нуля» вполне уместно говорить о возможностях построения на базе современных IP-технологий единой системы, поддерживающей и сетевые функции, и прикладные функции операторского центра обслуживания вызовов. И именно этот подход, подробнее рассматриваемый в главе 8, представляется одним из наиболее перспективных.
Необычайно быстрый рост Интернет, в совокупности с появлением технологий и стандартов, обеспечивающих конвергенцию компьютерного и телекоммуникационного миров, радикально меняет всю систему связи в деловой сфере. Для любой компании, претендующей на коммерческий успех, присутствие во «всемирной паутине» является не роскошью, а жизненной необходимостью. Стремительно развивающиеся технологии позволят компаниям экономически эффективно использовать IP-технологии не только для обмена данными, совместного использования файлов и показа рекламы, но и для услуп считавшихся еще недавно прерогативой традиционной телефонии. Сегодня IP-сети могут с успехом и выгодой использоваться
для телефонной связи, факсимильной связи и конференцсвязи, а технологии пакетной коммутации являются наиболее перспективными для построения различных специализированных коммутационных систем. Эти и другие возможности могут и должны быть интегрированы в традиционный операторский центр, и именно эта тенденция сегодня является определяющей, если мы говорим о тенденциях развития СРВ и Call-центров.
Конвергенция разнообразных инфраструктур, технологий и сред становится существенным фактором сточки зрения эффективности работы операторских центров и систем «самообслуживания» потребителей (self-service customer services). Тот факт, что граница между операторскими центрами и торговлей через Web размывается, также работает на потребителей, предоставляя им больше вариантов связи и делая для них электронную торговлю более удобной, чем совершение сделок традиционными способами.
Благодаря тому, что к привычным для них возможностям связи добавляется видеоконференцсвязь, предприятия получают ещё одно средство обеспечить немедленное, оперативное и «персонализированное» обслуживание клиентов. Кроме того, Call-центры с возможностью доступа через Интернет смогут направлять вызовы от пользователей к наиболее подходящему оператору (или кавтоинформа- ционному серверу), находящемуся в любой точке сети предприятия, обеспечивая тем самым круглосуточное обслуживание абонентов. Эти и другие возможности помогают компаниям выжить в условиях конкуренции и облегчают их внедрение на новые рынки. Компании, не желающие строить и эксплуатировать свои собственные «интернетовские» операторские центры, могут получить такие услуги у крупных операторов телефонной сети общего пользования, которые могут (и уже начинают) вести себя на этом рынке более агрессивно.
Технологии 7ext-to-Speech и языкXML обеспечили великолепные перспективы развития «автоинформационной составляющей» СРВ. Если выше была рассмотрена возможность произвести телефонный вызов из Интернет к оператору центра обслуживания вызовов, то технология 7ext-to-Speech дает обратную возможность - из телефонной сети получить доступ к любой текстовой информации, которую можно найти в Интернет, и прослушать эту информацию в речевой форме.
Пользуясь услугами операторов связи и поставщиков услуг Интернет, отдельные потребители и небольшие предприятия могут получить такие возможности обработки потока вызовов, которые когда-то считались доступными только крупным телекоммуникационным компаниям. Возможности современных операторских центров, в том числе, Call-центров, интегрированных с Web-серверами, подробно рассматриваются в двух следующих главах.
Глава 7 Call-центры
Век наш таков, что он гордится машинами, умеющими думать, и побаивается людей, которые пытаются проявить туже способность.
Г. Мамфорд Джонс
От СРВ к Call-центрам
Начиная новую главу, которая, как следует из ее названия, посвящена следующей ступени эволюции операторских центров 一 Call- центрам, хотелось бы сразу оговориться, что деление материала между этой главой и предыдущей во многом условно. Все, что сказано в разделах 6.3 и 6.4 про функциональные возможности СРВ, в полной мере относится и к Call-центрам.
В то же время, не следует забывать, что этими двумя терминами обозначаются два разных понятия. Ступень распределения вызовов (СРВ или ACD) - это коммутационная система со специальными функциями (организация очередей, обслуживание вызовов с ожиданием). Call-центр (операторский центр, инфоцентр, центр обслуживания вызовов) 一 это учреждение, оснащенное оборудованием и специализированными программными средствами и укомплектованное техническим и управленческим персоналом для обслуживания интенсивного потока вызовов операторами (телефонистками, агентами). Типичный Call-центр оборудуется рассмотренной выше СРВ, подключаемой к АТС телефонной сети общего пользования или к УАТС корпоративной сети. Функция СРВ - приём вызовов определённого класса и предоставление им соединений с определенными (или с любыми свободными) операторами, т.е. с агентами, которые способны эти вызовы обслужить. При отсутствии свободных операторов вызовы ожидают обслуживания в очереди.
Развитие бизнеса и ужесточение рыночной конкуренции неизбежно вели к росту требований, предъявляемых к оборудованию, которое, более чем какое-либо другое, причастно к формированию лица компании, - т.е. к операторским центрам.
Как уже было упомянуто в предыдущей главе, основной задачей операторских центров является обслуживание мощного потока вызовов с минимальными потерями, для чего требуются специальные алгоритмы распределения вызовов и процедуры их обслуживания. С развитием в Call-центрах компьютерной составляющей и, как следствие этого, с появлением все большего количества разного рода прикладных функций появилась возможность существенно усовершенствовать процесс обработки вызова. Прежде всего, это относится к включению в состав операторских центров систем IVR, без которых сегодня немыслимо ни одно серьезное учреждение подобного вида.
Функция систем IVR - повысить качество обслуживания вызовов и обеспечить абонентам определенные удобства при ожидании обслуживания, а также избавить оператора Call-центра от рутинной работы, связанной с получением стандартной информации. Как правило, при использовании IVR алгоритмы обработки вызовов в операторском центре предусматривают передачу абонентам, ожидающим в очереди, музыкальных фрагментов или речевых фраз. Эти фразы могут содержать сведения о порядковом номере вызова в очереди и об ориентировочном времени ожидания, или просто рекламную информацию о новостях и услугах компании. Кроме того, вполне возможно, что прослушивая такие фразы, абонент получит нужную ему информацию (например, информацию о котировках акций и курсах валют) автоматически. Клиенту, ожидающему в очереди, предоставляется меню, из которого он может непосредственно перейти к интересующей его информации, не дожидаясь ответа оператора. В ряде случаев автоматизированное меню обеспечивает возможность быстрой и правильной маршрутизации вызова к определенной группе операторов или даже к определенному специалисту.
Именно с помощью IVR операторский центр чаще всего предоставляет всю рутинную информацию (часы работы предприятия, как к нему доехать и т. д.), чтобы на это не тратилось дорогостоящее время операторов. Вся подобная информация может быть заранее записана и предоставлена клиенту, пока его вызов находится в очереди. Некоторые системы позволяют клиентам сохранить своё место в очереди, пока они занимаются другими делами (например, обращаются к IVR для проверки текущего баланса), экономя время как клиента, так и оператора. Системы отправки факсов по запросу, например, позволяют получить информацию о продуктах и услугах, не обращаясь к оператору.
Важно отметить, что при проектировании операторского центра, в ходе определения конфигурации системы и проработки оптимального алгоритма обслуживания вызовов необходимо правильно определить тип клиентских запросов и особенности поведения самих клиентов. Дело в том, что применение той или иной технологии за-
висит от целей работы операторского центра. В частности, безусловно удобная, система IVR имеет две стороны. Если СРВ поддержи ваетбольшое количество служб одновременно, то использование многоуровневого речевого меню помогает быстро переадресовать клиента к любой точке системы, не занимая этим операторов. Однако использование такой системы компаниями, занимающимися, например, исследованием потребительского спроса, скорее всего, не принесет желаемых результатов, поскольку, согласно исследованиям психологов, в таких ситуациях клиенты предпочитают иметь дело не с автоинформаторами, а с живыми людьми.
Существуют дополнительные формы общения абонента с IVR. Например, в часы пик, когда все операторы заняты, абонент может оставить оператору свой запрос в речевом почтовом ящике, зная, что оператор обработает этот запрос, как только у него будет свободное время (обычно - в течение часа или двух), и свяжется с абонентом, оставившим запрос. При психологической готовности абонента к такому способу общения, подобный вариант обработки входящих вызовов существенно уменьшает среднюю длину очереди и интенсивность потоков транзакций. Важно лишь, чтобы абонент не забыл оставить номер контактного телефона, факса или адрес электронной почты.
Существенным требованием к Call-центрам является необходимость тесной интеграции (и взаимодействия в процессе обслуживания вызовов) коммутационной подсистемы с информационными базами данных компании 一 владельца операторского центра. Для обслуживания каждого вызова, будь он входящий, или исходящий, требуется доступ к данным, хранящимся в информационных базах центра и, возможно, модификация этих данных.
Глобализация мировой экономики остро поставила вопрос о том, чтобы одна компания могла предоставлять услуги в нескольких территориально разнесенных точках (городах, а то и странах). Современные Call-центры могут иметь сотни или тысячи операторов, либо находящихся в одном месте, либо размещенных в нескольких региональных центрах, либо рассредоточенных по всей стране и работающих на дому. С технической точки зрения это означает наличие сети СРВ (так называемого виртуального Call-центра), связанных между собой телефонными каналами и высокоскоростными каналами передачи данных (чтобы обеспечивалась работа с общими базами данных). При такой распределенной структуре необходимо принимать во внимание вероятность перегрузки отдельных элементов сети. Чтобы избежать связанных с этим потерь вызовов, должна быть предусмотрена возможность ремаршрутизации трафика с перегруженного операторского центра на относительно свободный для того, чтобы сохранить должный уровень качества обслуживания вызовов.
На смену работавшим в операторских центрах неквалифицированным операторам приходят квалифицированные обученные специалисты. Они могут дать абоненту медицинскую консультацию или помочь инсталлировать на его компьютер Windows 2000. Они могут производить операции с ценными бумагами, координировать работу аварийных служб и продавать билеты на спектакль или на футбол.
Исходящие вызовы
Одной из важных особенностей СаЛ-центров является возможность обработки исходящих вызовов. Необходимость в этой функции возникла с развитием услуг торговли по телефону и связанных с ними технологий телемаркетинга и телерекламы, а также с использованием операторских центров банковскими или государственными компаниями. Информировать абонента о новых продуктах или услугах, провести опрос мнения покупателей, напомнить о необходимости погасить задолженность - для всего этого необходима возможность автоматизированного обслуживания мощных потоков ис- ХОДЯ1ЦИХ вызовов.
Первоначально работа с исходящими вызовами была довольно примитивна. Оператор, имеющий в своем распоряжении магнитофон с возможностью одновременной записи и воспроизведения, несколько телефонов и список абонентов, которых нужно вызвать, набирает один из номеров в списке и говорит: «Пожалуйста, оставайтесь на линии, у меня для вас сообщение от XXX». После этого вызванный абонент прослушивает сообщение, скажем, с рекламой некой продукции, а в завершение его просят оставить свое имя и адрес. Пока абонент произносит имя и адрес, оператор может по другой линии дозвониться до другого абонента и повторить тот же процесс с начала. Набирая номер, оператор не знает; будет ли его попытка связаться с абонентом успешна. Линия может быть занята, абонента может не оказаться на месте, у него может быть включен факс и т.д. Малая эффективность такого метода вполне очевидна, однако в конце 70-х годов он был довольно популярен в США и использовался большинством компаний.
Ясно, что подобный процесс является очень трудоемким. Мало того, что оператор должен сделать как можно больше исходящих вызовов. Статистика показывает; что без применения автоматизированных систем из 100 попыток оператора, в среднем, только 30-35 заканчиваются разговором, причем даже в успешных случаях оператор тратит большую часть своего времени на ожидание ответа вызываемого абонента.
В1984 году была создана первая система, которая генерировала вызовы автоматически и подключала настоящего оператора только
после того, как было обнаружено состояние «ответ абонента». Эта система получила название упреждающий набор номера (predictive dialing). Сегодня такие системы, а точнее - пакеты специализированного программного обеспечения, реализующего эти функции,- крайне популярны. Они помогают существенно сократить время непроизводительного занятия оператора: он избавлен от самой процедуры набора номера, от потерь времени на неудачные попытки вызвать занятых или не отвечающих абонентов. Вызовы абонентов производятся по заранее создаваемым спискам, причем их могут генерировать отдельные приложения, например, на основе анализа корпоративной базы данных и 工п. Количество операторов, необходимых для достижения одной и той же производительности Call-центра, сокращается в центрах, использующих системы упреждающего набора, по сравнению с центрами, не использующими таковые, в несколько раз.
Программное обеспечение систем упреждающего набора номера является довольно сложным. Оно должно учитывать общую емкость Call-центра, число операторов, продолжительность интервалов между вызовами, обеспечивающую максимальную эффективность работы, среднюю длительность разговора с абонентом и другие факторы. К тому же, важная функция подсистемы упреждающего набора номера состоит в том, чтобы в момент, когда в системе существуют свободные операторы, установить соединение с очередным абонентом из списка, обнаружить ответ вызываемого абонента и соединить его с оператором. При этом, как и в случае обработки входящих вызовов, соединение может устанавливаться либо с определенным оператором, либо с любым свободным (с контролем равномерной загрузки операторов в системе), причем оператору передается информация о том, с кем именно установлено данное соединение, сообщается история общения с этим клиентом и т.п.
Для повышения удобства операторов стандартная фраза обращения к абоненту при исходящих вызовахтакже может генерироваться системой автоматически (до подключения к нему оператора). Как показывают данные ряда зарубежных источников, использование такого рода устройств и соответствующего программного обеспечения позволяет вдвое увеличить число абонентов, обслуживаемых одним оператором в час.
Развитие и увеличение мощности корпоративных Call-центров привело к расширению круга их задач. Одним из важнейших элементов организации бизнеса стало новое направление - ведение клиента, или, точнее, 一 менеджмент взаимоотношений с клиентами CRM (Customer Relationship Management). Удержать клиента при жесткой конкуренции на рынке товаров и услуг - задача далеко не самая простая. Продавцы знают, что регулярные контакты с клиентами позволяют быть в числе первых, когда у клиента назревает решение о по-
купке дополнительных товаров или услуг Немного внимания к клиенту 一 и вот он уже готов сделать важную покупку. Вовремя уведомить постоянного клиента о маркетинговых программах, новинках, скидках - и он, скорее всего, не пойдет искать нужный ему товар в другую фирму, а дождется, когда этот товар появится в компании, с которой он уже привык работать. Аналогичная ситуация в банковской сфере. Там нередко требуется напомнить клиентам о необходимости погашения взятых займов. Бухгалтеры знают, что лучший способ избежать просрочки в оплате счетов - это проявить активность, пока счет еще не оказался просроченным. Итак, фирме нужно разрекламировать свой товар, чтобы привлечь потенциальных покупателей, маркетологам нужно провести соответствующие исследования, банковским служащим нужно заранее напомнить о платеже... Эти и подобные им задачи и потребовали организации обслуживания Call-центрами персонифицированного, подде ржи ваемо го соответствующими базами данных потока исходящих вызовов. Списки абонентов, подлежащих оповещению, генерируются в соответствии с определенными сценариями, зависящими от назначения Call-центра и от ведущейся в нем базы клиентов. На основании материала, накопленного о том или ином клиенте, номер его телефона может автоматически включаться в списки оповещения по соответствующей тематике.
В общем случае, система действует по следующему сценарию:
определяется, естьли свободные операторы, занимающиеся исходящими вызовами;
производится обращение к базе данных с запросом номеров абонентов, которые должны быть оповещены;
запускается процесс упреждающего набора номера по нескольким каналам одновременно. При этом, однако, контролируется, чтобы число одновременно вызываемых абонентов не превышало число свободных операторов более чем на определенную величину, рассчитанную, исходя из данных о непроизводительном времени ожидания ответа, о повторных вызовах и т.п.;
как правило, подобные системы обладают рядом полезных дополнительных функций, таких как фиксация факта прослушивания фразы или преждевременного отбоя со стороны вызываемого абонента, детектирование «живого» ответа. О последней функции можно сказать несколько слов. Помимо очевидных функций распознавания сигналов факса и модема, многие системы могут определить даже наличие автоответчика. Как правило, основанием для этого служит продолжительность первой ответной фразы. Если первая фраза длинная, то это, скорее всего, автоответчик, который сообщает, что никого нет дома, и предлагает оставить сообщение. Человек же, поднимая трубку телефонного аппарата,
в большинстве случаев произносит всего одно-два слова - «алло», или «да», или «я слушаю». Некоторые системы определяют электрическое напряжение (или уровень) шума, производимого автоответчиком;
при распознавании «живого» ответа происходит подключение ответившего абонента к одному из свободных операторов.
Как видно из приведенного алгоритма, при использовании такой системы большая часть рутинной работы перекладывается на компьютерную систему. Здесь намеренно опущены те случаи, когда оповещение производится с использованием автоинформационных ресурсов Call-центра, т.к. в этом случае мы имеем дело с модификацией систем IVR, которые были достаточно подробно рассмотрены в главе 4.
Еще одним способом работы с клиентами является использование функции обратного вызова call-back. Эта функция актуальна, главным образом, при наличии повременной системы оплаты телефонных переговоров или в случаях, когда необходимо убедиться в достоверности принятой информации АОН. В такой ситуации системой автоматически фиксируется номер телефона вызывающего абонента, или абонент вводит в диалоге с системой свой контактный телефон, ему передается поясняющая фраза автоинформатора или краткий ответ оператора, после чего производится разъединение. Далее этот номер вносится в список номеров для оповещения, и работа продолжается в соответствии с алгоритмом работы операторских центров, принятым для исходящих вызовов.
Call-центры смешанного типа
Последний пример с обратным вызовом как раз характерен для операторских центров смешанного типа, обслуживающих как входящие, так и исходящие вызовы. Основная задача организации работы в таких Call-центрах состоит в том, чтобы одни и те же операторы могли и обслуживать входящие вызовы, и производить исходящие.
Достигается это следующим образом. Входящие вызовы, которые не могут быть обслужены немедленно, ставятся в очередь на ожидание. Операторы в это время могут заниматься только исходящими вызовами. Когда количество запросов в очереди достигает определённого порогового значения, оператору передается сигнал отом, что после обработки текущих запросов он должен заняться входящими вызовами. Другими словами, оператор будет заниматься входящими или исходящими вызовами в зависимости от результата анализа соответствующих очередей.
Call-центр любого типа имеет в своем составе некоторый программно-аппаратный комплекс (групповое коммутационное обору-
дование, оборудование корпоративной ЛВС) и комплекты аппаратуры для каждого рабочего места. Набор группового оборудования может быть разным в зависимости от типа Call-центра, его архитектуры и существующей телефонной структуры корпоративной сети организации или данного фрагмента телефонной сети общего пользования. Оборудование рабочего места оператора до недавнего времени было практически одинаково во всех центрах; оно включало в себя телефон с гарнитурой (просто гарнитуру) и, при необходимости, персональный компьютер с доступом к локальной вычислительной сети.
Позже появились платы, встраиваемые в компьютер, которые позволили интегрировать эти два устройства в одно. Оператор получил возможность непосредственно с клавиатуры управлять приемом вызовов, набирать номер и выполнять другие операции, что существенно повысило удобство работы. В отечественной практике этот принцип впервые был применен в СРВ 30/24, рассмотренной в предыдущей главе.
Однако и при этом сетей оставалось две - телефонная и компьютерная. Но сегодня революционное развитие IP-технологии позволяет объединить их, избавившись тем самым от сложной кабельной проводки в офисах компаний и обеспечив новый уровень интеграции телефонной и компьютерной сетей при сохранении высокого качества речевого сигнала, что, конечно же, очень важно для Call-центров. Речь идет об операторских консолях на основе технологий IP-телефонии, которые предоставляют широчайшие возможности интеграции средств доступа к информации баз данных Call-центра в клиентские программы АРМ оператора и обеспечивают (благодаря дополнительным функциональным возможностям) еще более высокий уровень удобств работы операторов. Таким Web-контакт-центрам, построенным на базе IP-технологий, посвящена следующая глава.
В состав группового оборудования рассматриваемых в данной главе Call-центров, основанных на принципах традиционной, а не IP- телефонии, как правило, входят:
коммутационная подсистема (в зависимости от архитектуры Call- центра представляющая собой либо речевой коммуникационный сервер CTI, либо УАТС, либо специализированный коммутатор);
база данных Call-центра;
рабочая станция администратора Call-центра.
Дополнительно могут предусматриваться рабочие места программистов для текущей разработки и отладки прикладных программ.
Обобщенная структура Call-центра изображена на рис.7.1. Важно отметить, что блоки, изображенные на этом рисунке, являются скорее функциональными, чем физическими, и размещение их по отдельным физическим устройствам может быть самым произвольным.
Рис. 7.1 Примерная структура Call-центра
Варианты реализации Call-центров
Рассмотрим, как реализуются упомянутые выше функциональные возможности, на примере некоторых операторских центров. Подчеркнем, что авторы не собирались приводить в этом разделе исчерпывающий анализ решений, представленных на отечественном рынке, выбрав для иллюстрации лишь несколько характерных представителей систем этого класса.
Definity
Ядром всех решений для операторского центра AVM7X Communications является УАТС типа Definity ECS. Компания AVAYA предлагает три пакета программного обеспечения, позволяющих создавать операторские центры с разными функциональными возможностями: Call Center Basic с базовым набором функций центра, Call Center Deluxe с подсистемой гибкой маршрутизации вызовов (Call Vectoring) и Call Center Elite, возможности которого расширены за счет добавления функций маршрутизации вызовов с учетом квалификации операторов (Expert Agent Selection). Каждый пакет поддерживает операторские центры разной емкости. Минимальное число операторов - 12.
Особенностью операторского центра, разработанного компанией AVAYA, является использование (в комбинации с СРВ) гибких методов маршрутизации, получивших общее название Call Vectoring (векторизация вызовов). Если СРВ ответственна только за распределение вызовов между операторам и той или иной группы, то векторизация обеспечивает гибкую маршрутизацию вызовов к разным операторским группам в соответствии с критериями, задаваемыми администратором системы. Вектор представляет собой последовательность операций при обслуживании вызова (например, подача вызывных сигналов, сигналов «Занято», воспроизведение музыки или объявлений, установка в очередь к группе операторов). Эти операции называются векторными шагами. Вектор может содержать до 32 шагов. Каждому ссылочному номеру вектора приписывается (в порядке предпочтения) до трех групп операторов, могущих обслуживать вызовы, которые поступают к этому номеру.
Для распределения нагрузки между операторами используются два основных алгоритма: выбор оператора, дольше других остававшегося свободным (Most-Idle Agent - MIA), и выбор оператора, меньше других бывшего занятым (Least Occupied Agent - LOA).
Алгоритм MIA основан на формировании списка операторов в зависимости от времени, в течение которого тот или иной оператор оставался свободным, обслужив очередной вызов. При использовании метода Uniform Call Distribution место оператора в списке определяется только временем, в течение которого он был свободен. Поступающий в группу вызов направляется к тому оператору, который оставался свободным дольше всех и потому находится в начале списка. Коща оператор заканчивает обслуживание этого вызова, он заносится в конец списка.
При использовании метода Expert Agent Distribution место в списке свободных агентов определяется не только временем, в течение которого оператор оставался свободным, но и уровнем его квалификации. Коща поступает новый вызов, он направляется к тому из агентов, бывших свободными дольше других, который обладает более высоким уровнем квалификации, требующимся для обслуживания этого вызова.
Алгоритм LOA учитывает общее время, который оператор тратит на обслуживание вызовов. Например, даже если оператор дольше всех оставался в списке свободных, суммарное время обслуживания вызовов у него могло оказаться большим, чем у его коллег Благодаря использованию алгоритма LOA в сочетании с методом Expert Agent Distribution вызовы распределяются между операторами оптимально.
Кроме того, абонент, при желании, может направить вызов непосредственно к интересующему его сотруднику. Такие вызовы обладают более высоким приоритетом, чем вызовы, поступающие к операторской группе.
Имеется возможность установить вызов в очередь сразу к нескольким группам операторов, возможность динамически ограничивать длину очереди. Вызовы, поступающие в очередь, могут обладать разными приоритетами. Запросы, имеющие более высокий приоритет, обслуживаются в первую очередь.
В зависимости от параметров, задаваемых администратором системы, вызовы могут маршрутизироваться к разным операторским группам и к разным операторам, абоненты могут слышать разную музыку или разные объявления и т.д. Предусмотрено несколько основных критериев маршрутизации вызовов (время суток и день недели, общее число операторов в группе, число свободных операторов в группе и т.д.).
Предусмотрена функция выбора квалифицированного агента (Expert Agent Selection 一 EAS). Группы в среде EAS формируются с учетом наличия у операторов определенных профессиональных навыков. Профессионализм оператора оценивается по шкале от 1 до 16, в зависимости от опыта, профиля обучения или собственных предпочтений. Уровень 1 считается наивысшим. Оператор может обладать несколькими разными навыками (например, владеть русским и английским языками), следовательно, он может входить в несколько операторских групп.
Одна из функций маршрутизации в Definity ECS, называемая выбором оптимального маршрута (Best Servise Routing - BSR), позволяет при избытке вызовов заранее, еще до установки вызова в очередь, оценить возможную длительность ожидания в нескольких операторских группах и выбрать из них ту, в которой эта длительность предполагается наименьшей, а при избытке операторов - выбрать оператора с учетом его квалификации и нагрузки.
Предусмотрена возможность вывода основной статистической информации о текущем состоянии операторского центра на дисплеи телефонных терминалов каждого оператора. Операторы могут в каждый момент видеть, сколько вызовов находится в очереди, как долго ждет самый ранний вызов и т.д.
В качестве подсистемы интерактивного речевого взаимодействия в операторских центрах AVA^k применяется сервер CONVERSANT что значительно расширяет возможности операторского центра, построенного на базе Definity ECS. Используя синтезированную или заранее записанную речь, CONVERSANT может ответить на вызов, запросить у абонента дополнительную информацию, необходимую для обработки его вызова, предоставить абоненту информацию или услугу на основе полученных от него данных.
Пакет программного обеспечения Agent Assist служит для записи и хранения аудиоинформации, необходимой для обслуживания вы-
зовов того или иного типа. Запись может производиться по расписанию или по требованию.
Пакет программного обеспечения CallBack Manager предоставляет вызывающему абоненту возможность оставить сообщение с просьбой связаться с ним, как только это будет возможно. После того как абонент оставит сообщение, CallBack Manager выбирает время, наиболее подходящее для того, чтобы доставить это сообщение оператору.
Для поддержки функций компьютерно-телефонной интеграции Call-центр на базе УПАГС Definity имеет в своем составе сервер компьютерной телефонии CentreVu Computer Telephony Server, который поддерживает взаимодействие Definity ECS с внешними приложениями. К Definity ECS сервер подключается через специальную плату, обеспечивающую связь с локальной сетью передачи данных по протоколу TCP/IR Обмен сообщениями между Definity ECS и сервером происходит по протоколу ASAI.
На сервере CentreVu Computer Telephony устанавливается программное обеспечение, поддерживающее все открытые API-стандарты (TSAPI, JTAPI, TAPI, CallVisor PC/CallVisor LAN). Это ПО поддерживает широкий набор аппаратных платформ и операционных систем для прикладных решений, созданных на основе названных API-стандартов. Клиентская часть может быть реализована на основе TSAPI (Windows, UnixWare), JTAPI или CallVisor PC/CallVisor LAN (SCO UNIXware, Solaris x86, Sparc Solaris, Windows).
Call-центр на базе Definity обеспечивает также возможность приема и обработки вызовов, поступающих от Интернет. Для этого в структуре комплекса предусматривается сервер ICM (Internet Call Manager), который, работая вместе с сервером компьютерно-телефонной интеграции, обеспечивает возможность приема речевых вызовов из всемирной паутины с использованием технологии VoIR
Для приема вызовов от сети оператор должен зарегистрироваться со своего компьютера на специальной WEB-странице, и через сервер ICM, сервер компьютерной телефонии и интерфейс ASAI эти данные попадут в коммутатор. Когда поступает вызов от Интернет (через ICM), на экране компьютера высвечивается сообщение об этом вызове и одновременно появляется информация о WEB-странице, с которой поступил вызов.
Обеспечивается также возможность обработки запросов, поступающих по электронной почте, по факсу или в режиме текстового чата.
Для эксплуатационного управления операторским центром используется специальная система (Call Management System - CMS), предусматривающая механизмы контроля и формирования отчетности. CMS представляет собой отдельный сервер, который подключается к станции Definity по протоколу TCP/IR Процессор Definity ECS
пересылает в CMS информацию о вызовах и о действиях операторов, их обслуживающих. В ответ CMS предоставляет статистическую информацию, необходимую для управления потоками вызовов, работой операторов и оборудования. Одна система CMS может обслуживать до 8 УПАГС. Предусмотрена возможность генерации отчетов о состоянии системы в реальном времени, хронологических отчетов, интегрированных отчетов, а также отчетов-прогнозов и отчетов о недопустимых событиях.
ПринтерПринтерsoso网回回。网回回。Система начисленияплатыСистема начисленияплатыТелефон КомпьютерТелефон КомпьютерОператор 1Оператор 1Системный принтерСистемный принтерIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIII IIIIIII^3S3^3S3IIIIIIIIIIIIIIСРВ DefinityСРВ DefinityопопОператор NОператор NТелефон КомпьютерТелефон Компьютер冒1г I冒1г IВВСистема INTUI7YСистема INTUI7YСетевой серверСетевой серверS3 изS3 изВВСистема CONVERSANT-1Система CONVERSANT-1ODDODDJS!JS!База данныхБаза данных
Принтер
Принтер
so
so
网回回。
网回回。
Система начисленияплаты
Система начисленияплаты
Телефон Компьютер
Телефон Компьютер
Оператор 1
Оператор 1
Системный принтер
Системный принтер
IIIIIII
IIIIIII
IIIIIII IIIIIII
IIIIIII IIIIIII
^3
S3
^3
S3
IIIIIII
IIIIIII
СРВ Definity
СРВ Definity
оп
оп
Оператор N
Оператор N
Телефон Компьютер
Телефон Компьютер
冒1г I
冒1г I
В
В
Система INTUI7Y
Система INTUI7Y
Сетевой сервер
Сетевой сервер
S3 из
S3 из
В
В
Система CONVERSANT-1
Система CONVERSANT-1
ODD
ODD
JS!
JS!
База данных
База данных
Сетевой принтерСетевой принтер
Сетевой принтер
Сетевой принтер
CMS
Модем III
Базовая системаэксплуатационногоуправления
Рис. 7.2 Архитектура Call-центра AV/WK
Таким образом, основными элементами архитектуры Call-центра AVZVvA являются:
цифровая коммутационная платформа Definity - платформа, реализующая основные функции СРВ;
система начисления платы - компьютер со специальным программным обеспечением. Позволяет обрабатывать, сортировать, архивировать информацию о совершенных вызовах, полученную со станции. Позволяет формировать различные отчеты о совершенных вызовах;
системный принтер - принтер, подключенный к станции и позволяющий распечатывать различные отчеты, формируемые станцией;
система INTUITY - компьютер для обработки перенаправленных (не получивших ответа) вызовов. Позволяет иметь унифицированный почтовый ящик, который может хранить речевые сообщения, факсы и электронные сообщения;
сетевой сервер - компьютер-сервер для организации сети, связывающей между собой все компьютеры, принтеры и другие периферийные устройства и подключенный к станции через сетевой интерфейс. Сервер обрабатывает информацию, полученную со станции, и делает ее доступной для компьютеров операторов, а также служит для управления работой операторских консолей;
система CONVERSANT;
система CMS эксплуатационного управления Call-центром - специальный компьютер, позволяющий перемещать операторов из одной группы в другую, вводить в работу и выводить из работы дополнительные группы операторов, формировать большое количество разнообразных отчетов о работе центра. Система архивации компьютера хранит отчеты и другую информацию, связанную с работой центра, за последние несколько лет;
базовая система эксплуатационного управления Call-центром - интегрированная функция станции, являющаяся упрощенным вариантом CMS. Базовая система управляется через терминал технического обслуживания. Возможно использование дополнительного компьютера со специальным программным обеспечением, подключенного к станции через модем (модуль передачи данных);
база данных - компьютер с установленной базой данных, используемой операторами в процессе обработки вызовов;
рабочее место оператора с телефоном, задействованным в Call- центре, и компьютером, подключенным через сеть к серверу, что позволяет получать информацию, связанную с поступившим вызовом.
Основной составляющей Call-центра является цифровая коммутационная платформа Definity версии 6 и 7 (далее - Definity R6, R7) с активизированными программно-аппаратными опциями ACD, CMS/BCMS, Call Vectoring и др.
Интеграция функций передачи речи и данных, реализуемая в ЦСИО, позволяет Definity:
иметь постоянно высокое качество передачи речи;
подключать 2 терминальных устройства к одной абонентской линии базового доступа;
осуществлять идентификацию вызывающего абонента (фамилия и номер внутреннего абонента, номер абонента ISDN);
организовывать многофункциональные рабочие места с двумя информационными В-каналами на основе одной абонентской линии базового доступа;
использовать терминальные адаптеры для передачи данных с использованием интерфейсов V.24, Х.25 и Х.21;
использовать существующие кабельные сети.
Call-центр NEAX 2400/7400
Call-центр NEAX 2400/7400 имеет блочную конструкцию которая позволяет базовой 64 портовой системе связи, быть расширенной посредством дополнительных 64 портовых модулей (PIM) до максимально возможной емкости в512 портов.
Система имеет полностью не блокируемую архитектуру и 32-раз- рядный процессор, которые обеспечивают необходимую гибкость и производительность. В системе предусматривается:
минимизация расходов на связь - возможность распознавать и использовать самые дешевые каналы связи (из имеющихся);
поддержка ISDN - как Primary так и Basic Rate ISDN интерфейсов
автоматическое распределение вызовов;
цифровая консоль оператора (Operator's Console);
речевое приветствие;一
цифровые и аналоговые телефонные аппараты;
автоматическая входящая связь к абонентам УАТС (direct in dialling);
переадресация входящих вызовов (в том числе и на внешние цифровые линии);
встроенная поддержка составления отчетов о вызовах;
отдельный сервис для групп пользователей;
интеграция с компьютерной телефонией;
передача данных;
специальные возможности для гостиниц и больниц (поликлиник).
HSWI/OBUSHSWI/OBUSРис. 7.3 Блок-схема Call-центра NEAXРис. 7.3 Блок-схема Call-центра NEAX
HSWI/OBUS
HSWI/OBUS
Рис. 7.3 Блок-схема Call-центра NEAX
Рис. 7.3 Блок-схема Call-центра NEAX
Call-центр ПРОТЕЙ
С начала 90-х годов в сетях России успешно эксплуатируются уже два поколения систем для оснащения Call-центров: рассмотренная в предыдущей главе ступень распределения вызовов СРВ 30x24 и 8- ответствующий тематике этой и следующей плав Call-центр ПРО- ТЕЙ-РВ. Эти две системы имеют совершенно разную архитектуру и разные функциональные возможности, однако обе они позволяют успешно решать задачи оснащения операторских служб и организации Call-центров.
Ступень распределения вызовов СРВ 30x24 аппаратно реализована на базе абонентского модуля АГСЦ-90, подключается к ТфОП по тракту ИКМ-30 и имеет емкость до 24 рабочих мест операторов.
Как отмечалось выше в данной главе, современный Call-центр должен обладать гораздо большим набором функций, чем традиционная СРВ, маршрутизирующая входящие вызовы к первому освободившемуся оператору. Более того, в эпоху конвергенции различных сетей связи явно недостаточно принимать и обрабатывать вызовы, поступающие только от ТфОП. Сегодня операторский центр должен уметь обрабатывать вызовы любого типа, включая электронные письма и SMS-сообщения, поддерживать режим текстового чата и вызовы с использованием технологии VoIR Учитывая применение в современных центрах универсальных механизмов обработки трафика, производители оборудования и потребители таких систем постепенно переходят от термина Call-центр к другому, более полно отражающему их функциональные возможности термину Контакт- центр.
Контакт-центр ПРОТЕЙ-РВ реализован на базе интеллектуальной платформы ПРОТЕЙ, учитывающей тенденции конвергенции телекоммуникационных сетей и обладающей всеми функциями, необходимыми для организации современного контакт-центра. Система имеет распределенную архитектуру, позволяющую гибко наращивать ее емкость (как в части интерфейсов с ТфОП, так и в части количества рабочих мест операторов) и функциональные возможности комплекса. Обеспечивается прием вызовов как от ТфОП, так и от Интернет с использованием технологии IP-телефонии. Впрочем, мы уже забегаем вперед, т.к. эти аспекты, связанные с конвергенцией сетей, подробнее будут рассмотрены в следующей главе.
В контексте рассматриваемых в данной главе функций Call-центров к возможностям операторского центра ПРОТЕЙ РВ относятся следующие.
Обеспечивается поддержка в одной системе нескольких групп операторов (функциональных секторов) с отдельной очередью к ка- >вдоВ группе или с общим буфером ожидания.
Подсистема маршрутизации ПРОТЕЙ РВ обеспечивает возможность обслуживать входящие вызовы в ответном или предответном состояниях, направлять вызовы в ту или иную группу (с установкой в очередь при отсутствии свободных операторов) в зависимости от ряда параметров, задаваемых адм и н истрато ро м системы (набранный номер, номер вызывающего абонента, информация, введенная в процессе диалога с IVR, время суток и день недели, допустимая длина очереди к группе операторов, число вызовов, ожидающих в очереди к данной группе операторов, оценка длительности ожидания обслуживания данной операторской группой и т.д.).
Комбинируя эти параметры, можно создавать гибкие алгоритмы обслуживания вызовов. Например, вызовы от привилегированных абонентов можно обслуживать вне очереди. Можно назначать так называемые резервные группы операторов, к которым вызовы будут направляться только в том случае, если их невозможно установить в очередь к основной операторской группе.
Во время ожидания обслуживания предусмотрена передача абонентам фраз автоинформатора, содержание которых может зависеть от длины очереди, от того, в очереди к какой группе операторов находится вызов, и от вызываемой абонентом службы. Абоненту могут быть сообщены порядковый номер его вызова в очереди и ориентировочная длительность ожидания.
В ПРОТЕЙ-РВ интегрирована система IVR, которая позволяет во время ожидания не только обеспечивать абонента необходимой информацией и подсказками, но и строить многоэтапные диалоги, поддерживая меню произвольной структуры с навигацией путем многочастотного донабора. В ходе таких диалогов клиент может легко получить интересующую его рутинную информацию, причем на выдачу такой информации не будет тратиться рабочее время операторов Call-центра. При диалоге с IVR клиент может ввести определенную информацию, которая далее будет выведена на дисплей рабочего места оператора, что позволит последнему уже в момент приема вызова иметь нужные сведения о клиенте. Кроме того, вызовы могут переадресовываться к IVR в определенные часы суток и дни недели, что позволяет выдавать клиенту базовый набор информации даже тогда, когда операторы службы не работают (например, в ночные часы).
Таким образом, после того как абонент набрал номер нужной ему службы, вызов направляется на сервер распределения вызовов, который действует по одному из следующих сценариев:
при наличии свободных операторов в группе вызов направляется непосредственно к рабочему месту оператора с использованием установленного для этой службы алгоритма распределения;
при отсутствии свободных операторов вызов ставится в очередь;
вызов может быть направлен к системе IVR, последиалога с которой он адресуется (при необходимости) прямо к рабочему месту оператора (если контакт-центр оснащен соответствующими про- граммно-аппаратн ыми опциями);
вызов направляется к системе IVR, после диалога с которой он устанавливается в нужную очередь, если в соответствующей группе (службе) нет свободных операторов.
Подсистема распределения вызовов платных служб может обеспечивать проверку номера или категории телефона на предмет разрешения доступа к службе. Если номер телефона обнаружен в «черном списке», предоставление абоненту услуги может быть запрещено.
Для оптимального распределения нагрузки между операторами возможно использование одного из трех основных алгоритмов:
циклическое распределение вызовов, когда вызов из очереди направляется к первому попавшемуся из свободных операторов;
М1А, т.е. выбор оператора, который дольше других оставался свободным (после обслуживания последнего вызова);
LOA, те. выбор оператора, который меньше других был занят (с начала смены).
Реализованы две модификации алгоритма LOA, различающиеся критериями выбора оператора: в первой модификации критерием служит суммарное время разговоров оператора, а во второй - общее количество вызовов, обслуженных оператором. Возможны модификации всех трех алгоритмов, учитывающие коэффициент квалификации оператора.
В Протей-РВ предусмотрена подсистема упреждающего набора номера (predictive dialing). Функции этой подсистемы требуются, когда в процессе работы системы создаются исходящие соединения (например, для обслуживания абонентов в режиме с обратным вызовом). В этом случае, в зависимости от назначения центра, либо сама система генерирует список оповещения абонентов, либо этот список формируется силами персонала. Система автоматически производит вызовы по сформированным спискам оповещения, определяет состояние линии вызываемого абонента (занято; отсутствие ответа; факс; «живой» ответ). При обнаружении «живого» ответа к обслуживанию вызова подключается свободный оператор (возможно, с предварительной передачей абоненту нужной фразы автоинформатора). Обеспечивается возможность приема вызовов электронной почты, или вызовов от Интернет с использованием технологии VoIP.
Каждый оператор и дентифи ци руется в системе уникальным номером (именем) и имеет свой пароль. Личный номер оператора может «произноситься» системой автоматически. Поддерживается разделение операторов на обычных и старших; те и другие обладают разными правами доступа. Старший оператор (бригадир) имеетвоз- можность контролировать работу обычных операторов в группе (подключаясь в режиме скрытого прослушивания, а также анализируя статистическую и оперативную информацию).
Оператору контакт-центра предоставляются следующие возможности:
регистрация в любой группе на любом рабочем месте под уникальным паролем;
прием входящих вызовов от ТфОП и от сети Интернет;
организация исходящих соединений;
удержание соединения;
наведение справки (соединение с третьим участником);
переадресация вызова к другой группе (службе) или к старшему оператору;
кратковременный выход из режима обслуживания вызовов (блокировка консоли);
принудительное разъединение;
обращение к базе данных контакт-центра в процессе обслуживания вызова;
запись разговора с абонентом (в особых случаях).
При приеме входящего вызова оператором на его рабочем месте (на экране PC) отображается информация о вызывающем абоненте. Дорогостоящее время qnepayopa не тратится на выяснение личности абонента и (если это предусмотрено настройкой системы) цели его вызова.
Оповещение оператора о вызове может производиться путем ви - зуальной индикации на рабочем месте и/или тональным сигналом, передаваемым в наушники гарнитуры.
В ПРОТЕЙ-РВ предусмотрена функция переадресации при не- ответе оператора. Эта функция позволяет обслужить вызов, поступивший на пульт оператора, который по какой-то причине не может на него ответить (например, он покинул рабочее место, не оповестив об этом систему, и та продолжает считать его готовым к приему вызовов). Поскольку каждый такой случай ухудшает качество обслуживания клиентов, его последствия должны быть устраняемы. Если оператор не ответил на вызов в течение заданного интервала времени (устанавливаемого системным администратором), вызов пе-
реадресуется к другому оператору той же группы. Чтобы такая ситуация не повторилась снова, рабочее место отсутствующего оператора автоматически переводится в нерабочий режим, который сохраняется до тех пор, пока оператор, вернувшись, не переведет свою консоль в режим готовности. Предусмотрена возможность оповещения старшего оператора о каждом случае неответа оператора. Помимо оповещения в реальном времени, система формирует хронологические отчеты с указанием времени и имени оператора, не ответившего на вызов.
В системе предусмотрено формирование и хранение обширной статистической и эксплуатационной информации. Отчеты, создаваемые на основе этой информации, поступают на рабочее место администратора системы. Для каждого обработанного системой вызова фиксируется несколько ключевых параметров: тип вызова (исходя щий/входящий/внутренний), время обнаружения вызова, длительность ожидания, продолжительность обслуживания, номер оператора, обслужившего вызов, этап, на котором вызов был потерян (если это случилось). Предусмотрена выдача в реальном времени отчетов о состоянии рабочих мест Call-центра и о состоянии очередей к каждой группе операторов. Кроме того, администратор может запросить и получить в реальном времени информацию о длительности ожидания вызовов в очереди, о средней продолжительности разговора и т.д.
Система позволяет генерировать хронологические отчеты обо всех важных параметрах, характеризующих качество обслуживания вызовов и эффективность работы операторского центра (количество обслуженных/потерянных вызовов, количество вызовов, покинувших очередь до и после того, как был достигнут установленный порог длительности ожидания, суммарное время, затраченное на обслуживание вызовов оператором или группой операторов и т.д.).
7.4.4 Решение Nortel Networks
Операторские центры Simposium, пре/хлагаемые компанией Nortel Networks, используют в качестве коммутационного ядра УАТС типа Meridian-1, к которой по локальной вычислительной сети подключается сервер, реализующий прикладные функции СРВ и другие специфические функции Call-центра.
Call-центр поддерживает гибкую систему распределения вызовов по многим критериям. Благодаря функции дифференцированной маршрутизации, поддерживаемой сервером Symposium Call Center Server, система может распределять вызовы между агентами в соответствии с их знаниями и специализацией, направляя каждый вызов к тому агенту, который в состоянии лучше обслужить клиента.
Группы специализации агентов могут задаваться, исходя из тех критериев бизнеса, которые важны в конкретном операторском цен-
тре; этим группам могут присваиваться разные приоритеты, чтобы, например, первыми вызовы принимали более опытные агенты.
Вызовы клиентов могут маршрутизироваться к тем или иным группам специализации в зависимости оттого, кем является тот или иной клиент, откуда он звонит, какой номер он набрал, когда он позвонил, на чем он остановился, когда ему был предложен выбор, или каково было состояние Call-центра в момент, когда к нему поступил вызов (длины очередей к разным группам, день недели и время суток и т.д.).
Управление группами специализации агентов упрощается благодаря матрице распределения групп специализации (Symposium Call CenterXs Skillset Assignment Matrix) - интерфейсу на базе Windows, который позволяет с помощью стандартного графического пользовательского интерфейса вносить в распределение групп специализации изменения, соответствующие тому, как изменяются условия работы центра.
Внутри каждой группы специализации агентов сервер распределения вызовов операторского центра Symposium может направлять вызовы к агентам, дольше других находящимся в режиме ожидания или имеющим самый продолжительный совокупный период ожидания, что позволяет повышать производительность работы центра и распределять нагрузку более равномерно.
Сервер Symposium Call Center может также устанавливать вызовы в очередь к определенным агентам, а не переадресовывать их тем, кто в данный момент свободен. Таким образом, клиент может быть направлен к тому агенту, с которым он уже имел дело.
Продукты Symposium Call Center поддерживают стандартные интерфейсы CTI, используемые в корпоративных информационных системах, таких как Microsoft, Novell, IBM, HP, Sun, Dialogic и Tandem. Благодаря информации, получаемой из корпоративной базы данных при приеме вызова, агент заранее знает о прошлых транзакциях клиента, о предпочитаемых им продуктах и даже о его личных вкусах и пристрастиях. Поскольку искать всю эту информацию вручную не требуется, агент может экономить по 45 секунд при обслуживании каждого вызова. Именно об этом упоминалось в параграфе 7.2 там, где шла речь о принципе ведения клиентов CRM.
В составе операторского центра реализована интегрированная подсистема IVR, которую компания-разработчик называет интерактивной речевой системой автоматизированного предоставления справок по часто задаваемым вопросам, что, в общем, вполне точно отражает ее основное назначение.
Система Symposium IVR воспроизводит записанные речевые команды-подсказки, предлагая вызвавшему абоненту произнести нужную фразу или нажать нужную кнопку многочастотной тастатуры.
Благодаря поддержке современных мультимедийных функций, таких как распознавание речи на разных языках, Web-интеграция, преобразование текста в речь и интерактивный режим факсимильной связи (Interactive Fax Response), IVR открывает еще более широкие возможности высококачественного обслуживания клиентов.
Использование системы Symposium IVR для автоматизации рутинных транзакций и выдачи справок, а также для обеспечения должного обслуживания клиентов при минимальных издержках, помогает компании-оператору Call-центра лучше управлять трафиком и экономически эффективно повышать качество обслуживания.
Благодаря системе Symposium Remote Agent, агенты Call-центра могут работать, находясь вне своих рабочих мест, с той же производительностью и стой же концентрацией внимания на обслуживании клиента, что и при работе непосредственно в центре приема и обработки вызовов. Remote Agent позволяет агентам принимать вызовы и просматривать информацию, выводимую на экран монитора, так же, как если бы они находились в центре. Система контроля и управления деятельностью агентов является полностью интегрированной, так что супервизор может наблюдать за действиями удаленных агентов при помощи своего персонального компьютера.
Symposium дает агентам возможность получать от клиентов заявки, переданные в электронном формате через Интернет, так же, как они принимают обычные запросы, проходящие через систему автоматического распределения вызовов. Такая заявка может быть направлена к наиболее квалифицированному агенту или к IVR, и потому клиент имеет возможность выбора между получением информации в автоматическом режиме или путем общения с агентом. Подобная интеграция значительно повышает производительность центра обработки вызовов, давая агентам возможность обрабатывать заявки, переданные через Интернет, в периоды, когда появляются «окна» в обычном телефонном трафике.
Сервер Symposium Web-Response позволяет обрабатывать заявки, поступающие из всемирной паутины, так же быстро и легко, как и привычные для центра обработки вызовов телефонные запросы. Этот сервер дает возможность обрабатывать сообщения электронной почты, используя те же рабочие процессы и тех же агентов, что и при обработке вызовов, поступающих через СРВ. Агенты операторского центра могут использовать интервалы в телефонном трафике для обработки сообщений электронной почты, что тоже повышает эффективность работы центра.
Для интеграции с корпоративными информационными базами данных преду сматри вается специальное автоматизированное приложение Symposium Agent. Используя этот продукт, агент центра обработки вызовов получает возможность устанавливать правила и соз-
давать инструменты, необходимые для повышения производительности труда за счет автоматизированного доступа к информации разных баз данных и адаптации пользовательского интерфейса к конкретным нуждам.
Для доступа из внешних приложений к базе данных центра обработки вызовов используются стандартные открытые интерфейсы SQL и ODBC.
Подсистема обработки статистической информации и информации учета вызовов обеспечивает возможность интегрировать данные, накапливаемые в базе данных Call-центра, со статистикой других отделов компании. Например, приложение может получить из базы данных сервера Call-центра сведения о нагрузке, а из корпоративной базы данных - сведения о доходах, а затем автоматически составить отчет о доходе, приходящемся на один вызов.
Стандартные отчеты, генерируемые сервером центра обработки вызовов Symposium, могут содержать информацию о загруженности центра, колебаниях трафика, производительности труда агентов, характеристиках качества их работы, использовании ресурсов центра и производительности сети. Отчеты сервера Symposium Call Center Server могут составляться стандартными генераторами отчетов, что дает пользователю значительную свободу выбора форматов.
Как видно из приведенных описаний, базовые возможности современных Call-центров во многом схожи. Они включают в себя мощную систему маршрутизации вызовов, разнообразные алгоритмы распределения вызовов по операторам и организации очередей, статистические подсистемы, позволяющие получать исчерпывающую информацию о процессе обслуживания потоков вызовов операторским центром в целом и о работе отдельных агентов. Необходимой составляющей любого операторского центра является гибкая подсистема IVR. Сегодняшние реалии диктуют требования, связанные, прежде всего, с расширением возможностей доступа к Call- центрам, с более тесной интеграцией центра с информационными базами данных компании-оператора, а также с внедрением все более эффективных решений, позволяющих оптимизировать программно-аппаратные комплексы, о чем подробнее мы поговорим в следующей главе.
Аутсорсинг при организации Call-центров
Вернемся к проблематике корпоративных Call-цетров. Усложнение механизмов ведения бизнеса и уже многократно упомянутое усиление конкуренции привели к тому, что для успешного бизнеса стало необходимо не только квалифицированно «вести дела» в основной области, но и столь же квалифицированно заниматься «сопутствую-
щей» деятельностью. В частности, речь идет об организации взаимоотношений с клиентами. Для небольших компаний нередко оказывается неподъемной задача организовать обслуживание потоков вызовов столь же успешно, как это делают крупные корпорации, инвестировавшие огромные суммы в организацию Call-центров и обучение персонала. В то же время, многие операторские (и иные) компании, уже имеющие собственные мощные Call-центры, хотели бы использовать их более эффективно, т.к. их собственный трафик оставляет незадействованной часть ресурсов программно-аппаратного комплекса. Или, например, компания собирается внедрять новую технологию в своем операторском центре (на Западе, скажем, сегодня в моде эксперименты с технологией распознавания речи), но не уверена, стоитли приобретать оборудование или выгоднее арендовать услуги у сторонней фирмы. Так возник спрос на качественно новые услуги в области эксплуатации телекоммуникационного оборудования -услуги аутсорсинга, 一 и одновременно появилось их предложение.
Аутсорсинг (outsourcing) - это передача на контрактной основе некоторых функций, обычно - функций, выполняемых операторскими службами, - стороннему лицу или компании. Фирма прибегает к аутсорсингу, когда она приходит к выводу, что таким образом данная функция будет обеспечиваться и обслуживаться дешевле, быстрее и с меньшими трудностями, чем если делать это собственными силами. При этом фирма, пользующаяся услугой аутсорсинга, может сосредоточить силы и ресурсы на выполнении своих основных задач и функций, т.е. того, ради чего фирма и была создана. Этот процесс называется «концентрацией на главных сферах компетенции».
Поскольку такие услуги являются новыми и в России практически не распространены, просим прощения у читателей за обилие в этой главе примеров из зарубежной практики. Как показывает опыт американских и европейских компаний, коммерческие фирмы передают сторонним организациям целый ряд функций, несвязанных с основной деятельностью этих фирм. Это могут быть такие функции, как обработка статистических данных, приём и обработка почты, уборка помещений, служба безопасности, и, наконец (что непосредственно касается тематики главы), 一 функции, связанные с обработкой поступающих от телекоммуникационных сетей вызовов и заявок, включая обработку электронной почты и сообщений Интернет. Например, журналы Call Center, Computer Telephony и TELECONNECT передали работу с клиентами и организацию подписки на журналы компании Sunbelt Fulfillment, а взимание платы за размещение в журналах рекламных и иных материалов - компании Rubin Response. «Мы полагаем, что наши (журналистов и редакторов) основные функции - писать и редактировать журналы и книги, организовывать конференции и торговые выставки, а не отвечать
на вопросы по поводу потерянных номеров журнала, доставки журналов и цен. Эти функции лучше всего возложить на специалистов, компетентных в данных областях, ибо они справятся с такой работой гораздо лучше, чем мы своими собственными силами», - говорят менеджеры компании-издателя.
В операторских центрах применяется аутсорсинг трех основных типов.
Оо「анмзаима бюао обслуживания (Service Bureaus) - наиболее привычный тип предоставления в пользование ресурсов Call-центра, когда обслуживание потоков вызовов и обработка электронной корреспонденции компании-арендатора ведется агентами и автоинфор- мационными службами компании-владельца центра. Бюро обслуживания выполняютширокий спектр функций, включая работу с клиентами в режимах входящей и исходящей связи, продажу, выработку указаний и директив, плановый учёт. Эти функции выполняются с использованием телефонной связи и, всё более и более, электронной почты, Интернет, включая обратный вызов из WWW (Web-call-back), групповую работу и диалог (chat), и IP-телефонии. Многие бюро предлагают автоматизированную обработку электронной почты, услуги IVR и самообслуживание в Web. Некоторые из них могут поддерживать и видеосвязь - всё зависит от нужд и условий заказчика. Бюро обслуживания могут также предоставлять многие вспомогательные услуги, такие как маркетинговый анализ баз данных заказчика, обеспечение доступа к хранилищам данных (data warehousing) и другие услуги обработки данных. Часть таких бюро в настоящее время концентрируется на главных сферах своей компетенции и предлагает ряд услуг аутсорсинга в партнёрстве с другими фирмами, улучшая тем самым удобства, получаемые их клиентами при обслуживании. Например, Centrobe, подразделение крупной фирмы в сфере обработки данных EDS, имеет партнёрские отношения с Call Interactive - поставщиком услуг IVR.
Хостмн「прмложенм^ (Auulications Hosting) - менее традиционный вариант взаимодействия поставщика и потребителя услуг аутсорсинга. В этом случае поставщик, который владеет какими-либо ключевыми средствами, используемыми в процессе обслуживания вызовов и реализованными на базе некоего программно-аппаратного комплекса (сервера приложений - Application Host), сдает в аренду эти средства, управляет ими и модернизирует их. Это может быть, например, сервер IVR (с функцией распознавания речи или без нее), сервер электронной почты с расширенным набором функций, Центрекс.
Прадоставленме ресурсов Call-центра в пользование стооонне济 компании, которая обслуживает силами нанятых ею агентов потоки вызовов, созданных клиентами владельца операторского центра.
Эта компания платит агентам зарплату, а плату за предоставляемые ею услуги получает от владельца центра. Таким способом может быть организован, например, справочный стол какой-нибудь крупной компании. По мнению зарубежных аналитиков, преимущество подобной схемы состоит в том, что владелец Call-центра имеет возможность лучше контролировать качество обслуживания вызовов ЕГО клиентов ЧУЖИМИ агентами, потому что все действия совершаются в его помещениях. Недостатком является то, что владелец Call-центра несёт в этом случае все расходы на оборудование, в отличие от первой схемы, когда оборудование может принадлежать сторонней компании.
Аутсорсинг; реализуемый любым из трех описанных выше способов, дает компаниям, прибегающим к его услугам, ряд существенных преимуществ перед компаниями, организующими Call-центр собственными силами. Прежде всего, в ряде случаев обеспечивается существенно большая гибкость в управлении эффективностью использования ресурсов центра и его производительностью. Так, без дополнительных инвестиций в оборудование могут обслуживаться огромные потоки вызовов в периоды пиковых нагрузок (например, в США - это покупки в канун Рождества). Проще организовать работу агентов при предоставлении услуг в течение ограниченного периода времени. Существенно проще организовать операторскую службу при предоставлении, скажем, услуг связи по предоплаченным картам (СТК), не организуя свой операторский центр, а именно прибегнув к услугам аутсорсинга. Бюро могут нанимать агентов на неполный и полный рабочий день (и увольнять их) намного быстрее и с меньшей головной болью, чем отдел кадров крупной компании.
По этим причинам к услугам бюро традиционно прибегали для проведения маркетинговых акций, связанных с продажей по телефону. К услугам аутсорсинговых компаний фирмы могут прибегать для выполнения работы не основного профиля (например, продажи аксессуаров для основной продукции). Как пишут зарубежные аналитики, такая работа требует агентов и контролёров иной, чем в основной службе, квалификации и, следовательно, легче всего может быть возложена на сторонние фирмы. Приведем цитату из аналитического обзора компании Datamonitor: «Люди, умеющие виртуозно уговорить клиента купить какие-нибудь украшения на кузов автомобиля или выбить деньги из клиента, который на 20 минут просрочил платёж по счетам, часто оказываются не теми, кто может потратить пять минут, помогая клиенту выяснить, какие цветы или садовые скульптурки будут лучше сочетаться с гипсовой Мадонной перед его домом, и не теми, у кого хватает терпения помочь клиенту так очертить свою проблему, чтобы он смог решить ее самостоятельно, обратившись к соответствующему руководству. Агенты, обслуживающие входящие вызовы, являются лицом вашей компании и должны
всегда быть вежливыми и готовыми помочь, вне зависимости от степени идиотизма запроса, жалобы или самого клиента».
Еще одним преимуществом аутсорсинга является снижение затрат на подбор и обучение персонала. Организаторы бюро обслуживания могут сделать так, что одни и те же агенты будут выполнять работу для нескольких клиентов, или могут предусмотреть выделенных агентов, что заказчику обойдётся дороже, но при этом, возможно, качество обслуживания будет выше. Компания, предоставляющая услуги Call-центра на правах аутсорсинга, может оперативно начать предоставление услуг или свернуть свою деятельность, в зависимости от конкурентной ситуации на рынке. Заключение контракта с поставщиком услуг аутсорсинга является самым лучшим способом изучить реалии рынков в неизведанных регионах или странах до организации в таком регионе/стране полномасштабного Call-центра.
Поскольку, как уже упоминалось, услуги аутсорсинга являются для России, в общем-то, новыми, приведем любопытную информацию, хотя и не имеющую непосредственного отношения к тематике книги, но, безусловно, небесполезную с точки зрения внедрения операторских центров в сегодняшних российских телекоммуникационных сетях. Речь идет о механизме оплаты услуг аутсорсинга. Как правило, бюро обслуживания берут за свои услуги почасовую плату (не зависящую от обрабатываемой нагрузки) плюс плату за подключение. Обычно правило таково: чем меньше часов обслуживания покупает компания, тем выше почасовая плата. Небольшие бюро в США могут вести бизнес из расчёта продажи сотен часов ежемесячно в течение нескольких месяцев, тогда как крупная фирма согласится работать только при условии, что приобретаться будет полторы тысячи часов ежемесячно в течение года. Однако некоторые фирмы предлагают такую схему оплаты услуг; когда арендная плата определяется обработанным трафиком, а обязательное количество оплаченных часов сводится к минимуму.
Как показывают наблюдения зарубежных специалистов, крупным компаниям с большим штатом выгодна первая схема аренды, а мелким фирмам - вторая (в силу необходимости рационально использовать время немногочисленных операторов).
У аутсорсинга, тем не менее, имеются некоторые недостатки. Главными из них являются частичная утрата контроля над агентами и над информацией о клиентах. Контакты с клиентами тоже в какой- то степени слабеют, хотя, строго говоря, ценность таких контактов зависит оттого, насколько взаимоотношения с клиентами важны для бизнеса. Некоторые действия, такие как маркетинговые акции, связанные с большим числом исходящих вызовов, производя которые, компания убеждает вызванных потребителей что-то купить, меньше зависят от взаимоотношений с клиентом, чем обслуживание входя-
щих вызовов, когда вызывающий клиент чего-то хочет от компании. Поданным, публикуемым зарубежными консалтинговыми фирмами, можно сделать вывод, что компании, которые стремятся победить на конкурентном рынке, создавая не обезличенные взаимоотношения со своими клиентами, не должны передавать функции Call-центра сторонним организациям. Кроме того, текучесть рабочей силы у поставщика услуг аутсорсинга, как правило, выше, чем в собственном Call-центре, что увеличивает расходы на обучение персонала, ведет к более высокому проценту ошибок и более низкому качеству обслуживания, уменьшает вероятность того, что вы заподозрите что- то неладное прежде, чем потеряете много клиентов.
Пользование услугами аутсорсинга может оказаться более дорогим, чем создание и эксплуатация собственного центра, если речь идёт о долгосрочных программах, поскольку часть доходов от бизнеса компании идёт поставщику этих услуг. По оценкам консультантов, затраты на организацию собственного операторского центра на американском рынке окупаются примерно через три года. Следовательно, если проект рассчитан на более длительный срок, есть смысл открыть свой операторский центр. В России, в силу известной сложности долгосрочного планирования, это соображение может вызвать лишь грустную улыбку руководителей компаний среднего бизнеса. Однако оно же должно вселять оптимизм в руководителей тех телекоммуникационных компаний, для которых предоставление услуг аутсорсинга на базе собственных мощных операторских центров может стать неплохим источником дохода, да и сами центры при этом на 70% могут работать на собственные нужды этих компаний.
«Аутсорсинг имеет смысл тогда, когда бизнес-приложение относительно просто и не требует длительного обучения персонала, знания продукта или навыков продажи, и когда надо организовать операторский центр чрезвычайно быстро и с минимальными капиталовложениями», -отмечает РобертЭнгель, ведущий специалист Engel Picasso, консалтинговой фирмы в области выбора мест размещения операторских центров. - «Создание собственного операторского центра имеет наибольший смысл тогда, когда продукт или услуга является фирменной, когда нужна обширная, требующая больших расходов программа обучения агентов, и когда стратегия развития вашего бизнеса предполагает сильную культурную интеграцию и создание сплочённого, преданного компании коллектива».
Многофункциональный центр обслуживания вызовов
Из-за весьма ограниченного (еще недавно) применения Call-центров в отечественных ТфОП у нас отсутствует не только нормативнотехническая база, но и устоявшаяся терминология, что, впрочем, уже
было отмечено в главе 6 и видно непосредственно из названия данной главы и всей книги. Не так давно появился официальный и, на наш взгляд, несколько многословный термин 一 многофункциональный центр обслуживания вызовов (МФЦОВ).
На момент подготовки данной книги действовал следующий перечень руководящих документов, определяющих построение МФЦОВ для систем информационно-справочного обслуживания Взаимоувязанной сети связи России:
Закон РФ «О защите прав потребителей»от 09.01.96;
Федеральный закон «О связи»;
Общие технические требования (ОТТ) к оборудованию ЗУСС, ЭУИС-0 на базе ЭАТС, утвержденные Минсвязи РФ 24.06.97;
Общие технические требования (ОТТ) к аппаратно-программному комплексу оборудования цифрового многофункционального центра обслуживаяия вызовов (МФЦОВ), утвержденные. 22.12.97 Госкомсвязи России;
Правила оказания услуг телефонной связи, утвержденные постановлением Правительства РФ № 1235 от 26.09.97;
Система и план нумерации на сетях связи стран 7-й зоны всемирной нумерации, утвержденные Госкомсвязи РФ №71 от 20.04.99;
ГОСТ Р 22.7.01-99 «Безопасность в чрезвычайных ситуациях. Единая дежурно-диспетчерская служба. Основные положения». Дата введения 2000-01 -01;
Распределение резервных номеров действующей нумерации спецслужб местных сетей телефонной связи, утвержденное Минсвязи РФ 14.09.00.
Этими же документами нормируются качественные показатели телефонного доступа к Call-центрам. Качество телефонного доступа абонента к службе, включенной в телефонную сеть, оценивается на основе следующих критериев:
доступности службы для абонентов;
слышимости, обеспечиваемой трактом между абонентом и службой.
Основным нормируемым показателем, по которому должно оцениваться качество работы службы сточки зрения ее доступности для абонента, является вероятность потери первичной попытки, т.е. вероятность того, что абонент, обратившийся к службе в случайный момент времени, получит сигнал ЗАНЯТО.
Вероятность потери первичной попытки должна оцениваться с помощью контрольных вызовов службы, производимых в течение 30 минут в разные периоды суток, путем:
подсчета доли вызовов, встретивших зуммер ЗАНЯТО, в соответствии с формулой:
р = *・100%
N
где: N - общее число контрольных вызовов службы,
N33 — число вызовов, встретивших зуммер ЗАНЯТО;
измерения суммарного времени, в течение которого в условиях реальной нагрузки были заняты или заблокированы все линии пучка, ведущего к данной службе, и отнесения измеренной величины к продолжительности периода измерения в соответствии с формулой:
м=Тзан.пучКа 100%тизм
где: Тизм - продолжительность периода измерения,
Тзан пуч|(а 一 измеренное суммарное время, в течение которого были заняты или заблокированы все линии пучка, ведущего к службе.
Для уточнения графика работы операторов, сравнительной оценки работы групп операторов и т.п. используется показатель потерь по вызовам, который рекомендуется определять за 30-минутный интервал времени по формуле:
р — Мтк
гдеNo6c-число вызовов, обслуженных заданный 30-минутный
интервал времени,
NorK 一 число отказов, измеренное за тот интервал времени на пучке линий, ведущих к службе.
Вероятность потери первичной попытки не должна превышать:
- 0,002 при обращении абонента к экстренной спецслужбе;
0,02 при обращении абонента к справочной или заказной службе АМТС(МТС);
一 0,2 при обращении абонента к СИЗС;
Для оценки работы Call-центра используется также показатель, характеризующий время ожидания абонентом обслуживания и определяемый:
при проведении контрольных вызовов (КВ) путем регистрации длительности ожидания при каждом задержанном КВ; нормированию подлежит допустимая длительность ожидания Тож доп, которая может превышаться лишь с заданной вероятностью;
путем оценки средней длительности ожидания абонентом обслуживания Тож, которую рекомендуется вычислять за 30-минутный интервал времени по формуле:
м = Ь^・100%,т'задер.
где Тож сум - измеренная счетчиком суммарная длительность ожидания абонентом обслуживания за 30-минутный интервал,
N^^ - подсчитываемое счетчиком число вызовов, обслуженных за 30-минутный интервал с ожиданием.
Длительность ожидания обслуживания зависит от ряда факторов (средней длительности обслуживания, числа обслуживающих приборов, и т.п.) и, как правило, нормируется положением о конкретной службе, согласованным с управлением ГТС.
Следует также упомянуть о принципах начисления платы и расчетов с абонентами за предоставленные им услуги Call-центров. Плата, взимаемая с абонента за пользование услугой местной телефонной связи, в принципе, слагается из двух составных частей:
платы за предоставление телефонного разговора с СаВ-центром;
платы за услугу, оказываемую СаН-центром.
Плата за предоставление телефонного разговора может либо отсутствовать (бесплатный разговор), либо начисляться в зависимости от продолжительности разговора абонента со службой, в соответствии с системой повременного учета стоимости услуг местной телефонной связи.
Стоимость платной услуги, оказываемой абоненту службой, начисляется в соответствии с тарифом и выставляется в едином счете-извещении, формируемом в АСР с абонентами за услуги электросвязи и высылаемом абоненту оператором связи.
Чтобы исключить начисление платы за связь с экстренными спецслужбами, предоставляющими по согласованию с администрацией связи бесплатные услуги, разговор с этими службами должен происходить без подачи службами сигнала ответа, т.е. в предответном состоянии.
Оплата разговора с Call-центрами, вызванными по линиям внутризоновой, междугородной и международной телефонной связи производится в соответствии с принятой у оператора связи системой оплаты разговора между абонентами при вызовах по тем же линиям.
Дополнительные услуги телефонной связи оказываются с обеспечением для всех абонентов одинаковых условий обслуживания и оплаты (не считая льгот и преимуществ, предусмотренных законодательством РФ и иными нормативными правовыми актами). Тари-
фы на дополнительные услуги телефонной связи устанавливаются операторами связи с учетом затрат на их предоставление.
Система и порядок оплаты дополнительных услуг устанавливается оператором связи самостоятельно в соответствии с техническими возможностями сетей и средств связи. С целью рационального распределения нагрузки на справочно-информационные и заказные службы (кроме службы 09) оператор связи может вводить на их услуги тарифы, дифференцированные по часам. Срок расчета за услуги справочно-информационных и заказных служб устанавливает оператор связи, причем срок этот не должен составлять более месяца.
За дополнительную плату Call-центры могут предоставлять абонентам ТфОП следующие услуги:
перестановку, переключение (изменение схемы включения) телефонных аппаратов и иных абонентских устройств;
временное выключение по просьбе абонента абонентских устройств с бронированием абонентских номеров и линий и обратное их включение;
переоформление договора об оказании услуг телефонной связи;
справочно-информационные услуги, включая справки о номерах телефонов абонентов по неполным данным;
передачу телеграмм по телефону;
замену абонентского номера по просьбе абонента;
исключение абонентского номера из базы данных справочной службы по просьбе абонента;
междугородный телефонный разговор с уведомлением вызываемого лица;
междугородный телефонный разговор в назначенное пользователем время;
предупреждение вызываемого абонента о времени предстоящего междугородного телефонного разговора;
вызов к телефону определенного лица;
справку об абонентском номере в другом городе (населенном пункте) и др.
Бесплатными услугами Call-центров по правилам ВСС считаются:
вызов бюро ремонта телефонной сети;
справка о номерах телефонов абонентов местных телефонных сетей по полным адресным данным;
справка о междугородном коде нужного населенного пункта;
справка о международном коде нужной страны и нужного населенного пункта в этой стране;
справка о тарифах на услуги местной, междугородной и международной телефонной связи;
справка о разнице во времени между данным населенным пунктом и другим пунктом, расположенным на территории Российской Федерации или за ее пределами;
справка о порядке пользования автоматической телефонной связью;
справка об индексах вызова заказных служб междугородной и международной телефонной связи.
Запрещается выдавать справку об адресе абонента по его телефонному номеру. Вовремя стихийных бедствий, карантинов и в других чрезвычайных ситуациях федеральный орган исполнительной власти в области связи имеет право приоритетного пользования услугами телефонной связи.
И, в заключение данного параграфа, в таблице 7.1 приведены примеры расценок на услуги Call-центров, взятые из реально используемых в разных регионах России.
Таблица 7.1. Примеры расценок на услуги Call-центров в ряде телефонных сетей России в 2001 году
Наименование услуги
Плата, в руб.
Информация о номерах телефонов абонентов по неполным данным, справки о номерах телефонов, адресах фирм, телефаксах, наименовании фирм, их деятельности, о курсах валют, услугах биржи, как проехать по городу, подбор предприятий по виду деятельности (в дневное и ночное время), прибытие кораблей и т.п.
4,5 - 21,0
Номера телефонов в других городах и странах (абонентов, организаций и т.п.)
10,0
Информация о предприятиях, ведомствах, фирмах и т.п., их деятельности в других городах и странах
15,0 - 25,0
Справочная железной дороги
4,5
Заказ такси
6,0 - 15,0
Выход в Интернет
10,0
Поиск товаров, предоставление услуг по индивидуальному заказу
50,0
Прогноз погоды
4,5
Горсправка
7,5 - 15,75
Юридическая справка
15,0 - 31,5
Прием телеграмм по телефону
3,15
Подбор вариантов обмена квартир, дач, гаражей и т.п.
15,0 - 25,0
Бюро поручений
8,0 - 15,0
Заказ товаров и услуг на дом
8,5
Реклама предприятий культуры, выставок, фестивалей, спортивных соревнований
5,0
Служба знакомств
10,0
Учебно-консультативные справки
8,5 - 20,0
Заказы на рекламу в периодической печати
8,5
Информация для автомобилистов
40,0
Глава 8 Конта кт-центры
Как только идея становится понятной всем, ее пора менять. Закон Джексона
8.1 Конвергенция и операторские центры
Необычайно быстрый рост Интернет в совокупности с появлением технологий и стандартов, обеспечивающих конвергенцию компьютерного и телекоммуникационного миров, может коренным образом изменить (и уже меняет) всю систему связи в мире.
Сегодняшние тенденции развития обслуживания пользователей телекоммуникациями, а также бизнеса и коммерции в целом, пересекаясь с современными технологиями связи, формируют качественно новый уровень требований, предъявляемых к рассмотренным в предыдущей главе Call-центрам, к их архитектуре и функциональным возможностям. Чтобы понять, какие это требования, надо, прежде всего, ответить на три ключевых вопроса.
Вопрос первый: что изменилось, зачем, собственно, нужны какие- то изменения архитектуры и функций операторских центров нового поколения, если сегодня они и так представляют собой мощные, гибкие и многофункциональные системы? Вопрос второй: какиедопол- нительные функции требуются при организации операторских центров в сетях следующего поколения? И, наконец, вопрос третий, ответ на который, в значительной степени, вытекает из ответов на первые два: какова может быть архитектура такого рода программноаппаратных комплексов?
Итак, по порядку. Что же собственно произошло за последние годы? Прежде всего, это феноменальный рост популярности IP Присутствие во «Всемирной паутине» сегодня является не роскошью, а жизненной необходимостью для любой компании, претендующей на коммерческий успех.
8. Б.С. Гольдштейн
Не менее значительное влияние на эволюцию операторских центров оказывает динамичное развитие электронного бизнеса и коммерции. Электронная коммерция позволяет избежать известных трудностей и неудобств, связанных, скажем, с какой-либо покупкой (по крайней мере, сточки зрения самого покупателя). Больше никто не заставляет клиента ехать через весь город, преодолевать тяжелые погодные условия, долго выбирать необходимый товар и выстаивать в очереди к кассе. Благодаря существованию электронной коммерции покупка необходимого товара в другом регионе страны может стать менее обременительной, чем покупка его в соседнем магазине. Кроме того, сама операция купли/продажи удобна для покупателя. По крайней мере, электронный магазин всегда открыт, и клиент может его посетить в удобное для него время. Таким образом, возможности привлечения новых клиентов - огромны. Но при этом нельзя не отметить, что наряду с открывающимися возможностями существует и определенная доля риска. Если клиент испытывает неудобства с Web-сайтом - например, он не может найти интересующую его информацию, не понимает, каким образом следует заполнить ту или иную форму, сайт не работает или не оправдывает его надежд, - он просто покинет этот сайт и пойдет к конкурентам. Насколько клиенту проще совершить необходимые покупки, не выходя из дома, настолько же ему проще перейти на следующий сайт, если с предыдущим у него возникли какие-либо проблемы.
Итак, в условиях современного развития бизнеса и роста популярности Интернет практически любая компания, любая коммерческая или справочно-информационная служба имеет свой собственный Web-сайт. С другой стороны, процент посетителей этих сайтов, которые, в конечном итоге, пользуются предложенными услугами, пока еще очень мал. В первую очередь, это объясняется неуверенностью клиента в правильности своего выбора, недоверием к Интернет как к коммерческой структуре, излишней сложностью маршрута, который он должен пройти по сайту, чтобы получить желаемый результат.
Приведем характерный пример. Хотя сезон рождественской распродажи 1999 г. на Западе принято считать началом эры электронной коммерции, по оценкам ряда экспертов суммы прибылей, недополученных многими компаниями в электронном бизнесе в этот период, огромны. Одно из исследований показывает, что более 60% покупателей, сложивших покупки в свою электронную корзину, не доводит этот процесс до конца. А другое исследование оглашает конкретную сумму недополученных за 1999 匚 прибылей - 1,6 миллиардов USD [данные «World Trade» за апрель 2000]. При этом, поданным психологов, если бы в момент сомнений при выборе покупки клиент имел возможность обратиться к оператору (т.е. воспользоваться привычным речевым способом общения с представителем фирмы), то процент совершенных сделок был бы гораздо выше.
Бурное развитие электронной коммерции и популярность технологии IP как единого транспорта для передачи информации любого вида дало возможность связать Web-среду с ресурсами операторского центра и предложить клиентам персонализированное обслуживание и удобное средство общения.
Интеграция традиционных операторских центров и Интернет позволяет превратить менеджмент взаимоотношений с клиентами в мощный инструмент, повышающий эффективность бизнеса компаний и удобства клиентов.
Покажем это на примерах. Турфирмы могут предложить персонализированную услугу планирования тура и привлечь большее количество потенциальных путешественников, максимально заинтересовав их в предстоящей поездке. Web-страницы могут направляться на компьютер клиента - посетителя Web-сайта турфирмы, - и этот клиент может увидеть картинку тропического острова, образец дорожного чемодана, отель, в котором его предполагается разместить, или другую информацию, причём всё это - в ходе текстового или речевого общения с оператором центра в реальном времени.
Финансовые учреждения могут привлекать к себе потенциальных клиентов, предоставляя им легкодоступную полезную информацию в отношении сложных товаров и услуг Посетитель Web-сайта компании может одним щелчком мыши установить речевую связь с оператором-агентом, чтобы получить детальную информацию о предоставляемых услугах или ответы на частные вопросы, не оговоренные на Web-сайте.
Отделы технической поддержки и обслуживания заказчиков могут оказывать консультативные услуги, переключая поступивший от заказчика телефонный вызов к квалифицированному техническому специалисту, который может ответить на технические вопросы заказчика по телефону, часто - сопровождая ответ информацией, передаваемой через Web.
Менеджмент взаимоотношений с клиентами, который рассматривается сегодня как важнейший фактор, способствующий выживанию компании в условиях жесткой конкуренции, невозможен без эффективного использования всех технологий общения с реальным или потенциальным клиентом. Как следствие, конвергенция разнообразных инфраструктур, технологий и коммуникационных сред становится существенным средством повышения эффективности работы операторских центров и систем «самообслуживания» потребителей (self-service customer services).
Одним из важных элементов конвергенции является отвод в Интернет части потока вызовов от систем и устройств, более дорогих в обслуживании, для быстрейшего сбора нужной информации и обеспечения высокого качества обслуживания потребителей. Происхо-
дит переход от операций, ориентированных, преимущественно, на речевую связь, к смешанным, включающим в себя, как важнейшие составляющие, электронную почту и Web-трафик.
Интегрированные операторские центры эффективно применяются и в корпоративных мультисервисных сетях, которые сегодня строятся на принципах пакетной коммутации. Это могут быть Интрасети или менее привычные Экстрасети (специализированные виртуальные частные сети VPN, аналогичные внутрикорпоративным сетям на базе Е но разрешающие доступ к ним не одной компании, а группы таких компаний и их подразделений). Являясь расширением внутрикорпоративной Интрасети, Экстрасеть позволяет деловым партнёрам обмениваться конфиденциальной информацией и совершать финансовые операции. Интегрированный центр поможет описанным выше корпоративным сетям наращивать возможности поддержки своих клиентов, в частности, благодаря эффективной организации на его базе справочных столов.
Еще несколько лет назад ведущие мировые производители коммутационного оборудования рассматривали Call-центры только как дополнение к выпускаемым ими системам и возлагали на эти центры, в основном, функции распределения вызовов, рассмотренные в главе 6. Сейчас эти производители (и не только они) осознали огромный потенциал решений на базе Call-центров и начали предлагать на телекоммуникационном рынке интегрированные продукты - контакт-центры, способные взаимодействовать с любыми телекоммуникационными средами. В соответствии с исследованиями западных аналитиков, доходы от предоставления услуг контакт-центрами с 19,9 миллиардов долларов в 1998 возрастут к 2005 году до 49 миллиардов. И это - только в США, игроке номер один на рынке Call-центров, но далеко не единственном игроке.
Второй ключевой фактор, оказывающий влияние на развитие кон- такт-центров, - это развитие компьютерных технологий и рост вычислительных мощностей, фактор, который заставляет переоценить взгляды наархитектурутелекоммуникационных систем, выводит контакт-центры из разряда узкоспециального оборудования, усиливает конкуренцию на рынке и позволяет разработчикам быстро создавать и предлагать покупателям новые системы.
К тому же, стремительно развивающиеся IP-технологии позволяют компаниям экономично использовать решения на основе Web- контакт-центров и использовать (там, где это дает эффект) сеть Интернет, причем не только для обмена данными, совместного использования файлов и показа рекламы, но и для услуг; раньше считавшихся прерогативой телефонных сетей. Конвергенция систем переноса речи и данных по сетям IP открывает новые возможности предоставления дополнительных услуг, обеспечивает глобальный доступ к услугам Web-контакт-центра из любой точки сети и снижает про-
изводственные расходы за счет применения эффективных технологий пакетной коммутации, уменьшения полосы, используемой для передачи речевого трафика, и оптимизации программно-аппаратной архитектуры систем.
В контакт-центрах интеграция услуг передачи речи/данных осуществляется на качественно новом уровне: архитектура таких систем обеспечивает возможность мультимедийного обмена сообщениями, т.е. приема, распределения и обработки по унифицированным алгоритмам сообщений и вызовов разного типа, приходящих из различных сетей. Интегрированный контакт-центр нового поколения, упрощенная структура которого представлена на рис.8.1, должен обеспечивать прием традиционных телефонных вызовов, телефонных вызовов, поступающих из сети Интернет с использованием технологий VoIR прием заявок, допускающих отложенную обработку (факсимильные запросы и электронная почта, переходящие, в перспективе, в запросы по технологиям Unified Messaging), а также обработку в будущем запросов мультимедийной широкополосной связи. Должны также обеспечиваться поддержка режима чата (text chat) в реальном времени, доступ к динамической системе помощи, функции просмотра Web-страниц с сопровождением, возможности коллективного внесения отметок в страницы и совместного заполнения бланков заказов.
Рис. 8.1 Упрощенная структура контакт-центра
Функциональные возможности контакт-центров, интегрированных с Интернет, позволяют компаниям, создающим такие центры, персонализировать отношения с посетителями Web-сайтов, обеспечивая доступ к агенту службы взаимодействия с потребителем в кри-
тический момент, когда у посетителя имеется важный вопрос, от ответа на который зависит, совершит он покупку или нет. Действительно, с точки зрения психологии очевидно, что человек (клиент) почти всегда чувствует себя более комфортно, общаясь с другим человеком (оператором), чем просматривая безликие Web-сайты с яркими картинками или прослушивая механический голос автоответчика. Иногда на сайте той или иной компании можно встретить раздел «Наиболее часто задаваемые вопросы», который фактически призван разрешать возникающие у клиента вопросы. Но нельзя не учитывать тот факт, что заранее предусмотреть желания всех клиентов просто невозможно. Другое дело, когда посетитель, не утруждая себя поиском нужной информации на Web-сайте, просто нажимает нужную кнопку и без лишних физических и материальных затрат получает всю необходимую информацию, причем - с выгодной для компании стороны. Кроме того, информацию он может получить в том виде, в каком ему удобно, или в том, который допускает имеющееся у него терминальное оборудование. Отсюда сразу становится очевидным второе преимущество.
Интегрированный контакт-центр должен сделать одинаково удобными для клиента такие разные способы обращения к персоналу центра, кактелефонный вызов, вызов через Интернет, электронная почта или текстовый чат. При этом клиент должен быть уверен, что любой его вызов будет обработан с одинаковой тщательностью, и что если он, например, через двадня после отправки электронного письма или факса позвонит по поводу своего запроса в центр, ему не придется долго пересказывать оператору содержание этого запроса.
Абонент должен иметь возможность получить доступ к ресурсам центра, используя в качестве терминального оборудования либо телефонный аппарат, либо персональный компьютер. Сочетание традиционного операторского центра обслуживания вызовов с возможностями доступа из Интернет является мощнейшим катализатором для электронной коммерции и позволяет реализовать такие возможности взаимодействия с клиентом, которые выходят за рамки только использования информации, имеющейся на Web-сайте, или только заочной телефонной беседы «клиент-оператор». В настоящее время множество электронных коммерческих сделок расстраивается именно из-за того, что отсутствует общение клиента с живым сотрудником, который мог бы повлиять на решение клиента. В то же время, только телефонного интерфейса часто уже недостаточно для того, чтобы клиент мог получить всю интересующую его информацию о товарах или услугах. Таким образом, интегрированные контакт-центры могут стать решающим фактором в превращении потенциальных покупателей в реальных.
Важно, что благодаря возможностям IP-технологий операторы контакт-центра, интегрированного с Интернет, получают возмож-
ность находиться территориально в любом месте. При этом создаётся виртуальный, работающий круглосуточно контакт-центр, не требующий использования дорогого сетевого ПО или оборудования дистанционных операторов. Облегчается поддержка многоязычно- сти операторов контакт-центра, благодаря которой становится возможным обслуживать клиентов из разных уголков земного шара. Более того, учитывая наличие нескольких часовых поясов только на территории нашей страны, не говоря уже обо всем земном шаре, нетрудно обеспечить круглосуточное обслуживание клиентов. Если говорить о специфике использования глобальной сети Интернет в России, то надо отметить, что большинство пользователей предпочитают для работы в этой сети ночные часы, что обусловлено как наличием свободного времени именно ночью или поздним вечером, так и особенностями тарифов на услуги поставщиков.
Интеграция операторских центров с Интернет должна позволить предприятиям сократить расходы на персонал благодаря переводу в Интернет (в режим, не требующий немедленного ответа) значительной части информационных запросов, сохранив при этом возможность того, чтобы клиент, при необходимости, в любой момент легко связался с живым оператором. Обслуживая вызовы, поступающие из Интернет, предприятие предоставляет своим клиентам свободу просмотра любого оперативного материала (каталога продукции, технической информации), пока у них не возникнут вопросы или комментарии. Введение этой возможности в Web-страницы может привлечь тех, например, кто предпочитает сообщать номера кредитных карт по телефону, а не пересылать их через компьютер.
Все упомянутые выше преимущества, в совокупности с тенденциями, когда всё больше деловых операций осуществляется через Интернет, когда растет роль и место в жизни электронного бизнеса и электронной коммерции, а также с тем, что постоянное совершенствование технологии цифровой обработки речи и технологии ее передачи по сетям с пакетной коммутацией в последнее время существенно повысило качество речевой связи в пакетных сетях, ведут к тому, что в ближайшие годы прогнозируется настоящий бум в сфере операторских центров обслуживания вызовов, интегрированных с Интернет.
Крупные зарубежные производители, такие как Lucent Technologies, Nortel Networks и Cisco Systems, многие менее крупные (опять же в основном зарубежные) компании, а также некоторые отечественные разработчики (платформа ПРОТЕЙ, например) активно внедряются на рынок интегрированных операторских центров.
Некоторые действующие Web-контакт-центры уже сегодня предлагают возможность видеосвязи, если у клиента есть видеокамера и Н.323-совместимый Web-браузер. Правда, ее качество оставляет
желать лучшего, но это поправимо - более важен прецедент. А операторские компании, такие как AT&T MCI WorldCom и Sprint, уже предоставляют услуги интернетовского контакт-центра на условиях аутсорсинга фирмам, которые заинтересованы в таких услугах. Хочется верить, что в недалеком будущем подобным бизнесом займутся и отечественные телекоммуникационные операторы.
В настоящее время для интегрированного контакт-центра имеются варианты решений, позволяющие предприятиям начать построение операторского центра с ёмкости всего в несколько портов и единиц рабочих мест операторов. Это дает небол ьшим контакт-центрам возможность быстрее окупить капиталовложения, параллельно реализуя, в рамках общей стратегии продажи, высокопродуктивную и экономически выгодную программу электронной торговли. Тем компаниям, которые неуверены в том, насколько использование Инте р н ет п од ход ит дл я их деятельности, такие системы дают средство проверить (причем с малым риском) возможности контакт-центра, интегрированного с Web, и разного рода дополнительные приложения, а также отладить процессы реорганизации бизнесадо заключения долговременных соглашений об использовании операторских центров или до приобретения оборудования.
Разработаны методики оценки экономической целесообразности использования интегрированных контакт-центров коммерческими компаниями. Так, если компания уже ведет электронную торговлю через Web, то выполняется анализ регистрационных файлов Web- сервера, по результатам которого компания может быстро определить, достаточны ли поступающий трафик и частота обращений к Web для того, чтобы оправдать использование контакт-центра. Для компаний, которые, наоборот, сравнительно недавно занимаются электронной торговлей через Web и не знают, какие выгоды они могут получить от контакт-центра, интегрированного с Интернет, может выполняться, наряду с их обслуживанием на условиях аутсорсинга, экономический анализ, показывающий, как идут дела в течение года. Если наблюдается устойчивый рост числа операций, совершаемых через контакт-центр, а доходы от обслуживания приближаются к закупочной цене системы, то приобретение системы в свое пользование становится экономически оправданным.
Функциональные особенности контакт-центра
Итак, на вопрос «Зачем?» мы постарались ответить в первом параграфе данной главы. Постараемся теперь ответить на вопрос «Что именно?», т.е. какими функциональными возможностями должен обладать современный интегрированный контакт-центр.
Для начала определимся с терминологией. В главах 6 и 7 обсуждались уже ставшее привычным англо-русское словосочетание «Call-
центр», а также его менее часто употребляемые синонимы - «инфоцентр» или «операторский центр». Все эти термины относятся к структуре, оперирующей, в основном, с телефонными вызовами. Сегодняшний Call-центр такого рода обрабатывает запросы клиентов и оптимизирует обработку этих запросов с учетом того, что телефонный разговор является отнюдь не единственным и даже, возможно, не основным средством доступа к информации.
Отсюда - изменение названия. На смену терминам «инфоцентр», «операторский центр» или «Call-центр» приходит новый термин - «контакт-центр» (или даже «Web-контакт-центр»), более точно отражающий эволюцию понятий и функциональных возможностей подоб- ныхсистем.
Рассмотрим особенности новых, интегрированных с Интернет контакт-центров, разбив эти особенности на функциональные группы, аналогичные по назначению группам функциональных возможностей традиционных Call-центров, а также отметим некоторые специфические характеристики интегрированных контакт-центров.
Прежде всего это мультимедийность, понимаемая как способность обслуживать запросы разных типов, поступающие из разных телекоммуникационных сетей:
запросы речевой связи - из ТфОП;
запросы речевой связи - из Интернет, с использованием технологии 1Р-телефонии;
запросы связи по факсу, электронной почте;
запросы связи в режиме текстового чата - из Интернет;
видеовызовы (в недалекой перспективе).
Мультимедийность начинается с доступа куслугам ко нтакт- центре в.
Доступ к услугам контакт-центра
Рассмотрим некоторые из таких способов доступа к услугам, которые характерны именно для контакт-центра, интегрированного с Web. Как правило, если мы говорим об интегрированном контакт- центре,то предполагаем, что клиент получает доступ к ресурсам контакт-центра со стороны корпоративного Web-сайта и/или связанных с этим Web-сайтом операторов. Таким образом, задачей контакт- центра является обеспечение универсальности доступа с точки зрения абонента, свободы выбора метода доступа к услугам контакт- центра. Полная прозрачность механизмов доступа приводит к тому, что абоненту достаточно просто нажать на соответствующую иконку на первой странице сайта компании, выбрав тем самым способ связи с центром.
Существует целый ряд способов реализации такого универсального доступа. Одним из самых перспективных и экономически целесообразных способов (хотя несколько уступающим пока по качеству традиционной телефонной связи и требующим наличия у абонента хорошего Интернет-доступа) является доступ на базе технологии IP-телефонии, рассмотренной в [5]. Речевой диалоге клиентом проводится в виде сеанса VoIP с использованием уже имеющегося соединения корпоративного Web-сайта с Интернет. При этом клиент и оператор контакт-центра могут вести диалог и даже синхронно просматривать одни и те же Web-страницы, как это представлено на рис.8.2.
Рис. 8.2 Варианты доступа к контакт-центру
При вызове из Интернет пользователь получает доступ к контакт- центру компании, щёлкнув мышью на кнопке «call», находящейся на её Web-странице, что активизирует программу IP-телефонии, зарегистрированную у Web-браузера. Эта программа может быть интегрированным приложением Web-браузера или отдельным приложением, которое вызывается браузером из какого-либо места на рабочем столе пользователя.
При нажатии на кнопку начинается процедура организации связи через Интернет со шлюзом IP-телефонии с использованием соединения, уже установленного с Интернет-поставщиком. Кнопка фактически является гипертекстовой ссылкой, написанной на языке HTML, которая используется для инициирования этого процесса. Ниже приводится пример гипертекстовой ссылки с указанием IP-адреса сер-
вера и подкаталога, где надо искать нужное приложение (адрес выделяется жирным шрифтом):
a<href=((javascript:showWindow( http://209.192.139.68/ITG/ caUerapps.pl?vdn_ext=55396&type=voice&browseWinURL=http:// store.XYX.. com/icc/welcome. html'); ”〉<a >
В данном случае написанная на языке Perl процедура используется для нахождения нужного приложения вызывающего абонента (знак вопроса указывает, что это процедура поиска). Шлюз VoIP загружает в компьютер пользователя Java-приложение обработки вызова для запуска приложения IP-телефонии. Java-приложение обеспечивает интерфейс, через который пользователь может также получать сообщения о состоянии процесса обслуживания вызова, участвовать в обмене текстовыми сообщениями, сотрудничать с агентом операторского центра путём посылки ему Web-страницы, или прекратить сеанс.
Использование Java для предоставления пользователю этой функциональной возможности имеет ряд преимуществ перед другими реализациями стандартного межсетевого интерфейса (CGI). Во-первых, Java-приложение (аплет) загружается только в случае необходимости и не занимает постоянного места на компьютере клиента. Во-вторых, все задачи сопровождения программного обеспечения выполняются на сервере. Это значит, что Java-приложение можно изменять любым образом (функционально или косметически) прямо на сервере. В связи с тем, что Java-приложение после его использования не остаётся на компьютере клиента, пользователи, инициирующие вызов, будут всегда получать на свой Web-броузер самую последнюю версию. Наконец, поскольку Java-приложение распространяет функции сервера до клиента, трафик между клиентом и сервером сводится к минимуму, что позволяет использовать соединение более эффективно.
После того как кнопка «call» нажата, и приложение IP-телефонии открыто, устанавливается соединение с Web-сервером компании. В некоторых случаях Web-сервер только передает сообщение о вызове, которое запускает механизм планирования ответа на вызов в исходящей очереди операторского центра, определяя оператора или класс (группу) операторов для обслуживания данной заявки. На Web-сервер передается ответное сообщение с указанием расчётного времени обратного вызова, а Web-сервер пересылает эту информацию вызывающему абоненту.
После того как оператор принял вызов, дальнейшее зависит от того, на какой режим работы настроен контакт-центр. В простейшем сценарии оператор отвечает на вопросы вызвавшего абонента и вводит в базу данных компьютера ту информацию о состоявшемся диалоге, которая может оказаться полезной при следующем вызове от того же пользователя. Кроме того, эта информация может использоваться для многих других целей, включая вызов эксплуатационного персонала, создание транспортных ярлыков для заказанных то-
варов, отслеживание продажи, рассылку рекламных материалов по почте и подготовку отчетов о потребителях, обратившихся в контакт- центр.
В более сложном сценарии, как было отмечено выше, оператор может фактически просматривать ту же Web-страницу, что и вызывающий абонент, а также любое связанное с ней встроенное приложение, которое использует посетитель Web-сайта. Это позволяет представителю компании оказывать оперативное содействие клиенту, отвечая на его вопросы, направляя его к соответствующей информации на Web-сайте или принимая от него заказ в реальном времени.
Для совместного просмотра информации в компьютер клиента, как правило, загружается Java-приложение, которое захватывает битовое изображение экрана примерно раз в секунду. Таким образом, приложение Web-сервера, которое поддерживает функцию совместного использование браузера, «считывает» изображение на экране клиента и затем «рисует» его на экране оператора. Процесс работает и в обратном направлении, так что клиент может видеть то, что видит агент. Это особенно полезно при наличии возможности вносить изменения в Web-страницу, что позволяет оператору с помощью мыши делать на ней отметки, подчёркивая те пункты, на которые клиенту следует обратить внимание.
Другим способом общения с абонентом, работающим в сети, является использование для передачи речевого трафика и трафика дан- ныхдвух разных каналов, что возможно, например, при наличии у абонента линии ISDN. Однако технологических новшеств, как таковых, здесь немного, и мы не будем рассматривать этот способ подробно.
В тех случаях, когда клиент не хочет простаивать в очереди, ожидая обслуживания, он может обратиться к услуге «автоматический обратный вызов» (рис.8.3). В контакт-центре услуга обратного вызова (Call-back) приобретает новое наполнение. Описанная в главе4тра- диционная услуга этого вида сводилась к тому, что абонент, услышав ответ IVR, либо диктовал контактный телефон, либо подтверждал правильность автоматического определения его номера, после чего клал трубку на рычаг телефонного аппарата и ждал, когда ему позвонит оператор. В интегрированных с Web контакт-центрах возможности услуги обратного вызова существенным образом расширяются. Вместо того, чтобы диктовать свои данные или на слух контролировать правильность определения номера, значительно удобнее воспользоваться преимуществами Интернет. Абонент заполняет на Web-сайте компании соответствующую форму, вводя в неё номер своего телефона (или указывая любой другой способ для контактов - mail, ICQ и т.д,), тему для обсуждения и день и время, когда он будет на месте для приема обратного вызова от компании (если выбранный им способ общения предполагает диалог в реальном времени). Форма пересылается по электронной почте в контакт-центр, где она направляется наиболее компетентному в данной области оператору. Если або-
ненту нужно, чтобы с ним связались как можно скорее, он делает в форме соответствующую отметку. В этом случае запрос сразу ставится в очередь на обслуживание и маршрутизируется каклюбой другой вызов, поступающий в контакт-центр. Затем этот запрос получает первый освободившийся оператор, обладающий достаточной квалификацией. Он видит во временном окне телефонный номер пользователя и передает со своего терминала в систему команду автоматически набрать номер и установить соединение с этим пользователем.
Рис. 8.3 Два варианта организации услуги "обратный вызов"Рис. 8.3 Два варианта организации услуги "обратный вызов"
Рис. 8.3 Два варианта организации услуги "обратный вызов"
Рис. 8.3 Два варианта организации услуги "обратный вызов"
Способы связи с пользователем могут быть разными. Если у пользователя есть две телефонные линии, то его телефон тотчас начнет звонить, в противном случае возможны варианты. В самом простом случае пользователь либо должен сперва выйти из Интернет, чтобы получить вызов по той же линии, либо воспо л ьзоваться в качестве альтернативы преимуществами технологии VoIP и принять вызов с помощью одного из приложений, поддерживающих эту технологию.
Такие возможности предусмотрены, например, в оборудовании CentreVu Internet Solutions (AVAYA), в контакт-центре Suite компании Genesys и в упоминавшемся ранее отечественном контакт-центре ПРОТЕЙ.
На Web-сайтах трех названных контакт-центров присутствуют кнопки обратного вызова. При нажатии на эту кнопку запрос пользователя немедленно ставится в очередь исходящих вызовов, и на его экран выводится счётчик, указывающий место в очереди и ориентировочное время, когда к нему должен поступить обратный вызов от оператора. Приложение подстраивается под пользователей. Например, при нажатии на кнопку о братно го вызова в системе Suite, пользователю предлагается форма, в которую надо внести дополнительную информацию (в частности, указать предпочтительный способ приема обратного вызова - IP-телефония или обычная телефонная линия).
Варианты организации услуги «обратный вызов» в контакт-центре, интегрированном с Интернет, представлены на рис.8.3.
В тех сетях, гце предоставляется описанная в [3] услуга бесплатного междугородного вызова Freephone, целесообразно также наличие на Web-сайте компании кнопки, предоставляющей абоненту возможность заказать обратный вызов от оператора, находящего в другом регионе. Скажем, услуга InteractiveAnswers, предоставляемая AT&T позволяет устанавливать соединение между посетителем Web-сайта и «живым» оператором, который может немедленно ответить на вопросы, касающиеся товаров и услуг Когда пользователь щёлкает мышью на кнопке «Call Me Toll-Free», через Web посылается уведомление, информирующее оператора о том, что запрошен обратный вызов.
Выбор способа связи с абонентом может также производиться операторским центром автоматически, например, с помощью приобретающей сегодня популярность услуги ICW- Internet Call Waiting.
Когда обратный вызов поступает к абонентскому терминалу, абонент, сняв трубку, слышит записанное речевое сообщение с просьбой подтвердить, что он желает говорить с оператором. После этого происходит подключение оператора, и, спустя короткое время, пользователь может с ним разговаривать.
Следующий способ доступа к услугам операторского центра появился именно в контакт-центрах. Речь идет о режиме текстового чата (рис.8.4). Такой способ дает возможность обмена текстовой информацией между клиентом и оператором центра в реальном времени и может быть особенно актуален в случае отсутствия у пользователя программного обеспечения и оборудования VoIP (микрофона и громкоговорителя) или неудовлетворительного качества речи при использовании IP-телефонии, а также в случаях, когда надо безошибочно передать цифры, точное написание фамилий и т.д.
Серверы приложенийСерверы приложенийPCPC■Н■НРабочие места операторовРабочие места операторов
Серверы приложений
Серверы приложений
PC
PC
■Н
■Н
Рабочие места операторов
Рабочие места операторов
Рис. 8.4 Работа с контакт-центром в режиме текстового чата
Разнообразие типов обрабатываемых вызовов приводит к существенным изменениям в ряде основных функциональных блоков интегрированного операторского центра.
Организация очередей и маршрутизация вызовов
Дисциплины очередей и механизмы маршрутизации вызовов в контакт-центрах, интегрированных с Интернет, могут быть значительно сложнее, чем в «традиционных» операторских центрах. Свя-
зано это не только с совершенствованием алгоритмов распределения вызовов, но и с тем, что разные источники нагрузки в конвергентной сети имеют совершенно разные характеристики; соответственно, модель потока вызовов, которые должны обрабатываться интегрированным контакт-центром, существенно отличается от обычной модели, принятой для телефонных систем.
Понятно, что от источников разного типа запросы обслуживания поступают с разной интенсивностью, допускают разную длительность ожидания и разную продолжительность обслуживания, т.е. различаются параметрами, которые определяют характеристики входящей нагрузки, и на основании которых обычно производится распределение вызовов и организация очередей. Так, например, пороги длительности ожидания для заявок, допускающих отложенное обслуживание (почтовые услуги, Unified Messaging, факсимильные заявки), измеряются часами, а для традиционных телефонных вызовов - десятками секунд. Фактически, очередь превращается в буфер, выбор заявок из которого производится не в порядке их поступления (как это было в операторских центрах, обслуживающих только телефонные вызовы), а на основе анализа нескольких параметров, характеризующих эти заявки.
Механизмы обслуживания разных заявок могут быть различными. Их могут обслуживать л ибо отдельные операторы или「руппы операторов, либо те же операторы, которые обслуживают основной (речевой) поток запросов. Если второй вариант применим, появляется возможность существенно увеличить производительность контакт- центра, причем сделать это не за счёт увеличения ч и с л а о ператоров, а за счёт обработки запросов разных видов одним и тем же оператором. Запросы, допускающие отложенную обработку, оператор может обрабатывать в периоды, когца интенсивность потока телефонных запросов снижается.
В контакт-центрах может быть обеспечена возможность значительно улучшить качество обслуживания запросов, поступающих из сети Интернет. Не секрет, что сегодня запросы, поступающие в крупные компании, например, по E-mail, могут ожидать ответа довольно долго, иногда теряясь в огромном потоке входящей почты. Между тем, такие запросы являются все более удобными для пользователей, имеющих регулярный доступ к сети, и центры поддержки или справочные службы должны обрабатывать их с той же тщательностью, что и привычные для них телефонные запросы.
Чтобы решить эту проблему, в составе интегрированного с Интернет контакт-центра для обработки писем и факсимильных запросов обычно предусматривается специализированное программное обеспечение, которое помогает управлять:
обработкой электронной почты, генерируемой непосредственно с Web-сайта, - например, ответы пользователей на ссылки «write to us now» («напишите нам сейчас») или «Contact us>> («Свяжитесь с нами»), создаваемые на определённых Web-страницах и направляемые квалифицированным агентам;
~ обработкой электронной почты, направляемой по конкретному адресу, например, в отдел фирмы по технической поддержке клиентов; такие письма поступают прямо в контакт-центр и маршрутизируются на основании заданных алгоритмов;
обработкой факсимильных запросов, которые с помощью программного обеспечения факс-сервера, интегрированного в контакт-центр, пересылаются в специальный электронный почтовый ящик (или в обычный почтовый ящик при использовании технологий Unified Messaging) и хранятся на почтовом сервере.
В типовом сценарии пользователь передает сообщение электронной почты в центр обслуживания либо по обычному каналу электронной почты, либо путём заполнения формы на Web-сайте. Далее сообщение проходит по Интернет к почтовому серверу, установленному в помещении центра. По прибытии сообщения на почтовый сервер операторского центра генерируется так называемый «фантомный вызов» (термин, предложенный компанией 闻凤4 применительно к своему операторскому центру DEFINITY ECS и наиболее точно отражающий суть действия). Этот фантомный вызов предназначен для передачи сообщения оператору: он воспринимается как обычный телефонный вызов, ставится в очередь и маршрутизируется в соответствии с алгоритмом и набором средств, определёнными управляющим приложением.
Когда освобождается оператор, способный обслужить вызов этого типа и тематики, «вызов» электронной почты поступает к речевому терминалу оператора, и тот получает уведомление о его присутствии на экране браузера. Пользовательский интерфейс рабочего места оператора контакт-центра содержит ряд инструментальных средств, с помощью которых оператор имеет возможность создать ответ для передачи его по электронной почте, перевести «вызов» в режим удержания для наведения справки у других операторов контакт-центра или переправить «вызов» другому оператору, считающемуся специалистом в данной области. Во время выполнения всех этих действий оператор, который обслуживает вызов, поступивший в виде электронного письма, считается занятым, и другие вызовы поступать к его рабочему месту не могут. Более того, запросы, альтернативные речевым, обязательно учитываются при оценке общего обрабатываемого трафика, при динамиче-
ском управлении очередями запросов, при генерации подробных отчётов о работе системы.
В контакт-центре появляется ряд новых возможностей, доступных абоненту во время ожидания обслуживания, т.е. пока его вызов находится в очереди. Традиционно при ожидании освобождения занятого оператора абоненты слышат музыку, рекламные объявления, а также периодически получают уведомление о продвижении очереди. Если же клиент «попал» в контакт-центр с Web-страницы, то он, во-первых, может продолжать просматривать информацию на сайте компании, находясь в очереди, а во-вторых, получает еще целый ряд интересных возможностей. Так, если вызов не может быть установлен на ожидание из-за отсутствия свободных ресурсов шлюза IP- телефонии, приложение выдaётWeb-cтpaницy с извинениями за отказ в обслуживании и с просьбой к пользователю повторить вызов попозже или с предложением альтернативного варианта связи.
Приведем пример того, как эта функция может быть реализована в контакт-центре eBridge. С помощью услуги, называемой MultiHold, клиенты могут получать во время ожидания разнообразную мультимедийную информацию: например, в окне их браузера может обеспечиваться отображение ряда Web-страниц, или они могут получать звуковые объявления. Посредством интеллектуальных сценариев обработки вызова, написанных на языке Visual Basic или Java, предоставление такой информации может быть организовано разными способами в зависимости от потребностей клиента и от его действий при просмотре предлагаемой информации. В некоторых случаях возможна передача клиентам ответов до подключения оператора с использованием подсистемы IVR, что существенно повышает эффективность работы центра и сохраняет дорогостоящее рабочее время операторов.
Еще одна возможность контакт-центра - в качестве опции предложить своим клиентам всплывающее окошко, в котором содержится уведомление об установке вызова на ожидание. В случае, если все ресурсы центра уже заняты, в этом окошке всплывает извинение и просьба связаться с сотрудниками компании через определенный промежуток времени.
Можно также распределять вызовы с учетом коэффициента квалификации оператора (skill based routing); при этом подсистема маршрутизации вызовов, помимо сведений о вызываемой службе, по которым определяется характер запроса, накапливает и учитывает данные о типе запроса.
Использование открытых систем, взаимодействующих на базе протокола TCP/IR позволяет существенно упростить внедрение но-
вых приложений, связанных с применением таких современных технологий, как IP-телефония, автоматическое распознавание речи (ASR) и синтез речи (TTS). Это поднимает на качественно новый уровень функциональные возможности подсистем IVR и существенно расширяет перечень видов информации, которая может быть предоставлена клиенту без помощи оператора. В частности, в совокупности с технологией XML, синтез речи позволяет «озвучивать» Web- страницы, те. по определенным правилам произносить клиенту вслух их содержимое.
Коллективный обмен данными включает в себя совместное редактирование растровых изображений (электронная «доска объявлений»), передачу файлов, обмен текстовыми сообщениями («текстовая беседа») и дистанционное управление приложениями. Некоторые из этих функций входят в состав услуг справочного стола. Возможность дистанционного управления приложениями позволяет оператору справочного стола выполнять определённые действия на компьютере пользователя, например, инициировать диагностическую программу для программного драйвера. Посредством передачи файлов можно загрузить и инсталлировать в PC пользователя программную вставку. Эти действия должны быть согласованы с пользователем, но он может легко остановить их выполнение, нажав на аварийную кнопку.
Для повышения дохода компании, организующей контакт-центр, сценарии работы с клиентами могут модифицироваться (включая и постоянное сопровождение пользователей в диалоговом режиме). Пользователям может предоставляться информация о появляющихся новинках, оказываться помощь при разрешении спорных ситуаций и др. Этот инструментарий также оптимизирует механизмы анализа результатов проводимых кампаний телемаркетинга.
Например, посетителям Web-сайта требуется информация, которую желательно предоставить в форме электронной почты или факса, а не в устной форме по телефону. Для таких случаев приложение контакт-центра может заде йство вать ряд встроенных инструментальных средств обработки сообщений, включая шаблоны, позволяющие агенту быстро создать персональное сообщение электронной почты. Агент может, «удерживая» сообщение, навести справки у других агентов своего операторского центра или переадресовать это сообщение более компетентному агенту. В некоторых контакт-центрах реализованы системы автоматического ответа по факсу, в частности, системы с возможностью передавать факсы через Интернет в качестве вложений в электронную почту.
Использование единой сети для обслуживания речевого трафика и трафика данных между компонентами контакт-центра позволяет
существенно повысить уровень интеграции «операторской» и «информационной» подсистем центра. Появляется возможность использовать приложения, на базе которых станет реальностью работа с клиентами через Web-узлы (совместный направляющий просмотр страниц, заполнение форм и многие другие приятные мелочи, о которых уже говорилось выше).
Включение интегрированных контакт-центров в корпоративные IP- сети позволит создавать распределенные системы, которые не только смогут принимать и обрабатывать вызовы, поступающие из любой точки глобальной телекоммуникационной сети, но и дадут возможность агентам (операторам) организовывать свои рабочие места в любой точке этой сети. При этом наиболее эффективной с экономической точки зрения будет маршрутизация речевого трафика по сетям с коммутацией пакетов.
8.5 Безопасность
Очень важная группа задач, которые должны быть решены при построении HHTerpnpoBaHHbixWeb-KOHTaKT-ueHTpoB, связана с вопросами безопасности. Об этом сейчас много пишется в соответствую- щихспециализированных изданиях, поэтому, не углубляясь в технические подробности, обозначим основные задачи и методы их решения. Обеспечение безопасности, в общем случае, сводится к решению двух основных задач:
сохранение конфиденциальности информации, которой обмениваются клиенты с контакт-центром через сеть Интернет;
обеспечение защиты контакт-центра от несанкционированного доступа со стороны сети Интернет.
Решение первой задачи дает применение разнообразных защи- щенных протоколов обмена данными и кодирование информации. Что же касается несанкционированного доступа, то защитой от него является брандмауэр (firewall) с набором расширенных возможностей и поддерживаемых протоколов (главным образом, в части поддержки протоколов IP-телефонии и возможностей маршрутизации IP-трафика тех или иныхтипов). Брандмауэр является встроенным в контакт-центр компьютером, маршрутизатором или другим устройством, просеивающим требования доступа. Основной принцип его функционирования прост - пакеты, поступающие из подозрительного источника, блокируются, а пакеты из известных и проверенных источников (как это определяется локальной стратегией безопасности) проходят свободно. Брандмауэр для защиты контакт-центра, как правило, состоит из единственного устройства -
защитного экрана, обеспечивающего безопасность, аудит и мониторинг трафика и отслежи в ающего попытки взлома (break-in attempts).
Подобно компьютерной (пакетной) составляющей контакт-цен- тра, телефонная составляющая тоже может потребовать выявления всех, кто пытается получить несанкционированный доступ к контакт- центру или воспользоваться неразрешенными услугами. Для этого в контакт-центр ПРОТЕЙ, например, можно встраивать систему просеивания телефонных вызовов ЦЕРБЕР (телефонный экран на базе платформы ПРОТЕЙ). Такого рода система (рис.8.5) может применяться и вне связи с Call-центрами, например, для контроля базовым оператором пропускаемого транзитного трафика присоединяемых операторов связи, а также для предотвращения несанкционированного доступа к услугам связи. Так например, нередко бывает, что коммерческий оператор, подключ и в У ПАТ С к сети базового оператора, пропускает в сеть IP-телефонии транзитный трафик, ничего не отчисляя базовому оператору. При обнаружении входящего вызова анализируется номер вызываемой службы контакт-центра и номер вызывающего абонента. В зависимости от прав доступа этого абонента, его вызов либо обслуживается, либо получает отказ с передачей абоненту соответствующей фразы автоинформатора. При использовании алгоритма «черного списка» вызов получает отказ, если номер вызывающего абонента обнаружен в списке номеров, обслуживание которых запрещено. Если обслуживание данного номера разрешено, анализируется номер вызываемого абонента и определяется требуемое для связи логическое направление. Если вызывающему абоненту (его номеру или категории) разрешен доступ к этому логическому направлению, устанавливается соединение, в противном случае происходит отказ в обслуживании с передачей абоненту соответствующего акустического сигнала или фразы автоинформатора. В системе ЦЕРБЕР обеспечивается полный учет прошедших через нее вызовов, как обслуженных, так и тех, которым в обслуживании было отказано. Для каждого вызова фиксируется дата/ время поступления, результат обработки (обслуживание/отказ), номер вызывающего абонента, номер службы контакт-центра, длительность обслуживания. Интерфейсный блок подсистемы ЦЕРБЕР выполнен на основе и ндустр и ал ьн о го PC-совместимого компьютера, в корпус которого устанавливаются плата центрального процессора и специализированные платы, формирующие интерфейс ИКМ-30 (до 4-х ИКМ-трактов на один модуль ТСМ) и поддерживающие функции коммутации, генерации сообщений автоинформатора, а также функции обработки сигнализации под управлением программного обеспечения.
ЛВС
Рабочее место
оператора
ITS
Серверы приложений
Рис. 8.5 Подсистема информационной безопасности ЦЕРБЕР в контакт-центре ПРОТЕЙ
8・6 Клиентская база данных
При обслуживании вызовов оператор использует информацию, накопленную в клиентской базе данных компании с использованием технологий CTI, для идентификации вызывающего абонента. Благодаря этому оператор может, например, проверить состояние текущего счёта, или получить другую информацию о клиенте, хранящуюся в этой базе данных и позволяющую оператору предугадать требования или пожелания клиента и более эффективно обработать запрос. Если информация о клиенте отсутствует, то она обязательно будет создана по завершении обслуживания вызова. При дальнейшей работе с клиентом данные о нем будут обновляться. При доступе клиента в контакт-центр с Web-страницы спектр данных, которые клиент может сообщить о себе перед тем, как будет установлено соединение с оператором, существенно расширяется, что может значительно повысить эффективность взаимодействия клиент-оператор.
8.7 Архитектура контакт-центра
8-7.1 Два архитектурных стиля
В предыдущих параграфах этой плавы рассматривались задачи, которые должны быть реализованы контакт-центром:
обеспечение широкого спектра возможностей, как в плане доступа, так и сточки зрения услуг; предоставляемых с использованием человеческих ресурсов (операторов) и автоматизированных систем;
гарантированная обработка транзакций всех типов вне зависимости от источника вызова и от метода доступа к ресурсам контакт- центра;
обеспечение возможности интеграции с существую щи м и операторскими центрами и дооснащения их необходимыми функциями с применением оборудования сторонних производителей за счет использования открытых стандартов при построении систем.
Оптимальной технологией для решения этих задач является IP Чтобы доказать этот тезис, приведем ряд аргументов.
Как было отмечено в предыдущей главе, традиционные операторские центры (Call-центры, обрабатывающие только телефонные вызовы) строились, главным образом, с использованием специализированного оборудования СРВ, рассмотренного в главе 6, или на базе УАТС, дооснащенных специализированным программным обеспечением для автоматического распределения вызовов. Внеш-
ние компьютерные системы (базы данных CRM - customer relationship management и т.д.) соединялись с процессором СРВ посредством соответствующих интерфейсов (например, описанного в главе 3 интерфейса TAPI). В определенный момент функциональных возможностей Call-центров стало не хватать, и потребовалась поддержка взаимодействия оборудования не только с ТфОП, но и с сетями передачи данных. К существующему Call-центру было добавлено необходимое программное и аппаратное обеспечение, не связанное напрямую с СРВ. Такая архитектура содержит две отдельные части: телефонную и компьютерную, программное обеспечение которой отвечает за взаимодействие с другими сетями. Техническое обслуживание двух разных инфраструктур в телекоммуникационных сетях зачастую оказывается довольно дорогим, оно не всегда надежно и ставит определенные препятствия к интеграции коммуникаций различных типов.
Однако именно по такому пути пошли компании, которые уже имели к началу эпохи интеграции мощные Call-центры, построенные на базе СРВ, и которым было бы просто неразумно не использовать уже имеющийся потенциал. Речь идет, например, о таких признанных лидерах телекоммуникационного рынка, как AVAYA, Nortel, Siemens, Alcatel. Архитектуру их контакт-центров можно обобщенно представить следующей схемой:
Рис. 8.6 Типовая структура контакт-центра, построенного на базе УПАТС с функциями СРВ
Роль коммутационного ядра, как и в системах обычных операторских центров обслуживания вызовов, в этом случае берет на себя учрежденческая станция с функциями СРВ или специализированная СРВ с соответствующими функциями.
Например, оборудование CentreVu Internet Solutions разработки AVAfA работает совместно с Definity Ecs и с системой автоматического распределения вызовов Definity G3. Для реализации полного набора услуп присущего интегрированным контакт-центрам, оборудование CentreVu Inernet Solutions содержит пакет программного обеспечения операторского центра, включая: специальное ПО поддержки агентов (Expert Agent Software, EAS); шлюз IP-телефонии (ITG); программное обеспечение прикладного интерфейса с коммутатором (ASAI); Java-приложение обработки вызова; систему управления обслуживанием вызовов CentreVu; Web-сервер, который предоставляется заказчиком корпорации.
В то же время, компании, начинающие разработки контакт-цен- тров «с чистого листа» (или просто более смелые технически), повели себя при выборе архитектуры более свободно. И именно они получили в полной мере преимущества, возникающие при реализации систем на принципах пакетной коммутации. В качестве примеров приведем разработки мирового телекоммуникационного лидера CISCO Systems и отечественный контакт-центр ПРОТЕЙ.
Технологии пакетной коммутации позволяют в принципе отказаться от громоздкого коммутатора каналов, возложив функции коммутации на саму сеть с использованием возможностей протокола IP как универсального протокола транспортного уровня. В этом случае функции коммутации разговорных каналов сводятся к управлению медиа-потоками между определенными узлами компьютерной сети. Все функциональные возможности реализуются компьютерными серверами приложений, работающими суправляющей информацией и медиа-потоками (если необходимо) и взаимодействующими в процессе обслуживания вызова с информационными и технологическими базами данных. При этом каждый изтакихсер- веров отвечает за свой набор услуг (сервер СРВ, сервер IVR и др.). Таким же образом решаются вопросы надежности (стандартные методы резервирования аппаратного обеспечения компьютерной техники), масштабирования (установка, при необходимости, дополнительных серверов, работающих в режиме разделения нагрузки), введения новых функций (дополнительные серверы и приложения), создания распределенных систем (для этого достаточно связать разные офисы одной компьютерной сетью, обладающей нужной пропускной способностью).
Ядром систем такого рода является программный продукт, управляющий очередями и маршрутизацией вызовов. В состав системы входят также: периферийные шлюзы, которые обеспечивают взаимодействие компонентов системы и прием и обработку вызовов, по-
ступающих из разных сетей, серверы приложений и серверы баз данных, функции которых будут рассмотрены чуть ниже.
Нельзя забывать, что эволюция центров обслуживания вызовов оттрадиционных Call-центров, ориентированных на коммутацию каналов и автоматическое распределение вызовов, к современным контакт-центрам интересна не сама по себе, а как процесс, сопряженный с улучшением качества обслуживания клиентов, с расширением спектра предоставляемых услуг и, как следствие, - с повышением дохода компаний.
Как отмечено в [5], применение IP-технологий позволяет легко связать телефонный вызов с информацией о нем. Эта связь чрезвычайно важна для контакт-центров, именно она делает эффективной обработку вызовов из разных сред и обеспечивает необходимое качество обслуживания. Если принять во внимание и другие преимущества IP-контакт-центров, в том числе, низкую стоимость развертывания и эффективность масштабирования, привлекательность использования в контакт-центрах пакетной коммутации становится очевидной. Таблица 8.1 и л л юстри рует два рассмотренных выше подхода к построению интегрированных операторских центров.
Таблица 8.1.
Характеристики традиционных Call-центров
Характеристики 1Р-контакт- центра нового поколения
Преимущества с точки зрения компании, эксплуатирующей систему
Коммутация каналов
Коммутация пакетов
Более эффективная передача трафика, не требуется дорогостоящее оборудование для поддержки коммутации каналов
Поддержка одной среды для доступа к услугам
Поддержка всех сред для доступа к услугам
Широкие возможности с точки зрения доступа
Большое количество серверов приложений - отдельный сервер для каждого приложения
Число серверов зависит от их производительности и функциональных возможностей
Легкость развертывания и управления, низкая стоимость
Различные алгоритмы обслуживания вызовов разных типов
Единый алгоритм обслуживания вызовов всех типов
Выше качество обслуживания и эффективность работы операторов
Централизованная обработка трафика
Распределенная обработка трафика
Гибкость конфигурации, надежность
Жесткая привязка местоположения операторских консолей к местоположению системы
Независимость местоположения операторских консолей от местоположения системы
Возможность поддержки удаленных рабочих мест операторов, предоставления услуг аутсорсинга
Компьютерно-телефонная интеграция (интегрированные функциональные возможности)
Взаимодействие компьютер-компьютер (унифицированные функциональные возможности)
Дешевле интеграция услуг; меньше сроки реализации комплексных решений; слияние функций обработки речевого трафика и информационных технологий обеспечивает возможность быстрого и экономически эффективного развития
ТСМ"ТСМ"тракты Е1 (ТфОП)тракты Е1 (ТфОП)Ethernet100 Base-T/GigabitEthernet100 Base-T/Gigabit100 BaseT (Internet)100 BaseT (Internet):WEB- сервер/:Proxy:WEB- сервер/:Proxy
ТСМ"
ТСМ"
тракты Е1 (ТфОП)
тракты Е1 (ТфОП)
Ethernet100 Base-T/Gigabit
Ethernet100 Base-T/Gigabit
100 BaseT (Internet)
100 BaseT (Internet)
:WEB- сервер/
:Proxy
:WEB- сервер/
:Proxy
Прокомментируем таблицу. В операторских центрах на базе традиционных СРВ рабочие места операторов физически подсоединены к фиксированным портам коммутационного оборудования, возможности их размещения жестко ограничены, и организация распределенной системы (с поддержкой, например, удаленных рабочих мест) существенно затруднена. В то же время, виртуальная природа IP-адресации в современных контакт-центрах позволяет легко решить эти проблемы. Оператор может зарегистрироваться на любом терминале и при этом он будет распознан системой как уникальный агент, обладающий определенной квалификацией. Очевидны преимущества контакт-центра с точки зрения затрат на организацию удаленных рабочих мест, а также с точки зрения возможностей предоставления компанией-владельцем такого центра услуг аутсорсинга (т.е. предоставления ресурсов контакт-центра в аренду сторонним фирмам), которые сегодня являются неплохим источником дохода для многих операторских компаний.
Современные контакт-центры базируются на IP-технологиях и решениях компьютерной телефонии третьего поколения, а не на громоздких CTI-интерфейсах и классических коммутационных платформах, чем и объясняются их преимущества, отмеченные в таблице 8.1. Программное обеспечение оператора (агента) контакт-центра является компактным программным продуктом и, как правило, пишется на языке Java или ActiveX, обеспечивая хорошие возможности интеграции с информационными базами данных, используемыми в операторском центре. Контакт-центр, реализованный на базе IP-технологий, состоит из функциональныхэлементов нескольких типов, одни из которых могут быть программно-аппаратными блоками, а другие - чисто программными продуктами. Обобщенная архитектура контакт- центра на базе IP представлена на рис.8.6.
Г" Серверы приложенийГ" Серверы приложений「 Интерфейсные「 модули — I
Г" Серверы приложений
Г" Серверы приложений
Рассмотрим функции показанных на рис.8.7 блоков.
8-7.2 Шлюз 1Р-телефонии
Важнейшим элементом интегрированного с Интернет контакт- центра является шлюз, который обеспечивает взаимодействие между сетью с коммутацией пакетов IP и телефонной сетью с коммутацией каналов. Шлюз представляет собой программно-аппаратный комплекс, основным функциональным назначением которого является преобразование речевой информации, поступающей со стороны ТфОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковка речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование. Еще одна функция - преобразование номера ТфОП в 1Р-адрес - реализуется в шлюзах для работы в сети IP-телефонии без привратника. Кроме того, шлюз поддерживает обмен сигнальными сообщениями как с узлами коммутации/терминальным оборудованием ТфОП, так и с устройствами, работающими по стандартам 1Р-телефонии Н.323 и/или SIR
Шлюз преобразует межстанционную сигнализацию по трактам Е1 一 сообщения систем сигнализации DSS1, ОКС7, 2ВСК - или сигнализацию по абонентским линиям [4] в сигнальные сообщения набора протоколов Н.323 (в этом случае сообщения систем сигнализации DSS1, QS1G, основанных на Q.931, преобразуются в сигнальные сообщения Н.225.0 согласно рекомендации ITU-T Н.246) или в протокол SIP
Санкционирование доступа (если это необходимо), получение номера вызываемого абонента и навигация по меню системы IVR могут производиться либо на основании обработки соответствующих полей протокола Н.323, либо при помощи сигналов DTMF. Для реализации последней функции шлюз, используемый в контакт-цен- трах такого типа, должен умеет генерировать и распознавать сигналы DTMF на стороне ТфОП, а также передавать сигналы DTMF в сообщениях Н.245 по сети с маршрутизацией пакетов IP
Несколько шлюзов, обслуживающий один контакт-центр, могут объединяться в сеть под управлением привратника GK, что позволяет обслуживать десятки потоков Е1.
8.7.3 Серверы приложений
Серверы приложений обеспечивают реализацию логики предоставляемых услуг Применительно к операторским центрам можно выделить два базовых типа приложений, которые должны поддерживаться для того, чтобы система была полнофункциональной и удовлетворяла требованиям, о которых говорилось выше: интерактивное речевое взаимодействие и распределение вызовов.
Сервер интерактивного речевого взаимодействия 1VR выполняет все функции, связанные с организацией компьютерного диалога с абонентом, который обратился в контакт-центр. Это и передача абоненту речевых подсказок-приглашений, и прием от абонента дополнительной информации в режиме многочастотного донабора, и передача абоненту в автоматическом режиме разного рода справочной и сервисной информации, и поддержка функций синтеза речи, и многие другие функции, реализуемые современными 1VR, которые подробно рассматривались в главе 4. Функциональных отличий от обычных систем IVR этот элемент контакт-центра не имеет, но его фундаментальной технологической особенностью является передача и прием всей речевой информации в пакетном виде через сеть IR посредством которой он и связан с остальными подсистемами контакт-центра. Необходимость взаимодействовать с телефонной сетью и с Интернет при обработке запросов речевой связи требует поддержки различных кодеков, динамически подключаемых в зависимости от типа входящего вызова, поскольку передача несжатой речи (G.711) при обслуживании вызовов из ТфОП обеспечивает высокое качество воспроизведения звука, а применение эффективных алгоритмов кодирования (G.729) при обслуживании вызовов из Интернет- высокое использование полосы пропускания.
Сервер распределения вызовов СРВ является ключевым элементом контакт-центра. Динамически в за и модейству я с базами данных в процессе обслуживания вызовов, он обеспечивает поддержку систем очередей и функций маршрутизации вызовов, поступающих в контакт-центр.
8-7-4 Базы данных
Базы данных операторского центра хранят информацию о конфигурации системы, статистические данные о ее функционировании, данные учета и т.д.
8-7_5 Сервер эксплуатационного управления
Сервер/терминал эксплуатационного управления фактически представляет собой обычный персональный компьютер (рабочее место администратора системы) со специализированным программным обеспечением. С его помощью выполняются функции конфигурирования и диагностики системы, контроль состояния интерфейсов и разговорных каналов, сбор оперативной и статистической информации о работе системы и об обслуживании вызовов, а также генерация отчетов и архивация.
В качестве подхода к организации системы эксплуатационного управления обычно используется идеология «тонкого клиента» и доступа nepeaWWW. Помимо возможностей удобно настраивать графи-
ческий интерфейс, преимуществом такого подхода является и то, что единственным требованием к клиентскому рабочему месту администратора является наличие Web-браузера с поддержкой Java, например, Internet Explorer. Данный подход позволяет легко адаптировать систему управления к нуждам конкретного заказчика и получить большой набор функциональных возможностей и удобные механизмы для выполнения операций техобслуживания, а также удобную возможность организации удаленных рабочих мест.
Q ®Q ®пинФамилия и.о.сост.ДЛИТ.абонент© оое...Pioneeraff 8 RRREAD...Й009...Pioneeroff 9 P.P.BUSY...00:01:29CM_22 [tz...Йою...Pioneeroff 10 RP.BUSY...00:01:27CM 22 ftz...5Йо11...Pioneeroff 11 RRBUSY...00:01:19CM 22 [tz...阻52…Pioneeroff 12 P.P.BUSY...00:01:05CM 22 [tz...新13…Pioneeroff 13 P.P.BUSY...00:01:03CM 22 [tz...5^014...Pioneeroff 14 P.P.BUSY...00:00:59CM_22 [tz...015Pioneeroff 15 P PBUSY .00 00:27CM_22hz .S^O1B...pioneeroff 1G P.P.BUSY...00:00:17CM_22 [tz...S^017...Pioneeroff 17 P.P.BUSY...00:00:05CM_23 [tz..詠IB…Pioneeioff 1BP.P.BUSY...00:00:49CM_22 [tz...^019...Pioneeroff 19P.P.BUSY...00:00:47CM_22 (tz..5^020...Pioneeroff 20 P.P.BUSY...00:00:09CM_22 [tz...5^021...Pioneeroff 21 P.P.BUSY...00:00:45CM 22 [tz...® 022...Pioneeroff 22 P.P.READ...C 023...Pioneeroff 23 P.P.READ...8 024...Pioneeroff 24 P.P.READ...0底…Pioneeroff 25 P.P.READ...С02Б...Pioneeroff 26 P.P.READ...0 027...Pioneeroff 27 RRREAD...? 028...Pioneeroff 28 RRREAD...8 029...Pioneeroff 29 P.P.READ...静晒…pioneeroff 30 P.P.BUSY...00:00:33CM 22 [tz...氯111…Иванов И.И.LOCK...X 112...Петров П.П.NULL...X114...Сидоров С. С.NULL...X 117...出 ахметов М.С.NULL...異 155..Семенов Ю.Н.пинФамилия и.о.сост.ДЛИТ.абонент© оое...Pioneeraff 8 RRREAD...Й009...Pioneeroff 9 P.P.BUSY...00:01:29CM_22 [tz...Йою...Pioneeroff 10 RP.BUSY...00:01:27CM 22 ftz...5Йо11...Pioneeroff 11 RRBUSY...00:01:19CM 22 [tz...阻52…Pioneeroff 12 P.P.BUSY...00:01:05CM 22 [tz...新13…Pioneeroff 13 P.P.BUSY...00:01:03CM 22 [tz...5^014...Pioneeroff 14 P.P.BUSY...00:00:59CM_22 [tz...015Pioneeroff 15 P PBUSY .00 00:27CM_22hz .S^O1B...pioneeroff 1G P.P.BUSY...00:00:17CM_22 [tz...S^017...Pioneeroff 17 P.P.BUSY...00:00:05CM_23 [tz..詠IB…Pioneeioff 1BP.P.BUSY...00:00:49CM_22 [tz...^019...Pioneeroff 19P.P.BUSY...00:00:47CM_22 (tz..5^020...Pioneeroff 20 P.P.BUSY...00:00:09CM_22 [tz...5^021...Pioneeroff 21 P.P.BUSY...00:00:45CM 22 [tz...® 022...Pioneeroff 22 P.P.READ...C 023...Pioneeroff 23 P.P.READ...8 024...Pioneeroff 24 P.P.READ...0底…Pioneeroff 25 P.P.READ...С02Б...Pioneeroff 26 P.P.READ...0 027...Pioneeroff 27 RRREAD...? 028...Pioneeroff 28 RRREAD...8 029...Pioneeroff 29 P.P.READ...静晒…pioneeroff 30 P.P.BUSY...00:00:33CM 22 [tz...氯111…Иванов И.И.LOCK...X 112...Петров П.П.NULL...X114...Сидоров С. С.NULL...X 117...出 ахметов М.С.NULL...異 155..Семенов Ю.Н.[завершитьеззов ][завершитьеззов ]LabelLabelсделать вазое ] | проссузать] [- вкмчить запись ]сделать вазое ] | проссузать] [- вкмчить запись ]выходвыходТерминал Старшего Оператора
Q ®
Q ®
пин
Фамилия и.о.
сост.
ДЛИТ.
абонент
© оое...
Pioneeraff 8 RR
READ...
Й009...
Pioneeroff 9 P.P.
BUSY...
00:01:29
CM_22 [tz...
Йою...
Pioneeroff 10 RP.
BUSY...
00:01:27
CM 22 ftz...
5Йо11...
Pioneeroff 11 RR
BUSY...
00:01:19
CM 22 [tz...
阻52…
Pioneeroff 12 P.P.
BUSY...
00:01:05
CM 22 [tz...
新13…
Pioneeroff 13 P.P.
BUSY...
00:01:03
CM 22 [tz...
5^014...
Pioneeroff 14 P.P.
BUSY...
00:00:59
CM_22 [tz...
015
Pioneeroff 15 P P
BUSY .
00 00:27
CM_22hz .
S^O1B...
pioneeroff 1G P.P.
BUSY...
00:00:17
CM_22 [tz...
S^017...
Pioneeroff 17 P.P.
BUSY...
00:00:05
CM_23 [tz..
詠IB…
Pioneeioff 1BP.P.
BUSY...
00:00:49
CM_22 [tz...
^019...
Pioneeroff 19P.P.
BUSY...
00:00:47
CM_22 (tz..
5^020...
Pioneeroff 20 P.P.
BUSY...
00:00:09
CM_22 [tz...
5^021...
Pioneeroff 21 P.P.
BUSY...
00:00:45
CM 22 [tz...
® 022...
Pioneeroff 22 P.P.
READ...
C 023...
Pioneeroff 23 P.P.
READ...
8 024...
Pioneeroff 24 P.P.
READ...
0底…
Pioneeroff 25 P.P.
READ...
С02Б...
Pioneeroff 26 P.P.
READ...
0 027...
Pioneeroff 27 RR
READ...
? 028...
Pioneeroff 28 RR
READ...
8 029...
Pioneeroff 29 P.P.
READ...
静晒…
pioneeroff 30 P.P.
BUSY...
00:00:33
CM 22 [tz...
氯111…
Иванов И.И.
LOCK...
X 112...
Петров П.П.
NULL...
X114...
Сидоров С. С.
NULL...
X 117...
出 ахметов М.С.
NULL...
異 155..
Семенов Ю.Н.
пин
Фамилия и.о.
сост.
ДЛИТ.
абонент
© оое...
Pioneeraff 8 RR
READ...
Й009...
Pioneeroff 9 P.P.
BUSY...
00:01:29
CM_22 [tz...
Йою...
Pioneeroff 10 RP.
BUSY...
00:01:27
CM 22 ftz...
5Йо11...
Pioneeroff 11 RR
BUSY...
00:01:19
CM 22 [tz...
阻52…
Pioneeroff 12 P.P.
BUSY...
00:01:05
CM 22 [tz...
新13…
Pioneeroff 13 P.P.
BUSY...
00:01:03
CM 22 [tz...
5^014...
Pioneeroff 14 P.P.
BUSY...
00:00:59
CM_22 [tz...
015
Pioneeroff 15 P P
BUSY .
00 00:27
CM_22hz .
S^O1B...
pioneeroff 1G P.P.
BUSY...
00:00:17
CM_22 [tz...
S^017...
Pioneeroff 17 P.P.
BUSY...
00:00:05
CM_23 [tz..
詠IB…
Pioneeioff 1BP.P.
BUSY...
00:00:49
CM_22 [tz...
^019...
Pioneeroff 19P.P.
BUSY...
00:00:47
CM_22 (tz..
5^020...
Pioneeroff 20 P.P.
BUSY...
00:00:09
CM_22 [tz...
5^021...
Pioneeroff 21 P.P.
BUSY...
00:00:45
CM 22 [tz...
® 022...
Pioneeroff 22 P.P.
READ...
C 023...
Pioneeroff 23 P.P.
READ...
8 024...
Pioneeroff 24 P.P.
READ...
0底…
Pioneeroff 25 P.P.
READ...
С02Б...
Pioneeroff 26 P.P.
READ...
0 027...
Pioneeroff 27 RR
READ...
? 028...
Pioneeroff 28 RR
READ...
8 029...
Pioneeroff 29 P.P.
READ...
静晒…
pioneeroff 30 P.P.
BUSY...
00:00:33
CM 22 [tz...
氯111…
Иванов И.И.
LOCK...
X 112...
Петров П.П.
NULL...
X114...
Сидоров С. С.
NULL...
X 117...
出 ахметов М.С.
NULL...
異 155..
Семенов Ю.Н.
[завершитьеззов ]
[завершитьеззов ]
Label
Label
сделать вазое ] | проссузать] [- вкмчить запись ]
сделать вазое ] | проссузать] [- вкмчить запись ]
выход
выход
Рис. 8.8 Пример экранной формы на рабочем местестаршего оператора контакт-центра ПРОТЕЙ
8-7.6 Рабочие места операторов
Консоли операторов организуются на базе стандартных персональных компьютеров с установленным специализированным клиентским программным обеспечением (или Web-браузером). Дополнительная оснастка рабочего места зависит от того, какая технология используется внутри операторского центра для передачи речевого трафика. Если две сети - компьютерная и телефонная - существуют независимо, а роль речевого коммутатора выполняет СРВ, то никакого дополнительного оборудования не требуется. Телефонные вызовы в этом случае будут трад и цио н н ы м способом поступать на консоль (телефонный аппарат) оператора, включенную в СРВ по
абонентским линиям, а информация о вызове - на персональный компьютер через интерфейс CTI.
Если же в операторском центре используется полностью интегрированное решение на базе протокола IP (т.е. существует только одна сеть - компьютерная), то оператору не требуется никакой телефонной консоли, но его рабочее место необходимо дооснастить мультимедийными средствами - звуковой картой, гарнитурой или колонками и т.д. Речевая информация в этом случае передается в пакетном виде с использованием кодировки G.711 или G.729. Для поддержки кодека G.711 (несжатая речь 64 Кбит/с) подходит стандартная звуковая карта, а вся математическая обработка сигнала происходит в материнской плате. Если же на компьютере рабочего места оператора требуется поддержка кодеков G.729, то, как правило, необходима установка специализированной звуковой карты (например, QuickNet), т.к. на поддержку этих кодеков требуется значительный расход вычислительной мощности.
8-7.7 PROXY-сервер для доступа из Интернет
Основная функция этого устройства в интегрированном контакт- центре - сокрытие структуры узла IP-телефонии от удаленных компьютеров, которые должны «видеть» контакт-центр как единый сервер с одним IP-адресом (предполагается, что функции защиты сети от хакерских атак и несанкционированного доступа извне выполняются рассмотренными выше средствами брандмауера, например, межсетевым экраном ЦЕРБЕР).
При использовании конфигурации операторского центра с несколькими модулями СРВ, работающими в режиме разделения нагрузки, на PROXY возлагается также задача равномерного распределения между этими модулями потока вызовов, поступающих из Интернет,. Во всех случаях PROXY может быть физически совмещен с Web-сервером.
«8 Оборудование пользователя
Посетителям Web-сайтов не требуется иметь никакого специального оборудования, кроме того, которое имеется в стандартном наборе компонентов персонального мультимедийного компьютера (звуковая карта).
Из программного обеспечения нужны: любая программадля поддержки IP-телефонии (Microsoft NetMeeting 2.0 или выше, Open Phone и др.) и Web-браузер, например, Microsoft Internet Explorer 4.0 или выше, с поддержкой Java.
Что касается интерфейса, то это может быть аналоговая телефонная линия, линия ISDN или локальная сеть. К пропускной способности аналоговых линий требования примерно следующие: скорость
модемного соединения с Интернет-поставщиком должна быть не меньше 14,4 Кбит/с для текстового чата, или не меньше 28,8 Кбит/с для поддержки услуги VoIR
Административное управление работой контакт-центра
Вопросы административного управления в интегрированном кон- такт-центре совершенно аналогичны вопросам такого же управления в традиционном операторском центре, в особенности, если контакт-центр интегрирован в существующий режим функционирования. В целом, административное управление включает в себя управление данными, управление обработкой вызовов, управление транзакциями и управление персоналом.
Управление данными 一 способность системы собирать, сортировать и хранить информацию о посетителях Web-сайтов и о заказчиках, которая используется для маршрутизации вызовов к наиболее подходящему оператору центра. Вне зависимости от того, в какой форме поступает запрос от клиента, вся информация, относящаяся к данному вызову, собирается и хранится в базе данных. В этой базе хранится вся информация о пользователях, включая номер и версию Web-браузера посетителя, IP-адрес, номер соответствующей Web- страницы и т.д. Кроме того, Java-приложение может использоваться для запроса идентификатора и пароля пользователя, а Web-формы могут использоваться для запроса специфической информации о пользователе.
Для эффективного сбора информации о пользователях применяются различные инструментальные средства. Например, компания Accrue Software предлагает свое ПО, называемое Insight, которое обеспечивает выдачу отчётов, детализирующих поведение пользователя на Web-сайте. Эта информация позволяет администраторам Web-сайтов и специалистам по маркетингу понять, как посетители перемещаются по сайтам, какая информация представляет для них интерес и насколько эффективно она им предоставляется. Insight формирует отчёты, которые показывают индивидуальные URL-адреса и определяет те места в Web, где посетители вошли в сайт и вышли из сайта. Отслеживание точек входа и выхода дает адм и нистраторам важные сведения о том, как пользователи перемещаются по сайту, какая информация на сайте их заинтересовала и просмотрели ли они перед тем, как покинуть сайт, такую важную информацию, как регистрационные страницы или страницы для совершения сделок. Информация, содержащаяся в этих отчётах, помогает компаниям определить их аудиторию, снизить затраты пользователей на приобретение товаров и более эффективно удерживать покупателей.
Какие бы средства ни использовались для сбора данных, вся информация направляется в базу данных, из которой она может быть извлечена, когда посетитель в очередной раз сделает запрос. Это позволяет операторам оперативно и точно реагировать на требования клиентов.
Эффективное управление обработкой вызовов позволяет реализовать оптимальную маршрутизацию. Это означает, что запросы любого вида будут маршрутизироваться к наиболее подходящему оператору, который обслужит запрос клиента с заданным качеством. В этом случае необходима информация, которая содержит все данные о предыдущих запросах клиента, если онибыли, а также о номере счета, номере телефона и т.д.
При конфигурировании системы администратор операторского центра может установить, какие операторы должны отвечать на вызовы, приходящие с определённых Web-страниц.
Применительно к запросам электронной почты, операторы объединяются в группы по областям специализации или сферам ответственности. Администраторы обычно могут очень гибко конфигурировать системудля обеспечения надлежащей маршрутизации сообщений электронной почты. Например, когда поступает сообщение, адресованное к laptop@domain.com, оно может быть направлено в очередь к операторам, обученным отвечать на вопросы о линии портативных компьютеров, которые производит компания. В дополнение к этому, системе может быть, к примеру, дано задание искать определённые ключевые слова в строке «Тема» заголовка сообщения, что может быть полезным для выделения запросов, относящихся к конкретному продукту, и для их последующей передачи к соответствующей группе специалистов по продаже или по технической поддержке.
Подсистемауправления транзакциями обеспечивает гибкий, почти в реальном времени, механизм контроля деятельности операторского центра и уведомления старшего оператора (супервизора) о наличии проблем. Например, коща число входящих вызовов достигает порогового значения, выдаются предупреждающие сообщения, так что имеется возможность отреагировать на ситуацию до того, как это почувствует на себе вызывающий пользователь. Могут выдаваться визуальные или акустические тревожные сообщения или предупреждения. Среди действий, которые могут выполняться автоматически, -перевод избыточного потока вызовов на обслуживание к старшим операторам и администраторам, а также передача вызывающим пользователям сообщений, информирующих их о том, что они получат ответ при первой возможности.
В ходе подобной автоматизированной процедуры принятия решений приложение администратора транзакций системы рассматривает такие факторы, как число работающих операторов, уровень
их квалификации, количество вызовов, находящихся в очереди, и вызовов, обслуживаемых в данный момент Эти возможности управления транзакциями позволяют интернетовскому контакт-центру не только обслуживать большее число вызовов без привлечения дополнительного персонала, но и более полно удовлетворять клиентов, поскольку вызовы обрабатываются быстрее.
Что касается работы с персоналом центра, то надо отметить, что в интегрированном контакт-центре, где вызовы из ТфОП и из Интернет часто обслуживаются одними и теми же операторами, каждый из них должен знать информацию, содержащуюся на Web-странице компании, знать, каким образом и в каких случаях нужно применять технологию принудительной рассылки информации путём её «выталкивания» (push technology), владеть навыками поиска и ответа на запросы в виде электронной почты и уметь производить, при необходимости, обратные вызовы.
При надлежащем функционировании операторского центра вызывающий абонент ожидает подключения к оператору не более 20 секунд. В течение этого отрезка времени оператор должен получить на экран всю имеющуюся о данном пользователе информацию. Поскольку такой режим работы может вызывать утомление и стрессы, адм инистраторы и старшие операторы операторских центров должны предусматривать несколько перерывов в работе каждого оператора в течение рабочего дня, следя за тем, чтобы при этом обеспечивалось нормальное обслуживания входящих вызовов. Обращаясь к отчётам о вызовах, менеджеры могут определить часы пиковой нагрузки, когда все операторы должны находиться на своих рабочих местах. Этому помогает специализированное программное обеспечение, отвечающее также за отчетность и за контроль функционирования контакт-центра.
Качество функционирования контакт-центра зависит от характера изменения нагрузки, от числа задействованных операторов, от задач, которые решает контакт-центр, и от многих других факторов. При этом, если поток вызовов, поступающих от ТфОП, можно предугадать и соответствую щи м образом настроить систему, то сколько вызовов придет в тот или иной момент из сети Интернет или по электронной почте, предугадать практически невозможно. Таким образом, необходимо постоянно контрол и ровать работу центра, изменяя, когда нужно, число операторов в той или иной группе, создавая новые направления, модифицируя алгоритмы обслуживания и т.д., что и требует мощной подсистемы адм ин истрати в - ного управления, позволяющей оперативно реагировать на изменения во внешней среде.
Отчеты в системе генерируются на основании статистических данных, накапливаемых в базе данных, и оперативных данных, которые фиксируются не только по окончании обслуживания вызова, но и в хо-
де его обслуживания. Статистические данные, в свою очередь, накапливаются по вызовам и по клиентам, обращающимся в центр. Создается также удобный графический интерфейс, наглядно показывающий сложившуюся ситуацию.
Система должна отслеживать в реальном времени следующую оперативную информацию:
число вызовов в очереди;
длительность пребывания в очереди каждого вызова;
продолжительность разговора;
процент вызовов, обслуженных в течение заданного интервала времени;
среднюю длина интервала времени, по истечении которого абонент кладет трубку, не дождавшись ответа;
число свободных операторов;
причины отсутствия операторов на рабочем месте;
другую информацию по желанию заказчика.
При поступлении вызова может фиксироваться следующая информация:
тип вызова;
время поступления вызова;
время завершения сеанса связи;
длительность ожидания обслуживания;
продолжител ьность разговора;
стоимость разговора;
номер оператора, обслужившего вызов;
статус вызова (обслуженный / потерянный);
этап обслуживания, на котором вызов был потерян (для потерянных вызовов).
Возможен также сбор информации о конкретном клиенте:
номер вызывающего абонента;
номер и состояние счета (если таковой имеется);
характер предыдущих запросов;
дата первого обращения и 工д.
На основании всех вышеперечисленных данных формируются различные отчеты. Например, уже не раз упоминавшийся контакт- центр CentreVu Solutions компании AVAVA предусматривает в своей системе генерацию отчетов следующих типов:
отчеты реального времени;
интегрированные отчеты;
пользовательские отчеты;
отчеты о недопустимых событиях;
отчеты-прогнозы.
А в упоминавшемся ранее контакт-центре ПРОТЕЙ создана так называемая хронологическая система генерации отчетов реального времени, работающая с оперативными данными, перечисленными выше. Хронологические отчеты могут обновляться каждые 15 минут, данные могут суммироваться по временным интервалам, дням, неделям, месяцам и т.д. Хронологические отчеты позволяют решать долгосрочные стратегические задачи повышения эффективности работы операторского центра (например, определить наилучший способ организации приема и обслуживания вызовов, оптимальное число сотрудников в каждом подразделении с учетом их квалификации, оптимальное число соединительных линий и многое другое).
Система позволяет генерировать хронологические отчеты, благодаря которым можно проследить распределение вызовов по операторам, оценить эффективность действующих алгоритмов, распределение вызовов по временным интервалам и любую другую информацию, которую заказчик сочтет целесообразной.
В основе интегрированных отчетов лежит комбинация данных, полученных из отчетов реального времени и хронологических. Это уникальная возможность, которая позволяет видеть настоящее и прошлое операторского центра и понимать, как влияют принятые оперативные решения на долговременные стратегические задачи.
Пользовательские отчеты - это отчеты с любым набором данных, в любом порядке и в любом графическом виде - таблицы, графики, тексты - по желанию конкретного заказчика.
В основе генерации отчетов о недопустимых событиях лежит принцип оповещения администраторов о разного рода экстраординарных событиях, например, о неответеоператора. Таким образом, если происходит что-либо, выходящее за рамки правил функционирования центра, то происходит визуальное оповещение об этом соответствующего персонала, например старшего оператора или администратора. Это дает управляющему персоналу возможность немедленно реагировать на изменение оперативной ситуации в центре обслуживания вызовов. Пороговые значения, определяющие выход события за рамки допустимого, устанавливаются на уровне отдельных операторов, операторских групп, групп соединительных линий.
Отчеты-прогнозы позволяют оценивать будущие характеристики трафика, загрузки операторов и соединительных линий на основе
данных, взятых из хронологических отчетов. Отчеты-прогнозы отвечают на вопрос: «А что будет, если?...» и дают возможность сначала смоделировать ту или иную ситуацию, а потом уже приниматьокон- чательные решения (например, о расширении штата операторов или о подключении дополнительных соединительных линий).
Кроме того, благодаря программному обеспечению CentreVu Supervisor, работающему в стандартной среде MicrosoftWindows, пользователи, которым это разрешено, п олуч а ют доступ к средствам администрирования и отчетности со своего компьютера. Поскольку такое программное обеспечение является обычным прикладным решением Windows, пользователь может открывать одновременно несколько окон с разными отчетами.
Вопросы административного управления связаны и с теми услугами, для оказания которых контакт-центры привлекают сторонние структуры, - с аутсорсингом, подробно рассмотренным в главе 7. Такое решение позволяет мелким предприятиям пользоваться всеми преимуществами мощных контакт-центров, тогда как более крупные компании получают возможность продавать услуги своих контакт-центров. Кроме того, аутсорсинг позволяет переложить на поставщика услуг непростые обязанности, связанные с кадрами и модернизацией технологии.
И, в заключение данной главы, - прогноз американской аналитической компании DataQuest: к 2003 году в операторских центрах будет работать больше людей, чем в аграрном и образовательном секторах США вместе взятых.
В дополнение к этому прогнозу, авторы сочли возможным попытаться предсказать некоторые перспективные стимулы будущего развития контакт-центров. В первую очередь, вероятно, что наберут силу запросы относительно нового вида, в частности, видеотрафик. Возрастет также доля обращений к услугам контакт-центров пользователей мобильными телефонами, имеющих выход в Интернет, и, возможно, именно они откроют еще один канал для обслуживания клиентов и для операций в рамках электронной коммерции, поскольку рутинная работа с Web-сайтом для них затрудн ител ьна.
Глава 9 Алгоритмическое обеспечение
Компьютерная программа делает то, что вы приказали ей делать, а не то, что вы хотели, чтобы она сделала. «Третий закон Грира»
Общие положения
В главе 3 уже упоминались перипетии краткой, но содержащей весьма драматические страницы истории стандартизации архитектуры и программно-аппаратных интерфейсов для Call-центров и других систем компьютерной телефонии. Здесь же рассматриваются инженерные аспекты этого процесса.
В трех предыдущих главах говорилось, в частности, о том, что эволюция простейших СРВ к Web-контакт-центрам потребовала интеграции разных устройств компьютерной телефонии - систем интерактивного речевого ответа (IVR), речевой почты, ступеней распределения вызовов (ACD), шлюзов IP-телефонии и др. Однако задача поддержки большого количества разнообразных интерфейсов этих устройств и объединения их в единое целое может поставить в тупик даже самые мощные коллективы разработчиков.
Ситуацию осложняет еще и тот факт, что приложения CTI являются приложениями, управляемыми событиями. Существующие программные инструментальные средства обычно не обеспечивают поддержку систем, управляемых событиями, так что разработчик приложений CTI должен, прежде чем начинать работу над приложением, разработать структуру обработки событий. К тому же, Call-центры и оборудование, применяемые сегодня, должны интегрироваться с другими системами узлов услуг типа баз данных, служб каталогов, электронной почты и др., что также вызывает определенные алгоритмические трудности.
Кроме того, к программному управлению Call-центрами и к другим приложениям компьютерной телефонии, как правило, предъявляются жесткие требования в отношении быстроты ответа. Когда вызывающий абонент обращается к Call-центру или к иной службе CTI, он ожидает, что система ответит ему немедленно. Обычные операционные системы компьютеров CTI не ориентированы специально на организацию режима реального времени; то же касается времени задержки в сетях передачи данных и, в частности, в 1Р-сетях. Таким образом, программисты систем компьютерной телефонии, прежде чем приступить к разработке собственно приложения, должны разработать специальные методы организации режима реального времени.
Вместе все эти проблемы делают процесс создания программного обеспечения Call-центров и других приложений компьютерной телефонии длинным и трудным. Чтобы можно было создавать приложения CTI разных типов на базе единой архитектуры, необходима поддержка в ней широкого набора функциональных возможностей, не зависящих от способа доступа к ним.
Сегодня список наиболее популярных приложений компьютерной телефонии, рассмотренных в предыдущих главах книги, включаете себя системы интерактивного речевого ответа IVR, системы речевой почты, системы распределения вызовов СРВ, системы упреждающего набора, системы предоставления услуг факсимильной связи, разнообразные корпоративные системы набазеУАГС, интеллектуальные мосты конференцсвязи, системы речевого набора номера, распознавания и синтеза речи и др. Алгоритмическое обеспечение всех этих систем должно позволять с минимальными усилиями интегрировать их функциональные возможности с уже существующим оборудованием телефонной связи и с приложениями нетелефонной связи. Например, производители приложений электронной почты должны иметь возможность, используя архитектуру систем компьютерной телефонии, добавлять к их программам такие функции как синтезатор речи «text-to-speech» или речевая почта. Точно также, производители систем речевой почты должны иметь возможность добавлять к своему оборудованию функции электронной почты.
Основные аспекты алгоритмического обеспечения компьютерной телефонии рассматриваются ниже.
9-1.1 Управление обслуживанием вызова
Для предоставления телекоммуникационных услуг Call-центры и другие системы компьютерной телефонии включаются в телефонную сеть общего пользования и, следовательно, должны поддерживать существующие системы сигнализации и процедуры обслуживания вызовов, а также отслеживать всевозможные события, связанные с обработкой вызова, управлять параметрами и телефонными
ресурсами. Последние функции реализуются посредством интерфейса управления обслуживанием вызова с помощью протоколов CSTA, SCAI, 7ASC, интерфейса С.001 форума компьютерной телефонии, а также Parlay API. Рассмотрению названных протоколов посвящен следующий параграф 9.2.
Управление телефонными устройствами
Телефонные аппараты 一 наиболее распространенные в мире устройства. Сегодня их разнообразие впечатляет - существуют классические, бесшнуровые, специализированные (в составе УАГС), мобильные, спутниковые и др. телефонные аппараты. Их значительно больше, чем компьютерных клавиатур, «мышей», принтеров и всех прочих периферийных устройств, вместе взятых. В контексте данной книги все это телефонное оборудование следует рассматривать как новый вид компьютерной периферии, требующий для компьютера специального программного обеспечения и интерфейса, чтобы сделать возможным отслеживание сигналов телефонного аппарата (какие нажимаются кнопки, что отображено на дисплее, мигает или нет оповещающий индикатор и т.д.) и управление этим аппаратом (обновление информации на дисплее, имитация нажатия кнопок, включения индикаторов и т.д.).
Управление медиа-ресурсами
Другой задачей алгоритмического обеспечения является управление мед и а - ресурсам и или устройствами, которые участвуют в обработке пользовательской информации. Управление это заключается в том, чтобы создавать медиа-потоки, направлять их к соответствующим устройствам (как физическим, так и логическим) и контролировать их работу. Описание концепции медиа-услуг согласно спецификациям форума ECTF (S.100), представлено в параграфе 9.3.
Алгоритмическое обеспечение любого узла услуг; Call-центра или другой системы компьютерной телефонии содержит две области (два домена) - компьютерный и коммутационный (рис.9.1). Компьютерный домен описывает компьютерные ресурсы, входящие в состав системы и взаимодействующие с областью коммутации, объединяющей телефонные ресурсы, которые могут представлять собой опорно-транзитную АТС, АМТС, УДГС, АТС с поддержкой услуг ISDN, специализированный коммутатор и т.п. Домен коммутации содержит оборудование и программные средства, которые обеспечивают передачу речи и данных и выполняют функции коммутации. Граница между этими доменами в англоязычной литературе носит название «service boundary». Для связи между собой (т.е. для обмена информацией через границу) объекты, находящиеся в разныхдоменах, используют интерфейс, для которого определен набор запросов, ответов и событий.
Рис. 9.1 Логическая конфигурация оборудования CTI
Каждый из представленных на рис.9.1 доменов может находиться в одном из следующих состояний:
запуск: это состояние означает, что домен вводится в действие и временно не способен отвечать на запросы.
нормальное: домен находится в нормальном рабочем состоянии.
потеряно сообщение: это состояние означает, что было потеряно одно из сообщений (запрос, ответ, событие).
блокировка: это состояние, когда все запущенные программы находится в заблокированном состоянии.
возможность перегрузки: это состояние означает, что домен подошел к порогу перегрузки.
перегрузка: это состояние, когда система перегружена, и предпринимаются действия для уменьшения ее нагрузки.
перегрузка предотвращена: это состояние показывает, что система была у порога перегрузки, но в данный момент возможна нормальная работа.
Протокол CTSA
Протокол взаимодействия компьютерного и коммутационного оборудования CSTA уже упоминался в плаве 3 в качестве наиболее значимой работы ассоциации ЕСМА. Там же говорилось, что разработкой аналогичного интерфейса управления обслуживанием вызова занимались и другие стандартизующие организации - ANSI, а впоследствии и ITU-Т однако протокол CSTA стал первым широко распространенным интерфейсом, который был внедрен в УАТС таких фирм как Ericsson и Alcatel. Протокол CSTA оказал сильное влияние и на развитие интерфейсов TSAPI и TASC.
Как уже упоминалось выше, важнейшим элементом каждого из этих протоколов компьютерной телефонии является модель обслуживания вызова, отображающая работу коммутационного оборудования. Согласование модели обслуживания вызова, приемлемой как для телефонистов, так и для компьютерщиков, оказалось чрезвычайно трудной задачей. И хотя для такой модели и удалось определить объекты и состояния, детальные последовательности процедур установления соединения, разъединения и общего управления обслуживанием вызовов определены так и небыли.
Протокол CSTA оперирует следующими логическими объектами модели процесса обслуживания вызова - сеанс связи, соединение и устройство. Сеанс связи - логический объект, абстрактно отображающий процесс обслуживания вызова, т.е. процесс предоставления пользователю нужной ему связи или услуги, сопровождения этой связи (услуги) и ее прекращения (отмены). Устройство - это объект, абстрактно отображающий физический (логический) компонент сети, который используется в этом процессе, например, терминал пользователя, ступень распределения вызовов, сетевой интерфейс и т.п. Соединение -это объект, абстрактно отображающий ассоциацию между определенным объектом «устройство» и определенным объектом «сеанс». Если объект «сеанс» относится к связи, например, двух объектов «устройство», то абстрактное отображение этой связи содержит два объекта «соединение» (отсюда ясно, что применительно к модели CSTAслово «соединение» обозначает понятие, отличающееся от того, которое определено в других стандартизирующих документах, и, соответственно, от того, к которому мы все привыкли).
ЕСМА определяет состояния объектов «соединение», а состояния объекта «сеанс», отображающих процесс обслуживания вызова, рассматриваются как совокупность состояний ассоциированных с ним объектов «соединение».
На рис.9.2 показаны объекты «устройство», определённые ЕСМА. Атрибутами объекта «устройство» CSTA являются его тип и идентификатор. Каждый такой объект принадлежит, по крайней мере, одному из следующих классов: данные, видео, речь. В отношении идентификаторов ЕСМА определяет две возможности: они могут быть
статическими и динамическими. Статический идентификатор остаётся постоянным во времени, примером такого идентификатора является списочный номер. Динамический идентификатор используется всякий раз только для одного вызова. Состояния объекта «устройство» по протоколу CS7A однозначно соответствуют состояниям объекта «соединение», ассоциирующего данное «устройство» с объектом «сеанс». Объекты «соединение» и «сеанс» имеют два атрибута: идеитификатор и состояние. Состояние объекта «сеанс» определяется как набор состояний объектов «соединение», которые с ним ассоциированы.
Рис. 9.2 Типы устройств CSTA, определённые ЕСМАРис. 9.2 Типы устройств CSTA, определённые ЕСМА
Рис. 9.2 Типы устройств CSTA, определённые ЕСМА
Рис. 9.2 Типы устройств CSTA, определённые ЕСМА
Рассмотрим, например, обычный телефонный разговор между двумя абонентами. Когда абонент снимает трубку телефона, создается объект «сеанс», а также объект «соединение», который указывает на связь объекта «устройство», отображающего телефон абонента, с этим «сеансом». Списочный номер телефонного аппарата является статическим идентификатором объекта «устройство». Помимо этого, «устройство» получает и динамический идентификатор, имеющий смысл только во время существования «сеанса». До набора номера данный объект «соединение» находится в начальном состоянии -INITIAL; а объект «соединение» на вызываемой стороне находится в состоянии NULL Соответствующее состояние объекта «сеанс» - ожидание цифр номера PENDING. После приема и обработки номера активизируется объект «соединение» на вызываемой стороне, а объект «соединение» на вызывающей стороне переходит в состояние ESTABLISHED. Когда поступает сигнал КПВ (контроль посылки вызова), то это означает, что удаленный объект «соединение» (как и удаленный объект «устройство») перешел в состояние
ALERTING (посылка вызывного сигнала). Соответствующее этому состояние процесса обслуживания вызова называется DELIVERED. Каждый раз при изменении состояния объекта модели, генерируется отчет об этом изменении, который направляется в компьютерный домен, на основании чего в нем составляется представление о продвижении процесса обслуживания вызова.
На рис.9.3 приведена схема возможных состояний объекта «соединение» и возможные переходы между ними. Состояний всего 7, но поскольку с одним объектом «сеанс» бывает ассоциировано два и более объектов «соединение», часто находящихся в разных состояниях, то количество состояний объекта «сеанс» может оказаться очень большим, даже если принять во внимание ограничения, обусловленные правилами переходов.
Рис. 9.3 Состояния объекта "соединение"
Стандарты ЕС МА не определяют все состояния объекта «сеанс». Однако очень многие вызовы порождают «сеансы», которые могут находиться лишь в небольшом количестве состояний. Такие «сеансы» называют обыкновенными, и для них определены состояния, приведенные в табл.9.1.
Определив модель обслуживания, стандарты ЕСМА описывают услуги, с помощью которых компьютерный домен может управлять обслуживанием вызова, т.е. коммутационным оборудованием.
Стандартами определяются следующие категории услуг: услуги управления обслуживанием вызова (т.е. коммутационные услуги)
и услуги определения состояния. Основные коммутационные услуги, с кратким их описанием, представлены в табл. 9.2.
Таблица 9.1 Состояния обыкновенного "сеанса" по ЕСМА
Состояние местного объекта "соединение"
Состояние удаленного объекта "соединение"
Состояние обыкновенного объекта "сеанс"
ALERTING
CONNECTED
RECEIVED
ALERTING
HELP
REC^IVED-ON-HOLD
CONNECTED
ALERTING
DELIVERED
CONNECTED
CONNECTED
ESTABLISHED
CONNECTED
FAILED
FAILED
CONNECTED
HELD
ESTABUSHED-ON-HOLD
CONNECTED
NULL
ORIGINATED
CONNECTED
QUEUED
QUEUED
HELD
ALERTING
DELIVERED-HELD
HELD
CONNECTED
ES1ABUSHED-HELD
HELD
FAILED
FAILED-HELD
HELD
QUEUED
QUEUED-HELD
INITIATED
NULL
PENDING
NULL
NULL
NULL
Таблица 9.2 Основные коммутационные услуги протокола CS7A
1. Make call
Создает объект "сеанс" и объект "соединение", ассоциирующий с ним вызывающий объект "устройство"
2. Clear call
Ликвидирует объект "сеанс" и все связанные с ним "соединения"
3. Clear connection
Переводит объект "соединение" в состояние Null
4. Hold call
Переводит существующий объект "соединение" в состояние Held
5. Retrieve call
Услуга, возвращающая объект "соединение" из состояния Held в состояние Connected
6. Consultation call
Комбинация услуг 4 и 1
7. Alternate call
Комбинация услуг 4 и 5
8. Reconnect call
Комбинация услуг 2 и 5
9. Transfer call
Комбинация услуг 3 и 5, обеспечивающая переключение связи
10. Conference call
Создает связь трех объектов "устройство" с одним объектом "сеанс"
11. Answer call
Автоматический ответ на вызов
12. Call completion
Привлечение услуги Call back. Camp on или Intrude
13. Make predictive call
Аналогична услуге 1, но сначала к "сеансу" привлекается вызываемый объект "устройство", а затем - вызывающий
14. Divert call
Переадресует вызов
15. Set feature
Закрепляет дополнительную услугу за объектом "устройство"
Для управления обслуживанием вызова необходимо знать текущее состояние процесса, отображаемого объектами «сеанс» и «устройство». Основные услуги определения состояния представлены в табл. 9.3.
Таблица 9.3 Услуги определения состояния
Monitor start
Запуск мониторинга нужного объекта
Monitor stop
Прекращение мониторинга этого объекта
Event report
Отчеты о событиях в процессе, отображаемом этим объектом
Change monitor filter
Изменение фильтра отчетов о событиях
Query device service
Сведения о действии дополнительных услуг; закрепленных за определенным объектом "устройство", или о его статических атрибутах
Snapshot call
Сведения о состояниях всех объектов "устройство" и "соединение", ассоциированных с заданным объектом "сеанс"
Snapshot device
Сведения о состоянии всех объектов "сеанс", ассоциированных с заданным объектом "устройство"
Модель обслуживания вызовов SCAI
Модель SCAI тоже основана на рассмотрении взаимосвязи и поведения абстрактных объектов. Имеются объекты четырех типов 一 сеанс, участник, устройство и агент. Объект «сеанс», как и в модели CS7A, отображает процесс обслуживания вызова. Объект «участник» аналогичен объекту «соединение» модели CSTAbtom смысле, что он отражает ассоциацию между определенным объектом «сеанс» и определенным объектом «устройство», но на этом аналогия заканчивается. Дело в том, что в SCAI объект «сеанс» отражает состояния процесса обслуживания вызова не через состояния других объектов, как это имеет место в CS7A, а непосредственно. Заметим также, что с одним объектом «сеанс» в модели SCAI может быть ассоциировано одновременно несколько объектов «устройство». Объект «устройство» аналогичен одноименному обьекту CS7A. Отличие состоит в том, что поскольку организуемая связь может быть либо обычной, либо многосторонней, объект «устройство» в модели SCAI может отображать либо один, либо несколько компонентов сети и быть связан либо с одним, либо с несколькими объектами «сеанс» (соответственно, посредством либо одного, либо нескольких объектов «участник»). Наконец, объект «агент» отображает состояния оператора, который может участвовать в обслуживании вызова. Наличие в модели этого объекта обусловлено тем, что количество и смысл возможных состояний оператора не совпадают с аналогичными характеристи кам и состояний обычного пользователя.
Логическая связь объектов модели SCAI представлена на рис. 9.4.
Модель SCAI отдельно описывает обслуживание вызова на исходящей стороне, и отдельно - на входящей. В модели обслуживания обычного вызова на исходящей стороне (рис. 9.5) процесс, отображаемый объектом «сеанс», проходит через следующие состояния. Когда абонент снимает трубку, процесс переходит из свободного состояния (NULL) в состояние приема вызываемого номера (PENDING). При этом переходе генерируется отчет об инициировании обслуживания. После получения всех цифр, необходимых для маршрутизации вызова к месту назначения, процесс переходит в состояние ORIGINATED. Когда вызов достигает вызываемого абонента, процесс переходит в состояние DELIVERED, при этом вызываемый телефон звонит, а вызывающий абонент слышит сигнал контроля посылки вызова. И, наконец, когда вызываемый абонентснимаеттрубку, процесс переходит в состояние ESTABLISHED, идентифицируемое отчетом о том, что запрошенная связь организована.
Из рисунка 9.5 видно, что возможны и другие варианты установления исходящего соединения. Важно, однако, что процесс, который отображается объектом «сеанс», может, согласно модели SCAI, находиться только в определенных состояниях.
Если рассматривать модель обслуживания обычного вызова на входящей стороне,™ состояния процесса обслуживания могут быть следующими: NULL, ARRIVED, RECEIVED, ESTABLISHED. Состояние
ARRIVED означает, что вызов поступил в оборудование, непосредственно обслуживающее вызываемого пользователя (например, блок NT пользователя ISDN). Состояние RECEIVED означает, что в вызываемый терминал передается вызывной сигнал, а состояние ESTABLISHED, -что вызываемый пользователь ответил на вызов.
Для исходящей стороны протоколом определено следующее соответствие между состояниями процесса обслуживания, отображаемыми объектом «сеанс», и состояниями, отображаемыми объектом «участник», представленное в таблице 9.4. В таблице 9.5 перечислены возможные состояния объекта «агент».
Таблица 9.4 Соответствие состояний, отображаемых объектами "сеанс" и "участник" в протоколе SCAI
Объект "сеанс"
Объект "участник"
NULL
NULL
PENDING
ACTIVE
ORIGINATED
ACTIVE или HOLD
DELIVERED
ACTIVE или HOLD
EC7ABLISHED
ACTIVE или HOLD
FAILED
ACTIVE
Таблица 9.5 Объект "агент" - состояния и события
Состояния объекта "агент0
Отчеты о событиях
Регистрация выполнена (LOG ON)
Agent logged on
Регистрация отменена (LOG OFF)
Agent logged off
Готов (READY)
Agent ready
Не готов (NOT READY)
Agent not ready
Свободен (WORKING READY)
Agent working ready
Занят (WORKING NOT READY)
Agent working not ready
Интерфейс TASC
Как уже было отмечено в 3 главе, интерфейс управления обслуживанием вызова TASC, разработанный Сектором стандартизации Международного союза электросвязи (ITU-T), основан на предшествовавших наработках организаций ЕСМА и ANSI в этой области и существенных отличий от них не имеет Поэтому детальное рассмотрение 1ASC здесь не приводится.
Архитектура CTI по ECTF и интерфейс С.001
Для удовлетворения требований мобильности, взаимозаменяемости и расширяемости форум компьютерной телефонии ECTF предложил определить интерфейсы между основными компонентами системами, а также ее внешние интерфейсы. Список интерфейсов, определенных ECTF(рис. 9.6), включаете себя:
интерфейсы ком мутационных услуг и медиа-услуг (S. 100);
транспортный протокол (S.200);
интерфейс предоставления услуг (S.300);
интерфейсы аппаратного обеспечения (Н.100);
интерфейс контроля и управления обслуживанием вызова (С.хОО);
интерфейсы административных услуг (S.900);
интерфейс взаимодействия приложений (А.хОО).
ECTF не требует полного соответствия систем представленной на рис.9.6, то есть необязательно, чтобы в системе присутствовали все компоненты или поддерживались все интерфейсы. Разработчики систем имеет возможность определять, какие модули и какие интерфейсы их продукты должны поддерживать, а какие - нет (в зависимости от области применения, времени, необходимого для разработки, трудоемкости и стоимости). Например, возможно создание телефонного сервера только с интерфейсом S.100 API, без поддержки S.200, S.300 или интерфейсов Н.100. А другие системы могут поддерживать S.300 SPI, обеспечив тем самым способность к взаимодействию компонентов ресурса.
TAPI .TSAPI \ JTAPI
( Приложение、( Административное){ Тегщфомнае 、
\^ S.100JX. приложение^/х^^ приложение J
SJ00 Прикладной программируемый интерфейс
'饱SfTE» п^икйадногамнтерф^са^
V
Транспорт
Л
ASR
V
V
Аппаратная платформа
Ком мутаци я
ТфОП
Модуль управления обслуживанием вызова
SPI правления обстукиванием вызова
прилснкение
5,100
^Х$200:нтерф 轻元
SFC J[
)CSTA TSPi
Интерфейс сигнализации
Hay J
/ »,. обслуж^вен限м ахзова
Рис. 9*6 Интерфейсы архитектуры ECTF
200 мнт&рфе 访^/^
Связь
S.900 SNMPV кнтер@е访g К
/ Г ПО^рав^ния
/ V обслуживанием еызсша / CTI-linl?
Системный модуль(Сессии, группы, соединения),
S.3QQ инт:р(Ьейс i^gdtRUNK^ /
Факс
,Маршрутизация T"вызовов
Управление| ркгналнзаине 以(УС1J
Структура сервера ECTF
Архитектура систем ECTF предусматривает наличие в ней одного или нескольких взаимодействующих серверов, обеспечивающих предоставление медиа-услуг, т.е. услуг, которые связаны с обработкой информации, передаваемой по несущим каналам телекоммуникационных интерфейсов. ECTF определяет два типа серверов: серверы приложений и телефонные серверы. Серверы приложений подцер- живаюттелефонную связь и обработку медиа-информации в распределенной сети. Телефонные серверы предоставляют ресурсы телефонной связи и медиа-ресурсы (средства передачи и обработки медиа-информации -линии, системы распознавания речи, системы обработки факсимильной информации) по требованиям приложений.
Архитектура не накладывает ограничений на реализацию. В некоторых случаях прикладная программа и ресурсы телефонной связи могут находиться на едином сервере телефонной связи (серверы приложений не используются). Такая структура применяется, когда компьютерные возможности телефонного сервера адекватны требованиям ресурсов телефонной связи и прикладных программ. В других случаях могут использоваться отдельные прикладные серверы, что увеличивает возможности обработки потоков информации, допускаетреализацию географически распределенных систем или расширение функциональных требований. Итак, ECTF определяет две конфигурации размещения приложений: (а) на телефонном сервере и (б) на сервере приложений отдельно от телефонного сервера.
Конфигурации сервера
По идеологии ECTF как сервер приложений, так и телефонный сервер могут быть представлены в виде: (а) единого физического и логического узла; (б) нескольких физических устройств, объединенных- с точки зрения приложений - в единый логический узел; (в) нескольких физических устройств, представляющих несколько логических узлов.
На рис. 9.7 показана самая простая конфигурация, в которой телефонные серверы являются отдельными логическими узлами. Все ресурсы, используемые приложением для обслуживания вызовов, принадлежат этому отдельному узлу.
Приложение (или услуга) может использовать возможности не- сколькихтелефонныхсерверов (на рис. 9.7это показано пунктиром), но в данном случае для обслуживания вызова могут быть задействованы только ресурсы сервера, инициировавшего запрос обслуживания. Если несколько серверов связаны между собой (например, через ТфОП), приложение не может использовать эти связи, так как они находятся вне административной области серверов (проще говоря, приложение о них не знает).
Рис. 9.7 Телефонные серверы ECTF, размещенные на отдельных узлах
В конфигурации, показанной на рисунке 9.8, приложение «знает» уже про несколько телефонных серверов. Такие приложения могут обрабатывать вызовы от каждого сервера, используя прикладной интерфейс API S.100, и при этом использовать ресурсы разных серверов для обработки одного вызова. Правда, такая схема возможна только в том случае, если приложение само организует специальные соединения между серверами, ресурсы которых ему необходимы. Каналы между серверами можно организовать на базе любых средств - линий ТфОП, цифровыхлиний ISDN, арендованных линий, шин компьютерной телефонии и др.
Рис. 9.8 Телефонные серверы, объединенные специальными каналами
Имеются примеры архитектуры, позволяющей разработчикам телефонного сервера развертывать логический сервер, размещая ресурсы на разных физических узлах. В данной конфигурации для
объединения ресурсов на разных узлах, в соответствии со стандартом S.300, используется межузловой прокси-сервер. Такой сервер у станавл и вается нафизическиеузлы, как любое другое приложение, причем для него могут использоваться серверы разных производителей. Методика весьма проста, но отказ ведущего узла сделает недоступными и дополнительные узлы (узлы расширения). Впрочем, современные способы резервирования аппаратных средств позволяют хорошо известными стандартными средствами избежать подобных проблем. Более сложное программное обеспечение сервера может дублировать и тиражировать системные услуги каждого узла. Возможность межузлового обмена сообщениями - важное преимущество ECTF-стандартов S.300. Межузловыми соединениями управляет контроллер коммутации (SFC - switch fabric controller). Отказ ведущего узла, конечно, приведет к потере ресурсов и вызовов, обрабатываемых этим узлом, но приложения сохранят возможность нормально функционировать и продолжат обрабатывать вызовы, используя ресурсы других узлов, являющихся частью этого логического сервера.
Базовая конфигурация сервера
На рис. 9.9 показана базовая конфигурация телефонного сервера, достаточная, чтобы обеспечить все функциональные возможности приложений, описанные ранее. Услуги телефонной связи, определенные в S.100 API, включают в себя управление группой ресурсов для предоставления медиа-услуг управление самими медиа-услугами (запись, воспроизведение речи и др.), и прикладной интерфейс (API) для управления соединениями между сетевыми портами и группами медиа-ресурсов. Интерфейсы управления обслуживанием вызовов типа TAPI, TSAPI или JTAPI, согласно идеологии ECTF, не включены в базовый сервер телефонной связи. Вся коммутация речевых трактов, операции типа создания и приема вызовов, коммутации и т.п., осуществляются через интерфейс S.100 API.
Приложения, поддерживающие S.100, могут находиться на телефонном сервере, а для связи с системными услугами могут использовать внутренний (фирменный) интерфейс обмена данными между разными процессами или протокол S.200. Приложения, поддерживающие S.100 и находящиеся на удаленных серверах приложений, должны использовать протокол S.200.
Спецификация S.100 также определяет услугу распределения вызовов по приложениям - системный маршрутизатор вызовов (System Call Router - SCR). Маршрутизатор SCR ассоциирует вызов с медиа-группой, конфигурируя соответствующий ресурс несущего канала (call channel resource - CCR). Маршрутизатор ведет обработку вызовов на основе такой информации, как информация АОН, набранный номер и т.д.
Контроль телефонных линий и управление ими может осуществлять любое приложение, имеющее доступ к интерфейсу управления линиями телефонного сервера. На рис. 9.9 также показаны два разных варианта связи приложений с телефонным сервером ECTF - протокол связи S.200 и внутренний протокол обмена. Как правило, в системе используется только один из этих вариантов. Преимущество протокола S.200 состоит в том, что он предусматривает стандартное сопряжение и обеспечивает взаимозаменяемость удаленных серверов разных производителей.
<<ПриложениеS.100ПриложениеS.100ПриложениеS.100ПриложениеS.100S. 100 Прикладной программируемый интерфейсS. 100 Прикладной программируемый интерфейсАдаптер прикладного интерфейсаАдаптер прикладного интерфейсаТранспортТранспорт'S\s^200 интерфейс'S\s^200 интерфейсСистемный.модуль (Сессии, группы, соединения) S.300 интеа4)е〃с поставщикаСистемный.модуль (Сессии, группы, соединения) S.300 интеа4)е〃с поставщикаS.200 интерфейсS.200 интерфейсилиилимежпроцессорныймежпроцессорный.обмен.обменСвязьСвязьа.900 SNMP\ . интерфейс \а.900 SNMP\ . интерфейс \АдминистративноеАдминистративноеприложениеприложениеSFCSFC)(Play )( ASR )[ еакс)}^嗣 \质 а^ве又 1\/〈一^)(Play )( ASR )[ еакс)}^嗣 \质 а^ве又 1\/〈一^ФаксФакс1аршрутизация вызовов1аршрутизация вызовов/Интерфейс сигнализации Управление еигнализаиией/Интерфейс сигнализации Управление еигнализаиией硕 АратнаУ «латфоГ^^硕 АратнаУ «латфоГ^^、Г / S.5xx Интер(^е〃с управления коммутацие伉 \、Г / S.5xx Интер(^е〃с управления коммутацие伉 \Н.100 КоммутацияН.100 КоммутацияТфОПТфОП
<
<
Приложение
S.100
Приложение
S.100
Приложение
S.100
Приложение
S.100
S. 100 Прикладной программируемый интерфейс
S. 100 Прикладной программируемый интерфейс
Адаптер прикладного интерфейса
Адаптер прикладного интерфейса
Транспорт
Транспорт
'S\s^200 интерфейс
'S\s^200 интерфейс
Системный.модуль (Сессии, группы, соединения) S.300 интеа4)е〃с поставщика
Системный.модуль (Сессии, группы, соединения) S.300 интеа4)е〃с поставщика
S.200 интерфейс
S.200 интерфейс
или
или
межпроцессорный
межпроцессорный
.обмен
.обмен
Связь
Связь
а.900 SNMP\ . интерфейс \
а.900 SNMP\ . интерфейс \
Административное
Административное
приложение
приложение
SFC
SFC
)(Play )( ASR )[ еакс)}^嗣 \质 а^ве又 1\/〈一^
)(Play )( ASR )[ еакс)}^嗣 \质 а^ве又 1\/〈一^
Факс
Факс
1аршрутизация вызовов
1аршрутизация вызовов
/Интерфейс сигнализации Управление еигнализаиией
/Интерфейс сигнализации Управление еигнализаиией
硕 АратнаУ «латфоГ^^
硕 АратнаУ «латфоГ^^
、Г / S.5xx Интер(^е〃с управления коммутацие伉 \
、Г / S.5xx Интер(^е〃с управления коммутацие伉 \
Н.100 Коммутация
Н.100 Коммутация
ТфОП
ТфОП
Рис. 9.9 Базовая конфигурация телефонного сервера ECTF
Интеграция процессов управления обслуживанием вызова
На рис. 9.10-9.12 приводятся примеры интеграции стандартных интерфейсов API с телефонным сервером S.100. Эти варианты интеграции могут быть использованы, когда необходимо объединить возможности существующих интеллектуальных коммутаторов с сервером S.100.
На рис. 9,10 показана типичная конфигурация телефонного сервера, связанного каналом управления с УАТС. Маршрутизатор SCR может использовать каналы CTI для управления и для получения дополнительной информации относительно вызовов, которые поступают на УАТС. В этой конфигурации программы распределения вызовов (СРВ) или приложения операторского Call-центра посредством API-интерфейса могут управлять услугами, предоставляемыми на базе УАТС.
Приложение
S.100
Приложение S.10O
Адм инистративноеприложение ,
API управления обслуживанием в”зова
Телефонное приложение
S. 100 Прикладной программируемый интерфейс
Адаптер прикладного интерфейса
ТрнзюрГ .
S.200 интерфейс
S.200 интерфейс
или
Межпроцессорный
обмен
:Связь
V
S.900SNMP\интер中е%с }
TAPI TSAPI JTAPI
/I : обслуживанием вызова J
/ CTIFnk4一一二千:,":■l
SPI управленияобслуживаниемвызова
CSTA TSPI
<
SFC
ASR
A 巾巾 арагн/ платформа
Коммутация
S*300 ынтер4)е5с [юставидука
Системный модуль (Сессии, группы, соединения)
r Call Channel
Х^^\ Маршрутизация вызовов
八
V
f УС _ )
ТфОП
телефонная пиния
Модуль управл^ия
1 обслуживанием вызова
Интерфейс
си「напнзак14 Vl
Управление сигнализацией (VCi
Рис, 9,10 Телефонный сервер ECTF с внешним управлением обслуживанием вызова
Приложение
S.100
ПриложениеS.100
Адмт<ис1рагиемоеприложение j
(Телефонное k приложение
Транспорт
S.200 интерфейс
S.200 интерфейс
S. 100 Прикладной программируемый интерфейс
Адаптер прикладного интерфейса
Связь
или
Межпроцессорный
обмен
АР)управления обслуживанием вызова
TAPI TSAPI JTAP1
V
S.900 SNMP
/ CTI-linl?
мн丁@рф»е济а к
7—_
j<-^^{ Мар1ирутизаиия
Play
ASR
Факс
Апфаратная платформа
Коммутант
S.300 S7予)中 ете 门:阴авщика
Системный модуль (Сессии, группы, соединения}
^Г Call 1 Channel
Интерфейс А емгнан梵за居縫м '
Управление мнализаии或НУС)
SFC
вызовов
J
ПО управленияобслуживанием вызова
5Р1упра8ленияобслуживаниемвызова
〕CSTATSPI
Модуль управленияобслуживанием вызова
八
v
ГусПГусПГусЗ
ТфОП
Рис. 9.11 Телефонный сервер с объединенным управлением обслуживанием вызова
Приложение S.100
Административное
приложение
Транспорт
S.2O0 интерфейс
S.200 интерфейс
или
g网晔询ЙЙЯ?,J
<^(沌向№»石h山^0631 J
Телефонное приложение
ТАР!
TSAPI JTAPI
API управления 1уживанием вызова
Саязь
Приложение
S.1O0
обмен
S. 100 Прикладкой программируемый интерфейс
.Адапт^ прикладного интерфейса
,МежяроьдассорныЙ
V
S.900SNMP、 интерфейс /
/CTI-link
Системный модуль(Сессии, группы, соединения)
Маршрутизациявызовов
一百h 而鼠ёлёниа L"? обслуживанием Г" вазо8a/
CSTA TSPI
S.30Q интерфейс поставщика
Модуль управленияобслуживанием вызова
^ J1
"FC )(
Локальная коммутация
V
0
必-)
J ASR
айве
Факс J Iphannel)
АМаратна,
латфорМа
BI с^^
Рис. 9.12 Телефонный сервер с интегрированным управлением обслуживанием вызова
Телефонный сервер «видит» медиа-устройства и коммутационное оборудование как совокупность поставщиков услуг; взаимодействую- щихсним через стандартизован н ые ECTF интерфейсы, называемые Service Provider Interface - SPI. Для рассмотрения интегрированного телефонного сервера и услуг управления полезно представить себе схему обычной учрежденческой АТС. УАТС содержит абонентские комплекты и комплекты соединительных линий, возможно - цифроаналоговые преобразователи сигнала, интерфейсы управления каналами и модуль, управляющий линиями и внутренней коммутацией. Программное обеспечение УАТС управляет маршрутизацией и коммутацией между разными узлами и внешними сетями. Имеются также программные средства управления набором номера, очередями и средства контроля состояния линий, устройств и соединений в системе.
Нарис. 9.11 представлен телефонный сервер ECTF; область управления которого распространяется на компоненты УАТС (или, наоборот, граница УАТС распространяется на компоненты телефонного сервера). Идея рисунка состоит в том, что коммутационные возможности телефонного сервера и УАТС могут быть объединены. Рисунок показывает концептуальное соединение этих двух изделий.
На рис. 9.12 показан полностью интегрированный телефонный сервер ЕСТЕ Программное обеспечение модуля управления обслуживанием вызова осуществляет доступ к интегрированному коммутатору через интерфейс S.300. Это гарантирует правильное использование коммутационных ресурсов и связанных с ними медиа-ресурсов. Если модулю управления необходимы медиа-ресурсы, он может, в зависимости от реализации, обращаться к ним посредством протокола S.300 или использовать для этого внутренние интерфейсы. Для контроля состояния ресурсов или процессов и для предоставления соответствующих отчетов используется SNMP-агент.
Модель управления обслуживанием вызова С.001
Спецификация С.001 определяет модель управления обслуживанием вызова, включающую в себя описания услуг управления обслуживанием и их интерфейсов. Основой спецификации послужили ранее выполненные другими организациями работы в этой области - стандарты ЕСМАи консорциума CTI Encyclopedia. Модель С.001 определяет: объекты коммутационной области, процесс обслуживания и его состояния, услуги управления обслуживанием вызова, а также потоки сообщений, связанных с услугами.
9-5-6 Базовая модель обслуживания вызова в спецификациях ECTF
Базовая модель определяет параметры управления связью, услугами и интерфейсами внутри коммутационной области. Для обеспечения доступа к услугам и ресурсам телефонии внутри области
вычислений используются прикладные программные интерфейсы API. Модель предусматривает использование различных API и протоколов, которые в настоящий момент применяются в компьютерной телефонии.
Объектами модели ECTF (почти полностью соответствующей ранее описанной модели ЕСМА) являются сеанс, соединение ^устройство. Модель ECTF представлена рис. 9.13.
Ранее в этой главе отмечалось, что модель ЕСМА определяет 7 возможных состояний объекта «соединение». Там же, на рис.9.3 изображены все эти состояния, а линиями показаны возможные переходы между ними. Отмечено, что посколькулюбое состояние объекта «сеанс» определяется состояниями всех ассоциированных с ним объектов «соединение», общее число возможных состояний этого объекта очень велико, и стандарт ECTF (как и ЕСМА) не определяет их все. Как и для модели ЕСМА, для модели ECTF стандартом определены только состояния так называемого обыкновенного сеанса.
9.6 Концепция медиа-услуг
Одним из преимуществ технологии компьютерной телефонии является возможность содержать и эффективно использовать огромное количество ресурсов, а также наращивать их постепенно, по мере введения тех или иных услуг Управление ресурсами системы CTI возла-
гаются на отдельную подсистему, задача которой заключается в создании группы медиа-ресурсов, медиа-потоков (потоков пользовательской информации между медиа-ресурсами и интерфейсными устройствами) и в управлении этими потоками. Названные функции реализуются путем создания специального алгоритма работы как пользовательского, так системного оборудования. Для обслуживания каждого запроса требуется группа ресурсов с определенной конфигурацией. После того как вызов поступил в систему, медиа-сервер анализирует возможность создать такую конфигурацию (как с точки зрения прав пользователя, так и с точки зрения наличия в системе нужных ресурсов). По результатам анализа осуществляется диалог с оборудованием, от которого поступила заявка на обслуживание, и принимается решение о возможности обслужить данный вызов.
Модель обработки информации
Под обработкой информации понимается создание медиа-потоков и управление взаимодействием медиа-ресурсов с медиа-потоками и с базой данных. На рис. 9.14 представлена модель медиа-обработки. Прежде чем подробно изложить основные принципы предоставления медиа-услуг; определим некоторые часто употребляемые при изложении понятия.
Рис. 9.14 Модель медиа-обработки
Медиа-канал - ресурс, используемый для передачи медиа-потоков м ежду двум я устройствам и.
Медиа-информация - пользовательская информация, передаваемая по медиа-каналам.
Медиа-поток - это объект, несущий данные, которыми обмениваются устройства, участвующие в сеансе связи. Каждый медиа-поток характеризуется идентификатором, который присваивается ему на время существования сеанса, и направлением (прямое, обратное, дуплекс). Медиа-поток использует один или несколько медиа-каналов, каждый из которых может иметь индивидуальные характеристи-
ки (скорость передачи данных в бит/с, допустимое время задержки ит.д.). Направление передачи в медиа-каналах обязательно соответствует направлению медиа-потока.
Медиа-ресурсами называются устройства обработки медиа-информации или устройства доступа к медиа-информации. Можно выделить следующие основные категории медиа-ресурсов.
Устройства фильтрации предназначены для подавления звуков или шума в определенных частотных диапазонах, Это может быть необходимо для того, чтобы вырезать определенные частоты внутриполосной сигнализации, компенсировать влияние на сигнал определенного оборудования (например, при прохождении спутниковых участков), обеспечить подавление эхо-сигналов, или для предварительной обработки медиа-потоков по другим причинам.
Устройства сопоставления образцов предназначены для поиска в медиа-потоках битовых последовательностей, соответствующих определенным образцам. Например, частотный детектор отслеживает в медиа-потоках определенные частотные сигналы или их комбинации. Модем отслеживает определенную комбинацию символов при демодуляции входящего потока. Устройство распознавания речи может искать речевые фонемы.
Устройства преобразования обеспечивают преобразование одних медиа-потоков в другие. Например, устройства, выполняющие компрессию, преобразуют исходные данные в другой формат с компрессией, уменьшая тем самым необходимую для их передачи полосу. Другие устройства этой категории могут преобразовывать информацию в формат, пригодный для ее хранения в базе данных или для использования медиа-услуг клиентами. Например, после выделения фонем устройство распознавания речи может преобразовать речевой медиа-поток в текст.
Устройства хранения предназначены для хранения обработанной информации, например, в базах данных.
Устройство доставки информации к медиа-клиента м - медиа-ресурсы могут инициировать передачу сообщений, связанных с предоставлением медиа-услуг и содержащих данные, которые были получены из медиа-потоков.
Устройства генерации медиа-потоков могут сами генерировать медиа-потоки, основываясь на информации, полученной от абонента, из баз данных, из памяти устройств, на информации, извлеченной из одного или нескольких медиа-потоков, или на некоторой комбинации данных, полученных из упомянутых источников. Ресурсы этого типа могут выполнять одну или несколько из нижеперечисленных функций:
поиск информации, когда медиа-ресурсы могут использовать информацию, полученную от абонента, или информацию, хранимую в базах данных, для создания нового медиа-потока. Например, устройство преобразования текст-речь может исполь- зоватьсохраненныйтекстдля его звукового воспроизведения;
модуляцию, когда медиа-ресурс с функциями модема модулирует медиа-поток для кодирования данных;
смешивание - медиа-ресурс может смешивать информацию, получаемую из нескольких медиа-потоков, для создания одного или нескольких новых потоков. Например, устройство, используемое для конференцсвязи, создает для каждого из участников конференции поток, который содержит медиа-потоки всех остальных участников;
преобразование - медиа-ресурсы могут создавать медиа-поток, преобразуя информацию, полученную из других медиа-потоков. Например, многочастотный генератор преобразует медиа-данные, представляющие численные значения сигнальных частот и их продолжительность, в медиа-потоке многочастотными сигналами. При использовании технологии текст-речь ресурсы преобразуют текст в соответствующий речевой сигнал, основываясь на речевых особенностях того или иного языка. Другим примером медиа-ресурсов, выполняющих функции преобразования, являются устройства, преобразующие один формат сжатия информации в другой.
Медиа-группой называется виртуальное динамически конфигурируемое медиа-устройство, которое состоит из ресурсов, выполняющих разного рода действия с медиа-потоками.
Устройства маршрутизации и медиа-доступа
Маршрутизатор вызовов (SCR - system call router) является одной из основных составляющих сервера S.100. Задача маршрутизатора -обработка запросов, поступающих как со стороны ТфОП, так и от внутренних приложений. Для обслуживания внешних запросов SCR создает медиа-группу, удовлетворяющую требованиям к обслуживанию запросов данной категории, и направляет к ней медиа-поток. Маршрутизатор управляет медиа-устройствами доступа (т.е. устройствами доступа к медиа-ресурсам), являющимися той частью коммутационного оборудования, в которой посредством медиа-интерфейса обеспечивается доступ к медиа-ресурсам (т.е. функции медиа-устройства доступа состоят в том, чтобы добавить в объект типа «сеанс» интерфейс для взаимодействия с медиа-ресурсам и).
На рис.9.15 представлена процедура маршрутизации, включающая в себя команды и запросы, которыми обмениваются коммутационная и вычислительная области.
Коммутационнаяобласть(1) Вызов поступает на маршрутизатор(SCR), и посылается запроск вычислительной области отностельнодальнейшей маршрутизации вызоваКоммутационнаяобласть(1) Вызов поступает на маршрутизатор(SCR), и посылается запроск вычислительной области отностельнодальнейшей маршрутизации вызова(За)上ели поступила команда (2а).коммутационная область заканчиваетвыбор маршрута сообщениемRoute End(3b) Если поступила команда (2Ь),и место назначения доступно, токоммутационная область заканчиваетвыбор маршрута сообщениемRoute End(Зс) Если поступила команда (2Ь),и место назначения не доступно, токоммутационная область посылаетзапрос для выбора нового маршрутаRe-Route(3d) Если поступила команда (2с),коммутационная облас гь заканчивае!выбор маршрута(За)上ели поступила команда (2а).коммутационная область заканчиваетвыбор маршрута сообщениемRoute End(3b) Если поступила команда (2Ь),и место назначения доступно, токоммутационная область заканчиваетвыбор маршрута сообщениемRoute End(Зс) Если поступила команда (2Ь),и место назначения не доступно, токоммутационная область посылаетзапрос для выбора нового маршрутаRe-Route(3d) Если поступила команда (2с),коммутационная облас гь заканчивае!выбор маршрута(5) Коммутационная область сновапредпринимает попытку доставитьвызов к месту назначения(5а) Если место назначения доступно,посылаются запросы Route Used иRoute End, показывающие, чтонаправление задействуется дляэтого вызова(5Ь) Если место назначения недоступно, коммутационная областьпосылает запрос Re-Route для выборанового маршрута(5) Коммутационная область сновапредпринимает попытку доставитьвызов к месту назначения(5а) Если место назначения доступно,посылаются запросы Route Used иRoute End, показывающие, чтонаправление задействуется дляэтого вызова(5Ь) Если место назначения недоступно, коммутационная областьпосылает запрос Re-Route для выборанового маршрутаВычислительнаяобласть(2( Сервер принимаег решениео возможности обслужить вызов(2а) Ьспи серверрешает отказать в обслуживании,то посыпается команда Reject Call(2b) Если сервер решаетобслужить вызов, то определяегсяместо назначения(основываясь на информации,содержащейся в запросе)и посылается команда Route Select(2с) Еспм сервер решает закончигьдиалог, посылается командаRoute EndВычислительнаяобласть(2( Сервер принимаег решениео возможности обслужить вызов(2а) Ьспи серверрешает отказать в обслуживании,то посыпается команда Reject Call(2b) Если сервер решаетобслужить вызов, то определяегсяместо назначения(основываясь на информации,содержащейся в запросе)и посылается команда Route Select(2с) Еспм сервер решает закончигьдиалог, посылается командаRoute End(4а) Ьсли поступил пгшрос (За)или (ЗЬ), маршрутизация cuniaeicnзаконченной,и вызов либонаправляется к определенномуMAD, либо считается обслуженным(4Ь) Если поступил запрос (Зе), тоснова посылаеюя запрос RouteSelect с другим местом назначения(4а) Ьсли поступил пгшрос (За)или (ЗЬ), маршрутизация cuniaeicnзаконченной,и вызов либонаправляется к определенномуMAD, либо считается обслуженным(4Ь) Если поступил запрос (Зе), тоснова посылаеюя запрос RouteSelect с другим местом назначения(6а) Ьсли поступил запрос (5а),маршру1изация вызовасчитается законченной(6Ь) Если поступил запрос (5Ь), юпосылается третий запрос RouteSelect с другим местомназначения(6а) Ьсли поступил запрос (5а),маршру1изация вызовасчитается законченной(6Ь) Если поступил запрос (5Ь), юпосылается третий запрос RouteSelect с другим местомназначения
Коммутационнаяобласть
(1) Вызов поступает на маршрутизатор(SCR), и посылается запроск вычислительной области отностельнодальнейшей маршрутизации вызова
Коммутационнаяобласть
(1) Вызов поступает на маршрутизатор(SCR), и посылается запроск вычислительной области отностельнодальнейшей маршрутизации вызова
(За)上ели поступила команда (2а).коммутационная область заканчиваетвыбор маршрута сообщениемRoute End
(3b) Если поступила команда (2Ь),и место назначения доступно, токоммутационная область заканчиваетвыбор маршрута сообщением
Route End
(Зс) Если поступила команда (2Ь),и место назначения не доступно, токоммутационная область посылаетзапрос для выбора нового маршрутаRe-Route
(3d) Если поступила команда (2с),коммутационная облас гь заканчивае!выбор маршрута
(За)上ели поступила команда (2а).коммутационная область заканчиваетвыбор маршрута сообщениемRoute End
(3b) Если поступила команда (2Ь),и место назначения доступно, токоммутационная область заканчиваетвыбор маршрута сообщением
Route End
(Зс) Если поступила команда (2Ь),и место назначения не доступно, токоммутационная область посылаетзапрос для выбора нового маршрутаRe-Route
(3d) Если поступила команда (2с),коммутационная облас гь заканчивае!выбор маршрута
(5) Коммутационная область сновапредпринимает попытку доставитьвызов к месту назначения
(5а) Если место назначения доступно,посылаются запросы Route Used иRoute End, показывающие, чтонаправление задействуется дляэтого вызова
(5Ь) Если место назначения недоступно, коммутационная областьпосылает запрос Re-Route для выборанового маршрута
(5) Коммутационная область сновапредпринимает попытку доставитьвызов к месту назначения
(5а) Если место назначения доступно,посылаются запросы Route Used иRoute End, показывающие, чтонаправление задействуется дляэтого вызова
(5Ь) Если место назначения недоступно, коммутационная областьпосылает запрос Re-Route для выборанового маршрута
Вычислительнаяобласть
(2( Сервер принимаег решениео возможности обслужить вызов
(2а) Ьспи серверрешает отказать в обслуживании,то посыпается команда Reject Call
(2b) Если сервер решаетобслужить вызов, то определяегсяместо назначения(основываясь на информации,содержащейся в запросе)и посылается команда Route Select
(2с) Еспм сервер решает закончигьдиалог, посылается команда
Route End
Вычислительнаяобласть
(2( Сервер принимаег решениео возможности обслужить вызов
(2а) Ьспи серверрешает отказать в обслуживании,то посыпается команда Reject Call
(2b) Если сервер решаетобслужить вызов, то определяегсяместо назначения(основываясь на информации,содержащейся в запросе)и посылается команда Route Select
(2с) Еспм сервер решает закончигьдиалог, посылается команда
Route End
(4а) Ьсли поступил пгшрос (За)или (ЗЬ), маршрутизация cuniaeicnзаконченной,и вызов либонаправляется к определенномуMAD, либо считается обслуженным
(4Ь) Если поступил запрос (Зе), тоснова посылаеюя запрос RouteSelect с другим местом назначения
(4а) Ьсли поступил пгшрос (За)или (ЗЬ), маршрутизация cuniaeicnзаконченной,и вызов либонаправляется к определенномуMAD, либо считается обслуженным
(4Ь) Если поступил запрос (Зе), тоснова посылаеюя запрос RouteSelect с другим местом назначения
(6а) Ьсли поступил запрос (5а),маршру1изация вызовасчитается законченной
(6Ь) Если поступил запрос (5Ь), юпосылается третий запрос RouteSelect с другим местомназначения
(6а) Ьсли поступил запрос (5а),маршру1изация вызовасчитается законченной
(6Ь) Если поступил запрос (5Ь), юпосылается третий запрос RouteSelect с другим местомназначения
Рис. 9.15 Процедура маршрутизации
Роль медиа-устройств в процессе доступа к медиа-ресурсам системы зависит от местоположения этих ресурсов в коммутационном оборудовании. Медиа-ресурсы могут быть расположены внутри системы, принадлежать некоторому медиа-устройству доступа, или находиться в общем ресурсе группы медиа-устройств доступа.
Общее описание взаимодействия приложение - сервер
Каждое приложение проходит через одни и те же фазы-инсталлирования, обработки вызова, закрытия. Для инсталлирования приложения его производитель предоставляет конфигурационный файл Application Profile и исполняемую программу. Application Profile определяет набор ресурсов (включая их атрибуты и параметры), необходимых приложению для выполнения его функций. Сервер S.100 использует информацию из файла Application Profile для того, чтобы создать конфигурацию группы и установить требуемые параметры.
После запуска приложения открывается сессия связи приложения с сервером для передачи ему конфигурационной информации Application Profile. И когда приложение готово принимать вызовы, оно регистрируется в маршрутизаторе вызовов (SCR), идентифицируя себя с помощью идентификатора Application Service ID (ASI). Когда к сетевому интерфейсу сервера поступает вызов, SCR, в соответствии с установленными правилами маршрутизации, направляет его к одному из зарегистрированных приложений. При обслуживании каждого вызова маршрутизатор создает и настраивает группу устройств и передает управление этой группой приложению. В процессе работы приложение может изменять набор устройств в группе, а также передавать вызов другому приложению.
Группа и ресурсы
Как уже отмечалось ранее, медиа-группа (рис.9.16) содержит ресурсы, выполняющие разного рода действия с медиа-потоками. Концепция медиа-услуг; предлагаемая форумом компьютерной телефонии, не предусматривает прямого управления ресурсами со стороны пользователя. Любая, пусть даже самая простая задача, требующая использования медиа-ресурсов, обрабатывается медиа-группой, содержащей эти ресурсы. Различают два типа ресурсов группы: первичные и вторичные. Основная задача первичных ресурсов - обеспечить связь между устройствами медиа-доступа и вторичными ресурсами.
Характеристиками ресурсов являются:
класс, определяющий назначение ресурса;
порт, обеспечивающий передачу/прием медиа-потока в направлении к/от сети или другого ресурса. В зависимости от класса ресурса, он может обладать первичным и вторичным портами;
параметры, используемые для определения характеристик ресурса (при выполнении определенных действий с медиа-потоком);
набор функций («services» или «commands»), которые могут быть выполнены ресурсом.
Атрибуты Decyoca. Характеристики ресурса определяются при создании группы атрибутами в файле Application profile.
При работе с группой клиент может запросить ресурс, отвечающий задаваемому набору атрибутов, что позволяет ему (клиенту) изменить логику приложения. Ресурс каждого типа имеет свои специфические атрибуты. Ряд атрибутов, общих для всех ресурсов, описан ниже.
Атрибут идентификации сети. Это один из важных атрибутов ресурса. Сервер идентифицирует подгруппы ресурсов, которые мо-
гут быть взаимосвязаны через специальную схему. Эти подгруппы не пересекаются и охватывают все ресурсы на сервере. Для каждой такой подгруппы сервер назначает признак, который используется в качестве атрибута идентификации сети для каждого ресурса в подгруппах.
Информационные атрибуты ресурса. Ресурсы реализуются разными аппаратными средствами или компонентами программного обеспечения. Информационные атрибуты могут понадобиться клиентам для конфигурации группы, содержащей специфические компоненты (т.е. индивидуальной медиа-группы). Информация, представляемая информационными атрибутами ресурса, идентифицирует имя и версию аппаратных средств и/или программного обеспечения ресурса.
Атрибут управления временем запуска. Управление временем запуска (RunTime Control - RTC) - механизм, при котором операция, выполняемая одним ресурсом группы, запускается, без вмешательства клиента, согласно условию, существующему в другом ресурсе этой группы. При реконфигурации группы значения атрибута RTC, установленные для группы, не сохраняются.
медив-потоки
Первичные ресурсы. Первичны 询 ресурс обладает двумя портами — первичным и вторичным. Стандарты ECTF определяют следующие первичные ресурсы:
Switch Port Resource (SPR) - это ресурс коммутации, обеспечивающий соединение внешних устройств с группой;
Conference Port Resource (CPR) - ресурс, организующий конференц-мост между вторичными ресурсами. Он принимает медиа-потоки от всех вторичных ресурсов и передает обратно суммированный медиа-поток;
Call Channel Resource (CCR) - это ресурс, через который производится прием медиа-потока от медиа-устройства доступа. Таким образом, при необходимости принимать медиа-поток от устройства доступа, сервер включает этот ресурс в конфигурацию группы, тем самым обеспечивая доступ медиа-потока от MAD (Media Access Device -медиа-устройство доступа) ко вторичным ресурсам.
Втсюинные ресурсы. Вторичные ресурсы используются для выполнения таких операций как обнаружение сигнала, распознавание речи, прием, запись, воспроизведение и отправление факсимильных сообщений, а также для передачи и приема медиа-потока. В отличие от первичных, вторичные ресурсы обладают только первичными портами.
Структура пэуппн. Группа обычно содержит первичный ресурс и один или несколько вторичных ресурсов, описываемых атрибутами, параметрами, медиа-потоками, которые они обслуживают; и другими характе ристи кам и. Когда медиа-поток выделен первичным ресурсом, он передается одновременно ко всем вторичным ресурсам, но принимается только тем из них, для которого эта информация предназнамается. Для того чтобы не происходило смешивание медиа-потоков противоположных направлений или их искажение, используется арбитражная схема, определяющая порядок, согласно которому вторичный ресурс получает право передавать информацию к первичному ресурсу.
Конфигурация пэуппы. Конфигурация группы-этоспецификация используемых ресурсов (и их атрибутов). Медиа-потоки в описание конфигурации группы не входят, так как внутренние потоки (между первичным и вторичным ресурсами) управляются сервером и полностью определяются типом ресурсов, а внешние потоки контролируются клиентом.
В процессе работы приложения сервер и клиент используют информацию, из файла Application profile. Этот файл содержит сведения о конфигурации группы и другие данные.
Файл ^plication profile передается на сервер перед выполнением клиентского приложения, и с этого момента клиент, чтобы из-
менить настройку группы, может обратиться к специальным данным о конфигурации группы (particular group configuration) через идентификатор, определенный в файле Application profile.
Стек дппы. Группа всегда имеет пользователя и клиента, хотя пользователь может меняться. Стек группы содержит имена всех пользователей, которые работают с группой в данный момент, причем имя текущего пользователя всегда находится на вершине стека. Если клиенту данная группа больше не нужна, он может удалить свой идентификатор из стека. Клиенты могут манипулировать стеком только косвенно, через команды и события, имеющие отношение к группе (handoff and return).
Парамбт|эы пэуппы. Параметр группы ~ это элемент, содержащий информацию о состоянии группы. При реконфигурации группы значения параметров группы не сохраняются.
ЖнзнбннЕиб никлы пэуппы.
Создание группы. Клиент может создать группу определенной конфигурации с помощью команды C7grp_Create(). Получив эту команду, сервер проверяет, достаточно ли свободных ресурсов для того, чтобы реализовать запрошенную конфигурацию. Если серверу не доступен какой-нибудь ресурс, команда вернется с соответствующими данными об ошибке. Если все требуемые ресурсы доступны, сервер создает группу и передаетуправление клиенту, помещая его имя на вершину стека. Чтобы группа была готова к работе, необходимо приписать ей определенные устройства и медиа-потоки.
Назначение ресурсов группы. Режим назначения ресурсов предназначен для подготовки созданной группы к работе. Он назначает для группы набор устройств и медиа-потоков, соответствующих ее конфигурации. Существуют два режима назначения: статический и динамический. В статическом режиме все необходимые устройства и медиа-потоки назначаются сразу же после создания группы и освобождаются только после завершения ее работы.
Сервер, поддерживающий динамический режим, назначает ресурсы только тогда, когда они нужны в работе приложения. Например, ресурс воспроизведения назначается только после команды CTplyr_Play(), или если в группе, которая включает в себя этот ресурс, установлено время запуска RTC.
Каждый из названных режимов имеет и преимущества, и недостатки. Статическое назначение гарантирует клиенту, что все операции группы будут выполнены, и ситуация отсутствия ресурса не возникнет. Динамическое назначение исключает захват ресурса одной группой и позволяет серверу оптимизировать его использование, однако при этом есть риск, что нужный ресурс к моменту выполнения операции окажется не готов или занят.
Режим назначения можно установить для всех устройств в группе сразу или для каждого в отдельности. Так, с помощью команды CTgrp_Allocate() устанавливается статический режим, а команда C7grp_Deallocate() снимает эффект CTgrp_Allocate(), заставляя ресурсы снова перейти в динамический режим назначения.
Работа группы. Каждая группа может выполнять как одну, так и несколько операций, в зависимости от набора ресурсов, определенных в конфигурации. Некоторые операции при их выполнении могут конкурировать друг с другом, например, несколько вторичных ресурсов могут пытаться передать данные к первичному ресурсу. Спор о порядке доступа решается с помощью арбитражной схемы.
Клиентможет инициировать операции в группе вводом специальных команд. Во время операции первичные и вторичные ресурсы группы обмениваются медиа-потоками. Все медиа-потоки, идущие от первичного ресурса, направляются одновременно ко всем вторичным ресурсам, а те, в зависимости от передаваемого медиа-потока, определяют, которому из них он предназначен. Для определения порядка передачи медиа-потоков вторичными ресурсами используется арбитражная схема.
Реконфигурация группы. Клиент может инициировать реконфигурацию группы, и в ней будет изменен набор вторичных ресурсов. Когда к серверу поступает команда изменить конфигурацию группы, он проверяет наличие необходимых для этого ресурсов. При положительном результате проверки сервер освобождает ресурсы, не нужные в новой конфигурации, и добавляет требующиеся новые ресурсы. Группа может быть перестроена после команды CTgrp_Con, или при переключении (handing-off) группы от одного клиента другому, если новый клиент определяет, что конфигурация переданной группы не совпадает с той, которая необходима.
Переключение и возврат группы. Группа может быть переключена к новому клиенту или возвращена предыдущему. Для выполнения этих функций используется стек группы. Клиент может передать группу другому клиенту, вернуть группу другому клиенту, или забрать «свою» группу у другого клиента.
Для переключения группы к себе клиент посылает команду Clscr_RequestGroup(), тем самым регистрируя себя на сервере. Клиент, владеющий этой группой, передает команду CTgrp_Handoff (). Как только команда C7grp_Handoff() получена, сервер останавливает все операции, инициированные ресурсом в группе, и посылает прежнему клиенту уведомление о завершении операции. Если операция заканчивается неудачей, прежний клиент сохраняет право владения группой, а клиент, запросивший переключение, получает уведомление о невозможности выполнить данную операцию.
При возврате группы владелец «чужой» группы возвращает ее прежнему владельцу, посылая команду Clgrp_Return(), содержащую одну или несколькими отметок (catch tag). Сервер будет искать в стеке, начиная с его вершины, первого клиента с заданной отметкой. Если отметка обнаружена, сервер останавливает все операции, выполняемые ресурсами в группе, и посылает клиенту, возвращающему группу, уведомление о завершении операции. Если для возвращаемой группы не найдено сопоставимой отметки, группа уничтожается. В этом случае клиент, который инициировал возврат группы, получает уведомление Group_ECTF_Return, а каждый промежуточный клиент (т.е. клиент, которому эта группа была передана, но затем он сам передал ее третьему клиенту) получает сообщение Group_ECTF_Unwind. Управление группой со стороны клиента, который возвращал группу, и со стороны промежуточных клиентов становится невозможным.
Восстановление группы. Клиент, прежде владевший группой, может принудительно восстановить себя как ее владельца. Такая операция может быть выполнена путем передачи к серверу команды C7grp_Retrieve(). Сервер останавливает все операции, выполняемые ресурсами в группе, затем выполняет следующие независимые от клиента шаги: (а) меняет клиента, в данный момент владеющего группой, на клиента, запросившего восстановление, посылает клиенту, временно владевшему группой, и всем промежуточным клиентам уведомление о завершении операции Group_ECTF_Unwind; (б) конфигурирует группу в том виде, в каком она была до переключения к временному владельцу.
Удаление клиента из стека. Когда имя клиента находится в стеке группы, он может получить ее путем возврата (в зависимости от отметки, которую он установил, когда передавал эту группу). Имя клиента, который в настоящее время владеет группой, при передаче группы другому клиенту автоматически удаляется с вершины ее стека. Даже если клиент устанавливает отметку «Group_ECTF_NeverRe- turn», его имя все равно остается в стеке, и он может продолжать получать уведомления из группы. Клиент может передать группу с удалением своего имени из стека, что произойдет после того, как клиент введет команду CTgrp_Handoff() и установит отметку «Group_ECTF_RemoveSession». Переключение группы и удаление имени клиента из стека выполняется как единое действие, не зависящее от клиента. Клиент, передавая группу, может также удалить свое имя из стека, введя команду Clgrp_Return() и установив при этом отметку «Group_ECTF_RemoveSession». Особый случай возникает, если уведомление о возврате группы Group_ECTF_Returned было послано клиенту после команды переключения группы с удалением имени клиента из стека Clgrp_Return(...«Group_ECTF_RemoveSes- sion»...). В этом случае, даже если уведомление было доставлено клиенту, сервер произведет рестарт операции возврата, вызывавшей данное событие.
Уничтожение группы. Клиент уничтожает группу с помощью команды Clgrp_Destroy(). Группа уничтожается, когда она возвращается серверу. Когда группа уничтожена, ее устройства и медиа-потоки освобождаются и могут использоваться в других группах. Таким образом, группа больше не существует в структуре.
Арбитражная схема. Каждая группа связана с арбитражной схемой, определяющей порядок в очереди вторичных ресурсов, которым требуется передать данные к первичному ресурсу. Предусмотрено пять арбитражных схем: «передает последний» (last talker); «передает первый» (first talker), «блокировка» (blocking), «приоритет» (preemption) и «суммирование» (summing). То, какую арбитражную схему надлежит использовать, определяется в параметре сервера Group_ECTF_Arbit- rationScheme, который может принимать одно из пяти значений: Group_ECTF_LastTalker, Group_ECTF_Firstlalker, Group_ECTF_Blocking, Group_ECTF_PreEmption или Group_ECTF_Summing. В настоящее время алгоритмы работы арбитражных схем находятся в стадии разработки, так что принцип их действия в разных реализациях может быть разным.
Арбитражная схема «Передает последний». При использовании этой схемы (рис. 9.17) вторичный ресурс, передающий медиа-поток к первичному ресурсу, останавливает передачу в случае, если появился запрос передачи от другого вторичного ресурса. Он сможет возобновить передачу своих данных только после того, как закончат передачу все ресурсы, запросившие передачу после него. Прерванная передача медиа-потока может быть продолжена с той точки, где была прервана, или может быть продолжена с более поздней отметки (в зависимости от типа ресурса и его реализации).
первичныймедиа-поток
ИсточникИсточникИсточникИсточник6. Восстанавливается медиа-поток источника 16. Восстанавливается медиа-поток источника 17. Первичный ресурс принимает данные от источника 17. Первичный ресурс принимает данные от источника 11. Первичный ресурс принимает данные источника 11. Первичный ресурс принимает данные источника 13. Медиа-поток источника 1 отсоединяется от первичного ресурса3. Медиа-поток источника 1 отсоединяется от первичного ресурса2. Источник 2 запрашивает передачу2. Источник 2 запрашивает передачу4. Источник 2 начинает передачу4. Источник 2 начинает передачу/Первичный/ПервичныйресурсресурсИсточник 2 завершаетпередачу и уведомляетоб этом сервер
Источник
Источник
Источник
Источник
6. Восстанавливается медиа-поток источника 1
6. Восстанавливается медиа-поток источника 1
7. Первичный ресурс принимает данные от источника 1
7. Первичный ресурс принимает данные от источника 1
1. Первичный ресурс принимает данные источника 1
1. Первичный ресурс принимает данные источника 1
3. Медиа-поток источника 1 отсоединяется от первичного ресурса
3. Медиа-поток источника 1 отсоединяется от первичного ресурса
2. Источник 2 запрашивает передачу
2. Источник 2 запрашивает передачу
4. Источник 2 начинает передачу
4. Источник 2 начинает передачу
/Первичный
/Первичный
ресурс
ресурс
Арбитражная схема «Передаетпервый». При использовании этой схемы ресурсы передают свои данные в том порядке, в каком от них поступают зап росы. Если запрос поступает, когда уже ведется передача, подавший его ресурс ставится в очередь. Группа, подключенная к другой группе в качестве вторичного ресурса, также рассматривается арбитражной схемой как вторичный ресурс.
Арбитражная схема «суммирование». При такой схеме все вторичные ресурсы могут передавать медиа-потоки одновременно. Эта схема применяется к группам, первичный ресурс которых является ресурсом конференции (CPR).
Конкурирующие команды. Группа может исполнять несколько команд параллельно, однако имеются ограничения, которые, в основном, касаются команд создания, уничтожения, конфигурирования и переключения групп.
Возможны следующие варианты:
Override - новая команда не может быть исполнена одновременно с уже исполняемой командой; она останавливает ее исполнение, после чего исполняется сама;
Queue - новая команда не может быть исполнена одновременно с уже исполняемой командой; она должна ждать, пока предыдущая команда не будет исполнена;
Execute - новая команда исполняется одновременно с уже исполняемой командой.
Управление временем запуска (Run Time Control (RTC)) - это механизм, посредством которого режим исполнения команды одним ресурсом группы можетбыть изменен в результате события, произошедшего в другом ресурсе той же самой группы. Для механизма RTC определяются условие и результат. Условием может быть ситуация, возникающая внутри ресурса, такая, например, как окончание воспроизводимого ресурсом звукового объекта или обнаружение DTMF- сигнала. Условия бывают специфическими для каждого класса ресурсов. Результат есть изменение, которое ресурс может внести в режим исполнения команды, такое, например, как изменение скорости или объема воспроизведения. Результаты, подобно условиям, являются специфическими для каждого класса ресурсов.
RTC может быть установлен для группы постоянно и оставаться в силе до тех пор, пока очередной владелец группы не отменит его, или до того, как группа не сменит владельца в результате переключения или возврата. Этот механизм устанавливается и отменяется по команде C7grp_SetRTC(). Он может быть определен как часть конфигурации группы параметром <RTC_Settings> в файле Application profile. И тоща необходимое время запуска назначается при создании группы. Можно также задавать определенные механизмы за-
пуска, определяя RTC как аргумент в командах данному ресурсу (например, CTplyr_Play()). Однако такой RTC устанавливается только на время исполнения команды.
Соединения между группами. Группы могут быть связаны между собой медиа-потоками с использованием соответствующих соединений. Такие межгрупповые соединения могут потребоваться:
если в обслуживании вызова принимают участие разные группы;
чтобы подключить одну группу к другой в качестве вторичного ресурса;
чтобы соединить несколько групп для организации конференции.
После создания медиа-потока должны быть определены характеристики соединения, отвечающие характеристикам этого потока. Соединения между группами могут быть однонаправленными (Unidirectional), двунаправленными (Bi-directional) и вещательными (Опе- to-Many).
9.7 Протокол Parlay API
Как уже отмечалось в плаве 3, протокол Parlay API ориентирован на управление сетевыми ресурсами. Он позволяет значительно расширить диапазон используемых приложений и тем самым расширить функциональные возможности сети. Другие положительные характеристики Parlay API состоят в том, что он:
объектно-ориентированный,
мультимедийный,
управляемый,
простой,
расширяемый для поддержки новых услуг;
обеспечивающий независимость приложений от сетевых технологий.
Parlay API имеет две составляющие: интерфейсы структур и интерфейсы услуг Интерфейсы структур обеспечивают инфраструктуру для поддержки услуг и независимы от самой услуги, обеспечивая лишь инструментальные средства, необходимые для пользования разнообразными услугами. Интерфейсы услуг представляют собой программные модули вертикальной технологии, с помощью которых создаются приложения.
9_7_1 Интерфейсы структур
АутентификацияfAuthentication). Приложения используют структуру аутентификации для того, чтобы информировать Parlay API о том,
кто они такие. Существует много методов аутентификации, которые могут применяться, включая шифрование и цифровые (электронные) подписи.
Обнаружение (Discovery). После того как успешно пройдена фаза аутентификации, приложение может использовать структуру обнаружения для нахождения требуемых ему услуг
Уведомление о событии (Event notification). Структура уведомления о событии используется, чтобы информировать приложения □ моментах, когда происходят типовые события, относящиеся к услугам.
Управление целостностью (Integrity management). Структура управления целостностью позволяет приложению быть в курсе, когда возникают проблемы с Parlay API или с конкретной услугой.
Администрирование и обслуживание в процессе эксплуатации (ОА&М). Для версии 1.2. Parlay, функциональные возможности ОА&М ограничены запросами времени и даты.
9-7-2 Интерфейсы услуг
Общее управление обслуживанием вызовом. Эта услуга обеспечивает базовые функции управления обслуживанием вызова с участием других оконечных устройств (third-party call control) и может обрабатывать вызовы с коммутацией каналов и с коммутацией пакетов. Эта услуга детализируется в отдельных спецификациях управления обслуживанием вызова (т.е. ISUP, Н.323, SIP).
INAP. Услуга INAP расширяет общую услугу управления обслуживания вызова и обеспечивает дополнительные функциональные возможности, например, возможность запроса дополнительных цифр номера и возможность контроля процесса установления соединения.
Общий обмен сообщениями. Эта услуга позволяет приложениям передавать, хранить и принимать сообщения. Текущая версия поддерживает как электронную почту, так и речевую почту. Обеспечивается возможность управления почтовыми ящиками, папками и сообщениями.
Взаимодействие с пользователем. Услуга общего взаимодействия с пользователем позволяет разнообразным приложениям взаимодействовать с конечным пользователем.
Взаимодействие с участниками связи. Эта услуга расширяет услугу общего взаимодействия с пользователем и позволяет приложениям взаимодействовать с участниками сеанса связи. Она обеспечивает передачу участникам объявлений и получение от них сигналов обратной связи (сигналов DTMF).
Интерфейсы управления ресурсами
Интерфейсы управления ресурсами являются средством, с помощью которого продукт Parlay взаимодействует сетевыми элементами. Группа Parlay не специфицирует эти интерфейсы. Скорее всего, для каждого блока оборудования в сети, который взаимодействует с конкретным продуктом Parlay, будет требоваться адаптер. Эти адаптеры могут либо поставляться производителем оборудования или независимыми поставщиками в виде отдельных устройств, либо включаться в состав продукта Parlay. Доступность адаптеров ресурсов может оказывать большое влияние на возможности продукта Parlay. Создание адаптеров ресурсов потенциально сопряжено с трудностями. Похоже, что доступность адаптера ресурсов будет наиболее критическим фактором в использовании Parlay.
Архитектура Parlay API
Архитектуру Parlay API составляют интерфейсы нескольких категорий, о чем говорилось выше в этом параграфе (рис.9.18).
Рис. 9.18 Архитектура Parlay APIРис. 9.18 Архитектура Parlay API
Рис. 9.18 Архитектура Parlay API
Рис. 9.18 Архитектура Parlay API
Поскольку Parlay представляет собой спецификацию API, он не диктует какую-либо конкретную физическую архитектуру. Приложения могут размещаться или не размещаться на том же компьютерном элементе, что и программа Parlay. Программа интерфейса управ-
ления ресурсами может размещаться на том же центральном процессоре, что и программа Parlay, функционировать на промежуточном компьютерном элементе или же существовать непосредственно на оборудовании, которым она управляет.
Приложения существуют вне домена сети и взаимодействуют с сетью через Parlay API, причем Parlay API не специфицирует, каким образом будет происходить связь между приложениями и API. Для этой цели будет, скорее всего, использоваться промежуточное ПО, вроде CORBA. Такое же промежуточное ПО может служить в качестве коммуникационного моста между API и интерфейсами управления ресурсами.
Как правило, Parlay API функционирует на машине, называемой шлюзом Parlay. Этот шлюз соединяется с приложениями через 1Р-сеть. Адаптеры ресурсов Parlay, скорее всего, также подключаются к шлюзу через IP-сеть. Соединение между адаптерами ресурсов и оборудованием, с которым они стыкуются, зависит оттого, насколько близко к оборудованию размещается тот или иной адаптер. На этапе выполнения приложения будут взаимодействовать с сетью путем вызовов от API к шлюзу. Эти вызовы будут иногда приводить к взаимодействию между шлюзом и адаптером. Если адаптер связан с протоколом, он может посылать пакеты в сеть ОКС7.
Можно с уверенностью сказать, что Parlay API предлагает поставщикам сетевых услуг и разработчикам независимых приложений подход самого высокого уровня к созданию дополнительных услуг в конвергентной сети. Примеры функциональных возможностей, обеспечиваемых с помощью определенных в версии Parlay 1.2 интерфейсов -установление подлинности, обнаружение, уведомление о событиях, организация управления, - уже рассматривались выше вместе с интерфейсами услуг; обеспечивающими общие услуги управления обслуживанием вызова, услуги INAR общие услуги обмена сообщениями, общие услуги пользовательского взаимодействия и др.
Подчеркнем, что ресурсы API обеспечивают структурные подходы для интегрирования уже существующих сетевых ресурсов в API интерфейс. Например, существующие интерфейсы типа Н.323 или INAP могут быть использованы интерфейсом РаИауАРЦтакчто отпадает необходимость заново разрабатывать уже существующие протоколы.
Преимущества архитектуры Parlay API открывают хорошие перспективы сетевым операторам, операторам услуг; разработчикам приложений и конечным пользователям. Для сетевых операторов это могут быть: рост телефонной нагрузки, как следствие увеличения количества услуг; уменьшение времени, необходимого для ввода услуг, за счет партнерства с операторами услуг; новый шаг к конвергенции сетей. Для операторов услуг - это возможность развер-
тывать новые услуги, используя API; уменьшение времени, необходимого для ввода услуг, поскольку не требуется их тестирование с сетевым оператором; взаимозаменяемость приложений, поскольку API скрывает детали исполнения. Для разработчиков приложений Parlay API обеспечивает новые возможности, ранее технически не выполнимые (так как приложениям не были доступны функциональные возможности сетевого оператора); поддерживает разработку приложений независимыми разработчиками; предоставляет инструментальный набор для разработки программ, делающий ее простой и рентабельной. И, наконец, создаваемое с помощью Parlay API алгоритмическое обеспечение обладает следующими преимуществами: уменьшение времени реализации услуг; сохранение контроля баз данных и других функций; возможность выбора приложений из широкого перечня; возможности интеграции новых телекоммуникационных приложений с другим программным обеспечением.
9.8 Интерфейсы JAIN
Интерфейсы Java API для интегрированных сетей (JAIN) появились в июне 1998 года, когда Sun Microsystems и некоторые другие компании анонсировали это техническое решение на базе Java-технологии для создания и развертывания дополнительных телекоммуникационных услуг; сочетающее в себе технологии Интеллектуальной сети и сети Интернет. Первоначально акроним JAIN означал развитую И нтел л ектуа л ьн ую сеть (AIN) на базе Java, но впоследствии он стал расшифровываться как «Java API для интегрированных сетей», поскольку первая версия прочтения перестала устраивать разработчиков по ряду причин.
JAIN содержит библ иотеку программных компонентов, среду создания услуг (SCE) и среду выполнения логики услуг (SLEE). Библиотека компонентов является расширением стандартной иерархии Java. SCE представляет собой контейнер, содержащий Java-элементы (Java beans), который позволит строить услуги, используя графический пол ьзовател ьский интерфейс для динамического связывания компонентных элементов. SLEE представляет собой среду выполнения, в которой будут работать услуги JAIN. Она будет управлять услугами, ресурсами, необходимыми для их работы, и их взаимодействием с сетью. В некотором смысле она аналогична шлюзу Parlay.
Программные компоненты JAIN разбиты на две разные категории. Первая категория - это протокольная часть. Над этими частями JAIN работает экспертная группа по протоколам (PEG - Protocols Expert Group). Их работа состоит в определении интерфейсов API для прикладной подсистемы поддержки транзакций (ТСАР) ОКС7, подсис-
темы ISDN (ISUP) OKC7, подсистемы подвижной связи (MAP) 0КС7, протоколов системы эксплуатационного управления (ОА&М), протокола управления транспортными шлюзами (MGCP), протокола Н.323 и протокола инициирования сеансов связи (SIP).
Вторая категория компонентов JAIN - прикладная. Ею занимается экспертная группа по приложениям (Application Expert Group, AEG). Эта категория включает в себя интерфейсы API более высокого уровня, чем протокольные API, а именно:
API управления обслуживанием вызовов JAIN и API координации и транзакций JAIN. Эти API представляют собой набор независимых от сетевых технологий стандартных программ высокого уровня для управления обслужи ван ием вызовов. Используя эти API, можно прозрачно маршрутизировать вызовы через сети разных типов.
АР! защищенного дьступаксети. JAIN использует рассмотренные в предыдущем параграфе спецификации Parlay для обеспечения защищенного доступа к сетевым возможностям.
API создания услуг и выполнения логики услуг. Определяет услуги, наличие которых гарантировано в SCE и SLEE и которые предназначены для создания услуг с использованием программных модулей SCE.
API управления обеспечением связи. Обслужи вают сетевую стратегию и соединения. Более четкое определение на настоящий момент отсутствует
JAIN и рассмотренный в предыдущем параграфе Parlay видятся как дополняющие друг друга решения. Компания Sun отстаивает использование Java и JAIN для построения услуг и шлюзов Parlay. Sun добавляет в JAIN Parlay-иерархию API. В некоторых направлениях, таких как безопасность, Parlay API может обеспечивать все функциональные возможности JAIN.
Разработка открытых интерфейсов API, таких как JAIN и Parlay, направлена на упрощение создания, тестирования и поддержки дополнительных услуг в конвергентной сети. Фактически эти API будут, по всей видимости, основной движущей силой конвергенции, поскольку они должны облегчить создание услуг в сетях разных видов: проводных и беспроводных, для речи и для данных, общего пользования и корпоративных. Авторы отказались от более подробного изложения алгоритмических методологий и моделей обслуживания вызовов в компьютерной телефонии, так как их сдерживали и допустимый объем главы, и известное правило: как только технология становится привычной и понятной всем, ее пора менять. Это правило справедливо не только для алгоритмического, ноидля программного обеспечения Call-центров и компьютерной телефонии, рассматриваемого в следующей главе.
Глава 10
Программное обеспечение
Если программа тебе понятна, значит она уже устарела.
Правило Биттона
Основные компоненты программного обеспечения
Работая над двумя последними главами, авторы не раз вспоминали постулат Бенджамина Дизраэли, согласно которому лучший способ ознакомится с предметом - написать о нем книгу. Читатель, который добрался до этого места, тоже уже неплохо знаком с предметом. Но обольщаться не стоит ни авторам, ни читателям. Мы имеем дело с новой, бурно развивающейся областью, где методы и языки программирования, как и технологические принципы разработки программного обеспечения, все время изменяются в полном соответствии с приведенном в качестве эпиграфа правилом.
Программное обеспечение (ПО) систем компьютерной телефонии представляет собой сложную многофункциональную систему, в составе которой можно выделить следующие компоненты и подсистемы: программные реализации стеков протоколов, различные программные интерфейсы (API), пользовательские интерфейсы. Естественно, что архитектура программного обеспечения CTI зависит от операционной системы, поддерживаемых приложений, используемых аппаратных средств. Однако в данном параграфе мы будем рассматривать обобщенную архитектуру, которая от всего этого практически независима. Такую архитектуру ПО CTI можно представить в виде стека, изображенного на рисунке 10.1
Далее мы опишем каждый из представленных на рисунке компонентов.
Операционные системы
Операционная система (ОС) является промежуточным звеном между аппаратными средствами (базовой системой ввода/вывода BIOS, например) и работающим в данной компьютерной системе программным обеспечением. К задачам ОС относятся запуск программ, управление ресурсами компьютера, обработка обращений программ к системе ввода/вывода и т.д. Самыми распространенными операционными системами для Call-центров и другого оборудования компьютерной телефонии являются MS-DOS, Windows 95\98\NT, OS/2, различные UNIX-подобные ОС (SCO Unix, Linux, QNX и др.).
Операционная система MS-DOS являлась основной ОС, поставляемой с персональными компьютерами IBM PC. Интерфейс MS-DOS изначально ориентирован на использование командной строки. Когда-то самая распространенная, сейчас эта ОС стала морально устаревать, т.к. она не может работать в защищенном режиме, не позволяет полноценно использовать возможности современных процессоров, не обеспечивает удаленного доступа к системе для контроля и управления, имеет примитивный пользевательск ий интерфейс и т.д. Тем не менее, ряд систем CTI и сегодня работает под ее управлением. Следует отметить, что на первом этапе развития систем компьютерной телефонии MS-DOS получила значительное распространение, главным образом, благодаря тому, что она крайне нетребовательна к ресурсам персональных компьютеров, которые в те годы были весьма и весьма ограничены.
Рассмотренное в главе 2 движение связистов и компьютерщиков навстречу друг другу н и когда не ограничивалось только компьютерной телефонией. Среди многих достижений связистов, которые потом стали широко использоваться и в других областях, почетное ме-
сто занимает операционная система UNIX. Её разработали в 1970-х годах два сотрудника Bell Laboratories 一 Кен "Томас и Деннис Ритчи - для использования в телекоммуникационных системах. UNIX является многозадачной, многопользовательской системой, она может работать на компьютерах (точнее, на аппаратных платформах) практически всех видов (IBM PC, SUN, HP). UNIX-подобные ОС характеризуются эффективным использованием вычислительных ресурсов процессоров, эффективной системой управления защитой и правами доступа, обеспечивают возможность удаленного управления программно-аппаратными комплексами, использующими эти ОС, имеют удобный и развитый встроенный язык написания скриптов (приложений). Недостатком этих ОС является их громоздкость, сложность установки и конфигурирования, а также громадное число версий, причем зачастую программы, написанные для одной версии, неправильно работают (или вообще не работают) на другой. Эти причины, наряду с отсутствием удобных средств разработки и, в известной степени, закрытостью технологий (ОС UNIX входила в список продуктов, экспорт которых из США в страны Восточной Европы был до 1992 года запрещен СОСОМ), долгое время существенно сдерживали широкое внедрение UNIX-подобных ОС в системах CTI. Сегодня ситуация коренным образом изменилась, в частности, благодаря появлению ОС с открытым исходным кодом Linux, росту вычислительных мощностей компьютеров и большей открытости рынка инфокоммуникаций. Однако об этом - чуть позже.
В 1985 году появилась операционная система Windows, первоначально разработанная корпорацией Microsoft как графическая обо- ломка DOS. Однако первые версии этой ОС не сильно отличались от прародителя, их функциональные возможности были ограничены. Поэтому IBM и Microsoft приступили к разработке операционной системы Windows OS/2 (Operation system 2), которая должна была обладать такими достоинствами UNIX-подобных систем, как наличие системы защиты, многозадачности и расширенной памяти, сохраняя при этом присущие Windows удобства установки и конфигурирования и удобный графический интерфейс пользователя. OS/2 была предназначена для процессоров 386, 486 или Pentium. Однако стремительное развитие индустрии высоких технологий привело ктому, что рынок операционных систем для подавляющей части персональных компьютеров распался на два широких потока 一 UNIX-подобные ОС и OCWindows. В этой ситуации OS/2 оказалась в роли «третьего лишнего», хотя система, в общем-то, весьма перспективна и сегодня используется некоторыми разработчиками.
Тем временем, компания Microsoft продолжала работу над Windows, и в 1990 году вышла новая графическая оболочка Windows 3.0, а чуть позже - ее сетевая версия Windows 3.11. Она имела удобный графический интерфейс, работала с виртуальной памятью, была многозадачной. Однако Windows 3.0 еще не была полноценной one-
рационной системой, она лишь дополняла функции MS-DOS. Тем не менее, популярность этой ОС была огромной. В 1993 году выходит новая версия ОС от Microsoft - Windows NT работающая с FAK HPFS и имеющая свою файловую систему NTFS. Это действительно был прорыв в области операционных систем для персональных компьютеров. Хотя система не была лишена недостатков (например, значительное время загрузки), она обладала рядом функций, новых для ОС персональных компьютеров. Здесь имеются в виду встроенная система защиты, 32-разрядные API, улучшенная поддержка многозадачности, расширенные возможности работы с сетью.
NT впервые позволила создавать на базе ОС весьма надежные производительные приложения компьютерной телефонии, далеко выходящие за рамки компьютерных номеронабирателей и прочих средств персонального пользования, составлявших системы CTI первого поколения. Именно для Windows NT появилось значительное количество служебных приложений и пакетов программ, без которых появление полноценных систем CTI было бы немыслимо. Это и базы данных, и библиотеки создания многопотоковых приложений. Речь идет о разработанной в 1997 году компанией Microsoft архитектуре DCOM, специально ориентированной на распределенные приложения. При этом сама Windows NT продолжала интенсивно развиваться, и сегодня можно сказать, что по распространенности ее более поздних версий среди операционных систем, используемых в компьютерной телефонии, NT пока удерживает лидерство.
В 1995 году выходит операционная система Windows 95, представляющая собой высокопроизводительную, многозадачную и многопотоковую псевдо-32-разрядную (с 16-битовым ядром) ОС с графическим интерфейсом и расширенными сетевыми возможностями, работающую в защищенном режиме. Фактически, Windows 95 - это первая графическая операционная среда для компьютеров IBM PC с 32-разрядной архитектурой. Операционная система Microsoft Windows 98 - это обновление Windows, расширяющее функциональные возможности компьютера. Простой доступ к Интернет, высокая производительность системы, поддержка шины Universal Serial Bus (USB), улучшение качества воспроизведения графики, звука и мультимедийных приложений, новые служебные программы и средства диагностики - всё это повысило эффективность применения Windows в оборудовании компьютерной телефонии. К тому же, Windows 98 сохраняет совместимость с приложениями и технологиями, разработанными для старых версий Windows.
Однако вернемся к операционным системам, развившимся на базе ОС UNIX. Из всего их многообразия выделим две, которые, на взгляд авторов, в значительной степени способствовали (по разным причинам) росту популярности UNIX-подобных ОС среди разработчиков систем компьютерной телефонии.
Первая версия ОС QNX была разработана еще в 1982 г. фирмой Quantum Software Systems (Канада) по заказу Министерства обороны США. Операционная система QNX - это надежная и масштабируемая многопользовательская многозадачная сетевая ОС реального времени, т.е. система, ядро которой обеспечивает гарантированное время обработки прерываний со стороны устройств, подключаемых к шинам ISA или PCI персонального компьютера. Другая важная особенность QNX-ee модульность: основные функции ОС выполняются независимыми процессами, которые взаимодействуют между собой с помощью специального механизма, даже будучи запущенными на разных компьютерах. Еще одной важнейшей особенностью ОС QNX является ее компактность. Ядро этой ОС может быть установлено с дискеты и занимает единицы мегабайтов, что позволяет не применять в отдельных элементах систем CTI потенциально опасные с точки зрения надежности винчестеры, а использовать в качестве носителей информации высоконадежные FLASH-накопители.
Целый ряд систем упоминавшейся выше интеллектуальной платформы ПРОТЕЙ работает именно под QNX. Это позволило достичь нескольких важных результатов. Во-первых, удалось получить высокую производительность модулей - обработка десятков тысяч вызовов в час. Во-вторых, стало возможным отказаться от использования жестких дисков в коммутационных модулях системы, что существенно повысило надежность этих модулей. И, наконец, удалось отказаться от трудоемкого процесса написания и отладки драйверов телекоммуникационных плат (о том, зачем они нужны, 一 чуть ниже), возложив функции отработки прерываний со стороны аппаратного обеспечения непосредственно на прикладное ПО.
К сожалению, лихорадочное развитие рынка высоких технологий (в том числе, рынка ПО) в западных странах привело к тому, что разработка новых версий ОС QNX сегодня явно направлена на встроенные системы (банкоматы, справочные терминалы и т.п.), хотя, сточки зрения авторов, потенциал QNX как операционной системы для персональных компьютеров ее разработчики использовали далеко неполностью.
Практически все ПО рассмотренного в главе 8 Web-контакт-цен- тра ПРОТЕЙ, как и ПО многих из остальных подсистем этой интеллектуальной платформы, функционирует под управлением другой Unix-подобной операционной системы Linux, которая произвела, без преувеличения, мини-революцию на рынке ОС для персональных компьютеров.
Эта многопользовательская сетевая операционная система обладает всеми преимуществами UNIX, имеет удобную графической оконную систему X Window System, достаточно удобна в установке и конфигурировании, поддерживает стандарты открытых систем, име-
ет хорошую систему защиты, надежна, поддерживает весь спектр протоколов сети Интернет, обладает массой возможностей гибкой обработки и маршрутизации IP-трафика. В то же время, система достаточно компактна, что позволяет устанавливать определенным образом сконфигурированное ядро на FLASH-накопители. Для Linux существует масса приложений, адаптирующих систему под нужды любого пользователя, будь он пользователь персональным компьютером (существует весьма удобный пакет - аналог Microsoft Office) или разработчик телекоммуникационных приложений (наличие высоконадежной файловой системы, удобные отладчики и пр.). И, самое главное, - все компоненты системы, включая исходные тексты, распространяются с лицензией на свободное копирование и установку для неограниченного количества пользователей, что обусловило широкое распространение ОС Linux на платформах PC 486/Реп- tium/Pentium Pro и др. и стремительный рост популярности Linux в последние годы. Разработка ОС Linux выполнена Линусом Тэрвалдсом из университета Хельсинки и командой из тысяч пользователей Интернет, сотрудников исследовательских центров, фондов, университетов и т.п.
В заключение параграфа следует упомянуть о драйверах устройств -специальных программах, которые управляют информационным обменом между процессором и периферийным устройством, либо стандартным (монитор, дисковод, клавиатура), либо специализированным (интерфейсная телекоммуникационная плата). Драйвер должен «иметь представление» о специфике работы устройства, знать команды управления им и формат сообщений, посредством которых с ним производится обмен информацией, а потому каждое периферийное устройство имеет свой драйвер. Кроме того, специфической задачей драйверов телекоммуникационных плат является обработка большого потока данных между платой и процессором с минимальными задержками и с сохранением защиты ядра ОС от несанкционированных обращений в моменты выполнения разного рода системных функций.
Драйвер выполняет следующие функции:
Прием и обработка запроса к периферийному устройству, которое драйвер обслуживает. После этого драйвер должен выдать запрос периферийному устройству в приемлемом для этого устройства формате.
Обработка прерываний со стороны устройства. Действия драйвера могут быть различными: передача управления операционной системе, выполнение какой-либо подпрограммы и т.д.
Драйверы делятся на два типа - встроенные и загружаемые. Драйверы первого типа находятся, например, в ОС в качестве составной части ядра. Эти драйверы подключаются к системе автоматически
при загрузке и обеспечивают работу стандартных устройств (например, портов, видеоадаптеров). Драйверы второго типа подключаются динамически при необходимости обеспечить работу с нестандартными устройствами.
■ ПО обработки медиа-потоков
ПО обработки медиа-потоков занимается кодированием/декоди- рованием речевых, видео, мультимедийных сигнальных потоков, эхо- компенсацией, шумоподавлением, усилением сигналов и т.п. Специфика задач этого компонента ПО - большой объем передаваемой информации, специальные алгоритмы обработки речевых потоков, кодирование/декодирование/перекодирование речевых и мультимедийных сигналов 一 требует больших вычислительных ресурсов.
речьречьПриемник/передатчикречиПриемник/передатчикречиЗхокомпенсаторЗхокомпенсаторВокодерКодеки речи-G.711-G.729-G.723-G.726-GSMВокодерКодеки речи-G.711-G.729-G.723-G.726-GSM
речь
речь
Приемник/передатчикречи
Приемник/передатчикречи
Зхокомпенсатор
Зхокомпенсатор
Вокодер
Кодеки речи
-G.711
-G.729
-G.723
-G.726
-GSM
Вокодер
Кодеки речи
-G.711
-G.729
-G.723
-G.726
-GSM
Устройствоподавления пауз
Генератор комфортного шума
Рис. 10.2 Модуль обработки речи
В качестве примера можно привести ПО, используемое для обработки речевого сигнала 坤ОН с целью дальнейшей его передачи по сети с маршрутизацией пакетов IR В функции такого ПО входит преобразование речевого сигнала методом импульсно-кодовой модуляции, эхокомпенсация, кодирование речевого сигнала, обнаружение активных периодов и пауз в речи, адаптация воспроизведения, а также детектирование и генерация сигналов DTMF и обработка факсимильных сигналов.
Последняя функция связана еще и с тем, что после кодирования (а потом - декодирования) факсимильные сигналы, модулированные с применением относительной фазовой модуляции и передаваемые внутри полосы, совершенно изменяют свою форму, и их распознавание другим факсимильным аппаратом невозможно. По этой при- чинедля работы факсимильных аппаратов необходимы дополнитель-
ные механизмы. На входе устройства приема речевого потока ставится детектор факсимильных сигналов; как только этот детектор обнаруживает такой сигнал, он устанавливает специальное соединение для передачи факсимильных сообщений, перекодированных по протоколу Т38. На встречной стороне эти сигналы снова приобретают форму фазовой или квадратурно-амплитудной модуляции и вводятся в канал.
Модуль эхокомпенсации предназначен для подавления в канале приема сигнала, попадающего в него из канала передачи. Метод эхокомпенсации позволяет рассчитать принимаемый сигнал, если известны характеристики линии и передаваемый сигнал.
Еще одним примером ПО медиа-потоков может служить программная реализация механизма обнаружения активных периодов речи (VAD - Voice Activity Detector), который проверяет получаемый из ТфОП сигнал на предмет наличия в нем речевой информации. Если в течение определенного времени речевая информация отсутствует, передача речевых пакетов в IP-сеть прекращается. Применение этого механизма существенно повышает эффективность использования полосы пропускания: экономия полосы может достигать 60%.
Суть программного обеспечения механизма адаптации воспроизведения заключается в буферизации речевых пакетов для сглаживания вариации их задержки. Механизм использует буфер FIFO, хранящий речевые элементы перед их воспроизведением. Далее измеряется джиттер, и производится адаптивное управление задержкой пакетов в буфере.
Задача ПО генерации комфортного шума (Comfort Noise Generator -CNG) состоит в следующем. В момент, когда в речи активного участника беседы начинается период молчания, терминал слушающего участника может просто отключить воспроизведение звука. Однако это было бы неразумно. Если в трубке возникает «гробовая тишина», т.е. если фоновый шум (шум улицы и т.д.), который был слышен во время разговора, внезапно исчезает, слушающему кажется, что соединение по каким-то причинам нарушилось, и он обычно начинает спрашивать, слышит ли его собеседник. Генератор CNG позволяет избежать этого неприятного эффекта. Простейшие кодеки прекращают передачу в период молчания, и декодер генерирует какой-либо шум с уровнем, равным минимальному уровню, отмеченному в период речевой активности. Более совершенные кодеки (G.723.1 Annex A, G.729 Annex В) предоставляют удаленному декодеру информацию, нужную для восстановления шума с параметрами, близкими к фактически наблюдавшимся.
Одним из интереснейших примеров обработки речевой информации является преобразование «текст-речь» и «речь-текст». Устрой-
ства, выполняющие такое преобразование, широко используются в системе Unified Messaging. Предположим, что какой-то пользователь этой системы получил письмо по электронной почте, но в данный момент времени не может его прочитать, т.к. находится где-то вне офиса. Он набирает специальный номер и, после речевой подсказки, пароль для доступа к своему универсальному почтовому ящику. Система сообщает ему, что поступило почтовое сообщение и, используя ПО преобразования «текст-речь», зачитывает ему полученное письменное сообщение. Если пользователь хочет немедленно ответить на письмо, он диктует ответ, а преобразователь «речь-текст» формирует ответное сообщение, которое затем передается отправителю полученного электронного письма.
Преобразователь «текст-речь» - это синтезатор речи, который создает внятную человеческую речь из какого-либо символьного (например, из буквенно-текстового) ее представления. Простые программы, в которых реализован этот алгоритм, сегодня можно найти в Интернет. Преобразователь «речь-текст» - это устройство распознавания речи, оно перекодирует произносимые фразы в определенный текстовый или подобный формат. Обо всем этом было сказано в главе 4. Здесь же следует отметить, что приемник и передатчик речи - это программы, которые дают возможность ПО обработки медиа-потоков принимать сигнал на обработку и передавать обработанный сигнал к другим программным компонентам или периферийным устройствам.
ПО обработки сигнализации
ПО обработки сигнализации занимается приемом сигнальных сообщений, их декодированием и обработкой, а также формированием и отправкой сигнальных сообщений. На рис.10.3 показана функциональная схема программного компонента обработки сигнализации.
API
Обработка протокольныхпроцедур
Кодер/декодер сигнальныхсообщений
сигнальныесообщения
Рис. 10.3 Про「раммное обеспечение обработки си「нализаиии
Все сигнальные сообщения принимаются и передаются кодером/ декодером сигнальных сообщений (иногда этот компонент называют парсером). После приема сообщение декодируется из стандартной формы, принятой в соответствующем протоколе (Н.323, ОКС7, DSS1, SIP и т.п.), и преобразуется во внутрисистемный вид. Кроме того, на этом этапе проверяется правильность кодировки принятого сообщения, и при обнаружении ошибки производятся предусмотренные протоколом действия: посылается сообщение об ошибке передающей стороне, игнорируется неправильное сообщение и т.д. Кодирование обратно декодированию, т.е. сообщение преобразуется из внутрисистемного формата в стандартную протокольную форму. Эта процедура несколько проще предыдущей, т.к. здесь не требуется проверка синтаксиса. Существует 4 основных вида кодирования сигнальных сообщений:
с фиксированным расположением полей,
TLV (Type Length Value - тип/размер/значение),
ASN.1 (Abstract Syntax Notation One - абстрактное представление синтаксиса),
текстовый вид.
Первый способ - с фиксированным расположением полей - используется в таком протоколе, как IP, формат которого описан, в частности, в [5]. Каждому полю в заголовке IP-дейтаграммы отведено строго определенное место. Это облегчает анализ сообщения, ведь парсеру не надо определять название и размер поля - ито, и другое ясно из его положения. И формирование сообщения так же просто - в памяти содержится шаблон, в который нужно подставить требуемые значения.
Второй способ кодирования называется TLV - смысл поля задается его типом (Туре), затем указывается размер поля (Length), азатем идет его содержимое (Value). Примером такого поля может служить обязательная часть переменной длины или необязательная часть сообщений ISU" рассмотренных в [4], откуда и взят приведенный ниже рис.10.4.
Существуют две модификации второго способа кодирования: TV, когда по имени известен размер поля, и LV, когда по месту известен тип сообщения.
С точки зрения программной реализации следует заметить, что в представленной на рис.10.4 обязательной части сообщения используется кодирование с фиксированным положением полей. Это сделано для того, чтобы в начале находились самые важные поля, благодаря чему их можно быстрее обработать.
871654з2 I 1871654з2 I 1V Очередность передачи битовV Очередность передачи битовМаршрутная этикеткаМаршрутная этикеткаОчередностьпередачибайтовОчередностьпередачибайтовКод типа сообщенияОбязательный параметр А■Обязательный параметр F/—Указатель начала параметра М■—Указатель начала параметра РУказатель начала необязательной части—Индикатор длины параметра М二Параметр М,Код типа сообщенияОбязательный параметр А■Обязательный параметр F/—Указатель начала параметра М■—Указатель начала параметра РУказатель начала необязательной части—Индикатор длины параметра М二Параметр М,Обязательная переменная частьОбязательная переменная частьОбязательная фиксированная частьОбязательная фиксированная частьИндикатор длины параметра РПараметр РИмя параметра-XИндикатор длины параметра XПараметр X■Имя параметра = ZИндикатор длины параметра ZПараметр ZИндикатор длины параметра РПараметр РИмя параметра-XИндикатор длины параметра XПараметр X■Имя параметра = ZИндикатор длины параметра ZПараметр ZКонец необязательных параметровКонец необязательных параметров>>НеобязательнаячастьНеобязательнаячасть
8
7
16
5
4
з
2 I 1
8
7
16
5
4
з
2 I 1
V Очередность передачи битов
V Очередность передачи битов
Маршрутная этикетка
Маршрутная этикетка
Очередностьпередачибайтов
Очередностьпередачибайтов
Код типа сообщения
Обязательный параметр А
■
Обязательный параметр F
/
—
Указатель начала параметра М
■
—
Указатель начала параметра Р
Указатель начала необязательной части
—
Индикатор длины параметра М
二Параметр М,
Код типа сообщения
Обязательный параметр А
■
Обязательный параметр F
/
—
Указатель начала параметра М
■
—
Указатель начала параметра Р
Указатель начала необязательной части
—
Индикатор длины параметра М
二Параметр М,
Обязательная переменная часть
Обязательная переменная часть
Обязательная фиксированная часть
Обязательная фиксированная часть
Индикатор длины параметра Р
Параметр Р
Имя параметра-X
Индикатор длины параметра X
Параметр X
■
Имя параметра = Z
Индикатор длины параметра Z
Параметр Z
Индикатор длины параметра Р
Параметр Р
Имя параметра-X
Индикатор длины параметра X
Параметр X
■
Имя параметра = Z
Индикатор длины параметра Z
Параметр Z
Конец необязательных параметров
Конец необязательных параметров
>
>
Необязательнаячасть
Необязательнаячасть
Рис. 10.4 Формат сообщения ISUP
ASN.1 - стандартный способ описания сигнального сообщения. ASN.1 делится на две части: (а) синтаксические правила описания содержания сообщения в терминах типов данных и последовательности или структуры содержания сообщения; (б) способ кодирования каждого элемента в сообщении. ASN.1 определен в двух рекомендациях ITU-T (и соответствующих им стандартах ISO) 一 Х.208 (то же в ISO 8824), которая определяет синтаксис, т.е., например, какой элемент данных в сообщении идёт первым и к какому типу данных он принадлежит, и Х.209 (то же в ISO 8825), которая определяет основные правила кодирования. Абстрактный синтаксис ASN.1 позволяет определять базовые объекты и затем объединять их в более сложные. Существуют следующие основные правила кодирования для ASN.1:
Базовая кодировка (BER 一 Basic Encoding Rule). В этой кодировке данные кодируются по способу TLV Она основана на предопределенных данных, которые называются примитивами;
Каноническая кодировка (CER - Canonical Encoding Rule) необходима для работы с большим размером данных. Работа с BER возможна только после приема всего сообщения, а с CER - после приема части сообщения;
Особенная кодировка (DER - Distinguished Encoding Rule) используется, когда необходимо засекречивание сообщений;
Пакетная кодировка (PER - Packed Encoding Rule) отличается от BER более простым алгоритмом кодирования, что позволяет использовать ее при слабых вычислительных мощностях.
Пример ASN.1 кодирования приведен ниже:
MasterSlaveDetermination ::=SEQUENCE {
terminalType INTEGER (0..255), statusDeterminationNumber INTEGER (0..16777215), }
Здесь MasterSlaveDetermination - имя типа сообщения. Это сообщение состоит из последовательности (SEQUENCE) элементов terminalType и statusDeterminationNumber. Они имеют тип INTEGER, т.е. представляют собой целые числа.
Текстовый формат сообщений отличается тем, что тип заголовка определяется по его имени, записанному с использованием какого- либо буквенно-цифрового кодирования. При приеме сообщения парсер проверяет соответствие содержащихся в нем данных заданному списку известных имен полей. Если соответствие есть, просматривается содержимое того поля, которое следует за заданным символом, например двоеточием. Конецстроки определяется по символам «Возврат строки» (LF - line feed), «Возврат каретки» (CR 一 carriage return). Текстовый формат сообщений очень облегчает их анализ и обработку, он также пре дета вляется очень простым для программирования.
Кроме того, он может быть реализован на базе практически любого языка программирования. На рис.10.5 показано сообщение протокола SIP [5], которое кодируется в текстовом формате.
INVITE sip: watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel,com
From: A. Bell <sip: a.g.bell@bell-tel.com> To: T. Watson <sip: watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com Cseq: 1 INVITE
Content-Type: application/sdp Cont ent-Length:...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
C=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0345
Рис. 10.5 Сообщение протокола SIP
После того как сообщение декодировано, оно поступает в ПО обработки протокольных процедур. Здесь сообщение анализируется, после чего принимается решение о дальнейших действиях. Это может быть формирование ответа, передача информации другим подпрограммам и т.д.
Хотелось бы обратить внимание читателя на то, что ПО обработки сигнализации выполняет обработку протокольных процедур, а также прием и передачу сигнальных сообщений. Эти функции используются приложениями для решения возложенных на них задач установления соединения, разрушения соединения, уведомления друсо访 стороны о своих параметрах. Для взаимодействия приложений с ПО обработки сигнализации служат программные интерфейсы или API. Предположим, что приложению требуется установить соединение с удаленным терминалом. Это приложение, используя API, дает команду ПО обработки сигнализации передать сигнальное сообщение к указанному терминалу. В свою очередь, ПО обработки сигнализации формирует сообщение и передает его с помощью внутреннего интерфейса к кодеру/декодеру сигнальных сообщена访.Тот, после процедуры кодирования, отправляет его в канал передачи сигнальных сообщений. Полученный затем ответ декодируется и передается в ПО обработки сигнализации, которое, в зависимости от алгоритма работы, принимает решение о дальнейших действиях (передача информации приложению, подтверждение приема сообщения ит.п.).
В конце параграфа хотелось бы заметить, что иногда ПО обработки сигнализации называют реализацией стека протоколов, т.к. в нем содержатся программные компоненты разных протоколов сигнализации..
10.5 Программное обеспечение API
При работе компонентов программного обеспечения возникает необходимость их взаимодействия, например, для обмена данными, для запроса или передачи результатов работы, для запуска процедур и т.д. Взаимодействие происходит через представленный на рис.10.6 прикладной программный интерфейс API.
Про「раммньВкомпонент
/ 卜 Прикладной 门 ро「раммнн 访
V интерфейс (API)
Программныйкомпонент
Рис. 10.6 Взаимодействие программных компонентов
Прикладные программные интерфейсы или API (Application Programming Interface) позволяют двум программным компонентам обмениваться информацией, обращаясь к набору заранее определенных функций. Важным преимуществом использования API является упрощение написания приложений. Например, при использовании Windows API разработчику нет необходимости производить сложные обращения к операционной системе, достаточно написать несколько строк обращений к API-функциям. Существует целый класс интерфейсов API специально для обращения ктелефонным функциям, таким как установление соединения, разрушение соединения, занятие канала, прием сигналов DTMF и т.д., что заметно облегчает разработку телекоммуникационного программного обеспечения. Наличие таких интерфейсов для прикладных программ CTI избавляет программистов от необходимости знать особенности аппаратных платформ, на которых будут выполняться приложения, предоставляя им определенный уровень абстракции.
Наиболее известными прикладными программными интерфейсами являются уже неоднократно упоминавшиеся на страницах этой книги телефонный прикладной программный интерфейс TAPI (Telephony Application Programming Interface), предложенный Microsoft совместное Intel, и TSAPI (Telephone Server Applications Programming Interface), который разработали компании Novell и AT&T а также открытый интерфейс прикладного программирования Parlay API.
Программирование TAPI
В 1993 году компания Microsoft объявила о выпуске специализированного прикладного программного интерфейса TAPI, позволяю-
щего программе персонального компьютера управлять телефонными устройствами, не заботясь об их структуре и свойствах. TAPI, по определению самой фирмы Microsoft, - это набор функций, которые позволяют программировать подключаемые к телефонным линиям устройства способом, не зависящим отустройств. Сейчас вышла уже третья версия TAPI, которую называют телефонией Windows.
С точки зрения ПО телефония Windows является частным случаем WOSA - открытой архитектуры служебных функций для среды Windows. Главной идеей WOSA является наличие не зависящего от устройств API для разработчиков приложений и не зависящей от приложений спецификации драйвера для разработчиков внешних устройств. TAPI позволяет работать как с речевыми потоками, так и с потоками данных. Он может поддерживать приложения следующих видов:
Типовой сеанс связи в ТфОП
Конференция
Контакт-центр
Сеансы связи с использованием технологии VoIP (Voice over IP)
Системы интерактивного речевого взаимодействия IVR.
7API предоставляет программистам Windows PC стандартный доступ к телефонным сетям через динамическую библиотеку DynamicLink Library (DLL). TAPI может выполнять следующие функции:
Запрос данных о характеристиках линии или телефонного устройства
Организация связи при исходящем вызове
Получение уведомления о входящем вызове
Организация конференцсвязи и управление ею
Обнаружение изменений состояния сеанса связи (например, отбоя вызывавшего абонента)
Прием и накопление набираемых цифр
Управление телефонным устройством
Определение и использование функциональных возможностей устройства, предусмотренных фирмой-изготовителем
Координация обработки вызова с другими приложениями Windows.
Одно из преимуществ использования TAPI состоит в том, что программист не должен думать об управлении устройствами, а заниматься только управлением связью. Таким образом, приложению не важны особенности этих устройств, а устройства ничего не знаюто приложениях, что позволяет очень просто модифицировать конфигурацию устройств. Структура TAPI представлена на рис.10.7.
Рис, 10.7 Программная структура TAPI
Рассмотрим подробнее каждый из компонентов TAPI.
Приложение с модулем TAPI - это ПО, которое может взаимодействовать с пользователем или выполнять заданные пользователем телефонные задачи. Приложение должно содержать реализацию программного интерфейса TAPI для обращения к функциям динамической библиотеки TAPI DLL
Динамическая библиотека ТАР! DLL - слой, который отделяет пользовательские приложения от разных поставщиков услуг Иными словами, DLL обеспечивает интерфейс к поставщикам услуг Приложения вызывают из TAPI DLL функции, использующие для взаимодействия с сервером метод вызова удаленных процедур RPC (Remote Procedure Call).
Существуют динамические библиотеки трех видов: Tapi.dll, Tapi32.dll и Tapi3.dll.
Tapi.dll используется 16-битовыми приложениями и работает в версиях Windows 3.1 и Windows 95. В Windows98 и WindowsNT/Win- dows2000 эта библиотека используется для преобразования 16-битовых адресов в 32-битовые с последующей передачей их динамической библиотеке Tapi32.clll.
Tapi32.dll используется приложениями с модулем TAPI версии 2 для Windows 98 и WindowsNT/Windows2000. В случае необходимости она может обращаться к поставщикам медиа-услуг через программный интерфейс MSPI (Media Service Provider Interface).
Tapi3.clll используется совместно с третьей версией TAPI.
Сервер 7Api представляет собой программу, хранящуюся в файле Tapisrv.exe, и предоставляющую динамическим библиотекам TAPI DLL интерфейс с поставщиками телефонных услуг через TSPI (Telephone Service Provider Interface). Сервер может проверять состояние устройств, а также соединять, в случае необходимости, MSP и TSR Поставщик телефонных услуг (TSP) является компонентом, который предоставляет приложениям доступ к аппаратным средствам, избавляя их от необходимости знать особенности и характеристики этих средств. По сути, TSP 一 это динамическая библиотека DLL, которая позволяет управлять устройствами. Эту библиотеку создают производители оборудования и разработчики приложений, придерживаясь правил взаимодействия согласно интерфейсу TSPI, так что приложение не должно заботиться о специфике работы устройств. Таким образом, TSP принимает запросы от сервера TAPI и выполняет функции взаимодействия с устройством, зависящие от его типа. TSPI поддерживает устройства ISDN, сотовую связь, мини-АТС и обычные телефонные линии.
Поставщики медиа-услуг (MSP) отличаются от поставщиков телефонных услуг тем, что они позволяют приложениям управлять медиа-потоками в каналах. MSP появился только в третьей версии 1API для Windows 2000. Подобно TSF; MSP избавляет приложения от необходимости знать особенности управления медиа-потоками. Во время работы приложений MSP может связываться с TSR т.к. каждый из них выполняет в процессе обслуживания вызова свой круг задач: TSR например, управляет установлением и разрушением соединений, a MSP ~ передачей и приемом речевых потоков. Для связи MSP с TSP используется виртуальный путь, который создает между ними сервер TAPI. Производитель оборудования может создавать в рамках MSP свои собственные интерфейсы.
Поставщики услуг передают информацию об устройствах приложениям по их запросу, но, кроме того, они могут сообщать обо всех изменениях в состоянии устройств по собственной инициативе.
Рассмотрим теперь, в общем виде, процесс работы TAPI. Пусть выполняемому приложению необходимо обратиться к услугам теле-
фонии Windows и оно инициирует свой модуль TAPI. Этот модуль загружает библиотеки TAPI DLL, посредством которых через механизм вызова удаленных процедур RPC он связывается с сервером TAPI. Кроме того, создается соответствующий объект в MSP. Сервер TAPI взаимодействует с поставщиком телефонных услуг TSR используя интерфейс TSPI, и определяет состояние устройств. MSP и TSP отвечают за управление своим оборудованием.
Согласно документации Microsoft все услуги, которые позволяет предоставить TAPI, делятся на услуги содействия (Assisted Telephony) и полнофункциональные услуги (Telephony). Какой группой услуг воспользоваться при написании того или иного приложения, зависит от того, какие функциональные возможности API нужны этому приложениию.
Услуги содействия обеспечивают ряд команд, которые дают воз- м ожность л юбы м приложениям, базирующимся на Win32 (прикладной программный интерфейс в Windows 95, 98, 2000 и NT, позволяющий приложениям использовать 32-битовые команды), организовать предоставление телефонной связи. Сеанс связи можно организовать командой MakeCall, указав при этом номер вызываемого абонента. Существует функция, когда TAPI предлагает собственное приложение для управления организацией сеанса связи, но программист может создать и свое приложение, например, разработать пользовательскую программу, которая позволяет абоненту выводить на экран поле набора номера и выбирать опцию «набор», чтобы инициировать исходящий вызов. Для программиста, использующего услуги содействия, фирма Microsoft определила четыре функции TAPI, приведенные в табл. 10.1. Резюмируя вышесказанное, можно сказать, что услуги содействия используются, когда необходимо организовать простой сеанс связи двух пользователей (телефонной или с обменом данными).
Таблица 10.1 Функции TAPI для услуг содействия
TapiRequestMakeCall
Запрашивает связь с другим пользователем
TapiRequesMediaCall
Запрашивает медиа-связь
TapiRequestDrop
Запрашивает разъединение
TapiGetLocationlnfo
Сообщает код страны и города
Полнофункциональные услуги предоставляют весь стек Windows- телефонии для построения сложных систем CTI (Call-центры, например) и для реализации широкого спектра телекоммуникационных услуг На этом уровне в качестве функций выступают запросы от приложений к TSP и MSR а в качестве сообщений - ответы и информация о состояниях тех или иных устройств. Следует обратить внимание на то, что услуги содействия и полнофункциональные услуги не могут работать вместе, т.к. используют абсолютно разные механиз-
мы для своей реализации. Полнофункциональные услуги делятся на три уровня, различающихся своими возможностями:
Основные услуги. Этот уровень включает в себя услуги, поддерживаемые традиционными телефонными сетями. Он обеспечивает только непосредственное управление мультимедийной связью, что даёт программистам приложений средства для подключения приложения через выбранное устройство к определённому мультимедийному каналу и для организации соединения по этому каналу.
Дополнительные услуги обеспечивают доступ к таким функциям коммутации, как удержание, переключение связи, конференцсвязь и др., отличным от основных услуг Все эти функции предполагаются необязательными, и поставщик услуг сам решает, поддерживать их или нет.
Расширенные услуги обеспечивают многочисленные и хорошо определенные механизмы расширения API, которые позволяют разработчикам приложений получать доступ к специфическим функциям поставщика услуг; напрямую не определенным TAPI. Этот уровень позволяет разработчикам расширять специфицированные в TAPI возможности, сохраняя соответствие его базовой структуре. Тк. TAPI определяет только способы расширения, поставщик услуг должен сам разрабатывать правила работы расширенных услуг Вторая версия TAPI, кроме того, позволяет определять новые типы данных в большинстве структур, определять новые значения для числовых типов и флагов.
7API предусматривает следующие уровни управления:
Уровень управления сессиями. Всем соединениям в TAPI соответствуют программные объекты. Функция управления сессиями может создавать, изменять или уничтожать эти объекты. Кроме того, она может управлять мультимедийными конференциями в IP- сетях. Уровень управления сессиями содержит два подуровня:
- операционный - организует и разрушает мультимедийные сессии;
~ информационный ~ определяет информацию, которая должна быть получена во время обслуживания сессии (например, сведения о состоянии процесса обслуживания вызова).
Уровень управления устройствами. Для управления устройствами через TAPI требуется небольшой объем информации, т.к. за все особенности управления отвечают поставщики услуг 7Api различает следующие виды устройств:
терминал - приемник и источник информации;
сеть ~ транспортная сеть, где все элементы имеют свои адреса;
линия - служит для подключения к сети;
канал - элемент линии, имеющий адрес; линия может иметь один или несколько каналов;
адрес - определяет точку подключения к сети и идентифици- руетлинию или канал.
Уровень управления медиа-потоками. TAPI позволяет приложениям определять тип медиа-потока, а также некоторые его характеристики (уровень сигнала, параметры кодеков и т.д.). Кроме того, есть возможность управлять ими при уже установленном соединении, например, после набора цифр или нажатия клавиш.
Рассмотрим, как программировать TAPI, т.е. каким образом приложение может установить и разрушить соединение, определить состояние процесса обслуживания вызова и т.д. Более подробная информация имеется в руководстве MicrosoftWindows Telephony Programmer. Чтобы произвести обычный телефонный вызов, приложение должно запросить команду tapiRequestMakeCall.
Эта команды содержит следующие параметры.
Адрес назначения
Имя приложения
Имя вызываемого абонента
Комментарий.
Только первый параметр является обязательным; все остальные служат для удобства программиста. Адрес назначения может быть определён в виде полного канонического описания, т.е, универсального адреса, или набираемого номера.
Для мультимедийного вызова служит команда tapiRequestMedia- Са//. Её параметры:
Окно приложения для ответных сообщений
Идентификатор запрашивающего приложения
Класс устройства, которое определяет тип мультимедиа
Адрес назначения
Флаг (признак) защиты
Имя приложения
Имя вызываемого пользователя
Комментарий.
Три последних параметра являются необязательными.
Для разъединения используется команда tapiRequestDrop.
Эта команда должна содержать в качестве параметра идентификатор приложения, которое инициировало вызов.
Мониторинг типа информации. TAPI обеспечивает мониторинг режимов передачи информации по каналу. Мониторинг может запускаться в состоянии CONNECTED через функцию lineMonitorMedia. Контролируются следующие режимы:
Речевая связь между двумя пользователями
Связь пользователя с речевым автоматом (например, с автоответчиком)
Цифровые данные
Факс G3/G4
Модемная передача данных
Телетекс/видеотекс
Аналоговый сигнальный интерфейс (ADSI)
Приложения получают информацию о состоянии процесса обслуживания вызова в сообщении LINЕ_СALLSTATE. Примеры состояний этого процесса приведены ниже:
Offering (Вызов предложен)
Accepted (Вызов принят)
Dial tone (Сигнал «ответ станции»)
Dialing (Набор номера)
Connected (Соединениеустановлено)
Информацию о входящих вызовах можно запросить через функцию lineGetCalllnfo. Эта информация включает в себя сведения о режиме и скорости передачи информации, о типе передаваемой информации (media mode), об идентификаторе (номере) вызывающего абонента, об идентификаторе (номере) вызываемого абонента.
10.5.2 Программирование TSAPI
В 1994 году, через год после появления первой версии TAPI, компании Nowell и AT&T представили свою версию прикладного программного интерфейса для компьютерной телефонии - TSAPI (Telephone Server Applications Programming Interface). Как и TAPI, TSAPI позволяет управлять соединениями, дает возможность предоставлять широкий спектр телекоммуникационных услуг Но в отличие от TAPI, который ограничен использованием в среде Windows, TSAPI поддерживает и другие операционные системы.
Фундаментом для TSAPI является упоминавшийся выше стандарт компьютерной поддержки телекоммуникационных приложений (Computer Supported Telecommunications Applications, CSTA), разра-
ботанный Европейской ассоциацией производителей компьютеров ЕСМА. Более поздняя версия спецификации TSAPI определена как часть энциклопедии Versit CTI Encyclopedia (Versit, 1996) и упоминается как Versit TSAPI. Другие версии TSAPI, предшествовавшие Versit TSAPI, фактически являются ее подмножествами, не поддерживающими принцип «Plug&Play». В этой книге внимание сосредоточено на последней спецификации TSAPI.
Спецификация интерфейса TSAPI ориентирована на доступ к функциональным возможностям CTI, определенным стандартными протоколами компьютерной телефонии. С другой стороны, интерфейсы, ориентированные на операционную систему, создавались с несколько иными целями. Главное внимание в этих API направлено на то, чтобы упростить задачу программирования для большинства разработчиков приложений API, которые используют средства рассматриваемой операционной системы. В результате достигнуты упрощения, которые помогают большинству разработчиков приложений, но уменьшают при этом информацию, доступную приложениям определенных типов.
TSAPI определяет программный интерфейс для разработчиков приложений и производителей АТС так, что они могут взаимодействовать, не зная особенностей работы друг друга (что, в принципе, делает и I7\PI). Таким образом, приложения, написанные один раз, могут быть использованы с любыми TSAPI-совместимыми АТС.
С точки зрения разработчика приложений, TSAPI является аппаратно-независимым, те. приложение TSAPI может выполняться в любой сети с сервером CTI на основе TSAPI и не привязывает разработчика к единственной компании-производителю АТС. На базе TSAPI возможна организация следующих услуг:
инициирование вызова (так же, как и в TAPI, это можно сделать с помощью графического интерфейса);
ответ; переключение связи, организация конференции и многочисленные телефонные услуги;
определение статуса процесса обслуживания (ответ, посылка вызова, удержание), причем это можно делать в реальном времени, что дает тел ефон исту или менеджеру узла связи возможность следить за обслуживанием любого вызова.
В TSAPI используется принцип «клиент-сервер». Клиент дает запрос, в котором указывает, какого рода информацию ему нужно получить от сервера. Сервер принимает запрос, обрабатывает его и дает ответ, который может содержать уведомление об успешном исполнении запроса, уведомление об ошибке или информацию, затребованную клиентом. Таким образом, основное отличие интерфейса TSAPI от TAPI - наличие специального единого телефонного сер-
вера, который взаимодействует с АТС. Это делает сеть масштабируемой, централизует логику обработки вызовов, обеспечивая обслуживание большого числа пользователей.
Согласно идеологии компании Novell система компьютерной телефонии на базеТЗАР! содержит несколько программных компонентов (рис.10.8):
Тракт CTI. Это тракт, который соединяет сервер с коммутатором. Он поддерживает специфический протокол этого коммутатора и обеспечивает сеансы связи между приложениями TSAPI и ПО обработки вызовов в коммутаторе. Физически тракт CTI между сервером компьютерной телефонии и коммутатором может быть организован с использованием интерфейса RS-232 или LAN.
Драйвер коммутатора. Драйвер коммутатора - это набор загружаемых программных модулей (NLM- NetWare Load Module). Каждый такой модуль представляет собой сетевую услугу, утилиту или приложение, которые работают поверх операционной системы NetWare. Модули NLM поддерживают специфический для коммутатора тракт CTI и протокол CTI, отображают протокол CTI в TSAPI, поддерживают возможности администрирования и обслуживания драйвера коммутатора, а также интерфейс драйвера с аппаратным обеспечением тракта CTI.
Интерфейс драйвера коммутатора. Этот компонент представляет собой программный интерфейс между драйвером коммутатора и NLM телефонных услуг (о нем пойдет речь чуть ниже), через который проходят сообщения между приложениями и драйвером коммутатора. Обычно сообщения состоят из запросов услуг и уведомлений о событиях для клиентов TSAPI. Сообщения могут быть также запросами эксплуатационного управления, ответами и уведомлениями о событиях для приложений, выполняющих эксплуатационное управление драйвером коммутатора.
NLM телефонных услуг обеспечивает связь между многочисленными телефонными приложениями и драйвером коммутатора через интерфейс драйвера коммутатора, распределяет сообщения от драйвера к приложениям, обеспечивает функциональную реал изаци ю телефоны ых услуг
Телефонный сервер. Это - серверная машина, на которой работает NLM телефонных услуг
Библиотека телефонного сервера. Содержит правила работы функций TSAPI; принимает запросы доступа к функциям TSAPI и дает ответы приложениям сервера, может располагаться налю- бом сервере сети.
Библиотека телефонного клиента. Тоже содержит правила работы функций TSAPI, но располагается у клиента.
Если телефонный сервер выполнен, например, на базе Window NT, то вместо загружаемых модулей NLM могут использоваться программы Win 32.
Итак, сервер соединяется с коммутатором посредством тракта CTI. Для того чтобы подключиться к нему, необходим драйвер, который содержит правила работы с конкретным коммутатором. На этом заканчивается все, что зависитоттипа коммутатора, остальное представляет собой независимую платформу для предоставления телефонных услуг Приложения, соответствуя TSAPI, при запросе услуги вызывают выполнение процедуры на телефонном сервере.
•в① оо.вох。!/!•в① оо.вох。!/!Коммутатор 二刪国一 miniiiiiiii =_ miniiiiiiiiКоммутатор 二刪国一 miniiiiiiii =_ miniiiiiiiiТелефонные аппаратыТелефонные аппаратыТелефонный серверТелефонный серверТракт CTIТракт CTIЛокальная вычислительная сетьЛокальная вычислительная сеть
•в① оо.вох。!/!
•в① оо.вох。!/!
Коммутатор 二刪国一 miniiiiiiii =
_ miniiiiiiii
Коммутатор 二刪国一 miniiiiiiii =
_ miniiiiiiii
Телефонные аппараты
Телефонные аппараты
Телефонный сервер
Телефонный сервер
Тракт CTI
Тракт CTI
Локальная вычислительная сеть
Локальная вычислительная сеть
Рис. 10.8 Программная архитектура TSAPI
Об использовании в качестве API протоколов MGCP и Н.248 уже написано в книге [5], и это позволило авторам сэкономить место для иллюстрации вышеизложенных принципов на примере ПО интеллектуальной платформы ПРОТЕЙ.
10.6 ПО интеллектуальной платформы ПРОТЕЙ
10-6.1 Архитектура ПО
Разнообразные устройства компьютерной телефонии имеют общую структуру телекоммуникационного ПО, которая выглядит следующим образом:
Рис. 10.9 Обобщенная структура ПО компьютерной телефонии
Accumulator 一 носитель информации, к быстроте обработки и управления которой особых требований не предъявляется (статистика, журналы, и пр.).
Base - ядро системы, обеспечивающее выполнение базовых функций.
Configuration - носитель информации, связанной с конфигурацией системы. Обработка этой информации и управление ею должны производиться очень быстро.
О&М (Operation & Maintenance) - блок эксплуатационного управления системой.
Рис. 10.10 Структура модуля Base
Рассмотрим подробнее модуль Base.
Exchange - блок, посредством которого осуществляется связь модуля Base с внешним миром.
Call Control- главный блок. Отвечает за выполнение целевых функций системы, т.е. функций организации, поддержки и ликвидации сеансов связи между по л ьзо вате л я м и.
Signaling-блок, реализующий логику обмена сигнальной информацией с другими системами сети. Эта логика определена в протоколах сигнализации.
Physical - блок, осуществл яющий взаимодействие с устройствами адаптации к физической среде передачи информации.
Библиотека АТЕ
В отличие от отдельных устройств компьтерной телефонии, рассмотренных, в частности, в главе 4, для миофункциональной интеллектуальной платформы целесообразна разработка единой библиотеки, в которой общие части проектов представлены в неизменном виде, а различия, связанные с особенностями операционных систем или с протоколами передачи данных, - как набор специфических функциональных средств. Таким образом, любой проект представляет собой просто набор из готовых кирпичиков плюс код, который функционально присущ именно этому проекту. Такая библиотека классов C++ платформы Протей получила рабочее название АТЕ - Abstract Telephony Equipment - и была специально ориентирована на создание программного обеспечения цифровых систем телефонии. Библиотека включает в себя:
базовую часть - инструментальные средства для реализации телекоммуникационных протоколов, средства управления ими, средства взаимодействия протоколов, средства взаимодействия с операционной системой, другие средства общего назначения (таймеры, специализированные списки и т.д.);
реализацию протоколов телефонии;
общие части основных структурных модулей проектов, основанных на АТЕ;
интерфейс с целевым аппаратным обеспечением (имеются в виду физические устройства, которые непосредственно участвуют в реализации целевых функций системы, созданной на основе АТЕ).
Библиотека АТЕ интеллектуальной платформы Протей выполнена на C++и компилируется в средах Microsoft Visual C++, Watcom C++ и GCC, код библиотеки свободно переносим между платформами Win32, QNX32 и Linux, он совместно используется со стандартными библиотеками С, C++и средами программирования (MFCn др.). Реализация протоколов в библиотеке не зависит от особенностей конкретных проектов. Библиотека наращивается за счет реализации новых протоколов и интерфейсов с новым целевым аппаратным обеспечением, причем это происходит без модификации ранее написанного кода проектов; наращивание библиотеки может произво-
диться параллельно несколькими разработчиками независимо друг от друга. Средства библиотеки должны обеспечивать стандартные механизмы переноса алгоритмов, представленных в виде SDL-диаграмм; библиотека имеет встроенные средства отладки времени исполнения и распараллеливания работы отдельных узлов, вплоть до поддержки систем, распределенных между отдельными вычислительными устройствами; при этом реализация логики протоколов не должна зависеть от применения той или иной схемы распределения.
Структура ПО шлюза 1Р-телефонии
Для организации телефонной связи по IP-сети необходимо ПО, выполняющее преобразование сигналов систем телефонной сигнализации (0КС7 или DSS1) в сигнальные сообщения IP-телефонии (например, Н.323) и преобразование формата данных (речи или факсимильных сообщений), передаваемых из сети с коммутацией каналов в сеть с коммутацией пакетов и обратно.
Для решения некоторых задач используются специализированные процессоры цифровой обработки сигналов DSR которые кодируют речевой сигнал, приходящий из ТфОП, и пакетируют его в аудио-фреймы, а также выполняют обратное преобразование. Обо всем этом будет сказано в следующей главе. Остальные функции реализуются программными средствами с использованием обычных универсальных процессоров. На рис.10.11 изображена обобщенная структура ПО шлюза Протей-IR
Рис. 10.11 Обобщенная структура ПО шлюза IP-телефонии
Это ПО организует интерфейсы для речевых сигналов и телефонной сигнализации, приходящих на шлюз из ТфОП, и преобразует их в пакеты для передачи по сети IP. ПО разделено на несколько частей, чтобы обеспечить четкий интерфейс между программным обеспечением DSP и остальным ПО для различных протоколов пакетной
передачи речи. ПО, реализующее возможность передачи речи по сети с пакетной коммутацией, состоит из следующих частей:
Модуль пакетирования речи. Этот модуль большей частью работает на специализированном DSP-процессоре и используется для преобразования речевой информации, получаемой из ТфОП с постоянной скоростью, в закодированные по одному из алгоритмов аудио-фреймы для последующей передачи их по IP-сети, атакже для обратного преобразования. В состав модуля входят речевые кодеки, подсистема подавления эха, подсистема обнаружения активных периодов речи, подсистема подавления джиттера, средства работы с сигналами DTMF.
Модуль обработки телефонной сигнализации, который взаимодействует с телефонным оборудованием, преобразуя сигнальную информацию в последовательность событий, отражающих изменения состояния процесса обслуживания вызова (установление соединения, отбой ит.п.), которые используются модулем логики услуг шлюза для организации соединений между ТфОП и IP-сетью.
Модуль сигнализации Н.323 обрабатывает сигнальную информацию, передаваемую по протоколам Н.225.0 и Н.245. Информация об изменениях состояния процесса обслуживания вызова в IP-сети передается в модуль логики услуг шлюза.
Модуль логики услуг шлюза IP-телефонии отвечает за логику передачи обслуживания вызова из ТфОП в IP-сеть. Здесь выполняются такие операции, как контрол ь доступ а и анализ телефонного номера вызываемого абонента (в случае, если используется сигнализация RAS, многие функции могут быть возложены напри- вратниксети IP-телефонии) с последующим определением и предоставлением требуемой услуги.
Часть программного обеспечения, выполняемая на центральном процессоре, построена с использованием технологии АТЕ.
Модуль пакетирования речи
Программное обеспечение пакетирования речи выполняет подготовку речевого сигнала к дальнейшей передаче по пакетной сети. В его основные функции входит ИКМ-преобразование речевого сигнала, кодирование речевого ИКМ-сигнала, подавление эха, обнаружение активных периодов речи и адаптация воспроизведения. Кроме того, этим модулем детектируются и вырабатываются частотные сигналы, такие как DTMF или факсимильные сигналы. Определение активного периода речи заключается в том, что полученный сигнал проверяется на предмет наличия в нем речевой информации. Если в течение определенного времени речевая информация не обнаружена, ПО информирует об этом протокол пакетной передачи речи.
Адаптация воспроизведения заключается в буферизации аудиофреймов для их равномерного воспроизведения. Реализация этой функции имеет следующие особенности: организуется буфер FIFO, предназначенный для хранения речевых элементов перед воспроизведением и компенсации задержек при передаче речевых пакетов; выбирается период измерения джиттера и вычисляется его среднее значение за этот период, что позволяет осуществлять адаптивное управление задержкой аудио-фреймов. Структура модуля пакетирования речи представлена на рис.10.12.
Рис. 10.12 Модуль пакетирования речи
Модуль обработки телефонной сигнализации
Этот модуль полностью реализован при помощи библиотеки АТЕ платформы Протей, На его выходе формируется унифицированный интерфейс базового соединения. На рис.10,13 приведена часть модуля, соответствующая подсистеме Signalling библиотеки АТЕ.
Протокольный объект- блок поддержки протокола сигнализации, по которому система взаимодействуете сетью общего пользования. В интеллектуальной платформе ПРОТЕЙ реализованы протоколы DSS1, стек ОКС7, R1.5, интерфейсы V5.1/V5.2 и др.
В качестве иллюстраций к принципам кодирования сообщений систем сигнализации, описанным в п. 10.4 настоящей главы, отметим, что для кодирования подавляющего большинства сообщений системы сигнализации DSS1 используется принцип TLV, параметры подсистемы ISUP ОКС7 могут кодироваться по принципам «с фиксированным положением полей», LV, TLV, а элементы подсистем TCAR
МАР (используются в центре обработки коротких сооб山ени访 SMS Протей-СЦ) и элементы протоколов Н.323 (используются в шлюзе Протей-IP) - с применением ASN.1; сообщения протокола SIP кодируются в текстовом виде.
Унифицированный интерфейс базового соединения
Блок сопряжения
Интерфейс протокольного объекта
Протокольный объект
Рис. 10.13 Модуль обработки теле0онно访 сигнализации
Интерфейспротокольногообьектаорганизуетобменсообщения- ми, характерными для данного протокольного объекта.
Блок сопряжения 一 блок согласования сигналов, передаваемых протокольным объектом, и унифицированных сигналов, принимаемых блоком логики обработки вызова; этот блок обеспечивает независимость логики от протокола сигнализации.
Модуль сигнализации Н.323
Этот модуль построен с использованием библиотеки ОрепН323, предоставляющей базовые функции терминала Н.323 и нн丁ерфе访с для построения более сложных приложением Н.323.
Для построения шлюза IP-телефонии были переопределены некоторые классы библиотеки. В частности, были переопределены классы Connection и End point, потомки которых, унаследовав базовые функции предков, выполняют задачи обеспечения работы шлюза со стороны Н.323. Переопределенные классы предостав л я ют л о - гике некоторые^ набор ин丁ерфе访еннх функи1M访 для операнд访 с вызо- вами/соединениями.
10-6-7 Модуль логики услуг шлюза 1Р-телефонии
В этом модуле осуществляется, собственно, обработка вызовов, направленных из ТфОП в IP-сеть и обратно. ПО модуля получает информацию о состояниях процесса обслуживания вызова через сообщения-примитивы от модулей телефонное^ сигнализации и Н.323, причем эти сообщения отражают только основные изменения состоя-
ния процесса на стороне ТфОП и IP. Логика шлюза преобразует сообщения в операции с вызовом/соединением; таким образом, через логику связываются два процесса -в ТфОП и в IP
Благодаря использованию рассмотренной выше библиотеки АТЕ, библиотеки ОрепН323 и общего подхода к построению ПО компьютерной телефонии, задача написания ПО шлюза IP-телефонии свелась к написанию программ для модуля пакетирования речи и для модуля логики услуг (т.е. для преобразования сигнализации).
10.7 ПО пользовательского интерфейса
Программное обеспечение этого класса можно разделить надве большие части: ПО интерфейса техобслуживания и управления конфигурацией системы и ПО интерфейса взаимодействия с пользователями.
Назначение перво访 части ясно из названия - с помощью этого ПО обслуживающий персонал вносит изменения в конфигурацию системы, обновляет маршрутные таблицы, контролирует исправность всех компонентов системы, выявляет возможные неполадки в работе узла, собирает для дальнейшего анализа информацию о состоянии системы и т.п.
Интерфейс взаимо^е访ствия с пользователями - это программное обеспечение, позволяющее производить и принимать телефонные вызовы, заказывать разные услуги системы, т.е. все то, для чего, собственно, и строится система компьютерной телефонии. Наиболее часто этот интерфейс называют экранным или графическим пользовательским интерфе 访 сом.
「рафннески访 пользовательский интерфейс (GUI) позволяет обладателю компьютера делать все то, что он мог делать раньше с обычного телефонного аппарата, а также получать новые функции и услуги, которые ранее были недостижимы. Для этого к GUI предъявляются следующие требования:
「рафинески访 пользовательский интерфейс должен быть интуитивно понятным и относительно простым. Пользователь не должен тратить многие дни, чтобы научиться с ним работать.
Ин丁ерфе访с должен быть быстрым. Пользователь не должен думать, что использование средств компьютерной телефонии займет у него больше времени, чем традиционные средства связи. Грубо говоря, для того чтобы сделать вызов, он может просто ввести номер нужного абонента и нажать кнопку «Вызов». И все! Система сама позаботится обо всем остальном.
Интерфейс должен быть надежным. Если пользователь не будет доверять надежности системы, он не станет ею пользоваться. Те-
лефонные приложения с графическим интерфейсом должны надежно работать с момента их запуска до момента выключения. Естественно, надежность зависит не только от само访 программы, но и от работы компьютерной системы, на которой она установлена, -от операционной системы, аппаратных средств, электропитания и от других аспектов, рассматриваемых в следующей главе.
「рафинески访 ин丁ерфе访с, отвечающий всем этим требованиям, дает пользователю значительные преимущества.
Во-первых, это очень удобный способ набора номера. Список номеров можно хранить в телефонной книге, а набирать номер - либо выбирая нужную строку, либо перетаскивая иконку в окно телефонного приложения. Кроме того, возможен вызов адресата по имени - система сама определит его телефонный номер.
Во-вторых, интеграция с базами данных дает возможность при вызове сразу показать информацию о вызывающем пользователе (если, конечно, такая информация имеется), так что не надо тратить время на выяснение личности - все видно на экране.
В-третьих, есть возможность настраивать способ уведомления о входящем вызове, например воспроизведением фразы типа «Вам поступило сообщение» или заданной мелодии. Используя преобразователь «текст-речь», о котором шла речь в начале главы, приложение может произносить имя вызывающего абонента, исходя из информации АОН.
Из сказанного ясно, что должна существовать возможность подстраивать интерфейс под требования разннхгюльзова丁еле访.В тоже время, перенасыщение его всевозможными функциями, разными вызывными мелодиями и т.п. снижает удобство использования и универсальность изделия. Очень важно отметить, что конструкция пользовательского ин丁ерфе访са не может быть оптимальной для всего населения (как в случае других категорией телекоммуникационного программного обеспечения) по той причине, что психологические модели и пользовательские предпочтения слишком различны. Интеграторы систем и организации, которые реализуют технические решения Call-центров и CTI, должны предполагать, что люди, использующие систему, захотят иметь возможность выбора своего собственного пользовательского приложения.
С точки зрения подхода к организации системы эксплуатационного управления наиболее перспективна, по мнению авторов, идеология «тонкого клиента» с доступом через Интернет/Интранет. Помимо возможностей^ удобно настраивать графический интерфейс, преимуществом такого подхода является и то, что единственным требованием к клиентскому рабочему месту администратора является наличие Web-браузера с поддержкой Java, например, Internet
Explorer. Данн曰访 подход позволяет легко адаптировать систему управления к нуждам конкретного заказчика и получить большой набор функциональных возможностей^ и удобные механизмы для выполнения операим访 техобслуживания, а также удобную возможность организации удаленных рабочих мест.
Что же касается операторских консолей (используемых в Call-центрах), то они, как правило, организуются на базе стандартных персональных компьютеров, на которых либо устан а вл ивается специализированное клиентское ПО, взанмоде访ствующее с внешними приложениями через специальные библиотеки, либо используется упомянутая выше идеология «тонкого клиента».
В заключение следует отметить, что тема разработки программного обеспечения для Call-центров и программно-аппаратных комплексов компьютерно访 телефонии материалом зто访「лавы ни в коей мере не исчерпывается. Авторы не затронули тему планирования разработок, крайне актуальную, если учесть сегодняшнюю ситуацию с целым рядом рекламируемых продуктов, находящихся в состоянии «почти готов». Обойдена сторон。访 и проблема надежности ПО систем реального времени, а также связанные с ней технологические аспекты и особенности отладки таких продуктов. Не обсуждаются особенности работы с базами данных в телекоммуникационных системах. Авторы постарались дать здесь лишь основные понятия об архитектуре и принципах построения программного обеспечения Call-центров и систем компьютерной телефонии и надеются, что программисты, работающие или собирающиеся работать в сфере ннфокоммуннкаим访,ни в коей мере не ограничатся чтением только этой главы.
Глава 11Аппаратноеобеспечение
Парень, который изобрел первое колесо был идиотом, но парень, который изобрел остальные три, был гением.
Сид Сизар
Компьютеры
Сам термин «компьютерная телефония» подразумевает наличие важнейшего компонента аппаратного обеспечения этой индустрии - собственно компьютеров, а также специализированных аппаратных средств, которые позволяют компьютерам работать с интерфейсами, характерными для телефонной сети. Кроме того, некоторые компоненты аппаратного обеспечения предоставляют вычислительные ресурсы, необходимые для выполнения ряда функций (например, распознавание речи), которые не связаны непосредственно с телефонными соединениями. Однако с ростом производительности компьютеров общего применения необходимость в специализированном аппаратном обеспечении неуклонно сокращается, так как все большее количество функций оказывается возможным выполнять на базе универсального центрального процессора системы.
Итак, рассмотрим основные компоненты аппаратного обеспечения систем CTI. И начнем с самого основного - с компьютеров, как таковых.
Как уже упоминалось в главе 2, первые системы компьютерной телефонии строились на базе мейнфреймов, работавших по закрытым протоколам. Из-за высокой стоимости эти системы были доступны только очень крупным организациям. Приобретая их, покупатель оказывался жестко привязанным к конкретному решению. Поддержка и, тем более, модификация системы были весьма трудоем-
кими и дорогостоящими. Ситуация радикально изменилась в начале 90-х годов. Появление специальных плат, о которых будет сказано далее в этой главе, позволило строить новые системы компьютерной телефонии на базе архитектуры персональных компьютеров. Отличительно访 черт。访 систем компьютерной телефонии этого поколения стало также использование открытых стандартов. Все это дало возможность создавать доступные по цене масштабируемые системы, адаптируемые к решению рассмотренных в предыдущих главах задач.
Сами же персональные компьютеры проектируются на основе принципа открытой архитектуры. Он заключается в следующем: регламентируются и стандартизируются только описание принципа действия компьютера и его конфигурация (совокупность аппаратных средств и соединений между ними). Это позволяет собирать компьютер из отдельных узлов и деталей, разработанных и изготовленных независимыми фирмами-производителями, а также расширять и модернизировать компьютер, помещая во внутренние слоты расширения различные устройства, удовлетворяющие заданному стандарту, и тем самым конфигурировать компьютер в соответствии с его задачами.
Предполагая знакомство читателя с технологическими аспектами современных персональных компьютеров, авторы позволили себе более чем тезисное изложение нижеследующего материала, достаточное, впрочем, для понимания данной главы.
Главным узлом, определяющим возможности компьютера, является системная, или/иатеринская (отанглийского слова motherboard) плата. На ней обычно размещаются: центральный^ процессор, оперативная память, сверхоперативное ЗУ (кэш-память), ПЗУ с системной BIOS (базовой системой ввода/вывода), чипсет (chipset - набор управляющих микросхем, вспомогательных микросхем и контроллеров ввода/вывода), КМОП-память (CMOS) с данными об аппаратных настройках и аккумулятор для ее питания, разъемы расширения или слоты (slot), разъемы для подключения интерфейсных кабелей жестких дисков, дисководов, последовательного и параллельного портов, а также универсально访 последовательно访 шины USB, разъемы питания, подключения клавиатуры и ряд других компонентов. Чипсет обычно состоит из нескольких специализированных интегральных микросхем (ASIC - application-specific integration circuits), как правило, от одно й до четы рех, выпущенных одним производителем. На материнской плате могут находиться микросхемы видеоадаптера, а также контроллера SCSI.
Важне访ujnPi компонент любого персонального компьютера - это центральный процессор CPU (Central Processor Unit), который управляет работой компьютера и выполняет большую часть обработки информации. Выполняемые микропроцессором команды предусмат-
ривают, как правило, арифметические <це访ствня, логические операции, передачу управления (условную и безусловную) и перемещение данных (между регистрами, оперативное^ памятью и портами ввода/вывода). С внешними устройствами микропроцессор может общаться благодаря своим шинам адреса, данных и управления, выведенным на специальные контакты корпуса микросхемы. Разрядность внутренних регистров микропроцессора может не совпадать с количеством внешних выводов для линий данных, например, микропроцессор с 32-разрядными регистрами может иметь только 16 внешних линий данных.
Все компьютеры используют память трех видов: оперативную, постоянную и внешнюю. Оперативная память (ОЗУ - оперативное запоминающее устройство) предназначена для хранения информации, к которой приходится обращаться часто, и обеспечивает режимы записи, считывания и хранения. Память этого вида называют также памятью с произвольным доступом (Random Access Memory, RAM). По способу хранения информации оперативная память быва- етс丁атинеско访 н динамической. Постоянная память (ПЗУ - постоянное запоминающее устройство) обычно содержит такую информацию, которая не должна изменяться в ходе выполнения микропроцессором разных программ. Постоянная память имеет также название ROM (Read Only Memory), которое указывает на то, что она пре- дусматриваеттол ько считывание и хранение информации. Постоянная память энергонезависима, т.е. она может сохранять информацию и при отключенном питании. Внешняя память обычно реализуется на магнитных или оптических носителях.
Подключение к персональному компьютеру внешних устройств производится через специальные ннтерфе访сы, называемые портами ввода/вывода. До недавнего времени подобные порты выполнялись в виде отдельных плат расширения. Современные системные платы, как правило, содержат все необходимые интерфейсы. Спецификации РС98 и РС99 предполагают гюс丁епенны访 отказ от их применения в пользу универсально访 последовательней шины USB. Взаимодействие периферийного устройства с PC происходит через ин- 丁ерфе访с, определяющие^, в частности, тип соединителя, уровень и длительность электрических сигналов, протоколы обмена.
В контексте этой книги наиболыим访 интерес представляет системная шина PC, которую образует совокупность сигнал ьных линий, объединенных по назначению (данные, адреса, управление), с определенными электрическими характеристиками и протоколами передачи информации. Основное назначение системной шины - передача информации между процессором (или процессорами) и остальными компонентами компьютера. По 3To访 шине производится не только передача информации, но и адресация ус丁ро访ств, а также происходит обмен специальными служебными сигналами. Исполь-
зуемые в настоящее время шины различаются по разрядности, способу передачи сигнала (последовательно или параллельно), пропу- скно访 способности, количеству и типу поддерживаемых устройств, а также по протоколу работы. Как правило, шины PC можно представить в виде некой иерархической структуры - шинной архитектуры. В современных PC используется шина ISA, унаследованная от самых первых моделей IBM PC, а также шины EISA, MCA, VLB, PCI, PCMCIA (CardBus) и др.
Шины могут быть синхронными (с передачей данных только по тактовым импульсам) и асинхронными (с передачей данных в произвольные моменты времени) и использовать разные схемы арбитража (то есть способа совместного использования шины несколькими устройствами). Если обмен информацией ведется между периферийным устройством и контроллером, то соединяющий их канал передачи данных называется интерфейсом передачи данных, или просто интерфейсом. Среди применяемых в современных PC интерфейсов следует отметить EIDE, SCSI, SSA и Fibre Channel, USB, FireWire (IEEE 1394).
Ниже мы рассмотрим, прежде всего, те интерфейсы и системные шины, которые непосредственно используются для подключения специализированных периферийных устройств, необходимых для создания систем компьютерной телефонии.
Шина ISA
Впервые системная шина ISA (Industry Standard Architecture) стала применяться в компьютерах PC/AT использующих микропроцессор i80286. Она отличалась от предыдущей наличием дополнительного 36-контактного разъема для плат расширения и позволяла передавать параллельно 16 разрядов данных, а благодаря 24 адресным линиям -напрямую обращаться к 16 Мбайтам системной памяти. Кол и чество линий аппаратных прерываний в этой шине было увеличено с 8 до 16, а каналов DMA - с 4 до 8. Шина ISA стала работать асинхронно с процессором на частоте 8 МГц, что соответствовало максимальной теоретической скорости передачи 16 Мбайт/с и реальной пропускной способности порядка 5 Мбайт/с. В ISA появилась поддержка устройств, способных управлять шиной (Bus masters).
В современных PC шиной ISA управляет не процессор, а специальное устройство на более быстрой шине PCI - так называемый мост (Bridge) PCI-ISA, причем стандарт PCI 2.1 позволяет шине PCI работать независимо от более медленной ISA и параллельно с ней (PCI concurrency). Шина ISA позволяет использовать платы расширения, не сообщающие компьютеру о своих настройках и используемых ресурсах (так называемые legacy или не Plug&Play платы), что часто приводит к неправильному определению их операционной системой и к аппаратным конфликтам. Реализация режима самонастройки
Plug&Play для плат【SA на практике также далека от идеала. Источником болыие访 части аппаратных конфликтов являются ус丁ро访ства для шины [SA, поэтому в спецификации РС98 рекомендуется отказаться от ее использования, а РС99 уже не разрешает применение ISA.
В промышленных компьютерах и в системах CTI, как в более консервативных, чем настольные системы, областях, шина ISA будет еще долгое время находить применение как простое в реализации и отработанное решение. В большинстве приложением обработки телефонных вызовов производительность шины ISA оказывается вполне достаточной.
Шина EISA
Системная шина EISA (Extended Industry Standard Architecture) появилась в сентябре 1988 года как 32-разрядное расширение шины ISA с полно访 обратное^ совместимостью. Шина, представленная компа- ние访 Compaq, была поддержана большинством компани访 一 произ- водителе访 серверов и оборудования для них. Новые возможности EISA были получены путем добавления новых лини访 за счет размещения новых контактов EISA между контактами шины ISA в глубине разъема. В тот же разъем можно было установить и ISA-карту, так как ее контакты не доходили до контактов EISA. В EISA впервые появилась автонастройка плат расширения - прообраз Plug&Play.
EISA обеспечила 32-разрядную адресацию памяти и передачу данных, в том числе, и в режиме DMA (без загрузки центрального процессора), улучшенную систему прернвани访 и арбитраж DMA, автоматическую конфигурацию системы и плат расширения.
Шина EISA позволяет адресовать 4-Гбайтовое адресное пространство, причем доступ к этому пространству могут иметь не только центральный процессор, но и платы устройств, способныхуправ- лять перед1aHe访 данных по шине. Теоретически максимальная скорость передачи по шине EISA в так называемом пакетном режиме (burst mode) может достигать 33 Мба访 17c. EISA работает с частот。访 8-10 МГц, а скорость передачи увеличивается, в основном, благодаря увеличению разрядности шины. До появления локальных шин VESA EISA имела прочные позиции на рынке серверов, однако высокая цена плат EISA и появление гораздо более быстрых шин VLB и PCI воспрепятствовали ее широкому распространению.
Шина VESA
Появление локально访 шины было первым шагом к формированию архитектуры PC с несколькими шинами, имеющими разную пропускную способность. Локальная шина не заменяла собо访【SA или EISA, а дополняла их за счет нескольких (до трех) разъемов. Первоначально эти шины использовались для обмена процессора с видеоадап-
тером, для которого не хватало скорости работы ISA (отсюда и термин -локальная шина), причем существовало несколько разных закрытых патентованных стандартов, что сдерживало распространение локальной шины. Поэтому в августе 1992 года ассоциация VESA (Video Electronics Standards Association), представлявшая более 100 компаний, предложила свою спецификацию локальной шины VLB (VESA Local Bus).
LUi/iHaVL-bus позволяет подключаемым к ней периферийным устройствам работать с тактовой частотой до 66 МГц. Она представляет собой двунаправленную 32-разрядную шину данных с теоретической пропускной способностью 160 Мбайт/с при частоте 50 МГц и 107 Мбайт/с при частоте 33 МГц. VL-bus является, по сути, расширением шины процессоров 80386 и 80486. Устройствами, подключаемыми к VL-bus, являются контроллеры накопителей, видеоадаптеры и сетевые платы. Конструктивно VL-bus представляет собой короткий разъем типа MCA (112 контактов), установленный позади разъемов расширения ISA или EISA. При этом 32 линии используются для передачи данных и 30 - для передачи адреса. Стандарт VL- bus (версия 2) предусматривал использование 64-разрядной шины данных и увеличение количества разъемов расширения, однако распространения он так и не получил.
Эпоха VL-bus закончилась с уходом со сцены 486-х процессоров. Дело в том, что VL-bus жестко привязана к шине процессора 80486, отличающейся от шин современных процессоров, для которых, в принципе, можно построить шину VL-bus с использованием микросхемы моста, однако эффективность работы таких плат очень низка. Кроме того, к качеству сигналов, передаваемых по шине процессора, предъявляются жесткие требования, поэтому нестабильность работы VLB-платы легко приводит к нестабильности всей системы. К тому же, количество плат в системе не превышает двух (максимум, трех) из-за ограниченной нагрузочной способности локальной шины процессора.
Шина PCI
Спецификация шины PCI (Revision 1.0) была представлена компанией Intel в июне 1992 года как спецификация процессорно-независимой шины. Учитывая опыт эксплуатации шины VL-bus (VESA), разработчики PCI отказались от использования шины процессора и ввели еще одну, «мезонинную» (mezzanine) шину. Благодаря этому шина может работать параллельно с шиной процессора (например, процессор работает с оперативной памятью, а в это время по шине PCI идет обмен данными с видеоадаптером или жестким диском). Важным фактором, способствовавшим широкому распространению PCI, стало то, что компания Intel объявила стандарт шины PCI открытым и передала его некоммерческой организации PCI SIG (PCI Special In-
terest Group), которая начала вести все работы, связанные с его поддержкой и дальнейшим развитием.
Шина PCI является синхронной 32- или 64-разрядной шиной, работающей на частоте 33 или 66 МГц. В современных PC пока используется 32-разрядная 33 МГцшина PCI, хотя есть и исключения: наборы микросхем для некоторых PC реализуют 64-разрядную шину, в мощных серверах также используется 64-разрядная шина PCI. Для уменьшения числа контактов в PCI применено мультиплексирование (передача адреса и данных по одним и тем же линиям в разные моменты времени). PCI позволяет использовать платы с напряжением питания 5 и 3,3 В. Шина допускает наличие нескольких активных устройств (multiple bus masters). Поддерживается пакетная передача данных. Шина PCI обеспечивает автоматическое определение и конфигурирование плат расширения (Plug&Play). Спецификация PCI позволяет создавать на одной плате многофункциональные устройства с числом функций до восьми.
Шина PCI в настольном конструктиве имеет четыре 124/188-кон- тактных разъема (32/64-разрядная версия), или 8 разъемов в конструктиве CompactPCI, применяемом в промышленных и военных компьютерах. Если необходимо большее количество разъемов, применяются микросхемы моста РС!-РС!(при этом пропускная способность шины уменьшается). Максимально возможная скорость передачи данных по шине PCI составляет от 132 Мбайт/с (для реализации шины 32-бита/33 МГц) до 528 Мбайт/с (для реализации 64-бита/66 МГц).
В настоящее время шина PCI является неотъемлемой частью настольных и портативных PC архитектуры х86, а также компьютеров Apple, Digital (Compaq) Alpha, Sun SPARC и др. Спецификация PC99 предполагает наличие в PC только этой шины (не считая AGP и интерфейсов передачи данных). Все интерфейсы передачи данных (EIDE, SCSI, USB, FireWire и др.) подключены к соответствующим контроллерам на шине PCI.
Применение шины PCI в системах CTI позволяет экономично реализовать приложения, требующие интенсивного обмена данными между телекоммуникационным периферийным устройством и оперативной памятью хост-компьютера. Например, с помощью специализированных плат с PCI-интерфейсом можно построить систему многоканальной записи-воспроизведения речевых сообщений без предварительного низкоскоростного кодирования речевых сигналов на плате - благодаря высокой производительности шины PCI потоки речевой информации со скоростью 64 Кбит/с записываются на жесткий диск компьютера непосредственно. При применении шины ISA передача по ней нескольких десятков таких речевых потоков практически парализовала бы работу центрального процессора компьютера.
Промышленные компьютеры
Разработчики специализированных систем для Call-центров и компьютерной телефонии с каждым годом все больше и больше пытаются использовать преимущества PC-совместимой архитектуры, чему немало способствуют стандартизация конструкций и главные преимущества РС-архитектуры - совместимость, гибкость конфигураций, большие объемы производства, и, как следствие, низкие цены.
Но если архитектуру можно, почти без изменений, адаптировать к специальным вариантам применения, дополнив ее некоторыми элементами и смирившись с некоторой избыточностью, то конструкция типа motherboard не может удовлетворить требования к таким параметрам, как механическая стойкость к ударным и вибрационным нагрузкам, большое количество плат расширения, устойчивость к климатическим воздействиям, компактность. Это обстоятельство привело к рождению новых конструктивных решений, таких как конструкция на основе пассивной объединительной платы с шинами ISA/ PCI для полноразмерных плат (стандарт, разработанный группой PIC- MG - PCI Industrial Computer Manufactures Group), аналогичная конструкция, применяемая в промышленных компьютерах и рассчитанная на платы половинной длины (до 185 мм) с шиной ISA, новый стандарт PISA, основанный на компромиссе между размером платы, шинами ISA и PCI, стандарт Compact PCI, пришедший на смену шине VME и Multibus в евроконструктиве, разработанный и поддерживаемый той же группой PICMG и рассматриваемый далее в этой главе.
Некоторые из названных конструктивных решений названы «стандартами» условно, так как им не всегда соответствуют какие-либо нормативные документы, выпущенные стандартизирующими организациями. Но именно в этом и заключается основное достоинство конструкций, наследующих один из главных признаков РС-совмес- тимой архитектуры, - стандарты не спускаются сверху, а устанавливаются производителями и поддерживаются пользователями де- факто. Разработчики первого персонального компьютера IBM не думали о стандартах, они разрабатывали дешевую и удобную конструкцию. И, несмотря на все недостатки этой конструкции, она жива до сих пор.
11-2.1 Compact-PCI
Разработанный в 1994 году под эгидой консорциума PICMG (PCI Industrial Computer Manufacturer^ Group - Motorola, Sun, HR Dialogic, Force и др.), стандарт Compact PCI объединяет в себе схемотехнику PCI с механическим стандартом Eurocard. Основной сферой применения аппаратуры на основе стандарта CompactPCI как раз и явля-
ются телекоммуникации. В настоящее время форум ECTF и PICMG специфицировали для стандарта CompactPCI шину компьютерной телефонии Н.110, что позволяет говорить об индустриальном стандарте для систем компьютерной телефонии. Коструктивно-механи- ческие, схемотехнико-логические и «Plug&Play» программные возможности этого нового стандарта представляются весьма привлекательными как для многих производителей телекоммуникационного оборудования, так и для операторов связи, а также для всех разработчиков и потенциальных пользователей систем компьютерной телефонии.
Открытость стандарта CompactPCI позволяет применять аппаратные и программные средства многих производителей, что является одним из главных условий успеха на развивающемся рынке приложений и систем компьютерной телефонии. К преимуществам стандарта CompactPCI перед некоторыми частными решениями в области телекоммуникаций и компьютерной телефонии относятся: программная и аппаратная открытость платформы, шина компьютерной телефонии Н.110(CTBus), конструктивы 3U и 6U Евромеханики, возможность «горячей замены» коммуникационных плат, стандартизованная IEEE1101.11 поддержка телефонного ввода/вывода через задние панели, прямая «Plug&Play» совместимость с программным обеспечением, работающем на стандартных Desktop PCI-платформах. Рассмотрим эти аспекты несколько подробнее.
СтандартCompactPCI основан на использовании конструктивов Евромеханики 3U и 6U с размерами плат 100мм х 160мм и 233,3мм х 160мм, соответственно. Простота вертикальной компоновки и лучшие условия для воздушного охлаждения являются несомненными преимуществами стандартных евромеханических конструкций. Другим принципиальным фактором, особенно важным при создании высоконадежных систем, является удобный доступ к модулям и быстрота ремонта/ восстановления. Так, в отличие от системных плат персональных компьютеров, процессорный модуль в системе CompactPCI извлекается и устанавливается столь же легко, как и любые модули ввода/вывода. Простоту компоновки обеспечивают также специальные задние кросс-платы, через которые может осуществляться ввод/вывод. При этом замена плат интерфейсов (в том числе телефонных) не требует откл ючен и я кабелей ввода/вывода. Все это резко уменьшает время простоя системы и увеличивает коэффициент готовности, что особенно важно для телекоммуникационных систем.
В CompactPCI используются штырьковые соединители с шагом 2 мм (IEC-917), к достоинствам которых относятся лучшее согласование импедансов сигнальных линий платы и объедин и тел ьной панели, меньшее время прохождения сигналов через коннектор. Именно электромеханические свойства соединителя позволили увеличить
число слотов в CompactPCI до 8. Программная совместимость Сот- pactPCl систем базируется на уже упоминавшемся принципе «Plug&Play». При применении интерфейсных схем Desktop PCI драйверы устройств остаются без изменений, что позволяет использовать все стандартные программные платформы - MS Windows 95/ 98/NT Solaris, Linux и др.
Рис. 11.1 Системный разъём CompactPCI
Важным достоинством применения стандарта CompactPCI в системах компьютерной телефонии является наличие стандартизованной шины компьютерной телефонии Н.110. Более подробно обН.110 будет сказано далее.
Для современных Call-центров и систем компьютерной телефонии, которые используются телефонными операторами и Интернет- поставщиками, особенную важность приобретают высокий коэффициент готовности и возможность 口инамическо「о конфигурирования системы. В таких системах добавление новых модулей и замену неисправных компонентов необходимо производить без выключения системы. Стандарт CompactPCI предусматривает возможность «горячей замены» (hot-swap). Спецификация «горячей замены» относится к интерфейсным микросхемам, модулям, платформам, операционным системам. Для установки CompactPCI модулей в системном разъеме используются контакты разной длины, что позволяет производить многоступенчатое включение/отключение. Спецификация определяет два варианта «горячей замены» - ручную и автоматическую.
При включении модуля в работающую систему происходит:
подача напряжения и собственная активизация модуля;
уведомление (генерация прерывания) операционной системы;
загрузка драйверов и программное подключение модуля операционной системой.
При удалении модуля происходит обратный процесс:
срабатывание микропереключателя, установленного на передней панели;
генерация прерывания операционной системы;
программное отключение модуля и удаление его из системных ресурсов;
команда выключения светодиода на передней панели;
удаление модуля.
В спецификации CompactPCI для компьютерной телефонии приводится определение способов использования тыльных переходных модулей, удовлетворяющих стандарту IEEE 1101.11. Эти модули соединяются с основными модулями через разъем J5 объединительной панели и обеспечивают ввод/вывод через заднюю панель. Одно из важных положений спецификации 一 возможность подключения к каждомувставномутелефонномумодулюдо 32 сигнальных пар. Это означает, что к одному модулю можно подвести до 16 каналов Т1/Е1, что позволяет строить системы с очень высокой плотностью линий, при этом одна 14-слотовая система может (теоретически) поддерживать до 224 каналов Т1/Е1. («Теоретически» - потому, что производительность и надежность подобной системы вызывают большие вопросы, и на практике комплексы со столь высокой степенью централизации стараются не строить, хотя вычисл ительные мощности процессоров сегодня позволяют это делать.)
Использование CompactPCI спецификации «горячей замены» в системах компьютерной телефонии позволяет повысить коэффициент готовности и применять динамическое конфигурирование. Так, например компания Motorola предлагает CompactPCI платформы компьютерной телефонии с коэффициентом готовности 99.999%, что соответствует среднему времени простоя системы около 5 мин в год.
11.2.2 Компьютеры с пассивной объединительной платой
Другой стандарт - двухшинная архитектура ISA/PCI - оказался весьма популярным в приложениях, связанных с обработкой речи. Ш ина ISA обеспечивает обратную совместимость с существующими телефонными платами речевого ввода на основе стандарта ISA, а шина PCI обеспечивает доступ к новым сетевым подсистемам и высокоскоростным дисковым подсистемам ввода/вывода. Стандарт ISA/ PCI позволяет создавать вычислительную платформу специализированной системы, по крайней мере, с вдвое меньшими затратами, чем при создании ее на базе стандарта CompactPCI, что для систем, стоимость которых ограничена конкуренцией на рынке, или просто для небольших систем (до 10-20 трактов Е1) очень и очень существенно.
11-2-3 Процессоры
В промышленных PC используются процессоры тех же моделей, что и в настольных системах, однако применение самых старших моделей ограничивается выделяемой тепловой мощностью - при небольших размерах корпусов и плат в условиях повышенной температуры окружающей среды очень трудно обеспечить такой же теплоотвод, как в настольной системе. Поэтому разработчики вынуждены идти на разные ухищрения - блокировать часть ненужных для промышленных компьютеров функций чипсетов, снижать тактовые частоты, применять версии процессоров с пониженным энергопотреблением, разработанные для применения в портативных компьютерах (notebook).
Стоит отметить, что современные процессоры последнего поколения (Pentium IV) обладают полезной способностью снижать выделяемую мощность (и тактовую частоту) при отказах системы охлаждения (процессорных вентиляторов), что существенно повышает надежность плат, использующих подобные процессоры, и расширяет перспективы их применения в системах с и ндустри ал ьн ы м уровнем надежности.
11-2,4 Контроллеры внешних устройств
Сегодня уже можно считать общепринятым решение, когда на процессорной плате размещены все контроллеры стандартных внешних устройств - контроллеры дисководов и винчестеров, контроллер одного параллельного и двух последовательных интерфейсов, контроллеры клавиатуры и мыши, часы реального времени.
Дополнительно на процессорной плате обязательно присутствуют сторожевой таймер (watch dog timer), обеспечивающий перезагрузку компьютера или выдачу прерывания при зависании управляющей программы, и конструктив для включения энергонезависимого электронного диска (FLASH) емкостью от 2Мб до 1 Пб.
По поводу энергонезависимых электронных FLASH-дисков имеет смысл сказать несколько слов. Придя на сменуППЗУ и обладая в сотни раз большим объемом памяти и быстродействием, FLASH-диски нашли применение в огромном количестве компьютерных устройств, в том числе, в модулях систем компьютерной телефонии, несвязанных с хранением больших объемов данных (например, в шлюзах IP- телефонии, интерфейсных модулях интеллектуальных платформ или в конвертерах сигнализации). Использование FLASH-дисков, не имеющих подвижных частей и более надежных, чем винчестеры (хотя и с более высокой стоимостью хранения единицы объема информации), позволяет создавать эффективные и надежные решения. FLASH-диски последнего поколения имеют сотни мегабайтов памяти, стоимость порядка сотен долларов и значительные тиражи про-
изводства, что, безусловно, способствует их широкому распространению.
Кроме этого, разработчики стремятся разместить на плате максимальное количество дополнительных контроллеров, таких как видеоконтроллер, контроллер сети, контроллер интерфейса SCSI. В некотором смысле, это обстоятельство ограничивает свободу выбора для системного интегратора или конечного пользователя, что не свойственно PC-совместимой архитектуре. К тому же, стоимость такого решения несколько выше, чем при использовании стандартных контроллеров, подключаемых через слоты расширения. Но с одной стороны, это решение связано с экономией слотов расширения для дополнительных устройств, а с другой стороны, разработчик получает возможность оптимального выбора всех подсистем компьютера и элементной базы, гарантируя пользователю определенный уровень быстродействия, надежности и программной совместимости. И не секрет; что основная масса проблем при конфигурации компьютера связана именно с некорректной работой отдельных внешних контроллеров. В случае использования процессорной платы с интегрированными контроллерами производитель процессорных плат берет на себя ответственность за правильную и сбалансированную работу всех компонентов и имеет возможность оперативно решать все возникающие проблемы, так как конфигурация вычислительной платформы заранее известна.
В отличие от офисных компьютеров, специализированные процессорные платы должны обеспечивать надежную работу с большим числом слотов расширения (до 20-ти). Со стороны процессорной платы выполнение этого требования обеспечивается специальными буферными элементами с повышенной нагрузочной способностью по всем линиям шины. Большинство производителей специально отмечает их наличие в технических спецификациях на плату. Немаловажное значение имеет также грамотное исполнение пассивной объединительной платы.
Содержание данного параграфа, конечно, не исчерпывает всех аспектов применения промышленных компьютеров, но рассмотрение других аспектов выходит за рамки этой главы.
11.3 Изобретение DSP
Если бы не был изобретен процессор цифровой обработки сигналов DS 尸,компьютерная телефония вряд ли бы стала такой, какова она сегодня. Без DSR без плат обработки речи не получились бы столь эффективные интерактивные услуги Call-центров, телефонный диалог человек-компьютер и пр. На DSPxe строятся сегодня схемы детектирования и генерирования сигналов DTMR систем многочастотной сигнализации R1.5, R2 и др.[4].
DSP (Digital Signal Processor) - это специализированный программируемый микропроцессор, предназначенный для обработки в реальном времени цифровых потоков графической информации, аудио- и видеосигналов. Не вдаваясь в детальное обсуждение цифровой обработки речи (что само по себе может составить содержание отдельной книги), приведем лишь сведения, необходимые с точки зрения рассматриваемой здесь тематики.
DSP принципиально отличаются от микропроцессоров, образующих центральный процессор PC. Центральному процессору приходится управлять работой различных компонентов аппаратного обеспечения компьютера, таких как дисководы, графические дисплеи и сетевой интерфейс, с тем, чтобы они работали согласованно. Это означает, что центральные процессоры PC имеют сложную архитектуру, поскольку они должны поддерживать такие базовые функции, как защита памяти, целочисленная арифметика, операции с плавающей запятой и обработка векторной графики. В итоге, типичный современный центральный процессор поддерживает несколько сотен команд, обеспечивающих выполнение всех этих функций. Следовательно, необходим модуль декодирования команд, позволяющий реализовать сложный словарь команд, а также множество интегральных схем. Они, собственно, и должны выполнять действия, определяемые командами. Иными словами, типичный процессор в настольном компьютере содержит десятки миллионов транзисторов.
DSR напротив, должен быть «узким специалистом». Его единственная задача - изменять поток цифровых сигналов, и делать это быстро. DSP состоит, главным образом, из высокоскоростных аппаратных схем, которые выполняют арифметические функции и манипулируют битами и оптимизированы так, чтобы быстро изменять большие объемы данных. В силуэтого набор команд у DSP куда меньше, чем у центрального процессора настольного компьютера; ихчис- ло не превышает 80. Это значит, что для DSP требуется облегченный декодер команд и гораздо меньшеечисло исполнительных устройств, которые, в конечном итоге, должны поддерживать высокопроизводительные арифметические операции. Таким образом, типичный DSP содержит лишь несколько сотен тысяч транзисторов. Будучи узко специализированным, этот процессор отлично справляется со своей работой. Его математические функции позволяют непрерывно принимать и изменять цифровой сигнал (такой как звукозапись в формате MP3 или запись разговора по сотовому телефону), не тормозя передачу информации и не теряя ее. Для повышения пропускной способности DSP оснащается дополнительными внутренними шинами, которые обеспечивают более быстрый перенос данных между арифметическими модулями и интерфейсами процессора. Особенности архитектуры DSP связаны с особенностью программ, по которым им приходится работать. Эти программы, как правило, вы-
полняются в реальном времени - по мере поступления входных сигналов, -что придает особую важность вопросам б ыст роде й стви я. Программы содержат много логических и, особенно, арифметических операций и практически не содержат переходов. Происходит постоянный и быстрый ввод/вывод данных, часто ~ в аналоговой форме. Программы относительно коротки и довольно редко изменяются, а зачастую остаются неизменными на протяжении всего срока эксплуатации процессора.
Эти факторы определяют ряд особенностей архитектуры DSP 一 использование так называемой Гарвардской архитектуры с раздельными блоками памяти для хранения программ и данных; большая (иногда нестандартная) разрядность обрабатываемых данных (16,24, 32, 48, 64, 128), что позволяет увеличить диапазон обрабатываемых чисел без применения формата с плавающей запятой или обрабатывать по нескольку чисел одновременно; наличие блоков, предназначенных для ускорения выполнения команды умножения (сдвиговых регистров, матричных умножителей); реализация памяти команд и данных на кристалле самого процессора; возможность одновременного выполнения нескольких операций, например, ввода/выво- да и арифметических команд; одинаковые длина и время выполнения всех команд, что позволяет использовать счетчик команд для отсчета временных интервалов.
Вытекающие из этого возможности обработки информации делают DSP идеальным средством для многих приложений. Используя алгоритмы, основанные на соответствующем математическом аппарате, DSP может воспринимать цифровой сигнал и выполнять специфические операции с этим сигналом.
Рассмотрим некоторые примеры архитектуры DSR Рис.11.2 иллюстрирует строение ядра процессора Motorola DSP 5680х. Раздельные внутренние шины команд, данных и адресов способствуют резкому повышению пропускной способности вычислительной системы. Наличие вторичной шины данных позволяет арифметическому устройству считать два значения, перемножить их и выполнить операцию накопления результата за один такт работы процессора.
Еще один пример DSP - процессоры цифровой обработки сигна- ловфирмы Texas Instruments, которая выпускает несколько семейств DSP, объединенных в серию TMS320. DSP этой фирмы разделяются на два класса - для обработки чисел с фиксированной точкой и для обработки чисел с плавающей точкой. Первый класс представлен тремя семействами процессоров, базовыми моделями которых являются, соответственно, TMS320.10,.20,.50. Второй класс включает в себя процессоры TMS320.30,.40, TMS320C80, которые поддерживают операции с плавающей точкой и представляют собой мультипроцессорную систему, выполненную в одном кристалле, и семей-
ство TMS320C6x, в которое входят процессоры как с фиксированной, так и с плавающей точкой. Процессоры старших поколений одного семейства наследуют основные архитектурные особенности и совместимы «снизу вверх» по системе команд (чего нельзя сказать о процессорах, входящих в разные семейства). Основные серии процессоров: TMS320C1X, TMS320C2x, TMS320C2xx, TMS320C3X, TMS320C4X, TMS320C5X, TMS320C54X, TMS320C6x, TMS320C8x.
Рис. 11.2 Структура DSP компании Моторола
Даже краткое рассмотрение всех этих семейств в данной книге просто невозможно, обратим внимание только на DSP семейства TMS320C6X. Сразу следует отметить, что это семейство создавалось в рамках платформы TMS320C6000, ориентированной на то, чтобы достичь максимального быстродействия при решении задач цифровой обработки сигналов. Принадлежность к платформе 'С6000 означает полную программную совместимость семейства 'С64х с серийно выпускаемыми семействами 'С62хи 'С67х, что дает возможность вести отладку программ для нового семейства, пользуясь уже существующими отладочными средствами. Таким образом, огромный объем программных наработок может быть перенесен на эти DSP с минимальными затратами времени. Семейство TMS320C62X включает в себя процессоры как с фиксированной, так и с плавающей точкой. Первый представитель этого семейства - TMS320C6201, оперирует с данными в формате с фиксированной точкой; его производительность - до 1.6 млрд, операций в секунду. Небесполезно отметить использование микропроцессоров TMS320C62X и в уже существующих прикладных системах для увеличения их производительности. К таким системам относятся: базовые станции мобильной связи; модемные пулы и серверы удаленного доступа; xDSL-модемы следующего поколения и кабельные модемы; многоканальные телефонные платформы, включая
центральные офисные коммутаторы, РВХ и системы речевой передачи сообщений; мультимедийные системы.
Построенный в соответствии с разработанной компанией Texas Instruments архитектурой VelociTI процессор 'С62хх - первый из сигнальных процессоров, использующий для повышения производительности параллелизм уровня команд. Традиционная VLIW-архитектура (Very Long Instruction Word) подразумевает наличие нескольких параллельно работающих функциональных устройств, выполняющих за один такт несколько инструкций. Принимая основные принципы повышения производительности суперскалярных процессоров, архитектура VelociTI позволяет обеспечить лучшую эффективность за счет ослабления ограничений на порядок и способ выполнения инструкций. Такая архитектурная гибкость создает предпосылки и для повышения эффективности компиляторов. Структура микропроцессора TMS320C6201 приведена на рис.11.3.
Рис. 11.3 Структура TMS320C6201
Широкое распространение DSPсделало возможной экономичную реализацию многих функций обработки речевых и звуковых сигналов, начиная от простейших - детектирования и передачи сигналов DTMF или других систем внутриполосной сигнализации - и заканчивая сложными функциями низкоскоростного кодирования речевых сигналов и распознавания речи в реальном времени. С увеличением единичной производительности чипов DSP становится возможным построение все более многоканальных систем компьютерной телефонии.
11.4 Функции плат компьютерной телефонии
К основным задачам, возлагаемым на платы компьютерной телефонии, являются: преобразование текст-речь (Text-to-speech, TTS), распознавание речи (Automatic Speech Recognition, ASR, или Speech- to-text), прием цифр номера (Digit Capture), инициирование телефонного вызова, прием, передача и хранение факсимильных сообщений. Кроме того, платы CTI реализуют интерфейсы для связи систем компьютерной телефонии с телекоммуникационным оборудованием по аналоговым линиям и трактам ИКМ, позволяют организовывать многосторонние конференции и др.
11 _4.1 Запись и воспроизведение речевой информации
Для реализации значительной части услуг компьютерной телефонии необходимы запись и последующее воспроизведение аудиоинформации, поступающей в систему компьютерной телефонии по телефонным каналам. При этом для хранения обычно используется жесткий диск компьютера. Аудиоинформация преобразуется в вид, приемлемый для записи на HDD, а кодирование звукового потока обеспечивают рассмотренные выше DSP-процессоры, что позволяет существенно разгрузить центральный процессор PC и использовать освободившиеся системные ресурсы для других целей. Чтобы сэкономить ресурсы накопителей, аудиоинформация в ряде случаев сжимается и хранится в уплотненном виде.
При воспроизведении звуковой информации также используются аппаратные средства. Информация, хранящаяся в запоминающих устройствах для ее последующего воспроизведения, может быть записана разными способами. Это может быть текстовый файл или файл, содержащий закодированную аудиоинформацию. Информация может быть получена по телефонным каналам, как, например, при предоставлен и и услуги речевой почты, или создана непосредственно перед воспроизведением, как, например, при реализации услуги точного времени.
В последнем случае одним из вариантов реализации услуги может быть запись в память PC всех составляющих, необходимых для произнесения любой нужной фразы. Чтобы имелась возможность произнести точное время «21:45», необходимы минимум 4 записи: «двадцать», «один», «сорок», «пять». Достаточно записать речевые фрагменты, содержащие простейшие элементы, из которых состоят числа, - единицы, десятки, сотни, тысячи и т.д., - и из них можно будет собрать любое число. А поскольку работа многих информационных систем (погода, расписание, курсы валют и акций) связана именно с произнесением чисел, то такого синтеза будет вполне достаточно для работы очень многих приложений. Несмотря на внешнюю
простоту подобной системы, с ней связан целый ряд проблем. Для того, чтобы синтезируемое сообщение звучало плавно, без разрывов, подставляемые слова должны быть интонационно встроены в общую фразу, достичь чего не так просто. В русском языке к этой проблеме добавляется еще проблема изменяемости слов, так что для каждого контекста, где встречается числительное в определенном падеже, приходится делать отдельную запись. Кроме того, в зависимости от числительного изменяются и окружающие его слова, например: «двадцать одна минута» «двадцать две минуты», что еще больше осложняет ситуацию. Тем не менее, существуют стандартные методы подготовки речевых фрагментов для такого способа формирования фраз. Этот способ годится для подавляющего большинства речевых систем
Более гибкой и перспективной технологией, позволяющей предоставлять автоинформационные услуги произвольного вида, является технологии синтеза речи, которая обеспечивает возможность звукового воспроизведения информации, хранящейся в текстовом файле. Если точнее - эта технология обеспечивает преобразование любого хранимого в компьютерном формате текста в синтетическую речь, звучащую приблизительно как человеческая. Центральным компонентом этой технологии является аппаратный синтезатор речи. Основная проблема, до настоящего времени еще не нашедшая полного решения, состоит в том, чтобы синтезированная из текста речь звучала «по-человечески» - пока компьютерная речь практически не имеет интонаций и ударений, а кроме того, имеются трудности с озвучиванием имен собственных и адресов.
Первый этап работы механизма синтеза речи состоит в том, чтобы избавиться от кавычек, скобок, апострофов и других знаков препинания. Эту задачу решает модуль нормализации, который, кроме того, обрабатывает зависящие от конкретного языка форматы дат, а также сокращения единиц времени, денежных единиц, телефонных номеров и другие специальные обозначения. Модуль преобразования переводит текст из орфографического формата в фонетический, т.е. из букв в звуки. Для некоторых языков, таких как немецкий, это довольно легко, поскольку правила преобразования просты. В английском же, напротив, эти правила отличаются большой сложностью, а для многих случаев их и вовсе не существует. Например, окончание ough, может произноситься шестью разными способами. В русском языке правила проще, но тоже имеются хорошо известные читателям аномалии, которые создают трудности синтезирования речи на компьютере.
Модуль анализа выполняет одновременно лексикографическую и синтаксическую обработку для выбора нужного из возможных вариантов произношения, а также ритма и интонации. Лексический
анализ применяется для выяснения значения слова с учетом контекста, а синтаксический - для проверки порядка следования слов с целью расставить акценты. Результатом работы модуля анализа является фонетическое представление исходного текста, которое передается на вход фонетического модуля. Здесь данные из входного потока заменяются такими элементами речи, как дифтонги, трифтонги и четырехзвучия. Все они были выделены из естественной человеческой речи, так что в них сохранены межфонемные переходы (гладкие переходы от произнесения одного звука к произнесению другого). Связывание или сцепление вместе этих речевых элементов позволяет получить высококачественную синтезированную речь.
Этот же модуль обеспечивает разбиение текста на сегменты для формирования ритмического и интонационного рисунка (просодии).
■ В л итературоведен и и понятие просодия связывается с рифмой и размером стиха, а в контексте компьютерного синтеза речи под этим словом подразумевается ритмический и интонационный баланс предложения. Для формирования легкой для восприятия и естественно звучащей речи хорошая просодия имеет очень важное значение. Она достигается выбором надлежащей длительности воспроизведения каждой фонемы и обеспечением гладкой огибающей звуковой последовательности.
Модуль обработки звука преобразует фонетические данные в слышимые звуковые сигналы. Он генерирует волновые последовательности с частотой дискретизации 8 Гц. На этой стадии производится управление громкостью, быстротой речи и высотой голоса.
11-4.2 Распознавание речи
Как уже говорилось в главе 4, сегодня для взаимодействия человека с системой компьютерной телефонии при предоставлении ему интерактивных автоинформационных услуг; как правило, используется многочастотный DTMF-донабор. Однако в ряде случаев этой технологии недостаточно, илиона не вполне комфортна для пользователя. Предполагается, что в таких случаях на смену ей придет технология автоматического распознавания речи (Automatic Speech Recognition, ASR).
Применение технологии ASR позволяет пользователю давать компьютеру устные команды, управляя, таким образом, его работой. На сегодня это, пожалуй, одна из самых сложных проблем в области интерфейса человек-компьютер. Несмотря на некоторые успехи, достигнутые в последнее время, до полного решения проблемы еще далеко.
Все известные алгоритмы распознавания речи работают на базе словарей, причем количество и характер слов для разных языков и для разных режимов распознавания речи отличаются друг от дру-
га. Алгоритмы распознавания выделяют отдельные слова в речевом сигнале и преобразуют их в текст.
Существует два режима распознавания речи 一 с настройкой на голос определенного пользователя (дикторозависимый) и без настройки (дикторонезависимый). При первом режиме объем словаря может достигать нескольких десятков тысяч слов, которые распознаются при слитном произнесении. Такой режим применяется, когда у системы компьютерной телефонии имеется только один пользователь, который может по телефону давать системе команды и даже диктовать письма. Кроме того, этот пользователь может составить список часто вызываемых абонентов и отдавать системе устное приказание набрать номер того или иного абонента из списка, просто называя его имя.
Для систем общего пользования необходим режим распознавания без настройки на голос определенного пользователя. Такие системы тоже работают на основе словаря, который, однако, содержит гораздо меньшее количество слов. Словари для распознавания речи без настройки на определенного пользователя создаются на основе образцов речи, полученных от многих сотен или даже тысяч носителей языка. Такие словари могут обеспечивать либо распознавание цифр от нуля до девяти и нескольких простейших команд при их раздельном произнесении, либо распознавание цифр и более узкого набора команд при их слитном произнесении, либо распознавание цифр и названий всех букв алфавита.
Над технологиями распознавания речи работает множество компаний, однако все они следуют, в основном, одной и той же базовой методологии, основанной на четырехэтапной процедуре. Различия сводятся к тому, какие методы математического моделирования и алгоритмы применяются. Предпроцессор производит предварительную обработку поступающего сигнала. В нее могут входить автоматическая регулировка усиления, подавление эха, обнаружение при- сутствия/отсугствия речи и обнаружение интонационного конца фразы. Цель этого этапа обработки состоит в том, чтобы передать на следующий этап сигнал возможно более высокого качества.
Экстрактор выполняет частотный анализ сигнала. Акустическо- фонетичесий поток данных разбивается на короткие кадры, или векторы, продолжительностью, как правило, около Юме. Применяемые алгоритмы имеют достаточную акустическую устойчивость благодаря адаптивности канала записи и подавлению шумов на предыдущем этапе.
Компаратор производит акустическое сравнение - каждый кадр (вектор) сравнивается с имеющимися акустико-фонетическими образцами слов. Для каждой пары вычисляется функция правдоподобия.
Интерпретатор решает задачу динамического программирования с целью найти наилучшее разбиение полученного от компаратора «алфавитного» потока на слова и фразы. В зависимости от объема используемого словаря и действующих синтаксических правил применяется та или иная стратегия поиска.
В результате описанных выше действий механизм распознавания речи выдает поток слов и предложений. Чтобы некоторое приложение могло воспользоваться этим его конечным продуктом, необходим рассматривавшийся ранее прикладной программный интерфейс API, который дает средства управления механизмом распознавания. В частности, API охватывает такие административные функции, как изменение языка, пользователя или рабочей среды, запуск или остановка процесса распознавания, выборка результатов и т.п.
В заключение следует отметить, что приемлемой технологии дикторонезависимого распознавания речи для языков славянской группы сегодня, увы, не существует.
Обработка межстанционной и абонентской сигнализации
В предыдущей главе мы подробно рассмотрели программные аспекты реализации протоколов сигнализации и интерфейсной части систем компьютерной телефонии. Между тем, внимания заслуживает и аппаратная реализация подсистем обработки межстанционной и абонентской сигнализации.
Очевидно, что аппаратная реализация интерфейсной подсистемы (схемотехническое решение) целиком определяется тем, какой из трех основных интерфейсов поддерживается платой (двухпроводная аналоговая абонентская линия, линия базового доступа ISDN или цифровые тракты Е1Д1), а точнее - теми основными действиями, которые должна выполнять плата при обработке сигналов, принимае- мых/передаваемых через телефонный интерфейс.
Для двухпроводных линий основными действиями являются управление состоянием линии (замыкание/размыкание шлейфа), распознавание линейных сигналов, поступающих от опорной АТС (вы - зывной сигнал), а также распознавание акустических сигналов, используемых при обслуживании вызова (КПВ, Занято).
Не останавливаясь подробно на схемных решениях для поддержки интерфейса базового доступа (в силу ограниченного применения такого интерфейса в отечественных сетях), перейдем сразу к решениям для поддержки интерфейса Е1 (ИКМ-30). Очевидно, что на аппаратную часть интерфейсной подсистемы возлагаются функции формирования и распознавания цифрового потока, соответствующего рекомендациям G.703/704, а также прием, формирование и передача HDLC-пакетов при использовании общеканальной сигнализации (ОКС7, DSS1/PRI), или прием/передача линейных сигналов
CAS/BCK и многочастотных сигналов регистровой сигнализации R1,5/R2, а также тональных сигналов.
Основные компоненты всех цифровых интерфейсных плат, поддерживающих Е1, примерно одинаковы (рис. 11.4).
Рис. 11.4 Типовая схема интерфейсной платы сигнализации по тракту Е1
Схема интерфейса Е1 построена на БИС, которые поддерживают информационный обмен по ИКМ-тракту и выполняют следующие функции:
синхронизацию потоков с привязкой их к импульсам синхронизации системы и с использованием внутренней буферной памяти разговорных каналов;
выделение и формирование в потоке Е1 канала синхронизации (0- канал) и формирование импульсов тактовой частоты приема для внешних схем синхронизации;
автоматическую обработку аварийных ситуаций и подсчет ошибок;
поддержку тестирования схемы в разных режимах, задаваемых программно;
работу с ИКМ трактами разных стандартов, задаваемых программно.
Генератор сигналов синхронизации формирует тактирующие и синхронизирующие сигналы, необходимые для работы схемы.
Процессоры DSP используются для обработки и генерации акустических и речевых сигналов (воспроизведение подсказок, DTMF и т.д.) в каналах ИКМ-трактов.
Прием цифр номера
Системы компьютерной телефонии должны воспринимать команды абонента, которые, в простейшем случае, вводятся путем набора цифры на телефонном аппарате. Отсюда следует, что аппаратура для компьютерной телефонии должна распознавать, какую цифру набрал абонент.
Для набора номера могут использоваться две принципиально разные системы -DTMF (Dual-Tone Multifrequency) и импульсный набор. Для системы DTMF имеются стандартные схемные решения распознавания частот, поэтому обработка сигналов набора никаких затруднений не представляет. С импульсным набором дело обстоит сложнее 一 каждая цифра кодируется серией размыканий цепи между телефонным аппаратом и коммутационным оборудованием АТС. Основная проблема состоит в том, что размыкания цепи не передаются дальше абонентской линии, поэтому на другом конце соединения прослушиваются только характерные щелчки. Эти щелчки приходится распознавать, а сделать это при наличии помех в линии весьма и весьма затруднительно. (Разработчики подобных систем преподносят, как достижение, возможность распознавать одну цифру импульсного набора с вероятностью 0,9. Однако это означает, что введенный таким способом 9-значный PIN-код будет корректно распознан лишь с вероятностью 0,99=0,39, что может оказаться не очень удобно абоненту при пользовании услугой.)
Инициирование вызова
Call-центры и другие системы компьютерной телефонии должны сами производить набор номера (например, такой элемент услуги, как исходящий вызов, присутствует в услугах связи по телефонным картам, при исходящей связи в Call-центрах и в услуге оповещения).
Что касается систем, включенных в 坤ОП по СЛ (по цифровым трактам Е1), то инициирование исходящего вызова - дело, плавным образом, программное (см. Гл.10).
А если система компьютерной телефонии включается в 坤ОП по двухпроводным АЛ, то она должна выполнять также и мониторинг линии. Речь идет о распознавании акустических сигналов, говорящих о состоянии соединения: контроль посылки вызова (КПВ), снятие трубки на противоположном конце, короткие гудки сигнала ЗАНЯТО и даже отсутствие гудков, когда соединение не установилось. Кроме того, многие системы компьютерной телефонии должны различать, отвечает ли им человек, автоответчик или факсимильный
аппарат. Распознавание «типа» отвечающего основано на следующем. Факсимильный аппарат отвечает длинным сигналом готовности, который легко отличить от редких гудков и от человеческой речи. Человек, снимая трубку, коротко отвечает «Алло!» или, в крайнем случае, называет себя. Автоответчик же начинает долго рассказывать, куда вы позвонили, и что надо сделать, чтобы оставить свое сообщение.
11.5 Реализация плат компьютерной телефонии
Как уже отмечалось выше, одним из основных компонентов систем компьютерной телефонии являются речевые платы. Эти платы обладают возможностью оцифровывать, сжимать и воспроизводить речь, а также выполнять ряд функций, необходимых для телефонного соединения (набор номера, мониторинг линии, распознавание окончания разговора и т.п.) и описанных в предыдущем параграфе. Все эти функции речевые платы выполняют на аппаратном уровне, без обращения к центральному процессору, в результате чего даже довольно мощные системы могутбыть реализованы на базе относительно маломощных компьютеров (модели от 1386 и старше). Технической базой для работы этих плат являются специализированные процессоры DSR поддерживающие выполнение всех вышеупомянутых преобразований речевого сигнала.
Другим важнейшим компонентом аппаратных средств компьютерной телефонии являются коммутационные (интерфейсные) платы, используемые для организации интерфейса с телекоммуникационными устройствами и системами, для внутренней коммутации ресурсов и для организации конференций между телефо иными линиями, подключенными к одной системе.
В набор аппаратных средств могут также входить факсимильные платы и платы для аппаратного преобразования текст-речь.
Следует отметить, что разделение плат на группы (речевые, факсимильные и интерфейсные) произошло на самой ранней стадии развития компьютерной телефонии и было обусловлено, во-первых, ограниченностью ресурсов DSP и ресурсов персональных компьютеров, а во-вторых, тем, что системы CTI использовались, в значительной своей части, как речевые приставки к коммутационному оборудованию УАТС для реализации услуг IVR, речевой почты и т.д. (см главу 4). Сегодня, когда на системы компьютерной телефонии во многих случаях возлагаются такие функции обслуживания вызовов, которые раньше были присущи только специализированному телекоммуникационному оборудованию, многое изменилось, и стали появляться интегрированные платы, сочетающие в себе функциональные возможности всех вышеупомянутых элементов аппаратного обеспечения CTI.
Одним из наиболее известных (и стоявших у истоков отрасли) производителей плат компьютерной телефонии является американская компания Dialogic Corporation, ныне поглощенная корпорацией- гигантом Intel. Именно Dialogic первой создала модульный набор плат расширения для систем компьютерной телефонии, обеспечивший возможность создания самых разноплановых приложений CTI. По выполняемым ими функциям эти платы делятся на группы, кратко рассматриваемые далее в этом параграфе.
Начнем с речевых и интерфейсных плат. В изделиях Dialogic описанные выше функции поддержки интерфейса с ТфОП, оцифровки, записи и воспроизведения речевых ресурсов, распознавания и генерации звуковых сигналов и сигналов DTMF интегрируются на единой плате. В таких платах при внимательном рассмотрении можно четко выделить две функциональные части 一 интерфейсную и речевую. Это разделение становится особенно очевидным при программировании плат-одна группа функций выполняет операции, связанные с телефонными соединениями, другая - запись на диск и воспроизведение звука в линию. При этом в речевых платах (рис.11.5) на каждую подключенную аналоговую линию выделяется независимый ресурс, позволяющий записывать надиск PC звуковую информацию, получаемую по этой линии, или воспроизводить звук в эту линию. Таким образом, плата способна одновременно работать со звуковой информацией, относящейся ко всем 16 подключенным к ней аналоговым линиям.
Соединение с дополнительными
Рис. 11.5 Общая схема речевой платы Dialogic
Что касается интерфейсной части, то в номенклатуре плат Dialogic существуют модификации, поддерживающие от 2 до 16 аналоговых абонентских линий, от 2 до 8 интерфейсов базового доступа ISDN и от одного до 4-х цифровых потоков Е1Д1,
Перейдем к платам распознавания речи. Как уже отмечалось выше, распознавание речи может осуществляться в двух режимах - с настройкой на голос определенного пользователя и без настройки.
На данный момент существуют три типа словарей для работы без настройки на голос пользователя - цифровой, алфавитно-цифровой и словарьдля распознавания слитной речи. В цифровой словарь входят цифры от нуля до девяти, слова «да», «нет», «стоп», «помощь» и некоторые другие, в алфавитно-цифровой, помимо этих слов, включены названия всех букв алфавита, а словарьдля распознавания слитной речи (первые два словаря предполагают произнесение слов по одному) содержит цифры от нуля до девяти и слова «да» и «нет». Цифровые словари существуют для нескольких десятков языков, включая русский. Алфавитно-цифрового словаря для русской речи, как уже отмечалось, пока нет.
В настоящее время с платами Dialogic поставляются два русских словаря. Первый содержит слова «ноль», «один», «два», «три», «четыре», «пять», «шесть», «семь», «восемь», «девять» и слово «остановиться»; второй словарь содержит слова «да», «нет», «остановиться», «переносится», «аннулируется», «помогите». Такое разделение сделано для того, чтобы легче различать очень схожие по звучанию слова «да» и «два». Физически эти два словаря содержатся в одном файле и загружаются в плату вместе, но в каждый конкретный момент может работать какой-либо один из них.
Факсимильные платы обеспечивают отправку и получение факсимильных сообщений. Выпускаются они как в виде приставок к речевым платам, так и в виде автономных плат. Кодирование в образ документа, обработка входящих сообщений и т.п. производится в платах того и другого вида аппаратно по нескольким каналам одновременно. Автономные факсимильные платы могут сами набирать номер, вести мониторинг линии и распознавать сигналы DTME
Специализированные платы для аудиоконференций служат для организации больших аудиоконференций. Одна плата может поддерживать одновременно до трех конференций по 32 участника в каждой. Существенными характеристиками специализированных DSP-плат для аудиоконференций являются гибкость, обеспечивающая для многих пользователей возможность динамического подключения к разным конференциям (в зависимости от числа установленных DSP); высокая плотность участников одной конференции, работающих в полнодуплексном режиме (в случае Dialogic - 32); монито- ринг(прослушивание) одной конференции практически неограниченным числом слушателей с использованием шины SCbus; обнаружение активного участника, т.е. возможность аппаратно определять, кто из участников в данный момент говорит; автоматическое управление громкостью, обеспечивающее выравнивание уровней речевого
сигнала разных участников; индивидуальное управление громкостью звука конференции каждым ее участником; инструктаж одним участником другого в таком режиме, что остальные участники этого не слышат, доступ по SCbus, позволяющий подключать к конференции до 1024 слушателей, а также работать в одной системе с другими речевыми, интерфейсными и факсимильными платами; определение и подавление сигналов DTMF (плата принимает и распознает DTMF-сигналы отлюбого участника конференции, а другие участники их не слышат).
Поясним попутно, что SCbus - это двунаправленная, высокоскоростная мультиплексированная шина с возможностью управления основными параметрами для связи в синхронном режиме. SCbus соединяет установленные в компьютере платы и обеспечивает их совместную работу. Главными достоинствами SCbus являются ее емкость (до 1024 полнодуплексных каналов) и возможность коммутации любых двух каналов между собой. С помощью специальных плат SCxbus Adapter через SCbus можно соединять платы Dialogic, установленные в разных компьютерах. При этом компьютеры должны находиться на расстоянии не более 15 м один от другого.
Платы для подключения телефонных аппаратов и организации конференций предназначены, в основном, для подключения телефонных аппаратов или гарнитур операторов. Поддерживают интел лектуа льную коммутацию как местных, так и внешних линий. Кроме названных функций, указанные платы обеспечивают организацию полнодуплексных конференций. Для плат этого типа, производимых Dialogic: расстояние от телефонного аппарата до платы - не более 1000 м, максимальное количество участников одной конференции -8; количество одновременных полнодуплексных конференций -от 3 (при 8 участниках в каждой) до 16 (при двух участниках). Стоит подчеркнуть, что ограничение «до 8 участников» не означает, что в принципе невозможны конференции с большим числом участников. С помощью SCbus можно объединять в одну конференцию до 1024 участников. И хотя, действительно, в каждый момент времени «правом голоса» будут обладать лишь 8 из них, в реальных условиях это не является принципиальным недостатком.
Специализированные платы для IP-телефонии Dialogic DM3 IPLink описаны во многих источниках.
Основные функции и характеристики DM3 IPLink:
поддержка стандарта ITU-T Н.323.2;
различные алгоритмы сжатия, в том числе ITU-T G.723.1, ITU-T G.729a, ITU-T G.711, GSM, Voxware RT24 и др.;
поддержка стандартных Internet-протоколов, включая TCP/IR UDP и RTP/RTCP;
встроенный Ethernet-интерфейс WBaseT;
автоматическая регулировка уровня сигнала (AGC, Automatic Gain Control);
определение наличия речевого сигнала (VAD, Voice Activity Detection) для оптимизации использования пропускной способности сети;
подавление шумов;
подавление эха (ITU G.165);
компрессия пауз;
управляемый буфер приема (variable jitter buffer control);
внешняя обработка DTMF-сигналов;
API для управления соединениями (call control API) разгружает процессор компьютера и минимизирует задержку, достигая максимальной пропускной способности и оптимизируя использование ресурсов;
определение состояния линии и соединения, запись и воспроизведение, распознавание и генерация частотных сигналов (в том числе, DTMF), управление громкостью, устойчивость к шумам;
интерфейс Н.100 СТ Bus для платРС!;
интерфейс SCbus для совместимости с другими платами компьютерной телефонии;
API под Windows N[ т.е. набор функций, позволяющих разработчикам создавать собственные приложения IP-телефонии;
поддержка до 4 аналоговых АЛ или до 2-х потоков Е1.
В зависимости от функциональных требований и количества те- лефонныхлиний в компьютер может быть установлено необходимое количество плат Dialogic (это не касается только платы, описанной последней). Далее все платы соединяются между собой с помощью шины SCbus, через которую происходит обмен всей информацией.
Количество плат, устанавливаемых в один компьютер, ограничено количеством в нем свободных слотов. Dialogic выпускает платы как для шины ISA, так и для PCI. Кроме того, через SCbus можно соединять несколько компьютеров с установленными платами Dialogic с помощью специальных плат SCxbus Adapter. При этом компьютеры должны находиться на расстоянии не более 15 м друг от друга.
В главе 3 упоминались стандартные спецификации шин компьютерной телефонии Н.100 и Н.110 СТ Bus, разработанные ЕСТЕ Это соглашение описывает новую высокопроизводительную шину компьютерной телефонии, которая позволяет обеспечить совместимость существующих решений, использующих SCbus, с приложения-
ми компьютерной телефонии на базе MVIP-90. Так же, как SCbus, Н.100/Н.110 СТ Bus является средством для внедрения SCSA Hardware Model с использованием платформ PCI и ePCI.
И, в заключение этого параграфа, рассмотрим аппаратное обеспечение отечественной разработки - семейство плат, используемых в приложениях на базе интеллектуальной платформы Протей.
С точки зрения упоминавшейся выше классификации, эти платы являются комбинированными интерфейсными/речевыми платами, обеспечивающими весь набор функций, необходимых для построения приложений компьютерной телефонии, таких как:
поддержка цифровых интерфейсов Е1, используемых для связи с оборудованием телефонной сети;
коммутация разговорных каналов;
запись (с компрессией) и воспроизведение речевых подсказок,
распознавание и генерация многочастотных сигналов межстанционной сигнализации, акустических сигналов и сигналов DTME
В модификациях TSP4 и ITSP, предусматривающих возможность строить, помимо традиционных телефонных приложений, еще и приложения 1Р-телефонии, обеспечивается кодирование/декодирова- ние речи с использованием высокоэффективных кодеков G.723, G.729, пакетирование речи (RTP/RTCP), поддержка функций подавления эха (G.165) и функций обработки факсимильного трафика. Поддерживаются также контроль активности речи (подавление пауз) и управление громкостью звука.
Платы используются в протокол-тестерах и конвертерах сигнализации, описанных в [4], а также во всех других системах, строящихся на базе интеллектуальной платформы Протей.
Одна плата, в зависимости от модификации и варианта применения, поддерживает 2, 4 или 8 ИКМ-трактов. Архитектура платы практически в точности соответствует типовой архитектуре подобных плат, показанной на рис.11.4. Плата TSP содержит следующие узлы: схемы интерфейса Е1; систему коммутации; контроллер HDLC (реализованный на DSP-процессоре); генератор сигналов синхронизации; процессоры цифровой обработки сигналов; интерфейс с системной шиной (ISA в модификациях TSP-2, -3, PCI в модификации TSP-4).
Важно отметить, что тип используемой сигнализации определяется исключительно программными средствами и загружаемыми прошивками DSP-процессоров, так что указанные платы безо всякой модификации могут подключаться к оборудованию телефонной сети с использованием любого из протоколов, применяемых в ТфОП.
Генератор сигналов синхронизации формирует тактирующие
и синхронизирующие сигналы. Петля цифровой фазовой автоподстройки обеспечивает подстройку частоты системных синхросигналов в диапазоне ±100-10'6 в зависимости от частоты, выделяемой схемами интерфейса Е1 из входных потоков ИКМ. При этом производится фильтрация быстрых колебаний опорного сигнала,
DSP-процессоры используются для обработки и генерации акустических и речевых сигналов в каналах ИКМ-трактов, для реализации функций компрессии/декомпрессии и пакетирования речи, для подавления эха, а также для обработки интенсивных потоков HDLC- кадров. Последняя функция используется, например, в приложениях, где требуется поддержка нескольких сигнальных каналов ОКС7 и, соответственно, аппаратная реализация приема/генерации заполняющих сигнальных единиц. Благодаря использованию высокопроизводительного контроллера HDLC в центре обработки коротких сообщений Протей-СЦ, один коммутационный модуль обрабатывает до 8 сигнальных каналов ОКС7.
Завершим этим рассмотрение как аппаратных средств, используемых в приложениях компьютерной телефонии, так и всей совокупности идей, концепций и технологий Call-центров и компьютерной телефонии 3-го поколения. Конечно, изложенное в книге отнюдь не исчерпывает всего того, что можно было бы рассказать об этой бурно развивающейся индустрии. Индустрии, создающей основу для новых инфокоммуникационных услугмультисервисных сетей следующего поколения - NGN (Next Generation Networks), - грандиозные возможности которых сегодня еще трудно до конца осознать, по крайней мере, авторам книги. Более точно об этом сказано задолго до 1Р-телефонии в мудрых строках Омара Хайяма:
Удивленья достойны поступки творца!
Переполнены горечью наши сердца:
Мы уходим из этого мира, не зная
Ни начала, ни смысла его, ни конца.
Литература
Бернштейн С.С. К анализу алгоритма АТС//С6, трудов НИИТС №12, 1963.
Варламова Е. IP-телефония в России/Connect! Мир связи.-1999.-№9.
Гольдштейн Б.С., Ехриель И.М., Рерле РД. Интеллектуальные сети// М.: Радио и связь, 2000.
Гольдштейн Б.С. Сигнализация в сетях связи. Том 1. Протоколы сети доступа. Том 2//М,: Радио и связь, 2001.
Гольдштейн Б.С., ПинчукАЪ., Суховицкий А.Л. 1Р-телефония//М.; Радио и связь, 2001.
Джермейн К. Программирование на IBM/360: Пер. с англ./Под ред. В.С. Штаркмана, - 4-е изд.-М,:Мир, 1983.
Евгеньев А. Услуга предоплаты (prepaid) у нас и в мире/^еЬ-Модус.- 1999.-№2.
Компьютерная телефония.-2000.-№1.
КухарчукА.П, Струтинский Л.А. Особенности структуры управляющего комплекса для системы коммутации. - В кн.: Операционные системы комплексов ЭЦВМ. Киев: Изд. АН УССР 1972,
Машбиц Г.Я. Структуры комплекса управляющих программ УК “Не- ва-IM11. - Сб. Института кибернетики АН УССР. Техническое и программное обеспечение систем реального времени. - Киев: АН УССР 1980, с.20-27.
Муссель К.М. Компьютерной телефонии в России исполняется... 20 лет!//Компьютерная телефония,-1999.-№2-3.
Таранов П.С. Маневры общения: Миниатюры сокровенныхтайн//Д.: Сталкер.-1999
Уиллис Д. Хороший стандарт - плохой стандарт//Сети и системы связи.-1999. -№14
Фрейнкман В.А., Пигорева О.И. Системы универсальных сообщений -некоторые аспекты стандартизации//Вестниксвязи.-2001 .-Ns4.
Шнепс-Шнеппе М.А., Крестьянинов С. В., Полканов Е.И. Интеллектуальные сети и компьютерная телефония//М.: Радио и связь, 2001.
ЭрглисК.Э. Интерфейсы открытых систем//М.: Горячая линия-Телеком, 2000. - 256 с.: ил.
Яффе В.А. Некоторые вопросы разработки языка Ассемблер для спе- циализироваиного управляющего комплекса / Сб. Института кибернетики АН УССР Техническое и программное обеспечение систем реального времени / Киев: АН УССР 1980, с.32-36.
Asatani К. IP and Telecommunication Integration: De Jure and De Facto Standards have Entered a New Era//IEEE Communications Magazine - July, 1999.
Brooks John. Telephone: The First Hundred\fears//Harper & Row, 1976.
Caputo R. Cisco Packetized Voice and Data lntegration//McGraw-Hill Cisco Technical Expert - 2000.
Douskalis B. IPlelephony.The Integration of Robust VolPServices//Pren- tice Hall, 1999.
Edgar Bob. PC Ielephony//Flatiron Publishing - N.Y - 1995.
Elbert Bruce R. Private Telecommunication Networks//Artech House - 1989.
Faynberg I., Gabuzda L., Lu Hui-Lan. Converged Networks and Services: Internetworking IP and the PSTN//John Wiley & Sons - 2000.
Green, James Harry. The Irwin Handbook of Telecommunications /2nd edition/ Irwin Professional Publishing - 1992.
Horak R. Communications systems & networks /Second Edition/ M 员 T Books and IDG Books Worldwide, Inc. - 2000.
Jadoul M., O'Pella L. IN@lntemetTM: Intelligent Network services for the new world/Alcatel Telecommunications Review.-2nd quarter.-2000,
Newton, Harry. Newton's Telecom Dictionary, 15th Edition. Miller Freeman, Inc./February 1999.
Shapiro Jeffrey R. Computer Telephony Strategies//lDG Books Worldwide, Inc. An International Data Group Company. - 2000.
Toga J., Ott J. ITU-T standardization activities for interactive multimedia communications on packet-based networks: H.323 and related recom- mendations//Computer Networks, 1999.
Б.С. Гольдштейн - автор более 150 печатных работ в области телекоммуникаций. Его перу принадлежат, в частности, книги «Сигнализация в сетях связи», «Протоколы сетей доступа», «Интеллектуальные сети» (в соавторстве с И.М. Ехриелем и Р.Д. Рерле), «1Р-телефония» (в соавторстве с А.В. Пинчуком и А.Л. Суховицким). Заместитель директора ЛОНИИС по научной работе и начальник научно-исследовательского отделения этого института. Заведующий кафедрой систем коммутации и распределения информации Государственного университета телекоммуникаций им.М.А. Бонч-Бруевича. В 1982 г. защитил кандидатскую диссертацию «Исследование и разработка телефонной операционной системы электронного узла коммутации», а в 1994 г. - докторскую диссертацию «Численные методы анализа и проектирования
программного обеспечения систем коммутации», академик МАС и МАИ, «Мастер связи», член 10-ой Исследовательской комисси ITU-T лауреат премии Birmingham Torch Award, член IEEE.
В.А. Фрейнкман родился в 1973 году, а в 1995 году окончил Санкт-Петербургский государственный университет телекоммуникаций им. проф, М.А. Бонч-Бруевича. После защиты дипломного проекта пришел на работу в ЛОНИИС, где принял непосредственное участие в организации и выполнении ряда ключевых НИОКР в областях компьютерной и 1Р-те- лефонии, предоставления интеллектуальных телекоммуникационных услуп преобразования протоколов и оборудования сети доступа. В ведущих телекоммуникационных журналах отрасли опубликовал более 10 печатных работ.
Гольдштейн Борис СоломоновичФрейнкман Владимир Анатольевич
CALL-ЦЕНТРЫ И КОМПЬЮТЕРНАЯ ТЕЛЕФОНИЯ
Компьютерная вёрстка М.А. Фрост
ЛР № 065953 от 15.06.98
Подписано в печать 02.04.2002
Формат 70x100Хе.
Бумага офсетная.
Гарнитура прагматика. Печать офсетная.
Объем 24 печ.л. Усл. печ. л. 23,5
Тираж2500 экз. Зак № 3160
Издательство «БХВ - Санкт-Петербург», 198005, Санкт-Петербург; Измайловский пр., д.29
Отпечатано с готовых диапозитивовв Академической типографии «Наука» РАН199034, Санкт-Петербург 9 линия, 12
ISBN 5-8206-0105-Х
9 785820 60 1 057
Б.С. ГЪльдштейн. ВА Зрейнкман
^ALL-ЦЕНТРЫ
Б.С. Пэльд山те访н, В.А.①ре访нкман
CALL-ЦЕНТРЫиКОМПЬЮТЕРНАЯТЕЛЕФОНИЯ
Санкт-Петербург
2002
УДК 621.395.34
Г63
ББК 32.881
Гольдштейн Б.С., Фрейнкман В.А.
Call-центры и компьютерная телефония.—
СПб.: БХВ - Санкт-Петербург, 2002. — 372 с.: ил.
Г63 ISBN 5-8206-0105-Х
Конвергенция сетей и услуг связи в значительной степени основывается на технологиях компьютерной телефонии 3-го поколения. Рассматриваемые в книге достижения этой бурно развивающейся индустрии реализуются сегодня в Call-центрах и приходящих им на смену Web-контакт- центрах, в разнообразных узлах услуг (Service Nodes), в различных системах и средствах организации новых инфокоммуникационных видов обслуживания.
Для инженеров и бизнесменов, для программистов и менеджеров, для всех специалистов, занятых организацией, разработкой и эксплуатацией систем и средств компьютерной телефонии и Call-центров. Для студентов и аспирантов соответствующих специальностей. Для всех, кого интересуют современные технологии инфокоммуникаций.
Научно-техническое издание
ISBN 5-8206-0105-Х
© Гольдштейн Б.С., Фрейнкман В.А., 2002
B.S. Goldstein, V_A_ Freinkman
Call-centers and Computer telephony, Saint-Petersburg, BHV - Saint-Petersburg, 2002.
The convergence of telecommunication networks and services is based considerably on the third generation computer telephony technologies. The achievements of this rapidly developing industry considered in the book are implemented today in call centers and Web enabled contact centers coming up to take their place, in various Service Nodes and other systems and means for the provision of new infocommunications services.
The book is primarily intended for engineers, businessmen, programmers, managers, and all specialists involved in the management, development, and operation of computer telephony systems and call centers. It will be a valuable reference source for students and post-graduates studying in these areas. It will be helpful for all those who are interested in state-of-the-art infocommunications technologies.
Scientific and technicaf edition
Copyright © B.S. Goldstein, V.A. Freinkman, 2002
Содержание
Предисловие9
Основы компьютерной телефонии11
Что такое компьютерная телефония? 11
CTI или СТ? 22
CTI и Интеллектуальная сеть 25
Конвергенция телекоммуникационных услуг и IP-услуг32
Call-центры и речевые порталы 34
Исторические предпосылки37
История телефона37
История компьютера41
История компьютерной телефонии 62
Стандартизация75
Стандартизация компьютерной телефонии75
Этапы стандартизации78
Рекомендации ITU-T 80
Стандарты ISO 84
Стандарты ETSI 84
Структура ЕСМА 86
Американский институт стандартов ANSI 88
Консорциум мультимедиа и телеконференций IMTC 88
Конференции OpenSig and OpenArch и рабочая группа IEEE Р1520 88
Международный консорциум Softswitch 90
Форум MSF 90
Консорциум Parlay Group91
Еще раз о TAPI, TSAPI и JTAPI 93
Услуги компьютерной телефонии101
IVR и аудиотекс 101
Основы IVR 101
Аудиотекс 104
Меню 105
Системы оповещения 109
Запись переговоров 109
Речевая почта 110
Офисные системы 110
Алгоритмы речевойпочты 111
Речевая почта в ТфОП 117
Психологический аспект 119
Факс-серверы 119
Унифицированный обмен сообщениями 120
Предпосылки 121
Функциональные возможности 122
Архитектура 127
Стандартизация 129
Проблемы и перспективы 136
Телеголосование 137
Предоплаченные услуги связи 141
Принципы начисления платы за услуги связи 141
Предоплаченные услуги связи 143
Предоплаченные услуги на рынке мобильной связи 146
Привлекательность предоплаченных услуг связи 148
Функциональные возможности системы обработки СТК 150
Обслуживание вызова 150
Функциональный блок подготовки счетов 153
Блок маршрутизации и начисления платы 153
Присвоение прав доступам назначение категорий карт.... 154
Настройка параметров обслуживания вызовов 155
Доступ к статистической информации 156
Применение СТК в ТфОП. Процессинговые центры 157
Дополнительные услуги с помощью СТК 161
Ступени распределения вызовов 167
Основные понятия 167
Опыт ВСС России 171
Функциональные возможности СРВ 179
Маршрутизация и обработка вызовов 180
Дисциплины очередей и алгоритмы обслуживания вызовов 181
Операторы в системе 183
Статистика и учет вызовов 186
Системы отчетности и управления операторским центром 187
Архитектура и перспективы эволюции СРВ 188
Call-центры 191
От СРВ к Call-центрам 191
Исходящие вызовы 194
Call-центры смешанного типа 197
Варианты реализации Call-центров 199
Definity 199
Call-центр NEAX 2400/7400 205
Call-центр ПРОТЕЙ 207
Решение Nortel Networks 211
Аутсорсинг при организации Call-центров 214
Многофункциональный центр обслуживания вызовов 219
Контакт-центры225
Конвергенция и операторские центры 225
Функциональные особенности контакт-центра 232
Доступ к услугам контакт-центра 233
Организация очередей и маршрутизация вызовов 239
Безопасность 244
Клиентская база данных 247
Архитектура контакт-центра 247
Два архитектурных стиля 247
Шлюз IP-телефонии 252
Серверы приложений 252
Базы данных 253
Сервер эксплуатационного управления 253
Рабочие места операторов 254
PROXY-сервер для доступа из Интернет 255
Оборудование пользователя 255
Административное управление работой контакт-центра 256
Алгоритмическое обеспечение263
Общие положения 263
Управление обслуживанием вызова 264
Управление телефонными устройствами 265
Управление медиа-ресурсами 265
Протокол CTSA 267
Модель обслуживания вызовов SCAI 271
Интерфейс TASC 274
Архитектура CTI по ECTF и интерфейс С.001 274
Структура сервера ECTF 276
Конфигурации сервера 276
Базовая конфигурация сервера 278
Интеграция процессов управления обслуживанием вызова 279
Модель управления обслуживанием вызова С.001 283
Базовая модель обслуживания вызова в спецификациях ECTF 283
Концепция медиа-услуг 284
Модель обработки информации 285
Устройства маршрутизации и медиа-доступа 287
Общее описание взаимодействия приложение - сервер 288
Группа и ресурсы 289
Протокол Parlay API 297
Интерфейсы структур 297
Интерфейсы услуг 298
Интерфейсы управления ресурсами 299
Архитектура Parlay API 299
Интерфейсы JAIN 301
Программное обеспечение303
Основные компоненты программного обеспечения 303
ПО обработки медиа-потоков 309
ПО обработки сигнализации 311
Программное обеспечение API 316
Программирование 7API 316
Программирование TSAPI 323
ПО интеллектуальной платформыПРОТЕЙ 326
Архитектура ПО 326
Библиотека АГЕ 328
Структура ПО шлюза IP-телефонии 329
Модуль пакетирования речи 330
Модуль обработки телефонной сигнализации 331
Модуль сигнализации Н.323 332
Модуль логики услуг шлюза IP-телефонии 332
ПО пользовательского интерфейса 333
Аппаратное обеспечение337
Компьютеры 337
Шина ISA 340
Шина EISA 341
Шина VESA 341
Шина PCI 342
Промышленные компьютеры 344
Compact-PCI 344
Компьютеры с пассивной объединительной платой 347
Процессоры 348
Контроллеры внешних устройств 348
Изобретение DSP 349
Функции плат компьютерной телефонии 354
Запись и воспроизведение речевой информации 354
Распознавание речи 356
Обработка межстанционной и абонентской сигнализации 358
Прием цифр номера 360
Инициирование вызова 360
Реализация плат компьютерной телефонии 361
Список литературы369
Предисловие
彌金3三;7茎盡等^鑫
Телепортация - вот, пожалуй, единственная телекоммуникационная услуга, не реализованная к настоящему времени, хотя и над ней, по всей вероятности, работают ученые. В остальном же разработчики продолжают выдумывать всё новые и новые удивительные телекоммуникационные услуги, призванные удовлетворить поистине ненасытное желание людей иметь связь и получать информацию мгновенно, повсеместно и в самых различных формах: аудио, данные, видео, мультимедиа (а в недалеком будущем - запахов, осязательной информации). Все эти услуги требуют очень высоких технологий, среди которых в начале XXI века достойное место заняли Call-центры и оборудование компьютерной телефонии третьего поколения.
Не только извечная тяга к знаниям, но и весьма прозаические экономические резоны стимулировали их развитие. На мировом телекоммуникационном рынке ярко проявилось то, что темпы роста доходов, получаемых от предоставления дополнительных инфокоммуникацион- ных услуг существенно превышают темпы роста доходов от традиционных услуг - собственно обеспечения коммутируемых соединений. Несомненно, что современный оператор - поставщик услуг не только должен быть способен предложить широкий спектр специализированных услуг; ориентированных на удовлетворение потребностей отдельных групп пользователей, но и уметь быстро и при разумных затратах внедрять новые виды услуг. Рассматриваемые в книге технологии дают ему эти возможности.
Они, кстати, уже хорошо известны в России. Как операторами стационарной телефонной сети общего пользования (служба 09 или бюро ремонта, например), так и операторами мобильной связи и другими компаниями предлагаются разнообразные услуги Call-центров и компьютерной телефонии третьего поколения. Компьютеры уже умеют принимать и сортировать телефонные вызовы, производить оповещение абонентов, предоставлять абонентам доступ к базам данных, выдавать информацию о расписании поездов или самолетов, о наличии билетов или товаров на складах и в магазинах и т.п. Кроме того, компьютерная телефония -это сервисные телефонные карты, интегрированный корпоративный офис, запись телефонных переговоров и многое, многое другое.
Приложения компьютерной телефонии исторически были сосредоточены в центрах обработки вызовов (Call-центрах), сначала ориентированных только на распределение входящих вызовов (СРВ), а затем обслуживающих как входящую, так и исходящую нагрузку. Следующим шагом этой эволюции стала обработка электронной почты, сообщений
в чатах, факсимильных запросов и т.п., что привело, в частности, к постепенной замене терминов: от СРВ к Call-центру, от Call-центра к Контакт-центру, или даже к Web-контакт-центру.
На этом пути разработчики телекоммуникационных услуг пережили период, характерный и для многих других отраслей в 80-х годах прошлого столетия, - период чрезмерного очарования безграничными возможностями компьютеров, приведший, кстати говоря, к концепции Интеллектуальной сети, не предусматривающей участие «живых» операторов ни в одной из услуг списков CS1, CS2 и др. Разные аспекты этой концепции будут неоднократно упоминаться на страницах этой книги, а более глубокому ее изучению посвящена монография [3], которая может быть рекомендована читателям, интересующимся современными телекоммуникационными услугами.
Не избежали подобного увлечения и разработчики компьютерной телефонии и Call-центров, речевая почта и автоматические операторы которых явно злоупотребляли и продолжаютзлоупотреблять возможностями современных сверхмощных компьютеров, новейших алгоритмов распознавания речи, программного обеспечения на жестких дисках, которые практически не ограничивают его объем, и рассмотренными в последней главе книги новыми DSP, что, в совокупности, может сделать реальностью следующий телефонный разговор человека с Call-центром:
Компьютер: «Спасибо, что вы обратились в нашу справочную службу. Так как все операторы сейчас заняты, прослушайте рекламную информацию ...»
Человек: «Заткнись и сообщи мне телефон...»
Компьютер: «Тогда позвоните позже, когда у нас появятся свободные операторы, а вы научитесь приличным манерам».
О том, как это реализуется, говорится в главах 9, 10 и 11 данной книги (всего их, по традиции, -11), посвященных алгоритмическому, программному и аппаратному обеспечению Call-центров и компьютерной телефонии, соответственно. Очень хотелось бы, чтобы читатель добрался до этих последних трех глав, адресованных всем, кто работает в области сегодняшних инфотелекоммуникаций. Самим же Call-центрам посвящены главы 6,7 и8, содержание которых по важности и актуальности на самом деле заслуживает отдельной книги. В предшествующих главах рассматриваются основные услуги и технологии компьютерной телефонии третьего поколения, исторические аспекты, вопросы стандартизации, вопросы терминологии и, что самое важное, концептуальные вопросы организации инфокоммуникационных услуг в мультисер- висных сетях следующего поколения.
Авторы считают своим долгом высказать признательность А.В. Пинчуку, О.И. Пигоревой, Д.А. Потапову, А.А. Зарубину, В.В. Саморезову и другим коллегам, занимающимся разработками в рассматриваемых в кнм「е областях и оказавшим авторам существенную помощь в подготовке рукописи, а также отметить неоценимую помощь В.А.Соколова в редактировании книги, хотя ему и не удалось полностью решить терминологические проблемы, о которых будет сказано в главе 1. Так или иначе, но все просчеты (не только терминологические) остаются на совести авторов, которые готовы принять замечания, впечатления и пожелания читателей по электронной почте riio1@loniis.「u.