RTCDataChannel.negotiated — Eigenschaft · JavaScript-Referenz

Signatur

RTCDataChannel.negotiated

Beschreibung

Die Eigenschaft negotiated eines RTCDataChannel zeigt, wie der Kanal zwischen den beiden Peers eingerichtet wurde. Ihr Wert stammt aus der Option negotiated im dataChannelDict, das an RTCPeerConnection.createDataChannel() übergeben wird. Ohne Angabe gilt false.

Bei false (Standard, In-Band-Aushandlung) schickt der Browser über SCTP eine DCEP-Nachricht (Data Channel Establishment Protocol) an die Gegenseite. Dort wird dann automatisch ein datachannel-Ereignis auf der RTCPeerConnection ausgelöst. Nur eine Seite ruft createDataChannel() auf, die andere empfängt den Kanal über das Ereignis.

Bei true (Out-of-Band-Aushandlung) handelt die Anwendung den Kanal selbst aus. Beide Peers rufen createDataChannel() mit demselben Label und derselben festen id auf. Ein datachannel-Ereignis gibt es dann nicht. Das lohnt sich, wenn beide Seiten die Kanäle schon vorher kennen (z. B. feste Kanäle für „chat“ und „steuerung“), denn so entfällt die Wartezeit auf die DCEP-Nachricht und die Konfiguration ist symmetrisch.

Die Eigenschaft ist schreibgeschützt. Nach dem Erzeugen des Kanals lässt sie sich nicht mehr ändern.

Rückgabewert

Typ

boolean

Beschreibung

true, wenn die Anwendung den Kanal ausgehandelt hat (Option negotiated: true), sonst false.

Beispiele

Standardfall: In-Band-Aushandlung durch WebRTC

const pc = new RTCPeerConnection();
const channel = pc.createDataChannel('chat');

console.log(channel.negotiated); // Standardwert
console.log(channel.id);         // null, bis SCTP die ID vergibt

// Gegenseite erhält den Kanal über das datachannel-Ereignis:
// remotePc.addEventListener('datachannel', (e) => console.log(e.channel.negotiated));

false null

Out-of-Band: beide Peers legen den Kanal mit fester ID an

// Wird auf BEIDEN Seiten identisch ausgeführt
const createControlChannel = (pc) =>
  pc.createDataChannel('steuerung', {
    negotiated: true,
    id: 0,
    ordered: true
  });

const localPc = new RTCPeerConnection();
const remotePc = new RTCPeerConnection();

const localChannel = createControlChannel(localPc);
const remoteChannel = createControlChannel(remotePc);

console.log(localChannel.negotiated, localChannel.id);
console.log(remoteChannel.negotiated, remoteChannel.id);

true 0 true 0

Kanal-Info für Debugging protokollieren

const describeChannel = (channel) => ({
  label: channel.label,
  id: channel.id,
  aushandlung: channel.negotiated ? 'Anwendung (out-of-band)' : 'WebRTC (in-band)',
  zustand: channel.readyState
});

const pc = new RTCPeerConnection();
const a = pc.createDataChannel('dateien');
const b = pc.createDataChannel('telemetrie', { negotiated: true, id: 5 });

console.table([a, b].map(describeChannel));

// Wichtig · Fallstricke

ID ist Pflicht: Bei negotiated: true muss eine id (0–65534) angegeben werden, sonst wirft createDataChannel() einen TypeError. Bereits belegte IDs führen zu einem OperationError.
Kein datachannel-Ereignis: Out-of-Band-Kanäle lösen auf der Gegenseite kein datachannel-Ereignis aus. Legt nur eine Seite den Kanal an, wird er nie open.
Parameter müssen passen: Beide Peers sollten dieselbe id und dieselben Zuverlässigkeitsoptionen (ordered, maxRetransmits, maxPacketLifeTime) verwenden. WebRTC prüft das nicht, und ungleiche Einstellungen führen zu schwer auffindbaren Fehlern.
ID-Konflikte vermeiden: Nutzt man beide Modi gemischt, können automatisch vergebene IDs mit manuell gewählten kollidieren. Deshalb lieber hohe oder klar reservierte IDs für Out-of-Band-Kanäle nehmen.
Die Eigenschaft wird von allen modernen Browsern unterstützt. Sehr alte Implementierungen (Chrome vor Version 29) kannten die Option noch nicht.

Siehe auch

RTCDataChannel RTCPeerConnection.createDataChannel() RTCDataChannel.id RTCDataChannel.label RTCDataChannel.readyState StorageAccessHandle.localStorage