3. Procedures (Verfahren)

Dieser Abschnitt beschreibt die Verfahren zur Zuordnung von Medienbeschreibungen, die MediaStreamTracks innerhalb von MediaStreams repräsentieren, wie in [W3C-WebRTC] definiert.

In der in dieser Spezifikation beschriebenen Javascript-API besitzen MediaStream und MediaStreamTrack jeweils ein Attribut id vom Typ DOMString.

Der Wert des Feldes msid-id im MSID besteht aus dem Attribut id eines MediaStream, wie in der WebIDL-Spezifikation des MediaStream [WEBIDL] definiert. Der spezielle Wert - bedeutet „kein MediaStream“.

Der Wert des Feldes msid-appdata im MSID besteht, falls vorhanden, aus dem Attribut id eines MediaStreamTrack, wie in der WebIDL-Spezifikation des MediaStreamTrack definiert.

Wird eine SDP-Sitzungsbeschreibung aktualisiert, bezieht sich ein bestimmter Wert msid-id weiterhin auf denselben MediaStream und ein bestimmter Wert msid-appdata auf denselben MediaStreamTrack. Es gibt kein Gedächtnis außerhalb der jeweils gültigen SDP-Beschreibungen; verschwindet ein MSID-„Bezeichner“-Wert aus dem SDP und erscheint er in einer späteren Verhandlung wieder, gilt er als neuer MediaStream.

Entspricht das Attribut msid nicht der hier angegebenen ABNF, SOLLTE es ignoriert werden.

Im Folgenden eine Beschreibung auf hoher Ebene der Regeln für die Verarbeitung von SDP-Aktualisierungen. Detaillierte Verfahren stehen in Abschnitt 3.2.

• Tritt in einer Sitzungsbeschreibung ein neuer MSID-„Bezeichner“-Wert auf und ist er nicht -, kann der Empfänger seiner Anwendung signalisieren, dass ein neuer MediaStream hinzugefügt wurde.

• Wird eine Sitzungsbeschreibung so aktualisiert, dass Medienbeschreibungen mit einem MSID-„Bezeichner“-Wert und einem oder mehreren unterschiedlichen appdata-Werten vorliegen, kann der Empfänger seiner Anwendung signalisieren, dass neue MediaStreamTracks hinzugefügt wurden und zu welchem MediaStream. Dies geschieht für jeden unterschiedlichen MSID-„Bezeichner“-Wert, einschließlich des speziellen Werts -, der anzeigt, dass ein MediaStreamTrack ohne zugehörigen MediaStream hinzugefügt wurde.

• Erscheint ein MSID-„Bezeichner“-Wert ohne appdata-Wert, bedeutet dies, dass der Sender dem Empfänger die gewünschte Kennung des MediaStreamTrack nicht mitgeteilt hat, und der Empfänger weist den id-Wert des erzeugten MediaStreamTrack selbst zu. Alle MSIDs in einem Medienabschnitt ohne appdata-Wert gelten als Verweis auf denselben MediaStreamTrack.

• Wird eine Sitzungsbeschreibung so aktualisiert, dass für eine bestimmte Medienbeschreibung kein msid-Attribut mehr aufgeführt ist, kann der Empfänger seiner Anwendung signalisieren, dass der entsprechende MediaStreamTrack beendet wurde.

Neben der Signalisierung, dass die Spur beendet ist, wenn ihr msid-Attribut aus dem SDP verschwindet, wird die Spur auch dann als beendet signalisiert, wenn alle zugehörigen SSRCs nach den Regeln von [RFC3550], Abschnitte 6.3.4 (BYE-Paket empfangen) und 6.3.5 (Zeitüberschreitung), verschwunden sind oder wenn die entsprechende Medienbeschreibung durch Setzen der Portnummer auf null deaktiviert wird. Eine Änderung der Richtung der Medienbeschreibung (durch Setzen der Attribute sendonly, recvonly oder inactive) beendet den MediaStreamTrack nicht.

Die Zuordnung zwischen SSRCs und Medienbeschreibungen ist in [RFC8829] festgelegt.

3.1. Handling of Nonsignaled Tracks (Nicht signalisierte Spuren)

Entitäten, die den hier beschriebenen Mechanismus nicht verwenden, senden kein Attribut msid und damit keine Informationen zur Zuordnung von RTP-Paketen zu MediaStreams. Das bedeutet, dass es eingehende RTP-Pakete gibt, für die der Empfänger keinen vordefinierten MediaStream-ID-Wert hat.

Beachten Sie, dass die unten beschriebene Verarbeitung durch eingehende RTP-Pakete ausgelöst wird, nicht durch SDP-Verhandlungen.

Bei der Kommunikation mit Entitäten, die den MSID-Mechanismus verwenden, können eingehende RTP-Pakete nur dann ohne zugeordneten MediaStream-ID-Wert empfangen werden, wenn nach der anfänglichen Verhandlung eine Verhandlung stattfindet, bei der der Antwortende einen MediaStreamTrack zu einer bereits etablierten Verbindung hinzufügt und mit der Datenübertragung beginnt, bevor der Anbietende die Antwort erhält. Bei der Erstverhandlung fließen Pakete erst, nachdem ICE-Kandidaten und Fingerprints ausgetauscht wurden; dort entsteht das Problem nicht.

Der Empfänger dieser Pakete führt folgende Schritte aus:

• Beim erstmaligen Empfang von RTP-Paketen wird ein geeigneter MediaStreamTrack je nach Medientyp (über PayloadType) erzeugt und die MID-RTP-Header-Erweiterung [RFC8843] (falls vorhanden) verwendet, um die RTP-Pakete einem bestimmten Medienabschnitt zuzuordnen.

• Befindet sich die Verbindung nicht im RTCSignalingState stable, wartet er an dieser Stelle.

• Befindet sich die Verbindung im RTCSignalingState stable, werden ID-Werte zugewiesen.

Zur Zuweisung der ID-Werte werden folgende Schritte ausgeführt:

• Gibt es ein msid-Attribut, wird es verwendet, um das Feld id des MediaStreamTrack und der zugehörigen MediaStreams zu füllen, wie oben beschrieben.

• Gibt es kein msid-Attribut, wird die Kennung des MediaStreamTrack auf eine zufällig erzeugte Zeichenkette gesetzt und signalisiert, dass er Teil eines MediaStream mit WebIDL-Attribut label gleich Non-WebRTC stream ist.

• Nach Festlegung des auf den MediaStreamTrack anzuwendenden Feldes id wird die Spur dem Benutzer signalisiert.

Der obige Vorgang kann erhebliches Puffern vor Eintritt in den Zustand stable erfordern. Möchte die Implementierung dieses Puffern begrenzen, MUSS sie dem Benutzer signalisieren, dass Medien verworfen wurden.

Daraus folgt, dass MediaStreamTracks im „Standard“-MediaStream nicht durch Entfernen des Attributs msid geschlossen werden können; die Anwendung muss sie stattdessen als geschlossen signalisieren, wenn der SSRC verschwindet, entweder nach den Regeln der Abschnitte 6.3.4 und 6.3.5 von [RFC3550] oder durch Deaktivieren der Medienbeschreibung durch Setzen des Ports auf null.

3.2. Detailed Offer/Answer Procedures (Offer/Answer im Detail)

Diese Verfahren orientieren sich an den von [RFC3264] empfohlenen Abschnitten. Sie beschreiben die auszuführenden Aktionen in Bezug auf MediaStreams und MediaStreamTracks; sie umfassen keine Ereignissignalisierung innerhalb der Anwendung, die im JavaScript Session Establishment Protocol (JSEP) [RFC8829] beschrieben ist.

3.2.1. Generating the Initial Offer

Für jede Medienbeschreibung im Angebot: Gibt es einen zugehörigen ausgehenden MediaStreamTrack, fügt der Anbietende für jeden MediaStream, mit dem der MediaStreamTrack verknüpft ist, ein Attribut a=msid zum Abschnitt hinzu. Das Feld identifier des Attributs wird auf das WebIDL-Attribut id des MediaStream gesetzt. Möchte der Sender Kennungen für die MediaStreamTracks signalisieren, wird das Feld appdata auf das WebIDL-Attribut id des MediaStreamTrack gesetzt; andernfalls wird es weggelassen.

3.2.2. Answerer Processing of the Offer

Für jede Medienbeschreibung im Angebot und jedes Attribut a=msid in der Medienbeschreibung führt der Empfänger des Angebots folgende Schritte aus:

• Das Feld appdata des Attributs a=msid extrahieren, falls vorhanden.

• Existiert das Feld appdata: Prüfen, ob bereits ein MediaStreamTrack mit demselben WebIDL-Attribut id wie das Feld appdata existiert und nicht im Zustand ended ist. Wird kein solcher MediaStreamTrack gefunden, wird er erstellt.

• Existiert das Feld appdata nicht und ist kein MediaStreamTrack mit diesem Medienabschnitt verknüpft, wird ein MediaStreamTrack erzeugt und für spätere Verwendung mit diesem Medienabschnitt verknüpft.

• Das Feld identifier des Attributs a=msid extrahieren.

• Prüfen, ob bereits ein MediaStream mit demselben WebIDL-Attribut id existiert. Wenn nicht, wird er erzeugt.

• Den MediaStreamTrack zum MediaStream hinzufügen.

• Dem Benutzer signalisieren, dass ein neuer MediaStreamTrack verfügbar ist.

3.2.3. Generating the Answer

Die Antwort wird genau wie das Angebot erzeugt. Werte a=msid im Angebot beeinflussen die Antwort nicht.

3.2.4. Offerer Processing of the Answer

Die Antwort wird genau wie das Angebot verarbeitet.

3.2.5. Modifying the Session

Bei weiteren Austauschen wird dasselbe Verfahren wie beim ersten Offer/Answer befolgt, mit einem zusätzlichen Schritt beim Parsen von Angebot und Antwort:

• Für jeden MediaStreamTrack, der durch frühere Offer/Answer-Austausche erzeugt wurde und sich nicht im Zustand ended befindet, prüfen, ob im vorliegenden SDP noch ein Attribut a=msid existiert, dessen Feld appdata mit dem WebIDL-Attribut id der Spur übereinstimmt.

• Wird kein solches Attribut gefunden, den MediaStreamTrack stoppen. Dadurch geht sein Zustand auf ended.

3.3. Example SDP Description (SDP-Beispiel)

Die folgende SDP-Beschreibung zeigt die Darstellung einer WebRTC-PeerConnection mit zwei MediaStreams, von denen jeder eine Audio- und eine Videospur hat. Es werden nur die für MSID relevanten Teile gezeigt.

Zeilenumbrüche, Leerzeilen und Kommentare wurden der Übersichtlichkeit halber ergänzt. Sie gehören nicht zum SDP.

# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
       f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9

m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
       b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       b94006c5-cade-4e0a-9ed9-d3e6747be7d9

m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       f30bdb4a-1497-49b5-3198-e0c9a23172e0