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

Перспективы использования стандартной IVR-платформы определяются ее функциональностью, в частности:

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

Современная IVR-платформа, помимо перечисленных, должна обладать следующими достоинствами:

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

Грамотно спроектированная IVR-платформа в дальнейшем будет требовать от разработчика минимальных усилий по:

• разработке новых голосовых приложений;
• поддержке новых источников данных и протоколов;
• переходу на новое телефонное оборудование.

Архитектура IVR-платформы

Архитектура IVR-платформы должна удовлетворять следующим требованиям:

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

Рис. 1. Многоуровневая архитектура IVR

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

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

Рис. 2. Уровень бизнес-логики IVR

Что такое IVR?

Под IVR подразумеваются системы компьютерной телефонии, которыми абонент управляет с помощью тонального набора на телефоне или голосом, а система предоставляет необходимую информацию, используя заранее записанные голосовые фрагменты или систему синтеза речи TTS (Text-To-Speach). Примерами IVR являются такие голосовые приложения, как: автоинформатор, автопрозвонщик, голосовая почта (Voice Mail), универсальная почта (Unified Messaging), центры обработки вызовов (Call-Center), системы записи переговоров, телеголосование.

Требования к функциональности

Рассмотрим более подробно необходимую для современного IVR функциональность по уровням.

Уровень приложений

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

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

3. Составление фраз из голосовых фрагментов на правильном русском языке, особенно если IVR поддерживает несколько языков. Для согласования текстов целесообразно пригласить носителя языка, так как ошибки в произношении вызывают недоверие абонентов ко всей системе.

Уровень бизнес-логики

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

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

3. Возможность без прерывания обслуживания абонентов изменения структуры меню, бизнес-логики и настройки параметров системы.

Уровень абстракции телефонного оборудования

1. Наличие интерфейса "уровня абстракции оборудования", обеспечивающего использование любой телефонной технологии, так как телефонные протоколы могут существенно различаться по функциональности и способам установки соединения (например, цифровые протоколы ISDN и протоколы 1Р-телефонии).

2. Повышение производительности IVR за счет модернизации аппаратной части системы. При увеличении количества абонентов или появлении новых голосовых приложений нагрузка на IVR возрастает, который при этом не должен требовать доработки программной части для поддержки горизонтального масштабирования за счет увеличения числа телефонных плат и/или транков на них. Необходимость в наращивании производительности определяется эмпирическим путем - исследуется структура звонков у конкретного оператора связи на конкретную услугу. На рис. 3 представлено суточное распределение звонков у оператора мобильной связи на автоинформатор на один ISDN PRI транк (30 каналов) в минуту. В часы наибольшей нагрузки (ЧНН) необходимо предпринять статистически значимое количество попыток дозвониться на IVR, и если хотя бы одна из них будет неудачной по причине занятости линии, то необходимо расширение оборудования, так как непредоставление услуги вызывает нарекания абонентов к оператору связи.

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

4. Связь с оператором для решения вопросов, которые абонент не хочет или не может решить с помощью IVR. Это требует наличия в IVR перенаправления (трансфера) вызова. Данная функциональность может быть реализована использованием: трансфера, специфичного для конкретной телефонной станции {РВХ Private Branch eХchange); стан- дартных типов трансфера; ресурсов самой телефонной платы. Эти решения обусловливают различные степени интеграции с конкретной РВХ и перечислены согласно убыванию данной зависимости. При использовании специфичной функциональности РВХ или телефонной платы возникает зависимость реализации от "железа", что осложняет перено- симость системы. В IVR-платформе необходимо минимизировать интерфейс "уровня абстракции оборудования" и, как следствие, использовать в ней только стандартные функции телефонных протоколов и обработки голоса.

Рис. 3. Суточное распределение звонков на 30 каналов в минуту

Реализация IVR-платформы

Структура меню

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

IVR, управляемый тоновым набором, изначально является иерархическим приложением. В приложениях, использующих системы ASR (Automatic Speech Recognition) и управляемые голосом, меню может быть "плоским", т. е. абоненту не нужно последовательно осуществлять тоновый набор, чтобы добраться до нужного пункта меню, а достаточно сказать, что он хочет, и IVR по ключевым словам поймет его. За основу для создания меню необходимо взять открытое средство, имеющее иерархическую структуру. На сегодняшний день лучший выбор - стандарт XML, который обладает следующими возможностями:

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

Бизнес-логика

Для получения необходимой информации IVR может обращаться к различным источникам данных, используя разнообразные протоколы и языки доступа: SQL, HTTP, TCP, протокол сетевого администрирования - SNMP (Simple Network Management Protocol), протокол электронной почты - SMTP (Simple Mail Transfer Protocol), протокол для доступа к SMS/USSD центрам - SMPP (Short Message Peer-to-Реег). Следовательно, для выполнения этой задачи IVR должен предоставить гибкий механизм.

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

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

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

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

Многоплатформенность

IVR поддерживает многоплатформенность (работает на разных операционных системах). С этой целью при разработке платформы необходимо придерживаться ANSI стандарта C++ и не использовать функции, зависимые от конкретной операционной системы. Для реализации системных вызовов применяются многоплатформенные библиотеки.

***

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