PROSJEKTOPPGAVEpeople.item.ntnu.no/~lillk/stud-proj/soevik-IVR.pdf · FAKULTET FOR...

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG

ELEKTROTEKNIKK

PROSJEKTOPPGAVE

i faget TTM4700, Teletjenester og nett

Oppgavens tittel:

Interaktiv taleresponstjeneste

Levert av:

Andreas Wille Søvik

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG

ELEKTROTEKNIKK

PROSJEKTOPPGAVE Kandidatens navn: Andreas Wille Søvik Emne: TTM4700, Teletjenester og nett Oppgavens tittel: Interaktiv taleresponstjeneste Oppgavens tekst: Oppgaven går ut på å sette seg inn i behov og virkemåter for IVR og/eller VoiceXML-løsninger. Det skal gis en oversikt og sammenligning av disse med fokus på anvendelser og tekniske egenskaper. Hvordan kan taleløsninger brukes i tjenestesammenheng, hvilke eventuelle uavdekte bruksområder finnes det og har taleløsninger egne tjenesteplattformer eller må de brukes sammen med andre tjenesteplattformer. Oppgaven skal komme fram til en enkel IVR-løsning som skal være en del av en callcenter tjeneste. For at dette skal være mulig må selve IVR’en lages i tillegg til at to grensesnitt defineres. Disse er mot Dialogic kortet som skal stå i maskinen som kjører IVR løsningen. Det andre er grensesnittet mot tjenesteplattformen hvor callcentret ligger, som skal være selve brukeren av IVR løsningen. Under konstruksjon av grensesnittet mot callcentret må det benyttes en teknologi som er kompatibel både mot ActorFrame og IVR kortet. Dette løses i samarbeid med callcenter oppgaven. Valg av teknologi vil bli gjort etter en vurdering av tilgjenglige teknologier. Tilslutt vil en evaluering av løsningens generalitet bli gjort. Besvarelsen leveres innen: 5. desember 2003

Besvarelsen levert: 5. desember 2003

Utført ved: Institutt for telematikk

Veileder: Senior Konsulent Rune Viken, for GINTEL AS

Trondheim, 5. desember

Lill Kristiansen Professor


Forord Denne prosjektoppgaven er skrevet av Andreas Wille Søvik som går 5. årstrinn på sivilingeniørstudiet for Kommunikasjonsteknologi (NTNU), med fordypning i Teletjenester og nett. Oppgaven er skrevet for institutt for Telematikk, NTNU, høsten 2003, og er en del av fordypningsemnet TTM4700 med et omfang på 22,5 studiepoeng. Bakgrunnsmaterialet til oppgaven er hentet fra tekniske spesifikasjoner, papers, lærebøker og Internet. Jeg vil rette stor takk til Professor Lill Kristiansen og Senior Konsulent Rune Viken fra Gintel AS for inspirasjon og gode ideer i utviklingen av oppgaven. Jeg vil også benytte anledningen til å takke de andre ansatte ved Gintel for deres støtte og engasjement i oppgaven. Trondheim, 5. desember 2003 Andreas Wille Søvik

i


Innholdsfortegnelse Forord_________________________________________________________________ i

Innholdsfortegnelse______________________________________________________ ii

Figurliste______________________________________________________________ iii

Tabelliste______________________________________________________________ iii

Sammendrag ___________________________________________________________ iv

1. Innledning _________________________________________________________ 1 1.1. Bakgrunn ___________________________________________________________ 1 1.2. Avgrensning_________________________________________________________ 1 1.3. Oppbygning _________________________________________________________ 2

2. Arkitektur _________________________________________________________ 3 2.1. Intelligente nett ______________________________________________________ 3 2.2. Parlay ______________________________________________________________ 4

2.2.1. Om Parlay _______________________________________________________________ 4 2.2.2. Hva gir Parlay oss? ________________________________________________________ 4 2.2.3. Hva er Parlay API’ene? _____________________________________________________ 5

2.3. Grensesnitt__________________________________________________________ 6 2.3.1. GUI / UI_________________________________________________________________ 6 2.3.2. Interactive Voice Response __________________________________________________ 7

2.4. Web services ________________________________________________________ 8 2.5. Teknologi ___________________________________________________________ 8

2.5.1. Intel Dialogic SingleSpan/D300JCT-E1 ________________________________________ 8 2.5.2. Global Call______________________________________________________________ 11

3. Design ___________________________________________________________ 14 3.1. Overordnet løsning __________________________________________________ 14 3.2. IVR tjenesten. ______________________________________________________ 16

4. Implementering ____________________________________________________ 18 4.1. Valg av utviklingsverktøy_____________________________________________ 18 4.2. IVR tjenesten_______________________________________________________ 18

4.2.1. Min webservice __________________________________________________________ 20 4.2.2. TCP / IP socket server _____________________________________________________ 22 4.2.3. IVR kontroller ___________________________________________________________ 26

4.3. Grensesnitt mot callcenter ____________________________________________ 29 4.3.1. Oversikt over protokollen __________________________________________________ 29 4.3.2. Svarmeldinger ___________________________________________________________ 29 4.3.3. Feilhåndtering ___________________________________________________________ 30 4.3.4. Meldingsformat __________________________________________________________ 30 4.3.5. Meldingssekvensdiagrammer _______________________________________________ 31 4.3.6. Meldinger ______________________________________________________________ 34

ii


5. Konklusjon _______________________________________________________ 37

6. Referanseliste _____________________________________________________ 37

7. Vedlegg __________________________________________________________ 38 7.1. Bruk av CD-ROM___________________________________________________ 38 7.2. CD-ROM __________________________________________________________ 38

Figurliste Figur 1. Hvordan Parlay X, er knytte sammen med resten av Parlay rammeverket, fra [2] ____________ 5 Figur 2. Parlay til data og telenett, fra [2] __________________________________________________ 6 Figur 3. Dialogic interface med telefon nettet, fra [3] ________________________________________ 10 Figur 4. Global Calls arkitektur, fra [5] ___________________________________________________ 12 Figur 5 Tilstandsdiagram til Global Call ved en innkommende asynkron samtale, fra [5] ____________ 13 Figur 6. IVRens innpass i nettet. _________________________________________________________ 15 Figur 7. IVR tjenesten _________________________________________________________________ 17

Tabelliste Tabell 1 Global Call hendelser, med forklaring _____________________________________________ 28 Tabell 2 Tale ressurs hendelser, med forklaring _____________________________________________ 28

iii


Sammendrag Oppgaven har sitt utspring i at alle dagens IVR løsninger er properitære. Gintel er et firma som har spesialisert seg innen IN teknologi og ønsket seg et IVR system som kunne benytte seg av flere plattformer. Dette krever at man finner en måte å kommunisere på som er allment gyldig og er anvendbar. Jeg har jobbet med en helt ordinær datamaskin med et såkalt mediakort installert og laget en fullt brukbar IVR tjeneste, som pr. i dag kjører sammen med et call center. Tjenesten tar i mot kommandoer fra call centeret om hvilke meldinger som skal spilles av for brukeren. IVRen tar vare på inntastningen fra brukeren og sender tilbake til call centeret. Kommunikasjon mellom call centeret og IVRen går gjennom web service grensesnitt. Nettopp dette, er det som gjør denne oppgaven til et unikum; en kan legge til en hvilken som helst applikasjon - web klient funksjonalitet slik at den kan sende meldinger til IVRen om hva den skal gjøre.

iv


1. Innledning

1.1. Bakgrunn Dagens taleapplikasjoner er kompliserte og løsningene er properitære. Riktignok finnes det mange av dem og man kan med rette spørre seg om hvorfor det skal være nødvendig å lage noe som allerede finnes. Svaret på dette er enkelt, men før jeg svarer på det vil jeg si litt mer om dagens løsninger. Per i dag er det som nevnt mange properitære systemer, og hver eneste tjeneste er skreddersydd for en enkel løsning. Dette fører til at det er nesten like mange forskjellig taleapplikasjoner som det er ulike tale tjenester. Resultatet av dette blir at hver gang en løsning skal lages må den lages fra bunn av og dette fører med seg mye dobbeltarbeid med tanke på at arbeidet er gjort før bare for en annen plattform eller tjeneste. Ulempen med dette er selvsagt sløsing med tid, for den enkelte applikasjonsutvikler og at man må vite hvordan hver eneste taletjeneste fungerer for at man skal kunne utvikle på den. Hensikten med oppgaven er å lage et felles grensesnitt mot taleapplikasjonene slik at denne form for applikasjonsutvikling blir mer tilgjenglig. Hurtigere applikasjonsutvikling vil også være et resultat av dette. Hvis grensesnittet er kjent vil man slippe å bry seg om kommunikasjon med telenettet som er den vanskeligste delen av en slik tjeneste.

1.2. Avgrensning Oppgaven har vært først og fremst en praktisk oppgave. Derfor har det vært naturlig å bruke mye tid på å få IVR tjenesten til å fungere så bra som mulig. Av denne grunn er det en fordel at leseren har kjennskap til temaer som intelligente nett, parlay konsortiet og IVR fra tidligere, da dette ikke er diskutert i detalj. Dette er på ingen måte en forutsetning, men det vil øke forståelsen for oppgaven.

1


1.3. Oppbygning Oppgaven består av 5 kapitler hvorav kapittel 2 til 4 utgjør hoveddelen. Kapittel 1 er

innledning og kapittel 5 er konklusjon. Hoveddelen har jeg organisert på følgende måte:

• I kapittel 2 presenteres noen av de bakenforliggende teknologier, som er

nødvendig for å forstå hvordan oppgaven er laget og hvordan tjenesten fungerer.

• I kapittel 3 tar jeg for meg programdesign. Her vil tjenesten settes i sammenheng

med de teknologier den spiller sammen med. Det vil være diagrammer som viser

dette, både overordnet og i detalj.

• I kapittel 4 presenteres min løsning på oppgaven. Den vil gå igjennom de enkelte

deler av programmet som har vært nødvendig for å få det til å fungere som det

gjør.

Hensikten med oppbygningen har først vært å vise hvordan tjenestene i dag ville fungert hver for seg og deretter vise hvordan de kan spille sammen. Til slutt vil jeg se på om resultatet ble som forventet og evt. Hvorfor det ikke gikk som det skulle ha gått.

2


2. Arkitektur Kapittelet beskriver de ulike teknologiene som er benyttet for å løse oppgaven. Hensikten er å si litt om teknologiene for de som kan noe om de. Begrunnelser for hvorfor disse er valgt kommer lenger ut i kapittel tre og fire. Ikke bare tar det for seg hva tjenestene er men også hva som finnes av hardware og software for å få dette til. Samspillet mellom disse og oppgaven vil man se utifra kapittel 6, design.

2.1. Intelligente nett Tradisjonelle telefontjenester som vi kjenner dem i dag, går på å sette opp en samtale mellom to brukere gjennom ett aksessnett. Intelligente nett (IN) ble introdusert av Bell i USA som en måte å gi telenettet mer avansert funksjonalitet. Eksempel på tilleggsfunksjoner til nettet var særbehandling av enkelte telefonnummer og nummerserier (800 - nummer). IN ble først og fremst tatt i bruk for å markedsføre et konsept for hvordan slike tjenester kan realiseres. Intelligente nett ble av Bell fremlagt som måten å koble sammen nettkomponenter for å muliggjøre den avanserte tjenestefunksjonaliteten. Umiddelbart etter Bells lansering av IN begynte et standardiseringsarbeid for IN både i ITU (International Telecommunication Union )og ETSI (European Telecommunications Standards Institute). ITU’s standardiseringsarbeid for IN står omtalt Q.1200 serien fra september 1997. Generelt har dette arbeidet gitt følgende definisjon. ”Intelligent network is an architectural concept for the creation and provision of telecommunication services which is characterised by:

• Extensive use of information processing techniques • Efficient use of network resources • Modularisation of network functions • Flexible allocation of network functions among physical entities • Standarised communication between network functions via service independent

interfaces • Access to the process of composition of services through the combination of

network functions • Consumer control of some of his specific service attributes • Standarised management of service logic”

Kort fortalt består IN av mer eller mindre ”intelligente” noder i nettet som switcher telefonsamtaler på bakgrunn av forhåndsbestemte regler. Videre kan man for eksempel ha ulike betalingsregler for tjenestene.[1],[4]

3


2.2. Parlay Teksten er basert på [2]. Lesere som ønsker mer kunnskap om Parlay henvises dit.

2.2.1. Om Parlay Parlay konsortiet ble dannet i 1998, samtidig som den trådløse internett eksplosjonen kom for alvor verden rundt. På den tiden, var telekommunikasjon applikasjoner og tjenester en del av nettverksadministratorens arbeidsområde og disse ble primært utviklet med verktøy som var spesialisert for telebransjen. Dette var for så vidt ikke noe problem så lenge applikasjonene kun samhandlet med andre teleapplikasjoner, men med oppblomstringen av mobile applikasjoner og IP, økte behovet for applikasjoner som kombinerte telekom tjenester med internett tjenester og kritiske virksomhetsdata. Dette førte til at helt nye dimensjoner av tjenester vokste fram som hadde stor betydning for enkeltbrukere og virksomheter. Parlay konsortiet ble startet av en samling av teleoperatører, IT leverandører, nettverksutstyr leverandører og applikasjonsutviklere. De satte seg som mål å mette det nye behovet som var oppstått og å spesifisere API’er som kombinerte det beste fra telebransjen og IT verdenen. For å få til dette spesifiserer og fremmer de API’er som er sikre, enkle å bruke, funksjonsrike og som er basert på åpne standarder. Spesifikasjonene blir laget og standardisert med deltakelse fra Parlay Joint Working Group (JWG), som inkluderer Third Generation Partnership Program (3GPP), Third Generation Partnership Program 2 (3GPP2) og European Telecommunications Standards Institute (ETSI) Services and Protocols for Advanced Networks.

2.2.2. Hva gir Parlay oss? Parlay integrerer mulighetene i telekom nettverket med IT applikasjoner med sikre, gjennomtenkte og fakturerbare grensesnitt. Parlay’s åpne API frigjør utviklere fra å skrive kode for bestemte nettverk og miljøer, og med dette reduserer risiko og kostnader for prosjektet, noe som igjen åpner for at nyskapende tjenester blir levert gjennom telekom-nettverksoperatør kanalene. Med Parlay’s nettverksuavhengige API’er, genererer applikasjonene nye avgifts muligheter for nettverksoperatørene, applikasjons tjeneste tilbyderene og uavhengige program utviklere. Parlay ble med tiden svært komplisert og derfor ble Parlay X introdusert. Parlay X er et subset av Parlay, enklere å lære å støtte for web services. Dette gir en unik mulighet til å knytte sammen Parlay applikasjoner sammen med ikke Parlay applikasjoner. Nettopp denne muligheten er det jeg også benytter meg av i denne oppgaven, da tjenesten jeg jobber sammen med bruker Parlay og vi har da muligheten til å kommunisere ved hjelp av web services.

4


Figur 1. Hvordan Parlay X, er knytte sammen med resten av Parlay rammeverket, fra [2]

2.2.3. Hva er Parlay API’ene? Parlay API’ene muliggjør kjøring av tredje parts applikasjoner innenfor en teleoperatørs nettverk og samtidig som at applikasjonene kjøres på eksterne applikasjonsservere for å tilby tjenester til abonnentene gjennom en sikker gateway. I tillegg til å tilby sikker, konfigurerbar tilgang til mulighetene i tjeneste tilbyderens nettverkt, kobler også Parlay tredje parts programvare til nettverksoperatørens nettverk via Parlay rammeverket. Parlay rammeverket er et kraftig verktøy som gjør nye virksomhets modeller mulige, gjennom å lage et fellesskap mellom nettverksoperatørene og tjenestetilbyderne som går utover internetts begrensede muligheter.

5


Figur 2. Parlay til data og telenett, fra [2]

2.3. Grensesnitt

2.3.1. GUI / UI Grensesnitt mot dagens applikasjoner varierer stort. De fleste av oss kjenner begrepene GUI og UI, hvor GUI står for Graphical User Interface eller grafisk bruker grensesnitt. GUI kjenner vi best gjennom klikkbare ikoner enten det er på en mobiltelefon eller det er på en PC. UI står da kun for User Interface eller bruker grensesnitt. Dette kjenner vi best som tekst baserte grensesnitt, som for eksempel fra operativsystemet DOS eller mer aktuelt kanskje, Linux. Riktignok har man GUI med Linux også, hvis man installerer X, men det er slett ikke nødvendig. Tale grensesnitt eksisterer også, enten sammen med GUI eller UI men også alene, som for eksempel ved opplesning av feilkoder på hovedkort. Dette er som sagt de tradisjonelle grensesnittene, men vi har også flere hvis vi tenker oss om. Tale er et grensesnitt, enten det er tale ut fra en webside eller det er fra en telefon. Og bruker man en telefon kan man samhandle med tjenesten enten ved å gi tale tilbake eller ved å bruke DTMF. DTMF står for ”dual tone multi frequency”, og er det signalet du gir teleoperatøren din når du taster en tast på telefonen. Navnet kommer av at for hver gang du taster en knapp på telefonen din generer du to toner med hver sin frekvens, som da blir tolket som én tast hos teleoperatøren din. Hensikten med dette er at det skal være umulig

6


å gjengi disse lydene med tale. Etter sigende skal dette riktignok også være gjort, men det er ikke dette noe stort problem. Hvert siffer har en lav frekvens og en høy, for å vanskeliggjøre etterligninger. Sistnevnte er den aktuelle tilbakemeldingsformen for brukeren i denne oppgaven, og den beskrives mer utdypende i neste kapittel. For å oppsummere har vi ulike typer grensesnitt, i hovedsak varierer disse om man bruker telefon eller om man bruker en datamaskin, eller avansert mobiltelefon med skjerm. For datamaskinen, vil man ha tekst ut til brukeren, klikkbare ikoner og andre klikkbare felter og for eksempel tale ut fra en webside med VoiceXML. Telefon vil innebære tale ut til brukeren, eventuelt tale tilbake til applikasjonen og tilbakemeldinger gjennom DTMF. Du vil verken ha tekst ut eller noen ikoner eller annen form for GUI. Et interessant tema er talegjenkjenning som tilbakemeldingsform, men det temaet er ikke aktuelt for denne oppgaven, men kan absolutt være noe som hadde gjort tjenesten mer interessant.

2.3.2. Interactive Voice Response Interactive Voice Response (heretter forkortet IVR) er en applikasjon som godtar en kombinasjon av tale, telefoni og inntastingstoner (DTMF) og tilbyr passende tilbakemeldinger på formen tale, faks, tilbakeringing osv. Applikasjonen kjører på vanlige maskiner men et talekort med et gitt antall telefonlinjer må være til stede. En IVR er vanligvis en del av et større system som den kommuniserer med og står sjelden eller aldri alene. De fleste av oss møter slike systemer ukentlig ja kanskje daglig, når man ringer kundeservice i en bedrift og lignende. IVR løsninger er løsninger som automatiserer og er tidsbesparende innenfor enkelte applikasjoner. Som en følge av at løsningen automatiserer vil den også kunne gjøre jobben til flere arbeidstakere i en bedrift. Så selv om det er en relativt dyr installasjon både med tanke på hva hardware koster og hva det koster å få utvikle en løsning, vil en IVR spare penger for en bedrift i det lange løp. Dette vil komme klart frem senere, da kapittelet tar for seg hvilke tjenester IVRen kan utføre. Vanlige arbeidsoppgaver for en IVR er:

• Bank og aksje konti ballanser og overføringer. • Spørreundersøkelser og avstemninger • Kundesenter løsninger • Enkle bestillingssystemer, f.eks. kino • Informasjonsinnhenting, f.eks. kino

En ordinær IVR applikasjon tilbyr ferdig innspillte talemeldinger som spilles av for brukerne av systemet ved gitte hendelser, logikk etter utført inntasting fra bruker, tilgang til relevante data og mulighet for å ta opp tale fra en bruker for senere bruk. Ved bruk av

7


Computer Telephony Interaction kan man få opp ytligere informasjon om innringeren fra databaser og se disse på en skjerm og å se på autitentiseringsdata for innringeren, for eksempel om telefonnummeret er en lovlig bruker av tjenesten. Denne oppgaven fokuserer på en begrenset callcenter løsning hvor IVR’ens oppgave er å spille av talemeldinger på kommando fra callcenteret til en bruker som skal respondere med inntastinger. IVRen skal formidle disse inntastingene tilbake til callcenteret for så og få videre instrukser.

2.4. Web services Web services er uavhengige funksjoner som er tilgjenglig over internett. De er skrevet i henhold til nøyaktige spesifikasjoner, slik at de kan samarbeide med andre tilsvarende funksjoner. Noen av de mer etablerte funksjonene er meldingsformidling og beskrivelser av tekniske tjenester. Men andre er selvsagt også i bruk. Web services er nyttige for de gjør det mulig at flere ulike systemer kan kobles sammen på en sikker, enkel måte, som er standardisert. Samtidig som bedrifter hele tiden ønsker å knytte seg nærmere leverandører og kunder både på lang og kort sikt, er det viktig å ha et verktøy for hånden, som kan gjøre dette enkelt. Web services er nettopp et slikt verktøy. Styrken ligger i at en kan ikke bare kan sende meldinger til andre web services på en enkel måte men en kan også der det er behov for mye regnekraft, sende variabler over en web service til en annen rask maskin som kan utføre operasjonene og deretter returnere svaret. I tilfellet mitt brukes web services til å styre IVR maskinen. I og med at web services baserer seg på åpne standarder, er det tilgjenglig for mange systemutviklere. Resultatet av dette blir at konkurransen blir stor og at kostnadene ved å lage en slik tjeneste går ned. Konkurransen blant leverandørene av slike tjenester oppmuntrer til innovasjon i produktene og i tjenestene som tilbys bedriftene. Ved å basere systemer på standarder hindrer man også at løsningene kun passer en type maskin eller programvare.

2.5. Teknologi

2.5.1. Intel Dialogic SingleSpan/D300JCT-E1 Mye av stoffet er basert på [3] Intel Dialogic SingleSpan er betegnelsen på serien av telekom produkter som Intel tilbyr markedet. Denne serien er mer korrekt identifisert som et medie bearbeidelseskort, hvor mediet for eksempel kan være tale. Taleteknologi omslutter prosessering og manipulasjon av et talesignal i et datamaskin-telefon system, noe som innebærer: filtrering, analysering, opptak, digitalisering, komprimering, lagring, utvidelse og avspilling. I tillegg inkluderer det muligheten for å motta, kjenne igjen, og å generere spesifikke telefon og nettverks

8


toner. Denne typen teknologi i slike systemer er som regel standard og ikke spesielt for Intel sin løsning. Alle kortene i SingleSpan JCT serien gir digitale nettverksgrensensitt som er H.100 støttet. Det støtter digital signalering teknologi, industristandarden PCI bussen og CT bussen (Computer Telephony). CT-buss åpner for muligheter til å koble sammen flere kort slik at det vil få flere linjer inn og økt kapasitet. At kortet ikke har andre krav til maskin enn at det har støtte for PCI buss gjør at det er meget anvendbart og kan brukes i så å si alle PC’er. Kortene støtter media funksjoner som tale prosessering, tale gjenkjennings programvare, faks, tone signalering, global tone detektering, global tone generering, analyse av fremdriften til en samtale noe som gjør de ideelle for tjenestetilbydere. ISDN Primary Rate Interface (PRI) firmware er standard på alle kort i SingleSpan-JCT serien og denne er blant annet godkjent for de fleste protokoller basert på både T-1 (1.544 Mb/s) ogE-1 (2.048 Mb/s) fysiske grensesnitt. Som vi ser av kortbeskrivelsen, SingleSpan-D300JCT-E1, er kortet basert på E1 grensesnittet, hvilket betyr at det besitter 30 ISDN B kanaler og 2 D kanaler. I tillegg har kortet 30 taleressurser, altså en til hver talekanal. B kanalene er kun for samtalehåndtering / anropshåndtering, mens talekanalene er for opptak og avspilling av lyd på B-kanalen. ISDN PRI gir oss en rekke funksjonalitet, jeg vil raskt trekke frem de viktigste for denne oppgaven og de som er blitt tatt i bruk av denne. Dialed Number Identification Service (DNIS) – automatisk gjenkjenning av telefonnummeret som ble tastet inn. Automatic Number Identification (ANI) – Identifiserer innringeren med telefonnummeret (a nummer). Dynamisk sette protokoll timere gjennom API’s Videre støttes Global Call programvaren, et call control programmerings grensesnitt og protokoll motorsom gjør det enklere å utvikle nettverksapplikasjoner for telefonnettet uavhengig av nettverksprotokollene. Global Call kan leses mer om i neste kapittel.

9


Figur 3. Dialogic interface med telefon nettet, fra [3] Figuren viser hvordan Dialogic kortet setter programutvikleren i kontakt med telefonnettet. Vi ser også at uavhengig av hvor mange kort som benyttes vil vi kun benytte oss av en PCI kortplass i maskinen, tilkobling av flere kort går gjennom CT bussen. Kortet er heller ikke avhengig av Global Call, men at dette kun er et foretrukket API. PBX (Private Branc Exchange) er multiplekser som gir muligheten for at lokale linjer på den ene siden av kortet kan bruke samme linje på utsiden; mye brukt i bedrifter så man slipper og tilordne et telefonnummer til hver ansatt. Automated Speech Recognition (ASR) programvare kan også kobles til kortet, slik at men kan lage tjenester man kan prate til og for talegenerering.

10


2.5.2. Global Call Kapittelet er basert på utdrag fra [5] Global Call er Dialogic’s standard for call control. Global Call utviklingsverktøy gir et felles signalerings grensesnitt for nettverksapplikasjoner, uavhengig av signaleringsprotokollen som brukes på det lokale telefonnettverket. Signalerings grensesnittet som Global Call tilbyr, forenkler utvekslingen av call control meldinger mellom telefonnettet og nettverksapplikasjoner. Det gir utviklere mulighet til å lage applikasjoner som kan jobbe med signalerings systemer over hele verden, uavhengig av hvilket nettverk det er og hvilke applikasjoner som er tilkoblet. Det er ideelt for store nettverksløsninger, som tale, data og video applikasjoner, hvor hardware og signaleringsteknologi varierer fra land til land. Det er implementert som et API og fungerer på ulike typer telefon nettverk:

• Analog • Digital CAS • ISDN • SS7

Global Call kjører på følgende plattformer og arkitekturer:

• SpringWareTM eller R4-based • DM3-baserte kort • Ikke-Dialogic kort

GlobalCall består i hovedsak av tre hoved komponenter

• Global Call API Et enkelt, utvidbart API som tilbyr deg nettverksgrensesnittene på et høyere nivå. Det forenkler utvekslingen av call control meldinger mellom telefonnettet og nettverksapplikasjoner.

• Global Call - Call Control Biblioteker

Biblioteker som gir et grensesnitt mellom Global Call API og de ulike nettverk signalerings protokoller.

• Global Call Protokoller

Nettverk signalerings protokoller, som T-1 Robbed Bit, E-CAS, ISDN, Analog, QSIG, SS7, og IP H.323, kan bli anropt fra GlobalCall API for å utføre call control.

11


Figur 4. Global Calls arkitektur, fra [5] Figuren setter Global Call i kontekst med PSTN nettet og brukerapplikasjonen. Vi ser at for programmereren vil nettverksarkitekturen være transparent. Global Call API’et er et call control API. På samme måte som de andre Intel Dialogic API’er, som Voice API, bruker GlobalCall API, Standard Runtime Libary (SRL) API til å levere svarhendelser til de respektive API kall. GlobalCall muliggjør ikke bare call control men også funksjoner for støtte operasjoner, administrering og vedlikeholds oppgaver. Som et eksempel, signal kvitteringen eller informasjonsflyten som er nødvendig for å etablere en samtale vil variere utifra hvilket land en befinner seg i. Istedenfor å kreve at applikasjonen håndterer lavnivå detaljene, vil Global Call programvaren tilby et konsistent høynivå grensesnitt til brukeren og håndterer i tillegg de ulike lands unike protokollkrav, transparent for applikasjonen. Tilstandsdiagrammet under viser oss de ulike tilstandene når en samtale komme inn til global call. Hver transisjon er indikert med enten heltrukket eller stiplet linje, hvor heltrukket er et absolutt av hva programmereren må benytte seg av når han programmerer. Vi ser også hvilke kall som starter en transisjon. Hva de forskjellige hendelsene betyr står i tabell 2. Den røde streken indikerer hva som er benyttet i denne oppgaven.

12


Figur 5 Tilstandsdiagram til Global Call ved en innkommende asynkron samtale, fra [5]

13


3. Design Dette kapittelet har til hensikt å klargjøre hva tjenestens oppgave er og hvordan det er implementert på et høyere nivå enn implementasjon kapittelet.

3.1. Overordnet løsning Denne første delen av kapittelet setter fokus på, hva IVRen skal gjøre, for å sette leseren raskt inn i den praktiske betydningen av IVR. Senere vil det bli vist hvordan dette faktisk gjøres og hvordan det fungerer i dag. IVR maskinen står plugget rett i telenettet på en E-1 linje. E-1 er et europeisk digitalt transmisjons format som kan bære 32 kanaler á 64 Kbps til sammen 2048 Mbps. Det vil si at den kan ha 30 samtidige samtaler, fordi 2 av kanalene går til signalering på linjen. Videre er den koblet til IP nett med et standard nettverkskort. For å vise hvordan tjenesten fungerer har jeg tegnet en nummerert figur, hvor IVR maskinen er tegnet i sammenheng med resten av nettet som benyttes av løsningen. Løsningen vil være IVR tjenesten og Call center tjenesten sammen. Løsningen skal tilby call center funksjonalitet, hvor en bruker ringer et nummer og får opplest en meny, velger et av meny elementene og for eksempel blir satt over til en kunde konsulent. Tallene nedenfor indikerer hva som skjer ved tilsvarende tall på figur 7. 1. Når systemet startes opp, registrerer call centeret seg i IVR tjenesten. Det er først og

fremst fordi IVRen kan tjene flere tjenester og da er det nødvendig at IVRen sender til bake info om for eksempel inntastinger til riktig tjeneste. Den sender da med URL til web servicen som skal ta imot informasjon av denne art.

2. Innringeren er i denne sammenhengen en kunde som ønsker å benytte seg av tjenesten call centeret tilbyr. Innringeren kan godt ringe fra en mobiltelefon så vel som fra en fast telefon.

3. Videre kommer samtalen fram til endesvitsjen som ser at nummeret som ringes er et IN nummer.

4. Endesvitsjen signalerer da til et ”Service Control Point” (SCP) som videre sender forespørselen til call centeret. Call centeret sier så ifra til endesvitsjen, gjennom SCP, at samtalen skal viderekobles mot IVRen. Dette er fordi det er IVRen som kan spille av talemeldinger og ta imot dtmf fra telenettet. Et viktig poeng er at det fortsatt er Call centeret som har kontroll på eller styrer samtalen.

5. Samtalen rutes gjennom telenettet til den kommer til siste svitsjen som IVRen er koblet til.

6. Destinasjon er funnet og samtalen kommer fram til IVRen. IVRen gjennomgår nå en rekke prosedyrer, som å opprette tilstandsinformasjon om samtalen, slik at en finner tilbake til riktig samtale. Kommer det flere samtaler er det viktig å ikke blande dem.

14


7. IVRen har nå funnet ut at samtalen skal styres fra call centeret, og spør følgelig om hva som skal gjøres med samtalen. Dette vil i praksis si at den spør om hvilke meldinger som skal spilles av for innringeren.

8. Call centeret svarer da på forespørselen og forteller hvilke meldinger som skal spilles av for innringeren.

9. IVRen spiller av meldinger til riktig innringer, hvorpå innringeren svarer med et menyvalg. Vedkommende svarer da med å taste inn på telefonen.

10. IVRen sender igjen en melding til Call centeret om at den ene samtalen har tastet akkurat det menyvalget

Punkt 8, 9 og 10 gjentas nå så mange ganger som Call centeret bestemmer. Til slutt kobles samtalen til IVRen ned og viderekobles til en eventuell kundebehandler. Samtalen vil da være oppsatt mellom innringer og kundebehandler. Dette gjøres da av call centeret. Kundebehandleren vil da typisk ha en kundedatabase hvor en kan lete opp for eksempel adresse til innringeren ved en eventuell utkjøring av varer.

Figur 6. IVRens innpass i nettet.

15


3.2. IVR tjenesten. Nå som vi har sett på IVR’ens funksjon i nettet, la oss gå nærmere inn på hvordan slik funksjonalitet kan implementeres. Som vi har sett av figur 7, må IVRen tilby to inngående grensesnitt og to utgående. Det vil henholdsvis være en inn og ut til ISDN nettet samt en web service og en web klient som kaller en webservice hos call centeret. En av forutsetningene til oppgaven var å lage en tjeneste som skulle være uavhengig av tjenesten som benyttet seg av IVRen. Kommunikasjon med call centeret var det viktigste, men kunne man finne en løsning som er mer generell ville det være det beste. Call centeret benytter seg av Parlay for kommunikasjon med telenettet og hadde derfor også muligheten til å benytte seg av Parlay X. Parlay X består av, som nevnt tidligere, et utvalg Parlay funksjonalitet, men med web service støtte. Web services er dagens absolutt beste å enkleste måte å kommunisere mellom programmer over internett på. Det er plattformuavhengig og det er kun måten man bygger dem på som er forskjellig. Metodene og attributtene sendes på samme format, uansett hvordan de er bygd, og det er det som gjør det til et unikt verktøy. Det er heller ingen begrensing i programmeringsspråk, når en skal lage web services. Videre må vi ha ett grensesnitt mot PSTN nettet. I teknologi kapittelet er det skrevet om Global Call, og at det følger med Dialogic kortet. Global Call gir oss et grensesnitt mot PSTN nettet som er mer enn godt nok for den funksjonaliteten vi ønsker. Global Call er også særdeles godt dokumentert, men det er enormt og det tar lang tid å sette seg inn i det. Vi skal nå gå IVR tjenesten nærmere i sømmene og se hva som ligger bak ”den gule boksen” i figur 7. Det er klart at vi må ha med web services og global call API’et, utfordringen blir hvordan vi skal sette dette sammen. Implementasjonsmessig ville det være lettest å programmere alt i samme prosjekt. Av programmeringsmessige årsaker gikk dessverre ikke dette, så funksjonaliteten måtte deles inn i mindre programmer. Grunnen til at dette ikke gikk er omhyggelig beskrevet i kapittel 4.2 ”Implementering av IVR tjenesten”. Årsaken til oppdelingen har noe med web servicen å gjøre, så den måtte skilles ut fra hovedprogrammet, eller IVR kontrolleren. Jeg måtte likevel ha kommunikasjon mellom web servicen min og IVR kontrolleren og dette løste jeg med å bruke TCP / IP sockets mellom programmene. Dette kunne blitt et problem hvis programmene hadde vært på forskjellig maskiner, med tanke på forsinkelse, men de er på samme maskin så det er ikke noe problem.

16


Figur 7. IVR tjenesten Figur 8 viser oss hvordan arkitekturen av programmet vil være, når det er ferdig. Web klienter og web services er tegnet blå, socket kommunikasjonen er tegnet rød og IVR kontrolleren gul. Legg merke til hvilken vei pilene går. Vi ser at kommunikasjon inn til programmet vårt kommer gjennom web servicesen vår og kommunikasjon ut går enten gjennom Global call APIet eller web klienten. Meldingen som utveksles på figuren vil være definert av hva slags melding som skal sendes. De forskjellige meldingene som er definert mellom call centeret og inn til IVRen er: register, play og disconnect. Ut fra IVRen til call centeret er connect og return_number. Detaljerte beskrivelser av meldingene samt meldingssekvensdiagrammer finnes i kapittel 4.3 ”Grensesnitt mot callcenter”.

17


4. Implementering Implementasjonen av prosjektarbeidet er den jeg har brukt mest tid på. Den har vært utrolig tidkrevende samtidig den har vært teknisk krevende. Spesielt er det global call som har vært utfordrende, samtidig som at det er totalt ukjent og det har tatt lang tid å sette seg inn i dette store og omfattende APIet.

4.1. Valg av utviklingsverktøy Utgangspunktet for oppgaven er Global call biblioteket. Dette er skrevet i C++. Derfor var det viktig med et verktøy som håndterer C++. Oppgaven innebefatter flere teknologier blant annet webservices; derfor var det fint om verktøyet om verktøyet kunne lage. De fleste verktøy lager et standard program for deg i det du begynner, for eksempel ønsker man å lage en konsoll applikasjon lager veiviseren dette for deg, slik at du kun trenger å legge til funksjonalitet siden. At verktøyet også var integrert med en webserver og lett kunne utplassere webservicen på denne, var også viktig. Det viktigste kriteriet var likevel muligheten til å kompilere både managed og unmanaged C++ kode i samme prosjekt, og dette var det kun .NET rammeverket som gjorde. Derfor falt valget på Microsoft Visual Studio .NET. I etterkant er jeg meget fornøyd med valget. Visual Studio .NET har særdeles gode ”hjelp - funksjoner”, samt at det er tett integrert med Internet Information Server, som er Microsoft sin webserver, fine ”veivisere” er også der.

4.2. IVR tjenesten IVR tjenesten er implementert i tre forskjellige faser. Disse representerer de tre hoveddelene av selve tjenesten, som er: IVR kontrolleren, webservicen og TCP / IP sockets. Hvordan disse forskjellige delene henger sammen sees på figur 7. Ideelt sett burde alt vært programmert sammen, dette vil ha gjort at jeg hadde sluppet og brukt socket programmering mellom IVR kontrolleren og webservicen. Jeg kunne da ha implementert webservicen i kontrolleren og spart meg for mye tid. Begrunnelsen for hvorfor dette ikke ble gjort blir forklart nedenfor. Vær oppmerksom at kode som er vist i det følgende kapittel kan være noe forkortet i forhold til hva som er realiteten i oppgaven, dette er på grunn av plass hensyn og at det ikke er noe vits i å vise samme kode flere ganger. Global call API er skrevet i C++, og følgelig måtte også IVR kontrolleren skrives i C++. API’et distribueres til brukere gjennom header filer (*.h) og biblioteker (*.lib ). Header filene definerer klasser og funksjoner og enkelte variabler, mens bibliotekene inneholder kompilert kildekode. På denne måte kan ingen endre kildekoden og API’et forblir dermed uendret, eller ubrukelig hvis man endrer header filene som kun er tekstfiler.

18


Når man snakker om C++, snakker man egentlig om unmanaged C++. Unmanaged C++ betyr at garbage collection ikke er i bruk.. Garbage collection er at programmet ”rydder opp” etter seg. Med dette menes at hvis man bruker garbage collection, vil programmet automatisk frigjøre minne når en klasse er ferdig og slettes, eller for eksempel en tabell som slettes. Dette er som sagt det som brukes hvis ikke annet er angitt. Alle nye programmeringsspråk i dag benytter seg av garbage collection og er derfor managed. Man kan gjøre C++ managed ved å benytte seg av direktivet __gc, hvilket da forteller kompilatoren at her kommer det en managed funksjon eller datatype. Å blande managed og unmanaged C++ er også mulig men man må da fortelle kompilatoren hele tiden om man benytter seg av managed eller unmanaged kode. Dette gjøres med direktivene: #pragma managed og en __gc datatype / funksjon eller #pragma unmanaged og en __nogc datatype / funksjon. For å illustrere forskjellen gir jeg et raskt eksempel. Ikke garbage collection: #pragma unmanaged

int MyIntArray [100]; // eller int MyIntArray __nogc [100];

garbage collection: #pragma managed int MyIntArray __gc[]= new int __gc[100];

Vi ser at måten å deklarere varier utifra om vi bruker managed eller unmanaged C++. Hvis man ønsker å blande managed og unmanaged kode må man også benytte seg av /clr parameteren for kompilatoren, som forteller den at den skal bruke Common Language Runtime. Det viste seg at ved bruk av webservice i C++ må de avanserte datatypene i metodene være managed. I utgangspunktet er ikke dette noe problem, siden man med .NET rammeverket kan skrive både managed og unmanaged i samme program som vist ovenfor. Imidlertid var jo kildekoden for Global call API’et var allerede ferdig kompilert unmanaged C++ kode og jeg hadde derfor ikke mulighet for å gå inn i kildekoden å sette ”#pragma unmanaged” direktivet. Resultatet ble derfor at jeg måtte dele opp programmet i to, en del som håndterte kontroll av IVR’en og en som håndterte web servicen. Allikevel må jeg ha kommunikasjon mellom disse to programmene, for at kontrolleren skal få melding om hvilke lydfiler som skal avspilles, og dette løste jeg ved å implementere TCP / IP sockets. Innledningsvis i del kapittelet skrev jeg at jeg ideelt sett burde programmert alt sammen, i og dette er altså grunnen til at dette ikke ble gjort. Videre i kapittelet følger en beskrivelse for hvordan jeg har brukt de forskjellige teknologiene for å løse oppgaven.

19


4.2.1. Min webservice En tjeneste som man ønsker skal være lett tilgjenglig, må benytte seg av en teknologi som støttes på tvers av andre teknologier. Web services er dette og det er da også det eneste som egentlig trengs for å kunne benytte seg av denne tjenesten. Det er det som gjør den så anvendbar i mange forskjellige genre. Web servicen har som skrevet tidligere til hensikt å fungere som en mottaker av kommandoer fra call centeret. Den skulle også være et frittstående program og ikke integrert i IVR kontrolleren. Når den tar imot meldinger sender den de videre med TCP / IP socket klienten. Jeg vil nå gå igjennom litt av kildekoden i fra web servicen som jeg mener er relevant. Koden som vises vil være kode som blir eksekvert etter hverandre. Det begynner med en kommando som kommer inn på web servicen, deretter blir sendt med TCP / IP mottatt av IVR kontrolleren og deretter spilt av til riktig samtale tilkoblet IVR’en.

Dette er web servicen som tar imot kommando om å spille av lydfiler på IVRen. Programmerings språket er C# (uttales C sharp). Vi ser at det er en metode tilgjenglig på internett allerede fra første linje hvor det står [WebMethod]. Man kan ha mange metoder i en web service prosjekt men kun de av de som det står [WebMethod] foran vil være tilgjenglig for allmennheten. Det eneste som er spesielt med en web service er nettopp dette, som dere ser er resten av koden helt normal. Vi ser funksjonsdeklarasjonen public Boolean Play (), og den forteller oss at det er en offentlig funksjon altså aksesserbar for andre deler av programmet, Boolean forteller at funksjonen returnerer true eller false tilbake til den som kalte funksjonen. Play er funksjonsnavnet. Hele ideen med resten av koden er å gjøre om alle parametrene til om til en tekst streng slik at den kan sendes som ett argument til funksjonen som skal sende den til IVR kontrolleren. For å få dette til må først bestemme oss for på hvilken måte skal vi sette sammen strengen på, slik at vi kan finne fram til de opprinnelige variablene, når tekst strengen er kommet fram til IVR kontrolleren. Jeg måtte finne en løsning på å skille de ulike variablene. Ikke alle variablene er likt oppbygd, sånn som msg_id (message id), som inneholder en tabell men hvilke lydfiler som skal spilles av. Indeks 0 i denne tabellen brukes som velkomstmelding og det skal ikke leses opp ”Tast 1” foran den. Dette begynner programmet med fra og med indeks 1. Derfor måtte jeg finne en måte jeg kunne gjøre dette på som skulle være entydig og umulig å tolke, uansett datatype. Løsningen på dette problemet var å sette ett semikolon etter hvert variabelnavn og likhetstegn etter hver variabelverdi. For å markere slutten på en streng settes # tegnet. Variabelnavnet må være der for at jeg skal kunne vite i hvilken variabel jeg skal sette

20


verdien i når strengen kommer på andre siden. Jeg måtte også skille mellom variabler og verdier, derfor måtte jeg ha to separatorer, jeg valgte semikolon og likhetsegn. Grunnen til at disse separatorene kommer etter verdien eller variabelen er at da kan jeg huske på hvor jeg leste til sist og lese det som er imellom der jeg var og der jeg er. Jeg vil vise dette med et eksempel til slutt om i del kapittelet TCP / IP sockets. For – løkkene i funksjonen har til hensikt å hente ut alle variablene i tabellen med ider å legge dem etter hverandre i tekststrengen som oversendes DoSocketGet. Vi ser at i siste setning, bygges og oversendes strengen til socket klassen som skal sende tekststrengen, som også bygges ferdig i denne linjen. String.Concat slår sammen tekststrenger til en streng, og DoSocketGet ligger i Send klassen. Action forteller socket serveren hvilken web service som ble kalt, slik at det blir enkelt for kontrolleren å finne ut hva som skal gjøres. La oss tenke oss at vi har disse variablene: msg_id [ 0 ] = 101 msg_id [ 1 ] = 204 msg_id [ 3 ] = 306 ref_no = ” 35224678”

num_of_digits = 1 Dette vil se slik ut når det oversendes Send klassen: ”action;play=msg_id;101=204=306=0=0=0=0=0=0=0=ref_no;35224678=num_of_digits;1=#" Vi ser at det alltid blir sendt en tabell med indeks 0-9, dette har ingen praktisk betydning men er kun gjort for å forenkle mottaket av strengen. Dette var altså selve web servicen, nå skal vi se litt nærmere på socket klassen som sender tekststrengen til socket serveren.

Tekst strengen som funksjonen DoSocketGet heter nå conn_string. Meldinger som sendes over TCP / IP sockets sendes i dette programmet som en Byte tabell, vi ser at jeg

21


bruker en funksjon som henter ut bytesene fra conn_string og legger dem i msg. Deretter defineres variabelen som skal returneres til webservicen. Denne forteller om sende operasjonen var vellykket eller ikke. Videre blir det opprettet en socket. AdressFamily betyr at det er IPv4 som benyttes, deretter kommer socket type og i dette tilfelle benytter jeg Stream som er en pålitelig, forbindelses orientert type, den benytter seg av Internetwork familien og TCP. Videre definerer jeg hvilken port kommunikasjonen skal gå på. Det er det samme hvilken du bruker så lenge du holder deg unna de faste portene. Er du i tvil kan du bruke port lister som en finner på internett. Disse har oversikt over hvilke applikasjoner som bruker hvilke porter. Connect etablerer TCP forbindelsen til serveren, som ligger på samme maskin, på port 81. Lykkes dette sendes msg, som inneholder strengen, over til serveren. Samtidig som success = true returneres til web servicen som igjen sender true tilbake til call centeret.

4.2.2. TCP / IP socket server Socket serveren er skrevet i C++. Jeg har ikke benyttet meg av .NET’s C++ rammeverk, da ville jeg fått samme problem som jeg beskrev innledningsvis om implementasjon av IVR tjenesten. Implementasjonmessig tilhører den IVR kontrolleren, men den representerer spesifikk funksjonalitet og derfor skriver jeg om den for seg. Oppgaven til socket serveren er å ta imot byte tabellen som sendes fra socket klienten omtalt i web service kapittelet. Når det er gjort, må byte tabellen gjøres om til en char tabell slik at den kan behandles og tolkes på en slik måte at datastrukturene blir de samme igjen. Det vil si sånn de var da de ble mottatt av web servicen. For å gjøre forklaringen enklere og å enklere henvise til koden har jeg lagt inn piler, som peker til det omtalte området i koden. 1. Før vi kan begynne mottaket av byte tabellen må vi klargjøre en socket som lytter

etter tilkoblinger fra socket klienten i web servicen. Med metoden som jeg har benyttet for å lage en socket server må jeg først starte opp Windows Sockets prosessen. De 5 kodelinjene i punkt 1 starter prosessen slik bruk av ws2_32.dll blir mulig. Uten denne ville jeg for eksempel ikke kunnet lage en socket som jeg gjør i punkt 3.

2. Når det er gjort må jeg definere adressefamilie, hvilke adresser som skal få lov til å koble seg på, og til hvilken port dette gjøres. Dette er veldig likt som med måten man lager en socket som sender, altså forklart i forrige kapittel, så jeg sier ikke mer om dette. Det eneste som er forskjellig er syntaksen, funksjonaliteten blir akkurat den samme.

3. Videre må socketen lages og defineres for hva slags typer data den skal ta imot, dette er også likt som for klienten.. Deretter må adresseinformasjonen knyttes til socketen, som gjøres i bind kallet.

4. Socketen settes nå i en tilstand hvor den lytter etter innkommende tilkoblinger. 5 indikerer at det kan være 5 tilkoblinger som kan være i kø, man kan nemlig kun

22


behandle en og en tilkobling og i stedet for å kaste nye forespørsler, setter man de i kø.

5. Programmet har nå gått inn i en evig løkke, indikert av while(1), et argument som alltid vil være sant. Det er i denne fasen at vi mottar og prosesserer forespørselen. Accept godkjenner et tilkoblings forsøk og returner en ny socket datatype som lagres i Inn variabelen. Datastrømmen vil nå være tilgjenglig gjennom Inn.

6. Selve innlesningen av byte tabellen gjøres i dette punktet. Det leses en og en byte, samtidig som det sjekkes om terminerings tegnet ’#’ er lest inn, da vil i så fall innlesningen opphøre og vi går videre til, behandlingen av strengen. Resultatet blir lest inn i input.

7. Når innlesningen er unnagjort kan strengbehandlingen starte. Hvordan dette foregår vises nedenfor. Etter dette blir resultatet lagret i incomming tabellen, og IVR kontrolleren får melding om at en melding fra web servicen er kommet inn og lagret på den gitte plassen i tabellen. Incomming er en tabell som peker til forskjellige instanser av klassen Variables. Variables lagrer resultatet av strengbehandlingen, som vi skal se straks. Legg også merke til at incomming kan inneholde 30 klasser, altså like mange som vi har ISDN linjer. Vedlikeholdet av denne tabellen foregår utenfor den koden og kommenteres derfor heller ikke.

23


Strengbehandlingen foregår i ParseString(). Den er nødvendig for å skille ut dataene i tekststrengen som oversendes socket serveren. Oppgaven til ParseString er derfor og skille ut hvilke variabler som skal ha de ulike verdiene som oversendes. Koden nedenfor viser nettopp, og jeg skal gå igjennom den på samme måte som jeg gikk igjennom koden ovenfor. Vi ser at ParseString er deklarert på en sånn måte at, den returnerer en peker til en klasse, som lagres i incomming tabellen nevnt tidligere. Den tar en char* som argument og det er strengen som skal behandles. Det neste som skjer at variabler som brukes i funksjonen blir initiert. 1. En temporær klasse peker blir opprettet, slik at vi kan jobbe på denne klassen og

senere returnere den ved funksjonens slutt. Når dette er gjort startes en løkke som skal gå igjennom hver del av strengen og tolke denne. Vi kan aksessere et tegn i strengen

24


på følgene måte: streng[ teller ] og det er akkurat det som gjøres i switch utsagnet. For hvert tegn som leses sjekkes det om tegnet er ’ ; ’, ’ = ’eller ’ # ’. Hvis tegnet ikke er noen av delene sjekkes neste tegn i strengen.

2. Er tegnet ’ # ’ er strengbehandlingen ferdig. Vi husker fra tidligere at ’ # ’ terminerer strengen. Finished blir satt til true slik at strengbehandlingen avbrytes, og pekeren til klassen blir returnert og lagret på riktig plass i incomming tabellen.

3. Er tegnet ’ ; ’, er det lest inn en ny variabel. Det som er lest inn er variabel navnet og vi ser at det lagres i variabelen variabel. Er det for eksempel den første variabelen som er lest inn, som er ”action” vil offset være 0 og counter være 6.

Programmet leser da inn i variabel, det som står mellom offset og counter -1. Etterpå settes offset til counter + 1, slik at en vet hvor neste verdi / variabel begynner, ved neste innlesning.

4. Er tegnet ’ = ’, er det en verdi som er lest inn. Verdien blir lest inn i value på samme måte som i punkt 3. Deretter sjekkes hvilken variabel som skal få tilordnet verdien. Er verdien et tall som den er i to av tilfellene må man i tillegg til å tilordne verdien riktig variabel, gjøre den om til et tall. Er det en meldings id som er kommet inn må man inkrementere tabell indeksen slik at eventuelt neste tabell verdi blir tilordnet på neste indeks i tabellen.

5. Etter at programmet er ferdig med å behandle den spesifikke plassen i strengen inkrementeres counter slik at neste tegn kan tolkes. Er strengen ferdig tolket returneres pekeren til det kallende program.

25


4.2.3. IVR kontroller IVR kontrolleren er selve hjernen i IVR tjenesten. Funksjonaliteten i de foregående kapitlene har kun til hensikt å bringe informasjon fram til kontrolleren. Som for eksempel en meldings id som skal spilles. Jeg vil ikke i samme grad kommentere koden i dette kapittelet. Derfor vil jeg anbefale at leseren titter på denne på den vedlagte CD, slik at man får et visst inntrykk av det arbeid som er gjort i forbindelse med kontrolleren. IVR kontrolleren er vesentlig mer komplisert og lengre, men jeg vil trekke ut essensielle momenter. Oppgaven til kontrolleren er og først initialisere Global call biblioteket deretter Dialogic kortet. gc_Start(NULL) starter biblioteket og gc_Stop() stopper det. Initialisering av kortet foregår på den måten at en først finner ut hvor mange Dialogic kort man har installert. Deretter åpnes disse og registreres i Global call samt at man starter en Global call hendelses håndter for hvert kort. Hendelses håndtererens oppgave er å ta imot hendelser til kortet slik at en handling kan utføres. Videre skal alle linjene på hvert enkelt kort åpnes (30 ISDN linjer)og klargjøres for innkommende anrop. Et problem som ofte oppstår under åpning av ISDN linjene er at de ikke er klare til å motta anrop enda. Løsningen på dette er å nullstille linjen etter at man har åpnet den. Videre må man lage en hendelses håndterer som kan si ifra til programmet når en

26


innkommende samtale detekteres for eksempel. Til slutt kalles waitcall som setter linjen i stand til å motta en samtale. Koden nedenfor viser et utdrag fra denne klargjøringen. For løkken som står øverst vil kjøre 30 ganger siden det er 30 linjer som skal åpnes. Denne koden er portabel så den kan brukes på andre Dialogic kort, som for eksempel har flere eller færre linjer, eller i konfigurasjoner hvor man stacker kortene. Da vil eventuelt denne løkken ble startet like mange ganger som man har kort installert.

Resten av koden som omhandler den enkelte ISDN linje finnes i [8] under \ivr_controller\GlobalCall.cpp. Når alle linjer på alle kort er åpnet, må man initialisere talekanalen på hver ISDN linje. Denne koden ligner mye på koden for å åpne linjene, så den viser jeg ikke. Forskjellen er at det ikke er noen måte å nullstille denne kanalen, og man trenger heller ikke å klargjøre kanalen med en waitcall lignende funksjon. Hendelseshåndtereren til talekanalene vil ta seg av hendelser som har med tale på kanalen å gjøre. Dette kan typisk være at IVR kontrolleren holder på med et opptak eller avspilling av lyd. Forskjellen på hendelseshåndtereren til en linje enhet og til en tale enhet er viktig å forstå og oppgaven hadde vært umulig å gjennomføre uten disse. Hendelseshåndtereren til en linje enhet, håndterer altså alt som har med et anrop å gjøre mens tale håndtereren håndterer alt som har med lyd å gjøre på en enkelt kanal. For å øke forståelsen av

27


hendelsene listes de opp nedenfor, de er selvforklarende så noen forklaring utover det som er gjort trengs ikke.

Tabell 1 Global Call hendelser, med forklaring

HENDELSE FORKLARING GCEV_BLOCKED Linjen er sperret GCEV_UNBLOCKED Linjen er åpen, klar til bruk GCEV_CONNECTED Utgående samtale er besvart GCEV_ANSWERED Inngående samtale er besvart GCEV_ACCEPT Godkjenner en innkommende samtale GCEV_OFFERED Samtalen blir tilbudt applikasjonen GCEV_DICONNECTED Forbindelsen er brutt GCEV_DROPCALL Samtalen blir lagt på GCEV_TASKFAIL Hvis en oppringning har gått feil

HENDELSE FORKLARING CS_IDLE Kanalen gjør ingenting CS_PLAY Kanalen spiller lyd CS_RECD Kanalen gjør et lydopptak CS_DIAL Kanalen slår et nummer CS_GTDIG Kanalen mottar siffer CS_TONE Kanalen lager en tone CS_CALL Kanalen ringer opp CS_BLOCKED Kanalen er blokkert CS_RECVFAX Kanalen mottar en faks CS_SENDFAX Kanalen sender en faks CS_STOPD Operasjonen er avsluttet

Tabell 2 Tale ressurs hendelser, med forklaring Nå som kortet er klart til å motta samtaler og å spille av lydmeldinger, kan call centeret koble samtaler til IVRen og å gi melding om hva skal gjøres med den enkelte samtale. Neste eksempel vil anta at en samtale er kommet inn og at IVR kontrolleren har fått melding om hva som skal avspilles for brukeren. Koden som følger er hentet fra notify funksjonen som blir kalt etter at variablene er lest. Programmet har alt funnet ut at det er en avspilling som skal utføres.

28


getMsgId returnerer adressen til tabellen som inneholder alle id’ene som skal spilles av. Det første vi sjekker er om det som skal spilles av er en velkomstmelding eller pausemusikk. Meldinger av denne art legges alltid på plass 0 i tabellen, det vil heller ikke bli assosiert noen dtmf tone med disse meldings id’ene. Videre blir det spilt av like mange meldinger som tabellen er lang med tilhørende ”Tast 1 for ”, ” Tast 2 for ” meldinger. Legg merke til at ’i’ i for-løkken begynner på 1 så vi ikke spiller av en eventuell velkomstmelding to ganger. Lookup funksjonen finner riktig talekanal og spille av på. Siden kortet har 30 ISDN linjer og 30 talekanaler, har jeg mappet disse en til en. Det vil si at hvis jeg ønsker å spille av en melding på en gitt kanal er det kun en kanal som kan gjøre dette. For at brukeren av systemet skal kunne taste inn ett meny valg, må funksjonen dxGetDigits kalles. dxGetDigits må vite hvor mange siffer den skal vente på, og dette antallet ligger i getNumberOfDigits. Når brukeren tastet inn sitt svar vil funksjonen returnere og dxStop kalles. Den ”renser” opp og avslutter all tale trafikk på tale enheten slik at for eksempel dxPlay kan kalles på nytt. Når denne prosedyren er gjennomført blir web servicen til, i dette tilfelle, call centeret kalt og programmet sender med hvilken samtale kallet gjelder og hva resultatet av inntastningen var. Call centeret kan da ta en beslutning om hva som skal skje med samtalen videre. Enten er sesjonen over eller så sendes ny play melding.

4.3. Grensesnitt mot callcenter

4.3.1. Oversikt over protokollen Meldingene består av webservice kall. Hver melding er et kall til en webservice på tjeneren. Tjener vil i denne sammenheng si den maskin som skal utføre noe for en annen, denne rollen skifter altså maskinene på å ha. Innholdet av meldingen vil være argumenter til webservicen.

4.3.2. Svarmeldinger Alle meldinger har en tilhørende kvitteringsmelding. Denne er implementert ved at enhver forespørsel til tjeneren har en return klausul som sier noe om hvordan

29


eksekveringen gikk, for eksempel ”ok”. Ved feil under eksekvering og det returneres feil, legger IVR’en på samtalen.

4.3.3. Feilhåndtering Alle meldinger må komme i par hvis de skal tolkes og forståes korrekt av IVR’en. Meldinger mottatt fra en webservice forteller hva som skal gjøres med en samtale mottatt fra telenettet, så en samtale mottatt fra telenettet uten et webservice kall har ingen mening. Hver gang en melding blir sendt fra callcentret startes en timer i callcentret. Det være seg webservice kall eller melding til telefonnettet. Timeren har funksjonen å avbryte oppkoblingsforsøket mot IVRen hvis ikke en suksessfull return fra connect fra webservice mottas eller oppkoblingsforsøket timer ut for et gitt referansenummer. Timeren vil også fungere globalt for hele samtalen. Det vil si at en kan ikke behandle en kunde i mer enn den tiden timeren tillater. Hvis denne timeren slår inn hvil callcenteret sende disconnet melding. En tilsvarende timer er også implementert på IVR siden. Under mottak av siffer, vil det også startes en timer. Hensikten med denne er og spille av valgalternativene en gang til etter 30 sekunder hvis brukeren ikke har tastet et siffer. Dette gjøres tre ganger og hvis det fortsatt ikke er mottatt noen siffer, kobles samtalen ned fra callcenteret. Feilårsaker kan være:

• IVRen har ikke fler ledig telefonlinjer, maks er 30 samtidige samtaler • E-1 linjen til IVR er nede • IP nettet til IVRen er nede • IVR tjenesten har krasjet • Tilsvarende feil vil også kunne oppstå på callcenter siden

4.3.4. Meldingsformat Meldingene sendes i klartekst og vil være kall på bestemte funksjoner hos tjeneren, med tilhørende argumenter. Meldinger fra Callcenter: Register, Play og Disconnect Meldinger fra IVR:Connect og return_number.

30


4.3.5. Meldingssekvensdiagrammer

Selve registreringen av call centeret på IVRen er det første som skjer. Vi ser at register er den første meldingen som sendes til IVRens web service. Lykkes ikke web servicen i å sende dette kallet videre til IVR kontrolleren ser vi at registreringen avbrytes. Lykkes den derimot, blir informasjonen som er sendt over lagret og Call centeret får true tilbake som en indikasjon på at operasjonen var vellykket. Grensesnittet mellom IVR webservice og IVR kontroller er som tidligere nevnt TCP / IP sockets.

31


Avspilling av en melding initieres egentlig av IVRen. Det er den som får melding av global call om at en samtale er mottatt. Hva de forskjellige hendelsene som sendes til IVR kontrolleren betyr er forklart i tabell 2. Til venstre for GlobalCall er det nettverket som er. Deretter sender melding om dette til call centeret (connect). Sekvensen av meldinger som følger nå er en sekvens som gjentas helt til call centeret har fått spilt av så mange meldinger den vil, det vil si til det sender disconnect. Legg merke til at play ikke kommer fra noen steder, det har bakgrunn i at jeg ikke hadde plass til CC Web client som den sendes ifra, men som altså skulle stått der.

32


Til slutt, når call centeret har latt innringeren navigere seg gjennom de menyer som skal til for at en beslutning om hvilken kundebehandler samtalen skal settes over til, sendes disconnect til IVRen. Dette er egentlig mest en formalitet, fordi IVRen selv ville ha merket hvis samtalen bare ble koblet ned av call centeret med GCEV_DICONNECTED hendelsen. Uansett gjøres det og IVR kontrolleren må, når samtalen kobles ned, rydde opp i noen tabeller og klargjøre linjen for innkommende anrop igjen. Her behøves heller ingen returverdi, fordi IVRen er selvdetekterende på grunn av hendelseshåndterene.

33


4.3.6. Meldinger register Sender: Callcenter Mottaker: IVR Parametre: navn datatype

service_id string* url string* Returverdi: success boolean Beskrivelse: Register meldingen har til hensikt å fortelle IVR’en at noen ønsker å

kommunisere med den. Hvem det er som ønsker dette er angitt i service_id. For at kommunikasjonen skal gå begge veier er det nødvendig at IVRen vet hvor den skal returnere for eksempel inntastinger fra brukeren. Dette er angitt i URL variabelen. Tjenestene som ønsker å benytte IVRen kjører register med en gang tjenesten starter. Returverdien vil være true så lenge maks antall registrerte tjenester ikke er nådd.

Url parameteren er for at call centret kan endre IP, på denne måten slipper

IVRen ha oversikt over alle tjenestene, som bruker IVRen, sin IP adresse. IP adressen behøves for Play_ack meldingen. Formatet er på string* slik at denne kan være vilkårlig lang, for eksempel med tanke på Ipv6.

Service_id er et tekstfelt bestående av 20 tegn, og kan typisk være ”Callcenter”. Alle meldinger behøver ikke nødvendighvis ha samme opphav. IVR løsningen vil derfor i fremtiden ikke bare kommunisere med med Callcenter tjenesten, men også tilby tjenester til andre plattformer. Derfor er det nødvendig med en service id, slik at riktig grensesnitt benyttes ved kommunikasjon med den andre tjenesten/ platformen. Ikke alle plattformer vil kunne motta meldinger fra en webservice og derfor er dette nødvendig.

play Sender: Callcenter Mottaker: IVR Parametre: navn datatype msg_id integer[10] ref_no string* num_of_digits integer Returverdi: success boolean Beskrivelse: Play indikerer for IVR’en at noe skal spilles av for brukeren. Nøyaktig hva

som skal avspilles befinner seg i msg_id tabellen. Den har en begrensing på 10 meldinger. Meldingene vil være forhåndslagret på IVR’en og utvekslig av id’er vil være hardkodet. For hver meldings id som blir funnet

34


i tabellen, blir det før meldingen lest opp ”Tast x for” hvor x er rekkefølgen meldingen blir lest opp i. Det vil si at for meldingen som tilhører msg_id[1] vil x være ”en” osv. Dette gjelder for alle meldingsid’er bortsett fra den første meldings id’en lagret i msg_id[0]. Grunnen til dette er at man her kan legge velkommen meldinger som ikke skal være velgbare.

Antall siffer som skal mottas ligger lagret i num_of_digits. Dette er

nødvendig for at IVR’en skal vite hvor mange siffer den skal motta. Er det et meny valg vil denne være 1, men er det et kontonummer vil den være 11.

Hver melding får et referansenummer (ref_no) som er unikt for samtalen. Referansenummeret sendes med hver eneste melding slik at man lett identifiserer hvilken samtale meldingen tilhører. Nummeret består av åtte siffer og vil bli mappet mot Call Reference Number (CRN), som Global Call bibliotekene i IVR’en automatisk tilordner en samtale, i en tabell. Dette er fordi det er CRN som unikt identifiserer samtalen i IVR’en mens det er ref_no som gjør det i Callcenteret.

disconnect Sender: Callcenter Mottaker: IVR Parametre: navn datatype ref_no string* Returverdi: ingen Beskrivelse: Disconnect forteller IVRen at dens jobb er slutt, kunden har fått gjort de

valgene som skal til for at samtalen kan behandles videre av Callcenteret. Det som gjøres er at samtalen slettes fra koblingstabellen omtalt i connect meldingen og fra ressurstabellen. Callcenteret vil samtidig koble ned samtalen. Idet dette skjer klargjøres både linje og tale ressursen for nye samtaler.

connect Sender: IVR Mottaker: Callcenter Parametre: navn datatype ref_no string* Returverdi: ingen Beskrivelse: For å hindre at IVRen får for mange henvendelser og itillegg at det ikke

går an å reservere ressurser vil det bli forsøkt å koble til IVR fra PSTN

35


nettet først. IVRen har kun 30 linjer og det er derfor dette antallet som begrenser samtidig bruk av tjenesten.

IVRen vil derfor få et innkommende anrop og hvis den har ledig kapasitet

svare anropet og deretter sende connect til riktig tjeneste ved å se på a-nummeret. Ref_no som connect sender med er det samme som Call Reference Number (CRN), som er iden Global call tilordner en samtale. Deretter kan riktig tjeneste svare styre samtalen med play kallet slik at riktig meldinger blir spilt av.

Return_number Sender: IVR Mottaker: Callcenter Parametre: navn datatype ref_no string* recieved_digits string* Returverdi: ingen Beskrivelse: Play_ack forteller Callcenteret hvilke siffer som er tastet inn av brukeren.

Sifferene vil være lagret i recieved_digits og er av typen string siden antall siffer som skal returneres varierer. Sifferene vil være atskilt med komma tegn.

Ref_no er som for play meldingen.

36


5. Konklusjon Som nevnt tidligere ble web services valgt får å gjøre tjenesten mest mulig generell og plattformfri. Tjenesten er nå implementert og fungerer bra. Ikke bare er det mange som kan koble seg til IVRen på grunn av web service grensesnittet men det er også uhyre enkelt å lage test applikasjoner. Dette er utvilsomt en stor fordel når en skal utvikle nye tjenester, noe som også har bidratt til at tjenesten er så bra som den er. En ting som er viktig å tenke på er at call centeret er brukt i denne oppgaven er bare en av mange tjenester som IVRen kan brukes til. I denne oppgaven har vi også kun sett på eksempler hvor IVRen tar imot samtaler, men det er også muligheter for å ringe ut, sette opp konferanser, og å viderekoble samtaler. Vi skjønner at her er mulighetene mange, noen av dem kan kanskje være televoting, som vil ligne på det som kjøres under Grand Prix for eksempel. Andre muligheter vil kunne være at man kan ringe nummeret til IVRen og gi penger til Redd Barna. Spørreundersøkelser vil kunne defineres på IVRen slik at den automatisk ville ringt opp gitte telefonnummer, stilt spørsmål og tatt imot svar for så deretter presentert resultatet på en webside. Andre muligheter vil kunne være å ha samme logikk på en webside som på IVRen, benytte seg av VoiceXML og deretter lest opp tale til brukeren av websiden. Brukeren kunne da for eksempel ha svart på spørsmålene med et klikkbart GUI, eller lest svaret inn i maskinens mikrofon.

6. Referanseliste [1] Tore Riksaasen Telematikknett, 1995 [2] The Parlay group, www.parlay.org[3] The Intel Coorporation, http://www.intel.com/network/csp/products/6038web.htm[4] International Telecomunication Union, http://www.itu.int/home/[5] The Intel Coorporation,System Release 5.1.1 for Windows Feature Pack 1 Online

Bookshelf, http://resource.intel.com/telecom/support/releases/winnt/sr511fp1/onldoc/htmlfiles/index.html

37

http://www.parlay.org/

http://www.intel.com/network/csp/products/6038web.htm

http://www.itu.int/home/

http://resource.intel.com/telecom/support/releases/winnt/sr511fp1/onldoc/htmlfiles/index.html

http://resource.intel.com/telecom/support/releases/winnt/sr511fp1/onldoc/htmlfiles/index.html


7. Vedlegg

7.1. Bruk av CD-ROM

1. Kopier \ivr_controller\biblioteker fra cd’en til c:\biblioteker. 2. Alle kildekode ligger i *.cpp og *.h filer. Disse finnes under \ivr_controller\ og

\ivrWS 3. \ivr_controller\ inneholder kildekode for ivr kontrolleren og \ivrWS\ inneholder

kildekode for webservicen.

7.2. CD-ROM

38

PROSJEKTOPPGAVEpeople.item.ntnu.no/~lillk/stud-proj/soevik-IVR.pdf · FAKULTET FOR...

Documents

Transcript of PROSJEKTOPPGAVEpeople.item.ntnu.no/~lillk/stud-proj/soevik-IVR.pdf · FAKULTET FOR...