UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO. DESENHO DE IVRs PARA OPERADORAS TELEFÓNICAS

Transcrição

1 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO DESENHO DE IVRs PARA OPERADORAS TELEFÓNICAS Hugo Monteiro, n o 46546, AE de Telecomunicações Marco Mouta, n o 46607, AE de Telecomunicações LICENCIATURA EM ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES Relatório de Trabalho Final de Curso 119/2004/L Prof. Orientador: João Paulo Neto Trabalho realizado no L 2 F, INESC-ID Lisboa Setembro 2005

2

3 Agradecimentos Em primeiro lugar, queremos agradecer ao nosso orientador, Prof. João Paulo Neto por todo o apoio, disponibilidade e incentivo prestados ao longo de todo o trabalho. Queremos também agradecer: - a todo o grupo do L 2 F, por todo apoio e disponibilidade prestados durante a execução do projecto, em especial aos Engenheiros Renato Cassaca, Márcio Viveiros, Hugo Meinedo, Sérgio Paulo; e ao Doutor David Matos. - a Klaus Bucher, responsável pelo port de Linux para Windows do publicvoicexml, pelo incansável apoio e disponibilidade demonstrados em todas as fases do projecto, e a Tobias Witek,Public Voice Lab, por toda a ajuda na compreensão e utilização do publicvoicexml. - ao Prof. António Grilo pela disponibilização do Laboratório de Telecomunicações da Torre Norte do Instituto Superior Técnico. Só assim foi possível o desenvolvimento de toda a plataforma num ambiente real de linhas RDIS. Ainda durante a preparação deste documento, foram várias as pessoas que de uma forma ou de outra, uma vezes com correcções outras com sugestões, ajudaram na sua revisão. Os autores deste projecto, gostariam de agradecer, em especial, a todas estas pessoas pelo seu contributo: Prof. João Paulo Neto, Margarida Mouta, Carla Mouta, Maria Inês Pinto, Mário Gírio. Por último queremos agradecer às nossas famílias pelo infindável e constante apoio durante a realização deste trabalho. Todo e qualquer erro presente neste documento é de única e exclusiva responsabilidade dos autores. Hugo Monteiro e Marco Mouta iii

4

5 Resumo Este projecto, desenvolvido no âmbito do trabalho final de curso da licenciatura em Engenharia Electrotécnica e de Computadores, visa a criação de uma plataforma autónoma e modular, capaz de estabelecer uma interface Homem-Máquina interactiva em Português Europeu. Este tipo de plataformas designam-se por IVR(Interactive Voice Response) e são habitualmente utilizadas em linhas de atendimento ao cliente de operadoras telefónicas, seguradoras, bancos, aeroportos, etc. As IVRs, ao possibilitarem uma interacção automática com o utilizador, permitem por um lado, uma redução de custos e um serviço permanente (24 horas) neste tipo de centros e, por outro, uma redução significativa do número de chamadas em fila de espera nas horas de ponta. Estas plataformas, estão habitualmente dotadas de sintetizador de fala e reconhecedor de DTMF(Dual Tone Multiple Frequency) possuindo também, em alguns casos, reconhecedores de fala. A utilização de reconhecedores de fala nestas plataformas tem por objectivo proporcionar ao utilizador uma comunicação o mais natural possível. Até há bem pouco tempo, as IVRs eram soluções proprietárias, i.e., uma vez instaladas e operacionais, tanto o hardware como o software utilizados pertenciam a um único fornecedor. Este tipo de soluções, proprietárias e chave na mão, acabam por se revelar soluções limitadas, na medida em que não é possível a um programador comum desenvolver novas aplicações. Para obviar estas e outras limitações e com o objectivo primordial da standardização de plataformas e aplicações de IVRs surgiu o VoiceXML, considerado actualmente pelo World Wide Web Consortium (W3C), como um standard que descreve diálogos interactivos usando XML (Extensible Markup Language) como base. A plataforma IVR desenvolvida neste projecto, é baseada em VoiceXML, i.e., a gestão dos diálogos Homem-Máquina é feita com base em documentos VoiceXML carregados na IVR. As IVRs baseadas em VoiceXML, apresentam necessariamente um módulo, designado por VoiceXML browser, que é responsável pela interpretação e execução das tags que compõem os documentos VoiceXML. Após uma análise dos diferentes browsers existentes no mercado, o VoiceXML browser escolhido para desenvolvimento deste projecto foi o publicvoicexml(pvx). Este browser, como projecto open-source que é, resulta do contributo de diferentes programadores espalhados por todo o mundo. Na sua versão original, ponto de partida para v

6 vi este projecto, o publicvoicexml (PVX) estava incompleto. Não contemplava o reconhecimento de fala, possibilitando apenas a sua síntese e o reconhecimento de DTMF. Neste contexto, e com o intuito de implementar uma interface Homem-Máquina em Português Europeu, procedeu-se à integração de dois motores no publicvoicexml: o Audimus para reconhecimento de fala e o DIXI para síntese de fala, ambos desenvolvidos no Laboratório de sistemas de Língua Falada (L 2 F), INESC ID Lisboa. A aplicação de voz VoiceXML desenvolvida neste projecto contempla o acesso a conteúdos Web, daí que, na arquitectura deste sistema, tenha sido integrado um módulo, designado por servidor Web, sobre qual foram desenvolvidas Servlets específicas. Por último, uma vez definida e implementada toda a arquitectura do sistema, desenvolveu- -se uma aplicação VoiceXML baseada em menus com três serviços distintos: Voice , previsão meteorológica e disponibilização de notícias com base na tecnologia RSS, Really Simple Syndication. De referir ainda que o desenvolvimento e teste deste projecto, com recurso à linha RDIS, foi realizado no Laboratório de Telecomunicações da Torre Norte do Instituto Superior Técnico. Palavras Chave Interactive Voice Response, VoiceXML, VoiceXML browser, publicvoicexml, reconhecimento de fala, síntese de fala.

7 Abstract This project was developed as a component of the Final Project towards the Bachelors Degree in Computer and Electro-techniques Engineering. It aimed to create an autonomous and modular platform capable of establishing an interactive Human-Machine interface in European Portuguese. This sort of platforms are designated as IVR (Interactive Voice Response), and are typically used in customer service phone lines such as those of telephone operators, insurances, banks, and airports. IVRs enable an automatic interaction with the customer and as such have two advantages. On the one hand, they require reduced numbers of operators. On the other, they also lower significantly the number of calls placed on hold during peak periods. IVR platforms are normally equipped with voice synthesizers and devices that recognize Dual Tone Multiple Frequency (DTMF) inputs, but in some cases they are also equipped with speech recognition devices. The incorporation of the latter in IVR platforms serves to provide the customer with an experience as close to natural as possible. Until very recently, the IVRs were proprietary solutions. In other words, once an IVR was installed and operational, both the hardware and the software became the property of a single provider. This type of solutions, proprietary and key in hand prove themselves limited in that a common programmer is not capable of developing new applications. To overcome these and other limitations and with the primary goal of standardizing IVR platforms and applications, VoiceXML was developed. Nowadays, VoiceXML is considered by the World Wide Web Consortium (W3C) as the standard, describing interactive dialogues using as XML (Extensive Markup Language) a base. The IVR platform that this project developed and described is based on VoiceXML. In other words, the management of the Human-Machine dialogues is based on VoiceXML documents loaded onto the IVR. The IVRs based on VoiceXML necessarily present a module, designated as VoiceXML browser, which is responsible for the interpretation and execution of the tags that make up the VoiceXML documents. After a careful analysis of the different browsers currently available, we chose publicvoicexml (PVX) as the VoiceXML browser for this project. PVX is an open-source project and as such it incorporates the contributions from different programmers spread throughout the world. In its original version, which was the starting point for this project, PVX was incomplete: it did not contemplate speech recognition, allowing only for speech synthesizing and recognition of DTMF inputs. With that in mind, and aiming to implement a Human-Machine interface in European vii

8 viii Portuguese, we proceeded to incorporate two speech engines onto the PVX: the Audimus for speech recognition and the DIXI for speech synthesis. Both the Audimus and the DIXI were developed by the Laboratório de Sistemas de Lingua Falada (L2F), INESC ID, in Lisbon. The VoiceXML application developed in this project contemplates the access to Web contents. Therefore, we integrated within the architecture of this system a module, designated as Web server, upon which specific Servlets were developed. Finally, once we had defined and implemented the complete system architecture, we developed a VoiceXML application based on menus with three separate services: Voice , Weather reports and availability to news reports based on RSS (Rich Site Summary) documents. It should be added that both the development and the testing of this project, which had access to the RDIS line asset, were done in the Laboratório de Telecomunicações da Torre Norte, of the Instituto Superior Técnico, Universidade Técnica de Lisboa. Keywords Interactive Voice Response, VoiceXML, VoiceXML browser,publicvoicexml, Automatic Speech Recognition, Text To Speech.

9 Índice Agradecimentos Resumo/Palavras chave Abstract/Key words Lista de Figuras Lista de Tabelas Lista de Siglas iii v vii xiv xv xvii 1 Introdução Objectivos Técnicas e Ferramentas utilizadas Organização do relatório Aspectos inovadores do trabalho Standards abertos VoiceXML Sistema implementado VoiceXML Potencialidades Construtores utilizados em VoiceXML Como funciona o algoritmo FIA Descrição funcional Servidor Web Análise de VoiceXML browsers ix

10 x ÍNDICE Ambiente de teste publicvoicexml VoiceGenie Genie IDE Version1.6 (Beta) Elvira OptimTalk IBM Voice Toolkit for Web Studio Conclusão publicvoicexml O VoiceXML browser Arquitectura do browser Módulos constituintes do browser Módulo Interpretador de VoiceXML Interface CAPI Cliente HTTP Módulo de Áudio Módulo de Sintetização de fala Descrição funcional Melhoramentos implementados no browser Integração do DIXI-Festival Integração de uma Hardware Interface-ASR Integração do módulo detector de Endpoint Implementação da funcionalidade: Ditado Desenvolvimento da aplicação portaudio publicvoicexml - modo local Arquitectura do Sistema Plataformas IVR Análise da plataforma Solução Implementada Módulos constituintes Descrição funcional Ambiente de desenvolvimento e teste

11 ÍNDICE xi 5 Aplicação VoiceXML Introdução Notícias Introdução Descrição Funcional Exemplo prático Voice Introdução Descrição funcional Navegabilidade Compositor de Exemplo prático Meteorologia Introdução Descrição Funcional Exemplo prático Bateria de testes sobre a aplicação Conclusão Principais resultados Análise crítica Trabalho futuro TFC O ponto de partida Bibliografia 61 Glossário 63 Lista de Anexos A publicvoicexml B Aplicação VoiceXML 73 C Artigos COST278 81

12

13 Lista de Figuras 1.1 IVR proprietário versus IVR baseada em VoiceXML Arquitectura base do sistema O elemento form Excerto de um documento VoiceXML Perguntas simplesvoicexml Ambiente de teste dos VoiceXML browser VoIP-CAPI introduzida para teste deste browser Arquitectura do publicvoicexml Lógica de funcionamento da interface CAPI Arquitectura do publicvoicexml Interface CAPI2.0 a implementar IVR tradicional IVR baseada em VoiceXML Microsoft Speech API-SAPI Arquitectura do Sistema Implementado Chamada estabelecida - Disponibilização de Serviços Resposta do utilizador - Processamento da opção Resposta do utilizador - Processamento da opção Arquitectura do sistema em ambiente RDIS Exemplo de um diálogo do serviço de notícias Arquitectura da aplicação e o seu enquadramento na sistema Início de Sessão xiii

14 xiv LISTA DE FIGURAS 5.4 Login Apresentação dos grupos que contêm s novos Apresentação do conteúdo do e opções seguintes Apresentação da previsão meteorológica para Lisboa B.1 Fluxograma da aplicação de Voz Voice ouvir B.2 Ficheiros dinâmicos VXML B.3 Ficheiros dinâmicos VXML cont B.4 Ficheiros dinâmicos VXML cont B.5 Ficheiros dinâmicos VXML cont B.6 Users.XML

15 Lista de Tabelas 2.1 Análise do publicvoicexml publicvoicexml2.6.1 Avaliação Análise do VoiceGenie Genie IDE Version1.6 (Beta) VoiceGenie Genie IDE Version1.6 (Beta) Avaliação Análise do Elvira OptimTalk Elvira OptimTalk Avaliação Análise do IBM Voice Toolkit for Web Studio IBM Voice ToolKit for Web Avaliação Vantagens e desvantagens de uma IVR baseada VoiceXML Descrição dos módulos constituintes da IVR Descrição dos módulos constituintes do servidor Web Exemplo tipo de organização de contactos Ficheiros de Log para debug xv

16

17 xvii Lista de Siglas DTMF Dual Tone Multiple Frequency W3C World Wide Web Consortium XML Extensible Markup Language IVR Interactive Voice Response VoiceXML Voice Extensible Markup Language VoiceXML browser Voice Extensible Markup Language browser PVX publicvoicexml INESC-ID Instituto de Engenharia de Sistemas e Computadores ID Lisboa RSS Really Simple Syndication L2F Laboratório de sistemas de Língua Falada RDIS Rede Digital com Integração de Serviços IT Tecnologias de Informação SAPI5.1 Microsoft Speech Application Programming Interface 5.1 DLL Dynammically Linked Library GSM Global System for Mobile Communication CAPI2.0 Common ISDN Application Programming Interface VoIP Voice over Internet Protocol GNU/GPL GNU General Public License TFC Trabalho Final de Curso TTS Text To Speech ASR Automatic Speech Recognition SDK Software Development Kit CVS Concurrent Versions Systems XHTML Extensible HyperText Markup Language OTF On the fly FIA Form Interpretation Algorithm PC Personal Computer

18

19 Capítulo 1 Introdução Neste capítulo, para além de uma perspectiva geral do problema em estudo neste projecto, serão apresentados, de forma sucinta, os problemas que surgiram ao longo do trabalho e as soluções encontradas para sua resolução. Será feita uma breve descrição do conteúdo e da estrutura do relatório e por último serão apresentados os aspectos inovadores da solução implementada. O Telefone, inventado em 1876 por Alexander Graham Bell e aperfeiçoado mais tarde por Bert e Arsonval, cedo se transformou no principal meio de comunicação entre as pessoas, continuando nos dias de hoje, a ser o principal canal de interacção entre empresas e clientes. No mundo actual, a Internet influencia e define cada vez mais a sociedade em que vivemos, dita as oportunidades de negócio, tornando-se um meio de comunicação de excelência onde novas oportunidades surgem constantemente. A Voz, faculdade de falar, surge então como elo de ligação entre a Internet e as redes telefónicas. Actualmente, com o rápido crescimento que tiveram quer as redes telefónicas quer as redes GSM(Global System for Mobile Communication) qualquer utilizador pode aceder à Internet a qualquer hora e em qualquer lugar. Para este tipo de utilizadores, em número cada vez maior, o Telefone é a Internet. É com base nesta realidade emergente e na evolução dos sistemas de reconhecimento e síntese de fala, que surge a necessidade de recorrer a plataformas autónomas capazes de estabelecer uma interface interactiva Homem-Máquina. Deste modo, consegue-se por um lado reduzir o número de pessoas necessário nos centros de atendimento telefónico, Call Center, e por outro um alisamento significativo do pico do número de chamadas em espera nas horas mais críticas. Até há bem pouco tempo, as plataformas IVR, baseadas em tecnologias proprietárias, eram a única solução, relevando-se difíceis de integrar com outros sistemas e apresentando uma interoperabilidade reduzida. Nos dias de hoje, com o crescimento exponencial da Internet, a realidade é outra. As prementes necessidades das empresas de, por um lado reduzir custos e por outro concretizar o desenvolvimento das suas plataformas, levaram à 1

20 2 Introdução criação de standards abertos. No caso concreto das IVRs, resultado de um esforço conjunto da AT&T, IBM, Lucent Technologies e Motorola, surgiu o VoiceXML, uma extensão do XML, criado para a descrição diálogos interactivos e consequente estandardização das plataformas. Para uma melhor compreensão dos dois tipos de plataforma referidos anteriormente, na figura 1.1 estão representadas as duas soluções: proprietárias e baseada em VoiceXML. Internet IVR Aplicação da IVR IVR -VoiceXML Aplicação em VoiceXML Interpretador de VoiceXML ECMAS script C/C++/Java API C/C++/Java API C/C++/Java API C/C++/ Java API C/C++/Java API C/C++/Java API ASR TTS Hardware - Software Interface Telefónica Microsoft SAPI5.1 Reconhecedor de fala Microsoft SAPI5.1 Sintetizador de Fala Hardware - Software CAPI 2.0 Interface Telefónica (a) PSTN v RDIS PSTN v RDIS (b) Figura 1.1: (a) Solução dita proprietário e (b) Solução baseada em VoiceXML É neste contexto que surge o projecto Desenho de IVRs para Operadoras Telefónicas. Este projecto tem como objectivo primordial o desenvolvimento, estudo e análise de uma plataforma IVR autónoma e modular, baseada em standards abertos como é o caso do VoiceXML. Pretende-se com a implementação desta plataforma, a criação de um ambiente de laboratório vocacionado para o desenvolvimento e teste de aplicações VoiceXML. Posteriormente, pretende-se ainda implementar, uma aplicação em VoiceXML baseada em menus capaz de mostrar todo o potencial do sistema, viabilizando a disponibilização de serviços, ditos Web services, ao utilizador da linha telefónica. 1.1 Objectivos Ainda antes de iniciar uma descrição específica, dos diferentes objectivos que tornaram possível a criação desta plataforma IVR, e na sequência do que foi dito anteriormente, é conveniente explicitar aqui, o que torna esta solução uma solução standard, autónoma e modular. Standard: uma vez que todos os seus módulos constituintes são baseados em standards abertos, como é o caso do VoiceXML. Autónoma: uma vez que funciona quer em ambiente de laboratório, através de uma interface no PC local, quer em ambiente dito real, utilizando a linha RDIS.

21 3 Modular: na medida em que, ao contrário do que acontece nas IVRs tradicionais, qualquer módulo é passível de ser substituído por outro equivalente, necessitando apenas que as especificações standard sejam cumpridas. Definidos estes conceitos, fundamentais para o desenvolvimento do projecto, e implementando a estratégia do dividir para conquistar, decompôs-se o objectivo principal do projecto implementação de uma plataforma IVR autónoma e modular em diversos objectivos intermédios: Definição do VoiceXML browser a utilizar Garantir a autonomia da plataforma Integração do reconhecedor de fala Audimus no browser Integração do sintetizador de fala DIXI no browser Integração de um servidor Web Desenvolvimento de uma aplicação VoiceXML No que concerne à concretização dos objectivos previamente definidos e face aos problemas/obstáculos surgidos, foram várias as soluções adoptadas: Definição do VoiceXML browser após uma análise dos diferentes browsers disponíveis no mercado, concluiu-se que a melhor solução passaria pela utilização do publicvoicexml (PVX). O PVX, como projecto open-source recente que é, na sua versão actual 1, não contempla a utilização de motores de reconhecimento de fala, possibilitando apenas o reconhecimento de DTMF e a síntese de fala com recurso a motores cumpram a especificação Microsoft Speech Application Programming Interface 5.1 (SAPI5.1). Autonomia da plataforma para garantir a autonomia da plataforma, e uma vez que o PVX na sua versão original funciona apenas através de uma interface telefónica (linha RDIS) foi desenvolvido um modo alternativo distinto de utilização do sistema. Este modo, designado por modo local, estabelece a interacção com o utilizador através da placa de som do PC. Integração do reconhecedor de fala no caso concreto do reconhecimento de fala, e porque a solução a desenvolver, queria-se autónoma e modular, foi criada uma interface, compatível com a especificação SAPI5.1, responsável pela comunicação entre o PVX e o motor de reconhecimento de fala. Deste modo, garantiu-se a integração imediata do reconhecedor de fala Audimus, desenvolvido no L 2 F INESC ID Lisboa e, simultaneamente, viabilizou-se a utilização de qualquer motor de reconhecimento de fala que cumpra a especificação SAPI disponível para download na SourceForge

22 4 Introdução Integração do sintetizador de fala para tornar possível a síntese de fala em Português Europeu, procedeu-se à integração do motor de síntese DIXI. Este motor, desenvolvido no L 2 F, na sua versão actual não cumpre a especificação SAPI5.1, condição necessária para integração na versão original do PVX, daí que tenha sido necessário proceder a algumas adaptações no browser. Não alterando a estrutura original da interface de comunicação com motores de síntese de fala do PVX, o DIXI foi integrado através de uma Dynammically Linked Library (DLL). Integração de um servidor Web para tornar possível o desenvolvimento de aplicações VoiceXML que contemplem o acesso a conteúdos Web, foi integrado no sistema um servidor HTTP da ACME. Para que a aplicação final do projecto pudesse disponibilizar ao utilizador serviços do tipo Web services foram desenvolvidas Servlets específicas, que correm neste servidor, responsáveis pela criação de documentos VoiceXML (VXML) dinâmicos. Desenvolvimento de uma aplicação VoiceXML tendo como objectivo final a demonstração de todo o potencial das tecnologias utilizadas neste projecto, reconhecimento e síntese de fala em Português Europeu numa plataforma IVR baseada em VoiceXML, foi desenvolvida uma aplicação VoiceXML baseada em menus com três serviços distintos: Voice , previsão meteorológica e disponibilização de notícias com base na tecnologia Really Simple Syndication (RSS). Uma vez apresentadas as diversas soluções desenvolvidas neste projecto, será conveniente ter uma percepção visual da solução implementada. Na figura 1.2, está representada a arquitectura base do sistema. Internet Utilizador VXML HTTP1.1 Base de Dados 1 Plataforma IVR baseada em VoiceXML Web Server Base de Dados n Figura 1.2: Arquitectura base do sistema 1.2 Técnicas e Ferramentas utilizadas Após uma análise da descrição feita na secção anterior e da figura 1.2, representativa da arquitectura base do sistema, é possível identificar as três áreas distintas que compõem este sistema: interface com o utilizador, plataforma IVR baseada em VoiceXML e acesso a conteúdos Web. É com base nestas três áreas distintas, que serão descritas e analisadas as diferentes técnicas e ferramentas utilizadas:

23 5 1. Plataforma IVR baseada em VoiceXML o publicvoicexml faz uso da linguagem de programação C e da linguagem de programação orientada por objectos C++ nos diversos módulos que o compõem. Daí que todo o trabalho de adaptação e desenvolvimento do browser tenha sido realizado nestas duas linguagens. (a) Motores de síntese e reconhecimento de fala: no que concerne às técnicas utilizadas para integração dos dois motores, estas são distintas. No caso do reconhecedor de fala, Audimus, foi adicionada ao browser uma nova classe, designada ASRWindows, desenvolvida segundo a especificação Microsoft Speech Application Programming Interface 5.1. Para o sintetizador de fala, DIXI, a integração foi realizada através de um DLL responsável pela disponibilização de dois entry points para comunicação. (b) Interface telefónica: a interface telefónica utilizada pelo PVX está implementada em C++ segundo a especificação Common ISDN Application Programming Interface (CAPI2.0). Neste contexto, todas as adaptações implementadas no browser, tanto a este nível como ao nível do desenvolvimento do modo local, tiveram por base um estudo e análise profundo desta especificação. 2. Interface com o utilizador ao nível da interface com utilizador, leia-se aplicações VoiceXML, a linguagem utilizada foi o VoiceXML2.0 fazendo uso em alguns casos específicos de Java Script. 3. Acesso a conteúdos Web tanto o servidor utilizado como interface de acesso a conteúdos Web, ACME server, como as Servlets desenvolvidas para criação de documentos VoiceXML dinâmicos fazem uso da linguagem de programação orientada por objectos Java. (a) Pacotes Java utilizados: - Java Servlet Technology: utilizado para implementação de servlets. - Java Mail API : utilizado como plataforma base para disponibilização de acesso ao . - Java Beans Activation Framework: utilizada para determinar o tipo de conteúdo do . - Java API for XML Processing: utilizada para processamento de documentos XML. - JDBC API : utilizado no acesso a base de dados. - com.sun.cnpi.rss: utilizado para acesso a documentos disponibilizados via Really Simple Syndication (RSS). (b) Documentos XML: para disponibilização do acesso a conteúdos Web específicos, como é o caso do , é utilizado um ficheiro users.xml no qual estão armazenados dados específicos de cada utilizador do sistema. A referir: o nome do utilizador, o seu endereço , os seus grupos de contactos e respectiva identificação de cada elemento do grupo.

24 6 Introdução 1.3 Organização do relatório Este relatório reporta-se ao Trabalho Final de Curso (TFC), n o 119, do ano lectivo 2004/2005. Intitulado Desenho de IVRs para Operadoras Telefónicas, nele se reporta todo trabalho realizado com vista à implementação de uma plataforma IVR autónoma, modular e baseada em standards abertos. O relatório está organizado em seis capítulos e três anexos: Capítulo 1 Introdução Neste capítulo, para além de uma perspectiva geral do problema em estudo neste projecto, são apresentados, de forma sucinta, os problemas que surgiram ao longo do trabalho e as soluções encontradas para sua resolução. É apresentada uma breve descrição do conteúdo e da estrutura do relatório e por último são apresentados os aspectos inovadores da solução implementada. Capítulo 2 VoiceXML Neste capítulo é feita uma apresentação da linguagem VoiceXML e é apresentado o seu enquadramento no desenvolvimento deste projecto. Capítulo 3 publicvoicexml Ao longo deste capítulo são apresentados os módulos constituintes do VoiceXML browser bem como o seu princípio de funcionamento. Por fim, são explicadas as diversas implementações que tornam possível a utilização do publicvoicexml com síntese e reconhecimento de fala em Português Europeu. Capítulo 4 Arquitectura do sistema Neste capítulo é apresentada e analisada, em detalhe, toda a arquitectura do sistema e seus elementos constituintes. Capítulo 5 Aplicação Ao longo deste capítulo é descrita e analisada aplicação VoiceXML implementada. Esta aplicação, baseada em menus, disponibiliza os seguintes serviços: Voice , Meteorologia e disponibilização de notícias com base na tecnologia RSS Conclusão 6 Conclusão Por último é apresentado e criticado o desempenho da plataforma IVR criada. São também apresentados desenvolvimentos passíveis de ser implementados no futuro tendo em vista o acréscimo de funcionalidades e/ou aplicações. Anexo I publicvoicexml Documentação técnica relativa ao VoiceXML browser considerada relevante. Anexo II Aplicação VoiceXML Fluxogramas da aplicação baseada em menus com os serviços de: Voice , Meteorologia e disponibilização de notícias com base na tecnologia RSS.

25 7 Anexo III Artigos COST278 Artigos escritos no decorrer do TFC, no âmbito do projecto COST278-SDS: Spoken Language Interaction in Telecommunication. 1.4 Aspectos inovadores do trabalho Nesta secção, pretendem-se apresentar os aspectos inovadores do trabalho apresentado neste relatório. Antes de mais importa referir que, no que concerne ao desenvolvimento de plataformas IVR baseadas em standards abertos, este é o primeiro projecto realizado no L 2 F, INESC ID Lisboa. Assim, a análise dos aspectos inovadores do trabalho, será feita não com base em projectos de anos anteriores, mas sim tendo como referência o panorama actual das soluções IVR comercializadas e as mais valias inerentes à implementação de sistemas abertos Standards abertos VoiceXML O VoiceXML, como standard aberto que é, apresenta-se no mercado como um protocolo aberto, universal, vocacionado para o desenvolvimento de aplicações de voz que utilizam motores de síntese e reconhecimento de fala. Como referência que é, no que concerne a nova geração de plataformas IVR, o VoiceXML apresenta inúmeras vantagens. A referir: Portabilidade: uma vez criadas as aplicações VoiceXML podem ser corridas em qualquer plataforma IVR VoiceXML, independentemente do tipo de hardware, do tipo de ligação telefónica e do sistema operativo. Modularidade: uma vez criadas as aplicações VoiceXML, ao contrário das soluções proprietárias, podem ser utilizadas com novos motores de reconhecimento e síntese de fala. Acesso a conteúdos Web: acedendo à Web através do protocolo HTTP as aplicações VoiceXML, viabilizam a disponibilização de conteúdos Web ao utilizador. Contrariamente às IVRs tradicionais, que adoptam soluções proprietário, a nova geração de plataformas IVR VoiceXML, baseando-se em standards abertos, não só estimulam a inovação, como promovem a colaboração entre programadores de aplicações de voz Sistema implementado Os aspectos inovadores do sistema implementado dividem-se em duas áreas distintas: o VoiceXML browser utilizado e a aplicação criada.

26 8 Introdução VoiceXML browser o publicvoicexml é um browser completamente desenvolvido em ambiente open-source e, como tal, baseado em standards. Para além destas características, por si só inovadoras no que respeita a plataformas IVR, existe ainda um outro aspecto relevante a apresentar: a interface telefónica de comunicação com o browser. A este nível, e porque a comunicação de Voz sobre IP (VoIP) é um factor de relevo cada vez maior no mundo das telecomunicações, é conveniente aqui referir que, quer no desenrolar deste TFC quer em outros artigos publicados, foi já reportada a possibilidade de comunicar com o browser por VoIP, ao invés da habitual linha telefónica. Em ambos os casos as experiências foram realizadas recorrendo a uma virtual ISDN-Card VoIP-CAPI software proprietário da Ikon-GmbH. Prevê-se que num futuro próximo VoIP seja uma realidade integrada no browser. VoIP support is under development... publicvoicexml project, in SourceForge Aplicação VoiceXML a aplicação VoiceXML criada baseada em menus, disponibiliza ao utilizador três tipos de serviços distintos: Voice , previsão meteorológica e disponibilização de notícias com base na tecnologia RSS. Qualquer um dos serviços apresentados é inovador no que respeita à disponibilização de serviços para IVRs. No entanto, e devido ao crescimento exponencial que a Internet apresenta nos dias de hoje, convém aqui salientar os aspectos inovadores dos serviços Voice e Notícias. Voice neste serviço em que é disponibilizado ao utilizador o acesso ao , usando reconhecimento de fala, são apresentadas as opções de: consulta, resposta, composição de . Notícias a informação apresentada ao utilizador é obtida acedendo a Web sites que disponibilizam informação actualizada, via RSS.... Really Simple Syndication, que consiste numa maneira fácil de saber se um determinado site, de notícias por exemplo, tem novas notícias sem ter que aceder ao site em questão. in TSF rádio notícias

27 Capítulo 2 VoiceXML Neste capítulo apresentar-se-á a linguagem utilizada para a gestão de diálogos da plataforma IVR desenvolvida neste projecto. Considerada actualmente pelo World Wide Web Consortium (W3C) como um standard para o desenvolvimento de plataformas IVR, a linguagem VoiceXML, é um elemento essencial na criação de interfaces Homem-Máquina. 2.1 Potencialidades O VoiceXML foi pensado e desenvolvido tendo por base a necessidade crescente da criação de interfaces interactivas Homem-Máquina. Estas interfaces caracterizam-se por estarem dotadas de síntese e reconhecimento de fala, reconhecimento de DTMF e gravação do áudio proveniente do utilizador. Uma correcta gestão e articulação destes recursos torna possível o estabelecimento de diálogos entre o utilizador e a plataforma. O principal objectivo do VoiceXML, uma vez que disponibiliza o acesso a conteúdos Web nas suas aplicações, é trazer para os utilizadores da linha telefónica e GSM o enorme potencial da Internet 1 e libertar os programadores deste tipo de aplicações, das linguagens ditas baixo-nível e das interfaces com Hardware. O VoiceXML é responsável por todo o controlo dos diálogos entre a aplicação e o utilizador. O facto dos documentos VoiceXML poderem ser acedidos num servidor Web, do mesmo modo que um documento HTML, possibilita a estas aplicações aproveitar todo o potencial das tecnologias Web. Com um número estimado de cerca de dois biliões de utilizadores de linha telefónica e telefone móvel em todo o mundo, o VoiceXML permitirá, a um número de utilizadores sem precedente, a interacção com os chamados Web services através de ordens faladas, síntese de fala e DTMF. 1 i.e. Voic , previsão meteorológica, transferência de chamadas, consulta de bolsa,etc. 9

28 10 VoiceXML 2.2 Construtores utilizados em VoiceXML Os dois principais construtores utilizados no desenvolvimento de aplicações VoiceXML são o form e o menu. Enquanto que o form é utilizado para solicitar uma resposta ao utilizador, o menu convida o utilizador a fazer uma escolha perante um conjunto limitado de opções. Para uma melhor compreensão do princípio de funcionamento do VoiceXML apresentar-se-á mais detalhadamente o construtor form. No entanto ambos os construtores são utilizados. <form> <link> <filled> <grammar> form.item event.handler <grammar> executable.content <script> <property> <filled> Figura 2.1: O elemento form Os elementos form num documento VoiceXML são interpretados segundo um algoritmo específico denominado por FIA(Form Interpretation Algorithm). Existem dois tipos de form items: - items de entrada: <field> - items controlo: <block> Os chamados items de entrada, indicam ao FIA a necessidade de obter um resultado para um elemento específico, enquanto que os items de controlo indicam ao FIA para executar um determinado bloco de código. Um item de entrada especifica necessariamente uma variável para armazenamento do respectivo input. (e.g. cidade="lisboa"). De seguida apresentam-se os diferentes items de entrada: - field: declaração de um campo a preencher no VoiceXML form. - subdialog: invoca um outro diálogo VoiceXML como um subdiálogo. - record: dá início a uma gravação de áudio. - transfer: transfere uma chamada telefónica para um determinado número. - object: interage com uma extensão específica.

29 11 Existem dois tipos diferentes de items de controlo: block e initial. Enquanto que o block é responsável pela execução de uma sequência de procedimentos, o initial é responsável pelo início de uma interacção conjunta com o utilizador, i.e com o item initial é realizada uma pergunta ao utilizador em cuja resposta se pretende obter mais do que uma informação (e.g. Por favor diga-nos o seu nome, e a sua idade). <initial name="myinit"> <prompt> Bem vindo ao sistema. Por favor diga-nos o seu nome, e a sua idade </prompt> <nomatch count="1"> <prompt> Ok, passemos a uma pergunta de cada vez. </prompt> <assign name="myinit" expr="true"/> <reprompt/> </nomatch> Figura 2.2: Excerto de um documento VoiceXML Este tipo de interacção é realizado com o item initial, caso ao fim de um número predefinido de vezes, o sistema perceba que não está a conseguir obter toda a informação que pretende do utilizador, tem então início um conjunto de perguntas simples com o mesmo objectivo. <field name="nome"> <prompt>qual o seu nome?</prompt> <grammar src="nomes.grammar#nomes" type="text/gsl"/> </field> <field name="idade"> <prompt>qual a sua idade?</prompt> <grammar src="nomes.grammar#idade" type="text/gsl"/> </field> Figura 2.3: Perguntas simplesvoicexml Em resumo, um documento VXML é composto por forms e menus, sendo executado como uma aplicação isolada. A sua execução inicia-se no primeiro diálogo e, nesta mesma execução é determinado o diálogo seguinte a processar. Se a aplicação não especificar qual o diálogo seguinte a processar, a execução do documento pára.

30 12 VoiceXML 2.3 Como funciona o algoritmo FIA Um documento VoiceXML é geralmente constituído por diversos elementos form. Estes elementos são interpretados segundo um algoritmo específico, como já foi referido anteriormente, designado por Form Interpretation Algorithm (FIA). Este algoritmo é composto por um ciclo principal em que : - selecciona um item form. - visita o item escolhido. O form é seleccionado por ordem no documento. A interpretação de um form geralmente envolve: - seleccionar e reproduzir ao utilizador um ou mais prompts. - obtenção da resposta utilizador ou despoletar um evento. - interpretar as acções contidas no elemento <filled> O algoritmo FIA termina quando: - este interpreta o comando de transferência de controlo, e.g <submit>. - não existem mais elementos form para seleccionar. 2.4 Descrição funcional A arquitectura típica utilizada para aplicações VoiceXML é composta por uma plataforma IVR, um servidor Web e bases de dados (ver fig.1.2). A plataforma IVR é constituída por um VoiceXML browser e uma interface entre o browser e a linha telefónica. O VoiceXML browser é responsável pela interpretação dos documentos VoiceXML e pela síntese e reconhecimento de fala. Quando o utilizador estabelece uma chamada é-lhe apresentado um menu de falado. Neste momento, o utilizador responde com a sua fala. De seguida a sua resposta é entregue ao reconhecedor de fala que traduz o áudio para texto passível de ser processado pelo browser. Caso a acção a despoletar pelo browser não necessite de conteúdos externos, i.e. aceder à Internet, então é simplesmente apresentada uma resposta ao utilizador, tendo por base o documento VoiceXML em questão ou noutro alojado na máquina onde corre a IVR. Nestes casos trata-se de informação proveniente de documentos VoiceXML estáticos. Por outro lado, caso a acção a despoletar pelo browser necessite de aceder à Internet, então o browser expede ao servidor Web um pedido de um conteúdo específico. O servidor Web, por sua vez processa a sua lógica de funcionamento acedendo às suas bases de dados ou à Internet, de modo a obter a resposta ao pedido do cliente. De seguida, o servidor (através de CGI scripts, Java servlets, ASPs, etc) gera a resposta para o pedido

31 13 em questão, num documento VoiceXML dinâmico baseado em templates predefinidos e nos dados obtidos. O documento gerado é enviado ao VoiceXML browser que, recorrendo ao sintetizador de fala, o apresenta ao utilizador. Este ciclo repete-se até que a chamada termine, compondo assim a lógica de funcionamento de aplicações VoiceXML. De referir ainda que, embora o tipo de mecanismos disponíveis para as aplicações VoiceXML acederem a dados seja o mesmo das aplicações Web, o modo como a informação é apresentada ao utilizador é bastante diferente. Esta apresentação deverá ser feita de forma sintética e dividida em troços de fácil audição e compreensão, viabilizando assim a comunicação Homem-Máquina. 2.5 Servidor Web Como já foi referido anteriormente, este tipo de sistemas baseados em VoiceXML, fazem uso de um servidor Web para disponibilização de conteúdos Web às aplicações VoiceXML propriamente ditas. Nestes casos, em que as aplicações VoiceXML acedem a conteúdos Web, o VoiceXML browser funciona do mesmo modo que um Visual browser. A diferença reside apenas no facto de que o VoiceXML browser necessita de, por um lado verbalizar os conteúdos para apresentação ao utilizador, e por outro aceitar respostas faladas, ao invés da típica interacção através de teclado e ou rato. De referir ainda que, no caso das aplicações VoiceXML, os servidores Web utilizados, são servidores especialmente vocacionados para serviços de Voz, na medida em que recebem pedidos HTTP do VoiceXML browser e como resposta entregam documentos VoiceXML. Daí que, este módulo servidor Web seja de extrema importância para a plataforma IVR, como se poderá constatar ao longo deste relatório. Neste contexto, sendo explícita a necessidade de integração de um servidor Web no sistema a desenvolver, optou-se pela utilização de um servidor com a tecnologia servlet. O emprego de Java servlet deve-se não só à grande eficiência que esta disponibiliza, mas também à facilidade que proporciona na gerência de conteúdos dinâmicos. Dos diferentes servidores disponíveis no mercado, foram testados dois: o Java 2 Plataform, enterprise edition (J2EE) e o ACME Web server desenvolvido pela ACME Laboratories open source. Após uma série de experiências utilizando servlets e uma análise crítica dos resultados obtidos concluiu-se que o J2EE, para além de implementar a totalidade da API servlet, implementa também aplicações extra, consideradas desnecessárias para este projecto. Relativamente ao ACME Web server, constata-se que este implementa apenas o essencial da tecnologia servlet, tornando-se uma solução mais versátil e mais leve no que concerne a consumo dos recursos do computador. Devido à crescente complexidade do sistema a desenvolver, que se quer o mais modular e autónomo possível, e de forma a viabilizar a instalação do servidor Web em qualquer tipo de máquina, mesmo de recursos limitados, concluiu-se que a melhor solução seria a utilização do ACME Web server.

32 14 VoiceXML De salientar também que, o facto deste servidor Web ser open source foi levado em conta no processo de selecção do servidor Web a utilizar. Deste modo procurou-se também, salvaguardar a hipótese de, durante o projecto, surgir algum problema que obrigasse a alguma alteração a nível interno do servidor Web. Uma vez definido o servidor Web, é possível agora prosseguir para a próxima fase deste projecto: a escolha do VoiceXML browser a integrar na plataforma IVR. 2.6 Análise de VoiceXML browsers Após uma primeira fase de estudo e análise da linguagem VoiceXML, e com o intuito de seleccionar o VoiceXML browser a integrar na plataforma IVR, foram analisados 2 diferentes browsers disponíveis no mercado. Características principais analisadas: Disponibilidade do código fonte. Velocidade de processamento/peso computacional. Licenças dos pacotes e o seu estado de desenvolvimento. Cumprimento da norma VoiceXML2.0. Interfaces de comunicação com os motores de fala. Interface de comunicação com o utilizador. Gramáticas suportadas. Com base nestas características, foi realizada uma pesquisa exaustiva sobre os VoiceXML browsers disponíveis no mercado. Desta pesquisa, e porque a solução a desenvolver neste projecto se pretendia standard, autónoma e modular, resultaram os seguintes browsers: - Elvira - Optim Talk - IBM Voice ToolKit for Web - publicvoicexml VoiceGenie - Genie IDE version1.6 (Beta) Posteriormente foi desenvolvido um ambiente de teste específico para análise e teste dos diferentes browsers. Será apresentado de seguida o ambiente de teste criado e posteriormente uma descrição detalhada da análise feita, dando especial ênfase aos pontos fortes e pontos fracos de cada browser. 2 Análise realizada durante a fase inicial da realização deste TFC Setembro de À data actual, uma vez que esta área tem apresentado um grande desenvolvimento tecnológico, é possível que alguma das caraterísticas apresentadas se encontre desactualizada

33 Ambiente de teste Procurando tirar o máximo partido dos browsers em análise nesta secção, uma vez que se pretende seleccionar o VoiceXML browser a integrar na plataforma IVR do projecto, desenvolveu-se o ambiente de teste representado na figura 2.4. Para a simulação de um VoiceXML browser HTTP1.1 VoiceXML Web server Meteorologia Internet Base de dados Figura 2.4: Ambiente de teste dos VoiceXML browser serviço a disponbilizar ao utilizador, reutilizou-se o código de um projecto anteriormente desenvolvido no L 2 F, Ambrósio- Um Mordomo Virtual, referente ao serviço Meteo um sistema previsão meteorológica desenvolvido em Português Europeu. Neste ambiente pretende-se testar em cada browser o acesso a conteúdos Web. Em caso de sucesso será possível através do browser em teste obter a informação meteorológica para as cidades principais de Portugal. A informação a apresentar ao utilizador, nesta fase de teste, não é mais do que a temperatura para a cidade seleccionada. Esta informação é obtida através do parser de um site da Internet. O suporte escolhido para este controlador foi a base de dados MySQL. De referir que, o serviço Meteo foi adaptado à situação presente, i.e., isolou-se o dispositivo de forma a que a comunicação se realizasse através de servlets. Para tornar possível a comunicação entre o serviço Meteo e a servlet, responsável pela geração de documentos VoiceXML dinâmicos e comunicação com o browser em teste, foi necessário remover a interface de comunicação que este apresentava, redireccionando toda a informação para a servlet publicvoicexml2.6.1 Proveniente de um projecto open source disponível no CVS (Concurrent Versions Systems) da SourceForge, este VoiceXML browser foi compilado recorrendo ao Microsoft Visual Studio 7.0. Para que a análise do browser fosse possível foi necessário contactar Tobias Witek 3, visto que a versão disponível no CVS não estava completa. Convém também referir o precioso 3 programador pertencente ao projecto publicvoicexml

34 16 VoiceXML contributo de Klaus Bucher 4 para a obtenção e compilação das diversas bibliotecas das quais o projecto faz uso. Tabela 2.1: Análise do publicvoicexml2.6.1 Características Código fonte: Open source SourceForge. Licenças: GNU/GPL license. Norma VoiceXML2.0: Não cumpre a norma a 100%. Gramáticas: JSGF grammars. Barge-in: DTMF. Interface com o sintetizador de fala: Microsoft SAPI5.1, Festival. Interface com o reconhecedor de fala: Não está implementada. Interface telefónica: CAPI2.0, implementação de VoIP possível. Plataformas: Microsoft Windows (98/NT/2000/XP), Linux. Uma vez que no L 2 F o acesso à linha RDIS não está disponível, condição necessária para comunicação com o browser, foi necessário recorrer a uma Virtual ISDN Card para proceder ao seu teste no ambiente anteriormente referido. Para este efeito foi contactada a empresa Ikon-GmbH( para que fosse disponibilizada em versão de demonstração uma VoIP-CAPI, Voice over IP-Common ISDN interface. Internet VoIP -CAPI Figura 2.5: VoIP-CAPI introduzida para teste deste browser As experiências realizadas com este VoiceXML browser apresentam a seguinte lógica de funcionamento: 1. A chamada é iniciada pelo cliente Netmeeting, tendo como destino o IP da máquina na qual se encontra a correr o publicvoicexml com a layer VoIP-CAPI instalada. 2. publicvoicexml atende a chamada e inicia-se a interpretação do ficheiro VXML. 3. O áudio gerado no sintetizador de fala, com base no ficheiro VXML, chega com sucesso ao cliente. 4 responsável pelo port do publicvoicexml de Linux para Windows

35 17 Avaliação do browser Com o intuito de definir qual o VoiceXML browser a integrar na plataforma IVR a desenvolver, foram realizados diferentes testes: - Desenvolvimento de ficheiros VXML de forma a testar as principais tags da especificação VoiceXML Operabilidade do módulo com um servidor Web VXML (Meteo). - Operabilidade do módulo com o NetMeeting fazendo uso de uma interface VoIP- CAPI. Tabela 2.2: publicvoicexml2.6.1 Avaliação publicvoicexml2.6.1 Open source. Interface com o motor de síntese de fala SAPI5.1 e Festival. Gramáticas In line grammars e external grammars (JSGF) - versão light. Pontos Fortes Implementa as funcionalidades de barge-in para DTMF. Licença GNU/GPL license. Interface telefónica CAPI2.0 Linha RDIS. Implementação de VoIP possível. Pontos Fracos Não cumpre a norma VoiceXML na sua totalidade. Não tem interface para desenvolvimento de ficheiros VXML. Reconhecimento de fala não está implementado. Terminação de chamada caso o ficheiro VXML seja inválido sem identificação do erro. Apesar dos problemas existentes na comunicação de áudio entre o utilizador e o browser, as tags principais da especificação VoiceXML2.0 apresentam-se implementadas; a salientar: form, field, block, prompt, submit, var, record, menu, goto, grammar, etc. A comunicação com o servidor Web (Meteo) foi realizada com sucesso. De referir no entanto que durante a realização destes testes (VoIP), apesar do áudio chegar correctamente ao cliente, o mesmo não se passou no sentido inverso, i.e. o áudio gravado proveniente do cliente não chegava correctamente ao VoiceXML browser VoiceGenie Genie IDE Version1.6 (Beta) Disponível apenas na sua versão de demonstração, este VoiceXML browser da VoiceGenie apresenta um ambiente gráfico para desenvolvimento de aplicações VXML bastante completo: editor de documentos VoiceXML com validação, debug passo a passo da aplicação, etc.

36 18 VoiceXML Tabela 2.3: Análise do VoiceGenie Genie IDE Version1.6 (Beta) Características Código fonte: Privado. Licença: Privada. Norma VoiceXML2.0: Não cumpre a norma a 100%. Gramáticas: In line grammars e external grammars. Barge-in: DTMF. Interface com o sintetizador de fala: Microsoft SAPI5.1. Interface com o reconhecedor de fala: Indisponível na versão demonstração. Interface: PC Local, input através do teclado. Plataformas: Microsoft Windows (98/NT/2000/XP). Este browser apresenta grandes potencialidades no que respeita ao desenvolvimento de aplicações VoiceXML, no entanto está limitado pelo facto de, na versão demonstração, a interface de input do utilizador cingir-se apenas ao teclado. Importa também referir que a versão demonstração expira ao final de noventa dias. Avaliação do browser Com o intuito de definir qual o VoiceXML browser a integrar na plataforma IVR a desenvolver foram realizados diferentes testes: - Desenvolvimento de ficheiros VXML de forma a testar as principais tags da especificação VoiceXML Operabilidade do módulo com um servidor Web VXML (Meteo). Tabela 2.4: VoiceGenie Genie IDE Version1.6 (Beta) Avaliação VoiceGenie - Genie IDE version1.6 (Beta) Interface com o motor de síntese de fala SAPI5.1. Pontos Fortes Suporta gramáticas In line grammars e external grammars. Interface para desenvolvimento e validação de ficheiros VXML. Barge-in: DTMF e fala. Pontos Fracos Não é open source. Licença é privada. Não cumpre a norma VoiceXML na sua totalidade. SDK não disponível. Reconhecimento de fala não é possível na versão demo. Na versão demo a interface de comunicação é concretizada através do teclado e colunas do PC local (versão demo). Apesar da limitação na interface com o utilizador referida anteriormente, as tags principais da especificação VoiceXML2.0 apresentam-se implementadas; a salientar: form, field, block, prompt, submit, var, record, menu, goto, grammar, etc.

37 19 A comunicação com o servidor Web (Meteo) foi realizada com sucesso Elvira OptimTalk Disponível para download no website da Optimtalk, este browser disponibiliza uma interface local de comunicação com o utilizador, fazendo uso de microfone e colunas. De fácil e rápida instalação, apresenta-se como uma solução bastante interessante tanto para quem nunca teve contacto com browsers VoiceXML, como para quem desenvolve e testa aplicações. Tabela 2.5: Análise do Elvira OptimTalk Características Código fonte: Open Source. Licença: Privada. Norma VoiceXML2.0: Não cumpre a norma a 100%. Gramáticas: In line grammars e external grammars. Código fonte: Privado. Barge-in: DTMF e fala. Interface com os motores de fala: Microsoft SAPI5.1. Interface: PC local. Plataformas: Microsoft Windows (98/NT/2000/XP) Avaliação do browser Com o intuito de definir qual o VoiceXML browser a integrar na plataforma IVR a desenvolver, foram realizados diferentes testes: - Desenvolvimento de ficheiros VXML de forma a testar as principais tags da especificação VoiceXML Operabilidade do módulo com um servidor Web VXML (Meteo). A única limitação encontrada prende-se com o facto da interface de comunicação com o utilizador ser local. As tags principais da especificação VoiceXML2.0 apresentam-se implementadas; a salientar: form, field, block, prompt, submit, var, record, menu, goto, grammar, etc. A comunicação com o servidor Web (Meteo) foi realizada com sucesso.

38 20 VoiceXML Tabela 2.6: Elvira OptimTalk Avaliação Elvira - Optim Talk Aplicação para validar a estrutura dos documentos vxml proporcionando uma descrição detalhada sobre o problema (i.e. linha e coluna do erro). Open source. Pontos Fortes Interface com os motores de síntese e reconhecimento de fala SAPI5.1. Suporta gramáticas In line grammars e external grammars (JSGF). Barge-in: DTMF e fala. Pontos Fracos Não cumpre a norma VoiceXML na sua totalidade. Licença é privada. SDK não disponível. Na versão demonstração a interface de comunicação é realizada através do microfone e colunas do PC local IBM Voice Toolkit for Web Studio Ao contrário dos restantes browsers, o módulo da IBM apresenta-se como um Multimodal browser, i.e. um browser que interpreta e executa aplicações Multimodal em que existe simultaneamente interface de Voz baseada em VoiceXML e interface gráfica, baseada em XHTML. Este tipo de aplicações, pode ser utilizado quer através de interfaces telefónicas, quer através de interfaces gráficas. Quer isto dizer, a mesma aplicação é utilizada através de um telefone como através de um PC. Tabela 2.7: Análise do IBM Voice Toolkit for Web Studio Características Código fonte: Licença: Norma: Gramáticas: Código fonte: Barge-in: Sintetizador de fala: Reconhecedor de fala: Interface: Plataformas: Privado. Privada. VoiceXML + XHTML. In line grammars e external grammars. Privado. DTMF e fala. Microsoft SAPI5.1. Microsoft SAPI5.1. PC local. Microsoft Windows (98/NT/2000/XP) Avaliação do browser Este pacote requer a instalação prévia WebSphere Studio. Sendo este um pacote da ordem dos Gigabytes e cujas licenças teriam que ser compradas à IBM, optou-se por realizar apenas alguns testes na interface Web disponibilizada no Website da IBM. Pelo facto deste browser não se enquadrar nas necessidades do projecto, optou-se pelo estudo e análise de outros browsers.

39 21 Tabela 2.8: IBM Voice ToolKit for Web Avaliação IBM Voice ToolKit for Web Pontos Fortes Interface que possibilita validar a estrutura dos documentos vxml proporcionando uma descrição detalhada sobre o problema (i.e. linha e coluna do erro). Interface com os motores de síntese e reconhecimento de fala SAPI5.1. SDK disponível. Cumpre a norma VoiceXML + XHTML. Suporta gramáticas In line grammars e external grammars. Barge-in: DTMF e fala. Pontes Fracos -Não é open source. Elevado consumo dos recursos do computador. Licença é privada. Na versão demo a interface de comunicação é concretizada através do microfone e colunas do PC local (versão demo). 2.7 Conclusão Feita a análise individual de cada browser e, ponderados os prós e os contras de cada um, concluiu-se que o VoiceXML browser a utilizar neste projecto seria o publicvoicexml Apesar deste browser não se apresentar como a solução mais simples e completa, apresentava características que o distinguiam de todos os outros: - Projecto Open Source. - Demonstrava potencial futuro de integração de comunicação VoIP. - Apresentava interface telefónica potenciando o teste do projecto num ambiente real. - Peso computacional médio. - Licença GNU. - Integração de reconhecimento de fala apresentada como desejável na SourceForge. Após esta primeira fase de estudo, análise e selecção do VoiceXML browser a utilizar como ponto de partida para o desenvolvimento da plataforma IVR, foram definidos objectivos intermédios para que o objectivo principal do projecto pudesse ser uma realidade. Nos capítulos seguintes, é apresentado em detalhe todo o restante trabalho desenvolvido. Ao longo deste relatório vão ser descritas todas as melhorias que foram introduzidas neste módulo.

40

41 Capítulo 3 publicvoicexml Ao longo deste capítulo serão analisados detalhadamente os módulos constituintes do VoiceXML browser e, apresentado o seu princípio de funcionamento. Por fim, serão apresentadas as melhorias implementadas no browser que tornam possível a síntese e o reconhecimento de fala em Português Europeu. 3.1 O VoiceXML browser Ainda antes de iniciar a análise do browser, é importante aqui referir que,apesar de no ponto 2.7 do capítulo anterior se ter optado pelo publicvoicexml2.6.1, a versão do browser, a utilizar para desenvolvimento da plataforma IVR, é mais recente. Trata-se da versão 3.0. A modularidade conseguida nesta versão e as consequências que advêm desse facto, maior facilidade de integração de novas extensões e uma estabilidade superior, foram factores preponderantes para esta alteração. O publicvoicexml apresenta-se como elo de ligação entre os scripts de VoiceXML e o telefone. Se por um lado, estes scripts providenciam toda a lógica de funcionamento da plataforma IVR, por outro, o browser é responsável pela execução das VoiceXML tags ao nível do sistema operativo, e.g., dar início à escrita no disco quando a tag record é executada, procedendo assim à gravação do áudio da chamada. Para carregar e interpretar os scripts de VoiceXML, o publicvoicexml faz uso do do seu módulo interno OpenVXI. No que diz respeito à interface entre o browser e a linha telefónica, como já foi referido anteriormente, esta é implementada através do protocolo CAPI2.0. No ponto deste capítulo, esta interface será explicada e analisada mais detalhadamente. No que diz respeito à interacção com o utilizador, o publicvoicexml3.0 recorre a dois módulos distintos: sintetizador de fala e reconhecedor de DTMF. 23

42 24 publicvoicexml 1. Sintetizador de fala: responsável pela conversão de texto para fala, armazenando o resultado da conversão num ficheiro de áudio que posteriormente é reproduzido na linha telefónica. 2. Reconhecedor de DTMF: é responsável pelo reconhecimento das teclas pressionadas no telefone pelo utilizador da chamada em curso. 3.2 Arquitectura do browser Para uma melhor compreensão do modo de funcionamento do publicvoicexml é conveniente a visualização da figura 3.1. Linha Telefónica 1 Input Controller Thread Linha Telefónica 2 CAPI driver Conversor de Áudio Lei A «Wav Output Controller Thread Dados da sessão estabelecida VoiceXML Função Callback HTTP Client Handler HTTP 1.1 VXML Linha Telefónica N Reconhecedor DTMF Sintetizador de fala Microsoft SAPI5.1 Interpretador de VoiceXML OpenVXI Figura 3.1: Arquitectura do publicvoicexml3.0 Analisando a figura 3.1, é possível distinguir com clareza os diferentes módulos que compõem o browser. Nas secções seguintes serão analisados com maior detalhe cada um dos módulos, bem como o princípio lógico de funcionamento do PVX. 3.3 Módulos constituintes do browser Nesta secção serão analisados os principais módulos que compõem o publicvoicexml cujas funções são essenciais para a compreensão da lógica de funcionamento do browser Módulo Interpretador de VoiceXML O OpenVXI é uma biblioteca open source, desenvolvida pela Speechworks, que interpreta documentos VoiceXML. O OpenVXI, ao assegurar a implementação de uma boa

43 25 parte das funcionalidades da especificação VoiceXML2.0, apresenta-se como módulo essencial em qualquer plataforma VoiceXML, daí que seja designado como o interpretador de VoiceXML do PVX. A versão utilizada como ponto de partida para o criação do public- VoiceXML, o OpenVXI 2.0.1, disponibiliza reconhecimento de fala simulado e interface de comunicação com os motores de fala segundo o standard SAPI Interface CAPI COMMON ISDN-API (CAPI) é uma interface normalizada de programação que permite o acesso a equipamento RDIS ligado à camada de acesso básico e primário. Ao recorrer a este tipo de standards, as aplicações podem utilizar mecanismos já implementados e bem definidos para comunicação em linhas RDIS, evitando assim a necessidade de ajuste e/ou desenvolvimento para um único tipo de Hardware. As aplicações baseadas na especificação CAPI2.0, como é o caso do publicvoicexml, podem ser utilizadas com qualquer Hardware que cumpra a especificação. A CAPI possibilita aos programadores de aplicações para RDIS desenvolver as suas soluções sem necessidade de conhecer os protocolos baixo nível da linha RDIS. Actualmente, a CAPI é utilizada num universo vasto de sistemas operativos: DOS, Windows NT, Windows 2000, Linux, OS/2, UNIX, BeOS, etc. Descrição funcional A comunicação entre a aplicação e a CAPI baseia-se no conceito de filas de mensagens. Por um lado as aplicações enviam mensagens para a CAPI utilizando uma fila de mensagens única, por outro cada aplicação tem a sua fila de recepção de mensagens, e é através desta que a CAPI comunica com a respectiva aplicação. Aplicação Aplicação Fila de msgs Fila de msgs Fila de msgs CAPI Controlador Controlador Figura 3.2: Lógica de funcionamento da interface CAPI2.0 Uma aplicação pode ligar-se a um ou mais dispositivos RDIS, designados por controladores ao nível da CAPI, podendo ser usado por uma ou mais aplicações. Existem duas funções para a aplicação comunicar com a CAPI:

44 26 publicvoicexml - CAPI_GET_MESSAGE() - CAPI_PUT_MESSAGE() De assinalar ainda que nestas filas de mensagens, como o próprio nome indica, só são trocadas mensagens. Caso seja necessário proceder ao envio ou recepção de dados, tal será feito através de memória partilhada usando um ponteiro que é enviado por mensagem. No PVX a interface com a linha RDIS está implementada na classe CAPI20Interface. Esta classe é responsável pela escuta de mensagens provenientes da CAPI, reprodução de áudio na linha telefónica enviando CAPI_B3_REQUESTS, gravação de áudio proveniente da linha telefónica, aquando da recepção de pacotes de dados do tipo B3, bem como a recepção de dígitos DTMF. Resumidamente, esta interface inicia a escuta da linha telefónica no momento em que a chamada é estabelecida, ficando num ciclo infinito à espera de mensagens da CAPI processando-as de seguida em paralelo Cliente HTTP Este módulo é responsável pela interface de comunicação do browser com um ou mais servidores Web, disponibilizando assim o acesso a conteúdos Web às aplicações VoiceXML. Envia pedidos HTTP a servidores Web especificamente desenvolvidos para aplicações de voz VoiceXML, i.e em resposta aos pedidos HTTP estes servidores Web enviam documentos VXML que posteriormente são interpretados. Só assim é possível a disponibilização de serviços ao utilizador com base em documentos VoiceXML dinâmicos. Na realidade o servidor Web é que cria os novos documentos Módulo de Áudio Este módulo é responsável pela recepção e envio de áudio para a linha telefónica. Como tal, é responsável pela conversão de áudio de Wav para a Lei A e vice-versa Módulo de Sintetização de fala Este módulo é responsável pela interface de comunicação entre o publicvoicexml e o motor de síntese de fala. É através deste módulo que o browser gera a fala da plataforma. Sempre que o browser pretende reproduzir fala na linha telefónica, começa por enviar o respectivo texto ao motor de síntese de fala. De seguida, o motor de síntese de fala, cria um ficheiro de áudio com a(s) respectiva(s) palavra(s) ou frase(s) falada(s). Uma vez entregue o ficheiro ao browser, este é convertido no módulo de áudio e reproduzido na linha telefónica através da interface CAPI.

45 Descrição funcional Por cada chamada telefónica estabelecida o browser cria uma thread. Esta thread, designada por CurrentLine, é responsável pela interpretação dos documentos VoiceXML2.0 e consequente chamada, Callback, ao publicvoicexml, de forma a que a interacção com o utilizador se processe. Todas as interacções com hardware (síntese de áudio) são executadas em threads separadas, hardware threads. Uma por cada Hardware Interface 1. O publicvoicexml utiliza um mecanismo de comunicação baseado em mensagens, o que resulta num processo assíncrono de atendimento das mesmas. Existe ainda uma outra thread, designada por Message Digester, responsável pela gestão das acções centrais processadas pelo browser que percorre todas as linhas disponíveis verificando o seu estado. É através do estado que as threads das Linhas comunicam com a thread Message Digester. Em função do estado da linha são posteriormente despoletadas acções. Toda a comunicação entre as threads é passada por um objecto único, em cada sessão do publicvoicexml da classe CSuperController. No caso da thread Message Digester é explícito, uma vez que o método Message Digester pertence à classe. No caso das threads das Linhas o meio de comunicação utilizado é a CallbackFunction, processo através do qual são enviadas mensagens para o objecto da classe CSuperController e, consequentemente, para as outras threads. O processo repete-se para as hardware threads sendo habitualmente nestes casos o objecto CSuperController que chama estas threads. 1 Entenda-se Hardware Interface, por interface de comunicação com o motor de síntese de fala.

46 28 publicvoicexml 3.5 Melhoramentos implementados no browser Nesta secção, e uma vez que já foram analisados e descritos quer o princípio lógico de funcionamento do browser quer os módulos que o compõem, será então mais fácil compreender as modificações e os desenvolvimentos realizados sobre o PXV, com vista à sua utilização em Português Europeu. Na figura 3.3 apresentam-se os diferentes módulos onde houve intervenção. Linha Telefónica 1 Input Controller Thread Linha Telefónica 2 CAPI driver Conversor de Áudio Lei A «Wav Output Controller Thread Dados da sessão estabelecida VoiceXML Função Callback HTTP Client Handler HTTP 1.1 VXML Linha Telefónica N Audimus-ASR Dixi-TTS Interpretador de VoiceXML OpenVXI Figura 3.3: Arquitectura do publicvoicexml Integração do DIXI-Festival Para que a fala da plataforma desenvolvida fosse realizada em Português Europeu, foi necessário proceder à integração do sintetizador de fala DIXI. Uma vez que este sintetizador de fala, a partir de texto para Português Europeu, desenvolvido no L 2 F, não cumpre na sua versão actual a especificação Microsoft SAPI 5.1, foi necessário proceder à adaptação da classe TTSWindows do PVX. Esta adaptação teve por objectivo a integração de uma DLL responsável pela disponibilização de dois entry points carrega_festival(... ) e text_to_wave(... ) para comunicação entre o browser e o motor de síntese de fala. Assim, na fase de início da chamada telefónica, é feita a inicialização do sintetizador de fala, carrega_festival(... ). No decorrer da chamada, sempre que é necessário comunicar com o utilizador, o PVX entrega ao DIXI o texto que pretende reproduzir na linha telefónica text_to_wave(... ). Como resultado, o motor de síntese entrega ao PVX um ficheiro de áudio que, após conversão para a Lei A, é reproduzido na linha telefónica através da interface CAPI.

47 Integração de uma Hardware Interface-ASR Na fase inicial do projecto, o publicvoicexml não permitia o reconhecimento de fala. A interface Homem-Máquina disponibilizada resumia-se apenas a reconhecimento de DTMF e síntese de fala. Como tal, e na sequência dos objectivos estabelecidos para este trabalho, procedeu-se ao desenvolvimento de uma Hardware Interface que permitisse a utilização de qualquer reconhecedor de fala compatível com a especificação Microsoft SAPI 5.1. Este processo dividiu-se em três fases distintas: Desenvolvimento de uma aplicação em C++ baseada nas Microsoft Foundation Classes, responsável por abrir um ficheiro de áudio e proceder ao reconhecimento do mesmo. Numa primeira fase, todo o processo foi implementado recorrendo ao Microsoft English Recognizer v5.1, de forma a garantir o cumprimento das especificações Microsoft SAPI 5.1. Posteriormente, teve início a implementação desta mesma aplicação recorrendo ao reconhecedor de fala Audimus, desenvolvido no L 2 F INESC-ID Lisboa. Criação e integração da classe ASRWindows no publicvoicexml. Esta classe composta por dois métodos distintos, LoadASR e GenerateASR, é responsável pela criação de uma thread que processa todo o áudio proveniente do utilizador. Assim, na fase de início da chamada telefónica, é feita a inicialização do reconhecedor de fala, LoadASR. Posteriormente, no decorrer da chamada, sempre que é colocada uma pergunta ao utilizador, e este responde, o áudio com a resposta do utilizador armazenado num ficheiro Wav temporário é entregue ao Audimus, iniciando-se assim a fase de reconhecimento, GenerateASR. Uma vez processado todo o áudio, o método GenerateASR devolve o texto reconhecido. Após a integração da classe e consequente criação de novos estados para a linha telefónica LINE_GENERATE_ASR e LINE_ASR_COMPLETED, o OpenVXI possibilitava apenas reconhecimento simulado, i.e. a interface de processamento de dados do reconhecedor era incompleta. Foi necessário adaptar o interpretador de forma a que o texto proveniente do reconhecedor pudesse ser processado convenientemente. A partir desta fase, o restante desenvolvimento do projecto assenta num VoiceXML browser dotado da capacidade de reconhecimento de fala com a seguinte lógica de funcionamento: <form id="username"> <prompt>qual o seu nome?</prompt> <grammartype="text/gsl">joão Pedro António</grammar> </form> 1. No instante em que a tag <prompt> é processada, a string Qual o seu nome? é convertida para um ficheiro de áudio através do TTS Engine Dixi-Festival. 2. O estado da Linha é alterado para LINE_PLAYING, momento a partir do qual o áudio é reproduzido na Linha telefónica.

48 30 publicvoicexml 3. No instante em que a reprodução do áudio termina, o estado da Linha é alterado para LINE_PLAYING_FINISHED. 4. Tem então início o record do áudio do utilizador, que será a resposta à pergunta anteriormente realizada. 5. Assim que é detectado que o utilizador já respondeu, o ficheiro de áudio é entregue ao reconhecedor de forma a que este processe o reconhecimento de fala e o publicvoicexml possa então agir em consonância com a string obtida Integração do módulo detector de Endpoint O detector de Endpoint é usado para assinalar o início e o final de um troço de sinal acústico contendo fala, filtrando os restantes sinais acústicos que não contêm fala, normalmente compostos por silêncio ou ruído introduzido pela linha telefónica, evitando assim a entrega de sinal acústico que não interessa ao reconhecedor de fala. Descrição funcional A detecção de Endpoint, visa distinguir os segmentos de fala, dos de silêncio ou ruído do sinal de fala digital. O Endpoint é considerado como um dos componentes chave e preliminares para o pré processamento em sistemas de reconhecimento de fala. A estimativa apropriada do começo e do fim de fala (contra o ruído do silêncio ou de fundo) pode evitar avaliações desnecessárias de sinais de fala compostos por silêncio. Em algumas aplicações específicas de reconhecimento de fala, os ambientes incluem um elevado nível de ruídos não estacionários, como é o caso do telefone. Aqui, o ruído introduzido pode advir de diferentes sítios, como por exemplo dos altifalantes, do ambiente ou da transmissão. A variabilidade das durações e das amplitudes para sons distintos torna a detecção difícil. O detector de Endpoint apoia-se sobre uma máquina de estados finitos, FSM ( Finite State Machine), composta por quatro estados diferentes (Silence, Head,Body e Tail). As transições de estados possíveis são controladas por limiares de energia (threshold) e por intervalos de tempo nos quais a energia terá de permanecer acima dos respectivos limiares. Numa fase inicial este encontra-se no estado Silence - estado que corresponde a silêncio ou ruído. O evento responsável pela transição para outro estado é despoletado pela análise de amostras de dez em dez milissegundo sobre o espectro do sinal. Este calcula a energia de uma amostra e quando atinge o Head threshold e aí permanece por um determinado tempo (Head Max Time), existe a possibilidade de ser o início de uma palavra ou frase, por isso é alterado o estado para Head. O mesmo processo de análise é efectuado para o trânsito do outro estado, Body. Este estado é alcançado uma vez atingido o limiar Body Threshold e aí permanecer por um determinado tempo denominado de seg Min Time. É assim assumido que o sinal, que está a ser processado, é referente a uma palavra ou frase, passando neste momento para o estado Body, do qual só sai quando o nível de energia do sinal passar abaixo do tail threshold, passando para o estado Tail. Se este se mantiver abaixo deste limiar por um tempo mínimo seg Extended Time, significa o

49 31 fim de uma palavra ou frase, transitando outra vez para o estado Silence. Uma vez atingido este estado, é colocado um Endpoint no sinal e ignorado o resto até que volte a ser atingido o Head threshold outra vez. Intervenção no browser Após várias simulações de aplicações teste no publicvoicexml e, uma vez que se faz uso da linha telefónica para o reconhecimento de fala,tornou-se determinante o uso de um detector de Endpoint de fala. Este módulo, uma vez integrado na plataforma, trouxe vantagens significativas ao voicexml browser. Enquadramento da intervenção Admitindo uma chamada em curso e, que o estado da respectiva linha é LINE_RE- CORDING, isto é todos os pacotes provenientes da linha telefónica se apresentam como potenciais troços de sinal acústico contendo fala, surge então a necessidade de analisar o conteúdo destes e decidir se se trata de um troço de sinal contendo fala que será então gravado num ficheiro temporário ou se pelo contrário contém silêncio. Intervenção Neste contexto, e para que a análise anteriormente referida possa ser processada, procedeuse à integração do módulo Endpoint, desenvolvido no L 2 F INESC-ID Lisboa. Esta intervenção, realizada ao nível da interface CAPI do PVX, dividiu-se em duas áreas distintas: 1. Inicialização do Endpoint, realizada sempre que a linha telefónica passa para o estado de LINE_RECORDING. 2. Gestão do estado da linha telefónica. De seguida, analisar-se-á mais pormenorizadamente o modo como é gerido o estado das linhas, visto que, no caso em que a linha se encontra em LINE_RECORDING, esta depende directamente do Endpoint. Uma vez iniciada a sessão de gravação LINE_RECORDING é inicializado o Endpoint. A partir deste instante todos os pacotes que a interface CAPI recebe provenientes da linha telefónica são entregues ao Endpoint. Paralelamente, numa thread específica do Endpoint, os pacotes recebidos são analisados e é feita a detecção se o pacote recebido contem fala ou não. Assim que a máquina de estados do módulo Endpoint detecta silêncio, i.e. detectou o início e fim de um troço de sinal acústico contendo fala, o estado da linha telefónica é alterado, passando de LINE_- RECORDING para LINE_CONNECTED e o Endpoint terminado. O publicvoicexml, ao detectar esta transição, interpreta-a como uma indicação de que o utilizador acabou de responder à pergunta que lhe tinha sido colocada. De seguida, o ficheiro que o Endpoint grava, contendo o sinal acústico de fala, é entregue ao reconhecedor prosseguindo a execução normal da aplicação VoiceXML.

50 32 publicvoicexml Implementação da funcionalidade: Ditado Uma vez integrado o módulo de Endpoint, procedeu-se à adaptação do VoiceXML interpreter OpenVXI. A partir do momento em que para casos específicos de aplicações de VoiceXML surgiu a necessidade de recorrer a funções de Ditado foi necessário dotar o interpretador da capacidade de aceitar os resultados de reconhecimento do Audimus sem recorrer a gramáticas VoiceXML. Para tal, foi criada uma palavra chave, ditado_- INESC. Esta palavra é utilizada como identificador da função Ditado. Qualquer aplicação em que se pretenda realizar funções do tipo Ditado, ex.: compor , deverá apresentar no documento VXML respectivo a palavra chave. Exemplo:... <prompt>pode começar a ditar a mensagem do seu .</prompt> <grammar>ditado_inesc</grammar>... Deste modo, o browser ao interpretar o elemento <grammar> para o <prompt> referido, ao invés de comparar o texto devolvido pelo Audimus com a suposta gramática, visto que detectou ditado_inesc, assume o texto proveniente do reconhecedor de fala como correcto, continuando a processar a aplicação VXML. Esta intervenção, realizada ao nível do interpretador de VoiceXML OpenVXI, foi essencial, uma vez que em situações de Ditado não existe possibilidade de definir uma gramática concreta ao nível da aplicação VoiceXML. Deste modo todo o reconhecimento de fala e validação é da responsabilidade do reconhecedor. Daí que seja necessário um léxico extremamente bem concebido Desenvolvimento da aplicação portaudio Uma vez que no laboratório do L 2 F não está disponível o acesso à linha telefónica RDIS, surgiu a necessidade de criar uma aplicação que tornasse possível a comunicação com o publicvoicexml através da interface CAPI deste. O desenvolvimento desta aplicação dividir-se-ia em duas fases distintas: Implementação de um controlador CAPI virtual. Desenvolvimento de uma aplicação que comunicasse com a CAPI disponibilizando input/output de áudio através da placa de som. Deste modo, a partir do momento que o controlador CAPI estivesse registado no Windows seria possível a interacção com o publicvoicexml localmente e sem recurso à linha RDIS. O desenvolvimento deste controlador CAPI tinha requisitos específicos inerentes ao modo como está definida a especificação CAPI2.0. mais especificamente funções implementadas pelo publicvoicexml (transferência de dados pelo canal D). Para que haja comunicação entre um controlador e o publicvoicexml através da CAPI, é obrigatório que o controlador

51 33 responda a todos os pedidos de publicvoicexml. Esta comunicação divide-se em cinco fases fundamentais distintas: 1. Fase de registo da aplicação sobre a CAPI 2. Estabelecimento de uma chamada 3. Suspensão de chamadas e sua reactivação 4. Troca de dados 5. Terminação de chamada Durante todas estas fases, em que há constantemente comunicação quer do controlador quer do publicvoicexml com a CAPI, é necessário que: por um lado, o controlador responda com sucesso aos pedidos provenientes aplicação, o publicvoicexml, e, por outro, que seja capaz de processar toda a comunicação com o Hardware, neste caso o Hardware seria emulado numa aplicação com input/output através da placa de som do PC. Analisando a figura 3.4, poder-se-á compreender melhor a complexidade da aplicação a desenvolver. portaudio Aplicação App PublicVoiceXML 3.0 Fila de msgs Fila de msgs Fila de msgs CAPI Controlador Virtual Controlador Figura 3.4: Interface CAPI2.0 a implementar Seria necessário não só desenvolver a aplicação portaudio, que em boa parte seria uma réplica daquilo que são as comunicações entre da interface CAPI do publicvoicexml, como também implementar o controlador CAPI, na figura 3.4 designado por Controlador Virtual. Este controlador, uma vez registado no sistema operativo, seria responsável por pela comunicação bidireccional entre o publicvoicexml e a aplicação portaudio. Em todo este processo, tanto para o portaudio como para o publicvoicexml o papel desempenhado por

52 34 publicvoicexml este controlador seria transparente, na medida em que ambos apenas enviavam mensagens através da sua interface CAPI. O trabalho desenvolvido para cumprir este objectivo teve início com a criação do controlador, chegando a cumprir-se as cinco fases fundamentais referidas anteriormente. No entanto, e em parte devido à necessidade de implementação de threads, sincronismo da comunicação bidireccional entre aquilo que seria o portaudio e o publicvoicexml revelou-se um obstáculo. Daí que ao final de três meses de trabalho desenvolvido, perante as dificuldades encontradas e em concordância com o Professor se considerasse não ser rentável esta implementação. No entanto toda a investigação realizada, quer em torno da CAPI20Interface do public- VoiceXML, quer em torno da implementação do Controlador Virtual, mostrou ser uma mais valia essencial para o cumprimento dos objectivos iniciais de todo o trabalho publicvoicexml - modo local Perante as dificuldades encontradas no desenvolvimento da aplicação portaudio e, uma vez que se pretendia que o ambiente de desenvolvimento de aplicações para IVRs fosse o mais autónomo e modular possível, foi criada uma interface que permitisse simular um cliente único publicvoicexml sem recurso a cartas de rede RDIS. Esta classe foi desenvolvida de forma a que a interface com o utilizador fosse estabelecida através da placa de som do PC. Assim sendo, na versão do browser em modo local, a CAPI20interface encontra-se desactivada, tendo sido criada uma interface específica responsável pelos seguintes métodos: RecordAudio: assim que o estado da Linha passa para LINE_RECORDING, o áudio proveniente do microfone é gravado num pcm file. Posteriormente é entregue ao reconhecedor de fala, Audimus. PlayAudio: assim que o estado da Linha passa para LINE_PLAYING, o ficheiro de áudio proveniente do módulo TTS é reproduzido na placa de som.

53 Capítulo 4 Arquitectura do Sistema IVR - Interactive Voice Response, até há bem pouco tempo as plataformas IVR eram constituídas por Hardware e Software proprietários, apresentando em muitos casos: custos de manutenção elevados, interoperabilidade e flexibilidade reduzidas,etc. Para obviar estas e outras limitações surgiu o VoiceXML - um standard que descreve diálogos interactivos usando XML como base. Neste capítulo é apresentada a arquitectura do sistema implementado, tendo como elementos fundamentais o recurso ao publicvoicexml, reconhecimento e sintetização de fala em Português Europeu. 4.1 Plataformas IVR As plataformas IVR, até há bem pouco tempo eram soluções proprietárias, i.e. uma vez instaladas e operacionais tanto o Hardware como o Software utilizados pertenciam a um único fornecedor. Apesar destes fornecedores habitualmente disporem de programadores experientes no desenvolvimento de soluções, acabam por funcionar como um custo de manutenção do sistema, na medida em que não é um programador qualquer a desenvolver uma nova aplicação. Para além desta limitação surgem outras, como a baixa interoperabilidade dos seus elementos constituintes, obrigando à utilização tanto do ASR Engine, reconhecedor de fala, como o TTS Engine, sintetizador de fala, do mesmo proprietário. É neste contexto que surge o VoiceXML, com o objectivo primordial da estandardização de plataformas e aplicações de IVRs. Esta extensão do XML permite desenvolver rapidamente novas aplicações em conjunto com colaboradores e clientes, tornando estas soluções inovadoras e ambiciosas. Nas figuras 4.1 e 4.2 apresentam-se as duas arquitecturas tipo discutidas neste capítulo, IVR tradicional e IVR baseada em VoiceXML. 35

54 36 Arquitectura do Sistema Internet IVR Aplicação da IVR IVR -VoiceXML Aplicação em VoiceXML Interpretador de VoiceXML ECMAS script C/C++/Java API C/C++/Java API C/C++/Java API C/C++/ Java API C/C++/Java API C/C++/Java API ASR TTS Hardware - Software Interface Telefónica Microsoft SAPI5.1 Reconhecedor de fala Microsoft SAPI5.1 Sintetizador de Fala Hardware - Software CAPI 2.0 Interface Telefónica PSTN v RDIS PSTN v RDIS Figura 4.1: IVR tradicional Figura 4.2: IVR baseada em VoiceXML Análise da plataforma Analisando as figuras 4.1 e 4.2 consegue-se compreender melhor os aspectos fundamentais que distinguem a plataforma IVR implementada neste projecto de uma plataforma IVR tradicional. Ao nível da interface com os módulos síntese de fala, reconhecimento de fala e interface telefónica são notórias as diferenças: - Motores de fala: síntese e reconhecimento A interface SAPI5.1 da Microsoft disponibiliza uma interface de alto nível entre as aplicações e os motores de fala. Toda a implementação de baixo nível necessária para o controlo e gestão da operação dos motores em tempo real é implementada pela SAPI. Os dois tipos de motores controlados pela SAPI são o reconhecedor de fala e o sintetizador de fala. Aplicação C++ API SAPI 5.1 DDI Reconhecedor de fala Sintetizador de fala Figura 4.3: Microsoft Speech API-SAPI5.1 A implementação deste tipo de standards em IVRs é uma grande vantagem na medida em que, em qualquer momento, qualquer um dos módulos de síntese ou re-

55 37 conhecimento podem ser trocados. Assim, ao contrário do que acontece numa IVR tradicional, o proprietário de uma plataforma deste tipo não estará limitado a um único fornecedor, podendo utilizar qualquer motor de fala que cumpra a especificação SAPI5.1. No caso concreto deste projecto recorreu-se ao reconhecedor de fala Audimus e ao sintetizador de fala Dixi-Festival 1, desenvolvidos ambos no L 2 F-INESC. - Interface Telefónica Uma vez mais, ao recorrer a uma especificação standard como é a CAPI2.0, ao invés de se ficar limitado ao Hardware de um único fornecedor, como acontece nas IVRs tradicionais, é possível utilizar qualquer tipo de carta RDIS compatível com a respectiva especificação. - Aplicação e Interpretador VoiceXML As questões referidas anteriormente em relação aos motores de fala e à interface telefónica, representam por si só uma mais valia, na medida em que, deste modo, a plataforma apresenta uma interoperabilidade muitíssimo mais elevada acabando com a dependência de um único fornecedor. Por outro lado, o facto de recorrer ao VoiceXML permite que qualquer programador, mesmo que sem um conhecimento aprofundado de IVRs, possa começar a desenvolver aplicações trabalhando em conjunto quer com colaboradores quer com os próprios clientes da plataforma. O feedback dos utilizadores e posterior estudo e análise revelam-se factores preponderantes no sucesso deste tipo de aplicações. Recorrendo ao VoiceXML possibilita num curto espaço de tempo desenvolver aplicações, utilizá-la num grupo de teste e iterativamente proceder a uma optimização da aplicação ainda antes de a disponibilizar para funcionamento ao público. Tabela 4.1: Vantagens e desvantagens de uma IVR baseada VoiceXML Vantagens Implementação de um standard aberto Web developers poderão começar a desenvolver portais de Voz Desenvolvimento de aplicações facilitado Conteúdos VoiceXML poderão correr em servidores específicos para voz Proporciona aos utilizadores da linha telefónica muito do potencial da Internet Desvantagens Controlo de chamada reduzido Ainda não está consolidado no mercado de IVRs Obriga à substituição da tecnologia utilizada na IVR tradicional A migração de uma IVR tradicional para uma IVR VoiceXML apresentará custos significativos 1 Este Engine não cumpre a especificação SAPI5.1, daí que para este elemento não se tenha recorrido à interface SAPI

56 38 Arquitectura do Sistema 4.2 Solução Implementada Este projecto tem como objectivo principal a criação, desenvolvimento e estudo de uma plataforma genérica para o desenho de IVRs. Pretende-se ainda que esta apresente uma elevada interoperabilidade e flexibilidade de modo a anular qualquer tipo de limitações futuras. Depois de analisadas as diferentes plataformas para desenvolvimento de soluções baseadas em VoiceXML, secção 2.6 da pág. 14, e nunca esquecendo que o pretendido seria uma plataforma o mais modular possível em que a interoperabilidade fosse uma constante, i.e. qualquer módulo desde do reconhecedor ao servidor Web poderia ser trocado por outro semelhante, necessitando apenas que se cumprissem as especificações: SAPI 5.1, CAPI2.0, etc. Neste sentido, e à semelhança do que se passa no mercado IT, optou-se pela implementação de uma solução assente em standards abertos e o mais independente possível do sistema operativo. A solução desenvolvida baseia-se em software open-source, tanto ao nível do VoiceXML browser como ao nível do servidor Web. De mencionar que ao recorrer à especificação SAPI5.1 da Microsoft para comunicação com os motores de fala, garante-se desde uma elevada interoperabilidade para esta plataforma. Na figura 4.4 apresenta-se a arquitectura do sistema implementado. IVR-VoiceXML Web Server Módulo Cliente HTTP1.1 HTTP1.1 VXML Server Main Login Servlet Gestor de Clientes Users.XML Microsoft SAPI5.1 Interface CAPI2.0 ficheiro áudio string Audimus ASR string ficheiro áudio Dixi.Festival TTS Linha RDIS M E T E O Notícias RSS.Reader Voice servlets LoginMail Mail Java Mail API Internet Base de Dados RSS. XML web sites previsão meteorológica service provider Figura 4.4: Arquitectura do Sistema Implementado