簡體   English   中英

Firefox WebRTC信號通知DOMException無法解析SDP

[英]Firefox WebRTC signaling DOMException Failed to parse SDP

我正在使用WebRTC數據通道在HTML5游戲中進行聯網。 盡管可以使用WebRTC進行P2P,但該項目的拓撲結構是集中的客戶端-服務器。 該服務器是充當WebRTC對等方的Node.js進程。 客戶端是與服務器建立1-1連接的瀏覽器。

我正在使用簡單對等庫在客戶端和服務器上處理WebRTC。 在Node.js服務器上,我使用wrtc模塊作為對等連接實例。 對於信號交換 ,我在客戶端和服務器上都使用signalhub

以下是一些偽代碼,演示了如何設置握手

//client
var peer = new SimplePeer({initiator: true});
peer.on('signal', (signalPayload) => signalHub.broadcast('client_signal', signalPayload));
signalHub.subscribe('server_signal', function(signalPayload){ peer.signal(signalPayload) });

//server
signalHub.subscribe('client_signal', (signalPayload) => {
    peer = new Simplepeer({});
    peer.signal(signalPayload);

    peer.on('signal', (signalPayload) => signalHub.broadcast('server_signal', signalPayload));
})

當前設置始終可以在Chrome中正常運行...

Firefox無法建立連接。 簡單對等方的錯誤處理程序會引發錯誤對等方peer.on('error', (err) => {})

DOMException: "Failed to parse SDP: SDP Parse Error on line 6: No webrtc-datachannel token in m= media line, parse failed.

觸發此錯誤的特定信號有效負載如下所示:

v=0
o=- 1575807233894551963 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=application 0 UDP/DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=mid:0
a=sctpmap:5000 webrtc-datachannel 1024

這是服務器發送給客戶端的有效負載,它是“答案”有效負載。

以下是Chrome與Firefox的offeranswer有效負載的完整比較

  • Chrome提供給Node.js
{
type: "offer",
sdp:
"v=0
o=- 5121147169778109884 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=ice-ufrag:CmIA
a=ice-pwd:jHCWR4JJquU/r8KXtP0cQ9YN
a=ice-options:trickle
a=fingerprint:sha-256 0C:AC:DB:40:8E:AD:58:D8:09:3B:66:94:63:1B:00:D0:09:BD:F3:72:BF:29:66:53:94:9B:67:22:A9:27:A0:35
a=setup:actpass
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024
"
}
  • Firefox提供給Node.js
{
 type: "offer",
sdp:
"v=0
o=mozilla...THIS_IS_SDPARTA-64.0.2 6450781105440687594 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 54:5D:CF:E6:B6:B5:9B:60:C3:AB:F3:EC:5A:62:18:5E:13:F2:1A:23:86:03:BA:9D:D0:EA:67:7B:1C:5C:0A:2A\r\na=group:BUNDLE 0\r\na=ice-options:trickle
a=msid-semantic:WMS *
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:c2217ee835bac1bdc0a765ebf1b5de2c
a=ice-ufrag:b0ceda3e
a=mid:0
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823"
}
  • Node.js回答Chrome優惠
"v=0
o=- 4547471447226747141 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 62951 DTLS/SCTP 5000
c=IN IP4 192.168.1.159
b=AS:30
a=candidate:105744546 1 udp 2122260223 192.168.1.159 62951 typ host generation 0 network-id 1 network-cost 50
a=ice-ufrag:taPA
a=ice-pwd:Q/W3D4wgrRqMrfVT51yO3i5T
a=fingerprint:sha-256 2A:3C:A3:64:92:7D:32:F5:AB:5F:69:1F:C1:76:82:4C:97:A3:FE:CA:70:C5:E3:FA:FC:C0:11:FC:E3:DB:D5:1C
a=setup:active
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024"
  • Node.js回答Firefox的提議
"v=0
o=- 1575807233894551963 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=application 0 UDP/DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=mid:0
a=sctpmap:5000 webrtc-datachannel 1024"

我們可以看到Firefox的答案負載看起來很奇怪。 它缺少fingerprint和其他a=字段。 另外,它確實包含m=字段,這很奇怪,然后它拋出DOMException聲明無法解析它。

非瀏覽器端點不支持v21 SCTP報價,給出格式錯誤的答案

看起來您服務器上的webrtc代碼(設置中的遠程端點)不支持Firefox提供的較新的m=application格式,並且在這種情況下會產生錯誤的答案,這正是Firefox期望的,Firefox對此感到窒息以新格式為其新格式產品提供的答案:

  • Firefox優惠:
 m=application 9 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port:5000 

Firefox(63+)使用的是2017年以來SCTP SDP草案的21+較新版本

Chrome使用了2013年以來的SCTP SDP草案的舊版本05

  • Chrome優惠:
 m=application 9 DTLS/SCTP 5000 a=sctpmap:5000 webrtc-datachannel 1024 

不幸的是,這是一個重大變化。 舊解析器希望在m行中找到一個數字( 5000 ),新解析器希望在其中webrtc-datachannel 在此處了解更多信息。

當Firefox作為回答者時,它會同時響應這兩個問題(舊提議的舊答案,新提議的新答案),太好了! 但是,當Firefox是要約人時(在這種情況下),它發出一個新要約並期望得到一個新的答案(Chrome,BTW知道如何回答新要約,即使它本身並未發出請求)。

解決方法

理想情況下,您需要更新服務器以發出正確的答案。 取而代之的是,如果將Firefox作為應答器,它應該可以工作。

如果這不是一個選擇,則可以在兩種格式之間調整SDP:在服務器看到Firefox之前,您需要將Firefox的報價更改為舊格式,然后在使用setRemoteDescription對其進行設置之前,將其答案恢復為新格式。火狐瀏覽器。

基於下面問題的評論,我認為現在很清楚wrtc Node模塊不理解較新版本的Firefox使用的新SCTP SDP格式。 然后需要修復wrtc模塊並進行更新。

我看到您已經打開https://github.com/node-webrtc/node-webrtc/issues/483 我認為這是解決問題的方法。

從Chrome獲得此類答案的唯一方法是,如果您使用其專有的rtp數據通道,如下所示:

var pc = new RTCPeerConnection(null, {optional: [{RtpDataChannels: true}]});
pc.setRemoteDescription({type: 'offer', sdp: 'v=0\no=mozilla...THIS_IS_SDPARTA-64.0.2 6450781105440687594 0 IN IP4 0.0.0.0\ns=-\nt=0 0\na=sendrecv\na=fingerprint:sha-256 54:5D:CF:E6:B6:B5:9B:60:C3:AB:F3:EC:5A:62:18:5E:13:F2:1A:23:86:03:BA:9D:D0:EA:67:7B:1C:5C:0A:2A\r\na=group:BUNDLE 0\r\na=ice-options:trickle\na=msid-semantic:WMS *\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\nc=IN IP4 0.0.0.0\na=sendrecv\na=ice-pwd:c2217ee835bac1bdc0a765ebf1b5de2c\na=ice-ufrag:b0ceda3e\na=mid:0\na=setup:actpass\na=sctp-port:5000\na=max-message-size:1073741823\n'})

其次是createAnswer。

不要這樣 rtp數據通道在所有方面均低於標准數據通道。 不要使用它。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM