5.11. Applying an Answer (Anwenden einer Antwort)

5.11. Applying an Answer (Anwenden einer Antwort)

Zusätzlich zu den oben genannten Schritten zur Verarbeitung einer lokalen oder entfernten Beschreibung werden beim Verarbeiten einer Beschreibung vom Typ „pranswer“ oder „answer“ die folgenden Schritte ausgeführt.

Für jeden „m=“-Abschnitt MÜSSEN die folgenden Schritte ausgeführt werden:

• Wurde der „m=“-Abschnitt abgelehnt (d. h. der Wert des Feldes port ist in der Antwort auf null gesetzt), jeden Empfang oder jede Übertragung von Medien für diesen Abschnitt beenden und, sofern kein nicht abgelehnter „m=“-Abschnitt mit diesem „m=“-Abschnitt gebündelt ist, alle zugehörigen ICE-Komponenten verwerfen, wie in [RFC8839], Abschnitt 4.4.3.1 beschrieben.

• Hat sich der entfernte DTLS-Fingerabdruck geändert oder der Wert des Attributs „a=tls-id“, die DTLS-Verbindung abbauen. Dies schließt den Fall ein, dass der PeerConnection-Zustand „have-remote-pranswer“ ist. Muss eine DTLS-Verbindung abgebaut werden, die Antwort aber keinen ICE-Neustart anzeigt oder – im Fall von „have-remote-pranswer“ – keine neuen ICE-Anmeldedaten, MUSS ein Fehler erzeugt werden. Wird ein ICE-Neustart ohne Änderung des tls-id-Werts oder Fingerabdruchs durchgeführt, wird dieselbe DTLS-Verbindung über den neuen ICE-Kanal fortgesetzt. Obwohl JSEP verlangt, dass Antwortende den tls-id-Wert genau dann ändern, wenn der Anbietende es tut, dürfen nicht-JSEP-Antwortende den tls-id-Wert ändern, solange das Angebot einen ICE-Neustart enthielt. JSEP-Implementierungen, die DTLS-Daten vor Empfang einer Antwort verarbeiten, MÜSSEN daher darauf vorbereitet sein, entweder ein ClientHello oder Daten von der vorherigen DTLS-Verbindung zu empfangen.

• Existiert keine gültige DTLS-Verbindung, den Start einer DTLS-Verbindung unter Verwendung der angegebenen Rollen und Fingerabdrucke auf den zugrunde liegenden ICE-Komponenten vorbereiten, sobald diese aktiv sind.

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

  • Verweist der „m=“-Abschnitt auf RTCP-Feedback-Mechanismen, die im entsprechenden „m=“-Abschnitt des Angebots nicht vorhanden waren, weist dies auf ein Verhandlungsproblem hin und MUSS zu einem Fehler führen. Neue Medienformate und neue RTP-Header-Erweiterungswerte sind in der Antwort jedoch erlaubt, wie in [RFC3264], Abschnitt 7 und [RFC5285], Abschnitt 6 beschrieben.

  • Ist für den „m=“-Abschnitt RTCP-Mux aktiviert, die RTCP-ICE-Komponente verwerfen, falls vorhanden, und RTCP über die RTP-ICE-Komponente multiplexen beginnen oder fortsetzen, wie in [RFC5761], Abschnitt 5.1.3 spezifiziert. Andernfalls die Übertragung von RTCP über die RTCP-ICE-Komponente vorbereiten; existiert keine RTCP-ICE-Komponente, weil RTCP-Mux zuvor aktiviert war, MUSS dies zu einem Fehler führen.

  • Ist für den „m=“-Abschnitt Reduced-Size RTCP aktiviert, die RTCP-Übertragung für diesen „m=“-Abschnitt so konfigurieren, dass Reduced-Size RTCP verwendet wird, wie in [RFC5506] spezifiziert.

  • Gibt das Richtungsattribut in der Antwort an, dass die JSEP-Implementierung Medien senden soll („sendonly“ für lokale Antworten, „recvonly“ für entfernte Antworten oder „sendrecv“ für beide Antworttypen), das zu sendende Medienformat als das am stärksten bevorzugte Medienformat aus der entfernten Beschreibung wählen, das auch lokal unterstützt wird, wie in den Abschnitten 6.1 und 7 von [RFC3264] erörtert, und RTP-Medien mit diesem Format übertragen, sobald die zugrunde liegenden Transportschichten etabliert sind. Wurde für diesen ausgehenden RTP-Strom noch kein SSRC gewählt, einen eindeutigen zufälligen wählen. Werden bereits Medien übertragen, SOLLTE derselbe SSRC verwendet werden, es sei denn, die Taktfrequenz des neuen Codecs ist unterschiedlich; in diesem Fall MUSS ein neuer SSRC gewählt werden, wie in [RFC7160], Abschnitt 4.1 spezifiziert.

  • Die Payload-Typ-Zuordnung aus der entfernten Beschreibung wird verwendet, um Payload-Typen für die ausgehenden RTP-Ströme zu bestimmen, einschließlich des Payload-Typs für das oben gewählte Sendemedienformat. Verhandelte RTP-Header-Erweiterungen sollten in die ausgehenden RTP-Ströme aufgenommen werden, unter Verwendung der Erweiterungszuordnung aus der entfernten Beschreibung. Wurde die MID-Header-Erweiterung verhandelt, sie in die ausgehenden RTP-Ströme aufnehmen, wie in [RFC8843], Abschnitt 15 angegeben. Wurden die Header-Erweiterungen RtpStreamId oder RepairedRtpStreamId verhandelt und rid-ids festgelegt, diese Header-Erweiterungen in die ausgehenden RTP-Ströme aufnehmen, wie in [RFC8851], Abschnitt 4 angegeben.

  • Ist der „m=“-Abschnitt vom Typ „audio“, und wurde Stilleunterdrückung (1) für das Sendemedienformat als Ergebnis der Verarbeitung der entfernten Beschreibung konfiguriert und (2) für dieses Format auch in der lokalen Beschreibung aktiviert, Stilleunterdrückung für ausgehende Medien gemäß den Hinweisen in Abschnitt 5.2.3.2 verwenden. Sind diese Bedingungen nicht erfüllt, DARF Stilleunterdrückung für ausgehende Medien NICHT verwendet werden.

  • Wurde Simulcast verhandelt, die angemessene Anzahl von Quell-RTP-Strömen (Source RTP Streams) senden, wie in [RFC8853], Abschnitt 5.3.3 spezifiziert.

  • Hat das oben gewählte Sendemedienformat ein zugehöriges „rtx“-Medienformat oder wurde ein FEC-Mechanismus verhandelt, einen redundanten RTP-Strom mit eindeutigem zufälligem SSRC für jeden Quell-RTP-Strom etablieren und bei Bedarf RTX-/FEC-Pakete senden oder fortsetzen.

  • Hat das oben gewählte Sendemedienformat ein zugehöriges „red“-Medienformat derselben Taktfrequenz, redundante Kodierung mit dem angegebenen Format zu Resilienz-Zwecken erlauben, wie in [RFC8854], Abschnitt 3.2 erörtert. Im Gegensatz zu RTX- oder FEC-Medienformaten wird das „red“-Format auf dem Quell-RTP-Strom übertragen, nicht auf dem redundanten RTP-Strom.

  • Die in dem Medienabschnitt referenzierten RTCP-Feedback-Mechanismen für alle Quell-RTP-Ströme unter Verwendung der angegebenen Medienformate aktivieren. Konkret das Senden der angeforderten Feedback-Typen und die Reaktion auf empfangenes Feedback beginnen oder fortsetzen, wie in [RFC4585], Abschnitt 4.2 spezifiziert. Beim Senden von RTCP-Feedback die Regeln und Empfehlungen aus [RFC8108], Abschnitt 5.4.1 befolgen, um auszuwählen, welcher SSRC verwendet wird.

  • Gibt das Richtungsattribut in der Antwort an, dass die JSEP-Implementierung keine Medien senden soll („recvonly“ für lokale Antworten, „sendonly“ für entfernte Antworten oder „inactive“ für beide Antworttypen), die Übertragung aller RTP-Medien stoppen, aber RTCP weiter senden, wie in [RFC3264], Abschnitt 5.1 beschrieben.

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

  • Existiert eine SCTP-Assoziation und hat sich der entfernte SCTP-Port geändert, die bestehende SCTP-Assoziation verwerfen. Dies schließt den Fall ein, dass der PeerConnection-Zustand „have-remote-pranswer“ ist.

  • Existiert keine gültige SCTP-Assoziation, die Einleitung einer SCTP-Assoziation über die zugehörige ICE-Komponente und DTLS-Verbindung vorbereiten, unter Verwendung des lokalen SCTP-Portwerts aus der lokalen Beschreibung und des entfernten SCTP-Portwerts aus der entfernten Beschreibung, wie in [RFC8841], Abschnitt 10.2 beschrieben.

Enthält die Antwort gültige Bundle-Gruppen, alle ICE-Komponenten für die „m=“-Abschnitte verwerfen, die auf die primären ICE-Komponenten in jedem Bundle gebündelt werden, und das Multiplexen dieser „m=“-Abschnitte entsprechend beginnen, wie in [RFC8843], Abschnitt 7.4 beschrieben.

Wenn die Beschreibung vom Typ „answer“ ist und noch Kandidaten im ICE-Kandidatenpool verbleiben, diese verwerfen.