5.3.2. Subsequent Answers (Nachfolgende Antworten)

5.3.2. Subsequent Answers (Nachfolgende Antworten)

Wird createAnswer ein zweites (oder späteres) Mal aufgerufen oder nachdem bereits eine lokale Beschreibung installiert wurde, unterscheidet sich die Verarbeitung etwas von der einer initialen Antwort.

Wurde die vorherige Antwort nicht mit setLocalDescription angewendet, d. h. die PeerConnection befindet sich noch im Zustand "have-remote-offer", MÜSSEN die Schritte zur Erzeugung einer initialen Antwort befolgt werden, vorbehaltlich folgender Einschränkung:

• Die Felder der "o="-Zeile MÜSSEN unverändert bleiben, außer dem Feld <session-version>, das inkrementiert werden MUSS, wenn sich die Sitzungsbeschreibung in irgendeiner Weise von der zuvor erzeugten Antwort unterscheidet.

Wurde zuvor eine Sitzungsbeschreibung an setLocalDescription übergeben, wird eine Antwort erzeugt, indem die Schritte im Zustand "have-remote-offer" oben befolgt werden, zusammen mit diesen Ausnahmen:

• Die "s="- und "t="-Zeilen MÜSSEN unverändert bleiben.

• Jede "m="- und "c="-Zeile MUSS mit Port und Adresse des Standardkandidaten für den "m="-Abschnitt ausgefüllt werden, wie in [RFC8839], Abschnitt 4.2.1.2 beschrieben. In bestimmten Fällen kann das Protokoll der "m="-Zeile nicht mit dem des Standardkandidaten übereinstimmen, da der Protokollwert der "m="-Zeile mit dem im Angebot übereinstimmen MUSS, wie oben beschrieben.

• Jede "a=ice-ufrag"- und "a=ice-pwd"-Zeile MUSS unverändert bleiben, es sei denn, der "m="-Abschnitt startet neu; dann MÜSSEN neue ICE-Anmeldeinformationen wie in [RFC8839], Abschnitt 4.4.1.1.1 angegeben erstellt werden. Ist der "m="-Abschnitt in einen anderen "m="-Abschnitt gebündelt, DARF er weiterhin KEINE ICE-Anmeldeinformationen enthalten.

• Jede "a=tls-id"-Zeile MUSS unverändert bleiben, es sei denn, die "a=tls-id"-Zeile des Anbieters hat sich geändert; dann MUSS ein neuer tls-id-Wert wie in [RFC8842], Abschnitt 5.2 beschrieben erstellt werden.

• Jede "a=setup"-Zeile MUSS einen "active"- oder "passive"-Rollenwert verwenden, der mit der bestehenden DTLS-Assoziation übereinstimmt, wenn der Anbieter die Assoziation fortsetzt.

• RTCP-Multiplexing MUSS verwendet werden, und eine "a=rtcp-mux"-Zeile wird genau dann eingefügt, wenn der "m="-Abschnitt zuvor RTCP-Multiplexing nutzte.

• Ist der "m="-Abschnitt nicht in einen anderen gebündelt und RTCP-Multiplexing nicht aktiv, MUSS eine "a=rtcp"-Attributzeile mit Port und Adresse des Standard-RTCP-Kandidaten ausgefüllt werden. Wurden noch keine RTCP-Kandidaten gesammelt, MÜSSEN Standardwerte wie in Abschnitt 5.3.1 oben beschrieben verwendet werden.

• Ist der "m="-Abschnitt nicht in einen anderen gebündelt, MUSS für jeden in der jüngsten Sammelphase gesammelten Kandidaten (siehe Abschnitt 3.5.1) eine "a=candidate"-Zeile hinzugefügt werden, wie in [RFC8839], Abschnitt 5.1 definiert. Ist die Kandidatensammlung für den Abschnitt abgeschlossen, MUSS ein "a=end-of-candidates"-Attribut wie in [RFC8840], Abschnitt 8.2 beschrieben hinzugefügt werden. Ist der "m="-Abschnitt gebündelt, MÜSSEN sowohl "a=candidate" als auch "a=end-of-candidates" weggelassen werden.

• Für nicht gestoppte RtpTransceiver MÜSSEN die "a=msid"-Zeilen unverändert bleiben, unabhängig von Änderungen an Richtung oder Spur des Transceivers. Ist keine "a=msid"-Zeile in der aktuellen Beschreibung vorhanden, MÜSSEN "a=msid"-Zeilen nach denselben Regeln wie bei einer initialen Antwort erzeugt werden.