是否可以將 WebRTC SDP 報價轉換為答案？

Question

我有兩個想要通過 WebRTC 相互連接的對等方。通常，第一個對等方會創建一個報價並通過信令通道/服務器將其發送給第二個對等方，第二個對等方會回應一個答案。 這種情況很好。

但是，是否有可能支持兩個對等點碰巧嘗試同時相互連接的情況，兩者都通過信令服務器同時向彼此發送 SDP 提議。

// Both peers do this simultaneously:
const conn = new RTCPeerConnection(null);
const sdpOffer = await conn.createOffer();
await conn.setLocalDescription(sdpOffer);
signalingService.send(peerId, sdpOffer);

// At some point in the future both peers also receive an SDP offer 
// (rather than answer) from the other peer whom they sent an offer to 
// via the signaling service. If this was an answer we'd call 
// RTCPeerConnection.setRemoteDescription, however this doesn't work for an 
// offer: 

conn.setRemoteDescription(peerSDPOffer); 
// In Chrome results in "DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer"

我什至嘗試通過將 SDP 類型從offer重寫為answer並將setup:actpass為setup:active來將接收到的對等方提議“轉換”為答案，但這似乎不起作用，相反我只是得到一個新的異常。

所以問題是，是否以某種方式支持這種同時連接/提供用例 - 或者我應該關閉一側/對等 RTCPeerConnection 並這次使用RTCPeerConnection.createAnswer實例化一個新的？

Answer 1

這種情況稱為“信號眩光”。 WebRTC API並未真正定義處理方式（所謂的“回滾”除外，但尚未在任何瀏覽器中實現，並且到目前為止還沒有人錯過它），因此您必須自己避免這種情況。

簡單地替換a = setup是行不通的，因為底層的DTLS機制仍然需要客戶端和服務器的概念。

Answer 2

這些天如何避免眩光的答案是使用完美協商模式： https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Perfect_negotiation

然而，OP 所描述的確實與設置設置的輕微修改一起工作：在一個對等體上setup:active和setup:passive ： https://codepen.io/evan-brass/pen/mdpgWGG?editors=0010

它可能不適用於音頻/視頻連接（因為它們可能需要協商編解碼器），但我已經在 Chrome / Firefox / Safari 上針對僅 DataChannel 連接進行了測試。

您可以使用您用來確定完美協商中的“禮貌”的任何系統來選擇哪個對等方是主動的，哪個是被動的。 一種可能性是比較 DTLS 指紋並使較大的指紋成為活動對等體。