Routing av IP-telefoni med TRIP

Routing av IP-telefoni med TRIP Lars Olsson Per Bergman Lidebrandt Examensarbete Kungliga Tekniska Högskolan - Datateknik Januari 2002 Sammanfattning: Om telefoni över Internet gradvis slår igenom så kommer denna kommunikationsform under längre tid att samexistera med kommunikationen i det traditionella telefonnätet. För att möjliggöra kommunikation mellan dessa två olika nätverk under denna samexistens så används en speciell sorts gateway. Det framtida växande nationella och globala behovet av kommunikation mellan de båda näten förväntas leda till ett stort antal av dessa gateways och ett stort antal gatewayoperatörer. Ett problem som då uppstår är att finna och välja ut en lämplig gateway som kan terminera ett samtal från Internet till det traditionella telefonnätet. Problemet beror i korthet på att alla gateways teoretiskt kan koppla upp till alla telefoner på traditionella telefonnätet. En föreslagen lösning på ovan nämnda problem är TRIP (Telephony Routing over IP). I denna rapport beskriver vi komponenter och funktionalitet i TRIP samt diskuterar och utvärderar TRIP som lösning på gatewayproblemet. Utvärderingen av TRIP sker enligt en för syftet utvecklad utvärderingsmodell. Resultatet av arbetet är att TRIP, med vissa mindre reservationer, kan anses vara väl lämpat som lösning. Rapporten pekar dock på det faktum att TRIP behöver kompletteras av och integreras med andra tekniker och system för att framgångsrikt kunna integreras i en nätverksarkitektur för IPtelefoni. Detta examensarbete motsvarar 20 veckors heltidsarbete för var och en av författarna

IP Telephony routing with TRIP Lars Olsson Per Bergman Lidebrandt Master s Thesis Royal Institute Of Technology Computer Science and Engineering Januari 2002 Abstract: A gradual growth of IP-telephony will result in two co-existing telephony communication networks, the Internet and the traditional global telephony network. Communication between these two different networks is made possible with a special type of gateway. A future growing need for national and global communication between these two networks will most likely require a large number of these gateways and a large number of gateway operators. To find and choose the appropriate gateway to terminate a call from the Internet to the traditional telephony network is a non-trivial problem. In short, the problem originate from the fact that, in theory, all gateways are capable of terminate calls to all telephonys residing on the traditional telephony network. A suggested solution to the problem described above is TRIP (Telephony Routing over IP). This thesis describes components and functionality in TRIP and discusses and evaluates TRIP. In order to evaluate TRIP, a proprietary evaluation model was developed. The thesis concludes, with some minor reservations, that TRIP is well suited as a solution to the problem. However, the thesis points out that to successfully integrate TRIP in a network architecture for IP-telephony, TRIP needs to be complemented by and integrated with other technologies and systems. This thesis corresponds to the effort of 20 full-time working weeks for each of the authors

Förord Detta examensarbete är del av vår civilingenjörsutbildning i Datateknik vid Kungliga Tekniska Högskolan i Stockholm. Arbetet utfördes under perioden juli 2001 - januari 2002. Vi riktar ett stort tack till våra på alla sätt eminenta och alltid hjälpsamma handledare på Telia Research respektive DSV, Carl Wickbom och Johan Kummeneje. III

Innehållsförteckning 1 Inledning...1 1.1 Problemformulering...1 1.2 Syfte...2 1.3 Metod och tillvägagångssätt...4 1.4 Målgrupper...4 1.5 Rapportdisposition...4 2 Telefoni...6 2.1 PSTN...6 2.2 IP-telefoni...7 2.3 IP-telefoni till PSTN...8 3 Att välja gateway...11 3.1 Lösningar på gatewayproblemet... 12 4 Utvärderingsmodell...14 4.1 Komponent 1: Affärsrelationer... 14 4.2 Komponent 2: Leverantörspolicy... 15 4.3 Komponent 3: Kundpolicy... 15 4.4 Komponent 4: Distribution av gatewaykapacitet... 16 4.5 Komponent 5: Protokoll och kompatibilitet... 16 4.6 Komponent 6: Skalbarhet... 17 4.7 Komponent 7: Samverkan med telefoniarkitektur... 17 4.8 Komponent 8: Administration... 18 4.9 Komponent 9: Säkerhet... 18 4.10 Komponent 10: Möjlighet till införskaffning... 19 5 Beskrivning av TRIP...20 5.1 Översikt... 20 5.2 Begreppet ITAD... 23 5.3 Komponenter i TRIP... 23 5.4 Funktionaliteten i TRIP... 29 5.5 Exempel på funktionalitet: utbyte av gatewayinformation... 36 5.6 Exempel på funktionalitet: Samtalsuppkoppling... 44 IV

6 Utvärdering...45 6.1 Diskussion kring lösningsmodeller... 45 6.2 Utvärdering av TRIP... 46 7 Slutsatser och summering...58 7.1 Brister och svårigheter i arbetet... 59 7.2 Framtida arbete... 59 8 Terminologi och definitioner...62 Referenser...64 V

1 INLEDNING 1 Inledning Företag och organisationer engagerade i telefoni, telekommunikation och datakommunikation har börjat utforska nya typer av IP 1 - buren kommunikation för att kunna erbjuda nya, billigare och bättre tjänster. En av dessa nya kommunikationstjänster är IP-telefoni, d.v.s. möjligheten att kommunicera via telefon över ett datornätverk. Det traditionella telefonnätet PSTN (Public Switched Telephony Network) kommer dock under lång tid att fortleva som bärare av större delen av den telefoni som bedrivs runt om i världen, och det är naturligtvis önskvärt att kunna kommunicera mellan dessa två olika typer av nät. Det som möjliggör kommunikationen mellan IP-nätverk och PSTN är gateways. Dessa har till uppgift att konvertera mellan de olika typer av signal- och mediatrafik som bedrivs på respektive nät, och om kommunikationen mellan PSTN och IP-nätverk ska kunna lanseras i kommersiell skala så kommer detta att kräva stor gatewaykapacitet. Det visar sig dock att ett problem uppstår då antalet gateways ökar. Problemet uppstår när ett samtal skall kopplas upp från en telefon på ett IP-nät till en telefon på PSTN-nätet. En gateway kan nämligen normalt koppla upp samtal till alla telefoner på PSTN-nätet. Detta leder till följande för IP-nät unika situation: Alla gateways kan koppla upp samtal till alla PSTN-telefoner. Därmed uppstår problemet: vilken gateway ska väljas? För att uppnå driftsäkerhet och lönsamhet i systemet så kommer trafiken genom dessa gateways dessutom att behöva styras med avseende på bl a belastning, företagspolicys och de avtal om utbyte av gatewaytjänster som träffats mellan leverantörer av IP-telefoni. En sådan styrning kräver information om vilka gateways som finns tillgängliga, och vilka egenskaper dessa gateways har. Ett föreslaget sätt att hantera och distribuera denna information är protokollet TRIP. Detta arbete syftar till att utvärdera TRIP. 1.1 Problemformulering Detta examensarbetes problemställning är att utreda huruvida TRIP är ett lämpligt protokoll för att styra trafiken från IP-telefoner till PSTN. Med lämpligt avser vi olika affärsmässiga och tekniska faktorer. Affärsmässiga faktorer är: Stödjer TRIP affärsmässigt utbyte av gatewayinformation? Hur väl stödjer TRIP hantering av leverantörspolicy gällande den gatewayinformation som ska distribueras? Stödjer TRIP IP-telefonikunders möjligheter att själva välja den gateway som terminerar samtal i PSTN? 1 IP - Internet Protocol 1

1 INLEDNING De tekniska faktorer vi identifierat är Har TRIP stöd för distribuering av information om gatewaykapacitet? Hur väl stödjer TRIP olika signaleringsprotokoll? Är TRIP skalbart? Hur väl samverkar TRIP med omgivande telefoniarkitektur? Har TRIP bra administrationsmöjligheter? Har TRIP stöd för säkerhet? Finns det möjligheter att implementera eller på annat sätt införskaffa en lösning byggd på TRIP? Med dessa faktorer som grund har vi byggt upp en utvärderingsmodell. Motivering till dessa faktorer samt en närmare beskrivning av utvärderingsmodellen återfinns i Kapitel 4. Notera att TRIP avser att lösa de problem som uppstår då samtal skall kopplas upp från IP-nät till PSTN. Följaktligen är även detta arbete begränsat till att diskutera dessa problem. Samtal från PSTN till IP-nät är ett problemområde som ej berörs i denna rapport. 1.2 Syfte Varför utvärdera ett protokoll som TRIP? Vi beskrev i inledningen till detta kapitel hur en kommersiell lansering av IP-telefoni kommer att kräva stor gatewaykapacitet. Följaktligen är behovet av lösningar liknande TRIP beroende av denna förväntade ökning av gatewaykapacitet. Det råder för närvarande stor enighet i data- och telekombranschen om att ett brett genomslag för IP-telefoni kommer att kräva ett stort behov av gatewaykapacitet [1]. Vi identifierar tre faktorer som påverkar ett behov av TRIP: Att IP-telefoni får ett brett genomslag som kommunikationsform. Att genomslaget får en fläckvis geografisk och kulturell spridning. Att detta genomslag sker över en längre tidsperiod. Dessa tre faktorer kommer tillsammans leda till ett stort antal användare av IP-telefoni, av vilka många kommer att ha önskemål att terminera samtal till det parallellt existerande PSTN. 2

1 INLEDNING PSTN IP-telefoni Figur 1 Olika behov av gateways Varför dessa faktorer? Ett brett genomslag ger stora mängder potentiella samtal till PSTN, vilket skulle kunna kräva större gatewaykapacitet. Men ett brett genomslag räcker inte. Vilka ringer vi till egentligen? En stor majoritet av de samtal som privatpersoner och organisationer genomför är till personer och organisationer i deras geografiska och/eller kulturella närhet. Ett alltför brett genomslag av IP-telefoni inom samma geografiska och kulturella områden kommer därmed att leda till att en stor del av samtalen inom dessa områden kommer att ske mellan IP-telefoner. Dessa samtal kräver inget nyttjande av gatewaykapacitet. Genomslaget får ej heller gå för fort. Dessa framväxande öar (se Figur 1) med IP-telefoni måste under en längre tid samexistera med ett omgivande PSTN för att ett krav på stor gatewaykapacitet skall uppstå. Ett alltför snabbt framväxande kommer med stor sannolikhet att leda till att abbonenterna i PSTN övergår till IP-telefoni innan ett behov av stor gatewaykapacitet hinner uppstå. Även ett brett genomslag av sk residential gateways (se Kapitel 2.3.1) kommer att leda till ett betydligt mindre behov av mer storskaliga gatewayarkitekturer. Vi anser att sannolikheten att ovanstående situation inträffar är tillräckligt hög för att motivera en utvärdering av TRIP. 3

1 INLEDNING 1.3 Metod och tillvägagångssätt Detta arbete syftar till att dra slutsatser kring de faktorer som nämns i problemställningen i Kapitel 1.1. För att nå fram till dessa slutsatser skapade vi en utvärderingsmodell uppbyggd kring dessa faktorer. TRIP utvärderades sedan enligt denna modell genom att studera och diskutera TRIPs egenskaper. Även andra angreppssätt på problemet som i korthet beskrivs i Kapitel 1.1 presenteras och diskuteras. Syftet med dessa diskussioner är att påvisa alternativa lösningsmetoder än TRIP och därmed förhoppningsvis vidga läsarens perspektiv en aning. Någon utförligare värdering av en annan lösning än TRIP var ej möjlig, eftersom alternativa konkreta lösningar saknas. Det låg utanför detta arbetes syfte att basera studierna och diskussionerna kring TRIPs egenskaper på egna experiment med TRIP, och det var ej heller möjligt att insamla externa data kring TRIP eftersom vi ej lyckades finna något system byggt kring TRIP i drift. Dessutom är TRIP under kontinuerlig utveckling, vilket i dagsläget gör det mindre meningsfullt att mha experiment försöka utvärdera TRIP. Resultaten från sådana experiment kan ju snabbt visa sig vara inaktuella. 1.4 Målgrupper De tänkta målgrupperna för detta examensarbete är studenter vid tekniska universitet och högskolor med intresse eller inrikting inom tele- och datakommunikation samt personer inom tele- och datakommunikationsbranschen som arbetar med IP-telefoni. 1.5 Rapportdisposition Rapporten är disponerad enligt följande: Kapitel 1: Inledning Kapitel 1 innehåller övergripade information om examensarbetet. Bl a så redogörs för arbetets bakgrund, syfte och problemformulering. Kapitel 2: Telefoni Detta kapitel innehåller grundläggande information om telefoni, IP-telefoni och gateways. Kapttel 2 behöver ej läsas av de som har grundläggande kunskaper inom dessa områden. Kapitel 3: Att välja gateway I detta kapitel definierar vi det problem som motiverat utvecklingen av TRIP. Vi presenterar även ett antal lösningsmodeller för detta problem Kapitel 4: Utvärderingsmodell I detta kapitel presenterar vi den utvärderingsmodell som vi använder för att utvärdera TRIP. 4

1 INLEDNING Kapitel 5: TRIP I Kapitel 5 ger vi en uttömmande beskrivning av komponenter och funktionalitet i TRIP. Detta kapitel behöver ej läsas av de som har djupare kunskap om TRIP. Kapitel 6: Utvärdering I Kapitel 6 diskuterar och utvärderar vi TRIP som lösning enligt den utvärderingsmodell som presenteras i Kapitel 4. Vi diskuterar och värderar även i korthet ett antal andra lösningsmodeller. Kapitel 7: Slutsatser och summering I detta avslutande kapitel ges en övergripande sammanfattning av arbetets resultat. Kapitel 8: Terminologi och definitioner Kapitel 8 innehåller en sammanställning av terminologi och definitioner som används i rapporten. Referenser 5

2 TELEFONI 2 Telefoni I detta kapitel redogör vi kortfattat för grunderna i traditionell telefoni och IP-telefoni. Kapitlet avslutas med en beskrivning av gateways, enheterna som möjliggör kommunikationen mellan IP-nät och PSTN. 2.1 PSTN PSTN är det röstorienterade kretskopplade nät som sammankopplar all världens telefonnät. Idag är det till större delen av PSTN digitaliserat förutom sista biten från telefonväxel till slutanvändare. PSTN utgör även en stor del av Internets infrastruktur [2]. Nedan följer en kort beskrivning av funktionalitet i PSTN. 2.1.1 Funktionalitet Telefonerna hos slutanvändarna i PSTN är kopplade till en telefonväxel via en dedikerad kretskoppling kallad local loop (se Figur 2). I de flesta fall utgörs dessa local loops av koppartråd där röstöverföringen sker med hjälp av analog teknik. Telefonväxlarna är sammankopplade av s.k. trunks. Dessa är till skillnad från local loops delade resurser och här är det vanligare att överföringen sker digitalt, dock inte på samma format som i datanätverk. För att etablera en förbindelse mellan två telefoner signaleras nätverksadressen (destinationens telefonnummer) till nätverket över local loop. Därpå avsätts en trunk i riktning mot denna nätverksadress och telefonväxeln kopplar local loop till denna trunk. Telefonväxeln närmast nätverksadressen kopplar aktuell trunk till local loop för destinationen om linjen inte redan är upptagen. När endera parten lägger på luren frigörs aktuell trunk och den kan då användas av någon annan [3]. telefonväxel local loop trunk local loop telefonväxel Figur 2 Kretskoppling i PSTN 6

2 TELEFONI Att som ovan beskrivet endast ha två parter, sändare och mottagare, som delar på en förbindelse är inte ett effektivt utnyttjande av kapaciteten i nätet. När en person talar utnyttjas endast 50% kapaciteten och när båda är tysta 0%. Detta är en skillnad mot paketförmedlad datakommunikation. Där kan olika användare dela på en linje och utnyttja dess kapacitet till 100%. Man bör kanske poängtera att oavsett om överföringen av talet sker analogt eller digitalt kommer den förbindelse som upprättas för ett samtal fortfarande vara reserverad endast för de två kommunicerande parterna, dvs problemet med kapacitetsutnyttjandet kvarstår. 2.1.2 Signalering i PSTN Signalering innebär enkelt beskrivet att koppla upp och avsluta samtal. Fram till mitten av 1970-talet användes samma förbindelse för uppkoppling av samtal som för själva samtalet. Om förbindelsen utgjordes av flera successiva deluppkopplingar och mottagaren svarade med upptaget-signal så innebar det att alla deluppkopplingar gjorts i onödan, vilket även ledde till att kapaciteten i nätet hade låsts i onödan. Detta problem löstes sedan med SS7-nätverket (Signaling System 7), som är ett separat paketförmedlat nätverk upprättat för att sköta uppkopplingen. SS7 allokerar inte förbindelser för samtal innan uppkopplingen är klar [4]. 2.2 IP-telefoni Vi definierar IP-telefoni på följande sätt: IP-telefoni är möjligheten att på samma sätt som över PSTN utföra telefonsamtal, röstmeddelanden och sända faxmeddelanden över IP-baserade datanätverk [5]. 2.2.1 Funktionalitet Till skillnad från kretskopplad telefoni i PSTN, där en fast förbindelse mellan samtalsparterna upprättas, är telefoni över ett IP-baserat nätverk liksom all annan trafik på denna typ av nätverk paketförmedlat. När tal ska skickas så konverteras den analoga röstsignalen till digitalt format samt komprimeras och översätts till paketformat i form av RTP (Real-Time Transport Protocol) paket. Dessa paket skickas sedan godtycklig väg över IP-nätverket, och när paketen når mottagaren (t ex en annan IP-telefon eller en gateway) så reverseras konverteringsprocessen [6]. Innan RTP-paketen kan börjar strömma mellan de två ändpunkterna så måste dock en förbindelse - precis som i PSTN - på något sätt etableras mellan dessa, och detta utförs med en speciell typ av signaleringsprotokoll. Efter att ha etablerat förbindelsen mellan ändpunkterna så behåller signaleringsprotokollet kontrollen över samtalet och ser även till detta avslutas på ett korrekt sätt. Ett exempel på ett sådant kontroll- eller signalprotokoll är SIP (Session Initiation Protocol). 7

2 TELEFONI 2.2.2 Motivation för IP-telefoni PSTN med dess komponenter och arkitektur är en naturlig del av det vardagliga livet i större delar av världen och ger tillgång till ett billigt och redan existerande världsomspännande nät med vars hjälp man kan kommunicera med vem som helst både billigt, enkelt och med hög kvalitet. Vidare så anses även det globala telefonnätet vara mycket stabilt och på de flesta sätt väl fungerande, men trots alla dessa positiva egenskaper har många aktörer på senare år visat allt större intresse för att använda de snabbt framväxande datanäten som transportnät för röstkommunikation [7]. Anledningar till det är [8], [9]: För kunderna kan IP-telefoni förhoppningsvis erbjuda nya typer av röst- och datatjänster samt lägre kostnader för telefoni. För leverantörer av kommunikationstjänster och kommunikationsutrustning innebär IP-telefoni nya möjligheter att utveckla nya konkurrenskraftiga produkter och tjänster till lägre pris. Mängden datatrafik växer i dagsläget betydligt snabbare än mängden traditionell telefontrafik och stora investeringar i datanätverk görs för att denna ökning skall kunna tillgodoses. För att erhålla största möjliga utbyte av investeringarna så bör dessa datanät utnyttjas maximalt, t ex genom att använda dessa för transport av IP-telefoni. Man hoppas att endast ett globalt IP-nätverk i framtiden skall vara värd för alla typer av trafik, eftersom ett nät i stället för två parallella anses ge stora fördelar bl a i fråga om drift och underhåll. 2.3 IP-telefoni till PSTN Telefoni mellan två IP-telefoner över ett datanätverk är ett exempel på IP-telefoni, men naturligtvis är det även önskvärt och nödvändigt att kunna kommunicera mellan IP-nät och PSTN. Det som möjliggör denna kommunikation är en speciell typ av gateway, och här följer en kort beskrivning av dess komponenter och funktionalitet. 8

2 TELEFONI 2.3.1 Gateways En gateway för kommunikation mellan IP-nät och PSTN har två huvudfunktioner: Uppkoppling av samtal och konvertering av signaltrafik mellan IP-nät och PSTN. Konvertering av mediaströmmen (tal, fax eller annat) åt båda hållen. Det finns flera olika varianter av implementationer av denna funktionalitet. De bygger på tre grundkomponenter (se Figur 3): Signaling Gateway (SG) för uppkopplingen och signalkonvertering Media Gateway (MG) för mediekonverteringen (t ex konvertering av tal) Media Gateway Controller (MGC) för styrning av MG Gateway SIP eller H.323 Signaling Gateway SS7 eller PRI Internet Media Gateway Controller PSTN media paket Media Gateway media krets Figur 3 Beståndsdelar i en typisk gateway I en sk smart gateway är SG och MG integrerade i en enhet som klarar all funktionalitet. Om man använder en fristående MG behöver den styras av en MGC. Denna MGC kan i sin vara integrerad med en SG eller så kan den kommunicera med en separat SG. Om enheterna ej är integrerade med varandra finns möjligheter att t ex en SG styr flera MGC och en MGC styr flera MG, vilket kan ge skalfördelar, men det kan också innebära en ohanterlig komplexitet. I regel har gateways med integrerad SG och MG en lägre kapacitet och kan hantera färre samtal än fristående MG som styrs av MGC. Det finns inget som hindrar en användare av flera gateways att blanda dessa tekniker. 9

2 TELEFONI En annan viktig faktor vid val av gatewaytyp är vilket eller vilka typer av signaleringsprotokoll som stödjs. I dagsläget finns två dominerande typer av signaleringsprotokoll definierade, SIP (Session Initiation Protocol) och protokoll i H.323- familjen. En ytterligare gatewayvariant som bör nämnas är av typen residential gateway. Dessa är ofta en sorts telefonadapter kopplad direkt till den enskilda telefonen, dvs varje enskild telefon har en gateway som tjänstgör som konverterare för media- och signaltrafik 10

3 ATT VÄLJA GATEWAY 3 Att välja gateway Om IP-telefoni fortsätter att utvecklas och får ett stort genomslag som kommunikationsmedel så kommer antalet gateways att öka kraftigt. Det ökade kravet på gatewaykapacitet beror på att PSTN under mycket lång tid kommer att samexistera med IP-nätverken och att det då naturligtvis kommer att vara önskvärt och nödvändigt att kunna kommunicera mellan dessa nät (se Figur 4). IP-telefonikunder IP-telefonikunder ITAD 2 Internet ITAD 3 ITAD 1 Gateway PSTN Figur 4 Telefoni från IP-nät till PSTN Flera problem kommer att uppstå då antalet gateways ökar. Ett av dessa problem uppstår när ett samtal skall kopplas upp från en telefon på ett IP-nät till en telefon på PSTN-nätet. Som tidigare beskrivits så kräver denna typ av samtal att trafiken konverteras av en gateway. En gateway kan, precis som en vanlig telefon på PSTN-nätet, normalt nå alla andra telefoner på 11

3 ATT VÄLJA GATEWAY PSTN-nätet. Detta leder till följande för IP-nät unika situation: Vi har ett flertal resurser att välja på vilka alla potentiellt kan utföra samma tjänst åt oss. Man kan definiera det problem som motiverat utvecklingen av TRIP som: Hur kan vi, givet ett telefonnummer som korresponderar mot en telefon på det publika telefonnätet PSTN, få IP-adressen till en lämplig gateway eller internetresurs (vilken kan vidarebefordra oss till en gateway) som kan terminera ett samtal till detta PSTN-nummer? Detta problem kallas i fortsättningen ibland för gatewayproblemet. Denna problemdefinition är ej att förväxla med problemformuleringen för detta examensarbete. Problemformuleringen för detta examensarbete återfinns i Kapitel 1.1. 3.1 Lösningar på gatewayproblemet I detta kapitel ger vi en översiktlig beskrivning av tänkbara lösningar på gatewayproblemet. För att möjliggöra en kategorisering av de tänkbara lösningarna presenterar vi den lösningsrymd som illustreras av Figur 5. Statisk Dynamisk Central Distribuerad Figur 5 En lösningsrymd för gatewayproblemet Förklaring av de olika axlarna i denna lösningsrymd: Statisk: Förändringar i gatewayarkitekturer leder ej till omedelbar uppdatering av informationen om gateways. Exempelvis så sker uppdateringen av informationen i stället vid regelbundna intervall. Dynamisk: Förändringar i gatewayarkitekturer leder till att informationen om gateways omedelbart uppdateras. Central: All information om gateways administreras av en central resurs. Distribuerad: Aktörerna distribuerar information om gateways direkt till varandra utan inblandning av någon central resurs. 12

3 ATT VÄLJA GATEWAY Här följer ett antal exempel på tänkbara lösningsmodeller i den presenterade lösningsrymden. Syftet med beskrivningarna är att ge en översiktlig bild av olika tänkbara lösningar på gatewayproblemet. Avsikten med dessa beskrivningar är ej att presentera någon form av utvärderingsmodell eller del av utvärderingsmodell för de olika lösningsmodellerna. En detaljerad utvärderingsmodell för lösningar på gatewayproblemet återfinns i Kapitel 4. Central statisk modell Denna lösningsmodell bygger på att det finns en central resurs som håller all information om de gateways som användarna av systemet önskar göra tillgängliga för omvärlden. Informationen lagras statiskt, dvs det finns ingen automatisk uppdatering av informationen utan en operatör måste aktivt ändra konfigurationen varje gång en deltagare i systemet rapporterar in en förändring i sin lokala konfiguration. Central dynamisk modell En central dynamisk modell syftar till att lösa gatewayproblemet genom upprättandet av en central resurs. Uppdateringen av den centrala informationen sker med automatik genom inkrementella uppdateringar in till den centrala enheten. Dessa dynamiska uppdateringar genereras av användarna vid förändringar i deras lokala konfigurationer och skickas därefter till det centrala systemet. Distribuerad statisk modell En distribuerad statisk lösningsmodell bygger på att informationen utbyts direkt mellan aktörerna utan inblandning av en central resurs. Individuella aktörer konfigurerar alltså själva sina system för att distribuera rätt information till rätt motpart/kund med beaktande av ingångna affärsavtal och policypreferenser, och en aktör som vill ha tillgång till extern gatewayinformation abonnerar på informationen från andra utvalda aktörer i systemet. Distribuerad dynamisk modell Denna typ av lösningsmodell liknar föregående modell men här tillkommer att uppdateringen och utbytet av information mellan aktörerna sker inkrementellt och automatiskt vid förändringar i aktörernas lokala gatewayarkitekturer. Aktörerna får i denna modell snabbt reda på förändringar i omgivningens gatewaykonfigurationer. TRIP är ett exempel på en distribuerad dynamisk modell. De tre första lösningsmodellernas egenskaper diskuteras i korthet i Kapitel 6. I Kapitel 6 återfinns även en detaljerad utvärdering av den distribuerade dynamiska lösningen TRIP, som i dag är den enda existerande konkreta lösningen på gatewayproblemet. 13

4 UTVÄRDERINGSMODELL 4 Utvärderingsmodell I detta kapitel presenterar vi en utvärderingsmodell för lösningar på gatewayproblemet. Komponenterna som ingår i modellen baseras på främst på diskussioner i [10] och [1]. För att underlätta utvärderingen har varje komponent uppdelats i delkomponenter. En utvärdering av TRIP enligt denna utvärderingsmodell återfinns i Kapitel 6. 4.1 Komponent 1: Affärsrelationer Bakgrund: Anskaffande och drift av gateways medför kostnader för ägaren, som därmed kommer att betrakta nyttjande av dessa gateways som en värdefull tjänst. Tillgång till gatewaykapacitet kommer därför att behöva regleras genom olika typer av affärsavtal. K1.1: Möjlighet för leverantörer att upprätta autonoma affärsrelationer Motivation: Upprättande av affärsrelationer underlättas om endast de parter som vill göra affär med varandra behöver engageras. K1.2: Stöd för upprättande av olika typer av affärsrelationer Motivation: Affärsmöjligheterna ökar om olika typer av affärsrelationer kan upprättas. Det ger utrymme för både större och mindre aktörer som kan anta olika roller, t ex mäklare av gatewayinformation eller gatewaygrossister. K1.3: Möjlighet att informera affärspartners om förändringar i gatawayarkitektur Motivation: För att en leverantör ska kunna leverera den gatewaykapacitet som avtalats bör leverantören snabbt kunna uppdatera sina kunder när gatewaykapaciteten eller gatewayarkitekturen av olika anledningar ändras 14

4 UTVÄRDERINGSMODELL 4.2 Komponent 2: Leverantörspolicy Bakgrund: Leverantörer av IP-telefoni kommer i många fall, genom olika affärsavtal med andra leverantörer, ha tillgång till ett antal kandidatgateways utöver de egna vilka alla kan terminera ett samtal till ett visst PSTN-nummer eller nummerområde. Leverantörerna kommer av ekonomiska och politiska skäl att vilja styra trafiken till dessa gateways med någon form av regler, dvs mha en policy [10]. Dessa regler måste på något sätt tillåtas påverka distributionsoch urvalsprocessen av gateways. Ett viktigt delproblem är hur dessa policyregler ska administreras. K2.1: Stöd för leverantörer att bedriva policybaserat urval av gateways Motivation: Detta ger leverantörer möjlighet att styra trafiken till av ekonomiska och politiska skäl lämpliga gateways. Ett exempel på politik skulle kunna vara att det amerikanska försvarshögkvarteret Pentagon ej vill använda gateways som Irak har kontroll över. K2.2: Möjlighet att administrer a och automatisera urvalet av gateways Motivation: Rent allmänt kommer ett system att skala bättre och kräva mindre administration om så många processer som möjligt är automatiserade. 4.3 Komponent 3: Kundpolicy Bakgrund: Med kundpolicy avser vi möjligheten att en slutanvändare kan påverka valet av gateway utifrån egna preferenser genom olika typer av abonnemang eller direkt vid uppringningstillfället. K3.1: Möjlighet för kund att aktivt välja gateway vid uppringningstillfället Motivation: Detta ger kunden möjlighet att välja olika gateways för olika samtal vid olika tidpunkter. Kunden kan t ex ha olika krav på samtalskvalité beroende på samtalets natur, och kunden ges även möjlighet att aktivt välja olika leverantörer beroende på aktuell prisbild. Kunden kan även av politiska skäl ha önskemål om att det aktuella samtalet ej skall löpa genom vissa leverantörer. K3.2: Möjlighet för leverantören att välja gateway vid uppringningstillfället beroende på aktuell kundprofil Motivation: Detta ger leverantörerna möjlighet att erbjuda kunderna olika typer av telefoniavtal där olika kunder använder olika gateways för samma nummerområden, och ger även kunderna viss möjlighet att aktivt påverka valet av gateway. 15

4 UTVÄRDERINGSMODELL 4.4 Komponent 4: Distribution av gatewaykapacitet Bakgrund: Kapaciteten är olika för olika gateways och kapaciteten är ej heller statisk, då den bl a påverkas av aktuell belastning. Vid val av gateway bör det finnas tillgång till aktuella uppgifter om gatewaykapacitet, dels som en garanti för samtalskvalité och tillgänglighet, och dels som ett medel för lastbalansering mellan gateways. Därmed måste sådan information och även information om andra viktiga attribut på något sätt ges möjlighet att kontinuerligt uppdateras. K4.1: Möjlighet för leverantörer att på ett standardiserat format utbyta information avseende gateways och tillhörande PSTN-nummerområden. Motivation: Genom att ha ett standardiserat format för informationsutbyte underlättas möjligheten att automatisera och standardisera informationsutbytet och uppslagning av informationen. K4.2: Stöd för olika typer av attribut för att beskriva en gateways egenskaper. Motivation: En viktig faktor vid val av gateway för en viss destination är de olika egenskaper denna gateway har. Är exempelvis en gateway maximalt belastad (inga fler samtal kan termineras) skulle detta vara en mycket nyttig information att få reda på. Då ges en möjliget att välja eventuellt mindre belastad gateway och därigenom ökar sannolikheten att samtalsuppkopplingen mot PSTN lyckas. Det blir också lättare för leverantörerna att hålla utlovad samtalskvalité om det finns tillgång till information som beskriver en gateways aktuella status. K4.3: Stöd för att automatiskt införa och övervaka gateways i en leverantörs lokala gatewayarkitektur. Motivation: En lösning kommer att skala bättre och kräva mindre administration om så många processer som möjligt är automatiserade. Ju mer frekventa uppdateringar av aktuell gatewaystatus som görs i en lokal gatewayarkitektur, desto större behov av automatisering. 4.5 Komponent 5: Protokoll och kompatibilitet Bakgrund: Det är inte säkert att alla gateways stödjer det signaleringsprotokoll som uppringande part använder. Därför måste stöd finnas för att hantera olika signaleringsprotokoll och det måste vara möjligt att distribuera information om detta. Detta ger möjlighet att kontrollera att aktuell TRIP-rutt stödjer det samtal vi önskar terminera. K5.1: Möjlighet för leverantörer att på ett standardiserat format utbyta och avläsa information som beskriver vilket eller vilka signalprotokoll en gateway kan hantera. Motivation: Detta ger leverantörer möjlighet att välja ut gateways som stödjer de signalprotokoll som leverantörens kunder önskar använda. 16