Övervakning av kvalitet för SIP-baserad kommunikation

En presentation över ämnet: "Övervakning av kvalitet för SIP-baserad kommunikation"— Presentationens avskrift:

1 Övervakning av kvalitet för SIP-baserad kommunikation
Magisterarbete i Datornätverk gjort på KTH Syd av Emma Roos Handledare: Thomas Lindh

2 Projektbeskrivning Konfigurera en flödesmätare med information från SIP-signaleringen Mäta en multimediasessions datatrafik med flödesmätaren Delar i examensjobbet: Konfigurering av SIP-server och klienter SIP-laboration Undersökning av flödesmätaren NeTraMet Utveckling av prototyp Testning av prototyp Utgångspunkt: En operatör har en SIP-server som används av deras kunder för att koppla upp IP-telefonisamtal och ev. annan realtidstrafik som använder SIP. Målsättning: Hitta en metod som mha av SIP-meddelanderna som skickas vid upp- och nerkoppling av ett samtal konfigurerar en flödesmätare för att mäta samtalets kvalitet. Delar: (se bild)

3 IP-telefoni Telefoni över datornätverk
Varför IP-telefoni i stället för vanlig telefoni? Finns två standarder/inriktningar IETF (SIP, RTP) ITU-T (H.232) Blivit vanligare med att ”ringa” telefonsamtal över datornätverk, sk IP-telefoni Varför? Lätt att integrera tal, video och data Lättare att skapa nya funktioner Ses som billigare (framförallt för att bara ett nätverk (datornätverket) behövs och inte två (data och ett telefonnätverk) Samma adress var man än är i världen Två standarder IETF med SIP (Internetvärlden) och RTP och ITU-T med H.232 (Telekomvärlden)

4 SIP – Session Initiation Protocol
Signaleringsprotokoll på applikationsnivå Transportprotokoll: UDP eller TCP Hanterar signalering mellan klient och server Koppla upp och ner mediasessioner Informera om ändringar i en existerande mediasession SIP Klient kallas ”User Agent” (UA) Klientdel UAC Serverdel UAS Transportprotokoll: UDP används för det mesta. Minst en måste implementeras i en SIP-klient UAC initierar förfrågningar UAS genererar svar på förfrågningar

5 SIP – Session Initiation Protocol
Meddelandetyper i SIP: Metoder (INVITE, BYE m.fl.) Svarskoder (180 Ringing, 200 OK m.fl.) Ett SIP-meddelande består av: SIP-huvud Eventuell datadel skriven i SDP (Session Description Protocol) Metoder genereras av UAC medan svarskoder genereras av UAS SIP-huvudet Information om meddelandets typ Adresser till de som medverkar i samtalet Vilken transaktion och dialog meddelandet tillhör Annan administrativ information Datadelen: * Information datatrafiken såsom RTP-port, kodeks m.m.

6 SIP – Session Initiation Protocol
UAS UAC INVITE 100 Trying INVITE -transaktion 180 Ringing 200 OK Dialog ACK Visar utbytet av SIP-meddelanden för ett samtal. Hela utbytet kallas en dialog, denna består av olika transaktioner BYE BYE -transaktion 200 OK

7 SIP – Session Initiation Protocol SIP-servrar
Tar emot SIP förfrågningar och svarar på dessa SIP-servertyper Proxy Omdirigering Registrering Finns olika typer av SIP-servrar, dessa tar emot SIP-förfrågningar och svarar eller vidarebefodrar dessa. Typer: Proxy, Omdirigering och Registrering Proxy: tar emot meddelanden och vidarebefodrar dessa till den klient som är mottagaren eller till en annan proxy på vägen till mottagaren Omdirigering: Skickar tillbaka information om var en mottagare kan nås Registrering: Tar emot registreringar från klienter i en administrativ domän samt informerar andra servrar i denna domän om de existerande klienterna De olika serversorterna kan kombineras i samma programvara och finnas på samma dator

8 RTP – Real-time Transport Protocol
Används av datatrafiken i en mediasession Klarar av flera mediatyper Transportprotokoll: UDP Har ingen QoS RTP-port, kodeks etc. definieras i SIP-signaleringen RTP är protokollet som används för att skicka en mediasessions datatrafik Den klarar av flera mediatyper såsom: audio, video och data Använder UDP Ev. QoS hanteras av underliggande protokoll eller i ändpunkterna Vad för port, kodeks etc som ska användas definieras under uppkopplingsfasen av mediasessionen i SIP-meddelanderna

9 SER – SIP Express Router
SIP-serverprogramvara utvecklad av iptel.org Klarar av alla tre servertyperna Uppbyggnad: Enkla grundfunktioner Kan byggas ut med hjälp av moduler Konfigureras med C-liknande skriptspråk Verktyg: serweb serctl Den SIP-serverprogramvara jag använde under projeketet heter SIP Express Router Denna är utvecklad av iptel.org som är en portal som finns för att lansera VoIP-teknologier Klarar av alla tre servertyperna: Proxy, Omdirigering och Registrering Uppbyggnad: Programmet har enkla grundfunktioner och en stor del av funktionaliteten konfigureras i SER-serverns konfigureringsfil med ett C-liknande skriptspråk. Det finns också ett antal moduler som kan laddas in som ger extra funktionalitet. Verktyg: serweb är ett webbinterface som används i huvudsak till att administrera användare Serctl är ett program som körs vid kommandoraden och som hanterar de mest grundläggande administrativa uppgifterna samt att övervaka serverns status

10 Trafikmätningar Varför? Vad mäts vanligtvis? Se hur ett nätverk mår
Se om nätverket behöver uppgraderas Se om Service Level Agreement följs Vad mäts vanligtvis? Fördröjning (envägs och tur-och-retur) Fördröjningsvariation (jitter) Paketförluster Genomströmning Blivit mycket vanligare att nätverk används och för mera kvalitetskrävande trafik som realtidstrafik. Därför behöver operatörer mfl ha ett sätt att ta reda på hur nätverket mår och om det behöver uppgraderas. Det finns också ibland överrenskommelser mellan operatören och kunden som specificerar hur mycket trafik kunden får utnyttja och vilken kvalitet operatören ska erbjuda. Detta kallas Service Level Agreements Mätparametrar: Fördröjning: * Tiden det tar för paketen att komma fram till sin destination och för t-o-r tiden det tar för paketet att komma fram och ett svar på detta paket att skickas tillbaka. * Fördröjning ska vara så lågt som möjligt. Skapas: Processeringstid i nätverksutrustning, kodning och kompressionsalgoritmer Fördröjningsvariationer eller jitter: Variationen på paketens fördröjning Mycket jitter – inte bra för realtidstrafik eftersom ger ojämn ström Lösning: Jitterbuffrar (och förstora dessa) Paketförluster: Inträffar när paketbuffrar i nätverksutrustningen flödar över Lite paketförluster inget problem men mer än 1% ska det inte vara Genomströmning: Hur mycket data som går genom nätverket under en viss tid

11 Trafikmätningar Två typer av mätmetoder Dessa typer kan kombineras
Passiva Aktiva Dessa typer kan kombineras Aktivt: Fördröjningar och fördröjningsvariation Passivt: Paketförluster och genomströmning Passiva: Trafik info samlas in av nätverksutrustning, användare och servrar Mäter befintlig trafik Nackdelar: Mycket utrymme för att lagra statistik behövs, vid hög trafik kan tex nätverkskortet kanske inte hinna med Aktiva: Trafik genereras för mätsyfte och mäts Trafiken som genereras ska helst vara av samma typ som den ordinarie trafiken (pga bla prioriteter i nätverket) Metoder: Generera så mycket trafik som möjligt under kortare period – tex för att se hur mycket trafik nätverket klarar av innan kvaliteten påverkas Generera mindre trafikström hela tiden – bra om man vill ha larm vid överbelastning eller kontrollera SLA Fördelar: Lätt att implementera, Flexibla metoder och inte lika hög kapacitet behövs Nackdelar: Snäva resultat vid felkonfigurering av paketsorter som skickas, överbelastning och vid fel i nätet. Monitoreringspaket kan påverka resultatet om många paket skickas. Kombinering: Vissa mätparametrar passar inte vissa mätmetoder. (se bild) Man kan även använda sig av den aktiva metodens monitoreringspaket för att mäta paketförluster per övervakningsblock

12 Ethereal Passivt mätverktyg Protokollanalysator Använder sig av:
libpcap i Linux Winpcap i Windows Ethereal användes i SIP-laborationsdelen av projektet. Hämtar in information om de paket som går på nätverket och avkodar dessa så att man kan analysera trafiken och paketen.

13 Flödesmätaren NeTraMet
Passivt mätverktyg Mäter trafikflöden mellan två ändpunkter i ett nätverk Tre adressattribut definierar ett flöde: ”Adjacent” ”Peer” ”Transport” Flödena definieras med regler Reglerna skrivs i SRL - Simple Ruleset Language Datastrukturen definierad med SNMP MIBar Adressattribut: Adjacent: MAC-adress Peer: IP-adress Transport: TCP, UDP etc och port Kan definieras för både sändare och mottagare Man kan använda vilket SNMP program som helt för att hämta info om flöderna men för det mesta använder man manager programmet NeMaC

14 Flödesmätaren NeTraMet
Programmet NeMaC Administrerar NeTraMet instanser Hämtar data från de noder som kör NeTraMet Information som NeTraMet sparar: Id-nummer för flödet Typ av flöde Sändar- och destinationsadresser Antal paket och bytes som skickats och kommit in NeMaC startas från kommandofönster, och programmets inställningar sätts med flaggor eller i en konfig fil. Rulesfilen definieras där också. Typ av flöde: UDP, TCP etc

15 Flödesmätaren NeTraMet OAM-version
OAM – Operations Administration and Maintenance Kombinerar passiv och aktiv mätning Använder monitoreringspaket (OAM-paket) En grupp flöden kopplas till ett flöde med OAM-paket Gruppen identifieras med ett grupp-id Extra information som sparas: Tidstämpel när ett OAM-paket kommer in Antal OAM-paket som skickats sen förra hämtningen av NeMaC

16 SIP-laboration Mål: Få en översikt hur SIP fungerar Se vilken signaleringsinformation som kan användas vid kvalitetsövervakning Hur ska signaleringsinformationen tas tillvara Koppla upp samtal mellan två klienter via en SIP-server Spela in SIP- och RTP-trafiken som utväxlas

17 SIP-laboration: Upplägg
SIP Server Operativsystem: Fedora Core 2 SIP-serverprogamvara: SIP Express Router (SER) SIP Klienter Operativsystem: Fedora Core 2 och Windows XP Professional SIP-klientprogramvara: Linphone och Kphone (plus X-Lite, Windows Messenger 5.1 och SJ Phone). Trafiken spelades in och analyserades i Ethereal

18 SIP-laboration: Trafikfall
Registrering av klient med SIP-servern Samtal mellan två parter Samtal som ej besvaras Uppringande part lägger på Uppringd är upptagen eller avbryter (genom aktivt beslut) Uppringd gör ingenting Försök att ringa part som ej är registrerad med SIP-servern Samtal där någon av parterna pausar samtalet Tredje part ringer upp någon som redan är i samtal Andra scenarion och inställningar

19 SIP-laboration: Trafikfall Samtal mellan två parter
Klient B SIP-proxy INVITE 100 Trying 180 Ringing 200 OK ACK RTP Trafik (går ej genom proxy) BYE A ringer upp B B svarar Klient A Samtalet avslutas Klient B SIP-proxy INVITE 100 Trying 180 Ringing 200 OK ACK RTP Trafik (går ej genom proxy) BYE A ringer upp B B svarar Klient A Samtalet avslutas Med ”record route” Utan ”record route”

20 SIP-laboration: Trafikfall Samtal som ej besvaras
Klient A Klient B SIP-Proxy INVITE 100 Trying 180 Ringing A ringer upp B CANCEL 200 Canceling 200 OK 487 Request Terminated ACK Uppringningsförsöket avbryts av uppringaren A Uppringaren lägger på

21 SIP-laboration: Trafikfall Samtal som ej besvaras
Klient A SIP-Proxy Klient B INVITE Klient A SIP-Proxy Klient B INVITE INVITE 100 Trying INVITE 100 Trying A ringer upp B 100 Trying 100 Trying A ringer upp B 180 Ringing 180 Ringing 180 Ringing Proxy-timeouttid (tex 120s) 180 Ringing 486 Busy Here/603 Decline 408 Request Timeout CANCEL 486 Busy Here/603 Decline ACK Uppringsninsförsöket avbryts av mottagaren, B. ACK 487 Request Terminated Uppringsninsförsöket avbryts av proxyn efter em viss tid ACK 200 OK ACK Uppringd är upptagen eller avbryter genom aktivt beslut Uppringd gör ingenting

22 SIP-laboration: Information i signaleringmeddelandena
Användare (”From”- och ”To”-raderna) Klientadresser (”Contact”-raden) Call-ID CSeq Media information i SDP-datadelen Mediatyp Protokoll Format (kodek) RTP-port Användare: Deras SIP-URL tex Klientadresser: Var användaren sitter fysiskt. Info om IP-adress Call-ID: Unikt idnummer för samtalet. CSeq: Information om vilken transaktion meddelandet tillhör Mediainfo: typ – audio, video, data etc, protokoll: RTP, format: info om kodeks som kan användas (tex GSM-kodning), porten RTP trafiken kommer att använda

23 SIP-laboration: Parametrar som kan användas vid kvalitetsmätning
Uppkopplingsstatistik Misslyckade/avbrutna försök att starta upp ett samtal Samtalsspärr Upptagen mottagare Mottagaren svarar ej Uppringaren lagt på luren innan svar Mottagare temporärt oåtkomlig Ej registrerad mottagare Uppkopplingstid Uppkopplingsstatistik: Räkna hur många samtal som försökts kopplas upp etc. Tex genom att se hur många unika INVITE som skickats Misslyckade: Genom att titta på de svarsmeddelanden som skickas Spärr: 4xx och 5xx Upptagen: 486 Busy Here och 603 Declined Svarar ej: 408 Request Timeout, Cancel-session Uppringaren lagt på luren: 487 Request Terminated Temporärt: 480 Temporaily Unavailble, 302 Moved Temporarily, 380 Alternate Service Ej reggad: 404 Not Found Uppkopplingstid: Subtrahera tiden för BYE-meddelandet med tiden för INVITE-trans. ACK. Eller titta på RTP-paketens tidsstämplar. Inget av detta finns i prototypen men kan ganska enkelt läggas till genom att använda räknare och variabler

24 Undersökning av NeTraMet
Första test: SRL-skript från annat examensarbete Både datatrafiken och OAM-paket genererades med ping Första omskrivning av SRL-skript Datatrafiken av typ UDP Både sändar- och mottagaradresser och portar definierades Andra omskrivningen av SRL-skriptet Även OAM-paketen av typ UDP Bara sändarens adress och portar definierats Första test: Gjordes för att se att installationen av NeTraMet fungerade. Men ändringar måste göras eftersom ICMP-trafik kan vara nerprioriterat och RTP använder UDP. Första omskrivning: Satte datatrafiken till UDP men inte monitoreringspaketen eftersom ingen metod för detta tagits fram än. Sändarens och mottagarens IP-adresser och portar definierades i skriptet. Portarna var för både data och monitoreringstrafiken. Andra omskrivning: Efter undersökning hur man genererar UDP paket som monitoreringspaket så ändrades typen för dessa till UDP i skriptet. Mottagarens adress och portar togs bort eftersom sändarens var det ända som behövdes. Detta eftersom sändarens portar var unika för mediasessionen och moniotoreringspaketens flöden.

25 Generering av OAM-paket
OAM-paket behöver vara: Ha UDP som transportprotokoll Ha samma storlek som datapaketen Varför? RTP kör UDP med en viss storlek på paketen Eventuella olika prioriteter i nätverket Tre metoder att generera OAM-paket testades: UDP Ping logger Perl-skript NTools paketgenerator ngen En undersökning gjordes för att hitta en bra metod att generera OAM-paket som använder UDP. För att få en möjlighet till RTT så behövdes en lösning där mottagaren svarade på OAM-paketet och skickade ett svar. (se bild)

26 Generering av OAM-paket
UDP Ping Logger Nerdlabs Consulting Skickar ett UDP-paket i sekunden Går ej att definiera hur ofta paketen ska skickas eller hur stora de ska vara Perl-skript Använder Net::Ping och Time::HiRes Går inte att definiera vilken port paketen ska sändas från

27 Generering av OAM-paket NTools paketgenerator – ngen
Norbert Vegh på TeliaSonera AB R & B Kan generera både UDP- och TCP-strömmar Går att definiera: Hur stora paketen ska vara Hur ofta de ska skickas Vilken port de ska skickas från och mot Detta var lösningen som användes Paketstorlek: 200 bytes för hela (160 bytes utan Ethernet header) Port mot: 7

28 Undersökning av NeTraMet (igen) Testning av SRL-skript
Samtal mellan två SIP-klienter sattes upp RTP-portarna definierades i SIP-klientprogramvaran OAM-paketen genererades med ngen Hastighet 1 paket per 10:e sekund Mottagardatorns port: echo-porten (7) Första test NeTraMet bara på sändardatorn En instans av NeMaC Andra test NeTraMet på båda datorerna Två NeMaC instanser på sändardatorn Ena NeMaC hämtade från klient A den andra från klient B

29 Utveckling av prototyp: SIP-information för konfigurering av trafikmätningen
Typ av SIP-meddelande Metod såsom INVITE, BYE etc eller Svarskod tex 180 Ringing, 200 OK etc Klienternas IP-adresser Sändaren: Contact-raden i INVITE-meddelandet Mottagaren: Contact-raden i 180 Ringing meddelandet Samtalets Call-ID Från INVITE-meddelandet Sändarens RTP-port Från SDP-data i INVITE-meddelandet

30 Utveckling av prototyp: Prototypens funktion
Prototypen ska: Se att ett samtal håller på att kopplas upp Hämta nödvändig information från signaleringen Skapa SRL-filen och kompilera den Starta två instanser av NeMaC Starta UDP-generatorn Stoppa mätningen när samtalet kopplas ner

31 Utveckling av prototyp: Prototypens uppbyggnad
Skriven i Perl Använder sig av modulerna: Net::PcapUtils NetPacket Finns i två varianter där: Klienten gör statistikinsamlandet SIP-servern gör statistikinsamlandet

32 Protoypen: Lösning 1 Klienten gör statistikinsamling

33 Protoypen: Lösning 1 Perlskriptets delar
Importering av Perlmoduler Definiering av globala variabler Subrutinen createconfig() Subrutinen siphandler() Subrutinen get_callid() Subrutinen got_a_packet() Huvudprogrammet

34 Protoypen: Lösning 1 Huvudprogrammet och subrutinen got_a_packet()
Öppnar upp nätverkskortet för insamlande av UDP-paket Om ett UDP-paket så skickas detta till got_a_packet() Subrutinen got_a_packet Kontrollerar om ett paket är ett SIP-paket Om detta är fallet så avkodas paketet Viktig information om SIP-paketet läggs in i variabler

35 Protoypen: Lösning 1 Hämta Gå till siphandler-subrutinen
Nej Ja Start Hämta UDP-paket Är paketet ett SIP-paket? Gå till siphandler-subrutinen

36 Protoypen: Lösning 1 Subrutinen siphandler()
Består av algoritmen som hanterar de inkommande SIP-meddelanderna Startar endast mätningar för samtal från den dator specificerats vid programstart Om mätning ska göras så: Skapas SRL-filen Starta NeMaC och OAM-paketgeneratorn vid samtalets start

37 Hämta och lagra sändarens IP, mediaport och Call-ID
Vänta på relevant SIP-meddelande INVITE Hämta och lagra sändarens IP, mediaport och Call-ID Skapa SRL-filen och kompilera denna CANCEL, 486 Busy Here, 480 Temporarily Unavailable, 603 Declined eller 404 Not Found Vänta på nästa relevanta SIP-meddelande 180 Ringing Hämta destinationens IP Ta bort SRL- och regelfilerna plus rensa satta variabler CANCEL, 486 Busy Here eller 603 Declined Vänta på nästa relevanta SIP-meddelande 200 OK Starta NeMaC-instanser mot sändarens och mottagarens NeTraMet Starta UDP-generatorn mot mottagarens port 7 Mätning pågår BYE Stoppa NeMaC-instanserna och UDP-generatorn

38 Protoypen: Lösning 1 Subrutinerna createconf() och getcallid()
Anropas från subrutinen siphandler() Subrutinen createconf() Skapa SRL-fil med de inställningar som tagits from SIP-meddelanderna Kompilera SRL-filen Subrutinen getcallid() Hämta ett SIP-meddelandes Call-ID

39 Protoypen: Lösning 2 SIP-servern gör statistikinsamling

40 Protoypen: Lösning 2 SIP-servern gör statistikinsamling
Bygger i stor del på lösning 1 ”Record-route” måste vara satt på SIP-servern Två olika skript Klientskript som körs på SIP-klienterna Serverskript som körs på SIP-servern

41 Protoypen: Lösning 2 Klientskriptet
Hämtar vid uppstart av ett samtal som ska mätas Call-ID Mottagarens IP-nummer Startar UDP-generatorn vid samtalets start

42 Hämta och lagra Call-ID
Vänta på relevant SIP-meddelande INVITE Hämta och lagra Call-ID CANCEL, 486 Busy Here, 480 Temporarily Unavailble, 603 Declined eller 404 Not Found Vänta på nästa relevanta SIP-meddelande 180 Ringing Hämta destinationens IP Rensa satta variabler CANCEL, 486 Busy Here eller 603 Declined Vänta på nästa relevanta SIP-meddelande 200 OK Starta UDP-generatorn mot mottagarens port 7 Mätning pågår BYE Stoppa UDP-generatorn

43 Protoypen: Lösning 2 Serverskriptet
En instans per dator, vars trafik ska mätas, körs Hämtar information om klienten som startar samtalet Skapar SRL-fil och kompilerar den Startar NeMaC vid samtalets start

44 Hämta och lagra sändarens IP, mediaporten och Call-ID
Mätning pågår CANCEL, 486 Busy Here eller 603 Declined CANCEL, 486 Busy Here, 480 Temporarily Unavailble, 603 Declined eller 404 Not Found INVITE Hämta och lagra sändarens IP, mediaporten och Call-ID Skapa SRL-filen och kompilera denna Vänta på nästa relevanta SIP-meddelande 180 Ringing Hämta destinationens IP Ta bort SRL- och regelfilerna plus rensa satta variabler Starta NeMaC-instanser mot sändarens och mottagarens NeTraMet 200 OK Stoppa NeMaC-instanserna Vänta på relevant SIP-meddelande BYE

45 Mätning av trafik Mätning för att testa prototypen
IP-telefonisamtal mellan Haninge och Karlskrona

46 Mätning av trafik Samtal initierades från Karlskrona
Samtalstid ca 5 minuter Resultat skrevs i två flödesfiler Fyra tidstämplar per OAM-paket OAM-paket skickades 1 gång i sekunden Två flödes filer: en per NeTraMet-instans

47 Mätning av trafik Information som ficks i flödesfilerna
OAM-paketets ID-värde Tidstämpel Bytes RTP-trafik in och ut från datorn Antal RTP-paket in och ut från datorn

48 Mätning av trafik Parametrar som räknades ut
Fördröjning Round Trip Time (RTT) Processeringstid ”Exakt” RTT” Envägsfördröjning Drift i klockorna (NTP användes) Fördröjningsvariation ITU-T:s definition IETF:s definition Genomströmning per övervakningsblock RTT – Tid från att paketet skickas till att svaret kommit tillbaka Processeringstid – tiden från att det mottagarnoden tar emot OAM-paketet till att svaret skickas ut. Processtiden för paketet i noden Exakt RTT – RTT-Processeringstid Envägsfördröjning – Tittade bara lite på detta eftersom med NTP som synkroniseringssätt så fanns drift i klockorna vilket gjorde att värdena inte var tillförlitliga Fördröjningsvariation: räknades båda definitionerna ut. Dessa beskrivs senare

49 Resultat av mätning Fördröjning
Räknades ut med hjälp av tidstämplar RTT: t4-t1 Processeringstid: t3-t2 ”Exakt” RTT: t4-t1-(t3-t2) Fördröjning Karlskrona -> Haninge: t2-t1 Fördröjning Haninge -> Karlskrona: t4-t3 RTT Processeringstid ”Exakt” RTT Medelvärde 13,56 ms 0,861 ms 12,699 ms Standardavvikelse 1,835 ms 1,732 ms 0,533 ms Maxvärde 23,89 ms 11,179 ms 14,946 ms Minvärde 11,694 ms 0,363 ms 11,266 ms

50 Resultat av mätning Fördröjning

51 Resultat av mätning Fördröjning

52 Resultat av mätning Fördröjning
Bild för att visa att processeringstiden påverkar RTT

53 Resultat av mätning Fördröjning
Mindre spridning på värdena när ”exakt” RTT används Processeringstiden har stor påverkan Port 7 har lägre prioritet Program på datorn som påverkar En idé är att hitta eller utveckla en annan lösning för OAM-paketen Toppen innan huvudtoppen dyker upp från Haninge till Karlskrona

54 Resultat av mätning Fördröjningsvariation
Räknades ut med värdena för ”exakt” RTT ITU-T:s metod d(i)-medel(d) (eller d(i)-min(d)) IETF:s metod d(i)-d(i-1) Fördröjningsvariation, ITU-T Fördröjningsvariation, IETF Medelvärde 0 ms 0,004 ms Standardavvikelse 0,533 ms 0,756 ms Maxvärde 2,248 ms 2,352 ms Minvärde -1,433 ms -2,225 ms

55 Resultat av mätning Fördröjningsvariation

56 Resultat av mätning Fördröjningsvariation
ITU-T:s fördröjningsvariation Samma sannolikhetsfördelning som ”exakt” RTT IETF:s fördröjningvariation Jämnt fördelat runt medelvärdet

57 Resultat av mätning Genomströmning
Genomströmning per övervakningsblock (bytes(i-1,i)*8)/(tid(i)-tid(i-1)) Genomströmning Karlskrona -> Haninge Haninge -> Karlskrona Medelvärde 85,459 kbps 85,598 kbps Standardavvikelse 0,585 kbps 1,258 kbps Maxvärde 87,32 kbps 88,068 kbps Minvärde 82,144 kbps 82,938 kbps

58 Resultat av mätning Genomströmning

59 Resultat av mätning Genomströmning
Jämn genomströmning Beror på att RTP skickar små paket med konstant hastighet Tappas inga eller få paket

60 Resultat av mätning Paketförluster
Ingen eller mycket låga paketförluster Går inte att beräkna tappade paket per övervakningsblock Olika numrering på paket Brist på synkronisering Går att räkna ut totalt tappade paket

61 Diskussion och slutsatser
Serverversionen av prototypen Användas av operatör Record Route måste vara satt Definition av vilka samtal ska mätas Klientversionen av prototypen Eventuellt finna lösning för att: Skicka mätdata till en central lagringsplats eller Hämta mätdata från klienterna Problem med att använda ngen som OAM-paketgenerator Definition av samtal som ska mätas: Slumpmässigt urval – metod måste utvecklas Vissa valda användare Ett specifikt urval av samtal Om klientversion ska användas av operatör så behövs en metod för att skicka mätdata till en central lagringsplats eller kunna hämta den från klienten

62 Diskussion och slutsatser
Problem med tidstämplingens noggrannhet Tidstämpling görs i programmet ej på nätverkskortet Lösning: kompletterande mätningar mellan kantnoder Synkronisering av klockor görs med NTP Påverkar envägsfördröjningar Tur-och-retur fördröjningar troligtvis tillräckligt GPS ingen lösning Extra hårdvara behövs Alternativ metod att mäta trafikkvalitet: RTCP-XR Använder rapporter från RTCP Kan bara mäta RTP-trafik

63 Diskussion och slutsatser Idéer för att förbättra prototypen
Skriva om källkod så: Server- och klientversionerna finns i samma program Andra mediatyper än audio hanteras Information om missade samtal etc. sparas Utveckla program som behandlar och redovisar flödesfilerna Utveckla en bättre metod att generera OAM-paketen Server och klient i samma program: flaggor på kommandoraden

64 Sammanfattning Hämta information från SIP för att: SIP-laboration
Få statistik om samtal Konfigurera mätning med flödesmätare SIP-laboration Undersökning av NeTraMet och hur OAM-paket ska genereras Utveckling av prototyp i Perl Klientversion Serverversion Mätning gjord med prototypen

65 Frågor?