WebRTC冰候选人

时间:2013-11-16 15:03:25

标签: networking webrtc

我设置了RTCPeerConnection但它只在本地工作(在我的无线连接上有两台笔记本电脑)。对于其他连接,我看到一个黑色的流。我怀疑这是因为ICE候选人没有被正确收集,他们只包含本地IP:

RTCIceCandidate {sdpMLineIndex: 0, sdpMid: "", candidate: "a=candidate:2999745851 1 udp 2113937151 192.168.56.1 51411 typ host generation 0
↵"} app.js:14530
RTCIceCandidate {sdpMLineIndex: 0, sdpMid: "", candidate: "a=candidate:3366620645 1 udp 2113937151 192.168.0.17 44628 typ host generation 0
↵"} app.js:14530
RTCIceCandidate {sdpMLineIndex: 1, sdpMid: "", candidate: "a=candidate:2999745851 1 udp 2113937151 192.168.56.1 51411 typ host generation 0
↵"} app.js:14530
RTCIceCandidate {sdpMLineIndex: 1, sdpMid: "", candidate: "a=candidate:3366620645 1 udp 2113937151 192.168.0.17 44628 typ host generation 0
↵"} 
RTCIceCandidate {sdpMLineIndex: 0, sdpMid: "", candidate: "a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0
↵"} app.js:14507
RTCIceCandidate {sdpMLineIndex: 0, sdpMid: "", candidate: "a=candidate:2250862869 1 tcp 1509957375 192.168.0.17 0 typ host generation 0
↵"} app.js:14507
RTCIceCandidate {sdpMLineIndex: 1, sdpMid: "", candidate: "a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0
↵"} app.js:14507
RTCIceCandidate {sdpMLineIndex: 1, sdpMid: "", candidate: "a=candidate:2250862869 1 tcp 1509957375 192.168.0.17 0 typ host generation 0
↵"} 

以下是iceServers配置:

  this.configuration = {
    'iceServers': [
      {
        'url': 'stun:stun.l.google.com:19302'
      }
    ]
  };

然而,在另一台部署机器上,此配置实际上适用于远程对等设备,并且我接收具有公共IP的候选者。

编辑

实际上与另一个对等体运行测试会输出以下内容:

handling offer from radu1 
caching candidate from radu1 (x 15 - saving them locally because the remote description is not received/set yet and it will throw errors like: Illegal string...)
Set remote description from radu1
Object {sdp: "v=0
↵o=- 7594479116751954142 2 IN IP4 127.0.0.1
↵s…06 label:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1v0
↵", type: "offer"}
sdp: "v=0
↵o=- 7594479116751954142 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE audio video
↵a=msid-semantic: WMS iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1
↵m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
↵c=IN IP4 0.0.0.0
↵a=rtcp:1 IN IP4 0.0.0.0
↵a=ice-ufrag:nFjsr4JB2b6hTc4K
↵a=ice-pwd:z3BUY0Mlga5JywRNw9lLGqeF
↵a=ice-options:google-ice
↵a=fingerprint:sha-256 64:76:B6:98:ED:FA:6D:D5:E2:40:B6:FE:98:00:29:F7:28:93:C5:6A:CF:2F:59:D2:B7:82:14:BF:38:FD:3B:83
↵a=setup:actpass
↵a=mid:audio
↵a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
↵a=sendrecv
↵a=rtcp-mux
↵a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xGSOTjjxbfNVNAxoRxY6UFHTJY86bFnGqK1p23Tm
↵a=rtpmap:111 opus/48000/2
↵a=fmtp:111 minptime=10
↵a=rtpmap:103 ISAC/16000
↵a=rtpmap:104 ISAC/32000
↵a=rtpmap:0 PCMU/8000
↵a=rtpmap:8 PCMA/8000
↵a=rtpmap:106 CN/32000
↵a=rtpmap:105 CN/16000
↵a=rtpmap:13 CN/8000
↵a=rtpmap:126 telephone-event/8000
↵a=maxptime:60
↵a=ssrc:4260698723 cname:8jJISPnQEaP+YvYy
↵a=ssrc:4260698723 msid:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1 iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1a0
↵a=ssrc:4260698723 mslabel:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1
↵a=ssrc:4260698723 label:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1a0
↵m=video 1 RTP/SAVPF 100 116 117
↵c=IN IP4 0.0.0.0
↵a=rtcp:1 IN IP4 0.0.0.0
↵a=ice-ufrag:nFjsr4JB2b6hTc4K
↵a=ice-pwd:z3BUY0Mlga5JywRNw9lLGqeF
↵a=ice-options:google-ice
↵a=fingerprint:sha-256 64:76:B6:98:ED:FA:6D:D5:E2:40:B6:FE:98:00:29:F7:28:93:C5:6A:CF:2F:59:D2:B7:82:14:BF:38:FD:3B:83
↵a=setup:actpass
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=sendrecv
↵a=rtcp-mux
↵a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xGSOTjjxbfNVNAxoRxY6UFHTJY86bFnGqK1p23Tm
↵a=rtpmap:100 VP8/90000
↵a=rtcp-fb:100 ccm fir
↵a=rtcp-fb:100 nack
↵a=rtcp-fb:100 goog-remb
↵a=rtpmap:116 red/90000
↵a=rtpmap:117 ulpfec/90000
↵a=ssrc:1805691906 cname:8jJISPnQEaP+YvYy
↵a=ssrc:1805691906 msid:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1 iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1v0
↵a=ssrc:1805691906 mslabel:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1
↵a=ssrc:1805691906 label:iuzaFLXbo6HCbnWGdobaYN2gSPQmAFKZQaP1v0
↵"
type: "offer"

RTC: adding stream from radu1
Sending answer to radu1
Set candidate from cache for radu1 (x 15)
RTCIceCandidate {sdpMLineIndex: 0, sdpMid: "", candidate: "a=candidate:826241329 1 udp 2113937151 169.254.159.173 52996 typ host generation 0
↵"}
...

以上结果是peerconnection.iceConnectionState =' check'。事件的顺序是否适合被调用者?

  1. 收到要约
  2. 从另一个对等方接收冰候选人,但因为没有触发setRemoteDescription回调而没有保存它们
  3. 远程描述已成功设置。
  4. 收到远程流
  5. 发送回答
  6. 添加缓存的候选人
  7. 请注意,此实际设置适用于我的LAN中的两台笔记本电脑。我可以查看远程流。它不适用于不同的网络,黑屏和iceConnectionState = 'checking' 那是什么意思? 如何解决/调试此问题? 我是否需要设置任何其他STUN / TURN服务器?

1 个答案:

答案 0 :(得分:2)

通过正确设置STUN / TURN服务器解决。似乎有些对等体需要TURN服务器来中继流量,因为STUN失败了。