javascript - WebRTC onicecandidate : Am getting ICE candidates with sdpMid=audio only but not for video

Question

使用的浏览器是 Chrome...我有调用者和接收者代码来生成 SDP 和 ICE 候选者。我获取调用者代码以使用 sdpMid=video 生成正确的 SDP 和 ICE 候选者，但对于接收者，我仅获取为 sdpMid=audio 生成的 ICE 候选者。

更新:这是更改后接收方的 localSessionDescription SDP，如建议的:

 v=0
 o=- 7912682607537349212 2 IN IP4 127.0.0.1
 s=-
 t=0 0
 a=group:BUNDLE audio video
 a=msid-semantic: WMS 9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
 m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
 c=IN IP4 0.0.0.0
 a=rtcp:9 IN IP4 0.0.0.0
 a=ice-ufrag:0D1hLEwxnqReQosQ
 a=ice-pwd:Nsc4EAtefrfgzTetHjJA5lsg
 a=fingerprint:sha-256 6C:85:D8:33:D8:C6:CB:CE:D4:8E:B4:7A:C2:F5:2F:D0:67:04:25:B2:74:F9:C6:3A:2E:96:E6:56:E7:27:B0:F8
 a=setup:active
 a=mid:audio
 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
 a=sendrecv
 a=rtcp-mux
 a=rtpmap:111 opus/48000/2
 a=fmtp:111 minptime=10; useinbandfec=1
 a=rtpmap:103 ISAC/16000
 a=rtpmap:104 ISAC/32000
 a=rtpmap:9 G722/8000
 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:2958641119 cname:Iu8s16HLxglPDg9k
 a=ssrc:2958641119 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd bb63739b-cca2-4aa5-90a6-cf4bbaa199af
 a=ssrc:2958641119 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
 a=ssrc:2958641119 label:bb63739b-cca2-4aa5-90a6-cf4bbaa199af
 m=video 9 UDP/TLS/RTP/SAVPF 100 101 116 117 96
 c=IN IP4 0.0.0.0
 a=rtcp:9 IN IP4 0.0.0.0
 a=ice-ufrag:0D1hLEwxnqReQosQ
 a=ice-pwd:Nsc4EAtefrfgzTetHjJA5lsg
 a=fingerprint:sha-256 6C:85:D8:33:D8:C6:CB:CE:D4:8E:B4:7A:C2:F5:2F:D0:67:04:25:B2:74:F9:C6:3A:2E:96:E6:56:E7:27:B0:F8
 a=setup:active
 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=extmap:4 urn:3gpp:video-orientation
 a=sendrecv
 a=rtcp-mux
 a=rtpmap:100 VP8/90000
 a=rtcp-fb:100 ccm fir
 a=rtcp-fb:100 nack
 a=rtcp-fb:100 nack pli
 a=rtcp-fb:100 goog-remb
 a=rtcp-fb:100 transport-cc
 a=rtpmap:101 VP9/90000
 a=rtcp-fb:101 ccm fir
 a=rtcp-fb:101 nack
 a=rtcp-fb:101 nack pli
 a=rtcp-fb:101 goog-remb
 a=rtcp-fb:101 transport-cc
 a=rtpmap:116 red/90000
 a=rtpmap:117 ulpfec/90000
 a=rtpmap:96 rtx/90000
 a=fmtp:96 apt=100
 a=ssrc-group:FID 3143004909 4248148453
 a=ssrc:3143004909 cname:Iu8s16HLxglPDg9k
 a=ssrc:3143004909 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd 778ef702-e7fc-47ea-bb3a-477e0b4262ba
 a=ssrc:3143004909 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
 a=ssrc:3143004909 label:778ef702-e7fc-47ea-bb3a-477e0b4262ba
 a=ssrc:4248148453 cname:Iu8s16HLxglPDg9k
 a=ssrc:4248148453 msid:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd 778ef702-e7fc-47ea-bb3a-477e0b4262ba
 a=ssrc:4248148453 mslabel:9f0MAtEwYGWY3pdBDI8ZtTu4dVu92R6IpEFd
 a=ssrc:4248148453 label:778ef702-e7fc-47ea-bb3a-477e0b4262ba

这是为相应的 getUserMedia 生成的，如下所示:

 navigator.getUserMedia({ audio: true, video: { width: 1280, height: 720 } },...

ICE候选生成代码是:

pc.onicecandidate = function (event) {
   console.log("Generated Icecandidate:" );
   console.log(event);
   ...
 };

在 console.log 上，我看到 ICE 候选者，如下所示:

RTCIceCandidate
candidate: "candidate:211156821 1 udp 2122260223 192.168.1.5 41811 typ host generation 0 ufrag kV5Snl0LQhJlYujt"
sdpMLineIndex:0
sdpMid:"audio"

不用说，我无法显示远程视频。我正在本地网络上尝试这个，所以实际上甚至不需要 STUN。

我想知道为什么我没有收到任何 sdpMid=video 的 ICE 候选者。此外，在生成的四个 ICE 候选中，三个 ICE 候选的 sdpMLineIndex:0，一个 ICE 候选的候选属性为 null!

更新 1:我得到了上一期的答案...候选属性为 Null。 “注意:RTCPeerConnection.onicecandidate 将使用空候选属性调用一次，以表示滴流 ICE 事件结束。”这是解释here .

在调用方，我收到了 10 多个 ICE 候选者，其中一些带有音频，一些带有视频。

我哪里出错了？

更新2:以下是接收器部分的代码，它不会生成视频的 ICE 候选者。我删除了身份验证和其他部分，只关注相关部分。我删除了 ICE 候选的缓存并在它到来时发送它:

$(document).ready(function () {

  var socket = io.connect();
  var pc = new RTCPeerConnection ({
    "iceServers": [{"url": "stun:stun.l.google.com:19302"}]
  });

  pc.onicecandidate = function (event) {
    socket.emit('candidateFromReceiver',event.candidate);
    console.log("Candidate Generated:");
    console.log(event.candidate);
  }; 

  pc.onaddstream = function(ev) {
    stream = ev.stream;        
    var video = $('#vid2'); 
    video.attr('src', URL.createObjectURL(stream));
    video.onloadedmetadata = function(e) {
      video.play();
    }
  };

  socket.on('connect',function() { console.log("Socket connected"); });
  socket.on('candidateFromCaller', function (data) {
      pc.addIceCandidate(new RTCIceCandidate(data));
  });

  navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia ||
                       navigator.mozGetUserMedia;
  if (navigator.getUserMedia) {
    navigator.getUserMedia({ audio: true, video: { width: 1280, height: 720 } },
      function(stream) {
         var video = $('#vid1'); 
         video.attr('src', URL.createObjectURL(stream));
         video.onloadedmetadata = function(e) {
           video.play();
         }
     pc.addStream(stream);
      },error);

    socket.on('sdpOffer', function(data) {
      var sdpOffer = new RTCSessionDescription(data.sdpOffer);
      pc.setRemoteDescription(sdpOffer, function() {
        pc.createAnswer(function(sdpAnswer) {
          localSessionDescription = new RTCSessionDescription(sdpAnswer);
          pc.setLocalDescription(localSessionDescription, function() {
            socket.emit('sdpAnswer',localSessionDescription);
          },error);
        }, error);
      },error);
    });
  }

  function error(err) {
    console.log("ERROR!!!!");
    console.log(err);
  }

}); // End of document.ready function

如果我在获取用户媒体后插入代码来生成报价(正如我在调用者代码中所做的那样)，则生成的 ICE 候选也包括视频候选。当然，这只是为了测试，正如预期的那样，之后的其余代码炸弹都是如此。

Answer 1

(从评论中可以看出，您正在缓存 ICE 候选人。不要这样做。我还怀疑时间问题可能是导致某些候选人流失的原因。)

Trickle ICE 的全部目的是涓流候选人，即一旦有空就发送候选人。

使用 WebRTC，您的应用程序负责在对等点之间发送信号，这是时间敏感的。所以:

1. 在 setLocalDescription 成功回调中发送 pc.localDescription。
2. 预计 pc.onicecandidate 会在该回调后立即开始触发。发送给他们。

双方都是如此(对于提议和答复)。您希望在线看到的是:

offer, candidate, candidate, candidate

另一种方式:

answer, candidate, candidate, candidate

不该做什么:

• 不要缓存 ICE 候选者。
• 不要等到得到答复，那只会浪费时间。
• 当接收端因任何原因收到录用通知时，请勿延迟调用 setRemoteDescription，否则接收端将无法准备好接收候选人。

更新2:

您的 sdp 表示 a=recvonly 而不是 a=sendrecv，这意味着接收者只能接收，而不发送任何返回。以下两种情况之一可能会导致此情况:

1. 调用者设置 createOffer 选项，例如 offerToReceiveVideo:false 和/或 offerToReceiveAudio:false。
2. 接收方未及时调用 pc.addStream(之前)pc.setLocalDescription。

如果 getUserMedia 和收到报价之间存在竞争，则可能会发生第二种情况。

更新3:

如果所有其他方法都失败，请与工作代码进行比较。我之前在其他答案中分享过一个跨标签演示，但它只发送了视频，没有收到任何视频。

这是a modified version of that demo只接收来自远程摄像机的视频。像往常一样，在同一浏览器的两个选项卡中打开它。

请注意，在 Firefox 中，点击调用后，您必须先将焦点对准另一个选项卡，然后才能允许访问摄像头。