Zum Hauptinhalt springen

5.3.1. Initial Answers (Initiale Antworten)

5.3.1. Initial Answers (Initiale Antworten)​

Wird createAnswer zum ersten Mal aufgerufen, nachdem eine Remote-Beschreibung bereitgestellt wurde, heißt das Ergebnis initiale Antwort. Ist keine Remote-Beschreibung installiert, kann keine Antwort erzeugt werden, und es MUSS ein Fehler zurückgegeben werden.

Beachten Sie, dass das SDP der Remote-Beschreibung möglicherweise nicht von einem JSEP-Endpunkt stammt und nicht allen Anforderungen in Abschnitt 5.2 entspricht. In vielen Fällen ist das kein Problem. Fehlen jedoch obligatorische SDP-Attribute oder ist oben als obligatorisch aufgeführte Funktionalität nicht vorhanden, MUSS dies als Fehler behandelt werden, und die betroffenen "m="-Abschnitte MÜSSEN als abgelehnt markiert werden.

Der erste Schritt bei der Erzeugung einer initialen Antwort ist die Erzeugung von Attributen auf Sitzungsebene. Der Vorgang entspricht dem in Abschnitt 5.2.1 oben, außer dass die "a=ice-options"-Zeile mit der Option "trickle" wie in [RFC8840], Abschnitt 4.1.3, und der Option "ice2" wie in [RFC8445], Abschnitt 10, nur enthalten ist, wenn eine solche Option im Angebot vorhanden war.

Als Nächstes werden Sitzungs-Lipsync-Gruppen erzeugt, definiert in [RFC5888], Abschnitt 7. Für jede Gruppe vom Typ "LS" im Angebot wählen Sie die lokalen RtpTransceiver, auf die die MID-Werte der angegebenen Gruppe verweisen, und bestimmen, welche entweder einen gemeinsamen lokalen MediaStream referenzieren (in den addTrack-/addTransceiver-Aufrufen bei der Erstellung angegeben) oder keinen MediaStream referenzieren, weil sie nicht durch addTrack/addTransceiver erstellt wurden. Existieren mindestens zwei solcher RtpTransceiver, MUSS eine Gruppe vom Typ "LS" mit den MID-Werten dieser RtpTransceiver hinzugefügt werden. Andernfalls MUSS die angebotene "LS"-Gruppe ignoriert und keine entsprechende Gruppe in der Antwort erzeugt werden.

Als einfaches Beispiel betrachten Sie folgendes Angebot mit einer Audio- und einer Videospur im selben MediaStream. Irrelevante SDP-Zeilen wurden der Klarheit halber entfernt. Wie in Abschnitt 5.2 erläutert, wurde eine Gruppe vom Typ "LS" hinzugefügt, die den RtpTransceiver jeder Spur referenziert.

        a=group:LS a1 v1
        m=audio 10000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms1
        m=video 10001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms1

Verwendet der Antwortende einen einzelnen MediaStream beim Hinzufügen seiner Spuren, referenzieren beide Transceiver diesen Strom, und die nachfolgende Antwort enthält eine "LS"-Gruppe wie im Angebot, wie unten:

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2

Gruppiert der Antwortende die Spuren in getrennte MediaStreams, referenzieren die Transceiver verschiedene Ströme, und die nachfolgende Antwort enthält keine "LS"-Gruppe.

        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2a
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2b

Fügt der Antwortende keine Spuren hinzu, referenzieren die Transceiver keine MediaStreams, die Präferenzen des Anbieters bleiben erhalten, und die nachfolgende Antwort enthält eine identische "LS"-Gruppe.

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=recvonly
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=recvonly

Das Beispiel in Abschnitt 7.2 zeigt einen komplexeren Fall der "LS"-Gruppenerzeugung.

Als Nächstes wird für jeden im Remote-Angebot vorhandenen "m="-Abschnitt ein "m="-Abschnitt erzeugt, wie in [RFC3264], Abschnitt 6, angegeben. Für diese Diskussion gelten Sitzungsattribute im Angebot, die auch auf Medienebene gültig sind, als in jedem "m="-Abschnitt vorhanden. Jedem angebotenen "m="-Abschnitt ist ein RtpTransceiver zugeordnet, wie in Abschnitt 5.10 beschrieben. Gibt es mehr RtpTransceiver als "m="-Abschnitte, müssen die nicht zugeordneten RtpTransceiver in einem späteren Angebot zugeordnet werden.

Für jeden angebotenen "m="-Abschnitt gilt: Ist eine der folgenden Bedingungen wahr, MUSS der entsprechende "m="-Abschnitt in der Antwort als abgelehnt markiert werden, indem <port> in der "m="-Zeile auf null gesetzt wird, wie in [RFC3264], Abschnitt 6, angegeben; weitere Verarbeitung für diesen "m="-Abschnitt kann entfallen:

  • Der zugehörige RtpTransceiver wurde gestoppt.

  • Es gibt kein angebotenes Medienformat, das sowohl unterstützt als auch gegebenenfalls durch Codec-Präferenzen erlaubt ist.

  • Die Bundle-Richtlinie ist "max-bundle", und dies ist nicht der erste "m="-Abschnitt oder nicht in derselben Bundle-Gruppe wie der erste "m="-Abschnitt.

  • Die Bundle-Richtlinie ist "balanced", und dies ist nicht der erste "m="-Abschnitt für diesen Medientyp oder nicht in derselben Bundle-Gruppe wie der erste "m="-Abschnitt für diesen Medientyp.

  • Dieser "m="-Abschnitt liegt in einer Bundle-Gruppe, und der vom Anbieter markierte "m="-Abschnitt der Gruppe wird aus einem der obigen Gründe abgelehnt. Dann müssen alle "m="-Abschnitte der Gruppe abgelehnt werden, wie in [RFC8843], Abschnitt 7.3.3, angegeben.

Andernfalls MUSS jeder "m="-Abschnitt in der Antwort wie in [RFC3264], Abschnitt 6.1, erzeugt werden. Für die "m="-Zeile selbst gelten folgende Regeln:

  • Der <port>-Wert würde normalerweise auf den Port des Standard-ICE-Kandidaten für diesen "m="-Abschnitt gesetzt; da noch keine Kandidaten verfügbar sind, MUSS der Standard-<port>-Wert 9 (Discard) verwendet werden, wie in [RFC8840], Abschnitt 4.1.1, angegeben.

  • Das Feld <proto> MUSS exakt dem <proto>-Feld der entsprechenden "m="-Zeile im Angebot entsprechen.

  • Sind Codec-Präferenzen für den zugehörigen Transceiver gesetzt, MÜSSEN Medienformate in der entsprechenden Reihenfolge erzeugt werden, unabhängig vom Angebot, und Codecs außerhalb der Präferenzen MÜSSEN ausgeschlossen werden.

  • Andernfalls MÜSSEN die Medienformate auf der "m="-Zeile in derselben Reihenfolge wie im aktuellen Remote-Angebot erzeugt werden, unter Ausschluss nicht unterstützter Formate. Alle verfügbaren Formate, die nicht im aktuellen Remote-Angebot stehen, MÜSSEN nach allen bestehenden Formaten angefügt werden.

  • In beiden Fällen MÜSSEN die Medienformate in der Antwort mindestens ein im Angebot vorhandenes Format enthalten, dürfen aber lokal unterstützte, im Angebot fehlende Formate enthalten, wie in [RFC3264], Abschnitt 6.1, erwähnt. Gibt es kein gemeinsames Format, wird der "m="-Abschnitt wie oben abgelehnt.

Auf die "m="-Zeile MUSS unmittelbar eine "c="-Zeile folgen, wie in [RFC4566], Abschnitt 5.7. Da noch keine Kandidaten vorhanden sind, MUSS die "c="-Zeile den Standardwert "IN IP4 0.0.0.0" enthalten, definiert in [RFC8840], Abschnitt 4.1.3.

Unterstützt das Angebot Bundling, MÜSSEN alle zu bündelnden "m="-Abschnitte dieselben ICE-Anmeldeinformationen und -kandidaten verwenden; alle nicht gebündelten "m="-Abschnitte MÜSSEN eindeutige ICE-Anmeldeinformationen und -kandidaten verwenden. Jeder "m="-Abschnitt MUSS folgende Attribute enthalten (Typen weder IDENTICAL noch TRANSPORT):

  • Genau dann, wenn im Angebot vorhanden, eine "a=mid"-Zeile, wie in [RFC5888], Abschnitt 9.1. Der MID-Wert MUSS dem im Angebot entsprechen.

  • Ein Richtungsattribut, ermittelt durch Anwendung der in [RFC3264], Abschnitt 6.1, für die angebotene Richtung und Schnittmenge mit der Richtung des zugehörigen RtpTransceiver. Beispiel: Wird "sendonly" angeboten und der lokale Transceiver steht auf "sendrecv", ergibt sich in der Antwort "recvonly".

  • Für jedes Medienformat auf der "m="-Zeile "a=rtpmap"- und "a=fmtp"-Zeilen, wie in [RFC4566], Abschnitt 6, und [RFC3264], Abschnitt 6.1.

  • Ist "rtx" im Angebot, für jeden primären Codec mit RTP-Retransmission eine entsprechende "a=rtpmap"-Zeile mit "rtx" und Taktrate des primären Codecs sowie "a=fmtp", die den Payload-Typ des primären Codecs referenziert, wie in [RFC4588], Abschnitt 8.1.

  • Für jeden unterstützten FEC-Mechanismus "a=rtpmap"- und "a=fmtp"-Zeilen, wie in [RFC4566], Abschnitt 6. Zu unterstützende FEC-Mechanismen siehe [RFC8854], Abschnitt 7; Nutzung pro Medientyp in Abschnitten 4 und 5.

  • Ist dieser "m="-Abschnitt für Medien mit konfigurierbarer Paketdauer, z. B. Audio, eine "a=maxptime"-Zeile wie in Abschnitt 5.2.

  • Ist dieser "m="-Abschnitt für Video und sind Dekodiergrenzen für Bildgrößen bekannt, eine "a=imageattr"-Zeile wie in Abschnitt 3.6.

  • Für jede unterstützte, im Angebot vorhandene RTP-Header-Erweiterung eine "a=extmap"-Zeile, wie in [RFC5285], Abschnitt 5. Liste in [RFC8834], Abschnitt 5.2. Erfordert Verschlüsselung, wie in [RFC6904], Abschnitt 4.

  • Für jeden unterstützten, im Angebot vorhandenen RTCP-Feedback-Mechanismus eine "a=rtcp-fb"-Zeile, wie in [RFC4585], Abschnitt 4.2. Liste in [RFC8834], Abschnitt 5.1.

  • Hat der RtpTransceiver die Richtung sendrecv oder sendonly:

    • Für jeden beim Erstellen per addTrack oder addTransceiver zugeordneten MediaStream eine "a=msid"-Zeile, wie in [RFC8830], Abschnitt 2, ohne Feld "appdata".

Jeder "m="-Abschnitt, der nicht in einen anderen gebündelt ist, MUSS folgende Attribute enthalten (Kategorie IDENTICAL oder TRANSPORT):

  • "a=ice-ufrag"- und "a=ice-pwd"-Zeilen, wie in [RFC8839], Abschnitt 5.4.

  • Pro gewünschtem Digest-Algorithmus eine oder mehrere "a=fingerprint"-Zeilen pro Zertifikat des Endpunkts, wie in [RFC8122], Abschnitt 5.

  • Eine "a=setup"-Zeile, wie in [RFC4145], Abschnitt 4, und für DTLS-SRTP in [RFC5763], Abschnitt 5. Der Rollenwert in der Antwort MUSS "active" oder "passive" sein. Enthält das Angebot "actpass" (bei JSEP immer der Fall), SOLLTE der Antwortende "active" wählen. Nicht-JSEP-Angebote dürfen andere "a=setup"-Werte senden; dann MUSS die Antwort einen mit dem Angebot konsistenten Wert verwenden.

  • Eine "a=tls-id"-Zeile, wie in [RFC8842], Abschnitt 5.3.

  • Ist im Angebot eine "a=rtcp-mux"-Zeile, wie in [RFC5761], Abschnitt 5.1.3. Sonst eine "a=rtcp"-Zeile, wie in [RFC3605], Abschnitt 2.1, mit Standardwert "9 IN IP4 0.0.0.0" (noch keine Kandidaten).

  • Ist im Angebot eine "a=rtcp-rsize"-Zeile, wie in [RFC5506], Abschnitt 5.

Wurde ein Datenkanal-"m="-Abschnitt angeboten, MUSS auch ein "m="-Abschnitt für Daten erzeugt werden. Das Feld <media> MUSS "application" sein; <proto> und <fmt> MÜSSEN exakt dem Angebot entsprechen.

Im Daten-"m="-Abschnitt MUSS eine "a=mid"-Zeile wie oben erzeugt werden sowie eine "a=sctp-port"-Zeile mit SCTP-Port, definiert in [RFC8841], Abschnitt 5.1, und gegebenenfalls "a=max-message-size", definiert in [RFC8841], Abschnitt 6.1.

Wie oben: Folgende IDENTICAL-/TRANSPORT-Attribute nur, wenn der Daten-"m="-Abschnitt nicht in einen anderen gebündelt ist:

  • "a=ice-ufrag"

  • "a=ice-pwd"

  • "a=fingerprint"

  • "a=setup"

  • "a=tls-id"

Sind Medien-"m="-Abschnitte in einen Daten-"m="-Abschnitt gebündelt, können TRANSPORT-/IDENTICAL-Attribute auch im Daten-"m="-Abschnitt erscheinen, selbst wenn sie sonst nur für Medien gelten würden (z. B. "a=rtcp-mux").

Werden "a=group"-Attribute mit Semantik "BUNDLE" angeboten, MÜSSEN entsprechende Sitzungs-"a=group"-Attribute wie in [RFC5888] hinzugefügt werden. Semantik MUSS "BUNDLE" sein; alle mid-IDs nicht abgelehnter Bundle-Gruppen MÜSSEN enthalten sein. Unabhängig von "a=bundle-only" im Angebot DÜRFEN "m="-Abschnitte in der Antwort KEINE "a=bundle-only"-Zeile haben.

Gemeinsame Attribute aller "m="-Abschnitte dürfen auf Sitzungsebene verschoben werden, wenn dort explizit gültig.

Beim Angebotsaufbau verbotene Attribute sind auch beim Antwortaufbau verboten.

Letztes Update am