Multimedia über IP und TCP, UDP? - inf.fu-berlin.de · z.B. Netmeeting z.B. Net2Phone IP-basiertes...
Transcript of Multimedia über IP und TCP, UDP? - inf.fu-berlin.de · z.B. Netmeeting z.B. Net2Phone IP-basiertes...
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
Next Generation Internet SoSe03 128
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
Next Generation Internet SoSe03 129
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
Next Generation Internet SoSe03 130
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
Next Generation Internet SoSe03 131
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
Next Generation Internet SoSe03 132
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!
Next Generation Internet SoSe03 133
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
Next Generation Internet SoSe03 134
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
Next Generation Internet SoSe03 135
Verzögerungsquellen in der IP-Telefonie im Vergleich
Codierung
Warteschlange Puffer zumJitter-Ausgleich
Laufzeit (Physik)
Protokoll,Betriebssystem
Decodierung
Protokoll,Betriebssystem
G.711 (schnell)
Next Generation Internet SoSe03 136
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
Next Generation Internet SoSe03 137
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!
Next Generation Internet SoSe03 138
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
Next Generation Internet SoSe03 139
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.
Next Generation Internet SoSe03 140
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
Next Generation Internet SoSe03 141
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
Next Generation Internet SoSe03 142
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
Next Generation Internet SoSe03 143
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
Next Generation Internet SoSe03 144
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.
Next Generation Internet SoSe03 145
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
Next Generation Internet SoSe03 146
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.
Next Generation Internet SoSe03 147
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
Next Generation Internet SoSe03 148
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”.
Next Generation Internet SoSe03 149
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)
Next Generation Internet SoSe03 150
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)
Next Generation Internet SoSe03 151
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
Next Generation Internet SoSe03 152
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
Next Generation Internet SoSe03 153
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>
Next Generation Internet SoSe03 154
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
Next Generation Internet SoSe03 155
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!
Next Generation Internet SoSe03 156
VoIP Measurements: Test Sites
Cooperating Sites in 1999Cooperating Sites in 2002
Next Generation Internet SoSe03 157
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
Next Generation Internet SoSe03 158
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
Next Generation Internet SoSe03 159
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