SISÄLLYSLUETTELO 1. VoIP laskutus... 2 1.1 Johdanto... 2 1.2 Vaatimukset ja laskutusmallit... 2 1.2.1 PSTN/GSM-verkot... 3 1.2.2 IP-verkot... 4 1.3 Kirjaamismenetelmät... 5 1.3.1 RADIUS (Remote Access Dial-In User Service)... 5 1.3.2 SNMP (Simple Network Management Protocol)... 6 1.3.3 Muita menetelmiä... 7 1.4 CDR-formaateista... 7 1.5 Välityspalvelimet... 8 1.6 Inter-Domain VoIP... 8 1.6.1 INOW!-aloite... 9 1.6.2 Open Settlement Protocol... 9 1.7 Lähdeluettelo... 13 1
Tuomas Keränen 1. VOIP LASKUTUS 1.1 Johdanto IP-verkkoihin perustuvat uuden sukupolven palvelut ja liiketoimintamallien moninaistuminen ovat viime aikoina alkaneet edellyttää entistä kehittyneempiä liikenteen seurantaratkaisuja. Monet Internetpalveluntarjoajat ovat siirtymässä ns. flat-rate laskutusmallista palvelupohjaiseen laskutukseen. Lisäksi liikennemäärien kasvaessa on tullut ajankohtaiseksi ryhtyä laskuttamaan palvelun laadusta; mitä enemmän asiakas on valmis maksamaan, sitä enemmän hän voi luottaa palvelun saatavuuteen ja luotettavuuteen. Tällä tavalla palvelun tarjoajat voivat siis jakaa kustannuksia älykkäämmin ja ennen kaikkea erottautua kilpailijoista markkinoilla. Yksi tämän hetken nousevista IP-pohjaisista palveluista on äänen siirtäminen pakettikytkentäisten verkkojen yli. Sadan vuoden kokemukset äänen siirtämisestä piirikytkentäisten verkkojen yli aiheuttavat kuitenkin VoIP-palveluille reunaehtoja, jotka ovat IP-verkkojen ominaisuuksien vuoksi kohtuullisen vaikea täyttää. Palvelun laatu on näistä eniten tutkittu, ja sen parantamiseen on uhrattu paljon työtä eri standardointiyhteisöjen puolesta. Jotta VoIP-palveluita olisi mahdollista hyödyntää kaupallisesti, on niistä kuitenkin oltava mahdollista laskuttaa luotettavasti ja kuluttajaystävällisesti. Kuluttajat ovat tottuneet luotattavaan laskutusjärjestelmään PSTN- ja GSM verkkoja käyttäessään, eivätkä he ole valmiita luopumaan tästä ominaisuudesta VoIP-palveluiden kohdalla, vaikka teknologia sinänsä olisi kuinka edistyksellinen ja halpa tahansa. Jostain syystä laskutusmekanismeja ei kuitenkaan ole pyritty standardisoimaan kuin vasta viime aikoina. Tähän asti järjestelmät ovat usein olleet suljettuja yhden valmistajan ratkaisuja, jolloin varsinaisesta yhteensopivuudesta ei ole voinut puhua. Liikenteen kirjaamiseen on kuitenkin jo olemassa standardoituja ratkaisuja ja protokollia, joita pystytään käyttämään hyväksi laskutustietojen keräämisessä ja välittämisessä varsinaisille laskutusjärjestelmille. 1.2 Vaatimukset ja laskutusmallit Koska VoIP-puheluissa usein käytetään sekä PSTN- että IP-verkkoja äänen siirtämiseen, olisi suotavaa, että laskutusmenetelmät kummassakin verkossa vastaavat ominaisuuksiltaan toisiaan mahdollisimman paljon. Toimiakseen perustana luotettavalle laskutukselle, tulee verkon pystyä generoimaan tietoa sen käytöstä. Tämän tiedon tulee täyttä ainakin seuraavat sille asetetut vaatimukset [6]: 1. Erinomainen tarkkuus. Jotta asiakastyytyväisyys pystytään takaamaan, on käyttötiedon oltava ehdottoman luotettavaa. 2
2. Tarpeellisten käyttöparametrien saatavuus. Laskutusjärjestelmän on saatava juuri oikeat parametrit puhelun kulusta pystyäkseen muodostamaan asianmukaista laskutustietoa. 3. Skaalautuvuus. Tiedon määrän tulee olla vapaasti vaihdeltavissa. 4. Turvallisuus. Kenenkään ei pidä päästä muuttamaan kerättyä käyttötietoa. 5. Pysyvyys. Kerätty tieto ei saa hävitä missään käsittelyn vaiheessa. Seuraavassa kappaleessa on esitelty lyhyesti laskutusmalleja ja menetelmiä sekä piirikytkentäisen että pakettivälitteisien verkkojen osalta. 1.2.1 PSTN/GSM-verkot Perinteisessä piirikytkentäisessä verkossa eri verkkoelementit, kuten vaihteet keräävät jatkuvasti tietoa niiden lävitse virtaavasta datasta. Jotta saavutettaisiin mahdollisimman tehokas toiminta ja luotettavuus raskaankin liikennemäärän vallitessa, käytetään verkossa erillistä prosessointia keräämään dataa eri elementeistä. Lisäksi prosessointijärjestelmä vertailee (korreloi) eri elementtien keräämää dataa ja muodostaa tiedosta ns. Caller Data Record-tietoa välitettäväksi eteenpäin järjestelmän ylemmille hierarkiatasoille. Jotta eri valmistajien tuottamien järjestelmien välille saavutettaisiin mahdollisimman hyvä yhteensopivuus, on CDR:n muotoa pyritty standardoimaan. Formaatteja on tarkemmin esitelty kappaleessa 1.4. Muodostamisen jälkeen tieto siirretään CDR-muotoisena operaattorin keskitettyyn laskentakeskukseen, missä niiden pohjalta lasketaan tilastointija hinnoittelu-informaatiota sekä muodostetaan varsinainen laskutustieto. Yksinkertaistettu vuokaavio prosessista on esitetty kuvassa 1 [11]. Verkkoelementit Tiedon keräys, muotoilu, vertailu Väliprosessointi C D R Laskun muodostus, kirjanpito Käyttötiedon Muodostaminen Laskutusjärjestelmä 1. Laskutusmalli PSTN-verkossa Käyttämällä hyväsi IN (Intelligent Networks)-tyyppisiä verkkoratkaisuja asiakasta voidaan tämän lisäksi laskuttaa joustavasti erityyppisistä lisäarvopalveluista sekä mahdollistetaan mm. etukäteen maksettujen (prepaid) palveluiden käyttö. 3
Tuomas Keränen 1.2.2 IP-verkot Koska palveluiden kirjo IP-verkoissa on huomattavasti monipuolisempi kuin PSTN-verkoissa, on myös sen laskutusjärjestelmille asetettava hieman erilaisia vaatimuksia. Pelkän minuuttitaksan sijasta saatetaan olla kiinnostuneita palvelun laadusta, siirretyn datan määrästä ja palvelun luonteesta. Lisäksi, kuten myös PSTN-palveluissa, siirretty matka toimii yhtenä avaimena laskutuksen järjestämisessä. VoIP-palveluissa laskutusparametrit ovat kuitenkin hyvin pitkälle samat kuin perinteissä puhelinverkoissa. Periaatteellisella tasolla IP-verkkojen laskutusmalli on siis samantapainen kuin PSTN-verkoissa. Eri verkkoelementit, kuten reitittimet, yhdyskäytävät ja portinvartijat tuottavat tietoa puhelun kulusta, jonka jälkeen tieto kerätään ja muokataan sopivaan muotoon laskutusjärjestelmää varten. Ongelmaksi muodostuu kuitenkin tiedonkeräysmenetelmien vaihtelevuus ja standardisoitujen CDR-formaattien puute. Yksinkertainen kuva toiminnasta on esitetty kuvassa 2. Raaka kirjaamistieto Välityspalvelin Laskutusjärjestelmä VoIP- Yhdyskäytävä(t) RADIUS SNMP TACACS+ TFTP... Kuva 2. Esimerkki laskutuksen toteuttamisesta IP-verkossa Kirjaamistieto kerätään verkkoelementeiltä käyttämällä esimerkiksi AAA (Athentication, Authorization, Accounting) -tyyppisiä protokollia, kuten RADIUS ja TACACS+ [11]. Näitä mekanismeja on esitelty tarkemmin seuraavassa kappaleessa. Kerätty raakamuotoinen kirjaamistieto välitetään joko suoraan laskutusjärjestelmälle tai välityspalvelimelle, joka muokkaa ja tarkistaa tietoa samaan tapaan kuin väliprosessointi PSTN-verkoissa. Tämän jälkeen tieto on valmiina laskutusjärjestelmässä tapahtuvaan prosessointiin, mikä lopuksi johtaa laskun lähettämiseen asiakkaalle. Protokollaa voidaan käyttää myös ns. prepaid-palveluissa, jolloin yhdyskäytävälle välitetään tieto siitä, kauanko puhelu saa kestää. Laskutus on varsin ongelmatonta, jos pysytään yhdessä, hallinnoltaan yhdenmukaisessa verkossa. Ongelmia kuitenkin kohdataan otettaessa reititykseen mukaan toiselle organisaatiolle kuuluva verkko. Ratkaisuja tähän ongelmaan on esitetty dokumentin viimeisessä kappaleessa. 4
1.3 Kirjaamismenetelmät Jotta CDR tiedostoja voitaisiin luoda laskutusjärjestelmän analysoitavaksi, on resurssien käytöstä kerättävä käyttäjäkohtaista tietoa. Seuraavassa esitellään esimerkkejä menetelmistä tiedon keräämiseksi. 1.3.1 RADIUS (Remote Access Dial-In User Service) RADIUS-protokolla on alun perin määritelty tilaajien todentamista, oikeutusta sekä käyttäjäkohtaisten tapahtumien ja resurssien käytön kirjaamista varten. Standardointityöstä vastaa IETF. RADIUS perustuu asiakasohjelma-palvelin malliin, jossa palvelin vastaanottaa asiakasohjelmilta tulevia pyyntöjä yhteyden todentamiseen ja oikeutukseen sekä pitää kirjaa tapahtumista [1]. Juuri kirjaamistietoja voidaan käyttää hyväksi CDR-tietoja luotaessa. Protokolla sijoittuu TCP/IPprotokollapinossa UDP-kerroksen päälle sovellustasolle ja käyttää UDP porttia 1813. Tietojen suojaus asiakkaan ja palvelimen välillä perustuu jaettuun salaisuuteen (shared secret). Asiakasohjelma, joka voi sijaita esimerkiksi VoIP-yhdyskäytävässä, lähettää yhteyden alussa Accounting-Start paketin palvelimelle. Tämä aloituspaketti sisältää tiedon palvelun käyttäjästä sekä laadusta. Tähän palvelin puolestaan vastaa lähettämällä kuittauksen, olettaen että kirjaaminen on aloitettu menestyksekkäästi. Yhteyden katkettua suoritetaan vastaava toimenpide Accounting-Stop pakettien avulla merkiksi kirjaamisen päättymisestä. Tämä paketti sisältää lisäksi tietoa esim. yhteyden kestosta ja välitetyn datan määrästä. RADIUS-paketin rakenne on kuvattu kuvassa 3 [2] ja taulukossa 1. 0 7 15 31 koodi id pituus autentikaattori parametrit.. koodi ID pituus autentikaattori RADIUS-paketin tyyppi 4=Accounting-Request 5=Accounting-Response kytkee toisiinsa kysely ja vastauksen paketin kokonaispituus käytetään viestien todennukseen asiakkaan ja palvelimen välillä 5
Tuomas Keränen parametrit parametri-arvo-pareja, jotka sisältävät tietoa yhteyden kulusta esim. 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause Varsinainen kirjaamistieto siis välittyy RADIUS-palvelimelle lopetuspakettien mukana, ja ne toimivatkin perustana laskutustietojen luomiselle. RADIUS luo kirjaamistiedoista ASCII-muodossa olevia tiedostoja, joista välityspalvelin pystyy muokkaamaan halutun muotoisia CDR-tietoja. CDR:t puolestaan siirretään laskutusjärjestelmän analysoitavaksi käyttäen esimerkiksi FTP-tiedostonsiirtoprotokollaa. Yhden yhdyskäytävän läpi menevä puhelu koostuu kahdesta haarasta, joista RADIUS-protokollan avulla voidaan pitää kirjaa: sisääntulevasta- ja ulospäin suuntautuvasta haarasta. Jos puolestaan on kyseessä kahden yhdyskäytävän läpi reititetty puhelu (siis PSTN-verkosta PSTN-verkkoon), on haaroja vastaavasti neljä. Yhdestä puhelusta siis kirjautuu kahdesta neljään RADIUS-kirjanpitoa, jotka voidaan yhdistää Session-Id parametrin avulla toisiinsa ja täten saavuttaa luotettava kirjaamistarkkuus ja - luotettavuus. Cisco Systems käyttää omissa tuotteissaan RADIUS-protokollan lisäksi kehittämäänsä TACACS+ protokollaa, joka on toiminnallisuudeltaan RADIUSta vastaava. Tästä poiketen se kuitenkin toimii TCP:n päällä tuoden järjestelmään lisää luotettavuutta [11]. Tällä hetkellä IETF valmistelee RADIUS-protokollalle seuraajaa nimeltä DIAMETER, jonka pitäisi tulevaisuudessa vastata paremmin päätelaitteiden liikkumiseen liittyviin haasteisiin. Tälle protokollalle löytynee käyttöä mm. SIP-protokollaan liittyvien laskutustoimintojen yhteydessä. 1.3.2 SNMP (Simple Network Management Protocol) SNMP on IP-verkoissa yleisesti käytetty verkonhallintaprotokolla. Sitä tukevat verkkoelementit keräävät tietoa toiminnastaan MIB-kantoihin, joita voidaan määritellä valmistajakohtaisesti. SNMP siis tarjoaa kehyksen, jonka mukaan uusia MIB-kantoja voidaan määritellä varsin vapaasti koskematta varsinaiseen SNMP-standardiin[5]. Verkonhallintapalvelin voi siis suorittaa kyselyjä verkkoelementeille käyttäen SNMP:a, ja saada vastaukseksi kirjaamistietoja sen läpi kulkeneesta liikenteestä. 6
Yksi esimerkki tällaisesta menetelmästä on RTFM- liikennevuon mittausjärjestelmä [3], sekä siihen liittyvä RTFM-MIB. Lisäksi IETF on määritellyt mm. MIBin kirjaamistapahtumille yhteydellisissä verkoissa, kuten ATM ja Frame-Relay. Tätä voidaan käyttää hyväksi, jos tietoa halutaan kerätä resurssien käytöstä toisen kerroksen palveluista IP:n sijaan (esim. VoATM). VoIP-käytössä olevat MIB-kannat ovat kuitenkin enimmäkseen valmistajakohtaisia, mikä tekee SNMP:n käytöstä ongelmallisen verkoissa, joissa on lukuisten eri valmistajien laitteita. 1.3.3 Muita menetelmiä Koska portinvartija hallitsee VoIP-liikennettä hallinnollisen verkon sisällä, monet valmistajat ovat liittäneet niiden yhteyteen toiminnallisuuden, jonka avulla on mahdollista kerätä VoIP-puheluista lokitietoja, ja tallentaa niitä joko tiedostoon tai laskutusjärjestelmän luettavissa olevaan relatiiviseen tietokantaan. Näitä tietoja voidaan järjestelmän puolesta käyttää laskutustietojen muodostamiseen. Valmistajakohtaisista liikenteen kirjausjärjestelmistä lienee syytä mainita esimerkkinä Cisco Systemsin kehittämä NetFlow, joka pystyy tarkkailemaan ja kirjaamaan verkoissa tapahtuvaa liikennettä. Useimmat laskutusjärjestelmien valmistajat tukevat NetFlowta tuotteissaan. 1.4 CDR-formaateista IP-verkoille ei ole vielä varsinaisesti määritelty yhtenevää CDR-formaattia. Spesifikaatiotyöt on kuitenkin aloitettu, ja kehitteillä on kaksikin eri määrittelyä, IPDR (Internet Data Record) [12] ja VON (Voice Over Network record format). Tällä hetkellä keskeneräisistä formaateista on kuitenkin varsin rajallisesti tietoa saatavissa. IPDR formaattia valmistelee eri valmistajista muodostuva yhteenliittymä, ja ensimmäisen prototyypin tästä ilmeisesti XML-pohjaisesta menetelmästä pitäisi olla valmiina lähiaikoina. Koska IP:lle optimoitujen CDR-formaatien valmistelu on vielä kesken on välityspalvelimien tuotettava joko valmistajakohtaista tai PSTN-verkoissa tunnettua määriteltyä formaattia. Esimerkkinä näistä voisi mainita ITU-T:n määrittelemän Q.825 Call Detail Recording suosituksen[7], jossa määritellään, kuinka CDR-tietoja tuotetaan ja hallitaan eri verkkoelementeissä. Suositus sisältää myös mallin, jonka mukaan tietoja siirretään tuottajalta tietojen käyttäjälle. Lisäksi telekommunikaatiomaailmassa on varsin laajassa käytössä Bellcoren määrittelemä AMAformaatti (BAF). Yhteistä kaikille formaateille kuitenkin on, että ne sisältävät perustiedot käyttäjän generoimasta liikenteestä; A- ja B-tilaajien numerot, yhteyden aikaleimat, puhelun keston tai siirretyn datan määrän, tilakoodin ja tietoja käytetyistä reiteistä. Yleensä CDR luodaan yhteyden päättyessä, mutta se voidaan generoida myös tietyin sekvenssein. 7
Tuomas Keränen 1.5 Välityspalvelimet Välityspalvelimen pääasiallisena tehtävänä on kerätä raakamuotoinen kirjaustieto ja tarjoilla se sopivassa muodossa laskutusjärjestelmälle. Tämä on tarpeellista, koska nykyiset järjestelmät perustuvat pitkälti useiden eri laitetoimittajien toimittamille ratkaisuille. Lisäksi palvelin suorittaa datan tarkistusta ja pyrkii jo ensivaiheessa varmistamaan, ettei laskutusjärjestelmälle mene virheellisiä tietoja[8]. Lisäksi palvelin muodostaa yhden CDR:n yhteyttä kohti tilanteissa, joissa esimerkiksi pitkästä puhelusta on generoitunut useampia (kuva 3). Välityspalvelimilla on lisäksi oma tietokantansa raakadatan puskurointiin, prosessoitujen CDR:n tallentamiseen ja erilaisille auditointilokeille. Laskutusjärjestelmä CDR-data Jakelu Kanta Muunnos Tarkistus Keräily Loki Raaka kirjausdata Reititin Yhdyskäytävä Yhdyskäytävä Kuva 3. Välityspalvelimen toiminta 1.6 Inter-Domain VoIP PSTN- verkoissa puhelun välittäminen kahden eri verkon välillä perustuu yleensä verkko-operaattoreiden kahdenvälisiin sopimuksiin. Kirjaustietoja verrataan tietyn periodin välein, ja korvaukset suoritetaan verkkojen käytön mukaan sovittuna ajankohtana. On kuitenkin nähtävissä, että tulevaisuudessa samankaltainen menetelmä IP-maailmassa johtaisi hankaluuksiin Internet-operaattoreiden määrän kasvaessa jatkuvasti. Kahdenvälisten sopimusten määrä saattaisi samalla kasvaa vaikeasti hallittaviin mittasuhteisiin. Tätä ongelmaa on pyritty ratkaisemaan ns. 8
Clearing-house mekanismilla, jossa laskutusasiat sovitaan keskitetysti ns. luotetun sovittelupalvelimen välityksellä. 1.6.1 INOW!-aloite Laitteiden yhteensopivuus on kuitenkin ensisijaisesti verkkojen välisten VoIP-palveluiden esteenä. IMTC:n (The International Multimedia Teleconferencing Consortium) inow!-yhteenliittymä on määrittelemässä yhteensopivuusprofiilia yhdyskäytäville ja portinvartijoille, jotka toteuttavat ITU-T:nn suosituksia H.323 ja H.225.0 [10]. Aloitteessa keskitytään juuri Inter-domain palveluihin ja palvelimien yhteensopivuusongelmiin puheluiden välityksessä ja osoitteistuksessa. Järjestelmä perustuu sertifiointiin, joka suoritetaan testaamalla järjestelmä inow!-ryhmän määrittelemin testausmenetelmin. Järjestelmässä on kuitenkin heikkouksia: Se ei skaalaudu useampien sovittelupalvelimien käyttämiseen Se on sidottu H.323 protokollaan, eikä tue esimerkiksi SIPprotokollan käyttöä Inter-domain-laskutus ei ole mahdollista verkoissa, joissa ei ole portinvartijaa. 1.6.2 Open Settlement Protocol OSP on ETSI/TIPHON työryhmä 3:n standardi, joka mahdollistaa sovittelukäytännön käytön ns. Clearing-House-tyyppisen yhteenliittymän sisällä riippumatta käytetystä protokollasta. Tällöin verkkojen välinen laskutus ei siis perustu kahdenvälisiin sopimukseen, vaan OSPsovitteluserverin käyttöön ulkopuolisen verkon resursseja käyttäessä (Kuva 4). Tällöin OSP-palvelin toimii luotettuna välittäjänä useiden eri palvelutarjoajien välillä. 9
Tuomas Keränen OSP Palvelin IP IP IP IP PSTN PSTN Palveluntarjoaja 1 Palveluntarjoaja 2 Kuva 4. Open Settlement- protokollan toimintaympäristö Järjestelmä perustuu XML-pohjaisten viestien lähettämiseen yhdyskäytävien ja sovitteluserverin välillä, kun halutaan käyttää ulkopuolisen verkon resursseja[9]. XML-dokumentit lähetetään HTTPprotokollan päällä käyttäen suojaukseen SSL tai TLS-teknologioita sekä mahdollisesti digitaalista allekirjoitusta. Liikenne koostuu neljästä erilaisesta osasta: Todennus. Kun halutaan käyttää ulkopuolisen verkon resursseja puhelun reititykseen, tulee soittaja todentaa vastaanottavalle verkolle. Oikeutus käyttää verkon palveluita. Sovitteluserveri varmistaa, että puhelu voidaan ohjata ulkopuoliseen verkkoon. Hinnoittelu. Palvelun hinnoittelu on kommunikoitava sovittelupalvelimelle. Tämä tosin voidaan tehdä etukäteen. Käyttö. Käyttörekisterissä ilmoitetaan käyttötietoa, kuten aikaleimat, soittajan tiedot ja vastaanottavan palvelimen IP-osoite, sekä haluttaessa QoS-tietoa. 10
Ohessa esimerkkinä XML-pohjainen käyttöraportti yhdyskäytävältä OSPpalvelimelle: <?xml version=1.0?> <Message messageid="123454321" random="12345678"> <UsageIndication componentid="13579990"> <Timestamp> 2000-01-24T22:03:00Z </Timestamp> <Role> source </Role> <TransactionId> 67890987 </TransactionId> <CallId encoding="base64"> YT64VQpfyF467GhIGfHfYT6jH77n8 </CallId> <SourceInfo type="e164"> 81458811202 </SourceInfo> <DestinationInfo type="e164"> 4766841360 </DestinationInfo> <DestinationAlternate type="transport"> [10.0.1.2]:112 </DestinationAlternate> <UsageDetail> <Service/> <Amount> 10 </Amount> <Increment> 60 </Increment> <Unit> s </Unit> </UsageDetail> </UsageIndication> </Message> 11
Tuomas Keränen 1.6.2.1 OSP ja SIP OSP soveltuu hyvin käytettäväksi SIP-protokolla rinnalla. IETF:ltä on ilmestynyt tuore työkopio dokumentista, jossa kuvataan SIP:n ja OSP:n yhteistoimintaa[4] nimenomaan Inter-domain-palveluissa. Pääperiaatteeltaan järjestelmä toteuttaa kuvassa 4 esitettyä arkkitehtuuria. Tässä arkkitehtuurissa OSP-palvelinta voidaan käyttää myös hallitsemaan palvelun laatua yhteyden päästä päähän RSVP-protokollaa hyväksikäyttäen. SIP- ja OSP-palvelimien välillä liikkuu yhteyden aikana mm. seuraavia käyttöparametrejä: 1. Soittaja pyytä oikeutusta käyttää verkkoa: SIP Call ID Called Number Calling Number 2. OSP ilmoittaaa vastauksen SIP-palvelimelle: Called Number Authorization Token 3. Kun vastaanottaja saa INVITE-viestin, se lähetää oikeutuspyynnön OSP-palvelimelle: SIP Call ID Called Number Calling Number Authorization Token 4. Käyttöparametrit puhelun kummaltakin osapuolelta OSPpalvelimelle: Call Duration Called Number Calling Number SIP Call ID Authorization Token 12
1.7 Lähdeluettelo [1] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "RemoteAuthentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. [3] N. Brownlee etc., Traffic Flow Measurement: Architecture, RFC 2722 [4] S. Sinnreich etc., Interdomain IP Communications with QoS, Authorization and Usage Reporting, Internet draft [5] D. Harrington etc. An Architecture for Describing SNMP Management Frameworks. RFC 2217, January 1998 [6] Adoba etc, Instuction To Accounting Management, Internet Draft [7] Brownlee etc., Accounting Attributes and Record Formats, Internet Draft, February 2000 [8] Accounting in the PSTN, Teemu Mäkelä, HUT, April 1999 [9] ETSI TIPHON Working Group 3, Inter-domain pricing, authorization, and usage exchange, v1.4.2, December 1998 [10] Interoperability Now (inow!), http://www.imtc.org/act_inow.htm [11] Cisco Billing Architecture, Cisco Systems 1999 [12] The IP Detail Record Initiative, White Paper, http://www.ipdr.org/ipdrwp.pdf 13