Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.

View in English Always switch to English

RTCDtlsTransport

Baseline Weitgehend verfügbar *

Diese Funktion ist gut etabliert und funktioniert auf vielen Geräten und in vielen Browserversionen. Sie ist seit März 2022 browserübergreifend verfügbar.

* Einige Teile dieser Funktion werden möglicherweise unterschiedlich gut unterstützt.

Das RTCDtlsTransport-Interface bietet Zugriff auf Informationen über den Datagram Transport Layer Security (DTLS) Transport, über den die RTP- und RTCP-Pakete einer RTCPeerConnection von ihren RTCRtpSender- und RTCRtpReceiver-Objekten gesendet und empfangen werden.

Ein RTCDtlsTransport-Objekt wird auch verwendet, um Informationen über SCTP-Pakete bereitzustellen, die von den Datenkanälen einer Verbindung übertragen und empfangen werden.

Merkmale des DTLS-Transports umfassen die Hinzufügung von Sicherheit zum zugrunde liegenden Transport; das RTCDtlsTransport-Interface kann verwendet werden, um Informationen über den zugrunde liegenden Transport und die Sicherheit zu erhalten, die von der DTLS-Schicht hinzugefügt wurde.

EventTarget RTCDtlsTransport

Instanzeigenschaften

Erbt auch Eigenschaften von EventTarget.

iceTransport Schreibgeschützt

Gibt eine Referenz auf das zugrunde liegende RTCIceTransport-Objekt zurück.

state Schreibgeschützt

Gibt einen string zurück, der den Zustand des zugrunde liegenden Datagram Transport Layer Security (DTLS) Transports beschreibt. Es kann einen der folgenden Werte haben: new, connecting, connected, closed oder failed.

Instanzmethoden

Erbt auch Methoden von EventTarget.

getRemoteCertificates()

Gibt ein Array von ArrayBuffer-Objekten zurück, die die Zertifikatskette des entfernten Peers darstellen.

Ereignisse

error

Wird gesendet, wenn auf der RTCPeerConnection ein Fehler auf Transportschicht-Ebene auftritt.

statechange

Wird gesendet, wenn sich der state des DTLS-Transports ändert.

Beschreibung

Zuweisung von DTLS-Transporten

RTCDtlsTransport-Objekte werden erstellt, wenn eine App entweder setLocalDescription() oder setRemoteDescription() aufruft. Die Anzahl der erstellten DTLS-Transporte und ihre Verwendung hängt vom verwendeten Bündelungsmodus ab, der bei der Erstellung der RTCPeerConnection verwendet wird.

Bündelung ermöglicht es, einen RTCDtlsTransport zu verwenden, um die Daten für mehrere höherstufige Transporte, wie mehrere RTCRtpTransceiver zu tragen. Ob Bündelung verwendet wird, hängt davon ab, was der andere Endpunkt verhandeln kann. Alle Browser unterstützen Bündelung, sodass, wenn beide Endpunkte Browser sind, Sie sicher sein können, dass Bündelung verwendet wird.

Einige nicht-browserbasierte Legacy-Endpunkte unterstützen jedoch möglicherweise kein Bündel. Um mit solchen Endpunkten verhandeln zu können (oder sie vollständig auszuschließen), kann die Eigenschaft bundlePolicy bei der Erstellung der Verbindung angegeben werden. Die bundlePolicy ermöglicht es Ihnen, zu steuern, wie mit diesen Legacy-Endpunkten verhandelt wird. Die Standardrichtlinie ist "balanced", die ein Gleichgewicht zwischen Leistung und Kompatibilität bietet.

Zum Beispiel, um die Verbindung mit dem höchsten Bündelungsgrad zu erstellen:

js
const rtcConfig = {
  bundlePolicy: "max-bundle",
};

const pc = new RTCPeerConnection(rtcConfig);

Wenn BUNDLE nicht verwendet wird

Wenn die Verbindung erstellt wird, ohne BUNDLE zu verwenden, hat jede RTP- oder RTCP-Komponente jedes RTCRtpTransceiver ihren eigenen RTCDtlsTransport; das heißt, jeder RTCRtpSender und RTCRtpReceiver hat seinen eigenen Transport, und alle RTCDataChannel-Objekte teilen sich einen Transport, der dem SCTP gewidmet ist.

Wenn BUNDLE verwendet wird

Wenn die Verbindung BUNDLE verwendet, repräsentiert jedes RTCDtlsTransport-Objekt eine Gruppe von RTCRtpTransceiver-Objekten. Wenn die Verbindung im max-compat-Modus erstellt wurde, ist jeder Transport dafür verantwortlich, alle Kommunikationen für einen bestimmten Medientyp (Audio, Video oder Datenkanal) zu handhaben. Somit wird eine Verbindung mit einer beliebigen Anzahl von Audio- und Videokanälen immer genau einen DTLS-Transport für Audio- und einen für Videokommunikation haben.

Da die Transporte früh im Verhandlungsprozess etabliert werden, ist es wahrscheinlich, dass erst nach ihrer Erstellung bekannt wird, ob der entfernte Peer Bündelung unterstützt oder nicht. Aus diesem Grund sehen Sie manchmal, dass zuerst separate Transporte erstellt werden, jeweils einer für jede Spur, und dass sie dann zusammengebündelt werden, sobald bekannt ist, dass Bündelung möglich ist. Wenn Ihr Code direkt auf RTCRtpSenders und/oder RTCRtpReceivers zugreift, könnten Sie auf Situationen stoßen, in denen sie zunächst separat sind, dann die Hälfte oder mehr von ihnen geschlossen werden und die Sender und Empfänger aktualisiert werden, um auf die entsprechenden verbleibenden RTCDtlsTransport-Objekte zu verweisen.

Datenkanäle

RTCDataChannels verwenden SCTP zur Kommunikation. Alle Datenkanäle einer Peer-Verbindung teilen sich einen einzigen RTCSctpTransport, der sich in der sctp-Eigenschaft der Verbindung befindet.

Sie können wiederum den RTCDtlsTransport identifizieren, der verwendet wird, um die SCTP-Kommunikation der Datenkanäle sicher zu kapseln, indem Sie die transport-Eigenschaft des RTCSctpTransport-Objekts betrachten.

Beispiele

Dieses Beispiel präsentiert eine Funktion, tallySenders(), die die RTCRtpSender einer RTCPeerConnection iteriert und auflistet, wie viele von ihnen sich in verschiedenen Zuständen befinden. Die Funktion gibt ein Objekt zurück, dessen Eigenschaften anzeigen, wie viele Sender sich in jedem Zustand befinden.

js
let pc = new RTCPeerConnection({ bundlePolicy: "max-bundle" });

// …

function tallySenders(pc) {
  let results = {
    transportMissing: 0,
    connectionPending: 0,
    connected: 0,
    closed: 0,
    failed: 0,
    unknown: 0,
  };

  let senderList = pc.getSenders();
  senderList.forEach((sender) => {
    let transport = sender.transport;

    if (!transport) {
      results.transportMissing++;
    } else {
      switch (transport.state) {
        case "new":
        case "connecting":
          results.connectionPending++;
          break;
        case "connected":
          results.connected++;
          break;
        case "closed":
          results.closed++;
          break;
        case "failed":
          results.failed++;
          break;
        default:
          results.unknown++;
          break;
      }
    }
  });
  return results;
}

Beachten Sie, dass in diesem Code die Zustände new und connecting als ein einziger connectionPending-Status im zurückgegebenen Objekt behandelt werden.

Spezifikationen

Spezifikation
WebRTC: Real-Time Communication in Browsers
# dom-rtcdtlstransport

Browser-Kompatibilität

Siehe auch