Inhaltsverzeichnis - Universität Osnabrück

Transcription

VoIP
Thomas Leutermann
Universität Osnabrück
Die Ausarbeitung zum Thema Voice over IP stellt die Grundlagen und wesentlichen verwendeten
Protokolle dar. Zusätzlich wird kurz auf die Entstehung und die aktuellen Einsatzgebiete
eingegangen.
Inhaltsverzeichnis
1 Einführung................................................................................................................................................. 2
2 Entstehung und Organisationen.............................................................................................................. 3
3 Protokolle und Standards im Überblick..................................................................................................
3.1 Digitalisierung und Codierung............................................................................................................
3.2 Transport der digitalen Sprachdaten..................................................................................................
3.2.1 Real-Time Transport Protocol...................................................................................................
3.2.2 Real-Time Transport Control Protocol......................................................................................
3.3 Protokolle zur Signalisierung.............................................................................................................
3.3.1 Session Initiation Protocol........................................................................................................
3.3.2 SIP Proxy-Mode und Redirect-Mode........................................................................................
3.3.3 SIP-Nachrichten.......................................................................................................................
3.4 Ablaufsteuerung zwischen verschiedenen Netzen............................................................................
3.5 Telefonnummern-Systematik und Internet-Adressierung...................................................................
5
6
7
9
10
12
13
13
14
16
18
4 Schlussbetrachtung.................................................................................................................................. 20
5 Literaturverzeichnis und Web-Links........................................................................................................ 21
6 VoIP Diensteanbieter................................................................................................................................. 22
7 Anlagen...................................................................................................................................................... 23
1 Einführung
2
1 Einführung
Voice over Internet Protocol, Voice over IP oder kurz VoIP ermöglicht eine Sprachkommunikation über das
Internet bzw. über Netze, die das Internet Protocol nutzen.
Sprachkommunikation bedeutet, dass Nutzer miteinander interagieren, so dass eine Übertragung in Echtzeit
erfolgen muss. Außerdem soll, wie in der klassischen Welt der Telefonie, jeder Nutzer mit einem Netzzugang
prinzipiell mit jedem andern Nutzer eine Verbindung aufnehmen können. Dem entsprechend sind die
Anforderungen, die an die Vermittlung einer Verbindung und an die Übertragung eines Gespräches gestellt
werden, im digitalen, Datenpakete versendende Internet zu realisieren.
Der folgende Beitrag gibt einen Überblick über die Entstehung, die notwendigen Protokolle und Standards und
die technischen Realisierungen von VoIP. Außerdem soll kurz auf die Nutzung und auf aktuelle Entwicklungen
eingegangen werden.
2 Entstehung und Organisationen
3
Die Anfänge des Telefonierens über Datennetze liegen in der Übertragung von Sprache im Arpanet (Advanced
1
Research Projects Agency Network), dem Vorfahrendes Internets, mittels Network Voice Protocol (NVP) [1] ,
2
das 1973 entwickelt und 1977 in dem Request for Comments 741 (RFC 741) [2] festgelegt wurde. Das NVP
stellt damit den Vorläufer der VoIP-Protokollfamilie dar, hat aber heute keine Bedeutung, obwohl es im Internet
Protocol mit der Protokollnummer 11 (NVP-II) geführt wird.
Die Entwicklung des Arpanet zum Internet und dessen nach und nach entstandenen Protokolle bilden heute
die Grundlage für verschiedenste Dienste. Zunächst war nur die reine Datenkommunikation und die Robustheit
der Datenübertragung gegenüber Störungen und dem Ausfall von Teilen des Übertragungsnetzes wichtig.
1980 (aktualisiert 1981) wurden die wichtigsten dieser Protokolle veröffentlicht:
• User Datagram Protocol (UDP), RFC 768 (1980) [3]3
• Internet Protocol (IP), RFC 791 IPv4 (1981) [4]4
• Transmission Control Protocol (TCP), RFC 793 (1981) [5]5
+------+ +-----+ +-----+
+-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+
+-----+
|
|
|
|
+-----+
+-----+
+-----+
| TCP |
| UDP | ... | ... |
+-----+
+-----+
+-----+
|
|
|
+--------------------------+----+
|
Internet Protocol & ICMP
|
+--------------------------+----+
|
+---------------------------+
|
Local Network Protocol |
+---------------------------+
Protocol Relationships
Abbildung 1: Übersicht aus IPv4, RFC 791
Im gleichen Jahr wurde auch die ITU-T-Empfehlung (damals noch CCITT) für ISDN verabschiedet, die ebenfalls
prägend für die weitere Entwicklung sein sollte.
Die nächsten Schritte wurden getan mit dem Real-Time Transport Protocol (RTP) (1996 als Protokoll zur
Echtzeitkommunikation im RFC 1889; seit 2003 RFC 3550), dem ITU-T-Rahmenwerk H.323 u.a. zur
Signalisierung (1998), dem Session Initiation Protocol (SIP) (1999 im RFC 2543) als eine Alternative zur
Signalisierung im H.323 ITU-Standard sowie mit der SIP-Erweiterung im RFC 3261 in 2002 und dem Standard
ITU Q.1912.5 für die Interoperabilität zwischen SIP und ISDN User Part. Damit waren die wichtigsten Grundlagen
gelegt, um auch die Übertragung von Sprache/Audio und Video in einem datenpaketvermittelnden Netz zu
ermöglichen.
Nach einem kleinen Zwischenhoch des Interesses an der Thematik auf Basis von H.323 um das Jahr 2000
herum, kam es zu einem großen Interesse ab 2004, wo sich VoIP im Consumer-Bereich als Massenbewegung
etablierte. Treibend war der Erfolg des Unternehmens Skype, dem viele weitere Anbieter, u.a. auch klassische
1 http://en.wikipedia.org/wiki/Network_Voice_Protocol
2 http://tools.ietf.org/html/rfc741
4
Telekommunikationsunternehmen folgten. Als Signalisierungs-Protokoll kommt hier seit dem vor allem SIP
6
zum Einsatz. [6]
Die Entwicklung im Business-Bereich war geprägt durch das Bestreben Kosten zu senken und die Effizienz
zu steigern. Nachdem in den meisten Unternehmen die lokale Rechnervernetzung (LAN) und die Nutzung des
Internets gängig war, wurden einerseits die lokalen TK-Anlagen mit dem LAN verbunden und andererseits eine
Standortvernetzung über das Internet betrieben. Neben den deutlich verringerten Verbindungsentgelten kam
die Effizienzsteigerung insbesondere durch die Computer Telephony Integration (CTI), also die Integration von
Sprachkommunikation, Email, Web, Fax, usw. und das Call Routing innerhalb von bzw. zwischen
Firmenstandorten. Die Möglichkeit die Sprach- und auch Videokommunikation gänzlich auf die IP-Basis zu
verlagern und die alten TK-Netze zu ersetzen wird seither zunehmend genutzt und ermöglicht auch kleinen
Unternehmen den standortübergreifenden, globalen Einsatz. Häufig verschwimmen hier die Grenzen der
Consumer- und Business-Angebote, die VoIP als Grundlage haben.
Die aktuelle Entwicklung geht hin zu konvergenten Netzwerken, in denen VoIP aufgeht. Die Schlagworte sind
Multimedia-Kommunikation, Triple- und Quad-Play (Fernsehen, Telefonieren und Internet sowie Mobilfunk),
All-IP-Network bzw. Next Generation Network (NGN) und IP Multimedia Subsystem (IMS) sowie der Wandel
der klassischen Telekommunikationsunternehmen hin zu Content Service Providern.
Als Organisationen, die die Entwicklung begleiteten und auch heute im wesentlichen noch steuern sind besonders
zu nennen
• Internet Engineering Task Force (IETF) 7, die u.a. die Internet Drafts (ID) - Vorschläge für einen neuen
oder erweiterten Internet-Standard - diskutiert und ggf. als Request for Comments (RFC) - Internet-Standard
8
- heraus gibt. Die Arbeiten werden in so genannten Working Groups durchgeführt.
• International Telecommunication Union, mit der Abteilung Telecommunication Standardization Sector
9
(ITU-T) , die mit ihren Study Groups weltweite Standards zur Technik und Tarifierung in der
Telekommunikation festlegt.
• European Telecommunication Standards Institute (ETSI) 10, zuständig für die Standards und Normen in
der Informationstechnik und Telekommunikation auf europäischer Ebene. Die Arbeit ist in Technical Bodies
(Technical Committee, ETSI Project und ETSI Partnership Project) organisiert.
6 http://de.wikipedia.org/wiki/VoIP
7 http://www.ietf.org/
8 weiteres zur Organisation IETF in 'The TAO of IETF', http://tools.ietf.org/html/rfc4677
9 http://www.itu.int/ITU-T
10 http://www.etsi.org/
3 Protokolle und Standards im Überblick
5
Neben den bereits genannten wichtigsten Protokollen und Standards gibt es weitere Standards für die
Übertragung und Vermittlung, die sich mit den Themen
•
•
•
•
•
Digitalisierung und Codierung der analogen Sprachsignale,
Transport der digitalen Sprachdaten,
Signalisierung für den Auf- und Abbau und die Steuerung einer Verbindung,
Ablaufsteuerung zwischen verschiedenen Netzen und
Verbindung der Telefonnummern-Systematik mit der Internet-Adressierung
beschäftigen.
Außerdem sind Anforderungen an die Qualität der Übertragung vom Sender an den Empfänger zu
berücksichtigen, um eine ausreichende Sprachverständlichkeit zu erreichen, die sich an der Qualität
herkömmlicher analoger und digitaler Telefonverbindungen messen lassen muss. VoIP ist eine isochrone
Verbindung, d.h. es müssen gleiche Zeitabstände zwischen den Datenpaketen auf Sende- und Empfangsseite
11
gegeben sein. Die wichtigsten Parameter der Quality of Service (QoS), die die Isochronität beeinflussen sind :
• Bandbreite des Übertragungsweges - hier muss eine definierte Mindestbandbreite gegeben sein
• Ende-zu-Ende-Verzögerung (Delay) - Zeit, die ein Signal vom Sender zum Empfänger benötigt; eine Laufzeit
der Signale zwischen 150 ms bis 300 ms oder niedriger wird als ausreichen angesehen, über 300 ms ist
nicht mehr akzeptabel
• Schwankungen der Übermittlungszeit (Jitter) - kann durch einen Jitter-Buffer ausgeglichen werden
• Paketverluste (Packet Lost Rate) - vereinzelte Paketverluste stellen noch kein Problem dar, Häufungen
führen zu störenden Unterbrechungen
Zur Orientierung für die weiteren Beschreibungen hier die Darstellung der verwendeten Protokolle und Standards
12
für VoIP in einem Bild, die die Beziehungen und Abhängigkeiten veranschaulichen.
11 vgl. Badach 2007, S. 99 ff.
12 Anmerkung: Die Abkürzungen in dem Bild sowie die konkreten Abhängigkeiten werden in den nachfolgenden Kapiteln erläutert.
6
Abbildung 3.1: Übersicht VoIP-Protokolle
In den nachfolgenden Kapiteln wird eine Übersichten der Standards gegeben. Ist eine Zuordnung in das vier
Schichten umfassende TCP/IP möglich, so wird diese mit angegeben. In der nachfolgend Tabelle werden die
13
Schichten kurz beschrieben.[1]
TCP/IP model - DoD model
4. Application layer/ Die Anwendungsschicht umfasst alle Protokolle, die mit
Process layer
Anwendungsprogrammen zusammenarbeiten und die
Netzwerkinfrastruktur für den Austausch
anwendungsspezifischer Daten nutzen.
3. Transport layer/ Die Transportschicht stellt eine Ende-zu-Ende-Verbindung
host-to-host layer (host to host) her.
2. Network layer/
Die Vermittlungsschicht ist für die Weitervermittlung von
Internet layer
Paketen und die Wegewahl (Routing) zuständig. Auf dieser
Schicht und den darunter liegenden Schichten werden
Punkt-zu-Punkt-Verbindungen betrachtet. Die Aufgabe
dieser Schicht ist es, zu einem empfangenen Paket das
nächste Zwischenziel zu ermitteln und das Paket dorthin
weiterzuleiten.
1. Network access Die Netzwerkschicht ist im TCP/IP-Referenzmodell
layer
spezifiziert, enthält jedoch keine Protokolle der
TCP/IP-Familie. Sie ist vielmehr als Platzhalter für
verschiedene Techniken zur Datenübertragung von Punkt
zu Punkt zu verstehen. Die Internet-Protokolle wurden mit
dem Ziel entwickelt, verschiedene Subnetze
zusammenzuschließen. Daher kann die
Host-an-Netz-Schicht durch Protokolle wie Ethernet, FDDI,
PPP (Punkt-zu-Punkt-Verbindung) oder 802.11 (WLAN)
ausgefüllt werden.
Tabelle 3.1: TCP/IP Schichten-Modell
3.1 Digitalisierung und Codierung
Die Umsetzung und Aufbereitung der Sprachsignale in eine digital übertragbare Form kann mit einer Vielzahl
an Verfahren durchgeführt werden. Entscheidend für die Auswahl ist der Frequenzumfang des Ursprungssignals,
die gewünschte Qualität auf der Empfängerseite und die Bandbreite des Übertragungsweges.
Man unterscheidet bei der Sprachcodierung nach (a) Abtastwert-orientierten (sample-based) und (b)
Segment-orientierten (frame-based) Verfahren. Im ersten Fall erfolgt eine Abtastung des analogen Sprachsignals
mit einer Abtastrate von meist 8 kHz und einer anschließenden linearen oder nichtlinearen Quantisierung und
Codierung. Auf der Empfängerseite werden die Abtastsignale decodiert, regeneriert und mittels Tiefpassschaltung
geglättet.
14
Übersicht der wichtigsten internationalen CODEC Spezifikationen [1] [2]
Codec
G.711
Name
15
Transfer Rate Frequency Quality /
MOS
Pulse Code Modulation (PCM)\ 56 o. 64 kbit/s 300 bis
ISDN / 4.3
A-law and µ-law (a)
3400 Hz
13 http://en.wikipedia.org/wiki/TCP/IP_mode
14 http://www.itu.int/rec/T-REC-G/e
15 http://www.xten.de/
7
G.726
Adaptive Differential Pulse Code 16 - 40 kbit/s
Modulation (ADPCM) (a)
G.728
Low Delay Code Excited Linear 16 kbit/s
Prediction (LD-CELP) (b)
G.729/
Conjugate Structure Algebraic 8 kbit/s
G.729A
Code Excited Linear Prediction
(CS-ACELP) (b)
G.723.1
Multiple Maximum Likelihood 6,3 kbit/s
Quantization (MPMLQ) (b)
G.723
Algebraic Code Excited Linear 5,3 kbit/s
Prediction (ACELP) (b)
Speex
Free patent audio compression 4 - 15 kbit/s
Narrow-band (free), \ Code Excited Linear
Prediction (CELP) (b)
Speex\\\
Free patent audio compression 10 - 28 kbit/s
Wide-band (free), \ Code Excited Linear
Prediction (CELP) (b)
DVI4
Adaptive Differential Pulse Code 32 kbit/s
Modulation (ADPCM) (a)
iLBC
Internet Low Bit Rate Codec 13,3 kbit/s
(free) (b)
G.722.1
MLT
24 kbit/s
l16 PCM
Linear PCM at 16 bits per
128 kbit/s
sample (a)
EVCR
Enhanced Variable Rate Codec, 8 kbit/s
Relaxed Code Excited Linear
Prediction (RCELP) (b)
H.263
Videocodec Discrete Cosine 16-256 kbit/s
Transformation (DCT)
H.261
Videocodec DCT
64-256 kbit/s
-
/ 3.8
300 bis
3400 Hz
300 bis
3400 Hz
nearly
ISDN / 3.6
/ 3.9, 3.7
300 bis
3400 Hz
-
/ 3.9
8 kHz
medial
GSM
/ 3.6
16 - 32 kHz better GSM
8 kHz
-
8 kHz
/ 4.1
16 kHz
-
-
-
-
-
medium
-
low
Tabelle 3.2.: Digitalisierung und Codierung
Bei dem Segment-orientierten Verfahren wird das Sprachsignal in Abschnitten von 10 bis 30 ms nach
verschiedenen Kriterien analysiert, die u.a. die stimmhaften und stimmlosen Laute der menschlichen Sprache
charakterisieren. Nach der Codierung, der Übertragung und Decodierung auf der Empfängerseite wird das
Sprachsignal synthetisch mittels eines LPC-Vocoders (Linear Predictive Coding) zurückgewonnen, der akustisch
den menschlichen Vokaltrakt nachbildet.
Die Ausgangs-Sprachqualität wird im so genannten Meaning Opinion Score (MOS) angegeben in einer Skala
von
16
1 = bad, 2 = poor, 3 = fair, 4 = good und 5 = excellent.
Im RFC 3551 wird konkret angegeben, welche Codec-Verfahren zum Einsatz kommen können.[3]
17
Für eine effiziente Übertragung von Videodaten kommen ebenfalls Codierungsverfahren zum Einsatz, auf die
hier jedoch nicht weiter eingegangen wird.
3.2 Transport der digitalen Sprachdaten
Zur Übertragung von Daten für Echtzeitanwendungen in datenpaketvermittelnden Netzen, wie dem Internet,
sind Protokolle erforderlich, die möglichst geringe Übertragungszeiten und Isochronität, also den gleichen
16 vgl. Badach 2007, S. 133 ff.
8
zeitlichen Ablauf bei Sender und Empfänger sichern. In der Funktion wird dabei unterschieden nach Protokollen
für die Datenübermittlung selbst und für die Kontrolle und Absicherung der Übermittlung bzw. der
Übertragungsqualität.
Bei den Transportprotokollen wird zwischen verbindungsorientierten, verbindungslosen und gemischten
Protokollen unterschieden.Verbindungsorientierte Protokolle wie TCP ermöglichen eine gesicherte Übertragung,
da eine virtuelle Verbindung aufgebaut wird und empfangene Daten quittiert werden. Verbindungslose Protokolle
wie UDP übermitteln verbindungslos Daten und erhalten keine Bestätigung, ob diese angekommen sind. Ein
Beispiel für ein gemischtes Protokoll ist das Domain Name System (DNS), das in einem nachfolgenden Kapitel
18
kurz erläutert wird.
Protokoll Beschreibung
RFC
RTSP
Real-Time Transport Streaming Protocol (Application Layer) RFC 2326
initiiert und kontrolliert einen oder mehrere zeit-synchrone
Datenströme für Audio und Video. Die eigentliche
Datenübertragung erfolgt meist über RTP.
RTCP
Real-Time Transport Control Protocol (Application Layer) RFC 3550
Da RTP keine Empfangsquittierung hat, wird als
Monitoringprotokoll RTCP eingesetzt, indem Reports
ausgetauscht werden, um die Qualität der
Sprachübermittlung zu überwachen.
RTP
Real-Time Tranport Protocol (Transport Layer) zur
RFC 3550,
Übertragung von Sprache/Audio und Video in Echtzeit. Mit 3551
dem Dokument RTP Profile for Audio and Video
Conferences with Minimal Control" (RTP A/V Profile) wird
eine Hilfe gegeben zur Implementierung von Audio, Video
und anderen Echtzeit-Multimediaanwendungen. Zusätzlich
existieren für RTP viele Spezifikationen zur Payload
(Medienformate der zu übertragenden Nutzdaten) und zur
Header Compression (Reduzierung der Größe des
Overhead, wie Compressed RTP (CRTP) und Robust
Header Compression (ROHC)).
RSVP
Resource Reservation Protocol (Transport Layer) dient zur RFC 2205,
Reservierung einer benötigten Bandbreite und der Ermittlung 2750, 3936,
der optimalen Route in IP-Netzen, um eine bestimmte
4495
Quality of Service (QoS) zu garantieren.
TCP
Transmission Control Protocol (Transport Layer) ermöglicht RFC 793,
eine gesicherte virtuelle Verbindung zwischen zwei
3168
Rechnern über Sockets (Internetadresse und TCP-Port).
UDP
User Datagram Protocol (Transport Layer) ermöglicht eine RFC 768
ungesicherte Übertragung mit wenig Overhead auf dem
Internet Protocol.
SCTP
Stream Control Transmission Protocol (Transport Layer) als RFC 3286,
verbindungsorientiertes Protokoll arbeitet ähnlich wie TCP. 4960
Es werden jedoch keine sequenzierte Byte-Streams
übertragen, sondern parallel mehrere Inbound- und
Outbound-Streams, die Nachrichten in s.g. Chunks
unidirektional an einen oder mehrere Endpunkte (IP-Adresse
und SCTP-Port) transportieren. Es können z.B. Signalisierungsprotokolle wie SS7 aus dem ISDN übertragen
werden und bietet einen Schutz vor Denial of
Service-Attacken.
IP
Internet Protocol (Network/Internet Layer) dient der
RFC 791
datenpaketvermittelnden Übertragung. Als
Kontrollmecha-nismus ist nur die Header Checksum
gegeben. Weitere Fehlerkontrollen können mit dem Internet
Control Message Protocol (ICMP) durchgeführt werden.
18 vgl. Badach 2007, S. 69
9
Tabelle 3.3: Protokolle für die Sprachübermittlung
Nachfolgend werden die Protokolle RTP und RTCP etwas näher betrachtet.
3.2.1 Real-Time Transport Protocol
Eine RTP-Session kann als ein logischer Media Channel (Übermittlungskanal) verstanden werden, in dem die
zu übertragenden Daten, die Payload enthalten ist. Daneben sind noch diverse Informationen im RTP-Header
angegeben, die die Reihenfolge der RTP-Pakte und die Isochronität garantieren sowie die Art der Payloadformate
und den Einsatz von Translator und Mixer regeln. Die Translatorfunktionalität ermöglicht die Umsetzung von
einem Payloadformat in ein anderes, der Mixer kann verschiedene Quellmedien in einer Payload
zusammenfassen.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
sequence number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
contributing source (CSRC) identifiers
|
|
(optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
header extension
|
|
(optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
payload (audio/video segment)
|
|
(optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 3.2: RTP Packet Format
19
20
21
Die Bedeutung der einzelnen Abschnitte im RTP-Paket bzw. im RTP Header [1] [2] :
• Version (V), 2 bits: RTP-Version
• Padding (P), 1 bit: gibt an, ob das Paketes für eine gewünschte Länge mit Bit-Oktetten aufgefüllt werden
muss, wie z.B. bei Verschlüsselungen
• Extension (X), 1 bit: weist auf eine Header Extension
• CSRC count (CC), 4 bits: gibt de Anzahl der Quell-Indikatoren an - siehe CRSC-List
• Marker (M), 1 bit: weist auf eine anwendungsspezifische Nutzlast
• Payload type (PT), 7 bits: Format der Nutzlast, spezifiziert durch eine feste Nummer (0 bis 95) oder durch
dyn" (96 bis 127) für eine dynamische Zuteilung in einer Session (Beispiele: 0: PCM µ/G.711, 4: G.723, 8:
PCM A/G.711, 31: H.261, 34: H.263)
• Sequence number, 16 bits: ist eine Nummer, die zufällig ausgewählt je weiterem RTP-Paket hochgezählt
wird, die Nummer kennzeichnet ein Paket und legt die Reihenfolge fest
• Timestamp, 32 bits: eine beliebig festgelegte Zeitmarke, die für die Synchronisation und zum Ausgleich von
Jitter (Schwankungen der Übertragungszeit) verwendet wird
• SSRC - Synchronised Source Identifiers, 32 bits: dient zur Unterscheidung der Synchronisationsquelle, von
der die Media-Daten stammen, damit der Empfänger diese richtig zuordnen kann
• CSRC - Contributing Source Identifiers, Liste möglich von 0 bis 15 zu je 32 bits: Angaben, wenn mehrere
Mediaquellen zusammengefasst/gemixt werden
• Header Extension: wird optional für neue Klassen von Anwendungen, also Nutzlast abhängig verwendet
• Payload: enthält die eigentlichen Mediadaten
19 vgl. Badach 2007, S. 149 ff.
10
22
Hier ein Beispiel für RTP-Paket aus einer RTP-Session :
Frame 276 (104 bytes on wire, 104 bytes captured)
Ethernet II, Src: UniwillC_3e:79:8a (00:03:0d:3e:79:8a), Dst:
ProcompI_fe:2b:f3 (00:30:95:fe:2b:f3)
Internet Protocol, Src: 192.168.62.51 (192.168.62.51), Dst:
eul0300290-pip.eu.verio.net (213.198.65.201)
User Datagram Protocol, Src Port: 5004 (5004), Dst Port: 6630 (6630)
Real-Time Transport Protocol
[Stream setup by SDP (frame 27)]
[Setup frame: 27]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: iLBC (102)
Sequence number: 5184
[Extended sequence number: 70720]
Timestamp: 1682251140
Synchronization Source identifier: 0x35825f05 (897736453)
Payload: 7899AF945B63EEACF743073C3B591F00740F68B41980BEA1...
Text 3.1: Beispiel RTP-Paket
Das Beispiel zeigt neben dem RTP-Paket auch die umgebenden Protokollebenen UDP, IP und Ethernet mit
Angaben zu den IP-Adressen und den genutzten Ports. Wie zu sehen ist, erfolgte hier ein Sprachkommunikation
mit dem Internet Low Bit Rate Codec. Das Netzwerk-Analyse-Tool mit dem die VoIP-Session beobachtet wurde,
zeigt an, welcher Signalisierungskanal, hier mit dem Session Description Protocol (SDP), die RTP-Session
steuert.
3.2.2 Real-Time Transport Control Protocol
Das RTCP hat als eine Art Reporting-Kanal für RTP verschiedene Typen von Kontrollinformationen, die als
Nummern im Protokollfeld Payload Type erscheinen.
• Sender report - SR (200): Übertragungs- und Empfangsstatistiken der beteiligten Quellen als Information für
den Empfänger, zur Einstellung auf die zu erwartende Qualität bzw. die notwendigen Ressourcen
• Receiver report - RR (201): Empfangsstatistik der tatsächlich empfangenen Datenqualität
SR- und RR-Datenpakete nach dem RTCP haben annähernd den gleichen Aufbau.
• Source description - SDES (202): Quellangaben mit textuellem Namen, um Daten einzelner Quellen
zusammenführen zu können.
• Anzeige des Endes - BYE (203)
• Applikationsspezifische Funktionen - APP (204)
Der Anfang der RTCP-Pakete hat einen festen Teil, der ähnlich aufgebaut ist wie die RTP-Datenpakete, gefolgt
von einem variablen Teil, der in jedem Fall mit einer 32-bit-Begrenzung abgeschlossen wird.
Zusammengefasst können folgende Aufgaben festgehalten werden, die Überwachung der Übertragungsqualität,
23
die Identifikation der Quelle und die Unterstützung der Mehrpunkt-Kommunikation.
22 Anmerkung: aufgenommen mit Wireshark Network Protocol Analyzer
23 vgl. Badach 2007, S. 158 ff.
[1]
24
11
Nachfolgend exemplarisch das SR-Format des RTCP-Datenpaketes und ein RTCP-Beispiel aus einer
RTP-Session, wobei, wie schon gesagt, schon einige Angaben in RTP-Paketen enthalten sind.
Angegeben sind in dem Paket unter anderem die Anzahl der Report-Blöcke - Reception report count (RC), die
Länge des RTCP-Paketes - length, ein Zeitstempel im Format Network Time Protocol (NTP).
Besonders wichtig ist der Pakettyp - PT, mit dem der jeweilige oben genannte Typ angegeben wird. Daneben
gibt es noch weitere hier nicht weiter genannte Typen.[2]
25
Im Report-Block sind noch eine Abschätzung des Jitters, eine Verlustquote von RTP-Paketen, der Fraction
Lost und eine Berechnung der Verzögerung, dem Round-Trip Delay.
header
sender
info
report
block
1
report
block
2
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|
RC
|
PT=SR=200
|
length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SSRC of sender
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
NTP timestamp, most significant word
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
NTP timestamp, least significant word
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
RTP timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's packet count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's octet count
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
SSRC_1 (SSRC of first source)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost |
cumulative number of packets lost
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
extended highest sequence number received
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
interarrival jitter
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
last SR (LSR)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
delay since last SR (DLSR)
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
SSRC_2 (SSRC of second source)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
...
:
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
profile-specific extensions
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 3.3: RTCP-Packet Sender Report SR
Im nachfolgenden Beispiel ist die Ähnlichkeit des RTCP-Paketes mit dem RTP-Paket zu sehen.
Frame 146 (122 bytes on wire, 122 bytes captured)
Ethernet II, Src: UniwillC_3e:79:8a (00:03:0d:3e:79:8a), Dst:
ProcompI_fe:2b:f3 (00:30:95:fe:2b:f3)
Internet Protocol, Src: 192.168.62.51 (192.168.62.51), Dst:
eul0300290-pip.eu.verio.net (213.198.65.201)
User Datagram Protocol, Src Port: 5005 (5005), Dst Port: 6631 (6631)
Real-time Transport Control Protocol (Sender Report)
[Setup frame: 27]
[Setup Method: SDP]
...0 0001 = Reception report count: 1
25 http://www.networksorcery.com/enp/protocol/rtcp.htm
26
12
Packet type: Sender Report (200)
Length: 12 (52 bytes)
Sender SSRC: 0x35825f05 (897736453)
Timestamp, MSW: 3403971859 (0xcae47d13)
Timestamp, LSW: 2550136832 (0x98000000)
[MSW and LSW as NTP timestamp: Nov 13, 2007 19:44:19,5938 UTC]
RTP timestamp: 1682220110
Sender's packet count: 68
Sender's octet count: 3400
Source 1
Identifier: 0x00000000 (0)
SSRC contents
Extended highest sequence number received: 0
Interarrival jitter: 0
Last SR timestamp: 0 (0x00000000)
Delay since last SR timestamp: 0 (0 milliseconds)
Real-time Transport Control Protocol (Source description)
[Setup frame: 27]
[Setup Method: SDP]
...0 0001 = Source count: 1
Packet type: Source description (202)
Length: 6 (28 bytes)
Chunk 1, SSRC/CSRC 0x35825F05
Identifier: 0x35825f05 (897736453)
SDES items
Type: CNAME (user and domain) (1)
Length: 17
Text: user@gizmoproject
Type: END (0)
[RTCP frame length check: OK - 80 bytes]
Text 3.2: Beispiel RTCP-Packet SR
3.3 Protokolle zur Signalisierung
Das Session Initiation Protocol hat für VoIP gegenüber dem Rahmenwerk H.323-SIG in den letzten Jahren
eindeutig die größere Bedeutung gewonnen. Daneben kommt es auch zunehmend in den neueren Ansätzen
Next Generation Network und IP Multimedia Subsystem zum Einsatz, so dass nur SIP ausführlicher dargestellt
werden soll.
RFC/ITU
H.323-SIG H.323 - ITU-T Recommendation Q.931 H.323 beschreibt H.323 H.225.0
H.225.0 das Zusammenwirken der Protokolle H.225.0, H.245 sowie H.245 Q.931
H.245
RTP und RTCP. H.225.0 entspricht der Schicht 2, also
der Sicherungsschicht des D-Kanal-Protokolls im ISDN
und wird über TCP geführt. H.225.0 beschreibt die
Rufsignalisierung, die Medien (Audio und Video), die
Umwandlung des Datenstroms in Pakete, die
Synchronisierung des Datenstroms und die Kontrolle des
Nachrichtenformats. H.245 beschreibt die Nachrichten
und Verfahrensweisen für das Öffnen und Schließen
logischer Kanäle, die zur Übertragung von Audio, Video
und Daten dienen; sowie den Austausch, die Kontrolle
27
SIP
und Anzeige der Übertragungskapazitäten.[1]
Session Initiation Protocol (Application Layer) SIP ist RFC 3261 bis
ein textbasierendes Protokoll ähnlich dem Hypertext
3265, 3853,
Transfer Protokoll (HTTP). In der Funktion entspricht SIP 4320, 4916
27 http://de.wikipedia.org/wiki/H.323
13
weitgehend dem D-Kanal-Protokoll im ISDN und kann
beliebige RTP-Sessions für beliebige Multimediaströme
mit einem oder mehreren Teilnehmern verwalten und
scheint sich zum Standard-Protokoll für Voice over IP
28
SDP
29
(VoIP) zu entwickeln. [2]
Session Desciption Protocol (Application Layer) SIP wird RFC 4566
unterstützt durch das Session Desciption Protocol (SDP)
zur Beschreibung von Multimediaströmen.
30
Tabelle 3.4.: Protokolle zur Signalisierung
3.3.1 Session Initiation Protocol
Die Signalisierung dient dem Auf- und Abbau und der Steuerung einer Verbindung. Eine SIP-Session stellt
damit einen logischen Kanal dar, der zusätzlich über eine Fehlerkontrolle verfügt, so dass im Regelfall auf UDP
aufgesetzt und hierdurch ein schneller Verbindungsaufbau erreicht werden kann.
Als Well-Known-Port wird 5060 angegeben. Häufig werden jedoch auch andere Ports benutzt, da vielen
Netzwerken eine Firewall bzw. Network Adress Translation (NAT) vorgeschaltet ist, die ggf. diesen Port sperren
oder umleiten.
Die Übertragung der Nutzinformation erfolgt, wie bereits dargestellt in RTP-Paketen. Es ist zusätzlich notwendig
zwischen den Endgeräten der Kommunikation bekannt zu geben, welcher Art die Nutzinformation sind. Dies
erfolgt mit dem Session Description Protocol (SDP). Die Endpunkte der Kommunikation bezeichnet man, nach
der Client-Server-Systematik als User Agent Client (UAC) für die aufrufende Seite und User Agent Server
(UAS) für die aufgerufene Seite. Der große Vorteil von SIP besteht darin, dass es sich in die bestehende, durch
HTTP geprägte Landschaft einfügt. So erfolgt die Adressierung für einen Anruf mittels eines URI (Uniform
Ressource Identifier), der Teilnehmer entspricht der Email-Adress-Systematik z.B. [email protected] oder im Sinne
einer Rufnummer [email protected] (SIP URI). Die IP-Adresse des zugeordneten Endgerätes kann somit auch
über DNS ermittelt werden. Neben dem Einsatz für den direkten Verbindungsaufbau zwischen zwei Endpunkten,
soweit die IP-Adresse bekannt ist, wird SIP auch für die Signalisierung mit Hilfe von Proxy-Servern,
31
Redirect-Servern und Registraren/Location-Servern verwendet. [1]
32
3.3.2 SIP Proxy-Mode und Redirect-Mode
Die beiden Betriebsarten Proxy-Mode und Redirect-Mode ermöglichen es, ohne direkte Kenntnis der IP-Adresse
des gewünschten Endgerätes, eine Verbindung aufzubauen. Der Proxy-Server leitet, ggf. mit Nachfrage bei
einem Location-Server die Anfrage (INVITE) des Anrufers an das entsprechende Endgerät oder an einen
anderen Proxy-Server. Es erfolgt also eine Weiterleitung der Anfrage. Der Austausch der Echtzeitdaten über
RTP erfolgt dann direkt zwischen den Endgeräten (peer-to-peer), wenn der Anruf akzeptiert (OK) und die
Verbindung aufgenommen (ACK) wurde. Der Abbau (BYE) der Verbindung, für den ebenfalls der Proxy-Server
benutzt wird, wird abschließend quittiert (ACK). Im Redirect-Mode ermittelt der Redirect-Server die SIP-Adresse
des gewünschten Partners und teilt diese dem anrufenden Endgerät mit. Der Verbindungsaufbau und die
Signalisierungsmeldungen (Request und Response genannt) genannt, erfolgt danach direkt zwischen den
Endpunkten.
28 vgl. Badach 2007, S. 248
29 http://de.wikipedia.org/wiki/Session_Initiation_Protocol
30 vgl. ebd., S. 248 f.
31 vgl. Badach 2007, S. 247 ff.
14
Mit diesen Mechanismen können Rufverzweigungen, Anrufweiterleitungen und die Einbindung von netzseitigen
Diensten wie Voice-Mail-Systeme eingerichtet werden. Daneben gibt es noch zwei weitere wichtige Servertypen,
die VoIP-Gateways für den Übergang von IP-Netzen auf ISDN und die Gatekeeper zwischen Netzen mit SIP
und H.323-Signalisierung, wo ggf. auch die Konvertierung der Nutzdaten in ein anderes Medienformat
33
stattfindet.
3.3.3 SIP-Nachrichten
SIP-Nachrichten verfügen wie HTTP über einen Satz an Request-Typen und Response-Klassen, mit denen
die Abläufe gesteuert werden.
Request-Typen
Response-Klassen
INVITE initiiert einen neuen Anruf und enthält Informational - 1xx teilt dem
SIP-Adresse von beiden Teilnehmern, den
Absender die Bearbeitung des
Grund (Subject) des Anrufes und dessen
Requests mit: 100 Trying, 180
Priorität.
Ringing
BYE initiiert den Abbau der bestehenden
Success - 2xx teilt dem Absender
VoIP-Verbindung
den erfolgreichen Empfang mit: 200
OK
ACK (ACKnowledgemanagement) bestätigt Redirection - 3xx signalisiert dem
die Annahme des Anrufes
Absender , dass der Empfänger sich
in einer anderen Domäne befindet:
301 Moved Permanently, 302 Moved
Temporarily
OPTIONS fragt nach Fähigkeiten (Media
Client-Error - 4xx teilt dem
Capabilities), wie Arten von Medien (Audio, Absender ein Problem bei der
Video) und Verfahren zur Codierung
Bearbeitung des Requests mit: 400
Bad Request, 401 Unauthorized, 403
Forbidden, 404 Not Found, 406 Not
Acceptable, 486 Busy Here
CANCEL bricht Aufbau einer be-reits initiierten Server-Error - 5xx signalisiert dem
VoIP-Verbindung ab
Absender ein Serverproblem: 500
Internal Server Error, 501 Not
Implemented, 502 Bad Gateway, 505
SIP Version not supported
REGISTER teilt Registrar Informationen über Global-Failure - 6xx signalisiert ein
die Lokation/Art der IP-Telefone mit; Registrar allgemeines Zugriffsproblem: 600
kann im SIP Server (Proxy bzw.
Busy Everywhere, 606 Not
Redirect-Server) oder im Location-Server
Acceptable
untergebracht werden
INFO übermitteln zusätzlicher Informationen
während einer bestehenden RTP-Session
PRACK (Provisional Response
ACKnowledgement) bestätigen eines
Responses mit vorläufigen Charakter (sog.
Provisional Responses) wie z.B. 180 Ringing,
um eine Übertragung zu garantieren
UPDATE verändert bestimmte Parameter
schon während des Aufbaus dieser
RTP-Session
MESSAGE spezifiziert die SIP-Erweiterungen
für Instant Messaging
33 vgl. Badach 2007, S. 252 ff.
15
REFER soll sog. Session Transfer (überleiten
von einer Verbindung in eine andere) zu
ermöglichen
SUBSCRIBE und NOTIFY übermitteln
bestimmter Ereignisse z.B. die Integration des
Internets mit dem Intelligent Network
Tabelle 3.5: SIP Request-Typen und Response-Klassen
Exemplarisch ist der Verlauf einer Verbindung im RFC 3261 dargestellt, die über zwei Proxy-Server abläuft.
Request und Response werden jeweils von den Proxy-Servern empfangen und weitergeleitet. Die Verbindung
wird von Alice" initiiert und in diesem Fall von Bob" beendet. Media Session steht für den RTP-Datenaustausch.
.
atlanta.com
proxy
. . . biloxi.com
proxy
.
.
.
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone
SIP Phone
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
INVITE F2
|
|
| 100 Trying F3 |--------------->|
INVITE F4
|
|<---------------| 100 Trying F5 |--------------->|
|
|<-------------- | 180 Ringing F6 |
|
| 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------|
200 OK F9 |
|<---------------|
200 OK F10 |<---------------|
|
200 OK F11 |<---------------|
|
|<---------------|
|
|
|
ACK F12
|
|------------------------------------------------->|
|
Media Session
|
|<================================================>|
|
BYE F13
|
|<-------------------------------------------------|
|
200 OK F14
|
|------------------------------------------------->|
|
|
Abbildung 3.4: SIP-Session über zwei Proxy-Server
In dem nachfolgenden Beispiel einer reale SIP-Session1 ist zu sehen, dass in dem INVITE-Request auch das
Session Descripten Protocol zum Einsatz kommt. Dort ist angegeben, welche Medienformate auf Seiten des
Anrufenden verwendet werden können. In einer nachfolgenden Antwort OK-Response des Empfängers, die
hier nur auszugsweise angegeben ist, wird mitgeteilt welche Möglichkeiten der Empfänger hat, so dass ein
passendes Format gewählt werden kann. In diesem Fall ist es, wie in der obigen RTP-Session zu sehen ist,
der Codec iLBC (Internet Low Bit Rate codec).
An dem Beispiel ist auch der Aufbau eines SIP-Paketes zu erkennen, u.a. mit der Angabe des Request- bzw.
Response-Typen, des Empfängers (To), des Senders (From) und des Inhaltes (Content-Type) mit Verweis auf
das SDP-Paket. Weitere Informationen, wie in diesem Fall zu einer anbieterspezifischen Chat-Funktion mit
dem Jabber Protocol, können enthalten sein. Im Teil des UDP-Protocols ist auch der angesprochene Port 5060
34
zu sehen.
...
User Datagram Protocol, Src Port: 64064 (64064), '''Dst Port: 5060 (5060)'''
Session Initiation Protocol
Request-Line: '''INVITE''' sip:echoproxy01.sipphone.com SIP/2.0
Method: INVITE
[Resent Packet: False]
16
Message Header
Via: SIP/2.0/UDP
192.168.62.51:64064;branch=z9hG4bK-d87543-2e49d2507207de51-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:1747246242787.183.76.234:64064>
To: <sip:echoproxy01.sipphone.com>
From: <sip:17472462427proxy01.sipphone.com>;tag=1f0e7842
Call-ID: 720ac62d7247393712839456656Tm90ZWJvb2tfQW1pbG8.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, INFO, NOTIFY, MESSAGE
Content-Type: application/sdp
Supported: ICE
User-Agent: WinGizmo/1.7.08 (Gizmo-s2n1)
Content-Length: 451
JabberID: name-xychat.gizmoproject.com
CQBM: 242
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): GizmoProject 1120482861 1 IN IP4
213.198.65.201
Session Name (s): GizmoAudioSession
Connection Information (c): IN IP4 213.198.65.201
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 6630 RTP/AVP 103
102 97 100 101 0 8 3 106 13 117
Media Attribute (a): rtpmap:103 ISAC/16000
Media Attribute (a): rtpmap:102 iLBC/8000
Media Attribute (a): rtpmap:97 IPCMWB/16000
Media Attribute (a): rtpmap:100 EG711U/8000
Media Attribute (a): rtpmap:101 EG711A/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:106 telephone-event/8000
Media Attribute (a): rtpmap:13 CN/8000
Media Attribute (a): rtpmap:117 red/8000
Media Attribute (a): rtcp:6631
-------------------------------------------------------------------------...
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
...
Message body
Session Description Protocol
...
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 19566 RTP/AVP 102
0 8 106
Media Attribute (a): rtpmap:102 iLBC/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:106 telephone-event/8000
Media Attribute (a): fmtp:106 0-16
Media Attribute (a): silenceSupp:off - - - -
Text 3.3: Beispiel SIP INVITE-Request und OK-Request mit SDP
3.4 Ablaufsteuerung zwischen verschiedenen Netzen
Neben dem Verbindungsaufbau und dem Transport der Nutzdaten ist eine Ablaufsteuerung auf der Ebene der
Verbindungen unterschiedlicher Netze notwendig. Dies wird im Zusammenspiel von VoIP-Netzen und anderen
Netzen mit Hilfe der Protokolle Media Gateway Control Protocol (MGCP) und Media Gateway Control (Megaco)
ermöglicht.
17
RFC/ITU
MGCP
Media Gateway Control Protocol (Application Layer) RFC 3435,
MGCP ist ein Netzwerkprotokoll zur Steuerung von
3661
VoIP-Gateways. MGCP ist ein Master/Slave Protokoll
welches die Steuerinformationen in Klartext (wie SIP)
überträgt. Das VoIP-Gateway arbeitet als Slave und wird
von einer Vermittlungseinheit (Call Control Device)
35
gesteuert.[1] Die Übertragung erfolgt auf Basis von UDP.
Megaco Media Gateway Control (Application Layer) Megaco ist RFC 3015,
ein von der IETF und der ITU-T unterstütztes Gate2805, H.248
way-Protokoll zur Steuerung von Media Gateways (MG)
und wird für den Aufbau von VoIP-Verbindungen benutzt.
Es arbeitet unabhängig von Rufsignalisierungen wie dem
Netzwerkprotokoll H.323 und dem SIP-Protokoll.[2]
kann über TCP und UDP übertragen werden.
36
Es
Tabelle 3.6: Protokolle zur Ablaufsteuerung zwischen Netzen
Wegen des größeren Funktionsumfangs und der höheren Akzeptanz durch die Standardisierung von ITU-T
und IETF kommt das Protokoll Megaco stärker zum Einsatz, insbesondere für das Next Generation Network
und das IP Multimedia Subsystem. MGCP wird eher in kleineren Netzinfrastrukturen, z.B. zur Anbindung von
37
TK-Anlagen genutzt.
Die zentralen Elemente zur Verknüpfung und Ablaufsteuerung sind das Media Gateway (MG) und der Media
Gateway Controller (MGC). Das Media Gateway bildet die Schnittstelle zwischen dem IP-Netzwerk und anderen
Netzwerken, wie dem herkömmlichen Telefonnetz (public switched telephone network - PSTN). Dort erfolgt
nur die Umsetzung der angelieferten Nutzdaten in die für das jeweilige Netz transportierbare Form - für VoIP
in RTP/RTCP-Pakete. Der MGC übernimmt die Steuerung der MG und die Signalisierung, also die Umsetzung
von und nach SIP bzw. H.323-SIG. Zwischen MG und MGC kommen die Protokolle MGCP und Megaco zum
Einsatz. Für die Wandlung der Signalisierung zwischen den Netzen wird analog zum MG ein Signaling Gateway
38
(SG) benötigt, dessen Daten z.B. mittels SIGTRAN-Protokollen , wie das bereits oben erwähnte Trans39
portprotokoll SCTP, an das MGC gegeben werden. Einen Überblick gibt folgendes Bild[3] :
35 http://de.wikipedia.org/wiki/MGCP
36 http://de.wikipedia.org/wiki/Megaco
37 vgl. Badach 2007, S. 287 ff.
38 SIGTRAN: IETF Working Group, die sich mit Signalisierung von und zu PSTN beschäftigt
39 http://www.syrus.ru/files/devices/mon/masterquest/75.gif
18
Abbildung 3.5: Überblick Konvergente Netzwerkarchitektur
3.5 Telefonnummern-Systematik und
Internet-Adressierung
Das Grundprinzip der meisten Anbieter für VoIP-Dienste ist, für angemeldete Nutzer die zentrale Vermittlung
unter den Nutzern durchzuführen. Eine direkte Verbindung von Nutzern unterschiedlicher Anbieter ist in der
Regel nicht gegeben. Die Bereitstellung eines unabhängigen Verzeichnisdienstes mit dem ENUM-System
(TElephone NUmber Mapping) in Verbindung mit dem Domain Name Service (DNS) ermöglicht es dem einzelnen
Nutzer allgemein erreichbar zu werden und so unabhängig von einem Anbieter verschiedene Dienste wie VoIP
mittels SIP mit anderen Nutzern zu betreiben.
RFC/ITU
DNS
Domain Name System (Application Layer) DNS wird
RFC 1034,
hauptsächlich zur Umsetzung von Domain-Namen in
1035
IP-Adressen (forward lookup) genutzt. Eine umgekehrte
Abfrage ist ebenso möglich (reverse lookup). Das DNS
besteht aus den drei Hauptkomponenten
Domain-Namensraum, Nameserver und Resolver. Das DNS
stellt ein hierarchisches System dar, das sich von hinten
gelesen in den Ebenen eines Domain-Namens spiegelt (z.B.
tools.ietf.org). Die erste Ebene des Domain-Namens (.arpa,
.com, .org, .de, ...) wird als Top-Level-Domain
40
ENUM
bezeichnet.[1]
TElephone NUmber Mapping ist die Abbildung von
RFC 3761
herkömmlichen Telefonnummern nach dem ITU-T-System (3401)
E.164 auf IP-Adressen. Es nutzt das Domain Name System E.164
(DNS) um E.164-Nummern zu speichern und ist in der Lage,
Dienste zu kennzeichnen, die unter einer E.164-Nummer
40 http://de.wikipedia.org/wiki/Domain_Name_System
19
möglich sind. Es ermöglicht damit als Verzeichnisdienst die
Verbindung von VoIP-Nutzern mit Nutzern anderer Netze.
ENUM ist jedoch keine VoIP-Funktion und sollte getrennt
41
42
von deren Protokollen betrachtet werden.[2] [3] Der Dienst
wird auf Servern unterhalb der Top Level Domain .arpa
betrieben.
Tabelle 3.7: Zuordnung IP-Adress mit Telefonnummer
Die folgende Darstellung soll nur kurz anreißen, wie und welche Daten in dem Verzeichnisdienst vorgehalten
werden können.
Beispiel aus dem RFC 3761:
Die Rufnummer "+441164960348" wird zu: 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. Der ENUM-DNS stellt Server
bereit, auf denen Naming Authority Pointer (NAPTR) im DNS Resource Record gespeichert sind. Es werden
auf die umgeformte E.164-Rufnummer die verfügbaren Internet-Dienste abgebildet.
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:[email protected]!" .
NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:[email protected]!" .
NAPTR 10 103 "u" "E2U+tel" "!^.*$!tel:+441164960348!" .
Folgendes wird damit beschrieben: Die Domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. ermöglicht eine Kommunikation
mittels SIP, H.323 für Sprache und SMTP für EMail. Die Kürzel "sip", "h323", "msg" und tel" haben hierbei
keinen direkten Bezug zu den Protokollen oder zum URI-Schema.
42 http://www.itu.int/rec/T-REC-E/en
4 Schlussbetrachtung
20
4 Schlussbetrachtung
Bis zu diesem Punkt wurden im Wesentlichen die Grundlagen für VoIP dargestellt, die ein Grundverständnis
für die Abläufe und Inhalte der verwendeten Protokolle erreichen soll. Weiterführende Themen seien an dieser
Stelle nur in Schlagworten für VoIP benannt.
•
•
•
•
•
•
•
Sicherheit (Technik und Datenschutz)
Programmierschnittstellen und -umgebungen, u.a. auf Basis von Java
Netzkonzepte Next Generation Network und IP Multimedia Subsystem
Endgeräte und Anwendungen: Hardware und Softphones
Anbieter von VoIP-Diensten und Hardware für Privat- und Geschäftskunden
Marktübersichten und Geschäftsmodelle
Technikfolgen wirtschaftlicher und sozialer Art
VoIP ist technisch gesehen noch immer ein spannendes Thema, obwohl inzwischen die Grundlagen gefestigt
und standardisiert sind. Auf Basis von VoIP und mit VoIP als einem Bestandteil neben Instand Messaging,
IP-TV, usw. entwickeln sich heute neue Angebote, die schnell, wegen der hohen Verfügbarkeit von
Internetzugängen, Verbreitung finden. Die Einbindung von VoIP in eigene Applikationen und Angebote stellt
für jeden Programmierer ein interessantes und ggf. lukratives Betätigungsfeld dar.
5 Literaturverzeichnis und Web-Links
21
5 Literaturverzeichnis und Web-Links
•
•
•
•
•
•
•
•
•
•
•
Badach, Anatol (2007): Voice over IP Die Technik. 3., erweiterte Auflage. München Wien: Carl Hauser Verlag
Internet Engineering Task Force (IETF): http://www.ietf.org
IETF Tools, insbesondere RFC: http://tools.ietf.org
International Telecommunication Union - Telecommunication Standardization Sector (ITU-T):
http://www.itu.int/ITU-T
European Telecommunication Standards Institute(ETSI): http://www.etsi.org
Wikipedia, englische Version: http://en.wikipedia.org
Wikipedia, deutsche Version: http://de.wikipedia.org
Global IP Telecommunications, Inc.: http://www.xten.de
Wireshark network protocol analyzer: http://www.wireshark.org
Network Sorcery, RFC Sourcebook: http://www.networksorcery.com
Syrus: http://www.syrus.ru/
6 VoIP Diensteanbieter
6 VoIP Diensteanbieter
Anbieter
Hompage
Anwendung
Skype
http://www.skype.com/intl/de/
http://www.skype.com/intl/de/download/features/
Gizmo
http://www.gizmoproject.com/intl/de/ http://www.gizmoproject.com/intl/de/learn-more.html
T-Online
http://www.t-online.de
http://service.t-online.de/c/12/71/61/14/12716114.html
SparVoIP
http://www.sparvoip.de/
http://www.sparvoip.de/de/instructions.html
LowRateVoIP http://www.lowratevoip.com
http://www.lowratevoip.com/en/instructions.html
Google Talk http://www.google.com/talk/
http://www.google.com/talk/about.html
Anbieter
Peter zahlt
Gelbe Seiten
Marcophone
Hompage
http://www.peterzahlt.de/
Anmerkung
Web-Initated Call Services:
GoYellow
http://maps.gelbeseiten.de/ Direktverbindung Click-and-Call
http://marcophono.de/
Joke-Anwendung
22
7 Anlagen
23
7 Anlagen
Hier einige Screenshots der VoIP-Applikationen verschiedener Anbieter mit einigen Verbindungsprotokollen.
Skype
skype_080107_uni_1_sessions.txt (Verbindung zu einem anderen Skype-Nutzer))
Skype Kontakte:
Skype Wähltasten:
Skype Optionen:
T-Online
t-online080107_uni_2_sessions.txt (Verbindung zu einer Rufnummer an einem Telefonanschluß)
7 Anlagen
t-online-gizmo080103_sessions.txt (Verbindung zu einer Rufnummer bei einem anderen VoIP-Anbieter)
T-Online Softphone (veränderbares Design):
Peter zahlt
Peter zahlt Anwahlseite:
Gelbe Seiten
Gelbe Seiten Anwahlseite:
marcophon
24
7 Anlagen
marcophon Eingabeseite:
25

Inhaltsverzeichnis - Universität Osnabrück

Transcription

Documents pareils

VoIP confguration benutzerhandbuch Thomson st2022 De

Sicherheit geht vor

VoIP-Security

Online Dienste

Secure Network Gateway für Remote Services

Studie über sichere webbasierte Übertragungswege

Abschlussvortrag zur Bachelorarbeit - Classification of Traffic Flows

super-wolfi.de TARIF-TABELLE 04-07

Datenblatt Ciena 3932

Protokolle des Bösen

CN.as COM - SIP Spezifikationen Notruf

Get CHF 400 in free calls now!*

Dokumentation DENIC 23p