我拉我的头发与这一个。 大约一个月前，我能够放在一起证明了概念的WebRTC演示中，使用一些示例代码从SignalR的好乡亲。 该演示位于这里 ，因为它的来源是在这里 ，它做什么它应该做的。
但是，当我把这些代码并移动到我们的实际应用中，我一直没能得到它的工作。 当然，代码必须显著变化 - 不同的后端，另一组框架和配套代码，支持多个并发连接，诸如此类的事情 - 但核心的逻辑非常相似。 但我不能得到它的工作。
我在这里把一个示例应用程序演示该问题：
https://bitbucket.org/smithkl42/signalr.webrtc
核心的WebRTC逻辑是所有在这个打字稿文件：
https://bitbucket.org/smithkl42/signalr.webrtc/src/tip/SignalR.WebRTC/Scripts/Media/WebRTC.ts?at=default
这是几百线长，所以我不会打扰在这里张贴，但您可以通过点击上面的链接上看到它。
当它运行时，它会产生这样的输出：
12：17：58.531 WebRTCController.call（）：调用7d9e0d39-5047-4afe-86e5-e6e01b9f5955当制剂已经完成
12：17：58.533 WebRTCController.prepareForCall（）：准备呼叫：localSessionId = '39d2df53-6854-415a-8748-b5230eda2eb1'; remoteSessionId = '7d9e0d39-5047-4afe-86e5-e6e01b9f5955'
12：18：0.139对象（）：该用户已授予媒体设备的访问，所以前进到用于呼叫准备
12：18：0.141 Connection.createPeerConnection（）：创建对等体连接; 使用stunServer击晕：stun1.l.google.com：19302
12：18：0.144（）：准备结束。 创建和发送JSEP报价。 util.js中：21
12：18：0.272 Connection.handleIceCandidate（）：STUN服务器发现一个ICE候选（event.type = 'icecandidate'）。
12：18：0.282 Connection.handleIceCandidate（）：STUN服务器发现一个ICE候选（event.type = 'icecandidate'）。
（更像是）
12：18：0.655 WebRTCController.handleJsepAnswer（）：从7d9e0d39-5047-4afe-86e5-e6e01b9f5955处理JsepAnswer
12：18：0.694对象（）：发送ICE候选到远程机器：{ “sdpMLineIndex”：0 “sdpMid”： “音频”， “候选”：“A =候选：2999745851 1 UDP 2113937151 192.168.56.1 62978典型的宿主代0 \ r \ n“个}
12：18：0.706对象（）：发送ICE候选到远程机器：{ “sdpMLineIndex”：0 “sdpMid”： “音频”， “候选”：“A =候选：2999745851 2 UDP 2113937151 192.168.56.1 62978典型的宿主代0 \ r \ n“个}
（更像是）
但随后一直连接不上，即，从另一端的视频从未开始播放。 在信令层，我可以由日志和由通过所述第一浏览器发送一个JSEP报价的代码告诉步进; 第二浏览器正在接收它，储存它和发回一个适当的回答JSEP; 和第一机存储这个问题的答案。 然后，将每个等连接是找到ICE候选人和将它们发送到远程机器; 并且每个等连接被接收和显然是想那些ICE候选人; 和peerConnections甚至提高onaddstream事件。 但是视频从未开始播放。
对等连接的状态对象一路走过这个样子的：
(iceGatheringState=new; iceState=starting; readyState=active)
令人沮丧的一点是，每隔一段时间，也许有时间了20，它的工作，即，两个视频显示。 所以，我不这样做的一切错误。 这听起来像是某种形式的计时问题 - 但我无法弄清楚它是什么。 而且据我所知，有没有在的WebRTC对象很多（特别是RTCPeerConnection）告诉你什么地方出了错。
我讨厌问别人做我排除故障，对我来说......嗯，我跑出来的选择。 有没有人看不到我在做显然是错误的？
更新2012年12月19日 ：我正在做一些进展。 我意识到我打电话peerConnection.setLocalDescription()同步，即没有指定回调。 所以，现在我已经得到了一些代码行看起来像这样：
// Answer the call by sending a JsepAnswer message.
connection.peerConnection.createAnswer(
answer => {
connection.peerConnection.setLocalDescription(answer, () => {
var signalState: mData.SignalState = {
FromSessionId: connection.localSessionId,
ToSessionId: connection.remoteSessionId,
Message: JSON.stringify(answer)
};
me.roomHub.server.jsepAnswer(signalState);
mUtil.log("Sent JSEP answer: " + signalState.Message);
connection.readyForIceCandidates.resolve();
},
error => {
mUtil.error("Error setting local description from created answer: " + error + "; answer=" + JSON.stringify(answer));
});
},
error => {
mUtil.error("Error creating answer: " + error);
}, me.mediaConstraints);
而setLocalDescription()错误回调是显示此错误：
16：14：42.439 WebRTCController.handleJsepOffer（）：错误从创建接收设定本地描述：SetLocalDescription失败.; 回答= { “SDP”：“V = 0 \ r \没有= - 439659381 2 IN IP4 127.0.0.1 \ r \ NS = - \ r \ NT = 0 0 \ r \ NA =组：将音频视频\ r \ NA = MSID的语义：WMS u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf \ r \纳米= 1音频RTP / SAVPF 103 104 111 0 8 107 106 105 13 126 \ r \ NC = IN IP4 0.0.0.0 \ r \ NA = RTCP：1 IN IP4 0.0。 0.0 \ r \ NA =冰冷ufrag：vOKflTJ56gV0R9i0 \ r \ NA =冰冷PWD：9nuXPMDvQ2mZATFCQyEzPRQz \ r \ NA = SENDRECV \ r \ NA =中期：音频\ r \ NA = RTCP-MUX \ r \ NA =密码： 1 AES_CM_128_HMAC_SHA1_80直列：m9q9pmLgLuFnfFC09KXKW5p8TjsKk + VdqX0OWv77 \ r \ NA = rtpmap：103 ISAC / 16000 \ r \ NA = rtpmap：104 ISAC / 32000 \ r \ NA = rtpmap：111 OPUS /二分之四万八\ r \ NA = rtpmap：0 PCMU / 8000 \ r \ NA = rtpmap：8 PCMA / 8000 \ r \ NA = rtpmap：107 CN / 48000 \ r \ NA = rtpmap：106 CN / 32000 \ r \ NA = rtpmap：105 CN / 16000 \ r \ NA = rtpmap：13 CN / 8000 \ r \ NA = rtpmap：126电话事件/ 8000 \ r \ NA = SSRC：548068416 CNAME：IXg8QRisWrd7 + 7f8 \ r \ NA = SSRC：548068416 MSID：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf A0 \ r \呐= SSRC：548068416 mslabel：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf \ r \ NA = SSRC：548068416标签：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjfa0 \ r \ NM =视频1 RTP / SAVPF 100 116 117 \ r \ NC = IN IP4 0.0.0.0 \ r \ NA = RTCP：1 IN IP4 0.0.0.0 \ r \ NA =冰冷ufrag：vOKflTJ56gV0R9i0 \ r \ NA =冰冷PWD：9nuXPMDvQ2mZATFCQyEzPRQz \ r \ NA = SENDRECV \ r \ NA =中期：视频\ r \ NA = RTCP-MUX \ r \ NA =加密：1 AES_CM_128_HMAC_SHA1_80直列：m9q9pmLgLuFnfFC09KXKW5p8TjsKk + VdqX0OWv77 \ r \ NA = rtpmap：100 VP8 / 90000 \ r \ NA = rtpmap：116红色/ 90000 \ r \ NA = rtpmap：117 ulpfec / 90000 \ r \ NA = SSRC：1460425980 CNAME：IXg8QRisWrd7 + 7f8 \ r \ NA = SSRC：1460425980 MSID：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf V0 \ r \ NA = SSRC：1460425980 mslabel：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf \ r \ NA = SSRC：1460425980标签：u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjfv0 \ r \ n”个， “类型”： “应答”}
现在我只需要弄清楚为什么那个特定的SDP -这直接来自createAnswer()方法-失败。
更新二零一二年十二月二十〇日 ：我创建了这里的问题的在线演示： http://srdemo.alanta.com/ 。 我也打开Chrome的调试日志记录，与我看到一群看起来像这样的错误的结果：
[6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null. [6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null. [6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null. [6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null. [6584:7308:1220/091356:ERROR:rtc_peer_connection_handler.cc(84)] Native session description is null.
不知道他们有什么关系，我的问题，但我一直在寻觅到它。
*编辑二〇一二年十二月二十○日：我已经成功（我认为），以缩小问题了。 见这个问题进行更精确的细节。
