WebRTC代碼故障排除

Question

我正在用這個拉我的頭髮。大約一個月前，我能夠使用來自SignalR優秀人員的一些示例代碼，將WebRTC演示概念驗證整合在一起。該演示程序位於here，源代碼爲here，並且它執行它應該執行的操作。

但是，當我把這些代碼並移動到我們的實際應用中，我一直沒能得到它的工作。當然，代碼必須被顯着地改變 - 不同的後端，不同的框架和支持代碼，支持多種同時連接等等 - 但是核心邏輯非常相似。但我無法讓它工作。

我一個示例應用程序放在這裏一起演示該問題：

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(): Calling 7d9e0d39-5047-4afe-86e5-e6e01b9f5955 when preparations have finished

12:17:58.533 WebRTCController.prepareForCall(): Preparing for call: localSessionId='39d2df53-6854-415a-8748-b5230eda2eb1'; remoteSessionId='7d9e0d39-5047-4afe-86e5-e6e01b9f5955'

12:18:0.139 Object.(): The user has granted media device access, so proceeding to prepare for call

12:18:0.141 Connection.createPeerConnection(): Creating peer connection; using stunServer stun:stun1.l.google.com:19302

12:18:0.144(): Preparations finished. Creating and sending JSEP offer. Util.js:21

12:18:0.272 Connection.handleIceCandidate(): STUN server has found an ICE candidate (event.type='icecandidate').

12:18:0.282 Connection.handleIceCandidate(): STUN server has found an ICE candidate (event.type='icecandidate').

(More like that)

12:18:0.655 WebRTCController.handleJsepAnswer(): Handling JsepAnswer from 7d9e0d39-5047-4afe-86e5-e6e01b9f5955

12:18:0.694 Object.(): Sending ICE candidate to the remote machine: {"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:2999745851 1 udp 2113937151 192.168.56.1 62978 typ host generation 0\r\n"}

12:18:0.706 Object.(): Sending ICE candidate to the remote machine: {"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:2999745851 2 udp 2113937151 192.168.56.1 62978 typ host generation 0\r\n"}

(More like that)

但後來一直連接不上，即，從另一端的視頻從未開始播放。在信令層，我可以通過日誌和逐步瀏覽第一個瀏覽器發送JSEP提供的代碼來判斷，第二個瀏覽器正在接收它，存儲它併發回一個適當的JSEP答案;第一臺機器正在存儲該答案。每個peerConnection然後找到ICE候選者並將它們發送到遠程機器;並且每個peerConnection正在接收並顯然嘗試那些ICE候選人;並且peerConnections甚至提高了事件。但視頻從不開始播放。

的等連接的狀態對象一路走過這個樣子的：

(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(): Error setting local description from created answer: SetLocalDescription failed.; answer={"sdp":"v=0\r\no=- 439659381 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf\r\nm=audio 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=ice-ufrag:vOKflTJ56gV0R9i0\r\na=ice-pwd:9nuXPMDvQ2mZATFCQyEzPRQz\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:m9q9pmLgLuFnfFC09KXKW5p8TjsKk+VdqX0OWv77\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:111 opus/48000/2\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 telephone-event/8000\r\na=ssrc:548068416 cname:IXg8QRisWrd7+7f8\r\na=ssrc:548068416 msid:u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf a0\r\na=ssrc:548068416 mslabel:u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjf\r\na=ssrc:548068416 label:u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjfa0\r\nm=video 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=ice-ufrag:vOKflTJ56gV0R9i0\r\na=ice-pwd:9nuXPMDvQ2mZATFCQyEzPRQz\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:m9q9pmLgLuFnfFC09KXKW5p8TjsKk+VdqX0OWv77\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:116 red/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 label:u9fhVrWeLLweqb5ubLkw61Ijsh6BM6vZLhjfv0\r\n","type":"answer"}

現在我只需要弄清楚爲什麼那個特定的SDP - 直接來自createAnswer()方法 - 正在失敗。

更新2012-12-20：我在這裏創建了一個在線演示問題：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.

不知道他們有我的問題有什麼關係，但我繼續瞭解更多。

*編輯2012-12-20：我管理（我認爲）縮小了問題的範圍。有關更詳細的信息，請參閱this question。

Answer 1

想通了。事實證明，SignalR 1.0 RC1有一個錯誤，它將字符串中的任何「+」改爲空格。因此，在SDP線，看上去像這樣：

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2+z

都拿到變成這樣：

a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2 z

但因爲不是每個SDP在它有一個「+」在臨界線，有時會起作用。一切解釋。

的錯誤已被報告給好鄉親在SignalR（見https://github.com/SignalR/SignalR/issues/1194）的工作，並在此期間，一個簡單的encodeURIComponent()和decodeURIComponent()周圍有問題的琴絃固定它。