5.10. Applying a Remote Description (Anwenden einer entfernten Beschreibung)

5.10. Applying a Remote Description (Anwenden einer entfernten Beschreibung)

Die folgenden Schritte werden ausgeführt, um eine entfernte Beschreibung (remote description) anzuwenden. Wird ein Fehler zurückgegeben, MUSS die Sitzung in den Zustand vor der Ausführung dieser Schritte zurückversetzt werden.

Enthält die Antwort „a=ice-options“-Attribute, bei denen „trickle“ als Attribut aufgeführt ist, die PeerConnection-Eigenschaft canTrickleIceCandidates auf „true“ aktualisieren. Andernfalls diese Eigenschaft auf „false“ setzen.

Die folgenden Schritte MÜSSEN für Attribute auf Sitzungsebene ausgeführt werden; sind Parameter außerhalb der Grenzen oder nicht anwendbar, MUSS die Verarbeitung gestoppt und ein Fehler zurückgegeben werden.

• Für jeden angegebenen „CT“-Bandbreitenwert diesen Wert als Grenze für die maximale Gesamtbitrate aller „m=“-Abschnitte setzen, wie in [RFC4566], Abschnitt 5.8 spezifiziert. Innerhalb dieser Gesamtgrenze kann die Implementierung dynamisch entscheiden, wie die verfügbare Bandbreite am besten zwischen „m=“-Abschnitten aufgeteilt wird, unter Beachtung etwaiger spezifischer Grenzen für einzelne „m=“-Abschnitte.

• Für angegebene „RR“- oder „RS“-Bandbreitenwerte wie in [RFC3556], Abschnitt 2 spezifiziert behandeln.

• Jeder „AS“-Bandbreitenwert ([RFC4566], Abschnitt 5.8) MUSS ignoriert werden, da die Bedeutung dieses Konstrukts auf Sitzungsebene nicht wohldefiniert ist.

Für jeden „m=“-Abschnitt MÜSSEN die folgenden Schritte ausgeführt werden; sind Parameter außerhalb der Grenzen oder nicht anwendbar, MUSS die Verarbeitung gestoppt und ein Fehler zurückgegeben werden.

• Haben sich ICE-ufrag oder Passwort gegenüber der vorherigen entfernten Beschreibung geändert:

  • Ist die Beschreibung vom Typ „offer“, MUSS die Implementierung festhalten, dass ein ICE-Neustart erforderlich ist, wie in [RFC8839], Abschnitt 4.4.1.1.1 beschrieben.

  • Ist die Beschreibung vom Typ „answer“ oder „pranswer“, prüfen, ob die aktuelle lokale Beschreibung ein ICE-Neustart ist, und falls nicht, einen Fehler erzeugen. Ist der PeerConnection-Zustand „have-remote-pranswer“ und haben sich ICE-ufrag oder Passwort gegenüber der vorherigen vorläufigen Antwort geändert, dem ICE-Agenten signalisieren, jeden vorherigen ICE-Checklistenzustand für den „m=“-Abschnitt zu verwerfen. Schließlich dem ICE-Agenten signalisieren, Prüfungen zu beginnen.

• Gibt die aktuelle lokale Beschreibung einen ICE-Neustart an, haben sich aber weder ICE-ufrag noch Passwort gegenüber der vorherigen entfernten Beschreibung geändert (wie in [RFC8445], Abschnitt 9 vorgeschrieben), einen Fehler erzeugen.

• Die mit diesem Medienabschnitt verknüpften ICE-Komponenten so konfigurieren, dass sie die bereitgestellten ICE-entfernten-ufrag- und Passwortwerte für ihre Konnektivitätsprüfungen verwenden.

• Alle bereitgestellten ICE-Kandidaten mit gesammelten lokalen Kandidaten paaren, wie in [RFC8445], Abschnitt 6.1.2 beschrieben, und Konnektivitätsprüfungen mit den passenden Anmeldedaten starten.

• Ist ein „a=end-of-candidates“-Attribut vorhanden, die End-of-Candidates-Indikation wie in [RFC8838], Abschnitt 14 verarbeiten.

• Gibt der Wert des Feldes proto des „m=“-Abschnitts die Verwendung von RTP an:

  • Wird der „m=“-Abschnitt wiederverwendet (siehe Abschnitt 5.2.2), den derzeit verknüpften RtpTransceiver durch Setzen seiner mid-Eigenschaft auf null entkoppeln und die Zuordnung zwischen Transceiver und seinem „m=“-Abschnittsindex verwerfen.

  • Ist der „m=“-Abschnitt mit keinem RtpTransceiver verknüpft (möglicherweise weil er im vorherigen Schritt entkoppelt wurde), entweder einen RtpTransceiver finden oder gemäß den folgenden Schritten einen erstellen:

    • Ist der „m=“-Abschnitt sendrecv oder recvonly, und gibt es RtpTransceiver desselben Typs, die per addTrack zur PeerConnection hinzugefügt wurden, mit keinem „m=“-Abschnitt verknüpft sind und nicht gestoppt sind, den ersten (gemäß der in Abschnitt 5.2.1 beschriebenen kanonischen Reihenfolge) solchen RtpTransceiver finden.

    • Wurde im vorherigen Schritt kein RtpTransceiver gefunden, einen mit Richtung recvonly erstellen.

    • Den gefundenen oder erstellten RtpTransceiver mit dem „m=“-Abschnitt verknüpfen, indem der Wert der mid-Eigenschaft des RtpTransceiver auf die MID des „m=“-Abschnitts gesetzt und eine Zuordnung zwischen Transceiver und Index des „m=“-Abschnitts hergestellt wird. Enthält der „m=“-Abschnitt keine MID (d. h. der entfernte Endpunkt unterstützt die MID-Erweiterung nicht), einen Wert für die mid-Eigenschaft des RtpTransceiver erzeugen, gemäß den Hinweisen zu „a=mid“ in Abschnitt 5.2.1.

  • Für jedes angegebene Medienformat, das auch von der lokalen Implementierung unterstützt wird, eine Zuordnung zwischen dem angegebenen Payload-Typ und dem Medienformat herstellen, wie in [RFC3264], Abschnitt 6.1 beschrieben. Konkret zeichnet die Implementierung den Payload-Typ auf, der in ausgehenden RTP-Paketen beim Senden jedes angegebenen Medienformats verwendet werden soll, sowie die relative Präferenz für jedes Format, die durch ihre Reihenfolge angegeben wird. Ist ein angegebenes Medienformat von der lokalen Implementierung nicht unterstützt, MUSS es ignoriert werden.

  • Für jedes angegebene „rtx“-Medienformat eine Zuordnung zwischen RTX-Payload-Typ und zugehörigem primären Payload-Typ herstellen, wie in [RFC4588], Abschnitt 4 beschrieben. Fehlen referenzierte primäre Payload-Typen, MUSS dies zu einem Fehler führen. RTX-Payload-Typen können auf primäre Payload-Typen verweisen, die von der lokalen Medienimplementierung nicht unterstützt werden; in diesem Fall MUSS der RTX-Payload-Typ ebenfalls ignoriert werden.

  • Für jeden angegebenen fmtp-Parameter, der von der lokalen Implementierung unterstützt wird, diese auf den zugehörigen Medienformaten aktivieren.

  • Für jede angegebene Synchronisationsquelle (Synchronization Source, SSRC), die im „m=“-Abschnitt signalisiert wird, die Demultiplexierung von RTP-Strömen für diesen „m=“-Abschnitt unter Verwendung dieser SSRC vorbereiten, wie in [RFC8843], Abschnitt 9.2 beschrieben.

  • Für jede angegebene RTP-Header-Erweiterung, die auch von der lokalen Implementierung unterstützt wird, eine Zuordnung zwischen Erweiterungs-ID und URI herstellen, wie in [RFC5285], Abschnitt 5 beschrieben. Konkret zeichnet die Implementierung die Erweiterungs-ID auf, die in ausgehenden RTP-Paketen beim Senden jeder angegebenen Header-Erweiterung verwendet werden soll. Ist eine angegebene RTP-Header-Erweiterung von der lokalen Implementierung nicht unterstützt, MUSS sie ignoriert werden.

  • Für jeden angegebenen RTCP-Feedback-Mechanismus, der von der lokalen Implementierung unterstützt wird, diesen auf den zugehörigen Medienformaten aktivieren.

  • Für jeden angegebenen „TIAS“-Bandbreitenwert („Transport Independent Application Specific Maximum“) diesen Wert als Beschränkung der maximalen RTP-Bitrate beim Senden von Medien setzen, wie in [RFC3890] spezifiziert. Ist kein „TIAS“-Wert vorhanden, aber ein „AS“-Wert angegeben, einen „TIAS“-Wert mit dieser Formel erzeugen:

    TIAS = AS * 1000 * 0.95 - (50 * 40 * 8)

    Die 1000 wandelt die Einheit von kbps in bps um (wie von TIAS gefordert), und 0,95 reserviert 5 % für RTCP. Anschließend wird eine Schätzung des Header-Overheads abgezogen, wobei 50 auf 50 Pakete pro Sekunde, 40 auf typische Headergröße (in Byte) und 8 Byte in Bits umrechnet. „TIAS“ ist „AS“ vorzuziehen, da es eine genauere Bandbreitensteuerung ermöglicht.

  • Für „RR“- oder „RS“-Bandbreitenwerte wie in [RFC3556], Abschnitt 2 spezifiziert behandeln.

  • Jeder angegebene „CT“-Bandbreitenwert MUSS ignoriert werden, da die Bedeutung dieses Konstrukts auf Medienebene nicht wohldefiniert ist.

  • Ist der „m=“-Abschnitt vom Typ „audio“:

    • Für jedes angegebene „CN“-Medienformat Stilleunterdrückung für alle unterstützten Medienformate mit derselben Taktfrequenz konfigurieren, wie in [RFC3389], Abschnitt 5 beschrieben, außer für Formate mit eigenen internen Stilleunterdrückungsmechanismen. Stilleunterdrückung für solche Formate (z. B. Opus) wird über fmtp-Parameter gesteuert, wie in Abschnitt 5.2.3.2 erörtert.

    • Für jedes angegebene „telephone-event“-Medienformat Mehrfrequenzwahlverfahren-Übertragung (DTMF) für alle unterstützten Medienformate mit derselben Taktfrequenz aktivieren, wie in [RFC4733], Abschnitt 2.5.1.2 beschrieben. Gibt es unterstützte Medienformate ohne zugehöriges telephone-event-Format, DTMF-Übertragung für diese Formate deaktivieren.

    • Für jeden angegebenen „ptime“-Wert die verfügbaren Medienformate so konfigurieren, dass beim Senden die angegebene Paketgröße verwendet wird. Ist die angegebene Größe für ein Medienformat nicht unterstützt, stattdessen den nächstliegenden Wert verwenden.

Wenn diese Beschreibung schließlich vom Typ „pranswer“ oder „answer“ ist, die in Abschnitt 5.11 definierte Verarbeitung ausführen.