I detta avsnitt beskrivs några intressanta och ofta använda protokoll på transport-, applikations- och sessionsnivå.
4.5.1 Transportprotokoll
I lagret ovanför IP-protokollet används huvudsakligen två olika protokoll. Det vanligaste protokollet är TCP, som tillsammans med IP utgör kärnan i Internet. Det andra protokollet heter UDP och är ett komplement till TCP. En av huvuduppgifterna för proto- koll i detta lager är att leverera data till rätt applikation. Detta görs genom ett adressystem som kallas för portar. Dessa portar kan ses som en utökning av IP-adress- erna. Ibland behövs viss specifik funktionalitet som inte TCP eller UDP kan erbjuda. Detta gäller framförallt realtidstjänster. Därför har ett kompletterande protokoll, RTP, utvecklats som används tillsammans med UDP och TCP.
4.5.1.1 TCP
Transmission control protocol, TCP, är ett protokoll som erbjuder tillförlitlig överföring av paket [12]. Det garanterar även att paketen anländer i rätt ordning. Eftersom detta ofta är en nödvändig egenskap för en tillämpning har TCP blivit ett vanligt förekommande protokoll i IP-baserade nät.
Grundtanken med TCP är att skapa en förbindelse med mottagaren. Detta kan vara relativt komplicerat eftersom RTT kan variera kraftigt i stora IP-nät. Dessutom kan RTT till en mottagare variera beroende på vilken tid på dygnet uppkopplingen skapas.
När en förbindelse skapats är mottagaren redo att ta emot paket. TCP använder sekvensnummer, kontrollsumma och bekräftelse för att garantera att alla paket överförts korrekt och i rätt ordning. Detta innebär att informationen är dubbelriktad i en TCP-upp- koppling. Alla paket som är korrekta hos mottagaren konfirmeras. Paket som inte konfir- merats skickas om och när alla paket överförts korrekt avslutas uppkopplingen.
Förutom tillförlitlig överföring implementerar TCP även avancerade funktioner för flödeskontroll och congestion-kontroll. Flödeskontroll innebär att sändaren inte skickar data snabbare än mottagaren hinner ta emot. Detta görs genom att mottagaren hela tiden talar om hur stor mottagarbuffert den har. Sändaren skickar inte mer data än storleken på denna buffert.
Congestion-kontroll innebär att sändaren inte skickar så mycket data att nätverket blir överbelastat. TCP:s strategi är att sänka hastigheten så fort överbelastning detekteras. Om nätet är överbelastat eller ej avgörs genom att analysera hur många paket som tappas och hur RTT varierar.
4.5.1.2 UDP
User datagram protocol, UDP, är ett enklare protokoll än TCP [13]. Utöver den best- effort-tjänst som det underliggande nätverket erbjuder tillför UDP inget mer än möjlig- heten att leverera paket till rätt applikation. Möjlighet finns också att beräkna en kontroll- summa men detta är inget krav enligt standarden.
Datornät
MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder 37
4.5.1.3 RTP
I vissa sammanhang är det viktigare att paket anländer i tid än i rätt ordning. Detta kan till exempel vara realtidstjänster, där paket som anländer för sent är obrukbara. Real-time
transport protocol, RTP, är ett protokoll specifikt för multimediatjänster i realtid [11].
RTP fungerar tillsammans med många protokoll men normalt används det tillsammans med UDP, se figur 20.
Figur 20: Protokollstack för RTP.
RTP är utvecklat för att vara ett flexibelt protokoll som inte ska behöva uppdateras i takt med att nya applikationer och tjänster utvecklas. Den header RTP använder innehåller information om vilken typ av media paketet innehåller. Detta används av mottagaren för att veta hur den ska tolka informationen. RTP markerar även varje paket med ett sekvens- nummer och en tidsangivelse. Till skillnad mot TCP åtgärdas inte förlorade paket, utan sekvensnumret är endast information till mottagaren. Tidsangivelsen anger när motsvar- ande data ska presenteras. I headern kan även kompletterande källor anges. Detta kan användas för att tala om att RTP-strömmen ska kombineras med en RTP-ström från en annan källa.
Designen av RTP förutsätter så kallad application level framing, ALF. Principen för ALF är att applikationen vet bäst hur de data den vill skicka ska paketeras. Detta görs alltså inte av RTP.
Nära förknippat med RTP är RTP control protocol, RTCP [11]. Detta protokoll används som ett komplement till RTP för att skicka kontrolldata för en viss RTP-ström. RTCP används för att analysera nätverkets prestanda, synkronisera olika mediaströmmar från samma sändare och för att skicka information om sändaren. RTCP använder oftast TCP som transportprotokoll.
4.5.2 Applikations- och sessionsprotokoll
I applikationslagret finns en rad olika protokoll. Några, i sammanhanget intressanta, protokoll är HTTP och RTSP. För multimediakommunikation är det ibland nödvändigt att beskriva vilken typ av media som används innan sessionen startas. För detta används ett sessionsbeskrivande protokoll. Ett vanligt sessionsbeskrivande protokoll är SDP.
Ofta är det önskvärt att en klient i största möjliga mån konfigureras automatiskt. För grundläggande funktionalitet som adresstilldelning kan DHCP användas. För mer avan- cerad konfigurering, av till exempel tjänster, finns SLP.
Network IP UDP
RTP Application
4.5.2.4 HTTP
Hypertext transport protocol, HTTP, är ett protokoll som används för att hämta webb-
sidor över Internet [14]. Protokollet används tillsammans med TCP och det transporterar även aktuell data. HTTP kan även användas för att hämta mediafiler.
HTTP är ett nedladdningsprotokoll, det vill säga protokollet hämtar all begärd data innan det presenterar det. Protokollet kan därför inte användas för att hämta realtids- media.
4.5.2.5 RTSP
Real-time streaming protocol, RTSP, är ett sessionsorienterat protokoll på applikations-
nivå som används för att kontrollera och styra en eller flera multimediaströmmar [15]. RTSP används inte för att transportera data, utan till detta används till exempel RTP. RTSP själv transporteras oftast över TCP.
RTSP beskrivs ofta som en nätverksbaserad fjärrkontroll för multimediaströmmar. Protokollet används för att starta, stoppa, pausa och spela in mediaströmmar och syn- taxen liknar mycket den för HTTP.
4.5.2.6 SDP
Session description protocol, SDP, är ett protokoll som används för att beskriva multi-
mediasessioner [16]. Användningsområdet för detta är till exempel sessionsinitieringar och sessionsinbjudningar. SDP är inte ett transportprotokoll utan förmedlar endast infor- mation om sessioner. Informationen består av en beskrivande text. Texten beskriver bland annat vilken typ av media som används, vilken typ av transportprotokoll som används, eventuella start- och sluttider samt vilken eventuell multicastadress som ska användas. Information om flera sessioner kan ligga efter varandra i en lista.
SDP är utformat för att kunna transporteras över en rad olika protokoll. Några exempel är SAP, RTSP och epost [18] [15]. SAP är ett protokoll som används för att annonsera sessioner med hjälp av multicast.
4.5.2.7 SLP
Service location protocol, SLP, är ett protokoll som används för att automatiskt hitta,
konfigurera och välja tjänster i ett nätverk [17]. Klienten använder en speciell multicast- adress för att fråga om tillgänglighet av en viss tjänst i ett nätverk. De servrar som kan erbjuda tjänsten svarar med nödvändig information.
39
MPEG-4-kompatibel settop-box för IP-nät baserad på öppna standarder
KAPITEL
5
5
MPEG-4
ÖVER
IP
Detta kapitel beskriver förutsättningar och alternativ för att skicka MPEG-4-kodade videoströmmar över IP-baserade nätverk.
5.1 Introduktion
Anledningen till att IP-protokollet är intressant när det gäller MPEG-4 är att det är grunden för Internet. Genom att anpassa videoströmmarna till IP-baserade nätverk öppnas också dörrarna för att skicka dem över Internet. Genom att använda befintlig och fungerande infrastruktur ökas nåbarheten samtidigt som kostnaden kan hållas nere.
Från början var tanken att MPEG-4 inte skulle innehålla detaljer om transport av media. Istället skulle ett transportoberoende gränssnitt utvecklas. Del 1 av standarden, MPEG-4 Systems, beskriver hantering och synkronisering av olika ES och del 6, MPEG- 4 DMIF, beskriver ett transportoberoende sätt att leverera dessa strömmar. Dessa delar diskuteras utförligare i avsnitt 5.2.
Internets genomslagkraft gjorde dock att MPEG bestämde sig för att tillsammans med Internet Engineering Task Force, IETF, göra en gemensam kraftansträngning för att standardisera MPEG-4 över IP. MPEG:s arbete utmynnade i del 8 av standarden som innehåller riktlinjer för hur MPEG-4 ska transporteras över IP. Detta behandlas i avsnitt 5.3.
IETF:s arbete med MPEG-4 över IP pågår fortfarande och innebär att format för att paketera utdata i RTP-paket utvecklas. Arbetet har resulterat i en standard och två förslag till standarder. Dessa format diskuteras i avsnitt 5.4.