使用Ajax而不是WebSocket进行WebRTC视频聊天：可能吗？

使用Ajax而不是WebSocket进行WebRTC视频聊天：可能吗？

关于您的应用的第一条建议。偶尔工作/不工作是要查看当前的在线工作实现。互联网上有很多WebRTC演示。

AJAX

关于AJAX：为什么不起作用？我目前正在从事与您相同的工作，并且 每次
都可以正常工作（我暂时无法透露消息来源）。客户端不断以固定的时间间隔轮询服务器，他们可以通过这种方式将SDP描述/
ICE候选对象发送到特定的其他客户端。服务器充当一个简单的桥梁（这是信令的基础）。

无论是WebSocket，AJAX还是IPoAC，只要您将他需要的一切转移到另一个客户端（在适当的时候，稍后再介绍），它就可以正常工作。我什至进行了演示，您在其中使用文本区域手动复制/粘贴了SDP描述和ICE候选者，然后单击按钮以在信令过程中前进，当然也可以正常工作。

ICE候选人

现在：是的，您需要ICE候选人。看一下我刚刚在Chromium 27上使用的示例 SDP报价 块

createOffer

：

v=0o=- 3866099361 2 IN IP4 127.0.0.1s=-t=0 0a=group:BUNDLE audio videoa=msid-semantic: WMS 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126c=IN IP4 0.0.0.0a=rtcp:1 IN IP4 0.0.0.0a=ice-ufrag:l8Qu31Vu4VG5YApSa=ice-pwd:TpyQ5iESUH4HvYGE4ay8JUhea=ice-options:google-icea=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-levela=sendrecva=mid:audioa=rtcp-muxa=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bC5YSe2xCmui0wSxUHWKIi9INbZ2y0VrO1swoZbla=rtpmap:111 opus/48000/2a=fmtp:111 minptime=10a=rtpmap:103 ISAC/16000a=rtpmap:104 ISAC/32000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:107 CN/48000a=rtpmap:106 CN/32000a=rtpmap:105 CN/16000a=rtpmap:13 CN/8000a=rtpmap:126 telephone-event/8000a=maxptime:60a=ssrc:1976175890 cname:/+lKYsttecoiyiu5a=ssrc:1976175890 msid:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a0a=ssrc:1976175890 mslabel:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a=ssrc:1976175890 label:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a0m=video 1 RTP/SAVPF 100 116 117c=IN IP4 0.0.0.0a=rtcp:1 IN IP4 0.0.0.0a=ice-ufrag:l8Qu31Vu4VG5YApSa=ice-pwd:TpyQ5iESUH4HvYGE4ay8JUhea=ice-options:google-icea=extmap:2 urn:ietf:params:rtp-hdrext:toffseta=sendrecva=mid:videoa=rtcp-muxa=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bC5YSe2xCmui0wSxUHWKIi9INbZ2y0VrO1swoZbla=rtpmap:100 VP8/90000a=rtcp-fb:100 ccm fira=rtcp-fb:100 nack a=rtpmap:116 red/90000a=rtpmap:117 ulpfec/90000a=ssrc:3452335690 cname:/+lKYsttecoiyiu5a=ssrc:3452335690 msid:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8v0a=ssrc:3452335690 mslabel:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a=ssrc:3452335690 label:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8v0

您是否看到任何可以帮助其他客户端连接到我的计算机的东西？我不这么认为。所有这种ICE机制的目的是，

192.168.1.15

如果您落后于任何非对称的NAT，或者使用TURN的对称NAT，则使用STUN
收集连接候选对象（如本地的，如“公共”（由ISP分配的公共IP）） 。

收到这些ICE候选者后，其他对等方将使用一些预定义的度量对它们进行排序以进行优先级排序，然后发出连接测试以找到合适的候选者。因此，请共享它们：另一个对等方也需要它们（您也需要）。

所以这是我的一些ICE候选人：

a=candidate:303249700 1 udp 2113937151 192.168.50.238 43806 typ host generation 0a=candidate:303249700 2 udp 2113937151 192.168.50.238 43806 typ host generation 0a=candidate:1552991700 1 tcp 1509957375 192.168.50.238 35630 typ host generation 0

现在，这些方法是具体的（尽管只是本地的，因为我没有使用任何STUN URL配置RTC对等连接），以便其他对等方连接到我的计算机。

WebRTC信号提示

此页面底部有一些有趣的提示。我直言不讳地告诉你为什么你应该遵循这些原则或者为什么它们首先存在，但是我确实遵循了它们，没有任何信号问题。他们来了：

1. 对于回答者：在该对等方生成/创建答案SDP之前，请勿添加ICE候选者
2. 远程流开始流动时停止添加ICE候选对象
3. 在获得报价SDP之前，不要为应答者创建对等连接

您可以通过拥有一些WebRTC有限状态机来在客户端进行所有管理。请参阅参考页以了解他的意思是 远程流开始流动 。

尝试共享ICE候选人并将其添加到相反的一侧，并至少遵循提示＃1和＃3，您的应用程序应该可以再次运行。

信令通讯

您询问了在ICE候选人对于共享至关重要的情况下如何将ICE候选人从对等方转移到另一方。要使用AJAX共享内容，无论这些内容是什么，都可以使用邮箱。我相信您已经通过在数据库中放置客户端的内容来完成此 *** 作。

每当对等方需要将某项内容发送给另一方时，请尽快发送（使用AJAX）。在服务器端，将此“邮件”放在目标客户端的邮箱中。当对等方（定期）轮询服务器是否有新邮件时，请为其提供所有新邮件。

创建SDP报价后，会快速生成ICE候选者。所有这些ICE候选对象和SDP描述可能会在几毫秒内进入目标邮箱。目标对等方很有可能立即轮询所有需要的东西。即使ICE候选人迟到，它的下一次投票也会得到它。