Technischer Bericht als PDF

Transcrição

DEPARTMENT
FÜR
I NFORMATIK - ABTEILUNG RECHNERNETZE
UND
TELEKOMMUNIKATION
Klassische Telekommunikationsanwendungen
und deren Mehrwertdienste im Internet
VON
STEFAN BRUNHORN
APRIL 2008
Abstract
Das Internet Protokoll dringt in Anwendungsgebiete vor, die zuvor durch leitungsvermittelnde
Verfahren oder Rundfunk dominiert wurden. Dazu zählt die Telefonie, Telefax, Radio sowie das
Fernsehen. Für eine Umsetzung mit IP benötigen diese Anwendungen spezielle Protokolle, mit
denen audiovisuelle Medien transportiert und das Verhalten von Endgeräten gesteuert werden
kann. Die Protokolle müssen zudem dafür sorgen, dass etablierte Mehrwertdienste erhalten
bleiben. Um eine angemessene Dienstqualität zu erreichen, sind Störungen durch andere
Dienste zu unterbinden. Darüber hinaus ist für die Telefonie eine Anbindung an herkömmliche
Netze in der Übergangszeit unerlässlich.
Inhaltsverzeichnis
Inhaltsverzeichnis..........................................................................................................5
1. Einleitung..................................................................................................................9
2. Wechsel zu IP...........................................................................................................11
2.1 Ein anwendungsübergreifender Datenübertragungsstandard.....................................11
2.2 Leitungsvermittlung vs. Paketvermittlung...............................................................11
2.3 Infrastruktur.......................................................................................................11
2.4 IP-Dienste im Jahr 2007......................................................................................12
2.5 Entwicklung in Deutschland..................................................................................12
2.6 Bewertung.........................................................................................................13
3. Entwicklung von Telekommunikationsdiensten..............................................................15
3.1 Analoge Telefonie................................................................................................15
3.2 ISDN.................................................................................................................15
3.3 Mobiltelefonie.....................................................................................................16
3.4 Telefax...............................................................................................................16
3.5 Radio.................................................................................................................17
3.6 Fernsehen..........................................................................................................18
3.7 Digitaler Rundfunk..............................................................................................19
3.8 Bildtelefonie.......................................................................................................19
3.9 Network Voice Protocol........................................................................................20
4. Mehrwertdienste in der "klassischen Telekommunikation"..............................................21
4.1 ISDN-Dienste.....................................................................................................21
4.1.1 ISDN-Basisdienste........................................................................................21
4.1.2 ISDN-Dienstmerkmale..................................................................................22
4.2 GSM-Dienste......................................................................................................24
4.2.1 GSM-Basisdienste.........................................................................................24
4.2.2 GSM-Zusatzdienste.......................................................................................26
4.2.3 Open Mobile Alliance.....................................................................................26
4.3 Andere Mehrwertdienste für die Telefonie...............................................................27
4.4 Radio Data System..............................................................................................28
4.5 Mehrwertdienste für DAB und DRM........................................................................30
4.6 Teletext.............................................................................................................30
4.7 Digital Audio Video Council...................................................................................31
4.7.1 DAVIC 1.4...................................................................................................32
4.7.2 TV Anytime and TV Anywhere........................................................................33
5. IP-Technik................................................................................................................35
5.1 Datendienste......................................................................................................35
5.2 Voice over IP......................................................................................................35
5.2.1 H.323 Geräte und Adressierung.....................................................................36
5.2.2 H.225 Anrufsignalisierung..............................................................................38
5.2.3 H.245 Steuerung multimedialer Kommunikation...............................................39
5.2.4 H.323 Verbindungsaufbau.............................................................................40
5.2.5 H.323 Zusatzdienste.....................................................................................43
5
Inhaltsverzeichnis
5.2.6 SIP Anrufsignalisierung.................................................................................45
5.2.7 SDP Sitzungsbeschreibung............................................................................48
5.2.8 Ankündigung einer Sitzung mit dem SAP.........................................................49
5.2.9 RTP Medientransport.....................................................................................49
5.2.10 Sicherheit..................................................................................................50
5.2.11 Sprachqualität ...........................................................................................51
5.3 Quality of Service................................................................................................51
5.3.1 Reservierung von Ressourcen mit dem RSVP...................................................51
5.3.2 Differentiated Services..................................................................................52
5.4 Fax over IP.........................................................................................................53
5.4.1 T.37............................................................................................................53
5.4.1 T.38............................................................................................................54
5.5 Streaming Media.................................................................................................54
5.6 IPTV..................................................................................................................55
6. Gateways.................................................................................................................57
6.1 Gateway Control Protocol.....................................................................................57
6.2 SS7 over IP........................................................................................................58
6.3 SIP-T, SIP-I........................................................................................................59
6.4 Interoperabilität..................................................................................................59
7. Telearbeit................................................................................................................61
7.1 T.120 Protokolle zur Datenübertragung in Konferenzen............................................61
7.1.1 Multipoint Communication Service..................................................................61
7.1.2 Generic Conference Control...........................................................................62
7.1.3 Generic Application Template.........................................................................62
7.1.4 Anwendungen..............................................................................................63
7.2 H.239 Präsentationsvideos...................................................................................63
8. Ausblick...................................................................................................................65
Anhang A - ISDN..........................................................................................................67
A.1 Schnittstellen des ISDN-Basisanschlusses..............................................................67
A.2 Primary Service..................................................................................................69
A.3 Q.931 Verbindungsaufbau im ISDN.......................................................................70
A.4 SS7...................................................................................................................71
A.5 ISDN User Part...................................................................................................72
A.6 Breitband ISDN..................................................................................................73
A.7 ATM..................................................................................................................73
A.8 PDH/SDH...........................................................................................................74
A.9 PPP...................................................................................................................75
A.10 PPPoE..............................................................................................................75
A.11 ADSL...............................................................................................................75
Anhang B - H.323 Signalisierungsnachrichten..................................................................77
B.1 H.225 Nachrichten des RAS-Kanals.......................................................................77
B.2 Q.931 Signalisierungsnachrichten.........................................................................78
B.3 Q.932 Signalisierungsnachrichten.........................................................................79
B.4 H.225 Informationselemente................................................................................80
6
Inhaltsverzeichnis
B.5 H.245 Nachrichten zur Steuerung multimedialer Kommunikation..............................81
B.6 T.125 Nachrichten des Multipoint Communication Service.........................................83
B.7 T.124 Nachrichten der Generic Conference Control..................................................84
B.8 H.239 Nachrichten zum Aufbau eines privilegierten Videokanals...............................85
Anhang C - SIP-Signalisierungsnachrichten......................................................................87
C.1 Adressierung......................................................................................................87
C.2 URI-Parameter...................................................................................................88
C.3 Header-Felder....................................................................................................88
C.4 Methoden...........................................................................................................89
C.5 Status-Codes......................................................................................................90
C.6 Beispiele............................................................................................................91
Anhang D - Sitzungsbeschreibung mit dem SDP...............................................................93
D.1 Beispiel.............................................................................................................94
Anhang E - Ankündigen einer Sitzung mit dem SAP..........................................................95
Anhang F - RTP/RTCP-Header-Informationen....................................................................97
F.1 Nutzdatentypen.................................................................................................100
Anhang G - Megaco.....................................................................................................101
G.1 Befehle............................................................................................................101
G.2 Deskriptoren....................................................................................................102
G.3 Beispiel............................................................................................................104
Anhang H - SCTP........................................................................................................105
Anhang I - RSVP.........................................................................................................107
Anhang J - Vergleich von Sprachcodecs.........................................................................109
Anhang K - Telefax......................................................................................................111
K.1 Ablauf einer T.30-Telefaxverbindung....................................................................111
K.2 Wichtige Fax-Nachrichten...................................................................................111
Anhang L - RTSP.........................................................................................................113
Anhang M - Multicast...................................................................................................115
Glossar und Abkürzungsverzeichnis...............................................................................117
Begriffe.................................................................................................................117
Abkürzungen..........................................................................................................117
ISDN-Dienstmerkmale.........................................................................................117
RDS..................................................................................................................118
Teletext.............................................................................................................119
H.323 Zusatzdienste...........................................................................................119
Weitere Abkürzungen..........................................................................................119
Literatur....................................................................................................................123
Digital Audio Video Council.......................................................................................123
European Telecommunications Standards Institute......................................................123
International Telecommunication Union.....................................................................124
Open Mobile Alliance...............................................................................................126
Request for Comments............................................................................................126
Weitere Standards .................................................................................................127
Weitere Literatur.....................................................................................................127
7
Inhaltsverzeichnis
8
1. Einleitung
Der vorliegende Text betrachtet Telekommunikationsanwendungen, ihre Mehrwertdienste sowie
Techniken, mit denen diese im Internet Protokoll umgesetzt werden können.
Kapitel 3 stellt zunächst einige "klassische Telekommunikationsdienste" vor, die bis heute
weit verbreitet sind. Dazu zählen im Wesentlichen die Telefonie, Telefax, Radio sowie das
Fernsehen. Im Laufe der Zeit wurden außerdem eine Reihe von Mehrwertdiensten entwickelt,
mit denen diese Hauptanwendungen erweitert oder komfortabler gestaltet wurden. So ist z.B.
für die Telefonie innerhalb eines Call Centers das Halten eines Telefongesprächs notwendig, um
Telefongespräche weiterleiten zu können. Für das Fernsehen ist der Teletext zwar mittlerweile
etwas in die Jahre gekommen, er wird aber immer noch für Hinweise und Untertitel zum
laufenden Programm, für Werbezwecke und sogar für Chat-Anwendungen genutzt. Die
zugrunde liegenden Spezifikationen solcher Mehrwertdienste werden in Kapitel 4 informell
dargelegt.
Mittlerweile wird daran gearbeitet die genannten Dienste mit Hilfe einer einheitlichen
Infrastruktur anzubieten. Die Wahl fiel dabei auf das Internet Protokoll, das seit seiner
Entstehung heterogene Anwendungen ermöglicht. Die zur Steuerung und Übertragung von
Audio- und Videoströmen spezifizierten Protokolle werden in den Kapiteln 5 bis 7 vorgestellt.
Dazu gehören u.a. die H.323-Protokolle, das SIP und das RTP. Es werden zudem Protokolle
beschrieben, die eine Zusammenarbeit von VoIP und herkömmlichen Netzen sicherstellen
sollen. Einige weitere Protokolle unterstützen Telearbeit, die als Mehrwertdienst von IPbasierter Telekommunikation gesehen werden kann.
Das nun folgende Kapitel 2 geht auf den Wechsel von der "klassischen Telekommunikation"
zu IP-Diensten ein.
9
1. Einleitung
10
2. Wechsel zu IP
In diesem Kapitel wird der
Telekommunikation" beleuchtet.
Einsatz
des
Internet
Protokolls
in
der
"klassischen
2.1 Ein anwendungsübergreifender Datenübertragungsstandard
Seit den 1990er Jahren findet das Vermittlungsprotokoll IP mit der Verbreitung des Internet
immer häufiger Anwendung. Es kommt in Bereichen zum Einsatz, in denen man bislang auf
analoge Techniken oder aber eigene Protokollstapel gesetzt hat (siehe Einleitung). Als ein
wesentlicher Grund für diese Entwicklung wird häufig die Reduzierung von Kosten durch eine
homogene Infrastruktur beworben. So wurde Hard- und Software bislang häufig für jeden
Anwendungsbereich gesondert entwickelt. Daher ist speziell geschultes Personal notwendig,
um Netzwerke aufzubauen und zu verwalten. Produkte, wie z.B. Telefon-Switches können
außerdem nur in begrenzter Stückzahl verkauft werden.
Anwendungsübergreifende Datenübertragungsstandards, wie Ethernet und IP bietet hier
Vorteile. Hardware für allgemeinere Anwendungen ist zum einen günstiger, da sie in großen
Mengen produziert werden kann. Zum anderen ist es einfacher Personal zu finden, das mit
standardisierter Hard- und Software vertraut ist. Auf diese Weise können Schulungs- und
Personalkosten verringert werden. Das schließt insbesondere die Kosten für Wartungsarbeiten
ein, die z.B. bei "traditionellen Telefonanlagen" von externen Technikern durchgeführt werden.
2.2 Leitungsvermittlung vs. Paketvermittlung
IPv4 wurde 1981 im RFC 791 spezifiziert und stellt einen unzuverlässigen, paketbasierten
Datenübertragungsdienst zur Verfügung. Schaut man sich das analoge Telefonsystem oder
auch ISDN an, stellt man fest, dass diese im Gegensatz zu IP die benötigten Ressourcen
zwischen den Kommunikationspartnern reservieren. Das Prinzip wird auch als
Leitungsvermittlung (Circuit Switching) bezeichnet.
Natürlich stellt sich die Frage, warum ausgerechnet ein Protokoll wie IP die bisherigen
Techniken ablösen soll. Dies kann im Kontext des Inter-Networking, der internationalen
Verbindung unterschiedlicher Netze verstanden werden. Hier ist IP schon seit geraumer Zeit
das etablierte Protokoll. Hinzu kommt der Umstand, dass das durch Datendienste verursachte
Volumen gegen Ende der 1990er Jahre stark anstieg und das Sprachvolumen überholte. Da
paketbasierte Protokolle die verfügbare Bandbreite bei Datendiensten wesentlich besser
ausnutzen können, ist es für Telekommunikationsanbieter natürlich reizvoll diese zu
verwenden. Die Wahl des Internet Protokolls kann daher auch mit der steigenden Relevanz von
Datendiensten durch die Verbreitung des Internet begründet werden. [RÖSSEL S.22]
2.3 Infrastruktur
Um das Internet Protokoll sinnvoll für den Transport kontinuierlicher Echtzeitmedien einsetzen
zu können, ist ggf. eine Infrastruktur nötig, welche solche Dienste gegenüber anderen
11
2. Wechsel zu IP
Datendiensten priorisiert. Dies leisten spezielle Router und Switches mit Hilfe entsprechender
Warteschlangen. Die dafür notwendige Kennzeichnung von Datagrammen wird im RFC 2474
beschrieben und ermöglicht sogenannte Differential Services (siehe 5.3.2).
Eine Alternative zur Priorisierung stellt die Reservierung von Bandbreite mittels RSVP dar
(siehe 5.3.1). Aufgrund der recht komplexen Sicherheitsmechanismen und vor allem weil
sämtliche Vermittlungsknoten entlang einer Verbindung das Verfahren unterstützen müssen,
scheint es aber eher selten verwendet zu werden (siehe [M 5.136]). So wurden keine Berichte
über einen produktiven Einsatz gefunden, obgleich entsprechende Hardware verfügbar ist.
Für die Übertragung von Echtzeitmedien in herkömmlichen IP-Netzwerken können keine
Garantien für die Dienstqualität (QoS) gegeben werden. Weil keine Investitionen in neue
Verteiler notwendig sind, gibt es aber viele Fälle, in denen z.B. VoIP auch in einer solchen
Umgebung erfolgreich angewendet wird (siehe z.B. [HEIDELBERG]). Eine zufriedenstellende
Qualität kann hier jedoch nur erreicht werden, solange ausreichend Bandbreite zur Verfügung
steht. Dazu gilt es die Kollisionsbereiche möglichst klein zuhalten. Mit Techniken wie Traffic
Shaping kann zudem die maximale Bandbreite für reine Datendienste begrenzt werden.
Insbesondere Telekommunikationsanbieter setzen für den Transport von VoIP auf eine
Überdimensionierung der Bandbreite. QoS-Mechanismen kommen hier bestenfalls beim
Endkunden zum Einsatz. Sie können jedoch im betrieblichen Umfeld eine wichtige Rolle
spielen, wenn Telefon- und Computernetze zusammengelegt werden.
2.4 IP-Dienste im Jahr 2007
Viele Internet Service Provider (ISP) gehen zur Zeit dazu über, so genannte Tripple-PlayLösungen anzubieten. Konventionelle Internetdienste, wie das WWW oder E-Mail sowie die
neuen Dienste IPTV und VoIP werden dabei über eine DSL-Leitung oder via Fernsehkabel
angeboten. Auf diese Weise kann der ursprüngliche Telefon-, Fernsehkabel- oder
Internetanbieter seine Produktpalette um neue Dienste erweitern. Für den Kunden bedeutet
das meist günstigere Tarife und eine bessere Rechnungsübersicht. Ein Ausfall des Netzwerks
wirkt sich aber gleich auf mehrere, zuvor unabhängige Dienste aus.
Hatten Stromausfälle bislang keine direkten Auswirkungen auf die Funktionsfähigkeit eines
analogen Telefons, so muss sich bei bei VoIP noch zeigen, in wie weit spezielle Maßnahmen
den Dienst aufrecht erhalten können. Vorstellbar ist z.B. eine Notstromversorgung mit
Akkumulatoren in Kombination mit Power over Ethernet (PoE). Ein weiteres Problem stellt die
geografische Lokalisierung eines Anschlusses anhand der Rufnummer oder die Vermittlung von
Notrufnummern zur nächstgelegenen Zentrale dar. Dies ist jedoch nur relevant, sofern ein
VoIP-Zugang von verschiedenen Endpunkten aus genutzt werden soll. [KNAUER S.33,40-41]
2.5 Entwicklung in Deutschland
Bis zum 1. Januar 1998 wurde das Telefonnetz in Deutschland von der Deutschen Bundespost
und später von der Deutschen Telekom AG betrieben und ausgebaut. Mit der Liberalisierung
des Telefonmarktes musste das Netz dann auch anderen Unternehmen zur Verfügung gestellt
werden. Die neue Konkurrenzsituation sorgte recht bald für einen starken Preisverfall (siehe
12
2. Wechsel zu IP
[RÖSSEL S.21]). Da sich die Anbieter von IP-Technik u.a. langfristige Kosteneinsparungen
erhoffen, kann dieser Umstand den Wechsel zur IP-Technik in Deutschland beschleunigt haben.
2.6 Bewertung
Es gibt zur Zeit Bestrebungen möglichst viele Dienste über ein Netz und mit einheitlicher
Technik anzubieten. Dies bezeichnet man auch als Konvergenz der Netze. Der Wechsel von
"klassischen Telekommunikationsmedien" zu IP-Diensten bringt dabei sowohl für Kunden als
auch für Anbieter finanzielle Vorteile. Im betrieblichen Umfeld können allerdings QoSMechanismen nötig sein, um eine zufriedenstellende Dienstqualität zu gewährleisten. Dafür
müssen Investitionen getätigt werden, die z.B. einer Einführung von VoIP zunächst im Weg
stehen können.
13
2. Wechsel zu IP
14
3. Entwicklung von Telekommunikationsdiensten
Dieses Kapitel gibt einen Überblick über die Entwicklung der Telekommunikation für einige
ausgewählte Anwendungen. Dies soll helfen deren aktuelle Bedeutung und ggf. spezifische
Anforderungen zu erfassen.
3.1 Analoge Telefonie
Nach am dem Ende des 19. Jahrhunderts Patentstreitigkeiten zwischen Alexander Graham Bell
und der Western Union Telegraph Company zu Gunsten von Bell entschieden wurden,
verbreitete sich das analoge Telefon weltweit. Die Vermittlung von Telefongesprächen wurde
zunächst per Hand vom sogenannten Fräulein vom Amt durchgeführt und brachte gerade bei
Verbindungen ins Ausland lange Wartezeiten mit sich. Einen weiteren Nachteil stellte die
manuelle Vermittlung von Geschäftsgesprächen dar, weil das Mithören leicht möglich und die
Vertrauenswürdigkeit des Personals nicht immer gegeben war. Erst nach und nach wurden die
Stellen durch automatische Telefonvermittlungen ersetzt. Dazu kamen erst mechanische
Hebdrehwähler und mit den 1970er Jahren auch elektrische Telefon-Switches (Crossbarwähler)
zum Einsatz. [WIESEL]
Da das Telefon im wirtschaftlichen Bereich immer wichtiger wurde, gingen größere
Unternehmen dazu über, eigene unternehmensweite Telefonnetze zu betreiben. Für die
Vermittlung interner Gespräche und die Anbindung an das öffentliche Telefonnetz (PSTN)
wurden kleinere Telefon-Switches, sogenannte Public Branch Exchanges (PBX) entwickelt.
Diese erlaubten die gemeinsame Nutzung von wenigen externen Leitungen durch eine Vielzahl
interner Telefone. Die PBXs ermöglichten darüber hinaus erstmals Dienste, welche die Telefonie
vereinfachten. Da die notwendige Funktionalität im Switch positioniert wurde, waren die
Dienste direkt, ohne Anschaffung neuer Telefone anwendbar. Ein auf diese Weise angebotener
Dienst war z.B. das Halten eines Gesprächs, während ein neu eingehender Anruf beantwortet
werden konnte. Die Signalisierung eines Anrufs während eines laufenden Telefonats wird auch
als Anklopfen (Call Waiting) bezeichnet (siehe 4.1.2). Für Unternehmen, die nicht in der Lage
waren einen PBX zu finanzieren, konnten die Leistungen auch im Rahmen sogenannter
Centrex-Dienste (Central Office Exchange) genutzt werden. Diese wurden von Telekommunikationsunternehmen kostenpflichtig zur Verfügung gestellt. [WALLINGFORD S.4-7,68]
3.2 ISDN
ISDN wurde in den 1970er Jahren auf Konferenzen der CCITT sowie der europäischen
Telefonverwaltung (CEPT) entwickelt und in den 1980er und 1990er Jahren in vielen Ländern
aufgebaut. Das Hauptziel bestand darin, alle bis dahin angebotenen und zukünftigen Dienste
mit einer einheitlichen Technik umzusetzen (siehe [WIESEL]). Die selben Beweggründe
sprechen heute für den Einsatz von IP.
Die mit ISDN einhergehende digitale Übertragung von Sprache bietet aber auch eine
bessere Klangqualität: Jedes Signal, welches über eine größere Distanz versendet wird,
unterliegt einer Dämpfung und äußeren Einflüssen, die das Signal stören. Kommt bei einer
15
analogen Übertragung nur die direkte Verstärkung und ggf. Filterung des Signals in Frage,
kann ein digitales Signal aufgrund der bekannten möglichen Zustände rekonstruiert werden.
Die digitale Abbildung eines analogen Audiopegels wird in der Empfehlung G.711 "Pulse Code
Modulation (PCM) of Voice Frequencies" der International Telecommunication Union (ITU-T),
ehemals CCITT beschrieben.
Für ISDN wurden viele sogenannte Dienstmerkmale standardisiert, von denen einige, wie
das Halten eines Gesprächs bereits für die analoge Telefonie verfügbar waren. Andere Dienste,
wie die Rufnummernanzeige konnten erst durch eine digitale Datenübertragung im analogen
Telefonnetz umgesetzt werden (siehe [EN 300 659]). In Punkt 4.1.2 werden die ISDNZusatzdienste zusammengefasst. Eine Beschreibung zum ISDN ist im Anhang A zu finden.
3.3 Mobiltelefonie
Ab 1952 war es in Deutschland möglich über städtische Systeme mit einem Autotelefon
Gespräche ins Festnetz zu führen. Um lokale Inkompatibilitäten zu beseitigen, wurde 1958 das
sogenannte A-Netz eingerichtet, in
dem
die
Vermittlung von
Gesprächen per
Hand
durchgeführt wurde. Im Jahr 1972 folgte dann das B-Netz, das Roaming mit einigen
Nachbarländern Deutschlands ermöglichte und Gespräche automatisch vermitteln konnte.
Ein aktuelles Mobilfunknetz benötigt eine Reihe festinstallierter Basisstationen, deren
jeweiliger Abdeckungsbereich als Zelle definiert ist. Bewegt sich ein Teilnehmer von einer Zelle
in eine andere, so ist es wünschenswert, das Gespräch zwischen den Stationen übergeben zu
können. Diese Fähigkeit wird auch als Handover bezeichnet und wurde erst 1986 mit Hilfe
einer digitalen Signalisierung im C-Netz eingeführt. Zudem wurde so eine automatische
Lokalisierung der Teilnehmer möglich.
1982 rief die CEPT eine Studiengruppe, die Groupe Spéciale Mobile (GSM) ins Leben, um
ein Konzept für ein einheitliches europäisches Mobilfunksystem zu erarbeiten. Dieses wurde
1988 durch das European Telecommunications Standards Institute (ETSI) spezifiziert und in
Deutschland unter den Namen D1, D2, E-Plus und E2 (bzw. O2) in Betrieb genommen. Mit der
Verbreitung des Standards wurde die Abkürzung GSM dann als Global System for Mobile
Communications neu besetzt. Das GSM-Netz überträgt sowohl Signalisierungsdaten als auch
Sprache in digitaler Form. Es arbeitet leitungsvermittelt und ist für den Datentransfer nur
bedingt geeignet. Seit Mitte der 1990er Jahre liegt daher das Hauptinteresse in der
Spezifikation mobiler, paketbasierter Datenübertragungsstandards, wie GPRS, UMTS, usw.
Aufgrund des leichten physikalischen Zugangs muss ein Funknetzwerk geschützt werden.
GSM-Netze verwenden dazu eindeutige Gerätekennungen mit denen die Zugangsberechtigung
über ein Challenge-Response-Verfahren geprüft wird. Die übertragenen Daten werden
außerdem verschlüsselt und die Anonymität der Nutzer durch zufällig generierte Teilnehmerkennungen gewährleistet. [SCHNABEL]
3.4 Telefax
Das Wort Telefax wird von dem lateinischen Wort Faksimile abgeleitet und beschreibt den
Dienst eines Fernkopierers. Im Gegensatz zum Telegrafiedienst werden keine Zeichen sondern
16
eingelesene Bildelemente des Originaldokuments übermittelt. Alexander Bain stellte 1843 ein
entsprechendes System vor, das im Laufe der Zeit von verschiedenen Personen
weiterentwickelt wurde. (Die Telegrafie wird in diesem Text nicht näher betrachtet, da sie
mittlerweile für die Telekommunikation keine Relevanz mehr besitzt.)
Im Gegensatz zur Telegrafie oder dem Telefon verbreitete sich das Telefax lange Zeit nur in
besonderen Anwendungsbereichen. Die erste kommerzielle Anwendung war die Übermittlung
von Informationen zum Aktienhandel im Jahr 1870 in Frankreich. Durch die Reproduzierbarkeit
einer Unterschrift und einer geringeren Relevanz von Übertragungsfehlern bot das Telefax eine
höhere Vertrauenswürdigkeit als die Telegrafie. In den 1920er Jahren kam dann die
Übertragung von Bildern für die Veröffentlichung in Zeitungen als Einsatzgebiet hinzu. Das
Versenden von Wetterkarten an Schiffe, Flugzeuge oder Zeitungen ist als ein weiterer wichtiger
Anwendungsfall zu nennen. Militärisch wurde das Telefax zum Austausch von Kartenmaterial
und darauf verzeichneten Feindpositionen genutzt.
In den USA wurden auch noch speziellere Einsatzszenarien getestet. So installierte man
mobile Empfänger in Polizeifahrzeugen, um Fingerabdrücke und Fotos gesuchter Personen von
einer Polizeidienststelle aus zu versenden. Für kurze Zeit wurde das Telefax auch als
Rundfunkdienst angeboten. Mit der Verbreitung des Fernsehens wurde dieser Dienst aber
wieder eingestellt. Ende der 1940er Jahre wurde zudem ein System entwickelt, das neben
Dokumenten und Ton auch Filme versenden konnte. Das sogenannte Ultrafax kann als eine Art
früher Vorläufer des Internet angesehen werden. Aus wirtschaftlichen Gründen blieb es jedoch
lediglich bei einem Demonstrationsbetrieb.
Mit den fallenden Kosten für Endgeräte und für die Übermittlung von Dokumenten wurde
das Telefax auch für Privatpersonen und kleinere Unternehmen interessant. Insbesondere für
die Bearbeitung von Kundenaufträgen besitzt der Dienst noch heute einen hohen Stellenwert.
In Deutschland kann dies mit der häufigen rechtlichen Anerkennung von Empfangsbestätigungen begründet werden. Die Empfehlungen der ITU-T (siehe Anhang K) ermöglichen
zudem einen internationalen Austausch von Dokumenten. Zum Sicherstellen der Kompatibilität
folgen die Hersteller bis heute der ITU-T Empfehlung T.30, welche die Datenübertragung mit
akustischen Signalen via Modem festlegt. Mittlerweile sind Faxe in schwarz-weiß, in Graustufen
oder in Farbe sowie in unterschiedlichen, vordefinierten Auflösungen möglich. Neben dem
aktiven Versand von Faxen können diese über einen Faxabruf auch aktiv empfangen werden.
[RENSEN][LIGHT S.358-367]
3.5 Radio
Die Voraussetzungen für eine drahtlose Kommunikation wurden in der zweiten Hälfte des 19.
Jahrhunderts von bedeutenden Physikern, wie Alexander Stepanowitsch Popow, James Clerk
Maxwell und Heinrich Rudolf Hertz geschaffen. Als erste Anwendung kann die Telegrafie
genannt werden, mit der Guglielmo Marchese Marconi 1901 die erste transatlantische
Funkübertragung durchführte.
Da es vor 1912 keine gesetzlichen Regulierungen für Funkübertragungen in den USA gab,
bauten hier viele Amateure in den frühen 1900er Jahren eigene Funkgeräte. Mit diesen konnte
zunächst nur Telegrafie, später aber auch Sprache übertragen werden. 1918, während des
17
ersten Weltkriegs sendete dann das amerikanische Militär ein erstes Unterhaltungsprogramm
für verwundete Soldaten. Mit Kriegsende gewannen schließlich Rundfunkübertragungen von
Musik und gesprochenen Nachrichten an Popularität. Große Elektronikhersteller sahen darin
eine Möglichkeit um ihre Geräte zu vermarkten. Bis Ende 1922 entstanden außerdem über 500
kleine regionale Radiostationen, die durch Unternehmen, Organisationen oder Einzelpersonen
finanziert wurden. [EARLYRADIOHISTORY]
In Deutschland wurde der Rundfunk von Anfang an staatlich betrieben und nach dem
zweiten Weltkrieg von den Besatzungsmächten kontrolliert. So wurde ab 1950 der
Kopenhagener Wellenplan wirksam, der in jeder Besatzungszone die Nutzung von genau einer
Mittelwellenfrequenz erlaubte. Man entschied daher die Übertragung von Radiosendungen in
den UKW-Bereich zu verlegen, der aufgrund seiner geringeren Reichweite zunächst unbeliebt
war. Entfernte Sender können im UKW-Bereich jedoch die selben Frequenzen nutzen, wodurch
lokal eine höhere Bandbreite zur Verfügung steht. Auf diese Weise konnten bald mehrere
Programme in einem Gebiet gesendet und eine bessere Tonqualität erreicht werden. Ab 1986
wurde das staatliche
[CHOWANETZ]
Monopol
aufgehoben
und
private
Rundfunkanbieter
zugelassen.
3.6 Fernsehen
Neben der Übertragung von Dokumenten wurde Ende des 19. Jahrhunderts auch an der
Übertragung von bewegten Bildern gearbeitet. In diesem Zusammenhang wird häufig Paul
Julius Gottlieb Nipkow genannt, der mit einer Spirallochscheibe sowohl eine Bildabtastung als
auch eine Wiedergabe realisierte. Die Ausmaße einer solchen Scheibe schränkten jedoch die
Bildgröße, Auflösung und Bildwiederholfrequenz stark ein. Daher konnte sich auf der
Empfängerseite recht bald die von Karl Ferdinand Braun entwickelte Kathodenstrahlröhre
durchsetzen. Die Abtastung konnte erst ab 1933 durch ein von Vladimir Kosma Zworykin
patentierten elektronischen Bildabtaster übernommen werden.
Der erste regelmäßige Fernsehprogrammdienst wurde 1935 in Deutschland gestartet. Die
Übertragungen wurden zunächst mit Bildwiederholraten von bis zu 25Hz durchgeführt, so dass
ein deutliches Flimmern wahrgenommen werden konnte. Aus diesem Grund ging 1937 das
Zeilensprungverfahren in die deutsche Fernsehnorm ein. Dabei werden abwechselnd die
geraden und ungeraden Zeilen eines Bildes als Halbbild dargestellt, wodurch sich die
Bildwiederholrate verdoppelt.
Nach dem Ende des zweiten Weltkriegs wurde in den USA die Gerber-Norm mit 525 Zeilen
bei 30 ganzen Bildern pro Sekunde eingeführt. Dieses wurde 1954 durch das NTSC-Verfahren
abgelöst, um Übertragungen in Farbe zu ermöglichen. In Deutschland wurde die Gerber-Norm
mit 625 Zeilen und 25 ganzen Bildern pro Sekunde umgesetzt. Hier wurde das Farbfernsehen
erst 1967 mit dem PAL-System eingeführt, welches im Vergleich mit NTSC aber eine bessere
Bildqualität erreicht. [BUCHHOLZ][NALDINI]
Seit der Einführung des Fernsehens wurden die Empfangsgeräte als auch die Übertragungstechniken stetig weiterentwickelt. 1950 kamen so zunächst die ersten kabelgebundenen und
ab 1956 auch kabellose Fernbedienung auf den Markt. Weitere wichtige Entwicklungen sind der
Videorekorder sowie der Teletext:
18
Da die Aufzeichnung von Sendungen gerade für Fernsehsender eine wichtige Rolle spielt,
wurden bereits vor dem zweiten Weltkrieg experimentelle Aufnahmegeräte konstruiert. Aber
erst 1956 stellte die Firma Ampex einen kommerziellen Rekorder vor, der das volle Signal
gemäß Gerber-Norm sichern konnte. Die ersten Geräte für den Heimgebrauch wurden dann
1964 eingeführt. [TVHISTORY]
Anfang der 1970er Jahre verwendeten Techniker der BBC zum ersten Mal die freien Zeilen
des Fernsehsignals, um zusätzliche Informationen zu übertragen. Ab 1976 boten die
Fernsehsender BBC und IBA dann ein regelmäßiges Teletextprogramm an. Neben kostenlosen
Informationen wurden hier auch gebührenpflichtige Dienste für Handelsketten und Wettbüros
angeboten. Mit dem Feldversuch von ARD und ZDF im Jahr 1980 hat sich dann der Teletext
auch in Deutschland etabliert. [BOETTLERCERNKO]
3.7 Digitaler Rundfunk
Mit den 1990er Jahren hatten Politik und Wirtschaft entschieden, den analogen Rundfunk durch
digitale Techniken abzulösen. Auf diese Weise sollte eine bessere Dienstqualität und eine
größere Programmvielfalt realisiert werden.
1994 startete in den USA das erste digitale Fernsehprogramm, dass mit zwei Satelliten bis
zu 150 NTSC-Programme ausstrahlte. Einige Radiostationen begannen zudem Ihr Programm
über das Internet zu versenden. Im gleichen Jahr wurde auch die Übertragungstechnik ADSL
erstmals produktiv eingesetzt, um einen Video-on-Demand-Dienst anzubieten. Bei diesem
wählt der Zuschauer zunächst einen Film aus und kann ihn dann unabhängig von Sendezeiten
anschauen.
1997 wurde der Digital Audio Broadcast (DAB) Standard eingeführt, mit dem ein digitales
Audioprogramm mit terrestrischer Funktechnik übertragen wird. 1998 folgte das Digital Radio
Mondial (DRM), das im Kurz-, Mittel- und Langwellenspektrum sendet und somit vor allem
große Empfangsbereiche abdeckt.
Das terrestrische digitale Fernsehen (DVB-T) wurde in Deutschland ab 2002 flächendeckend
eingeführt. Neben der terrestrischen Variante existieren außerdem Varianten für das digitale
Satelliten- (DVB-S) und Kabelfernsehen (DVB-C) sowie eine weitere terrestrische Variante für
kleine mobile Geräte (DVB-H). Die einzelnen Varianten unterscheiden sich im Wesentlichen
durch das Empfangsteil und die zur Verfügung stehende Datenrate. Zur Kompression wird bei
allen Varianten der MPEG2-Standard eingesetzt. [BLANK S.5-8,11,13-14,17-18]
3.8 Bildtelefonie
Bei der
Bildtelefonie werden neben dem Ton
auch die visuellen Informationen der
Gesprächspartner übertragen. Da hierfür eine große Bandbreite notwendig ist, wurde diese
Kommunikationsform zunächst nur selten genutzt. Als frühes Anwendungsbeispiel kann der
Fernseh-Sprechdienst genannt werden, der 1936 während der Berliner Olympiade in 25
Fernsehstuben angeboten wurde. Verbindungen waren jedoch nur zwischen den Städten Berlin
und Leipzig möglich. [BUCHHOLZ]
19
In den 1960er Jahren brachte AT&T verschiedene Modelle des Picturephones auf den Markt,
die allerdings wenig Verbreitung fanden. In den 1970er und 1980er Jahren wurden dann
Videokonferenzstudios zum Standard. Die Kommunikation zwischen den Geräten wurde jedoch
erst 1990 mit der CCITT-Empfehlung H.320 vereinheitlicht. [WALTER][GARTVIHS]
Mit der Verbreitung des Internet wurde Mitte der 1990er Jahre der PC als Plattform für die
Bildtelefonie entdeckt. Spezielle Kameras und Software zum Führen von Videokonferenzen
wurden zu geringen Preisen angeboten. Sie erbrachten durch Kompressionstechniken
brauchbare und dennoch kostengünstige Ergebnisse. Mittlerweile kann die Bildtelefonie über
das Internet als Standardanwendung gesehen werden.
Im Mobiltelefonbereich wurden ab dem Jahr 2000 erste Geräte mit integrierter Kamera
verkauft. Mit der Einführung von UMTS kamen dann Geräte auf den Markt, mit denen auch ein
mobiler Bildtelefondienst möglich ist.
3.9 Network Voice Protocol
Das NVP kann als Vorläufer der heutigen VoIP Protokolle gesehen werden. Es wurde 1976 im
[RFC 741] spezifiziert und sollte zeigen, dass eine Zweiwegekommunikation über paketbasierte
Netzwerke in Echtzeit realisierbar ist. Dabei galt es, eine gute Sprachqualität bei einer
geringen Bandbreite zu erreichen. Das NVP wurde erstmals 1973 implementiert und im
ARPANET getestet.
Das Protokoll lässt sich in ein Steuerungs- und ein Datenprotokoll unterteilen. Mit dem
Steuerungsprotokoll kann u.a. ein Anruf, die Bereitschaft einen Anruf entgegenzunehmen, das
Klingeln oder das Ende eines Gesprächs signalisiert werden. Das Datenprotokoll transportiert
dann die Sprachdaten in einzelnen durchnummerierten Paketen, deren Größe während des
Verbindungsaufbaus ausgehandelt wird. Mehrere Pakete können zu einer Nachricht
zusammengefasst werden, die zur Synchronisation wiederum mit einem Zeitstempel versehen
werden.
20
4. Mehrwertdienste in der "klassischen Telekommunikation"
Mehrwertdienste (Value Added Services) werden in diesem Text als Leistungen verstanden, die
über eine Hauptanwendung, also Telefonie, Radio oder Fernsehen hinaus gehen. Im Folgenden
werden bislang etablierte oder auch ehemals verbreitete Mehrwertdienste aufgeführt.
4.1 ISDN-Dienste
Die ITU-T unterteilt in der Empfehlung [I.210] die Telekommunikationsdienste in Trägerdienste
(Bearer Services) und Basisdienste (Teleservices), welche wiederum jeweils eine Klasse von
Zusatzdiensten (Supplementary Services) enthalten. Für Trägerdienste werden jedoch lediglich
Datenraten, Verwendungszwecke (I.131) und die Möglichkeit einer paketbasierten Übertragung
(I.132) spezifiziert. Zusatzdienste finden in diesem Zusammenhang keine Erwähnung. Daher
werden hier ausschließlich Basisdienste und die dafür spezifizierten Zusatzdienste betrachtet.
Letztere werden auch als Dienstmerkmale bezeichnet.
4.1.1 ISDN-Basisdienste
Die Empfehlung [I.240] führt sogenannte Basisdienste auf, die als Hauptanwendung von ISDN
gesehen werden können.
I.241.1 Telephony
Telefonie ermöglicht eine Zweiwege-Sprachkommunikation in Echtzeit über ein Netzwerk und
ist hinreichend bekannt.
I.241.2 Teletex
Teletex ist ein internationaler Dienst zur Abwicklung von Schriftverkehr. Texte werden mit
einem standardisierten Teletex-Zeichensatz kodiert und in den Speicher geladen. Die
Verbindung wird aufgebaut, der Text übertragen und die Verbindung schließlich wieder
abgebaut.
I.241.3 Telefax 4
Wie bei Teletex handelt es sich bei Telefax um einen internationalen Dienst zur Abwicklung von
Schriftverkehr. Hier werden die Informationen jedoch faksimilekodiert (siehe 3.4).
I.241.4 Mixed-Mode
Die mittlerweile hinfällige Empfehlung F.230 erlaubt einen Mixed-Mode, mit dem sowohl
zeichensatzbasierter Text als auch Informationen in Faksimilekodierung übertragen werden
können. Die Empfehlung I.241.4 enthält einen Auszug des Dokuments.
21
1.241.5 Videotex
Der Videotexdienst bietet Empfangs- und Hinterlegungsfunktionen (Briefkasten) für Texte und
Grafiken. Er basiert auf der zurückgezogenen Empfehlung F.300 und entspricht dem deutschen
Bildschirmtext oder dem französischen Minitel.
I.241.6 Telex
Beim ursprünglichen Fernschreiben werden die Zeichen eines Textes direkt übertragen und
nicht, wie beim Teletex, zwischengespeichert. Ein Teilnehmer kann also direkt auf die Eingaben
eines anderen Teilnehmers reagieren.
I.241.7 Telephony 7kHz Teleservice
Dieser Dienst verbessert die Klangqualität der Telefonie. Er erweitert den Frequenzbereich bei
Telefongesprächen auf max. 7kHz, sofern die Endgeräte dies unterstützen. [I.241.7]
I.241.8 Teleaction Stage One Service Description
Unter Teleaction versteht man die gesicherte Übertragung eines geringen Datenvolumens zur
Fernsteuerung und Überwachung von Objekten. [I.241.7]
4.1.2 ISDN-Dienstmerkmale
In der Empfehlung [I.250] werden sogenannte Dienstmerkmale aufgelistet, welche die
Möglichkeiten der Telefonie erweitern. Zusätzlich zu den hier aufgeführten Merkmalen sind im
Laufe der Zeit einige weitere hinzugekommen.
I.251 Number Identification supplementary services
Die Dienste zur Teilnehmeridentifikation beschreiben die Möglichkeit Informationen, wie die
Rufnummer oder den Namen eines Teilnehmers an eine Gegenstelle zu übermitteln (CLIP,
COLP, CNIP) oder die Übermittlung zu unterbinden (CLIR, COLR, CNIR). Des Weiteren kann
eine Verbindung im Netzwerk registriert werden, um z.B. störende, anonyme Anrufer ausfindig
zu machen (MCI). Es wird dargelegt wie Rufnummern an eine Schnittstelle (MSN) und
erweiterte Rufnummern an einzelne Geräte (SUB) gebunden werden können. Zudem wird die
Vermittlung eines internen Anrufs über eine Telefonanlage (auch ISPBX) beschrieben (DDI).
I.252 Call Offering supplementary services
Die Dienste zur Anrufweiterleitung differenzieren Situationen in denen eine Weiterleitung
erfolgen kann. So wird unterschieden, ob ein Gespräch bereits besteht (CT) oder der Anruf erst
signalisiert wird. Geht ein Anruf gerade ein, ist eine unbedingte Weiterleitung (CD, CFU) oder
eine Weiterleitung bei besetzt (CFB) möglich. Wird ein Gespräch nicht entgegengenommen
(CFNR), kann dieses ebenfalls weitergeleitet werden. Eine Menge eingehender Anrufe kann auf
verschiedene Geräte verteilt werden (LH), um z.B. Call Center Dienste zu realisieren. Es ist
auch möglich die Gesprächspartner von zwei gleichzeitig geführten Gesprächen miteinander zu
verbinden (ECT).
22
I.253 Call Completion supplementary services
Die Dienste zur Vervollständigung eines Anrufs beschreiben das Anklopfen (CW) sowie das
Halten eines Gesprächs (HOLD). Das Anklopfen signalisiert einem Teilnehmer während eines
laufenden Gesprächs einen weiteren eingehenden Anruf. Der Teilnehmer kann dann
entscheiden, ob er das Gespräch annimmt, zurückweist oder den Anruf ignoriert. Das Halten
eines Gesprächs ermöglicht es ein laufendes Gespräch zu unterbrechen, um es ggf. wieder
aufnehmen zu können. Der Wechsel zwischen den Gesprächen wird auch als Makeln
bezeichnet.
Der Dienst "Anruf bei besetzt" signalisiert einem Teilnehmer, dass ein zuvor besetztes Gerät
frei geworden ist. Auf Wunsch reinitiiert der Dienstanbieter dann den Anruf (CCBS). Es kann
außerdem signalisiert werden, wenn ein zuvor nicht erreichbarer Teilnehmer eine Aktivität an
einem Gerät beendet hat. Dieser sollte somit wieder erreichbar sein (CCNR).
I.254 Multiparty supplementary services
Die Dienste für Situationen mit mehreren Teilnehmern beinhalten zwei Konzepte für
Konferenzschaltungen. So können bei einer Add-On-Konferenz die Teilnehmer nacheinander
hinzugefügt werden (CONF). Bei einer Meet-Me-Konferenz wird der Dienst von einem Benutzer
für eine definierte Zeitspanne gebucht. Jedem Benutzer steht währenddessen
Spezialnummer zur Verfügung über die er an der Konferenz teilnehmen kann (MMC).
eine
Neben den Konferenzschaltungen wird die Kommunikation zwischen drei Teilnehmern
gesondert betrachtet (3PTY). Der Drei-Parteien-Dienst erlaubt es während eines laufenden
Gesprächs die Anruf-Halten-Funktion zu verwenden, um einen weiteren Anruf tätigen zu
können. Es ist dann möglich zwischen den Gesprächen zu wechseln. Optional kann auch eine
Drei-Wege-Kommunikation zwischen den Teilnehmern eingerichtet werden.
I.255 Community of Interest supplementary services
Die Dienste für Interessengemeinschaften spezifizieren die Verwendung von Benutzergruppen
(CUG). Ein Teilnehmer kann dabei Mitglied in verschiedenen Gruppen sein. Benutzergruppen
können einen eigenen Rufnummernplan haben, der vom öffentlichen Rufnummernplan
abweicht (PNP). Dies ist z.B. bei Unternehmen mit verteilten Gebäuden sinnvoll. Die
Kommunikation mit und von einer Gruppe kann zudem beschränkt werden. Eine
Rufnummernsperre für ausgehende Anrufe ist ebenfalls möglich (OCB). Die Gruppierung von
Teilnehmern erlaubt es ein- und ausgehende Anrufe zu priorisieren (Priority Services). Die
Ressourcen laufender, niedrig priorisierter Gespräche können außerdem übernommen werden
(MLPP).
I.256 Charging supplementary services
Der Gebührennachweisdienst (AOC) übermittelt Preisinformationen an einen Teilnehmer. Dabei
ist es möglich die verbrauchten Einheiten während oder am Ende eines Gesprächs zu
übertragen. Eine andere Möglichkeit besteht darin, die Tarifinformationen zu Beginn eines
Gesprächs zu übermitteln und die anfallenden Kosten während des Gesprächs zu aktualisieren.
Mit den Diensten zur Abrechnung der erbrachten Leistung werden Kunden über anfallende
23
Kosten informiert und erhalten die von ihnen gewünschten Zahlungsmodalitäten.
Bei einem R-Gespräch (REV) werden die Kosten vom angerufenen Teilnehmer getragen,
sofern sich dieser dazu bereit erklärt. Diese Art der Bezahlung sowie der auf diese Weise
abzurechnende Zeitraum kann ggf. erst während eines Gesprächs gewählt werden.
I.257 Additional Information Transfer supplementary service
Bislang wurde nur ein Dienst zur Übertragung von Zusatzinformationen definiert (UUS). Dieser
erlaubt es einem Benutzer Nachrichten mit bis zu 128 Zeichen über den Signalisierungskanal
zu versenden, um z.B. das Thema eines Anrufs anzukündigen oder einen Grund für das
Ablehnen oder das Beenden einer Verbindung anzugeben.
weitere ISDN-Zusatzdienste
Es gibt zwei Dienste zur Unterstützung der Mobilität von Endgeräten. In diesen wird die
Beweglichkeit eines mobilen Endgerätes zwischen verschiedenen Basisstationen (TP) sowie die
Veränderung der Konfiguration eines laufenden Gesprächs (IM) beschrieben. Ein weiterer
Dienst richtet sich gegen den Missbrauch von Diensten und soll sicherstellen, dass ein
Teilnehmer nur Daten von und zu bestimmten anderen Teilnehmern senden kann (ADS).
4.2 GSM-Dienste
Analog zum ISDN unterscheidet die ETSI im Standard [02.01] zwischen Basis- und
Zusatzdiensten. Da es sich bei GSM um einen Mobilfunkstandard handelt, werden u.a. Dienste
beschrieben, die spezielle Mobilitätsanforderungen erfüllen.
4.2.1 GSM-Basisdienste
Der Standard [02.03] charakterisiert vier Hauptanwendungen die jeweils in kleinere
Basisdienste (Teleservices = TS) unterteilt sind.
TS12 Emergency Calls
Neben der Telefonie (TS11) werden Notrufe bei GSM als gesonderter Basisdienst betrachtet.
Um auch netzfremden Teilnehmern einen Zugriff darauf zu erlauben, wird ein standardisierter
Zugang zu einem GSM-Netz vorgeschrieben. Nationale Notrufnummern müssen erkannt und
nach nationalen Regulierungen an entsprechende Stellen weitergeleitet werden. Alle
Beschränkungen des Netzwerks und des Mobiltelefons müssen dazu ggf. übergangen werden.
Teilnehmer ohne Geräte- oder Teilnehmeridentifizierung können jedoch vom Notrufsystem
ausgeschlossen werden. Auf diese Weise kann ein Anbieter im Falle eines Missbrauchs die
Identität des Teilnehmers bestimmen.
TS21 - TS23 Short Message
Im Standard [02.03] werden drei Arten von Kurznachrichten unterschieden. So gibt es
Kurznachrichten die an ein mobiles Gerät (TS21: Mobile Termination/Punkt-zu-Punkt), von
24
einem mobilen Gerät (TS22: Mobile Origination/Punkt-zu-Punkt) oder an alle mobilen Geräte
einer Basisstation (TS23: Cell Broadcast) übermittelt werden. Die Nachrichten werden dabei
immer über eine Dienstzentrale versendet. Das gilt auch, wenn sich zwei mobile Geräte in
unmittelbarer Nähe zueinander befinden.
Bei Punkt-zu-Punkt-Nachrichten arbeitet eine Dienstzentrale nach dem Store-and-ForwardPrinzip. Sie darf Nachrichten beliebiger Quellen (Sprache, Telefax, usw.) annehmen und diese
dann im Format einer Kurznachricht an ein mobiles Gerät weiterleiten. Die Länge des Textes ist
auf 160 Zeichen begrenzt. Kann eine Zentrale eine Kurznachricht nicht innerhalb ihrer
Gültigkeitsdauer zustellen, werden keine weiteren Sendeversuche unternommen.
Mit dem Versand einer Nachricht kann einem Empfänger auch ein Antwortpfad (Reply Path)
zur Verfügung gestellt werden. Die Dienstzentrale garantiert dann, eine einzelne Antwort zum
Ausgangspunkt zurückzuführen. Der Ausgangspunkt trägt in diesem Fall die Gesamtkosten.
Nach dem Empfang einer Punkt-zu-Punkt-Nachricht muss jeweils eine Bestätigung an die
Gegenstelle zurückgesendet werden. Auf Wunsch kann eine Zentrale auch den Ausgangspunkt
einer Nachricht über den Erfolg der Zustellung informieren.
Möchte ein Dienstleister ein bestimmtes Gebiet mit Informationen versorgen, kann er
spezielle Broadcast-Nachrichten verwenden. Diese werden nicht bestätigt und enthalten eine
Identifikation, anhand der ein Empfänger feststellen kann, ob eine Nachricht erwünscht ist
oder ob sie bereits empfangen wurde. Broadcast-Nachrichten haben eine maximale Länge von
93 Zeichen und können mit weiteren Broadcast-Nachrichten zu einer größeren Nachricht
zusammengesetzt werden.
TS61 - TS62 Facsimile
Der GSM Basisdienst TS62 (Automatic Facsimile G3) erlaubt es Faxgeräte der Gruppe 3 (siehe
Anhang K) an mobile Geräte anzuschließen. Dazu wird ein Faxadapter verwendet, der zwischen
den akustischen Signalen des Faxmodems und den digitalen Daten eines mobilen Gerätes
konvertiert (siehe [03.45 S.9-10]). Für die Übermittlung von Telefaxdaten können mehrere
Fullrate Datenkanäle verwendet werden. Dieses Vorgehen ermöglicht eine maximale
Datenübertragungsrate von 14,4kbit/s, die von vielen Faxgeräten heute angeboten wird. Der
Basisdienst TS61 (Alternate Speech/Facsimile G3) erlaubt darüber hinaus die abwechselnde
Übertragung von Sprache und Telefaxdokumenten. Dies wird mit Signalisierungsnachrichten
realisiert, mit denen die Kanalkonfiguration entsprechend geändert werden kann (siehe [03.45
S.16ff]).
TS91 - TS92 Gruppendienste für Sprachen
Vergleichbar zum Funk wird mit dem Basisdienst TS92 (Voice Broadcast Service) die
Übertragung von Sprache an eine vordefinierte Personengruppe beschrieben. Die Mitglieder
können solche Sprachnachrichten mit einer Gruppenidentifikationsnummer im Netz
abonnieren. Der Empfangsbereich wird zuvor vom Dienstanbieter in Zusammenarbeit mit dem
Netzbetreiber festgelegt.
Der Dienst TS91 (Voice Group Call Service) bietet für Abonnenten zusätzlich die Möglichkeit,
selbst Sprachnachrichten zu versenden. Im Gegensatz zur Telefonie findet eine Konversation
25
hier aber in einem Halbduplexmodus statt. [02.03 S.18-19]
4.2.2 GSM-Zusatzdienste
Bei einem Vergleich zwischen GSM- und IDSN-Zusatzdiensten fällt auf, dass es eine große
Schnittmenge gibt. Innerhalb der GSM-Standards wird daher explizit auf das Zusammenwirken
entsprechender Dienste eingegangen. Hier werden nun zwei ausgewählte Dienste aufgeführt,
die jeweils eine Erweiterung eines ISDN-Zusatzdienstes darstellen. Andere Dienste werden
nicht betrachtet, da Sie im Wesentlichen von Punkt 4.1.2 abgedeckt werden.
02.82 Call Offering
Zusätzlich zu den bei ISDN beschriebenen Situationen für Umleitungen, erlaubt GSM eine
Weiterleitung, falls ein Empfänger nicht erreichbar ist. Dieser Fall tritt auf, wenn die
Netzabdeckung in einem Gebiet nicht vollständig ist oder ein Gebiet mit Netzabdeckung
verlassen wird. Ein mobiles Gerät kann außerdem deaktiviert werden. Bei GSM wird die
Weiterleitung häufig in Verbindung mit einem netzinternen Anrufbeantworterdienst verwendet.
[02.82]
02.88 Call Restriction
Neben
den
Beschränkungen
geschlossenen
für
Benutzergruppen,
ein-
und
können
ausgehende
mit
GSM
Gespräche
weitere
grobe
im
Rahmen
von
Beschränkungen
vorgenommen werden. So können alle, alle internationalen oder internationale Gespräche, die
nicht über das eigene Netz laufen blockiert werden. Zudem ist es möglich alle eingehenden
Gespräche oder solche die per Roaming vermittelt werden abzulehnen. Ausgenommen hiervon
sind Notrufnummern. [02.88]
4.2.3 Open Mobile Alliance
Im Jahr 2002 haben sich verschiedene Mobilfunkunternehmen zur Open Mobile Alliance
zusammengeschlossen, um zusammen an neuen offen Standards zu arbeiten. Dies soll die
Interoperabilität zwischen verschiedenen Anbietern vorantreiben und die Kosten für die
Entwicklung neuer Technologien senken. Zur Zeit gibt es eine Reihe von Arbeitsgruppen, die
sich
mit
verschiedenen
Anwendungsgebieten
beschäftigen.
Dazu
gehören
u.a.
Sicherheitsfragen, die Verbreitung von Inhalten und die Lokalisierung von Geräten. Einige
Arbeiten finden seit geraumer Zeit Anwendung. [OMA]
Multimedia Message Service (MMS)
Der Multimedia Nachrichten Dienst erlaubt es verschiedene Medien in einer Nachricht
zusammenzufassen. Zur Beschreibung der verwendeten Medientypen wird der MIME-Standard
(RFCs 2045-2049) verwendet. Als Haupteigenschaft des Dienstes wird die mögliche
Zusammenarbeit mit anderen verfügbaren Messaging-Systemen, wie E-Mail, Fax oder SMS
angeführt. Eine Multimedia Nachricht wird über Proxy-Relay Server an den MMS-Server eines
Empfängers geleitet und kann dort von diesem heruntergeladen werden. Geht eine neue
26
Nachricht ein, wird der Empfänger von seinem Proxy-Relay Server benachrichtigt. [MMS]
E-Mail Notification (EMN)
Die Benachrichtigung beim Eingang einer neuen E-Mail kann als Mehrwert für den sonst
üblichen E-Mail-Dienst gesehen werden. Sie soll ein Programm auf dem mobilen Gerät eines
Empfängers starten, welches wiederum die E-Mail von einem Server herunterlädt. Dazu
kommen die üblichen Internetprotokolle zum Einsatz. Die Benachrichtigung wird mit Hilfe des
WAP-Push-Frameworks versendet. [EMN]
Push-to-Talk over Cellular (PoC)
Wie der Voice Group Call Service (siehe 4.2.2) spezifiziert der Push-to-Talk Dienst eine
Halbduplexkommunikation. Der Push-to-Talk Dienst ermöglicht jedoch keine Einschränkungen
bezüglich des Empfangsbereichs. Zudem kann immer nur mit einem ausgezeichneten
Teilnehmer gesprochen werden.
Während des Sprechens muss wie bei Funkgeräten eine Trägertaste gehalten werden. Ein
Empfänger kann dann entscheiden, ob er die Sprachnachrichten automatisch empfangen
möchte. Alternativ kann er über die neue Sprachnachricht informiert werden, um dann den
Eingang manuell zu akzeptieren. [PoC]
4.3 Andere Mehrwertdienste für die Telefonie
Diensterufnummern
In Deutschland ist der Begriff "Mehrwertdienst" eng mit Diensterufnummern verknüpft. Diese
beinhalteten den Anrufbeantworter im Netz, Kundendienste, aber auch Gewinnspiele und
Partnervermittlungen. Die Rufnummern werden in Premium Rate-, Freephone und Shared-Cost
Dienste unterteilt und von der Bundesnetzagentur zugewiesen.
Die Kosten für Premium Rate-Dienste können vom Anbieter frei festgelegt werden (siehe
[0900]).
Das
Gesetz
zur
Bekämpfung
des
Missbrauchs
von
0190er-/0900er-
Mehrwertdiensterufnummern [0900 GESETZ] begrenzt jedoch den Preis bei Blocktarifen pro
Verbindung oder bei zeitabhängigen Diensten pro Minute. Für die Nutzung eines FreephoneDienstes dürfen dagegen keine Gebühren anfallen (siehe [0800]). Ausgenommen sind hier
lediglich Gebühren für die Nutzung eines Endgerätes. Bei Shared-Cost-Diensten werden die für
eine Verbindung anfallenden Kosten zwischen dem Anbieter und dem anrufenden Teilnehmer
aufgeteilt. Hier gelten die Tarife des Netzbetreibers (siehe [0180]).
Um die ggf. große Anzahl von Anrufen zu den Diensterufnummern bewältigen zu können,
müssen die Netzbetreiber die Anrufraten beschränken. Der Arbeitskreis der Telekommunikationsnetzbetreiber und -hersteller in Deutschland (AKNN) empfiehlt dazu die
sogenannte Leaky-Bucket-Methode. Bei dieser verringert jeder Anruf die verbleibende
Kapazität, während diese in einem vorgegebenen zeitlichen Intervall wieder erhöht wird.
[E.412 S.4][MABEZ02]
27
Unterhaltungsdienste
Für den Mobilfunkbereich wird seit geraumer Zeit eine Reihe von Unterhaltungsdiensten
angeboten. Dazu gehören Klingeltöne, Hintergrundbilder und Animationen, mit denen ein
Mobiltelefon individuell gestaltet werden kann. Einige Provider ersetzen auch das Freizeichen
durch ein ausgewähltes Musikstück. Mit der Verbreitung von Java-fähigen Geräten ist
außerdem eine große Menge an Spielen entstanden, die via Kurznachricht geordert oder mit
WAP heruntergeladen werden können.
4.4 Radio Data System
Um Radioempfänger benutzerfreundlicher gestaltet zu können, spezifiziert die IEC im Standard
[IEC 62106] das Radio Data System (RDS). Dieses ersetzt die zuvor verbreiteten Autofahrer
Rundfunk Informationen [ARI], bei denen definierte Zustände mit frequenz- und
amplitudenmodulierten Signalen kodiert werden. RDS kann zusammen mit ARI verwendet
werden und überträgt im Gegensatz zu diesem digitale Informationen. Unabhängig von RDS
und ARI signalisiert der sogenannte Hinz-Triller bis heute zusätzlich die Übertragung eines
Verkehrsfunkprogramms. RDS bietet eine Reihe von Diensten, die im Folgenden vorgestellt
werden.
Alternative Frequencies list (AF)
Um einen bestimmten Radiosender an unterschiedlichen Orten wiederzufinden, wird eine Liste
mit alternativen Frequenzen versendet. Diese wird im mobilen Empfänger zwischengespeichert
und dient dazu den stärksten lokalen Sender ausfindig zu machen.
Clock Time and date (CT)
Die interne Uhr eines Empfänger kann via RDS aktualisiert werden. Die Zeit wird als
koordinierte Weltzeit (UTC) und Modified Julian Day (MJD) kodiert.
Coding of Enhanced Other Networks information (EON)
Innerhalb eine Sendergruppe macht es Sinn, wenn ein Sender auch Informationen über andere
Sender verbreitet. Dazu gehören alternative Frequenzen und das aktuelle Programm. Es
können ebenfalls Informationen zur Existenz von Sendern übertragen werden, auf denen lokale
Verkehrsinformationen zu empfangen sind.
Decoder Identification (DI) and dynamic PTY Indicator (PTYI)
Die
Decoder-Identification
enthält
eine
Empfehlung
für
den
Wiedergabemodus
des
Empfängers. Neben Mono und Stereo kann signalisiert werden, dass ein Kunstkopf für die
Aufnahme verwendet wurde oder dass eine Kompression genutzt wird. Zum letzten Punkt gibt
es allerdings keine näheren Ausführungen. Ein Indikator für einen dynamischen Programmtyp
gibt außerdem an, ob der Programmtyp im Laufe der Zeit verändert wird.
28
Emergency Warning Systems (EWS)
Das
Notfallwarnsystem
überträgt
einen
Programmidentifizierungscode
(PI).
In
dem
entsprechenden Programm werden dann die dazugehörigen Nachrichten übertragen.
In House applications (IH)
Daten für interne Anwendungen können nur vom Betreiber eines Senders dekodiert werden.
Mit ihnen können der Ursprung einer Sendung, Informationen zur Fernsteuerung des
Netzwerks oder Nachrichten an Mitarbeiter übertragen werden.
Music Speech switch (MS)
Bei bestimmten Empfangsgeräten können für Sprache und Musik unterschiedliche Lautstärken
vorgegeben werden. Das Gerät erkennt dabei anhand des RDS-Signals, was aktuell gesendet
wird.
Open Data Applications (ODA)
Die IEC erlaubt es Daten für Anwendungen zu spezifizieren, die über den Standard hinaus
gehen. Diese müssen zuvor bei bei einem Registrierungsbüro angemeldet werden und erhalten
jeweils eine eindeutige Anwendungskennung.
Programme Identification (PI) and Extended Country Codes (ECC)
Der Programmidentifizierungscode kennzeichnet ein Radioprogramm, das auf verschiedenen
Frequenzen übertragen wird. Auf diese Weise kann ein Empfänger bei Störungen auf einen
alternativen Kanal ausweichen.
Innerhalb des Bitfeldes wird ebenfalls eine Länderkennung übertragen, für die ursprünglich
vier Bits zur Verfügung standen. Weil sich einige Länder eine Kennung teilen mussten, wurde
die erweiterte Länderkennung eingeführt, die vier weitere Bits verwendet.
Programme Item Number (PIN)
Mit Hilfe dieser Nummer kann ein Programm eindeutig identifiziert werden. Der Hörer erhält so
die Möglichkeit, das gewünschte Radioprogramm im Vorhinein zusammenzustellen.
Programme Service name (PS)
Ein Programmname darf bis zu acht alphanummerische Zeichen enthalten.
Programme TYpe (PTY)
Es können 15 Programmtypen
unterschieden werden. Dazu gehört
Programm, Nachrichten, Aktuelles, Informationen, Sport,
Wissenschaft, Verschiedenes sowie unterschiedliche Musikstile.
Bildung,
ein undefiniertes
Drama,
Kultur,
29
Traffic Message Channel (TMC)
Über den Traffic Message Channel werden kodierte Verkehrsinformationen gesendet, die im
ISO Standard 14819 beschrieben werden. Die Informationen werden heute oftmals von
Navigationsgeräten
berücksichtigen.
verwendet,
um
Verkehrsbehinderungen
bei
der
Routenplanung
zu
RadioText (RT)
Mit RDS können beliebige textuelle Informationen übertragen und von einem geeigneten
Empfänger angezeigt werden. Dabei handelt es sich meist um aktuelle
Programminformationen.
Radio paging (RP)
Es ist möglich Kurznachrichten an einzelne Kunden zu versenden. Für den Empfang sind
spezielle Geräte notwendig, die eine entsprechende Empfängeradresse besitzen.
Traffic Programme (TP) and Traffic Announcement (TA)
Im RDS werden zwei Flags zur Signalisierung eines Verkehrsfunkdienstes beschrieben. Das TPFlag signalisiert, dass auf einem Programm Verkehrsnachrichten gesendet werden. Während
einer solchen Sendung wird dann zusätzlich das TA-Flag gesetzt. Ein Empfänger kann auf diese
Weise automatisch die Lautstärke anpassen und den Wiedergabemodus oder das Programm
wechseln.
4.5 Mehrwertdienste für DAB und DRM
Wie beim analogen werden natürlich auch beim digitalen Radio zusätzliche Informationen
übertragen. Dabei handelt es sich im Wesentlichen um solche, die schon beim RDS betrachtet
wurden. Die Kodierung wird im ETSI Standard EN 300 401 spezifiziert. Zusätzlich gibt es z.B.
die Möglichkeit IP-Datagramme über DAB zu transportieren. Dies wird im ETSI Standard EN
201 735 näher betrachtet.
4.6 Teletext
Im Anhang des ETSI-Standards [EN 300 706] werden Funktionen beschrieben, die mit Hilfe
des Teletextes realisiert werden.
Code of Practice for navigation via FLOF (Anhang H)
Mit dem Full-Level-One-Facilities- (FLOF) System soll die Steuerung des Teletextes vereinfacht
werden. Dafür werden vier farbige Tasten eingeführt, die von einer Teletextseite auf andere
empfohlene Seiten führen.
30
Navigation via Table Of Pages (TOP, Anhang I)
Der TOP-Teletext ist eine Alternative zum FLOF und wurde in einer technischen Richtlinie von
ARD und ZDF spezifiziert. Beim TOP-System werden alle Seiten anhand ihres Themas in Form
einer Baumstruktur miteinander verknüpft. Die vier farbigen Tasten, die auch beim FLOF
verwendet werden haben hier eine feste Bedeutung: Die erste Taste wechselt zur nächsten
Seite innerhalb der aktuellen Gruppe. Die zweite Taste führt zur ersten Seite der nächsten
Gruppe. Mit der dritten Taste kann zum nächsten Informationsblock navigiert werden, der
wiederum verschiedene Gruppen enthält. Die vierte Taste führt durch die zuvor betrachteten
Seiten zurück.
VCR programming and control via Teletext (Anhang K)
Das Video Programme System (VPS) versieht jede Sendung mit einer eindeutigen Kennung
und gibt diese auf Teletextseiten bekannt, die das Fernsehprogramm der nächsten Zeit
enthalten. In einem speziellen Teletextpaket wird dann die Kennung des aktuellen Programms
gesendet und kann mit zuvor ausgewählten Programmkennungen verglichen werden. Auf diese
Weise kann ein Videorekorder aufzuzeichnende Sendungen identifizieren.
Da die Kennungen ebenfalls die Namen der Programmanbieter enthalten, können diese für
einen automatischen Sendersuchlauf genutzt werden. Das sogenannte Automatic Tuning
System (ATS) wird im Anhang B des ETSI Standards [TS 101 231] beschrieben.
Use of Teletext Data for Automatic Channel Installation (Anhang L)
Ein Kabelnetzbetreiber kann den Teletext nutzen, um eine automatische Installation seiner
Programmen zu ermöglichen. Er speist dazu eine spezielle Teletextseite ein, auf der alle
Namen, Kanäle und Frequenzen vorgegeben werden.
Data transmission via Teletext (Anhang M)
Es ist möglich unspezifizierte Daten über Teletextpakete zu transportieren. Diese können
entweder in unsichtbaren Seiten oder in nicht verwendeten Zeilen einer Teletextseite enthalten
sein. Durch die Transportschicht sind auch geschlossene Benutzergruppen möglich, so dass der
Zugang eingeschränkt werden kann. Umgesetzt wird dies mit adressierbaren Nutzern und
einem Verschlüsselungssystem.
Electronic Programme Guide (EPG, Anhang N)
Ein elektronischer Programmführer gibt Auskunft über das Fernsehprogramm verschiedener
Sender und übernimmt somit die Aufgabe einer Fernsehzeitung. Der Herausgeber kann eine
eigene
Menüstruktur
definieren
und
neben
den
Sendezeiten
auch
Inhaltsangaben,
Bewertungen, Vorschaubilder, usw. zur Verfügung stellen.
4.7 Digital Audio Video Council
Das Digital Audio Video Council (DAVIC) wurde 1994 von 222 Firmen aus 25 verschiedenen
Ländern ins Leben gerufen. Dieses sollte international akzeptierte Standards für das Fernsehen
31
der Zukunft entwickeln und wurde dazu durch eine Internetseite und vierteljährliche Treffen
koordiniert. Die Arbeit der Organisation wurde 1999 planmäßig eingestellt und ein Teil der
Ergebnisse bei der ISO und ITR standardisiert.
Die DAVIC-Dokumente enthalten die Versionsnummern 1.0 bis 1.5 und beschreiben
Aspekte, die jeweils auf den Spezifikationen der Vorgängerversionen aufbauen. [DAVIC]
4.7.1 DAVIC 1.4
In den Spezifikationen bis zur Version 1.4 werden u.a. Anwendungsbeispiele vorgestellt, von
denen einige im Folgenden kurz umrissen werden (siehe [PART1 S.36-39,41-44,46-47,53]).
Video on Demand (VoD) bzw. Movies on Demand (MoD)
Ein Zuschauer kann Inhalte zu einem selbstbestimmten Zeitpunkt konsumieren. Inhalte
können Filme, Nachrichten, Dokumentationen aber auch Musik, Hörspiele oder Texte sein.
Teleshopping
Für das Teleshopping bewegt sich ein Kunde durch eine Einkaufsumgebung, in der er Produkte
auswählen kann. Er erhält Bilder, Texte und audiovisuelle Beschreibungen zu einem Produkt
und kann sich durch real existierendes Verkaufspersonal beraten lassen. Ist ein Produkt für
den Kunden interessant, kann er sich dieses zurücklegen lassen oder die Zahlungsweise
festlegen.
Near Video on Demand (NVoD)
Echte On-Demand-Dienste benötigen Punkt-zu-Punkt-Verbindungen, um jeden Zuschauer
individuell mit Inhalten versorgen zu können. Da dies nicht immer möglich ist, gibt der NearVideo-on-Demand-Dienst die Startzeitpunkte für die Übertragung einer Sendung vor. Um eine
Art Pausefunktion zu ermöglichen, kann der Zuschauer auf einen anderen Kanal wechseln, bei
dem der Startzeitpunkt weiter hinten liegt. Die Pausezeit wird durch den zeitlichen Versatz der
Sendungen vorgegeben.
Delayed Broadcast
Der Anbieter oder Endkunde stellt ein Rundfunkprogramm zusammen und sichert die
Zusammenstellung im Netzwerk oder beim Anbieter. Das Programm kann dann zu einem
späteren Zeitpunkt via VoD oder NVoD von Endkunden empfangen werden.
Telework
Beim Telework steht dem Benutzer ein Verzeichnisdienst und der Zugang zu einem Forum zur
Verfügung. Er kann Informationen an andere Benutzer weiterleiten, über einen
Konferenzdienst mit bis zu zwei anderen Benutzern kommunizieren und gemeinsam eine
Anwendung bedienen.
32
Content Production
Ein Benutzer kann selbst Inhalte produzieren, um diese anderen Benutzern zur Verfügung zu
stellen. Dies kann als Hobby, aber auch geschäftlich betrieben werden.
4.7.2 TV Anytime and TV Anywhere
Mit der digitalen Übertragung von Rundfunksendungen ergibt sich die Möglichkeit, diese auf
digitalen Datenträgern aufzuzeichnen. Die Inhalte können dann über ein Netzwerk zu
beliebigen Zeiten an beliebigen Orten konsumiert werden.
An dieser Stelle wird ein Überblick über die "TV Anytime and TV Anywhere"
Anwendungsszenarien gegeben (siehe [TVANY S.6-18]), die Teil der DAVIC 1.5 Spezifikationen
sind.
Broadcast Capture
Mit Hilfe eines elektronischen Programmführers oder des Internet kann ein Zuschauer eine
Sendung zur Aufnahme vormerken. Zusätzlich gibt es die Möglichkeit einen Agenten
einzusetzen, der Sendungen anhand vorgegebener Charakteristika auswählt. Natürlich kann
der Zuschauer die Aufnahme einer Sendung auch sofort starten.
Eine Erweiterung der sofortigen Aufnahme stellt das dynamische Fernsehen zur Verfügung,
das heute auch als Time Shifting bekannt ist. Dies erlaubt das gleichzeitige Aufnehmen und
Abspielen einer Sendung, um währenddessen die Pause-, Rücklauf- oder Slow-Motion-Funktion
nutzen zu können.
Video File Transfer
In einer grafischen Benutzungsschnittstelle wird eine Liste mit verfügbaren Filmen angezeigt.
Der Benutzer kann einen Titel auswählen, um diesen sofort oder zu einem späteren Zeitpunkt
anzuschauen. Der Film wird dann mit einer entsprechenden Geschwindigkeit heruntergeladen.
Es ist auch möglich, dass ein Anbieter Inhalte bei einem Benutzer hochlädt, um diese hier
vorrätig zu halten. Die Zahlung kann einmalig erfolgen oder es wird für eine bestimmte Anzahl
an Vorführungen abgerechnet.
Remote Stream Access
Ist ein Zuschauer nicht Zuhause, hat er u.U. das Bedürfnis das Fernsehprogramm des
regionalen Anbieters, bereits erworbene Filme oder aufgezeichnete Sendungen zu sehen. Dazu
können die Inhalte über ein Netzwerk in ein Hotelzimmer oder zum Mobiltelefon transportiert
werden. Auf diese Weise können auch Übertragungen aus anderen Regionen zu Hause
empfangen werden.
Web Links
Während der Ausstrahlung eines Fernsehprogramms können Referenzen zu Web-Seiten
gesendet werden, auf denen Zusatzinformationen zum Programm angeboten werden. Der
Zuschauer hat die Möglichkeit die Webseiten während der Sendung zu betrachten oder diese
33
als Lesezeichen zu speichern.
Segment Jumping
Obgleich Filmmaterial oftmals in linearer Form vorliegt, kann dieses dennoch nichtlinear
verwendet werden. Dazu können Verknüpfungen innerhalb eines Filmsegments existieren, mit
denen die nachfolgend abgespielten Segmente bestimmt werden. Es sind auch Referenzen
zwischen Video und nicht Videoinhalten möglich. Verknüpfungen innerhalb von Filmen werden
heute z.B. bei DVD-Menüs verwendet.
Content Customization
In verschiedenen Situationen kann es sinnvoll sein, die Inhalte nach gewissen Kriterien an
Zuschauer anzupassen. So können Sender lokale Werbespots ausstrahlen oder eine globale
Werbung mit lokalen Informationen ergänzen. Daten wie das Alter oder Geschlecht können
ebenfalls Einfluss auf die Auswahl der Werbespots haben. Das Alter kann zudem bestimmen,
ob eine Sendung für Minderjährige geeignet ist. Eine weitere Anwendung ist die Auswahl der
Sprache oder Untertitel. Es kann auch vorkommen, dass die Bandbreite für bestimmte Inhalte
nicht ausreicht. In diesem Fall könnte eine Übertragung vorgezogen und lokal zwischengespeichert werden, so dass diese zum eigentlichen Sendezeitpunkt vorliegt. Die Anpassung
von Inhalten kann z.B. mit Segment Jumping realisiert werden.
34
5. IP-Technik
In den 1970er Jahren existierten bereits einige Computernetzwerke, die im Wesentlichen von
amerikanischen Forschungsanstalten und dem US-Militär betrieben wurden. Während das
Militär vor allem an einem ausfallsicherem Netz interessiert war, wollten die Forschungsanstalten die begrenzten Rechenressourcen möglichst effizient ausnutzen. Mit diesen Zielen
wurde 1974 das Transmission Control Protocol (TCP) entwickelt. Dieses konnte verschiedene
paketbasierte Netzwerke miteinander verbinden, ohne dass die zugrundeliegende Technologie
bekannt sein musste. 1978 wurde das Protokoll in die Bestandteile TCP und IP zerlegt und
1982 zum Standard für das ARPANET erklärt, welches eine Vorform des Internet darstellt.
[ZAKON]
Wie bereits in Kapitel 2 erwähnt wurde, gibt es zur Zeit Bestrebungen die Dienste der
"klassischen Telekommunikation" mit dem Internet Protokoll zu reimplementieren. In diesem
Kapitel werden nun einige bereits existierende Protokolle beleuchtet, die das ermöglichen.
5.1 Datendienste
Die heute genutzten Datendienste stammen zu einem großen Teil noch aus den Anfängen des
Internet. So wurde das erste E-Mail-Programm bereits 1971 entwickelt. 1972 folgte dann der
Telnet-Dienst für Terminalanwendungen und 1973 das File Transfer Protocol (FTP) zum
Austausch von Dateien. Da die Handhabung von IP-Adressen für den Menschen unkomfortabel
ist, führte man 1984 den Domain Name Service (DNS) ein, der einen hierarchischen
Verzeichnisdienst zur Verfügung stellt. Das World Wide Web wird seit 1991 angeboten.
[ZAKON]
Alle diese Diensten versenden Daten, bei denen zeitliche Verzögerungen während der
Übertragung keine Rolle spielen. Selbst bei Chat-Anwendungen wirkt eine Verzögerung von
wenigen Sekunden nicht als störend. Dies sieht bei der Übertragung von Audio- und
Videodaten anders aus. Daher können hier die Protokolle der "klassischen Datendienste" nicht
eingesetzt werden.
5.2 Voice over IP
Das Kürzel VoIP beinhaltet alle Protokolle, Kompressionsverfahren und sonstige Techniken, die
für einen Telefondienst über das Internet Protokoll zur Verfügung stehen. Die erste
Protokollfamilie, die dafür entwickelt wurde, wird in der ITU-T Empfehlung H.323 beschrieben.
Diese verwendet das Real-Time Transport Protocol (RTP) für die Übertragung von
Multimediadaten sowie die Signalisierungsprotokolle H.225 und H.245 zur Steuerung der
Kommunikation. Innerhalb der Empfehlung H.225 werden Q.931 Nachrichten referenziert, die
ursprünglich für ISDN spezifiziert wurden (sieh Anhang A.3). Darüber hinaus existieren einige
alternative Signalisierungsprotokolle, die eine gewisse Relevanz erreicht haben. Dazu gehören
das offene Session Initiation Protocol (SIP) und Session Description Protocol (SDP) sowie das
proprietäre Skinny Client Control Protocol (SCCP) von Cisco (siehe [WALLINGFORD S.133]). Im
Folgenden werden die zuvor genannten offenen Protokolle vorgestellt. Auf das SCCP wird
35
5. IP-Technik
aufgrund fehlender Quellen nicht weiter eingegangen.
5.2.1 H.323 Geräte und Adressierung
Die erste Version der ITU-T Empfehlung [H.323] wurde 1996 verabschiedet. Sie beschreibt
eine Infrastruktur für audiovisuelle Dienste in paketbasierten Netzwerken, in denen es keine
Zusicherungen bezüglich der Dienstqualität gibt. Eine Sicherung der Daten gegen Verfälschung
oder Verlust muss daher in den Endpunkten umgesetzt werden.
Es werden zunächst vier Geräte vorgestellt, die innerhalb von H.323 spezielle Aufgaben
erfüllen. Anschließend wird in einem kurzen Abschnitt gezeigt, welche Möglichkeiten H.323 zur
Adressierung vorsieht.
Terminal
Ein Terminal ist ein Endpunkt, der über multimediale Ein- und Ausgabegeräte, wie Mikrofon,
Lautsprecher, eine Kamera oder einen Bildschirm verfügt. Er ermöglicht eine bidirektionale
Echtzeitkommunikation mit einem anderen Terminal, einem Gateway oder einer MultipointControl-Unit (MCU).
Für die Kodierung bzw. Dekodierung von Audio- und Videodaten können verschiedene
Codecs genutzt werden. Jedes Terminal muss aber mindestens PCM-kodierte Audiodaten
gemäß der ITU-T-Empfehlung G.711 verarbeiten können, um die Interoperabilität zwischen
Terminals sicherzustellen.
Die kodierten Daten werden via RTP übertragen und anschließend beim Empfänger in einem
Buffer abgelegt. Damit Laufzeitschwankungen von Paketen (Jitter) ausgeglichen werden
können, wird die Weiterverarbeitung um einen kurzen Zeitraum verzögert. Nach dem selben
Prinzip werden auch zeitversetzt eintreffende Audio- und Videoströme miteinander
synchronisiert. [H.323 S.15-18]
Gateway
Es gibt viele Situationen, in denen Terminals mit Endpunkten innerhalb eines anderen Netzes
kommunizieren sollen. Dies ist z.B. der Fall, wenn eine Verbindung in ein leitungsvermittelndes
Telefonnetz aufgebaut wird. Zu diesem Zweck kann ein Gateway verwendet werden, das
zwischen den unterschiedlichen Protokollen und Datenformaten übersetzt. Es übernimmt den
Auf- und Abbau von Verbindungen und spiegelt dabei die Eigenschaften der verbundenen
Endpunkte nach außen wieder.
Innerhalb eines paketbasierten Netzes kommunizieren Terminals in der Regel direkt
miteinander, so dass hier auf ein Gateway verzichtet werden kann. [H.323 S.28-29]
Gatekeeper
Ein Gatekeeper verwaltet eine bestimmte Menge an Terminals, Gateways und MCUs, die
zusammen als Zone bezeichnet werden. Seine Hauptaufgabe besteht in der Adressumsetzung,
um Aliases, wie Telefonnummern in Netzwerkadressen umzuwandeln. Zusätzlich kann er den
36
5. IP-Technik
Zugriff auf das Netzwerk autorisieren und Funktionen für das Bandbreitenmanagement zur
Verfügung stellen.
Wird ein Gatekeeper verwendet, so gibt es pro Zone genau einen. Dieser kann seine
Funktion aber bei Bedarf an einen alternativen Gatekeeper abtreten. [H.323 S.42-44]
Multipoint-Control-Units
MCUs ermöglichen Konferenzschaltungen zwischen drei und mehr Endpunkten. Sie enthalten
einen Multipoint Controller und können zusätzlich über sogenannte Multipoint Prozessoren
verfügen.
Ein Multipoint Controller bestimmt vor einer Verbindung die gemeinsamen Fähigkeiten der
einzelnen Endpunkte und informiert diese z.B. über die erlaubten Codecs. Falls weitere
Endpunkte einer Konferenz beitreten wollen, werden die Daten aktualisiert. Es ist auch
möglich, Codecs zu verwenden, die nicht von jedem Teilnehmer unterstützt werden. In diesem
Fall müssen geeignete Transkodierungen von einem Multipoint Prozessor durchgeführt werden.
Ein Multipoint Controller kann auch in einem Terminal, Gateway oder Gatekeeper enthalten
sein.
Ein Multipoint Prozessor empfängt die Video und Audiodaten der Konferenzteilnehmer und
verarbeitet sie auf eine bestimmte Art weiter. Videoprozessoren können z.B. das Bild der
einzelnen Redner einblenden oder verschiedene Videoquellen zusammenfassen. Audioprozessoren mischen häufig Audiokanäle und entfernen ggf. unerwünschte Nebengeräusche.
Die generierten Medienströme werden dann an alle oder auch nur an bestimmte Konferenzteilnehmer weitergeleitet. Multipoint Prozessoren werden ausschließlich von einem Multipoint
Controller gesteuert. Zusammen mit einem Multipoint Controller können sie Teil eines
Gateways oder Gatekeepers sein. [H.323 S.44-46]
Adressierung
Eine Voraussetzung für den Aufbau einer Verbindung zwischen Endpunkten ist deren eindeutige
Identifizierbarkeit. Diese muss durch Netzwerkadressen, z.B. IP-Adressen in Kombination mit
Portnummern (Sockets) sichergestellt werden. Optional können Endpunkte oder Konferenzen,
die von einem Endpunkt unterhalten werden, auch durch Aliases identifiziert werden. Ein Alias
kann eine Telefonnummer gemäß der ITU-T Empfehlung E.164, eine Teilnehmernummer oder
eine Zeichenkette sein. [H.323 S.50-51]
Neben den Aliases und Netzwerkadressen, kann ein Endpunkt ein sogenanntes Access Token
besitzen. Dieses dient als Berechtigung, um die Ressourcen eines Gateways für eine
Verbindung zu verwenden. Wird ein Access Token bekannt gegeben, muss ein anderer
Endpunkt keine weiteren Kontaktinformationen kennen, um eine Verbindung aufzubauen. Die
Kontaktinformationen können somit geheim bleiben. [H.323 S.57]
Um mehrere Sprach-, Daten- und Signalisierungsinformationen über eine Netzwerkadresse
(z.B. einen Socket) zu übertragen, wird in der Empfehlung [H.323 S.50] eine Transport Service
Access Point (TSAP) Kennung eingeführt,
Signalisierungskanal kann dann wiederum
mit der ein Kanal identifiziert wird. Ein
Nachrichten für verschiedene Anrufe und
Konferenzen transportieren. Eine Konferenzkennung (CID) fasst zu diesem Zweck alle
37
5. IP-Technik
Nachrichten innerhalb einer Konferenz zusammen. Einzelne Anrufe werden außerdem durch
eine Anrufkennung (Call ID) als auch durch einen Referenzwert (Call Reference Value)
auseinander gehalten. Eine Anrufkennung ist zwischen allen Teilnehmern eindeutig und kann
nicht verändert werden. Ein Referenzwert ist dagegen lediglich zwischen jeweils zwei
Teilnehmern auf einem Signalisierungskanal eindeutig und wird in Q.931-Nachrichten
verwendet. [H.323 S.69-70]
5.2.2 H.225 Anrufsignalisierung
Unter dem Begriff Anrufsignalisierung (Call Signalling) werden in der Empfehlung [H.323 S.49]
Nachrichten zusammengefasst, mit denen z.B. eine Verbindung auf- und abgebaut oder eine
Bandbreitenänderung beantragt werden kann. Die Empfehlung [H.225] unterscheidet zwischen
den Nachrichten des RAS-Kanals und denen des Anrufsignalisierungskanals, die im Folgenden
beschrieben werden. In Anhang B.1 - B.3 kann eine Auflistung der verschiedenen Nachrichtentypen gefunden werden.
RAS-Kanal
Über den Registration, Admission and Status (RAS) Kanal kann ein Endpunkt den Gatekeeper
seiner Zone ausfindig machen und sich bei diesem registrieren. Die Registrierungsinformationen enthalten u.a. die Adresse eines RAS-Kanals zum Aufbau einer Verbindung, die
Adresse zur Anrufsignalisierung, den Gerätetyp und eine Menge von Aliases (siehe [H.225
S.65-67]). Sollen die Informationen nicht länger vorgehalten werden, können diese sowohl
vom Gatekeeper als auch vom Endpunkt wieder entfernt werden.
Um nun eine Verbindung mit einem Endpunkt aufzubauen, dessen Adresse nicht bekannt
ist, kann eine Lokalisierungsanfrage an einen Gatekeeper gestellt werden. Ist dieser in der
Lage, den Endpunkt anhand eines Aliases zu identifizieren, werden entsprechende Kontaktinformationen an das anfragende Gerät zurück gesendet. Diese können sich auch auf den
Gatekeeper selbst beziehen, falls er die Anrufsignalisierung weiterleiten soll.
Sind die notwendigen Informationen für den Aufbau einer Verbindung bekannt, kann ein
Endpunkt bei seinem Gatekeeper Bandbreite für neue Audio- und Videokanäle beantragen.
Steht nicht genügend Bandbreite zur Verfügung, weist der Gatekeeper entweder eine geringere
Bandbreite zu oder er verweigert die Erlaubnis für den Verbindungsaufbau. Es ist ebenfalls
möglich die Bandbreite bereits bestehender Verbindungen zu reduzieren.
Um die Skalierbarkeit der Gatekeeperfunktionalität zu gewährleisten, kann ein Endpunkt
auch an alternative Gatekeeper verwiesen werden. Der Endpunkt wählt aus einer Menge
alternativer Gatekeeper einen aus und verwendet diesen, bis der ursprüngliche Gatekeeper
wieder ausreichende Kapazitäten besitzt. Der Status des ursprünglichen Gatekeepers wird
währenddessen vom Endpunkt oder vom alternativen Gatekeeper regelmäßig überprüft.
Sobald der ursprüngliche Gatekeeper den Endpunkt wieder übernehmen kann, registriert sich
der Endpunkt dort erneut. Alle über den alternativen Gatekeeper geführten Verbindungen
werden dann ebenfalls zum ursprünglichen Gatekeeper übertragen.
Über Gateways sind Verbindungen in ein externes und damit ggf. gebührenpflichtiges
38
5. IP-Technik
Telefonnetz möglich. Daher können Endpunkte die Fähigkeit besitzen, Berichte über alle
bislang geführten Verbindungen zu erstellen, um diese abzurechnen. Die Berichte werden zu
diesem Zweck in regelmäßigen zeitlichen Abständen an einen Gatekeeper versendet oder
können von diesem explizit angefordert werden. Für eine sinnvolle Nutzung ist aber ein
besonderes Vertrauensverhältnis notwendig. [H.323 S.51-62]
Alle RAS-Informationen (siehe Anhang B.1) werden über einen unzuverlässigen Kanal
versendet. Die TSAP-Kennung wird bei einem Gatekeeper fest vorgegeben und kann bei
anderen Geräten dynamisch zugewiesen werden. [H.225 S.8-10]
Anrufsignalisierungskanal (Call Signalling Channel)
In
Netzwerken,
die
über
keinen
Gatekeeper
verfügen,
werden
Nachrichten
zur
Anrufsignalisierung direkt zwischen den Endpunkten übertragen. Dafür ist es notwendig, dass
die Adresse des Kanals zuvor bekannt ist. In einem Netzwerk mit Gatekeeper wird dagegen
über den RAS-Kanal zunächst eine Genehmigung für die Verwendung von Bandbreite
eingeholt. Die Antwort legt dann fest, ob die Anrufsignalisierung über den Gatekeeper oder
direkt zwischen den Endpunkten stattfinden soll. Die Adresse des Anrufsignalisierungskanal
wird in der Antwort bekannt gegebenen.
Die
Nachrichten
auf
dem
Signalisierungskanal
entsprechen
einer
Untermenge
der
Empfehlungen Q.931 und Q.932 (siehe Anhang A.3 sowie Anhang B.2 und B.3). Während die
Empfehlung Q.931 Nachrichten für den Auf- und Abbau von Verbindungen beschreibt, geht die
Empfehlung Q.932 auf die Unterstützung von Zusatzdiensten ein. Dazu werden in der
Empfehlungsreihe H.450.x spezielle Dateneinheiten (Application Protocol Data Units)
beschrieben, die in den Signalisierungsnachrichten transportiert werden. [H.323 S.6566][H.225 S.14-16]
Der Anrufsignalisierungskanal wird über ein zuverlässiges Transportprotokoll übertragen.
Dabei wird jede Nachricht in genau einem Paket des verwendeten Transportprotokolls
versendet. Die Empfehlung schreibt zudem vor, dass das Paket auf dem Übertragungsweg
nicht fragmentiert werden darf. Die TSAP-Kennung kann sowohl fest vorgegeben als auch
dynamisch zugewiesen werden. [H.225 S.8-10]
5.2.3 H.245 Steuerung multimedialer Kommunikation
Die Empfehlung [H.245] definiert Nachrichten (siehe Anhang B.5), mit denen logische Kanäle
für Datenströme erstellt, konfiguriert und entfernt werden können. Dazu wird bei einem
Verbindungsaufbau ein Steuerungskanal zwischen den Endpunkten eingerichtet, sobald die
H.245-Adresse bekannt ist. Um die Anrufsignalisierung zu verkürzen, kann die Adresse auch
schon in einer der initialen Q.931-Nachrichten (CALL PROCEEDING oder ALERTING - siehe
5.2.4) gesendet werden. Dieses Vorgehen wird auch als Schnellstart (Fast Start) bezeichnet.
[H.225 S.8]
Die Empfehlung unterscheidet zwischen vier Arten von Nachrichten. So gibt es Anfragen
(Requests), die eine Aktion auslösen und mit einer Antwort bestätigt werden. Dazu gehört die
Bestimmung von Master und Slave Rollen, die in Situationen mit mehr als einem Multipoint
39
5. IP-Technik
Controller notwendig ist. Beim Aufbau eines bidirektionalen Kanals verhindern die Rollen
außerdem Konflikte bei konkurrierenden Präferenzen.
Eine weitere wichtige Anfrage ermöglicht es, die gemeinsamen Fähigkeiten von Endpunkten
in Erfahrung zu bringen, mit denen diese kommunizieren können. Dabei unterscheidet man
zwischen der Fähigkeit Informationen in einer bestimmten Form senden und der Fähigkeit
solche Daten verarbeiten zu können. Darüber hinaus können symmetrische Fähigkeiten
definiert werden, bei denen sowohl das Versenden als auch die Verarbeitung von Informationen
eines Formats unterstützt werden muss.
Der Auf- und Abbau eines logischen Kanals wird ebenfalls mit einer Anfrage realisiert. Die
einzelnen Kanäle erhalten eine Kanalnummer (logical channel number), um diese von einander
unterscheiden zu können. Der Steuerungskanal selbst wird mit der Kanalnummer 0
gekennzeichnet.
Befehle (Command Messages) sind eine andere Art von Nachrichten, die ebenfalls eine
Aktion auslösen. Im Gegensatz zu Anfragen, bleiben diese aber unbeantwortet. Ein Kommando
wird z.B. für die Flusssteuerung zur Angabe einer maximalen Datenrate verwendet.
Als letzter Nachrichtentyp existieren sogenannte Indikatoren (Indications), mit denen
lediglich Informationen über den Zustand eines Endpunktes übertragen werden können. Das
sind z.B. gemessene Laufzeitschwankungen, die bei einem Empfänger ebenfalls Einfluss auf die
übertragene Datenrate haben können.
H.245-Nachrichten werden auf einem zuverlässigen Kanal übertragen und können sich ein
Paket des verwendeten Transportprotokolls teilen. Wie beim Anrufsignalisierungsprotokoll, darf
das Paket auf dem Übertragungsweg aber nicht fragmentiert werden.
5.2.4 H.323 Verbindungsaufbau
Der Auf- und Abbau einer H.323-Verbindung wird anhand eines kurzen Szenarios vorgestellt:
Die Endpunkte A und B sind jeweils bei einem anderen Gatekeeper registriert. Gatekeeper A
ist für eine direkte Anrufsignalisierung
Anrufsignalisierung weiterleitet.
konfiguriert,
während
Gatekeeper
B
die
Endpunkt A holt zunächst mit der Nachricht ARQ (Admission Request) eine Erlaubnis für die
Nutzung des Netzes bei seinem Gatekeeper ein. Die Nachricht ACF (Admission Confirm)
signalisiert eine Genehmigung und kann außerdem die Adresse des Anrufsignalisierungskanals
von Endpunkt B übertragen, sofern Gatekeeper A mit Gatekeeper B solche Informationen
austauscht. Es ist auch möglich, dass die Adresse direkt im Endpunkt A bekannt ist.
Endpunkt A sendet nun die Nachricht SETUP über den Anrufsignalisierungskanal an
Endpunkt B, der zum Akzeptieren der eingehenden Verbindung eine CALL-PROCEEDINGNachricht zurücksendet. Endpunkt B beantragt seinerseits eine Erlaubnis für die Netznutzung,
die von Gatekeeper B mit der Nachricht ARJ (Admission Reject) abgelehnt wird, weil dieser für
die Weiterleitung der Anrufsignalisierung konfiguriert wurde. In einer FACILITY-Nachricht
informiert Endpunkt B den Endpunkt A über die Adresse des Anrufsignalisierungskanals von
Gatekeeper B, woraufhin der Anrufsignalisierungskanal zwischen beiden Endpunkten mit der
40
5. IP-Technik
Nachricht RELEASE COMPLETE wieder freigegeben wird. Endpunkt A informiert seinen
Gatekeeper mit der Nachricht DRQ (Disengage Request) über das Ende der Verbindung, das
mit der Nachricht DCF (Disengage Confirm) bestätigt wird.
Endpunkt
A
beantragt
nun
erneut
die
Nutzung
des
Netzes,
um
einen
Anrufsignalisierungskanal zum Gatekeeper B zu öffnen. Endpunkt A erhält die Erlaubnis und
sendet die Nachricht SETUP an den Gatekeeper B, die dann von diesem an den Endpunkt B
weitergeleitet wird. Im Rahmen des H.245-Schnellstarts beinhaltet die SETUP Nachricht bereits
Open-Logical-Channel-Anfragen zum Öffnen von Medienkanälen, die Endpunkt A zum Senden
und Empfangen verwenden möchte. In einer Terminal Capability Set werden die hierfür zur
Verfügung stehenden Fähigkeiten von Endpunkt A übertragen. Zur Bestimmung der Master und
Slave Rollen wird außerdem eine Master-Slave-Determination-Anfrage gestellt. Gatekeeper B
signalisiert mit der Nachricht CALL PROCEEDING, dass der Verbindungsaufbau initiiert wurde
und weist mit einem Flag (provisionalRespToH245Tunnelling) darauf hin, dass noch nicht
feststeht, ob der Schnellstart erfolgreich war. Da der Endpunkt B den Schnellstart nicht
beherrscht, antwortet es auf die Nachricht SETUP mit einer CALL-PROCEEDING-Nachricht ohne
gekapselte Schnellstartinformationen. Wären diese in der Nachricht enthalten gewesen, so
hätte Gatekeeper B sie in einer FACILITY-Nachricht an den Endpunkt A nachreichen müssen.
Endpunkt B beantragt nun bei seinem Gatekeeper eine Erlaubnis für die Netznutzung, die in
diesem Fall gewährt wird. Endpunkt B signalisiert den Anruf und sendet daraufhin die Nachricht
ALERTING an seinen Gatekeeper. Dieser leitet die Nachricht an den Endpunkt A weiter, welcher
nun weiß, dass der Schnellstart nicht erfolgreich war.
Wird am Endpunkt B die Verbindung angenommen, sendet er die Nachricht CONNECT und
überträgt damit die Adresse des H.245 Kanals. Gatekeeper B kann anhand seiner Konfiguration
entscheiden, ob er die Nachricht weiterleitet oder die Adresse durch seine eigene ersetzt. Der
Gatekeeper B lässt eine direkte H.245-Verbindung zu, die dann von Endpunkt A aufgebaut
wird. Es folgt der Austausch der Fähigkeitenmengen sowie die Bestimmung der Master- und
Slave-Rollen. Anschließend werden mit der Anfrage Open Logical Channel zwei unidirektionale
Medienkänale (z.B. Sprachkanäle) zwischen den beiden Endpunkten geöffnet. Der Master
entscheidet dabei, welche Kanäle und welche Kompressionsverfahren verwendet werden.
Während einer Verbindung können Gatekeeper oder Endpunkte eine Änderung der
Datenrate beantragen. In diesem Fall sendet Gatekeeper A die Anfrage BRQ (Bandwidth
Request) an Endpunkt A, welcher diese mit der Nachricht BCF (Bandwidth Confirm) bestätigt.
Endpunkt A sendet den Befehl Flow Control Command an Endpunkt B, damit dieser bei seinem
Gatekeeper eine Bandbreitenänderung für den ausgehenden Kanal beantragt. Diese wird
genehmigt und der Kanal neu geöffnet.
Zum Beenden der Verbindung sendet Endpunkt A den Befehl End Session Command an
Endpunkt B, welcher mit dem selben Befehl antwortet. Endpunkt A signalisiert dann mit der
Nachricht RELEASE COMPLETE die Freigabe der Kanäle. Schließlich informieren beide
Endpunkte Ihre Gatekeeper noch über das Ende der Verbindung, die damit vollständig
abgebaut ist. [H.323 S.86-87,101-105]
41
5. IP-Technik
Abbildung 1: Verbindungsaufbau im H.323
42
5. IP-Technik
5.2.5 H.323 Zusatzdienste
Für
H.323
werden
in
der
Empfehlungsserie
H.450
analog
zum
ISDN
verschiedene
Zusatzdienste spezifiziert (siehe 4.1.2). Die Empfehlung [H.450.1] legt dazu H.225- bzw.
Q.931-/Q.932- Nachrichten des Anrufsignalisierungskanals fest, mit denen entsprechende
Dateneinheiten übertragen werden können. Die Empfehlungen H.450.2 - H.450.12 beschreiben
dann konkrete Zusatzdienste.
Angelehnt an die Dienste zur Teilnehmeridentifikation gibt es so die Möglichkeit den Namen
eines anrufenden oder den des angerufenen Teilnehmers anzuzeigen oder diese Informationen
zu verbergen (siehe H.450.8). Zur Unterstützung der Anrufweiterleitung werden die Dienste
CT, CD, CFU, CFB und CFNR beschrieben (H.450.2, H.450.3). Zur Vervollständigung eines
Anrufs werden neben HOLD, CW, CCBS und CCNR (H.450.4, H.450.6, H.450.9) einige neue
Dienste eingeführt. Dazu gehört das Parken und das Anbieten eines Gesprächs sowie das
Einbrechen in ein Gespräch.
Parken
Die Empfehlung [H.450.5] beschreibt die Möglichkeit, ein Gespräch auf einer Parkposition
abzulegen (SS-PARK). Diese kann innerhalb eines Endpunktes oder in einem Gatekeeper liegen
und durch eine Kennung identifiziert werden, falls mehrere Parkpositionen existieren. Der
wartende Teilnehmer wird in dieser Situation z.B. mit Musik, einem Video oder einem Standbild
unterhalten. Das Gespräch kann dann von einem autorisierten Endpunkt zu jeder Zeit wieder
aufgenommen werden (SS-PICKUP).
Anbieten
Ein Teilnehmer kann bei einem Anruf zu einem besetzten Ziel angeben, dass er solange warten
möchte, bis der entsprechende Teilnehmer den Anruf entgegennimmt (SS-CO). Dieses Angebot
wird dem angerufenen Teilnehmer signalisiert, der dann entscheiden kann, ob er den Anruf
ignoriert oder die für das Gespräch notwendigen Ressourcen verfügbar macht. [H.450.10]
Einbrechen
Alternativ zum Warten auf freiwerdende Ressourcen ist es auch möglich in ein laufendes
Gespräch einzubrechen (SS-CI). Der vorherige Gesprächspartner wird dabei entweder
gehalten, er kann in einer Konferenzschaltung ebenfalls kommunizieren oder er wird getrennt.
Es ist außerdem möglich, ein laufendes Gespräch abzuhören, ohne dass die Teilnehmer dies
bemerken. [H.450.11]
Erweiterte Netzwerkfähigkeiten
Die Empfehlung [H.450.12] definiert sogenannte ANF-Endpunkte, die nicht näher spezifizierte,
erweiterte Netzwerkfähigkeiten besitzen. Der beschriebene Zusatzdienst erlaubt es diese
Fähigkeiten
in
Form
von
allgemeinen
Informationen
mit
anderen
ANF-Endpunkten
auszutauschen. Diese können für einen beliebigen Zweck, wie z.B. zur Anzeige am
empfangenden Endpunkt verwendet werden.
43
5. IP-Technik
Hinweis über eingetroffene Mitteilungen
In einem Kommunikationsnetz ist es in der Regel hilfreich, wenn eine Einheit, stellvertretend
für
einen
Teilnehmer,
Mitteilungen
entgegen
nehmen
kann.
Dies
kann
z.B.
ein
Anrufbeantworter oder eine MMS-Zentrale sein. Um einen Teilnehmer über eingetroffene
Nachrichten zu informieren, können bestimmte Informationen mit einem Zusatzdienst (SSMWI) versendet werden. Dazu gehört die Identität der Nachrichtenzentrale, die Anzahl der
Nachrichten, die Adresse des Benutzers, der eine Nachricht hinterlassen hat, der Zeitpunkt zu
dem die Nachricht eingetroffen ist sowie die höchste Priorität aller eingetroffenen Nachrichten.
[H.450.7]
Anklopfen
Als Beispiel für die Anrufsignalisierung für einen Zusatzdienst soll der Dienst Anklopfen
[H.450.6] nun kurz umrissen werden.
Der Endpunkt C besitzt eine Erlaubnis zur Netznutzung und kennt die Adresse von Endpunkt
B, der bereits eine Verbindung mit Endpunkt A unterhält.
Der Endpunkt C sendet zunächst die Nachricht SETUP über den Anrufsignalisierungskanal an
Endpunkt B. Dieser antwortet wie bei einem gewöhnlichen Verbindungsaufbau mit den
Nachrichten CALL PROCEEDING und ALERTING. In der ALERTING-Nachricht wird allerdings die
optionale Information callWaiting.invoke beigelegt, mit der darauf hingewiesen wird, dass der
Zusatzdienst aktiviert wurde. Endpunkt C sendet daraufhin die ebenfalls optionale Information
callWaiting.indication, um zu signalisieren, dass auf die Verbindung gewartet wird. Gemäß der
Empfehlung [H.450.1 S.4] kann dafür eine FACILITY-Nachricht verwendet werden. Endpunkt B
kann nun z.B. die Verbindung mit Endpunkt A beenden oder den Anruf halten. Er sendet dann
die Nachricht CONNECT an Endpunkt C und nimmt so die Verbindung an.
44
5. IP-Technik
Abbildung 2: Anklopfen an eine bestehende H.323-Verbindung
5.2.6 SIP Anrufsignalisierung
Das Session Initiation Protocol (SIP) wird im RFC 2543 und [RFC 3261 S.1,10,20-26,142] als
Anwendungsprotokoll beschrieben, mit dem multimediale Sitzungen erstellt, beendet und
deren Rahmenbedingungen geändert werden können. Solche Sitzungen beinhalteten
Telefongespräche, Konferenzen oder sonstige multimediale Datenströme und können zwischen
zwei und mehr Teilnehmern aufgebaut werden.
Im Gegensatz zur Empfehlung H.323 werden für das SIP bestimmte zugrundeliegende
Protokolle vorausgesetzt. So wird auf der Vermittlungsschicht explizit das Internet Protokoll in
den Versionen 4 (IPv4) oder 6 (IPv6) verwendet. Um eine Interoperabilität zu gewährleisten,
müssen als Transportschichtprotokolle außerdem mindestens das UDP und mit dem RFC 3261
auch TCP unterstützt werden. Die Entscheidung für das TCP wurde getroffen, da dieses
stromorientiert ist und somit größere Nachrichtengrenzen erlaubt.
Das SIP weist große Ähnlichkeiten zu einigen verbreiteten Internetanwendungen auf. So
werden für die Adressierung spezielle SIP-URIs verwendet, die in gewissen Teilen analog zu EMail-Adressen aufgebaut sind. Daher können diese mit Hilfe des DNS in IP-Adressen
umgewandelt werden. Zusätzlich können mit Header-Informationen weitreichende
Rahmenbedingungen für einen Verbindungsaufbau vorgegeben werden. Die SIP-Informationen
selbst werden in einem Textformat übertragen, welches an das HTTP erinnert. Das
Nachrichtenformat, die darin enthaltenen Informationen sowie die Adressierung werden im
Anhang C genauer betrachtet.
45
5. IP-Technik
Im SIP werden insgesamt drei logische Einheiten beschrieben, denen unterschiedliche
Aufgaben zukommen:
User Agent
Ein User Agent ist in der Regel ein Endpunkt, der für eine gewisse Zeit mit einem anderen User
Agent kommuniziert. Er übernimmt für jede zusammenhängende Abfolge von Nachrichten
(Transaktion) entweder die Rolle eines Clients (UAC) oder eines Servers (UAS) und hält den
aktuellen Zustand der Transaktion im Speicher. Für nicht authentifizierte Anfragen wird jedoch
kein Zustand gesichert, um DoS-Angriffe zu erschweren.
Neben dem User Agent als Endpunkt gibt es auch sogenannte Back-to-Back User Agents,
die Anfragen entgegennehmen und zur Beantwortung weitere Anfragen stellen. Das kann z.B.
ein Soft-PBX sein, der die Aufgaben einer Telefonanlage übernimmt.
Vergleicht man den User Agent mit den vorgestellten H.323-Geräten, so entspricht dieser
am ehesten dem Signalisierungsdienst eines H.323-Terminals. Ein Back-to-Back User Agent
übernimmt Aufgaben eines Gatekeepers oder einer MCU. [RFC 3261 20-26]
Registrar
Unter einem Registrar versteht man einen Serverdienst (UAS), der Lokalisierungsinformationen
zu den Benutzern einer Domäne bereitstellt. Ein Endpunkt (UAC, z.B. ein Telefon) sendet dazu
in regelmäßigen zeitlichen Abständen eine Registrierungsanfrage, um die URI des aktuellen
Teilnehmers mit der URI des Endgerätes zu assoziieren. Ein Teilnehmer kann dabei auch mit
mehreren Endgeräten gleichzeitig assoziiert sein. Die Registrierungsinformationen werden nach
Ablauf einer Gültigkeitsdauer oder explizit durch die Anfrage eines Endpunktes wieder entfernt.
Ein Registrar wird häufig zusammen mit einem Proxy bereitgestellt, so dass der Proxy direkt
auf die Lokalisierungsinformationen zugreifen kann. Er übernimmt einen Teil der Aufgaben, die
im H.323 durch einen Gatekeeper erfüllt werden. [RFC 3261 S.16-17,20-26]
Proxy
Die wichtigste Aufgabe eines Proxies besteht in der Weiterleitung von Anfragen, um diese
letztlich an einen Endpunkt auszuliefern. Er stellt zu diesem Zweck sowohl Client- als auch
Serverfunktionalitäten bereit.
Für einen Endpunkt kann ein sogenannter Outbound Proxy definiert werden, der zunächst
alle Anfragen des Endpunktes erhält. Dieser bestimmt dann via DNS oder alternativ mit lokalen
Regeln über welche Proxies eine Anfrage weitergeleitet wird. Das RFC 2543 spezifiziert dazu
ein sogenanntes Strict Routing, bei dem ein initial vorgegebener Pfad durchlaufen wird. Im RFC
3261 wird dieses durch ein kompatibles Loose Routing ergänzt, bei dem jeder Proxy weitere
Zwischenstationen im Pfad einfügen kann. Die Anfrage gelangt dann irgendwann an einen
sogenannten Inbound Proxy der sie schließlich mit Hilfe von Lokalisierungsinformationen an
den gewünschten Endpunkt ausliefert.
Ein Proxy kann zustandslos arbeiten und Anfragen sowie Antworten direkt weiterleiten.
Sichert er dagegen den Zustand einer Transaktion, ist es möglich eine Anfrage aufzuteilen und
46
5. IP-Technik
an verschiedene Proxies zu senden. So kann z.B. ein optimaler Pfad ermittelt oder die Antwort
mit der kürzesten Bearbeitungszeit verwendet werden. Ein Proxy, der den Zustand einer
Transaktion sichert kann außerdem zur Bearbeitung einer Anfrage selbst weitere Anfragen
stellen. Auf diese Weise werden Zusatzdienste (im SIP auch Mid-Call Features genannt), wie
das Anklopfen an eine bestehende Sitzung unterstützt.
Abgesehen vom Lokalisierungsdienst stellt ein Proxy in etwa die selben Dienste zur
Verfügung wie ein H.323-Gatekeeper. Einige Punkte, wie z.B. das Bandbreitenmanagement
werden hier jedoch nur am Rande betrachtet. [RFC 3261 S.16-17,20-26,91-106,122-124]
Verbindungsaufbau
Von Endpunkt A soll eine Sitzung mit Teilnehmer B gestartet werden, von dem lediglich eine
SIP-URI bekannt ist. Endpunkt A besitzt weder Informationen über den Endpunkt B noch über
den Proxy B. Die Adresse von Proxy A wurde jedoch vorkonfiguriert oder alternativ in einer
DHCP-Option mitgeteilt (siehe RFC 3361 - Dynamic Host Configuration Protocol for SIP). Proxy
A übernimmt dabei die Rolle eines Outbound-Proxies, um Kontakt mit externen Teilnehmern
oder Geräten aufzunehmen.
Endpunkt A sendet zunächst eine Einladung in Form einer INVITE-Anfrage an Proxy A, in der
die von ihm gewünschten Sitzungsparameter mit Hilfe des Session Description Protocols (SDP,
siehe 5.2.7) beschrieben werden. Proxy A nimmt die Nachricht entgegen und stellt eine DNSAnfrage, um den Proxyserver ausfindig zu machen, der für die Domäne von Teilnehmer B
zuständig ist. Proxy A leitet dann die Anfrage an diesen weiter und unterrichtet anschließend
Endpunkt A mit der Antwort 100 Trying, dass versucht wird, die Anfrage an das Ziel
weiterzuleiten.
Proxy B ist der Inbound-Proxy für Endgerät B und empfängt die Nachricht. Er fragt bei
einem Lokalisierungsdienst nach, an welchen Endpunkten Teilnehmer B angemeldet ist. In
diesem Fall ist das ausschließlich Endpunkt B, so dass Proxy B die Anfrage an diesen
übergeben kann. Proxy B sendet dann ebenfalls die Antwort 100 Trying an Proxy A.
Endgerät B informiert nun Teilnehmer B z.B. mit einem akustischen Signal darüber, dass
eine Anfrage eingetroffen ist und propagiert die Antwort 180 Ringing über die beiden Proxies
an das Endgerät A. Dieses kann dann seinerseits signalisieren, dass die Anfrage ausgeliefert
wurde. Nimmt Teilnehmer B die Sitzung an, versendet Endpunkt B die Antwort 200 OK, in der
mit einer SDP-Beschreibung angegeben wird, welche der angebotenen Sitzungsparameter
akzeptiert werden. Endpunkt A bestätigt anschließend die Sitzung mit der Nachricht ACK und
sendet diese direkt an die nun bekannte Adresse von Endpunkt B.
Falls die gewünschte Sitzung von Endpunkt B nicht unterstützt wird, muss dieser mit der
Nachricht 606 Not Acceptable antworten, in der eine für ihn gültige Sitzungsbeschreibung
enthalten sein kann. Er beendet anschließend die Sitzung mit der Nachricht BYE, woraufhin
Endpunkt A ggf. eine erneute INVITE-Anfrage stellt. Während einer laufenden Sitzung ist es
ebenfalls möglich die Sitzungsparameter zu verändern. Zu diesem Zweck können
währenddessen neue INVITE-Anfragen versendet werden. Diese stoßen dann eine erneute
Aushandlung der gemeinsamen Sitzungsparameter an.
Im dargestellten Szenario werden die Sitzungsparameter akzeptiert, so dass die Sitzung
47
5. IP-Technik
direkt gestartet werden kann. Im Anschluss an die Kommunikationsphase beendet Endpunkt B
dann die Sitzung mit der Anfrage BYE, die Endpunkt A wiederum mit der Nachricht 200 OK
bestätigt. [RFC 3261 S.11-15,83-89,192-193]
Abbildung 3: Verbindungsaufbau im SIP
5.2.7 SDP Sitzungsbeschreibung
Das [RFC 4566] spezifiziert ein Protokoll das ursprünglich für das Session Announcement
Protocol (SAP, siehe 5.2.8) entwickelt wurde, mittlerweile aber auch oder vor allem im SIP
(siehe 5.2.6) verwendet wird. Es muss sowohl von jeder SAP-Implementierung als auch von
allen SIP User Agents unterstützt werden, um eine Interoperabilität im jeweiligen Protokoll zu
gewährleisten.
Das Session Description Protocol (SDP) dient ausschließlich zur Beschreibung multimedialer
Sitzungen und überlässt die Aushandlung von Sitzungsparametern explizit anderen Protokollen
(z.B. dem SIP). Des Weiteren wird der Transport des Protokolls offen gehalten, so dass es in
verschiedenen Anwendungen eingesetzt werden kann. Zu diesem Zweck wird auch ein eigener
MIME-Typ definiert, der z.B. innerhalb von E-Mails oder WWW-Diensten angegeben werden
kann.
Die Sitzungsinformationen beinhalten den Namen, den Betreff sowie den zeitlichen Rahmen
einer Sitzung. Außerdem werden Kontaktinformationen und die verwendeten Medien
48
5. IP-Technik
bekanntgegeben. Es ist es auch möglich, dass mehrere Sitzungen in einem Paket beschrieben
werden. Im SAP ist die Anzahl der Sitzungsbeschreibungen jedoch auf eine beschränkt. Die
Sitzungsbeschreibung selbst erfolgt in Form textueller Wertezuweisungen, die im Anhang D
kurz umrissen werden. [RFC 4566 S.1-7]
5.2.8 Ankündigung einer Sitzung mit dem SAP
Das Session Announcement Protokoll wird im [RFC 2974] aus dem Jahr 2000 beschrieben und
ist bislang noch nicht über den Status eines experimentellen Protokolls hinausgekommen. Es
wurde spezifiziert um Sitzungen und Informationen die für eine Teilnahme relevant sind in
einer Multicast-Umgebung anzukündigen.
Ein sogenannter SAP-Announcer sendet via UDP periodisch Pakete an eine allgemein
bekannte Multicast-Adresse. Er weiß dabei nicht, ob Empfänger vorhanden sind oder nicht.
Empfänger halten die eintreffende Ankündigungen dann solange in einem Cache, bis diese
durch ein Löschpaket, durch die Zeitangaben innerhalb der Sitzungsbeschreibung oder durch
das Ausbleiben weiterer Ankündigungen entfernt werden. Die bereits im Cache vorhandenen
Einträge werden außerdem durch erneute Ankündigungen aktualisiert. Ein Überblick über das
SAP-Paket-Format wird im Anhang E gegeben.
5.2.9 RTP Medientransport
Das [RFC 3550] spezifiziert die beiden Protokolle RTP (Real-Time Transport Protocol) und RTCP
(RTP Control Protocol) für den Transport von Daten, an die Echtzeitanforderungen gestellt
werden. Die Reservierung von Ressourcen sowie die Priorisierung von Daten wird hier zunächst
außer Acht gelassen und in eigenen RFCs gesondert betrachtet. Stattdessen geht das RFC auf
Metainformationen ein, mit denen Nutzdaten und ihr zeitlicher Kontext beschrieben werden.
Des Weiteren werden Hinweise gegeben, wie das RTP für die Übertragung solcher Daten
verwendet werden sollte.
Das RTP unterteilt einen Datenstrom in einzelne Chunks, versieht diese jeweils mit einem
RTP-Header und bildet so RTP-Pakete. Der Header enthält u.a. eine Sequenznummer sowie
einen Zeitstempel, mit denen der Datenstrom beim Empfänger wieder korrekt
zusammengesetzt werden kann. Verspätet eintreffende Chunks werden ggf. verworfen.
Außerdem wird für jeden Chunk ein Nutzdatentyp angegeben, so dass die Kodierung während
der Übertragung geändert werden kann.
Das RTP gibt keine Garantien, dass Pakete in der richtigen Reihenfolge ausgeliefert werden
oder dass sie überhaupt ankommen. Dies wird auch von den unteren Protokollschichten nicht
verlangt, da solche Forderungen die rechtzeitige Auslieferung von Daten stören können. Das
RTCP bietet jedoch eine Möglichkeit, Rückmeldungen über die Dienstqualität zu versenden. Auf
diese Weise kann z.B. die Bandbreite der Nutzdaten durch eine veränderte Kompression an die
Netzkapazität angepasst werden.
Neben Unicast- ist das RTP auch für Multicast-Übertragungen geeignet, sofern das Netz
diese unterstützt. In heterogenen Multicast-Umgebungen kann aber häufig keine optimale
Qualität mit nur einer RTP-Sitzung gewährleistet werden. Aus diesem Grund wird der Dienst
49
5. IP-Technik
eines Mixers eingeführt, der vor einem Netzwerksegment mit geringer Datenrate positioniert
werden kann. Der Mixer fast dann verschiedene Ströme hoher Qualität zu einem Strom
niedrigerer Qualität zusammen und leitet diesen weiter. Alternativ können auch sogenannte
Layered Encodings verwendet werden, bei denen die Ausgangsdaten so kodiert werden, dass
aufeinander aufbauende Informationen entstehen. Diese werden dann in einzelnen RTPSitzungen in verschiedenen Multicast-Gruppen angeboten und können von Empfängern
abonniert werden. Auf diese Weise sind diese selbst in der Lage eine für sie optimale
Bandbreite zu wählen.
Es auch möglich, dass die Hosts eines Netzwerksegmentes nicht direkt via Multicast
erreichbar sind, wenn sie z.B. durch eine Firewall geschützt werden. Für diesen Fall kann ein
Translator-Dienst verwendet werden, der RTP-Pakete stellvertretend für einen Empfänger
entgegennimmt. Er leitet die Pakete dann über eine gesicherte Verbindung an einen Translator
innerhalb der geschützten Zone weiter, der diese wiederum einer internen Multicast-Gruppe zur
Verfügung stellt.
In Multimediakonferenzen werden dem Namen nach verschiedene Medien, wie z.B. Audio
und Video verwendet. Um einem Teilnehmer die Wahl zu lassen, welche Medien er empfangen
möchte, werden diese mit dem RTP in getrennten Sitzungen transportiert. Sie können dann
beim Empfänger wieder zusammengesetzt und mit Hilfe des zeitlichen Kontextes miteinander
synchronisiert werden.
In einem IP-Netzwerk kommt für das RTP typischerweise das UDP als Transportprotokoll
zum Einsatz. Dies ist allerdings nicht verpflichtend und kann z.B. durch das SCTP ausgetauscht
werden. Ein Überblick über die Header-Informationen des RTP und RTCP kann in Anhang F
gefunden werden. [RFC 3550 S.1-8]
Profile
Das RTP ist im Gegensatz zu anderen Transportprotokollen nicht vollständig spezifiziert. Es
kann vielmehr als Rahmenwerk verstanden werden, das mit einem Profil an eine spezifische
Anwendung angepasst werden muss.
Ein Profil zur Übertragung von Audio- und Videodaten wird im RFC 3351 beschrieben. Hier
wird darauf eingegangen, wie die Daten verschiedener Kompressionsverfahren innerhalb der
Nutzdaten angeordnet werden.
Das RFC 3711 geht auf Sicherheitsbelange, wie die Authentisierung von Nachrichten oder
das Sicherstellen der Vertraulichkeit ein.
5.2.10 Sicherheit
Für die bis hierher betrachteten VoIP-Protokolle existieren Ausführungen zu den jeweils
protokollspezifischen Sicherheitsbelangen. Hier wird in der Regel auf bereits vorhandene
Verschlüsselungsverfahren (z.B. IPSec, TLS) zurückgegriffen. Das Bedürfnis nach
Vertraulichkeit, Unverfälschtheit usw. sollte mit diesen in der Regel zu erfüllen sein. Da das
Thema Sicherheit aber einen eigenen großen Themenkomplex darstellt, wird in diesem Text
nicht näher darauf eingegangen.
50
5. IP-Technik
5.2.11 Sprachqualität
Zur Entlastung eines Netzes wird Sprache häufig komprimiert übertragen. Dabei wird der
Verlust von Informationen in Kauf genommen, um gute Kompressionsraten zu erreichen. Der
Informationsverlust reduziert jedoch ebenfalls die Qualität der Medienströme. Da dies nicht
rein objektiv quantifiziert werden kann, definiert die ITU-T in der Empfehlung [P.800]
Methoden
zur
subjektiven
Bestimmung der
Übertragungsqualität. Dazu
werden
reproduzierbare Laborbedingungen, Konversations- und Hörtests beschrieben. Die Bewertung
erfolgt u.a. anhand des Mean Opinion Score (MOS). Dieser sowie eine Liste bewerteter SprachCodecs ist im Anhang J zu finden.
5.3 Quality of Service
IP-Netzwerke arbeiten in der Regel nach dem Best-Effort-Prinzip. D.h. dass Datagramme
verspätet, in unterschiedlicher Reihenfolge, verfälscht oder auch gar nicht eintreffen können.
Für bestimmte Anwendungen, wie beim Transport von Echtzeitmedien ist dies aber nicht immer
ausreichend. So sollte z.B. ein Telefongespräch nicht durch eingehende Telefaxe gestört
werden. Um dies zu vermeiden, gibt es zwei verschiedene Ansätze, die hier nun vorgestellt
werden.
5.3.1 Reservierung von Ressourcen mit dem RSVP
Das Ressource Reservation Protocol (RSVP) wird im [RFC 2205] spezifiziert und kann
verwendet werden, um Ressourcen auf einem Unicast-Pfad oder auf Multicast Pfaden zu
reservieren.
Es
setzt
direkt
auf
IPv4
oder
IPv6
auf
und
nimmt
den
Platz
eines
Transportprotokolls ein. Das RSVP selbst wird jedoch nicht für die Übertragung von Nutzdaten
verwendet.
Um eine Reservierung zu veranlassen, überträgt ein Sender zunächst eine Path-Nachricht an
einen oder mehrere Empfänger. Die Nachricht enthält u.a. eine Sitzungsbeschreibung sowie ein
Feld, das jeder RSVP-Router auf dem Pfad zum Empfänger mit seiner eigenen IP-Adresse
überschreibt. Die jeweils vorherige Adresse wird dabei in den Routern als sogenannter PathState gesichert. Nicht-RSVP-fähige Router erscheinen transparent.
Ein Empfänger kann nun eine Reservierungsanfrage in Form einer Resv-Nachricht auf dem
umgekehrten Pfad zurücksenden. In jedem RSVP-Router wird die Anfrage dann durch zwei
Module geführt, in denen entschieden wird, ob die Reservierung durchgeführt werden kann.
Das ist zum einen die Admission Control, die überprüft, ob genügen Ressourcen zur Verfügung
stehen und zum anderen die Policy Control, die die Berechtigung des Empfängers überprüft.
Schlägt eine der Prüfungen fehl, wird eine Fehlermeldung an den Empfänger zurückgegeben.
Anderenfalls wird ein Reservation-State gesichert und die Anfrage zum nächsten Router auf
dem Weg zum Sender weitergeleitet.
Mit einer Anfrage kann optional eine Bestätigung für die erfolgreiche Einrichtung der
Reservierung beantragt werden. Diese stellt jedoch keine Garantie für eine erfolgreiche
Reservierung bis zum Sender dar. So ist es in einer Multicast-Umgebung möglich, dass
51
5. IP-Technik
verschiedene Empfänger gemeinsame Ressourcen für ein und den selben Datenstrom
reservieren. Die einzelnen Reservierungen werden dann in dem Router, in dem die Pfade
zusammenlaufen, zu einer Reservierung zusammengefasst, die der ressourcenintensivsten
entspricht. Bestätigungen an die Empfänger, von denen ressourcenschwächere Reservierung
ausgingen, müssen daher von dem hier betrachteten Router versendet werden und gehen
nicht vom Sender aus.
Um in einem Netzwerk mit RSVP-Routern eine unberechtigte Dienstnutzung oder DoSAttacken zu vermeiden, müssen im RSVP einige Sicherheitsmaßnahmen getroffen werden.
Dazu muss eine Menge von Schlüsseln so verteilt werden, dass jeweils zwei aufeinander
folgende Zwischenstationen einen gemeinsamen Schlüssel besitzen. Bei einer Übertragungen
zwischen zwei Endpunkten dienen diese dann zur Authentifizierung beim jeweils nächsten
Router oder bei einem Endpunkt. Diese Art der Authentifizierung wird auch als Hop-By-HopAuthentifizierung bezeichnet.
In einem RSVP-Router muss außerdem jeder abgelegte Zustand (Path- oder Resv-State)
durch periodische Path- bzw. Resv-Nachrichten aktiv gehalten werden. Wird ein solcher
Zustand nicht vor dem sogenannten Cleanup Timeout reaktiviert, so wird dieser vom Router
entfernt. Dieser Ansatz wird auch als Soft State bezeichnet. Alternativ können Zustände auch
durch explizite Anweisungen entfernt werden.
Das RSVP unterscheidet zwischen drei verschiedenen Reservierungsarten. Der sogenannte
Wildcard Filter Style reserviert Ressourcen, die von den Datenströmen aller Sender gemeinsam
genutzt werden können. Beim Shared-Explicit Style müssen für jeden Sender die Ressourcen
getrennt reserviert werden. Die einzelnen Ströme eines Senders können sich diese jedoch
ebenfalls teilen. Der Fixed-Filter Style reserviert schließlich die Ressourcen für genau einen
Strom von einem Sender. [RFC 2205]
5.3.2 Differentiated Services
Im Internet Protokoll wird ein Header-Feld beschrieben, das zur Klassifizierung von IPDatagrammen vorgesehen ist. Dieses wird im IPv4 als Type-of-Service und im IPv6 als TrafficClass bezeichnet.
Im Type-of-Service-Feld des IPv4-Headers (siehe [RFC 791 S.12]) wird ein Datagramm
einer von acht Prioritätsklassen (Precedence) zugeordnet. Optional kann eine niedrige
Verzögerung, eine hohe Übertragungsrate und eine hohe Zuverlässigkeit für die
Datenübertragung gefordert werden. Die Stationen auf dem Weg zwischen den Endpunkten
müssen dann entsprechend handeln, um den Forderungen nachzukommen. Im IPv6 (siehe
[RFC 2460 Punkt 7]) werden keine direkten Angaben zur Verwendung des Traffic-Class-Feldes
gemacht. Stattdessen wird auf nicht näher spezifizierte separate Dokumente verwiesen.
Das [RFC 2474] beschreibt eine neue, gemeinsame Klassifizierung von Diensten für IPv4
und IPv6 und redefiniert so das Type-of-Service-Feld. Die Felder der beiden
Vermittlungsprotokolle werden zusammen als Differentiated-Services- oder kurz DS-Feld
bezeichnet. Dieses enthält einen sogenannten Differentiated Services Codepoint (DSCP), der
die Verarbeitung in Zwischenstationen (Per-Hop Behavior, kurz PHB) analog zum Type-of52
5. IP-Technik
Service beeinflusst. Für die Zuordnung eines Codepoints zum Verhalten einer Zwischenstation
wird dabei gefordert, dass diese frei konfigurierbar ist.
Zur Realisierung unterschiedlicher Prioritätsklassen in Zwischenstationen können
unterschiedliche Warteschlangenmodelle verwendet werden. Als Beispiele werden das Strict
Priority Queueing, Weighted Fair Queueing, Weighted Round Robin, Varianten davon und das
Class-Based Queuing genannt. [RFC 2474 Punkt 1-3,4.2.2.4]
5.4 Fax over IP
Die akustischen Signale eines Modems oder Faxgerätes können mit VoIP über ein IP-Netzwerk
übertragen werden. Voraussetzung dafür ist jedoch, dass eine Kodierung ohne Kompression
sowie eine ausreichende Abtastrate verwendet wird. Es ist sonst nicht möglich die modulierten
Daten wiederherzustellen. Im IP-Netzwerk muss außerdem mit einer entsprechend hohen
Bandbreite oder QoS-Mechanismen sicherstellt werden, dass es zu keinen Paketverlusten
kommt und dass der Jitter nicht zu groß wird. Anderenfalls entstehen Lücken im Datenstrom,
die zu Fehlern im Dokument führen oder die Kommunikation abbrechen lassen können (siehe
auch [UNDERWOOD]). Für einen bandbreiteneffizienten Transport ohne VoIP kann alternativ
auf zwei Empfehlungen der ITU-T zurückgegriffen werden. Anhang K gibt einen Überblick über
das "traditionelle Telefax-Verfahren".
5.4.1 T.37
Die ITU-T
beschreibt in der Empfehlung [T.37] ein Store-And-Forward-Verfahren zur
Übertragung eines Telefax-Dokumentes über das Internet. Das Verfahren wird auch als SimpleMode bezeichnet, um dieses von einem nicht näher spezifizierten Full-Mode abzugrenzen.
Im Simple-Mode nimmt ein Gateway ein Telefax-Dokument von einem "traditionellen Faxgerät"
stellvertretend entgegen. Es leitet dieses dann im Anhang einer E-Mail über das Internet an ein
anderes Gateway weiter. Das Dokument wird anschließend von diesem Gateway an das
Zielfaxgerät ausgeliefert.
Die Bilddaten werden gemäß RFC 2301 Profile S im Tag Image File Format (TIFF) kodiert.
Das Profile S beschreibt einen minimalen Schwarz-Weiß-Modus, der in der ITU-T Empfehlung
[T.4] ausgeführt wird. Für die Adressierung wird eine internationale Rufnummer gemäß der
Empfehlung
E.164
mit
der
Domäne
eines
Gateways
kombiniert
(z.B.
+12027653000/[email protected]).
Alternativ zu einem Gateway kann eine E-Mail mit Fax-Anhang auch von einem E-MailProgramm (User Agent) generiert oder an ein solches versendet werden. Es gibt außerdem
sogenannte Internet Aware Fax Terminals, (IAF), die ebenfalls Telefax-Dokumente als E-Mail
versenden und empfangen können. [T.37][F.185 S.1-3][RFC 2304]
53
5. IP-Technik
5.4.1 T.38
Die ITU-T-Empfehlung [T.38] spezifiziert die Echtzeitübertragung einer Telefax-Sitzung über
das Internet. Zwei "traditionelle Telefax-Geräte" (der Gruppe 3) verbinden sich dazu mit Hilfe
zweier Gateways über das Internet. Das Gateway des Faxgerätes, das eine Verbindung
aufbauen möchte, demoduliert die Nachrichten gemäß der Empfehlungen T.4/T.30. Es
behandelt einige Nachrichten, wie den Erkennungston für Nicht-Sprach-Dienste (CNG) selbst
und sendet alle anderen Nachrichten mit dem Internet Facsimile Transfer Protokoll (IFT) an das
Gateway des Zielfaxgerätes. Dieses Gateway stellt dann seinerseits eine Verbindung mit dem
Zielfaxgerät her und leitet die Nachrichten in modulierter Form an dieses weiter.
Das IFT-Protokoll wird in ASN.1 definiert und kann als Transportprotokoll TCP als auch UDP
verwenden. Es überträgt sowohl T.30-HDLC-Nachrichten als auch die T.4-Daten, mit denen das
eigentliche Telefax-Dokument transportiert wird. Letztere enthalten keine Fehlerkorrektur, so
dass diese im IP-Netz vom Transportprotokoll übernommen werden sollte.
Anstelle eines Telefax-Gerätes und eines Gateway kann analog zur Empfehlung [T.37] auch
ein IAF verwendet werden. [T.38][F.185 S.1-3]
5.5 Streaming Media
Seit den 1990er Jahren verwenden Radiostationen, neben der "traditionellen Übertragung" per
Funk oder Kabelfernsehen, auch das Internet als Transportmedium. Die digitalisierten
Audioinformationen werden dazu erst komprimiert, kodiert und dann zu jedem Endgerät per
Unicast versendet. Multicast-Übertragungen werden für Medienströme, die durch das Internet
transportiert werden, nicht genutzt, weil diese aufgrund von Sicherheitsproblemen nicht
weiträumig unterstützt werden.
Für die Kompression kommen sowohl proprietäre als auch standardisierte Verfahren, wie
z.B. MPEG-1 Layer 3 Audio (MP3) oder MPEG-4 AAC Audio zum Einsatz. In der Regel wird dabei
ein Informationsverlust in Kauf genommen, um die für den Empfang benötigte Datenrate
möglichst gering zu halten. Die komprimierten Daten werden anschließend in einem
proprietären Format, wie z.B. Quicktime von Apple, Windows Media von Microsoft oder
Shoutcast von Nullsoft kodiert. Die so gekapselten Daten werden dann entweder per UDP,
HTTP, RTP oder einem proprietären Protokoll übertragen. Um den Datenstrom zu steuern kann
außerdem das Real Time Streaming Protocol (RTSP) verwendet werden, das im Wesentlichen
die Funktionen einer Fernbedienung bereitstellt (siehe Anhang L). Dieses wird z.B. in Apple's
Quicktime genutzt. [COGEL]
Zusätzlich zum Internetradio haben sich ebenfalls kombinierte Audio- und Videoströme
etablieren können. So existieren Online-Videotheken die hochauflösende MoD- bzw. VoDDienste (siehe 4.7.1) anbieten. Einige Fernsehsender können zudem direkt über das Internet
empfangen werden. Darüber hinaus gibt es Videorekorder, die aufgenommene Sendungen
vorhalten und diese auf Wunsch über das Internet abspielen. Mittels P2P-Technik stellen auch
einige Benutzer ihre lokalen Fernsehsender zur Verfügung, die dann von überall aus gesehen
werden können. Für die Übertragung kommen die bereits beschriebenen Containerformate zum
Einsatz.
54
5. IP-Technik
Gängige Standards zur Videodatenkompression werden z.B. in den Empfehlungen H.263
(MPEG-4) und H.264 der ITU-T beschrieben. Letztere ist ein Gemeinschaftsprojekt der ISO/IEC
Moving Picture Experts Group (MPEG) und der ITU-T Video Coding Experts Group (VCEG), die
zusammen auch als Joint Video Team (JVT) bezeichnet werden. Im Vergleich zum MPEG-2Standard ermöglicht H.264 eine Halbierung der Datenrate bei gleicher Qualität.
5.6 IPTV
IPTV ermöglicht es, Fernsehen in PAL, NTSC (SDTV) oder einer besseren Qualität (HDTV) über
das Internet Protokoll zu übertragen. Abhängig von der Auflösung und den verwendeten
Kompressionsverfahren sind dafür Datenraten zwischen 1,2 (SDTV, H.264) und 20MBit/s
(HDTV, MPEG-2) für jeden Sender notwendig. Die Anforderung an die Bandbreite eines
Anschlusses ist jedoch um ein Vielfaches höher, da es in Haushalten häufig üblich ist, mehrere
Sender gleichzeitig zu empfangen und aufzuzeichnen. Dazu kommen VoIP und Datendienste,
die ebenfall Bandbreite benötigen. Aus diesem Grund werden Techniken wie VDSL(2)
eingesetzt, mit denen ein Durchsatz von bis zu 100MBit/s in Full Duplex erreicht werden kann.
Hier werden die Videodaten zunächst mit Glasfaserleitungen in die geografische Nähe der
Endkunden gebracht und von einem lokalen DSLAM mit einem möglichst kurzen Kupferkabel in
die Heimnetze weitertransportiert. Im Unterschied zur herkömmlichen Fernsehübertragung
wird beim IPTV dann nicht das gesamte Programmangebot, sondern lediglich die zur Zeit
gewünschten
Programme
gesendet.
Jedes
Programm
wird
an
eine
Multicast-Adresse
übertragen und kann so durch eine Mitgliedschaft in der jeweiligen Multicast-Gruppe
empfangen werden (siehe Anhang M). Auf diese Weise wird die Anzahl der Fernsehsender nicht
durch die Bandbreite beschränkt.
Zur Standardisierung von IPTV werden Spezifikationen von der ETSI und von der Internet
Streaming Media Alliance (ISMA) herausgegeben, die zur Zeit jedoch nicht miteinander
kompatibel sind. Beide Spezifikationen beschreiben eine Kompression mit MPEG-2 und H.264,
den Transport über UDP und RTP, On-Demand-Dienste sowie die Steuerung von
Medienströmen mit Hilfe des RTSP (siehe Anhang L). Die ISMA betrachtet darüber hinaus die
Verschlüsselung von Inhalten, die Authentifizierung von Nachrichten und die Übertragung von
Teletextseiten. Die ETSI führt dagegen einen Dienst ein, mit dem andere verfügbare Dienste
ausfindig gemacht und ausgewählt werden können (SD&S) und beschreibt einen EPG-Dienst.
[HÖVEL][SCHNABEL][TS 102 034][ISMA01]
55
5. IP-Technik
56
6. Gateways
In vielen Szenarien müssen heute verschiedene Netzwerke miteinander verbunden werden.
Dies ist insbesondere für Telefonnetze, wie ISDNs, analoge Telefonnetze, Mobilfunk- und VoIPNetze von Bedeutung. Da in diesen sowohl für die Übertragung von Nutzdaten als auch für
Signalisierungsinformationen
unterschiedliche
Formate
verwendet
werden,
müssen
entsprechende Konvertierungen durchgeführt werden. Diese Aufgabe übernehmen Gateways,
die am Rand eines Netzwerks positioniert werden. Man unterscheidet dabei zwischen
Signalisierungs- und Media Gateways.
6.1 Gateway Control Protocol
Das Gateway Control Protocol (Megaco) wird von der ITU-T in der Empfehlung H.248 und von
der IETF im [RFC 3525] spezifiziert. Es basiert auf dem Media Gateway Control Protokoll
(MGCP), das im RFC 3435 beschrieben wird (siehe [RFC 3525 S.211]).
Die Funktionalität eines H.323-Gateways wird im Megaco-Protokoll auf die beiden
Unterkomponenten Media Gateway Controller (MGC) und Media Gateway (MG) aufgeteilt. Ein
Media Gateway dient dabei der Übersetzung des Nutzdatenformates eines Netzwerks in das
Format eines anderen Netzwerks. Ein Media Gateway Controller hat dagegen die Aufgabe
Media Gateways mit dem Megaco-Protokolls zu steuern. Die Unterteilung ermöglicht eine
bessere Skalierbarkeit, da eingehende Anrufe auf mehrere Media Gateways verteilt werden
können.
Das
Megaco
definiert
sogegenannte
Terminierungen
als
Quellen
und
Senken
für
Medienströme. Dieses sind logische Einheiten, die einen dauerhaften physikalischen Kanal oder
einen temporären Informationsfluss repräsentieren. Ein physikalischer Kanal ist z.B. ein ISDNKanal
während
einzelne
RTP-Ströme,
die
via
Ethernet
eintreffen
als
temporäre
Informationsflüsse gesehen werden. Um Multiplexing zu ermöglichen gibt es zusätzlich
temporäre Multiplexing-Terminierungen, die die Daten eingehender Ströme neu anordnen und
wieder ausgeben. Dies ist z.B. nötig, wenn ein gemischter Audio-Video-Strom über ISDN-BKanäle eintrifft und über RTP-Ströme aufgetrennt weitergeleitet werden soll.
Terminierungen werden in Kontexten zusammengefasst, mit denen festgelegt wird, welche
Quellen an welche Senken weitergeleitet werden. Eine Terminierung muss dabei genau einem
Kontext angehören. Ist eine physikalische Terminierung mit keiner anderen Terminierung
verknüpft ist, wird sie einem speziellen Null-Kontext zugeordnet.
Ein Kontext wird implizit erzeugt, indem eine Terminierung zu einem Kontext mit einer
neuen Kennung hinzugefügt wird. Analog kann eine temporäre Terminierung generiert werden,
indem eine neue Terminierungskennung einem Kontext zugeordnet wird. Diese existiert dann
solange, bis sie vom Kontext wieder entfernt wird. Ein Kontext selbst wird entfernt, wenn
diesem keine Terminierungen mehr zugeordnet sind.
Eine Terminierung wird mit Hilfe von Eigenschaften beschrieben, die mit Befehlen spezifiziert
oder ausgelesen werden können (siehe Anhang G). Man unterscheidet zwischen gemeinsamen
Standardeigenschaften, die den Zustand einer Terminierung festlegen und optionalen
57
6. Gateways
Eigenschaften, die nicht Teil des Basisprotokolls sind. Letztere werden in Paketen gruppiert, die
in eigenen RFCs bzw. im Anhang des [RFC 3525] spezifiziert werden.
In den Standardeigenschaften werden die Medien von Terminierungen mit dem SDP
beschrieben. Es kann zudem eine Topologie angegeben werden, die bestimmt wie die Ströme
zwischen den Terminierungen eines Kontextes weitergeleitet werden.
In zusätzlichen Paketen können Signale, wie Wähltöne oder Ansagen eingeführt werden, die
von einem Media Gateway generiert werden. Es ist auch möglich Ereignisse zu definieren, die
ein Media Gateway an einen Media Gateway Controller melden soll. Das kann z.B. die
Erkennung
einer
Nummer
sein,
die
mit
dem
Tonwahlverfahren
(DTMF)
in
einem
Nutzdatenkanal übermittelt wird. Das Media Gateway kann daraufhin z.B. einen von ihm
generierten Wählton unterbrechen, während der Media Gatway Controller die Information für
einen Verbindungsaufbau verwendet. In Paketen kann außerdem festgelegt werden, auf welche
Weise Statistiken über Terminierungen erhoben werden sollen. [RFC 3525 S.5-27]
6.2 SS7 over IP
Um Telefongespräche aus leitungsvermittelnden Netzen über IP-Netzwerke zu übertragen,
müssen neben Sprachdaten auch Signalisierungsinformationen ausgetauscht werden. Für eine
standardisierte Signalisierung zwischen Vermittlungsstationen in leitungsvermittelnden Netzen
wird in der Regel das zentrale Zeichengabesystem No. 7 (SS7, siehe Anhang A.4) eingesetzt.
Dieses definiert nicht nur ein Signalisierungsprotokoll, sondern einen ganzen Protokollstapel.
Die Protokolleigenschaften der unteren SS7-Schichten können jedoch weder direkt durch das
IP noch durch die verbreiteten Transportprotokolle TCP und UDP zur Verfügung gestellt
werden. Aus diesem Grund wurde das Transportprotokoll SCTP (Stream Control Transmission
Protocol) entwickelt, das als Grundlage für die Übertragung von SS7-Nachrichten über ein IPNetzwerk dient (siehe Anhang H).
Um SS7-Nachrichten mit dem Internet Protokoll zu übertragen, werden am Rand eines IPNetzes sogenannte Signalisierungsgateways (SG) platziert, die nach außen mit jeweils einem
Signalisierungspunkt eines SS7-Netzes verbunden sind (Signaling End Points, Signaling
Transfer Points). Ein Signalisierungsgateway tauscht die unteren SS7-Protokollschichten durch
ein auf dem SCTP basierendes Adapterprotokoll aus und ermöglicht so eine Kommunikation mit
einem MGC, einem Signalisierungspunkt im IP-Netz oder einem Signalisierungsgateway am
anderen Ende des IP-Netzes. Die beiden Komponenten SG und MGC werden auch häufig zu
einem sogenannten Softswitch zusammengefasst.
Von der SigTran werden einige Adapterprotokolle definiert, die in zwei Kategorien eingeteilt
werden. So gibt es für die zweite und die dritten SS7-Protokollschichten sogenannte User
Adaptation Layer (M2UA, M3UA, SUA), mit denen höhere Schichten in Form von Nutzdaten zu
genau einer Gegenstelle transportiert werden können. Um den gesamten Protokollstapel ab der
dritten Schicht zu übertragen, existiert zudem ein sogenannter Peer to Peer Layer (M2PA). In
diesem
werden
Routing-Informationen
interpretiert,
so
dass
Nachrichten
über
Signalisierungspunkte im IP-Netzwerk weitergeleitet werden können. Auf diese Weise sind
nicht nur Transporte in ein IP-Netzwerk, sondern auch durch dieses hindurch möglich
(Transitdienste). [DARROCH]
58
6. Gateways
6.3 SIP-T, SIP-I
Die in Punkt 6.2 genannten Signalisierungsgateways ermöglichen einen Transport von SS7Informationen von einem SG zu einem MGC. Die Informationen werden dort interpretiert und
dienen der Steuerung eines MGs. Es gibt jedoch Szenarien, in denen ein Endpunkt nur über
mehrere miteinander verbundene MGs erreicht werden kann. In diesem Fall müssen die
Signalisierungsinformationen über die zu den MGs gehörenden MGCs weitergeleitet werden.
Um eine vollwertige Kompatibilität mit den ISDN-Zusatzdiensten gewährleisten zu können,
dürfen dabei jedoch keine Informationen durch Konvertierungen vom ISDN User Part (ISUP)
zum SIP verloren gehen. Aus diesem Grund interpretiert ein MGC zunächst die eingehenden
ISUP-Nachrichten und überführt die relevante Informationen ins SIP. Die ursprünglichen
Nachrichten können dann zusätzlich im SIP als Nutzdaten transportiert werden.
Die Übertragung von ISUP-Nachrichten in den Nutzdaten des SIP wird im Session Initiation
Protocol for Telephones (SIP-T) der IETF beschrieben (siehe RFC 3372). Eine alternative
Spezifikation stellt die ITU-T mit der Empfehlung [Q.1912.5] zur Verfügung. Hier werden drei
Profile definiert, mit denen die gewünschte Kompatibilität zwischen den beiden Protokollen
ISUP und SIP festgelegt werden kann. In den Profilen A und B werden die ISUP-Informationen
soweit möglich in die Attribute des SIP und des SDP übersetzt. Im Profil C, dem sogenannten
SIP-I sind die SIP-User Agents selbst in der Lage ISUP-Nachrichen zu verarbeiten. An Stelle
des ISUP unterstützt die Empfehlung der ITU-T auch das Bearer Independent Call Control
Protokoll (BICC, siehe ITU-T Empfehlung Q.1901), das die Anrufsignalisierung vom
Trägermedium und den damit verbundenen Signalisierungsinformationen trennt. [Q.1912.5
S.1-2,8,57-65]
Alternativ zum SIP-T und SIP-I ist es möglich andere Protokolle für die Kommunikation
zwischen MGCs einzusetzten. So können ISUP-Nachrichten, wie in Punkt 6.2 beschrieben, mit
einem SigTran-Adapterprotokoll transportiert werden (siehe Mailing List [SANTI]). Es ist
ebenfalls möglich das H.323 oder SIP zu verwenden. ISDN-Zusatzdienste können dann aber
ggf. nicht ohne Einschränkungen genutzt werden.
6.4 Interoperabilität
Für die Zusammenarbeit verschiedener leitungsvermittelnder Netze wird in der Regel das SS7
als Standard für die Anrufsignalisierung eingesetzt. Mit der Nutzung von IP als Trägermedium
für Telefongespräche ist auch hier eine standardisierte Signalisierung notwendig. Im Laufe der
Zeit sind dazu eine ganze Reihe Protokolle entstanden, die von der IETF und der ITU-T
entwickelt wurden. Sie übertragen bestimmte Teile des SS7 und stellen so sicher, das die
Zusatzdienste der leitungsvermittelnden Netze auch im oder über das Internet Protokoll
genutzt werden können (siehe 6.2 und 6.3).
Zusätzlich zur Interoperabilität der Netze muss in einem IP-Netz darauf geachtet werden,
dass genügend Ressourcen für eine Weiterleitung von Medien- und Datenströmen zur
Verfügung stehen. Das Megaco (siehe 6.1) bietet eine standardisierte Lösung, mit der ein MG
skalierbar wird.
Die folgende Abbildung fasst die Übertragung von Signalisierungsinformationen, sowie die
59
6. Gateways
von Media- und Datenströmen zusammen und zeigt, welche Protokolle zwischen den Akteuren
einsetzbar sind.
Abbildung 4: Anrufsignalisierung zwischen leitungsvermittelnden und IP-Netzen (nach
[DARROCH], [NRIC VI S.9], [SCHERTENLEIB S.39], [SANTI])
SG: Signalisierungsgateway
MG Media Gateway
MGC: Media Gateway Controller
H.323-GK: H.323 Gatekeeper
60
7. Telearbeit
Zur Unterstützung von Telearbeit stellt die ITU-T zwei verschiedene Konzepte zur Verfügung.
So schafft die Empfehlungsserie [T.120] eine Grundlage für die gemeinsame Bearbeitung eines
Dokumentes. Im Gegensatz dazu ist mit der Empfehlung [H.239] lediglich das gemeinsame
Betrachten der Präsentation eines einzelnen Teilnehmers möglich.
7.1 T.120 Protokolle zur Datenübertragung in Konferenzen
Während eines Anrufs oder einer Konferenz sind Situationen vorstellbar, in denen es hilfreich
ist neben Sprache und Video weitere anwendungsspezifische Daten auszutauschen. Die
Empfehlungsserie
[T.120]
beschreibt
Protokolle
zur
Konferenzsteuerung,
welche
dies
ermöglichen.
7.1.1 Multipoint Communication Service
Der Multipoint Communication Service (MCS) stellt einen allgemeinen verbindungsorientierten
Datendienst zur Verfügung, über den verschiedene Endpunkte miteinander kommunizieren
können. Ein Endpunkt enthält dazu einen sogenannten MCS Provider, der sich zusammen mit
den MCS Providern anderer Endpunkte in einer Baumstruktur befindet. Über diese können
anwendungsspezifische Daten auf einem möglichst kurzen Pfad von einem MCS Provider zu
einem anderen versendet werden. Die Datenpakete können dabei einer Prioritätsklasse
zugeordnet werden, mit der bestimmt wird, in welcher Reihenfolge diese weitergeleitet
werden.
Die MCS Provider innerhalb einer Baumstruktur werden unter dem Begriff einer
Mehrpunktdomäne zusammengefasst. Bei einem Verbindungsaufbau werden immer zwei
Domänen zu einer Domäne verschmolzen. Dabei ist es auch möglich, dass ein MCS Provider
mehreren Domänen gleichzeitig angehört. Wird eine Verbindung beendet, bleibt der
Domänenteil mit dem obersten Provider, dem sogenannten Top Provider erhalten. Der
getrennte Teil der Domäne erlischt.
Innerhalb
einer
Domäne
werden
Kanäle
definiert,
auf
denen
Provider
Steuerungsinformationen und anwendungsspezifische Daten senden können. Die Provider
können wiederum Kanäle abonnieren, um die darauf übertragenen Daten zu empfangen. Es
gibt sowohl statische Kanäle, die zusammen mit einer Domäne erzeugt werden als auch
dynamische Kanäle, die von einem Provider beantragt werden. Letztere können entweder von
allen (Multicast-Kanäle) oder nur von ausgewählten Providern (Private- bzw. Single-MemberKanäle) genutzt werden.
Die Wurzel des Domänenbaums übernimmt die Aufgabe der Ressourcenverwaltung und wird
in der Regel von einer MCU repräsentiert. Sie vergibt Zugriffsrechte auf Kanäle und bietet
Tokens an, die außerhalb des MCS, z.B. für einen exklusiven Zugriff auf anwendungsspezifische
Ressourcen genutzt werden können. Zudem werden sequenzielle Datenübertragungen
zwischen Providern über die Wurzel geleitet, damit die Pakete bei jedem Provider in der
61
7. Telearbeit
richtigen Reihenfolge eintreffen.
Der
MCS
ermöglicht
sowohl
einen
unzuverlässigen
als
auch
einen
zuverlässigen
Datenaustausch. Um die Zuverlässigkeit zu garantieren, muss ein Empfänger jedoch eine
gewisse Datenrate verarbeiten können. Ist dies nicht der Fall, wird dieser von der
Kommunikation ausgeschlossen. Bei Multicast-Verbindungen kann so sichergestellt werden,
dass es zu keinen Überläufen von Sende-Buffern kommt.
Anhang B.6 enthält eine Auflistung verschiedener MCS-Nachrichten. [T.120 S.3-5,811][T.122 S.1-10][T.125 S.1-6,8-11,75]
7.1.2 Generic Conference Control
Der Generic-Conference-Control- (GCC) Dienst verwendet den MCS und definiert Abläufe für
den Auf- und Abbau sowie die Steuerung einer Konferenz. Vor einer Teilname kann ein
sogenannter GCC-Provider zunächst eine Liste mit allen zur Zeit unterhaltenen Konferenzen
einsehen. Er kann dann einer Konferenz beitreten oder eine neue Konferenz eröffnen.
Konferenzen können entweder für jeden zugänglich sein oder durch ein Passwort geschützt
werden. Es ist auch möglich den Zugang nur auf eingeladene GCC-Provider zu beschränken.
Konferenzen können gleichberechtigt ablaufen oder sie unterstehen einer Leitung. Diese wird
mit einem Token signalisiert, welches zwischen Teilnehmern ausgetauscht werden kann.
Nach dem Beitritt zu einer Konferenz, teilt ein Provider den anderen Teilnehmern seine
Anwesenheit sowie die für eine Kommunikation notwendigen Daten mit. Diese werden dann in
den
Konferenzlisten
(Conference
Roster)
der
anderen
Provider
eingetragen.
Jeder
Konferenzteilnehmer versendet anschließend eine Auflistung seiner Anwendungen (sein Local
Application Roster), die bei allen Providern in einer weiteren Liste (Conference Application
Roster) eingetragen werden. Auf diese Weise kann die gemeinsame Schnittmenge der
Fähigkeiten und der Anwendungen für eine konferenzweite Kommunikation bestimmt werden.
Neben den lokalen Listen unterhält der oberste GCC-Provider, der sogenannte Top GCC
Provider eine zentrale Registrierungsdatenbank (GCC Application Registry). In dieser werden
Kanäle, Tokens und andere Ressourcen einer Konferenz verwaltet, um den Verbindungsaufbau
zwischen Anwendungen zu unterstützen.
In Anhang B.7 ist eine Auflistung der GCC-Nachrichten zu finden. [T.120 S.8,11][T.124 S.112,55,61,76]
7.1.3 Generic Application Template
Die Empfehlung [T.121] beschreibt eine Vorlage für Anwendungen (Generic Application
Template, kurz GAT), die während einer T.120-Konferenz miteinander kommunizieren können.
Eine solche Anwendung besitzt eine oder mehrere sogenannte Application Protocol Entities
(APE), die für die Kommunikation verantwortlich sind. Eine APE beinhaltet wiederum eine
Verwaltung für GCC- und MCS-Ressourcen (Application Resource Manager). Sie enthält
außerdem ein anwendungsspezifisches Dienstelement (Application Service Element), das die
Zusammenarbeit mit bestimmten Anwendungen (siehe 7.1.4) unterstützt.
62
7. Telearbeit
Jedes APE kann an maximal einer Anwendungsprotokollsitzung (Application Protocol
Session) teilnehmen. Dabei ist es auch möglich, dass verschiedene Instanzen einer Anwendung
innerhalb eines Gerätes eine gemeinsame Sitzung unterhalten. Eine Sitzung kann mehrere
Kanäle und Tokens umfassen und wird über eine MCS-Kanalkennung identifiziert. Einzige
Ausnahme bildet eine Registrierungssitzung, in der Anwendungen ihre Anwesenheit sowie ihre
spezifische
Funktionalität
ankündigen.
Eine
Anwendung
wird
hier
über
einen
Anwendungsschlüssel gekennzeichnet. Neben der Registrierungssitzung gibt es vier weitere
Arten von Sitzungen:
Die Standard Base Session ist für standardisierte Anwendungsprotokolle reserviert.
Sie
verwendet die Sitzungskennung eines vordefinierten statischen MCS-Kanals.
Die Non-Standard Base Session nutzt eine dynamische MCS-Kanalkennung, die in der
zentralen GCC-Registrierungsdatenbank hinterlegt wird.
Eine Public Session wird erzeugt, wenn die Base Session einer Anwendung bereits
verwendet wird und eine weitere unabhängige Sitzung nötig ist. Sie kann uneingeschränkt
betreten werden und bleibt so lange bestehen bis der letzte Teilnehmer sie verlässt.
Eine Private Session erlaubt nur ausgewählten Benutzern an dieser teilzunehmen. Sie wird
beendet, sobald der initiierende Teilnehmer diese verlassen hat.
[T.121 S.1-9][T.120 S.12]
7.1.4 Anwendungen
In weiteren ITU-T-Empfehlungen der T.120-Serie werden einige konkrete Anwendungen
standardisiert. Zu diesen gehört der Austausch unbewegter Bildinformationen in der
Empfehlung [T.126]. Diese beschreibt neben rasterbasierten Bitmaps auch Zeichenoperationen
mit denen Polygone, Punkte, Rechtecke, Ellipsen und Text auf einem gemeinsamen WhiteBoard
positioniert
werden
können.
Die
Empfehlung
T.127
stellt
einen
allgemeinen
Übertragungsdienst für anwendungsspezifische Daten zur Verfügung [T.121 S.3]. In der
Empfehlung [T.128] wird die Anzeige und Steuerung entfernter Anwendungen betrachtet.
7.2 H.239 Präsentationsvideos
Eine häufig benötigte Anwendung während einer Konferenz ist die visuelle Präsentation, um
Informationen zu veranschaulichen. Die Übertragung der dabei anfallenden Bilddaten wird in
der Empfehlung [H.239] mit einem sekundären Videokanal realisiert. Um diesen von den
anderen Kanälen zu unterscheiden, definiert die Empfehlung Rollen, die einem Kanal
zugewiesen werden können. Das ist zum einen die Live-Rolle, mit der das Video eines
Konferenzteilnehmers gekennzeichnet wird. Zum anderen gibt es die Präsentationsrolle, die
das wichtigsten Video der Konferenz markiert. Sie wird mit einem konferenzweiten Token
verwaltet, das bestimmt, welcher Teilnehmer mit dieser Rolle senden darf.
Die ITU-T-Empfehlung H.245 unterstützt zwar auch die Verwendung mehrerer Videokanäle,
allerdings können diese nicht als Präsentation gekennzeichnet oder gesondert gesteuert
werden. Die Empfehlung [H.239] definiert daher Nachrichten, mit denen die Empfehlungen
63
7. Telearbeit
H.320 und H.245 erweitert werden. Die entsprechenden Nachrichten werden im Anhang B.8
aufgeführt. [H.239 S.1,4-16]
64
8. Ausblick
Das Internet Protokoll hat sich im Laufe der Zeit zu einem Übertragungsstandard für
verschiedene Anwendungen entwickelt. Dazu zählt neben Datendiensten auch der Transport
audiovisueller Medien, für den zuvor ein eigenständiges oder leitungsvermittelndes Netz nötig
war. Solche Netze garantieren eine feste Datenrate und sind damit für die Übertragung von
Medien mit beschränkten Ressourcen gut geeignet. Durch die wachsende Bandbreite wurde
dann aber die Übertragung von Telefongesprächen auch in IP-Netzwerken möglich. Mittlerweile
können außerdem Fernsehprogramme transportiert werden. Geht man davon aus, dass in
Zukunft immer höhere Datenraten zu Verfügung stehen, müssen demnächst
Anwendungen geschaffen werden, die in der Lage sind das Potential auszuschöpfen.
neue
Die Übertragung von VoIP und IPTV wird in der Regel nicht über das unkontrollierte
Internet, sondern über Leitungen des entsprechenden Anbieters geführt. Nur so kann dieser
heute Garantien für die Qualität eines Dienstes geben. In einigen Jahren mag es aber durchaus
möglich sein, dass auch diese Dienste in vollständige Internet-Dienste übergehen. Dann wird
sich zeigen, ob dies mit purer Bandbreite oder mit QoS-Mechanismen in Weitverkehrsnetzen zu
erreichen ist. Andere Dienste, wie Telefax und Teletext könnten darüber hinaus durch andere
Techniken, wie E-Mail und Webdienste vollständig abgelöst werden.
Zur Realisierung "klassischer Telekommunikationsanwendungen" und ihrer Mehrwertdienste
über IP können Hersteller und Anbieter auf eine Reihe standardisierte Protokolle und Verfahren
zurückgreifen. So stellen die ITU-T und die IETF für VoIP zwei unterschiedliche Ansätze zur
Verfügung. Nicht berücksichtigte Dienste werden in der Regel mit proprietären Protokollen
ergänzt. Das InterAsterisk-Protokoll (IAX) unterstützt auf diese Weise z.B. das Versenden eines
Rufnummernplans. Im Falle des Internetradios ersetzen jedoch proprietäre Verfahren
vorhandene Standards, so dass hier ggf. mehrere Programme zur Wiedergabe nötig sind.
Analog zur drahtgebundenen Telekommunikation werden auch Mobilfunknetze seit den
1990er Jahren mit Techniken, wie GPRS und UMTS auf paketbasierte Dienste umgestellt. Daher
wird heute versucht, die mobile Nutzung von E-Mail, Web- oder anderen Datendiensten auch
für Privatkunden interessant zu machen. Im Gegensatz zur SMS werden diese nämlich
überwiegend von Geschäftskunden genutzt. Ggf. müssen dazu neue Darstellungs- und
Bedienkonzepte geschaffen werden, die sich an den Anforderungen reisender Personen
orientieren.
65
8. Ausblick
66
Anhang A - ISDN
Da ISDN noch weit verbreitet ist und eine Interoperabilität mit VoIP gewährleistet werden
muss, wird dieses hier grob umrissen.
A.1 Schnittstellen des ISDN-Basisanschlusses
Anders als im bekannten Ethernet-LAN, kommen beim ISDN-Basisanschluss ggf. nicht alle OSISchichten am Endgerät an. In der Referenzkonfiguration [I.411] werden sogenannte
Referenzpunkte beschrieben, die jeweils einer physikalischen Schnittstelle entsprechen.
Abbildung 5: Basic Rate ISDN Customer's Interface
Nach einer ersten Netzwerkterminierung, z.B. durch ein eigenständiges Gerät, kann am
Referenzpunkt T auf die Bitübertragungsschicht [I.430] zugegriffen werden. Diese überträgt
zwei B-Kanäle mit jeweils 64kbit/s sowie einen D-Kanal mit einer Bandbreite von 16kbit/s. Die
Bitübertragungsschicht ist für das Timing und für das Multiplexing bzw. Demultiplexing der
einzelnen Kanäle verantwortlich. Über eine Deaktivierungsfunktion können ISDN-Geräte in
einen Stromsparmodus versetzt werden, der insbesondere für die optionale Stromversorgung
durch das Netz relevant ist. Da die Rahmen von verschiedenen Endgeräten miteinander
kollidieren können, wiederholt ein Netzwerkterminierungspunkt alle D-Kanal-Daten in einem
Echokanal. Empfängt ein Endgerät andere Daten als es gesendet hat, bricht es die
Übertragung ab.
In
vielen
Fällen
müssen
die
Daten
über
verdrillte
Metallleitungespaare
zur
Vermittlungsstation übertragen werden. Der Duplexbetrieb wird hier mittels zeitlichem
Multiplexing (TDM bzw. TCM) oder via Echoauslöschung (Echo Cancelation) realisiert. [I.430
S.4-10,18][G.961 S.13]
67
Anhang A - ISDN
Abbildung 6: Struktur eines ISDN-Rahmens
D: D-Kanal
E: Echo des D-Kanals zur Kollisionserkennung
L: Gleichspannungsausgleich
F: Das Framing Bit dient zur Synchronisation und entspricht einer binären Null. Aufgrund
des Leitungscodes wird diese als alternierendes Signal übertragen.
B1: erster B-Kanal
B2: zweiter B-Kanal
A: Aktivierungsbit aktiviert einen Netzwerkterminierungspunkt oder ein Endgerät
M: Multiframing signalisiert die Verwendung von weiteren Kanälen (S und Q) zwischen den
Endgeräten und einem Netzwerkterminierungspunkt.
F_A: Framing Bit oder Q-Kanal
N: Inverses von F_A
S: S-Kanal
Der Referenzpunkt S steht nach einer weiteren Netzwerkterminierung zur Verfügung und
reduziert den Zugriff innerhalb des D-Kanals auf die Sicherungs- und Vermittlungsschicht. Die
Sicherungsschicht [Q.921] spezifiziert das HDLC-LAPD-Verfahren, das zur Fehlererkennung und
-korrektur verwendet wird. Dieses erstellt eine CRC Frame Check Sequence über die
relevanten Daten, welche sich aus einer Adresse, Steuerungsinformationen und bei Bedarf aus
weiteren Daten der Vermittlungsschicht zusammensetzen. Alternativ zur gesicherten
Verbindung ist auch der Versand unbestätigter Nachrichten möglich. Ein Rahmen der
Sicherungsschicht wird durch die Bitfolge 01111110 eingeleitet wobei die Transparenz der
Daten mittels Bitstuffing gewährleistet wird. [Q.921 S.6-10,15]
68
Anhang A - ISDN
Abbildung 7: Rahmen der Sicherungsschicht
In Deutschland werden die vorgestellten Netzwerkterminierungspunkte im sogenannten NTBA
zusammengefasst. An diesen können z.B. Endgeräte vom Typ 1 angeschlossen werden, die
über eine ISDN-Schnittstelle verfügen. Andere Endgeräte entsprechen dem Typ 2 und
benötigen einen vorgeschalteten Adapter. Dieser stellt den Referenzpunkt R zur Verfügung.
[I.411]
Um die Interoperabilität zwischen den ISDN-Implementierungen innerhalb von Europa zu
gewährleisten, spezifiziert die ETSI im Standard [ETS 300 102-1] das sogenannte Digital
Subscriber Signalling one (DSS1). Das DSS1 basiert auf der Empfehlung I.411 und beschreibt
die Vorgänge auf der Vermittlungsschicht. Es erlaubt u.a. die Verwendung der weit verbreiteten
Q.931-Nachrichten, auf die im Anhang A.3 beispielhaft eingegangen wird.
A.2 Primary Service
Neben dem ISDN-Basisanschluss (Basic Service) existiert ein sogenannter Primary Service,
mit dem eine Bruttodatenrate von 1544kbit/s bzw. 2048kbit/s erreicht wird. Die Daten werden
in 23 bzw. 30 B-Kanälen mit jeweils 64kbit/s, in 3 bzw. 5 H0-Kanälen mit jeweils 384kbit/s
oder in einem H1-Kanal mit 1536kbit/s bzw. 1920kbit/s übertragen. Die Datenrate des D69
Anhang A - ISDN
Kanals wird auf 64 kbit/s angehoben. [I.431]
A.3 Q.931 Verbindungsaufbau im ISDN
Die Empfehlung [Q.931] spezifiziert Abläufe für den Auf- und Abbau von ISDN-Verbindungen
zwischen Endgeräten. Um einen Überblick über die wichtigsten Q.931-Nachrichten zu erhalten,
werden diese hier in einem kurzen Szenario vorgestellt:
Zum Aufbau einer ISDN-Sprachverbindung nimmt ein Teilnehmer A den Hörer ab, woraufhin
das Endgerät die Nachricht SETUP an die Vermittlungsstation überträgt. Enthält die Nachricht
bereits vollständige Wählinformationen, sendet die Vermittlungsstation eine CALLPROCEEDING-Nachricht zurück. Diese bestätigt, dass die Verbindung aufgebaut wird und keine
weiteren Wählinformationen akzeptiert werden.
Fehlen noch Informationen für den Aufbau der Verbindung, sendet die Vermittlungsstation
die Nachricht SETUP ACKNOWLEDGE. Auf diese kann das Endgerät mit INFORMATION
Nachrichten antworteten, um die fehlenden Informationen nachzuliefern. Dabei wird für jede
Wählziffer eine INFORMATION-Nachricht versendet. Vor der Eingabe der ersten Ziffer ist ein
Wählton zu hören.
Nachdem eine CALL-PROCEEDING-Nachricht vom Endgerät empfangen wurde, versendet die
Vermittlungsstation eine gemeinsame SETUP-Nachricht an alle Endgeräte von Teilnehmer B.
Diese prüfen nun, ob sie kompatibel sind und antworten im positiven Fall jeweils mit der
Nachricht ALERTING. Die Vermittlungsstation leitet die ALERTING-Nachricht an das Endgerät
von Teilnehmer A weiter, bei dem nun ein Freiton zu hören ist. An den kompatiblen Endgeräten
von Teilnehmer B wird der eingehende Anruf z.B. durch ein Klingeln signalisiert.
Teilnehmer B hebt den Hörer von einem Endgerät ab, welches daraufhin die Nachricht
CONNECT versendet, die über das Netz an das Endgerät von Teilnehmer A weiterpropagiert
wird. Dieses bestätigt die Nachricht mit einer CONNECT-ACKNOLEDGE-Nachricht und die
Kommunikationsphase beginnt. Um die anderen Endgeräte von Teilnehmer B in den
Normalzustand zurückzuversetzen, erhalten diese jeweils RELEASE-Nachrichten von der
Vermittlungsstation. Jedes Endgeräte sendet daraufhin eine RELEASE-ACKNOWLEDGENachricht zurück.
Die Kommunikationsphase kann jederzeit von beiden Teilnehmern abgebrochen werden.
Teilnehmer A legt dazu den Hörer auf, woraufhin sein Endgerät die Nachricht DISCONNECT an
die Vermittlungsstation sendet. Diese antwortet mit einer RELEASE-Nachricht, die das Endgerät
wiederum mit der Nachricht RELEASE COMPLETE bestätigt. Gleichzeitig versendet die
Vermittlungsstation die Nachricht DISCONNECT an das Endgerät von Teilnehmer B, welches
mit der Nachricht RELEASE antwortet. Die Vermittlungsstation bestätigt diese abschließend mit
einer RELEASE-COMPLETE-Nachricht und die Verbindung ist abgebaut. [GRIFFITHS S.86]
70
Anhang A - ISDN
Abbildung 8: Verbindungsaufbau und Auslösung eines ISDN Basic Calls
A.4 SS7
Alle Signalisierungsdaten, die mit ISDN an eine Vermittlungsstelle gelangen, werden in der
Regel mit dem SS7 weitergeleitet. Dieses wird in der Empfehlung [Q.700] der ITU-T spezifiziert
und
stellt
einen
internationalen
Standard
für
die
Kommunikation
zwischen
Vermittlungsstationen (auch Signalisierungspunkte genannt) dar. Es wurde für verschiedene
Anwendungen
konzipiert
und
kann
z.B.
auch
in
Mobilfunknetzen
oder
im
analogen
Telefonsystem eingesetzt werden.
Im SS7 werden die Funktionen in Übertragungs- und Benutzerfunktionen unterteilt. So gibt
es auf den unteren drei OSI-Schichten als Übertragungsfunktion die Message Transfer Parts
(MTP), die zusammen eine zuverlässige Ende-zu-Ende-Datenübertragung anbieten. Darauf
aufbauend existiert der Signalling Connection Control Part (SCCP), der Routing anhand von
Wählinformationen unterstützt. Der SCCP wird ebenso wie der MTP 3 der Vermittlungsschicht
71
Anhang A - ISDN
zugeordnet und stellt sowohl verbindungslose als auch verbindungsorientierte Netzwerkdienste
zur Verfügung.
Die Benutzerfunktionen können die genannten Übertragungsfunktionen nutzen, um
anwendungsspezifische Signalisierungsinformationen zu versenden. Definiert sind z.B. der
Telephone User Part (TUP), der Data User Part (DUP) und der ISDN User Part (ISUP). Die
Transaction Capabilities (TC bzw. TCAP) bilden zudem eine Zwischenschicht, die z.B. vom
Mobile Application Part (MAP) verwendet wird.
Abbildung 9: SS7-Protokollstapel
A.5 ISDN User Part
ISUP ist ein SS7-Protokoll, dass den Auf- und Abbau von ISDN-Verbindungen sowie die in
Punkt 4.1.2 definierten Zusatzdienste unterstützt. Die von einer Vermittlungsstation
empfangenen Q.931-Nachrichten (siehe A.3) stoßen dazu eine Kommunikation mit anderen
Vermittlungsstationen an. Dabei kommen Nachrichten zum Einsatz, die in den ITU-TEmpfehlungen Q.762, Q.763 und Q.764 beschrieben werden. Um einen kurzen Einblick in den
ISDN User Part zu erhalten, wird im Folgenden der Zusatzdienst Anklopfen (Call Waiting) als
Beispielszenario betrachtet:
Beispiel: Anklopfen
Zwischen den beiden Endgeräten A und B besteht eine Verbindung, über die sich zwei
Teilnehmer unterhalten. Ein weiterer Teilnehmer versucht mit dem Endgerät C eine Verbindung
zum Endgerät B aufzubauen und sendet dazu die Nachricht SETUP an seine
Vermittlungsstation. Die Kontaktinformationen, wie z.B. die Rufnummer werden im ISUP mit
der Nachricht Initial Address (IAM) bis zur Vermittlungsstation von Endgerät B weitergeleitet.
Am Endgerät B ist der Zusatzdienst Anklopfen aktiviert, so dass der Anruf von Endgerät C
signalisiert wird. Endgerät B sendet daraufhin die Nachricht ALERTING, die zwischen den
Vermittlungsstationen B und C als Address-Complete-Nachricht (ACM) übertragen wird. Diese
enthält gleichzeitig die Information, dass an eine laufende Verbindung angeklopft wurde (CW).
72
Anhang A - ISDN
Teilnehmer B kann nun den Anruf von Teilnehmer C annehmen, so dass sein Endgerät die
Nachricht CONNECT versendet. Diese wird im ISUP mit der Nachricht Answer (ANM)
übertragen, die gleichzeitig dafür sorgt, dass die Kostenabrechnung für Teilnehmer C gestartet
wird. Die Verbindung mit Teilnehmer A kann entweder mit einem weiteren Zusatzdienst
gehalten oder beendet werden. [Q.733.1 S.5][Q.762 S.4-5]
Abbildung 10: Anklopfen im ISUP
A.6 Breitband ISDN
Ende der 1980er Jahre gab es Bestrebungen, das ISDN zu einem Netzwerk auszubauen, das in
der Lage ist, Daten verschiedener Anwendungen zu übertragen. Dabei standen insbesondere
Anwendungen, wie Multimediakonferenzen oder Fernsehen im Vordergrund, die eine sehr viel
höhere Bandbreite als die Telefonie benötigen. Für den Transport solcher Daten spezifiziert die
CCITT/ITU-T das Breitband-ISDN (B-ISDN), welches auf Technologien, wie der Plesiochronen
bzw. Synchronen Digitalen Hierarchie (PDH/SDH) und dem Asynchronen Transfer Mode (ATM)
basiert (siehe A.7 und A.8). [I.211]
A.7 ATM
Der Asynchrone Transfer Mode (ATM) wurde Anfang der 1990er Jahre für das B-ISDN
entwickelt und wird von der ITU-T in diversen Empfehlungen spezifiziert. Es ist sowohl auf der
Sicherungs- als auch auf der Vermittlungsschicht einzuordnen und kann z.B. mit ADSL oder
73
Anhang A - ISDN
SDH übertragen werden.
Im Gegensatz zum schmalbandigen ISDN erlaubt ATM einen asynchronen Versand von
Daten. Das bedeutet, dass ein Endgerät den Zeitpunkt einer Datenenübertragung selbst
wählen kann, ohne das Bandbreite im vorhinein reserviert werden muss.
Vor einer Datenübertragung wird in allen Knoten auf dem Pfad zwischen zwei Endpunkten
zunächst eine Verbindung etabliert. Es können dann Pakete (Zellen) mit jeweils 48 Byte
Nutzdaten übertragen werden. Anstelle einer Endpunktadresse wird im ATM-Header die
Verbindung über zwei Kennungen identifiziert, sodass die Adressierungsinformationen
minimiert werden. In Zeiträumen, in denen kein Endgerät Daten überträgt werden leere Pakete
versendet.
Oberhalb der ATM-Schicht kann einer von fünf ATM Adaptation Layer verwendet werden, der
eine bestimmte Dienstklasse unterstützt. Dies können Dienste mit konstanter oder variabler
Datenrate, verbindungslose, verbindungsorientierte, synchrone oder asynchrone Dienste sein.
Zudem kommt in der Regel eine Zwischenschicht zum Einsatz mit der Daten, die größer als
eine Zelle sind, segmentiert und reassembliert werden können. [SCHNABEL]
A.8 PDH/SDH
Die Plesiochrone und Synchrone Digitale Hierarchie (PDH/SDH) sind Übertragungsverfahren,
die verschiedene Datenströme niedrigerer Bandbreite zu einem Datenstrom höherer
Bandbreite zusammenfassen (Multiplexing). Auf diese Weise können mehrere Ströme
gleichzeitig über ein Weitverkehrsnetz transportiert werden. Die Verfahren werden in der Regel
mehrmals nacheinander angewendet, so dass mehrere Hierarchieebenen mit steigenden
Bandbreiten entstehen.
Die PDH wurde Anfang der 1970er Jahre eingeführt, um mehrere PCM-Datenströme
zusammenzufassen. Die USA, Japan und Europa verwendeten jedoch unterschiedliche
Datenraten für PCM-Ströme, sodass nur bestimmte Hierarchieebenen miteinander verbunden
werden konnten. Da es zu dieser Zeit nicht möglich war an verschiedenen Orten einen
gemeinsamen Takt zur Verfügung zu stellen, konnten die Daten außerdem nicht völlig synchron
übertragen werden. Daher wird der Takt bei der PDH lokal erzeugt und Abweichungen mit Hilfe
von Stopfbits kompensiert. Die Stopfbits verhindern aber auch die Positionsbestimmung eines
Datenstroms, sodass für das Ein- und Auskoppeln die gesammte Hierarchie aufgespaltet
(Demultiplexing) und anschließend wieder zusammengesetzt werden muss.
Die SDH entspricht dem amerikanischen SONET (Synchrones Optisches Netzwerk) und ist
mit der PDH interoperabel. Sie verwendet einen globalen Takt und ermöglicht ein einfaches
Ein- und Auskoppeln einzelner Datenströme. Die Daten werden in virtuellen Containern
gekapselt und sind nicht an SDH-Rahmengrenzen gebunden. Dies wird mit Hilfe eines Zeigers
realisiert, der den Anfang eines Containers referenziert. Auf diese Weise können auch Daten
versendet werden, die zeitversetzt zu einem SDH-Rahmen eintreffen. [FREIERMUTH]
74
Anhang A - ISDN
A.9 PPP
Das Point-to-Point Protocol (PPP) wird im RFC 1661 beschrieben und dient dem Transport von
Datagrammen zwischen zwei direkt miteinander verbundenen Teilnehmern. Es setzt eine
Fullduplex-Verbindung sowie einen geordneten Versand von PPP-Rahmen vorraus und kapselt
Datagramme verschiedener Vermittlunsschichtprotokolle. Es kann die Rahmengrenzen mit Hilfe
von HDLC-Flags sowie entsprechende Vorkommen in den Nutzdaten mit Fluchtzeichen
kennzeichnen und eine Prüfsumme zur Fehlererkennung bereitstellen. Optional ist ein
gesicherter Transport möglich.
Innerhalb des PPP wird das Link Control Protocol (LCP) spezifiziert, das zum Auf- und Abbau
von Verbindungen dient. Dieses ermöglicht die Aushandlung von Optionen und kann so z.B. die
maximal empfangbare Rahmengröße festlegen oder Authentifizierungsdaten übertragen. Für
jedes unterstützte Vermittlungsschichtprotokoll kann außerdem ein entsprechendes Network
Control Protocol (NCP) gewählt werden, mit dem besondere Anforderungen unterstützt
werden. Bei IP ist das z.B. die dynamische Zuweisung von Adressen. [TANENBAUM S.256-260]
LCP-Nachrichten
Configure-Request stellt eine Verbindung her und schlägt eine Reihe von Optionen vor.
Configure-Ack bestätigt, dass alle Optionen eines Configure-Request erkannt und akzeptiert
wurden.
Configure-Nack bestätigt, dass alle Optionen eines Configure-Request erkannt wurden. Es
konnten aber nicht alle Werte akzeptiert werden. Die Nachricht enthält die nichtakzeptierten Werte.
Configure-Reject signalisiert, dass nicht alle Optionen erkannt wurden, dass eine wertelose
Option nicht akzeptiert wurde oder dass eine Option nicht verhandelbar ist. Die Nachricht
enthält die betreffenden Optionen.
Terminate-Request und Terminat-Ack beenden eine Verbindung.
Code-Reject signalisiert, dass eine andere Version verwendet wird.
Protocol-Reject signalisiert, dass ein angegebenes Protokoll nicht unterstützt wird.
Echo-Request und Echo-Reply unterstützen Loopback für Debugging.
Discard-Request signalisiert, dass ein Empfänger alle Anfragen verwerfen soll. (Unterstützt
Debugging)
A.10 PPPoE
Das PPP over Ethernet (PPPoE) wird im [RFC 2516] beschrieben und stellt Punkt-zu-Punkt
Beziehungen zwischen einzelnen Ethernet-Geräten her, damit diese darüber PPP-Verbindungen
aufbauen können. In einer Erkennungsphase versendet ein Client zunächst ein EthernetBroadcast, um alle verfügbaren Server, sogenannte Access Concentrators ausfindig zu machen.
Nachdem diese geantwortet haben, kann der Client einen Server auswählen und eine Punktzu-Punkt Beziehung über das Ethernet aufbauen. In der Sitzungsphase werden die PPP75
Anhang A - ISDN
Rahmen dann jeweils im Nutzdatenfeld eines PPPoE-Pakets und ohne HDLC-Flags gekapselt
übertragen. [RFC 2516]
Nachrichten der Erkennungsphase
Active Discovery Initiation (PADI) ist eine Broadcast-Anfrage nach einem bestimmten
Dienst.
Active Discovery Offer (PADO) wird von einem Access Concentrator gesendet, wenn er einen
gesuchten Dienst anbietet.
Active Discovery Request (PADR) sucht eines der Angebote (PADO) aus.
Active Discovery Session-confirmation (PADS) bestätigt, dass die PPP-Sitzung eingerichtet
wurde. Die Nachricht enthält eine entsprechende Sitzungskennung.
Active Discovery Terminate (PADT) signalisiert, dass eine Sitzung beendet wurde.
A.11 ADSL
Die ITU-T spezifiziert in der Empfehlung G.992.1 die Asymmetric Digital Subscriber Line, um
Haushalte über übliche verdrillte Metallleitungspaare mit einem Breitbandnetzwerk zu
verbinden. Der bislang ungenutzte Frequenzbereich oberhalb des analogen Telefondienstes
bzw. oberhalb von ISDN wird dazu in der Regel mit einer Frequenzweiche (Splitter)
abgetrennt. Auf diese Weise kann auch eine Duplexübertragung von Daten realisiert werden,
indem ein Bereich zum Empfangen und ein anderer zum Senden verwendet wird.
Bei ADSL wird der gesamte Frequenzbereich bis 1104kHz in 256 Unterfrequenzbereiche zu
je 4,3kHz aufgeteilt, von denen bis zu 254 Bereiche genutzt werden können. Pro Sekunde
werden 4000 ADSL-Rahmen erzeugt, sodass mit einer QAM bis zu 15 Bit pro
Unterfrequenzbereich und Rahmen übertragen werden können. So ergibt sich eine maximale
Datenrate von 15,24Mbps, die jedoch durch die Systemarchitektur auf 8Mbps beschränkt ist.
Das gesamte Modulationsverfahren wird als Discrete Multitone Transmission (DMT) bezeichnet.
Jeweils 69 Rahmen werden zu einem Superrahmen zusammengefasst, von denen der letzte
ein Synchronisationssymbol enthält. Die übrigen Rahmen transportieren neben den Nutzdaten
CRC- und Steuerungsinformationen sowie Daten zur FEC. Als Algorithmus für die FEC kommt
das Reed Solomon-Verfahren zum Einsatz.
Die Nutzdaten können entweder auf einem sogenannten Fast Path oder einem Interleaved
Path übertragen werden. Letzterer verteilt die Informationen zur FEC zwischen den Nutzdaten,
wodurch eine geringere Fehlerrate erreicht wird. Dies erzeugt jedoch eine zusätzliche
Verzögerung, die auf dem Fast Path vermieden wird. [LANGLOIS]
76
Anhang B - H.323 Signalisierungsnachrichten
An dieser Stelle werden die Signalisierungsnachrichten der ITU-T Empfehlung H.323
aufgeführt. Die Empfehlungen [H.225 S.141-177], [H.245 S.11-77], [T.125 S.14-36] und
[T.124 S.172-194] verwenden zur Beschreibung des Nachrichtenaufbaus die Abstract Syntax
Notation No. 1 (ASN.1). Die H.223-, H.239 und H.245-Nachrichten werden nach der Variante
Aligned der Packed Encoding Rules (PER) gemäß der Empfehlung X.691 kodiert. Die T.120
Nachrichten können abhängig von der Version auch nach den Basic Encoding Rules (BER,
X.690) kodiert werden.
B.1 H.225 Nachrichten des RAS-Kanals
GRQ (Gatekeeper Request) wird von einem Endgerät gesendet und holt eine
Registrierungserlaubnis von einem Gatekeeper ein.
RRQ (Registration Request) registriert Kontaktinformationen eines Endgerätes bei einem
Gatekeeper.
URQ (Unregistration Request) entfernt eine Registrierung bei einem Gatekeeper.
ARQ (Admission Request) holt bei einem Gatekeeper die Erlaubnis für die Nutzung des
Netzes ein.
BRQ (Bandwidth Request) beantragt bei einem Gatekeeper oder einem Endgerät eine
Bandbreitenänderung.
DRQ (Disengage Request) informiert einen Gatekeeper, dass ein Endgerät eine Verbindung
verlässt.
LRQ (Location Request) übergibt einen Alias und erwartet die Rückgabe einer
Netzwerkadresse zur Kontaktaufnahme.
Für jede zuvor genannten Anfragen existieren bestätigende (Acknowledge) und ablehnende
(Negative Acknowledge) Antworten.
IRQ (Info Request) beantragt bei einem Endgerät Berichte über bislang geführte
Verbindungen.
IRR (Info Request Response) überträgt einen Bericht.
IACK (Info Request Acknowledge) bestätigt den Erhalt eines Berichts.
INAK (Info Request Negative Acknowledge) signalisiert, dass ein Bericht nicht angenommen
wurde, weil z.B. das Endgerät nicht beim Gatekeeper registriert ist.
RIP (RAS timers and Request in Progress) verschiebt laufende Anfragen, wenn sie nicht
sofort beantwortet werden können.
RAI (Resources Available Indicate) teilt einem Gatekeeper die Auslastung eines Gateways
77
mit.
RAC (Resources Available Confirm) bestätigt den Erhalt einer RAI-Nachricht.
SCI (Service Control Indication) öffnet eine neue Dienststeuerungssizung (z.B. für HTTP als
Zusatzdienst [H.323 S. 206])
SCR (Service Control Response) bestätigt den Erhalt einer SCI-Nachricht.
NSM (Non-standard message) richtet Beziehungen zwischen Endgeräten ein, die nicht im
Standard spezifiziert sind.
XRS (Message not understood) signalisiert, dass eine Nachricht nicht ausgewertet werden
konnte.
B.2 Q.931 Signalisierungsnachrichten
Verbindungsaufbau
ALERTING zeigt an, dass ein Benutzer über einen eingehenden Anruf informiert wurde.
CALL PROCEEDING signalisiert, dass ein angeforderter Verbindungsaufbau initiiert wurde.
CONNECT akzeptiert einen eingehenden Anruf.
CONNECT ACKNOWLEDGE bestätigt, dass eine Verbindung aufgebaut ist und Medienkanäle
genutzt werden können.
PROGRESS zeigt den Fortschritt eines Anrufs an (z.B. das Ziel ist kein ISDN).
SETUP initiiert einen Verbindungsaufbau.
SETUP ACKNOWLEDGE signalisiert, dass weitere Informationen für den Verbindungsaufbau
benötigt werden.
Verbindungsauslösung
DISCONNECT bewirkt die Auslösung einer Verbindung.
RELEASE signalisiert, dass der sendende Endpunkt alle Kanäle freigegeben hat.
RELEASE COMPLETE ist die Antwort auf eine RELEASE-Nachricht und zeigt an, dass die
Kanäle auf der anderen Seite ebenfalls wieder frei sind.
Nachrichten der Informationsphase
RESUME nimmt eine Verbindung wieder auf, die mit SUSPEND in einen Ruhezustand
versetzt wurde.
RESUME ACKNOWLEDGE zeigt an, dass die Verbindungsaufnahme erfolgreich war.
RESUME REJECT signalisiert, dass die Verbindungsaufnahme nicht erfolgreich war.
SUSPEND beantragt einen Ruhezustand für eine laufende Verbindung (in der Zwischenzeit
kann das Endgerät mit einem anderen Netzwerkanschluss verbunden werden [SIEMENS]).
78
SUSPEND ACKNOWLEDGE signalisiert, dass der Ruhezustand akzeptiert wurde.
SUSPEND REJECT zeigt an, dass der Ruhezustand nicht akzeptiert wurde.
USER INFORMATION ermöglicht es einem Benutzer Informationen an einen entfernten
Benutzer zu senden.
andere Nachrichten
CONGESTION CONTROL informiert darüber, dass eine Flusssteuerung für USER
INFORMATION Nachrichten zum Einsatz kommt oder dass diese beendet wurde.
INFORMATION ermöglicht es einem Benutzer Informationen an das Netz zu senden, z.B. für
einen Verbindungsaufbau.
NOTIFY enthält Informationen zu einer laufenden Verbindung.
SEGMENT zeigt an, dass die Nachricht Teil eines größeren Ganzen ist.
STATUS berichtet Fehlerfälle.
STATUS ENQUIRY veranlasst einen Statusbericht.
Die Empfehlung [H.225 S.16] erlaubt die Verwendung der Nachrichten ALERTING, CALL
PROCEEDING, CONNECT, PROGRESS, SETUP, SETUP ACKNOWEDGE, RELEASE COMPLETE,
USER INFORMATION, INFORMATION, NOTIFY, STATUS und STATUS ENQUIRY.
B.3 Q.932 Signalisierungsnachrichten
Zusatzdienste
FACILITY beantragt oder bestätigt einen Zusatzdienst während einer laufenden Verbindung.
HOLD beantragt einen Ruhezustand für eine laufende Verbindung, so dass der belegte Kanal
frei wird.
HOLD ACKNOWLEDGE signalisiert, dass ein Ruhezustand akzeptiert wurde.
HOLD REJECT zeigt an, dass ein Ruhezustand nicht akzeptiert wurde.
REGISTER stellt eine Verbindung zwischen einem Endgerät und dem Netzwerk her.
RETRIEVE nimmt eine Verbindung wieder auf, die mit HOLD in einen Ruhezustand versetzt
wurde.
RETRIEVE ACKNOWLEDGE zeigt an, dass eine Verbindungsaufnahme erfolgreich war.
RETRIEVE REJECT signalisiert, dass eine Verbindungsaufnahme nicht erfolgreich. war.
Die Empfehlung [H.225 S.16] erlaubt ausschließlich die Verwendung der Nachricht FACILITY.
79
B.4 H.225 Informationselemente
Die Empfehlung [H.225] definiert eine Reihe von Informationselementen, die mit Q.931- und
Q.932-Nachrichten versendet werden können.
Protocol Discriminator identifiziert den Protokolltyp. (08H für Q.931-Nachrichten)
Call Reference identifiziert einen Anruf. Der Wert ist auf einem Signalisierungskanal
zwischen jeweils zwei Teilnehmern eindeutig.
Message Type identifiziert die übertragene Nachricht (siehe B.2 und B.3)
Bearer Capability beschreibt die Fähigkeiten des Trägerdienstes (Sprache vs. Daten,
synchrone vs. asynchrone und Halbduplex- vs. Vollduplex-Übertragung, Leitungsvermittlung
vs. Paketvermittlung, die verwendete Datenrate, die Existenz eines Signalisierungskanals,
Flusskontrolle usw.). Dies ist nur für Verbindungen in leitungsvermittelnde Netzwerke
relevant.
Call Identity identifiziert einen Anruf. Die Kennung ist zwischen allen Teilnehmern eindeutig.
Call State gibt den aktuellen Status einer Verbindung an (Anruf initiiert, Aktiv usw.).
Called/Calling Party Number enthalten die Telefonnummer des angerufenen/anrufenden
Teilnehmers. Hier kann auch auf ein Alias innerhalb des User-User-Information-Elements
verwiesen werden.
Called/Calling Party Subaddress identifizieren ein Gerät außerhalb eines öffentlichen Netzes.
Cause gibt den Grund einer Nachricht an (keine Bandbreite, keine Erlaubnis usw.).
Connected Number/Subaddress identifizieren das aktuell verbundene Gerät
Display enthält bis zu 82 Zeichen langen IA5 kodierten Text, der einem Benutzer angezeigt
werden kann.
Facility ist das Informationselement der gleichnamigen Nachricht und wird verwendet, wenn
ein Anruf umgeleitet werden soll oder Zusatzdienste zum Einsatz kommen.
Notification Indicator informiert darüber, wenn ein Gerät in Wartestellung versetzt wurde,
wenn ein Anruf fortgesetzt wird oder sich die Trägerdienste ändern.
Progress Indicator beschreibt ein aufgetretenes Ereignis bei einer Verbindung mit ISDNoder ATM-basierten Endpunkten (z.B. das Ziel liegt nicht im ISDN oder Informationen sind
im Mediendatenstrom verfügbar (in-band)).
Redirecting Number identifiziert das Gerät, von dem eine Umleitung initiiert wurde. Dies
wird nur für die Zusammenarbeit mit leitungsvermittelnden Netzwerken zur Verfügung
gestellt.
Sending Complete informiert darüber, dass ein gewählte Rufnummer vollständig ist.
Signal steuert die akustische Signalisierung eines Gerätes (Wählton, Besetztzeichen,
Klingeln usw.).
User-User tunnelt andere Signalisierungsnachrichten und H.245-Kanäle und überträgt
80
Daten für H.450.1-Zusatzdienste.
B.5 H.245 Nachrichten zur Steuerung multimedialer Kommunikation
Anfragen (Requests)
Master Slave Determination enthält eine Zufallszahl, die zwischen den Rollen Master und
Slave entscheidet. Der Endpunkt, der die größte Zahl sendet ist Master. Bei zwei gleichen
Zahlen kann die Anfrage abgelehnt werden.
Terminal Capability Set enthält eine Menge an Empfangs- und Sendefähigkeiten, die vom
sendenden Terminal unterstützt werden.
Open Logical Channel öffnet einen uni- oder bidirektionalen logischen Kanal.
Close Logical Channel schließt einen uni- oder bidirektionalen logischen Kanal. Diese
Anfrage kann nicht abgelehnt werden.
Request Channel Close beantragt das Schließen eines logischen Kanals.
Multiplex Entry Send überträgt H.223 Multiplex Tabelleneinträge. (Diese spezifizieren ein
Multiplexingmuster für übertragene Daten.)
Request Multiple Entry beantragt die Übertragung von H.223 Multiplex Tabelleneinträgen.
Request Mode beantragt eine Liste mit Audio-, Video-, Daten- und Verschlüsselungsmodi,
die von einem Terminal unterstützt werden.
Round Trip Delay Request beantragt die Zustellung von Paketumlaufzeiten zwischen zwei
Terminals.
Maintenance Loop Request beantragt ein Loop Back von logischen Kanälen.
Communication Mode Request erfragt den aktuellen Kommunikationsmodus (unicast,
multicast) einer Konferenz.
Conference Request ermöglicht verschiedene Anfragen innerhalb einer Konferenz gemäß der
ITU-T Empfehlung H.230. Mit diesen kann z.B. eine Liste aller Terminals beantragt oder die
Leitung einer Konferenz übernommen werden.
Multilink Request unterstützt einen Wechsel der physikalischen Verbindung.
Logical Channel Rate Request beantragt eine Änderung der Datenrate.
Je nach Anfrage existieren bestätigende (Acknowledge), ablehnende (Negative Acknowledge)
und spezielle Antworten. Es gibt außerdem Indikatoren zur Timeout-Signalisierung.
Befehle (Command Messages)
Maintenance Loop Off Command löst die Verbindung aller Loop Back Kanäle.
Send Terminal Capability Set veranlasst den Empfänger seine Empfangs- und
Sendefähigkeiten zuzusenden.
81
Encryption Command übermittelt Verschlüsselungsfähigkeiten und einen
Initialisierungsvektor.
Flow Control Command legt die obere Datenrate für logische Kanäle fest.
End Session Command signalisiert das Ende einer H.245 Sitzung.
Miscellaneous Command unterstützt verschiedene Befehle, die in weiteren ITU-T
Empfehlungen, wie H.221 und H.230 beschrieben werden. Dazu gehört z.B. die Steuerung
eines Videoencoders oder der Austausch von Verschlüsselungsinformationen.
Communication Mode Command spezifiziert den Kommunikationsmodus (unicast, multicast)
für jeden Medientyp.
Conference Command übermittelt H.230 konforme Konferenzbefehle.
H.223 Multiplex Reconfiguration ändert den Level des Multiplexmodes. (siehe Empfehlung
H.223)
New ATMVC Command lässt den Empfänger einen ATM virtual channel öffnen.
Mobile Multilink Reconfiguration Command ändert die Konfiguration eines Multilinkrahmens.
Indikatoren (Indications)
Open Logical Channel Confirm bestätigt bei einem eingehenden bidirektionalen Kanal, dass
der Rückkanal ebenfalls geöffnet wurde
Miscellaneous Indication wird für verschiedene Indikatoren verwendet, die in weiteren ITU-T
Empfehlungen, wie H.221 und H.230 beschrieben werden.
Jitter Indication überträgt Jitterinformationen.
H.223 Skew Indication gibt Auskunft über die Zeitverschiebung zweier gemeinsam
übertragener (multiplex) Kanäle. Ein Skew beinhaltet unterschiedliche Samplezeiten,
Kodierungszeiten und Verzögerungen durch den Sendebuffer.
New ATMVC Indication überträgt Parameter für einen ATM virtual channel.
User Input überträgt Benutzernachrichten.
H.2250 Maximum Skew Indication gibt Auskunft über die maximale Zeitverschiebung zweier
gemeinsam übertragener (multiplex) Kanäle.
MC Location Indication wird von einem Multipoint Controller an Terminals versendet und
enthält die Signalisierungsadresse mit der dieser erreicht werden kann.
Conference Indication übermittelt H.230 konforme Konferenzbefehle.
Vendor Identification enthält Informationen über den Hersteller eines Gerätes.
Function Not Supported wird zurückgegeben wenn eine Anfrage, Antwort oder ein Befehl
nicht verstanden wurde.
Mobile Multilink Reconfiguration Indication signalisiert, dass die Samplegröße oder die
Anzahl der Samples pro Rahmen geändert wird.
82
Flow Control Indication informiert ein Terminal darüber, dass die ausgehende Bandbreite im
Rahmen der Flusssteuerung angepasst wurde.
Es gibt Nachrichten, die als Anfrage, Antwort, Befehl oder Indikator verwendet werden:
Non Standard enthält Fähigkeiten und Steuerungsnachrichten die nicht im Standard
enthalten sind.
Generic Message erlaubt die Spezifikation neuer Nachrichten, ohne dass die H.245 Syntax
geändert werden muss.
B.6 T.125 Nachrichten des Multipoint Communication Service
Anfragen (Requests)
Connect Provider verbindet ein MCS Provider mit einer Domäne. Dazu werden
Informationen über die Domänenhierarchie versendet.
Disconnect Provider wird verwendet, wenn ein Provider eine Domäne verlässt.
Attach User verbindet eine Anwendung mit einer Domäne. Im Gegensatz zu einer ConnectProvider-Anfrage enthält sie keine Informationen über die Domänenhierarchie.
Detach User wird verwendet, wenn eine Anwendung eine Domäne verlässt.
Channel Join abonniert einen Kanal, um auf diesem senden und empfangen zu können.
Channel Leave hebt ein Kanal-Abonnement auf.
Channel Convene erlaubt es einem Provider, die Steuerung eines privaten Kanals zu
übernehmen.
Channel Admit lädt einen Provider ein, einem privaten Kanal beizutreten.
Channel Expel entfernt einen Provider von einem privaten Kanal.
Channel Disband unterbricht einen privaten Kanal.
Send Data ermöglicht eine ein-zu-viele Kommunikation.
Uniformly Sequenced Data Transfer wird über die Wurzel einer Domäne geroutet, um
Anfragen in der richtigen Reihenfolge an die Empfänger weiterzuleiten.
Token Grab beantragt exklusiven Zugriff auf eine anwendungsspezifische Ressource.
Token Test fragt den Status eines Tokens ab.
Token Please beantragt ein Token vom aktuellen Eigentümer.
Token Give transferiert ein beantragtes Token an einen neuen Eigentümer.
Token Release gibt ein Token in einen allgemeinen Status frei.
83
Token Inhibit belegt ein Token mit einer Sperre. Bei einer parallelen Verarbeitung kann
damit z.B. ein Token von allen beteiligten Providern gesperrt werden. Nach der Verarbeitung
wird die Sperre wieder entfernt, so dass ein freies Token signalisiert, dass die Verarbeitung
abgeschlossen wurde.
Für die beschriebenen Anfragen existieren ggf. positive und negative Antworten sowie
zusätzliche Indikatoren.
B.7 T.124 Nachrichten der Generic Conference Control
Anfragen (Requests)
Conference Create erstellt eine neue Konferenz.
Conference Query beantragt Informationen über laufende Konferenzen.
Conference Join wird verwendet, um einer existierenden Konferenz beizutreten.
Conference Invite übermittelt Einladungen, mit denen an einer Konferenz teilgenommen
werden kann.
Conference Add erlaubt es dem Leiter einer Konferenz, bei einem Benutzer anzufragen, ob
dieser teilnehmen möchte.
Conference Lock wird von dem Leiter einer Konferenz gesendet, um weitere Teilnehmer
auszuschließen.
Conference Unlock wird vom Leiter einer Konferenz gesendet, um zuvor ausgeschlossene
Teilnehmer wieder zuzulassen.
Conference Disconnect beendet eine Verbindung mit einer Konferenz.
Conference Terminate ermöglicht es dem Leiter einer Konferenz, diese aufzulösen.
Conference Eject User kann vom Leiter einer Konferenz gestellt werden, um die Verbindung
mit einem Teilnehmer zu beenden.
Conference Transfer gibt dem Leiter einer Konferenz die Möglichkeit bestimmte Teilnehmer
einer Konferenz in eine andere zu überführen. Die Anfrage kann verwendet werden, um
Konferenzen zusammenzuführen oder um diese zu teilen.
Conference Announce Presence teilt die Anwesenheit eines Teilnehmers in einer Konferenz
mit.
Conference Roster Inquire beantragt eine Zustellung der aktuellen Konferenzliste.
Application Enroll meldet eine Anwendung bei einer Konferenz an oder ab. Diese Anfrage
erstellt, verändert oder entfernt einen entsprechenden Eintrag innerhalb der
Anwendungsliste.
Application Roster Inquire beantragt eine Zustellung von Einträgen der Anwendungsliste.
Application Invoke signalisiert anderen Provider, dass diese eine Anwendung ausführen
84
sollen.
Registry Register Channel registriert die Kennung eines dynamischen MCS-Kanals
Registry Assign Token allokiert ein Token und registriert dessen Kennung.
Registry Set Parameter Channel setzt einen Wert in der Registrierungsdatenbank.
Registry Retrieve Entry erfragt den Wert eines Eintrags aus der Registrierungsdatenbank.
Registry Delete Entry entfernt einen Eintrag aus der Registrierungsdatenbank.
Registry Registry Monitor schaltet die Überwachung eines Registrierungsdatenbankeintrags
ein oder aus. Bei einer Veränderung kann so ein entsprechender Indikator gesendet werden.
Registry Registry Allocate Handle erzeugt ein Handle, dass innerhalb einer Konferenz nur
einmal vorkommt.
Conductor Assign beantragt die Leitung einer Konferenz.
Conductor Release gibt die Leitung einer Konferenz frei.
Conductor Please beantragt die Leitung einer Konferenz vom aktuellen Leiter.
Conductor Give übergibt die Leitung einer Konferenz an einen anderen Teilnehmer.
Conductor Inquire erfragt, ob eine Konferenz einer Leitung untersteht.
Conductor Permission Ask beantragt beim Leiter einer Konferenz, dass eine Anwendung eine
genehmigungspflichtige Aktion durchführen darf.
Conductor Permission Grant informiert darüber, welche Teilnehmer eine
genehmigungspflichtige Aktion durchführen dürfen.
Conference Time Remaining überträgt die Zeit, zu der eine Konferenz beendet werden soll
Conference Time Inquire erfragt die Zeit, zu der eine Konferenz beendet werden soll
Conference Extend beantragt die Verlängerung einer Konferenz.
Conference Assistance beantragt eine unspezifizierte Unterstützung vom Operator einer
Konferenz
Text Message überträgt Textinformationen zwischen Providern
Analog zu Anhang B.5 existieren für die beschriebenen Anfragen ggf. positive und negative
Antworten sowie zusätzliche Indikatoren.
B.8 H.239 Nachrichten zum Aufbau eines privilegierten Videokanals
h239ControlCapability signalisiert, dass ein Gerät H.239 sowie Flusssteuerungsnachrichten
unterstützt.
h239ExtendedVideoCapabilities enthält die unterstützten Rollen für einen Kanal.
flowControlReleaseRequest wird gesendet, wenn ein neuer Kanal zu einer MCU eingerichtet
85
oder die Bandbreite eines Kanals erhöht werden soll.
flowControlReleaseResponse lehnt eine Flusssteuerungsanfrage ab oder bestätigt, dass
diese bearbeitet wird. Die Bandbreitenbeschränkungen selbst werden in separaten
Nachrichten aufgehoben.
presentationTokenRequest fragt das Token an, das mit der Präsentationsrolle assoziiert ist.
presentationTokenResponse ist ein positive oder Negative Antwort auf eine Tokenanfrage.
presentationTokenRelease gibt das Präsentationstoken auf.
presentationTokenIndicateOwner signalisiert, dass ein Gerät das Präsentations-Token
besitzt.
86
Anhang C - SIP-Signalisierungsnachrichten
Das SIP ist ein textbasiertes Protokoll und verwendet den UTF-8 Zeichensatz. Die Nachrichten
sind in der erweiterten Backus-Naur-Form definiert:
allgemeine-Nachricht = Startzeile *Kopf CRLF [Rumpf]
Startzeile = Anfrage-Zeile / Status-Zeile
Anfrage-Zeile = Methode SP Anfrage-URI SIP-Version CRLF
Status-Zeile = SIP-Version SP Status-Code SP Begründungstext CRLF
Kopf = Header-Bezeichner HCOLON Header-Wert *(COMMA Header-Wert)
SP = Leerzeichen
CRLF = Zeilenumbruch
HCOLON = ":"
COMMA = ","
/ = oder
* = der nachfolgende Teil ist optional und kann wiederholt werden
() = eine vorhergehende Operation wird auf den eingeklammerten Teil angewendet
[] = der eingeklammerte Teil ist optional
Der Rumpf einer Nachricht wird in den Header-Feldern beschrieben und enthält z.B. SDPInformationen. Die SIP-Version wird analog zum HTTP angegeben. SIP-Nachrichten gemäß RFC
3261 werden mit der Zeichenkette "SIP/2.0" gekennzeichnet. [RFC 3261 S.25-34]
C.1 Adressierung
Eine SIP-URI identifiziert einen Teilnehmer und kann bereits eine eigenständige Anfrage
enthalten. Die allgemeine Form lässt sich wie folgt zusammenfassen:
SIP:Benutzer:Passwort@Host:Port;URI-Parameter?Header-Felder
Kommen in einem URI-Teil Steuerzeichen zum Einsatz, müssen diese durch das "%"-Zeichen
als normales Datum markiert werden. Bei der Benutzerkennung dürfen jedoch einige
Steuerzeichen auch ohne Fluchtzeichen verwendet werden.
Die einzelnen URI-Teile haben folgende Bedeutung:
Benutzer ist die Benutzerkennung bei einem Host. Dabei kann es sich um eine
Telefonnummer oder einen Benutzernamen handeln.
Passwort enthält ein Passwort zur Benutzerkennung
87
Host wird durch einen Domänennamen oder eine IP-Adresse identifiziert.
Port ist eine Portnummer, an die eine Anfrage gesendet werden kann. Der Standardport für
SIP ist 5060 und für sichere SIPS 5061.
C.2 URI-Parameter
URI-Parameter beeinflussen Anfragen, die aus einer URI gebildet werden. Sie bestehen aus
"Bezeichner=Wert"-Paaren, die jeweils durch ein Semikolon getrennt sind. Dabei können
folgende Bezeichner verwendet werden:
Transport definiert das zu verwendende Transportprotokoll. Das Standardprotokoll ist bei
SIP UDP und bei SIPS TCP.
Maddr gibt die Adresse eines Servers (z.B. eines Proxies) an, der für den Verbindungsaufbau
mit einem Benutzer kontaktiert werden soll.
TTL gibt die Gültigkeitsdauer eines UDP-Pakets an, wenn dieses an eine Multicastadresse
gesendet wird.
User wird verwendet um Telefonnummern und Benutzernamen auseinanderzuhalten. Bei
einer Telefonnummer sollte als Wert "phone" angegeben werden.
Method gibt eine SIP-Methode an. Als Vorgabewert wird die Methode INVITE verwendet
(siehe dazu auch den Abschnitt "Methoden").
LR wird aus Kompatibilitätsgründen zum RFC 2543 verwendet. Dieses signalisiert, dass ein
Gerät Loose-Source-Routing betreibt. Fehlt der Parameter wird Strict-Source-Routing
betrieben.
C.3 Header-Felder
Innerhalb einer SIP-URI können Header-Felder für Anfragen vorgegeben werden. Sie werden
hier durch ein "?"-Zeichen eingeleitet und enthalten durch "&"-Zeichen separierte "Bezeichner
=Werteliste"-Paare. Der Bezeichner "body" gibt an, dass es sich bei der Werteliste um den
Rumpf einer Anfrage handelt. Es werden nun einige wichtige Header-Felder aufgeführt:
Call-ID ist eine eindeutige Kennung mit der mehrere Nachrichten eines Dialogs
zusammengefasst werden.
Contact gibt einen SIP- oder SIPS-URI an, über den ein Ziel erreicht werden kann.
Content-Type beschreibt den Inhalt des Nachrichtenrumpfes mit einem MIME-Type.
Content-Length gibt die Länge des Rumpfes in Bytes an.
CSeq enthält die 32-Bit-Sequenznummer einer Anfrage und deren Methode.
From gibt den Absender einer Anfrage an. Es können SIP-, SIPS- und ggf. andere URIs
verwendet werden.
88
Max-Forwards ist die maximale Anzahl der Zwischenstationen (Hops), die eine Nachricht
passieren darf.
To gibt den Empfänger einer Anfrage an. Wie beim Absender können SIP-, SIPS- und ggf.
andere URIs verwendet werden.
Record-Route enthält die Adresse eines Proxies. Das Feld wird bei der Übertragung einer
Anfrage von jedem durchlaufenen Proxy eingefügt, die Teil des Pfades bleiben will. Der so
aufgezeichnete Pfad wird in eine Antwort kopiert, sodass zukünftige Anfragen der Sitzung
diesen verwenden können.
Route gibt eine Route von Proxies vor, die eine Anfrage durchlaufen soll.
Via wird bei der Übertragung einer Anfrage von jeder durchlaufenen Zwischenstation
eingefügt und repräsentiert zusammen mit anderen Via-Feldern die verwendete Route. Die
Route sollte dann für Antworten in umgekehrter Reihenfolge ebenfalls verwendet werden,
wobei die eigenen Via-Einträge von der jeweiligen Zwischenstation wieder entfernt werden.
Neben Kontaktinformationen in Form eines URI oder einer IP-Adresse mit Portnummer
werden ebenfalls die verwendete SIP-Version und das Transportprotokoll angegeben. Der
Parameter "Received" gibt an, über welche Schnittstelle eine Nachricht eingegangen ist. Ein
sogenannter Branch-Parameter identifiziert zudem eine Übertragung und hilft einem Proxy
Schleifen zu erkennen. Optional können hier auch weitere URI-Parameter angegeben
werden.
[RFC 3261 S.147-182]
C.4 Methoden
Mit SIP-Nachrichten können verschiedene Anfragen gestellt werden:
INVITE lädt einen Benutzer oder einen Dienst ein, an einer Sitzung teilzunehmen. Im Rumpf
der Nachricht ist eine Sitzungsbeschreibung enthalten, mit der alle notwendigen
Sitzungsparameter vorgegeben werden. Durch das Senden weiterer INVITE-Nachrichten
während einer Sitzung ist es auch möglich die Rahmenbedingungen im Nachhinein zu
verändern.
ACK wird gesendet, wenn ein Gerät eine endgültige Antwort zu einer INVITE-Anfrage
erhalten hat.
OPTIONS erfragt die Fähigkeiten eines Gerätes. Die Antwort enthält die unterstützten
Methoden, Inhalte (z.B. SDP) und Codecs. Der Status der Antwort wird wie bei einer
INVITE-Anfrage gesetzt.
CANCEL bricht eine gestellte Anfrage ab. Die Methode kann z.B. von einem Proxy verwendet
werden, wenn dieser zu einer parallelen Anfrage bereits Erfolgs- oder globale
Fehlermeldungen erhalten hat.
BYE beendet eine Sitzung.
89
REGISTER registriert die Adresse im To-Header-Feld bei einem Registrar.
[RFC 2543 S.27-34]
In gesonderten Dokumenten werden weitere Methoden spezifiziert:
INFO überträgt anwendungsspezifische Steuerungsinformationen, die während einer Sitzung
erzeugt werden. Das können Ziffern sein, die mit einem VoIP-Telefon eingegeben werden
oder auch Abrechnungsinformationen. (RFC 2976)
PRACK Bestätigung für vorläufige 1xx-Antworten (RFC 3262).
SUBSCRIBE Abonniert Benachrichtigungen (NOTIFY) für eine gegebene Zeit (RFC 3265).
NOTIFY überträgt Zustandsinformationen (RFC 3265). Dabei kann es sich z.B. um die
Anwesenheit befreundeter Teilnehmer (buddy list) handeln. Es können ebenfalls neue
Nachrichten in der Mailbox signalisiert oder Rückrufdienste realisiert werden.
MESSAGE überträgt eine Instant Message in Form eines MIME-Rumpfes (RFC 3428).
[SCHULZRINNE]
UPDATE aktualisiert die Parameter einer Sitzung. Im Unterschied zur INVITE-Methode wird
der Zustand der SIP-Kommunikation aber nicht beeinflusst. So kann eine Sitzung
aktualisiert werden, bevor die initiierende INVITE-Nachricht beantwortet wurde. [RFC 3311]
REFER beantragt, dass der Empfänger eine Verbindung mit einer dritten Partei aufbaut. Der
Sender wird mit einer NOTIFY-Anfrage über das Ergebnis der ursprünglichen Anfrage
informiert. Auf diese Weise ist z.B. eine Anrufweiterleitung möglich. [RFC 3515].
C.5 Status-Codes
Die in einer Antwort zurückgegebenen Status-Codes werden in unterschiedliche Gruppen
unterteilt:
1xx enthält vorläufige Antworten, weil eine zugehörige Anfrage noch bearbeitet wird.
2xx meldet das eine Aktion verstanden, akzeptiert oder erfolgreich ausgeführt wurde.
3xx signalisiert, dass der Client eine Anfrage an einen anderen Server stellen muss. Dies ist
z.B. der Fall, wenn ein Benutzer nicht mehr über eine Adresse erreichbar ist.
4xx informiert darüber, dass eine Anfrage von einem Server nicht bearbeitet werden kann.
Diese Antwort wird z.B. versendet, wenn die Syntax einer Anfrage fehlerhaft ist oder der
Client sich nicht autorisieren kann.
5xx weist auf einem Fehler beim Server hin, wenn dieser eine offensichtlich zulässige
Anfrage nicht bearbeiten kann.
6xx signalisiert, dass eine Anfrage bei keinem Server bearbeitet werden kann. Diese nennt
man auch globale Fehler.
90
[RFC 3261 S.29]
C.6 Beispiele
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
Abbildung 11: SIP-Anfrage INVITE (aus [RFC 3261 S.214])
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
Abbildung 12: SIP-Antwort (aus [RFC 3261 S.215])
91
92
Anhang D - Sitzungsbeschreibung mit dem SDP
Das SDP beschreibt multimediale Sitzungen mit Hilfe textueller Wertezuweisungen. Im RFC
wird dazu die Verwendung der UTF-8-Kodierung empfohlen. Für Werte dürfen im Rahmen einer
Internationalisierung aber auch andere Zeichensätze verwendet werden.
Sitzungsbeschreibung
v= Protokoll Version
o= Eigentümer und Sitzungskennung
s= Sitzungsname
i= Sitzungsinformationen (opt.)
u= URI zu weiteren Informationen (opt.)
e= E-Mail-Adresse (opt.)
p= Telefonnummer (opt.)
c= Verbindungsinformationen (diese werden nicht benötigt, wenn sie in den
Medieninformationen vorhanden sind)
b= Bandbreiteninformationen (opt.)
z= Zeitzonenanpassung (opt.)
k= kryptografischer Schlüssel (opt.)
a= keine oder mehr Zeilen mit Sitzungsattributen (opt.)
Zeitliche Beschreibung
t= zeitlicher Rahmen der Sitzung
r= keine oder mehr Wiederholungszeiträume (opt.)
Medienbeschreibung
m= Medienbezeichner und Transportadresse
i= Medientitel (opt.)
c= Verbindungsinformationen (optional, wenn diese bereits in der Sitzungsbeschreibung
enthalten sind)
b= Bandbreiteninformationen (opt.)
[RFC 4566 S.9]
93
Anhang D - Sitzungsbeschreibung mit dem SDP
D.1 Beispiel
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
[email protected] (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Abbildung 13: SDP-Sitzungsbeschreibung (aus [RFC 4566 S.10])
94
Anhang E - Ankündigen einer Sitzung mit dem SAP
Mit Hilfe des SAP werden Informationen zu Sitzungen innerhalb einer Multicast-Umgebung
angekündigt. Dazu werden Sitzungsbeschreibungen als Nutzdaten im folgenden Paket
versendet.
Abbildung 14: SAP-Paket-Format
Paket-Felder
v= Version
a= Adresstyp: 0=IPv4, 1=IPv6
r= Reserved
t= Nachrichtentyp: 0=Session Announcement Paket, 1=Session Deletion Paket
e= Verschlüsselung
c= Kompression
Authentifizierungslänge: die Anzahl der 32-Bit-Worte, die dem Header folgen und als digitale
Signatur interpretiert werden müssen
Nachrichten-Hash-Kennung: die eindeutige Kennung einer Ankündigung
Quelle: die IP-Adresse des Endpunktes, der die Ankündigung in Auftrag gegeben hat
optionaler Nutzdatentyp: ein MIME-Typ
95
Anhang E - Ankündigen einer Sitzung mit dem SAP
Felder der optionalen digitalen Signatur
v= Version
p= die digitale Signatur ist mit Padding-Bits auf ein Vielfaches von 32-Bit erweitert worden
Authentifizierungsverfahren: 0=PGP (Pretty Good Privacy), 1=CMS (Cryptographic Message
Syntax)
96
Anhang F - RTP/RTCP-Header-Informationen
Abbildung 15: RTP-Header [RFC 3550 S.12-21]
v= Version
p= Es sind Padding-Bytes vorhanden, die nicht Teil der Nutzdaten sind. Dies ist für
Verschlüsselungsalgorithmen relevant, die eine feste Blocklänge benötigen.
x= Dem Header folgt eine Erweiterung.
cc= Anzahl der contributing sources (0..15)
m= Die Interpretation des Markierungsbits wird von einem Profil definiert. Das Bit kann z.B.
genutzt werden, um die Rahmengrenzen eines Paketstroms zu markieren.
pt= Nutzdatentyp: Die Standardkennungen werden im RFC 3551 definiert.
Sequenznummer: Eine Sequenznummer wird mit einem zufälligen Wert initialisiert und mit
jedem gesendeten Paket um eins erhöht. Auf diese Weise können Paketverluste erkannt und
die Reihenfolge eintreffender Pakete wiederhergestellt werden.
Zeitstempel: Ein Zeitstempel verknüpft das erste Nutzdatenbyte mit einer monoton
steigenden Zeiteinheit. Er wird mit einem zufälligen Wert initialisiert und besitzt eine auf die
Nutzdaten angepasste Taktrate. Seine Aufgabe besteht im Ausgleich von
Laufzeitschwankungen und in der Synchronisation unterschiedlicher Datenströme. Um diese
miteinander abgleichen zu können, werden Zeitstempel regelmäßig via RTCP mit
hochauflösenden Referenzzeiten verknüpft.
Synchronization Source ID: Die Kennung des RTP-Teilnehmers, von dem das Paket ausgeht.
Contributing Source IDs: Die Kennungen der Teilnehmer, die zum Inhalt eines Datenstroms
beitragen. Dies ist für Ströme relevant, die von einem Mixer generiert werden.
97
RTCP-Informationen werden in Form von Verbundpaketen gesendet. Sie können
Senderinformationen, Empfangsreporte, eine Signalisierung zum Beenden einer Sitzung sowie
anwendungsspezifische Informationen enthalten. Jedes RTCP-Paket muss darüber hinaus
mindestens eine Teilnehmerbeschreibung enthalten, die die Kennung eines RTP-Teilnehmers
mit einem eindeutigen Bezeichner verbindet. Es wird empfohlen, etwa 5% der
Sitzungsbandbreite für RTCP-Informationen zu verwenden. Ein Viertel dieser Bandbreite sollte
wiederum für sendende Teilnehmer zur Verfügung stehen.
Abbildung 16: RTCP-Header + Senderinformationen + Empfangsreporte [RFC 3550 S.21-45]
98
rc= Anzahl der Reporte, die im Verbundpaket enthalten sind
pt= Nutzdatentyp: 200=Sendereport, 201=Empfangsreport, 202=Senderbeschreibung,
203=BYE-Paket zum Beenden einer Sitzung
optionaler Zufallswert: Dieser ist für verschlüsselte Pakete relevant.
NTP-Zeitstempel: hochauflösender Zeitwert
RTP-Zeitstempel: der mit dem hochauflösenden Zeitwert verknüpfte RTP-Zeitstempel
höchste empfangene Sequenznummer: Hier werden ebenfalls die Werteüberläufe gezählt.
Die Teilnehmerbeschreibung dient zur Assoziation von Attributen mit der Kennung (SSRC)
eines Senders. Ein besonderes Attribut stellt der eindeutige Bezeichner (CNAME) dar, der in
jedem RTCP-Paket enthalten ist, um den Teilnehmer von dem das Paket ausgeht
stromübergreifend zu identifizieren. Dies ist z.B. bei einem Neustart eines RTP-Stroms
relevant, wenn die Kennung (SSRC) eines Senders geändert wird. Der eindeutige Bezeichner
wird außerdem von Empfängern benötigt, um verschiedene Ströme eines Senders miteinander
zu assoziieren, sodass diese synchronisiert werden können.
Abbildung 17: Teilnehmerbeschreibung [RFC 3550 S.45-51]
sc= Anzahl der Quellen, die in der Teilnehmerbeschreibung beschrieben werden
SDES items: der eindeutiger Bezeichner eines Teilnehmers (CNAME), eine E-Mail-Adresse,
eine Telefonnummer, o.ä.
99
F.1 Nutzdatentypen
pt
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
dyn
dyn
dyn
dyn
dyn
dyn
dyn
dyn
dyn
dyn
24
25
26
27
28
29
30
31
32
33
34
dyn
35-71
72-76
77-95
96-127
Bezeichner
PCMU
reserviert
reserviert
GSM
G723
DVI4
DVI4
LPC
PCMA
G722
L16
L16
QCELP
CN
MPA
G728
DVI4
DVI4
G729
reserviert
unzugewiesen
unzugewiesen
unzugewiesen
unzugewiesen
G726-40
G726-32
G726-24
G726-16
G729D
G729E
GSM-EFR
L8
RED
VDVI
unzugewiesen
CelB
JPEG
unzugewiesen
nv
unzugewiesen
unzugewiesen
H261
MPV
MP2T
H263
H263-1998
unzugewiesen
reserviert
unzugewiesen
dynamisch
Medientyp
Taktrate (Hz)
A
8.000
A
A
A
8.000
A
8.000
A
8.000
A
16.000
A
8.000
A
8.000
A
8.000
A
44.100
A
44.100
A
8.000
A
8.000
A
90.000
A
8.000
A
11.025
A
22.050
A
8.000
A
A
A
A
A
A
8.000
A
8.000
A
8.000
A
8.000
A
8.000
A
8.000
A
8.000
A
variabel
A
A
variabel
V
V
90.000
V
90.000
V
V
90.000
V
V
V
90.000
V
90.000
AV
90.000
V
90.000
V
90.000
?
nicht verfügbar
?
?
Kanäle
1
1
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
variabel
1
Abbildung 18: Nutzdatentypen (aus [RFC 3551 S.33-34])
100
Anhang G - Megaco
G.1 Befehle
Ein Media Gateway enthält Terminierungen, die mit Befehlen gesteuert werden können:
Add fügt eine Terminierung zu einem Kontext hinzu. Existiert der Kontext noch nicht, so
wird dieser generiert.
Modify ändert die Eigenschaften, Ereignisse und Signale einer Terminierung.
Subtract entfernt eine Terminierung von einem Kontext und gibt eine Statistik über die
Teilnahme in diesem Kontext zurück. Handelt es sich bei der Terminierung um die letzte im
Kontext, so wird dieser ebenfalls entfernt.
Move ändert den Kontext einer Terminierung.
AuditValue gibt den aktuellen Zustand der Eigenschaften, Ereignisse, Signale und Statistiken
einer Terminierung zurück.
AuditCapabilities gibt alle Werte für die Eigenschaften, Ereignisse und Signale einer
Terminierung zurück, die ein MG erlaubt.
Notify erlaubt es ein MGC über das Auftreten von Ereignissen im MG zu informieren.
ServiceChange ermöglicht verschiedene Dienständerungen. So kann ein MG mitteilen, dass
Terminierungen außer Dienst gestellt werden bzw. dass diese ihren Dienst wieder
aufgenommen haben. Die Nachricht wird auch verwendet, um einem MGC mitzuteilen, dass
ein MG für diesen verfügbar ist oder dass ein vollständiger Neustart bevorsteht. Ein MGC
kann außerdem eine Übergabe (Handover) an einen anderen MGC ankündigen oder ein MG
veranlassen Terminierungen außer Dienst zu stellen.
[RFC 3525 S.26-27]
Sequenzen von Befehlen werden zu Aktionen zusammengefasst, die innerhalb eines Kontextes
nacheinander ausgeführt werden. Innerhalb einer Transaktion können mehrere Aktionen
übertragen werden. Verschiedene Transaktionen können wiederum in einer Nachricht
zusammengefasst werden:
101
Anhang G - Megaco
Transaktionsanfrage(Transaktionskennung {
Kontextkennung {Befehl ... Befehl},
. . .
Kontextkennung {Befehl ... Befehl } })
Transaktionsantwort(Transaktionskennung {
Kontextkennung { Antwort ... Antwort },
. . .
Kontextkennung { Antwort ... Antwort } })
Abbildung 19: Kommunikation im Megaco [RFC 3525 S.69-70]
Für den Aufbau von Megaco-Nachrichten existiert eine ASN.1-Beschreibung [RFC 3525 S.91112]. Es gibt außerdem eine ABNF-Spezifikation die eine textuelle Notation spezifiziert [RFC
3525 S.113-127].
G.2 Deskriptoren
Die Parameter eines Befehls werden in Deskriptoren spezifiziert. Diese haben die Form:
Deskriptor=<Kennung>{Parameter=Wert, Parameter=Wert, ...}.
Mögliche Deskriptoren sind:
Modem spezifiziert einen Modemtyp und entsprechende Parameter.
Mux (Multiplexing) assoziiert Medien mit Trägern, wie ISDN-Kanälen oder RTP-Strömen.
Media spezifiziert Parameter für alle Medienströme. Die Parameter sind in die zwei
Unterdeskriptoren TerminationState und Stream unterteilt, wobei Stream wiederum die
Descriptoren LocalControl, Local und Remote enthalten kann.
TerminationState beschreibt den Zustand einer Terminierung. Gültige Zustände sind: Test,
Out of Service oder In Service. Es wird außerdem festgelegt, ob Ereignisse in einem Buffer
temporär abgelegt oder direkt verarbeitet werden.
Stream spezifiziert die Parameter eines bidirektionalen Stroms. Ein Strom kann erzeugt
werden, indem eine neue Stromkennung für eine Terminierung innerhalb eines Kontextes
angegeben wird. Ein Strom wird entfernt, indem leere Local- und Remote-Deskriptoren
verwendet werden und die Parameter ReserveGroup und ReserveValue im Deskriptor
LocalControl auf False gesetzt werden.
LocalControl enthält den Parameter Mode, der auf Send-Only, Receive-Only, Send/Receive,
Inactive (Default) oder Loop-Back gesetzt werden kann. Die Parameter ReserveValue und
ReserveGroup geben an, ob alle oder eine der alternativen Ressourcen reserviert werden
soll, die in den Deskriptoren Local und Remote aufgeführt werden.
Local und Remote spezifizieren die Ressourcen die für eine Dekodierung bzw. Kodierung von
Strömen benötigt werden. Zur Beschreibung der Ströme wird das SDP verwendet. Local
bezieht sich auf eintreffende Ströme während Remote ausgehende behandelt.
102
Anhang G - Megaco
Events enthält eine Liste von Ereignissen, die ein MG erkennen und mitteilen soll. Dies
können z.B. Faxtöne sein, damit ein MGC ggf. eine geeignete Konvertierung veranlassen
kann. Events kann zusätzlich einen eingebetteten Signals- oder Event-Deskriptor enthalten,
der den vorherigen Deskriptor ersetzt, wenn das Ereignis erkannt wird. Dieser ermöglicht
z.B. das Beenden des Wähltons, nachdem eine Nummer eingeben wurde.
EventBuffer enthält eine Liste von Ereignissen, die von einem MG erkannt werden sollen,
damit diese in eine Warteschlange eingereiht werden können.
Signals beschreibt die Medien, die von einer Terminierung erzeugt werden. Dies sind z.B.
Töne, Ansagen oder trägerbezogene Signale.
Audit veranlasst die Übermittlung von Werten in Deskriptoren.
DigitMap definiert Muster zum Vergleich mit gewählten Rufnummern. Diese können z.B. mit
dem DTMF-Verfahren eingegeben werden. Wird ein Muster erkannt, wird ein entsprechendes
Ereignis gemeldet.
Statistics stellt Informationen über den Status und die Verwendung einer Terminierung
innerhalb eines Kontextes zu Verfügung.
Packages wird wird als Antwort auf den Befehl AuditValue gesendet. Der Deskriptor enthält
eine Liste von Paketen, die eine Terminierung unterstützt.
ObservedEvents wird mit dem Befehl Notify an ein MGC versendet und enthält erkannte
Ereignisse.
Topology spezifiziert die Flussrichtung zwischen Terminierungen in einem Kontext. Je zwei
Terminierungen haben die Beziehung Oneway, Bothway oder Isolate. Wird der Deskriptor
nicht angegeben, kann jede Übertragung von allen Terminierungen in einem Kontext
empfangen werden.
Error kann in einer Antwort zu einem Befehl oder in einem Notify-Befehl übertragen werden
und weist auf einen Fehler bei der Verarbeitung einer Übertragung hin.
ServiceChange beschreibt welcher Dienst aus welchem Grund geändert wird und gibt
weitere Hintergrundinformationen an.
[RFC 3525 S.27-50,61-64]
103
Anhang G - Megaco
G.3 Beispiel
Context = - {
ServiceChange = ROOT {Services {
„-“: kein Kontext
ServiceChange-Nachricht
ROOT-Terminierung bzw.
betrifft das gesamte Gateway
} }
}
Method=Restart,
Dienst wird wiederaufgenommen
ServiceChangeAddress=55555,
GW verwendet Port-Nummer 55555
für weitere Kommunikation
Profile=ResGW/1}
Profil ResGW, Version 1
keine Alternative definiert
Abbildung 20: Ein MG registriert sich bei einem MGC [RFC 3525 S.184]
104
Anhang H - SCTP
Das IP sowie UDP bieten weder einen zuverlässigen noch einen verbindungsorientierten
Übertragungsdienst an. Hier müssen alle Anforderungen in höheren Schichten implementiert
werden. Das TCP stellt diese Dienste zwar bereit, ist aber anfällig für DoS-Angriffe. Durch den
Transport
eines
Bytestroms
können
außerdem
Nachrichtengrenzen
nicht
direkt
wiederhergestellt werden. Das TCP erzwingt darüber hinaus eine zuverlässige Übertragung
durch unbedingte Wiederholungen der gesamten Daten ab einem fehlenden oder fehlerhaften
Segment. Neuere Informationen werden so verzögert (Head of Line Blocking) und können die
zeitlichen Anforderungen des SS7 nicht erfüllen. Des Weiteren muss eine höhere Schicht den
Push-Mechanismus verwenden, um Nachrichten innerhalb einer sinnvollen Zeit versenden zu
können. [RFC 4960 S.5]
Auf Grund der genannten Probleme entwickelte die IETF-Arbeitsgruppe Signaling Transport
(SigTran) das Transportprotokoll SCTP (Stream Control Transmission Protocol), das im [RFC
4960] beschrieben wird. Die Eigenschaften resultieren aus den Anforderungen des SS7,
können jedoch auch für andere Anwendungen hilfreich sein:
Das SCTP verwendet für einen Verbindungsaufbau einen Vier-Wege-Handshake, um DoSAngriffe zu erschweren. Dazu werden die Ressourcen einer Verbindung erst reserviert,
nachdem der initiierende Teilnehmer seine ursprüngliche Anfrage in der dritten Nachricht
bestätigt hat. Die Erreichbarkeit eines Teilnehmers kann zusätzlich durch die Angabe mehrerer
Adressen verbessert werden (Multi-Homing). Um sicherzustellen, dass eine Verbindung
zwischen zwei Adressen noch aktiv ist, können außerdem Lebenszeichen in Form kurzer
Nachrichten
ausgetauscht
werden
(Heartbeat).
Interne
Steuerungsinformationen
sowie
Nutzdaten werden beim SCTP in Chunks versendet, damit unterschiedliche Informationen in
einem Paket übertragen werden können. Datenchunks enthalten zudem jeweils genau eine
Nachricht oder Fragmente davon und wahren so anwendungsspezifische Nachrichtengrenzen.
Ein Datenchunk wird einem bestimmten Strom zugeordnet, der beim Empfänger unabhängig
von anderen Strömen abgerufen werden kann. Auf diese Weise wird ein Head of Line Blocking
zwischen einzelnen Strömen vermieden. Es ist auch möglich einzelne Chunks als ungeordnet
zu markieren, so dass diese ebenfalls nicht durch sequenzielle Chunks blockiert werden. Als
Erweiterung zum SCTP wurde im [RFC 3758] ein teilweise zuverlässiger Transportdienst
(Partial Reliability, PR-SCTP) eingeführt. Damit kann ein Sender mitteilen, dass fehlende oder
fehlerhafte Pakete nicht erneut übertragen werden. Ein geordneter Datenstrom kann so trotz
Lücken ausgeliefert werden. Zusätzlich kann die Zustellung von Paketen, deren Lebensdauer
abgelaufen ist, abgebrochen werden. [RFC 4960 S.6-15,22-24,34-37,63][RFC 3758 S.3-7,1415]
105
Anhang H - SCTP
106
Anhang I - RSVP
RSVP-Nachrichten verwenden einen gemeinsamen Header. Dieser besitzt folgende Felder:
Version 1 (4 Bit)
Flags (4 Bit) sind noch undefiniert.
Nachrichtentyp (8 Bit)
1: Path etabliert einen Pfad zwischen einem Sender und ggf. mehreren Empfängern. Die
Nachricht beinhaltet die Objekte SESSION, RSVP_HOP, TIME_VALUES und optional u.a.
SESSION_TEMPLATE.
2: Resv reserviert Ressourcen auf einem Pfad. Die Nachricht beinhaltet die Objekte
SESSION, RSVP_HOP, TIME_VALUES, STYLE und optional u.a. FLOWSPEC und
FILTER_SPEC.
3: PathErr überträgt Fehlermeldungen zum Sender.
4: ResvErr überträgt Fehlermeldungen zum Empfänger.
5: PathTear entfernt die gesicherten "Path-States" entlang eines Pfades.
6: ResvTear entfernt Reservierungen von einem Pfad.
7: ResvConf bestätigt, dass Reservierung (wahrscheinlich) erfolgreich war.
Prüfsumme (16 Bit) enthält das Einerkomplement der Einerkomplementsumme, die über die
Nachricht gebildet wird. Der
TTL (8 Bit) sichert den IP-Time-To-Live-Wert, um Nicht-RSVP-Router zu entdecken.
Reserviert (8 Bit)
Länge (16 Bit) gibt die Länge der RSVP-Nachricht in Bytes an.
Dem Header folgen Objekte mit folgendem allgemeinen Aufbau:
Länge (16 Bit) gibt die Länge des Objektes in Bytes an. Diese muss einem Vielfachen von 4
entsprechen.
Klasse (8 Bit) enthält die Klasse des übertragenen Objektes (z.B. 1 = SESSION).
Type (8 Bit) identifiziert eine Art Unterklasse.
Objektinhalt
Wichtige Objekte sind:
SESSION enthält die Ziel-IP-Adresse und Portnummer sowie das IP-Protokollfeld.
RSVP_HOP enthält die IP-Adresse der vorherigen Zwischenstation sowie ein Handle, mit
dem eine logische Schnittstelle und damit ein Path-State identifiziert wird.
STYLE enthält einen Option-Vector, mit denen angegeben wird, ob eine Reservierung für
107
Anhang I - RSVP
einen Strom oder für mehrere Ströme gilt und ob ein oder mehrere Sender die Reservierung
nutzen dürfen.
TIME_VALUES gibt das Intervall an, in dem eine Nachricht gesendet wird, um einen Zustand
aktiv zu halten.
FLOWSPEC beschreibt Datenraten, Paketgrößen (siehe RFC 2210, RFC 2212)
SENDER TEMPLATE/FILTER_SPEC enthält die ausgehende IP-Adresse und Portnummer oder
alternativ ein IPv6 Flow Label.
[RFC 2205 S.32-47,57,77-79,84-89]
108
Anhang J - Vergleich von Sprachcodecs
Sprachqualität
Score
Exzellent (Excellent)
Gut (Good)
Mittelmäßig (Fair)
Mangelhaft (Poor)
Schlecht (Bad)
5
4
3
2
1
Abbildung 21: Mean Opinion Score [P.800 S.11]
Codec
Bit
Rate
(Kbps)
Codec
Sample
Größe
(Bytes)
Codec
Sample
Interval
(ms)
Mean
Opinion
Score
(MOS)
Sprachdaten
pro
Paket (Bytes)
Sprachdaten
pro
Paket
(ms)
Pakete
pro
Sekunde
(PPS)
Bandbreite
Ethernet
(Kbps)
G.711
64
80
10
4.1
160
20
50
87.2
G.729
8
10
10
3.92
20
20
50
31.2
G.723.1 6.3
24
30
3.9
24
30
34
21.9
G.723.1 5.3
20
30
3.8
20
30
34
20.8
G.726
32
20
5
3.85
80
20
50
55.2
G.728
16
10
5
3.61
60
30
34
31.5
Abbildung 22: Vergleich von Sprachcodecs [CISCO01]
109
Anhang J - Vergleich von Sprachcodecs
110
Anhang K - Telefax
Die ITU-T-Empfehlung [T.4] beschreibt die Bilddatenformate von Telefaxdokumenten und legt
die Modulationarten fest, mit denen die Dokumente über ein Telefonnetz versendet werden
können. In der Empfehlung [T.30] werden zusätzlich Nachrichten spezifiziert, mit denen eine
Verbindung auf- und abgebaut sowie Rahmenbedingungen für die Datenübertragung
ausgehandelt werden können. Die Nachrichten werden mit einem HDLC-Verfahren versendet,
das eine optionale Fehlerkorrektur ermöglicht.
K.1 Ablauf einer T.30-Telefaxverbindung
Eine Telefax-Verbindung läuft in fünf Phasen ab. In der ersten Phase A erfolgt ein manueller
(ausgehender) oder automatischer (eingehender) Verbindungsaufbau. Das anrufende Faxgerät
sendet dann einen Erkennungston für Nicht-Sprach-Dienste (CNG), den das angerufene Gerät
mit einem Identifizierungston (CED) beantwortet.
Es folgt die Phase B in der beide Geräte ihre Fähigkeiten austauschen. Dazu übermittelt das
angerufene Gerät eine Identifikationsnachricht (DIS), woraufhin das anrufende Gerät mit
einem Befehl festlegt, ob es Daten senden (DTC) oder empfangen möchte (DCS). Der Sender
testet nun mit Trainingssignalen (TCF) verschiedene Datenraten, von denen das empfangende
Gerät eine auswählt (FTT/CFR).
In der Phase C wird erneut ein Trainingsignal gesendet bevor die Übertragung einer
Telefaxseite gemäß der Empfehlung T.4 beginnt. Am Ende der Datenphase wird der Empfänger
in die Phase D überführt (RTC), damit dieser erneut Nachrichten entgegennimmt.
In der Phase D kann der Sender dem Empfänger nun mitteilen, ob weitere Seiten gesendet
werden (MPS). Alternativ kann er signalisieren, dass die Übertragung beendet ist (EOP) oder
dass ein Übergang in Phase B stattfinden soll (EOM). Das empfangende Gerät bestätigt
anschließend den korrekten Empfang (MCF).
In der letzten Phase E beendet das sendende Gerät die Verbindung (DCN).
[T.4 S.4][T.30 S.4-52]
K.2 Wichtige Fax-Nachrichten
CNG Calling Tone signalisiert einen Nicht-Sprach-Dienst.
CED Called Terminal Identification antwortet auf die Nachricht CNG.
DIS Digital Identification enthält die Fähigkeiten eines Faxgerätes.
DTC Digital Transmit Command signalisiert, dass das anrufende Faxgerät ein Dokument
senden möchte. Die Nachricht enthält darüber hinaus die Fähigkeiten des Gerätes.
DCS Digital Command Signal signalisiert, dass das anrufende Gerät ein Dokument
empfangen möchte.
111
Anhang K - Telefax
TCF Training Check stellt ein Trainingssignal dar und testet eine Modulation gemäß ITU-TEmpfehlung T.4.
FTT Failure To Train weist eine Modulation ab.
CFR Confirmation To Receive bestätigt, dass der vorherige Nachrichtenaustausch
abgeschlossen ist und die Übertragung des Dokumentes mit der Modulation des letzten
Trainingssignals beginnen kann.
RTC Return To Control signalisiert das Ende einer Datenphase.
EOM End Of Message signalisiert das Ende einer Telefaxseite. Es folgt ein Übergang in Phase
B.
MPS MultiPage Signal signalisiert das Ende einer Telefaxseite und weist darauf hin, dass
weitere Seiten folgen. Nach einer Bestätigung gehen die Faxgeräte in Phase C über.
EOP End Of Procedure signalisiert das Ende eines Telefaxdokuments und der Übertragung.
Nach einer Bestätigung gehen die Faxgeräte in Phase E über.
MCS Message Confirmation bestätigt den korrekten Empfang einer Nachricht und
signalisiert, dass weitere Nachrichten empfangen werden können.
DCN Disconnect veranlasst den Abbau der Verbindung.
[T.4 S.4][T.30 S.15,44-52]
112
Anhang L - RTSP
Das Real Time Streaming Protocol (RTSP) wird im [RFC 2326] beschrieben und ermöglicht die
Steuerung eines Medienstroms von einem entfernten Endpunkt. Das Protokoll ist textbasiert
und weist, wie das SIP, einige Ähnlichkeiten zum HTTP auf.
Methoden
DESCRIBE beantragt die Sitzungsbeschreibung zu einer gegebenen URL.
ANNOUNCE übergibt einem Server die Sitzungsbeschreibung zu einer URL. Ein Server kann
damit außerdem eine Sitzungsbeschreibung aktualisieren.
GET_PARAMETER fragt die Parameter eines Medienstroms ab (z.B. Jitter).
OPTIONS beantragt die Übertragung der vom Server unterstützten Methoden.
PAUSE hält den Medienstrom vorübergehend an.
PLAY startet die Übertragung des Medienstroms. Dabei kann z.B. auch die Startposition oder
die Abspieldauer angegeben werden.
RECORD veranlasst die Aufnahme von Mediendaten. Optional kann der aufzunehmende
Bereich angegeben werden.
REDIRECT sendet der Server zum Client, um ihn darüber zu informieren, dass er sich mit
einem anderen Server verbinden muss.
SETUP beantragt ein Transportprotokoll für die Übertragung des Medienstroms.
SET_PARAMETER legt die Parameter eines Medienstroms fest.
TEARDOWN unterbricht einen Medienstrom. Die Sitzung ist anschließend ungültig.
Eine Sitzung wird mit Hilfe des SDP beschrieben und in Anfragen und Antworten
eingebettet.
Statusmeldungen
1xx: Informell - Eine Anfrage wurde erhalten; die Verarbeitung wird fortgesetzt.
2xx: Erfolg - Eine Aktion wurde empfangen, verstanden und akzeptiert.
3xx: Umleitung - Für die Bearbeitung einer Anfrage sind weitere Aktionen notwendig.
4xx: Client-Fehler - Eine Anfrage enthält fehlerhaften Syntax oder kann nicht erfüllt werden.
5xx: Server-Fehler - Der Server konnte eine gültige Anfrage nicht erfüllen.
[RFC 2326 S.23,30-40]
113
Anhang L - RTSP
114
Anhang M - Multicast
Anwendungen, wie das Fernsehen produzieren Inhalte, die zeitgleich an viele Empfänger
ausgeliefert werden. Bei einer Unicast-Übertragung werden die gleichen Informationen dabei
mehrmals über die selben Leitungen transportiert. Multicast bietet eine Möglichkeit, die
Redundanz und damit die notwendige Bandbreite minimal zu halten:
Ein Endpunkt übermittelt die Daten an genau eine spezielle Adresse, die für MulticastÜbertragungen reserviert ist. Andere Endpunkte können die Daten dann empfangen, indem sie
die mit der Adresse assoziierte Multicast-Gruppe abonnieren. Die Daten werden zu diesem
Zweck von Punkt zu Punkt übertragen und lediglich dort vervielfältigt, wo die einzelnen
Empfänger über unterschiedliche Schnittstellen erreichbar sind. Multicast-Übertragungen
setzen daher eine Infrastruktur voraus, in der alle Router zwischen dem Sender und den
Empfängern diese Technik beherrschen.
Multicast-Adressen
Ethernet-MAC-Adressen: 33-33-00-00-00-00 bis 33-33-FF-FF-FF-FF
IPv4: 224.0.0.0/4, lokal: 224.0.0.0/24
IPv6: FF 4-Bit-Flags 4-Bit-Scope/16
Flags definiert, ob es sich um eine wohlbekannte oder vorübergehende Adresse handelt.
Scope legt fest in welchem Bereich der Verkehr weitergeleitet werden muss. (Global,
Organisationsweit, Standortweit, auf einer direkten Verbindung zweier benachbarter Geräte,
innerhalb eines Gerätes)
Nachrichten
Zur Steuerung einer IPv4-Multicast-Gruppe wird in den RFCs 1112, 2236 und 3376 das
Internet Group Management Protocol (IGMP) spezifiziert. Im RFC 3810 werden mit dem
Multicast Listener Discovery (MLD) Protokoll analoge Nachrichten zur Multicast-Steuerung in
einem IPv6-Netz beschrieben.
Multicast Listener Report (MLD) bzw. Membership Report (IGMP) wird von Endpunkten an
eine Multicast-Adresse versendet, um die Mitgliedschaft in einer Gruppe zu verkünden.
Multicast Listener Query (MLD) bzw. Membership Query (IGMP) wird von einem Router
versendet, um festzustellen, ob in einem Netz an einer seiner Schnittstellen Mitglieder einer
angegebenen Gruppe existieren. Ist dies nicht der Fall, müssen keine weiteren
Gruppeninformationen in das entsprechende Netzwerksegment weitergeleitet werden.
Multicast Listener Done (MLD) bzw. Leave Group (IGMP) wird von einem Gruppenmitglied
gesendet, wenn dieses die Gruppe verlässt und es das letzte Mitglied innerhalb eines
Subnetzes ist.
[MICROSOFT01]
115
Anhang M - Multicast
116
Glossar und Abkürzungsverzeichnis
Begriffe
Codec
eine Einheit, die sowohl eine Kodiereinheit (Encoder) als auch eine
Dekodiereinheit (Decoder) enthält
Jitter
Laufzeitschwankungen von Paketen
Soft-PBX
ein Back-to-Back User Agent im SIP
Softswitch
fasst ein Signalisierungsgateway und einen Media Gateway Controller
zusammen
Traffic Shaping
verteilt Bandbreite nach Kriterien, wie Anwendung, Benutzer oder
Priorität
Video on Demand
lässt einen Zuschauer einen Film auswählen, damit er diesen
unabhängig von Sendezeiten anschauen kann
Abkürzungen
ISDN-Dienstmerkmale
3PTY
I.254.2 Three Party Service
ADS
I.529.1 Address Screening
AOC
I.256.2 Advice of Charge
CCBS
I.253.3 Completion of Calls to Busy Subscribers
CCNR
I.253.4 Completion of Calls on no Reply
CD
I.252.5 Call Deflection
CFB
I.252.2 Call Forwarding Busy
CFNR
I.252.3 Call Forwarding No Reply
CFU
I.252.4 Call Forwarding Unconditional
CLIP
I.251.3 Calling Line Identification Presentation
CLIR
I.251.4 Calling Line Identification Restriction
CNIP
I.251.9 Calling Name Identification Presentation
CNIR
I.251.10 Calling Name Identification Presentation
COLP
I.251.5 Connected Line Identification Presentation
COLR
I.251.6 Connected Line Identification Restriction
CONF
I.254.1 Conference Calling
CRED
I.256.1 Credit Card Calling
CUG
I.255.1 Closed User Group
CW
I.253.1 Call Waiting
CT
I.252.1 Call Transfer
117
DDI
I.251.1 Direct-Dialling-In
ECT
I.252.7 Explicit Call Transfer
HOLD
I.253.2 Call Hold
IM
I.258.2 In-Call Modification
LH
I.252.6 Line Hunting
MCI
I.251.7 Malicious Call Identification
MLPP
I.255.3 Multi-Level Precedence and Preemption service
MMC
I.254.5 Meet-Me Conference
MSN
I.251.2 Multiple Subscriber Number
OCB
I.255.5 Outgoing Call Barring
PNP
I.255.2 Private Numbering Plan
PS
I.255.4 Priority Services
REV
I.256.3 Reverse Charging
SUB
I.251.8 Sub-addressing
TP
I.258.1 Terminal Portability
UUS
I.257.1 User-to-User Signalling
RDS
AF
Alternative Frequencies
CT
Clock Time and date
DI
Decoder Identification
ECC
Extended Country Codes
EON
Coding of Enhanced Other Networks information
EWS
Emergency Warning Systems
IH
In House applications
MS
Music Speech switch
ODA
Open Data Applications
PI
Programme Identification
PIN
Programme Item Number
PS
Programme Service name
PTY
Programme TYpe
PTYI
Dynamic PTY Indicator
TMC
Traffic Message Channel
RP
Radio paging
RT
RadioText
TP
Traffic Programme
TA
Traffic Announcement
118
Teletext
ATS
Automatic Tuning System
EPG
Electronic Programme Guide
FLOF
Full-Level-One-Facilities
TOP
Table Of Pages
VPS
Video Programme System
H.323 Zusatzdienste
SS-PARK
H.450.5 Call Park
SS-PICKUP H.450.5 Call Pickup
SS-MWI
H.450.7 Message Waiting Indication
SS-CO
H.450.10 Call Offering
SS-CI
H.450.11 Call Intrusion
ANF-CMN
H.450.12 Additional Network Feature Common Information
Weitere Abkürzungen
AAC
Advanced Audio Codec
ADSL
Asymmetric Digital Subscriber Line
AKNN
Arbeitskreis technische und betriebliche Fragen der Nummerierung und der
Netzzusammenschaltung
AMI
Alternate Mark Inversion
APE
Application Protocol Entity
ARI
Autofahrer Rundfunk Information
ASN.1
Abstract Syntax Notation No. 1
ATM
Asynchroner Transfer Mode
BICC
Bearer Independent Call Control
CCITT
Comité Consultatif International Télégraphique et Téléphonique
CEPT
Conférence Européenne des Administrations des Postes et des Telecommunications
CMS
Cryptographic Message Syntax
CRC
Cyclic Redundancy Check
DAB
Digital Audio Broadcast
DAVIC
Digital Audio Video Council
DHCP
Dynamic Host Configuration Protocol
DMT
Discrete Multitone Transmission
DRM
Digital Radio Mondial
DS
Differentiated Services
DSCP
Differentiated Services Codepoint
119
DSL
Digital Subscriber Line
DSS1
Digital Subscriber Signalling one
DTMF
Dual Tone Multiple Frequency
DUP
Data User Part
DVB
Digital Video Broadcast
EMN
E-Mail Notification
ETSI
European Telecommunications Standards Institute
FEC
Forward Error Correction
FTP
File Transfer Protocol
GAT
Generic Application Template
GCC
Generic Conference Control
GPRS
General Packet Radio Service
GSM
Groupe Spéciale Mobile, Global System for Mobile Communications
HDLC
High-level Data Link Control procedures
HDTV
High Definition Television
IAF
Internet Aware Fax Terminals
IAX
InterAsterisk-Protokoll
IETF
Internet Engineering Task Force
IGMP
Internet Group Management Protocol
IP
Internet Protocol
IPTV
Internet Protocol Television
ISDN
Integrated Services Digital Network
ISMA
Internet Streaming Media Alliance
ISP
Internet Service Provider
ISUP
ISDN User Part
IFT
Internet Facsimile Transfer
ITU
International Telecommunication Union
ISO
International Organization for Standardization
ITR
International Telecommunication Regulations
JVT
Joint Video Team
LAPD
Link Access Procedure on the D-channel
LCP
Link Control Protocol
M2UA
MTP2 User Adaptation Layer
M2PA
MTP2 Peer-to-Peer Adaptation Layer
M3UA
MTP3 User Adaptation Layer
MAP
Mobile Application Part
MCS
Multipoint Communication Service
MGCP
Media Gateway Control Protocol
120
MIME
Multipurpose Internet Mail Extensions
MJD
Modified Julian Day, ein Zeitformat in dem Tage gezählt werden
MLD
Multicast Listener Discovery
MMS
Multimedia Message Service
MP3
MPEG Audio Layer 3
MPEG
ISO/IEC Moving Picture Experts Group
MTP
Message Transfer Part
NCP
Network Control Protocol
NTBP
Network Termination Basic Rate Access
NTSC
National Television Standards Committee
NVoD
Near Video on Demand
OMA
Open Mobile Alliance
PAL
Phase Alternating Lines
PBX
Public Branch Exchange
PDH
Plesiochrone Digitale Hierarchie
PER
Packed Encoding Rules
PGP
Pretty Good Privacy
PHB
Per-Hop Behavior
PoC
Push-to-Talk over Cellular
PoE
Power over Ethernet
PPP
Point to Point Protocol
PPPoE
PPP over Ethernet
PSTN
Public Switched Telephone Network
QAM
Quadraturamplitudenmodulation
QoS
Quality of Service
RAS
Registration, Admission and Status
RFC
Request for Comments
RSVP
Ressource Reservation Protocol
RTP
Real-Time Transport Protocol
RTCP
RTP Control Protocol
RTSP
Real Time Streaming Protocol
SAP
Session Announcement Protocol
SCCP
Signalling Connection Control Part (ISDN),
Skinny Client Control Protocol (VoIP)
SCTP
Stream Control Transmission Protocol
SD&S
Service Discovery and Selection
SDH
Synchrone Digitale Hierarchie
SDP
Session Description Protocol
121
SDTV
Standard Definition Television
SIP
Session Initiation Protocol
SIP-T
Session Initiation Protocol for Telephones
SMS
Short Message Service
SONET
Synchronous Optical Network
SS7
Signaling System No. 7
SUA
SCCP User Adaptation Layer
TCAP
Transaction Capabilities
TCM
Time Compression Multiplex
TCP
Transmission Control Protocol
TDM
Time Division Multiplex
TIFF
Tag Image File Format
TUP
Telephone User Part
UDP
User Datagram Protocol
UKW
Ultrakurzwelle, (Frequenzbereich für Radio: 87,5–108 MHz)
UMTS
Universal Mobile Telecommunications System
URI
Uniform Resource Identifier
UTC
koordinierte Weltzeit
VCR
Videorecorder
VoIP
Voice over IP
VoD
Video on Demand
VCEG
ITU-T Video Coding Experts Group
WAP
Wireless Application Protocol
WWW
World Wide Web
122
Literatur
Digital Audio Video Council
[DAVIC] Welcome to DAVIC, 1999, http://www.davic.org, letzter Besuch 09.2007
[PART1] Description of Digital Audio-Visual Functionalities, DAVIC 1.4 Specification Part 1,
DAVIC, Geneva, 1998
[TVANY] TV Anytime and TV Anywhere, DAVIC 1.5 Specifications, DAVIC, Geneva, 1999
(Die DAVIC-Spezifikationen können online bezogen werden:
http://www.davic.org/down1.htm)
European Telecommunications Standards Institute
[02.01] ETSI 300 500, Principles of telecommunication services supported by a GSM Public
Land Mobile Network (PLMN), (GSM 02.01), ETSI, Sophia Antipolis, 1996
[02.03] ETSI TS 100 905 V7.0.0, Teleservices supported by a GSM Public Land Mobile
Network (PLMN) (GSM 02.03 version 7.0.0 Release 1998), ETSI, Sophia Antipolis, 1999
[03.45] ETSI TS 100 931 V8.0.1, Technical realization of facsimile group 3 transparent
(GSM 03.45 version 8.0.1 Release 1999), ETSI, Sophia Antipolis, 2000
[02.04] ETSI EN 300 918 V7.1.2, General on supplementary services (GSM 02.04 version
7.1.2 Release 1998), ETSI, Sophia Antipolis, 1999
[02.82] ETSI TS 100 515 V7.0.1, Call Forwarding (CF) Supplementary Services - Stage 1
(GSM 02.82 version 7.0.1 Release 1998), ETSI, Sophia Antipolis, 1999
[02.88] ETSI TS 100 520 V7.0.0, Call Barring (CB) Supplementary Services - Stage 1 (GSM
02.88 version 7.0.0 Release 1998), ETSI, Sophia Antipolis, 1999
[EN 300 659] Access and Terminals (AT); Analogue access to the Public Switched Telephone
Network (PSTN); Subscriber line protocol over the local loop for display (and related)
services; Part 1-3, ETSI, Sophia Antipolis, 2001
[EN 300 706] ETSI EN 300 706 V1.2.1 (2003-04), Enhanced Teletext specification, ETSI,
Sophia Antipolis, 2003
[ETS 300 102-1] ETS 300 102-1, Integrated Services Digital Network (ISDN); User-network
interface layer 3 Specifications for basic call control, ETSI, Sophia Antipolis, 1990
[TS 101 231] ETSI TS 101 231 V1.3.1 (2002-12), Television systems; Register of Country
and Network Identification (CNI), Video Programming System (VPS) codes and Application
codes for Teletext based systems, ETSI, Sophia Antipolis, 2002
[TS 102 034] Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB
123
Literatur
Services over IP Based Networks, ETSI, Sophia Antipolis, 2007
(Die Standards der ETSI können online bezogen werden:
http://pda.etsi.org/pda/queryform.asp)
International Telecommunication Union
[E.412] Network Management Controls, ITU-T, 2003
[F.185] Internet facsimile: Guidelines for the support of the communication of facsimile
documents, ITU-T, 1998
[G.961] Digital transmission system on metallic local lines for isdn basic rate access, ITU-T,
Helsinki, 1993
[H.239] Role management and additional media channels for H.300-series terminals, ITU-T,
2005
[H.245] Control protocol for multimedia communication, ITU-T, 2006
[H.323] Packet-based multimedia communications systems, ITU-T, 2007
[H.450.1] Generic functional protocol for the support of supplementary services in H.323,
ITU-T, Geneva, 1998
[H.450.5] Call park and call pickup supplementary services for H.323, ITU-T, 1999
[H.450.6] Call waiting supplementary service for H.323, ITU-T, Geneva, 1999
[H.450.7] Message waiting indication supplementary service for H.323, ITU-T, 1999
[H.450.10] Call offering supplementary services for H.323, ITU-T, 2001
[H.450.11] Call intrusion supplementary service for H.323, ITU-T, 2001
[H.450.12] Common Information Additional Network Feature for H.323, ITU-T, 2001
[I.210] Principles of Telecommunication Services supported by an ISDN and the Means to
describe them, ITU-T, Melbourne, 1993
[I.211] B-ISDN Service Aspects, ITU-T, 1993
[I.240] #Definition of Teleservices, ITU-T, Melbourne, 1988, 1993
[I.241.7] Telephony 7kHz Teleservice, ITU-T, Helsinki, 1993
[I.241.8] Teleaction Stage One Service Description, ITU-T, Geneva, 1995
[I.250] Definition of supplementary Services, ITU-T, Melbourne, 1988, 1993
[I.251.9] Calling Name Identification Presentation, ITU-T, Geneva, 1996
[I.251.10] Calling Name Identification Restriction, ITU-T, Geneva, 1996
[I.252.7] Explicit Call Transfer, ITU-T, Geneva, 1997
[I.253.4] Completion of Calls on no Reply, ITU-T, Geneva, 1996
124
Literatur
[I.254.5] Meet-Me Conference, ITU-T, Geneva, 1997
[I.255.3] Multi-Level Precedence and Preemption service, ITU-T, Geneva, 1990
[I.255.4] Priority Services, ITU-T, Geneva, 1990
[I.255.5] Outgoing Call Barring, ITU-T, Geneva, 1992
[I.258.1] Terminal Portability (TP), ITU-T, Geneva, 1995
[I.258.2] In-Call Modification (IM), ITU-T, Geneva, 1994
[I.529.1] Address Screening, ITU-T, Geneva, 1996
[I.411] ISDN user-network interfaces - reference configurations, ITU-T,
[I.430] Basic user-network interface - Layer 1 specification, ITU-T, Malaga-Torremolinos,
Melbourne, Helsinki, 1996
[I.431] Primary Rate User-Network Interface – Layer 1 specification, ITU-T, MalagaTorremolinos, Melbourne, Helsinki, 1993
[P.800] Methods for subjective determination of transmission quality, ITU-T, 1996
[Q.700] Intrduction to CCITT Signaling System No. 7, ITU-T, Melbourne, Helsinki, 1994
[Q.921] ISDN user-network interface – Data link layer specification, ITU-T, 1998
[Q.931] ISDN user-network interface layer 3 specification for basic call control, ITU-T, 1999
[Q.932] Digital Subscriber Signalling System No. 1 – Generic procedures for the control of
ISDN supplementary services, ITU-T, 1999
[T.4] Standardization of Group 3 facsimile terminals for document transmission, ITU-T, 2003
[T.30] Procedures for document facsimile transmission in the general switched telephone
network, ITU-T, 2005
[T.37] Procedures for the transfer of facsimile data via store-and-forward on the Internet,
ITU-T, 1998
[T.38] Procedures for real-time Group 3 facsimile communication over IP networks, ITU-T,
1998
[T.120] Data protocols for multimedia conferencing, ITU-T, Geneva, 1996
[T.121] Generic application template, ITU-T, Geneva, 1996
[T.122] Multipoint communication service - Service definition, ITU-T, 1998
[T.124] Generic Conference Control, ITU-T, Geneva, 1998
[T.125] Multipoint communication service protocol specification, ITU-T, 1998
[T.126] Multipoint still image and annotation protcol, ITU-T, Geneva, 1995
[T.128] Multipoint application sharing, ITU-T, Geneva, 1998
(Alle ITU-T Empfehlungen können online bezogen werden: http://www.itu.int/rec/T-REC)
125
Literatur
Open Mobile Alliance
[OMA] Open Mobile Alliance Ltd., 2004, http://www.openmobilealliance.org, letzter Besuch
08.2007
[MMS] Enabler Release Definition for MMS, Candidate Version 1.3 – 27 Oct 2005, OMAERELD-MMS-V1_3-20051027-C, Open Mobile Alliance Ltd., 2005
[EMN] Enabler Release Definition for E-Mail Notification, Candidate Version 1.0 – 31 Jul
2004, OMA-ERELD-EMN-v1_0-20040731-C, Open Mobile Alliance Ltd., 2004
[PoC] Enabler Release Definition for Push-to-Talk over Cellular, Approved Version 1.0.1 – 28
Nov 2006, OMA-ERELD-PoC-V1_0_1-20061128-A, Open Mobile Alliance Ltd., 2006
(OMA Veröffentlichungen können online bezogen werden:
http://www.openmobilealliance.org/release_program/index.html)
Request for Comments
[RFC 741] Network Voice Protocol (NVP), Danny Cohen, ISI, 1976
[RFC 791] Internet Protocol, Arlington, Information Sciences Institute University of
Southern California, 1981
[RFC 2205] Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,
Braden (ISI), Zhang (UCLA), Berson (ISI), Herzog (IBM Research), Jamin (Univ. of
Michigan), 1997
[RFC 2304] Minimal FAX address format in Internet Mail, C. Allocchio, GARR-Italy, 2001
[RFC 2326] Real Time Streaming Protocol, H. Schulzrinne, A. Rao, R. Lanphier, Columbia
University, Netscape, RealNetworks, 1998
[RFC 2460] Internet Protocol, Version 6 (IPv6) Specification, S. Deering, R. Hinden, Cisco,
Nokia, 1998
[RFC 2474] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, Nichols (Cisco Systems), Blake (Torrent Networking Technologies), Baker (Cisco
Systems), Black (EMC Corporation), 1998
[RFC 2516] A Method for Transmitting PPP Over Ethernet (PPPoE), L. Mamakos et al.,
UUNET Technologies, Inc., RedBack Networks, Inc., RouterWare, Inc., 1999
[RFC 3261] SIP: Session Initiation Protocol, J. Rosenbert et al., ICIR, E. Scooler, AT&T, 2002
[RFC 3311] The Session Initiation Protocol (SIP) UPDATE Method, J. Rosenberg,
dynamicsoft, 2002
[RFC 3515] The Session Initiation Protocol (SIP) Refer Method, R. Sparks, dynamicsoft,
2003
[RFC 3525] Gateway Control Protocol Version 1, C. Groves et al., Nortel Networks, 2003
126
Literatur
[RFC 3550] RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne et al.,
Columbia University, Packet Design, Blue Coat Systems Inc., 2003
[RFC 3551] RTP Profile for Audio and Video Conferences with Minimal Control, H.
Schulzrinne et al., Columbia University, Packet Design, 2003
[RFC 3758] Stream Control Transmission Protocol (SCTP) Partial Reliability Extension, R.
Stewart et al., University of Delaware, 2004
[RFC 4566] SDP: Session Description Protocol, M. Handley et al., UCL, University of
Glasgow, 2006
[RFC 4960] Stream Control Transmission Protocol, R. Stewart, 2007
(Request for Comments können online bei der IETF bezogen werden: http://www.ietf.org)
Weitere Standards
[IEC 62106] The new RDS IEC 62106:1999 standard, RDS Forum Office, Geneva, 1999
[ISMA01] Internet Streaming Media Alliance Implementation Specification, ISMA, Mountain
View, 2001
(Alle ISMA-Spezifikationen können online bezogen werden:
http://www.isma.tv/specreq.nsf/SpecRequest)
Weitere Literatur
[0900 GESETZ] Gesetz zur Bekämpfung des Missbrauchs von 0190er-/0900erMehrwertdinsterufnummern, Bundesgesetzblatt Jahrgang 2003 Teil I Nr. 40, ausgegeben zu
Bonn am 14. August 2003
[0900] (0)900 Premium Rate-Dienste, Bundesnetzagentur, 2007,
http://www.bundesnetzagentur.de/enid/641078fcb87897ba1bcee16de178c3b8,d0d2d85f74
72636964092d0936333139/Nummernverwaltung/_9___fb.html, letzter Besuch 08.2007
[0800] Freephone-Dienste (0) 800, Bundesnetzagentur, 2007,
http://www.bundesnetzagentur.de/enid/641078fcb87897ba1bcee16de178c3b8,d0d2d85f74
72636964092d0936333139/Nummernverwaltung/_8___fd.html, letzter Besuch 08.2007
[0180] (0)180, Bundesnetzagentur, 2007,
http://www.bundesnetzagentur.de/enid/641078fcb87897ba1bcee16de178c3b8,0/Nummern
verwaltung/_ss8__ex.html, letzter Besuch 08.2007
[ARI] ARI-Technik – Hilfe beim DX, Bernhard Weiskopf, UKW/TV-Arbeitskreis der AGDX e.V.,
Mannheim, 2001
[BLANK] All-over-IP contra All-over-OSI, Torsten Blank, Wolfgang Hankeln, Hans-Christoph
Jakobeit und Lars Struss, Universität Bremen, 2004
127
Literatur
[BOETTLERCERNKO] Videotext Technik in Vergangenheit, Gegenwart und Zukunft, Sibylle
Weber-Böttler, Patrick Cernko, 1999
[BUCHHOLZ] Anfänge des Fernsehens: Technische Grundsatzentscheidungen, Agon S.
Buchholz, Freie Universität Berlin, Fachbereich Philosophie und Sozialwissenschaften I,
Arbeitsbereich Informationswissenschaft, 1996, http://www.kefk.net/Research/Funk/HAFunk/titel.html, letzter Besuch 08.2007
[CHOWANETZ] Schneewittchensarg und Katzenkopf, dem Versuch einer Chronologie des
Rundfunks in Deutschland der Jahre 1923 bis 2000, J. Chowanetz, Hengersberg, 20012007, http://www.chowanetz.de/radios, letzter Besuch 08.2007
[CISCO01] Voice Over IP - Per Call Bandwidth Consumption, Cisco Systems, 2005,
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.
shtml, letzter Besuch 12.2007
[COGEL] Streaming: Video und Audio im Internet, Berthold Cogel, Sebastian Schetter,
Universität zu Köln, 2007, http://www.unikoeln.de/rrzk/multimedia/dokumentation/streaming/, letzter Besuch 12.2007
[DARROCH] Introduction to Sigtran, Jim Darroch, Artesyn Communication Products, 2004
[EARLYRADIOHISTORY] EarlyRadioHistory.us, Thomas H. White, http://earlyradiohistory.us/,
letzter Besuch 08.2007
[FREIERMUTH] Digitale Übertragungstechnik, IT-Ausbildung: Öffentliche Netze und Dienste,
Freiermuth Wolfgang, BBS-Landau, 2007
[GARTVIHS] Wofür brauchen wir Telekommunikation - Telekonferenz, Irina Gartvihs, Long
Lam, Balz Schaerer, Tobias Witzig, ETH Zürich, Universität Karlsruhe, 2002, http://www.ework.ethz.ch/praesentationen/ws_01-02/gruppe_2/Balz/Videokonferenz1-2.htm, letzter
Besuch 08.2007
[GRIFFITHS] ISDN Explained, John M. Griffiths, John Wiley & Sons, Chichester, 1990
[HEIDELBERG] VoIP an der Universität Heidelberg, Steffen Michl, 2005, http://web.urz.uniheidelberg.de/Netzdienste/VoIP/, letzter Besuch 07.2007
[HÖVEL] Kupfer am Limit, Jörg Auf dem Hövel, Telepolis, 2006,
http://www.heise.de/tp/r4/artikel/24/24244/1.html, letzter Besuch 12.2007
[ITWISSEN] ITWissen, DATACOM Buchverlag GmbH, 2004-2007, http://www.itwissen.info,
letzter Besuch 07.2007
[KNAUER] Regulierung von Voice over IP (Diplomarbeit), Robert Knauer, HumboldtUniversität zu Berlin, 2006
[LANGLOIS] ADSL Tutorial, Matthew J. Langlois, University of New Hampshire, Durham,
USA, 2002
[LIGHT] Facsimile: A forgotten 'new medium' from the 20th century, Jennifer S. Light,
Northwestern University, SAGE Publications, 2006
[M 5.136] M 5.136 Dienstgüte und Netzmanagement bei VoIP, Bundesamt für Sicherheit in
128
Literatur
der Informationstechnik, http://www.bsi.de/gshb/deutsch/m/m05136.htm, letzter Besuch
07.2007
[MABEZ02] Spezifikation Behandlung von Massenverkehr zu bestimmten Zielen, Rainer
Hurek, AKNN, UAK MABEZ, 2002
[MICROSOFT01] TCP/IP-Grundlagen für Microsoft Windows, Anhang A: IP-Multicast,
Microsoft TechNet, 2006,
http://www.microsoft.com/germany/technet/itsolutions/network/evaluate/technol/tcpipfund
/tcpipfund_appa.mspx, letzter Besuch 12.2007
[NALDINI] Eine kleine Geschichte des Fernsehens, Petra Naldini, R. Stehle, Telepolis, Heise
Zeitschriften Verlag 2006, http://www.heise.de/tp/r4/artikel/23/23477/1.html, letzter
Besuch 08.2007
[NRIC VI] Network Interoperability - Final Report, Network Reliability and Interoperability
Council VI Focus Group 3, 2003
[RENSEN] HF-FAX, Marius Rensen, 2004, http://www.hffax.de/history/index.html, letzter
Besuch 07.2007
[RÖSSEL] Jahrbuch 2001 Kommunikationsnetze, Heiko Rössel Hrsg., Addison-Wesley,
Prentice Hall, Pearson Education Deutschland, München, 2001
[SANTI] Santiago Muñoz, SIGTRAN between MGCs, 2006, http://www1.ietf.org/mailarchive/web/sigtran/current/msg06213.html, letzter Besuch 11.2007
[SCHERTENLEIB] Signalisierung in konvergenten Netzen, Funkschau 12/2001, Kurt
Schertenleib, 2001
[SCHNABEL] Das Elektronik-Kompendium, Patrick Schnabel, Die Geschichte des Mobilfunks:
http://www.elektronik-kompendium.de/sites/kom/0910121.htm, letzter Besuch 07.2007,
VDSL - Very High Data Rate Digital Subscriber Line: http://www.elektronikkompendium.de/sites/kom/0305237.htm, letzter Besuch 12.2007, IP-TV / IPTV / TV over
IP /TVoDSL: http://www.elektronik-kompendium.de/sites/kom/1103281.htm, letzter Besuch
12.2007, ATM - Asynchronous Transfer Mode: http://www.elektronikkompendium.de/sites/kom/0712111.htm, letzter Besuch 02.2008
[SCHULZRINNE] SIP RFCs and Drafts, Henning Schulzrinne,
http://www.cs.columbia.edu/sip/drafts.html, letzter Besuch 12.2007
[SIEMENS] Clarification of Suspend/Resume and Hold/Retrieve vs. Facility in H.225, Robert
Callaghan, Siemens, ITU-T Study Group 16, 1997, http://ftp3.itu.int/av-arch/avc-site/19972000/9702_Bos/AVC-1115.doc, letzter Besuch 09.2007
[TANENBAUM] Computernetzwerke, A. S. Tanenbaum, Pearson Studium, 2000
[TVHISTORY] Television History - The First 75 Years, Tom Genova, Tvhistory.TV, 2001-2006,
http://www.tvhistory.tv, letzter Besuch 08.2007
[UNDERWOOD] Faxing over IP networks, Steve Underwood, Soft-Switch.org, 2007,
http://www.soft-switch.org/foip.html, letzter Besuch 12.2007
129
Literatur
[WALLINGFORD] Switching to VoIP, Ted Wallingford, O'Reilly Media, Inc., Sebastopol, 2005
[WALTER] Technisch basierte audiovisuelle Fernkommunikation, Prof. Dr. H. Walter Schmitz,
Universität Essen, 2003, http://www.uni-essen.de/videokonferenz, letzter Besuch 08.2007
[WIESEL] Die Entwicklung der Telephon-Vermittlungstechnik in Deutschland, Daniel
Erpelding, Rheinisch Westfälisch Technische Hochschule Aachen, 2000,
http://www.wiesel.lu/publications/telefon/, letzter Besuch 06.2007
[ZAKON] Hobbes' Zeitgeschichte des Internet v5.2, Robert H Zakon, Michael Kaul, 19992001, http://www.michaelkaul.de/Geschichte/geschichte.html, letzter Besuch 09.2007
130
Alle genannten Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen
des jeweils gültigen Kennzeichnungsrechtes und gegebenenfalls den Besitzrechten der jeweilig
eingetragenen Eigentümer.

Technischer Bericht als PDF

Transcrição

Documentos relacionados

NETGEAR - Produktkatalog

SCX-4720FN - JA

DSL-Tester zur schnellen und kostengünstigen Fehleranalyse mit

DSL-2543B - D-Link

Super 8

Das S0-Modul 540 verfügt über vier schaltbare ISDN

Datenblatt: UF-7100

Datenblatt Alcatel-Lucent Enterprise OMNIPCX Office Rich

Knigge-Tipps rund um die Kommunikation Wussten Sie, dass

Software VPN-Appliance der besonderen Art