PROSJEKTOPPGAVE Interaktiv taleresponstjeneste ... - NTNU

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. 

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 

Tabell 1 Global Call hendelser, med forklaring 

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 


Mottaker: IVR 


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 


Mottaker: IVR 



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 




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å anummeret. 

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 



recieved_digits string* 


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/in 

dex.html 

37

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

PROSJEKTOPPGAVE Interaktiv taleresponstjeneste ... - NTNU

Create successful ePaper yourself

Delete template?

Save as template?