Baseline Widely available
Die createOffer()-Methode der RTCPeerConnection-Schnittstelle initiiert die Erstellung eines SDP-Angebots, um eine neue WebRTC-Verbindung zu einem entfernten Peer zu starten.
Das SDP-Angebot enthält Informationen über alle bereits an die WebRTC-Sitzung angehängten MediaStreamTrack-Objekte, unterstützte Codecs und Optionen durch den Browser sowie alle bereits vom ICE-Agenten gesammelten Kandidaten, die über den Signalisierungskanal an einen potenziellen Peer gesendet werden sollen, um eine Verbindung anzufordern oder die Konfiguration einer bestehenden Verbindung zu aktualisieren.
createOffer()
createOffer(options)
createOffer(successCallback, failureCallback) // deprecated
createOffer(successCallback, failureCallback, options) // deprecated
options Optional
Ein Objekt, das die folgenden für das Angebot angeforderten Optionen bereitstellt:
iceRestart Optional
Um ICE auf einer aktiven Verbindung neu zu starten, setzen Sie dies auf true. Dies führt dazu, dass das zurückgegebene Angebot andere Anmeldedaten hat als die bereits bestehenden. Falls Sie dann das zurückgegebene Angebot anwenden, wird ICE neu gestartet. Geben Sie false an, um dieselben Anmeldedaten beizubehalten und ICE daher nicht neu zu starten. Der Standardwert ist false. Anstelle dieser Option erwägen Sie den Aufruf von RTCPeerConnection.restartIce(), das diese Option beim nächsten Aufruf von createOffer() automatisch setzt.
offerToReceiveAudio Optional Veraltet
Bietet zusätzliche Kontrolle über die Ausrichtung von Audio. Zum Beispiel kann sichergestellt werden, dass Audio empfangen werden kann, unabhängig davon, ob Audio gesendet wird oder nicht.
offerToReceiveVideo Optional Veraltet
Bietet zusätzliche Kontrolle über die Ausrichtung von Video. Zum Beispiel kann sichergestellt werden, dass Video empfangen werden kann, unabhängig davon, ob Video gesendet wird oder nicht.
In älterem Code und Dokumentationen könnten Sie eine Callback-basierte Version dieser Funktion sehen. Diese ist veraltet, und die Verwendung wird dringend abgeraten. Sie sollten jeden vorhandenen Code aktualisieren, um die auf Promise basierende Version von createOffer() zu verwenden. Die Parameter der älteren Form von createOffer() sind unten beschrieben, um bei der Aktualisierung vorhandenen Codes zu helfen.
successCallback Veraltet
Eine Callback-Funktion, die ein einziges RTCSessionDescription-Objekt übergeben bekommt, das das neu erstellte Angebot beschreibt.
errorCallback Veraltet
Eine Callback-Funktion, die ein einziges DOMException-Objekt übergeben bekommt, das erklärt, warum die Anfrage zur Erstellung eines Angebots fehlgeschlagen ist.
options Optional
Ein optionales Objekt, das die für das Angebot angeforderten Optionen bereitstellt.
Ein Promise, das mit einem Objekt erfüllt wird, das dieselben Eigenschaften wie ein RTCSessionDescription-Objekt enthält:
type
Ein String, dessen Wert "offer" ist.
sdp
Ein String, der das SDP beschreibt, das das generierte Angebot beschreibt, und an den entfernten Peer geliefert werden soll.
Diese Ausnahmen werden durch die Ablehnung des zurückgegebenen Promises zurückgegeben. Ihr Ablehnungs-Handler sollte die empfangene Ausnahme untersuchen, um festzustellen, welche aufgetreten ist.
InvalidStateError DOMException
Wird zurückgegeben, wenn die RTCPeerConnection geschlossen ist.
NotReadableError DOMException
Wird zurückgegeben, wenn kein Zertifikat oder kein Satz von Zertifikaten für die Sicherung der Verbindung bereitgestellt wurde und createOffer() kein neues erstellen konnte. Da alle WebRTC-Verbindungen gesichert sein müssen, führt dies zu einem Fehler.
OperationError DOMException
Wird zurückgegeben, wenn das Ãberprüfen des Zustands des Systems, um die Ressourcenverfügbarkeit festzustellen und das Angebot zu erstellen, aus irgendeinem Grund fehlgeschlagen ist.
Hier sehen wir einen Handler für das negotiationneeded-Ereignis, der das Angebot erstellt und es über einen Signalisierungskanal an das entfernte System sendet.
Hinweis: Denken Sie daran, dass dies Teil des Signalisierungsprozesses ist, wobei die Transportschicht ein Implementierungsdetail ist, das ganz bei Ihnen liegt. In diesem Fall wird eine WebSocket-Verbindung verwendet, um eine JSON-Nachricht mit einem type-Feld mit dem Wert "video-offer" an den anderen Peer zu senden. Der Inhalt des Objekts, das an die Funktion sendToServer() übergeben wird, zusammen mit allem anderen im Promise-Erfüllung-Handler, hängt vollständig von Ihrem Design ab.
myPeerConnection
.createOffer()
.then((offer) => myPeerConnection.setLocalDescription(offer))
.then(() => {
sendToServer({
name: myUsername,
target: targetUsername,
type: "video-offer",
sdp: myPeerConnection.localDescription,
});
})
.catch((reason) => {
// An error occurred, so handle the failure to connect
});
In diesem Code wird das Angebot erstellt, und sobald es erfolgreich ist, wird das lokale Ende der RTCPeerConnection konfiguriert, um zu passen, indem das Angebot (das durch ein Objekt in derselben Form wie RTCSessionDescription dargestellt wird) an setLocalDescription() übergeben wird. Sobald das erledigt ist, wird das Angebot über den Signalisierungskanal an das entfernte System gesendet; in diesem Fall durch eine benutzerdefinierte Funktion namens sendToServer(). Die Implementierung des Signalisierungsservers ist unabhängig von der WebRTC-Spezifikation, so dass es keine Rolle spielt, wie das Angebot gesendet wird, solange sowohl der Anrufer als auch der potenzielle Empfänger denselben verwenden.
Verwenden Sie Promise.catch(), um Fehler abzufangen und zu behandeln.
Siehe Signalisierung und Videoanrufe für das vollständige Beispiel, aus dem dieser Ausschnitt abgeleitet ist; dies wird Ihnen helfen zu verstehen, wie der Signalisierungscode hier funktioniert.
Spezifikationen Browser-KompatibilitätRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4