5.1.2. Profile Names and Interoperability (Profilnamen und Interoperabilität)

5.1.2. Profile Names and Interoperability (Profilnamen und Interoperabilität)

Für Medien-"m="-Abschnitte MÜSSEN JSEP-Implementierungen das in [RFC5764] spezifizierte Profil "UDP/TLS/RTP/SAVPF" sowie das in [RFC7850] spezifizierte Profil "TCP/DTLS/RTP/SAVPF" unterstützen und MÜSSEN eines dieser Profile für jede Medien-"m="-Zeile angeben, die sie in einem Angebot erzeugen. Für Daten-"m="-Abschnitte MÜSSEN Implementierungen das Profil "UDP/DTLS/SCTP" sowie das Profil "TCP/DTLS/SCTP" unterstützen und MÜSSEN eines dieser Profile für jede Daten-"m="-Zeile angeben, die sie in einem Angebot erzeugen. Das zu verwendende genaue Profil wird durch das Protokoll bestimmt, das dem aktuellen Standard- oder ausgewählten ICE-Kandidaten zugeordnet ist, wie in [RFC8839], Abschnitt 4.2.1.2 beschrieben.

Leider erzeugen einige Endpunkte im Versuch der Kompatibilität andere Profilzeichenfolgen, selbst wenn sie beabsichtigen, eines dieser Profile zu unterstützen. Beispielsweise könnte ein Endpunkt "RTP/AVP" generieren, aber "a=fingerprint"- und "a=rtcp-fb"-Attribute bereitstellen, was seine Bereitschaft anzeigt, "UDP/TLS/RTP/SAVPF" oder "TCP/DTLS/RTP/SAVPF" zu unterstützen. Um die Kompatibilität mit solchen Endpunkten zu vereinfachen, MÜSSEN JSEP-Implementierungen die folgenden Regeln befolgen, wenn sie die Medien-"m="-Abschnitte in einem empfangenen Angebot verarbeiten:

• Jedes Profil im Angebot, das mit einem der folgenden übereinstimmt, MUSS akzeptiert werden:

  • "RTP/AVP" (definiert in [RFC4566], Abschnitt 8.2.2)
  • "RTP/AVPF" (definiert in [RFC4585], Abschnitt 9)
  • "RTP/SAVP" (definiert in [RFC3711], Abschnitt 12)
  • "RTP/SAVPF" (definiert in [RFC5124], Abschnitt 6)
  • "TCP/DTLS/RTP/SAVP" (definiert in [RFC7850], Abschnitt 3.4)
  • "TCP/DTLS/RTP/SAVPF" (definiert in [RFC7850], Abschnitt 3.5)
  • "UDP/TLS/RTP/SAVP" (definiert in [RFC5764], Abschnitt 9)
  • "UDP/TLS/RTP/SAVPF" (definiert in [RFC5764], Abschnitt 9)

• Das Profil in jeder "m="-Zeile in jeder generierten Antwort MUSS genau mit dem im Angebot bereitgestellten Profil übereinstimmen.

• Da DTLS-SRTP ERFORDERLICH ist, hat die Wahl von SAVP oder AVP keine Auswirkung; die Unterstützung für DTLS-SRTP wird durch das Vorhandensein eines oder mehrerer "a=fingerprint"-Attribute bestimmt. Beachten Sie, dass das Fehlen eines "a=fingerprint"-Attributs zu einem Verhandlungsfehler führt.

• Die Verwendung von AVPF oder AVP steuert lediglich die Zeitregeln, die für RTCP-Feedback verwendet werden. Wenn AVPF bereitgestellt wird oder ein "a=rtcp-fb"-Attribut vorhanden ist, nehmen Sie AVPF-Timing an, d.h. einen Standardwert von "trr-int=0". Andernfalls nehmen Sie an, dass AVPF in einem AVP-kompatiblen Modus verwendet wird, und verwenden Sie einen Wert von "trr-int=4000".

• Für Daten-"m="-Abschnitte MÜSSEN Implementierungen den Empfang der Profile "UDP/DTLS/SCTP", "TCP/DTLS/SCTP" oder "DTLS/SCTP" (für Rückwärtskompatibilität) unterstützen.

Beachten Sie, dass Neuangebote von JSEP-Implementierungen die korrekten Profilzeichenfolgen verwenden MÜSSEN, selbst wenn der anfängliche Angebots-/Antwortaustausch eine (falsche) ältere Profilzeichenfolge verwendete. Dies vereinfacht das JSEP-Verhalten mit minimalem Nachteil, da jeder entfernte Endpunkt, der ein solches Neuangebot nicht verarbeiten kann, auch das anfängliche Angebot eines JSEP-Endpunkts nicht verarbeiten kann.