Multimedia über IP und TCP, UDP? - inf.fu-berlin.de · z.B. Netmeeting z.B. Net2Phone IP-basiertes Netz PSTN, ISDN Gateway IP-basiertes Netz PSTN, ISDN PSTN, ISDN Gateway Gateway

Next Generation Internet SoSe03 127

Multimedia over IP

ThemenMultimedia over IP

Sprachübertragung mit Voice-over-IP (VoIP)Nutzung bereits vorhandener Datennetze zur Sprachübertragung

Protokolle für Multimediadaten: RTP, RTCP, RTSP, ...Übertragung von Audio- und Videodaten über das Internet

VoIP Messungen im Internet

Architekturen: H.323, SIPSteuerung von Multimediakonferenzen


Einige Folien sind von Kurose/Ross

Chapter 6Multimedia Networking

Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith RossAddison-Wesley, July 2002.

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in powerpoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:

If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)

If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK / KWR

All material copyright 1996-2002J.F Kurose and K.W. Ross, All Rights Reserved


Anwendungsklassen

Klassen von vernetzten Multimediaanwendungen (networked multimedia applications):

Streaming stored audio and videoStreaming live audio and videoReal-time interactive audio and video

Basiseigenschaften:Verzögerung ist wichtig

Ende-zu-Ende VerzögerungJitter

Relativ tolerant gegenüber PaketverlustenGeringe Paketverluste durchaus tolerierbar


Multimedia über IP und TCP, UDP?

UDP:Server sendet einer der Anwendung entsprechenden Rate (unabhängigvom Zustand des Netzes)

Normal: Send Rate = encoding Rate (daher oft konstante Rate)

Client hat einen Playoutbuffer (2-5 Sekunden) wegen des Jitters im Netz

Fehlerbehebung (error recovery) meist nicht möglich (ein Paket das zuspät ist, ist ein verlorenes Paket)

TCP:Sendet mit der maximalen Rate, die TCP erlaubtSenderate variiert auf Grund der TCP Staukontrolle, deshalb größererPlayoutbuffer notwendig

HTTP/TCP wird von dem meisten Firewalls durchgelassen


Sprachübertragung über das Internet bzw. IP-basierte Netze

Im Prinzip ein alter Hut...Bereits in den frühen 80ern erste Programme

Aber erst Ende der 90er in der breiten Öffentlichkeit (z.B. Net2Phone, Dialpad, ...)

Motivation (oft angeführte Gründe)Kostenreduktion (?): einer der ersten Gründe: oft ist ein Datennetz sowieso vorhanden und wird nach flat-rate abgerechnet – dann kann auch noch zusätzlich der Sprachdatenverkehr über dieses Netz geleitet werden (oft auch zeit- vs. Volumenabhängige Abrechnung) – fraglich bei heutigen Preisen!

Vereinfachung: Verwaltung nur noch eines Netzes, einer Hardware

Effizienz: Nutzung freier Reserven, Multiplex-Gewinn

Robustheit (?): Internet kann Komponentenausfälle kompensieren (dynamische Wegewahl pro Datenpaket)

Flexibilität: „beliebige“ Bandbreiten nutzbar – nicht nur Vielfache von 64 kbit/sIntegration: Das Internet transportiert beliebige Daten zum Endgerät, so können mit einem Gerät, einem Netz, einem Protokoll alle Anwendungen genutzt werden


Anwendungen für VoIP

Sprachkommunikation in Zusammenhang mit Arbeiten am PCMultimedia-Konferenzen (mit Video, Dokumenten, verteiltem Arbeiten)

Helpdesk/Call Center: Zugriff auf KundendatenCTI: Computer-Telephony-Integration

Nutzung vorhandener IntranetsBreakout erst im Ziel-Ortsnetz

Nutzung privater Netze solange wie möglich

Nutzung der Konvergenz von Sprache und DatenTelefon mit Email

Wandlung Sprache-Text, Fax-Email, SMS-Fax, ...

Aber auch Optimisten geben Sprache-über-Internet keine große Chance als Alternative zum Telefonnetz – eher ein Nischenbereich, solange die Qualität nicht verbessert werden kann!


Architekturen

PC zu PC

PC zu Telefon

Telefon zu Telefon

IP-basiertesNetz

z.B. Netmeeting

z.B. Net2PhoneIP-

basiertesNetz

PSTN, ISDN

Gateway

IP-basiertes

NetzPSTN, ISDN

PSTN, ISDN

Gateway Gateway


Technische Herausforderungen I

Das Internet-Protokoll IP bietet keine Dienstgütegarantien!Best-Effort-DatenübertragungKeine QoS in Standard-RouternKeine Verwaltung von Bandbreite etc.Für IP sind alle Pakete gleich!

VerzögerungStandard-Telefon: ca. 5 ms pro 1000 km Laufzeitverzögerung (Festnetz)G.729-Kompression (8 kbit/s): 10 ms Rahmenerzeugung + 5 ms Vorausschauen + 10 ms Berechnung = 25 ms algorithmische VerzögerungG.723.1 (5,3 kbit/s): 100 ms algorithmische VerzögerungJitter-Puffer (Ausgleich der Schwankungen): 40-60 msIP-Paketerzeugung, Netzverzögerung, Betriebssystem des PCs, ...Insgesamt sind Werte um 400 ms und darüber keine Seltenheit!

Echoprobleme ab 50 ms, überlappendes Sprechen ab 250 ms


Verzögerungsquellen in der IP-Telefonie im Vergleich

Codierung

Warteschlange Puffer zumJitter-Ausgleich

Laufzeit (Physik)

Protokoll,Betriebssystem

Decodierung

Protokoll,Betriebssystem

G.711 (schnell)


Technische Herausforderungen II

VerzögerungsschwankungenIntegration von Puffer, führt jedoch zu erhöhter VerzögerungMinimierung von Jitter und Minimierung von Verzögerung sind konträre Ziele

Paketlängengroße Pakete bedeuten auch eine große VerzögerungKleine Pakete erhöhen massiv den Aufwand in Routern

PaketverlustWiederholungen sind meist nicht machbarVorwärtsfehlerkorrektur zur RekonstruktionRauschen, Wiederholen des vorangegangenen Signals oder Extrapolation zum Verdecken der Lücke

Echo CancellationEcho aufgrund der Verzögerung, des Übergangs 2/4-Draht, schlechter PC-HardwareFiltern von Echos nach G.165


Technische Herausforderungen III

Sprachcodierung und –kompressionEinfache und effiziente Verfahren zur Reduzierung der Last bei Sender und Empfänger

Sprachpausenunterdrückung und Generierung von Comfort Noise

AdressumsetzungE.164-Telefonnummern nach IP-Adressen, Verzeichnisdienste

SignalisierungUnterschiedliche Verfahren je nach Nebenstellenanlage, Umsetzung nach SS7, Anbindung an PC-Software

Umfasst Verbindungssteuerung, Bandbreitenreservierung

Dienstgüte im Internet/LANBisher nicht vorhanden – für IP sind alle Pakete gleich (erste Ansätze IntServ/DiffServ im Internet, IEEE 802.1p im LAN)Sollte Ressourcenreservierung, Bandbreitengarantien umfassen – aber auch Sicherheit!


Architectural Model for PC to Phone

An architectural model for Internet telephony.

Packet voiceSample 20 msec

followed by Streaming voice

Internet POTS

CodecG723 <-> PCM

Bitstream 64kpbs

Signaling to set up

Call [email protected] 6331598


Interactive Multimedia: Internet Phone

speaker’s audio: alternating talk spurts, silent periods.64 kbps during talk spurt

packets generated only during talk spurts20 msec chunks at 8 Kbytes/sec: 160 bytes data

application-layer header added to each chunk, including RTP header (see below)

Chunk+header encapsulated into UDP segment.

application sends UDP segment into socket every 20 msec during talk spurt.


network loss: IP datagram lost due to network congestion (router buffer overflow)

delay loss: IP datagram arrives too late for playout at receiver

delays: processing,

queueing in network

end-system (sender, receiver) delays

typical maximum tolerable delay: 400 ms

loss tolerance: depending on voice encoding, losses concealed:packet loss rates between 1% and 10% can be tolerated

Internet Phone: Packet Loss and Delay


Client Playoutbuffer

constant bit rate video

transmission

Cum

ulat

ive

data

time

variablenetwork

delay

client videoreception

constant bit rate video

playout at client

client playoutdelay

buff

ered

vide

o

Client-side buffering, playout delay compensate for network-added jitter


Internet Phone: Fixed Playout Delay

Receiver attempts to playout each chunk exactly q msecs after chunk was generated.

chunk has time stamp t: play out chunk at t+q .chunk arrives after t+q: data arrives too late for playout, data “lost”

Tradeoff for q:large q: less packet losssmall q: better interactive experience


Fixed Playout Delay

Sender generates packets every 20 msec during talk spurt.First packet received at time rFirst playout schedule: begins at pSecond playout schedule: begins at p’

packets

time

packetsgenerated

packetsreceived

loss

r

p p'

playout schedulep - r

playout schedulep’ - r


Adaptive Playout Delay

Goal:minimize playout delay, keeping late loss rate low

Approach: adaptive playout delay adjustment:Estimate network delay, adjust playout delay at beginning of each talk spurt.

Silent periods compressed and elongated.Chunks still played out every 20 msec during talk spurt.


Real-time Transport Protocol (RTP) – RFC 1889

Was ist RTP (aus RFC 1889)“RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.”

RTP bietetIdentifizierung der Nutzlast, Sequenznummern, Zeitstempel, Multicast-Eignung

RTP bietet NICHTRessourcenreservierung, Dienstgüte, garantierte Auslieferung/Reihenfolge

RTP wird typischerweise über UDP eingesetzt

UDP

IP

RTP

Anwendung

Host-to-Network


RTP Header

Nutzlasttyp (payload type): zeigt an, was für eine Encodierung geradeverwendet wird. Diese kann sich im Verlauf einer Session ändern.

Nutzlast-typ

Sequenz-nummer

Zeit-stempel

Sync.SourceID

Misc.

0 PCM µ-law 8 kHz 64 kbps3 GSM 8 kHz 13 kbps15 G.728 8 kHz 16 kbps26 MJPEG31 H.26133 MPEG2

Sequenznummer (16 Bits): wird um jedes gesendete Paketinkrementiert. Damit kann der Empfänger Paketverluste und Reihenfolgeänderungen feststellen.


RTP Header (2)

Zeitstempel (32 Bit): stellt den Samplingszeitpunkt des 1.Bytes dar. Z.B. für Audio wird der Zeitstempel bei jeder Abtastung um eins erhöht, also bei 8KHz sampling rate jede 125 us.

SSID (32 Bits): Identifiziert die Quelle des RTP Stroms

Optional: Contributing Source ID: Daten können unterwegs verändert werden


RTP und Synchronisation

RTP kann verschiedene Datenströme von verschiedenen Mediensynchronisieren.

Beispiel:Konferenz mit Video- und Audiodaten

Warum das funktioniert:Zeitstempel in RTP sind an Video und Audio “Samplingclocks” gebunden, nicht an die “Ortszeit”.


Mixer und Translator

ZielAnpassung des Datenstroms an Anforderungen einzelner Empfänger

MixerZusammenfügen mehrerer Ströme

TranslatorUmkodierung des Stroms

ForderungZwischensysteme müssenauf Anwendungsebeneoperieren. Bei heutigenZwischensystemen ist diesnicht der Fall.

Translator

Mixer

PCM GSM

PCM

B

A

Audiodaten von A (PCM-kodiert)Audiodaten von B (PCM-kodiert)Gemixte Audiodaten von A und B (PCM-kodiert)Audiodaten von B (GSM-kodiert)


RTP Control Protocol (RTCP) – RFC 1889

Gemeinsam mit RTP spezifiziertes Signalisierungsprotokoll für RTPÜberwachung und Rückmeldung der Qualität des RTP-Transports

Arbeitet über separaten Port

Periodisches Aussenden an alle Gruppenmitglieder von EmpfängerstatistikenAnzahl gesendeter Pakete, Jitter, Datenverluste, ...

Sender können auf Statistiken reagierenAnpassen der Senderate

Auch Diagnosemöglichkeit für EmpfängerProbleme lokal/regional/global?

RTCP hat SkalierungsproblemeRTP-Verkehr unabhängig von der Zahl der Empfänger

RTCP-Signalisierungshäufigkeit muss an Teilnehmerzahl angepasst werden

RTCP-Sendeperiode für RTP-Empfänger = (Anzahl Empfänger * durchschn. RTCP-Paketgröße)/(0,75*0,05*RTP-Bandbreite)


RTCP (2)

Eine RTP Session benutzt eine Multicast-Adresse:RTP und RTCP Pakete der gleichen Session benutzen die gleicheMulticast-Adresse

Unterscheidung von RTP und RTCP:Unterschiedliche Ports


Real-Time Streaming Protocol (RTSP) – RFC 2326

Benutzer von Multimediaanwendungen wollen diese oft steuernPause, Sprung zu einer bestimmten Stelle, schneller Vorlauf/Rücklauf, Zeitlupe etc.

Vgl. Fernbedienung von Videorekorder/CD-Spieler

RTSP definiert NICHTKompressionsverfahren, Kapselung der Daten (dies kann z.B. durch RTP geschehen)

Transport der Daten (z.B. UDP, TCP oder proprietär)

Implementierung (Pufferung, sofortiges Abspielen etc.)

RTSP steuert die Übertragung„out-of-band“-Signalisierung über eigenen Port (544) [vgl. FTP-Steuerung]Transport der Signalisierungsdaten via UDP oder TCP

AnwendungenRealMedia Server und Player G2Abspielen aber auch Aufnehmen von A/V-Strömen


RTSP: Beispiel

Beschreibung von Audio und VideoWird via Web-Browser von einem Server gelesenEnthält im Beispiel zwei verschiedene Audioformate

Lippensynchrones Abspielen von Audio und Video

<title>Matrix</title>

<session>

<group language=de lipsync>

<switch>

<track type=audio

e="PCMU/8000/1"

src="rtsp://audio.film.de/matrix/audio.de/lofi">

<track type=audio

e="DVI4/16000/2" pt="90 DVI4/8000/1"

src="rtsp://audio.film.de/matrix/audio.de/hifi">

</switch>

<track type="video/jpeg"

src="rtsp://video.film.de/matrix/video">

</group>

</session>


RTSP: Signalisierungsbeispiel

Client: SETUP rtsp://audio.film.de/matrix/audio RTSP/1.0Transport: rtp/udp; compression; port=12345; mode=PLAY

Server: RTSP/1.0 200 1 OK

Session 8765Client: PLAY rtsp://audio.film.de/matrix/audio.de/hifi RTSP/1.0

Session: 8765Range: npt=0-

...

Client: PAUSE rtsp://audio.film.de/matrix/audio.de/hifi RTSP/1.0

Session: 8765Range: npt=48

...

Client: TEARDOWN rtsp://audio.film.de/matrix/audio.de/hifi RTSP/1.0Session: 8765

Server: RTSP/1.0 200 3 OK

Web Browser Web ServerHTTP GET(Beschreibungsdatei)

Beschreibungsdatei

MediaPlayer

MediaServer

SETUP, PLAY, ...

PAUSE, TEARDOWN, ...

Multimediadaten


VoIP Measurements by Ian Marsh (SICS)

Goal: study how well VoIP works in today’s Internet

Produce: loss, delay and jitter results for VoIP

Compare with results obtained in 1999Construct a robust measurement infra-structure

Collect a repository of VoIP trace files

Danke für die Folien, Ian!


VoIP Measurements: Test Sites

Cooperating Sites in 1999Cooperating Sites in 2002


VoIP Measurements

Methodology: Send pre-recorded wav file between sites

Currently once per hour (mainly to keep load down)Using scripts allows any tool to be used (even w/o source)

Timestamp files as GMT offset (post-processing easier)

Uses RTP/UDP/IP

Data:

Call duration: 70 secs

Silence Sup.: 2043 packetsNo Silence Sup.: 3653 packets

Coding: 8 bit PCM

File Size: 584480 bytesTotal Trace Files:22436


Comparison 1999 and 2002 VoIP Quality:

-26,1 %84,95 ms115 msDelay

-58,3%0,5%1,2%Loss

-50%22,6 ms 45,1 msJitter

% diff.20021999Quality

Loss, jitter and delay improved

Attribute it to upgrading links

2002 we had 1000's of traces whilst 1999 fairly few in comparison


VoIP: inter-arrival times

0 20 40 60 80 100 1200

50

100

150

200

250

interarrival times, ms

freq

uenc

y

VoIP session from Argentina to Stockholm, packetization 20 ms

Documents

Multimedia über IP und TCP, UDP? - inf.fu-berlin.de · z.B. Netmeeting z.B. Net2Phone IP-basiertes Netz PSTN, ISDN Gateway IP-basiertes Netz PSTN, ISDN PSTN, ISDN Gateway Gateway