ÚJ, MEGOLDÁSRA ÉPÜLŐ KOMMUNIKÁCIÓS SZOLGÁLTATÁSOK Benyó Balázs Informatika Tanszék Széchenyi István Egyetem 9026 Győr, Egyetem tér 1. benyo@sze.hu Kulcsszavak: internetes tartalomszolgáltatás, telekommunikációs szolgáltatás, eljárás, DNS adatbázis, NAPTR rekord, felhasználó azonosítás, alkalmzás kliens I. BEVEZETŐ Az (Telephone Number Mapping) egy olyan internetes műszaki megoldás, amely lehetővé teszi, hogy az internetes domain név rendszert (DNS), mint egy világméretű elosztott adatbázist felhasználva, valamely E.164 szabvány [1] szerinti telefonszámhoz különféle internetes, és hagyományos távközlési szolgáltatásokat rendeljünk, és azt a telefonszám alapján elérjük. Az műszaki megoldás magja az az eljárás [7], mely a telefonszámokat egyértelműen Internet domain névvé alakítja át. Az megoldásra épülő rendszerekben két világ találkozik: az internetes világ és a távközlési világ. A két világ eltérő fejlődése számtalan problémát vet fel, amelyeket az együttműködés érdekében meg kell oldani. Ilyen lényeges eltérés, hogy a két világ másmás eljárást használ az előfizetők, szolgáltatások azonosítására. A különböző szolgáltatások számának gyors növekedésével mindkét területen nagymértékben megnövekedett egy felhasználó által használt azonosítók száma. Ennek, a távközlési és tartalomszolgáltatások területén egyaránt jelentkező problémának a megoldására vonatkozó kritériumok azonosak: A felhasználók által használt és tárolt azonosítók fajtája csökkenjen. Az azonosító egyszerűsítse az autentikációt, és egyben növelje annak hatékonyságát. Könnyen meghatározható legyen, hogy hogyan lehet egy másik felhasználóval kommunikálni, és milyen azonosítót kell használni. Ne lehessen könnyen hamisítani, csalás ellen védett legyen. Jelenleg több módszer van fejlesztés, kidolgozás alatt, ezek közül néhány fontosabb: Az, mely az E.164 szerinti telefonszámokat az.e164.arpa domain név tartományba konvertálja át. Az egyirányú átalakítás, csak a telefonszámokat alakítja át domain névvé.
Univerzális Távközlési Azonosító UCI. Ez az ETSI által javasolt, az EU által támogatott új azonosítási rendszer. Az UCI három részből áll: Egyedi szám azonosító + természetes név + kiegészítő információ. Az egyedi szám azonosító szolgál a hívó és a hívott fél azonosítására, ez az E.164 kibővítése. Az egyedi név az előfizetőt azonosítja. Microsoft Passport. A Microsoft szervereken fut, a meglévő email címeken alapul. Liberty Alliance. Számos szolgáltató által támogatott nyílt kezdeményezés, elosztott architektúrájú rendszer, melyben a felhasználók nem rendelkeznek master azonosítóval. Ezek közül az elsőként említett eljárás a leggyorsabban terjedő, legnagyobb támogatottságú megoldás. Jelen cikk egy olyan kutatásfejlesztési projektet mutat be, melynek célja olyan új, megoldásra épülő szolgáltatások megvalósítása, melyek kihasználják az technológia nyújtotta előnyöket, és versenyképesek a meglevő szolgáltatásokkal. A projekt célja a szolgáltatások megtervezésén és technikai megvalósításán túl a szolgáltatások működtetését leíró üzleti modellek kidolgozása. A cikk első része bemutatja az eljárást és annak alkalmazási lehetőségeit, majd ismerteti a közelmúltban indult projekt eddigi eredményeit. II. AZ FUNKCIONÁLIS MODELLJE Az működésének alapja az Interneten alkalmazott világméretű elosztott adatbázis, a domain név rendszer. Ezt az adatbázis használják fel arra, hogy a telefonszámokhoz a felhasználó elérésére adatokat tároljanak és keressenek ki az Interneten alkalmazott különböző szolgáltatásokhoz. Ehhez a telefonszámokat olyan DNS azonosítóvá kell konvertálni, amihez információs rekordokat lehet kötni. A telefonszámok International Telecommunication Union (ITU) által készített ITU-T E.164 ajánlás szerinti hierarchikus felépítése miatt a konverzió egyértelműen elvégezhető. Egy számhoz több adatbázis rekord (Naming Authority Pointer NAPTR) tartozhat. A rekordokban elvben minden jelenleg meglevő és később kialakuló szolgáltatáshoz tartozó fontos információ elhelyezhető egy ún. Uniform Resource Identifier (URI) formájában [4]. Az URI-k értelmezése elsősorban a DNS bejegyzéseket lekérő kliens programra van bízva, így egy URI kiválasztásával elindítható a kommunikáció a megfelelő alkalmazás segítségével a kapott URI azonosító alapján. Például hívás indítható az IP telefonra, fax küldhető a megadott számra, e-mail küldhető a megadott címre, stb. Az adatokat a DNS tárolja. Az adatok tárolása és a rendszer működtetése a domain nevek tárolásához és működtetéséhez hasonló. Az adatok adminisztrációja hierarchikusan, felülről lefelé, három szinten történik. Mivel a telefonszámok kiosztását szigorú nemzetközi előírások szabályozzák, az adminisztráció szintjeit ezekhez illesztik [2][3].
Az megvalósítás a 1. ábrán látható háromszintű architektúrára épül. A DNS mindhárom szintjén vannak adminisztratív és működtetési feladatok, ezen kívül kapcsolatot kell tartani az E.164-es telefonszámok előfizetőivel, a távközlési szolgáltatókkal és a számgazdálkodást végző szervezetekkel is. Ez utóbbira annak ellenőrzésére van szükség, hogy az adatokat a telefonszámok birtokosa viszi a DNS-be. ITU 0. szint nyilvántartó Nemzeti keretszabályozás Delegálás 1. szint nyilvántartó Validálás Delegálás regisztrátor Hatóság, Távközlési szolgáltató 2. szint nyililvántartó előfizető (regisztrált) E.164 számkijelölés Együttműködés Szabályozás, adminisztráció Alkalmazások 1. ábra Az funkcionális modellje A megvalósítás alapelvei: Általános alapelvek: Olyan általános szabályok gyűjteménye, melyek biztosítják, hogy az rendszer ne veszyélyeztesse a telefonszámok eddigi felhasználását. Önkéntesség elve: Az -ban való részvételhez a telefonszám birtokosának a kifejezett
kérése szükséges ahhoz, hogy az E.164-es telefonszámát az domain-ben regisztrálják és a számhoz bármilyen NAPTR rekordot közzétegyenek. Ez azért fontos, mert az rekord a DNS lekérdezéssel nyilvánosan elérhető. Elvek a hívók és a szolgáltatók részére: Amikor a hívó fél egy E.164-es telefonszámot tárcsáz, alapértelmezésben a meglévő (ITU-T E.105 ajánlás szerinti) telefonszolgáltatást kell nyújtani az bevonása nélkül. III. AZ TECHNOLÓGIA A fejezet a technológia legfontosabb elemeit és azok kapcsolatát ismerteti. A részletes, mindenre kiterjedő specifikációk természetesen az ide vonatkozó szabványok, ill. ajánlások alapján ismerhetők meg. A. Az eljárás Az (Telephone Number Mapping) egy olyan internetes műszaki megoldás, amely lehetővé teszi, hogy az internetes domain név rendszert (DNS) felhasználva valamely E.164 szabvány szerinti számhoz (telefonszámhoz) különféle szolgáltatásokat rendeljünk. A művelet egyik fele, hogy az E.164 szerinti számhoz egy domain név képzési eljárás alkalmazásával, továbbá egy regisztrált (domain név regisztráció) mutató segítségével kikeressük az Interneten azt a zónafájlt, amely az adott E.164 szerinti számhoz tartozó különböző szolgáltatások igénybevételéhez szükséges adatokat tartalmazza. A keresés eszköze az Interneten alapszolgáltatásként hagyományosan működő DNS rendszer, amely egy alfanumerikus karaktersorozathoz egyértelműen hozzárendel egy adatállományt (zónafájlt), amely az adatállomány gazdája által regisztráltatott helyen található az Interneten. A művelet másik fele, hogy a zónafájlban található adatok alapján különféle szolgáltatásokhoz kapcsolódó információhoz juthatunk. Így pl. az adott E.164 szerinti számhoz tartozó email cím(ek)hez, további telefonszám(ok)hoz, fax számhoz, Web címhez, stb. Ezeket az adatokat jellemzően valamilyen alkalmazás használja fel például arra, hogy a telefonszám (az E.164 szerinti szám) ismeretében emailt (például emailben hangüzenetet) küldjön a telefonszám gazdájának, vagy a nyilvános kapcsolt telefonhálózat helyett internetes telefonon kezdeményezze a hívást. Az adatok között egy szolgáltatáshoz több protokoll és cím is fel lehet sorolva, sőt közöttük rangsort lehet megadni. Például megadhatjuk, hogy telefonhívást inkább az Interneten x címen szeretnénk kapni, de ha ez nem működik, akkor a nyilvános telefonhálózat y számán várjuk a hívást. A zónafájlban az információ ún. erőforrás rekordok (RR - resource record) formájában található. Az definiál olyan erőforrás rekord formátumokat, amelyek az ilyen szolgáltatások megvalósításához szükségesek. A szabvány nyitott olyan értelemben, hogy újabb és újabb szolgáltatás típusok definiálására ad módot.
Az lényegét az RFC 2916 (E.164 numbers and DNS) számú internetes szabvány írta le, amit 2000 szeptemberében fogadtak el. Mára ezt tovább bővítették, az újabb változat az RFC 2916bis (The E.164 to URI DDDS Application) jelzést viseli, de ez még nem lezárt, hivatalosan még nem elfogadott szabvány. B. A DNS gyökér meghatározása A DNS-ben egy teljes domain név egyediségét az garantálja, hogy a névadás hierarchikus, fordított fa struktúrában történik. Ahhoz, hogy az E.164 szerinti számok szerint a DNS-ben kereshessünk, előbb el kell helyezni az E.164 szerinti számokból képzett nevet a DNS hierarchiában olyan helyen, ahol az így előálló név már egyedi lesz az egész globális DNS rendszerben. A szabvány erre a célra az.e164.arpa alatti névteret jelöli ki. A.arpa legfelső szintű domain a címeknek és útválasztó paramétereknek van fenntartva (Address and Routing Parameter Area). Ez alatt hozták létre az e164 jelölésű domaint, amely az céljaira használható [8]. Az helyét a DNS hierarchiában a 2. ábra mutatja. C. Az E.164 szerinti számok átalakítása domain névvé Annak érdekében, hogy egy E.164 szerinti szám alapján a világon bárki egyértelműen meghatározhassa, hogy abból milyen domain nevet kell képezni, pontosan meg kell határozni a szám átalakításának módját domain névvé. Ez a következőképpen történik: A kiinduló formátum az E.164 szerinti szám a teljes alakjában, tartalmazva az országkódot is (pl. +36 1 234 5678). Az átalakítás első lépcsőjében csak a szám karaktereket hagyjuk meg és közéjük pontot helyezünk el (pl. 3.6.1.2.3.4.5.6.7.8). Az átalakítás második lépcsőjében az előző lépésben nyert karaktersorozatot elhelyezzük a DNS fordított hierarchikus rendszerében az gyökér alá. Ez úgy történik, hogy az első lépésben nyert karaktersorozatot fordított sorrendben írjuk le és a végére illesztjük a.e164.arpa karaktersorozatot (pl. 8.7.6.5.4.3.2.1.6.3.e164.arpa). Ezzel megkaptuk a DNS használatához szükséges ún. teljesen meghatározott domain nevet.
Gyökér.arp.hu....com.e164.arp.in-addr.bme 2. szintű domain 2. szintű domain.6.3.e164.arpa.ik 3. szintű domain... 8.7.6.5.4.3.2.1.6.3.e164.arpa 2. ábra Az helye a DNS hierarchiában A DNS rendszer számára bemenetül szolgáló domain név láthatólag közvetlenül nehezen értelmezhető. De a rendszer nem is arra számít, hogy a felhasználók közvetlen DNS parancsokat adnak ki, majd a választ értékelve megállapítják pl. a nevezett email címét. A tervezők arra számítanak, hogy ezeket a feladatokat kliens program végzi. Az kliens programok pedig vagy más alkalmazásoktól (kliens vagy szerver programoktól) kapják a bemenő adatokat vagy barátságos felhasználói felületeket szolgáltatnak, ahol a telefonszámok a szokásos írásmóddal adhatók meg. Tehát pl. a számítógép képernyőjén megjelenő "Melyik telefonszámhoz tartozó email címet keresi?" kérdésre nyugodtan beírhatjuk a "+3612345678" karaktersorozatot, mert a program ezt értelmezi és elvégzi az átalakítási lépéseket, majd a DNS-nek elküldi a 8.7.6.5.4.3.2.1.6.3.e164.arpa domain névre vonatkozó kérdést. A választ hasonlóképpen vagy programok kapják vagy ember, ez utóbbi esetben nyilvánvalóan valamilyen érthető formátumban és kommentárral. A továbbiakban azt tárgyaljuk, hogy a kérdésre milyen válaszok érkezhetnek. D. A DNS lekérdezésre adott válasz Az előző pont szerint előállított domain névre elküldött szabályos DNS lekérdezés bármely más domain névre vonatkozó lekérdezéshez hasonlóan végigjárja a DNS-ről szóló részben tárgyalt utakat. A lényeg, hogy a rendszer előbb-utóbb megtalálja azt az autoritatív választ tudó szervert, illetve azt a zónafájlt, amely az adott domain névhez tartozó erőforrás rekordokat tartalmazza. Természetesen most nem a domain névhez tartozó IP címre van szükségünk (az A erőforrás rekordra), hanem különböző
szolgáltatásokra vonatkozó információkra. Szerencsére a DNS rendszer lehetővé teszi, hogy a zónafájlban többféle erőforrás rekord legyen és ezeket a rendszer el is küldi a lekérdezésre adott válaszban. Ezután a lekérdező feladata a kapott rekordok közül a neki szükségeseket kiválasztani és azokat értelmezni. Az lekérdezés a zónafájlban elhelyezett NAPTR (Naming Authority Pointer) erőforrás rekordokra kíváncsi, mert ezek tartalmazzák a számára fontos információkat. A NAPTR rekordokban olyan bejegyzéseket találhatunk, amelyek további erőforrások elérésének módját, helyét mondják meg az ún. URI (Uniform Resource Identifier) szintaxis szerint. A különböző szolgáltatásokhoz különböző URI-kat találunk, illetve egy szolgáltatáshoz találhatunk több URI-t, amelyekhez különböző preferencia szint van megadva. Az alkalmazás tehát a DNS lekérdezésre válaszul egy URI listát kap, amelyből kiválasztja az adott szolgáltatáshoz, az adott helyzetben megfelelőt (pl. email üzenet küldéséhez szükségeset). A következő lépés függ az adott szolgáltatástól, de rendszerint az következik, hogy az URI domain név részét véve az alkalmazás egy újabb DNS lekérdezést hajt végre, ímmár az URI-ból nyert domain névre vonatkozóan és így jut hozzá ahhoz az IP címhez, amely címen már a tulajdonképpen elérni kívánt szolgáltatással, számítógéppel közvetlenül kapcsolatba léphet. A folyamatot leegyszerűsítve úgy vázolhatjuk, hogy a hagyományos domain név -> IP cím feloldás elé egy megelőző lekérdezés kerül, amely során a telefonszámból képzett domain névből egy szolgáltatás specifikus domain névhez és protokoll megválasztáshoz jutunk. E. Az alkalmazások működésének általános sémája Ezek után vizsgáljuk meg az alkalmazások működéi modelljét. Egy tipikus alkalmazás működése a következő (0. ábra): Az alkalmazás (azaz az kliens) előállítja az E.164 formátumú számból a domain nevet. Pl.: +36 1 234 5678 3.6.1.2.3.4.5.6.7.8. e164.arpa (ld. 5.1.3 pontban) Az kliens szoftver egy DNS lekérdezést indít az előállított domain névre. A lekérdezésre válaszul az NS-től ( nyilvántartók névszerveitől) megkapja az adott zónafájlban tárolt, kért domain névhez tartozó erőforrás (NAPTR) rekordokat. Az alkalmazás az NAPTR rekordok közül kikeresi az adott típusú szolgáltatásra vonatkozó bejegyzéseket. A bejegyzések tartalma alapján amennyiben az adott szolgáltatás megvalósításához szükség van rá további hagyományos, domain név IP cím feloldó lekérdezéseket kezdeményez.
1.szint Nyilvántartó NS 2.szint Nyilvántartó NS frissítések Regisztrátor NAPTR rekordok rendszer NAPTR rekord lekérdezések Előfizető rendszerre épülő alkalmazás alkalmazás kliens Alkalmazás szerver Alkalmazás kliens szoftver Az alkalmazások által megteremtett kommunikációs kapcsolat felhasználó 3. ábra alkalmazás általános működési sémája Az egyes szolgáltatások megvalósításához különböző típusú információt kell az NAPTR rekordokban tárolni. Az, hogy egy adott NAPTR rekord melyik szolgáltatásra vonatkozó információt tartalmazza az NAPTR rekord Szolgáltatás mezője fogja azonosítani az RFC 3401-3405 -ben (Dynamic Delegation Discovery System) leírt formában. Az NAPTR rekordok általános szintaktikája jól definiált az RFC 2916bis-ben. Ugyan az RFC 2916bis még nem hivatalos szabvány, azonban a vele kapcsolatos egyeztetés igen előrehaladott állapotában van. Fontos kiemelni, hogy az a szolgáltatások a szempontjából teljesen nyílt, mindenki olyan szolgáltatást, ill. hozzá tartozó NAPTR rekordot definiálhat, amit szeretne. Az egyes szolgáltatásokhoz tárolandó információ, ill. a tárolás formátuma jelenleg szabvány által nem szabályozott. Világszerte folynak kísérletek (trial-ek) az szolgáltatásokkal kapcsolatban. Vannak olyan szolgáltatások, amelyek NAPTR leírásának szintaxisára már véglegesnek tűnő javaslatok vannak, mások még képlékeny állapotban vannak. Azonban egyik esetben sem beszélhetünk hivatalosan elfogadott szabványokról.
Ilyen körülmények között fennáll a veszélye annak, hogy a különböző országokban folyó kísérletekben szolgáltatásokat megvalósító rendszerek nem tudnak együttműködni egymással. Ennek az inkompatibilitásnak a veszélye nagy, hiszen az egyes szolgáltatások bevezetését célzó kísérletek különböző országokban folynak, így az -os domain névhez tartozó bejegyzéseket (NAPTR rekordokat) különböző Regisztrátor rögzíti. A 4. ábrán olyan rendszer működését láthatjuk, melyben több kísérleti rendszerek működik. A domain nevek lekérdezésekor az kliens számára transzparens, hogy melyik Regisztrátor által rögzített telefonszámhoz tartozó domain nevet kérdezi le. Az ábrán jól látható, hogy a kliens a domain névtől függően bármelyik NS-től kaphat választ, vagyis nem biztos, hogy a saját kísérletében résztvevő Regisztrátor által rögzített NAPTR rekordot fogja megkapni. Ha különböző kísérletekben használt NAPTR rekordokban tárolt információ nem kompatibilis egymással, az kliens nem fog tudni az alkalmazás számára értelmezhető NAPTR rekordokat lekérdezni, ill. tovább adni [6]. kísérlet 1 kísérlet 2 1. szint Nyilvántartó NS 1. szint Nyilvántartó NS Regisztrátor frissítések 2. szint Nyilvántartó NS 2. szint Nyilvántartó NS frissítések Regisztrátor NAPTR rekordok NAPTR rekordok Előfizető NAPTR rekord lekérdezések NAPTR rekord lekérdezések Előfizető alkalmazás kliens Az alkalmazások által megteremtett kommunikációs kapcsolat Alkalmazás szerver felhasználó Alkalmazás kliens szoftver Az alkalmazások által megteremtett kommunikációs kapcsolat 4. ábra Különböző kísérleti alkalmazások együttműködése
F. szolgáltatások és a hozzájuk tartozó DNS bejegyzések Az eljárás megvalósításának kérdéseit különböző technikai ajánlások specifikálják. Ezek pontosan definiálják az kliensek szerepét, ajánlott működési módjukat az URI sémák tartalmát és formáját. Ezek a technikai ajánlások tartalmazzák a szolgáltatások egy minimális alaphalmazát, melyek olyan NAPTR rekordokat leírását tartalmazzák, melyeket minden kliensnek értelmeznie kell. Ezen felül létezik a az NAPTR rekordoknak, ill. az ezekhez tartozó szolgáltatásoknak egy olyan köre, mely szolgáltató specifikus. Annál is inkább igaz ez, hiszen az egyik fontos előnye az, hogy nyitott, minden szolgáltató kiterjesztheti az NAPTR rekordok halmazát. G. szolgáltatások minimális alaphalmaza Minden szolgáltatás definíciónak a következő formátumúnak kell lennie: típus:altípus az RFC 2916bis szerint, kivéve a sip és a h323 szolgáltatásokat, amelyekben csak típus megnevezés szerepel. A következő definíciókban az altípus helyén szereplő azonosító az NAPTR rekordban tárolt URI sémával megegyezik. szolgáltatások média stream átvitelre Ez az szolgáltatás mező olyan erőforrás azonosítására szolgál, amely interaktív (media stream exchange) hívások lebonyolítására alkalmas. o Hang átviteli szolgáltatások. o Videó átviteli szolgáltatások. szolgáltatások egyedi üzenet küldésre Ez a csoportja az szolgáltatás mezőknek olyan erőforrások azonosítására szolgál mely alkalmas különálló (egyedi) (non-session related) üzenetek vagy dokumentumok fogadására. Ezt a csoportját az szolgáltatás mezőknek akkor kérdezi le a kliens alkalmazás, ha üzeneteket (pl. faxot) akar a címzettnek küldeni. szolgáltatások információ forrásokra Ezek az szolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított erőforrások információ források lehetnek. Ezek a szolgáltatások az üzenet küldő szolgáltatások ellentétei, hiszen ezek az információ adói, míg az előzőekben ismertetett üzenetküldők az információ nyelői. szolgáltatások szolgáltatást feloldó (engedélyező) szolgáltatásokhoz Az szolgáltatásoknak ezt a csoportját akkor használjuk, ha az Előfizető az mellett az -tól független "Service Resolution Service" szolgáltatást akarja használni. Erre akkor van szükség, ha az szolgáltatások köre olyan tényezőktől függ, amelyeket az rendszer nem kezel. Ilyen lehet például a hirdetés szolgáltatás, amikor is a hirdetést küldő (jelen esetben a lekérdezést indító) személyének azonosítása után küldhető csak vissza a kért információ.
szolgáltatások session-oriented üzenet küldésre Ezek az szolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított távoli erőforrás alkalmas chat-elésre (chat sessions session-oriented message exchanges). Ez különbözik a korábban említett e-mail szolgáltatástól, ahol különálló leveleket lehetet küldeni. szolgáltatások hirdetmények megjelenítésére Az szolgáltatások ezen csoportja olyan szolgáltatásokat jelöl, ahol az Előfizető az kliensen keresztül közvetlen üzeneteket tud küldeni a az felhasználónak. szolgáltatások átirányítása Ez az szolgáltatás különleges abból a szempontból, hogy magában foglalja az összes többi szolgáltatást. A cél az volt, hogy egy alapértelmezett szolgáltatást lehessen definiálni. Ezt arra lehet használni, hogy az adott NAPTR rekordban ne kelljen tovább részletezni, hogy rekordban megnevezett erőforrás milyen szolgáltatásokat támogat. Az ilyen rekordot definiáló Előfizető kijelenti, hogy az NAPTR rekordban leírt erőforrás(ok) minden szolgáltatást támogat(nak). Ez azonban a gyakorlatban azt jelenti, hogy a végfelhasználónak tovább fel kell dolgoznia az NAPTR rekordot kifejtve a reguláris kifejezést annak érdekében, hogy azonosítani tudja a benne definiált URI-t és eldönthesse, hogy a szóban forgó NAPTR rekordot fel tudja használni, vagy el kell dobnia. H. További szolgáltatások szolgáltatások helymeghatározásra Ez az szolgáltatás mező jelzi, hogy a hozzá társított erőforrás képes földrajzi elhelyezkedés azonosítására alkalmas információt adni. A tervek szerint az információt Geography Markup Language (GML) segítségével lehet elérni. szolgáltatások nyilvános kulcs (Public Key) megadására Ez az szolgáltatás mező jelzi, hogy a hozzá társított erőforrásról lehetséges Public Key lekérdezése. I. kliensek által lekérdezett információ feldolgozása Általános kliens Az általános kliensnek kell lekérdeznie a DNS-től adott domainhez tartozó összes NAPTR rekordot. Az általános kliensnek fel kell ismernie az szolgáltatások minimális halmazát. Az kliensnek meg kell jeleníteni azokat az szolgáltatásokat, melyekhez a lekérdezett NAPTR erőforrás rekordok tartoznak. Ha például az szolgáltatás E2U+voice:sip, a hozzá tartozó URI sip:user@work.net a kliens felajánlhatja a felhasználónak a Hívja fel telefonon opciót. -képes alkalmazás kliens
Az összes rendelkezésre álló (adott helyen elérhető) alkalmazás klienst indíthatja egy általános kliens. Maguk az alkalmazás kliensek is végezhetnek közvetlen lekérdezéseket. Ezeket a klienseket -képes alkalmazás klienseknek nevezik. Az -képes alkalmazás kliensek csak azokat az szolgáltatásokat kell támogatniuk, melyek használatára tervezték őket. Az igénybevétele az E.164 szám cél mezőbeli, +NNN formátumban való megadásával történik. Azoknál az alkalmazásoknál, melyek közvetlenül megértik az E.164 számokat (pl. PC telefonok), megengedett, hogy külön konfigurálni lehessen, hogy egy adott szolgáltatás megvalósítása előtt végezzenek-e először lekérdezést. Minden -képes alkalmazás kliensnek mindig először az all: szolgáltatást kell lekérdeznie. Ha van ilyen szolgáltatáshoz tartozó NAPTR, akkor további lekérdezéseket kell végrehajtani az : URI sémával megadott domainre. A végtelen hurkok elkerülésére a kliensnek maximum 5 ilyen átirányítást kell csak figyelembe vennie. Ha az -képes alkalmazás kliens talált ann:http szolgáltatást, akkor ezt külön jeleznie kell. (Ez a szolgáltatás a lekérdezett számhoz tárolt hirdetmények megjelenítését jelenti.) Az -képes alkalmazás kliensnek meg kell jelenítenie az összes olyan ann:http szolgáltatást melyek megjeleníthetők az -képes alkalmazás kliens felhasználói terminálján. Az -képes alkalmazás kliensek megjeleníthetik (lejátszhatják) az ann:sip, ann:h323 és ann:tel szolgáltatásokat amennyiben a felhasználói terminál képes ilyen szolgáltatásokat fogadni, ill. megjeleníteni. (Ezek a szolgáltatások különböző formátumban tárolt üzeneteket jeleznek.) Az -képes alkalmazás kliensnek meg kell keresnie az összes olyan NAPTR erőforrás rekordot, melyek olyan szolgáltatásokhoz tartoznak, melyek az adott alkalmazás kliens által megvalósított szolgáltatással kapcsolatosak. Ha nem található olyan NAPTR rekord mely az alkalmazás kliens számára felhasználható szolgáltatást tartalmaz, akkor az -képes alkalmazás kliensnek ezt tudatnia kell a felhasználóval. Ennek a jelzésnek eltérőnek kell lennie a domain nem található jelzéstől. -képes SIP kliens Az -képes SIP kliens először a sip szolgáltatáshoz tartozó NAPTR rekordokat kell keresnie [2]. Ha megtalálta a sip szolgáltatáshoz tartozó NAPTR rekordot, akkor az abban található SIP URI által definiált végponttal veszi fel a kapcsolatot. Ha nem található sip szolgáltatáshoz tartozó NAPTR rekord, akkor az képes SIP kliensnek kereshet voice:sip szolgáltatáshoz tartozó NAPTR rekordot, és ha talál ilyet, akkor létesít csak hang átvitelére alkalmas összeköttetést.
Attól függően, hogy milyen szolgáltatásokat kínál fel a felhasználóknak az adott -képes SIP kliens, megkeresheti a voice:tel, video:sip és video:tel, azután a email:mailto fax:tel és im:sip szolgáltatáshoz tartozó NAPTR rekordokat az adott típusú szolgáltatások felajánlása érdekében. IV. ÜZLETI MODELLEK Az -ra épülő szolgáltatások és alkalmazások definiálásakor a megoldandó problémáknak csak egy része technikai/technológia jellegű. A szolgáltatások megvalósítása érdekében nagyon fontos, hogy a különböző szolgáltatásokhoz ki kell dolgozni a megfelelő üzleti modelleket, ill. folyamatokat, valamint az ezekhez kapcsolódó díjszabási sémákat. A. Díjszabás A telekommunikáció azon területei, melyeket az összeköt, különböző díjszabási megoldásokat alkalmaznak. Míg az Internet hozzáférésekre az átalányár alkalmazása jellemző, addig a hagyományos telefonhálózatot a perc vagy átvitt információ mennyiség alapú számlázás jellemzi. A különféle szolgáltatási scenáriókra alkalmazható díjszabási megoldásokat a bevezetési kísérletek során kell kiértékelni. Az szolgáltatás által generált más költség profilba tartozó E.164 számra történő átirányítás esetén meg kell oldani a fellépő problémás helyzeteket. Például ha egy földrajzi számra irányuló hívás egy mobil vagy emeltdíjas számra kerül átirányításra, akkor a hívó feltételezi a földrajzi számra tartozó tarifát, míg a végződtető operátor a magasabb végződtetési költséget várja el. Vagyis a kiindulási operátornak meg kell győződnie róla, hogy a hívó állja-e a drágább hívási költséget vagy az szolgáltató kompenzálja a végződtető operátort az előfizető költségére. B. Szabályozás Az megoldásra alapuló szolgáltatások megtervezésekor igen alaposan körül kell járni a jogi szabályozás kérdéseit. Az esetén találkozó telefonos világ igen alaposan és részletesen szabályozott, míg az internetes világra pont ennek az ellenkezője igaz. A telefonszám, mint telekommunikációs azonosító, nem telefonálás céljára történő felhasználása sem egyértelműen megengedett az aktuális szabályok szerint, erre az Európai Unió országaiban is eltérő jogi normák vonatkoznak. Az új szolgáltatások bevezetésekor fontos definiálni, hogy telekommunikációs szólgáltatásként, vagy kommunikációt lehetővé tevő műszaki megoldásként jelenik-e meg a felhasználó számára. A telekommunikációs világ igen élesen megkülönbözteti a két fogalmat. Míg az első esetben a szolgáltatónak kötelessége bizonyos rendelkezésreállást, és a segélyhívés lehetőségét garantálnia, úgy a második esetben ez nem kötelező. C. Megtérülés Bármilyen új kommunikációs szolgáltatás bevezetésekor számolni kell a piaci szereplők ellenálásával. Egyik működő szolgáltató sem fog egy alternatív, számára konkurens szolgáltatást támogatni vagy terjeszteni.
Vagy olyan újszerű megoldásokat kell kidolgozni, melyek eddig nem ismert szolgáltatásokat adnak a felhasználóknak, vagy a már meglevő szolgáltatásokat tudják a felhasználók számára lényegesen alacsonyabb áron elérhetővé tenni. Mindkét esetben a felhasználók fogják a szolgáltatás elterjesztését kikényszeríteni a piac többi szereplőjétől. V. NEMZETKÖZI KITEKINTÉS Az elmúlt néhány évben számos kísérleti projekt indult el a világ különböző országában. A technológia iránt fokozott érdeklődést mutatnak az európai országok, de több ázsiai ország is beindította a kísérleti üzemet. Természetesen az Amerikai Egyesült Államokban is több konferenciát rendeztek, ahol beszámoltak az elért eredményekről, ill. ismertették az elsősorban szabályozási problémákat, és azok megoldásainak lehetséges módszereit. Az amerikai számkiosztás miatt ugyanis az első szint adminisztrációja nem egyszerű feladat. A számunkra érdekes európai projektek közül a legfontosabbakat a 1. táblázatban tüntettük fel. 1. táblázat kísérleti projektek Ország Anglia Ausztria Franciaország Hollandia Információk az kísérleti projektről http://www.ukenumgroup.org Regisztrációs portált üzemeltet. Kínálnak mobiltelefonos klienst. A kísérleti üzem feltehetőleg 2002-ben indult. Alkalmazás: SIP Internetwork Application: különböző SIP szolgáltatásokat használó szigetek közvetlen összekapcsolása. Közepesen aktív projekt. http://enum.nic.at Számos profit orientált támogató partner részt vesz a kísérletekben. Igen sok dokumentumot és munkaanyagot adtak ki, melyek hasznos információkat tartalmaznak [16]. Windows alapú, csak lekérdezésre szolgáló szoftverek: Kapsch EnumObserver, AOSA, Infonova. Az adatok a Weben keresztül is lekérdezhetők. Rendszeres workshopokat rendeznek. Kísérleti regisztrációs Web szervert üzemeltetnek, melyen keresztül minden ausztriai felhasználó regisztrálhat. 2001. júliusa óta működő, igen aktív projekt. http://www.numerobis.prd.fr Átgondolt projektszervezetet és projekttervet találhatunk a fenti Web-címen. Rendszeres workshopokat szerveznek. Kliensek, szolgáltatások: WHOIS rendszer integrációja web kliens. ASP szintű admin. felület (https). Tier2 szintű admin. felület (https). Kereső kliens (Java) az adatok eléréséhez (telefonszám, ország, szolgáltatás, rendezés megadható). kame kliens: Dnssec/IPv6 támogatás. Teljes -DNS architektúra szimulátor. A projekt 2002. májusában indult, igen aktív. http://www.enuminnederland.nl A projekt 2001. júniusában indult de jelenleg nem aktív az oldal.
Ország Lengyelország Németország Svédország Svájc Információk az kísérleti projektről 2002-ben készült egy viszonylag részletes terv az rendszer működésére vonatkozóan [10] azóta nincs frissítés. Megvalósított kliensek nem elérhetőek. Több profit orientált támogatót vontak be. http://www.dns.pl/ Mobiltelefonos (Sony Ericsson P800/900-as telefonon használható) kliens. Elérhető szolgáltatások az általános lekérdezés. Rendszeres rendeznek -hoz kapcsolódó rendezvényeket. A ma is aktív projekt 2002. novemberében indult. http://www.denic.de/de/enum 2002. szeptemberétől működő projekt. Résztvevők száma: 2004-ben 367. Számos munkaanyagot dolgoztak ki: Adminisztratív modellek: felelősségek (feladatok) meghatározására a nyilvántartó (DENIC) és a regisztrátorok között DENIC modell. Hitelesítés, annak ellenőrzésére, hogy az igénylő használatában van-e az a telefonszám, amelyhez kapcsolódó regisztrációját igényli (Portunity GmbH, Deutsche telekom AG.) Számos -ra épülő alkalmazást dolgoztak ki: Lekérdező portal. Institutszentrum Birlinghoven (IZB): VoIP-s szigetek összekapcsolása. T-Systems Nova: ESP SOAP-Connector. Universität des Saarlandes: VoIP szolgáltatás a hallgatóknak (SIPtelefonos kliensek, szoftverkliensek, SIP szigetek összekapcsolása DNS szerverek segítségével) Rendszeres workshopok. A projekt igen aktív. http://enum.autonomica.se klienseket nem tettek közzé Lekérdező portált üzemeltetnek (RIPE Whois Database kereső). A projekt ma is aktív. http://www.ofcom.ch/de/telekommunikation/nummerierung/enum/index.html Számos dokumentumot és munkaanyagot adtak ki. Szerveztek több workshop-ot. Közepesen aktív projekt. VI. ÉRTÉKELÉS A cikkben az eljárást és az eljárásra épülő kommunikációs szolgáltatások megvalósításával kapcsolatos legfontosabb problémákat mutattuk be. Az eljárás megvalósításának technológiai részleteit a vonatkozó technikai ajánlások részletesen taglalják. Az eljárás gyakorlatban történő elterjedéséhez azonban konkrét szolgáltatásokat kell kidolgozni melyek képesek kihasználni az előnyeit, ill. ki kell dolgozni a meglévő szolgáltatások -ra épülő hatékony megvalósításának módszerét. A szolgáltatások megvalósítását célzó projekt kezdeti stádiumban van, azonban az eddigi eredmények alapján látható, hogy a projekt keretében megvalósítandó, -ra épülő hagyományos szolgáltatások között előkelő helyen állnak az IP alapú hang-, ill. képtovábbítási szolgáltatások. Eredeti szolgáltatások kidolgozásakor legfontosabb szempont a szolgáltatás újszerűsége. Az újszerű szolgáltatások megvalósításakor meghatározó tényező, az hogy
az -hoz tartozó DNS bejegyzések nyilvánosak. Mivel a DNS-ben tárolt információ könnyen lekérdezhető, ez azt jelenti, hogy a bejegyzésekben tárolt információ rosszindulatú, ill. nem rendeltetésszerű felhasználása nem akadályozható meg [15]. Ezért vagy csak nyilvánosan más úton is elérhető információ tárolása célszerű, vagy olyan információé, ami csak az adott alkalmazás számára értelmezhető, jellemzően valamilyen módszerrel kódolt. Az szolgáltatás üzleti modelljével kapcsolatos legfontosabb három kérdéskör a díjszabási modellek, a jogi szabályozás, valamint a megtérülés. VII. KÖSZÖNETNYILVÁNÍTÁS A kutatómunkát támogatta az Országos Tudományos Kutatási Alap (OTKA-F046726), valamint a Gazdasági és Közlekedési Minisztérium GVOP-AKF-05-0408.
VIII. IRODALOM [1] ITU-T Recommendation E.164.1: Criteria and procedures for the reservation, assignment and reclamation of E.164 country codes and associated Identification Codes (IC) [2] Service registration for SIP Addresses-of-Record http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-01.txt [3] Service Registration for H.323 URL http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt [4] The "" URI scheme http://www.ietf.org/internet-drafts/draft-brandner--uri-01.txt [5] The tel URI for Telephone Calls http://www.ietf.org/internet-drafts/draft-antti-rfc2806bis-08.txt. [6] ETSI TS 102 172 Services and Protocols for Advanced Networks (SPAN); Minimum requirements for interoperability of European trials [7] ITU-T. Global Implementation of : A Tutorial Paper 2002. [8] Bernardi, Marco: principles and administration aspects, ETNO workshop, 2002. [9] ETSI: Administration in Europe, 2002. [10] Dutch Group (NLEG): in the Netherlands, 2002. [11] Steven Cheung, Department of Computer Science, Universit yof California A Formal-Specification Based Approach for Protecting the Domain Name System [12] Giuseppe Ateniese, Department of Computer Science and JHU Information Security Institute, The Johns Hopkins University, A New Approach to DNS Security (DNSSEC) [13] Hagnell, Staffan, 2 Description of Administrative Routines for and Prestudy fro the Trieal, 2002. [14] Nooren, P.A.: Enum in the Netherlands An operator s view of the currend status and next steps, ETNO workshop, 2002. [15] NetNumber Inc: Securiy Policy and Procedure Overwiew, 2002. [16] Reichinger, Kurt: An update on situation on Austria, ETNO workshop, 2002. [17] Shockey, Richard: is everywhere, Woice on the Net, Atlanta, 2002.