|
Название модуля
|
res_speech
|
ASR
|
|
Платформа IP-телефонии
|
Asterisk
|
FreeSWITCH
|
|
Функция
распознавания речи.
|
+
|
+
|
|
Лицензирование
модуля
|
GPL
|
GPL
|
|
Конвертация
речи в текстовый формат.
|
-
|
+
|
|
Грамматическая
проверка сообщения.
|
+
|
-
|
|
Наличие полноценной
документации.
|
-
|
-
|
|
Наличие
бизнес-логики.
|
-
|
-
|
Существующие модули помогают распознать речевой сигнал в
процессе соединения, но не имеют функции ответа по результатам распознавания,
что говорит об отсутствии у модулей свойства интерактивности. Эту проблему
должен решить Asterisk-модуль sip_response, основная задача
которого - обеспечить полноценный диалог с клиентом любой целевой организации с
минимальным вмешательством работников этой организации. Автоматизация подобного
рода позволяет достичь главной цели бизнеса - максимизации прибыли при
минимизации издержек.
Выводы по
разделу
Основной целью данного раздела являлся описание системы IP-телефонии как предметной
области данной работы. В рамках данного раздела описана постановка задачи,
подкрепленная перечнем проанализированных требований к разрабатываемому
программному продукту. Далее сделан анализ предметной области с целью введения
потенциальных заказчиков в домен работы модуля sip_response. В заключение проведен
анализ как платформ IP-телефонии с целью осознанного выбора базовой
платформы для разработки, так и аналогичных модулей - конкурентов модуля sip_response, умеющих распознавать
речь с помощью протокола.
2.
Проектирование информационной системы
На стадии проектирования информационная система обретает
собственный облик, отличный от других систем. Именно на этом этапе происходит
формирование логики работы программного продукта перед дальнейшим переносом в
исходный код.
В данном разделе ВКР описана основная концепция системы,
выделена идея, которая отображена в формате UML-диаграмм. Далее в
разделе приведено описание проектирования хранилища данных, состоящего из двух
баз данных - БД приложения sip_response и БД клиентов организации (в данном
случае банка).
2.1
Разработка UML-диаграмм
2.1.1
Разработка моделей AS-IS
Модель AS-IS - модель существующего состояния организации (в
переводе с английского означает "как есть"). Данная модель позволяет
систематизировать протекающие в данный момент процессы, а также используемые
информационные объекты. На основе этого выявляются узкие места в организации и
взаимодействии бизнес-процессов, определяется необходимость тех или иных
изменения в существующей структуре. Такую модель часто называют функциональной
и выполняют с использованием различных графических нотаций и case-средств. На этапе
построения модели AS-IS важным считается строить максимально
приближенную к действительности модель, основанную на реальных потоках
процессов, а не на их идеализированном представлении.
В разработанном комплексе диаграмм UML в качестве моделей AS-IS воспринята та модель
процессов организации, которая существовала до начала использования модуля IP-телефонии sip_response. Модель AS-IS описана в виде диаграммы
вариантов использования, показанной на рисунке 2.2.1 Данная диаграмма
показывает следующий подход к обработке запросов клиентов. В любом случае в
любой момент времени на запрос отвечает оператор первой линии технической
поддержки. Перенаправление на рабочую станцию оператора осуществляет диалплан
сконфигурированной системы Asterisk. После консультации и удовлетворения потребности
пользователя в информации вызов завершается. Однако даже после вызова
происходит рутинная работа со стороны оператора. Оператор протоколирует
сведения о вызове через специальное приложение для работы с базой данных
организации.
Рисунок 2.2.1 - диаграмма вариантов использования (use-case) до внедрения модуля sip_response
Данный подход к клиентскому обслуживанию имеет существенные
недостатки. В первую очередь, неэффективное использование ресурсов оператора в
принципе. В данной модели человек должен ответить на любой запрос, даже тот,
ответ на который может быть сгенерирован автоматически (например, расписание
поездов или баланс на счете клиента). Во-вторых, наличие дополнительных
издержек в финансовом плане организации, связанных с содержанием
многочисленного штаба операторов call-центра, закупкой и поддержкой
оборудования, используемого операторами (компьютеры, телефоны). Реализация
модуля sip_response в бизнес-процессах организации позволит
избавиться от этих проблем.
2.1.2
Разработка моделей TO-BE
Проектирование информационных систем и управление процессами
подразумевает построение модели AS-IS и дальнейший переход к
модели TO-BE, что является залогом автоматизации
"правильных", усовершенствованных процессов.
TO-BE - модель "как
должно быть". Как правило, данная модель создается на основе AS-IS, с устранением
недостатков в существующей организации бизнес-процессов, а также с их
совершенствованием и оптимизацией. Это достигается за счет устранения
выявленных на базе анализа AS-IS узких мест. В традиционном реинжиниринге именно
на основе модели TO-BE рекомендуется производить автоматизацию
бизнес-процессов и проектировать информационные системы. Подразумевается, что
это позволяет существенно снизить риск проявления автоматизации как
исключительно источника затрат из-за автоматизации несовершенных процессов.
В разработанном комплексе диаграмм UML в качестве моделей TO-BE можно представить
следующие виды диаграмм:
1) диаграмма вариантов использования;
2) диаграмма деятельности;
3) диаграмма состояний;
4) диаграмма развертывания;
5) диаграмма последовательности;
6) диаграмма компонентов;
7) диаграмма классов.
2.1.2.1
Диаграмма вариантов использования (use-case diagram)
Диаграмма вариантов использования - диаграмма, на которой
изображаются отношения между актерами и вариантами использования.
Полный вариант диаграммы вариантов использования показан в
приложении А. Основными компонентами данной диаграммы являются актеры и
варианты использования.
Диаграмма включает в себя следующих актеров:
) пользователь системы - главный актер в системе,
который передает запрос и принимает ответ на него, а также может в любой момент
прервать соединение;
2) диалплан IP-телефонии - механизм управления модулем sip_response от лица системы IP-телефонии Asterisk; подтверждает завершение
вызова и выводит сообщение клиенту системы;
) специалист технической поддержки - принимает
пользовательский запрос и отвечает на него вместо автоматизированной системы, у
которой недостаточно данных для самостоятельного ответа.
Диаграмма включает в себя следующие варианты использования:
) запрос в службу технической поддержки организации;
2) формирование ответа на запрос (включает в себя
процесс запроса в службу поддержки, а также подпроцессы преобразования
сообщения в текстовый формат, проверку контекста запроса и аутентификацию
пользователя);
) вывод сгенерированной фразы (включает в себя
процессы формирования ответа на запрос и самого факта запроса в службу
технической поддержки, а также подпроцесс преобразования сообщения из
текстового формата в речевой);
) завершение вызова (включает запись информации о
вызове в базу данных);
) перенаправление вызова специалисту центра
технической поддержки.
Подводя итоги данного анализа, можно отметить, что
проектируемая система позволит решить проблемы и искоренить недостатки
бизнес-процессов традиционной модели call-центра организации.
2.1.2.2
Диаграмма деятельности (activity diagram)
Диаграммы деятельности - частный случай диаграмм состояний.
Они позволяют реализовать в языке UML особенности процедурного и синхронного
управления, обусловленного завершением внутренних действий и деятельности.
Диаграмму деятельности можно увидеть в приложении А. Данная UML-модель показывает
концепцию модуля sip_response как структуру, совершающую определенное действие
в определенный момент времени. Диаграмма имеет несколько видов деятельности,
процессы которых разделены на несколько подсистем:
) Диалплан IP-телефонии - данная подсистема воспроизводит
пользователю стартовый вопрос, ответ на пользовательский запрос,
сгенерированный модулем sip_response, перенаправляет вызов в центр технической
поддержки, а также обрабатывает процесс завершения вызова;
2) Модуль распознавания речи - данная подсистема в
качестве основной задачи имеет процесс преобразование пользовательского запроса
из речевого формата в текстовый посредством запросов к API внешней системы
распознавания речи Google Speech;
) Модуль контроля вызова - данный модуль обрабатывает
множество условий, от которых зависит результат ответа на пользовательский
запрос и запускает процессы формирования ответа на запрос, аутентификации
пользователя, а также записи в базу данных;
) Интерфейс БД - данная подсистема отправляет запросы
к базам данных, полученные от модуля контроля вызова, и передает их в
окончательном итоге;
) Хранилище данных - под хранилищем данных
представлены 2 базы данных - БД организации-клиента и БД модуля sip_response, из которых считывается
информация подсистемами модуля sip_response.
2.1.2.3
Диаграмма состояний (state diagram)
Диаграмма состояний показывает, как объект переходит из
одного состояния в другое. Диаграммы такого вида служат для моделирования
динамических аспектов системы.
Диаграмму состояния, разработанную в ходе выполнения ВКР,
можно увидеть в приложении А. Характерными чертами модуля sip_response, которые ярко выражены в
данной модели, являются контролируемая цикличность, и взаимосвязь компонентов и
операций используемых подсистем.
В качестве точки входа в диаграмме показан процесс
пользовательского запроса в систему IP-телефонии. Первым шагом
работы модуля sip_response является прием ссылки на аудиофайл с записанным клиентским
вызовом от диалплана IP-телефонии. В свою очередь, диалплан получает
пользовательский вызов через Интернет-соединение.
Данная диаграмма показывает следующие состояния работы модуля
sip_response:
) преобразование ответа в текстовый формат - голосовое
сообщение пользователя преобразуется в текстовый формат, при этом текст
хранится в файле;
2) аутентификация пользователя - после обработки
клиентского запроса происходит процесс подтверждения личности пользователя на
основании данных, которые пользователь сообщил системе;
) формирование ответа на клиентский запрос - после
подтверждения личности пользователя система генерирует полноценный ответ на
запрос на основании найденного запроса и данных из клиентской БД;
) преобразование ответа в речевой формат -
сформированный текст запроса преобразуется в голосовое сообщение с помощью
запроса к системе обработки речевых сигналов;
) вывод голосового сообщения - диалплан воспроизводит
пользователю сформированное голосовое сообщение, ожидая его ответ;
) соединение со специалистом - система может перейти в
данное состояние только в том случае, если система не нашла запрос,
удовлетворяющий потребностям клиента; в таком случае происходит ручная
обработка запроса специалистом центра технической поддержки;
) завершение соединения - система может перейти в
данное состояние в любой момент времени, когда пользователь повесил трубку, тем
самым разорвав соединение с системой; на данном этапе происходит обработка
данных о вызове и запись сформированной информации в базу данных.
В качестве точки выхода система имеет процесс разрыва
соединения с абонентом. В таком случае для повторного вызова пользователь будет
вынужден начать с нового запроса, перейдя на точку входа состояний системы.
Также в диаграмме показано хранилище данных в виде БД модуля sip_response, в которую записывается
информация о соединениях, обработанных модулем sip_response.
2.1.2.4
Диаграмма развертывания (deployment diagram)
Диаграмма развертывания - диаграмма, на которой представлены
узлы выполнения программных компонентов реального времени, а также процессов и
объектов.
Диаграмму развертывания, разработанную в ходе выполнения ВКР,
можно увидеть в приложении А. В диаграмме наиболее пристальное внимание
уделяется отображению концепции модуля sip_response как комплекса
аппаратного и программного обеспечения. Данная модель описывает все шаги,
которые проходит вызов пользователя и его последующий запрос, для обеспечения
корректной и полнофункциональной работы модуля.
Список компонентов, показанных на диаграмме развертывания:
) телефон пользователя, с которого пользователь
совершает вызов в систему;
2) банк каналов - инструмент преобразования аналогового
сигнала, полученного от линии АТС, в сетевые пакеты, которые впоследствии
передаются по IP-сети;
) физический сервер - представление вычислительной
машины, на которой происходят все операции по обработке вызова;
) операционная система - ПО абстракции
пользовательских программ от особенностей и спецификаций аппаратного
обеспечения на машине;
) система IP-телефонии - ПО, обрабатывающее пользовательские
запросы;
) модуль IP-телефонии sip_response - объект проектирования
данной работы;
) СУБД PostgreSQL - система, которая
управляет базами данных, используемыми в процессе работы модуля sip_response;
) телефон специалиста - устройство, на которое система
IP-телефонии перенаправляет
запрос в том случае, если модуль sip_response его не может обработать;
) рабочая станция специалиста - место обработки
пользовательского запроса оператором центра технической поддержки. Под рабочей
станцией подразумевается офис технической поддержки.
2.1.2.5
Диаграмма последовательности (sequence diagram)
Диаграмма последовательности относится к диаграммам,
описывающим поведенческие аспекты системы, при этом рассматривая взаимодействие
объектов во времени.
В рамках данной выпускной квалификационной работы
спроектированы две диаграммы последовательности. Диаграмма
последовательности, описывающая обработку клиентского запроса, показана на
рисунке 2.1.2.5.1.
Рисунок 2.1.2.5.1 - диаграмма последовательности обработки
клиентского запроса
Данная диаграмма описывает обработку запроса модулем IP-телефонии sip_response в состоянии, когда
запрос обработан успешно. В данном случае сам запрос не является чрезвычайно
сложным для модуля и соединение с клиентом не разорвано. Каждый компонент схемы
(клиент как актер, подсистемы модуля как activity-классы) выполняет
определенную операцию, результатом которой является перенос управления работой
информационной системы к другому компоненту.
Исключение составляет процедура аутентификации, где вместо
перехода работы модуля на следующий этап происходит дополнительная проверка
пользовательских данных в рамках того же самого компонента. Работа модуля
показывается в виде непрерывной последовательности операций.
Диаграмма последовательности процесса обработки разрыва
соединения показана на рисунке 2.1.2.5.2.
Рисунок 2.1.2.5.2 - диаграмма последовательности процесса
обработки разрыва соединения
Данная диаграмма описывает последовательность действий модуля
после завершения соединения с клиентом и обработки клиентского запроса в
частности. Задачей совместной работы структурных компонентов диаграммы является
запись в БД модуля sip_response информации о соединении (дата начала и
окончания, текст запроса, факт успешной обработки запроса системой, факт
перенаправления запроса в центр поддержки):
) диалплан вызывает подсистему контроля вызова через
основную подсистему для записи информации о вызове в базу данных;
2) подсистема контроля вызова фиксирует данные
соединения с пользователем и отправляет их в базу модуля sip_response через SQL-запрос;
) запрос проходит через интерфейс базы данных,
установивший соединение с СУБД PostgreSQL.
2.1.2.6
Диаграмма компонентов (component diagram)
Диаграмма компонентов описывает особенности физического
представления системы. Диаграмма компонентов позволяет определить архитектуру
разрабатываемой системы, установив зависимости между программными компонентами
проектируемой системы.
Диаграмму компонентов, можно увидеть в приложении А. На
диаграмме указаны следующие компоненты:
1) система IP-телефонии Asterisk;
2) диалплан как компонент системы IP-телефонии;
) модуль системы IP-телефонии sip_response (объект проектирования
данной выпускной квалификационной работы);
) подсистемы модуля sip_response (основная подсистема,
подсистема контроля вызова, интерфейс БД);
) клиентская БД, в которой хранятся сведения о
клиентах организации;
) БД модуля sip_response, в которой хранится
информация, необходимая для обработки пользовательского запроса;
) СУБД PostgreSQL, которая управляет доступом
к данным БД, перечисленных выше;
) хранилище аудиофайлов, представленное в виде
директории в файловой системе сервера;
) транскодер аудиофайлов, преобразующий аудиофайлы в
формат wav и gsm;
) система распознавания речи Google Speech.
Основные процессы взаимодействия между компонентами:
взаимодействие между пользователем и системой IP-телефонии (диалплан
записывает пользовательский запрос, отправляет его на обработку в модуль sip_response, и по окончанию
обработки отправляет пользователю, сгенерированный модулем ответ на запрос);
взаимодействие между основной подсистемой и подсистемой
обработки речевых сигналов (основная подсистема отправляет запрос на
преобразование пользовательского запроса из речевого формата в текстовый);
взаимодействие между подсистемой обработки речевых сигналов и
транскодером FFmpeg (транскодер преобразовывает аудиофайлы в форматы wav и gsm, отправляя ссылку на
сгенерированные файлы подсистеме обработки речевых сигналов);
взаимодействие между подсистемой обработки речевых сигналов и
системой распознавания речи Google Speech (подсистема обработки
речевых сигналов отправляет запрос на распознавание в Google Speech API через модуль Python SpeechRecognition и получает ответ в виде
текста, записывая его в файл);
взаимодействие между основной подсистемой и подсистемой
контроля вызовов (основная подсистема вызывает функции поиска запроса,
аутентификации и генерирования ответа на пользовательский запрос);
взаимодействие между подсистемой контроля вызовов и
интерфейсом БД (подсистема контроля вызова отправляет запрос на выборку или
вставку данных в базу через интерфейс);
взаимодействие между подсистемой контроля вызовов и
хранилищем аудиофайлов (подсистема контроля вызовов находит по абсолютному пути
к файлу необходимую фразу-шаблон и вставляет её в ответ пользователю);
взаимодействие между интерфейсом БД и базами данных
(интерфейс напрямую общается с клиентской БД и с БД модуля, отправляя SQL-запросы, полученные от
подсистемы контроля вызовов).
2.2
Проектирование модели хранилища информации
С точки зрения теории разработку модели хранилища информации
можно разделить на 5 стадий: выбора СУБД, формализации, графического
отображения, реализации и проверки корректности схемы БД. Перед началом
разработки модели рассмотрено встроенное хранилище данных системы IP-телефонии Asterisk - NoSQL базу данных BerkleyDB, которая данные в
формате ключ-значение. В ходе анализа сформулирована мысль о непригодности
данного формата хранения информации для нужд модуля sip_response, поэтому хранилище
информации разрабатывалось независимо от решения в системе Asterisk.
На стадии выбора РСУБД проведен анализ существующих решений
на рынке и выбор одной из рассматриваемых платформ. Выбор пал на реляционные
базы данных в виду всеобщей популярности данной модели хранилища, а также
простоте дальнейшей эксплуатации по сравнению с NoSQL-решениями, где в
процессе эксплуатации администратор должен преодолеть предварительный порог по
обучению работе с целевой базой данных.
Среди наиболее популярных РСУБД (PostgreSQL, MySQL,
SQLite, Firebird, Oracle, MS SQL) для
реализации хранилища информации выбрана платформа PostgreSQL. Выбор
сделан по той причине, что PostgreSQL является продуктом СПО, имеет
открытый исходный код, проста в эксплуатации небольших баз данных и имеет более
высокий темп развития по сравнению с аналогами.
На стадии формализации сформирована схема базы данных
встраиваемого модуля Asterisk sip_response, распределены данные
по таблицам в соответствии с теориями нормальных форм, выделены сущности,
атрибуты, ключи, связи между таблицами - компоненты, формирующие БД.
Стадия применения графических средств отображения модели
реализована инструментом визуального моделирования Sparx Enterprise
Architect посредством добавления таблиц, атрибутов, формирования первичных
и внешних ключей и визуализации конечной схемы БД.
Стадия реализации состояла заключалась в переносе структурной
схемы хранилища данных непосредственно в РСУБД посредством запуска
сгенерированного SQL-кода.
Стадия проверки заключалась в непрерывном тестировании использования
сущностей баз данных в процессе тестирования работы приложения. В ходе
тестирования обнаружены и исправлены несколько логических ошибок, допущенных в
ходе проектирования.
2.2.1
Выделение сущностей, атрибутов, ключей, связей
Сущность базы данных - это непосредственно сам элемент,
хранящийся в базе. Атрибут - название столбца в БД. Первичный ключ БД -
уникальное значение, по которому идентифицируется запись (строка) в таблице. В
правильно спроектированной таблице должен быть обязательно один первичный ключ.
Внешний ключ БД - атрибут, значения которого связаны со значениями первичного
ключа другой таблицы. С помощью внешнего ключа можно создать связи между
таблицами. Внешний ключ также может играть роль первичного ключа таблицы. Связи
в БД позволяют моделировать отношения между таблицами базы.
В процессе формализации предметной области БД созданы 2 базы
данных: клиентская база данных customers, содержащая необходимую
информацию о клиентах организации ООО "ПриветБанк" и база данных sip_response, в которой находится
информация, необходимая для контроля вызова модулем sip_response, в рамках которого
генерируется автоматизированный ответ на клиентский запрос.
Распределенная архитектура баз данных обеспечивает
мобильность БД, сокращение времени запросов и отсутствие избыточности в
элементах базы данных. Базы данных спроектированы в соответствии с теорией пяти
нормальных форм:
) значения всех атрибутов таблицы атомарны (неделимы);
) каждый неключевой атрибут функционально полно зависит от
первичного ключа таблицы;
) каждый неключевой атрибут нетранзитивно зависит от
первичного ключа (т.е. зависит только от первичного ключа, и больше ни от
одного другого атрибута);
) отсутствуют многозначные зависимости, не являющиеся
функциональными зависимостями;
) любая зависимость определяется только его возможными
ключами таблицы.
2.2.1.1
Проектирование клиентской базы данных
В рамках данной ВКР смоделирована БД организации, основным
назначением которой является хранение данных о пользователях услугами
организации и состоянии их учетной записи.
В данном случае спроектирована база данных ООО
"ПриветБанк". Всего в рамках проектируемой БД выделены 4 сущности:
клиенты банка, доступные программы банка, платежные транзакции, а также внешняя
информация о банке (такая, как курс обмена валют и новости). Дополнительно
спроектировано несколько связей "многие-ко-многим" в виде отдельных
таблиц. Всего база данных customers содержит 12 таблиц.
Статическая информация о клиентах банка находится в трех
таблицах: customers, customers_accounts и auth.
Таблица customers содержит уникальный ID клиентов банка, а также
их имена, фамилии, отчества и дату рождения.
Несмотря на создание уникальных атрибутов вместе с таблицей,
данные атрибуты будут храниться отдельно внутри последовательностей. Это
особенность СУБД PostgreSQL - хранить ID записи только тогда,
когда нужно разработчику.
Таблица customers_accounts содержит банковские
счета, прикрепленные к клиентам банка. В данном случае присутствует связь
"один ко многим", где связаны атрибут customer_id
таблицы customers_accounts и атрибут id таблицы customers.
Дополнительно каждый счет имеет свой уникальный ID, а также состояние
баланса на банковском счете.
Таблица auth содержит данные, необходимые для распознавания
личности. Кроме своих инициалов, в общении с модулем sip_response пользователь должен
назвать номер своей кредитной карты, CVV-код на обратной стороне
карты, а также код доступа к карте. Данные должны совпадать с значениями в
таблице auth, иначе в доступе к информации по запросу будет отказано.
Сущность финансовых транзакций описана в таблице transactions. Каждая финансовая
транзакция имеет собственный уникальный ID. Также в таблице записан
партнер транзакции (это может быть другой банковский счет, оператор сотовой
связи и т.д.), формат транзакции (cash-in, где баланс пополняется
или cash-out где баланс уменьшается) и сумма транзакции.
Сущность доступных в банке программ описана в таблицах credits, deposits и pension_programs. В данных трех таблицах
записана информация о доступных в банке кредитах, вкладах и пенсионных
программах. Также в таблицах хранятся недоступные, однако используемые
клиентами услуги. У каждой услуги есть собственный уникальный ID, название, описание,
процентная ставка и временной срок (если это кредит или вклад). Доступ к данным
подобного рода осуществляется в модуле sip_response без дополнительной
аутентификации.
Связи между клиентами банка и услугами, которыми они
пользуются описываются в БД customers как отдельные таблицы, где присутствуют связи
"многие-ко-многим". Данные связи олицетворяют 3 таблицы:
customers_credits, customers_deposits и customers_pensions. В данных таблицах
рассматриваются связи пользовательских ID и ID банковских услуг,
состояние баланса в рамках программы (например, оставшаяся сумма погашения
кредита или накопившаяся сумма по вкладу), а также срок окончания действия
услуги (если это не пенсионная программа).
Дополнительно БД customers также хранит данные,
доступ к которым может быть предоставлен без аутентификации. Информацией,
указанной в 2 таблицах news и exchange_rate, может воспользоваться
любой полноправный гражданин, даже если он не является клиентом банка. Таблица news хранит последние новости
банка, состоящие из даты и полноценного описания.
Таблица exchange_rate хранит свежие данные о курсе валют -
цифры по сумме покупки и продажи, а также уникальный ID самой валюты.
Дополнительно хотелось подчеркнуть, что в рамках ВКР
происходила имитация не всей базы данных клиентов банка, а только той части,
необходимой первой версии модуля sip_response для ответов на базовые пользовательские
запросы.
2.2.1.2
Проектирование базы данных информационной системы
В рамках проектируемой ИС смоделирована база данных sip_response, отвечающая за хранение
данных, необходимых для функционирования модуля sip_response. Основным назначением
данных является подсказка модулю sip_response в выборе наиболее точного запроса,
удовлетворяющего потребностям пользователя. БД sip_response состоит из 10 таблиц.
Всего в спроектированной базе данных можно выделить 3
основные сущности: база запросов, на которые может ответить система, база
метаданных, помогающая выбрать запрос наиболее точно, а также журнал с историей
вызовов, обработанных модулем sip_response. Дополнительно база запросов и база
метаданных образуют отдельные таблицы, хранящие связи между сущностями в
формате "многие-ко-многим".
База запросов описана в таблице requests. Эту таблицу можно
считать основной, так как именно из нее модуль sip_response достает конечный запрос
и спрашивает пользователя, верно ли система поняла его потребности. Каждый
запрос содержит собственный уникальный ID, формулировку запроса,
статус запроса (требует аутентификацию или нет), а также путь в файловой
системе к аудиофайлу, в котором проигрывается формулировка запроса.
В дальнейшем будет показано, что почти все текстовые данные
базы sip_response ссылаются на относительные пути к аудиофайлам, из которых
впоследствии "склеивается" полноценный запрос, который система
возвращает пользователю.
Комплекс метаданных состоит из 4-х таблиц: keywords, answers, templates и statements. Таблица keywords содержит список ключевых
слов, которые могут быть связаны с запросами. Именно на основании ключевых слов
система может определиться с тем, связан ли запрос с клиентской потребностью.
Таблица answers содержит шаблонные фразы, которые являются
частью ответа, отдаваемого пользователю. Примером может быть фраза
"История ваших кредитов" или "Название пенсионной
программы". В таблице также содержатся ссылки на файл в локальной файловой
системе.
Таблица templates также содержит шаблонные
фразы, участвующие в формировании ответа пользователю. Однако части этих фраз
обычно используются в попытках наиболее точно узнать пожелания пользователя.
Примером может быть фраза "Ваш запрос". В таблице также содержатся
ссылки на файл в локальной файловой системе.
Таблица statements содержит SQL-запросы в текстовом
формате. Эти запросы впоследствии используются модулем sip_response для поиска подходящего
ответа в клиентской базе данных. Например, в базе хранится команда запроса для
нахождения ID пользовательской транзакции, информация о которой должна быть
отдана пользователю.
Связи между базой знаний и метаданными хранятся в отдельных
4-х таблицах requests_answers, requests_statements, requests_templates и requests_keywords. Именно в этих таблицах
каждый запрос имеет связь с информацией, необходимой для точного ответа на
запрос. Именно в подобных таблицах можно найти список ключевых слов, связанных
с конкретным запросом или составные части, формирующие в совокупности ответ на
запрос (таблицы requests_answers и requests_statements соответственно). В
каждой таблице описывается связи сущностей БД "многие-ко-многим".
Также в БД sip_response описывается сущность журнала вызовов,
описанная таблицей call_history. После каждого вызова пользователя, вне
зависимости от результата записываются данные о звонке, обработанном модулем sip_response. В таблице содержится
уникальный ID звонка, ID, отмеченный системой Asterisk в атрибуте call_agi_id, время завершения
вызова, ссылка на сгенерированный аудиофайл ответа пользователю, ID запроса из таблицы requests, ID клиента из БД customers и статус ответа
пользователю (успешно/не успешно/перенаправление в центр технической
поддержки).
Таким образом, спроектирована отдельная база данных для
модуля sip_response, удовлетворяющая всем необходимым требованиям для решения
задач, поставленных перед разрабатываемой системой.
2.2.2
Проектирование диаграмм "сущность-связь"
Для наглядности предметной области спроектированы диаграммы
БД "сущность-связь" с применением графических средств отображения
модели. В качестве средства визуализации использован программный продукт EA 12. Сначала созданы таблицы
проектируемой БД. Затем добавлены атрибуты с выделением первичных ключей и
присвоением ограничения "NOT NULL" для некоторых атрибутов.
Напоследок средствами EA проведена визуализация полученной базы данных с
последующим нанесением связей между таблицами. В приложении Б показаны итоговые
физические схемы двух БД: клиентской БД и БД модуля sip_response.
2.3 Выводы по
разделу
Основной задачей данного раздела работы проектирование модуля
информационной системы IP-телефонии sip_response как
полноценного программного продукта. сформирована концепция системы, описана
логика работы модуля в виде UML-диаграмм. Далее в разделе спроектировано
хранилище данных, состоящее из двух баз данных - БД модуля sip_response
и БД клиентов организации (в данном случае ООО "ПриветБанк").
3. Реализация
информационной системы
В разделе приведено описание по формированию тестового
окружения, реализация которого наиболее близка к среде целевой организации.
Далее описывается создание баз данных, необходимых для работы модуля. Затем
следует основная часть работы - реализация проекта sip_response
как приложения, осуществляющего общение с платформой Asterisk через
шлюзовой интерфейс AGI. Реализация проекта расписана по частям, каждая
из которых охватывает отдельный модуль системы. После этапа реализации описан
процесс непрерывного тестирования системы в совокупности с платформой IP-телефонии
Asterisk. В заключение раздела подводится итог проделанной работы путем
описания всех реализованных требований, описанных в первом разделе выпускной
квалификационной работы, а также конкретный путь реализации и преимущества,
которые несет в себе реализация работы модуля sip_response.
3.1
Формирование окружения для разработки системы
Одним из важнейших в разработке архитектуры системы является
подбор необходимых инструментов. Ключевыми факторами подбора являлись формат
лицензии (открытый или проприетарный продукт) и популярность на рынке
существующих решений. В рамках реализации модуля sip_response выделено несколько
функций, под каждую из которых отдельно подбирался инструмент.
) Операционная система. Основным требованием к
окружению создание среды на базе операционной системы GNU/Linux в виду того, что
платформа IP-телефонии Asterisk в данный момент может работать только на Linux системах.
Таким образом, средой программного окружения выбрана
операционная система Debian 8 (Jessie). В данной операционной системе имеется
пакетный менеджер apt, с помощью которого можно устанавливать
необходимое ПО.
Тестирование функционала в локальной среде, как и сама
разработка, проходила в рамках операционной системы Fedora 24, также построенной на
ядре Linux. Основным различием между системами являлся пакетный менеджер. В
ОС Fedora используется пакетный менеджер dnf. Однако данный факт не
повлиял на работоспособность окружений, как и на сам процесс разработки.
) СУБД. В рамках реализации модуля sip_response для формирования
хранилища данных выбрана СУБД PostgreSQL. Выбор СУБД обоснован в разделе 2.2 данной ВКР.
3) Язык программирования. В рамках разработки модуля sip_response в качестве языка
программирования выбран язык Python. Рабочим интерпретатором языка являлся
интерпретатор версии 2.7 сделан принципиальный отказ от разработки под
интерпретатор версии 3 ввиду отсутствия его поддержки интерфейсом Asterisk.
Выбор среди существующих решений для реализации интеграции
модуля с существующим функционалом Asterisk состоял из девяти языков программирования:
Bash, Java, Pascal, Perl, PHP, Python, Ruby, C и Haskell. В конечном итоге для
разработки модуля sip_response был выбран язык Python по следующим причинам:
знание языка Python разработчиком модуля sip_response, что впоследствии
значительно сократило время, отведенное на разработку;
простота языка и высокая скорость разработки;
поддержка обновленного интерфейса Asterisk;
возможность неограниченного расширения посредством
подключаемых модулей;
архитектура языка, позволяющая разбить программу на составные
модули, а также отказаться от парадигмы объектно-ориентированного
программирования, значительно нагружающую логику программы, как и сам процесс
ее выполнения;
высокая скорость эволюции языка, что делает проект актуальным
как минимум в ближайшие несколько лет.
) Интерфейс системы IP-телефонии. В платформе IP-телефонии Asterisk существует возможность
расширения существующего функционала за счет выполнения сторонних программ
через шлюзовой интерфейс Asterisk (Asterisk Gateway Interface - AGI). Именно AGI выбрано в качестве
интерфейса общения между интерпретатором Python и диалпланом Asterisk.
Реализация обмена данными с диалпланом Asterisk проведена через внешний
модуль Python под названием pyst2. Процесс обмена данными в основном заключался в
передаче состояния системы другой системе посредством переменных. Таким
образом, логика работы каждого из компонентов модуля сохранялась только внутри
модуля.
) Среда разработки. Очень важным моментом являлся
выбор среды для написания программного кода модуля sip_response. В итоге выбрана связка
текстового редактора Sublime Text 3 с необходимыми
расширениями для языка Python, а также терминал командной строки Linux, в которой запускался
интерпретатор Python 2.7 для тестирования изменений.
Впоследствии в процессе анализа данного решения сделан вывод
о том, что можно улучшить подход к написанию программного кода. Дальнейшие
разработки продукта будут проводиться в текстовом редакторе Vim, расширенный несколькими
плагинами, внутри которого будет запускаться интерпретатор Python.
) Транскодер аудиофайлов. Необходимо выбрать
инструмент, осуществляющий преобразование аудиофайлов в формат, наиболее
подходящий как для системы Asterisk, так и для конвертации в текст.
Платформа Asterisk способна проигрывать аудиофайлы в процессе
соединения с клиентом в формате gsm. Для конвертации аудио в формат gsm использовалась утилита sox, запускаемая программой
на языке Python в виде выполнения системной командой. Утилита sox, приняв на вход аргумент
формата файла, осуществляет его транскодирование в формат gsm, сохраняя результат в
новом файле, который впоследствии проигрывается платформой Asterisk.
Для конвертации речи в текст через запрос к внешнему API речевого распознавания
наиболее четко работает с аудиофайлами в формате wav. Для конвертации в
формат wav использовалась утилита FFmpeg, запускаемая
подключаемым Python-модулем pydub. Аналогично функция конвертации файла принимает
на вход необходимый исходный формат файла и преобразует его в wav. Предполагалось
использовать модуль pydub и в транскодировании в формат gsm, однако возникли
проблемы с поддержкой gsm-кодеков утилитой FFmpeg.
) Интерфейс СУБД. После выбора самой СУБД необходимо
также выбрать интерфейс работы с базами данных, через который можно бы
осуществить подключение к базе и проводить тестовые запросы. В качестве
интерфейса к СУБД PostgreSQL был выбран модуль языка Python psycopg2.
8) Интерфейс конвертации речи в текст. Для речевого
распознавания клиентских запросов решено использовать сторонний инструмент. Это
позволило в дальнейшем сократить время на разработку программы, а также
сохранить умственные ресурсы разработчика для полноценной концентрации на самом
программном продукте. Основной задачей речевого распознавания конвертация
запроса клиента, записанного в аудиофайл, в текстовый файл для дальнейшей
обработки подсистемой контроля вызова в модуле sip_response.
Для выполнения данной задачи импортирован сторонний модуль Python SpeechRecognition, представляющий собой API для общения с внешними
системами речевого распознавания. В качестве систем распознавания использованы
две среды: Google Speech API и Wit. ai. Выбор данных систем
обосновывается в разделе 3.3.3, где наиболее подробно описывается механизм
речевой обработки данных.
) Интерфейс конвертации текста в речь. В реализации
модуля sip_response также выполняется процесс конвертации текста в речевой
формат для формирования части полноценного ответа на клиентский запрос перед
непосредственным слиянием частей в общий ответ. Для этого использована система Google Speech, позволяющая запрашивать
обработку текста в голос на нескольких речевых языках. Взаимодействием с Google Speech управляет сторонний
модуль Python gTSS (Google Text-to-Speech), позволяющий упростить
процедуру конвертации текста в речь до двух-трех строчек программного кода.
Взаимодействие модуля sip_response с вышеперечисленными
инструментами показано на диаграмме компонентов в приложении В. В разделе 2.1.2
наиболее подробно описаны процессы взаимодействия модуля sip_response с внешними системами.
) Шаблоны ответа на пользовательский запрос. В рамках
реализации модуля необходимо подготовить шаблоны для дальнейшего слияния
утилитой sip_response в единый ответ для отдачи клиенту в ответ на его запрос. Под
шаблоном в данном случае воспринимается кусок фразы, который можно встроить в
начало, середину или конец фразы. Дополнительно необходимо реализовать фразы
приветствия и прощания с клиентом системы, которые не должны изменяться
сторонними программами и быть доступными для воспроизведения диалпланом Asterisk.
В итоге данная проблема решена подготовкой
шаблонов-аудиофайлов посредством нескольких запросов в Google Speech API через командную строку Linux. Итогом подготовки
шаблонов стал отсортированный перечень аудиофайлов, относительные пути к
которым прописаны в базе данных. На рисунке 3.1.2 представлена визуализация
дерева аудиофайлов-шаблонов, доступных как для диалплана системы Asterisk, так и для модуля sip_response.
Рисунок 3.1.2 - дерево файловой системы аудиофайлов-шаблонов
Данное дерево файловой системы состоит из следующих узлов:
1) asterisk - раздел, в котором
хранятся готовые фразы для ответа пользователю без необходимости дополнительной
обработке. В перечень таких фраз входят запросы на прохождение аутентификации,
стартовый вопрос пользователю, перенаправление в систему технической поддержки
и т.д.;
2) builtin - раздел, в котором
хранятся конкретные фразы, которые будут являться частями полноценного ответа
на пользовательский запрос; в свою очередь фразы отсортированы в файловой
системе по трем категорям:
а) answers (для окончательного ответа на конкретный
пользовательский запрос, например, состояние транзакции или информация о
вкладах пользователя);
б) requests (для воспроизведения формата пользовательского
запроса, выбранного системой для дальнейшей обработки);
в) templates (дополнительные фразы, которые могут быть
включены и в категорию requests, и в категорию answers).
Все полноценные утилиты установлены через пакетный менеджер
операционной системы Debian apt. Подключаемые модули
языка Python установлены через менеджер зависимостей pip, предназначенный
конкретно для установки модулей Python.
Все реализуемые инструменты находятся в открытом доступе и
являются продуктами СПО, позволяющими при необходимости отследить работу
программного кода сторонних процедур и разобраться в возможных ошибках работы с
внешними инструментами.
Также после ручной установки всех необходимых программ
написан отдельный скрипт на языке Bash - языке командной оболочки Linux, который автоматически устанавливает
все необходимые утилиты. Работа данного скрипта полностью протестирована и
отлажена на новой "пустой среде", созданной запуском отдельного
виртуального контейнера.
Далее описываются ключевые инструменты непосредственного
самого процесса разработки и тестирования модуля sip_response.
.1.1 Система
контроля версий
Система контроля версий (CVS) - это система,
регистрирующая изменения в одном или нескольких файлах с тем, чтобы в
дальнейшем возможность вернуться к определённым старым версиям этих файлов. Ни
один из современных проектов разработки ПО не обходится без системы контроля
версий ввиду как усложнения архитектуры программы, так и наличия дополнительных
окружений, которые необходимо использовать в процессе разработки.
В начале разработки модуля sip_response
возникла проблема несовместимости локального и тестового окружений. Установить
для тестов дополнительную систему IP-телефонии означало существенное
увеличение нагрузки на локальный компьютер, а также нецелесообразность расхода
аппаратных ресурсов.
Нужен механизм разделения проекта на разработку в локальном
окружении и тестирование в специальном окружении, т.е. разделение отдельных
частей программного кода с сохранением общей кодовой базы. Именно поэтому
решено использовать версионирование кода посредством CVS.
Выбор среди решений по системам контроля версий проведен
достаточно быстро ввиду отсутствия конкуренции на рынке решений. Для разработки
выбрана система контроля версий Git, основной концепцией которого
являются две составляющие: сохранение изменений в программном коде в виде
отдельных кусков (commit), которые впоследствии можно легко откатить
назад, а также разделение окружений и задач на несколько ветвей (branch).
В рамках разработки проект sip_response
разделен на 3 ветки:
master - ветка со стабильным программным кодом;
testing - ветка для разработки в локальной среде с
последующим тестированием на основании входных данных, имитирующих реальные
рабочие процессы программного продукта;
intermediate - промежуточный программный код, который
проходит через этап тестирование на окружении, аналогичном инфраструктуре
организации, где работает как система IP-телефонии Asterisk, так
и СУБД PostgreSQL.
Таким образом, путем разделения кодовой базы на несколько
веток удалось достигнуть консенсуса между стабильной кодовой базой проекта и
его непрерывным совершенствованием.
3.1.2
Контейнеризация тестового окружения
На начальном этапе процесса разработки стояла проблема
использования системы IP-телефонии для тестирования работы модуля sip_response. Система IP-телефонии является
достаточно тяжеловесным программным обеспечением, которое трудно развернуть на
локальной среде и еще труднее поддерживать его в рабочем состоянии. Именно
поэтому принято решение развернуть полноценное тестовое окружение с необходимым
ПО (в частности, с платформой Asterisk) внутри контейнера. Данное решение можно
называть "контейнеризацией" тестового окружения.
Под словом "контейнеризация" понимается
виртуализация на уровне операционной системы, т.е. создание изолированного
окружения пользовательского уровня ОС, работающего на той же версии ядра ОС,
что и среда виртуализации. Преимущества данного подхода заключаются в
уменьшении накладных расходов на утилизацию аппаратного обеспечения, так как в
данный момент процессор использует только одно ядро ОС, а также возможность
быстро развернуть окружение в любой среде, на которой работает ОС типа GNU/Linux.
Программным обеспечением для реализации контейнера на
локальной машине, работающей на ОС Fedora 24, являлся такой продукт, как Docker. Docker - программное
обеспечение для автоматизации развёртывания и управления приложениями в среде
виртуализации на уровне операционной системы, например LXC. Docker позволяет
"упаковать" приложение со всем его окружением и зависимостями в
контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также
предоставляет среду по управлению контейнерами.
Инструкция по созданию контейнера описывается как код в
отдельном конфигурационном файле - Dockerfile. В качестве основного контейнера
взят шаблон asterisk-testsuite из общего репозитория контейнеров Docker Hub. Контейнер asterisk-testsuite содержит не только
установленную систему IP-телефонии Asterisk, но и тестовое окружение
Asterisk testsuite, позволяющего запускать
тесты, проверяющие работу платформы IP-телефонии как единого
целого.
После получения конфигурационного файла контейнера проведена
его дополнительная доработка посредством добавления команд установки ПО,
описанного в данном разделе. После этого запущен процесс сборки контейнера.
После успешной сборки готовый контейнер стартовал на локальной среде. В
дальнейшем подключение к Docker-контейнеру осуществлялось посредством вызова
командной строки интерпретатора Bash и вводом команд, необходимых для
конфигурации тестового окружения. В листинге 3.1.2.1 указан скрипт, описывающий
перечень процедур, выполненных для развертывания тестового окружения в
контейнере.
docker build - t asterisk-testsuite
github.com/sboily/asterisk-testsuite. gitrun - i - t asterisk-testsuite /bin/bash ps - a
Листинг 3.1.2.1 - развертывание тестового окружения в Docker-контейнере
3.1.3 Выбор
SIP-клиента
Под SIP-клиентом воспринимается программное обеспечение,
способное подключаться к серверу IP-телефонии и поддерживать клиентские вызовы к
этой системе. По своему существу SIP-клиенты действуют как обычные телефоны, только
работают не по АТС, а по IP-сети, передавая данные по локальной или
глобальной сети.
Основным назначением SIP-клиентом в разработке и
тестировании модуля sip_response являлась имитация вызова к IP-телефонии от лица
клиента как часть end-to-end тестирования. Таким образом, совершая вызов к
системе IP-телефонии Asterisk, тестировался функционал системы, отдельные
части и нововведения в программный код.
Выбор SIP-клиента для разработки основывался на ОС,
поддерживаемых программой. Необходимо выбрать тот клиент, который работал бы на
операционной системе Fedora. Всего рассмотрено порядка 10-15 клиентов.
Задачу выбора усложняли отчетливо видимые недостатки инструментов. Например,
утилита Zoiper не поддерживала проигрывание аудиофайлов системой Asterisk, а программа Jitsi могла работать только на
Java 7 - устаревшей версии
интерпретатора.
В итоге выбран SIP-клиент Ring - полнофункциональный
инструмент, с помощью которого наиболее удобно совершать звонки к утилите Asterisk. Перед осуществлением
вызовов необходимо сконфигурировать подключение к клиенту сначала источника
звонка (использована та же тестовая среда Asterisk, что и в разработке
приложения), а затем и адреса назначения (сконфигурирован адрес, который в
рамках тестирования имитировал центр технической поддержки организации).
3.2
Реализация баз данных системы
В ходе разработки модуля sip_response реализованы две базы
данных в рабочую СУБД PostgeSQL 9.5: клиентская БД customers и база данных модуля sip_response. Процесс реализации
разбит на 4 этапа: создание баз данных, создание таблиц, добавление тестовых
данных и тестирование запросов средствами языка программирования Python.
Создание баз данных осуществлено посредством подключения к командной
строке PostgreSQL и ввода команды CRAETE DATABASE дважды: один раз для
создания БД customers и один раз для создания БД sip_response.
Создание таблиц осуществлено посредством наката SQL-скриптов в базы данных,
к которым происходило подключение через командную строку. введены команды
исполнения скриптов, указанные в листинге 3.2.1, после чего интерпретатор
командной строки PostgreSQL поочередно выполнял запросы CREATE TABLE, написанные в скриптах,
создавая новые таблицы.
\i sql/create_tables_customers. sql
\i sql/create_tables_sip_response. sql
\i sql/insert_into_customers. sql
\i sql/insert_into_sip_response. sql
Листинг 3.2.1 - выполнение SQL-скриптов создания схемы
БД
Далее сгенерированы тестовые данные посредством наката SQL-скриптов с SQL-операторами INSERT. Команды выполнения
скриптов также доступны для просмотра в листинге 3.2.1.
Для клиентской базы данных customers в качестве сущности
клиента добавлен клиент банка, у которого есть собственный банковский счет,
активы в виде вклада, пенсионной программы и пассив в виде кредита. В качестве
сущности услуг банка добавлен 1 услуга кредита, 1 услуга вклада и 1 услуга
пенсионной программы. Также добавлена тестовая транзакция и данные, необходимые
для аутентификации пользователя. Кроме, того, добавлены данные в другие
сущности, не связанные напрямую с клиентами и услугами банка напрямую, такие,
как новость банка и состояние курса доллара и евро.
Для базы данных sip_response добавлены реальные данные, необходимые
для функционирования модуля sip_response. добавлены базовые запросы, которые
модуль sip_response должен обрабатывать самостоятельно, ключевые слова, по
которым проводится поиск в клиентском запросе, шаблоны ответа пользователю, а
также SQL-запросы поиска информации, необходимой для ответа на клиентский
запрос. Сущности запросов и сопутствующих метаданных связаны в смежных таблицах
БД по уникальным ID. Данные в таблицу call_history заранее планировалось
добавлять в процессе работы модуля.
Тестирование запросов к СУБД осуществлялось посредство
запуска командной строки интерпретатора Python 2.7, импортированием
модуля psycopg2 как интерфейса работы с PostgreSQL и запуском функции
подключения к базам данных, имея необходимые данные для полноценного доступа.
Дополнительно после этого протестированы отдельные запросы, чтобы проверить
корректность их выполнения и понять принцип упаковки данных модулем psycopg2 для последующей
обработки результатов запроса.
3.3
Разработка модулей системы
С точки зрения архитектуры модуль sip_response решено разделить на несколько
подсистем, которые также можно назвать модулями в терминологии языка Python. Однако, чтобы не
путаться в терминологии в рамках данной ВКР, составные части модуля sip_response будут названы
подсистемами, а основной запускаемый файл - основным модулем.
Модульный подход имеет гораздо больше преимуществ, чем
недостатков. В первую очередь преимуществом является разделение бизнес-логики
приложения и отсутствие единой точки отказа. Далее модульный подход имеет
преимущество в упрощении задачи сопровождении программы. Гораздо легче найти
ошибку в программном коде на 200 строк, чем искать и отлаживать ее в коде на
1000 строк. Дополнительно данный подход является полноценно масштабируемым. В
дальнейшем разрабатываемые подсистемы гораздо проще разделить в команде
разработчиков и даже между несколькими командами разработчиков.
В случае разработки модуля sip_response выделено несколько
подсистем:
1) диалплан платформы Asterisk
extensions. conf;
2) основной модуль main. py как запускаемый файл;
) подсистема речевой обработки данных recognition. py;
) подсистема контроля вызовов control. py;
) интерфейс работы с базами данных db_interface. py.
Каждая из подсистем отдельно описывается в следующих
подразделах ВКР.
3.3.1
Разработка диалплана информационной системы
Любая операция, происходящая с соединением по каналу связи,
управляется Asterisk исходя из настроек, указанных в файле диалплана. В
операционных системах GNU/Linux полным названием файла диалплана является
/etc/asterisk/extensions. conf. В контексте
конфигурации диалплана для реализации модуля sip_response подразумевается:
) запуск кода на Python в системе Asterisk;
) последующая конфигурация логики диалплана для обмена
данными с модулем.
Запуск стороннего программного кода решается посредством
оформления специальных AGI-скриптов. Под аббревиатурой AGI подразумевается шлюзовой
интерфейс Asterisk (Asterisk Gateway Interface), позволяющий расширять
семантику диалплана Asterisk. Фактически модуль работает в виде отдельного
приложения, где исполняемый файл main. py запускается встроенной
функцией диалплана AGI. Интерфейс AGI может выполнять
программы на многих языках программирования при наличии соответствующих
библиотек, однако создателями Asterisk рекомендуется использовать язык Python, выбранный для
разработки модуля.
Обмен данными между диалпланом и подсистемами модуля sip_response сконфигурирован путем
использования стандартных функций диалплана. Основной концепцией будет передача
данных в потоках stdin, stdout и stderr, что является основой межпроцессорного
взаимодействия в операционных системах GNU/Linux.
На рисунке 3.3.1.1 показана блок схема, отображающая
последовательность обработки вызова диалпланом системы Asterisk в соответствии с
заданными условиями.
Рисунок 3.3.1.1 - блок-схема работы диалплана Asterisk
Конфигурация диалплана, описанная специфичным языком конфигурации DSL, разделена на несколько логических
частей.
1) Создание пользователей.
2) Начало вызова.
3) Прием вызова и просьба озвучить запрос.
) Опрос пользователя на корректность данных по
распознаванию запроса.
5) Аутентификация пользователя.
) Ответ на запрос пользователя.
) Прерывание вызова.
В приложении В указан отрывок кода конфигурации диалплана Asterisk. Данный перечень команд
управляет абонентскими вызовами, предназначенными для обработки модулем sip_response.
3.3.2
Разработка основного модуля
Основным модулем системы является файл main. py. Именно этот файл
совершает обмен данными между модулем sip_response и системой IP-телефонии Asterisk, а также выполняет
базовые операции, запрашиваемые диалпланом. В основной модуль импортированы как
внутренние подсистемы, являющиеся частью приложения, так и AGI-оболочка для общения с Asterisk - модуль pyst и модули стандартной
библиотеки Python для работы с системой: sys, os и re.
На рисунке 3.3.2.1 показана блок схема, отображающая
последовательность обработки вызова основным файлом модуля sip_response main. py в соответствии с
заданными условиями.
Рисунок 3.3.2.1 - блок-схема работы модуля main. py
В самом начале модуль main.
py загружает состояние вызова в виде
присвоения переменных диалплана локально, а также устанавливая путь к корневой
директории аудиофайлов, запрашиваемых пользователем. Основными переменными
состояния являются счетчик ключевых слов (keyword_flag) и
счетчик запросов (request_flag). Далее принцип работы заключается в
исполнении одной из пяти операций, которую запросил диалплан.
1) Обработка запроса.
2) Опрос пользователя на корректность распознанного
запроса.
3) Аутентификация.
4) Генерирование ответа на пользовательский запрос.
5) Логгирование.
3.3.3
Разработка подсистемы речевой обработки данных
Основным назначением подсистемы речевой обработки данных
является работа с аудиоданными, получаемыми и генерируемыми модулем
информационной системы IP-телефонии sip_response.
Функционал подсистемы разбит на несколько функций, вызываемых как основным
модулем main. py, так и системой контроля вызова.
Всего подсистема речевой обработки данных
способна выполнять 4 функции.
1) Конвертация аудиофайлов. Основной целью процесса
конвертации является преобразование аудиоданных в тот формат, который наиболее
пригоден для обработки целевым компонентом системы, в данном случае системой IP-телефонии.
На данный момент функция работает следующим образом: все
запросы по конвертации направляются в модуль pydub, который в свою
очередь вызывает FFmpeg. Исключение составляет формат GSM, который
преобразуется через утилиту sox.
2) Преобразование речевого запроса в текстовые данные.
На рисунке 3.3.3.1 показана блок схема, отображающая процесс конвертации
речевого запроса пользователя в текстовый формат для последующей обработки
подсистемой контроля вызовов.
Рисунок 3.3.3.1 - блок-схема работы процесса конвертации
речевого запроса
) Преобразование текстовых данных в речевой запрос.
Процесс переноса текстовых данных в речь кажется наиболее сложным, чем обратный
процесс распознавания человеческой речи. Однако данная функция, необходимая
модулю sip_response для вставки клиентских данных из БД в полный ответ, также
отдается на выполнение внешнему API.
В данном случае используется внешний Python-модуль gTTS, работающий с Google Speech API. Речь генерируется в том
же формате, что и в популярном внешнем сервисе Google Translate. В данном случае при
вызове функции просто запускается функция генерирования аудиоданных из API с последующей записью в
бинарный файл. В итоге подсистеме контроля вызова на выход отдается ссылка на
аудиофайл для дальнейшей генерации полноценного ответа.
) Слияние файлов. Основной целью процесса слияния
файлов является генерация полноценного связанного ответа пользователю
посредством последовательного склеивания кусков файла, поступающих на вход
функции. Для этого вызывается модуль pydub который в свою очередь
посылает запрос на утилиту FFmpeg по слиянию файлов.
3.3.4
Разработка подсистемы контроля вызовов
Подсистема контроля вызовов является основополагающим
компонентом модуля информационной системы IP-телефонии sip_response. Именно здесь описывается
логика обработки клиентского запроса, а также генерирования ответа на
пользовательский запрос.
Для доступа к хранилищу данных используется импортированный
интерфейс БД. Данные для доступа к БД подсистема получает из внешнего
конфигурационного файла через модуль ConfigParser. Весь функционал
подсистемы заключен в несколько функций, вызываемых основным модулем main. py. Ниже
приводится полный список функций системы.
1) Поиск запроса. На рисунке 3.3.4.1 показана блок
схема, отображающая процесс поиска запроса в соответствии с текстовыми данными,
полученными от пользователя.
Рисунок 3.3.4.1 - блок-схема работы процесса поиска подходящего
запроса
2) Аутентификация по пользовательским данным. На рисунке
3.3.4.2 показана блок схема, отображающая процесс аутентификации пользователя в
соответствии с достоверностью запрашиваемых данных.
Рисунок 3.3.4.2 - блок-схема работы процесса аутентификации
пользователя
3) Ответ на запрос пользователя. На рисунке 3.3.4.3
показана блок схема, отображающая процесс формирования полноценного ответа на
пользовательский запрос.
Рисунок 3.3.4.3 - блок-схема работы процесса формирования ответа
4) Логгирование. Процесс логгирования состоит из 2-х
операций: подключения к БД и выполнению INSERT-запроса с теми данными,
которые поступили на вход от основного модуля.
3.3.5
Разработка интерфейса базы данных
Процедура подключения к базе данных в языке программирования Python представляет собой
рутинную операцию, которая в ходе выполнения программы вызывается несколько
раз. В разработке проектов на языке Python операции такого рода
обычно заключают либо в отдельные функции внутри определенного модуля, либо
выносят как отдельный модуль в принципе.
В случае разработки модуля sip_response решено вынести операции
создания соединений с БД в виде отдельного модуля, который будет играть роль
интерфейса доступа к хранилищу данных. Данный интерфейс называется db_interface. py и работает как модуль,
импортируемый в подсистему контроля вызовов. Сам интерфейс для подключения к
хранилищу данных использует внешний модуль psycopg2.
Всего интерфейс может выполнять 2 операции, описанные в виде
отдельных функций: подключение к базе (функция connect) и запрос к базе
(функция query). Данные функции представляют собой лишь оболочку основных
методов модуля psycopg2, однако теперь в подсистеме контроля вызовов мы можем
выполнить подобные операции уже в одну строку. Таким образом, программный код
получается более структурированным и менее громоздким.
3.4
Тестирование работы системы
Тестирование программного обеспечения является одним из
ключевых этапов в процессе разработки информационных систем. Именно
тестирование ПО позволяет ответить на вопрос, работает ли новая версия
программного продукта, успешно ли проведена интеграция новых функций в уже
устоявшуюся систему и по каким причинам продукт перестал работать в
совокупности с новыми изменениями.
Всего существуют несколько видов тестирования программного обеспечения:
unit-тестирование,
интеграционное тестирование, smoke-тесты, приемочно-пользовательское тестирование,
тесты производительности, end-to-end тестирование, а также нагрузочное тестирование.
В итоге на первых стадиях разработки решено использовать стратегию end-to-end тестирования (E2E). E2E-тестирование заключается
в тестировании функционала программного продукта со стороны пользователя.
Например, каждое новое введение дополнительного функционала
проверялось посредством тестового звонка в систему со стороны SIP-клиента на локальном
компьютере с целью проверки именно нового функционала. Таким образом, в
разработке можно столкнуться с ошибками изменений, повлиявшими на старый
функционал, которые в итоге быстро обнаруживались и редактировались.
В ходе разработки проводилось непрерывное тестирование
программного продукта. Вообще после реализации "каркаса" модуля sip_response разработка проводилась
следующим образом:
) переход на ветку testing в системе контроля
версий;
2) написание функционала, контактирующего с внешними API без участия системы IP-телефонии Asterisk с возможностью
добавления входных данных;
) проверка функционала посредством запуска приложения
с соответствующими входными данными; корректировка возникших ошибок в коде;
4) commit изменений в ветке testing переход на ветку intermediate с дальнейшим слиянием
изменений из ветки testing коммандой git cherry-pick;
) доведение исходного кода в ветке intermediate до рабочего состояния;
) выкат изменений в git-репозиторий и дальнейшая
загрузка изменений в тестовую среду IP-телефонии;
) тестирование функционала путем тестового звонка в
систему Asterisk;
) выявление ошибок и корректировка исходного кода в
локальной среде с дальнейшей загрузкой в git-репозиторий;
) повтор шага 7 до тех пор, пока код из ветки intermediate не станет полноценно
работать;
) слияние работающих изменений в ветку master;
) проверка работы ветки master; корректировка
появившихся ошибок;
) регистрация изменений; закрытие поставленной задаче
в личном to-do листе; переход к новой задаче, возвращаясь к шагу 1 итерации
разработки.
Данная стратегия разработки ни в коем случае не является
совершенной и имеет свои недостатки. Однако эта стратегия позволила сохранить
стабильный код в "боевой" среде, а также проводить тестирование без
опасения отказов, после которых нельзя вернуть систему к прежнему состоянию.
В дальнейшем при совершенствовании программного продукта
планируются написать отдельные тесты на языке Python, которые будут
прогоняться автоматически при загрузке commit-а в удаленный Git-репозиторий.
3.5
Реализация требований к модулю
При постановке задачи на внедрение/разработку ИС определены
следующие требования:
) функциональные требования;
) требования к безопасности;
) требования к удобству использования;
) требования к производительности;
) требования к срокам внедрения;
) требования к ПО для сопровождения проекта;
) требования к расходам на сопровождение проекта.
Под функциональными требованиями охарактеризована задача
обработки перечня базовых запросов, поступающих в техническую поддержку
организации. В данном случае для реализации модуля sip_response для технической
поддержки ООО "ПриветБанк" сформирован конкретный перечень запросов.
По итогам тестирования продемонстрировано умение системы
отвечать на все запросы, описанные в рамках технических требований.
Дополнительно стоит отметить тот факт, что схема обработки запросов является
масштабируемой и способной к увеличению перечня базовых запросов, хранимых в БД
модуля.
Дополнительно протестировано требование отказоустойчивости и
перенаправления вызова в узкоспециализированный центр технической поддержки в
случае невозможности точно определить потребности клиента. Перенаправление
осуществляет непосредственно сама система IP-телефонии Asterisk, переключая SIP-клиентов на стороне
организации.
Требование по безопасности выполнено посредством реализации
процесса аутентификации в модуле sip_response для доступа к конфиденциальным данным.
Для входа в систему пользователь должен назвать не только свое имя и номер
кредитной карты, но и CVV-код, а также код доступа к кредитной карте.
Таким образом, спроектированный механизм обеспечения информационной
безопасности соответствует трем базовым свойствам: конфиденциальность (только
владелец информации о коде доступа к кредитной карте может иметь доступ к
данным), целостности (даже при утере/краже клиентской кредитной карты,
злоумышленнику недостаточно приобретенной информации для доступа к данным) и
доступности (процесс входа в систему в целом напоминает общеизвестную
аутентификацию в банкоматах, где также требуется ввести код доступа).
Также соблюдено дополнительное требование по безопасности, а
именно хранение данных для доступа к внешним ресурсам за пределами исходного
кода. В настоящий момент компоненты модуля sip_response получают данные для
доступа из конфигурационного файла myresponse. conf, который находится
внутри корневой директории проекта.
Файл myresponse. conf представляет собой структурированный
текст конфигурации, описанный в формате ini. Подсистемы получают
данные для доступа путем вызова модуля стандартной библиотеки Python ConfigParser, вызывая отдельные
параметры внутрь локальных переменных. Таким образом, сейчас во внешнем
конфигурационном файле отдельно хранятся данные для доступа к следующим
компонентам системамы:
1) клиентская БД;
2) БД модуля sip_response;
3) Google Speech API;
4) Wit. ai.
Требование к удобству использования выполнено в процессе
реализации системы посредством запуска shell-скрипта,
устанавливающего необходимое ПО для работы модуля, а также осуществляющего необходимую
конфигурацию. Таким образом, процесс настройки окружения модуля sip_response является полностью
автоматизированным. Также при разработке отмечен тот факт, что созданная
система не имеет каких-либо ярко выраженных проблем, связанных с сопровождением
системы.
Требования к производительности рассматривают:
) идентичность поведения системы IP-телефонии в двух
ситуациях: до и после установки модуля;
) добавление модулем сравнительного небольшой нагрузки на
систему в процессе работы;
) способность асинхронной работы, возможность
обработки/удержания нескольких запросов одновременно.
В ходе процесса тестирования работы модуля sip_response доказано удовлетворение
всех вышеперечисленных требований по работе окружения системы IP-телефонии. Существующее
решение системы по-прежнему отвечает на определенные виды звонков,
перенаправляя вызовы к необходимым объектам диалплана.
Нагрузка, добавленная модулем sip_response при активной работе,
сравнительно небольшая. Интерпретатор языка Python, в отличие от Java Virtual Machine, потребляет гораздо
меньше ресурсов на обработку запросов, существенно выигрывая в
производительности запущенной машины в целом. Также разработанный модуль может
обрабатывать несколько ресурсов одновременно, обрабатывая несколько запросов к
БД одновременно.
Требования по срокам внедрения проекта также успешно
выполнены. С большим временным запасом в полгода модуль sip_response спроектирован и
реализован, предварительно пройдя этап постановки задачи и анализа требований к
системе.
Требования к ПО для сопровождения проекта успешно реализованы
в процессе тестирования. установлены, сконфигурированы и протестированы в
рабочих процессах приложения все необходимые программные продукты и модули,
описанные в первой части ВКР.
Требования к расходам на сопровождение программного продукта
также успешно выполнены. Все необходимое ПО для запуска модуля sip_response является свободным
программным обеспечением, которое имеет свойство свободного распространения без
взимания какой-либо дополнительной платой. Таким образом, основной частью
статьи расходов на реализацию модуля будут являться только расходы на рабочие
часы разработчика.
Таким образом, итогом этапа реализации модуля информационной
системы IP-телефонии Asterisk под названием sip_response стало выполнение полного
перечня требований, согласованного в процессе постановки задачи как со стороны
заказчика, так и со стороны разработчика информационной системы.
3.6 Выводы по
разделу
Основной целью данного раздела ВКР описание ключевого этапа
реализации модуля информационной системы IP-телефонии sip_response. Данный этап
включал в себя описание таких шагов, как:
1) формирование окружения проекта, выбор подходящих
инструментов для разработки и тестирования;
2) создание клиентской БД customers и БД модуля sip_response, образующих в комплексе
хранилище данных системы;
) реализация модуля sip_response посредством написания
исходного кода проекта, разделенного на несколько взаимосвязанных модулей;
) процесс непрерывного интеграционного тестирования
системы, верификация работы инкрементальных изменений;
) подведение итогов реализации посредством пересмотра
технических требований к проекту и описания шагов, реализованных для выполнения
этих требований.
Заключение
По итогам исследований, описанных в данной выпускной квалификационной
работе, удалось достичь главной цели - полноценной реализации модуля sip_response, встраиваемого в
информационную систему IP-телефонии Asterisk. В конечном итоге создан
полноценный программный продукт, готовый для продаж и пригодный для дальнейшего
совершенствования и технической поддержки. В рамках работы выполнены следующие
задачи:
) анализ предметной области, существующих решений на рынке
информационных систем и выбор базовой системы для дальнейшего проектирования
модуля;
) постановка задачи, выбор целевого потребителя, формирование
концепции проекта, описываемого в работе, выбор необходимых инструментов для
реализации;
) проектирование составных компонентов модуля системы IP-телефонии, баз данных,
необходимых для поддержки проекта;
) реализация модуля информационной системы IP-телефонии sip_response посредством переноса
концепции проекта в исходный код, предварительно выбрав инструменты для
формирования окружения и тестирования проекта.
В ходе выпускной квалификационной работы:
1) проанализирована предметная область;
2) путем исследований выявлены наиболее актуальные
решения в предметной области, выбрана целевая платформа для реализации
системного модуля и конкуренты в целевой отрасли;
) сформированы как общие, так и технические требования
к проекту;
) разработаны модели на языке UML, формирующие и
отображающие концепцию как всей информационной системы, так и реализуемого
программного продукта в частности;
) проанализировано, смоделировано и реализовано
хранилище данных системы, представляющее собой слияние существующей клиентской
базы данных и отдельной базы данных модуля IP-телефонии в логике
программного кода;
) разработан модуль sip_response в виде полноценного
встраиваемого программного компонента, позволяющего проводить двухсторонний
обмен данными между клиентами и системой IP-телефонии с минимизацией
человеческого вмешательства.
В виде дальнейших перспектив планируется:
) внедрение модуля в рынок свободного программного
обеспечения с выкладыванием исходного кода на основе тестовой ситуации в
открытый доступ;
2) интеграция хранилища данных модуля с NoSQL базами данных, такими,
имеющими документно-ориентированную структуру (например, MongoDB, DynamoDB и т.д.);
) укрепление базы знаний: увеличение количества
вариантов (use-case), при которых модуль sip_response способен обслужить
клиентский запрос без вмешательства персонала организации (т.е. специалистов
технической поддержки).
Библиографический
список
1. Чакон
С., Штрауб Б. Git для профессионального программиста. - СПб., Питер,
2016 г. - 490 с.
2. Riggs
S. PostgreSQL 9 Administration Cookbook - Second Edition. - Packt, 2015 г. - 504 с.
3. Дж.
ван Меггелен, Ярд Смит, Лейф Маадсен. Asterisk - будущее телефонии/ 4-e
издание. - СПб, Питер, 2015 г. - 656 с.
. Фиайли
К. SQL. Руководство по изучению языка. - М., ДМК Пресс, 2014 г. - 454 с.
5. Turnbull
D. The Docker Book: Containerization is the new virtualization. - Amazon, 2014 г. - 268 с.
6. Лутц
М. Изучаем Python/ 4-e издание. - М., Символ-Плюс, 2012 г. - 1280
с.
7. Introduction
to Docker // Youtube.
Режим доступа: https: // www.youtube.com/watch? v=Q5POuMHxW-0, свободный
(дата обращения: 30.07.2016 г.). - Заголовок с экрана.
8. Asterisk
Tutorial 06 - Asterisk Dialplan Introduction [english] // Youtube. Режим доступа: https: //
www.youtube.com/watch? v=UaIx_URUllw, свободный (дата обращения: 30.06.2016
г.). - Заголовок с экрана.
9. Database
Engineering with Enterprise Architect 12 // Youtube. Режим доступа: https: // www.youtube.com/watch?
v=LLtp49TU1H8, свободный (дата обращения:
12.03.2016 г.). - Заголовок с экрана.
10. IP-телефония в компьютерных сетях //
Национальный Открытый Университет "ИНТУИТ" | Бесплатное образование.
Режим доступа: #"896793.files/image012.gif">
Рисунок Б.2 - физическая схема базы данных модуля sip_response в EA
CREATE TABLE customers_credits (SERIAL
PRIMARY KEY,_id INT REFERENCES customers (id),_id INT REFERENCES credits
(id),DATE NOT NULL,_left NUMERIC (30,2) NOT NULL,customers_credits_id_idx
UNIQUE (id)
);
Листинг Б.3 - создание в клиентской базе данных customers таблицы сведений по
кредитам клиентов
CREATE TABLE call_history (_id SERIAL
PRIMARY KEY,_agi_id BIGINT NOT NULL,_timestamp TIMESTAMP NOT NULL,_number
VARCHAR (50),_status VARCHAR (10),_id INT,_id INT,_path VARCHAR (100),
);
Листинг Б.4 - создание в базе данных модуля sip_response таблицы журнала
обработанных вызовов
Приложение В
Исходный код проекта
if status == 'auth': #verify user identity
#get request field (name/cvv-code/credit card)=
agi. get_variable ('auth_subrequest')_request_id = int (agi. get_variable
('user_request_id')). verbose ('auth_subrequest %s' % field)_subdir =
'workflow/auth'_file = request_dir + '/' + request_subdir + '/' +
request_file_key + '. ' + request_extension
#build full file name_file = check_extension
(request_file, request_extension) #convert if it's not wav_text_file =
recognition. speech_to_text (_file, request_dir,_file_key, flag='auth'
)
#convert request to text. verbose
('request_text_file %s' % request_text_file)field == 'name': #call control
module function_result, customer_id = control. auth_name (_text_file,
user_request_id
). set_variable ('customer_id', customer_id) #get
customer id after authentication. verbose ('customer_id: %s' % customer_id):_id
= int (agi. get_variable ('customer_id'))_result = control. auth_credentials (,
request_text_file, customer_id
)_failed_flag = int (agi. get_variable
('auth_failed_flag'))auth_result == 'success': agi. set_variable
('auth_failed_flag', 0)auth_result == 'failed' and auth_failed_flag == 0: agi.
set_variable ('auth_failed_flag', 1)auth_result == 'failed' and
auth_failed_flag == 1: auth_result = 'redirect'. set_variable ('auth_result',
auth_result) #tell dialplan what's the final result. verbose ('auth_result: %s'
% auth_result)
Листинг В.1 - процесс пользовательской аутентификации в
запускаемом файле модуля main. py. (убрать курсив
в коде)speech_to_text (myfile, directory, key, flag=None):speech_recognition as
srConfigParser= sr. Recognizer () #create new object. energy_threshold =
300#set energy threshold. pause_threshold = 2#set appropriate pause threshold
#getting credentials from log file= ConfigParser.
ConfigParser (). read ("/var/lib/asterisk/agi-bin/sip_response/myresponse.
conf")_key = config. get ('recognition', 'google_api_key')_key = config.
get ('recognition', 'wit_api_key')sr. AudioFile (myfile) as source:
#create audio BLOB to recognize= r. listen
(source):= r. recognize_google (, key=google_key,='ru-RU'
)
#Google in priority but they have 50 API calls
limit
#if Google was broken - go to the nextsr.
UnknownValueError, sr. RequestError:= r. recognize_wit (, key=wit_key
)
#generate text file name_file = directory +
'/workflow/text/' + keyflag:_file = text_file + '_' + flagopen (text_file, 'w')
as text_store:_store. write (text. encode ('utf-8')) text_file
Листинг В.2 - процесс преобразования речевого запроса в
текстовый формат модулем recognition. py.
def auth_name (text_file, user_request_id):
#get request textline in open (text_file, 'r'):=
line, name, middle_name, year = request. split () [0: 4] #syntax requires
correct names and years order, cursor = db_interface. connect
(=customer_db_host, port=customer_db_port, db=customer_db_name,
user=customer_db_user, password=customer_db_password
)
#get the fact customer exists, pull his id= (
'SELECT id, CONCAT (surname, \' \', name, \'
\',_name, \' \', year) FROM customerssurname = \'%s\' AND name =
\'%s\'middle_name = \'%s\' AND year = \'%s\'; '
)= db_interface. query (statement, connect,
cursor)len (result) > 1:= 'redirect'status, 0len (result) == 0:
#failed authentication
#if no one customer has been found=
'failed'status, 0:= 'success'
#set the customer id if we found any_id = result
[0] [0]status, customer_id
Листинг В.3 - аутентификация пользователя по имени в модуле control. py.
; entire macro for authentication process
[macro-auth]
; accept the name of subrequest (customer name,
cvv etc.)=> s,1,Playback (sip_response/asterisk/auth_${ARG1})=> n,Record
(sip_response/workflow/auth/${request_id}: ${file_extension},5,10,q)=> n,Set
(module_call=auth)=> n,Set (auth_subrequest=${ARG1})=> n,AGI
(sip_response/main. py)=> n,GotoIf ($ ["${auth_result}" =
"failed"]? auth_failed)=> n,GotoIf ($ ["${auth_result}"
= "redirect"]? redirect)=> n,MacroExit ()
; go back if authentication failed=> n
(auth_failed),Playback (sip_response/asterisk/auth_failed)=> n,Goto (s,1)
; redirect to specialist if there is more than 2
attempts=> n (redirect),Playback (sip_response/asterisk/redirect)=>
n,Dial (SIP/caller)=> n,Goto (log,s,1)
; call the logging in case of hangup
[log]=> s,1,Set (module_call=log)=> n,AGI
(sip_response/main. py) => n,Hangup
Листинг В.4 - управление процессом пользовательской
аутентификации в диалплане Asterisk.