Современная платформа IVR: архитектура и функциональность.

Введение

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

Суть  задачи

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

Стандартная IVR платформа предоставляет следующие возможности:

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

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

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

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

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

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

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

1. Многоуровневой см. Рисунок 1. Уровни должны взаимодействовать друг с другом с помощью абстрактных, четко определенных и минимизированных интерфейсов. Это необходимо для того, чтобы у разработчика в дальнейшем была возможность быстрого изменения уровня, не затрагивая другие. Например, для поддержки телефонного оборудования нового производителя.
2. Каждый уровень должен состоять из заменяемых функциональных подсистем. На Рисунке 2 представлены подсистемы и их взаимодействие на “уровне бизнес логики”. Такая архитектура обеспечит защиту IVR от остановки, в случае если какая-то подсистема вышла из строя. В этом случае IVR потеряет часть функциональности, но остается работоспособной системой. При сбое в какой-либо подсистеме IVR должен информировать оставшимися доступными средствами администратора о проблеме. Также такая организация позволяет наращивать функциональность IVR платформы добавлением новых подсистем на соответствующие уровни, не затрагивая другие.
3. Необходимо обеспечить достаточный уровень дублирования серверов или даже иметь возможность “горячего дублирования”. При “горячем дублировании” в случае выхода из строя одного сервера, резервный автоматически обработает все активные звонки без разрыва соединения и потери информации.

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

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

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

На “уровне приложений” предоставляется следующая функциональность:

1. Возможность для заказчика самостоятельно менять структуру меню и бизнес логику. Хотя, несмотря на такую возможность, заказчик, как правило, обращается за доработкой к разработчикам IVR. Но эта функциональность не будет лишней, т.к. позволит подразделению, отвечающему за внедрение и сопровождение, самостоятельно делать необходимые доработки.
2. Возможность для голосовых приложений динамически распределять необходимое число физических телефонных ресурсов. Например, когда необходимо обзвонить абонентов, IVR должен предоставить автопрозвонщику необходимые ресурсы за счет уменьшения ресурсов у других приложений, но так, чтобы не блокировать их функционирование.
3. IVR должен составлять фразы из голосовых фрагментов на правильном русском языке, чем иногда пренебрегают некоторые производители. Правильность составления фраз приобретает особое значение, если IVR поддерживает несколько языков. Для согласования текстов лучше  пригласить носителя языка, т.к. ошибки в правилах произношения сразу вызывают недоверие абонентов ко всей системе.

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

На “уровне бизнес логики” правильная платформа предоставляет следующую функциональность:

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

Подсистемы “структура меню” и “бизнес логика” рассматриваются далее в разделе “Реализация IVR платформы”.

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

На “уровне абстракции телефонного оборудования” необходимы следующие возможности:

1. IVR должен иметь такой интерфейс “уровня абстракции оборудования”, чтобы уметь использовать любую телефонную технологию. Реальность такова, что сами телефонные протоколы могут значительно различаться по своей функциональности и способам установки соединения. Примером могут служить цифровые протоколы ISDN и протоколы IP телефонии.
2. Увеличение производительности IVR должно достигаться за счет модернизации аппаратной части системы. При росте числа абонентов или при появлении новых голосовых приложений нагрузка на IVR возрастает. IVR не должен требовать доработки программной части для поддержки горизонтального масштабирования за счет увеличения числа телефонных плат и/или транков на них. Необходимость в наращивании производительности определяется эмпирическим путем, а именно исследуется структура звонков у конкретного оператора связи на конкретную услугу. На Рисунке 3 представлено суточное распределение звонков у оператора мобильной связи на автоинформатр на один ISDN PRI транк (30 каналов) в минуту. На графике хорошо видны часы наибольшей нагрузки (ЧНН). В эти часы  необходимо сделать статистически значимое число попыток  дозвонится на IVR, и если хотя бы одна из них будет неудачной по причине занятости линии, то необходимо расширение оборудования. т.к. непредоставление услуги вызывает нарекания абонентов к оператору связи.
3. Ограничение длительности звонка обычно происходит на коммутаторе и составляет около часа. Если такая функциональность отсутствует, то IVR должен со своей стороны ограничить длительность вызова. Это избавит от проблемы, когда PBX не определяет разрыв соединения и звонок остается активным несмотря на то, что абонент повесил трубку. Подобная ситуация может возникнуть, когда звонок производится с аналоговых городских линий.
4. Возможность связи абонента с оператором для решения вопросов, которые абонент не хочет или не может решить с помощью IVR. Это требование предполагает наличие в IVR перенаправления (трансфера) вызова. Данная функциональность может быть реализована несколькими способами: использовать трансфер,  специфичный для  конкретной телефонной станции (PBX Private Branch eXchange), использовать стандартные типы трансфера, использовать ресурсы самой телефонной платы. Данные решения предполагают различную степень интеграции с конкретной PBX и перечислены согласно убыванию данной зависимости. При использовании специфичной функциональности PBX или телефонной платы возникает зависимость реализации от железа, что осложняет переносимость системы. В IVR платформе необходимо минимизировать интерфейс “уровня абстракции оборудования”, что вынудит использовать в IVR только необходимые телефонные функции. В реализации интерфейса необходимо использовать только стандартные функции телефонных протоколов и обработки голоса. Это снизит риск использования специфичных возможностей телефонного оборудования.

Реализация 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 Peer). Соответственно, IVR должен предоставить гибкий механизм для решения этой задачи.

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

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

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

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

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

Заключение

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

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

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

Рисунок 3. Звонков в минуту на 30 каналов.

Алексей Сушков

Старший инженер-программист

группы “Телеком” отдела новых технологий

ЗАО “ПЕТЕР-СЕРВИС”                       

E-mail: Alexey.Sushkov@billing.ru

URL: http://www.billing.ru

Март 2005 года