CTDesign-VoiceXML-convertor

Academiejaar 2007 – 2008

Departement Toegepaste Ingenieurswetenschappen Schoonmeersstraat 52 – 9000 Gent

CTDesign-VoiceXML-convertor

Eindwerk voorgedragen tot het behalen van het diploma van MASTER IN DE INDUSTRIËLE WETENSCHAPPEN: INFORMATICA

Bram DE COENE Promotoren: Veerle ONGENAE Filip HOSTE

Woord vooraf Mijn dank gaat in de eerste plaats uit naar MI4C, het bedrijf waar ik stage heb mogen lopen en dat de thesis aanbood. Meer in het bijzonder wens ik de heren Filip Hoste (technical manager en tevens mijn thesisbegeleider) en Bert Reyntjens (development engineer) te bedanken voor hun bijstand met raad en daad, zowel qua ideeën en strategie als wat het eigenlijke programmeerwerk betreft. Ook de overige collega’s wil ik hier niet vergeten: de heren Maarten Bossuyt (accounting manager) en Antony Verbruggen (installation & support engineer) voor hun nuttige tips en voor de sfeer op de werkplek. Daarnaast wil ik ook de vakgroep informatica van de Hogeschool Gent danken. Het gaat hier dan meer specifiek om mevrouw Veerle Ongenae (mijn interne thesisbegeleider) voor haar zorgvuldige follow‐up en correcties, en de heren Rudy Stoop (docent algoritmen) en Jan Cnops (docent systeemanalyse) voor de leerrijke bijdragen die zij via hun lessen geleverd hebben en die handig van pas kwamen bij de verwezenlijking van deze thesis. Verder wens ik ook een woord van dank te richten aan de verschillende personen die de moeite genomen hebben deze thesis na te lezen en mij te wijzen op type‐, spellings‐ en stijlfouten en andere mogelijkheden tot verbetering. Ten slotte ook nog een speciaal woord van dank voor mevrouw Kathleen Pollefliet (assistente communicatie departement INWE) voor haar uiterst praktische handleiding over het schrijven van een correcte en aantrekkelijke masterproef. Bram De Coene Melle, 5 juni 2008

Abstract MI4C is an enterprise situated in the interactive voice response (IVR) market. There are quite a number of emerging and more mature standards out there; VoiceXML seems to be the most suitable one for IVR and call center solutions, the firm’s specialty. Call Control XML (CCXML) might be a valuable addition, whereas Speech Application Language Tags (SALT) offer extra possibilities for web surveys. The main goal, however, is to convert the proprietary CTDesign data format (using a Btrieve file database system) for IVR flows into a more generally known and accepted format, VoiceXML, and back to CTDesign format as well, for validation reasons. Although only few similarities can be found between the two formats and in spite of VoiceXML’s rather strict structure rules, a basic full‐circle conversion is possible.

Keywords IVR; IVR flow; VoiceXML; SALT; CCXML; CTDesign; Btrieve

B. De Coene

VoiceXML‐conversie

4

Inhoudsopgave Woord vooraf .................................................................................................................................. 2 Abstract .......................................................................................................................................... 3 Keywords ............................................................................................................................................. 3 Inhoudsopgave ................................................................................................................................ 4 Figuren en tabellen ......................................................................................................................... 8 Inleiding .......................................................................................................................................... 9 Hoofdstuk 1: IVR? .................................................................................................................................. 10 1.1

Werking ................................................................................................................................. 10

1.2

Toepassingen ......................................................................................................................... 10

1.2.1

Voice activated diallers (VAD) ....................................................................................... 11

1.2.2

Informatie en entertainment ........................................................................................ 11

1.2.3

Anonimiteit .................................................................................................................... 11

1.2.4

Medische experimenten ................................................................................................ 11

1.3

Gebruikte technologieën ....................................................................................................... 12

1.4

Een eerste aanzet .................................................................................................................. 12

1.5

Praktische toepassing ............................................................................................................ 13

1.6

IVR‐ontwikkeling .................................................................................................................... 13

1.7

ARU ........................................................................................................................................ 13

1.8

Nadelen van IVR .................................................................................................................... 14

Hoofdstuk 2: MI4C ................................................................................................................................. 14 2.1

Probleemstelling .................................................................................................................... 16

2.2

Thesisvoorstel: New standard for computerised telephony ................................................. 17

Wie zijn we? .................................................................................................................................. 17 Probleemstelling ............................................................................................................................ 17 Doelstelling .................................................................................................................................... 17 Gebruikte technologieën ............................................................................................................... 17 Contactpersoon ............................................................................................................................. 17 2.3

Uitgebreid eindwerkvoorstel: voornaamste elementen ....................................................... 18

2.3.1

Beknopte analyse .............................................................................................................. 18

2.3.2

Te verwezenlijken .............................................................................................................. 18

2.3.3

Mogelijke opties en uitbreidingen .................................................................................... 19

2.3.4

Potentiële problemen ....................................................................................................... 19

B. De Coene


5

2.3.5

Gebruikte technologieën ................................................................................................... 19

2.3.6

Vernieuwende aspecten .................................................................................................... 20

Deel I ............................................................................................................................................. 21 Hoofdstuk 3: Standaarden voor IVR‐systemen ..................................................................................... 21 3.1

Een brokje geschiedenis ........................................................................................................ 22

3.2

VoiceXML ............................................................................................................................... 23

3.2.1

Configuratie ................................................................................................................... 23

3.2.2

Structuur ........................................................................................................................ 24

3.2.3

Een voorbeeld: Hello World .......................................................................................... 24

3.2.4

Een realistische toepassing ........................................................................................... 25

3.2.5

Voornaamste elementen ............................................................................................... 25

3.2.6

Een realistisch voorbeeld .............................................................................................. 26

3.2.7

Interoperabiliteit ........................................................................................................... 28

3.2.8

De toekomst .................................................................................................................. 29

3.2.9

Conclusie ....................................................................................................................... 29

3.3

CCXML.................................................................................................................................... 30

3.4

SALT ....................................................................................................................................... 31

3.4.1

Gebruikerservaring ........................................................................................................ 32

3.4.2

Structuur en elementen ................................................................................................ 32

3.4.3

Toepassingen ................................................................................................................. 34

3.4.4

Hardware ....................................................................................................................... 36

3.4.5

Voordelen ...................................................................................................................... 37

3.4.6

Praktische opmerkingen ................................................................................................ 38

3.4.7

Nog een laatste voorbeeld ............................................................................................ 38

3.4.8

Call control met SALT .................................................................................................... 38

3.4.9

Conclusie met betrekking tot SALT ................................................................................ 39

3.4.10

Een voorbeschouwing op het debat ‘VoiceXML versus SALT’? ..................................... 39

3.5

Samenvatting en conclusie .................................................................................................... 40

Hoofdstuk 4: VoiceXML versus SALT: de keuze van een spraakapplicatiestandaard ........................... 40 4.1

De toekomst van de spraaktechnologie ................................................................................ 41

4.2

VoiceXML ............................................................................................................................... 41

4.3

SALT ....................................................................................................................................... 42

4.4

Vijf belangrijke vragen ........................................................................................................... 42

4.4.1

Hoe ziet de huidige webinfrastructuur er uit? .............................................................. 42

B. De Coene


6

4.4.2

Zijn snelheid en ondersteuning belangrijk? .................................................................. 43

4.4.3

Is multimodale toegang vereist? ................................................................................... 43

4.4.4

Welke standaard ondersteunt het best de bestaande infrastructuur? ........................ 44

4.4.5

Welke standaard zal de contactcentermarkt veroveren? ............................................. 45

4.5

Standaarden in het vooruitzicht ............................................................................................ 45

4.6

Mogelijkheden ....................................................................................................................... 45

4.7

Architectuur ........................................................................................................................... 46

4.7.1 4.8

Samenvatting ................................................................................................................. 48

Ontwerp................................................................................................................................. 48

4.8.1

Ontwerp en manier van werken ................................................................................... 49

4.8.2

Samenvatting ................................................................................................................. 49

4.9

Leerproces en gebruiksvriendelijkheid .................................................................................. 50

4.9.1

Samenvatting ................................................................................................................. 51

Conclusie van deel I ............................................................................................................................... 52 Deel II ............................................................................................................................................ 54 Inleiding ............................................................................................................................................. 54 Hoofdstuk 5: CTDesign en IVR‐flows ..................................................................................................... 54 Hoofdstuk 6: Stage ................................................................................................................................ 55 6.1

Verkenning van CTDesign ...................................................................................................... 55

6.2

Optimalisatie structuur CTDesign‐broncode ......................................................................... 57

6.3

Eigen code ............................................................................................................................. 58

6.4

TinyXML++ en integratie ....................................................................................................... 59

6.5

JVoxEdit ................................................................................................................................. 59

6.6

Doorlopen van de CTDesign‐projectgraaf ............................................................................. 61

Hoofdstuk 7: Analyse ............................................................................................................................. 61 Hoofdstuk 8: CTDesign → VoiceXML .................................................................................................... 65 8.1

Queue .................................................................................................................................... 65

8.2

Map creëren vanuit code ...................................................................................................... 65

8.3

Werkdirectory ....................................................................................................................... 65

8.4

Map/bestand selecteren ....................................................................................................... 66

8.5

Nagaan of een (absolute) padnaam geldig is ........................................................................ 66

8.6

Mapselectie ........................................................................................................................... 66

8.7

Tekststructuren ..................................................................................................................... 66

8.8

Controls manipuleren ............................................................................................................ 67

B. De Coene


7

8.9

Hernoemen ............................................................................................................................ 67

8.10

Stringoperaties ...................................................................................................................... 67

8.11

Stringoperaties (bis) .............................................................................................................. 67

8.12

Exception handling ................................................................................................................ 67

8.13

TiCPP ...................................................................................................................................... 68

8.14

Exception handling en TiCPP ................................................................................................. 68

8.15

Hardnekkige crash ................................................................................................................. 68

8.16

Memory leaks ........................................................................................................................ 68

8.17

Memory leaks (bis) ................................................................................................................ 69

8.18

Stack corruption .................................................................................................................... 69

8.19

Resource management ......................................................................................................... 69

8.20

Een bestand weergeven in een control ................................................................................. 69

8.21

Beschrijving van een bericht ................................................................................................. 70

Hoofdstuk 9: VoiceXML → CTDesign .................................................................................................... 70 9.1

Mapstructuur met dubbele sleutel ....................................................................................... 70

9.2

Inlezen van een xml‐document ............................................................................................. 70

9.3

Formaten voor tekstopslag ................................................................................................... 71

9.4

BTV‐bestanden ...................................................................................................................... 71

9.5

Release‐build ......................................................................................................................... 71

9.6

Debug assert failure .............................................................................................................. 71

9.7

AutoAanvullen van padnamen .............................................................................................. 72

9.8

Een bestand laten openen vanuit code ................................................................................. 72

Conclusie ............................................................................................................................................... 73 Conclusie van deel II .............................................................................................................................. 75 Eindconclusie ................................................................................................................................ 76 Bibliografie .................................................................................................................................... 77

B. De Coene


8

Figuren en tabellen Figuur 1: de voornaamste onderdelen van het MI4C‐CTI‐systeem ...................................................... 14 Figuur 2: de FSM‐voorstelling van een project in CTDesign .................................................................. 15 Figuur 3: illustratie van een mogelijke architectuur van VoiceXML, CCXML en SALT ........................... 22 Figuur 4: een mogelijke architectuur voor een VoiceXML‐systeem ..................................................... 24 Figuur 5: Hello World met VoiceXML .................................................................................................... 25 Figuur 6: voorbeeld van reactie die afhangt van de gebruikersinvoer ................................................. 27 Figuur 7: een voorbeeld van SRGF‐grammatica .................................................................................... 28 Figuur 8: een ‘conversational system’ (JUPITER stelt het systeem voor) ............................................. 29 Figuur 9: een eenvoudige webpagina met SALT ................................................................................... 33 Figuur 10: een eenvoudig text‐to‐speechbericht .................................................................................. 33 Figuur 11: afspelen van een opgenomen bericht.................................................................................. 33 Figuur 12: dynamisch invullen van de berichtinhoud ........................................................................... 33 Figuur 13: het opnemen van een bericht en binden aan een variabele ............................................... 34 Figuur 14: een functie oproepen tijdens het opnemen van een bericht .............................................. 34 Figuur 15: html‐code en binden van een invoerveld aan een variabele ............................................... 35 Figuur 16: functies om geldigheid van de invoer te garanderen .......................................................... 36 Figuur 17: benodigdheden voor SALT‐implementatie .......................................................................... 37 Figuur 18: namespacedeclaratie van SALT ............................................................................................ 38 Figuur 19: MIME‐type van de documenten .......................................................................................... 38 Figuur 20: events bij het <listen>‐element ............................................................................................ 38 Figuur 21: een schets van de architectuur van een VoiceXML‐server .................................................. 47 Figuur 22: een schets van de architectuur van het SALT‐systeem ........................................................ 47 Figuur 23: een functionele vergelijking tussen VoiceXML en SALT ....................................................... 51 Figuur 24: een eenvoudige CTDesign‐applicatie (IVR‐flow) .................................................................. 55 Figuur 25: de definitie van een normale staat ...................................................................................... 56 Figuur 26: de elementen van een bericht ............................................................................................. 56 Figuur 27: voorwaarden opleggen voor het afspelen van een bericht ................................................. 56 Figuur 28: een wachttoestand............................................................................................................... 56 Figuur 29: de elementen van een verbinding ....................................................................................... 56 Figuur 30: de elementen van een opname ........................................................................................... 56 Figuur 31: het algemeen schema van een CTDesign‐applicatie ............................................................ 58 Figuur 32: validatie van een vxml‐document in een eenvoudige editor ............................................... 60

B. De Coene


9

Inleiding De wereld van de Interactive Voice Response (IVR) en callcenters lijkt eerder op zichzelf te staan. Ze krijgt niet veel directe media‐aandacht, laat staan van onze dagelijkse media. In mijn opleiding tot industrieel ingenieur informatica was ik tot op het moment waarop ik deze thesis aanvatte, nog slechts weinig in contact gekomen met praktisch, grootschalig gebruik van markuptalen zoals VoiceXML en Call Control XML (CCXML) of uitbreidingen op markuptalen, zoals Speech Application Language Tags (SALT). Het leek mij dus wel interessant en leerrijk om eens van naderbij te kijken naar deze standaarden, en daar wat meer onderzoek naar te verrichten. Anderzijds hadden we door de vakken Algoritmen I en II al wat kennis opgedaan over gegevensstructuren en hoe ermee om te gaan. Daar kwam nog bovenop dat we door het vak Databanken ook al een idee hadden over het omgaan met databanksystemen. En dan kwam het thesisvoorstel op tafel: conversie van het bedrijfseigen CTDesign‐opslagformaat (dat gebruikmaakt van een bestandsdatabanksysteem) naar VoiceXML en terug. Met onze opleiding en enige zin voor innovatie is dat dus een ideaal voorstel te noemen. Nog vóór de stageperiode heb ik de specificaties van VoiceXML doorgenomen (die overigens ook voorbeelden bevatten), om alvast niet onvoorbereid ten strijde te trekken. Gedurende de stage was het de beurt aan CTDesign en de mogelijkheden daarvan. De volgende stap was het verkennen van de structuur van het programma, en alvast enkele herschikkingen doorvoeren in de code, met het oog op het isoleren van de functionaliteit voor in‐ en uitlezen van de gegevensbestanden. En dan kwam uiteraard de moeilijkste stap: de conversies, zowel voor‐ als achterwaarts. U leest alles over de moeilijkheden en problemen die dit met zich meebracht in deel II. Terecht vraagt u zich af: en wat moet ik me voorstellen bij het eerste deel? Wel, daar mag u een uitgebreide kennismaking verwachten met de wereld van de IVR en bijbehorende technologieën. Ik heb hiervoor een aantal teksten gebundeld, gesynthetiseerd en voorzien van wat commentaar en extra uitleg waar nodig. U leert er de mogelijkheden van de bovenvermelde standaarden kennen, en krijgt uiteraard ook mijn mening over de geschiktheid van elk ervan voor gebruik bij callcentersoftware. Daar is het eerste deel immers rond gebouwd: welke taal of standaard sluit het beste aan bij CTDesign, en is het meest geschikt voor IVR‐flows? En wat is mijn persoonlijke mening daaromtrent? U leest het allemaal in het eerste deel. Veel leesplezier gewenst!

B. De Coene


10

De wereld van IVR Hoofdstuk 1: IVR? In de telefoniewereld staat interactive voice response, ook wel afgekort tot IVR, voor een technologie die het mogelijk maakt dat een computer spraak en toetstonen detecteert bij een eenvoudig telefoongesprek. Het IVR‐systeem kan antwoorden aan de hand van vooraf opgenomen of dynamisch aangemaakte audio en bellers verdere instructies geven. IVR‐systemen kunnen bijna telkens ingezet worden voor functies waarbij de interface kan opgedeeld worden in een aantal eenvoudige menukeuzes. Zodra ze opgezet zijn, kunnen ze geleidelijk uitgebouwd worden voor grotere hoeveelheden oproepen.

1.1

Werking

Een beller vormt een telefoonnummer dat beantwoord wordt door een IVR‐systeem. Het IVR‐ systeem voert een toepassing uit die gekoppeld is aan de DNIS (dialed number information service) van het gevormde nummer. Vooraf opgenomen geluidsberichten of dynamisch aangemaakte Text‐ to‐Speech (TTS)‐audio geven de beschikbare opties voor de beller weer. Die kan dan kiezen tussen deze opties via dtmf‐tonen of gesproken woorden. Spraakherkenning wordt normaal gebruikt om meer complexe transacties (die dan eerder neigen naar ‘conversational systems’, zie verderop) uit te voeren en zo de menustructuur van de applicatie te vereenvoudigen.

1.2

Toepassingen

IVR‐systemen worden doorgaans ingezet voor het verwerken van grote aantallen oproepen, om de kosten te drukken en de gebruikerservaring te verbeteren. Voorbeelden van situaties waarin IVR‐ systemen vaak gebruikt worden, zijn de volgende: telefonisch bankieren, stemmen via de telefoon en transacties met kredietkaarten. Grote bedrijven benutten IVR om hun applicaties ook buiten de kantooruren toegankelijk te maken. Het gebruik van een VUI (voice user interface) is bedoeld om dezelfde gebruikerservaring te bereiken als met een webinterface het geval zou zijn. Bedrijven zijn er zich bewust van geworden dat toegang tot spraakservices snel en eenvoudig is, en dit komt in hoofdzaak door de snelle verspreiding van mobiele telefoons en gsm’s. Callcenters gebruiken IVR‐systemen om oproepers te identificeren en in groepen onder te verdelen. Door de mogelijkheid om klanten te identificeren, is men in staat om services specifiek op hun maat aan te bieden (zoals bijvoorbeeld direct ‘categoriseren’ van de beller, opzoeken of de oproeper het systeem al eerder gebruikte). En het maakt de weg vrij voor geautomatiseerde services. Er kan informatie naar de beller doorgegeven worden, met opties als: wachten in de wachtrij, een geautomatiseerde service kiezen, of vragen om teruggebeld te worden. Dankzij het gebruik van CTI (computer telephone integration) kan het IVR‐systeem het CLI (calling line id) opzoeken in een

B. De Coene


11

database op het netwerk en zo de beller identificeren. Deze manier is tegenwoordig nauwkeurig voor ongeveer 80 % van de binnenkomende oproepen (althans volgens Wikipedia), maar dit aantal zal nog toenemen naarmate mobiele telefoons nog meer ingeburgerd raken. Voor gevallen waarin het CLI niet meegestuurd werd of niet beschikbaar is, kan aan de beller gevraagd worden zichzelf kenbaar te maken via een andere methode, zoals bijvoorbeeld een PIN‐code of een wachtwoord. Het gebruik van DNIS verzekert dat de correcte applicatie en taal aangesproken worden door het IVR‐systeem. 1.2.1 Voice activated diallers (VAD) Spraakgeactiveerde IVR‐systemen worden nu gebruikt om switchbord‐ of PABX‐operatoren te vervangen (PABX staat voor private automatic branch exchange; de operatoren zijn dan personen gespecialiseerd in het behandelen en doorschakelen van inkomende externe oproepen naar toestellen of pagers van het binnennetwerk). Ze worden ingezet in vele ziekenhuizen en grote bedrijven om de wachttijden voor bellers te reduceren. Een extra functie hierbij is de mogelijkheid dat externe bellers het personeel ‘oppiepen’ en dat de inkomende oproep dan wordt doorgeschakeld naar de opgeroepen persoon. 1.2.2 Informatie en entertainment De omvangrijkste IVR‐platformen zijn inzetbaar voor toepassingen zoals het stemmen in tv‐spelletjes genre American Idol, X‐Factor, Big Brother, … die voor enorme oproeppieken zorgen. IVR’s worden ook frequent gebruikt voor het aanbieden van diensten voor gsm’s (zoals beltonen en logo’s, weerberichten, antwoorden van kruiswoordraadsels en het hele spectrum van ‘entertainment voor volwassenen’). 1.2.3 Anonimiteit IVR‐systemen bieden de mogelijkheid om relatief anoniem gegevens op te vragen. Ziekenhuizen hebben in het verleden al IVR‐systemen gebruikt om bellers toegang te geven tot testresultaten. Dergelijke informatie kan in feite gemakkelijk door een persoon verstrekt worden, maar een IVR‐ systeem biedt een grotere vorm van privacy en vermijdt mogelijke ontevredenheid over het verstrekken van gevoelige informatie of medische onderzoeksresultaten. 1.2.4 Medische experimenten IVR‐systemen worden ook weleens benut door farmaceutische bedrijven bij medische experimenten en de bijbehorende grote datavolumes. De toepassing waarvan de IVR gebruikmaakt bij medische experimenten wordt vaak een Voiceform‐toepassing genoemd. De beller beantwoordt vragen in zijn voorkeurstaal en zijn antwoorden worden vastgelegd in een databank, en indien mogelijk ook direct

B. De Coene


12

opgenomen om verzekerd te zijn van authenticiteit. Toepassingen zijn onder meer te vinden bij het uittesten van geneesmiddelen (wie het echte testmiddel krijgt en wie een placebo).

1.3

Gebruikte technologieën

DTMF‐signalen (ingetoetst op een telefoon) en de herkenning van natuurlijke spraak zijn het antwoord van de beller op afgespeelde spraakberichten. Andere technologieën bevatten de mogelijkheid meer complexe en dynamische informatie zoals e‐ mail, nieuws of het weer uit te spreken via text‐to‐speech (TTS). TTS staat voor door de computer gegenereerde gesynthetiseerde spraak zonder de robotachtig klinkende stem die er lang mee geassocieerd werd. Menselijke stemmen creëren het bericht in kleine fragmentjes die dan verbonden (geconcateneerd) worden vooraleer ze afgespeeld worden voor de beller. Een IVR‐systeem heeft diverse configuratiemogelijkheden: (zie hiervoor ook figuur 4 verderop) 1. Bij de beller opgestelde apparatuur (voor TTS bijvoorbeeld) 2. Apparatuur geïnstalleerd op het PSTN (public switched telephone network) 3. Bij de application service provider geïnstalleerde toestellen Diverse bedrijfsapplicaties maken gebruik van deze technologie: telefoonbankieren, bestellingen plaatsen, identificatie van de oproeper, routing, opvragingen van het rekeningsaldo, vliegtuigtickets boeken, … Een eenvoudig voicemailsysteem verschilt van een IVR‐systeem in die zin dat het eerste geval persoon‐tot‐persoon is, terwijl het laatste persoon‐tot‐computer is. Spraakformulieren (uiteraard met IVR – dit doet eerder aan SALT denken, waarop ik later uitgebreid terugkom) breiden de mogelijkheden voor voicemailapplicaties nog verder uit. Zo kan het IVR‐systeem vragen of de beller een bericht dat zojuist werd opgenomen, wenst te beluisteren, te bewerken of te verwijderen.

1.4

Een eerste aanzet

Een automatic call distributor (ACD) is vaak de eerste stap naar een omvangrijker systeem. Een ACD maakt gebruik van digitale opslag om begroetingen en aankondigingen af te spelen, maar schakelt de beller meestal door zonder naar invoer te vragen. Een IVR‐systeem kan daarentegen naast aankondigingen afspelen ook om invoer vragen aan de gebruiker. Die informatie wordt dan gebruikt om de oproep te routen naar een bepaalde skillset. (Een skillset is een functie die toegepast wordt op een groep callcenteragenten met een bepaalde vaardigheid.) CTDesign voldoet eveneens aan deze definitie, en kan dus ook als ACD beschouwd worden.

B. De Coene

1.5


13

Praktische toepassing

Interactive voice response is bruikbaar als front‐end voor een callcenter, bijvoorbeeld door de noden van de beller te bepalen. Er kan informatie opgevraagd worden aan de beller, zoals bijvoorbeeld bankrekeningnummers. Antwoorden op eenvoudige vragen zoals rekeningsaldo’s of vooraf opgenomen informatie kunnen verkregen worden zonder tussenkomst van een menselijke operator. Rekeningnummers die de IVR binnenkrijgt, worden meestal geverifieerd aan de hand van de gegevens gekoppeld aan het id van de beller (om veiligheidsredenen), en indien er geen overeenstemming is, zullen extra antwoorden op vragen van de IVR nodig zijn.

1.6

IVRontwikkeling

IVR call flows kunnen op diverse manieren gecreëerd worden. Een traditionele IVR hing af van privaat programmeerwerk of van scripttalen (denken we maar aan CTDesign, een volkomen bedrijfseigen toepassing), daar waar de moderne varianten analoog gestructureerd zijn als webpagina’s, en gebruikmaken van VoiceXML, SALT of T‐xml‐talen. De mogelijkheid om op xml gebaseerde toepassingen te gebruiken, heeft tot gevolg dat een webserver als toepassingsserver kan optreden, en laat de programmeur de ruimte om zich in hoofdzaak te richten op de call flow. Er werd algemeen aangenomen dat ontwikkelaars niet langer over verregaande programmeerkennis moesten beschikken, maar dit blijkt misleidend te zijn: IVR‐applicaties moeten de menselijke reactie op de dialogen van de toepassing ‘verstaan’. En dat is nu net het verschil tussen een degelijke gebruikerservaring en de ‘IVR‐hel’. IVR‐ontwikkeltools voor een hoger niveau zijn pas de laatste jaren opgekomen, en vereenvoudigen het ontwikkelproces aanzienlijk. Het is nu al mogelijk het stroomdiagram van een oproep uit te tekenen in een GUI, en de toepassingscode (VoiceXML of SALT) automatisch te laten genereren. En die tools voorzien dan meestal ook nog eens in uitbreidingen voor software‐integratie zoals een http‐ interface naar een website of een Java‐interface voor toegang tot een databank.

1.7

ARU

In de telecommunicatiewereld is een audio response unit (ARU) een toestel dat gesproken antwoorden aanbiedt op de toetstonen (dtmf) door het afhandelen van oproepen op basis van (a) de invoer van de beller, (b) informatie gehaald uit een databank en (c) informatie uit de inkomende oproep, zoals bijvoorbeeld het uur van de dag. ARU’s verhogen het aantal afgehandelde informatieve oproepen en leveren een hoge kwaliteit voor het ophalen van informatie. In zekere zin is CTDesign dus ook als een ARU te beschouwen, aangezien het perfect voldoet aan bovenstaande definitie. Meer algemeen lijkt het mij dat en ARU een meer primitieve soort IVR‐toepassing voorstelt, en dat alle IVR’s dus in feite tegelijk ook ARU’s zijn.

B. De Coene

1.8


14

Nadelen van IVR

IVR wordt vaak bekritiseerd als onhandig en onhandelbaar als gevolg van slecht ontwerp en gebrek aan begrip voor de noden van de beller. Sommige bellers weigeren zelfs faliekant om antwoorden te verstrekken aan een automatisch systeem en wensen enkel met een menselijke operator te spreken. Een weldoordachte IVR‐toepassing dient dus onmiddellijk aan de wensen van de beller te voldoen, en dat met een minimum aan complexiteit.

Hoofdstuk 2: MI4C En wat is het verband tussen MI4C en dit alles? Het bedrijf biedt totaaloplossingen aan voor o.a. callcenters en ondernemingen die enquêtes (zowel telefonisch, face‐to‐face, als via internet) wensen uit te voeren. En aangezien het hier in hoofdzaak om de telefonieomgeving te doen is, zal ik daar wat meer uitleg over verschaffen. Dat kan het best aan de hand van onderstaande figuur, waarop een aantal componenten van het systeem afgebeeld staan.

Figuur 1: de voornaamste onderdelen van het MI4C‐CTI‐systeem

Als we nu deze componenten wat meer in detail bekijken, zal het geheel wellicht een stuk duidelijker worden. De supervisor, die zich bedient van het Supervisor‐programma, is als het ware de watchdog van de agenten. Die agenten, ook wel operatoren genoemd, zijn de personen die de

B. De Coene


15

telefoontoestellen bedienen (vaak in het contactcenter). Nadat de beller aan de andere kant van de lijn een aantal stappen heeft doorlopen (waarbij bijvoorbeeld keuzemogelijkheden worden aangeboden in de vorm van menuopties) en door het systeem wordt doorverwezen naar een menselijke operator, ofwel er zelf heeft voor gekozen een telefonist(e) aan de lijn te krijgen, komt hij/zij bij een agent terecht. Die krijgt dan, via het agentenprogramma CATI, alle stappen die de beller al heeft doorlopen, op zijn scherm te zien. Maar goed, we waren van start gegaan bij de supervisor. Die kan, naast het controleren van de agenten, ook kleine wijzigingen aanbrengen op de CCA‐server. De componenten die onder Supervisor en CATI vermeld staan, doen in het kader van dit eindwerk niet veel ter zake. Van veel groter belang zijn CCA en CTArchitect, respectievelijk de applicatie‐ en telefonieserver. De eerste verzorgt, zoals op de figuur vermeld, alles wat inbound (inkomende) en outbound (uitgaande) trafiek aangaat. CTArchitect daarentegen verzorgt de interface van de applicatie met het PSTN, zeg dus maar het telefonienetwerk. Het is echter in hoofdzaak de component rechtsboven op de figuur waar ik mee te maken heb: CTDesign. Dit programma wordt omschreven als ‘de grafische IVR‐generator’. Hiermee worden, op een volledig grafische manier, de stroomdiagrammen voor een project ontworpen. Die geven aan hoe een oproep precies behandeld wordt door de applicatie, en die behandeling kan men zich het beste voorstellen als het doorlopen van een eindige‐toestandsmachine (FSM, finite state machine), of, voor wie het liever in termen van algoritmen ziet, een graaf. Onderstaande figuur maakt deze uitleg wellicht iets makkelijker te verwerken.

Figuur 2: de FSM‐voorstelling van een project in CTDesign

B. De Coene


16

Voor meer uitleg bij deze figuur verwijs ik naar figuur 24. Daarbij staat alle nodige uitleg vermeld die hier eveneens van toepassing is. Laten we nu dichter tot de kern van de zaak naderen.

2.1

Probleemstelling

CTDesign, de door MI4C zelf ontwikkelde grafische application generator voor IVR, werkt momenteel enkel samen met het bedrijfseigen databaseformaat (Btrieve‐bestandsdatabank). Om tegemoet te komen aan een eis van vele klanten wil het bedrijf in de toekomst een door de markt aanvaard standaardformaat voor IVR‐flows aanbieden. Concreet houdt dat in dat er een extra module dient te worden geschreven, die de uitvoer van CTDesign omzet naar een ander formaat, dat voldoet aan een actuele standaard. Dat wordt wellicht VoiceXML. Toch behoren ook andere standaarden tot de mogelijkheden, en daarom zal ik die verderop wat nader toelichten. Ik kan alvast vermelden dat er van reeds bestaande oplossingen voor het gestelde probleem geen sprake was: CTDesign is een programma louter en alleen door MI4C ontwikkeld, en tot hiertoe was er nog geen sprake van VoiceXML daarbij te betrekken. Bijgevolg had zeker nog geen grondige studie plaatsgevonden omtrent de mogelijkheden van het converteren van het eigen formaat naar een algemeen aanvaarde standaard. Ik ben dus wat dat betreft van nul moeten starten. Op de volgende bladzijde staat alvast de omschrijving van dit eindwerk, zoals opgesteld door MI4C. Dit schetst een beeld van het kader waarin deze thesis past. Daarna volgen de voornaamste delen uit mijn uitgebreid eindwerkvoorstel, zodat duidelijk wordt wat ik mij had voorgenomen te realiseren, en in hoeverre dit effectief gelukt is.

B. De Coene

2.2


17

Thesisvoorstel: New standard for computerised telephony

Wie zijn we? MI4C is een jong, dynamisch en groeiend bedrijf dat zich specialiseert in hoogwaardige telecomoplossingen en tevens ook sofware aanbiedt voor gespecialiseerd marktonderzoek. Probleemstelling CTDesign, onze eigen ontwikkelde grafische application generator voor IVR (Interactive Voice Response), werkt momenteel enkel samen met ons eigen databaseformaat. Om tegemoet te komen aan een eis van vele klanten willen wij in de toekomst een door de markt aanvaard standaardformaat voor IVR‐flows aanbieden. Doelstelling De bedoeling van het eindwerk is tweeledig: • •

Analyseren van de standaard VoiceXML (Voice Extensible Markup Language) ten opzichte van andere standaarden (zoals bvb SALT – Speech Application Language Tags) om de beste toekomstgerichte keuze te maken. (+/‐ 25 %) Implementeren van een module boven op/in CTDesign die ervoor zorgt dat VoiceXML geïntegreerd kan worden. Hierbij dient ook nog bepaald te worden op welke manier dit het best gebeurt. Dit kan bijvoorbeeld via een import/export‐functionaliteit, maar andere opties kunnen ook overwogen worden. (+/‐ 75 %)

Gebruikte technologieën CTDesign wordt ontwikkeld met behulp Visual C++ en werkt boven op een dataset op basis van Btrieve. Binnen CTDesign wordt gebruikgemaakt van verschillende standaardcomponenten zoals ODBC‐koppelingen naar externe databases, VBScript engine voor het uitvoeren van bepaalde acties … De gebruikte technologieën voor de nieuwe implementatie zullen afhangen van de gemaakte keuzes. CTDesign werkt in een complete pc‐gebaseerde telefonieomgeving – zowel analoog als digitaal (VoIP), waardoor tijdens de opdracht ook in contact gekomen zal worden met onze andere softwarecomponenten, de verschillende hardwarecomponenten … Contactpersoon Filip Hoste E‐mail: [email protected]

B. De Coene

2.3


18

Uitgebreid eindwerkvoorstel: voornaamste elementen

2.3.1 Beknopte analyse

De moeilijkheid van dit project is in hoofdzaak het mappen van het ene formaat op het andere: CTDesign gebruikt een heel eigen formaat, met eigen ‘eenheden’, als ik het zo mag noemen. Zo zijn er als eenheden staten, berichten, stukjes gesproken tekst, verbindingen, projecten en applicaties. VoiceXML daarentegen gebruikt elementen zoals menu’s met scopes, choice‐elementen binnen de menu’s, forms, block‐ zowel als prompt‐elementen voor af te spelen berichten, … Bij de conversie van CTDesign naar VoiceXML zijn vooral de verbindingen moeilijk te mappen, en zal dit waarschijnlijk gesimuleerd moeten worden via verwijzingen naar andere bestanden. (Verbindingen zijn overgangen tussen verschillende staten van een applicatie, en ze kunnen afhankelijk zijn van wat de gebruiker ingeeft, of van variabelen.) Dit geeft dus ook aan dat één enkel CTDesign‐project zal moeten opgesplitst worden naar een verzameling bij elkaar horende vxml‐ bestanden. De andere eenheden zijn (misschien) iets eenvoudiger te behandelen: zo komt een bericht min of meer overeen met een prompt‐element in VoiceXML (hoewel dus ook een block‐ element in aanmerking komt). Bovendien is het ook zo dat het VoiceXML‐formaat een specificatie van maar liefst 240 pagina’s heeft (versie 2.0 althans), wat het zeker niet gemakkelijk maakt om het overzicht te behouden over de mogelijkheden. Gelukkig zijn de specificaties voorzien van voldoende duidelijke voorbeelden. De omgekeerde conversie vraagt het aanmaken van Btrieve‐bestanden die dan samen een project vormen dat door CTDesign kan worden ingelezen. Deze omzetting is van eenzelfde moeilijkheidsgraad, aangezien ze ook een conversie tussen elementen van de totaal verschillende technologieën vraagt.

2.3.2 Te verwezenlijken Deel I: (uitgebreide) analyse van de beschikbare standaarden voor IVR‐flow met aanduiding van hun sterke en zwakke punten, gevolgd door een conclusie Deel II: •

• •

conversie CTDesign → VoiceXML, waarbij zeker de meest elementaire operaties kunnen uitgevoerd worden: o een eenvoudige CTDesign‐applicatie omzetten naar het VoiceXML‐equivalent o menukeuze aan de hand van telefoontoetsen o spraakberichten afspelen conversie VoiceXML → CTDesign controleren of beide ‘formaten’ alle elementen bevatten, m.a.w. identieke functionaliteit aanbieden

B. De Coene


19

2.3.3 Mogelijke opties en uitbreidingen Indien de minimaal te verwezenlijken functionaliteit gerealiseerd wordt, kan nog aandacht besteed worden aan volgende extra’s: • • • •

spraakberichten van de respondent opnemen en opslaan logica toevoegen om variabelen op te slaan en aan de hand van hun waarde beslissingen te nemen interactie met een databank (SQL Server) mogelijk maken …

2.3.4 Potentiële problemen Hieronder som ik even de te verwachten moeilijkheden en hinderpalen op die in de thesis zullen opduiken of al opgedoken zijn: • Uit een aantal standaarden die kunnen aangewend worden voor toepassing in een IVR‐ omgeving, deze kiezen die het best aan de gestelde eisen voldoet en tegelijk het meest toekomstgericht is • Het onbekende formaat VoiceXML bestuderen: een omvangrijke standaard, met erg uitgebreide mogelijkheden • De werking en het opslagformaat van CTDesign onder de knie krijgen • Schrijven naar en lezen van een Btrieve‐database vanuit (Visual) C++ • De mapping van CTDesign‐projectelementen naar een VoiceXML‐structuur • De inverse conversie van (een of meerdere) VoiceXML‐documenten naar een structuur die een CTDesign‐applicatie voorstelt • De verificatie van equivalentie tussen de VoiceXML‐ en CTDesign‐versie van eenzelfde flow.

2.3.5 Gebruikte technologieën CTDesign wordt ontwikkeld met behulp van Visual C++ en werkt boven op een dataset op basis van Btrieve. Binnen CTDesign wordt gebruikgemaakt van verschillende standaardcomponenten zoals ODBC‐koppelingen naar externe databases, VBScript engine voor het uitvoeren van bepaalde acties … De gebruikte technologieën voor de nieuwe implementatie zullen afhangen van de gemaakte keuze wat de standaard betreft (VoiceXML of SALT of …). Het conversiegedeelte moet daarnaast ook MFC‐klassen bevatten, om de integratie met CTDesign te vergemakkelijken. CTDesign werkt in een complete pc‐gebaseerde telefonieomgeving – zowel analoog als digitaal (VoIP) – waardoor ook andere softwarecomponenten, de verschillende hardwarecomponenten … van de gebruikte telefonieomgeving aan bod zullen komen.

B. De Coene


20

2.3.6 Vernieuwende aspecten Voor het eindwerk zal zeker gebruikgemaakt worden van nieuwe technologieën en methodes, die niet in de opleiding aan bod komen of zijn gekomen. Hieronder volgt een beknopt overzicht van de nieuwigheden: • • • •

De standaard VoiceXML Het programma CTDesign met al zijn mogelijkheden om IVR‐flows te ontwerpen, alsook de broncode, een complex grafisch C++‐programma MFC‐programmeren in Visual Studio: extra functionaliteit voor GUI‐applicaties Andere standaarden die voor IVR kunnen gebruikt worden, bv. SALT

B. De Coene


21

Deel I Hoofdstuk 3: Standaarden voor IVRsystemen Er lijkt een overgang in de maak van het gebruik van bedrijfsspecifieke benaderingen voor het ontwikkelen van spraakgestuurde applicaties naar architecturen gebaseerd op standaarden (dat is trouwens net de overgang die met dit eindwerk beoogd wordt). Standaarden bieden namelijk een aantal voordelen voor de ontwikkelaars van spraaksoftware, zoals overdraagbaarheid van applicaties en de mogelijkheid de bestaande webinfrastructuur ten volle te benutten, de productiviteit van ontwikkelaars te verhogen (kennis van een low‐level API of resourcebeheer is niet vereist), en bijvoorbeeld eenvoudig multimodale applicaties te bouwen. Multimodale applicaties kunnen bepaalde tekortkomingen van single mode‐toepassingen (bediening via GUI of spraak) verhelpen, door de gebruiker te laten interageren op diverse manieren (spraak, pen, toetsenbord, …) binnen eenzelfde sessie, afhankelijk van de context. Multimodaal is in de context van IVR een uitermate belangrijk begrip, dat nog vaak zal terugkomen in deze tekst. VoiceXML, Call Conctrol eXtensible Markup Language (CCXML) en Speech Application Language Tags (SALT) zijn opkomende xml‐specificaties, ontstaan uit standaarden van industriële consortia die zich bezighouden met de ondersteuning van telefonie en spraakgestuurde toepassingen. De bedoeling is hier een beknopt overzicht te bieden van VoiceXML, CCXML en SALT, om hun rol en architectuur te schetsen, in het licht van de ontwikkeling van spraakgestuurde en multimodale telefonieapplicaties. Laten we, vooraleer in detail te gaan kijken naar de drie ‘talen’, een mogelijk scenario bekijken dat deze specificaties kan gebruiken. Op het hoogste niveau zijn er twee voor de architectuur belangrijke componenten: de documentserver en het spraak/telefonieplatform. Elk van beide interageert met een aantal secundaire servers (Automated Speech Recognition‐server (ASR), Test‐to‐Speech‐server (TTS), dataopslag). In deze architectuur genereert een documentserver de documenten als antwoord op aanvragen van het spraak/telefonieplatform. De documentserver spreekt een webapplicatie aan voor de interface met achterliggende dataopslag (berichtopslag, databanken met gebruikersprofielen, content servers) om VoiceXML‐, CCXML‐ en SALT‐documenten te genereren. Normaal gezien scheidt de globale webapplicatie de servicelogica (businesslogica) af van de presentatiedetails (VoiceXML, CCXML, SALT, html, WML) om een uitgebreidere applicatiearchitectuur te bieden. De toepassingsinfrastructuur dient ook de dialoogstaten van de toepassing bij te houden op een manier die onafhankelijk is van een specifieke presentatielaag. Om inkomende oproepen af te handelen, vraagt het spraak/telefonieplatform, via http, documenten op bij de documentserver. Een VoiceXML‐ of CCXML‐browser die zich op het platform bevindt, interpreteert de VoiceXML‐ en CCXML‐documenten om te kunnen interageren met gebruikers aan de telefoon. Meestal interageert het platform met het PSTN (Public Switched Telephone Network) en met mediaservers (ASR, TTS) en biedt het VoIP‐ondersteuning (SIP, H.323). Een ASR‐server aanvaardt spraakinvoer van de gebruiker, gebruikt een grammatica om de gesproken woorden te herkennen, en genereert een tekstueel equivalent op basis waarvan het platform kan beslissen wat de volgende

B. De Coene


22

actie zal zijn, afhankelijk van het script. Een TTS‐server aanvaardt markuptekst en genereert gesynthetiseerde spraak voor de presentatie naar de gebruiker toe. In deze opstelling interpreteert een SALT‐browser op een mobiel toestel SALT‐documenten. Onderstaande figuur illustreert een dergelijke architectuur.

Figuur 3: illustratie van een mogelijke architectuur van VoiceXML, CCXML en SALT

3.1

Een brokje geschiedenis

Gedurende het volledige computertijdperk zijn het steeds de programmeurs geweest die verantwoordelijk waren voor het schrijven van applicatielogica. Vanaf de periode waarin desktopcomputers hun opgang maakten (de jaren ’80 van vorige eeuw), verschoof het accent echter naar de gebruikersinterface, het opvangen van gebeurtenissen en het grafisch aspect dat nodig was om de toepassing tot in de handen van de gebruikers te brengen. Samengevat: weinig innovatie, en software die ontwikkeld werd door grote bedrijven. Vanaf het webtijdperk (de jaren ’90 van vorige eeuw) werden de gebruikersinterface en andere grafische elementen gerenderd door een webbrowser zoals Netscape Navigator of Microsoft Internet Explorer. Programmeurs konden een volledig systeem aan de eindgebruiker afleveren na enkel de applicatielogica en wat eenvoudige html‐code voor de interface te hebben gecodeerd. Dit was een hele revolutie en vernieuwing, aangezien een heleboel webapplicaties nu in luttele maanden werden ontwikkeld door een handvol programmeurs. Niemand kan eraan voorbijgaan dat telefoontoestellen een stuk verder staan in draagbaarheid en nog meer ingeburgerd zijn dan pc’s en webbrowsers. Verder is het zo dat een telefoon betrekkelijk eenvoudig in gebruik is, daar waar toch wel een redelijke groep gebruikers weinig of geen geduld heeft met de veel complexere computer. Het lijkt dan ook niet onlogisch dat men een informatiesysteem toegankelijk wenst te maken voor gebruikers die enkel over een telefoon beschikken. Hoe zou men hierbij te werk kunnen gaan? In 1980 zouden hiervoor de huur van een

B. De Coene


23

telefoonlijn, een omvangrijk toestel om spraak te herkennen en nog een ander groot toestel om te praten tegen de gebruiker noodzakelijk geweest zijn; deze toestellen zouden logischerwijze naast de applicatieserver terechtgekomen zijn. In de jaren ’90 was er enkel nog nood aan de telefoonlijn en gespecialiseerde software, die zelfs kon draaien op een doordeweekse pc! Men kon ermee volstaan deze pc (voor de spraakherkenning – aan de serverkant) naast de toepassingsserver neer te zetten. Met de opkomst van de hedendaagse voice browsers worden de komende jaren allicht veelbelovend wat betreft de vernieuwing in het ontwikkelen van via de telefoon toegankelijke internettoepassingen. Bij een webapplicatie bevinden zich aan de ene kant de http‐server en de applicatiecode, en aan de andere kant de browser. Bij een voice browser is het idee hetzelfde. Aan de ene kant zijn er de server en de toepassing. De andere zijde, bv. de telefoonmaatschappij, zorgt voor de telefoonlijn en de voice browser. Conclusie: voice browsers laten toe telefonische spraakapplicaties te ontwikkelen enkel en alleen op basis van een http‐server. Deze eenvoud zal voor een enorme vernieuwing zorgen.

3.2

VoiceXML

Nu we een globaal beeld hebben van de architectuur waarin deze specificaties kunnen gebruikt worden, kunnen we wat meer in detail gaan kijken naar VoiceXML. VoiceXML kan beschouwd worden als een zoveelste presentatielaag (naast html, wml). Het verschil zit hierin: html wordt gerenderd door de webbrowser om inhoud en formulieren weer te geven; VoiceXML wordt door een voice browser gerenderd. VoiceXML is een dialooggebaseerde xml‐taal die toelaat interactieve spraakapplicaties te ontwikkelen voor toestellen zoals telefoons en gsm’s. Het is een op zichzelf staande presentatietaal, bedoeld om gebruikersinvoer in de vorm van dtmf (toetstonen voortgebracht door een telefoon) en spraak te aanvaarden en uitvoer in de vorm van gesynthetiseerde spraak en vooraf opgenomen geluidsfragmenten te genereren voor de gebruiker. Het is niet bedoeld om in een bestaande webtaal (zoals html en wml) ingebed te worden en bijvoorbeeld het html‐eventmechanisme uit te breiden (hetgeen wel zou kunnen gezegd worden van SALT). VoiceXML wordt tegenwoordig gebruikt voor diverse doeleinden – bijvoorbeeld voor het afhandelen van klanten in callcenters. Het wordt eveneens aangewend om gebruikers in staat te stellen hun berichten (e‐mail, voicemail, fax) en andere persoonlijke informatie (adresboeken) te ordenen. 3.2.1

Configuratie

Net als vroeger is het nog steeds mogelijk een telefoonlijn te huren en commerciële text‐to‐speech‐ en spraakherkenningssoftware te draaien. Het interessante aan VoiceXML is nu net dat dat niet meer hoeft! Er bestaan namelijk VoiceXML gateways, zoals BeVocal (www.bevocal.com), Voxeo (www.voxeo.com) en VoiceGenie (www.voicegenie.com). Deze programma’s halen VoiceXML‐ webpagina’s van de webserver en lezen ze voor aan de gebruiker. Als de applicatie invoer verwacht, zal de gateway het binnenkomend bericht interpreteren en doorgeven aan de server op een manier die voor de software verstaanbaar is.

B. De Coene


24

Er moet gebruikgemaakt worden van een webformulier om de gateway met de url van de applicatie te configureren. Op die manier zal een telefoonnummer aan de toepassing worden gehecht. Gebruikers kunnen dan gewoon dat nummer bellen vanaf een doordeweekse eenvoudige telefoon, om op die manier met de applicatie te ‘spreken’.

Figuur 4: een mogelijke architectuur voor een VoiceXML‐systeem

Een paar woorden uitleg bij bovenstaande figuur zijn wellicht niet overbodig. Html‐gedeelte: de http‐ server gebruikt html om de gebruiker een interface aan te bieden; deze interface wordt op het scherm van de pc weergegeven. VoiceXML‐gedeelte: de http‐server gebruikt VoiceXML die op een third‐party gateway gerenderd wordt en als audio wordt doorgespeeld aan de telefoon van de gebruiker. 3.2.2 Structuur Om ten volle in te zien hoe VoiceXML kan worden gebruikt, is het nodig de structuur, elementen en mechanismen ervan te kennen. Een VoiceXML‐applicatie omvat een aantal documenten, die elk hetzelfde rootdocument delen. Wanneer een willekeurig document uit de applicatie geladen wordt, wordt dat rootdocument mee ingeladen. Gebruikers bevinden zich steeds in een dialoog (de interactie tussen een gebruiker en het spraak/telefonieplatform wordt voorgesteld door een dialoog). Gebruikers zorgen voor invoer (dtmf of spraak) en krijgen dan, op basis van de applicatielogica in het document, een nieuwe dialoog die voor uitvoer zorgt (audiobestanden of gesynthetiseerde spraak) en verdere invoer aanvaardt, om zo tot nog een andere dialoog te komen. De uitvoering eindigt als er geen verdere dialoog meer is gedefinieerd. Overgangen tussen dialogen worden gemaakt via URI’s (een mechanisme dat bekend is van andere markuptalen). 3.2.3 Een voorbeeld: Hello World Het formaat van een VoiceXML‐document is erg eenvoudig. Het voorbeeld hieronder illustreert hoe we “Hello World” kunnen uitdrukken:

B. De Coene


25

Figuur 5: Hello World met VoiceXML

De tag geeft aan dat het hier een VoiceXML 2.0‐document betreft. Binnen dit element is er een
, dat ofwel kan dienen voor interactie – er wordt dan invoer verwacht van de gebruiker – of een louter informatieve functie kan hebben. Er staat geen beperking op het aantal ‐elementen in een VoiceXML‐document. Een ‐element is als het ware een opslagplaats voor uitvoerbare code; hiermee wordt bedoeld dat alle tags die ervoor zorgen dat de applicatie iets ‘doet’, zoals ,

CTDesign-VoiceXML-convertor

Recommend Documents