Wie kann ich ein WebRTC-Angebot ablehnen?

Question

In WebRTC scheint es eine sehr gut definierte Reihenfolge zu geben, in der Dinge passieren. Lokal verwende ich getUserMedia, um meinen lokalen Stream zu erhalten und den Stream in einer Variablen zu speichern. Ich erstelle ein RTCPeerConnection Objekt, das ich nenne, und ich füge den lokalen Strom hinzu. Ich füge einen onaddstream Event-Handler zu pc hinzu, so dass ich den Stream des entfernten Benutzers zu einer Variable speichern kann, und schließlich als das src Attribut eines HTML-Elements wie audio setzen kann. Ich setzte auch onicecandidate Event-Handler auf meinem pc, um Eiskandidaten zu behandeln.

An diesem Punkt gibt es eine RTCPeerConnection, aber kein Remote-Benutzer "noch verbunden". Hier beginnt das "Angebot/Antwort". Nehmen wir an, ich benutze Websockets zur Signalisierung und erhalte ein Angebot, eine Nachricht, die 'Angebot' genannt wird und ein SDP-Objekt enthält. Wie lehne ich es ab und wie sollte dies an beiden Endpunkten gehandhabt werden?

Zum Beispiel könnte ich eine Nachricht "ablehnen" senden, die an den anderen Benutzer weitergeleitet werden würde. Meine RTCPeerConnection existiert noch, und vielleicht möchte ich andere Anrufe empfangen können. Wie es ist, muss ich nichts zu meiner RTCPeerConnection tun, richtig? Muss der andere Benutzer, der das Angebot gesendet hat, etwas tun? Muss er diese bestimmte RTCPeerConnection schließen? Ich würde nicht denken, da er nur ein SDP-Objekt erstellt hat und dann außerhalb von WebRTC über Websockets das Objekt an den anderen Benutzer gesendet hat. Er fügte jedoch das Angebot mit setLocalDescription hinzu. Wenn das Angebot abgelehnt wird, muss er etwas dagegen tun?

Wenn ich ein Angebot erstelle und es an den anderen Benutzer sende, wenn ich nie eine Antwort bekomme, kann ich einfach ein Angebot an einen dritten Benutzer senden und dann, wenn er eine Antwort sendet, bin ich mit ihm verbunden?

Ich habe nichts über den Lebenszyklus einer RTCPeerConnection gefunden.

Answer 1

Proper (spec) Art und Weise Medien

Die "richtige" Art und Weise zu "Reject" angeboten Medien in einer Antwort abzulehnen ist noch nicht in jedem Browser implementiert:

pc.ontrack = e => e.transceiver.stop(); 

Grundsätzlich ist die WebRTC 1.0 spec hat changed quite significantly in diesem Bereich. Kurz gesagt, ein Transceiver ist ein Objekt, das einen Sender und einen Empfänger kombiniert, wobei jeder eine einzelne Spur sendet oder empfängt. transceiver.stop() können Sie eine einzelne bidirektionale m-line (ausgehandelte Medien) in der signalisierten SDP-Medienbeschreibung zurückweisen. Z.B. Sie können Teile eines Angebots in Ihrer Antwort zurückweisen, ohne das Ganze abzulehnen.

Heute

Heute ist die einzige Möglichkeit, einzelne m-Linien abzulehnen ist durch das SDP-Angebot Mangeln/manuell beantworten.

Aber es klingt wie Sie fragen überhaupt nicht darüber. Stattdessen klingt es so, als würden Sie fragen, wie Sie die unvollständige Signalisierung beenden und eine Peer-Verbindung zurück in den "stabilen" Zustand bringen können.

Rollback zu einem stabilen Zustand

Das Angebot/Antwort ist Verhandlungszyklus ein state machine.Der Staat ist pc.signalingState:

Sie gefragt, ob eine Seite von der Verhandlung geht weg, sind auf beiden Seiten benötigen, etwas zu tun, bevor sie ihr Verbindungsobjekt für einen neuen Versuch mit dem gleichen oder verschiedenen wieder Zweck kann Peer. Es hängt davon ab.

Wenn Sie nur createOffer aufgerufen haben, ist kein Rollback des Status erforderlich, da sich createOffer nicht im obigen Diagramm befindet.

Wenn Sie setLocalDescription jedoch genannt haben, dann sind Sie jetzt in "have-local-offer" Zustand, was bedeutet, dass Sie Notwendigkeit tun irgendwie "stable" Zustand zurück zu bekommen, bevor Sie die Verbindung wiederverwenden können. entweder

sind Ihre Optionen, um die Verhandlungen zu beenden, löschen Sie die Verbindung oder Zurückkehren zu stabilem Zustand (derzeit nur supported in Firefox, obwohl es in der Spezifikation ist):

let pc = new RTCPeerConnection(); 
 

 
pc.onnegotiationneeded = async e => { 
 
    try { 
 
    await pc.setLocalDescription(await pc.createOffer()); 
 
    console.log(pc.signalingState); // have-local-offer 
 

 
    await pc.setLocalDescription({type: "rollback"}); 
 
    console.log(pc.signalingState); // stable 
 

 
    } catch(e) { 
 
    console.log(e); 
 
    } 
 
} 
 
pc.createDataChannel("dummy");

<script src="https://webrtc.github.io/adapter/adapter-latest.js"></script>

Natürlich sollten Sie den Peer auch wissen lassen, normalerweise durch Out-of-Band-Signalisierung.

Warum dies normalerweise kein Problem ist.

In typischen Fällen besitzen Sie das JavaScript an beiden Enden, so dass dies nicht auftritt. Mit anderen Worten, der Wunsch, eine Verbindung zu haben, geht gewöhnlich einem voraus.