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

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)

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)

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

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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”

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å

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

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 emma@sipserver.domain.com 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

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

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.

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)

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

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

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

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

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

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

Protoypen: Lösning 1 Klienten gör statistikinsamling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Resultat av mätning Fördröjning

Resultat av mätning Fördröjning

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

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

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

Resultat av mätning Fördröjningsvariation

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

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

Resultat av mätning Genomströmning

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

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

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

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

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

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

Frågor?