Voice over IP --- Eine Einführung

Voice over IP — Eine Einführung
Marcus Fey
Technische Universität Chemnitz
1. Februar 2006
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
1 / 42
Inhalt
1
Einführung
2
Codecs
3
Transportprotokoll
4
Signalisierungsprotokoll und Auskunftsdienst
5
Das RTP-NAT-Problem
6
Nicht behandelte Punkte
7
Diskussion
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
2 / 42
Inhalt
1
Einführung
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
3 / 42
Zutaten für Voice-over-IP
Physische Zutaten
“kompatible” Endgeräte (IP-Telefon, PC)
“geeignete” Netzwerkverbindung
Logische Zutaten
Möglichkeit, Sprache zu kodieren/komprimieren → Codec
Möglichkeit, kodierte Daten zu übertragen → Transportprotokoll
Möglichkeit, das Ziel-Gerät zu finden und zu erreichen →
Signalisierungsprotokoll/Auskunftsdienst
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
4 / 42
Inhalt
2
Codecs
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
5 / 42
Codecs: Sprachkodierung und -kompression
Abtastwert-orientierte Kodierung: Pulse Code Modulation (PCM)
“dumme” Sprachkodierung ⇒ relativ hohe Bitraten nötig
hohe maximal erreichbare Qualität
segmentorientierte Kodierung: Linear Prediction Coding (LPC)
Eingangssignal wird in Segmente geteilt betrachtet
berücksichtigt Sprachentstehung (Effekte von Kehlkopf,
Mundhöhle)
bei gleicher Qualität geringere Bitraterate nötig
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
6 / 42
Vergleich Audiocodecs
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
7 / 42
Inhalt
3
Transportprotokoll
RTP im Detail
RTCP im Detail
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
8 / 42
Transportprotokoll
Anforderungen
einfacher (schneller) Transport und Verarbeitung der Datenpakete
Isochronität: zeitlich korrekte Verarbeitung
Nutzlast muss spezifizierbar sein (Medientyp und Codec)
Übertragungsrate entsprechend der Netzwerkbedingungen
anpassen
Unnötig
Quittierung von Paketen, erneute Übertragung wäre zu langwierig
Lösung
Real-Time Transport [Control] Protocol (RT[C]P)
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
9 / 42
Konzepte von RTP/RTCP
Definition
RFC 3550 (aktuell)
Bestandteile
RTP
zum Transport der Daten selbst
Daten werden in virtuellem Media Channel übertragen
RTCP
zur Kontrolle und Steuerung der Datenübertragung
festlegen der Datenrate
Informationen zur Übertragungsqualität
Daten werden in virtuellem Media Control Channel übertragen
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
10 / 42
RTP im Detail
“Sub”-Transportprotokoll: UDP
kein Quittungsbetrieb
keine automatische Flusskontrolle
keine Garantie der Unversehrheit der Daten (CRC o.ä.)
⇒ nur Empfänger bemerkt gestörten Datenstrom (Paketverlust,
Verzögerungen, etc.)
Verbindung findet in sog. Sessions statt (Client-Server Prinzip)
Serverport wird zufällig bestimmt, d.h.
Sender muss über Nummer informiert werden
Problem für Firewalls/NAT
verschiedene Datenströme können zusammengeführt (gemixt)
oder übersetzt werden
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
11 / 42
Header von RTP-Paketen
Payload Type → Codec
Sequence Number & Timestamp → Isochronität und
Empfangspuffergröße
Synchronization Source Identifier (SSRC) → Sender-“Gerät”
optional: Contributing Source Identifier (CSRC) (bei Mixereinsatz)
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
12 / 42
Einsatz von Mixern bei RTP
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
13 / 42
RTCP im Detail
Empfänger und Sender
tauschen sich mit z.B. Sender
bzw. Receiver Reports aus
immer mehrere RTCP-Pakete
in einem UDP-Paket
Auswahl möglicher
Pakettypen:
Sender Report (SR) (s.u.)
Receiver Report (RR) (s.u.)
Application Defined Packets
(APP)
BYE
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
14 / 42
Receiver und Sender Reports
Receiver Report:
Übertragungsdaten aus
Sicht des Empfängers
Sender Report:
Übertragungsdaten aus
Sicht des Senders/Mixers
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
15 / 42
Inhalt
4
Signalisierungsprotokoll und Auskunftsdienst
SIP
H.323
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
16 / 42
Signalisierungsprotokoll und Auskunftsdienst
Anforderungen
Sender (Anrufer) muss Empfänger “finden” können, weiß nur
“nichttechnische” Daten (also Name/“mobile” Adresse)
muss Port für RTP-Übertragung übermitteln
Audio-/Video-Codecs müssen ausgehandelt werden
Zwei mögliche Lösung
Session Initiation Protocol — SIP
H.323-Framework
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
17 / 42
Allgemeines zu SIP
von IETF spezifiziert ⇒ Ursprung: IP-Netzwerke und -Protokolle
Protokoll zur Übertragung von Daten zum Aufbau einer
RTP-Session
an HTTP/SMTP angelehnt ⇒ textbasiert, zeilenorientiert
normalerweise Transport über UDP, Server auf Port 5060
empfiehlt Session Description Protocol (SDP) zur Beschreibung
der RTP-Session (→ Nachrichteninhalt)
SIP-Namen ähnlich E-Mail-Adressen ⇒ Domain-basiert ⇒
Einsatz von z.B. DNS oder LDAP
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
18 / 42
Einfache Signalisierung eines Anrufs mit SIP
1
2
3
4
Anrufer (A) kennt Rechner von Empfänger (B)
A schickt SIP-Request (INVITE) an B
ist B erreichbar, wird RINGING zu A geschickt
nimmt B Anruf entgegen, wird OK gesendet, A bestätigt (ACK)
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
19 / 42
Weiterer Verlauf des Anrufs
5
6
7
zunächst RTP-Verbindungsaufbau
während des Anrufs: eventuell SIP re-INVITE-Request
Anrufende:
SIP-Request zur Signalisierung des Anrufendes
RTCP-Nachricht zum Abbau der Verbindung
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
20 / 42
Bestandteile einer SIP-Architektur
Endgeräte: SIP-Telefon oder Computer
Proxy-Server: Kontaktieren des Anrufziels durch “Durchschleifen”
der Anfrage (s.u.)
Redirect-Server: Finden des Anrufziels durch Rückgabe von
Zusatzinformationen (s.u.)
Location-Server/Registrar
ordnet einer SIP-Adresse den Namen des aktuell benutzen
Rechners zu
oft Modul des Proxy-/Redirect-Servers
implizit: Domain Name Server
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
21 / 42
Signalisierung mit Proxy-Server
1
2
3
4
Anrufer sendet SIP-Request (INVITE) an SIP-Server
Proxy befragt Location Server nach Rechner zu SIP-Adresse
eingegangenen SIP-Request bearbeiten: eigene Adresse als
Zwischenstation (Via) eintragen, dann an Zielrechner senden
SIP-Response (und alle weitern SIP-Nachrichten) durchleiten
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
22 / 42
Signalisierung mit Redirect-Server
1
Anrufer sendet SIP-Request (INVITE) an SIP-Server
2
Redirect-Server befragt LS nach Rechner zu SIP-Adresse
3
SIP-Response an Sender des INVITE: Standort des Ziels
4
Sender bestätigt mit ACK an Redirect-Server
5
Sender schickt neuen SIP-Request direkt an Rechner des
Anrufziels
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
23 / 42
Beispiel: Header eines SIP-Requests
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
24 / 42
Request Methods und Response Codes
einige Request Methods
INVITE: Anrufinitialisierung
BYE: Verbindungsabbau beginnen
ACK: Bestätigung
REGISTER: Registrierung eines Endgeräts beim Registrar
Response Code-Klassen: sehr ähnlich zu HTTP
1xx: Informational (z.B. “Trying”, “Ringing”)
2xx: Success (Request empfangen und akzeptiert)
3xx: Redirection (z.B. “Moved Permanently”, “Moved Temporarily”)
4xx: Client Error (Fehler bei Anfrage des Clients)
5xx: Server Error (Server kann Request nicht ausführen)
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
25 / 42
Session Description Protocol — SDP
v-Zeile: Angabe der SDP-Version (z.B. v=0)
o-Zeile (owner): Angabe zu Initiator
s-Zeile (subject): Name der Session
m-Zeile (media): Beschreibung der Übertragungsdaten
a-Zeile (attribute): Spezifizierung einer vorherigen Zeile
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
26 / 42
Voice over IP nach H.323-Standard
ITU-T-Standard ⇒ Wurzel: Telekommunikation
“klassisches” Protokoll
H.323 bildet Framework für VoIP-Standards und legt deren
Zusammenarbeit fest (H.225/245, TCP/IP, RTP)
Gatekeeper kontrolliert Endgeräte (müssen sich registrieren,
Bandbreite anfordern, etc.)
Signalisierung über H.225 bzw. H.245
binäres Protokoll
stark an klassisches Telefonsystem angelehnt (z.B. Verwendung
des ISDN-Protokolls)
VoIP-Gateway zur Verbindung mit Telefonnetz möglich
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
27 / 42
H.323-Systemkomponenten
Endgeräte (Telefon, PC)
Gatekeeper (GK)
kontrolliert Endgeräte einer H.323-Zone
Abbildung von generischen Adressen auf IPs
prüft Nutzungsberechtigung für Bandbreite
IP-Domains werden über Border Elements (BE) verbunden
TRIP bzw. H.225 Annex G zum Austausch der Anrufziele (ähnlich
BGP-4)
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
28 / 42
Verbindungsverlauf
Voraussetzung: Terminals
per RAS registriert
Anrufverlauf
Gatekeeper muss
Anruf genehmigen ⇒
kann Bandbreite
reservieren (RSVP)
H.225 überträgt Daten
zur H.245-KanalEinrichtung
H.245 überträgt Daten
zur RT(C)P-KanalEinrichtung
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
29 / 42
Inhalt
5
Das RTP-NAT-Problem
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
30 / 42
Das RTP-NAT-Problem
In vielen privaten Netzwerken NAT im Einsatz
Router verändert IP-Paket bei Verlassen des privaten Netzes
(ersetzt Absende-IP und -Port)
Problem für SIP/RTP:
in SIP-Nachricht (Anwendungsschicht) steht private Absender-IP
und RTP-Port
Antwort auf SIP-Nachricht an private IP des Senders ⇒ nicht im
öffentlichen Netz geroutet
Lösungsvariante: STUN (Simple Traversal of User Datagram Protocol
Through Network Address Translators)
1
SIP-Endgerät erfragt öffentliche IP von STUN-Server im Internet
2
in SDP wird öffentliche IP und Port eingetragen
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
31 / 42
STUN am Beispiel
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
32 / 42
Inhalt
6
Nicht behandelte Punkte
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
33 / 42
Nicht behandelte Punkte
Gateways: MGCP, Megaco
Vernetzung mit Telefonnetz / TK-Anlagen: TRIP, ENUM
Sicherheitsaspekte
SRTP/SRCTP
bei der Signalisierung
QoS-Aspekte: Queueing, Subnetzbildung
Firewall-Kompatibilität
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
34 / 42
Inhalt
7
Diskussion
Details und Beschränkungen von STUN
Einsatz von Asterisk
Abrechenbarkeit von VoIP-Gesprächen
Codecwechseln
Implementierung von RTP/RTCP
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
35 / 42
Dem Vortrag folgende Diskussion
Nach dem Vortrag wurden folgende Fragen diskutiert:
Details und Beschränkungen von STUN
Einsatz von Asterisk
Abrechenbarkeit (“Billing”) von VoIP-Gesprächen
automatischer Codecwechseln bzw. Reaktionen des Gatekeepers
auf Netzwerkauslastung
Umfang der Implementierung und Nutzung der Fähigkeiten von
RTP/RTCP
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
36 / 42
Details und Beschränkungen von STUN
Funktionsweise von STUN
1
SIP-Endgerät im privaten Netz schickt STUN-Nachricht an
STUN-Server im öffentlichen Netz
2
STUN-Server meldet SIP-Endgerät dessen öffentliche IP-Adresse
und den (aktuell genutzten) öffentlichen Port
3
SIP-Endgerät trägt diese Adresse-/Port-Kombination in SDP-Teil
des SIP-INVITE ein (die im privaten Netz eigentlich falsch wären)
Beschränkungen von STUN: Nicht alle NAT-Typen kompatibel
Zitat aus RFC 3489 (STUN):
In particular, STUN does not enable incoming UDP packets
through symmetric NATs (defined below), which are common
in large enterprises.
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
37 / 42
Einsatz von Asterisk
Telefonanlagensoftware, die in H.323- und SIP-Netze sowie
herkömmliche Telefonanlagen integriert werden und dazwischen
vermitteln kann
Überbrückung von NAT mit Asterisk
1
Anrufer sendet SIP-INVITE an Anrufziel
2
Asterisk-Server (am Ausgang des privaten Netzes) fängt INVITE
ab und sendet eigenes SIP-INVITE an Anrufziel
3
Anrufziel meldet vorhandene Codecs an Asterisk-Server
4
wenn Codecs kompatibel, sendet Asterisk-Server RE-INVITE an
Anrufer und Anrufziel (mit zu verwendendem Codec)
5
beide RTP-Übertragungen (Anrufziel → Anrufer und
Anrufer → Anrufziel) gehen beim Asterisk-Server ein, dieser leitet
RTP-Pakete an eigentliche Ziele weiter
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
38 / 42
Abrechenbarkeit von VoIP-Gesprächen
wahrscheinliche Entwicklung: traditioneller Telefonanschluss wird
durch VoIP ersetzt werden
⇒ Verlust von Einnahmequellen für Telefonanbieter
⇒ möglicherweise Versuch der Erhebung von Gebühren auf
VoIP-Übertragung durch Internet-Provider (oftmals gleichzeitig
Telefonanbieter)
Gegenargument: Internet-Provider mit VoIP-Gebühren im hart
umkämpften Markt nicht konkurrenzfähig
Option: Internet-Provider sperrt “klassische” VoIP-Ports (allerdings
existieren auch Maßnahmen dagegen)
mögliche endgültige Situation: Flatrate für Sprachtelefonie
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
39 / 42
Automatische/erzwungene Codecwechsel
kleine Änderungen der Sprachkodierung sind ohne Signalisierung
auf RTP-Ebene möglich (z.B. Umschalten zwischen µ-Law und
A-Law bei G.711 durch ändern des Payload-Types)
bei H.323 nutzen Gatekeepers den Zwang zur Anmeldung einer
Übertragung zur Reservierung von Bandbreite und damit zur
Garantie einer Quality of Service für bestehende Verbindungen
es konnte nicht geklärt werden, ob in der Praxis bestehenden
Verbindungen zum Wechseln zu Codecs mit einer geringeren
Datenrate gezwungen werden
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
40 / 42
Implementierung von RTP/RTCP
viele SIP-Telefone bzw. VoIP-Programme nutzen RTCP nur zur
Signalisierung des Verbindungsabbaus (BYE)
Felder des RTP-Header werden oft ignoriert
manche Programme gehen von einer festen Größe von 12 Byte
des RTP-Headers aus, damit würden CSRC-Felder
fälschlicherweise als Nachrichteninhalt interpretiert
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
41 / 42
Bibliographie I
Badach, Anatol (2005).
Voice over IP: Die Technik.
2. überarbeitete und erweiterte Auflage.
München/Wien: Carl Hanser Verlag.
Khasnabish, Bhumip (2003).
Implementing Voice over IP.
Lexington: Wiley.
Nölle, Jochen (2003).
Voice over IP: Grundlagen, Protokolle, Migration.
Berlin/Offenbach: VDE Verlag.
Perkins, Colin (2003).
RTP: Audio and Video for the Internet.
Upper Saddle River: Addison-Wesley Professional.
Marcus Fey (TU-Chemnitz)
Voice over IP — Eine Einführung
1. Februar 2006
42 / 42