`Voice over IP' (VoIP) gaat over het versturen van een stemsignaal via een IP netwerk (het Internet is hier een voorbeeld van). De context van dit signaal bepaalt de vereisten voor deze transmissie. Bijvoorbeeld, als het signaal deel uitmaakt van een conversatie tussen twee personen, moet men ervoor proberen te zorgen dat de real-time eigenschappen ervan behouden blijven: de vertraging tussen het spreken van één persoon en het horen wat er gezegd werd door de andere persoon moet zo klein mogelijk zijn om irritante stiltes in de communicatie te vermijden. Andere VoIP toepassingen - zoals een lezing via een netwerk - hebben deze vertragingsbeperking niet.
Deze thesis gaat over VoIP in genetwerkte virtuele omgevingen. Ze bevat zowel informatie over VoIP in het algemeen als over toepassing ervan in virtuele omgevingen. Verder geef ik ook een beschrijving van de applicaties die ik zelf ontwikkelde om verschillende aspecten van VoIP in virtuele omgevingen te kunnen testen.
De klassieke toepassing van VoIP is als vervangingsmiddel voor een gewoon telefoongesprek. Wanneer VoIP op deze manier gebruikt wordt, kunnen de kosten van een gesprek verminderd worden, maar de kwaliteit ervan is meestal wel lager dan bij een normaal telefoongesprek. Het gebruik van VoIP in genetwerkte virtuele omgevingen is relatief nieuw. Zulke toepassingen laten gebruikers toe met elkaar te `chatten' zoals bij IRC, maar in plaats van tekstuele boodschappen naar elkaar te sturen kunnen ze gewoon met elkaar praten. Het toevoegen van een 3D effect aan het stemsignaal van een gebruiker zorgt voor een meer natuurlijke omgeving. Er zijn nog vele andere toepassingen die soortgelijke technieken gebruiken als VoIP, bijvoorbeeld het versturen van een videosignaal.
Er zijn heel wat componenten nodig om VoIP in virtuele omgevingen mogelijk te maken. Een stemsignaal wordt opgesplitst in kleine stukjes die afzonderlijk verzonden worden. Om zo een stukje van een signaal te kunnen versturen, moet het eerst gedigitaliseerd worden. Bij de ontvanger moet deze informatie weer gereconstrueerd worden tot een continu geluidssignaal dat naar de luidsprekers gestuurd kan worden. Merk op dat wanneer verschillende personen tegelijk spreken, hun stemsignalen gecombineerd moeten worden. Verder moeten er ofwel bij de zender, ofwel bij de ontvanger, 3D effecten toegevoegd worden aan het signaal. Om de nodige bandbreedte voor het versturen van de gegevens te verminderen, kan het gedigitaliseerde signaal best gecomprimeerd worden. Natuurlijk moet dan aan de andere zijde deze informatie weer gedecomprimeerd worden vooraleer het verder verwerkt kan worden. Tenslotte moet er ook een component zijn die het versturen en ontvangen van pakketten met steminformatie mogelijk maakt.
Het Internet Protocol of IP is een deel van een gelaagde architectuur die het TCP/IP referentiemodel heet. Dit model bestaat uit vier lagen waarvan elke laag een aantal functies voorziet aan de laag erboven. De internet laag is de laag waarin IP gedefinieerd wordt. Deze maakt het mogelijk om blokken met gegevens, datagrams genaamd, te versturen van bron naar bestemming. Dit wordt gedaan door actief elk datagram over elk tussenliggend netwerk te versturen. Aangrenzende netwerken worden met elkaar verbonden door machines die `routers' genoemd worden. Deze routers analyseren binnenkomende IP datagrams en sturen ze verder via het juiste netwerk. IP ondersteunt `multicasting', een techniek waarmee een datagram efficient naar verscheidene bestemmingen gestuurd kan worden. Het sturen van een datagram naar slechts één bestemming wordt `unicasting' genoemd.
Het Internet Protocol is een connectieloos pakketgebaseerd protocol dat geen garanties biedt over de aankomst van een datagram. Datagrams kunnen zelfs gedupliceerd of in de verkeerde volgorde afgeleverd worden. Andere karakteristieken van IP netwerken zijn de vertraging door wachttijden in routers en de verschillen in vertraging tussen opeenvolgende pakketten. Dit laatste wordt ook wel `jitter' genoemd.
De transport laag - die boven de internet laag ligt - bevat twee veel gebruikte protocols. Het `Transmission Control Protocol' of TCP, biedt een connectiegeörienteerde dienst aan waarvan de connectie kan beschouwd worden als een betrouwbare stroom van bytes. Het `User Datagram Protocol' of UDP, is enkel een extensie van IP op het niveau van de transport laag en heeft dezelfde eigenschappen als IP.
De belangrijkste redenen voor pakketgebaseerde communicatie zijn de mogelijkheden om de informatie te comprimeren en stiltes uit te buiten. De alomtegenwoordigheid van IP is de voornaamste reden waarom dit protocol een goede kandidaat is voor het transporteren van steminformatie.
Omwille van een aantal redenen werd er een nieuwe versie van het Internet Protocol ontwikkeld. De belangrijkste reden was het feit dat er al gauw geen IP adressen meer beschikbaar zouden zijn op het Internet. De nieuwe versie van het protocol heet IP versie zes, of kortweg IPv6.
Een aantal aspecten van het communiceren via de stem hebben een belangrijke betekenis voor `Voice over IP'. Om VoIP mogelijk te maken, moeten we een stemsignaal kunnen digitaliseren en reconstrueren. Een meetsnelheid van 8000 Hz waarbij men acht bit samples gebruikt, is voldoende om communicate met dezelde kwaliteit als een telefoongesprek mogelijk te maken. Hiervoor is dan een bandbreedte van 64 kbps nodig.
Mensen zijn meestal erg verdraagzaam tegenover incorrecte of verloren pakketten met spraakinformatie. Ze zijn echter veel minder tolerant tegenover vertraging en jitter. Jitter moet men trachten te vermijden door pakketten even in een buffer te plaatsen, aangezien het de kwaliteit van de communicatie sterk verlaagt. De vertraging van een pakket zou onder 200 ms moeten blijven om een conversatie met telefoonkwaliteit te kunnen houden.
Vanuit het standpunt van de communicatie zijn erg kleine pakketten wenselijk aangezien een incorrect of verloren pakket dan een kleinere onderbreking in de communicatie veroorzaakt. Vanuit het standpunt van de vertraging is een klein meetinterval belangrijk aangezien dit interval direct bijdraagt tot de algemene vertraging in de communicatie.
Tenslotte is er in de praktijk meestal slechts één persoon tegelijk aan het praten in een discussie. Dit betekent dat heel wat bandbreedte beter benut kan worden door geen pakketten te versturen die enkel stilte bevatten.
Voor communicatie met telefoonkwaliteit waarbij gedigitaliseerde spraakinformatie verzonden wordt, is een bandbreedte van 64 kbps nodig indien de gegevens niet gecomprimeerd worden. Zulke spraakgegevens kunnen vaak echter sterk gecomprimeerd worden waardoor de nodige bandbreedte drastisch vermindert.
Sommige compressiemethodes houden geen rekening met de aard van de gegevens. Zulke technieken zorgen wel voor wat compressie, maar resulteren meestal niet in hoge compressieratio's. Ze kunnen echter wel gebruikt worden om de vereiste opslagruimte nog verder te verminderen wanneer een andere methode de spraakinformatie al gecomprimeerd had.
`Waveform coding' technieken veronderstellen dat de gegevens een audio signaal representeren maar ze maken geen gebruik van de wetenschap dat het signaal enkel steminformatie bevat. Ze proberen gewoon het eigenlijke signaal zo goed mogelijk te modelleren. Deze manier van werken heeft meestal goede spraakkwaliteit tot gevolg waarbij een relatief hoge bandbreedte vereist is (16 kbps of meer).
`Vocoders' maken wel gebruik van het feit dat de gegevens feitelijk een gedigitaliseerd stemsignaal zijn. Ze coderen niet het signaal zelf, maar wel een benadering van hoe het signaal gevormd werd door het menselijke spraakmechanisme. Zulke methodes laten zeer hoge compressieratio's toe terwijl de verstaanbaarheid van de communicatie zeer goed blijft (aan 4.8 kbps of minder). Het gereconstrueerde signaal klinkt vaak wel wat synthetisch.
Een combinatie van technieken die waveform coders en vocoders gebruiken, wordt toegepast in hybride technieken. Ze maken nog steeds gebruik van een spraakproductiemodel, maar ze kunnen het oorspronkelijke signaal veel beter reconstrueren door het gebruik van technieken die waveform coders toepassen. Hybride methodes kunnen goede spraakkwaliteit genereren en hebben meestal een bandbreedte van 4.8 tot 16 kbps nodig.
Het comprimeren en decomprimeren van spraakgegevens zorgt voor een zekere hoeveelheid vertraging in de communicatie. Omdat computers steeds sneller worden en omdat gespecialiseerde hardware beschikbaar wordt, is waarschijnlijk de hoeveelheid `lookahead' die een compressiemethode nodig heeft de belangrijkste component van deze vertraging. De `lookahead' beschrijft hoe ver de methode vooruit moet kijken om een deel van het signaal te kunnen comprimeren.
Om verschillende applicaties met elkaar te kunnen laten samenwerken, is het belangrijk dat standaarden vastgelegd worden. Bekende compressie standaarden in de VoIP wereld zijn onder andere de G. standaarden van ITU-T en de GSM standaarden van ETSI.
Wanneer we spraakgegevens willen versturen, zijn er een aantal dingen waar we aan moeten denken. Zo is er een of ander mechanisme nodig om intramedia synchronisatie te bewaren. Ook moeten er maatregelen genomen worden om een kleine vertraging te garanderen en moeten `flow control' en `congestion control' mogelijk zijn.
In de TCP/IP architectuur kan een applicatie TCP of UDP gebruiken om gegevens te versturen. Om steminformatie te verzenden zou TCP misschien een goede keuze lijken aangezien TCP een stroom van bytes betrouwbaar kan versturen waarbij flow en congestion control intern geregeld worden. Deze betrouwbaarheid wordt echter gegarandeerd door het opnieuw versturen van incorrecte of verloren pakketten en dit verhoogt dan weer de algemene vertraging in de communicatie. Extra vertraging kan ook veroorzaakt worden door de flow en congestion control mechanismen, waarover de gebruiker maar weinig controle heeft.
Het andere protocol, UDP, is niet voldoende voor real-time gegevens aangezien het op geen enkele manier intramedia synchronisatie of flow of congestion control mogelijk maakt. Een oplossing voor dit probleem is UDP een beetje uitbreiden. Dit is de manier waarop RTP in de TCP/IP architectuur gebruikt wordt.
Het `Real-time Transport Protocol' (RTP) voorziet een pakket van extra informatie die gebruikt kan worden voor synchronisatie binnen een stroom van gegevens. Het `RTP Control Protocol' (RTCP) geeft bijkomende informatie die gebruikt kan worden voor synchronisatie tussen verschillende media, voor flow en congestion control en voor identificatie.
Elk stukje gedigitaliseerde spraakgegevens wordt voorafgegaan door een aantal zogenaamde `headers'. Deze headers nemen ook een deel van de bandbreedte in, dus om deze hoeveelheid relatief laag te houden, mag een pakket niet te klein zijn. Voor dial-up verbindingen kan extra bandbreedte bespaard worden door header compressie technieken toe te passen.
Om `quality of service' (QoS) mogelijk te maken, zou men de prioriteitsinformatie in de IP header kunnen gebruiken. Deze methode kan de QoS vebeteren maar biedt geen garanties. Wanneer garanties noodzakelijk zijn, kunnen andere protocols zoals ST2 en RSVP gebruikt worden. Beide geven garanties door het maken van reservaties, bijvoorbeeld van bandbreedte.
Versie twee van het `Stream Protocol' (ST2) gebruikt een zender-geïnitieerd reservatiemodel: de zender stuurt reservatie-aanvragen over het pad naar de ontvangers. Het is een connectiegeörienteerd protocol dat als aanvulling bij IP dient.
Het `Resource Reservation Protocol' (RSVP) daarentegen gebruikt een ontvanger-geïnitieerde aanpak. De zender verspreidt een beschrijving van de gegevens die hij zal zenden en de ontvangers kunnen dan reservaties maken voor deze gegevens. Het is een `soft-state' mechanisme: zenders en ontvangers moeten deze informatie geregeld verspreiden omdat anders de gemaakte reservaties vrijgegeven worden. RSVP voegt ook reservaties samen wanneer mogelijk. Dit protocol lijkt efficienter te zijn dan ST2.
Het verzenden van pakketten zorgt voor een bepaalde vertraging in de communicatie. Deze vertraging is sterk variabel door de wachttijden in routers.
Om te doen lijken alsof een geluid vanaf een zekere positie komt, is het nodig om een stereo signaal te genereren. Hierdoor is het efficienter om 3D effecten toe te voegen aan de kant van de ontvanger, aangezien we dan enkel een mono signaal moeten verzenden. Op deze manier kunnen we ook IP multicasting gebruiken omdat exact dezelfde gegevens naar alle ontvangers gestuurd moeten worden.
Eén manier om de spraakgegevens te verspreiden is door unicasting te gebruiken. Dit laat toe dat de zender bepaalt wie deze gegevens ontvangt, maar verspilt bandbreedte. Efficientere distributie kan door het gebruik van multicasting. Het is dan aan de ontvangers om te bepalen wiens spraakgegevens ze moeten verwerken.
Geluiden lijken vanaf een bepaalde positie te komen doordat elk trommelvlies een licht verschillend signaal ontvangt. Uit deze verschillen bepalen de hersenen de positie van de bron van het geluid. Twee belangrijke aanwijzingen voor lokalisatie zijn `Interaural Time Difference' (ITD) en `Interaural Intensity Difference' (IID). Deze drukken respectievelijk het tijdsverschil en intensiteitsverschil uit van het waargenomen signaal aan elk trommelvlies. Het buitenoor (de oorschelp) speelt ook een zeer belangrijke rol bij de localisatie van geluiden.
Door ITD en IID te gebruiken, is het mogelijk eenvoudige 3D effecten te genereren. Het is op deze manier echter niet mogelijk om een onderscheid te maken tussen `voor' en `achter' of tussen `boven' en `onder'. Betere resultaten kunnen behaald worden door de transformaties van een signaal vooraleer het de trommelvliezen bereikt, te simuleren. `Head-Related Transfer Functions' (HRTFs) beschrijven deze transformaties.
Omdat er meerdere geluidsbronnen tegelijkertijd kunnen zijn, is het mogelijk dat de berekeningen om 3D geluiden te genereren te zwaar zijn. Het kan dan nodig zijn om de localisatie van geluiden te laten doen door hardware. Omwille van dezelfde reden kan het zijn dat de nodige bandbreedte niet beschikbaar is, bijvoorbeeld wanneer een dial-up verbinding gebruikt wordt. Een oplossing is dan een machine vóór de trage verbinding de 3D effecten te laten toevoegen en het gecombineerde signaal over de verbinding te sturen.
Verscheidene protocols en standaarden zijn gerelateerd aan VoIP. Een eerste voorbeeld is H.323, een aanbeveling voor het houden van multimedia conferenties over pakketgebaseerde netwerken zonder QoS garanties. Het is een onderdeel van een reeks standaarden die dezelfde diensten beschrijven over verschillende soorten netwerken.
H.323 definieert hoe verschillende componenten samen moeten werken om bepaalde functies mogelijk te maken. Door middel van H.323 kan een verbinding gemaakt worden, kunnen de mogelijkheden van de deelnemers uitgewisseld worden en kunnen de deelnemers met elkaar communiceren. Media vertrekken en komen aan in `terminals'. Een `gateway' maakt communicatie over verschillende soorten netwerken mogelijk. Conferenties tussen meerdere gebruikers zijn mogelijk door het gebruik van een `multipoint control unit' (MCU). Een `gatekeeper' maakt gevorderde zaken als beheer van bandbreedte en registratie van gesprekken mogelijk.
De H.323 aanbeveling werd ontwikkeld door ITU-T. De IETF werkt ook aan een architectuur die soortgelijke diensten mogelijk maakt. Net zoals bij H.323, worden de media binnen deze architectuur verzonden via RTP, dus is het grootste verschil tussen beide aanpakken de manier waarop een verbinding gemaakt en beheerd wordt. In de IETF architectuur wordt het `Session Initiation Protocol' (SIP) gebruikt om dit te doen. De functionaliteit die SIP aanbiedt, komt overeen met de functionaliteit die door componenten van H.323 worden aangeboden. Een belangrijk kenmerk van SIP is de mogelijkheid tot persoonlijke mobiliteit. Hiermee wordt bedoeld dat een gebruiker een oproep die aan hem gericht is eender waar kan beantwoorden.
Wanneer we SIP en H.323 vergelijken, lijkt SIP minder complex te zijn, beter uitbreidbaar en beter bruikbaar bij conferenties met toenemend aantal deelnemers. Hun functionaliteit is gelijkaardig, maar het uitwisselen van mogelijkheden tussen terminals in H.323, is meer geavanceerd dan de overeenkomstige functie in SIP. Daarentegen voorziet SIP betere persoonlijke mobiliteit.
Het `Real-Time Streaming Protocol' (RTSP) is een ander VoIP gerelateerd protocol. Dit protocol dient als een soort afstandsbediening voor een media server. Zo kan RTSP bijvoorbeeld gebruikt worden om een presentatie of mediabestand op een server af te spelen. Het kan ook gebruikt worden om een presentatie die bezig is op te nemen.
Om RTP gemakkelijk in verscheidene applicaties te kunnen gebruiken, heb ik een library geschreven die RTP functionaliteit voorziet. Deze library heet JRTPLIB, wat staat voor ``Jori's RTP Library''. Hij is geschreven in C++, gebruik makend van een objectgeoriënteerde aanpak.
De library maakt het zenden en ontvangen van RTP pakketten makkelijker. De gebruiker kan een willekeurig aantal bestemmingen opgeven. Multicasting kan gebruikt worden voor het efficiënt verspreiden van de gegevens. De RTCP functionaliteit wordt volledig intern behandeld.
De structuur van de library is erg modulair, wat de broncode gemakkelijk begrijpbaar en uitbreidbaar maakt. De `Application Programming Interface' (API) is relatief gemakkelijk te gebruiken. Door het gebruik van standaard socket functies is de library beschikbaar op een groot aantal platformen. Verschillende technieken worden toegepast om de library zo snel mogelijk te maken, wat natuurlijk erg wenselijk is bij applicaties met real-time vereisten.
Na de library een tijdje te hebben gebruikt, besloot ik hem beschikbaar te maken op het World Wide Web. Dit heeft me geholpen om de ondersteuning voor verscheidene platformen te verbeteren.
Om gemakkelijk wat VoIP test applicaties te kunnen maken, heb ik eerst een object-georiënteerd VoIP framework gemaakt in C++. Dit framework was ook ontworpen om verschillende technieken om een VoIP component te realiseren uit te kunnen testen, bijvoorbeeld verschillende compressiemethodes. De structuur van het framework weerspiegelt de componenten die in deze thesis beschreven worden.
De kern van het framework bevat veel abstracte klassen die VoIP componenten voorstellen, zoals bijvoorbeeld een transmissie of compressie component. Door overerving te gebruiken kan dan een component werkelijk gerealiseerd worden. Het is dit principe dat toelaat verscheidene versies van een component gemakkelijk uit te proberen.
Om het VoIP framework te testen heb ik een aantal programma's gemaakt, waaronder een Internettelefonie applicatie en een 3D omgeving. Het VoIP gedeelte van de applicaties wordt in een aparte thread opgestart. Hierin wordt voortdurend een functie uit het framework aangeroepen om VoIP mogelijk te maken. Er wordt nog wat extra werk gedaan om synchronisatie tussen de deelnemers te verzekeren.
De Internettelefonie applicatie is relatief eenvoudig en laat makkelijk communicatie met een goede kwaliteit toe wanneer voldoende bandbreedte beschikbaar is. De 3D omgeving laat toe dat verscheidene personen met elkaar communiceren. Daarbij worden eenvoudige localisatie-effecten toegevoegd aan hun stemsignalen. Zowel unicasting als multicasting kan geselecteerd worden om spraakgegevens te versturen. Ook deze applicatie laat communicatie met goede kwaliteit toe wanneer er voldoende bandbreedte aanwezig is. Bij beide applicaties hangt de hoeveelheid bandbreedte die nodig is af van de gebruikte compressiemethode.
Momenteel is VoIP in het algemeen al mogelijk wanneer het netwerk genoeg capaciteit heeft. Omwille van een aantal redenen verwacht ik dat in de toekomst zulke applicaties meer gebruikt zullen worden. Zo zullen QoS ondersteunende protocols op grotere schaal gebruikt worden, wat betere gesprekskwaliteit garandeert. Ook zullen hoogstwaarschijnlijk de beschikbare bandbreedte toenemen en zullen compressiemethodes krachtiger worden, wat alweer betere kwaliteit van de communicatie tot gevolg heeft. Wanneer standaarden als H.323 en SIP meer in gebruik genomen worden, zullen applicaties van verschillende ontwerpers met elkaar kunnen interageren. Een gebruiker kan dan een programma naar keuze gebruiken om met iemand anders te communiceren. Ook het kostenbesparend karakter van VoIP zal een rol spelen bij de ingebruikname ervan.
Specifiek voor VoIP in genetwerkte virtuele omgevingen bestaan er nog niet veel applicaties. Zulke applicaties vormen echter een aantrekkelijk alternatief voor tekstuele `chat' programma's. Betere QoS zal ook dit soort applicaties waarschijnlijk meer populair maken. Toenemende kracht van processoren zal voor steeds betere 3D effecten zorgen, wat het realisme van zulke applicaties sterk zal verbeteren. Dit kan ook weer bijdragen tot de ingebruikname ervan.
Wat mijn eigen programma's betreft kan ik alvast stellen dat de RTP library zeer handig in gebruik is. Dit wordt bevestigd door de vele positieve reacties. Ook het VoIP framework is handig te gebruiken en laat toe gemakkelijk verschillende VoIP componenten te testen. De applicaties die ik hiermee geimplementeerd heb blijken een goede gesprekskwaliteit toe te laten wanneer voldoende bandbreedte aanwezig is.