Technischer Bericht als PDF
Transcrição
Technischer Bericht als PDF
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 3. Entwicklung von Telekommunikationsdiensten 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 3. Entwicklung von Telekommunikationsdiensten 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 3. Entwicklung von Telekommunikationsdiensten 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 3. Entwicklung von Telekommunikationsdiensten 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 3. Entwicklung von Telekommunikationsdiensten 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 4. Mehrwertdienste in der "klassischen Telekommunikation" 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang B - H.323 Signalisierungsnachrichten 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 Anhang C - SIP-Signalisierungsnachrichten 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 Anhang C - SIP-Signalisierungsnachrichten 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 Anhang C - SIP-Signalisierungsnachrichten 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 Anhang C - SIP-Signalisierungsnachrichten [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 Anhang C - SIP-Signalisierungsnachrichten 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 Anhang F - RTP/RTCP-Header-Informationen 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 Anhang F - RTP/RTCP-Header-Informationen 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 Anhang F - RTP/RTCP-Header-Informationen 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 Glossar und Abkürzungsverzeichnis 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 Glossar und Abkürzungsverzeichnis 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 Glossar und Abkürzungsverzeichnis 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 Glossar und Abkürzungsverzeichnis 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 Glossar und Abkürzungsverzeichnis 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.