Zum Hauptinhalt springen

3. Definitions (Definitionen)

  • RTP-Nutzlast (RTP Payload) : Die von RTP in einem Paket transportierten Daten, beispielsweise Audioabtastwerte oder komprimierte Videodaten. Das Format und die Interpretation der Nutzlast liegen außerhalb des Rahmens dieses Dokuments.

  • RTP-Paket (RTP Packet) : Ein Datenpaket, bestehend aus dem festen RTP-Header, einer gegebenenfalls leeren Liste von Beitragendenquellen (siehe unten) und den Nutzlastdaten. Einige zugrunde liegende Protokolle können erfordern, dass eine Kapselung des RTP-Pakets definiert wird. Typischerweise enthält ein Paket des zugrunde liegenden Protokolls genau ein RTP-Paket, jedoch können mehrere RTP-Pakete darin enthalten sein, falls die Kapselungsmethode dies zulässt (siehe Abschnitt 11).

  • RTCP-Paket (RTCP Packet) : Ein Steuerpaket, das aus einem festen Kopfbereich ähnlich dem der Datenpakete besteht, gefolgt von strukturierten Elementen, die je nach RTCP-Pakettyp variieren. Die Formate sind in Abschnitt 6 definiert. Typischerweise werden mehrere RTCP-Pakete zusammen als zusammengesetztes RTCP-Paket (Compound RTCP Packet) in einem einzigen Paket des zugrunde liegenden Protokolls gesendet; dies wird durch das Längenfeld im festen Header jedes RTCP-Pakets ermöglicht.

  • Port : „Die Abstraktion, die Transportprotokolle verwenden, um mehrere Ziele innerhalb eines bestimmten Host-Rechners zu unterscheiden. TCP/IP-Protokolle identifizieren Ports mittels kleiner positiver Ganzzahlen." [12] Die von der OSI-Transportschicht verwendeten Transportselektoren (TSEL) entsprechen den Ports. RTP stützt sich auf das Protokoll der unteren Schicht, um einen Mechanismus wie Ports bereitzustellen, um RTP- und RTCP-Pakete einer Sitzung zu multiplexen.

  • Transportadresse (Transport Address) : Die Kombination aus Netzwerkadresse und Port, die einen Endpunkt auf Transportebene identifiziert, beispielsweise eine IP-Adresse und ein UDP-Port. Pakete werden von einer Quell-Transportadresse zu einer Ziel-Transportadresse übertragen.

  • RTP-Medientyp (RTP Media Type) : Ein RTP-Medientyp ist die Menge der Nutzlasttypen, die innerhalb einer einzigen RTP-Sitzung transportiert werden können. Das RTP-Profil ordnet die RTP-Medientypen den RTP-Nutzlasttypen zu.

  • Multimediasitzung (Multimedia Session) : Eine Menge gleichzeitiger RTP-Sitzungen zwischen einer gemeinsamen Gruppe von Teilnehmern. Beispielsweise kann eine Videokonferenz (die eine Multimediasitzung ist) eine RTP-Audiositzung und eine RTP-Videositzung enthalten.

  • RTP-Sitzung (RTP Session) : Eine Assoziation zwischen einer Menge von Teilnehmern, die mit RTP kommunizieren. Ein Teilnehmer kann gleichzeitig an mehreren RTP-Sitzungen beteiligt sein. In einer Multimediasitzung wird jedes Medium typischerweise in einer separaten RTP-Sitzung mit eigenen RTCP-Paketen transportiert, sofern die Kodierung nicht selbst mehrere Medien in einem einzigen Datenstrom multiplexed. Ein Teilnehmer unterscheidet mehrere RTP-Sitzungen daran, dass er sie über verschiedene Ziel-Transportadresspaare empfängt, wobei ein Transportadresspaar aus einer Netzwerkadresse plus einem Portpaar für RTP und RTCP besteht. Alle Teilnehmer einer RTP-Sitzung können ein gemeinsames Ziel-Transportadresspaar teilen, wie im Fall von IP-Multicast, oder die Paare können für jeden Teilnehmer unterschiedlich sein, wie im Fall einzelner Unicast-Netzwerkadressen und Portpaare. Im Unicast-Fall kann ein Teilnehmer von allen anderen Teilnehmern der Sitzung unter Verwendung desselben Portpaars empfangen oder für jeden ein eigenes Portpaar verwenden.

    Das Unterscheidungsmerkmal einer RTP-Sitzung ist, dass jede einen vollständigen und separaten Raum von SSRC-Identifikatoren (unten definiert) verwaltet. Die Menge der in eine RTP-Sitzung eingeschlossenen Teilnehmer umfasst diejenigen, die einen von einem beliebigen Teilnehmer übertragenen SSRC-Identifikator empfangen können, entweder in RTP als SSRC oder CSRC (ebenfalls unten definiert) oder in RTCP. Betrachten wir beispielsweise eine Dreierkonferenz, die mit UDP-Unicast implementiert ist, wobei jeder Teilnehmer von den beiden anderen über separate Portpaare empfängt. Wenn jeder Teilnehmer nur einem anderen Teilnehmer ein RTCP-Feedback über die von jenem empfangenen Daten gibt, besteht die Konferenz aus drei separaten Punkt-zu-Punkt-RTP-Sitzungen. Wenn jeder Teilnehmer den beiden anderen Teilnehmern ein Feedback über seinen Empfang eines anderen Teilnehmers gibt, besteht die Konferenz aus einer einzigen Mehrparteien-RTP-Sitzung. Letzterer Fall simuliert das Verhalten, das bei IP-Multicast-Kommunikation zwischen den drei Teilnehmern auftreten würde.

    Das RTP-Gerüst lässt die hier definierten Varianten zu, aber ein bestimmtes Steuerungs- oder Anwendungsprotokoll wird im Allgemeinen Einschränkungen bezüglich dieser Varianten auferlegen.

  • Synchronisationsquelle (SSRC, Synchronization Source) : Die Quelle eines RTP-Paketstroms, identifiziert durch einen numerischen 32-Bit-SSRC-Identifikator, der im RTP-Header getragen wird, sodass er unabhängig von der Netzwerkadresse ist. Alle Pakete einer Synchronisationsquelle gehören zum selben Zeit- und Sequenznummernraum, sodass ein Empfänger die Pakete nach Synchronisationsquelle gruppiert, um sie abzuspielen. Beispiele für Synchronisationsquellen umfassen den Sender eines Paketstroms, der von einer Signaleingangsquelle wie einem Mikrofon oder einer Kamera abgeleitet ist, oder einen RTP-Mischer (siehe unten). Eine Synchronisationsquelle kann ihr Datenformat im Laufe der Zeit ändern, beispielsweise die Audiokodierung. Der SSRC-Identifikator ist ein zufällig gewählter Wert, der innerhalb einer bestimmten RTP-Sitzung global eindeutig sein soll (siehe Abschnitt 8). Ein Teilnehmer muss nicht denselben SSRC-Identifikator für alle RTP-Sitzungen einer Multimediasitzung verwenden; die Verknüpfung von SSRC-Identifikatoren wird über RTCP bereitgestellt (siehe Abschnitt 6.5.1). Wenn ein Teilnehmer in einer RTP-Sitzung mehrere Ströme erzeugt, beispielsweise aus separaten Videokameras, muss jeder als ein separater SSRC gekennzeichnet sein.

  • Beitragende Quelle (CSRC, Contributing Source) : Eine Quelle eines RTP-Paketstroms, die zu dem von einem RTP-Mischer (siehe unten) erzeugten kombinierten Strom beigetragen hat. Der Mischer fügt eine Liste der SSRC-Identifikatoren der Quellen, die zur Erzeugung eines bestimmten Pakets beigetragen haben, in den RTP-Header dieses Pakets ein. Diese Liste wird CSRC-Liste genannt. Ein Anwendungsbeispiel ist die Audiokonferenz, bei der ein Mischer alle Sprecher angibt, deren Sprache zur Erzeugung des ausgehenden Pakets kombiniert wurde, sodass der Empfänger den aktuellen Sprecher anzeigen kann, selbst wenn alle Audiopakete denselben SSRC-Identifikator (den des Mischers) enthalten.

  • Endsystem (End System) : Eine Anwendung, die den Inhalt erzeugt, der in RTP-Paketen gesendet wird, und/oder den Inhalt der empfangenen RTP-Pakete konsumiert. Ein Endsystem kann als eine oder mehrere Synchronisationsquellen in einer bestimmten RTP-Sitzung fungieren, typischerweise jedoch nur als eine.

  • Mischer (Mixer) : Ein Zwischensystem, das RTP-Pakete von einer oder mehreren Quellen empfängt, das Datenformat gegebenenfalls ändert, die Pakete auf eine bestimmte Weise kombiniert und dann ein neues RTP-Paket überträgt. Da die Zeitstruktur zwischen mehreren Eingangsquellen im Allgemeinen nicht synchronisiert ist, nimmt der Mischer Zeitkorrekturen zwischen den Strömen vor und erzeugt seine eigene Zeitstruktur für den kombinierten Strom. Daher werden alle Datenpakete eines Mischers als den Mischer als Synchronisationsquelle kennzeichnend identifiziert.

  • Übersetzer (Translator) : Ein Zwischensystem, das RTP-Pakete weiterleitet, ohne deren Synchronisationsquellen-Identifikator zu verändern. Beispiele für Übersetzer umfassen Geräte, die Kodierungen ohne Mischung konvertieren, Multicast-zu-Unicast-Replikatoren und Application-Level-Filter in Firewalls.

  • Überwacher (Monitor) : Eine Anwendung, die die von den Teilnehmern einer Sitzung gesendeten RTCP-Pakete, insbesondere die Empfangsberichte, empfängt und die aktuelle Dienstgüte für Verteilungsüberwachung, Fehlerdiagnose und Langzeitstatistiken schätzt. Die Überwacherfunktion wird voraussichtlich in die (bzw. die) Anwendung(en), die an der Sitzung teilnehmen, integriert, kann aber auch eine separate Anwendung sein, die nicht anderweitig beteiligt ist und weder RTP-Datenpakete sendet noch empfängt (da diese auf einem separaten Port liegen). Dies sind sogenannte Drittanbieter-Überwacher (Third-Party Monitors). Es ist ebenfalls zulässig, dass ein Drittanbieter-Überwacher die RTP-Datenpakete empfängt, aber keine RTCP-Pakete sendet noch anderweitig in der Sitzung gezählt wird.

  • Nicht-RTP-Mittel (Non-RTP Means) : Protokolle und Mechanismen, die zusätzlich zu RTP erforderlich sein können, um einen nutzbaren Dienst bereitzustellen. Insbesondere für Multimediakonferenzen kann ein Steuerungsprotokoll Multicast-Adressen und Verschlüsselungsschlüssel verteilen, den zu verwendenden Verschlüsselungsalgorithmus aushandeln und dynamische Zuordnungen zwischen RTP-Nutzlasttypwerten und den von ihnen repräsentierten Nutzlastformaten für Formate ohne vordefinierten Nutzlasttypwert festlegen. Beispiele für solche Protokolle umfassen das SIP (Session Initiation Protocol, RFC 3261 [13]), die ITU-Empfehlung H.323 [14] und Anwendungen, die SDP (RFC 2327 [15]) verwenden, wie RTSP (RFC 2326 [16]). Für einfache Anwendungen können auch E-Mail oder eine Konferenzdatenbank verwendet werden. Die Spezifikation solcher Protokolle und Mechanismen liegt außerhalb dieses Dokuments.