Entwicklung einer verteilten Architektur für ein ... - AG Rechnernetze

Universität BremenEntwicklung einer verteilten Architekturfür ein modulares Systemzur Adaption vonSteuer- und Medienströmenin Multi-Protokollumgebungen fürIP-Telefonie und MultimediakonferenzenDiplomarbeit vonAndreas Büsching16. November 20011. Gutachter: Prof. Dr.-Ing. Ute Bormann2. Gutachter: Prof. Dr. rer. nat. Martin Gogolla

Inhaltsverzeichnis1. Einleitung 12. Basistechnologien 32.1. IP – Internet-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. RTP und RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1. Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2. Medientransport mit RTP . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3. RTP-Steuer-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4. Translator und Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3. MEGACO-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2. Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4. Anrufsignalisierung und -steuerung . . . . . . . . . . . . . . . . . . . . . . . 282.5. Medienbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383. Anforderungen und Ziele 413.1. Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2. Zielfindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.1. Bestandsaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.2. Anwendungsszenarien von Media-Prozessoren . . . . . . . . . . . . . 483.2.3. Funktionalität von Media-Prozessoren . . . . . . . . . . . . . . . . . 493.3. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.1. Robust Audio Tool – RAT . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.2. Die UCL commonlib . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.3. UCL Transcoding Gateway – UTG . . . . . . . . . . . . . . . . . . . . 523.3.4. SIP-basierter Audio-Konferenz-Server – sipconf . . . . . . . . . . . . 533.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544. Architektur 55

ivInhaltsverzeichnis4.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2. Konferenz-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.1. Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2.2. Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.3. Konferenz-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3. Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.2. Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3.3. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3.4. Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.4. Interne Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765. Implementierung 775.1. RTP-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.1.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.1.2. Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2. MePro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.3. Konferenz-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866. Zusammenfassung und Ausblick 876.1. Stand der Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.2. Weiterer Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A. Verlustunempfindlicher Transport von Medienströmen mit RTP 91A.1. RTP-Payload-Typ für redundante Informationen . . . . . . . . . . . . . . . . 91A.2. Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.3. Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Glossar 95Literaturverzeichnis 99Index 103

Abbildungsverzeichnis2.1. IPv4-Paketkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. IPv6-Paketkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Kopf eines RTP-Pakets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4. optionale Erweiterung des RTP-Kopfes . . . . . . . . . . . . . . . . . . . . . 112.5. RTCP-Empfänger-Bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6. RTCP-Sender-Bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7. RTCP-Quellbeschreibungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8. RTCP-SDES-Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9. RTCP-BYE-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10.RTCP-Anwendungserweiterung . . . . . . . . . . . . . . . . . . . . . . . . . 172.11.MEGACO – Verbindung zum herkömmlichen Telefonnetz . . . . . . . . . . . 212.12.Trennung zwischen Steuereinheit und Media-Prozessor . . . . . . . . . . . . 222.13.Verbindungsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.14.SIP-Anrufsignalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.15.SIP-Anrufübergabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.16.H.323-Anrufsignalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1. Infrastruktur in der Arbeitsgruppe . . . . . . . . . . . . . . . . . . . . . . . . 423.2. Verbindung zu einer Multicast-Konferenz . . . . . . . . . . . . . . . . . . . . 463.3. Übersetzung zwischen verschiedenen Kodierungsverfahren . . . . . . . . . . 473.4. Vermittlung zwischen verschiedenen Netzen . . . . . . . . . . . . . . . . . . 473.5. Bündelung von Medienströmen . . . . . . . . . . . . . . . . . . . . . . . . . 473.6. Anbindung von Teilgruppen in große Konferenzen . . . . . . . . . . . . . . . 493.7. UTG-Server und UTG-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.8. Audio-Mixer von sipconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.1. Aufbau eines Media-Prozessors . . . . . . . . . . . . . . . . . . . . . . . . . 554.2. Informationsfluß im Konferenz-Modell . . . . . . . . . . . . . . . . . . . . . 574.3. Aufbau des Konferenz-Modells . . . . . . . . . . . . . . . . . . . . . . . . . 65

viAbbildungsverzeichnis4.4. Verwaltung von Modulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.5. Address-Struktur eines Transport-Moduls . . . . . . . . . . . . . . . . . . . . 664.6. Aufbau eines Transport-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . 674.7. Codec-Struktur für Filter-Module . . . . . . . . . . . . . . . . . . . . . . . . 684.8. Beispiel einer Codec-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . 694.9. Aufbau eines Filter-Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.10.Aufbau eines Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.11.Aufbau eines Ereignis-Objektes . . . . . . . . . . . . . . . . . . . . . . . . . 704.12.Struktur zur Meldung von Ereignissen . . . . . . . . . . . . . . . . . . . . . 704.13.Argumenten-Liste für Ereignisse und Signale . . . . . . . . . . . . . . . . . . 714.14.Aufbau eines Erweiterungs-Modul . . . . . . . . . . . . . . . . . . . . . . . . 724.15.Aufbau eines Steuer-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.16.Beispiel: Vermittlung zwischen IPv4- und IPv6-Netz . . . . . . . . . . . . . . 734.17.Fluß der Mediendaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.18.Aufbau einer Konferenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.1. Struktur der RTP-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2. Ereignis-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3. Generische Schnittstelle der RTP-Bibliothek . . . . . . . . . . . . . . . . . . 815.4. Abhängigkeiten innerhalb MEPRO . . . . . . . . . . . . . . . . . . . . . . . . 82A.1. RTP-Paket mit redundanten Informationen . . . . . . . . . . . . . . . . . . . 92

Tabellenverzeichnis2.1. Erweiterungsköpfe in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Liste der SDES-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3. Kommandos zwischen MGC und MG . . . . . . . . . . . . . . . . . . . . . . 252.4. MEGACO-Deskriptoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1. Quell- und Ziel-Adreßtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2. verschiedene Signal-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

viiiTabellenverzeichnis

1. EinleitungDas Internet ist mittlerweile eines der am häufigsten eingesetzten Medien zum Austauschvon Informationen. Dabei bietet es ein weites Spektrum an Diensten. Zu den bekanntestengehören das World Wide Web (WWW), E-Mails und Newsgroups. Ein weiterer Dienst,der erst langsam Verbreitung findet, ist die interaktive Sprachkommunikation, die optionaldurch Video-Informationen erweitert werden kann.Sprachkommunikation wird heutzutage über das leitungsvermittelte Telefonnetz abgewikkelt.Bei der ständig steigenden Zahl von Menschen, die Dienste des Internet nutzen, könnteeine Einführung von Telefonie-Diensten bald zu einem vollwertigen Ersatz für das herkömmlicheTelefonnetz heranwachsen. Entwicklungen in diesem Bereich werden mit demBegriff IP-Telefonie umschrieben.Für IP-basierte Netze werden auch andere Möglichkeiten zur interaktiven Sprachkommunikationentwickelt, die sich nicht direkt an die Telefonie anlehnen. Dabei werden spezielleFähigkeiten der zugrundeliegenden Netze ausgenutzt, um den Transport der Informationenzwischen den einzelnen Teilnehmern zu optimieren und den Verlust von Daten zu minimieren.In diesen Bereich gehören die Mbone-Konferenzen, die die Gruppenadressierung(Multicast) in IP-basierten Netzen nutzen, um die Menge der zu transportierenden Datenzu reduzieren.Zur Realisierung von IP-basierter Multimedia-Kommunikation wird zur Zeit an mehrerenStandards gearbeitet. Dabei werden komplexe Signalisierungs- und Steuerungs-Protokolleentwickelt, die die Funktionalität der heutigen Telefonnetze bieten sollen. Weitere wichtigeThemen in der Standardisierung sind der Transport und die Verarbeitung der Mediendaten.Diese beiden Themen sind bei jeder interaktiven Kommunikation über ein IP-basiertes Netzwichtig und hängen von der Form der Kommunikation ab.Der Begriff der Kommunikation ist eine allgemeine Beschreibung für zwei Formen, die indieser Diplomarbeit von Interesse sind. Die einfachere Form beschreibt eine Kommunikationzwischen zwei Teilnehmern (Zwei-Punkt-Beziehung). Die zweite Form befaßt sich mitKommunikationsbeziehungen, in die mehr als zwei Teilnehmer involviert sind (Konferenzen).Sowohl die Signalisierung als auch der Transport und die Verarbeitung der Medienströmeist in dieser Form der Kommunikation komplexer.In Zwei-Punkt-Beziehungen können die Mediendaten direkt zwischen den Teilnehmernausgetauscht werden. In Konferenzen hingegen müssen andere Techniken gefunden werden,um die Informationen effizient zwischen allen Teilnehmern auszutauschen. Eine Möglichkeitbietet die Multicast-Adressierung des Internet Protokolls (IP), die in den Mbone-Konferenzen eingesetzt wird. Die Multicast-Adressierung wird allerdings zur Zeit nur ineinem Teilbereich des Internet unterstützt und bietet somit keine einheitliche Lösung füralle Konferenzen. Eine andere Möglichkeit bieten Konferenz-Zentralen, die als Verteiler fungieren.Die Teilnehmer selbst leiten ihre Mediendaten nur an die Zentrale weiter. Von dortwerden die Daten an die anderen Teilnehmer verteilt. Bei einem Ausfall der Zentrale ist diegesamte Konferenz unterbrochen was eine hohe Störanfälligkeit bedeutet.

2 Kapitel 1. EinleitungNicht nur der Transport von Mediendaten ist in IP-basierten Netzen mit neuen Problemenverbunden, die im leitungsvermittelten Telefonnetz nicht auftreten. In der heterogenenStruktur des Internet existieren Netze mit den unterschiedlichsten Kapazitäten. Auf demWeg zwischen zwei Teilnehmern können sich somit Netze befinden, die nicht die benötigteBandbreite zur Verfügung stellen können, um die Mediendaten zu transportieren. In diesenFällen können beispielsweise Instanzen an den Grenzen dieser Netze eingesetzt werden,die durch eine Komprimierung der Mediendaten für einen reibungslosen Transport durchdas Netz sorgen. Diese Technik beeinflußt die anderen Teilnehmer nicht und bietet denNutzern in den Netzen mit geringer Kapazität eine Teilnahme an der Konferenz.Diese Diplomarbeit beschäftigt sich mit der genauen Analyse von Problemstellungen imBereich des Transportes und der Verarbeitung von Medienströmen in Konferenzen. DieseAnalysen sowie weitergehende Untersuchungen und die Betrachtung von vorhandenenTechniken sollen zur Definition einer Architektur für eine Komponente führen, die zur Lösungvon Problemen, wie den zuvor beschriebenen, eingesetzt werden kann. Dabei ist dieModularität der Komponente besonders wichtig, um einen weiträumigen Einsatz in beliebigenMultimedia-Kommunikationen einschließlich der IP-Telefonie zu gewährleisten. Desweiterenmuß die Verwendung als zentrale Instanz oder als Teil einer solchen sowie derEinsatz innerhalb eines Endpunktes möglich sein.• Im nächsten Kapitel werden Basistechnologien beschrieben, die für den Kontext dieserDiplomarbeit wichtig sind.• Kapitel 3 beschreibt die Infrastruktur für IP-Telefonie und entwickelt Ideen für Strukturenund Funktionen der zu entwickelnden Komponente.• Kapitel 4 definiert die Architektur und legt eine genaue Definition der Funktionenund Module fest.• Kapitel 5 befaßt sich mit der exemplarischen Implementierung der zuvor entwickeltenArchitektur.• Kapitel 6 schließt die Arbeit mit Überlegungen zu möglichen Erweiterungen ab.

2. BasistechnologienInternationale Standards sind für das Internet von großer Bedeutung. Diese ermöglichendie übergreifende Kommunikation zwischen den verschiedenen Netzen, aus denen das Internetbesteht. Geschlossene Systeme hingegen ermöglichen nur einer begrenzten Anzahlvon Herstellen die Integration ihrer Produkte, wodurch eine weiträumige oder übergreifendeKommunikation schwierig oder unmöglich ist.Für die Thematik dieser Diplomarbeit, die sich mit der Erweiterung und Verbesserung vonDiensten in Multimedia-Konferenzen beschäftigt, sind internationale Standards unverzichtbar.Dieses Kapitel beschäftigt sich mit den Basistechnologien, die für das Verständnis dieserArbeit notwendig sind, sowie mit den Gremien, die diese entwickelt haben.Viele der im Internet eingesetzten Technologien basieren auf internationalen Standards, dievon dem wichtigsten Standardisierungsgremium in diesem Bereich, der IETF (Internet EngineeringTask Force), publiziert wurden. Ein weiteres Gremium, das in den letzten Jahrenviel im Bereich der Multimedia-Kommunikation in paketvermittelten Netzen beigetragenhat, ist die ITU-T (Telecommunication Standardization Sector of ITU).Die IETF ist eine offene internationale Organisation, die es erlaubt, daß Menschen ausallen Teilen der Welt ohne formale Mitgliedschaft aktiv an der Internet-Standardisierungteilnehmen können. Gegenstand der Standardisierung in der IETF sind alle erdenklichenBereiche, die sich mit Technologien im Internet beschäftigen. Unterteilt ist die IETF in Areas,die wiederum aus mehreren Working Groups bestehen, welche sich mit bestimmtenThemengebieten beschäftigen. Kommuniziert wird hauptsächlich über Mailing-Listen 1 , sodaß sich jeder ohne Einschränkungen an der Entwicklung beteiligen kann. Die Ergebnissewerden in Form von RFCs (Request for Comment) veröffentlicht.Die ITU-T 2 , die schon vor der Entstehung des Internet existierte, ist eine Untergruppe derITU (International Telecommunication Union). Ihr Ursprung liegt in der Standardisierungim Bereich der Telekommunikationstechnik. Seit Mitte 1995 befassen sich Teile der ITU-Tmit der IP-Telefonie. Unterteilt ist die ITU-T in Study Groups, die sich mit fest definiertenThemen beschäftigen. Mehrere Working Parties sind einer Study Group zugeordnet undbestehen aus einer Anzahl von Questions, die sich mit einer Reihe von konkreten Fragenauseinandersetzen.Die im folgenden ausgewählten Standards und Basistechnologien bilden die Grundlage fürdas Verständnis dieser Arbeit. Dabei werden Protokolle verschiedener Schichten und Modelleund Konzepte vorgestellt.Eines der wichtigsten Protokolle ist IP (Internet Protocol, RFC 791 [47]). Seit vielen Jahrenist IP in der Version 4 das Protokoll der Vermittlungsschicht im Internet. Mittlerweilewird an einer neuen, verbesserten Version 6 gearbeitet, die nun langsam in Teilnetzen eingesetztwird. Um Konferenzen in und zwischen Netzen mit diesen beiden Protokollen der1 Zusätzlich findet dreimal im Jahren ein Treffen statt.2 Früher als CCITT (Comite Consultatif International Telegraphique et Telephonique) bekannt.

4 Kapitel 2. BasistechnologienVermittlungsschichten zu unterstützen, ist ein detailliertes Wissen über diese Protokollenotwendig.Der Transport von Medienströmen in IP-basierten Netzen wird in der Regel mittels RTP(Real-Time Transport Protocol, RFC 1889 [18]) realisiert. Der RFC beschreibt zusätzlichzum Protokoll wichtige Konzepte die für Verarbeitung von Medienströmen, für die das Verständnisvon RTP und RTCP (RTP Control Protocol) notwendig sind.Multimedia-Gateways, zentrale Komponenten, die Dienste im Bereich des Transportes undder Verarbeitung von Medienströmen bereitstellen, sind zentraler Punkt der Entwicklungender Working Group MEGACO. Die im RFC „Megaco Protocol 1.0“ 3015 [9] veröffentlichtenKonzepte, Modelle und Definitionen des Protokolls können für die Entwicklung der eigenenArchitektur von Nutzen sein.Um die Möglichkeit einer Integration in die IP-Telefonie zu untersuchen, werden zwei Konferenzumgebungenanhand ihrer wichtigsten Protokolle, Komponenten und Konzepte beschrieben.Desweiteren wird in diesem Zusammenhang auf Möglichkeiten zur Beschreibungvon Medienströmen eingegangen, die für die Kommunikation mit einer Steuer-Instanz eingesetztwerden können.2.1. IP – Internet-ProtokollDas Internet ist ein Zusammenschluß von verschiedenen Netzen. Damit über die Grenzender einzelnen Netze hinaus beliebige Daten versendet werden können, wird eine netzübergreifendeAdressierung benötigt. IP (Internet Protocol, RFC 791 [47]) bietet genau dieseArt der Adressierung. Dadurch können Pakete von einem Netz in ein beliebiges anderestransportiert werden und dabei weitere Netze passieren. Dabei werden die Datenpaketevon besonderen Systemen (Routern) durch das Internet bis zum Ziel transportiert. Anhandder Adresse wird der Weg zum Ziel ermittelt.Die Architektur des Internet setzt voraus, daß es Systeme gibt, die zwischen den verschiedenenNetzen vermitteln. Treten Fehler bei der Vermittlung von Paketen auf, muß es möglichsein, die Quelle darüber zu informieren, damit diese entsprechend reagieren kann (z.B.durch ein erneutes Senden des Paketes). Für diese Aufgabe ist ICMP (Internet Control MessageProtocol, RFC 792 [46]) definiert worden.Die vier Byte langen Adressen der aktuell eingesetzten Version 4 des Internet-Protokolls(IPv4) bieten einen Adreßraum, der mittlerweile durch das enorme Wachstum des Internetfast vollständig aufgebraucht ist. Auch hat die langjährige Praxis mit der Version 4 gezeigt,daß sich die Anforderungen an das Internet-Protokoll gewandelt haben. Im RFC 2460 [10]ist eine neue Version 6 (IPv6) spezifiziert. Die Adressen von IPv6 sind 16 Byte lang undbieten somit genügend Platz für weitere Netzknoten.Im folgenden werden anhand der Paketköpfe die genauen Fähigkeiten von IPv4 und IPv6untersucht. Dabei wird genauer auf Funktionen für den Transport von Medienströmen(„Echtzeitdaten“) eingegangen.IP Version 4In Abbildung 2.1 ist der Kopf eines IP-Paketes der Version 4 dargestellt. Jedes IP-Paket beginntmit einem 4-Bit-Feld, das die Version des Protokolls enthält. Das darauf folgende Feld

2.1. IP – Internet-Protokoll 5IHL (Internet Header Length) gibt die tatsächliche Länge des Kopfes in 32-Bit-Worten an.Die dort eingetragene Zahl kann nicht kleiner als fünf sein, da dies der Länge des feststehendenTeil des Kopfes entspricht.0 16 32VersionIHLToSTotal LengthIdentificationFlagsFragment OffsetTTL Protocol ChecksumSource AddressDestination AddressOptionsPadding BytesAbbildung 2.1.: IPv4-PaketkopfDas Feld Type of Service (ToS) kann mit einer Kombination von Flags den Transport deseinzelnen Paketes beeinflussen. Die genaue Definition der einzelnen Bits aus dem RFC entsprichtnicht mehr der aktuellen Interpretation. Im RFC 2474 [38] mit dem Titel „Definitionof the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers“ werden dieToS-Bits neu definiert. Dabei ist die Rückwartskompatibilität nicht gegeben.Das Feld Total Length enthält die gesamte Länge des IP-Paketes in Bytes. Dabei werdenKopf- und Datenlänge zusammengezählt.Das nächste 32-Bit-Wort enthält Informationen zur Fragmentierung. In den ersten zweiBytes ist eine Kennung (Identification) für die Fragmente enthalten, damit die Bestandteileeines Paketes beim Empfänger identifiziert und zusammengesetzt werden können.Anschließend folgt das Feld Flags, in dem beschrieben wird, ob dieses Paket fragmentiertwerden darf, und falls es sich um ein Fragment handelt, ob es sich um das letzte Fragmenteines Paketes handelt. Die letzten 13 Bits des 32-Bit-Wortes enthalten einen Offset, der inEinheiten von 64-Bit-Worten angegeben wird. 3 Damit wird bestimmt, an welche Stelle imGesamtpaket dieses Fragment eingefügt werden muß.Im Feld TTL (Time To Live) wird eingetragen, nach wievielen Zwischenstationen (Routern)das Paket zerstört werden soll. Jeder Router im Internet, der dieses Paket weiterleitet, solldiese Zahl um eins erniedrigen. 4 Erreicht diese Zahl den Wert null, wird das Paket gelöscht.Durch dieses Feld wird verhindert, daß unzustellbare Pakete ewig durch das Internet geleitetwerden.Im Feld Protocol steht eine Kennung, die angibt, welches Protokoll in der darüber liegendenSchicht verwendet wird. Die Zahlen sind ebenso wie die Type of Service-Flags bei der IANA(Internet Assigned Numbers Authority) registriert. Als letztes Feld vor der Quell- und Ziel-Adresse folgt noch die Checksum (Prüfsumme), die jedoch nur über den Kopf des Paketesgebildet wird.Der Kopf eines IP-Paketes kann nach den Adressen noch Optionen enthalten. Die Anzahlgenauso wie die Länge der einzelnen Optionen ist variabel. Dabei gibt es zwei Arten vonFormaten für eine Option. Die erste Art der Optionen besteht nur aus einem einzigen Byte.3 Die Fragmente werden so aufgeteilt, daß sie in der Länge einem Vielfachen von 64 Bit entsprechen. Ausschließlichdas letzte Fragment muß diese Eigenschaft nicht erfüllen.4 Der RFC definiert Sekunden als die Einheit für das Feld, aber dies hat mit der Realität nichts zu tun. Da vieleRouter keine Bearbeitungszeit von einer Sekunde brauchen, ist die Einheit dieser Zahl zu vernachlässigen.

6 Kapitel 2. BasistechnologienEtwas komplexer ist das Format der zweiten Optionsart. Die ersten zwei Bytes bestehenaus einem Typfeld gefolgt von einer Längenangabe, die diese zwei Bytes inklusive demRest der Option zusammenzählt. Eine mögliche Option wäre z.B. Loose Source and RecordRoute, mit der die Quelle eines Paketes die Möglichkeit hat, Informationen über die zuverwendende Route vorzugeben.IP Version 6Der Kopf eines IP-Paketes der Version 6 hat sich gegenüber seines Vorgängers wesentlichverändert, wie in Abbildung 2.2 zu sehen ist. Gleichgeblieben ist das Feld mit der Version,mit dem der Kopf beginnt.Traffic Class (Klassifizierung) ist ein in IPv6 neu eingeführtes Feld. Die Funktion diesesFeldes soll der des Feldes Type of Service aus IPv4 ähnlich sein. Zur Zeit der Entstehungdes RFCs ist noch keine genaue Definition des Feldes vorhanden. Die Erfahrungen mit IPv6sollen die benötigten Klassen und Prioritäten hervorbringen, welche dann in weiteren RFCsspezifiziert werden.0 16 32VersionTraffic ClassFlow LabelPayload Length Next Header Hop LimitSource AddressDestination AddressAbbildung 2.2.: IPv6-PaketkopfEbenso wie das Feld Traffic Class kann für die Multimedia-Kommunikation das folgendeFeld Flow Label (Datenstrombezeichnung) von Interesse sein. Wird dieses Feld mit einemWert ungleich null ausgefüllt, dient es als Bezeichnung für einen Strom von IP-Paketen.Damit soll bei den Routern, die diese Funktionalität unterstützen, ein verbesserter Servicefür diese Pakete aktiviert werden. Diese Fähigkeit ist in IPv6 neu hinzugekommen undgehört zu einer der wichtigsten neuen Funktionen, die zur Entwicklung der neuen Versiongeführt haben. Dieser besondere Service könnte z.B. bei Konferenzen nützlich sein, um dieMedienströme als solche zu kennzeichnen und somit eine höhere Wahrscheinlichkeit derfristgerechten Zustellung zu erzielen.Das Feld Payload Length (Nutzdatenlänge) gibt die Länge der Nutzdaten einschließlichaller Erweiterungen dieses Paketes an. Das nachfolgende Byte enthält eine Kennung, diespezifiziert welche Erweiterung nach diesem Kopf folgt (Next Header). Das letzte Feld vorden Adressen ist das Feld Hop Limit (Reichweitenbegrenzung). Die Funktion dieses Feldesentspricht der des TTL-Feldes aus Version 4 des IP-Protokolls.

2.1. IP – Internet-Protokoll 7Die Darstellung der Optionen hat sich gegenüber der Version 4 verändert. Das Feld NextHeader (nächster Kopf) kann entweder auf den Kopf der nächsten Protokollschicht verweisenoder auf den einer Erweiterung. Im RFC 2460 sind acht Paketköpfe definiert. Werdenmehrere dieser Köpfe in ein IP-Paket integriert, sind sie in der Reihenfolge einzufügen, wiein Tabelle 2.1 angeben ist.KopfIPv6-KopfHop-by-Hop-OptionskopfRouting-KopfFragment-KopfZiel-OptionskopfAuthentisierungs-KopfgekapselteSicherheitsdatenKopf der darüberliegendenSchichtBeschreibungStandardkopf eines IPv6-Paketes (wie zuvor beschrieben)dient zum Transport von optionalen Informationen,die von allen Knoten auf dem Weg zum Zielbetrachtet werden müssen.gibt Knoten an, die auf dem Weg zum Ziel besuchtwerden sollen.wird eingesetzt, wenn Pakete verschickt werdensollen, die größer als die maximal erlaubteTransporteinheit (Maximum Transmission Unit,MTU) sind. Im Gegensatz zu IPv4 kann die Fragmentierungeines Paketes nur von der Quellevorgenommen werden und nicht mehr von denRoutern auf dem Weg zum Ziel.enthält optionale Informationen, die nur vonden angegebenen Zielen des Paketes zu untersuchensind. Die einzigen definierten Variantendieser Option dienen zur Erzeugung von Füllbytes.bietet Quellauthentisierung. Eine genaue Beschreibungdieses Kopfes ist in RFC 2402 [33]zu finden.dient zur Bereitstellung von Sicherheitsdiensten.Eine genaue Beschreibung dieses Kopfesist in dem RFC 2406 [34] zu finden.wird durch die darüberliegende Schicht definiert,etwa durch TCP oder UDP.Tabelle 2.1.: Erweiterungsköpfe in IPv6AdressierungIPv4 stellt dem Anwender drei Adressierungsarten zur Verfügung. Unicast dient zur Adressierunggenau eines einzelnen Rechners. Um eine Gruppe von Rechnern anzusprechen, gibtes die Möglichkeit der Multicast-Adressierung. Um alle Rechner in einem Netzabschnittanzusteuern, gibt es Broadcast. Diese Adressierung aus IPv4 wird in IPv6 durch eine erweiterteMulticast-Adressierung ersetzt. Eine weitere Art der Adressierung ist das Anycast.Hierbei wird nur der erste Rechner einer Gruppe angesprochen. Welches der erste Rechnerist entscheidet der Router nach seinem Maßstab.Für Multimedia-Konferenzen ist die von beiden IP-Versionen unterstützte Gruppenadressier-

8 Kapitel 2. Basistechnologienung eine sehr wichtige Fähigkeit. Diese Technik kann aber nicht alleine von IP realisiert werden.Damit Pakete, die nicht direkt an einen Rechner adressiert sind, auch von den beteiligtenRoutern weitergeleitet werden, müssen sich interessierte Rechner bei Multicast-fähigenRoutern anmelden. Bei IPv4 wird diese Funktionalität mittels IGMP (Internet Group ManagementProtocol, RFC 2236 [12]) unterstützt 5 . Für IPv6 wurde keine Version von IGMPdefiniert. Dafür wurde ICMP (Internet Control Message Protocol, RFC 2463 [7]) stark erweitertund übernimmt diese Aufgabe. Ursprünglich wurde ICMP eingesetzt, um auftretendeFehler beim Transport von Paketen an die Quelle zu melden (z.B. nicht zustellbarePakete).Um Multicast-Adressen von Unicast-Adressen unterscheiden zu können, sind die Adreßräumein Bereiche aufgeteilt. Für IPv4 ist der Wertebereich von 224.0.0.0 bis 239.255.255.255 6für Multicast-Kommunikationen reserviert. Bei IPv6 sind die Adressen für Multicast reserviert,bei denen die acht höchstwertigen Bits gesetzt sind. Da IPv6-Adressen [23] mit128 Bit wesentlich größer geworden sind, ist auch der Bereich für die Multicast-Adressendementsprechend gewachsen. In RFC 2375 „IPv6 Multicast Address Assignments“ [22]werden festdefinierte Multicast-Adreßbereiche aufgelistet. Interessant in Bezug auf dieseDiplomarbeit ist dabei, daß auch Adreßräume für Multimedia-Konferenzen reserviert wurden.2.2. RTP und RTCPRTP (Real-Time Transport Protocol, RFC 1889 [18]) ist ein Transport-Protokoll, das entworfenwurde, um einen End-zu-End-Dienst zu realisieren, der für Echtzeitdaten wie Audiound Video geeignet ist. Dafür stellt RTP Dienste wie Nutzlast-Erkennung, Sequenzerhaltung,Synchronisation mittels Zeitstempeln und Überwachungsfunktionen zur Verfügung.Der RFC 1889 wurde im Januar 1996 von der IETF herausgegeben. Zur Zeit wird aneiner verbesserten und aktualisierten Fassung gearbeitet, die noch nicht fertiggestellt istund somit nur als Internet-Draft vorliegt [52]. Der RFC 1890 [17] definiert das RTP/AVP-Profil und eine Reihe von vordefinierten Bezeichnungen für bestimmte Audio- und Videokodierungsverfahren.Dieser RFC ist ebenso in einer überarbeiteten Fassung als Internet-Draft [51] vorhanden.In Verbindung mit RTP wird RTCP (RTP Control Protocol, RFC 1889) eingesetzt. Dieses Protokollbietet Überwachungs- und Informationsdienste. RTCP-Pakete enthalten Angaben zurQualität der transportierten Medienströme. Diese können zur Qualitätskontrolle verwendetwerden. Zusätzlich enthalten RTCP-Pakete Daten über die Teilnehmer, die einerseits zur internenIdentifikation und andererseits für eine menschenlesbare Beschreibung verwendetwerden können. 7RTP und RTCP werden auf die Transportschicht des jeweiligen Netzes aufgesetzt, wobeibeide Protokolle unabhängig von den verwendeten Protokollen der Transport- und Vermittlungsschichtsind. In IP-basierten Netzen werden RTP und RTCP in der Regel in Verbindungmit UDP (User Datagram Protocol, RFC 768 [45]) eingesetzt, das einen verbindungslosen,unzuverlässigen Dienst zur Verfügung gestellt. Genutzt werden durch RTP die Eigen-5 In RFC 1112 [11] sind die notwendigen Erweiterung spezifiziert, die ein System erfüllen muß, um Multicastzu unterstützen.6 Dies ist der gesamte Bereich bei dem die höchstwertigen 3 Bits gesetzt und das vierte Bit gelöscht sind.Darüber liegende Adressen sind für zukünftige Adressierungsarten reserviert.7 Diese Informationen sind Texte wie Name, Telefonnummer, E-Mail-Adresse etc.

2.2. RTP und RTCP 9schaften der Korrektheitsprüfung (Checksum) und Anwendungsadressierung von UDP. DieAdressierung bietet die Möglichkeit, zwischen zwei Rechnern mehrere voneinander unterscheidbarePaket-Ströme zu versenden (Multiplexing). Diese Adressen werden Ports genannt.Ein anderes Protokoll, das oft in IP-basierten Netzen verwendet wird, ist TCP (TransmissionControl Protocol, RFC 761 [44]). Es stellt einen verbindungsorientierten, zuverlässigenTransportdienst zur Verfügung. Die Zuverlässigkeit von TCP, die durch wiederholtes Sendenvon defekten oder verlorengegangenen Paketen realisiert wird, ist bei Echtzeitdateneine unerwünschte Eigenschaft. Dadurch werden Teile (Fragmente) eines Medienstromeszu lange verzögert. Auch der von TCP durchgeführte Verbindungsaufbau kostet zu viel Zeit.Für Medienströme ist ein einfaches Protokoll wie UDP besser geeignet.2.2.1. DefinitionenIm folgenden werden Begriffe im Zusammenhang mit RTP und RTCP definiert, die für dasweitere Verständnis benötigt werden.Port Die Abstraktion zur Adressierung von Anwendungen, die von den Transport-ProtokollenUDP und TCP verwendet wird. RTP setzt diese Fähigkeit der Transport-Protokolleein, um mehrere RTP-Ströme zwischen zwei Rechnern unterscheiden zu können.Transport-Adresse Die Kombination aus Netzadresse und Port, z.B. eine IP-Adresse undein UDP-Port.RTP-Payload Die Bezeichnung für Daten, die unter Verwendung von RTP übertragen werden,z.B. Audio-Samples oder Video-Frames.RTP-Paket Ein Datenpaket, das die folgende (logische) Unterstruktur aufweist: Zu Beginnkommt der RTP-Kopf mit einer fest definierten Größe, danach folgt eine eventuellleere Liste von beteiligten RTP-Quellen und der RTP-Payload.RTCP-Paket Ein Steuer-Paket, das aus mehreren Teilen besteht, beginnend mit einem vonder Größe fest definierten Kopf, der zum Teil dem RTP-Kopf gleicht. Darauf folgt einevariable Anzahl von strukturierten Elementen, deren Typ je nach RTCP-Paket variiert.Eine genauere Beschreibung dieser Elemente ist in Abschnitt 2.2.3 zu finden.RTP-Session Eine Beziehung zwischen einer Menge von Teilnehmern. Für jeden Teilnehmereiner RTP-Session wird diese durch eine für ihn eindeutige Transportadresse definiert.Diese kann für alle Teilnehmer die gleiche sein, wenn es sich um eine Multicast-Adressehandelt.Synchronization-Source (SSRC) Die Quelle eines Stroms von RTP-Paketen. Es handeltsich um einen numerischen Bezeichner von 32 Bit Länge, der in den Kopf jedes RTP-Pakets eingetragen wird. Diese Kennung ist eine Zufallszahl, welche innerhalb einerRTP-Session eindeutig sein muß. Jeder Medienstrom eines End-Systems bekommt eineeigene Kennung, d.h. nicht das End-System, sondern der Medienstrom wird durchdie SSRC identifiziert.Contributing-Source (CSRC) Die Quelle eines Stroms von RTP-Paketen, wobei eine CSRCeine von vielen Quellen bezeichnet, die an einem RTP-Strom beteiligt sind. Die SSRCeines solchen kombinierten Stroms ist die des Mixers (siehe Definition Mixer). Dabei

10 Kapitel 2. Basistechnologienwerden vom Mixer alle Quellen in eine Liste eingetragen, die in dem resultierendenRTP-Strom vorhanden sind. Diese Liste wird CSRC-Liste genannt.End-System Eine Anwendung, die die Daten erzeugt und/oder empfängt, die mittels RTPtransportiert werden.Translator Ein End-System, das RTP-Pakete weiterleitet, ohne die SSRC zu verändern. EinTranslator kann das Kodierungsverfahren einzelner RTP-Ströme verändern. Solche Systemekönnen zur Verbindung mehrerer Multicast-Konferenzen oder zur Anbindungvon nicht Multicast-fähigen End-Systemen dienen.Mixer Ein End-System, welches von einer oder mehreren RTP-Quelle(n) Pakete empfängtund diese eventuell verändert (z.B. das Kodierungsverfahren) und dann die Strömebündelt und als neuen Strom von RTP-Paketen weiterleitet.Monitor Eine Anwendung, die nur die RTCP-Pakete einer RTP-Session empfängt und diesezu Statistikzwecken auswertet. Diese Funktionalität kann Teil eines vollwertigen RTP-End-Systems sein.RTP-Profil Eine Definition von Payload-Typen und der dazu gehörigen Medienformate (z.B.Kodierungs- oder Kompressionsverfahren). Optional können dazu Erweiterungen sowieVeränderungen definiert werden. Das am häufigsten eingesetzte und implementierteProfil ist in RFC 1890 [17] definiert. Dazu existiert mittlerweile eine aktualisierteFassung als Internet-Draft draft-ietf-avt-profile-new-10 [51]. Aktuell existierenungefähr 20 weitere RFCs mit RTP-Profilen, wie z.B. RFC 2198 [42], in dem einPayload-Format für die Übertragung von redundanten Audio-Daten definiert ist.2.2.2. Medientransport mit RTPIm folgenden wird genauer auf die Arbeitsweise von RTP eingegangen. Zusätzlich werdenanhand des Paketaufbaus die einzelnen Funktionen von RTP genau beschrieben.PaketformatRTP arbeitet mit einem sehr einfach strukturierten Paketformat, das aus zwei bis drei Teilenbesteht. Mindestens enthalten sind ein Kopf von fest definierter Größe sowie die Nutzlast.Optional kann in das Paket eine Erweiterung integriert werden. Jedes korrekt aufgebauteRTP-Paket beginnt mit einem festen 12-Byte-Kopf wie in Abbildung 2.3 zu sehen ist. Dieersten 2 Bits enthalten die verwendete Version von RTP. Das nächste Bit (Padding-Bit) besagt,wenn es gesetzt ist, daß das Paket mit Füllbytes bis auf ein Vielfaches von 32 Bitaufgestockt wurde. Das letzte Byte eines solchen Paketes enthält die Anzahl der angefügtenBytes. Eingesetzt wird diese Technik für Pakete, die verschlüsselt werden, da einigeVerschlüsselungsalgorithmen auf festen Blockgrößen arbeiten 8 .Das Extension-Bit (X) definiert, ob das RTP-Paket noch eine optionale Kopferweiterungenthält. Ist das Bit gesetzt, folgt eine Erweiterung, die dem Format aus Abbildung 2.4 entspricht.Dabei ist die Erweiterung so strukturiert, daß zuerst eine 16-Bit-Kennung folgt unddann eine Längenangabe, für die ebenfalls ein 16-Bit-Feld zur Verfügung steht. Diese Längebesagt, wie viele 32-Bit-Worte noch in dieser Erweiterung folgen.8 DES arbeitet in der Regel mit 64-Bit-Blöcken, in denen der Schlüssel enthalten ist. Aus diesem Grund mußdie Länge eines RTP-Paketes ein Vielfaches von acht Bytes sein.

2.2. RTP und RTCP 110 16 32V=2P X CC M PT SequenznummerZeitstempelSynchronisationsquelle (SSRC)beteiligte Quellen (CSRC)...Abbildung 2.3.: Kopf eines RTP-PaketsDas Feld CC enthält die Anzahl der beteiligten Quellen (CSRC), die zu diesem Medienstrombeigetragen haben. Diese Liste der Quellen folgt nach dem RTP-Kopf. Das Marker-Bit variiertin seiner Bedeutung, die abhängig von dem verwendeten RTP-Profil ist. Das Bit solleingesetzt werden, um signifikante Ereignisse im Strom zu markieren. Beispielsweise kannso die Grenze eines Video-Frames, der über mehrere Pakete verteilt ist, gekennzeichnetwerden.Damit Empfänger die Art der transportierten Daten erkennen können, wird im Kopf derRTP-Payload-Typ eingetragen. Das Feld ist 7 Bit lang. Die restlichen 16 Bits des ersten 32-Bit-Wortes enthalten die Sequenznummer. Diese sollte mit einem Zufallswert beginnen,um einfache, unerwünschte Angriffe auf verschlüsselte Pakete etwas zu erschweren. Mitjedem Paket wird diese Sequenz um eins inkrementiert, so daß Empfänger diese Nummerzur Erkennung von Paketverlusten nutzen können. Das zweite 32-Bit-Wort enthält einenZeitstempel (RTP-Timestamp). Benötigt wird dieser Zeitstempel zur Synchronisation undJitterberechnung. Dabei sollte der Zeitstempel von einer Uhr abgeleitet werden, die ihrenWert in konstanten Intervalle monoton und linear erhöht, wobei das Intervall kurz genugsein muß, um eine Jitterberechnung zu ermöglichen. Die Intervalle des RTP-Timestampshängen von dem verwendeten RTP-Payload ab. Ebenso wie die Sequenznummer sollte derZeitstempel mit einem Zufallswert beginnen.Das letzte 32-Bit-Wort im RTP-Kopf beinhaltet die Kennung der Quelle des Paketes, dieSSRC (Synchronization Source) genannt wird. Diese Kennung wird ebenfalls zufällig gewählt,wobei sie innerhalb einer RTP-Session eindeutig und konstant sein muß. Nur beieiner Kollision von mehreren gleichen SSRCs in einer Konferenz oder wenn eine Quelle dieTransportadresse ändert, kann die SSRC geändert werden.0 16 32ErweiterungskennungLängeKopf−Erweiterung...Nutzdaten...Abbildung 2.4.: optionale Erweiterung des RTP-KopfesWie in der Abbildung 2.3 veranschaulicht, folgt nach der SSRC die Liste der CSRCs. Dies

12 Kapitel 2. Basistechnologiengilt nur, wenn das RTP-Paket keine Kopf-Erweiterung enthält. Andernfalls wird erst dieErweiterung an den RTP-Kopf und danach die Liste der beteiligten Quellen angehängt.Anforderungen und VerhaltenRTP ist unabhängig von der darunterliegenden Transportschicht definiert. Typischerweisewird RTP in Verbindung mit UDP eingesetzt. Dienste wie Multiplexen und Fehlererkennungwerden dabei von RTP wiederverwendet. Für UDP und gleichartige Protokolle ist definiert,daß RTP einen geradzahligen Port in der Zieladresse verwendet. RTCP soll den darauf folgenden(ungeraden) Port benutzen. 9 In dem Fall, daß einer Anwendung ein ungerader Portfür RTP mitgegeben wird, soll dieser um eins dekrementiert werden.Da RTP-Pakete keine Längenangaben enthalten, muß das unterliegende Protokoll diese Informationbieten. Aus diesem Grund ist auch die maximale Länge des Paketes nur durchdie unterliegende Schicht beschränkt.RTP versendet die Informationen in dem zuvor definierten Paketformat. Stellt das unterliegendeProtokoll keinen Paket-Mechanismus zur Verfügung, muß ein zusätzliches Protokolleingesetzt werden, das RTP-Pakete kapseln kann.Ein Endpunkt, der das RTP-Paketformat versteht, muß zusätzlich ein vordefiniertes Verhaltenaufweisen, wie im folgenden beschrieben, um als RTP-End-System erkannt zu werden.Anwendungen, die RTP für den Transport von Audio-Daten einsetzen, versenden diese inFragmenten, die beispielsweise Informationen für 20 ms Abspielzeit enthalten. Zusammenmit einem RTP-Kopf wird jedes dieser Fragmente in einem UDP-Paket versendet. Es bestehtdie Möglichkeit, daß Pakete verloren gehen oder in einer anderen Reihenfolge ankommen.Ein RTP-End-System muß darauf reagieren. Anhand des im RTP-Kopf enthaltenen Zeitstempelskönnen Verzögerungen erkannt werden. Die Sequenznummer dient hauptsächlich dazudie Reihenfolge der Pakete zu kennen, um sie gegebenfalls zu korrigieren. Desweiterenkönnen die Sequenznummer genutzt werden, um verlorene Pakete zu zählen. Diese Informationensowie Daten über die Teilnehmer werden mittels RTCP verteilt. Jedes RTP-End-System muß RTCP unterstützen.2.2.3. RTP-Steuer-ProtokollRTCP (RTP Control Protocol) ist an RTP gebunden. Es dient zur Beobachtung und Steuerungeiner RTP-Session. Die Aufgaben von RTCP sind in der folgenden Auflistung genauerbeschrieben.1. Primär soll RTCP Informationen über die Empfangsqualität der einzelnen Teilnehmerverbreiten. Diese Daten können die einzelnen End-Systeme nutzen, um herausfinden,ob eventuelle Probleme lokaler oder globaler Natur bezüglich der transportierten Medienströmeexistieren. Dadurch können z.B. Internet Service Provider mittels einesRTP-Monitors die Informationen nutzen, um Konfigurationsprobleme (z.B. im MulticastRouting) zu finden und zu beheben. Auch die teilnehmenden Systeme wertendiese Informationen aus und können aufgrund dieser ihr Verhalten anpassen.2. RTCP transportiert die persistente Kennung einer Quelle, den CNAME (Canonical Na-9 Ein gültiges Paar wäre 48002 für RTP und 48003 für RTCP.

2.2. RTP und RTCP 13me). Im Gegensatz zur SSRC ändert sich der CNAME niemals. 10 Ebenso wichtig ist derCNAME zur Synchronisation mehrerer Medienströme einer Quelle. Beispiel für einesolche Anwendung ist eine Video-Konferenz, bei der jeder Teilnehmer einen Audioundeinen Videostrom versendet. Jedem einzelnen Strom ist eine eindeutige SSRCzugeordnet, hingegen ändert sich der CNAME nicht mit dem Medienstrom, sondernidentifiziert das End-System. Dadurch können zusammengehörige Medienströme erkanntwerden.3. Die ersten zwei Aufgaben verlangen von allen Teilnehmern das Versenden von RTCP-Paketen. Dies kann in größeren Konferenzen dazu führen, das die RTCP-Pakete einenwesentlichen Teil der verwendeten Bandbreite einnehmen. Um dies zu verhindern,ist ein adaptives Verhalten der End-Systeme notwendig. Anhand der empfangenenRTCP-Pakete muß ermittelt werden, welche RTCP-Informationen und wie oft dieseversendet werden müssen. Der aktuelle Internet-Draft definiert eine Funktion, die berechnet,in welchen Intervallen die RTCP-Pakete zu versenden sind. Werte wie Anzahlder Teilnehmer und Sender und verlorengegangene Pakete werden eingesetzt, um dasZeitintervall für das nächste RTCP-Paket zu berechnen.4. Eine weitere Aufgabe, die als optional definiert ist, besteht in der Versendung von zusätzlichenTextinformationen über die teilnehmenden Benutzer. Anwendungen könnendiese Daten nutzen, um eine Teilnehmerliste anzuzeigen. Enthalten sind z.B. derreale Name, Telefonnummer, E-Mail-Adresse und der CNAME.Für die in den Aufgaben genannten Informationen ist in RTCP ein mehrstufiges Paketformatdefiniert. Jedes einzelne RTCP-Paket beginnt mit einem Kopf fester Größe gefolgt vonstrukturierten Nutzinformationen, deren Länge variabel ist. Die Gesamtlänge eines Paketesmuß einem Vielfachen von 32 Bit entsprechen. Solche Pakete werden in der Regel als einVerbund versendet, indem sie direkt hintereinander geschrieben werden. Zusätzliche Informationensind in einem Verbund nicht enthalten. Die Anzahl der enthaltenen Pakete mußdurch die Längenangabe der darunterliegenden Schicht ermittelt werden.Wie RTP-Pakete werden auch RTCP-Pakete anhand eines Payload-Typs identifiziert. DieserPayload-Typs hat andere Werte und Bedeutungen als der Payload-Typ der RTP-Pakete. Definiertwird mit diesem Typ die Art des Paketes. Daraus können Aufbau und Informationsgehaltabgeleitet werden. Im RFC 1889 sind fünf dieser Typen definiert, die im folgendenbeschrieben werden.Empfänger-Berichte (Receiver-Reports, RR)Die als Empfänger-Bericht bezeichneten Pakete werden von allen passiven Teilnehmernder RTP-Session gesendet. Dazu zählen Teilnehmer, die selbst keine RTP-Pakete erzeugen.RTCP-Pakete dieses Typs sind wie in Abbildung 2.5 aufgebaut. Das Pakete beginnt mit einemKopf fester Länge. Das Feld PT enthält den RTCP-Payload-Typ. Anschließend an denKopf folgt eine Liste von Blöcken, die jeweils aus sechs 32-Bit-Worten bestehen. Darin enthaltensind Informationen über die einzelnen Quellen, von denen seit dem letzten BerichtMediendaten empfangen wurden. Im Feld RC ist die Anzahl der Bericht-Blöcke eingetragen,wobei auch null ein zugelassener Eintrag ist.10 Damit können Quellen auch nach einer Kollision (von gleichen SSRCen) oder einem Neustart identifiziertwerden.

14 Kapitel 2. BasistechnologienDie Bericht-Blöcke enthalten Informationen über die Anzahl der Paketverluste, den Jitterder empfangenen Pakete und Zeitangaben zum letzten empfangenen Sender-Bericht derbeschriebenen Quelle.0 16 32V=2 P RC PT=RR=201 LängeSSRC des SendersHeaderSSRC_1 (erster SSRC)Verlust: Bruchteilinsgesamt verlorene Paketeerweiterte SequenznummerJitter der Ankunftszeitenletzter Sender−ReportVerzögerung letzter Sender−ReportSSRC_2 (zweiter SSRC)...Empfänger−Report 1Empfänger−Report 2profil−spezifische ErweiterungAbbildung 2.5.: RTCP-Empfänger-BerichtSender-Berichte (Sender-Reports, SR)Sender-Berichte werden von den aktiven Teilnehmern einer RTP-Session verschickt. Diessind alle Teilnehmer, die selbst Medienströme erzeugen. Der Aufbau ähnelt dem Empfänger-Bericht, enthält aber einen weiteren Block von fünf 32-Bit-Worten. Dieser beinhaltet Informationenüber die Quelle, wie in Abbildung 2.6 zu sehen ist. Die folgenden zwei 32-Bit-Worte sind ein Zeitstempel, wie er aus NTP (Network Time Protocol, RFC 1305 [37])bekannt ist. Damit wird der Sendezeitpunkt des Berichtes festgelegt. Der RTP-Zeitstempelbeschreibt den selben Zeitpunkt. Die verwendete Einheit ist Sample und verhält sich wieder aus RTP bekannte Zeitstempel. Mit den beiden Zählern wird die Anzahl der versendetenPakete bzw. Bytes festgehalten.Quellbeschreibungen (Source-Description, SDES)Die bisher beschriebenen RTCP-Pakete liefern Informationen zu den versendeten bzw. empfangenenMedienströmen. Die SDES-Pakete hingegen enthalten Informationen über dieRTP-Quellen eines Medienstroms. Im Normalfall ist nur eine Quelle an einem Medienstrombeteiligt. Im Abschnitt 2.2.4 wird genauer auf die Fälle eingegangen, bei denen mehrereQuellen an einem Medienstrom beteiligt sind.Zur Angabe von Informationen über eine Quelle sind acht verschiedene Elemente definiert.Diese Elemente werden nach vordefinierten Regeln in einem RTCP-Paket verpackt.Das wichtigste Element ist der CNAME (Canonical Name), der zur Identifikation einer Quelledient. Der CNAME ist eindeutig und ändert sich nicht.

2.2. RTP und RTCP 150 16 32V=2 P RC PT=SR=200 LängeSSRC des SendersHeaderNTP−Zeitstempel, höherwertiges WortNTP−Zeitstempel, niederwertiges WortRTP−ZeitstempelSender−InformationenAnzahl der gesendeten PaketeAnzahl der gesendeten BytesSSRC_1 (erste SSRC)...Empfänger−Report 1profil−spezifische ErweiterungAbbildung 2.6.: RTCP-Sender-BerichtVier der Elemente geben genauer Auskunft über den menschlichen Benutzer und sind auchnur von ihm zu interpretieren. NAME, EMAIL, PHONE und LOC sind die Bezeichnungendieser Elemente. Da es sich hierbei um Informationen handelt, die auf die Funktionsweisekeinen Einfluß haben, sind diese Elemente optional. Das Format der Inhalte ist der Anwendungfreigestellt. Ein Überblick zu allen definierten Beschreibungselementen ist der Tabelle2.2 zu entnehmen.ElementCNAMENAMEEMAILPHONELOCBeschreibungDieses Element enthält eine eindeutige Bezeichnungdes End-Systems. Der Aufbau des CNAME istdefiniert als „user@host“, wodurch die Eindeutigkeitgewährleistet werden soll. Ist der Benutzernamenicht ermittelbar 11 , so läßt die Definition desRFCs es zu, daß nur der Name des Rechners eingesetztwird.Dieses Element enthält den realen Namen eines Benutzers.Die hier eingetragene E-Mail-Adresse kann verwendetwerden, um mit dem Teilnehmer der Konferenzüber ein anderes Medium Kontakt herzustellen.Um die Möglichkeit zu haben, einen Teilnehmerüber das herkömmliche Telefonnetz zu erreichen,kann dieses Element eine Telefonnummer enthalten.Dieses Element kann Informationen zum Standorteines Teilnehmers enthalten.weiter ⊲11 Manche Betriebssysteme bieten diese Information nicht, da es bei ihnen das Konzept verschiedener Benutzernicht gibt.

16 Kapitel 2. BasistechnologienElementTOOLNOTEPRIVBeschreibungUm eventuell fehlerhafte RTP-Implementierungenidentifizieren zu können, kann dieses Element benutztwerden. Eingetragen wird in dieses Elementder Name der RTP-Anwendung. Optional kann dazudie Version angegeben werden.Kann eine Beschreibung des aktuellen Status derQuelle enthalten. Diese Information soll im Wechselmit dem CNAME versendet werden. Ebenso kanndieses Element benutzt werden, um den Titel einesVortrags zu verbreiten.Dieses spezielle Element kann für frei definierbareQuellbeschreibungen genutzt werden. Dabei bestehtjede Erweiterung aus einem frei wählbarenNamen und dem zu gehörigen Inhalt.Tabelle 2.2.: Liste der SDES-ElementeSDES-Pakete werden wie in Abbildung 2.7 zusammengesetzt. Im Feld SC des Kopfes ist dieAnzahl der SDES-Einheiten eingetragen. Jede dieser Einheiten beschreibt exakt eine Quelleund besteht aus einer Liste von SDES-Elementen, denen die SSRC bzw. CSRC vorangestelltist.0 16 32V=2 P SC PT=SDES=202LängeSSRC_1/CSRC_1SDES−Element...SSRC_2/CSRC_2SDES−Element...HeaderEinheit 1Einheit 2Abbildung 2.7.: RTCP-QuellbeschreibungenEin SDES-Element entspricht der Abbildung 2.8. In den ersten 8 Bit wird der Element-Typ eingetragen. Die nächsten 8 Bit enthalten die Länge des Elements exklusive der erstenzwei Bytes. Beendet wird die Liste mit mindestens einem terminierenden Null-Byte. WeitereNull-Bytes werden angefügt, wenn die Länge nicht einem Vielfachen von 32 Bit entspricht(diese Bytes sind nicht mit den Padding-Bits im RTP-Kopf gleich zu setzen).0 16SDES−Typ LängeInhalt ...Abbildung 2.8.: RTCP-SDES-Element

2.2. RTP und RTCP 17Abschied (BYE)Das BYE-Paket wird verwendet, um explizit mitzuteilen, daß eine oder mehrere Quellennicht mehr an der Konferenz teilnehmen. Optional kann in das Paket ein Grund eingetragenwerden, der zu einem vielleicht ungewollten Abbruch geführt hat. Wird einer angegeben,beginnt dieser mit einem 8-Bit-Feld für die Längenangabe und wird mit mindestens einemNull-Byte abgeschlossen. Entspricht die Länge des Paketes keinem Vielfachen von 32-Bit-Worten , wird ein Null-Byte angehängt (dies ist nicht mit den Padding-Bits im RTP-Kopfgleich zu setzen). Nach dem Paket-Kopf folgt eine Liste von SSRC/CSRC-Kennungen derQuellen, die sich mit diesem Paket aus der RTP-Session verabschieden.0 16 32V=2 P SC PT=BYE=203LängeSSRC/CSRC...HeaderSSRC/CSRC−ListeLängeGrund für Abschied... (optional)Abbildung 2.9.: RTCP-BYE-PaketAnwendungserweiterung (Application, APP)Dieser Typ von RTCP-Paketen ist nur für die experimentelle Entwicklung von neuen Fähigkeitenund nicht für den dauerhaften Einsatz gedacht. Der Kopf für jedes RTCP-Paket wirdhier ebenfalls eingesetzt. Die fünf Bits direkt hinter dem Padding-Bit haben bei diesemPaket eine spezielle Bedeutung. Während dieses Feld bei allen anderen Paketen als Zählerausgelegt wird, dient es in diesem Fall als numerische Kennung für den Typ des APP-Paketes.Nach dem Paket-Kopf folgt die SSRC bzw. CSRC der Quelle des Paketes. Das folgende 32-Bit-Feld beinhaltet einen numerischer Bezeichner, der im Kontext der Anwendung definiertist. Optional können an dieser Stelle beliebige Daten folgen, die auf ein Vielfaches von 32Bit aufgefüllt werden müssen.0 16 32V=2 P Typ PT=APP=204LängeHeaderSSRC/CSRCNameDaten... (optional)Abbildung 2.10.: RTCP-Anwendungserweiterung2.2.4. Translator und MixerViele Konferenzen in IP-basierten Netzen nutzen die Fähigkeit der Gruppenadressierung.Damit der Einsatz dieser Technik möglich ist, müssen alle involvierten Router der Netze,in denen sich die Teilnehmer befinden, Multicast-Routing unterstützen. 12 Dies ist leider12 Bei nicht benachbarten Netzen sind auch die Router zwischen den Netzen gemeint.

18 Kapitel 2. Basistechnologiennicht der Normalfall 13 , so daß manchen Benutzer die Teilnahme an Konferenzen verwehrtbleibt. Genauso können teilweise Benutzer hinter einer Firewall nicht an Konferenzen teilnehmen.Im RFC 1889 werden zwei funktionale Komponenten definiert, die zur Lösungsolcher Probleme verwendet werden können. Dabei werden Methoden definiert, um Kodierungsverfahrenanzupassen und die Medienströme mehrerer Teilnehmer zu mischen.Bevor eine Konferenz aufgesetzt werden kann, ist die Bestimmung der Kodierungsverfahrenfür die Medienströme erforderlich. Zur genauen Spezifikation eines Medienstroms reichtdie Angabe eines Kodierungsverfahrens nicht aus. Zusätzlich müssen je nach Art des Verfahrensweitere Parameter definiert werden. Beschreibungen von Kodierungsverfahren inklusivefestgelegter Parameter und jeweils einem zugeordneten registrierten Payload-Typsind in RFC 1890 definiert. Das als RTP/AVP bezeichnete Profil umfaßt 27 verschiedenePayload-Typen. Durch die Registrierung bei IANA sind für die Kodierungsverfahren symbolischeBezeichner definiert, die in anderen Protokollen eingesetzt werden können, wie z.B.in SDP (siehe Abschnitt 2.5). Neue Profile für RTP werden in weiteren RFCs definiert, wiez.B. im RFC 2032 [56] „RTP Payload Format for H.261 Video Streams“ und RFC 2198 [42]„RTP Payload for Redundant Audio Data“.Probleme bei der Wahl des richtigen Kodierungsverfahrens können dann auftreten, wennan der Konferenz Benutzer mit Netzanbindungen stark unterschiedlicher Bandbreite undQualität teilnehmen. Bei höherer Klang- bzw. Bildqualität ist in der Regel auch die Mengeder zu transportierenden Daten größer.Die Wahl eines Kodierungsverfahrens mit geringer Bandbreite in einer Konferenz mit nurwenigen Teilnehmern, die über eine Anbindung mit geringer Kapazität verfügen, ist eineinakzeptable Lösung für die anderen Teilnehmer. In Multimedia-Konferenzen, bei denenVideo- und Audioströme übertragen werden, bleibt manchen Benutzern nur die Wahl zwischeneinem der beiden Medienströme, da ihre zur Verfügung stehende Bandbreite nichtfür beide ausreicht. Solche Lösungsansätze für das Problem sind nicht zufriedenstellend.Eine andere Möglichkeit der Lösung bieten Konferenzen mit einer zentralen Einheit. Dieseals Konferenz-Zentrale bezeichnete Instanz übernimmt die Umwandlung von Kodierungsverfahrensowie das Mischen von einzelnen Medienströmen. Alle Teilnehmer kommunizierennur über die Zentrale miteinander. 14 Diese bündelt die Medienströme der Teilnehmerso, daß jeder nur einen Strom empfängt. Enthalten ist darin ein Produkt aus allen Medienströmender anderen Teilnehmer. Obwohl jeder Teilnehmer nur mit einer Instanz kommuniziert,empfängt er die Daten aller Teilnehmer. Eingesetzt werden kann diese Technik inallen Multimedia-Konferenzen. Nachteil daran ist die zentrale Instanz, die bei einem Ausfalldie Konferenz beendet.Die beiden funktionalen Komponenten Translator und Mixer, die im RFC 1889 definiertwerden, sollen die Lösung solcher Probleme unterstützen.Ein Translator leitet empfangene RTP-Pakete an andere Teilnehmer einer Konferenz weiter.Dabei kann der Translator die Medienströme beeinflussen, indem er z.B. das Kodierungsverfahrenverändert, bevor er die Pakete versendet. Unabhängig von der angewendetenTechnik wird die SSRC das Paketes vom Translator dabei nicht verändert.Wenn durch die Veränderung der Kodierung die Paketanzahl beeinflußt wird, müssenneue Sequenznummern und RTP-Zeitstempel erzeugt werden. Somit sind die Aufgabeneines Translators wie folgt definiert:13 Zumindest in Deutschland ist es nicht selbstverständlich, daß ein Internet Service Provider Multicast zurVerfügung stellt.14 Dies ist ein vereinfachter Fall. Es können z.B. auch Multicast-Konferenzen mit Brücken verbunden werden.

2.3. MEGACO-Protokoll 19• Weiterleiten von empfangenen RTP- und RTCP-Paketen einer Quelle.• Ändern der Kodierung von Mediendaten.• Anpassen der RTCP-Informationen eines veränderten RTP-Stroms.Ein Mixer empfängt RTP-Pakete und ändert gegebenfalls die Kodierung, kombiniert bzw.teilt Medienströme auf und leitet sie an ausgewählte Teilnehmer weiter. Da die eingehendenMedienströme nicht miteinander synchronisiert sind, muß der Mixer das Timingder Ströme anpassen, bevor sie gebündelt werden können. Aus diesem Grund istder Mixer selbst eine aktive Quelle mit einer eigenen SSRC. Die ursprünglichen Quellender Ströme werden dabei in die CSRC-Liste der RTP-Pakete eingetragen. Sollteder Mixer selbst aktiv an einem der Ströme beteiligt sein, so muß auch die SSRC desMixers in die Liste der beteiligten Quellen eingetragen werden. Die Aufgaben einesMixers sind wie folgt definiert:• Empfangen von RTP- bzw. RTCP-Paketen von einer oder mehreren Quellen.• Weiterleiten von RTP-Strömen.• Ändern des Kodierungsverfahren einzelner RTP-Ströme.• Kombinieren bzw. Aufspalten von Medienströmen.Diese beiden logischen Funktionen können das Kodierungsverfahren der transportiertenMediendaten ändern. Dementsprechend müssen auch die RTCP-Pakete korrigiert werden,um die Statistiken den veränderten RTP-Paketen anzupassen.Ein Translator läßt RTCP-Pakete der Typen SDES, BYE und APP unverändert und schicktsie an ihren Bestimmungsort. Bei den Sender-Berichten muß die Anzahl der versendetenBytes korrigiert werden. Sollten dabei auch RTP-Pakete kombiniert bzw. aufgeteilt werden,so wird auch die Anzahl der versendeten Pakete korrigiert. Genauso kann es dadurchnotwendig sein, die RTP-Zeitstempel dem neuen Timing anzupassen. In den Blöcken derEmpfänger-Berichte müssen die Informationen über verlorengegangene Pakete und Abweichungenbeim Empfang angepaßt werden.Ein RTP-Mixer behandelt SDES- und BYE-Pakete genauso wie ein Translator und verschicktsie unverändert weiter. Die Behandlung von APP-Paketen ist abhängig von der jeweiligenAnwendung und wird von der Spezifikation nicht vorgeschrieben. Die Sender- undEmpfänger-Berichte werden vom Mixer komplett neu aufgesetzt, da in kombinierten Medienströmenneue Parameter gelten. Da ein Mixer selbst eine SSRC ist, müssen auch eigeneSender-Informationen generiert werden. Die Blöcke eines Empfänger-Berichts, die der Mixererzeugt, werden nur an die jeweils zugehörige Menge von Teilnehmern weitergeleitet,d.h. an die Teilnehmer, die an dem empfangenen Medienstrom beteiligt waren.Funktionale Komponenten, wie der Translator und der Mixer, stellen für die Multimedia-Kommunikation in paketvermittelten Netzen im Zusammenhang mit RTP und RTCP grundlegendeTechnologien zur Verfügung. Diese sind für das weitere Verständnis dieser Diplomarbeitsehr wichtig.2.3. MEGACO-ProtokollMit dem Dokument „Simple Gateway Control Protocol (SGCP) 1.0“, welches im Mai 1998veröffentlicht wurde, war eine neuartige Architektur für IP-Telefonie-Gateways eingeführt

20 Kapitel 2. Basistechnologienworden. Neu war die Trennung zwischen dem Modul zur Anrufsignalisierung und -steuerungund dem Media-Prozessor, der nur für die Verarbeitung der Medienströme zuständigist. MGCP (Media Gateway Control Protocol), ein Nachfolge-Protokoll von SGCP, hat sichnicht durchgesetzt. Grund dafür könnte die Spezialisierung auf Verbindungen zwischendem herkömmlichen Telefonnetz und einem paketvermittelten Netz sein. Desweiteren istdie Definition der Methode zur Meldung von aufgetretenen Ereignissen auf den nordamerikanischenRaum zugeschnitten.MEGACO (Media Gateway Control) ist in einer Kooperation der Working Group „Megaco“der IETF und der Study Group 16 der ITU-T entstanden. Das Resultat der Arbeit ist eineSynthese aus einigen Vorgänger-Protokollen wie z.B. MGCP, IDCP (IP Device ControlProtocol) und MDCP (Media Device Control Protocol).Im November 2000 hat die Working Group „Megaco“ den RFC 3015 [9] mit dem Titel„Megaco Protocol Version 1.0“ veröffentlicht. Die ITU-T Study Group 16 hat die Arbeitals Empfehlung H.248 herausgegeben. Inhalt dieser Dokumente ist die Beschreibung einerArchitektur für ein Media-Gateway (MG) und die Spezifikation eines darauf abgestimmtenProtokolls zur Kommunikation zwischen dem MG und einer zugehörigen Steuereinheit,dem Media-Gateway-Controller (MGC). Im folgenden Abschnitt werden beide Bestandteilevon MEGACO beschrieben.Architekturelle Anforderungen und grundsätzliche Voraussetzungen für MEGACO sind inRFC 2805 [16] beschrieben. Dabei werden Themen wie z.B. Ressourcen-Reservierung undKonferenz-Management im Media-Gateway, Signal- und Ereignisverarbeitung, Qualität derDienste, Fehlerbehandlung und Anforderungen an die Transportschicht ausführlich behandelt.Ein konkretes Anwendungsprofil für ein Media-Gateway zum Einsatz in der IP-Telefoniewurde von der IETF im Januar 2001 als RFC 3054 [2] unter dem Titel „Megaco IP PhoneMedia Gateway Application Profile“ veröffentlicht. Dabei wurde speziell darauf geachtet,die Integration des Media-Gateways in die vorhandenen IP-Telefonie-Systeme zu ermöglichenund die Definitionen von MEGACO zu beachten.2.3.1. ArchitekturDie verschiedenartigen Netze, aus denen das Internet zusammengesetzt ist, müssen durchspezielle Rechner miteinander verbunden werden. Um netzübergreifend Dienste anbietenzu können, werden Gateways eingesetzt, die für den jeweiligen Dienst die Übersetzungübernehmen. Einer dieser Dienste ist die Telefonie. Gateways, die zwischen einem herkömmlichenleitungsvermittelten und einem paketvermittelten Netz, wie dem Internet, eingesetztwerden, können Gespräche über diese Grenze vermitteln. Die dabei zu erfüllendenAufgaben lassen sich in funktionale Bestandteile gliedern. Diese Möglichkeit der Gliederunghat zur Trennung der einzelnen Funktionen in eigenständige Komponenten geführt, diewie in Abbildung 2.11 dargestellt, miteinander kooperieren. Das Signalisierungs-Gatewayübernimmt die Anrufsteuerung und -signalisierung zwischen dem herkömmlichen Telefonnetzund dem IP-Netz. Innerhalb des IP-Netzes vermittelt der Media-Gateway-Controllerden Anruf an den entsprechenden Endpunkt weiter. Um die Medienströme zwischen denunterschiedlichen Netzen zu transportieren, wird ein Media-Gateway vom Media-Gateway-Controller initialisiert und konfiguriert. Je nach Konstellation können auch mehrere Gatewayseiner Art involviert sein. Wird beispielsweise ein Telefonat, dessen Teilnehmer sich inleitungsvermittelten Netzen befinden, durch IP-Netz geschleust, so wird an jeder der beidenGrenzen die Kombination von Signalisierungs-Gateway, Media-Gateway-Controller sowie

2.3. MEGACO-Protokoll 21Media-Gateway zur Vermittlung eingesetzt.SGSignalisierungs−GatewayMGCMedia−Gateway−ControllerMGCMedia−Gateway−ControllerISDNPSTNGSMSIP−EndpunktH.323−EndpunktMedienströmeAnrufsignalisierungMedia−Gateway Steuer−ProtokollMGMedia−GatewayMGMedia−GatewayAbbildung 2.11.: MEGACO – Verbindung zum herkömmlichen TelefonnetzDie Aufgaben des Media-Gateways sind die Weiterleitung und geeignete Umsetzung vonMedienströmen sowie die Verwaltung der benötigen Ressourcen. Dabei wird auch der Transportüber Netze mit unterschiedlichen Protokollen der Vermittlungschicht unterstützt. Hiermitwerden nicht nur verschiedene paketvermittelte Netze angesprochen, sondern auchleitungsvermittelte Netze, so daß z.B. Vermittlungen zwischen einem IPv4-Netz und undeinem ISDN-Anschluß möglich sind. Das Gateway kann die Fähigkeiten besitzen, AudioundVideodaten zu verarbeiten sowie auf T.120 15 basierende Konferenzen zu integrieren.Ebenso können lokal vorbereitete Mediendaten (z.B. Ansagetexte für Anrufbeantworter)abgespielt werden.Der Media-Gateway-Controller ist die intelligente Steuerungseinheit für eine Gruppe vonMedia-Gateways. Zuständig für die Initialisierung und Konfiguration der Media-Gatewaysmuß die Steuereinheit auch die Verteilung der Konferenzen auf einzelne Media-Gatewayszur Lastverteilung vornehmen. Da die Umwandlung von Kodierungsverfahren sowie dieBündelung von mehreren Medienströmen rechenintensive Aufgaben sind, kann ein Media-Gateway mit einer Konferenz ausgelastet sein, so daß eine weitere Konferenz das Media-Gateway überlasten würde. Aus diesem Grund muß die Steuereinheit über die Verteilungder einzelnen Konferenzen aufgrund der noch vorhandenen Ressourcen der Media-Gateways entscheiden. Daraus folgend ist eine weitere Aufgabe des Media-Gateway-Controllerdas Erzeugen sowie Freigeben von Ressourcen einer Konferenz.MEGACO verwendet das Modell der funktionalen Trennung als Basis. Dabei gibt es eineSteuereinheit, den Media-Gateway-Controller, und eine beliebige Menge von Media-Gateways, wie es in Abbildung 2.12 veranschaulicht wird. Grund für diese Aufteilung istdie Komplexität der jeweiligen Aufgaben. Der Transport von Medienströmen sowie eventu-15 Bezeichnet eine Serie von Empfehlungen der ITU-T [25]. Diese definiert eine Konferenzarchitektur, basierendauf weiteren Empfehlungen der ITU-T wie z.B. Konferenzsteuerung (T.124) und Mehrpunktkommunikation(T.122,T.125).

22 Kapitel 2. Basistechnologienelle Korrekturen der Kodierungsverfahren und Mischen mehrerer Medienströme sind sehrrechen- und damit zeitaufwendige Vorgänge. Die Anrufsignalisierung bedarf zwar einerausgereiften Verwaltungsfunktionalität, ist aber keine rechenintensive Aufgabe. Nach außenbildet der Media-Gateway-Controller mit den zugehörigen Media-Gateways eine Einheit,d.h. Dienste werden nur von dem Media-Gateway-Controller zur Verfügung gestellt,für deren Abarbeitung die Media-Gateways eingesetzt werden. Die beschriebene Architekturbefaßt sich mit dem Aufbau eines Media-Gateways, die Voraussetzung für die korrekteFunktionsweise des Protokolls ist.MGCMGMGMGAbbildung 2.12.: Trennung zwischen Steuereinheit und Media-ProzessorDie wichtigsten Elemente dieses Modells sind die Terminationen und Kontexte. Endpunkte,die in einer Konferenz beteiligt sind, werden durch Terminationen repräsentiert. Dieempfangenen Medienströme werden an die entsprechenden Terminationen der Konferenzweitergeleitet. Um diese Zuordnung treffen zu können, werden Terminationen einer Konferenzin einem Kontext zusammengefaßt. Während die Terminationen alle Parameter bezüglichder Medienströme verwalten, ist der Aufgabenbereich des Kontextes die Steuerungder Konferenz. Ein Beispiel für eine Anordnung von Terminationen in einem Kontext ist inAbbildung 2.13 zu sehen.Media GatewayContextTerminationTelefon−verbindungTerminationRTP−StromTerminationTelefon−verbindungAbbildung 2.13.: VerbindungsmodellTerminationEine Termination ist eine logische Einheit in einem Media Gateway. Diese verwaltet einbzw.ausgehende Medienströme. Beschrieben wird eine Termination in diesem Modell durcheine Menge von Eigenschaften, die in Deskriptoren zusammengefaßt sind. Deskriptorenwerden bei den definierten Kommandos als Parameter eingesetzt. Eine Liste der möglichenDeskriptoren inklusive einer kurzen Beschreibung ist in der Tabelle 2.4 zu finden. Genauso

2.3. MEGACO-Protokoll 23wie ein Kontext wird eine Termination durch eine eindeutige Kennung identifiziert, durchdie TerminationID. Diese wird bei Erzeugung der Termination erstellt.Grundsätzlich gibt es zwei Arten von Terminationen, die durch ihre zugehörige Medienquelleunterschieden werden. Einerseits sind dies permanent existierende Quellen. Ein Beispielfür solch eine Quelle ist ein ISDN B-Kanal. Diese Quellen stehen für Konferenzanbindungenzur Verfügung, solange die Verbindung gehalten wird. Die andere Art von Terminationenrepräsentiert eine flüchtige Quelle. Diese existieren nur solange, wie sie verwendet werden.Ein Beispiel hierfür ist ein RTP-Strom.Die flüchtigen Terminationen werden durch das Kommando Add erzeugt und mittels desKommandos Subtract freigegeben. Im Gegensatz dazu werden Terminationen, die physikalischvorhandene Geräte repräsentieren, durch das Kommando Add aus einer Art Ruhestandgeholt und mit Subtract wieder hineinversetzt.Um spezielle Töne (z.B. DTMF, Frei- und Besetzt-Zeichen), d.h. deren Audio-Informationen,in Medienströme zu integrieren, können Signale definiert werden, die eine Beschreibungdieser Töne enthalten. Ebenso kann es von Interesse sein, empfangene Medienströme aufsolche Signale hin zu untersuchen. Dafür sind in MEGACO Ereignisse definiert, die beimAuftreten eines Signals ausgelöst werden. Dabei wird der Media-Gateway-Controller mittelseiner Nachricht über das Ereignis informiert.Für einen Medienstrom wird im Normalfall ein Kanal bereitgestellt, an dem die Fragmente16 nacheinander abgeholt werden können. In speziellen Fällen können Medienströmeauch auf mehrere Kanäle verteilt und damit parallel übertragen werden. Die EmpfehlungH.221 [28] der ITU-T beschreibt eine Methode zur Aufspaltung von Medienströmen ineine Anzahl von digitalen Kanälen mit einer Übertragungsrate von 64 kbit/s. Diese Artvon Verbindung würde von dem Modell wie folgt behandelt werden. Für jeden der Datenkanälewird eine eigene Termination initiiert. Eine zusätzliche Termination, die Multiplex-Termination, vereinigt die Teile zu einem Gesamtstrom. Dieser kann wiederum mit anderenTerminationen in dem Kontext verbunden werden.Die TerminationID wird bei der Erstellung eines Termination-Objektes von dem Media-Gateway kreiert. Die TerminationID kann von dem Gateway nach einer vordefiniertenStruktur aufgebaut werden, z.B. kann der Name des Anschlusses, gefolgt von einer Nummer,enthalten sein. Genau zwei Wildcards können auf die Kennung angewendet werden:ALL und CHOOSE. Die erste Variante wählt alle innerhalb das angegebenen Kontexts existierendenTerminationen aus. Die zwei Variante CHOOSE spezifiziert eine einzige, beliebiggewählte Termination. Ein Kommando, welches als Ziel die TerminationID ALL spezifiziert,hat denselben Effekt wie die Wiederholung des Kommandos mit allen gültigen Kennungender aktuell vorhandenen Terminationen. Bei manchen Konfigurationen mag es von Vorteilsein, wenn mit einem Kommando alle Terminationen des Gateway angesprochen werdenkönnen. Für diesen Fall wurde die Root-Termination definiert. Wird ROOT als Ziel desKommandos für die TerminationID angegeben, wird das Kommando auf alle existentenTerminationen angewendet. Hier besteht jedoch die Einschränkung, daß Signale auf diesespezielle Termination nicht angewendet werden können.16 Der Begriff Fragment bezeichnet die einzelnen Teile eines Medienstroms, die in RTP-Paketen transportiertwerden.

24 Kapitel 2. BasistechnologienKontextEin Kontext ist ein Verbund einer beliebigen Anzahl von Terminationen. Beschrieben wirddabei die Kommunikation unter den Terminationen, d.h. wer wen sieht bzw. wer wen hört.Durch ein Attribut des Kontextes kann beschrieben werden, wie die Medienströme innerhalbdes Kontextes bearbeitet werden sollen, d.h. es können z.B. Medienströme nur an bestimmteTerminationen weitergeleitet oder mehrere Medienströme gemischt werden, bevorsie an eine Termination übergeben werden.Ein weiteres Attribut ist die ContextID anhand der ein Kontext bei allen anwendbarenKommandos identifiziert wird. Als eine dritte Eigenschaft kann einem Kontext eine Prioritätzugeordnet werden. Damit kann bei der parallelen Bearbeitung von mehreren Kontextendie Reihenfolge festgelegt werden.In dem Modell existiert ein spezieller Kontext, der NULL-Kontext, in dem Terminationen liegen,die noch keine Beziehungen zu anderen Terminationen haben. Die Zugehörigkeit zumNULL-Kontext ist für eine Termination keine Einschränkung bezogen auf die Veränderungder Parameter. Auch der Empfang von Ereignissen ist für diese Terminationen möglich.Im Normalfall existiert nach dem Modell ein Kommando Add, mit dem Terminationen zueinem Kontext hinzugefügt werden können. Wird beim Aufruf dieses Kommandos vomMedia-Gateway-Controller der optionale Parameter eines Kontexts nicht angegeben, kreiertdas Media-Gateway einen neuen. Um Terminationen zu entfernen, wird das KommandoSubtract verwendet. Ebenso gibt es die Möglichkeit, mittels des Kommandos Move eineTermination von einem Kontext in einen anderen zu bewegen. Dabei muß sichergestelltsein, daß Terminationen nur in einem Kontext existieren. Wird aus einem Kontext die letzteTermination gelöscht, wird auch der Kontext entfernt, und die dafür belegten Ressourcenfreigegeben.Die maximale Anzahl von Terminationen pro Kontext hängt von dem Media-Gateway ab.Werden nur Punkt-zu-Punkt Verbindungen unterstützt, so ist damit die Anzahl auf zwei beschränkt.Werden Mehrpunkt-Verbindungen unterstützt, können auch drei oder mehr Terminationenpro Kontext zugelassen werden.PackageIn einem Media Gateway können Terminationen mit unterschiedlichsten Charakteristikenimplementiert sein. Um die Funktionalität von Terminationen zu erweitern bzw. zu verändern,müssen zusätzliche Eigenschaften, Ereignisse und Signale hinzugefügt werden. Fürdiese Möglichkeit sind in MEGACO Packages definiert, die eine abstrakte Definition derTerminationen ermöglichen, da die konkreten Eigenschaften spezieller Terminationen inPackages definiert werden können.Neue Packages werden in eigenen RFCs definiert und die der ITU-T in weiteren Empfehlungen.Enthalten sind in diesen Dokumenten mindestens ein Name, eine eindeutige Kennung,eine kurze Beschreibung, eine Version und die zur Verfügung gestellten Eigenschaften, Signaleund Ereignisse. Definiert das Package eine Erweiterung eines anderen, muß diesangegeben werden. Eine Registrierung bei der IANA ist nicht zwingend erforderlich.

2.3. MEGACO-Protokoll 252.3.2. ProtokollDie beschriebene Architektur bildet die Basis für das MEGACO-Protokoll zwischen Media-Gateway und Media-Gateway-Controller. Aufgabe dieses Protokolls ist die Manipulationder logischen Einheiten Kontext und Termination. Mittels der definierten Kommandos kanndas Verhalten des Media-Gateway gesteuert werden.Durch die Kooperation zwischen IETF und ITU-T ist dieses Protokoll in zwei Kodierungsartendefiniert: ASCII und ASN.1. In den Verhandlungen konnte keine Einigung bezüglichder Kodierung herbeigeführt werden. 17KommandosDer wesentliche Teil der Kommandos ist ausschließlich für den Media-Gateway-Controllerkonzipiert, um das Media Gateway zu steuern. In der Tabelle 2.3 ist eine Liste der definiertenKommandos und eine kurze Beschreibung ihrer Funktion zu finden.KommandoAddModifySubtractMoveAuditValueAuditCapabilitiesNotifyServiceChangeBeschreibungdient zum Hinzufügen einer Termination ineinen Kontext. Existiert der angesprochene Kontextnicht, wird dieser kreiert.konfiguriert die Eigenschaften, Ereignisse undSignale einer Termination.entfernt eine Termination aus einem Kontextund liefert Statistiken über die Teilnahme derTermination in dem Kontext zurück.ist eine atomare Operation, die eine Terminationin einen anderen Kontext versetzt.dient zur Abfrage von Eigenschaften, Ereignissen,Signalen und Statistiken einer Termination.erlaubt das Abfragen von möglichen Werten derEigenschaften, Ereignisse und Signale einer Termination.benachrichtigt den Media-Gateway-Controllervom Eintreten eines Ereignisses im Media-Gateway.dient zur Bekanntgabe von Änderungen im Betriebszustandeiner oder mehrerer Terminationen.Tabelle 2.3.: Kommandos zwischen MGC und MGAusnahmen bezogen auf die Kommunikationsrichtung bilden die beiden Kommandos ServiceChangeund Notify. Während das Kommando Notify nur vom Media-Gateway zumMedia-Gateway-Controller gesendet wird, kann ServiceChange von beiden Systemen verwendetwerden. Das Media-Gateway verwendet das Kommando, um dem Media-Gateway-17 Es wurde eine Münze geworfen, was zur Folge gehabt hätte, daß die ASCII-Kodierung verwendet wird. Dieswurde von der Study Group 16 nicht akzeptiert, so daß der Kompromiß geschlossen wurde.

26 Kapitel 2. BasistechnologienController mitzuteilen, daß eine Termination oder eine Gruppe von Terminationen betriebsbereitist oder den Betrieb eingestellt hat. Auch wenn ein Media-Gateway den Betriebaufnimmt, wird das Kommando ServiceChange gesendet, um eine Registrierung beimMedia-Gateway-Controller vorzunehmen. In der anderen Richtung wird das Kommandovom Media-Gateway-Controller verwendet, um eine Termination oder eine Gruppe vonTerminationen zu beenden.DeskriptorDie Verwendung der obigen Kommandos ähnelt einem Funktionsaufruf. Deskriptoren werdendem Kommando als Parameter übergeben. Diese werden ebenfalls für die Rückgabewerteder Kommandos eingesetzt. Ein Deskriptor besteht aus einem Namen, einer Kennungund einer Liste von Schlüssel-Wert-Paaren, wie es in der folgenden Zeile dargestellt ist. DasBeispiel verwendet die Text-Kodierung des Protokolls.DescriptorName={parm=value1, parm=value2.}Dabei muß zwischen drei verschiedenen Arten von Parametern unterschieden werden:Vollständig spezifiziert: Dem Parameter ist genau ein eindeutiger Wert zugewiesen, dervom Empfänger verwendet werden muß.Ungenügend spezifiziert: Der Parameter ist dem Wert CHOOSE gleichgesetzt. Das Media-Gateway wählt entsprechend seiner momentanen Ressourcen den richtigen Wert fürden Parameter aus einer vorgegebenen Menge aus.Überspezifiziert: Dem Parameter ist eine Liste möglicher Werte zugeordnet. Der Empfängermuß einen aus der Liste auswählen, wobei die Reihenfolge die Priorität des Sendersangibt.Parameter und Rückgabewerte der Kommandos sind optional. Für beide werden ausschließlichDeskriptoren eingesetzt. Sollte ein benötigter Deskriptor bei einem Kommandoaufruffehlen, so sind die zuvor verwendeten Werte des Deskriptors, falls sie vorhanden sind, weiterhingültig. Ist ein Parameter ungenügend oder überspezifiziert, muß der Empfänger inseiner Antwort den gewählten Wert in den jeweiligen Deskriptor eintragen.Das MEGACO-Protokoll spezifiziert eine Menge von grundlegenden Deskriptoren. In derfolgenden Tabelle 2.4 werden diejenigen beschrieben, die für die zu entwickelnde Architekturvon Interesse sind.Deskriptor NameMediaTerminationStateBeschreibungspezifiziert die Parameter für die Medienströmeund Verwendung der Deskriptoren TerminationStateund Stream.enthält alle Eigenschaften einer Termination,die sich nicht auf die Medienströme beziehen.Solche Eigenschaften werden in Packages definiert.Der Deskriptor beinhaltet desweiterennoch den Status der Termination sowie Informationenüber den EventBuffer.weiter ⊲

2.3. MEGACO-Protokoll 27Deskriptor NameStreamLocalControlBeschreibungsetzt sich aus LocalControl, Local und RemoteDeskriptor zusammen und beschreibt eine bidirektionaleKommunikationsverbindung.beschreibt den Modus der Termination, welcherden Fluß der Medienströme grundlegendcharakterisiert. Mögliche Werte sind send-only,receive-only, send/receive, inactive und loopback.Zusätzlich sind Informationen zur Reservierungvon Ressourcen enthalten. Ein wiederholtesSetzen des Deskriptors führt zur vollständigenErsetzung der alten Werte. Dieser Deskriptorkann in Packages definiert werden.Local charakterisiert die Medienströme, die dasMedia-Gateway von dem entfernten End-System empfängt. Wird die Text-Kodierung desMEGACO-Protokolls verwendet, so enthält dieserDeskriptor eine SDP 18 -Beschreibung.RemoteEventsEventBufferSignalsAuditPackages18 SDP ist eine Beschreibungssprache für Medienströme.ist das entsprechende Gegenstück zum LocalDeskriptor und charakterisiert die Medienströme,die das Media-Gateway an das entfernteEnd-System schickt.umschreibt Ereignisse, die vom Media-Gatewayerkannt und Aktionen, die daraufhin ausgeführtwerden sollen. Ereignisse sind z.B. Fax-Töneund das Abheben oder Auflegen des Telefonhörers.enthält Ereignisse, die erkannt werden sollen,wenn der Event-Buffering-Modus aktiviert ist.In diesem Modus werden Events zwischengespeichertund erst auf Anfrage weitergeleitet.enthält eine Liste von Signalen. Signale werdenin Packages definiert. Ein Signal kann optionaleine Zuordnung zu einem bestimmten Medienstrombeinhalten. Weitere optionale Parametersind ein Signal-Typ und eine Zeitangabezur Dauer des Signals. Der ebenfalls optionaleParameter notifyCompletion kann gesetzt werden,wenn der Media-Gateway-Controller nachAbspielen des Signales benachrichtigt werdensoll.definiert, welche Deskriptoren ein Kommandozurückgeben soll. Der Audit-Deskriptorenthält eine Liste von Deskriptoren. Es könnenauch Deskriptoren aufgelistet werden, die nichtim Aufruf des Kommandos enthalten sind.beschreibt eine Liste der von der Terminationimplementierten Packages.weiter ⊲

28 Kapitel 2. BasistechnologienDeskriptor NameDigitMapServiceChangeObservedEventsStatisticsErrorBeschreibungenthält Muster, die eine Abfolge von Ereignissenbeschreiben. Trifft eines der Muster zu, werdendie Ereignisse in Gruppen gemeldet und nichteinzeln.besagt, daß sich der Status einer Terminationgeändert. Dabei können z.B. Informationenwie Methode, Begründung, Adresse, Verzögerungund Zeitstempel angegeben werden.wird benutzt, um zu überwachende Ereignissezu melden. Eingesetzt wird der Deskriptorim Audit-Deskriptor. Angegeben zu denerkannten Ereignissen wird die Event-Kennungsowie der Zeitpunkt des Eintretens des Ereignises(in Millisekunden).enthält Informationen zu Statistiken, die von einerTermination aufgezeichnet wurden. Informationenwie der Status der Termination undgesendete bzw. empfangene Bytes gehören dazu.Weitere Statistiken werden von dem Packageder Termination definiert. Gesendet werdendie Statistiken auf jeden Fall bei der Entfernungder Termination aus dem Kontext. Mittels desAudit-Deskriptors können die Statistikenauch abgefragt werden.wird verwendet, um aufgetretene Fehler an denMedia-Gateway-Controller zu melden. DieserDeskriptor besteht aus einem von der IANA registriertenFehlercode und optional einem beschreibendenText, der möglichst informativ fürdie Fehlersuche sein soll.Tabelle 2.4.: MEGACO-DeskriptorenEin weiterer Deskriptor, der nicht in der Tabelle aufgeführt, aber für diese Arbeit von Bedeutungist, wird als Topology-Deskriptor bezeichnet. Während alle anderen Deskriptoreneiner Termination zugeordnet werden, ist dieser Deskriptor einem Kontext zuzuordnen.Beschrieben wird damit der Fluß der Medienströme zwischen den Terminationen einesKontextes. Die Standard-Topology in einem Kontext definiert, daß ein Medienstrom an alleTerminationen des Kontextes außer der Quelle weitergeleitet wird. Durch diese Definitionist die Implementierung eines Topology-Deskriptors optional.2.4. Anrufsignalisierung und -steuerungUnter anderen befassen sich IETF und ITU-T mit der IP-Telefonie. Die IETF arbeitet an demSignalisierungsprotokoll SIP (Session Initiation Protocol) während die ITU-T die H.323-Serie von Empfehlungen entwickelt.

2.4. Anrufsignalisierung und -steuerung 29Die Konferenzumgebungen definieren das Verhalten von Endpunkten und Servern. Hauptsächlichwird die Anrufsignalisierung und -steuerung betrachtet. Die dabei versendetenInformationen bestimmen den Ablauf eines Anrufs oder einer Konferenz. Hierbei sind Vorgängewie z.B. Auf- und Abbau eines Anrufes, Weiterleitung und Auffinden von Gesprächspartnerndefiniert.In den folgenden Abschnitten werden H.323 und SIP und dazugehörige Standards genauererläutert. Sie bilden die Basis für heutige IP-Telefonie.SIPDas von der Multi-Party Multimedia Session Working Group (MMUSIC) der IETF hervorgebrachteProtokoll SIP (RFC 2543 [21] und RFC 2543bis [19]) dient zum Initiieren, Ändernund Beenden von Multimedia-Konferenzen im Internet und ist Bestandteil einer IETF-Architektur für lose gekoppelte Konferenzen.Die Medienströme, die in einer Konferenz übertragen werden sollen, sind während des Verbindungsaufbausin einer Aushandlung zu bestimmen. Eingesetzt wird dafür SDP (SessionDescription Protocol, RFC 2327 [20]), das eigentlich für Mbone-Konferenzen entwickeltwurde. Die ausgehandelten Medienströme werden mittels RTP transportiert. Auf der Transportschichtwird für die Medienströme und die Signalisierung UDP eingesetzt. Alternativkönnen die Signalisierungsnachrichten auch über TCP transportiert werden.Für den Aufbau der Nachrichten hat sich SIP nach den Definitionen aus RFC 822 [8] gerichtet,in dem der Aufbau einer E-Mail-Nachricht beschrieben wird. SIP-Nachrichten sindwie eine E-Mail-Nachricht aus einem Kopf und dem Inhalt zusammengebaut, die durch eineleere Zeile voneinander getrennt sind. Desweiteren wurden die wichtigsten Felder, wie To,From, Date und Subject, aus dem Kopf übernommen.Desweiteren verwendet SIP einige Definitionen aus HTTP (Hypertext Transfer Protocol,RFC 2616 [13]). Beispielsweise werden in SIP wie in HTTP URLs (Uniform Resource Locator,[1]) zur Adressierung verwendet. Beim Kommunikations-Modell von SIP werdenvon den End-Systemen Kommandos versendet, die mit dreistelligen Antwortcodes bestätigtwerden. Die Codes sind in sechs Gruppen untergliedert, die durch die erste Ziffer unterschiedenwerden. Anhand der Gruppe wird die Art der Antwort bestimmt, dabei kann essich um zusätzliche Informationen, Erfolgsmeldungen, Weiterleitungen, Fehler des Clientsoder des Servers und allgemeine Fehler handeln. Die restlichen zwei Stellen stehen für einegenauere Beschreibungen innerhalb der Gruppe.Da eine Anrufsignalisierung vom Ablauf nicht einer Anfrage bei einem Web-Server entspricht,wurden für SIP neue Kommandos definiert. Der Aufbau ist gegenüber HTTP gleichgeblieben. Ein Anruf beginnt mit einer INVITE-Nachricht. Diese enthält eine Einladungdes Anrufers zu einem Gespräch. Wenn der Aufbau erfolgreich verläuft, wird dieser mitdem Kommando ACK des Anrufers abgeschlossen. Andernfalls wird das Gespräch mit einemCANCEL abgebrochen. Ein geregelter Abbau wird durch ein BYE eingeleitet. Ein weiteresSIP-Kommando, das für die Anrufübergabe eingesetzt wird, ist REFER. Zusätzlich existiertnoch das Kommando NOTIFY, das es ermöglicht, den Status eines End-Systems zu melden.Wie in HTTP beginnt eine URL mit einem Präfix, das das Schema der URL definiert. InSIP ist das Präfix sip. Als Trennzeichen folgt ein ’:’, nach dem wie bei einer E-Mail-Adresse Benutzername und eine Domain kommen. Alternativ kann ein Rechnername eingesetztwerden, dem optional eine Portnummer folgt. Diese muß angegeben werden, wenndie SIP-Nachrichten nicht über den Port 5060 übertragen werden. Beispiele für gültige

30 Kapitel 2. BasistechnologienSIP-Adressen sind sip:crunchy@tzi.de und unter Verwendung eines Rechnernamenssip:dolormin.informatik.uni-bremen.de:5060.SIP definiert verschiedene Arten von Servern. Diese werden anhand ihrer logischen Funktionengetrennt. Eine Kommunikation zwischen den Servern ist nicht definiert, wobei diemeisten Implementierungen die einzelnen Funktionen auf einem Rechner oder sogar ineinem einzigen Programm zusammenfassen.Redirect-Server Dies ist der einfachste SIP-Server. Seine Aufgabe ist die Auflösung vonAdressen. Im Gegensatz zu anderen SIP-Servern kann der Redirect-Server keine Anfragenweiterleiten. Diese Funktion kann ein Anrufer nutzen, um einen Gesprächspartneranhand einer URL aufzufinden.Proxy-Server SIP-Proxies übernehmen die Aufgabe eines Routers auf der SIP-Ebene. EingehendeAnrufe können an Endpunkte bzw. weitere Proxies weitergeleitet werden.Einfache Varianten dieses Servers können eingehende Anrufe nur an einen Endpunktweiterleiten. Stehen für einen Angerufenen mehrere mögliche Adressen zur Auswahl,kann ein Forking-Proxy die Nachrichten vervielfachen und an alle möglichen Zielpunkteverteilen.Location-Server Um Benutzer aufzuspüren, können Redirect-Server und Proxy-Server aufden Location-Server zurückgreifen. Seine Aufgabe ist die Ermittlung von aktuellenAufenthaltsorten von Benutzern und gegebenenfalls die Herausgabe dieser bei Anfragen.Registrar Bei diesem Server registrieren sich aktive Endpunkte. Dies ist hilfreich für denLocation-Server, um seine Aufgabe zu erfüllen. Der Zugriff auf den gemeinsamenDatenbestand ist der Grund dafür, daß bei realen Implementierungen der Registrarim Location-Server integriert ist.Ein Anruf, in den ein zustandsloser Proxy-Server involviert ist, wird in Abbildung 2.14dargestellt. Der Anrufer A verschickt die Einladung (INVITE) an den Proxy-Server. Dieserermittelt in diesem Beispiel eine mögliche Adresse für den Angerufenen und leitet dieEinladung weiter. Als Antwort kann von dem Angerufenen und dem Proxy eine MeldungTrying zurückkommen, welche signalisiert, daß der Anruf bearbeitet wird. Ebenfalls optionalist die Antwort Ringing, die von dem Proxy-Server an den Anrufer weitergeleitetwird. Nimmt der Angerufene das Gespräch an, wird dies durch die Antwort OK signalisiert,die vom Anrufer mit dem Kommando ACK bestätigt wird. Mit dieser Nachricht ist derVerbindungsaufbau abgeschlossen. Beim Abbau einer stehenden Verbindung wird ein BYEgesendet, das wiederum durch ein OK bestätigt wird.Das bisher beschriebene Modell bezieht sich auf Zwei-Punkt-Beziehungen. Die Initiierungvon Mehrpunkt-Beziehungen (Konferenzen) ist in SIP in mehreren Varianten möglich, istaber noch in der Entwicklung. Die Verwendung von Multicast ist eine mögliche Variante.Dadurch können beliebig viele Teilnehmer zu der Multicast-Konferenz eingeladen werden.Wie genau die Anrufsignalisierung für Mehrpunkt-Kommunikationen in SIP aussehen soll,ist zum aktuellen Zeitpunkt noch nicht definiert. Eine mögliche Variante ist in dem InternetDraft „SIP Call Control - Transfer“ [55] beschrieben. Genauer beschäftigt sich der Draft mitder Funktion der Anrufübergabe. Dabei wird ein Endpunkt durch das Kommando REFERangewiesen, eine Verbindung zu einem dritten Gesprächspartner aufzubauen, wie es inAbbildung 2.15 veranschaulicht wird. Der Draft schreibt nicht vor, daß die ursprüngliche

2.4. Anrufsignalisierung und -steuerung 31Abbildung 2.14.: SIP-AnrufsignalisierungAbbildung 2.15.: SIP-AnrufübergabeVerbindung beendet wird. Neuere Versionen des Drafts weisen aber daraufhin, daß diesesKommando nicht zur Initiierung von Konferenzen gedacht ist.Eine einfache Möglichkeit, eine Konferenz zwischen drei Parteien aufzubauen, ist der Einsatzeiner Konferenz-Zentrale. Dabei ruft A B an und B ruft C an. In dieser Konstellationmuß B die Medienströme von A und C mixen. Nachteil dieser Konstellation ist die zentraleStellung von B. Fällt B aus, bricht die Konferenz auseinander.Eine weitere Variante ist die vollständig vermaschte Konferenz. Bei diesem Modell bautjeder Endpunkt mit allen anderen eine Verbindung auf. Durch diese Technik existiert keinezentrale Einheit, die bei Ausfall den Ablauf der Konferenz stört. Nachteile dieser Art vonKonferenz sind die benötigte hohe Bandbreite und eine lange Phase der Anrufsignalisierung,bei der jeder mit jedem einen Anruf aufbauen muß.Alle diese Varianten, abgesehen von dem Multicast-Modell, benötigen Komponenten alszentrale Einheit oder in jedem Endpunkt, die nicht nur Medienströme transportieren können,sondern auch Transcoding und/oder Mixing zur Verfügung stellen. Mit einer generischenSchnittstelle läßt sich hier eine Komponente integrieren, die in SIP-Konferenzumgebungeneingesetzt werden kann und gleichzeitig in weiteren IP-Telefonie-Systemen sowiein Multimedia-Konferenzen in IP-basierten Netzen verwendet werden kann, um Medienströmezu transportieren und zu verarbeiten.

32 Kapitel 2. BasistechnologienH.323Die H.323-Serie [31] von Empfehlungen der ITU-T beschreibt eine Konferenzumgebungfür eng-gekoppelte Multimedia-Kommunikation in paketorientierten Netzen. Zu der Seriegehört z.B. die Empfehlung H.225.0 [29] für Paketisierung, Synchronisation und Signalisierung.Die Signalisierung wird unter zusätzlicher Verwendung von Q.931 [27] realisiert. DieEmpfehlung H.245 [30] wird für die Medienbeschreibung und -aushandlung eingesetzt.Aus ISDN bekannte Mehrwertdienste werden in den H.450-Empfehlungen [26] beschrieben.Für die Medienübertragung wird auf RTP zurückgegriffen. Alternativ kann T.120 [25]integriert werden. 19 Die Pakete der H.323-Serie werden mittels ASN.1 (Abstract SyntaxNotation One) definiert.In den herkömmlichen leitungsvermittelten Telefonnetzen können alle Endpunkte nur zwischenwenigen Kodierungsverfahren für die Mediendaten wählen. In der IP-Welt ist dieAushandlung der Medienströme umfangreicher. Durchgeführt wird sie während der Signalisierungsphasedes Anrufes. In H.323 ist definiert, daß alle Endpunkte mindestens dasKodierungsverfahren G.711 [24] für Audio-Informationen unterstützen müssen, damit eineKommunikation nicht an der Aushandlung des Kodierungsverfahrens scheitern kann.Eine Definition dieser Art existiert für die Videoübertragung nicht.Die H.323-Architektur basiert ebenso wie SIP auf zentralen Komponenten. Der Gatekeeperist für Funktionen wie Registrierung, Adressierung und die Einhaltung von Benutzungsrichtlinien(Policy) zuständig. H.323-Endpunkte registrieren sich bei einem Gatekeeper miteiner oder mehreren Alias-Adressen und einer Transportadresse, die von Anrufern bei derSignalisierung verwendet wird. Unter Verwendung dieser Informationen ist der Gatekeeperfähig, eine Adreßauflösung zur Verfügung zu stellen, die von Anrufern genutzt werdenkann. Ein Gatekeeper kann Gesprächswünsche ablehnen oder zulassen. Ein Grund für dieAblehnung kann z.B. die angeforderte Bandbreite für die Medienströme sein. Da währendeines Gespräches neue Kodierungsverfahren ausgehandelt werden können, ist die Fähigkeitdes Gatekeepers, die laufenden Gespräche zu überwachen, sinnvoll. Diese Funktionalitätkann eine Überlastung des Netzes verhindern.Trotz seiner zentralen Funktion ist der Gatekeeper eine optionale Komponente. Endpunktekönnen aber ohne einen Gatekeeper keine Adressen auflösen. Stattdessen können Transportadressenverwendet werden. Dabei wird die IP-Adresse des Ziels sowie der allgemeinbekannte Signalisierungsport 1720 20 verwendet.Ein Endpunkt kann sich bei einem Gatekeeper mit verschiedenen Arten von Adressen registrieren.Dabei ist die Zusammensetzung der Menge von Adressen beliebig, d.h. es könnenverschiedene Arten kombiniert werden und von jeder Art mehrere vorhanden sein. Der Gatekeeperregistriert den Endpunkt mit allen in seiner Datenbank bekannten Adressen. AlsArten werden u.a. H.323-Adressen und herkömmliche Telefonnummern akzeptiert. H.323-Adressen werden als URL mit dem Präfix h323 und beliebigen Zeichen als Adresse spezifiziert.Häufig gleichen solche Adressen einer E-Mail-Adresse mit einem Benutzernamenund einer Domain wie z.B. h323:crunchy@tzi.de. Telefonnummern werden durch denPräfix tel gekennzeichnet. 21Ein Anruf in einer H.323-Umgebung, an dem ein Gatekeeper beteiligt ist, kann auf verschie-19 Diese Serie von Empfehlungen kann beispielsweise für verteilte Anwendungen (Application Sharing) eingesetztwerden.20 Es kann auch ein anderer Port gewählt werden. Der Port 1720 ist Standard und wird eingesetzt, wenn keinanderer definiert ist.21 Im RFC 2806 [58] werden URL-Typen für die IP-Telefonie definiert.

2.4. Anrufsignalisierung und -steuerung 33dene Weisen abgewickelt werden. Im Gatekeeper-Routed-Call-Model fungiert der Gatekeeperals Vermittlungsstelle zwischen den Gesprächsteilnehmern. Dabei werden alle Nachrichtender Anrufsignalisierung an den Gatekeeper geschickt, der sie an den jeweiligenGesprächspartner weiterleitet. Dieses Modell gibt dem Gatekeeper die Kontrolle über denAblauf des Anrufs. Im Direct-Call-Model löst der Gatekeeper die Adresse das Angerufenenauf und gibt diese an den Anrufer zurück. Damit wird die Anrufsignalisierung direktzwischen den beiden Gesprächspartnern ausgetauscht. Über solche Gespräche hat der Gatekeeperkeine Kontrolle.In Abbildung 2.16 ist ein exemplarischer Ablauf eines Anrufaufbaus nach dem Gatekeeper-Routed-Call-Model dargestellt. Der Anrufer A holt sich zuvor die Berechtigung für diesenAnruf. Bei positiver Bestätigung wird ein Setup an den Gatekeeper geschickt, der diesan den Gesprächspartner B weiterleitet. Als Antwort schickt dieser ein CallProceeding,um die Bearbeitung des Anrufs zu signalisieren. Bevor der Anruf angenommen werdenkann, muß auch der Angerufene bei seinem Gatekeeper nach einer Berechtigung für diesenAnruf fragen und schickt ein AdmissionRequest. Nach der positiven Bestätigung desGatekeeper durch das Kommando AdmissionConfirm, muß B mit einem Alerting anA antworten, um die Annahme des Anrufes zu signalisieren. Mit dem Kommando Connectvon B wird der Aufbau des Gesprächs vollendet und die Verbindung ist aufgebaut.Abbildung 2.16.: H.323-AnrufsignalisierungDie H.323-Serie von Empfehlungen beschäftigt sich auch mit Konferenzen, in denen sichmehr als zwei Teilnehmer befinden. Zur Realisierung werden die zwei Komponenten MC(Multipoint-Controller) und MP (Multipoint-Processor) definiert. Eine MCU (Multipoint-Controller-Unit) besteht aus einem Multipoint-Controller und einer beliebigen Anzahl vonMultipoint-Processors. Die verschiedenen Arten einer Multipoint-Controller-Unit werdendurch die Fähigkeiten des verwendeten Multipoint-Processors bestimmt.Der Multipoint-Controller ist die Steuereinheit in einer Konferenz. Als Aufgabe übernimmter die Aushandlung von Eigenschaften der Endpunkte, entscheidet über den Modus derKonferenz und steuert die Allokation von Konferenz-Ressourcen. Die Funktionen für dieseAufgaben sind in der Empfehlung H.245 definiert.Die Multipoint-Processors sind für die zentrale Verarbeitung der Video-, Audio- und Datenströmezuständig. Funktionen wie Weiterleitung, Übersetzung von Kodierungsverfahrenund Mixen werden unterstützt. Gesteuert wird der Multipoint-Processor durch einenMultipoint-Controller.Eine Konferenz kann in verschiedenen Modi aufgesetzt werden. In einer zentralisierten

34 Kapitel 2. BasistechnologienKonferenz werden alle Medienströme durch eine zentrale Einheit geleitet, die die Medienströmeverarbeitet und weiterleitet. Dabei werden wenn nötig Übersetzungen in den Kodierungsverfahrensowie Mixvorgänge angewendet. Dezentralisierte Konferenzen setzen eineMulticast-Adressierung ein, um die Medienströme zu versenden. Das Mixen der einzelnenMedienströme muß in diesem Fall von den Endpunkten übernommen werden. In einemdritten Modus werden die beiden anderen vereinigt, d.h. es werden einige Medienströmeüber zentrale Einheiten geleitet und andere direkt an die beteiligten Endpunkte.2.5. MedienbeschreibungBei SIP sowie bei H.323 wird während der Anrufsignalisierung eine Medienaushandlungdurchgeführt. Dabei tauschen die Endpunkte gegenseitig ihre Fähigkeiten bezüglich derMedienkodierung aus. Abschließend wird aus der Schnittmenge ein Kodierungsverfahrenpro Medienstrom ausgewählt. Diese Aushandlung ermöglicht den Endpunkten ein Verfahrenauszuwählen, das ihre verfügbare Bandbreite nicht überschreitet. Bei breitbandigenAnbindungen ist dieses Kriterium nicht wichtig. Solche Endpunkte können sich das Kodierungsverfahrenmit dem geringsten Qualitätsverlust aus der Schnittmenge aussuchen.Um einen Medienstrom zu charakterisieren, reicht es nicht, ein Kodierungsverfahren anzugeben.Für die genaue Beschreibung sind je nach Kodierungsverfahren weitere Parameterzu bestimmen. Ein Medienstrom, der z.B. Audio-Informationen enthält und auf Samples basiert,wird zusätzlich durch die Abtastrate, die Bits pro Sample und die Anzahl der Kanälecharakterisiert.In der Medienaushandlung müssen außer einer Charakterisierung der Mediendaten auchdie Transportadressen für die Übertragung angegeben werden. Für eine bidirektionale Kommunikationwerden genau zwei Transportadressen benötigt. Eine der Adressen definiertden Zielrechner sowie den zugehörigen Port für die zu versendenden Mediendaten, unddie andere legt das lokale Interface und den Port für den Empfang eines Medienstroms fest.Die Beschreibung von Medienströmen ist nicht nur in der IP-Telefonie interessant, sondernist in allen Konferenzen in paketvermittelten Netzen nötig. Im folgenden werden Protokollevorgestellt, die sich mit der Beschreibung von Medienströmen beschäftigen. Ausgewähltwurden die Protokolle, die in SIP und H.323 eingesetzt werden. Dies sind SDP (SessionDescription Protocol) aus SIP sowie H.245 aus der H.323-Serie. Zusätzlich wird SDPng(Session Description Protocol Next Generation) beschrieben, welches der Nachfolger vonSDP werden soll.Session Description Protocol (SDP)In der SIP-Konferenzumgebung wird SDP (Session Description Protocol, RFC 2327 [20])für die Medienbeschreibung eingesetzt. Trotz der Bezeichnung Protokoll, sind in SDP keineKommunikationsvorschriften enthalten, sondern eine Beschreibungssprache, die für Mbone-Konferenzen entwickelt wurde. SDP-Nachrichten enthalten nicht nur Beschreibungen vonMedienströmen, sondern zusätzlich auch Adressen für den Transport sowie Konferenzbeschreibungen.SDP-Nachrichten sind aus Textbausteinen zusammengesetzt. Die Informationen sind in Zeilenangeordnet, welche wie Zuweisungen aufgebaut sind. Eine Zeile beginnt mit einemZeichen (Schlüssel) gefolgt von einem Gleichheitszeichen (=). Der Rest der Zeile entspricht

2.5. Medienbeschreibung 35dem zugewiesenen Wert. Im folgenden wird genauer auf die Schlüssel eingegangen, die zurBeschreibung eines Medienstroms sowie der Adressen verwendet werden.m= Diese Zeilen beschreiben einen Medienstrom. In dem Feld wird einer derWerte audio, video, application, data und control angegeben. Mit dem wird die Anwendungsadresse definiert. Für das dritte Feld sind ausschließlich die Werte RTP/AVP und udp definiert. Verwendet eine Konferenzein proprietäres Medienformat, so wird dies durch Verwendung des Wertes udpgekennzeichnet. Mit dem Wert RTP/AVP wird die folgende Liste alsRTP-Payload-Nummern aus dem RTP-Profil AVP interpretiert.a=, a=:Zeilen mit Schlüssel a definieren Attribute. Die erste Variante a= spezifiziertBool’sche Eigenschaften. Durch die Angabe in einer SDP-Nachricht wird eineEigenschaft aktiviert. Beispielsweise kann durch die Zeile a=recvonly festgelegtwerden, daß die Kommunikation nur unidirektional ist. Mit der zweiten Variante wirdeinem Attribut ein Wert () zugewiesen.c= Diese Zeilen definieren eine Netzadresse. Das Feld enthält denNetztyp. Dafür ist nur der Wert IN definiert, welcher für Internet steht. gibt den genauen Adreßtyp an, für den im aktuellen RFC nur der Wert IP4definiert ist, der ein Netz basierend auf IPv4 spezifiziert. Das letzte Feld enthältdie Transportadresse, an die die Medienströme gesendet werden. Für eine Unicast-Adresse, ist entweder ein eindeutiger Rechnername oder die IP-Adresse anzugeben.Bei Multicast-Adressen wird durch einen ’/’ getrennt eine TTL angegeben. Optionalkann ebenfalls durch einen weiteren ’/’ getrennt eine Zahl folgen. Diese gibt an wievieleAdressen definiert sind. Durch 224.1.1.1/127/3 werden beispielsweise dieAdressen 224.1.1.1, 224.1.1.2 und 224.1.1.3 angegeben. und die TTL auf127 gesetzt.In dem folgenden Ausschnitt einer SDP-Nachricht wird ein Audiostrom beschrieben. AlsAnwendungsadresse wird der Port 4710 angegeben. 22 Darauf folgt die Liste der Kennungender Kodierungsverfahren. Der Wert RTP/AVP definiert, daß die folgenden Kennungen RTP-Payload-Nummern sind. In den beiden folgenden Attribut-Zeilen werden den RTP-Payload-Nummern Kodierungsverfahren und eine zugehörige Abtastrate zugeordnet. Der Kennung0 wird der Codec PCM-µ-Law mit einer Abtastrate von 8000 Hz und der Kennung 8 wirdder Codec PCM-A-Law mit der selben Abtastrate zugewiesen. Als Adresse wird die IPv4-Multicast-Adresse 224.2.1.1 mit einer TTL von 127 definiert.m=audio 4710 RTP/AVP 0 8a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000c=IN IP4 224.2.1.1/127Die zeilenweise Formatierung und die Kennungen mit einem einzigen Zeichen für den Inhalteiner Zeile erfüllen die definierte Aufgabe, aber lassen sich nur schwer erweitern.22 Implizit ist der RTCP-Port dadurch auf 4711 definiert.

36 Kapitel 2. BasistechnologienSDP Next Generation (SDPng)Der Einsatz von SDP zur Medienbeschreibung ist durch die schwer zu erweiternde Struktureingeschränkt. Aus diesem Grund entwickelt die Working Group MMUSIC der IETF z.Z.das Nachfolge-Protokoll SDPng [35]. Dieses soll die Fähigkeiten von SDP bereitstellen undfolgende zusätzliche Eigenschaften aufweisen, wobei die Reihenfolge nicht die Prioritätwiderspiegelt:• SDPng-Nachrichten müssen einfach parsierbar und die Protokoll-Regeln leicht zu implementierensein.• SDPng soll erweiterbar sein, so daß eine Änderung an der Spezifikation selbst nichterforderlich ist. Diese soll allerdings einen Mechanismus bereitstellen, der verhindert,daß sich unabhängige Erweiterungen überschneiden (z.B. in verwendeten Bezeichnungen).• SDPng soll für einzelne Teile der Beschreibung unabhängige Sicherheits-Attribute zulassen.Es soll das Signieren sowie das Verschlüsseln einzelner Teile in beliebiger Kombinationmöglich sein.• Eine kurze und prägnante Textrepräsentation ist wünschenswert, um die Portierbarkeitzu verbessern und die Implementierungen einfach zu halten. Eine Beschreibungssprache,die formell validiert werden kann, ist erwünscht. Aktuelle Internet Draftsverwenden XML.• In vielen Szenarien (z.B. in SIP und MEGACO) sind ausschließlich Medienbeschreibungenvon Interesse. Konferenz-Beschreibungen sind hier nicht notwendig. Aus diesemGrund sollen bestimmte Eigenschaften nur optional sein.• Es soll möglich sein, einen Teil der SDPng-Beschreibungen auf SDP abzubilden. DaSDPng eine stark erweitere Funktionalität gegenüber SDP bietet, ist eine vollständigeAbbildung nicht möglich.Die momentane Version des Internet-Drafts definiert kein vollständiges Protokoll. Auch dasNachrichtenformat ist noch in der Entwicklung. Der derzeitige Stand spezifiziert vier Teile,aus denen eine SDPng-Nachricht bestehen soll: Definitionen, Konfigurationen, Abhängigkeitenund Attribute.In den Definitionen werden unter anderem Medientypen beschrieben. Dabei sind beispielsweiseAttribute wie Kodierungsverfahren, Abtastrate und Anzahl der Kanäle angegeben.Alternativ kann dabei auch auf vordefinierte RTP-Payload-Typen referenziert werden. Jederdieser Medientyp-Beschreibungen wird ein Name zugewiesen, der in den folgenden Teilender Nachricht als Verweis eingesetzt werden kann.

2.5. Medienbeschreibung 37Im Abschnitt „Konfiguration“ werden die einzelnen Komponenten beschrieben. Hierbeiwerden die zuvor definierten Namen der Medientypen verwendet. Die Komponenten beschreibenAlternativen von Konfigurationen für Medienströme. Komponenten und Alternativenwerden wiederum mit einem Namen gekennzeichnet. Zu einer Alternative gehörenein Medientyp-Bezeichner aus dem Abschnitt „Definition“, eine IP-Adresse sowie ein RTPundRTCP-Port. In dem folgenden Ausschnitt einer SDPng-Nachricht wird eine Komponente„interactive-audio“ beschrieben, in der zwei Alternativen „AVP-audio-0“ und „AVP-audio-11“ definiert sind.Der Abschnitt „Abhängigkeiten“ (constraints) definiert Einschränkungen für die paralleleVerwendung von zuvor spezifizierten Komponenten. Verwendet werden kann dieser Abschnittbeispielsweise, um bei rechenintensiven Kodierungsverfahren die Anzahl von parallelenAnwendungen auf ein Maximum zu begrenzen.Der vierte Abschnitt „Attribute“ (conf) ist optional. Hier werden die Informationen zu einerKonferenz, wie Titel, Initiator und Beschreibung untergebracht. In dem folgenden Beispielträgt die Konferenz den Titel „An SDPng seminar“ und wurde von joe@example.com initiiert.Desweiteren wird mit dem Element repeat beschrieben, das sich die Konferenz alle7 Tage wiederholt und eine 1 Stunde dauert. Das umschließende Element time bestimmtStart- und Endzeit. Zusätzlich kann die Semantik von Medienströmen beschrieben werden,wie es in dem Beispiel mit Element info getan wird.

38 Kapitel 2. BasistechnologienThis seminar is about SDPng...http://www.ietf.org/mailto:joe@example.comsip:joe@example.comAudio stream for the different speakersEmpfehlung H.245Die H.323-Konferenzumgebung verwendet für die Medienaushandlung und -beschreibungein eigenes Protokoll, das in der Empfehlung H.245 [30] beschrieben wird. H.245 definiert,wie zwei H.323-Endpunkte eine Medienaushandlung durchführen. Der Ablauf siehtvor, daß die Aushandlung der Medien vor Beginn des Gespräches durchgeführt werden sollund jederzeit während des Gesprächs erneut stattfinden kann. Gründe für wiederholte Medienaushandlungenkönnen Schwankungen der Klangqualität durch überlastete Netze seinoder weitere Teilnehmer, die in eine Konferenz einsteigen.Wie viele Protokolle der ITU-T, so ist auch H.245 so konstruiert worden, daß durch dievordefinierten ASN.1-Strukturen möglichst viele Variationen zur Definition von Medienströmenabgedeckt werden. Da diese Empfehlung zusätzlich für die Konferenzsteuerungzuständig ist und dieses Protokoll auch für weitere Empfehlungen der ITU-T entwickeltwurde, ist die Menge der definierten Strukturen sehr komplex und umfangreich.H.245 unterstützt eine sehr komplexe Methode zur Beschreibung der Fähigkeiten des Endpunktes.Es können Gruppen von Kodierungsverfahren angegeben werden, wobei die Reihenfolgedie Priorisierung angibt. Auch ist es möglich, erlaubte bzw. verbotene Parallelitätin den Mengen auszudrücken. Ein Endpunkt kann von diesen Gruppen eine beliebige Anzahl(maximal 256) definieren.2.6. ZusammenfassungJede Multimedia-Konferenz in paketvermittelten Netzen muß sich mit Medienströmen, d.h.ihren Eigenschaften, der Verarbeitung und dem Transport, auseinandersetzen.Damit Medienströme heutzutage durch das Internet transportiert werden können, reichtdie Unterstützung von IPv4 in der Vermittlungsschicht nicht mehr aus. Schrittweise werdenimmer mehr Teilnetze IPv6 fähig. Eine Komponente, die Teilnehmer aus IPv6- sowie IPv4-Netzen in einer Konferenz verbinden will muß zwischen den beiden Protokollen vermittelnkönnen.

2.6. Zusammenfassung 39Zusätzlich zwingt die heterogene Struktur des Internet durch ein breites Spektrum vonverfügbaren Kapazitäten für die Medienströme zur Anpassung der Kodierungsverfahren fürTeilgruppen von Konferenzteilnehmern. Dafür sind detailierte Kenntnisse über RTP, RTCP,Kodierungsverfahren und Techniken zur Medienbeschreibung erforderlich.Das Ziel dieser Diplomarbeit ist die Entwicklung einer Architektur für eine Komponente, diesowohl in IP-Telefonie-Systemen als auch in anderen Multimedia-Konferenzen zum Transportund zur Verarbeitung von Medienströmen eingesetzt werden kann. Die Working GroupMEGACO hat sich mit ähnlichen Konzepten befaßt und bietet somit eine Grundlage für architekturelleStrukturen.Mittels dieser theoretischen Informationen ist eine Basis für weitere Überlegungen gelegt.Basierend auf diesen Kenntnissen werden im folgenden Schritt anhand von praktischen Beispielendas Einsatzgebiet sowie genauere Funktionsdefinitionen dieser Komponente erarbeitet.Dabei liegt ein Schwerpunkt in Überlegungen zur generischen Integration der Komponentein vorhandene Konferenzumgebungen und der genauen Definition der möglichenEinsatzgebiete.

40 Kapitel 2. Basistechnologien

3. Anforderungen und ZieleDieses Kapitel beschäftigt sich mit vorhandenen Strukturen und Konzepten im Bereich desTransportes und der Verarbeitung von Medienströmen. Darauf aufbauend soll anhand vonAnalysen von Mbone- und IP-Telefonie-Konferenzen eine Anforderungsdefinition sowie eineZielsetzung für diese Diplomarbeit erarbeitet werden.3.1. HintergrundIn den letzten Jahren hat die Arbeitsgruppe Rechnernetze der Universität Bremen durchstudentische und wissenschaftliche Projekte sowie Diplomarbeiten eine Infrastruktur fürIP-Telefonie aufgebaut. Das Resultat dieser Arbeit soll sich in diese Strukturen eingliedernlassen und ihre Funktionalität erweitern. Dabei soll die Unabhängigkeit der zu entwickelndenKomponente gewährleistet bleiben.Die in Abbildung 3.1 dargestellte Infrastruktur der Arbeitsgruppe beinhaltet Komponentenaus der SIP- und aus der H.323-Konferenzumgebung. In den Projekten der Arbeitsgruppewerden beide Systeme erforscht, indem Teststellungen aufgebaut und analysiert und eigeneKomponenten entwickelt werden. Welche Komponenten aus welchen Projekten stammen,wird im folgenden erläutert.Erste Überlegungen zu Multimedia-Konferenzen in paketvermittelten Netzen stammen ausdem Projekt CONTRABAND (Conferencing for Transport Breakdown and Accident Managementand Networking of Dispatchers). Ziel dieses Projekts war die Entwicklung einerkonkreten Strategie für den Einsatz von Multimedia-Telekonferenzsystemen im Umfeld derbremischen Transportwirtschaft. Dabei stand eine Konferenzsteuerung auf der Basis vonInternet-Technologien im Vordergrund.MECCANO [3] war ein weiteres Projekt der Arbeitsgruppe, welches sich nicht ausschließlichmit der IP-Telefonie, sondern hauptsächlich mit Multimedia-Konferenzen im Mbone beschäftigthat. Ziel war die Bereitstellung von technischen Komponenten zur Unterstützungkooperativer Forschung und Entwicklung unter Einsatz von professionellen Werkzeugen fürMultimedia-Kommunikation. Dabei sollten die vorhandenen Anwendungen unter Berücksichtigungder Schwerpunkte Fernunterricht und Konferenzen verbessert werden. Punktewie in der folgenden Auflistung waren Merkmale der Arbeit von MECCANO.• Verbesserung der Nutzerfreundlichkeit• Unterstützung für Bandbreitenreservierung• Kopplung zwischen den beiden Konferenzsystemen der ITU-T und IETF• Messung, Beobachtung und Verwaltung der Ressourcen-Reservierungen

42 Kapitel 3. Anforderungen und ZieleH.323−GatekeeperH.323−TelefoneWiponeH.323−Software−EndpunktMedia−ServerIntranetWiNInternetMBoneSIP−ProxySIP−TelefoneStarGateH.323 − SIP − ISDNISDNPSTNGSMAudioGateRTP/RTCP − ISDNAbbildung 3.1.: Infrastruktur in der Arbeitsgruppe• Integration von schmalbandigen Anbindungen mittels intelligenter Paket-Filter, Multiplexenund Änderung von Kodierungsverfahren.In MECCANO sind für die Infrastruktur die beiden Gateways AudioGate und StarGate zurAnbindung an das herkömmlichen Telefonnetz und für die Kopplung der KonferenzumgebungenSIP und H.323 entwickelt worden. Desweiteren stammen eine SIP- sowie eineMbus 1 -Bibliothek aus diesem Projekt.AudioGate bietet die Fähigkeit, von einem beliebigen Telefonnetz (PSTN, ISDN oder GSM)eine Verbindung zu einer Mbone-Konferenz herzustellen. Dem Benutzer wird die Möglichkeitgeboten, aus einer Liste von laufenden Konferenzen auszuwählen. Während der Verbindungstehen zusätzliche Dienste wie Benutzer-Identifikation und Stummschaltung zurVerfügung.StarGate ist ein Gateway zur Anrufsignalisierung und -steuerung sowie zur Verarbeitungvon Medienströmen. Wichtigste Aufgabe dabei ist die Verbindung zwischen den drei SignalisierungsprotokollenSIP, H.323 und ISDN mit einer entsprechenden Konvertierung derMedienströme. Zusätzlich sollen H.323-Endpunkte durch das Gateway aktiv an Mbone-Konferenzen teilnehmen können. Entstanden ist das Gateway im Rahmen der Diplomarbeitvon Niels Pollem [43].Vom Wintersemester 1998/1999 bis zum Sommersemester 2000 hat sich das Projekt Uni-Tel [4], welches von der Arbeitsgruppe betreut wurde, mit der Erschaffung einer Infrastrukturfür IP-Telefonie innerhalb des Fachbereichs 3 Informatik/Mathematik beschäftigt. Dabeiwurde der Schwerpunkt nicht in die technische Entwicklung gelegt, sondern in den Bereich1 Der Mbus (Message Bus, Internet-Draft [41]) unterstützt die Entwicklung von modularen Systemen. Definiertwird eine Art der Kommunikation, die es Anwendungen erlaubt über mehrere Rechner und unabhängig vonder Programmiersprache miteinander Nachrichten auszutauschen.

3.1. Hintergrund 43der Nutzung. Einerseits wurden bekannte Themen wie z.B. Authentisierung der Nutzer, Kostenabrechnungund Datenschutz diskutiert, anderseits beschäftigte sich das Projekt auchmit neuen Fragestellungen aus der IP-Telefonie wie z.B. Auffinden eines Benutzers undKontrolle der verwendeten Bandbreite für IP-Telefonie.Entstandene Produkte aus dem Projekt setzen auf die H.323-Architektur auf. Der in UNI-TEL entwickelte Media-Server hat die Funktion eines zentralen Anrufbeantworters. Allenicht entgegengenommenen Anrufe werden automatisch an den Media-Server weitergeleitet.Für den Anrufer ist das Verhalten des Media-Servers dem eines Anrufbeantwortersgleich. Nach einer individuellen Ansage wird die gesprochene Nachricht bis zu einer maximalenLänge aufgezeichnet und kann später vom Angerufenen abgehört werden. EineErweiterung ermöglicht die Verwaltung der einzelnen Benutzer-Konten auf dem Media-Server über einen beliebigen Web-Browser. Somit können Benutzer ihren Anrufbeantworterirgendwo auf der Welt abfragen.Nach dem Beginn von UNITEL startete im April 1999 das wissenschaftliche Projekt WIP-TEL [5] und dauerte 18 Monate. Ziel war die Entwicklung einer Referenzkonfiguration fürdie Nutzung der IP-Telefonie innerhalb des Deutschen Wissenschaftsnetzes (WiN). WeitereSchwerpunkte in diesem Projekt waren die Entwicklung einer Infrastruktur für IP-Telefoniesowie die Implementierung von benötigten Komponenten. Dabei sind der Gatekeeper, Wiponeund ein Anrufsignalisierungs-Modul (H.323-Call-Control) entstanden.Der Gatekeeper ist eine vollständige Implementierung der gleichnamigen Komponente ausder H.323-Empfehlung. Zu seinen Funktionen gehören Adreßauflösung (auch über seineH.323-Zone 2 hinaus), Ressourcen-Verwaltung und eine spezielle Anpassung an das Fehlverhalteneinzelner getesteter H.323-Endpunkte. Eine erste Version dieses Gatekeepers istin der Diplomarbeit von Stefan Prelle [48] entstanden.Die H.323-Call-Control ist ein Modul zur Anrufsignalisierung und -steuerung für einenH.323-Endpunkt. Zusätzlich zu den verbindlichen Funktionen der Anrufsignalisierung werdenspezielle Fähigkeiten wie Fast-Start unterstützt. In der Diplomarbeit von Dirk Meyer[36] wurde die H.323-Call-Control unter Verwendung der H.450-Empfehlungen um einigeMehrwertdienste, wie Weiterleitung, Stummschaltung und Transfer erweitert. Mit einereinzigen Instanz der H.323-Call-Control können mehrere parallele Anrufe verwaltet werden.Wie viele andere Komponenten in der Infrastruktur bietet auch die H.323-Call-Controleine Schnittstelle zur Steuerung über den Mbus. 3Wipone ist ein GUI (Graphical User Interface) für einen H.323-Endpunkt. Über eine Mbus-Schnittstelle kommuniziert das GUI mit der H.323-Call-Control, die die Anrufsignalisierungübernimmt. Wipone besitzt ein Telefonbuch, in dem mehrere Adressen pro Datensatz eingetragenwerden können. Zusätzlich kann zu einem Eintrag definiert werden, ob Anrufedieser Person direkt abgelehnt werden sollen. Weitere Fähigkeiten von Wipone sind dieVerwaltung von mehreren parallelen Anrufen, Lautstärkeregelung und Senden von DTMF.Zur Übertragung der Medienströme wird RAT (siehe Abschnitt 3.3.1) eingesetzt.Zwei in der Arbeitsgruppe aktuell laufende Projekte beschäftigen sich mit der SIP-Konferenzumgebung.Zum einen das Projekt Siphon, in dem der Einsatz von SIP in professionellenAnwendungsbereichen evaluiert wird, und anderseits das Projekt Siptel, in dem ein eigensentwickelter SIP-Protokollstack in ein Telefon integriert werden soll. Dabei ist der SIP-Proxyentstanden.2 Eine Zone bezeichnet ein Teilnetz, das von einem Gatekeeper verwaltet wird.3 Die Mbus-Kommandos der H.323-Call-Control sind im Internet Draft draft-ietf-mmusic-mbus-call-control-01 [40] definiert.

44 Kapitel 3. Anforderungen und ZieleDas Projekt 6WINIT erforscht in Zusammenarbeit mit europäischen Telekommunikationsbetreibern,Geräteherstellern, Forschungseinrichtungen und Krankenhäusern neue Einsatzmöglichkeitenfür IPv6 in drahtlosen Netzen. Ziel des Projektes ist es, im Vorfeld der Markteinführungder Mobilfunknetze der dritten Generation neue Lösungen für den Einsatz vonInternet-Technologien zu entwickeln und zu demonstrieren.3.2. ZielfindungIm folgenden Abschnitt sollen anhand von strukturierten Analysen der Ist-Situation diegenaue Funktionsweise und nötigen Fähigkeiten für die zu entwickelnde Komponente erarbeitetwerden. Desweiteren sollen verwendete Konzepte und Techniken in Multimedia-Konferenzen betrachtet sowie Überlegungen zur Skalierbarkeit angestellt werden, die zurder Entwicklung der Architektur beitragen.Um bestimmte Begrifflichkeiten in den folgenden Ausführungen wohldefiniert einsetzen zukönnen, werden an dieser Stelle die Interpretationen des Autors eingeführt.Eine Kommunikationsbeziehung ist eine abstrakte Bezeichnung für jede Art von Informationsaustausch,der einem fest definierten Ablauf folgt. Dabei sind nicht nur SprachoderBilddaten inbegriffen sondern auch beliebige andere Daten. Die ausgetauschtenInformationsflüsse werden als Medienströme bezeichnet.Ein Endpunkt umschreibt eine Hardware- oder Software-Komponente, die als Quelle vonMedienströmen für Kommunikationen eingesetzt wird. Beispiel für einen Endpunktist ein Telefon.Eine Konferenz beschreibt eine Kommunikation zwischen mehreren Personen. Eine Kommunikationmit genau zwei Personen (Zwei-Punkt-Kommunikation) ist der einfachsteFall einer Konferenz.Eine Multimedia-Konferenz bezeichnet eine Konferenz, in der mehrere Medienströmeverschiedener Art zwischen den Teilnehmern ausgetauscht werden.Ein Media-Prozessor bezeichnet die in dieser Arbeit zu entwickelnde Komponente. Dabeihandelt es sich um eine Anwendung, die in Konferenzen integriert wird und dortAufgaben übernimmt, die die eines einfachen Endpunktes übersteigen. Diese Komponentegehört zu einer Gruppe von Systemen, die als Zwischen-Systeme (Middleboxes)bezeichnet werden. Durch einen modularen Aufbau soll der Media-Prozessor auch inEndpunkte integrierbar sein.Ziel dieser Arbeit soll die Entwicklung einer Architektur für einen Media-Prozessor sein.Dafür wird im folgenden eine Bestandsaufnahme durchgeführt, die vorhandene Problemein Multimedia-Konferenzen aufzeigen soll. Desweiteren werden die Zielanwendungenbetrachtet, d.h. in welchen Arten von Konferenzen kann mittels zusätzlicher Komponenten,wie einem Media-Prozessor, eine Problemlösung herbeigeführt werden. Abschließendwird aus diesen Betrachtungen eine Definition der geforderten Funktionen eines Media-Prozessors abgeleitet.

3.2. Zielfindung 453.2.1. BestandsaufnahmeIn der IP-Telefonie sowie in Mbone-Konferenzen sind Fähigkeiten zum Transport und zurVerarbeitung von Medienströmen notwendig. Diese Bereiche bilden den Schwerpunkt dieserDiplomarbeit. Durch die heterogene Struktur des Internet ist die Komplexität dieserAufgabe nicht zu vernachlässigen. Unterschiedliche Protokolle in der Vermittlungschichtlassen den Transport von Daten über die Grenzen eines Netzes unter Umständen nur mittelsGateways zu. Diese Komponenten können verschiedene Protokolle der Vermittlungsschichtineinander umsetzen. Zur Zeit wird diese Fähigkeit auf Grund der schrittweisenEinführung von IPv6 interessant. Da diese Umstellung mehrere Jahre dauern wird, sindGateways notwendig, die in Konferenzen für eine Überbrückung der verschiedenen Vermittlungsschichtsprotokollesorgen.Eine weitere Schwierigkeit beim Transport von Medienströmen liegt in der grundlegendenTechnik der paketvermittelten Netze. In herkömmlichen Telefonnetzen (leitungsvermittelt)ist ein festgelegter Weg zwischen den Gesprächsteilnehmern für die Dauer des Telefonatsreserviert. Die komplette Kapazität des Kanals steht ausschließlich für ein einzelnes Gesprächzur Verfügung. Auftretende Pausen führen allerdings zu einer geringen Auslastung,da der Kanal nicht anderweitig eingesetzt werden kann. In paketvermittelten Netzen sindReservierungen dieser Art nicht möglich. Jedes einzelne Paket kann einen anderen Wegzum Ziel nehmen, da die Router ihre Informationen über die einzelnen Streckenabschnitteständig aktualisieren. Pakete können unterwegs verloren gehen, zerstört werden oderlänger für den Weg benötigen als andere Pakete. Solche Verluste sind bei Medienströmennur in Grenzen akzeptabel. Eine zu hohe Fehlerrate führt z.B. bei Audio-Informationenzur Unverständlichkeit. Mittels RTP und speziellen Payloads (siehe Anhang A) können solcheProbleme erheblich gemildert werden. Mittels der Sequenz-Nummern von RTP könnendie korrekte Reihenfolge sowie Verluste bei den Paketen erkannt werden. Die speziellenRTP-Payloads fügen Informationen zu den Mediendaten hinzu, welche bei Bedarf zur Rekonstruktionvon verlorengegangenen oder defekten Daten verwendet werden können.Viele Privatanwender verbinden sich durch das herkömmliche Telefonnetz über einen ISP(Internet Service Provider) mit dem Internet. Diese Anbindungen stellen gegenüber denKernstrecken des Internet eine sehr geringe Kapazität zur Verfügung. Auch Firmennetzesind teilweise nur über schmalbandige Standleitungen mit dem Internet verbunden. Die inMedienströmen transportierten Daten, wie Audio- oder Video-Informationen, benötigen jenach Kodierungsverfahren eine bestimmte Bandbreite. Diese liegt bei nicht wenigen Kodierungverfahrenüber den Bandbreiten der Anbindungen von Privatanwendern. Beispielsweisekann ein Nutzer mit einer Modemanbindung bei einer maximalen Übertragungsrate von56 kBit/s keinen Audiostrom empfangen, der mit PCM-A-Law kodiert ist, da dieser eine Datenrate60 kBit/s erzeugt. Dadurch kann eine Teilnahme an einer Konferenz an fehlenderBandbreite scheitern. Um solche Nutzer in Konferenzen zu integrieren, müssen auf demWeg zum Teilnehmer Kodierungsverfahren mit geringerer Bandbreite eingesetzt werden.In Multimedia-Konferenzen gibt es zusätzlich die Möglichkeit, aus der Menge der gesendetenMedienströme nur einen Bruchteil auszuwählen, der an diese Teilnehmer weitergeleitetwird. Beispielsweise wird nur der Audiostrom empfangen, und der Videostrom wird nichtan diesen Teilnehmer versendet.Mbone-Konferenzen setzen die Funktion der Gruppenadressierung (Multicast) voraus. DieseFähigkeit des Internet-Protokolls hängt von den eingesetzten Routern ab. Ihre Aufgabeist das Erkennen der speziell adressierten Pakete sowie die entsprechende Weiterleitung.In weiten Teilen des Internet sind solche Router nicht vorhanden, wodurch Mbone-Konferenzen in ihrem Anwendungsbereich eingeschränkt sind. Beispielsweise bieten viele

46 Kapitel 3. Anforderungen und ZieleISPs in Deutschland kein Multicast an. Dadurch können Heimanwender nicht an solchenKonferenzen teilnehmen. Um Endpunkte aus Netzen zu integrieren, die kein Multicast unterstützen,kann wie in Abbildung 3.2 veranschaulicht ein Gateway verwendet werden, dasals Vermittler fungiert. Das Gateway empfängt dabei die Medienströme der Konferenz perMulticast und sendet sie unverändert per Unicast an die externen Teilnehmer. Deren Medienströmewiederum werden durch das Gateway an die Konferenz weitergeleitet. Dabeibleibt das Gateway für die Konferenzteilnehmer unsichtbar.MBoneausschließlichUnicastMulticast / UnicastGatewayAbbildung 3.2.: Verbindung zu einer Multicast-KonferenzIn der IP-Telefonie ist ebenfalls zwischen Zwei- und Mehr-Punkt-Beziehungen zu unterscheiden.In Zwei-Punkt-Beziehungen sind unterschiedliche Protokolle in der Vermittlungsschichtund unterschiedliche Kapazitäten der Anbindungen die Hauptprobleme. ZusätzlicheProbleme treten bei den Mehrpunkt-Beziehungen auf. Konferenzen in der IP-Telefonie basierenim Normalfall nicht auf Multicast, d.h. die Medienströme werden nicht an die Gruppeadressiert, sondern an die einzelnen Teilnehmer. Um die Verteilung der Medienströme zuorganisieren, existieren mehrere Möglichkeiten, die alle auf der Bündelung von Medienströmenbasieren. Jedem Teilnehmer wird ein einziger Medienstrom zugeschickt, der auseiner Kombination aller Medienströme außer seinen eigenen besteht.Die Bündelung der Daten muß entsprechend ihrer Art vorgenommen werden. DekodierteAudio-Informationen können durch eine simple Addition gemischt werden, so daß die Datenaller Medienströme in einem einzelnen integriert sind. Praktisch bedeutet dies, daß dieStimmen der einzelnen Teilnehmer in dem resultierenden Medienstrom enthalten sind. Dieseeinfache Methode kann bei Video-Informationen nicht angewendet werden. Anhand derArt einer Konferenz muß eine entsprechende Alternative ausgewählt werden. Bei Konferenzen,in denen der Sprecher gar nicht oder nur selten wechselt, kann der gebündelte Medienstrombeispielsweise nur aus den Videodaten des Sprechers bestehen. Bei offenen Diskussionsrunden,bei denen der Sprecher beliebig wechselt, ist diese Vorgehensweise nichtpraktikabel, da das resultierende Video nur aus unerkennbaren Bildern bestehen würde.Alternativ könnten in diesem Fall die Video-Bilder der einzelnen Sprecher in einem resultierendenVideo verkleinert und nebeneinander gesetzt werden, wobei diese Technik nurbei einer geringen Anzahl von Sprechern funktioniert. Diese Betrachtungen zeigen, daß fürVideo-Informationen keine einheitliche Technik zur Bündelung existiert.Alle Typen von Mediendaten werden in der IP-Telefonie mittels RTP transportiert. Da bei derBündelung der Mediendaten die RTP-Ströme verändert werden, müssen die RTCP-Datenentsprechend angepaßt werden. Wie die Informationen anzupassen sind, kann den Definitionendes RTP-Translators und RTP-Mixers entnommen werden (siehe Abschnitt 2.2.4).Aus den beschriebenen Situationen lassen sich Aufgaben bezüglich des Transportes und

3.2. Zielfindung 47der Verarbeitung von Medienströmen extrahieren. Diese lassen sich anhand von einfachenBeispielen verdeutlichen.Die zu transportierenden Medienströme werden bei Bedarf mittels geeigneter Kodierungsverfahrenkomprimiert, um die benötigte Bandbreite zu reduzieren. Nicht alle Endpunktekönnen jedes Kodierungsverfahren beherrschen und nicht jede Anbindung bietet genugBandbreite für jeden Medienstrom. Um dieses Problem zu lösen, müssen die verwendetenKodierungsverfahren für einzelne Teilnehmer angepaßt werden (Transcoding), wie esschematisch in Abbildung 3.3 angedeutet ist.Media−ProzessorAbbildung 3.3.: Übersetzung zwischen verschiedenen KodierungsverfahrenIn jeder Kommunikationsbeziehung kann es von Interesse sein, Teilnehmer aus verschiedenenNetzen miteinander zu verbinden. Zur Realisierung wird eine Instanz benötigt, die dieverschiedenen Vermittlungsschichten versteht und diese ineinander umsetzen kann. Abbildung3.4 zeigt eine schematische Darstellung einer Verbindung von drahtgebundenen unddrahtlosen sowie Teilnehmern aus dem herkömmlichen Telefonnetz.ISDNPSTNGSMMedia−ProzessorAbbildung 3.4.: Vermittlung zwischen verschiedenen NetzenAus der zuvor beschriebenen Konstellation läßt sich eine weitere Fähigkeit ableiten. Die Instanz,die zwischen verschiedenen Netzen vermittelt, fungiert als zentrale Einheit der Konferenz,d.h. die Medienströme aller Teilnehmer werden an sie geschickt. Da viele Endpunktenicht parallel mehrere Medienströme verarbeiten können, müssen die Medienströme, wiein Abbildung 3.5 veranschaulicht, gebündelt werden.Medienstrom CMedienstrom A+BMedienstrom AMedienstrom B+CMedienstrom A+CMedienstrom BMedia−ProzessorAbbildung 3.5.: Bündelung von Medienströmen

48 Kapitel 3. Anforderungen und ZieleEine weitere Funktionalität liegt in der Überwachung von Medienströmen und der Erkennungsowie Erzeugung von vordefinierten Mustern. Ein Beispiel hierfür ist DTMF. Diese speziellenTöne sind in den Audio-Informationen enthalten und müssen durch eine Art Filteranhand einer genauen Definition des Musters erkannt werden, wenn sie von einer Anwendungverarbeitet werden sollen. RTP bietet die Möglichkeit, DTMF und andere Signale ausTelefonie mit einem eigens dafür definierten RTP-Payload (RFC 2833 [53]) zu verschicken.Enthalten sind darin keine Audio-Informationen, sondern eine exakte Beschreibung desgesendeten Tons. Diese Technik erleichtert die Erkennung sowie Erzeugung der Töne.Eine Anwendung, die diese Funktionalitäten alle benötigt, ist eine Konferenz-Zentrale. Eingesetztwerden diese in der IP-Telefonie und in Mbone-Konferenzen. Die vorangegangenBetrachtungen beschreiben Aufgabenfelder, die von einem Media-Prozessor abgedeckt werdenmüssen. Dabei zeigt sich, daß ein Media-Prozessor sowohl in Mbone-Konferenzen alsauch in der IP-Telefonie Anwendung finden kann und somit auch Ziel dieser Arbeit ist.3.2.2. Anwendungsszenarien von Media-ProzessorenDie beschriebenen Situationen beschreiben Hindernisse, die zum Scheitern bei der Instantiierungeiner Konferenz führen können. Ein weiterer Parameter, der bei Konferenzen inpaketvermittelten Netzen von Wichtigkeit ist, ist mit der Anzahl der Teilnehmer verbunden.Media-Prozessoren können nicht in allen Konferenzen eingesetzt werden. Im folgendenwerden Konferenzen verschiedener Größe betrachtet und geprüft, ob der Einsatz einesMedia-Prozessors möglich ist.In kleinen Konferenzen mit ungefähr einem Dutzend Teilnehmern kann in der Regel ohneeinen Media-Prozessor gearbeitet werden. Eine Einigung auf ein gemeinsames Kodierungsverfahrenfür die Medienströme ist bei solchen Gruppen realisierbar. Auf Multicast kann insolchen Fällen verzichtet werden, da auch bei Unicast-Verbindungen keine enorm hohe Kapazitätder Anbindungen benötigt wird. Dabei kann auch ein Kodierungsverfahren gewähltwerden, welches eine geringere Bandbreite benötigt. Unabhängig von den Adressierungsarten,müssen die Endpunkte in diesen Konferenzen selbst in der Lage sein, Medienströme zumixen oder es wird jeweils nur ein ausgewählter Medienstrom empfangen. In diesen Fällenist die Fähigkeit des Media-Prozessors, sich in verschiedene Umgebungen zu integrieren,hilfreich.Der Einsatz von Media-Prozessoren in Konferenz-Zentralen von sehr großen Konferenzenmit mehreren tausend Teilnehmern ist in der Praxis nicht realisierbar. Multicast-Adressierungist in diesem Fall dringend erforderlich, da sonst ein zu großes Datenaufkommenentsteht, welches selbst die Kernstrecken des Internet überlasten kann. Nutzer einer Modemanbindungwären dabei definitiv ausgeschlossen. Um solche Teilnehmer in große Konferenzenzu integrieren, kann dennoch ein Media-Prozessor verwendet werden. Hierbeisymbolisiert der Media-Prozessor einen unter vielen Teilnehmern und ist nicht der zentralePunkt für alle Medienströme in der Konferenz. Diese Technik kann angewendet werden, umNutzer mit schmalbandigen Anbindungen oder in Netzen ohne Multicast oder mit anderenProtokollen in der Vermittlungsschicht zu integrieren, wie in Abbildung 3.6 dargestellt.Das wichtigste Anwendungsgebiet für einen Media-Prozessor sind jedoch die mittelgroßenKonferenzen mit einigen Dutzend Teilnehmern. Hier werden alle Funktionen eines Media-Prozessors benötigt. Zu finden sind solche Konferenzen im Mbone und in der IP-Telefonie.In der IP-Telefonie ist der Einsatz eines Media-Prozessors als Konferenz-Zentrale die häufigsteAnwendung. Die Initialisierung des Media-Prozessors wird durch eine Verwaltungs-

3.2. Zielfindung 49MboneIPv6geringe BandbreiteUnicastMedia−ProzessorAbbildung 3.6.: Anbindung von Teilgruppen in große Konferenzeninstanz der verwendeten Konferenzumgebung, beispielsweise einen SIP-Proxy oder einenH.323-Gatekeeper, vorgenommen. Wird ein Media-Prozessor beispielsweise durch einenH.323-Gatekeeper gesteuert, so benötigt dieser Rückmeldungen über die laufende Kommunikation.Bricht der Medienstrom eines Teilnehmers unerwartet ab, so kann der H.323-Gatekeeper anhand dieser Information seinen Status über die Konferenz aktualisieren unddiese eventuell beenden. Ist der Media-Prozessor in der Lage, mehrere Konferenzen parallelzu verwalten, kann der H.323-Gatekeeper die Möglichkeit bieten, einzelne Teilnehmeraus einer Konferenz in eine andere zu verschieben.Mbone-Konferenzen, die einen oder mehrere Media-Prozessoren einsetzen, bieten keineMöglichkeit einer automatischen Konfiguration durch eine Verwaltungsinstanz. Somit müssendie Media-Prozessoren manuell an die vorliegende Situation angepaßt werden. Die jeweiligenTeilnehmer, die die Funktionalität des Media-Prozessors brauchen, integrieren diesenin die Konferenz und konfigurieren eine entsprechende Weiterleitung an ihre Endpunkte.Diese statische Art der Konfiguration des Media-Prozessors ist für Mbone-Konferenzenausreichend.3.2.3. Funktionalität von Media-ProzessorenDie vorangegangenen Überlegungen haben gezeigt, daß der Transport von Medienströmenin paketvermittelten Netzen eine komplexe Aufgabe ist. Aus den beschriebenen Ansätzenlassen sich Funktionen ableiten, die von einem Media-Prozessor zur Verfügung gestellt werdenmüssen:• Empfangen, Senden und Weiterleiten von MediendatenEin Media-Prozessor muß Medienströme von verschiedenartigen Quellen empfangenund an sie senden können. Im Regelfall sind die Quellen der Medienströme nichtauf dem lokalen Rechner, so daß ein Media-Prozessor auf jeden Fall RTP-Quellenunterstützen muß. Zusätzlich können lokale Geräte wie Soundkarte, Mikrofon undKopfhörer eingesetzt werden. Zur Integration von Teilnehmern aus dem Telefonnetzist auch die Verwendung eines ISDN-Anschlusses als Quelle eine Möglichkeit.

50 Kapitel 3. Anforderungen und Ziele• Übersetzen zwischen verschiedenen VermittlungsschichtprotokollenEin großer Bereich des Internet ist durch IPv4 erreichbar. Doch besonders der langsambeginnende Einsatz von IPv6 macht es nötig, daß ein Media-Prozessor die Fähigkeitbesitzt, zwischen verschiedenen Protokollen der Vermittlungsschicht zu übersetzen.Ebenso gehören zu diesem Bereich Anbindungen an das Telefonnetz.• Ändern von Kodierungsverfahren (Transcoding)Um Endpunkte in Konferenzen zu integrieren, die aufgrund der verwendeten Kodierungsverfahrender Medienströme nicht teilnehmen können, muß ein Media-Prozessordie Fähigkeit haben, Kodierungen umzuwandeln.• Mischen von mehreren MedienströmenAls Konferenz-Zentrale muß der Media-Prozessor die ankommenden Medienströmefür jeden Teilnehmer individuell mischen. Da die einzelnen Ströme nicht synchronsind, muß der Media-Prozessor eine Synchronisation vornehmen. Sollten in der Konferenzunterschiedliche Medientypen transportiert werden, z.B. pro Teilnehmer einVideo- und ein Audiostrom, dann muß zusätzlich auf eine Synchronisation zwischenden resultierenden Audio- und Video-Informationen geachtet werden.Ein Media-Prozessor soll in verschiedenen Konferenzumgebungen eingesetzt werden. Umsich gut in die jeweilige Umgebung zu integrieren, ist eine angepaßte Schnittstelle zurSteuerung von Vorteil. Während in Mbone-Konferenzen eine einfache statische Konfigurationausreicht, ist in der IP-Telefonie eine dynamische interaktive Steuerung passender. Auchin den definierten Funktionen ist Anpassungsfähigkeit erforderlich. Um dies zu erfüllen,muß ein Media-Prozessor folgende Eigenschaften aufweisen:• ParallelitätEin Media-Prozessor muß fähig sein, mehrere Konferenzen zur gleichen Zeit zu verwalten.Jeder einzelne Endpunkt sowie jede Konferenz muß einzeln konfigurierbarsein.• ModularitätUm die Fähigkeiten des Media-Prozessors ausbauen zu können, sollen Kodierungsverfahren,Protokolle für die Vermittlungsschicht und Filter als Module zur Verfügunggestellt werden. Die Wahl der zu verwendenden Module soll durch die externeSteuereinheit beeinflußbar sein.• Externe SteuereinheitDie Verwaltung von Konferenzen sowie benötigten Ressourcen sind die Aufgaben desMedia-Prozessors. Die Steuerung sowie Instantiierung von Konferenzen wird durcheine externe Einheit übernommen. Um eine möglichst gute Anpassung zu ermöglichen,soll ein Media-Prozessor mehrere Benutzungsschnittstellen bieten.Aus diesen Eigenschaften und Funktionen soll in dieser Arbeit eine Architektur für einenMedia-Prozessor entwickelt werden, die anhand einer exemplarischen Implementierunggetestet wird.3.3. Verwandte ArbeitenIn den Bereichen Medien-Transport und -Verarbeitung sowie Kommunikation über verschiedeneVermittlungsschichtprotokolle existieren einige Software-Produkte, die für die Ent-

3.3. Verwandte Arbeiten 51wicklung des Media-Prozessors wertvolle Informationen bieten. Bei der anschließendenBeschreibung der Produkte wird besonders auf die folgenden Aufgaben geachtet:• Techniken zum Transport von Medienströmen in paketvermittelten Netzen.• Bearbeitung von Medienströmen, wie z.B. Änderung des Kodierungsverfahren undMischen von mehreren Medienströmen (Synchronisation).• Netzunabhängige Datenübertragung und Berücksichtigung der Konvertierung zwischenden Protokollen der Vermittlungsschicht in verschiedenen Netzen.• Kopplung von IP-Telefonie-Systemen auf der gemeinsamen Basis des Transportes derMedienströme mit RTP.Zu jedem dieser Gebiete gibt es Beispiele, die als freie Software 4 veröffentlicht sind und dadurchzur Analyse verwendet werden können. Da Dokumentationen zur internen Arbeitsweisesowie zur Architektur der Software nur selten vorhanden ist, dient der Quellcode alsErsatz. In den folgenden Abschnitten werden einige ausgewählte Software-Produkte kurzvorgestellt und auf ihre besonderen Fähigkeiten bezüglich der zuvor aufgezählten Aufgabenhin untersucht.3.3.1. Robust Audio Tool – RATAufgabe des Projektes RAT [57] war die Entwicklung eines Endpunkts für Mbone-Konferenzen.Wichtigstes Merkmal des Endpunktes ist der Einsatz von Techniken für einen verlustunempfindlichenTransport von Audio-Informationen in paketvermittelten Netzen auf Basisvon IP. Zur Realisierung werden Redundanz-Informationen in die Audio-Informationenintegriert, die beim Empfänger zur Rekonstruktion verlorener oder defekter RTP-Pakete genutztwerden können.Weiter bietet RAT eine große Auswahl an Kodierungsverfahren für die Audioströme bei unterschiedlichenAbtastraten. Die Umsetzung der Kodierungsverfahren funktioniert bei RATin zwei Stufen. Im ersten Schritt werden die empfangenen Mediendaten dekodiert, d.h. siewerden in eine Sequenz von Samples bei gleichbleibender Abtastrate umgewandelt (roheAudiodaten). Diese können in einem zweiten Schritt in das gewünschte Kodierungsverfahrenumgesetzt werden.Im Bereich der Verschlüsselung bietet RAT die vier Betriebsarten aus DES (Data EncryptionStandard [50]) an. Dadurch ist es möglich, private Konferenzen über das Internet zu führen.Um Konferenzen auf diese Art zu verschlüsseln, muß zuvor der Schlüssel ausgetauschtwerden.RAT besteht aus einem GUI-Modul und der Audio-Engine. Die Audio-Engine enthält eineRTP/RTCP-Implementierung sowie eine eigene Socket-Schnittstelle für die Kommunikationüber UDP. Als Protokolle für die Vermittlungsschicht werden IPv4 und IPv6 unterstützt. BeideKomponenten stammen aus der UCL 5 common multimedia Bibliothek (siehe Abschnitt3.3.2). Desweiteren enthält die Audio-Engine ein Transcoding-Modul und eine Verwaltungfür RTP-Sessions. Das GUI-Modul bietet dem Benutzer die Möglichkeit, Konferenzen zu instantiieren,Einstellungen vorzunehmen und Zustandsinformationen von der Audio-Engine4 Der Begriff „freie Software“ bezeichnet hier Produkte, die unter der GPL/LGPL oder ähnlicher Lizenz, bei derder Programmcode frei verfügbar ist, veröffentlicht wurden.5 University College London

52 Kapitel 3. Anforderungen und Zielezu empfangen. Die Kommunikation der beiden Module erfolgt über den Mbus (MessageBus, Draft draft-ietf-mmusic-mbus-transport-05 [41]).Das Projekt RAT hat eine langjährige Erfahrung im Bereich der Mbone-Konferenzen. Fürdie Diplomarbeit kann aus dem Projekt Wissen über Transcoding und die Steuerung vonKonferenzen gewonnen werden. Auch die modulare Implementierung bietet Ansätze, dieim Media-Prozessor weiterverwendet werden können.3.3.2. Die UCL commonlibDie „UCL common multimedia“ Bibliothek (commonlib) umfaßt eine Sammlung von Algorithmenund Protokoll-Implementierungen, die in einer Reihe von Multimedia-Anwendungendes UCL verwendet werden (z.B. RAT). Für diese Arbeit sind besonders die RTPunddie Socket-Implementierung mit der Unterstützung für IPv4 und IPv6 von Interesse.Die Socket-Implementierung ist der BSD-Socket-Schnittstelle nachempfunden und bietetalle bekannten Funktionsaufrufe mit leicht abgewandelten Namen. Da diese Socket-Schnittstellenur für die RTP-Kommunikation über IP ausgelegt ist, wurde das Transportprotokollauf UDP beschränkt. Aufschlußreich ist das Verfahren zur Ermittlung des richtigen Protokollsfür die Vermittlungsschicht. Bei der Instantiierung eines Socket wird intern anhandder Netzadresse das zu verwendende Protokoll für die Vermittlungsschicht ermittelt. DieWahl des Protokolls kann der Nutzer nur mit der Angabe einer entsprechenden IP-Adresseoder einem vollständigen Rechnernamen (Fully Qualified Domain Name) beeinflussen.Die RTP/RTCP-Implementierung orientiert sich an den aktuellen Internet Drafts zu RTP undbietet somit eine gute Vorlage für eine eigene Implementierung. 6 Zum Testen der eigenenImplementierung kann sie ebenfalls eingesetzt werden.Zur Kommunikation mit der Anwendung bietet die Bibliothek einen Callback-Mechanismus.Die Anwendung kann bei der Initialisierung für vordefinierte Ereignisse Funktionen festlegen,die bei Eintreten der Ereignisse von der Bibliothek angesprungen werden. Als Argumentwird diesen Funktionen eine Struktur übergeben, die eine genaue Beschreibung desEreignisses enthält, z.B. empfangene RTP- oder RTCP-Daten.Anwendungen, die auf einer Mainloop (einer Endlos-Schleife, die Ereignis-orientiert arbeitet)basieren, können diese Bibliothek ohne Verwendung von Threads integrieren. Dies istdurch eine Schnittstelle möglich, die eine Einbindung in eine Mainloop der Anwendungmöglich macht.3.3.3. UCL Transcoding Gateway – UTGDas UCL Transcoding Gateway (UTG) hat die Aufgabe, für Benutzer von ISDN und anderenschmalbandigen Punkt-zu-Punkt Verbindungen die Möglichkeit der Anbindungen anMbone-Konferenzen zur Verfügung zu stellen.Die Aufgaben bei der Anbindung sind die Berücksichtigung der geringen Bandbreite vonISDN und die zusätzlichen Steuer-Informationen. Die benötigte Kapazität für viele Mbone-Konferenzen liegt über der eines ISDN B-Kanals (häufig werden 128kb/s für Video und64kb/s für Audio verwendet). Aus diesem Grund ist eine Aufgabe des UTG-Systems dieAnpassung der Kodierungsverfahren, so daß ein ISDN-Kanal ausreicht. Eine weitere Auf-6 Der Grund für eine eigene RTP-Bibliothek wird im späteren Verlauf noch erläutert.

3.3. Verwandte Arbeiten 53gabe, mit der sich das UTG beschäftigt, ist die Integration von Teilnehmern in Mbone-Konferenzen, deren Netze keine Multicast-Adressierung unterstützen.Das UTG-System, wie in Abbildung 3.7 dargestellt, besteht aus zwei Anwendungen, einemServer und einem Client. Der Server muß eine Verbindung zum Mbone haben und solltesich im selben Netz wie der Einwahlpunkt des Clients befinden. Der Client wird in demselben Netz gestartet wie der Endpunkt. Dessen Aufgabe ist die Steuerung der Mbone-Tools(Entwicklungen des UCL, die für Mbone-Konferenzen eingesetzt werden können) sowie dieKommunikation mit dem Server. Zusätzlich zu den Kanälen für Medienströme existiert eineTCP-Verbindung zwischen Server und Client, die für die Steuerung der Module des Serversgenutzt wird.Mbonegeringe BandbreiteUnicastUTG−ClientRAT, VIC, SDRUTG−ServerAbbildung 3.7.: UTG-Server und UTG-ClientInteressant für diese Arbeit ist das UTG, da es einige der Fähigkeiten hat, die auch derMedia-Prozessor besitzen soll. Dazu gehören die Verbindungen zwischen Netzen unterschiedlicherFähigkeiten und die Anpassung von Medienströmen entsprechend der Anbindungskapazitätender Teilnehmer.3.3.4. SIP-basierter Audio-Konferenz-Server – sipconfDer SIP Audio Conference Server sipconf [54] wurde von Kundan Singh an der UniversitätColumbia entwickelt. sipconf besitzt die Fähigkeit, zuvor angekündigte Konferenzen zuverwalten. Die dafür notwendige Aufgabe des Mischens von Audio-Informationen ist insipconf integriert.In der Abbildung 3.8 ist schematisch die Funktionsweise des Audio-Mixers dargestellt. Dieempfangenen Audio-Ströme werden in ein einfaches lineares Kodierungsverfahren umgewandelt.Die zu mischenden Ströme werden über einen eigenen Zeitgeber synchronisiert.Durch die linearen Kodierungsverfahren, können die Ströme nach einem einfachen mathematischenVerfahren, der Addition, gemischt werden. Der entstandene Strom wird in dasbenötigte Kodierungsverfahren umgesetzt und an das Ziel weitergeleitet.Entstanden ist sipconf aus mehreren Gründen. Einerseits verwendet sipconf zur AnrufsignalisierungSIP, weil die ITU-T Alternative H.323 zu komplex und umfangreich ist. Das Modellder Konferenz-Zentrale wurde gewählt, da Multicast noch nicht weit genug verbreitetist und somit im voraus Benutzergruppen ausschließt.Für diese Arbeit interessant ist das Konzept zum Mischen von Audio-Informationen. Diesist interessant für den Einsatz des Media-Prozessors als Konferenz-Zentrale.

54 Kapitel 3. Anforderungen und ZieleG.711 uLinearAbspielverzögerungDADVIDBGSMLinearLinearX=A+B+CX−A=B+CX−CX−BEESende zu AG.711 uSende zu BDVICDESende zu CGSMperiodischer ZeitgeberDAudio DecoderEAudio Encoder3.4. ZusammenfassungAbbildung 3.8.: Audio-Mixer von sipconfDieses Kapitel gab anhand einer Beschreibung der vorhandenen Infrastruktur für IP-Telefonieeine Einführung in den Kontext dieser Arbeit. Die durchgeführte Analysen von praktischenBeispielen aus der IP-Telefonie sowie verschiedenen Mbone-Konferenzen haben zueiner Definition von Funktionen für den Media-Prozessor und der Notwendigkeit eines modularenSystems geführt. Mit diesen Ergebnissen und den Erkenntnisse aus den verwandtenArbeiten soll eine Architektur für einen Media-Prozessor entwickelt werden.

4. ArchitekturDas folgende Kapitel beschreibt die Architektur für ein modulares System eines Media-Prozessors. Dabei werden verwendete Modelle, Begriffe und Schnittstellen zwischen denModulen und zur Steuerung definiert.4.1. AufbauDiese Architektur soll ein modulares System für Media-Prozessoren definieren. Die Modularitätwird durch die Teilung der Komponente in einen Kern und eine Modul-Steuerungerreicht, wie es in Abbildung 4.1 veranschaulicht wird. Der Kern verwaltet die Konferenzenund die verwendeten Ressourcen und verfügt über die Grundfunktionen zur Steuerung vonKonferenzen. Zur Erweiterung der Fähigkeiten kann der Kern über die Modul-SteuerungAnfragen nach verfügbaren Modulen stellen. Dabei können vier verschiedene Arten vonModulen angefordert werden. Welche grundlegenden Funktionen der Kern zur Verfügungstellt und welche Modul-Arten es gibt wird im folgenden beschrieben.Kern desMedia−ProzessorsKonferenz−VerwaltungKonferenzKonferenzModul−SteuerungFilter Erweiterung SteuerungTransportAbbildung 4.1.: Aufbau eines Media-ProzessorsFunktionenDie Management-Funktion beschreibt die Fähigkeit eines Media-Prozessors mehrere parallelstattfindende Konferenz zu verwalten. Dafür wird ein Modell benötigt, das es ermöglicht,die Elemente einer Konferenz von anderen zu unterscheiden. Verwendet wird dafüreine Erweiterung des Konferenz-Modells von MEGACO (siehe Abschnitt 2.3.1).Die Vermittlungs-Funktion definiert eine komplexe sowie grundlegende Aufgabe des Media-Prozessors. Dabei sind verschiedene Arten von Netzen zu unterstützen, was sich in unterschiedlichenQuellen und Zielen widerspiegelt. Mögliche Varianten sind:

56 Kapitel 4. Architektur• RTP-End-SystemDie Medienströme werden zwischen zwei RTP-Quellen ausgetauscht. Auf der Transportschichtwird beispielsweise UDP verwendet, das auf IP aufsetzt.• Lokale GeräteDie Medienströme werden von einem lokalen Gerät wie einer Soundkarte gelesenoder auf diese geschrieben. Damit kann der Media-Prozessor beispielsweise in einemIP-Telefonie-Endpunkt eingesetzt werden. Zu dieser Gruppe von Quellen gehört auchein ISDN-Anschluß. 1• DateienDateien können zur Aufzeichnung von Gesprächen oder zum Abspielen von vordefiniertenAnsagen verwendet werden. Diese Funktion ist beispielsweise beim Einsatzals Anrufbeantworter von Nutzen.Die Mixer-Funktion kann aus mehreren Medienströmen einen einzelnen Medienstrom erzeugen,der alle Informationen enthält. 2 Um dies zu realisieren, muß jede im Media-Prozessorverwaltete Konferenz eine zentrale Instanz (Kontext) besitzen, an die alle Medienströmeder Konferenz geleitet werden. In dieser Instanz muß die Mixer-Funktion integriertwerden. Diese Funktion ist für den Media-Prozessor notwendig, wenn er als Konferenz-Zentrale eingesetzt wird.ModuleDie Transport-Module des Media-Prozessors sollen die Vermittlung zwischen verschiedenenNetzen realisieren, d.h. jedes Modul enthält eine Implementierung eines speziellen Protokollsfür die Vermittlungschicht. Da Netze sich in ihren Fähigkeiten unterscheiden können,muß der Media-Prozessor Methoden zur Abbildung dieser Fähigkeiten auf andere Netzebieten. Beispielsweise existiert in IPv6 eine direkte Unterstützung für den Transport vonMedienströmen (Flow Label, siehe Abbildung 2.2).Die Steuer-Module stellen externen Anwendungen eine Schnittstelle zur Verfügung, überdie sie den Media-Prozessor beeinflussen können. Da dieser in verschiedensten Konstellationeneingesetzt werden soll, ist die Möglichkeit zur Wahl einer passenden Schnittstelleeine wichtige Funktion. Beispielsweise kann eine einmalige Initialisierung beim Startdes Media-Prozessors ausreichen. Andererseits kann eine bidirektionale Kommunikationmit dem Media-Prozessor erforderlich sein, um z.B. Statusmeldungen zu empfangen oderum eine weitere Konferenz ohne einen Neustart dynamisch zu instantiieren. Ein möglichesSteuer-Modul kann z.B. eine Implementierung des MEGACO-Protokolls enthalten, um eineIntegration in IP-Telefonie-Systeme zu ermöglichen.Die Filter-Module des Media-Prozessors sind zuständig für eine entsprechende Anpassungdes Kodierungsverfahrens eines Medienstroms an die jeweils anderen Teilnehmer. JedesModul kennt genau ein Kodierungsverfahren, welches es in verschiedene Varianten einerlinearen Kodierung umwandeln kann. Zusätzlich muß jedes Modul fähig sein, diese Dekodierungumzukehren.1 Dafür muß in dem Rechner eine ISDN-Karte installiert sein.2 Die Qualität der Medienströme muß dabei auf einen gemeinsamen Nenner gebracht werden, was dazu führenkann, daß die Qualität einzelner Medienströme reduziert wird. Ein gewisser Verlust von Informationenkann dabei nicht ausgeschlossen werden.

4.2. Konferenz-Modell 57Die Erweiterungs-Module bieten spezielle Funktionen, die auf die Basis-Fähigkeiten einesEndpunktes in einer Konferenz aufgesetzt werden können. Das Senden und Empfangenvon Medienströmen ist die Basis eines Endpunktes. Die Erweiterungs-Module können dieseMedienströme analysieren und manipulieren. Beispielsweise kann es für einen Anrufbeantwortervon Nutzen sein, DTMF in den Medienströmen zu erkennen, um auf diese zureagieren. Solche Informationen können mittels dieser Erweiterungen erkannt und an dieexterne Steuereinheit gemeldet werden. Zusätzlich ist es den Modulen möglich, die zu sendendenDaten zu beeinflussen, indem eigene Fragmente integriert werden. Ein Beispiel fürdiese Funktion ist das Erzeugen von DTMF.4.2. Konferenz-ModellIn der Konferenzverwaltung wird ein Modell verwendet, daß auf den Grundideen vonMEGACO basiert. Das MEGACO-Konferenz-Modell enthält die beiden Elemente Kontextund Termination. Diese Objekte sowie einige ihrer Eigenschaften werden für die Architekturdes Media-Prozessors übernommen. Um die Parallelität von Konferenzen in das Modellzu integrieren wird ein weiteres Element, der Konferenz-Controller, definiert. Dieses Objektbietet eine generische Schnittstelle, um jedes Kontext- und jedes Termination-Objektzu beeinflussen. Dabei werden die Informationen durch die Hierarchie der Objekte, wie inAbbildung 4.2 dargestellt, durchgereicht.Konferenz−ControllerKontextKontextTerminationTerminationTerminationTerminationAbbildung 4.2.: Informationsfluß im Konferenz-ModellIm folgenden werden die angepaßten Kontext- und Termination-Objekte und der Konferenz-Controllervorgestellt. Einige der beschriebenen Deskriptoren stammen aus MEGACOund sind für den Einsatz im Media-Prozessor modifiziert. Alle nicht beschriebenen Deskriptorenund Eigenschaften aus MEGACO sind für die Architektur nicht definiert. Dadas MEGACO-Protokoll als Schnittstelle für den Media-Prozessor einsetzbar sein soll, istbei der Anpassung der Deskriptoren für den Aufgabenbereich des Media-Prozessors, daraufgeachtet worden, daß eine Abbildung auf die Definitionen von MEGACO möglich ist.Zu den Beschreibungen der Objekte dieser Architektur werden Schnittstellen definiert. Diesebeschreiben eine mögliche Variante der Kommunikationsschnittstelle in einer Pseudo-Programmiersprache. Die spezifizierten Rückgabewerte, Parameter und Funktionsnamendienen nur der besseren Verständlichkeit und sind nicht verpflichtend. Eine Implementierungdieser Architektur muß nur ähnliche Schnittstellen zur Verfügung stellen, die aller-

58 Kapitel 4. Architekturdings die exakt gleiche Funktionalität bieten.4.2.1. TerminationDas Termination-Objekt steht stellvertretend für einen Endpunkt in einer Konferenz. DieseObjekte empfangen bzw. senden Medienströme. Die charakteristischen Eigenschaften vonTermination-Objekten werden mittels Deskriptoren beschrieben. Diese werden in Kommandoszur Änderung bzw. Abfrage eingesetzt.Termination-Objekte können die Medienströme verändern. Unter Verwendung von Filter-Modulen werden z.B. die Kodierungsverfahren verändert oder durch Erweiterungs-Modulekönnen Signale verschickt werden, wenn ein bestimmtes Muster in den Medienströmen erkanntwird. Jedes Termination-Objekt kann verschiedene Filter- und Erweiterungs-Moduleauf die empfangenen bzw. zu versendenden Medienströme anwenden.Jedes Termination-Objekt hat einen Bezeichner (TerminationID), der das Objekt innerhalbeiner Instanz des Media-Prozessors eindeutig identifiziert. Eine TerminationID besteht auseiner beliebigen Abfolge von ASCII-Zeichen mit einer maximalen Länge von 255 Bytes. DerBezeichner kann eine Struktur enthalten, wie z.B. die Art der Termination gefolgt von einerNummer.Vordefinierte Bezeichner sind ALL und CHOOSE. Mit ALL werden alle Termination-Objekteund mit CHOOSE ein beliebiges einer Konferenz ausgewählt. Die Wahl trifft der Media-Prozessor entsprechend den verbleibenden Ressourcen.Ein spezielles Termination-Objekt ist durch die Bezeichnung ROOT gekennzeichnet. DiesesObjekt existiert solange wie die zugehörige Instanz des Media-Prozessors. Alle zu erzeugendenTermination-Objekte werden von dem ROOT-Objekt kopiert, d.h. alle zu diesem Objekthinzugefügten Erweiterungs-Module sowie der Modus werden als initiale Werte übernommen.Der Modus eines Termination-Objektes bestimmt das grundsätzliche Verhalten. MöglicheModi sind SendOnly, ReceiveOnly, SendReceive, Inactive und Loopback. Ein Termination-Objekt mit dem Modus SendOnly leitet empfangene Medienströme nicht weiter. Umgekehrtverhält sich ein Termination-Objekt im Modus ReceiveOnly. Der Standard-Modus ist Send-Receive. Ist eine Termination im Modus Inactive, so werden Medienströme in beiden Richtungenignoriert. Im Loopback-Modus werden die empfangenen Medienströme innerhalbder selben Termination weitergeleitet. In jedem Modus außer dem Inactive-Modus könnenFilter-Module auf die Medienströme angewendet werden. Dadurch kann der Media-Prozessor mit einem einzelnen Termination-Objekt im Loopback-Modus als Übersetzer vonKodierungsverfahren (Transcoder) eingesetzt werden.Zur Steuerung der Termination-Objekte, d.h. zur Zuweisung und zum Auslesen von Deskriptoren,soll eine Schnittstelle wie die folgende definiert sein. Dabei wird durch denBool’schen Rückgabewert der Erfolg der Funktion ausgedrückt.bool apply ( Descriptor desc )Dieser Funktion kann jeder beliebige für eine Termination definierte Deskriptor übergebenwerden. Dabei werden die im Deskriptor enthalten Eigenschaften von der Terminationübernommen.bool request ( Descriptor &desc )Um die aktuellen Werte von Eigenschaften abzufragen, ist diese Funktion zu verwen-

4.2. Konferenz-Modell 59den. Dabei werden die im übergebenen Objekt enthaltenen Eigenschaften gesetzt,d.h. die zurückgegebenen Informationen hängen vom Typ von desc ab.bool sendData ( TerminationID tid, Pointer data, int length)Die Daten, die das Termination-Objekt versenden soll, werden durch diese Funktionvom zugehörigen Kontext-Objekt übergeben. Die Technik für den Datenaustauschzwischen Termination und Kontext kann in den einzelnen Implementierungen variieren.DeskriptorenDie Eigenschaften einer Termination werden in Deskriptoren zusammengefaßt. Diese werdenals Parameter sowie als Rückgabewerte von Kommandos eingesetzt. Die Architektur desMedia-Prozessors definiert neun Deskriptoren, die auf ein Termination-Objekt angewendetwerden können.Der Mode-Deskriptor enthält einen Modus für ein Termination-Objekt. Sofort nach demSetzen des neuen Modus (durch die Funktion apply) muß das Termination-Objekt seinVerhalten dementsprechend anpassen.Der Remote-Deskriptor definiert die Art des Medienstroms, den das Termination-Objektempfängt. Es gibt genau zwei Varianten, einen Medienstrom zu beschreiben. Die erste Methodeverwendet einen wohldefinierten RTP-Payload-Typ aus einem RTP-Profil. Diese Methodekann für alle möglichen Medientypen eingesetzt werden, für die ein RTP-Profil definiertist. Die zweite Methode erlaubt die Definition von eigenen Formaten von Audio- undVideoströmen. Dabei sollen Frame- sowie Sample-basierte Kodierungsverfahren unterstütztwerden.Der Local-Deskriptor beschreibt den Medienstrom, den das Termination-Objekt versendet.Dabei können genau die selben Methoden zur Beschreibung verwendet werdenwie beim Remote-Deskriptor. Beide Deskriptoren müssen an ein neu instantiiertesTermination-Objekt übergeben werden, da keine Standardwerte definiert sind.Der Address-Deskriptor enthält Beschreibungen von Adressen für Quelle und Ziel einesTermination-Objektes. Unterschieden wird zwischen drei Adreßarten, die in der Tabelle4.1 beschrieben werden.AdreßtypNetworkFileBeschreibungEine Adresse dieses Typs besteht aus zwei Transportadressen.Eine definiert das Ziel und die andere die lokal zu verwendendeAdresse für ankommende Medienströme. Die lokaleTransportadresse ist optional. Ist der lokale Port nichtdefiniert, so wird dieser vom Betriebssystem bestimmt. dielokale Netzadresse wird nur bei Endpunkten benötigt, diemehrere besitzen.Dieser Typ wird eingesetzt, wenn das Termination-Objektdie zu übertragenden Medienströme aus einer Datei lesenbzw. die empfangenen Medienströme in eine Datei schreibensoll. Der Modus des Termination-Objektes bestimmt,welche der beiden Vorgänge ausgeführt wird. Die Dateienmüssen mit einem eindeutigen Pfad angegeben werden.weiter ⊲

60 Kapitel 4. ArchitekturAdreßtypDeviceBeschreibungUm ein Termination-Objekt mit einem lokalen Gerät zu verbinden,wird dieser Typ von Adresse eingesetzt. Beispieledafür wären ISDN-Anschlüsse, Mikrofone, Lautsprecheroder Head-Sets. Angegeben werden die Geräte mittels eindeutigersystemspezifischer Bezeichner.Tabelle 4.1.: Quell- und Ziel-AdreßtypenDer Filter-Deskriptor aktiviert bzw. deaktiviert den Einsatz eines Filter-Moduls ineinem Termination-Objekt. Dafür bietet der Deskriptor die beiden Operationen Add undRemove. Auf welchen Medienstrom das Filter-Modul angewendet werden soll, kann zusätzlichim Deskriptor spezifiziert werden. Bei keiner Angabe wird das Modul für beide Medienströmeeingesetzt. Welches Modul für diese Funktion zu verwenden ist, wird anhandder Definitionen aus dem Remote- und Local-Deskriptor vom Termination-Objektbestimmt. Welche Funktion des Filter-Moduls benutzt wird, hängt von der Richtung derMedienströme ab. Empfangene Medienströme werden dekodiert und zu sendende Datenwerden kodiert. Diese Technik ermöglicht es, mit einem einzigen Termination-Objekt einenTranscoder zu realisieren.Der Package-Deskriptor bietet Erweiterungen der Funktionalität einer Termination.Der Deskriptor wird verwendet, um Erweiterungs-Module zum Termination-Objekt hinzuzufügenoder zu entfernen. Empfangene und zu sendene Medienströme werden an Erweiterungs-Moduleweitergegeben. Diese können die Medienströme verändern, wobei auchdas Löschen sowie Hinzufügen von Fragmenten möglich ist. Identifiziert werden Erweiterungs-Moduledurch eine eindeutige Nummer und einen beschreibenden Namen.Wie bei MEGACO kann ein Erweiterungs-Modul (Package)) optionale Definitionen von Ereignissen(Events) und Signalen (Signals) enthalten. Ereignisse werden an die externeSteuereinheit übermittelt, wenn bestimmte Muster im Medienstrom erkannt werden. DieSignale hingegen erzeugen vordefinierte Muster (z.B. DTMF). Diese werden vom Erweiterungs-Modulin den Medienstrom eingefügt.Der Signals-Deskriptor dient zum Aktivieren bzw. Deaktivieren von Signalen. Dabeikann mit einem Deskriptor eine Menge von Signalen beeinflußt werden. Zusätzlich zumneuen Status ist bei Signalen einer der drei Typen aus Tabelle 4.2 festzulegen.Signal-TypOnOffTimeoutBriefBeschreibungDas Signal wird solange gesendet, bis es explizit deaktiviertwird.Das Signal wird gesendet, bis es deaktiviert wird oder eindefiniertes Zeitintervall abgelaufen ist. Das Intervall wird inMillisekunden angegeben.Das Signal ist durch seine Definition auf ein festes Zeitintervallfestgelegt und beendet sich selbsttätig. Das Intervallwird in Millisekunden festgelegt.Tabelle 4.2.: verschiedene Signal-Typen

4.2. Konferenz-Modell 61Die zu aktivierenden Signale werden in der Reihenfolge ausgeführt, wie sie im Signals-Deskriptor spezifiziert sind. Eine Parallelität in der Ausführung von Signalen ist nicht möglich.Der Events-Deskriptor dient zum Aktivieren bzw. Deaktivieren von Ereignissen. Diedurch ein Erweiterungs-Modul transportieren Medienströme werden auf bestimmte Musteruntersucht. Bei der Erkennung eines Musters, wird das zugehörige Ereignis an die externeSteuereinheit gesendet.Mit dem Deskriptor können mehrere Ereignisse in ihrem Status beeinflußt werden. Dabeikönnen mehrere Ereignisse zur gleichen Zeit aktiv sein.Der State-Deskriptor ermöglicht das Ändern bzw. Abfragen des Status eines Termination-Objektes.Erlaubte Werte sind Run, Stop, Pause und Resume. Der initiale Statuseines Objektes ist Stop. Ein Termination-Objekt kann den eigenen Status verändern. Gesetztwerden kann nur der Status Stop oder Pause. Verändert des Objekt den Status, wirdein abrufbarer Text gespeichert, der den Grund für die Statusänderung enthält. Dieser Textkann mittels des State-Deskriptors abgefragt werden.4.2.2. KontextEin Kontext umfaßt die Menge von Termination-Objekten, die an einer Konferenz beteiligtsind. Eine Aufgabe eines Kontext-Objektes ist die Steuerung des Flusses der Medienströmezwischen den einzelnen Termination-Objekten. Bietet ein Media-Prozessor die optionaleFunktionalität eines Mixers, so wird auch diese Aufgabe vom Kontext-Objekt übernommen.Identifiziert werden Kontext-Objekte durch die ContextID. Innerhalb der Instanz einesMedia-Prozessors muß diese eindeutig sein. Wie die TerminationID besteht die ContextIDaus einer Zeichenkette basierend auf dem ASCII-Zeichensatz.Spezielle Bezeichner für Kontext-Objekte sind CHOOSE und ALL. Mit CHOOSE wird demMedia-Prozessor die Wahl des Kontext-Objektes überlassen. Die Wahl wird entsprechenddes Kommandos, in dem die ContextID eingesetzt wird und den verbleibenden Ressourcendurchgeführt. Der Bezeichner ALL wählt alle vorhandenen Kontext-Objekte aus.Ein besonderes Kontext-Objekt ist durch den Bezeichner NULL gekennzeichnet. In diesemObjekt können Termination-Objekte existieren, die aktuell nicht in einer Konferenz eingesetztwerden. Die Medienströme aktiver Termination-Objekte im NULL-Kontext werdennicht weitergeleitet.Jedes Kontext-Objekt hat einen Typ, der die grundlegende Funktionalität charakterisiert.Mögliche Werte sind CtxAudio, CtxVideo, CtxData, CtxSync und CtxNull. Die ersten dreiTypen spezifizieren die Art der Informationen, die in dem Kontext transportiert werden.Pro Kontext-Objekt wird nur ein Medientyp unterstützt. Um Konferenzen mit mehrerenMedientypen zu verwalten gibt es Kontext-Objekte vom Typ CtxSync. Diese Objekte verwaltenselbst keine eigenen Termination-Objekte, sondern dienen nur zur Synchronisationanderer Kontext-Objekte. Implementierungen müssen die Typen CtxAudio, CtxVideo undCtxNull unterstützen. Der Typ CtxNull bezeichnet den NULL-Kontext und kann nur einmalvorkommen.Um die Eigenschaften von Kontext-Objekten zu verändern, werden, wie bei den Termination-Objekten,Deskriptoren verwendet. Für Kontext-Objekte sind drei Deskriptoren definiert.Der Routing-Deskriptor ermöglicht die Veränderung der Weiterleitungsregeln eines

62 Kapitel 4. ArchitekturKontext-Objektes. Ohne die Anwendung eines solchen Deskriptors werden die Medienströmeeines Termination-Objektes im Kontext an die jeweils anderen weitergeleitet. Grundsätzlichexistieren zwei Arten von Definitionen für Routing-Informationen. Forwarding definiertWeiterleitungsregeln, in denen TerminationIDs einer Liste von TerminationIDs zugewiesenwerden, an die die Medienströme verschickt werden. Eine Definition der FormA = B, C, D besagt, daß die Medienströme des Termination-Objektes A an die ObjekteB, C und D verschickt werden. Ein Routing-Deskriptor vom Typ Forwarding ohne eineListe von Zuweisungen entspricht der Standardeinstellung eines Kontext-Objektes. Dieandere Art der Routing-Informationen, Mixing, beschreibt welche Medienströme gebündeltan ein Termination-Objekt geschickt werden. Der Term E = F, G, H definiert, daßdie Medienströme von F, G und H gemischt und dann als ein resultierender Medienstroman E weitergeleitet werden. Ein Routing-Deskriptor vom Typ Mixing, dessen Listevon Zuweisungen leer ist, besagt, daß jedes Termination-Objekt in dem Kontext nur einenMedienstrom zugesendet bekommt, der aus einer Bündelung aller anderen Medienströmebesteht. Die Art Mixing muß nur von Implementierungen unterstützt werden, welche dieoptionale Funktionalität eines Mixers zur Verfügung stellen.Der Type-Deskriptor ermöglicht das Setzen des Typs eines Kontext-Objektes. Alle Typenbis auf CtxNull können einem Kontext-Objekt zugewiesen werden. Der spezielle TypCtxSync bekommt als zusätzliche Information eine Liste von ContextIDs der zu synchronisierendenKontext-Objekte.Der State-Deskriptor wird verwendet, um den Status eines Kontext-Objektes zu verändern.Mögliche Stati sind Run, Stop, Resume und Pause. Ein Kontext-Objekt kann seineneigenen Status nicht verändern.Ein Kontext muß eine Schnittstelle wie die folgende bieten, um die Menge der verwaltetenTerminationen beeinflussen zu können. Mit dem Bool’schen Rückgabewert der Funktionwird der Erfolg der Ausführung signalisiert.TerminationID addTermination ( Termination term )Das Termination-Objekt term wird zum Kontext hinzugefügt. Der Rückgabewert istdie vom Kontext generierte TerminationID.bool removeTermination ( TerminationID tid )Zum Entfernen des Termination-Objektes mit der TerminationID term wird dieseFunktion eingesetzt.bool modifyTermination ( TerminationID tid, Descriptor desc )Diese Funktion übergibt den Deskriptor desc an das Termination-Objekt mit derTerminationID tid.bool requestTermination ( TerminationID tid, Descriptor &desc )Zum Abfragen der Eigenschaften des Termination-Objektes mit der TerminationIDtid wird diese Methode verwendet. Die Eigenschaften werden in den Deskriptordesc eingetragen.bool apply ( Descriptor desc )Der Deskriptor desc wird auf das Kontext-Objekt angewendet.bool request ( Descriptor desc )Um die aktuellen Werte von Eigenschaften abzufragen, ist diese Funktion zu verwenden.Welche Eigenschaften zurückgegeben werden, hängt vom Typ des übergebenenDeskriptor-Objektes ab.

4.2. Konferenz-Modell 63recvData ( TerminationID tid, Pointer data, int length )Diese Funktion wird von Termination-Objekten aufgerufen, wenn neue Fragmenteeines Medienstroms angekommen sind. Diese Funktion ist nur ein Beispiel. Je nachImplementierung kann der Mechanismus zum Weiterleiten der Daten an das Kontext-Objekt variieren.dispatch ( EventInfo info )Erweiterungs-Module verwenden diese Funktion zur Weiterleitung von Informationenüber auftretende Ereignisse. Informationen zu dem jeweiligen Ereignis werdenals Argument info übergeben. Die Technik, um die Ereignis-Informationen weiterzuleiten,ist den Implementierungen überlassen.4.2.3. Konferenz-ControllerDie beiden beschriebenen Objekte Termination und Kontext werden zur Abbildung voneiner Konferenz eingesetzt. Ein Media-Prozessor soll die Fähigkeit besitzen, mehrere Konferenzenparallel zu verwalten und zu steuern. Hierfür wird der Konferenz-Controller benötigt.Dieser verwaltet die einzelnen Kontext-Objekte und kann über diese auch die Termination-Objektesteuern (siehe Abbildung 4.2). Zusätzlich wird der Konferenz-Controllervon den Modulen der Benutzungsschnittstelle (siehe Abschnitt 4.3.4) eingesetzt, um denSteuereinheiten die Verwaltung der Konferenzen zu ermöglichen. Die Schnittstelle (API)dieser Steuereinheit muß Zugriff auf alle Eigenschaften der Termination- und Kontext-Objekte bieten. Eine minimale Steuereinheit soll Kommandos zur Verfügung stellen, dieeine Funktionalität entsprechend der folgenden Schnittstelle bereitstellen.TerminationID createTermination ( ContextID cid = „NULL“ )Dieses Kommando ermöglicht das explizite Erzeugen eines Termination-Objektes.Wird der optionale Parameter cid nicht angegeben, gehört die Termination in denspeziellen NULL-Kontext. Im anderen Fall wird das kreierte Objekt dem spezifiziertenKontext-Objekt zugeordnet. Die TerminationID des neu erzeugten Objektes ist derRückgabewert des Kommandos.bool moveTermination ( TerminationID t, ContextID dest, ContextID src )Das Termination-Objekt t wird vom Kontext-Objekt src in das Objekt dest verschoben.Existiert das Kontext-Objekt dest nicht, so wird es erzeugt. Die Objekte tund src müssen hingegen vorhanden sein. Der NULL-Kontext kann als Quelle oderals Ziel der Verschiebung eingesetzt werden.bool removeTermination ( ContextID cid, TerminationID t = „ALL“ )Zum Entfernen von Termination-Objekten wird dieses Kommando verwendet. Wirddas optionale Argument t nicht angegeben, so ist sein Wert auf ALL gesetzt. Dies führtzum Löschen aller Termination-Objekte im angegebenen Kontext-Objekt. CHOOSEhingegen kann nicht als Bezeichner eingesetzt werden.bool modifyTermination ( ContextID cid, TerminationID t, Descriptor desc )Mit diesem Kommando kann ein Deskriptor mit neuen Einstellungen an ein Termination-Objektübergeben werden. Mit der speziellen TerminationID ALL können auchalle Termination-Objekte eines Kontext-Objektes verändert werden. Wird zusätzlich

64 Kapitel 4. Architekturder ALL-Bezeichner für den Kontext eingesetzt, so wird auf alle momentan im Media-Prozessor existieren Termination-Objekte die Änderung angewendet. Hat der Parametert den Wert ROOT, dann wird der Parameter ContextID nicht evaluiert und dieModifikation wird an der ROOT-Termination vorgenommen. Als Deskriptoren sindnur die für Termination-Objekte definierten erlaubt. Bei diesem Kommando ist dieVerwendung des Bezeichners CHOOSE für die TerminationID und für die ContextIDerlaubt.bool requestTermination ( ContextID cid, TerminationID t, Descriptor &desc )Diese Funktion bietet die Möglichkeit, Eigenschaften eines Termination-Objektes abzufragen.Der Typ des Objektes desc bestimmt, welche Eigenschaften zurückgegebenwerden. Für die ContextID können die speziellen Bezeichner ALL und CHOOSE nichteingesetzt werden.bool modifyContext ( ContextID cid, Descriptor desc )Um Deskriptoren auf ein Kontext-Objekt anzuwenden, wird dieses Kommando aufgerufen.Bei diesem Kommando kann der spezielle Bezeichner NULL nicht benutztwerden, da dieses Kontext-Objekt nicht verändert werden kann. Bezeichnet cid einnicht existentes Kontext-Objekt, meldet die Funktion einen Fehler. Nur für Kontext-Objekte definierte Deskriptoren können als Argument desc eingesetzt werden.bool requestContext ( ContextID cid, Descriptor &desc )Die Eigenschaften eines Kontext-Objektes können mit diesem Kommando abgefragtwerden. Zurückgegeben werden die Eigenschaften des Deskriptor-Typs, von dem auchdesc ist. Die speziellen Bezeichner CHOOSE, ALL und NULL sind bei diesem Kommandonicht erlaubt.Die definierten Rückgabewerte der Funktionen erlauben nur eine minimale Fehlerbehandlung.Einer Implementierung ist die Methode der Erweiterung der Fehlererkennung und-behebung selbst überlassen.Die drei beschriebenen Komponenten des Konferenz-Modells und ihre Zuordnung zueinanderist in dem folgenden Diagramm 4.3 dargestellt. Jede Instanz eines Media-Prozessorshat exakt einen Konferenz-Controller. Dieser verwaltet eine beliebige Anzahl von Kontext-Objekten3 , die wiederum die Steuerung über eine beliebige Anzahl von Termination-Objektenausüben.4.3. ModuleEin Ziel bei der Entwicklung der Architektur ist die Erweiterbarkeit. Diese wird beim Media-Prozessor durch nachladbare Module realisiert. Diese sind nach ihrer Funktionalität in verschiedeneGruppen aufgeteilt. Im folgenden werden vier Arten dieser Module definiert. Fürdie Kommunikation mit dem Media-Prozessor muß eine einheitliche Schnittstelle für alleArten der Module spezifiziert werden. Diese muß eine Funktionalität wie in der folgendenDefinition bieten.bool capable ( Term term )Dient zur Prüfung, ob das Modul fähig ist, eine Aufgabe zu erledigen, die durch die3 Wobei jeder Media-Prozessor mindestens ein Kontext-Objekt besitzt, den NULL-Kontext.

4.3. Module 65Abbildung 4.3.: Aufbau des Konferenz-Modellsübergebene Bedingung term beschrieben wird. Das Objekt term enthält eine genaueBeschreibung der benötigten Fähigkeit sowie benötigte Parameter.Module generate ( Term term )Diese Funktion erzeugt eine Instanz des Moduls und übergibt zur Initialisierung dasObjekt term, welche zur Überprüfung mit der Funktion capable verwendet wurde.Bei dieser Funktion wird das Objekt benötigt, um die Parameter auszulesen.string description ( )Diese Funktion gibt eine textuelle Beschreibung der Funktion des Moduls zurück.Durch die capable-Funktion liegt die Fähigkeit zur Erkennung der eigenen Funktionalitätbei den Modulen. Diese Technik spart die Entwicklung einer generischen und komplexenMethode zur Beschreibung von Fähigkeiten der einzelnen Module. Bei sehr großen Mengenvon Modulen könnte diese Technik zu hohen Verzögerungen bei der Anforderung führen.Da bei der Anforderung von Modulen grundsätzlich nur eine Art von Modul nach der benötigtenFunktionalität befragt wird, ist die Menge der zu untersuchenden Module reduziert.Da auch pro Gruppe nur eine begrenzte Anzahl von Modulen bereitsteht, ist die tatsächlicheVerzögerung zum Auffinden des richtigen Moduls nur minimal.Die Abfrage der Funktionalität sowie die Instantiierung der Module wird von dem Plugin-Controller (Modul-Steuerung) übernommen (siehe Abbildung 4.4). Dieser implementiertdie systemabhängigen Funktionen, wie das Laden und den Zugriff auf die Funktionen.Module können ausschließlich von den Termination-Objekten angefordert werden. EineAusnahme bilden die Module für Benutzungsschnittstellen, die nur bei der Initialisierungdes Media-Prozessors erzeugt werden können. Die Aufgaben und die dafür zur Verfügunggestellten Schnittstellen der einzelnen Modul-Arten werden im folgenden beschrieben.

66 Kapitel 4. ArchitekturTerminationPlugin−ControllerTransport Filter Package ControllerAbbildung 4.4.: Verwaltung von Modulen4.3.1. TransportEine der Aufgaben des Media-Prozessors ist die Verbindung zwischen verschiedenartigenNetzen. Dafür werden Implementierungen der zu unterstützenden Protokolle der Vermittlungsschichtbenötigt. Diese werden in Transport-Module, wie in Abbildung 4.6 dargestellt,gekapselt. Welche Implementierung im speziellen Fall zu wählen ist, wird anhand der Transportadresseermittelt, die an die capable-Funktion übergeben wird.Das Kriterium, das der capable-Funktion eines Transport-Moduls übergeben wird, bestehtaus vier Komponenten, wie in Abbildung 4.5 dargestellt. Die ersten beiden Komponentensind die Netzadressen bzw. Namen des entfernten und lokalen Rechners. Die anderen zweiKomponenten sind Anwendungsadressen (Ports). Einer definiert die Zieladresse des Medienstromsauf dem entfernten Rechner, der zweite Port ist optional und kann die lokal zuverwendende Anwendung adressieren.Abbildung 4.5.: Address-Struktur eines Transport-ModulsEin Transport-Modul muß die drei Modi SendReceive, ReceiveOnly und SendOnly unterstützen.Nur im SendReceive-Modus muß das Modul für den Transport in beiden Richtungenvorbereitet werden. Im SendOnly-Modus sind nur die Netzadresse und der zugehörigePort des entfernten Rechners von Interesse. Hingegen ist im ReceiveOnly-Modus nur dielokale Transportadresse zu beachtet. Ist diese nicht definiert, so muß das Modul selbst einewählen. 4Implementierungen der Transport-Module müssen eine Schnittstelle entsprechend der folgendenSpezifikation zur Verfügung stellen. Dabei geht es nur um die Existenz der einzelnenFunktionen und ihrer Aufgaben und nicht um die exakte Einhaltung der Rückgabewertebzw. Argumente.int open ( )Entsprechend des gewählten Modus werden die Verbindungen vorbereitet, d.h. dievom Betriebssystem bereitgestellte Abstraktion für Netzkommunikation wird initiali-4 Bei dieser Wahl ist das zugrundeliegende Betriebssystem zu befragen.

4.3. Module 67siert 5 . Negative Rückgabewert bedeuten ein Fehler in der Ausführung der Funktion.Alle anderen Werte sind eine eindeutige Nummer für den erfolgreich geöffneten Kommunikationskanal.bool close ( )Diese Funktion schließt den oder die geöffneten Kanäle und gibt die reserviertenRessourcen frei.bool send ( Pointer data, int length )Diese Funktion wird zum Versenden von Daten eines Medienstroms eingesetzt. DieArgumente data und length definieren einen Puffer, der die zu sendenden Datenenthält.int recv ( Pointer data, int max )Diese Funktion dient zum Empfangen von Daten. Das erste Argument enthält einenVerweis auf einen Puffer, in den die Daten geschrieben werden, das zweite Argumentlegt fest, wieviele Bytes maximal empfangen werden sollen. Diese Angabe entsprichtin der Regel der Größe des Puffers. Der Rückgabewert der Funktion enthält die Anzahlder tatsächlich empfangenen Bytes.int lastError ( String &description )Wenn eine der anderen Funktionen einen Fehler signalisiert, kann mittels dieser Funktioneine detailierte Beschreibung abgefragt werden. Der Rückgabewert ist eine eindeutigeFehlernummer, und die übergebene Zeichenkette enthält nach Aufruf derFunktionen die Beschreibung. Ist seit dem letzten Aufruf dieser Funktion kein Fehleraufgetreten, gibt die Funktion null zurück.Abbildung 4.6.: Aufbau eines Transport-ModulsDiese Schnittstellen-Definition enthält keine Möglichkeit zur Prüfung auf angekommeneDaten. Diese Funktionalität ist aus den Modulen ausgelagert. Durch die vom Betriebssystemzur Verfügung gestellte Abstraktion muß es möglich sein, diese Aufgabe unabhängig vonder Implementierung der Vermittlungsschicht auszuführen.4.3.2. FilterAudio- und Videodaten sind die in den meisten Multimedia-Konferenzen verwendeten Medientypen.Filter-Module, wie aus Abbildung 4.9, dienen zur Kodierung bzw. Dekodierungeines einzigen Kodierungsverfahrens. Diese Funktionalität kann der Media-Prozessor zumTranscoding und Mixen von Medienströmen einsetzen.5 Bei einer BSD-Socket-Schnittstelle entspricht dies einem Aufruf der Systemfunktionen socket und bind.Eventuell werden zusätzlich einige Optionen mittels setsockopt gesetzt.

68 Kapitel 4. ArchitekturZur Kommunikation zwischen den Filter-Modulen und dem Media-Prozessor muß eine Methodedefiniert sein, mit der die Kodierungsverfahren eindeutig beschrieben werden können.Dafür werden der Name des Verfahrens und eine variable Anzahl von Parametern wieAbtastrate, Anzahl der Kanäle und Paketgröße benötigt. Weitere Parameter hängen vondem jeweiligen Kodierungsverfahren ab.Die in Abbildung 4.7 dargestellten Strukturen bieten eine generische Beschreibung fürAudio- und Video-Informationen. Die Struktur Codec definiert den Medientyp und die Bezeichnungfür das Kodierungsverfahren. Als Bezeichner werden die MIME 6 -Media-Typenaus dem Internet Draft „MIME Type Registration of RTP Payload Formats“ [6] verwendet.Die weiteren Parameter sind in der Struktur CodecOptionSet definiert. Für Kodierungsverfahren,die zu den vordefinierten Parametern noch zusätzliche benötigen, sind vonder Implementierung Erweiterungsmöglichkeiten vorzusehen, wie sie in der Abbildung mituserDefined angedeutet sind.Abbildung 4.7.: Codec-Struktur für Filter-ModuleDie capable-Funktion der Filter-Module bekommt eine Codec-Struktur übergeben, wiesie in Abbildung 4.8 beispielhaft dargestellt ist. Das CodecOptionSet Input definiert dieParameter für die kodierten und Output für die dekodierten Mediendaten. In diesem Fallmuß das Filter-Modul eine Umsetzung zwischen den Abtastraten vornehmen. Ist das Modulin der Lage, das Kodierungsverfahren PCM-µ-Law zu verstehen, kann aber die Umsetzungnicht vornehmen, so ist eine Anforderung durch die capable-Funktion abzulehnen. DerImplementierung ist es überlassen, ob die Funktion zur Übersetzung der Parameter von denFilter-Modulen realisiert wird oder in den Kontext-Objekten.Die Schnittstelle eines Filter-Moduls muß Funktionen zur Dekodierung bzw. Kodierung derMediendaten zur Verfügung stellen. Die folgende Beschreibung ist ein Beispiel.6 MIME (Multipurpose Internet Mail Extensions) wird in E-Mails eingesetzt, um andere Datentypen wie beispielsweiseBilder zu integrieren.

4.3. Module 69Abbildung 4.8.: Beispiel einer Codec-Strukturbool encode ( Pointer data, int length )Die im Parameter data enthaltenen Daten werden entsprechend der Definition inden Parametern des Moduls kodiert.bool decode ( Pointer data, int length )Die übergebenen Daten werden entsprechend der Optionen dekodiert.Abbildung 4.9.: Aufbau eines Filter-Moduls4.3.3. ErweiterungenErweiterungs-Module haben die Möglichkeit, empfangene und zu sendende Daten auf einebeliebige Art und Weise zu verändern. Mittels Signalen können Erweiterungs-Module Fragmentein die Medienströme einfügen. Zusätzlich können diese Module eine Überwachungsfunktionbieten, die vordefinierte Muster erkennt und diese als Ereignisse an die externeSteuereinheit meldet. Für diese Aufgaben haben die Erweiterungs-Module die Möglichkeit,auf Filter-Module zurückzugreifen.Jedes Erweiterungs-Modul kann mehrere Signale definieren, die in beliebiger Reihenfolgesequentiell ausgeführt werden können. Identifiziert werden Signale anhand einer Nummer,die eindeutig sein muß. Zusätzlich besitzt jedes Signal einen beschreibenden Namenbeliebiger Länge.Die in Abbildung 4.10 dargestellten Signal-Objekte können Mediendaten unterschiedlicherDauer erzeugen. DTMF beispielsweise sind kurze Töne. Ein Besetzt-Zeichen hingegen hältan, bis der Anrufer auflegt. Diese verschiedenen Arten von Signalen werden auf die drei TypenBrief, Timeout und OnOff abgebildet. Die erzeugten Mediendaten der Signale könnenvon einem Termination-Objekt auf zwei verschiedene Arten angefordert werden. Mittelsder Funktion complete werden die kompletten Mediendaten abgefragt, die das Signalproduziert. Diese Methode ist nur bei Signalen des Typs Brief oder Timeout anzuwenden.Für Signale, deren Typ auf OnOff gesetzt ist, kann die zweite Methode verwendet werden.

70 Kapitel 4. ArchitekturMittels der Funktion fragment können aufeinander folgende Fragmente der Daten abgeholtwerden, bis das Signal deaktiviert wird. Als weiteres Argument wird ein Intervall inMillisekunden übergeben, das die maximale Dauer des zu liefernden Fragments definiert.Am Rückgabewert der Funktion kann die tatsächlich zurückgegebene Länge erkannt werden.Abbildung 4.10.: Aufbau eines SignalsEreignis-Objekte, wie aus Abbildung 4.11, überprüfen Medienströme auf spezielle Musterund melden diese bei Erkennung mittels einer EventInfo-Struktur aus Abbildung 4.12 andie externe Steuereinheit. Dabei kann ein Medienstrom parallel auf mehrere Muster überprüftwerden, die zu Ereignissen führen. In jedem Ereignis-Objekt existiert wie bei Signal-Objekten eine eindeutige Nummer zur Identifikation und ein beschreibender Name.Abbildung 4.11.: Aufbau eines Ereignis-ObjektesAbbildung 4.12.: Struktur zur Meldung von EreignissenEreignisse und Signale können Argumente haben, deren Anzahl nicht beschränkt ist. Fürdie einzelnen Ereignisse und Signale sind die Argumente, d.h. Anzahl und Typen, in demzugehörigen Erweiterungs-Modul zu definieren.Mögliche Typen für die Argumente sind Integer, Double, Bool, String, List und Enum (sieheAbbildung 4.13). Der Typ String basiert auf dem ASCII-Zeichensatz. Enum ist ein Aufzählungstyp,bei dem aus einem festdefinierten Nummernraum ein beliebiger Wert ausgewähltwird. List ist eine untypisierte Liste, d.h. es können Elemente der verschiedenen Typen ineiner Liste enthalten sein. Der Typ List kann ebenso als Element in einer Liste verwendetwerden.Ein Beispiel für ein parametrisiertes Ereignis ist die Meldung eines erkannten DTMF. DasArgument ist das erkannte Zeichen. Entsprechend kann ein Signal als Argument das Zeichenübergeben bekommen, welches als DTMF in den Medienstrom eingefügt werden soll.Ein Erweiterungs-Modul wird durch eine eindeutige Nummer identifiziert. Ein Name istals beschreibende Kennung zusätzlich zu definieren. Weitere Attribute eines Erweiterungs-Moduls sind die Listen der aktiven Ereignisse und Signale.Die Schnittstelle eines Erweiterungs-Moduls zur Verwaltung und Steuerung der Ereignisse

4.3. Module 71Abbildung 4.13.: Argumenten-Liste für Ereignisse und Signaleund Signale muß von der Funktionalität her der folgenden Definition entsprechen. DieBool’schen Rückgabewerte informieren über den Erfolg der Funktionen.bool addSignal ( int id, Enum type, PList args )Um Signal-Objekte zu auszulösen, wird diese Funktion verwendet. Als Argumentewerden die eindeutige Nummer, der Typ und die Liste der Argumente des Signalsübergeben.bool removeSignal ( int id )Diese Funktion entfernt das Signal-Objekt, welches durch die Nummer id identifiziertwird, aus der Liste der aktiven. Ist das Signal nicht in der Liste oder kann ausanderen Gründen nicht gelöscht werden, ist dies durch den Rückgabewert bekanntzugeben.bool addEvent ( int id, PList args )Äquivalent zu addSignal fügt diese Funktion ein Ereignis-Objekt in die Liste der aktivenein. Als Parameter werden die eindeutige Nummer und die Liste der Argumentefür das Ereignis übergeben.bool removeEvent ( int id )Das durch die eindeutige Nummer id identifizierte Ereignis-Objekt wird aus der Listeder aktiven entfernt.bool eval ( Pointer data, int length )Der übergebene Parameter data verweist auf die Mediendaten, welche zu überprüfensind. In dieser Funktion kann das Erweiterungs-Module die Daten verändern. BeiVeränderungen oder bei Erkennung eines Musters muß der Rückgabewert eine erfolgreicheAusführung der Funktion signalisieren.bool provide ( Pointer data, int length )Diese Funktion muß in regelmäßigen Abständen von dem Termination-Objekt aufgerufenwerden, wenn sich aktive Signal-Objekte in der Liste des Erweiterungs-Modulsbefinden. Aufgabe dieser Funktion ist die Erzeugung der der Mediendaten. Solangeder Rückgabewert positiv ist, werden auch die nächsten Fragmente des Medienstromsdurch die Funktion provide erstellt.

72 Kapitel 4. ArchitekturAbbildung 4.14.: Aufbau eines Erweiterungs-Modul4.3.4. SteuerungDie Steuer-Module aus Abbildung 4.14 bilden die Verbindung zu einer externen Steuereinheit.Identifiziert werden diese Module anhand eines eindeutigen Namens. Pro laufenderInstanz eines Media-Prozessors darf nur ein Steuer-Modul existieren.Die capable-Funktion dieser Module bekommt als Argument einen Modul-Namen übergeben.Ist der Name des Moduls gleich dem als Argument übergebenen, so muß die Funktiondie Anfrage positiv beantworten.Für die interne Kommunikation müssen die Steuer-Module, wie in Abbildung 4.15, eineSchnittstelle zur Verfügung stellen, deren Funktionalität dem folgenden Beispiel entspricht.bool init ( ConferenceControl control, List options )Diese Funktion wird direkt nach der Instantiierung des Moduls aufgerufen. Übergebenwerden als Argumente ein Verweis auf den Konferenz-Controller control sowieeine Liste von Optionen options, die zur Initialisierung dienen.void event ( EventInfo info )Diese Funktion wird aufgerufen, wenn ein Erweiterungs-Modul ein Ereignis meldet.Abbildung 4.15.: Aufbau eines Steuer-Modul4.4. Interne KommunikationIn den vorangegangenen Abschnitten wurden die Komponenten des Kommunikations-Modellssowie die einzelnen Module der Architektur vorgestellt. Wie diese Bestandteile desMedia-Prozessors intern miteinander kommunizieren, wird im folgenden Abschnitt anhandeines Beispiels beschrieben.In den Erklärungen werden Diagramme eingesetzt, um den Ablauf der Kommunikationenzu verdeutlichen. Dabei werden teilweise die Rückmeldungen der Funktionsaufrufe vernachlässigt.In diesen Fällen wird von einer positiven Rückmeldung ausgegangen, da sonstdie Kommunikation beendet ist.

4.4. Interne Kommunikation 73Fluß der MedienströmeAm Beispiel der einfachen Konferenz aus Abbildung 4.16, soll der Fluß der Medienströmeinnerhalb einer Konferenz verdeutlicht werden. Dargestellt wird in diesem Beispiel derAnruf eines Nutzers bei seinem Anrufbeantworter, um vorhandene Anrufe abzuhören. Miteinem ISDN-Endgerät ruft er über ein Gateway in einem IPv6-Netz den zentralen Anrufbeantworteran, der sich in einem IPv4-Netz befindet. Zur Vermittlung zwischen den beidenIP-Netzen wird ein Media-Prozessor eingesetzt. Dafür wird im Media-Prozessor eine Konferenzmit zwei Termination-Objekten aufgesetzt, wie in Abbildung 4.17 dargestellt.AnrufbeantworterISDNPSTNGSMIntranetIPv6IntranetIPv4GatewayMedia−ProzessorAbbildung 4.16.: Beispiel: Vermittlung zwischen IPv4- und IPv6-NetzAbbildung 4.17.: Fluß der MediendatenDas Termination-Objekt RTP-1 repräsentiert den Anrufbeantworter aus dem IPv4-Netz.Der ISDN-Teilnehmer, der in der Abbildung nicht zu sehen ist, kommuniziert über das Gatewaymit dem Termination-Objekt RTP-2. Damit die vom Nutzer gesendeten DTMF erkanntwerden können, wird ein Erweiterungs-Modul von der Termination RTP-2 verwendet.Zum besseren Verständnis werden von den Termination-Objekten unterschiedliche Module

74 Kapitel 4. Architektureingesetzt. Für die Transport-Module werden eine IPv4- und eine IPv6- Variante verwendet.Dies soll das Blackbox-Prinzip der Module verdeutlichen.Das Termination-Objekt RTP-2 empfängt Daten von seinem Transport-Modul. Das Objektmuß den Puffer mit den empfangenen Daten an das Erweiterungs-Modul weitergeben, indem es die eval-Funktion des Moduls aufruft. In dem Beispiel wird ein DTMF erkannt. Dieserwird direkt an das Kontext-Objekt weitergeleitet. Dafür werden die Informationen durchdas Argument der Funktion dispatch übergeben. Die übergebene Struktur EventInfoenthält die Kennung und den Namen des Erweiterungs-Moduls und eine Argumentenliste.In diesem Fall enthält die Liste den erkannten DTMF.Nachdem das Erweiterungs-Modul die Daten verarbeitet hat, werden diese an das Kontext-Modulweitergereicht, wobei dem Kontext die Quelle der Daten mit übergeben wird.In dem Beispiel ist dem Kontext ein Routing-Deskriptor zugewiesen worden, in demdefiniert ist, daß nur Daten von RTP-1 an RTP-2 geleitet werden. Auf die Beispielsituationabgebildet bedeutet dies, daß der Nutzer keine Medienströme an den Anrufbeantwortersenden kann. Dies ist nicht nötig, da die vom Nutzer gesendeten DTMF vorher erkannt undan das Kontext-Objekt geleitet werden. Von dort werden diese an die externe Steuereinheitübertragen, die mit der Steuereinheit des Anrufbeantworters kommuniziert und so dieBefehle übermittelt.Als Reaktion auf den empfangenen DTMF sendet der Anrufbeantworter Mediendaten, diedas Termination-Objekt RTP-1 empfängt. Da dieser Termination keine Erweiterungs-Modulezugeordnet sind, können die Daten direkt an das Kontext-Objekt weitergegeben werden.Nach den Definitionen im Routing-Deskriptor gibt der Kontext die Daten an das Termination-ObjektRTP-2. Diese werden wiederum an das Erweiterungs-Modul gegeben unddaraufhin an das Transport-Modul, welche die Daten über das Netz schickt.Auf- und Abbau einer KonferenzAnhand des Beispiels aus Abbildung 4.18 sollen alle Phasen einer Konferenz von der Instantiierungbis zur Beendigung vorgeführt werden. Dabei wird die Verwendung der definiertenSchnittstellen für die Erzeugung und Manipulation von Termination-Objekten demonstriert.Dargestellt wird in dem Beispiel ein Steuer-Modul, das über den Konferenz-Controller eine Konferenz aufbaut und wieder schließt. Verwaltet wird die Konferenz durchdas Kontext-Objekt CTX-1. Desweiteren existiert noch das spezielle Kontext-Objekt NULLin dem sich ein Termination-Objekt befindet, das einem ISDN-Anschluß zugeordnet ist undein Termination-Objekt, das während des Vorgangs erzeugt wird. In der folgenden Beschreibungwird der Ablauf anhand von vier Phasen erläutert.1. Phase – ErzeugungDie erste Phase beginnt mit der Erzeugung der Termination-Objekte und ihrer Initialisierung.In der Abbildung 4.18 wird exemplarisch eine Konferenz aufgebaut, in der ein einzigesTermination-Objekt instantiiert wird. Mit dem Befehl createTermination wird dieErzeugung des Objektes ausgeführt. Das Argument CTX-1 gibt den Kontext an, in den dasTermination-Objekt bewegt werden soll. Existiert der Kontext nicht, so wird ein neues Kontext-Objekterzeugt. Dieses gibt die TerminationID des neu erzeugten Termination-Objekteszurück.

4.4. Interne Kommunikation 75Abbildung 4.18.: Aufbau einer Konferenz2. Phase – KonfigurationIn der nächsten Phase wird das Termination-Objekt TERM-1 konfiguriert. Mit dem Mode-Deskriptorwird das Termination-Objekt in den Modus SendReceive gebracht. Für die beidenMedienströme, die in diesem Modus zu verwalten sind, werden mittels des Remote- undLocal-Deskriptor die Medientypen definiert. Der Address-Deskriptor legt fest,daß eine Kommunikation mit dem Rechner, dessen IP-Adresse 134.102.218.11 ist, aufgebautwird. Die zu verwendenden Anwendungsadressen sind auf dem entfernten Rechner45678 und lokal 45876.3. Phase – InitialisierungMit dem Befehl moveTermination wird das Termination-Objekt ISDN-1 aus dem NULL-Kontext in den Kontext CTX-1 verschoben. In der Kommunikation zwischen dem Steuer-Modul und dem entsprechenden Kontext wird der Befehl zum Verschieben aufgeteilt in dasLöschen aus dem NULL-Kontext und dem Hinzufügen in den neuen Kontext CTX-1. Da

76 Kapitel 4. Architekturein neu erzeugtes Kontext-Objekt initial den Status Stop hat, muß der Kontext mittels desState-Deskriptors aktiviert werden, in dem der Status auf Run gesetzt wird.4. Phase – BeendigungZur Beendigung der Konferenz wird der Status auf Stop zurückgesetzt und das Termination-ObjektTERM-1 aus dem Kontext entfernt. Abschließend kann das Objekt ISDN-1 ausdem Kontext CTX-1 entfernt werden. Dies würde zur Freigabe der Ressourcen des Kontext-Objektesführen, da keine weiteren Termination-Objekte vorhanden sind.4.5. ZusammenfassungDiese Architektur definiert ein modulares System für einen Media-Prozessor. Die geforderteErweiterbarkeit dieses Systems ist durch die Modul-Technik erreicht.Das Konferenz-Modell der Architektur basiert auf den Ideen von MEGACO. Die Erweiterungdes Modells um den Konferenz-Controller schränkt das Modell nicht ein, sondern erweitertes um eine generische Schnittstelle zur Verwaltung von parallel ablaufenden Konferenzen.Durch die Steuer-Module kann ein der Umgebung entsprechender Steuerungsmechanismusgewählt werden. Zur Integration in die IP-Telefonie kann beispielsweise ein Steuer-Modulfür das MEGACO-Protokoll entwickelt werden. Bei Mbone-Konferenzen, die manuell initialisiertwerden, reicht ein Modul zum Parsieren der Kommandozeilen-Parameter. Diesermöglicht eine optionale Anpassung an die Umgebung.Die Verwendung der richtigen Protokolle für die Vermittlungsschicht ist durch die Transport-Modulefür die Termination-Objekte völlig transparent. Eine einheitliche Schnittstellesowie die Modul-Technik machen dies möglich.Die Fähigkeiten der Termination-Objekte können mittels der Erweiterungs-Module beliebigerweitert werden. Die generischen Definitionen von Ereignissen und Signalen bieteneine gut erweiterbare Kommunikation mit der externen Steuereinheit und die Möglichkeit,beliebige Daten in die Medienströme zu integrieren.Durch die Filter-Module können Teilnehmer, die unterschiedlichste Kodierungsverfahrenfür ihre Medienströme einsetzen, in Konferenzen miteinander verbunden werden. Auchbieten sie Unterstützung für die Mixer-Funktion.Somit ist die Entwicklung eines modularen Systems zur Adaption von Steuer- und Medienströmenin Multi-Protokollumgebungen anhand dieser Architekturbeschreibung möglich.

5. Implementierung„A Computer is a state machine. Threads are for people who can’t programstate machines.“ – Alan CoxIn diesem Kapitel wird die Implementierung MEPRO der Architektur für Media-Prozessorenvorgestellt. In der Beschreibung wird speziell auf die Realisierung des Konferenz-Modellsund eine Technik zur Umsetzung der Module eingegangen. Zusätzlich wird eine eigeneImplementierung einer RTP-Bibliothek vorgestellt, die im Rahmen dieser Diplomarbeit entwickeltwurde. Beide Komponenten sind in der Sprache C++ beschrieben und wurdenausschließlich auf dem Betriebssystem Linux getestet.5.1. RTP-BibliothekFür eine RTP-Bibliothek, die im Media-Prozessor eingesetzt wird, müssen spezielle Anforderungenerfüllt werden:• Eine Instantiierung mehrerer unabhängiger RTP-Sessions muß möglich sein.• Die Transport-Funktion muß aus der Bibliothek ausgegliedert sein. Da der Media-Prozessor eigene Transport-Module bereitstellt, muß die Möglichkeit gegeben sein,die RTP- bzw. RTCP-Pakete mittels dieser zu versenden.• Jedes Feld der RTP- und RTCP-Pakete muß veränderbar sein. Einerseits muß die Bibliothekdie Fähigkeit besitzen, Pakete weitestgehend selbständig zusammenzusetzen,andererseits muß der Benutzer die Möglichkeit haben, den Wert jedes Feldes zubeeinflussen.• Die Bibliothek muß einen passiven Modus bieten. Dabei werden keine eigenen RTPbzw.RTCP-Pakete generiert, sondern fertige Pakete weitergeleitet. Diese Funktionalitätbenötigt der Media-Prozessor z.B. zur Vermittlung zwischen Teilnehmern in unterschiedlichenNetzen und in jeder anderen Konstellation, bei der der Media-Prozessorselbst keine RTP-Quelle ist.• Ankommende Pakete sowie Änderungen von Zustandsinformationen müssen an dieAnwendung gemeldet werden. Dabei muß die Anwendung bestimmen können welcheInformationen wie detailiert tatsächlich an sie weitergeleitet werden.Alle evaluierten RTP-Bibliotheken können zumindest einige dieser Anforderungen nichterfüllen. Aus diesem Grund wurde eine eigene Bibliothek entwickelt, deren Aufbau undSchnittstelle im folgenden beschrieben wird.

78 Kapitel 5. Implementierung5.1.1. AufbauDer Aufbau der RTP-Bibliothek, wie sie in Abbildung 5.1 dargestellt ist, wird anhand derwichtigsten Klassen, ihrer Kommunikation untereinander und der Schnittstelle für Anwendungenbeschrieben.Abbildung 5.1.: Struktur der RTP-BibliothekDie Klasse RtpSession ist die Schnittstelle zur Anwendung. Ein Objekt dieser Klasse spiegeltein RTP-End-System wider. Je nach gewählten Optionen werden von einer RtpSessionObjekte der Klassen RtpReceiver, RtcpReceiver, RtpTransmitter und RtcpTransmitter instantiiert.Welche Objekte ausgewählt werden, hängt vom Modus der RtpSession ab. Send-Receive ist der Standard-Modus. In diesem Fall werden alle vier Objekte erzeugt und derrepräsentierte Endpunkt kann als Empfänger und Sender von RTP- und RTCP-Paketen eingesetztwerden. Die Modi SendOnly und ReceiveOnly erzeugen jeweils nur die Empfängerbzw. Sender-Objekte für RTP und RTCP.Die Empfänger-Objekte nehmen Daten vom Netz entgegen, parsieren diese und meldendie erkannten Daten an die Anwendung. Diese Ereignis-gesteuerte Technik basiert auf der

5.1. RTP-Bibliothek 79Bibliothek libextcpp 1 , die einen generischen Rahmen dafür bereitstellt. Dadurch ist es derAnwendung möglich die gewünschten Informationen auszuwählen. Bei der RTP-Bibliothekkann die Anwendung zwischen vier Arten von Informationen wählen. Um die Informationenzu empfangen muß die Anwendung vordefinierte Schnittstellen implementieren,in dem sie Instanzen von Handler-Klassen erzeugt. Für jede Art von Information existiertgenau eine Handler-Klasse wie es in Abbildung 5.2 dargestellt ist. Nur durch die Instantiierungund den Aufruf der Funktion attach der jeweiligen Handler-Instanz ist die Anwendungregistriert und empfängt die Informationen. Mit der Funktion detach kann derInformationsfluß jederzeit unterbrochen und durch ein wiederholten Aufruf von attachwieder aufgenommen werden.Abbildung 5.2.: Ereignis-KlassenPktHandlerAnwendungen, die diesen Handler implementieren können RTP- und RTCP-Paketeempfangen. Dies ermöglicht eine effiziente Technik zur Weiterleitung.DataHandlerDieser Handler empfängt nur die Payload-Daten der RTP-Pakete. Einem RTP-Mixerspart dieser Handler die Extrahierung des RTP-Payloads.CompHandlerRTP-Monitore können diesen Handler einsetzen. Die empfangenen RTCP-Pakete werdenintern in die einzelnen Komponenten zerteilt und aufbereitet an diesen Handlerübergeben.SrcHandlerAn diesen Handler werden Informationen über hinzugekommene und verlorengegangeneRTP-Quellen geschickt. Damit hat die Anwendung einen Überblick über dieaktuellen Teilnehmerzahlen.Mit der Klasse RtpTransmitter können RTP-Pakete auf zwei verschiedene Art versendet werden.Für Instanzen, wie RTP-Translator, können extern erzeugte RTP-Pakete an den Rtp-Transmitter übergeben werden, die unverändert verschickt werden. Im anderen Fall wirdan den RtpTransmitter nur die RTP-Nutzlast übergeben. Der RTP-Kopf wird vom RtpTransmitteranhand der Parameter der RtpSession konstruiert und mit der Nutzlast zusammenversendet.1 Diese Bibliothek wurde im Zusammenhang mit der C++-Mbus-Implementierung der AG Rechnernetze entwickelt.

80 Kapitel 5. ImplementierungRTCP-Pakete werden durch Objekte der Klasse RtcpTransmitter versendet. Im aktiven Modusgenerieren diese Objekte aus den gesammelten RTP-Statistiken RTCP-Pakete und versendendiese in den berechneten Intervallen. Der passive Modus ist für RTP-Translator, diekeine eigenen RTCP-Pakete erzeugen, sondern nur andere RTCP-Pakete weiterleiten.Die Klassen RtpPacket und RtcpPacket sind Kapselungen für einzelne Pakete. Diese bietendem Benutzer eine einfache und komfortable Schnittstelle zum Manipulieren und Auslesender Paket-Köpfe. Desweiteren haben beide Klassen Funktion zur Anpassung der Byte-Orderund verfügen über eine dynamische Speicherverwaltung. RtpPacket hat zusätzlich Methodenzum Zugriff auf die Nutzlast und RtcpPacket bietet Funktionen zum Extrahieren dereinzelnen Komponenten des RTCP-Paketes.Zusätzlich zu den drei Modi kann das Verhalten der Sende- und Empfangs-Objekte durchOptionen beeinflußt werden. Aus Erfahrungen und der Begutachtung anderer RTP-Implementierungensind einige Definition des RFC 1889 nicht immer berücksichtigt worden. Dieaufgelisteten Optionen bieten die Möglichkeit das Verhalten der RTP-Bibliothek an diese Implementierungenanzupassen. Auch wenn diese Verhalten nicht dem Standard entsprechen,sind sie für die Praxis unverzichtbar.RTP_WEAK_VALIDATIONWerden RTP-Pakete von unbekannten RTP-Quellen empfangen, dürfen diese nur „aufProbe“ angenommen werden. Ist diese Option nicht gesetzt, werden nur Pakete vonbekannten Quellen angenommen, d.h. neue Quellen werden nur anhand von RTCP-Paketen akzeptiert.RTP_PROMISCUOUSMit dieser Optionen gesetzt können unbekannte RTP-Quellen angenommen und alsgültig gekennzeichnet werden, d.h. die Probezeit entfällt.RTP_NO_LOOPIst diese Option gesetzt, verhindert sie das Empfangen von eigenen RTP- bzw. RTCP-Paketen.Speziell für den Einsatz im Media-Prozessor wurde eine weitere Option hinzugefügt. Ohnedas Setzen der Optionen RTP_PASSIV_MODE versendet eine RtpSession durch das RtcpTransmitter-Objektselbsttätig RTCP-Pakete in den korrekten Intervallen. Arbeitet derMedia-Prozessor als Weiterleitungseinheit (der Modus eines Kontext-Objektes ist auf Forwardgesetzt), dann müssen nicht nur die RTP-Pakete, sondern auch die RTCP-Pakete unberührtweitergeleitet werden. Dazu darf die RtpSession keine eigenen RTCP-Pakete generieren.5.1.2. SchnittstelleDie RTP-Bibliothek bietet eine generische Schnittstelle für Anwendungen. Zur Anbindungsind von einer Anwendung die zwei Klassen Notifier und Network, aus Abbildung 5.3,zu implementieren. Die Struktur AppContext ist die Schnittstelle für die internen Klassender Bibliothek, um auf die Implementierungen zu zugreifen. Mit der Klasse Network isteine Abstraktion für die Netzkommunikation geschaffen. Diese soll die Möglichkeit bieteneinen Kommunikationskanal für RTP und RTCP zu verwalten. Dabei entspricht ein Kanaleiner bidirektionalen Verbindung. Funktionen wie Öffnen, Schließen, Senden und Empfangenmüssen auf diese Kanäle anwendbar sein. Desweiteren muß eine Überwachung dieser

5.2. MePro 81Kanäle möglich sein. Bei ankommenden Daten soll dies einem ausgewählten Objekt mitgeteiltwerden. Zusätzlich sollen Zeitgeber (Timer) registriert werden können, die nach Ablaufeines Zeitintervalls eine ausgewählte Funktion aufrufen. Dabei sollen diese Timer nureinmal ausgelöst und daraufhin automatisch gelöscht werden. Der Abbruch einer Überwachungmuß jeder Zeit möglich sein. Diese Funktionalität wird durch die Klasse Notifierbereitgestellt.Speziell die abstrakte Schnittstelle ermöglicht den vielseitigen Einsatz dieser RTP-Bibliothek.Durch die Unabhängigkeit von der systemspezifischen Abstraktion der Netzkommunikation,kann die Bibliothek RTP- sowie RTCP-Pakete über beliebige Netze transportieren. DieEntkopplung von einer eigenen Mainloop bietet eine einfache Integration ohne die Verwendungvon Threads und vermeidet somit Nebenläufigkeitsprobleme.Abbildung 5.3.: Generische Schnittstelle der RTP-Bibliothek5.2. MeProMEPRO ist eine Implementierung der Architektur für Media-Prozessoren. Bei der Entwicklungvon wurde besonders auf die folgenden Schwerpunkte der Architektur geachtet:• Schnittstellen für alle definierten Modul-Arten• Dynamisches Laden von Modulen• Definitionen aller Deskriptoren• Transport-Module für IPv4 und IPv6 (Unicast sowie Multicast)• Filter-Module für die Kodierungsverfahren PCM-A-Law und PCM-µ-Law• Ein Steuer-Modul für Kommandozeilen-Parameter.• Eine Termination für RTP-Ströme (Typ Audio)• Ein Kontext zur Weiterleitung (Modus Forwarding)• Einen Konferenz-Controller5.2.1. AufbauDas Verhalten eines Media-Prozessors wird durch empfangene Daten gesteuert. Jedes Daten-Fragmentbeispielsweise aus einem RTP-Strom, einer Datei oder aus einem ISDN B-Kanal veranlaßt den Media-Prozessor zu einer Reaktion, die sein weiteres Handeln bestimmt.

82 Kapitel 5. ImplementierungEine solche Vorgehensweise wird als Ereignis-gesteuert bezeichnet. Dieses Verhalten wirdvon MEPRO ausgenutzt. Anstatt Threads für die einzelnen Konferenzen einzusetzen, um eineParallelität zu erzeugen, basiert MEPRO auf der Bibliothek libnotifier 2 , die konfigurierbareEreignisse an definierbare Funktionen melden kann. Als Ereignisse können SchreiboderLesevorgänge auf einem Kommunikationskanal und Timer verwendet werden. Umdie Ereignisse verarbeiten zu können, verwendet die Bibliothek eine Klasse Notifier, dieeine Mainloop zur Verfügung stellt.Zusammen mit einer Instanz des Notifier bilden zwei weitere Klassen die Basis von ME-PRO, wie in Abbildung 5.4 dargestellt. Die PluginCtrl-Klasse bietet eine Schnittstelle zurSteuerung der Module und die Klasse MeProCtrl ist der Konferenz-Controller.Abbildung 5.4.: Abhängigkeiten innerhalb MEPRODie PluginCtrl implementiert die Fähigkeit des dynamischen Ladens von Modulen. Dafürwird eine Bibliothek eingesetzt, die zu der Sammlung von GNU Standard-C-Bibliotheken(glibc) gehört. Diese bietet die Möglichkeit beliebige Bibliotheken (Shared Objects) zu laden.Unter Verwendung von Symbolen können Funktionen in den Bibliotheken gefundenund aufgerufen werden.Beim Start von MEPRO wird von der Instanz des PluginCtrl die globale Konfigurationsdateigelesen. Diese ist unter /etc/mepro.conf zu finden. Sollte im Home-Verzeichnis des Benutzersnoch eine Konfigurationsdatei mit dem Namen ˜/.mepro.conf vorhanden sein,so kann damit die globale Konfiguration erweitert bzw. überschrieben werden. Die folgendeBeispieldatei enthält die fünf definierten Abschnitte, aus denen die Dateien bestehen.[global]ctrl_module=cmdlinemax_conf=10max_term=20log_error=/usr/var/log/mepro-error.loglog_info=/usr/var/log/mepro-info.log[network]ipv4-sock=/usr/lib/mepro/libipv4.soipv6-sock=/usr/lib/mepro/libipv6.so[user-interface]cmdline=/usr/lib/mepro/libcmdline.so[converter]PCMu=/usr/lib/mepro/libpcm-u.soPCMa=/usr/lib/mepro/libpcm-a.so2 Diese Bibliothek wurde im Zusammenhang mit der C++-Mbus-Implementierung der AG Rechnernetze entwickelt.

5.2. MePro 83[package]dtmf=/usr/lib/mepro/libdtmf.soDer Abschnitt global enthält Einstellungen, die das grundlegende Verhalten von MEPRObeeinflussen. Der Eintrag ctrl_module legt anhand des Names das zu verwendende Steuer-Modulfest. Mit den Einträgen max_conf und max_term werden Obergrenzen für dieAnzahl der verwalteten Konferenzen bzw. Terminationen festgelegt. Durch diese Einstellungenkönnen die von MEPRO maximal eingesetzten Ressourcen kontrolliert werden. Wirdeine der Obergrenzen erreicht, lehnt MEPRO weitere Anforderungen ab. Eine Kontrolle dermaximalen Bandbreite ist momentan noch nicht möglich. Die Einträge log_error undlog_info in dem Abschnitt definieren zwei Dateien, in den Fehlermeldungen bzw. Informationenzum Ablauf protokolliert werden. Alle weiteren Abschnitte definieren die dynamischladbaren Bibliotheken, in denen Module für den Media-Prozessor enthalten sind.Der Abschnitt network definiert Transport-Module, uinterface enthält Steuer-Module,converter beschreibt die Filter-Module und Package enthält eine Liste von Erweiterungs-Modulen. Alle Module werden nach dem Schema angeben.Der hier angebende Modul-Name hat nichts mit dem beschreibenden Namen einesModuls zu tun, sondern dient nur der besseren Lesbarkeit der Konfigurationsdatei. DerDateiname muß mit einem absoluten Pfad angegeben werden, damit die Datei gefundenwerden kann.Zusätzlich zu den Konfigurationsdateien kann MEPRO über die Kommandozeilen-Optionenaus der folgenden Liste gesteuert werden.-h, --helpGibt eine Liste aller möglichen Argumente inklusive einer kurzen Beschreibung ausund beendet MEPRO.-c, --config Gibt den Dateinamen der zu verwendenden globalen Konfigurationsdatei an.-u, --user-config Setzt den Dateinamen der Benutzer-Konfigurationsdatei. Einstellungen aus dieser Dateiüberschreiben die globalen Einstellungen.-i, --interface Definiert das zu verwendende Steuer-Modul. Dabei ist der Name des Moduls einzusetzenund nicht die Bezeichnung aus der Konfigurationsdatei.-l, --list-interfacesGibt eine Liste aller vorhandenen Module aus und beendet MEPRO. Existiert die Funktiondescription in einem Modul, so wird zusätzlich die Beschreibung ausgegeben.--Wenn dem ausgewählten Steuer-Modul Optionen übergeben werden sollen, so müssendie beiden Striche als Trennzeichen eingefügt werden. Beispielsweise gibt derAufruf mepro -i cmdline -- -t die Option -t an das Steuer-Modul mit demNamen cmdline.

84 Kapitel 5. Implementierung5.2.2. ModuleDas Laden sowie Instantiieren von Modulen wird durch die Template-Klasse IPluginLoaderrealisiert, d.h. von ihren konkreten Instanzen. Für die verschiedenen Module müssen derKlassen nur die Typen des Moduls und der zugehörigen Bedingung, die an die capable-Funktion übergeben wird, bekannt gemacht werden. Durch die Definition der einheitlichenSchnittstelle in der Architektur ist diese Vereinfachung für alle Modul-Typen möglich.Die Instanzen des IPluginLoader, für die verschiedenen Modul-Typen, werden von einemObjekt der PluginCtrl-Klasse verwaltet. Für die Termination-Objekte ist diese Klasse dieSchnittstelle zu den Modulen.Transport-ModuleMEPRO implementiert die Protokolle IPv4 und IPv6 der Vermittlungsschicht. Beide Transport-Moduleunterstützen Unicast und Multicast.Der capable-Funktion der Module wird eine Struktur übergeben, die zwei Texte und zweiPorts enthält. Die Texte enthalten einen Rechnernamen oder eine IP-Adresse. Beide Moduleprüfen mittels der Funktion getaddrinfo, wie sie im RFC 2553 [15] beschrieben wird,ob der angebene Adreßtyp unterstützt wird.Die Implementierungen der Module gehen davon aus, daß das zugrundeliegende Systemeine BSD-Socket-Schnittstelle bereitstellt. Die open-Funktion der Module löst die angegebeneAdresse auf, kreiert ein Transport-Objekt, setzt die benötigten Optionen und bindetdas Objekt an die lokale Anwendungsadresse. Ist diese nicht definiert, so wird vom Systemeine bestimmt. Sollte in dem Text eine Multicast-Adresse enthalten sein, so werden dieentsprechenden Optionen hier gesetzt. Die drei Funktionen send, recv und close sinddirekte Abbildungen auf Socket Funktionen.Controller-ModuleMEPRO implementiert für die Steuerung ein Modul, daß über Kommandozeilen-ArgumenteKonferenzen instantiieren kann. Diese Schnittstelle ist einfach in der Bedienung und vielseitigeinsetzbar und eignet sich somit für eine erste Variante eines Steuer-Moduls.Da Controller-Modul sowie MEPRO Argumente von der Kommandozeile lesen, wurde zurTrennung die Option -- als Separator verwendet. Alle Argumente davor werden an denMeProCtrl weitergereicht, und alle anderen Optionen werden an das ausgewählte Controller-Modulweitergeleitet. Die Optionen des Controller-Moduls sind in der folgendenAuflistung enthalten.-h, --helpGibt eine Liste aller möglichen Argumente inklusive einer kurzen Beschreibung ausund beendet MEPRO.-t, --termination (host,rx,tx,codec)Dieser Parameter definiert eine Termination inklusive vier Optionen. host definiertden entfernten Rechner. Der zugehörige Port wird durch tx angeben und rx legt denlokalen Port fest. Ist der Port null, wird er vom System bestimmt. Die Option codecwird in dem Format RTP: angeben. wird durch eineRTP-Payload-Nummer ersetzt, die in einem RTP-Profil definiert ist.

5.2. MePro 85Mit dem folgenden Kommando kann eine Konferenz zwischen den Rechnern dolormin.\tzi.de und ringelreigen.ipv6.tzi.de instantiiert werden, in der Audio-Informationenunter Verwendung des PCM-µ-Law-Kodierungsverfahren übertragen werden:mepro -i cmdline -- -t (dolormin.tzi.de,45000,45002,RTP:0) \-t (ringelreigen.ipv6.tzi.de,45002,45000,RTP:0)Filter-ModuleDie implementierten Filter-Module basieren auf der Bibliothek libst, die mit dem Programmsox [39] ausgeliefert wird. Die Module selbst bilden nur eine Brücke zwischen der Bibliothekund MEPRO.Die Bibliothek bietet eine Schnittstelle mit sechs Funktionen für jedes unterstützte Kodierungsverfahren:startreadInitialisiert das Einlesen der Audio-Informationen indem z.B. Parameter gesetzt oderKopf-Informationen parsiert werden.readDer Funktion wird ein Puffer sowie dessen Länge übergeben. Gelesen werden so vieleSamples wie in den Puffer passen. Die Daten werden als 32-Bit-Worte in den Puffergeschrieben.stopreadBeendet den Lesevorgang und gibt eventuell belegte Ressourcen frei.startwriteInitialisiert den Schreibvorgang der Audio-Informationen, indem z.B. Parameter gesetztoder Kopf-Informationen geschrieben werden.writeÜbergeben wird der Funktion ein Puffer und dessen Länge. Die aus dem Puffer gelesenenAudio-Informationen werden in die Kodierung umgewandelt.stopwriteBeendet den Schreibvorgang und korrigiert eventuell Kopf-Informationen.Diese Schnittstelle bietet Funktionen, um Audio-Informationen zu kodieren bzw. zu dekodieren.Zusätzlich können die Audio-Informationen in Dateien gespeichert bzw. aus Dateiengelesen werden.5.2.3. Konferenz-ModellMEPRO implementiert grundlegende Varianten der drei Komponenten des Konferenz-Modells.Die Termination-Objekte akzeptieren alle der definierten Deskriptoren, wobei die Package-,Events- und Signals-Deskriptoren nicht verarbeitet werden. Als Quellen werdenRTP-Ströme akzeptiert. Die Anbindung an die RTP-Bibliothek unterstützt alle definiertenHandler-Klassen.

86 Kapitel 5. ImplementierungDie Kontext-Objekte sind auf Audio-Informationen ausgelegt, können aber auch Video-Informationenweiterleiten. Im Forwarding-Modus ist eine Unterstützung für den Routing-Deskriptor implementiert. Alle weiteren definierten Deskriptoren werden erkannt undbis auf den State-Deskriptor ausgewertet. 3 Desweiteren wird das spezielle Kontext-Objekt mit dem Bezeichner NULL instantiiert und kann zur Zwischenlagerung von Termination-Objekteneingesetzt werden.Die exemplarische Implementierung des Konferenz-Controller unterstützt alle Funktionender Schnittstelle, wie sie in der Architektur für Media-Prozessoren definiert ist, d.h. Termination-und Kontext-Objekte können erzeugt, modifiziert und gelöscht werden.5.3. ZusammenfassungViele der ausgeführten Tests haben sich mit der eigenen RTP-Bibliothek beschäftigt. Dafürist das Programm RAT als Kommunikationspartner eingesetzt worden. Die Tests haben ergeben,daß die eigene RTP-Bibliothek sich korrekt nach dem Standard verhält und Kommunikationskanälezu anderen RTP-End-Systemen aufgebaut werden können. RTCP ist soweitimplementiert, daß andere RTP-End-Systeme die Pakete verstehen und akzeptieren.MEPRO wurde in mehreren Langzeittests als Vermittlung zwischen zwei RAT-Endpunkteneingesetzt. Außer der Weiterleitung von RTP-Paketen wurde dabei auch die Kommunikationzwischen einem IPv4- und einem IPv6-Endpunkt getestet. Bei allen Tests hat sich MEPRO alsstabiler und anpaßbarer Media-Prozessor erwiesen, der zur Erweiterung der Funktionalitätbeigetragen hat.Die Implementierung bietet eine gute Basis für weitere Entwicklungen und ist im jetzigenStadium ein stabile und gut konfigurierbare Implementierung eines Media-Prozessors.Durch die dynamische Einbindung von Bibliotheken als Module ist eine hervorragendeMöglichkeit für Erweiterungen geschaffen. Diese Eigenschaften sowie die strikte Einhaltungder Definitionen aus der Architektur machen MEPRO zu einem vielseitig einsatzfähigenMedia-Prozessor.3 Für diesen Deskriptor ist eine Erweiterung der gesamten Status-Verwaltung notwendig.

6. Zusammenfassung und AusblickZiel dieser Diplomarbeit ist die Entwicklung einer verteilten Architektur für ein modularesSystem zur Adaption von Steuer- und Medienströmen. Anhand dieser soll die Implementierungeines Media-Prozessors realisiert werden, die sich an den Konzepten und derDefinition der Architektur orientiert.6.1. Stand der EntwicklungDie entwickelte Architektur bietet wohldefinierte Modelle, Strukturen und Kommunikationsschnittstellenzur Realisierung eines Media-Prozessors. Die wichtigen Aufgaben wieVermittlung zwischen verschiedenen Netzen, Umwandlung von Kodierungsverfahren, Analyseund Manipulation der Daten und Schnittstelle zur Kommunikation mit der externenSteuereinheit sind in Modulen definiert, um die Erweiterbarkeit in diesen Bereichen zuermöglichen. Das definierte Modell für Konferenzen, das aus den Ideen von MEGACO entstandenist, bietet eine einfache und modulare Beschreibung. Die Erweiterung durch denKonferenz-Controller ermöglicht mittels der wohldefinierten Schnittstelle und des Deskriptoren-Konzeptseine überschaubare und mächtige Möglichkeit zur Steuerung mehrerer parallelerKonferenzen.MEPRO ist die Implementierung der Architektur für Media-Prozessoren, die im Rahmendieser Diplomarbeit entwickelt wurde. Diese bietet viele Möglichkeiten zur Erweiterungder Funktionalität. Die dafür bereitgestellte Technik ermöglicht das dynamische Einbindenvon Modulen, die zur Erweiterung eingesetzt werden. Ein weiterer Aspekt bei der Entwicklungvon MEPRO war die Effizienz. Dafür wurde bei der Implementierung darauf geachtet,daß die Pakete der Medienströme, die mehrmals pro Sekunde durch den Media-Prozessorgeleitet werden, nicht unnötig dupliziert werden und immer den direkten Weg innerhalbdes Media-Prozessors zum Ziel nehmen.Zur Integration in Mbone- und IP-Telefonie-Konferenzen stellt die Architektur und damitauch MEPRO das Modell der externen Steuereinheiten zur Verfügung. Die Steuer-Moduleermöglichen eine dynamische Anpassung an verschiedene Steuereinheiten durch die Bereitstellungeiner entsprechenden Schnittstelle.Die im Rahmen dieser Diplomarbeit entwickelte RTP-Bibliothek ist durch ihren modularenAufbau vielseitig einsetzbar. Mit dem generischen Ereignis-Mechanismus kann jede Anwendungdie gewünschten Informationen herausfiltern und verarbeiten. Durch die Entkopplungvon einem vordefinierten Protokoll für die Vermittlungsschicht ist der Einsatz in beliebigenNetzen realisierbar.Beide Implementierungen, MEPRO und die RTP-Bibliothek, bieten durch ein stabiles Grundgerüst,modulare Strukturen und wohldefinierte Schnittstellen gute Möglichkeiten zur Erweiterungihrer Funktionalität. Naheliegende Erweiterungen für die Implementierungenwerden im folgenden anhand der einzelnen Komponenten beschrieben.

88 Kapitel 6. Zusammenfassung und Ausblick• TerminationDas Termination-Objekt von MEPRO bietet grundlegende Funktionalitäten für denTransport von RTP-Daten. Wichtige Erweiterungen wären die Unterstützung weitererQuellen wie Dateien oder Geräte. Da MEPRO beispielsweise als Anrufbeantworter indie IP-Telefonie-Infrastruktur der AG Rechnernetze integriert werden kann, um dieAnsagetexte abzuspielen und die Anrufe aufzuzeichnen, ist diese Art von Quelle einenaheliegende Erweiterung. Werden auch Geräte wie z.B. ISDN-Karten unterstützt,kann auch eine Anbindung an das herkömmliche Telefonnetz realisiert werden.• KontexteEine der wichtigsten Erweiterungen ist die Unterstützung des Routing-Deskriptors.Dies ermöglicht eine exaktere Steuerung der Medienströme. Damit verbunden ist dieUnterstützung der Mixer-Funktion.Unabhängig davon, welches Konferenz-Modell gewählt wird, muß ein beteiligter Endpunktoder ein zusätzlich eingeführtes zentrales System die Medienströme mischen,sobald mehr als zwei Teilnehmer involviert sind. Für diese Art von Problem kann eineKonferenz-Zentrale eingesetzt werden, die durch einen Media-Prozessor und eine externeSteuereinheit, welche die Signalisierung übernimmt, realisiert werden kann.Aus diesem Grund ist die Erweiterung des Media-Prozessors zu einer Konferenz-Zentrale eine der nächsten Aufgaben.• ModuleModule sind die Komponenten, die den Media-Prozessor zu einem besonders anpassungsfähigenSystem machen. Eine Vielzahl von Modulen ermöglicht dem Media-Prozessor eine Eingliederung in möglichst viele verschiedene Konstellationen. Je mehrProtokolle für die Vermittlungsschicht ein Media-Prozessor unterstützt, desto mehrNetze können in einer Konferenz verbunden werden. Auch die anderen Modul-Artenkönnen bei steigender Anzahl die Fähigkeiten des Media-Prozessors entscheidend erweitern.Die von MEPRO unterstützten Protokolle der Vermittlungsschicht, IPv4 und IPv6, dekkeneinen wesentlichen Teil der interessanten Netze ab. Hingegen sind die Mengeder vorhandenen Filter-Module gegenüber der möglichen Kodierungsverfahren sehrgering. Um als Übersetzer in Konferenzen zu fungieren, ist eine Erweiterung dieserModule sehr wichtig. Bei einer Anbindung an das herkömmliche Telefonnetz sinddie Erkennung sowie die Erzeugung von DTMF von Interesse. Diese Funktionalitätkönnte mittels eines Package-Moduls realisiert werden. Dies sind nur Beispiele fürnaheliegende Erweiterungen. Im Einsatz wird sich zeigen, welche weiteren Modulesich als notwendig und nützlich erweisen.• IntegrationDer Einsatz von MEPRO in Mbone-Konferenzen bedarf keiner speziellen Integration.Die meisten dieser Konferenzen werden zuvor angekündigt und manuell konfiguriert.Dies gestattet es, MEPRO bei Bedarf zu konfigurieren und zu starten.Für die Integration in die IP-Telefonie müssen auf Seiten von MEPRO sowie der jeweiligenIP-Telefonie-Infrastruktur Änderungen vorgenommen werden. MEPRO benötigtein interaktives Steuer-Modul, das einer externen Steuereinheit ermöglicht, Rückmeldungenüber die erteilten Kommandos zu erhalten. Die Steuereinheit wiederum mußin das IP-Telefonie-System integriert werden. Denkbar wäre die Verwendung einesSIP-Proxy oder eines H.323-Gatekeeper als Steuereinheit. Diese Komponenten sindin die Anrufsignalisierung involviert und haben die Möglichkeit, die Adressen der

6.2. Weiterer Ausblick 89Medienströme zu beeinflussen, um den Media-Prozessor zwischen die Endpunkte zustellen.6.2. Weiterer AusblickDas Internet besteht aus einer Vielzahl von heterogenen Netzen, und dieser Zustand wirdsich auch in Zukunft nicht ändern. Somit ändert sich auch das grundsätzliche Szenario fürMultimedia-Konferenzen im Internet nicht. Es werden immer Komponenten erforderlichsein, die Medienströme über verschiedene Vermittlungsschichtsprotokolle transportierenund die Kodierungsverfahren der Medienströme für die einzelnen Teilnehmer anpassenkönnen.Die Multicast-Adressierung wird vielleicht in den kommenden Jahren noch in weiterenTeilnetzen des Internet unterstützt, so daß Mbone-Konferenzen bald zum Alltag gehören.Welche Konferenzumgebung sich in der IP-Telefonie durchsetzt, ist nicht absehbar.In Zukunft sollen MEPRO oder andere Implementierungen der Architektur für Media-Prozessorendafür sorgen, daß in beliebigen Multimedia-Konferenzen, ob Mbone oder IP-Telefonie,der Transport und die professionelle Verarbeitung von Medienströmen kein Problemdarstellt, sondern eine selbstverständliche Funktion ist.

90 Kapitel 6. Zusammenfassung und Ausblick

A. Verlustunempfindlicher Transport vonMedienströmen mit RTPDer Transport von Medienströmen in IP-basierten Netzen wird hauptsächlich mittels RTPrealisiert. Zu den Diensten, die RTP sowie die darunterliegenden Protokolle nicht bereitstellen,gehören rechtzeitige Auslieferung und Fehlerbehebung. 1 Die Kompensierung des durchverlorengegangene Pakete entstehenden Schadens ist in der Kommunikation über paketvermittelteNetze ein wichtiger Aspekt. Im folgenden werden zwei Verfahren beschrieben, dieMöglichkeiten bieten, den Transport von Medienströmen mit RTP zu erweitern, um denVerlust von Paketen zu korrigieren oder die Wahrscheinlichkeit des Verlusts von aufeinanderfolgenden Paketen zu minimieren. Für den Einsatz beider Verfahren kann ein spezielldafür entwickelter RTP-Payload-Typ verwendet werden, der im RFC 2198 [42] definiert ist.A.1.RTP-Payload-Typ für redundante InformationenEine Möglichkeit, den Verlust von Paketen auszugleichen, ist die Verwendung von redundantenInformationen zur Rekonstruktion der verlorengegangenen Informationen. Um diebenötigte Bandbreite nicht zu verdoppeln, werden die zusätzlichen Informationen durchverschiedene mathematische Verfahren komprimiert. Der in RFC 2198 definierte RTP-Payload-Typist für den Transport von beliebigen Audio-Informationen verwendbar und kannzusätzlich redundante Informationen transportieren.Zu überlegen ist dabei, auf welche Weise die redundanten Informationen in die RTP-Paketeeingefügt werden. Wichtig ist, daß die zusätzlichen Informationen im Verhältnis zu der eigentlichenNutzlast nicht einen zu großen Anteil einnehmen. Desweiteren muß festgelegtwerden, wo innerhalb eines RTP-Paketes die zusätzlichen Informationen eingesetzt werden.Eine Variante ist die Verwendung der Kopf-Erweiterung von RTP-Paketen. Eine andereMöglichkeit besteht in der Definition eines neuen RTP-Payload-Typs, in dem die redundantenDaten in der Nutzlast transportiert werden. Eine solche Methode ist in RFC 2198beschrieben.Die Struktur der Nutzlast des RTP-Payload-Typs für redundante Informationen ist derartigaufgebaut, daß es möglich ist, außer Audio-Informationen auch beliebige andere Daten alsRedundanz-Informationen zu verwenden. Dabei werden in 32-Bit-Worten Beschreibungender redundanten Informationen bestehend aus RTP-Payload-Typ, Zeitstempel und Längenangabean den Anfang der Nutzlast geschrieben, wie dem Beispiel-Paket aus Abbildung A.1zu entnehmen ist. Der Zeitstempel der redundanten Informationen ist relativ zu dem deseigentlichen (primären) Mediendaten-Fragments in dem RTP-Paket angegeben. Die Längewird in der Einheit Byte angegeben. Nach der Beschreibung aller Blöcke mit redundantenInformationen wird eine abschließende Beschreibung für die primären Mediendaten ein-1 In diesem Fall wird davon ausgegangen, daß auf der Transportschicht UDP oder ein ähnliches Protokolleingesetzt wird.

92 Anhang A. Verlustunempfindlicher Transport von Medienströmen mit RTPgefügt, die keine Längenangabe enthält. In dem Beispiel wird eine Block von 14 Bytes mitredundanten Daten angegeben. Enthalt sind darin Audio-Informationen, die mit LPC kodiertsind. Als Primäre Nutzlast werden weitere 84 Byte Audio-Informationen in dem Pakettransportiert.0 16 32V=2P X CC M PT SequenznummerBeschreibung eines Blocksmit redundanten Informationen.Zeitstempel der primären MediendatenSynchronisationsquelle (SSRC)Beschreibung des Blocksmit den primärenMediendaten}}1 Block PT=7 Zeitstempel Block Länge0 Block PT=5LPC kodierte redundante Daten (PT=7)(14 Byte)DVI4 kodierte Mediendaten (PT=5)(84 Byte)Abbildung A.1.: RTP-Paket mit redundanten InformationenMittels dieser Techniken können beliebige Algorithmen für die Erzeugung der redundantenInformationen verwendet werden. Zusätzlich ist die Möglichkeit gegeben, mehrere Blöckemit redundanten Informationen in einem RTP-Pakete zu verschicken.A.2.InterleavingInterleaving ist die Bezeichnung für ein mathematisch einfaches Verfahren, das die Anzahlder aufeinander folgenden defekten Fragmente in einem Medienstrom reduzieren soll. Dafürwerden die einzelnen Frames 2 der kodierten Mediendaten vom Sender umsortiert. Zielist es dabei, daß keine Frames, die nacheinander abgespielt werden, direkt hintereinanderversendet werden. Kommt eine Reihe von Paketen defekt oder gar nicht beim Empfängeran, so sind in dem Fall keine aufeinander folgenden Frames betroffen. Um dieses Verfahrenmit RTP einzusetzen, kann der RTP-Payload-Typ aus RFC 2198 verwendet werden.Damit der Empfänger die Frames wieder in die korrekte Reihenfolge bringen kann, müssenin der Nutzlast des RTP-Paketes zusätzliche Informationen gespeichert werden. Dieswird durch die Unterstruktur des RTP-Payload-Typs aus RFC 2198 erbracht. Ausgehend davon,daß jeweils vier Frames in ein RTP-Paket gehören, werden die ersten drei Frames alsredundante Daten in die Nutzlast eingetragen und der zeitlich erste Frame als primäresMediendaten-Fragment. 3 Für den Empfänger ist die Verarbeitung dieser Daten mit einem2 Mit Samples ist dies auch möglich. Wichtig ist beim Interleaving nur, daß die Informationen der einzelnenaufeinander folgenden Frames bzw. Samples nicht aufeinander aufbauen.3 Das zeitlich erste Fragment muß als primäre Nutzlast eingefügt werden, da die relativen Zeitstempel der

A.3. Forward Error Correction 93geringen Aufwand verbunden, da die Frames nur in ihrer Reihenfolge angepaßt werdenmüssen und sonst keine rechenintensive Rekonstruktion erforderlich ist. Durch Interleavingist keine Wiederherstellung von defekten Daten möglich.A.3.Forward Error CorrectionDer RFC 2733 [49] beschreibt einen RTP-Payload-Typ für den Transport von FEC-Daten(Forward Error Correction). Entwickelt wurde dieser Typ für die FEC-Algorithmen, die aufder Exklusive-Oder-Operation basieren. Mittels dieser einfachen mathematischen Operationwird aus mehreren RTP-Paketen des Medienstroms ein Fragment erstellt, das zur Rekonstruktionder Original-Pakete verwendet werden kann. Der im RFC definierte RTP-Payload-Typ sieht vor, daß die FEC-Informationen über eine separate Transportverbindung geschicktwerden. Dadurch können auch Empfänger ohne eine FEC-Implementierung die RTP-Paketelesen und auswerten.Eine alternative Methode beschreibt die Verwendung des RTP-Payload-Typs aus RFC 2198.Dabei wird ein RTP-Paket, das FEC-Informationen transportiert, in mehreren Schritten zusammengesetzt.Im ersten Schritt werden die RTP-Pakete erzeugt, die nur die primäreNutzlast, d.h. die realen Mediendaten enthalten. Diese werden nach der Definition desRFCs 2733 in ein FEC-Paket eingefügt. Allerdings werden aus den Paketen eventuell vorhandeneKopf-Erweiterungen, Füllbytes und CSRC-Listen zuvor entfernt. Dieses kompletteFEC-Paket, d.h. Kopf sowie Nutzlast, werden als redundante Informationen in das endgültigeRTP-Paket eingefügt. Im letzten Schritt wird das aktuell zu versendete Mediendaten-Fragment an die Nutzlast angefügt. Die vor der Generierung des FEC-Paketes entferntenTeile aus dem RTP-Paket müssen in das resultierende Paket wieder integriert werden. Aufdiese Weise können über eine einzige Verbindung Medien- sowie FEC-Daten ausgetauschtwerden. Das Erzeugen der Pakete auf seiten des Senders sowie das Verarbeiten auf seitendes Empfängers erfordern eine erhöhte Rechenleistung und können somit zu Verzögerungenführen.Blöcke für redundante Informationen nur positiv sein können.

94 Anhang A. Verlustunempfindlicher Transport von Medienströmen mit RTP

GlossarAAbstract Syntax Notation One (ASN.1)Eine Sprache, mit der Datenstrukturen beschrieben werden können. ASN.1 abstrahiertvon der eigentlichen Repräsentation der Daten eines Rechners, um Datenstrukturenunabhängig von der Architektur zu übertragen. ASN.1 wird häufig im Umfeldder ITU-T benutzt.American Standard Code for Information Interchange (ASCII)Spezifiziert die Kodierung von 128 Zeichen (Buchstaben, Ziffern, Interpunktion undSteuerzeichen) geeignet für den Austausch englischsprachiger Dokumente. ASCII bildetdie Grundlage der meisten Computer-Zeichensätze.CCodecEin Codec ist ein Verfahren für die Kodierung von Audio- oder Videodaten. Codecsunterscheiden sich hinsichtlich der Effektivität, Geschwindigkeit und Art der Komprimierung,und vor allem bei verlustbehafteter Komprimierung hinsichtlich der Qualitätdes Stroms.DDual Tone Multi Frequency (DTMF)Töne für die verschiedenen Tasten des Telefons. Jede Zahl bzw. jedes Sonderzeichengeneriert zwei Töne, einen für die Reihe, einen für die Spalte. Die beiden Töne werdensimultan übertragen. Hiermit sind sowohl Tonwahl als auch die Steuerung vonTelefonanlagen/Computern möglich.EExtensible Markup Language (XML)XML ist eine Meta-Sprache; eine Sprache zum Erzeugen eigener Beschreibungssprachen(Markup Languages).FForward Error CorrectionEin Verfahren zur Erzeugung von redundanten Informationen, das beim Transport

96 Glossarvon Mediendaten eingesetzt wird, um verlorengegangene Pakete rekonstruieren zukönnen.GG.711Bezeichnet ein Kodierungsverfahren für Audio-Informationen, von dem zwei Variantenexistieren. Die µ-Law Variante wird in Nord-Amerika und Japan im Telefonnetzeingesetzt. Die Variante A-Law hingegen wird in Europa verwendet.GatewayEin Gateway verbindet zwei Netze miteinander, indem es zwischen verschiedenenProtokollen einer Schicht vermittelt. Beispielsweise kann ein Gateway zwischen einemIP- und einem ATM-Netz vermitteln oder ein Gespräch zwischen einem H.323-und einem SIP-Endpunkt ermöglichen.Graphical User Interface (GUI)Engl. für grafische Benutzungsoberfläche.HH.323H.323 ist ein Telefoniestandard der ITU-T für paket-basierte Netze.H.450In der H.450-Serie werden Mehrwertdienste für H.323 spezifiziert. Die EmpfehlungH.450.1 beschreibt den generellen Aufbau und Einsatz von Mehrwertdiensten.Hypertext Markup Language (HTML)Eine Syntax zur logischen Auszeichnung von Dokumenten im WWW.Hypertext Transfer Protocol (HTTP)HTTP dient zum Transport von verteilten HTML-Dokumenten.IInterleavingEin Verfahren, das beim Transport von Mediendaten eingesetzt wird, um den Verlustvon aufeinanderfolgenden Fragmenten zu verringern.International Telecommunication Union (ITU)Die ITU ist ein internationales Gremium, dessen Mitglieder ursprünglich aus demBereich der Telefonie kamen. Heute beschäftigen sich Teile der ITU auch mit anderenInternet-Technologien.Internet Assigned Numbers Authority (IANA)Die zentrale Instanz für die Vergabe von eindeutigen Bezeichnern für Parameter vonInternet-Protokollen.Internet Engineering Task Force (IETF)Standardisierungsgremium, das Protokolle und Technologien für das Internet entwickeltund standardisiert.

Glossar 97Internet Protocol (IP)Das Internet Protocol dient zur netzübergreifenden Adressierung von Rechnern inpaketorientierten Netzen (siehe auch RFC791).IP-AdresseEine 32-bit-Zahl, die einem Rechner im Internet eindeutig zugeordnet ist. In der neuenVersion 6 des Internet-Protokolls ist der Nummernraum auf 128 Bit vergrößertworden.IP-TelefonieTelefonie über IP-basierte Netze. Die Konferenzumgebungen H.323 und SIP bietendiese Art der Telefonie.MMulticastMulticast ist eine Kommunikationsbeziehung zwischen einem Sender und mehrerenEmpfängern.Multicast Backbone (Mbone)Der Mbone ist der Multicast Backbone, der eine weltweite Infrastruktur für die Verteilungvon Daten auf Basis der Multicast-Adressierung darstellt.Multipoint Control Unit (MCU)Steuerungsmodul innerhalb einer Mehrpunktbeziehung.PPortEin Port ist eine Anwendungsadresse. Verwendet werden solche Adressen beispielsweisein den Protokollen TCP und UDP.Public Switched Telephone Network (PSTN)Unter PSTN versteht man das Öffentliche Telefonnetz.RReal-Time Control Protocol (RTCP)RTCP liefert periodisch Rückmeldungen über die Qualität des zugehörigen RTP-Stromsund Informationen über die Teilnehmer.Real-Time Transport Protocol (RTP)RTP spezifiziert End-zu-End-Übertragungsdienste unter Bewahrung des Echtzeitcharakters.SSession Description Protocol (SDP)SDP dient zur Beschreibung von Multimedia-Konferenzen. Hierfür werden Beschreibungslementezur Verfügung gestellt, um die Konferenz selbst sowie die Medienströmezu beschreiben.

98 GlossarSession Initiation Protocol (SIP)Telefonie-Standard der Internet Engineering Task Force für IP-basierte Netze.Simple Mail Transfer Protocol (SMTP)SMTP dient zum Transport von E-Mail-Nachrichten im Internet (RFC 821). Der Aufbaudes Kopfes einer E-Mail ist in RFC 822 beschrieben.TTime to Live (TTL)Die TTL gibt an, wieviele Router ein Paket maximal passieren soll. Jeder Router, derdas Paket empfängt, dekrementiert die TTL im eins. Ist die TTL null, so wird das Paketgelöscht.Transmission Control Protocol (TCP)Gewährleistet eine zuverlässige End-zu-End Verbindung zweier Anwendungen überein paketorientiertes Übertragungsmedium (siehe auch RFC 793).TransportadresseEine Transportadresse beschreibt eine vollständige Anwendungsadressierung, also eineIP-Adresse mit Port.UUnicastUnicast ist eine Kommunikationsbeziehung zwischen einem Sender und einem Empfänger.Uniform Resource Locator (URL)Adresse einer Ressource im Netz. Ein Beispiel sind URLs im World Wide Web, die aufein bestimmtes Dokument verweisen.User Datagram Protocol (UDP)Dieses Protokoll beschreibt, wie Datagramme in verbindungslosen IP-basierten Netzenübertragen werden sollen (RFC 768).WWorld Wide Web (WWW)Das WWW ist eine Anwendung des Internet. Dabei handelt es sich um eine dezentraleSammlung von Informationsangeboten, die über das Internet weltweit abrufbar sindund durch Querverweise (Hyperlinks) miteinander verknüpft sind.

Literaturverzeichnis[1] BERNERS-LEE, T., L. MASINTER und M. MCCAHILL: Uniform Resource Locators (URL).RFC 1738, IETF, Dezember 1994.[2] BLATHERWICK, P., R. BELL und P. HOLLAND: Megaco IP Phone Media Gateway ApplicationProfile. RFC 3054, IETF, Januar 2001.[3] BORMANN, UTE, CARSTEN BORMANN und JÖRG OTT: MECCANO - Multimedia Educationand Conferencing Collaboration over ATM Networks and Others. WissenschaftlichesProjekt, Universität Bremen, Universität Freiburg, University of Oslo, University CollageLondon, Teles AG, EUTELSAT, Juli 1998.[4] BORMANN, UTE, CARSTEN BORMANN und JÖRG OTT: UNITEL - Aufbau einer Infrastrukturfür IP-Telefonie-Dienste im Fachbereich 3 der Universität Bremen. StudentischesProjekt, Universität Bremen, Technologiezentrum Informatik, Bereich Digitale Medienund Netze, Juli 1998.[5] BORMANN, UTE, CARSTEN BORMANN und JÖRG OTT: WIPTEL - Aufbau einer Infrastrukturfür IP-Telefonie-Dienste im Wissenschaftsnetz. Wissenschaftliches Projekt, UniversitätBremen, Technologiezentrum Informatik, Bereich Digitale Medien und Netze,Juli 1998.[6] CASNER, S. und P. HOSCHKA: MIME Type Registration of RTP Payload Formats. INTER-NET DRAFT, IETF, Juli 2001. draft-ietf-avt-rtp-mime-05.txt.[7] CONTA, A. und S. DEERING: Internet Control Message Protocol (ICMPv6) for the InternetProtocol Version 6 (IPv6) Specification. RFC 2463, IETF, Dezember 1998.[8] CROCKER, D.: Standard for the format of ARPA Internet text messages. RFC 0822, IETF,August 1982.[9] CUERVO, 0. F., N. GREENE, A. RAYHAN, C. HUITEMA, B. ROSEN und J. SEGERS: MegacoProtocol Version 1. RFC 3015, IETF, November 2000.[10] DEERING, S. und R. HINDEN: Internet Protocol, Version 6 (IPv6) Specification. RFC2460, IETF, Dezember 1998.[11] DEERING, S.E.: Host extensions for IP multicasting. RFC 1112, IETF, August 1989.[12] FENNER, W.: Internet Group Management Protocol, Version 2. RFC 2236, IETF, November1997.[13] FIELDING, 1. R., J. GETTYS, J. MOGUL, H. FRYSTYK, L. MASINTER, P. LEACH undT. BERNERS-LEE: Hypertext Transfer Protocol – HTTP/1. RFC 2616, IETF, Juni 1999.[14] GERMEIER, MARKUS: Entwurf und Implementierung einer Mbusgesteuerten Engine fürverlustunempfindliches Video über IP. Diplomarbeit, Universität Bremen, März 2000.

100 Literaturverzeichnis[15] GILLIGAN, R., S. THOMSON, J. BOUND und W. STEVENS: Basic Socket Interface Extensionsfor IPv6. RFC 2553, IETF, März 1999.[16] GREENE, N., M. RAMALHO und B. ROSEN: Media Gateway Control Protocol Architectureand Requirements. RFC 2805, IETF, April 2000.[17] GROUP, AUDIO-VIDEO TRANSPORT WORKING und H. SCHULZRINNE: RTP Profile forAudio and Video Conferences with Minimal Control. RFC 1890, IETF, Januar 1996.[18] GROUP, AUDIO-VIDEO TRANSPORT WORKING, H. SCHULZRINNE, S. CASNER, R. FRE-DERICK und V. JACOBSON: RTP: A Transport Protocol for Real-Time Applications. RFC1889, IETF, Januar 1996.[19] HANDLEY, SCHULZRINNE, SCHOOLER und ROSENBERG: SIP: Session Initiation Protocol.INTERNET DRAFT, IETF, November 2000. draft-ietf-sip-rfc2543bis-02.txt.[20] HANDLEY, M. und V. JACOBSON: SDP: Session Description Protocol. RFC 2327, IETF,April 1998.[21] HANDLEY, M., H. SCHULZRINNE, E. SCHOOLER und J. ROSENBERG: SIP: Session InitiationProtocol. RFC 2543, IETF, März 1999.[22] HINDEN, R. und S. DEERING: IPv6 Multicast Address Assignments. RFC 2375, IETF, Juli1998.[23] HINDEN, R. und S. DEERING: IP Version 6 Addressing Architecture. INTERNET DRAFT,IETF, Februar 2001. draft-ietf-ipngwg-addr-arch-v3-04.txt.[24] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation G.711: Pulse code modulation(PCM) of voice frequencies, 1988.[25] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation T.120: Data Protocolsfor Multimedia Conferencing, Juli 1996.[26] INTERNATIONAL TELECOMMUNICATION UNION: Draft New Recommendation H.450.1:Generic Functional Protocol for the Support of Supplementary Services, 1998.[27] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation Q.931: ISDN User-Network Interface Layer 3 Specification for Basic Call Control, 1998.[28] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation H.221: Frame structurefor a 64 to 1920 kbit/s channel in audiovisual teleservices, Mai 1999.[29] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation H.225.0: Call SignalingProtocols and Media Stream Packetization for Packet Based Multimedia CommunicationsSystems, November 1999.[30] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation H.245: Control Protocolfor Multimedia Communication, 2000.[31] INTERNATIONAL TELECOMMUNICATION UNION: Recommendation H.323: Paket-BasedMultimedia Communications Systems, Juli 2000.[32] JOHNSTRON, ALAN B.: Understanding the Session Initiation Protocol. Artech HousePublishers, 2001.

Literaturverzeichnis 101[33] KENT, S. und R. ATKINSON: IP Authentication Header. RFC 2402, IETF, November1998.[34] KENT, S. und R. ATKINSON: IP Encapsulating Security Payload (ESP). RFC 2406, IETF,November 1998.[35] KUTSCHER, DIRK, JÖRG OTT und CARSTEN BORMANN: Requirements for Session Descriptionand Capability Negotiation. INTERNET DRAFT, IETF, April 2001. draft-ietf-\mmusic-sdpng-req-01.txt.[36] MEYER, DIRK: Anruf- und Mediensteuerung auf der Basis von Mbus und SDPng: exemplarischeRealisierung einer IP-PBX. Diplomarbeit, Universität Bremen, März 2001.[37] MILLS, DAVID L.: Network Time Protocol (Version 3) Specification, Implementation. RFC1305, IETF, März 1992.[38] NICHOLS, K., S. BLAKE, F. BAKER und D. BLACK: Definition of the Differentiated ServicesField (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, IETF, Dezember 1998.[39] NORSKOG, LANCE und CHRIS BAGWELL: SoX - Sound eXchange. http://home.sprynet.\com/ cbagwell/sox.html.[40] OTT, JÖRG, DIRK KUTSCHER und DIRK MEYER: An Mbus Profile for Call Control. IN-TERNET DRAFT, TZI, Universität Bremen, Februar 2001. draft-ietf-mmusic-mbus-\call-control-00.txt.[41] OTT, JÖRT, COLIN PERKINS und DIRK KUTSCHER: A Message Bus for Conferencing Systems.INTERNET DRAFT, Universität Bremen/ University College London, Februar2001. draft-ietf-mmusic-mbus-transport-04.txt.[42] PERKINS, C., I. KOUVELAS, O. HODSON, V. HARDMAN, M. HANDLEY, J.C. BOLOT,A. VEGA-GARCIA und S. FOSSE-PARISIS: RTP Payload for Redundant Audio Data. RFC2198, IETF, September 1997.[43] POLLEM, NIELS: Entwurf und Implementierung eines ausbaufähigen Gateways zur Umsetzungunterschiedlicher Verbindungsprotokolle für IP-Telefonie. Diplomarbeit, UniversitätBremen, Januar 2000.[44] POSTEL, J.: DoD standard Transmission Control Protocol. RFC 0761, IETF, Januar1980.[45] POSTEL, J.: User Datagram Protocol. RFC 0768, IETF, August 1980.[46] POSTEL, J.: Internet Control Message Protocol. RFC 0792, IETF, September 1981.[47] POSTEL, J.: Internet Protocol. RFC 0791, IETF, September 1981.[48] PRELLE, STEFAN: Entwurf und Implementierung eines H.323-Gatekeepers zur Resourcenverwaltungund Zugangsregelung für IP-Telefonie-Dienste. Diplomarbeit, UniversitätBremen, Oktober 1999.[49] ROSENBERG, J. und H. SCHULZRINNE: An RTP Payload Format for Generic ForwardError Correction. RFC 2733, IETF, Dezember 1999.[50] SCHNEIDER, BRUCE: Applied Cryptpgraphy. Wiley, 605 Third Avenue, New York, 1996.

102 Literaturverzeichnis[51] SCHULZRINNE und CASNER: RTP Profile for Audio and Video Conferences with MinimalControl. INTERNET DRAFT, IETF, August 2001. draft-ietf-avt-profile-new-10.txt.[52] SCHULZRINNE, CASNER, FREDERICK und JACOBSON: RTP: A Transport Protocol for Real-Time Applications. INTERNET DRAFT, IETF, August 2001. draft-ietf-avt-rtp-new-\09.txt.[53] SCHULZRINNE, H. und S. PETRACK: RTP Payload for DTMF Digits, Telephony Tones andTelephony Signals. RFC 2833, IETF, Mai 2000.[54] SINGH, KUNDAN: SipConf System. University Columbia, http://www.cs.columbia.\edu/˜kns10/software/sipconf/.[55] SPARKS, R.: SIP Call Control - Transfer. INTERNET DRAFT, IETF, Februar 2001. draft-\ietf-sip-cc-transfer-04.txt.[56] SPEER, M. und D. HOFFMAN: RTP Payload Format of Sun’s CellB Video Encoding. RFC2029, IETF, Oktober 1996.[57] UNIVERSITY COLLEGE LONDON, http://www-mice.cs.ucl.uk/mice/rat: The RAT(Robust-Audio Tool) Home Page.[58] VAHA-SIPILA, A.: URLs for Telephone Calls. RFC 2806, IETF, April 2000.

IndexAG Rechnernetze, 41Gateway, 46H.323, 32, 41Adressierung, 32Gatekeeper, 32Protokollablauf, 32IETF, 3IP, 4Anycast, 7Broadcast, 7ICMP, 8IGMP, 8Multicast, 7Unicast, 7ITU-T, 3Mbone, 87, 88Mbone-Konferenz, 45, 50, 52Mbus, 42, 43, 52Media-Prozessor, 48, 77, 81Aufbau, 55Controller, 72Erweiterungs-Modul, 56, 69Filter, 67Filter-Modul, 56Funktionalität, 49Konferenz-Controller, 63Konferenz-Modell, 57Kontext, 61Module, 64Steuer-Modul, 56Termination, 58Transport, 66Transport-Modul, 56Zielanwendungen, 48Medienbeschreibung, 34H.245, 38SDP, 34SDPng, 36MEGACO, 20Architektur, 20Protokoll, 24MePro, 77, 81, 87Aufbau, 81Konferenz-Modell, 85Module, 84Schnittstelle, 80Projekte6WINIT, 43MECCANO, 41UNITEL, 42WIPTEL, 43RTCP, 8RTP, 8Abschied, 16Anwendungserweiterung, 17APP, 17BYE, 16CSRC, 9Empfänger-Bericht, 13End-System, 10Mixer, 10Monitor, 10Port, 9Quellbeschreibungen, 14RR, 13RTCP, 12RTCP-Paket, 9RTP-Paket, 9RTP-Payload, 9RTP-Profil, 10RTP-Session, 9SDES, 14Sender-Bericht, 14SR, 14SSRC, 9Translator, 10Transport-Adresse, 9RTP-Bibliothek, 77SIP, 29, 41Adressierung, 29Nachrichtenformat, 29Protokollablauf, 30Server, 30