Vertraging

De belangrijkste adder on het gras bij internettelefonie is de gesprekskwaliteit. Vooral vertragingen zorgen voor problemen.

OK, waar zitten nu de adders onder dit zo verleidelijke gras? De dikste adder is ongetwijfeld de vaak belabberde gesprekskwaliteit. En je mag nog zo je best doen om braafjes te articuleren, heel wat technische verwikkelingen kunnen aardig wat stokken in de wielen steken. De grootste spelbreker laat zich alvast samenvatten in het begrip ‘vertraging’. Niet alleen de snelheid waarmee je zelf of je gesprekspartner met de ISP verbonden is, maar ook de capaciteit en de kwaliteit van diens connectie met de internet-backbone speelt mee bij het aantal en de omvang van de gespreksonderbrekingen. Zo mag je op het Net toch rekenen op vertragingen tot wel 500 milliseconden of meer, terwijl dit bij een gesprek via het PSTN meestal zo’n tien keer lager ligt. Als je weet dat vertragingen vanaf 200 à 250 ms merkbaar zijn en een vlot gesprek verstoren, dan weet je meteen ook wat je gewoonlijk van VoIP-gesprekken mag verwachten.

Adres
Heb je het IP-adres van je gesprekspartner te pakken, dan kun je zelf min of meer uittesten wat de gemiddelde vertraging is die je tussen de beide toestellen mag verwachten. Het IP-adres kun je uitvissen door het commando winipcfg in het uitvoervenster in te tikken. In het dialoogvenster kies je vervolgens de correcte Ethernet-adapter en vrijwel onmiddellijk krijg je dan het gewenste adres in het veld ‘IP-adres’ te lezen. Gewapend met dit IP-adres kun je er dan een ping-opdracht op los laten. Dat geeft je de zogenaamde round-trip delay te lezen: de vertraging dus tussen jouw toestel en dat van je correspondent én terug. Wil je van een aanvaardbaar gesprek genieten, dan zal de gemiddelde vertraging dus onder de 400 ms moeten liggen. Nog beter is een visuele tracerouter als Ping Plotter, waar je in één oogopslag een pak nuttige informatie op je scherm krijgt.

Jitter
Zo mogelijk nog kwalijker voor een vlotte stemoverdracht is dat de vertragingstijd tussen de verschillende pakketjes erg kan variëren, een fenomeen dat als jitter door het leven gaat. Zo verwonderlijk is dat overigens niet, als je weet dat de stempakketjes binnen één gesprek niet noodzakelijk allemaal dezelfde route(rs) volgen om tot bij de bestemmeling te geraken. Deze jitter maakt het inplanten van een softwarematige buffer noodzakelijk, waarin de ontvangen pakketjes lang genoeg bewaard worden tot ook de traagste pakketjes binnen zijn om dan in de juiste volgorde te worden afgespeeld. Jammer genoeg zorgt ook zo’n buffer voor alweer wat extra vertraging…

Pakketverlies
In het slechtste geval echter gaat het zelfs niet meer om een vertraagde aankomst van de gedigitaliseerde stempakketjes, maar is er zelfs regelrecht sprake van pakketverlies. Een combinatie van beperkte bandbreedte en overdruk internetverkeer zorgt immers al gauw voor een flinke congestie op het Net waar meer dan één pakketje het leven bij kan inschieten. De ontvangende partij de zender nogmaals om de verloren pakketjes laten vragen — zoals bij het klassieke dataverkeer — biedt hier jammer genoeg geen uitkomst, aangezien dit bij de ontvanger voor extra vertraging tijdens de stemreconstructie zorgt. Eenvoudige applicaties voor internettelefonie vangen dergelijk pakketverlies dan maar simpelweg op door stilte, zodat het lijkt alsof je gesprekspartner heel wat klanken en zelfs halve woorden inslikt. Geen bijzonder fraaie oplossing, als je het mij vraagt.

Verloren klanken
Begint nu stilaan alle hoop op een vlot en betaalbaar gesprek met je Balinese lief te slenken, dan wordt het hoog tijd je vertrouwen weer wat op te krikken. Want oplossingen geraken stilaan geïmplementeerd en situeren zich zowel op softwaregebied als op het vlak van hardware. Zo stoppen programmeurs van VoIP-pakketten allerlei intelligente algoritmes in hun producten om de gevolgen van pakketverlies minder te laten opvallen. Is het pakketverlies minimaal, dan wordt getracht de verloren klanken te interpoleren uit de omgevingsklanken die wel goed zijn terechtgekomen. Een andere tactiek bestaat erin extra informatie aan de gedigitaliseerde stempakketjes te kleven waarmee verloren pakketjes kunnen worden gereconstrueerd (forward error correction). Nadeel van deze techniek is dan weer dat er meer bandbreedte vereist is, wat op zijn beurt weer tot grotere vertragingen kan leiden. Sommige pakketten zoeken in dit geval hun toevlucht tot een iets grotere compressie bij het samenstellen van de stempakketjes (tot zo’n 3 Kbps), zodat op die manier wat bandbreedte wordt gespaard en er meer ruimte vrijkomt voor redundante herstelinformatie.

Het blijft behelpen
Al bij al blijft het toch maar wat behelpen met deze VoIP-technieken. Veel meer heil wordt echter verwacht van de groeiende bandbreedte van het Net en van de installatie van snellere giga-Ethernetverbindingen en gigarouters. Deze laatste kunnen tot wel 20 miljoen pakketjes per seconde verwerken, wat zo’n tien tot twintig keer meer is dan de klassieke routers. Ook kijkt men hoopvol uit naar de algemene implementatie van enkele protocollen die internettelefonie eindelijk een aanvaardbare kwaliteit kunnen garanderen (QoS, quality of service). De bekendste initiatieven zijn ongetwijfeld DiffServ (Differentiated Services) en het RSVP (resource reservation protocol). Het eerste werkt met prioriteitsvlaggen in de IP-headers, terwijl het laatste erop gericht is een zekere bandbreedte en een vaste route te reserveren indien bepaalde real-time internetapplicaties – zoals VoIP – daarom vragen. Routers die dat RSVP-protocol ondersteunen, liggen voorlopig echter nog niet zo dik bezaaid… Boven op al deze zenuwslopende vertragingen en verloren gelopen pakketjes, komt daar nog bij dat de meeste VoIP-pakketten niet bepaald de beste maatjes zijn van elkaar. Anders gezegd: beide gesprekspartners gebruiken best hetzelfde pakket, willen ze tenminste ook maar één lettergreep van elkaar ten gehore krijgen. Maar ook hier is er snel beterschap op komst. Meer en meer pakketten volgen de H.323-standaard voor multimediacommunicatie over pakketgeschakelde netwerken – die nota bene al in mei 1996 werd geratificeerd – zodat het probleem van incompatibiliteit tussen de pakketten geleidelijk aan ook van de baan kan geraken.